Guía de Operaciones de OmniUDR
OmniUDR es el Repositorio de Datos Unificado (UDR) del núcleo 5G de Omnitouch. Implementa el servicio Nudr_DataRepository (TS 29.504) y expone datos estructurados de suscriptores, políticas y contexto al UDM y PCF a través de la interfaz basada en servicios (SBI).
OmniUDR no posee datos de suscriptores. Es una fachada Nudr_DR delgada y conforme a estándares sobre el backend de aprovisionamiento REST de OmniHSS: cada lectura del repositorio de datos se traduce en el momento de la solicitud en una o más llamadas REST de OmniHSS, y la respuesta del HSS se mapea al modelo de datos Nudr de 3GPP antes de ser devuelta al consumidor. OmniUDR es la única función de red del núcleo 5G que se comunica directamente con la API REST de OmniHSS: el UDM (y, a través de él, el AUSF) accede a los datos del suscriptor llamando a OmniUDR a través de Nudr estándar, no llamando al HSS.
Debido a que el HSS es el sistema de registro, OmniUDR casi no mantiene estado persistente. Su único estado local son tres pequeños almacenes en memoria (ETS): una caché de contexto de registro de AMF y SMF (utilizada para decidir si una escritura de contexto es una creación o una actualización), un almacén de suscripciones de cambios de datos que contiene las suscripciones activas Nudr_DR subs-to-notify, y un almacén de datos de aplicación que contiene las familias de datos application-data de Nudr_DR (PFDs, influencia del tráfico, BDT). Ninguno de estos se persiste; todos se borran al reiniciar. La caché de contexto de registro se puede vaciar a través de la API de gestión.
Referencias de Rol y Especificación de 3GPP
| Especificación | Relevancia |
|---|---|
| TS 23.501 | Arquitectura del sistema 5G - rol del UDR y su relación con UDM, PCF y la capa de datos del UDM |
| TS 29.504 | Servicio Nudr_DataRepository - marco de recursos, datos de suscripción, datos de contexto, datos de políticas |
| TS 29.505 | Estructuras de datos de suscripción - suscripción de autenticación, acceso y movilidad, gestión de sesiones, selección de SMF |
| TS 29.519 | Estructuras de datos de políticas - formas de recursos de datos de políticas AM y SM |
| TS 29.503 | Servicios Nudm - el consumidor UDM cuyas procedimientos UEAU/SDM/UECM impulsan lecturas de UDR y escrituras de contexto |
| TS 29.571 | Tipos de datos comunes - PatchResult, ProblemDetails, codificaciones PLMN y S-NSSAI |
Interfaces
| Interfaz | Vinculación | Propósito |
|---|---|---|
| SBI (Nudr_DR) | {sbi_scheme}://{sbi_addr}:{sbi_port} (por defecto http://127.0.0.22:7777) | Sirve los recursos nudr-dr/v2 consumidos por el UDM y PCF |
| Backend REST de HSS | hss_api_base_url (por defecto https://127.0.0.1:8443) | Llamadas REST salientes a OmniHSS que cumplen cada lectura/actualización |
| NRF | nrf_uri | Registro de NF y latido periódico |
| API de Gestión / OAM | :8443 (HTTPS, montado bajo /api) | Estado, salud del HSS, proxy de suscriptor y acciones de OAM - ver Referencia de Configuración |
| Métricas de Prometheus | prometheus_metrics_port (por defecto 9568) | Punto final de raspado de métricas - ver Métricas |
Conjuntos de Datos Servidos
OmniUDR sirve los siguientes conjuntos de datos Nudr_DR. Cada uno se deriva en el momento de la lectura del registro del suscriptor de OmniHSS; la columna "fuente HSS" nombra los datos REST subyacentes de los que se mapea el valor.
| Conjunto de datos | Familia de recursos Nudr | Acceso | Consumidor | Fuente HSS |
|---|---|---|---|---|
| Suscripción de autenticación | subscription-data/.../authentication-data/authentication-subscription | Leer / actualizar | UDM (Nudm_UEAU) | Suscriptor key_set (Ki, OPc, AMF, SQN) o key_set_id |
| Vectores de autenticación | subscription-data/.../authentication-data/authentication-vectors | Generar (propietario) | OmniUDM | HSS generate_auth_vectors (Milenage + SQN/resync) |
| Datos de acceso y movilidad (AM) | subscription-data/.../provisioned-data/am-data | Leer | UDM (Nudm_SDM) | Perfil EPC del suscriptor UE-AMBR + NSSAI sintetizado |
| Datos de gestión de sesiones (SM) | subscription-data/.../provisioned-data/sm-data | Leer | UDM (Nudm_SDM) | Perfiles APN de EPC → configuraciones DNN, AMBR de sesión, QoS por defecto, reglas de carga |
| Datos de selección de SMF | subscription-data/.../provisioned-data/smf-selection-subscription-data | Leer | UDM (Nudm_SDM) | Lista de APN de EPC → información S-NSSAI / DNN suscrita |
| Contexto de registro de AMF | subscription-data/.../context-data/amf-3gpp-access | Escribir | UDM (Nudm_UECM) | Mapeado a la actualización de sesión de circuito del HSS (ubicación); reflejado en la caché local |
| Contexto de registro de SMF | subscription-data/.../context-data/smf-registrations/{pduSessionId} | Escribir | UDM (Nudm_UECM) | Almacenado solo en la caché local (no persistido al HSS) |
| Datos de políticas AM | policy-data/ues/{ueId}/am-data | Leer | PCF | Derivado del UE-AMBR de EPC (categorías de suscriptor gruesas) |
| Datos de políticas SM | policy-data/ues/{ueId}/sm-data | Leer | PCF | Derivado de los perfiles APN/QoS de EPC y reglas de carga de PCRF |
| Datos de aplicación | application-data/{family}/{id} (familias pfds, influenceData, bdtData) | Crear / leer / reemplazar / eliminar | PCF, NEF | Ninguno - mantenido en un almacén en memoria (ETS) local, no respaldado por HSS y no persistido |
Los datos de aplicación son servidos por un almacén genérico en memoria en lugar del HSS. No se persiste: un reinicio lo borra. Ver Puntos finales de SBI → Datos de Aplicación a continuación.
Puntos finales de SBI
Todos los puntos finales de Nudr_DR se sirven a través de HTTP en {sbi_scheme}://{sbi_addr}:{sbi_port} (por defecto http://127.0.0.22:7777) con Content-Type: application/json. Los fallos se devuelven como ProblemDetails de TS 29.571.
El segmento de ruta {ueId} es un SUPI en forma de imsi-<dígitos> (también se acepta un IMSI desnudo). El segmento {servingPlmnId} en las lecturas de datos aprovisionados se valida: debe ser un PLMN bien formado (5 o 6 dígitos) y debe coincidir con el PLMN de servicio configurado a partir de mcc/mnc, de lo contrario, la lectura se rechaza con 400 MANDATORY_IE_INCORRECT. Esta construcción sirve un solo registro por suscriptor.
Datos de Suscripción - Autenticación (TS 29.504 / 29.505)
| Método | Ruta | Descripción | Éxito |
|---|---|---|---|
| GET | /nudr-dr/v2/subscription-data/{ueId}/authentication-data/authentication-subscription | Recuperar suscripción de autenticación (método, Ki, OPc, AMF, SQN) | 200 |
| PATCH | /nudr-dr/v2/subscription-data/{ueId}/authentication-data/authentication-subscription | Actualizar suscripción de autenticación (SQN) | 204, o 200 + PatchResult en caso de fallo parcial |
| POST | /nudr-dr/v2/subscription-data/{ueId}/authentication-data/authentication-vectors | Generar vectores de autenticación (ver nota) | 200 |
Punto final no estándar. El POST de
authentication-vectorses una extensión propietaria de Omni 5GC; TS 29.504/29.505 no definen tal recurso. La generación de vectores y la gestión de SQN/resync se delegan al UDR, por lo que se manejan centralmente en el HSS. Solo es consumido por OmniUDM; un consumidor de terceros conforme a estándares nunca lo llamará.
Datos de Suscripción - Aprovisionados (TS 29.505)
| Método | Ruta | Descripción | Éxito |
|---|---|---|---|
| GET | /nudr-dr/v2/subscription-data/{ueId}/{servingPlmnId}/provisioned-data/am-data | Recuperar datos de suscripción de acceso y movilidad | 200, o 400 MANDATORY_IE_INCORRECT en caso de un {servingPlmnId} mal formado o no coincidente |
| GET | /nudr-dr/v2/subscription-data/{ueId}/{servingPlmnId}/provisioned-data/sm-data | Recuperar datos de suscripción de gestión de sesiones | 200, o 400 MANDATORY_IE_INCORRECT en caso de un {servingPlmnId} mal formado o no coincidente |
| GET | /nudr-dr/v2/subscription-data/{ueId}/{servingPlmnId}/provisioned-data/smf-selection-subscription-data | Recuperar datos de suscripción de selección de SMF | 200, o 400 MANDATORY_IE_INCORRECT en caso de un {servingPlmnId} mal formado o no coincidente |
Datos de Suscripción - Contexto (TS 29.504)
| Método | Ruta | Descripción | Éxito |
|---|---|---|---|
| PUT | /nudr-dr/v2/subscription-data/{ueId}/context-data/amf-3gpp-access | Almacenar contexto de registro de AMF 3GPP | 201 + Location (nuevo) o 204 (actualización) |
| PUT | /nudr-dr/v2/subscription-data/{ueId}/context-data/smf-registrations/{pduSessionId} | Almacenar contexto de registro de SMF | 201 + Location (nuevo) o 204 (actualización) |
Un cuerpo vacío en cualquiera de los PUT de contexto devuelve 400 ProblemDetails (cause: MANDATORY_IE_MISSING).
Datos de Políticas (TS 29.519)
| Método | Ruta | Descripción | Éxito |
|---|---|---|---|
| GET | /nudr-dr/v2/policy-data/ues/{ueId}/am-data | Recuperar datos de políticas AM (subscCats, praInfos) | 200 |
| GET | /nudr-dr/v2/policy-data/ues/{ueId}/sm-data | Recuperar datos de políticas SM (smPolicySnssaiData por DNN) | 200 |
Datos de Aplicación (TS 29.504)
CRUD genérico sobre las familias application-data de Nudr_DR. El segmento de ruta {family} es uno de pfds, influenceData, o bdtData; el segmento {id} es el id del recurso de la familia (appId / influenceId / bdtReferenceId). Los registros se mantienen en un almacén en memoria (ETS) local, no en el HSS, y no se persisten a través de un reinicio. Cualquier otro valor de {family} cae en el 404 catch-all.
| Método | Ruta | Descripción | Éxito |
|---|---|---|---|
| GET | /nudr-dr/v2/application-data/{family} | Listar todos los recursos en la familia (colección GET) | 200 (array) |
| GET | /nudr-dr/v2/application-data/{family}/{id} | Recuperar un recurso | 200, o 404 si es desconocido |
| PUT | /nudr-dr/v2/application-data/{family}/{id} | Crear o reemplazar un recurso | 201 + Location (nuevo) o 200 (reemplazo) |
| DELETE | /nudr-dr/v2/application-data/{family}/{id} | Eliminar un recurso | 204, o 404 si es desconocido |
Un cuerpo vacío en el PUT devuelve 400 ProblemDetails (cause: MANDATORY_IE_MISSING).
Suscripciones de Cambio de Datos (TS 29.504 subscriptions-to-notify)
| Método | Ruta | Descripción | Éxito |
|---|---|---|---|
| POST | /nudr-dr/v2/subscription-data/subs-to-notify | Crear una suscripción de cambio de datos (el cuerpo nombra los URIs de recurso monitoreados y el URI de callback de notificación) | 201 + Location, o 400 en caso de un cuerpo incorrecto |
| DELETE | /nudr-dr/v2/subscription-data/subs-to-notify/{subsId} | Eliminar una suscripción de cambio de datos | 204, o 404 si la suscripción es desconocida |
Ver Suscripciones de Cambio de Datos y DataChangeNotify para el comportamiento de fan-out.
Cualquier ruta que no coincida con los recursos anteriores se responde con un 404 ProblemDetails.
Llamadas REST del Backend de HSS
Cada operación de SBI se cumple con una o más llamadas al backend REST de OmniHSS en hss_api_base_url. La relación es:
| Operación Nudr_DR | Llamada(s) REST de HSS | Notas |
|---|---|---|
| Lectura de suscripción de autenticación | GET /api/subscriber/imsi/{imsi}, luego GET /api/key_set/{id} si el material clave es referenciado por id | El material clave en línea en el registro del suscriptor omite la segunda llamada |
| Generación de vectores de autenticación | POST /api/hlr/generate_auth_vectors | Cuerpo {imsi, auts}; auts es rand‖auts hex en resync |
| Actualización de SQN (PATCH) | POST /api/hlr/update_sqn | Cuerpo {imsi, sqn} |
| Lectura de AM / SM / selección de SMF | GET /api/subscriber/imsi/{imsi} | Obtención de un solo suscriptor, mapeado localmente |
| Escritura de contexto de AMF | PUT /api/hlr/circuit_session/{imsi} | Actualización de ubicación/sesión de circuito; también almacenada localmente |
| Escritura de contexto de SMF | (ninguna) | Solo caché local ETS |
| Lectura de datos de políticas (AM / SM) | GET /api/subscriber/imsi/{imsi} | Reutiliza el mapeo AM/SM y lo reconfigura |
| Verificación de salud | GET /api/status/api | Impulsa el punto final de gestión /health/hss y el medidor de salud |
Los puntos finales
/api/hlr/*(generate_auth_vectors,update_sqn,circuit_session/{imsi}) son la interfaz REST diseñada a medida del HSS para las operaciones de vector de autenticación, SQN y ubicación de OmniUDR, junto con los puntos finales de suscriptor/conjunto de claves (/api/subscriber/*,/api/key_set/*) y la sonda de salud (/api/status/api). Un suscriptor deshabilitado (enabled: false) se trata como no encontrado.
Procedimientos Clave
Lectura de Suscripción de Autenticación (UDM → UDR → HSS)
El flujo central de UDR: el UDM (sirviendo al AUSF durante 5G-AKA) solicita a OmniUDR la suscripción de autenticación de un suscriptor; OmniUDR lee el suscriptor y el material clave del HSS y lo mapea a la estructura Nudr.
Generación de Vectores de Autenticación (propietario, con resync)
OmniUDM llama al POST no estándar authentication-vectors para que la generación de vectores de Milenage y la gestión de SQN/resync se manejen centralmente en el HSS. En una resincronización, el UDM pasa resynchronizationInfo (rand + auts), que OmniUDR concatena en el hex rand‖auts que el HSS espera.
Lectura de Datos Aprovisionados (AM / SM / Selección de SMF)
Para los datos de AM, el mapeo en su lugar deriva subscribedUeAmbr del UE-AMBR de EPC y adjunta un NSSAI sintetizado (ver default_am_nssai); para los datos de selección de SMF, enumera los APNs del suscriptor como información de DNN bajo un único S-NSSAI suscrito.
Cómo el perfil APN del HSS se convierte en datos de suscripción SM de 5G
El registro del HSS de 4G no tiene estructuras de gestión de sesiones de 5G, por lo que OmniUDR sintetiza una entrada dnnConfigurations por cada APN aprovisionado (epc_profile.apn_profiles[]). Cada campo se deriva de la siguiente manera. Cuando el campo nombrado del HSS está ausente, se sirve el valor de reserva; una reserva en todos los ámbitos significa que los nombres de los campos del perfil QoS de APN no coinciden (ver Solución de Problemas → Los datos de SM sirven un AMBR fijo).
| Campo SM de 5G | Derivado de (campo HSS) | Reserva cuando está ausente |
|---|---|---|
singleNssai | DNN → S-NSSAI a través de dnn_snssai_map | eMBB sst 1 / sd 000001 |
Clave DNN en dnnConfigurations | Nombre de APN (apn_identifier.apn) | internet |
pduSessionTypes | APN apn_identifier.ip_version (ver tabla a continuación) | IPV4 por defecto, IPV4/IPV4V6 permitido |
sscModes | fijo: SSC_MODE_1 por defecto, permitido SSC_MODE_1 + SSC_MODE_2 | - (no aprovisionable) |
5gQosProfile.5qi | apn_qos_profile.qci | 9 |
5gQosProfile.arp.priorityLevel | apn_qos_profile.allocation_retention_priority | 1 |
5gQosProfile.arp.preemptCap | apn_qos_profile.pre_emption_capability (bool) | NOT_PREEMPT |
5gQosProfile.arp.preemptVuln | apn_qos_profile.pre_emption_vulnerability (bool) | NOT_PREEMPTABLE |
sessionAmbr.uplink | apn_qos_profile.apn_ambr_ul_kbps | 100000 Kbps |
sessionAmbr.downlink | apn_qos_profile.apn_ambr_dl_kbps | 200000 Kbps |
chargingRules | APN pcrf_profile.charging_rules[] (nombre, precedencia, 5QI/QCI, ARP, GBR/MBR, infos de flujo) | [] (sin flujos dedicados) |
Tipos de sesión PDU. El tipo de sesión PDU de 5G es el gemelo de 4G del tipo PDN, derivado de la ip_version del APN, por lo que un APN IPv6 o de pila dual produce una sesión capaz de IPv6 en lugar del valor por defecto solo de IPv4. defaultSessionType es a lo que el SMF recurre cuando el UE no solicita un tipo permitido específico.
APN ip_version | defaultSessionType | allowedSessionTypes |
|---|---|---|
ipv4 | IPV4 | IPV4 |
ipv6 | IPV6 | IPV6 |
ipv4v6 / ipv4_or_ipv6 | IPV4V6 | IPV4V6, IPV4, IPV6 |
| no establecido / otro | IPV4 | IPV4, IPV4V6 |
Los modos SSC no son aprovisionables por suscriptor: cada DNN se anuncia con SSC_MODE_1 por defecto y SSC_MODE_1/SSC_MODE_2 permitidos. Según TS 29.503 / 29.571, SscModes.allowedSscModes tiene maxItems: 2 (el valor por defecto más como máximo una alternativa), por lo que el conjunto no puede ampliarse.
Los datos de suscripción de selección de SMF enumeran cada APN aprovisionado como un DNN bajo una única clave S-NSSAI suscrita 01, independientemente del mapeo por DNN en dnn_snssai_map. En un despliegue de múltiples slices donde los DNN viven en diferentes S-NSSAIs, utilice los datos de suscripción AM/SM (que llevan el S-NSSAI correcto por DNN) para decisiones de slice; la selección de SMF solo publicita la lista de DNN.
Actualización de SQN (PATCH suscripción de autenticación)
Escritura de Contexto de Registro de AMF
Escritura de Contexto de Registro de SMF (solo caché local)
El contexto de registro de SMF se almacena solo en la caché local ETS, indexado por {ueId}/{pduSessionId}; nunca se persiste en el HSS y se pierde al reiniciar. La presencia de una entrada de caché existente decide creación vs. actualización.
Lectura de Datos de Políticas AM (PCF → UDR → HSS)
Los datos de políticas AM son gruesos: OmniUDR lee el UE-AMBR del suscriptor del HSS y lo clasifica en una única categoría de suscriptor (premium / standard / basic); praInfos siempre está vacío.
Lectura de Datos de Políticas SM (PCF → UDR → HSS)
Registro y Latido de NRF
Al iniciar, OmniUDR registra su perfil NF con el NRF y luego envía un latido cada heartbeat_interval milisegundos para que el registro siga anunciándolo como vivo. El estado de registro se expone como un medidor (ver Métricas), y una acción de OAM puede forzar el re-registro.
Suscripciones de Cambio de Datos y DataChangeNotify
OmniUDR implementa el servicio de suscripción de cambio de datos Nudr_DR (el recurso subscription-data/subs-to-notify, TS 29.504 subscriptions-to-notify). Un consumidor registra una suscripción que nombra los URIs de recurso que desea monitorear y un URI de callback de notificación, opcionalmente con una expiración. Las suscripciones se mantienen en un almacén de suscripciones en memoria (ETS); una expiración, cuando se proporciona, es respetada por el almacén, que elimina la suscripción una vez que ha expirado.
Cuando un recurso monitoreado cambia, OmniUDR emite un DataChangeNotify al URI de callback de cada suscriptor cuyos URIs monitoreados cubren el recurso cambiado (una coincidencia exacta de URI, o un prefijo de colección para que una suscripción en un recurso padre capture sus recursos hijos). Cada notificación lleva un tipo de cambio: ADD, REPLACE, o REMOVE. En esta construcción, las notificaciones se activan en una actualización de SQN (PATCH de la suscripción de autenticación) y en escrituras de contexto de AMF y SMF (un primer registro para un recurso es un ADD, una escritura subsiguiente es un REPLACE).
La entrega es de mejor esfuerzo y nunca afecta la respuesta de SBI que recibe el consumidor. Un callback que falla o es inalcanzable se reintenta con un número limitado de intentos y un retroceso exponencial (ver notification_max_attempts y notification_backoff_ms); una vez que se agotan los intentos, la notificación se descarta y el evento se registra.