Lorsqu'un UE passe en CM-IDLE sur un accès 3GPP, une session PDU établie peut être conservée alors que sa connexion du plan utilisateur est désactivée. Des paquets descendants peuvent toujours parvenir à l'UPF depuis le réseau de données par N6, même si le tunnel N3 côté accès nécessaire à leur livraison immédiate est indisponible. La mise en tampon peut conserver une partie de ce trafic pendant que le plan de contrôle tente de rétablir la livraison.
Sur N4, le SMF contrôle l'UPF au moyen de PFCP. Une règle d'action de mise en tampon (BAR) fournit des instructions aux règles d'action de transfert (FAR) associées. La distinction est essentielle : la FAR sélectionne la mise en tampon par Apply Action ; BAR ne reconnaît pas les paquets et ne déclenche pas le paging de façon autonome. CM-IDLE ne garantit pas non plus que chaque paquet sera conservé ou que chaque notification entraînera un paging.
PDR, FAR et BAR ont des responsabilités différentes
Une règle de détection de paquets (PDR) identifie le trafic concerné et référence une FAR. FORW demande le transfert selon les Forwarding Parameters applicables. BUFF demande la mise en tampon. NOCP demande de notifier au plan de contrôle le premier paquet descendant mis en tampon ; c'est une action de notification, pas un paramètre d'allocation mémoire.
Dans le cas ordinaire BUFF/NOCP en 5GC, le rapport porte sur le premier paquet descendant de chaque flux QoS pour une FAR donnée. Les paquets suivants du même flux QoS ne nécessitent pas chacun un nouveau rapport. Des paquets d'un autre flux QoS ou associés à une autre FAR peuvent produire des rapports supplémentaires. La mise en tampon prolongée peut modifier ce comportement.
Une FAR peut référencer BAR par BAR ID. Une BAR peut servir plusieurs FAR associées, notamment pour un tampon partagé à l'échelle de la session PFCP. Dans TS 29.244 V18.7.0, une seule BAR au maximum peut être créée par session PFCP. Créer BAR ne prouve pas à lui seul que le trafic descendant l'utilise : examinez la relation PDR-FAR et le BAR ID de la FAR.
Les étapes de classification et de transfert sont détaillées dans les guides consacrés à la détection des paquets par PDR sur N4 et au transfert FAR et aux paramètres de tunnel.
Que se passe-t-il lorsque des données descendantes arrivent en CM-IDLE ?
Prenons un UE enregistré avec une session PDU établie. Tant que la connexion du plan utilisateur est active, l'UPF transfère les paquets descendants vers le gNB. Quand cette connexion est désactivée, le SMF met à jour les règles N4 et les informations de tunnel d'accès concernées. Pour une mise en tampon dans l'UPF, la FAR concernée peut demander BUFF et NOCP au lieu d'un transfert immédiat. Il s'agit d'une décision de contrôle de session, pas d'une réaction autonome de BAR à un changement d'état radio.
Les données descendantes arrivent à l'UPF. La PDR correspondante et la FAR associée déterminent leur traitement.
S'il reçoit l'instruction de mettre en tampon et de notifier, l'UPF conserve les données et envoie un PFCP Session Report Request contenant un Downlink Data Report. Le rapport identifie les PDR concernées ; le SMF peut déterminer le flux QoS à partir du contexte PDR ou de Downlink Data Service Information.
Le SMF acquitte le rapport avec un PFCP Session Report Response et contacte, le cas échéant, l'AMF au moyen de Namf_Communication_N1N2MessageTransfer. L'AMF peut déclencher le paging et la procédure Service Request pour rétablir la connexion du plan utilisateur.
Une fois le tunnel côté accès établi, le SMF met à jour l'UPF avec l'action de transfert et les bons paramètres de tunnel. Les paquets conservés peuvent alors être transférés selon les nouvelles instructions.
TS 23.502 nomme l'échange de niveau 2 Data Notification et Data Notification Ack. Dans une capture N4, utilisez les noms réels du message PFCP et de Downlink Data Report. Appeler l'ensemble « DDN » est un raccourci pratique, mais n'en fait pas un message EPC Downlink Data Notification sur S11.
Cette séquence décrit un cas courant de mise en tampon dans l'UPF. TS 23.502 permet aussi de transférer les données au SMF pour qu'il les conserve, si cela est demandé. Un UE peut être en CM-CONNECTED alors qu'une session PDU particulière ne possède pas de connexion active du plan utilisateur ; RRC_INACTIVE est également distinct de CM-IDLE. Le type d'accès, MICO, le DRX étendu en veille, les restrictions de paging et une injoignabilité connue peuvent modifier ou empêcher le paging. Vérifiez les états réels de la session et de l'accès avant d'appliquer une explication fondée sur le mode veille.
Les champs BAR doivent être interprétés dans le contexte de leur procédure
Les distinctions suivantes suivent TS 29.244 V18.7.0, clauses 5.2.4, 7.5.2.6, 7.5.4.11 et 7.5.9.2. BAR n'est pas un conteneur universel devant présenter tous les réglages possibles de tampon dans chaque échange N4.
| Champ | Signification et conditions |
|---|---|
| BAR ID | Identifie BAR dans la session PFCP. Une référence FAR sélectionne les instructions de mise en tampon associées à cette BAR. |
| Suggested Buffering Packets Count | Champ dépendant d'UDBC indiquant un nombre suggéré de paquets UL/DL à conserver en attendant de nouvelles instructions du plan de contrôle. Il ne décrit pas la capacité mémoire physique de l'UPF. Lorsqu'il est fourni, les tableaux Create/Update BAR cités imposent de supprimer les paquets dépassant la limite. |
| DL Buffering Suggested Packet Count | Champ distinct : le nombre maximal de paquets descendants qu'il est suggéré de conserver pour la mise en tampon prolongée dans la session PFCP. Ne pas le confondre avec Suggested Buffering Packets Count. |
| DL Buffering Duration | Contrôle la mise en tampon descendante prolongée. Sa fourniture dans PFCP Session Report Response dépend du support de DLBD ; via PFCP Session Modification, elle dépend de DBDM et des conditions applicables. Il n'est pas nécessairement présent lors de l'établissement initial. |
| Downlink Data Notification Delay | Retarde la notification après l'arrivée d'un paquet, lorsque cela s'applique. La clause 5.2.4 décrit sa fourniture pour EPC ; sa présence dans un schéma BAR générique ou un IE groupé décodé ne suffit pas à en faire une commande générale du délai de paging en 5GC. |
DL Buffering Duration agit sur les rapports comme sur la conservation. Pendant la période de mise en tampon prolongée spécifiée, les notifications supplémentaires d'arrivée de données descendantes sont normalement supprimées. Avec le support de Extended DL Buffering Notification Control (EDBNC) et EDBN réglé à 1, l'UPF signale au contraire le premier paquet conservé de chaque flux QoS pour une FAR donnée pendant cette période. NOCP seul ne prouve donc pas qu'un autre rapport est dû.
À la fin de la mise en tampon prolongée, l'UPF cesse d'appliquer DL Buffering Duration et DL Buffering Suggested Packet Count et supprime ces paramètres de BAR. De nouvelles instructions du plan de contrôle déterminent si les paquets déjà conservés sont transférés ou supprimés. La mise en tampon est un traitement temporaire du trafic, pas un stockage garanti sans perte.
Pourquoi une trace peut ne pas montrer tous les paramètres de mise en tampon
Commencez par l'historique complet de la session PFCP. BAR peut avoir été créée à l'établissement ou lors d'une modification antérieure, tandis que l'échange examiné met uniquement à jour la FAR. Les champs facultatifs et dépendant des capacités n'ont pas non plus à figurer dans chaque message. Un champ facultatif absent est différent d'une référence non résolue ou d'un champ manquant alors que les conditions le rendent obligatoire.
TS 29.244 permet de fournir facultativement des paramètres de mise en tampon avec BUFF. Cependant, pour modifier une BAR dans un PFCP Session Report Response, celle-ci doit déjà avoir été fournie, même vide, et associée aux FAR. Les limites locales de ressources de l'UPF ne remplacent ni une association BAR ID ni un champ exigé par la procédure applicable.
La clause 5.2.4.3 présente une option d'implémentation plus étroite : lorsque l'UPF prend en charge une mise en tampon prolongée configurée pour un APN/DNN et/ou un S-NSSAI, et que les autres conditions spécifiées s'appliquent, le plan de contrôle peut garder lui-même le temporisateur au lieu de le fournir à l'UPF, tout en maintenant NOCP activé pour les notifications de flux QoS supplémentaires. Ce n'est pas une dispense générale permettant de remplacer tous les paramètres BAR par une configuration locale.
Pour le diagnostic, obtenez les UP Function Features négociées, la configuration BAR antérieure, les associations de règles actuelles et les réglages locaux de ressources pertinents. Cela distingue l'absence normale d'un paramètre facultatif d'une fonction non prise en charge, d'une capture incomplète ou d'un véritable défaut de configuration.
Diagnostiquer l'action, la mise en tampon, la notification et la reprise
Un premier message retardé après inactivité, un paging réussi avec des paquets initiaux manquants ou des tampons UPF qui grossissent peuvent avoir des causes différentes. Suivez le paquet et son état dans le plan de contrôle en quatre étapes.
1. Confirmer l'action et la règle correspondante
Vérifiez que les paquets descendants atteignent bien l'UPF prévu et correspondent à la bonne PDR. Suivez son FAR ID, examinez Apply Action et vérifiez l'acceptation de PFCP Session Modification. Si la FAR transfère encore avec des informations de tunnel d'accès obsolètes, examinez les mises à jour des règles et du tunnel avant de modifier les paramètres de tampon.
2. Identifier les instructions de mise en tampon effectives
Résolvez BAR ID et examinez le dernier Create BAR ou Update BAR dans le contexte de message adéquat. Distinguez les deux champs de nombre de paquets et vérifiez le support des fonctions. Rapprochez les limites configurées des paquets réellement conservés et supprimés ; un nombre suggéré ne réserve pas de mémoire physique et ne garantit pas la conservation de chaque paquet jusqu'à la reconnexion.
3. Vérifier le rapport et son traitement
Recherchez PFCP Session Report Request, Downlink Data Report, PDR ID et la réponse correspondante. Vérifiez la portée des rapports par flux QoS, la suppression des notifications, la mise en tampon prolongée et les causes d'échec. Si un rapport est accepté sans paging ultérieur, examinez l'échange SMF-AMF et les conditions de joignabilité de l'UE avant de conclure à un défaut de BAR.
4. Vérifier la livraison après rétablissement
Après la réussite de Service Request, vérifiez que le SMF rétablit FORW ainsi que l'adresse et le TEID actuels côté accès. Comparez les arrivées sur N6, les sorties sur N3 et les compteurs du tampon. Un UE joignable peut encore perdre des données si la FAR reste en BUFF, si les informations de tunnel sont erronées, si le délai de conservation a expiré ou si les paquets ont déjà été supprimés.
Questions fréquentes
BUFF a-t-il besoin de BAR pour classifier les paquets ?
Non. La PDR classe le trafic et la FAR demande BUFF. BAR fournit des instructions spécifiques de mise en tampon lorsqu'elle est configurée et associée ; ce n'est pas un autre classificateur de paquets.
L'absence de Suggested Buffering Packets Count prouve-t-elle une mauvaise configuration ?
Non. Ce champ dépend du support d'UDBC et diffère du champ de nombre de paquets descendants pour la mise en tampon prolongée. Vérifiez le contexte du message, les fonctions négociées et l'état BAR existant avant de juger cette absence.
Chaque Downlink Data Report déclenche-t-il un paging ?
Non. Le SMF et l'AMF appliquent des conditions de joignabilité, d'accès et de politique. Un rapport peut entraîner une réactivation du plan utilisateur, une mise en tampon prolongée ou un traitement d'échec ; le paging n'est qu'une composante possible de la procédure.
Pourquoi des paquets peuvent-ils être perdus même après une reconnexion réussie ?
Le tampon peut avoir atteint une limite ou expiré avant la reprise. La mise à jour de la FAR ou du tunnel peut aussi être incomplète. La seule réussite de la reconnexion ne vérifie ni les paquets conservés ni la reprise du transfert sur N3.
Références
3GPP TS 29.244 V18.7.0 : les clauses 5.2.3–5.2.4, 7.5.2.6, 7.5.4.11, 7.5.8–7.5.9 et 8.2.28–8.2.30, 8.2.100 couvrent la gestion FAR/BAR, les rapports et les éléments d'information de mise en tampon.
3GPP TS 23.502 V18.9.0 : la clause 4.2.3.3 décrit Network Triggered Service Request, la notification de données, les exceptions de joignabilité et la mise en tampon prolongée.
