{"id":14969,"date":"2026-10-07T12:23:05","date_gmt":"2026-10-07T09:23:05","guid":{"rendered":"https:\/\/vasexperts.com\/?p=14969"},"modified":"2026-10-07T18:38:49","modified_gmt":"2026-10-07T15:38:49","slug":"hierarchical-qos-on-pcef-how-to-manage-service-priorities","status":"publish","type":"post","link":"https:\/\/vasexperts.com\/fr\/blog\/mobile-networks\/hierarchical-qos-on-pcef-how-to-manage-service-priorities\/","title":{"rendered":"QoS hi\u00e9rarchique sur PCEF : comment g\u00e9rer les priorit\u00e9s des services"},"content":{"rendered":"L\u2019op\u00e9rateur fait face \u00e0 un probl\u00e8me similaire \u00e0 l\u2019\u00e9chelle de tout le r\u00e9seau. En cas de congestion aux heures de pointe ou lors de grands \u00e9v\u00e9nements, le c\u0153ur de r\u00e9seau envoie des profils mis \u00e0 jour avec une bande passante r\u00e9duite, ce qui abaisse le d\u00e9bit de tous les abonn\u00e9s \u00e0 la fois. Tous les services se disputent alors sans distinction la ressource restante. La vid\u00e9o et les appels, sur lesquels l\u2019abonn\u00e9 juge la qualit\u00e9 du r\u00e9seau, se d\u00e9gradent en premier, et il est difficile pour l\u2019op\u00e9rateur de redistribuer rapidement la bande passante entre les services.\r\n\r\nLe probl\u00e8me ne vient ni de pannes d\u2019\u00e9quipement ni de la configuration d\u2019un r\u00e9seau particulier. Le standard 3GPP (3rd Generation Partnership Project) d\u00e9crit des m\u00e9canismes pour limiter la bande passante de l\u2019abonn\u00e9 et de services individuels, mais il ne d\u00e9finit pas quel service obtient la bande passante en premier lorsqu\u2019il n\u2019y en a pas assez pour tous. Dans cet article, nous verrons o\u00f9 se situe cette lacune du standard et comment le PCEF de VAS\u00a0Experts<\/a> la comble.\r\n

Un plafond, mais pas de r\u00e8gles<\/h2>\r\nPour comprendre d\u2019o\u00f9 vient cette lacune, il faut se plonger dans la sp\u00e9cification 3GPP TS 23.203 \u00ab Policy and charging control architecture \u00bb<\/a> (architecture de contr\u00f4le des politiques et de la tarification).\r\n\r\nL\u2019architecture QoS du 3GPP repose sur les porteuses : les bearers en LTE et les QoS Flows en 5G. Une porteuse est un canal logique entre le terminal de l\u2019abonn\u00e9 et la passerelle de paquets<\/a>, avec son propre ensemble de param\u00e8tres de qualit\u00e9.\r\n

Dedicated Bearer<\/h3>\r\nSi un flux de donn\u00e9es n\u00e9cessite des param\u00e8tres de service sp\u00e9cifiques (d\u00e9bit garanti, latence<\/a> admissible et taux de perte de paquets<\/a>) ou une priorit\u00e9 particuli\u00e8re, une porteuse distincte (Dedicated Bearer) est cr\u00e9\u00e9e pour lui avec son propre profil QoS (QCI\/5QI, ARP).\r\n\r\nLe standard permet aussi de d\u00e9finir une priorit\u00e9 via l\u2019ARP (Allocation and Retention Priority), mais il s\u2019agit de la priorit\u00e9 de la porteuse, et non d\u2019un service individuel. Le SDF (service definition function) r\u00e9partit les services entre les porteuses pour lesquelles un QCI et un ARP sont d\u00e9finis. En cas de manque de ressources radio, une porteuse dont l\u2019ARP est faible ne sera pas cr\u00e9\u00e9e, et une porteuse existante peut \u00eatre enti\u00e8rement supprim\u00e9e. La priorit\u00e9 existe donc au niveau de la porteuse, mais elle n\u2019influe que sur la cr\u00e9ation ou la suppression de la porteuse enti\u00e8re, avec tous les services qu\u2019elle contient, et ne permet pas de r\u00e9partir la bande passante de mani\u00e8re souple entre les services.\r\n

Default Bearer<\/h3>\r\nTout le trafic des services pour lesquels aucun canal d\u00e9di\u00e9 n\u2019a \u00e9t\u00e9 cr\u00e9\u00e9 (web, messageries, YouTube, torrents, mises \u00e0 jour en arri\u00e8re-plan) passe par le canal de base, la porteuse par d\u00e9faut (Default Bearer). Il s\u2019agit toujours d\u2019une porteuse non-GBR (Non-Guaranteed Bit Rate), \u00e0 laquelle on attribue g\u00e9n\u00e9ralement la classe de faible priorit\u00e9 QCI 9. Le trafic de cette classe est trait\u00e9 selon les ressources disponibles (best effort), et sa remise n\u2019est pas garantie. Pour tout le trafic non-GBR, le standard pr\u00e9voit un param\u00e8tre commun : l\u2019APN-AMBR.\r\n\r\n[important]L\u2019APN-AMBR est le plafond de d\u00e9bit agr\u00e9g\u00e9 pour l\u2019ensemble du trafic non-GBR d\u2019un abonn\u00e9 au sein d\u2019un APN.[\/important]\r\n\r\nConform\u00e9ment \u00e0 la sp\u00e9cification 3GPP, le r\u00f4le du PCEF (Policy and Charging Enforcement Function) est de veiller \u00e0 ce que le d\u00e9bit total de tous les flux de donn\u00e9es de service (SDF) non-GBR au sein d\u2019un point d\u2019acc\u00e8s r\u00e9seau (APN) ne d\u00e9passe pas ce plafond. Le standard ne d\u00e9crit pas comment r\u00e9partir la bande passante entre des flux concurrents lorsque leur demande totale d\u00e9passe le plafond. C\u2019est pourquoi les interfaces par lesquelles le serveur de politiques (PCRF<\/a>) transmet les r\u00e8gles au PCEF (par exemple, Gx via le protocole Diameter<\/a>) ne comportent aucun attribut (AVP) permettant de transmettre une telle r\u00e9partition.\r\n\r\n[important]Le PCRF (Policy and Charging Rules Function) est le n\u0153ud qui prend les d\u00e9cisions de politique QoS et de tarification et les transmet au PCEF sous forme de r\u00e8gles.[\/important]\r\n\r\nImaginons que l\u2019offre de l\u2019abonn\u00e9 soit de 50 Mbit\/s, alors qu\u2019un torrent ou une mise \u00e0 jour de jeu peut occuper jusqu\u2019\u00e0 100 Mbit\/s : le canal est enti\u00e8rement satur\u00e9. Les paquets de la messagerie passent par le m\u00eame policer que le torrent. Faute de r\u00e8gles d\u2019\u00e9quilibrage, le policer coupe le trafic sans distinguer les services. Presque toute la bande passante revient alors \u00e0 celui qui g\u00e9n\u00e8re le plus de trafic, en l\u2019occurrence le torrent.\r\n\r\nLe standard 3GPP r\u00e9glemente strictement les interfaces entre les n\u0153uds, mais laisse volontairement aux fabricants d\u2019\u00e9quipements la logique d\u2019ordonnancement (scheduling) et la concurrence du trafic au sein d\u2019un m\u00eame APN. R\u00e9sultat : le standard ne pr\u00e9voit aucun m\u00e9canisme de r\u00e9partition de la bande passante entre les services selon leur priorit\u00e9.\r\n

QoS hi\u00e9rarchique sur le PCEF de VAS\u00a0Experts<\/h2>\r\nChez VAS Experts, ce probl\u00e8me est r\u00e9solu gr\u00e2ce \u00e0 la QoS hi\u00e9rarchique (HQoS) sur le PCEF avec des profils locaux. La bande passante de l\u2019abonn\u00e9 n\u2019est pas augment\u00e9e : elle est r\u00e9partie entre les services selon leur priorit\u00e9. Les types de trafic prioritaires, comme la voix et le web, en b\u00e9n\u00e9ficient en premier, tandis que le P2P et les t\u00e9l\u00e9chargements en arri\u00e8re-plan utilisent le reste.\r\n

Deux niveaux de policing<\/h3>\r\nLe niveau sup\u00e9rieur de la hi\u00e9rarchie est la classe racine HTB (root), c\u2019est-\u00e0-dire la bande passante totale de l\u2019abonn\u00e9. Elle est d\u00e9finie dans le profil de policing (plan tarifaire). On y indique la valeur de l\u2019APN-AMBR (ou le d\u00e9bit de l\u2019offre d\u2019Internet r\u00e9sidentiel), par exemple 50 Mbit\/s. Au total, l\u2019abonn\u00e9 ne pourra pas d\u00e9passer ce plafond.\r\n\r\nLe second niveau (leaf classes) comprend huit classes, de class0 \u00e0 class7. Par d\u00e9faut, class0 a la priorit\u00e9 la plus \u00e9lev\u00e9e et class7 la plus faible. Le moteur DPI<\/a> \u00e0 signatures reconna\u00eet le protocole ou la destination du trafic (YouTube, BitTorrent, Telegram) et affecte le flux \u00e0 la classe appropri\u00e9e. La r\u00e9partition par classes est d\u00e9finie par un marquage global par protocoles et destinations, ou par un marquage individuel par protocoles pour un abonn\u00e9 donn\u00e9. Les classes sont associ\u00e9es aux groupes de tarification (rating groups) via une table de correspondance.\r\n\r\n