Dépannage de la dégradation des indicateurs de performance clés - ASR 4G

Introduction

Ce document décrit comment dépanner la dégradation des indicateurs de performance clés (KPI) du taux de réussite de l'attachement 4G (ASR).

Scénarios possibles

La dégradation de la technologie ASR 4G peut être due à plusieurs facteurs : 

1. Problèmes de réseau
2. Problème spécifique au flux d'appels
3. Problèmes spécifiques au noeud
4. Problèmes liés à la configuration
5. Problèmes de fin RAN

Journaux requis pour l'analyse initiale

1. Graphiques de tendance ICP soulignant la dégradation.
2. Formule ICP utilisée pour la mesure.
3. Compteurs Bulkstat bruts et tendances de cause de code depuis le début du problème.
4. Deux instances de Show Support Details (SSD) capturées à un intervalle de 30 minutes pendant le temps problématique.
5. Syslogs collectés de deux heures avant la dégradation jusqu'à l'heure actuelle.
6. Capturez ces journaux :
   • Mon-sub/pro traces
   • Logging monitor msid <imsi>

Séquence de dépannage

1. Identifiez la formule 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))

Attention : la formule varie en fonction de la façon dont le client mesure les IPC.

2. Sur la base de la formule, plusieurs compteurs sont utilisés pour calculer le taux de remise standard. Par conséquent, à partir des statistiques par lots, vous devez vérifier la tendance des indicateurs de performance clés de chaque compteur.

3. Tendance des IPC à comparer avec des délais non problématiques et des délais problématiques.

4. Une fois que le compteur Bulkstat problématique est identifié à partir de la formule d'indicateur, vous devez vérifier comment ce compteur est défini en fonction du flux et essayer d'établir un modèle. 

5. Recueillez également les raisons de déconnexion du noeud avec plusieurs itérations avec des intervalles de temps de 3 à 5 minutes.

Vous pouvez trouver le delta des raisons de déconnexion de deux SSD collectés à des horodatages différents. La raison de la déconnexion qui augmente rapidement à partir des déconnexions delta peut être attribuée à la cause de la dégradation de l'indicateur de performance clé. En outre, la description de toutes les déconnexions est disponible dans le document de référence de Cisco relatif aux statistiques et aux compteurs, à l'adresse suivante : 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

Voici un exemple d'étapes de dépannage pour résoudre un scénario de dégradation causé par une augmentation du motif de déconnexion « MME-HSS-User-Unknown ». Reportez-vous à la page https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/214633-troubleshoot-4g-asr-kpi-degradation-due.html.

6. Vérifiez les statistiques egtp en fonction du type de noeud.

--- 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. Pour analyser et dépanner la dégradation de l’indicateur de performance clé, capturez les traces d’appels mon-sub/mon pro et envisagez d’utiliser des outils externes pour obtenir des traces Wireshark. Ces suivis permettent d'identifier le flux d'appels spécifique à l'origine du problème.

Les commandes permettant de capturer les sous-traces Mon sont les suivantes : 

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. Dans les cas où la capture de traces comme mon-sub n'est pas possible en raison d'un pourcentage minimal de dégradation de l'indicateur de performance clé, capturez les journaux de débogage au niveau du système. En outre, capturez les journaux de débogage pour sessmgr et egptc, et si le problème suspecté implique des entités telles que HSS/RAN, capturez les journaux de débogage pour s1-ap/diameter en fonction du problème spécifique.

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. Une fois que vous obtenez un indice à partir des débogages, vous pouvez également capturer le fichier de base pour cet événement particulier où vous voyez les journaux d'erreurs :

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

Voici les différentes étapes à suivre pour résoudre ce problème.