Architecture for billing management in a telecommunications network

0001The present invention relates to an architecture providing a service pricing in a telecommunication network management system.

0002The invention is particularly likely to apply to Telecommunications networks management (GTA) and defined in series M.3000 of recommendations issued by the ITU-T (<i>International Telecommunication Union - Telecommunication Standardization Section).</i>

0003Pricing is one of five major families of management services the OSI architecture (<i>Open System Interaction</i>), Jointly defined by ISO (<i>International Standardization Organization</i>) And ITU-T.

0004These large families, called functional areas in the vocabulary own in the OSI architecture are the following:<ul><li>faults management,</li><li>The pricing management,</li><li>The management of the configuration,</li><li>The Performance Management and</li><li>security management.</li></ul>

0005The pricing management service is described more particularly by the X.742 recommendation ITU-T entitled " <i>Information technology</i> - <i>Open Systems Interconnection - Systems management: Usage metering function for accounting Purposes</i> ".

0006This recommendation specifies only low levels and components no one way to arrange them to form a pricing service.

0007In a telecommunication network, upon termination of a communication, the caller's switch transmits to a billing center a billing ticket containing the information on the communication which are necessary for billing center (call duration, tariff zone etc.)

0008In an intelligent network comply with the set of recommendations Q.1200 of ITU-T, services emit equivalent of billing tickets.

0009We see that existing solutions are dependent on the architecture telecommunications network, including billing tickets issued by switches or by the services of the intelligent network.

0010The object of the present invention is to provide means for allowing the implementing pricing policies independently of the network telecommunication underlying and services that use the network.

0011To achieve this goal, the invention relates to an architecture comprising a telecommunications network formed from a plurality of structured elements hierarchically, and management means containing a hierarchical set of software components.<ul><li>each software component is associated with a network element of telecommunications, and each hierarchical level of this set corresponds to a hierarchical level of the telecommunication network,</li><li>at least one software component comprises a transmitting means messages to at least one means of pricing, and,</li><li>only the lowest level of software components have means to access information relating to the use of elements of network associated, in these network elements.</li></ul>

0012According to particular embodiments of the invention, it may further comprise one or more of the following characteristics:<ul><li>Messages are transmitted to the notifications or the means pricing, via one or more notification services.</li><li>Or notifications and notification services are supported by CORBA software architecture type. </li><li>The usage metering means to transmit some of the components software contract (or <i>policy,</i> according to the English terminology) setting the means of transmitting messages.</li><li>The information about a communication is transmitted to the end communication, in one or more messages.</li><li>The information relating to a call are transmitted periodically, in one or more messages.</li><li>The managing means further includes means for establishing and interrupt communications in the telecommunication network, for example according to the specifications of the TINA consortium.</li></ul>

0013Thus, by using an architecture according to the invention, the pricing becomes independent of the underlying telecommunications network. That implies two distinct advantages:<ul><li>On the one hand, the information transmitted by the components of the architecture of the invention being generic, that is to say, independent of the underlying network resources, it means that pricing is not linked to specific information in the billing dockets issued by the resources of a network particular.</li><li>And secondly, it means the change of a resource of network (a switch, for example) does not change policy Pricing has been set up.</li></ul>

0014Similarly, the information transmitted by the components of the architecture according to the invention being generic, that is to say the same for all its supported services, any charging policy can be implemented, and longer depends exclusively specific information contained in the ticket from the network or specific services.

0015Yet another advantage is to allow invoicing using several levels of information. It is for example possible to issue invoices depending on the actual use of used or the number of switches subnets used etc.

0016Other features and advantages of the invention will appear in the Detailed description of various embodiments will be made in relation with the accompanying figures.

0017Figure 1 schematically illustrates the architecture for the management of pricing of the invention.

00182a and 2b show two particular embodiments of this architecture.

0019T telecommunications network shown in Figure 1 comprises 3 hierarchical levels. The first level is formed by the network of telecommunication itself. The network is divided into several sub-networks S₁, S₂each having one or more network resources, R₁, R₂, R₃, R₄, R₅. The telecommunication network T, S subnets₁, S₂ and network resources, R₁, R₂, R₃, R₄, R₅Are called network elements.

0020Each of these network elements is associated with a software component of structured architecture of the invention.

0021R network resources₁, R₂, R₃, R₄, R₅Are associated with the software components of lower levels, respectively C₁C₂C₃C₄C₅. The S subnets₁ and S₂ are, as to them, associated with software components intermediate hierarchical level C₆ and C₇. Finally, the network itself is associated at the highest level software component C₈.

0022Each of these software components may comprise transmitting means messages to a charging means. Messages from of a given software component comprises information on the use of the network element which it is associated.

0023Furthermore, the lowest level of software components may communicate with access to network resources to obtain interfaces information relating to the use of thereof. This information can be stored in databases called MIB (for <i>Management Information Based,</i> in English). The lowest level software components can access these MIB via these access interfaces using a communication protocol such that CMIP (<i>Common Management Information Protocol</i>) That is specified by the Recommendation X.710 ITU-T, or SNMP <i>(Simple Network Management Protocol).</i>

0024The lowest level software components can access accurate information on network resources. This information can be :<ul><li>the actual use of resources, i.e. the flow or, for example, the number of cells in transit for a given communication, a switch,</li><li>an error rate, for example, the number of incorrect cells could not be transmitted.</li></ul>

0025This information can then be fed back to the components software highest levels to be aggregated there.

0026According to a particular implementation, the hierarchy of components software is confused with a connection manager, particularly with Connection Manager within specifications from the TINA consortium (<i>Telecommunication Information Networking Architecture</i>). According to these specifications, initiating a communication in the past telecommunication network by the connection manager.

0027The initialization request is sent to the software component of highest level, and then propagated through the hierarchy of software components.

0028For example, using the example illustrated by Figure 1, if the communication requires connecting the R resources₁ and R₄, Then the component highest level of software, C₈, Will propagate the request to the two components next lower level of software that have in their offspring software components associated with those resources, ie the components C software₆ and C₇. Each of these software components then propagates the request to the software components associated with resources for connecting requested resources, that is to say C₁C₂C₃ and C₄.

0029The software components C₁C₂C₃ and C₄ which are capable of communicate with R resources₁, R₂, R₃ and R₄Can then configure these resources for the establishment of the connection, and thus, the communication.

0030Through this mechanism, the various software components have the information relating to communications that are currently on the network telecommunication.

0031According to a particular embodiment of the invention, the one or more means of Pricing forward to some elementary software components contract, or <i>policy</i> according to the English terminology, to set the means for transmitting messages.

0032In particular, it is thus set:<ul><li>The information from the generic information available which will be issued by these means, to the usage metering means,</li><li>The timing of this information will be transmitted. Information can be transmitted for example at the end of the communication or on a periodic basis (once a day, once a month...).</li></ul>

0033According to a particular embodiment of the invention, the messages sent by the software components are notifications, that is to say messages Sent on an asynchronous basis. These notifications are sent to one or more notification services to which the usage metering means register. In this way, a way of pricing is being registered with a notification service receives notifications from the software components.

0034The architecture according to the invention can be implemented over a CORBA platform (<i>Common Object Request Broker Architecture),</i> complies with specifications from the OMG (<i>Open Management Group).</i> In this case, the notification service can be a notification service complies with these specifications.

0035Other implementations include using no notifications are possible. For example, messages can be responses to requests or from the pricing means.

0036From this information, pricing means can develop bills. These bills depend on the nature of the information received.

0037The dependency relationship can be extremely simple: the bill for communication can be the product of a fixed cost pricing and the actual use of resources used.

0038Other solutions are of course possible. Especially,<ul><li>It is possible to take into account an error rate and / or quality service measured at the network resources to implement a sliding scale for poor quality communication, or not to charge non-transmitted cells.</li><li>It is possible to apply different pricing for certain subnets.</li><li>It is possible to vary pricing based on hours of day.</li></ul>

0039This list is obviously not exhaustive.

00402a illustrates an embodiment of the invention. In this example, the charging means is unique. A contract is sent to the software components indicating that only the software components below level (C₁C₂C₃C₄ and C₅) Transmit messages Mr.

0041The messages M contain a communication identifier, IdC, NC and the number of cells that have passed through the switch to this communication.

0042These messages are sent when closing of the communication to a N. Notification Service

0043Upon receipt of these messages, the pricing means T aggregates information received from various software components corresponding to various network resources used by communication.

0044Figure 2b illustrates a second embodiment of the invention.

0045A contract is sent to the software components indicates that only higher level software component C₈Must send messages M.

0046The messages M contain an identifier of the communication and IdC the DC term of the related communication. They are sent on a base periodic (eg, at the end of each month) through pricing T.