Comportement GGSN avec échecs d'activation PDP et aucune réponse d'écho GTP

Introduction

Ce document décrit le comportement du noeud de prise en charge GGSN (Gateway General Packet Radio Service) lorsque le noeud de prise en charge GPRS (Serving GPRS Support Node) ne répond pas à la demande d'écho GPRS Tunneling Protocol (GTP) envoyée par le GGSN.

Informations générales

Vous pouvez rencontrer des échecs d'activation PDP (Packet Data Protocol) élevés dans le GGSN pendant 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. Les demandes Create PDP ou Update PDP du SGSN arrivent-elles au GGSN ?
   
   
2. Lorsque les requêtes d'écho GTP échouent du GGSN vers les SGSN, comment le GGSN doit-il se comporter si le contexte PDP de mise à jour envoyé par le GGSN ne reçoit pas de réponse ?
   
   
3. Comment un GGSN échoue-t-il un PDP s'il ne reçoit pas de réponse d'écho GTP ou de réponse pour les messages de requête non d'écho qui arrivent d'un SGSN pour ce PDP ?
   
   
4. Comment un manque de réponses écho/non écho GTP affecte-t-il directement les échecs d'activation PDP ?

Comportement GGSN

Si les messages n'arrivent pas au GGSN, le SGSN déclenche une alarme de défaillance de chemin et les supprime silencieusement. En outre, si aucune réponse d'écho n'est reçue pour la demande d'écho lancée par le GGSN, elle indique que l'homologue est en panne, de sorte que le GGSN efface localement les appels qui sont liés à cet homologue.

Dans la sortie de la commande show support details ou la sortie de la commande show gtpc statistics verbose, vous pouvez afficher les compteurs GGSN Req Timeout :

#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 examinez les messages de demande d'écho qui sont transférés du GGSN au SGSN, il semble que le GGSN ne reçoive pas les réponses d'écho. Vous devez vous assurer que les messages ne sont pas supprimés en raison de problèmes de routage sur le réseau ou que le SGSN n'est pas disponible.

Le problème le plus courant est les échecs de chemin de contrôle, qui rendent un grand nombre de SGSN itinérants inaccessibles.

S'il existe un message de contrôle GTP (tel qu'une demande de contexte PDP de mise à jour) du GGSN qui ne reçoit pas de réponse une fois toutes les tentatives épuisées, le GGSN pense que l'homologue est inaccessible et ne déchire que cette session particulière signale la cause comme un échec de chemin. Le contexte PDP est supprimé sur le GGSN, mais le SGSN n'est pas notifié. Ce nombre est identifié par les statistiques suivantes :

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étruit maintenant la session de contexte PDP et ne notifie jamais le SGSN ou l'équipement utilisateur (UE). Le SGSN ou l'UE peut déclencher une demande de contexte PDP de mise à jour, et le GGSN peut le rejeter avec un code de cause 192 (inexistant).

Voici une section qui est tirée de TS 29.060 :

• Si un noeud de prise en charge Gprs (GSN) reçoit un message GTP-C (Tunneling Protocol-Control plane) Gprs demandant une action liée à un contexte PDP que le noeud émetteur croit exister, mais qui n'est pas reconnu par le noeud récepteur, le noeud récepteur renvoie à la source du message une réponse avec la valeur de cause appropriée (soit « Inexistant », soit « Contexte introuvable »).  L'identificateur de point de terminaison du tunnel utilisé dans le message de réponse doit être défini sur tous les zéros.
• Si le SGSN reçoit une réponse de contexte PDP Update avec une valeur de cause « Inexistante », c'est doit supprimer le contexte PDP.

Erreur Code Cause 192

Un code de cause 192 (ou inexistant) est une erreur envoyée par les GSN sur l'interface Gn. Il est renseigné dans l'élément d'information Cause of GTP messages.

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

• Réponse_Contexte_PDP_MiseÀJour
  
  
• Réponse_Contexte_PDP_Supprimer

Note: L'identificateur de fin de tunnel (TEID) utilisé dans le message qui contient cette erreur sera zéro. Référez-vous à TS 29.060 pour plus de détails.

Cette erreur peut apparaître dans les messages mentionnés ci-dessus lorsqu'elle est envoyée par un GSN et qu'il n'a pas de contexte qui correspond à celui qui est envoyé par l'autre GSN. Les GSN suppriment le contexte PDP lors de la réception de cette erreur.

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 défaillance de chemin GTP-C se produit entre les GSN.
  
  
• Scénario 2 - Une erreur de requête/réponse d'écho se produit entre les GSN.
  
  
• Scénario 3 - Un problème de transfert GTP version 1 (GTPv1) vers GTP version 0 (GTPv0) provoque l'erreur. Voici un exemple de flux d'appels pour ce scénario :
  
  
  1. Une demande de contexte PDP avec GTPv1 est établie.
     
     
  2. La remise GTPv1 à GTPv0 se produit.
     
     
  3. L'appel sur le GGSN est maintenant à GTPv0.
     
     
  4. Le GGSN reçoit la demande de contexte PDP de mise à jour avec un TEID d'en-tête non nul et le rejette en raison de l'erreur (inexistante).

     Note: Le SGSN aurait dû oublier le TEID, car l'appel a été déplacé vers GTPv0 (il n'existe que des étiquettes de flux pour GTPv0, et non des TEID). Cela indique que le SGSN a été maintenu sur l'appel GTPv1 même après la remise à GTPv0.

• Scénario 4 - L'effet TEID hors synchronisation est multiplié. Voici un exemple :
  
  
  1. L’UE1 établit un contexte PDP ; le SGSN attribue le Control-TEID-1 (C-TEID-1) comme son TEID de contrôle vers le GGSN sur le contexte sgsn-UE1-ctxt. Le C-TEID de tous les messages sur le GGSN qui se dirigent vers le SGSN a C-TEID-1.
     
     
  2. Un message de signalisation (non-écho) expire sur le SGSN, et le SGSN nettoie localement ce contexte sgsn-UE1-ctxt. Il informe également le contrôleur de réseau radio (RNC) de nettoyer. Il n'en informe pas le GGSN, car il traite le GGSN comme étant en panne. Il n'y a maintenant 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 veut ensuite établir un contexte PDP sur le même APN et passer par le même SGSN et GGSN. Sur le SGSN, le TEID est attribué et un contexte sgsn-UE2-ctxt est envoyé au GGSN. Si le nombre de TEID gratuits est faible, le TEID récemment libéré est réattribué au nouveau contexte PDP. Dans ce cas, C-TEID-1 est réattribué à UE2.
     
     
  4. Sur le GGSN, il y a deux contextes avec C-TEID-1 comme Gn C-TEID. Le GGSN ne vérifie pas s'il existe déjà un TEID pour le même. Le GGSN lance ensuite un DPC (Delete PDP Context) pour UE1 vers le SGSN.
     
     
  5. Sur le SGSN, le C-TEID-1 est trouvé, ainsi que le contexte pour lui, qui est sgsn-UE2-Ctxt. Une tentative est faite pour supprimer ce contexte et répondre au GGSN.
     
     
  6. S'il y a des requêtes initiées par GGSN (mise à jour/suppression du PDP) pour les autres contextes, le SGSN répond avec une cause Contexte introuvable.
     
     
  7. Le GGSN abandonne cette réponse DPC pour UE2 car il n'a jamais envoyé de requête DPC pour 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 attribué à une autre UE, le problème se répète et se complique.

Voici une section qui est tirée de TS 29.060 :

Réponse d'écho

Le message doit être envoyé en réponse à une demande d’écho reçue.

Le GSN qui reçoit une réponse d'écho d'un GSN homologue doit comparer la valeur du compteur de redémarrage reçue avec la valeur du compteur de redémarrage précédente stockée pour ce GSN homologue. Si aucune valeur précédente n'a été stockée, la valeur du compteur de redémarrage reçue dans la réponse d'écho doit être stockée pour le GSN homologue.

La valeur d'un compteur de redémarrage précédemment stocké pour un GSN homologue peut différer de la valeur du compteur de redémarrage reçue dans la réponse d'écho de cet homologue GSN. Dans ce cas, le GSN qui a envoyé la réponse d'écho est considéré comme redémarré par le GSN qui a reçu la réponse d'écho. La nouvelle valeur de compteur de redémarrage reçue doit être stockée par l'entité réceptrice, en remplacement de la valeur précédemment stockée pour le GSN émetteur.

Si le GSN d'envoi est un GGSN et que le GSN de réception est un SGSN, le SGSN doit considérer tous les contextes PDP utilisant le GGSN comme inactifs. Pour d'autres mesures du SGSN, voir les spécifications techniques (TS) 23.007 du 3e projet de partenariat de génération (3GPP) [3].

Si le GSN d'envoi est un SGSN et que le GSN de réception est un GGSN, le GGSN doit considérer tous les contextes PDP utilisant le SGSN comme inactifs. Pour plus d'informations sur les actions du GGSN, voir 3GPP TS 23.007 [3].

Voici une section tirée de 3GPP TS 23.007 V8.0 :

Restauration des données dans le SGSN

Redémarrer le SGSN

Après un redémarrage SGSN, le SGSN supprime tous les contextes Mobility Management(MM), PDP, Multimedia Broadcast Multicast Services (MBMS) UE et MBMS Bearer affectés par le redémarrage. Le stockage SGSN des données est volatile sauf comme spécifié dans cette sous-clause. Le SGSN conserve en mémoire volatile un compteur de redémarrage GGSN pour chaque GGSN avec lequel le SGSN est en contact, et en mémoire non volatile des compteurs de redémarrage SGSN qui se rapportent à chaque GGSN avec lequel le SGSN est en contact. Les compteurs de redémarrage SGSN sont incrémentés et tous les compteurs de redémarrage GGSN sont effacés immédiatement après le redémarrage du SGSN.  Le compteur de redémarrage peut être commun à tous les GGSN ou il peut y avoir un compteur distinct pour chaque GGSN.

Le GGSN effectue une fonction d'interrogation (requête d'écho et réponse d'écho) vers les SGSN avec lesquels le GGSN est en contact. Le compteur de redémarrage SGSN doit être inclus dans la réponse d'écho. Si la valeur reçue dans le GGSN diffère de celle stockée pour ce SGSN, le GGSN considérera que le SGSN a redémarré (voir 3GPP TS 29.060). Les compteurs de redémarrage GGSN doivent être mis à jour dans le SGSN pour qu'ils atteignent la valeur reçue dans le premier message d'écho provenant de chaque GGSN après le redémarrage du SGSN.

Lorsque le GGSN détecte un redémarrage dans un SGSN avec lequel le ou les contextes PDP sont activés, il doit supprimer tous ces contextes PDP . En outre, la nouvelle valeur du compteur de redémarrage SGSN reçue dans la réponse d'écho du SGSN redémarré doit être mise à jour dans le GGSN.