Tecnología inalámbrica / Movilidad : Gateway GPRS Support Node (GGSN)

Comportamiento GGSN con los errores de activación PDP y ningunas respuestas de la generación de eco GTP

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (27 Agosto 2015) | Comentarios

Introducción

Este documento describe el comportamiento del General Packet Radio Service del gateway (GPRS) que soporta el nodo (GGSN) cuando la porción GPRS que soporta el nodo (SGSN) no responde al pedido de eco del Tunneling Protocol GPRS (GTP) que se envía del GGSN.

Contribuido por Krishna Kishore, ingeniero de Cisco TAC.

Antecedentes

Usted puede ser que experimente los altos errores de activación del protocolo de datos de paquete (PDP) en el GGSN durante un período de tiempo en que el SGSN no responde a los pedidos de eco GTP. Aquí están algunas preguntas que pudieron presentarse en este escenario:

  1. ¿Crean PDP o las peticiones de la actualización PDP del SGSN llegan el GGSN?

  2. ¿Cuando los pedidos de eco GTP fallan del GGSN al SGSNs, cómo debe el GGSN comportarse si el contexto de la actualización PDP que se envía del GGSN no recibe una respuesta?

  3. ¿Cómo un GGSN falla un PDP si no recibe una respuesta de la generación de eco GTP o una respuesta para los mensajes request de la NON-generación de eco que llegan de un SGSN para eso PDP?

  4. ¿Cómo una falta en las respuestas de la generación de eco/de la NON-generación de eco GTP afecta directamente a los errores de activación PDP?

Comportamiento GGSN

Si los mensajes no llegan el GGSN, entonces el SGSN acciona una alarma de la falla del trayecto y los cae silenciosamente. Además, si no hay respuesta de la generación de eco recibida para el pedido de eco que es iniciado por el GGSN, indica que el par está abajo, así que el GGSN localmente borra las llamadas que se relacionan con ese par.

En la demostración el soporte detalla la salida de comando, o la salida del comando verbose de las estadísticas del gtpc de la demostración, usted puede ver los contadores del descanso del req 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 usted investiga los mensajes del pedido de eco que se transfieren del GGSN al SGSN, aparece que el GGSN no recibe las respuestas de la generación de eco. Usted debe asegurarse de que los mensajes no sean caído debido a los problemas de ruteo en la red o de que el SGSN no está disponible.

El problema más común es los errores del trayecto de control, que hacen un gran número del SGSNs de itinerancia llegar a ser inalcanzable.

Si hay algunos GTP de mensaje de control (por ejemplo una petición del contexto de la actualización PDP) del GGSN que no recibe una respuesta después de que se agoten todas las tentativas, el GGSN piensa que el par es inalcanzable y derriba solamente que la sesión específica señala la causa como falla del trayecto. El contexto PDP se borra en el GGSN, pero el SGSN no se notifica. Esta cuenta 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 derriba la sesión del contexto PDP y nunca notifica el SGSN o el equipo del usuario (UE). El SGSN o el UE pudo accionar una petición del contexto de la actualización PDP, y el GGSN pudo rechazarla con un código de la causa 192 (inexistente).

Aquí está una sección que se toma de TS 29.060:

  • Si un Gprs que soporta Node(GSN) recibe un mensaje del avión del control del protocolo del Tunelización de Gprs (GTP-C) que pide la acción relacionada con un contexto PDP que el nodo de envío cree está en la existencia, pero eso no es reconocida por el nodo de recepción, el nodo de recepción enviará detrás a la fuente del mensaje, una respuesta con el valor de causa apropiado (“inexistente” o “contexto no encontrado”).  El identificador del punto final del túnel usado en el mensaje de respuesta será fijado a todos los ceros.
  • Si el SGSN recibe una respuesta del contexto de la actualización PDP con un valor de causa “inexistente”, borrará el contexto PDP.

Error del código de la causa 192

Un código de la causa 192 (o inexistente) es un error que es enviado por el GSNs en la interfaz GN. Se puebla en la causa del elemento de información de los mensajes GTP.

Éstos son los mensajes GTP que pueden tener un error del código de la causa 192:

  • Update_PDP_Context_Response

  • Delete_PDP_Context_Response

Nota: El identificador del extremo del túnel (TEID) que se utiliza en el mensaje que contiene este error será cero. Refiera a TS 29.060 para otros detalles.

Este error puede aparecer en los mensajes ya mencionados cuando es enviado por un GSN y no tiene un contexto que corresponda al que es enviado por el otro GSN. La cancelación de GSNs el contexto PDP cuando se recibe este error.

“Situaciones de ejemplo”

Esta sección describe cuatro escenarios en los cuales un error del código de la causa 192 pueda ocurrir.

  • Escenario 1 – Una falla del trayecto GTP-C ocurre entre el GSNs.

  • Escenario 2 – Un pedido de eco/un error de la respuesta ocurre entre el GSNs.

  • Escenario 3 – Hay una versión 1 (GTPv1) GTP al problema de las manos de la versión 0 GTP (GTPv0) que causa el error. Aquí está un flujo de llamada de la muestra para este escenario:

    1. Una petición del contexto del crear PDP con GTPv1 se establece.

    2. Las manos GTPv1-to-GTPv0 ocurren.

    3. La llamada en el GGSN ahora está en GTPv0.

    4. El GGSN recibe la petición del contexto de la actualización PDP con una encabezado no-cero TEID y la rechaza debido al error (inexistente).

      Nota: El SGSN debe haber olvidado el TEID, como la llamada se movió a GTPv0 (solamente las flujo-escrituras de la etiqueta existen para GTPv0, no TEIDs). Esto indica que el SGSN se aferró a la llamada GTPv1 incluso después las manos a GTPv0.

  • Escenario 4 – Se multiplica el efecto del hacia fuera-de-sincronizar TEID. Aquí tiene un ejemplo:

    1. El UE1 establece un contexto PDP; el SGSN asigna el Control-TEID-1 (C-TEID-1) como su control TEID hacia el GGSN en el contexto sgsn-UE1-ctxt. Los C-TEID para todos los mensajes en el GGSN que dirijan hacia el SGSN tienen C-TEID-1.

    2. Los descansos de un mensaje de señalización (NON-generación de eco) en el SGSN, y el SGSN limpia ese contexto sgsn-UE1-ctxt localmente. También informa al regulador de la red de radio (RNC) para limpiar. No informa al GGSN, pues trata el GGSN como abajo. 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 disponible.

    3. El UE2 después quiere establecer un contexto PDP al mismo APN y pasa con el mismo SGSN y GGSN. En el SGSN, se afecta un aparato el TEID y un contexto sgsn-UE2-ctxt se envía al GGSN. Si el número de TEIDs libre es bajo, después el TEID recientemente liberado 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 GN C-TEID. El GGSN no marca si hay TEID ya presentes para lo mismo. El GGSN entonces inicia un contexto de la cancelación PDP (DPC) para UE1 hacia el SGSN.

    5. En el SGSN, el C-TEID-1 se encuentra, junto con el contexto para él, que es sgsn-UE2-Ctxt. Una tentativa se hace para borrar ese contexto y responder al GGSN.

    6. Si hay pedidos GGSN-iniciados (actualización/cancelación PDP) los otros contextos, el SGSN responde con una causa no encontrada del contexto.

    7. El GGSN cae esa respuesta DPC para UE2 porque nunca envió una petición 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 otro UE, el problema relanza y compone el problema.

Aquí está una sección que se toma de TS 29.060:

Respuesta de la generación de eco

El mensaje será enviado como respuesta a un pedido de eco recibido.

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

El valor de un contador del reinicio salvado previamente para un par GSN puede diferenciar del valor de contador del reinicio recibido en la respuesta de la generación de eco de ese par GSN. En este caso, el GSN que envió la respuesta de la generación de eco será considerado como recomenzado por el GSN que recibió la respuesta de la generación de eco. El nuevo valor de contador del reinicio recibido será salvado por la entidad de recepción, substituyendo el valor salvado previamente para el GSN de envío.

Si el GSN de envío es un GGSN y el GSN de recepción es un SGSN, el SGSN considerará todos los contextos PDP usando el GGSN como inactivo. Para otras acciones del SGSN refiera a la sociedad de la 3ra generación Project(3GPP) Specifications(TS) técnico 23.007 [3].

Si el GSN de envío es un SGSN y el GSN de recepción es un GGSN, el GGSN considerará todos los contextos PDP usando el SGSN como inactivo. Para otras acciones del GGSN refiera a 3GPP TS 23.007 [3].

Aquí está una sección que se toma de 3GPP TS 23.007 V8.0:

Restauración de datos en el SGSN

Reinicio del SGSN

Después de que un reinicio SGSN, el SGSN borre toda la movilidad Management(MM), PDP, los servicios de multidifusión del broadcast de las multimedias (MBMS) los contextos del portador UE, y MBMS afectados por el reinicio. El almacenamiento SGSN de los datos es volátil excepto como se especifica en este subclause. El SGSN mantiene en la memoria volátil un contador del reinicio GGSN para cada GGSN con el cual el SGSN esté en el contacto, y en los contadores del reinicio de la memoria no volátil SGSN que se relacionan con cada GGSN con el cual el SGSN esté en el contacto. Los contadores del reinicio SGSN serán incrementados y todos los contadores del reinicio GGSN serán borrados inmediatamente después que el SGSN ha recomenzado.  El contador del 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 la interrogación (respuesta del pedido de eco y de la generación de eco) hacia el SGSNs con el cual el GGSN está en el contacto. El contador del reinicio SGSN será incluido en la respuesta de la generación de eco. Si el valor recibido en el GGSN diferencia del que está salvado para ése SGSN, el GGSN considerará que el SGSN ha recomenzado (véase 3GPP TS 29.060). Los contadores del reinicio GGSN serán puestos al día en el SGSN al valor recibido en el primer mensaje de eco que viene de cada GGSN después de que el SGSN haya recomenzado.

Cuando el GGSN detecta un reinicio en un SGSN con el cual haga los contextos PDP activar, borrará todos estos contextos PDP. También, el nuevo valor del contador del reinicio SGSN recibido en la respuesta de la generación de eco del SGSN recomenzado será puesto al día en el GGSN.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 119246