FR2816421A1

FR2816421A1 - Gestion coordonnee de contrats et services, notamment de telecommunication

Info

Publication number: FR2816421A1
Application number: FR0014154A
Authority: FR
Inventors: Sophie Houssiaux; Anne Laverriere; Isabelle Lebourg
Original assignee: Evidian SA
Current assignee: Evidian SA
Priority date: 2000-11-06
Filing date: 2000-11-06
Publication date: 2002-05-10
Also published as: US20030033162A1

Abstract

La gestion consiste à construire (S1) en technologie orientée objets un modèle (80) de service et un modèle (90) de contrat; générer (52), à partir des deux modèles (80, 90), le service (85) et le contrat (100) de façon à être définis chacun, à tout instant, en un nombre maximal au moins égal à deux de versions (85a, 85b; 100a, 100b); définir (S3) des périodes d'application (88, 105) desdites versions (85a, 85b; 100a, 100b); et définir (S4) pour les versions (85a, 85b; 100a, 100b) des états (89, 106) pour déterminer à tout instant une coordination entre une version (85a) de service et une version (100a) de contrat. Ce procédé permet une gestion entièrement automatique et assure une adaptation facile et une continuité rapide et fiable des versions.

Description

Titre
Gestion coordonnée de contrats et services, notamment de télécommunication.

Domaine technique.

L'invention se rapporte à un procédé de gestion coordonnée de services et de contrats. Elle concerne tout service ayant au moins un composant technique et se référant à un contrat technique. L'invention sera illustrée par un exemple typique particulièrement contraignant relatif à un service fourni par un opérateur de télécommunication à un client qui peut être une personne physique ou morale. Le contrat technique se rapporte dans ce cas à des critères de qualité associés à des seuils et relatifs à la technologie de télécommunication correspondant au service.

L'invention a aussi pour objet un système informatique pour la mise en oeuvre du procédé de gestion du service et du contrat. En particulier, un service de télécommunication peut mettre en oeuvre des composants techniques de différents types de technologies et imposer une surveillance continue par rapport à de nombreux critères de qualité du contrat technique. Dans un tel cas, le procédé de gestion nécessite des moyens très réactifs et performants, tels que ceux mis en oeuvre 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 oeuvre du procédé de gestion du service et du contrat. Elle a aussi pour objets un programme d'ordinateur pour la mise en oeuvre du procédé de l'invention et un support d'enregistrement du programme, tel qu'un cédérom.

L'art antérieur.

Dans le temps, le service et le contrat correspondant peuvent subir des modifications plus ou moins importantes et plus ou moins fréquentes. Ces modifications posent le grave problème du maintien de la cohérence entre le service et le contrat.

L'importance du problème ressort de l'exemple suivant.

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 oeuvre d'un service (Service Fulfillment), au maintien du service (Service Assurance) et à sa facturation (Billing). La mise en oeuvre 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 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 très complexe compte tenu des liaisons pouvant exister entre les données et de leur évolution très rapide.

On comprend donc que dans ce domaine les modifications peuvent être nombreuses, fréquentes et très diverses dans le service offert et dans le contrat relatif à

chaque client. La gestion dans le temps du service et du contrat pose donc un problème très compliqué, encore plus compliqué pour la gestion de l'ensemble des clients d'un opérateur de télécommunication. Des modifications peuvent être contractuelles et faire intervenir dans le temps plusieurs versions du contrat d'un client. Parmi ces modifications, certaines peuvent être techniques, telles que celles relatives à des seuils de qualité, tandis que d'autres peuvent être relatives à l'application dans le temps des versions de service et de contrat. D'autres modifications peuvent être liées aux technologies de télécommunication ou à leur implantation géographique, par exemple au remplacement d'un routeur obsolète par un autre type de routeur beaucoup plus perfectionné mais impliquant un autre type de service et d'autres seuils de qualité à répercuter dans le contrat. Parmi ces modifications, certaines peuvent être relatives à l'application dans le temps du contrat et du service. Les modifications du service engendrent donc plusieurs versions de service. Certaines versions de service peuvent s'appliquer sur une même version de contrat, tandis que d'autres nécessitent une correspondance technique et temporelle rigoureuse entre une version de service et une version du contrat, comme par exemple celle relative au changement de routeur. Ces exemples illustrent bien le problème lié aux imbrications possibles entre versions de service et versions de contrat et le risque très grand de leur incohérence ou même d'une rupture de continuité entre le contrat et le service. On comprend que les conséquences de leur incohérence peuvent être très graves pour l'opérateur et ses clients. Les clients peuvent avoir des problèmes de connexion, de facturation et de contrôle de qualité et l'opérateur peut perdre ainsi une partie de sa clientèle et de sa crédibilité.

À présent, la gestion coordonnée dans le temps des services et des contrats n'est pas encore entièrement automatisée. La très grande complexité du problème et la vigilance nécessaire pour minimiser tout risque d'incohérence dans le suivi des modifications requiert beaucoup de personnel. En plus du coût matériel et personnel s'ajoute une grande lourdeur dans la gestion, mal appropriée aux modifications fréquentes et peu réactives aux souhaits des opérateurs et des clients.

Sommaire de l'invention.

Un premier but de l'invention est d'offrir un procédé entièrement automatisé de gestion coordonnée dans le temps des services et des contrats correspondants.

Un second but de l'invention est pouvoir adapter de façon rapide et fiable le procédé de gestion à toute modification relative aux composants techniques du service.

Un troisième but est d'assurer une continuité et une cohérence dans l'application temporelle des modifications entre le service et le contrat.

Un quatrième but de l'invention est de permettre au procédé de gestion de sélectionner les modifications de service qui impliquent des modifications du contrat et des les répercuter automatiquement dans le contrat.

Un cinquième but de l'invention est de mettre en oeuvre le procédé de gestion par des moyens simples, peu coûteux, très réactifs et facilement exploitables.

L'invention a pour objet un procédé de gestion coordonnée, au moyen d'au moins un processeur et de moyens de mémoire, d'un service incluant au moins un composant technique et d'un contrat technique correspondant au service, caractérisé en ce qu'il comprend les étapes de : construire en technologie orientée objets un modèle de service et un modèle de contrat ; générer, dans les moyens de mémoire et à partir des deux modèles, le service et le contrat de façon à être définis chacun, à tout instant, en un nombre maximal au moins égal à deux de versions ; définir dans les moyens de mémoire des périodes d'application desdites versions ; et définir, pour les versions et dans les moyens de mémoire, des états pour déterminer à tout instant une coordination entre une version (85a) de service et une version de contrat.

L'invention a pour objet corollaire un système informatique incluant au moins un processeur et des moyens de mémoire, caractérisé en ce que en ce qu'il met en oeuvre la procédé défini précédemment. Le système informatique peut constituer un système d'administration d'au moins une ressource.

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 oeuvre un procédé de gestion 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.

'La figure 4 est un diagramme illustrant des étapes d'un exemple de procédé de gestion, par le système d'administration représenté sur les figures 1 et 2, d'un service de télécommunication et du contrat correspondant.

'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 oeuvre 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 oeuvre 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 oeuvre par le procédé de l'invention représenté sur la figure 4.

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

* La figure 10 est un diagramme illustrant un exemple de modélisation d'un service et d'un contrat pour la mise en oeuvre du procédé de l'invention.

'La figure 11 est un diagramme illustrant un exemple d'états de service et de leurs liens pour la mise en oeuvre du procédé de l'invention.

* Et la figure 12 est une vue très schématique d'une structure de télécommunication utilisée pour illustrer un exemple de mise en oeuvre du procédé de l'invention par le système d'administration représenté sur la figure 1.

Description détaillée d'exemples illustrant 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 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.

Le système d'administration 10 choisi a une architecture de type clientserveur. 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.

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 dans un ou plusieurs langages, le langage Javas 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 ; et un 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 schema Service) contenant les schémas, aussi dits classes, des objets gérés par la plate-forme ; un service 63 de traitement des événements (Event Processor) ; un service 64 d'alarmes incorporant un journal 65 d'alarmes (Alarm Log) ; et un 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 plate-forme 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, 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 sous-modules 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 oeuvre 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. 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, M-ACTION 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 oeuvre du procédé de gestion coordonnée d'un contrat et d'un service fourni par un opérateur de télécommunication à un client dans les conditions définies dans le 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 référence à la figure 2 que système d'administration 10 fournit les services de base à une application 42 relative à la gestion des contrats et services de télécommunication. Le système d'administration 10 illustré, enrichi de l'invention, offre aux opérateurs de télécommunication l'avantage de gérer à partir de modèles adéquats, les services à surveiller et les contrats de qualité de service passés entre les opérateurs et ses clients sur ces services. 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 gestion coordonnée, à l'aide du système d'administration 10, d'un contrat et d'un service de télécommunication mis en oeuvre dans le système d'information 11. Les services de télécommunication offerts par un opérateur sont contenus dans l'inventaire 46 (Figure 2), où sont identifiés les services, les clients et les contrats correspondants. Un service de télécommunication est défini selon une parmi plusieurs technologies possibles de télécommunication. Le procédé illustré dans la figure 4 pour la gestion d'un service et d'un contrat est activé à une étape SO et commence par une étape SI de construction en

technologie orientée objets 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. Cette construction peut être faite de façon quelconque, et plus particulièrement selon la demande de brevet français enregistrée sous le n 0006537 du demandeur. Selon ce document, les trois modèles 80,90 et 110 sont construits à partir de trois structures respectives de description générique. 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 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 au moins un modèle 90 de contrat, aussi appelé modèle SLA. 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 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 oeuvre 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 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 de l'étape SI 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 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 Definition).

Le procédé de gestion illustré dans la figure 4 se poursuit par une étape S2 de génération, à partir des trois modèles 80,90 et 110, de versions respectives 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, l'étapes S2 permet 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 ; les valeurs des seuils 102 issues d'au moins le modèle de seuil 92 ; les indicateurs QoS 103 relatifs aux critères SLA 101 et construits à partir des modèles d'indicateur QoS respectifs 93 ; et au moins un composant 104 attaché à un critère SLA 101 et choisi parmi les composants 86 du service 85 associé. De même, les modèles 110 d'outils de collecte servent à définir des outils 120 de collecte des indicateurs QoS relatifs aux critères SLA 101 et nécessaires au contrôle de la qualité du service défini par le contrat 100.

Le procédé illustré dans la figure 4 est inclus dans un procédé de contrôle de la qualité du service. Le procédé de contrôle illustré inclut aussi : une étape S5 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 S6 de comparaison des indicateurs

QoS avec les seuils correspondants 102 définis dans le contrat 100 ; et, selon l'option choisie, une étape S7 de rapports établis en l'occurrence selon les modèles 94 de rapport qui existent dans le modèle de contrat 90 et aussi contenus dans le contrat 100 et non illustrés dans le contrat 100 pour des raisons de clarté des dessins. Le procédé de contrôle illustré prend fin à l'étape S8.

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.

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 :

vident 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 (point) 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).

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 ConfïgurationMib 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 oeuvre 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 oeuvre 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,

* defaultValue 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 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 SI du procédé. À partir du modèle SLA 90 est généré à l'étape S 1 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.

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 QosIndicator 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 ; * 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 (logicaiPort).

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 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 QosIndicator 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 PerformanceIndicator.

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 (ilS), la milliseconde (ms), la seconde (s), la minute (m) et l'heure (h).

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.

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 PerformanceIndicator, 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 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.

La figure 9 illustre la structure d'un modèle 110 de description d'au moins un outil SLA 120, qui utilise 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 é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 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.

La classe ConfigData représente la description de la configuration d'une application, hors outil de collecte, à configurer pour la mise en oeuvre 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'étape SI du procédé de 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.

On remarquera que dans l'exemple illustré le modèle 110 d'outils de collecte d'indicateurs QoS ne sert qu'à contrôler la qualité du service en référence aux critères SLA et aux seuils définis dans le contrat. On peut donc dire que le modèle 110

d'outils est un attribut du modèle 90 de contrat. Il en est par conséquent de même avec les outils 120, qui sont des attributs du contrat 100. D'autre part, un modèle de contrat ne peut être utilisé que si au moins un modèle de service reposant sur la même technologie de télécommunication est défini. De même, un modèle d'outils ne peut être utilisé que si au moins un modèle de contrat reposant sur la même technologie de télécommunication est défini. Les modèles de service, de contrat et d'outils possèdent donc comme lien commun la technologie de télécommunication. Par ailleurs, le modèle de contrat possède également un lien avec le modèle de service dans la mesure où y sont définis les types d'équipement (pointA, pointl, pointz) sur lesquels sont collectés les indicateurs de qualité, ces types d'équipement devant être choisis parmi ceux définis dans un modèle de service. Une modification de contrat n'induit pas une modification de service. Une modification de contrat fait suite, soit à une modification de service, soit à un besoin de modifier des données propres au contrat (seuils, rapports) qui n'ont pas d'impact avec le service. La création d'un service consiste à choisir un modèle de service et à affecter les équipements réels du service aux types d'équipements définis dans le modèle de service. La création d'un contrat consiste à choisir un modèle de contrat pour le service précédemment créé et à choisir parmi les équipements du service ceux qui seront utilisés pour mesurer les critères. La création d'un contrat peut inclure aussi des options consistant à modifier des critères prédéfinis dans le modèle de contrat, à choisir des outils, prédéfinis dans un modèle d'outils, pour mesurer ces critères, et à choisir des rapports, prédéfinis dans le modèle de contrat, pour rendre compte des mesures.

L'opérateur peut, dans l'étape S2 pouvant se répéter dans le temps et à partir du modèle 80 de service et du modèle 90 de contrat, générer respectivement un service 85 relatif à une technologie donnée et un contrat 100 relatif à cette technologie et spécifique entre l'opérateur et un client. Compte tenu de la remarque énoncée au paragraphe précédent, la génération du contrat 100 à partir du modèle 90 comprend aussi la génération des outils 120 à parti du modèle 110. À l'étape S2 l'opérateur, fournisseur du service, peut générer dans le temps plusieurs versions 85a, 85b,... 85m d'un service 85, plusieurs versions 100a, lob,..., 100n d'un contrat 100 et plusieurs versions 120a, 120b,..., 120n d'au moins un outil déterminé 120. Dans l'exemple décrit, les outils sont liés au modèle de contrat et on n'autorise pas de changer de version des outils pour un contrat déjà créé. Cependant, il serait possible de faire de modifier la version d'au moins un outil pour un contrat donné lorsque, notamment, le modèle d'outils est séparé du

modèle de contrat. L'invention concerne plus particulièrement la gestion coordonnée d'un service et d'un contrat et de leurs versions respectives. Selon l'étape S2 du procédé de la présente invention, la génération des versions est faite de façon à avoir à tout instant un service 85 et un contrat 100 définis chacun par un nombre maximal de deux de versions.

On appelle version de service et version de contrat un service et un contrat ayant chacun un contenu déterminé. Une version différente de service ou de contrat est définie par un contenu différent du contenu déterminé. Le contenu différent peut être une petite modification, par exemple de la date d'activation, et peut aussi être un changement substantiel de service et/ou de contrat. Cependant, dans l'exemple illustré, un service est fondé sur une technologie donnée, de sorte que les versions du service restent toujours définies à partir du même modèle 90 relatif la technologie donnée.

De même, le procédé illustré dans la figure 4 comprend une étape S3 de définition d'agenda pour déterminer l'application dans le temps des versions de service et de contrat. Toute version de service 85 et de contrat 100 incluent donc deux agendas respectifs 88 et 105. Les agendas 88 et 105 sont définis par l'opérateur avec l'aide de sa station graphique 44. De même, le procédé illustré comprend aussi une étape S4 de définition d'états pour déterminer à tout instant une coordination entre une version de service et une version de contrat. Toute version de service 85 et de contrat 100 incluent donc deux états respectifs 89 et 106. Les états 89 et 106 sont définis automatiquement à la création des versions, qui correspond à l'état enregistré registered défini ultérieurement.

La figure 10 est un diagramme illustrant conforme au langage unifié de modélisation UML actuellement bien adapté à la description d'objets dans la technologie orientée objets. Le service 85 est représenté par une classe Service et le contrat 100 est représenté par une classe Contract. Le diagramme illustre les relations de correspondance entre ces deux classes.

La classe Service contient : - des paramètres de trafic 87 optionnels, nommés TrafficParameters, liés à la technologie et représentés par une classe ServiceParameter, - au moins un client dans une liste de clients Customers ayant souscrit au service, représentée par une classe Company, et - au moins une version et au maximum deux versions 85a, 85b du service 85, représentées par une classe Service Version.

La classe Service Version contient les éléments modifiables du service, à savoir : - les dates (jours et heures) de validité du service, constituant l'agenda 88 et comprenant la date de départ StartOfService et la date de fin EndOfService, représentées par une classe Date, - au moins un composant 86, comprenant au moins un composant correspondant à au moins un point terminal EndPoints, au moins un composant optionnel correspondant à au moins un point intermédiaire intermediatePoints et au moins un composant optionnel d'application applicationComponent correspondant à la mesure de la qualité du service, représentés par une classe Component,

- et des contacts associés au service, comprenant au moins un contact providerContacts correspondant aux employés du fournisseur du service et au moins un contact customerContacts correspondant aux clients ayant souscrit au service, et représentés par une classe Person.

La classe Contract contient : - le service représenté par la classe Service, de sorte que le service est un attribut du contrat, et - au moins une version et au maximum deux versions 100a, 100b de contrat 100, représentées par une classe ContractVersion.

La classe ContractVersion contient les éléments modifiables du contrat, à savoir : - les dates de validité du contrat 100, constituant l'agenda 105 et comprenant la date de départ startOfContract et la date de fin stopOfContract, représentées par la classe Date ;

- un calendrier de mesure measurementCalendar représenté par une classe Calendar ; - au moins un critère SLA slaCriteria 101, tous représentés par une classe SLACriteria qui a pour éléments principaux : - un opérateur slaOperator représenté par une classe OperatorEnum, - un ensemble triggerRules de règles à déclencher en cas de non respect des seuils du critère SLA, représentées par une classe TriggerRule, - au moins un composant 104 de mesures, représenté par une classe Component et sur lequel sont effectuées les mesures pour le critère SLA. Un seul composant 104 est défini par type de composant théorique défini dans le modèle 90 de contrat. Il faut au moins le composant représentant la source (source) du sens de mesure dont le type

théorique est pointa. Un composant représentant la destination (destination) du sens de mesure peut être ajouté, dont le type théorique est point. On pourra étendre ce nombre de points de mesure à d'autres types théoriques de point de mesure, comme cela est indiqué par un trait discontinu à la figure 10. En d'autres termes, le composant 104 est choisi de façon que le point de mesure théorique du composant 86 du service 85 corresponde à celui défini dans le modèle 90 de contrat pour le critère SLA donné. D'une manière générale, un composant 104 dans le contrat 100 correspond à chaque type de point de mesure théorique dans le modèle 90 de contrat ; et - un indicateur QoS 103 représenté par une classe ComputedIndicator et spécialisé selon le sens de mesure wayToCompute (entre les deux points de la connexion) représenté par une classe WayToComputeComputed et auquel est associée une règle de calcul computation représentée par une classe Computation. La règle de calcul utilise un ensemble de paramètres parameters modélisés par une classe Indicator et ses classes héritées qui sont la classe d'indicateur calculé ComputedIndicator et la classe d'indicateur simple BasicIndicator. La valeur d'un indicateur simple est récupérée pour un sens de mesure, représenté par une classe WayToRetrieveBasic, sur un composant de service représenté par son type théorique par la classe TheoreticalMeasurementPoint.

Le composant du service réel est un des composants de mesure choisis précédemment pour le critère SLA. Les indicateurs servent à mesurer le service selon des règles définies dans le contrat. Les équipements de télécommunication sur lesquels sont collectés ces indicateurs sont des composants du service ; - et des rapports 106 de contenu défini hors ligne ofjLineReport, représentés par une classe Report et pour lesquels sont définis les destinataires addressees représentés par la classe Person. Les destinataires des rapports sont nécessairement des personnes préalablement définies comme contacts du service, puisque les personnes ne sont pas définies dans le contrat 100 mais dans le service 85.

Les objets représentés par les classes respectives Service et Contract et leurs versions respectives représentées par les classes Service Version et ContractVersion possèdent aussi des attributs respectifs représentés par une classe StatusEnum représentative de leur état administratif status défini ultérieurement.

À partir des modèles 80,90 et 110 de service, de contrat et d'outils sont générés lors de l'étape S2 du procédé au moins une version de service 85a et au moins une version de contrat 100a. D'autres versions peuvent être générées par la suite

conformément à l'étape S2. Selon cette étape et l'exemple choisi, deux versions 85a, 85b et 100a, 100b peuvent seulement coexister à tout instant donné. L'utilisation des versions va maintenant être décrite.

Afin de gérer facilement les évolutions des services et des contrats dans le temps, des versions y sont associées. À un moment donné, au maximum deux versions peuvent être définies pour chaque objet constitué par un service ou par un contrat. Une version, dite"courante", représente l'objet dans son état actuel et une version, dite "latente", représente l'objet dans un état futur. Une nouvelle version est associée à un objet quand il est nécessaire d'en modifier la définition, mais toute modification sur un objet (un service, par exemple) n'est pas forcément répercutée sur l'autre objet (le contrat, en l'occurrence). A tout moment, on peut donc avoir l'un des quatre cas suivants : - une version de service et une version de contrat, - une version de service et deux versions de contrat, - deux versions de service et une version de contrat, - ou deux versions de service et deux versions de contrat.

Les modifications de service impactant le contrat sont répercutées sur l'objet contrat 100. La répercussion est de préférence faite dès qu'une telle modification se produit, mais elle pourrait être déclenchée par une commande plus ou moins complexe.

La répercussion se traduit par la création d'une nouvelle version du contrat. Les modifications concernées dans l'exemple choisi peuvent concerner les trois cas suivants, seuls ou en combinaison : - la prolongation de la période de validité du service. Dans ce cas, et selon l'exemple choisi, s'ajoute une nouvelle version du contrat avec une période de validité prolongeant celle de la version précédente ; - un composant 86 du service 85, utilisé comme point de mesure d'un indicateur simple impliqué dans une règle de calcul d'un indicateur QoS ; et - le retrait d'un contact de service destinataire d'un rapport associé au contrat.

Deux autres cas particuliers de modifications se produisent avec répercussion. Le premier cas se produit lorsque le contrat possède déjà deux versions 100a et 100b de contrat et que la création d'une nouvelle version 100c est demandée après une modification de service. Dans ce cas, la version latente 100b de contrat est remplacée par la nouvelle version 100c, de sorte que les modifications prévues devront être reportées ultérieurement. Le second cas a lieu lorsqu'une modification de contrat, indépendante du

service, est requise et que deux versions de service 85a et 85b existent. Dans ce cas, un choix est fait pour valider la version de service sur laquelle va être établie la nouvelle version de contrat.

Chaque version de service et de contrat possède une période de validité délimitée par une date de début et une date de fin dans les agendas respectifs 88 et 105. La figure 10 illustre les correspondances de la date de début startOfService et de la date de fin endOfService entre la classe Service et la classe ServiceVersion, ainsi que les correspondances de la date de début startOfContract et la date de fin stopOfContract entre la classe Contract et la classe ContractVersion. Le procédé de gestion assure des correspondances cohérentes entre ces dates. Ainsi, deux versions successives de service assurent un service continu dans le temps. En d'autres termes, la version latente commence toujours avant la fin de la version courante. Le procédé assure aussi que la période de validité d'un contrat soit incluse dans la période de validité du service. Dans le cas où une version de contrat n'est valide que pour une version de service, le procédé assure que la période de validité de la version de contrat soit incluse dans la période de validité de la version de service correspondante. Dans tous les cas, le passage de la version courante à la version latente est effectué automatiquement en fonction de la période de validité de la version, par une prise en compte de la date de début d'activité de l'objet correspondant (service ou contrat).

On a vu en référence à la figure 4 que, selon l'étape S4 du procédé, des états de service et de contrat sont définis pour déterminer une coordination entre une version de service et une version de contrat à tout instant donné. L'exemple choisi distingue deux types d'état. Le premier type d'état, dit"interne", se rapporte au service 85 et au contrat 100 ainsi qu'aux versions correspondantes et représente l'état des définitions associées au service et au contrat. La définition d'un objet, ici le service 85 ou le contrat 100, est l'ensemble des informations nécessaires et suffisantes pour représenter l'objet et qui sont stockées dans l'inventaire 46 des services de télécommunication. L'état interne peut avoir deux valeurs, à savoir une valeur dite registered correspondant à l'état enregistré des informations sans avoir été validées, et une valeur dite validated correspondant à l'état validé des informations et assurant que la cohérence des informations est vérifiée et les informations sont enregistrées dans la base. Quand un objet présente deux versions, l'état interne de l'objet est déterminé par celui de la version courante. Le second type d'état, dit"externe", se rapporte uniquement au service et reflète

l'état réel du service. En d'autres termes, le service ne peut prendre un état externe que s'il a été validé (état interne de la version courante). L'état externe peut avoir l'une des quatre valeurs suivantes : activated, indiquant que le service est actif ; suspended, indiquant que le service est momentanément interrompu ; monitored, indiquant que le service est surveillé ; et terminated, indiquant que le service est définitivement arrêté. Les états registered, validated et suspended sont positionnés à la suite d'actions explicites de la part d'un acteur extérieur, telles que par exemple la création et/ou la validation de l'objet via un éditeur, et la suspension d'un service.

Dans l'exemple choisi, la validation d'un service permet de vérifier : que les dates de validité de versions successives assurent une continuité du service, par le fait que la date de début d'une version latente de service est antérieure à la date de fin de la version courante ; que la définition des composants de service 86 correspond à des éléments répertoriés dans l'inventaire 46 de la plate-forme 30 ; et que les personnes définies comme contacts du service sont des membres des sociétés fournisseur ou cliente du service. Il serait aussi possible d'utiliser l'inventaire de réseau d'une autre plate-forme d'administration que celle de l'exemple choisi (OpenMaster) pour déterminer la validité d'un composant de service. Lors de la validation d'un service, le contrôle dans l'inventaire de la plate-forme illustrée est effectué sur demande explicite d'un opérateur.

La figure Il est un diagramme illustrant les états du service 85 et leurs liens entre eux. Dans la figure, les états y sont indiqués en caractères gras dans des cases en trait gras tandis que leurs liens sont indiqués par des flèches et définis en caractères normaux dans des cases à trait normal. Comme illustré, l'état registered est déclenché par un utilisateur du système d'administration 10 à partir d'un événement de création de service nommé service creation, et peut soit passer à l'état validated lors d'un événement de validation nommé service validation déclenché par l'utilisateur, soit être annulé par lui ou automatiquement par l'application 42 du système d'administration 10, en déclenchant un événement nommé service deletion. De même, les états activated, monitored et terminated sont déterminés automatiquement par l'application 42 selon la nature des éléments qui composent l'objet et selon les conditions suivantes. Un événement d'activation de service, nommé service activation, est déclenché automatiquement à partir de l'état validated vers l'état activated quand la date de début de la version courante de service est atteinte. Un événement d'activation de surveillance, nommé monitoring activation, est déclenché automatiquement à partir de l'état activated vers l'état

monitored lorsque le service possède un contrat et que la date de début de la version courante de contrat est atteinte. En sens inverse, un événement de suspension de surveillance, nommé monitoring suspension, est déclenché à partir de l'état monitored vers l'état activated. Un événement de cessation de service, nommé service termination, est déclenché automatiquement à partir de l'état monitored vers l'état terminated quand la date de fin de la version courante de service est atteinte. De même, l'état activated peut passer directement à l'état terminated au déclenchement de l'événement service termination lorsque la date de fin de la version courante du service est atteinte et que le service ne nécessite pas de surveillance. On empêche ainsi ce cas de se produire, car les dates de contrat doivent toujours être incluses dans la dates de service, de sorte que l'arrêt de la surveillance se produit toujours avant l'arrêt du service. L'état terminated supprime automatiquement le service par déclenchement automatique de l'événement service deletion après une période de temps déterminée suivant l'arrêt du service. L'état monitored passe automatiquement à l'état suspended lors d'un événement de suspension de service, nommé service suspension. D'autre part, l'état activated peut passer automatiquement à l'état suspended par le déclenchement automatique de l'événement service suspension et, inversement, l'état suspended peut être automatiquement réactivé pour prendre l'état activated par le déclenchement de l'événement service activation.

Enfin, l'état suspended peut passer automatiquement à l'état terminated par déclenchement automatique de l'événement service termination.

En ce qui concerne le contrat, on a vu que le contrat 100 possède uniquement des états internes. En fait, il en est ainsi parce que le contrat de l'exemple choisi est intégré au service. Ainsi, l'état monitored indique qu'un contrat est lié au service pour déterminer les critères de surveillance. Cela signifie que dans d'autres cas un contrat pourrait avoir des états externes. D'autre part, la validation d'un contrat consiste à vérifier : que les dates de validité de versions successives assurent à la fois une continuité du contrat, par le fait que la date de début d'une version latente de contrat est antérieure à la date de fin de la version courante, et une continuité avec le service correspondant, par le fait que la période délimitée par les deux dates précédentes est incluse dans la période d'activité du service ; que les points de mesure des indicateurs sont des composants définis pour le service ; et que les personnes définies comme destinataires des rapports sont établies comme contacts du service.

La coordination entre une version de service et une version de contrat à partir des états de service et de contrat qui ont été définis précédemment va maintenant être décrite. Les actions autorisées sur un objet sont conditionnées par l'état de l'objet et des versions associées. La table de l'Annexe 1 indique les actions autorisées sur les objets relatifs au service, en fonction des états de service qui sont considérés comme états initiaux dans l'exemple choisi et/ou des versions associées, ainsi que les conséquences sur l'état de l'objet. La version 85a représente la version courante du service et la version 85b représente la version latente. Au moment de sa création, un service peut, selon le cas l, être simplement enregistré dans la base ou, selon le cas 2, être validé ultérieurement, ces deux actions pouvant également être combinées en une seule étape. Selon le cas 3, la modification d'un service non validé se traduit toujours par la modification de la version courante. En conséquence, un service non validé possède toujours une seule version.

Selon le cas 4, la modification d'un service validé possédant une seule version se traduit par l'ajout d'une seconde version alors que selon le cas 5 la modification d'un service validé possédant deux versions se traduit par la modification de la version latente. Selon le cas 5 également, la seconde version produite après une modification de service est simplement enregistrée, même lorsqu'elle est issue de la modification d'une version latente validée. Selon le cas 6, une validation de service est de nouveau à faire après la modification de service. Les actions de modification et de validation peuvent être combinées en une seule étape. Un service qui possède l'état activated (cas 7), monitored (cas 8) ou suspended (cas 9) peut toujours être modifié selon les règles établies pour un service validé. Selon le cas 10, un service qui possède l'état terminated est définitivement arrêté et ne peut pas être modifié. Il est à noter que l'état validated du service reflète toujours l'état de la version courante du service et ne prend pas en considération l'état de la version latente. Il est donc recommandé de valider systématiquement tout service après modification. Cependant l'application 42 proposera un outil permettant de détecter tout objet non validé.

La table de l'annexe 2 indique les actions relatives au contrat qui sont autorisées sur les objets de service en fonction des états initiaux des objets, ainsi que les conséquences sur les états finaux des objets. Selon le cas 1, un contrat ne peut pas être créé sur un service non validé. Selon les cas 2 et 3, l'activation de la surveillance du service ne peut pas être déclenchée si un contrat n'est pas associé au service, quel que soit l'état du service. Un contrat peut être créé sur un service validé (cas 4) ou activé (cas 5).

Selon le cas 6, l'état du contrat est enregistré tant que l'étape de validation n'a pas été réalisée. Selon le cas 7, la surveillance du service ne peut pas être déclenchée si le contrat associé n'est pas validé. L'activation de la surveillance du service possédant un contrat valide le fait passer automatiquement à l'état surveillé (cas 8), sauf si ce service est suspendu (cas 9). Dans ce dernier cas, le service doit d'abord être de nouveau activé pour passer automatiquement à l'état surveillé (cas 10). L'activation de la surveillance n'est pas possible sur un service terminé (cas 11). L'arrêt de la surveillance n'a de conséquence que sur un service surveillé (cas 12). Dans tous les autres cas (cas 13), l'état du service reste inchangé.

La figure 12 illustre un exemple d'application du procédé qui vient d'être décrit. On suppose que le 15 janvier 2000 est défini par un opérateur de télécommunication un service souscrit par un client et que le service correspond à une télécommunication entre Paris Londres selon la technologie de type IP défini en introduction. À cette date, le service est souscrit pour une durée de six mois, du ler février 2000 au 1er août 2000, et s'appuie sur deux composants techniques terminaux représentés par un point A nommé RouterLondon et un point Z nommé RouterParis. Des composants de service intermédiaires pour relayer la liaison sont également référencés sous les désignations Gateway, Gateway2 et Gateway3. On suppose aussi qu'un contrat est associé à ce service pour mesurer la qualité de service sur une période de quatre mois, du 1 mars 2000 au 1 juillet 2000, sur deux critères de qualité concernant respectivement le temps d'indisponibilité du service et nombre de paquets de données perdus. Ces deux critères sont calculés à partir d'indicateurs collectés sur les points terminaux du service RouterLondon et RouterParis. Des rapports seront également émis périodiquement à tous les contacts définis pour le service.

À partir des modèles correspondants 80 et 90 sont respectivement générés un objet de service 85 et un objet de contrat 100 définis par une première version correspondante 85a et 100a. Ces versions sont enregistrées pour prendre l'état registered, puis validées pour prendre l'état validated. Il a été supposé que la validité de la version 85a de service commence le 1 février 2000 et celle de la version 100a de contrat commence le 1"mars 2000. Au 15 janvier existent donc un objet 85 de service ayant l'état validated et la version 85a et un objet 100 de contrat ayant l'état validated et la version 100a.

Le 1 er février 2000, l'application de télécommunication 42 du système d'administration 10 mettant en oeuvre le procédé de l'invention met automatiquement à jour l'état du service par rapport à sa date de validité et le service passe à l'état actif. Au 1 er février existent un objet de service ayant l'état activé (activated) et la version 85a et un objet de contrat ayant l'état validé (validated) et la version 100a.

Le 1 er mars 2000, la mise en oeuvre du procédé de l'invention met automatiquement à jour l'état du service par rapport à la date de validité du contrat et fait passer le service à l'état surveillé (monitored). Au 1 er mars existent donc un objet de service ayant l'état monitored et la version 85a et un objet de contrat ayant l'état validated et la version 100a.

On suppose maintenant qu'au cours du mois de mars l'opérateur envisage de remplacer le composant intermédiaire Gateway2 au 1er avril 2000. L'opérateur effectue donc une modification du service pour établir et valider une nouvelle version 85b de service ayant une période de validité allant du 1 er avril 2000 au 1"août 2000. Étant donné que cette modification n'impacte pas la mesure des critères de qualité du service, aucune modification de contrat n'est à faire. Au 15 mars existent donc un objet de service ayant l'état externe monitored et deux versions 85a, 85b de service ayant chacune l'état interne validated et un objet de contrat ayant l'état validated et la version loofa.

Le 1"avril 2000, l'application 42 de télécommunication du système d'administration 10 remplace automatiquement la version courante 85a de service, devenue obsolète, par la version latente 85b dont la validité débute au 1 avril. À cette date existent donc un objet de service ayant l'état monitored et la version 85b et un objet de contrat ayant l'état validated et la version loofa.

On suppose qu'au cours du mois d'avril 2000 le point A RouterLondon doit être modifié. L'opérateur effectue alors une modification du service pour établir et valider une nouvelle version de service 85c ayant une période de validité allant du 30 avril 2000 au ler août 2000. Cette modification impactant la mesure des critères de qualité du service, une modification de contrat est donc faite pour établir et valider une nouvelle version 100b du contrat. Au 15 avril existent donc un objet de service ayant l'état monitored et deux versions 85b et 85c ayant chacune l'état validated et un objet de contrat ayant l'état validated et deux versions 1 00a et 1 00b ayant chacune l'état validated.

Le 30 avril 2000, l'application 42 de télécommunication remplace automatiquement les versions courantes de service 85b et 100a de contrat, devenues

obsolètes, par les versions latentes 85c et 100b dont la validité de chacune débute au 30 avril. À cette date existent donc un objet de service ayant l'état monitored et la version 85c et un objet de contrat ayant l'état validated et la version 100b.

Les exemples décrits et illustrés peuvent recevoir de nombreuses variantes à la portée de l'homme du métier. Le procédé de l'invention tel que décrit et illustré fait, selon l'étape SI, une construction en technologie orientée objets d'un modèle 80 de service et d'un modèle 90 de contrat qui a pour attribut un modèle 110 d'outils de contrôle de la qualité du service en référence au contrat. Il ressort à l'évidence de la description qui précède que cet attribut n'est pas nécessaire pour la mise en oeuvre du procédé de l'invention. Le procédé décrit et illustré comprend aussi la génération, selon l'étape S2 et à partir des deux modèles 80 et 90, d'un service 85 et d'un contrat 100. Le service inclut au moins un composant technique et on a vu qu'un tel composant peut constituer au moins un lien de correspondance entre le service 85 et le contrat 100. 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 générer au moins une unité telle qu'un service, un contrat et un outil de collecte.

Dans les exemples décrits, des liens de correspondance sont établis entre les périodes de validité du service et du contrat. Plus généralement, un service et un contrat peuvent inclure d'autres caractéristiques que la période de validité et au moins un des liens de correspondance peut aussi porter sur au moins l'une d'entre elles, par exemple sur les destinataires des rapports. D'autre part, dans l'exemple décrit, le fait que la classe de service est incluse dans la classe de contrat constitue un lien de correspondance. Ce lien est nécessaire dans la mesure où le contrat a besoin d'éléments définis uniquement dans le service, tels que les composants techniques du service comme points de mesure, ou les contacts du service comme destinataires des rapports. En outre, selon l'étape S2, le service 85 et le contrat 100 sont générés de façon à être définis chacun, à tout instant, en un nombre maximal de deux de versions. La gestion de deux versions de chacun des modèles permet de prévoir un changement de service et/ou de contrat et de coordonner le changement d'un service par rapport aux changements d'un contrat. En particulier, quand par exemple une modification relative au service intervient

sur le réseau 13, elle est répercutée au niveau du contrat, de sorte que la mesure de la qualité de service est en ligne avec l'état du service. Dans l'exemple choisi, l'une des deux versions constitue une version courante et l'autre constitue une version latente, préparatoire à une version courante future. En pratique, ces deux versions suffisent à tout instant. Mais il serait possible dans certains cas que deux alternatives se présentent comme versions latentes, l'une d'entre elles étant élue avant de devenir la version courante. On pourrait donc gérer deux versions de contrat par version de service, soit quatre versions de contrat pour un service donné. Par conséquent, un nombre maximal supérieur à deux de versions possibles à tout instant est envisageable. Ce nombre de versions présentes à tout instant est à distinguer du nombre de versions pouvant exister dans une période de temps. Dans ce dernier ca, on a vu précédemment qu'il pouvait normalement être supérieur à deux.

Le procédé décrit et illustré comprend aussi dans une étape S3 une définition des périodes respectives d'application dans le temps des versions du service 85 et du contrat 100 et, dans une étape S4, une définition d'états relatifs au service et au contrat pour déterminer à tout instant une coordination entre une version de service et une version de contrat. Bien que les états soient différents pour l'un ou l'autre, on a vu que cela peut ne pas être le cas. En bref, les états internes concernent les versions de service et de contrat, puisqu'ils portent sur la validité des deux objets (service et contrat). Les états externes concernent l'objet service et peuvent concerner l'objet contrat pour décider de l'état du service (activé ou surveillé), établissant ainsi un nouveau lien entre les deux objets (service et contrat). La gestion de ces états permet le contrôle, la mise en oeuvre et le suivi des évolutions couplées des versions de service et des contrat. Par conséquent, le procédé assure en permanence la mise en phase du service et du contrat avec la réalité du système de télécommunication 11 administré. Parmi les états possibles qui ont été décrits sont un état enregistré et un état validé. Selon l'option choisie, un contrat est défini si le service correspondant est validé. Plus généralement, il suffirait d'un état validé, déterminé après vérification, et d'au moins un état non validé. Dans ce cas, une vérification possible, telle qu'illustrée, est relative à l'inclusion de la période de validité d'une version du contrat dans celle d'une version du service correspondant pour que la version du contrat soit validée pour seulement cette version du service. L'inclusion de la période de validité du contrat est déterminée à la création du contrat en fonction de la période de validité du service, qui est connue au moment de l'inclusion, puisque le service est un attribut du

contrat. La vérification d'un contrat peut inclure la vérification d'éléments du service qui sont utilisés dans la définition du contrat, tels que les composants de service et les contacts de service. Au moins l'un des états possibles décrits sont des états d'activité du service (activated, monitored, suspended, terminated). Au moins un autre état possible est celui relatif à la surveillance du service selon au moins un critère, tel qu'un critère QoS de qualité de service dans l'exemple illustré. Dans l'exemple illustré, les agendas 88 et 105 sont respectivement définis directement dans le service 85 et le contrat 100 lors de l'étape S3. De même, les états 89 et 106 sont respectivement définis directement dans le service 85 et dans le contrat 100 lors de l'étape S4. Cependant, comme cela et indiqué par des traits discontinus à la figure 4, les agendas 88,105 et/ou les états 89,106 pourraient être définis à partir des modèles respectifs 80 et 90 de service et de contrat lors de l'étape S2.

Le modèle 80 de service contient un modèle 83 d'agenda et un modèle 84 d'état tandis que le modèle 90 de contrat contient un modèle 95 d'agenda et un modèle 96 d'état. Un modèle d'agenda pourrait définir le format du calendrier à utiliser pour la validité de l'objet. Le format de base de base peut inclure seulement la date de début et la date de fin, tandis qu'un format plus élaboré pourrait inclure plusieurs périodes d'application pouvant être discontinues. Un modèle d'état pourrait comprendre la liste des états possibles pour un objet et un automate d'états associé. L'étape SI de construction des modèles 80 et 90 serait donc modifiée en conséquence.

L'invention a donc aussi pour objet un système informatique mettant en oeuvre le procédé de l'invention. Dans l'exemple choisi, le système informatique est un système d'administration d'au moins une ressource telle que celles disponibles dans un système d'information et pouvant être une ressource de système et/ou de réseau et/ou d'application. Le système d'administration 10 illustré peut s'appliquer aussi à plusieurs opérateurs, par exemple par une société ayant pour clients des opérateurs de télécommunication.

ANNEXE 1

<tb>
<tb> Conditions <SEP> initiales <SEP> États <SEP> finaux
<tb> cas <SEP> Action <SEP> Nombre
<tb> État <SEP> service <SEP> État <SEP> service <SEP> Version <SEP> 1 <SEP> Version <SEP> 2
<tb> versions
<tb> 1 <SEP> Non
<tb> Création <SEP> d'un <SEP> service <SEP> Non <SEP> existant <SEP> 0 <SEP> registered <SEP> registered
<tb> existant
<tb> 2 <SEP> Validation <SEP> d'un <SEP> Non
<tb> registered <SEP> 85a <SEP> validated <SEP> validated
<tb> service <SEP> existant
<tb> 3 <SEP> Modification <SEP> d'un <SEP> Non
<tb> registered <SEP> 85a <SEP> registered <SEP> registered
<tb> service <SEP> existant
<tb> 4 <SEP> Modification <SEP> d'un
<tb> validated <SEP> 85a <SEP> validated <SEP> validated <SEP> registered
<tb> service
<tb> 5 <SEP> Modification <SEP> d'un
<tb> validated <SEP> 85b <SEP> validated <SEP> validated <SEP> registered
<tb> service
<tb> 6 <SEP>Validation <SEP> d'un
<tb> validated <SEP> 85b <SEP> validated <SEP> validated <SEP> validated
<tb> service
<tb> 7 <SEP> Modification <SEP> d'un
<tb> activated <SEP> 85a/85b <SEP> activated <SEP> validated <SEP> registered
<tb> service
<tb> 8 <SEP> Modification <SEP> d'un
<tb> monitored <SEP> 85a/85b <SEP> monitored <SEP> validated <SEP> registered
<tb> service
<tb> 9 <SEP> Modification <SEP> d'un
<tb> suspended <SEP> 85a/85b <SEP> suspended <SEP> validated <SEP> registered
<tb> service
<tb> 10 <SEP> Modification <SEP> d'un
<tb> terminated <SEP> 85a/85b <SEP> Action <SEP> non <SEP> autorisée
<tb> service
<tb>

ANNEXE 2

<tb>
<tb> Conditions <SEP> initiales <SEP> États <SEP> finaux
<tb> Action
<tb> cas <SEP> Etat <SEP> service <SEP> Etat <SEP> contrat <SEP> Etat <SEP> service <SEP> Etat <SEP> contrat
<tb> 1 <SEP> Création <SEP> d'un <SEP> contrat <SEP> registered <SEP> Non <SEP> existent <SEP> Action <SEP> non <SEP> autorisée
<tb> 2 <SEP> Activation <SEP> de <SEP> la <SEP> validated <SEP> Non <SEP> existant <SEP> Action <SEP> non <SEP> autorisée
<tb> surveillance
<tb> 3 <SEP> Activation <SEP> de <SEP> la <SEP> activated <SEP> Non <SEP> existant <SEP> Action <SEP> non <SEP> autorisée
<tb> surveillance
<tb> 4 <SEP> Création <SEP> d'un <SEP> contrat <SEP> validated <SEP> Non <SEP> existant <SEP> validated <SEP> registered
<tb> 5 <SEP> Création <SEP> d'un <SEP> contrat <SEP> activated <SEP> Non <SEP> existant <SEP> validated <SEP> registered
<tb> 6 <SEP> Validation <SEP> d'un <SEP> contrat <SEP> validated <SEP> registered <SEP> validated <SEP> validated
<tb> 7 <SEP> Activation <SEP> de <SEP> la <SEP> activated <SEP> registered <SEP> Action <SEP> non <SEP> autorisée
<tb> surveillance
<tb> 8 <SEP> Activation <SEP> de <SEP> la <SEP> activated <SEP> validated <SEP> monitored <SEP> validated
<tb> surveillance
<tb> 9 <SEP> Activation <SEP> de <SEP> la <SEP> suspended <SEP> validated <SEP> suspended <SEP> validated
<tb> surveillance
<tb> 10 <SEP> Activation <SEP> du <SEP> service <SEP> (suite <SEP> suspended <SEP> validated <SEP> monitored <SEP> validated
<tb> à <SEP> 9)
<tb> 11 <SEP> Activation <SEP> de <SEP> la <SEP> terminated <SEP> tout <SEP> état <SEP> Action <SEP> non <SEP> autorisée
<tb> surveillance
<tb> 12 <SEP> Arrêt <SEP> de <SEP> la <SEP> surveillance <SEP> monitored <SEP> validated <SEP> activated <SEP> validated
<tb> 13 <SEP> Arrêt <SEP> de <SEP> la <SEP> surveillance <SEP> tout <SEP> état <SEP> sauf <SEP> validated <SEP> inchangé <SEP> validated
<tb> monitored
<tb>

Claims

Revendications 1. Procédé de gestion coordonnée, 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) et d'un contrat technique (100) correspondant au service, caractérisé en ce qu'il comprend les étapes de : construire (SI) en technologie orientée objets un modèle (80) de service et un modèle (90) de contrat ; générer (S2), dans les moyens de mémoire (15) et à partir des deux modèles (80,90), le service (85) et le contrat (100) de façon à être définis chacun, à tout instant, en un nombre maximal au moins égal à deux de versions (85a, 85b ; 100a, 100b) ; définir (S3) dans les moyens de mémoire (15) des périodes d'application (88,105) desdites versions (85a, 85b ; 100a, 100b) ; et définir (S4), pour les versions (85a, 85b ; 100a, 100b) et dans les moyens de mémoire (15), des états (89,106) pour déterminer à tout instant une coordination entre une version (85a) de service et une version (lOOa) de contrat.
2. Procédé selon la revendication 1, caractérisé en ce que le service (85) est défini dans une classe (Service) incluse dans la classe (Contract) relative au contrat.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les deux versions du nombre maximal de versions comprennent une version courante et une version latente, dont les périodes de validité ont une partie commune.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que les versions (85a,

85b) de service et les versions (lOOa, 100b) de contrat sont définies dans des classes respectives (ServiceVersion, ContractVersion) contenues dans des classes respectives (Service, Contract) représentatives du service et du contrat.
5. Procédé selon l'une des revendications 4, caractérisé en ce que les périodes d'application des versions sont définies dans une classe (Date) commune à deux classes (ServiceVersion, ContractVersion) représentatives des versions de service et de contrat.

<Desc/Clms Page number 43>
6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que les états comprennent un état validé (validated), déterminé après une vérification, et un état non validé (registered).
7. Procédé selon la revendication 6, caractérisé en ce que le contrat est défini si le service correspondant est validé.
8. Procédé selon la revendication 6 ou 7, caractérisé en ce que la vérification est relative à l'inclusion de la période de validité d'une version du contrat dans celle d'une version du service correspondant pour que la version du contrat soit validée pour seulement ladite version du service.
9. Procédé selon l'une des revendications 6 à 8, caractérisé en ce que la vérification du contrat inclut la vérification d'éléments du service qui sont utilisés dans la définition du contrat.
10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce qu'au moins l'un des états est représentatif de l'états d'activité du service (activated, monitored, suspended, terminated).
11. Procédé selon l'une des revendications 1 à 10, caractérisé en ce qu'au moins l'un (monitored) des états est relatif à la surveillance du service selon au moins un critère défini dans le contrat associé, tel qu'un critère (QoS) de qualité du service.
12. Procédé selon l'une des revendications 1 à 11, caractérisé en ce que les états sont définis dans une classe (StatusEnum) commune à deux classes (Service, Contract) représentatives du service et du contrat ainsi qu'à deux classes (ServiceVersion,

ContractVersion) représentatives des versions correspondantes.
13. Procédé selon l'une des revendications 1 à 11, caractérisé en ce que les périodes d'application (88,105) et/ou les états (89,106) sont définis lors de l'étape (S2) de génération du service (85) et du contrat (100) à partir de modèles respectifs (83,95 ;

<Desc/Clms Page number 44>

90).

84,96) définis lors de l'étape (SI) de construction des modèles correspondants (80,
14. Système informatique incluant au moins un processeur (14) et des moyens de mémoire (15), caractérisé en ce qu'il met en oeuvre le procédé défini par l'une des revendications précédentes.
15. Système selon la revendication 14, caractérisé en ce qu'il constitue un système d'administration d'au moins une ressource.