Pular para o conteúdo principal

OmniUDR

OmniUDR implementa o Repositório Unificado de Dados (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) acessam os dados do assinante chamando o OmniUDR via 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 de Nudr_DR subs-to-notify, e um armazenamento de dados de aplicação 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 limpo através da API de gerenciamento.

Documentação​

  • Guia de Operações - papel 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 do backend HSS, API de gerenciamento/OAM e registro.
  • Métricas - Métricas Prometheus para registro NRF, saúde do backend HSS, contagens 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 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 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 assinantes quando os dados monitorados mudam (por assinaturas-to-notify do TS 29.504).
  • Dados de aplicação 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 respaldadas pelo HSS e não persistidas 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 e o manuseio de SQN/resync para o HSS (Ki/OPc nunca saem dele), consumido apenas pelo OmniUDM.
  • Sem estado respaldado pelo HSS: sem armazenamento local de assinantes; a disponibilidade de leitura e latência rastreiam 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 alterações de configuração ao vivo, re-registro forçado e limpeza do cache de contexto.

Início Rápido​

As principais configurações do operador são a URL do backend REST do OmniHSS e a chave da API do OmniHSS. A chave é obrigatória e deve ter o papel hlr_interworking do OmniHSS. Uma implantação mínima vincula o ouvinte SBI e aponta o OmniUDR para seu NRF e HSS:

config :omniudr,
  hss_api_base_url: "https://hss.example.net:8443",
  hss_api_key: "<Chave da API OmniHSS com papel 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"

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

Última atualização em