El Protocolo de control de reenvío de paquetes ( PFCP ) es un protocolo 3GPP utilizado en la interfaz Sx / N4 entre el plano de control y la función del plano de usuario, especificado en TS 29.244. [1] Es uno de los principales protocolos introducidos en la Red Núcleo Móvil de Próxima Generación 5G (también conocida como 5GC [2] ), pero también se utiliza en el EPC 4G / LTE para implementar Control y Separación del Plano de Usuario (CUPS). [3]El PFCP y las interfaces asociadas buscan formalizar las interacciones entre los diferentes tipos de elementos funcionales utilizados en las redes centrales móviles desplegadas por la mayoría de los operadores que brindan servicios 4G, así como 5G, a los suscriptores móviles. Estos 2 tipos de componentes son:
- Los elementos funcionales del plano de control (CP), que se ocupan principalmente de los procedimientos de señalización (por ejemplo, procedimientos de conexión a la red, gestión de las rutas del plano de datos de usuario e incluso la prestación de algunos servicios ligeros como SMS )
- El Plano-datos de usuario (UP) de elementos funcionales, la manipulación en su mayoría el reenvío de paquetes, en base a las reglas establecidas por los elementos de CP (por ejemplo, de paquetes de reenvío para IPv4 , IPv6 - o posiblemente incluso Ethernet con futuro 5G implementaciones - entre los distintos inalámbricos soportados RANs y la PDN que representa Internet o una red empresarial).
El alcance de PFCP es similar al de OpenFlow , sin embargo, fue diseñado para servir al caso de uso particular de Mobile Core Networks .
PFCP también se utiliza en la interfaz entre el plano de control y las funciones del plano de usuario de un BNG desagregado , según lo definido por BroadBand Forum en TR-459 .
Descripción general
Aunque similar a GTP en conceptos e implementación, PFCP es complementario. Proporciona los medios de control para que un componente de señalización del plano de control gestione el procesamiento y reenvío de paquetes realizado por un componente del plano de usuario. Las puertas de enlace de paquetes EPC o 5G típicas están divididas por el protocolo en 2 partes funcionales, lo que permite una evolución y escalabilidad más natural.
El protocolo PFCP se utiliza en las siguientes interfaces centrales móviles 3GPP :
- Sxa - entre SGW-C y SGW-U
- Sxb - entre PGW-C y PGW-U
- Sxc: entre TDF-C y TDF-U (función de detección de tráfico)
- N4 - entre SMF y UPF
Nota: Sxa y Sxb se pueden combinar, en caso de que se implemente una SGW / PGW fusionada.
Funcionalidad
El elemento funcional del plano de control (por ejemplo, PGW-C, SMF) controla el procesamiento y reenvío de paquetes en los elementos funcionales del plano de usuario (por ejemplo, PGW-U, UPF), estableciendo, modificando o eliminando sesiones PFCP.
Los paquetes del plano de usuario se reenviarán entre las funciones CP y UP encapsulando los paquetes del plano de usuario mediante encapsulación GTP-U (véase 3GPP TS 29.281 [3]). Para reenviar datos desde la función UP a la función CP, la función CP proporcionará PDR (s) por contexto de sesión PFCP, con el PDI identificando el tráfico del plano de usuario para reenviar a la función CP y con un FAR configurado con la interfaz de destino " Lado de la función CP "y configurado para realizar la encapsulación GTP-U y reenviar los paquetes a un GTP-u F-TEID asignado de forma única en la función CP por sesión PFCP y PDR. La función CP identificará entonces la conexión PDN y el portador al que pertenecen los datos reenviados por el F-TEID en el encabezamiento del paquete de encapsulación GTP-U. Para reenviar datos de la función CP a la función UP, la función CP debe proporcionar uno o más PDR por contexto de sesión PFCP, con el PDI configurado con la interfaz de origen "lado de función CP" e identificando el GTP-u F- TEID asignado de forma única en la función UP por PDR, y con un FAR configurado para realizar la desencapsulación GTP-U y reenviar los paquetes al destino previsto. También se pueden configurar URR y QER.
Por sesión se envían múltiples PDR, FAR, QER, URR y / o BAR.
A continuación, se muestran los principales conceptos utilizados, organizados en su modelo de asociación lógica:
- Las PDR (reglas de detección de paquetes) contienen información para hacer coincidir los paquetes de datos con ciertas reglas de procesamiento. Se pueden combinar tanto la encapsulación externa como los encabezados internos del plano de usuario. Las siguientes reglas se pueden aplicar a la coincidencia positiva:
- FAR: Reglas de acción de reenvío: si los paquetes que coinciden con los PDR deben descartarse, reenviarse, almacenarse en búfer o duplicarse, incluido un activador para la notificación del primer paquete; incluye encapsulación de paquetes o reglas de enriquecimiento de encabezados. En caso de almacenamiento en búfer, se pueden aplicar las siguientes reglas:
- BAR: Reglas de acción de almacenamiento en búfer: cuántos datos almacenar en búfer y cómo notificar al plano de control.
- QER ( Reglas de aplicación de QoS ): reglas para proporcionar control de puerta y control de QoS, marcado de nivel de servicio y flujo.
- Las URR (reglas de informes de uso) contienen reglas para contar y notificar el tráfico manejado por la función del plano de usuario, generando informes para habilitar la funcionalidad de cobro en las funciones del plano de control.
- FAR: Reglas de acción de reenvío: si los paquetes que coinciden con los PDR deben descartarse, reenviarse, almacenarse en búfer o duplicarse, incluido un activador para la notificación del primer paquete; incluye encapsulación de paquetes o reglas de enriquecimiento de encabezados. En caso de almacenamiento en búfer, se pueden aplicar las siguientes reglas:
Mensajes
Desplazamiento de bit / byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Bytes 0..3 | Versión 1) | (0 de repuesto) | MP | S | Tipo de mensaje | Longitud del mensaje (en bytes, sin incluir los primeros 4) | ||||||||||||||||||||||||||
Bytes 4..11 | si (bandera S activada) entonces SEID; de lo contrario, faltan estos bytes | |||||||||||||||||||||||||||||||
Bytes 8..11 | ||||||||||||||||||||||||||||||||
Bytes 4..7 o 12..15 | Secuencia de números | si (bandera MP establecida) entonces Mensaje Prioridad; else (sobra 0s) | (0 de repuesto) | |||||||||||||||||||||||||||||
Bytes 8 .. (MsgLen + 4) o 16 .. (MsgLen + 4) | Cero o más elementos de información |
Desplazamiento de bit / byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Bytes 0..3 | Tipo | Longitud de IE (en bytes, sin incluir los primeros 4) | ||||||||||||||||||||||||||||||
Bytes 4..IELen + 4 | si (Tipo> = 32768), entonces Enterprise-ID; de lo contrario, esto es parte de la carga útil | Carga útil (cont.) ... | ||||||||||||||||||||||||||||||
Carga útil cont. ... |
Los IE se definen por tener una codificación patentada o agrupados. Los IE agrupados son simplemente una lista de otros IE, codificados uno tras otro como en la carga útil del mensaje PFCP.
Los tipos de IE 0..32767 son específicos de 3GPP y no tienen un conjunto de ID de empresa. Los tipos de IE 32768..65535 se pueden utilizar mediante una implementación personalizada y el Enterprise-ID debe establecerse en los códigos de empresa privada de IANA SMI Network Management [4] de la parte emisora.
Mensajes
Tipo de mensaje | Mensaje | Aplicabilidad de la interfaz | Dirección | Propósito | |||||
---|---|---|---|---|---|---|---|---|---|
Pedido | Respuesta | Sxa | Sxb | Sxc | N4 | Pedido | Respuesta | ||
0 | (Reservado) | ||||||||
(1..49) | Mensajes relacionados con el nodo | ||||||||
1 | 2 | Latido del corazón | X | X | X | X | CP ↔ ARRIBA | Opcionalmente se puede usar entre pares de comunicación que tengan una asociación establecida, para verificar si el otro nodo está vivo. Se utiliza una marca de tiempo de recuperación para detectar si el otro par se ha reiniciado. | |
3 | 4 | Gestión de PFD | - | X | X | X | CP → ARRIBA | ARRIBA → CP | Característica opcional, para aprovisionar PFD por identificador de aplicación, fuera de las sesiones regulares de PFCP. |
5 | 6 | Configuración de asociación | X | X | X | X | CP ↔ ARRIBA | Configurar y actualizar una asociación entre elementos funcionales CP y UP. Incluye una lista de características opcionales, para informar a los otros elementos sobre las capacidades; también se pasan otros elementos de configuración. No se deben intercambiar mensajes relacionados con la sesión antes de este procedimiento. Si bien la liberación de asociación solo es activada por el CP, la UP puede solicitarla como parte de la solicitud de actualización de asociación. | |
7 | 8 | Actualización de la asociación | X | X | X | X | CP ↔ ARRIBA | ||
9 | 10 | Liberación de asociación | X | X | X | X | CP → ARRIBA | ARRIBA → CP | |
- | 11 | Versión no admitida | X | X | X | X | CP ↔ ARRIBA | Respuesta de error a todas las solicitudes que no cubren las versiones implementadas (actualmente solo la versión 1 definida). | |
12 | 13 | Informe de nodo | X | X | X | X | ARRIBA → CP | CP → ARRIBA | Enviado por la función UP para informar información que no forma parte de una sesión, pero que es potencialmente general (por ejemplo, falla de ruta del plano de usuario). |
14 | 15 | Eliminación del conjunto de sesiones | X | X | - | CP → ARRIBA | ARRIBA → CP | Enviado por la función CP para indicar un fallo parcial, solicitando el borrado de todas las sesiones afectadas. | |
(50..99) | Mensajes relacionados con la sesión | ||||||||
50 | 51 | Establecimiento de la sesión | X | X | X | X | CP → ARRIBA | ARRIBA → CP | Utilizado por el CP para configurar, modificar y eliminar sesiones que consisten en conjuntos de reglas para procesar y reenviar el tráfico UP. Estos son el mensaje funcional principal del dominio de aplicación PFCP. El UP puede incluir información de Informe de uso en la respuesta, de modo que se evitaría un mensaje de Informe de sesión adicional. |
52 | 53 | Modificación de sesión | X | X | X | X | |||
54 | 55 | Eliminación de sesión | X | X | X | X | |||
56 | 57 | Informe de sesión | X | X | X | X | ARRIBA → CP | CP → ARRIBA | Informe de uso UP Información de informe basada en el procesamiento de paquetes y procedimientos de reenvío: datos de enlace descendente (notificación de nuevos paquetes en cola), informe de uso (información basada en volumen, tiempo, etc., para fines de carga), errores y / o indicaciones de inactividad. |
(100..255) | Otros mensajes |
Transporte
Muy similar a GTP-C , PFCP usa UDP . El puerto 8805 está reservado. [5]
Para mayor confiabilidad, se emplea una estrategia de retransmisión similar a la del GTP-C , y los mensajes perdidos se envían N1 veces a intervalos T1. Las transacciones se identifican mediante el número de secuencia de 3 bytes de longitud, la dirección IP y el puerto del par de comunicación.
El protocolo incluye un modelo propio de solicitud / respuesta de latido del corazón, que permite monitorear la disponibilidad de los pares de comunicación y detectar reinicios (mediante el uso de un elemento de información de marca de tiempo de recuperación).
Para intercambios de paquetes en el plano de usuario entre los elementos funcionales del plano de usuario y control, GTP-U para la interfaz Sx-u o, alternativamente, una encapsulación UDP o Ethernet más simple para la interfaz N4-u (por confirmar, ya que los estándares aún están incompletos) .
Ver también
Notas
- ^ 3GPP TS 29.244 LTE; Interfaz entre el plano de control y el plano de usuario de los nodos EPC
- ^ "La red central 5G (5GC) - Parte 1 - Entidades de red" .
- ^ Flynn, Kevin. "Control y Separación del plano de usuario de los nodos EPC (CUPS)" . www.3gpp.org .
- ^ https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers
- ^ "Registro de número de puerto de nombre de servicio y protocolo de transporte" . www.iana.org .