El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
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.
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:
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.
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:
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.
Esta sección describe cuatro escenarios en los que puede producirse un error de Código de causa 192.
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.
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.