EP1774705A1 - 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

Info

Publication number
EP1774705A1
EP1774705A1 EP05787400A EP05787400A EP1774705A1 EP 1774705 A1 EP1774705 A1 EP 1774705A1 EP 05787400 A EP05787400 A EP 05787400A EP 05787400 A EP05787400 A EP 05787400A EP 1774705 A1 EP1774705 A1 EP 1774705A1
Authority
EP
European Patent Office
Prior art keywords
diagnosis
module
communication network
management system
failure
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.)
Withdrawn
Application number
EP05787400A
Other languages
German (de)
English (en)
Inventor
Emmanuel Marilly
Olivier Martinot
Mohamed Adel Saidi
Sylvain Squedin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Publication of EP1774705A1 publication Critical patent/EP1774705A1/fr
Withdrawn legal-status Critical Current

Links

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 œuvre 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 grand nombre de données d'information et d'alarmes auprès des nombreux é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 Génération 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 llogRules™ 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 « Faυlt Détective 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 Interpréter » et « Troubleshooting Assistant » (TAC) de la société Cisco.
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 Une 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.
Des solutions existent pour automatiser la configuration des équipements du réseau de communication en fonction de la détermination d'un diagnostic. De telles solutions sont par exemple décrites dans « A Multiagent System for Coopérative Network-Faυlt Management » de Mercedes Garijo, Andrés Cancer et Julio J. Sanchez, paru le 22 avril 1996 dans Proceedings of the International Conférence on the Practical Application of Intelligent Agents and Multi-agent Technology, ou bien dans « A Fuzzy Expert System for Network Faυlt Management » de Jiann-Liang Chen et Pei-Hwa Huang, paru en octobre 1996 dans Systems, Man and Cybernetics, IEEE International Conférence on Beijing.
Toutefois, ces systèmes ne disposent d'aucun moyen de contrôle pour s'assurer que les actions correctives ont effectivement corrigé les problèmes détectés. Ils ne permettent pas non plus de s'assurer si ces actions correctives n'ont pas dégradé la situation. Cette problématique n'est nullement abordée, même, dans ces documents. Le but de l'invention est d'automatiser la correction des pannes du réseau de communication géré, tout en s'assurant que les problèmes détectés sont corrigés ou, tout du moins, que la situation générale du réseau de télécommunication est améliorée.
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é 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, 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. Selon des modes de réalisation de l'invention, le système de gestion peut comporter les caractéristiques suivantes, individuellement ou en combinaison : 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 œuvre un réseau bayesien afin de déterminer le diagnostic. 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 ; la première étape étant automatiquement déclenchée à l'issue de la seconde étape, afin de former un cycle de traitement
Selon des modes de réalisation de l'invention, le procédé de gestion peut comporter les caractéristiques suivantes, individuellement ou en combinaison : - 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.
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 œuvre 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 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 à 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 œuvre 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 déterminer la cause technique ayant amenée cette plainte. Il 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 :
• II 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.
• II 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 Informat ion 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 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 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. Il 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 :
• II 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.
• II doit pouvoir fournir le diagnostic le plus probable et si possible y attacher une probabilité.
Préférentiellement, ce module de diagnostic met en œuvre 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 diagnostics sont par exemple décrits dans l'ouvrage « An introduction to Bayesian Networks » de F. Jensen, LJCL Press, 1996 ou dans l'article « IP VPN Network Diagnosis : Technologies and Perspectives » de Gérard Délègue, Stéphane Betgé-Brezetz, Emmanuel Marilly et Olivier Martinot, 3rd International Conférence 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 CPLJ), « Interface I N Status » (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 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 sont par exemple conformes au protocole SNMP (Simple Network Management Protocol) défini par l'IETF (Internet Engineering Task Force) dans les RFC 1 157 et 1592 pour les versions 1 et 2 respectivement. II peut s'agir d'un unique message (ou « trap ») 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 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 Reqυest 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érentiel lement 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.
• 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 table suivante donne un exemple d'un « trap SNMP » :
Ces OIDs (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 « trap 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 œuvre, 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 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/l 92.128.12.52, lnterface=FastEthernetl/O) && ((lteration = l )<3) && (Failure = INTERFACE_DOWN) Then (Exécute Corrective Action 2). o If (Router=Alcatel/l 92.128.12.52, lnterface=FastEthernetl/O) && ((lteration = l )<3) && (Failure
BGP_MISCON FIGU RATION ) Then (Exécute Corrective Action 3). o (Corrective Action 2) = Put (Router = Cisco/192.128.12.52, lnterface=FastEthernetl /O) Interface Up. o (Corrective Action 3) = Configure
(Router=Alcatel/l 92.128.12.52, Interface =FastEthernetl/O)
With BGP_Configuration_Script_l
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 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 réseaux neuronaux. L'avantage de l'utilisation des réseaux de neurones est 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 N1 et N2, chacune de ces commandes spécifiques étant conforme au langage propre des équipements, et notamment de leur interface CLI (Commancf Une 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 « Policy- based Management » en langue anglaise) peut notamment être utilisée. Les demandes de brevet EPl 335524 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 EPl 387526 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. 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. Il 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 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 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 {back tracking) 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 œuvre 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 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 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 « Fl ») S'il y a une panne, le procédé consiste à déterminer certains critères d'arrêts (« Stop ? »). Il 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 œuvre une étape « Rep » consistant à 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.
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 (« υp » 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 (« υp ») et que le réseau fonctionne normalement. Il 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. 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 (« cfown »). 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 (« cfown »). 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 convertit en une commande conforme au langage propre au routeur Y afin de mettre l'interface X en service (« υp »).
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. Il ressort du nouveau diagnostic D que la même interface X du routeur Y est hors-service (« down »). 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 différents comportements, comme avertir l'opérateur, déclencher un module d'optimisation du trafic, déclencher des commandes de réparation etc.

Claims

REVENDICATIONS
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 (N1, 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), 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, et 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.
2) 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é.
3) 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 formulées dans un langage générique, en des commandes spécifiques (C1, C2) conformes à des langages de commandes propres aux différents équipements dudit réseau de communication.
4) Système de gestion selon l'une des revendications 2 ou 3, 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.
5) 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. 6) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de diagnostic (MD) met en œuvre un réseau bayesien afin de déterminer ledit diagnostic.
7) 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.
8) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de diagnostic communique ledit diagnostic audit module de réparation au moyen d'un message conforme au protocole SNMP. 9) 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.
10) Système de gestion selon la revendication précédente et la revendication 2, dans lequel lesdites règles peuvent dépendre dudit compteur d'itérations.
11) 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 (N1, 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, et en ce que ladite première étape est automatiquement déclenchée à l'issue de ladite seconde étape, afin de former un cycle de traitement.
12) 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é.
13) Procédé selon la revendication précédente, dans lequel un historique des diagnostics et des actions correctives déterminées à chaque 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.
14) Procédé selon l'une des revendications 1 1 à 13, 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.
15) Procédé selon l'une des revendications 1 1 à 14, 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.
16) Procédé selon l'une des revendications 1 1 à 15, dans lequel ladite première étape met en oeuvre un réseau bayesien afin de déterminer ledit diagnostic. 17) Procédé selon l'une des revendications 1 1 à 16, 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.
EP05787400A 2004-07-30 2005-07-01 Systeme de gestion de reseau de communication pour reparation automatique de pannes Withdrawn EP1774705A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP1774705A1 true EP1774705A1 (fr) 2007-04-18

Family

ID=34947039

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05787400A Withdrawn EP1774705A1 (fr) 2004-07-30 2005-07-01 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 (46)

* Cited by examiner, † Cited by third party
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 中国移动通信集团浙江有限公司 一种移动用户投诉综合处理系统及其方法
US7957423B2 (en) * 2008-01-02 2011-06-07 Cisco Technology, Inc. Packet error correction
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
DE102009033215A1 (de) * 2008-07-15 2010-01-21 Airbus Operations Gmbh Netzwerkverwaltungs-System für ein Flugzeug
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株式会社 障害自動復旧システム、制御装置、手順作成装置およびプログラム
JP7398189B2 (ja) * 2017-09-13 2023-12-14 フィッシャー－ローズマウント システムズ，インコーポレイテッド 方法、コンピューティングデバイスおよびシステム
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
WO2020235926A1 (fr) * 2019-05-20 2020-11-26 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
US11770290B2 (en) 2021-08-13 2023-09-26 Juniper Networks, Inc. Network management actions based on access point classification

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6012152A (en) * 1996-11-27 2000-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Software fault management system
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
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
EP1312003A4 (fr) * 2000-06-16 2005-12-21 Verisae Systeme et procede de gestion des avoirs d'une entreprise
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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006021702A1 *

Also Published As

Publication number Publication date
US8149718B2 (en) 2012-04-03
FR2873879A1 (fr) 2006-02-03
JP2008508760A (ja) 2008-03-21
FR2873879B1 (fr) 2006-10-27
WO2006021702A1 (fr) 2006-03-02
US20070260911A1 (en) 2007-11-08
CN101027872A (zh) 2007-08-29

Similar Documents

Publication Publication Date Title
EP1774705A1 (fr) Systeme de gestion de reseau de communication pour reparation automatique de pannes
EP1463238B1 (fr) Dispositif de gestion locale de procédés d&#39;assurance pour un équipement de réseau de communications
EP0951155B1 (fr) Procédé et système d&#39;administration de réseaux et de systèmes
US7434099B2 (en) System and method for integrating multiple data sources into service-centric computer networking services diagnostic conclusions
EP3087701B1 (fr) Procede de diagnostic de fonctions service dans un reseau ip
JP4509093B2 (ja) エンド・ツー・エンドのテスト及び診断マネジャ
US20210243068A1 (en) Programmable diagnosis model for correlation of network events
US20090129260A1 (en) Devices, Systems, and/or Methods Regarding Virtual Routing Forwarding
FR2809513A1 (fr) Controle de qualite de service, notamment de telecommunication
Harrington Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions
FR2860369A1 (fr) Localisation de points d&#39;entree de flux dans un reseau de communications
Morris Network management, MIBs and MPLS
EP1633081A1 (fr) DIispositif de diagnostic modulaire à base de connaissances évolutive, pour un réseau de communications
Bahnasse et al. Smart hybrid SDN approach for MPLS VPN management on digital environment
EP1401146A1 (fr) Dispositif et procédé de planification de configuration d&#39;un réseau de communications par prévision d&#39;évolution
EP1635507B1 (fr) Dispositif de diagnostic à modèles de diagnostic adaptatifs, pour un réseau de communications
García-Algarra et al. A lightweight approach to distributed network diagnosis under uncertainty
Varga et al. Integration of service-level monitoring with fault management for end-to-end multi-provider ethernet services
Yu et al. A practical scheme for MPLS fault monitoring and alarm correlation in backbone networks
US11956116B2 (en) Programmable diagnosis model for correlation of network events
EP2472783B1 (fr) Procédé de selection de noeuds de bordure inter-domaines
US11088928B2 (en) Service aware conditional path monitoring
Al-Fuqaha et al. Intelligent service monitoring and support
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

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070228

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20101029

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110510