Perguntas e respostas técnicas: Como a BAR na interface N4 controla o armazenamento em buffer de pacotes de downlink e a notificação de dados quando um UE está em CM-IDLE?
Quando um UE entra em CM-IDLE, sua sessão PDU não desaparece. No entanto, o caminho de plano de usuário N3 usado anteriormente para o encaminhamento de downlink pode não estar mais ativo. Se novos dados chegam de uma rede externa neste momento, os pacotes ainda podem alcançar o UPF, mas não podem ser encaminhados imediatamente ao gNB via N3 como seriam em CM-CONNECTED. Portanto, o UPF precisa determinar se os pacotes devem ser armazenados em buffer, quantos pacotes podem ser retidos, por quanto tempo podem permanecer em buffer e quando o plano de controle deve ser notificado de que chegaram dados de downlink.
Dentro da estrutura de regras PFCP na interface N4, a BAR (Buffering Action Rule) fornece as regras para esse comportamento de buffering. No entanto, a BAR não decide de forma independente se o buffering deve ocorrer. A ação de buffering é acionada pela Apply Action na FAR, enquanto a BAR define como esse buffering deve ser realizado. Essa distinção é fundamental para entender a relação entre FAR e BAR.
A BAR Define Como o UPF Armazena os Pacotes em Buffer
Quando o UPF recebe um pacote, ele primeiro usa uma PDR para identificar o tráfego e depois segue a FAR referenciada por essa PDR para determinar a próxima ação. Se a FAR exigir encaminhamento normal, o UPF encaminha o pacote de acordo com os Parâmetros de Encaminhamento. Se a Apply Action da FAR contiver BUFF, o pacote não é enviado imediatamente para a interface de destino e, em vez disso, entra no processo de buffering.
É aqui que a BAR se torna relevante. A FAR pode referenciar uma BAR que informa ao UPF como os pacotes afetados devem ser armazenados em buffer. A relação pode ser resumida da seguinte forma:
A PDR identifica o pacote → A FAR seleciona BUFF/NOCP → A BAR define o comportamento de buffering.
Um equívoco comum é tratar BUFF e BAR como se fossem a mesma coisa. Não são. BUFF responde à pergunta: “Este pacote deve ser armazenado em buffer agora?” A BAR responde à pergunta: “Uma vez selecionado o buffering, em que condições o pacote deve ser armazenado em buffer?” Olhar apenas para BUFF na FAR sem verificar a BAR associada ou a configuração de buffering local do UPF fornece apenas uma parte do panorama do plano de usuário.
NOCP também é comumente associado a esse cenário. Quando o UPF está armazenando pacotes de downlink em buffer, NOCP pode exigir que o UPF notifique o plano de controle de que chegaram dados de downlink para que o SMF possa iniciar os procedimentos de plano de controle seguintes. O buffering e a notificação, portanto, ocorrem como duas tarefas coordenadas: o plano de usuário retém temporariamente os pacotes enquanto o evento é reportado ao plano de controle.
O Cenário Mais Típico da BAR Ocorre Após o UE Entrar em CM-IDLE
O papel da BAR é mais fácil de entender quando um UE faz a transição de CM-CONNECTED para CM-IDLE. Suponha que o UE já tenha concluído o registro e o estabelecimento da sessão PDU. Enquanto está conectado, o caminho de plano de usuário N3 está disponível e o UPF pode encaminhar pacotes de downlink diretamente para o gNB.
Após um período de inatividade, o lado de acesso pode liberar a conexão e o UE entra em CM-IDLE. A sessão PDU permanece no lugar, mas o caminho de encaminhamento de plano de usuário N3 anteriormente ativo não está mais imediatamente disponível. Os servidores externos não estão necessariamente cientes dessa mudança de estado, então novos pacotes IP de downlink ainda podem chegar ao UPF através do N6.
Isso cria o problema-chave: o UPF recebeu os dados, mas atualmente não possui um caminho N3 utilizável pelo qual entregá-los ao UE.
Nesta etapa, o SMF atualiza as regras do plano de usuário via N4 para que a FAR relevante mude do encaminhamento imediato para o comportamento de buffering. Em um caso típico, BUFF e NOCP são habilitados na Apply Action, enquanto FORW não é mais usado como a ação de downlink atual. Quando novos pacotes de downlink chegam, o UPF os retém de acordo com a política de buffering aplicável e reporta a chegada dos dados de downlink ao SMF.
Após receber a notificação, o SMF pode coordenar com o AMF para iniciar os procedimentos necessários para tornar o UE alcançável novamente, incluindo paging quando aplicável. Uma vez que o UE retorna a um estado em que o tráfego do plano de usuário pode ser transportado e o caminho N3 é restaurado, o SMF atualiza as regras do UPF novamente para que o tratamento de downlink mude de buffering para encaminhamento. Os pacotes armazenados em buffer podem então continuar em direção ao UE.
Portanto, a BAR não é simplesmente uma regra estática de alocação de memória. Seu verdadeiro propósito é ajudar o plano de usuário a transpor o período temporário durante o qual os pacotes de downlink já chegaram, mas o encaminhamento imediato ainda não é possível.
Os Parâmetros-Chave da BAR Definem os Limites do Buffering
O buffering não pode continuar indefinidamente. Se o UPF fosse autorizado a reter dados de downlink ilimitados para um UE inalcançável, a memória do plano de usuário poderia ser consumida desnecessariamente. Portanto, a BAR fornece limites para o comportamento de buffering. Dependendo do procedimento PFCP e das capacidades do UPF, eles podem incluir o ID da BAR, limites de contagem de pacotes, duração do buffering e parâmetros de atraso de notificação.
ID da BAR
O ID da BAR identifica exclusivamente a regra de buffering dentro da sessão PFCP e permite que a FAR correspondente referencie a BAR correta. Durante a solução de problemas, ver uma criação de BAR isoladamente não prova que a regra afeta o tráfego sendo analisado. A FAR correspondente também deve ser verificada para confirmar qual ID de BAR ela realmente referencia.
Contagem de Pacotes Sugerida para Buffering
A Contagem de Pacotes Sugerida para Buffering indica o número de pacotes que o UPF é aconselhado a armazenar em buffer para o tráfego aplicável. Uma vez excedido o limite sugerido, pacotes adicionais podem ser descartados. Este parâmetro controla o limite de capacidade de buffering em vez do tempo de buffering.
Sua presença também depende do suporte de recursos do UPF. Se o campo não estiver visível em um trace PFCP, isso por si só não prova que o controle de buffering está ausente. A análise também deve considerar se o UPF suporta a capacidade relevante e se parâmetros de buffering locais estão sendo usados em seu lugar.
Duração do Buffering de Downlink
A Duração do Buffering de Downlink define o período durante o qual os pacotes de downlink podem continuar armazenados em buffer no UPF sob o procedimento aplicável. Ela reflete um princípio de design importante: o buffering é destinado a ser um mecanismo temporário enquanto a entrega do plano de usuário está sendo restaurada, não um armazenamento permanente de pacotes.
Se o UE permanecer inalcançável por um período prolongado, o processo de buffering precisa de uma condição de término definida; caso contrário, os recursos do plano de usuário poderiam permanecer ocupados indefinidamente.
Atraso de Notificação de Dados de Downlink
Em procedimentos e combinações de capacidades suportadas, o Atraso de Notificação de Dados de Downlink pode controlar quanto tempo o UPF espera após receber o primeiro pacote de downlink antes de notificar o plano de controle. Este parâmetro afeta quando a notificação é enviada, em vez de se o pacote deve ser armazenado em buffer.
Portanto, seu comportamento deve ser interpretado no contexto do procedimento PFCP específico, da implementação da rede e das capacidades do UPF, em vez de ser inferido apenas pelo nome do parâmetro.
Por Que Parâmetros Completos da BAR Às Vezes Estão Ausentes nos Traces PFCP?
Este é um dos pontos mais fáceis de interpretar erroneamente ao analisar a BAR. O número de pacotes a armazenar em buffer, a duração do buffering e outros parâmetros de buffering nem sempre precisam ser provisionados dinamicamente via N4. Operadores ou fornecedores de equipamentos também podem configurar políticas de buffering localmente no UPF.
Com essa implementação, o SMF pode precisar apenas alterar a ação da FAR dinamicamente. Por exemplo, após o UE entrar em CM-IDLE, o SMF pode usar a Modificação de Sessão PFCP para atualizar a FAR relevante para BUFF/NOCP. Uma vez que o UPF vê a ação de buffering, ele pode aplicar limites de contagem de pacotes e duração configurados localmente.
Portanto, a seguinte observação em um trace não é automaticamente anormal:
A FAR solicita BUFF, mas as mensagens PFCP não contêm os parâmetros completos da BAR esperados pelo engenheiro.
Pelo menos duas perguntas adicionais devem ser verificadas: se o UPF está usando valores de buffering configurados localmente e se o UPF suporta o provisionamento dinâmico dos parâmetros relevantes da BAR. Caso contrário, uma diferença de implementação pode ser confundida com uma regra ausente do SMF.
A configuração local também pode ter vantagens práticas. Ela pode reduzir parte da sinalização N4 e acomodar diferenças de capacidade entre implementações de UPF. A contrapartida é que parte do comportamento de buffering não é mais totalmente visível em um único trace PFCP, portanto, a solução de problemas entre múltiplos fornecedores pode exigir tanto a análise de sinalização quanto a inspeção da configuração local do UPF.
Como o Fluxo PFCP Deve Ser Entendido Quando Dados de Downlink Chegam em CM-IDLE?
A BAR é mais fácil de entender quando colocada de volta no procedimento completo, em vez de analisada como um elemento de informação isolado.
Enquanto o UE está em CM-CONNECTED, o caminho N3 está disponível e o UPF encaminha pacotes de downlink de acordo com a FAR normal. Após um período de inatividade, a conexão do lado do acesso é liberada. Uma vez que o SMF toma conhecimento de que o estado da conexão do plano de usuário mudou, ele usa a Modificação de Sessão PFCP para atualizar as regras relevantes do UPF.
O ponto importante é que a sessão PDU não foi excluída. Em vez disso, o caminho atual do plano de usuário de downlink está temporariamente indisponível para entrega imediata. Portanto, a FAR relevante pode entrar em comportamento de buffering habilitando BUFF e a ação de notificação ao plano de controle necessária, enquanto a BAR ou a configuração local do UPF fornece as condições detalhadas de buffering.
Quando um servidor da Internet ou aplicativo envia posteriormente novos dados de downlink, os pacotes chegam primeiro ao UPF. O UPF usa a PDR para identificar o tráfego e, em seguida, aplica a FAR associada. Como a ação atual não é mais FORW, os pacotes são armazenados em buffer. Ao mesmo tempo, o UPF reporta a chegada dos dados de downlink ao SMF através do mecanismo de relatório PFCP.
O SMF então coordena com os procedimentos do lado do AMF para que o UE possa se tornar alcançável novamente e o caminho do plano de usuário possa ser restabelecido. Uma vez que o encaminhamento N3 se torna disponível novamente, a FAR no N4 é atualizada novamente para encaminhamento normal e o UPF pode continuar entregando tráfego de downlink ao UE.
A lógica geral pode ser resumida como:
O UE entra em CM-IDLE → N3 fica temporariamente indisponível → O SMF atualiza FAR/BAR → Os dados de downlink chegam ao UPF → O UPF armazena em buffer e reporta → O plano de controle restaura a alcançabilidade do UE → N3 é restaurado → A FAR retorna ao encaminhamento.
Portanto, a BAR controla o comportamento do plano de usuário durante o período em que os dados já chegaram, mas o caminho de entrega ainda não retornou.
A Solução de Problemas da BAR Deve Seguir Quatro Passos: Ação, Buffering, Notificação e Recuperação
Problemas relacionados à BAR raramente aparecem como um “erro de BAR” explícito. Mais frequentemente, o sintoma é que o primeiro tráfego de downlink após o UE entrar em um estado inativo se comporta de forma anormal. Um aplicativo pode funcionar normalmente enquanto ativo, mas após um período de inatividade a próxima mensagem chega com atraso perceptível. Em outro caso, o UE pode ser paginado e reconectado com sucesso, mas os primeiros pacotes de downlink já foram perdidos.
Esses problemas podem ser analisados em quatro etapas.
Passo 1: Confirme que a FAR Realmente Entrou no Modo de Buffering
Comece com a FAR referenciada pela PDR de downlink relevante e confirme que a Modificação de Sessão PFCP esperada ocorreu após o UE entrar em CM-IDLE. Verifique se a Apply Action mudou do comportamento FORW normal para as ações BUFF e de notificação esperadas para o cenário.
Se a FAR ainda tentar encaminhar pacotes para um caminho de plano de usuário que não é mais utilizável, o problema não é principalmente uma questão de BAR.
Passo 2: Determine Quais Regras de Buffering o UPF Está Aplicando
Verifique o ID da BAR referenciado pela FAR e, em seguida, examine os parâmetros de Create BAR ou Update BAR correspondentes. Se o trace PFCP não contiver os parâmetros de buffering completos, continue verificando a configuração de buffering local do UPF e as capacidades suportadas.
Se o limite de contagem de pacotes for muito pequeno, alguns dos primeiros pacotes de downlink podem ser descartados antes que o UE se torne alcançável novamente. Se o comportamento de buffering observado diferir substancialmente das expectativas, a própria associação da BAR também deve ser verificada.
Passo 3: Confirme que o UPF Reportou a Chegada dos Dados de Downlink
Armazenar pacotes em buffer por si só não restaura a comunicação com o UE. Se o plano de controle não estiver ciente de que novos dados de downlink chegaram, o procedimento subsequente de paging ou recuperação do plano de usuário não será iniciado. Portanto, o trace deve ser verificado quanto ao Relatório de Sessão PFCP apropriado e ao processamento correto pelo SMF.
Se os pacotes já estão armazenados em buffer no UPF, mas nenhum procedimento de plano de controle se segue, a solução de problemas deve passar dos parâmetros da BAR para o caminho de relatório UPF-SMF e os procedimentos SMF subsequentes.
Passo 4: Confirme que o Encaminhamento é Retomado Após a Recuperação do Plano de Usuário
Depois que o UE se torna alcançável novamente, verifique se o SMF atualiza as regras N4 corretamente para que a FAR de downlink mude de buffering para encaminhamento normal e os parâmetros de encaminhamento N3 necessários sejam restaurados.
Se o paging for bem-sucedido e o UE tiver retornado, mas a FAR permanecer em BUFF, o sistema pode entrar em um estado em que o UE está alcançável enquanto os pacotes continuam permanecendo no UPF. Portanto, a solução de problemas da BAR deve continuar até que o caminho de encaminhamento do plano de usuário seja totalmente restaurado.
O Valor Central da BAR
Dentro da estrutura de regras PFCP, a BAR não participa de cada pacote encaminhado normalmente da mesma forma que a PDR e a FAR. Sua importância se torna mais visível em uma situação específica, mas crítica: a sessão ainda existe, mas o caminho atual do plano de usuário não pode entregar imediatamente os dados de downlink recém-chegados.
A FAR muda a ação de processamento de pacotes de FORW para BUFF, a BAR define os limites de buffering, o UPF retém temporariamente os pacotes e reporta sua chegada, e funções do plano de controle como SMF e AMF coordenam a restauração da alcançabilidade do UE. Juntos, esses mecanismos transpõem a transição da indisponibilidade temporária de entrega de volta para um caminho de plano de usuário ativo.
Portanto, a BAR não deve ser entendida apenas como “Buffering Action Rule = uma regra de buffering de pacotes”. Uma interpretação mais útil é: a BAR diz ao UPF como gerenciar pacotes de downlink que já chegaram enquanto o caminho de entrega do plano de usuário está temporariamente indisponível. Uma vez que a BAR é vista em conjunto com CM-IDLE, FAR BUFF/NOCP, Relatório de Sessão PFCP e os procedimentos subsequentes de paging e recuperação do plano de usuário, seu papel na interface N4 se torna muito mais claro.
Perguntas Frequentes
Qual é a diferença entre BAR e BUFF na FAR?
BUFF é uma Apply Action na FAR que indica que os pacotes correspondentes devem ser armazenados em buffer em vez de encaminhados imediatamente. A BAR define como esse buffering deve ser realizado, como limites de contagem de pacotes, duração do buffering ou outras condições aplicáveis. Em termos simples, a FAR decide que o buffering é necessário, enquanto a BAR define como o buffering é realizado.
A BAR pode operar independentemente de uma FAR?
A BAR não deve ser tratada como uma regra de correspondência de pacotes independente. O pacote é primeiro correspondido por uma PDR, que referencia a FAR relevante. Quando essa FAR exige buffering e referencia a BAR aplicável, os parâmetros da BAR são então usados para controlar como esses pacotes são armazenados em buffer.
Por que os pacotes de downlink não são simplesmente descartados quando o UE entra em CM-IDLE?
CM-IDLE não significa que a sessão PDU foi excluída. Aplicativos externos podem continuar enviando dados enquanto o caminho de entrega do plano de usuário está apenas temporariamente indisponível. O buffering de curto prazo permite reter parte desse tráfego de downlink enquanto o plano de controle restaura a alcançabilidade do UE, ajudando a reduzir a interrupção da continuidade do aplicativo.
A ausência da Contagem de Pacotes Sugerida para Buffering significa que a BAR está mal configurada?
Não necessariamente. O aparecimento desse parâmetro depende do procedimento PFCP, da capacidade do UPF e da implementação. Limites de contagem de pacotes e outros comportamentos de buffering também podem ser configurados localmente no UPF, portanto, o suporte de capacidade, a associação da BAR e a configuração de buffering do lado do dispositivo devem ser verificados.
Por que o UE ainda não recebe dados mesmo que o UPF tenha armazenado os pacotes de downlink em buffer?
O buffering é apenas uma parte do procedimento. O UPF também deve reportar a chegada dos dados de downlink ao SMF, o plano de controle deve iniciar os procedimentos necessários para restaurar a alcançabilidade do UE, e o SMF deve atualizar a FAR e os parâmetros de encaminhamento N3 uma vez que o caminho do plano de usuário esteja disponível novamente. Uma falha em qualquer uma dessas etapas pode deixar os pacotes armazenados em buffer ou eventualmente fazer com que sejam descartados.
