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:
- Problemi di rete
- Chiama problema specifico del flusso
- Problemi specifici del nodo
- Problemi di configurazione
- Problemi finali RAN
Registri necessari per l'analisi iniziale
- Grafici di tendenza degli indicatori KPI che evidenziano la degradazione.
- Formula KPI utilizzata per la misurazione.
- Contatori di bulkstat non elaborati e causare le tendenze del codice da quando il problema è iniziato.
- Due istanze di Mostra dettagli supporto (SSD) acquisite a un intervallo di 30 minuti durante il tempo in cui si è verificato il problema.
- Syslog raccolti da due ore prima della degradazione fino all'ora corrente.
- 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.