Questions-réponses techniques : comment la BAR sur l'interface N4 contrôle-t-elle la mise en mémoire tampon des paquets descendants et la notification de données lorsqu'un UE est en mode CM-IDLE ?
Lorsqu'un UE passe en mode CM-IDLE, sa session PDU ne disparaît pas. Cependant, le chemin de plan utilisateur N3 précédemment utilisé pour le transfert descendant peut ne plus être actif. Si de nouvelles données arrivent d'un réseau externe à ce moment-là, les paquets peuvent encore atteindre l'UPF, mais ils ne peuvent pas être transférés immédiatement vers le gNB via N3 comme ils le seraient en mode CM-CONNECTED. L'UPF doit donc déterminer si les paquets doivent être mis en mémoire tampon, combien de paquets peuvent être conservés, pendant combien de temps ils peuvent rester en mémoire tampon et quand le plan de contrôle doit être informé de l'arrivée de données descendantes.
Dans le cadre des règles PFCP sur l'interface N4, la BAR (Buffering Action Rule) fournit les règles de ce comportement de mise en mémoire tampon. Cependant, la BAR ne décide pas de manière indépendante si la mise en mémoire tampon doit avoir lieu. L'action de mise en mémoire tampon est déclenchée par l'Apply Action de la FAR, tandis que la BAR définit la manière dont cette mise en mémoire tampon doit être effectuée. Cette distinction est fondamentale pour comprendre la relation entre la FAR et la BAR.
La BAR définit comment l'UPF met les paquets en mémoire tampon
Lorsque l'UPF reçoit un paquet, il utilise d'abord une PDR pour identifier le trafic, puis suit la FAR référencée par cette PDR pour déterminer l'action suivante. Si la FAR exige un transfert normal, l'UPF transfère le paquet conformément aux paramètres de transfert. Si l'Apply Action de la FAR contient BUFF, le paquet n'est pas envoyé immédiatement vers l'interface de destination et entre plutôt dans le processus de mise en mémoire tampon.
C'est là que la BAR devient pertinente. La FAR peut référencer une BAR qui indique à l'UPF comment les paquets concernés doivent être mis en mémoire tampon. La relation peut se résumer ainsi :
La PDR identifie le paquet → la FAR sélectionne BUFF/NOCP → la BAR définit le comportement de mise en mémoire tampon.
Une confusion courante consiste à traiter BUFF et BAR comme s'il s'agissait de la même chose. Ce n'est pas le cas. BUFF répond à la question : « Ce paquet doit-il être mis en mémoire tampon maintenant ? » La BAR répond à la question : « Une fois la mise en mémoire tampon sélectionnée, dans quelles conditions le paquet doit-il être mis en mémoire tampon ? » Ne regarder que BUFF dans la FAR sans vérifier la BAR associée ou la configuration de mise en mémoire tampon locale de l'UPF ne donne qu'une image partielle du comportement du plan utilisateur.
NOCP est également couramment associé à ce scénario. Lorsque l'UPF met en mémoire tampon des paquets descendants, NOCP peut exiger que l'UPF informe le plan de contrôle de l'arrivée de données descendantes afin que le SMF puisse lancer les procédures de plan de contrôle suivantes. La mise en mémoire tampon et la notification se produisent donc comme deux tâches coordonnées : le plan utilisateur retient temporairement les paquets pendant que l'événement est signalé au plan de contrôle.
Le scénario le plus typique de la BAR se produit après le passage de l'UE en mode CM-IDLE
Le rôle de la BAR est plus facile à comprendre lorsqu'un UE passe de CM-CONNECTED à CM-IDLE. Supposons que l'UE a déjà terminé l'enregistrement et l'établissement de la session PDU. Lorsqu'il est connecté, le chemin de plan utilisateur N3 est disponible et l'UPF peut transférer les paquets descendants directement vers le gNB.
Après une période d'inactivité, le côté accès peut libérer la connexion et l'UE passe en mode CM-IDLE. La session PDU reste en place, mais le chemin de transfert de plan utilisateur N3 précédemment actif n'est plus immédiatement disponible. Les serveurs externes ne sont pas nécessairement conscients de ce changement d'état, de sorte que de nouveaux paquets IP descendants peuvent encore arriver à l'UPF via N6.
Cela crée le problème clé : l'UPF a reçu les données, mais il ne dispose actuellement d'aucun chemin N3 utilisable pour les remettre à l'UE.
À ce stade, le SMF met à jour les règles du plan utilisateur via N4 afin que la FAR concernée passe du transfert immédiat au comportement de mise en mémoire tampon. Dans un cas typique, BUFF et NOCP sont activés dans l'Apply Action, tandis que FORW n'est plus utilisé comme action descendante actuelle. Lorsque de nouveaux paquets descendants arrivent, l'UPF les retient conformément à la politique de mise en mémoire tampon applicable et signale l'arrivée des données descendantes au SMF.
Après avoir reçu la notification, le SMF peut se coordonner avec l'AMF pour lancer les procédures nécessaires afin que l'UE redevienne joignable, y compris la radiomessagerie le cas échéant. Une fois que l'UE revient à un état dans lequel le trafic de plan utilisateur peut être transporté et que le chemin N3 est rétabli, le SMF met à nouveau à jour les règles de l'UPF afin que le traitement descendant passe de la mise en mémoire tampon au transfert. Les paquets mis en mémoire tampon peuvent alors continuer vers l'UE.
La BAR n'est donc pas simplement une règle statique d'allocation de mémoire. Son véritable objectif est d'aider le plan utilisateur à franchir la période temporaire pendant laquelle les paquets descendants sont déjà arrivés, mais où le transfert immédiat n'est pas encore possible.
Les paramètres clés de la BAR définissent les limites de la mise en mémoire tampon
La mise en mémoire tampon ne peut pas continuer indéfiniment. Si l'UPF était autorisé à conserver des données descendantes illimitées pour un UE injoignable, la mémoire du plan utilisateur pourrait être consommée inutilement. La BAR fournit donc des limites au comportement de mise en mémoire tampon. Selon la procédure PFCP et les capacités de l'UPF, celles-ci peuvent inclure l'ID de la BAR, des limites de nombre de paquets, la durée de mise en mémoire tampon et des paramètres de délai de notification.
ID de la BAR
L'ID de la BAR identifie de manière unique la règle de mise en mémoire tampon au sein de la session PFCP et permet à la FAR correspondante de référencer la bonne BAR. Lors du dépannage, le fait de voir une création de BAR seule ne prouve pas que la règle affecte le trafic analysé. La FAR correspondante doit également être vérifiée pour confirmer quel ID de BAR elle référence réellement.
Nombre de paquets suggéré pour la mise en mémoire tampon
Le nombre de paquets suggéré pour la mise en mémoire tampon indique le nombre de paquets qu'il est conseillé à l'UPF de mettre en mémoire tampon pour le trafic concerné. Une fois la limite suggérée dépassée, les paquets supplémentaires peuvent être rejetés. Ce paramètre contrôle la limite de capacité de mise en mémoire tampon plutôt que la durée de mise en mémoire tampon.
Sa présence dépend également du support des fonctionnalités de l'UPF. Si le champ n'est pas visible dans une trace PFCP, cela ne prouve pas à lui seul que le contrôle de mise en mémoire tampon est absent. L'analyse doit également prendre en compte si l'UPF prend en charge la capacité concernée et si des paramètres de mise en mémoire tampon locaux sont utilisés à la place.
Durée de mise en mémoire tampon des données descendantes
La durée de mise en mémoire tampon des données descendantes définit la période pendant laquelle les paquets descendants peuvent continuer à être mis en mémoire tampon dans l'UPF selon la procédure applicable. Elle reflète un principe de conception important : la mise en mémoire tampon est conçue comme un mécanisme temporaire pendant le rétablissement de la livraison du plan utilisateur, et non comme un stockage permanent des paquets.
Si l'UE reste injoignable pendant une période prolongée, le processus de mise en mémoire tampon a besoin d'une condition de fin définie ; sinon, les ressources du plan utilisateur pourraient rester occupées indéfiniment.
Délai de notification de données descendantes
Dans les procédures et combinaisons de capacités prises en charge, le délai de notification de données descendantes peut contrôler combien de temps l'UPF attend après avoir reçu le premier paquet descendant avant d'informer le plan de contrôle. Ce paramètre affecte le moment où la notification est envoyée, et non si le paquet doit être mis en mémoire tampon.
Son comportement doit donc être interprété dans le contexte de la procédure PFCP spécifique, de l'implémentation réseau et des capacités de l'UPF, plutôt que déduit du seul nom du paramètre.
Pourquoi des paramètres complets de la BAR sont-ils parfois absents des traces PFCP ?
C'est l'un des points les plus faciles à mal interpréter lors de l'analyse de la BAR. Le nombre de paquets à mettre en mémoire tampon, la durée de mise en mémoire tampon et d'autres paramètres de mise en mémoire tampon ne doivent pas toujours être provisionnés dynamiquement via N4. Les opérateurs ou les fournisseurs d'équipements peuvent également configurer des politiques de mise en mémoire tampon localement dans l'UPF.
Avec cette implémentation, le SMF peut n'avoir besoin que de modifier dynamiquement l'action de la FAR. Par exemple, après que l'UE est passé en mode CM-IDLE, le SMF peut utiliser la modification de session PFCP pour mettre à jour la FAR concernée vers BUFF/NOCP. Une fois que l'UPF voit l'action de mise en mémoire tampon, il peut appliquer les limites de nombre de paquets et de durée configurées localement.
L'observation suivante dans une trace n'est donc pas automatiquement anormale :
La FAR demande BUFF, mais les messages PFCP ne contiennent pas les paramètres complets de la BAR attendus par l'ingénieur.
Au moins deux questions supplémentaires doivent être vérifiées : si l'UPF utilise des valeurs de mise en mémoire tampon configurées localement et si l'UPF prend en charge le provisionnement dynamique des paramètres de la BAR concernés. Sinon, une différence d'implémentation peut être confondue avec une règle manquante du SMF.
La configuration locale peut également présenter des avantages pratiques. Elle peut réduire une partie de la signalisation N4 et s'adapter aux différences de capacités entre les implémentations d'UPF. Le compromis est qu'une partie du comportement de mise en mémoire tampon n'est plus entièrement visible dans une seule trace PFCP, de sorte que le dépannage multi-fournisseurs peut nécessiter à la fois l'analyse de la signalisation et l'inspection de la configuration locale de l'UPF.
Comment le flux PFCP doit-il être compris lorsque des données descendantes arrivent en mode CM-IDLE ?
La BAR est plus facile à comprendre lorsqu'elle est replacée dans la procédure complète plutôt qu'analysée comme un élément d'information isolé.
Lorsque l'UE est en mode CM-CONNECTED, le chemin N3 est disponible et l'UPF transfère les paquets descendants conformément à la FAR normale. Après une période d'inactivité, la connexion côté accès est libérée. Une fois que le SMF apprend que l'état de la connexion du plan utilisateur a changé, il utilise la modification de session PFCP pour mettre à jour les règles de l'UPF concernées.
Le point important est que la session PDU n'a pas été supprimée. Au lieu de cela, le chemin actuel du plan utilisateur descendant est temporairement indisponible pour une livraison immédiate. La FAR concernée peut donc passer au comportement de mise en mémoire tampon en activant BUFF et l'action de notification du plan de contrôle requise, tandis que la BAR ou la configuration locale de l'UPF fournit les conditions détaillées de mise en mémoire tampon.
Lorsqu'un serveur Internet ou une application envoie ultérieurement de nouvelles données descendantes, les paquets arrivent d'abord à l'UPF. L'UPF utilise la PDR pour identifier le trafic, puis applique la FAR associée. Étant donné que l'action actuelle n'est plus FORW, les paquets sont mis en mémoire tampon. En même temps, l'UPF signale l'arrivée des données descendantes au SMF via le mécanisme de rapport PFCP.
Le SMF se coordonne ensuite avec les procédures côté AMF afin que l'UE puisse redevenir joignable et que le chemin du plan utilisateur puisse être rétabli. Une fois que le transfert N3 redevient disponible, la FAR sur N4 est à nouveau mise à jour pour un transfert normal et l'UPF peut continuer à livrer le trafic descendant à l'UE.
La logique globale peut se résumer ainsi :
L'UE passe en CM-IDLE → N3 est temporairement indisponible → le SMF met à jour FAR/BAR → les données descendantes atteignent l'UPF → l'UPF met en mémoire tampon et signale → le plan de contrôle rétablit la joignabilité de l'UE → N3 est rétabli → la FAR revient au transfert.
La BAR contrôle donc le comportement du plan utilisateur pendant la période où les données sont déjà arrivées, mais où le chemin de livraison n'est pas encore revenu.
Le dépannage de la BAR doit suivre quatre étapes : action, mise en mémoire tampon, notification et récupération
Les problèmes liés à la BAR apparaissent rarement comme une « erreur BAR » explicite. Le plus souvent, le symptôme est que le premier trafic descendant après que l'UE est entré dans un état inactif se comporte de manière anormale. Une application peut fonctionner normalement lorsqu'elle est active, mais après une période d'inactivité, le message suivant arrive avec un retard notable. Dans un autre cas, l'UE peut être correctement radiomessagé et reconnecté, mais les premiers paquets descendants ont déjà été perdus.
Ces problèmes peuvent être analysés en quatre étapes.
Étape 1 : confirmer que la FAR est réellement passée en mode de mise en mémoire tampon
Commencez par la FAR référencée par la PDR descendante concernée et confirmez que la modification de session PFCP attendue s'est produite après le passage de l'UE en mode CM-IDLE. Vérifiez si l'Apply Action est passée du comportement FORW normal aux actions BUFF et de notification attendues pour le scénario.
Si la FAR tente toujours de transférer des paquets vers un chemin de plan utilisateur qui n'est plus utilisable, le problème n'est pas principalement un problème de BAR.
Étape 2 : déterminer quelles règles de mise en mémoire tampon l'UPF applique
Vérifiez l'ID de la BAR référencé par la FAR, puis examinez les paramètres de création ou de mise à jour de la BAR correspondants. Si la trace PFCP ne contient pas les paramètres de mise en mémoire tampon complets, poursuivez en vérifiant la configuration de mise en mémoire tampon locale de l'UPF et les capacités prises en charge.
Si la limite de nombre de paquets est trop petite, certains des premiers paquets descendants peuvent être rejetés avant que l'UE ne redevienne joignable. Si le comportement de mise en mémoire tampon observé diffère sensiblement des attentes, l'association de la BAR elle-même doit également être vérifiée.
Étape 3 : confirmer que l'UPF a signalé l'arrivée des données descendantes
La mise en mémoire tampon des paquets à elle seule ne rétablit pas la communication avec l'UE. Si le plan de contrôle n'est pas conscient de l'arrivée de nouvelles données descendantes, la procédure de radiomessagerie ou de récupération du plan utilisateur suivante ne sera pas lancée. La trace doit donc être vérifiée pour le rapport de session PFCP approprié et pour le traitement correct par le SMF.
Si les paquets sont déjà mis en mémoire tampon dans l'UPF mais qu'aucune procédure de plan de contrôle ne suit, le dépannage doit passer des paramètres de la BAR au chemin de rapport UPF-SMF et aux procédures SMF ultérieures.
Étape 4 : confirmer que le transfert reprend après la récupération du plan utilisateur
Une fois que l'UE redevient joignable, vérifiez que le SMF met à jour correctement les règles N4 afin que la FAR descendante passe de la mise en mémoire tampon au transfert normal et que les paramètres de transfert N3 requis soient rétablis.
Si la radiomessagerie réussit et que l'UE est revenu, mais que la FAR reste en mode BUFF, le système peut entrer dans un état où l'UE est joignable alors que les paquets continuent de rester dans l'UPF. Le dépannage de la BAR doit donc se poursuivre jusqu'à ce que le chemin de transfert du plan utilisateur soit entièrement rétabli.
La valeur essentielle de la BAR
Dans le cadre des règles PFCP, la BAR ne participe pas à chaque paquet transféré normalement de la même manière que la PDR et la FAR. Son importance devient plus visible dans une situation spécifique mais critique : la session existe toujours, mais le chemin actuel du plan utilisateur ne peut pas livrer immédiatement les données descendantes nouvellement arrivées.
La FAR fait passer l'action de traitement des paquets de FORW à BUFF, la BAR définit les limites de mise en mémoire tampon, l'UPF retient temporairement les paquets et signale leur arrivée, et les fonctions du plan de contrôle telles que le SMF et l'AMF coordonnent le rétablissement de la joignabilité de l'UE. Ensemble, ces mécanismes comblent la transition entre l'indisponibilité temporaire de la livraison et le retour à un chemin de plan utilisateur actif.
La BAR ne doit donc pas être comprise uniquement comme « Buffering Action Rule = une règle de mise en mémoire tampon des paquets ». Une interprétation plus utile est : la BAR indique à l'UPF comment gérer les paquets descendants qui sont déjà arrivés alors que le chemin de livraison du plan utilisateur est temporairement indisponible. Une fois que la BAR est considérée avec CM-IDLE, FAR BUFF/NOCP, le rapport de session PFCP et les procédures ultérieures de radiomessagerie et de récupération du plan utilisateur, son rôle sur l'interface N4 devient beaucoup plus clair.
FAQ
Quelle est la différence entre BAR et BUFF dans la FAR ?
BUFF est une Apply Action dans la FAR indiquant que les paquets correspondants doivent être mis en mémoire tampon au lieu d'être transférés immédiatement. La BAR définit comment cette mise en mémoire tampon doit être effectuée, comme les limites de nombre de paquets, la durée de mise en mémoire tampon ou d'autres conditions applicables. En termes simples, la FAR décide que la mise en mémoire tampon est requise, tandis que la BAR définit comment la mise en mémoire tampon est effectuée.
La BAR peut-elle fonctionner indépendamment d'une FAR ?
La BAR ne doit pas être traitée comme une règle de correspondance de paquets indépendante. Le paquet est d'abord mis en correspondance par une PDR, qui référence la FAR concernée. Lorsque cette FAR exige la mise en mémoire tampon et référence la BAR applicable, les paramètres de la BAR sont alors utilisés pour contrôler la manière dont ces paquets sont mis en mémoire tampon.
Pourquoi les paquets descendants ne sont-ils pas simplement rejetés lorsque l'UE passe en mode CM-IDLE ?
Le mode CM-IDLE ne signifie pas que la session PDU a été supprimée. Des applications externes peuvent continuer à envoyer des données alors que le chemin de livraison du plan utilisateur n'est que temporairement indisponible. La mise en mémoire tampon à court terme permet de conserver une partie de ce trafic descendant pendant que le plan de contrôle rétablit la joignabilité de l'UE, contribuant ainsi à réduire l'interruption de la continuité des applications.
L'absence du nombre de paquets suggéré pour la mise en mémoire tampon signifie-t-elle que la BAR est mal configurée ?
Pas nécessairement. L'apparition de ce paramètre dépend de la procédure PFCP, des capacités de l'UPF et de l'implémentation. Les limites de nombre de paquets et d'autres comportements de mise en mémoire tampon peuvent également être configurés localement dans l'UPF ; il convient donc de vérifier le support des capacités, l'association de la BAR et la configuration de mise en mémoire tampon côté équipement.
Pourquoi l'UE ne reçoit-il toujours pas de données même si l'UPF a mis en mémoire tampon les paquets descendants ?
La mise en mémoire tampon n'est qu'une partie de la procédure. L'UPF doit également signaler l'arrivée des données descendantes au SMF, le plan de contrôle doit lancer les procédures nécessaires pour rétablir la joignabilité de l'UE, et le SMF doit mettre à jour la FAR et les paramètres de transfert N3 une fois que le chemin du plan utilisateur est à nouveau disponible. Une défaillance à l'une de ces étapes peut laisser les paquets en mémoire tampon ou finir par les faire rejeter.
