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 delgada y conforme a estándares Nudr_DR 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 de suscriptores 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): un caché de contexto de registro de AMF y SMF (utilizado 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 aplicaciones que contiene las familias de datos application-data de Nudr_DR (PFDs, influencia de tráfico, BDT). Ninguno de estos se persiste; todos se borran al reiniciar. El caché de contexto de registro se puede vaciar a través de la API de gestión.
Referencias de Rol y Especificación 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 de 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 | Enlace | 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 satisfacen cada lectura/actualización. Cada llamada envía hss_api_key en el encabezado x-omnihss-key (rol de OmniHSS hlr_interworking) |
| 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 suscriptores y acciones de OAM - ver Referencia de Configuración |
| Métricas de Prometheus | prometheus_metrics_port (por defecto 9568) | Punto de finalización 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 de 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 (AMF, SQN) o key_set_id; Ki/OPc permanecen en el HSS |
| Vectores de autenticación | subscription-data/.../authentication-data/authentication-vectors | Generar (propietario) | OmniUDM | HSS generate_eutran_auth_vectors (vector + 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 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 actualización de sesión de circuito del HSS (ubicación); reflejado en caché local |
| Contexto de registro de SMF | subscription-data/.../context-data/smf-registrations/{pduSessionId} | Escribir | UDM (Nudm_UECM) | Almacenado solo en caché local (no persistido al HSS) |
| Datos de políticas AM | policy-data/ues/{ueId}/am-data | Leer | PCF | Derivado de EPC UE-AMBR (categorías de suscriptores gruesas) |
| Datos de políticas SM | policy-data/ues/{ueId}/sm-data | Leer | PCF | Derivado de 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 local (ETS), 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 que sirve configurado desde mcc/mnc, de lo contrario, la lectura es rechazada con 400 MANDATORY_IE_INCORRECT. Esta construcción sirve un único 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, 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 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
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 para que se manejen 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 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 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 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 acceso 3GPP de AMF | 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 de 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 local (ETS), 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 (reemplazar) |
| 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 recursos monitoreados y el URI de callback de notificación) | 201 + Location, o 400 en 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 mediante 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 se referencia por id | El material clave en línea en el registro del suscriptor omite la segunda llamada |
| Generación de vectores de autenticación | GET /api/subscriber/imsi/{imsi}, luego POST /api/hlr/generate_eutran_auth_vectors | Cuerpo {imsi, num_vectors: 1, resynchronization_info?}; resynchronization_info 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} | Recuperació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 almacenado 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_eutran_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) pide 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 y la gestión de SQN/resync se manejen centralmente en el HSS, y Ki/OPc nunca salgan de él. El HSS devuelve un vector EUTRAN (rand, xres, autn, ck, ik) cuyo AUTN lleva el AMF aprovisionado del suscriptor; OmniUDM deriva las claves 5G de él. 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 EPC UE-AMBR y adjunta un NSSAI sintetizado (ver default_am_nssai); para los datos de selección de SMF, lista los APNs del suscriptor como información DNN bajo una única clave S-NSSAI suscrita.
Cómo el perfil APN del HSS se convierte en datos de suscripción SM 5G
El registro HSS 4G no tiene estructuras de gestión de sesiones 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 fallback - un fallback en todos los ámbitos significa que los nombres de los campos del perfil QoS del APN no coinciden (ver Solución de Problemas → Los datos de SM sirven un AMBR fijo).
| Campo SM 5G | Derivado de (campo HSS) | Fallback cuando está ausente |
|---|---|---|
singleNssai | DNN → S-NSSAI a través de dnn_snssai_map | eMBB sst 1 / sd 000001 |
Clave DNN en dnnConfigurations | Nombre 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) |
staticIpAddress | Suscriptor static_ips[] cuyo apn_profile_id es este perfil APN: ipv4_static_ip → ipv4Addr, ipv6_static_ip → ipv6Addr | Omitido (SMF asigna de su pool) |
Tipos de sesión PDU. El tipo de sesión PDU 5G es el gemelo 5G del tipo PDN 4G, 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 de la por defecto solo IPv4. defaultSessionType es lo que el SMF utiliza como fallback 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 |
Modos SSC no son aprovisionables por suscriptor: cada DNN se publicita 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 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, utiliza 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 al HSS y se pierde al reiniciar. La presencia de una entrada de caché existente decide crear vs. actualizar.
Lectura de Datos de Política AM (PCF → UDR → HSS)
Los datos de política AM son generales: OmniUDR lee el UE-AMBR del suscriptor desde el HSS y lo clasifica en una sola categoría de suscriptor (premium / standard / basic); praInfos siempre está vacío.
Lectura de Datos de Política SM (PCF → UDR → HSS)
Registro y Latido de NRF
Al iniciar, OmniUDR registra su perfil NF con el NRF y luego envía latidos cada heartbeat_interval milisegundos para que el registro siga anunciándolo como activo. El estado de registro se expone como un medidor (ver Métricas), y una acción OAM puede forzar un nuevo 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, suscripciones TS 29.504 a notificar). Un consumidor registra una suscripción que nombra las URIs de recursos que desea monitorear y una URI de callback de notificación, opcionalmente con una fecha de caducidad. Las suscripciones se mantienen en una tienda de suscripciones en memoria (ETS); una fecha de caducidad, cuando se proporciona, es respetada por la tienda, que elimina la suscripción una vez que ha expirado.
Cuando un recurso monitoreado cambia, OmniUDR emite un DataChangeNotify a la URI de callback de cada suscriptor cuyas URIs monitoreadas 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 versión, las notificaciones se activan en una actualización de SQN (PATCH de la suscripción de autenticación) y en escrituras de contexto AMF y SMF (un primer registro para un recurso es un ADD, una escritura posterior es un REPLACE).
La entrega es de mejor esfuerzo y nunca afecta la respuesta 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.