'GTP'

GTP' (GTP prime) es un protocolo basado en IP que se utiliza en redes GSM y UMTS . Se puede utilizar con UDP o TCP . GTP' utiliza la misma estructura de mensajes que GTP (GTP-C, GTP-U), pero es en gran medida un protocolo independiente. GTP' utiliza el puerto UDP/TCP registrado 3386.

El GTP se puede utilizar para transportar datos de tarificación desde la "Función de datos de tarificación" (CDF) de la red GSM o UMTS hasta la "Función de pasarela de tarificación" (CGF). En la mayoría de los casos, esto debería significar desde muchos elementos de red individuales, como los GGSN, hasta un ordenador centralizado que luego envía los datos de tarificación de forma más cómoda al centro de facturación del operador de red.

'GTP' se utiliza en la interfaz Ga dentro de la definición de red central GPRS 3GPP .

GTP' reutiliza aspectos de GTP, aunque, para citar 3GPP TS 32.295, "solo se reutiliza parcialmente el plano de señalización de GTP". ^[1] GTP' define un encabezado diferente, mensajes adicionales, valores de campo, así como un protocolo de sincronización para evitar perder o duplicar los CDR en caso de fallo de CGF o SGSN / GGSN . Los CDR transferidos, si siguen los estándares 3GPP, se codifican en ASN.1 .

Los encabezados v1 y v2 de GTP contienen los siguientes campos

Versión

El primer campo de encabezado de un paquete GTP es el campo de versión de 3 bits. Para GTP' v2, este tiene un valor de 2 (de ahí el nombre GTP' v2).

Tipo de protocolo (PT)

un valor de 1 bit que diferencia GTP' (valor 0) de GTP (valor 1).

Reservado

un campo reservado de 3 bits (deben ser 1).

Longitud del encabezado (longitud HDR)

un valor de 1 bit que para la versión 0 de GTP indica si se utiliza un encabezado de 20 bytes (valor 0) (como en GTP ) o este encabezado de 6 bytes. Este bit debe estar sin configurar (valor 0) para las versiones posteriores de GTP y en estas no indica la longitud del encabezado ya que este siempre debe ser de 6 bytes.

Tipo de mensaje

Un campo de 8 bits que indica el tipo de mensaje. Valores posibles:

Longitud

Un campo de 16 bits que indica la longitud del paquete que está encapsulando GTP' (sin incluir el encabezado GTP' en sí).

Número de secuencia

Un campo de 16 bits que identifica de forma única este paquete y permite la detección de pérdida o duplicación.

GTP' utiliza los mensajes Versión GTP no compatible, Solicitud de eco y Respuesta de eco sin cambios, pero agrega los siguientes mensajes

• Solicitud de nodo activo
• Respuesta de nodo activo
• Solicitud de redirección
• Respuesta de redirección
• Solicitud de transferencia de registros de datos
• Respuesta de transferencia de registro de datos

Los mensajes Node Alive se utilizan para avisar a otros componentes de la red que un nodo ha iniciado el servicio. La solicitud se envía desde el nodo que se está iniciando y, por lo tanto, proporciona un método más rápido para volver a habilitar el servicio que el sondeo mediante Echo Request/Response. Este mensaje también se puede utilizar para avisar de que otros nodos vuelven a estar en servicio y (en la versión 2 de GTP) para avisar de la dirección IPv6 del CGF.

Los mensajes de redirección se utilizan para:

1. desviar el flujo de CDR de los CDF ( SGSN / GGSN ) a otro CGF cuando el remitente se retira del servicio (por mantenimiento/falla).
2. Informar que el CGF ha perdido su conexión a un sistema descendente

En cualquier caso, los CDF reciben más información sobre una falla inminente o inmediata que la que recibirían si el CDF estuviera sondeando utilizando mensajes de solicitud de eco.

Este mensaje contiene detalles sobre la causa y, opcionalmente, direcciones de un CGF alternativo.

Los mensajes de transferencia de registros de datos se utilizan para transportar de manera confiable los CDR desde el punto de generación ( SGSN / GGSN ) al almacenamiento no volátil en el CGF.

Cada mensaje de solicitud de transferencia de registro de datos puede contener un mensaje de uno de cuatro tipos:

1. Enviar paquete de registro de datos: este mensaje contiene cero o más CDR. Los CDR pueden codificarse en ASN.1 mediante BER o, con menor frecuencia, PER .
2. Enviar paquete de registro de datos posiblemente duplicado: este mensaje contiene uno o más CDR y este mensaje se ha enviado previamente a otro CGF.
3. Cancelar paquete de registro de datos: este mensaje ordena al CGF que elimine uno o más paquetes de registro de datos de la cola pendiente de "posiblemente duplicados" del CGF.
4. Liberar paquete de registro de datos: este mensaje ordena al CGF que escriba el contenido de uno o más paquetes de registro de datos de la cola pendiente "posiblemente duplicada" del CGF.

Existe un mecanismo para intentar evitar la pérdida o escritura de cualquier CDR duplicado. Esto se describe con cierto detalle en 3GPP TS 32.295. La premisa básica es que cada paquete está secuenciado y, si no se reconoce individualmente, se reenvía hasta que lo reconozca cualquier CGF. Los paquetes de registro de datos normales se escriben inmediatamente en un almacenamiento no volátil (por ejemplo, un disco), pero los paquetes reenviados se marcan como "posiblemente duplicados" y entran en una cola especial que no se escribe inmediatamente en un almacenamiento no volátil; se requiere una segunda confirmación del CDF.

La capacidad de enviar una solicitud de transferencia de registro de datos que contenga cero CDR se utiliza como prueba para detectar el éxito o el fracaso del CGF en tener ya registros escritos asignados a ese número de secuencia y es una parte importante del mecanismo mencionado anteriormente.

La respuesta de transferencia de registro de datos reconoce la recepción de uno o más mensajes de transferencia de registro de datos; las respuestas se pueden agrupar por razones de eficiencia, pero se deben enviar con mayor frecuencia que el tiempo de espera de envío de CDF.

El reconocimiento incluye una causa y puede ser un rechazo de los registros contenidos.

• Acceso directo a las especificaciones numeradas del 3GPP
• Función de pasarela de carga de código abierto (CGF)