L UNIVERSITÉ BORDEAUX I

N d ordre : 4461 THÈSE présentée à L UNIVERSITÉ BORDEAUX I ÉCOLE DOCTORALE DE MATHÉMATIQUES ET D INFORMATIQUE Par Jingxian LU POUR OBTENIR LE GRADE DE DOCTEUR SPÉCIALITÉ : Informatique L auto-diagnostic dans les réseaux autonomes. Application à la supervision de services multimédia sur réseau IP de nouvelle génération Soutenue le : 19 Décembre 2011 Après avis des rapporteurs : Eric Fabre................. Directeur de recherche, INRIA Pascal Lorenz............. Professeur, Université de Haute Alsace Devant la commission d examen composée de : Eric Fabre................. Zoubir Mammeri.......... Pascal Lorenz............. Toufik Ahmed............. Yacine Ghamri-Doudane... Christophe Dousson....... Francine Krief............. Directeur de recherche, INRIA Professeur, Université Paul Sabatier (Président du Jury) Professeur, Université de Haute Alsace Professeur, IPB, Université Bordeaux Maître de conférences (HDR), Université Paris-Est Expert sénior, France Télécom (Responsable de thèse) Professeur, IPB, Université Bordeaux (Directrice de thèse)

i Titre : L auto-diagnostic dans les réseaux autonomes. Application à la supervision de services multimédia sur réseau IP de nouvelle génération Résumé : Les réseaux autonomes représentent un intérêt certain pour les opérateurs de télécommunications. L auto-diagnostic, pour la détection des pannes et des dysfonctionnements, est une fonction critique dans le cadre de ces réseaux. Nous avons opté pour l utilisation d un diagnostic à base de modèles car il permet un diagnostic automatique, distribué et adapté à l architecture des réseaux autonomes. Ce diagnostic est basé sur une modélisation explicite des comportements normaux ou anormaux du système. Nous utilisons ensuite un algorithme de diagnostic générique qui s appuie sur cette modélisation pour réaliser l auto-diagnostic. La modélisation utilisée est à base de graphe causal. Elle est une représentation intuitive et efficace des relations de causalités qui existent entre les observations et les pannes. Notre algorithme d auto-diagnostic qui s appuie sur l utilisation de graphes causaux, fonctionne sur le principe suivant : lorsqu une alarme est déclenchée, l algorithme est lancé et, grâce aux relations de causalité entre l alarme et les causes, les causes primaires vont pouvoir être localisées. Puisque le graphe causal permet une modélisation modulaire et extensible, il est possible de le séparer ou de le fusionner pour répondre aux besoins des services et architectures de communication. Cette caractéristique nous permet de proposer un algorithme distribué qui s adapte à l architecture des réseaux autonomes. Nous avons, ainsi, proposé un algorithme d auto-diagnostic qui permet de réaliser le diagnostic distribué correspondant à l architecture du réseau autonome afin de réaliser un diagnostic global. Nous avons implémenté cet algorithme sur une plateforme OpenIMS, et nous avons montré que notre algorithme d auto-diagnostic pourrait être utilisé pour différents types de service. Les résultats obtenus correspondent bien à ce qui est attendu. Mots clés : auto-diagnostic, IMS, VoIP, algorithme de diagnostic distribué.

ii Title : Self-diagnosis in autonomic networks. Application to the supervision of multimedia services on next generation IP network Abstract : The autonomic networks show certain interest to manufacturers and operators of telecommunications. The self-diagnosis, the detection of failure and malfunction, is a critical issue in the context of these networks. We choose based-model diagnosis because it allows an automatic diagnosis, and is suitable to distributed network architecture. This diagnosis is based on an explicit modeling of normal and abnormal behavior of the system. We then use a generic diagnostic algorithm that uses this modeling to perform self-diagnosis. The modeling used is based on causal graph. It is an intuitive and efficient representation of causal relationships between observations and failures. The self-diagnosis algorithm we proposed based on the use of causal graphs. The principle is : when an alarm is triggered, the algorithm is run and, with the causal relationships between alarms and causes, the principal causes will be located. Since the causal graph modeling allows a modular and extensible model, it is possible to separate or merge according to the needs of services and communication architectures. This feature allows us to propose a distributed algorithm that adapts to autonomic network architecture. We have thus proposed a self-diagnosis algorithm that allows for the diagnosis corresponding to the autonomic network architecture to realize a global diagnosis. We have implemented this algorithm on a platform OpenIMS, and we showed that our self-diagnostic algorithm could be used for different types of services. The results of implement correspond to what is expected. Keywords : self-diagnosis, IMS, VoIP, distributed diagnosis algorithm.

iii Remerciements Je commencerai naturellement par remercier le professeur Francine Krief et Monsieur Christophe Dousson, pour leur encadrement. Ils n ont ménagé ni leur temps, ni leur expérience pour que ce travail aboutisse. J ai pris beaucoup de plaisir à travailler avec deux personnes aussi sympathiques. J adresse également mes plus sincères remerciements aux professeurs Eric Fabre et Pascal Lorenz qui m ont fait l honneur d évaluer les travaux de cette thèse. Je remercie aussi l ensemble des membres du jury pour leur présence lors de ma soutenance. Je voudrais remercier aussi tous les membres de l équipe SID et tout le personnel administratif d Orange Labs et du LaBRI. Sur un plan plus personnel, je tiens à remercier tout particulièrement mes parents, mon Qidong et tous les membres de ma famille. Je les remercie pour leur soutien de tous les jours, leur compréhension dans les moments difficiles. Sans eux, certains jours auraient été bien plus noirs. Encore un grand MERCI à toutes et à tous!

iv Liste des publications Conférences internationales avec actes Towards an Autonomic Network Architecture for Self-healing in Telecommunications Networks, Jingxian Lu, Christophe Dousson, Benoit Radier, Francine Krief, In proceeding of 4th International Conference on Autonomous Infrastructure, Management and Security (AIMS 10), 21 to 25 June 2010 in Zurich, Switzerland. A Self-diagnosis Algorithm based on Causal graphs, Jingxian Lu, Christophe Dousson, Francine Krief, In proceeding of 7th International Conference on Autonomic and Autonomous Systems (ICAS 2011), 22 to 27 2011 in Venice, Italy. Un algorithme distribué à base de graphe causal pour la fonction d autodiagnostic des réseaux autonomes, Jingxian Lu, Christophe Dousson, Francine Krief. 25ème Congrès DNAC : De Nouvelles Architectures pour les Communications, 16 au 18 Novembre 2011. Distributed self-diagnosis algorithm for VoIP service over IMS network, Jingxian Lu, Christophe Dousson, Francine Krief. In 9th IEEE - RIVF International Conference on Computing and Communication Technologies, in Ho Chi Minh City, Vietnam, 2012. (Submitted) Self-diagnosis architecture for QoS and QoE management in IPTV services over IMS network, Jingxian Lu, Christophe Dousson, Francine Krief, In Third International Conference on Communications and Networking, in Hammamet, Tunisia, 2012. (Submitted)

Table des figures 2.1 Les propriétés de la gestion autonome................. 15 2.2 Les 4 objectifs principaux d un système autonome.......... 16 2.3 Le processus de l auto-rétablissement.................. 18 2.4 L architecture d une gestion autonome (Boucle autonome)...... 20 2.5 Les défis clés du projet UniverSelf................... 28 3.1 La gestion des pannes.......................... 34 3.2 Principe du diagnostic à base de modèles............... 40 4.1 L architecture NGN........................... 49 4.2 L architecture IMS............................ 51 4.3 La structure interne du cœur IMS et les interfaces.......... 52 4.4 La signalisation du processus de VoIP................. 58 4.5 Architecture IMS-IPTV......................... 60 5.1 L architecture du gestionnaire autonome chargé de l auto-diagnostic 67 5.2 Représentation graphique des cinq types de nœuds du graphe causal 69 5.3 Représentation graphique des liens Cause sûre et Cause possible 70 5.4 Graphe causal pour IMS (extrait).................... 71 5.5 Illustration des définitions S, S, S 1 et S 1............... 75 6.1 Exemple d un diagnostic insuffisant................... 85 7.1 Différentes architectures d un système de diagnostic......... 93 7.2 Frontières des effets et des causes................... 96 7.3 Architecture d un réseau autonome chargé de l auto-diagnostic... 100 8.1 OpenIMS................................. 106 8.2 Infrastructure IMS open source..................... 112 8.3 Le graphe causal global......................... 113 8.4 Le graphe causal restreint à HSS et AS................. 114 8.5 Le graphe causal utilisé......................... 115

vi Table des figures 8.6 Interface administrative de Mobicents................. 116 8.7 Interface de gestion des Sip Servlets de Mobicents.......... 117 8.8 Critères de filtrage initiaux (IFC).................... 118 8.9 Profil de service pour le service déployé sur Mobicents........ 119 8.10 Flux d appel lors de l invocation d un serveur d application..... 120 8.11 Enregistement du client «a»....................... 121 8.12 L alarme declenchée au niveau de AS1................. 122 8.13 Les 3 types de nœud........................... 122 8.14 Hypothèse 2 au niveau de AS1..................... 123 8.15 Hypothèse 3 au niveau de AS1..................... 123 8.16 L hypothèse 7 exige la communication avec HSS........... 124 8.17 Lancement des Tests........................... 125 8.18 Le résultat concernant l hypothèse 7.................. 126 8.19 Les résultats concernant l hypothèse 4................. 127 8.20 Les résultats concernant l hypothèse 5................. 128 8.21 Les résultats concernant l hypothèse 6................. 129 8.22 Le graphe causal pour le service IPTV................. 130

Table des matières 1 Introduction 1 1.1 Contexte Général............................. 1 1.2 Objectif.................................. 3 1.3 Plan de la thèse.............................. 4 I Etat de l art 7 2 Réseaux autonomes 9 2.1 Introduction................................ 9 2.2 Les principaux concepts......................... 12 2.2.1 Historique de l autonomic.................... 12 2.2.2 Les termes techniques...................... 13 2.2.3 Les objectifs de la gestion autonome.............. 16 2.3 Architecture de la gestion autonome.................. 20 2.3.1 Les ressources gérées....................... 21 2.3.2 Les interfaces de gestion..................... 21 2.3.3 Les gestionnaires autonomes................... 22 2.4 Les projets de recherche......................... 25 2.4.1 Projets européens........................ 26 2.4.2 Projets industriels et académiques............... 28 2.4.3 Synthèse.............................. 30 2.5 Conclusion................................ 30 3 Diagnostic dans les réseaux de télécommunications 31 3.1 Réseaux de télécommunications..................... 31 3.1.1 L Internet............................. 32 3.1.2 La convergence des réseaux................... 33 3.2 La gestion des pannes.......................... 34 3.2.1 Définition d une panne...................... 35 3.2.2 Approches utilisées pour la gestion des pannes........ 36

viii Table des matières 3.3 Vision IA du Diagnostic......................... 37 3.3.1 Introduction........................... 37 3.3.2 Les deux principales approches................. 37 3.3.3 Intérêt du diagnostic à base de modèles pour les réseaux autonomes.............................. 45 3.4 Conclusion................................ 45 4 Les services multimédia sur réseau IP de nouvelle génération 47 4.1 Introduction à IMS............................ 47 4.1.1 Motivation pour l utilisation de l IMS............. 49 4.1.2 L architecture IMS........................ 50 4.1.3 Cœur du réseau IMS....................... 52 4.1.4 Protocoles utilisés dans l IMS.................. 54 4.1.5 Conclusion............................ 56 4.2 Service VoIP............................... 56 4.3 Service IPTV............................... 58 4.4 Conclusion................................ 60 II Proposition d une méthode d auto-diagnostic 63 5 Diagnostic avec Graphes Causaux 65 5.1 Introduction................................ 65 5.2 Architecture du gestionnaire autonome................. 67 5.3 Modélisation de la connaissance par le graphe causal......... 68 5.3.1 Nœuds causaux.......................... 68 5.3.2 Liens causaux........................... 70 5.3.3 Exemple.............................. 70 5.4 Le processus de diagnostic du diagnostiqueur............. 72 5.5 Définitions et notations......................... 74 5.5.1 Relations de causalité, graphe causal.............. 74 5.5.2 Pannes, Symptômes et Diagnostic............... 75 5.5.3 Diagnostics minimaux...................... 76 5.6 Conclusion................................ 77

Table des matières ix 6 L Algorithme de Diagnostic de base 79 6.1 Introduction................................ 79 6.2 Recherche des diagnostics........................ 80 6.3 Algorithme de recherche des diagnostics minimaux.......... 82 6.4 Alarmes absentes ou perdues...................... 83 6.5 Introduction des Tests.......................... 84 6.5.1 Proposition initiale pour le lancement des Tests........ 84 6.5.2 Solution améliorée pour un diagnostic insuffisant....... 85 6.5.3 Politiques de lancement des Tests............... 88 6.6 Cause sûre et cause possible....................... 88 6.7 Conclusion................................ 89 7 Distribution de l algorithme de diagnostic 91 7.1 Systèmes distribués............................ 91 7.2 Architectures pour un système de diagnostic.............. 94 7.3 Principe.................................. 95 7.4 Algorithme distribué........................... 98 7.5 Architecture du réseau autonome.................... 100 7.6 Conclusion................................ 101 III Implémentation et évaluation 103 8 Implémentation dans un environnement IP de nouvelle génération105 8.1 Introduction................................ 106 8.2 Description des composants....................... 106 8.2.1 Le cœur de réseau Open IMS.................. 106 8.2.2 Les terminaux.......................... 107 8.2.3 La plate-forme de développement................ 108 8.3 Implémentation.............................. 111 8.3.1 Scénario d implémentation.................... 111 8.3.2 Flux d appel........................... 120 8.3.3 Les résultats de tests....................... 121 8.4 Extension proposée pour le service IPTV............... 130

x Table des matières 8.5 Synthèse des résultats et analyse.................... 131 8.6 Conclusion................................ 131 9 Conclusion et perspectives 133 A 137 A.1 Représentation d un graphe causal................... 137 Bibliographie 143

CHAPITRE1 Introduction 1.1 Contexte Général Au tout début, les opératrices du réseau téléphonique se chargeaient de mettre en relation manuellement les clients qui voulaient rentrer en communication. A partir des années 1920, le développement des réseaux est devenu de plus en plus rapide. Ce développement spectaculaire nécessita le déploiement, l exploitation et l administration d infrastructures complexes et distribuées. L intervention manuelle étant devenue difficile voire impossible, la nécessité de décharger l opérateur manuel de la fonction de contrôle a entraîné l introduction des autocommutateurs. Le monde des technologies de la communication, de l information en général et des réseaux en particulier, a connu une deuxième grande révolution, au même titre que ce qu elle a connu lors de l automatisation du plan de contrôle, avec le réseau Internet. Depuis la fin du XX e siècle, nous vivons un développement sans précédent des nouvelles technologies. Les réseaux sont devenus accessibles de partout (réseaux ubiquitaires). Les services disponibles deviennent de plus en plus variés : la VoIP (voix sur IP), l IPTV (télévision sur IP), la VOD (vidéo à la demande), etc. Ces services dépendent fortement de la QoS (Qualité de Service). Les terminaux de communication sont de plus en plus nombreux et hétérogènes (PC, Mobiles et Smartphones, etc.). La tendance actuelle est désormais à la convergence entre les différents types de réseaux : réseaux fixes et mobiles, réseaux téléphoniques et réseaux informatiques, réseaux cellulaires et réseaux sans fil (WiFi). Cette convergence ne signifie pas l uniformisation par une seule technologie, mais l interconnexion entre celles-ci via des tentatives d uniformisation des protocoles (IP, SIP,...). Afin d assurer la qualité

2 Chapitre 1. Introduction de service, la nécessité de techniques innovantes est donc cruciale. Ces évolutions rendent la gestion du cœur du réseau de plus en plus complexe, il faut en effet prendre en compte les exigences des différents types de services utilisés par les terminaux communicants. Alors que la gestion traditionnelle des réseaux se faisait de manière centralisée et que l optimisation des paramètres de configuration était réalisée par des experts humains, l ensemble des paramètres à considérer est maintenant devenu tellement important et complexe qu il est impossible de le gérer manuellement. Le diagnostic et la correction des pannes pour la gestion de réseaux deviennent de véritables défis avec un cœur de réseau complexifié par la traversée de différents services et l hétérogénéité des équipements. Avec le développement rapide des technologies informatiques et de télécommunication, les capacités de traitement des données des ordinateurs ont sensiblement augmenté et l architecture de connexion entre les équipements s est complexifiée (réseaux fixes, mobiles, sans fil). Quand une panne ou une erreur se produit à un endroit d un réseau, il est possible qu elle ait des répercussions dans le réseau entier. Ceci rend difficile la tâche qui consiste à trouver la cause de la panne et donc de la dépanner en temps voulu. Une panne peut influencer les différents composants ou les autres opérations du réseau. Il est évident que l accroissement des délais pour identifier les raisons d une panne et des délais de réparation vont augmenter le coût de réparation. La seule véritable option pour protéger les équipements du réseau et pour améliorer le service du réseau contre ces pannes, est la prévention et la détection automatique et évolutive. Les administrateurs ne doivent pas seulement configurer les équipements pour interconnecter les réseaux, mais ils doivent aussi assurer la stabilité des systèmes. Chaque mise à jour d un équipement peut engendrer des perturbations et des pannes. Cette complexité conduit souvent à retarder le changement de systèmes, même s ils sont désuets. D autre part, la formation pour les techniciens et les experts capables de gérer les équipements réseaux et d optimiser les configurations est certainement une source de charge importante pour les entreprises et les opérateurs réseau. Pourtant, l un des objectifs de la gestion du réseau est de réduire les coûts (Total Cost Ownership). La gestion du réseau par des techniciens et experts semble également augmenter les temps d indisponibilité durant les diagnostics et les optimisations. En contrepartie, la fiabilité du système permet de réduire les coûts.

1.2. Objectif 3 Ainsi, 40% des pannes de services sont causées par des problèmes de configuration réalisées par les opérateurs [Patterson 2002] qui doivent prendre des décisions trop rapidement [Brown & Patterson. 2001]. La réalisation de la gestion autonome est un nouveau concept. Le but est de permettre aux équipements de se gérer automatiquement tout en respectant des politiques de haut niveau fournies par l administrateur. Ce nouveau concept doit permettre de diminuer la complexité de la gestion des équipements et réduire l activité humaine dans la boucle de gestion des réseaux. C est l équivalent de la révolution du téléphone avec l automatisation du plan de contrôle dans les années 20, mais cette fois-ci sur la gestion des réseaux de communications. Ce concept se base sur quatre fonctions autonomes principales que sont l auto-configuration, l auto-optimisation, l auto-protection et l auto-rétablissement. L idée d utiliser les systèmes autonomes, qui ont la capacité de s adapter à leur environnement sans interventions humaines pour réaliser des fonctions automatiques, est entrain d être développée et de s affiner continuellement. Le plan de connaissance proposé est basé sur cette idée. En effet, il s agit d une structure qui permet de gérer le réseau en utilisant la connaissance du réseau et des processus autonomes. Durant ces dernières années, le diagnostic a joué un rôle de plus en plus important dans la gestion du réseau. La réalisation de l auto-diagnostic a un attrait considérable pour les opérateurs, puisqu ils peuvent réduire les coûts d exploitation comme mentionnés ci-dessus, ainsi qu améliorer l efficacité et la rapidité du dépannage. Alors que le diagnostic traditionnel basé souvent sur le système expert ne répond pas aux besoins d évolution constante des réseaux d aujourd hui, au contraire, le diagnostic à base de modèle peut être modifié et mis à jour en exploitant le plan de connaissance et correspond à la demande de développement des réseaux futurs. Mes travaux de thèse se sont centrés sur cette problématique. 1.2 Objectif Cette thèse s intéresse à la problématique de l auto-diagnostic, et plus précisément à étudier dans quelle mesure les approches du diagnostic peuvent être utilisées dans le cadre des réseaux autonomes. Nous proposons ainsi une étude et une série de

4 Chapitre 1. Introduction propositions pour utiliser le diagnostic à base de modèle dans les réseaux autonomes. Notre cas d étude à porté sur l auto-diagnostic pour les applications s appuyant sur un réseau IMS pour lequel nous avons développé un algorithme d auto-diagnostic distribué. Dans ce contexte, le travail inclut : La détection au plus tôt de situations anormales dégradant le niveau de service qui pourraient se manifester par une alarme ; Le diagnostic des causes primaires de ces défaillances (dysfonction d équipement, panne de logiciel, problème de base de données, panne de synchronisation, panne de configuration, etc.) ; La définition du modèle (graphe causal) pour expliciter le plan de connaissance concernant les pannes, les causes et les relations causales entre elles ; La réalisation de l algorithme d auto-diagnostic distribué capable de tenir compte de l architecture du réseau autonome. Ce travail se situe principalement dans un cadre d exécution simple de service VoIP, mais peut facilement être étendu pour d autres services tels que l IPTV. L auto-diagnostic des pannes liées à des alarmes rentre dans le cadre de ce travail de thèse. 1.3 Plan de la thèse Le présent document de thèse est organisé en 8 chapitres dont les contenus respectifs sont listés ci-dessous. Chapitre 2 : Dans ce chapitre, nous présentons un état de l art des réseaux autonomes en commençant par l historique et les motivations conduisant à la mise en œuvre de réseaux autonomes. Cet historique permet de montrer l importance et la nécessité de réaliser des réseaux autonomes dans les réseaux de futures générations. Ce chapitre précise également l architecture de base de la gestion autonome ainsi que celle des éléments autonomes selon la vision d IBM. Ce chapitre se termine par la présentation des projets européens concernant la thématique des réseaux autonomes. Cette présentation permet ainsi d introduire les concepts des réseaux autonomes pour réaliser les fonctions de gestion autonome.

1.3. Plan de la thèse 5 Chapitre 3 : Ce chapitre introduit d abord l architecture des réseaux de télécommunications. Ensuite, ce chapitre présente nos travaux de recherche qui se situent dans l environnement des réseaux de télécommunications. Ce chapitre présente également l aire fonctionnelle de gestion des pannes car nos travaux se focalisent sur cette aire pour réaliser l auto-diagnostic. Nous introduisons ensuite le diagnostic, présentons son objectif et proposons une définition d une panne. Nous comparons ensuite les deux principales approches pour le diagnostic s appuyant sur l Intelligence Artificielle (IA) en montrant les avantages et les inconvénients de chacune de ces approches. Nous montrons également que le diagnostic à base de modèles est mieux adapté pour notre architecture de réseau. Chapitre 4 : Ce chapitre présente les services multimédia dans un environnement IMS. D abord, nous introduisons les motivations pour l utilisation de l IMS, puis présentons et illustrons l architecture IMS et la structure de cœur IMS. Le cœur du réseau IMS est utilisé pour le contrôle des sessions média. Ensuite, les protocoles utilisés dans IMS (comme SIP, AAA, etc.), standardisés par l IETF, sont présentés. Enfin, ce chapitre se consacre, dans la partie suivante, à l étude des services VoIP et IPTV dans un environnement IMS afin d y introduire la réalisation de l autodiagnostic. Chapitre 5 : Dans ce chapitre, nous présentons la modélisation de la causalité des pannes par un graphe causal et présentons aussi le principe général du diagnostic qui sera formellement mis en œuvre par les algorithmes introduit aux chapitres 6 et 7. Ce chapitre décrit également les définitions et notations nécessaires à la formalisation du processus de diagnostic. Chapitre 6 : Ce chapitre présente l algorithme de base du diagnostic mis en œuvre par le diagnostiqueur ainsi que les différentes extensions proposées afin de prendre en compte les tests en cours de diagnostic. L algorithme présenté dans ce chapitre permet de calculer l ensemble de tous les diagnostics, il s appuie sur un ensemble d hypothèses et se termine lorsqu il ne reste aucun nœud à expliquer dans les hypothèses (C est-à-dire lorsque les hypothèses sont closes.). Nous avons aussi tenu compte du cas des alarmes absentes ou perdues et du cas où les observables

6 Chapitre 1. Introduction ne remontent pas spontanément mais correspondent à des tests à déclencher (ou à des requêtes à exécuter). Le développement de notre algorithme peut passer par le choix du test à exécuter, c est-à-dire qu une partie de la politique de diagnostic réside alors dans le choix du test à effectuer. Chapitre 7 : Ce chapitre décrit le principe de la distribution de l algorithme et explicite l algorithme formel. La technique utilisée pour exécuter le diagnostic est dépendant de l architecture du système de diagnostic, donc nous présentons d abord les différentes architectures de diagnostic : centralisée, hiérarchique, distribuée et hiérarchique et distribuée. Dans ce chapitre, l algorithme montré repose sur l architecture distribuée. L algorithme distribué que nous proposons permet de fournir des explications à des alarmes déclenchées en tenant compte des différents composants d un système autonome. L algorithme permet également de faire la communication entre les différents diagnostiqueurs locaux. La communication est réalisée par les nœuds de «connexion», il s agit de trouver une explication distante pour ce nœud et de vérifier que l état de ce nœud n est pas compromis vis-à-vis d un observable distant. Chapitre 8 : Dans ce chapitre, nous présentons des descriptions des composants utilisés pour réaliser l implémentation de notre algorithme d auto-diagnostic sur une plate-forme IMS (OpenIMS). Nous présentons ensuite un descriptif des différentes étapes d exécution de l algorithme de diagnostic. Nous présentons, également, les différents éléments utilisés dans le cadre de cette démonstration de faisabilité : le graphe causal utilisé, le scénario de test considéré et la configuration du service de VoIP des tests. L implémentation de notre approche est réalisée sur une plateforme IMS, et nous montrons que notre algorithme d auto-diagnostic pourrait être utilisé pour un exemple de service VoIP. Les résultats obtenus correspondent bien à ce qui est attendu. Notre approche est ensuite étendue au service IPTV. Ce mémoire de thèse se finit par une conclusion et décrit un ensemble de perspectives pour des recherches futures.

Première partie Etat de l art

CHAPITRE2 Réseaux autonomes Sommaire 2.1 Introduction........................ 9 2.2 Les principaux concepts................. 12 2.2.1 Historique de l autonomic................ 12 2.2.2 Les termes techniques.................. 13 2.2.3 Les objectifs de la gestion autonome.......... 16 2.3 Architecture de la gestion autonome.......... 20 2.3.1 Les ressources gérées................... 21 2.3.2 Les interfaces de gestion................. 21 2.3.3 Les gestionnaires autonomes............... 22 2.4 Les projets de recherche................. 25 2.4.1 Projets européens.................... 26 2.4.2 Projets industriels et académiques........... 28 2.4.3 Synthèse.......................... 30 2.5 Conclusion......................... 30 2.1 Introduction A partir des années 1920, le développement des réseaux est devenu de plus en plus rapide. Ce développement spectaculaire nécessita le déploiement, l exploitation et l administration d infrastructures complexes et distribuées. L intervention ma-

10 Chapitre 2. Réseaux autonomes nuelle étant devenue difficile voire impossible, la nécessité de décharger l opérateur manuel de la fonction de contrôle a entraîné l introduction des autocommutateurs. Le monde des technologies de la communication, de l information en général et des réseaux en particulier, a connu une deuxième grande révolution, au même titre que ce qu elle a connu lors de l automatisation du plan de contrôle, avec le réseau Internet. Depuis la fin du XX e siècle, nous vivons un développement sans précédent des nouvelles technologies. Les réseaux sont devenus accessibles de partout (réseaux ubiquitaires). Les services disponibles deviennent de plus en plus variés : la VoIP (voix sur IP), l IPTV (télévision sur IP), la VOD (vidéo à la demande), etc. Ces services dépendent fortement de la QoS (Qualité de Service). Les terminaux de communication sont de plus en plus nombreux et hétérogènes (PC, Mobiles et Smartphones, etc.). La tendance actuelle est désormais à la convergence entre les différents types de réseaux : réseaux fixes et mobiles, réseaux téléphoniques et réseaux informatiques, réseaux cellulaires et réseaux sans fils (WiFi). Cette convergence ne signifie pas l uniformisation par une seule technologie, mais l interconnexion entre celles-ci via des tentatives d uniformisation des protocoles (IP, SIP,...). Afin d assurer la qualité de service, la nécessité de techniques innovantes est donc cruciale. Ces évolutions rendent la gestion du cœur du réseau de plus en plus complexe, il faut en effet prendre en compte les exigences des différents types de services utilisés par les terminaux communicants. Alors que la gestion traditionnelle des réseaux se faisait de manière centralisée et que l optimisation des paramètres de configuration était réalisée par des experts humains, le nombre de paramètres à considérer est maintenant devenu tellement important et complexe qu il est impossible de le gérer manuellement. Le diagnostic et la correction des pannes pour la gestion de réseaux deviennent également de véritables défis avec un cœur de réseau complexifié par la traversée de différents services et l hétérogénéité des équipements. Avec le développement rapide des technologies informatiques et de télécommunication, les capacités de traitement des données des ordinateurs ont sensiblement augmenté et l architecture de connexion entre les équipements s est complexifiée (réseaux fixes, mobiles, sans fil). Quand une panne ou une erreur se produit à un endroit d un réseau, il est possible qu elle ait des répercussions dans le réseau entier. Ceci rend difficile la tâche qui consiste à trouver la cause de la panne et donc de la

2.1. Introduction 11 dépanner en temps voulu. Une panne peut influencer les différents composants ou les autres opérations du réseau. Il est évident que l accroissement des délais pour identifier les raisons d une panne et les délais de réparation vont augmenter le coût de réparation. La seule véritable option pour protéger les équipements du réseau et pour améliorer le service du réseau contre ces pannes, est la prévention et la détection automatique et évolutive des pannes. Les administrateurs ne doivent pas seulement configurer les équipements pour interconnecter les réseaux, mais ils doivent aussi assurer la stabilité des systèmes. Chaque mise à jour d un équipement peut engendrer des perturbations et des pannes. Cette complexité conduit souvent à retarder le changement de systèmes, même s ils sont désuets. D autre part, la formation pour les techniciens et les experts capables de gérer les équipements réseaux et d optimiser les configurations est certainement une source de charge importante pour les entreprises et les opérateurs réseau. Pourtant, l un des objectifs de la gestion du réseau est de réduire les coûts (Total Cost Ownership). La gestion du réseau par des techniciens et experts semble également augmenter les temps d indisponibilité durant les diagnostics et les optimisations. En contrepartie, la fiabilité du système permet de réduire les coûts. Ainsi, 40% des pannes de services sont causées par des problèmes de configuration realisées par les opérateurs [Patterson 2002] qui doivent prendre des décisions trop rapidement [Brown & Patterson. 2001]. Tous les problèmes qui viennent d être mentionnés montrent le besoin pour des fonctions de gestion comme : Le monitoring continu des ressources (matérielles et logicielles) ; Le diagnostic et la correction des pannes de manière automatique pour trouver les causes plus rapidement afin de maintenir les paramètres de configuration et de service à des valeurs désirées. La réalisation de la gestion autonome est un nouveau concept. Le but est de permettre aux équipements de se gérer automatiquement et sans intervention humaine en respectant des politiques de haut niveau. Ce nouveau concept peut permettre de diminuer la complexité de la gestion des équipements et de réduire l intervention humaine dans la boucle de contrôle des réseaux. C est l équivalent de la révolution du téléphone avec l automatisation du plan de contrôle dans les années 20, mais cela concerne la gestion des réseaux de communications à présent. Ce chapitre présente les concepts de la gestion autonome. La première section

12 Chapitre 2. Réseaux autonomes introduit les principaux concepts pour la gestion autonome, la deuxième section présente les travaux existants dans ce domaine. 2.2 Les principaux concepts 2.2.1 Historique de l autonomic Le concept de l autonomic est apparu dans la période où le domaine de la recherche a commencé à tenir compte du fonctionnement de la nature pour concevoir les systèmes futurs. Effectivement, à la fin des années 1990, particulièrement en 1997, le projet SUO SAS (Small Unit Operations Situation Awareness System) a été lancé par DARPA 1. Bien que l objectif de ce projet concerne les développements militaires, il est une des pierres de fondation dans le processus de la construction de l autonomic. Ce projet est une preuve de concept de l autonomic et aussi une orientation pour le domaine de la recherche. Au début des années 2000, certains grands industriels, notamment IBM et HP, ont initié une réflexion sur la vision du futur. Cette nouvelle vision se basait sur l observation du fonctionnement de la nature. En 2001, IBM a proposé le concept de l Autonomic Computing pour la première fois inspiré de la biologie (Système nerveux autonome). Le modèle du système nerveux autonome utilise un système distribué et hiérarchique de contrôle qui s appuie sur des capteurs et des réactions. IBM suggère que les systèmes informatiques complexes doivent posséder les propriétés de l autonomic. C est-à-dire que les systèmes doivent être capables de prendre en charge leur propre maintenance et optimisation sans intervention de l administrateur. Ceci permet de réduire les tâches de l administrateur qui pourra se concentrer sur les objectifs de l exécution du système. Ce concept a été développé largement par le domaine de la recherche et les industries, puisque il est bien adapté aux systèmes de gestion et de contrôle. 1. http ://www.darpa.mil/default.aspx

2.2. Les principaux concepts 13 2.2.2 Les termes techniques Depuis la proposition du concept de l autonomic, le domaine de la recherche et les industries ont porté un grand intérêt pour la nécessité d une gestion autonome. Ce paradigme est devenu rapidement un objectif de différentiation marketing pour les grandes entreprises. Il y a donc des nombreux termes techniques pour ce concept. Ces nouveaux termes, dans le domaine de la recherche, sont présentés comme des mots clés : Autonomic Computing Autonomic Communication Autonomic Networking Autonomic and Autonomous Systems Cognitive Networks Ambiant Intelligent (AmI) ecosystems Global service Ecosystems... Bien qu il y ait des variations sur le sens et la portée des termes cités précédemment, la vision et l objectif sont partagés par tous : rendre les systèmes capables de s auto-gérer. Pourtant, il faut noter que le terme Autonomic Communication couvre la plupart des domaines liés aux réseaux, comme l indique l annotation sur le site Autonomic-Communication 2 : Autonomic Communication (AC) - a new communication paradigm to assist the evolution of communication networks towards functional adaptability, extensibility and resilience to a wide range of possible faults and attacks. Special emphasis is given on the grounding principles to achieve purposeful behavior on top of self-organization (including self-management, self-healing, self-awareness, etc.). Papers are solicited that study network element s autonomic behavior exposed by innovative (cross-layer optimized, context-aware, and securely programmable) protocol stack in its interaction with numerous often dynamic network groups and communities. The goals are to understand how autonomic behaviors are learned, influenced or changed, and how, in turn, 2. http ://www.autonomic-communication.org/annales/

14 Chapitre 2. Réseaux autonomes these affect other elements, groups and the network. Les objectifs principaux de ce concept sont définis par l ACI (Autonomic Computing Initiative) créé par IBM en 2001 [Horn 2001]. L ACI regroupe les caractéristiques d un système autonome en huit points : 1. Un système autonome doit avoir des connaissances détaillées sur lui-même (ses composants, l état actuel, sa capacité et toutes les connexions avec les autres systèmes) pour se gérer (Know itself ). 2. Un système autonome doit se configurer et se reconfigurer sans intervention externe, afin de s adapter aux conditions et aux changements variables de son environnement. 3. Un système autonome doit être capable d optimiser son fonctionnement et de surveiller son travail de façon continue pour atteindre des objectifs de haut niveau. 4. Un système autonome doit pouvoir réparer ses pannes et ses dysfonctionnements, sans endommager les données ni le délai de traitement. 5. Un système autonome doit être capable de se protéger contre les différents types d attaques, afin d assurer la sécurité du fonctionnement. 6. Un système autonome doit prendre connaissance de son environnement et du contexte de ses activités et faciliter ainsi son adaptation. 7. Un système autonome doit être capable de fonctionner dans un environnement hétérogène et implémenter des standards ouverts. 8. Un système autonome doit cacher la complexité de son fonctionnement aux utilisateurs, les prises de décision doivent être transparentes. Ces huit éléments sont les conditions nécessaires pour qu un système soit autonome. Ils peuvent être traduits en propriétés [Sterritt & Bustard 2003] représentées par la figure 2.1 [Sterritt & Bustard 2003]. Ces propriétés décrivent la vision, les objectifs, les attributs et les moyens de ce nouveau concept.

2.2. Les principaux concepts 15 Vision Gestion autonome Auto-Configuration Objectifs Auto-Rétablissement Auto-Optimisation Autonomic Computing Auto-Protection Auto-connaissance Attributs Connaissance de l'environnement Auto-monitorage Auto-ajustement Boucle de contrôle Moyens Ingénierie (Système; Logiciel) Apprentissage (IA; Adaptation) Figure 2.1 Les propriétés de la gestion autonome

16 Chapitre 2. Réseaux autonomes IBM a étendu sa vision [Kephart & Chess 2003, Jacob et al. 2002] du concept d Autonomic Computing afin de couvrir les domaines des nouvelles technologies de l informatique et des télécommunications. D autre part, l AS 3 (Autonomic Communication), ACF 4 (Autonomic Communication Forum) et TF-AAS 5 (Task Force Autonomous & Autonomic Systems) tentent de rassembler les idées concernant l Antonomic networking afin de proposer des standards. 2.2.3 Les objectifs de la gestion autonome 2.2.3.1 Les fonctions des réseaux autonomes Les réseaux autonomes représentent une coupure technologique, qui peut offrir aux opérateurs et aux équipements des possibilités de réduction des coûts de gestion et d intégration des réseaux et services, ainsi qu une intégration rapide de nouveaux services. Cette coupure s appuie essentiellement sur la prise de décision par des éléments autonomes situés dans le réseau et partageant leurs connaissances et leurs décisions avec d autres éléments autonomes. Temps de Réponse Amélioré Adaptation dynamique aux changements de l'environnement Auto- Configuration Auto- Rétablissement Plus de Stabilité Découvrir, diagnostiquer, et agir pour éviter des pannes Efficacité Opérationnelle Ajuster les paramètres de performance et permettre une meilleure utilisation des ressources Auto- Optimisation Auto- Protection Des Ressources Sécurisées Anticiper, détecter, identifier, et se protéger contre les attaques Figure 2.2 Les 4 objectifs principaux d un système autonome 3. http ://www.autonomic-communication.org/ 4. http ://www.autonomic-communication-forum.org/ 5. http ://www.infj.ulst.ac.uk/ãutonomic/ieee TF-AAS/index.html

2.2. Les principaux concepts 17 Actuellement, la communauté scientifique et industrielle travaille sur l application des systèmes autonomes aux réseaux avec l objectif principal de construire des réseaux qui peuvent atteindre l auto-configuration, l auto-rétablissement (en cas de défaillance ou de panne), l auto-optimisation, et l auto-protection (en cas d attaques extérieures et de malveillances) (voir la Figure 2.2). 2.2.3.2 Auto-Configuration : Self-Configuring Il s agit d installer, de configurer et d intégrer de grands systèmes complexes dans des délais très courts et sans erreur. C est une tâche très complexe dans l environnement hétérogène des réseaux actuels. Pour la gestion traditionnelle, la fonction de configuration des systèmes avec de nombreux composants hétérogènes est vraiment difficile et demande beaucoup de temps aux experts. Mais les systèmes autonomes agissent d une manière transparente vis-à-vis de l opérateur qui peut effectuer les politiques et les directives de haut niveau afin de réaliser l auto-configuration. Les politiques spécifient la cible à atteindre, mais non la manière avec laquelle les composants doivent se configurer pour l atteindre. Lorsqu un composant autonome est introduit, il s intègre de manière homogène dans son environnement et le reste du système s adapte automatiquement à sa présence. Il a aussi la capacité de se réajuster automatiquement. Les erreurs de configuration peuvent donc être évitées. Une fois les politiques de configuration spécifiées, les administrateurs peuvent gagner un temps considérable. 2.2.3.3 Auto-Rétablissement : Self-Healing L auto-rétablissement désigne la capacité du système à examiner, diagnostiquer et réagir à des dysfonctionnements du système. Les éléments et les applications d auto-rétablissement doivent pouvoir observer les défaillances du système, évaluer les contraintes imposées par l extérieur, et appliquer les corrections appropriées. Afin de découvrir automatiquement les dysfonctionnements du système ou les défaillances possibles, il est nécessaire de connaître le comportement prévu du système. Un système autonome doit avoir des connaissances sur son comportement propre, puis il doit avoir une connaissance pour déterminer si le comportement actuel est cohérent et prévisible dans le contexte de l environnement. Dans de nou-

18 Chapitre 2. Réseaux autonomes veaux contextes ou dans des scénarios différents, de nouveaux comportements du système peuvent être observés et l entité autonome doit pouvoir réagir avec le changement d environnement grâce à son plan de connaissance. Surveillance Exécution des opérations de réparation (Autoréparation) Détection des pannes et diagnostic Analyse et Sélection d'une opération de réparation Figure 2.3 Le processus de l auto-rétablissement Les systèmes d auto-rétablissement assurent un processus afin de maintenir une qualité satisfaisante de service du système y compris en présence d une panne. La première étape du processus est appelée Surveillance. Pendant l étape de Surveillance, la supervision du système devra inspecter l information d environnement pour détecter toute conduite inappropriée. Les inspections de supervision terminées, il envoie les données des observations actuelles recueillies à l étape suivante. La deuxième étape du processus est appelée Détection des pannes et diagnostic, si le diagnostic indique qu il n y a pas de panne dans le système, il retournera à l étape de Surveillance. S il y a une panne détectée par le superviseur, l étape de détection d erreur l indiquera à l étape suivante. La troisième étape du processus est d analyser et de sélectionner une opération de réparation. Dans cette étape, les erreurs sont analysées et une méthode de réparation est déterminée. Une fois l opération de réparation déterminée, la dernière étape consiste à exécuter la réparation (L auto-réparation). Toute réparation nécessaire est réalisée dans cette étape. Une

2.2. Les principaux concepts 19 fois les pannes réparées, le processus recommence. Puisque ce processus est une boucle fermée, il sera continu comme le montre la figure 2.3. Le système d auto-rétablissement doit avoir un modèle de diagnostic pour bien trouver les causes correspondant aux pannes. Sinon il n y a aucun moyen d évaluer si un système actuel peut se rétablir en situation d intérêt. C est pourquoi nos travaux se focalisent sur la deuxième étape Détection des pannes et diagnostic. Nos travaux dissocient la fonction d auto-diagnostic et d auto-réparation qui sont contenues dans la fonction d auto-rétablissement. 2.2.3.4 Auto-Optimisation : Self-Optimizing Cet objectif permet au système de surveiller son environnement et apprendre à améliorer ses choix en terme d optimisation. Pour bien réaliser ceci, les systèmes autonomes vont continuellement chercher à améliorer leurs fonctionnements et saisir les opportunités de devenir plus performants. En même temps, ils vont surveiller leur environnement pour trouver les ressources adaptées, afin d assurer un fonctionnement optimal par rapport aux besoins spécifiés. L auto-optimisation permet une meilleure utilisation des ressources, et avec le temps, vise à obtenir une certaine expérience pour réaliser l auto-régulation et atteindre un objectif qui permet de réaliser une QoS optimale pour les utilisateurs avec une utilisation optimale des ressources pour les systèmes [Mbaye 2009]. 2.2.3.5 Auto-Protection : Self-Protecting Le système autonome va détecter les situations d attaques et se protéger pour ne pas perturber les utilisateurs. Ceci correspond à la mise en place de mécanismes et d architectures pour la détection et la protection de l ensemble des éléments de réseaux. De plus, les systèmes autonomes s auto-protègent de deux façons : Le système va se défendre contre les attaques malveillantes ou les défaillances en isolant ou réparant les sources de pannes qui ne sont pas traitées par l auto-rétablissement. Le système doit anticiper les attaques en analysant les rapports d événements et en lancant les actions adéquates.

20 Chapitre 2. Réseaux autonomes 2.3 Architecture de la gestion autonome Un système autonome peut s adapter aux changements de l environnement. Il se gère lui-même sans intervention humaine [Horn 2001]. En plus de ces concepts, le système autonome doit être Environment-Awareness, c est-à-dire être capable d appréhender et de comprendre l environnement dans lequel il agit. Cette connaissance est indispensable au bon fonctionnement du système qui doit prendre les bonnes décisions et pouvoir interagir avec son environnement. Fournir des décisions rapides et adaptées à la situation est crucial dans des environnements fortement dynamiques comme c est le cas aujourd hui pour les demandes de communication. Cette prise de décision, qui peut concerner les changements de configuration ou le traitement du trafic, doit être coordonnée. Capteurs Actionneurs Analyser Planifier Monitorer Connaissance Gestionnaire Autonome Executer Donnée Capteurs Actionneurs Action Ressource gérées Interfaces de gestion Figure 2.4 L architecture d une gestion autonome (Boucle autonome) Comme la figure 2.4 [Kephart & Chess 2003, Jacob et al. 2002] le montre, un élément autonome est essentiellement composé d une ou de plusieurs ressources gérées, de capteurs, d actionneurs, d un gestionnaire autonome et, également d une boucle de contrôle qui doit être implémentée par ce dernier afin de réaliser les quatre objectifs de gestion autonome.

2.3. Architecture de la gestion autonome 21 2.3.1 Les ressources gérées Une ressource gérée est un composant matériel ou bien un composant logiciel, qui peut être contrôlé. Par rapport à une ressource traditionnelle, un élément géré dans l architecture autonome doit permettre au gestionnaire de le surveiller et de le contrôler grâce à l utilisation des interfaces de gestion. Les points de contact pour implémenter ces interfaces correspondent à des capteurs et des actionneurs. Un élément géré peut être une ressource unique telle qu un serveur, une base de données, une application, un service, une mémoire ou encore un ensemble de ressources tel qu un ensemble de serveurs. Un gestionnaire autonome peut lui-même être une ressource gérée ou faire partie d un ensemble de ressources à gérer. C est pourquoi il dispose également de capteurs et d actionneurs. 2.3.2 Les interfaces de gestion L interface de gestion, pour contrôler un élément géré, est organisée en capteurs et actionneurs. L implémentation du comportement d un capteur et d un actionneur spécifique à une ressource est assurée par des points de contacts appelés, également, point de communication qui permettent de réduire la complexité des différentes technologies pouvant être utilisées par les ressources, et ce en offrant aux gestionnaires autonomes une interface standardisée afin de contrôler les ressources dont il est responsable. Capteur : C est l intégration des différents mécanismes qui sont capables de collecter les informations des éléments gérés. Un capteur peut traiter l ensemble des opérations qui permettent de retrouver les informations sur l état de l élément géré. Ainsi, un capteur peut traiter la série des événements de gestion qui se traduit par l envoi de messages asynchrones informant les changements intervenus sur l état de l équipement géré. Actionneur : C est l agrégation des différents mécanismes qui sont utilisés pour changer le comportement d un élément géré. Un actionneur peut traiter l ensemble des opérations qui permettent la modification de la configuration de l élément géré. Dans l architecture de gestion autonome, les opérations des capteurs et des actionneurs sont associées à la boucle de contrôle. Effectivement, un changement de

22 Chapitre 2. Réseaux autonomes configuration effectué par un actionneur doit être accompagné d une notification de ce changement grâce à l interface du capteur. Cette notification qui peut être considérée comme un type de feed-back, permet aux processus d évaluer l impact des actions. 2.3.3 Les gestionnaires autonomes Le gestionnaire autonome est la partie la plus importante dans l architecture qui exécute le concept de boucle de contrôle sans l intervention humaine. En fait, si un système est capable de s auto-gérér, il doit utiliser une méthode automatique qui peut permettre de collecter toutes les informations dont il a besoin et de les analyser pour identifier si un changement doit être opéré sur le système. Si c est le cas, le gestionnaire autonome doit établir un plan contenant une séquence d actions qui va être exécutée afin de réaliser les changements nécessaires. 2.3.3.1 Les fonctions d un gestionnaire autonome Une représentation de la boucle de contrôle est déjà montée dans la figure 2.4. Cette boucle permet de réaliser les actions de manière automatique. Elle est composée des quatre fonctions indépendantes reliées par le plan de connaissance. Monitoring : cette fonction offre des mécanismes qui réalisent la collecte, l agrégation, la corrélation et le filtrage des données. Ces données peuvent porter sur la topologie, les paramètres de configuration, l état fonctionnel, la capacité offerte ou encore les mesures provenant des ressources gérées dont le gestionnaire est responsable. La collecte des informations se fait par l intermédiaire des points de contact, et plus précisément de l interface capteur de la ressource. Ensuite, une quantité importante de données, qui peut être soit statique soit dynamique, est regroupée en symptômes qui vont être analysés dans une seconde étape. Analyse : cette fonction offre des mécanismes permettant d observer et d analyser des situations afin de déterminer si un changement doit être effectué pour satisfaire un objectif ou une directive de haut niveau. Ainsi, la fonctionnalité d analyse est responsable du respect des politiques de haut niveau durant toute l activité des composants réseau. Pour réaliser cette tâche, cette

2.3. Architecture de la gestion autonome 23 fonction implique l utilisation de modèles comportementaux complexes et de techniques de prédiction afin de permettre au gestionnaire autonome d apprendre à connaître l environnement dans lequel se trouvent les ressources gérées. Ces outils permettent, aussi, d anticiper sur l évolution de l environnement et sur les besoins en terme de ressources afin de s y adapter au mieux. Le gestionnaire autonome doit alors être capable de faire des analyses, des raisonnements et des traitements complexes sur les symptômes reçus de la fonction de monitoring. Si des modifications doivent être effectuées, la fonction d analyse va passer une requête à la fonction de planification. Cette requête contient la description des modifications qui doivent être effectuées afin d atteindre un fonctionnement respectueux des objectifs de gestion. Planification : cette fonction offre des mécanismes permettant de planifier les actions nécessaires pour atteindre les objectifs fixés. Ces mécanismes de planification peuvent prendre la forme de règles de politique. Cette fonction permet la création ou la sélection de procédures capables de mettre en œuvre les changements souhaités par la fonction d analyse sur les ressources gérées. Le résultat de la planification peut avoir plusieurs formes allant d une simple commande à un enchaînement ordonné de tâches. Les modifications ainsi planifiées peuvent être passées à la fonction d exécution. Exécution : Cette fonction offre des mécanismes permettant de contrôler l exécution d un plan d actions afin de réaliser les changements nécessaires sur le système. En effet, lorsque le gestionnaire autonome génère un plan (fonction planification), un ensemble d actions doit être entrepris pour modifier l état d une ou de plusieurs ressources gérées dont il a le contrôle. La fonction d exécution de la boucle de contrôle d un gestionnaire autonome est responsable de la mise en œuvre de la procédure générée par la fonction de planification Ces actions sont exécutées en utilisant le point de contact actionneur de la ressource concernée par les modifications. Le résultat de ces plans d exécution peut permettre ensuite d enrichir la connaissance partagée entre les différentes fonctions [Mbaye 2009].

24 Chapitre 2. Réseaux autonomes 2.3.3.2 La Connaissance Les données utilisées par les quatre fonctions assurées par le gestionnaire autonome sont stockées et partagées telle qu illustré dans la figure 2.4 (Connaissance). La connaissance utilisée par le gestionnaire autonome peut être obtenue de diverses manières. En effet, les informations qui enrichissent cette connaissance peuvent être passées au gestionnaire par l intermédiaire de son interface de type actionneur, et ce sous forme par exemple de règles de politique qui ne sont autre qu un ensemble de règles de comportement ou des préférences qui influencent les décisions du gestionnaire. Un autre moyen d enrichir cette base de connaissance est la récupération d information d un service externe susceptible de fournir des informations sur le système sous forme de rapports précisant les différents événements qui sont survenus sur les différents composants. Enfin, le gestionnaire peut créer lui même sa connaissance par le biais des informations récupérées par la fonction monitoring et la procédure de planification qui en a résulté. Grâce aux informations remontées par les capteurs, il pourra récupérer les conséquences des actions planifiées et exécutées. La connaissance peut être de plusieurs natures : les informations sur la topologie du réseau. Celles-ci permettent de spécifier les différents composants formant le système autonome. Ainsi, elles contiennent les constructions de ces composants avec leurs capacités, ce qui facilitera la planification. les politiques qui sont les règles qui peuvent être consultées pour déterminer si des changements sont nécessaires ou non pour atteindre les objectifs du système autonome. Ces règles doivent être définies de manière standardisée pour qu elles puissent être partagées par plusieurs gestionnaires autonomes. Ce partage permet au système de fonctionner en se basant sur un ensemble de règles de politique cohérentes. Cependant, dans ce contexte il y a plusieurs niveaux de cohérence qui sont plus ou moins nécessaires suivant les objectifs du système : une cohérence interne, du voisinage locale et globale. La connaissance qui permet la détermination et la résolution de problème en s appuyant sur une adaptation de la configuration des ressources gérées de manière automatique et suivant les changements de l environnement. Ces

2.4. Les projets de recherche 25 informations évolutives permettent au système autonome de reconnaitre les symptômes de mauvais fonctionnement du système. Dans nos travaux, nous modéliserons la connaissance en utilisant les graphe causaux pour réaliser l auto-diagnostic. Le chapitre 5 décrira cette modélisation plus en détail. 2.3.3.3 Le plan de connaissance Le plan de connaissance qui était né dans l esprit de régler des limites spécifiques à Internet va être adopté (ou intégré), par la suite, dans les architectures de gestion autonomes pour, finalement, y prendre une place assez importante. En parallèle, le concept de connaissance a fait naître de nouveaux concepts telles que la gestion orientée connaissances qui est une gestion de réseaux basée sur les connaissances acquises par le plan de connaissance. La vision de base du plan de connaissance est celle de la conception de nouveaux systèmes réseaux avec de nouvelles techniques avancées permettant d avoir plus d intelligence distribuée au niveau des équipements. Cependant, la contrainte qui est posée est celle de garder les avantages des systèmes classiques (extensibilité, facilités de déploiement de nouvelles applications). Les équipements au cœur du réseau auront ainsi une connaissance du comportement des applications aux extrémités du réseau et s adapteront en fonction de ces connaissances mais aussi des objectifs de haut niveau qui leur sont fixés par les administrateurs. Cette vision permet d avoir une adaptation automatique de la configuration des éléments réseaux sous la contrainte des configurations acceptables fournies par les administrateurs. Cette adaptation est basée sur une vue globale de la connaissance du réseau qui permet aux équipements de prendre des décisions de bas niveau sans violer les objectifs de haut niveau qu ils doivent atteindre [Mbaye 2009]. 2.4 Les projets de recherche Plusieurs travaux ont mis en avant des systèmes et des architectures qui ont pour objectif de réaliser une ou plusieurs fonctions de gestion autonome avec des mécanismes et concepts offrant des degrés différents d autonomie.

26 Chapitre 2. Réseaux autonomes 2.4.1 Projets européens Au niveau européen, une action de coordination appelée ACCA (Autonomic Communication Coordination Action) qui fait partie des projets ouverts du programme FP6 (Framework Programme) concernant les technologies émergentes FET (Future and Emergent Network Technologies) dans l IST (Information Society Technologies) a stimulé de nouvelles initiatives de recherche dans le domaine de la gestion autonome. Ainsi, dans le cadre du SAC (Situated and Autonomic Communication), quatre projets portant sur la gestion autonome ont été proposés : BIONETs (Biologically-Inspired Autonomic Networks), ANA (Autonomic Netywork Architceture), CASCADAS (Componentware for Autonomic, Situated-aware Communication and Dynamically Adaptable Services) et enfin HAGGLE (A novel Communication Paradigm for Autonomic Opportunistic Communication). Le programme FP7 a propulsé d autres projets tels que AutoI (Autonomic Internet), UniverSelf. Le projet BIONETs (2006-2009) [Pellegrini et al. 2006] suppose que les environnements de communications futurs seront aussi complexes que les organismes ou encore les écosystèmes biologiques. Ainsi, BIONETS cherche à s inspirer des systèmes biologiques dans le but de concevoir un environnement qui permet de faciliter l intégration d un grand nombre de composants ou encore de ressources hétérogènes, et qui est capable de s adapter et évoluer de façon autonome. Dans ce cadre, le projet BIONETS vise plutôt la recherche fondamentale en prenant comme modèle les systèmes biologiques. Le projet ANA (2006-2009) [Tschudin et al. 2008] explore de nouvelles méthodes d organisation et d utilisation au delà des technologies traditionnelles de l Internet. Ces travaux visent la conception et le développement d une nouvelle architecture réseau qui permet la formation d entités globales mais aussi de réseaux entiers de façon flexible, dynamique et totalement autonome. L objectif scientifique de ce projet est l identification des principes fondamentaux des réseaux autonomes. De plus, ce dernier a développé une plateforme de démonstration pour tester l architecture de gestion autonome proposée. Le projet CASCADAS [CASCADAS 2006] 2006-2008 a comme objectif l identification, le développement et l évaluation d une abstraction (ACE : Autonomic Commmunication Element) d usage universel pour les services de communications

2.4. Les projets de recherche 27 autonomes. Dans ce cadre, ces éléments réalisent d une façon autonome des fonctions d auto-organisation et d auto-adaptation pour la fourniture de services adaptés et situés. Enfin, ce projet vise à introduire de nouvelles technologies dans le domaine de l autonomic networking. Le projet HAGGLE [Giordano & Puiatti 2006] (2006-2010) propose une nouvelle architecture de gestion autonome des réseaux pour permettre la communication en présence de connectivité intermittente dans les réseaux, et ce en exploitant le concept de communication opportuniste autonome (AOC : Autonomic and Opportunistic Communication), en l absence d infrastructures de communication de bout en bout. Les travaux de recherches réalisés dans ce contexte vont au delà des approches innovante de Cross Layer en définissant un système qui utilise le best effort et les informations de contexte (context-aware) pour l acheminement des messages entre dispositifs mobiles omniprésents, afin de fournir des services quand la connectivité est locale et l intermittente. Enfin, ce projet présente un environnement ouvert afin de faciliter la prolifération des applications et des services. Le projet AutoI (Autonomic Internet) (2008-2010) [AutoI 2008] a pour ambition d avoir une solution autonome qui pourra être déployée à court terme. Il développe des overlays virtuels de ressources qui peuvent couvrir des réseaux hétérogènes, supporter la mobilité, la fiabilité et la QoS. Les services d adaptation se basent sur des informations et modèles de données ontologiques, ceci dans le but de faciliter le déploiement de nouveaux services et ainsi prendre en compte les NGN (Next Generation Networks). Le but attendu est l unification des efforts de recherche dans le domaine de l autonomic pour produire des standards, définir un framework de référence pour l autonomic pour garantir l interopérabilité et enfin, créer une structure organisationnelle pour maintenir ces deux premiers objectifs. Le projet UniverSelf [UniverSelf 2009] est une des composantes des Réseaux du futur dans le cadre du 7ème programme-cadre de l Union Européenne. Il est doté d un budget de 10 millions d euros, pour une période de trois ans (2010-2013). Ce projet de recherche a pour but de simplifier la gestion des réseaux de télécommunication, notamment à travers l auto-gestion. Ce projet permet de consolider les méthodes autonomes de l Internet du Futur pour le business, le service et l administration du réseau dans un nouvel environnement appelé Unified Management Framework (UMF) qui évolue par cognition. Cet UMF vise à résoudre les problèmes

28 Chapitre 2. Réseaux autonomes Figure 2.5 Les défis clés du projet UniverSelf de conception de l Internet et de sa mosaïque de protocoles arrivée plus tard, en unifiant parfaitement le contrôle et la gestion et en permettant l auto-organisation et l autorisation avec cognition. Cela mettra les tâches de gestion par l humain au niveau de la gouvernance du réseau entier et des services écosystémiques. Ce projet de recherche européen s articule autour de trois objectifs : concevoir une plate-forme de gestion unifiée pour les architectures existantes, élaborer des fonctions permettant aux réseaux de s auto-gérer et permettre le déploiement de solutions autonomes dans les réseaux des opérateurs. Les utilisateurs finaux bénéficieront également directement des résultats du projet UniverSelf, puisque les solutions ainsi créées devraient permettre d améliorer la qualité de service et les performances des réseaux de télécommunications. 2.4.2 Projets industriels et académiques La plupart des grands industriels ont également lancé des initiatives dans la foulé d IBM [Horn 2001] : par exemple Autonomic System de Fujitsu Siemens Com-

2.4. Les projets de recherche 29 puter [Fujitsu-Siemens 2003], Dynamic Systems de Microsoft [Microsoft 2007], Harmonious Computing de Hitachi [Hitachi 2007] et N1 Architecture de de Sun MicroSystems. Le monde académique s est également intéressé de prêt au domaine et plusieurs projets ont vu le jour : Bio-Networking [BIO-NETWORKING 2007] de l Université de Californie, AUtonomia [Autonomia 2007] de l université d Arizona, JSPOON [Konstantinou & Yemini 2003] de l université de Columbia, et CPN : Cognitive Packets Networks de l impérial College. Le projet AUTONETS (AUTOnomic Networking for End To End Supervision) est un projet interne de France Télécom, repris maintenant dans le projet UniverSelf. Il considère l amélioration de la supervision de VoIP (plus généralement des services IP) par l introduction de comportements autonomes. Il rentre dans le cadre de l administration de services. Notre travaux pour l auto-diagnostic se situent dans le cadre de ce projet. Par conséquent, les capacités d auto-gestion, et en particulier l auto-rétablissement, représentent une solution très attrayante pour résoudre les problèmes de gestion du réseau. Comme mentionné ci-dessus, il est de plus en plus crucial d assister l homme dans les opérations de surveillance. Cette aide se déploie dans la fonction d auto-rétablissement, incluant donc les problématiques d auto-diagnostic et d auto-réparation. D autres travaux de recherche portant sur le domaine des réseaux autonomes ont été réalisés et mettent en avant des fonctions particulières de gestion autonome. Ainsi l architecture OpenWings [Bieber & Carpenter 2003] fait de l auto-restauration de services en réaction aux problèmes réseaux et SELFCON [Boutaba et al. 2001] préconise l auto-configuration de composants grâce aux informations de configuration et de politique associées aux données par un serveur d annuaire. Dans self-star [SELF-STAR 2007], l auto-optimisation se fait par l évaluation de performances de systèmes de composants et d équilibrage de charge alors que les acteurs dans [Menasce et al. 2001] proposent une solution d auto-optimisation par le monitoring dynamique et la reconfiguration des paramètres basée sur une métrique de QoS agrégée.

30 Chapitre 2. Réseaux autonomes 2.4.3 Synthèse De nombreux travaux de recherche en réseau autonome ont déjà été effectués depuis de nombreuses années. Nous avons présenté plusieurs projets concernant les réseaux autonomes dans les sections précédentes. Nous avons pu constater que la plupart des projets se consacrent à l architecture autonome et à la fonction d auto-configuration (ANA, AutoI). Il y a très peu de recherches sur la fonction d auto-rétablissement, notamment l auto-diagnostic. C est pourquoi nous avons choisi l auto-diagnostic comme sujet d étude. 2.5 Conclusion Nous avons, dans ce chapitre 2, présenté un état de l art se rapportant aux réseaux autonomes. Nous avons d abord présenté l historique et les motivations qui ont conduit à ce nouveau paradigme.cet historique permet de montrer l importance sinon la nécessité de faire évoluer les architectures réseaux vers plus d autonomie pour répondre aux besoins de communication de demain et proposer une architecture adaptée aux réseaux de future génération. Ce chapitre décrit aussi, l architecture de base de la gestion autonome ainsi que l architecture des éléments autonomes selon la vision d IBM qui peut être vue comme modèle de référence dans ce domaine. Ce chapitre se termine par la présentation des projets de recherche concernant la thématique des réseaux autonomes. Peu de travaux sur l autonomic traitent spécifiquement de l auto-rétablissement. Notre travaux portent plus précisément sur l auto-diagnostic et son application pour la supervision de services multimédia dans un réseau IP de nouvelle génération. C est pourquoi dans le chapitre suivant, nous introduisons le diagnostic dans les réseaux de télécommunications.

CHAPITRE3 Diagnostic dans les réseaux de télécommunications Sommaire 3.1 Réseaux de télécommunications............. 31 3.1.1 L Internet......................... 32 3.1.2 La convergence des réseaux............... 33 3.2 La gestion des pannes................... 34 3.2.1 Définition d une panne.................. 35 3.2.2 Approches utilisées pour la gestion des pannes.... 36 3.3 Vision IA du Diagnostic................. 37 3.3.1 Introduction....................... 37 3.3.2 Les deux principales approches............. 37 3.3.3 Intérêt du diagnostic à base de modèles pour les réseaux autonomes........................ 45 3.4 Conclusion......................... 45 3.1 Réseaux de télécommunications Jusqu au milieu des années 80, les services de télécommunications traditionnels possédaient chacun leur réseau dédié optimisé pour le transport d un type d infor-

32 Chapitre 3. Diagnostic dans les réseaux de télécommunications mation pour lequel il a été conçu, et l interconnexion entre ces réseaux était très limitée ou inexistante. Ainsi, le monde des réseaux était constitué de trois sousréseaux distincts et indépendants, à savoir les réseaux de diffusion, les réseaux de télécommunications et les réseaux de données. En effet, la voix est transportée sur les réseaux téléphoniques commutés (RTC) qui répondent alors parfaitement aux impératifs de QoS, de fiabilité et d interactivité en se basant sur un plan de contrôle rigide. La télévision est diffusée par satellite ou par voie hertzienne qui apparaît comme le mode de transmission le plus adapté vue leur nature diffusive intrinsèque caractérisée par une communication unidirectionnelle qui permet la scalabilité en supportant un grand nombre d utilisateurs. Enfin, les réseaux de données, basés sur X.25, représentent un intermédiaire entre la fiabilité du réseau de télécommunications et la mise à l échelle du réseau de diffusion tout en permettant une certaine interactivité. Cette vision des réseaux de communication se révèle progressivement étroite puisqu elle entraîne des situations de «monopole naturel» caractérisées par la mise en œuvre systématique de solutions propriétaires et d infrastructures qu il est difficile de faire évoluer ou d interconnecter. Par conséquent, l infrastructure dédiée au transfert de données va proposer une nouvelle vision des architectures de communication ; il s agit de l architecture Internet qui se fonde sur le modèle TCP/IP. 3.1.1 L Internet Au cours des années 90, l explosion du volume du trafic véhiculé sur Internet et l accroissement de son hétérogénéité en termes de services (données, voix, vidéo), ont favorisé l adoption de l architecture d Internet. Basé sur le modèle TCP/IP et la commutation de paquets, le développement de protocoles et de services sur Internet est largement simplifié puisque ce modèle est ouvert, indépendant d une architecture particulière et propose une hiérarchie protocolaire qui permet à chaque couche de s abstraire des difficultés soulevées et résolues par la couche inférieure. En effet, le protocole IP, offre une connectivité en mode paquet indépendante du réseau sous-jacent permettant d interconnecter tout type de réseau. Avec les protocoles de niveau «Transport» (UDP et TCP), les applications disposent alors d une interface standard pour transmettre sur un réseau

3.1. Réseaux de télécommunications 33 IP. Graduellement, des protocoles de niveau applicatif (FTP, SMTP, HTTP) ont été standardisés ; ce qui a permis le développement des services «classiques» d Internet (mail, Web, FTP). Finalement, l augmentation en puissance des terminaux utilisateurs, conjointement avec l accroissement des débits et portées des réseaux d accès, a permis d envisager non seulement la réplication, sur Internet, des services RTC ou télévisuels mais aussi le développement de nouveaux services large bande multimédia. 3.1.2 La convergence des réseaux Durant ces dernières années, les trois réseaux ont connu des évolutions conséquentes. Le réseau de télécommunications est devenu numérique, sans fil et mobile grâce à l émergence des réseaux mobiles de 2ème et 3ème générations qui ont augmenté le débit de transmission, et par la même, le nombre de services. Le même constat peut être fait pour le réseau de diffusion qui migre actuellement vers la télévision et la radio numérique. Ainsi, les frontières entre les trois réseaux tendent à disparaître et les services se généralisent sur tous les réseaux. Par exemple, l Internet et la TV sont disponibles sur les réseaux de télécommunications, les communications téléphoniques peuvent être effectuées sur Internet, etc. Cette nouvelle mouvance a fait émerger la notion de convergence des réseaux qui a pour objectif de définir un cadre global pour le regroupement des trois types de réseaux sous une seule architecture. Les réseaux NGN (Next Generation Network) représentent la prochaine génération de réseaux censée réaliser la convergence totale des services en une seule architecture. IP Multimedia Subsystem (IMS) est une architecture standardisée NGN pour les opérateurs de téléphonie, qui permet de fournir des services multimédia fixes et mobiles. C est sur ce type d architecture réseau que nous appliquerons nos travaux de recherche. C est pourquoi nous détaillerons IMS au chapitre 4.

34 Chapitre 3. Diagnostic dans les réseaux de télécommunications 3.2 La gestion des pannes La gestion des pannes (ou fautes) est une des cinq aires fonctionnelles [ISO10040 1991] de gestion (voir la figure 3.1). Alarme 1 Alarme 2 Figure 3.1 La gestion des pannes La gestion des pannes couvre l ensemble des fonctionnalités suivantes : La détection des pannes : elle comprend la préparation de rapports d incidents de fonctionnement, la gestion de compteurs ou des seuils d alarme, le filtrage d événements par filtrage en amont des informations, l affichage des dysfonctionnements. La localisation : on y procède au moyen de rapports d alarme, de mesures et de tests. La réparation : elle consiste à prendre les mesures correctives (réaffectation de ressources, «reroutage», limitation du trafic par filtrage, maintenance), ou encore à rétablir du service (tests de fonctionnement, gestion de systèmes de secours, etc.).

3.2. La gestion des pannes 35 L enregistrement des historiques d incidents et statistiques : la gestion des pannes ne peut se limiter à ces actions ponctuelles, nécessaires mais insuffisantes pour donner le service attendu. C est la raison pour laquelle elle comporte aussi, d une part, l enregistrement d historiques d incidents et la compilation de statistiques qui peuvent porter sur la probabilité des pannes, leur durée, les délais de réparation et, d autre part, un rôle d interface avec les usagers qui consiste à les informer des problèmes réseau et à leur donner la possibilité de signaler eux-mêmes des incidents : la déconnexion d un câble ; une mauvaise configuration d un équipement ; une interface défectueuse d un routeur ; la réinitialisation accidentelle. 3.2.1 Définition d une panne Nous trouvons qu il y a une variété de termes pour définir «les pannes en général» dans les normes et dans la littérature scientifique : Faute, dysfonctionnement, défaillance, anomalie, incident etc. Dans [UIT-T 1992] par exemple, les pannes sont définies comme : Erreur : une déviation du système par rapport à l opération normale ; Faute : une condition qui provoque un dysfonctionnement (et se manifeste par des erreurs). Afin de simplifier et de bien comprendre les problèmes de la gestion des pannes dans les réseaux de télécommunications, une définition de la panne a été proposée par [Boubour 1997] pour ce type de réseau : Définition 3.2.1 (Pannes) Une panne est un état de non fonctionnement ou de dysfonctionnement, matériel ou logiciel pertinent pour l opérateur, au sens où il souhaite en avoir une trace pour le suivi. Nous pouvons remarquer que cette définition est basée sur la perception subjective de l opérateur, et dépend du niveau de détail auquel il s intéresse. Les pannes peuvent être classées en deux types : permanentes ou intermittentes. Les pannes permanentes exigent une action de réparation. Par exemple, un câble

36 Chapitre 3. Diagnostic dans les réseaux de télécommunications fractionné entre deux équipements est une panne permanente. Une panne intermittente se manifeste de façon discontinue mais peut se répéter au cours du temps. Par exemple, la réinitialisation d un équipement réseau est une panne intermittente. Elle peut se produire plusieurs fois au cours du fonctionnement du réseau. Le diagnostic des pannes intermittentes est une tâche plus complexe car les conséquences d une panne de ce type peuvent disparaître. 3.2.2 Approches utilisées pour la gestion des pannes Le développement rapide des réseaux à la fois en termes d extension physique et de multiplicité des services offerts, signifie qu ils deviennent de plus en plus complexes techniquement. Cela signifie également qu il est de plus en plus difficile d identifier ou de réparer les défauts de fonctionnement lorsqu ils se produisent. Pour pallier les défaillances d un réseau de télécommunications, les grands opérateurs ont souvent développé ou fait développer à grands frais des solutions de gestion propriétaires parfois efficaces, mais peu évolutives et peu adaptées à l explosion actuelle des réseaux de télécommunications et aux difficultés d acquisition de l expertise qui en résultent. L utilisation des techniques de l intelligence artificielle pour la gestion n est pas nouvelle [Gaiti & Pujolle 1993]. Si les systèmes experts ont fait l objet de nombreuses utilisations en gestion, notamment pour la gestion des fautes, d autres techniques de l intelligence artificielle semblent aujourd hui très prometteuses. Nous en avons retenues essentiellement une pour nos travaux de recherche que nous présentons dans la section 3.3.2.2 : le diagnostic à base de modèles. La section suivante est consacrée à l introduction du diagnostic en Intelligence Artificielle (IA) et à la comparaison de deux grandes approches : le diagnostic à base de systèmes experts et le diagnostic à base de modèles.

3.3. Vision IA du Diagnostic 37 3.3 Vision IA du Diagnostic 3.3.1 Introduction Le diagnostic est la partie de l intelligence artificielle visant à détecter, localiser et identifier les dysfonctionnements d un système. Le diagnostic s appuie sur des observations (symptômes) fournies par le système. Ces observations sont parfois imprécises, incertaines, voire partiellement fausses. L objectif du diagnostic consiste alors à inférer les pannes possibles ou probables sur le système étant donné ces observations. 3.3.2 Les deux principales approches 3.3.2.1 Diagnostic à base de systèmes experts Les systèmes experts traditionnels constituent le premier système d aide au diagnostic. Ils sont à base de raisonnement ou règles de l expert pour montrer les associations entre effets et causes. Ces associations sont généralement basées sur l expérience de l expert plutôt que sur une connaissance de la structure et du comportement du système. Communément, cette connaissance se présente sous la forme suivante : si s y mpt ôm e 1 et s y m pt ôm e 2 et... s y m pt ôm e N alors pa nne x La fonctionnalité d un système expert pour le diagnostic est de trouver la cause de ce qui a été observé en parcourant les règles par des techniques classiques en IA telles que le chaînage avant, le chaînage arrière ou encore le chaînage mixte. Nous présentons suivante un exemple des systèmes experts pour la supervision d un réseau de télécommunication à commutation de paquets bien connu : le réseau Transpac. Un exemple de système expert : réseau Transpac Le système d aide à la supervision utilisé sur le réseau Transpac était à la base un système expert comportant environ 200 règles. Il effectue une synthèse des éléments provenant du réseau, propose des actions à l opérateur, attire son attention sur des pannes trop fréquentes ou trop longues et met à jour une base de données des états des éléments du réseau. Cette base de données est mise à jour sans effectuer

38 Chapitre 3. Diagnostic dans les réseaux de télécommunications de photographies d état, c est-à-dire sans aller demander à chaque composant dans quel état il se trouve. Ce système expert utilise des règles de production mises en œuvre à l aide d un générateur de systèmes experts appelé Chronos. Ce générateur est un outil de développement de systèmes experts. Il a été choisi pour résoudre le problème d efficacité et pour faciliter l intégration de l expertise. Une règle type est constituée d une partie prémisse et d une partie conclusion. La partie prémisse décrit une suite d alarmes, précisant pour chacune d entre elles leur nature, leur provenance, et éventuellement leur date de réception et des délais entre ces dates, ou encore l indication d un nombre minimum d alarmes. La partie conclusion indique en général les éléments indésirables survenus dans le réseau et supposés responsables de l émission des alarmes. Elle peut aussi mentionner des actions à entreprendre par le superviseur (envois de commandes). Dans l exemple ci-dessous, nous présentons en langage naturel, une règle typique décrite dans le système expert de Transpac. Dans cette règle entrent en jeu un composant du réseau de type CT (Centre Technique), et des commutateurs (un centre technique gère un ensemble de commutateurs). Exemple [Une règle du système expert] Dès que : On a reçu une alarme CVHS concernant un objet < x > du réseau du type CT au temps T1 et On a reçu une alarme CVES concernant le même objet < x > au temps T2 avec T2 > T1 et Durant la période [ T1, T2+30secondes], on a reçu plus de 3 alarmes de type N004 concernant des commutateurs dépendant de cet objet < x > Faire : Afficher à l intention de l opérateur «Il y a eu arrêt du CT < x > du temps T1 au temps T2» La prémisse de cette règle exprime la réception d un certain nombre d alarmes (CVHS, CVES et N004) dans un intervalle de temps précis, provenant d un centre

3.3. Vision IA du Diagnostic 39 technique < x > et d un sous-ensemble de ses commutateurs. La conclusion de cette règle est un diagnostic de panne envoyé à l opérateur. Si une commande à activer existait dans ce cas de panne, la conclusion de cette règle serait augmentée d un message informant l opérateur que cette commande pourrait être activée pour résoudre le problème [Pencolé 2002]. Les principaux avantages des systèmes experts Dans un système expert, les règles spécifient la partie du raisonnement que doit avoir l opérateur de supervision. La qualité première d un système fonctionnant avec de telles règles est son efficacité au niveau temps de calcul. Il est suffisant pour un tel système d attendre que survienne un enchainement d événements extérieurs facilement observables puis d arriver directement aux conclusions [Ungauer 1993]. Il n y a pas de raisonnement compliqué et coûteux en temps de calcul à réaliser. Ceci est possible car un expert n a enregistré dans le système que les conditions initiales et les conclusions finales de son raisonnement. Donc, nous pouvons voir ces règles comme des raccourcis efficaces de raisonnements généralement beaucoup plus longs. Puisque ces règles sont produites par l expert humain, le résultat est compréhensible pour l opérateur. Ainsi, une règle d un système expert est directement interprétable par l opérateur. Il peut aussi lui servir pour l explication et la justification, face à la situation à laquelle il se trouve confrontée. L implantation d un système expert est aussi très simple. En effet, le travail est facilité car il n a pas besoin de développer des algorithmes complexes. Les principaux inconvénients des systèmes experts 1. La difficulté d acquisition de l expertise. Ce point est particulièrement important lors de l installation d un nouveau réseau. En effet, puisque le réseau est nouveau, il n y a pas ou peu d expériences au sujet des pannes qui peuvent se produire et particulièrement des événements (observables en particulier) qui peuvent être les conséquences. 2. Le manque de généricité. C est-à-dire que les règles pour un réseau ne peuvent pas être utilisées pour un autre réseau, parce qu elles sont trop souvent dé-

40 Chapitre 3. Diagnostic dans les réseaux de télécommunications pendantes de l architecture du réseau. 3. Le problème de l évolution du système. Si un système de supervision évolue (ce qui se produit souvent dans les réseaux de télécommunications) soit par remplacement de composants, soit par ajout de composants, les systèmes de règles doivent être modifiés. Une nouvelle expertise doit être mise en place afin que le système expert soit toujours pertinent face aux observations. 3.3.2.2 Diagnostic à base de modèles Il y a un intérêt considérable pour le raisonnement à base de modèles, en particulier pour les applications du diagnostic et dépannage depuis plusieurs années. La méthode appelée «Diagnostic à base de modèles» [Hamscher et al. 1992] a été proposée pour pallier les faiblesses des premiers systèmes de diagnostic. Le diagnostic à basé de modèles a une variété de noms, dont «le raisonnement à partir des principes premiers», parce qu il est fondé principalement sur la base de la causalité, et du «raisonnement profond», il repose sur une modélisation explicite du comportement ou du fonctionnement du système et non plus sur la modélisation du raisonnement de l expert pour effectuer le diagnostic. Système actuel Observations Comportement observé Comportement prévu Prédictions Modèle du système Comparaison Diagnostic Figure 3.2 Principe du diagnostic à base de modèles Le paradigme principal du raisonnement à base de modèles pour le diagnostic est l interaction entre l observation et la prévision (figure 3.2). D une part, pour les systèmes réels, particulièrement pour quelques artefacts physiques, nous pouvons

3.3. Vision IA du Diagnostic 41 observer leurs comportements. D autre part, nous avons un modèle du système qui permet de faire des prédictions sur son comportement prévu. L observation indique ce que le système est entrain de faire, c est-à-dire le comportement de l état actuel du système ; la prédiction indique ce que le système est censé faire. Les événements intéressants, ceux sur lesquels nous devons nous concentrer pour retrouver les composants défectueux, sont ceux qui vont modifier l état attendu. Une présomption fondamentale concernant le diagnostic à base de modèles est que si le modèle est correct, toutes les différences entre l observation et la prédiction découlent (et on peut faire remonter à) de défauts du système. Autrement dit, si le modèle est correct, le système doit être en panne, et les différences sont des pistes sur le caractère et la localisation des défauts. Mais nous pouvons voir que c est aussi un concept simplifié : en fait, l hypothèse selon laquelle le modèle est correct est erronée dans tous les cas. Il est faux d une manière qui est parfois assez évidente, et parfois assez subtile. Autrement dit, un modèle est un modèle, précisément parce qu il n est pas le système lui-même et doit donc être une approximation. Il y aura toujours des choses sur le système que le modèle ne peut pas capturer [Randall.Davis & Hamscher 1988]. Motivation du diagnostic à base de modèles Le diagnostic à base de modèles peut utiliser des modèles différents pour décrire le système. Les plus habituels décrivent les fonctions, les comportements ou les topologies. Les caractères communs de ces modèles sont qu ils montrent toujours un ensemble de relations entre les variables du système, chacun d eux étant relatif aux composants du système. Lorsque le comportement du système est normal, toutes ces relations sont vérifiées par les observations provenant du système physique. Quand une erreur se produit, certaines de ces relations deviennent incompatibles avec le comportement observé du système réel. Le succès de ces méthodes est fortement relatif à la qualité du modèle. En fait, pour que le modèle fournisse une description précise du système réel, il doit comprendre les effets de la connaissance imprécise et les perturbations inconnues ainsi que la prédiction de l évolution naturelle du système en temps réel [R.Pons et al. 1999]. Pour le diagnostic à base de modèles, il existe deux grandes orientations, qui

42 Chapitre 3. Diagnostic dans les réseaux de télécommunications utilisent des connaissances différentes sur le système. La première est le diagnostic basé sur la cohérence, qui utilise un modèle de bon fonctionnement du système. Le but de cette approche est de trouver l état du système consistant avec les observations. La seconde est le diagnostic abductif [Console & Torasso 1991a, Console & Torasso 1991b], qui s appuie sur le modèle de dysfonctionnement du système. Le but de cette approche est d expliquer les observations. Nous présentons ensuite ces deux approches afin de bien les comprendre et de pouvoir comparer leurs avantages et inconvénients. De cette façon, nous pouvons trouver les situations et les environnements correspondant à ces deux approches. Diagnostic de cohérence Une autre caractéristique du diagnostic à base de modèles est qu il n est nul besoin de savoir quoi que ce soit a priori sur les défauts ou dysfonctionnements pouvant affecter un système pour pouvoir le diagnostiquer : modéliser le comportement correct est suffisant. L idée fondamentale est de comparer le comportement réel du système tel qu il peut être observé par l intermédiaire de capteurs et son comportement attendu tel qu il peut être prédit grâce aux modèles de bon comportement. Le résultat de cette comparaison permet d établir un diagnostic de cohérence. Si ces modèles sont corrects, en ce sens qu ils sont effectivement vérifiés par un système en bon fonctionnement, toute contradiction entre les observations et les prédictions déduites des modèles est nécessairement la manifestation d un dysfonctionnement, c est-à-dire de la présence d un ou plusieurs défauts. Dans le cadre de la théorie logique, DS mentionne un prédicat unaire AN (x) où x COM PS et qui est interprété comme signifiant anormal. Si, pour COM PS, on note D( ) = ( AN (c) c ) ( AN (c) c COM PS ), le diagnostic est défini par : Définition 3.3.1 (Diagnostic de cohérence) Soit (DS, COM PS,O BS) un système observé, son diagnostic est D( ) avec un COM PS tel que : DS O BS {D( )} est satisfiable. COM PS décrit l ensemble des composants du système à diagnostiquer, DS décrit le comportement des composants ainsi que la structure du système et O BS est un ensemble d observations.

3.3. Vision IA du Diagnostic 43 Ce type de raisonnement par l absurde fait qu un défaut est par définition n importe quoi d autre que le comportement attendu et il n est pas recensé parmi une liste finie prédéterminée. Cette approche est une méthode de raisonnement très puissante, qui pallie la plupart des limites des approches traditionnelles et qui peut être logiquement fondée : la détection de dysfonctionnements par réfutation du bon comportement prédit est un raisonnement logiquement correct, ce que n est pas le cas de la détection de dysfonctionnements par corroboration avec un mauvais comportement prédit [Pencolé 2002]. Le diagnostic à base de modèles, dans ses principes de base, traite principalement de la tâche de localisation des défauts et également, après extension, de celle d identification de ces défauts. Diagnostic abductif Le premier objectif du diagnostic est de détecter/localiser voire identifier un dysfonctionnement à partir des observations du système. Mais parfois, il peut être intéressant que le diagnostic explique les observations. Dans ce cas, il faut passer à un raisonnement de type abductif où l on cherche les causes qui expliquent les symptômes. En l absence de modèle de comportements défectueux, le pouvoir explicatif est nul. Le diagnostic est uniquement fondé sur la restauration de la cohérence avec les observations. Pour établir un diagnostic abductif, il faut pouvoir disposer d un modèle de dysfonctionnement du système. Formellement, Définition 3.3.2 (Diagnostic abductif) Soit (DS, COM PS,O BS) un système observé et O BS = E S une partition de O BS, S correspondant aux observations que l on veut expliquer. Un diagnostic abductif pour (DS,COM PS, E S) est un D( ) avec COM PS tel que : DS E {D( )} est satisfiable et DS E {D( )} = S. Ici, on partage les observations O BS en deux sous-ensembles distincts E et S, et l on cherche dans ce cadre les modes comportementaux qui, d une part sont cohérents avec les observations E, et d autre part impliquent S conjointement avec E. En faisant varier à volonté E et S, on a ainsi tout un spectre qui s étend du diagnostic purement fondé sur la cohérence (cas où S = ) au cas du diagnostic

44 Chapitre 3. Diagnostic dans les réseaux de télécommunications purement abductif (cas où E = ) [Console & Torasso 1991a]. Le diagnostic à base de modèles a également été utilisé pour modéliser le comportement de différents types de réseaux de télécommunications. Ainsi des outils ont été proposés pour diagnostiquer les fautes dans un réseau de télécommunications ATM [Osmani & Krief 1999] ainsi que SDH en utilisant une approche à base de modèles [Dague et al. 2001]. Les principaux avantages du diagnostic à base de modèles Les techniques de diagnostic qui utilisent la méthode à base de modèles ont de nombreux avantages par rapport aux systèmes experts. 1. Elles n ont pas besoin d avoir nécessairement des connaissances sur les pannes. C est-à-dire qu un raisonnement peut être exécuté uniquement à partir d un modèle de fonctionnement du système. 2. Elles sont plus flexibles et génériques. Quand il y a une modification du fonctionnement du système, nous n avons pas besoin de mettre en œuvre une nouvelle expertise, mais la modification nécessite d adapter le modèle. Elles peuvent être utilisés pour différents systèmes par apport à un modèle respectif de fonctionnement. 3. Elles possèdent un pouvoir d explication clair des diagnostics assez important. Les principaux inconvénients Par contre, le diagnostic utilisant des raisonnements à base de modèles possède deux inconvénients principaux : 1. Ils nécessitent la construction d un modèle du système. Cette construction est un processus complexe. 2. Ils sont souvent basés sur des techniques de raisonnement abductifs dont la complexité est exponentielle par rapport au nombre de composants. Concernant le second point ci-dessus, la distribution du diagnostic permet de maîtriser cette complexité, c est ce que nous montrerons dans le chapitre 7.

3.4. Conclusion 45 3.3.3 Intérêt du diagnostic à base de modèles pour les réseaux autonomes Comme indiqué lors de la description des avantages du diagnostic à base de modèles, ce type de diagnostic permet de séparer la connaissance et le raisonnement. Le raisonnement est exécuté uniquement à partir d un modèle de fonctionnement du système (la connaissance que l on a du système). Cette séparation est bien adaptée à l architecture des réseaux autonomes (boucle de contrôle fermée) dont les 4 fonctions sont indépendantes et reliées par la connaissance. Dans la suite de nos travaux, nous choisissons donc le diagnostic à base de modèles et nous nous intéresserons à la distribution de l algorithme d auto-diagnostic pour résoudre le problème de passage à l échelle. La complexité de construction du modèle fera l objet de travaux futurs. 3.4 Conclusion Dans ce chapitre, nous avons présenté l architecture des réseaux de télécommunications, puisque nos travaux de recherche sont situés dans l environnement des télécommunications. Ce chapitre présente également l aire fonctionnelle de gestion des pannes car nos travaux se focalisent sur cette aire pour réaliser l auto-diagnostic. Ensuite, nous avons introduit le diagnostic, présenté son objectif et proposé une définition d une panne. Nous avons comparé les deux principales approches pour le diagnostic s appuyant sur l Intelligence Artificielle (IA) en montrant les avantages et les inconvénients de chacune de ces approches. Nous avons montré également que le diagnostic à base de modèles est mieux adapté pour notre architecture de réseau. Dans le chapitre 4, nous présenterons les services multimédia sur réseaux IP de nouvelle génération qui nous a servi de cadre d application à notre approche.

CHAPITRE4 Les services multimédia sur réseau IP de nouvelle génération Sommaire 4.1 Introduction à IMS.................... 47 4.1.1 Motivation pour l utilisation de l IMS......... 49 4.1.2 L architecture IMS.................... 50 4.1.3 Cœur du réseau IMS................... 52 4.1.4 Protocoles utilisés dans l IMS.............. 54 4.1.5 Conclusion........................ 56 4.2 Service VoIP........................ 56 4.3 Service IPTV........................ 58 4.4 Conclusion......................... 60 4.1 Introduction à IMS Alors que la première génération de I Internet concernait principalement le transport de données non temps réel, les services ayant des exigences de qualité de service (QoS) sont aujourd hui largement adoptées (Par exemple la voix sur IP

48 Chapitre 4. Les services multimédia sur réseau IP de nouvelle génération (VoIP), la vidéo à la demande (VoD)). Le mouvement vers une architecture tout-ip pour la délivrance des services est une tendance forte. Dans ce contexte, les clients veulent un accès aux services personnalisés interactifs, aux services multimédia, sur n importe quel équipement et n importe où. Cette tendance introduit de nouvelles exigences pour les infrastructures réseau. L IMS (IP Multimedia Subsystem) est considéré comme une solution pour répondre à ces besoins. L IMS se réfère à une architecture fonctionnelle pour la délivrance de services multimédia, basée sur les protocoles de l Internet. Son objectif est de fusionner l Internet et le monde cellulaire, afin de permettre des échanges multimédia plus riches [Camarillo 2005, Tadault et al. 2003]. Il est spécifié dans le 3GPP (3rd Generation Project). La première version de l IMS, se focalise sur la facilité de développement et de déploiement pour les nouveaux services dans le réseau mobile [3GPP 2003]. L IMS a ensuite été développé par European Telecommuication Standards Institute (ETSI), dans le cadre de ses travaux sur les Next Generation Networks (NGN) 1. Un NGN, simplifié dans la Figure 4.1, est constitué principalement de deux couches : une couche transport qui fournit une connectivité IP aux différents composants d un NGN tout en garantissant une QoS de bout-en-bout, et une couche de service qui fournit les fonctionnalités de base pour le fonctionnement des services avec ou sans session. Par exemple, des fonctionnalités relatives à l enregistrement, la notification et la présence. Un comité technique de normalisation de l ETSI, appelé Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) standardise IMS comme un sous-système de NGN. On peut dire que 3GPP décrit le point de vue des opérateurs de téléphonie mobile (le soutien de nouvelles applications), mais TISPAN ajoute les spécifications pour les opérateurs filaires (convergence). La plupart des protocoles IMS sont standardisés par l Internet Engineering Task Force (IETF) (par exemple le Session Initiation Protocol (SIP)). Nous devons distinguer entre le core IMS (vocabulaire de TISPAN) et l IMS (vocabulaire de 3GPP). Nous nous concentrons sur le standard de l ETSI TISPAN. Nous utilisons le terme d architecture IMS pour nous référer à l architecture NGN caractérisée par l IMS. 1. 3GPP Release 7 (Mars 2007) fournit un IMS unifié qui supporte les technologies d accès du réseau hétérogène (par exemple DSL, WLAN). [3GPP 2007]

4.1. Introduction à IMS 49 IP Videoconference IPTV Game VoIP Email Web Service Layer Transport Layer Location IP Network DiffServ QoS Subscribtion Identification Security QoS IP Network IntServ QoS IP Network MPLS Connection with other netrworks X-ADSL Wimax 802.16 Broadcasts Networks DVB-S, DVB-T, DVB-H Mobile Networks GSM, GPRS, UMTS WiFi 802.11a/b/g/h Figure 4.1 L architecture NGN Cette section est divisée en trois sous sections. Après une courte introduction sur l IMS, nous introduisons les principes, l architecture IMS et les protocoles utilisés dans l IMS. 4.1.1 Motivation pour l utilisation de l IMS Anticipant la conversion des infrastructures de réseau de télécommunications vers un transport tout-ip, l IMS est une architecture cible, dont la généralisation ne pourra être que progressive car complexe et qui ambitionne de remplacer les réseaux téléphoniques traditionnels. L IMS est une architecture standardisée NGN pour les opérateurs de téléphonie, qui permet de fournir des services multimédia fixes et mobiles. Ce système utilise la technologie VoIP basée sur une implémentation 3GPP. Une cible de l IMS est de faire de la gestion de réseau plus facilement. IMS devrait simplifier l administration du réseau, puisqu un réseau intégré tout-ip est plus facile à gérer. IMS est une architecture horizontale : il fournit un ensemble de fonctions communes qui peuvent être utilisées par plusieurs services (par exemple, la gestion de

50 Chapitre 4. Les services multimédia sur réseau IP de nouvelle génération groupe/liste, le provisioning, l opération et la gestion...). Cela rend l implémentation de service plus facile et plus rapide. En effet, l IMS permet à l opérateur du réseau de jouer un rôle central dans la délivrance des services, et le regroupement de services avec leurs offres d accès. Par ailleurs, l IMS devrait supporter la création et le déploiement de services innovants pour les opérateurs ou les tiers, afin de créer de nouvelles sources de revenus. Le développement plus rapide des services IMS devrait réduire le temps de marketing et le temps de stimuler l innovation. La combinaison de plusieurs services dans un seule session peut susciter l intérêt des clients et augmenter les opportunités de revenus. En somme, l IMS peut permettre le déploiement de nouveaux services plus riches. Il doit permettre la délivrance de communications en temps réel basées sur IP[Tadault et al. 2003]. Il doit faire l intégration pour les applications temps réel et non temps réel plus facilement. Il doit permettre la délivrance de services conversationnels simultanés dans une seule session. Il doit être agnostique pour l accès, c est-à-dire qu il peut permettre à l utilisateur d accéder à ses services par tous les média supportés [Bertrand 2007]. 4.1.2 L architecture IMS L architecture IMS est une infrastructure de contrôle de service. L idée a été suggérée afin de répondre au besoin de convergence des services multimédia entre réseaux mobiles et filaires et d en faciliter les interfaçages. Elle fournit une couche intermédiaire au cœur des réseaux pour passer du mode d appel classique (circuit) au mode session. Il s agit d une architecture en couches, permettant d agencer toutes les fonctions fondamentales communes à tout type de service de télécommunications. Pour cela, l architecture IMS, illustrée par la figure 4.2, est découpée en trois plans distincts qui séparent les fonctionnalités liées aux contrôles, aux services et aux réseaux. Ci-dessous, nous donnons une brève description de chaque plan : La couche d accès : Elle peut représenter tout accès haut débit tel que : UTRAN (UMTS Terrestrial Radio Access Network), CDMA2000 (technologie d accès large bande utilisée dans les réseaux mobiles aux Etats-Unis), xdsl, réseau câble, Wireless IP, WiFi, etc.

4.1. Introduction à IMS 51 Application Layer Application servers (AS) AS AS AS AS IPTV, VOD service VoIP service Game service Videoconference service Control Layer Session management and control HSS CSCF Transport Layer IP network access and management Figure 4.2 L architecture IMS La couche de transport : Elle correspond au réseau IP. Le réseau IP peut intégrer des mécanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche transport consiste donc en des routeurs (edge router à l accès et core router en transit) reliés par un réseau de transmission. Différentes piles de transmission peuvent être considérées pour le réseau IP : IP/ATM/SDH, IP/Ethernet, IP/SDH, etc. La couche de contrôle : Elle authentifie, établit les sessions, interconnecte les opérateurs, permet l interfonctionnement avec les réseaux existants et l aiguillage vers les serveurs d application. C est au cœur de cette couche qu est implémenté le protocole SIP. La couche d application : Elle comprend les serveurs d applications (AS - Application Servers) et les serveurs de contenu qui exécutent les applications et les services IMS. Le serveur d application peut inclure des capacités web (HTTP) lui permettant de prendre d un serveur de contenu des ressources tels que des fichiers multimédia et des scripts d application. Puisque l IMS est encore en cours de définition pour notamment le support de l IPTV, et puisqu il décrit plusieurs interfaces et des entités fonctionnelles, un système IMS complet est assez difficile à représenter. Il faut néanmoins noter que l IMS est une partie d une architecture fonctionnelle, et que certains de ses composants

52 Chapitre 4. Les services multimédia sur réseau IP de nouvelle génération peuvent être mis en œuvre dans un seul matériel. 4.1.3 Cœur du réseau IMS Le cœur IMS est utilisé pour la session et le contrôle de média. Sa structure est illustrée par la figure 4.3 [TISPAN 2006] et ses composants fonctionnels sont les suivants : HSS AS SLF Cx ISC/Ma Dx Mw I/S-CSCF Mw Mr Mi IMS Core Mx IBCF Mk BGCF Mj UE Gm P-CSCF MRFC MGCF Figure 4.3 La structure interne du cœur IMS et les interfaces Call Session Control Function (CSCF) peut établir, surveiller, supporter et communiquer les sessions multimédia, il peut également gérer les interactions de service de l utilisateur [3GPP et al. 2002]. La fonction de CSCF se décompose en P-CSCF, S-CSCF et I-CSCF. Le «I-CSCF» (Interrogating) est le point d aiguillage intermédiaire pour l initialisation des connexions, et qui, via le DNS, fournit la destination recherchée pour les requêtes orientées vers les multiples S-CSCF des réseaux. Le «S-CSCF» (Serving) est utilisé pour la commutation vers l application, l enregistrement, le contrôle des session SIP, le service ou le réseau (serving in charge) demandés. Le P-CSCF (Proxy) sert d extension logique vers le réseau de l abonné ou vers le réseau visité et sert au contrôle du réseau d accès. Il assure les fonctions de liaison aux réseaux de paquets et au PDF (Policy Decision Function) (recherche des profils de l usager) [Camarillo & Garcia-Martin 2004]. Dans la cinquième version de la norme TISPAN, le PDF est séparé de l I-CSCF afin de permettre l ouverture

4.1. Introduction à IMS 53 de nouvelles applications liées à la qualité de service hors IMS. Cette interface P-CSCF existe dans tous les réseaux, fixes ou mobiles. En fixe, il sert à la voix sur IP et en réseau mobile, il est utilisé pour toutes les connexions [Beaufils et al. 2008]. Deux des CSCF (le I et le S) sont connectés à la base de données du réseau (HSS) afin de recevoir les informations nécessaires aux autorisations de connexion. Les I-CSCF de réseaux voisins sont reliés entre eux afin d assurer les communications sortantes ou entrantes. Multimedia Resource Function Controller (MRFC) est utilisé pour contrôler un Multimedia Resource Function Processor (MRFP) qui fournit essentiellement la fonctionnalité de transcodage et d adaptation de contenu [Cuevas et al. 2006]. Breakout Gateway Control Function (BGCF) permet de sélectionner l entité qui constituera la passerelle vers le domaine CS (Circuit Switched). C est un serveur SIP qui possède des fonctionnalités de routage pour une session initiée par un terminal IMS à destination d un client dans un réseau à commutation de circuit (cas de PSTN). Media Gateway Controller Function (MGCF) est, comme son nom l indique, utilisé pour contrôler une passerelle média et leurs canaux dans le plan utilisateur afin d établir, maintenir et libérer des connexions sous forme de canaux média. Il assure la conversion des messages de signalisation et sélectionne le CSCF approprié afin de remettre la signalisation SIP qu il génère, au soussystème IMS. Home Subscriber Server (HSS) est le système de gestion des données des clients et des services auxquels ils ont souscrit. Parmi les données stockées figurent l identité du client, les paramètres d accès (authentification, autorisation de roaming et S-CSCF alloués) et les informations permettant l invocation de ses services. HSS utilise le protocole Diameter afin d interagir avec les autres entités du réseau [Beaufils et al. 2008]. Application Server (AS) exécute des services (e.g., Push To Talk, Présence, Conférence, Instant messaging, etc.) et peut influencer le déroulement de la session à la demande du service. Subsription Locator Function (SLF) permet de localiser le HSS lorsque plusieurs HSS ont été déployés au sein du réseau de l opérateur. Cette résolution

54 Chapitre 4. Les services multimédia sur réseau IP de nouvelle génération d adresse de HSS est requise par I-CSCF, S-CSCF ainsi que d autres serveurs d applications. Interconnection Border Control Function (IBCF) est utilisé comme passerelle vers les réseaux externes, et fournit également des fonctions NAT et Firewall. 4.1.4 Protocoles utilisés dans l IMS Comme mentionné précédemment, la plupart des protocoles utilisés dans l IMS sont standardisés par l IETF. Ils sont brièvement décrits dans les sections ci-dessous. 4.1.4.1 Signalisation et description de flux médias Le protocole principal de signalisation utilisé dans l IMS est appelé Session Initiation Protocol (SIP). Il a été principalement défini dans le RFC 2543 et plus tard dans le RFC 3261 [Handley et al. 1999, Rosenberg et al. 2002]. SIP profite de certains principes de HTTP (Hypertext Transfer Protocol) et SMTP (Simple Mail Transfer Protocol). SIP a été sélectionné pour être utilisé essentiellement dans l IMS, parce qu il peut fonctionner selon l exigence d IMS et il est flexible (plusieurs extensions sont standardisées) et sécurisé. En fait, le SIP d IMS est une version améliorée du protocole SIP, il comprend plusieurs extensions qui sont décrites dans le standard 3GPP TS.24.299 [3GPP et al. 2005, Radvision 2006]. L objectif principal du protocole SIP est l établissement, la modification et la fermeture des sessions multimédia entre deux terminaux. SIP est le protocole clé dans l architecture IMS. Il est capable de gérer la gestion des clients, le contrôle de service, l autorisation de QoS, la facturation et la gestion des ressources [Rosenberg et al. 2002]. 4.1.4.2 Protocole AAA Le protocole Diameter est un protocole AAA (Authentication, Authorization and Accounting) récent. Il a déjà remplacé le protocole RADIUS (Remote Authentication Dial In User Service) [Handley & Jacobson 1998] et il est défini dans le RFC 3588 [Calhoun et al. 2003]. La sécurité de Diameter est assurée par IPSec (Internet Protocol Security) ou TLS (Transport Layer Security). Diameter est utilisé dans le cadre d IMS par I-CSCF, S-CSCF et les serveurs d application (AS)

4.1. Introduction à IMS 55 dans leurs échanges avec le HSS contenant les profils des utilisateurs. 4.1.4.3 Les protocoles additionnels Le protocole MeGaCo, aussi appelé H248, est un successeur du protocole MGCP (Media Gateway Control Protocol) qui est utilisé pour contrôler les média au service des fonctions dans un environnement IMS. Il est spécifié dans le RFC 3015 [Cuervo et al. 2000]. Le protocole RTP (Real Time Protocol) fournit les fonctions de transport pour la transmission des données en temps réel. Il est spécifié dans le RFC 3550 [Schulzrinne et al. 2003]. Et il est utilisé en conjonction avec un protocole de contrôle appelé Real Time Control Protocol (RTCP) afin de permettre la supervision de la délivrance des données et fournir un contrôle minimum avec la fonctionnalité d identification. Le protocole de transport de signalisation SIGTRAN (Signalling Transport) est chargé de définir une infrastructure de signalisation au-dessus de IP. Le but principal est le transport des protocole de la suite SS7 (Signalling System 7 ) d un réseau IP [Beaufils et al. 2008]. Le protocole SDP (Session Description Protocol) est destiné à la description des sessions multimédia pour les annonces de session, l invitation à une session, et d autres formes d initiation de session multimédia. Il permet de contrôler la conformité des types de médias et des codecs utilisés avec ceux autorisés à l utilisateur. Le protocole DNS (Domain Name System) est un service permettant d établir une correspondance entre une adresse IP et un nom de domaine et, plus généralement, de trouver une information à partir d un nom de domaine. Le protocole COPS (Common Open Policy Service) est défini par l IETF dans le RFC 2748. Il spécifie un simple modèle client/serveur pour soutenir la politique de contrôle sur le protocole signalisation de QoS (e.g. RSVF (Resource Reservation Protocol)). Les politiques sont stockées sur des serveurs, et sollicités par le PDP (Policy Decision Points), pour être appliquées sur les clients, connu sous le nom de PEP (Policy Enforcement Points).

56 Chapitre 4. Les services multimédia sur réseau IP de nouvelle génération 4.1.5 Conclusion Comme les introductions et les discussions des sections précédentes, l IMS ouvre de nouvelles perspectives pour les opérateurs réseau. Mais plusieurs défis techniques et défis industriels devront être envisagés afin de permettre la sélection à grande échelle de cette technologie prometteuse. Par ailleurs, l IMS peut résoudre certaines contradictions inhérentes : il s appuie sur les technologies IP qui permettent la communication libre, mais vise à contrôler les services IP. De plus, l IMS conduit les opérateurs réseau à jouer un rôle central dans la distribution des services. Cela implique que les transporteurs devront obtenir des contenus [Tadault et al. 2003]. Le rôle des opérateurs, dans la facturation des services fournis par les tiers, doit aussi être clarifié. Avec l IMS, un seul client peut souscrire aux services de plusieurs fournisseurs. L IMS conduit donc les opérateurs réseau à une concurrence avec les acteurs de l Internet mondial. 4.2 Service VoIP La voix téléphonique sur IP, appelée VoIP (Voice over IP) est devenue une application classique grâce aux progrès de la numérisation et à la puissance des PC, qui permettent d annuler les échos. L élément le plus contraignant de cette application sur Internet reste le délai de bout en bout qui ne doit pas excéder 300ms pour permettre l interactivité. Les opérateurs de télécommunications doivent également contrôler le réseau de sorte que le temps total de transport de la parole, y compris la paquétisation et la dépaquétisation, soit limité. De manière générale, la mise en place d une communication téléphonique sur IP suit différentes étapes : 1. Pour mettre en place la communication, il faut d abord utiliser une signalisation qui démarre la session. Le premier élément à considérer est la localisation du récepteur (User Location). Elle s effectue par une conversion de l adresse du destinataire en une adresse IP d une machine qui puisse joindre le destinataire. 2. L établissement de la communication passe par une acceptation du terminal

4.2. Service VoIP 57 destinataire, que ce dernier soit un téléphone, une boîte vocale ou un serveur Web. Plusieurs protocoles de signalisation sont utilisés pour cela, en particulier le protocole SIP (Session Initiation Protocol) de l IETF. Comme son nom l indique, SIP est utilisé pour initialiser la session. Une requête SIP contient un ensemble d en-têtes, qui décrivent l appel, suivis du corps du message, qui contient la description de la demande de session. SIP est un protocole clientserveur, qui utilise la syntaxe et la sémantique de HTTP. Le serveur gère la demande et fournit une réponse au client. Trois types de serveurs gèrent différents éléments : un serveur d enregistrement (Registration Server), un serveur relais (Proxy Server) et un serveur de redirection (Redirect Server). Ces serveurs travaillent à trouver la route : le serveur proxy détermine le prochain serveur (Next-Hop Server), qui à son tour trouve le suivant, et ainsi de suite. Des champs supplémentaires de l en-tête gèrent des options, comme le transfert d appel ou la gestion des conférences téléphoniques. 3. Le protocole RTP (Real-time Transport Protocol) prend le relais pour transporter l information téléphonique proprement dite. Le rôle de ce protocole est organiser les paquets à l entrée du réseau et de les contrôler à la sortie de façon à reformer le flot avec ses caractéristiques de départ (vérification du synchronisme, des pertes, etc.). C est un protocole de niveau transport qui essaye de corriger les défauts apportés par le réseau. 4. Un autre lieu de transit important de la voix sur IP est constitué par les passerelles permettant de passer d un réseau à transfert de paquets à un réseau à commutation de circuits, en prenant en charge les problèmes d adressage de signalisation et de transcodage que cela pose. De nouveau, le protocole SIP propose des solutions pour permettre ces correspondances. Dans le cadre de notre étude, nous nous intéressons principalement aux applications de service VoIP sur l architecture IMS. Il s agit plus précisément d une simplification de l architecture VoIP SIP utilisée dans le projet T3G SIP de France Télécom [Tuffin 2009]. La Figure 4.4 montre la signalisation du processus de VoIP dans ce cas. La LiveBox est représentée dans cette architecture comme un UE. Les lignes rouges sont les interfaces ou les liens de la signalisation.

58 Chapitre 4. Les services multimédia sur réseau IP de nouvelle génération! Signaling interface (SP, Diameter, H248, DNSEnum,...) Media interface Provisioning interface (Subscriber data) VoIP System or Information System building block Information Information System System LNP LiveBox (Signaling & Media Processing Layer) A-SBC SLF Node HSS CSCF Node DNS Enum Telephony AS Media Server Voice Mail I-SBC MGC I-BCF Other IP Signaling & Media Processing Sub-System MGW PSTN Managed Signaling & Media Processing System Figure 4.4 La signalisation du processus de VoIP 4.3 Service IPTV Le service IPTV est le terme générique utilisé pour désigner les services de transmission audio/vidéo, live ou préenregistrés, sur des infrastructures IP. IPTV est défini comme «étant des services multimédia, télévision/vidéo/audio/texte/graphiques/données, délivrés sur un réseau IP contrôlé afin de fournir le niveau de QoS/QoE, sécurité, interactivité et fiabilité exigé» [ITU-T 2006]. Ainsi, IPTV couvre un large panel de services, comme la VoD, le LoD, l IPTV multicast, le IPTV pairs-à-pairs. Chaque service se base sur une architecture bien définie, un mode de transmission spécifique et des protocoles de contrôle appropriés. Nous présentons, ci-dessous, une brève description de chaque service : VoD (Video on Demand) : Le service VoD permet aux utilisateurs de recevoir à la demande des vidéos préenregistrées et stockées sur des serveurs. Le VoD suit une architecture client/serveur et le client doit explicitement demander la vidéo en utilisant un protocole de contrôle de session (RTSP, SIP, MMS, etc.) pour que le serveur entame la transmission. Ce service correspond à un vidéo

4.3. Service IPTV 59 club virtuel, où, le client paye pour voir un film à la demande à n importe quelle heure sans avoir à se déplacer. Le mode de transmission adopté par ce service est principalement l unicast. LoD (Live on Demand) : D une manière similaire au VoD, le LoD permet aux utilisateurs de recevoir à la demande des flux vidéo live et non pas des vidéos préenregistrées. Il se base sur une architecture client/serveur, dans laquelle le serveur représente le point de contrôle des flux live. Le client utilise les protocoles de contrôle de session pour demander la transmission en unicast d un flux particulier. Le principal inconvénient de ce service est sa scalabilité puisque le flux live est dupliqué dans le réseau pour chaque récepteur. Cependant, cette duplication permet d adapter et de personnaliser le flux live suivant l environnement du récepteur. IPTV multicast : Ce service se base sur le multicast IP pour la transmission de flux live ou de sessions vidéo préprogrammés. Ceci permet un gain considérable en bande passante comparé au service LoD. L IPTV multicast ne se base pas sur une architecture particulière, l utilisateur doit s abonner à un groupe multicast pour recevoir le flux vidéo. IPTV pairs-à-pairs : Ce service reprend le principe du partage de fichiers pairs-à-pairs pour l adapter aux services IPTV. Il se base sur la notion de pair qui est à la fois client et serveur. Le pair partage les flux vidéo avec d autres pairs. Il peut avoir plusieurs sources et peut retransmettre le flux reçu à plusieurs pairs. L architecture fonctionnelle de l IMS basée sur l IPTV présentés dans cette section contient les fonctions principales et des points de référence définis dans TISPAN IMS IPTV concept. Nous allons présenter les différents scénarios de communication entre les composants de l architecture IMS-IPTV. Le terminal utilisateur (UE) communique avec la fonction de contrôle de service d IPTV via le cœur IMS pour gérer la session, et peut utiliser l interface Xt à des fins de configuration du profil de service ou d interaction avec le serveur d applications IPTV. Le Multimedia Service Control Function (MSCF) est utilisé comme élément de service de contrôle (réutilisable pour tous les services multimédia et pas seulement pour les services IPTV). Cet élément fonctionnel (MSCF) supplémentaire de IMS

exist at least three ecture: all available solutions ke some interworking service control and lly for IPTV services bles interaction and 60 point between IPTV NGN components. ontrol elements for tem (RACS) or the ASS). This approach NGN to provide all ifies IPTV functions loys these functions to service initiation and Protocol). This paper ncept. in groups of services radio channel feeds cast services provided content (e.g. movie, nclude services which ilities for live content The functional architecture of IMS based IPTV presented in this section contains main functions and reference points defined in TISPAN IMS IPTV concept. The following sections describe the main functions, including the service control function, the media control function and the media delivery function. We enhance the short description from original TISPAN drafts [2] (originally described in TISPAN Work item 2048) and include our Chapitre extensions 4. presented Les services in TISPAN multimédia draft WG2TD11 sur réseau [3] but more IP de as nouvelle just additional functions descriptions in line with our IMS IPTV génération concept implemented in ScaleNet demonstrator as shown in Figure 1. UE Xc Xt HSS Gm Sh e2 NASS Cx Transport Functions In this paper we define functional entities for the presented functional architecture Figure 4.5 and Architecture propose new IMS-IPTV concept of service control for IMS based IPTV. Several enhancements for distributed IPTV media delivery functional elements and new ed IPTV ne change reference pas les fonctionnalités points are introduced. de base de All cethese dernier. enhancements MSCF est utilisé are pour des necessary in more realistic environments. In following section we PTV services enables tâches de would contrôle like des to flux explain [Mikoczy main et principles al. 2007]. of Chaque this IPTV terminal functional (UE) a au moins quatre interfaces architecture pour le contrôle des média via l interface Xc et les flux en cours de tion (single sign-on) livraisonthe via l interface User Equipment Xd ainsi communicates que l interfacewith Gm the pouriptv le cœur Service du réseaux IMS Control Functions via the Core IMS for the purpose of session er, numbering et enfin management, l interface Xt pour and may le serveur use d the application Xt (enhanced IPTV Ut (voir interface) la Figure 4.5). enablers (presence, reference point for the purpose of service profile configuration or Le Media interaction Control with Fonctions IPTV application (MCF) peut server contrôler (in our lerealisation Media Delivery it is Fonctions (MDF) pour also permettre used for service également discovery la construction and selection d un contenu functionalities). adaptable. Les multimédia communicate externes peuvent with être the importés IMS based de sources NGN externes service de control. médiaswe via l interface IPTV application server functions (IASF) use the ISC interface to Xg avec propose MDF (Media to introduce Delivery Functions). Multimedia Service Control Function al advantages such as (MSCF) which should be used as reusable service control element with existing NGN for any multimedia services not just for IPTV services. This d media adaptation as additional functional element extend IMS core without special tegrated voice, data, needs to change IMS core functionality or interfaces. MSCF is adruple play service used for control tasks across distributed media control and e4 IPTV Supporting Functions IPTV Application Functions ISC IMS-based session and service control (P-/S-/I-CSCF & MSCF) Gq' RACS Y2 Xd IPTV Media Control Functions Xp IPTV Media Delivery Functions Xg External Media Sources Figure 1. Simplified and adapted IMS IPTV functional architecture for ScaleNet 4.4 Conclusion alled sometimes also delivery architecture. Each UE has at least four interfaces for media control over Xc (originally Xc ) and media delivery over Ce chapitre Xd (originally a permisxc ) de présenter as well les as services Gm interface multimédia to IMS dansand un environnement Xt interface to IASF. Media Control Functions (MCF) can control IMS. Nous avons, d abord, introduit les motivations pour l utilisation de l IMS, puis présenté et illustré l architecture IMS et la structure de cœur IMS. Le cœur du réseau IMS est utilisé pour la session et le contrôle de média. Les protocoles utilisés dans IMS (comme SIP, AAA, etc.), qui sont standardisés par l IETF, sont également

4.4. Conclusion 61 présentés. Nous allons à présent nous consacrer, dans le chapitre suivant, à l étude et à la proposition d un algorithme d auto-diagnostic que nous appliquerons ensuite pour les services VoIP et IPTV dans un environnement IMS.

Deuxième partie Proposition d une méthode d auto-diagnostic

CHAPITRE5 Diagnostic avec Graphes Causaux Sommaire 5.1 Introduction........................ 65 5.2 Architecture du gestionnaire autonome........ 67 5.3 Modélisation de la connaissance par le graphe causal 68 5.3.1 Nœuds causaux...................... 68 5.3.2 Liens causaux....................... 70 5.3.3 Exemple.......................... 70 5.4 Le processus de diagnostic du diagnostiqueur.... 72 5.5 Définitions et notations.................. 74 5.5.1 Relations de causalité, graphe causal.......... 74 5.5.2 Pannes, Symptômes et Diagnostic........... 75 5.5.3 Diagnostics minimaux.................. 76 5.6 Conclusion......................... 77 5.1 Introduction Depuis l émergence des premiers systèmes experts, l automatisation du diagnostic à inspiré de nombreux travaux en intelligence artificielle (IA). Avec la complexité croissante des systèmes, avec l apparition de grands réseaux, avec l augmentation

66 Chapitre 5. Diagnostic avec Graphes Causaux des risques, il était devenu crucial d assister l homme dans les opérations de surveillance. Cette aide au diagnostic implique d automatiser un ensemble de tâches : détecter un fonctionnement anormal du système, puis à partir des observations anormales, détecter la cause du dysfonctionnement du système, afin de proposer éventuellement des actions à effectuer. Dans le cadre de cette thèse, nous nous intéressons au diagnostic dans son sens strict, c est-à-dire la recherche d explication(s) pour un ensemble de phénomènes anormaux observés, ceci dans le but d aider le gestionnaire autonome à prendre les bonnes décisions de réparation. Les premiers systèmes d aide au diagnostic s appuient sur la modélisation du raisonnement de l expert pour résoudre le problème (voir le chapitre 3, la section 3.3.2), ou sur l utilisation par analogie de cas déjà résolus. Ces premières approches, bien que très efficaces - certaines se sont montrées aussi efficaces que des experts humains - ont été critiquées dès le début des années 80. Les principaux reproches portent sur les difficultés d acquisition et de validation du modèle, sur la nécessité de connaître à l avance les pannes pouvant survenir, sur la difficulté de traiter les cas de pannes multiples, sur l absence de justification des réponses proposées, ainsi que sur les problèmes de maintenance de la base de connaissance lorsque le système évolue. Notre travail se situe dans le cadre des méthodes dites à base de modèles [Hamscher et al. 1992], car reposant sur une modélisation profonde du comportement ou du fonctionnement du système, proposées pour pallier aux faiblesses des premiers systèmes. Au sein de ces approches, deux grands courants se dessinent (voir le chapitre 4) : le diagnostic basé sur la cohérence, qui utilise un modèle de fonctionnement correct du système (en intégrant éventuellement la représentation des dysfonctionnements connus), et le diagnostic abductif, qui se base sur la représentation des dysfonctionnements. Dans le cadre de cette thèse, nous nous intéressons au diagnostic abductif, en particulier lorsqu il prend en compte l évolution des systèmes surveillés. Le diagnostic abductif s appuie sur la modélisation des enchaînements causaux reliant les pannes initiales à leurs effets observables. Ces enchaînements causaux peuvent être vus comme une justification des associations pannes/symptômes. Un modèle causal est donc a priori un modèle plus robuste qu un modèle associatif [Simmons 1992].

5.2. Architecture du gestionnaire autonome 67 Un des avantages des modèles causaux est la possibilité de représenter les interactions entre les pannes, afin de limiter la complexité du problème. Notre travail s est donc orienté vers la représentation de la connaissance nécessaire pour diagnostiquer un problème sous la forme d un graphe causal. Ce chapitre présentera l architecture que nous avons retenue pour le système autonome chargé du diagnostic. La modélisation par graphes causaux ainsi que le processus général de diagnostic utilisé par le diagnostiqueur seront ensuite décrits. Ce chapitre introduit également les définitions et notations nécessaires à la formalisation du processus de diagnostic. 5.2 Architecture du gestionnaire autonome Diagnostiqueur Algorithme de diagnostic Planification Connaissance Graphes causaux Base de règles (Politiques de lancement des tests) Echange de la connaissance Monitoring (Alarmes) Exécution Capteurs Actionneurs Ressources gérées Figure 5.1 L architecture du gestionnaire autonome chargé de l autodiagnostic Comme le décrit la figure 5.1, l architecture du gestionnaire autonome chargé de l auto-diagnostic est composée d une base de connaissance contenant les graphes causaux (voir la section 5), une base de règles utilisée pour le test (voir le chapitre 6)

68 Chapitre 5. Diagnostic avec Graphes Causaux et le module d échange de connaissances. La fonction de monitoring, comme dans le cas de l architecture IBM, permet de récupérer les informations sur la situation de la ressource gérée. Ici elle concernera plus spécifiquement les alarmes. Les alarmes sont ensuite analysées par le diagnostiqueur. Nous nous intéressons à la fonction d auto-diagnostic dans le cadre de nos travaux de recherche, c est pourquoi les modules planification et exécution qui permettent de réaliser la fonction d auto-réparation ne seront pas détaillées. La section suivante décrit la modélisation de la connaissance, et plus précisément le fonctionnement anormal du système géré en utilisant les graphes causaux. 5.3 Modélisation de la connaissance par le graphe causal Le graphe causal est une représentation générale intuitive et efficace pour modéliser les causalités régissant le fonctionnement du système à surveiller en cas de panne. Comme tout graphe, il est composé de nœuds et de liens. Les nœuds du graphe correspondent à différents états partiels du système. Ces nœuds sont reliés par des liens orientés qui modélisent la relation de causalité entre ces états. L arc est orienté de la cause vers l effet. La relation de causalité est supposée être acyclique (on s interdit les cycles de causalité du style de celui de la poule et de l œuf) aussi le graphe causal est, par définition, un graphe orienté acyclique. Cette hypothèse limite l expressivité de la représentation dans certains cas (par exemple, il n est pas possible de représenter des événements récurrents), mais elle permet de réduire grandement la complexité du raisonnement. À ce jour, cette hypothèse d acyclicité n a pas été un obstacle à notre démarche. 5.3.1 Nœuds causaux La structure du graphe causal est basée sur cinq types de nœuds et deux types de liens qui sont présentés dans les figures 5.2 et 5.3. Afin d enrichir la représentation, les nœuds du graphe peuvent être de différentes

5.3. Modélisation de la connaissance par le graphe causal 69 Cause primaire Cause intermédiaire Action de réparation Observation Test Figure 5.2 Représentation graphique des cinq types de nœuds du graphe causal catégories qui sont les suivantes (voir figure 5.2 pour leur représentation graphique) : Causes primaires (encore appelées défauts, pannes initiales, ou désordres) : sans antécédent dans le graphe, elles correspondent aux phénomènes à l origine du dysfonctionnement du système. Elles correspondent aux causes qui vont être recherchées de façon abductive. Causes intermédiaires (ou syndromes, états pathologiques) : elles représentent des états partiels du système, qui ne peuvent être directement observés. Elles ont des antécédents et des successeurs dans le graphe causal. Observations (ou manifestations) : ce sont les effets observables des pannes (par exemple des mesures anormales faites sur le système). Elles correspondent aux symptômes à expliquer et n ont jamais de successeurs (ce sont les effets finaux ). Il peut s agir des alarmes. Tests : Ils servent à vérifier un état ou une hypothèse. Du point de vue de la causalité, ce sont exactement des observations à la différence qu elles ne sont pas notifiées automatiquement mais doivent être explicitement demandées. Ce type de nœuds sert à représenter des requêtes à des bases de données ou des tests à exécuter. Actions de réparation : elles sont définies comme des concepts associés à un état intermédiaire (ou à une conjonction d états intermédiaires) et représentent les états nécessitant une réparation. Ces nœuds sont un peu particulier dans la mesure où ce ne sont pas véritablement des états partiels et qu ils ne participent pas à l enchaînement causal des causes et des effets. On peut les considérer comme des étiquettes qui serviront à compléter le diagnostic une fois

70 Chapitre 5. Diagnostic avec Graphes Causaux celui-ci achevé. Ces actions sont utilisées comme indication des traitements supplémentaires à effectuer. Les Observations et les Tests constituent l ensemble des observables du système dont le comportement en cas de panne est modélisé par le graphe causal. Les Tests que nous proposons dans la structure de graphe causal sont innovants. 5.3.2 Liens causaux De la même façon, nous envisageons plusieurs types de liens causaux. Seuls deux types sont utilisés dans notre approche (voir la figure 5.3) : les causes sûres où la cause produit systématiquement l effet (l effet est donc un effet systématique de la cause). Par exemple : livebox débranchée cause sûre pas de connectivité IP. les causes possibles où la cause peut produire ou pas l effet (la cause est une explication possible de l effet) ; l effet n est pas systématique. Par exemple : surcharge de CPU cause possible crash système. Figure 5.3 Représentation graphique des liens Cause sûre et Cause possible 5.3.3 Exemple La figure 5.4 montre un exemple de demande de service VoIP dans un environnement IMS, présentant les différentes relations de causalité qui peuvent être mises en œuvre. Ce graphe contient deux observables : une alarme IMPU (IP Mutimedia Public Identity) qui remonte spontanément et un test Unknown Client qui peut être déclenché pour tester si un client est effectivement inconnu ou non dans la base de données lorsque celui-ci veut utiliser le service VoIP. La panne de non-synchronisation de la base de données (SLF no sync.) et la panne de client inconnu (Unknown client) ont pour symptôme la même alarme. La distinction entre ces deux causes s appuiera précisément sur le test disponible. Et

5.3. Modélisation de la connaissance par le graphe causal 71 Unknown client in HSS (No account) Unknown client in SLF(No account) SLF no synchronizaton Test of unknown client Resynchronization SLF Client barring in SLF IMPU unknown in SLF IMPU barring in SLF Alarm unknown IMPU in SLF Figure 5.4 Graphe causal pour IMS (extrait)

72 Chapitre 5. Diagnostic avec Graphes Causaux faire cette distinction sera nécessaire puisque si le diagnostic conclut sur un problème de synchronisation, l action de réparation (Resynchronization SLF) devient envisageable. Enfin, toujours sur cet exemple, l ensemble des causalités sont sûres à l exception de la panne de synchronisation de la base de données du SLF qui peut avoir pour conséquence que le client est inconnu et/ou interdit (barring) sans pour autant en avoir la certitude. On utilise alors la causalité de type possible. Le graphe causal permet une modélisation modulaire. Il peut modéliser chaque partie de la propagation d un défaut d un sous-système comme un sous-graphe causal, puis la fusion de ces sous-graphes donne le graphe causal global. La modélisation est également extensible, ce qui signifie qu elle permet, étape par étape, le raffinement de la propagation d un défaut en ajoutant les causes sur le haut du graphe causal. Ainsi, certaines causes primaires deviennent donc les causes intermédiaires quand les chemins de causalité sont étendus dans le graphe causal. Dans l exemple précédent, on peut établir une nouvelle cause au fait que le client soit interdit (barring) qui viendrait compléter le graphe actuel sans pour autant remettre en cause le reste de celui-ci. La section suivante décrira le principe général du processus de diagnostic. 5.4 Le processus de diagnostic du diagnostiqueur Le processus de diagnostic consiste à recueillir toutes les observations actuelles, et ensuite, à déterminer toutes les causes primaires qui pourraient expliquer ces observations. Le diagnostic pourra éventuellement lancer des tests afin de discriminer les ambiguïtés restantes. Enfin, les nœuds actions de réparation connectés pour identifier les causes déterminent les actions à exécuter pour la réparation. Afin de réaliser ce processus, plusieurs états sont associés à chaque nœud : Guilty/Coupable : pour un nœud de symptôme (test ou observation), cela signifie que le symptôme a été observé et doit être expliqué par, au moins, un de ses prédécesseurs. Pour un nœud intermédiaire, cela signifie que l état pathologique correspondant est affirmé et doit aussi être expliqué par, au moins,

5.4. Le processus de diagnostic du diagnostiqueur 73 un de ses prédécesseurs, et pour une cause primaire, cela signifie que cette cause est responsable du problème actuel. Les actions de réparation dans l hypothèse reliée aux nœuds coupables sont candidates pour la réparation. Innocent : pour un nœud de type symptôme, cela signifie que le symptôme n est pas observé (i.e. l alarme n est pas présente ou le test renvoie un résultat négatif), pour une cause (primaire ou pas), cela signifie qu elle n est pas impliquée dans le chemin de causalité et donc que la cause doit être cherchée ailleurs. Le processus de diagnostic consiste à développer des hypothèses cohérentes avec les règles de propagation de causalité qui suivent, et ce jusqu à la détermination des causes primaires nécessaires et suffisantes pour expliquer les symptômes observés (et les résultats des tests exécutés). Ces règles de propagation de la causalité sont les suivantes R1 : si un nœud est coupable, alors tous ses successeurs reliés par un lien de type cause sûre sont coupables. R2 : si un nœud est coupable, au moins un de ses prédécesseurs est coupable (sauf s il s agit d une cause primaire, auquel cas cette cause fait partie du diagnostic) R1 : si un nœud est innocent, alors tous ses prédécesseurs de cause sûre sont innocents (car sinon, on violerait la règle R1). R2 : si tous les prédécesseurs sont innocents, le nœud est innocent (car sinon, on violerait la règle R2). R3 : pour un nœud de test, son état deviendra Guilty ou Innocent en fonction de son résultat d exécution (l exécution d un test permet donc d ajouter des observations dans le processus). R4 : pour un nœud de réparation, si et seulement si, l état de son prédécesseur de cause sûre est coupable, l action de réparation sera mise en œuvre. Il faut noter que ces règles de propagation sont monotones. Elles permettent donc de garantir que l algorithme de diagnostic s arrêtera dans tous les cas. Les états initiaux des nœuds sont établis comme suit : les nœuds des symptômes observés sont coupables (guilty), ceux qui ne sont pas observés (l alarme n est pas

74 Chapitre 5. Diagnostic avec Graphes Causaux présente) sont innocents. 5.5 Définitions et notations 5.5.1 Relations de causalité, graphe causal Définition 5.5.1 (Graphe causal) Le graphe causal est un graphe acyclique orienté défini par un couple G = (,S) où : est l ensemble des nœuds du graphe ; S est la relation de causalité (successeur). Notation 5.5.2 (Successeurs et prédécesseurs, descendants et ascendants) Soit un graphe causal G = (,S), pour chaque nœud n, on note : S(n) : le sous-ensemble des successeurs de n ; S(n) : le sous-ensemble de contenant tous les descendants de n (fermeture transitive de S) S 1 (n) : le sous-ensemble des nœuds dont n est successeur ; S 1 (n) : le sous-ensemble de tous les ascendants de n. Par exemple, sur le graphe de la figure 5.5, on voit que S(d ) = {m, j, s}, S(d ) = {m, j,s,q,r }, S 1 (k ) = {b, g } et S 1 (k ) = {b, g,a,e}. Par extension, si N est un sous-ensemble de, on notera S(N ) (resp. S 1 (N )) l ensemble de tous les descendants (resp. ascendants) des noeuds de N. S(N ) = S(p) et S 1 (N ) = S 1 (p) p N p N L hypothèse du graphe acyclique se traduit alors par la propriété suivante : Proposition 5.5.1 (Graphe acyclique) Le graphe causal G = (,S) est un graphe acyclique si et seulement si n, n / S(n)

5.5. Définitions et notations 75 ^ S -1 (k) a b c d e f S -1 (k) g h i ^ S(d) k l m j S(d) n o p q r s Figure 5.5 Illustration des définitions S, S, S 1 et S 1 5.5.2 Pannes, Symptômes et Diagnostic Définition 5.5.3 (Causes primaires et Observables) Pour un graphe causal donné G = (,S), on définit l ensemble des pannes et l ensemble des observables 1 de la façon suivante : = {n S 1 (n) = } (l ensemble des pannes du graphe) = {n S(n) = } (l ensemble des observables du graphe) Notons que regroupe les nœuds correspondant aussi bien aux alarmes qu aux tests, la distinction interviendra uniquement à la section 6.5. Pour le graphe de la figure 5.5 : les pannes sont donc = {a,b,c,d } et les observables sont = {n,o,p,q,r,s}. Définition 5.5.4 (Symptômes d une panne) Une observable a est un symptôme (e.g. une alarme) de la panne p si et seulement si, il existe un chemin de causalité de p vers a. Autrement dit si a S(p). L ensemble des symptômes d une panne p est ainsi défini par S(p). 1. On oublie délibérément les actions de réparation à ce stade dans la mesure où elles n interviennent pas dans le raisonnement du diagnostic mais ne sont utilisées qu en fin de processus, lorsque le diagnostic est achevé.

76 Chapitre 5. Diagnostic avec Graphes Causaux Sur le graphe de la figure 5.5, il existe un chemin de c vers o (c f h l o) ; o est un effet de la panne c (ou encore, c est une cause possible de l alarme o). L ensemble des descendants de c est défini par S(c) = {f,h,i,l,m,o,p,q,r }, (o S(c)) et l ensemble des ascendants de o est défini par S 1 (o) = {a,b,c,e, f, g,h,k,l } (c S 1 (o)). Toujours dans cet exemple, les effets observables de la panne c sont définis par S(c) = {o,p,q,r }. Définition 5.5.5 (Indépendance des pannes) Si deux pannes p 1 et p 2 sont indépendantes, alors l ensemble des effets (symptômes observables et causes intermédiaires) de la cooccurrence de ces deux pannes est l union des effets de chacune des pannes. Autrement dit : S({p 1,p 2 }) = S(p 1 ) S(p 2 ) Définition 5.5.6 (Diagnostic) Soit un graphe causal G = (,S) et un ensemble A d alarmes (observations), un diagnostic D est un sous-ensemble de qui explique l ensemble des observations. Autrement dit : D est un diagnostic pour A ssi : A S(D) = S(p) Plusieurs approches du diagnostic peuvent être envisagées : la plus basique peut être celle consistant à trouver un diagnostic expliquant les symptômes. Le problème de cette approche trop simpliste est qu on risque de passer à côté d une autre alternative d explication lorsqu il y a ambiguïté dans le diagnostic. L approche la plus sûre, quoique la plus coûteuse en temps de calcul, consiste à trouver l ensemble de tous les diagnostics expliquant A. La notion de diagnostics minimaux permet de restreindre cet ensemble sans nuire à l exhaustivité du diagnostic. p D 5.5.3 Diagnostics minimaux Remarquons que si D est un diagnostic pour A, alors p, s il n y a pas d interaction entre pannes (hypothèse des pannes indépendantes), D {p} est un diagnostic pour A.

5.6. Conclusion 77 Preuve : Si D est un diagnostic pour A, alors on a A S(D). Sous l hypothèse des pannes indépendantes, on a S(D {p}) = S(D) S(p). On a bien A S(D {p}) et, D {p} est donc bien un diagnostic pour A. Aussi, pour un même ensemble de symptômes A, on peut ordonner les diagnostics correspondants à l aide de la relation. Comme on peut toujours grossir le diagnostic en lui adjoignant des pannes supplémentaires (toujours sous l hypothèse de l indépendance des pannes qu on fera dans l ensemble de ce mémoire), on va plutôt orienter le diagnostic de façon à trouver les diagnostics minimaux. Définition 5.5.7 (Diagnostic minimal) Soit un graphe causal G = (,S) et un ensemble A d alarmes (observations), un diagnostic D est un diagnostic minimal pour A si et seulement si il n existe pas de diagnostic D pour A tel que D D. Autrement dit, si D et D sont deux diagnostics minimaux pour A et que D D alors D = D. La recherche du diagnostic minimal s appuie sur le constat qu une justification simple est meilleure qu une autre plus compliquée (le fameux «Rasoir d Occam»). Autrement dit, si on n a pas besoin d une panne pour expliquer un symptôme, alors il est inutile de faire l hypothèse que cette panne est active. L objectif du diagnostic sera alors la recherche de l ensemble des diagnostics minimaux. 5.6 Conclusion Dans ce chapitre, nous avons présenté la modélisation de la causalité des pannes par un graphe causal ainsi que le principe général du diagnostic. Dans le cadre de cette thèse, nous nous intéressons au diagnostic abductif, en particulier lorsqu il prend en compte l évolution des systèmes surveillés. Le diagnostic abductif s appuie sur la modélisation des enchaînements causaux reliant les pannes initiales à leurs

78 Chapitre 5. Diagnostic avec Graphes Causaux effets observables. Ces enchaînements causaux peuvent être vus comme une justification des associations pannes/symptômes. Un modèle de graphe causal est donc a priori un modèle plus robuste q un modèle associatif. Nous avons également présenté les définitions et notations nécessaires à la formalisation du processus de diagnostic. Les chapitres 6 et 7 décriront formellement les algorithmes mis en œuvre pour réaliser le diagnostic.

CHAPITRE6 L Algorithme de Diagnostic de base Sommaire 6.1 Introduction........................ 79 6.2 Recherche des diagnostics................ 80 6.3 Algorithme de recherche des diagnostics minimaux. 82 6.4 Alarmes absentes ou perdues.............. 83 6.5 Introduction des Tests.................. 84 6.5.1 Proposition initiale pour le lancement des Tests.... 84 6.5.2 Solution améliorée pour un diagnostic insuffisant... 85 6.5.3 Politiques de lancement des Tests........... 88 6.6 Cause sûre et cause possible............... 88 6.7 Conclusion......................... 89 6.1 Introduction Ce chapitre présente l algorithme de diagnostic de base proposé pour le diagnostiquer (voir le chapitre 5, section 5.2) ainsi que les différentes extensions qui ont permis de prendre en compte les tests à réaliser en cours de diagnostic.

80 Chapitre 6. L Algorithme de Diagnostic de base 6.2 Recherche des diagnostics L algorithme présenté ici calcule l ensemble de tous les diagnostics et non celui de l ensemble des diagnostics minimaux (voir la section 6.3). Il ne s agit donc pas de l algorithme souhaité mais il permet de décrire l architecture générale de cet algorithme qui sera ensuite adaptée aux réseaux autonomes dans les sections suivantes. L algorithme s appuie sur un ensemble d hypothèses H, et se termine lorsqu il ne reste aucun nœud à expliquer dans les hypothèses (les hypothèses sont closes). Définition 6.2.1 (Hypothèse de diagnostic) Une hypothèse H de diagnostic est définie par : 1. un ensemble G(H) de nœuds coupables (cet ensemble contient A) 2. un ensemble I(H) de nœuds innocents 3. un ensemble X (H) G(H) contenant tous les nœuds inexpliqués (i.e. sans prédécesseur coupable) Définition 6.2.2 (Hypothèse close) Une hypothèse est close lorsqu elle explique tous ses symptômes et lorsqu elle est cohérente, c est-à-dire lorsque : X (H) = et I(H) G(H) = Lors de l initialisation de l algorithme, on partira de l hypothèse initiale H 0 qui s appuiera sur A comme l ensemble des alarmes à expliquer. Par défaut, les autres alarmes seront considérées comme inactives : A = \ A. Les procédures sont décrites ci-dessous : La procédure 1 décrit le processus de calcul de l ensemble D des diagnostics. Cette procédure permet de parcourir l ensemble des hypothèses du diagnostic et de repérer les hypothèses closes. La procédure 2 permet de développer les hypothèses. Cette procédure décrit le traitement à faire pour chaque prédécesseur d un nœud à expliquer. La procédure 3 assure la propagation de la causalité et la détection du cas d inconsistance d une hypothèse.

6.2. Recherche des diagnostics 81 Procédure 1 Calcul de l ensemble D des diagnostics Pré-requis : A A = 1: H = {H 0 } avec H 0 défini par G(H 0 ) = X (H 0 ) = A et I(H 0 ) = A 2: tant que H faire 3: Choisir H dans H (et le supprimer de H) 4: si X (H) = (l hypothèse H est close) alors 5: Le diagnostic D est défini par D = G(H) 6: D D {D} 7: sinon 8: exécuter Développer H 9: fin si 10: fin tant que Procédure 2 Développer H 1: Choisir n X (H) (et le supprimer de X (H)) 2: pour tout m S 1 (n) faire 3: Créer H en dupliquant l hypothèse de diagnostic H 4: G(H ) G(H ) {m} 5: exécuter Propager m dans H 6: si H est consistant alors 7: H H {H } 8: fin si 9: I(H) I(H) {m} 10: fin pour Si, à la fin de l algorithme, D =, c est que le modèle ne permet pas d expliquer les fautes (i.e. le modèle est faux, ou probablement, incomplet). Nous pouvons modifier la politique de déroulement du diagnostic en changeant la procédure de choix H dans H des hypothèses de diagnostic à développer (ligne 3 de l algorithme). Bien entendu, cela n aura aucune incidence sur le résultat de l algorithme mais uniquement sur l ordre d exploration des hypothèses. Cela aura

82 Chapitre 6. L Algorithme de Diagnostic de base Procédure 3 Propager m dans H 1: si S(m ) I(H ) alors 2: renvoyer H est inconsistant 3: sinon 4: G(H ) G(H ) S(m ) 5: renvoyer H est consistant 6: fin si une incidence sur l ordre d exécution des tests (voir section 6.5) ou sur la façon de communiquer avec les diagnostiqueurs voisins lors de la distribution de l algorithme (voir le chapitre 7). La ligne 9 de la procédure 2 permet d éviter d explorer plusieurs fois les mêmes hypothèses lors du déroulement de l algorithme. Cet algorithme de base est exhaustif : il explore l ensemble des diagnostics possibles et ne se restreint pas aux diagnostics minimaux. Il s agit donc ensuite d extraire les diagnostics minimaux de D, ce qui peut être fait par un tri de l ensemble D. Le problème réside plutôt dans le nombre d hypothèses à gérer lors du calcul de D plutôt que son tri proprement dit. 6.3 Algorithme de recherche des diagnostics minimaux Plutôt que de construire l ensemble des diagnostics, comme il s agit de chercher à terme les diagnostics minimaux, nous allons utiliser la propriété résultant de l hypothèse des pannes et éviter de développer inutilement des hypothèses. Le remplacement de la procédure 2 par la procédure 4 permet d éviter d explorer bon nombre d hypothèses qui ne peuvent conduire qu à des diagnostics non minimaux. Plus précisément, la procédure 2 développe toutes les hypothèses, sans considérer les hypothèses valides ou non. Par exemple, une situation possible est que certains états des nœuds soient déjà fixés (expliqués), alors les hypothèses correspondantes n ont pas besoin d être développées. La procédure 4 permet de déduire ces hypothèses invalides afin de conduire à un diagnostic minimal [Lu et al. 2011].

6.4. Alarmes absentes ou perdues 83 Procédure 4 Développer H 1: Choisir n X (H) (et le supprimer de X (H)) 2: si S 1 (n) = ou S 1 (n) G(H) alors 3: H H {H} (n est déjà expliqué, H reste valide) 4: sinon 5: pour tout m S 1 (n) faire 6: Créer H en dupliquant l hypothèse de diagnostic H 7: G(H ) G(H ) {m} 8: exécuter Propager m dans H 9: si H est consistant alors 10: H H {H } 11: fin si 12: I(H) I(H) {m} 13: fin pour 14: fin si 6.4 Alarmes absentes ou perdues Une alarme inactive est une alarme qu on sait ne pas être active au moment du diagnostic. Une telle information peut être utilisée lors du diagnostic puisqu une panne ayant pour effet une telle alarme ne peut faire partie du diagnostic. En revanche, une alarme absente ou perdue correspond à une absence d information, nous ne savons pas si le symptôme est présent ou non. Soit l ensemble des informations liées aux alarmes qui remontent, nous avons vu que, par défaut A A = (les alarmes non observées sont considérées comme les alarmes inactives représentées par A ). Dans ce cas, il suffit d exécuter l algorithme avec A = \ A. Cependant, il se peut que certaines alarmes soient perdues, dans ce cas nous ne pouvons pas conclure sur leur état. Donc l ensemble A \ A. L algorithme reste inchangé. Les diagnostics obtenus supposeront que certaines de ces alarmes seront actives mais perdues. Pour un diagnostic D donné, l ensemble des alarmes actives est :

84 Chapitre 6. L Algorithme de Diagnostic de base p D S(p) Et donc les alarmes supposées perdues par ce même diagnostic sont : p D S(p) \ A En revanche, si on souhaite ajouter un calcul de vraisemblance aux diagnostics (afin de les classer du plus au moins probable par exemple), cette vraisemblance peut s appuyer sur le nombre ou la nature des alarmes supposées perdues. 6.5 Introduction des Tests Nous traitons ici le cas où certains observables ne remontent pas spontanément mais correspondent à des tests à déclencher (ou à des requêtes à exécuter). Dans ce cas, certains observables de sont étiquetés comme des tests (i.e. appartiennent à ). Nous tenons compte ainsi de la présence des nœuds qui permettent d ajouter des observables lors du déroulement de notre algorithme. 6.5.1 Proposition initiale pour le lancement des Tests L idée initiale était de reproduire la même démarche que l algorithme de base (dans les sections 6.2 et 6.3 ) et à chaque fois qu une hypothèse traite un nœud de test, le test associé sera exécuté. Les hypothèses qui sont closes à ce stade seront revues en éclaircissement du résultat du test. En effet, deux processus séparés sont utilisés : le premier pour l exécution du diagnostiqueur et un deuxième pour le lancement des tests. Le déroulement de l algorithme est donc le suivant : Commencer le processus de diagnostic par le développement des hypothèses. Une fois qu une hypothèse a besoin d un résultat de test, arrêter le processus de diagnostic en cours : 1. Lancer le test d abord ; 2. Ensuite, l hypothèse qui a lancé le test ainsi que les hypothèses supposées closes à ce stade sont réinitialisées et insérées de nouveau dans

6.5. Introduction des Tests 85 l ensemble des hypothèses à traiter. La réinitialisation consiste à ramener l hypothèse à son état initial avec ses ensembles initiaux de nœuds innocents et coupables. De cette manière, les hypothèses seront retraitées en prenant en considération les résultats des tests. 6.5.2 Solution améliorée pour un diagnostic insuffisant En regardant le déroulement de cette implémentation de l algorithme, nous nous sommes aperçus que les hypothèses ne prennent en considération que le résultat des tests qui apparaissent dans l ensemble des nœuds coupables ou innocents. Ce résultat n est bien évidemment pas satisfaisant puisqu on aura des cas où l hypothèse peut être close mais elle ne permet pas d expliquer toutes les observations (les alarmes déclenchées et les nœuds tests estimés coupables). Un cas présenté dans la Figure 6.1 peut donc avoir lieu. Les hypothèses (partie gauche du graphe) sont closes alors que toutes les observations n ont pas été expliquées. Client No payment AS no synchronizaton Client barring in AS Client Barring in HSS Test of client barring IMPU unknown in AS Resynchronization AS IMPU barring in AS Alarm unknown IMPU in AS Figure 6.1 Exemple d un diagnostic insuffisant Cette première approche d intégration des tests dans le déroulement de l algo-

86 Chapitre 6. L Algorithme de Diagnostic de base rithme présente ainsi les deux problèmes suivants : Le manque d optimisation en traitant plusieurs fois une même hypothèse si elle était considérée close à un moment et qu ensuite, plusieurs tests sont lancés. La possibilité de retenir des diagnostics partiels qui ne permettent pas d expliquer tous les observables. Afin de pallier ces problèmes, une solution était de faire une séparation entre le processus de développement des hypothèses et celui du lancement des tests. Dès que le processus de développement des hypothèses est terminé, le processus de lancement de tous les tests peut commencer. Il n y aura donc pas d interruption du diagnostiqueur pour exécuter les tests. La procédure 5, ci-dessous, décrit le processus de calcul de l ensemble D de diagnostic consistant avec les tests. Procédure 5 Calcul de l ensemble D de diagnostic consistant avec les tests Pré-requis : D : l ensemble de diagnostic à traiter ; : l ensemble des tests disponibles. 1: D =, D : l ensemble du diagnostic consistant avec les tests 2: pour tout D D faire 3: T T ( S(D)) 4: fin pour 5: exécuter les tests dans T T I : l ensemble des tests de résultat Innocent T G : l ensemble des tests de résultat Guilty 6: pour tout D D faire 7: si T I S(D) = alors 8: D D {D} (D est consistant avec les tests) 9: fin si 10: fin pour 11: renvoyer D Deux nouveaux ensembles de nœuds ont été ajoutés afin d assurer cette séparation de processus : Un ensemble de nœuds supposés innocents et Un ensemble de nœuds supposés coupables.

6.5. Introduction des Tests 87 Ces deux ensembles ne peuvent contenir que des observables. Un nœud de test est inséré dans l ensemble des nœuds supposés innocents si par propagation, l hypothèse suppose que ce nœud est Innocent. Un nœud de test est inséré dans l ensemble des nœuds supposés coupables si par propagation, l hypothèse suppose que ce nœud est Guilty. L ensemble des nœuds supposés innocents doit aussi contenir pour chaque hypothèse tous les observables qui ne sont ni innocents, ni coupables, ni supposés coupables par cette hypothèse. Ainsi, chaque hypothèse sera au courant du déclenchement d une alarme et du changement d état d un nœud de test. En procédant ainsi, on contourne le problème d avoir des diagnostics partiels. En se basant sur ces nouveaux ensembles, nous pouvons suivre la même démarche que pour l algorithme de base. Nous nous trouvons à la fin avec un ensemble d hypothèses closes. Parmi ces hypothèses, il y a celles qui ont été développées avec une supposition sur l état de ces nœuds observables. Ensuite, il est possible de commencer le processus de lancement des tests. C est l existence d un nœud dans l ensemble des nœuds supposés innocents ou des nœuds supposés coupables d une certaine hypothèse qui provoque le lancement du test. L état d un observable doit être communiqué à l ensemble des hypothèses. Ainsi, nous associons un historique à chaque nœud observable dans lequel sont marqués les intervalles de temps pendant lesquels le nœud est coupable ou innocent. Un même test ne sera exécuté qu une seule fois même s il a été supposé innocent (ou coupable) par plusieurs hypothèses. Dès que nous disposons du résultat d un test, nous devons aussi propager l état du nœud correspondant tout au long du graphe causal. Cette propagation peut induire des inconsistances de certaines hypothèses qui seront éliminées du résultat du diagnostic. Nous nous retrouvons au final avec un diagnostic permettant d expliquer tous les observables d une entité du système autonome. En revanche, les observables d autres entités peuvent avoir un état qui permet de changer le résultat du diagnostic. C est ainsi qu un algorithme distribué (présenté dans le Chapitre 7) a été conçu.

88 Chapitre 6. L Algorithme de Diagnostic de base 6.5.3 Politiques de lancement des Tests La politique de choix du test peut s appuyer sur le coût induit par le test (en terme de délai, de ressource informatique, etc.). Nous proposons trois politiques de lancement des Tests pour bien optimiser le processus de diagnostic par rapport à différentes conditions : Lancer tous les Tests avant le processus de diagnostic : cette politique s applique au cas où nous connaissons tous les états des nœuds dans le système. Lancer les Tests avec un ensemble de nœuds supposés innocents et un ensemble de nœuds supposés coupables : cette politique s applique au cas de la distribution, si un diagnostiqueur local «A» ne connaît pas tous les états du nœud du système, mais a besoin de connaître l état du nœud d un autre diagnostiqueur «B», en même temps, si «B» n a pas encore fini son processus de diagnostic, «A» peut d abord supposer le nœud dont il a besoin innocent ou coupable, puis l ajouter dans son hypothèse. Pour cette politique, il faut bien considérer le coût (des intervalles de temps et des ressources) avant de l utiliser. Lancer tous les Tests dès l achèvement du diagnostic : cette politique permet de juger si les hypothèses du diagnostic sont inconsistantes ou pas, afin d éliminer certains résultats de diagnostic. Le développement d un algorithme peut alors passer par le choix des tests à exécuter. 6.6 Cause sûre et cause possible La prise en compte des notions de causes sûres et possibles consiste à modifier les relations de précédence dans le graphe de la façon suivante : S(n) : ensemble des successeurs en tant que cause sûre. S 1 (n) : ensemble des prédécesseurs en tant que cause possible ou cause sûre. S(n) (resp. S 1 (n)) reste toujours la fermeture transitive de S(n) (resp. S 1 (n)). Les effets (certains) d une panne p sont toujours définis par S(p) et a est un effet possible d une panne p ssi a S 1 (p).

6.7. Conclusion 89 Les algorithmes précédents s appliquent alors de la même façon. 6.7 Conclusion Nous avons présenté l algorithme de base du diagnostic mis en œuvre par le diagnostiqueur ainsi que les différentes extensions proposées afin de prendre en compte les tests en cours de diagnostic. L algorithme présenté ici permet de calculer l ensemble de tous les diagnostics, il s appuie sur un ensemble d hypothèses H et se termine lorsqu il ne reste aucun nœud à expliquer dans les hypothèses (C est-àdire lorsque les hypothèses sont closes). Nous avons aussi tenu compte des alarmes absentes ou perdues ainsi que du cas où les observables ne remontent pas spontanément mais correspondent à des tests à déclencher (ou à des requêtes à exécuter). Le développement de notre algorithme peut passer par le choix des tests exécuter, c est-à-dire qu une partie de la politique de diagnostic réside alors dans le choix des tests à effectuer. L algorithme présenté dans ce chapitre permet de réaliser un auto-diagnostic centralisé, mais pour s adapter aux architectures autonomes et pour diminuer la complexité de calcul du diagnostic dans les systèmes complexes, cet algorithme de diagnostic doit être distribué. Nous consacrons donc le chapitre suivant à la distribution de notre algorithme.

CHAPITRE7 Distribution de l algorithme de diagnostic Sommaire 7.1 Systèmes distribués.................... 91 7.2 Architectures pour un système de diagnostic..... 94 7.3 Principe........................... 95 7.4 Algorithme distribué................... 98 7.5 Architecture du réseau autonome............ 100 7.6 Conclusion......................... 101 7.1 Systèmes distribués Un système distribué est constitué d un rassemblement de composants (matériels ou logiciels) qui interagissent et collaborent pour réaliser une cible commune. Un système distribué coordonne un certain nombre de processus qui s exécutent sur différents composants. Les processus associent leurs activités en envoyant des messages à travers le réseau de communication. Un réseau autonome est un système distribué. Il doit avoir la capacité de communiquer avec des entités distantes d une manière ouverte et évolutive. Le terme «ouvert» indique que chaque composant est continuellement ouvert à l interaction

92 Chapitre 7. Distribution de l algorithme de diagnostic avec d autres composants. Le terme «évolutif» indique que le système peut facilement être modifié pour tenir compte des changements dans le nombre de composants, de ressources et l architecture du système. Les caractéristiques d un réseau autonome peut compliquer la tâche de diagnostic. Par rapport aux caractéristiques, tout d abord la nature de la plupart de ces systèmes est fortement évolutive, dans le sens où il est possible d enlever ou d ajouter des composants. Donc, cela demande que le système de diagnostic soit suffisamment flexible pour supporter un tel changement du système. Les informations et les ressources utilisées pour le diagnostic doivent pouvoir facilement être mises à jour. Pour un réseau autonome, le nombre de composants étant souvent important, le calcul du diagnostic doit être efficace. Les composants sont souvent hétérogènes, mais le mécanisme du diagnostic doit être suffisamment générique pour s adapter à tous les types de composants. Le système de diagnostic doit être capable de supporter les évolutions du réseau.

7.1. Systèmes distribués 93 composant composant composant composant composant composant composant composant composant a). Diagnostic centralisé b). Diagnostic hiérarchique composant composant composant composant composant composant composant composant composant c). Diagnostic distribué d). Diagnostic hiérarchique et distribué Figure 7.1 Différentes architectures d un système de diagnostic composant composant

94 Chapitre 7. Distribution de l algorithme de diagnostic 7.2 Architectures pour un système de diagnostic La technique utilisée pour exécuter le diagnostic est dépendante de l architecture du système de diagnostic. La plupart des systèmes classiques pour le diagnostic reposent sur une architecture centralisée (voir la Figure 7.1 - a) : un unique système en charge du diagnostic collecte toutes les alarmes (C est l approche centralisée présentée au chapitre 6). Cette forme de diagnostic montre deux problèmes principaux dans le cas des systèmes distribués qui peuvent atteindre une taille importante. Le premier problème est le nombre potentiellement exorbitant d alarmes à traiter par le système de diagnostic. Le second problème est le nombre important de communications pouvant occuper les ressources utiles en concurrence avec les services à destination des clients. Les solutions s appuient sur différentes architectures comme celles présentées Figure 7.1 : L architecture hiérarchique (voir la Figure 7.1 - b) qui permet de dispatcher les tâches de diagnostic entre différents niveaux d abstraction. Cette architecture permet ainsi de diminuer le nombre d alarmes à traiter en comparaison d un système de diagnostic central. L architecture distribuée (voir la Figure 7.1 - c) : chaque sous-système de diagnostic (local) calcule d abord son propre diagnostic à partir des informations locales à sa disposition, puis un diagnostic global sera calculé par échanges d informations entre les systèmes locaux. Cette méthode a l avantage de descendre complètement les tâches de diagnostic. D ailleurs, il semble intéressant d exécuter le diagnostic aussi proche que possible de la source des alarmes, ceci afin de permettre de diminuer les problèmes de délais et de pertes d alarmes. Toutefois, il y a aussi un risque de produire un grand nombre de communications. L architecture hiérarchique et distribuée (voir la figure 7.1 - d) qui regroupe les deux méthodes précédentes. Les tâches de diagnostic consistent à collectionner toutes les alarmes actuelles de dysfonctionnement, et ensuite, à déterminer toutes les causes primaires qui pourraient expliquer ces alarmes. Dans un système distribué, les alarmes peuvent se

7.3. Principe 95 produire souvent en cascade, c est-à-dire que la propagation des erreurs de composant à composant augmente très rapidement. Pour exécuter le diagnostic, il faut identifier les premières alarmes qui ont été lancées, puisqu elles sont souvent les plus proches de la source de la panne. Certaines approches se concentrent sur le point liée à l algorithme distribué, et proposent des méthodes de monitoring distribué basée sur plusieurs superviseurs communicants [Boel & van Schuppen 2002, Debouk et al. 2000, Yoo & Lafortune 2002]. D autres approches combinent des algorithmes distribués avec la caractérisation des comportements du système [Fabre et al. 2005, Boel & Jiroveanu 2004, Genc & Lafortune 2003]. L algorithme, présenté suivante, appartient à la seconde catégorie. Dans ce chapitre, l algorithme présenté repose sur l architecture distribuée qui répond bien à la problématique d auto-diagnostic des réseaux autonomes. Toutefois l architecture hiérarchique et distribuée est également envisageable et peut présenter un intérêt dans certaines situations. 7.3 Principe La distribution de l algorithme dans le cas des réseaux autonomes va donc s appuyer sur l architecture distribuée présentée section 7.2 : les différents nœuds du graphe causal correspondent à des variables d état liées aux composants du système autonome (réseaux, composants IMS, etc.). Le principe va consister à découper le graphe causal en fonction des composants de l architecture du système. Chaque composant (ou groupe de composants) autonome aura son diagnostiqueur qui établira ses hypothèses de diagnostic à partir de la connaissance dont il dispose (sous-graphe du graphe causal global) et devra les confronter aux diagnostiqueurs voisins afin que chacun opte pour un diagnostic compatible et cohérent avec ses voisins. La validité de l algorithme distribué sera vérifiée en s assurant des points suivants : les diagnostics locaux seront compatibles avec les observations locales et le sous-graphe causal local. tout diagnostic local sera compatible avec au moins un diagnostic local de chacun de ses voisins.

96 Chapitre 7. Distribution de l algorithme de diagnostic Plus formellement, on peut voir, dans notre cas, le travail d un diagnostiqueur local comme une projection du diagnostiqueur global tel que présenté dans les chapitre précédents. Un diagnostiqueur local s appuie sur un sous-graphe de G = (,S) et son diagnostiqueur voisin s appuie sur un autre sous-graphe de G appelé G v, G v = ( v,s), qu on définit par l ensemble c = ( v ) et S la relation s appliquant sur c. Les symptômes concernant le diagnostiqueur local (i.e. les symptômes devant être expliqués) sont alors A c (idem pour A ). Il existe malgré tout un nouveau type de nœud dans le graphe local, ce sont les nœuds de c qui sont causalement reliés à des nœuds qui ne sont pas dans. Ces nœuds sont les nœuds de «connexion» entre diagnostiqueurs locaux, et c est leurs changements d état (coupable ou non) qui vont déclencher des échanges de messages entre diagnostiqueurs. On définit alors deux frontières entre les graphes : la frontière des effets composée des nœuds qui sont successeurs de nœuds locaux mais dépendent d un autre diagnostiqueur (notée G ) et la frontière des causes (ou prédécesseurs) qui regroupe les nœuds qui ne peuvent être expliqués localement mais par un autre diagnostiqueur (notée 1 G ). La Figure 7.2 illustre cette notion qui est définie formellement ci-après. a b c d e G' f g h i k l m j n o p q r s Figure 7.2 Frontières des effets et des causes Définition 7.3.1 (Frontières des effets et des causes) Soit le graphe causal G = (,S). Soit un sous-graphe G = (,S) de G (i.e. ).

7.3. Principe 97 La frontière des effets (ou successeurs) de G est définie par : G = n n / et S 1 (n) La frontière des causes (ou prédécesseurs) de G est définie par : 1 G = n S 1 (n) Pour le sous-graphe G de la Figure 7.2, on a 1 G = {f,m} et G = {k,l }. Note : par définition, les frontières ne contiennent ni observables, ni pannes, ni actions de réparation. Avec ces définitions, on déroule l algorithme de diagnostic comme dans les chapitres précédents moyennant les transformations suivantes : Le graphe causal local est défini par ( G,S) (on étend le sous-graphe en lui incorporant ses frontières). Les observables locaux sont définis par G (on ajoute la frontières des effets dans les observables). Les causes primaires sont définies par 1 G des causes dans les causes primaires). (on ajoute la frontière À l issue des diagnostics locaux, il reste à les confronter aux diagnostics des voisins. Pour cela, il y a deux types de vérifications à faire pour chaque diagnostic D : La vérification des causes : les causes primaires correspondant à la frontière (i.e. D 1 G ) doivent être expliquées par les diagnostiqueurs voisins : on envoie donc le diagnostic avec les causes primaires incriminées en tant qu alarmes. La vérification des effets : les effets de frontière supposés par le diagnostic (i.e. S(D) G ) ne doivent pas être en contradiction avec les alarmes observées par d autres diagnostiqueurs : on envoie donc le diagnostic avec les effets de frontières comme causes primaires à propager dans le diagnostiqueur voisin. Cela suppose également que le diagnostiqueur est en mesure de réagir à des messages de ce type. Le comportement est le suivant. Lors de la réception d une frontière d effets à expliquer (i.e. réception d un sous-ensemble de G comme alarmes actives), ces alarmes sont ajoutées à l ensemble A et le diagnostic s exécute comme précédemment. Lors de la réception d une frontière de causes à propager (i.e. réception d un sous-ensemble de 1 G ), on propage ces causes comme dans l algorithme de base présenté au chapitre 6 et le diagnostic se poursuit.

98 Chapitre 7. Distribution de l algorithme de diagnostic 7.4 Algorithme distribué L algorithme distribué permet de fournir des explications à des alarmes déclenchées en tenant compte des différents composants d un système autonome. L algorithme permet de faire la communication entre les différents diagnostiqueurs locaux. En effet, le déclenchement d une alarme a pour effet le démarrage du diagnostiqueur local correspondant au composant dans lequel l alarme a été déclenchée. Le résultat du diagnostic local doit, ensuite, être confronté aux diagnostiqueurs voisins, c est-à-dire que l hypothèse du diagnostic local doit fusionner les autres hypothèses des diagnostiqueurs voisins (produit cartésien avec conservation uniquement des hypothèses cohérentes). La communication entre diagnostiqueurs est décidée par l état des nœuds de «connexions». En effet, un diagnostiqueur local décide de communiquer avec d autres diagnostiqueurs, si et seulement si, parmi ses hypothèses il y a au moins une hypothèse qui suppose qu un nœud de «connexion» est Guilty. En effet, il s agit soit de trouver une explication distante pour ce nœud, soit de vérifier que l état Guilty de ce nœud n est pas en compromission avec un observable distant. La procédure 8 ci-dessous présente la communication des nœuds de «connexion» c = ( v ) entre le sous-graphe G = (,S) et son voisin (sous-graphe) G v = ( v,s). Procédure 6 La communication entre G et G v Pré-requis : c : l ensemble de nœuds de «connexion», c = v 1: H c 2: pour tout D D faire 3: si c (D S(D)) alors 4: Créer H c : G(H c ) = {D S(D)} X (H c ) = { c (D S(D))} I(H c ) = 5: H c H c {H c } 6: fin si 7: fin pour 8: envoyer H c à G v

7.4. Algorithme distribué 99 Quand G v reçoit H c de son voisin G, la procédure 7 permet de calculer l ensemble D de diagnostics dans G v à base de H c. Procédure 7 Calcul de l ensemble D dans G v à base de H c Pré-requis : G v reçoit H c de G 1: H v H c 2: tant que H v faire 3: Choisir H dans H v (et le supprimer de H v ) 4: si X (H) = alors 5: Le diagnostic D est défini par D = G(H) 6: D D {D} 7: sinon 8: exécuter Procédure 4 : Développer H 9: fin si 10: fin tant que Lorsque la décision de communiquer est prise, l ensemble de toutes les hypothèses du diagnostiqueur local ayant une supposition sur un nœud de «connexion» est envoyé aux diagnostiqueurs voisins. Le diagnostiqueur voisin développe ses hypothèses en commençant par introduire les nœuds de «connexion» supposés innocents par le diagnostic précédent dans son ensemble de nœuds innocents et les nœuds de «connexion» supposés coupables par le diagnostic précédent dans son ensemble de nœuds coupables. A la fin du diagnostic, le résultat est transmis au diagnostiqueur précédent. Une même hypothèse peut avoir besoin de contacter plusieurs diagnostiqueurs. Ce contact peut se faire d une manière simultanée (les nœuds de communication appartiennent à différents composants du système autonome) ou bien d une manière successive (une succession de diagnostics pour une même hypothèse). La détection d une inconsistance permet d interrompre la succession des diagnostiqueurs et ainsi d optimiser le processus de diagnostic. La procédure 8 présente l algorithme de diagnostic distribué qui a intégré tous les procédures nécessaires afin de réaliser le diagnostic distribué.

100 Chapitre 7. Distribution de l algorithme de diagnostic Procédure 8 L algorithme de diagnostic distribué 1: exécuter Procédure 1 (obtenir l ensemble de diagnostic D) 2: exécuter Procédure 5 (obtenir l ensemble de diagnostic D consistant avec les tests) 3: exécuter Procédure 6 (réaliser l échange des hypothèses entre les différents diagnostiqueurs) 7.5 Architecture du réseau autonome La figure 7.3 représente l architecture du réseau autonome chargé de l autodiagnostic. Chaque gestionnaire autonome effectue un premier diagnostic local et si nécessaire échange ses hypothèses de diagnostic avec ses voisins afin de chacun opte pour un diagnostic compatible et cohérent. Diagnostiqueur 1 Algorithme de diagnostic Planification Diagnostiqueur 2 Algorithme de diagnostic Planification Connaissance Connaissance Graphes causaux Base de règles (Politiques de lancement des tests) Echange de la connaissance (Algorithme distribué) Graphes causaux Base de règles (Politiques de lancement des tests) Monitoring (Alarmes) Exécution Monitoring (Alarmes) Exécution Capteurs Actionneurs Ressources gérées Capteurs Actionneurs Ressources gérées Figure 7.3 Architecture d un réseau autonome chargé de l auto-diagnostic Les changements dans l environnement réseau ne remettent pas en cause le fonctionnement de l algorithme d auto-diagnostic qui reste valable quelque soit l évolution du réseau. Par contre, la qualité du diagnostic dépend de la qualité des graphes causaux qui devront pouvoir être mis à jour avec l évolution du réseau. Cette mise à jour peut ce faire grâce aux gestionnaires autonomes de haut niveau par l intermédiaire des points de contact (capteurs et actionneurs).

7.6. Conclusion 101 7.6 Conclusion Nous avons décrit le principe de la distribution de l algorithme et explicité l algorithmes formel. L algorithme distribué que nous proposons permet de fournir des explications à des alarmes déclenchées en tenant compte des différents composants d un système autonome. L algorithme permet également de faire la communication entre les différents diagnostiqueurs locaux. La communication est réalisée par les nœuds de «connexion», il s agit de trouver une explication distante pour ce nœud et de vérifier que l état de ce nœud n est pas compromis vis-à-vis d un observable distant. Nous présenterons l implémentation et l évaluation de notre algorithme d autodiagnostic distribué basé sur le graphe causal au chapitre 8.

Troisième partie Implémentation et évaluation

CHAPITRE8 Implémentation dans un environnement IP de nouvelle génération Sommaire 8.1 Introduction........................ 106 8.2 Description des composants............... 106 8.2.1 Le cœur de réseau Open IMS.............. 106 8.2.2 Les terminaux...................... 107 8.2.3 La plate-forme de développement............ 108 8.3 Implémentation...................... 111 8.3.1 Scénario d implémentation................ 111 8.3.2 Flux d appel....................... 120 8.3.3 Les résultats de tests................... 121 8.4 Extension proposée pour le service IPTV....... 130 8.5 Synthèse des résultats et analyse............ 131 8.6 Conclusion......................... 131

106 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération 8.1 Introduction Les chapitres 5, 6 et 7 ont permis de présenter l approche que nous avons proposée pour l auto-diagnostic. L approche se base principalement sur l utilisation de graphe causal. Ce chapitre est un descriptif des différentes étapes d exécution de l algorithme de diagnostic. Nous présentons également les différents éléments utilisés dans le cadre de cette démonstration de faisabilité : le graphe causal utilisé, le scénario de test considéré et la configuration du service de VoIP des tests. Finalement, nous étendons notre approche au service IPTV 8.2 Description des composants 8.2.1 Le cœur de réseau Open IMS Figure 8.1 OpenIMS OpenIMS [OpenIMS 2006] est un cœur de réseau IMS basé sur la solution open

8.2. Description des composants 107 source SIP Express Router (SER). Il a été développé par l institut Fraunhofer FO- KUS en Allemagne et les premières versions sont apparues à partir de 2006 et sont destinées à des plateformes du monde Linux. Cette solution fournit toutes les fonctions élémentaires d un cœur de réseau IMS, à savoir : P-CSCF, I-CSCF et S-CSCF. Il fournit également la fonction HSS permettant de provisionner un certain nombre d utilisateurs et de leur associer un profil de service nécessaire à la mise en œuvre de l invocation de services. OpenIMS nous apporte les fonctions de contrôle élémentaires d un réseau IMS permettant d enregistrer des utilisateurs et d établir des appels. Celui-ci fonctionne cependant de manière ouverte et l ensemble des messages échangés sont tout autant visibles que si les fonctions avaient été réparties sur des serveurs différents. Il a fallut cependant, afin de permettre d établir des appels avec des clients distants, configurer chacune des fonctions de façon spécifique pour que les messages puissent être routés correctement. Ainsi l ensemble des fonctions sont en écoute sur l interface système externe et non pas uniquement sur le «localhost» comme cela aurait pu être le cas si les clients avaient été locaux eux-aussi. De la même façon, le HSS doit être configuré afin de permettre un accès externe par un AS via l interface S h (voir la figure 8.1). 8.2.2 Les terminaux Les terminaux actuellement les plus intéressants pour être utilisés dans l environnement Open IMS sont les suivants : UCT IMS Client [UCTIMSClient 2006] Ce client IMS a été conçu pour être utilisé en conjonction avec Open IMS. C est donc une solution intéressante pour compléter notre réseau cœur car elle a été, de ce fait, testée et validée avec ce dernier. Le client UCT a été développé par un groupe de recherche de l Université du Cap en Afrique du Sud. La dernière version présente encore quelques dysfonctionnements, notamment dans la gestion des informations de présence, mais permet une émulation très correcte des caractéristiques principales d un terminal IMS. Seule une version Linux existe. Mercuro [Mercuro 2008] n est pas un produit open source mais une des toutes premières solutions commerciales d un client IMS. Ses caractéristiques sont

108 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération plutôt riches incluant notament une gestion de serveurs XDMS (XCAP Document Management Server) dès sa version gratuite d évaluation (version Bronze). Monster [Monster 2009] n est pas, à proprement parlé, un simple client mais plutôt un réel framework permettant de développer des applications clients destinées au monde mobile (IMS en autre). Il a également été développé par l institut Fraunhofer FOKUS. J ai fait un usage très restreint de cette solution qui adresse un grand nombre d environnements (Windows, Linux, Android, ect.). Par la suite, nous avons retenu le terminal UCT IMS Client, puisqu il peut être compilé avec Linux, et est plus simple à configurer. 8.2.3 La plate-forme de développement 8.2.3.1 L IDE Eclipse Le but de cette plateforme étant de pouvoir développer et tester de nouveaux services, il est, de ce fait, nécessaire de pouvoir bénéficier d un environnement couvrant ces deux fonctionnalités et s intégrant parfaitement à notre environnement. La plate-forme Eclipse remplit ce rôle et grâce à ses nombreux plug-ins apporte une réelle valeur ajoutée dans la simplification du processus de développement. 8.2.3.2 L environnement Java EE J2EE (Java 2 Enterprise Edition) est une norme proposée par la société Sun, portée par un consortium de sociétés internationales, visant à définir un standard de développement d applications d entreprises multi-niveaux, basées sur des composants. Une plateforme J2EE est composée de deux parties essentielles : Un ensemble de spécifications pour une infrastructure dans laquelle s exécutent les composants écrits en Java : un tel environnement se nomme serveur d application. Un ensemble d API qui peut être obtenu et utilisé séparément. Pour être utilisées, certaines nécessitent une implémentation de la part d un fournisseur

8.2. Description des composants 109 tiers. Application Multi-niveaux L architecture d une application entreprise se découpe idéalement en au moins trois tiers : La partie cliente : c est la partie qui permet le dialogue avec l utilisateur. Le client communique avec l application par le biais d un Navigateur ou d une Applet ou d une autre application Java locale. La partie métier : C est la partie qui représente le savoir-faire, l aspect fonctionnel de l application. Elle met en œuvre des mécanismes pour garantir l intégrité du système d information qu elle expose au travers d interfaces. Elle joue le rôle d interface entre des clients potentiels (en général des IHM) et la partie données. La partie données : c est la partie qui stocke les données. Elle représente le cœur de métier de l application. Les mécanismes mis en œuvre garantissent que les données sont toujours préservées, disponibles et exactes. L environnement d exécution des applications J2EE J2EE propose des spécifications pour une infrastructure dans laquelle s exécutent les composants (Servlet, JSP, EJB). Ces spécifications décrivent les rôles de chaque élément et précisent un ensemble d interfaces pour permettre à chacun de ces éléments de communiquer. Pour exécuter ces composants de natures différentes, J2EE défini des conteneurs pour chacun de ces composants. Il définit pour chaque composant des interfaces qui leur permettront de dialoguer avec les composants lors de leur exécution. Les conteneurs permettent aux applications d accéder aux ressources et aux services en utilisant les API. Les appels aux composants se font par des clients via les conteneurs. Les clients n accèdent pas directement aux composants mais sollicitent le conteneur pour les utiliser. Pour déployer une application dans un conteneur, il faut lui fournir deux éléments : l application avec tous les composants (classes compilées, ressources...) regroupée dans une archive ou module. Chaque conteneur possède son propre format d archive (War, Sar, Jar).

110 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération un fichier descripteur de déploiement contenu dans le module qui précise au conteneur des options pour exécuter l application. 8.2.3.3 Les SIP servlets Mobicents Sip Servlets : Les servlets sont des applications Java fonctionnant du côté serveur. Les servlets permettent de gérer des requêtes HTTP et de fournir au client une réponse HTTP dynamique (donc de créer des pages web dynamiques). Les servlets s exécutent dans un moteur de servlet utilisé pour établir le lien entre la servlet et le serveur web. Ainsi le programmeur n a pas à se soucier de détails techniques tels que la connexion au réseau, la mise en forme de la réponse http, etc. Les Servlets SIP sont une transposition des Servlets HTTP, basées sur le langage Java. Elles sont fonctionnellement très riches et permettent le développement de services évolués. Mobicents : Mobicents est un serveur hautement évolutif d applications événementielles, ainsi que la première et la seule plate-forme open source certifiée JSLEE ; cette technologie vient en complément de J2EE pour permettre la convergence voix, vidéo, messagerie instantanée et données dans des applications de nouvelle génération. Sip Servlets Mobicents : La solution SIP servlets de Mobicents est une plateforme ouverte permettant de développer et déployer des applications SIP portables et des services Web Java EE convergents. Il s agit de la première implémentation open source certifiée conforme de la Servlet SIP 1.1 (JSR 289 Spec). La plate-forme Mobicents peut utiliser à la fois les conteneurs JBoss et Tomcat. Mobicents Diameter : Mobicents propose une stack Diameter permettant de compléter notre environnement afin de permettre à notre AS de pouvoir s interfacer avec le HSS (Interface S h ). Celle-ci est fournie pré-intégrée avec l environnement JBoss et SIP Servlets. Cette interface nous permettra de développer des services nécessitant un accès à la base de données HSS. Le serveur JBoss : JBoss est un serveur d application Java du monde open source permettant d exécuter des applications développées avec des techno-

8.3. Implémentation 111 logies web de type Servlets, JSP, ect. Il constituera donc le moteur exécutif de notre serveur d application. Il fournit une plate-forme J2EE complète avec des fonctions telles que : 1. Un conteneur Enterprise Java Bean (EJB). 2. Java Management Extensions (JMX). 3. Java Connector Architecture (JCA). Par défaut, JBoss utilise Tomcat comme conteneur Web. 8.3 Implémentation 8.3.1 Scénario d implémentation 8.3.1.1 Architecture IMS d Implémentation L architecture que nous proposons ici et qui a été utilisée dans le cadre de mes travaux est évidemment une vue simplifiée d une architecture IMS telle qu elle serait vue par un opérateur dans le cadre d un déploiement car elle ne tient compte ni des problèmes d interconnexion avec le réseau RTC existant (et de ses services) ni des problématiques d accès, de QoS ou de facturation. Elle illustre principalement les mécanismes de routage de cœur de réseau mais permet cependant d y intégrer des services et de traiter les problématiques de plateforme de développement (SDP). Nous souhaitons nous appuyer sur cette infrastructure afin de mettre en place de façon concrète une implémentation du mécanisme de diagnostic autonome. Le but de cette infrastructure est de reproduire aussi fidèlement que possible une architecture IMS avec ses 4 couches distinctes, accès, média, contrôle et services. C est une instanciation concrète de l architecture IMS au travers de l utilisation de composants logiciels open source. Lorsque l on rattache des composants logiciels aux fonctions d une architecture IMS, on obtient la solution globale suivante :

112 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération! "#!#$%! "#$!! "#$"$%! "##!!! "#$%$&!! "#$%$&!! "#$!%&'! #()*+,!! Figure 8.2 Infrastructure IMS open source

8.3. Implémentation 113 8.3.1.2 Le graphe causal utilisé pour le service VoIP L implémentation de l algorithme est basée sur la plateforme IMS présentée dans le chapitre 4 et la section 8.3.1.1 ci-dessus. Le graphe causal sur lequel est basé cette implémentation diffère de celui présenté dans l article [Lu et al. 2010]. En effet, le graphe causal de l article (voir la Figure 8.3) se base sur un diagnostic global qui regroupe les composants suivants : les bases de données HSS et SLF et un serveur d application. No subscriber Client No payment Unknown client in HSS (No account) Client Barring in HSS Unknown client in SLF(No account) SLF no synchronizaton Test of unknown client Client barring in SLF Test of client barring Unknown client in AS(No account) AS no synchronizaton Client barring in AS IMPU unknown in SLF Resynchroni -zation SLF IMPU barring in SLF IMPU unknown in AS Resynchronization AS IMPU barring in AS Alarm unknown IMPU in SLF Alarm unknown IMPU in AS Figure 8.3 Le graphe causal global Cependant, l étude du cœur du réseau OpenIMS, nous a conduit à la conclusion qu il n est pas possible d intégrer la base de données SLF dans notre architecture. Nous avons donc envisagé de restreindre ce graphe causal à seulement deux composants : HSS et AS. Il fallait ainsi changer l alarme «Unknown IMPU in SLF» par l alarme «Unknow IMPU in HSS». Le nouveau graphe causal est le suivant :

114 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération No subscriber Client No payment Unknown client in HSS (No account) Client Barring in HSS Test of unknown client Test of client barring Unknown client in HSS(No account) IMPU barring in HSS Unknown client in AS(No account) AS no synchronizaton Client barring in AS IMPU unknown in AS Resynchronization AS IMPU barring in AS Alarm unknown IMPU in HSS Alarm unknown IMPU in AS Figure 8.4 Le graphe causal restreint à HSS et AS Cette solution a également été abandonnée car nous ne trouvions aucun scénario permettant de coller à cette modélisation. En effet, les deux alarmes ne peuvent pas être déclenchées en même temps. Le seul scénario permettant de déclencher l alarme «Unkown IMPU in HSS» est d appeler une personne qui n existe pas dans la base de données. L appel sera de toute façon terminé avant d atteindre le serveur d application. Un autre problème également rencontré était celui du déclenchement de l alarme «Unkown IMPU in AS». En effet, aucun service de VoIP n est bloquant au niveau du serveur d application. Les services comme Voice Mail, call transfer, push to talk, click to call ne déclenchent pas d alarmes lorsque le client veut passer un appel alors qu il n est pas abonné à un de ces services. La solution trouvée pour déclencher cette alarme est de concevoir un service VoIP qui nécessite une liste d utilisateurs associée au serveur d application. Ainsi, le serveur d application utilise son propre serveur d authentification pour autoriser l utilisateur et lui offrir des services adaptés à son profil. Un AS concentre toute l intelligence de services comme le serveur d appels, de messagerie instantanée, de

8.3. Implémentation 115 serveur vidéo, etc. Chaque serveur peut avoir son profil de souscription, si l AS ne connait pas l utilisateur dans sa base de données, il ne peut pas lui offrir de service et sa demande de service est rejetée. Cette solution nous a amenés à adapter le graphe causal pour notre implémentation (voir la figure 8.5). HSS diagnostiqueur No subscriber Unknown client in HSS (No account) Client No payment Client Barring in HSS Test of unknown client Test of client barring Unknown client in AS1 (No account) Client barring in AS1 Unknown client in AS2 (No account) Client barring in AS2 AS1 No synchronizaton AS2 No synchronizaton IMPU unknown in AS1 Resynchronization AS1 IMPU barring in AS1 IMPU unknown in AS2 Resynchronization AS2 IMPU barring in AS2 Alarm unknown IMPU in AS1 AS1 diagnostiqueur AS2 diagnostiqueur Alarm unknown IMPU in AS2 Figure 8.5 Le graphe causal utilisé Dans le cadre de l architecture autonome que nous avons présentée au chapitre 7, la mise à jour du graphe causal est réalisée par le gestionnaire autonome de haut niveau. Celui-ci doit être capable de modifier le graphe causal en fonction des ressources disponibles (absence de la base de données de SLF dans notre cas). Un changement a aussi été effectué au niveau des liens de causalité de ce graphe. Le lien entre les nœuds «IMPU barring in AS» et «Alarm unknown IMPU in AS» a été remplacé par un lien de type «possible». En fait, un client peut être barring pour un service sans pour autant être la cause de déclenchement de l alarme d «Alarm unknown IMPU in AS». Un diagnostiqueur sera donc installé au niveau du HSS. Un autre sera exécuté sur chaque serveur d application (AS SIP) (voir la figure 8.5). Nous pouvons soit

116 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération utiliser deux serveurs d application différents ou bien deux services différents ayant chacun sa propre base de données. Le développement à été fait avec le langage Java. Un graphe causal est généré par un fichier Dot 1 comme présenté dans l annexe A. 8.3.1.3 Déploiement du service VoIP Le service de VoIP que nous avons choisi pour notre implémentation, nommé CallControl, permet de contrôler la durée d appels pour les personnes qui sont abonnées à ce service et qui sont présents dans la base de données du serveur d application. Le développement de ce service est assuré par la conception d une Sip Servlet qui sera déployée dans notre serveur d application Mobicents. La logique de ce service est assurée par l implémentation des méthodes doinvite et dobye. Le déploiement de ce service se fait directement par l interface administrative de Mobicents 2. Cette interface est présentée dans la figure 8.6. Figure 8.6 Interface administrative de Mobicents Il est aussi possible de gérer l ensemble des services à déployer sur un même 1. http ://www.graphviz.org/ 2. http ://localhost :8001/admin-console/.

8.3. Implémentation 117 serveur d application 3. L interface de gestion est présentée dans la figure 8.7. Figure 8.7 Interface de gestion des Sip Servlets de Mobicents 8.3.1.4 Configuration du profil de service A chaque usager IMS est associé un profil d usager dans le HSS. Un profil d usager consiste en un ensemble de profils de service. Le profil de service est une collection d informations spécifique à l utilisateur, stockée en permanence dans le HSS. Il est transféré du HSS à un S-CSCF alloué à l aide de deux opérations user datahandling operations : Server-Assignment Answer(SAA) et Push-Profile-Request (PPR). Il est défini dans un document XML, dans un AVP Diameter. Un profil de service est composé d une liste de ifc (initial Filter Criteria). Un critère de filtrage (voir la Figure 8.8) est une information statique correspondant à une souscription d un usager à un service du domaine IMS. Il comprend les informations suivantes : AS address : Adresse du serveur d application à contacter (adresse SIP). Priority : Priorité du critère de filtrage indiquant sa position dans la liste. 3. http ://localhost :8001/sip-servletmanagement/org.mobicents.servlet.management.Sip ServletsManagement/SipServletsManagement.html

118 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération Trigger Point : Un Trigger Point est composé de 1 à N instances de SPT (Service Point Trigger). Des SPT peuvent être combinés à l aide d opérateurs logiques (AND, OR, NOT, etc.). Default handling : Correspond à la prise en charge par défaut si l entité S-CSCF n arrive pas à contacter l AS. Optionnal Service Information : Information de service facultative rajoutée au contenu de la méthode SIP avant qu elle ne soit acheminée à l AS. Initial Filter Criteria Priority: integer Pro,ilePartIndicator: enumerated Trigger Point ConditionTypeCNF: boolean Application Server ServerName: Sip URL Default Handling: enumerated Service Point Trigger Condition Negated: boolean Group: list of integer Service Information ServiceInfo:string Figure 8.8 Critères de filtrage initiaux (IFC) Le profil de service est obtenu par l entité S-CSCF auprès du HSS à travers l interface C x lorsque l usager s enregistre au sous-système IMS. Lorsqu une entité S-CSCF reçoit une requête SIP concernant un usager donné, elle évalue les critères de filtrage associés à cet usager un à un selon leur ordre de priorité. Si la requête SIP vérifie le critère de filtrage, l entité S-CSCF achemine la requête SIP au serveur d application correspondant. Si l entité S-CSCF ne peut joindre le serveur d application (AS) associé à un critère de filtrage (i.e, Serveur d application hors service), elle applique une prise en charge par défaut, indiquée dans le critère de filtrage par le paramètre Default call handling dont la valeur peut être : Continue, continuer à analyser les critères de filtrage de plus basse priorité dans la liste. Release, abandonner l analyse des autres critères de filtrage et libérer le dialogue.

8.3. Implémentation 119 Avec OpenIMS Core, ce profil de service peut être configuré directement sur l interface administrative du HSS. On crée donc un profil pour notre service et on définit la liste de ses abonnés. Le profil que nous avons crée est illustré dans la figure 8.9. Figure 8.9 Profil de service pour le service déployé sur Mobicents

120 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération 8.3.2 Flux d appel Les cas de tests considérés consistent à passer un appel d un abonné au service vers une autre personne. La figure 8.10 montre l acheminement de cet appel en cas d invocation du service et localise l alarme IMPU qui est associée au graphe causal correspondant [Lu et al. 2012a]. HSS diagnostiqueur No subscriber Unknown client in HSS (No account) Client No payment Client Barring in HSS Test of unknown client Test of client barring Unknown client in AS1 (No account) Client barring in AS1 Unknown client in AS2 (No account) Client barring in AS2 AS1 No synchronizaton AS2 No synchronizaton IMPU unknown in AS1 Resynchronization AS1 IMPU barring in AS1 IMPU unknown in AS2 Resynchronization AS2 IMPU barring in AS2 Alarm unknown IMPU in AS1 AS1 diagnostiqueur AS2 diagnostiqueur Alarm unknown IMPU in AS2 Visited network de «a» Home network de «a» Home network de «alice» AS1 Diagnostiqueur HSS Diagnostiqueur AS2 Diagnostiqueur Visited network de «alice» a P-CSCF P-cscf S-CSCF S-cscf AS I-cscf I-CSCF S-CSCF S-cscf AS P-CSCF P-cscf alice INVITE INVITE Evaluation ifcs Exécution du service INVITE INVITE LIR LIA INVITE INVITE Evaluation ifcs Exécution du service INVITE INVITE Figure 8.10 Flux d appel lors de l invocation d un serveur d application

8.3. Implémentation 121 8.3.3 Les résultats de tests Nous considérons que «a» appelle «alice». «a» est inscrit au service (voir la Figure 8.11) mais il n est pas présent dans la base de données de Mobicents. L alarme «Unknow IMPU in service 1» est donc déclenchée au niveau de AS1, comme le montre la figure 8.12. Figure 8.11 Enregistement du client «a»

122 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération Figure 8.12 L alarme declenchée au niveau de AS1 Les figures suivantes montrent le fonctionnement de notre mécanisme d autodiagnostic. Les différents états des nœuds représentés dans les figures sont différenciés par les trois couleurs présentées dans la figure 8.13. Guilty Innocent To explain Figure 8.13 Les 3 types de nœud Nous exécutons le processus de diagnostic, puis nous obtenons les deux hypothèses (Hypothèse 2 et Hypothèse 3) qui sont développées au niveau de diagnostiqueur de AS1 (comme montré dans les figures 8.14 et 8.15).

8.3. Implémentation 123 Figure 8.14 Hypothèse 2 au niveau de AS1 Figure 8.15 Hypothèse 3 au niveau de AS1

124 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération La Figure 8.16 indique que l hypothèse 7 exige la communication avec le diagnostiqueur de HSS. Figure 8.16 L hypothèse 7 exige la communication avec HSS

8.3. Implémentation 125 Nous lançons les Tests afin de vérifier si les hypothèses sont inconsistantes. Dans le cadre de notre proposition, la décision de lancement de test est prise d une manière automatique en consultant une base de règles de politique. Ici, nous considérons le cas où les tests confirment que le client existe dans HSS et qu il n est pas barring comme le montre la figure 8.17. Figure 8.17 Lancement des Tests

126 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération La Figure 8.18 montre que le résultat de hypothèse 7 sera donc rejeté en tenant compte des résultats des Tests. Figure 8.18 Le résultat concernant l hypothèse 7

8.3. Implémentation 127 Le résultat de l hypothèse 4 (voir la Figure 8.19) doit être rejeté lors de la communication avec le diagnostiqueur voisin, puisque le résultat du Test montre qu il est inconsistant si on le compare au résultat de l hypothèse 4. Figure 8.19 Les résultats concernant l hypothèse 4

128 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération En conséquence, les hypothèses 5 et 6 sont retenues au final [Lu et al. 2012a]. Figure 8.20 Les résultats concernant l hypothèse 5

8.3. Implémentation 129 Figure 8.21 Les résultats concernant l hypothèse 6

130 Chapitre 8. Implémentation dans un environnement IP de nouvelle génération 8.4 Extension proposée pour le service IPTV Nous avons présenté l implémentation de notre approche pour un service VoIP sur une plateforme OpenIMS dans la section précédente. Cette approche peut également être étendue à d autres services tels que l IPTV. La figure 8.22 présente un exemple de graphe causal pour le service IPTV basé sur SIP dans un environnement IMS. Dans cet exemple, il y a deux alarmes (deux observables) : «Alarm QoS in P-CSCF» (dans le domaine Client) et «Alarm QoE in Client» (dans le domaine de P-CSCF). Ce graphe causal est divisé en sept sous-graphes correspondant aux différents domaines. Le diagnostic pour les domaines de P-CSCF, S-CSCF, HSS, AS, AN (Access Network), PDP-PEP (Policy Decision Point et Policy Enforcement Point) et Client, est traité localement [Lu et al. 2012b]. HSS no update HSS Bad server address in AS Overcrowed server AS AN Exceeded Thresholds Profil change Update HSS Test changing profil Bad server address Verify address Media server problem Changing server Delay Test Jitter Test Test Packet Loss Correction of error Rate Test Configuration Problem in S-CSCF Media server problem S-CSCF Network Degradation PDP-PEP Bad policy applied Changing QoS class Bad MoS Test MoS Video interruption Video problem Configuration Problem in P-CSCF User unregistred Core IMS problem in P-CSCF Core IMS problem in S-CSCF Network problem Network QoS problem in AN Policy Problem Policy Problem in QoS Policy Correction Client Alarm QoE in Client P-CSCF Alarm QoS in P-CSCF Figure 8.22 Le graphe causal pour le service IPTV Chaque domaine a un diagnostiqueur local. Quand une alarme est présente dans un domaine, le diagnostiqueur local correspondant à ce domaine va exécuter son diagnostic local. Le résultat de ce diagnostic local doit être comparé avec celui des diagnostiqueurs voisins (domaines voisins). Les nœuds de «connexion» décident

8.5. Synthèse des résultats et analyse 131 la communication entre les diagnostiqueurs (domaines). Dans ce graphe, les nœuds de «connexion» sont présentés par les nœuds noirs. 8.5 Synthèse des résultats et analyse Notre approche d auto-diagnostic qui s appuie sur l utilisation de graphe causal a été implémentée pour un service VoIP sur une plateforme OpenIMS. Les résultats obtenus correspondent bien à ce qui est attendu. Ils prouvent la faisabilité de notre approche et aussi l intérêt pour le domaine des réseaux autonomes. Ainsi, l auto-diagnostic que nous proposons permet la scalabilité et le changement de l environnement réseaux. Mais notre choix de lancement de tests n est pas pratique pour toutes les situations. Le choix de politiques pour lancer les tests doit être bien considéré selon les situations et les besoins. Le développement d une politique dynamique pour les tests doit être pris en compte. Du côté des opérateurs qui ne peuvent pas accepter la solution boîte noire du control loop [Horn 2001], les actions de réparation ne peuvent pas être exécutée automatiquement. Ici, le diagnostic doit être le plus complet possible et présenté à l opérateur de la façon la plus synthétique possible. De plus, la complexité du graphe causal détermine la complexité du diagnostic. Aussi, les travaux pour créer et modifier dynamiquement des graphes causaux sont indispensables. Ces trois points sont très importants pour les recherches dans le domaine de l auto-diagnostic. 8.6 Conclusion Dans ce chapitre, nous avons détaillé l implémentation de notre approche. Un descriptif des différentes étapes d exécution de l algorithme de diagnostic a été fait dans un premier temps. Nous avons présenté ensuite les différents éléments utilisés dans le cadre de cette démonstration de faisabilité. L implémentation de notre approche a été réalisée sur une plateforme IMS, et nous avons montré que notre algorithme d auto-diagnostic pourrait être utilisé pour un exemple de service VoIP. Les résultats obtenus correspondent bien à ce qui est attendu. Notre approche a ensuite été étendu au service IPTV.

CHAPITRE9 Conclusion et perspectives Les réseaux autonomes représentent une rupture technologique qui permet d offrir aux opérateurs des possibilités de réductions des coûts de gestion et d intégration des réseaux et services, ainsi qu une intégration rapide de nouveaux services. Cette approche est d autant plus intéressante que les réseaux ne cessent de devenir complexes, en particulier l hétérogénéité des technologies de communication (fixe, mobile, filaire et sans fils), la variété des équipements terminaux voulant communiquer ensemble et la multiplication des services ayant des exigences de qualité de service. Le concept de réseaux autonomes aura donc pour objectif de résoudre le problème de la complexité de la gestion du réseau et de permettre de contrôler les équipements autonomes par des politiques de haut niveau. Dans ce contexte, la fonction d auto-réparation est primordiale. La tâche d autodiagnostic est complexe car une fois qu une panne ou qu une erreur s est produite, il est possible qu elle se propage dans le réseau entier. Ceci peut rendre difficile la tâche de trouver la cause de la panne et de dépanner en temps voulu. Une panne peut influencer les différents composants ou les autres opérations du réseau et augmente les coûts de façon évidente. La seule véritable option pour protéger les équipements réseaux et améliorer le service, est celle de la prévention et de la détection automatiques et évolutives des pannes. L auto-diagnostic, pour la détection de panne et des dysfonctionnements, est donc un sujet critique dans le cadre de ces réseaux. Contributions Les principales contributions de cette thèse ont consisté à concevoir une méthode d auto-diagnostic dans le cadre des réseaux autonomes, afin de réaliser la supervision des services multimédia (voix sur IP principalement) déployés

134 Chapitre 9. Conclusion et perspectives sur la base de réseaux NGN/IMS. Les problèmes de diagnostic que nous avons considéré consistaient à être en mesure de fournir un diagnostic complet, exhaustif des causes primaires à partir d un ensemble d observations (alarmes). Nous avons pris en compte des tests automatiques exécutés par décision du diagnostiqueur et proposé un algorithme distribué capable de tenir compte des différents domaines de gestion du réseau (notamment dans le cadre d un diagnostic de bout-en-bout). Plus spécifiquement, nous avons cherché à montrer l intérêt et le potentiel d utilisation du diagnostic à base de modèles - Graphe Causal, pour bien modéliser les causalités entre les pannes du système et les causes primaires et pour réaliser l algorithmique distribuée. Ce diagnostic est basé sur une modélisation explicite des comportements anormaux du système. Nous utilisons ensuite un algorithme de diagnostic générique qui utilise cette modélisation pour réaliser l auto-diagnostic. L algorithme d auto-diagnostic que nous avons proposé s appuie sur l utilisation de graphes causaux. Le principe est le suivant : lorsqu une alarme est déclenchée, l algorithme se lance et, grâce aux relations de causalité entre l alarme et les causes, les causes primaires vont pouvoir être identifiées et localisées. Puisque le graphe causal permet une modélisation modulaire et extensible, il est possible de le séparer ou de le fusionner pour répondre aux besoins des services et de l architecture du système. Cette caractéristique nous permet de proposer un algorithme distribué qui s adapte à l architecture des réseaux autonomes. Nous avons, ainsi, proposé un algorithme d auto-diagnostic qui permet également de réaliser le diagnostic distribué correspondant à l architecture du réseau autonome afin de réaliser un diagnostic global. Enfin, nous avons implémenté cet algorithme avec le langage Java et nous l avons utilisé pour un service VoIP sur une plateforme IMS en utilisant OpenIMS. Les résultats obtenus correspondent bien à ce qui est attendu et ont permis de prouver la faisabilité de notre solution qui peut être étendue à d autres services, tels que l IPTV. La solution que nous proposons est scalable. Le graphe causal peut se compléter avec les autres graphes causaux des réseaux qui s interconnectent avec ceux existants. Le graphe causal sera gigantesque à la fin, mais développé par sous domaine,

135 ce qui va permettre de les valider avant de les interconnecter via le partage de la connaissance. Nous avons proposons d inclure les tests dans le graphe causal qui constitue une partie innovante de la structure de graphe causal. Concernant le diagnostic à base de modèles que nous avons utilisé, il permet de séparer la connaissance (graphes causaux) et le raisonnement (l algorithme d autodiagnostic). L algorithme d auto-diagnostic est exécuté uniquement à partir d un modèle de fonctionnement du système (le graphe causal que nous utilisons). Cette séparation est bien adaptée à l architecture des réseaux autonomes (boucle de contrôle fermée) dont les 4 fonctions sont indépendantes et reliées par la connaissance. La distribution de l algorithme permet de résoudre le problème de passage à l échelle. À notre connaissance, il y a très peu de recherches sur la fonction d autorétablissement, notamment l auto-diagnostic, dans le domaine des réseaux autonomes. Notre approche permet de pallier une lacune dans ce domaine et de proposer une solution possible de développement de la fonction d auto-diagnostic dans le domaine des réseaux autonomes. Perspectives À l issue de ce travail nous dégageons plusieurs perspectives de recherche que nous évoquons ci-dessous : Automatisation du lancement des Tests Nous n avons pas complètement approfondi l optimisation du lancement des tests comme support du processus de mise en œuvre du modèle de graphe causal. La politique de choix du test peut s appuyer sur le coût induit par le test (en terme de délai, de ressource informatique,...). Notre choix (lancer tous les Tests dès l achèvement du diagnostic) n est pas pratique pour tous les cas, car certains tests sont souvent très coûteux quand le système est complexe et de grande taille. Exécution de l Action de Réparation Bien que dans notre exemple d application, ceci ne soit pas le cas, l exécution de l action de réparation peut être considérable. Cependant, les opérateurs ne peuvent pas accepter la solution boîte noire de la control loop [Horn 2001]. Après les résultats du diagnostic, la décision d exécution de l action de réparation doit être validée par l humain (experts ou adminitrateurs). Nous devons alors prendre en compte la validation et l autorisation

136 Chapitre 9. Conclusion et perspectives du côté des opérateurs et proposer une architecture adaptée aux opérateurs. Explicitation des nœuds de «connexion» entre les diagnostiqueurs Comme nous l avons mentionné au chapitre 7, la communication entre diagnostiqueurs est décidée par l état des nœuds de «connexion». Dans notre exemple d application, les éléments des réseaux sont homogènes, nous pouvons donc partager l état des nœuds de «connexion» entre deux diagnostiqueurs différents. Mais dans les systèmes héterogènes, nous ne pouvons les partager simplement, il faut définir une interface. La construction du graphe causal Notre algorithme d auto-diagnostic s appuie sur le modèle de graphe causal qui permet la scalabilité de notre approche. Puisque le graphe causal peut se compléter avec les autres graphes causaux des réseaux qui s interconnectent avec ce qui sont existant. Le graphe causal sera gigantesque à la fin, mais développé par sous domaine, ce qui va permettre de les valider avant de les interconnecter via l échange de la connaissance. La construction de graphe n est pas l objectif de notre étude. Nous ne proposons qu un type de modèle qui peut être utilisé pour réaliser l auto-diagnostic. L évolution du graphe causal peut être supportée par des gestionnaires de haut niveau qui se chargent de la création et de la modification dynamique des graphes causaux ainsi que de leur diffusion auprès des gestionnaires autonomes de bas niveau chargés du diagnostic. L évaluation de performance Nous avons, dans un premier temps, réalisé et implémenté une solution d auto-diagnostic pour un service VoIP dans l environnement IMS. Nous avons réalisé ainsi une preuve de concept. Il serait intéressant de réaliser d autres tests et d évaluer les performances de notre approche (temps pris par le diagnostic, coût du lancement les tests etc.)

ANNEXE A A.1 Représentation d un graphe causal 1 digraph causalgraph { 2 3 SLF1 [ label =" Alarm unknown \ nimpu in service 1", type = symptom, code ="5002", domain =" Service1 "] 4 SLF2 [ label =" IMPU unknown \ nin service 1", type = fault, domain =" Service1 "] 5 SLF3 [ label =" IMPU barring \ nin service 1", type = fault, domain =" Service1 "] 6 SLF4 [ label =" Client barring \ nin service 1", type =comm, domain =" Service1 "] 7 SLF5 [ label =" Unknown client \ nin service 1\ n( No account )", type =comm, domain =" Service1 "] 8 SLF6 [ label =" AS no sync ", type = initial, domain =" Service1 "] 9 SLF7 [ label =" resync. AS", type = action, domain =" Service1 "] 10 11 SLF2 -> SLF1 [ cause = possible ] 12 SLF3 -> SLF1 [ cause = possible ] 13 SLF4 -> SLF3 [ cause = sure ] 14 SLF5 -> SLF2 [ cause = sure ] 15 SLF6 -> SLF2 [ cause = possible ] 16 SLF6 -> SLF3 [ cause = possible ] 17 SLF6 -> SLF7 [ cause = sure ] 18 19 AS1 [ label =" Alarm unknown \ nimpu in service 2", type = symptom, code ="5003", domain =" Service2 "] 20 AS2 [ label =" IMPU unknown \ nin service 2", type = fault, domain =" Service2 "] 21 AS3 [ label =" IMPU barring \ nin service 2", type = fault, domain =" Service2 "] 22 AS4 [ label =" Client barring \ nin service 2", type =comm, domain =" Service2 "] 23 AS5 [ label =" Unknown client \ nin service 2\ n( No account )", type =comm, domain =" Service2 "] 24 AS6 [ label =" AS no sync ", type = initial, domain =" Service2 "] 25 AS7 [ label =" resync. AS", type = action, domain =" Service2 "] 26 27 AS2 -> AS1 [ cause = possible ] 28 AS3 -> AS1 [ cause = possible ]

138 Annexe A. 29 AS4 -> AS3 [ cause = sure ] 30 AS5 -> AS2 [ cause = sure ] 31 AS6 -> AS2 [ cause = possible ] 32 AS6 -> AS3 [ cause = possible ] 33 AS6 -> AS7 [ cause = sure ] 34 35 HSS1 [ label =" No subscriber ", type = initial, domain =" HSS "] 36 HSS2 [ label =" Unknown client \ nin HSS \n(no account )", type =comm, domain =" HSS "] 37 HSS3 [ label =" Test of\n unknown \n client ", type =test, domain =" HSS "] 38 HSS1 -> HSS2 [ cause = sure ] 39 HSS2 -> HSS3 [ cause = sure ] 40 HSS2 -> SLF5 [ cause = sure ] 41 HSS2 -> AS5 [ cause = sure ] 42 43 HSS4 [ label =" No payment ", type = initial, domain =" HSS "] 44 HSS5 [ label =" Client barring \ nin HSS ", type =comm, domain =" HSS "] 45 HSS6 [ label =" Test of client \n barring ", type =test, domain =" HSS "] 46 HSS4 -> HSS5 [ cause = sure ] 47 HSS5 -> HSS6 [ cause = sure ] 48 HSS5 -> SLF4 [ cause = sure ] 49 HSS5 -> AS4 [ cause = sure ] 50 }

A.1. Représentation d un graphe causal 139 Liste des abréviations A AAA Authentication, Authorization and Accounting AC AS Autonomic Communication Application Servers ACCA Autonomic Communication Coordination Action ACE ANA AOC AutoI Autonomic Commmunication Element Autonomic Network Architceture Autonomic and Opportunistic Communication Autonomic Internet AUTONETS AUTOnomic Networking for End To end Supervision B BIONETS Biologically-Inspired Autonomic Networks BGCF Breakout Gateway Control Function C CASCADAS Componentware for Autonomic, Situated-aware Communication and Dynamically Adaptable Services COPS CPN CSCF Common Open Policy Service Cognitive Packets Networks Call Session Control Function CT Centre Technique D DNS Domain Name System E ETSI European Telecommuication Standards Institute

140 Annexe A. F FET FP6-7 Future and Emergent Network Technologies Framework Programme 6 th - 7 th G GW Gateway H HAGGLE A novel Communication Paradigm for Autonomic Opportunistic Communication HSS Home Subcriber Server HTTP Hypertext Transfer Protocol I IA Intelligence Artificielle I-CSCF Interrogating-Call Session Control Function IEEE IETF IMPU Institute of Electrical and Electronics Engineers Internet Engineering Task Force IP Multimedia Public Identity IMS IP Multimedia Subsystem IP Internet Protocol IPSEC IPTV Internet Protocol Security Internet Protocol Television IST Information Society Technologies L LoD Live on Demand

A.1. Représentation d un graphe causal 141 M MAPE MMS MGCP MRFC MRFP Monitoring, Analyzing, Planning, Executing Multimedia Messaging Service Media Gateway Control Protocol Multimedia Resource Function Controller Multimedia Resource Function Processor N NGNs Next Generation Networks P P-CSCF Proxy-Call Session Control Function PDF PDP PEP Policy Decision Function Policy Decision Points Policy Enforcement Points Q QoS Quality of Service R RADIUS Remote Authentication Dial In User Service RSVF RTP RTCP RTSP Resource Reservation Protocol Real Time Protocol Real Time Control Protocol Real Time Streaming Protocol S SAC Situated and Autonomic Communication S-CSCF Serving-Call Session Control Function

142 Annexe A. SDP Session Description Protocol SIGTRAN Signalling Transport SIP SLF Session Initiation Protocol Subscriber Locator Function SMTP Simple Mail Transfer Protocol SOA Service Oriented Architecture T TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking TLS ToIP Transport Layer Security Telephony over IP U UE User Equipment UMF Unified Management Framework V VoD VoIP Video on Demand Voice over IP

Bibliographie [3GPP et al. 2002] 3GPP, GSM et ETSI. TS 123 002 : Universal Mobile Telecommunications System (UMTS) ; Network architecture. Rapport technique, ETSI, 2002. 52 [3GPP et al. 2005] 3GPP, GSM et ETSI. TS 24 229 : Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) - version 7.2.0 Release 7. Rapport technique, ETSI, 2005. 54 [3GPP 2003] 3GPP. Overview of 3GPP Release 5 - Summary of all Release 5 Features. Rapport technique, 3GPP - ETSI Mobile Competence Centre, 2003. 48 [3GPP 2007] 3GPP. TS 23 228 : IP Multimedia Subsystem (IMS) ; Stage 2 (Release 7). Rapport technique, 3GPP - ETSI Mobile Competence Centre, March 2007. 48 [ANA ] ANA : Autonomic Network Architecture. [Arpège 1992] Arpège. Gestion de réseaux : concepts et outils. Masson, 1992. [AutoI 2008] AutoI. Project AutoI. Site officiel http ://ist-autoi.eu/, flyer du projet recuperable à l adresse ftp ://ftp.cordis.europa.eu/pub/fp7/ict/docs/futurenetworks/projects-autoi-factsheet en.pdf, 2008. 27 [Autonomia 2007] Project Autonomia. Autonomia : Autonomic Control and Management Environment. Page officielle http ://acl.ece.arizona.edu/projects/autonomia Programmable/, 2007. 29 [Beaufils et al. 2008] Pierre Beaufils, Zièd Choukair et Sami Tabbane. Réseaux 4g. LAVOISIER, 2008. 53, 55 [Bertrand 2007] Gilles Bertrand. The IP Multimedia Subsystem in Next Generation Networks. May 30 2007. 50 [Bieber & Carpenter 2003] Guy Bieber et Jeff Carpenter. A Service- Oriented Component Architecture for Self-Forming, Self- Healing, Network-Centric Systems (Rev 2.0). Accessible at

144 Bibliographie http ://www.openwings.org/download/specs/openwingswp.pdf, 2003. 29 [BIO-NETWORKING 2007] Project BIO-NETWORKING. The BIO- NETWORKING Architecture. Accessible at http ://netresearch.ics.uci.edu/bionet/, 2007. 29 [Boel & Jiroveanu 2004] René K. Boel et George Jiroveanu. Distributed Contextual Diagnosis for very Large Systems. In Proceedings of WODES 04, pages 343 348, 2004. 95 [Boel & van Schuppen 2002] René K. Boel et Jan H. van Schuppen. Decentralized Failure Diagnosis for Discrete-Event Systems with Costly Communication between Diagnosers. In Proceeding of 6th International Workshop on Discrete Event Systems, pages 175 181, 2002. 95 [Boubour 1997] R. Boubour. Suivi de pannes par corrélation causale d alarmes dans les systèmes répartis : Application aux réseaux de télécommunication. PhD thesis, Ifsic/Université de Rennes 1, 1997. 35 [Boutaba et al. 2001] Raouf Boutaba, Salima Omari et Ajay Pal Singh Virk. SELF- CON : An architecture for self-configuration of networks. Journal of communication and networks ISSN 1229-2370, 2001. 29 [Brown & Patterson. 2001] A. Brown et D. Patterson. To err is Human. In Proceedings of First workshop of Evaluation and Architecture of dependanbility EASY 01, 2001. 3, 11 [Calhoun et al. 2003] P. Calhoun, J. Loughney, E. Guttman, G.Zorn et J. Arkko. RFC 3588 : Diameter Base Protocol. Rapport technique, IETF, 2003. 54 [Camarillo & Garcia-Martin 2004] Gonzalo Camarillo et Miguel-Angel Garcia- Martin. The 3g ip multimedia subsystem (ims) : Merging the internet and the cellular worlds. John Wiley & sons, Ltd, 2004. 52 [Camarillo 2005] Gonzalo Camarillo. Introduction to TISPAN NGN. Rapport technique, Ericsson, 2005. 48 [CASCADAS 2006] CASCADAS. Component-ware for Autonomic Situation-aware Communications, and Dynamically Adaptable Services. Page officielle http ://www.cascadas-project.org/, 2006. 26

Bibliographie 145 [Clark et al. 2003] David D. Clark, Craig Partridge, J. Christopher Ramming et John T. Wroclawski. A knowledge plane for the internet. In Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, pages 3 10, New York, NY, USA, 2003. ACM. [Console & Torasso 1991a] L. Console et P. Torasso. On the co-operation between abductive and temporal reasoning in medical diagnosis. Artificial Intelligence in Medicine, vol. 3, no. 6, pages 291 311, 1991. 42, 44 [Console & Torasso 1991b] L. Console et P. Torasso. A spectrum of logical definitions of model-based diagnosis. Computational Intelligenge, pages 133 141, 1991. 42 [Cuervo et al. 2000] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen et J. Segers. RFC 3015 : Megaco Protocol Version 1.0. Rapport technique, IETF, 2000. 55 [Cuevas et al. 2006] Antonio Cuevas, Jose I. Moreno, Pablo Vidales et Hans Einsiedler. The IMS Service Platform : A Solution for Next Generation Network Operators to Be More Than Bit Pipes. IEEE Communications Magazine, vol. August, pages 75 81, 2006. 53 [Dague et al. 2001] P. Dague, F. Krief, F. Lévy et A. Osmani, editeurs. Distributed model for an sdh telecommunication network diagnosis, Arlington, USA, 2001. ICIS 2001. 44 [Debouk et al. 2000] Rami Debouk, Stéphane Lafortune et Demosthenis Teneketzis. Coordinated decentralized protocols for failure diagnosis of discrete event systems. Journal of Discrete Event Dynamical Systems : Theory and Application, vol. 10(1/2), pages 33 86, 2000. 95 [Fabre et al. 2005] Eric Fabre, Albert Benveniste, Stefan Haar et Claude Jard. Distributed Monitoring of Concurrent and Asynchronous Systems. Journal of Discrete Event Systems, 2005. 95 [Fujitsu-Siemens 2003] Fujitsu-Siemens. Autonomic Systems : Concept for self-managing IT infrastructures. White Paper accessible at http ://sysdoc.doors.ch/fujitsusiemens/autkonz-3030e.pdf, 2003. 29

146 Bibliographie [Gaiti & Pujolle 1993] Dominique Gaiti et Guy Pujolle. L intelligence dans les réseaux. Eyrolles, Octobre 1993. 36 [Genc & Lafortune 2003] Sahika Genc et Stéphane Lafortune. Distributed Diagnosis Of Discrete-Event Systems Using Petri Nets. In Proceeding of 24th International Conference on Applications and Theory of Petri Nets., pages 316 336. LNCS 2679, 2003. 95 [Giordano & Puiatti 2006] Silvia Giordano et Alessandro Puiatti. Specification of first Haggle application and INFANT-Haggle. Accessible at http ://www.haggleproject.org/images/b/b0/d11 final.pdf, 2006. 27 [Grosclaude 2001] Irène Grosclaude. Diagnostic abductif temporel : scénarios de pannes, modèles causaux et traitement de l interaction. PhD thesis, Université de Rennes 1, 2001. [Group 2005] IBM Group. An architectural Blueprint for autonomic computing. Rapport technique, IBM White paper, June 2005. [Guerraz 2005] Bruno Guerraz. Construction de chroniques à partir d une modélisation du système. Application au diagnostic de réseaux de télécommunications. PhD thesis, Université de Rennes 1, Octobre 2005. [Hamscher & de Kleer Walter 1992] Walter Hamscher et Johan de Kleer Walter. Readings in model-based diagnosis. San Francisco, CA, USA, 1992. [Hamscher et al. 1992] Walter Hamscher, Johan de Kleer et Luca Console. Readings in model-based diagnosis. Morgan Kaufmann, San Meteo, CA, Etats- Unis, 1992. 40, 66 [Handley & Jacobson 1998] M. Handley et V. Jacobson. RFC 2327 : SDP : Session Description Protocol. Rapport technique, IETF, 1998. 54 [Handley et al. 1999] M. Handley, H. Schulzrinne, E. Schooler et J. Rosenberg. RFC 2543 : SIP : Session Initiation Protocol. Rapport technique, IETF, 1999. 54 [Hitachi 2007] Hitachi. Harmonous Computing. Accessible at http ://www.hitachi.co.jp/products/harmonious/center/gl/index.html, 2007. 29

Bibliographie 147 [Horn 2001] P. Horn. Autonomic Computing : IBM s Perspective on the State of Information Technology. Technical report, IBM T. J. Warson Labs, New York, USA, 2001. 14, 20, 28, 131, 135 [ISO10040 1991] ISO10040. Open Systems Interconnection, Systems Management Overview. ISO, 1991. 34 [ISO 1998] ISO. Information technology - Open Systems Interconnection - Systems management overview. ISO/IEC 10040, 1998. [ITU-T 2006] ITU-T. FG IPTV-R-0014. In 2nd FG IPTV meeting, Busan, Korean, 16-20 October 2006. International Telecommunication Union. 58 [Jacob et al. 2002] B. Jacob, D. K. Nadgir R. Lanyon-Hogg et A. F. Yassin. A practical guide to the IBM Autonomic Computing Toolkit. In Proceedings of 18th International Conference (ICLP 2002). IBM, 2002. 16, 20 [Keller ] Ariane Keller. Intergration Guidelines for the Final ANA Distribution. Rapport technique, ANA Project Deliverable D.4.8. [Kephart & Chess 2003] J. O. Kephart et D. M. Chess. The vision of Autonomic Computing. In IEEE Computer Society Press, volume 36, pages 41 50, Los Alamitos, CA, USA, January 2003. 16, 20 [Klenk et al. 2008] Andreas Klenk, Micheal Kleis, Benoit Radier, Sanaa Elmoumouhi, Georg Carle et Michael Salaun. Towards Autonomic Service Control in Next Generation Networks. In ICAS, pages 266 271. IEEE Computer Society, March 2008. [Konstantinou & Yemini 2003] Alexander V. Konstantinou et Yechiam Yemini. Programming Systems for Autonomy. In Autonomic Computing Workshop 5th Annual International Workshop on Active Middleware Services (AMS 03), page 186, 2003. 29 [Krief & Salaun 2006] Francine Krief et Michael Salaun. L autonomie dans les réseaux. Introduction. LAVOISIER, September 2006. [Lu et al. 2010] Jingxian Lu, Christophe Dousson, Benoit Radier et Francine Krief. Towards an Autonomic Network Architecture for Self-healing in Telecommunications Networks. In Proceedings of 4th International Conference on AIMS, Zurich, Switzerland, 2010. 113

148 Bibliographie [Lu et al. 2011] Jingxian Lu, Christophe Dousson et Francine Krief. A selfdiagnosis algorithm based on causal graphs. In Proceeding of 7th International Conference on Autonomic and Autonomous Systems, Venice, Italy, 2011. 82 [Lu et al. 2012a] Jingxian Lu, Christophe Dousson et Francine Krief. Distributed self-diagnosis algorithm for VoIP service over IMS network. In 9th IEEE - RIVF International Conference on Computing and Communication Technologies, Ho Chi Minh City, Vietnam, 2012. (Submitted). 120, 128 [Lu et al. 2012b] Jingxian Lu, Christophe Dousson et Francine Krief. Self-diagnosis architecture for QoS and QoE management in IPTV services over IMS network. In The Third International Conference on Communications and Networking, Hammamet, Tunisia, 2012. (Submitted). 130 [Mayer 1999] Emmanuel Mayer. Apprentissage inductif de scénarios pour la supervision de réseaux de télécommunications. PhD thesis, Université de Rennes 1, 1999. [Mbaye 2009] Maïssa Mbaye. Les sysèmes cognitifs dans les réseaux autonomes : une méthode d apprentissage distribué et collaboratif situé dans le plan de connaissance pour l auto-adaptation. PhD thesis, Université Bordeaux I, 2009. 19, 23, 25 [Menasce et al. 2001] D. A. Menasce, D. Barbara, et R. Dodge. Preserving QoS of e-commerce sites through self-tuning : a performance model approach. In Proceedings of the 3rd ACM Conference on Electronic Commerce (EC 01), pages 224 234, Tampa, Florida, USA, October 14-17 2001. ACM. 29 [Mercuro 2008] Mercuro. IMS Client. http ://www.mercuro.net/, 2008. 107 [Microsoft 2007] Microsoft. Dynamic Systems Initiative (DSI). Page officielle http ://www.microsoft.com/business/dsi/default.mspx, 2007. 29 [Mikoczy et al. 2007] Eugen Mikoczy, Dmitry Sivchenko, Bangnan Xu et Veselin Rakocevic. IMS based IPTV services : Architecture and Implementation. In Proceedings of the 3rd international conference on Mobile multimedia communications, 2007. 60 [Monster 2009] Monster. IMS Client. http ://www.monster-the-client.org/, 2009. 108

Bibliographie 149 [OpenIMS 2006] OpenIMS. The open source IMS core progect. http ://www.openimscore.org/, 2006. 106 [Osmani & Krief 1999] A. Osmani et F. Krief, editeurs. Model-based-diagnosis for fault management in atm networks, Colmar, France, 1999. ICATM 99. IEEE. 44 [Patterson 2002] D. Patterson. Availability and Maintainability Performance : New focus for a New Century. In USENIX conference on File and Storage Technologies FAST 2003, Monterey, 2002. 3, 11 [Pellegrini et al. 2006] Francesco De Pellegrini, Iacopo Carreras et Giuseppa Alfano. Application Scenario Analysis, Network Architecture Requirements and High-Level Specifications. In Deliverable of Bionets project accessible at http ://www.bionets.eu/docs/bionets D1 1 1.pdf, 2006. 26 [Pencolé 2002] Yannick Pencolé. Diagnostic décentralisé de systèmes à événements discrets : application aux réseaux de télécommunications. PhD thesis, Université de Rennes 1, Juin 2002. 39, 43 [Poole 1989] David Poole. Normality and Faults in Logic-Based Diagnosis. Artificial Interlligence, pages 1304 1310, 1989. [Pujolle 2008] Guy Pujolle. Les réseaux. Eyrolles, 2008. [Radvision 2006] Radvision. IMS SIP and Signaling, the Radvision perspective - A technology overview. Rapport technique, Radvision, 2006. 54 [Randall.Davis & Hamscher 1988] Randall.Davis et Walter C. Hamscher. Modelbased Reasoning Troubleshooting. In AI. Memo No.1059, 1988. 41 [Rosenberg et al. 2002] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley et E. Schooler. RFC 3261 : SIP : Session Initiation Protocol. Rapport technique, IETF, 2002. 54 [R.Pons et al. 1999] R.Pons, L. Travé-Massuyès et M. Porcheron. Model-based Diagnosis and maintenance of Time-verying Dynamic Systems. In 10th International Workshop on Principles of Diagnosis DX 99, Loch Awe, Scotland, June 1999. 41

150 Bibliographie [Schulzrinne et al. 2003] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson. RFC 3550 : RTP : A Transport Protocol for Real-Time Applications. Rapport technique, IETF, 2003. 55 [SELF-STAR 2007] Project SELF-STAR. Self-Star : Agents, Composants et Services Autonomiques. Accessible at http ://liuppa.univpau.fr/spip/article.php3?id article=4, 2007. 29 [Simmons 1992] R. Simmons. The roles of associational and causal reasoning in problem solving. In Artificial Intelligence 53, pages 159 207, 1992. 66 [Simoni & Znaty 1997] Noëmie Simoni et Simon Znaty. Gestion de réseaux et de service : similitude des concepts, spécificités des solutions. Masson, 1997. [Sluman 1989] Chris Sluman. A tutorial on OSI management. Computer Networks and ISDN Systems, vol. 17, pages 270 278, October 1989. [Sterritt & Bustard 2003] R. Sterritt et D. W. Bustard. Autonomic Computing : a mean of achieving dependanbility. In Proceedings of IEEE International Conference on the engeneering of computer based systems ECBS 03, pages 247 251, 2003. 14 [Strassner et al. 2007] John C. Strassner, Nazim Agoulmine et Elyes Lehtihet. FO- CALE A Novel Autonomic Networking Architecture. volume 3, pages 64 79, May 2007. [Strassner et al. 2009] John Strassner, Sung-Su Kim et James Won-Ki Hong. The Design of an Autonomic Communication Element to Manage The Design of an Autonomic Communication Element to Manage The Design of an Autonomic Communication Element to Manage Future Internet Services. In APNOMS, volume 5787 of Lecture Notes in Computer Science, pages 122 132. Springer, 2009. [Tadault et al. 2003] M. Tadault, S. Soormally et L. Thiébaut. Network Evolution towards IP Multimedia Subsystem. Strategy white paper, Alcatel, 2003. 48, 50, 56 [TISPAN 2006] TISPAN. ES 282 007 IP Multimedia Subsystem (IMS) ; Functional architecture NGN IMS Architecture. Rapport technique, ETSI, 2006. 52 [Tschudin et al. 2008] Christian Tschudin, Christophe Jelger et al. ANA Blueprint - final version. In Deliverable of ANA project accessible at http ://www.ana-

Bibliographie 151 project.org/web/publications/deliverables2008/start last acces 31th August, 2008. 26 [Tuffin 2009] Stephane Tuffin. Monitoring and troubleshooting VoIP. Rapport technique, France Telecom (Orange Labs), 2009. 57 [UCTIMSClient 2006] UCTIMSClient. http ://uctimsclient.berlios.de/, 2006. 107 [UIT-T 1992] UIT-T. Systems Management - Alarm Reporting Function, 1992. 35 [UMTS 2001] UMTS. Ranking of top 3G services. Rapport technique, UMTS forum, 2001. [Ungauer 1993] C. Ungauer. Problématique d utilisation de techniques de supervision à base de connaissances profondes : l exemple de la supervision du réseau TRANSPAC. Rapport technique, France Telecom, 1993. 39 [UniverSelf 2009] UniverSelf. http ://www.univerself-project.eu/, 2009. 27 [V9.0.0 2009] 3GPP TS 23.228 V9.0.0. IP Multimedia Subsystem (IMS) ; Stage 2 (Release 9). Technical specification group services and system aspects, 3rd Generation Partnership Projet, June 2009. [Venkatasubramanian et al. 2003a] Venkat Venkatasubramanian, Raghunathan Rengaswamy, Surya N. Kavuri et Kewen Yin. A review of process fault detection and diagnosis, volume 27 of Part I : Quantitative model-based methods. Elsevier Science Ltd., 2003. [Venkatasubramanian et al. 2003b] Venkat Venkatasubramanian, Raghunathan Rengaswamy, Surya N. Kavuri et Kewen Yin. A review of process fault detection and diagnosis, volume 27 of Part II : Quantitative models and search strategies. Elsevier Science Ltd., 2003. [Venkatasubramanian et al. 2003c] Venkat Venkatasubramanian, Raghunathan Rengaswamy, Surya N. Kavuri et Kewen Yin. A review of process fault detection and diagnosis, volume 27 of Part III : Process history based methods. Elsevier Science Ltd., 2003. [Yoo & Lafortune 2002] T. S. Yoo et Stéphane Lafortune. A General Architecture for Decentralized Supervisory Control of Discrete-Event Systems. Journal of Discrete Event Dynamic Systems : Theory and Applications, vol. 12(3), pages 335 377, July 2002. 95

152 Bibliographie