Dans l’architecture 3GPP, la Policy and Charging Rules Function (PCRF) prend la décision de contrôle de politique. La Policy and Charging Enforcement Function (PCEF) l’applique. La PCRF gère les règles sur la PCEF via l’interface Gx ; la PCEF remonte la consommation à la facturation via Gy et Gz. Dans notre PCEF, l’inspection approfondie des paquets (DPI) identifie les applications présentes dans le trafic.
Que décide la PCRF et qu’applique la PCEF ?
Selon la norme 3GPP TS 23.203, la PCRF prend la décision de contrôle de politique : elle détermine comment le trafic de certains services est traité dans la PCEF. La PCEF, située au niveau de la passerelle, applique cette décision en contrôlant si un flux passe et quelle qualité de service (QoS) il reçoit.
La norme attribue à la PCRF la décision de contrôle de politique et le contrôle de la facturation par flux. Elle fournit à la PCEF le contrôle réseau sur la détection des flux de données de service, le gating, la QoS et la facturation par flux, à l’exception de la gestion du crédit. La PCRF définit le traitement du trafic du plan utilisateur dans la PCEF afin qu’il corresponde au profil d’abonnement de l’utilisateur.
Dans l’architecture 3GPP, la PCEF assure la détection des flux de données de service, l’application des politiques et la facturation par flux. Elle applique les politiques de deux façons. Le gate enforcement ne laisse passer un flux que si sa porte est ouverte, et le QoS enforcement applique au flux la QoS autorisée. La PCEF mesure également les flux de données de service et gère les interactions de facturation en ligne et hors ligne.
La PCRF décide, et la PCEF applique la décision au trafic. Notre PCEF applique les politiques de QoS et la facturation flexible selon les exigences de la PCRF.
Comment la PCEF et la PCRF communiquent : Gx, Gy et le déroulement de la session
La PCEF et la PCRF communiquent via l’interface Gx, une interface Diameter. Lorsque la session de données d’un abonné est établie, la PCEF envoie à la PCRF un CC-Request (CCR). La PCRF répond par un CC-Answer (CCA) qui fournit les règles de contrôle de politique et de facturation (PCC) pour cette session. La PCEF remonte la consommation à la facturation via Gy et Gz.
Diameter transporte les messages d’authentification, d’autorisation et de comptabilité (AAA) sur TCP ou sur Stream Control Transmission Protocol (SCTP). Consultez l’entrée protocole Diameter de notre glossaire.
Dans l’architecture 3GPP, une règle PCC permet de détecter un flux de données de service et contient des paramètres de contrôle de politique et/ou de contrôle de facturation.
| Interface | Ce qu’elle relie | Ce qu’elle transporte |
|---|---|---|
| Gx | PCEF et PCRF | Règles PCC dynamiques et références à des règles prédéfinies, de la PCRF vers la PCEF ; requêtes et rapports d’événements, de la PCEF vers la PCRF |
| Gy | PCEF et système de facturation en ligne (OCS) | Contrôle de crédit en ligne pour la facturation par flux, via Diameter |
| Gz | PCEF et système de facturation hors ligne (OFCS) | Informations de facturation hors ligne pour la facturation par flux |
| Sy | PCRF et OCS | Informations sur l’état des compteurs de politique liés aux dépenses de l’abonné, de l’OCS vers la PCRF |
Notre article DPI System Components décrit un exemple de session de données ; nous le résumons en six étapes.
| Déroulement d’une session type | Ce qui se passe | Interface |
|---|---|---|
| 1. Début de session | La PCEF envoie à la PCRF un CC-Request contenant des informations sur l’abonné et le service | Gx |
| 2. Profil | La PCRF demande le profil de l’abonné au référentiel de données utilisateur (UDR) via Ud ; la norme définit aussi pour cela le référentiel de profils d’abonnement (SPR) via Sp | Sp ou Ud |
| 3. Décision | La PCRF décide s’il faut fournir le service et avec quels paramètres de qualité, puis construit les règles PCC | Au sein de la PCRF |
| 4. Réponse | La PCRF renvoie les règles à la PCEF dans un CC-Answer | Gx |
| 5. Contrôle de crédit | La PCEF ouvre une session de contrôle de crédit avec l’OCS, la session est autorisée et le trafic commence à circuler | Gy |
| 6. Fin de session | La PCEF ferme les sessions Diameter avec la PCRF et avec l’OCS | Gx, Gy |
Session de l’abonné -> PCEF (notre moteur DPI)
PCEF –Gx : CC-Request–> PCRF
PCRF –Sp ou Ud–> référentiel de profils d’abonnement (SPR) ou référentiel de données utilisateur (UDR)
PCRF –Gx : CC-Answer avec règles PCC–> PCEF
PCEF –Gy–> OCS (facturation en ligne)
PCEF –Gz–> OFCS (facturation hors ligne)
PCRF <–Sy– OCS Les liaisons Gx, Ud et Gy suivent la session type ; Sp, Gz et Sy proviennent de la norme. La mention DPI concerne uniquement notre PCEF. Dans l’exemple ci-dessus, une fois la session autorisée et le trafic en circulation, la PCEF lui applique les règles reçues. Le DPI de notre PCEF identifie les applications présentes dans ce trafic. La PCEF limite, bloque ou autorise le flux et en compte le volume pour la facturation via Gy et Gz. Dans l’architecture 3GPP, la PCRF peut aussi envoyer de nouvelles règles sans requête de la PCEF, dans un Re-Auth-Request (RAR). La PCEF répond par un Re-Auth-Answer (RAA). La PCEF signale à la PCRF les événements auxquels celle-ci s’est abonnée, et certains événements sont toujours signalés. Elle remonte aussi la consommation cumulée lorsqu’un seuil fixé par la PCRF est atteint. Notre PCEF se connecte au réseau de l’opérateur sur Gi/SGi et fonctionne avec la PCRF, l’OCS et l’OFCS via les interfaces standard Gx, Gy et Gz.
La place du DPI et pourquoi la PCEF en a besoin
Notre PCEF repose sur notre propre moteur DPI, qui analyse le trafic qui le traverse et identifie les applications qu’il contient. Il classe le trafic par application et par protocole, et pas seulement par port et adresse IP, ce qu’exige la tarification par type de service. La PCEF applique ensuite les politiques tarifaires qu’elle reçoit de la PCRF.
La classification vient en premier : elle identifie les applications et les protocoles présents dans le trafic. La gestion, l’optimisation et la priorisation du trafic suivent.
Le DPI identifie une application principalement par analyse de signatures. Chaque application présente des caractéristiques stockées dans une base de signatures, qui doit être mise à jour à mesure que de nouvelles applications apparaissent. Notre article sur la manière dont la PCEF et le DPI fonctionnent avec le ML et l’IA explique comment une PCEF utilise le DPI.
Le trafic chiffré est plus difficile à classer : le DPI ne peut pas lire la charge utile chiffrée, il s’appuie donc sur les métadonnées non chiffrées et sur l’analyse comportementale et heuristique. Aucune méthode ne classe à elle seule tout le trafic, c’est pourquoi on les combine. Ces méthodes sont décrites dans notre article Traffic Classification and Deep Packet Inspection.
Selon la norme 3GPP TS 23.203, la détection des applications s’effectue dans la Traffic Detection Function (TDF) ou dans une PCEF dotée de la détection et du contrôle des applications (ADC). La norme ne définit pas comment les applications sont détectées ; cela relève de l’implémentation de chaque fournisseur.
Comment une règle tarifaire devient une action sur le trafic en temps réel
La PCEF applique en temps réel au trafic de l’abonné les politiques de facturation et de QoS qu’elle reçoit de la PCRF via Gx : elle limite le débit, bloque ou autorise le trafic et compte le volume de données par service. Elle transmet ce volume à la facturation via Gy et Gz. Sans application dans une PCEF, les règles définies dans la PCRF restent lettre morte.
Notre PCEF prend en charge la tarification au niveau de l’application, de la catégorie de trafic et du profil d’abonné. La logique des règles pour les rating groups est définie via la PCRF ; la PCEF l’applique au trafic.
Dans le cadre d’une politique d’usage raisonnable (fair usage policy), notre PCEF enregistre la consommation du forfait grâce à l’intégration Gy avec l’OCS. Ce qui se passe lorsque le quota est épuisé dépend de la présence ou non d’une liaison Sy entre l’OCS et la PCRF. Avec Sy, l’OCS signale à la PCRF l’état des compteurs de politique. La PCRF modifie alors les services ou leurs paramètres pour la session de l’abonné selon sa propre logique, par exemple en réduisant le débit.
Sans Sy, l’OCS envoie à la PCEF une final unit indication (FUI) via Gy, et la PCEF bloque le service. Selon la configuration, notre PCEF procède de l’une des deux façons suivantes. Soit elle cesse de transmettre les paquets du service, soit elle active un charging rule base name (CRBN), un groupe de règles qui met en œuvre le blocage. La seconde méthode est couramment utilisée pour un portail captif : l’abonné est redirigé et l’accès est limité aux ressources nécessaires pour atteindre le portail de l’opérateur et recharger son crédit.
Pour le zero-rating, notre PCEF reconnaît une messagerie ou une plateforme vidéo par classification DPI, et non par une liste d’adresses IP. Elle tarifie ce trafic séparément, le comptabilise dans son propre bucket et remonte ce bucket à la facturation. Le trafic en zero-rating ne réduit pas le quota principal. Pour d’autres scénarios tarifaires, consultez notre article sur l’évolution des tarifs mobiles et la place de la PCEF.
Ce que devient la liaison PCEF–PCRF sous charge
La PCRF peut devenir un goulet d’étranglement. La croissance du nombre d’abonnés, d’objets connectés (IoT) et de sessions Gx surcharge une PCRF dimensionnée pour des volumes plus faibles. Diameter sur TCP ajoute en outre le blocage en tête de file (head-of-line, HOL) : le retard d’une session ralentit le traitement des autres.
Nous appelons PCRF offload le transfert vers un proxy d’une partie de la logique de décision et du traitement des messages Diameter et Gx. L’objectif est de réduire la charge de la PCRF principale. Le PCRF offload ne remplace pas la PCRF existante.
Notre PCRF Proxy est placé en coupure de l’interface Gx entre la PCEF et la PCRF, en tant que nœud transparent. Son Diameter bridge convertit les sessions TCP en SCTP multistream pour supprimer le blocage HOL.
Notre PCEF repose sur une architecture Control and User Plane Separation (CUPS). Elle permet au traitement du trafic (le plan utilisateur) d’évoluer indépendamment de la logique de gestion des politiques (le plan de contrôle). Nous détaillons cette séparation dans notre article CUPS pour PCEF et PGW.
Notre PCRF Proxy se déploie en quatre étapes : audit de la charge de signalisation, insertion du proxy en coupure de Gx, configuration des règles d’offload, puis supervision avec ajustement fin du routage.
Comment nous travaillons avec les opérateurs sur la PCEF
L’opérateur remplit un formulaire. Nous le contactons, précisons son besoin, lui donnons accès à la documentation et répondons à ses questions, puis nous examinons la situation actuelle : volume de trafic, équipements disponibles et fonctionnalités nécessaires. Nos ingénieurs installent le logiciel choisi et l’adaptent aux besoins de l’opérateur. Le contrat est signé après un test concluant.
Le logiciel peut être testé sur les équipements de l’opérateur, sur une machine virtuelle ou via VPN.
Le déploiement de notre PCEF se déroule en plusieurs étapes. Elles comprennent un audit du réseau et du système de facturation existants ainsi que la conception du schéma d’intégration. Les interfaces Gx et Gy sont configurées avec la PCRF et le système de facturation. Un pilote sur un segment limité d’abonnés précède le déploiement à grande échelle, supervisé dans Stingray NMS. Nos spécialistes accompagnent le projet du pilote jusqu’au support après la mise en service.
Nous assurons le support technique pendant la connexion de la PCEF à la facturation de l’opérateur via les interfaces standard. Notre PCEF a déjà été intégrée à des PCRF, OCS et OFCS de différents systèmes de facturation. Pour en savoir plus, consultez les pages de notre PCEF, de notre PCRF Proxy et de la solution PCRF Offload.
FAQ
Que signifie PCEF ?
Dans la terminologie 3GPP, PCEF signifie Policy and Charging Enforcement Function. Située au niveau de la passerelle, elle assure la détection des flux de données de service, l’application des politiques et la facturation par flux. La PCRF est la Policy and Charging Rules Function, qui gère les règles sur la PCEF via Gx.
Quel nœud prend les décisions de politique, la PCEF ou la PCRF ?
La PCRF prend la décision de contrôle de politique. Dans l’architecture 3GPP, elle détermine comment le trafic de certains services est traité dans la PCEF. La PCEF applique cette décision en contrôlant si un flux passe et quelle QoS il reçoit, à l’aide des règles qu’elle reçoit via Gx.
Quelles interfaces relient la PCEF à la PCRF et à la facturation ?
Gx relie la PCEF à la PCRF. Gy la relie à l’OCS, et Gz à l’OFCS. Sy relie la PCRF et l’OCS. Notre PCEF utilise ces interfaces standard : Gx avec la PCRF, Gy avec l’OCS et Gz avec l’OFCS.
Quel est le rôle du DPI dans une PCEF ?
Dans notre PCEF, le DPI identifie les applications présentes dans le trafic qui la traverse. La classification est la première étape ; la PCEF fixe ensuite les priorités et applique les politiques tarifaires. Notre propre moteur DPI, sur lequel repose la PCEF, classe le trafic par application et par protocole.
Qu’est-ce qu’un PCRF Proxy et comment fonctionne-t-il avec une PCRF existante ?
Notre PCRF Proxy est un nœud transparent sur la liaison Gx entre la PCEF et la PCRF. Il traite lui-même une partie des requêtes, et le reste est transmis à la PCRF existante. Nous appelons cela PCRF offload, et cela ne remplace pas la PCRF existante.
À quoi correspondent la PCRF et la PCEF en 5G ?
Dans le cœur 5G, l’architecture 3GPP fait correspondre la PCRF à la Policy Control Function (PCF). La PCEF correspond à la combinaison de la Session Management Function (SMF) et de la User Plane Function (UPF). N7 relie la SMF et la PCF.
