Quando um UE entra em CM-IDLE através de acesso 3GPP, uma sessão PDU estabelecida pode permanecer enquanto a sua ligação do plano de utilizador é desativada. Os pacotes de downlink podem continuar a chegar ao UPF pela N6 a partir da rede de dados, embora o túnel N3 do lado de acesso necessário à entrega imediata esteja indisponível. O armazenamento temporário pode conservar parte desse tráfego enquanto o plano de controlo tenta restabelecer a entrega.
Na N4, o SMF controla o UPF através de PFCP. Uma regra de ação de armazenamento temporário (BAR) fornece instruções às regras de ação de encaminhamento (FAR) associadas. A distinção é importante: a FAR seleciona o armazenamento através de Apply Action; BAR não identifica pacotes nem inicia paging de forma independente. CM-IDLE também não garante que todos os pacotes sejam armazenados ou que cada notificação provoque paging.
PDR, FAR e BAR têm responsabilidades diferentes
Uma regra de deteção de pacotes (PDR) identifica o tráfego aplicável e referencia uma FAR. FORW solicita encaminhamento com os Forwarding Parameters aplicáveis. BUFF solicita armazenamento temporário. NOCP solicita uma notificação ao plano de controlo sobre o primeiro pacote de downlink armazenado; é uma ação de notificação, não um parâmetro de alocação de memória.
No caso habitual BUFF/NOCP em 5GC, o âmbito do relatório é o primeiro pacote de downlink de cada fluxo QoS para uma determinada FAR. Os pacotes seguintes do mesmo fluxo QoS não exigem, individualmente, outro relatório. Pacotes de outro fluxo QoS ou associados a outra FAR podem originar relatórios adicionais. O armazenamento prolongado pode alterar este comportamento de notificação.
Uma FAR pode referenciar BAR através de BAR ID. Uma BAR pode servir várias FAR associadas, incluindo um buffer partilhado para a sessão PFCP. Em TS 29.244 V18.7.0, pode ser criada, no máximo, uma BAR por sessão PFCP. Criar BAR, por si só, não prova que o tráfego de downlink a utiliza: examine a relação PDR-FAR e o BAR ID da FAR.
As etapas de classificação e encaminhamento são abordadas nos guias relacionados sobre deteção de pacotes por PDR na N4 e encaminhamento FAR e parâmetros de túnel.
O que acontece quando chegam dados de downlink em CM-IDLE?
Considere um UE registado com uma sessão PDU estabelecida. Enquanto a ligação do plano de utilizador está ativa, o UPF encaminha pacotes de downlink para o gNB. Quando essa ligação é desativada, o SMF atualiza as regras N4 e as informações do túnel de acesso relevantes. Para armazenamento no UPF, a FAR afetada pode solicitar BUFF e NOCP em vez de encaminhamento imediato. É uma decisão de controlo de sessão, não uma reação autónoma de BAR a uma alteração do estado de rádio.
Os dados de downlink chegam ao UPF. A PDR correspondente e a FAR associada determinam o tratamento.
Se receber instruções para armazenar e notificar, o UPF armazena os dados e envia um PFCP Session Report Request com um Downlink Data Report. O relatório identifica as PDR relevantes; o SMF pode determinar o fluxo QoS a partir do contexto PDR ou de Downlink Data Service Information.
O SMF confirma o relatório com um PFCP Session Report Response e, quando aplicável, contacta o AMF utilizando Namf_Communication_N1N2MessageTransfer. O AMF pode iniciar paging e o procedimento Service Request para restabelecer a ligação do plano de utilizador.
Depois de estabelecido o túnel do lado de acesso, o SMF atualiza o UPF com a ação de encaminhamento e os parâmetros corretos do túnel. Os pacotes armazenados podem então ser encaminhados segundo as novas instruções.
TS 23.502 designa a troca da etapa 2 como Data Notification e Data Notification Ack. Numa captura N4, utilize os nomes reais da mensagem PFCP e de Downlink Data Report. Chamar «DDN» a toda a troca é uma abreviatura prática, mas não a transforma numa mensagem EPC Downlink Data Notification em S11.
Esta sequência descreve um caso comum de armazenamento no UPF. TS 23.502 também permite encaminhar os dados para armazenamento no SMF quando assim instruído. Um UE pode estar em CM-CONNECTED enquanto uma sessão PDU específica não tem uma ligação ativa do plano de utilizador; RRC_INACTIVE também é distinto de CM-IDLE. O tipo de acesso, MICO, DRX prolongado em modo inativo, restrições de paging e inacessibilidade conhecida podem alterar ou impedir o paging. Examine o estado real da sessão e do acesso antes de aplicar uma explicação baseada no modo inativo.
Os campos BAR devem ser interpretados no contexto do procedimento
As distinções seguintes seguem TS 29.244 V18.7.0, cláusulas 5.2.4, 7.5.2.6, 7.5.4.11 e 7.5.9.2. BAR não é um contentor universal em que todos os ajustes possíveis do buffer tenham de aparecer em cada troca N4.
| Campo | Significado e condições |
|---|---|
| BAR ID | Identifica BAR na sessão PFCP. Uma referência FAR seleciona as instruções de armazenamento associadas a essa BAR. |
| Suggested Buffering Packets Count | Campo dependente de UDBC para sugerir quantos pacotes UL/DL armazenar enquanto se aguardam novas instruções do plano de controlo. Não expressa a capacidade física de memória do UPF. Quando fornecido, as tabelas Create/Update BAR citadas exigem que sejam descartados os pacotes que excedem o limite. |
| DL Buffering Suggested Packet Count | Um campo diferente: o número máximo de pacotes de downlink sugeridos para armazenamento prolongado na sessão PFCP. Não deve ser confundido com Suggested Buffering Packets Count. |
| DL Buffering Duration | Controla o armazenamento prolongado de downlink. O seu fornecimento em PFCP Session Report Response depende do suporte DLBD; através de PFCP Session Modification depende do suporte DBDM e das condições aplicáveis. Não está necessariamente presente no estabelecimento inicial. |
| Downlink Data Notification Delay | Atrasa a notificação após a chegada do pacote, quando aplicável. A cláusula 5.2.4 descreve o seu fornecimento para EPC; não se deve assumir que é um controlo geral do atraso de paging em 5GC apenas por aparecer num diagrama BAR genérico ou num IE agrupado descodificado. |
DL Buffering Duration influencia os relatórios e a conservação. Durante o período especificado de armazenamento prolongado, as novas notificações de chegada de downlink são normalmente suprimidas. Com suporte de Extended DL Buffering Notification Control (EDBNC) e EDBN definido como 1, o UPF passa a comunicar o primeiro pacote armazenado de cada fluxo QoS para uma determinada FAR durante esse período. Assim, NOCP, por si só, não prova que seja devido outro relatório.
Quando termina o armazenamento prolongado, o UPF deixa de aplicar DL Buffering Duration e DL Buffering Suggested Packet Count e remove esses parâmetros de BAR. Novas instruções do plano de controlo determinam se os pacotes já armazenados são encaminhados ou descartados. O armazenamento temporário é um tratamento transitório do tráfego, não armazenamento garantido sem perdas.
Porque uma captura pode não mostrar todos os parâmetros de armazenamento
Comece pelo histórico completo da sessão PFCP. BAR pode ter sido criada no estabelecimento ou numa modificação anterior, enquanto a troca em análise atualiza apenas a FAR. Os campos opcionais e dependentes de capacidades também não precisam de aparecer em todas as mensagens. Um campo opcional ausente é diferente de uma referência não resolvida ou da falta de um campo obrigatório sob determinadas condições.
TS 29.244 permite fornecer opcionalmente parâmetros de armazenamento com BUFF. Contudo, para modificar uma BAR num PFCP Session Report Response, esta já deve ter sido fornecida, mesmo vazia, e associada às FAR. Os limites locais de recursos do UPF não substituem uma associação BAR ID nem um campo exigido pelo procedimento aplicável.
A cláusula 5.2.4.3 apresenta uma opção de implementação mais restrita: quando o UPF suporta armazenamento prolongado configurado para um APN/DNN e/ou S-NSSAI, e se aplicam as restantes condições especificadas, o plano de controlo pode manter o temporizador de armazenamento prolongado em vez de o fornecer ao UPF, mantendo NOCP ativo para notificações de fluxos QoS adicionais. Isto não é uma dispensa geral para substituir todos os parâmetros BAR por configuração local.
Durante o diagnóstico, obtenha as UP Function Features negociadas, o fornecimento anterior de BAR, as associações atuais de regras e os ajustes locais de recursos relevantes. Isto distingue uma omissão opcional normal do uso de funções não suportadas, de uma captura incompleta ou de uma falha real de configuração.
Diagnosticar ação, armazenamento, notificação e recuperação
Uma primeira mensagem atrasada após inatividade, paging bem-sucedido com perda de pacotes iniciais ou buffers UPF em crescimento podem ter causas diferentes. Siga o pacote e o seu estado no plano de controlo ao longo de quatro etapas.
1. Confirmar a ação e a regra correspondente
Verifique se os pacotes de downlink chegam efetivamente ao UPF previsto e correspondem à PDR correta. Siga o FAR ID, examine Apply Action e verifique o resultado aceite de PFCP Session Modification. Se a FAR continuar a encaminhar com informações obsoletas do túnel de acesso, investigue as atualizações de regras e túneis antes de ajustar os parâmetros de armazenamento.
2. Identificar as instruções efetivas de armazenamento
Resolva BAR ID e examine o último Create BAR ou Update BAR no contexto de mensagem adequado. Distinga os dois campos de contagem de pacotes e verifique o suporte das funções. Correlacione os limites configurados com os pacotes realmente armazenados e descartados; uma contagem sugerida não reserva memória física nem garante que todos os pacotes sejam conservados até à reconexão.
3. Verificar o relatório e o seu processamento
Procure PFCP Session Report Request, Downlink Data Report, PDR ID e a resposta correspondente. Verifique o âmbito dos relatórios por fluxo QoS, a supressão de notificações, o armazenamento prolongado e eventuais causas de falha. Se um relatório for aceite sem paging subsequente, examine a troca SMF-AMF e as condições de acessibilidade do UE antes de assumir uma falha de BAR.
4. Verificar a entrega após a recuperação
Após o sucesso de Service Request, confirme que o SMF restabelece FORW e o endereço e TEID atuais do lado de acesso. Compare as chegadas N6, a saída N3 e os contadores do buffer. Um UE acessível ainda pode perder dados se a FAR permanecer em BUFF, as informações do túnel estiverem erradas, o armazenamento tiver expirado ou os pacotes já tiverem sido descartados.
Perguntas frequentes
BUFF precisa de BAR para classificar os pacotes?
Não. A PDR classifica o tráfego e a FAR solicita BUFF. BAR fornece instruções específicas de armazenamento quando provisionada e associada; não é outro classificador de pacotes.
A ausência de Suggested Buffering Packets Count prova uma configuração incorreta?
Não. Esse campo depende do suporte UDBC e é distinto do campo de contagem de pacotes para armazenamento prolongado de downlink. Verifique o contexto da mensagem, as funções negociadas e o estado existente de BAR antes de avaliar a omissão.
Cada Downlink Data Report provoca paging?
Não. O SMF e o AMF aplicam condições de acessibilidade, acesso e política. Um relatório pode conduzir à reativação do plano de utilizador, armazenamento prolongado ou tratamento de falhas; o paging é apenas uma parte possível do procedimento.
Porque podem perder-se pacotes mesmo após uma reconexão bem-sucedida?
O buffer pode ter atingido um limite ou expirado antes da recuperação. A atualização da FAR ou do túnel também pode estar incompleta. A reconexão bem-sucedida, por si só, não verifica os pacotes conservados nem a retoma do encaminhamento N3.
Referências
3GPP TS 29.244 V18.7.0: as cláusulas 5.2.3–5.2.4, 7.5.2.6, 7.5.4.11, 7.5.8–7.5.9 e 8.2.28–8.2.30, 8.2.100 abrangem o tratamento FAR/BAR, os relatórios e os elementos de informação de armazenamento temporário.
3GPP TS 23.502 V18.9.0: a cláusula 4.2.3.3 descreve Network Triggered Service Request, a notificação de dados, as exceções de acessibilidade e o armazenamento prolongado.
