Aller au contenu principal

OmniUDR

OmniUDR implémente le Référentiel de Données Unifié (UDR) du cœur 5G d'Omnitouch. Il expose le service Nudr_DataRepository (TS 29.504) : données structurées sur les abonnés, données de politique et données de contexte à l'UDM et au PCF via l'Interface Basée sur les Services (SBI).

OmniUDR ne possède pas de données d'abonnés. C'est une façade Nudr_DR conforme aux normes, mince, sur le backend de provisioning REST OmniHSS : chaque lecture du référentiel de données est traduite au moment de la demande en un ou plusieurs appels REST OmniHSS, et la réponse HSS est mappée dans le modèle de données Nudr 3GPP avant d'être renvoyée au consommateur. OmniUDR est la seule fonction du réseau cœur 5G qui communique directement avec l'API REST OmniHSS. L'UDM (et, à travers lui, l'AUSF) accède aux données des abonnés en appelant OmniUDR via Nudr standard, et non en appelant le HSS.

Parce que le HSS est le système de référence, OmniUDR ne conserve presque aucun état persistant. Son seul état local est constitué de trois petits magasins en mémoire (ETS) : un cache de contexte d'enregistrement AMF et SMF (utilisé pour décider si une écriture de contexte est une création ou une mise à jour), un magasin d'abonnement aux changements de données contenant les abonnements actifs subs-to-notify de Nudr_DR, et un magasin de données d'application contenant les familles de application-data de Nudr_DR (PFDs, influence du trafic, BDT). Aucun de ces éléments n'est persistant ; tous sont effacés au redémarrage. Le cache de contexte d'enregistrement peut être vidé via l'API de gestion.

Documentation​

  • Guide des Opérations - rôle 3GPP, ensembles de données servis, points de terminaison SBI, et les procédures clés de lecture/mise à jour/contexte/politique avec des diagrammes de séquence.
  • Référence de Configuration - Référence complète de configuration à l'exécution, paramètres du backend HSS, API de gestion/OAM, et journalisation.
  • Métriques - Métriques Prometheus pour l'enregistrement NRF, la santé du backend HSS, les comptes de requêtes/latence, et la santé de la VM BEAM, avec exemple de PromQL.
  • Dépannage - Problèmes courants et leurs résolutions.

Vue d'Ensemble de l'Architecture​

L'AUSF n'apparaît pas comme un consommateur direct : les données d'authentification 5G circulent AUSF → UDM → OmniUDR → OmniHSS. OmniUDR mappe l'enregistrement d'abonné HSS de style 4G (matériel clé, profils QoS EPC/APN, règles de facturation PCRF) dans les structures Nudr 5G (abonnement d'authentification, données d'accès et de mobilité, données de gestion de session, données de sélection SMF, données de politique) à la volée.

Vue d'Ensemble des Fonctionnalités​

  • Données d'abonnement Nudr_DR : lecture de l'abonnement d'authentification et mise à jour SQN (PATCH), plus données provisionnées d'accès et de mobilité, de gestion de session, et de sélection SMF (GET), mappées en direct à partir de l'enregistrement d'abonné HSS.
  • Données de contexte Nudr_DR : enregistrement d'accès 3GPP AMF (miroité vers la session/circuit HSS/emplacement et vers un cache local) et enregistrement SMF (cache ETS local uniquement), chacun retournant 201/204 pour création vs mise à jour.
  • Données de politique Nudr_DR : données de politique AM (coarse subscCats) et données de politique SM (smPolicySnssaiData par S-NSSAI/DNN) dérivées des profils EPC/PCRF HSS pour le PCF.
  • Abonnements aux changements de données Nudr_DR : les consommateurs enregistrent un abonnement subs-to-notify nommant les URI de ressources surveillées et une URI de rappel de notification, conservée dans un magasin d'abonnement en mémoire ; OmniUDR émet des notifications DataChangeNotify (ADD / REPLACE / REMOVE) aux abonnés lorsque les données surveillées changent (selon les abonnements-to-notify TS 29.504).
  • Données d'application Nudr_DR : CRUD générique (GET collection / GET / PUT / DELETE) sur les familles de application-data (pfds, influenceData, bdtData) soutenues par un magasin en mémoire local (ETS) ; non soutenues par HSS et non persistées après un redémarrage.
  • Génération de vecteurs d'authentification propriétaires : un POST authentication-vectors non standard qui délègue la génération de vecteurs Milenage et la gestion de SQN/resync au HSS, consommé uniquement par OmniUDM.
  • Statelessness soutenue par HSS : pas de magasin d'abonnés local ; la disponibilité et la latence de lecture suivent directement le HSS, affichées à travers un indicateur de santé et des métriques de requêtes par point de terminaison.
  • Intégration NRF : enregistrement automatique et battement de cœur périodique, avec une API OAM pour des changements de configuration en direct, une réinscription forcée, et un vidage du cache de contexte.

Démarrage Rapide​

Le paramètre principal de l'opérateur est l'URL du backend REST OmniHSS. Un déploiement minimal lie l'auditeur SBI et pointe OmniUDR vers son NRF et 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"

L'ensemble complet des paramètres - y compris l'identité PLMN, le réglage des métriques/battement de cœur, les remplacements de mappage de tranche, et l'aide aux abonnés de test en laboratoire - est documenté dans la Référence de Configuration.

Dernière mise à jour le