GGSN-Verhalten bei PDP-Aktivierungsfehlern und keine GTP-Echo-Antworten

Einführung

In diesem Dokument wird das Verhalten des GGSN (Gateway General Packet Radio Service) (GPRS) Supporting Node (GGSN) beschrieben, wenn der SGSN (Serving GPRS Supporting Node) nicht auf die GPRS Tunneling Protocol (GTP)-Echoanfrage reagiert, die vom GGSN gesendet wird.

Hintergrundinformationen

Es kann vorkommen, dass die Aktivierung des Packet Data Protocol (PDP) im GGSN während eines Zeitraums fehlschlägt, in dem der SGSN nicht auf die GTP-Echo-Anfragen reagiert. Hier einige Fragen, die sich in diesem Szenario stellen könnten:

1. Werden die Anfragen zum Erstellen von PDP oder Aktualisieren von PDP vom SGSN im GGSN eintreffen?
   
   
2. Wenn die GTP-Echo-Anfragen vom GSN zum SGSN fehlschlagen, wie sollte sich das GGSN verhalten, wenn der Update PDP-Kontext, der vom GGSN gesendet wird, keine Antwort erhält?
   
   
3. Wie schlägt ein GGSN einen PDP fehl, wenn er keine GTP-Echo-Antwort oder keine Antwort für die Nicht-Echo-Anforderungsnachrichten erhält, die von einem SGSN für diesen PDP eintreffen?
   
   
4. Wie wirkt sich ein Mangel an GTP-Echo-/Nicht-Echo-Antworten direkt auf die PDP-Aktivierungsfehler aus?

GGSN-Verhalten

Wenn die Nachrichten nicht beim GGSN eintreffen, löst das SGSN einen Pfadfehler-Alarm aus und lässt sie leise fallen. Wenn für die vom GGSN initiierte Echoanfrage keine Echo-Antwort empfangen wurde, bedeutet dies, dass der Peer ausgefallen ist. Daher löscht das GGSN lokal die Anrufe, die mit diesem Peer zusammenhängen.

In der Befehlsausgabe show support details oder in der Ausgabe des Befehls show gtpc statistics ausführliche Befehlsausgabe können Sie die GSN Req Timeout-Zähler anzeigen:

#show gtpc statistics verbose 

SGSN Restart:                       Timeout:
    Create PDP Req:                 5   GTPC Echo Timeout:          149160
    Update PDP Req:                 0   GTPU Echo Timeout:               0
    Echo Response:                312   GGSN Req Timeout:            24182

Path Management Messages:
  Echo Request RX:         34006780   Echo Response TX:         34006780
  Echo Request TX:         29603851   Echo Response RX:         29537123

Wenn Sie die Echo-Anforderungsnachrichten untersuchen, die vom GGSN an den SGSN übertragen werden, wird angezeigt, dass der GGSN die Echo-Antworten nicht empfängt. Sie müssen sicherstellen, dass die Nachrichten nicht aufgrund von Routing-Problemen im Netzwerk verworfen werden oder dass das SGSN nicht verfügbar ist.

Das häufigste Problem sind die Fehler bei der Steuerung von Pfaden, die dazu führen, dass eine große Anzahl der Roaming-SGSNs nicht erreichbar ist.

Wenn eine GTP-Kontrollnachricht (z. B. eine Update-PDP-Kontextanforderung) vom GGSN vorhanden ist, die nach Erschöpfung aller Versuche keine Antwort erhält, hält der GGSN den Peer für nicht erreichbar und löscht nur diese Sitzung als Path Failure aus. Der PDP-Kontext wird im GGSN gelöscht, das SGSN wird jedoch nicht benachrichtigt. Diese Zahl wird mit den folgenden Statistiken ermittelt:

SGSN Restart:                       Timeout:
    Create PDP Req:                 5   GTPC Echo Timeout:          149160
    Update PDP Req:                 0   GTPU Echo Timeout:               0
    Echo Response:                312   GGSN Req Timeout:            24182


Update PDP Context Denied:
  No Resources:                 500   No Memory:                       0
  System Failure:                 0   Non-existent:                55460

Der GGSN löscht jetzt die PDP-Kontext-Sitzung und benachrichtigt niemals das SGSN oder die Benutzergeräte (UE). SGSN oder UE können eine PDP-Kontextanforderung auslösen, und das GGSN kann diese mit einem Ursachencode 192 ablehnen (nicht vorhanden).

Der folgende Abschnitt stammt aus TS 29.060:

• Wenn ein GPRS Supporting Node (GSN) eine GPRS Tunneling Protocol-Control Plane (GTP-C)-Nachricht empfängt, in der Maßnahmen in Bezug auf einen PDP-Kontext angefordert werden, von dem der sendende Knoten glaubt, dass er vorhanden ist, der vom empfangenden Knoten jedoch nicht erkannt wird, sendet der empfangende Knoten eine Antwort mit dem entsprechenden Ursachenwert (entweder "Nicht vorhanden" oder "Kontext nicht gefunden").  Die in der Antwortnachricht verwendete Tunnel-Endpunkt-Kennung muss auf alle Nullen eingestellt sein.
• Wenn der SGSN eine PDP-Kontextantwort mit dem Ursachenwert "Nicht vorhanden" empfängt, es muss PDP-Kontext löschen..

Ursachenfehler Code 192

Ein Ursachencode 192 (oder nicht vorhanden) ist ein Fehler, der von den GSNs auf der Gn-Schnittstelle gesendet wird. Sie wird in das Informationselement Ursache von GTP-Nachrichten eingetragen.

Dies sind die GTP-Meldungen, bei denen der Ursachencode 192-Fehler auftreten kann:

• Update_PDP_Context_Response
  
  
• Delete_PDP_Context_Response

Hinweis: Die Tunnel End Identifier (TEID), die in der Meldung verwendet wird, die diesen Fehler enthält, ist Null. Weitere Informationen finden Sie unter TS 29.060.

Dieser Fehler kann in den oben genannten Meldungen angezeigt werden, wenn er von einem GSN gesendet wird und nicht über einen Kontext verfügt, der dem vom anderen GSN gesendeten entspricht. Die GSNs löschen den PDP-Kontext, wenn dieser Fehler auftritt.

Beispielszenarien

In diesem Abschnitt werden vier Szenarien beschrieben, in denen ein Ursachencode-Fehler 192 auftreten kann.

• Szenario 1: Zwischen den GSNs tritt ein Fehler beim GTP-C-Pfad auf.
  
  
• Szenario 2 - Zwischen den GSNs tritt ein Echo-Anfrage-/Antwortfehler auf.
  
  
• Szenario 3 - Es liegt ein Handoff-Problem mit GTP-Version 1 (GTPv1) an GTP-Version 0 (GTPv0) vor, das den Fehler verursacht. Im Folgenden finden Sie ein Beispiel für einen Anrufablauf in diesem Szenario:
  
  
  1. Eine PDP-Kontextanforderung mit GTPv1 wird erstellt.
     
     
  2. Die GTPv1-to-GTPv0-Übergabe erfolgt.
     
     
  3. Der Anruf auf dem GGSN befindet sich jetzt in GTPv0.
     
     
  4. Der GGSN empfängt die PDP-Kontextanforderung mit einer TEID-Nummer ohne 0-Header und lehnt sie aufgrund des Fehlers ab (nicht vorhanden).

     Hinweis: Der SGSN sollte die TEID vergessen haben, da der Anruf in GTPv0 verschoben wurde (nur Flow-Label für GTPv0, nicht für TEIDs vorhanden). Dies weist darauf hin, dass das SGSN selbst nach der Übergabe an GTPv0 am GTPv1-Anruf gehalten wird.

• Szenario 4 - Der synchrone TEID-Effekt wird multipliziert. Hier ein Beispiel:
  
  
  1. Die UE1 erstellt einen PDP-Kontext. Der SGSN weist dem sgsn-UE1-ctxt-Kontext die Control-TEID-1 (C-TEID-1) als Steuerungs-TEID zum GGSN zu. Die C-TEID für alle Meldungen im GGSN, die zum SGSN führen, lautet C-TEID-1.
     
     
  2. Eine Signalisierungsmeldung (kein Echo), die im SGSN ein Timeout ausgibt, und das SGSN räumt diesen sgsn-UE1-ctxt-Kontext lokal auf. Es informiert außerdem den Radio Network Controller (RNC), das Problem zu beheben. Sie informiert den GGSN nicht, da er den GGSN als inaktiv behandelt. Nun gibt es keinen PDP-Kontext für UE1 auf dem SGSN, und der PDP-Kontext für dasselbe UE1 existiert auf dem GGSN mit C-TEID-1. Der C-TEID-1 geht zurück zum Schwanz der freien Liste.
     
     
  3. Die UE2 möchte dann einen PDP-Kontext für dasselbe APN einrichten und über dasselbe SGSN und GGSN weiterleiten. Im SGSN wird die TEID zugewiesen, und ein sgsn-UE2-ctxt-Kontext wird an den GGSN gesendet. Wenn die Anzahl der freien TEIDs gering ist, wird die kürzlich freigegebene TEID dem neuen PDP-Kontext neu zugewiesen. In diesem Fall wird C-TEID-1 UE2 neu zugewiesen.
     
     
  4. Auf dem GGSN gibt es zwei Kontexte mit C-TEID-1 als Gn C-TEID. Der GGSN überprüft nicht, ob für dasselbe bereits eine TEID vorhanden ist. Der GGSN initiiert dann einen Delete PDP Context (DPC) für UE1 zum SGSN.
     
     
  5. Auf dem SGSN wird die C-TEID-1 zusammen mit dem Kontext für sie gefunden, d. h. sgsn-UE2-Ctxt. Es wird versucht, diesen Kontext zu löschen und auf den GGSN zu reagieren.
     
     
  6. Wenn GGSN-Anforderungen (Update/Delete PDP) für die anderen Kontexte vorliegen, reagiert das SGSN mit einer nicht gefundenen Ursache im Kontext.
     
     
  7. Der GGSN verwirft diese DPC-Antwort für UE2, da er nie eine DPC-Anforderung für UE2 gesendet hat.
     
     
  8. Es gibt jetzt einen zweiten Kontext auf dem GGSN, der keinem Kontext auf dem SGSN entspricht.
     
     
  9. Wenn einem anderen UE dasselbe C-TEID-1 zugewiesen wird, wiederholt sich das Problem und verschärft es.

Der folgende Abschnitt stammt aus TS 29.060:

Echoantwort

Die Nachricht wird als Antwort auf ein empfangenes Echo Request gesendet.

Das GSN, das eine Echo-Antwort von einem Peer-GSN empfängt, vergleicht den empfangenen Restart Counter-Wert mit dem vorherigen Restart Counter-Wert, der für diesen Peer-GSN gespeichert wurde. Wenn kein früherer Wert gespeichert wurde, muss der in der Echo-Antwort erhaltene Zählerwert neu starten für das Peer-GSN gespeichert werden.

Der Wert eines Zählers neu starten, der zuvor für einen Peer-GSN gespeichert wurde, kann sich von dem Wert des Zählers neu starten unterscheiden, der in der Echo-Antwort dieses Peer-GSN empfangen wurde. In diesem Fall gilt das GSN, das die Echo-Antwort gesendet hat, als vom GSN neu gestartet, das die Echo-Antwort erhalten hat. Der neu erhaltene Zählerwert für den Neustart wird von der empfangenden Einheit gespeichert und ersetzt den zuvor für den sendenden GSN gespeicherten Wert.

Handelt es sich beim sendenden GSN um ein GGSN und beim empfangenden GSN um ein SGSN, betrachtet das SGSN alle PDP-Kontexte, die das GGSN verwenden, als inaktiv. Weitere Maßnahmen des SGSN finden Sie in den technischen Spezifikationen für das 3rd Generation Partnership Project (3GPP) 23.007 [3].

Handelt es sich beim sendenden GSN um ein SGSN und beim empfangenden GSN um ein GGSN, betrachtet das GGSN alle PDP-Kontexte, die das SGSN verwenden, als inaktiv. Weitere Maßnahmen des GGSN finden Sie unter 3GPP TS 23.007 [3].

Der folgende Abschnitt stammt aus dem 3GPP TS 23.007 V8.0:

Wiederherstellung der Daten im SGSN

Neustart des SGSN

Nach einem SGSN-Neustart löscht das SGSN alle vom Neustart betroffenen Kontexte für Mobility Management (MM), PDP, Multimedia Broadcast Multicast Services (MBMS) UE und MBMS Bearer. Die SGSN-Speicherung von Daten ist flüchtig, außer wie in dieser Unterklausel angegeben. Der SGSN unterhält im flüchtigen Speicher einen GGSN-Neustartzähler für jedes GGSN, mit dem der SGSN in Kontakt ist, sowie in nichtflüchtigen SGSN-Neustartzählern, die sich auf jedes GGSN beziehen, mit dem der SGSN in Kontakt steht. Die Zähler für den SGSN-Neustart werden inkrementiert und alle Zähler für den GGSN-Neustart werden sofort nach dem Neustart des SGSN gelöscht.  Der Neustartzähler kann allen GGSNs gemeinsam sein, oder es gibt einen separaten Zähler für jeden GGSN.

Der GGSN führt eine Polling-Funktion (Echoanfrage und Echoantwort) für die SGSNs aus, mit denen das GGSN in Kontakt ist. Der Zähler für den SGSN-Neustart muss in die Echo-Antwort aufgenommen werden. Weicht der im GGSN empfangene Wert von dem für diesen SGSN gespeicherten Wert ab, wird vom GGSN angenommen, dass der SGSN neu gestartet wurde (siehe 3GPP TS 29.060). Die Zähler für den GGSN-Neustart werden im SGSN auf den Wert aktualisiert, der in der ersten Echo-Nachricht von jedem GGSN empfangen wird, nachdem der SGSN neu gestartet wurde.

Wenn das GGSN einen Neustart in einem SGSN erkennt, mit dem der PDP-Kontext aktiviert ist, löscht es alle PDP-Kontexte. Außerdem wird der neue Wert des SGSN Restart-Zählers, der in der Echo-Antwort des neu gestarteten SGSN empfangen wird, im GGSN aktualisiert.