Cuando un UE entra en CM-IDLE mediante acceso 3GPP, una sesión PDU establecida puede mantenerse mientras se desactiva su conexión del plano de usuario. Los paquetes de enlace descendente pueden seguir llegando al UPF desde la red de datos por N6, aunque no esté disponible el túnel N3 del lado de acceso necesario para la entrega inmediata. El almacenamiento temporal puede conservar parte de ese tráfico mientras el plano de control intenta restablecer la entrega.
En N4, el SMF controla el UPF mediante PFCP. Una regla de acción de almacenamiento temporal (BAR) proporciona instrucciones de almacenamiento a las reglas de acción de reenvío (FAR) asociadas. La distinción es importante: la FAR selecciona el almacenamiento mediante Apply Action; BAR no identifica paquetes ni inicia la búsqueda de forma independiente. CM-IDLE tampoco garantiza que se almacenen todos los paquetes ni que cada notificación provoque una búsqueda.
PDR, FAR y BAR tienen responsabilidades diferentes
Una regla de detección de paquetes (PDR) identifica el tráfico aplicable y hace referencia a una FAR. FORW solicita el reenvío con los Forwarding Parameters correspondientes. BUFF solicita almacenamiento temporal. NOCP solicita notificar al plano de control el primer paquete de enlace descendente almacenado; es una acción de notificación, no un parámetro de asignación de memoria.
En el caso habitual de BUFF/NOCP en 5GC, se informa del primer paquete de enlace descendente de cada flujo QoS para una FAR determinada. Los paquetes posteriores del mismo flujo QoS no requieren cada uno un nuevo informe. Los paquetes de otro flujo QoS o asociados a otra FAR pueden generar informes adicionales. El almacenamiento prolongado puede modificar este comportamiento de notificación.
Una FAR puede hacer referencia a BAR mediante BAR ID. Una BAR puede servir a varias FAR asociadas, incluido un búfer compartido para la sesión PFCP. En TS 29.244 V18.7.0, se permite crear como máximo una BAR por sesión PFCP. La creación de BAR por sí sola no demuestra que el tráfico de enlace descendente la utilice: examine la relación entre PDR y FAR y el BAR ID de la FAR.
Las etapas de clasificación y reenvío se explican en las guías relacionadas sobre detección de paquetes mediante PDR en N4 y reenvío FAR y parámetros de túnel.
¿Qué ocurre cuando llegan datos de enlace descendente en CM-IDLE?
Considere un UE registrado con una sesión PDU establecida. Mientras la conexión del plano de usuario está activa, el UPF reenvía paquetes de enlace descendente hacia el gNB. Cuando se desactiva esa conexión, el SMF actualiza las reglas N4 y la información del túnel de acceso correspondientes. Para el almacenamiento en el UPF, la FAR afectada puede solicitar BUFF y NOCP en lugar del reenvío inmediato. Es una decisión de control de sesión, no una reacción autónoma de BAR ante un cambio del estado radioeléctrico.
Los datos de enlace descendente llegan al UPF. La PDR coincidente y la FAR asociada determinan su tratamiento.
Si recibe instrucciones de almacenar y notificar, el UPF almacena los datos y envía un PFCP Session Report Request con un Downlink Data Report. El informe identifica las PDR correspondientes; el SMF puede determinar el flujo QoS a partir del contexto PDR o de Downlink Data Service Information.
El SMF confirma el informe con un PFCP Session Report Response y, cuando corresponde, contacta con el AMF mediante Namf_Communication_N1N2MessageTransfer. El AMF puede iniciar la búsqueda y el procedimiento Service Request para restablecer la conexión del plano de usuario.
Una vez establecido el túnel del lado de acceso, el SMF actualiza el UPF con la acción de reenvío y los parámetros correctos del túnel. Los paquetes almacenados pueden entonces reenviarse conforme a las nuevas instrucciones.
TS 23.502 denomina al intercambio de etapa 2 Data Notification y Data Notification Ack. En una captura N4, utilice los nombres reales del mensaje PFCP y de Downlink Data Report. Llamar «DDN» a todo el intercambio es una abreviatura práctica, pero no lo convierte en un mensaje EPC Downlink Data Notification sobre S11.
Esta secuencia describe un caso habitual de almacenamiento en el UPF. TS 23.502 también permite reenviar los datos al SMF para almacenarlos cuando así se indica. Un UE puede estar en CM-CONNECTED aunque una sesión PDU concreta no tenga una conexión activa del plano de usuario; RRC_INACTIVE también es distinto de CM-IDLE. El tipo de acceso, MICO, DRX prolongada en modo inactivo, las restricciones de búsqueda y la inaccesibilidad conocida pueden modificar o impedir la búsqueda. Examine el estado real de la sesión y del acceso antes de aplicar una explicación basada en el modo inactivo.
Los campos BAR deben interpretarse en el contexto del procedimiento
Las siguientes distinciones se basan en TS 29.244 V18.7.0, cláusulas 5.2.4, 7.5.2.6, 7.5.4.11 y 7.5.9.2. BAR no es un contenedor universal en el que todos los ajustes posibles del búfer deban aparecer en cada intercambio N4.
| Campo | Significado y condiciones |
|---|---|
| BAR ID | Identifica BAR dentro de la sesión PFCP. Una referencia FAR selecciona las instrucciones de almacenamiento asociadas a esa BAR. |
| Suggested Buffering Packets Count | Campo dependiente de UDBC que sugiere cuántos paquetes UL/DL almacenar mientras se esperan nuevas instrucciones del plano de control. No expresa la capacidad física de memoria del UPF. Cuando se proporciona, las tablas Create/Update BAR citadas exigen descartar los paquetes que superen el límite. |
| DL Buffering Suggested Packet Count | Un campo diferente: el número máximo de paquetes de enlace descendente que se sugiere conservar durante el almacenamiento prolongado en la sesión PFCP. No debe confundirse con Suggested Buffering Packets Count. |
| DL Buffering Duration | Controla el almacenamiento prolongado de enlace descendente. Su provisión en PFCP Session Report Response depende del soporte DLBD; mediante PFCP Session Modification depende del soporte DBDM y de las condiciones aplicables. No aparece necesariamente durante el establecimiento inicial. |
| Downlink Data Notification Delay | Retrasa la notificación tras la llegada del paquete cuando corresponde. La cláusula 5.2.4 describe su provisión para EPC; no suponga que es un control general del retardo de búsqueda en 5GC solo porque aparezca en un diagrama BAR genérico o en un IE agrupado decodificado. |
DL Buffering Duration influye tanto en la notificación como en la conservación. Durante el período especificado de almacenamiento prolongado, normalmente se suprimen las nuevas notificaciones de llegada de datos. Con soporte de Extended DL Buffering Notification Control (EDBNC) y EDBN establecido en 1, el UPF informa, en cambio, del primer paquete almacenado de cada flujo QoS para una FAR determinada durante ese período. Por tanto, NOCP por sí solo no demuestra que deba emitirse otro informe.
Cuando finaliza el almacenamiento prolongado, el UPF deja de aplicar DL Buffering Duration y DL Buffering Suggested Packet Count y elimina esos parámetros de BAR. Las nuevas instrucciones del plano de control determinan si se reenvían o descartan los paquetes ya almacenados. El almacenamiento temporal es un tratamiento transitorio del tráfico, no un almacenamiento sin pérdidas garantizado.
Por qué una traza puede no mostrar todos los parámetros de almacenamiento
Empiece por el historial completo de la sesión PFCP. BAR puede haberse creado durante el establecimiento o una modificación anterior, mientras que el intercambio examinado solo actualiza la FAR. Los campos opcionales y dependientes de capacidades tampoco tienen que aparecer en cada mensaje. La ausencia de un campo opcional es distinta de una referencia sin resolver o de la falta de un campo obligatorio bajo determinadas condiciones.
TS 29.244 permite proporcionar opcionalmente parámetros de almacenamiento con BUFF. Sin embargo, para modificar una BAR en un PFCP Session Report Response, esta debe haberse proporcionado previamente, aunque esté vacía, y estar asociada a las FAR. Los límites de recursos locales del UPF no pueden sustituir una asociación BAR ID ni un campo exigido por el procedimiento aplicable.
La cláusula 5.2.4.3 presenta una opción de implementación más limitada: cuando el UPF admite almacenamiento prolongado configurado para un APN/DNN y/o S-NSSAI, y se cumplen las demás condiciones especificadas, el plano de control puede conservar él mismo el temporizador de almacenamiento prolongado en vez de proporcionarlo al UPF, manteniendo NOCP habilitado para notificaciones de flujos QoS adicionales. Esto no es una exención general que permita sustituir cualquier parámetro BAR por configuración local.
Durante el diagnóstico, obtenga UP Function Features negociadas, la provisión BAR anterior, las asociaciones actuales de reglas y los ajustes locales de recursos pertinentes. Así se distingue una omisión opcional normal del uso de funciones no admitidas, una captura incompleta o un fallo real de provisión.
Diagnosticar acción, almacenamiento, notificación y recuperación
Un primer mensaje retrasado tras la inactividad, una búsqueda correcta con pérdida de paquetes iniciales o un crecimiento de los búferes del UPF pueden tener causas distintas. Siga el paquete y su estado en el plano de control a través de cuatro etapas.
1. Confirmar la acción y la regla coincidente
Verifique que los paquetes de enlace descendente llegan realmente al UPF previsto y coinciden con la PDR correcta. Siga su FAR ID, examine Apply Action y compruebe el resultado aceptado de PFCP Session Modification. Si la FAR sigue reenviando con información obsoleta del túnel de acceso, investigue las actualizaciones de reglas y túneles antes de ajustar parámetros de almacenamiento.
2. Identificar las instrucciones efectivas de almacenamiento
Resuelva BAR ID y examine el último Create BAR o Update BAR en el contexto de mensaje adecuado. Distinga los dos campos de cantidad de paquetes y verifique el soporte de funciones. Correlacione los límites configurados con los paquetes realmente almacenados y descartados; una cantidad sugerida no reserva memoria física ni garantiza que todos los paquetes sobrevivan hasta la reconexión.
3. Verificar el informe y su procesamiento
Busque PFCP Session Report Request, Downlink Data Report, PDR ID y la respuesta correspondiente. Compruebe el alcance de los informes por flujo QoS, la supresión de notificaciones, el almacenamiento prolongado y las causas de fallo. Si se acepta un informe pero no sigue una búsqueda, examine el intercambio SMF-AMF y las condiciones de accesibilidad del UE antes de atribuir el fallo a BAR.
4. Verificar la entrega después de la recuperación
Tras completarse correctamente Service Request, confirme que el SMF restablece FORW y la dirección y el TEID actuales del lado de acceso. Compare las llegadas N6, la salida N3 y los contadores del búfer. Un UE accesible aún puede perder datos si la FAR permanece en BUFF, la información del túnel es incorrecta, el almacenamiento ha caducado o los paquetes ya se han descartado.
Preguntas frecuentes
¿BUFF necesita BAR para clasificar paquetes?
No. La PDR clasifica el tráfico y la FAR solicita BUFF. BAR proporciona instrucciones específicas de almacenamiento cuando está provisionada y asociada; no es otro clasificador de paquetes.
¿La ausencia de Suggested Buffering Packets Count demuestra una configuración incorrecta?
No. Ese campo depende del soporte UDBC y es distinto del campo de cantidad de paquetes de enlace descendente para almacenamiento prolongado. Compruebe el contexto del mensaje, las funciones negociadas y el estado existente de BAR antes de valorar la omisión.
¿Cada Downlink Data Report provoca una búsqueda?
No. El SMF y el AMF aplican condiciones de accesibilidad, acceso y política. Un informe puede dar lugar a reactivación del plano de usuario, almacenamiento prolongado o gestión de fallos; la búsqueda es solo una posible parte del procedimiento.
¿Por qué pueden perderse paquetes incluso después de una reconexión correcta?
El búfer puede haber alcanzado un límite o caducado antes de la recuperación. También puede estar incompleta la actualización de la FAR o del túnel. La reconexión correcta por sí sola no verifica los paquetes conservados ni la reanudación del reenvío N3.
Referencias
3GPP TS 29.244 V18.7.0: las cláusulas 5.2.3–5.2.4, 7.5.2.6, 7.5.4.11, 7.5.8–7.5.9 y 8.2.28–8.2.30, 8.2.100 cubren la gestión FAR/BAR, los informes y los elementos de información de almacenamiento temporal.
3GPP TS 23.502 V18.9.0: la cláusula 4.2.3.3 describe Network Triggered Service Request, la notificación de datos, las excepciones de accesibilidad y el almacenamiento prolongado.
