Saltar al contenido principal

OmniUDR

OmniUDR implementa el Repositorio de Datos Unificado (UDR) del núcleo 5G de Omnitouch. Expone el servicio Nudr_DataRepository (TS 29.504): 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 de 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 en el 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): una caché del 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 de Nudr_DR subs-to-notify, y un almacén de datos de aplicaciones que contiene las familias de application-data de Nudr_DR (PFDs, influencia del tráfico, BDT). Ninguno de estos se persiste; todos se borran al reiniciar. La caché del contexto de registro se puede vaciar a través de la API de gestión.

Documentación​

  • Guía de Operaciones - rol de 3GPP, conjuntos de datos servidos, puntos finales de SBI y los procedimientos clave de lectura/actualización/contexto/política con diagramas de secuencia.
  • Referencia de Configuración - Referencia completa de configuración en tiempo de ejecución, configuraciones del backend HSS, API de gestión/OAM y registro.
  • Métricas - Métricas de Prometheus para el registro de NRF, salud del backend HSS, conteos de solicitudes/latencia y salud de BEAM VM, con ejemplo de PromQL.
  • Solución de Problemas - Problemas comunes y sus resoluciones.

Visión General de la Arquitectura​

El AUSF no aparece como un consumidor directo: los datos de autenticación 5G fluyen AUSF → UDM → OmniUDR → OmniHSS. OmniUDR mapea el registro de suscriptor del HSS estilo 4G (material clave, perfiles de QoS EPC/APN, reglas de carga PCRF) en las estructuras Nudr 5G (suscripción de autenticación, datos de acceso y movilidad, datos de gestión de sesiones, datos de selección de SMF, datos de políticas) sobre la marcha.

Visión General de Características​

  • Datos de suscripción Nudr_DR: lectura de suscripción de autenticación y actualización de SQN (PATCH), además de datos provisionados de acceso y movilidad, gestión de sesiones y selección de SMF (GET), mapeados en vivo desde el registro de suscriptor del HSS.
  • Datos de contexto Nudr_DR: registro de acceso 3GPP de AMF (reflejado en la sesión/circuito de HSS/localización y en una caché local) y registro de SMF (solo caché ETS local), cada uno devolviendo 201/204 para creación vs. actualización.
  • Datos de políticas Nudr_DR: datos de políticas AM (categorías subscCats gruesas) y datos de políticas SM (smPolicySnssaiData por S-NSSAI/DNN) derivados de perfiles EPC/PCRF del HSS para el PCF.
  • Suscripciones de cambios de datos Nudr_DR: los consumidores registran una suscripción subs-to-notify nombrando URIs de recursos monitoreados y una URI de callback de notificación, mantenida en un almacén de suscripciones en memoria; OmniUDR emite notificaciones DataChangeNotify (ADD / REPLACE / REMOVE) a los suscriptores cuando los datos monitoreados cambian (según las suscripciones-to-notify de TS 29.504).
  • Datos de aplicación Nudr_DR: CRUD genérico (GET colección / GET / PUT / DELETE) sobre las familias de application-data (pfds, influenceData, bdtData) respaldadas por un almac��n en memoria local (ETS); no respaldado por HSS y no persistido a través de un reinicio.
  • Generación de vectores de autenticación propietaria: un POST authentication-vectors no estándar que delega la generación de vectores y el manejo de SQN/sincronización al HSS (Ki/OPc nunca lo abandonan), consumido solo por OmniUDM.
  • Sin estado respaldado por HSS: sin almacén local de suscriptores; la disponibilidad de lectura y la latencia siguen al HSS directamente, presentadas a través de un medidor de salud y métricas de solicitud por punto final.
  • Integración NRF: registro automático y latido periódico, con una API OAM para cambios de configuración en vivo, re-registro forzado y vaciado de caché de contexto.

Inicio Rápido​

Los ajustes principales del operador son la URL del backend REST de OmniHSS y la clave de API de OmniHSS. La clave es obligatoria y debe tener el rol de OmniHSS hlr_interworking. Un despliegue mínimo vincula el oyente de SBI y apunta a OmniUDR a su NRF y HSS:

config :omniudr,
  hss_api_base_url: "https://hss.example.net:8443",
  hss_api_key: "<Clave API de OmniHSS con rol hlr_interworking>",
  sbi_scheme: "http",
  sbi_addr: "127.0.0.22",
  sbi_port: 7777,
  nrf_uri: "http://127.0.0.1:7777",
  mcc: "999",
  mnc: "70"

El conjunto completo de parámetros - incluyendo identidad PLMN, ajuste de métricas/latido, sobrescrituras de mapeo de slice, y la ayuda de suscriptor de prueba de laboratorio - está documentado en la Referencia de Configuración.

Última actualización en