Method for Synchronizing Charging Processes Involved in Performance of Service on Network Elements in Communication Network

Abstract

A control protocol using mechanisms of a transport protocol is used to distribute control messages containing specific dedicated information for each charging process involved in the performance of a service or application to each charging process required in the performance of the service or application.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is based on and hereby claims priority to German Application No. 10 2004 026 140.7 filed on May 26, 2004, the contents of which are hereby incorporated by reference.

BACKGROUND

The method described below relates to synchronizing charging processes involved in the performance of a service on network elements in a communication network. In this context, the service or the application is generally a packet-based service or a packet service. Existing packet services operate on what is known as an IP layer 3 based on the OSI model within the communication network. Currently existing and practiced processes and methods for charge metering for such a service in communication networks are based on normally independent and unsynchronized metering when the service of used resources is performed by the charging processes involved in the performance of the service on the various network elements. Charge data gathered in the process are merged, following use, in network elements provided specifically for this purpose in order to produce a service-oriented or service-specific bill. In the case of what are known as prepaid subscribers who wish to use the service, this process needs to take place during exhaust use. For some services, the data cannot currently be merged.

To be able to use the known described method, all network elements involved in charge metering need to have a unique correlation identifier. This correlation identifier clearly identifies all use data which are associated with a specific service use and needs to be entered into the use data so that they can be combined by a central entity and can be processed together.

One of the central problems in the correlation-based charge metering described is the distribution of the correlation identifier to all the network elements involved. The network elements involved in the performance of a service can operate on different network layers, for example, such as on what is known as layer 2, 3 or 7. In addition, they may also be arranged in various network areas or domains, such as in what is known as a PS (Packet Switched) domain or in what is known as an IMS (IP Multimedia Subsystem). It is also conceivable for the network elements involved in the performance of a service to be separated from one another by technological boundaries too. Thus, by way of example, some of the network elements may be based on UMTS (Universal Mobile Telecommunication System), and another portion of the network elements may be based on WLAN (Wireless Local Area Network). In such a heterogeneous environment, a mechanism for distributing the correlation identifier needs to be defined for each new service and then standardized. As a result of this practice, fast and flexible introduction of new services is not assured. The problem presented has meant that the “MS” (Multimedia Service) has for a long time not been able to be offered to online prepaid subscribers on account of a lack of charging methods. The already existing complexity for the charge ascertainment or metering is increased in the case of the new distributed network architectures such that charge metering using the current methods described will no longer be able to be controlled in future. In addition, the complexity is increased whenever new technology is introduced.

Another problem is the inefficiency of existing methods. These gather charge data in all network elements involved and forward the resulting charge data records to a central entity. This central entity has to find the associated charge data records from an incoming flood of data. The important charge data records are then evaluated and the rest are discarded.

Accordingly, it would be desirable to provide an overall concept which allows service-oriented charge data to be produced for a service in a communication network as easily, efficiently and quickly as possible. To this end, dynamic control of charging processes needs to be made possible for any use of a service.

SUMMARY

Against the background of the problem described at the outset, a method is disclosed which can be used to synchronize charging processes involved in the performance of a service on network elements in a communication network. The method described below synchronizes charging processes involved in the performance of a service or an application on individual network elements in a communication network, where a control protocol using mechanisms of a transport protocol is used which is used to distribute control messages containing dedicated information which is specific to each charging process involved in the performance of the service or the application to each charging process involved in the performance of the service or the application.

In this case, the control protocol used is preferably a signaling protocol which is based on what is known as an NSIS Transport Layer Protocol (NTLP).

The NSIS (Next Step In Signaling) “Working Group” has already standardized a fundamental concept for controlling network elements along a data path for a service or an application. This concept is currently used to control the quality of service QoS of what is known as an “end-to-end” link or a portion thereof. The fundamental concept is described indraft-ietf-nsis-fw-05.txt, available from the Internet Engineering Task Force (IETF). The NSIS transport protocol series defined therein—NTLP—is provided for supporting various signaling applications for installing and/or manipulating specific states within the communication network. In this context, this respective state is in relation to a data flow and is installed and maintained on the NSIS entities (NEs) through which the data flow passes or which are arranged along the data flow path. This fundamental transport protocol NTLP can then be taken as a basis by various users using a respective specific NSIS Signaling Layer Protocol “NSLP”. A fundamental difference between signaling on the basis of the NSIS protocols and previous signaling is that NSIS signaling is not related to general superordinate network operation but rather to the specific data flow for a service and that also network elements in a communication network are included in the signaling and the signaling does not proceed transparently between the terminal points.

Within the context of QoS control, the NSIS Working Group has already defined a signaling protocol series—NSIS Signaling Layer Protocol QoS-NSLP—which is based on the general NSIS concept. This is described in an internet draft from the IETF, draft-ietf-nsis-qos-nslp-03.txt.

The QoS-NSLP developed in this context is not tied down to supporting a specific QoS model, but rather is suitable for forwarding information for various QoS models.

Within the context of one embodiment of the disclosed method, this means that the control protocol is then a specific NSIS Service Layer Protocol (NSLP), which is subsequently called the Accounting NSLP. This control protocol uses mechanisms of a transport protocol, such as those of the NTLP, in order to send or distribute control messages to all charging processes involved in the performance of the service. The charging processes which are implemented on the individual network elements are controlled using these control messages. In the terminology of the NSIS, a charging process corresponds to what is known as an NSIS Entity NE and the messages correspond to signaling messages based on the NSIS concept. In this case, an NE is a function within the network element which (function) implements or supports an NSIS protocol. In another embodiment of the disclosed method, the control messages are forwarded from one network element to the next network element along a data path initiated by the service. As already mentioned, the charging processes which are implemented on the respective network elements and which are involved in the performance of the service or the application are controlled using the control messages. The control messages can be used to transmit instructions about the charging processes' further behavior to the charging processes. By way of example, it is conceivable for some of the charging processes to be turned off. In addition, it is possible to ask charging processes to perform actions, such as metering transfer volumes.

In another embodiment of the disclosed method, it is conceivable for the charging processes involved in the performance of the service to insert additional information and instructions into the control messages.

In addition, individual charging processes can be asked to forward data which they have metered to another charging process or to an appropriate network element on which the charging process is implemented.

It is also conceivable for the disclosed method to send the control messages upon setup and/or during and/or upon cleardown of a connection initiated by the service.

In another embodiment of the disclosed method, the control messages are originally transmitted by a charging process involved in the performance of the service. In principle, it is conceivable for an arbitrary charging process arranged on the data path initiated by the service to send control messages to all other charging processes in the service. To prevent a plurality of charging processes or the relevant network elements on which the charging processes are implemented from distributing contradictory instructions, another particularly embodiment of the disclosed method prescribes a hierarchic stipulation for the individual charging processes involved in the performance of the service. This hierarchic stipulation governs how to handle the control messages transmitted by the respective charging processes and/or the instructions inserted into the control messages by the respective charging processes. This means that the hierarchic stipulation prescribes restrictions and rules regarding how control messages are to be classified or handled by individual charging processes. Precise information is given about which control messages are to be considered and handled as having priority by which charging process.

In another embodiment of the disclosed method, the hierarchic stipulation is prescribed for each service on a service-specific basis.

In addition, the hierarchic stipulation is distributed to all charging processes involved in the performance of the service on the individual network elements, preferably using a control message.

Preferably, the hierarchic stipulation is distributed by a network element which is authorized to do so on the basis of a table stored in each network element on which a charging process involved in the performance of the service is implemented. This means that the hierarchic stipulation can be distributed only by specific network elements or charging processes implemented thereon. The hierarchic stipulation is met by a network administrator. Network elements which receive a control message can then use their stored table to establish whether or not the sending element, that is to say the sender is authorized.

Charging processes are synchronized whenever a service is performed. Accordingly, a different configuration for the charge metering is possible on the basis of specifically relevant parameters whenever a service is performed. In this context, relevant parameters may be user data, utilization level of the communication network or nature of the terminal point or terminal.

In another embodiment of the disclosed method, the control protocol is used to send all charging processes involved in the performance of the service a data request message which includes a listing of data required for service-oriented charging and a destination address for a charging process, which is specifically selected as the metering process and which is involved in the performance of the service, to which the requested data need to be sent. The charging processes respectively react to the data request message by sending the requested use data, which they are respectively able to provide, in the form of a transport message using a transport protocol directly to the metering process. This means that provision is preferably made for use data for a service to be metered by precisely one charging process or metering process. This metering process is subsequently called the primary metering process. In this context, the primary metering process sometimes requires use data which can be provided only by other charging processes. By way of example, an application computer could have neither the transfer volume nor the type of access network or the “MSISDN” of a subscriber in question. Since these data are indispensable for service-oriented charging, however, these data need to be transported to the primary metering process, these being requested in line with the disclosed method by the control protocol.

A method is known from 3GPP in which data from an SGSN can be transported to a GGSN using a signaling message. In this case, the signaling message is transported via a Gn interface existing within the context of PDP context signaling. In contrast to this, the disclosed method does not involve the use data being transported by signaling messages via the entire data path initiated by the service, but rather involves them being routed from the respective charging processes directly to the metering process.

In one embodiment of the disclosed method, the required data are sent to the metering process using a standard transport protocol, particularly what is known as an IPFIX.

Preferably, the data required for service-oriented charging are metered and processed or evaluated by the primary metering process.

Also disclosed is a method which can be used to determine a network node or a network element from a plurality of network nodes and network elements, on which network node or on which network element a charging process is arranged, and to stipulate to which network node the function of a primary metering process in the aforementioned sense is transferred.

When the need for configuration of the charge metering processes has been identified by what is known as the NSIS Initiator NI, a primary metering process needs to be started. This primary metering process does not necessarily need to take place on the NI. By way of example, an overload or lack of power at the network node on which the NI is situated may require the function of the charging process, as primary metering process, to be moved to another node of the same type which has sufficient power. In addition, the characteristics of the NI may mean that the NI is not able to run a primary metering process. In this case, it is necessary to move the primary metering process to a different kind of network node. It may be necessary to move a charging process before and during the service's runtime.

The need to transfer a primary metering process can be established by the NI or the network node, subsequently called the “transferrer”, on which the charging process is currently situated from the fact that the transferrer or the NI is overloaded, for example.

It is also conceivable for there to be a rule which states that the NI is not intended to be the primary metering process.

In addition, it is possible for a rule to stipulate that the NI does not have some functions which would be required for a primary metering process, and for this reason for the primary metering process to have to be transferred to another network node.

A request from another network node for transfer may also result in the primary metering process being transferred.

When the transferrer, that is to say the network node on which the primary metering process is currently situated, has established that the primary metering process needs to be transferred, it needs to ascertain a network node to which it can transfer the primary metering process. This network node is subsequently called the “recipient”.

Preferably, network-element-specific characteristics and/or prescribed rules mean that a network element is selected as a recipient on which the primary metering process is arranged or to which the primary metering process is transferred by a first network element, that is to say the transferrer.

In one embodiment of the disclosed method, the recipient is in this case stipulated by a rule. This applies particularly when the need for moving has been stipulated by a rule. In addition, the rule may also be used when the transfer on account of overload or missing functions is taking place, however. In this context the rule preferably also contains statements indicating how the transfer needs to be made.

The rule can contain the destination address of the recipient, inter alia. In this case, the transferrer sends a “transfer request message” to the destination address of the recipient. The recipient responds with a “transfer response message” and notifies the transferrer whether it wants to execute the primary metering process. If this is the case then the transferrer sends all data required for this to the recipient using a data transfer message. When the recipient has acknowledged receipt, the transfer operation is complete. Should the first recipient asked not wish to undertake the primary metering process then it is possible to apply other methods, for example stipulated by the rule. Should the primary metering process not be able to be transferred then the service can be terminated or performed at no charge.

In another embodiment of the disclosed method, the rule stipulates an address range for which a request is to be made. The “transfer request message” is then sent to this address range. The rest of the process then takes place as described in the previous paragraph. All recipients can then respond to the request and hence request the transfer of the primary metering process. The transferrer decides to which possible recipient the primary metering process is to be transferred. This can be done according to the order in which the responses arrive, for example.

In another embodiment of the disclosed method, the rule stipulates the type of recipient, such as a routing computer. In this case, the “transfer request message” is sent only to this type of network node. For this purpose, a bit string describing the various types of network nodes is stipulated, for example. Each network node which receives the message can evaluate the bit string so as easily to establish whether the message was intended for this type of network node. The rest of the process then takes place as described above.

Should the rule not have made a stipulation or should the processes stipulated by the rule have been unsuccessful then in another embodiment of the disclosed method the transferrer can send a “general request message” through the network. This message is then distributed by the entire network. All recipients are than able to respond to the request and hence to request transfer of the primary metering process. The transferrer decides to which recipient the primary metering process is to be transferred. This can be done according to the order in which the responses arrive, for example.

Should the transfer be made during performance of the service then it is necessary to synchronize the turning-on and turning-off of the metering on the transferrer and recipient. For this purpose, the recipient sends a “start message” to the transferrer and in so doing notifies it of the point from which the recipient started charge metering. The transferrer then sends the recipient the resource use ascertained up to this time.

The “transfer request message” specifies the full requirements to the recipient. This ensures that the recipient can actually execute the primary metering process.

One great advantage of the disclosed method can be seen in that an existing method which is evidently reaching the limits of its power is replaced by a new method. In this context, the disclosed method is thus complex. The actual charging process involves fewer network elements, which means that, possibly even several times, it would be necessary to gather less data relevant to charging overall. Efficiency is also higher in this case. Whereas previously a series of charge-related data was first of all gathered and then discarded, the disclosed method involves only data which are actually required being gathered. In addition, the disclosed method is very flexible—new services can quickly be integrated into the communication network when the basic method described is supported. Since the disclosed method can operate on the IP 3 layer, which is common to all packet services, it is universally applicable and does not need to be adapted to suit each packet service.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects and advantages will become more apparent and more readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:

FIG. 1 is a schematic illustration of an embodiment of a cycle of a method described below;

FIG. 2 is a schematic illustration of another embodiment of a cycle of the method.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout.

FIG. 1 shows a schematic illustration of very simple possible signaling in a GPRS communication network. Between a terminal point 1, acting as recipient, and a terminal point 2, as sender, there runs a simple data stream initiated by a service, which is then identified by a thin black arrow. In this case, the data stream passes through a series of network elements or network nodes i (i=1, 2, 3). The figure shows only those network elements or network nodes in which it is possible to meter charges incurred on the basis of performance of the service—that is to say that respective charging processes are implemented in these network elements. In line with the terminology of NSIS, the charging processes are NSIS Entities NE, which support an NSIS signaling protocol NSLP (NSIS Signaling Layer Protocol) and are able to interchange NSIS messages. In the case shown here, all the involved network elements shown include a respective charging process GP i (i=1-5). Even terminal points 1 and 2 include a respective charging process GP1 and GP5.

To synchronize the distributed charging processes GP1-GP5, a control protocol is used, e.g. an “Accounting NSLP”. This can be used to interchange control messages between the individual charging processes GP1-GP5, which is indicated by the thick light arrows running between the individual network elements, including the terminal points 1 and 2. This control protocol uses the mechanisms of a general transport protocol, e.g. of the NTLP, to distribute the control messages to all charging processes GP1-GP5 along the data path. In this case, the transport protocol is shown by a dark, thick arrow passing through all network elements. The control messages are forwarded from one network element to the next along the data path for the application or service. The charging processes GP1-GP5 taking place on the individual network elements are controlled by the control messages in the control protocol. Hence, the charging processes GP1-GP5 can be sent instructions about their further behavior. For example some of the charging processes can be turned off and others can be requested to perform actions, such as metering transfer volumes. In addition, the individual charging processes GP1-GP5 can insert additional information or instructions into the control messages. Furthermore, individual charging processes can be asked to send metered data to another network element. The control messages may be sent in the connection setup phase or else during the connection or when it is cleared down. In principle, any charging process GP1-GP5 on the data path can send control messages to all charging processes GP1-GP5. To prevent a plurality of network elements or charging processes GP1-GP5 implemented thereon from distributing contradictory instructions, a hierarchic stipulation can be made which stipulates restrictions and rules. This hierarchic stipulation may be prescribed for each service and distributed using a control message. Advantageously, hierarchic stipulations can be distributed only by specific network elements or charging processes. Network elements or charging processes which receive a control message may then use an internal table stored on them, for example, to stipulate whether or not the sender of the control message is authorized.

FIG. 2 shows another of a cycle in the disclosed method. This figure also shows a schematic illustration of very simple possible signaling in a GPRS communication network. Between a terminal point 1, acting as recipient, and a terminal point 2, as sender, there runs a simple data stream initiated by a service. In this case, the data stream passes through a series of network elements or network nodes i (i=1, 2, 3). The figure shows only those network elements or network nodes in which it is possible to meter charges incurred as a result of performance of the service—that is to say that respective charging processes GP2-GP4 are implemented in these network elements. The terminal points 1 and 2 likewise include charging processes GP1 and GP5. To synchronize the distributed charging processes GP1-GP5, a control protocol is used, e.g. an “Accounting NSLP”. This can be used to interchange control messages between the individual charging processes GP1-GP5, which is indicated by the thick light arrows running between the individual network elements, including the terminal points 1 and 2. This control protocol uses the mechanisms of a general transport protocol, e.g. of the NTLP, to distribute the control messages to all charging processes GP1-GP5 along the data path. In this case, the transport protocol is shown by a dark, thick arrow passing through all network elements. The control messages are forwarded from one network element to the next along the data path for the application or service. The charging processes GP1-GP5 taking place on the individual network elements are controlled using the control messages in the control protocol.

Provision is advantageously made, when synchronizing charging processes, for all use data for a service to be metered by precisely one charging process, subsequently called the primary metering process. That charging process which is intended to meter the use data, that is to say the primary metering process, sometimes requires use data which can be provided only by other charging processes. By way of example, an application computer can have neither the transfer volume nor the type of access network or what is known as a subscriber's MSISDN. Since these data are indispensable for service-oriented charging, however, these data need to be transported to the selected primary metering process.

In the case illustrated here, the use data are not transported by signaling messages via the entire data path initiated by the service but rather are transferred from the respective charging processes GP1-GP4 directly to the metering process, which in this case is implemented in the terminal point 2. For this purpose, the charging process which undertook metering, that is to say the primary metering process, notifies the other charging processes GP1-GP4 of which data they need to transfer to it. In the case illustrated here, the primary metering process asks GP1 for information about the type of access network, asks GP2 for the user's MSISDN and asks GP3 for the transfer volume, for example. So that the other charging processes GP1-GP4 can send the data to the primary metering process, the latter notifies them of its address, which in this case is indicated by the character string 192.68.99.105. The data request and the destination address are transferred to the charging processes GP1-GP4 using the control protocol, such as an Accounting NSLP.

The charging processes GP1-GP4 then send the requested data to the primary metering process in the form of transport messages using a standard transport protocol, such as IPFIX (IP Flow Information Export).

A description has been provided with particular reference to embodiments thereof and examples, but it will be understood that variations and modifications can be effected within the spirit and scope of the claims which may include the phrase “at least one of A, B and C” as an alternative expression that means one or more of A, B and C may be used, contrary to the holding in Superguide v. DIRECTV, 358 F3d 870, 69 USPQ2d 1865 (Fed. Cir. 2004).

Claims

1-25. (canceled)

26. A method for synchronizing charging processes involved in performance of a service or an application on individual network elements in a communication network, comprising:

distributing to each charging process involved in the performance of the service or the application, via a control protocol using mechanisms of a transport protocol: control messages containing dedicated information specific to each charging process, a data request message which includes a listing of required data for service-oriented charging and a destination address for a primary metering process which is involved in the performance of the service and to which the required data need to be sent; and

sending the required data to the primary metering process using a standard transport protocol.

27. The method as claimed in claim 26, wherein the standard transport protocol is an internet protocol flow information export.

28. The method as claimed in claim 26,

wherein said distributing includes forwarding the control messages from one network element to a next network element along a data path initiated by the service, and

wherein the charging processes which are implemented on respective network elements and which are involved in the performance of the service or the application are controlled by the control messages.

29. The method as claimed in claim 28, wherein the charging processes involved in the performance of the service insert additional information and instructions into the control messages.

30. The method as claimed in claim 29, wherein the control messages are sent at least one of upon setup, during use and upon cleardown of a connection initiated by the service.

31. The method as claimed in claim 30, wherein the control protocol used is an NSIS accounting signaling layer protocol based on an NSIS transport protocol, and the control messages used are messages based on NSIS.

32. The method as claimed in claim 31, wherein the control messages are originally transmitted by one of the charging processes involved in the performance of the service.

33. The method as claimed in claim 32, wherein a hierarchic stipulation for the individual charging processes involved in the performance of the service is prescribed which governs how to handle at least one of the control messages transmitted by respective charging processes and the instructions inserted into the control messages by the respective charging processes.

34. The method as claimed in claim 33, wherein the hierarchic stipulation is prescribed for each service on a service-specific basis.

35. The method as claimed in claim 34, wherein the hierarchic stipulation is distributed to all charging processes involved in the performance of the service on the individual network elements using one of the control messages.

36. The method as claimed in claim 35, wherein the hierarchic stipulation is distributed by a network element which is authorized to do so based on a table stored in each network element on which one of the charging processes involved in the performance of the service is implemented.

37. The method as claimed in claim 36, wherein the primary metering process meters and processes charging data required for service-oriented charging.

38. The method as claimed in claim 37, wherein at least one of network-element-specific characteristics and prescribed rules are taken as a basis for selecting a metering network element on which the primary metering process is arranged or to which the primary metering process is transmitted by an initiating network element.

39. The method as claimed in claim 38, wherein the metering network element is selected by a rule.

40. The method as claimed in claim 39, wherein the rule contains statements indicating how the primary metering process is to be transmitted.

41. The method as claimed in claim 40, wherein the rule stores one of a destination address and a destination address range for at least one recipient network element selected and to which the primary metering process is to be transmitted by the initiating network element.

42. The method as claimed in claim 41, further comprising:

sending from the initiating network element a transmission request message to the at least one recipient network element; and

responding by the at least one recipient network element using a respective transmission response message which contains information regarding whether the primary metering process can be executed.

43. The method as claimed in claim 42, further comprising if the primary metering process can be executed by the at least one recipient network element:

transmitting all data required therefor a data transmission message from the initiating network element to the at least one recipient network element; and

acknowledging receipt of the data transmission message by the at least one recipient network element.

44. The method as claimed in claim 42, further comprising, if the primary metering process cannot be executed by any of the at least one recipient network element; terminating the service.

45. The method as claimed in claim 42, further comprising, if the primary metering process cannot be executed by any of the at least one recipient network element; performing the service at no charge.

46. The method as claimed in claim 42, further comprising, if the primary metering process can be executed by a plurality of the at least one recipient network element, deciding by the initiating network element using a selection criterion, to which of the network elements all data needed for executing the primary metering process are transmitted.

47. The method as claimed in claim 46, wherein the selection criterion is the order of arrival of respective transmission response messages from respective ones of the at least one recipient network element.

48. The method as claimed in claim 47, wherein the rule includes a bit string identifying a network element type suitable as a recipient.

49. The method as claimed in claim 38, further comprising:

deciding by the initiating network element using a selection criterion, at least one recipient network element to which all data needed for executing the primary metering process are transmitted;

sending by the initiating network element a general transmission request message through the network to the at least one recipient network element; and

responding by the at least one recipient network element using a respective transmission response message to provide notification of an ability to execute the primary metering process.