Solucionar problemas de degradação de KPI - ASR 4G

Introdução

Este documento descreve como solucionar problemas de degradação de KPIs (Key Performance Indicators, indicadores chave de desempenho) de taxa de êxito de conexão 4G (ASR).

Possíveis cenários

A degradação do 4G ASR pode ser causada por vários fatores: 

1. Problemas de rede
2. Problema Específico do Fluxo de Chamadas
3. Problemas específicos do nó
4. Problemas de configuração
5. Problemas de fim de RAN

Logs necessários para a análise inicial

1. Gráficos de tendência de KPI que destacam a degradação.
2. Fórmula de KPI usada para medição.
3. Contadores bulkstat brutos e tendências de código de causa desde o início do problema.
4. Duas instâncias de Mostrar Detalhes de Suporte (SSD) capturadas em um intervalo de 30 minutos durante o momento problemático.
5. Syslogs coletados de duas horas antes da degradação até o momento atual.
6. Capturar estes logs:
   • Mon-sub/pro traces
   • Logging monitor msid <imsi>

Sequência de Troubleshooting

1. Identifique a 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))

Cuidado: a fórmula varia de acordo com a forma que os Clientes usam para medir os KPIs.

2. Com base na fórmula, há vários contadores usados para calcular o ASR, portanto, a partir do bulkstats, é necessário verificar a tendência de KPI de cada contador.

3. Tendência dos ICD a comparar com prazos não problemáticos e prazos problemáticos.

4. Uma vez que o contador bulkstat problemático é identificado a partir da fórmula de KPI, você precisa verificar como esse contador é definido com base no fluxo e tentar estabelecer um padrão. 

5. Além disso, colete os motivos de desconexão do nó com várias iterações com intervalos de tempo de 3 a 5 minutos.

Você pode encontrar o delta de razões de desconexão de dois SSDs coletados em carimbos de data/hora diferentes. O motivo da desconexão que aumenta rapidamente a partir das desconexões delta pode ser atribuído à causa da degradação do KPI. Além disso, a descrição de todas as desconexões está disponível na Referência de estatísticas e contadores da 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 é um exemplo de etapas de Troubleshooting para resolver um cenário de degradação causado por um aumento no Motivo da Desconexão "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. Verifique as estatísticas de egtp com base no tipo de nó.

--- 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 analisar e solucionar problemas da degradação do KPI, capture os rastreamentos de chamada mon-sub/mon pro e considere o uso de ferramentas externas para obter rastreamentos do Wireshark. Esses rastreamentos ajudam a identificar o fluxo de chamadas específico que causa o problema.

Os comandos para capturar sub-rastreamentos Mon são os seguintes: 

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. Nos casos em que a captura de rastreamentos como mon-sub não for possível devido a uma porcentagem mínima de degradação de KPI, capture os logs de depuração do sistema. Além disso, capture logs de depuração para o sessmgr e o egptc e, se o problema suspeito envolver entidades como HSS/RAN, capture logs de depuração para s1-ap/diâmetro com base no 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. Depois de obter qualquer pista dos logs de depuração, você também poderá capturar o arquivo do núcleo para esse evento específico, onde você verá os logs de erro:

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

Estas são as várias etapas para solucionar esse problema.