Le véritable défi d’un déploiement comportant plusieurs PCF ne réside pas dans l’existence de plusieurs instances de PCF en elle-même. Le problème est qu’un même UE peut facilement être acheminé vers des PCF différents au cours de procédures de service distinctes. Lors de l’établissement d’une session PDU, le SMF peut déjà avoir créé une association de politique avec un PCF. Plus tard, lorsqu’un service vocal IMS est déclenché et que l’AF lance une nouvelle demande de politique, l’équilibrage de charge peut envoyer cette demande vers un autre PCF. Le contexte de politique entre les deux étapes est alors rompu, ce qui peut entraîner des incohérences dans les flux QoS VoNR, les règles PCC et les politiques de session.

Le BSF, ou Binding Support Function, est précisément conçu pour résoudre ce type de problème, dans lequel les demandes d’un même utilisateur passant par différentes interfaces doivent atteindre le même PCF. Il ne génère pas les règles PCC et ne remplace pas le PCF dans les décisions de politique. Sa responsabilité principale consiste à maintenir la relation de liaison entre une session UE et le PCF associé, afin que les consommateurs de service puissent retrouver le PCF ayant déjà participé au contrôle de politique de cet utilisateur lorsque de nouvelles demandes arrivent.

Pourquoi un réseau multi-PCF peut sélectionner le mauvais PCF

Pour comprendre l’intérêt du BSF, il est utile de revenir sur un problème similaire déjà présent en 4G. Dans l’architecture EPC, le PGW communique avec le PCRF via l’interface Gx, tandis que le P-CSCF du domaine IMS envoie les demandes d’autorisation de politique via l’interface Rx. Lorsque plusieurs PCRF sont déployés, les chemins de signalisation Gx et Rx doivent finalement aboutir au même PCRF. Sinon, les demandes de service IMS ultérieures ne peuvent pas hériter du contexte de politique créé plus tôt dans la session.

Dans les réseaux 4G, la solution courante consiste à utiliser un DRA pour le routage Diameter et la liaison de session. Prenons un cas typique : lorsque le PGW établit une connexion PDN pour l’APN IMS, la demande Gx est routée via DRA1 vers PCRF1. DRA1 enregistre la relation entre l’IMSI, l’adresse IP de l’UE et PCRF1. Si un message Rx ultérieur provenant du P-CSCF est envoyé à DRA2 à cause de l’équilibrage de charge et que DRA2 le transfère à PCRF2, PCRF2 ne connaît pas le contexte de session précédemment établi côté PGW.

L’impact est bien plus grave que la simple sélection d’un mauvais serveur. PCRF2 ne possède pas l’état existant des règles PCC ; les nouvelles demandes de politique média reçues sur Rx ne peuvent donc pas être correctement corrélées aux politiques précédemment établies sur Gx. Dans les déploiements 4G, ce problème peut être traité en synchronisant en temps réel les informations de liaison entre plusieurs DRA, mais ces implémentations sont souvent spécifiques aux fournisseurs, ce qui complique fortement les déploiements multifournisseurs et l’exploitation à long terme.

Dans le 5GC, l’exigence de cohérence des politiques reste identique, même si les fonctions réseau et les interfaces ont changé. Le SMF communique avec le PCF via N7, tandis que l’AF demande une autorisation de politique via N5. Dans un flux complet de politique VoNR, l’AF fournit d’abord les exigences de flux applicatif et de QoS, le PCF génère les règles PCC correspondantes, puis le SMF et l’UPF appliquent ces règles. Si différentes demandes d’un même UE atteignent des PCF différents, la continuité de politique peut encore être rompue.

Le BSF standardise ainsi une capacité de liaison qui dépendait auparavant de mécanismes de synchronisation propriétaires. Il maintient la relation entre la session UE actuelle et le PCF responsable, afin que les demandes de politique ultérieures soient renvoyées vers l’instance PCF ayant déjà participé à cette session.

Quelles informations le BSF lie-t-il ?

Du point de vue de l’implémentation, le BSF peut être considéré comme une table dynamique associant un UE à l’instance responsable de sa politique. Lorsqu’un PCF participe au contrôle de politique d’une session PDU de l’UE, il enregistre auprès du BSF les informations de liaison nécessaires. D’autres fonctions réseau peuvent ensuite interroger le BSF à l’aide des identifiants de l’UE et des caractéristiques de la session afin de récupérer les informations d’adressage du PCF correspondant.

Un enregistrement de liaison type peut contenir l’adresse IP de l’UE, le SUPI, le DNN, le S-NSSAI et l’adresse du PCF associé. Dans les déploiements devant interfonctionner avec des interfaces Diameter traditionnelles, il peut également inclure le nom d’hôte Diameter ou le FQDN du PCF.

Ces champs ne sont pas collectés uniquement pour compléter l’enregistrement. Chacun joue un rôle précis pour filtrer et identifier la bonne liaison :

• UE IP: Permet de localiser directement la liaison à partir de l’adresse actuelle du plan utilisateur et constitue l’un des paramètres de requête les plus courants.

• SUPI: Identifie l’abonné au niveau de l’identité utilisateur et aide à garantir que la liaison correspond au bon UE.

• DNN: Distingue les différents réseaux de données utilisés par un même UE, par exemple IMS et les services Internet ordinaires.

• S-NSSAI: Identifie plus précisément la tranche réseau associée à la session dans un déploiement 5G avec slicing.

• Adresse PCF: Fournit les informations d’adressage effectives nécessaires à un consommateur de service pour joindre le PCF sélectionné.

• Nom d’hôte Diameter/FQDN: Fournit une référence de correspondance pour le routage Diameter traditionnel dans les déploiements où SBI et Diameter coexistent.

Pour cette raison, la liaison BSF ne doit pas être réduite à une simple correspondance un-à-un entre une adresse UE et une adresse PCF. Un même UE peut avoir plusieurs sessions PDU et accéder à différents DNN ou tranches réseau. Si les critères de requête sont trop larges, le PCF renvoyé peut ne pas correspondre au contexte de service courant.

En déploiement, la granularité de la liaison doit correspondre à celle du contrôle de politique. C’est particulièrement important pour les services IMS, où la continuité de politique est essentielle. Si l’UE possède plusieurs tranches ou plusieurs contextes de réseau de données, le DNN et le S-NSSAI ne doivent pas être omis des critères de liaison.

Comment utiliser Nbsf_Management ?

Le BSF expose le service Nbsf_Management via SBI. Ce service n’est pas construit autour d’une grande collection d’API sans lien entre elles. Il fournit quatre opérations principales couvrant tout le cycle de vie d’un enregistrement de liaison : enregistrement, découverte, mise à jour et désenregistrement. En pratique, ces quatre opérations correspondent directement à la création, l’utilisation, la maintenance et la suppression d’une liaison PCF.

Enregistrement : créer d’abord la liaison

Une fois qu’un PCF a été sélectionné et qu’il intervient dans le contrôle de politique de l’UE, il doit enregistrer la liaison auprès du BSF. Une requête type est :

POST .../pcfBindings

Le corps de la requête peut contenir des champs clés tels que l’adresse IP de l’UE, le SUPI, le DNN, le S-NSSAI, l’adresse du PCF et le FQDN correspondant. Lorsque le BSF crée correctement l’enregistrement de liaison, il renvoie :

201 Created

Le moment de l’enregistrement constitue l’un des pièges d’implémentation les plus courants à cette étape. La liaison doit être enregistrée avant toute requête ultérieure côté service. Sinon, lorsqu’une demande côté AF ou une demande compatible Diameter atteint le réseau, le BSF peut ne pas encore disposer de la liaison PCF correspondante, entraînant l’échec de la recherche.

Découverte : retrouver le PCF existant à partir du contexte de session

L’opération Discovery met le mieux en évidence la valeur pratique du BSF. Un consommateur de service envoie une requête à l’aide des informations UE actuellement disponibles :

GET .../pcfBindings?query_parameters

Les paramètres de requête peuvent inclure l’adresse IP de l’UE, le SUPI ou GPSI, le DNN, le S-NSSAI et d’autres identifiants pertinents. Si une liaison correspondante est trouvée, le BSF renvoie :

200 OK

La réponse contient l’adresse du PCF correspondant et, si nécessaire, le nom d’hôte Diameter ou le FQDN. Dans l’architecture standardisée, les consommateurs de service peuvent inclure des fonctions telles que le NEF, l’AF et le NWDAF. Dans les déploiements qui doivent encore prendre en charge le routage Rx traditionnel, les informations de liaison renvoyées peuvent également servir à sélectionner le bon PCF pour la signalisation suivante.

Mise à jour et désenregistrement : maintenir le cycle de vie de la liaison

Si les informations de liaison changent, un enregistrement existant peut être mis à jour à l’aide de PATCH :

PATCH .../pcfBindings/{bindingId}

Une mise à jour réussie renvoie 200 OK. Lorsque la session est libérée, que le PCF ne dessert plus l’UE ou que la liaison devient invalide, l’enregistrement doit être supprimé à l’aide de :

DELETE .../pcfBindings/{bindingId}

Une suppression réussie renvoie normalement 204 No Content. Dans les déploiements réels, l’étape de désenregistrement ne doit pas être négligée. Si des enregistrements de liaison obsolètes restent trop longtemps dans le BSF, le même abonné peut ensuite établir une nouvelle session et correspondre par erreur à un ancien PCF. Ce type de problème est souvent plus difficile à diagnostiquer qu’une liaison simplement absente.

Comment diagnostiquer les liaisons N7 et Rx

Sur l’ensemble du chemin de signalisation, le flux BSF peut être divisé en trois étapes : enregistrer d’abord la liaison, l’interroger ensuite, puis renvoyer la signalisation de politique ultérieure vers le PCF d’origine. Une fois cette séquence comprise, le diagnostic des problèmes de politique VoNR devient beaucoup plus efficace que la collecte massive de signalisation sans orientation précise.

Étape 1 : établir la session PDU et enregistrer le PCF

Après sa mise en service, une instance BSF enregistre d’abord ses capacités et ses informations d’adressage auprès du NRF. Le UE établit ensuite une session PDU pour le DNN IMS, et le SMF demande un contrôle de politique à un PCF. Une fois le PCF sélectionné, celui-ci invoque Nbsf_Management_Register afin de stocker dans le BSF la liaison entre l’UE et le PCF.

À ce stade, le BSF peut contenir des enregistrements de liaison semblables à :

UE IP1 + DNN1 + S-NSSAI1 + SUPIxx → PCF1
UE IP2 + DNN2 + S-NSSAI2 + SUPIyy → PCF2

Étape 2 : un appel VoNR déclenche la recherche du PCF associé à la politique

Lorsque l’UE initie un appel VoNR, le domaine IMS déclenche une nouvelle demande d’autorisation de politique. Dans l’architecture 5GC standardisée, l’AF et le PCF échangent les informations de politique via l’interface N5. Dans certains déploiements continuant d’utiliser la signalisation Diameter IMS traditionnelle, le P-CSCF peut encore utiliser la procédure Rx/AAR.

La question essentielle à ce stade est simple : quel PCF doit recevoir la demande de politique ?

Le demandeur ne doit pas simplement sélectionner un autre PCF selon la logique habituelle d’équilibrage de charge. Il interroge d’abord le BSF à l’aide d’informations telles que l’adresse de l’UE, le DNN et le S-NSSAI. Le BSF fait correspondre l’enregistrement de liaison existant et renvoie l’instance PCF déjà responsable de la session de l’UE.

Étape 3 : renvoyer la signalisation ultérieure vers le PCF d’origine

Une fois le bon PCF identifié, les demandes de politique suivantes sont dirigées vers ce même PCF. Le contexte de politique créé lors de l’établissement de la session PDU et les nouvelles demandes générées pendant l’étape média VoNR restent ainsi sur la même instance de contrôle de politique. Le PCF peut alors générer et maintenir les règles PCC à partir du contexte complet de session.

Si un appel VoNR peut être lancé mais que le comportement de politique QoS est anormal, que les règles média IMS sont incohérentes ou que seuls certains abonnés subissent des échecs intermittents, il faut vérifier le chemin de liaison BSF avant d’attribuer immédiatement le problème au réseau radio.

Une séquence de diagnostic pratique peut être divisée en quatre étapes. Premièrement, confirmer que l’opération BSF Register a bien été effectuée après l’établissement de la session PDU. Deuxièmement, vérifier que l’adresse IP de l’UE, le SUPI, le DNN et le S-NSSAI stockés dans le BSF sont corrects. Troisièmement, vérifier que les critères utilisés dans la requête Discovery ultérieure permettent d’identifier de façon unique la liaison d’origine. Quatrièmement, confirmer que l’adresse PCF ou l’identifiant Diameter renvoyé correspond exactement au PCF ayant initialement participé au contrôle de politique N7.

L’architecture de déploiement doit également être prise en compte. Dans certains réseaux, le BSF peut être colocalisé avec le SMF. Dans ce cas, les points de capture de paquets et les flux d’appels internes peuvent différer de ceux d’un BSF autonome. Le principe fondamental reste toutefois le même : le réseau doit maintenir une liaison stable entre la session UE et le PCF responsable.

Questions fréquentes

Le BSF et le NRF réalisent-ils tous deux la sélection des fonctions réseau ?

Non. Leurs rôles sont différents. Le NRF aide les fonctions réseau à découvrir les instances NF disponibles et leurs capacités, jouant plutôt le rôle d’un registre de services. Le BSF stocke une liaison déjà établie entre une session UE précise et un PCF. En termes simples, le NRF répond à la question « Quels PCF sont disponibles ? », tandis que le BSF répond à « Quel PCF est déjà responsable de cette session UE ? »

Un UE ne peut-il avoir qu’une seule liaison PCF ?

Pas nécessairement. Une liaison n’est pas définie uniquement par l’identité de l’UE. Elle peut aussi dépendre du DNN, du S-NSSAI et du contexte précis de la session PDU. Si le même UE accède à différents réseaux de données ou différentes tranches réseau, les liaisons correspondantes peuvent devoir être maintenues séparément.

Le BSF et le SMF peuvent-ils être déployés dans la même instance de fonction réseau ?

Oui. Un déploiement colocalisé est possible. Dans ce cas, la séquence de signalisation visible de l’extérieur peut différer de celle d’un BSF autonome, mais la liaison UE-PCF doit toujours être stockée et utilisée. Lors du diagnostic, il convient donc de confirmer en premier lieu l’architecture de déploiement réelle du fournisseur.

Que faut-il vérifier en premier lorsqu’une requête BSF échoue ?

Commencez par trois points : vérifier que l’enregistrement de liaison a bien été créé, que les paramètres de requête correspondent aux valeurs utilisées lors de l’enregistrement et que la liaison n’a pas expiré ou été supprimée prématurément. Si le BSF renvoie un enregistrement, vérifiez également que l’adresse PCF, le FQDN ou l’identifiant Diameter renvoyé pointe vers l’instance PCF attendue.