Resolución de problemas de degradación de KPI: ASR 4G

Introducción

Este documento describe cómo resolver problemas de degradación de los indicadores clave de rendimiento (KPI) del índice de éxito de la conexión 4G (ASR).

Situaciones posibles

La degradación de 4G ASR puede deberse a varios factores: 

1. Problemas de red
2. Problema específico del flujo de llamada
3. Problemas Específicos del Nodo
4. Problemas de configuración
5. Problemas de fin de RAN

Registros necesarios para el análisis inicial

1. Gráficos de tendencias de KPI que resaltan la degradación.
2. Fórmula KPI utilizada para la medición.
3. Los contadores de bulkstat sin procesar y las tendencias de código de causa desde que se inició el problema.
4. Dos instancias de Show Support Details (SSD) capturadas en un intervalo de 30 minutos durante el tiempo problemático.
5. Registros del sistema recopilados desde dos horas antes de la degradación hasta la hora actual.
6. Capture estos registros:
   • Mon-sub/pro traces
   • Logging monitor msid <imsi>

Secuencia de Troubleshooting

1. Identifique la fórmula 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))

Precaución: la fórmula varía en función de la forma en que los clientes miden los KPI.

2. Basándose en la fórmula, hay varios contadores utilizados para calcular ASR, por lo que, a partir de las estadísticas de volumen, debe comprobar la tendencia KPI de cada contador.

3. Tendencia de KPI que debe compararse con plazos no problemáticos y plazos problemáticos.

4. Una vez identificado el contador de bulkstat problemático a partir de la fórmula de KPI, debe comprobar cómo se define este contador en función del flujo e intentar establecer un patrón. 

5. También, recoger las razones de desconexión del nodo con múltiples iteraciones con intervalos de tiempo de 3 a 5 minutos.

Puede encontrar el delta de razones de desconexión de dos SSD recolectados en diferentes marcas de tiempo. La razón de desconexión que aumenta rápidamente a partir de las desconexiones delta se puede atribuir a la causa de la degradación de KPI. Además, la descripción de todas las desconexiones está disponible en la Referencia de estadísticas y contadores de Cisco; 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

Este es un ejemplo de pasos de troubleshooting para abordar un escenario de degradación causado por un aumento en el motivo de desconexión "MME-HSS-User-Unknown". Consulte https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/214633-troubleshoot-4g-asr-kpi-degradation-due.html.

6. Compruebe las estadísticas de egtp según el tipo de nodo.

--- 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. Para analizar y resolver problemas adicionales de la degradación de KPI, capture los seguimientos de llamadas mon-sub/mon pro y considere el uso de herramientas externas para obtener seguimientos de Wireshark. Estos seguimientos ayudan a identificar el flujo de llamadas específico que causa el problema.

Los comandos para capturar sub-seguimientos Mon son los siguientes: 

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. En los casos en los que no sea posible capturar seguimientos como mon-sub debido a un porcentaje mínimo de degradación de KPI, capture los registros de depuración a nivel del sistema. Además, capture los logs de depuración para sessmgr y egptc, y si el problema sospechoso involucra entidades como HSS/RAN, capture los logs de depuración para s1-ap/diámetro según el problema específico.

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. Una vez que obtiene alguna pista de los debuglogs, también puede capturar el archivo de núcleo para ese evento concreto donde ve los logs de errores:

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

Estos son los diversos pasos para resolver este problema.