KPI 성능 저하 문제 해결 - 4G ASR

소개

이 문서에서는 4G ASR(Attach Success Rate) KPI(Key Performance Indicator) 성능 저하를 해결하는 방법에 대해 설명합니다.

가능한 시나리오

4G ASR 성능 저하는 여러 요인으로 인해 발생할 수 있습니다. 

1. 네트워크 문제
2. 통화 흐름별 문제
3. 노드별 문제
4. 설정 문제
5. RAN 최종 문제

초기 분석에 필요한 로그

1. 성능 저하를 강조하는 KPI 추세 그래프
2. 측정에 사용되는 KPI 공식입니다.
3. 문제가 시작된 이후의 원시 bulkstat 카운터 및 원인 코드 추세
4. 문제 발생 시간 동안 30분 간격으로 SSD(Show Support Details) 인스턴스 2개가 캡처되었습니다.
5. Syslog는 성능 저하 2시간 전부터 현재 시간까지 수집됩니다.
6. 다음 로그를 캡처합니다.
   • Mon-sub/pro traces
   • Logging monitor msid <imsi>

문제 해결 순서

1. ASR 공식을 식별합니다.

1-((emm-msgtx-decode-failure+emm-msgtx-attach-rej-gw-reject+emm-msgtx-attach-rej-activation-reject+emm-msgtx-attach-rej-svc-temp-out-of-order+emm-msgtx-attach-rej-protocol-error+emm-msgtx-attach-auth-failed+attach-proc-fail-max-retx-auth-req+attach-proc-fail-max-retx-sec-mode-cmd+attach-proc-fail-max-retx-attach-accept+attach-proc-fail-setup-timeout-exp+attach-proc-fail-sctp-fail+attach-proc-fail-guard-timeout-exp+attach-proc-fail-max-retx-esm-info-req+emm-msgtx-attach-rej-gw-auth-failed+emm-msgtx-attach-rej-insuff-resources+emm-msgtx-attach-reject-congestion+emm-msgtx-attach-reject-severe-network-failure+emm-msgtx-network-failure ) / (epsattach-imsi-attempted+epsattach-guti-local-attempted+epsattach-guti-foreign-attempted+epsattach-ptmsi-attempted+combinedattach-imsi-attempted+combinedattach-guti-local-attached+combinedattach-guti-foreign-attempted+combinedattach-ptmsi-attempted))

주의: 배합표는 고객의 KPI 측정 방법에 따라 다릅니다.

2. 공식에 따라 ASR을 계산하는 데 사용되는 여러 개의 카운터가 있으므로 통계에서 각 카운터의 KPI 추세를 확인해야 합니다.

3. 문제 아닌 일정 및 문제 있는 일정과 비교하는 점수 체계

4. KPI 공식에서 문제가 있는 Bulkstat 측정값이 확인되면 플로우를 기준으로 이 측정값이 어떻게 정의되는지 확인하고 패턴을 설정해야 합니다. 

5. 또한 3~5분의 시간 간격으로 여러 번 반복되는 노드에서 연결 끊기 사유를 수집합니다.

서로 다른 타임스탬프에 수집된 2개의 SSD에서 연결 끊김 사유의 델타를 찾을 수 있습니다. 델타 단절로부터 급격하게 증가하는 단절사유는 KPI 열화의 원인에 기인할 수 있다. 또한 모든 연결 해제에 대한 설명은 Cisco Statistics and Counters Reference(https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-23/Stat-Count-Reference/21-23-show-command-output/m_showsession.html)에서 확인할 수 있습니다.

show session disconnect-reasons verbose

다음은 연결 끊기 이유 "MME-HSS-User-Unknown"의 증가로 인한 성능 저하 시나리오를 해결하기 위한 트러블슈팅 단계의 예입니다. https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/214633-troubleshoot-4g-asr-kpi-degradation-due.html을 참조하십시오.

6. 노드 유형을 기준으로 egtp 통계를 확인합니다.

--- SGW end -----

show egtpc statistics interface sgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only

show egtpc statistics interface sgw-egress path-failure-reasons
show egtpc statistics interface sgw-egress summary
show egtpc statistics interface sgw-egress verbose
show egtpc statistics interface sgw-egress sessmgr-only

---- PGW end -----

show egtpc statistics interface pgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only

--- MME end -----

show egtpc statistics interface mme path-failure-reasons
show egtpc statistics interface mme summary
show egtpc statistics interface mme verbose
show egtpc statistics interface mme sessmgr-only

 7. KPI 저하를 더 분석하고 트러블슈팅하려면 mon-sub/mon pro 통화 추적을 캡처하고 외부 툴을 사용하여 Wireshark 추적을 얻는 방법을 고려합니다. 이러한 추적은 문제의 원인이 되는 특정 통화 흐름을 식별하는 데 도움이 됩니다.

Mon 하위 추적을 캡처하는 명령은 다음과 같습니다. 

monitor subscriber imsi <IMSI number>  ---------- verosity level +++++,A, S, X, Y, 19. 26, 33, 34, 35
 
More options can be enabled depending on the protocol or call flow we need to capture specifically

8. kpi 저하의 비율이 적어 mon-sub 등의 추적을 캡처할 수 없는 경우 시스템 수준의 디버그 로그를 캡처합니다. 또한 sessmgr 및 egptc에 대한 디버그 로그를 캡처하고 의심되는 문제가 HSS/RAN과 같은 엔터티와 관련된 경우 특정 문제를 기반으로 s1-ap/diameter에 대한 디버그 로그를 캡처합니다.

logging filter active facility sessmgr level debug 
logging filter active facility egtpc level debug
logging filter active facility diameter level debug ----- depending on scenario
logging filter active facility s1-ap evel debug ----- depending on scenario

logging active ----------------- to enable 
no logging active ------------- to disable

Note :: Debugging logs can increase CPU utilization so need to keep a watch while executing debugging logs

9. 디버깅 로그에서 힌트를 얻은 다음 오류 로그가 표시되는 특정 이벤트에 대한 코어 파일을 캡처할 수도 있습니다.

logging enable-debug facility sessmgr instance <instance-ID> eventid 11176 line-number 3219 collect-cores 1

For example :: consider we are getting below error log in debug logs which we suspect can be a cause of issue 
and we don;t have any call trace

[egtpc 141027 info] [15/0/6045 <sessmgr:93> _handler_func.c:10068] [context: MME01, contextID: 6] [software internal user syslog] [mme-egress] Sending reject response for the message EGTP_MSG_UPDATE_BEARER_REQUEST with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE to <Host:x.x.x.x, Port:31456, seq_num:82011>

So in this error event 

facility :: sessmgr
event ID = 141027 
line number = 10068

다음은 이 문제를 해결하기 위한 다양한 단계입니다.