FR 2812995 A1 20020215 FR 0010458 A 20000809 -1. 2812995 Système et procédé de gestion d'un commutateur d'un opérateur de télécommunication" La présente invention se rapporte à un système de gestion d'un commutateur d'un opérateur de télécommunication. Elle vise également le procédé mis en oeuvre dans ce système pour la gestion d'un réseau de commutateurs d'un opérateur donné. Un commutateur d'un opérateur de télécommunication donné a essentiellement pour rôle la transmission dans de bonnes conditions d'un signal de télécommunication vers un second commutateur distant. Ce second commutateur peut être un commutateur appartenant au même opérateur ou à un opérateur différent. Dans l'état actuel de la technique, des commutateurs organisés en réseau de commutateurs sont gérés à partir de terminaux de commande reliés à ce réseau. Un terminal de commande d'un commutateur est essentiellement utilisé par un personnel technique maîtrisant parfaitement un langage spécifique de commande des commutateurs. L'état de fonctionnement d'un commutateur est suivi et surveillé en consultant plusieurs données brutes représentées dans des tableaux sous forme de codes. Ainsi un tel système a pour inconvénient majeur de n'être maîtrisable que par techniciens. La présente invention vise à remédier à cet inconvénient en proposant un système dans lequel des personnels techniciens et des personnels commerciaux peuvent tout autant intervenir dans la gestion d'un commutateur. L'invention vise ainsi un objectif d'ouverture à un plus grand nombre de personnes de la gestion d'un commutateur dans un souci d'optimisation de - 2- 2812995 son exploitation, en proposant un système permettant une amélioration de la gestion technique, commerciale et financière d'un réseau de commutateurs d'un opérateur de télécommunication. Un autre but de l'invention est de réaliser une fonction optimisée de routage à moindre coût, désignée sous le terme de "Least Cost Routing" en langue anglaise. On atteint les objectifs précités avec un système pour gérer au moins un commutateur d'un opérateur de télécommunication, ce commutateur étant pourvu d'un terminal de commande Suivant l'invention, ce système comprend: - un serveur de gestion connecté via au moins un réseau de communication au terminal de commande et comprenant: - des moyens pour collecter des données de commutation au sein dudit terminal de commande, - des moyens pour stocker ces données de commutation au sein d'une base de données, des moyens pour traiter ces données collectées et stockées en vue d'élaborer une pluralité d'interfaces graphiques représentant le fonctionnement dudit commutateur; et - au moins un terminal client connecté au serveur de gestion via au moins un réseau de communication et agencé pour visualiser au moins une des dites interfaces graphiques et pour émettre des requêtes de commande formulées par un utilisateur. Avec un tel système, les interfaces graphiques permettent une vision globale de l'état de fonctionnement du commutateur ou du réseau de commutateurs. Le système de gestion selon l'invention traduit ainsi le langage technique de commande d'un commutateur en un langage visuel dont le degré de technicité et de complexité est -3- 2812995 significativement réduit. Ainsi, les ordres de commande du commutateur sont réalisés plus rapidement. En outre, la commande du commutateur s'ouvre à un public d'utilisateurs plus large que celui des seuls techniciens, par exemple à des personnels commerciaux qui peuvent désormais participer à la gestion du commutateur. Les personnels commerciaux apportent en effet une valeur ajoutée à la gestion d'un commutateur puisqu'ils sont directement en contact avec les clients. On peut ainsi tenir compte, dans la gestion du commutateur, des alarmes, des attentes et des requêtes de la clientèle. Le serveur de gestion mis en oeuvre dans le système de gestion selon l'invention est de préférence conçu pour récupérer et traiter des données d'une pluralité de commutateurs d'un opérateur de télécommunication donné. Dans ce cas, on parle donc de réseau de commutateurs. Avantageusement, le serveur de gestion met à jour de façon périodique la base de données en fonction des données périodiquement récupérées dans le terminal de commande. Cette périodicité peut être par exemple de dix secondes entre chaque consultation du terminal de commande et récupération des données modifiées. Pour cela, on peut installer un logiciel de communication ou une interface fonctionnelle qui est apte à entrer en contact avec le serveur et lui transmettre les données pertinentes. D'une façon générale, le terminal de commande est pourvu d'un logiciel de commande du commutateur. Ainsi l'interface fonctionnelle de la présente invention vient se greffer sur ce logiciel afin de prélever des données sans pour autant bloquer le fonctionnement de ce logiciel de commande. -4- 2812995 L'exploitation d'un commutateur peut généralement être schématisée en deux parties distinctes mais intimement liées: les connexions et la traduction. Les données récupérées par le serveur concernent ces deux parties. Plus précisément, les connexions comprennent toute la partie physique ("hardware" en langue anglaise) composée de liens de transmissions (SDH/PDH) qui relient entre eux l'ensemble des commutateurs de chaque opérateur. Ces liens physiques sont répartis en plusieurs sous- ensembles plus ou moins étoffés suivant la technologie du commutateur utilisé. L'entité standard et universelle entre deux commutateurs est le MIC (Modulation Impulsion de Codage) schématisé par trente deux intervalles de temps ou trente et un voix de paroles (intervalle 0 = synchro). Dans la technologie Alcatel par exemple, ces MIC sont regroupés en " Faisceaux ". Un faisceau correspond à une destination (route) vers un commutateur distant. On appelle donc connexion l'ensemble des faisceaux et des MIC. La traduction comprend une logique qui permet d'aiguiller un appel de son entrée dans le commutateur à sa sortie. Elle permet de déterminer un routage en consultant des tables d'indicatifs (renfermant les indicatifs de destination des appels téléphoniques), des tables d'acheminement (indiquant le chemin pour acheminer les appels téléphoniques) et des tables de faisceaux (indiquant les faisceaux pris en compte pour un appel téléphonique donné). Pour ce faire la traduction utilise la signalisation qui correspond à tous les messages et paramètres autres que la voix (transmission de la numérotation, décrochage, raccrochage, messagerie...). 2812995 Les données relatives aux connexions et à la traduction permettent au serveur d'élaborer des interfaces graphiques qui sont mises à jour en temps réel. De préférence ces interfaces sont visualisées sur des terminaux distants reliés au serveur. Un utilisateur peut émettre une requête vers le serveur qui la convertit en un ordre de commande compréhensible par le commutateur puis transmet cet ordre vers le terminal de commande. Avantageusement, le serveur réalise une interprétation de commande en transformant le signal provenant d'une interface graphique en un ordre de commande compréhensible par le commutateur. Ce signal peut être un clic d'une souris ou encore une syntaxe de commande en langage naturel ou proche du langage humain. Selon un mode de mise en oeuvre de l'invention, les interfaces graphiques comprennent des premières interfaces graphiques dédiées à une supervision technique du commutateur, et des secondes interfaces graphiques dédiées à l'optimisation du routage dans le commutateur pour une gestion de routage de moindre coût Les premières interfaces graphiques permettent de superviser graphiquement, en temps réel, les données du commutateur ou d'un réseau de commutateurs: des données statiques sur les connexions et la traduction; des données dynamiques sur des alarmes, sur l'évolution du trafic et du routage commercial. Pour ce faire, le serveur comprend des moyens de modélisation graphique du fonctionnement d'un commutateur ou d'un réseau de commutateurs. Ces premières interfaces sont plus particulièrement destinées aux techniciens. La modélisation graphique permet également de faire de la simulation et de visualiser l'état de fonctionnement d'un commutateur à un temps donné du passé, présent ou futur. -6- 2812995 Les secondes interfaces, plus particulièrement destinées à des services commerciaux, permettent de réaliser la fonction de routage à moindre coût, soit "Least Cost Routing", procurant des fonctions de programmation et de supervision du routage. Le paramétrage du routage est tel que les utilisateurs sont guidés dans la manipulation de ces interfaces, et les données purement liées aux techniques des télécommunications leur sont masquées. On libère ainsi les utilisateurs non techniciens des tâches répétitives et manuelles, ce qui contribue à réduire significativement les taux d'erreur et permet aux utilisateurs d'évoluer et de se concentrer sur des aspects stratégiques de leur métier. Avec ces secondes interfaces graphiques, les utilisateurs commerciaux peuvent saisir des données relatives à la qualité d'un faisceau reliant le commutateur, ces données provenant principalement de la clientèle alors que jusqu'à présent seules des alarmes électroniques scrutant le réseau déterminaient la qualité d'un réseau. Ces interfaces graphiques dédiées à l'optimisation du routage sont ainsi conçues pour transmettre vers le serveur des informations relatives à la qualité du routage du commutateur. Selon une caractéristique avantageuse de l'invention, le serveur comprend en outre des algorithmes de calcul pour déterminer des ordres de commande du commutateur en prenant en compte des modélisations graphiques et des informations provenant desdites interfaces graphiques dédiées à l'optimisation du routage. Les algorithmes de calcul établissent donc un lien entre, d'une part, des données provenant des interfaces dédiées aux techniciens et, d'autre part, des -7- 2812995 données provenant des interfaces dédiées aux fonctions commerciales. Le résultat d'un algorithme est ensuite interprété dans un langage de commande du commutateur. De préférence, les algorithmes sont paramétrés, ce qui permet d'envisager par exemple plusieurs plans de réalisation du routage à moindre coût en favorisant telle ou telle donnée. Suivant un autre aspect de l'invention, il est proposé un procédé pour gérer au moins un commutateur d'un opérateur de télécommunication, ce commutateur étant pourvu d'un terminal de commande, ce procédé étant mis en oeuvre dans un système selon l'invention. Le procédé de gestion selon l'invention comprend: - sur un site de gestion, - une collecte des données de commutation au sein dudit terminal de commande, via au moins un réseau de communication, - un stockage de ces données de commutation au sein d'une base de données, - un traitement de ces données collectées et stockées en vue d'élaborer une pluralité d'interfaces graphiques représentant le fonctionnement dudit commutateur; et - sur en au moins un site client connecté au site de gestion via au moins un réseau de communication, - une visualisation d'au moins une desdites interfaces graphiques, et - une émission de requêtes de commande formulées par un utilisateur à destination du terminal de commande. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés donnés à titre d'exemples non limitatifs: -8- 2812995 - la figure 1 est un schéma de l'architecture matérielle de technologie client-serveur d'un système de gestion selon l'invention; et - la figure 2 est un schéma de l'architecture logicielle d'un système de gestion selon l'invention. On considère tout d'abord, en référence à la figure 1, un ensemble de commutateurs 1 à 3 commandés chacun par un terminal de commande 4, 5, 6. Le terminal 4 est par exemple relié à un réseau informatique de communication local "LAN" 10 (Local Area Network), tandis que les terminaux de commande distants 5, 6 sont connectés au moyen d'un routeur 7 à un réseau informatique de communication de type "WAN" 8 auquel le réseau local 10 est connecté au moyen d'un routeur 9. Un serveur de gestion 11 est relié aux terminaux de commande 4 à 6 au moyen des réseaux "LAN" 10 et "WAN" 8. Ce serveur de gestion comprend une application client- serveur, multi-processeurs, construite autour d'une base de données d'objets C++. Les applications clientes sont logées dans des terminaux distants 12 à 18 reliés au serveur de gestion via le réseau "LAN" 10. Une base de données des objets C++ est établie à partir des données récupérées dans les terminaux de commande 4-6 à travers les réseaux "LAN" 10 et "WAN" 8. Ces terminaux de commande 4-6 comprennent chacun une application cliente fonctionnelle afin d'assurer la communication entre le serveur 11 et des applications de commande logées dans ces terminaux de commande. Les applications de commande permettent de commander les commutateurs 1 à 3. D'une façon générale, ces applications de commandes peuvent être des applications originelles fournies par le fabricant des commutateurs, et l'application client-serveur selon la présente -9- 2812995 invention vient se greffer sur ces applications de commande afin d'optimiser la gestion des commutateurs. L'application serveur contenue dans le serveur 11 permet le paramétrage des applications clientes, la création et la mise à jour de données relatives aux commutateurs ainsi que la gestion des sauvegardes. Les applications clientes comprennent des interfaces graphiques que l'on peut classer en deux parties: des interfaces graphiques techniques et des interfaces graphiques commerciales. Les interfaces techniques permettent de superviser graphiquement, en temps réel, les données de l'ensemble des commutateurs, une supervision dite "Network Operations Center" en langue anglaise. Ces données sont des données statiques (connexions, traduction, type de signalisation...) et des données dynamiques (alarmes, évolution du trafic et du routage commercial..). La gestion de ces données est accessible à travers les interfaces techniques disposées dans des terminaux de gestion 12 à 16. L'interface I12 proposée sur le terminal de gestion 12 est une interface de supervision du réseau, ayant des fonctions de visualisation, de consultation et d'action. Au moyen d'un référentiel graphique interactif, l'utilisateur navigue à travers les connexions (opérateurs, faisceaux, routes, MIC...) ou les traductions (analyse et protocole de type sous-système n 7) de chaque commutateur. Une hiérarchisation des données, simple et logique, permet d'accéder rapidement à l'information recherchée. Cette hiérarchisation est construite sous un modèle de télécommunication n'impliquant pas la connaissance du type de commutateur. Des alarmes concernant l'exploitation apparaissent directement, par -10- 2812995 code de couleurs, sur une vue graphique du réseau de commutateurs. Il est ainsi possible de naviguer jusqu'à l' élément incrimine. Différentes fonctions de recherche permettent graphiquement et spontanément de suivre le cheminement d'un type d'appel (indicatif -> faisceaux -> MIC). L'historique daté et identifié (par exemple en archivant le nom du poste utilisateur ayant effectué la modification) de toute commande passée sur le réseau (par le système ou en direct sur l'OMC qui est espionné) sous forme d'ordre de travaux, de billets d'incidents ou de commandes spontanées garantit une visibilité au niveau de l'ingénierie. Toutes les commandes simples d'exploitation sont disponibles. Elles sont exécutées sous formes d'ordres de travaux datés (exécution immédiate possible). L'ordre de travail est alors archivé et activé à la date renseignée. Son exécution est alors soit manuelle (une alarme indique au technicien qu'il doit effectuer la modification), soit semi-automatique (la modification est exécutée, une alarme indiquant au technicien de valider l'exécution de la commande) ou soit automatique (la modification est exécutée automatiquement, le rapport d'exécution s'inscrivant en historique). Un tableau de gestion des alarmes permet également de les acquitter, de les corriger, ou d'effectuer une investigation. Suivant le type d'alarme, une procédure automatique ou manuelle permet soit de traiter l'alarme, soit de la porter à un niveau supérieur avec un dossier de diagnostic. Deux autres interfaces I13 et I14 respectivement d'ingénierie et d'interprétation des commandes peuvent être associées à cette interface I12 sur un même terminal ou disposées sur des terminaux indépendants comme dans la -11- 2812995 suite. L'interface I13 est une interface d'ingénierie permettant de suivre l'évolution et le dimensionnement du réseau au cours du temps. Elle permet également de se projeter dans l'avenir en programmant un certain nombre d'opérations d'ingénierie du réseau. Elle présente des fonctions de visualisation, de consultation, et d'action. Le réseau ou chaque commutateur à un instant t (passé, présent ou futur). En saisissant une date, une vue graphique représente l'état du réseau jusqu'à cette date, puis l'état du réseau après cette date. Cet état correspond aux opérations programmées par une équipe d'ingénierie. Il est possible de consulter toutes les données (connexions, traduction, trafic, incidents...) associées à cette vue et correspondant à la date saisie. Une base d'archives permet de consulter toutes les opérations passées ou futures effectuées sur chaque commutateur. La programmation de réalisations d'ingénierie (comme par exemple l'extension ou la création de capacités au niveau des connexions) est réalisée sous forme d'ordres de travaux qui sont activés manuellement, ou automatiquement à la date prévue. Le paramétrage des éléments de connexions ou de traduction du commutateur, réalisé à ce niveau par des experts en ingénierie, permet lors de l'exploitation une utilisation plus conviviale. De plus, il sécurise l'homogénéité des composantes du réseau et diminue le taux d'erreurs de paramétrages, sources de nombreux problèmes difficilement identifiables par la suite. L'interface I14 est une interface d'interprétation de commandes accordant aux exploitants une souplesse et une sécurité dans l'utilisation des commandes et ayant des -12- 2812995 fonctions de visualisation, de consultation et d'action. Les principales opérations à effectuer sur le réseau sont répertoriées dans une bibliothèque de commandes. Elles sont généralement graphiquement programmées par l'utilisateur. Ainsi, l'utilisateur ne se préoccupe pas du langage propriétaire du commutateur, ni de la hiérarchisation des données. L'utilisateur possède en outre une assistance au niveau des paramètres des commandes, pré-enregistrés par des experts par rapport à la configuration du réseau. Une aide en ligne ainsi que des exemples complètent le support. Par ailleurs, il est possible de compléter la bibliothèque d'opérations en y ajoutant des séquences personnalisées. A titre d'exemple, on peut encore associer à l'interface I12 une interface d'atelier de paramétrage du routage pour donner la possibilité à un exploitant de contrôler l'affectation de ses ressources de traduction tout en garantissant par exemple une gestion dynamique et automatique du routage. Il existent deux principes de paramétrages du routage, les tables d'acheminement dynamiques et les tables d'acheminement statiques. Le choix de l'un ou l'autre est obtenu par observation de la destination. Une utilisation mesurée des deux principes garantie l'optimisation du système. La gestion statique des acheminements correspond à affecter à une destination (équivalent à un ensemble d'indicatifs) un acheminement fixe fonctionnant en partage de charges ou en débordements en cascades. Cette gestion convient aux destinations ayant beaucoup d'indicatifs, ce qui permet en cas de changement de routage d'effectuer une modification de faisceaux au niveau de l'acheminement au lieu d'une modification d'acheminement au niveau des -13- 2812995 indicatifs. Le nombre d'indicatifs par destination peut être visualisé dans un tableau de contrôle afin que l'utilisateur puisse choisir les destinations à programmer en statique ainsi que le numéro d'acheminement fixe (on peut choisir plusieurs acheminements pour une même destination si l'on désire différencier les origines du trafic). La gestion dynamique des acheminements dépend fortement du nombre d'acheminements que l'utilisateur alloue à cette gestion. La programmation des tables dynamiques permet la création ou la suppression de quelques acheminements. Il est possible à ce niveau de préciser un intervalle de numéros d'acheminements correspondant à des critères d'opérateurs (par le biais des faisceaux), de formats nationaux ou internationaux, de traducteurs, de signalisations... Cet atelier permet le paramétrage entre opérateurs et faisceaux. Pour chaque opérateur et faisceau sortant, on peut paramétrer les différentes caractéristiques des acheminements terminaux. On prend en compte la gestion des formats par destination (national ou international) ainsi que la gestion du nombre de chiffres du code pays des destinations si nécessaire. L'interface I15 est une interface de supervision du trafic comportant des fonctions de visualisation, consultation et d'action. L'ensemble des faisceaux d'un commutateur est représenté graphiquement. Toutes les observations de compteurs, d'indicateurs calculés de trafic sont mis à jour en temps réel sur ce graphique. Des indicateurs de base interprètent sous forme de tableaux et graphiques les fluctuations du trafic. Une base d'archives permet de consulter a posteriori toutes -14- 2812995 ces données. Des calculs évaluent la capacité du réseau. Croisés avec des simulations d'augmentation de charge, ces calculs permettent d'ajuster le dimensionnement en fournissant des statistiques de besoins de liens supplémentaires. Une animation graphique permet dans un intervalle de temps donné, de visualiser au cours du temps l'évolution de la charge des faisceaux. Deux autres interfaces I16 et I17 peuvent être associées à cette interface de supervision du trafic I15 sur un même terminal ou disposées sur des terminaux indépendants comme dans la suite. L'interface I16 est une interface de gestion des alarmes comportant des fonctions de programmation, de visualisation et d'action. Par type de jours et tranches horaires spécifiques, des alarmes de trafic (à titre d'information pour l'utilisateur) sont programmées en fonction d'un certain seuil de remplissage des faisceaux ou des groupes de faisceaux. Par exemple, si le vendredi entre 15 H 00 et 16 H 00, il y a X Erlans sur l'ensemble des faisceaux de l'opérateur Y, on place une alarme à 60 %. Lorsque la date et l'heure arrivent, si le trafic sur ces faisceaux n'est que de X/2 Erlans, alors l'alarme se déclenchera, à charge pour le technicien superviseur d'identifier cette baisse de trafic (qui peut être d'ailleurs naturelle). Il est à noter que ces alarmes ne sont pas des indicateurs de dysfonctionnement. Le déclenchement des alarmes est interactif graphiquement sur les interfaces de supervision du trafic. Il apparaît également au niveau d'un tableau de bord principal. L'interface 17 est une interface de configuration et -15- 2812995 d'analyse comportant des fonctions de visualisation et d'action. On retrouve la vue graphique des interfaces de supervision du trafic, avec une répartition différente des faisceaux, correspondant aux associations effectuées. Tous les compteurs sont alors cumulés pour afficher des sommes ou des moyennes. Les indicateurs de trafic sont consultés à travers des tableaux ou graphiques. La programmation de nouveaux indicateurs à partir des compteurs et formules mathématiques rend l'application évolutive. Ces interfaces graphiques techniques I12 à I17 sont complétées par des interfaces graphiques commerciales I18 à I20 qui permettent de réaliser un routage à moindre coût LCR, "Least Cost Routing". Pour réaliser un routage à moindre coût, on affiche les traducteurs (tables d'analyses ou d'indicatifs) nationaux et internationaux sous un modèle commercial à base de destinations et de catégories (pays, régions, villes, mobiles...). Pour chaque destination, on saisit ensuite des tarifs. Puis on calcul en temps réel le meilleur routage possible pour chaque destination en prenant en compte à titre d'exemples non limitatifs les paramètres suivants: tarifs:- 24 tranches horaires - 8 types de jours ( jours de la semaine + un jour férié) - trafic d'origine - 3 tarifs sur volumes - le crédit temps - format de transport (voix ou 64 Kbit/s) - qualité de la destination par opérateur, - capacité ou saturation par opérateur. -16- 2812995 A chaque modification de ces paramètres, on calcule à nouveau le routage optimal. Ce routage calculé est un routage théorique. Le plan de routage réel (plan effectif sur le commutateur) est égal au plan de routage théorique avec des changements de routages demandés par un service client suite à une mauvaise qualité de la destination. Il est important de noter que le service client peut directement et rapidement agir sur la modification du routage réel. La différence entre les deux plans respectivement théorique et réel représente le facteur de qualité d'une destination pour un opérateur donné. Ce facteur de qualité est par défaut prioritaire sur le facteur de rentabilité (exprimé par les tarifs). Ce choix est paramétrable. Une supervision temps réel des routages permet de garantir la qualité et la rentabilité du réseau. A chaque billet ou requête de modification de routage émis par le service client pour des raisons de qualité de service, on recalcule le routage le plus rentable. Cette fonction de routage à moindre coût LCR fait intervenir une première interface I18 de saisie des tarifs ayant des fonctions de visualisation et d'action. L'interface de saisie des tarifs est un ensemble de grilles associant les destinations aux différents opérateurs. On change de grille en modifiant la tranche horaire, le type de jour ou le trafic d'origine. Suivant le mot de passe entré à la connexion de cette interface, il est possible de visualiser ou de modifier ces tarifs. La fonction de routage à moindre coût LCR concerne également une seconde interface I19 de gestion du routage -17- 2812995 ayant des fonctions de visualisation, de préparation de plans tarifaires, de programmation d'un calendrier de routage, de simulation, d'activation du calendrier et de mise en oeuvre d'algorithmes de calcul du routage. Cette interface I19 comporte ainsi une visualisation sous forme d'arborescence des tables d'indicatifs d'un commutateur donné afin d'effectuer une hiérarchisation des destinations commerciales (pays, régions, villes, mobiles...). Pour des plans tarifaires, différentes grilles tarifaires, en fonction des tranches horaires et des types de jours, peuvent par exemple être automatiquement transposées en listesd'opérateurs (du meilleur choix au plus mauvais choix) d'un commutateur concerné. Le plan de routage calculé par le serveur propose par exemple une disposition de débordements en cascade des opérateurs, du plus rentable au moins rentable, c'est-à-dire que tout le trafic d'une destination est routé par un opérateur 1 (le plus rentable). En cas de saturation de cet opérateur le trafic sera routé par un opérateur 2 (le plus rentable après 1). En cas de saturation de cet opérateur 2, on prévoit le débordement sur un 3ème opérateur correspondant à une route de grande capacité et de bonne qualité, mais généralement de prix élevé. Cette transposition automatique est calculée en fonction de paramètres sélectionnés tels que la qualité, des volumes, ou un crédit temps. Un deuxième calcul, répondant à des contraintes de capacité par opérateur et par destination est alors possible en faisant intervenir des matrices complexes. Ces opérations sont réalisées automatiquement et systématiquement pour chaque plan tarifaire (couple type de jours / tranche horaire). On peut ainsi traiter, -18- 2812995 à titre d'exemple non limitatif, 192 plans tarifaires standards possibles. Par défaut, on considère qu'une destination fonctionne sous le principe " débordement en cascade ", mais il est possible de transformer son fonctionnement sous le principe de " répartition de charge ". Ce principe de " répartition de charge " consiste à affecter plusieurs opérateurs à pourcentages de charges différents pour la même destination. Le trafic sera alors aiguillé en fonction des pourcentages définis par opérateur. L'utilisateur peut également sélectionner le type d'acheminement à utiliser. Ce principe est géré au niveau de la destination, ce qui permet pour un même plan tarifaire de disposer de destinations statiques ou dynamiques gérées en " débordement en cascade " ou en " répartition de charge ". Pour chaque commutateur, deux calendriers (national et international) hebdomadaires à précision horaire sont programmés. Des modifications de routage sont effectuées automatiquement en rapport à ces calendriers. On affecte graphiquement, pour chaque type de jours et pour chaque tranche horaire, un plan de routage standard. Par exemple, pour un site donné, on affecte la grille tarifaire " Lundi 13H00 " du Lundi 13H00 au Lundi 17H00 à partir de laquelle on affecte la grille tarifaire " Lundi 17H00 " jusqu'à 24H00. Par défaut la grille tarifaire valide est " Lundi 00H00 ". Cette organisation entre le calendrier et des différents plans fournit à l'utilisateur la possibilité de gérer le routage de chaque commutateur en fonction de l'heure. Un calendrier annuel est également disponible pour pouvoir saisir le type de jours de chaque date (intéressant pour les jours fériés). - 19- 2812995 Une simulation permet ensuite d'évaluer techniquement la réalisation du calendrier. Elle renseigne pour chaque changement de grille, en fonction du nombre de destinations incriminées, et du nombre d'indicatifs par destination, le temps d'exécution des modifications. Si ce temps d'exécution est supérieur à la tranche allouée pour le changement, la modification est refusée. En pratique, si par exemple un changement demandé à 13H00 met 1 heure 30 minutes à s'exécuter complètement (ce temps dépend uniquement de la vitesse d'exécution des commandes sur le commutateur), un autre changement n'est pas possible avant 15H00. Le système possède deux types de calendriers. Les calendriers " actifs " sont utilisés pour gérer les routages en cours. Les calendriers " préparatoires " sont utilisés par l'interface 19 de gestion du routage pour programmer les nouveaux routages. A l'initiative des utilisateurs un basculement des calendriers permet d'effectuer un changement de programmation de routage. Les calendriers " préparatoires " deviennent ensuite " actifs ". Cette opération intervient par exemple au quart d'heure de l'heure suivante pour laisser le temps au système de préparer son nouveau routage qui ne sera mis en place que l'heure suivante. Une interface de simulation de surcoût permet d'observer en terme de coûts et de ressources systèmes, les conséquences d'un plan tarifaire (jour / heure / origine). Avant chaque changement de plan tarifaire, (changements automatiques en fonction de l'heure système), le serveur transforme le routage théorique en des fichiers de commandes du commutateur qui seront exécutées lors du changement horaire. Le principe est de traduire le choix théorique de chaque destination en -20- 2812995 paramètres techniques permettant la préparation d'algorithmes de calculs ou macro-commandes de changement de routage. Ces algorithmes de calculs, par défaut, mettent en oeuvre des tables d'acheminements en cascades ou multiples suivant les destinations. Le dispositif optimise la composition de ces tables pour garantir la rentabilité du routage demandé en fonction aux limites imposées (nombre d'acheminements maximum). L'interface d'ingénierie permet de personnaliser les algorithmes de calculs pour chaque destination, et de respecter les contraintes d'affectations et de nomenclatures des acheminements. Une simulation permet d'associer chaque destination dynamique valide à une combinaison qui sera ensuite traduite en valeurs techniques respectant l'architecture logicielle du commutateur, une combinaison étant le regroupement de toutes les destinations possédant les mêmes critères. Ces critères sont le choix des opérateurs, le format par opérateur (national ou international), le nombre de chiffres du code pays (ce paramètre est facultatif, il est activé au niveau de l'interface de l'atelier de paramétrage du routage). Au cours de la simulation, un débordement en cascade est mis en place avec deux premiers opérateurs. Un acheminement assure le troisième choix. Cet acheminement est un partage de charge entre opérateurs bénéficiant de capacité et de qualité. Le format d'une combinaison peut présenté de la manière suivante: - opérateur 1 - opérateur 2 - format national ou international - nombre de chiffres du code pays (1,2,3 si -21- 2812995 activé; 0 sinon) - liste de destinations associées - somme des volumes des destinations associées. On associe donc par destination, deux combinaisons. La première nommée principale représente le choix technique mis en place. La deuxième nommée secondaire intervient à l'issue d'un premier débordement. La somme des combinaisons principales et secondaires forment les besoins pour programmer le routage idéal. Il faut comparer ces besoins aux ressources définies par l'utilisateur. La liste de combinaisons principales est ensuite triée par volumes décroissants. Elle est modifiée jusqu'à ce que le nombre de besoins soit égal aux ressources. Dans tous les cas le ler choix d'opérateur est toujours servis. Dans le cas o le nombre de combinaisons secondaires est supérieur aux ressources, le routage ne peut pas être optimisé d'avantage. Dans ce cas l'optimisation détruira complètement la liste de combinaisons principales. Pour respecter absolument les ressources, il faut modifier la répartition des opérateurs de certaines destinations au niveau du plan débordement en cascades. C'est une des fonctions de la simulation, car elle permet d'observer la répartition des combinaisons, l'impact de leur modification sous l'aspect technique (ressources et besoins) et financier (coût supérieur par rapport à la situation idéal si débordement). En effet lorsqu'une combinaison est détruite (dans le cadre de l'optimisation par rapport aux ressources systèmes), les destinations qui la composaient sont réparties dans d'autres combinaisons (en respectant toujours le 1er choix). Lors de cette recomposition, l'opérateur de débordement (2ème choix) peut être modifié en entraînant un surcoût. Ce surcoût est affiché par -22- 2812995 destination, ainsi qu'au niveau d'un compteur général. La fonction de routage à moindre coût LCR met aussi en oeuvre une interface I20 supervision du routage ayant des fonctions de visualisation, de consultation et d'action. Des cartes géographiques colorées représentent la répartition des routages théoriques et réels par destination et par opérateur au cours du temps. Des calendriers permettent de visualiser la répartition des différents plans de routages théoriques au cours du temps. Des fonctions graphiques facilitent les consultations et permettent d'effectuer graphiquement des comparaisons, des statistiques mettant en avant la qualité de chaque destination. Des tableaux généraux ou par destination donnent également un suivi quotidien de la répartition des routages et un calcul des coûts (vente / achat). Dans le cas o le routage réel n'est pas le plus rentable, il affiche également les pertes par rapport au routage optimal. Cette interface I20 est dédiée au service client, qui, sur plainte de la mauvaise qualité d'une destination desservie par un opérateur, a tous les éléments en main pour ordonner la modification du routage. Une simulation de comparaison de coût et délais d'implémentation est disponible avant l'envoi d'un billet ou requête qui sera automatiquement, semi - automatiquement ou manuellement traité. Cette fonction LCR peut aussi comporter d'autres fonctionnalités telles qu'une fonctionnalité multi- commutateurs (" multi-switch ") permettant de prendre en compte le calcul tarifaire du meilleur chemin de routage d'une destination. Elle compare, à partir d'un premier -23- 2812995 commutateur, le prix de la desserte de la destination via un opérateur tiers connecté à ce premier commutateur au prix du routage de cette même destination à partir d'un second commutateur du réseau. On peut aussi envisager une fonctionnalité de "Capacité" permettant, par des calculs matriciels complexes, d'optimiser au mieux l'élaboration des plans de routages, ou encore une fonctionnalité de "Saturation" permettant de basculer automatiquement le routage des destinations lorsqu'un lien vers un opérateur est sur le point de saturer. Sur la figure 2, est représentée l'architecture logicielle d'un système de gestion selon l'invention avec des interfaces graphiques clientes disposées pour une part dans des terminaux 21 à 23 dédiés à un service technique, et pour une autre part dans des terminaux 24 et 25 dédiés à un service commercial. Les interfaces graphiques techniques concernent la modélisation 26 de l'état de fonctionnement d'un commutateur 30, alors que les interfaces graphiques commerciales concernent des données 27 pour la mise en euvre d'un routage à moindre coût (LCR). Des algorithmes de calcul 28 permettent au serveur, à partir des éléments de la modélisation 26 et des données LCR 27, d'établir des données de commutation ou de commande 29 du commutateur 30. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. En particulier, le système de gestion selon l'invention peut être avantageusement mis en oeuvre pour la mise en place d'une bourse des télécommunications. -24- 2812995 REVENDICATIONS 1. Système pour gérer au moins un commutateur (1, 2, 3) d'un opérateur de télécommunication, ce commutateur étant pourvu d'un terminal de commande (4, 5, 6), caractérisé en ce qu'il comprend: - un serveur de gestion (11) connecté via au moins un réseau de communication (10, 9, 8, 7) au terminal de commande (4, 5, 6) et comprenant: - des moyens pour collecter des données de commutation au sein dudit terminal de commande(4, , 6), - des moyens pour stocker ces données de commutation au sein d'une base de données, - des moyens pour traiter ces données collectées et stockées en vue d'élaborer une pluralité d'interfaces graphiques représentant le fonctionnement dudit commutateur; et - au moins un terminal client (12,... ,20) connecté au serveur de gestion (11) via au moins un réseau de communication (10) et agencé pour visualiser au moins une des dites interfaces graphiques et pour émettre des requêtes de commande formulées par un utilisateur. 2. Système selon la revendication 1, caractérisé en ce que le serveur de gestion (11) comprend en outre des moyens pour mettre à jour de façon périodique la base de données en fonction de données de commutation collectées au sein du terminal de commande (4, 5, 6). 3. Système selon l'une des revendications 1 ou 2, caractérisé en ce que le serveur de gestion comprend en -25- 2812995 outre des moyens de mise en temps réel des interfaces graphiques en fonction des modifications des données de la base de données. 4. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de gestion comprend en outre des moyens pour transmettre vers le terminal de commande des ordres de commande du commutateur. 5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de gestion comprend en outre des moyens pour convertir des requêtes émises par le terminal client en des ordres de commande compréhensibles par le commutateur. 6. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de gestion élabore des interfaces graphiques (21, 22, 23) dédiées à une supervision technique du commutateur (30). 7. Système selon la revendication 6, caractérisé en ce que le serveur comprend des moyens de modélisation graphique (26) du fonctionnement d'un commutateur (30), ladite modélisation fournissant des interfaces graphiques dédiées à une supervision technique (21, 22, 23). 8. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de gestion élabore des interfaces graphiques (24, 25) dédiées à l'optimisation du routage dans un commutateur (30) pour une gestion de routage de moindre coût. -26- 2812995 9. Système selon la revendication 8, caractérisé en ce que ces interfaces graphiques dédiées à l'optimisation du routage sont aptes à transmettre vers le serveur des informations (27) relatives à la qualité du routage du commutateur. 10. Système selon l'une des revendications 8 ou 9, caractérisé en ce que le serveur comprend des algorithmes de calcul (28) pour déterminer des ordres de commande (29) du commutateur (30) en prenant en compte des modélisations graphiques (26) et des informations (27) provenant desdites interfaces graphiques dédiées à l'optimisation du routage (24, 25). 11. Système selon la revendication 10, caractérisé en ce que les algorithmes de calcul (28) sont paramétrables. 12 Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur est apte à récupérer et traiter des données d'une pluralité de commutateurs d'un opérateur de télécommunication. 13. Procédé pour gérer au moins un commutateur (1, 2, 3) d'un opérateur de télécommunication, ce commutateur étant pourvu d'un terminal de commande (4, 5, 6), mis en oeuvre dans un système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend: - sur un site de gestion, une collecte des données de commutation au sein dudit terminal de commande, via au moins un réseau de communication, - un stockage de ces données de commutation au sein d'une base de données, -27- 2812995 - un traitement de ces données collectées et stockées en vue d'élaborer une pluralité d'interfaces graphiques représentant le fonctionnement dudit commutateur; et - sur au moins un site client (12,..., 20) connecté au site de gestion via au moins un réseau de communication (10), - une visualisation d'au moins une desdites interfaces graphiques, et - une émission de requêtes de commande formulées par un utilisateur à destination du terminal de commande. 14. Procédé selon la revendication 13, caractérisé en ce qu'il comprend en outre une mise à jour périodique de la base de données en fonction de données de commutation collectées au sein du terminal de commande. 15. Procédé selon l'une des revendications 13 ou 14, caractérisé en ce qu'il comprend en outre une mise en temps réel des interfaces graphiques en fonction des modifications des données de la base de données. 16. Procédé selon l'une quelconque des revendications 13 à 15, caractérisé en ce qu'il comprend en outre une conversion de requêtes émises par un terminal client (12,...,20) en des ordres de commande compréhensibles par le commutateur. 17. Procédé selon l'une quelconque des revendications 13 à 16, caractérisé en ce qu'il comprend en outre une élaboration d'interfaces graphiques (21, 22, 23) dédiées à une supervision technique du commutateur. -28- 2812995 18. Procédé selon l'une quelconque des revendications 13 à 17, caractérisé en ce qu'il comprend en outre une modélisation graphique (26) du fonctionnement d'un commutateur (30), ladite modélisation fournissant des interfaces graphiques (21, 22, 23) dédiées à une supervision technique. 19. Procédé selon l'une quelconque des revendications 13 à 18, caractérisé en ce qu'il comprend en outre une élaboration d'interfaces graphiques (24, 25) dédiées à l'optimisation du routage dans un commutateur (30) pour une gestion de routage de moindre coût. 20. Procédé selon l'une quelconque des revendications 13 à 19, caractérisé en ce qu'il comprend en outre une détermination d'ordres de commande (29) du commutateur (30) en prenant en compte des modélisations graphiques (26) et des informations (27) provenant des interfaces graphiques (24, 25) dédiées à l'optimisation du routage. 21. Procédé selon l'une quelconque des revendications 13 à 20, caractérisé en ce qu'il est mis en oeuvre pour la gestion d'une pluralité de commutateurs d'un opérateur de télécommunication.