Saltar al contenido principal

OmniUDR

OmniUDR implementa el Repositorio Unificado de Datos (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 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é 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 mantiene las suscripciones activas 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 de 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.

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 de backend de HSS, API de gestión/OAM y registro.
  • Métricas - Métricas de Prometheus para registro de NRF, salud del backend de HSS, conteos de solicitudes/latencia y salud de BEAM VM, con ejemplo de PromQL.
  • Resolución de Problemas - Problemas comunes y sus soluciones.

Descripció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 de 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.

Descripció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/ubicación y en una caché local) y registro de SMF (solo caché ETS local), cada uno devolviendo 201/204 para creación frente a actualización.
  • Datos de políticas Nudr_DR: datos de políticas de AM (categorías subscCats gruesas) y datos de políticas de SM (smPolicySnssaiData por S-NSSAI/DNN) derivados de los 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 suscripción en memoria; OmniUDR emite notificaciones DataChangeNotify (ADD / REPLACE / REMOVE) a los suscriptores cuando los datos monitoreados cambian (según las suscripciones-to-notify del TS 29.504).
  • Datos de aplicaciones 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 respaldadas por HSS y no persistidas a través de un reinicio.
  • Generación de vectores de autenticación propietarios: un POST authentication-vectors no estándar que delega la generación de vectores Milenage y el manejo de SQN/resincronización al HSS, 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​

La configuración principal del operador es la URL del backend REST de OmniHSS. 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",
  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 la 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