Brevet FR2802745A1 — publié le 20010622

Poste d'aide au paramétrage d'un réseau de télécommunications L'invention concerne le déploiement et la maintenance des réseaux de télécommunications. On sait que tout appel d'un numéro, par exemple téléphonique, est d'abord transmis à une station proche, qui se charge ensuite, en général par différentes stations relais, de le faire aboutir à son destinataire. La station proche et les stations relais sont dénommées ici génériquement "autocommutateurs". Les exploitants ont la charge d'optimiser et de sécuriser le réseau en fonction du trafic attendu, qui varie notamment de façon saisonnière. Ceci implique de modifier le "paramétrage" des autocommutateurs, comme on le verra. Avant de valider un nouveau paramétrage, on le teste au moyen d'une plate-forme d'aide au paramétrage d'un réseau de télécommunications. Celle-ci se fonde sur des machines du réseau, en service dans le réseau lui-même et/ou regroupées dans un réseau auxiliaire dédié au test. Cette façon de faire des tests réels est considérée comme sûre, quant aux résultats obtenus. En contrepartie, elle implique un matériel de test imposant. Le matériel requis est moins important dans le cas où les paramètres des machines sont modifiés dans le réseau réel, mais il existe alors un risque substantiel de perturber celui-ci. La présente invention vient améliorer la situation. Elle part d'un poste d'aide au paramétrage d'un réseau de télécommunications . Le mot "poste", au lieu de "plate-forme" , reflète que ce poste peut être implanté sur un ordinateur personnel ou une station de travail. De façon connue, ce poste comprend des moyens de test prévus pour déterminer le comportement de machines interconnectées du réseau, en fonction du paramétrage de ces machines, à partir d'au moins un jeu d'essai pour le paramétrage. Le jeu d'essai est d'éléments que l'on appellera ici "informations d'appel", ou "énoncé d'appel", ces expressions couvrant à la fois les données nécessaires à l'analyse de la numérotation et celles qui servent au routage d'un appel, et ce à toute phase du traitement d'un appel. Selon l'invention, les moyens de test, installés dans l'ordinateur, comprennent: - une pluralité de modules noeuds de base, dont chacun possède, au moins, une fonction externe de traitement d'appel, et des fonctions internes, aptes à coopérer avec la fonction externe pour donner un énoncé d'appel de sortie avec un identifiant de route future, en réponse à un énoncé d'appel d'entrée, - un module de réseau apte à faire circuler, parmi les modules de base, des versions successives d'un énoncé d'appel initial, en fonction des identifiants de route future et de données de topologie du réseau, jusqu'à satisfaire une condition choisie (condition de fin), et - un module superviseur, capable d'exciter sélectivement le module de réseau par des énoncés d'appel initiaux choisis. Selon un aspect intéressant de l'invention, il est prévu un module noeud générique, offrant des méthodes publiques de création d'instances et de traitement d'appel, et apte à loger des attributs, ainsi que des méthodes privées; les modules de base sont tirés du module noeud générique, aptes à mettre en oeuvre des expressions respectives des méthodes privées; la méthode publique de traitement d'appel est prévue pour recevoir un énoncé d'appel d'entrée, et pour retourner d'une part un énoncé d'appel de sortie, avec au moins un identifiant de route future, tirés de l'énoncé d'entrée par des méthodes privées choisies; les modules noeuds de base sont tirés du module noeud générique ; se distinguent par le fait qu'ils mettent en oeuvre des expressions respectives des méthodes privées. Selon un autre aspect avantageux de l'invention, le module noeud générique offre en outre une méthode publique de chargement de données paramètres, et en ce que lesdites expressions des méthodes privées sont fonction de ces données paramètres. De préférence, le dispositif comprend en outre des modules de conversion des commandes de paramétrage exprimées dans des langages propres aux machines en un langage commun. Dans un mode de réalisation intéressant, les modules de conversion comprennent des fichiers de format de commande, un lecteur de format et un lecteur de fichier de commande. Plus précisément encore, le langage commun est défini par un objet commande instanciable. Selon encore un autre aspect avantageux de l'invention, il est prévu un fichier de configuration du réseau, avec lequel coopère le module de réseau, ce fichier comprenant des données de topologie du réseau, y compris, pour chaque noeud, au moins un attribut correspondant de langage et format de paramétrage. De préférence, les données de topologie du réseau comprennent aussi, pour chaque noeud, l'identification de ses voies d'entrée et de sortie, et en ce qu'il est prévu séparément une description des liens entre ces voies d'entrée et de sortie. Ainsi, chacun des modules de base peut simuler ou "émuler" la totalité ou la quasi totalité des réactions de tout autocommutateur particulier du réseau. Et l'essai du nouveau paramétrage s'effectue totalement "hors réseau". D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : - la figure 1 est une représentation schématique des interconnexions de communication (voix, données, notamment) d'un réseau de télécommunications commuté, avec son réseau parallèle de signalisation; - la figure 2 illustre schématiquement les techniques de test mises en oeuvre jusqu'à présent; - la figure 3 illustre comparativement les éléments généraux de la technique de test selon l'invention; - la figure 4 est un schéma synoptique du système de test selon l'invention; - les figures 5 à 7 sont trois schémas procéduraux de la technique mise en oeuvre selon l'invention ; -les figures 8 et 9 illustrent deux variantes de traitement. En outre, on trouvera en fin de description: - en Annexe 1, la liste des paramètres d'un "énoncé d'appel", - en Annexe 2, la structure des objets utilisés selon l'invention, - en Annexe 3 des exemples de fichiers d'entrées, et - en Annexe 4 des exemples de traitement. Les annexes et les dessins contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant. La figure 1 cherche à illustrer les différents cas de figure rencontrés dans le réseau. Les références X1 à X7 représentent des autocommutateurs, dont le nombre de connexions est réduit, pour simplifier. Les références XlO à X13 représentent des autocommutateurs plus gros, du réseau dit de transit. La référence XT1 désigne une passerelle internationale (ou autre opérateur tiers). La figure montre que tous ces éléments sont interconnectés entre eux, et avec des postes XS1 à XS3 du réseau de signalisation SIG, également dénommé "réseau sémaphore" (illustré en trait tireté court). L'autocommutateur X1 est relié notamment à un contrôleur (BSC) de stations de téléphonie mobile XZ1, susceptible de travailler avec des stations de base (BTS) pour le raccordement de téléphones mobiles, telles que XM1 et XM2 . L' auto- commutateur X6 est relié notamment à une boucle locale qui va vers des abonnés, tel XA1, et un PABX, tel XB1. L'autocommutateur X7 et X2 travaille notamment, via le réseau sémaphore, avec des bases de données d'abonnés mobiles (HLR), notées XY11 et XY12. De même, via le poste XS1, les autocom- mutateurs ont accès à des système de réseau "intelligent" (IN, pour "intelligent network"), notés XY21 et XY22. On peut ainsi prévoir des points de contrôle de service (SCP pour "Service Control Point"), qui abritent des fonctions de contrôle de service (SCF pour "Service Control Functions"), ou des points de commutation de service (SSP pour "Service Switching Point"), notamment. On appelle ici "machine" tout organe du réseau intervenant dans le traitement d'appels (analyse de la numérotation + routage), notamment les autocommutateurs, PABX, HLR et SCP. Toute machine est un élément du réseau NE ("Network Element"). On appelle "routage réel" une transition de NE à NE à travers le réseau de trafic, et "routage virtuel" une transition de NE à NE à travers le réseau sémaphore. Par "paramétrage" des machines, on entend notamment les règles selon lesquelles une machine donnée va transférer un appel à une autre machine. Ces règles sont inscrites par des commandes (notées RHM, pour Relations Homme Machine) dans chaque machine. La syntaxe et la sémantique du langage de commande dépendent des choix technologiques faits par le fabricant de la machine. Par ailleurs, le routage peut être réel, correspondant à un passage physique, par un faisceau, d'une machine à une autre, ou virtuel, correspondant alors à une adresse dans le réseau sémaphore. Avant de mettre en oeuvre une modification du paramétrage, il convient de la tester en profondeur, car une grande prudence est requise : modification du paramétrage peut en effet induire de graves perturbations. On sait utiliser à cet effet (figure 2) une plate-forme d'aide au paramétrage d'un réseau de télécommunications, qui comprend d'abord une mémoire 110 d'au moins une pluralité de numéros d'appel, formant jeu d'essai pour le paramétrage (en fait une base de données). Les nouveaux paramètres à tester sont également mis en mémoire en 100, en correspondance de la topologie des autocommutateurs du réseau. Le système 150 effectue les tests : - soit par appel des machines du réseau elles-mêmes, dans un mode maintenance, où on leur indique les paramètres modifiés avec le numéro d'appel en cours, tandis que le résultat est recueilli par le système de test, et collationné en 190. Cette façon de faire des tests réels est considérée comme sûre, quant aux résultats obtenus. En contrepartie, elle implique un matériel de test imposant, et de plus, un certain risque de perturber le réseau réel. Les paramétrages spécifiques aux tests doivent par ailleurs n'introduire aucun conflit avec le fonctionnement opérationnel, ce qui peut restreindre l'éventail des test réalisables. - soit en recourant à un groupe de machines représentatives du réseau, formant un réseau de test, opérant pour le reste dans les mêmes conditions que ci-dessus. Ce procédé est assez sûr quant aux résultats obtenus, dans la mesure où le réseau de test est représentatif. Il n'implique pas de surcharge du réseau. Par contre, le réseau de test implique un investissement supplémentaire considérable et immobilisé. Le système selon l'invention (Figure 3) opère différemment. Les mémorisations faites en 200 et 210 sont réalisées à l'aide de fichiers aménagés. En outre, une mémorisation dans un autre fichier aménagé est faite en 220, pour définir complètement la topologie du réseau. Ensuite, la Demanderesse a trouvé le moyen de faire les tests à l'aide d'un ordinateur du type ordinateur personnel, ou mieux station de travail 250, qui donne les résultats en 290 sans aucune sollicitation de machines réelles. Les avantages sont considérables. On décrira maintenant comment cette solution est élaborée. La Demanderesse s'est intéressée aux informations d'appel, ou "énoncé d'appel". Celui-ci représente, avec l'indication du faisceau d'entrée, l'ensemble des informations requises pour traiter et acheminer un appel dans chacune des machines du réseau. Certaines de ces informations, notamment le numéro demandé, sont véhiculées de machine en machine par le réseau sémaphore, lors du trajet de l'appel dans le réseau ; nes autres informations sont déduites localement au niveau de la machine selon son paramétrage, ainsi que l'identité du faisceau d'entrée. Chacune des machines utilise les données de l'énoncé d'appel qu'elle reçoit pour traiter l'appel, et effectue les modifications convenables avant d'acheminer l'appel vers la machine occupant le noeud suivant du réseau sur le trajet de l'appel. On trouvera en Annexe 1 la liste des paramètres faisant partie de l'énoncé d'appel. Tous ne sont pas forcément utilisés lors de l'acheminement d'un appel. Certains, comme CDN, NUMTYPE ou ORIG, peuvent être modifiés, au cours des différentes phases d'un appel, même au sein d'une même machine. On peut aussi modifier le numéro lui-même pendant le traitement de l'appel : exemple, un numéro national d'urgence, comme le "18" pour les pompiers en France, est transformé en le numéro de la caserne de pompiers la plus proche. Le paramétrage des machines du réseau définit la manière dont elles répondent aux énoncés d'appel. Ce paramétrage est défini par des lignes de commande supportant ce paramétrage, pour chaque machine. Ces lignes de commande sont nommées ciaprès les RHM (relation homme-machine). Une commande RHM peut comprendre plusieurs lignes. Malgré la complexité du problème, la Demanderesse a pu construire un environnement logiciel du type à objets, permettant de traiter la quasi totalité des cas d'une façon standard. Les objets ou modules sont illustrés sur la Figure 4, qui en donne une vue d'ensemble, avec les relations d'héritage et de contenance de ces modules. Seront d'abord présentés les différents modules du simulateur, puis les fichiers servant en entrée du système (fichier de configuration et fichiers de paramétrage à appliquer aux machines occupant les noeuds du réseau). Dans ce qui suit, on appellera lecteur ou "parser", un objet ayant les fonctions de lire des fichiers spécifiques, de les analyser, et d'effectuer des actions qui permettent de connaître les informations contenues dans ces fichiers durant la simulation. Il s'agit en fait de créer un ensemble d'objets représentant les données contenues dans un fichier. De façon générale, les objets ont une méthode externe "new()", qui permet d'en créer des instances, et d'autres méthodes connues en langage objet, par exemple pour supprimer une instance précédemment créée. L'élément central est le noeud. L'objet (générique) Noeud 420 représente une machine du réseau. Sa structure est donnée en A2.4 dans l'annexe 2. Les méthodes publiques sont définies au niveau de l'objet noeud générique. Les attributs et les méthodes privées sont définies ou ajustées pour chacun des noeuds spécifiques, ou instances de noeud, tirées du noeud générique, qui, en outre, héritera des caractéristiques générales d'un noeud. Une instance de l'objet noeud va donc présenter les caractéristiques et les fonctionnalités spécifique d'un autocommutateur particulier. La partie spécifique du noeud aura 2 fonctions principales : - une première fonction interne ("premières méthodes privées"), pour la transformation de l'énoncé d'appel : conversion de la numérotation, changement d'origine, et autres opérations complémentaires, - une seconde fonction interne ("secondes méthodes privées") pour enregistrer des informations de routage : vers les prochains noeuds dans le référentiel interne à la machine (faisceaux). Ces deux fonctions correspondent aux résultats des phases de pré-analyse, analyse, acheminement dont le noeud a la charge, et sont donc totalement spécifiques à chaque équipement simulé. A titre d'exemple uniquement, la figure 4 montre en 420A, 420B, et 420C trois instances de noeud pour 3 machines de fournisseurs différents, fréquemment rencontrées en Europe (le principe étant applicable à d'autres machines). Chaque fournisseur possède son propre langage pour la définition du paramétrage de ses machines, le langage pouvant même varier d'un type de machine à un autre. Comme déjà indiqué, cette diversité des langages pose également problème. Elle porte en particulier sur les cas de routage et sur la définition des faisceaux. Selon un autre aspect de l'invention, la Demanderesse a préféré partir du langage des machines elles-mêmes, pour plus de sécurité. Les fichiers de RHM tel que 511A sont composés de commandes, et ces commandes sont accompagnées de leurs paramètres, un exemple de fichier RHM est donné en A3.3. Le format d'une ligne de RHM est donné en A3.2. Il est prévu un objet dit "Parser de Format" 520, dont la structure est donnée en A2. 8. Une ou plusieurs instances de cet objet (520A - 520C) sont utilisées par chaque noeud pour connaître le format des fichiers de RHM qui le paramètrent. Le parser de RHM 510, dont la structure est donnée en A2.6, a pour fonction de lire des fichiers de RHM et de créer les objets nécessaires à un noeud spécifique. C'est un parser générique car il est capable de traiter des fichiers de RHM ayant différents formats (autrement dit, les trois blocs 510A à 510C de la figure 4 représentent en fait le même parser). Le parser de RHM 510 utilise, pour interpréter correctement un fichier de RHM, un format dépendant lié au fournisseur de la machine, et ce format fait partie de la configuration du noeud. Une syntaxe de définition du format d'un RHM a donc été établie, par exemple comme "UNE~SYNTAXE" (annexe 3.2). Ainsi, à l'aide d'un parser de format qui lui est désigné, le parser de RHM 510A lit un fichier RHM, avec ses commandes accompagnées de leurs paramètres, et chaque commande donne lieu à la création d'un objet commande 530A (structure en A2. 7) ayant comme attributs ces paramètres. Les annexes A3.2 et A3.3 montrent comment une RHM est transformée en objet commande à partir d'un fichier de format. Le parser 510 ne traite pas la signification des commandes ; ne gère que la syntaxe. Seul le noeud qui recevra l'ensemble des commandes créées pour des RHM donnés, sera capable d'interpréter leur signification. Une instance de noeud peut ainsi lancer le parsing d'un ou plusieurs fichiers de RHM (c. f parser RHM), en paramétrant ce parsing à l'aide du format établi par le parser de format. Ceci fournit des objets commande accessibles au noeud, qui définissent un langage uniforme inter-machine, formant le "langage du réseau pour le test". L'objet Réseau 410 (structure en A2. 3) représente le réseau, qui est composé de noeuds 420, et de liens 430, les noeuds étant reliés entre eux par des liens. Ceci représente le maillage du réseau. L'objet Lien 430 (structure en A2. 5) correspond à la liaison entre deux machines, souvent nommée "faisceaux". Les deux attributs essentiels d'un lien sont du genre: * machine source, faisceau de sortie; * machine destination, faisceau d'entrée + marquage du faisceau indiquant le type d'origine. Le parser du fichier de configuration du réseau 560 est un objet permettant de lire un fichier 561 contenant la description du réseau et de sa topologie ou maillage, et d'autres informations, par exemple le code de pays ("country code"), avec un préfixe correspondant, comme "33" pour la France. L'objet Réseau 410 s'en sert pour créer une configuration du réseau représentée par un ensemble de noeuds reliés par des liens. Un exemple est donné en annexe A3.4. On notera que, pour chaque noeud, sont définis aussi de préférence le nom du fichier RHM associé, et le nom de sa syntaxe (fichier de format). Enfin, l'objet simulateur 400 (structure en A2. 1) est au sommet de l'arbre de contenance des objets. Il commande l'objet réseau 410, et offre une interface utilisateur de gestion des noeuds du réseau, afin de définir la topologie du réseau simulé et les types de machine (autocommutateurs) composant le réseau. Il peut utiliser un fichier de configuration de la simulation 502. Ce fichier contient des options de simulation. Le rôle opérationnel du simulateur 400 est de prendre des appels en entrée, de les donner au réseau simulé, puis de récupérer l'appel en sortie pour présenter les résultats obtenus à l'utilisateur. C'est ce que l'on appelle le traitement de l'objet appel (énoncé d'appel initial, c'est-àdire avec la route initiale). La structure de l'objet appel est donnée en Annexe A2.2. De plus, des possibilités de paramétrage (pendant la simulation) sont offertes (ex : modif ication du paramétrage d'un noeud), afin de permettre la gestion des divers amendements appliqués aux fichiers de paramètres. En sortie d'un noeud, l'objet Appel a été modifié, et contient des informations sur son routage à venir. Le réseau doit donc interpréter ces données et remettre l'objet appel au (x) prochain (s) noeuds, ou bien retourner l'appel au simulateur si les traitements sur l'appel sont terminés (l'appel est arrivé à destination). En sortie d'un noeud, un appel peut avoir plusieurs routes possibles, le réseau a donc la capacité de simuler l'ensemble des routes possibles pour un même appel. De plus, le réseau a aussi la charge de détecter les erreurs (boucle infinie par exemple). Les machines et les routes seront spécifiées dans un fichier de configuration du réseau. Ainsi, en principe, on prévoit une instanciation de noeud pour chacune des machines du réseau réel à traiter. Les paramètres de chaque machine sont modifiés en agissant sur le fichier de RHM (511) correspondant, ce qui modifiera l'objet commande 530 associé à la machine. En variante, l'utilisateur peut aussi ajouter des lignes RHM à la volée, à l'aide d'une interface graphique. Le système crée donc ainsi une image complète du réseau dans l'ordinateur 250. Une autre variante, de portée plus large, consisterait à ne créer une instance de noeud qu'au moment où il apparaît un appel qui la concerne. L'occupation mémoire et la rapidité seraient alors diminuées en même temps. Le parser d'appel 500 est un objet permettant de lire un fichier 501 contenant les appels qui vont transiter par le réseau. Il crée les objets (instanciation) Appel pour chaque appel contenu dans ce fichier. Le simulateur se chargera de router ces appels dans le réseau. L'objet Appel représente un appel à traiter par le simulateur. La définition des appels se trouve dans un fichier de simulation : le fichier des appels 501. La création des objets Appel sera effectuée par lecture et interprétation de ce fichier au moyen du parser d'appel 500. Un exemple est donné en annexe 3.1. De préférence, l'objet Appel contient aussi des paramètres (dynamiques) qui représentent son parcours dans le réseau, à savoir son parcours effectivement suivi, mais aussi son parcours à suivre (informations de routage). Ces attributs sont interprétables par le réseau pour le routage, et par le simulateur pour la présentation et l'analyse des résultats. L'Annexe 2 donne la structure, c'est-à-dire les attributs et les méthodes, des objets de base définis selon l'invention. L'annexe est restreinte aux méthodes principales de ces objets : par exemple, les erreurs sont gérées tant au niveau de chaque objet qu'au niveau général du simulateur ; relative importance du simulateur (en taille) impose un contrôle d'erreur à plusieurs niveaux. On exposera maintenant le processus de traitement d'un appel dans le réseau simulé sur ordinateur, selon l'invention, en référence aux figures 6 à 8. L'utilisateur a accès à tous les objets par une interface graphique. Au départ (Figure 5), le simulateur 1000 va : - en 1002, lire les appels dans le fichier d'appel. Il s'en sert pour créer une base d'objets appel (jeu d'essai). - en 1004, lire la topologie du réseau dans un fichier de configuration. Il s'en sert pour la création du réseau composé de noeuds et de liens entre ces noeuds. Le réseau simulé est alors défini en sa structure. Ensuite: - en 1010, on déclenche l'initialisation du réseau Chaque noeud charge ses fichiers de configuration. Le réseau simulé est prêt à fonctionner. Ensuite: - en 1020, on envoie chaque appel dans le réseau, - en 1050, on récupère chaque appel en sortie du réseau, - en 1052, on présente les résultats à l'opérateur. Le cas échéant, en 1060 on modifie l'état du réseau, notamment ses paramètres, et l'on revient en 1010, ou l'on stoppe (1100). Entre les étapes 1020 et 1050, le réseau va (figure 6): - en 1022, déterminer le prochain noeud d'entrée de l'appel (information contenue dans l'appel); en variante, le choix peut être donné à l'utilisateur, s'il y a plusieurs possibilités ; - en 1024, si l'appel sort du réseau, le rendre au simulateur ; - sinon, en 1030, donner l'appel à ce noeud; - en 1040, récupérer l'appel en sortie du noeud, avec analyse des résultats obtenus; - en 1045, si l'appel est arrivé à destination, passer à la fin 1050, qui redonne l'appel au simulateur ; retourner en 1022. Entre les étapes 1030 et 1040, le noeud va (figure 7): - en 1031, effectuer la phase de pré-analyse, - en 1032, effectuer la phase d'analyse, - en 1033, prendre différentes voies selon le résultat de l'analyse. Ces voies sont: - en 1033A, le cas où l'on se trouve en fin de sélection, avec une terminaison anormale, qui voudrait, en mode réel, que l'on transmette à l'usager un message pré-enregistré ("film"), et/ou un signal audible d'alerte, par exemple. Dans ce cas, l'étape 1034 retourne le code de fin de sélection, représentatif de l'anomalie. - en 1033B, le cas de fin normale d'acheminement, où l'on a atteint le poste ultime ("terminal") ou le PABX raccordé, l'appel étant arrivé à destination. Dans ce cas, l'étape 1035 retourne le code de fin ou "terminal". - en 1033C, le cas d'un "routage virtuel", c'est-à-dire qui va vers un appareil autre que les autocommutateurs, tel que les HLR ou SCP. Dans ce cas, l'étape 1036 retourne les informations d'appel, avec un identifiant de faisceau virtuel. - en 1033D, le cas d'un "routage normal", c'est-à-dire qui va vers un autre autocommutateur. Dans ce cas, l'étape 1037 définit l'acheminement, c'est-à-dire le choix du faisceau de sortie, et l'étape 1038 retourne les informations d'appel et l'identifiant du faisceau de sortie. - enfin, en 1033E, on peut effectuer un rebouclage sur l'étape d'analyse 1032, avec des informations d'appel modifiées. La pré-analyse est une phase préliminaire, qui peut être utilisée pour conditionner la phase suivante (analyse) en fonction des différents paramètres de l'énoncé d'appel. Les paramètres qui peuvent être pris en compte dans la préanalyse sont notamment l'origine de l'appel, le type de numérotation (national, international, spécial, ...), le profil d'abonné, le numéro de l'appelant, le type d'interface (par exemple: "INAP" pour "Intelligent Network Application Part" i.e. élément d'application pour réseau intelligent, ou encore "ISUP" pour "ISDN User Part", ce qui vise la partie utilisateur du réseau numérique à intégration de services ou "Integrated Service Digital Network"), ainsi que les données spécifiques à la gestion "IN". Là aussi, la nature et le codage de ces paramètres dépendent de la machine considérée. Le traitement réalisé en phase de préanalyse dépend lui aussi de la machine. Il consiste généralement en un aiguillage de l'appel vers différents traducteurs, avec éventuellement un préfixage du numéro appelé en fonction de l'origine, de sa longueur, des caractéristiques d'interface, notamment. Ceci est réalisé par un premier jeu de méthodes privées (ou "premières fonctions internes"), qui passent de l'énoncé d'entrée à un énoncé intermédiaire. Les différents aspects physiques pris en compte en préanalyse n'apparaissent plus en phase d'analyse. Typiquement, le traitement effectué en phase d'analyse consiste à analyser les premiers chiffres du numéro appelé (éventuellement modifié par la préanalyse), en fonction des différents plans de numérotage (numéros nationaux, internationaux, services privés, numéro d'urgence, notamment). Le résultat d'une analyse est un acheminement, c'est-à-dire une référence à la façon de traiter un appel et de le rentrer dans le réseau. Ceci est réalisé par un second jeu de méthodes privées (ou "secondes fonctions internes"). Les acheminements peuvent provoquer une retraduction du numéro (et retour en analyse), ou envoyer l'appel vers un faisceau ou groupe de faisceaux, ou encore appeler un élément de réseau IN. Autrement dit, les secondes fonctions internes passent de l'énoncé intermédiaire à un énoncé de sortie ou à un autre énoncé intermédiaire. L'invention permet une grande richesse dans la définition des phases de pré-analyse et d'analyse. Le but des trois phases successives (pré-analyse, analyse de la numérotation et acheminement) est de déterminer, en fonction de la numérotation et d'autres informations collectivement désignées ici par "Données d'Appel", l'acheminement de l'appel à effectuer. L'analyse de la numérotation s'effectue sur les chiffres de la numérotation reçue, de gauche à droite, ainsi que sur la longueur (le nombre de chiffres), en se basant sur un (des) ensemble (s) de données configurées appelé(s) Traducteur(s), introduit (s) dans l'autocommutateur via des RHM. L'analyse fournit en finale un identifiant de Destination, et d'autres données annexes concernant ou non l'acheminement, comme des indications de taxation, d'observation, par exemple. Dans un autocommutateur, il existe en fait plusieurs analyses différentes adaptées chacune à une circonstance précise. La Demanderesse a observé que le mécanisme de ces analyses est le même ; seules diffèrent les données configurées à prendre en compte. Selon l'organisation des données (dépendant du constructeur de l'autocommutateur), il est apparu que l'on se retrouve dans un des deux cas suivants : - Cas n 1 : Les données concernant les analyses sont structurées en de multiples traducteurs. A une analyse donnée est associé un traducteur d'origine, c'est à dire le traducteur par lequel il faut commencer à effectuer l'analyse de la numérotation pour cette analyse là. - Cas n 2 . Les données concernant les analyses sont dans un traducteur unique. Les séquences de chiffres concernant le début d'une analyse donnée sont toutes préfixées par un même préfixe, conventionnellement choisi. A une analyse donnée est donc associé un préfixe qu'il faut ajouter au préalable à la numérotation, avant analyse par le traducteur unique. La pré-analyse permet de déterminer précisément quelle est l'analyse à effectuer parmi plusieurs, en se basant sur des données de pré-analyse introduites dans l'autocommutateur sous forme de lignes de RHM. De façon non exhaustive, les données en entrée de la pré-analyse peuvent être le paramètre ORIGINE, qui reflète les circonstances dans lesquelles la numérotation a été reçue, le TYPE de la numérotation (National, International, Inconnu) ainsi que, dans certains cas, la numérotation elle-même (ou plutôt quelques uns des premiers chiffres de celle-ci). En sortie, et selon l'organisation des données décrite plus haut (Cas 1 ou 2), on obtient soit un identifiant de Traducteur (Cas 1), soit un préfixe à ajouter à la numérotation, préalablement à l'analyse (Cas 2). Ensuite, le routage consiste à choisir l'acheminement effectif à partir d'un identifiant de Destination. L'acheminement peut être de plusieurs natures différentes, par exemple, de manière non exhaustive : - acheminement vers un terminal (abonné ou autre) de l'autocommutateur; - acheminement vers une bande annonce ou une tonalité; - acheminement vers un autre autocommutateur (via un faisceau); - acheminement vers un système autre, par exemple un HLR ("Home Location Register") ou un SCP ("Service Control Point"). Contrairement aux précédents, ce type d'acheminement est "virtuel" car il n'implique pas encore de connexion effective de l'appel entrant avec la cible. Seule la signalisation est impliquée. Pour mieux percevoir les traitements internes qui composent le simulateur, on considérera maintenant des exemples simplifiés de ce que peuvent être les deux phases de préanalyse et d'analyse. Dans ces exemples, les RHM sont représentés dans un langage naturel fictif, pour faciliter la compréhension. Les fichiers RHM contiennent des lignes de RHM destinées à la pré-analyse. Bien entendu, toutes les RHM ne concernent pas forcément un appel donné. Un appel ne sera concerné par un RHM que si ses paramètres répondent à des conditions spécifiques, dénommées "CRITERE". La représentation concrète d'un CRITERE est un RHM contenant des paramètres qui vont être confrontés aux paramètres de l'appel par des expressions logiques. Le résultat de ces expressions logiques (vrai ou faux) déterminera si un appel est concerné par le critère. Dans le cas où l'appel est concerné par le critère de préanalyse, on appliquera une ou des transformations sur ses paramètres. L'annexe A4.1 comprend en A4.1.1 un jeu de lignes RHM d'un autocommutateur simplifié (fictif), et en A4.1.2 la traduction de ces lignes en objets commande (également simplifiés). Les lignes RHM de critère (ici RHM1 et RHM2) contiennent des critères à appliquer, et une ou plusieurs informations sur les manipulations à effectuer. Ces manipulations peuvent modifier non seulement l'état de l'appel, mais aussi l'état du simulateur lui même. On considère un énoncé d'appel initial ayant les paramètres donnés en A4.3. L'autocommutateur fictif compare cet énoncé d'appel aux critères contenus dans les objets commande. RHM1 sera rejeté car 123=123 est vrai mais pas PLMN=BSS. Par contre, RHM2 sera accepté car (123=123 et PLMN=PLMN) sont vrais tous deux. Dans ce cas, le champ action contenu dans RHM2 sera pris en compte pour l'énoncé d'appel considéré. Il renvoie à un autre RHM, ici le RHM3, par le paramètre "nom de l'action". L'énoncé d'appel va donc subir les transformations contenues dans le RHM3. On admet que le champ dicon = "+size" est interprété par l'autocommutateur fictif comme le rajout de la taille du numéro de l'appel, en tête de ce même numéro ("digit conversion"). En sortie du RHM3, l'énoncé d'appel devenu APPEL1A aura donc les nouveaux paramètres donnés en A4.1.5. Après une ou plusieurs interventions de ce genre (ou aucune, dans certains cas), l'énoncé d'appel est prêt pour l'analyse. Les fichiers RHM contiennent également des lignes de RHM destinées à l'analyse, comme RHM4 et RHM5 en A4.2.1 dans l'annexe 4. Le but de l'analyse est de rechercher une destination ("destination logique"). Les types de destination varient, et sont spécifiés eux aussi dans des lignes de RHM, telle RHM6 en A4.2.1. Comme pendant la phase de pré-analyse, un énoncé d'appel sera soumis à différents critères d'analyse, le but étant de déterminer les RHM qui vont concerner l'appel pour son routage futur. Le paramètre "dest" identifie une destination, dans le jeu de RHM. Il existera donc des routes liées ayant ce paramètre, et ayant d'autres paramètres spécifiant une destination physique. Ainsi, la RHM6 affecte le faisceau E90A à la destination logique 101. L'application des conditions se fait comme en pré-analyse. Le traitement d'analyse de l'énoncé d'appel APPEL1A va donc appliquer RHM5, qui vise RHM6, d'où un aiguillage vers le faisceau "E90A". Le processus donné en exemple peut se terminer à ce niveau, par la donnée de la numérotation transformée et du faisceau de sortie. Dans la réalité, bien d'autres critères peuvent être examinés (tels que vérification des droits de lancer cet appel, ou de recevoir cet appel, en fonction des caractéristiques de l'abonnement, notamment), avant que le traitement d'appel par le noeud considéré soit retourné au simulateur du réseau pour passage à la machine suivante. Dans un cas réel, les types de RHM sont nombreux pour une machine donnée ; chaque commande RHM peut faire intervenir plusieurs critères (de 1 à 20 environ) et/ou plusieurs actions. Les expressions logiques retenant un RHM, ou le rejetant pour un énoncé d'appel donné, sont donc diverses et leur complexité variée. Plus généralement, et non limitativement, on pourra prévoir: - des RHM de configuration des paramètres de la machine, - des RHM spécifiant le partage de charge entre destinations, - des RHM précisant des priorités entre les routes, - des RHM annulant d'autres RHM, par exemple. Une machine réelle intègre plusieurs milliers, voire plusieurs dizaines de milliers, de lignes de RHM, qui définissent de très nombreuses "premières fonctions internes" pour la pré-analyse, et "secondes fonctions internes" pour l'analyse, ainsi que d'autres informations, telles que: définition des faisceaux, gestion de la taxation, par exemple. Le simulateur objet de l'invention doit donc, pour simuler cette machine, faire de même. L'invention offre une solution avantageuse pour y arriver de façon satisfaisante, en évitant largement les risques d'erreurs liés à une telle complexité. La préanalyse n'est pas toujours effectuée. Ainsi, dans le cas d'un appel de téléphone mobile (figure 8), l'énoncé d'appel initial EA10 est transmis à une machine XXO du type MSC ("Mobile Switching Center"), qui interroge en EAU (routage virtuel) une base de données HLR notée XY99, reçoit en retour une réponse EA12, et s'en sert pour adresser l'appel EA19, à travers le réseau, à une autre station MSC notée XX9, par un routage réel. Dans le cas du réseau dit "intelligent" ou "IN" (figure 9), un appel initial (ou incident) EA20 arrive sur une machine XY90 (de type SSP). Celle-ci interroge en EA21 (routage virtuel) une machine XY92, du type SCP, qui donne en EA22 une réponse, laquelle est utilisée en EA25 pour un routage réel vers une autre machine SSP, notée XY95. En d'autres termes, le routage peut s'effectuer non seulement d'autocommutateur à autocommutateur, mais aussi par le fait qu'un autocommutateur donné interroge un système NE non raccordé au réseau de trafic (du type HLR ou SCP, notamment), afin d'effectuer ensuite une nouvelle phase de préanalyse, analyse, et la suite. On peut donc avoir notamment la séquence suivante: - autocommutateur A: préanalyse, analyse, routage virtuel vers une machine NE; - machine NE : consultation d'une base de données interne, re-routage virtuel vers l'autocommutateur A; - autocommutateur A, à nouveau : analyse, routage réel vers un autocommutateur B, et ainsi de suite. Le paramétrage de machines du genre HLR ou SCP peut être reproduit avantageusement par une base de données (non représentée), incorporée à l'ordinateur 250, plutôt que par des commandes, comme pour les autocommutateurs. Le système selon l'invention, que l'on peut appeler "simulateur" permet de déclarer un réseau de centres de commutation ("machines"), de le configurer avec les paramètres du réseau réel, d'étudier le parcours d'un jeu de cas d'appel, et de valider des évolutions de ce réseau. Tout ceci est fait simplement, et sans perturbation du réseau opérationnel réel. La technique selon l'invention présente un autre avantage important. Comme le rappelle l'annexe III, en A3.2 à A3.4, la décision de routage prise par un autocommutateur réel comporte un aspect statistique : un même but désiré (intermédiaire), une fraction des appels suivra une certaine route, une autre fraction suivra une autre route, et ainsi de suite ; en outre, des routages de secours sont prévus. Selon la technique antérieure, on ne pouvait que recevoir la décision de la machine, telle quelle. L'invention permet au contraire de gérer directement l'aspect statistique de la décision. Bien entendu, l'invention n'est pas limitée à la forme de réalisation décrite précédemment à titre d'exemple, et est susceptible de nombreuses variantes. Par exemple, si le nombre de langages n'est pas trop élevé, on peut envisager de fusionner le parser générique de RHM et les "n" parsers de format, ce qui donne "n" parsers de lecture directe de RHM pour en faire des objets commande. Sur un tout autre plan, il n'a pas été question ici de la constitution matérielle des faisceaux. Il est clair cependant que l'invention prend en compte ce facteur, au moins au niveau de la propension à choisir un faisceau plutôt qu'un autre, pour un appel donné. Les moyens essentiels sont ici les différents éléments, logiciels et fichiers, à charger dans l'ordinateur de simulation. Ceci s'étend à tout fichier de données utilisant quelque partie que ce soit de l'invention, notamment les fichiers 502,501, 561 et 521, ainsi que 511 (utilisé selon l'invention). L'invention couvre donc ces éléments logiciels, ensemble ou séparément, en particulier mais non exclusivement lorsqu'ils sont mis à disposition sous une forme lisible en machine. L'expression "forme lisible en machine" inclut les supports de stockage, notamment magnétiques ou optiques, aussi bien que tout moyen de transmission utilisant des signaux analogiques et/ou numériques. ANNEXE 1 - Paramètres descriptifs d'appel Al - paramètres testés - CDN (CalleD Number) Numéro appelé, généralement composé de digits de 0 à 9, mais pouvant aussi comporter des caractères alphanumériques - CGN (CallinG Number) Numéro de l'appelant, composé de digits de 0 à 9 - CC (Country Code) CC de l'appelant - IMSI (International Mobile Subscriber Identity) IMSI de l'appelant - LAC (Location Area Code) LAC de l'appelant - NUMTYPE (NUMber TYPE) Type de numérotation, qui peut prendre l'une des valeurs : . UKN (UnKNown) . NAT (NATional) . INT (INTernational), SPS (SPecial Service, PRV (PRiVate) ORIG (ORIGin) Origine à un moment donné de l'appel, qui peut prendre l'une des valeurs : . PSTN (Public Switched Telephone Network) - accès aux réseaux tiers) . TC (Transit Center - commutateur de transit du réseau considé- ré) . SC (Switching Center - commutateur du réseau considéré, hors commutateur de transit) . PLMN (autre commutateur du réseau - TC ou SC) . IN (Intelligent Network - plate-forme IN) . BSS (Base Station Subsystem - appel en provenance d'un mobile ou MOC pour "Mobile Originated Call") . TERM (TERMinal - dans le cas où le réseau considéré est un réseau fixe) . FW (ForWard - renvois d'appel) . GMSC~FW et VMSC-FW (Gateway/Visited Mobile-services Switching Center ForWard - renvois d'appel particularisés) . PABX (Private Automatic Branch eXchange) . MSRN (Mobile Station Roaming Number - le CDN est un MSRN) . HON (HandOver Number - le numéro est dédié au handover inter-MSC) . LOOP (boucle interne d'un commutateur) CALLTYPE Type d'appel qui peut prendre l'une des valeurs : . INC (INComing call), OUTG (OUTGoing call) . FW (ForWarded call) SUBPROF (SUBscribe PROFile) Profil d'abonné OSCC (Operator Spécifie Supplementary Service Code) Code utilisé dans le cadre de l'IN SSIND (Supplementary Service INDicator) Code utilisé dans le cadre de l'IN SCM (Sercice Class Mark) Code utilisé dans le cadre de l'IN SK (Service Key) Code utilisé dans le cadre de l'IN POSCC (POSition of CC) Position du CC dans le numéro CDN TRKGRP (TRunK GRouP) Faisceau utilisé NODE Libellé du noeud considéré DATE Date au formant mm/dd/yyyy pour laquelle la simulation est faite. Les fichiers de configuration utilisés pour la simulation sont en cohérence avec cette date. A.2 Paramètres générés mais non testés (sortie seulement) CHGIND (CHarGing INDicator) Information de taxation générée au cours des appels MCC (Mobile Country Code) Extrait de IMSI MNC (Mobile Network Code) Extrait de IMSI PARAM~x...x (PARAMeter~x...x) Paramètre spécifique aux machines, généré pour information ANNEXE 2 - Structure des objets A2.1 - Objet : Simulateur Attributs : - un parser d'appel, - un réseau Méthode publiques: - new (..): Le constructeur de l'objet, il prend un fichier de configuration contenant la description de la simulation particulière à faire. - Charge les~appels(..) : prend un fichier d'appel, lance le parsing de celui-ci, renvoie une structure contenant les appels. - go(..) : lance la simulation, pour les données effectivement chargées. - actualise(..) : modification des paramètres de simulation, (fonction liée à l'interface utilisateur) - affiche(..) : présentation des résultats A2.2 - Objet : Appel Attributs : - list~param : une structure contenant les paramètres et leurs valeurs : attributs construits dynamiquement. Méthodes publiques: - New(..) : prend en paramètres les données de l'énoncé d'appel, - Affich(..) : affiche l'appel à un instant donné, - méthode d'accès/modif. A2.3 - Objet : Réseau Attributs : - Attributs de paramétrage "détaillé" d'une simulation , - Un Parser du fichier de configuration du réseau, - Une structure contenant les noeuds, - Une structure contenant les liens, - Des attributs représentant le langage du réseau (son protocole inter-machine). Méthodes publiques: - new(..) : Le constructeur du réseau, il prend en paramètre la topologie du réseau, ainsi que le type de machine associé à chaque noeud. - init(..) : initialisation du réseau. - Ajouter~un~noeud(..), - Ajouter~un~lien(..), - Supprimer~un~noeud(..), - Supprimer un lien(..), - méthodes d'accès/modif. Méthodes privées : - Choisir~un~noeud(..) : Pour un appel donné en paramètre, cette méthode détermine le parcours à suivre pour celui-ci. - Traite~un~appel(..) : envoie un appel à un noeud A2. 4 - Objet : Noeud Attributs : - Nom : nom de la machine simulée, Palier : nom du palier fonctionnel (attribué par le vendeur d'équipement) de la machine simulée, - Des structures contenants l'ensemble des commandes contenues dans les RHM. Méthodes publiques: - new(..) : Le constructeur d'un noeud, il prend en paramètre le type de noeud, ex : SIEMENS SR6, SIEMENS SR7, SSP ALCATEL T23) et charge dynamiquement les méthodes spécifiques, de la machine correspondante, de traitement des appels. - charge~rhm : Permet de charger des RHM, dans la configuration du noeud : en paramètre les fichiers de RHM et leurs formats associés. - traite~appel(..) : prend en paramètre un appel (une référence), et une liste de fonctions spécifiques à appliquer, par exemple : analyse, et retourne l'appel modifié. - Affich(..) : affiche l'état d'un noeud à un instant donné. - Méthode d'accès. Méthodes privées: - Les méthodes liées aux phases de préanalyse, analyse, et acheminement, dont l'algorithmique est propre à la machine simulée. - Les méthodes spécifiques de traitement de la numérotation. A2.5 - Objet : Lien Attributs : - Machine source, faisceau de sortie, - Machine destination, faisceau d'entrée. - De plus, on définit un certain nombre de paramètres qui représentent l'état du lien, notamment " En fonction/ Hors fonction", etc. Méthodes publiques: - new(..) : Le constructeur du lien. - Méthode d'accès/modif. A2. 6 - Objet : Parser~de~RHM Attribut : - Une structure contenant les formats. Méthodes publiques: - new (..) : le constructeur d'un parser de RHM. Il prend en paramètre les fichiers de rhm et leurs formats respectifs. - parse(..) : lance le parsing des fichiers ; construit et retourne des structures contenant les objets Commande A2. 7 - Objet : Commande Attributs : - type : type de la commande, c. a.d sa sémantique interprétable par un noeud spécifique, - list~param : une structure contenant les paramètres et leurs valeurs correspondant à une RHM : construits dynamiquement. Méthodes publiques: - New(..) : prend en paramètre le type de l'objet, représentant sa sémantique qui sera interprétable par le simulateur, - Affich(..) : affiche la commande à un instant donné, - méthode d'accès/modif. A2.8 - Objet : Parser~de~format Attribut : - Une structure représentant le format lu. Méthodes publiques: - new (..) : le constructeur d'un parser de format. Il prend en paramètre les fichiers de format. - parse(..) : lance la lecture du fichier spécifiant le format. Annexe 3 - Exemples de fichiers d'entrées A3. 1 - Fichiers d'Appel : ' Abonnés fixes FT au format national (avec le préfixe 0) CALL : CDN = 0123456789, ORIG = BSS CALL : CDN = 0315678901, ORIG = BSS, SSIND = 244 ' Abonnés fixes FT au format international CALL: CDN =0033123456789, ORIG = BSS CALL : CDN =0033123456789, ORIG = BSS, SSIND = 244 CALL : CDN =0033123456789, ORIG = BSS, SSIND = 246 ' Numéro court de 3 à 6 chiffres - Test accès à service étranger ' accès à service Swiss Telecom CALL : CDN = 950, ORIG = BSS, IMSI = 22801 CALL : CDN = 7372, ORIG = BSS, IMSI =22801 Le mot clef de reconnaissance d'un appel est "CALL": le parsing de ce fichier provoquera la création de 7 instances de l'objet Appel ayant pour attribut les paramètres de la ligne d'appel. Exemple : INSTANCE1: attributs : IND=0123456789 = > numéro appelé Origine de l'appel : BSS origine de l'appel De préférence, un certain nombre de paramètres sont ajoutés dans l'appel pour sa gestion par le simulateur. Exemple : INSTANCE1: attribut : LIGNE = 2 = > position de l'appel dans le fichier pour les erreurs. A3.2 - Fichier FORMAT RHM Ce fichier précise le format d'un RHM. De manière simplifiée, une ligne de RHM représentant une commande ayant n paramètres à l'organisation suivante : [(param) (val) ]*n-1(param) (val) où début de la commande nom de la commande param value une affectation, étant l'opérateur d'affectation fin de commande, début des paramètres. le symbole de fin de ligne RHM, fin de commande séparateur de paramètre exemple : une RHM siemens :" " CRDPFCDAT : " = " " " : " , " Le fichier de format RHM doit donc contenir ces définitions (syntaxe et sémantique) . Dans un exemple simplifié : >UNE~SYNTAXE ACTION:CRDPFCACT:ACTION =77, PRIO = 3, DICON = Il 77 " d : A3.3 - Fichier de RHM Exemple de fichier : SIEMENS Le fichier de configuration donnant le format de RHM donne le type d'objet Commande a créer et les règles à vérifier : (présence de certain paramètres et vérification de leurs tailles); Exemple : le parser interprète la première ligne et instancie l'objet Commande : Commande! = > attribut: type=ACTION PRIO = 200 DICON=" +CO " ZONDAT=N ACTION = NATCO A3.4 - Fichier de configuration du réseau Le format du fichier de configuration du réseau peut être défini par le fait que, pour chaque machine, on déclare : NUMERO : Numéro de machine (numéro 1 réservé à la machine d'entrée des cas d'appels) NOM : nom de la machine OPERATEUR : nom de l'opérateur qui gère la machine PALIER : nom du palier RHM : nom du fichier de RHM, nom de sa syntaxe (l'ordre compte) RHM~ERREUR : nom du fichier d'erreur des RHM ACH : #cas de notre réseau N de faisceau de sortie = > N de machine, N de faisceau d'entrée N de faisceau de sortie = > N de machine, N de faisceau d'entrée # cas d un routage vers un réseau que 1 on ne gère pas N de faisceau de sortie = > others, nom de l'autre #cas d'erreur default= > type d'erreur FONCTION : fonction à exécuter par la machine OPTION : Liste d'option de simulation RESULTAT : nom du fichier de résultat de cette machine . On définit en outre un langage contenu dans l'appel, ce qui permet à l'objet réseau de prendre une décision quant au routage. Par exemple, si l'on a les cas de routage : ROUTE = NORMAL: (F1 ,45%) (F2,55%) SECOURS: (F3,25%) (F4,75%) ECHEC : (F5,100%) où ' F1,F2,F3,F4,F5' sont des faisceaux, chaque machine simulée traduit ces cas de routages dans ce langage pour que l'objet réseau route effectivement les cas d'appels. De plus, dans le cas où le routage est terminé (le numéro appelé appartient au central demandé = > BSC) ou erroné, l'appel contient de préférence des attributs tels que : TERMINE, ERREUR, etc. Ces attributs prennent comme valeur une explication textuelle fournie par la machine. Le champ OPERATEUR permet au simulateur de retrouver des paramètres dits "de transcodage", qui représentent des données spécifiques à un opérateur, par exemple "MNC". Ce qui suit est un exemple de fichier de configuration du réseau, pour 3 machines. NUMERO : 1 NOM : MSC~SIEMENS OPERATEUR : Un~Operateur PALIER : SR6 RHM : rhm~D6, syntaxel rhm~roaming~in, syntaxe2 Mnicl252.dg, syntaxe2 RHM~ERREUR : rhm~machinel.err ACH : 100A = > 2 , 200B 101B = > 3 , 100B 200A = > others, " CT FT de Trouville " default = > ERREUR-END FONCTION : pretrans, analyse, acheminement OPTION : all~result RESULTAT : machine1~compte~rendu.txt NUMERO : 2 NOM : CT-ALCATEL OPERATEUR : Un~Operateur PALIER : ZW345 RHM : rhmalcal, syntaxAlca2 RHM~ERREUR : rhm~machinel.err ACH : 200B = > others, " CT FT de Lutèce " default = > ERREUR-END FONCTION : all OPTION : all~result RESULTAT : machine2~compte~rendu.txt NUMERO : 3 NOM : MSC~SIEMENS OPERATEUR : Un~Operateur PALIER : SR7 RHM : rhm~D6, syntaxel rhm~roaming~in, syntaxe2 Mnicl252.dg, syntaxe2 RHM~ERREUR : rhm~machinel.err ACH : 100A = > 2 , 200B 101B = > 1 , 100B 200A = > others, " CT FT du Boucheauxnoix ' default = > ERREUR-END FONCTION : pretrans, analyse, acheminement OPTION : all result RESULTAT : machine3~compte~rendu.txt Annexe 4 - Exemples simplifiés de traitement A4. 1 - Exemple 1 - Pré-analyse A4.1.1 - lignes de RHM RHM1 = > critere~pre : NUM=123, ORIGINE=BSS, action=change~orig RHM2 => critere~pre : NUM=123, ORIGINE=PLMN, action=ajout taille RHM3 = > action : nom=ajout~taille, dicon= "+size" Les deux premiers RHM ont un paramètre "action" qui est un lien vers un autre RHM. Ainsi, il est possible d'avoir plusieurs liens de ce genre entre RHM. Le RHM3 pourrait lui aussi référencer un autre RHM. A4.1.2 - attributs des objets commande correspondants RHM1.CRITERE.NUM = 123 RHM1.CRITERE.ORIGINE = BSS RHM1.CRITERE.ACTION = change~ori RHM2. CRITERE. NUM = 123 RHM2.CRITERE.ORIGINE = PLMN RHM2.CRITERE.ACTION = ajout taille RHM3.ACTION.NOM = ajout~taille RHM3.ACTION.DICON = "+size" A4.1.3 - un appel à traiter Appell = > NUM=123, ORIGINE=PLMN A4.1.4 - conditions du test de pré-analyse APPEL. NUM = CRITERE.NUM APPEL.ORIGINE = CRITERE.ORIGINE A4.1.5 - appel après traitement par RHM3 AppellA = > NUM=3123, ORIGINE = PLMN A4.2 - Exemple 2 - Analyse A4.2.1 -lignes de RHM RHM4 = > critere~ana : NUM=3123, ORIGINE=BSS, dest=100 RHM5 = > critere~ana : NUM=3123, ORIGINE=PLMN, dest=101 RHM6 => route: dest=101, faisceau=E90A A4.2.2 - attributs des objets commande correspondants RHM4. CRITERE2. NUM = 3123 RHM4.CRITERE2.ORIGINE = BSS RHM4.CRITERE2.DEST = 100 RHM5.CRITERE2.NUM = 3123 RHM5.CRITERE2.0RIGINE = PLMN RHM5.CRITERE2.DEST = 101 RHM6. ROUTE.DEST = 101 RHM6.ROUTE.FAISCEAU = E90A Revendications 1. Dispositif formant poste d'aide au paramétrage d'un réseau de télécommunications, comprenant des moyens de test (150) prévus pour déterminer le comportement de machines interconnectées du réseau, en fonction du paramétrage (100) de ces machines, à partir d'au moins un ensemble d'énoncés d'appel, formant jeu d'essai pour le paramétrage (110), caractérisé en ce que les moyens de test, installés dans un ordinateur (250), comprennent: - un module noeud générique (420), offrant des méthodes publiques de création d'instances et de traitement d'appel, et apte à loger des attributs, ainsi que des méthodes privées, - la méthode publique de traitement d'appel étant prévue pour recevoir un énoncé d'appel d'entrée, et pour retourner un énoncé d'appel de sortie, avec au moins un identifiant de route, en appliquant des méthodes privées choisies à l'énoncé d'entrée, - une pluralité de modules de base (420A-420C), tirés du module noeud générique, aptes à mettre en oeuvre des expressions respectives des méthodes privées (200), - un module de réseau (410) apte à faire circuler, parmi les modules de base, des versions successives d'un énoncé d'appel initial, en fonction des identifiants de route future et de données de topologie du réseau (220), jusqu'à satisfaire une condition choisie, et - un module superviseur (400), capable d'exciter sélectivement le module de réseau par des énoncés d'appel initiaux choisis (210). 2. Dispositif selon la revendication 1, caractérisé en ce que le module noeud générique (420) offre en outre une méthode publique de chargement de données paramètres, et en ce que lesdites expressions des méthodes privées sont fonction de ces données paramètres. 3. Dispositif selon la revendication 2, caractérisé en ce qu'il comprend en outre des modules (510-511) de conversion des commandes de paramétrage exprimées dans des langages propres aux machines en un langage commun. 4. Dispositif selon la revendication 3, caractérisé en ce que les modules de conversion comprennent des fichiers de format de commande (521), un lecteur de format (520) et un lecteur (510) de fichier de commande (511). 5 . Dispositif selon la revendication 4, caractérisé en ce que les fichiers de format de commande (521) sont prévus pour couvrir les langages de commandes respectifs de différents fournisseurs de machines. 6. Dispositif selon l'une des revendications 3 à 5, caractérisé en ce que le langage commun est défini par un objet commande instanciable (530). 7. Dispositif selon l'une des revendications 1 à 6, caractérisé en ce qu'il est prévu un fichier de configuration du réseau (561), avec lequel coopère le module de réseau (410), ce fichier comprenant des données de topologie du réseau, y compris, pour chaque noeud, au moins un attribut correspondant de langage et format de paramétrage. 8. Dispositif selon la revendication 7, caractérisé en ce que les données de topologie du réseau comprennent aussi, pour chaque noeud, l'identification de ses voies d'entrée et de sortie, et en ce qu'il est prévu séparément une description des liens entre ces voies d'entrée et de sortie (430). 9. Dispositif selon l'une des revendications précédentes, caractérisé en ce que les méthodes privées définissent de premières fonctions internes correspondant à une phase de préanalyse, et de secondes fonctions internes correspondant à une phase d'analyse. 10. Dispositif selon l'une des revendications précédentes, caractérisé en ce que, pour certaines au moins des machines, et pour certains au moins des noeuds, l'identification des voies d'entrée et de sortie ainsi que la description des liens correspondent à un routage virtuel.