Guía de Operaciones de OmniNEF

Descripción general | Referencia de Configuración | Métricas y Monitoreo | Resolución de Problemas

Esta guía describe cómo OmniNEF se comporta como la puerta de enlace de exposición hacia el norte del núcleo 5G y cómo operarlo. OmniNEF es la Función de Exposición de Red definida en 3GPP TS 23.501 §6.2.5, exponiendo la API T8 (TS 29.122) / servicios Nnef (TS 29.522) hacia Funciones de Aplicación.

Tabla de Contenidos

• Descripción General de la Arquitectura
• Ciclo de Vida de la Solicitud
• Autorización y Control de Flujo
• APIs de Norte a Sur
• Interoperabilidad de Sur a Norte
• Puntos Finales de SBI
• Registro en NRF
• Notas Operativas

Descripción General de la Arquitectura

OmniNEF termina la API de norte hacia funciones AF externas y traduce cada solicitud en una operación SBI hacia un NF productor del núcleo. Se registra con el NRF como NFType NEF y utiliza el descubrimiento de NRF para resolver el UDM, PCF o UDR que atiende una solicitud dada.

Ciclo de Vida de la Solicitud

Cada solicitud de creación de recurso de norte sigue el mismo camino:

1. Autorizar el AF que llama desde su clave API y verificar que tiene derecho a la API solicitada.
2. Controlar el flujo contra el límite de solicitudes por segundo del AF.
3. Validar el cuerpo de la solicitud (identificador del UE objetivo, QoS requerida, objetivo de enrutamiento, …).
4. Descubrir el NF objetivo (UDM/PCF/UDR) del NRF y seleccionar una instancia consciente de la carga.
5. Traducir y enviar la solicitud SBI correspondiente al NF productor.
6. Almacenar el recurso creado (AF propietario, representación, URL de desmantelamiento descendente) y devolver 201 Created con un encabezado Location apuntando al recurso individual.

GET en el recurso individual devuelve la representación almacenada; DELETE desmantela el recurso en el NF productor (mejor esfuerzo) y elimina el registro del lado de NEF.

Autorización y Control de Flujo

El NEF es el límite entre AFs de terceros no confiables y el núcleo confiable, por lo que la autorización es obligatoria (TS 23.501 §6.2.5).

• Autenticación: el AF presenta una clave API como Authorization: Bearer <key> o X-Api-Key: <key>. Las claves se buscan en el registro de AF. Una clave faltante o desconocida devuelve 401.
• Derecho: cada AF está limitado a :all APIs o una lista explícita. Un AF conocido que llama a una API a la que no tiene derecho devuelve 403.
• Control de Flujo: cada AF tiene un límite de solicitudes por segundo (el suyo o el predeterminado configurado). Un AF que lo excede devuelve 429. La ventana es de un segundo deslizante.

Consulte la Referencia de Configuración para saber cómo incorporar un AF.

APIs de Norte a Sur

Capacidad	Recurso de norte	Método(s)	Sur
Eventos de Monitoreo (Nnef_EventExposure)	/3gpp-monitoring-event/v1/{scsAsId}/subscriptions	POST, GET, DELETE	UDM (Nudm_EventExposure)
Aprovisionamiento de Parámetros (Nnef_ParameterProvision)	/nnef-pp/v1/{afId}/provisionings	POST, GET, DELETE	UDM (Nudm_ParameterProvision) → UDR
Sesión de AF con QoS (Nnef_AFsessionWithQoS)	/3gpp-as-session-with-qos/v1/{scsAsId}/subscriptions	POST, GET, DELETE	PCF (Npcf_PolicyAuthorization)
Influencia de Tráfico (Nnef_TrafficInfluence)	/3gpp-traffic-influence/v1/{afId}/subscriptions	POST, GET, DELETE	PCF o UDR

Eventos de Monitoreo

Un AF se suscribe a eventos de red para un UE identificado por externalId o msisdn. Los valores de monitoringType soportados se mapean a tipos de eventos de UDM:

T8 monitoringType	UDM eventType
LOSS_OF_CONNECTIVITY	LOSS_OF_CONNECTIVITY
UE_REACHABILITY	UE_REACHABILITY_FOR_DATA
LOCATION_REPORTING	LOCATION_REPORTING
ROAMING_STATUS	ROAMING_STATUS
COMMUNICATION_FAILURE	COMMUNICATION_FAILURE
AVAILABILITY_AFTER_DDN_FAILURE	AVAILABILITY_AFTER_DDN_FAILURE

El identificador externo se mapea a un GPSI de UDM (extid-<externalId> o msisdn-<msisdn>).

Aprovisionamiento de Parámetros

Un AF aprovisiona parámetros de comportamiento esperado del UE o características de comunicación para un UE (externalId / msisdn) o un grupo (externalGroupId). Se acepta un objeto ppData explícito o los campos de aprovisionamiento de nivel superior reconocidos; el NEF los aplica a través de Nudm_ParameterProvision, que el UDM persiste en el UDR.

Sesión de AF con QoS

Un AF proporciona la dirección del UE (ueIpv4Addr / ueIpv6Addr), los flujos IP a tratar y una qosReference (o QoS solicitada). El NEF crea un Contexto de Sesión de Aplicación Individual en el PCF, que instala la política correspondiente hacia el SMF.

Influencia de Tráfico

Un AF solicita al núcleo que dirija tráfico seleccionado hacia un DNAI / ubicación de aplicación. El objetivo de enrutamiento depende del alcance:

• UE Individual (gpsi o supi presente) → una sesión de aplicación en el PCF.
• Grupo / cualquier UE (sin identificador individual) → almacenado como datos de aplicación influenceData en el UDR, que el PCF lee al construir políticas para futuras sesiones coincidentes.

Interoperabilidad de Sur a Norte

El NEF resuelve cada NF productor desde el NRF (Nnrf_NFDiscovery, filtrado por nombre de servicio) y selecciona la instancia de menor carga. Luego emite la solicitud SBI mapeada:

• POST …/nudm-ee/v1/{gpsi}/ee-subscriptions (UDM)
• PUT …/nudm-pp/v1/{gpsi}/pp-data (UDM)
• POST …/npcf-policyauthorization/v1/app-sessions (PCF)
• PUT …/nudr-dr/v1/application-data/influenceData/{id} (UDR)

Cuando un NF productor devuelve una Location, el NEF retiene la URL absoluta resuelta para que el recurso pueda ser eliminado más tarde. Para eventos de monitoreo, el NEF registra una URL de callback de notificación por suscripción con el NF productor (…/nnef-eventexposure/v1/notifications/{subId}); cuando el productor publica un informe de evento en esa callback, el NEF lo mapea a una MonitoringNotification de T8 y lo reenvía al notificationDestination almacenado del AF (la ruta de datos de exposición de eventos). El reenvío es de mejor esfuerzo. El NEF siempre reconoce la callback del productor con 204. El NEF descarta notificaciones para una suscripción desconocida o expirada. Consulte la entrada de resolución de problemas de reenvío de notificaciones.

Puntos Finales de SBI

• GET /nnef/v1/status: prueba de vida; devuelve 200 {"status":"UP"}.
• Los puntos finales de recursos de norte en la tabla de APIs de Norte a Sur.

Las rutas no coincidentes devuelven 404 con un cuerpo ProblemDetails de 3GPP.

Registro en NRF

Al iniciar, OmniNEF se registra con el NRF como NFType NEF, anunciando cuatro servicios (nnef-eventexposure, nnef-pp, nnef-afsessionwithqos, nnef-trafficinfluence) y su punto final de IP de SBI, luego envía latidos en el intervalo configurado. La capacidad y prioridad provienen de los ayudantes compartidos Omni5gEx.NRF.Config.

Notas Operativas

• HTTP Simple: el oyente de SBI sirve HTTP simple. Termine TLS externamente (un proxy inverso o malla de servicios) para cualquier exposición más allá de una red confiable.
• Estado no persistente: el registro de AF, las ventanas del limitador de tasa y el almacenamiento de recursos creados están en memoria. Al reiniciar, los AF se vuelven a sembrar desde la configuración y los recursos de norte previamente creados son olvidados por el NEF (los recursos subyacentes del núcleo NF persisten hasta que expiran o son eliminados directamente).
• El desmantelamiento descendente es de mejor esfuerzo: un DELETE siempre elimina el registro del lado de NEF incluso si el NF productor es brevemente inalcanzable; el fallo se registra.