STP-Überlastung, IMSIMGR-Overstate und SCTP-Link-Flaps im SGSN aufgrund von HLR MAP_RESET

Einleitung

In diesem Dokument wird ein Problem beschrieben, das auf dem SGSN (Serving General Packet Radio Service) des Cisco ASR (Aggregated Services Router der Serie 5000) auftritt. Darüber hinaus werden einige mögliche Problemumgehungen für dieses Problem beschrieben.

Hintergrundinformationen

Diese spezielle Ereigniskette im ASR SGSN wird in diesem Dokument beschrieben:

1. 21.11.2025: Das Home Location Register (HLR) hat eine MAP_RESET gesendet.
   
   
2. 21.11.2013: Für Signalübertragungspunkt 2 (STP-2) wird ein Überlastungsalarm ausgelöst.
   
   
3. 21.11.2023: Für STP-1 und STP-2 wird ein Überlastungsalarm ausgelöst.
   
   
4. 21.11.08:48: Der International Mobile Subscriber Identity Manager (IMSIMGR) wechselt in den Warn-Status.
   
   
5. 21.11.2007: Die Verbindungen werden vom STP-2 zum SGSN zurückgesetzt.
   
   
6. 21. November, 10:15 Uhr: In den Statistiken zur SGSN-Standortaktualisierung (SGSN Location Update, LU) wurden Verbesserungen festgestellt.
   
   
7. 21.11.2010€10“30 Uhr: Die Statistik verbessert sich um 10:00 Uhr.
   
   
8. 21. November, 11:15 : Ein Rückgang ist in den SGSN LU Statistiken zu beobachten.
   
   
9. 21.11.11:41: Das STP-Team berichtet, dass der Signaling Link Code (SLC)-1 von STP-2 keinen Datenverkehr empfängt, der SLC zurückgesetzt wird und der Datenverkehr wieder normal verläuft.
   
   
10. 21.11.11:42: Ein Überlastungsalarm wird auf SGSN für SLC-1 des STP ausgelöst.
    
    
11. 21.11.2012:00: Nachdem SLC-3 zurückgesetzt wurde, verbessern sich die GPRS LU-Statistiken.

Problem

Wenn der HLR die Meldung MAP_RESET empfängt, wird ein Flag für ein GPRS Location Update (GLU) gesetzt. Wenn die Benutzerausrüstung (UE) ihre ersten Uplink-Pakete sendet, sendet das SGSN eine GLU-Nachricht an das HLR.

At  7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers:             2386266
Active:                        2386266
sgsn-pdp-type-ipv4:            942114

 
Wie in der Beispielausgabe gezeigt, sind 950.000 Packer Data Protocol (PDP)-Kontexte auf dem SGSN vorhanden, und die UEs versuchen, sie im Laufe des Tages zu durchsuchen.

Wenn die ersten Uplink-Pakete empfangen werden, löst das SGSN eine GLU-Nachricht aus. Da es Hunderttausende von UEs gibt, kann STP die Menge an generiertem Datenverkehr nicht verarbeiten und wechselt in einen permanenten Überlastungsstatus.

Nachrichten werden beim SGSN in die Warteschlange gestellt, und es tritt ein Timeout für die maximale Neuübertragung auf. Da nicht alle GLU-Nachrichten vom SGSN an das HLR weitergeleitet werden, ist das SGSN gezwungen, die Mobilfunkteilnehmer zu trennen und sie aufzufordern, sich erneut anzuschließen. Alle getrennten Abonnenten versuchen dann, eine Verbindung herzustellen, was zu einem plötzlichen Anstieg der Anzahl eingehender Anhangsanforderungen führt. Da der Schutz vor Netzwerküberlastung angewendet wird, werden die meisten Verbindungsversuche aufgrund von Überlastung abgelehnt, und die Mobilfunkteilnehmer sind gezwungen, einen neuen Versuch zu unternehmen.

Wenn sich diese Kette von Ereignissen entfaltet, erzeugt sie kaskadierende Effekte. Viele SAI-Nachrichten (Send Authentication Information), GLU-Nachrichten und MAP-IMEI_CHECK-Nachrichten bleiben in der SGSN-Warteschlange hängen oder werden verworfen. Aus diesem Grund erreichen alle STP-1- und STP-2-Verbindungen einen Überlastungsstatus. Jeder STP verfügt über vier Signalisierungsverbindungen. In diesem Szenario stellen sich die ersten drei Verbindungen von STP-2 jedoch nicht sehr lange wieder her.

Nachfolgend sind die Überlastungswarnungen aufgeführt, die zeigen, dass alle STP-Verbindungen in den Überlastungsstatus auf STP-2 übergehen:

Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-1 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-2 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-3 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:13:29 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:18:48 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:20:00 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:22:52 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:22:55 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:23:22 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:26:33 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:28:06 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 08:28:45 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1
Fri Nov 21 09:27:27 2014 Internal trap notification 1074 (M3UAPSPCongested)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congested congLevel-1

Wie dargestellt, wurde nur der Peer-Serverprozess (PSP) 4 gelöscht, und die übrigen befinden sich noch im Überlastungsstatus:

Fri Nov 21 08:18:47 2014 Internal trap notification 1075 (M3UAPSPCongestionCleared)
 ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
 congestion cleared congLevel-0

Lösung

In diesem Abschnitt wird beschrieben, wie Sie das im vorherigen Abschnitt beschriebene Problem beheben.

STP-Verbindung empfängt zu viel Datenverkehr

Wie im vorherigen Abschnitt beschrieben, empfängt eine bestimmte Verbindung im STP eine große Menge an Datenverkehr. Sie können sehen, dass die ersten drei Verbindungen in STP-2 in den Überlastungszustand übergehen und sich nie wieder erholen, sodass nur eine Verbindung verfügbar ist und der Überlastungsalarm auf SLC-3 (oder Peer-Server-2-Peer-Server-Prozess-4) gelöscht wird. 

Gemäß dem SGSN Load Sharing-Mechanismus müssen die Pakete des Message Transfer Part (MTP) Level 3 (MTP3) User Adaptation Layer (M3UA) auf allen vier Verbindungen gleichmäßig gesendet werden. Von den SNMP-Traps (Simple Network Message Protocol) aus sind die ersten drei STP-2-Verbindungen jedoch dauerhaft überlastet, was bedeutet, dass der gesamte Datenverkehr an die SLC-3-Verbindung weitergeleitet wird (die einzige verfügbare STP-Verbindung zur Weiterleitung des Datenverkehrs). Dies erklärt, warum die Datenverkehrsverteilung zwischen den STP-2-Verbindungen verzerrt ist.

In Überlastungssituationen werden eine oder mehrere Verbindungen zwischen überlasteten und nicht überlasteten Zuständen hin- und hergeschaltet, sodass der Datenverkehr nur von den verfügbaren Verbindungen gemeinsam genutzt wird. Aus diesem Grund ist in einem der Links eine höhere Auslastung vorhanden. Dies erfordert ein Zurücksetzen der Verbindung, um die Verbindungen wiederherzustellen.

Die nächste Ausgabe zeigt die M3UA-Level- und Abstandsstatistiken. Die wichtigsten zu berücksichtigenden Statistiken sind PSP-Instanz 4 für STP-2, wo anormaler Datenverkehr zu erkennen ist: 

Time   #1:ss7rd-m3ua-psp-data-tx   #2:ss7rd-m3ua-psp-error-tx  #3:ss7rd-m3ua-psp-data-rx
21-11-14 7:30             37409                      0                     37942
21-11-14 8:00             43677                      0                     43866
21-11-14 8:30             190414                     0                     71844
21-11-14 9:00             547418                     0                     104135
21-11-14 9:30             536019                     0                     102477
21-11-14 10:00            376797                     0                     132227
21-11-14 10:30            100394                     0                     97302
21-11-14 11:00            119652                     0                     114809
21-11-14 11:30            107073                     0                     95354

Die STP-Daten:

   DATE             TIME     LSN     LOC  SLC    LINK        TX %     RX %
11/21/2014 9:00 sgsncisco   5216       3   A     IPVL        11.26    62.07
11/21/2014 9:00 sgsncisco   5213       0   A1    IPVL        11.29    4.86
11/21/2014 9:00 sgsncisco   5214       1   A1    IPVL        11.27    4.85
11/21/2014 9:00 sgsncisco   5215       2   A     IPVL        11.23    4.7

Diese Ausgabe zeigt die Abtrennungen pro Sekunde zum Zeitpunkt des Problems:

Time                 #13:2G-ms-init-detach      #14:2G-nw-init-detach

21-11-14 6:30                  136465                 7400
21-11-14 7:00                  149241                 9557
21-11-14 7:30                  165788                 12630
21-11-14 8:00                  179311                 16963
21-11-14 8:30                  125564                 44759
21-11-14 9:00                  112461                 95299
21-11-14 9:30                  240341                 112461
21-11-14 10:00                 288014                 116298
21-11-14 10:30                 203261                 123300
21-11-14 11:00                  67788                 122945

Diese Ausgabe zeigt die Anhänge pro Sekunde gemäß WEM:

Time           #3:2G-total-attach-req-all  Request/Second

21-11-14 8:00         738279                205.078
21-11-14 9:00         14053511              3903.753
21-11-14 10:00        24395071              6776.409
21-11-14 11:00        24663454              6850.959
21-11-14 12:00        17360687              4822.413

IMSIMGR im Warnungszustand

Jede neue Anforderung für das Hinzufügen und Aktualisieren der Routing-Area (RAU) von IMSI/Packet Temporary Mobile Subscriber Identity (P-TMSI) muss vom IMSIMGR verarbeitet werden.

Eine vorsichtige Beobachtung zeigt, dass das System einen Spitzenwert von 6.850 2-G-Attach-Anfragen pro Sekunde und etwa 5.313 3-G-Attach-Anfragen pro Sekunde erhält. Der Höchstwert, den Sie für den Schutz vor Netzwerküberlastung festlegen können, beträgt 5.000 Anhängen pro Sekunde. Um den IMSIMGR im betriebsfähigen Zustand zu halten, kann das System eine so große Anzahl von Anrufen aus den UEs nicht verarbeiten.

Dieses Problem tritt nach 8 Uhr morgens auf, wenn die Warteschlangengröße 1.500 Anforderungen pro Sekunde zum Anhängen erreicht:

network-overload-protection sgsn-new-connections-per-second 500 action
 reject-with-cause congestion queue-size 1500 wait-time 5

Da pro Sekunde ca. 12.000 Attach-Anfragen vorliegen, werden vom IMSIMGR fast 9.000 Anrufe verarbeitet und abgelehnt. Dadurch erreicht die IMSIMGR-CPU-Verarbeitung einen hohen Status.

Empfängt der SGSN mehr als die konfigurierte Anzahl von Attach-Anforderungen pro Sekunde, werden die Anforderungen in der Pacing-Warteschlange gepuffert und nur verworfen, wenn der Puffer aufgrund einer hohen eingehenden Attach-Rate überläuft. Nachrichten in der Warteschlange werden nach einem First-In, First-Out (FIFO)-Prozess verarbeitet, bis sie veraltet sind, wenn die Lebensdauer der Nachrichten in der Warteschlange die konfigurierte Wartezeit überschreitet.

Wenn Sie die Ablehnungs- oder Ablehnungsoptionen basierend auf Ihren Einstellungen auswählen, empfiehlt Cisco, einen Ablehnungsursachencode zu verwenden, um eine Überlastung im Netzwerk anzuzeigen. Dadurch können Sie die Netzwerkbedingungen verstehen, bevor Sie einen Uplink-Vorgang versuchen. 

HLR-Fehler

Gemäß 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.060 beschreibt dieser Abschnitt das SGSN-Verhalten während eines HLR-Neustarts. Wenn der SGSN ein MAP-Reset empfängt, wird erwartet, dass er eine UL-Anfrage an das HLR für seine Teilnehmer sendet.

Wenn ein HLR neu startet, sendet es eine Reset-Nachricht an jedes SGSN, an dem eine oder mehrere seiner Mobilstationen (MS) registriert sind. Dies bewirkt, dass der SGSN die relevanten Mobile Management Kontexte als ungültig markiert, wenn eine Zuordnung von SGSN zu Mobile Switching Center (MSC)/Visiting Location Register (VLR) besteht. Nach Empfang des ersten gültigen Logical Link Control (LLC)-Frames (für A/Gb-Modus) oder nach Empfang des ersten gültigen GPRS Tunneling Protocol User (GPT-U)-Pakets oder der Uplink-Signalisierungsnachricht (für Iu-Modus) von einer markierten Mobilstation führt der SGSN eine URL zum HLR aus, wie bei der Attach-Anfrage oder bei Inter-SGSN Routing Area (RA)-Aktualisierungsverfahren. Wenn das Non-GPRS Alert Flag (NGAF) festgelegt ist, wird das Verfahren in der Non-GPRS Alert-Klausel befolgt. Die UL-Prozedur und die Prozedur in Richtung MSC/VLR können durch das SGSN für eine maximale Operatorkonfiguration verzögert werden, je nachdem, welche Ressourcen zu diesem Zeitpunkt verwendet werden, um eine hohe Signalisierungslast zu vermeiden.

Anmerkung: Die regelmäßige Sicherung der HLR-Daten auf nichtflüchtigem Speicher ist zwingend erforderlich, wie in TS 23.007 [5] beschrieben.

Empfehlungen

Cisco empfiehlt zur Behebung dieses Problems die folgenden Schritte:

1. Die Anzahl neuer Verbindungen pro Sekunde erhöhen. Dieser Wert kann anhand der durchschnittlichen Anzahl von Attach-Anforderungen berechnet werden.
   
   
2. Erhöhen Sie die Anzahl der Transaktionen pro Sekunde (TPS) in der STP-Verbindung auf einen idealen Wert.
   
   
3. Ändern Sie den SCTP-RTO-MAX-Standardwert von 600 (600*100 = 60.000) in 5 (5*100 ms). Beispielsweise können Sie für zwei STPs mit 4.000 TPS bis zu 1.000 Attach-Anfragen pro Sekunde vom SGSN unterstützen.

Hinweis: Jede Attach-Anfrage führt zu vier Transaktionen mit STP. Das bedeutet, dass 1.000 Attach-Anfragen pro Sekunde 4.000 TPS ergeben.

Im Idealfall verfügt jeder STP über vier Verbindungen, sodass pro STP-Verbindung 125 Attach-Requests verarbeitet werden können. Diese wird gleichmäßig auf alle STP-Verbindungen verteilt. Wenn jedoch einer der Links ausfällt, werden viele Verbindungsversuche erkannt, die Warteschlange wird voll, und das Paket wird verworfen. Wenn mehr Verbindungen ausfallen, ist der Datenverkehr ungleichmäßig verteilt.

Datenverkehrsfluss

Der EU-Datenverkehr verläuft nicht linear. Sie tritt in der Regel in einem Burst und mit vielen Wiederverbindungsversuchen auf. Das SGSN sendet Datenverkehr in Paketen an STP. Zu diesem Zeitpunkt überschreitet der Datenverkehr die auf dem STP konfigurierten TPS-Werte. Dies führt dazu, dass einige Links im STP eine niedrige Fenstergröße ankündigen, wenn sie bereits mehr Anrufe verarbeiten, und das SGSN beginnt, die SCTP-Datenblöcke, die in die Warteschlange gestellt werden, in eine Warteschlange zu stellen. Anschließend wird gewartet, bis der RTO-MAX-Timer abläuft.

Wenn der STP regelmäßig eine gute angekündigte Fenstergröße sendet, sollten Sie in der Lage sein, mehr SCTP-Datenblöcke zu senden, wenn der SCTP_RTO_MAX-Wert auf maximal fünf Sekunden reduziert wird. Die Warteschlange wird schneller gelöscht, und es wird kein M3UA-Überlastungsalarm ausgelöst. Außerdem sollte das vom SCTP ausgelöste Flag für die interne Flusskontrolle nicht angezeigt werden, um den Paketfluss zu steuern.

Das SGSN sendet Pakete nur in der vom STP akzeptierten Menge, die auf der angegebenen Fenstergröße basiert. Wenn Sie die TPS pro STP-Verbindung erhöhen, können Sie eine STP-Überlastung vermeiden und den SCTP_RTO_MAX-Timer reduzieren.

Auslöser für überlasteten M3UA-Alarm in SGSN

Wenn die angegebene Fenstergröße in der SCTP-SACK-Nachricht (Stream Control Transmission Protocol) nahe Null (oder Null) liegt, löst der SGSN einen M3UA-Alarm aus, um anzugeben, dass für diesen Peer-Endpunkt keine Nachrichten gesendet werden sollen. Dies führt dazu, dass die Verbindung ein Flapping durchführt oder in einen überlasteten Zustand übergeht. Da das SGSN eine höhere Fenstergröße sendet, erhalten Sie weiterhin M3UA-Daten von den Peer-Knoten. Diese Pakete werden möglicherweise in die Warteschlange gesetzt, wenn der Peer-Point-Code nie aus dem überlasteten Zustand kommt.

Hier ein Beispiel:

1. Das SCTP sendet eine Startanzeige für die Flusssteuerung an das M3UA.
   
   
2. Der M3UA setzt das aktive Überlastungsflag für die Zuordnung und beginnt, das SCTP regelmäßig nach seinem Flusssteuerungsstatus abzufragen.
   
   
3. Während sich eine Zuordnung in der Flusssteuerung befindet, werden künftige Datenanforderungen für diese Zuordnung in die Warteschlange gestellt, bis QUEUE_SIZE 8.000 erreicht hat. An diesem Punkt werden zukünftige Nachrichten für die Zuordnung verworfen.
   
   
4. Wenn der STP eine korrekte angekündigte Fenstergröße sendet, versucht der M3UA, die Nachrichten zu leeren, die in die Warteschlange gestellt werden, bis er 5.000 erreicht. Auch der RTO-Timer spielt dabei eine Rolle.

Die SCTP-Nachrichten werden nur für die Zuordnungen in die Warteschlange gestellt, bei denen das Flag für die Flusssteuerung auf True gesetzt wird und der SGSN dann entsprechend der STP-Antwort verarbeitet wird:

*Peer Server Id :        2   Peer Server Process Id:        2 
 
 Association State : ESTABLISHED
 
 Flow Control Flag                       :                TRUE 
 Peer INIT Tag                           :                20229
 SGSN INIT Tag                           :           3315914061
 Next TSN to Assign to                          
 Outgoing Data Chunk                   :           3418060778
 Lowest cumulative TSN acknowledged      :           3418060634
 Cumulative Peer TSN arrived from peer   :            103253660
 Last Peer TSN sent in the SACK          :            103253658
 Self RWND                               :              1048576
 Advertised RWND in received SACK        :                    8
 Peer RWND(estimated)                    :                    8
 Retransmission counter                  :                    0
 Zero Window Probing Flag                :                FALSE
 Last Tsn received during ZWnd Probing   :                    0
 Bytes outstanding on all                       
 addresses of this association        :                19480
 Congestion Queue Length                 :                  143
  Ordered TSN assignment Waiting QLen     :                 8050 
 Unordered TSN assignment Waiting QLen   :                    0
 Total number of GAP ACKs Transmitted    :                  279
 Total number of GAP ACKs Received       :                58787
 
 
 Path No.                                :                    1
 
 Current CWND                            :                11840
 SSThresh                                :                11840
 Partial Bytes Acked                     :                    0
 Bytes Outstanding for this Path         :                19480
 Current RTO for this Path(in ms)        :                60000

Wie dargestellt, liegt der Grund für die Überlastung darin, dass die Gesamtzahl ausgehender Chunks die Grenze von 5.000 überschreitet (8050+143=8193) und den maximalen RTO-Timer von 60 Sekunden erreicht, was zu verworfenen SCTP-Datenanforderungen führt. Außerdem gibt es einen höheren RTO-Timer.