Fehlerbehebung bei verminderten Leistungskennzahlen - 4G ASR

Einleitung

In diesem Dokument wird die Fehlerbehebung bei einer Verschlechterung der Leistungskennzahlen (Key Performance Indicators, KPIs) für 4G Attach Success Rate (ASR) beschrieben.

Mögliche Szenarien

Eine Verschlechterung der 4G-ASR kann auf mehrere Faktoren zurückzuführen sein: 

1. Netzwerkprobleme
2. Anrufflussspezifisches Problem
3. Knotenspezifische Probleme
4. Konfigurationsprobleme
5. RAN-Endprobleme

Für die erste Analyse erforderliche Protokolle

1. KPI-Trenddiagramme zur Hervorhebung des Abbaus.
2. Für die Messung verwendete KPI-Formel.
3. Rohbulkstat-Zähler und Ursachencodetrends seit Beginn des Problems.
4. Zwei Instanzen von Show Support Details (SSD), die in einem 30-Minuten-Intervall während der problematischen Zeit erfasst wurden.
5. Syslogs sammelten sich zwei Stunden vor dem Abbau bis zur aktuellen Zeit.
6. Diese Protokolle erfassen:
   • Mon-sub/pro traces
   • Logging monitor msid <imsi>

Reihenfolge der Fehlerbehebung

1. Geben Sie die ASR-Formel an:

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

Vorsicht: Die Formel hängt von der Methode des Kunden zur Messung der Leistungskennzahlen ab.

2. Basierend auf der Formel gibt es mehrere Zähler, die zur Berechnung der ASR verwendet werden. Aus den Statistiken müssen Sie daher den KPI-Trend jedes Zählers überprüfen.

3. KPI-Trend mit unproblematischen und problematischen Zeitachsen zu vergleichen.

4. Nachdem der problematische Bulkstatzähler aus der KPI-Formel identifiziert wurde, müssen Sie überprüfen, wie dieser Zähler basierend auf dem Datenfluss definiert ist, und versuchen, ein Muster zu erstellen. 

5. Sammeln Sie auch die Gründe für die Trennung vom Knoten mit mehreren Iterationen mit Zeitintervallen von 3 bis 5 Minuten.

Sie können das Delta der Gründe für die Trennung von zwei SSDs finden, die unter verschiedenen Zeitstempeln gesammelt wurden. Der Grund für die Abkopplung, der durch die Delta-Abkopplung rasch zunimmt, kann auf die Ursache der KPI-Verschlechterung zurückgeführt werden. Eine Beschreibung aller Verbindungsunterbrechungen finden Sie in der Statistik- und Zählerreferenz von Cisco unter 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

Im Folgenden finden Sie ein Beispiel für Schritte zur Fehlerbehebung, mit denen ein Szenario behoben werden soll, das durch eine Erhöhung des Trennungsgrunds "MME-HSS-User-Unknown" verursacht wurde. Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/214633-troubleshoot-4g-asr-kpi-degradation-due.html.

6. Überprüfen Sie die egtp-Statistiken basierend auf dem Knotentyp.

--- 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. Erfassen Sie zur weiteren Analyse und Fehlerbehebung der Leistungskennzahlen mon-sub/mon pro call traces, und ziehen Sie die Verwendung externer Tools in Betracht, um Wireshark traces zu erhalten. Diese Ablaufverfolgungen helfen dabei, den spezifischen Anruffluss zu identifizieren, der das Problem verursacht.

Die Befehle zum Erfassen von Mon-Subtraces sind wie folgt: 

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. In Fällen, in denen die Erfassung von Ablaufverfolgungen wie mon-sub aufgrund eines minimalen Prozentsatzes der KPI-Degradation nicht möglich ist, sollten Debug-Protokolle auf Systemebene erfasst werden. Erfassen Sie außerdem Debug-Protokolle für sessmgr und egptc. Wenn das vermutete Problem Entitäten wie HSS/RAN betrifft, erfassen Sie je nach Problem Debug-Protokolle für s1-ap/ameter.

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. Sobald Sie Hinweise aus den Debug-Protokollen erhalten, können Sie auch eine Kerndatei für dieses spezielle Ereignis erfassen, in dem Fehlerprotokolle angezeigt werden:

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

Dies sind die verschiedenen Schritte zur Behebung dieses Problems.