GGN-gedrag met activeringsfouten van PDP en geen GTP-Echo-respons

Inleiding

Dit document beschrijft het gedrag van het Gateway General Packet Radio Service (GPRS) Support Node (GGSN) wanneer het Serving GPRS Support Node (SGSN) niet reageert op het GPRS Tunneling Protocol (GTP)-echo-verzoek dat van de GGSN wordt verstuurd.

Achtergrondinformatie

U kunt tijdens een periode waarin het SGN niet reageert op de GTP-echo-verzoeken, vaak last hebben van fouten in de PDP-activeringswizard (Packet Data Protocol). Hier zijn een paar vragen die in dit scenario zouden kunnen rijzen:

1. arriveren de PDP-verzoeken om PDP-bestanden te uploaden van het SGN?
   
   
2. Als de GTP-echo-verzoeken nalaten van de GGSN naar de SGSN's, hoe moet de GGSN zich dan gedragen als de PDP-context die van de GGSN wordt verstuurd, geen antwoord ontvangt?
   
   
3. Hoe faalt een GSN een PDP als het geen GTP echo respons of een reactie voor de niet echo verzoekberichten ontvangt die van een SGSN voor die PDP komen?
   
   
4. Hoe beïnvloedt een gebrek aan GTP-echo-/niet-echo-reacties de PDP-activeringsmislukkingen direct?

GSN-gedrag

Als de berichten niet bij het GGSN aankomen, dan leidt SGSN een alarm voor een padstoring en laat het in stilte vallen. Als er geen echo-reactie is ontvangen voor het echo-verzoek dat door GSN is geïnitieerd, duidt dit erop dat de peer omlaag is, dus klaagt de GGSN lokaal de oproepen die aan die peer gerelateerd zijn.

In de opdrachtoutput van de showondersteuningsdetails, of de show gtpc statistieken breedteuitvoer, kunt u de Time-out -tellers van GSN Req bekijken:

#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

Als je de echo-berichten onderzoekt die van de GGSN naar de SGSN worden overgebracht, lijkt het erop dat de GGSN de echo-reacties niet ontvangt. U moet ervoor zorgen dat de berichten niet vallen vanwege het verzenden van problemen op het netwerk of dat SGN niet beschikbaar is.

Het meest voorkomende probleem is het falen van het controlepad, waardoor een groot aantal van de roamende SGSN's onbereikbaar wordt.

Als er een GTP-controleverslag (zoals een update PDP context request) van de GGSN is dat geen antwoord ontvangt nadat alle pogingen zijn uitgeput, denkt het GGSN dat de peer onbereikbaar is en lekt alleen die sessie de oorzaak af als een Padfout. De PDP-context wordt verwijderd op het GGSN, maar het SGSN wordt niet aangemeld. Deze telling wordt in deze statistieken bepaald:

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

De GGN-code gaat nu de PDP-vergadersessie af en stelt nooit de SGN of de gebruikersapparatuur (UE) op de hoogte. Het SGSN of de EU kan een PDP-contextverzoek starten en het GGSN kan het met een oorzaakcode 192 afwijzen (niet-bestaand).

Dit is een deel dat is overgenomen van TS 29.060:

• Als een GPRS Support Node (GSN) een GPRS Tunneling Protocol-Control plane (GTP-C) bericht ontvangt met het verzoek om actie met betrekking tot een PDP-context waarvan het verzendende knooppunt bestaat, maar dat niet wordt herkend door het ontvangende knooppunt, stuurt het ontvangende knooppunt een reactie naar de bron van het bericht, met de juiste oorzaakwaarde (ofwel "Niet-bestaand" of "Context niet gevonden").  De in het antwoordbericht gebruikte tunnelendpointidentificatie wordt op alle nullen ingesteld.
• Als het SGSN een PDP-respons met een oorzaakwaarde "niet-bestaand" ontvangt, IT verwijdert de PDP-context.

Oorzaakcode 192-fout

Een oorzaakcode 192 (of niet-bestaand) is een fout die door de GNU's op de GNU-interface wordt verzonden. Het is bevolkt in het Oorzaak van GTP-berichten informatie element.

Dit zijn de GTP berichten die een fout van de Oorzaakcode 192 kunnen hebben:

• Update_PDP_Context_Response
  
  
• Verwijderen_PDP_Context_Response

Opmerking: De Tunnel End Identifier (TEID) die wordt gebruikt in het bericht dat deze fout bevat, is nul. Zie TS 29.060 voor nadere informatie.

Deze fout kan in de bovengenoemde berichten verschijnen wanneer hij door een GSN wordt verstuurd en heeft geen context die overeenkomt met de fout die door de andere GSN wordt verstuurd. De GSN's verwijderen de PDP-context wanneer deze fout wordt ontvangen.

Bijvoorbeeld scenario's

In dit hoofdstuk worden vier scenario's beschreven waarin een oorzaakcode 192-fout kan voorkomen.

• Scenario 1 - Er treedt een fout in de GTP-C snijpad tussen de GSN’s op.
  
  
• Scenario 2 - Tussen de GSN's treedt een storing op in een echo-verzoek/reactie.
  
  
• Scenario 3 - Er is een handig probleem met GTP versie 1 (GTPv1) naar GTP versie 0 (GTPv0) dat de fout veroorzaakt. Hier is een voorbeeld van aanroep-flow voor dit scenario:
  
  
  1. Er wordt een PDP-contextverzoek met GTPv1 ingesteld.
     
     
  2. De GTPv1-to-GTPv0 afhankelt.
     
     
  3. De oproep aan de GGSN is nu op GTPv0.
     
     
  4. GGN ontvangt het PDP-contextverzoek met een niet-nulheaderTEID en verwerpt dit vanwege de fout (niet-bestaand).

     Opmerking: Het SGSN had de TEID moeten vergeten, omdat de oproep naar GTPv0 is verplaatst (er bestaan alleen stroomlabels voor GTPv0 en niet voor TEIDs). Dit geeft aan dat het SGSN op de GTPv1-oproep werd gehouden zelfs na de handoff naar GTPv0.

• Scenario 4 - Het out-of-sync TEID-effect wordt vermenigvuldigd. Hierna volgt een voorbeeld:
  
  
  1. De EU1 stelt een PDP-context vast; de SGSN toekent de Control-TEID-1 (C-TEID-1) als zijn CONTROLE-TEID ten opzichte van de GSN op de sgsn-UE-1-ctxt context. De C-TEID voor alle berichten op de GSN die naar de SGSN gaan, heeft C-TEID-1.
     
     
  2. Een signaleringsbericht (niet-echo) - time-out op de SGSN, en de SGSN ruimen de lokale sgsn-UE1-ctxt context op. Het stelt ook de Radio Network Controller (RNC) op om het op te ruimen. Het stelt de GGSN niet op de hoogte, omdat het de GGSN als beneden behandelt. Er is nu geen PDP-context voor UE1 op de SGSN, en de PDP-context voor dezelfde UE1 bestaat op de GSN met C-TEID-1. De C-TEID-1 gaat terug naar de staart van de vrije lijst.
     
     
  3. UE2 wil dan een PDP-context creëren die gelijk is aan APN en door dezelfde SGSN en GGSN gaat. Op het SGSN wordt de TEID toegewezen en wordt een sgsn-UE2-ctxt context naar het GGSN gestuurd. Als het aantal gratis TEID's laag is, wordt de recent vrijgegeven TEID opnieuw toegewezen aan de nieuwe PDP-context. In dit geval wordt C-TEID-1 opnieuw toegewezen aan UE2.
     
     
  4. Op het GSN zijn er twee contexten met C-TEID-1 als Gn C-TEID. Het GSN controleert niet of er al een TEID voor hetzelfde product aanwezig is. Het GSN start vervolgens een PDP-context (DPC) verwijderen voor UE1 in de richting van het SGSN.
     
     
  5. Op het SGSN is de C-TEID-1 gevonden, samen met de context ervoor, namelijk sgsn-UE2-Ctxt. Er wordt gepoogd deze context te verwijderen en op de GGSN te reageren.
     
     
  6. Als er GN-geïnitieerde verzoeken (update/verwijder PDP) zijn voor de andere contexten, reageert SGN met een Context die oorzaak niet gevonden heeft.
     
     
  7. De GGSN laat die reactie van DPC voor UE2 vallen omdat deze geen DPC-aanvraag voor UE2 heeft ingediend.
     
     
  8. Er is nu een tweede context over het GSN die niet overeenkomt met een context inzake het SGSN.
     
     
  9. Als dezelfde C-TEID-1 aan een andere UE is toegewezen, dan herhaalt en koppelt het probleem zich af.

Dit is een deel dat is overgenomen van TS 29.060:

Echo-respons

Het bericht wordt verzonden als antwoord op een ontvangen echo-aanvraag.

Het GSN dat een Echo-respons van een peer-GSN ontvangt, moet de waarde van de Restart Counter vergelijken met de vorige Restart Counter waarde die is opgeslagen voor dat peer-GSN. Als er geen vorige waarde is opgeslagen, moet de waarde van de contrastwaarde voor het herstarten van de echo-respons worden opgeslagen voor de peer GSN.

De waarde van een eerder opgeslagen herstartteller voor een peer GSN kan afwijken van de waarde van de herstartteller in de Echo-respons van dat peer GSN. In dat geval wordt het GSN dat de Echo-respons heeft verstuurd, beschouwd als herstart door het GSN dat de Echo-respons heeft ontvangen. De nieuwe ontvangen tegenwaarde voor herstart wordt door de ontvangende entiteit opgeslagen ter vervanging van de eerder voor de verzendende GSN opgeslagen waarde.

Indien het verzendende GSN een GSN is en het ontvangende GSN een SGSN is, beschouwt het SGSN alle PDP-contexten waarbij het GGSN wordt gebruikt als inactief. Voor verdere maatregelen van het SGSN wordt verwezen naar het derde-generatiepartnerschapsproject (3GPP) Technische specificaties (TS) 23.007 [3].

Indien het verzendende GSN een SGSN is en het ontvangende GSN een GGSN is, beschouwt het GGSN alle PDP-contexten waarbij het SGSN wordt gebruikt als inactief. Voor verdere acties van het GGSN wordt verwezen naar 3GPP TS 23.007 [3].

Dit is een gedeelte dat is overgenomen uit 3GPP TS 23.007 V8.0:

Herstel van gegevens in het SGSN

Herstart van het SGSN

Na een herstart van SGSN, verwijdert SGSN alle Mobility Management (MM), PDP, Multimedia Broadcast Multicast Services (MBMS) UE en MBMS Beonder de gevolgen van de herstart. SGSN-opslag van gegevens is volatiel, behalve zoals in deze subclausule gespecificeerd. Het SGSN houdt in vluchtig geheugen een GGSN Restart teller bij voor elk GSN waarmee het SGSN in contact komt, en in niet-vluchtige geheugen SGSN Restart tellers die betrekking hebben op elk GSN waarmee het SGSN in contact komt. De SGSN-herstarttellers worden verhoogd en alle GGSN-herstarttellers worden onmiddellijk na de herstart van het SGSN vrijgegeven.  De herstartteller kan gemeenschappelijk zijn voor alle GG's of er kan een afzonderlijke teller zijn voor elke GGSN.

Het GSN vervult een stemfunctie (echo-verzoek en echo-reactie) ten aanzien van de SGSN’s waarmee het GGSN in contact staat. De SGSN-herstartteller wordt opgenomen in de echo-respons. Als de in het GSN ontvangen waarde verschilt van de waarde die voor dat SGSN is opgeslagen, zal het GGSN overwegen dat het SGSN opnieuw is opgestart (zie 3GPP TS 29.060). De GGSN Restart tellers worden in het SGSN geactualiseerd tot de waarde die wordt ontvangen in het eerste echo bericht van elke GGSN nadat het SGSN opnieuw is gestart.

Wanneer het GGSN een herstart in een SGSN waarmede het PDP-context(s) is geactiveerd, detecteert, moet het al deze PDP-context(s) verwijderen. Ook de nieuwe waarde van de SGSN Restart teller die in de echo-respons van het SGSN is ontvangen, wordt in het GGSN aangepast.