FR 2834409 A1 20030704 FR 0200037 A 20020103 une liaison série. Système de gestion de réseaux de transport basé l'analyse des tendances des donnces acquises sur le réseau La présente invention est relative à un système de gestion de réseaux de transport, notamment de réseaux de télécommunication. Au sein de ces réscaux de transport, de nombreux flux de données sont transmis. Le trafic résultant des ces flux de donnces a un comportement susceptible d'évolutions importantes avec le temps. Aussi, il est possible qu'à un instant donné, le trafic devienne incompatible avec les ressources disponibles sur le réseau de télécommunication, ou avec un contrat de qualité de service ou SLA (Service Level Agreement) sur lequel l'opérateur du réseau s'est engagé vis-à-vis d'un client ou d'un fournisseur de service C'est typiquement le cas lorsque le déLit sur un lien entre deux n_ubs du réseau devient supérieur au débit admissible sur ce lien. Il en résulte un engorgement et une perte de performance des flux de données. Pour palier ce problème, les réseaux de transport sont généralement associés à des systèmes de gestion de réseau, dont un des buts est de surveiller le trafic en certains points jugés clés du réseau, au moyen de sondes de mesure. Ces sondes de mesure transmettent des données au système de gestion de réscau, soit au moyen d'alarmes, soit en réponse à des requêtes de mesures provenant du système de gestion de réssau lui-méme. Selon les systèmes de gestion de réscau, les donnces acquises sont ensuite présentées à un opérateur humain, idéclement après un traitement informatique simple pour les rendre plus lisibles. L'opérateur a alors pour tâche de surveiller cet ensemble de donnces acquises afin de détecter une anomalie (panne d'un élément du réseau, engorgement d'un lien, etc.). Ensuite, I'opérateur doit décider de l'action corrective approprise 1 03957/SYC/NNAD L:\Salle\F1 03957\PREMDEP\Fll\projelUr.doc (remplacement d'un élément de réseau, redéfinition des schémas de routage, etc.) Toutefois, une tel le façon de faire s'avère insuffisante. D'une part, la tail le et la complexité grandissante des réscaux de transport (notamment de télécommunication) et la multiplicité des services à déployer sur ces réscaux tendent à faire cro^'tre le nombre de donnses acquises que l'opérateur doit surveiller. Il en ressort une difficulté grandissante pour l'opérateur de récliser sa tâche de façon efficace. D'autre part, seul l'état du réseau de transport à un instant donné est pris en compte. L'opérateur n'a aucun moyen simple d'anticiper les problémes et doit donc leur faire face uniquement au moment o ils se présentent. A ce moment-là, les conséquences de ces problèmes sont, bien entendu, plus importantes que s'ils avaient été anticipés. Cela peut notamment déboucher sur la violation d'un SLA (Service Level Agreemenf), c'est-à-dire du contrat qui lie l'opérateur du réscau de transport et un tiers (client ou fournisseur de services). Une telle violation peut avoir pour conséquence le paiement d'une pénalité au tiers lésé. Le but de l'invention est de palier ce problème posé par les solutions de l'état de la technique. Pour ce faire, le système de gestion de réscau selon l'invention calcule, de façon automatique, des tendances à partir des donnces acquises et détermine si ces tendances satisfont des conditions qui leur ont été associéss. Plus précisément, I'invention a pour objet un système de gestion de réseau, comportant un module d'acquisition de donnces provenant du réseau de transport géré. Ce système se caractérise en ce qu'il comporte À un module de calcul de tendances apte à déterminer la tendance d'un ensemble de données acquises, et 1 03957/SYC/NNAD L:\Salle\F1 03957\PREMDEP\FIT\projelbr.doc À un module de calcul de satisfaction, apte à déterminer la satisfaction de conditions associces à ces tendances. Les conditions peuvent par exemple étre formées à partir de seuils et d'opérateurs de comparaison liant les seuils aux tendances. Le système de gestion de réseau peut de surcro^t comporter une base de définition de tendance contenant les paramètres de l'association entre les donnéss acquises et les tendances et une base de déTinition de conditions définissant l'association entre les conditions et les tendances. Ainsi, I'opérateur peut ne se voir présenter que les tendances qui ne satisfont pas les conditions qu'on leur a associéss. L'opérateur peut alors anticiper un problème avant que celui-ci n'apparaisse. Il peut donc entreprendre des actions correctives, de sorte que ce problème potentiel ne survienne pas. Selon une mise en _uvre de l'invention, le module de calcul de satisfaction détermine la date à laquelle une condition commence à ne plus 8tre satisfaite, et possède de surcro'^t des moyens pour classifier les situations de non-satisfaction de condition, en fonction de ces dates. Le module de caicul de satisfaction peut en outre 8tre prévu pour déclencher une alarme lorsque la date dépasse un seuil déterminé. Selon une mise en _uvre de l'invention, le système de gestion de réseau comporte en outre un module de déclenchement d'actions pour déclencher des actions correctrices associces aux conditions, lorsque le module de calcul de satisfaction de conditions a déterminé qu'une condition n'était pas satisfaite. Ce module de déclenchement d'actions peut être apte à transmettre ces actions correctrices, aux équipements du résaou de transport géré et/ou à un module de gestion de trafic. 1 03957/SYC/NNAD L:\Salle\F7 03957\PREMDEP\FIT\projelbr.doc Il peut aussi être apte à transmettre les actions correctives à un service de planification en charge du réseau de transport géré. Ainsi, I'opérateur peut ne plus intervenir sur un certain nombre d'actions correctives qui peuvent être gérces automatiquement par le système de gestion de résacu. L'invention a pour second objet un système de gestion de service, comportant un système de gestion de réseau tel que décrit. L' invention et ses avantages seront expl iqués plus cla irement da ns la description de mises en _uvre qui va suivre, en liaison avec les figures annexces. La figure 1 représente un réseau de télécommunication et son interaction avec un système de gestion de réseau selon l'invention. La figure 2 détaille, de façon schématique, le système de gestion de réscau selon l'invention. La figure 3 illustre un exemple de calcul de satisfaction de condition. Sur la figure 1, le réseau de télécommunication N comporte des éléments de réseau, ici des routeurs, R, R2, R3, R4. Ce réseau de télécommunication est associé à un système de gestion de réseaux NMS. Les éléments de réscau transmettent des données, d,, d2, d3, d4 à un mod u le d 'acquisition de don nces DAM, faisa nt partie d u système de gestio n de réseau NMS. Ces données acquises peuvent provenir d'alarmes ou bien de mesures. Les alarmes sont notifiées par un équipement de réscau ayant détecté un problème (déficience, dépassement d'un seuil par une valeur, etc.) 1 03957/SYC/NNAD L:\Salle\F1 03957\PREMDEP\FIT\projelbr. doc Les mesures sont des valeurs transmises en deLors d'une situation de probléme. Elles peuvent correspondre à un modèle " posh ", c'est à dire être transmises à la demande du système de gestion de réseau NMS. Ces transmissions peuvent être périodiques. Elles peuvent aussi correspondre à un modèle " pull ". Dans ce cas, les mesures sont disponibles dans des bases de données localisses sur les équipements de réseau. Ces bases de donnces sont habituellement désignées sous l'acronyme MIB, pour Management Information Base, en anglais. Le système de gestion réseau NMS peut alors lire ces mesures en accéJant à ces bases de donnces MIB. Ces donnces acquises sont transmises ensuite, par exemple périodiquement, à un module de calcul de tendances TCM. Ce module d'analyse de tendances TCM est apte à calculer la tendance de chaque ou d'une partie des données acquises. Pour ce faire, il peut utiliser une base de déTinition de tendances TDB, qui contient les délinitions des tendances à calculer. La définition d'une tendance peut être caractérisée par des paramètres de l'association entre des donnces acquises et des tendances. Plus précisément, il peut s'agir, pour chaque tendance, de la désignation des valeurs acquises sur laquelle elle porte, la méthode de calcul de la tendance (régression linéaire, non linéaire...) et des paramètres de cette méthode. Les tendances ainsi calculées sont ensuite transmises à un module de calcul de satisfaction SCM. Son rôle est de vérifier que les tendances qui lui sont transmises par le module de calcul de tendances TCM, satisfont un ensemble de conditions. Ces conditions sont déTinies dans une base de délinition de conditions CDB, qui permet d'associer les tendances à des conditions. Ces conditions peuvent être caractérisées par un opérateur de comparaison et, 1 03957/SYC/NNAD L:\Salle\F1 03957\PREMDEP\FIT\projelEr.doc éventuellement par une valeur. Elles peuvent 8tre exprimoes sous la forme: valeur 1 " Cette valeur peut étre une valeur de seuil, fixé préclablement, ou bien une valeur d'historique, par exemple déterminée par un instant précédent de I'évolution de la (ou desJ donnée(s) acquise(s). Ces conditions peuvent mettre en jeu plusieurs tendances, qui peuvent alors être reliées: À soit par un opérateur de comparaison. On peut ainsi exprimer, par exemple, des conditions de la forme " Tendancel > Tendance2 ". À Soit par un opérateur logique, afin de permettre d'exprimer des comparaisons de la forme: " Tendancel > valeurl ET Tendance2 > valeur2 " Ce module de calcul de satisfaction de condition CSM vérifie, par exemple périodiquement, que l'ensemble des conditions sont satisfaites. S'il détecte qu'une ou plusieurs tendances ne satisfont pas une condition qui leur est associé, I'opérateur peut en étre avertie au moyen d'une interface homme machine IHM. Dans les autres cas, les données acquises ou les tendances peuvent ne pas étre présentée à l'opérateur, ceci afin de limiter le nombre d'information que l'opérateur doit traiter. Ainsi, I'opérateur peut se voir présenter des informations sur l'évolution prévisible du réseau géré. Il peut donc anticiper cette évolution en mettant en _uvre des actions correctives permettant soit de minimiser, soit de supprimer les effets négatifs de cette évolution. Ce module de calcul de satisfaction de condition CSM peut aussi déterminer la date à laquelle une tendance commence à ne plus satisfaire une condition. 1 03957/SYC/NNAD L:\Scille\F1 03957\PREMDEP\FIT\projelUr. doc Ainsi, selon un mode de réulisation de l'invention, les non- satisfactions de condition peuvent être classifices, notamment en fonction de ces dates. Il est alors aisé, notamment par l'opérateur, de traiter les problémes suivant la proximité de leur occurrence. La figure 3 illustre un exemple de calcul de satisfaction de condition. L'axe des abscisses représente le temps, et l'axe des ordonnées représente la valeur de la valeur considérce. Les points m, m2, m3, m4, m5, sont des donnces acquises par le module d'acquisition de donnces DAM. La courbe T représente la tendance calculée par le module de calcul de tendances TCM. Un seuil S a été placé pour former une condition > déTinie dans la base de délinition des conditions CDB et dont la satisfaction est vérifiée par le module de calcul de satisfaction de conditions SCM. Ce dernier est à méme de déterminer que cette tendance T va dépasser la condition > en un point P. Il peut alors présenter à l'opérateur, via l'interface homme-machine IHM, une information lui indiquant ce dépassement. Il peut aussi lui étre présenté la date du point P auquel la tendance T dépasse le seuil S. ou plutôt le délai séparant cette date, de la date courante (c'est-à-dire, ici, la date de la dernière donnce acquise m5). Selon une mise en _uvre de l'invention, on peut classifier les informations fournies à l'opérateur, en fonction de ce délai 6. Les conditions non satisfaites sont classées par ordre de délai croissant. Ceci permet de mettre en avant à l'opérateur, les problèmes les plus urgents à traiter. Selon un mode de réclisation, il est possible d'associer un seuil d'alarme à la condition cela à différents horizons temporels. La valeur de fiabilité se répercute bien évidemment sur les résultats du module de calcul de satisfaction SCM, et donc sur les informations présentées à l'opérateur. Par exemple, chaque information relative à une non-satisfaction d'une condition peut être affichée en association avec une valeur de fiabilité. 11 peut aussi être prévu, selon un mode de réclisation de 1'invention, q ue l 'i nterface hom me-machi ne permette des interactions pl us évol uses avec les différents modules du système de gestion de réseau NMS. Elle peut notamment permettre à l'opérateur d'effectuer des requêtes en prédiction. Par exemple, le système peut fournir à la demande, la date à laquelle une tendance atteint une valeur fixce par 1'opérateur. Inversement, il peut fournir la valeur atteinte par une tendance à une date détermince par cet opérateur. Cette interface homme-machine (ou bien une autre) peut aussi être connectée directement à la base de délinition des tendances TDB et/ou à la 1 03957/SYC/NNAD L:\Salle\F 1 03957\PREMDEP\Fll\projetbr.doc base de définition des conditions CDB, afin de permettre la créction, la modification et la suppression de tendances et/ou de conditions. Alternativement, ces bases peuvent être enrichies au moyen de simples fichiers, par exemple. La figure 2 illustre une seconde mise en _uvre de 1'invention. Le module de gestion de réseau NMS est associé à un réseau N composé de 4 équipements de réseau R" R2, R3, R4. Comme dans la mise en _uvre illustrée par la figure 1, ce module de gestion de résacu NMS comporte un module d'acquisition de donnces DAM, un module de calcul de tendances TCM associé à une base de déTinition de tendances TDB et un module de calcul de satisfaction SCM associé à une base de définition de conditions CDB, I'ensemble de ces modules et de ces bases étant identiques à ceux décrit précédemment. Le module d'acquisition de donnces acquière des données d3, d4 ainsi que décrit précédemment. Selon cette mise en _uvre, le module de calcul de satisfaction communique avec un module de déclenchement d'actions ADM. Le rôle de ce dernier est de déclencher automatiquement des actions correctrices lorsque le module de calcul de satisfaction SCM détecte qu'une condition n'est pas satisfaite. Cette action correctrice peut nocessiter une action de confirmation, ou éventuellement de paramétrage, de l'opérateur par le biais de l'interface homme-machine IHM. L'action correctrice est ensuite transmise soit aux équipements de réseau, a3, soit à un module de gestion de trafic TMM, ah, qui peut étre conforme aux modules de gestion de trafic tels que connus de l'état de la technique. 10395 7/SYC/N NAD L:\Sclle\F 10395 7\PREA4DEP\FIT\projelUr. doc Ce module de gestion de trafic est. classiquement, apte à déterminer les actions bas-niveaux a, a2 correspondant à l'action correctrice ah qui lui est soumis. Ces actions bas-niveau a, a2, a3 sont transmises à certains éléments de réseau, R, R2 et R3 sur la figure 2, afin d'éviter le probième qui a été pré détecté par le module d'analyse de tendances TAM. Ces actions a, a2, a3 peuvent par exemple viser à Modifier la route d'un tunnel MPLS (Multi-Protocol Label Switching), Modifier la taille d'un tunnel MPLS, 10. Récliser de la répartition de charge (ou "Lood balancing" en anglais), etc. Ainsi, I'opérateur peut ne plus avoir à intervenir pour certaines opérations correctives et se consacrer aux problèmes les plus complexes. Pour des catégories intermédiaires de problèmes, I'action de l'opérateur peut se limiter à la confirmation et/ou au paramétrage d'actions correctives proposées automatiquement par le système de gestion de réscau NSM. Dans tous les cas, il en résulte un gain substantiel en efficacité pour l'opérateur. Il peut aussi étre prévu qu'une action correctrice consiste à alerter le service de planification en charge du réseau. Ceci permet de mettre en _uvre des actions correctrices à plus long terme consistant à redimensionner le réseau, par exemple en ajoutant des équipements de réseau, ou en changeant le type de connexion physique entre les routeurs. Lorsque le modu le de déclenchement d'actions ADM a pl usieu rs non - satisfactions de conditions à gérer simultanément, il peut faire un tri en se basant sur les délais restant avant les non-satisfactions des conditions, ainsi que décrit précédement. Plus particulièrement, les actions peuvent n'8tre 103957/SYC/NNAD L:\Salle\F103957\PREMDEP\FIT\projelbr.doc déclenchées que si une alarme est levée, c'est-à-dire si le délai est inférieur à un seuil A. 1 03957lSYC/NNAD REVENDICATIONS 1) Système de gestion de réseau, comportant un module d'acquisition de donnces (DAM) provenant du réseau de transport géré, caractérisé en ce qu'il comporte un module de calcul de tendances (TCM) apte à déterminer la tendance d'un ensemble de données acquises, et un module de calcul de satisfaction (SCM), apte à déterminer la satisfaction de conditions associéss aux dites tendances. 2) Système de gestion de réseau selon la revendication précédente, dans lequel lesHites conditions sont formées à partir de seuils et d'opérateurs de comparaison liant lesUits seuils aux dites tendances. 3) Système de gestion de réseau selon l'une des revendications précédentes, comportant de surcro^'t une base de délinition de tendance (TDB) contenant les paramètres de l'association entre les données acquises et lesHites tendances et une base de délinition de conditions (CDB) délinissant l'association entre les conditions et les tendances. 4) Système de gestion de réseau selon l'une des revendications précédentes, dans lequel ledit module de calcul de satisfaction détermine la date à laquelle une condition commence à ne plus être satisfaite, et possédant de surcro^'t des moyens pour classifier les situations de nonsatisfaction de condition, en fonction desUites dates. ) Système de gestion de réscau selon la revendication précédente, dans lequel ledit module de calcul de satisfaction est prévu pour déclencher une alarme lorsque ladite date dépasse un seuil déterminé. 1 03957/SYC/NNAD L:\Salle\F1 03957\PREMDEP\FIT\projelUr.doc 6) Système de gestion de réseau selon l'une des revendications précédentes, dans lequel une valeur de fiabilité est associée auxdites tenda nces. 7) Système de gestion de réseau selon l'une des revendications précédentes, comportant de surcro'^t une interface hom me-machine (I HM) permettant la réclisation de requetes de prédiction. 8) Système de gestion de réseau selon l'une des revendications précédentes, comportant en outre un module de déclenchement d'actions (ADM) pour déclencher des actions correctrices associces auxdites conditions, lorsque ladit module de calcul de satisfaction de conditions (SCM) a déterminé qu'une condition n'était pas satisfaite. 9) Système de gestion de réscau selon la revendication précédente, dans lequel ledit module de déclenchement d'actions est apte à transmettre lesdites actions correctrices, aux équipements dudit réseau de transport géré et/ou à un module de gestion de trafic (TMM). 10) Système de gestion de réscau selon l'une des revendications 8 ou 9, da ns lequel ledit module de déclenchement d 'actions est apte à transmettre lesUites actions correctives à un service de planification en charge dudit réseau de transport géré. 11) Système de gestion de service, comportant un système de gestion de réseau selon l'une des revendications 1 à 10.