Brevet FR2928801A1 — publié le 20090918

Procédé de gestion de charge d'un équipement d'un système de mise en oeuvre 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 oeuvre 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 oeuvre un service applicatif dans un réseau de 10 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 15 d'une multitude de services et applications. C'est le réseau fédérateur adopté par les opérateurs pour mutualiser 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 20 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 à la téléphonie traditionnelle qui s'appuie sur la commutation de circuits. L'avantage avancé pour le passage à 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 25 l'informatique et l'Internet en particulier. Pour accompagner le déploiement de services de VoIP, l'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), 30 RTCP (Real-time Transport Control Protocol), MGCP (Multimedia Gateway Contra/ 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 Vo1P 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 oeuvre 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 1.5 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 20 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 ]. 25 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 oeuvre des mécanismes de partage de charge (ou load balancing en anglais) entre les 30 noeuds 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 destiné à 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 à joindre pour recevoir une somme d'argent. Ce genre de situation peut déboucher sur un grand nombre d'appels passés vers le numéro en question sur une période relativement courte, entrainant 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 congestionné 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 sollicité n'est pas en mesure de traiter la requête suite à une surcharge temporaire ou à 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 10 15 20 25 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 regroupés sous un même nom de domaine, et que l'un d'eux est surchargé, 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 surchargé. 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-Alter" permet à un équipement surchargé d'indiquer au demandeur de n'émettre la requête qu'à l'expiration d'un � timer � donné. 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 utilisé. De ce fait, d'autres cas d'usage ont été spécifiés voire implémentés. Ceci complique l'interprétation précise de ce code à des fins propres de détection de surcharge. 30 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 oeuvre d'un service applicatif hébergé par un réseau 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 oeuvre 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 réseaux d'accès au service. Selon l'invention, le procédé de gestion de charge est caractérisé 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 autorisé 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 oeuvre 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 autorisé. Un critère fondamental adopté 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 mesurés à la périphérie ou au coeur du système. La mise en oeuvre de l'invention se fait en imposant des seuils de charge, ou taux de charge autorisés, à 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 coeur de réseau. 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éré peut être déduit 10 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. 15 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éré, 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 20 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é 25 supérieur au taux autorisé actuel et inférieur à 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 30 é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 autorisé 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 autorisé 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 oeuvre 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 oeuvre le procédé de gestion de charge et de profiter de mesures de charge qui sont généralement disponibles dans le coeur 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 oeuvre le procédé de gestion de charge selon l'invention est capable d'estimer la charge globale du système 30 à 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 oeuvre le procédé selon l'invention sans dépendre d'un autre équipement du coeur du système. Selon un autre aspect de l'invention, le procédé 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 autorisé actuel de l'équipement de bordure est donc transmis par l'équipement de bordure lui-même à l'équipement qui met en oeuvre 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 oeuvre par au moins deux équipements du système applicatif, afin que l'un puisse prendre connaissance d'un taux de charge autorisé fixé par l'autre. Ceci est par exemple le cas, lorsque le procédé selon l'invention est mis en oeuvre 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 oeuvre 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 oeuvre 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 à la mise en oeuvre des étapes d'un procédé 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 disc) ou un disque dur. l0 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 15 lequel le programme est incorporé, le circuit étant adapté 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 oeuvre par un équipement de configuration du système de mise en oeuvre du service applicatif. 20 Par conséquent, l'invention concerne un équipement de configuration d'un système de mise en oeuvre 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érisé en ce que 25 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 autorisé 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 30 équipement étant fonction dudit taux de charge autorisé 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 coeur du système. L'invention concerne enfin 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 à 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 fiqures 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre d'un 5 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 oeuvre 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. 10 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 oeuvre d'un service applicatif, en régulant 15 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 oeuvre du service applicatif et un réseau 20 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 oeuvre du service se fait par la collaboration d'une pluralité de 25 plateformes de téléphonie. Le déploiement d'une pluralité d'équipements de bordure est adopté 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 Presence ou POP) de services, la plupart du temps distribués, qui accèdent eux mêmes à une 30 plateforme de service centralisée, dite aussi coeur 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 à 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 Presence, Point de Présence) d'accès donnés et des équipements de service du réseau coeur 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 Ti à T4 sont répartis (ou attachés) entre différents POP (Point Of Presence) 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 coeur 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 codecs utilisés 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-Asterisk Exchange). Le procédé de gestion de charge d'un système de mise en oeuvre 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 El 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. Il 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 E1, 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 variés, 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 25 information pertinente pour estimer la charge d'un équipement de service. Selon un aspect de l'invention, l'étape d'obtention est une étape E12 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 à un instant t donné. On notera que, de façon connue, les plateformes de téléphonie actuelles disposent d'un système de 30 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 E31, 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 E32, 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. Il 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 (1SiSm)) ou g (Mi (1SiSm)) S n * M (1) dans laquelle g ( ) est une fonction qui relie le taux de charge global maximal autorisé 20 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 25 toujours vérifiée : N = f (Ni (1SiSm)) S 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 30 périphérie du service. A titre d'exemple, la fonction f O peut s'exprimer comme suit : - f () = E Ni (1 i 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 N i 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 autorisé Nj 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 concernés par la modification de configuration dépend de la politique de l'opérateur 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é Mj 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 été 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 CIi qui est choisi comme destinataire de la modification de configuration. Il 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 corrèle 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 autorisé 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 à son évaluation, tels que le rythme de traitement des requêtes entrantes. Par conséquent, abaisser le taux de charge autorisé 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 autorisé Mj, l'équipement de bordure EBj met en oeuvre 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 CM? j autorisé. Une telle étape consiste à contrôler que le traitement des requêtes en cours n'occasionne pas pour l'équipement une charge N j supérieure au taux de charge autorisé Mj. II 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 oeuvre du procédé de gestion de charge d'un système de mise en oeuvre d'un service applicatif selon l'invention peut se décliner selon deux modes principaux: - Un mode centralisé, selon lequel le procédé 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 forcément dans la fourniture du service en question. Un avantage de ce mode est de permettre à l'opérateur du service une maitrise centralisée du comportement du service et un point d'entrée unique à partir d'un équipement de configuration centralisé dont la responsabilité est le pilotage des équipements de bordure et de modifier leurs comportements; Un mode distribué (dit aussi autonome), selon lequel les équipements de bordure échangent entre eux des informations relatives à 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 oeuvre le procédé de gestion de charge selon l'invention. Le mode distribué 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 oeuvre du procédé de gestion de charge selon un mode de réalisation centralisé. Les étapes E'1 à E'4 sont identiques aux étapes El à E4 de la figure 2 et ne seront pas décrites. Dans une étape E'5, le nouveau taux de charge autorisé Mj 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 oeuvre 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 oeuvre le procédé de gestion de charge selon l'invention. II reçoit, en E"11, 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 20 de charge autorisé Mi pour cet équipement. L'équipement de bordure EBk met en oeuvre une étape E"22 d'estimation du taux de charge global effectif N de la plateforme à partir des taux de charge effectifs des équipements de bordure EB1 à EB4. On considère que le taux de charge global autorisé M a été fourni au préalable à l'équipement de bordure EBk. 25 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 30 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 oeuvre 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 Mj pour chacun des équipements EBj. Ils n'ont donc a priori pas besoin de s'échanger mutuellement les valeurs Mj 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 Mj . - 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 oeuvre 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 N i 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 IS Master O ). 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é TSAR 1,.1ASTE? 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 l'adresse IP la plus longue, etc. A base de ces informations tous les équipements de bordure procèdent à la mise à 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 oeuvre le procédé selon l'invention et dans une étape E"5, il envoie aux équipements de bordure concernés les nouveaux taux de charge autorisés Mj qu'il a calculés. Ces derniers mettent en oeuvre les nouvelles configurations reçues. Le procédé de gestion de charge selon l'invention est donc mis en oeuvre 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 oeuvre par au moins un équipement de bordure EBi. Dans le cas du mode distribué hiérarchisé, le procédé de calcul et de prise de décision est mis en oeuvre par un seul équipement de bordure maître EBi. Dans le cas du mode distribué non hiérarchisé, il est mis en oeuvre par tous les équipements de bordure EBi. Dans tous les cas, un équipement mettant en oeuvre 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, à 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/réception de messages dans le réseau 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 oeuvre du mode de réalisation centralisé de l'invention. Selon cet exemple, le procédé de gestion de charge est mis en oeuvre par un équipement de configuration EC de la plateforme PTF de téléphonie du réseau coeur 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 coeur 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 coeur, 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 N i relative à un équipement de bordure EBi. Il exploite cette information en mettant en oeuvre 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é fsj à 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 oeuvre 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 coeur à 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 polling 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 oeuvre le procédé selon l'invention et les équipements de bordure EB1 à EB4 s'appuient sur le protocole DHCP. En effet, DHCP est majoritairement déployé par les opérateurs et notamment utilisé 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 oeuvre 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 CALE FLOW ACCEPTAtCE (CFA) , sera exploitée pendant le démarrage des équipements de bordure. Elle est définie comme suit : Le format de l'option CALL FLOG1 ACCEPTANCE est le suivant : Len Val Variable Mi CALL_FLOW_ACCEPTANCE Code : ce champ renseigne le code de l'option. La valeur de ce champ doit être attribuée (TBA pour � To Be Assigned � en anglais) par IANA (Internet Assigned Numbers Authority). La longueur de ce champ est de 1 octet. 25 -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. Code TBA20 - Val: 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 (� Cal/ Attempts Per Second � en anglais). II 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 oeuvre 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. II 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 oeuvre 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 à multipoints, 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 (Distributed Hash Table). On présente enfin, en relation avec la figure 9, un exemple de mise en oeuvre d'un mode de réalisation distribué et non hiérarchisé de l'invention. Selon ce mode de réalisation, chacun des équipements de bordure EB1 à EB4 met en oeuvre le procédé selon l'invention. L'ensemble des équipements de bordure se voit communiquer les valeurs du taux de charge global autorisé 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 autorisé 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 à chacun des équipements de bordure d'estimer le taux de charge effectif de la plateforme de service coeur, 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 coeur telle que calculée par les équipements de bordure sur la base des Mi 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 coeur. 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. II 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) dernier(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 coeur 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 coeur 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 à 5 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é. 10 REVENDICATIONS 1. Procédé de gestion de charge d'un système de mise en oeuvre 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 du système et des réseaux d'accès au service, caractérisé en ce que ledit procédé 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 autorisé pour ledit au moins un équipement de bordure. 2. Procédé de gestion de charge selon la revendication 1, caractérisé en ce que le taux de charge autorisé pour un équipement de bordure est un taux d'acceptation de requêtes de signalisation reçues. 3. Procédé de gestion de charge selon la revendication 1, caractérisé en ce que le taux de charge effectif obtenu concerne une pluralité d'équipements formant une plateforme centralisée. 4. Procédé de gestion de charge selon la revendication 1, caractérisé en ce que le taux de charge effectif obtenu concerne un équipement de bordure et en ce que 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 à une capacité maximale dudit équipement de bordure. 5. Procédé de gestion de charge selon la revendication 4, caractérisé en ce qu'il 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. 6. Procédé de gestion de charge selon la revendication 1, caractérisé en ce qu'ilcomprend une étape d'envoi du nouveau taux autorisé audit au moins un équipement de bordure concerné. 7. Procédé de gestion de charge selon la revendication 3, caractérisé en ce que 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. 8. Procédé de gestion de charge selon la revendication 5, caractérisé en ce que l'étape d'obtention du taux de charge effectif de la plateforme comprend une étape d'estimation du taux de charge effectif de la plateforme à partir du taux de charge effectif dudit au moins un équipement de bordure. 9. Procédé de gestion de charge selon la revendication 4, caractérisé en ce qu'il comprend en outre une étape d'obtention d'un taux de charge autorisé dudit équipement de bordure. 10. 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, ledit procédé comprenant 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é. 11. Procédé de régulation de charge selon la revendication 10, caractérisé en ce que lesdits moyens d'envoi sont mis en oeuvre lorsque ledit taux de charge effectif atteint le taux de charge autorisé. 12. Procédé de régulation de charge selon la revendication 10, caractérisé en ce que lesdits moyens d'envoi sont mis en oeuvre selon un rythme d'envoi prédéterminé. 13. Equipement de configuration d'un système de mise en oeuvre d'un service applicatif dans un réseau de télécommunications, ledit système comprenant unepluralité 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érisé 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 autorisé 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 autorisé dudit au moins un équipement de bordure. 14. Equipement de bordure d'un système de mise en oeuvre 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 à échanger des messages d'établissement de sessions applicatives avec 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 20 bordure en fonction du nouveau taux de charge autorisé, 15. Equipement de bordure selon la revendication 14, caractérisé en ce qu'il est un équipement de configuration comprenant les moyens suivants : - obtention d'un taux de charge effectif d'au moins un équipement du système de téléphonie IP; 25 - 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 autorisé pour ledit au moins un équipement de bordure. 30 16. Système de mise en oeuvre d'un service applicatif dans un réseau detélécommunications IP, 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érisé en ce qu'il comprend : au moins un équipement de configuration comprenant 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 autorisé 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 autorisé pour ledit au moins un équipement de bordure; 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é, 17. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de gestion de charge selon la revendication 1. .18. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de régulation de charge selon la revendication 10.