CN104159290B - Method for registering multi-contact device - Google Patents

Abstract

Techniques are described herein that allow an IMS-enabled network to terminate communication requests directed to a user device in an explicit manner. Even for the case where there are multiple registrations of the IMS in relation to the same physical user equipment, a method embodiment of the technique comprises registering multiple user agents for the same user device, wherein contact information comprising a device ID identifying the user device is provided from each user agent; processing a communication request directed to the user device, the processing comprising identifying a plurality of identical device IDs of registered contacts, and handling the communication request according to a predetermined processing scheme related to detection of identical device IDs.

Description

Method for registering multi-contact device

Technical Field

The present invention relates generally to the field of communication networks comprising an IMS domain. More particularly, the present invention relates to a technique for registering a multi-contact user device in an IMS domain of a mobile network.

Background

Mobile networks are currently evolving from pure circuit switched networks to IP-based networks and can therefore be seamlessly integrated into existing IP-based infrastructures, such as the internet, world wide web, and other IP-based communication networks.

In modern third generation mobile networks, the IP Multimedia Subsystem (IMS) domain has been specified by the third generation partnership project (3GPP) as a flexible service delivery platform architecture for providing IP multimedia services, in addition to the Circuit Switched (CS) domain and the Packet Switched (PS) domain. One of the main components of the IMS domain is the Call State Control Function (CSCF) which performs session setup and termination control of the IMS session. While the proxy CSCF (P-CSCF) terminates the session path at the IMS domain boundary, the main control function is located within the serving CSCF (S-CSCF).

For session control and signaling functions, such as session initiation, session modification and session termination for voice over IP (VoIP) or multimedia conferencing, IMS uses the Session Initiation Protocol (SIP). SIP provides services similar to telephony protocols such as ISUP (ISDN user part), but in the IP context. One important logical entity within the SIP framework that terminates a SIP session towards a user is the user agent (user agent). The user agent initiates a session request and is typically its destination.

After the user agent is registered in the IMS domain, the user agent contacts on behalf of a particular user. The user may of course register more than one contact, each contact generally corresponding to a particular user device via which the user will be reachable. The mechanism for selecting one contact from a plurality of registered contacts makes use of the contact attributes, since there is a user capability and a q-value (priority value) provided by the user agent during registration. When the contact with the highest priority can be identified, the session request is forwarded by the S-CSCF to the corresponding P-CSCF. In case there are two equally ranked contacts, the incoming session is branched (fork), i.e. forwarded to both contacts, which typically results in a parallel ringing at both user devices.

Within the framework described so far, a particular problem arises because of the fact that there is often no one-to-one correspondence now between the user equipment (assuming a piece of hardware in the vicinity of the user) and the user agent (typically a software module representing the call or session termination function). When using modern multi-contact user devices, it is now possible for a user to register more than one user agent in the network, so that two or more contacts can be associated with the same user device. This is different, for example, for GSM networks, where the termination point of a call is a subscriber device that is fixedly built-in with the required functionality.

In order to achieve efficient and flexible service provision, it will generally be better to place service control in the IMS domain in the future, as well as for services that have been provided by other domains so far. For example, call and service control for typical voice services has heretofore been performed by the CS domain. However, contemplated network configurations plan to place call and service control for these services in the IMS domain. The user may then have an IMS client and a CS client on his device, for example. Now, both clients require one user agent, i.e. there are two user agents associated to the same user device. The S-CSCF thus branches incoming communication requests to two or more user agents associated with the same user device, with the same or overlapping user capabilities, possibly resulting in an ambiguous operating state of the user device. Furthermore, under conditions such as "user unavailable" or "user busy", the redirection mechanism may result in the redirection of the incoming call to another user agent, but in fact to the same device.

Similar problems may occur with two or more IMS clients on the same user device, or in case the user has configured his IMS client to be reachable from the CS domain, or in still other configurations.

It is therefore an object of the present invention to propose an efficient and reliable mechanism to prevent the above-mentioned undesirable effects.

Disclosure of Invention

According to a first aspect of the present invention, a method of registering two or more user agents associated with a single multi-contact user device in an IMS enabled network is proposed. The method comprises providing, by the two user agents, each a device Identifier (ID) to the IMS domain, the device ID identifying the user device.

The term "user agent" as used herein is not limited to the corresponding SIP entity, but generally denotes a component capable of managing tasks for a user, more precisely for a user device or user client, and may thus be configured in a user-specific manner. In this context, a user agent may, for example, act as an initiator of a communication request or as a destination for a communication request.

A multi-contact user device is a device that provides two or more contact options for setting up voice, data or multimedia communications or for being reachable for such communications. In this context, a multi-contact user device will typically be associated with more than one user agent.

The user agent of the multi-contact device may be configured to provide a set of contact attributes to the S-CSCF of the IMS domain. The device ID may constitute a new parameter or may be represented by an existing parameter in the set of contact attributes. IMS enabled networks preferably include mobile networks having an IMS domain, but may also include other scenarios, such as access networks using WLAN, WIFI or WiMAX connected to the IMS domain.

One or more user agents may be located in the user device. For example, a user device may take over a SIP client for multimedia telephony or other applications. Alternatively or additionally, one or more user agents may be located in the network (e.g., resident at, near, or associated with the P-CSCF). In this case, the user agent may act as a CS client in the user device. Thus, any communication will rely solely on the CS protocol (e.g. 3GPP TS 24.008) between the CS client on the user equipment and the network node where the user agent resides, and will likely be SIP based between the user agent and other entities within the IMS domain, in particular the P-CSCF and the S-CSCF.

The invention is of course not limited to SIP usage. Other protocols for control and signaling purposes already exist in the IP-based service domain, or may exist in the future; one example is the existing h.323 protocol specified by ITU-T.

In yet another variant, the user agent additionally provides a predetermined user capability value suitable for delivering CS services via said IMS domain. Typical values may be "multimedia telephony, audio only". This value may be predetermined in case the user agent is specifically designed for the present purpose, or may be controlled by the user or the operator.

The device ID may be obtained from a global permanent identifier associated with the user device. In one embodiment of the invention, IMEI (international mobile equipment identity) may be used. However, it is also possible to use another global permanent identifier for this purpose, such as an IMSI (international mobile subscriber identity).

According to yet another aspect of the present invention, a method of controlling a communication request for a multi-contact user device in an IMS enabled network is proposed. The method comprises the steps of registering a plurality of user agents for the same user device, wherein contact information including a device ID identifying the user device is provided from each user agent; and further comprising the step of processing the communication request directed to the user device. The processing step comprises the following substeps: identifying a plurality of identical device IDs of registered contacts suitable for terminating communications to the user device; and handling the communication request according to a predetermined processing scheme related to the detection of the same device ID.

The device ID provided to the S-CSCF or similar network node during user agent registration allows early detection of undesirable conditions, such as branching or redirecting an incoming session to the substantially same user device. Typically, a detection routine for the same device ID may be applied when more than one contact possibility is generated in a previous step (e.g. evaluating user capabilities or q-value).

The predetermined handling scheme may comprise an instruction to forward the communication request to only one of the contacts comprising the same device ID. This may be a randomly selected contact from two or more detected contacts having the same device ID, or more detailed decision logic (e.g. including other parameters of the contact profile) may be applied. Additionally, or alternatively, the predetermined processing scheme may include instructions not to redirect "busy" communications between contacts that include the same device ID.

In yet another variation, the predetermined processing scheme may be configurable by at least one of a network operator and a user. For example, an operator may be configured in a standard manner to detect characteristics with the same device ID, and a user may make changes according to his personal needs (e.g., by adjusting the q value to a particular value).

The present invention may be implemented as hardware, software, or a combination thereof. In terms of software, a computer program product is proposed, which comprises program code portions for performing the above-mentioned method steps when the computer program product is run on one or more computing devices. The computer program product may be stored on a computer readable recording medium.

According to yet another aspect of the invention, a user agent is proposed which acts as a termination point for communications from an IMS enabled network. The user agent is adapted to provide a device ID during registration with the IMS domain, the device ID identifying a user device associated with the user agent. The user agent will typically be a piece of software that can be written in the Java programming language, which is popular for implementing features in mobile phones, among other things. Of course, the user agent may also be hardware based or may be implemented as firmware.

The user agent is further adapted to provide a predetermined user capability during registration with the IMS domain, suitable for delivering CS services via the ISM domain. This is particularly useful for user agents specifically designed for ease of understanding the present invention, user agents in networks, and agents implemented on user devices, to simplify device configuration.

According to a further aspect of the present invention, a user device is proposed, incorporating a user agent as described above. For example, a mobile device (telephone, notebook, but also commonly referred to as a personal computer or other computing device that is not "mobile" in itself) may implement an IMS client that includes a user agent to allow setting up sessions with the IMS domain of a mobile or non-mobile network. The session may be transmitted via WCDMA, GPRS, WLAN, or WiMax. In any case, the user agent will provide its contact attributes including the device ID to the IMS domain.

According to yet another aspect of the present invention, a user equipment is proposed, having a user agent as described above associated therewith, the user agent being located in a network. Here, the user device and the user agent are physically separated, and the communication protocol between the agent and the device depends on the details of the situation. The user device may, for example, incorporate a CS client, and the user agent then acts as the CS client. In this case, the communication between the user agent and the user may rely on a CS-based protocol, e.g. as specified in TS 24.008.

The user device may have other user agents incorporated therewith and/or associated therewith. Examples include devices with a SIP-enabled IMS client and a SIP-enabled CS client, or devices with two IMS clients, e.g. one operating over WCDMA and the other over WLAN.

According to a further aspect of the present invention, there is proposed a network gateway for exchanging data between a user device incorporating a CS client adapted to exchange data with the CS domain of the or any network and the IMS domain of the network, the gateway incorporating a user agent as described above. This gateway allows a user to access services in the IMS domain from ordinary CS phones through CS access. In addition to taking over the (typically SIP) user agent serving the CS client in the CS phone, the gateway may perform one or more of the following functions: interworking between TS 24.008/ISUP and SIP for calls/sessions; at least a subset of functions of the P-CSCF; gsmSCF (GSM service control function) for static call routing; and Media Gateway (MGW) control. The gateway may be provided as a stand-alone device or it may be co-located with the MSC.

According to yet another aspect of the present invention, a serving node in an IMS enabled network for controlling communication requests of multi-contact user devices is proposed. The service node is adapted to register a plurality of user agents for the same user device, wherein contact information comprising a device ID identifying the user device is provided from each user agent. The service node is further adapted to process a communication request directed to the user device. The treatment comprises the following steps: a plurality of identical device IDs of registered contacts suitable for terminating communication with a user device are identified. The process further comprises the steps of: the communication request is handled according to a predetermined processing scheme related to detection of the same device ID. The serving node may be, for example, an S-CSCF in the IMS domain of the mobile network.

Description of the drawings in the following, the invention will be described with reference to exemplary embodiments shown in the drawings, in which:

fig. 1 is a flow chart illustrating a first method embodiment of the present invention.

Fig. 2 is a flow chart illustrating a second method embodiment of the present invention.

Fig. 3 is a schematic diagram illustrating a first system embodiment of the present invention.

Fig. 4 is a schematic diagram illustrating a second system embodiment of the present invention.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular network topologies, communication protocols, etc., in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. For example, the skilled person will appreciate that the present invention may be practiced with different signaling and control protocols than the SIP standard described below which illustrates the invention. Furthermore, the present invention may be practiced with various access networks other than the PS and CS access described below.

Those skilled in the art will also appreciate that the functions described herein below may be implemented using individual hardware circuits, using software functioning in conjunction with a programmed microprocessor or general purpose computer, using an Application Specific Integrated Circuit (ASIC), and/or using one or more Digital Signal Processors (DSPs). It will also be appreciated that while the present invention is described as a method, it may also be implemented in a computer processor and a memory coupled to the processor, wherein the memory is encoded with one or more programs that perform the methods described herein.

Referring to fig. 1, a flow chart 100 illustrates the steps of a first method embodiment of the present invention for registering two or more user agents associated with a single multi-contact user device in an IMS enabled network.

In a first step 102, each user agent sends a device ID to the IMS domain. The device ID uniquely identifies the user device associated with the user agent. In a second step 104, a corresponding device ID is received in the IMS domain. In this way, each user agent provides a device ID to the IS domain during registration.

Referring to fig. 2, a flow chart 200 illustrates the steps of a second method embodiment of the present invention for controlling communication requests for multiple contact user devices in an IMS enabled network.

In a first step 202, a user agent is registered in a network. In further steps 204, 206, further user agents are registered in the network. Step 204 is not explicitly shown and may include registering zero or more user agents in addition to the agents registered in steps 202 and 206. During registration, each user agent provides contact information including a device ID that identifies the user device.

In further steps 208, 210, a communication request directed to the user device is processed. Step 208 includes identifying (or detecting) a plurality of identical device IDs of registered contacts suitable for terminating a communication request to a user device. Step 210 comprises handling the communication request according to a predetermined processing scheme related to the detection of two or more identical device IDs.

Fig. 3 schematically shows network entities comprising user equipment, which entities are involved in a further embodiment of the invention. User equipment (or user equipment UE) is used by user bob. The apparatus comprises a SIP client 312 for PS access to the IMS domain 311 of the mobile network. Com "is associated with a private ID obtained from ISIM (IP multimedia service identity module) and a public ID" bob @ op.com ", in the form of an e-mail address, but also a number (like a telephone number) or any other identifier. Further, the user agent has a plurality of contact attributes associated therewith, as will be discussed below. The contact profile is called "contact A of user Bob".

The user device 310 also includes a CS client 314 for communicating over a CS domain (not shown) of the mobile network. In addition, the CS client 314 may connect to an entity 320 in the mobile network, which will be described later. The connection between client 314 and entity 320 is CS based, i.e. the CS protocol will be used to set up, control and terminate the connection. The protocol may include ISUP for connection forking (connecting leg) between the radio access network and the entity 320.

The entity 320 is a Media Access Gateway Control Function (MAGCF). Generally speaking, MAGCF320 performs interworking mainly for registration and call related functions. One of its tasks is to take over the SIP user agents 322, 324 for different user devices. The user agent 322 communicates with the CS client 314 within the device 310 of the user bob and, on the other hand, with other entities of the IMS domain 311 as SIP clients. The user agent 322 has associated with it a value obtained by the IMSI as the private ID. The same applies to the temporary public ID. Alternatively, the private ID and the temporary public ID cannot be obtained from the IMSI, but are generated in other ways. In this example, the permanent public ID is the same as the public ID associated with the user agent 312 within the user device 310. The user agent 322 has a number of contact attributes associated therewith, as will be discussed below. Its contact profile is called "user Bob's contact B" for further discussion.

In addition to hosting user agent 322 of user bob, MAGCF320 may host a large number of other user agents for other users; the example summarizes two other user agents 324. The MAGCF further comprises a P-CSCF 326 as a Proxy (Proxy) for the user agents 322, 324.

The IMS domain 311 also includes a separate proxy CSCF 330 that operates as a proxy for the SIP client 312 on the user device 310. A further CSCF 340 operates as a serving entity (S-CSCF) for the user bob (and possibly other users). The S-CSCF 340 thus controls the session in relation to the corresponding user agent 312, 322. The IMS domain 311 may comprise part of the home network of the user.

The SIP clients 312, 322 are to be registered in the IMS domain 311 (more precisely with the S-CSCF 340) in order to be able to initiate session requests or in order that other user initiated session requests are reachable. To this end, during the registration process, the corresponding proxy shall provide its contact profiles (or simply contact) a and B, respectively, to the S-CSCF 340, which stores the contact in a user (user) or subscriber (subscriber) related manner, as indicated by an object 342 named "bob". Of course, many other users may register their user agents at the S-CSCF 340, which is indicated as a further object 344.

Object 342 "bob" is shown in greater detail in fig. 3 as an enlarged structure, schematically illustrating some of the contents of this object 342. The object holds the private user ID of user bob and the public permanent and temporary user IDs. Further, the object contains contacts A and B (reference numerals 352, 354) that have been provided by the user agents 312, 322 during registration.

Contact a 352 specifies parameters for a session terminated on one end by the SIP client 312 on the user device 310. The contact address may be a WLAN or GPRS address. The user capability is 'multimedia telephone with video and audio'. The priority or q value indicated for the user agent is "SIP client WLAN". CSCF 330 is designated as a proxy.

Contact B354 specifies the address of the network-based MAGCF 320. Because communication data is to be transferred between the user agent 322 and the CS client 314 on the user device via the CS access mechanism, multimedia telephony, audio only, is specified as a capability. The q value is selected accordingly as "CS client". The CSCF 326 located in the MAGCF320 is designated as a proxy.

Of particular interest in understanding the present embodiment are the device IDs 356, 358 which form part of each contact profile A, B and which have likewise been transferred from the user agents 312, 322 to the S-CSCF 340 during registration.

It is assumed here that the user equipment 310 has an IMEI (international mobile equipment identity) associated with it. This is for example the case for mobile phones. The IMEI consists of information representing the manufacturer and a serial number and as such constitutes an ID that uniquely identifies the user device in all mobile phones that have been previously manufactured (and will be manufactured in the future). However, for ease of understanding the invention, a device identification that is unique within a session control context related to the IMS domain of a particular (mobile) network will also apply.

Thus, in principle an identifier that is unique in the network will also suffice. However, it may be more efficient to rely on the existing IMEI instead of introducing a further identification scheme. For devices that do not have an IMEI, other mechanisms will be used. For example, to facilitate understanding of the present embodiment, it is also possible to use the IMSI (international mobile subscriber identity) of the subscriber. Since here the unique identity is assigned to the user, more precisely to its (U) SIM card, and not directly to the user device, the same user may use several IMSIs within or associated with the same device. However, these cases do not at present seem to have a large association and can be addressed by appropriately configuring the user agent and/or responsible IMS components.

Of course, other global permanent identifiers may be used for purposes of the present invention. In this regard, "global" means "unique" at least with respect to the network to which the user device is attached, and the network typically includes all interrelated entities under the control of the network operator to which the user or subscriber is subscribed, although other configurations are possible.

In the example shown in fig. 3, the IMEI of the user device 310 is used by the user agent 312 located within the device to obtain the device ID. The user agent 322 located in the IMS domain 311 also obtains the device ID from this IMEI. In general, it would be advantageous if two or all user agents used the same scheme to obtain the device ID. For example, the simplest possibility is to use the IMEI directly. In case this is not desirable, e.g. due to storage or processing capacity limitations or for security reasons, a scheme may be used, e.g. similar to the generation of hash values of data sets to be signed or encrypted in the field of IT security.

The user agent 322 in the MAGCF320 may have received the IMEI via CS-based communication with the CS client on the user device 310, or the device ID may have been configured directly by the operator when implementing the user agent 322 in the MAGCF 320.

In this embodiment, both user agents 312, 322 use the same scheme to obtain the device ID. Thus, the device IDs 356, 358 are the same for each other. The use of such device IDs by the session control function according to a further embodiment of the present invention will be described below with reference to fig. 4.

Fig. 4 schematically illustrates a mobile network 400, wherein an IMS domain (possibly identical to IMS domain 311 in fig. 3) is represented by a CSCF 402 acting as a serving CSCF, a MAGCF 404 co-located with the serving MSC, and an IMS application server and MRFC (multimedia resource function control) 406. The mobile network 400 also includes user data transfer capabilities represented by an MRFP (multimedia resource function processor) 412, a media gateway 414, and a Radio Access Network (RAN) (UTRAN/GERAN) for UMTS/GPRS 408. User data is forwarded along the path designated by reference numeral 420 and signaling/control data is forwarded along paths 416, 418.

It is assumed here that the user device 410 is the same as shown in fig. 3, belonging to user bob. The corresponding user agent 411 is located in the MAGCF 404 associated with the user device 410. The user agent 411 communicates with the CS client (not shown) of the user device 410 and other subsystems of the device 410 via a CS-based communication protocol, as shown at (TS) 24.008. For the IMS domain of network 400, SIP is used as a control protocol to register user agent 411, e.g., at S-CSCF 402.

Typically, calls directed to user bob (and more precisely to a user agent associated with user device 410 of user bob) will be routed to S-CSCF 402. The S-CSCF 402 will involve the IMS AS 406 which in turn will trigger the execution of the terminating service. The S-CSCF 402 knows the address of the MAGCF 404 serving the user equipment 410. The MAGCF 404 also comprises a P-CSCF (not shown) which is the P-CSCF specified in the contact profile of the user agent 411.

In case of multiple (active) registrations, a decision needs to be made in the S-CSCF 402 to which P-CSCF the incoming session request is to be forwarded. It is assumed here that the incoming call requires the user capability audio' (voice, speech), which is satisfied by video, audio multimedia telephony and multimedia telephony, audio only. Contact a and contact B of figure 3 with these capabilities are therefore both eligible to forward the request to its address corresponding P-CSCF.

The S-CSCF 402 will typically examine the q-value of each contact a and B and select the contact with the highest q-value. In case the contacts have the same q-value, branching (parallel ringing) can be applied according to the prior art. If two contacts are associated with the same user device as in the present embodiment, the branch will not function properly.

According to this embodiment, the S-CSCF 402 will therefore additionally check the device IDs contained in the two qualifying (squaring) contacts. From fig. 3, it is apparent that the device IDs are the same. In this case, further logic is needed in the S-CSCF 402, for example to forward requests to only one of these contacts and/or to avoid redirecting sessions from one contact to another when the user is busy (since both contacts represent the same device).

The contact attribute "device ID" may be a necessary or optional feature, for example to allow parallel use of enabled SIP clients and (conventional) SIP clients not enabled for providing device IDs in the network. In an optional case, the S-CSCF is to handle the case where the registered user agent does not provide a device ID. One possibility is then to assume that a contact without a device ID qualifies for no further consideration, or that it qualifies for further consideration.

In either case, in the final step, the S-CSCF has a list of two or more contacts, all subject to the condition of forwarding the communication (session) request and containing the same device ID (or, in the case of absence of a device ID, assuming the same device ID). In the embodiment described here, this is the case for contacts a and B. The S-CSCF 402 therefore decides which of these contacts to use for forwarding the request.

This determination will be based on predetermined rules or processing schemes. In many cases, it may be useful for the processing scheme to include instructions to forward a communication or session request to only one of the contacts that includes the same device ID. The decision to which eligible contact the request is to be forwarded may rely on further examination of the contact attributes, other user data available at or associated with the S-CSCF, or may simply be done by selecting the "first item" in the contact list. In any of these cases, the advantage of the invention is achieved that undesired branching of the session to the same physical device is avoided.

In the example described here, the S-CSCF 402 may therefore decide to use the properties of contact a, which results in forwarding the request to the user agent 411 only via the P-CSCF within the MAGCF 404. Forwarding via another P-CSCF to the user agent located on the mobile phone 410 (not shown in fig. 4) is suppressed. The audio data will then be forwarded via the transmission nodes 412, 414.

After the session or call has been routed to the P-CSCF comprised in MAGCF 404 will terminate the call towards user device 410 without invoking any service.

The predetermined processing scheme used in S-CSCF 402 to determine eligible contacts for the same device may additionally or alternatively include instructions to not redirect communications between contacts that include the same device ID during busy hours. This avoids ringing, for example, a notebook, smart phone, or other mobile device when the user is temporarily busy, for example, receiving another phone call.

The predetermined processing scheme described above may be configured by the operator. For example, it may be applied in terms of user categories, e.g. "normal" users or "premium" users (in case the network operator usually decides to provide this feature as an optional feature). The processing scheme may also be implemented to be configurable by the user as is the case with its user agent q value that conveys the session to the preferred SIP contact. However, as unnecessary data transmission over the radio interface is generally to be avoided due to physically limited bandwidth, operator-based configurations appear to be preferred. Thus, operators may prefer to configure radio access in a way that avoids unnecessary forking, without giving the user the possibility to influence this aspect. However, some additional or alternative sub-characteristics relating to service characteristics may also be configurable to the user, e.g. a "busy" time redirect.

Although the above description assumes contact for two registrations of the same device, the invention is of course equally applicable to other situations where there is more than one registration for the same device. For example, there may be three user agents associated with a mobile phone, one agent serving CS clients on the phone, one agent for PS access via WLAN, and one agent for cellular PS access. Some or all of these user agents may have a registration for multimedia telephony in the IMS domain. In other cases, PS access may be used to obtain access to the CS domain of the mobile network. In this case, the user device may arrive from the CS domain via both CS and PS accesses simultaneously. The skilled person realizes that many other scenarios are possible.

The invention disclosed in the above allows an IMS enabled network to terminate a communication request directed to a user device in an unambiguous manner, even for the case where there are multiple registrations in the IMS domain relating to the same physical user device.

While the present invention has been described with respect to its preferred embodiments, it is to be understood that this disclosure is only illustrative. Accordingly, the invention is not to be restricted except in light of the attached claims.

Claims (6)

1. A method of controlling a communication request to a multi-contact user device (310, 410) in an IMS-enabled network, the user device (310, 410) being uniquely identifiable by a device ID (310, 410) relating to an IMEI of the user device,

the method comprises the following steps:

registering a plurality of user agents (312, 322, 411) for the user device (310, 410) in the IMS-enabled network S-CSCF, wherein contact information including the device ID (356, 358) is provided from each user agent;

processing a communication request directed towards the user device, the processing comprising:

identifying a plurality of identical device IDs of registered contacts suitable for terminating the communication request towards the user device, and

the communication request is handled according to a predetermined processing scheme related to detection of the same device ID.

2. The method of claim 1, wherein the first and second light sources are selected from the group consisting of a red light source, a green light source, and a blue light source,

wherein the predetermined handling scheme comprises instructions to forward the communication request to only one of the contacts comprising the same device ID.

3. The method according to claim 1 or 2,

wherein the predetermined processing scheme includes instructions not to redirect "busy" communications between contacts that include the same device ID.

4. The method according to claim 1 or 2,

wherein the predetermined processing scheme is configurable by at least one of an operator and the user.

5. A computer-readable storage medium storing a computer program which, when run on one or more computing devices, causes the one or more computing devices to perform the method of any of claims 1-4.

6. A service node (340, 404) in an IMS enabled network for controlling a communication request to a multi-contact user device (310, 410), the user device (310, 410) being uniquely identifiable by a device ID relating to an IMEI of the user device,

wherein the serving node is adapted to register a plurality of user agents (312, 322, 411) for the user device in an S-CSCF of the IMS-enabled network, wherein contact information comprising the device ID (356, 358) is provided from each user agent; and the serving node is further adapted to process a communication request directed towards the user device, the processing comprising:

identifying a plurality of identical device IDs of registered contacts suitable for terminating the communication request towards the user device, and

the communication request is handled according to a predetermined processing scheme related to detection of the same device ID.

Images