Comportement GGSN avec des pannes d'activation PDP et aucune réponses d'écho GTP

Introduction

Ce document décrit le comportement du Service général de radiocommunication par paquets (GPRS) de passerelle prenant en charge le noeud (GGSN) quand le service GPRS prenant en charge le noeud (SGSN) ne répond pas à la requête d'écho de GPRS Tunneling Protocol (GTP) qui est envoyée du GGSN.

Informations générales

Vous pourriez éprouver les pannes d'activation élevées de Protocol de données de paquets (PDP) dans le GGSN au cours d'une période où le SGSN ne répond pas aux requêtes d'écho GTP. Voici quelques questions qui pourraient se poser dans ce scénario :

1. Créent le PDP ou les demandes de la mise à jour PDP du SGSN arrivent au GGSN ?
   
   
2. Quand les requêtes d'écho GTP échouent du GGSN au SGSNs, comment le GGSN devrait-il se comporter si le contexte de la mise à jour PDP qui est envoyé du GGSN ne reçoit pas une réponse ?
   
   
3. Comment est-ce qu'un GGSN échoue un PDP s'il ne reçoit pas une réponse d'écho GTP ou une réponse pour les messages de demande de non-écho qui arrivent d'un SGSN pour ce PDP ?
   
   
4. Comment est-ce qu'un manque dans des réponses d'écho/non-écho GTP affecte directement les pannes d'activation PDP ?

Comportement GGSN

Si les messages n'arrivent pas au GGSN, alors le SGSN déclenche une alarme de panne de chemin et les relâche silencieusement. Supplémentaire, s'il n'y a aucune réponse d'écho reçue pour la requête d'écho qui est initiée par le GGSN, il indique que le pair est vers le bas, ainsi le GGSN localement efface les appels qui sont liés à ce pair.

Dans l'exposition le support détaille la sortie de commande, ou la sortie de commande bavarde de statistiques de gtpc d'exposition, vous pouvez visualiser les compteurs de délai d'attente GGSN Req :

#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

Si vous étudiez les messages de requête d'écho qui sont transférés du GGSN vers le SGSN, il s'avère que le GGSN ne reçoit pas les réponses d'écho. Vous devez s'assurer que les messages ne sont pas dus abandonné à conduire des questions sur le réseau ou que le SGSN n'est pas disponible.

La plupart de problème courant est les pannes de chemin de contrôle, qui font devenir un grand nombre de SGSNs errant inaccessible.

S'il y a n'importe quels GTP de message de contrôle (comme une demande de contexte de mise à jour PDP) du GGSN qui ne reçoit pas une réponse après que toutes les tentatives soient épuisées, le GGSN pense que le pair est inaccessible et démolit seulement que la session particulière signale la cause comme panne de chemin. Le contexte PDP est supprimé sur le GGSN, mais le SGSN n'est pas annoncé. Ce compte est identifié avec des ces des statistiques :

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

Le GGSN déchire maintenant vers le bas la session de contexte PDP et n'informe jamais le SGSN ou l'équipement de l'utilisateur (UE). Le SGSN ou l'UE pourrait déclencher une demande de contexte de la mise à jour PDP, et le GGSN pourrait la rejeter avec code de cause 192 (inexistant).

Voici une section qui est prise des SOLIDES TOTAUX 29.060 :

• Si un Gprs prenant en charge Node(GSN) reçoit un message de l'avion de Protocol-Control de Tunnellisation de Gprs (GTP-C) demandant l'action liée à un contexte PDP que le noeud émetteur croit est en existence, mais cela n'est pas identifié par le noeud récepteur, le noeud récepteur renverra à la source de message, une réponse avec la valeur de cause appropriée (« inexistant » ou « contexte non trouvé »).  L'identifiant de périphérique du tunnel utilisé dans le message de réponse sera placé à tous les zéros.
• Si le SGSN reçoit une réponse de contexte de la mise à jour PDP avec une valeur de cause « inexistante », il shalldelete le contexte PDP.

Erreur de code de cause 192

Code de cause 192 (ou inexistant) est une erreur qui est envoyée par le GSNs sur l'interface de la GN. Il est rempli dans la cause de l'élément d'information de messages GTP.

Ce sont les messages GTP qui peuvent avoir une erreur de code de cause 192 :

• Update_PDP_Context_Response
  
  
• Delete_PDP_Context_Response

Remarque: L'identifiant d'extrémité de tunnel (TEID) qui est utilisé dans le message qui contient cette erreur sera zéro. Référez-vous aux SOLIDES TOTAUX 29.060 pour d'autres détails.

Cette erreur peut apparaître dans les messages mentionnés ci-dessus quand elle est envoyée par un GSN et elle n'a pas un contexte qui correspond à celui qui est envoyé par l'autre GSN. L'effacement de GSNs le contexte PDP quand cette erreur est reçue.

Exemples de scénarios

Cette section décrit quatre scénarios dans lesquels une erreur de code de cause 192 peut se produire.

• Scénario 1 ? Une panne de chemin GTP-C se produit entre le GSNs.
  
  
• Scénario 2 ? Une panne de requête d'écho/réponse se produit entre le GSNs.
  
  
• Scénario 3 ? Il y a une version 1 (GTPv1) GTP à la question de transfert de la version 0 GTP (GTPv0) qui entraîne l'erreur. Voici un appel-écoulement d'échantillon pour ce scénario :
  
  
  1. Une demande de contexte de la création PDP avec GTPv1 est établie.
     
     
  2. Le transfert GTPv1-to-GTPv0 se produit.
     
     
  3. Le faire appel au GGSN est maintenant à GTPv0.
     
     
  4. Le GGSN reçoit la demande de contexte de la mise à jour PDP avec une en-tête différente de zéro TEID et la rejette due à l'erreur (inexistante).

     Remarque: Le SGSN devrait avoir oublié le TEID, comme l'appel s'est déplacé à GTPv0 (seulement les écoulement-étiquettes existent pour GTPv0, pas TEIDs). Ceci indique que le SGSN s'est tenu en fonction sur l'appel GTPv1 même après le transfert sur GTPv0.

• Scénario 4 ? L'effet du -de-sync TEID est multiplié. Voici un exemple :
  
  
  1. L'UE1 établit un contexte PDP ; le SGSN répartit le Control-TEID-1 (C-TEID-1) en tant que son contrôle TEID vers le GGSN sur le contexte sgsn-UE1-ctxt. Les C-TEID pour tous les messages sur les GGSN qui se dirigent vers le SGSN ont C-TEID-1.
     
     
  2. Les minuteries d'un message de signalisation (non-écho) sur le SGSN, et le SGSN nettoie ce contexte sgsn-UE1-ctxt localement. Il informe également le contrôleur de réseau radio (RNC) pour nettoyer. Il n'informe pas le GGSN, car il traite le GGSN en tant que vers le bas. Maintenant il n'y a aucun contexte PDP pour UE1 sur le SGSN, et le contexte PDP pour le même UE1 existe sur le GGSN avec C-TEID-1. Le C-TEID-1 retourne à la queue de la liste libre.
     
     
  3. L'UE2 alors veut établir un contexte PDP au même APN et traverse le mêmes SGSN et GGSN. Sur le SGSN, le TEID est alloué et un contexte sgsn-UE2-ctxt est envoyé au GGSN. Si le nombre de TEIDs libre est bas, alors le TEID récemment libéré est réapproprié au nouveau contexte PDP. Dans ce cas, C-TEID-1 est réapproprié à UE2.
     
     
  4. Sur le GGSN, il y a deux contextes avec C-TEID-1 en tant que GN C-TEID. Le GGSN ne vérifie pas s'il y a des TEID déjà actuels pour la même chose. Le GGSN initie alors un contexte de l'effacement PDP (DPC) pour UE1 vers le SGSN.
     
     
  5. Sur le SGSN, le C-TEID-1 est trouvé, avec le contexte pour lui, qui est sgsn-UE2-Ctxt. Une tentative est faite afin de supprimer ce contexte et répondre au GGSN.
     
     
  6. S'il y a des demandes GGSN-initiées (mise à jour/effacement PDP) des autres contextes, le SGSN répond avec une cause non trouvée de contexte.
     
     
  7. Le GGSN relâche cette réponse DPC pour UE2 parce qu'il n'a jamais envoyé une demande DPC d'UE2.
     
     
  8. Il y a maintenant un deuxième contexte sur le GGSN qui ne correspond à aucun contexte sur le SGSN.
     
     
  9. Si le même C-TEID-1 est assigné à un autre UE, le problème répète et compose la question.

Voici une section qui est prise des SOLIDES TOTAUX 29.060 :

Réponse d'écho

Le message sera envoyé comme réponse à une requête d'écho reçue.

Le GSN qui reçoit une réponse d'écho d'un pair GSN comparera la valeur du compteur de reprise reçue à la valeur du compteur précédente de reprise enregistrée pour ce pair GSN. Si aucune valeur précédente n'était enregistrée, la valeur du compteur de reprise reçue dans la réponse d'écho sera enregistrée pour le pair GSN.

La valeur d'un compteur de reprise précédemment enregistré pour un pair GSN peut différer de la valeur du compteur de reprise reçue dans la réponse d'écho de ce pair GSN. Dans ce cas, le GSN qui a envoyé la réponse d'écho sera considéré en tant que redémarré par le GSN qui a reçu la réponse d'écho. La nouvelle valeur du compteur de reprise reçue sera enregistrée par l'entité de réception, remplaçant la valeur précédemment enregistrée pour le GSN de envoi.

Si le GSN de envoi est un GGSN et le GSN de réception est un SGSN, le SGSN considèrera tous les contextes PDP utilisant le GGSN comme inactif. Pour d'autres actions du SGSN référez-vous au 3ème partenariat de génération Project(3GPP) Specifications(TS) technique 23.007 [3].

Si le GSN de envoi est un SGSN et le GSN de réception est un GGSN, le GGSN considèrera tous les contextes PDP utilisant le SGSN comme inactif. Pour d'autres actions du GGSN référez-vous aux SOLIDES TOTAUX 3GPP 23.007 [3].

Voici une section qui est prise des SOLIDES TOTAUX 3GPP 23.007 V8.0 :

Restauration des données dans le SGSN

Reprise du SGSN

Après qu'une reprise SGSN, le SGSN supprime toute la mobilité Management(MM), le PDP, des multimédia a annoncé des contextes des services de Multidiffusion (MBMS) UE, et du support MBMS affectés par la reprise. La mémoire SGSN des données est volatile excepté comme spécifiée dans ce paragraphe. Le SGSN met à jour dans la mémoire volatile une reprise GGSN contre- pour chaque GGSN avec lequel le SGSN est en contact, et dans des compteurs de reprise de la mémoire non volatile SGSN qui associent à chaque GGSN avec lequel le SGSN est en contact. Les compteurs de reprise SGSN seront incrémentés et tous les compteurs de reprise GGSN seront effacés juste après que le SGSN a redémarré.  Le compteur de reprise peut être commun à tout le GGSNs ou il peut y a un compteur distinct pour chaque GGSN.

Le GGSN remplit une fonction d'interrogation (réponse de requête d'écho et d'écho) vers le SGSNs avec lequel le GGSN est en contact. Le compteur de reprise SGSN sera inclus dans la réponse d'écho. Si la valeur reçue dans le GGSN diffère de celui enregistré pour celui SGSN, le GGSN considèrera que le SGSN a redémarré (voir 3GPP LES SOLIDES TOTAUX 29.060). Les compteurs de reprise GGSN seront mis à jour dans le SGSN à la valeur reçue dans le premier message d'écho provenant chaque GGSN après que le SGSN ait redémarré.

Quand le GGSN détecte une reprise dans un SGSN avec lequel elle fait lancer des contextes PDP, elle supprimera tous ces contextes PDP. En outre, la nouvelle valeur du compteur de reprise SGSN reçu dans la réponse d'écho du SGSN redémarré sera mise à jour dans le GGSN.