Konfiguration und Fehlerbehebung für die Funktion "Dynamische Paging-Steuerung - kritisches Paging"

Einleitung

In diesem Dokument werden die Paging-Logik und Verbesserungen beschrieben, die das Paging bei einer Überlastung der MME-CPU optimieren und so Netzwerkstabilität und Kontinuität gewährleisten.

Problembeschreibung

Paging-Sturm-Auswirkungen auf MME-Ressourcen aufgrund eines eNB/RAN-Ausfalls

In großen mobilen Netzwerken ist das Paging-Verfahren entscheidend, um ungenutzte Benutzergeräte (User Equipment, UEs) zu finden, wenn Downlink-Daten vorhanden sind. Dieses Verfahren umfasst mehrere Paging-Phasen und eine Fallback-Logik, die sich unter bestimmten Fehlerbedingungen über das Netzwerk erstreckt.

Ein schwerwiegendes Problem ist auf einen kritischen Fehler auf der Ebene des erweiterten Node B (eNB)/Funkzugangsnetzwerks (RAN) zurückzuführen, bei dem alle Paging-Versuche während der Paging-Phase 1 fehlschlugen. Nach dem Standard-Fallback-Mechanismus wurden diese Paging-Fehler zu Paging-Phase 2, dann zu Paging-Phase 3 eskaliert und führten schließlich zu gleichzeitigen Paging-Versuchen bei Paging-Phase 4.

Netzwerkbetreiber konfigurieren das Paging in der Regel in Stufe 3 und Stufe 4 mit WAN-Logik und lösen das Paging für alle eNBs oder alle TAIs (Tracking Area Identities) aus. In Szenarien, in denen das Control Plane Virtual Machine (CPVM) neu geladen wird (aufgrund eines EGTPC-Pfadfehlers (Evolved GPRS Tunneling Protocol Control)) oder RAN nicht reagiert, führt die Fallback-Logik zu Massen-Paging im gesamten Netzwerk.

Auswirkungen

• Dieser Paging-Sturm führt zu einer unerwarteten Flut von Paging-Nachrichten und Anforderungen zum erneuten Anhängen, wodurch der MME-Manager (Mobility Management Entity) immens belastet wird.
• Es wird eine hohe CPU- und Speichernutzung beobachtet, die das System häufig in einen Überlastungs- oder Warnzustand versetzt.
• Unter diesen Belastungsbedingungen wechselt der MME-Manager (die MME-Komponente, die das Paging verarbeitet) in den "Besetzt-Aus"-Zustand, wodurch neue Verbindungen oder Sitzungen abgelehnt werden, was zu vorübergehenden Kapazitätsabstufungen und Service-Beeinträchtigungen führt.

Wichtigste Punkte für Netzwerkbetreiber

Dieser Fall unterstreicht die Bedeutung von:

• Implementierung von Mechanismen zur Geschwindigkeitssteuerung und -drosselung für das Paging.
• Überwachung auf frühe Indikatoren wie CPVM-Neuladevorgänge, RAN-Paging-Reaktionszeiten und Paging-Wiederholungsmuster, um die Last präventiv zu verwalten.

Grafische Darstellung der Auswirkungen

Hierbei wird davon ausgegangen, dass das Paging-Profil von den Paging-Phasen 1, 2, 3 und 4 konfiguriert wurde.

Diese Diagramme stellen die gesamten Paging-Versuche und -Fehler für die verschiedenen Paging-Phasen dar.

MME Paging-Profil Phase1 Versuch

Fehler bei MME-Paging-Profil Phase 1

Fehler bei MME-Paging-Profil Phase 2

MME-Paging-Profil Phase3-Versuch

MME-Paging-Profil Phase4-Versuch

MME Manager CPU-Auslastungsdiagramm

MME Manager CPU-Auslastungsdiagramm

MME Manager-Speicherauslastung - Protokolle:

2024-01-11T22:18:10.575996+09:00 UHNxxxmmvm0001 evlogd: [local-60sec10.022] UHN3tte2mmvm0001 [resmgr 14508 error] [17/0/10121 <rmmgr:170> _resource_cpu.c:4421] [software internal system critical-info syslog] The task mmemgr-8 is way over its memory limit! Allocated 409600K, Using 624696K

2024-01-11T22:18:10.069772+09:00 UHN3xxxmmvm0001 evlogd: [local-60sec9.695] UHN3tte2mmvm0001 [resmgr 14508 error] [8/0/10120 <rmmgr:80> _resource_cpu.c:4421] [software internal system critical-info syslog] The task mmemgr-6 is way over its memory limit! Allocated 409600K, Using 584680K

2024-01-11T22:18:09.998162+09:00 UHN3xxxmmvm0001 evlogd: [local-60sec9.634] UHN3tte2mmvm0001 [resmgr 14508 error] [10/0/10132 <rmmgr:100> _resource_cpu.c:4421] [software internal system critical-info syslog] The task mmemgr-2 is way over its memory limit! Allocated 409600K, Using 543404K

Konfigurationsbeispiel

paging-profile paging-ps

paging-stage 1 match-criteria ue-contact-time 1200 action last-n-enb-last-tai max-n-enb 1 t3413-timeout 2 max-paging-attempts 1.        

paging-stage 2 match-criteria all action last-n-enb-last-tai max-n-enb 5 t3413-timeout 2 max-paging-attempts 1

paging-stage 3 match-criteria all action all-enb-last-tai t3413-timeout 2 max-paging-attempts 1

paging-stage 4 match-criteria all action all-enb-all-tai t3413-timeout 3 max-paging-attempts 1

Wie wird Paging in MME verwaltet?

Funktionslogik

Es ist wichtig, die allgemeine Paging-Logik zu verstehen, insbesondere, wenn es um außergewöhnliche Bedingungen in kritischen Paging-Szenarien geht. Wie beschrieben, verarbeiten Session Manager den Paging-Cache und verwalten die Zuordnung zwischen TAIs und MME-Managern. Diese Zuordnung wird nach jedem erfolgreichen Paging-Versuch/jeder erfolgreichen Paging-Antwort aktualisiert, bleibt aber bei einem Paging-Fehler unverändert. Beim ersten Paging-Versuch sendet der Session-Manager die Paging-Anforderung an alle MME-Manager und verwendet die Antworten, um den Paging-Cache zu erstellen und die TAI-MME-Manager-Zuordnung festzulegen.

Paging-Nachrichtenfluss

Erstellen des Cache

Wenn der Sessmgr eine Paging-Verbindung mit der UE herstellen möchte, überprüft er, ob die Cache-Informationen für alle TACs vorhanden sind, die paging ausgeführt werden müssen. Wenn ja, und die Validitätsprüfung des Cache-Eintrags besteht, sendet Sessmgr eine Unicast-/Multicast-Paging-Anforderung an den entsprechenden MMEMgr. Wenn nein, sendet Sessmgr die Paging-Anforderung an alle MMEMgrs. Als Antwort muss MMEMgr die TACs in der Paging-Anfrage angeben, die er bedient, damit der Sessmgr den Cache erstellt.

Gültigkeit des Caches

Jeder Cacheeintrag enthält einen Ursprungszeitstempel. Wenn auf den Cache zugegriffen wird, wird dieser anhand des Erstellungs-Zeitstempels und des konfigurierten Timeouts für die Cachegültigkeit validiert. Wenn das Timeout abgelaufen ist, darf der Eintrag nicht verwendet werden. Der gesamte Cache muss gelöscht werden, wenn alle MME-Dienste beendet werden.

Lösung

Funktionsweise der Paging-Funktion automatisch deaktivieren

Wie bereits erwähnt, wird nur die Paging-Phase ausgelöst, die unter der Konfiguration für kritisches Paging konfiguriert ist. Dies ist jedoch nicht der Fall, und es zeigt sich, dass bei dieser Funktion eine Abhängigkeit vom Paging-Cache besteht. Wenn also bereits eine bestimmte TAI-MME-Manager-Zuordnung unter dem Sessmgr-Paging-Cache verfügbar ist, verwendet kritisches Paging den Paging-Trigger nur für die konfigurierten Paging-Phasen. Falls jedoch keine TAI-MMEMgr-Zuordnung für eine bestimmte TAI verfügbar ist, können auch auf nachfolgenden Paging-Phasen Versuche erkannt werden, auch wenn diese nicht unter Paging-Phasen konfiguriert sind. Sobald die Zuordnung unter dem Paging-Cache erstellt wird, findet die normale Logik des kritischen Paging statt.

Konfiguration

mme-manager

    congestion-control cpu-utilization threshold 90 tolerance 10

  #exit




Configuration: critical paging need to configure under paging-profile to allow the configured paging stages while skip the unconfigured paging stages.




configure 

   lte-policy 

      paging-profile paging_profile_name 

         [ no ] critical paging_stage 

         end 

Konfigurationsbeispiel

paging-profile paging-ps

      paging-stage 1 match-criteria ue-contact-time 1200 action last-n-enb-last-tai max-n-enb 1 t3413-timeout 2 max-paging-attempts 1      

      paging-stage 2 match-criteria all action last-n-enb-last-tai max-n-enb 5 t3413-timeout 2 max-paging-attempts 1      

      paging-stage 3 match-criteria all action all-enb-last-tai t3413-timeout 2 max-paging-attempts 1      

      paging-stage 4 match-criteria all action all-enb-all-tai t3413-timeout 3 max-paging-attempts 1

critical 1 2

Hier wird die Paging-Stufe 1 und 2 immer dann ausgelöst, wenn Bedingungen für kritisches Paging auftreten. Wenn die Paging-Versuche in Phase 1 und 2 fehlschlagen, werden entsprechend der Paging-Logik die Versuche in der nächsten Paging-Phase ausgelöst. In diesem Szenario handelt es sich um die Paging-Schritte 3 und 4. Wenn jedoch kritisches Paging konfiguriert ist, wird nach dem Paging-Schritt 2 kein weiteres Paging versucht. Es gibt jedoch außergewöhnliche Bedingungen, unter denen Paging-Versuche für nicht konfigurierte Paging-Phasen ebenfalls zu sehen sind. Weitere Informationen finden Sie im Abschnitt "Critical Paging Exceptional Condition" (Kritischer Paging-Ausnahmezustand).

Kritischer Paging-Ausnahmezustand

Wie bereits erwähnt, wird nur die Paging-Phase ausgelöst, die unter "Kritisches Paging" konfiguriert ist. Dies ist jedoch nicht der Fall, und es zeigt sich, dass in dieser Funktion eine Abhängigkeit vom Paging-Cache besteht. Wenn also bereits eine bestimmte TAI-MME-Manager-Zuordnung unter dem Sessmgr-Paging-Cache verfügbar ist, verwendet kritisches Paging den Paging-Trigger nur für die konfigurierten Paging-Phasen. Falls jedoch keine TAI-MMEMgr-Zuordnung für eine bestimmte TAI verfügbar ist, können auch auf nachfolgenden Paging-Phasen Versuche erkannt werden, auch wenn diese nicht unter Paging-Phasen konfiguriert sind. Sobald sich die Zuordnung unter dem Paging-Cache aufbaut, wird wieder die normale Logik des kritischen Pagings verwendet.

Funktionstests

Wie bereits erwähnt, werden Paging-Phase 1 und 2 unter Paging-Profil-Paging-ps konfiguriert. Falls das Paging auf Stufe 1 und 2 fehlschlägt, wurden andere Paging-Versuche auf den anderen Paging-Stufen 3 und 4 übersprungen. Sie können jedoch sehen, dass nur wenige Versuche unternommen werden. Dies liegt an den unter "Critical Paging Exceptional Condition" definierten Bedingungen.