El núcleo 5G ya no está diseñado únicamente para comunicaciones entre personas. Los vehículos conectados, las fábricas inteligentes, los campus inteligentes, la sanidad remota, los drones y muchas otras aplicaciones verticales necesitan cada vez más influir dinámicamente en los recursos de red según las condiciones del servicio u obtener del operador información autorizada sobre el estado de la red. Si cada nuevo requisito obligara al operador a modificar manualmente la configuración del AMF, SMF, PCF, UDM y otras funciones de red, el despliegue masivo de 5G en sectores verticales sería extremadamente difícil.

Aquí entra en juego el NEF, o Network Exposure Function. Se sitúa entre el 5GC y las funciones de aplicación, o AF, y convierte las capacidades internas del núcleo en interfaces estandarizadas que pueden utilizar las aplicaciones externas. Al mismo tiempo, gestiona el control de seguridad, la traducción de información y la entrega de parámetros. Para aplicaciones de terceros, el NEF actúa como una pasarela controlada hacia el marco de capacidades del núcleo 5G del operador, no como una simple pasarela API.

Por qué 5GC necesita el NEF

El modelo de negocio de 4G estaba orientado en gran medida a B2C: la red proporcionaba conectividad y los abonados utilizaban Internet móvil para acceder a distintas aplicaciones. Con 5G, el modelo se ha ampliado hacia B2B2X. La red debe admitir no solo usuarios individuales, sino también una interacción más profunda y automatizada con plataformas utilizadas en fabricación, transporte, campus, sanidad y otros sectores verticales.

Esto plantea una pregunta importante: ¿cómo pueden las aplicaciones industriales utilizar las capacidades de red del operador de una forma segura y estandarizada?

Pensemos en una empresa industrial que quiere que los terminales de producción de una zona concreta reciban una QoS más predecible o que el tráfico de una aplicación se dirija a una red de datos local más cercana a la fábrica. Sin un mecanismo unificado de exposición de capacidades, la plataforma de aplicaciones podría tener que conectarse directamente a varias funciones del núcleo e implementar configuraciones distintas para diferentes proveedores. Esto aumentaría la complejidad de integración y expondría más interfaces internas del núcleo.

El NEF crea un límite común entre las aplicaciones industriales y el 5GC. Un AF externo no necesita comprender todos los detalles internos del AMF, SMF, PCF, UDM o UPF. Solo tiene que enviar una solicitud de servicio conforme a los estándares a través del NEF. A continuación, el NEF interactúa con las funciones de red 5GC adecuadas y devuelve el resultado al lado de la aplicación.

Este enfoque convierte algunos requisitos que de otro modo dependerían de coordinación manual y configuración estática en llamadas de servicio estandarizadas, permitiendo a los operadores exponer capacidades de red a sus socios de una forma más automatizada.

Dónde se sitúa el NEF en 5GC

El NEF se despliega entre las funciones de red 5GC y los AF. Un AF es una entidad funcional de la capa de aplicación responsable de la lógica de negocio. Puede ser una aplicación de confianza propiedad o bajo gestión del operador, o una plataforma de aplicaciones de terceros situada fuera del dominio de confianza del operador. Una aplicación de terceros no puede recibir acceso sin restricciones a las funciones internas del núcleo, por lo que la interacción controlada se gestiona a través del NEF.

Desde el punto de vista de las interfaces, el NEF conecta de hecho dos entornos distintos. Hacia el norte, atiende a AF como plataformas de vídeo, plataformas de vehículos conectados y sistemas de control industrial. Hacia el sur, se conecta a funciones internas del 5GC y se comunica con entidades como el SMF, PCF y UDM según el servicio solicitado.

El NEF evolucionó a partir del SCEF utilizado en 4G, pero su alcance es considerablemente más amplio. SCEF estaba asociado principalmente a determinados casos de uso de IoT, mientras que el NEF de 5GC admite una gama mucho mayor de aplicaciones centradas en personas y máquinas y se ha convertido en una parte importante del marco de exposición de capacidades basado en servicios.

Por diseño, el NEF hace mucho más que reenviar mensajes. Entre sus responsabilidades principales se incluyen exponer capacidades y eventos de red, aprovisionar de forma segura en la red 3GPP información procedente de aplicaciones externas, traducir información entre formatos externos e internos y recibir datos de otras funciones de red para almacenarlos o volver a exponerlos posteriormente cuando sea necesario.

Parte de la información recibida por el NEF puede almacenarse en el UDR, por lo que no tiene que quedar vinculada a una única instancia de NEF. El NEF también puede admitir funciones PFD, proporcionando la base para una detección de aplicaciones y un tratamiento de políticas más precisos.

Cómo se exponen cinco capacidades clave

El valor del NEF procede en última instancia de los servicios que puede exponer. En despliegues 5GC reales, sus principales capacidades pueden agruparse en cinco áreas: exposición de QoS, suscripciones a eventos de red, redirección del tráfico, provisión de parámetros y gestión PFD. Estas funciones corresponden a algunos de los requisitos de interacción más habituales entre aplicaciones industriales y redes de operadores.

Exposición de capacidades QoS

La exposición de capacidades QoS permite que una aplicación asociada solicite una calidad de servicio específica para un determinado flujo de servicio. Por ejemplo, una aplicación de vídeo puede estar ejecutándose ya sobre una sesión PDU existente. Si el usuario selecciona un servicio de vídeo de mayor calidad, el AF puede utilizar el NEF para solicitar una QoS mejorada para ese flujo de tráfico.

Tras recibir la solicitud, el NEF se coordina con funciones del núcleo como el PCF. El PCF aplica entonces la lógica de políticas y trabaja con el SMF y otros recursos de red para establecer el tratamiento QoS adecuado para el flujo de servicio.

La clave no consiste simplemente en asignar más ancho de banda al dispositivo. El objetivo es permitir que una aplicación exprese sus requisitos de servicio mediante una interfaz estandarizada, manteniendo al mismo tiempo las decisiones de política y la aplicación de los recursos de red bajo el control del 5GC.

Movilidad y suscripciones a eventos de red

Un AF de terceros también puede utilizar el NEF para suscribirse a eventos de red relacionados con el UE, como pérdida de conectividad, recuperación de la alcanzabilidad, ubicación actual o última conocida, estado de itinerancia, causas de fallos de comunicación y estado de entrega de datos de enlace descendente.

Estos eventos son detectados por distintas funciones del núcleo. El AMF puede detectar la alcanzabilidad del UE, la pérdida de conectividad y determinados fallos de comunicación. El UDM puede proporcionar información como el estado de itinerancia o ciertos cambios de asociación de identidad, mientras que el SMF puede informar de condiciones relacionadas con la entrega de datos de enlace descendente.

El AF no necesita conectarse directamente a cada función de red. En su lugar, crea una suscripción a eventos a través del NEF. El NEF establece después la suscripción interna necesaria con la función de red correspondiente. Cuando se produce el evento objetivo, el núcleo notifica al NEF y este reenvía la notificación del evento al AF externo de acuerdo con la suscripción.

Este mecanismo es especialmente útil para aplicaciones industriales que necesitan activar lógica de negocio automatizada en función del estado del dispositivo. En lugar de consultar continuamente la red para conocer el estado del UE, la plataforma externa puede recibir una notificación cuando realmente se produzca el evento relevante.

Redirección del tráfico

El NEF también puede recibir solicitudes de Traffic Influence de un AF y dirigir el tráfico de un UE o servicio específico hacia un Local DN, o Local Data Network. Un Local DN se identifica mediante un DNAI y suele estar asociado a computación perimetral o a servicios desplegados regionalmente.

En una fábrica automatizada, por ejemplo, un servidor de control industrial puede estar desplegado en una red local cercana al área de producción. La plataforma de aplicaciones puede solicitar a través del NEF que el 5GC ajuste la ruta del plano de usuario para que el tráfico de los dispositivos correspondientes se encamine hacia el Local DN adecuado.

El NEF no controla directamente el UPF. En su lugar, introduce el requisito en el proceso de control de políticas. A continuación, el PCF y el SMF gestionan la política y la configuración del plano de usuario. Según la situación, el SMF puede volver a seleccionar el UPF o añadir, sustituir o eliminar UPF en la ruta existente para completar la operación de redirección del tráfico.

Provisión segura de parámetros

Un AF externo también puede utilizar el NEF para proporcionar al 5GC determinados parámetros relacionados con el usuario. Esto no significa que la aplicación pueda modificar libremente los parámetros del núcleo. El conjunto de información que puede aprovisionarse está estrictamente controlado.

Entre los ejemplos habituales se encuentran Expected UE Behaviour y determinados Network Configuration Parameters. Expected UE Behaviour puede describir las características de movilidad previstas de un dispositivo, mientras que los parámetros de configuración de red pueden incluir información como el tiempo máximo de respuesta, el retardo aceptable de transmisión de datos de enlace descendente o el número recomendado de paquetes de enlace descendente que deben almacenarse en búfer cuando el UE no es alcanzable.

El NEF reenvía las solicitudes de parámetros autorizadas al UDM, que trabaja con el UDR para leer y actualizar los datos correspondientes. El AMF u otras funciones de red que se hayan suscrito a esos cambios de datos pueden recibir después los parámetros actualizados para su posterior procesamiento en la red.

Gestión PFD

PFD, o Packet Flow Description, puede entenderse como un conjunto de reglas utilizado para detectar aplicaciones. Un AF de terceros puede crear información de identificación de aplicaciones a través del NEF. Las reglas resultantes pueden almacenarse en el UDR, ser recuperadas por el SMF a través del NEF y posteriormente enviarse al UPF para la detección de aplicaciones.

En comparación con la identificación del tráfico únicamente mediante puertos o direcciones básicas, los PFD pueden describir características de aplicación más específicas. Por ejemplo, un servicio de vídeo puede identificarse mediante un patrón URL concreto u otras características del tráfico, lo que permite a la red asociar el tráfico de forma más precisa con las reglas de tratamiento de políticas adecuadas.

El verdadero valor técnico del NEF

Desde una perspectiva arquitectónica, la función más importante del NEF no es añadir otro nodo de reenvío. Su verdadero objetivo es crear una capa de exposición de capacidades gestionable. Los AF externos ven interfaces orientadas a servicios, mientras que el trabajo real dentro del 5GC sigue siendo realizado por funciones como el control de políticas del PCF, la gestión de sesiones del SMF, la gestión de datos del UDM y el procesamiento del plano de usuario del UPF.

Por este motivo, el NEF no debe considerarse una pasarela API convencional. Debe comprender la relación entre las solicitudes de negocio externas y las capacidades del núcleo 3GPP, a la vez que gestiona el control de seguridad, la traducción de información y la coordinación de procesos entre ambos lados.

El NEF tampoco sustituye a otras funciones de red. La aplicación de QoS sigue dependiendo del control de políticas y de la configuración de recursos de sesión. Los eventos de red siguen siendo detectados por la NF correspondiente. Las rutas del plano de usuario siguen siendo ajustadas por funciones como el SMF y los datos relacionados con el usuario siguen siendo mantenidos por el UDM y el UDR. La función del NEF es exponer estas capacidades internas de forma controlada y estandarizada.

Esta capacidad es especialmente importante para servicios 5G B2B2X. Las aplicaciones industriales no necesitan conocer toda la topología interna del 5GC ni crear interfaces propietarias con cada función de red. Pueden presentar sus requisitos de red mediante mecanismos de exposición estandarizados. Al mismo tiempo, el operador conserva el control del límite del núcleo y convierte capacidades de red seleccionadas en servicios que pueden utilizar socios de confianza.

En términos prácticos, el NEF ayuda al núcleo 5G a evolucionar desde una red que proporciona principalmente conectividad hacia una plataforma capaz de exponer capacidades de red directamente a aplicaciones industriales.

Preguntas frecuentes

¿Todos los AF deben desplegarse fuera de la red del operador?

No. Un AF puede ser una aplicación de confianza propiedad o bajo gestión del operador, o una aplicación de terceros situada fuera del dominio de confianza del operador. Los métodos de acceso y el tratamiento de seguridad pueden variar según el tipo de AF.

¿Los datos de negocio se almacenan siempre localmente en el NEF?

No. Parte de la información recibida por el NEF puede almacenarse en el UDR y utilizarse posteriormente por otras funciones de red o por procedimientos posteriores. Por tanto, el almacenamiento de datos no tiene que permanecer vinculado a una única instancia de NEF.

¿Un Local DN es lo mismo que un UPF?

No. Un Local DN es una red de datos local que aloja aplicaciones o servicios de datos específicos, mientras que el UPF es una función de red del plano de usuario de 5GC. El tráfico puede enrutarse a través de una ruta UPF adecuada para llegar a un Local DN determinado, pero ambos cumplen funciones distintas.

¿El UPF crea por sí mismo las reglas PFD?

No. Las reglas PFD pueden ser proporcionadas por un AF y gestionadas a través del NEF. El SMF recupera las reglas correspondientes y las entrega al UPF para lograr una detección de aplicaciones más precisa en el plano de usuario.