Inhalt

Einleitung

Mögliche Szenarien

Für die erste Analyse erforderliche Protokolle

Reihenfolge der Fehlerbehebung

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.