Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
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 :
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.
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 :
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.
Cette section décrit quatre scénarios dans lesquels une erreur de code de cause 192 peut se produire.
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.
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.