O 5G Core já não é concebido apenas para comunicações entre pessoas. Veículos conectados, fábricas inteligentes, campi inteligentes, saúde remota, drones e muitas outras aplicações de setores verticais precisam cada vez mais influenciar dinamicamente os recursos de rede conforme as condições do serviço ou obter do operador informações autorizadas sobre o estado da rede. Se cada nova necessidade exigisse alterações manuais nas configurações do AMF, SMF, PCF, UDM e de outras funções de rede, a implantação de 5G em larga escala nos setores verticais seria extremamente difícil.

É nesse ponto que entra o NEF, ou Network Exposure Function. Ele fica entre o 5GC e as funções de aplicação, ou AFs, convertendo capacidades internas do núcleo em interfaces padronizadas que aplicações externas podem utilizar. Ao mesmo tempo, trata do controle de segurança, da tradução de informações e da entrega de parâmetros. Para aplicações de terceiros, o NEF funciona como uma porta de entrada controlada para a estrutura de capacidades do 5G Core do operador, e não apenas como um gateway de API básico.

Por que o 5GC precisa do NEF

O modelo de negócios do 4G era em grande parte orientado a B2C: a rede fornecia conectividade, e os assinantes usavam a Internet móvel para acessar diferentes aplicações. Com o 5G, o modelo expandiu-se para B2B2X. A rede precisa agora atender não apenas usuários individuais, mas também interações mais profundas e automatizadas com plataformas usadas em manufatura, transporte, campi, saúde e outros setores verticais.

Isso levanta uma questão importante: como as aplicações industriais podem usar as capacidades de rede do operador de forma segura e padronizada?

Considere uma empresa industrial que deseja que terminais de produção em determinada área recebam uma QoS mais previsível ou que o tráfego de uma aplicação seja direcionado para uma rede de dados local mais próxima da fábrica. Sem um mecanismo unificado de exposição de capacidades, a plataforma de aplicação talvez tivesse de se conectar diretamente a várias funções do núcleo e implementar configurações diferentes para diferentes fornecedores. Isso aumentaria a complexidade de integração e exporia mais interfaces internas do núcleo.

O NEF cria uma fronteira comum entre aplicações industriais e o 5GC. Um AF externo não precisa compreender todos os detalhes internos do AMF, SMF, PCF, UDM ou UPF. Basta enviar uma solicitação de serviço compatível com os padrões por meio do NEF. Em seguida, o NEF interage com as funções de rede 5GC adequadas e devolve o resultado ao lado da aplicação.

Essa abordagem converte parte das necessidades que dependeriam de coordenação manual e configuração estática em chamadas de serviço padronizadas, permitindo que os operadores exponham capacidades de rede aos parceiros de maneira mais automatizada.

Onde o NEF se posiciona no 5GC

O NEF é implantado entre as funções de rede do 5GC e os AFs. Um AF é uma entidade funcional da camada de aplicação responsável pela lógica de negócio. Pode ser uma aplicação confiável pertencente ou gerida pelo operador, ou uma plataforma de aplicação de terceiros localizada fora do domínio de confiança do operador. Uma aplicação de terceiros não pode receber acesso irrestrito às funções internas do núcleo, portanto a interação controlada é realizada por meio do NEF.

Do ponto de vista das interfaces, o NEF conecta efetivamente dois ambientes diferentes. Ao norte, atende AFs como plataformas de vídeo, plataformas de veículos conectados e sistemas de controle industrial. Ao sul, conecta-se às funções internas do 5GC e se comunica com entidades como SMF, PCF e UDM conforme o serviço solicitado.

O NEF evoluiu do SCEF usado no 4G, mas seu escopo é significativamente mais amplo. O SCEF estava principalmente associado a casos específicos de uso de IoT, enquanto o NEF no 5GC suporta uma gama muito maior de aplicações centradas em pessoas e máquinas e tornou-se parte importante da estrutura de exposição de capacidades baseada em serviços.

Por projeto, o NEF faz muito mais do que encaminhar mensagens. Suas principais responsabilidades incluem expor capacidades e eventos de rede, provisionar com segurança informações de aplicações externas na rede 3GPP, traduzir informações entre formatos externos e internos e receber dados de outras funções de rede para armazenamento ou posterior reexposição quando necessário.

Algumas informações recebidas pelo NEF podem ser armazenadas no UDR, o que significa que não precisam permanecer vinculadas a uma única instância do NEF. O NEF também pode oferecer suporte à funcionalidade PFD, fornecendo a base para uma detecção de aplicações e um processamento de políticas mais precisos.

Como cinco capacidades principais são expostas

O valor do NEF decorre, em última análise, dos serviços que ele pode expor. Em implantações práticas de 5GC, suas principais capacidades podem ser agrupadas em cinco áreas: exposição de QoS, subscrição de eventos de rede, direcionamento de tráfego, provisionamento de parâmetros e gestão de PFD. Essas funções correspondem a alguns dos requisitos de interação mais comuns entre aplicações industriais e redes de operadores.

Exposição de capacidade de QoS

A exposição de capacidade de QoS permite que uma aplicação parceira solicite uma qualidade de serviço específica para determinado fluxo. Por exemplo, uma aplicação de vídeo pode já estar sendo executada sobre uma sessão PDU existente. Se o usuário escolher um serviço de vídeo de maior qualidade, o AF pode usar o NEF para solicitar QoS aprimorada para esse fluxo de tráfego.

Após receber a solicitação, o NEF coordena-se com funções do núcleo como o PCF. O PCF aplica a lógica de políticas e trabalha com o SMF e outros recursos de rede para estabelecer o tratamento de QoS adequado ao fluxo de serviço.

O ponto principal não é simplesmente atribuir mais largura de banda ao dispositivo. O objetivo é permitir que a aplicação expresse seus requisitos de serviço por meio de uma interface padronizada, mantendo as decisões de política e a aplicação de recursos de rede sob controle do 5GC.

Mobilidade e subscrição de eventos de rede

Um AF de terceiros também pode usar o NEF para subscrever eventos de rede relacionados ao UE, como perda de conectividade, retorno à condição de alcançável, localização atual ou última conhecida, estado de roaming, motivos de falha de comunicação e estado da entrega de dados no downlink.

Esses eventos são detectados por diferentes funções do núcleo. O AMF pode detectar a alcançabilidade do UE, perda de conectividade e determinadas falhas de comunicação. O UDM pode fornecer informações como estado de roaming ou certas alterações de associação de identidade, enquanto o SMF pode relatar condições relacionadas à entrega de dados no downlink.

O AF não precisa se conectar diretamente a cada função de rede. Em vez disso, cria uma subscrição de eventos por meio do NEF. O NEF estabelece então a subscrição interna necessária com a função de rede correspondente. Quando o evento-alvo ocorre, o núcleo notifica o NEF, e o NEF encaminha a notificação ao AF externo conforme a subscrição.

Esse mecanismo é especialmente útil para aplicações industriais que precisam acionar lógica de negócio automatizada com base no estado do dispositivo. Em vez de consultar continuamente a rede sobre o estado do UE, a plataforma externa pode receber uma notificação quando o evento relevante realmente ocorrer.

Direcionamento de tráfego

O NEF também pode receber solicitações de Traffic Influence de um AF e direcionar o tráfego de um UE ou serviço específico para um Local DN, ou Local Data Network. Um Local DN é identificado por um DNAI e costuma estar associado a edge computing ou serviços implantados regionalmente.

Em uma fábrica automatizada, por exemplo, um servidor de controle industrial pode ser implantado em uma rede local próxima à área de produção. A plataforma de aplicação pode solicitar, por meio do NEF, que o 5GC ajuste o caminho do plano de usuário para que o tráfego dos dispositivos relevantes seja roteado ao Local DN apropriado.

O NEF não controla o UPF diretamente. Em vez disso, envia o requisito ao processo de controle de políticas. O PCF e o SMF passam então a cuidar da política e da configuração do plano de usuário. Dependendo da situação, o SMF pode selecionar novamente o UPF ou adicionar, substituir ou remover UPFs do caminho existente para concluir o direcionamento de tráfego.

Provisionamento seguro de parâmetros

Um AF externo também pode usar o NEF para fornecer ao 5GC determinados parâmetros relacionados ao usuário. Isso não significa que a aplicação possa alterar livremente os parâmetros do núcleo. O conjunto de informações que pode ser provisionado é rigorosamente controlado.

Exemplos típicos incluem Expected UE Behaviour e determinados Network Configuration Parameters. Expected UE Behaviour pode descrever características esperadas de mobilidade de um dispositivo, enquanto os parâmetros de configuração da rede podem incluir tempo máximo de resposta, atraso aceitável de transmissão de dados no downlink ou a quantidade recomendada de pacotes de downlink a armazenar em buffer quando o UE estiver inalcançável.

O NEF encaminha solicitações de parâmetros autorizadas ao UDM, que trabalha com o UDR para ler e atualizar os dados relevantes. O AMF ou outras funções de rede que tenham subscrito essas alterações de dados podem então receber os parâmetros atualizados para processamento posterior na rede.

Gestão de PFD

PFD, ou Packet Flow Description, pode ser entendido como um conjunto de regras usado para detecção de aplicações. Um AF de terceiros pode criar informações de identificação de aplicações por meio do NEF. As regras resultantes podem ser armazenadas no UDR, recuperadas pelo SMF através do NEF e depois entregues ao UPF para detecção de aplicações.

Em comparação com a identificação de tráfego apenas por portas ou endereços básicos, os PFDs podem descrever características de aplicação mais específicas. Um serviço de vídeo, por exemplo, pode ser identificado por determinado padrão de URL ou outras características de tráfego, permitindo que a rede associe o tráfego com maior precisão às regras adequadas de processamento de políticas.

O verdadeiro valor técnico do NEF

Do ponto de vista arquitetural, o papel mais importante do NEF não é adicionar outro nó de encaminhamento. Seu verdadeiro objetivo é criar uma camada gerenciável de exposição de capacidades. Os AFs externos veem interfaces orientadas a serviços, enquanto o trabalho real dentro do 5GC continua sendo executado por funções como controle de políticas do PCF, gestão de sessões do SMF, gestão de dados do UDM e processamento do plano de usuário do UPF.

É por isso que o NEF não deve ser visto como um gateway de API comum. Ele precisa compreender a relação entre solicitações de negócio externas e capacidades do núcleo 3GPP, enquanto trata do controle de segurança, tradução de informações e coordenação de processos entre os dois lados.

O NEF também não substitui outras funções de rede. A aplicação de QoS continua dependendo do controle de políticas e da configuração de recursos de sessão. Eventos de rede continuam sendo detectados pela NF apropriada. Caminhos do plano de usuário continuam sendo ajustados por funções como o SMF, e os dados relacionados ao usuário continuam sendo mantidos pelo UDM e UDR. O papel do NEF é expor essas capacidades internas de forma controlada e padronizada.

Essa capacidade é especialmente importante para serviços 5G B2B2X. Aplicações industriais não precisam compreender toda a topologia interna do 5GC nem construir interfaces proprietárias para cada função de rede. Elas podem enviar requisitos de rede por meio de mecanismos padronizados de exposição. Ao mesmo tempo, o operador mantém o controle da fronteira do núcleo e transforma capacidades de rede selecionadas em serviços que parceiros confiáveis podem utilizar.

Na prática, o NEF ajuda o 5G Core a evoluir de uma rede que fornece principalmente conectividade para uma plataforma capaz de expor capacidades de rede diretamente a aplicações industriais.

Perguntas frequentes

Todos os AFs precisam ser implantados fora da rede do operador?

Não. Um AF pode ser uma aplicação confiável pertencente ou gerida pelo operador, ou uma aplicação de terceiros fora do domínio de confiança do operador. Os métodos de acesso e os controles de segurança podem variar conforme o tipo de AF.

Os dados de negócio são sempre armazenados localmente no NEF?

Não. Algumas informações recebidas pelo NEF podem ser armazenadas no UDR e depois utilizadas por outras funções de rede ou procedimentos posteriores. Portanto, o armazenamento de dados não precisa permanecer vinculado a uma única instância do NEF.

Um Local DN é o mesmo que um UPF?

Não. Um Local DN é uma rede de dados local que hospeda aplicações ou serviços de dados específicos, enquanto o UPF é uma função de rede do plano de usuário do 5GC. O tráfego pode ser roteado por um caminho UPF adequado até um Local DN designado, mas os dois exercem funções diferentes.

O UPF cria regras PFD por conta própria?

Não. As regras PFD podem ser fornecidas por um AF e gerenciadas por meio do NEF. O SMF recupera as regras relevantes e as entrega ao UPF para uma detecção de aplicações mais precisa no plano de usuário.