Procédé de gestion de charge d'un équipement d'un système de mise en œuvre d'un service applicatif

Domaine de l'invention Le domaine de l'invention est celui des réseaux de télécommunications, et plus particulièrement celui d'un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications

L'invention trouve son application pour la gestion de la charge d'équipements d'un système mettant en œuvre un service applicatif dans un réseau de télécommunications, par exemple un service de téléphonie déployé au dessus d'un réseau IP.et en particulier dans la gestion des phénomènes de la surcharge plus particulièrement le problème dit « Flash Crowds » Art antérieur Le réseau IP (Internet Protocol) devient de plus en plus le support universel d'une multitude de services et applications C'est le réseau fédérateur adopte par les operateurs pour mutuahser leurs offres de service hétérogènes Parmi ces services, la téléphonie IP ou la voix sur IP, connue aussi sous le sigle VoIP pour (Voice over IP), a pris ces dernières années une place prépondérante, au point que tous les fournisseurs de services disposent aujourd'hui d'offres IP à destination de leurs clients, qu'ils soient des clients résidentiels ou des entreprises Ces offres de services, basées sur le protocole IP, s'opposent de par leur conception et leur philosophie a la téléphonie traditionnelle qui s'appuie sur la commutation de circuits L'avantage avance pour le passage a la téléphonie sur IP, outre le coût moindre des communications, est la capacité estimée à pouvoir faire du couplage de services avec le monde de l'informatique et l'Internet en particulier

Pour accompagner le déploiement de services de VoIP, I ¹ IETF (Internet Engineering Task Force) a porté de nombreux travaux de standardisation Plusieurs protocoles ont été ainsi spécifiés parmi lesquels on peut citer SIP (Session Initiation Protocol) SDP (Session Description Protocol), RTP (Real-time Transport Protocol), RTCP (Real-time Transport Control Protocol), MGCP (Multimedia Gateway Control

Protocol), SAP (Session Announcement Protocol) et TRIP {Telephony Routing Over IP), etc. Ces protocoles répondent à des besoins différents et intègrent en particulier la signalisation et la commande des appels, l'échange des flux média, leur contrôle et l'échange d'informations de routage des appels. Pour satisfaire les clients qu'ils ont attirés, les opérateurs de télécommunications fournisseurs de services de VoIP doivent satisfaire diverses contraintes liées notamment à la disponibilité du service, à sa configuration (provisioning), à son coût, à la sécurité des flux de communications, à la tolérance aux pannes et à la flexibilité du service. En particulier, ils doivent se prémunir contre les phénomènes de surcharge qui peuvent affecter les équipements participant à la mise en œuvre du service de téléphonie sur IP

On entend ici par surcharge l'incapacité du service ou d'équipements mettant en oeuvre le service, à traiter une demande. Cette incapacité est souvent due à une insuffisance de ressources disponibles lors de la réception de la demande. La gestion d'une surcharge est d'autant plus délicate, qu'il s'agit d'un phénomène qui a tendance à s'entretenir lui-même.

En effet, le problème affecte souvent progressivement les autres équipements du service, qui en essayant d'écouler le trafic, et se trouvent à leur tour surchargés. De plus, une partie des ressources est alors utilisée pour envoyer des messages d'erreurs ou d'alertes, ce qui empiète encore davantage sur les ressources disponibles pour résoudre le problème Un facteur dégradant supplémentaire tient à la réémission des requêtes qui est destinée à prévenir des potentielles erreurs du transport IP. Une telle procédure de réémission est décrite, par exemple, dans la RFC définissant SIP [RFC3261] Inconvénients de l'art antérieur

Des règles d'ingénieries permettent aux opérateurs de télécommunications d'éviter ce genre de phénomène dans des conditions normales de fonctionnement, d'une part en dimensionnant de manière juste leur service, d'autre part en mettant en œuvre des mécanismes de partage de charge (ou load balancing en anglais) entre les nœuds constituant le service. Cependant, ces mécanismes s'avèrent pour la plupart du

temps insuffisants à l'occasion d'événements exceptionnels qui engendrent des pics de charge (exemples Nouvelle Année, tremblement de terre, coupure d'électricité, événements graves tels que ceux survenus lors des événements du 11 septembre, etc ) ou bien encore suite à une panne affectant le parc des clients ou la plateforme de service

L'un des phénomènes de surcharge les moins évidents à appréhender est celui dit couramment "Flash Crowds", qui se produit typiquement lorsqu'un nombre important d'utilisateurs tente simultanément d'effectuer un appel, les éléments du service n'ayant pas été dimensionnés pour absorber cet afflux simultanément (i e burst de trafic) En effet, le dimensionnement des réseaux de téléphonie est notamment basé sur une distribution statistique des appels, régie notamment par les lois d'Erlang Or ce type de dimensionnement n'est pas destine a aboutir au déploiement d'un service pouvant faire face aux surcharges occasionnelles du trafic Dans le cas d'un phénomène de type "Flash Crowds", l'origine d'un goulot d'étranglement au niveau de la plateforme de service peut alors émaner de deux situations particulières (1 ) un afflux important d'appels vers une destination (e g numéro d'appel ou une zone géographique) particulière ou (2) un afflux important provenant d'une région (en termes de raccordement au service) donnée Un exemple consiste à considérer un jeu télévisé annonçant un numéro de téléphone a joindre pour recevoir une somme d'argent Ce genre de situation peut déboucher sur un grand nombre d'appels passes vers le numéro en question sur une période relativement courte, entraînant une congestion dégradant le niveau du service rendu et donc celui perçu par les utilisateurs (autres que ceux appelant le dudit numéro)

Une solution connue de l'art antérieur et décrite dans le document RFC 3261 du protocole SIP ("Session Initiation Protocol") consiste en ce que l'équipement congestionne notifie le client de l'impossibilité d'accéder au service II peut utiliser dans ce but le code d'erreur dans sa réponse "503", l'envoi d'un message d'erreur SIP avec ce code signifiant que l'élément de service sollicite n'est pas en mesure de traiter la requête suite à une surcharge temporaire ou a une opération de maintenance L'équipement en question peut à cette occasion indiquer un délai après lequel le client

pourra effectuer une nouvelle tentative (notamment avec le champ "Retry-After"). Un client recevant un tel code de réponse est censé solliciter un autre équipement pour satisfaire sa demande, au moins jusqu'à expiration du délai spécifié par le champ "Retry-After" (s'il est indiqué) et si la possibilité de contacter un autre équipement est offerte

Une proposition alternative est toujours en cours de discussion au sein des organismes de standardisation, en particulier à l'IETF (Internet Engineering Task Force). Elle consiste en l'ajout par les équipements du service, dans les messages de signalisation, par exemple selon le protocole SIP ("Session Internet Protocol"), d'un champ dédié au traitement des phénomènes de congestion/surcharge, afin de fournir une meilleure qualification de l'état de congestion. Ce champ dédié de l'en-tête SIP, dénommé "CONGESTION", peut être inséré dans toute réponse SIP. Il permet notamment de caractériser le degré de congestion constaté (valeur allant de 0 à 4), le type de congestion (e g CPU, réseau, etc.), l'équipement concerné ainsi qu'un délai au-delà duquel une nouvelle tentative pourra être effectuée (dans l'hypothèse où le degré de congestion est à son maximum.). Cette solution est similaire à l'utilisation du tag "Retry-After" décrit ci-haut car l'équipement de service doit générer un message et exécuter une procédure pour déterminer (voir prédire, compte tenu des demandes présentes et futures) l'échéance de son retour à la normale, ce qui n'est pas facilement réalisable lors des phénomènes de surcharge exceptionnels (tels que des crises, événements importants, etc.).

Un premier inconvénient de ces solutions est qu'elles supposent que l'équipement congestionné est en mesure de générer un tel message et de procéder au traitement associé lors d'une surcharge du service. Un deuxième inconvénient est qu'elles génèrent du trafic supplémentaire. Un troisième inconvénient est qu'elles résolvent le problème de surcharge de manière curative. Concrètement et en plus des inconvénients listés ci-haut, on peut citer aussi les problèmes suivants :

Amplification de la surcharge du service Le fait de réorienter un client vers un autre équipement du service, qui lui-même est peut être surchargé, peut induire un accroissement non-négligeable du

nombre de messages échangés, augmentant la surcharge globale pouvant même aboutir, à l'extrême, à un effondrement (i e indisponibilité) du service Cette technique n'est donc pas adaptée à partir du moment où plusieurs équipements sont en situation de surcharge

Sous-utilisation des ressources La portée d'un message SIP avec code erreur "503" n'est pas suffisamment précise Typiquement, si plusieurs serveurs sont regroupes sous un même nom de domaine, et que l'un d'eux est surcharge, un client pourrait considérer qu'il ne faut plus solliciter le nom de domaine en question, alors que dans la réalité seul un serveur parmi ceux pointés par le nom de domaine est surcharge Avec l'entête "CONGESTION", on minimise quelque peu ce problème, car cet entête contient un champ permettant de caractériser plus précisément l'élément ayant envoyé le message Toutefois, l'exploitation de cette information n'est pas décrite dans les documents de spécification, et peut donc être différente d'une implémentation à l'autre

Manque de souplesse La notification d'un délai grâce au champ "Retry-After" permet à un équipement surchargé d'indiquer au demandeur de n'émettre la requête qu'à l'expiration d'un « timer » donne De plus, l'équipement surchargé peut rediriger ou pas tout le trafic qui lui arrive, sans possibilité de ne rediriger qu'une partie seulement après l'occurrence du phénomène de surcharge Ambiguïtés d'utilisation La procédure décrite dans la RFC3261 ne précise pas suffisamment les circonstances selon lesquelles le code erreur réponse "503" doit être utilise De ce fait, d'autres cas d'usage ont ete spécifiés voire implementés Ceci complique l'interprétation précise de ce code a des fins propres de détection de surcharge

Exposé de l'invention

II existe donc un besoin de pallier ces inconvénients de l'art antérieur Plus précisément, il existe un besoin de fournir une solution pour prévenir un phénomène de surcharge dans un système de mise en œuvre d'un service applicatif héberge par un reseau de télécommunications L'invention répond à ce besoin à l'aide d'un procédé de gestion de charge d'un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications, ledit système comprenant une pluralité d'équipements parmi lesquels des équipements de bordure aptes à relayer des messages d'établissement de sessions applicatives entre des équipements dudit système et des reseaux d'accès au service

Selon l'invention, le procédé de gestion de charge est caractérise en ce qu'il comprend les étapes suivantes

- obtention d'un taux de charge effectif d'au moins un équipement du système,

- si le taux de charge effectif dudit au moins un équipement atteint un taux de charge autorisé dudit au moins un équipement, calcul d'un nouveau taux de charge autorisé pour au moins un des équipements de bordure, le taux de charge effectif dudit au moins un équipement étant fonction dudit taux de charge autorise pour ledit au moins un équipement de bordure

Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion de la charge supportée par un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications En effet, l'invention propose un mécanisme de gestion de la charge qui consiste à corréler le taux de charge d'au moins un équipement du système aux taux de charge individuels des équipements de bordure de ce système Un contrôle des taux de charge individuels des équipements de bordure permet de maîtriser le taux de charge d'au moins un équipement du système, de telle sorte que son taux de charge effectif reste en deçà d'un taux de charge autorise

Un critère fondamental adopte par cette invention n'est plus la détection de la surcharge d'un équipement du service, mais la prévention d'une surcharge du système, en s'appuyant sur les taux de charge effectifs mesures a la périphérie ou au cœur du

système La mise en œuvre de l'invention se fait en imposant des seuils de charge, ou taux de charge autorises, a ne pas dépasser, aux équipements de bordure lesquels permettent l'interconnexion avec des opérateurs tiers ou avec des réseaux d'accès au service, et d'autres équipements faisant partie du cœur de reseau L'invention permet ainsi de résoudre le problème technique de la prévention de phénomènes de surcharge tel que le phénomène de "Flash Crowds"

Selon un aspect de l'invention, le taux de charge autorisé pour un équipement de bordure est calculé à partir d'un taux d'acceptation de requêtes de signalisation reçues On considère en effet que le trafic de données média génère peut être déduit des messages de signalisation, par exemple à partir de connaissances a priori sur la consommation de ressources d'un CODEC particulier

Un avantage de cet aspect de l'invention est qu'il permet d'ajuster de manière dynamique le trafic entrant au niveau des équipements de bordure en fonction de l'état de charge du système en général et des équipements de bordure en particulier Selon un premier mode de réalisation de l'invention, le taux de charge effectif obtenu concerne une pluralité d'équipements formant une plateforme centralisée

Ce taux constitue un taux de charge effectif global de la plateforme centralisée, qui est considère, selon l'invention, comme une fonction des taux de charge effectifs individuels des équipements de bordure du système Un avantage est de contrôler ce taux de charge global en régulant les taux de charge individuels des équipements de bordure

Selon un deuxième mode de réalisation de l'invention, le taux de charge effectif obtenu concerne un équipement de bordure et l'étape de calcul d'un taux autorisé évalue la possibilité d'affecter audit équipement de bordure un nouveau taux autorisé supérieur au taux autorisé actuel et inférieur a une capacité maximale dudit équipement de bordure

Un avantage est que, lors d'un afflux important de requêtes de signalisation au niveau d'un équipement de bordure, par exemple lorsqu'une situation de crise survient dans une région donnée, le procédé selon l'invention donne la possibilité à cet équipement d'absorber la surcharge en lui augmentant, dans la mesure de ses

capacités, la valeur de son taux de charge maximale autorisée

De façon avantageuse, le procédé comprend en outre une étape d'obtention d'un taux de charge effectif d'une pluralité d'équipements formant une plateforme centralisée et en ce que l'étape de calcul est mise en oeuvre si le taux de charge effectif de la plateforme centralisée est inférieur à un taux de charge autorisé pour ladite plateforme

Un avantage est que le taux de charge autorise pour l'équipement de bordure n'est augmenté que dans la mesure où le taux de charge global autorisé de la plateforme de service le permet Selon encore un autre aspect de l'invention, le procédé de gestion de charge comprend une étape d'envoi du nouveau taux autorise audit au moins un équipement de bordure concerné

L'équipement de bordure concerné peut donc prendre en compte ce nouveau taux pour le traitement des requêtes de signalisation qu'il reçoit Selon un autre aspect de l'invention, l'étape d'obtention d'un taux de charge effectif de la plateforme centralisée comprend une étape de récupération dudit taux de charge auprès d'un équipement de supervision

Selon cet aspect de l'invention, le taux de charge global du système de téléphonie n'est pas estimé par l'équipement qui met en œuvre le procédé, mais récupéré auprès d'un ou plusieurs autres équipements. Un avantage est de ne pas surcharger l'équipement du système de téléphonie qui met en œuvre le procédé de gestion de charge et de profiter de mesures de charge qui sont généralement disponibles dans le cœur d'un système de téléphonie

De façon alternative, le procédé de gestion de charge selon l'invention comprend une étape d'estimation du taux de charge effectif global du système de téléphonie à partir de ladite au moins une information obtenue (auprès des équipements de bordure)

Selon cet aspect de l'invention, l'équipement qui met en œuvre le procède de gestion de charge selon l'invention est capable d'estimer la charge globale du système a partir des charges individuelles des équipements de bordure Le procédé selon

l'invention s'appuie sur le fait qu'on peut relier mathématiquement le taux de charge effectif de la plateforme de service aux taux de charge effectifs individuels des équipements de bordure Un avantage d'obtenir le taux de charge effectif de la plateforme de service par calcul, est de ne pas dépendre d'un équipement de supervision Un avantage est qu'un équipement de bordure peut mettre en œuvre le procédé selon l'invention sans dépendre d'un autre équipement du cœur du système

Selon un autre aspect de l'invention, le procède de gestion de charge comprend en outre une étape d'obtention d'un taux de charge autorisé dudit équipement de bordure Le taux de charge autorise actuel de l'équipement de bordure est donc transmis par l'équipement de bordure lui-même à l'équipement qui met en œuvre l'invention en même temps que le taux de charge effectif Cet aspect de l'invention est particulièrement avantageux lorsque le procédé de gestion de charge est susceptible d'être mis en œuvre par au moins deux équipements du système applicatif, afin que l'un puisse prendre connaissance d'un taux de charge autorise fixé par l'autre Ceci est par exemple le cas, lorsque le procédé selon l'invention est mis en œuvre par plusieurs équipements de bordure Un autre avantage est la prévention d'une panne de l'équipement de configuration en garantissant que d'autres équipements du système, susceptibles de le remplacer si besoin, disposent des informations de configuration en vigueur dans le système Dans un mode particulier de réalisation, les différentes étapes du procédé de gestion de charge d'un système de mise en œuvre d'un service applicatif sont déterminées par des instructions de programmes d'ordinateurs

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un équipement de configuration du système de téléphonie ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées a la mise en œuvre des étapes d'un procède de configuration tel que décrit ci-dessus

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source

et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable

L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapte pour exécuter ou pour être utilisé dans l'exécution du procédé en question

Le procédé de configuration selon l'invention peut notamment être mis en œuvre par un équipement de configuration du système de mise en œuvre du service applicatif Par conséquent, l'invention concerne un équipement de configuration d'un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications, ledit système comprenant une pluralité d'équipements parmi lesquels des équipements de bordure aptes à échanger des messages d'établissement de sessions applicatives avec des réseaux d'accès au service, caractérise en ce que ledit équipement de configuration comprend les moyens suivants

- obtention d'un taux de charge effectif d'au moins un équipement du système,

- si le taux de charge effectif dudit au moins un équipement atteint un taux de charge autorise pour cet équipement, calcul d'un nouveau taux de charge autorisé pour au moins un des équipements de bordure, le taux de charge effectif dudit au moins un équipement étant fonction dudit taux de charge autorise dudit au moins un équipement

de bordure.

Selon ce mode de réalisation centralisé de l'invention, le procédé est mis en oeuvre par un équipement de configuration, auquel une pluralité d'équipements de bordure renvoient leur informations relatives aux taux de charge. L'équipement de configuration calcule les nouveaux taux autorisés pour les équipements de bordure du système et leur envoie pour mise en application. Un avantage d'un tel mode de réalisation centralisé est le contrôle du comportement du système et la possibilité pour l'opérateur de service de modifier la configuration du service en agissant sur l'élément central implémentant le procédé de gestion de charge. Un autre avantage de cette solution est de garantir la cohérence du service rendu.

L'invention concerne également un procédé de régulation de charge d'un équipement de bordure d'un système de mise en oeuvre d'un service applicatif dans un réseau de télécommunications IP, ledit système comprenant une pluralité d'équipements parmi lesquels des équipements de bordure aptes à échanger des requêtes d'établissement de sessions applicatives avec des réseaux d'accès au service, caractérisé en ce qu'il comprend les étapes suivantes : -envoi d'un taux de charge effectif à un équipement de configuration dudit système; - réception d'un nouveau taux de charge autorisé en provenance dudit équipement de configuration; et - régulation d'un traitement de requêtes de signalisation reçues par ledit équipement de bordure en fonction du nouveau taux de charge autorisé

Selon un aspect de l'invention, l'étape d'envoi est mise en œuvre lorsque ledit taux de charge effectif atteint le taux de charge autorisé. Un avantage est de ne solliciter l'équipement de configuration que lorsqu'un événement le justifie Selon une variante, l'étape d'envoi est mise en oeuvre selon un rythme d'envoi prédéterminé.

Un avantage est d'adapter régulièrement le taux de charge autorisé des équipements de bordure au trafic.

Dans un mode particulier de réalisation, les différentes étapes du procédé de régulation de charge sont déterminées par des instructions de programme d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un équipement de bordure du système ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de configuration tel que décrit ci-dessus.

L'invention concerne également un équipement de bordure d'un système de mise en œuvre d'un service applicatif sur un réseau de télécommunications, ledit système comprenant une pluralité d'équipements parmi lesquels des équipements de bordure aptes à relayer des messages d'établissement de sessions applicatives entre des équipements du système et des réseaux d'accès au service, caractérisé en ce qu'il comprend les moyens suivants : -envoi d'un taux de charge effectif à un équipement de configuration dudit système;

- réception d'un nouveau taux de charge autorisé en provenance dudit équipement de configuration, et

- régulation d'un traitement de requêtes de signalisation reçues par ledit équipement de bordure en fonction du nouveau taux de charge autorisé, L'équipement de bordure peut être, par exemple, un Session Border Controller (SBC) ou un serveur de proximité classique (encore appelé Proxy Server selon le protocole SIP).

Selon un autre aspect de l'invention, l'équipement de bordure agit en outre en tant qu'équipement de configuration selon l'invention. Selon ce mode de réalisation distribué, l'équipement de bordure reçoit les taux de charge effectifs d'autres équipements de bordure et calcule de nouveaux taux de charge autorisés pour ces équipements, de telle sorte que le taux de charge globale de la plateforme de service reste en deçà d'un taux de charge global autorisé. Un avantage est de ne pas surcharger les équipements du cœur du système L'invention concerne enfin un système de mise en œuvre d'un service applicatif

dans un réseau de télécommunications IP, ledit système comprenant une pluralité d'équipements parmi lesquels des équipements de bordure aptes à relayer des messages d'établissement de sessions applicatives entre des équipements du système et des réseaux d'accès au service ; caractérisé en ce qu'il comprend : au moins un équipement de configuration selon l'invention et en ce que les équipements de bordure comprennent les moyens suivants : -envoi d'un taux de charge effectif à un équipement de configuration dudit système; - réception d'un nouveau taux de charge autorisé en provenance dudit équipement de configuration; et - régulation d'un traitement de requêtes de signalisation reçues par ledit équipement de bordure en fonction du nouveau taux de charge autorisé,

Liste des figures

D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente de façon schématique un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications selon l'art antérieur, - la figure 2 présente les étapes du procédé de gestion de charge d'un système selon l'invention; la figure 3 présente les étapes du procédé de gestion de charge d'un système selon un mode de réalisation centralisé de l'invention; la figure 4 présente les étapes du procédé de gestion de charge d'un système selon un mode de réalisation distribué et hiérarchisé de l'invention; la figure 5 présente les étapes du procédé de gestion de charge d'un système selon un mode de réalisation distribué et non hiérarchisé de l'invention, la figure 6 présente de façon schématique la structure d'un équipement de configuration mettant en œuvre le procédé de gestion de charge selon l'invention;

la figure 7 présente de façon schématique un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications selon un mode de réalisation centralisé de l'invention, la figure 8 présente de façon schématique un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications selon un mode de réalisation distribué et hiérarchisé de l'invention, et la figure 9 présente de façon schématique un système de mise en œuvre d'un service applicatif dans un réseau de télécommunications selon un mode de réalisation centralisé et non hiérarchisé de l'invention

Description d'un mode de réalisation particulier de l'invention

Le principe général de l'invention repose sur la maîtrise du taux de charge global d'une architecture de service déployée sur un réseau de télécommunications, un système de mise en œuvre d'un service applicatif, en régulant la charge des équipements constitutifs de ce système, afin d'éviter d'atteindre un seuil de charge critique Une telle régulation se fait au niveau des équipements de bordure situés dans le réseau de télécommunications hébergeant le système En effet, ce sont ces équipements de bordure qui, en permettant l'échange de requêtes de signalisation et de flux média entre le système de mise en œuvre du service applicatif et un réseau d'accès par l'intermédiaire duquel un terminal d'utilisateur accède au service, voient passer le trafic entrant dans le système

La fonction des équipements de bordure peut être rendue par des équipements dédiés ou supportée par un serveur de proximité (ou encore appelé Proxy Server) lorsque la mise en œuvre du service se fait par la collaboration d'une pluralité de plateformes de téléphonie Le déploiement d'une pluralité d'équipements de bordure est adopte notamment dans la majeure partie des architectures de services de téléphonie sur IP déployées à ce jour, selon lesquelles l'accès des clients aux services conversationnels s'effectue au travers de points de présence (Point of Présence ou

POP) de services, la plupart du temps distribués, qui accèdent eux mêmes à une plateforme de service centralisée, dite aussi cœur du service

Dans la suite de la description, on considère, à titre d'exemple, un système de téléphonie On notera toutefois que l'invention s'applique à tout type d'architecture de service applicatif, pourvu qu'elle nécessite un établissement de session applicative entre le client et le système On présente, en référence à la figure 1, un réseau de télécommunications CN hébergeant un système de téléphonie Une vue simplifiée de ce système permet de le décomposer en trois segments les clients finaux représentés dans cet exemple comme des terminaux T1 a T4, des équipements d'accès au service tels que des équipements de bordure (encore appelés Session Border Controllers ou SBC) EB1 à EB4, des serveurs DHCP ou clients relais DHCP qui peuvent être situés dans des PoP (Point of Présence, Point de Présence) d'accès donnés et des équipements de service du reseau cœur formant une plateforme de service centralisée PFT, tels que des serveurs de proximité (ou Proxy Server) ou encore des serveurs de bases de données (non représentés) Les équipements de bordure EBi, i entier compris entre 1 et 4, sont aptes à recevoir des messages de signalisation et média en provenance d'un terminal client Ti et à le transmettre au système de téléphone et vice-versa De manière générale, les clients finaux T1 à T4 sont répartis (ou attachés) entre différents POP (Point Of Présence) ou réseaux d'accès AN1 à AN4 Les équipements de bordure EB1 à EB4 servent d'interface pour les échanges de signalisation et média entre le réseau cœur de télécommunication et les réseaux d'accès AN1 à AN4 Les équipements de bordure rendent plusieurs autres fonctions telles que, par exemple, un contrôle de la qualité du service, un contrôle des codées utilises ou encore une correction protocolaire (par exemple concernant une validation des messages, un reformatage des messages ou encore un ajout d'en-têtes spécifiques)

Dans la suite de la description on considère que les messages de signalisation échangés sont conformes au protocole SIP (Session Initiation Protocol) On notera toutefois que le domaine d'application de l'invention ne se limite pas à ce cas particulier, mais concerne tout autre protocole de signalisation pour l'établissement de sessions, tel que, par exemple le protocole IAX (Inter-Asteπsk Exchange)

Le procédé de gestion de charge d'un système de mise en œuvre d'un service applicatif selon l'invention va maintenant être décrit en référence à la figure 2. Un tel procédé comprend une étape E1 d'obtention GET d'au moins un taux de charge effectif NPi ou Ni d'au moins un des équipements du système de téléphonie IP, Npi étant le taux de charge effectif d'un équipement central et Ni le taux de charge effectif d'un équipement de bordure EBi On notera qu'une telle information peut aussi bien être obtenue en mode PULL ou en mode PUSH. En mode PULL, elle est obtenue sur requête auprès de l'équipement, alors qu'en mode PUSH, elle est émise spontanément par cet équipement, par configuration ou lorsqu'un événement déclencheur survient Le taux de charge effectif obtenu peut être constitué d'un ou plusieurs différents types d'informations II peut s'agir, par exemple, d'une mesure de charge CPU. Si l'équipement de service considéré est un équipement de bordure EB1 à EB4, le taux de charge effectif Ni est obtenu dans une étape E11 et concerne au moins un état des sessions de voix sur IP simultanées actives ou un nombre de requêtes d'accès au service reçues pendant une période de temps donnée. Selon le protocole SIP, une telle requête d'accès prend la forme d'un message INVITE On notera qu'une telle mesure du nombre de requêtes d'accès au service est un déclencheur particulier du mécanisme de gestion de charge selon l'invention, car le phénomène "Flash Crowds" que l'on cherche à prévenir est précisément lié à une avalanche de requêtes d'accès au service. Toutefois, les informations obtenues peuvent avantageusement être de types varies, parmi lesquels on trouvera, de façon non exhaustive un nombre de sessions simultanées actives; un rythme de traitement des requêtes d'accès au service, un taux d'occupation du CPU de l'équipement de service ou toute autre information pertinente pour estimer la charge d'un équipement de service

Selon un aspect de l'invention, l'étape d'obtention est une étape EI ₂ GET-N d'obtention d'un taux de charge effectif global N de plusieurs équipements du système formant la plateforme de téléphonie PFT a un instant t donne On notera que, de façon connue, les plateformes de téléphonie actuelles disposent d'un système de supervision apte à estimer la charge globale de la plateforme à partir de mesures

d'exploitation fournies par des compteurs MIB SNMP ou encore des sondes RMON

Dans une étape ES ₁ , le taux de charge effectif Ni pour l'équipement de bordure EB, est comparé à un taux de charge Mi autorisé pour cet équipement de bordure

Dans une étape E3 ₂ , le taux de charge global effectif N obtenu est comparé à un taux de charge global maximal autorisé M On notera que les valeurs de taux de charge autorisé sont généralement définies par l'opérateur du service qui précise les limites maximales de charge supportées par la plateforme de téléphonie PFT dans son ensemble et, en particulier, par chacun des équipements de bordure EBi

Le procédé selon l'invention s'appuie sur les principes suivants On considère un ratio n au-delà duquel la plateforme de téléphonie PFT est considérée en surcharge Le taux de charge Mi est le taux de charge autorisé, fixé par configuration, de l'équipement de bordure EBi II représente la charge maximale que cet équipement de bordure est autorisé à accepter afin de ne pas surcharger la plateforme PFT Par défaut, considérant une distribution statistique des appels dans le temps, régi par les lois d'Erlang, les valeurs Mi peuvent tout à fait être configurées de telles sorte que M = g (Mi (l≤i≤m) ) ou g (Mi (l≤i≤m) ) < n * M (1)

dans laquelle g ( ) est une fonction qui relie le taux de charge global maximal autorisé du système en fonction du taux de charge local maximal autorisé de chaque équipement de bordure EBi situé à la périphérie du service.

On considère maintenant le taux de charge effectif Ni généré par un POP d'accès ou équipement de bordure EBi en direction de la plateforme de téléphonie PFT Le principe de l'invention est de faire en sorte que l'inégalité suivante soit toujours vérifiée

N = f (Ni ( l≤i≤m) ) < n * M (2)

dans laquelle f ( ) est une fonction qui relie le taux de charge global du système en fonction du taux de charge local de chaque équipement de bordure EBi situé à la périphérie du service A titre d'exemple, la fonction f ( ) peut s'exprimer comme suit

f ( ) ≈ σ Ni (l ≤ i ≤ξ m) , dans le cas ou un et seulement un équipement de bordure EBi intervient dans l'établissement de l'appel et dans les échanges de flux média , f () = 1/2* σ Ni (l≈ζi≈≤m) , dans le cas ou deux équipements de bordure EBi ₁ EBj interviennent dans l'établissement de l'appel et dans les échanges de flux média f () = 1/p* σ Ni (1 ^ i ^ m) , dans le cas o u un nombre p d'équipements de bordure interviennent dans l'établissement de l'appel et les échanges de flux média

Selon l'invention, une étape E4 de calcul d'un nouveau taux de charge autorisé Ni pour au moins un équipement de bordure EBi est déclenchée, au moins dans les deux cas suivants

1- si le taux de charge effectif global N excède le taux de charge global autorisé M, c'est-à-dire si on est dans la situation d'un afflux important de requêtes au niveau de la plateforme centralisée, qui engendre un état de charge élevé de cette plateforme, ou

2- si le taux de charge effectif Ni de l'équipement de bordure EBi est supérieur à son taux de charge Mi autorisé, alors que le taux de charge effectif global N excède le taux de charge global autorisé M On se trouve alors dans la situation d'un afflux important de requêtes au niveau d'un accès particulier à la plateforme, qui engendre localement une charge élevée de l'équipement de bordure EBi.

Préférentiellement, le procédé de gestion de charge selon l'invention modifie la configuration d'un équipement de bordure EBj, j entier de 1 à 4, de telle sorte que le nouveau taux autorise Mj permette de satisfaire les inégalités précédentes Dans le premier cas, c'est préférentiellement l'équipement de bordure EBj ayant reçu le plus grand nombre de requêtes d'accès au service qui est choisi On notera toutefois que le choix du ou des équipements de bordure concernes par la modification de configuration dépend de la politique de l'operateur et peut-être tout autre On peut

envisager, par exemple, une modification répartie sur plusieurs équipements de bordure

La modification décidée par le procédé selon l'invention, est, par exemple, d'abaisser le taux de charge maximum autorisé M] pour cet équipement EBj de façon à ce que la plateforme de téléphonie soit moins sollicitée par cet équipement de bordure et donc moins chargée

On comprend que l'équipement de bordure EBj destinataire du nouveau taux de charge maximum autorisé Mj selon l'invention n'est pas forcément l'équipement de bordure EBi à partir duquel les informations de taux de charge effectif Ni ont ete obtenues

Dans le deuxième cas, c'est préférentiellement l'équipement de bordure EBi ayant émis l'information représentative de son taux de charge effectif Ni qui est choisi comme destinataire de la modification de configuration II s'agira d'évaluer la possibilité d'augmenter son taux de charge maximal autorisé Mi, de façon à ce qu'il puisse absorber la charge occasionnée par le traitement des requêtes qu'il reçoit tout en satisfaisant les inégalités précédentes

On comprend donc que l'étape E4 du procédé de gestion de charge selon l'invention correle directement la charge d'un équipement de bordure par lequel transite une partie du flux de requêtes entrant dans le système de téléphonie à celle générée dans le système de téléphonie proprement dit

Avantageusement, le seuil de charge maximum autorise s'exprime et se calcule au moins en fonction d'un nombre maximum de requêtes d'accès entrantes autorisé On notera toutefois que d'autres paramètres peuvent servir a son évaluation, tels que le rythme de traitement des requêtes entrantes Par conséquent, abaisser le taux de charge autorise Mi pour un équipement de bordure EBi peut se traduire par exemple, par une diminution du taux d'acceptation de requêtes entrantes et/ou du rythme de traitement des requêtes les moins prioritaires

Sur réception du nouveau taux de charge autorise Mj , l'équipement de bordure EBj met en œuvre le procédé de régulation de charge selon l'invention Un tel procédé comprend une étape de régulation d'un traitement de requêtes de signalisation reçues

par l'équipement de bordure en fonction du nouveau taux de charge M] autorisé Une telle étape consiste à contrôler que le traitement des requêtes en cours n'occasionne pas pour l'équipement une charge N] supérieure au taux de charge autorisé M] .

Il s'agit, par exemple, de contrôler dynamiquement le nombre de sessions maintenues Cette capacité de traitement d'appel est contrôlée soit localement (au travers une interface de configuration) ou commandée (pilotée) par une entité extérieure Le mode de pilotage dépend de l'architecture adoptée (i e centralisée ou autonome)

La mise en œuvre du procédé de gestion de charge d'un système de mise en œuvre d'un service applicatif selon l'invention peut se décliner selon deux modes principaux

Un mode centralisé, selon lequel le procède de gestion de charge est exécuté par un équipement central, par exemple localisé dans la plateforme centralisée de téléphonie PFT, qui reçoit des informations relatives aux taux de charge des équipements de bordure et récupère le taux de charge global de la plateforme, par exemple, auprès de son système de supervision Cet équipement n'intervient pas forcement dans la fourniture du service en question Un avantage de ce mode est de permettre à l'opérateur du service une maîtrise centralisée du comportement du service et un point d'entrée unique à partir d'un équipement de configuration centralise dont la responsabilité est le pilotage des équipements de bordure et de modifier leurs comportements,

Un mode distribue (dit aussi autonome), selon lequel les équipements de bordure échangent entre eux des informations relatives a leurs taux de charge effectifs, déterminent et régulent eux-mêmes l'afflux de trafic qu'ils sont en mesure d'accepter, de telle sorte que l'ensemble des échanges de signalisation et de flux média qu'ils remontent vers la plateforme de service engendre au niveau de la plateforme une charge qui reste inférieure au taux de charge maximal autorisé M Ils mettent donc eux-mêmes en œuvre le procédé de gestion de charge selon l'invention Le mode distribue offre une

flexibilité, « dynamicité » et souplesse dans la gestion du phénomène de surcharge sans pour autant introduire de nouveaux éléments et interfaces

On présente maintenant, en relation avec la figure 3, la mise en œuvre du procédé de gestion de charge selon un mode de réalisation centralise Les étapes E'1 à E'4 sont identiques aux étapes E1 à E4 de la figure 2 et ne seront pas décrites

Dans une étape E'5, le nouveau taux de charge autorisé M] est transmis à l'équipement de bordure EBj concerné Selon l'invention, ledit équipement EBj met à jour son taux et active des règles de régulation de trafic de façon à respecter le nouveau taux de charge M] à ne pas dépasser

On présente maintenant, en relation avec la figure 4, la mise en œuvre du procédé de gestion de charge selon un mode de réalisation distribué Selon ce mode, au moins un équipement de bordure EBk, k entier compris entre 1 et 4, met en œuvre le procédé de gestion de charge selon l'invention II reçoit, en E ¹¹ I ₁ , des informations relatives au taux de charge Ni d'au moins un équipement de bordure EBi du système de téléphonie.

Avantageusement, il reçoit en outre des informations relatives au moins au taux de charge autorisé Mi pour cet équipement

L'équipement de bordure EB _k met en œuvre une étape E"2 ₂ d'estimation du taux de charge global effectif N de la plateforme à partir des taux de charge effectifs des équipements de bordure EB1 a EB4 On considère que le taux de charge global autorise M a été fourni au préalable à l'équipement de bordure EBk Avantageusement, d'autres informations ST-INF stockées en mémoire peuvent aussi être utilisées Cette estimation s'appuie, comme précédemment, sur le principe selon lequel la charge effective globale de la plateforme PFT est une fonction des charges effectives des équipements de bordure Les étapes E"31 , E"32 et E"4 qui suivent sont identiques aux étapes E'31 , E'32 et E'4 de la figure 3 et ne seront pas décrites

Le mode de réalisation distribué se divise en deux variantes

- selon une première variante, tous les équipements de bordure EB1 à EB4 mettent en œuvre le procédé selon l'invention. A l'issue de l'étape E"4, ils ont donc tous dans leurs tables les mêmes valeurs mises à jour des taux de charge autorisés M] pour chacun des équipements EBj. Ils n'ont donc a priori pas besoin de s'échanger mutuellement les valeurs M] calculées. Toutefois, pour des raisons de sécurité et de prévention, il peut être avantageux que les équipements de bordure s'échangent les nouveaux taux de charge autorisés M] .

- selon une deuxième variante, une hiérarchie est mise en place au sein de la communauté des équipements de bordure EBi. Un équipement de bordure est élu comme maître pour mettre en œuvre le procédé de gestion de charge selon l'invention Une telle élection peut se faire administrativement sur décision de l'opérateur de la plateforme, ou dynamiquement. Une élection dynamique peut, par exemple, consister en ce qu'un équipement de bordure qui a envoyé une information renseignant Ni et/ou Mi le concernant à ses pairs et qui n'a reçu aucune réponse en retour à l'issue d'un délai prédéterminé s'auto proclame maître de la communauté d'équipements de bordure Selon une variante, un équipement de bordure envoie, lors de sa mise en service, une requête spécifique (Who_l S_Master ( ) ). Cette requête est reçue par l'ensemble des équipements de bordure. Si un maître a déjà été élu/désigné, alors ce dernier répond à l'émetteur de la requête. L'émetteur indique alors dans une table dédié l'identité du maître. Seules les décisions reçues de la part de cet équipement de bordure seront prises en compte. Une phase de négociation d'une association de sécurité peut être envisagée entre l'équipement de bordure maitre et l'équipement de bordure émetteur. Si, aucun équipement de bordure maître n'est présent dans le système, alors l'émetteur s'autoproclame maître et envoie un message à la communauté les notifiant de cette élection. Les autres équipements de bordure mettent alors leurs tables à jour avec l'identité du nouvel équipement de bordure maître Tout équipement de bordure maître peut renoncer à cette fonction si par exemple il atteint une charge critique, si la procédure de prise de décision dégrade ses performances ou pour des opérations de maintenance planifiées Pour ce faire, il envoie un message

dénommé TEAR_MASTER ( ) au groupe multicast G Une fois reçu par les autres équipements de bordure, une procédure de remplacement de cet équipement de bordure maître est alors lancée Cette élection se fait à base d'informations telles que la capacité de traitement d'un équipement de bordure, la charge courante, l'élément ayant I adresse IP la plus longue, etc A base de ces informations tous les équipements de bordure procèdent à la mise a jour de leurs tables en indiquant l'identité de la nouvelle entité agissant comme équipement de bordure maître Ce dernier, envoie un message de confirmation et déclenche une phase de négociation d'associations de sécurité avec ses pairs L'équipement de bordure maître met en œuvre le procédé selon l'invention et dans une étape E"5, il envoie aux équipements de bordure concernes les nouveaux taux de charge autorisés M] qu'il a calculés Ces derniers mettent en œuvre les nouvelles configurations reçues

Le procède de gestion de charge selon l'invention est donc mis en œuvre par au moins un équipement du réseau de télécommunications CN

Selon un premier mode de réalisation, dit mode centralisé, cet équipement est un équipement de configuration central, constitutif ou non de la plateforme centralisée PTF, tel qu'un serveur Selon un deuxième mode de réalisation, dit mode distribué, le procédé de gestion de charge est mise en œuvre par au moins un équipement de bordure EBi Dans le cas du mode distribue hiérarchisé, le procède de calcul et de prise de décision est mis en œuvre par un seul équipement de bordure maître EBi Dans le cas du mode distribue non hiérarchise, il est mis en œuvre par tous les équipements de bordure EBi

Dans tous les cas, un équipement mettant en œuvre le procédé selon l'invention comporte en relation avec la figure 5, les éléments matériels que l'on retrouve classiquement dans un ordinateur conventionnel, a savoir un processeur 11 , une mémoire vive de type RAM 12, une mémoire morte de type ROM 13, des moyens 14 d'émission/reception de messages dans le reseau de télécommunications CN

Conformément à l'invention, les moyens 14 d'émission/réception de messages sont multiples et gère d'autant de canaux de communications que d'équipements de bordure à piloter

Conformément à l'invention, l'équipement 10 est connecté à une base de données 15, qui peut être interne ou externe, comprenant au moins les informations relatives à l'état de charge des équipements qu'il a obtenues et avantageusement les seuils de charge maximum autorisée qu'il leur a attribués.

La mémoire morte 13 constitue un support d'enregistrement conforme à l'invention. Ce support mémorise un programme d'ordinateur conforme à l'invention, ce programme comportant des instructions pour l'exécution des étapes du procédé de gestion de charge décrit précédemment.

En référence à la figure 6, on présente maintenant, de façon schématique, un premier exemple de mise en œuvre du mode de réalisation centralisé de l'invention. Selon cet exemple, le procédé de gestion de charge est mis en œuvre par un équipement de configuration EC de la plateforme PTF de téléphonie du réseau cœur CN. Cet équipement EC échange des informations avec les équipements de bordure EB1 à EB4, afin de modifier, configurer et activer les valeurs de seuils de charge autorisés pour une période donnée au niveau des réseaux d'accès AN1 à AN4, de sorte que le cœur du service ne se retrouve pas en situation de surcharge suite à un phénomène de type "Flash Crowds".

Ce mode de réalisation repose sur la faculté, au niveau de la plateforme cœur, de disposer du taux de charge global N du système de téléphonie à l'instant t, et communiquer avec les équipements de bordure, afin de requérir de leur part un ajustement de leur capacité d'acceptation d'appels, de telle sorte que la résultante de l'ensemble des sollicitations des équipements de bordure vers la plateforme n'entraîne pas sa saturation. Ceci nécessite la mise en place de canaux de communication entre l'équipement EC et les équipements de bordure EB1 à EB4, afin de permettre de tels échanges.

L'équipement de configuration EC obtient par au moins l'un de ces canaux, une information Ni relative à un équipement de bordure EBi. Il exploite cette information en mettant en œuvre le procédé selon l'invention. Le cas échéant, il utilise les canaux de communication pour informer un des équipements de bordure EBj d'un nouveau taux de charge maximum autorisé M] à prendre en considération.

On présente maintenant en référence à la figure 7, un deuxième exemple de mode de réalisation centralisé, selon lequel le procédé de gestion de charge est mis en œuvre par un équipement de configuration ES externe au système de téléphonie. Un tel équipement est, par exemple un équipement de supervision ES. Selon l'invention, des messages d'information INFi et INFP comprenant respectivement les taux de charge Ni et N sont envoyés par les équipements de bordure et la plateforme cœur à l'équipement ES L'envoi de ce type de messages peut être périodique ou conditionné par l'occurrence d'un événement (e.g. passage d'un seuil donné). De tels messages renseignent l'équipement ES sur l'état de charge actuelle de l'équipement en question. Les informations renseignées dans ces messages ainsi que les paramètres de configuration configurés par l'opérateur du service, permettent à l'équipement ES de prendre les décisions adéquates et d'acheminer en conséquence les politiques de traitement d'appel spécifique à chaque équipement de bordure EB1 à EB4, sous forme de nouveaux taux de charge autorisés Mj, j entier compris entre 1 et 4.

Un avantage est de profiter d'infrastructures disponibles et de ne pas surcharger davantage les équipements de service et d'accès au service du système de téléphonie.

Selon une variante, l'équipement ES s'appuie sur des informations de mesure relatives à la charge des équipements, en particulier des équipements de bordure, qui sont collectées, de façon connue, par des sondes de type RMON ou des équipements MIB SNMP au profit d'un système de supervision du réseau de télécommunication mis en place par l'opérateur Dans ce cas, l'équipement ES peut soit interroger directement les sondes qui alimentent ce système (par exemple à l'aide de polhng SNMP) au travers de canaux de communications déjà existants, soit ré-exploiter les informations

déjà collectées par le système de supervision. En outre un canal de communication unilatéral est suffisant entre l'équipement ES et la plateforme de services PTF et chacun des équipements de bordure EB1 à EB4 pour ajuster le nouveau seuil de charge Mi autorisé

De façon avantageuse, les messages échangés entre l'équipement ES ou EC des figures 6 et 7, mettant en œuvre le procédé selon l'invention et les équipements de bordure EB1 a EB4 s'appuient sur le protocole DHCP

En effet, DHCP est majoritairement déployé par les opérateurs et notamment utilise pour communiquer aux équipements de service leur configuration au démarrage Ce protocole est aussi utilisé régulièrement pour la mise à jour des informations de configuration

De façon avantageuse, la mise en œuvre de l'invention utilise une nouvelle option DHCP pour communiquer des mises à jour des valeurs de seuils de charge autorisés à destination des équipements de bordure par l'équipement de supervision De façon préférentielle, cette nouvelle option DHCP, appelée CALL_FLOW_ACCE PTANCE ( CFA) , sera exploitée pendant le démarrage des équipements de bordure Elle est définie comme suit Le format de l'option CALL_FLOW_ACCE PTANCE est le suivant

CALL_FLOW_ACCEPTANCE

Code ce champ renseigne le code de I option La valeur de ce champ doit être attribuée (TBA pour « To Be Assigned » en anglais) par IANA (Internet Assigned Numbers Aυthonty) La longueur de ce champ est de 1 octet Len Ce champ renseigne la longueur de la valeur de l'option Dans le cas de l'option CALL_FLOW_ACCEPTANCE, la valeur de ce champ est variable

Va/ . Ce champ renseigne la valeur de la charge autorisée Mi au niveau d'un équipement de bordure EBi Cette valeur est exprimée en « taux d'appels par seconde » ou CAPS (« CaII Attempts Per Second » en anglais).

Il est bien sûr entendu que le protocole DHCP, n'est cité ici qu'à titre d'exemple. D'autres moyens sont envisageables, comme le recours aux méthodes de configuration de service telles que celle reposant sur les principes de NETCONF

(NETwork CONFiguration) ou encore sur le protocole COPS (Common Open Policy

Service).

En référence à la figure 8, on présente un exemple de mise en oeuvre d'un mode de réalisation distribué et hiérarchisé de l'invention. Selon cet exemple, le procédé de gestion de charge est mis en œuvre au niveau d'un équipement de bordure

EB4, soit de façon nominale, soit pour faire face à une panne des équipements EC ou

ES du réseau de télécommunications décrits précédemment. Il s'agit donc d'un mode hiérarchique, selon lequel un équipement de bordure EB1 joue un rôle particulier par rapport aux autres, celui de centraliser les décisions de gestion de charge, d'implémenter la logique de prise de décision et de notifier les autres équipements de bordure de nouveaux taux de charge autorisés.

Afin de réaliser ce mode distribué, l'équipement de bordure EB1 doit, pour mettre en œuvre le procédé selon l'invention, établir des canaux de communication au moins unidirectionnels avec chacun des autres équipements de bordure EB2 à EB4 de façon à former une communauté d'équipements de bordure au sein de laquelle les informations relatives à la charge peuvent être échangées. Deux modes de communication, le mode point à point ou le mode point à multipomts, peuvent être envisagés pour l'échange des informations relatives aux taux de charge des équipements de bordure :

Selon un premier aspect de l'invention, tous les messages sont envoyés en unicast au seul destinataire, que ce soit l'équipement de configuration pour le taux de charge effectif Ni ou l'équipement de bordure EBj pour le nouveau taux autorisé Mj. Un avantage est de limiter le nombre de messages échangés et donc d'optimiser les ressources du réseau

Selon un deuxième aspect de l'invention, tous les messages de notification (Ni) sont émis en unicast et les messages de décision (Mj) en multicast Un avantage est d'informer simultanément toute la communauté d'équipements de bordure des décisions prises Ainsi, en cas de panne de l'équipement maître, l'équipement qui le remplace dispose immédiatement de toutes les informations de configuration à jour,

Selon un troisième aspect de l'invention tous les messages sont émis en multicast L'avantage de cette deuxième variante est l'uniformisation des informations stockées par l'ensemble des SBC, que ce soit les notifications ou les décisions

Une autre technique consisterait à s'appuyer sur des mécanismes de type "peer to peer" en s'appuyant sur l'utilisation de DHT (Distπbuted Hash Table)

On présente enfin, en relation avec la figure 9, un exemple de mise en œuvre d'un mode de réalisation distribue et non hiérarchisé de l'invention Selon ce mode de réalisation, chacun des équipements de bordure EB1 a EB4 met en oeuvre le procède selon l'invention L'ensemble des équipements de bordure se voit communiquer les valeurs du taux de charge global autorise M pour le système de téléphonie et celles Mi de chacun des équipements de bordure. Ces valeurs peuvent être récupérées de diverses manières configurées "en dur" dans les équipements, communiquées par

DHCP lors de la mise en service, etc De même, ces valeurs peuvent être mises à jour par l'opérateur par la méthode de son choix configuration manuelle, par DHCP,

NETCONF, COPS, etc

Selon ce mode de réalisation de l'invention, les différents équipements de bordure s'échangent dynamiquement, en mode unicast ou multicast, les valeurs de taux de charge effectif Ni et autorise Mi qui les caractérisent, de telle sorte que chacun d'entre eux ait une vision à jour de l'ensemble des informations de charge de tous les équipements de bordure de sa communauté Ces informations permettent alors a chacun des équipements de bordure d'estimer le taux de charge effectif de la

plateforme de service cœur, en fonction d'une formule de calcul exploitant les taux de charge effectifs des équipements de bordure et configurée par l'opérateur du service.

De cette manière, le mode autonome permet de faire face aux deux situations critiques identifiées ci-haut de la manière suivante ^• 1- Suite à un afflux important d'appels, la charge totale effective au niveau de la plateforme cœur telle que calculée par les équipements de bordure sur la base des Ni augmente de manière significative, s'approchant du seuil de charge global maximum autorisée M défini par l'opérateur. Afin de prévenir un dépassement de ce seuil, certains équipements de bordure vont diminuer la valeur Mi représentant la charge maximale que ces équipements de bordure sont autorisés à transmettre vers la plateforme cœur. Comme évoqué précédemment, le choix des équipements de bordure en question peut se faire de différentes façons, mais on peut raisonnablement envisager que les équipements générant le plus de charge s'auto-limitent, ou bien encore tabler sur une diminution des Mi distribuée sur l'ensemble des équipements de bordure. Typiquement, les valeurs Mi pourront être diminuées de telle sorte que les Ni effectifs soient limités à des niveaux tels que l'inégalité (1 ) soit vérifiée. 2- Suite à un afflux important d'appels au niveau d'un équipement de bordure EBi, ce dernier se retrouve confronté à la situation où Ni atteint Mi. Il peut alors consulter les valeurs Ni /Mi des autres équipements de bordure afin d'évaluer leur taux de charge effectif Ni. Dans l'hypothèse ou un (ou plusieurs) autre(s) équipement de bordure a un taux de charge faible, l'équipement de bordure proche de la surcharge peut solliciter ce(s) dernιer(s) afin qu'il diminue(nt) temporairement son taux de charge Mi et que lui- même puisse relever sa propre valeur Mi, dans la mesure où la charge totale constatée au niveau de la plateforme cœur est inférieure à n*M. Lorsque l'afflux d'appel sera absorbé, l'équipement de bordure pourra alors en informer les autres équipements de bordure, qui réajusteront à la hausse leurs valeurs Mi tandis que l'équipement de bordure concerné repositionnera sa valeur Mi à un niveau plus bas Cette opération revient donc à ajuster de manière temporaire les valeurs des Mi afin de limiter les phénomènes ponctuels de surcharge au niveau des équipements de

bordure, tout en s'assurant que la plateforme cœur ne se retrouve jamais elle-même surchargée

Les nouvelles valeurs de taux autorisées peuvent être diffusées à tous les équipements de bordure de la communauté en mode multicast ou émises seulement à leurs destinataires en mode unicast

Le mode autonome, en s'appuyant sur un canal de communication entre les équipements de bordure, est donc à même de gérer les deux situations de crise identifiées tout comme le permettait le mode centralisé