RU2262807C2 - System and method for payments in telecommunication network - Google Patents

Abstract

FIELD: telecommunications.

SUBSTANCE: method includes optimizing combination of event data, and excluding unnecessary transfer of detailed event records from one network object, responsible for data-gathering, to another.

EFFECT: detailed records of events, related to one session, but generated by several different network nodes, are sent in centralized manner in real time to data-gathering network node.

3 cl, 7 dwg

Description

Technical field

The present invention relates to payment in a telecommunications network.

State of the art

The third generation mobile communication system is called UMTS (Universal Mobile Telecommunication System) in Europe. It is part of the IMT-2000 system of the International Telecommunication Union. UMTS / IMT-2000 is a global multimedia radio communication system that provides a higher transmission speed (2 Mbps) than existing mobile networks.

UMTS and GPRS (common packet radio services) in the global mobile communications system (GSM) are designed to provide packet-switched, as well as circuit-switched, radio communications services.

Figure 1 shows a very simplified diagram of a UMTS network. Only those network elements that are essential to the present invention are shown. Of course, the network may contain one or more of each network elements described hereinafter, depending on the capacity of the element, the number of mobile subscribers and the organization of the network.

User terminals 100 may be multi-mode terminals that can operate using at least two radio access technologies, such as, for example, UMTS and GSM standards.

The GPRS Support Gateway Node (GGSN) 102 is a gateway for external networks, and it acts as a router sending data packets to and from the GPRS support node currently serving this GPRS terminal.

The Serving GPRS Support Node (SGSN) 101 is at the same hierarchical level as the Mobile Switching Center (MSC). It maintains the location information of the GPRS terminal in its service area and performs the functions of providing security and user access control. During data transfer, the serving GPRS support node sends data packets to a specific terminal and receives data packets from this terminal through the base station subsystem. The serving GPRS support node requests routing information and subscriber information from the home location register 103 (HLR), where all subscriber information is constantly stored.

The UMTS specification allows a subscriber to have one or more Packet Data Protocol (PDP) addresses. Each address is described using one or more packet data protocol contexts in a user terminal serving a GPRS support node and a GPRS gateway support node. The context of the packet data protocol can be selectively and independently activated, modified, and deactivated. All user packet data protocol contexts are associated with the same mobility management (MM) context for the international mobile station subscriber identity code (IMSI) of that subscriber. When the packet data protocol is installed, it means that the communication channel is installed.

1, the serving GPRS support node and the gateway GPRS support node are located in the same domain A. When a connection is to be established between the subscriber and, for example, the Internet 108, the first step is that the mobile terminal 100 sends an active context request packet data protocol through a radio access network (RAN) 106 to a serving GPRS support node 101. The message includes many parameters, which further include the packet data protocol address and the access point name (APN). The access point name is a logical name that refers to the GPRS support gateway node used. In the present description, the access point name refers to the gateway node 102 support GPRS, through which data packets are routed between the mobile terminal and the Internet. Various messages are sent between said network elements before the connection is completed.

The collection of event (call / session) details is always used when certain detailed information about the event (call / session) is required for billing or to control the detailed features of the event (call / session). Thus, each of the network elements collects data related to each call / session until a certain predetermined limit is reached. The limit is a certain amount of data, time, or other determined values of a trigger signal, for example megabytes. The network element then generates a detailed event record and sends it using the active protocol through the Internet Protocol (IP) network 107 to the payment gateway function 104 (CGF1). Typically, at least the following network elements generate detailed event call records: a serving GPRS support node, a GPRS gateway support node, a call state management function (CSCF), and application server (s) in radio access networks, such as a GPRS access network (GERAN) or UMTS terrestrial access network (UTRAN), the latter being the broadband radio access multiple access network currently described in 3GPP (Third Generation Partnership Project). Typically, during a single session, each of these network elements generates a series of detailed event call records related to the session.

The payment gateway function receives, for example, four detailed records of events related to the same session from the serving GPRS support node and four from the GPRS support gateway, and then combines them using the sequence number found in each detailed event record. A formatted detailed event call record is sent from the payment gateway function to the billing center 105 for processing.

A number of problems arise if the method described above is used as such in the latest version of the third generation mobile communication system. Some of the problems are briefly described hereinafter with reference to fig.1b.

Several million detailed event records are constantly generated in each network element, such as a serving GPRS support node 101, a GPRS support gateway node 102, a CSCF call state management function 109, an application server 110, or some other network elements N 111. Then, each of the network elements independently transmits detailed call records to function 112 of the payment gateway CGF1-CGFN. The problem is that there is currently no mechanism that could automatically automatically centralize directly all detailed event records related to a single session in real time for a specific payment gateway function (e.g. CGF1) in the network / domain of interest. Conversely, detailed event records are routed to a large number of different payment gateway functions. This leads to a problem in how to combine these detailed event records related to the same session / call. One solution is to use an autonomous device, the so-called pick, to collect and combine detailed event records before sending them for further processing to the billing center 106. Combining detailed event records in a mediator is quite complex and time-consuming.

One solution is to use a unique session identifier to combine the correct detailed event records. This type of solution is described in a previous patent application US 09/577152 of the same applicant, which was not published by the date of registration of this application. The identifier is called the global transaction ID (unique session identifier).

However, this solution does not solve the aforementioned problem, which is time consuming, i.e., various network elements still send detailed event records to various gateway payment functions.

SUMMARY OF THE INVENTION

The present invention relates, in General, to the collection and management of detailed event records (CCD) (related to payment, control, legal listening, etc.) in a telecommunication network and, in particular, to deferred and pre-made payment based on detailed event records in the third generation mobile communication network.

The objective of the invention is to create a solution through which detailed event records related to a single session, but generated by a number of different network elements, are sent in a centralized manner in real time to a specific network object that collects data. Thus, the integration of event data is optimized and the unnecessary transmission of detailed event records from one network object collecting data to another is eliminated. The problem is solved by the method and system described in the independent claims.

The idea of the invention is the collection of specific session data in a specific network object for collecting data when user connections are established during a session through a series of network objects generating detailed event records and having a mutual signaling connection.

Each of the network objects generating detailed event records in the domain / network has a corresponding table that includes the set addresses of network objects collecting detailed event records. The address of the network entity collecting the data is universally unique.

During the connection setup, the network entity that receives the connection / session setup request selects an address for the network entity collecting data from the table and offers this address to network entities generating detailed event records by inserting the address with a unique session identifier into the alarm A message sent to the next network entity that generates detailed event records.

When a network entity that generates detailed event records receives a suggested address, it checks to see if the address is configured in the table of network entities that collect data.

If the proposed address matches the primary address of the network entity collecting the data in the configured table, the network entity sends a message further to the next network entity.

If the proposed address does not match the primary address of the network entity collecting the data in the configured table, the network entity checks to see if the next address in the table, etc. If the address is found, the message is sent to the next network entity, as mentioned above.

If the proposed address is not found in the table, the said network object selects the address of the main network object that is collecting data from the table, replaces the proposed address with it, and sends a message to the next network object.

In cases where the proposed network object that is collecting data is not used or does not respond, then this network object replaces the proposed address with the next address from the configured table and sends a message to the next network object.

All detailed event records related to this session / call are sent in real time during the session / event to the same address of the network object collecting the data selected in this way.

The combination of detailed session-related event records is performed using a unique session identifier in this particular network entity collecting data.

Thus, detailed event records generated from several network objects associated with one session / call are centralized in the same network object collecting data. This speeds up the actual aggregation of detailed event records.

The proposed solution is dynamic and simplifies the transfer of detailed records of events on the network, regardless of whether the network objects are in the same or different networks / domains.

Brief Description of the Drawings

The invention is described in more detail with reference to the drawings, which represent the following:

figa is a simplified diagram of a third generation mobile communication system;

fig.1b - a solution known from the prior art, providing the sending of detailed call records in a telecommunication network;

figure 2 is a block diagram of an example implementation of a method in accordance with the invention;

3 is a signaling diagram illustrating an example of setting up a primary connection;

4 is an illustration of the transmission of the address of the payment gateway in one domain in a third generation mobile communication network;

5 is an illustration of the transmission of the address of the payment gateway in one domain in a third generation mobile communication network;

6 is an illustration of the transmission of a payment gateway address in two domains in a third generation mobile communication network.

Detailed Description of a Preferred Embodiment

The following describes the dynamic collection and real-time management of detailed event records in a third-generation mobile communication system or ALL-IP network (3GPP version 5). However, it is understood that the invention is not limited to ALL-IP UMTS networks, but can also be applied to any type of network where there is a need to use the dynamic collection and real-time management of detailed event records.

The idea of the method described below is to concentrate the transmission of detailed event records created in various network elements of a telecommunication network in a specific network object that collects data. Further, detailed records of events will also be called CCD, the serving GPRS service support node will be called OPU, the GPRS gateway support node will be called SHUP, the payment gateway function will be called FSHO, the application server will be called SP and the call status management function will be called either FUSW or COB (call processing server).

The invention is now described in detail using some examples with reference to FIGS. 2-6. In the following examples, event data is billing data, and network entities are network elements.

Figure 2 illustrates a method for implementing the functionality necessary to improve payment efficiency.

To solve the problem of combining time-consuming payment data and unnecessarily transmitting detailed event records between different functions of a payment gateway, each network element in a domain / network sends CCDs associated with one session / call to the same FSO. Thus, the network elements of the OPU 201, the STUP 202, the application server 203 and the OWL 204 transmit all the CCDs through the Ga interface in the ALL-IP UMTS network to FSO 205.

It is important to note that this is just a very simplified example. Globally, the UMTS network contains various network elements, each of which constantly generates millions of detailed event records.

In Fig. 3, an example of setting up a voice call is considered. The signaling diagram depicts the establishment of a basic connection in a 3GPP version 5. network. The signaling messages mentioned in the present description are merely examples, and many other types of signaling messages can also be used. This example indicates only one of the possible ways to transfer the FSO address between network elements exchanging signaling messages related to the call / session. Alternatively, the user terminal could also participate in the process of transmitting a unique session identifier and FSO address.

Signaling during call setup is symmetrical between the calling party and the application server, on the one hand, and between the application server and the called party, on the other hand. Therefore, it is enough to consider only one side of the signaling diagram.

It is assumed that the packet data protocol (PDP) context is activated. As already mentioned above, each packet data protocol context can be selectively and independently activated, modified, and deactivated.

The calling party, the mobile subscriber A, wants to make a voice call to the called party, which in this particular example may be another mobile subscriber B. Despite the voice call, the connection can also be a session, i.e. from a subscriber to a video server, or a network game, etc., depending on the user terminal and service providers.

The user terminal sends an INVITATION message 300 to the FUSW call state control function or, more precisely, to the authorized U-FUSW call state control function via the serving radio access network CP OUPU and SHUPU.

The function of managing the call state of the FUSW can be divided into two logical parts, i.e. FUSW may act as an authorized FUSW or serving FUSW (O-FUSW). FUSW manages several functionalities: acting as the first entry point, performs routing of incoming calls; It reports call events for billing, auditing, listening, or other purposes; it can provide a server startup mechanism; It accepts and processes application level registrations. it notifies the base domain of the user's initial access (for example, the FUSW signal transmission address and user ID).

U-FUSW is the first contact point for the user terminal in the multimedia subsystem of the Internet protocol. Each user terminal always has an authorized FUSW associated with it and located in the same network.

Message 300 "INVITATION" is the request "I want to establish a voice call connection with subscriber B". In response to the received message, the authorized FUSW generates a unique call ID, identifies the payment gateway from the configured list that is used as the initial payment gateway, to which all CCDs generated during the call are sent (step 301). These two unique parameters are stored in memory, and the parameters are also added to the received message. The call ID is available for the CCD of the multimedia subsystem of the IP core network.

From this moment, the mentioned payment gateway should be called by the name of the proposed function of the payment gateway proposed by the FSO or the proposed address of the FSO IPv6 (IPv6 = Internet Protocol version 6).

At step 302, the U-FUSW sends a SIP invitation message, including the call ID and IPv6 address of the proposed payment gateway to the O-FUSW, where the call / session conditions are processed. Then U-FUSW begins to establish a call connection. The call ID is available for the CCD of the multimedia subsystem of the IP core network.

Session Initiation Protocol (SIP) is an application layer signaling protocol for establishing sessions on an IP network. A session can be a simple two-way phone call or a multimedia conference call. SIP is a protocol for creating, modifying, and terminating sessions with one or more participants. It also supports user mobility and forwards requests to the user's current location.

U-FUSW analyzes the destination address and determines whether the subscriber belongs to the operator of the same or another network. U-FUSW also checks whether the proposed FSO address matches the original FSO address in the configured FSO address list. If the result of the comparison is positive, i.e. the addresses are the same, all the CCDs created in the U-FUSW relating to this particular call will be transmitted to the proposed FSO address. The proposed FSO address is included in the messages between the various network elements related to this particular call, at the beginning and during the call setup phase. Verification of the proposed FSO address from the configured FSO list is repeated from now on by each network element receiving messages related to this call.

If the proposed address does not match the original address of the payment gateway function in the configured list, the network element selects the next address of the payment gateway function from the list, replaces the proposed address with it, and sends a message along with a unique session identifier to the next network element.

Also, in cases when the proposed function of the payment gateway is not used or does not respond, this network element replaces the proposed address with the next address from the configured list.

Then, at step 303, the SIP INVITATION message is sent along with the call ID and IPv6 address of the proposed payment gateway from U-FUSW to the application server. The call ID is available for the CCD of the application server. The application server confirms the received message by sending message 304 ANSWER to U-FUSW.

In response, the U-FUSW sends a SIP INVITATION message 305, including the call ID and IPv6 address of the proposed payment gateway, to the interconnected FUSW (U-FUSW). U-FUSW is the point of contact in the operator’s network for all connections directed to the subscriber of this network operator. The call ID is available for the CCD of the multimedia subsystem of the IP core network.

The first task is to determine where the called subscriber is located and whether the subscriber’s mobile terminal is free to receive a voice call.

When the location of the mobile terminal has become known and it is free to receive a call, a CONFIRMATION message 306 informing that the connection can be established is sent from a network element, such as U-FUSW, located on the network of some other operator. The message is sent through FUSW, SHUPU and OPUP to the user terminal of subscriber A.

Until now, messages between the aforementioned network elements have been transmitted through signaling channels, i.e. a traffic channel has not yet been allocated. The messages at the bottom of the signaling diagram are needed to route the data / traffic medium.

At step 307, the user terminal sends to the FUSW the message “REQUEST - activate the secondary PDP protocol context”, and the FUSW transmits the message 308 “REQUEST - create the PDP protocol context” to the ACUP. In response to the received message, the SHUPU generates a payment ID, which is available for the OUPU and the CUP of the SHUPU. After that, the control will send a message 309 "REQUEST authentication" in the U-FUSW, which can be based, for example, on the messages of the COPS protocol (protocol of the strategy of common open services).

The strategy management function is a logical element, and it controls which packets are allowed to pass through the control system. In response to the message, the U-FUSW informs the SHUPU of its decision regarding the resolution of the activation of the PDP context by sending the message “SOLUTION” 310, which includes the call ID and IPv6 address of the proposed payment gateway. This call ID is available for the CCD CO (processing server).

The next step is that the control will respond to the control with the message 311 "ANSWER - create PDP protocol context", which includes the call ID, payment ID and IPv6 address of the proposed payment gateway. Call ID and pay ID are available for CCD. At step 312, the OPU sends a “RECEIVE - Enable Secondary PDP Protocol Context” message to the user terminal.

All CCDs related to this call are sent automatically from each of the network elements described above to the proposed FSO.

Hereinafter, the present invention is illustrated using three examples with reference to figures 4-6.

Figure 4 illustrates the process of sending a unique address of a payment gateway used in a single domain in a third generation mobile communication system. The unique call ID is also transmitted along with the address of the payment gateway, as described above.

The numbering in FIG. 4 corresponds to the numbering in FIG. 1, so that the network elements and networks 100-108 correspond to network elements and networks 400-408. The register 403 of the initial subscription services is expanded by the register of the initial location.

The PDP packet data protocol context is activated, i.e. a signaling channel is created between the user terminal 400 and the call state control function 409. The user terminal requested a connection with the called party. Alternatively, it may be desirable for a subscriber or user terminal to connect to an application server that serves multimedia, video, games, etc. Alarm messages needed when a connection is established are sent through the OPU 401 and the STUP 402 to the FUSW. The CSCF analyzes the content of the received message, for example, a call setup request, and performs actions such as transmitting the request to the CSCF located on another operator’s network. In FIG. 4 shows that each of the network elements, i.e. OUPU 401, SHUPU 402 and FUSV 409, has a configured address list 410-412 functions of the payment gateway. FUSW selects from the list 410 the address of the function of the payment gateway FSHO1, used by all the network elements involved in this session. The proposed address of the payment gateway function is sent together with the message to the OPU, which, in turn, sends it together with the message to the OPU. Message transmission and verification of the proposed payment address is performed as described above. Lists in network elements correspond to each other.

5 also illustrates the process of sending a unique address of a payment gateway in a single domain in a third generation mobile communication system. In the drawing, the PDP packet data protocol context is activated between the user terminal and the application 500, and the connection between the user terminal and the application is established and activated. FUSW informs the application in the message (described in figure 3) about the proposed FSO used during the connection. Messages between the FUSW and the application are sent at the application level.

6 illustrates the process of sending a unique address of a payment gateway in two domains of a third generation network.

Operator A owns the network in domain A, and operator B owns the network in domain B. The configured lists differ from each other in the network elements of different network owners. FUSV 409 offers the address FShO5 in SHUPU 402, but SHUPU does not find the proposed address from its own list. In this case, SHUPU selects the primary function of the payment gateway FShO1 from its list, replaces the address FShO5 with its address and transmits a message to SHUPU.

A subscriber can have several active calls / sessions at the same time, such as voice call, email, video session. Using a unique identifier, it is possible to track in detail the generated payment information, for example, to distinguish from the payment information how much data was transferred during a voice call, email, or video session.

Using a unique session identifier along with a unique payment gateway address that is sent from one network element to the next network element, you can realize fast, clear and dynamic payment, as well as actions related to monitoring, statistics collection and legitimate listening.

Although the invention has been especially developed for use in a third generation mobile communication system, it is not limited to use for such a system. It is obvious that the described method and system of payment can be installed on any type of network. Of course, the user terminal can also be of any type. In addition, the unique session identifier and the FSO address can be delivered to the user terminal, and then to other network elements generating payment data, in order to ensure that the unique session identifier and the FSO address are delivered to all these network elements involved in this session / call.

The implementation and embodiments of the present invention are explained above with various examples. However, it is understood that the invention is not limited to the above details of the embodiments and that numerous changes and modifications can be made by those skilled in the art without departing from the spirit of the invention. The described embodiments are to be regarded as illustrative, but not restrictive. Therefore, the invention should be limited only by the attached claims. Thus, alternative implementations defined by the claims, as well as equivalent implementations are included in the scope of the invention.

Claims (20)

1. A method of collecting event data related to a communication session in a network, in which user connections during a communication session are established through a series of network objects generating event data and having a mutual signaling connection, characterized in that it includes the following steps performed in each from network objects generating event data related to the connection: remember the set of addresses for network objects collecting event data, select one address from the set of addresses during installation with unity and send event data generated at the time of connection in the network entity performing the data collection events having a selected address. 2. The method according to claim 1, characterized in that the address of the object collecting the data is universally unique. 3. The method according to claim 2, characterized in that it includes the following steps that are performed during connection setup in a network entity generating event data: receive a request to establish a communication session / connection and offer the selected address as the proposed address, at least , another network entity generating event data by inserting the selected address into the signaling message. 4. The method according to claim 3, characterized in that a universally unique identifier related to the said session is inserted into the signaling message. 5. The method according to claim 3 or 4, characterized in that it includes the following steps performed in another network entity that generates event data: receive a signaling message that includes the proposed address, and compare the proposed address with at least the primary address from the stored address set, while at the mentioned address selection step, the selected address is the proposed address, if the proposed address is found in the stored address set, and the selected address is the address from the stored address set ow if the proposed address is not found in the saved address set. 6. The method according to claim 5, characterized in that the selected address is the primary address from the stored set of addresses, if the proposed address is not found in the stored set of addresses. 7. The method according to claim 6, characterized in that it includes sending a signaling message containing the selected address to at least the next network entity. 8. The method according to claim 1, characterized in that it includes the selection of the next address from the stored set of addresses if the network entity collecting the event data does not respond or is not used. 9. The method according to claim 1, characterized in that the network objects are network elements. 10. The method according to claim 1, characterized in that it includes the use of a user terminal to forward the selected address between network entities that generate event data. 11. The method according to claim 1, characterized in that the contents of the plurality of addresses are identical, at least in network objects in the same domain. 12. The method according to claim 1, characterized in that the contents of the plurality of addresses are identical, at least in network objects in the same network. 13. The method according to claim 1, characterized in that the stored set of addresses of network objects generating event data is presented in the form of a table. 14. The method according to claim 1, characterized in that the event data includes payment data. 15. A communication system comprising at least network routing objects, network objects generating event data, and network objects collecting event data, wherein each of the network objects generating event data comprises memory means for storing a plurality the addresses of network objects that collect data from events, a selection tool designed to select from multiple addresses a single address of a network object that collects data, signaling tools designed to transfer signaling the selected address as the proposed address between network entities generating event data, sending means for sending event data generated during the session to the address selected by the selection means. 16. The communication system of claim 15, wherein the network entities generating the event data comprise a comparison tool for comparing the proposed address with a plurality of addresses in the memory means, and the selection means is configured to select the proposed address if the proposed address is found in the stored a plurality of addresses, and addresses from a stored plurality of addresses if the proposed address is not found in the stored plurality of addresses. 17. The communication system according to clause 16, wherein the selection tool is configured to select a primary address from the stored set of addresses as the selected address, if the proposed address is not found in the stored set of addresses. 18. A network object for a communication system, comprising means for generating events for generating event data, characterized in that the network object further comprises memory means for storing a plurality of addresses of network objects collecting event data, a selection means for selecting from one of a plurality of addresses the addresses of the network object collecting data, signaling means for transmitting signaling about the selected address as the proposed address between network objects by those generating event data, and a sending means for sending event data generated during the session to the address selected by the selector. 19. The network object according to claim 18, characterized in that it comprises means of comparison for comparing the proposed address with a plurality of addresses in the memory means, and the selection tool is configured to select the proposed address if the proposed address is found in the stored plurality of addresses, and addresses from the stored multiple addresses if the proposed address is not found in the stored multiple addresses. 20. The network object according to claim 19, characterized in that the selection means is configured to select a primary address from the stored address set as the selected address if the proposed address is not found in the stored address set.

Images