IMS Public User Identities (IMPUs)

There might be a few interesting things to say about IMS user identities.

As you certainly know, there can be two sorts of IMS Public User Identities (also known as IMPUs): tel URIs (e.g. tel:+1-234-456789) and sip URIs (e.g. sip:user@operator).

(Note that a SIP URI with an E.164 number in the user part and a parameter "user=phone" is the equivalent to a tel URI and will be treated as such by the IMS core network)

Tel URIs: Smooth Migration From Legacy Telephony

In IMS, tel URIs may be used to address an IMS user or a user in the legacy circuit-switched network.

When the tel URI corresponds to an IMS user, the core network entity called S-CSCF (Serving Call Session Control Function) will be able to resolve it into a SIP URI, thanks to a DNS extension called ENUM,. It will then proceed with the routing of the SIP request within the IMS.

When the tel URI corresponds to a circuit-switched user, the S-CSCF's query to ENUM will fail to resolve the tel URI into a SIP URI. The S-CSCF will then route the call to the circuit-switched network through an appropriate gateway.

Consequently, using a tel URI an IMS user can set up a call with another IMS user or with a legacy telephony user.

Tel URIs also permit IMS users to be called from the circuit-switched network. The CS network routes the call to a voice gateway, which sets up a voice session in the IMS using the original B-party number to form a tel URI. The IMS core then resolves the tel URI into a SIP URI of the IMS user.

In order to support interoperability with the circuit-switched network, IMS users will need to keep legacy phone numbers for years, even if they use SIP URIs in parallel.

SIP URIs: The Future of User Addressing

SIP URIs should eventually dominate and replace phone numbers as the way to address other users in some years from now.

This steady migration from telephone numbers to alphanumerical SIP addresses will be a fundamental element for different types of convergence:

- Convergence between fixed and mobile communication, as mobile and fixed -segregated phone numbers will be replaced by access-agnostic SIP URIs.

- Convergence between telecom and Internet communication, as both can use SIP and SIP URIs.

- Convergence between SIP-based communication (e.g. multimedia sessions, voice, instant messaging) and email through the possibility to use the same address between SIP and the email protocol (e.g. sip:John@service_provider vs. smtp:John@service_provider).

IMPUs Identify Users, Not a Specific Line or Device!

There is a major difference between IMS and pre-IMS addresses. While pre-IMS phone numbers are usually associated to a unique line or device, IMS IMPUs relate to end-users.

In a pre-IMS world, mapping a legacy phone number to multiple devices is an added-value feature requiring a specific implementation in existing fixed and mobile networks.

In contrast, the possibility to concurrently assign an IMPU to multiple devices is a basic IMS feature, supported by the IMS core network (i.e. S-CSCF), without the need for a specific support in the application layer. The dynamic allocation of an IMPU to one or several devices is performed through the IMS registration procedure.

In addition, the possibility for IMS to support multiple access technologies (e.g. cable, xDSL, cellular wireless, non-cellular wireless) makes that an IMPU can concurrently be shared between multiple fixed and mobile devices (e.g. fixed phone, PC, set top box, mp3 player, mobile phone). This is fixed mobile convergence at the user and network level.

Multiple IMPUs for One User

IMS specifications permit a user to have several IMPUs. It is up to the operator to decide how many IMPUs a user will be allowed to have.

Different IMPUs may serve as aliases. These IMPUs are totally inter-changeable, as they are associated to the same set of services and are transparently associated to the same devices. The user may use them to differentiate between different groups of contacts (e.g. friends vs. strangers). A user will typically have a tel URI as alias to a SIP URI (see above).

Different IMPUs may also permit the user to endorse several persona (e.g. member of an association, owner of a private business). In this case, the IMPUs may be associated to different service profiles, and possibly to different devices (but they can also be associated to the same).

One IMPU for All Services, Across All Devices

A feature that may seem to conflict with the previous, and might actually be more essential, is the possibility to associate a single IMPU to virtually all the services of a user.

IMS and SIP can unify all real time 2-party and multi-party person to person communication (e.g. voice, video, instant messaging, deferred messaging), blend communication, content and data together, and support access to user data and information (e.g. presence, user profile, various event packages permitting to access and monitor user-related data and events).

All these communication/content/data services can be accessed through a single user IMPU, which is independent from the devices and access technologies being used. Moreover, if this IMPU corresponds to the user's email address, you can then finally have a unique address on your visit or business cards, and this address may provides access to more services than all the old ones put together.

More Enablers for Services

The possibility to access a plethora of services through a single IMPU can also be extremely beneficial to services themselves.

Consider the following example (which may not be that interesting from a service perspective, but this is not the point).

John sends an electronic birthday card to Mary through IMS deferred messaging (i.e. the message will be delivered to Mary as soon as she is able to receive it). A service associated to John intercepts the SIP service request, extracts Mary's IMPU from it and generates a presence request on behalf of John and addressed to Mary's IMPU. Mary's presence server answers with a set of information related to Mary, according to John's authorization to access it. This information may be very rich about Mary, the means and addresses to communicate with her, her devices, the applications she uses, and various availability and preference information about them. John's service may use this information to suggest additional or alternative ways to deliver the electronic birthday card (e.g. email). It may also suggest to store elements of this information in various repositories, such as John's address book.

This example shows that even if a an IMS subscriber still makes use multiple identities and addresses (for instance addresses related to Internet services), one of them may be used as the key to dynamically discover all others.

It also shows that a service which had never heard about a user can discover a whole lot of information about this user and use it for the delivery of sophisticated services. In the example, I used presence, which by itself can be a very rich set of information, but this could be extended to much more than this.

Christophe