Sommario

Introduzione

Scenari possibili

Registri necessari per l'analisi iniziale

Sequenza di risoluzione dei problemi

Introduzione

In questo documento viene descritto come risolvere i problemi relativi alla riduzione di prestazioni degli indicatori KPI (Key Performance Indicator) ASR (Attach Success Rate) 4G.

Scenari possibili

La degradazione dell'ASR 4G può essere causata da più fattori:

1. Problemi di rete

2. Chiama problema specifico del flusso

3. Problemi specifici del nodo

4. Problemi di configurazione

5. Problemi finali RAN

Registri necessari per l'analisi iniziale

1. Grafici di tendenza degli indicatori KPI che evidenziano la degradazione.

2. Formula KPI utilizzata per la misurazione.

3. Contatori di bulkstat non elaborati e causare le tendenze del codice da quando il problema è iniziato.

4. Due istanze di Mostra dettagli supporto (SSD) acquisite a un intervallo di 30 minuti durante il tempo in cui si è verificato il problema.

5. Syslog raccolti da due ore prima della degradazione fino all'ora corrente.

6. Acquisisci questi registri:

- Mon-sub/pro traces

- Logging monitor msid <imsi>

Sequenza di risoluzione dei problemi

1. Identificare la formula del rapporto di risposta automatico:

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))

Attenzione: la formula varia in base al modo in cui i clienti misurano gli indicatori KPI.

2. In base alla formula, ci sono più contatori utilizzati per calcolare ASR, quindi dai bulkstats, è necessario controllare la tendenza KPI di ogni contatore.

3. Andamento degli indicatori chiave di prestazione da confrontare con scadenze non problematiche e scadenze problematiche.

4. Una volta identificato il contatore bulkstat problematico dalla formula KPI, è necessario controllare come questo contatore è definito in base al flusso e provare a stabilire un modello.

5. Inoltre, raccogliere i motivi di disconnessione dal nodo con più iterazioni con intervalli di tempo da 3 a 5 minuti.

È possibile trovare il delta dei motivi di disconnessione da due unità SSD raccolte con timestamp diversi. Il motivo di disconnessione che aumenta rapidamente a causa delle disconnessioni delta può essere attribuito alla causa del degrado degli indicatori KPI. Inoltre, la descrizione di tutte le disconnessioni è disponibile in Cisco's 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

Di seguito è riportato un esempio di procedura di risoluzione dei problemi per risolvere uno scenario di peggioramento causato da un aumento del motivo di disconnessione "MME-HSS-User-Unknown". Fare riferimento a https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/214633-troubleshoot-4g-asr-kpi-degradation-due.html.

6. Controllare le statistiche egtp in base al tipo di 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. Per analizzare ulteriormente e risolvere i problemi relativi al degrado degli indicatori KPI, catturare tracce di chiamate mon-sub/mon pro e utilizzare strumenti esterni per ottenere tracce di Wireshark. Queste tracce consentono di identificare il flusso di chiamata specifico che causa il problema.

Di seguito sono riportati i comandi per acquisire le sottotracce 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. Nei casi in cui non è possibile catturare tracce come mon-sub a causa di una percentuale minima di degradazione degli KPI, acquisire i log di debug a livello di sistema. Inoltre, acquisire i log di debug per sessmgr ed egptc e, se il problema sospetto coinvolge entità quali HSS/RAN, acquisire i log di debug per s1-ap/diametro in base al problema specifico.

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 volta ottenuto qualsiasi suggerimento dai log di debug, è possibile acquisire anche il corefile per quell'evento particolare in cui vengono visualizzati i log degli errori:

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

Di seguito sono riportati i vari passaggi per risolvere il problema.