O verdadeiro desafio em uma implantação com vários PCFs não é a simples existência de várias instâncias de PCF. O problema é que o mesmo UE pode ser encaminhado facilmente para PCFs diferentes durante procedimentos de serviço distintos. Durante o estabelecimento de uma sessão PDU, o SMF pode já ter criado uma associação de política com um PCF. Mais tarde, quando um serviço de voz IMS é acionado e o AF inicia uma nova solicitação de política, o balanceamento de carga pode enviar essa solicitação para outro PCF. Quando isso acontece, o contexto de política entre as duas etapas é quebrado, o que pode causar inconsistências nos fluxos QoS de VoNR, nas regras PCC e nas políticas de sessão.

O BSF, ou Binding Support Function, foi projetado especificamente para resolver esse tipo de problema em que solicitações do mesmo usuário por interfaces diferentes precisam chegar ao mesmo PCF. Ele não gera regras PCC nem substitui o PCF nas decisões de política. Sua principal responsabilidade é manter a relação de vinculação entre uma sessão do UE e o PCF associado, permitindo que consumidores de serviço localizem o PCF que já participou do controle de política daquele usuário quando novas solicitações chegam.

Por que redes com vários PCFs podem selecionar o PCF errado

Para entender o valor do BSF, é útil voltar a um problema semelhante que já existia no 4G. Na arquitetura EPC, o PGW se comunica com o PCRF pela interface Gx, enquanto o P-CSCF no domínio IMS envia solicitações de autorização de política pela interface Rx. Quando vários PCRFs são implantados, os caminhos de sinalização Gx e Rx precisam terminar no mesmo PCRF. Caso contrário, solicitações IMS posteriores não conseguem herdar o contexto de política criado anteriormente na sessão.

Em redes 4G, a solução comum é usar um DRA para roteamento Diameter e vinculação de sessão. Considere um caso típico: quando o PGW estabelece uma conexão PDN para o APN IMS, a solicitação Gx é roteada por DRA1 para PCRF1. O DRA1 registra a relação entre IMSI, endereço IP do UE e PCRF1. Se uma mensagem Rx posterior do P-CSCF for enviada ao DRA2 por causa do balanceamento de carga e o DRA2 encaminhar a solicitação para PCRF2, o PCRF2 não terá conhecimento do contexto de sessão previamente estabelecido no lado do PGW.

O impacto é muito mais sério do que simplesmente selecionar o servidor errado. O PCRF2 não possui o estado existente das regras PCC, portanto novas solicitações de política de mídia recebidas via Rx não podem ser correlacionadas corretamente com as políticas estabelecidas anteriormente via Gx. Em implantações 4G, esse problema pode ser tratado sincronizando em tempo real as informações de vinculação entre vários DRAs, mas essas implementações costumam ser específicas de cada fornecedor, tornando implantações multivendor e operações de longo prazo significativamente mais complexas.

No 5GC, a exigência de consistência de políticas continua a mesma, embora as funções de rede e as interfaces tenham mudado. O SMF se comunica com o PCF por N7, enquanto o AF solicita autorização de política por N5. Em um fluxo completo de política VoNR, o AF primeiro fornece requisitos de fluxo de aplicação e QoS, o PCF gera as regras PCC correspondentes e depois o SMF e o UPF aplicam essas regras. Se diferentes solicitações do mesmo UE chegarem a PCFs diferentes, a continuidade da política ainda pode ser quebrada.

O BSF efetivamente padroniza uma capacidade de vinculação que antes dependia de mecanismos proprietários de sincronização. Ele mantém a relação entre a sessão UE atual e o PCF responsável, ajudando a garantir que solicitações de política posteriores sejam encaminhadas de volta à instância de PCF que já participou da sessão.

Quais informações o BSF vincula?

Do ponto de vista de implementação, o BSF pode ser visto como uma tabela mantida dinamicamente que relaciona o UE à instância responsável por sua política. Depois que um PCF passa a participar do controle de política de uma sessão PDU do UE, ele registra no BSF as informações de vinculação necessárias. Outras funções de rede podem depois consultar o BSF usando identificadores do UE e características da sessão para recuperar as informações de endereçamento do PCF correspondente.

Um registro típico de vinculação pode incluir o endereço IP do UE, SUPI, DNN, S-NSSAI e o endereço do PCF associado. Em implantações que precisam interoperar com interfaces Diameter tradicionais, o registro também pode incluir o nome de host Diameter ou FQDN do PCF.

Esses campos não são coletados apenas por completude. Cada um tem uma função específica para filtrar e identificar a vinculação correta:

• UE IP: Fornece uma forma direta de localizar a vinculação com base no endereço atual do plano de usuário e é um dos parâmetros de consulta mais comuns.

• SUPI: Identifica o assinante no nível da identidade do usuário e ajuda a garantir que a vinculação esteja associada ao UE correto.

• DNN: Distingue diferentes redes de dados usadas pelo mesmo UE, como IMS e serviços normais de Internet.

• S-NSSAI: Identifica ainda mais a fatia de rede associada à sessão em uma implantação 5G com slicing.

• Endereço do PCF: Fornece as informações reais de endereçamento necessárias para que um consumidor de serviço alcance o PCF selecionado.

• Nome de host Diameter/FQDN: Fornece uma referência de mapeamento para o roteamento Diameter tradicional em implantações onde SBI e Diameter coexistem.

Por esse motivo, a vinculação do BSF não deve ser reduzida a um simples mapeamento um-para-um entre um endereço UE e um endereço PCF. Um único UE pode ter várias sessões PDU e acessar diferentes DNNs ou fatias de rede. Se as condições de consulta forem amplas demais, o PCF retornado pode não corresponder ao contexto de serviço atual.

Na implantação, a granularidade da vinculação deve corresponder à granularidade do controle de política. Isso é especialmente importante para serviços IMS, nos quais a continuidade de política é crítica. Se o UE tiver várias fatias ou vários contextos de rede de dados, DNN e S-NSSAI não devem ser omitidos dos critérios de vinculação.

Como o Nbsf_Management deve ser usado?

O BSF expõe o serviço Nbsf_Management sobre SBI. O serviço não é construído em torno de uma grande coleção de APIs sem relação entre si. Em vez disso, oferece quatro operações principais que cobrem todo o ciclo de vida de um registro de vinculação: registro, descoberta, atualização e desregistro. Em implantações práticas, essas quatro operações correspondem diretamente à criação, uso, manutenção e remoção de uma vinculação de PCF.

Registrar: criar primeiro a vinculação

Depois que um PCF é selecionado e passa a participar do controle de política do UE, ele precisa registrar a vinculação no BSF. Uma solicitação típica é:

POST .../pcfBindings

O corpo da solicitação pode incluir campos importantes como endereço IP do UE, SUPI, DNN, S-NSSAI, endereço do PCF e o FQDN correspondente. Depois que o BSF cria com sucesso o registro de vinculação, ele retorna:

201 Created

O momento do registro é uma das armadilhas de implementação mais comuns nesta etapa. A vinculação precisa ser registrada antes que qualquer consulta posterior do lado do serviço seja iniciada. Caso contrário, quando uma solicitação do lado do AF ou uma solicitação compatível com Diameter chegar à rede, o BSF pode ainda não ter a vinculação PCF correspondente, fazendo a consulta falhar.

Descoberta: recuperar o PCF existente a partir do contexto de sessão

A operação Discovery é onde o valor prático do BSF fica mais evidente. Um consumidor de serviço envia uma consulta usando as informações do UE disponíveis no momento:

GET .../pcfBindings?query_parameters

Os parâmetros de consulta podem incluir o endereço IP do UE, SUPI ou GPSI, DNN, S-NSSAI e outros identificadores relevantes. Se uma vinculação correspondente for encontrada, o BSF retorna:

200 OK

A resposta inclui o endereço do PCF correspondente e, quando necessário, o nome de host Diameter ou FQDN. Na arquitetura padronizada, consumidores de serviço podem incluir funções como NEF, AF e NWDAF. Em implantações que ainda precisam suportar roteamento Rx tradicional, as informações de vinculação retornadas também podem ser usadas para selecionar o PCF correto para a sinalização subsequente.

Atualizar e desregistrar: manter o ciclo de vida da vinculação

Se as informações de vinculação mudarem, um registro existente pode ser atualizado usando PATCH:

PATCH .../pcfBindings/{bindingId}

Uma atualização bem-sucedida retorna 200 OK. Quando a sessão é liberada, o PCF deixa de atender o UE ou a vinculação se torna inválida, o registro deve ser excluído usando:

DELETE .../pcfBindings/{bindingId}

Uma exclusão bem-sucedida normalmente retorna 204 No Content. Em implantações reais, a etapa de desregistro não deve ser ignorada. Se registros de vinculação obsoletos permanecerem no BSF por muito tempo, o mesmo assinante poderá mais tarde estabelecer uma nova sessão e corresponder por engano a um PCF antigo. Esse tipo de problema costuma ser mais difícil de diagnosticar do que uma simples vinculação ausente.

Como solucionar problemas de vinculação N7 e Rx

Considerando todo o caminho de sinalização, o fluxo de trabalho do BSF pode ser dividido em três etapas: primeiro registrar a vinculação, depois consultar a vinculação e, por fim, rotear a sinalização de política subsequente de volta ao PCF original. Quando essa sequência está clara, a investigação de problemas de política VoNR torna-se muito mais eficiente do que coletar grandes volumes de sinalização sem uma direção definida.

Etapa um: estabelecer a sessão PDU e registrar o PCF

Depois que uma instância BSF entra em operação, ela primeiro registra suas capacidades e informações de endereçamento no NRF. Em seguida, o UE estabelece uma sessão PDU para o DNN IMS e o SMF solicita controle de política a um PCF. Depois que o PCF é selecionado, ele invoca Nbsf_Management_Register para armazenar no BSF a vinculação entre UE e PCF.

Nesse ponto, o BSF pode conter registros de vinculação semelhantes a:

UE IP1 + DNN1 + S-NSSAI1 + SUPIxx → PCF1
UE IP2 + DNN2 + S-NSSAI2 + SUPIyy → PCF2

Etapa dois: uma chamada VoNR aciona uma consulta de política

Quando o UE inicia uma chamada VoNR, o domínio IMS aciona uma nova solicitação de autorização de política. Na arquitetura 5GC padronizada, AF e PCF trocam informações de política pela interface N5. Em algumas implantações que continuam usando sinalização Diameter IMS tradicional, o P-CSCF ainda pode usar o procedimento Rx/AAR.

A pergunta principal nesta etapa é direta: qual PCF deve receber a solicitação de política?

O solicitante não deve simplesmente selecionar outro PCF de acordo com a lógica normal de balanceamento de carga. Em vez disso, primeiro consulta o BSF usando informações como endereço do UE, DNN e S-NSSAI. O BSF localiza o registro de vinculação existente e retorna a instância PCF que já é responsável pela sessão do UE.

Etapa três: rotear a sinalização subsequente de volta ao PCF original

Depois que o PCF correto é identificado, as solicitações de política seguintes são direcionadas ao mesmo PCF. Isso mantém o contexto de política criado durante o estabelecimento da sessão PDU e as novas solicitações de política geradas durante a etapa de mídia VoNR na mesma instância de controle de política. O PCF pode então gerar e manter regras PCC usando o contexto completo da sessão.

Se uma chamada VoNR puder ser iniciada, mas o comportamento da política QoS estiver anormal, as regras de mídia IMS forem inconsistentes ou apenas alguns assinantes apresentarem falhas intermitentes, o caminho de vinculação do BSF deve ser verificado antes de atribuir imediatamente o problema à rede de rádio.

Uma sequência prática de diagnóstico pode ser dividida em quatro etapas. Primeiro, confirme que a operação BSF Register foi realmente executada após o estabelecimento da sessão PDU. Segundo, verifique se o endereço IP do UE, SUPI, DNN e S-NSSAI armazenados no BSF estão corretos. Terceiro, verifique se as condições de consulta usadas na solicitação Discovery posterior conseguem corresponder de forma única à vinculação original. Quarto, confirme se o endereço PCF ou o identificador Diameter retornado é exatamente o mesmo do PCF que participou originalmente do controle de política N7.

A arquitetura de implantação também precisa ser considerada. Em algumas redes, o BSF pode ser co-localizado com o SMF. Nesse caso, os pontos de captura de pacotes e os fluxos internos podem diferir daqueles de uma implantação BSF independente. No entanto, o princípio fundamental permanece o mesmo: a rede deve manter uma vinculação estável entre a sessão UE e o PCF responsável.

Perguntas frequentes

O BSF e o NRF realizam ambos a seleção de funções de rede?

Não. Suas funções são diferentes. O NRF ajuda as funções de rede a descobrir instâncias NF disponíveis e suas capacidades, atuando mais como um registro de serviços. O BSF armazena uma vinculação já estabelecida entre uma sessão UE específica e um PCF. Em termos simples, o NRF responde “Quais PCFs estão disponíveis?”, enquanto o BSF responde “Qual PCF já é responsável por esta sessão UE?”

Um UE pode ter apenas uma vinculação PCF?

Não necessariamente. Uma vinculação não é definida apenas pela identidade do UE. Ela também pode depender do DNN, do S-NSSAI e do contexto específico da sessão PDU. Se o mesmo UE acessar diferentes redes de dados ou fatias de rede, as vinculações correspondentes podem precisar ser mantidas separadamente.

O BSF e o SMF podem ser implantados na mesma instância de função de rede?

Sim. Uma implantação co-localizada é possível. Nesse caso, a sequência de sinalização visível externamente pode diferir de uma implantação BSF independente, mas a vinculação UE-PCF ainda precisa ser armazenada e usada. Durante a solução de problemas, portanto, a arquitetura real de implantação do fornecedor deve ser confirmada primeiro.

O que deve ser verificado primeiro quando uma consulta ao BSF falha?

Comece por três itens: se o registro de vinculação foi criado com sucesso, se os parâmetros da consulta correspondem aos valores usados no registro e se a vinculação expirou ou foi excluída prematuramente. Se o BSF retornar um registro, verifique também se o endereço PCF, FQDN ou identificador Diameter retornado aponta para a instância PCF esperada.