UMTS - Protocolo de túnel GPRS
La generación de GPRS Tunneling Protocol (GTP) fue prácticamente imposible, pero tampoco es deseable darlo para el nuevo sistema, pero, por otro lado, es bastante comprensible que las mejoras también sean necesarias para poder interactuar con el mundo de PS heredado sin problemas y las funciones de soporte necesarias para el sistema más nuevo.
Protocolo de túnel GPRS (GTP)
El protocolo GTP está diseñado para tunelizar y encapsular unidades de datos y mensajes de control en GPRS. Desde su diseño a fines de la década de 1990, se puso en marcha a gran escala y se ha acumulado una sólida experiencia.
GTP para el sistema 3GPP evolucionado está disponible en dos variantes, control y plano de usuario. GTP-C gestiona la señalización del plano de control, y es necesario además del protocolo de transferencia de datos sobre la pureza del usuario, GTP-U; se llama plano de usuario. Las versiones actuales, adecuadas para EPS son GTPv1 US y GTPv2-C.
La peculiaridad de GTP es que admite la separación del tráfico dentro de su titular de túnel GTP principal, o en otras palabras, la capacidad de agruparlos y tratar a los operadores. Los extremos de los túneles GTP se identifican mediante TEID (identificadores de punto final de túnel); son asignados al nivel local para el enlace ascendente y el enlace descendente por entidades pares y se informan transversalmente entre ellos. Los TEID se utilizan en diferente granularidad mediante una conexión PDN de ejemplo específica en S5 y S8 y EU en interfaces S3 / S4 / S10 / S11.
Plano de control del protocolo de túnel GPRS
GTPv2-C se utiliza en las interfaces de señalización EPC (incluidos SGSN de al menos Rel. 8). Por ejemplo
- S3 (entre SGSN y MME),
- S4 (entre SGSN y Serving GW),
- S5 y S8 (entre Serving GW y PDN GW),
- S10 (entre dos MME) y
- S11 (entre MME y Serving GW).
En correspondencia con esto, una unidad de datos de protocolo GTPv2-C típica como se muestra en la figura anterior, la parte específica GTP está precedida por encabezados IP y UDP, consta de un encabezado GTPv2-C y una parte que contiene información variable GTPv2-C en número, longitud y formato, según el tipo de mensaje. Como el eco y la notificación de una versión de protocolo no son compatibles, la información TEID no está presente. Obviamente, la versión está firmemente establecida en 2 en esta versión del protocolo.
GTP tenía un mecanismo de encabezado de extensión heredado complejo; no se utiliza en la mayoría de GTPv2-C. El tipo de mensaje se define en el segundo byte (por lo que se puede definir un máximo de 256 mensajes para futuras extensiones). La siguiente tabla proporciona una descripción general de los mensajes GTPv2-C actualmente definidos. La longitud del mensaje se codifica en bytes 3 y 4 (medidos en bytes y no contienen los primeros cuatro bytes).
TEID es el ID del punto final del túnel, un valor único en el lado opuesto / receptor; permite la multiplexación y demultiplexación de túneles en un extremo en los casos muy frecuentes sobre un túnel GTP hay que distinguir.
| Tipo de mensaje | Mensaje | Explicación adicional |
|---|---|---|
| 0 | Reservado | Nunca debe usarse (excluido intencionalmente del protocolo, para hacer cumplir una configuración explícita) |
| 1/2 | Solicitud / respuesta de eco | Se usa para probar si una versión de GTP es compatible con el nodo remitente. |
| 3 | Indicación de versión no admitida | Contiene la última versión de GTP compatible con el nodo emisor. |
| 4/5 | Solicitud / respuesta de transferencia directa | Se utiliza para el mensaje de señalización de túnel en la interfaz S101 para un traspaso optimizado, entre HRPD access not y MME |
| 6/7 | Solicitud / respuesta de notificación | Se utiliza para notificaciones de tunelización en S101 entre el nodo de acceso HRPD y MME |
| 25/26 | Solicitud de SRVCC PS a CS | Se utiliza para activar y confirmar el inicio de SRVCC entre SGSN / MME y el servidor MSC |
| 27/28 | Notificación completa de SRVCC PS a CS | Se utiliza para indicar y confirmar la finalización de SRVCC entre el servidor MSC y SGSN / MME |
| 32/33 | Crear solicitud de sesión | Se utiliza para establecer la conectividad entre dos nodos. |
| 34/35 | Modificar solicitud de portador | Se utiliza para modificar las propiedades de un portador único o de varios, incluye información de contexto del portador |
| 36/37 | Eliminar solicitud de sesión | Derriba la sesión de control de GTP |
| 38/39 | Solicitud de notificación de cambio | Se utiliza para informar información de ubicación |
| 66/67 | Eliminar comando de portador / indicación de falla | Indique a los nodos que eliminen al portador y confirmen de nuevo |
| 68/69 | Indicación de fallo / comando de recurso portador | Se utiliza para asignar o modificar recursos. |
| 73 | Detener indicación de paginación | Enviado desde SGW al MME o SGSN |
| 95/96 | Crear solicitud / respuesta al portador | Indique a los nodos que instalen portadores y confirme |
| 97/98 | Actualizar solicitud de portador | Se utiliza para informar a los nodos del plano de control desde el plano del usuario sobre los cambios de portador. |
GTPv1-U mejorado
Solo se aplicó una pequeña pero efectiva mejora a GTP-U, y para eso no se consideró necesario fortalecer el número de versiones del protocolo. Por lo tanto, todavía esperamos GTPv1-U, pero al menos es el Rel más reciente. 8.
La pila de protocolos es esencialmente la misma que para GTPv2-C con solo el nombre de las capas y los protocolos sustituidos en consecuencia. El mecanismo del encabezado de extensión se mantiene en su lugar; permite insertar dos elementos si es necesario.
Puerto de origen UDP del mensaje desencadenante (dos octetos);
PDCP Número de PDU: relacionado con la transferencia de características sin pérdida; en este caso, los paquetes de datos deben numerarse en el EPC (dos octetos).
La mejora es la capacidad de transmitir un "mercado final" en el plano del usuario. Se utiliza en el procedimiento de traspaso entre eNodoB y da la indicación de que la vía se activa inmediatamente después del paquete de datos, por ejemplo, la función no es necesaria para pre-Rel.8 porque GTP-U no terminó en el acceso de radio nodo (es decir, no en la BS o NodeB) solo existen unos pocos mensajes. GTPv1-U, y se enumeran en la tabla anterior.
Está claro que, de hecho, es posible un tipo de señalización muy limitado a través de GTPv1-U (mecanismos de eco y etiquetado final). El único mensaje de que la transferencia de datos de usuario reales es del tipo 255, el llamado mensaje G-PDU; la única información que lleva, después del encabezado, es el paquete de datos original de un usuario o equipo externo de PDN.
No todas las instancias de túneles GTP-U se enumeran en la arquitectura de referencia (cuyo objetivo era capturar las asociaciones que ya no vivían entre los nodos de la red); son posibles túneles temporales -
Entre dos GW en servicio, aplicable para la transferencia basada en S1, en el caso de que el servicio se mueva GW;
Entre dos SGSN, corresponde al caso anterior, pero en la red PS heredada;
Entre dos RNC, aplicable para la reubicación del RNC en la red 3G PS (sin relación con el EPC, se menciona aquí solo para completar).