Patent Application
20100095010
1. Field of the Invention
The present invention relates to a method and apparatus for use in a communications network, for example a Universal Mobile Telecommunications System having an IP Multimedia Subsystem.
2. Description of the Related Art
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packets switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004-03).
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criterion for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select a S-CSCF if a S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. [It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.] When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded. In the case that an IFC indicates that a SIP message received at the S-CSCF should be forwarded to a particular SIP AS, that AS is added into the message path. Once the SIP message is returned by the AS to the S-CSCF, it is forwarded on towards its final destination, or forwarded to another AS if this is indicated in the IFCs.
3GPP TS 32.260 defines the IMS charging architecture and principles and thereby defines when to send charging information and when not to send charging information.
SIP re-INVITE and SIP UPDATE messages are used e.g. as bearers of the SDP information when a user wants to modify an established SIP session by adding, removing or changing the media. A user or the terminal can reject a received SDP offer, which results in a non-2xx final response (such as a 3xx, 4xx, 5xx or 6xx response).
The non-2xx final response leaves the session unchanged and therefore there is no need to change the charging of the session.
According to table 5.2.1.1 in 3GPP TS 32.260, the only offline charging information sent as a result of SIP re-INVITE and SIP UPDATE is at reception of SIP 200 OK acknowledging the requests. Offline charging is a post-paid type of charging scheme whereby charging is performed after a service has been consumed by the user; for example the user might receive a monthly bill showing chargeable items from the previous month.
According to table 5.3.1 in 3GPP TS 32.260, the only online charging information sent as a result of SIP re-INVITE and SIP UPDATE is at reception of SIP 200 OK acknowledging the requests, or at the actual reception of the requests. Online charging is a pre-paid type of charging scheme, where network entities would consult with the charging system before allowing a user access to the requested service.
The applicant has appreciated the following problem with the situation as it is currently specified.
3GPP TS 32.260 defines implicitly that no charging information shall be sent at unsuccessful responses to these requests, which denies the possibility of having a full traceability of e.g. unsuccessful SDP negotiations.
It is desirable to address the above-identified issue.
According to a first aspect of the present invention there is provided a method for use in a telecommunications network that makes use of the Session Initiation Protocol, SIP, the method comprising sending charging information to a charging function of the network in response to the receipt of an unsuccessful SIP response to a SIP request.
The SIP request may relate to a request to modify an established SIP session.
The SIP request may relate to a request to modify the media of an established SIP session, for example by adding, removing or changing the media.
The SIP request may be a SIP UPDATE request.
The SIP request may be a SIP re-INVITE request.
The unsuccessful SIP response may be a non-2xx SIP response.
The unsuccessful SIP response may be a non-2xx SIP final response.
The unsuccessful SIP response may be a negative response to the SIP request.
The unsuccessful response may be a response indicating an unsuccessful procedure.
The unsuccessful response may be one at least partly rejecting the SIP request.
The method may comprise receiving the unsuccessful response.
The method may comprise sending the charging information outside an ongoing charging session.
The method may comprise correlating the charging information to the ongoing charging session with reference to a session identifier relating to the ongoing charging session.
The network may be a Universal Mobile Telecommunications System comprising an IP Multimedia Subsystem, IMS.
The charging function may comprise an IMS Charging Data Function, CDF.
The charging function may comprise an IMS Online Charging System, OCS.
The method may be performed by a Charging Triggering Function of the network.
According to a second aspect of the present invention there is provided an apparatus for use in a telecommunications network that makes use of the Session Initiation Protocol, SIP, the apparatus comprising means for sending charging information to a charging function of the network in response to the receipt of an unsuccessful SIP response to a SIP request.
According to a third aspect of the present invention there is provided a program for controlling an apparatus to perform a method according to the first aspect of the present invention or which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the second aspect of the present invention. The program may be carried on a carrier medium. The carrier medium may be a storage medium. The carrier medium may be a transmission medium.
According to a fourth aspect of the present invention there is provided an apparatus programmed by a program according to the third aspect of the present invention.
According to a fifth aspect of the present invention there is provided a storage medium containing a program according to the third aspect of the present invention.
The following abbreviations are used in the above Figures and elsewhere herein:
According to a basic concept underlying an embodiment of the present invention, the Charging Triggering Function (CTF) is able to send charging information to the Charging Function (CDF or OCS) for non-2xx final responses to SIP re-INVITE and
SIP UPDATE received for established SIP sessions. The CTF is able, at reception of an unsuccessful response to SIP re-INVITE and SIP UPDATE, to send charging information for the event to the CDF or OCS. An example of such a response is a 4xx, 5xx or 6xx response; a 3xx response may be considered less applicable in this situation, as such a response should already have appeared at session establishment.
A method embodying the present invention is illustrated in
The charging information can be sent either within the established charging session, or outside. The unsuccessful response is a session related event but it is not intended to affect the charging of the session. It is preferable, therefore, to send it outside the charging session but connect it to the ongoing charging session by re-using session identifiers to enable correlation. There would be a new ICID (IMS Charging Identifier) for the ACR/CCR but the call-id is the same. The call-id can then be used to relate to the ongoing charging session. A new AVP could be created to pass on the ICID of the ongoing charging session, which could make it easier to correlate the data, if required.
A more detailed embodiment of the present invention is illustrated in the signalling flow diagram of
In step T1, User A sends a SIP Re-INVITE or UPDATE request to the Charging Triggering Function 10, which in step T2 is received by the Charging Triggering Function 10 and forwarded to User B.
Following receipt of the SIP Re-INVITE or UPDATE request in step T3 at User B, the request is rejected by sending an unsuccesful SIP response (e.g. a 3xx, 4xx, 5xx, 6xx response) in step T4 from User B.
The unsuccessful response is received and detected by the Charging Triggering Function 10 in step S1 and forwarded to User A. The unsuccessful response is received at User A in step T5.
In an online charging scenario, the charging function 20 depicted in
As an alternative to steps S2, T6, T7 and T8 described immediately above, in an offline charging scenario, where the charging function 20 would instead be a Charging Data Function, the following series of steps could occur. In response to receipt of the unsuccessful response in step S1, an ACR (SDP) message is sent in step S2 from the Charging Triggering Function 10 and received at the Charging Data Function 20 in step T6. The Charging Data Function 20 responds in step T7 with an ACA response, which is received in step T8 by the Charging Triggering Function 10.
Although an embodiment of the present invention is described above mainly in relation to SIP re-INVITE and SIP UPDATE messages, the invention is applicable to other types of SIP message as well. Although 3GPP mentions the Diameter protocol (e.g. ACR/ACA) in relation to the sending of charging data in the offline charging scenario, it will readily be apparent to the skilled person that the RADIUS protocol or another protocol such as FTP could be used to send a file with charging data in the offline charging scenario. It will also be readily apparent to the skilled person that an embodiment of the present invention need not be implemented in a CTF, but can be implemented in any suitable network node or function.
It will be appreciated that operation of one or more of the above-described components can be controlled by a program operating on the device or apparatus. Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website. The appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.
It will also be appreciated by the person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the present invention as defined by the appended claims. In particular, it will be appreciated that, although described in relation to a Universal Mobile Telecommunications System having an IP Multimedia Subsystem, the present invention is also applicable to other types of network.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP07/51848 | 2/27/2007 | WO | 00 | 8/27/2009 |
