VERSATILE RINGTONE HANDLING IN IMS

Technical Field

The present invention relates to methods and apparatus for providing a versatile ringtone service to users of a communications network. More particularly, the invention relates to provision of ringtone services in an Internet Protocol Multimedia Subsystem (IMS).

Background

It is known for users of communication devices such as mobile phones or the like to select a ringtone from a range of available ringtones, for example popular tunes or jingles. However, for the purposes of this discussion a ringtone will be taken to refer to all media types that can be used to inform the user that there is an incoming call (or session invitation). Examples of types of ringtone include audio, video, text and vibration frequency. The selected ringtone is usually stored in a memory in the communication device, which is set by the user so that the selected ringtone plays when the device is called. Ringtones are made available by a ringtone service provider, and can be downloaded by a user to her/his device.

Hitherto the handling of ringtones has not changed or advanced much. In a conventional ringtone service, the user decides when she desires to change her ringtone and contacts the ringtone service provider (by whatever means have been made available to her). Typically, the ringtone service provider will provide a list of available ringtones, from which the user will select a new ringtone. The new ringtone, in the form of a ringtone data file, will then be down- loaded to the user's UA. The user is then charged for the new ringtone. Currently deployed ringtone services are quite static and inflexible, in that they do not allow subscribers much variety in the service they receive, or service providers the ability to adapt the service to meet changing commercial demands. Moreover, they do not permit the complete utilization of the ringtones'

market potential; users bear the full costs of such services, and this acts as a disincentive to more frequent changing of ringtones.

The advent of the IP Multimedia Subsystem (IMS) provides for much greater versatility in the types of services that can be offered to users. IMS is the technology defined by the Third Generation Partnership Project (3 GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.003, TS 23.008, TS 23.218,

TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Release 5,

Release 6 and Release 7). IMS provides key features to enrich the end-user person-to- person communication experience through the integration and interaction of services.

IMS allows new rich person-to-person (client-to-client) as well as person-to-content

(client-to-server) communications over an IP -based network.

Figure 1 is a simplified schematic illustration of the network entities in the IMS. A user A operates a user terminal device or User Agent (UA) 12, which accesses the IMS 10.

The UA 12 may be, for example, a mobile telephone or a computer device, and communicates with other users such as User B, who operates another UA 14, or may take part in web-based sessions via the Internet 18. Communications take place in the form of sessions, which are controlled by Call/Session Control Functions (CSCFs) 16. Information relating to each user and their UAs is stored on a Home Subscriber Server

20 (operated by the Home Network to which the user subscribes). The IMS allows for services to be provided to users by means of Application Servers (ASl, AS2, etc.).

Services that can be provided to users in this way might involve voice, text, video, or multimedia services. The Services provided are charged to users by means of a charging function, for example a call charging function (CCF) 22 or event charging function (ECF) 24.

The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (UAs) or between UAs and application servers (ASs). 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.

Within an IMS network, the Call/Session Control Functions (CSCFs) 16 operate as SIP entities within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy

CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct

S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P- CSCF.

IMS service functionality is implemented using the application servers (ASs). For any given UA, one or more ASs may be associated with that terminal. ASs communicate with an S-CSCF via the IMS Service Control (ISC) interface and are linked into a SIP messaging route as required (e.g. as a result of the triggering of Initial Filter Criteria (IFCs) downloaded into the S-CSCF for a given UE).

The S-CSCF is responsible for handling the registration processes, making routing decisions and maintaining session states as well as sending accounting-related information to a charging system, which may include, for example, a call charging function (CCF) 22 or an event charging function (ECF) 24. Information concerning users' registration and the services to which users subscribe is stored on the Home Subscriber Server (HSS) 26, and this information is provided to the CSCFs when required.

A user registers in 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 using subscription information stored in the HSS 20, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria 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 an S- CSCF, if an S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the HSS, and selects an appropriate S-CSCF based on the received capabilities. It is noted that S-CSCF allocation is also carried 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.

Summary

It is an object of the present invention to provide a simple and efficient mechanism for delivering ringtones to user terminals. This is achieved by employing SIP messages, including INVITE and NOTIFY, to transport ringtone information to user terminals.

According to a first aspect of the present invention there is provided a method of updating a user terminal with a ringtone, the user terminal accessing an IP Multimedia Subsystem (IMS) network. The method comprises intercepting, within the IMS, an INVITE message destined for the user terminal, inserting information relating to an updated ringtone into the INVITE message, and forwarding the INVITE message with the updated ringtone information to the user terminal.

Use of the INVITE for this purpose minimises the need for user interaction, and is also efficient in terms of bandwidth useage.

Preferably, the ringtone information includes information that enables the ringtone to be

played upon receipt of the message. Alternatively, the ringtone information comprises information for enabling the user terminal to download the ringtone or streaming information that enables the user terminal to receive the ringtone from a streaming agent whereby the user terminal plays the ringtone as it is received from the streaming agent.

In order to allow appropriate charges to be levied or credited, the method may comprise the step of notifying a charging function of the updating of the ringtone. To this end, the charging function is notified of the updating after the user terminal has responded to the message.

According to a second aspect of the present invention there is provided method of setting up a ringtone service for a user of a communications network, the method comprising: subscribing the user to the ringtone service wherein INVITE messages inviting said user to participate in a session are to have ringtone information inserted; providing an indication to the user's home network that the user has signed up to the ringtone service and that INVITE messages to said user are to be intercepted so that the ringtone information can be inserted.

According to a third aspect of the present invention there is provided a system for updating a user terminal with a ringtone, the user terminal accessing an IP Multimedia Subsystem (IMS) network, the system comprising: a ringtone application server; and a serving call/session control function (S-CSCF) adapted to receive an INVITE message destined for the user terminal and to forward said INVITE message to said ringtone application server; wherein said ringtone application server is adapted to receive said INVITE message from said control function server, to insert information relating to a ringtone into said INVITE message and to forward said INVITE message with inserted ringtone information to said user terminal.

According to a fourth aspect of the present invention there is provided an IMS application server, comprising: means for receiving an INVITE message destined for a user terminal; means for inserting information relating to a ringtone into said INVITE message; and means for forwarding said INVITE message to said subscriber.

According to a fifth aspect of the present invention there is provided user terminal for accessing an IP Multimedia Subsystem (IMS) network, the user terminal comprising: means for receiving an INVITE message that includes a ringtone or additional information for instructing the user terminal to obtain a ringtone; means for reading and processing said additional information so as to obtain said ringtone; and means for playing said ringtone.

According to a sixth aspect of the present invention there is provided method of updating a user terminal with a ringtone, the user terminal accessing an IP Multimedia Subsystem network, the method comprising: inserting information relating to an updated ringtone into the NOTIFY message; and sending the NOTIFY message with the updated ringtone information from the IP Multimedia Subsystem network to the user terminal.

Brief Description of the Drawings

Figure 1 is a simplified schematic illustration of the configuration of network entities operating in IMS.

Figure 2 illustrates the signalling flows in the provision of ringtone services in accordance with embodiments of the invention.

Detailed Description

The invention concerns the delivery of ringtones to users of an IP Multimedia Subsystem

(IMS) network. The embodiments described below include two modes of operation: ad- mode, and tailor-mode. In the ad-mode the content of a ringtone includes an advertisement. The ringtone service provider can choose an advertisement to be provided to the user, to be played as a ringtone on the user terminal (or "UA"). The ringtone service provider can update the advertisement as frequently as desired.

Associated with the ad-mode is a business model where the advertisement provider gives benefits to a user who has subscribed to the ad-mode ringtone service, an example of which will be described in more detail below.

The tailor-mode is one where a user can subscribe to a service, which dynamically changes his/her ringtone according to a pre-agreed policy. For example, one possible policy is one where a subscriber receives ringtones that play modified versions of Top- 10 music hits. In the tailor-mode it is envisaged that the user pays the ringtone service provider for the service, an example of this will be described in more detail below.

Three ringtone delivery methods are described, each of which may be used for either the ad-mode or tailor-mode service. These are: bundled-delivery, referred-delivery, and streaming-delivery.

Figure 2 illustrates the signalling flow that would occur in an exemplary system. The network entities are identified by the same reference numerals as described above with reference to Figure 1. The signalling flow starts at step 101 with a user, User A, switching on her UA 12 and registering in the IMS network 10 (see above for a summary of the process of registering in the IMS). For the purposes of the following discussion, the User A is a subscriber to ringtone service for providing up-dated ringtones to her UA 12 in accordance with the principles set out herein. That is to say that User A has previously been set up to be provided with the ringtone service. Typically this would have involved A'S UA 12 being provided with software that

enables it to process certain ringtone related information sent to it. The subscription method can vary, and it can be done, e.g. with an Interactive Voice Response (IVR) service, where A calls to "sip:subscribe@ringtone-provider-a.com". When A has subscribed to the ringtone service, this information is stored in the HSS 20 and is provided as part of User A's service profile.

At step 102 some other user, say user B, calls to A by sending a SIP INVITE A message. The S-CSCF 16 allocated to A's UA, has been provided with the service profile of User A, and this profile will include a ringtone related Initial Filter Criterion (IFC). This IFC is triggered at the S-CSCF upon receipt of the INVITE, causing the S- CSCF to forward the INVITE to the ringtone Application Server ASl (step 103).

At step 104, the ringtone Application Server ASl inserts information relating to a ringtone into the INVITE A message, and sends it back to the S-CSCF 16. At step 105, the S-CSCF forwards the INVITE A message to A's UA 12. The behaviour of A's UA 12 will then depend on the ringtone information inserted into the received INVITE A message, and which delivery method is being employed.

If the bundled-delivery method is being used the ringtone data file itself is carried inside the SIP INVITE A message. In that case, the signal flow skips step 106 and A's UA 12 just plays the ringtone. However, many access technologies impose restrictions on the message size, so this delivery method is suitable only for ringtones with a light footprint (small file size).

On the other hand, larger ringtones can be provided if the referred-delivery method is used. In this method a pointer to a ringtone file is carried inside the SIP INVITE A message. For example, the reference might be in a form "http://www.ringtone-provider- a.com/tones/283791.mp3". In this case, at step 106, A's UA 12 is instructed to download the ringtone. A's UA 12 fetches the ringtone e.g. by using File Transfer Protocol (FTP) or Message Session Relay Protocol (MSRP) [ID-MSRP] in step 106. Provided A's UA is accessing the IMS 10 through an access network that has sufficient

bandwidth, the downloading of the new ringtone can be completed very quickly, and A's UA can play the ringtone almost immediately. If A's UA 12 is accessing the IMS in a narrowband access network, then a previously received ringtone can be played, and the fetching of a new ringtone can be done later as a background process. Note that A's UA may be a mobile device that is roaming into a different network that has a different access bandwidth to A's Home Network 10.

In the streaming-delivery method, the incoming INVITE A message contains a reference to a streaming service, which should be used to provide the ringtone. For example, the reference to a streaming service might be in a form "sip:28379 l.tones@ringtone-provider-a.com". In this case, at step 106, A's UA is instructed to set up a streaming session e.g. with SIP and Session Description Protocol (SDP). The ringtone is streamed from the ringtone Application Server ASl to be played directly as it is received at the user's UA. This delivery method is especially well suited to Next Generation Network (NGN), because it has a wide broadband access network.

IfA accepts the session invitation, then A's UA 12 sends a 200 OK message at step 107 to the S-CSCF. At step 108, the 200 OK message is forwarded to the ringtone Application Server ASl, which then returns the 200 OK message to the S-CSCF 16 (step 109), which then forwards it on to B's UA 14 (step 110). When the ringtone Application Server ASl has received the 200 OK message it notifies the charging function, CCF 22 or ECF 24, so that the appropriate charging for the service can be applied (step 111), as will be described below.

Note that because in the IMS communications can be sent over the internet to any location in any participating network, the ringtone Application Server ASl could be located in any of the networks that operate in the IMS. Equally, the Application Server from which user A's UA 12 fetches the ringtone or receives the streamed ringtone need not be the ringtone Application Server ASl from which it received the INVITE A message with ringtone information inserted. In other words the ringtone information in the INVITE A message could direct User A's UA 12 to fetch/receive the ringtone from

a different Application Server. This means that the ringtone service would not need to be restricted to subscribers of a particular Home Network.

When A's UA 12 has received the INVITE A message, and has accepted the session, the ringtone Application Server ASl will instruct the CCF 22 or ECF 24 to initiate charging in accordance with the charging policy to which user A has subscribed. In the ad-mode, the charging policy may be one where user A's account receives credits each time an advertisement ringtone is played on user A's UA. However, these credits would only be applied after user A has accepted the session. This would prevent user A from gaining free credits just by asking her friends call to her UA, and by never accepting those calls. In the tailor-mode user A's account would be debited each time a new ringtone is sent.

Note that the embodiments described above involve the insertion of the ringtone/ringtone information into an INVITE message. The use of the INVITE message is a preferred embodiment because this is efficient with respect to bandwidth usage, and because it fits well with the service logic of IMS. However, it will be appreciated that the principles of the invention may be applied equally well using other messages sent to the user. For example, where the user's terminal supports a subscribe/notify framework (IETF RFC3265), then the ringtones/ringtone information may be provided by means of a NOTIFY message. In this scenario, an end user subscribes, with SUBSCRIBE message, to a ringtone event package and the NOTIFY messages contain ringtone information as described above. Using the subscribe/notify framework means that the time at which the ringtone is changed is not tied to an incoming call, but it can be chosen arbitrarily by the ringtone service provider. Similar accounting mechanisms and business models apply also to this ringtone service delivery method.

It will 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.