Comportamiento GGSN con fallas de activación PDP y sin respuestas de eco GTP

Introducción

Este documento describe el comportamiento del nodo de soporte de GGSN (General Packet Radio Service, GPRS) de la puerta de enlace cuando el nodo de soporte de GPRS de servicio (SGSN) no responde a la solicitud de eco del GPRS Tunneling Protocol (GTP) enviada desde GGSN.

Antecedentes

Es posible que experimente fallos de activación de protocolo de datos de paquetes (PDP) en GGSN durante un período de tiempo en el que SGSN no responde a las solicitudes de eco de GTP. Estas son algunas de las preguntas que podrían surgir en este escenario:

1. ¿Las solicitudes Create PDP o Update PDP del SGSN llegan al GGSN?
   
   
2. Cuando las solicitudes de eco GTP fallan de GGSN a los SGSN, ¿cómo debería comportarse GGSN si el contexto Update PDP enviado desde GGSN no recibe respuesta?
   
   
3. ¿Cómo falla un GGSN en un PDP si no recibe una respuesta de eco GTP o una respuesta para los mensajes de solicitud sin eco que llegan de un SGSN para ese PDP?
   
   
4. ¿Cómo afecta directamente la falta de respuestas de eco/no eco GTP a los fallos de activación PDP?

Comportamiento GGSN

Si los mensajes no llegan al GGSN, el SGSN activa una alarma de falla de trayectoria y los descarta silenciosamente. Además, si no se recibe respuesta de eco para la solicitud de eco iniciada por GSN, indica que el par está inactivo, por lo que GGSN borra localmente las llamadas relacionadas con ese par.

En la salida del comando show support details, o en la salida del comando show gtpc statistics verbose, puede ver los contadores de tiempo de espera de solicitud de GGSN:

#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 investiga los mensajes de solicitud de eco que se transfieren desde el GGSN al SGSN, parece que el GGSN no recibe las respuestas de eco. Debe asegurarse de que los mensajes no se descarten debido a problemas de ruteo en la red o que el SGSN no esté disponible.

El problema más común son las fallas de trayectoria de control, que hacen que un gran número de SGSNs de roaming se vuelvan inalcanzables.

Si hay algún mensaje de control GTP (como una solicitud de contexto PDP de actualización) del GGSN que no recibe una respuesta después de que se agotaron todos los intentos, el GGSN piensa que el peer es inalcanzable y elimina sólo esa sesión en particular informa la causa como un error de trayecto. El contexto PDP se elimina en el GGSN, pero el SGSN no se notifica. Este recuento se identifica con estas estadísticas:

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

El GGSN ahora desgarra la sesión de contexto PDP y nunca notifica al SGSN o al Equipo de usuario (UE). El SGSN o UE podría activar una solicitud de contexto PDP de actualización, y el GGSN podría rechazarla con un Código de causa 192 (inexistente).

Esta es una sección tomada de TS 29.060:

• Si un Gprs Supporting Node (GSN) recibe un mensaje Gprs Tunneling Protocol-Control Plane (GTP-C) solicitando acciones relacionadas con un contexto PDP que el nodo remitente cree que existe, pero que no es reconocido por el nodo receptor, el nodo receptor enviará de vuelta al origen del mensaje, una respuesta con el valor de causa adecuado (ya sea "No existente" o "No encontrado el contexto").  El identificador del punto final del túnel utilizado en el mensaje de respuesta se establecerá en todos los ceros.
• Si el SGSN recibe una actualización de respuesta de contexto PDP con un valor de causa "No existente", it shalldelete the PDP Context.

Error de código de causa 192

Un código de causa 192 (o no existente) es un error que envían los GSN en la interfaz Gn. Se rellena en el elemento de información Causa de mensajes GTP.

Estos son los mensajes GTP que pueden tener un error de Código de causa 192:

• Update_PDP_Context_Response
  
  
• Delete_PDP_Context_Response

Nota: El identificador final del túnel (TEID) que se utiliza en el mensaje que contiene este error será cero. Consulte TS 29.060 para obtener más detalles.

Este error puede aparecer en los mensajes antes mencionados cuando es enviado por un GSN y no tiene un contexto que corresponda al que es enviado por el otro GSN. Los GSN eliminan el contexto PDP cuando se recibe este error.

“Situaciones de ejemplo”

Esta sección describe cuatro escenarios en los que puede producirse un error de Código de causa 192.

• Situación 1: se produce una falla de trayectoria GTP-C entre los GSN.
  
  
• Situación 2: se produce una falla de solicitud/respuesta de eco entre los GSN.
  
  
• Situación 3: hay un problema de transferencia de la versión 1 de GTP (GTPv1) a la versión 0 de GTP (GTPv0) que causa el error. Este es un ejemplo de flujo de llamada para este escenario:
  
  
  1. Se establece una solicitud de contexto PDP con GTPv1.
     
     
  2. Se produce la transferencia de GTPv1 a GTPv0.
     
     
  3. La llamada en GGSN está ahora en GTPv0.
     
     
  4. El GGSN recibe la solicitud de contexto PDP de actualización con un TEID de encabezado distinto de cero y lo rechaza debido al error (inexistente).

     Nota: El SGSN debería haber olvidado el TEID, ya que la llamada se trasladó a GTPv0 (sólo existen etiquetas de flujo para GTPv0, no TEID). Esto indica que el SGSN se mantuvo en la llamada GTPv1 incluso después de la transferencia a GTPv0.

• Situación 4: el efecto TEID fuera de sincronización se multiplica. Aquí tiene un ejemplo:
  
  
  1. La UE1 establece un contexto PDP; el SGSN asigna el Control-TEID-1 (C-TEID-1) como su TEID de control hacia el GGSN en el contexto sgsn-UE1-ctxt. El C-TEID para todos los mensajes en el GGSN que van hacia el SGSN tienen C-TEID-1.
     
     
  2. Se agota el tiempo de espera de un mensaje de señalización (sin eco) en el SGSN y el SGSN limpia ese contexto sgsn-UE1-ctxt localmente. También informa al controlador de red de radio (RNC) para que lo limpie. No informa al GGSN, ya que trata al GGSN como inactivo. Ahora no hay contexto PDP para UE1 en el SGSN, y el contexto PDP para el mismo UE1 existe en el GGSN con C-TEID-1. El C-TEID-1 vuelve a la cola de la lista libre.
     
     
  3. A continuación, la UE2 desea establecer un contexto PDP con el mismo APN y pasa a través del mismo SGSN y GGSN. En el SGSN, el TEID se asigna y un contexto sgsn-UE2-ctxt se envía al GGSN. Si el número de TEID libres es bajo, el TEID liberado recientemente se reasigna al nuevo contexto PDP. En este caso, C-TEID-1 se reasigna a UE2.
     
     
  4. En el GGSN, hay dos contextos con C-TEID-1 como el Gn C-TEID. El GGSN no verifica si hay un TEID ya presente para el mismo. A continuación, GGSN inicia un contexto PDP de eliminación (DPC) para UE1 hacia el SGSN.
     
     
  5. En el SGSN, se encuentra el C-TEID-1, junto con el contexto para él, que es sgsn-UE2-Ctxt. Se intenta eliminar ese contexto y responder al GGSN.
     
     
  6. Si hay solicitudes iniciadas por GGSN (actualizar/eliminar PDP) para los otros contextos, el SGSN responde con una causa no encontrada en el contexto.
     
     
  7. El GGSN descarta esa respuesta DPC para UE2 porque nunca envió una solicitud DPC para UE2.
     
     
  8. Ahora hay un segundo contexto en el GGSN que no corresponde a ningún contexto en el SGSN.
     
     
  9. Si el mismo C-TEID-1 se asigna a otra UE, el problema se repite y complica.

Esta es una sección tomada de TS 29.060:

Respuesta de eco

El mensaje se enviará como respuesta a una solicitud de eco recibida.

El GSN que recibe una respuesta de eco de un GSN de peer comparará el valor del contador de reinicio recibido con el valor del contador de reinicio anterior almacenado para ese GSN de peer. Si no se almacenó ningún valor anterior, el valor del contador de reinicio recibido en la respuesta de eco se almacenará para el GSN del par.

El valor de un contador de reinicio almacenado previamente para un GSN de peer puede diferir del valor de contador de reinicio recibido en la respuesta de eco de ese GSN de peer. En este caso, el GSN que envió la respuesta de eco se considerará reiniciado por el GSN que recibió la respuesta de eco. El nuevo valor del contador de reinicio recibido será almacenado por la entidad receptora, sustituyendo el valor previamente almacenado para el GSN remitente.

Si el GSN remitente es un GGSN y el GSN receptor es un SGSN, el SGSN considerará que todos los contextos PDP que utilicen el GGSN están inactivos. Para otras acciones de la SGSN, consulte el Proyecto de asociación de tercera generación (3GPP) Especificaciones técnicas (TS) 23.007 [3].

Si el GSN remitente es un SGSN y el GSN receptor es un GGSN, el GGSN considerará que todos los contextos PDP que utilicen el SGSN están inactivos. Para más acciones del GGSN, véase 3GPP TS 23.007 [3].

Esta es una sección tomada de 3GPP TS 23.007 V8.0:

Restauración de datos en SGSN

Reinicio de SGSN

Después de un reinicio de SGSN, el SGSN elimina todos los contextos de gestión de movilidad (MM), PDP, servicios multidifusión de difusión multimedia (MBMS) UE y portador de MBMS afectados por el reinicio. El almacenamiento SGSN de datos es volátil, excepto según se especifica en esta subcláusula. El SGSN mantiene en la memoria volátil un contador GGSN Restart para cada GGSN con el que el SGSN está en contacto, y en contadores SGSN Restart de memoria no volátil que se relacionan con cada GGSN con el que el SGSN está en contacto. Los contadores de reinicio de SGSN se incrementarán y todos los contadores de reinicio de GGSN se borrarán inmediatamente después de que se haya reiniciado el SGSN.  El contador de reinicio puede ser común a todos los GGSN o puede haber un contador separado para cada GGSN.

El GGSN realiza una función de sondeo (solicitud de eco y respuesta de eco) hacia los SGSN con los que el GGSN está en contacto. El contador de reinicio de SGSN se incluirá en la respuesta de eco. Si el valor recibido en el GGSN difiere del almacenado para ese SGSN, el GGSN considerará que el SGSN se ha reiniciado (véase 3GPP TS 29.060). Los contadores de reinicio de GGSN se actualizarán en el SGSN al valor recibido en el primer mensaje de eco procedente de cada GGSN después de que se haya reiniciado el SGSN.

Cuando el GGSN detecte un reinicio en un SGSN con el que tenga activados los contextos PDP, eliminará todos estos contextos PDP . Además, el nuevo valor del contador SGSN Restart recibido en la respuesta de eco del SGSN reiniciado se actualizará en el GGSN.