FR2873879A1 - Systeme de gestion de reseau de communication pour reparation automatique de pannes - Google Patents
Systeme de gestion de reseau de communication pour reparation automatique de pannes Download PDFInfo
- Publication number
- FR2873879A1 FR2873879A1 FR0408505A FR0408505A FR2873879A1 FR 2873879 A1 FR2873879 A1 FR 2873879A1 FR 0408505 A FR0408505 A FR 0408505A FR 0408505 A FR0408505 A FR 0408505A FR 2873879 A1 FR2873879 A1 FR 2873879A1
- Authority
- FR
- France
- Prior art keywords
- diagnosis
- module
- communication network
- management system
- diagnostic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 61
- 238000003745 diagnosis Methods 0.000 claims abstract description 81
- 230000008439 repair process Effects 0.000 claims abstract description 69
- 230000009471 action Effects 0.000 claims abstract description 55
- 238000007726 management method Methods 0.000 claims description 34
- 238000000034 method Methods 0.000 claims description 19
- 230000001960 triggered effect Effects 0.000 claims description 14
- 238000005457 optimization Methods 0.000 claims description 12
- 230000001131 transforming effect Effects 0.000 claims description 4
- 230000005540 biological transmission Effects 0.000 claims description 3
- 238000012545 processing Methods 0.000 claims description 2
- 208000024875 Infantile dystonia-parkinsonism Diseases 0.000 description 21
- 208000001543 infantile parkinsonism-dystonia Diseases 0.000 description 21
- 238000012360 testing method Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 238000013528 artificial neural network Methods 0.000 description 4
- 230000006399 behavior Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 201000005625 Neuroleptic malignant syndrome Diseases 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 230000007257 malfunction Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000001364 causal effect Effects 0.000 description 1
- 238000005336 cracking Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000004807 localization Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/16—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using machine learning or artificial intelligence
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Artificial Intelligence (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Databases & Information Systems (AREA)
- Evolutionary Computation (AREA)
- Medical Informatics (AREA)
- Software Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
L'invention concerne un système de gestion (NMS) d'un réseau de communication (N) comportant un module de diagnostic (MD) apte à déterminer un diagnostic (D) à partir d'informations (A) fournies par des éléments de réseau (N1, N2, N3, N4), ce diagnostic identifiant une panne au sein du réseau. Le système de gestion comporte en outre un module de réparation (MR) agencé pour déterminer une ou plusieurs actions correctives à partir au moins de ce diagnostic et pour transmettre une ou plusieurs commandes (C) correspondants aux actions correctives, à un ou plusieurs des éléments de réseau, en vue de corriger ladite panne.
Description
Système de gestion de réseau de communication pour réparation
automatique de pannes La présente invention est relative aux réseaux de communication et s'applique notamment mais non exclusivement aux réseaux de communication orientés paquets. Elle concerne plus particulièrement la gestion des réseaux de communication.
Il est connu d'associer aux réseaux de communication, des systèmes de gestion de réseau (ou NMS pour Network Management System ) dont le but est de récolter des alarmes provenant des équipements du réseau, d'en réaliser une synthèse, notamment au moyen de procédés de corrélation, et d'afficher cette synthèse ou ses alarmes à l'intention d'un opérateur afin que celui-ci puisse mettre en oeuvre une action corrective en cas de panne d'un ou plusieurs de ces équipements. La notion de panne doit être comprise dans un sens très général signifiant tout type de dysfonctionnement qu'il soit matériel ou logiciel. Ainsi, une mauvaise configuration d'un élément de réseau peut être assimilée à une panne (logicielle), de même qu'une erreur dans une table de routage d'un routeur IP ou qu'un port malencontreusement fermé.
Les systèmes de gestion de réseau peuvent également configurer les équipements de réseau. L'opérateur peut saisir de nouveaux paramètres grâce à une interface homme-machine et le système de gestion de réseau répercute ces nouveaux paramètres sur les équipements. De cette façon, l'opérateur peut corriger une panne du réseau, en réaction à l'affichage d'alarmes.
Une telle analyse centralisée repose toutefois sur la collection d'un 30 grand nombre de données d'information et d'alarmes auprès des nombreux 105480/SYC/IPD éléments du réseau de communication. Ces éléments peuvent être des équipements comme des routeurs dans le cadre d'un réseau de communication IP (Internet Protocol), mais il peut s'agir aussi de commutateurs voix, optiques, de PABX (Private Branch Exchange), de passerelles médias (Media Gateway) dans un réseau dit NGN (Next Generation Network) etc. Un élément de réseau peut aussi être une partie d'un tel équipement, comme une carte par exemple.
Du fait des nombreuses interactions entre les éléments d'un réseau, une unique panne peut générer un grand nombre d'alarmes. Ainsi, une panne sur une carte d'un équipement peut générer une alarme de la part de l'ensemble des cartes d'autres équipements, connectés à un des ports de cette carte, ainsi que par les cartes de l'équipement dans lequel la panne a eut lieu.
Aussi, il est difficile pour l'opérateur de déterminer quelle est la panne véritable à partir du grand nombre d'alarmes générées, et a fortiori de déterminer l'action corrective à entreprendre.
Un progrès a été effectué grâce aux systèmes de diagnostic qui, à partir de ce grand nombre d'alarmes, déterminent la ou les causes les plus probables.
Ces systèmes de diagnostic se basent par exemple sur des ensembles de règles, comme par exemple ceux basés sur le produit IlogRulesïM de la société Ilog. Ils peuvent aussi se baser sur des réseaux de neurones, sur des réseaux bayesiens, sur des systèmes experts ou d'autres techniques, notamment d'intelligence artificielle.
Comme autres produits, on peut citer aussi le produit Fault Detective for Data Communications (FDDC) de la société Agilent, les produits Network Note Manager et Network Node Manager Extended Topology de Hewlett-Packard, ou les produits Output Interpreter et Troubleshooting Assistant (TAC) de la société Cisco.
105480/SYC/IPD Néanmoins, ces outils nécessitent l'opérateur d'intervenir à chaque panne pour déterminer la ou les actions correctives à entreprendre et pour les déclencher. Il lui faut alors reconfigurer le réseau à travers le système de gestion de réseau ou bien se connecter manuellement sur un ou plusieurs équipements et envoyer les commandes CLI (Command Line Interface) adéquates.
Quoique aidée par les systèmes de diagnostic de l'état de l'art, cette tâche demeure difficile et donc coûteuse, et sujette à erreurs.
En effet, la phase de reconfiguration et de connexion manuelle aux équipements est longue et fastidieuse. Il est de plus facile de se tromper dans un paramètre d'une commande CLI et de provoquer ainsi une nouvelle panne du réseau.
La phase de détermination des actions correctives est aussi délicates pour l'opérateur, car s'il veut que celles-ci soient optimales, il faut qu'il prenne en compte des informations de performance du réseau ou d'autres paramètres encore.
Avec l'accroissement de la complexité des réseaux, du nombre de types d'équipements disponibles et de leur complexité, ces tâches seront de plus en plus délicates et coûteuses.
Le but de l'invention est d'automatiser la correction des pannes du réseau de communication géré.
Pour ce faire, l'invention a pour premier objet un système de gestion d'un réseau de communication comportant un module de diagnostic apte à déterminer un diagnostic à partir d'informations fournies par des éléments du réseau de communication. Ce diagnostic identifie une panne au sein du réseau de communication. Ce système de gestion se caractérise en ce qu'il comporte en outre un module de réparation agencé 105480/SYC/IPD - pour déterminer une ou plusieurs actions correctives à partir au moins du diagnostic reçu du module de diagnostic et - pour transmettre une ou plusieurs commandes correspondants à la ou aux actions correctives, à un ou plusieurs des éléments du réseau de communication, en vue de corriger la panne.
Selon des modes de réalisation de l'invention, le système de gestion peut comporter les caractéristiques suivantes, individuellement ou en combinaison: Le module de réparation est agencé pour transmettre une demande de diagnostic au module de diagnostic pour déclencher la détermination d'un nouveau diagnostic par le module de diagnostic.
- un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, et le système de gestion stoppe les modules de diagnostic et de réparation lorsque le compteur d'itération a atteint un seuil prédéterminé.
- la ou les commandes sont transmises par l'intermédiaire d'un module de médiation apte à transformer la ou les commandes formulées dans un langage générique, en des commandes spécifiques conformes à des langages de commandes propres aux différents équipements du réseau de communication.
- le module de réparation est agencé pour communiquer avec un module d'optimisation du trafic si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger le panne, ceci afin de supprimer ou limiter l'influence de cette panne sur le comportement du réseau de communication.
- le module de diagnostic met en oeuvre un réseau bayesien afin de déterminer le diagnostic.
105480/SYC/IPD le diagnostic contient au moins la désignation de le panne, la localisation de le panne, et éventuellement une estimation de la probabilité associée au diagnostic.
le module de diagnostic communique le diagnostic au module de réparation au moyen d'un message conforme au protocole SNMP.
- le module de réparation dispose d'une base de règles de réparation.
- Les règles peuvent dépendre du compteur d'itérations.
- Le module de réparation dispose d'un historique des diagnostics et des actions correctives déterminées à chaque itération et est apte à revenir à l'état du réseau de communication pour une itération donnée, si lorsque le seuil est atteint, le diagnostic est moins bon que ce qu'il était pour cette itération donnée.
L'invention a par ailleurs pour second objet un procédé de gestion d'un réseau de communication comportant une première étape de détermination d'un diagnostic à partir d'informations fournies par des éléments du réseau de communication. Ce procédé se caractérise en ce qu'il comporte en outre une seconde étape de détermination, si le diagnostic identifie une panne, d'une ou de plusieurs actions correctives à partir au moins du diagnostic et de transmission d'une ou de plusieurs commandes (C) correspondants à cette ou ces actions correctives, à un ou plusieurs des éléments du réseau de communication, en vue de corriger la panne.
Selon des modes de réalisation de l'invention, le procédé de gestion peut comporter les caractéristiques suivantes, individuellement ou en combinaison: - La première étape est automatiquement déclenchée à l'issue de la seconde étape, afin de former un cycle de traitement.
105480/SYC/IPD - un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, le cycle de traitement s'interrompant lorsque ce compteur d'itération a atteint un seuil prédéterminé.
- la ou les commandes sont transmises par l'intermédiaire d'un module de médiation apte à transformer la ou les commandes formulées dans un langage générique, en des commandes spécifiques conformes à des langages de commandes propres aux différents équipements du réseau de communication.
- une commande peut être transmise à un module d'optimisation du trafic si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger la panne, afin de supprimer ou limiter l'influence de cette panne sur le comportement du réseau de communication.
- la première étape met en oeuvre un réseau bayesien afin de déterminer le diagnostic.
- le diagnostic contient au moins la désignation de la panne, la localisation de la panne, et éventuellement une estimation de la probabilité associée au diagnostic.
un historique des diagnostics et des actions correctives déterminées à chaque itération est constitué et si lorsque le seuil est atteint le diagnostic est moins bon que ce qu'il était pour une itération antérieure, on revient à l'état du réseau de communication pour cette itération antérieure.
Ainsi, selon l'invention, le module de réparation permet de réparer automatiquement (ou semi-automatiquement, après validation de l'opérateur) les pannes du réseau de communication et/ou d'entreprendre des actions correctives limitant les conséquences des pannes, et notamment leurs impacts sur les SLA (Service Level Agreements) déployés sur le réseau de communication.
105480/SYC/IPD Après correction, un nouveau diagnostic est demandé au module de diagnostic afin de s'assurer que cette réparation n'a pas engendré de nouvelle panne, et si oui, de les corriger à leur tour. Un cycle de traitement peut ainsi être mis en oeuvre qui doit converger vers la réparation de la panne diagnostiquée.
Afin d'éviter des boucles de réparation trop longues, un seuil peut être fixé pour le nombre d'itérations de la boucle.
L'invention, ses caractéristiques et ses avantages apparaîtront de 10 façon plus claire dans la description qui va suivre en liaison avec les figures annexées.
La figure 1 schématise le système de gestion selon l'invention.
La figure 2 représente une architecture interne du module de réparation selon une mise en oeuvre de l'invention.
La figure 3 illustre l'enchaînement des étapes du procédé selon l'invention.
Ces dessins annexés pourront non seulement servir à compléter l'invention, sans que celle-ci y soit limitée, mais aussi contribuer le cas échéant 20 à sa définition.
Selon l'invention, le système de gestion de réseau comporte deux modules principaux qui sont d'une part un module de diagnostic MD et d'autre part un module de réparation MR.
Le module de diagnostic reçoit en entrée des plaintes des clients CC et des informations du réseau A. Les plaintes du client peuvent être provoquées par une baisse des performances du réseau ou des services mis en oeuvre sur le réseau. À la réception d'une telle plainte, le système de diagnostic MD peut déclencher une recherche de diagnostic afin de 105480/SYC/IPD déterminer la cause technique ayant amenée cette plainte. II peut alors tirer profit des informations issues des éléments du réseau.
Une recherche de diagnostic peut aussi être déclenché par ces informations issues des éléments du réseau de communication elles-mêmes (c'est-à-dire indépendamment de la présence d'une plainte de client).
Les informations A issues des éléments du réseau peuvent être principalement de deux natures: É Il peut s'agir d'alarmes, c'est-à-dire de notifications asynchrones transmises par les éléments du réseau vers le système de gestion de réseau. Ces alarmes sont transmises lorsqu'une anomalie est détectée par l'élément, lorsqu'une valeur mesurée atteint un seuil prédéterminé ou, d'une façon plus générale, lors de n'importe quel type d'événement dont on a prévu, par configuration, que l'apparition devait déclencher une alarme. Ces alarmes peuvent donc indiquer une panne, que celle-ci soit logicielle ou matérielle.
É Il peut aussi s'agir de données de configuration ou de performances, qui ne sont pas notifiées au système de gestion de réseau NMS, mais que celui-ci doit aller chercher dans une base d'information de gestion (MIB pour Management Information Base, en anglais).
É II peut aussi s'agir de la mise en place de tests actifs, de mesures actives ou passives, et notamment de mesures de bout en bout.
Notamment à la réception d'alarmes, le module de diagnostic MD 25 peut déterminer que celles-ci représentent une panne ou une panne probable.
À la suite d'une telle détermination, il déclenche alors la détermination du diagnostic, c'est-à-dire la recherche de la panne.
Comme on a dit précédemment, lorsqu'une panne a lieu, elle peut provoquer des alarmes provenant non seulement de l'élément de réseau en panne, mais aussi d'éléments de réseau voisins . La détermination du 105480/SYC/IPD diagnostic consiste justement à identifier l'élément de réseau en panne (c'est la localisation de la panne), ainsi que le type de panne (l'intitulé de la panne), à partir de cet ensemble d'alarmes provenant d'une multitude d'éléments de réseau. Généralement, le diagnostic ne peut être certain, et le module de diagnostic MD fournira alors le diagnostic D le plus probable en y associant une valeur de probabilité. Il peut aussi fournir une liste de plusieurs diagnostics, chacun étant associé à une valeur de probabilité, et chacun identifiant une panne au sein du réseau de communication N. Le module de diagnostic peut être un module connu de l'état de l'art. Comme décrit précédemment, les technologies mises en oeuvre peuvent être diverses: réseaux de neurones, systèmes experts, systèmes à base de règles etc. II peut s'agir des produits commerciaux précédemment évoqués.
Le module de diagnostic MD doit préférentiellement toutefois respecter deux critères: É Il doit être proactif , c'est-à-dire que la recherche de diagnostic peut être déclenchée autrement que par la réception d'alarmes A du réseau de communications. Notamment, cette recherche doit pouvoir être déclenchée par un événement extérieur qui peut être soit une plainte client CC, soit une demande de diagnostic (CD), transmise par le module de réparation MR et qui sera explicité ultérieurement.
É Il doit pouvoir fournir le diagnostic le plus probable et si possible y attacher une probabilité.
Préférentiellement, ce module de diagnostic met en oeuvre des réseaux bayésiens et est similaire au produit 5530 Network Analyzer de la société Alcatel. Le fonctionnement d'une mise en oeuvre de ce module est par conséquent décrit dans la document technique du produit 5530 . La technologie des réseaux bayésiens et son application à la détermination de 105480/SYC/IPD diagnostics sont par exemple décrits dans l'ouvrage An introduction to Bayesian Networks de F. Jensen, UCL Press, 1996 ou dans l'article IP VPN Network Diagnosis: Technologies and Perspectives de Gérard Delègue, Stéphane Betgé-Brezetz, Emmanuel Marilly et Olivier Martinot, 3rd International Conference on Networking, Mars 2004.
Le principe des réseaux bayesiens utilise la théorie des probabilités qui définit une règle pour raffiner une hypothèse en prenant en compte des éléments de preuve additionnels et des informations d'arrière-plan et ainsi conduire à un nombre représentant le degré de probabilité que l'hypothèse soit vraie.
Un diagramme bayesien définit donc toutes les actions de test à entreprendre, associées à une probabilité et à un coût, le coût servant par exemple pour définir quels tests demandent plus de temps que les autres.
La figure 3 illustre un exemple extrêmement simplifié de diagramme bayesien. Il montre que l'entité LossPacket (perte de paquets) dépend de plusieurs autres entités, HighCPUUtilization (haut taux d'utilisation du CPU), InterfacelNStatus (Statut de l'interface entrante), InterfaceOutStatus (Statut de l'interface sortante). Ce modèle permet donc au système d'une part de représenter les chaînes de causalité et donc de lui indiquer les tests à effectuer, et d'autre part de calculer une valeur de probabilité pour chaque diagnostic possible et de déterminer un diagnostic le plus probable.
Dans la pratique, les diagrammes bayesiens sont bien évidemment 25 plus complexes et peuvent comporter plusieurs niveaux hiérarchiques. De plus, il faut de nombreux diagrammes pour modéliser un élément de réseau.
Une fois un diagnostic D déterminé, celui-ci est transmis au module de réparation MR, sous la forme d'un ou de plusieurs message. Ces messages 30 sont par exemple conformes au protocole SNMP (Simple Network 105480/SYC/IPD Management Protocol) défini par I'IETF (Internet Engineering Task Force) dans les RFC 1 157 et 1592 pour les versions 1 et 2 respectivement.
Il peut s'agir d'un unique message (ou trop ) SNMP ou de plusieurs messages. Dans ce dernier cas, les messages doivent être clairement identifiés pour que le module de réparation MR puisse aisément déterminer qu'ils sont relatifs à un même diagnostic D. Selon un mode de réalisation, le premier message contient les informations générales sur le diagnostic, tandis que le ou les messages suivants contiennent des informations de détails. Si, par exemple, le diagnostic concerne un LSP (Label Switching Point), le premier message peut contenir les informations de diagnostic relatives au LSP lui-même, tandis que les messages subséquents contiennent des informations relatives aux équipements (ou routeurs) traversés par le LSP.
Cette détermination peut être réalisée au moyen du ticket qui sera explicité plus bas: tous les messages SNMP transportant un même diagnostic 15 D auront le même ticket.
Toutefois, d'autres mises en oeuvre sont possibles, notamment les deux modules peuvent communiquer via un bus logiciel de type CORBA (Common Object Request Broker Architecture) tel que défini par l'OMG (Open Management Group) ou COM/DCOM de la société Microsoft.
Ce message D doit contenir préférentiellement les informations suivantes: É l'intitulé de la panne diagnostiqué. Par exemple, Interface hors service , mauvaise configuration de BGP (Border Gateway Protocol) etc. É la localisation de la panne, c'est-à-dire un identificateur de l'élément de réseau, de la carte, de l'interface, du réseau virtuel (VPN pour Virtual Private Network en anglais) etc. concerné.
É Une valeur de probabilité, qui détermine à quel niveau de confiance on doit considérer le diagnostic établi.
105480/SYC/IPD É Un ticket, c'est-à-dire un numéro qui identifie une session de recherche du bon diagnostic pour un problème donné). Comme dit précédemment, si un même diagnostic est transporté par plusieurs messages, notamment parce que le volume d'information est trop important, chacun de ces messages aura le même ticket.
É Un numéro d'itération qui identifie le nombre d'occurrence d'une recherche de diagnostic pour un ticket donné. On verra ultérieurement qu'un problème peut engendrer une boucle entre le module de diagnostic MD et le module de réparation MR, de sorte que plusieurs itérations peuvent être nécessaires pour aboutir à la résolution du problème.
Dans le cas d'une mise en oeuvre basée sur le protocole SNMP, la 15 table suivante donne un exemple d'un trap SNMP : Nom du champ Description OID (SNMP object ASN Applic de la trop identifier) 1 ation SNMP Type format Type de Panne Description de l'alarme 1.3.6.1.4. 1.637.4.1 String String
SNMP; Description de la
panne pour laquelle la "trop" SNMP a été générée.
Localisation VPN ID 1.3.6.1.4.1.637.4.2.1 String String LSP LSP ID; identificateur du LSP 1.3.6.1.4.1.637.4.2.2 String Int Router Router ID; Adresse IP du 1.3.6.1.4.1.637.4.2.3 String String routeur Interface Interface index. 1.3.6.1.4.1.637.4.2.4 String Int SNMP Interface index Ticket Ticket ID; Ticket unique 1.3.6.1.4.1.637.4. 3 String Int identifiant la panne.
Reliability Probabilité du diagnostic. 1.3.6.1.4.1.637.4.4 String Float Iteration Itération dans la boucle de 1.3.6.1.4.1.637.4.5 String Int diagnostic.
Diagnostics Description du scénario de 1.3.6.1.4.1.637.1.6 String String scenario diagnostic.
105480/SYC/I PD Ces OlDs (SNMP Object IDentifiers) se décomposent en trois parties: La partie gauche (1.3.6.1.4.1.637.) correspond à l'identifiant Alcatel, la partie suivante (4.) correspond à l'application (i.e. le module de diagnostic MD) et la dernière partie correspond aux attributs propres aux champs du trop SNMP .
À la réception d'un message contenant un diagnostic D, le module de réparation D va chercher à déterminer une ou plusieurs actions correctives.
La figure 2 représente une architecture fonctionnelle possible du module de réparation MR. Cette architecture étant fonctionnelle, elle peut donner lieu à différentes réalisations. Selon cette mise en oeuvre, le module de réparation MR comporte un module principal MP, une interface homme-machine IHM, une base de données B et un module de configuration MC.
Les diagnostics D sont reçus par le module principal MP, dont le but est de déterminer les actions correctives et de transmettre les commandes correspondant à ces actions correctives soit vers un module de médiation MED, soit directement vers les éléments du réseau, non représentés sur la figure.
Cette détermination est donc réalisée à partir du diagnostic D et des informations qu'il comporte et que nous avons vu précédemment. Il peut toutefois aussi dépendre d'autres informations telles - une logique interne, c'est-à-dire une formalisation dans un langage particulier, de la politique qui permet de déterminer une action corrective à partir d'au moins un diagnostic. Cette logique interne est mémorisée dans une base de données B. - des paramètres déterminés par l'utilisateur, notamment au moyen de l'interface IHM et du module de configuration MC 105480/SYC/IPD 30 et mémorisés dans la base de données B (ou éventuellement dans une autre base de données distincte).
- Des informations transmises par l'utilisateur par l'interface IHM, durant l'élaboration du diagnostic, notamment en réponse à une proposition effectuée par le module principal MP.
Selon un mode de réalisation préférentiel de l'invention, la logique interne est formalisée sous la forme d'un ensemble de règles.
Ces règles permettent d'associer les diagnostics C qui peuvent être reçus du module de diagnostic MD à des actions correctives. Elles peuvent être entrées dans la base B par l'intermédiaire du module de configuration MC et de l'interface IHM.
Ces règles peuvent typiquement s'exprimer sous la forme: SI prémisses ALORS actions dans laquelle prémisses est une liste de conditions qui doivent être remplies pour que la ou les actions soient déclenchées. Cette liste peut contenir plusieurs conditions liées entre elles de façon conjonctives (par l'opérateur logique ET) ou disjonctives (par l'opérateur logique OU).
De telles règles peuvent par exemple être: o If (Router=Alcatel/192.128. 12.52, Interface= FastEthernetl /0) && ((Iteration=1)<3) && (Failure = INTERFACE_DOWN) Then (Execute Corrective Action 2).
o If (Router=Alcatel/192.128.12.52, Interface= FastEthernetl /0) && ((Iteration=1)<3) && (Failure BGP MISCONFIGURATION) Then (Execute Corrective Action 3).
o (Corrective Action 2) = Put (Router=Cisco/192.128.12.52, Interface=FastEthernetl/0) Interface Up.
105480/SYC/IPD o (Corrective Action 3) = Configure (Router=Alcatel/192.128.12.52, Interface= FastEthernetl /0) With BGP Configuration_Script_1 Dans le formalisme de ces règles, ou bien dans des paramètres associées à ces règles, on peut associer un indicateur pour préciser si les actions correctives peuvent être directement transmises aux éléments du réseau de communication, éventuellement au travers du module de médiation MED, ou si une validation de l'opérateur est nécessaire. Dans ce dernier cas, les actions correctives sont transmises à l'interface homme-machine IHM pour affichage sur un écran. Ces indicateurs peuvent être mémorisés dans la base B grâce au module de configuration MC, accessible par l'opérateur au travers de l'interface homme-machine IHM.
Outre ces actions correctives, d'autres informations peuvent être affichées afin d'aider l'opérateur dans sa décision, notamment les informations relatives au diagnostic D transmises par le module de diagnostic MD.
L'opérateur peut alors valider la proposition du module de réparation MR avant que celui-ci ne transmette les commandes C vers les éléments de 20 réseau.
Dans la situation où plusieurs actions correctives sont possibles, l'interface IHM peut les afficher sur l'écran et permettre à l'utilisateur de choisir celle qui lui semble la plus appropriée. Le module de réparation MR transmettra alors vers les éléments du réseau de communication, les commandes C correspondant aux actions correctives choisies par l'opérateur.
Outre la mise en oeuvre préférentielle à base de règles, d'autres mises en oeuvre sont également possibles.
On peut par exemple utiliser des réseaux bayésiens ou bien des 30 réseaux neuronaux. L'avantage de l'utilisation des réseaux de neurones est 105480/SYC/IPD leur faculté d'apprentissage et de fonctionnement dans l'incertain. Par exemple, ils peuvent être capables d'appliquer l'action corrective la plus probable à la panne la plus probable, même si un certain nombre d'informations sont manquantes. Toutefois, à la date de dépôt de la présente demande, le problème est la difficulté d'appréhension d'une telle technologie par les opérateurs des réseaux de communication.
Comme évoqué précédemment, les commandes C peuvent être transmises vers les éléments du réseau de communication N, par l'intermédiaire d'un module de médiation MED. Le but de ce module de médiation est de transformer des commandes C formulées dans un langage générique par le module de réparation MR, en des commandes spécifiques C1, C2 conformes en des langages de commandes propres aux différents équipements du réseau de communication.
Ainsi, sur la figure 1, les équipements N1 et N2 peuvent être de type différent, par exemple un routeur IP et une passerelle média (Media gateway) permettant de relier ce réseau de communication N à un autre réseau, non représenté. Il peut aussi s'agir d'équipements de types similaires mais fabriqués par des fournisseurs différents. Dans ces deux situations, les commandes à utiliser pour les configurer doivent être adaptées au langage de commandes compris par l'équipement. Une même commande C générique (par exemple, ouvrir une interface ) donnera donc lieu à des commandes spécifiques différentes pour les deux équipements N1et N2, chacune de ces commandes spécifiques étant conforme au langage propre des équipements, et notamment de leur interface CLI (Command Line Interface).
Différents produits et technologies peuvent être utilisés pour réaliser ce module de médiation MED.
Une architecture de gestion à base de règles de politique (PBM pour 30 Policy-based Management en langue anglaise) peut notamment être 105480/SYC/IPD utilisée. Les demandes de brevet EP1335524 intitulée Déploiement des règles par une dispositif de gestion de services, en fonction d'informations sur les équipements du réseau ou EP1387526 intitulée Système de gestion de réseau par règles comportant un moteur d'inférence par exemples, décrivent de telles architectures.
Ainsi, par la détermination des actions correctives, le module de réparation MR selon l'invention permet d'automatiser la réparation du réseau de communication ou de le semi-automatiser dans le cas où une intervention de l'opérateur est demandée.
Toutefois, la complexité des réseaux de communication est telle qu'il est pratiquement impossible de maîtriser complètement l'impact des actions correctives. D'une part, la réparation peut s'avérer inefficace pour résoudre le problème (par exemple, parce que le diagnostic n'était pas bon, mais aussi parce que les actions correctrices n'étaient pas entièrement adaptées), et d'autre part, il est aussi possible que la réparation réelle de la panne puisse engendrer une nouvelle panne. Par exemple, en réparant une première panne, on permet la transmission de trafic vers des éléments de réseau qui jusqu'alors étaient isolés, et ce faisant, on peut mettre en évidence une panne parmi ces éléments de réseau.
La demanderesse a donc considéré le problème technique additionnel de minimiser les impacts insuffisants ou non désirés sur le réseau de communication. Pour ce faire, après transmission des commandes C vers les éléments du réseau de communication, une demande de diagnostic CD est transmise au module de diagnostic MD, afin que celui-ci détermine un nouveau diagnostic.
Cette demande de diagnostic CD peut contenir la valeur du ticket, afin que ce nouveau diagnostic (ainsi que les éventuels suivants) soit lié au premier diagnostic au sein d'une session déterminée par un même ticket.
105480/SYC/IPD Grâce à ce re-bouclage vers le module de diagnostic MD, celui-ci peut vérifier la correction de la panne et détecter l'apparition d'une nouvelle panne. II pourra alors déclencher une nouvelle réparation par le module de réparation MR, et ainsi de suite. Ce mode de réalisation préférentiel de l'invention permet donc de réaliser une boucle de contrôle des actions faites sur le réseau de communication géré.
Toutefois ce mode de réalisation peut poser le problème additionnel de provoquer des boucles infinies, c'est-à-dire que chaque réparation 10 engendre une nouvelle panne de façon cyclique.
Afin d'éviter ces boucles infinies, un compteur d'itération peut être mis en oeuvre. Par exemple, ce compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic. Lorsque ce compteur d'itération atteint un certain seuil, prédéfini, la boucle est stoppée et le système peut indiquer à l'opérateur grâce à l'interface IHM qu'aucune solution n'a été trouvée.
De façon équivalent pour l'homme du métier, le compteur peut être initialisé à la valeur de ce seuil et décrémenté à chaque déclenchement de nouveau diagnostic. Le critère d'arrêt est alors le passage à 0 de ce compteur d'itération.
Selon un mode de réalisation de l'invention, ce compteur d'itération peut influer sur la logique interne du module de réparation. Par exemple, dans la situation où cette logique interne est implémentée sous la forme d'un ensemble de règles, ces règles peuvent dépendre de la valeur du compteur d'itération.
L'opérateur peut configurer ces dépendances en fonction des contraintes qu'il se fixe. Par exemple, sur un LSP sans importance, l'opérateur peut y associer un seuil d'itération élevé (notamment car le coût résultant est moindre que le déclenchement du module d'optimisation du trafic, dont nous 105480/SYC/IPD verrons le fonctionnement ultérieurement). Pour un LSP très important avec un SLA comportant des fortes pénalités, le seuil d'itération peut être très faible et l'opérateur souhaite avant tout maintenir le service même s'il faut déclencher le module d'optimisation du trafic.
Éventuellement, si in fine, les diagnostics relèvent des problèmes plus graves sur le réseau de communication que ce qu'ils étaient à un moment donné, un mécanisme de retour arrière (bock Cracking) peut être mis en oeuvre pour revenir à cette configuration du réseau. Pour ce faire, le module de réparation contient un historique des actions correctives et/ou des commandes émises et des diagnostics reçus. Si lorsque le seuil est atteint, le nouveau diagnostic est moins bon que ce qu'il était pour une itération antérieure, alors le module de réparation peut utiliser cet historique pour faire revenir le réseau dans l'état correspond à cette itération. Il suffit de transmettre alors les commandes inverses pour rétablir cette situation antérieure.
À défaut de résoudre véritablement la panne, cette mise en oeuvre permet un compromis en améliorant l'état du réseau.
À l'issue d'un tel retour arrière, un message est envoyé à l'opérateur via l'interface homme-machine IHM pour lui indiquer que le problème n'a pas 20 pu être résolu et la situation du réseau.
Selon un autre mode de réalisation, si un problème ne peut être résolu par le module de diagnostic, un module d'optimisation du trafic TE (ou Traffic Engineering, en langue anglaise) peut être utilisé. Le but de ce module d'optimisation du trafic est de rediriger le trafic afin qu'il évite le problème, plutôt que de résoudre véritablement le problème. Ainsi, si un problème au sein d'un routeur ne peut être résolu (un problème matériel, par exemple), le module TE peut modifier les tables de routage des autres routeurs, les LSP passant par ce routeur, etc. afin que plus aucun trafic ne soit dirigé vers ce 105480/SYC/IPD routeur. Ainsi, même si l'équipement en question demeure inopérant, le comportement du réseau peut devenir totalement opérationnel.
Pour résumer, un diagnostic identifiant une panne peut aboutir à 4 conclusions: soit il a réparation, soit il n'y a pas réparation et l'opérateur est averti, soit il n'y a pas réparation mais déclenchement de l'outil d'optimisation du trafic, soit le module de réparation MR place le réseau dans l'état le moins mauvais en utilisant la fonction de retour-arrière et prévient l'opérateur.
La figure 3 schématise le déroulement des étapes du procédé selon l'invention.
Une première étape Diag consiste à déclencher la détermination d'un diagnostic. Cette étape est déclenchée, typiquement, à la suite de la réception d'une alarme du réseau de communication ou d'une plainte d'un client.
Puis, le système détermine si le diagnostic identifie une panne (case P ? ). S'il n'y a pas de panne, le procédé s'arrête (case F1 ) S'il y a une panne, le procédé consiste à déterminer certains critères d'arrêts ( Stop ? ). II s'agit de déterminer si le nombre d'itération a atteint le seuil prédéfini, ou bien si le diagnostic correspond à un diagnostic déjà établi lors d'une itération antérieure. Si ces critères d'arrêts sont remplis, le système s'arrête (case F2 ).
Si non, le procédé met en oeuvre une étape Rep consistant à 25 déterminer des actions correctives et à déployer des commandes associées à ces actions correctives vers le réseau de communication.
Puis, selon une mise en oeuvre préférentielle de l'invention, une nouvelle étape de diagnostic Diag est déclenchée et le procédé repasse alors par les différentes étapes et tests décrits ci-dessus.
105480/SYC/IPD Le procédé forme alors un cycle de traitement, dont la résolution de la panne et la rencontre des critères d'arrêts lors des tests P ? et Stop ? , respectivement, permettent de sortir.
L'invention et l'enchaînement de ses différentes étapes peuvent être rendus plus clairs au travers des 3 exemples de cas concrets suivants.
Dans chacun de ces exemples le module de diagnostic est mis en fonctionnement par la réception d'alarmes du réseau de communication ou par une plainte d'un client.
Dans un premier exemple, une plainte d'un client CC ou des alarmes A reçues du réseau de communication ont mis en évidence un problème au sein de ce réseau. Un premier diagnostic révèle que l'interface X d'un routeur Y est hors service ( down en anglais). Le module de diagnostic MD transmet ce diagnostic au module de réparation, avec une valeur de ticket et une valeur d'itération de 1.
Le module de réparation MR détermine alors l'action corrective associée à ce diagnostic. L'action corrective est, dans cet exemple, de remettre l'interface X en service ( up en anglais). Une commande générique associée à cette action corrective est transmise au module de médiation MED, qui détermine la commande appropriée dans le langage propre au routeur Y. Le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, en précisant la même valeur de ticket.
Le module de diagnostic MD refait un diagnostic du réseau de communication et détermine que l'interface X du routeur Y est effectivement opérationnelle ( up ) et que le réseau fonctionne normalement. II peut alors transmettre un diagnostic D au module de réparation pour signaler que le réseau fonctionne normalement. À la suite de quoi, le problème étant résolu, le module de réparation MR ne déclenche aucune action et le procédé de l'invention se termine.
105480/SYC/IPD Dans un deuxième exemple, le module de diagnostic détermine aussi que l'interface X du routeur Y est hors service ( down ) . De la même façon que dans le premier exemple, le diagnostic D est transmit au module de réparation avec un ticket, et le module de réparation MR détermine une action corrective. La commande générique associée à cette action corrective est transmise au module de médiation MED qui la convertit en une commande conforme au langage spécifique du routeur Y. Le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, avec le même ticket. Le module de diagnostic MD déclenche une nouvelle détermination de diagnostic. Le nouveau diagnostic D relève que l'interface X du routeur Y est toujours hors-service ( down ). Ce diagnostic D est transmis au module de réparation MR avec le même ticket, et une valeur d'itération égale à 2.
Le module de réparation MR peut constater que bien que l'itération soit égale à 2, le problème demeure le même. Il peut alors décider de transmettre une commande au module d'optimisation du trafic TE (Traffic Engineering).
Ce module d'optimisation du trafic TE peut alors modifier les chemins en place dans le réseau de communication afin que ceux-ci évite l'interface X du routeur Y. De cette façon, bien que l'interface en question soit hors-service, le réseau de communication pourra se comporter normalement.
Dans un troisième exemple, le module de diagnostic MD détermine également que l'interface X du routeur Y est hors-service ( down ). Le diagnostic D est transmit au module de réparation avec un numéro de ticket et une valeur d'itération égale à 1.
Comme précédemment, le module de réparation détermine la commande générique à transmettre au module de médiation MED qui la 105480/SYC/I PD convertit en une commande conforme au langage propre au routeur Y afin de mettre l'interface X en service ( up ).
Le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, avec le même numéro de ticket.
Le module de diagnostic déclenche alors une nouvelle détermination de diagnostic et il en ressort un nouveau problème, par exemple une mauvaise configuration du protocole de routage BGP (Border Gateway Protocol). Ce diagnostic D est transmis au module de réparation avec un numéro d'itération égal à 2 et la même valeur de ticket.
Le module de réparation MR détermine alors les actions correctives adéquates, qui peuvent être ici de reconfigurer le protocole BGP. Des commandes génériques sont alors transmises au module de médiation MED qui les convertit en des commandes spécifiques.
Une nouvelle fois, le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, en précisant le même numéro de ticket. II ressort du nouveau diagnostic D que la même interface X du routeur Y est hors-service ( clown ). Ce diagnostic D est transmis au module de réparation MR avec une valeur d'itération égale à 3 et toujours la même valeur de ticket.
Le module de réparation peut constater que la valeur d'itération est égale à 3 et que le diagnostic est le même que celui de l'itération 1. Il peut alors déterminer qu'il est incapable de résoudre le problème et transmettre à l'interface homme-machine IHM une commande provoquant l'affichage d'un message exprimant cette incapacité ainsi que des informations relatives au diagnostic.
On voit au travers de ces exemples, les différents modes de fonctionnement de l'invention, et notamment que par la configuration de la base de règles B, le module de réparation MR de l'invention peut adopter 105480/SYC/IPD différents comportements, comme avertir l'opérateur, déclencher un module d'optimisation du trafic, déclencher des commandes de réparation etc. 105480/SYC/IPD
Claims (19)
1) Système de gestion (NMS) d'un réseau de communication (N) comportant un module de diagnostic (MD) apte à déterminer un diagnostic (D) à partir d'informations (A) fournies par des éléments (N,, N2, N3, N4) dudit réseau de communication, ledit diagnostic identifiant une panne au sein dudit réseau de communication, ledit système étant caractérisé en ce qu'il comporte en outre un module de réparation (MR) agencé pour déterminer une ou plusieurs actions correctives à partir au moins dudit diagnostic reçu dudit module de diagnostic (MD) et pour transmettre une ou plusieurs commandes (C) correspondants à ladite ou auxdites actions correctives, à un ou plusieurs des éléments dudit réseau de communication, en vue de corriger ladite panne.
2) Système de gestion selon la revendication précédente, dans lequel ledit module de réparation (MR) est agencé pour transmettre une demande de diagnostic (CD) au module de diagnostic (MD) pour déclencher la détermination d'un nouveau diagnostic par ledit module de diagnostic.
3) Système de gestion selon la revendication précédente, dans lequel un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, ledit système de gestion stoppant les modules de diagnostic et de réparation lorsque ledit compteur d'itération a atteint un seuil prédéterminé.
4) Système de gestion selon l'une des revendications précédentes, dans lequel la ou les commandes sont transmises par l'intermédiaire d'un module de médiation (MED) apte à transformer la ou lesdites commandes 105480/SYC/IPD formulées dans un langage générique, en des commandes spécifiques (C,, C2) conformes à des langages de commandes propres aux différents équipements dudit réseau de communication.
5) Système de gestion selon l'une des revendications 3 ou 4, dans lequel le module de réparation (MR) dispose d'un historique des diagnostics et des actions correctives déterminées à chaque itération et est apte à revenir à l'état du réseau de communication pour une itération donnée, si lorsque ledit seuil est atteint, le diagnostic est moins bon que ce qu'il était pour ladite itération donnée.
6) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de réparation est en outre agencé pour communiquer avec un module d'optimisation du trafic (TE) si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger ladite panne, afin de supprimer ou limiter l'influence de ladite panne sur le comportement dudit réseau de communication.
7) Système de gestion selon l'une des revendications précédentes, 20 dans lequel ledit module de diagnostic (MD) met en oeuvre un réseau bayesien afin de déterminer ledit diagnostic.
8) Système de gestion selon l'une des revendications précédentes, dans lequel ledit diagnostic (D) contient au moins la désignation de ladite panne, la localisation de ladite panne, et éventuellement une estimation de la probabilité associée audit diagnostic.
9) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de diagnostic communique ledit diagnostic audit 30 module de réparation au moyen d'un message conforme au protocole SNMP.
105480/SYC/IPD
10) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de réparation dispose d'une base de règles de réparation.
11) Système de gestion selon la revendication précédente et la revendication 3, dans lequel lesdites règles peuvent dépendre dudit compteur d'itérations.
12) Procédé de gestion d'un réseau de communication (N) comportant une première étape de détermination d'un diagnostic (D) à partir d'informations (A) fournies par des éléments (N N2, N3, N4) dudit réseau de communication, caractérisé en ce qu'il comporte en outre une seconde étape de détermination, si ledit diagnostic identifie une panne, d'une ou de plusieurs actions correctives à partir au moins dudit diagnostic et de transmission d'une ou de plusieurs commandes (C) correspondants à cette ou ces actions correctives, à un ou plusieurs des éléments dudit réseau de communication, en vue de corriger ladite panne.
13) Procédé de gestion selon la revendication précédente, dans lequel ladite première étape est automatiquement déclenchée à l'issue de ladite seconde étape, afin de former un cycle de traitement.
14) Procédé selon la revendication précédente, dans lequel un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, ledit cycle de traitement s'interrompant lorsque ledit compteur d'itération a atteint un seuil prédéterminé.
15) Procédé selon la revendication précédente, dans lequel un 30 historique des diagnostics et des actions correctives déterminées à chaque 105480/SYC/IPD itération est constitué et dans lequel si lorsque ledit seuil est atteint, le diagnostic est moins bon que ce qu'il était pour une itération antérieure, on revient à l'état du réseau de communication pour cette itération antérieure.
16) Procédé selon l'une des revendications précédentes, dans lequel la ou les commandes sont transmises par l'intermédiaire d'un module de médiation (MED) apte à transformer la ou lesdites commandes formulées dans un langage générique, en des commandes spécifiques conformes à des langages de commandes propres aux différents équipements dudit réseau de communication.
17) Procédé selon l'une des revendications précédentes, dans lequel une commande peut être transmise à un module d'optimisation du trafic (TE) si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger ladite panne, afin de supprimer ou limiter l'influence de ladite panne sur le comportement dudit réseau de communication.
18) Procédé selon l'une des revendications précédentes, dans lequel ladite première étape met en oeuvre un réseau bayesien afin de déterminer 20 ledit diagnostic.
19) Procédé selon l'une des revendications précédentes, dans lequel ledit diagnostic (D) contient au moins la désignation de ladite panne, la localisation de ladite panne, et éventuellement une estimation de la probabilité associée audit diagnostic.
105480/SYC/IPD
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0408505A FR2873879B1 (fr) | 2004-07-30 | 2004-07-30 | Systeme de gestion de reseau de communication pour reparation automatique de pannes |
| PCT/FR2005/050530 WO2006021702A1 (fr) | 2004-07-30 | 2005-07-01 | Systeme de gestion de reseau de communication pour reparation automatique de pannes |
| EP05787400A EP1774705A1 (fr) | 2004-07-30 | 2005-07-01 | Systeme de gestion de reseau de communication pour reparation automatique de pannes |
| JP2007523126A JP2008508760A (ja) | 2004-07-30 | 2005-07-01 | 自動障害修復のための通信ネットワーク管理システム |
| US11/572,904 US8149718B2 (en) | 2004-07-30 | 2005-07-01 | Communication network management system for automatic repair of failures |
| CNA2005800323261A CN101027872A (zh) | 2004-07-30 | 2005-07-01 | 用于自动故障修复的通信网络管理系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0408505A FR2873879B1 (fr) | 2004-07-30 | 2004-07-30 | Systeme de gestion de reseau de communication pour reparation automatique de pannes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2873879A1 true FR2873879A1 (fr) | 2006-02-03 |
| FR2873879B1 FR2873879B1 (fr) | 2006-10-27 |
Family
ID=34947039
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0408505A Expired - Fee Related FR2873879B1 (fr) | 2004-07-30 | 2004-07-30 | Systeme de gestion de reseau de communication pour reparation automatique de pannes |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US8149718B2 (fr) |
| EP (1) | EP1774705A1 (fr) |
| JP (1) | JP2008508760A (fr) |
| CN (1) | CN101027872A (fr) |
| FR (1) | FR2873879B1 (fr) |
| WO (1) | WO2006021702A1 (fr) |
Families Citing this family (48)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7536595B1 (en) * | 2005-10-19 | 2009-05-19 | At&T Intellectual Property, Ii, L.P. | Systems, devices, and methods for initiating recovery |
| JP2007128437A (ja) * | 2005-11-07 | 2007-05-24 | Hitachi Ltd | ディスクアレイ装置及びその経路障害検出方法 |
| US20070106784A1 (en) * | 2005-11-08 | 2007-05-10 | Dickman David T | Systems, methods and apparatus to identify network maintenance zones |
| JP4701148B2 (ja) * | 2006-03-02 | 2011-06-15 | アラクサラネットワークス株式会社 | 障害回復システム及びサーバ |
| US7788544B2 (en) * | 2006-05-03 | 2010-08-31 | Computer Associates Think, Inc. | Autonomous system state tolerance adjustment for autonomous management systems |
| US8213321B2 (en) * | 2007-02-01 | 2012-07-03 | Deere & Company | Controller area network condition monitoring and bus health on in-vehicle communications networks |
| US8839325B2 (en) * | 2007-02-14 | 2014-09-16 | At&T Intellectual Property I, L.P. | System and method of managing video content quality |
| CN101197621B (zh) * | 2007-12-07 | 2012-03-07 | 中兴通讯股份有限公司 | 一种对网管系统故障进行远程诊断定位的方法及其系统 |
| CN101459925B (zh) * | 2007-12-11 | 2010-10-20 | 中国移动通信集团公司 | 电信网络投诉管理系统及方法 |
| WO2009082836A1 (fr) * | 2007-12-26 | 2009-07-09 | Zte Corporation | Procédé et dispositif de traitement d'un dysfonctionnement |
| CN101217696B (zh) * | 2007-12-28 | 2012-09-05 | 中国移动通信集团浙江有限公司 | 一种移动用户投诉综合处理系统及其方法 |
| US7995575B2 (en) * | 2008-01-02 | 2011-08-09 | Cisco Technology, Inc. | Packet error handling |
| US8588225B1 (en) * | 2008-07-07 | 2013-11-19 | Cisco Technology, Inc. | Physical resource to virtual service network mapping in a template based end-to-end service provisioning |
| US8190727B2 (en) * | 2008-07-15 | 2012-05-29 | Airbus Operations Gmbh | Network management system for an aircraft |
| US7954010B2 (en) * | 2008-12-12 | 2011-05-31 | At&T Intellectual Property I, L.P. | Methods and apparatus to detect an error condition in a communication network |
| CN101801015B (zh) | 2009-02-06 | 2014-03-12 | 中兴通讯股份有限公司 | 一种小区退服故障的处理方法及装置 |
| CN101924661B (zh) * | 2009-06-17 | 2015-07-22 | 中兴通讯股份有限公司 | 告警的处理方法及装置 |
| CN102640154B (zh) | 2009-07-30 | 2015-03-25 | 惠普开发有限公司 | 基于所接收的与网络实体相关联的事件来构造贝叶斯网络 |
| US8825845B1 (en) | 2010-11-10 | 2014-09-02 | Open Invention Network, Llc | Managing a network element operating on a network |
| CN102325036B (zh) * | 2011-05-17 | 2016-09-14 | 南京中兴软件有限责任公司 | 一种网络系统的故障诊断方法、系统及装置 |
| US9160620B2 (en) * | 2011-11-30 | 2015-10-13 | GM Global Technology Operations LLC | Integrated fault diagnosis and prognosis for in-vehicle communications |
| US9021310B1 (en) * | 2012-02-14 | 2015-04-28 | Amazon Technologies, Inc. | Policy-driven automatic network fault remediation |
| CN103684828B (zh) * | 2012-09-18 | 2018-08-03 | 长春亿阳计算机开发有限公司 | 一种电信设备故障的处理方法和装置 |
| CN103023699B (zh) * | 2012-11-30 | 2016-12-21 | 北京奇虎科技有限公司 | 一种网络修复方法和系统 |
| CN103001801B (zh) * | 2012-11-30 | 2016-12-21 | 北京奇虎科技有限公司 | 网络修复方法和装置 |
| US9071956B2 (en) * | 2012-12-03 | 2015-06-30 | Qualcomm Incorporated | Systems and methods for dynamic enablement of wireless communication device functionalities |
| US20140351414A1 (en) * | 2013-05-24 | 2014-11-27 | Alcatel Lucent | Systems And Methods For Providing Prediction-Based Dynamic Monitoring |
| US9578047B2 (en) * | 2015-01-13 | 2017-02-21 | GM Global Technology Operations LLC | Method and system for reflectometry based communication network monitoring, intrusion detection, and message authentication |
| CN105262622A (zh) * | 2015-10-27 | 2016-01-20 | 北京极科极客科技有限公司 | 一种路由器的优化和诊断的方法及系统 |
| US9973441B2 (en) * | 2015-11-07 | 2018-05-15 | King Abdulaziz City Of Science And Technology (Kacst) | Method and system for establishing routes in wireless ad-hoc networks utilizing Bayesian approach |
| US10355918B2 (en) * | 2016-01-20 | 2019-07-16 | Level 3 Communications, Llc | System and method for automatically repairing a network element |
| US10162698B2 (en) * | 2016-03-25 | 2018-12-25 | Dropbox, Inc. | System and method for automated issue remediation for information technology infrastructure |
| US10142185B2 (en) | 2016-06-08 | 2018-11-27 | At&T Intellectual Property I, L.P. | Content quality assessment and prediction via flows |
| JP6718398B2 (ja) * | 2017-02-15 | 2020-07-08 | 日本電信電話株式会社 | サービス復旧装置およびサービス復旧方法 |
| CN108540298B (zh) * | 2017-03-01 | 2022-06-17 | 中兴通讯股份有限公司 | 一种自动处理垃圾业务的方法及装置 |
| JP2018170618A (ja) * | 2017-03-29 | 2018-11-01 | Kddi株式会社 | 障害自動復旧システム、制御装置、手順作成装置およびプログラム |
| GB2608281B (en) * | 2017-09-13 | 2023-05-10 | Fisher Rosemount Systems Inc | Assistant application for a modular control system |
| US10771331B2 (en) | 2018-11-07 | 2020-09-08 | Cisco Technology, Inc. | Closed loop control for fixing network configuration issues to aid in device classification |
| CN111200827B (zh) * | 2018-11-19 | 2023-03-21 | 华硕电脑股份有限公司 | 网络系统、无线网络延伸器以及网络供应端 |
| CN109560970A (zh) * | 2018-12-24 | 2019-04-02 | 大唐软件技术股份有限公司 | 一种网络故障愈合方法、装置以及系统 |
| US10985969B2 (en) * | 2019-02-19 | 2021-04-20 | Juniper Networks, Inc. | Systems and methods for a virtual network assistant |
| EP3847843B1 (fr) * | 2019-05-20 | 2026-02-11 | Samsung Electronics Co., Ltd. | Procédés et systèmes de récupération d'éléments de réseau dans un réseau de communication |
| US11570038B2 (en) | 2020-03-31 | 2023-01-31 | Juniper Networks, Inc. | Network system fault resolution via a machine learning model |
| US11314583B2 (en) | 2020-08-18 | 2022-04-26 | Micron Technology, Inc. | Memory data correction using multiple error control operations |
| US11743151B2 (en) | 2021-04-20 | 2023-08-29 | Juniper Networks, Inc. | Virtual network assistant having proactive analytics and correlation engine using unsupervised ML model |
| CN113114357B (zh) * | 2021-06-16 | 2021-10-22 | 中兴通讯股份有限公司 | 无源波分设备故障检测方法、装置、服务器和存储介质 |
| US11770290B2 (en) | 2021-08-13 | 2023-09-26 | Juniper Networks, Inc. | Network management actions based on access point classification |
| US12450400B2 (en) * | 2023-10-31 | 2025-10-21 | Dell Products L.P. | Out of band component validation |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998024222A2 (fr) * | 1996-11-27 | 1998-06-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Systeme de gestion des pannes de logiciels |
| US6294991B1 (en) * | 1998-09-08 | 2001-09-25 | Mci Communications Corporation | Method and system therefor for ensuring a true activation of distributed restoration in a telecommunications network |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6654914B1 (en) * | 1999-05-28 | 2003-11-25 | Teradyne, Inc. | Network fault isolation |
| JP2000358029A (ja) * | 1999-06-15 | 2000-12-26 | Nec Corp | 自動障害診断ネットワークシステム及びネットワークの自動障害診断方法 |
| US6718377B1 (en) * | 1999-08-13 | 2004-04-06 | Lucent Technologies Inc. | Telecommunications network management system interface |
| US7496532B2 (en) * | 2000-06-16 | 2009-02-24 | Verisae, Inc. | Enterprise asset management system and method |
| US20020124070A1 (en) * | 2001-03-02 | 2002-09-05 | Pulsipher Eric A. | System for providing related information of a network error event in a hand-held device |
| JP4149178B2 (ja) * | 2001-03-09 | 2008-09-10 | 松下電器産業株式会社 | リモートメンテナンスシステム |
| FR2835674B1 (fr) | 2002-02-07 | 2006-02-24 | Cit Alcatel | Deploiement des regles par un dispositif de gestion de services, en fonction d'informations sur les equipements du reseau |
| JP2003244150A (ja) * | 2002-02-15 | 2003-08-29 | Toshiba Corp | ネットワーク復旧システム |
| US7091846B2 (en) * | 2002-03-18 | 2006-08-15 | Siemens Communications, Inc. | Methods and apparatus for handling information regarding an alarm for a communication network |
| FR2843260B1 (fr) | 2002-07-31 | 2005-04-08 | Cit Alcatel | Systeme de gestion de reseau par regles comportant un moteur d'inference |
| JP2004164615A (ja) * | 2002-10-11 | 2004-06-10 | Seiko Epson Corp | 作業担当者支援方法及び作業担当者支援プログラム |
| US7301909B2 (en) * | 2002-12-20 | 2007-11-27 | Compucom Systems, Inc. | Trouble-ticket generation in network management environment |
| US7620848B1 (en) * | 2003-11-25 | 2009-11-17 | Cisco Technology, Inc. | Method of diagnosing and repairing network devices based on scenarios |
| WO2006007460A2 (fr) * | 2004-06-21 | 2006-01-19 | Spirent Communications Of Rockville, Inc. | Systeme et procede d'integration de multiples sources de donnees dans des conclusions de diagnostics de services de mise en reseau informatique centres sur les services |
| US20060221913A1 (en) * | 2005-03-31 | 2006-10-05 | Adc Telecommunications, Inc. | Integrated network management of a software defined radio system |
| US8068425B2 (en) * | 2008-04-09 | 2011-11-29 | Embarq Holdings Company, Llc | System and method for using network performance information to determine improved measures of path states |
-
2004
- 2004-07-30 FR FR0408505A patent/FR2873879B1/fr not_active Expired - Fee Related
-
2005
- 2005-07-01 US US11/572,904 patent/US8149718B2/en not_active Expired - Fee Related
- 2005-07-01 JP JP2007523126A patent/JP2008508760A/ja active Pending
- 2005-07-01 WO PCT/FR2005/050530 patent/WO2006021702A1/fr not_active Ceased
- 2005-07-01 CN CNA2005800323261A patent/CN101027872A/zh active Pending
- 2005-07-01 EP EP05787400A patent/EP1774705A1/fr not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998024222A2 (fr) * | 1996-11-27 | 1998-06-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Systeme de gestion des pannes de logiciels |
| US6294991B1 (en) * | 1998-09-08 | 2001-09-25 | Mci Communications Corporation | Method and system therefor for ensuring a true activation of distributed restoration in a telecommunications network |
Non-Patent Citations (2)
| Title |
|---|
| GARIJO M ET AL: "A MULTIAGENT SYSTEM FOR COOPERATIVE NETWORK-FAULT MANAGEMENT", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON THE PRACTICAL APPLICATION OF INTELLIGENT AGENTS AND MULTI-AGENT TECHNOLOGY, XX, XX, 22 April 1996 (1996-04-22), pages 279 - 294, XP002068055 * |
| JIANN-LIANG CHEN ET AL: "A fuzzy expert system for network fault management", SYSTEMS, MAN AND CYBERNETICS, 1996., IEEE INTERNATIONAL CONFERENCE ON BEIJING, CHINA 14-17 OCT. 1996, NEW YORK, NY, USA,IEEE, US, vol. 1, 14 October 1996 (1996-10-14), pages 328 - 331, XP010206647, ISBN: 0-7803-3280-6 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101027872A (zh) | 2007-08-29 |
| FR2873879B1 (fr) | 2006-10-27 |
| US8149718B2 (en) | 2012-04-03 |
| JP2008508760A (ja) | 2008-03-21 |
| EP1774705A1 (fr) | 2007-04-18 |
| US20070260911A1 (en) | 2007-11-08 |
| WO2006021702A1 (fr) | 2006-03-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2873879A1 (fr) | Systeme de gestion de reseau de communication pour reparation automatique de pannes | |
| EP1463238B1 (fr) | Dispositif de gestion locale de procédés d'assurance pour un équipement de réseau de communications | |
| US8411579B2 (en) | Communication system hierarchical testing systems and methods—entity dependent automatic selection of tests | |
| US7434099B2 (en) | System and method for integrating multiple data sources into service-centric computer networking services diagnostic conclusions | |
| EP0951155B1 (fr) | Procédé et système d'administration de réseaux et de systèmes | |
| US11533215B2 (en) | Programmable diagnosis model for correlation of network events | |
| US11809266B2 (en) | Failure impact analysis of network events | |
| Harrington | Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions | |
| US11956116B2 (en) | Programmable diagnosis model for correlation of network events | |
| Bahnasse et al. | Smart hybrid SDN approach for MPLS VPN management on digital environment | |
| Morris | Network management, MIBs and MPLS | |
| CN1744522B (zh) | 在通信网络中使用的模块化的基于演进的知识的诊断设备 | |
| Varga et al. | Integration of service-level monitoring with fault management for end-to-end multi-provider ethernet services | |
| CN100433644C (zh) | 用于通信网络中的利用自适应诊断模型的诊断设备 | |
| EP2472783B1 (fr) | Procédé de selection de noeuds de bordure inter-domaines | |
| Al-Fuqaha et al. | Intelligent service monitoring and support | |
| WO2023249506A1 (fr) | Relecture d'analytique pour système de gestion de réseau | |
| Acharya et al. | Presence based network topology tracing system for VoIP networks | |
| Abdurakhmanov et al. | Distributed Fault Management in WBEM-based inter-AS TE for QoS guaranteed DiffServ-over–MPLS | |
| CN118743199A (zh) | 应用服务级别期望健康和性能 | |
| Festor et al. | Operations & Management: 12th International Workshop on Distributed Systems, DSOM 2001: proceedings | |
| del Nuevo | Deliverable 3.1. 1 Preliminary report on IP and carrier-grade management functions analysis | |
| Golub et al. | Deliverable D8. 6 (DS4. 3.2): Initial Design for Refactoring GN3 Tools based on Business Process Modelling | |
| Halse | Novel Approaches to the Monitoring of Computer Networks | |
| Harrington | RFC 5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| CD | Change of name or company name | ||
| ST | Notification of lapse |
Effective date: 20100331 |