Dans cet article, nous passons en revue chacun d’eux, montrons comment estimer et limiter les pertes, et indiquons quels indicateurs surveiller pour détecter un problème à temps.
Fonctionnement du comptage dans une passerelle de services
Une passerelle de services se compose de nœuds de traitement et de nœuds de contrôle. Plusieurs éléments participent au comptage du trafic :
- Nœud de traitement (DPI) : élément de la passerelle de services situé dans le plan utilisateur (user plane), par lequel transite physiquement le trafic des abonnés.
- Nœud de contrôle (PCEF) : élément de la passerelle de services situé dans le plan de contrôle (control plane), qui transmet aux nœuds de traitement les seuils de chaque groupe de comptage et reçoit les rapports de consommation.
- Billing (OCS) : système de taxation externe. Il attribue les quotas de trafic et reçoit les rapports de consommation.
- PCRF : système externe de gestion des politiques. Il définit la politique de service de l’abonné et l’ensemble des groupes auxquels l’abonné a droit. Le PCRF joue parfois aussi le rôle d’OCS.
Figure 1. Architecture de la passerelle de services
L’unité de base du comptage est le groupe de comptage. Il regroupe le trafic de plusieurs services taxés de la même manière, et le DPI rend compte de leur volume total. Par exemple, un groupe « streaming vidéo » avec les identifiants RG 10 et SI 0 (Rating Group et Service Identifier) peut rassembler le trafic de YouTube et d’autres services vidéo.
Le DPI classe les paquets, les affecte aux groupes de comptage et tient un compteur de volume pour chaque groupe. Le PCEF obtient les données de volume à partir des rapports du DPI. Le PCEF stocke par ailleurs l’état des sessions : crédits attribués, volume consommé et durées de validité des quotas.
Le PCRF définit aussi les limites de débit de chaque groupe de comptage. L’OCS attribue des volumes pour chaque groupe autorisé et reçoit les rapports de consommation.
Le cycle de comptage commence au niveau du PCRF. Celui-ci indique au PCEF quels groupes de comptage sont accessibles à l’abonné. Le PCEF demande à l’OCS des volumes pour chaque groupe autorisé et transmet au DPI l’ensemble des groupes avec leurs limites et leurs seuils.
Figure 2. Le cycle de comptage
Lorsque la consommation d’un groupe atteint le seuil, le DPI envoie un rapport au PCEF. Le rapport peut aussi être envoyé plus tôt à la demande du PCEF. Le PCEF transmet les données à l’OCS ou au PCRF et reçoit en retour un nouveau quota ou un nouvel ensemble de règles, qu’il envoie ensuite au DPI. Tous les échanges entre le DPI et l’OCS passent par le PCEF.
Le point faible de ce cycle est l’intervalle entre deux rapports. Tant qu’aucun rapport n’est arrivé, ni le PCEF ni l’OCS ne disposent de données sur la consommation accumulée. Cette consommation n’existe que dans les compteurs du DPI. Si un nœud tombe en panne ou si une session est déplacée lors d’un rééquilibrage, le volume non remonté est perdu. C’est la cause profonde des pertes de comptage.
Premier point : panne d’un nœud de traitement
En cas de panne d’un nœud, une certaine perte est inévitable, car le nœud n’a pas le temps de transmettre les données accumulées. Mais l’ampleur de la perte peut être calculée à l’avance :
La formule donne une estimation pour un nœud chargé à pleine capacité. Pendant l’intervalle entre deux rapports, un tel nœud écoule un volume égal à sa capacité multipliée par la durée de l’intervalle. En moyenne, la panne survient au milieu de cet intervalle : environ la moitié de ce volume est donc perdue.
Voici ce que cela donne pour un nœud d’une capacité de 200 Gbit/s.
| Intervalle moyen entre deux rapports | Perte en cas de panne du nœud |
| 5 minutes | environ 3,75 To |
| 1 minute | environ 750 Go |
| 30 secondes | environ 375 Go |
Les chiffres semblent importants, mais à l’échelle d’un nœud, c’est peu. La perte financière finale dépend de la fréquence des pannes et de la manière dont le trafic perdu est taxé.
D’après la formule, la perte est proportionnelle à l’intervalle entre deux rapports. Le DPI envoie un rapport lorsqu’une session a consommé un volume égal au seuil. Plus le seuil est bas, plus vite il est atteint, plus les rapports sont fréquents et plus l’intervalle est court, ce qui signifie une perte plus faible.
Le volume non remonté de chaque session ne dépasse jamais son seuil. Par conséquent, la perte en cas de panne d’un nœud de traitement ne dépasse jamais la somme des seuils de toutes les sessions de ce nœud. Les pertes peuvent donc être maîtrisées par les seuils, qui sont eux-mêmes fixés par le nœud de contrôle PCEF.
Par défaut, le PCEF fixe le seuil à la valeur du quota de l’OCS. La somme des seuils d’un nœud est alors égale au quota multiplié par le nombre de sessions. C’est ce qui sera perdu dans le pire des cas si le nœud tombe en panne. Pour réduire ce risque, l’opérateur peut plafonner à l’avance les pertes possibles.
Budget de risque
Pour cela, le PCEF de VAS Experts propose un budget de risque : le volume maximal qu’il est acceptable de perdre en cas de panne d’un nœud. L’opérateur peut le définir dans la configuration pour le nœud dans son ensemble et séparément pour chaque groupe de services. Lorsqu’un budget est défini, le PCEF vérifie que le quota attribué à un abonné, multiplié par le nombre de sessions utilisant ce service, ne le dépasse pas.
Si le budget est dépassé, le quota est fractionné : le nœud de traitement reçoit un seuil de rapport plus bas. Le PCEF additionne lui-même les rapports intermédiaires et n’envoie un rapport à l’OCS que lorsque la totalité du quota a été consommée.
Figure 2. Fractionnement du quota pour respecter un budget de perte défini
Exemple de calcul
Le système de taxation a attribué un quota de 100 Mo. Deux scénarios sont possibles :
- Le quota, compte tenu du nombre de sessions, reste dans les limites du budget de risque. Le nœud de contrôle fixe un seuil de 100 Mo. Lorsque le seuil est atteint, le PCEF envoie un rapport au système de taxation et demande un nouveau quota.
- Le quota dépasse le budget de risque. Le nœud de contrôle fixe un seuil de 10 Mo, et le nœud de traitement envoie un rapport intermédiaire tous les 10 Mo. Dès que la somme des rapports intermédiaires atteint 100 Mo, le nœud de contrôle envoie un rapport au système de taxation et demande un nouveau quota.
À la place du budget de risque, il est possible d’utiliser une option simplifiée. Le quota est divisé par un coefficient fixe ou plafonné à une valeur constante. Le réglage s’applique à tous les services à la fois ou à chacun séparément. L’option simplifiée ne tient pas compte du nombre de sessions. Elle limite la perte par session et non pour le nœud de traitement dans son ensemble. Son avantage : aucun calcul n’est nécessaire, ce qui en fait un point de départ pratique pour le déploiement.
Deux fréquences de rapport au lieu d’une
Dans notre solution, le fractionnement du quota est assuré par le PCEF. Le PCEF transmet la configuration aux nœuds DPI via PFCP. Ce protocole permet d’attribuer à un nœud DPI un seuil de rapport inférieur au quota. Le PCEF détermine la taille du seuil et l’ajuste au budget de risque configuré. Par exemple, l’opérateur a indiqué que pas plus de 100 Go de trafic non remonté ne peuvent s’accumuler sur un nœud pour le groupe « streaming vidéo ». Si un seul abonné utilise le service, le PCEF lui attribuera un seuil de 50 Go. S’il y a un million d’abonnés, le DPI fera un rapport pour chaque session environ tous les 100 Ko.
Sans fractionnement, le seuil est égal au quota : le DPI rend compte au PCEF exactement aussi souvent que le PCEF rend compte à l’OCS. Avec le fractionnement, ces deux fréquences sont découplées et définies indépendamment.
| Rapports | Ce qui détermine la fréquence | Résultat |
| Du nœud de contrôle vers le système de taxation (du PCEF vers l’OCS) | Le quota attribué par le système de taxation | La charge sur le système de taxation ne change pas |
| Du nœud de traitement vers le nœud de contrôle (du DPI vers le PCEF) | Le budget de risque | La perte en cas de panne d’un nœud de traitement ne dépasse pas le budget de risque |
Sans fractionnement, l’opérateur doit faire un compromis. Des rapports fréquents réduisent les pertes en cas de panne, mais chargent l’OCS. Des rapports espacés soulagent l’OCS, mais augmentent les pertes. Avec le fractionnement, seuls les rapports du nœud de traitement vers le nœud de contrôle deviennent plus fréquents. Cet échange a lieu à l’intérieur de la passerelle de services et coûte moins cher que la communication avec le système de taxation.
Trois conditions pour que le mécanisme fonctionne correctement
Les rapports intermédiaires ne sont pas transmis au système de taxation
Les rapports intermédiaires ne sont pas transmis à l’OCS. L’OCS reçoit un rapport lorsque la totalité du quota a été consommée, ainsi qu’à l’expiration du quota ou à la fin de la session. Les rapports intermédiaires multiplieraient la charge sur l’OCS par le nombre de parts du quota, soit exactement ce que le fractionnement doit éviter.
L’action liée à l’épuisement du quota n’est déclenchée qu’après consommation de la totalité du quota
Le système de taxation peut définir une action en cas d’épuisement du quota : blocage ou redirection. Un seuil intermédiaire ne déclenche que l’envoi d’un rapport, tandis que l’action est exécutée une fois la totalité du quota consommée. Si l’action était liée au seuil intermédiaire, un abonné disposant d’un quota de 100 Mo serait bloqué dès 10 Mo.
Le fractionnement a une limite inférieure
Plus chaque part du quota est petite, plus les rapports sont nombreux, et si le quota est fractionné trop finement, l’échange interne devient lui aussi une charge notable. C’est pourquoi le seuil a une valeur minimale. Si le budget de risque ne peut pas être respecté même à ce minimum, le PCEF génère un avertissement : dépasser le budget sans en informer l’opérateur n’est pas acceptable.
Deuxième point : le rééquilibrage
Les pertes lors d’un rééquilibrage sont moins visibles que les pertes dues à une panne. Lorsque la répartition des abonnés entre les nœuds est calculée en fonction de la liste des nœuds actifs, toute modification de cette liste déplace une partie des sessions vers d’autres nœuds. L’abonné perd alors la connexion, et cela se voit. En revanche, le volume accumulé sur l’ancien nœud depuis le dernier rapport disparaît avec la session.
Le rééquilibrage n’est pas seulement déclenché par des pannes, mais aussi par l’ajout planifié d’un nœud DPI, une opération courante pour augmenter la capacité. Autrement dit, les données de comptage se perdent précisément au moment où le réseau est censé être amélioré.
Découvrez comment croître sans impact sur les abonnés dans notre article Mise à l’échelle dans le modèle CUPS : comment croître sans impact sur les abonnés.
Pour que le volume ne soit pas perdu, la session est transférée vers le nouveau nœud de manière contrôlée :
- Le PCEF crée une session sur le nœud cible, y transfère les services et les profils de l’abonné et fixe le seuil au quota restant.
- Le trafic de l’abonné est basculé vers le nœud cible.
- Le PCEF clôture la session sur le nœud source, et celui-ci envoie un rapport final.
- Le PCEF additionne les volumes comptés par les deux nœuds et fixe un nouveau seuil sur le nœud cible.
Figure 3. Transfert d’une session sans perte de comptage : addition des volumes et seuil absolu sur le nœud cible
Avec ce type de transfert, rien n’est perdu. Le nœud source clôture la session normalement et transmet auparavant tout le volume accumulé. Il n’y a pas non plus de double comptage. Chaque octet n’est compté que par l’un des deux nœuds, et le nouveau seuil du nœud cible est fixé comme une valeur absolue calculée à partir de la consommation totale sur les deux nœuds, et non comme un incrément ajouté à ce que le nœud cible a déjà compté.
Le transfert contrôlé présente un autre avantage. La connexion de l’abonné n’est pas interrompue et la consommation est connue avec précision. Il n’est donc pas nécessaire de fermer puis de rouvrir la session de taxation. Avec un grand nombre de sessions, la différence est considérable. Fermer puis rouvrir une seule session de taxation nécessite quatre messages : une requête et une réponse pour la fermeture, une requête et une réponse pour l’ouverture. Si l’on retire du service un nœud de traitement portant quatre millions de sessions en les fermant puis en les rouvrant, le système de taxation recevra jusqu’à seize millions de messages. Avec un transfert contrôlé, il n’y a aucun échange avec le système de taxation.
Troisième point : bascule du nœud de contrôle
Le PCEF conserve en mémoire l’état des sessions de taxation : quotas attribués, volumes consommés, durées de validité des quotas et numéros des requêtes envoyées au système de taxation. Avec le fractionnement des quotas, les totaux cumulés des rapports intermédiaires y sont également stockés. En cas de panne d’un nœud de contrôle, ses sessions sont reprises par un autre nœud de contrôle. Sans cet état, le nouveau nœud ne sait ni combien de quota il reste, ni quand il expire. C’est pourquoi l’état des sessions est conservé dans un stockage partagé, accessible à tous les nœuds PCEF. Ce stockage doit répondre à deux exigences.
Les durées de validité des quotas sont stockées sous forme d’heure d’expiration absolue, et non de temps restant
Un enregistrement indiquant « le quota est encore valable 400 secondes » est inutile pour un nouveau nœud de contrôle, car celui-ci ne sait pas quand l’enregistrement a été créé. Un enregistrement indiquant « le quota est valable jusqu’à 14:32:07 » est sans ambiguïté à tout moment. Cette exigence suppose que les horloges de tous les nœuds PCEF sont synchronisées.
Le numéro de requête au système de taxation est enregistré dans le stockage avant l’envoi de la requête, et non après
Chaque requête adressée à l’OCS au sein d’une session reçoit son propre numéro. L’OCS rejette comme doublon toute requête portant un numéro déjà utilisé. Supposons qu’un nœud de contrôle ait envoyé une requête et soit tombé en panne avant d’enregistrer le numéro dans le stockage. Le nouveau nœud de contrôle reprendra le dernier numéro enregistré et le réutilisera. L’OCS rejettera la requête, aucun nouveau quota ne sera attribué et la session se retrouvera sans quota. Pour l’éviter, il suffit d’enregistrer d’abord le numéro de requête dans le stockage, puis seulement d’envoyer la requête. C’est simple à mettre en œuvre dans le code. Ce qui est bien plus difficile, c’est de repérer l’erreur elle-même. Elle se produit rarement et ressemble à un incident aléatoire touchant un seul abonné.
Quatrième point : changement de l’ensemble de règles en cours de session
Le PCRF peut changer l’ensemble de règles en pleine session, par exemple lors du passage d’un forfait de jour à un forfait de nuit. Le volume compté avant le changement doit être taxé selon les anciennes règles. Sinon, le trafic consommé dans le cadre du forfait de jour sera taxé au tarif de nuit.
Le mécanisme est simple, mais exige un ordre strict des étapes :
- Le DPI reçoit les nouvelles règles du PCEF.
- Le DPI envoie un rapport sur le volume accumulé.
- Le DPI applique les nouvelles règles.
- Le DPI confirme le changement de règles au PCEF.
La confirmation est envoyée après le rapport : au moment où le PCEF apprend le changement de règles, tout le volume relevant des anciennes règles a donc déjà été comptabilisé.
Entre l’envoi du rapport et l’application des nouvelles règles, il existe un intervalle pendant lequel la configuration de comptage n’est pas définie. Pendant ce temps, une règle par défaut bloquant le trafic de l’abonné doit s’appliquer :
N’attendez pas le rapprochement avec le billing
Les erreurs de comptage ne se manifestent pas immédiatement, et à la fin de la période de facturation, leur cause ne peut plus être retrouvée. Pour détecter un problème à temps, surveillez ces six indicateurs.
| Indicateur | Ce que signifie une hausse |
| Écart entre le nombre de sessions de taxation ouvertes et fermées | Une partie des sessions ne se termine pas normalement, et leur consommation finale n’est pas remontée |
| Nombre de sessions transférées sans rapport final | Le nombre de cas de perte de volume augmente |
| Intervalle moyen entre deux rapports pour les sessions actives | Le multiplicateur de la formule de perte en cas de panne d’un nœud de traitement augmente |
| Somme des seuils de toutes les sessions d’un nœud de traitement | La limite supérieure de la perte en cas de panne de ce nœud augmente. S’approcher du budget de risque est une raison de revoir le fractionnement des quotas |
| Retard des nœuds sur les mises à jour de la table de répartition des sessions | Les nœuds utilisent une table de répartition obsolète. Le trafic de l’abonné peut arriver sur un nœud DPI qui ne gère plus sa session |
| Nombre de rapports provenant d’un nœud de traitement qui ne gère plus la session | Le nombre de rapports tardifs augmente |
Le dernier indicateur mérite une explication. Lorsqu’une session est transférée vers un autre nœud DPI, l’ancien nœud peut envoyer un rapport en retard. Par exemple, le rapport a été envoyé avant la bascule, mais il est parvenu au PCEF après. Un tel rapport contient du trafic réel de l’abonné qui n’a encore été comptabilisé nulle part. Si le PCEF le rejette uniquement parce que ce nœud ne gère plus la session, le volume sera perdu. Autrement dit, la passerelle de services perdra elle-même des données de comptage, sans la moindre panne. C’est pourquoi les rapports tardifs doivent être acceptés et ajoutés à la consommation de la session à laquelle ils se rapportent.
Conclusion
Les pertes dans le comptage du trafic surviennent dans quatre situations, et une seule d’entre elles est inévitable : la panne d’un nœud de traitement. Le nœud n’a pas le temps de transmettre le volume accumulé, et ce trafic échappe au comptage. Mais même dans ce cas, la perte peut être maîtrisée : sa limite supérieure est égale à la somme des seuils du nœud et, grâce au budget de risque, l’opérateur décide lui-même de ce qu’il est prêt à perdre. Dans notre solution, le PCEF ajuste lui-même les seuils à ce budget : la limite de perte en cas de panne de n’importe quel nœud est donc connue à l’avance, sans augmentation de la charge sur l’OCS.
Dans les trois autres situations, les pertes peuvent être évitées si l’on prévoit dès le départ le bon ordre des opérations :
- lors d’un rééquilibrage, les sessions sont transférées vers un autre nœud de traitement de manière contrôlée ;
- les durées de validité des quotas sont stockées sous forme d’heure absolue ;
- le numéro de requête est enregistré avant l’envoi de la requête ;
- le volume accumulé est remonté avant le changement de règles.
Tout cela est facile à prévoir. En revanche, trouver la cause d’un écart après le rapprochement avec le billing est quasiment impossible.
