FR3127663A1

FR3127663A1 - Procédé de contrôle d’un accès à un service applicatif, procédé de traitement d’un message de contrôle d’un accès audit service, dispositifs, système et programmes d’ordinateur correspondants.

Info

Publication number: FR3127663A1
Application number: FR2110174A
Authority: FR
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2021-09-27
Filing date: 2021-09-27
Publication date: 2023-03-31
Also published as: CN118044170A; EP4409864A1; US20240406175A1; WO2023047068A1

Abstract

L’invention concerne un procédé de contrôle d’un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit procédé comprenant:- l’obtention (50) d’informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif;- la détection (51), à partir des informations obtenues, d’une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d’exécution du service; et- la transmission (53) d’au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client. FIGURE 5

Description

Procédé de contrôle d’un accès à un service applicatif, procédé de traitement d’un message de contrôle d’un accès audit service, dispositifs, système et programmes d’ordinateur correspondants.

1. Domaine de l'invention

L'invention se situe dans le domaine des télécommunications, et notamment dans celui de la téléphonie sur IP.

En particulier, l’invention concerne le contrôle de l’accès par des équipements clients à un service applicatif mis en œuvre dans un réseau de télécommunications.

Elle s’applique notamment mais non exclusivement à un service de voix sur IP.

2. Art antérieur et ses inconvénients

La Téléphonie sur IP, souvent désignée par le sigle VoIP (pour « Voice over IP », en anglais), a pris ces dernières années une place prépondérante au point que tous les fournisseurs de services proposent de telles offres à leurs clients. Ces offres de service reposent sur le protocole IP (pour « Internet Protocol », en anglais) et donc la commutation de paquets de données. Elles diffèrent donc dans leur conception des services de téléphonie traditionnelle qui eux reposent sur le principe de la commutation de circuits.

Néanmoins, la Téléphonie sur IP se doit de satisfaire les besoins des clients, notamment du point de vue de la qualité et de la disponibilité du service qui doivent être au moins équivalentes à celles fournies par les offres de téléphonie traditionnelle et reposant sur le réseau RTC (Réseau Téléphonique Commuté). En particulier, la qualité de service, la robustesse, la haute disponibilité et la résistance aux pannes sont des facteurs déterminants pour les utilisateurs de services téléphoniques, lesquels sont par nature des services d'échange de flux en temps réel. Les opérateurs de télécommunications, qu’on appellera aussi fournisseurs de services, doivent particulièrement éviter les phénomènes de surcharge des éléments composant le service et anticiper les anomalies qui peuvent perturber le service tel que perçu par les clients.

On désigne ici par surcharge l'incapacité du service, ou de certains éléments de ce service, à traiter une demande d’établissement d’une session applicative, par exemple d’un appel audio, vidéo ou de messagerie instantanée IM (ou « Instant Messaging », en anglais), souvent à cause d'une insuffisance de ressources pour traiter ladite demande.

La gestion des surcharges est d'autant plus délicate que le phénomène a tendance à s'entretenir lui-même. En effet, le problème de surcharge est de nature à progressivement affecter les éléments du service impliqués dans la procédure d’établissement d’appels, et qui tentent toujours d'écouler le trafic : ces éléments se trouvent donc à leur tour affectés par une surcharge de trafic.

Lorsqu’un élément de service est dans un état de surcharge, une partie de ses ressources est alors utilisée pour envoyer des messages d'erreur, d'alerte, etc., ce qui a pour effet de réduire d'autant plus les ressources disponibles pour résoudre le problème de surcharge. Dans le cas d’un service de Téléphonie sur IP, un facteur dégradant supplémentaire tient à la réémission des requêtes qui est souvent mise en œuvre, car elle est destinée à pallier d’éventuelles erreurs du transport IP. Par exemple, le document RFC 3261 définissant le protocole de signalisation SIP (pour « Session Initiation Protocol », en anglais) utilisé dans la procédure d’établissement d’appels, décrit une procédure de retransmission pour les messages de type INVITE et les messages non-INVITE. A titre d’exemple, pour les messages de type INVITE, un temporisateur (ou « timer », en anglais) de retransmission T1 est défini. La procédure est reproduite à chaque intervalle correspondant à un double de T1. Au bout de 7 tentatives, l’équipement client SIP cesse d’exécuter la procédure de retransmission.

Des règles d'ingénierie permettent aux opérateurs de télécommunications d'éviter ce genre de situation de crise dans des conditions normales de fonctionnement, en dimensionnant de manière adéquate leur service, ou en mettant par exemple en œuvre des mécanismes de partage de charge (ou «load balancing »en anglais) entre les éléments de service constituant le service. Cependant, ces mécanismes s'avèrent la plupart du temps insuffisants pour traiter de nombreuses sessions (par ex., appels) liées à des évènements exceptionnels (tels que, par exemple, l’échange de vœux par SMS à l’occasion de la nouvelle année, une catastrophe naturelle, une émission télévisée reposant sur le vote des téléspectateurs, une coupure d’électricité, une attaque terroriste, etc.) ou bien encore suite à une panne (affectant les équipements clients ou les éléments qui constituent la plateforme de service). Ainsi, c'est surtout dans la gestion de pics de charge (ou «burst »,en anglais) que les services conversationnels actuels connaissent des faiblesses. Typiquement, il arrive que les services conversationnels sur IP connaissent de sérieuses défaillances, qui sont amplifiées par la surcharge générée au moment du rétablissement du service et qui retardent ainsi un rétablissement du service. De telles circonstances rendent souvent la reprise du service ingérable au point parfois de provoquer des situations de crise que ne maîtrise pas l’opérateur de télécommunications. A cet égard, la survenue d’une telle crise peut ne pas être prise en compte lors du dimensionnement du service et du réseau sous-jacent.

Un des phénomènes de surcharge les moins faciles à appréhender est celui du phénomène de « pics de charge soudains » (ou "Flash Crowds", en anglais). Il se produit notamment lorsque des utilisateurs en nombre trop important tentent simultanément d'établir un appel ou de se connecter à un site Internet, les éléments du service n'ayant pas été dimensionnés pour absorber simultanément cet afflux de trafic (en anglais, «burst »). Par exemple, le dimensionnement des réseaux de téléphonie repose notamment sur une distribution statistique des appels, régie par les lois d'Erlang en particulier. Or ce type de dimensionnement ne permet pas de déployer un service pouvant faire face à des surcharges occasionnelles de trafic. Dans le cas d'un phénomène de type «Flash Crowds», l'origine d'un goulot d'étranglement au niveau d’une plateforme de service peut être liée à au moins deux situations particulières :
(1) un afflux important de sessions vers une destination particulière (par ex. un numéro particulier comme un numéro d’urgence ou une zone géographique particulière) ou
(2) un afflux important provenant d'une région donnée (en termes de raccordement au service) ou encore une combinatoire des deux situations, dans le contexte de catastrophes naturelles, par exemple.

Ce genre de situation peut générer un grand nombre de sessions passées vers le numéro en question sur une période relativement courte, ce qui provoque une congestion qui dégrade la qualité du service rendu telle que perçue par les utilisateurs.

Un autre exemple bien connu est la saturation quasi systématique des réseaux de téléphonie au moment des fêtes de fin d'année, notamment lors du réveillon du Nouvel An. Là encore, le service de l'opérateur est souvent dimensionné pour pouvoir gérer un nombre important d’appels clients dans des conditions de fonctionnement nominal, c’est-à-dire telles que prévues dans un cahier des charges ou dans un contrat spécifiant des conditions générales d’utilisation (CGU) du service, établi avec les clients. En revanche, lorsque surviennent des pics de charge, le système qui met en œuvre le service est généralement incapable de faire face à la surcharge d’appels, ce qui peut conduire à une forte dégradation du service, voire à son indisponibilité. Un tel afflux de demandes d’établissement d’appels est également de nature à retarder le retour à une situation normale à cause de la persistance dans le temps de cet afflux de trafic.

Les diverses défaillances qui ont affecté les offres de Téléphonie sur IP ces dernières années ont démontré que bien souvent le système qui met en œuvre le service rencontre de grandes difficultés à absorber une surcharge exceptionnelle.

Les ingénieries de services de téléphonie sur IP reposent essentiellement sur un dimensionnement adéquat (incluant un surdimensionnement) pour répondre aux demandes d’accès au service par les clients ayant souscrit au service. Elles s’appuient aussi sur des mécanismes de partage de charge pour limiter le risque de surcharge. Cependant, l'expérience a prouvé que ces choix d’ingénierie, s’ils sont adaptés dans le cadre d'un fonctionnement opérationnel nominal, le sont beaucoup moins pour répondre à des pics de charge soudains et provoqués par des événements exceptionnels ou un comportement non-prévu d’un élément de service (par ex. défaillance logicielle partielle qui induit une perte de session aléatoire).

En relation avec la , une pratique simple et mise en œuvre aujourd’hui consiste à informer les clients de la présence d’une situation de surcharge en cours de résolution. Cela peut se faire via l’envoi par exemple d’un code d'erreur lors d’une tentative d’établissement d’appel par exemple selon le protocole SIP ou par une communication en temps réel pour le Web ou WebRTC (ou « Web Real Time Communication », en anglais). Ce code d’erreur précise le problème rencontré. Dans un environnement SIP par exemple, le document RFC 3261 définit le code de réponse "503" qui doit être transmis par un élément de service en situation de surcharge à tout équipement client ou agent de l’utilisateur UA (pour « User Agent », en anglais) ayant sollicité cet élément. L’envoi d’un message d’erreur SIP avec ce code signifie 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'élément de service en question peut à cette occasion indiquer un délai à l’issue duquel le client peut effectuer une nouvelle tentative (grâce à l’en-tête "Retry-After"). Un client UA recevant un tel code de réponse est censé solliciter un autre élément du service pour satisfaire sa demande, au moins jusqu'à l’expiration du délai "Retry-After" (s'il est indiqué) et si la possibilité de contacter un autre élément de service lui est offerte. A cet égard, il convient de noter qu’une procédure de détermination d’un tel délai est difficile à établir. La mise en place d’une telle procédure par l’élément de service congestionné risque même d’aggraver la situation et de le maintenir en état de surcharge permanente.

L’exemple de la montre un échange de messages qui intervient entre un agent UA1 de l’utilisateur et un élément de service PS, de type élément relais (ou « proxy server » en anglais). Ainsi, UA1 envoie une requête de type INVITE pour établir un appel vers PS. Ce dernier étant indisponible, il génère alors une réponse de type "503 Service Unavailable" pour notifier au client l’impossibilité d’accéder au service. Ceci suppose que la procédure SIP est en mesure de générer un tel message et que l’opérateur a la capacité de procéder au traitement associé en cas de surcharge.

Une autre pratique connue consiste à envoyer des notifications de congestion ou de surcharge dans des messages SIP de type OPTIONS ou NOTIFY.

Une caractéristique commune à ces pratiques est l’implication de l’élément du service congestionné dans la résolution, notification et gestion de la situation de surcharge. Elles présentent cependant l’une comme l’autre un certain nombre de limitations.

Une alternative consiste en l'ajout par les éléments du service d'un champ d’information dédié au traitement des phénomènes de congestion/surcharge. L'objectif de cette alternative est de fournir une meilleure qualification de l'état de congestion et de minimiser les approximations des mécanismes décrits précédemment. Elle repose sur un en-tête SIP dédié, dénommé "CONGESTION", qui 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 (par ex. CPU, réseau), l'élément de service concerné ainsi qu'un délai au-delà duquel une nouvelle tentative pourra être effectuée. Cette alternative présente toutefois les mêmes inconvénients que l’utilisation du champ "Retry-After" car l’élément de service doit générer un message et exécuter une procédure pour déterminer (voire prédire, compte tenu des demandes présentes et futures) l’échéance de son retour à la normale (c.-à-d. fonctionnement nominal), ce qui n’est pas facilement réalisable lors des phénomènes de surcharge exceptionnels (par ex. crises ou événements importants).

Le document RFC7339 définit différentes méthodes de contrôle et algorithmes associés. Il décrit en particulier comment un élément du service surchargé peut indiquer aux autres éléments de service qui le sollicitent de réduire le nombre de messages qu’ils lui envoient pour qu’ils régulent les sollicitations entrantes en cas de surcharge. Pour ce faire, des paramètres SIP dédiés à la gestion de la charge et dénommés "oc" (pour « overload control », en anglais), "oc-algo, "oc-validity", et "oc-seq" ont été définis pour inclure diverses informations permettant de caractériser le taux et les conditions de la surcharge. Un avantage des méthodes décrites dans le document RFC7339 est de permettre une meilleure gestion des situations de surcharge que la méthode décrite dans le document RFC3261, mais elles ne permettent pas de garantir une éradication rapide du phénomène de surcharge ni de le prévoir. Au contraire, face à un problème de surcharge de type "Flash Crowds", l'élément de service subissant le pic de trafic doit déclencher tous les processus décrits dans le document RFC7339, ce qui augmente d'autant le nombre d’opérations qu’il a à effectuer, et contribue donc à l’aggravation de son état de surcharge. En conséquence, le temps nécessaire pour absorber l'afflux de trafic se trouve augmenté.

On connaît de la demande de brevet internationale publiée sous le numéro WO2009/122071, un procédé de gestion préventive d’une situation de surcharge, qui vise à éviter qu'un pic de surcharge n'impacte la plateforme de service de sorte que le service devienne indisponible, par exemple un pic provoqué par un phénomène de type "Flash Crowds». Ce procédé consiste à instaurer un filtrage des demandes d’accès au service, au niveau des équipements de bordure. Ce filtrage est piloté par la définition et la mesure préalables de seuils pertinents pour caractériser le début d’un phénomène de surcharge. Ces seuils sont définis par l'opérateur du service. Ils prennent en compte une limite maximale supportée par l’élément de service et un ratio par rapport à cette limite qui représente la valeur limite acceptée en situation opérationnelle. Un tel écrêtage du flux de demandes à traiter permet de protéger la plateforme de service et de s’assurer qu’elle soit toujours en mesure d'absorber le trafic qu'elle reçoit. En effet, contrairement aux autres pratiques susmentionnées, cette opération de filtrage permet de réguler les pics de trafic avant que ces pics n’affectent le fonctionnement de la plateforme de service.

Toutefois, il se peut que d’autres éléments que la plateforme de service impliqués dans la mise en œuvre du service subissent des défaillances ou rencontrent des anomalies. De tels éléments sont, par exemple, des éléments de bordure qui relaient des messages d’établissement de sessions applicatives entre les terminaux utilisateurs et la plateforme de service. Ces sessions sont supportées par des réseaux d’accès au service par l’intermédiaire desquels les agents d’utilisateurs transmettent des demandes d’accès au service, ou des éléments d’interconnexion vers d’autres réseaux (p. ex., interconnexion RTC ou PLMN (« Public Land Mobile Network », en anglais)).

L’invention propose un mécanisme permettant de gérer une telle situation.

3. Présentation de l’invention

L’invention répond à ce besoin en proposant un procédé de contrôle d’un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit procédé comprenant:
- l’obtention d’informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif;
- la détection, à partir des informations obtenues, d’une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d’exécution du service; et
- la transmission d’au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client.

L’invention propose une approche complètement nouvelle et inventive de la gestion d’une situation de surcharge ou de défaillance subie par un système de mise en œuvre d’un service applicatif dans un réseau de télécommunications. Elle consiste à observer le fonctionnement des équipements de service de ce système en collectant des informations relatives à des événements de traitement de messages échangés lors d’un accès à ce service au niveau de ces équipements, et, en cas d’anomalie détectée par rapport à un ou plusieurs critères donnés d’exécution du service, à décider d’une ou plusieurs actions de contrôle d’un traitement d’au moins une demande d’accès au service par ledit équipement client.

Avantageusement, l’action de contrôle a pour effet de modifier une configuration réseau initiale faite au démarrage de l’équipement client. A cet effet, elle comprend par exemple un ou plusieurs paramètres de contrôle du traitement d’une demande d’accès au service par l’équipement client. L’invention s’applique à un équipement client déjà configuré pour accéder au service et y a déjà accès. Le mécanisme de contrôle du traitement d’une demande d’accès au service applicatif par l’équipement client selon l’invention diffère donc d’une procédure de configuration initiale d’un équipement client destiné à lui permettre d’accéder au service.

De la sorte, les anomalies de traitement qui pourraient induire une situation de crise/surcharge et impacter la bonne exécution du service telle que définie par lesdits critères, sont gérées en anticipation, à la source des demandes d’accès au service et en dehors du système, sans impacter les équipements du cœur de service (ou plateforme de service).

Contrairement à l’art antérieur, il ne s’agit plus seulement de détecter et d’éviter un état de surcharge d’un équipement de service, mais surtout de détecter voire d’anticiper une anomalie ou une défaillance dans la mise en œuvre du service par un ou plusieurs équipements de service, avant qu’elle ne crée une situation de surcharge et surtout avant qu’elle nuise à la bonne exécution du service considéré.

Selon l’invention, des critères d’exécution génériques aux différents services et/ou spécifiques au service considéré sont définis et pris en compte, et utilisés pour détecter des anomalies de traitement comme des déviations par rapport à des conditions de fonctionnement nominal, ce qui permet de décider de façon pertinente de la ou les actions de contrôle les mieux adaptées.

Selon l’invention, ces actions de contrôle sont destinées aux équipements clients eux-mêmes de façon à agir au plus près de la source des demandes d’accès au service tout en minimisant l’impact sur le fonctionnement du cœur du système. Ceci permet de modifier la façon dont ils traitent une demande d’accès au service ou un message d’établissement d’une session applicative et offre bien plus de possibilités d’ajustements qu’un simple filtrage aléatoire du trafic à l’entrée de la plateforme de service, comme le propose l’art antérieur.

En effet, si un tel filtrage préserve la plateforme de service d’un état de surcharge, il ne prend pas en compte le type de service ni d’éventuels critères pour évaluer si les mesures de filtrage mises en œuvre au niveau des équipements de bordure permettent de rendre le service applicatif dans des conditions de fonctionnement acceptables et satisfaisantes pour l’utilisateur.

Ainsi, en prenant en compte des critères d’exécution spécifiques au service applicatif considéré, l’invention permet d’adapter le contrôle effectué sur les équipements clients.

Avantageusement, l’action de contrôle comprend un paramètre de configuration de l’équipement client de façon à ce que ce dernier modifie sa configuration initiale.

L’invention s’appuie sur des mécanismes de signalisation connus et déjà utilisés pour la fourniture du service, sans nécessiter d’extension particulière. Par exemple un protocole de gestion de la configuration des équipements d’un réseau, tel que NETCONF ou RESTCONF peut être utilisé. Un tel protocole s’appuie sur le langage XML pour coder les données de configuration ainsi que les messages du protocole. En ce qui concerne le format et la structure des notifications d’événements de traitement, un langage de modélisation de données tel que YANG peut être utilisé, moyennant la définition d’un module YANG dédié.

L’invention s’applique à tout type de service applicatif, mais elle est particulièrement intéressante dans le cas d’un service de téléphonie sur IP, notamment lorsqu’il se trouve confronté à une situation de type « Flash Crowds ».

Selon au moins un aspect de l’invention, ledit procédé comprend l’apprentissage préalable d’un modèle de classification d’un système de détection automatique d’unedite anomalie de traitement à partir d’un ensemble d’apprentissage comprenant des informations d’événements de traitement préalablement étiquetées à l’aide d’au moins deux classes comprenant une classe de présence d’anomalie et une classe d’absence d’anomalie et ladite détection d’une anomalie est réalisée par ledit système à partir des informations d’évènement de traitement obtenues pour un ou plusieurs équipements de service impliqués dans la mise en œuvre du service considéré, ledit système produisant en sortie l’une des au moins deux classes.

Par exemple un tel système met en œuvre un modèle de classification déterminé à l’aide de techniques d’intelligence artificielle telles que l’apprentissage machine (pour « machine learning », en anglais) pour collecter et classer les données observées et un algorithme (tel que l’apprentissage par renforcement) permettant d’assister la prise de décision relative au traitement de la situation de crise.

Un avantage est de déterminer une situation optimale de fonctionnement d’un équipement de service ou d’un ensemble d’équipements de service pour rendre le service considéré.

Selon un autre aspect de l’invention, ladite action de contrôle appartient à un groupe comprenant au moins :
- une action de contrôle d’un étalement temporel d’émissions de demandes d’établissement de sessions applicatives par ledit équipement client ;
- une action de contrôle d’un nombre de tentatives d’établissement d’une session applicative audit service par ledit équipement client ;
- une action de contrôle d’un numéro de remplacement du numéro de téléphone associé au service demandé par ledit équipement client ;
- une action de contrôle d’une priorité du service, comprenant la configuration de niveaux de priorité affectés aux services demandés et aux autres services auxquels ledit équipement client peut accéder;
- une action de contrôle d’une programmation automatique d’un serveur d’annonces d’un numéro de remplacement d’un numéro de téléphone associé au service demandé par ledit équipement client.

Un avantage est que l’ajustement de la configuration des équipements de service et/ou des équipements clients proposé par l’invention permet de réguler, rediriger, voire hiérarchiser le trafic en fonction du service demandé.

Selon encore un autre aspect de l’invention, lorsque ledit service applicatif comprend un établissement d’une communication téléphonique, ladite action de contrôle comprend la configuration d’au moins un numéro de téléphone, dit numéro alias, de remplacement d’un numéro de téléphone associé au service.

Avantageusement, un tel numéro alias permet d’accéder au standard téléphonique par une autre route réseau. Pour un service d’urgence par exemple, l’objectif est que le service soit rendu pour toutes les demandes d’accès reçues par le système. Un avantage de l’invention est de permettre la configuration d’un autre numéro de téléphone par l’intermédiaire duquel le centre d’urgence, bien que saturé sur son numéro de téléphone principal, reste joignable. Cette configuration est transparente pour l’utilisateur qui peut continuer à composer le numéro de téléphone habituel et ne se rend même pas compte de la redirection de sa demande.

L’invention propose ainsi une solution fiable pour gérer un pic de surcharge au niveau d’un service applicatif, en particulier un centre d’appel de sécurité publique (pour « Public Safety Answering Point », en anglais), sans exiger d’un utilisateur en état de stress extrême de consulter un réseau social pour prendre connaissance d’un numéro de téléphone alternatif mis en place par l’opérateur du service, par exemple.

En variante, lorsque ledit service applicatif comprend un établissement d’une communication téléphonique, ladite action de contrôle comprend la programmation automatique d’un serveur d’annonce d’un numéro de téléphone de remplacement d’un numéro de téléphone de destination.

Alternativement, lorsqu’un utilisateur tente d’établir une communication téléphonique avec un numéro de téléphone de destination (par ex. associé au standard téléphonique, un centre d’urgence, un appel international) et qu’un numéro de remplacement a été mis en place du fait que celui-ci est temporairement injoignable, le serveur de programmation annonce à l’utilisateur le numéro de remplacement à composer.

Selon un autre aspect de l’invention, ledit au moins un critère d’exécution du service comprend un taux d’échec d’établissement de communication téléphonique égal à zéro et un délai d’établissement de communication téléphonique inférieur à un seuil prédéterminé.

Pour un service d’urgence, la communication avec le centre d’urgence doit être établie avec succès dans 100% des cas et avec un délai raisonnablement court.

L’invention concerne également un dispositif de contrôle d’un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en œuvre :
- l’obtention d’informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif;
- la détection, à partir des informations obtenues, d’une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d’exécution du service; et
- la transmission d’au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client.

Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé de contrôle d’un accès tel que décrit précédemment.

Avantageusement, ledit dispositif est intégré dans un équipement de contrôle d’au moins un équipement de service impliqué dans la mise en œuvre d’un service applicatif dans un réseau de télécommunications.

Avantageusement, ledit équipement de contrôle est compris dans 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 de service impliqués dans la mise en œuvre dudit service.

Le système, l’équipement de contrôle et le dispositif de contrôle présentent au moins les mêmes avantages que ceux conférés par le procédé de contrôle précité.

Corrélativement, l’invention concerne aussi un procédé de traitement d’un message de contrôle d’un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit procédé étant exécuté par un équipement client configuré pour accéder audit service applicatif, ledit procédé comprenant :
- la réception du message de contrôle en provenance d’un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client, et
- l’exécution de l’action de contrôle lors du traitement de ladite demande.

Avec l’invention, l’équipement de contrôle agit sur l’équipement client de sorte à ajuster la façon dont il traite les demandes d’accès au service applicatif. Il intervient ainsi à la source de sorte à corriger sans délai la ou les anomalies de fonctionnement constatées au niveau d’un ou plusieurs équipements de service constituant le système de mise en œuvre du service applicatif.

Selon un aspect de l’invention, lorsque le service demandé comprend l’établissement d’une communication téléphonique avec une destination et l’action de contrôle comprend la configuration d’au moins un numéro de téléphone alias d’un numéro de téléphone associé au service demandé, l’exécution de l’action comprend :
- la modification d’un en-tête du message de demande d’accès audit service comprenant le remplacement du numéro de téléphone associé au service demandé par ledit numéro de téléphone alias.

Par exemple l’équipement client effectue ce remplacement dans le champ « Request URI » de l’en-tête « To » de la demande d’accès au service.

Un avantage d’effectuer cette modification au niveau de l’équipement client est que les en-têtes ne sont pas encore chiffrés. En effet, de façon courante, des équipements de service utilisent des protocoles de chiffrement de certains en-têtes du message ou de certains champs d’information contenus dans ces en-têtes.

L’invention concerne également un dispositif de traitement d’un message de contrôle d’un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit dispositif étant destiné à être exécuté par un équipement client configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en œuvre :
- la réception d’un message de contrôle en provenance d’un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client, et
- l’exécution de l’action de contrôle lors du traitement de ladite demande.

Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé de traitement d’un message de contrôle d’un accès tel que décrit précédemment.

Avantageusement, ledit dispositif est intégré dans un équipement client d’un domaine client configuré pour accéder à un service applicatif, ledit service étant mis en œuvre par au moins un équipement de service d’un réseau de télécommunications. Il peut aussi être intégré dans le système de mise en œuvre d’un service applicatif précité.

Le système, l’équipement client et le dispositif de traitement présentent au moins les mêmes avantages que ceux conférés par le procédé de contrôle précité.

L’invention concerne également des produits programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu’ils sont exécutés par un processeur.

Un 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 également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés selon l’invention tel que décrits ci-dessus.

Un tel support d'enregistrement 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 un support mobile (carte mémoire) ou un disque dur ou un SSD.

D'autre part, un tel support d'enregistrement 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, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.

Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés précités.

Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d’éléments matériels et/ou logiciels support d’une fonction ou d’un service, qu’ils soient unitaires ou combinés.

De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc.

Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.

Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique.

4. Brève description des figures

D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

: la (déjà décrite) illustre de façon schématique un exemple de notification d’un état de surcharge par un équipement de service impliqué dans la mise en œuvre d’un service applicatif à un équipement client qui souhaite accéder au service, selon l’art antérieur;

: la illustre de façon schématique un exemple d’architecture d’un système de mise en œuvre d’un service applicatif dans un réseau de télécommunications auquel accède un équipement client selon un mode de réalisation de l’invention;

:la détaille un exemple de structure d’un équipement de contrôle d’un tel système et d’un équipement client selon un mode de réalisation de l’invention;

: la illustre de façon schématique un exemple d’architecture d’un système de mise en œuvre d’un service applicatif selon un autre mode de réalisation de l’invention ;

:la décrit sous forme d’un logigramme les étapes d’un procédé de contrôle d’un accès à un service applicatif mis en œuvre dans un réseau de télécommunications, selon un exemple de réalisation de l’invention ;

:la décrit sous forme d’un logigramme les étapes d’un procédé de traitement d’un message de contrôle d’un accès à un service applicatif mis en œuvre dans un réseau de télécommunications, selon un exemple de réalisation de l’invention ;

: la illustre de façon schématique un exemple de fonctionnement nominal du service applicatif ;

:la illustre de façon schématique un exemple d’anomalie de fonctionnement du service ;

:la illustre de façon schématique un exemple de contrôle effectué sur un équipement client selon un mode de réalisation de l’invention;

: la décrit un exemple de structure matérielle d’un dispositif de contrôle d’un accès à un service applicatif selon l’invention ; et

: la décrit un exemple de structure matérielle d’un dispositif de traitement d’un message de contrôle selon l’invention.

5. Description détaillée de l'invention

Le principe général de l’invention repose sur le contrôle d’un accès par au moins un équipement client à un service applicatif mis en œuvre par un système comprenant une pluralité d’équipements de service dans un réseau de télécommunications. Ce contrôle s’appuie sur l’obtention d’informations d’événements relatifs au traitement par au moins un des équipements de service du système, de messages échangés dans le cadre de la mise en œuvre du dit service applicatif, la détection, à partir des informations obtenues, d’une anomalie de traitement par ledit équipement de service par rapport à au moins un critère donné d’exécution du service, et la transmission d’au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement de ladite au moins une demande d’accès audit service par ledit équipement client.

L’invention s’applique à tout type de service applicatif dont l’accès se fait par l’établissement d’une session applicative entre un équipement client demandeur et un tel système, par exemple un appel audio, vidéo ou de messagerie instantanée IM.

Elle concerne tout type de réseau de télécommunications. Dans la suite de la description néanmoins, on s’attache à décrire le cas d’un réseau de télécommunications IP (RT) et un service de téléphonie sur IP. Compte tenu des déploiements actuels en matière de Téléphonie sur IP, les exemples ci-après s'appuieront sur le protocole SIP.

Bien sûr, les modes de réalisation, particulièrement les protocoles envisagés dans ces modes de réalisation, ne sont cités qu’à titre d’exemple.

Dans la suite, on désignera indifféremment par équipement ou élément de service tout élément sollicité pour la fourniture d’un service (et en particulier pour l’établissement d’une session applicative).

Un tel équipement ou élément peut intervenir dans les échanges des messages de contrôle (par exemple à l’aide du protocole SIP), l’échange des données utiles (par exemple à l’aide du protocole RTP), voire les deux.

La mise en œuvre d’un service peut impliquer un ou plusieurs éléments de service.

L’ordre d’invocation des éléments de service peut être statique et spécifique à un service (par exemple conforme à l’architecture IMS) ou être établi à la demande (par exemple, réalisé à l’aide d’une technique de chaînage de service).

Un élément de service peut être mis en œuvre de manière logicielle et/ou matérielle. Un ou plusieurs éléments de service peuvent être embarqués dans un même équipement physique.

La illustre de façon schématique un exemple d’architecture d’un système S pour la mise en œuvre d’un service de téléphonie IP déployé par un fournisseur de service dans un réseau de télécommunications RT, selon un mode de réalisation de l’invention. Sur cette , on a aussi représenté un équipement client ou agent d’utilisateur UA (ou « User Agent », en anglais) configuré pour accéder au service. Cet agent utilisateur peut aussi être embarqué dans un terminal utilisateur CPE (ou « Customer Premises Equipment », en anglais). Il s’agit typiquement de tout équipement installé chez ou porté par l’utilisateur pour créer, acheminer ou terminer une communication entre l’utilisateur et le système de l'opérateur ou du fournisseur de service, par exemple une passerelle résidentielle ou professionnelle (ou « gateway », en anglais) ou un téléphone intelligent (ou « smartphone », en anglais). En alternative, l’UA peut aussi être intégré dans un équipement dédié. En cas de présence d’un CPE, ce dernier embarque généralement un équipement relais (ou « proxy server », en anglais), non représenté.

Dans cet exemple, l’équipement client UA, CPE accède au réseau RT par l’intermédiaire d’un réseau d’accès AN, par exemple de type radio cellulaire, fibre ou ADSL.

Le système S de la comprend les éléments suivants :
- Des éléments ou équipements de service en bordure, appelés ici SBE (« Session Border Element ») et DBE (« Data Border Element »). L’élément SBE est responsable du traitement des messages de signalisation, alors qu’un élément DBE est responsable du traitement des flux média. Ces deux éléments peuvent être embarqués dans un même équipement ou dans des équipements distincts. Un exemple d’implémentation de l’élément SBE est la fonction P-CSCF (ou « proxy-call/session control function », alors que la fonction BGF (« Border Gateway Function ») est un exemple d’implémentation de l’élément SBE. La fonction SBC (« Session Border Controller ») est un autre exemple d’implémentation qui supporte les deux éléments SBE et DBE.
On note que :
Lorsque ces éléments SBE/DBE sont directement connectés aux UA, ils sont les points de contact du système mettant en œuvre le service. Dans cette configuration, les UA n’ont pas de visibilité de la structure interne d’une plateforme cœur PFC de mise en œuvre du service.
Ces éléments peuvent aussi être utilisés pour des besoins d’interconnexion avec d’autres domaines (identifiés par « RLM# r» sur la , avec r entier compris entre 2 et 5). Ces domaines peuvent être d’autres domaines de téléphonie IP, un autre réseau de télécommunications tel que le réseau RTC ou un réseau mobile, etc.
- La plateforme cœur PFC, composée d’éléments appelés CF (« Core Functions ») situés dans le réseau cœur CN, non représentés. En effet, l’invention est utilisable de manière générale indépendamment de l’architecture du service sous-jacente, qui est par exemple une architecture IMS (ou « IP Multimedia Subsystem », en anglais) ou toute autre architecture future. Aucune hypothèse n’est faite quant à la nature des CF, leur nombre, ou le séquencement d’invocation de ces CF pour l’établissement d’une session applicative.

Selon ce mode de réalisation de l’invention, le système S comprend aussi un équipement de contrôle, ou contrôleur CTR, configuré pour contrôler les équipements de service et les équipements clients UA, CPE. Il s’agit par exemple d’un contrôleur SDN (ou « Software-Defined Networking », en anglais), comme illustré sur la . Il est responsable de la gestion et de la configuration des éléments de service. Les protocoles NETCONF ou RESTCONF sont utilisés à titre d’exemple pour gérer et configurer ces éléments, mais d’autres protocoles peuvent être utilisés.

Dans cet exemple de réalisation de l’invention, l’équipement de contrôle CTR comprend un dispositif 100 de contrôle d’un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif. Il est configuré pour obtenir des informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans la mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif, détecter, à partir des informations obtenues, une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d’exécution du service; et transmettre au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client.

Le dispositif 100 met ainsi en œuvre le procédé de contrôle d’un accès au service selon l’invention qui sera détaillé ci-après en relation avec la .

Alternativement, le dispositif 100 peut être indépendant de l’équipement de contrôle, mais connecté à celui-ci par une liaison quelconque, filaire ou non. Par exemple, il peut être intégré à un autre équipement du réseau de télécommunications, par exemple un équipement de service.

Plusieurs contrôleurs peuvent être déployés, comme illustré par la . Dans ce deuxième exemple, un premier contrôleur est responsable des éléments de service du fournisseur de service, alors qu’un deuxième contrôleur est utilisé pour la gestion des équipements clients (UA, CPE).

En cas de présence de plusieurs contrôleurs, on suppose qu’ils s’interfacent pour des besoins de coordination et de synchronisation d’états, le cas échéant, de façon connue en soi.

Selon ce mode de réalisation de l’invention, l’équipement client UA, CPE comprend un dispositif 200 de traitement d’un message de contrôle d’un accès au service applicatif impliquant au moins un équipement de service dans le réseau de télécommunications RT. Ce dispositif 200 est configuré pour recevoir un message de contrôle en provenance de l’équipement de contrôle du réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client, et exécuter l’action de contrôle lors du traitement de ladite demande.

Le dispositif 200 met ainsi en œuvre le procédé de traitement d’un message de contrôle d’un accès au service applicatif selon l’invention qui sera détaillé ci-après en relation avec la .

On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de contrôle d’un accès à un service applicatif par au moins un équipement client, selon un mode de réalisation de l’invention. Dans ce qui suit, ce procédé est mis en œuvre par le dispositif 100 précité.

En 50, des informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif, sont obtenues.

Par exemple, le dispositif de contrôle 100 reçoit ces informations (directement ou indirectement) des équipements de service qu’il contrôle. Elles reflètent l’état d’un tel équipement de service. Avantageusement, il les stocke dans une mémoire M1, structurée ou non. Par exemple, une telle mémoire est organisée sous la forme d’une base de données et indexée par un identifiant de l’équipement de service concerné par la ou les informations reçues.

A titre d’exemple, le format des notifications comprenant ces informations est défini à l’aide d’un langage de modélisation de données. Par exemple, il s’agit du langage YANG de modélisation des données qui peuvent être véhiculées par exemple dans des messages des protocoles NETCONF ou RESTCONF. Il s’agit d’un langage modulaire représentant des structures de données dans un format d'arbre XML. Le langage de modélisation des données est livré avec un certain nombre de types de données intégrés. D'autres types de données d'application spécifiques peuvent être dérivés des types de données intégrés. En particulier, selon l’invention, les types de données des informations reçues des équipements de service par l’équipement de contrôle peuvent être spécifiés dans un module Yang dédié. Ces informations d’événements de traitement peuvent être sollicitées ou non. Les réponses sollicitées sont des réponses à des requêtes explicites telles que des requêtes GET émises par le dispositif de contrôle 100, alors que les réponses non-sollicitées sont typiquement des notifications envoyées par un équipement de service sans qu’une requête spécifique n’ait été envoyée. Les notifications NETCONF/RESTCONF sont des exemples de réponses non-sollicitées. Par exemple, les notifications peuvent être générées en fonction de filtres maintenus localement par cet équipement de service. Ces notifications peuvent consister à informer le contrôleur :
- d’un taux d’erreurs observé sur une interface donnée de l’équipement de service,
- d’un taux d’échec d’établissement de toutes les sessions traitées par l’équipement de service.,
- d’un taux d’échec d’établissement de la moyenne mobile des sessions traitées par un élément de service,
- d’un taux d’échec d’établissement de sessions applicatives vers une destination ou un service spécifique (par ex., un serveur identifié par une adresse IP, un site Web, un numéro E.164, ou un alias SIP),
- d’un délai de réponse (c.-à-d., délai entre le temps d’envoi d’une requête et le temps de réception d’une réponse correspondante)
- d’un taux d’échec d’établissement de sessions vers l’une des destinations (par ex. des numéros E.164 ou des alias SIP) servies par l’équipement de service
- d’un niveau de charge CPU de l’équipement de service,
- d’un journal des sessions de l’équipement de service,
- etc.

En 51, une anomalie de traitement par au moins undit équipement de service est détectée à partir des informations obtenues et par rapport à au moins un critère donné d’exécution du service. En d’autres termes, des anomalies au niveau du service peuvent aussi être détectées en plus des anomalies au niveau d’un équipement de service.

Ces ou ces critères d’exécution du service peuvent être génériques à tout type de service et/ou spécifiques au service applicatif considéré. Par exemple, pour un service d’urgence tel que le 15, un premier critère peut être un taux d’échec des établissements de sessions d’appel égal à zéro et un délai d’établissement d’un appel par exemple inférieur à une minute.

Ce ou ces critères d’exécution donnés contribuent à définir un fonctionnement nominal du service et aussi des équipements de service impliqués et la détection d’une anomalie selon l’invention comprend la détection d’au moins un écart de fonctionnement dudit au moins un équipement de service par rapport au fonctionnement nominal.

Avantageusement, le procédé comprend l’apprentissage d’un modèle de classification d’un système de décision automatique à partir d’un ensemble d’apprentissage comprenant des informations d’événements de traitement préalablement étiquetées à l’aide d’au moins deux classes comprenant une classe de présence d’anomalie et une classe d’absence d’anomalie et la détection est réalisée par le système de décision qui prend en entrée les informations d’évènements de traitement obtenues pour un ou plusieurs équipements de service impliqués dans la mise en œuvre du service considéré et fournit en sortie une décision d’anomalie détectée ou d’absence d’anomalie détectée. Par exemple, un tel apprentissage met en œuvre des techniques d’apprentissage machine ML (ou « Machine Learning », en anglais) et alimentent la logique de calcul du dispositif 100 et déterminent le modèle de classification.

On note que la détection d’anomalies peut se faire par équipement de service, pour la pluralité d’équipements de service impliqués dans la mise en œuvre du service considéré, pour les équipements de service associés à une même plateforme cœur PFC globale à plusieurs services, etc.

On note également qu’une décision d’anomalie peut être prise sur la base d’un cumul d’anomalies de traitement détectées au niveau d’équipements de service différents.

En 52, lorsqu’une anomalie de traitement a été détectée au niveau d’un ou plusieurs équipements de service, une décision de commander l’exécution d’au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par au moins un équipement client UA, CPE est prise.

En fonction du(es) critère(s) d’exécution donnés utilisé(s) pour détecter une anomalie ou défaillance) de l’anomalie détectée et d’autres informations relatives à l’architecture ou au fonctionnement du système telles que par exemple des travaux de maintenance programmés, le dispositif de contrôle 100 décide de procéder:
- au contrôle de la charge au niveau d’un ou plusieurs équipements clients, avec un certain niveau de granularité, (par exemple, par numéro de téléphone ou plage de numéros de téléphone des équipements clients) ;
- au contrôle de l’étalement temporel de la création de nouvelles sessions applicatives au niveau des équipements clients UA , CPE;
- au contrôle d’un nombre de tentatives prises en compte pour l’établissement d’une session applicative demandée par l’équipement client. Ce nombre peut éventuellement être défini par plage de numéros de téléphone, typiquement, un nombre plus grand peut être défini pour les appels d’urgence que pour d’autres services applicatifs ;
- à la fourniture d’une liste de numéros de téléphone de remplacement ou alias directement à l’équipement client. Par exemple, en cas d’indisponibilité d’une route pour joindre un numéro abrégé (pour le service d’urgence des sapeurs-pompiers 18, par exemple), il s’agit de configurer dynamiquement les équipements clients avec une liste d’alias à utiliser à la place du numéro de téléphone associé au service demandé. Selon une variante d’implémentation, il est aussi possible de configurer des numéros de contournement pour réagir à une indisponibilité d’un équipement d’interconnexion (par. ex. un équipement permettant à un opérateur de se connecter au réseau d’un autre opérateur). L’équipement client UA, CPE remplacera automatiquement le numéro indisponible par un numéro de contournement. Ainsi, les appels seront interceptés par un équipement de contournement associé qui se chargera ensuite de remplacer le numéro de contournement par le numéro d’origine avant transmission ;
- à la priorisation de certains numéros, d’urgence par exemple, grâce à des filtres dédiés communiqués à l’UA,CPE (voire SBE) ;
- à la programmation automatique d’un serveur d’annonces (ou « Announcement Server », en anglais) qui permet d’annoncer des numéros de remplacement lorsque l’UA appelle le numéro abrégé du service ;
- etc.

On note que ces actions de contrôle sont destinées aux équipements clients qui demandent à accéder au service applicatif, mais qu’elles peuvent aussi être commandées à des équipements de service, en particulier des équipements de bordure (SBE). C’est le cas notamment pour l’action de priorisation de certains numéros de téléphone par la mise en place de filtres dédiés.

Bien sûr, ces actions peuvent être combinées. Par exemple, le dispositif de contrôle 100 peut décider, pour permettre le redémarrage d’un service applicatif sans que celui-ci soit écroulé par les pics de trafic immédiatement après la remise en service, d’agir sur l’étalement du traitement de requêtes d’établissement de sessions applicatives envoyées par un UA et/ou sur l’établissement du relais par équipement de bordure un SBE/DBE et/ou sur la redirection des requêtes vers un serveur d’annonce, etc.

En 53, au moins un message de contrôle comprenant au moins une action de contrôle est transmis à un ou plusieurs équipements clients UA, CPE.

On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de traitement d’un message de contrôle d’un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications.

Dans ce qui suit, ce procédé est mis en œuvre par le dispositif 200 précité, intégré à un équipement client UA, CPE configuré pour accéder audit service applicatif.

En 60, un message de contrôle MC est reçu en provenance d’un équipement de contrôle CTR dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle AC d’un traitement d’au moins une demande d’accès audit service par ledit équipement client. Par exemple, il enregistre l’action de contrôle reçue dans une mémoire M2.

En 61, le dispositif 200 modifie sa configuration initiale pour prendre en compte l’action de contrôle reçue.

Par exemple, lorsque l’action de contrôle comprend un numéro alias à utiliser en remplacement du numéro de téléphone associé au service applicatif considéré, le dispositif 200 enregistre ce numéro alias dans une mémoire et modifie sa procédure de sorte à systématiquement remplacer le numéro de téléphone associé au service par cet alias. Les actions sont par exemple définies à l’aide d’expressions régulières (« regexp »).

En 62, il exécute l’action de contrôle lors du traitement de ladite demande d’accès au service.

Par exemple, à réception d’une demande d’accès au service, il cherche d’abord en mémoire si un numéro alias existe pour cette demande. Si oui, il remplace automatiquement le numéro de téléphone associé au service demandé dans le champ « Request URI» et l’en-tête « To » de la requête d’établissement de session applicative. Contrairement à l’état de l’art, cette action de l’UA est transparente pour l’utilisateur et elle est immédiatement exécutée. Faire exécuter cette action par l’UA est notamment avantageux en cas d’utilisation de protocoles de chiffrement (et de l’URI « sips ») par les équipements de service, car elle intervient à la source, donc avant que le chiffrement soit réalisé).

On présente maintenant, en relation avec la l’exemple d’une configuration nominale pour une destination donnée, par exemple un centre d’appel d’urgence situé dans un domaine de destination, par exemple le domaine IP RLM#5 et associé à un numéro de téléphone, par exemple le numéro abrégé 18. Pour les besoins de cet exemple, on suppose que le domaine de destination RLM#5 est aussi joignable avec un autre numéro de téléphone, dit alias. Dans cet exemple, un appel émis par l’équipement client UA, CPE est acheminé jusqu’au centre d’appel dans des conditions de fonctionnement nominal. Autrement dit, la session applicative est établie avec succès dans un délai inférieur à un délai maximum autorisé.

La illustre un exemple d’échec d’établissement d’une session applicative demandée par l’équipement client UA, CPE. On suppose que le procédé de contrôle d’accès selon l’invention mis en œuvre par l’équipement de contrôle CTR a détecté une défaillance de fonctionnement d’un équipement de bordure SDE5/DBE5, plus précisément d’interconnexion entre le réseau cœur CN et le domaine IP RLM#5. Cette défaillance impacte la mise en œuvre d’un ou plusieurs services applicatifs, dont le centre des gestions des appels est situé dans ce domaine IP.

Selon l’invention, l’équipement de contrôle transmet un message de contrôle à l’équipement client UA, CPE.

Ce message comprend une action de contrôle qui consiste en la configuration d’une liste d’alias associant un numéro alias au numéro de téléphone de chacun des services concernés. A réception de la liste d’alias, l’équipement client UA, CPE modifie sa configuration initiale de sorte à utiliser cette liste pour procéder automatiquement à la réécriture du champ « Request URI » (et « To ») de toute requête d’établissement d’une session applicative pour accéder à l’un de ces services, en remplaçant le numéro de téléphone associé au service demandé par son alias. De la sorte et comme illustré par la , l’appel peut être acheminé avec succès via le domaine IP RLM#4 voisin. Ladite liste d’alias peut aussi être associée avec une date de validité au-delà de laquelle elle est supprimée automatiquement de la mémoire de l’UA, CPE sauf si une action de contrôle est reçue avec une demande de mise à jour de la date de validité à une autre date, ultérieure ou antérieure selon la rapidité avec laquelle la défaillance de fonctionnement est corrigée.

En alternative, le contrôle de traitement d’un accès au service peut aussi être effectué par l’équipement de contrôle CTR au niveau du CPE de l’utilisateur ou de l’équipement de bordure SBE1 localisé dans le réseau d’accès AN. Le contrôleur configure le CPE ou le SBE1 avec une liste d’alias. Cette liste est utilisée par l’équipement de bordure SBE1 pour procéder à la réécriture du champ « Request URI » (et « To ») de la requête d’établissement d’une session applicative. L’appel d’urgence peut être acheminé avec succès via le domaine IP RLM#4 voisin.

La redirection de tout ou partie du trafic vers la destination demandée telle que mise en œuvre selon l’invention permet aussi de réduire la charge de traitement de l’équipement de service défaillant et facilite la conduite d’opérations de maintenance telles qu’un redémarrage par exemple.

On considère maintenant, selon un deuxième exemple d’application de l’invention, un service de vote électronique. Chaque votant est invité à soumettre son vote (à l’occasion d’une émission télévisée ou d’une échéance électorale, par exemple) en accédant à un site web. La procédure de validation du vote repose sur un mécanisme d’acquittement qui consiste à envoyer au votant un message de confirmation de la prise en compte du vote (et de sa conformité à la règle électorale, le cas échéant). La soumission d’un tel vote peut être soumise à des contraintes temporelles fortes, susceptibles de provoquer une surcharge de trafic au niveau de plusieurs ressources réseau. Il s’agit notamment de celles du réseau utilisé pour acheminer les votes, de celles de l’équipement serveur destiné à réceptionner et comptabiliser les votes, de celles du système d’acquittement évoqué précédemment, ou de n’importe quelle combinatoire de ces ressources.

Dans ce deuxième exemple, l’invention s’appuie sur des dispositifs de traitement 200 embarqués dans des équipements clients, agents utilisateurs UA ou CPE ou encore dans d’autres équipements typiquement situés à la périphérie du réseau, tels que des routeurs du réseau d’accès, des routeurs du réseau cœur, un équipement d’accès au site de vote ou un équipement serveur en charge du traitement des votes. Ces dispositifs 200 sont configurés pour recevoir des actions de contrôle décidées et transmises par un dispositif de contrôle 100 tel que précédemment décrit, par exemple embarqué dans un équipement de contrôle CTR du réseau. De telles actions de contrôle visent à fluidifier l’acheminement du trafic.

Elle consistent par exemple à :
(1) surveiller un ensemble de compteurs d’interface qui rendent compte de la volumétrie du trafic transitant par chacune de ces interfaces,
(2) détecter l’atteinte d’un seuil à l’issue d’un relevé de ces compteurs (par exemple, 70% de la bande passante associée à une interface est actuellement utilisée pour acheminer le trafic des votes,
(3) mettre en place une fonction de conditionnement de trafic reposant par exemple sur un algorithme de seaux à jetons (tant qu’il y a des jetons dans le seau, le trafic peut être acheminé, quand il n’y a plus de jetons, le trafic peut être stocké dans une file d’attente (le temps que le volume de trafic repasse en dessous du seuil de 70%) ou bien être redirigé sur un autre chemin non congestionné mais permettant d’atteindre le site de traitement des votes),
(4) (re-) marquer le trafic en excès via un codage DSCP (ou « DiffServ Code Point », en anglais) spécifique, au niveau des équipements UA, CPE ou de périphérie. Par exemple, le trafic du vote est initialement marqué avec un DSCP AF12 (ce qui signifie que le trafic est stocké dans une file d’attente particulière) puis qu’il est re-marqué en AF11 ou Best Effort (DSCP valorisé à zéro), lorsque le trafic a atteint le seuil de 70% cité en exemple,
(5) modifier la ou les métriques associée(s) à une ou plusieurs interface(s) de sorte que de nouvelles routes puissent être spécifiquement établies et utilisées pour acheminer le trafic de soumission des votes et des messages d’acquittement à l’exclusion de tout autre trafic et/ou pour « forcer » le trafic en excès à emprunter un autre chemin, cette modification de métrique pouvant relever d’une décision prise par un contrôleur SDN lequel se chargera d’ordonner à l’équipement concerné de procéder à cette modification, par ex. via une commande NETCONF. On note que la politique d’affectation de métriques à des interfaces est généralement une politique de moindre coût qui tient compte de la bande passante associée à chaque interface. Par exemple, une interface à 10 Gbit/s est affectée d’une métrique de valeur 1 tandis qu’une interface à 100 Mbit/s est affectée une métrique de 100. Si le lien à 10 Gbit/s atteint un taux de charge de 70%, la métrique des interfaces correspondantes pourra être augmentée par exemple à 200. Dans ce cas, le protocole de routage dynamique sélectionnera des chemins au coût moindre, par exemple un chemin transitant par l’interface à 100 Mbit/s,
(6) envoyer une notification d’atteinte ou de dépassement de seuil à un contrôleur SDN, ce qui peut déclencher le calcul de nouveaux chemins selon une architecture PCE (ou « Path Computation Element », en anglais), etc.

De telles actions de contrôle permettent de prévenir tout risque de surcharge de l’équipement serveur configuré pour réceptionner les votes, notamment. Ces actions de contrôle sont exécutées par certains éléments du réseau (voire les équipements clients CPE) selon des informations qui peuvent être véhiculées dans des messages conformes au protocole PCEP (ou « Path Computation Element Protocol », en anglais) pour l’établissement de nouvelles routes, par exemple.

L’invention permet ainsi d’anticiper un contexte de surcharge et de fluidifier aussi bien les messages de soumission des votes que les messages d’acquittement.

Bien entendu les deux exemples d’application ne sont donnés qu’à titre illustratif, et on pourrait envisager encore d’autres contextes d’application de l’invention.

On présente maintenant, en relation avec la , un exemple de structure matérielle d’un dispositif 100 de contrôle d’un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit dispositif comprenant un module d’obtention d’informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif, un module de détection, à partir des informations obtenues, d’une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d’exécution du service; et un module de transmission d’au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client.

Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.

Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg1, représentatif des modules d’obtention, de détection et de transmission, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir les informations d’événement obtenues.

La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu’il effectue les étapes du procédé de contrôle d’un accès au service tel que détaillé ci-dessus, en relation avec la , dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 intégré dans un équipement de contrôle d’un réseau de télécommunications, mais il peut aussi être intégré dans un équipement de service ou tout autre équipement du réseau de télécommunications.

On présente aussi, en relation avec la , un exemple de structure matérielle d’un dispositif 200 de traitement d’un message de contrôle d’un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, comprenant un module de réception d’un message de contrôle en provenance d’un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client, et un module d’’exécution de l’action de contrôle lors du traitement de ladite demande.

Plus généralement, un tel dispositif 200 comprend une mémoire vive 203 (par exemple, une mémoire RAM), une unité de traitement 202 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg2, représentatif des modules de réception et d’exécution, stocké dans une mémoire morte 201 (par exemple, une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 203 avant d'être exécutées par le processeur de l'unité de traitement 202. La mémoire vive 203 peut aussi contenir l’action de contrôle reçue dans le message de contrôle.

La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu’il effectue les étapes du procédé de traitement d’un message de contrôle d’un accès à un service applicatif tel que détaillé ci-dessus, en relation avec la , et dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).

Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Claims

Procédé de contrôle d’un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit procédé comprenant:
- l’obtention (50) d’informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif;
- la détection (51) , à partir des informations obtenues, d’une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d’exécution du service; et
- la transmission (53) d’au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client.
Procédé de contrôle selon la revendication 1, caractérisé en ce que ledit procédé comprend l’apprentissage préalable d’un modèle de classification d’un système de détection automatique d’unedite anomalie de traitement à partir d’un ensemble d’apprentissage comprenant des informations d’événements de traitement préalablement étiquetées à l’aide d’au moins deux classes comprenant une classe de présence d’anomalie et une classe d’absence d’anomalie et en ce que ladite détection d’une anomalie est réalisée par ledit système à partir des informations d’évènement de traitement obtenues pour un ou plusieurs équipements de service impliqués dans la mise en œuvre du service considéré, ledit système produisant en sortie l’une des au moins deux classes.
Procédé de contrôle selon l’une des revendications 1 et 2, caractérisé en ce que ladite action de contrôle appartient à un groupe comprenant au moins :
- une action de contrôle d’un étalement temporel d’émissions de demandes d’établissement de sessions applicatives par ledit équipement client ;
- une action de contrôle d’un nombre de tentatives d’établissement d’une session applicative audit service par ledit équipement client ;
- une action de contrôle d’un numéro de remplacement du numéro de téléphone associé au service demandé par ledit équipement client ;
- une action de contrôle d’une priorité du service, comprenant la configuration de niveaux de priorité affectés aux services demandés et aux autres services auxquels ledit équipement client peut accéder;
- une action de contrôle d’une programmation automatique d’un serveur d’annonces d’un numéro de remplacement d’un numéro de téléphone associé au service demandé par ledit équipement client.
Procédé de contrôle selon l’une des revendications précédentes, caractérisé en ce que lorsque ledit service applicatif comprend un établissement d’une communication téléphonique, ladite action de contrôle comprend la configuration d’au moins un numéro de téléphone, dit numéro alias, de remplacement d’un numéro de téléphone associé au service.
Procédé de contrôle selon l’une des revendications précédentes, caractérisé en ce que, lorsque ledit service applicatif comprend un établissement d’une communication téléphonique, ladite action de contrôle comprend la programmation automatique d’un serveur d’annonce d’un numéro de téléphone de remplacement d’un numéro de téléphone de destination.
Procédé de contrôle selon l’une des revendications 4 et 5, caractérisé en ce que ledit au moins un critère d’exécution du service comprend un taux d’échec d’établissement de communication téléphonique égal à zéro et un délai d’établissement de communication téléphonique inférieur à un seuil prédéterminé.
Procédé de traitement d’un message de contrôle d’un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit procédé étant exécuté par un équipement client configuré pour accéder audit service applicatif, ledit procédé comprenant :
- la réception (60) du message de contrôle en provenance d’un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client, et
- l’exécution (62) de l’action de contrôle lors du traitement de ladite demande.
Procédé de traitement selon la revendication précédente, caractérisé en ce que, lorsque le service demandé comprend l’établissement d’une communication téléphonique avec une destination et l’action de contrôle comprend la configuration (61) d’au moins un numéro de téléphone alias d’un numéro de téléphone associé au service demandé, l’exécution de l’action comprend :
- la modification d’un en-tête du message de demande d’accès audit service comprenant le remplacement du numéro de téléphone associé au service demandé par ledit numéro de téléphone alias.
Dispositif (100) de contrôle d’un accès par au moins un équipement client à un service applicatif dans un réseau de télécommunications, ledit au moins un équipement client étant configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en œuvre :
- l’obtention d’informations d’événements relatifs au traitement par au moins un équipement de service impliqué dans une mise en œuvre du service applicatif, de messages échangés lors d’au moins un accès audit service applicatif;
- la détection, à partir des informations obtenues, d’une anomalie de traitement par au moins undit équipement de service par rapport à au moins un critère donné d’exécution du service; et
- la transmission d’au moins un message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client.
Dispositif (200) de traitement d’un message de contrôle d’un accès à un service applicatif impliquant au moins un équipement de service dans un réseau de télécommunications, ledit dispositif étant destiné à être exécuté par un équipement client configuré pour accéder audit service applicatif, ledit dispositif étant configuré pour mettre en œuvre :
- la réception d’un message de contrôle en provenance d’un équipement de contrôle dudit réseau de télécommunications, ledit message de contrôle comprenant au moins une action de contrôle d’un traitement d’au moins une demande d’accès audit service par ledit équipement client, et
- l’exécution de l’action de contrôle lors du traitement de ladite demande.
Système (S) de mise en œuvre d’un service applicatif dans un réseau de télécommunications, ledit système comprenant une pluralité d’équipements de service impliqués dans la mise en œuvre d’un service applicatif, caractérisé en ce qu’il comprend au moins un dispositif de contrôle (100) selon la revendication 9.
Système (S) selon la revendication 11, caractérisé en ce qu’il comprend au moins un dispositif de traitement (200) d’un message de contrôle d’un accès à un service applicatif selon la revendication 10.
Programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 8, lorsqu’il est exécuté par un processeur.