Cuando los ingenieros se encuentran por primera vez con las interfaces del núcleo 5G, es habitual empezar memorizando de N1 a N50: las funciones de red de ambos extremos, el protocolo utilizado y el equivalente más cercano en 4G. Este enfoque puede ayudar al principio, pero pronto resulta insuficiente durante el despliegue, el análisis de señalización y la resolución de problemas. En la práctica, las preguntas más útiles son: ¿esta interfaz pertenece al acceso, a la gestión de sesiones, al control de políticas o al plano de usuario? ¿Transporta NAS, GTP-U, PFCP o un servicio SBI? Y cuando aparece un problema, ¿qué ruta de control debe seguirse a continuación?

Esta es también una de las diferencias arquitectónicas más importantes entre 5GC y EPC. 5G no se limita a renombrar interfaces como S1, S11, Gx y S6a. En su lugar, conserva varios puntos de referencia e introduce la arquitectura basada en servicios, o SBA, que permite a las funciones de red del plano de control interactuar mediante llamadas de servicio. Por ello, conviene analizar las interfaces 5GC tanto desde la perspectiva de los puntos de referencia como desde la perspectiva de los servicios SBA.

Cómo entender la SBA y la arquitectura de puntos de referencia

Hay dos formas útiles de observar 5GC. La primera es la arquitectura tradicional de puntos de referencia, que describe la relación lógica entre dos entidades funcionales, como N1 entre el UE y el AMF, N2 entre el gNB y el AMF, N3 entre el gNB y el UPF, y N4 entre el SMF y el UPF. La segunda es la visión SBA, en la que funciones del plano de control como AMF, SMF, PCF, UDM, AUSF, NSSF, NEF y NRF se consideran productores y consumidores de servicios.

Estas dos visiones no se contradicen. El modelo de puntos de referencia resulta útil para seguir rutas de señalización de extremo a extremo, mientras que la SBA permite comprender con mayor claridad el descubrimiento dinámico de funciones de red, la invocación de servicios y su ampliación.

N2, por ejemplo, presenta una relación de extremos muy clara: el gNB se conecta al AMF y utiliza NGAP para transportar señalización NAS y admitir la gestión de conexiones. N3 conecta el gNB con el UPF y transporta tráfico del plano de usuario mediante GTP-U. Las interfaces de este tipo presentan una ruta punto a punto claramente definida.

Sin embargo, cuando el AMF accede al UDM, AUSF o PCF, la atención se desplaza hacia los servicios expuestos por esas funciones de red. N8 se utiliza entre AMF y UDM para obtener información de suscripción de gestión de movilidad, N12 admite la gestión de autenticación entre AMF y AUSF, y N15 permite al AMF obtener políticas relacionadas con la movilidad. Estas relaciones reflejan la migración del plano de control de 5GC desde protocolos dedicados tradicionales hacia interacciones de servicio basadas en HTTP/2.

Esto significa que, al analizar capturas de paquetes o diagramas de arquitectura, los ingenieros no deben tratar una interfaz como N8 simplemente como una conexión física fija. Es más importante determinar qué NF consume qué servicio, cómo se descubrió la instancia de servicio y a qué fase del procedimiento de servicio pertenece la transacción HTTP/2.

¿Cómo se pueden agrupar las interfaces principales?

En lugar de memorizar los números de interfaz uno por uno, resulta más práctico agruparlos según la función de red a la que dan soporte. Cuando aparece un mensaje de señalización, los ingenieros pueden identificar primero la categoría funcional y después reducir el análisis hasta la interfaz concreta.

Rutas de acceso y plano de usuario

N1, N2 y N3 forman el grupo de interfaces más básico del lado de acceso 5G. N1 funciona entre el UE y el AMF y transporta información de gestión de movilidad y gestión de sesiones dentro de 5G NAS. N2 conecta el gNB y el AMF, utiliza NGAP para transportar señalización NAS y admite la gestión de conexiones. N3 conecta el gNB y el UPF y transporta el tráfico real del plano de usuario mediante GTP-U.

Dentro de la red central, los UPF pueden seguir reenviando tráfico de usuario por N9 mediante GTP-U, mientras que el UPF se conecta a la red de datos externa, o DN, a través de N6. El tráfico de N6 ya no es señalización de control específica de 5G; se trata de tráfico IP de capa de aplicación, como contenido web, imágenes, vídeo y otros datos de usuario.

Por tanto, si el registro del UE se realiza correctamente y la sesión PDU se establece, pero el tráfico de aplicación sigue sin pasar, la resolución de problemas normalmente debe dejar el plano de control del AMF y centrarse en N3, el comportamiento de reenvío del UPF, N6 y la DN externa.

Control de sesión y del plano de usuario

N4 es una de las interfaces de control más importantes de 5GC. Funciona entre el SMF y el UPF y utiliza PFCP. El SMF gestiona el control de sesión y el UPF realiza el reenvío de paquetes, por lo que N4 se emplea para instalar reglas de reenvío y controlar el comportamiento del plano de usuario.

N11 conecta el AMF y el SMF y admite principalmente la señalización de gestión de sesiones PDU. Cuando un UE inicia el establecimiento de una sesión PDU, el AMF envía la solicitud de gestión de sesión al SMF para su procesamiento posterior. Si el registro se completa pero falla el establecimiento de la sesión PDU, N11 y los procedimientos posteriores del SMF suelen ser puntos importantes de diagnóstico.

N16 admite interacciones entre instancias de SMF, incluidos procedimientos relacionados con la reselección de SMF. En comparación con EPC, 5GC separa las funciones de control en un mayor número de NF independientes. Las responsabilidades que antes se concentraban en MME, SGW o PGW se distribuyen entre funciones como AMF, SMF, PCF y UDM, creando nuevas relaciones de servicio.

Políticas, autenticación y datos de suscripción

El control de políticas se centra principalmente en el PCF. N7 conecta el SMF y el PCF y se utiliza para solicitar políticas relacionadas con la gestión de sesiones. N5 funciona entre el PCF y el AF y transporta parámetros y requisitos de servicio a nivel de aplicación. N15 permite al AMF obtener políticas relacionadas con la movilidad.

En cuanto a los datos de suscripción, N8 permite al AMF acceder al UDM y recuperar información de suscripción de gestión de movilidad, mientras que N10 conecta el SMF y el UDM para obtener datos de suscripción relacionados con la gestión de sesiones. La autenticación se separa además en N12 entre AMF y AUSF y N13 entre AUSF y UDM.

Esta separación es especialmente importante. En EPC, el HSS gestionaba una gran parte de las funciones de datos de suscriptor y autenticación. En 5GC, las responsabilidades se distribuyen de forma más precisa entre UDM, AUSF y las funciones de almacenamiento de datos relacionadas. Cuando falla la autenticación, ya no basta con comprobar si existen datos del suscriptor. También hay que determinar si el fallo se produjo cuando el AMF inició la autenticación, durante el procesamiento en AUSF o cuando AUSF intentó recuperar la información necesaria del UDM.

¿Qué gestionan las interfaces de servicio avanzadas?

La escalabilidad del modelo de interfaces 5GC se aprecia con especial claridad más allá de N1 a N16. A medida que se introducen la segmentación de red, la exposición de capacidades, el análisis de red, el roaming y la desacoplación de datos, se establecen más interfaces alrededor de funciones de red independientes.

N22 conecta el AMF y el NSSF para la selección de segmentos de red. N34 conecta NSSF y NWDAF para que el análisis de red pueda respaldar decisiones relacionadas con segmentos. NWDAF también puede proporcionar información analítica al PCF a través de N23, permitiendo que los datos analíticos ayuden en las decisiones de políticas. Como resultado, el control de políticas ya no necesita depender únicamente de información estática de suscripción y reglas predefinidas.

La exposición de capacidades implica principalmente al NEF. N29 funciona entre SMF y NEF, mientras que N30 conecta NEF y PCF. N33 admite la invocación de servicios entre las API y el AF. Por tanto, NEF ocupa una posición importante entre las aplicaciones externas y las capacidades de la red central, proporcionando una forma controlada de exponer funciones de red a los servicios del lado de aplicación.

El almacenamiento de datos también se separa en mayor medida. N35 conecta UDM y UDR para almacenar datos de suscripción, N36 conecta PCF y UDR para almacenar datos de políticas, y N37 permite que NEF acceda a UDR para datos relacionados con la exposición de capacidades y las aplicaciones. UDSF también se utiliza para almacenar datos no estructurados, favoreciendo la separación entre funciones de cómputo y almacenamiento.

En escenarios de roaming e interconexión entre operadores, aparecen interfaces adicionales como N24 entre el PCF visitado y el PCF de origen, N27 entre el NRF visitado y el NRF de origen, N31 entre V-NSSF y H-NSSF, y N32 entre V-SEPP y H-SEPP. SEPP proporciona control de seguridad en los límites entre operadores. Estas interfaces pueden no aparecer con frecuencia en un entorno de pruebas local de un único operador, pero son importantes al analizar arquitecturas de roaming.

Las funciones de tarificación también están pasando del modelo tradicional basado en Diameter a interacciones basadas en servicios. N28 conecta PCF y CHF para que la información relacionada con la tarificación pueda respaldar las decisiones de reglas PCC, mientras que N40 conecta SMF y CHF. N41 a N49 están reservadas dentro del intervalo correspondiente de especificaciones. Otra interfaz especializada es N50, que conecta AMF y CBCF para servicios de alerta pública y avisos de desastre.

¿Qué debe tenerse en cuenta al mapear 5GC con EPC?

La experiencia con EPC es muy útil al pasar de 4G a 5G, pero la relación no debe tratarse como una sustitución mecánica uno a uno. Las similitudes entre las interfaces 5GC y EPC son principalmente referencias funcionales y no equivalencias exactas.

Algunos mapeos son relativamente intuitivos. N2 puede compararse funcionalmente con S1-MME, mientras que N3 se asemeja a S1-U. N4 es funcionalmente similar a Sxa, Sxb y Sxc en una arquitectura EPC basada en CUPS. N7 puede compararse con Gx desde la perspectiva del control de políticas, mientras que N5 ayuda a entender la función de política de aplicación asociada tradicionalmente con Rx.

También pueden observarse patrones de migración similares en las funciones de suscripción y autenticación. N8 puede compararse funcionalmente con parte de la interacción S6a entre MME y HSS. N14, que admite la gestión de movilidad entre AMF, puede compararse con S10 entre MME, mientras que N17 para la comprobación de identidad del equipo corresponde funcionalmente a la interacción S13 entre MME y EIR.

Sin embargo, muchas interfaces 5GC no tienen un equivalente directo en 4G. Entre los ejemplos se incluyen N22 para selección de segmentos, N23 para análisis de red, N27 para descubrimiento NRF entre dominios y las interfaces relacionadas con el almacenamiento de datos basado en UDR. Estas relaciones aparecieron como resultado de la arquitectura basada en servicios y del mayor desacoplamiento funcional de 5GC.

Por ello, un método de migración más adecuado consiste en comparar primero las funciones y después los mecanismos de señalización, en lugar de forzar la correspondencia de cada interfaz N con una interfaz S o un punto de referencia Diameter. La evolución de los protocolos es especialmente significativa: la señalización del plano de control EPC dependía en gran medida de Diameter y GTPv2, mientras que muchas interacciones del plano de control 5GC utilizan ahora servicios SBI basados en HTTP/2.

Un enfoque práctico para analizar interfaces 5GC

En el análisis real de señalización 5GC, suele ser más eficaz trabajar hacia atrás desde el síntoma del servicio que avanzar desde un número de interfaz. Si el UE no puede registrarse, hay que empezar por N1, N2 y los procedimientos posteriores de autenticación y datos de suscriptor del AMF. Si el registro se completa pero falla la sesión PDU, se continúa con N11, SMF, N7, N10 y N4. Si la sesión PDU se establece pero el tráfico de usuario no puede llegar a la red de datos, la atención debe desplazarse a N3, el reenvío del UPF y N6.

Para problemas relacionados con políticas, se sigue con N7 y la cadena de señalización relacionada con PCF. Para problemas de selección de segmentos, el foco debe ponerse en N22 entre AMF y NSSF. Para la exposición de capacidades o requisitos de políticas impulsados por aplicaciones, el análisis debe ampliarse hacia las interfaces relacionadas con NEF, AF y PCF. Una vez establecido un mapeo de cuatro niveles de “etapa del servicio — función de red — interfaz — protocolo”, las decenas de interfaces N resultan mucho más fáciles de interpretar.

Desde el estudio de la arquitectura hasta la resolución de problemas en una red en producción, lo más importante del análisis de interfaces 5GC es comprender la relación entre las funciones. La capa de acceso introduce el UE en la red central, la gestión de sesiones establece la sesión PDU, los servicios de políticas y suscripción determinan cómo debe tratarse esa sesión, el plano de usuario transporta el tráfico real de aplicaciones y la SBA permite que las funciones del plano de control colaboren mediante interacciones basadas en servicios. Comprender esta lógica de extremo a extremo aporta más valor de ingeniería que memorizar una tabla completa de interfaces.

Preguntas frecuentes

¿Un número de interfaz N más alto significa una función más nueva?

No. Los números de interfaz N se utilizan para identificar puntos de referencia lógicos y no indican generación tecnológica, importancia ni orden cronológico. N1, N2 y N3 se encuentran entre las interfaces 5GC más fundamentales, mientras que los números superiores incluyen tanto relaciones funcionales más recientes como puntos de referencia reservados.

¿Todas las interfaces del plano de control 5GC utilizan HTTP/2?

No. Muchas interacciones del plano de control relacionadas con SBA utilizan HTTP/2, pero 5GC incluye otros protocolos. N2 utiliza NGAP, N3 y N9 utilizan GTP-U, N4 utiliza PFCP y la comunicación entre UE y AMF también implica 5G NAS. Por tanto, la resolución de problemas debe comenzar identificando el tipo de interfaz antes de elegir el método de análisis de protocolo adecuado.

¿Por qué a veces no aparece el nombre de la interfaz N en las capturas de paquetes?

Los nombres de interfaz N representan puntos de referencia lógicos de la arquitectura. Las capturas de paquetes muestran normalmente el protocolo real, como HTTP/2, NGAP, PFCP o GTP-U, junto con las direcciones IP de las funciones de red que se comunican. Por tanto, la interfaz N lógica debe identificarse a partir de las funciones de los dos NF y del procedimiento de servicio que se está analizando.

¿Una red de pruebas 5GC necesita desplegar todas las interfaces definidas?

No. Las interfaces que aparecen realmente dependen de la escala de la red, los servicios habilitados y de si el despliegue admite funciones como roaming, segmentación de red, exposición de capacidades, análisis de red o servicios de alerta pública. El registro básico y la conectividad de datos solo utilizan una parte del marco completo de interfaces 5GC.