FR2809513A1 - Controle de qualite de service, notamment de telecommunication - Google Patents

Abstract

L'invention a pour objet un procédé de contrôle de la qualité d'un service (85) incluant au moins un composant technique (86) défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie par un contrat technique (100) entre le fournisseur du service et un client et le contrat (100) incluant des critères de qualité (101) associés à des seuils (102) et relatifs à ladite technologie. Le procédé comprend : une description (S1, S2, S3), faite en un langage de modélisation en technologie orientée objets (UML, XML) et indépendante desdites technologies, de la structure d'un modèle (80) de service, de la structure d'un modèle (90) de contrat et de la structure d'un modèle (110) d'outils de collecte; la construction (S4, S5, S6) d'un modèle de service (80), d'un modèle de contrat (90) et d'au moins un modèle d'outils de collecte (110) à partir des descriptions respectives desdites structures; la construction (S7-S9) du service (85), du contrat (100) et d'au moins un outil (120) de collecte à partir des modèles respectifs (80, 90, 110); la collecte (S10) d'indicateurs de qualité de service (103) au moyen d'au moins ledit outil (120); et la comparaison (S11) des indicateurs de qualité (103) avec les seuils (102) définis dans le contrat (100).

Description

<Desc/Clms Page number 1>

Titre
Contrôle de qualité de service, notamment de télécommunication.

Domaine technique.

L'invention se rapporte à un procédé de contrôle de la qualité d'au moins un service fourni à un client. Elle concerne tout service ayant au moins un composant technique défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie par un contrat technique entre le fournisseur du service et un client. Un tel contrat inclut des critères de qualité associés à des seuils et relatifs à la technologie du service. L'invention sera illustrée par un exemple typique particulièrement contraignant relatif à un service fourni par un opérateur de télécommunications à un client qui peut être une personne physique ou morale. La description de ce service et du contrat associé est réputée complexe et doit s'adapter aux différentes technologies disponibles sur le marché. L'invention se rapporte aussi à des structures génériques respectives de service, de contrat et d'outils de collecte, qui permettent la mise en #uvre du procédé de contrôle de la qualité du service par rapport au contrat défini entre le fournisseur du service et un client.

Grâce aux trois structures modulaires mises en oeuvre par le procédé de contrôle de qualité de service, l'invention peut simplement être mise en #uvre par une structure de service pour la surveillance ou contrôle de service. La surveillance de service est faite pour connaître le ou les services fournis et leurs états. L'invention se rapporte donc aussi à un procédé de surveillance de service.

En outre, surtout lorsqu'un service a de nombreux critères de qualité et impose une surveillance continue, tel qu'un service de télécommunication, le procédé de contrôle nécessite des moyens très réactifs et performants, tels que ceux mis en #uvre pour l'administration d'un système d'information. L'invention se rapporte donc aussi à un système d'administration d'un système d'information, utilisé pour la mise en #uvre du

<Desc/Clms Page number 2>

procédé de contrôle de la qualité d'un service défini par un contrat entre le fournisseur du service et un client.

L'art antérieur.

Le contrôle de la qualité d'un service a pour but principal de vérifier si les critères déterminés dans un contrat lié au service fourni sont satisfaits. Il a pour buts accessoires d'avertir le fournisseur et le client lorsque au moins l'un des critères est en défaut et d'offrir au fournisseur et au client des informations sous forme de rapports. Les rapports peuvent permettre de corriger le service pour respecter le contrat. La correction peut être technique ou contractuelle, par exemple en révisant des critères défaillants. Les rapports peuvent aussi servir à facturer le client en fonction de la qualité de service qui a été fournie.

Le Forum de télé-administration (Telemanagement Forum) classifie les fonctions d'administration des opérateurs de télécommunication en trois domaines relatifs respectivement à la mise en #uvre d'un service (Service Fulfillment), au maintien du service (Service Assurance) et à sa facturation (Billing). La mise en #uvre d'un service peut comprendre une prise d'ordre du service par le client, la conception de l'infrastructure de communication et la configuration des équipements de réseau, et l'activation du service. Le maintien d'un service tel qu'il a été vendu regroupe la surveillance de l'infrastructure de communication et le contrôle de la qualité du service. La facturation d'un service peut être faite en fonction de la qualité du service rendu par l'opérateur.

Dans le domaine des télécommunications, un service est une connexion de bout en bout (de point terminal à point terminal) reposant sur une technologie donnée. Actuellement, une technologie de télécommunication peut être par exemple choisie parmi la technologie de relais de trame (Frame Relay), la technologie temporelle asynchrone connue sous l'acronyme ATM (Asynchronous Transfer Mode) et la technologie utilisant le protocole internet (IP). La qualité du service est définie par un contrat, connu sous l'acronyme SLA (Service Level Agreement), constitué d'un ensemble de critères de

<Desc/Clms Page number 3>

qualité de service appelés critères SLA. Les critères SLA reposent sur des indicateurs de qualité de service, ordinairement appelés indicateurs QoS (Quality of Service). Lors de la définition du contrat, le fournisseur de service et le client s'accordent pour définir un seuil par critère SLA. Le contrôle de la qualité du service comprend la mesure de la qualité et la surveillance du contrat. La surveillance du contrat comprend la comparaison des mesures relatives au service avec les valeurs de seuil définies dans le contrat. Les valeurs des seuils relatifs aux critères SLA d'un contrat définissent un niveau de contrat. En d'autres termes, un niveau de contrat est un contrat définissant pour les critères SLA des valeurs de seuil par défaut qui sont au moins en partie différentes des valeurs définies pour les mêmes seuils d'un autre niveau de contrat.

Le contrôle de la qualité d'un service de télécommunication requiert de nombreuses données dans un domaine technique très diversifié où il faut tenir compte notamment des diverses technologies de télécommunication disponibles, des différents modes de réalisation proposés par les constructeurs d'équipements de réseaux, et des différents moyens possibles de collecte de données nécessaires à la surveillance du contrat.

Chaque technologie, chaque infrastructure de communication et chaque configuration d'équipement de réseau sont définies par de nombreuses caractéristiques. Il en résulte une combinaison de données très élevée et souvent complexe compte tenu des liaisons pouvant exister entre elles et de leur évolution très rapide. À ces données s'ajoutent les nombreuses données liées aux outils de collecte. Par exemple, il faut tenir compte des débits, des horaires et des zones géographiques. De surcroît, il faut que l'opérateur soit très vite averti d'un défaut et soit suffisamment informé sur la nature et les caractéristiques du défaut pour en faire un diagnostic rapide permettant de proposer une correction efficace du service offert. On comprend donc que le contrôle de la qualité de service d'un tel service pose de nombreux problèmes.

Quatre problèmes sont particulièrement importants. Le premier problème est d'assurer un contrôle exhaustif de la qualité du service.

L'exhaustivité doit porter sur tous les critères de qualité de service du contrat

<Desc/Clms Page number 4>

et toutes leurs caractéristiques, la vérification des critères par rapport aux seuils associés, et l'évaluation des défauts détectés lors de la vérification. Elle doit aussi pouvoir évoluer avec une rémanence aussi courte que possible dans ce domaine qui est actuellement en pleine expansion. Le second problème est de faire un contrôle générique de la qualité d'un service. Un contrôle spécialement adapté à un, voire plusieurs types de technologie de télécommunication, d'équipement de réseau et d'outils de collecte de données, peut être vite obsolète dans ce domaine si évolutif et varié. Un contrôle aussi lourd en investissement humain et financier ne peut avoir de pérennité que s'il est suffisamment générique pour pouvoir s'adapter très vite et à moindre frais à une telle évolution. Le troisième problème est d'offrir un contrôle synthétique. Compte tenu de l'énorme masse de données à traiter, des nombreux critères de qualité à mesurer et des défauts susceptibles de se produire, une surveillance non synthétique aurait l'inconvénient de la rendre difficilement exploitable, et même parfois inexploitable si plusieurs défauts se produisent sensiblement en même temps. Le quatrième problème important réside dans un accès facile aux données à traiter et aux données résultant du contrôle de qualité. La surveillance du contrat nécessite un diagnostic rapide et sûr des causes possibles d'un défaut de qualité afin d'y remédier efficacement le plus vite possible. Il faut donc pouvoir accéder facilement aux données concernées par un diagnostic.

Plusieurs systèmes d'administration connus disposent de moyens matériels et logiciels puissants pour pouvoir traiter une forte masse de données pour le contrôle de la qualité de service d'un service aussi riche et complexe qu'est un service de télécommunication. Un exemple qui servira à l'illustration de l'invention est le produit du demandeur connu sous le nom OpenMaster@. C'est un logiciel constituant un système d'administration de systèmes, de réseaux et d'applications. Les grands systèmes d'administration connus à ce jour peuvent traiter le domaine du maintien de service, nommé Service Assurance par le Forum de télé-administration. Cependant, les systèmes d'administration actuels ne peuvent faire qu'un traitement primaire

<Desc/Clms Page number 5>

de données pour surveiller la qualité de service. En d'autres termes, aucun ne peut résoudre au moins l'un des quatre problèmes présentés précédemment.

L'administration pour le contrôle de la qualité d'un service pose aussi un problème qui lui est spécifique. Le but des fournisseurs de produits d'administration et des intégrateurs de produits logiciels est de vendre aux fournisseurs de services, tels que les opérateurs de télécommunication, un produit de contrôle convenant à chacun des opérateurs. Un tel produit doit donc être suffisamment générique pour l'adapter facilement et à peu de frais aux divers opérateurs actuels et à venir. En outre, les intégrateurs souhaitent pouvoir obtenir facilement les informations basiques du fonctionnement d'un produit d'administration destiné au contrôle de la qualité d'un service.

Sommaire de l'invention.

Un premier but de l'invention est d'avoir un procédé adaptable de façon rapide et fiable aux technologies actuelles et futures pour le contrôle de la qualité d'au moins un service. Dans le cas par exemple d'un service fourni par un opérateur de télécommunication, ce but est obtenu si le procédé est indépendant des technologies utilisées par les opérateurs de télécommunication et les constructeurs d'équipements de réseaux et pour les moyens de collecte des données de contrôle.

Un second but est de pouvoir aisément faire un contrôle exhaustif de la qualité d'un service riche en données et en complexité.

Un troisième but est d'offrir une description synthétique des données pour faciliter à la fois l'exploitation des données en vue de la mise en #uvre du procédé de contrôle de la qualité de service, et le diagnostic des défauts rencontrés. Cette facilité d'exploitation présente éventuellement pour le fournisseur l'avantage de pouvoir très vite corriger efficacement les défauts et, par conséquent, de perdre moins d'argent tout en satisfaisant mieux ses clients.

Un quatrième but est de pouvoir adapter les données, qui sont nécessaires au contrôle de la qualité de service, à tout fournisseur de service tout en gardant une même structure des données. Cette adaptation a pour

<Desc/Clms Page number 6>

avantage de pouvoir à peu de frais fournir rapidement à chaque fournisseur un outil d'administration adapté à ses besoins.

Un cinquième but est de guider les intégrateurs de logiciels en leur donnant une structure précise des données nécessaires au contrôle de la qualité de service. Les intégrateurs peuvent ainsi de manière simple et fiable adapter les données nécessaires à chaque fournisseur avec un coût induit minimal.

Un sixième but est de pouvoir simplement faire une surveillance de service, sans mesurer la qualité du service, pour connaître le ou les services fournis et leurs états, de façon indépendante des technologies relatives au service.

L'invention a pour premier objet un procédé de surveillance, au moyen d'au moins un processeur, d'un service incluant au moins un composant technique défini selon une parmi plusieurs technologies possibles, caractérisé en ce qu'il comprend : une description, faite dans des moyens de mémoire en un langage de modélisation en technologie orientée objets et indépendante desdites technologies, de la structure d'un modèle de service ; la construction dans les moyens de mémoire d'un modèle de service à partir de la description de ladite structure ; la construction dans les moyens de mémoire du service à partir du modèle de service ; et la surveillance du service ainsi construit.

L'invention a pour second objet un procédé de contrôle, au moyen d'au moins un processeur et de moyens de mémoire, de la qualité d'un service incluant au moins un composant technique défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie par un contrat technique entre le fournisseur du service et un client et le contrat incluant des critères de qualité associés à des seuils et relatifs à ladite technologie, le procédé étant caractérisé en ce qu'il comprend : une description, faite dans les moyens de mémoire en un langage de modélisation en technologie orientée objets et indépendante desdites technologies, de la structure d'un modèle de service, de la structure d'un modèle de contrat et de la structure d'un modèle d'outils de collecte ; la construction dans les moyens de mémoire d'un modèle

<Desc/Clms Page number 7>

de service, d'un modèle de contrat et d'au moins un modèle d'outils de collecte à partir des descriptions respectives desdites structures ; la construction dans les moyens de mémoire du service, du contrat et d'au moins un outil de collecte à partir des modèles respectifs ; la collecte d'indicateurs de qualité de service au moyen d'au moins ledit outil ; et la comparaison des indicateurs de qualité avec les seuils définis dans le contrat.

L'invention a pour troisième objet une structure de modèle de service pour le contrôle de la qualité de service d'un service incluant au moins un composant technique défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie par un contrat technique entre le fournisseur du service et un client et le contrat incluant des critères associés à des seuils et relatifs à ladite technologie, caractérisée en ce qu'elle est contenue dans des moyens de mémoire et mise en #uvre par au moins un processeur dans les moyens de mémoire conformément au procédé de surveillance de service ou au procédé de contrôle de qualité de service qui ont été définis précédemment.

L'invention a pour quatrième objet une structure d'un modèle de contrat pour le contrôle de la qualité de service d'un service incluant au moins un composant technique défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie par un contrat technique entre le fournisseur du service et un client et le contrat incluant des critères associés à des seuils et relatifs à ladite technologie, caractérisée en ce qu'elle est contenue dans des moyens de mémoire et mise en oeuvre par au moins un processeur dans les moyens de mémoire conformément au procédé de contrôle de qualité de service qui a été défini précédemment.

L'invention a pour cinquième objet une structure d'au moins un modèle d'outils de collecte d'indicateurs de qualité pour le contrôle de la qualité de service d'un service incluant au moins un composant technique défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie d'un contrat technique entre un fournisseur d'un service et un client et le contrat incluant des critères associés à des seuils et relatifs à ladite technologie, caractérisée en ce qu'elle est contenue dans des moyens de

<Desc/Clms Page number 8>

mémoire et mise en #uvre par au moins un processeur dans les moyens de mémoire conformément au procédé de contrôle de qualité de service qui a été défini précédemment.

L'invention a pour sixième objet un système d'administration d'au moins une ressource, comprenant au moins un processeur et des moyens de mémoire et mettant en #uvre un service incluant au moins un composant technique défini selon une parmi plusieurs technologies possibles, le système d'administration incluant dans les moyens de mémoire des indicateurs de qualité servant au contrôle de la qualité de service définie par un contrat technique entre le fournisseur du service et un client et le contrat incluant des critères associés à des seuils et relatifs à ladite technologie, caractérisé en ce qu'il met en #uvre le procédé de surveillance de service ou le procédé de contrôle de qualité de service qui ont été définis précédemment.

Présentation des dessins.

# La figure 1 est une vue synoptique d'un exemple de système d'administration d'au moins une ressource, en l'occurrence un système d'information, le système d'administration mettant en #uvre un procédé de contrôle de la qualité de services fournis par un opérateur de télécommunication à ses clients dans les conditions définies dans des contrats respectifs.

# La figure 2 est une vue synoptique détaillée d'un exemple de structure d'une plate-forme d'administration présente dans le gestionnaire du système d'administration représenté sur la figure 1 et illustre aussi sous forme synoptique des agents servant d'interfaces avec les ressources du système d'information.

# La figure 3 est une vue schématique et très partielle d'un arbre représentatif d'une base d'informations d'administration, dite base MIB (Management Information Base), relative aux objets gérés par le gestionnaire représenté sur les figures 1 et 2.

<Desc/Clms Page number 9>

# La figure 4 est un diagramme illustrant des étapes d'un exemple de procédé de contrôle, par le système d'administration représenté sur les figures 1 et 2, de la qualité d'un service de télécommunication.

# La figure 5 illustre un exemple de structure de la grammaire d'un modèle de service mis en oeuvre par le procédé de l'invention représenté sur la figure 4.

# La figure 6 illustre un exemple de structure de la grammaire d'un modèle
SLA mis en #uvre par le procédé de l'invention représenté sur la figure 4.

# La figure 7 illustre un exemple de structure d'un indicateur de qualité de service mis en #uvre par le procédé de l'invention représenté sur la figure
4.

# La figure 8 illustre un exemple de structure d'un indicateur de performance mis en #uvre par le procédé de l'invention représenté sur la figure 4.

# Et la figure 9 illustre un exemple de structure d'un modèle de description d'outils SLA mis en #uvre par le procédé de l'invention représenté sur la figure 4.

Description détaillée de l'invention.

La figure 1 représente un système d'administration 10 d'un système d'information 11. L'exemple qui suit se rapporte au système d'administration et de sécurité connu sous le nom de marque déposée OpenMaster du demandeur. Sa conception est conforme aux normes ISO de l'administration de systèmes et réseaux. Dans ces conditions, les termes utilisés seront conformes à cette norme, qui sont de langue anglaise, notamment les sigles et acronymes. D'autre part, les verbes "administrer" et "gérer" et leurs dérivés qui seront employés ici traduisent tous deux indifféremment le verbe anglais "manage" et ses dérivés. L'homme du métier connaît bien ces normes. Compte tenu de leur masse informative, on ne donnera ici que les éléments nécessaires à la compréhension de l'invention.

Le système d'information illustré 11 est distribué et se compose de machines 12, en l'occurrence cinq machines 12a-12e, organisées en un ou

<Desc/Clms Page number 10>

plusieurs réseaux 13 correspondant à un ou plusieurs protocoles quelconques, de préférence dédiés à l'administration et normalisés. Dans l'exemple illustré, le réseau 13 utilise le protocole SNMP (Simple Network Management Protocol) et le protocole CMIP (Common Management Information Protocol) reposant sur la norme ISO définissant des services pour le transfert des informations d'administration, appelés services CMIS (Common Management Information Services). Bien sûr, d'autres protocoles pourraient être utilisés, de même que le réseau internet de la Toile.

Une machine est une unité conceptuelle très large, de nature matérielle et logicielle, pouvant être les moyens impliqués pour exécuter une application donnée, des moyens pour exécuter une fonction donnée, un ordinateur, ainsi qu'un système informatique dans une architecture à systèmes en cascade. Les machines 12 peuvent être donc très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées et passerelles entre réseaux. L'exemple choisi suppose que les machines illustrées sont destinées à la surveillance de la qualité de services de télécommunication et incorporent notamment des routeurs.

Le système d'information 11 est ordinairement un système comprenant plusieurs processeurs 14, un processeur 14 étant par exemple illustré dans chaque machine 12, des moyens de mémoire 15 pour contenir les logiciels et les données du système, et des moyens d'entrée-sortie 16 servant pour la communication entre machines par l'intermédiaire du réseau 13, ainsi que pour une ou plusieurs communications extérieures, par exemple pour l'impression, la télécopie, etc. Un tel système peut par exemple gérer des données à distance, distribuer des données, commander l'exécution de programmes à distance sur des machines spécialisées, partager localement des ressources physiques ou logicielles et communiquer. Plus généralement, le système 11 se compose de ressources matérielles et/ou logicielles, réelles ou virtuelles, telles que machines, imprimantes, circuits virtuels, réseaux et applications. Le système d'administration 10 utilise au moins l'une de ces ressources selon une technologie orientée objets, bien connue de l'homme du métier.

<Desc/Clms Page number 11>

Le système d'administration 10 choisi a une architecture de type client-serveur. La partie serveur gère et la partie cliente comprend la ou les ressources à gérer. Dans l'exemple illustré, la partie serveur comprend un gestionnaire 17 inclus dans la machine 12a, dite machine gestionnaire, tandis que la partie cliente comprend une machine 12b de concentration d'agents, dite machine de concentration, et trois agents 18 (18a-18c) permettant l'accès aux ressources à gérer incluses dans les machines respectives 12c-12e, dites machines gérées. Les ressources gérées dans les machines 12c-12e sont identifiées sous forme d'objets organisés dans des sous-arbres respectifs 19 (19a-19c). Dans les machines gérées 12c-12e, les ressources 19a-19c incluent des journaux respectifs 20 (20a-20c) contenant des indicateurs de qualité de service appelés indicateurs QoS. La machine de concentration 12b choisie contient une application de concentration 21 et un journal 22. L'application de concentration 21 est une application de type système d'administration de réseau plus connu sous le nom NMS (Network Management System). Elle est chargée de concentrer dans le journal 22, dit aussi journal NMS, les données contenues dans les journaux locaux 20 et relatives à la surveillance de la qualité des services de télécommunication utilisés dans les machines gérées 12c-12e. Par conséquent, l'application de concentration 21 est reliée, comme le gestionnaire 17, aux agents 18 (18a-18c) par l'intermédiaire du réseau 13.

Elle est aussi reliée par l'intermédiaire du réseau 13 au gestionnaire 17.

Ainsi, pour obtenir les données désirées, le gestionnaire 17 peut accéder directement aux agents 18 et/ou indirectement par l'intermédiaire de la machine de concentration 12b. Par exemple, le gestionnaire 17 peut avoir des données directement des machines gérées 12c et 12d et indirectement de l'ensemble des trois machines gérées 12c-12e par l'intermédiaire de la machine de concentration 12b. Pour faciliter la description, on supposera par la suite que le gestionnaire 17 utilise la machine de concentration 12b pour obtenir l'ensemble des données relatives au contrôle de la qualité des services de télécommunication. La machine de concentration 12b se comporte donc vis- à-vis du gestionnaire 17 comme un agent 18 pour l'ensemble de ces données.

<Desc/Clms Page number 12>

D'une manière générale, le gestionnaire 17 analyse et agit sur l'environnement à gérer. Il répond aux requêtes des utilisateurs en les envoyant à la ressource gérée concernée. Un agent 18, de même que la machine de concentration 12b, est une interface réactive affectée à un protocole donné de communication avec au moins un gestionnaire 17 par l'intermédiaire du réseau associé 13. Il attend et traite les requêtes que le gestionnaire lui adresse. Il gère et met à jour les données contenues dans le sous-arbre correspondant 19 de la machine gérée 12. D'autre part, une ressource peut émettre une réponse à une requête du gestionnaire. Cette réponse est transmise au gestionnaire par un agent. En outre, un objet géré dans une ressource peut émettre des notifications à un agent pour le gestionnaire. Selon la norme ISO, une notification est un message non sollicité par un gestionnaire. La norme définit un événement comme un type de notification, et une alarme comme un type d'événement. Pour des raisons de simplification de la description et des dessins, les trois machines gérées 12c-12e sont seulement pourvues de trois agents respectifs 18a-18c. Selon une option courante et avantageuse du système d'administration 10, un gestionnaire 17 gère aussi la machine gestionnaire 12 correspondante ou, d'une manière plus générale, gère tout ou partie des machines gestionnaires pouvant exister dans le système d'administration. Cela peut se faire de façon similaire à celle illustrée, plus ou moins adaptée à cette option. L'exemple illustré offre le double avantage de faciliter la lecture des dessins tout en permettant à l'homme du métier de faire une généralisation du système décrit et illustré.

La figure 2 illustre la structure d'une plate-forme d'administration 30 du système d'administration 10. La plate-forme 30 est contenue dans la machine gestionnaire 12a et correspond ainsi au gestionnaire 17. Cependant, dans un système d'administration à plusieurs gestionnaires, la plate-forme 30 pourrait être distribuée parmi tout ou partie d'entre eux. La plate-forme 30 se compose de deux ensembles 40 et 50.

L'ensemble 40 contient un bloc 41 contenant un ensemble d'applications 42 connectées à un tableau de bord 43. Les applications peuvent être écrites

<Desc/Clms Page number 13>

dans un ou plusieurs langages, le langage Java@ dans la plate-forme OpenMaster du demandeur. Le tableau de bord 43 est classique et inclut une partie graphique et un lanceur de requêtes. Une station graphique 44, extérieure à la plate-forme 30, est connectée au tableau de bord 43 pour visualiser les applications 42, lancer les requêtes et visualiser les résultats contenus dans les réponses. Elle permet à un utilisateur de se connecter à la machine 12a pour démarrer et arrêter comme il le désire ses propres copies des applications 42. L'ensemble 40 comporte des moyens 45 d'interface et, dans le bloc 41, une base de données 46 constituant un inventaire des services de télécommunication utilisés dans le système d'information 10 et un référentiel 47 constituant aussi une base de données. L'inventaire 46 et le référentiel 47 sont reliés à une application 42 dédiée au contrôle de qualité des services de télécommunication contenus dans l'inventaire 46. L'ensemble 40 peut former une unité autonome délimitée par un trait fantôme et constitutive d'une station d'administration.

Dans le cas où l'ensemble 40 constitue une station d'administration, l'ensemble 50 forme un serveur d'administration. Le serveur 50 utilise un seul protocole donné, ici le protocole CMIP. Il comprend trois blocs fonctionnels : un bloc de communication 51 aussi appelé courtier CMIP ou distributeur de services CMIS (CMIS Dispatcher) ; un bloc 60 de services CMIS ; etun bloc 70 d'interface de la plate-forme 30 avec la machine de concentration 12b et les agents 18a et 18b des ressources gérées directement par la plate-forme. Le courtier 51 est connecté aux moyens d'interface 45 de la station 40, ainsi qu'aux blocs 60 et 70 du serveur 50, pour traiter les requêtes et leurs réponses éventuelles, ainsi que les notifications en provenance des agents 18a et 18b et de la machine de concentration 12b.

Le courtier 51 contient l'objet racine ROOT à laquelle sont attachés tous les objets gérés par la plate-forme 30. Le bloc 60 contient tous les services communs aux applications 42, notamment : une base CMIS-DB 61 de données CMIS ; un service 62 de schémas d'informations d'administration, appelé MISS (Management Information schéma Service) contenant les schémas, aussi dits classes, des objets gérés par la plate-forme ; un service 63 de

<Desc/Clms Page number 14>

traitement des événements (Event Processor) ; un service 64 d'alarmes incorporant un journal 65 d'alarmes (Alarm Log) ; etun service 66 de rapports et performances incorporant un journal 67 et utilisé pour les applications 42 de performances et plus particulièrement par l'application de contrôle 42 pour évaluer les performances du contrat et faire des rapports. Le bloc 70 illustré inclut deux interfaces 71a et 71b qui sont, dans l'exemple choisi, reliées respectivement par l'intermédiaire du réseau 13 d'une part à l'agent 18a et d'autre part à la machine de concentration 12b et l'agent 18b et sont ordinairement nommées intégrateurs (d'agents) ou AI (Agent Integrators). Plusieurs ensembles d'agents 18a et 18b extérieurs à la plateforme 30 sont illustrés pour indiquer qu'en pratique tout ou partie des agents peuvent gérer des objets distribués dans le système d'information et se trouver dans plusieurs machines 12 du système d'information 11, une machine pouvant incorporer plusieurs agents utilisant des protocoles différents.

La figure 3 illustre de façon schématique et très partielle un exemple de structure d'une base MIB des objets qui sont gérés par la plateforme 30 constituant le gestionnaire 17 du système d'administration 10 et qui sont représentatifs d'au moins une ressource du système d'information 11.

Les ressources gérées sont converties en classes d'objets organisées hiérarchiquement dans une base d'informations d'administration MIB (Management Information Base). Cette base n'est pas une base de données proprement dite, mais est assimilable à un catalogue de caractéristiques puisqu'elle contient la description et le contenu de toutes les classes gérées par le système d'administration 10. Une classe est définie par des caractéristiques nommées attributs, tels qu'un nom d'un composant du système et un état d'impression. Un objet d'une classe est une instance de la classe. L'organisation des classes dans l'exemple choisi du système d'administration 10 est hiérarchique. On distingue l'arbre des classes, une classe étant définie en subordination à une ou plusieurs classes mères, et l'arbre des instances, une instance étant attachée à une ou plusieurs instances mères. L'arbre des classes est contenu dans le service MISS 62,

<Desc/Clms Page number 15>

tandis que l'arbre des instances est l'arbre correspondant à la base MIB telle que représentée sur la figure 3. Dans la base MIB, les objets sont divisés en classes d'objets gérés, dites classes MOC (Managed Object Class). Un objet géré est une vue abstraite, définie pour les besoins de la gestion, d'une ressource logique ou physique d'un système. Chaque classe MOC représente un type donné desdits moyens du système 11. À chaque classe MOC peuvent être attachées une ou plusieurs instances d'objets gérés, appelées instances MOI (Managed Object Instance) et représentant des occurrences actuelles desdits moyens.

Tous les objets de la base MIB dans la figure 3 sont placés sous la racine ROOT et sont répartis en sous-MIB appelées par la suite modules de MIB. La racine ROOT est contenue dans le courtier 51 et les racines des modules de MIB sont appelées sous-racines (rootlets). La figure 3 illustre deux modules de MIB représentatifs des deux machines gérées 12c et 12d par le gestionnaire 17 et correspondant aux deux sous-arbres respectifs 19a et 19b, et un module de MIB représentatif de la machine de concentration 12b.

On a vu précédemment que les sous-arbres 19a et 19b incluent les journaux respectifs 20a et 20b. La machine de concentration 12b ayant été considérée précédemment comme un agent, elle est une sous-racine à laquelle sont attachés comme sous-modules les sous-arbres respectifs 19a-19c.

Cependant, la machine de concentration 12b peut ne pas être un agent. Dans ce cas, la machine de concentration 12b ainsi que les trois sousmodules 19a-19c n'apparaîtraient pas dans la base MIB de la figure 3. La machine de concentration 12b n'aurait alors pour fonction que de collecter les données dans les journaux 20a-c des trois machines gérées 12c-12e. Il suffirait alors au gestionnaire 17 de demander à la machine de concentration de lui transmettre les données collectées. Ce cas est dans la pratique plus simple et correspond à celui choisi pour la mise en #uvre du procédé de contrôle de qualité de service conforme à l'invention. La figure 3 offre l'avantage d'illustrer une variante possible.

En pratique également, sous la racine ROOT de la base MIB est aussi attachée une sous-racine (non illustrée) pour chaque service du bloc 60.

<Desc/Clms Page number 16>

Dans ce bloc, le service CMIS-DB 61 fournit une base de données des objets gérés MOI destinée à leur persistance une fois que le gestionnaire a été mis hors fonctionnement. Il supporte toutes les classes MOC des services CMIS qui sont stockées localement dans une base de données. En outre, il fournit un ensemble de services ou fonctions de base, appelées aussi primitives, disponibles pour toutes les applications 42. Ces fonctions sont bien adaptées à la structure hiérarchique de la base MIB. Elles incluent notamment les fonctions : M-GET pour lire une ou plusieurs instances, M-SET pour mettre à jour une ou plusieurs instances, M-CREATE pour créer une instance, MACTION pour activer une opération spécifique sur une ou plusieurs instances et M-EVENT pour envoyer un événement.

Le système d'administration 10 sert d'exemple de support pour la mise en #uvre du procédé de contrôle de la qualité d'un service fourni par un opérateur de télécommunication à un client dans les conditions définies dans un contrat et tel que défini dans l'introduction de la présente demande. Un client peut être quelconque, une personne ou une société, celle-ci pouvant être un autre opérateur. On a vu en introduction qu'un système d'administration 10 classique fournit les fonctions de base pour assurer le maintien du service. Le système d'administration 10 illustré, enrichi de l'invention, offre au fournisseur de services de télécommunication l'avantage de saisir à partir de modèles adéquats, les services à surveiller, les contrats de qualité de service passés entre lui et ses clients sur ces services, et la description de la manière de contrôler la qualité de service. Il permet aussi de générer des rapports de surveillance sur les services fournis, de manière à offrir aux clients une vue restreinte et sécurisée.

La figure 4 est un diagramme illustrant un exemple de structure du procédé de contrôle, à l'aide du système d'administration 10, de la qualité d'un service de télécommunication mis en #uvre dans le système d'information 11. Les services de télécommunication offerts par l'opérateur sont contenus dans l'inventaire 46 (figure 2), où sont identifiés les services, les clients et les contrats correspondants. Le procédé illustré dans la figure 4 pour le contrôle de la qualité d'un service, un service étant défini selon une

<Desc/Clms Page number 17>

parmi plusieurs technologies possibles, commence à une étape SO et comprend trois étapes de description SI, S2 et S3. Ces trois étapes décrivent, en un langage de modélisation en technologie objet et indépendante des technologies possibles pour la mise en #uvre du service, trois structures respectives, à savoir une structure de modèle de service, une structure de modèle de contrat et une structure de modèle d'outils de collecte.

Le procédé de la figure 4 se poursuit par trois étapes S4, S5 et S6 de construction respective d'un modèle 80 d'un service relatif à une technologie donnée, d'un modèle 90 d'un contrat relatif à cette technologie et servant à définir le contrat 100 spécifique entre le fournisseur et un client, et d'au moins un modèle 110 d'outil de collecte, à partir des trois étapes respectives de description générique SI, S2 et S3. Ainsi, un fournisseur de service peut, d'après les trois structures décrites précédemment, créer autant de modèles de service, de modèles SLA et de modèles de description d'outils SLA qu'il souhaite. Tous ces modèles respectent les structures définies dans leurs grammaires respectives. L'ensemble des modèles 80,90 et 110 est contenu dans le référentiel 47 (figure 2).

Plus précisément, la structure d'un modèle de service est décrite sous forme générique au moyen d'une grammaire de modèle de service. La description est générique en ce sens qu'elle est indépendante de la technologie et de l'infrastructure de communication. La description d'une structure de modèle de service permet de définir lors de l'étape S4 au moins un modèle de service 80, qui respecte donc la grammaire générique de modèle de service, quelle que soit la technologie concernée. Dans l'exemple illustré, un modèle de service 80 inclut au moins un modèle 81 de type de composant et un modèle 82 de paramètres. Les modèles de service 80 enrichissent le référentiel 47 du procédé de contrôle de qualité par des données permettant de décrire la structure d'un service à surveiller.

De même, la structure de modèle d'un contrat, appelé aussi modèle SLA est décrite sous forme générique au moyen d'une grammaire de modèle SLA. La structure de modèle de contrat permet de définir lors de l'étape S5 au moins un modèle de contrat 90, aussi appelé modèle SLA.

<Desc/Clms Page number 18>

Chaque critère SLA qui compose un contrat et qui est défini dans la structure sous la forme générique, c'est-à-dire indépendante de la technologie, est appelé dans le modèle SLA 90 un prototype 91 de critère SLA. Dans un modèle SLA 90, chaque prototype 91 est relié à au moins un modèle 92 de seuil et à un seul modèle 93 d'indicateur QoS. Le modèle SLA peut aussi inclure en option, comme illustré, au moins un modèle 94 de rapports à générer. Un modèle SLA 90 créé lors de l'étape S5 respecte donc la grammaire générique de la structure de modèle SLA, quelle que soit la technologie concernée par le modèle SLA. Les modèles SLA 90 enrichissent le référentiel 47 du procédé de contrôle de qualité pour différentes technologies, selon les besoins du fournisseur.

De même encore, la structure d'un modèle d'outils de collecte de données utilisables pour vérifier les critères SLA est décrite sous forme générique au moyen d'une grammaire de description d'outils SLA. Dans ce cas, la description générique signifie qu'elle est indépendante des technologies utilisées par les opérateurs et les équipementiers. La structure de modèle d'outils de collecte qui est décrite au moyen de la grammaire de description d'outils SLA permet de définir lors de l'étape S6 au moins un modèle 110 d'outils SLA. Ainsi, la création d'un modèle 110 d'outils SLA respecte la grammaire générique, quelle que soit la technologie, l'équipement et le modèle SLA concernés. Les modèles 110 d'outils SLA enrichissent le référentiel 47 du procédé de contrôle de qualité par des données permettant de configurer automatiquement un produit d'administration de façon à mettre en #uvre le contrôle de qualité des services.

Il est à noter qu'un modèle 110 d'outils SLA s'appuie sur l'infrastructure d'un service défini pour une technologie donnée avec des types de composants spécifiques. L'infrastructure de ce service est représentée sous forme d'un modèle de service dépendant des types d'équipements constituant son infrastructure. Ainsi, un modèle 110 d'outils SLA est totalement dépendant d'un modèle SLA 90 et d'un modèle 80 de service. En conséquence, un modèle 110 d'outils SLA ne peut être installé que si le modèle 90 de

<Desc/Clms Page number 19>

contrat et le modèle 80 de service auquel il se rapporte ont déjà été installés dans le système d'administration.

En résumé, l'invention propose donc trois grammaires pour décrire les trois structures lors des étapes SI, S2 et S3 du procédé, à savoir : - une grammaire de modèle de service pour décrire la structure d'un modèle de service à fournir qui, dans le domaine des télécommunications, est une connexion de bout en bout utilisant une technologie donnée et des types d'équipements fournis par différents constructeurs. Cette grammaire peut par exemple définir des types de points terminaux aux deux bouts de la connexion et des paramètres, notamment des paramètres de trafic ; - une grammaire de modèle SLA pour décrire la structure d'un modèle de contrat passé entre un client et un opérateur de télécommunications, la description concernant un ensemble de critères SLA du contrat et, en option, un ensemble de modèles de rapports à générer ; et - une grammaire de description d'outils SLA pour décrire un modèle de configuration des outils utilisables pour vérifier la conformité du contrat. Ces outils peuvent être des outils de collecte d'indicateurs ou bien d'autres outils intervenant dans le procédé de contrôle de qualité. La description de la configuration de ces outils doit permettre de pré-configurer ces outils de manière automatique avec les éléments de configuration dont ils ont besoin lors de leur exécution.

Ces trois grammaires résultent d'un choix des données à traiter.

La description de la structure de ces grammaires est faite en langage unifié de modélisation UML (Unified Modeling Language) actuellement bien adapté à la description d'objets dans la technologie orientée objets. Les trois grammaires spécifiées en UML sont implémentées en langage XML sous la forme de trois fichiers. Le langage XML (eXtensible Markup Language) est un langage de description et d'échange de documents structurés. Il permet de décrire la structure logique de documents à l'aide d'un système de balises permettant de marquer les éléments qui composent la structure, et les relations entre ces éléments. Le langage XML distingue deux classes de documents : les documents bien formés et les documents valides. Un

<Desc/Clms Page number 20>

document est dit bien formé lorsqu'il obéit aux règles syntaxiques du langage XML. Il peut donc être traité avec succès par un processeur adéquat, et notamment par un analyseur (parser) XML. Un document est dit valide lorsqu'il est bien formé et qu'il obéit en outre à une structure type définie explicitement dans une grammaire appelée DTD (Document Type Définition).

Le procédé de contrôle de qualité de service qui est représenté sur la figure 4 se poursuit par trois étapes S7, S8 et S9 illustré par des flèches et partant des trois modèles respectifs 80,90 et 110. Les étapes S7, S8 et S9 se rapportent à la construction notamment du service désiré 85, du contrat désiré 100 et d'au moins un outil de collecte 120 nécessaire au contrôle de la qualité définie par le contrat 100. En d'autres termes, les étapes S7, S8 et S9 permettent de construire plusieurs services 85, plusieurs contrats 100 et plusieurs outils de collecte 120 à partir des modèles respectifs 80,90 et 110.

Le service 85 contient des composants 86 et, optionnellement, des paramètres 87, pouvant par exemple inclure des paramètres de trafic dans le cas d'un service de télécommunication. Les composants 86 sont issus des modèles 81 de type de composant du modèle 80 de service tandis que les paramètres 87 sont issus du modèle de paramètre 82 du modèle 80. Le contrat 100 définit notamment : les critères SLA 101, construits à partir des prototypes de critère SLA respectifs 91 ; valeurs des seuils 102 issues d'au moins le modèle de seuil 92 ; et les indicateurs QoS 103 relatifs aux critères SLA 101 et construits à partir des modèles d'indicateur QoS respectifs 93. De même, les modèles 110 d'outils de collecte servent à définir des outils 120 de collecte des indicateurs QoS nécessaires au contrôle de la qualité du service défini par le contrat 100.

Le procédé de contrôle de la qualité du service ainsi défini inclut aussi : une étape S10 de collecte d'indicateurs QoS conformément aux indicateurs QoS 103 du contrat 100 et au moyen d'au moins un outil de collecte 120 ; une étape S11 de comparaison des indicateurs QoS avec les seuils correspondants 102 définis dans le contrat 100 ; et, selon l'option choisie, une étape S12 de rapports établis en l'occurrence selon les modèles 94 de rapport qui existent dans le modèle de contr at 90 et aussi contenus dans le

<Desc/Clms Page number 21>

contrat 100 et non illustrés dans le contrat 100 pour des raisons de clarté des dessins. Le procédé illustré prend fin à l'étape S13.

La figure 5 illustre la structure d'un modèle 80 de service, qui met en oeuvre dans l'étape SI du procédé une grammaire de description d'un modèle de service. Le modèle 80 de service illustré comprend au moins un modèle de type de composant, en l'occurrence relatif aux divers types de composants 81 pouvant constituer l'infrastructure d'une connexion de télécommunication, et un modèle 82 de paramètre. À partir du modèle 80 de service est défini un service 85 en spécifiant les composants 86 et en donnant les paramètres 86 de configuration du trafic. Le modèle 80 d'un service de télécommunication 85 est décrit par une classe ServicePackage qui possède les attributs : # name désignant le nom du modèle de service ; # version désignant la version du modèle de service ; # serviceType désignant le type de service du modèle ; et # iconName désignant le nom de l'icône représentant un service.

La classe ServicePackage inclut les différents types de composants 81 utilisables pour le modèle de service 80. Ces types sont regroupés en trois catégories.

La première catégorie représente les points terminaux du service dans une classe EndPoints. Ces points représentent dans le réseau les composants d'entrée et de sortie du service. Lors de la création du service, ces composants devront être définis en nombre et en type tels que décrits dans le modèle. Ces points sont indispensables à la définition du service de télécommunication 85 choisi comme exemple.

La deuxième catégorie représente des points intermédiaires du service dans une classe IntermediatePoints. Ces points représentent des composants de réseau intermédiaires sur lesquels s'appuie la connexion. Le modèle donne uniquement l'ensemble des types possibles, mais n'indique pas de nombre de composants à définir pour chaque type. Ce nombre varie d'un service à l'autre et peut être nul. Cette catégorie est donc optionnelle.

<Desc/Clms Page number 22>

La troisième catégorie représente les composants applicatifs du service dans une classe Applications. Ces composants représentent les points sur lesquels se trouvent des applications impliquées dans le service, telles qu'une application de facturation. Cette catégorie est donc optionnelle.

Ces trois catégories de composants reposent sur la même description du type de composants, définie dans une classe ComponentType. La classe ComponentType possède les attributs : # ident désignant l'identifiant du type du composant ; # theoreticalMeasurementPoint désignant le point de mesure théorique du composant conformément à un type TheoreticalPointEnum d'énumération des points de mesures théoriques qui peuvent être le point d'entrée du service (pointA), le point de sortie du service (pointZ) ou un point intermédiaire du service (point!) ; et, en option, # ptMeasurementType désignant le type de point de mesure du composant conformément à un type PtMeasurementTypeEnum d'énumération des types de point de mesure qui peuvent être une connexion (connection), un point terminal (endPoint) ou un port logique (logicalPort).

La classe ComponentType inclut au moins un module de MIB supporté par le composant et décrit dans une classe Mib. La classe Mib possède les attributs : # name désignant le nom du répertoire contenant le module de MIB selon les règles imposées par le système d'administration 10 ; # logicalName désignant le nom logique du module de MIB utilisé par le système d'administration 10 ; et# oid désignant l'identifiant de l'objet de plus haut niveau défini dans le module de MIB. L'identifiant "oid" (Object Identifier) est attribué de façon unique dans le monde suivant une arborescence d'autorités d'adressage définie par l'Organisme de Standardisation International appelé ISO (International Standards Organization).

<Desc/Clms Page number 23>

La classe ComponentType inclut aussi, en option, les paramètres nécessaires pour représenter le composant dans une classe MibAttribute. La classe MibAttribute possède les attributs : # label désignant le nom de l'attribut du module de MIB ; # unit désignant le type de l'attribut du module de MIB ; # description désignant la description de l'attribut du module de MIB ; et# request désignant la requête CMIS permettant de parcourir le module de
MIB du composant concerné pour accéder directement à l'attribut.

La classe ServicePackage inclut aussi, en options : # une liste de paramètres, incluant des paramètres de trafic dans l'exemple illustré, définie dans une classe Parameters ; # un module de MIB décrit dans une classe ConfigurationMib et permettant de parcourir les paramètres de trafic ; # un fichier de requêtes CMIS à installer, décrit dans une classe
ExportedRequests. Ces requêtes sont utilisées pour accéder directement aux paramètres de trafic définis par la classe Parameters ou aux paramètres spécifiques des composants définis par la classe
MibAttribute ; et # une application tierce, dite aussi application partenaire, de mise en #uvre du service, utilisée pour le modèle de service et décrite dans une classe
IntegratedAppli. Alors que l'application 42 de mise en #uvre du procédé est conçue pour le système d'administration OpenMaster du demandeur, une application partenaire est une application conçue pour un autre système.

La classe Parameters contient au moins un paramètre décrit dans une classe Parameter qui peut être reliée, comme représenté, à la classe MibAttribute représentant un attribut interrogeable sur un composant du service. La classe Parameter possède les attributs : # name désignant le nom du paramètre de trafic ; # description désignant la description du paramètre désigné par name ; et, en option,

<Desc/Clms Page number 24>

# defauItValue désignant une valeur par défaut pour ce paramètre.

La classe ConfigurationMib contient le module de MIB nécessaire à la navigation parmi les paramètres et qui est décrit dans la classe Mib.

La classe ExportedRequests contient le fichier de requêtes CMIS à installer qui est décrit dans une classe File. La classe File décrit un fichier à traiter suivant son type et possède les attributs : # name désignant le nom du fichier ; et, en option, # dir désignant le répertoire de destination du fichier ; et # type désignant le type du fichier conformément à un type
FileTypeEnum d'énumération des différents types de fichier possibles qui peuvent être un fichier ASCII à copier (CopyFile), un fichier décrivant des indicateurs à collecter (CollectFile), un fichier décrivant des filtres d'alarmes (AlarmFilterFile), un fichier ASCII d'export d'une base de requêtes CMIS à importer (ImportCMISFile), un fichier à exécuter (ExecuteFile), un fichier de démarrage de la collecte des données (StartCollectFile) et un fichier d'arrêt de la collecte des données (StopCollectFile), ou un fichier IDL (IDLFile).

Enfin, la classe IntegratedAppli contient la description de l'application partenaire utilisable pour ce modèle de service et possède l'attribut name désignant le nom de l'application partenaire. Cette classe contient au moins un fichier décrit dans la classe File.

La grammaire de description d'un modèle 80 de service, qui est illustrée dans la figure 5 et décrite en langage UML lors de l'étape SI du procédé, est implémentée lors de cette même étape SI en langage XML et est alors appelée grammaire DTD (Document Type Définition). L'annexe 1 illustre le fichier XML correspondant à la grammaire DTD d'un modèle 80 de service. Pour faire la traduction, des règles de génération de la grammaire DTD ont été appliquées au modèle UML qui a été défini précédemment. Pour générer la grammaire DTD à partir de la précédente description, on a procédé ainsi : - une classe de la description est traduite en ELEMENT et se lit tel que :

<Desc/Clms Page number 25>

<ELEMENT ServicePackage (...)> - un attribut de classe est traduit en un attribut de l'élément, tel que l'attribut ATTLIST dans : <ATTLIST ServicePackage version ...> - une association ou une agrégation se traduit par un sous-élément de l'élément en cours, comme Parameters dans l'exemple suivant : <ELEMENT ServicePackage (Parameters)> - et la cardinalité de l'association ou de l'agrégation précise le nombre d'occurrences du sous-élément de la façon suivante : - si 0 ou 1 : parun point d'interrogation ? tel que : <ELEMENT ServicePackage (Parameters?)> - si 1 et plus : par le signe + tel que : <ELEMENT ServicePackage (Parameters+)> - et si 0 ou plus : par le signe * tel que : <ELEMENT ServicePackage (Parameters*)>.

L'annexe 2 illustre un exemple de modèle de service 80 créé lors de l'étape S4 conformément à la grammaire DTD de service décrite dans l'annexe 1. Le modèle de service 80 illustré s'applique à la technologie à relais de trame (Frame Relay).

La figure 6 illustre la structure d'un modèle 90 de contrat, aussi appelé modèle SLA 90, qui utilise la grammaire de description d'un modèle SLA lors de l'étape S2 du procédé. À partir du modèle SLA 90 est généré à l'étape SU le contrat 100 entre le fournisseur de service et le client. Comme indiqué à la figure 4, le contrat 100 inclut principalement des critères SLA 101, qui sont les objets du contrôle de la qualité du service et qui sont définis à partir d'au moins un prototype 91 de critère SLA. Un prototype 91 de critère SLA est défini comme un modèle relatif à un critère SLA pour une technologie donnée. Le modèle SLA 90 est décrit par une classe SlaPackage qui possède les attributs : # level désignant un niveau de contrat pour la technologie utilisée ; # version désignant une version du modèle SLA ; et # serviceType désignant un type de service.

<Desc/Clms Page number 26>

La classe SlaPackage contient au moins un prototype 91 de critère SLA, représenté par une classe SlaCriteriaPrototype et, en option, au moins un ensemble de modèles 94 de rapport à générer, inclus dans une classe ReportModels. La classe ReportModels regroupe tous les modèles 94 de rapports à générer pour toutes les cibles de destinataires. Un ensemble de modèles de rapport 94 est défini pour chaque cible de destinataires. La classe ReportModels contient, par agrégation, un ou plusieurs ensembles de modèles de rapport à générer par cible de destinataires. Ces modèles sont représentés par une classe ReportPackage, qui représente donc un ensemble de modèles de rapports à générer pour un type de destinataire donné. Elle possède les attributs : # name désignant un nom d'une ensemble de modèles de rapport pour une cible de destinataires définie par l'attribut target ; # dir désignant un répertoire d'installation de l'ensemble des modèles de rapport désigné par name ; et # target désignant une cible de l'ensemble des modèle de rapport, c'est-à- dire le type d'utilisateur visé conformément à un type d'énumération
TargetEnum qui définit les cibles possibles des modèles de rapports à générer pouvant être l'entité de facturation (billing), l'entité de réseau (network), l'entité de fourniture du service (provisioning) ou l'entité financière (financial).

La classe SlaCriteriaPrototype contient un unique modèle d'indicateur QoS 93 représenté par la classe Qoslndicator et, par agrégation, au moins une règle de déclenchement d'actions sur franchissement de seuil représentée par la classe TriggerRule. La classe SlaCriteriaPrototype possède un attribut task désignant le nom de la tâche à déclencher sur franchissement de seuil. Un indicateur QoS 103 peut être, en technologie de relais de trame, le temps moyen de résolution des incidents, temps connu sous le nom de MTTR (Mean Time To Repair) ou bien le taux de trames délivrées, taux connu sous le nom de FDR (Frame Delivery Ratio). La classe QoSIndicator possède les attributs : # name désignant un nom d'un modèle d'indicateur QoS ;

<Desc/Clms Page number 27>

# slaOperator désignant un opérateur arithmétique par défaut, valide pour un indicateur QoS conformément à un type d'énumération
OperatorEnum qui définit des opérateurs arithmétiques de supériorité (>, #), d'infériorité (<, #) et d'égalité (=) ; et, en option, # ptMeasurementType (défini aussi dans la classe ComponentType à la figure 4) désignant le type du point de mesure sur lequel porte un indicateur QoS conformément au type d'énumération
PtMeasurementTypeEnum qui définit des types de point de mesure de l'indicateur pouvant être une connexion (connection), un point terminal (endPoint) ou un port logique (logicalPort).

En pratique, un indicateur QoS 103 est mesuré selon une fréquence variable et est comparé avec un seuil 102, suivant l'un des opérateurs arithmétiques, pour prévenir le client lorsque cet opérateur est vérifié. Pour commodité, on dira que le seuil 102 est franchi lorsque l'opérateur correspondant est vérifié. Il est possible de positionner plusieurs seuils supplémentaires en définissant autant de règles de déclenchement que de seuils positionnés, mais seul le premier seuil est contractuel. Ainsi, en ajoutant, par exemple, un ou plusieurs seuils préliminaires, il est possible d'avertir le client de l'approche ou de l'imminence de la condition choisie.

La classe TriggerRule représente les règles de déclenchement d'actions sur franchissement de seuil d'un critère SLA et possède les attributs : # threshold désignant un seuil de critère SLA à surveiller ; et, en option, # validityPeriod désignant une période de validité d'un seuil conformément à un type ValidityEnum d'énumération des périodes de validité possibles pour un seuil, en l'occurrence une période rouge (red) pour des horaires correspondant à un trafic intense, une période bleue (blue) pour des horaires correspondant à un trafic normal et une période blanche (white) pour des horaires correspondant à un trafic faible.

Un seul seuil 102 étant associé à une règle de déclenchement, il existe donc autant de règles de déclenchement que de seuils à surveiller.

Dans l'exemple illustré, les actions à déclencher sur franchissement du seuil

<Desc/Clms Page number 28>

sont effectuées par le service 63 contenu dans la plate-forme 30 représentée sur la figure 2 et utilisé pour la gestion de tâches du système d'administration 10. Sur franchissement du seuil pour un indicateur donné, une alarme est envoyée au service 63 de traitement d'événements, mis en attente de cette alarme. À la réception de cette alarme, le service 63 active la tâche concernée pour déclencher au moins une action liée au seuil franchi et pouvant être exemple un envoi de courrier électronique et la génération de rapports.

La figure 7 illustre un exemple de structure d'un modèle 93 d'indicateur QoS, défini par la classe Qoslndicator qui contient : # une description textuelle de l'indicateur, définie dans une classe
Description ; # au moins une unité valide pour cet indicateur, en l'occurrence choisie parmi les quatre unités représentées par quatre classes relatives respectivement aux types d'unité de pourcentage PercentUnit, de temps
TimeUnit, d'objet ObjectUnit et de débit ThroughputUnit, et # au moins un et au plus deux modes de collecte de l'indicateur QoS, relatifs respectivement aux deux sens possibles de flux de données et modélisés par une classe WayToComputeQoS. Chaque mode de collecte est associé à au moins une règle de calcul par outil de collecte, qui est représentée par une classe Computation. Une règle de calcul peut utiliser des paramètres représentés par des indicateurs de performance dans une classe
Performancelndicator.

La classe PercentUnit décrit une unité de type pourcentage et possède un attribut type désignant l'unité de type pourcentage choisie. La valeur de cet attribut doit être conforme à un type PercentUnitEnum d'énumération des unités de pourcentage possibles, en l'occurrence %.

La classe TimeUnit décrit une unité de type temps et possède un attribut type désignant l'unité de type temps choisie. La valeur de cet attribut doit être conforme à un type TimeUnitEnum d'énumération des unités de temps possibles, en l'occurrence la microseconde ( s), la milliseconde (ms), la seconde (s), la minute (m) et l'heure (h).

<Desc/Clms Page number 29>

La classe ObjectUnit décrit une unité de type objet et possède un attribut type désignant l'unité de type objet choisie. La valeur de cet attribut doit être conforme à un type ObjectUnitEnum d'énumération des unités d'objets possibles, en l'occurrence les bits (bits), kilobits (kbits), octets (bytes), kilooctets (kb), mégaoctets (Mb), gigaoctets (Gb), trame (Frame) incident (Incident) et flux (Flow).

La classe ThroughputUnit décrit une unité de type débit et possède un attribut type désignant l'unité de type débit choisie. La valeur de cet attribut doit être conforme à un type ThroughputUnitEnum d'énumération des unités de débit possibles, en l'occurrence les bits par seconde (bits/s), octets par seconde (bytes/s), kilooctets par seconde (kb/s), paquets par seconde (packet/s) et flux par seconde (Flow/s).

Le calcul d'un indicateur QoS peut être fait dans les deux sens de flux de données de la connexion, et de manière différente selon le sens. La classe WayToComputeQoS possède un attribut dataFlow représentatif du sens du flux de données conformément à un type FlowEnum d'énumération des sens possibles pouvant être, pour une connexion entre deux points terminaux A et Z, les sens A-Z et Z-A (A-Z, Z-A), et pour un port, les sens de réception R et d'émission T (R, T);
La classe Computation décrit une règle de calcul/récupération d'un indicateur, la règle étant décrite dans une méthode et la classe possédant les attributs : # toolName désignant le nom de l'outil utilisé par la méthode ; et, en option, # methodName désignant le nom de la méthode permettant de faire le calcul/récupération de l'indicateur et impliquant alors les attributs : # methodFile désignant le fichier contenant le nom de la méthode methodName ; et # methodFileDir désignant le répertoire d'installation du fichier désigné par methodFile. En l'occurrence, ce répertoire (non illustré) se trouve dans le gestionnaire 17.

<Desc/Clms Page number 30>

La figure 8 illustre un exemple de structure d'un indicateur de performance défini par la classe PerformanceIndicator représentée sur la figure 7. Contrairement à un indicateur QoS qui s'applique à une connexion de bout en bout et est soumis à un seuil contractuel, un indicateur de performance s'applique à un équipement de réseau et n'est pas soumis à un seuil contractuel. Un indicateur QoS portant sur une connexion, c'est-à-dire sur un ensemble d'équipements de réseau, il peut être l'agrégation de plusieurs indicateurs de performance. C'est pourquoi le mode de calcul d'un indicateur QoS peut inclure en paramètres des indicateurs de performance.

L'indicateur de performance illustré dans les figures 7 et 8 est décrit par la classe Performancelndicator, qui possède les attributs : # name désignant le nom de l'indicateur de performance ; # type désignant le type de l'indicateur conformément à un type
IndicatorTypeEnum d'énumération des types d'indicateur, en l'occurrence un type d'indicateur basique (basic) et un type d'indicateur calculé (computed). Un indicateur basique est calculé par un outil de collecte alors qu'un indicateur calculé est agrégé à partir d'autres indicateurs ; et # ptMeasurementType désignant le type de point de mesure sur lequel porte un indicateur de performance conformément au type d'énumération
PtMeasurementTypeEnum.

La classe PerformanceIndicator contient : # nécessairement une description textuelle de l'indicateur, définie dans la classe Description représentée aussi sur la figure 6 ; # au moins une unité valide, en l'occurrence choisie parmi les quatre unités représentées par les classes PercentUnit, TimeUnit, ObjectUnit et
ThroughputUnit ; et # au moins un et au plus deux modes de collecte de l'indicateur de performance selon le sens du flux des données.

Le mode de collecte est modélisé par une classe WayToComputePerf qui possède l'attribut dataFlow désignant un sens de

<Desc/Clms Page number 31>

flux de données conformément au type d'énumération FlowEnum. Comme pour un indicateur QoS 103, le calcul d'un indicateur de performance peut être fait dans les deux sens de flux de données de l'équipement et de manière différente selon le sens. Si l'indicateur est de type calculé, la classe WayToComputePerf peut être associée à la classe Computation qui définit une règle de calcul/récupération de l'indicateur par outil de collecte.

Comme décrit précédemment, cette règle de calcul peut prendre optionnellement en paramètres d'autres indicateurs de performance PerformanceIndicator dans le cas où l'indicateur de performance décrit est lui-même composé d'autres indicateurs. Si l'indicateur est de type basique, il n'a pas de règle de calcul/récupération mais il possède un point de mesure théorique défini par une classe TheoreticalMeasurementPoint associée à la classe WayToComputePerf et sur lequel on pourra obtenir sa valeur. La classe TheoreticalMeasurementPoint décrit le point de mesure théorique d'un indicateur de performance de type basique. Il n'y a qu'un seul et unique point de mesure pour un indicateur. Si l'indicateur est de type calculé, il n'a pas de point de mesure associé. La classe possède un attribut point désignant le point de mesure théorique conformément au type TheoreticalPointEnum.

L'annexe 3 illustre le fichier XML correspondant à la grammaire DTD du modèle SLA qui vient d'être décrite dans le langage UMK lors de l'étape S2 du procédé représenté sur la figure 4. Les mêmes règles de traduction définies pour la grammaire du modèle de service ont été appliquées pour ce fichier. L'annexe 4 illustre un exemple de modèle SLA 90 obtenu de l'étape S5 et conforme à la grammaire DTD décrite dans l'annexe 3.

Le modèle SLA 90 illustré s'applique à la technologie à relais de trame (Frame Relay) d'un opérateur nommé op pour un contrat de niveau nommé siluer.

La figure 9 illustre la structure d'un modèle 110 de description d'au moins un outil SLA 120, qui utilise lors de l'étape S3 du procédé la grammaire d'un modèle de description d'outils SLA. Un modèle 110 de description d'outils SLA définit, pour une technologie donnée et un

<Desc/Clms Page number 32>

équipement donné, des outils 120 nécessaires à la mesure de la qualité de service décrite dans un modèle SLA et s'appuyant sur un modèle 80 de service donné. Le modèle 110 illustré de description d'outils SLA est décrit par la classe SlaToolsPackage qui possède les attributs : # version désignant la version du modèle d 'outils SLA ; # serviceType désignant le type de service auquel est associé le modèle 110 de description d'outils SLA ; # manufacturer désignant le nom du constructeur de l'équipement (un routeur par exemple) supporté par ce modèle d'outils SLA ; # equipment désignant le nom de l'équipement supporté par ce modèle d'outils SLA ; et # equipmentVersion désignant la version de l'équipement supporté par ce modèle d'outils SLA.

La classe SlaToolsPackage peut contenir, comme illustré : # au moins un mode de collecte utilisable pour le modèle SLA, en l'occurrence : # un mode de collecte par agent représenté par une classe AgentData, dont les données proviennent d'un agent 18 ; # un mode de collecte par journal représenté par une classe LogData, dont les données proviennent d'un journal 20,22, 67 ; # un mode de collecte par alarmes représenté par la classe AlarmData, dont les données proviennent d'alarmes filtrées enregistrées dans le journal 65 ; et,en option, # un mode de collecte par application tierce (autre que OpenMaster dans l'exemple illustré), représenté par la classe ApplData et dont les données proviennent de l'application tierce ;et # au moins une description de configuration d'application, autre que les outils de collecte et utile pour la mesure de qualité de service, et représentée par la classe ConfigData.

La classe AgentData représente le mode de collecte par agent 18 d'un outil. Elle possède l'attribut toolName désignant le nom de l'agent

<Desc/Clms Page number 33>

18. Elle décrit en option des informations de configuration nécessaires à cet outil, telles que celles représentées par la classe Mib illustrée dans la figure 4 et concernant les modules de base Mib supportés par l'agent et ceux définis pour les types de composant du modèle de service correspondant, et celles représentées par la classe File illustrée dans la figure 4 et contenant les fichiers d'installation automatique et les fichiers de collecte, dans les journaux 20,22 et 67, d'indicateurs à installer et, de préférence, le ou les fichiers de configuration spécifiques à l'agent.

La classe LogData représente le mode de collecte par journal 20,22, 67 d'un outil. Elle décrit en option des informations de configuration nécessaires à cet outil, telles que celles relatives à la classe AgentData et contenues dans les classes Mib et File. La classe LogData possède les attributs : # toolName désignant le nom de l'outil de collecte par journal ; # logName désignant le nom du journal 20,22, 67 d'indicateurs collectés par l'outil désigné par toolName ; # logDir désignant le répertoire où doit être installé le journal désigné par logName ; # namingRule désignant la règle de nommage des instances dans le journal désigné par logName ; et # repatriationMode désignant le mode de rapatriement du journal désigné par logName.

La classe AlarmData représente le mode de collecte par alarmes d'un outil. Elle possède l'attribut toolName désignant le nom de l'outil collectant les alarmes, par exemple l'outil 64. Elle décrit en option des informations de configuration nécessaires à l'outil, telles que celles relatives à la classe AgentData et contenues dans les classes Mib et File.

La classe ApplData représente le mode de collecte par une application tierce. Elle possède l'attribut toolName désignant le nom de l'application tierce et décrit en option les informations de configuration nécessaires à cet outil, telles que celles relatives à la classe AgentData et contenues dans les classes Mib et File.

<Desc/Clms Page number 34>

La classe ConfigData représente la description de la configuration d'une application, hors outil de collecte, à configurer pour la mise en #uvre de la mesure de la qualité. L'application à configurer peut être en l'occurrence une application 42 d'OpenMaster ou une application tierce. La classe ConfigData possède l'attribut toolName désignant le nom de l'application à configurer et contient en option les fichiers nécessaires à la configuration ou à l'installation automatique de l'application.

L'annexe 5 illustre le fichier XML correspondant à la grammaire du modèle de description d'outils SLA qui vient d'être spécifiée dans le langage UML lors de l'étape S3 du procédé. Les mêmes règles de traduction définies pour la grammaire du modèle de service et la grammaire du modèle SLA ont été appliquées pour ce fichier. L'annexe 6 illustre un exemple de modèle 110 de description d'outils SLA obtenu de l'étape S6 et conforme à la grammaire DTD décrite dans le fichier de l'annexe 5.

On peut constater que les grammaires actuelles référencent des fichiers de collecte et des fichiers de modèles de rapports. Ces fichiers sont actuellement externes et suivent un format de texte (ascii) spécifique à l'offre Report du produit OpenMaster@ du demandeur. La spécification d'une grammaire DTD pour ces modèles est envisageable. Il sera alors possible de référencer dans les grammaires DTD des modèles SLA et des modèles de description d'outils SLA, les grammaires DTD des fichiers de collecte et des modèles de rapports.

L'invention offre notamment les avantages suivants. Une grammaire DTD permet de bien définir des structures complexes comme celles décrivant un modèle de service, un modèle SLA ou un modèle de description d'outils SLA. L'invention permet aussi de réutiliser une grammaire DTD, notamment pour l'étendre, ou pour l'introduire dans une autre DTD, ou encore pour s'en servir et l'adapter à une autre application de service. L'invention permet encore de créer facilement des modèles en langage XML. Il suffit de suivre les grammaires DTD créées pour savoir ce qu'il faut mettre dans un modèle. Néanmoins, l'écriture des documents XML peut se faire plus ou moins facilement selon les éditeurs graphiques utilisés. Trois

<Desc/Clms Page number 35>

types de ces outils sont actuellement connus. Un simple éditeur de texte peut suffire, mais il ne permet pas de vérification des documents XML. Un éditeur de texte avec mode XML permet une vérification. Le meilleur outil est un éditeur conçu spécialement pour le langage XML. Un tel éditeur sait lire les grammaires DTD écrites et proposent une aide à la saisie et une validation efficace de ce qui a été écrit. En outre, les modèles créés suivant ces grammaires XML par un intégrateur de logiciels (qui écrit les modèles adaptés à ses clients) peuvent être aisément validés par des outils du marché permettant d'analyser un fichier XML suivant une grammaire DTD donnée.

D'autre part, l'invention fait une description générique, exhaustive et synthétique de la description des informations à fournir pour mesurer et surveiller la qualité de service. Des modèles de service sont créés par technologie, indépendamment d'un contrat de qualité. Des modèles SLA sont créés pour une technologie donnée, indépendamment des outils de collecte et des équipements, pour modéliser les différents niveaux de contrats applicables à la surveillance d'un service. Des modèles de description d'outils SLA sont créés pour une technologie et un équipement donné pour définir les outils utilisables pour vérifier le contrat. Un modèle de description d'outils SLA n'est installé dans le système d'administration 10 que si un modèle SLA, définissant le modèle du contrat, et un modèle de service, définissant les équipements sujets à mesures, pour une technologie concernée, ont déjà été installés. Il suffit alors de créer un nouveau modèle de description d'outils SLA pour supporter un nouvel équipement pour cette technologie. La description de ces modèles permet donc de décrire de manière synthétique et exhaustive les informations concernant la mesure et la surveillance de la qualité de service d'un service de télécommunication.

Il ressort de la description qui précède que l'invention peut s'appliquer à tout service incluant au moins un composant technique qui peut être physique, tel qu'une connexion dans l'exemple choisi, et/ou applicatif comme aussi illustré. Tout langage de modélisation en technologie orientée objets peut être utilisé. On a vu aussi que chaque structure peut être génératrice d'au moins un modèle respectif, et que chaque modèle peut aussi

<Desc/Clms Page number 36>

générer au moins une unité telle qu'un service, un contrat et un outil de collecte.

Il ressort aussi que le procédé de contrôle de qualité de service peut être utilisé d'une façon réduite à la construction de services à partir d'une structure de modèle de service. Dans ce cas, le procédé ne peut plus faire du contrôle de qualité mais il peut servir à la surveillance d'au moins un service. La surveillance de services sert notamment à connaître les services et leurs états. L'invention a donc pour premier objet un procédé de surveillance d'un service 85 incluant au moins un composant technique 86 défini selon une parmi plusieurs technologies possibles et comprenant : une description (SI, annexe 1), faite en un langage de modélisation en technologie orientée objets (UML, XML) et indépendante desdites technologies, de la structure d'un modèle 80 de service ; la construction (S4, annexe 2) d'un modèle 80 de service à partir de la description de ladite structure ; la construction (S7) du service 85 à partir du modèle 80 de service ; et la surveillance du service ainsi construit. Dans cette définition, un service est la base, le procédé s'appliquant de la même façon à tout ensemble de services.

Plus généralement, l'invention a pour second objet un procédé de contrôle de la qualité d'un service 85 incluant au moins un composant technique 86 défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie par un contrat technique 100 entre le fournisseur du service et un client et le contrat 100 incluant des critères de qualité 101 associés à des seuils 102 et relatifs à ladite technologie. Le procédé comprend : une description (SI, S2, S3, annexes 1,3, 5), faite en un langage de modélisation en technologie orientée objets (UML, XML) et indépendante desdites technologies, de la structure d'un modèle 80 de service, de la structure d'un modèle 90 de contrat et de la structure d'un modèle 110 d'outils de collecte ;la construction (S4, S5, S6, annexes 2,4, 6) d'un modèle de service 80, d'un modèle de contrat 90 et d'au moins un modèle d'outils de collecte 110 à partir des descriptions respectives desdites structures ; la construction (S7-S9) du service 85, du contrat 100 et d'au moins un outil (120) de collecte à partir des modèles respectifs (80,90, 110) ; la collecte, à l'étape

<Desc/Clms Page number 37>

S 10, d'indicateurs de qualité de service 103 au moyen d'au moins ledit outil 120 ; et la comparaison, à l'étape S11, des indicateurs de qualité 103 avec les seuils 102 définis dans le contrat 100. Dans cette définition, un service est la base, le procédé s'appliquant de la même façon à tout ensemble de services.

Selon l'exemple illustré, la description (SI, annexe 1) de la structure d'un modèle de service 80 est faite à partir d'une classe de modèle de service ServicePackage incluant au moins un modèle 81 relatif à au moins ledit composant 86 et défini dans une classe de composant (EndPoints, Applications) selon lesdites technologies possibles.

Accessoirement, au moins ledit composant 86 peut être décrit dans une classe de type de composant ComponentType. Lorsque le procédé est mis en oeuvre par un système d'administration 10 incluant une base d'informations d'administration dite base MIB comme dans l'exemple choisi, la classe de type de composant ComponentType peut être avantageusement associée à une classe Mib représentative d'au moins un module de la base MIB. La description d'un type de composant dans la classe ComponentType peut alors aussi inclure une classe d'attribut de module de base MIB MibAttribute permettant à des requêtes d'accéder dans la base MIB à au moins un attribut représentatif du type de composant.

Lorsque le service inclut des paramètres, la classe de modèle de service ServicePackage peut inclure avantageusement au moins un paramètre relatif au service et défini dans une classe de paramètres Parameters. Cette classe peut, comme illustré, être reliée à la classe d'attribut de module de base MIB MibAttribute lorsque le procédé est mis en #uvre par un système d'administration 10 incluant une base MIB. La classe de modèle de service ServicePackage peut alors aussi inclure au moins un fichier de requêtes à installer, défini dans une classe ExportedRequests et permettant d'obtenir au moins une valeur relative à au moins ledit paramètre défini par la classe Parameters. Elle peut permettre aussi d'obtenir au moins une valeur d'au moins un paramètre défini par la classe MibAttribute. Elle peut aussi permettre d'obtenir au moins un paramètre spécifique du type de composant défini par la classe

<Desc/Clms Page number 38>

ComponentType. La classe de modèle de service ServicePackage peut avantageusement inclure, comme illustré, un module de base MIB permettant de parcourir lesdits paramètres et décrit dans une classe ConfigurationMib attachée à classe Mib. La classe ServicePackage peut encore inclure une application (42, tierce) de mise en oeuvre du service 85, définie dans une classe (IntegratedAppli) et reliée à au moins un fichier permettant de mettre en #uvre l'application de mise en #uvre du service et défini dans une classe File. Toutes ces classes peuvent évidemment être mises en #uvre par le procédé de surveillance de services.

Selon l'exemple illustré, la description, faite à l'étape S2, de la structure d'un modèle 90 de contrat est faite à partir d'une classe de modèle de critère SlaPackage incluant au moins un prototype de critère défini dans une classe SlaCriteriaPrototype selon l'une desdites technologies possibles, cette classe étant associée à une classe QosIndicator représentative des indicateurs de qualité de service 103 ainsi qu'à au moins une classe TriggerRule représentative d'au moins une règle de déclenchement d'au moins une action lorsqu'un seuil 102 est atteint. La classe Qoslndicator peut avantageusement inclure une description définie dans une classe Description, au moins une classe représentative d'une unité de seuil (PercentUnit, TimeUnit, ObjectUnit, ThroughputUnit) et au moins une classe WayToComputeQoS représentative d'au moins un mode de calcul d'un indicateur de qualité de service. La classe WayToComputeQoS peut être associée à au moins une règle de calcul définie dans une classe Computation. Cette dernière classe peut prendre, en options, au moins un indicateur de performance contenu dans une classe Performancelndicator incluant une description définie dans ladite classe Description, au moins la classe d'unité de seuil (PercentUnit, TimeUnit, ObjectUnit, ThroughputUnit) et au moins une classe WayToComputePerf représentative d'au moins un mode de collecte d'un indicateur de performance. Lorsque l'indicateur de performance est basique, le mode de collecte défini par la classe WayToComputePerf peut s'appliquer à un point de mesure théorique défini par une classe TheoreticalMeasurementPoint.

<Desc/Clms Page number 39>

Lorsque l'indicateur de performance est calculé, le mode de collecte décrit dans la classe WayToComputePerf peut être représenté par la classe de règles de calcul Computation pouvant optionnellement prendre en paramètre (s) au moins un autre indicateur de performance contenu dans la classe Performancelndicator.

On a vu aussi que, en variante avantageuse illustrée, la classe de modèle de critère SlaPackage inclut en outre dans une classe de modèles de rapport ReportModels au moins un ensemble de modèles 94 de rapport de contrôle de la qualité de service.

En ce qui concerne la description (S3, annexe 5) de la structure d'au moins un modèle d'outils de collecte, elle peut, comme dans l'exemple illustré, être faite à partir d'une classe de modèle d'outils SlaToolsPackage destinée à mettre en #uvre les étapes (S10, S11) de collecte et de comparaison et pouvant optionnellement inclure au moins une classe (AgentData, LogData, AlarmData, ApplData) représentative d'un mode de collecte d'indicateurs de qualité et/ou au moins une description dans une classe ConfigData de configuration d'une application informatique (42 ou tierce).

L'invention a pour objets connexes les structures de modèle, de contrat et d'outils de collecte, ainsi que les modèles et unités (services, contrats et outils) qui en sont issus. Elle a aussi pour objets connexes un système d'administration 10 et un système d'information 11 utilisés pour la mise en #uvre du procédé de surveillance de services ou du procédé de contrôle de qualité de service.

<Desc/Clms Page number 40>

ANNEXE 1
Grammaire DTD d'un modèle de service <!ELEMENT ServicePackage (Parameters?, EndPoints, IntermediatePoints?, Applications ?, ConfigurationMib?, ExportedRequests ?, IntegratedAppli?)> <!ATTLIST ServicePackage name CDATA #REQUIRED> <!ATTLIST ServicePackage version CDATA #REQUIRED> <!ATTLIST ServicePackage serviceType CDATA #REQUIRED> <!ATTLIST ServicePackage iconName CDATA #REQUIRED> <!ELEMENT Parameters (Parameter+)> <!ELEMENT EndPoints (ComponentType+)> <!ELEMENT IntermediatePoints (ComponentType+)> <!ELEMENT Applications (ComponentType+)> <!ELEMENT ConfigurationMib (Mib)> <!ELEMENT ExportedRequests (File)> <!-- IntegratedAppli --> <!ELEMENT IntegratedAppli (File, File+)> <!ATTLIST IntegratedAppli name CDATA #REQUIRED> <!-- Parameter --> <!ELEMENT Parameter (MibAttribute?)> <!ATTLIST Parameter name CDATA #REQUIRED> <!ATTLIST Parameter defaultValue CDATA #IMPLIED> <!ATTLIST Parameter description CDATA #REQUIRED> <!-- ComponentType --> <!ELEMENT ComponentType (Mib*, MibAttribute* <!ATTLIST ComponentType ident CDATA #REQUIRED> <!ATTLIST ComponentType theoreticalMeasurementPoint CDATA #REQUIRED> <!ATTLIST ComponentType ptMeasurementType CDATA #IMPLIED> <!-- Mib --> <!ELEMENT Mib EMPTY> <!ATTLIST Mib name CDATA #REQUIRED> <!ATTLIST Mib logicalName CDATA #REQUIRED> <!ATTLIST Mib oid CDATA #REQUIRED> <!-- MibAttribute --> <!ELEMENT MibAttribute EMPTY> <!ATTLIST MibAttribute label CDATA #REQUIRED> <!ATTLIST MibAttribute unit CDATA #REQUIRED> <!ATTLIST MibAttribute description CDATA #REQUIRED> <!ATTLIST MibAttribute request CDATA #REQUIRED> <!-- File --> <!ELEMENT File EMPTY> <!ATTLIST File name CDATA #REQUIRED> <!ATTLIST File dir CDATA #REQUIRED> <!ATTLIST File type CDATA #REQUIRED>

<Desc/Clms Page number 41>

ANNEXE 2
Exemple d'un modèle de service Cet exemple de modèle de service a été créé pour un service à technologie de relais de trames (Frame Relay), conformément à la grammaire DTD de l'annexe 1.

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ServicePackage SYSTEM "packageService.dtd"> <ServicePackage iconName="service.icone" serviceType="fr" version="1.0" name="srv~rfc1604"> <Parameters> <Parameter name="Bc" defaultValue="70" description="Committed Burst Size"/> <Parameter name="Ec" defaultValue="85" description="Excess Burst Size"/> </Parameters> <EndPoints> <ComponentType ident="FrPtA" theoreticalMeasurementPoint="pointA"> <Mib name="rfcl604" logicalName="rfcl604" oid="1.3.6.1.2.1.10.44"/> <MibAttribute label="FRLogicalPort" request="reqGetFRLP" description="Frame Relay Logical Port" unit="integer" /> <MibAttribute label="DLCI" request="reqGetDLCI" description="Data Link Control Identifier" unit="integer" /> </ComponentType> <ComponentType ident="FrPtZ" theoreticalMeasurementPoint="pointZ"> <Mib name="rfcl604" logicalName="rfcl604" oid="1.3.6.1.2.1.10.44"/> <MibAttribute label="FRLogicalPort" request="reqGetFRLP" description="Frame Relay Logical Port" unit="integer" /> <MibAttribute label="DLCI" request="reqGetDLCI" description="Data Link Control Identifier" unit="integer" /> </ComponentType> </EndPoints> <Applications> <ComponentType ident="ARS" theoreticalMeasurementPoint="pointA"></ComponentType> </Applications> <ExportedRequests> <File name="svr~fc1604.export" dir="$ISMROOT/var/import/telecom" type="importCMISFile"/> </ExportedRequests> </ServicePackage>

<Desc/Clms Page number 42>

ANNEXE 3
Grammaire DTD d'un modèle SLA <!ELEMENT SlaPackage (SlaCriteriaPrototype+, ReportModels? <!ATTLIST SlaPackage level CDATA #REQUIRED> <!ATTLIST SlaPackage version CDATA #REQUIRED> <!ATTLIST SlaPackage serviceType CDATA #REQUIRED> <!-- SlaCriteriaPrototype --> <!ELEMENT SlaCriteriaPrototype (Qoslndicator, TriggerRule+ <!ATTLIST SlaCriteriaPrototype task CDATA #REQUIRED> <!-- QosIndicator --> <!ELEMENT QosIndicator (Description, ((PercentUnit+) # (TimeUint+) # (ObjectUnit+) # (ThroughputUnit#)), WayToComputeQoS+)> <!ATTLIST QosIndicator name CDATA #REQUIRED> <!ATTLIST QosIndicator slaOperator CDATA #REQUIRED> <!ATTLIST QosIndicator ptMeasurementType CDATA #IMPLIED> <!ELEMENT Description (#PCDATA)> <!ELEMENT PercentUnit EMPTY> <!ATTLIST PercentUnit type CDATA #REQUIRED> <!ELEMENT TimeUnit EMPTY> <!ATTLIST TimeUnit type CDATA #REQUIRED> <!ELEMENT ObjectUnit EMPTY> <!ATTLIST ObjectUnit type CDATA #REQUIRED> <!ELEMENT ThroughputUnit EMPTY> <!ATTLIST ThroughputUnit type CDATA #REQUIRED> <!ELEMENT WayToComputeQoS (Computation+ <!ATTLIST WayToComputeQoS dataFlow CDATA #REQUIRED> <!ELEMENT Computation (PerformanceIndicator*) > <!ATTLIST Computation toolName CDATA #REQUIRED> <!ATTLIST Computation methodName CDATA #REQUIRED> <!ATTLIST Computation methodFile CDATA #REQUIRED> <!ATTLIST Computation methodFileDir CDATA #REQUIRED> <!-- PerformanceIndicator --> <!ELEMENT PerformanceIndicator (Description, (PercentUnit + #TimeUnit + #ObjectUnit + # ThroughputUnit#), WayToComputePerf+)> <!ATTLIST PerformanceIndicator name CDATA #REQUIRED> <!ATTLIST PerformanceIndicator type CDATA #REQUIRED> <!ELEMENT WayToComputePerf (TheoreticalMeasurementPoint?, Computation? <!ATTLIST WayToComputePerf dataFlowCDATA #REQUIRED> <!ELEMENT TheoreticalMeasurementPoint EMPTY> <!ATTLIST TheoreticalMeasurementPoint point CDATA #REQUIRED> <!-- TriggerRule --> <!ELEMENT TriggerRule EMPTY> <!ATTLIST TriggerRule threshold CDATA #REQUIRED> <!ATTLIST TriggerRule validityPeriod CDATA #IMPLIED>

<Desc/Clms Page number 43>

<!-- ReportModels--> <!ELEMENT ReportModels (ReportPackage+)> <!-- ReportPackage --> <!ELEMENT ReportPackage EMPTY> <!ATTLIST ReportPackage name CDATA #REQUIRED> <!ATTLIST ReportPackage dir CDATA #REQUIRED> <!ATTLIST ReportPackage target CDATA #REQUIRED>

<Desc/Clms Page number 44>

ANNEXE 4
Exemple d'un modèle SLA Cet exemple de modèle SLA a été créé pour un service à technologie de relais de trames (Frame Relay) et pour une qualité de service de niveau silver, conformément à la grammaire DTD décrite dans l'annexe 3.

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE SlaPackage SYSTEM "packageSla.dtd"> <SlaPackage serviceType="fr" version="1.0" level="silver"> <SlaCriteriaPrototype task="taskCriterial"> <QosIndicator slaOperator=">" name="FDR"> <Description>Frame Delivery Ratio</Description> <!-- one of (ThroughputUnit+ ObjectUnit+ TimeUnit+ PercentUnit+) - -> <PercentUnit type="%"/> <WayToComputeQoS dataFlow="A-Z"> <Computation toolName="PMS" methodFile="calcFDR.class" methodName="calcFDR" methodFileDir="."> <PerformanceIndicator type="basic" name="txFrames"> <Description>Nombre de trames en sorties</Description> <!-- one of (ThroughputUnit+ ObjectUnit+ TimeUnit+ PercentUnit+) --> <ObjectUnit type="Frame"/> <WayToComputePerf dataFlow="A-Z"> <TheoreticalMeasurementPoint point="pointZ"/> </WayToComputePerf> </PerformanceIndicator> <PerformanceIndicator type="basic" name="rxFrames"> <Description>Nombre de trames en entree</Description> <!-- one of (ThroughputUnit+ ObjectUnit+ TimeUnit+ PercentUnit+) --> <ObjectUnit type="Frame"/> <WayToComputePerf dataFlow="A-Z"> <TheoreticalMeasurementPoint point="pointA"/> </WayToComputePerf> </PerformanceIndicator> </Computation> </WayToComputeQoS> <WayToComputeQoS dataFlow="Z-A"> <Computation toolName="PMS" methodFile="calcFDR.class" methodName="calcFDR" methodFileDir="."> <PerformanceIndicator type="basic" name="txFrames"> <Description>Nombre de trames en sorties</Description> <!-- one of (ThroughputUnit+ ObjectUnit+ TimeUnit+ PercentUnit+) --> <ObjectUnit type="Frame"/> <WayToComputePerf dataFlow="Z-A"> <TheoreticalMeasurementPoint point="pointA"></TheoreticalMeasurementPoint> </WayToComputePerf> </PerformanceIndicator> <PerformanceIndicator type="basic" name="rxFrames"> <Description>Nombre de trames en entree</Description> <!-- one of (ThroughputUnit+ ObjectUnit+ TimeUnit+ PercentUnit+) --> <ObjectUnit type="Frame"/>

<Desc/Clms Page number 45>

<WayToComputePerf dataFlow="Z-A"> <TheoreticalMeasurementPoint point="pointA"></TheoreticalMeasurementPoint> > </WayToComputePerf> </PerformanceIndicator> </Computation> </WayToComputeQoS> </QosIndicator> <TriggerRule threshold="80"/> </SlaCriteriaPrototype> <ReportModels> <ReportPackage target="billing" dir="$ISMROOT/var/config/REPORT" name="rfc1604-bill.odc"> </ReportPackage> <ReportPackage target="network" dir="$ISMROOT/var/config/REPORT" name="rfc1604-Net.odc"> </ReportPackage> </ReportModels> </SlaPackage>

<Desc/Clms Page number 46>

ANNEXE 5
Grammaire DTD d'un modèle de description d'outils SLA <!ELEMENT SlaToolsPackage (AgentData?, LogData ?, AlarmData?,ApplData?, ConfigData* <!ATTLIST SlaToolsPackage version CDATA #REQUIRED> <!ATTLIST SlaToolsPackage serviceType CDATA #REQUIRED> <!ATTLIST SlaToolsPackage manufacturer CDATA #REQUIRED> <!ATTLIST SlaToolsPackage equipment CDATA #REQUIRED> <!ATTLIST SlaToolsPackage equipmentVersion CDATA #REQUIRED> <!ELEMENT AgentData (Mib*, File*) > <!ATTLIST AgentData toolName CDATA #REQUIRED> <!ELEMENT LogData (Mib*, File*) > <!ATTLIST LogData toolName CDATA #REQUIRED> <!ATTLIST LogData logName CDATA #REQUIRED> <!ATTLIST LogData logDir CDATA #REQUIRED> <!ATTLIST LogData namingRule CDATA #REQUIRED> <!ATTLIST LogData repatriationMode CDATA #REQUIRED> <!ELEMENT AlarmData (Mib*, File*) > <!ATTLIST AlarmData toolName CDATA #REQUIRED> <!ELEMENT ApplData (Mib*, File*)> <!ATTLIST ApplData toolName CDATA #REQUIRED> <!ELEMENT ConfigData (File*)> <!ATTLIST ConfigData toolName CDATA #REQUIRED> <!ELEMENT Mib EMPTY> <!ATTLIST Mib name CDATA #REQUIRED> <!ATTLIST Mib logicalName CDATA #REQUIRED> <!ATTLIST Mib oid CDATA #REQUIRED> <!ELEMENT File EMPTY> <!ATTLIST File name CDATA #REQUIRED> <!ATTLIST File dir CDATA #REQUIRED> <!ATTLIST File type CDATA #REQUIRED>

<Desc/Clms Page number 47>

ANNEXE 6
Exemple d'un modèle de description d'outils SLA Cet exemple de modèle de description d'outils SLA a été créé pour un service à technologie de relais de trames (Frame Relay), pour supporter un équipement Routeur3000 du constructeur Cisco suivant la norme RFC1604.

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE SlaToolsPackage SYSTEM "packageSlaTools.dtd"> <SlaToolsPackage version="1.0" serviceType="fr" manufacturer="Cisco" equipment="Router3000" equipmentVersion="1.0"> <AgentData toolName="PMS"> <Mib name="rfcl604" logicalName="rfc1604" oid="1.3.6.1.2.1.10.44"/> <File name="rfcl604Cisco.pck" dir="$ISMROOT/var/config/PMS" type="CollectFile"/> <File name="rfcl604Core.pck" dir="$ISMROOT/var/config/PMS" type="CollectFile"/> </AgentData> <AlarmData toolName="PMS"> <File name="rfc1604Filter.conf" dir="$ISMROOT/var/config/Alarm" type="CopyFile"/> <File name="rfcl604Core.pck" dir="$ISMROOT/var/config/PMS" type="CollectFile"/> <File name="rfcl604.ALcfg" dir="$ISMROOT/var/config/Alarm" type="AlarmFilterFile"/> </AlarmData> <ConfigData toolName="Ip-Discovery"> <File name="discovery.conf"dir="$ISMROOT/var/config/Ip-Discovery" type="CmisImportFile"/> </ConfigData> <ConfigData toolName="Ep"> <File name="taskCriterial" dir="$ISMROOT/var/config/Ep" type="CmisImportFile"/> </ConfigData> </SlaToolsPackage>

Claims (18)

Revendications 1. Procédé de surveillance, au moyen d'au moins un processeur (14) et de moyens de mémoire (15), d'un service (85) incluant au moins un composant technique (86) défini selon une parmi plusieurs technologies possibles, caractérisé en ce qu'il comprend : une description (SI, annexe

1), faite dans les moyens de mémoire (15) en un langage de modélisation en technologie orientée objets (UML, XML) et indépendante desdites technologies, de la structure d'un modèle (80) de service ; la construction (S4, annexe 2) dans les moyens de mémoire (15) d'un modèle (80) de service à partir de la description de ladite structure ; la construction (S7) dans les moyens de mémoire (15) du service (85) à partir du modèle (80) de service ; et la surveillance du service ainsi construit.

S5, S6, annexes 2,4, 6) dans les moyens de mémoire (15) d'un modèle de service (80), d'un modèle de contrat (90) et d'au moins un modèle d'outils de collecte (110) à partir des descriptions respectives desdites structures ; la construction (S7-S9) dans les moyens de mémoire (15) du service (85), du contrat (100) et d'au moins un outil (120) de collecte à partir des modèles respectifs (80,90, 110) ; la collecte (S 10) d'indicateurs de qualité

2. Procédé de contrôle, au moyen d'au moins un processeur (14) et de moyens de mémoire (15), de la qualité d'un service (85) incluant au moins un composant technique (86) défini selon une parmi plusieurs technologies possibles, la qualité de service étant définie par un contrat technique (100) entre le fournisseur du service et un client et le contrat (100) incluant des critères de qualité (101) associés à des seuils (102) et relatifs à ladite technologie, le procédé étant caractérisé en ce qu'il comprend : une description (SI, S2, S3, annexes 1,3, 5), faite dans les moyens de mémoire (15) en un langage de modélisation en technologie orientée objets (UML, XML) et indépendante desdites technologies, de la structure d'un modèle (80) de service, de la structure d'un modèle (90) de contrat et de la structure d'un modèle (110) d'outils de collecte ; la construction (S4,

<Desc/Clms Page number 49>

de service (103) au moyen d'au moins ledit outil (120) ; et la comparaison (Sll) des indicateurs de qualité (103) avec les seuils (102) définis dans le contrat (100).

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la description (Si, annexe 1) de la structure d'un modèle (80) de service est faite à partir d'une classe de modèle de service (ServicePackage) incluant au moins un modèle (81) relatif à au moins ledit composant (86) et défini dans une classe de composant (EndPoints, Applications) selon lesdites technologies possibles.

4. Procédé selon la revendication 3, caractérisé en ce que au moins ledit composant (86) est décrit dans une classe de type de composant (ComponentType) qui, lorsque le procédé est mis en #uvre par un système d'administration (10) incluant une base d'informations d'administration dite base MIB, est associée à une classe (Mib) représentative d'au moins un module de la base MIB.

5. Procédé selon la revendication 4, caractérisé en ce que la description d'un type de composant dans la classe (ComponentType) inclut aussi une classe d'attribut de module de base MIB (MibAttribute) permettant à des requêtes d'accéder dans la base MIB à au moins un attribut représentatif du type de composant.

6. Procédé selon l'une des revendications 3 à 5, caractérisé en ce que la classe de modèle de service (ServicePackage) inclut aussi au moins un paramètre relatif au service et défini dans une classe de paramètres (Parameters) pouvant optionnellement être reliée à la classe d'attribut de module de base MIB (MibAttribute) lorsque le procédé est mis en #uvre par un système d'administration (10) incluant une base MIB.

<Desc/Clms Page number 50>

MIB (MibAttribute) et au moins un paramètre spécifique du type de composant défini par la classe (ComponentType).

7. Procédé selon la revendication 6, caractérisé en ce que la classe de modèle de service (ServicePackage) inclut aussi au moins un fichier de requêtes à installer, défini dans une classe (ExportedRequests) et permettant d'obtenir au moins une valeur relative à au moins ledit paramètre défini par la classe (Parameters) et, en options, d'obtenir au moins une valeur d'au moins un paramètre défini par la classe d'attribut de module de base

8. Procédé selon la revendication 6 ou 7, caractérisé en ce que la classe de modèle de service (ServicePackage) inclut aussi un module de base MIB permettant de parcourir lesdits paramètres et décrit dans une classe (ConfigurationMib) attachée à la classe de module de base MIB (Mib).

9. Procédé selon l'une des revendications 3 à 8, caractérisé en ce que la classe de modèle de service (ServicePackage) inclut aussi une application (42, tierce) de mise en #uvre du service (85), définie dans une classe (IntegratedAppli) et reliée à au moins un fichier permettant de mettre en #uvre l'application de mise en #uvre du service et défini dans une classe (File).

10. Procédé selon l'une des revendications 2 à 9, caractérisé en ce que la description (S2) de la structure d'un modèle (90) de contrat est faite à partir d'une classe de modèle de critère (SlaPackage) incluant au moins un prototype de critère défini dans une classe (SlaCriteriaPrototype) selon l'une desdites technologies possibles, cette classe étant associée à une classe (QosIndicator) représentative desdits indicateurs de qualité de service (103) ainsi qu'à au moins une classe (TriggerRule) représentative d'au moins une règle de déclenchement d'au moins une action lorsqu'un seuil (102) est atteint.

<Desc/Clms Page number 51>

ObjectUnit, ThroughputUnit) et au moins une classe (WayToComputeQoS) représentative d'au moins un mode de calcul d'un indicateur de qualité de service.

11. Procédé selon la revendication 10, caractérisé en ce que la classe (Qoslndicator) représentative des indicateurs de qualité (103) inclut une description définie dans une classe (Description), au moins une classe représentative d'une unité de seuil (PercentUnit, TimeUnit,

ThroughputUnit) et au moins une classe (WayToComputePerf) représentative d'au moins un mode de collecte d'un indicateur de performance.

12. Procédé selon la revendication 11, caractérisé en ce que la classe (WayToComputeQoS) de calcul d'indicateur de qualité de service est associée à au moins une règle de calcul définie dans une classe (Computation) et pouvant prendre, en options, au moins un indicateur de performance contenu dans une classe (Performancelndicator) incluant une description définie dans ladite classe (Description), au moins la classe d'unité de seuil (PercentUnit, TimeUnit, ObjectUnit,

13. Procédé selon la revendication 12, caractérisé en ce que l'indicateur de performance étant basique, le mode de collecte défini par la classe (WayToComputePerf) s'applique à un point de mesure théorique défini par une classe (TheoreticalMeasurementPoint).

14. Procédé selon la revendication 12, caractérisé en ce que l'indicateur de performance étant calculé, le mode de collecte décrit dans la classe (WayToComputePerf) est représenté par la classe de règles de calcul (Computation) pouvant optionnellement prendre en paramètre (s) au moins un autre indicateur de performance contenu dans la classe (Performancelndicator).

<Desc/Clms Page number 52>

15. Procédé selon l'une des revendications 10 à 14, caractérisé en ce que la classe de modèle de critère (SlaPackage) inclut en outre dans une classe de modèles de rapport (ReportModels) au moins un ensemble de modèles (94) de rapport de contrôle de la qualité de service.

16. Procédé selon l'une des revendication 2 à 15, caractérisé en ce que la description (S3, annexe 5) de la structure d'au moins un modèle d'outils de collecte est faite à partir d'une classe de modèle d'outils (SlaToolsPackage) destinée à mettre en #uvre les étapes (S 10, S11) de collecte et de comparaison et pouvant optionnellement inclure au moins une classe (AgentData, LogData, AlarmData, ApplData) représentative d'un mode de collecte d'indicateurs de qualité et/ou au moins une description dans une classe (ConfigData) de configuration d'une application informatique (42 ou tierce).

17. Procédé selon l'une des revendications 1 à 16, caractérisé en ce que le service (85) est un service de télécommunication et au moins le composant (86) inclut une connexion de télécommunication.

18. Système d'administration (10) d'au moins une ressource (11), comprenant au moins un processeur (14) et des moyens de mémoire (15) et mettant en #uvre un service (85) incluant au moins un composant technique (86) défini selon une parmi plusieurs technologies possibles, le système d'administration (10) incluant dans les moyens de mémoire (15) des indicateurs de qualité (103) servant au contrôle de la qualité de service définie par un contrat technique (100) entre le fournisseur du service et un client et le contrat (100) incluant des critères (101) associés à des seuils (102) et relatifs à ladite technologie, caractérisé en ce qu'il met en #uvre le procédé défini par l'une des revendications 1 à 17.