Pular para o conteúdo principal

OmniUDR

OmniUDR implementa o Repositório de Dados Unificado (UDR) do Core 5G da Omnitouch. Ele expõe o serviço Nudr_DataRepository (TS 29.504): dados estruturados de assinantes, políticas e contexto para o UDM e PCF através da Interface Baseada em Serviço (SBI).

OmniUDR não possui dados de assinantes. É uma fachada Nudr_DR fina e compatível com padrões sobre o backend de provisionamento REST do OmniHSS: cada leitura do repositório de dados é traduzida no momento da solicitação em uma ou mais chamadas REST do OmniHSS, e a resposta do HSS é mapeada no modelo de dados Nudr do 3GPP antes de ser retornada ao consumidor. OmniUDR é a única função de rede do Core 5G que se comunica diretamente com a API REST do OmniHSS. O UDM (e, através dele, o AUSF) acessa os dados do assinante chamando o OmniUDR através do Nudr padrão, e não chamando o HSS.

Como o HSS é o sistema de registro, o OmniUDR quase não mantém estado persistente. Seu único estado local é três pequenos armazenamentos em memória (ETS): um cache de contexto de registro AMF e SMF (usado para decidir se uma gravação de contexto é uma criação ou uma atualização), um armazenamento de assinatura de mudança de dados que mantém as assinaturas ativas subs-to-notify do Nudr_DR, e um armazenamento de dados de aplicativo que mantém as famílias de application-data do Nudr_DR (PFDs, influência de tráfego, BDT). Nenhum desses é persistido; todos são limpos na reinicialização. O cache de contexto de registro pode ser esvaziado através da API de gerenciamento.

Documentação​

  • Guia de Operações - função 3GPP, conjuntos de dados servidos, endpoints SBI e os principais procedimentos de leitura/atualização/contexto/política com diagramas de sequência.
  • Referência de Configuração - Referência completa de configuração em tempo de execução, configurações de backend do HSS, API de gerenciamento/OAM e registro.
  • Métricas - Métricas Prometheus para registro NRF, saúde do backend HSS, contagem de solicitações/latência e saúde da VM BEAM, com exemplo PromQL.
  • Solução de Problemas - Problemas comuns e suas resoluções.

Visão Geral da Arquitetura​

O AUSF não aparece como um consumidor direto: os dados de autenticação 5G fluem AUSF → UDM → OmniUDR → OmniHSS. O OmniUDR mapeia o registro de assinante do HSS estilo 4G (material de chave, perfis de QoS EPC/APN, regras de cobrança PCRF) nas estruturas Nudr 5G (assinatura de autenticação, dados de acesso e mobilidade, dados de gerenciamento de sessão, dados de seleção SMF, dados de política) em tempo real.

Visão Geral dos Recursos​

  • Dados de assinatura Nudr_DR: leitura de assinatura de autenticação e atualização de SQN (PATCH), além de dados provisionados de acesso e mobilidade, gerenciamento de sessão e seleção SMF (GET), mapeados ao vivo do registro de assinante do HSS.
  • Dados de contexto Nudr_DR: registro de acesso 3GPP AMF (espelhado para a sessão/circuito de localização do HSS e para um cache local) e registro SMF (apenas cache ETS local), cada um retornando 201/204 para criação vs. atualização.
  • Dados de política Nudr_DR: dados de política AM (coarse subscCats) e dados de política SM (smPolicySnssaiData por S-NSSAI/DNN) derivados dos perfis EPC/PCRF do HSS para o PCF.
  • Assinaturas de mudança de dados Nudr_DR: consumidores registram uma assinatura subs-to-notify nomeando URIs de recursos monitorados e uma URI de callback de notificação, mantidas em um armazenamento de assinatura em memória; o OmniUDR emite notificações DataChangeNotify (ADD / REPLACE / REMOVE) para os assinantes quando os dados monitorados mudam (por assinaturas-to-notify do TS 29.504).
  • Dados de aplicativo Nudr_DR: CRUD genérico (GET coleção / GET / PUT / DELETE) sobre as famílias de application-data (pfds, influenceData, bdtData) respaldadas por um armazenamento local em memória (ETS); não respaldado pelo HSS e não persistido entre reinicializações.
  • Geração de vetor de autenticação proprietário: um POST authentication-vectors não padrão que delega a geração de vetores Milenage e o manuseio de SQN/resync ao HSS, consumido apenas pelo OmniUDM.
  • Sem estado respaldado pelo HSS: sem armazenamento local de assinantes; a disponibilidade de leitura e latência acompanham diretamente o HSS, apresentadas através de um medidor de saúde e métricas de solicitação por endpoint.
  • Integração NRF: registro automático e heartbeat periódico, com uma API OAM para mudanças de configuração ao vivo, re-registro forçado e esvaziamento do cache de contexto.

Início Rápido​

A configuração principal do operador é a URL do backend REST do OmniHSS. Um provisionamento mínimo vincula o ouvinte SBI e aponta o OmniUDR para seu NRF e 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"

O conjunto completo de parâmetros - incluindo identidade PLMN, ajuste de métricas/heartbeat, substituições de mapeamento de fatias e a ajuda de assinante de teste de laboratório - está documentado na Referência de Configuração.

Última atualização em