WO2002013504A1

WO2002013504A1 - System and method for managing a telecommunication operator's switching unit

Info

Publication number: WO2002013504A1
Application number: PCT/FR2001/002572
Authority: WO
Inventors: Olivier Flegeau
Original assignee: Switching Soft
Priority date: 2000-08-09
Filing date: 2001-08-08
Publication date: 2002-02-14
Also published as: FR2812995A1; AU2001284119A1

Abstract

The invention concerns a system for managing a telecommunication operator's switching unit (1, 2, 3), said switching unit being provided with a control terminal (4, 5, 6). Said system comprises: a management server (11) connected via at least a communication network (10, 9, 8 7) to the control terminal (4, 5, 6) and comprising means for collecting switching data in said control terminal, means for storing said switching data in a database, means for processing said collected and stored data to produce a plurality of graphic interfaces (12, , 20) representing the operation of said switching unit (1, 2, 3); and at least a client terminal (12, , 20) connected to the management server via at least a communication network (10) and designed to display at least one of the graphic interfaces and to transmit command requests made by a user.

Description

"System and method for managing a switch of a telecommunications operator"

The present invention relates to a system for managing a switch of a telecommunications operator. It also relates to the method implemented in this system for managing a network of switches of a given operator.

The main role of a switch of a given telecommunications operator is the transmission under good conditions of a telecommunications signal to a second remote switch. This second switch can be a switch belonging to the same operator or to a different operator. In the current state of the art, switches organized into a network of switches are managed from control terminals connected to this network. A switch control terminal is mainly used by technical personnel who have a perfect command of a switch control language. The operating status of a switch is tracked and monitored by consulting several raw data represented in tables in the form of codes. Thus such a system has the major drawback of being controllable only by technicians.

The present invention aims to remedy this drawback by proposing a system in which technical personnel and commercial personnel can equally intervene in the management of a switch. The invention thus aims to open up the management of a switch to a larger number of people in order to optimize its operation, by proposing a system allowing an improvement of the technical, commercial and financial management of a network of switches of a telecommunications operator. Another object of the invention is to provide an optimized routing function at a lower cost, referred to as "Least Cost Routing" in the English language.

The aforementioned objectives are achieved with a system for managing at least one switch of a telecommunications operator, this switch being provided with a control terminal.

According to the invention, this system comprises:

a management server connected via at least one communication network to the control terminal and comprising: means for collecting switching data within said control terminal,

- means for storing this switching data within a database,

- Means for processing this collected and stored data with a view to developing a plurality of graphical interfaces representing the operation of said switch; and

- At least one client terminal connected to the management server via at least one communication network and arranged to display at least one of said graphical interfaces and to issue command requests formulated by a user.

With such a system, the graphical interfaces allow a global vision of the operating state of the switch or of the network of switches. The management system according to the invention thus translates the technical language for controlling a switch into a visual language whose degree of technicality and complexity is significantly reduced. Thus, the switch control commands are carried out more quickly. In addition, control of the switch is open to a wider audience of users than that of technicians alone, for example to sales personnel who can now participate in the management of the switch. Commercial staff indeed add value to the management of a switch since they are in direct contact with customers. It is thus possible to take into account, in the management of the switch, alarms, expectations and requests from customers.

The management server implemented in the management system according to the invention is preferably designed to retrieve and process data from a plurality of switches of a given telecommunications operator. In this case, we therefore speak of a network of switches.

Advantageously, the management server periodically updates the database as a function of the data periodically retrieved from the control terminal. This periodicity can be for example ten seconds between each consultation of the control terminal and recovery of the modified data.

For this, one can install a communication software or a functional interface which is able to come into contact with the server and transmit the relevant data to it.

Generally, the control terminal is provided with switch control software. Thus the functional interface of the present invention is grafted onto this software in order to take data without blocking the operation of this control software. The operation of a switch can generally be represented in two separate but closely related parts: connections and translation. The data retrieved by the server concerns these two parts.

More specifically, the connections include all the physical part ("hardware" in English) composed of transmission links (SDH / PDH) which connect all the switches of each operator. These physical links are divided into several more or less expanded subsets depending on the technology of the switch used. The standard and universal entity between two switches is the MIC (Pulse Coding Modulation) diagrammed by thirty-two time intervals or thirty-one speech voices

(interval 0 = sync). In Alcatel® technology for example, these MICs are grouped into “Bundles”. A beam corresponds to a destination (route) to a remote switch. We therefore call connection all the bundles and MICs.

The translation includes logic that allows a call to be routed from its entry in the switch to its exit. It allows routing to be determined by consulting callsign tables (containing the destination codes for telephone calls), routing tables (indicating the route for routing telephone calls) and beam tables (indicating the beams taken account for a given phone call). To do this, the translation uses signaling which corresponds to all messages and parameters other than voice (transmission of the numbering, off-hook, on-hook, messaging, etc.). Connection and translation data allow the server to develop graphical interfaces which are updated in real time. Preferably these interfaces are displayed on remote terminals connected to the server. A user can send a request to the server which converts it into a command order understandable by the switch and then transmits this order to the command terminal.

Advantageously, the server performs a command interpretation by transforming the signal from a graphical interface into a command order understandable by the switch. This signal can be a click of a mouse or a command syntax in natural language or close to human language.

According to one embodiment of the invention, the graphical interfaces include first graphical interfaces dedicated to technical supervision of the switch, and second graphical interfaces dedicated to optimizing routing in the switch for less routing management cost

The first graphical interfaces make it possible to supervise graphically, in real time, the data of the switch or of a network of switches: static data on connections and translation; dynamic data on alarms, on traffic and commercial routing trends.

To do this, the server includes means for graphical modeling of the operation of a switch or of a network of switches. These first interfaces are more particularly intended for technicians. Graphic modeling also allows simulation and visualization of the operating state of a switch at a given time in the past, present or future. The second interfaces, more particularly intended for commercial services, make it possible to carry out the routing function at lower cost, that is to say "Least Cost Routing", providing programming functions and supervision of routing. The routing configuration is such that users are guided in the manipulation of these interfaces, and data purely related to telecommunications techniques are hidden from them. This frees up non-technical users from repetitive and manual tasks, which contributes to significantly reducing error rates and allows users to evolve and focus on strategic aspects of their business.

With these second graphical interfaces, commercial users can enter data relating to the quality of a beam connecting the switch, this data coming mainly from customers, whereas until now only electronic alarms scanning the network determined the quality of a network. These graphical interfaces dedicated to routing optimization are thus designed to transmit to the server information relating to the quality of the routing of the switch. According to an advantageous characteristic of the invention, the server also comprises calculation algorithms for determining control commands of the switch by taking into account graphic models and information coming from said graphic interfaces dedicated to the optimization of routing. The calculation algorithms therefore establish a link between, on the one hand, data coming from the interfaces dedicated to technicians and, on the other hand, data from interfaces dedicated to commercial functions. The result of an algorithm is then interpreted in a switch command language. Preferably, the algorithms are configured, which makes it possible, for example, to envisage several routing realization plans at a lower cost by favoring such or such data.

According to another aspect of the invention, a method is proposed for managing at least one switch of a telecommunications operator, this switch being provided with a control terminal, this method being implemented in a system according to the invention.

The management method according to the invention comprises:

- on a management site, - a collection of switching data within said control terminal, via at least one communication network,

- storage of this switching data in a database, - processing of this data collected and stored with a view to developing a plurality of graphical interfaces representing the operation of said switch; and

- on at least one customer site connected to the management site via at least one communication network,

a display of at least one of said graphic interfaces, and

- a transmission of command requests formulated by a user bound for the command terminal.

It should be noted that the management method according to the invention can advantageously be provided for carrying out a purse of communication units, for example a minutes exchange, between the operator and several other supplier operators. Each supplier operator then transmits its tariffs to a platform connected to the telecommunications operator. An algorithm determines optimum routing based on the tariffs and switching data of the telecommunications operator's switch.

Other features and advantages of the invention will appear in the description below. In the accompanying drawings given by way of nonlimiting examples: FIG. 1 is a diagram of the hardware architecture of client-server technology of a management system according to the invention; FIG. 2 is a diagram of the software architecture of a management system according to the invention; and

- Figure 3 illustrate the steps of the management method according to the invention implemented for the realization of a minute purse.

Consider first of all, with reference to FIG. 1, a set of switches 1 to 3 each controlled by a control terminal 4, 5, 6. The terminal 4 is for example connected to a local computer communication network "LAN "10 (Local Area Network), while the remote control terminals 5, 6 are connected by means of a router 7 to a" AN "type communication computer network 8 to which the local network 10 is connected by means of a router 9.

A management server 11 is connected to the control terminals 4 to 6 by means of the "LAN" 10 and "WAN" networks 8. This management server comprises a client-server, multiprocessor application, built around a database d C ++ objects. Client applications are housed in remote terminals 12 to 18 connected to the management server via the "LAN" network 10.

A database of C ++ objects is established from the data retrieved in command terminals 4-6 through the "LAN" 10 and "WAN" networks 8. These command terminals 4-6 each include a functional client application in order to ensuring communication between the server 11 and control applications housed in these control terminals. The control applications make it possible to control the switches 1 to 3. In general, these control applications can be original applications supplied by the manufacturer of the switches, and the client-server application according to the present invention is grafted onto these control applications to optimize the management of switches. The server application contained in the server 11 allows the configuration of client applications, the creation and updating of data relating to switches as well as the management of backups.

Client applications include graphical interfaces which can be classified into two parts: technical graphical interfaces and commercial graphical interfaces.

The technical interfaces make it possible to graphically supervise, in real time, the data of all the switches, a so-called "Network Operations Center" supervision in English. This data is static data (connections, translation, type of signaling, etc.) and dynamic data (alarms, changes in traffic and commercial routing, etc.). The management of this data is accessible through the technical interfaces arranged in management terminals 12 to 16. The interface 112 proposed on the management terminal 12 is a network supervision interface, having viewing, consultation and action functions. By means of an interactive graphic reference system, the user navigates through the connections (operators, beams, routes, MIC ...) or the translations (analysis and protocol of subsystem type n ° 7) of each switch. A hierarchy of data, simple and logical, allows quick access to the information sought. This hierarchy is built under a telecommunications model that does not imply knowledge of the type of switch. Operational alarms appear directly, by color code, on a graphical view of the switch network. It is thus possible to navigate to the offending element.

Different search functions allow you to graphically and spontaneously follow the progress of a type of call (callsign -> beams -> MIC). The dated and identified history (for example by archiving the name of the user station that made the modification) of any order placed on the network

(by the system or directly on the WTO which is spied on) in the form of work orders, incident tickets or spontaneous orders guarantees visibility at the engineering level.

All simple operating commands are available. They are executed in the form of dated work orders (immediate execution possible). The work order is then archived and activated on the date entered. Its execution is then either manual (an alarm indicates to the technician that it must carry out the modification), or semi-automatic (the modification is carried out, a alarm indicating to the technician to validate the execution of the command) or either automatic (the modification is executed automatically, the execution report being recorded in history). An alarm management table also allows them to be acknowledged, corrected, or investigated. Depending on the type of alarm, an automatic or manual procedure can either deal with the alarm or take it to a higher level with a diagnostic file. Two other interfaces 113 and 114 respectively for engineering and command interpretation can be associated with this interface 112 on the same terminal or arranged on independent terminals as in the following. The interface 113 is an engineering interface making it possible to follow the evolution and the dimensioning of the network over time. It also makes it possible to project into the future by programming a certain number of network engineering operations. It presents functions of visualization, consultation, and action.

The network or each switch at an instant t

(past, present or future). By entering a date, a graphical view represents the state of the network up to this date, then the state of the network after this date. This state corresponds to the operations programmed by an engineering team. It is possible to consult all the data (connections, translation, traffic, incidents ...) associated with this view and corresponding to the date entered.

An archive database allows you to consult all past or future operations carried out on each switch.

The programming of engineering achievements (such as the extension or creation of capacities to level of connections) is carried out in the form of work orders which are activated manually, or automatically on the scheduled date. The configuration of the connection or translation elements of the switch, carried out at this level by engineering experts, allows for more user-friendly use during operation. In addition, it secures the homogeneity of the network components and reduces the rate of configuration errors, which are the source of many problems that are difficult to identify later.

The interface 114 is a command interpretation interface granting operators flexibility and security in the use of the commands and having viewing, consultation and action functions.

The main operations to be performed on the network are listed in a command library. They are generally graphically programmed by the user. Thus, the user does not worry about the proprietary language of the switch, nor about the hierarchy of data.

The user also has assistance with command parameters, pre-recorded by experts in relation to the network configuration. - Online help and examples complete the support. In addition, it is possible to complete the operations library by adding personalized sequences to it.

As an example, we can also associate interface 112 with a routing configuration workshop interface to give an operator the possibility of controlling the allocation of his translation resources while guaranteeing, for example, dynamic management and automatic routing. There are two principles of routing settings, dynamic routing tables and static routing tables. The choice of one or the other is obtained by observing the destination. A measured use of the two principles guarantees the optimization of the system. Static route management corresponds to assigning to a destination (equivalent to a set of callsigns) a fixed route operating under load sharing or overflow in cascades. This management is suitable for destinations with many callsigns, which makes it possible, in the event of a change of routing, to make a modification of beams at the routing level instead of a routing modification at the callsign level. The number of callsigns per destination can be viewed in a control panel so that the user can choose the destinations to be programmed statically as well as the fixed route number (you can choose several routes for the same destination if you wants to differentiate the origins of traffic).

The dynamic management of routes strongly depends on the number of routes that the user allocates to this management. The programming of dynamic tables allows the creation or the deletion of some routes. It is possible at this level to specify a range of routing numbers corresponding to criteria of operators (through the beams), national or international formats, translators, signals ...

This workshop allows the configuration between operators and beams. For each operator and outgoing bundle, the different characteristics of the terminal routes can be configured. We take into account the management formats by destination (national or international) as well as the management of the number of digits of the country code of destinations if necessary.

The interface 115 is a traffic supervision interface comprising display, consultation and action functions.

All the beams of a switch are represented graphically. All observations of counters, calculated traffic indicators are updated in real time on this graph.

Basic indicators interpret the traffic fluctuations in tabular and graphical form. An archive database allows all of this data to be viewed a posteriori. Calculations assess the capacity of the network. Cross-referenced with load increase simulations, these calculations make it possible to adjust the sizing by providing statistics on additional link needs.

A graphic animation makes it possible, over a given time interval, to visualize over time the evolution of the beam load.

Two other interfaces 116 and 117 can be associated with this traffic supervision interface 115 on the same terminal or arranged on independent terminals as in the following.

The interface 116 is an alarm management interface comprising programming, display and action functions.

By type of days and specific time slots, traffic alarms (for information for the user) are programmed according to a certain threshold for filling beams or groups of beams. For example, if Friday between 3 p.m. and 4:00 p.m., there are X Erlans on all the beams of operator Y, an alarm at 60% is set. When the date and time arrive, if the traffic on these beams is only X / 2 Erlans, then the alarm will be triggered, it is up to the supervising technician to identify this drop in traffic (which may be due 'elsewhere natural). It should be noted that these alarms are not indicators of malfunction.

The triggering of alarms is graphically interactive on the traffic supervision interfaces. It also appears on a main dashboard.

The interface 17 is a configuration and analysis interface comprising display and action functions.

We find the graphic view of the traffic supervision interfaces, with a different distribution of the beams, corresponding to the associations made. All the counters are then cumulated to display sums or averages. The traffic indicators are consulted through tables or graphs.

Programming new indicators from counters and mathematical formulas makes the application scalable. These technical graphical interfaces 112 to 117 are supplemented by commercial graphical interfaces 118 to 120 which allow routing at low cost LCR, "Least Cost Routing". To achieve routing at a lower cost, we display national and international translators (tables of analyzes or callsigns) under a commercial model based on destinations and categories (countries, regions, cities, mobiles, etc.). For each destination, we then enter prices. Then we real-time calculation of the best possible routing for each destination, taking into account as non-limiting examples the following parameters: - prices: - 24 time slots - 8 types of days (days of the week + a holiday)

- originating traffic

- 3 tariffs on volumes

- time credit - transport format (voice or 64 Kbit / s) quality of the destination by operator, capacity or saturation by operator. Each time these parameters are modified, the optimal routing is calculated again. This calculated routing is a theoretical routing. The actual routing plan (effective plan on the switch) is equal to the theoretical routing plan with routing changes requested by customer service following poor quality of the destination. It is important to note that customer service can directly and quickly act on the modification of the actual routing.

The difference between the two plans, respectively theoretical and real, represents the quality factor of a destination for a given operator.

This quality factor has priority over the profitability factor (expressed by the tariffs). This choice is configurable.

Real-time routing supervision guarantees the quality and profitability of the network. For each ticket or routing modification request issued by customer service for quality of service reasons, the most profitable routing is recalculated. This LCR lower-cost routing function involves a first tariff entry interface 118 having viewing and action functions.

The tariff entry interface is a set of grids associating the destinations with the different operators. We change the grid by modifying the time slot, the type of day or the original traffic.

Depending on the password entered when connecting this interface, it is possible to view or modify these rates.

The LCR lower cost routing function also relates to a second routing management interface 119 having functions for viewing, preparing tariff plans, programming a routing calendar, simulation, activating the calendar and setting implementation of routing calculation algorithms.

This interface 119 thus includes a display in the form of a tree structure of the tables of callsigns of a given switch in order to carry out a prioritization of commercial destinations (countries, regions, cities, mobiles, etc.).

For tariff plans, different tariff grids, depending on the time bands and types of days, can for example be automatically transposed into lists of operators (from the best choice to the worst choice) of a switch concerned. The routing plan calculated by the server proposes for example a provision of cascading overflows of operators, from the most profitable to the least profitable, that is to say that all the traffic of a destination is routed by an operator 1 (the more profitable) . In case of saturation of this operator the traffic will be routed by an operator 2 (the most profitable after 1). In case of saturation of this operator 2, we provides overflow on a 3 ^{th e} operator corresponding to a large capacity drive and good quality, but generally high prices. This automatic transposition is calculated according to selected parameters such as quality, volumes, or time credit. A second calculation, responding to capacity constraints by operator and by destination is then possible by using complex matrices. These operations are carried out automatically and systematically for each tariff plan (typical couple of days / time slot). It is thus possible to treat, by way of nonlimiting example, 192 possible standard tariff plans.

By default, a destination is considered to operate under the “cascade overflow” principle, but it is possible to transform its operation under the “load distribution” principle. This principle of “load sharing” consists in assigning several operators with different load percentages for the same destination. Traffic will then be routed according to the percentages defined by operator. The user can also select the type of routing to use. This principle is managed at the destination level, which allows for the same tariff plan to have static or dynamic destinations managed in “cascade overflow” or in “load distribution”.

For each switch, two weekly calendars (national and international) with time accuracy are programmed. Routing changes are made automatically in relation to these schedules. We assign graphically, for each type of day and for each time slot, a standard routing plan. Through example, for a given site, we assign the "Monday 1:00 pm" rate schedule from Monday 1:00 pm to Monday 5:00 pm from which we assign the "Monday 5:00 pm" rate schedule until 24:00. By default, the valid price list is "Monday OOHOO". This organization between the calendar and different plans provides the user with the possibility of managing the routing of each switch according to the time. An annual calendar is also available to be able to enter the type of days of each date (interesting for public holidays).

A simulation then makes it possible to technically evaluate the achievement of the calendar. It informs for each change of grid, according to the number of incriminated destinations, and the number of callsigns per destination, the execution time of the modifications. If this execution time is greater than the tranche allocated for the change, the modification is refused. In practice, if for example a change requested at 1:00 p.m. takes 1 hour 30 minutes to execute completely (this time depends only on the speed of execution of commands on the switch), another change is not possible before 3:00 p.m.

The system has two types of calendars. “Active” calendars are used to manage the routings in progress. The "preparatory" calendars are used by the routing management interface 19 to program the new routes. At the initiative of the users, a switchover of the calendars makes it possible to change the routing schedule. The "preparatory" calendars then become "active". This operation takes place for example a quarter of an hour after the next hour to allow time the system to prepare its new routing which will not be implemented until the following hour.

An additional cost simulation interface makes it possible to observe in terms of costs and system resources, the consequences of a tariff plan (day / hour / origin). Before each change in tariff plan (automatic changes according to the system time), the server transforms the theoretical routing into switch command files which will be executed during the time change. The principle is to translate the theoretical choice of each destination into technical parameters allowing the preparation of calculation algorithms or macro-commands for routing change.

These calculation algorithms, by default, implement cascade or multiple routing tables depending on the destinations. The device optimizes the composition of these tables to guarantee the profitability of the requested routing according to the limits imposed (maximum number of routes).

The engineering interface makes it possible to personalize the calculation algorithms for each destination, and to respect the constraints of assignments and nomenclatures of routes. A simulation makes it possible to associate each valid dynamic destination with a combination which will then be translated into technical values respecting the software architecture of the switch, a combination being the grouping of all the destinations having the same criteria. These criteria are the choice of operators, the format by operator (national or international), the number of digits of the country code (this parameter is optional, it is activated at the interface of the routing configuration workshop).

During the simulation, a cascade overflow is set up with two first operators. Routing ensures the third choice. This routing is a load sharing between operators benefiting from capacity and quality. The format of a combination can be presented as follows:

- operator 1 - operator 2

- national or international format

- number of digits of the country code (1,2,3 if activated; 0 otherwise)

- list of associated destinations - sum of the volumes of associated destinations.

We therefore associate by destination, two combinations.

The first named main represents the technical choice put in place. The second named secondary intervenes after a first overflow. The sum of the main and secondary combinations forms the requirements for programming the ideal routing. These needs must be compared to user-defined resources. The list of main combinations is then sorted by decreasing volumes. It is modified until the number of needs equals resources. In all cases, the ^1st choice of operator is always served. In the case where the number of secondary combinations is greater than the resources, the routing cannot be optimized further. In this case the optimization will completely destroy the list of main combinations. To absolutely respect resources, it is necessary to modify the distribution of operators of certain destinations at the plan level overflow in cascades. This is one of the functions of the simulation, because it makes it possible to observe the distribution of combinations, the impact of their modification from the technical (resources and needs) and financial (higher cost compared to the ideal situation if overflow) aspect. ). When a combination is destroyed (in the context of optimization with respect to system resources), the destinations that made it up are distributed among other combinations (always respecting the ^1st choice). During this reconstruction, the operator overflow ^(2nd choice) can be modified by causing an additional cost. This additional cost is displayed by destination, as well as at a general counter.

The LCR low cost routing function also implements a routing supervision interface 120 having viewing, consulting and action functions.

Colored geographic maps represent the distribution of theoretical and real routes by destination and by operator over time. Calendars are used to visualize the distribution of the different theoretical routing plans over time.

Graphical functions facilitate consultations and allow graphical comparisons to be made, statistics highlighting the quality of each destination. General tables or by destination also give daily monitoring of the distribution of routes and a calculation of costs (sale / purchase). In case the actual routing is not the most profitable, it also displays the losses compared to the optimal routing. This interface 120 is dedicated to customer service, which, upon complaint of the poor quality of a destination served by an operator, has all the elements in hand to order the modification of the routing.

A simulation of cost comparison and implementation times is available before sending a ticket or request which will be automatically, semi-automatically or manually processed.

This LCR function can also include other functionalities such as a multi-switch functionality allowing to take into account the tariff calculation of the best routing path of a destination. It compares, from a first switch, the price of serving the destination via a third-party operator connected to this first switch to the price of routing this same destination from a second network switch. We can also consider a "Capacity" functionality allowing, by complex matrix calculations, to optimize the development of routing plans, or even a "Saturation" functionality allowing to automatically switch the routing of destinations when link to an operator is about to saturate.

In FIG. 2, the software architecture of a management system according to the invention is represented with graphical client interfaces arranged partly on terminals 21 to 23 dedicated to a technical service, and partly on terminals 24 and 25 dedicated to a commercial service. The technical graphical interfaces relate to the modeling 26 of the operating state of a switch 30, while the commercial graphical interfaces relate to data 27 for the implementation of routing at lower cost (LCR). Calculation algorithms 28 allow the server, from the elements of the modeling 26 and LCR data 27, to establish switching or control data 29 of the switch 30. The management system according to the invention can also be advantageously implemented for the establishment of a telecommunications exchange.

In the prior art, so-called telecommunications minutes exchange systems exist. The only criterion that a user must enter by hand in such a system is the tariff of each destination by operator. The system according to the invention makes it possible to automatically integrate a minute purse. To do this, each operator supplying capacity for an operator owning the system according to the invention, enters its tariffs by destination in the form of a table on an IP platform. These tables will be automatically consulted in real time by the systems according to the invention at the time of the routing plan calculation algorithms, at least every hour.

In return, the calculation algorithms when they have chosen a particular operator for a destination and a time slot (minimum 1 hour), a minute purchase order will pass through the IP platform to the operator selected for a volume. given. Once this order has been validated by both the supplying operator and the requesting operator owning the system according to the invention, the system proceeds to the referral.

The anonymity of the participants is respected as long as the calculation algorithm has not established its choice. The prices of the other unselected choices are therefore not displayed.

In addition, depending on the capacities and qualities of the links of each carrier, the choices of the calculation algorithm may be different for two supplier operators even if the price is identical.

The diagram in Figure 3 shows the mechanism of the stock market in seven stages. The operator X is the one having the system according to the invention. The supplier operators are designated by “carrier”.

_ step 1: Operators 1, 2 and 3 suppliers of operator X enter all tariffs by destination (with the options of time credits, volume discounts, etc.).

_ step 2: System X collects by destination the tariffs of the supplier operators connected to it (in fact the stock exchange is multi-user) in order to be able to use them in its calculation algorithms by comparing them with the switching data (volume, capacity , quality, technical resources ...). At this stage operator X is not aware of the tariffs of the supplier operators. Anonymity is therefore respected.

_ step 3: Result of the calculation algorithm for an ideal routing plan for operator X (optimization of cost / capacity / resources).

_ step 4: Acceptance of the plan by operator X or rework on this plan by the operator manually or automatically, always without knowing the tariffs of each operator for each destination. _ step 5: In the case of acceptance: display of the tariffs of the supplier operators selected by destination. At the same time the selected supplier operator receives the capacity purchase request for a volume of minutes per destination for a defined time slot.

_ step 6: Validation of the seller (selected supplier operator) and the buyer (operator

X) by destination. For the buyer each destination can have a specific selected supplier operator.

The added value for the first is to know the filling rate of its input network, the added value for the second is to optimize the cost of purchasing output capacity. Each operator can be a customer and a supplier. This step 6 can be automated.

If not agreed -> return to step 3,

_ step 7: Implementation of routing within the switch of operator X using the technical functions of the system: modification of switching data. Issue of an invoice for the transaction.

Steps 5 to 7 are to be performed for each destination. The telecom minutes exchange carried out with the method and the management system according to the invention presents a certain number of advantageous criteria: _ is independent of the transmission links between operators;

_ offers the tariffs of all operators by destination, based on volumes; _ guarantees the anonymity of operators until the transaction;

_ directs traffic from one operator to another once the transaction has been recorded for:. a particular destination,. a defined time slot,

. a volume of minutes purchased, and _ defines warranty rules (depending on the quality, volumes sold, etc.)

It is therefore independent and manages all of the traffic of the operators connected by optimizing routing in real time according to parameters known to the switch.

Of course, the invention is not limited to the examples which have just been described and numerous modifications can be made to these examples without departing from the scope of the invention.

Claims

1. System for managing at least one switch (1, 2, 3) of a telecommunications operator, this switch being provided with a control terminal (4, 5, 6), characterized in that it comprises:

- a management server (11) connected via at least one communication network (10, 9, 8, 7) to the control terminal (4, 5, 6) and comprising:

means for collecting switching data within said control terminal (4, 5, 6),

- means for storing this switching data within a database,

- Means for processing this collected and stored data with a view to developing a plurality of graphical interfaces representing the operation of said switch; and - at least one client terminal (12, ..., 20) connected to the management server (11) via at least one communication network (10) and arranged to display at least one of said graphical interfaces and to send requests for command formulated by a user.

2. System according to claim 1, characterized in that the management server (11) further comprises means for periodically updating the database as a function of switching data collected within the control terminal (4 , 5, 6).

3. System according to one of claims 1 or 2, characterized in that the management server comprises in addition to means for real-time graphical interfaces according to changes in the data in the database.

4. System according to any one of the preceding claims, characterized in that the management server also comprises means for transmitting control commands from the switch to the control terminal.

5. System according to any one of the preceding claims, characterized in that the management server further comprises means for converting requests sent by the client terminal into control orders understandable by the switch.

6. System according to any one of the preceding claims, characterized in that the management server develops graphical interfaces (21, 22, 23) dedicated to technical supervision of the switch (30).

7. System according to claim 6, characterized in that the server comprises means for graphical modeling (26) of the operation of a switch (30), said modeling providing graphical interfaces dedicated to technical supervision (21, 22, 23 ).

8. System according to any one of the preceding claims, characterized in that the management server develops graphical interfaces (24, 25) dedicated to the optimization of routing in a switch (30) for routing management at a lower cost. .

9. System according to claim 8, characterized in that these graphical interfaces dedicated to the optimization of the routing are capable of transmitting to the server information (27) relating to the quality of the routing of the

⁵ switch.

10. System according to one of claims 8 or 9, characterized in that the server comprises calculation algorithms (28) for determining control orders ° (29) of the switch (30) taking into account graphic models ( 26) and information (27) from said graphical interfaces dedicated to the optimization of routing (24, 25).

5 11. System according to claim 10, characterized in that the calculation algorithms (28) are configurable.

12. System according to any one of the preceding claims, characterized in that the server is able to 0 recover and process data from a plurality of switches of a telecommunications operator.

13. Method for managing at least one switch (1, 2, 3) of a telecommunication operator, this switch being 5 provided with a control terminal (4, 5, 6), implemented in a system according to l '' any one of the preceding claims, characterized in that it comprises: - on a management site,

a collection of switching data within ^{0 of} said control terminal, via at least one communication network,

- storage of this switching data in a database, - processing of this data collected and stored in order to develop a plurality of graphical interfaces representing the operation of said switch; and - on at least one client site (12, ..., 20) connected to the management site via at least one communication network (10),

a display of at least one of said graphic interfaces, and

14. Method according to claim 13, characterized in that it further comprises a periodic updating of the database as a function of switching data collected within the control terminal.

15. Method according to one of claims 13 or 14, characterized in that it further comprises a real-time setting of the graphical interfaces as a function of the modifications of the data of the database.

16. Method according to any one of claims 13 to 15, characterized in that it further comprises a conversion of requests sent by a client terminal (12, ..., 20) into control orders understandable by the switch .

17. Method according to any one of claims 13 to 16, characterized in that it further comprises an elaboration of graphical interfaces (21, 22, 23) dedicated to technical supervision of the switch.

18. Method according to any one of claims 13 to 17, characterized in that it further comprises a graphical modeling (26) of the operation of a switch (30), said modeling providing graphical interfaces (21, 22, 23) dedicated to technical supervision.

19. Method according to any one of claims 13 to 18, characterized in that it further comprises an elaboration of graphical interfaces (24, 25) dedicated to the optimization of routing in a switch (30) for management lower cost routing.

20. Method according to any one of claims 13 to 19, characterized in that it further comprises a determination of control orders (29) of the switch (30) taking into account graphic models (26) and information (27) from the graphical interfaces (24, 25) dedicated to the optimization of routing.

21. Method according to any one of claims 13 to 20, characterized in that it is implemented for the management of a plurality of switches of a telecommunications operator.

22. Method according to any one of claims 13 to 21, characterized in that a purse of communication units is produced between said operator and several other supplier operators.

23. The method of claim 22, characterized in that one realizes a minute purse.

24. Method according to one of claims 22 or 23, characterized in that each supplier operator transmits its tariffs to a platform connected to said telecommunications operator.

25. Method according to claim 24, characterized in that an algorithm determines an optimum routing as a function of the tariffs and the switching data of the switch of said telecommunications operator.