RU2575873C2 - Method for communication between ip multimedia subsystem nodes - Google Patents

Abstract

FIELD: radio engineering, communication.

SUBSTANCE: disclosed is a method for communication between two nodes providing online charging functionalities in an IP multimedia subsystem (IMS) network, wherein a first node is configured to operate as a charging triggering function (CTF) and a second node is configured to operate as an online charging service (OCS).

EFFECT: method allows to alleviate drawbacks stemming from low availability of the OCS.

13 cl, 7 dwg

Description

FIELD OF THE INVENTION

The present invention relates to a communication method between two nodes providing real-time charging functionality in an IP multimedia subsystem (IMS) network. In particular, it relates to a communication method between a first node configured to function as a charging initiation function block (CTF) and a second node configured to function as a real-time charging service unit (OCS).

BACKGROUND

IP Multimedia Services (IPMM) provides a combination of voice, video, messaging, data, etc., during the same session. As the number of basic applications and media that can be combined increases, the number of services offered to end users will increase, and the potential for enriching the experience of interpersonal communication will increase. This will lead to a new generation of personalized, advanced multimedia communications services, including so-called “combinational IP-Multimedia” services.

IMS is a technology defined by the Third Generation Partnership Project (3GPP) to provide IP multimedia services in mobile networks. IMS provides opportunities to improve end-user end-user interaction through integration and interaction between services. IMS enables enhanced personal interactions between people (client-client), as well as between people and content (client-server) over an IP network. IMS uses the Session Initiation Protocol (SIP) to establish and manage calls or sessions between subscriber terminals (or subscriber terminals and application servers). Session Description Protocol (SDP), transmitted through SIP signaling, is used to describe and negotiate the media components of a session. While SIP was created as an inter-user protocol, IMS enables operators and service providers to control user access to services and accordingly charge users. Other protocols that are used for media transmission and control are the real-time transmission protocol and the real-time transmission control protocol (RTP / RTCP).

In the IMS network, call control function blocks (CSCFs) perform signaling processing and routing. CSCFs handle session establishment, change, and termination of IP multimedia sessions using the SIP / SDP protocol stack. The 3GPP specification TS23.228 describes the logical nodes P-CSCF, I-CSCF, S-CSCF, E-CSCF and BGCF. The S-CSCF complies with the 3GPP TS 24.229 specification and provides session management services for user equipment (UE). It maintains session state to support services and performs the following functions:

he acts as a registrar in accordance with [RFC3261] during registration;

he notifies subscribers of registration changes;

It provides session management for registered users;

it processes SIP requests and either serves them internally or forwards them to the next node; and

It interacts with IMS application servers.

The S-CSCF performs SIP routing in accordance with the 3GPP routing procedures.

Most SIP sessions in IMS, such as calls that are initiated by subscriber equipment, must be charged by the operator. The IMS architecture provides for two different pricing models: offline pricing and real-time pricing.

Real-time billing is based on the so-called prepaid subscription model. As a rule, the subscriber buys a certain amount of loans from the operator. If the SIP session is initiated by a SIP request sent from the subscriber equipment to the S-CSCF, the S-CSCF communicates with the application server by implementing the Tariff Initiation Function (CTF). The CTF function is described in the 3GPP TS 32.260 and 3GPP TS 32.299 specifications. It supports billing for users using IMS infrastructure and services. The CTF node determines whether the requested billing session is subject to or not. If the requested session is subject to billing, the CTF node communicates with the node of the real-time billing system (OCS), which stores the current subscriber credit. If the subscriber’s account contains sufficient credit to provide a SIP request, OCS responds accordingly to CTF, which satisfies the request. Similarly, if the loan is insufficient, the SIP request may be rejected, or a session may be provided for a limited amount of time.

The CTF and OCS nodes implement real-time billing functionality for the IMS architecture. Communication between CTF and OCS nodes is done through the Ro interface described in the 3GPP TS32.299 specification and is implemented using the DIAMETER protocol. More specifically, the CTF sends credit control request (CCR) messages over the DIAMETER protocol, while OCS responds with credit control response (CCA) messages over the DIAMETER protocol. These messages are described in RFC 4006.

Many developing countries deploying the IMS architecture rely solely on real-time billing infrastructure. Indeed, the technical infrastructure for creating a real-time charging system based on the IMS architecture is not as complicated and expensive as the technical infrastructure needed to create an offline charging system in which users are charged retroactively for the period of time using the service and infrastructure.

However, problems arise when a communication link implementing the Ro interface used to connect CTF and OCS is unreliable. For example, a transaction request may arrive at the CTF node when the OCS is unavailable due to a link failure between the CTF and the OCS. In the event of an error processing the credit control request message, OCS sends a pair of attribute values (AVP) “credit control request processing failure”, as defined in RFC 4006, to CTF. AVP indicates CONTINUE the requested session, TERMINATE the requested session or REPEAT and TERMINATE (RETRY and TERMINATE). In the standard mode that CTF executes, if OCS does not send any response at all, then TERMINATE is executed. The operator needs to configure CTF so that he can decide whether to satisfy the request, assuming the default behavior to CONTINUE, or reset it without access to the credit status of the subscriber initiating the transaction.

In a conservative approach, CTF can by default reject a session request if OCS is not available. This policy enables the operator to avoid any loss of revenue if the credit balance of the subscriber is actually not high enough to satisfy the transaction. On the other hand, if the credit balance of a subscriber is high enough to conduct a transaction, the subscriber may not be satisfied with the quality of the service, since the transaction did not occur regardless of the credit balance of the subscriber.

With a less conservative approach, CTF may allow the session to continue regardless of the credit balance of the subscriber in case OCS is unavailable. Such a policy leads to high availability of the service, but can lead to serious loss of revenue for the operator if the credit balance of the subscriber is not high enough for transactions.

In accordance with the existing and currently proposed IMS architectures, there is no easy way to configure the CTF node and / or the OCS node so as to resolve this unsatisfactory behavior in the IMS model for real-time billing.

SUMMARY OF THE INVENTION

In accordance with a first aspect of the present invention, there is provided a communication method between two nodes providing real-time charging functionality in an IP multimedia subsystem (IMS) network. The first node is configured to function as a billing initiation functional unit (CTF), and the second node is configured to function as a real-time billing service unit (OCS). The method comprises the step of receiving at the CTF node a Session Establishment Protocol (SIP) request relating to a SIP session from a network node. In addition, the method comprises providing notification to the CTF node. The notification indicates that the OCS node is unavailable. If the notification includes an indication that CCR requests related to the SIP session should be buffered, the method further comprises the step of storing the credit control request (CCR) information on the CTF node. The stored CCR information corresponds to said SIP session and is to be sent to OCS. The CTF node stores it in the memory buffer. The CTF node processes requests related to said SIP session, assuming that corresponding CCR requests have been provided. In addition, the CTF node transmits said buffered CCR information to said OCS after receiving a notification that the OCS node is available. The method further comprises processing said pre-buffered CCR information on an OCS node.

In accordance with a second aspect of the present invention, there is provided a method for processing a Session Protocol (SIP) request in an IP Multimedia Subsystem (IMS) node configured to function as a billing initiation function block (CTF). The method comprises the step of receiving at the CTF node a Session Establishment Protocol (SIP) request relating to a SIP session from a network node. In addition, the method comprises providing notification to the CTF node. A notification indicates that the OCS node is unavailable. If the notification includes an indication that the CCR requests related to the SIP session should be buffered, then the method further comprises the step of storing the credit control request (CCR) information on the CTF node. The stored CCR information corresponds to said SIP session and is to be sent to OCS. The CTF node stores it in the memory buffer. The CTF node processes requests related to said SIP session, assuming that corresponding CCR requests have been provided. In addition, the CTF node transmits said buffered CCR information to said OCS after receiving notification that the OCS is available.

In accordance with a third aspect of the present invention, there is provided a method for processing a credit control request message (CCR) in a network node of an IP multimedia subsystem (IMS) configured to function as a real-time billing service unit (OCS). The method comprises the step of receiving pre-buffered CCR information from a CTF node. The method further comprises processing said pre-buffered CCR information. Preferably, the OCS node may further send a notification to the Tariff Initiation Function Block (CTF), indicating that the OCS node is unavailable.

The unavailability notification can preferably be transmitted from the OCS node to the CTF node.

More preferably, the unavailability notification can be transmitted via a CCA response message, and it can indicate that CCR requests related to the SIP session should be buffered.

Preferably, the CCA response message may indicate CONTINUE BUFFERING (CONTINUE_BUFFER).

The buffered CCR information may preferably be transmitted in at least one CCR request, including an indication that the information has been buffered.

According to a fourth aspect of the present invention, there is provided an apparatus comprising a first node configured to function as a billing initiation function block (CTF) in an IP multimedia subsystem (IMS) network. The device comprises a first receiving module for receiving SIP requests, a second receiving module for receiving CCA response messages, a first transmitting module for sending SIP messages, a second transmitting module for sending CCR requests; a memory configured to buffer CCR information; and processing module. The processing module is configured to generate CCR information corresponding to the received SIP request and related to the SIP session. Subject to the provision of a notification indicating that the OCS service is not available, and that the CCR requests related to the SIP session should be buffered, the processing module is configured as follows. It is configured to store said CCR information in a buffer. The processing module, among other things, is configured to process SIP requests related to said SIP session, assuming that said CCR requests are provided, and read said CCR information from said buffer before transmitting said CCR information to at least at least one CCR request to said OCS node when it is available.

Preferably, the processing module may further be configured to include in said at least one CCR request containing buffered information that is transmitted to said OCS node, indicating that the information contained therein has been buffered.

In accordance with a fifth aspect of the present invention, there is provided an apparatus comprising a second node configured to function as a real-time billing service unit (OCS) in an IP multimedia subsystem (IMS) network. The device comprises a receiving module for receiving CCR requests, a transmitting module for sending CCA response messages, a memory, and a processing module. The processing module is configured to process CCR requests related to the SIP session, the CCR request being received from the CTF node and indicating that the included CCR information has been buffered by said CTF node.

Preferably, the processing module may further be configured to transmit an unavailability notification in response to a CCR request received from the CTF.

More preferably, the processing module may further be configured to transmit a notification of unavailability in response to a CCR request received from the CTF by means of a response message in response to a credit control request (CCA) that contains an indication that CCR requests related to said SIP session must be buffered.

The CCA response message may preferably contain a CONTINUE_BUFFER CONTINUE.

Embodiments of the present invention can reduce the problems encountered in real-time billing in an IMS-based system when the communication link between the CTF and the OCS is unreliable. Using the present invention, operators are able to maintain the availability of services without loss of revenue. Operators can use the Ro interface for both prepaid and post-paid subscribers, since their costs can be calculated retroactively.

BRIEF DESCRIPTION OF THE DRAWINGS

Next, aspects of the present invention will be described by way of example only with reference to the accompanying drawings.

FIG. 1 depicts an alarm related to a method in accordance with an embodiment of the present invention.

FIG. 2 depicts an alarm related to a method in accordance with an embodiment of the present invention.

FIG. 3 is a flowchart illustrating the steps of a method in accordance with an embodiment of the present invention.

FIG. 4 is a flowchart illustrating the steps of a method in accordance with an embodiment of the present invention.

FIG. 5 is a flowchart illustrating the steps of a method in accordance with an embodiment of the present invention.

FIG. 6 schematically illustrates an embodiment of a device implementing a CTF node.

FIG. 7 schematically illustrates an embodiment of a device implementing an OCS node.

DETAILED DESCRIPTION OF THE INVENTION

As described above, in the IMS architecture, there is a need to use available infrastructure related to real-time billing more efficiently. Currently, if the connection between the CTF and OCS nodes is not available via the Ro interface, then there is no way to establish a SIP session for the subscriber, even if the subscriber has a credit balance that would allow such a session to be established. In accordance with the present invention, this problem is solved, for example, by supplementing the pair of attribute values (AVP) “failure of credit control request processing” with a new value. The new value indicates that the CTF should continue to establish the requested session and buffer any credit control requests (CCR) for the requested session for subsequent processing on the OCS. In the following description, the new value will be designated as an indication to CONTINUE BUFFERING (CONTINUE_BUFFER).

In order to implement the invention in accordance with the present invention, CTF is provided with the ability to buffer CCR requests upon receipt of a message CONTINUE BUFFERING (CONTINUE_BUFFER). Moreover, CTF is provided with the ability to empty said buffer from CCR information later when OCS becomes available again. CTF clears the buffer by sending previously generated CCR requests to the OCS, including an indication that they are buffered, and therefore not real-time, requests. OCS is also provided with the ability to handle CCR requests that are not real-time requests and that include pre-buffered CCR information.

The sequence of processing events CONTINUE BUFFERING (CONTINUE_BUFFER) AVP is shown in FIG. one.

The subscriber equipment UE or the application server AS requests the establishment of a new SIP session with the called party. The corresponding SIP INVITE request is received by the CTF, possibly using the CSCF, which is not shown in FIG. 1. The CTF generates a first CCR, designated as CCR-1, which contains the user identifier of the requesting party, as well as service information related to the requested service. CCR-1 is transmitted via the Ro interface to OCS, which contains the subscriber's credit balance.

If OCS is unavailable for providing services, for example, because it is overloaded, it responds with CTF using a new pair of CONTINUE_BUFFER CONTINUE_BUFFER attribute values. Among other things, the operator can configure CTF to use the CONTINUE_BUFFER CONTINUE_BUFFER value as the default value whenever the OCS does not respond. After a notification indicating CONTINUE BUFFERING CONTINUE_BUFFER the AVP is available on CTF, it stores the previously sent CCR in memory, which is configured to store CCR information related to the requested session. This memory is called the CCR buffer.

Assuming that the OCS has provided the appropriate CCR, the CTF sends a SIP INVITE message to the called party, which is well known in the art. If the session is successfully established, a SIP 200 OK confirmation (successfully) is received from the calling party to the CTF, and sent by CTF to the calling subscriber equipment (UE) or AS. Once a session has been established, the CTF may, for example, generate a second CCR message to be transmitted to the OCS. CCR-2 contains information regarding the established session. As soon as CTF finds out that OCS is unavailable, it stores CCR-2 in the CCR buffer.

Similarly, as soon as a SIP session is terminated by a SIP BYE request, the CTF generates a corresponding termination request (CCR-3) and stores it in the CCR buffer.

The sequence of events for flushing the CCR buffer on the CTF and processing the buffered CCR requests in the OCS is shown in FIG. 2.

The CCR buffer on CTF is ideally configured as a FIFO buffer (“first come, first leave”), so that a sequence of generated CCR requests belonging to the same session is supported. First, the CTF sends the initial CCR-1 request to the OCS. Preferably, if all the transmitted CCR requests include an indication that the transmitted information has been buffered, and therefore are not real-time requests. OCS processes the received CCR requests and checks the subscriber's credit balance. Regardless of the result of the balance check, the CCA response message indicating approval of the request is transmitted to CTF.

The operator can preferably implement the OCS retroactive credit policy of the subscriber in accordance with the received buffered CCR requests that reflect previous subscriber services and infrastructure utilization. Such a policy makes it possible for an operator to recover at least some of its revenues when the Ro interface is down, while at the same time ensuring the availability of the services offered. Other policies may be applied to account for subscriber needs.

The CTF does not take any action with the accepted CCAs, as the session has already been provided before. The remaining buffered CCR information is processed in a similar manner.

In a preferred embodiment of the present invention, the CONTINUE_BUFFER instruction is transmitted using the AVP message “Credit Processing Processing Failed” (code AVP 427) as defined in RFC 4006. The AVP is returned to the CTF in the CCA sent from the CCS and is enumerated data taking the following possible values:

- STOP (TERMINATE) 0;

- CONTINUE 1;

- REPEAT AND STOP (RETRY_AND_TERMINATE) 2;

- Continue Buffering (CONTINUE_BUFFER) 3.

In an alternative embodiment of the present invention, the transmission of the CONTINUE_BUFFER indication is implemented using the experimental code AVP (Experimental-Code-AVP) defined in RFC 3588. Similarly, the AVP value of the 'non-real-time CCR request' can be added to transmit an indication of that CCR requests transmitted from CTF to OCS have been pre-buffered and present non-real-time CCR information.

FIG. 3 illustrates the main steps of the method in accordance with the present invention in the form of a flowchart corresponding to the sequence diagram in FIG. 1 and 2. The method begins at step 10. At step 11, the CTF node receives a SIP request related to the SIP session. At step 12, a notification that the OCS service node is unavailable arrives at the CTF node. At step 13, the CTF checks whether the notification indicates that the CCR requests related to the SIP session are to be buffered, and that the corresponding SIP requests should be processed assuming that the corresponding CCR requests have been submitted. If such an indication is present, the CTF stores the CCR information related to the SIP session in the memory buffer in step 14. In step 15, the CTF node processes the SIP requests that relate to the SIP session, assuming that appropriate CCR requests. As soon as the OCS service node becomes available again, in step 16, the CTF node transmits buffered CCR information to the OCS. Finally, in step 17, the OCS node processes the pre-buffered CCR information that was received from the CTF.

FIG. 4 illustrates the main steps of a method implemented in one embodiment using a CTF node similar to the CTF node shown in FIG. 1 and 2. The method begins at step 20. At step 21, the CTF node receives a SIP request related to the SIP session. At step 22, a notification that the OCS service node is unavailable arrives at the CTF node. At step 23, the CTF checks whether the notification contains an indication that the CCR requests related to the SIP session are to be buffered, and that the corresponding SIP requests should be processed under the assumption that the corresponding CCR requests have been submitted. If such an indication is present, the CTF stores the CCR information related to the SIP session in the memory buffer in step 24. In step 25, the CTF node processes the SIP requests that relate to the SIP session, assuming that the corresponding CCR requests. As soon as the OCS service node becomes available again, the CTF node transmits buffered CCR information to the OCS in step 26.

FIG. 5 illustrates the main steps of a method implemented in one embodiment with an OCS node similar to the OCS node shown in FIG. 1 and 2. The method starts at step 30. At step 31, the OCS node receives a CCR request containing CCR information that was previously buffered on CTF. In step 32, the OCS node processes the pre-buffered CCR information that has been received from the CTF.

FIG. 6 schematically illustrates an embodiment of an IMS node 100 in accordance with the present invention. The node is configured to function as a functional unit for initiating billing (CTF). This provides the functionality of the CTF node in FIG. 1 and 2. The node 100 comprises at least a first receiving module 110 for receiving SIP packets from the S-CSCF, UE or AS subscriber equipment, and a first transmitting module 111 for sending SIP packets. The node 100 further comprises at least a second receiving module 120 for receiving CCA response messages via DIAMETER protocol from the OCS node, and a second transmitting module 121 for sending DIAMETER CCR requests to the OCS node. The node 100 further comprises a processing module 130 and a memory 140, the processing module 130 being configured to generate CCR information corresponding to the received SIP request and related to the SIP session. The processing module is further configured to check whether a notification on the node 100 that the OCS node is unavailable is available and indicating that CCR requests related to the SIP session that should have been transmitted to said OCS should instead buffered to the buffer region 150 of said memory. The processing module 130 is further configured to save the generated CCR request 122 in the memory buffer 150, provided that the alert is received. Processing module 130 processes incoming SIP requests related to the SIP session, assuming that corresponding CCR requests are provided. In addition, the processing module 130 is configured to read buffered CCR request information 122 from the buffer memory 150 and transmit it in at least one CCR request to the OCS node as soon as it becomes available. Preferably, the processing module indicates in the outgoing CCR request that the information contained in the CCR request has been buffered.

FIG. 7 schematically illustrates an embodiment of an IMS node 200 in accordance with the present invention. The node 200 is configured to function as a real-time billing service unit (OCS). This provides the functionality of the OCS node in FIG. 1 and 2. Node 200 comprises at least a receiving module 220 for receiving CCR requests via DIAMETER protocol from a CTF node and a second transmitting module 221 for sending CCA responses via DIAMETER protocol to a CTF node. The node 200 further comprises a processing module 230 and a memory 240, the processing module being configured to process CCR information that is received in a CCR request containing non-real-time CCR information that has been pre-buffered. Advantageously, the processing module is configured to generate a CCA response message that informs the CTF node that the OCS node is unavailable and that the CTF node should buffer CCR requests.

Memory modules 140, 240 store instructions for processing by respective processing modules 130, 230. Each node 100, 200 can be considered as a computer, configured to act as described by processing the corresponding stored commands.

One skilled in the art will appreciate that various modifications may be made to the above described embodiments without departing from the scope of the present invention.

Claims (13)

1. A communication method between two nodes providing real-time charging functionality in an IP multimedia subsystem (IMS) network, the first node (100) being configured to function as a charging initiation function block (CTF), and the second node ( 200) is configured to function as a service charging unit in real time (OCS), the method comprising the steps of:
- on the CTF node, a Session Establishment Protocol (SIP) request relating to the SIP session is received from the network node;
- a notification is provided on the CTF node indicating that the OCS service unit is not available;
- on the CTF node, if said notification contains an indication that CCR requests related to said SIP session should be buffered, then
- store in the memory buffer information request for credit control (CCR), which corresponds to the aforementioned SIP session and which is to be sent to OCS,
- process requests related to said SIP session, assuming that appropriate CCR requests have been provided;
- transmit said buffered CCR information to said OCS after receiving a notification that OCS is becoming available;
- at the OCS node, the aforementioned pre-buffered CCR information is processed. 2. The method of claim 1, wherein said unavailability notification is transmitted from OCS to CTF. 3. The method of claim 1 or 2, wherein said buffered CCR information is transmitted in at least one CCR request, including indicating that the information has been buffered. 4. A method for processing a request using a Session Establishment Protocol (SIP) on a node (100) of an IP multimedia subsystem (IMS) configured to function as a billing initiation functional unit (CTF), the method comprising the steps of:
- receive a SIP request from a network node;
- provide a notification indicating that the real-time billing service unit (OCS) is not available;
if said notification contains an indication that the CCR requests related to said SIP session should be buffered, then
- store credit control request information (CCR) in the memory buffer, which corresponds to the SIP session and which is to be sent to OCS;
- process SIP requests related to said SIP session, assuming that said CCR requests have been provided;
- transmit said buffered CCR information to said OCS after receiving a notification that the service unit is available. 5. The method of claim 4, wherein said unavailability notification is transmitted from the OSR to the CTF. 6. The method of claim 4 or 5, wherein said buffered CCR information is transmitted in at least one CCR request, including indicating that the information has been buffered. 7. A method for processing a credit control request (CCR) on a network node (200) of an IP multimedia subsystem (IMS) configured to function as a real-time billing service unit (OCS), the method comprising the steps of:
- send a notification by means of a response message with a response to the credit control request (CCA) to the charging initiation function block (CTF), indicating that the OCS service block is not available; moreover, the notification contains an indication that CCR requests related to said SIP session should be buffered;
- receive pre-buffered CCR information from CTF;
- process said pre-buffered CCR information. 8. The method of claim 7, wherein said CCA response message instructs CONTINUE BUFFERING (CONTINUE_BUFFER). 9. The method of claim 7 or 8, wherein said buffered CCR information is transmitted in at least one CCR request, including indicating that the information has been buffered. 10. The device containing the first node (100), configured to function as a functional unit initiating billing (CTF), in the network of the IP multimedia subsystem (IMS), and the device contains:
a first receiving module (110) for receiving SIP requests;
a second receiving module (120) for receiving CCA response messages;
a first transmitting module (111) for sending SIP messages;
a second transmitting module (121) for sending CCR requests;
a memory (150) configured to buffer information (122) CCR; and
processing module (130), configured to, in the event that a notification is issued indicating that the OCS service unit is unavailable and that the CCR requests related to said SIP session should be buffered,
- generating CCR information corresponding to the received SIP request and related to the SIP session;
- storing said CCR information in said buffer (150);
- processing SIP requests related to said SIP session, assuming that said CCR requests are provided;
- reading said CCR information from said buffer and transmitting said CCR information in at least one CCR request to said OCS service unit when it becomes available.  11. The device according to p. 10, in which the processing module is further configured to include in said at least one CCR request containing buffered information that is transmitted to said OCS service unit, indicating that the information contained therein has been buffered . 12. A device containing a second node (200), configured to function as a service billing unit in real time (OCS), in the network of the IP multimedia subsystem (IMS), the device comprising:
a receiving module (220) for receiving CCR requests;
a transmitting module (221) for sending CCA response messages;
memory (240) and
processing module (230) configured to
- transmitting in response to a CCR request received from the CTF, by means of a credit control response (CCA) response message, an unavailability notification in response to a CCR request received from the CTF, the notification indicating that the CCR request relating to said SIP session must be buffered; and
processing the CCR request (222) related to the SIP session, the CCR request being received from the CTF node and indicating that the CCR information contained therein was buffered by said CTF node. 13. The device according to p. 12, in which the said CCA response message instructs to Continue buffering (CONTINUE_BUFFER).

Images