WO2001047189A1 - Station for helping to parameterize a telecommunications network - Google Patents

Abstract

In order to help parameterize a telecommunications network, it is necessary to determine the behavior of the machines that are interconnected in said network. The testing means are installed in a computer (250). A generic node module provides a public method of processing calls, for receiving an entry call statement and returning an exit call statement with at least one route identifier, while applying selected private methods to the entry call. Base modules that are capable of carrying out the respective expressions of the private methods (200) are drawn from said generic module. A network module circulates successive versions of an initial call statement among these base modules according to the future route identifiers and network topology data (220). A supervisor module selectively excites the network module with the selected initial call statements (210).

Description

Help station for setting up a telecommunications network

The invention relates to the deployment and maintenance of telecommunications networks.

It is known that any call from a number, for example a telephone number, is first transmitted to a nearby station, which is then responsible, generally by different relay stations, for getting it to its recipient. The near station and the relay stations are here called generically "automatic switches".

Operators are responsible for optimizing and securing the network according to the expected traffic, which varies notably seasonally. This implies modifying the "configuration" of the automatic switches, as we will see. Before validating a new configuration, it is tested by means of a platform to aid in the configuration of a telecommunications network. This is based on machines in the network, in service in the network itself and / or grouped in an auxiliary network dedicated to the test. This way of doing real tests is considered safe, as far as the results obtained are concerned. In return, it involves imposing test equipment.

The hardware required is less important if the parameters of the machines are modified in the real network, but there is then a substantial risk of disturbing it.

The present invention improves the situation.

It starts from an aid station for setting up a telecommunications network. The word "workstation", instead of "platform", reflects that this workstation can be installed on a personal computer or a workstation. In known manner, this station includes test means provided for determining the behavior of machines interconnected from the network, as a function of the configuration of these machines, from at least one test set for the configuration. The test game is elements that we will call here "call information", or "call statement", these expressions covering both the data necessary for the analysis of the dialing and those which are used for routing a call , and this at any phase of the processing of a call.

According to the invention, the test means, installed in

1 computer, include:

a plurality of basic node modules, each of which has, at least, an external call processing function, and internal functions, capable of cooperating with the external function to give an output call statement with an identifier of future route, in response to an input call statement, - a network module capable of circulating, among the basic modules, successive versions of an initial call statement, as a function of the future route identifiers and network topology data, until satisfying a chosen condition (end condition), and - a supervisor module, capable of selectively exciting the network module by selected initial call statements.

According to an interesting aspect of the invention, a generic node module is provided, offering public methods of creating instances and processing calls, and capable of accommodating attributes, as well as private methods; the basic modules are taken from the generic node module, capable of implementing respective expressions of the private methods; the public call processing method is intended to receive an entry call statement, and to return on the one hand an exit call statement, with at least one future route identifier, drawn from the statement entry by selected private methods; the basic node modules are taken from the generic node module; they are distinguished by the fact that they use respective expressions of the private methods.

According to another advantageous aspect of the invention, the generic node module also offers a public method of loading of parameter data, and in that said expressions of the private methods are a function of this parameter data. Preferably, the device also comprises modules for converting the configuration commands expressed in machine-specific languages into a common language. In an interesting embodiment, the conversion modules include command format files, a format reader and a command file reader. Even more precisely, the common language is defined by an instantiable command object.

According to yet another advantageous aspect of the invention, a network configuration file is provided, with which the network module cooperates, this file comprising network topology data, including, for each node, at least one attribute. language and configuration format correspondent. Preferably, the network topology data also includes, for each node, the identification of its input and output channels, and in that a description is provided separately of the links between these input and output channels. exit.

Thus, each of the basic modules can simulate or "emulate" all or almost all of the reactions of any particular automatic switch in the network. And the test of the new configuration is completely "off-grid".

Other characteristics and advantages of the invention will appear on examining the detailed description below, and the attached drawings in which:

- Figure 1 is a schematic representation of the communication interconnections (voice, data, in particular) of a switched telecommunications network, with its parallel signaling network; - Figure 2 schematically illustrates the test techniques implemented so far;

- Figure 3 illustrates comparatively the general elements of the test technique according to the invention; - Figure 4 is a block diagram of the test system according to the invention;

- Figures 5 to 7 are three procedural diagrams of the technique used according to the invention; and

- Figures 8 and 9 illustrate two variants of treatment.

In addition, we will find at the end of the description:

- in Annex 1, the list of parameters of a "call statement", - in Annex 2, the structure of the objects used according to

The invention,

- in Annex 3 examples of input files, and

- in Annex 4, examples of treatment.

The annexes and the drawings essentially contain elements of a certain nature. They can therefore not only serve to better understand the description, but also contribute to the definition of the invention, if necessary.

FIG. 1 seeks to illustrate the different scenarios encountered in the network. References XI to X7 represent automatic switches, the number of connections of which is reduced, for simplicity. The references X10 to X13 represent larger automatic exchanges, of the so-called transit network. The reference XT1 designates an international gateway (or other third-party operator). The figure shows that all these elements are interconnected with each other, and with stations XS1 to XS3 of the GIS signaling network, also called "signaling network" (illustrated in short dashed lines). The PABX XI is linked in particular to a controller (BSC) of mobile telephone stations XZ1, capable of working with base stations (BTS) for the connection of mobile telephones, such as XM1 and XM2. The PABX X6 is linked in particular to a local loop which goes to subscribers, such as XA1, and a PABX, such as XB1. The automatic switch X7 and X2 works in particular, via the signaling network, with mobile subscriber databases (HLR), denoted XY11 and XY12. Similarly, via the XS1 extension, the autocom- mutators have access to "intelligent network" (IN) systems, denoted XY21 and XY22. It is thus possible to provide service control points (SCP for "Service Control Point"), which house service control functions (SCF for "Service Control Functions"), or service switching points (SSP for "Service Switching Point "), in particular.

The term “machine” is used here to refer to any member of the network involved in the processing of calls (numbering analysis + routing), in particular automatic branch exchanges, PABX, HLR and SCP. Every machine is an element of the NE network ("Network Element"). We call "real routing" a transition from NE to NE through the traffic network, and "virtual routing" a transition from NE to NE through the signaling network. By "configuration" of the machines, we mean in particular the rules according to which a given machine will transfer a call to another machine. These rules are entered by commands (noted RHM, for Human Machine Relations) in each machine. The syntax and semantics of the command language depend on the technological choices made by the machine manufacturer.

Furthermore, the routing can be real, corresponding to a physical passage, by a beam, from one machine to another, or virtual, then corresponding to an address in the signaling network.

Before implementing a modification of the configuration, it should be tested in depth, because great care is required: any modification of the configuration can indeed cause serious disturbances.

It is known to use for this purpose (FIG. 2) a platform for assisting in the configuration of a telecommunications network, which first comprises a memory 110 of at least a plurality of call numbers, forming a set of test for configuration (actually a database). The new parameters to be tested are also stored in memory 100, corresponding to the network switch topology. System 150 performs the tests:

- either by calling the network machines themselves, in a maintenance mode, where they are informed of the parameters modified with the current call number, while the result is collected by the test system, and collated in 190. This way of doing real tests is considered safe, as far as the results obtained are concerned. In return, it involves imposing test equipment, and moreover, a certain risk of disturbing the real network. The test-specific settings must also not introduce any conflict with operational operation, which may limit the range of tests that can be performed.

- or by using a group of machines representative of the network, forming a test network, operating for the rest under the same conditions as above. This process is fairly safe as to the results obtained, as long as the test network is representative. It does not imply network overload. On the other hand, the test network involves a considerable additional and immobilized investment.

The system according to the invention (Figure 3) operates differently. The memorizations made in 200 and 210 are carried out using fitted files. In addition, a storage in another arranged file is made in 220, to completely define the network topology. Next, the Applicant has found a way to carry out the tests using a computer of the personal computer type, or better workstation 250, which gives the results in 290 without any solicitation of real machines. The benefits are considerable.

We will now describe how this solution is developed.

The Applicant is interested in call information, or "statement of appeal". This represents, with the indication of the input beam, all the information required to process and route a call in each of the machines on the network. Some of this information, including the requested number, is transmitted from machine to machine by the network semaphore, during the call route in the network; certain other information is deduced locally at the level of the machine according to its configuration, as well as the identity of the input beam. Each of the machines uses the call statement data it receives to process the call, and makes the appropriate changes before routing the call to the machine on the next network node on the route from call.

Appendix 1 lists the parameters that are part of the call statement. Not all are necessarily used during the routing of a call. Some, such as CDN, NUMTYPE or ORIG, can be modified, during the different phases of a call, even within the same machine. You can also change the number itself during call processing: for example, a national emergency number, such as "18" for firefighters in France, is transformed into the number of the most fire station close.

The configuration of the machines on the network defines how they respond to call statements. This configuration is defined by command lines supporting this configuration, for each machine. These command lines are hereinafter called the RHM (human-machine relationship). An RHM command can consist of several lines.

Despite the complexity of the problem, the Applicant has been able to construct an object-type software environment, making it possible to deal with almost all of the cases in a standard manner. The objects or modules are illustrated in Figure 4, which gives an overview, with the inheritance and capacity relationships of these modules.

The different modules of the simulator will first be presented, then the files used as input to the system (configuration file and configuration files to be applied to the machines occupying the nodes of the network). In what follows, we will call reader or "parser", an object having the functions to read specific files, to analyze them, and to carry out actions which make it possible to know the information contained in these files during the simulation. It is actually a matter of creating a set of objects representing the data contained in a file.

Generally, objects have an external method "new ()", which allows to create instances, and other known methods in object language, for example to delete a previously created instance.

The central element is the knot. The (generic) object Node 420 represents a machine on the network. Its structure is given in A2.4 in appendix 2. The public methods are defined at the level of the generic node object.

Private attributes and methods are defined or adjusted for each of the specific nodes, or node instances, taken from the generic node, which, in addition, will inherit the general characteristics of a node.

An instance of the node object will therefore present the specific characteristics and functionalities of a particular automatic switch. The specific part of the node will have 2 main functions:

- a first internal function ("first private methods"), for the transformation of the call statement: conversion of the numbering, change of origin, and other additional operations,

- a second internal function ("second private methods") to record routing information: links to the next nodes in the internal repository of the machine (beams).

These two functions correspond to the results of the pre-analysis, analysis and routing phases for which the node is responsible, and are therefore completely specific to each simulated device. By way of example only, FIG. 4 shows in 420A, 420B, and 420C three node instances for 3 machines from different suppliers, frequently encountered in Europe (the principle being applicable to other machines). Each supplier has its own language for defining the configuration of its machines, the language can even vary from one type of machine to another. As already indicated, this diversity of languages also poses a problem. It relates in particular to routing cases and to the definition of beams.

According to another aspect of the invention, the Applicant preferred to use the language of the machines themselves, for more security.

RHM files such as 511A are composed of commands, and these commands are accompanied by their parameters, an example of RHM file is given in A3.3.

The format of an RHM line is given in A3.2. An object called "Parser de Format" 520 is planned, the structure of which is given in A2.8. One or more instances of this object (520A - 520C) are used by each node to know the format of the RHM files which configure it.

The RHM 510 parser, the structure of which is given in A2.6, has the function of reading RHM files and creating the objects necessary for a specific node. It is a generic parser because it is able to process RHM files having different formats (in other words, the three blocks 510A to 510C in Figure 4 actually represent the same parser). The RHM 510 parser uses a dependent format linked to the machine supplier to correctly interpret an RHM file, and this format is part of the node configuration. A syntax for defining the format of an RHM has therefore been established, for example as "UNE_SYNTAXE" (appendix 3.2).

Thus, using a format parser designated for it, the RHM 510A parser reads an RHM file, with its commands accompanied by their parameters, and each command gives rise to the creation of a 530A command object (structure in A2.7) having these parameters as attributes. Appendices A3.2 and A3.3 show how an RHM is transformed into an order object from a format file. Parser 510 does not process the meaning of commands; it only handles syntax. Only the node which will receive all the commands created for given RHMs, will be able to interpret their meaning.

A node instance can thus launch the parsing of one or more RHM files (see parsing RHM), by configuring this parsing using the format established by the format parser. This provides command objects accessible to the node, which define a uniform inter-machine language, forming the "network language for the test".

The Network object 410 (structure in A2.3) represents the network, which is composed of nodes 420, and of links 430, the nodes being linked together by links. This represents the mesh of the network.

The Link 430 object (structure in A2.5) corresponds to the link between two machines, often called "beams". The two essential attributes of a link are like:

* source machine, output beam;

* destination machine, input beam + beam marking indicating the type of origin.

The parser of the network configuration file 560 is an object making it possible to read a file 561 containing the description of the network and its topology or mesh, and other information, for example the country code ("country code"), with a corresponding prefix, such as "33" for France. The Network object 410 uses it to create a configuration of the network represented by a set of nodes connected by links. An example is given in Appendix A3.4. It should be noted that, for each node, the name of the associated RHM file, and the name of its syntax (format file).

Finally, the simulator object 400 (structure in A2.1) is at the top of the object containment tree. It controls the network object 410, and offers a user interface for managing the nodes of the network, in order to define the topology of the simulated network and the types of machine (automatic switches) making up the network. It can use a 502 simulation configuration file. This file contains simulation options.

The operational role of the simulator 400 is to take incoming calls, give them to the simulated network, then retrieve the outgoing call to present the results obtained to the user. This is called the processing of the call object (initial call statement, that is to say with the initial route). The structure of the call object is given in Annex A2.2.

In addition, configuration possibilities (during the simulation) are offered (eg modification of the configuration of a node), in order to allow the management of the various amendments applied to the parameter files.

At the output of a node, the Call object has been modified, and contains information on its future routing. The network must therefore interpret this data and deliver the call object to the next node (s), or return the call to the simulator if the call processing has ended (the call has arrived at its destination).

At the output of a node, a call can have several possible routes, the network therefore has the capacity to simulate all the possible routes for the same call. In addition, the network is also responsible for detecting errors (infinite loop for example). Machines and routes will be specified in a network configuration file. Thus, in principle, a node instantiation is provided for each of the mac ines of the real network to be processed. The parameters of each machine are modified by acting on the corresponding RHM file (511), which will modify the command object 530 associated with the machine. Alternatively, the user can also add RHM lines on the fly, using a graphical interface. The system thus thus creates a complete image of the network in the computer 250. Another variant, of wider scope, would consist in creating an instance of node only when a call appears which concerns it. The memory occupation and the speed would then be reduced at the same time.

The call parser 500 is an object making it possible to read a file 501 containing the calls which will pass through the network. It creates the Call instantiation objects for each call contained in this file. The simulator will be responsible for routing these calls over the network.

The Call object represents a call to be processed by the simulator. The definition of the calls is found in a simulation file: the calls file 501. The creation of the Call objects will be carried out by reading and interpretation of this file by means of the call parser 500. An example is given in appendix 3.1.

Preferably, the Call object also contains (dynamic) parameters which represent its route in the network, namely its route actually followed, but also its route to be followed (routing information). These attributes can be interpreted by the network for routing, and by the simulator for the presentation and analysis of results.

Annex 2 gives the structure, that is to say the attributes and the methods, of the basic objects defined according to the invention. The appendix is restricted to the main methods of these objects: for example, errors are managed both at the level of each object and at the general level of the simulator; the the relative importance of the simulator (in size) requires error control at several levels.

From the above description, the invention can be defined as a method comprising the following steps:

- create and configure a plurality of basic modules 420A- 420C, representing individual machines of the network and drawn from a generic node module, - establish a network module 410 representing a simulated network comprising the basic modules and links between these modules basic, and

- Create a supervisor module 400, capable of selectively exciting the network module by selected initial call statements 210, these call statements containing at least information on the links to borrow between basic modules.

The process for processing a call in the computer simulated network according to the invention will now be explained, with reference to FIGS. 6 to 8.

The user has access to all objects through a graphical interface.

At the start (Figure 5), the simulator 1000 will:

- in 1002, read the calls in the call file.

He uses it to create a base of calling objects (test game).

- in 1004, read the network topology in a configuration file.

It uses it for the creation of the network made up of nodes and links between these nodes.

The simulated network is then defined in its structure. Then: - in 1010, the network initialization is triggered

Each node loads its configuration files.

The simulated network is ready to operate. Then:

- in 1020, we send each call in the network, - in 1050, we retrieve each call leaving the network,

- in 1052, the results are presented to the operator.

If necessary, in 1060, the state of the network is modified, in particular its parameters, and it is returned to 1010, where it is stopped (1100).

Between steps 1020 and 1050, the network goes (Figure 6):

- in 1022, determining the next call entry node (information contained in the call); alternatively, the choice can be given to the user, if there are several possibilities;

- in 1024, if the call leaves the network, return it to the simulator; - otherwise, in 1030, give the call to this node;

- in 1040, recover the call at the output of the node, with analysis of the results obtained;

- in 1045, if the call has arrived at destination, go to the end of 1050, which returns the call to the simulator; otherwise, return to 1022.

As a variant, the network is defined in its structure without being simulated. The process then includes the following steps:

- receive an entry call statement including routing information for a route to be performed,

- create an instance from a generic node module capable of simulating a machine, for example, corresponding to said routing information, and capable of receiving said call statement, - return an output call statement, with at minus a route identifier, applying to the input statement selected private methods,

-reiterate these steps in order to circulate among basic modules created during the interpretation of the routing information, successive versions of an initial call statement, as a function of future route and data identifiers network topology, until satisfying a selected condition. Between steps 1030 and 1040, the node goes (Figure 7):

- in 1031, carry out the pre-analysis phase,

- in 1032, perform the analysis phase, - in 1033, take different routes depending on the result of the analysis.

These pathways are:

- in 1033A, the case where one is at the end of the selection, with an abnormal termination, which would, in real mode, require that a pre-recorded message ("film") be transmitted to the user, and / or an audible alert signal, for example. In this case, step 1034 returns the selection completion code, representative of the anomaly. - in 1033B, the case of normal end of routing, where one reached the ultimate set ("terminal") or the connected PABX, the call having arrived at destination. In this case, step 1035 returns the end or "terminal" code.

- in 1033C, the case of a "virtual routing", that is to say which goes to a device other than the automatic exchanges, such as the HLR or SCP. In this case, step 1036 returns the call information, with a virtual beam identifier.

- in 1033D, the case of a "normal routing", that is to say which goes to another automatic branch exchange. In this case, step 1037 defines the routing, that is to say the choice of the output beam, and step 1038 returns the call information and the identifier of the output beam.

- Finally, in 1033E, it is possible to perform a loopback on the analysis step 1032, with modified call information. The pre-analysis is a preliminary phase, which can be used to condition the next phase (analysis) according to the different parameters of the call statement. The parameters which can be taken into account in the pre-analysis are in particular the origin of the call, the type of dialing (national, international, special, ...), the subscriber profile, the number of the caller, the type of interface (for example: "INAP" for "Intelligent Network Application Part" ie application element for intelligent network, or "ISUP" for "ISDN User Part", which targets the user part of the digital network to integration of services or "Integrated Service Digital Network"), as well as data specific to "IN" management. Here too, the nature and the coding of these parameters depend on the machine considered.

The processing performed in the pre-analysis phase also depends on the machine. It generally consists of switching the call to different translators, possibly with a prefixing of the number called depending on the origin, its length, interface characteristics, in particular. This is achieved by a first set of private methods (or "first internal functions"), which pass from the input statement to an intermediate statement.

The different physical aspects taken into account in pre-analysis no longer appear in the analysis phase. Typically, the processing carried out in the analysis phase consists in analyzing the first digits of the number called (possibly modified by the pre-analysis), according to the different numbering plans (national, international numbers, private services, emergency number, in particular) . The result of an analysis is a routing, that is to say a reference to how to handle a call and enter it into the network. This is achieved by a second set of private methods (or "second internal functions"). Routes can cause a number redirection (and return to analysis), or send the call to a beam or group of beams, or even call an IN network element. In other words, the second internal functions pass from the intermediate statement to an output statement or to another intermediate statement.

The invention allows a great wealth in the definition of the pre-analysis and analysis phases. The purpose of the three successive phases (pre-analysis, numbering analysis and routing) is to determine, depending on the numbering and other information collectively referred to here as "Call Data", the routing of the call to perform.

The analysis of the numbering is carried out on the digits of the received numbering, from left to right, as well as on the length (the number of digits), based on one (or more) set (s) of configured data called (s) Translator (s), introduced into the PABX via RHM. The analysis ultimately provides a Destination identifier, and other ancillary data concerning or not the routing, such as charging or observation indications, for example.

In a PABX, there are in fact several different analyzes, each adapted to a specific circumstance. The Applicant has observed that the mechanism of these analyzes is the same; only the configured data differ to take into account. Depending on the organization of the data (depending on the manufacturer of the PABX), it appeared that we are in one of the following two cases:

- Case 1: The data concerning the analyzes are structured in multiple translators. With a given analysis is associated an original translator, that is to say the translator by which one must begin to carry out the analysis of the numbering for this analysis there.

- Case n ° 2: The data concerning the analyzes are in a single translator. The sequences of numbers relating to the start of a given analysis are all prefixed by the same prefix, conventionally chosen. A given prefix is therefore associated with a prefix which must be added before the numbering, before analysis by the single translator. The pre-analysis makes it possible to determine precisely which analysis is to be carried out among several, based on pre-analysis data introduced into the automatic switch in the form of lines of RHM. In a non-exhaustive manner, the data entering the pre-analysis can be the ORIGIN parameter, which reflects the circumstances in which the numbering was received, the TYPE of the numbering (National, International, Unknown) as well as, in certain cases , the numbering itself (or rather some of the first digits of it). At the output, and according to the organization of the data described above (Case 1 or 2), one obtains either a Translator identifier (Case 1), or a prefix to be added to the numbering, before the analysis (Case 2) .

Then, the routing consists in choosing the effective routing from a Destination identifier. The routing can be of several different natures, for example, in a non-exhaustive manner: routing to a terminal (subscriber or other) of the PABX;

- routing to a trailer or a tone;

- routing to another automatic branch exchange (via a beam);

- routing to another system, for example an HLR ("Home Location Register") or an SCP ("Service Control

Point "). Unlike the previous ones, this type of routing is" virtual "because it does not yet imply an effective connection of the incoming call with the target. Only signaling is involved.

To better perceive the internal processes that make up the simulator, we will now consider simplified examples of what the two phases of pre-analysis and analysis can be. In these examples, the RHM are represented in a fictitious natural language, to facilitate understanding.

RHM files contain RHM lines for pre-analysis. Of course, not all RHMs concern necessarily a given call. A call will only be affected by an RHM if its parameters meet specific conditions, called "CRITERIA". The concrete representation of a CRITERION is an RHM containing parameters which will be compared with the parameters of the call by logical expressions. The result of these logical expressions (true or false) will determine whether a call is affected by the criterion. If the call is concerned with the pre-analysis criterion, one or more transformations will be applied to its parameters.

Appendix A4.1 includes in A4.1.1 a set of RHM lines of a simplified (fictitious) automatic branch exchange, and in A4.1.2 the translation of these lines into command objects (also simplified).

The RHM criteria lines (here RHM1 and RHM2) contain criteria to be applied, and one or more information on the manipulations to be carried out. These manipulations can modify not only the state of the call, but also the state of the simulator itself.

We consider an initial call statement having the parameters given in A4.3. The dummy exchange compares this call statement to the criteria contained in the command objects.

RHM1 will be rejected because 123 = 123 is true but not PLMN = BSS. On the other hand, RHM2 will be accepted because (123 = 123 and PLMN≈PLMN) are both true. In this case, the action field contained in RHM2 will be taken into account for the call statement considered. It refers to another RHM, here RHM3, by the parameter "name of the action".

The call statement will therefore undergo the transformations contained in RHM3. We admit that the field dicon = "+ size" is interpreted by the fictitious PABX as the addition of the size of the call number, at the head of this same number ("digit conversion"). At the end of RHM3, the call statement which has become APPEL1A will therefore have the new parameters given in A4.1.5. After one or more interventions of this kind (or none, in some cases), the statement of appeal is ready for analysis.

RHM files also contain lines of RHM intended for analysis, such as RHM4 and RHM5 in A4.2.1 in appendix 4. The purpose of the analysis is to search for a destination ("logical destination"). The destination types vary, and are also specified in RHM lines, such as RHM6 in A4.2.1. As during the pre-analysis phase, a call statement will be subject to different analysis criteria, the aim being to determine the RHMs which will relate to the call for its future routing. The "dest" parameter identifies a destination in the RHM set. There will therefore be linked routes having this parameter, and having other parameters specifying a physical destination. Thus, the RHM6 assigns the beam E90A to the logical destination 101.

The conditions are applied as in pre-analysis. The call statement analysis processing APPEL1A will therefore apply RHM5, which targets RHM6, hence a referral to the beam "E90A".

The process given as an example can end at this level, with the data of the transformed numbering and the output beam.

In reality, many other criteria can be examined (such as verification of rights to initiate this call, or to receive this call, depending on the characteristics of the subscription, in particular), before the call processing by the node considered is returned to the network simulator for passage to the next machine.

In a real case, there are many types of RHM for a given machine; and each RHM command can involve several criteria (from 1 to 20 approximately) and / or several actions. The logical expressions retaining an RHM, or rejecting it for a given call statement, are therefore diverse and their complexity varied. More generally, and without limitation, we can provide:

- RHM for configuring machine parameters,

- RHM specifying the load sharing between destinations,

- RHMs specifying priorities between routes, - RHMs canceling other RHMs, for example.

A real machine integrates several thousands, even several tens of thousands, of RHM lines, which define very numerous "first internal functions" for the pre-analysis, and "second internal functions" for the analysis, as well as others information, such as: definition of beams, management of taxation, for example. The simulator object of the invention must therefore, to simulate this machine, do the same. The invention offers an advantageous solution for achieving this satisfactorily, largely avoiding the risks of errors linked to such complexity.

The pre-analysis is not always carried out. Thus, in the case of a mobile phone call (FIG. 8), the initial call statement EA10 is transmitted to a machine XXO of the MSC type ("Mobile Switching Center"), which interrogates in UAE (virtual routing) an HLR database denoted XY99, receives in return an EA12 response, and uses it to address the call EA19, through the network, to another MSC station denoted XX9, by real routing.

In the case of the so-called "intelligent" or "IN" network (FIG. 9), an initial call (or incident) EA20 arrives on a machine XY90 (of SSP type). This interrogates in EA21 (virtual routing) a machine XY92, of the SCP type, which gives in EA22 a response, which is used in EA25 for real routing to another SSP machine, denoted XY95.

In other words, routing can be carried out not only from a PABX to a PABX, but also by the fact that a given PABX interrogates a NE system not connected to the traffic network (of the HLR or SCP type in particular), in order to then carry out a new pre-analysis phase, analysis, and more. We can therefore have the following sequence in particular:

- PABX A: pre-analysis, analysis, virtual routing to a NE machine; - NE machine: analysis, consultation of an internal database, virtual re-routing to the PABX A;

- PBX A, again: pre-analysis, analysis, actual routing to PBX B, and so on.

The configuration of machines of the HLR or SCP type can be advantageously reproduced by a database (not shown), incorporated into the computer 250, rather than by commands, as for automatic switches.

The system according to the invention, which can be called "simulator" allows to declare a network of switching centers ("machines"), to configure it with the parameters of the real network, to study the course of a game of call cases, and to validate developments in this network. All this is done simply, and without disruption of the actual operational network.

The technique according to the invention has another important advantage. As recalled in Appendix III, in A3.2 to A3.4, the routing decision taken by a real automatic exchange includes a statistical aspect: for the same desired (intermediate) goal, a fraction of the calls will follow a certain route, a another fraction will follow another route, and so on; in addition, emergency routes are planned.

According to the prior art, one could only receive the decision of the machine, as it was. The invention on the contrary makes it possible to directly manage the statistical aspect of the decision.

Of course, the invention is not limited to the embodiment described above by way of example, and is susceptible of numerous variants. For example, if the number of languages is not too high, we can consider merging the generic RHM parser and the "n" format parsers, which gives "n" RHM direct parsers to make them command objects.

On a completely different level, it was not a question here of the material constitution of the beams. It is clear however that the invention takes this factor into account, at least at the level of the propensity to choose a beam rather than another, for a given call.

The essential means here are the various elements, software and files, to be loaded into the simulation computer. This extends to any data file using any part of the invention, in particular files 502, 501, 561 and 521, as well as 511 (used according to the invention). The invention therefore covers these software elements, together or separately, in particular but not exclusively when they are made available in machine-readable form. The expression "machine-readable form" includes storage media, in particular magnetic or optical, as well as any means of transmission using analog and / or digital signals.

APPENDIX 1 - Descriptive call parameters

Al - parameters tested

CDN (CalleD Number)

Called number, generally composed of digits from 0 to 9, but can also include alphanumeric characters

CGN (CallinG Number)

Caller's number, consisting of digits from 0 to 9

CC (Country Code)

Caller's CC

IMSI (International Mobile Subscriber Identity) of the caller's IMSI

LAC (Location Area Code) Caller's LAC

NUMTYPE (NUMber TYPE)

Type of numbering, which can take one of the values:. UKN (UnKNown). NAT (NATional). LNT (INTernational), SPS (SPecial Service, PRV (PRiNate)

ORIG (ORIGin)

Origin at a given time of the call, which can take one of the values:

. PSTΝ (Public Switched Telephone Network) - access to third-party networks)

. TC (Transit Center - transit switch of the considered network)

. SC (Switching Center - switch of the network in question, excluding transit switch)

. PLMN (other network switch - TC or SC). IN (Intelligent Network - IN platform). BSS (Base Station Subsystem - call from a mobile or MOC for "Mobile Originated Call"). TERM (TERMinal - in case the network considered is a fixed network)

. FW (ForWard - call forwarding)

. GMSC_FW and NMSC-FW (Gateway / Visited Mobile-services Switching Center ForWard - special call forwarding). PABX (Private Automatic Branch eXchange). MSRΝ (Mobile Station Roaming Number - CDN is MSRN)

. HON (HandOver Number - the number is dedicated to the inter-MSC handover). LOOP (internal loop of a switch)

CALLTYPE Type of call which can take one of the values:. INC (INComing call), OUTG (OUTGoing call). FW (ForWarded call)

SUBPROF (SUBscribe PROFile) Subscriber Profile OSCC (Operator Specifies Supplementary Service Code) Code used within the framework of the IN

SSIND (Supplementary Service INDicator) Code used within the framework of the IN

SCM (Séquence Class Mark)

Code used in the context of the IN

SK (Service Key)

Code used in the context of the IN

POSCC (POSition of CC)

CC position in CDN number

TRKGRP (TRunK GRouP) Beam used

NODE

Label of the node considered

DATED

Date in the form mm / dd / yyyy for which the simulation is made. The configuration files used for the simulation are consistent with this date.

A.2 Parameters generated but not tested (output only)

CHGIND (CHarGing INDicator)

Charging information generated during calls

MCC (Mobile Country Code) Extract from IMSI

MNC (Mobile Network Code) Extract from IMSI

PARAM_x ... x (PARAMeter_x ... x)

Machine-specific parameter, generated for information

APPENDIX 2 - Structure of objects

A2.1 - Subject: Simulator

Attributes:

- a call parser,

- a network

Public methods:

- new (..): The object's constructor, it takes a configuration file containing the description of the particular simulation to be performed.

- Charge_les_appels (..): takes a call file, starts parsing it, returns a structure containing the calls.

- go (..): launches the simulation, for the data actually loaded.

- update (..): modification of the simulation parameters, (function linked to the user interface)

- poster (..): presentation of results

A2.2 - Subject: Appeal

Attributes: listjtaram: a structure containing the parameters and their values: dynamically constructed attributes. Public methods:

- New (..): takes the parameters of the call statement as parameters,

- Display (..): displays the call at a given time,

- access / change method.

A2.3 - Subject: Network

Attributes:

- "Detailed" configuration attributes of a simulation,

- A Parser of the network configuration file,

- A structure containing the nodes,

- A structure containing the links,

- Attributes representing the language of the network (its inter-machine protocol).

Public methods:

- new (..): The network constructor, it takes the network topology as a parameter, as well as the type of machine associated with each node.

- init (..): initialization of the network.

- Add_a_node (..),

- Add_a_link (..),

- Delete_a_node (..),

- Delete_a_link (..),

- access methods / modify.

Private methods:

- Choisir_un_noeud (..): For a call given in parameter, this method determines the route to follow for this one.

- Traite_un_appel (..): send a call to a node A2.4 - Object: Knot

Attributes:

- Name: name of the simulated machine,

- Bearing: name of the functional bearing (assigned by the equipment seller) of the simulated machine,

- Structures containing all the orders contained in the RHM.

Public methods:

- new (..): The constructor of a node, it takes as a parameter the type of node, eg SIEMENS SR6, SIEMENS SR7, SSP ALCATEL T23) and dynamically loads the specific methods, of the corresponding machine, of processing calls.

- rhm load: Allows RHM to be loaded, in the node configuration: by setting the RHM files and their associated formats.

- call_treatment (..): takes as a parameter a call (a reference), and a list of specific functions to apply, for example: pretrans, analysis, and returns the modified call.

- Display (..): displays the state of a node at a given time.

- Access method.

Private methods: Methods linked to the pre-analysis, analysis and routing phases, the algorithm of which is specific to the simulated machine.

- Specific methods for processing numbering.

A2.5 - Subject: Link

Attributes:

- Source machine, output beam,

- Destination machine, input beam.

- In addition, we define a certain number of parameters which represent the state of the link, in particular "On / Off", etc.

Public methods:

- new (..): The constructor of the link.

- Access / change method.

A2.6 - Object: Parser_de_RHM

Attribute:

- A structure containing the formats.

Public methods:

- new (..): the constructor of an RHM parser. It takes as parameters the rhm files and their respective formats.

- parse (..): starts parsing files; builds and returns structures containing Command objects

A2.7 - Subject: Order

Attributes: type: type of the command, i.e. its semantics interpretable by a specific node,

- list_param: a structure containing the parameters and their values corresponding to an RHM: attributes constructed dynamically.

Public methods: - New (..): takes as a parameter the type of the object, representing its semantics which will be interpretable by the simulator,

- Afïich (..): displays the command at a given time,

- access / change method.

A2.8 - Object: Parser_de_format

Attribute:

- A structure representing the format read.

Public methods:

- new (..): the constructor of a format parser. It takes format files as a parameter.

- parse (..): starts reading the file specifying the format.

Annex 3 - Examples of input files

A3.1 - Call files:

'' FT fixed subscribers in national format (with the prefix 0)

CALL: CDN = 0123456789, ORIG = BSS

CALL: CDN = 0315678901, ORIG≈BSS, SSIND = 244

'' FT fixed subscribers in international format

CALL: CDN = 0033123456789, ORIG≈BSS

CALL: CDN = 0033123456789, ORIG = BSS, SSIND = 244

CALL: CDN = 0033123456789, ORIG≈BSS, SSIND = 246

'' Short number from 3 to 6 digits - Foreign service access test

Swiss Telecom service

CALL: CDN = 950, ORIG = BSS, IMSI = 22801

CALL: CDN = 7372, ORIG = BSS, IMSI = 22801

The key word for recognizing a call is "CALL": parsing this file will cause the creation of 7 instances of the Call object with the parameters of the call line as their attribute. Example:

INSTANCE1: attributes: IND = 0123456789 => called number

Origin of call: BSS origin of call

Preferably, a certain number of parameters are added to the call for its management by the simulator. Example:

INSTANCE1: attribute: LINE = 2 => position of the call in the file for errors.

A3.2 - RHM FORMAT file

This file specifies the format of an RHM. In a simplified way, a line of RHM representing an order having n parameters to the following organization:

<d> <COMMANDE> <f [(param) <affect> (val) <sep> J * n- 1 (param) <affect> (val) <F> where <d>: start of the command

<COMMANDE>: name of the command param <affect> value: an assignment,

<affect> being the assignment operator <f>: end of command, start of parameters.

<F>: the RHM end of line symbol, end of command

<sep>: parameter separator example: a RHM siemens <CRDPFCACT: PRIO = 200, DICON = "+ C0", ZONDAT = N, ACTION = NATC0;

Here <d>: "<"

<COMMAND>: "CRDPFCDAT"

<affect>: "="

<f: " _: "

<F>

<September>

The RHM format file must therefore contain these definitions (syntax and semantics). In a simplified example:

> UNE_SYNTAXE

ACTION: CRDPFCACT: ACTION = 77, PRIO = 3, DICON = "77" d: <

AFFECT: =

SEP_PARAM:,

F:;

In this file, the specified syntax is called: A SYNTAX. It defines an ACTION object which will be recognized by a particular machine. This object is associated with a command found in RHM: CRDPFCACT. In addition, for this command we specify the mandatory parameters and their sizes (ACTION = 77). We then give the structure of an RHM line, for syntactic and semantic control.

A3.3 - RHM file

Example file: SIEMENS

<CRDPFCACT: PRIO = 200, DICON = "+ C0" ZONDAT = N = NATC0 ACTION!

: PRIO = 200, DICON = "+ C0" ZONDAT = N = NAT33C0 ACTION!

: PRIO = 200, DICON = "+ C + (NOD-HEX)", ZONDAT = N, ACTION = NATCX;

<CRDPFCDAT: CODE = 0 = NOD 16 FEAT = PRetrans, CALLTYP = PRetrans, ACTION = N

ATCO!

CODE = 0033, NOD = 16 FEAT = PRetrans, CALLTYP PRETRANSACTION = = NAT33C0!

: CODE = 9, FEAT = PRETRANS, CALLTYP = PRETRANS, ACTION = NATCX;

Here two commands appear: CRDPFCACT, and CRDPFDAT.

The configuration file giving the format of RHM gives the type of Order object to create and the rules to check: (presence of certain parameters and verification of their sizes);

Example: the parser interprets the first line and instantiates the Command object: Commandel => attribute: type = ACTION PRIO = 200 DICON = "+ C0"

ZONDAT≈N

ACTION≈NATCO

A3.4 - Network configuration file

The format of the network configuration file can be defined by the fact that, for each machine, we declare:

NUMBER: Machine number (number 1 reserved for the input machine for call cases)

NAME: machine name

OPERATOR: name of the operator who manages the machine

LANDING: name of the level

RHM: name of RHM file, name of its syntax (account order)

RHM_ERREUR: name of the RHM error file

ACH: #cases from our network

N of output beam => N of machine, N of input beam N of output beam => N of machine, N of input beam

# case of routing to a network that 1 we do not manage N of output beam => others, name of the other

#case of error default => type of error FUNCTION: function to be executed by the machine OPTION: List of simulation option RESULT: name of the result file for this machine.

We also define a language contained in the call, which allows the network object to make a routing decision. For example, if we have the routing cases:

ROUTE = NORMAL: (F1, 45%) (F2.55%) EMERGENCY: (F3.25%) (F4.75%)

FAIL: (F5, 100%) where 'F1, F2, F3, F4, F5' are beams, each simulated machine translates these routing cases into this language so that the network object actually routes the call cases.

In addition, if the routing is finished (the number called belongs to the central requested => BSC) or incorrect, the call preferably contains attributes such as: ENDED, ERROR, etc. These attributes take as value a textual explanation provided by the machine.

The OPERATOR field allows the simulator to find so-called "transcoding" parameters, which represent data specific to an operator, for example

"MNC".

The following is an example of a network configuration file for 3 machines. NUMBER 1

NAME: MSC_SIEMENS

OPERATOR: Un_Operateι; r

BEARING: SR6

RHM: rhm_D6, syntax 1 rhm_roaming_in, syntax2 Mnicl252.dg, syntax2 RHM_ERREUR: rhm_machinel.err ACH: 100A => 2, 200B 101B => 3, 100B

200A => others, "CT FT de Trouville" default => ERROR-END FUNCTION: pretrans, analysis, routing OPTION: all_result RESULT: machinel_compte_rendu.txt

NUMBER 2

NAME: CT-ALCATEL

OPERATOR: A_Operator

BEARING: ZW345

RHM: rhmalcal, syntaxAlca2

RHM_ERREUR: rhm_machinel .err

ACH: 200B => others, "CT FT de Lutèce" default => ERROR-END FUNCTION: garlic OPTION: all_result RESULT: machine2_compte_rendu.txt

NUMBER: 3

NAME: MSC_SIEMENS

OPERATOR: Un_Oρerateur

BEARING: SR7

RHM: rhm_D6, syntax 1 rhm roaming in, syntax2

Mnicl252.dg, syntax2 RHM ERROR: rhm_machinel.err ACH: 100A => 2, 200B

101B => 1, 100B

200A => others, "CT FT du Boucheauxnoix" default => ERROR-END

FUNCTION: pretrans, analysis, routing

OPTION: all_result

RESULT: machine3_compte_rendu.txt Annex 4 - Simplified examples of processing

A4.1 - Example 1 - Pre-analysis

A4.1.1 - RHM lines

RHM1 => critere_pre: NUM = 123, ORIGIN = BSS, action = change_orig

RHM2 => critere_pre: NUM = 123, ORIGTNE = PLMN, action = add out size

RHM3 => action: name = add_size, dicon = "+ size"

The first two RHMs have an "action" parameter which is a link to another RHM. Thus, it is possible to have several such links between RHM. RHM3 could also reference another RHM.

A4.1.2 - attributes of the corresponding control objects

RHM1.CRITERE.NUM = 123 RHM1.CRITERE.ORIGINE = BSS RHM 1.CRITERE. ACTION = change_ori

RHM2.CRITERE.NUM = 123 RHM2.CRITERE.ORIGINE = PLMN RHM2.CRITERE.ACTION = add_size

RHM3.ACTION.NOM = add_size RHM3.ACTION.DICON = "+ size"

A4.1.3 - a call to be processed

Call 1 => NUM = 123, ORIGIN = PLMN

A4.1.4 - conditions of the pre-analysis test

APPEL.NUM = CRITERE.NUM APPEL.ORIGINE - CRITERE.ORIGINE

A4.1.5 - call after treatment by RHM3 CallA => NUM = 3123, ORIGIN = PLMN A4.2 - Example 2 - Analysis

A4.2.1 - RHM lines

RHM4 => critere_ana NUM = 3123, ORIGIN = BSS, ie ^≈ lOO

RHM5 => critere_ana: NUM = 3123, ORIGIN = PLMN, dest≈lOl

RHM6 => road: dest = 101, beam = E90A

A4.2.2 - attributes of the corresponding control objects

PχHM4.CRITERE2.NUM = 3123 RHM4.CRITERE2.ORIGIN - BSS RHM4.CRITERE2.DEST = 100

RHM5.CRITERE2.NUM = 3123 RHM5.CRITERE2.ORIGIN = PLMN RHM5.CRITERE2.DEST = 101

RHM6.ROUTE.DEST = 101 RHM6.ROUTE.FAISCEAU = E90A

Claims

claims

1. Device forming an aid station for configuring a telecommunications network, comprising test means (150) provided for determining the behavior of machines interconnected from the network, as a function of the configuration (100) of these machines, from '' at least one set of call statements, forming a test set for configuration (110), characterized in that the test means, installed in a computer (250), include:

- a generic node module (420), offering public methods for creating instances and processing calls, and capable of accommodating attributes, as well as private methods,

- the public call processing method being provided to receive an entry call statement, and to return an exit call statement, with at least one route identifier, by applying selected private methods to the input statement,

- a plurality of basic modules (420A-420C), taken from the generic node module, capable of implementing respective expressions of the private methods (200),

- a network module (410) able to circulate, among the basic modules, successive versions of an initial call statement, as a function of the future route identifiers and network topology data (220), up to '' to satisfy a chosen condition, and

- a supervisor module (400), capable of selectively exciting the network module by selected initial call statements (210).

2. Device according to claim 1, characterized in that the generic node module (420) also offers a public method for loading parameter data, and in that said expressions of the private methods are a function of these parameter data.

3. Device according to claim 2, characterized in that it further comprises conversion modules (510-511) configuration commands expressed in machine-specific languages in a common language.

4. Device according to claim 3, characterized in that the conversion modules comprise command format files (521), a format reader (520) and a command file reader (510) (511).

5. Device according to claim 4, characterized in that the command format files (521) are provided to cover the respective command languages of different machine suppliers.

6. Device according to one of claims 3 to 5, characterized in that the common language is defined by an instantiable command object (530).

7. Device according to one of claims 1 to 6, characterized in that there is provided a network configuration file (561), with which the network module (410) cooperates, this file comprising topology data of the network, including, for each node, at least one corresponding attribute of language and configuration format.

8. Device according to claim 7, characterized in that the network topology data also include, for each node, the identification of its input and output channels, and in that a description is provided separately links between these entry and exit routes (430).

9. Device according to one of the preceding claims, characterized in that the private methods define first internal functions corresponding to a pre-analysis phase, and second internal functions corresponding to an analysis phase.

10. Device according to one of the preceding claims, characterized in that, for at least some of the machines, and for at least some of the nodes, the identification of input and output channels as well as the description of the links correspond to virtual routing.

11. Method for assisting in the configuration of a telecommunications network, comprising steps making it possible to determine the behavior of machines interconnected from the network, as a function of the configuration (100) of these machines, from at least one set of call statements, forming a test set for configuration (110), characterized in that said method comprises the following steps:

- create and configure a plurality of basic modules (420A- 420C), representing individual machines on the network and drawn from a generic node module,

- establishing a network module (410) representing a simulated network comprising the basic modules and links between these basic modules, and

- Create a supervisor module (400), capable of selectively exciting the network module by selected initial call statements (210), these call statements containing at least information on the links to be borrowed between basic modules.

12. Method for assisting in the configuration of a telecommunications network, comprising steps making it possible to determine a behavior of a machine of the network, as a function of the configuration (100) of this machine, from at least one set of call statements, forming a test set for configuration (110), characterized in that these steps include the steps for:

- receiving an entry call statement (210) comprising routing information for a route to be performed,

- create an instance from a generic node module capable of simulating a machine (420-A) corresponding to said routing information, and capable of receiving said call statement, - return an exit call statement, with at least one route identifier, by applying selected private methods to the entry statement,

-reiterate these steps in order to circulate among basic modules created during the interpretation of the routing information, successive versions of an initial call statement, as a function of future route and data identifiers network topology (220), until a chosen condition is satisfied.

13. A computer program for assistance in configuring machines of a telecommunications network in a software environment, characterized in that it is defined according to at least part of the objects or modules of one of claims 1 to 10 or for the implementation of the method of one of claims 11 and 12.