Fixed Mobile Convergence(s)

The term "fixed mobile convergence" is very ambiguous. In this post, I will try to clarify the concept by distinguishing between different types of convergence and by positioning IMS with regards to them.

Device convergence

This type of convergence essentially relies on the ability of a device to connect to a single or to separate networks using either fixed or mobile access (typically WiFi behind xDSL and GSM/UMTS).

UMA (Universal Mobile Access), also called Generic Access Network (GAN) in 3GPP, is a potential solution for this type of convergence, as it permits to add an IP access to the mobile core network while keeping the higher level signaling stacks, thus enabling standard handover between, e.g. WiFi and cellular access. UMA/GAN requires the support of a dedicated "base station" in the access network to add the new access to the mobile core.

The IMS Voice Call Continuity (VCC) specification supports a similar feature, but this time handover is performed through switching between an IMS core network and the mobile core network. An issue with VCC is that voice services are supported across two different core networks (IMS and the pre-IMS mobile core), which may cause trouble with regards to the execution of value added services that should be unified or at least coherent across the two networks. The 3GPP IMS Centralized Services (ICS) initiative could be a way to address this issue, by locating value added voice services for both IMS and the pre-IMS mobile core network in a single IMS Telephony Application Server (TAS)

Overall, device convergence suffers from the significant hurdle to rely on dual mode devices, with the need for associated market penetration. It may also face technical issues related for instance to the quality of user experience or battery consumption. Note that this is the only type of convergence which relies on the ability of a device to connect to the network through different access types.

Service convergence

Service convergence relies on the support of convergence through service implementation.

Typically, fixed and mobile devices each access their own network through their specific access. A service is then made convergent by an ad hoc implementation permitting the coherent delivery of the service across the different access technologies and devices. This generally implies federation between fixed and mobile identities, the usage of a converged service profile and a consolidation of fixed and mobile OSS/BSS functions in order to deliver a coherent provisioning and a converged bill.

The drawback with this approach is that services have to be made convergent one by one, either by totally service-specific implementations or by the integration with a usually proprietary convergence framework dealing for instance with identity federation and shared fix / mobile service profiles. This type of convergence may be costly to support, difficult to evolve, and may sometimes be limited due to technical issues.

Network convergence

Network convergence relies on the ability of a core network to support different types of devices using different access technologies.

A single IMS core network may for instance support a variety of access technologies among GSM, UMTS, LTE, Femtocells, WiFi, WiMax, xDSL, FTTH, circuit-switched fixed access and cable, and consequently the devices making use of them.

IMS based network convergence requires the ability of the device to connect with IMS, either through native or acquired internal support, through a home gateway or through a network gateway. On the other hand, it does not require the device to support various access technologies (like WiFi and GSM/UMTS).

Taken in isolation, network convergence is essentially a cost reduction feature as it permits to avoid deploying access-specific core networks, thus cutting in the CAPEX and OPEX of the operator. Fixed and mobile devices can still make use of different user identities associated to different service profiles, and providing access to discriminated services or service implementations.

However, network convergence can also be seen as a support facilitating the implementation of service convergence, as it implies the support of the same (IMS) protocols by the devices (or through gateways) as well as a unified access to application servers through the unique core network. IMS-based network convergence can therefore be used to support convergent services in a more cost effective and simplified manner.

Network convergence is currently a strong IMS driver for operators deploying new access technologies (e.g. WiMax, LTE) or targeting specific convergent services (e.g. enterprise FMC, converged messaging) across these new or legacy access technologies.

In addition, IMS-based network convergence can also be seen as a step towards the ultimate goal of user convergence.

User convergence

User convergence relies on the support of a unique converged subscription possibly making use of converged user identities (i.e. user identities shared between fixed and mobile devices). It builds and extends upon network convergence.

In this approach, the operator provisions a unique user profile in the HSS, which may include converged identities, separate fixed and mobile identities if needed, and access specific information like authentication methods and credentials (e.g. UMTS AKA for mobile and SIP digest for fixed).

In the most advanced scenario, the user can concurrently register the same user identity (e.g. sip:john.smith@operator.com) from multiple fixed and mobile devices. The service profile stored in the HSS and associated to the shared identity supports converged access to IMS application servers, which associate a converged user profile to this identity. In this approach, every service deployed on the IMS framework and associated to a converged identity is de facto converged because immediately accessible from various devices using vaious accesses.

SIP requests addressed to the converged identity (e.g. incoming calls, incoming instant messages) can be handled intelligently by the IMS core network (and possibly the application layer) with a panel of strategies ranging from alerting the user or delivering the request (e.g. an IM) on several devices to selecting the most appropriate one according to various criteria such as user preferences, device capabilities and more dynamic information such as presence.

Other interesting features include session mobility (currently worked on in the IETF and 3GPP) permitting to transfer an ongoing session from one device to another, as well as the possibility to deliver the different components of a multimedia session over different devices (CPM requirement), like delivering the video component of a voice/video session to the TV and the voice one to the mobile phone.

I had the opportunity to describe user oriented convergence in a previous post, but I will use this one to demystify prejudices that sometimes exist about it.

First, while IMS can eventually support user convergence, it will not mandate it for all users. An operator implementing a coherent IMS strategy will be able to offer convergent subscriptions while keeping the possibility to offer mobile and fixed specific subscriptions as well (using IMS network convergence in this case). Moreover, even for converged subscriptions, the operator will be able to keep separate fixed and mobile identities if the user wishes it or for access to specific services. This is only a matter of user profile provisioning in network databases.

Second, user convergence does not necessarily mean the impossibility to distinguish between fixed and mobile access for:
- Service discrimination: some services may remain fixed or mobile specific.
- Service implementation discrimination: variants may still exist between the implementations of a service depending on the access used to deliver it.
- Charging discrimination: differentiated fixed and mobile charging may apply as long as users are informed about it, possibly in an interactive manner before service delivery.

The key element permitting to support these differentiations is the fact that all SIP signalling originating from a device includes an identification of the access technology it uses (e.g. UMTS, xDSL). This information can be used for service routing in the network (i.e. definition of initial filter criteria) or within service logic prior to or while delivering the service. A device switching from one access to another during service delivery would inform the network about it, for instance by initiating session re-negotiation, thus permitting the network and services to dynamically adapt to the change.

User convergence will not happen overnight, as it implies, besides the addressing of pending technical issues, major changes related to organizations, processes, business models, OSS and BSS, as well as regulation. However, I cannot imagine that it will never happen, whether this is under the control of operators using IMS or through disruptive players using alternative solutions enabled by all-IP networks.

Conclusion

IMS can support all types of convergence: device convergence, service convergence, network convergence, and user convergence.

Personally, I consider that device convergence and service convergence are of a limited and tactical appeal, due to the limitations and costs they imply. Moreover, to support them, IMS is only a candidate framework among others, which alone may not justify an investment.

The real interest of IMS for fixed mobile convergence appears when network and user convergence are part of the roadmap for the operator. These targets justify the usage of IMS for device and service convergence, as an initial step towards a more ambitious strategy combining both network and user convergence. Network convergence in itself can be used as an intermediate step towards user convergence, which will be a true revolutionary aspect of IMS, together with its ability to support multimedia communication, to combine services and to merge the Internet and telecommunications domains.

Different Strategies for IMS

Most operators do not want to be reduced to the role of bitpipe provider, offering low cost connectivity to services supplied by other companies. They want to be service providers themselves, and try to figure out how IMS will help them achieving this objective.

This basic point aside, the strategies between operators might diverge, and their differences may essentially lie into the level of control they want IMS to support. This level of control can be illustrated by the following questions, which purposedly address extreme attitudes (it should be understood that intermediate opinions also exist).

Should IMS be fully open to other IP networks, and permit communication and service interoperability with devices and service providers located outside of the traditional telecommunications domain, more especially the Internet? Or should IMS, on the contrary, help operators establishing a new "walled garden", forcing or strongly encouraging the customer to use the services provided by telecommunications operator, and preventing or strongly discouraging them to use services provided in the Internet?

Should IMS foster service innovation, permitting telecommunications operators to differentiate between themselves and compete on value for money to improve their market share? Or should IMS, on the contrary, be used to maintain the old, slow and standardization driven telecommunications model, in which most operators provide the same mass market services and only differentiate at the margin?

Operators in a challenger position, or which are confident in their ability to cope with the new challenges they are facing with the rapid evolution of technologies and customers' habits, are keen on adopting an open IMS and a new approach to service creation. In addition to developing their own services, they are likely to seek other ways to maximize revenues, acting as a channel provider or intelligent pipe provider towards 3rd party service providers, by partnering with them and/or adding values to their services (see here an example of how IMS can be used by an operator to add value to 3rd party services).

Operators with a control freak approach are more in a defensive attitude, having to preserve a market position or facing internal uncertainties about the future world.

These diverging strategies do not only concern operators, as they will directly impact the supplier ecosystem the operators will rely on in the years to come.

Operators favoring service innovation, short development cycles, high service customization, or niche market services, will have to adopt technologies and practices that come from more dynamic business sectors, where state-of-the-art IT and methods are common place. To develop their services, they are likely to rely on open service platforms (e.g. J2EE), enterprise architecture practices, and to primarily view services as applications, developed in-house, purchased off the shelf, or contracted to IT-centric application providers.

On the other hand, operators opting for mass market standardized services, with little differentiation, are likely to maintain the existing ecosystem of traditional equipment and service box suppliers. The more a traditional telecommunications equipment supplier has difficulties to move from telco IT (e.g. proprietary platforms, poor skills at Java, SOA and other advanced IT architecture and programming paradigms, long and costly development cycles) to standard IT, the more this supplier will take as a threat the advent of an all-IP and open IMS era.

How IMS positioned itself a couple of years ago

This was a mixed bag.

Despite what some people think and claim, 3GPP always ensured that IMS was fully interoperable with non-IMS SIP networks. I already addressed this topic in a past post, from which I will only reuse a telling example: IMS session setup.

In order to permit IMS calls to replicate the experience an end-user has when establishing a call in the circuit-switched network, IMS opted for a more complex procedure than the basic IETF SIP one, permitting network resources to be reserved before the call is established. An IMS device is mandated to follow this procedure. While this procedure and the related SIP extensions can also be used in non-IMS networks (these are not 3GPP-specific extensions), it cannot be assumed that all SIP clients will ever support it. Not doing anything about this would have prevented an IMS device to set up sessions with most of non-IMS devices. However, 3GPP did something about this: in case the peer device does not support the complex session setup procedure, the IMS device (or a network based agent acting on its behalf) is mandated to revert to the basic IETF procedure.

The technical ingredients to support service innovation were also there: the intrinsic power of IP and SIP, the powerful IMS service architecture, the SIP servlets specification permitting the integration of SIP-related service logic into advanced and open J2EE platforms, the endorsement of SIP servlets by all the suppliers of J2EE platforms.

However, it did not work out that well, and this can be linked to multiple good and bad reasons: IMS was still a prospective technology (real deployments are starting now), focus was on short-term (hopefully) value generation services (e.g. VoIP, push to talk over cellular), IT-centric platforms were not mature yet, the capabilities of SIP and the IMS service architecture were not well known, no compelling IMS services were proposed, the legacy telecom culture was a handicap that was reflected in the old fashioned silo way OMA (the Open Mobile Alliance) was specifying IMS-based enablers...

I would not claim that all these factors have disappeared now, but some progress has been made in the recent time, as IMS is becoming real.

The last two years: hidden fight between various strategies

3GPP Communication Services are the textbook example of how suppliers and operators with conflicting strategies have used all the subtle (and less subtle) panoply of standardization tricks to push their agendas and counter-agendas in IMS standardization.

I already addressed the topic (here and there) at a time when the fight reached its heights, and I will soon dedicate a post to describe the current status and potential consequences of Communication Services standardization.

For now, suffice to say that:

- Would all the ideas pushed by Communication Services promoters have been accepted, IMS would certainly have become a walled garden preventing interoperability between IMS and non-IMS SIP devices, and huge barriers to innovation by IMS operators would have been erected.

- In the present state of standardization, these risks have been globally averted (thanks to the IETF and some companies active in 3GPP).

I personally view Multimedia Telephony as an initiative that goes in the same control direction. As I already wrote, Multimedia Telephony can be seen as an attempt at defining multimedia sessions as an incremental, person-to-person communication centric evolution of voice telephony. Moreover, at the moment, the content of Multimedia Telephony specifications is limited to the emulation of classical voice telephony services over an IMS network. From this you can derive that, from a target perspective, MMTel is a half full or half empty evolution in direction of the true multimedia experience SIP can provide, and that in any case there is not much hurry to move toward this target.

Another initiative I would strongly liken to MMTel is OMA PoC phase 2. While PoC phase 1 can be described as a 2-party or group walkie talkie service (essentially) for mobile phones, PoC phase 2 significantly enriches the user experience with other media, permitting for instance to transform a session from half duplex voice (original PoC) to full duplex voice, to use text messaging or send images, files or video streams in the session. This is still not full multimedia, but a controlled step in the direction, defined as an enrichment of a service silo looking for a future. As such a silo, PoC has a very interesting feature for companies which are not that thrilled with the idea of interworking with non-IMS devices: PoC is the only IMS service that can be described as fully IMS centric. It was totally specified by the IMS community and has no equivalent in the non-IMS SIP community.

On the other side of the fence, you can undoubtly place the ongoing OMA Converged IP Messaging (CPM) initiative. CPM intends to use the full capabilities of SIP sessions and IMS convergence features. It is multi-access, multi-party, multi-media in the most advanced meaning, and multi-device, supporting both person-to-person and person-to-service sessions. If every thing goes well, instead of a fully standardized service like telephony or PoC, CPM should end up being an architectural framework permitting operators to place or allow any media component one can think of in an IMS session, thus realizing (and possibly improving on) everything one can implement in the Internet using the SIP protocol.

Until recently, I tended to see 3GPP as the standardization body with the most coherent and liberal approach to IMS, and OMA as the organization which, through its heavy pre-IMS heritage and its inadequate organization, would keep on standardizing good old service silos (with overlapping features). However, it looks like this time is over, at least for OMA. This said, thinking about it, this OMA organizational problem (the fact that each group standardizing a service works in parallel to the others while the architecture group works on its own topics instead of ensuring the overall coherency of the OMA architecture like SA2 does in 3GPP) is more obvious than ever when you consider the current situation of OMA specifications: as an operator, you now have no less than three alternatives if you want to deploy an IMS messaging solution, OMA SIMPLE Messaging, OMA PoC phase 2 and OMA Converged IP Messaging, among which the last two can claim to support multimedia sessions as well. Finally, I may withdraw my positive comment about OMA as a whole.

Christophe

3GPP Multimedia Telephony & OMA CPM

In this post, I will address two standardization initiatives that try to define the future of communication services based on IMS, and more especially the support of Multimedia Communication.

As you will see, I have a soft spot for one of them (OMA Converged IP Messaging) and a strong bias against the other (3GPP Multimedia Telephony).

3GPP Multimedia Telephony

3GPP Multimedia Telephony (MMTel for short) has appeared in 3GPP release 7 and will evolve in the next releases. The initiative originates from ETSI TISPAN requirements for fixed networks.

The name always made me mad, but it is actually very telling about what MMTel is today.

The service is "multimedia" in the sense that it permits the combination and dynamic re-negotiation of different media components within an IMS session. Sample components include full duplex voice, real time video, text communication, file transfer (e.g. video clip, audio clip, pictures). Note that there is no explicit mention of applications, and the 3GPP requirements state that a "typical usage" is speech (voice) and speech combined with other media components.

On the other hand, this is a "telephony" service, which seems to anchor its definition to the well-known, decades-old, voice-centric, and circuit-switched implemented telephony service. Basically, you could infer that Multimedia Telephony is an incremental evolution of Voice Telephony with the addition of new media components.

This may lead to potential questions when specifying Multimedia Telephony:
- Is the service only related to person-to-person communication or can it apply to person-to-service interactions? I already showed an example of how a multimedia SIP session can be used in a person-to-service relationship, and you will see below that CPM supports it.
- Are current classical telephony supplementary services applicable in a new world where a session can be established with a service, where SIP URIs will eventually replace telephone numbers, where the protocol and the core network permit to reach the user on a multiplicity of devices, where enablers like group management and presence can change the users' behaviors to communication (e.g. is the user available for voice communication now? What are the alternatives?) as well as the way network-based call handling services can be implemented (using presence to take an informed decision), where users can negotiate the content of a session when establishing it, and where services can easily redirect users to web pages to allow them to decide how a call should be handled?

These questions are not purely theoretical when you consider the current standardization state of MMTel: it solely consists of the specification of how classical telephony services like Original Identification Presentation, Call Forwarding Unconditional or Communication Waiting can be implemented in IMS. The requirements specification clearly states that the behavior of each service, "as perceived by the user, should be consistent with the behavior perceived when using the equivalent services on PSTN/ISDN and CS Mobile networks." Isn't this crystal clear?

As such, at the moment MMTel looks like a vehicle to standardize voice-centric telephony services to be supported by a Telephony Application Server (TAS), which may eventually become a Multimedia Telephony Server when voice is not the only media component supported by a call.

The MMTel initiative can be associated to another 3GPP one called IMS Centralized Services (ICS) which aims at having an IMS-based TAS for both CS telephony and IMS telephony. The approach would eventually deprecate existing IN servers in legacy networks and see them replaced by a TAS. Put together, both initiatives draw the following potential roadmap:
1) A TAS for IMS voice telephony
2) A TAS for both CS and IMS based voice telephony
3) A TAS to support IMS-based Multimedia Telephony
Basically, a TAS at the center of the future telecommunications network.

I personally do not believe at all in this incremental approach to Multimedia Communication, as SIP and IMS will drastically change the way people communicate, leaving plain old telephony as a separate service whose usage will gradually decline as people will adopt a totally new way to communicate. A TAS should therefore be seen as an important box in an IMS network, but a box that will remain focused and essentially unchanged until its termination.

True Multimedia Communication is to be supported by something else, and this is...OMA CPM.

OMA Converged IP Messaging (CPM)

OMA Converged IP Messaging is currently under specification within OMA (the Open Mobile Alliance). In my opinion, this is by far to date the most significant step towards an optimal exploitation of IMS capabilities that I described in the past.

The name of this enabler may be misleading, as it seems to imply that CPM is a pure messaging service, while it is not.

Actually, CPM can be defined as a composite specification addressing two concerns:
- Full IMS messaging (OMA SIMPLE IM), including page mode and session-based approaches, as well as transparent interworking with legacy mobile messaging services (SMS, MMS, OMA IMPS). This could certainly be extended to other messaging services like email or Jabber/XMPP in either future versions of the specification or in smart implementations.
- Multimedia communication as I had the opportunity to describe it in the past.

Let's start with the messaging features.

Page mode messaging, which is based on the SIP method MESSAGE can be seen as the equivalent to SMS in the SIP/IMS world. A user can send a page mode short message to another user or a group of users. This message is either delivered instantly over the IMS core network or stored for deferred delivery if the recipient is not available.

Session-based messaging is based on a SIP session, with messages delivered through a protocol called MSRP. Session-based messaging essentially serves two requirements that cannot be fulfilled by page mode messaging: the support of chats, in which messages are exchanged between two or more parties within a dialog context; the possibility to send large volume files like music or video clips. In addition, session-based messaging has two important benefits: it minimizes SIP control traffic to session management, and utilizes a specific protocol for the messages itself, permitting to implement an appropriate support in the network; by reusing the concept of SIP session, it permits messaging to be one component among others in a multimedia session.

Interworking with legacy messaging services like SMS and MMS permits CPM to be interesting from the start, as it does not rely only on the initially limited IMS community to deliver its services.

The scope of multimedia communication supported by CPM is very broad.

CPM will support a wide range of discreet (e.g. messaging, files, applications) and continuous (e.g. full duplex voice, video) components. It supports the negotiation of initial components in a session, dynamic renegotiation of components in the session, and does not require any specific component to be part of the session (for instance, it is not mandatory to have a messaging component despite the name of the service). The session can be both person-to-person (2-party or multiparty) or person-to-service (and obviously person-to-person&service).

CPM supports a multi-device approach, making use of SIP convergence capabilities. It permits a user to share an identity between several devices and to use several identities per device. A user may have its CPM session shared between several of its devices on a media per media basis (e.g. video sharing on TV and voice on mobile). Session mobility between devices is also supported (e.g. ongoing session transferred from TV to mobile). The user can also define preferences on how CPM should address communication according to its devices (e.g. IMs should be sent only to mobile).

In summary, CPM supports both of the three axes I defined for an optimal exploitation of IMS capabilities: multimedia communication and user oriented convergence.

CPM supports conferencing through a variety of means supported by SIP and already used in services like PoC or IMS Messaging: sessions to ad-hoc groups (a user sends an INVITE to a group explicitly defined in the INVITE), to pre-defined groups (the INVITE is sent to a PSI identifying a group whose definition is stored in the network), and by adding participants to a session on the fly.

Interworking with non-CPM communication means is not limited to messaging. It also includes interworking with non-IMS voice, such as circuit-switched voice. This will be done by reusing current IMS/CS interworking components.

In addition, CPM supports a converged address book, converged in the sense that it is aimed at being shared by all the devices owned by the user. It also has an archiving functionality, able to store such things as messages, media objects and session histories. It interacts with presence in order to publish or access presence information for a user. CPM will also support web services towards application willing to use its services. An interesting feature is the possibility for users not to divulge their identity when using CPM, by using a nickname for instance.

The CPM architecture is quite straightforward:
- A CPM Client in the device supports CPM from a user perspective.
- A Converged Address Book component supports the address book for multiple devices.
- A Message and Media Storage component archives everything that needs to be archived.
- An Interworking Function supports interworking with non-CPM messaging solutions (voice interworking is supported through the IMS core network).
- A CPM User Prefs component interfaces with the user for CPM customization.
- The CPM Conversation Server supports multimedia sessions, and should in implementations look very similar to what I described here. Like PoC and IMS Messaging, it will be subdivided in a Participating Function dedicated to a specific user in the session (called Personal Multimedia Controller in my post on the subject) and a Controlling Function component supporting features shared by multiple users like conferencing (I called it Multimedia Focus in the same post). These SIP centric components will control media intermediaries for individual components in the multimedia session (I called them Media Mixers). Note that the specification does not mandate network intermediaries for every component, as it allows peer-to-peer media flows between devices when the operator's policies permit it.

Building block standardization approaches

Both specifications can claim (and actually do) a building block approach to standardization. However, there are significant differences between them.

CPM's approach is IMS-centric, as it intends to reuse IMS enablers like the interworking with the circuit-switched network for voice, presence, group management and to make generic and extend architecture patterns that were introduced with the specification of Push To Talk over Cellular and later reused for IMS Messaging (OMA SIMPLE IM).

On the other hand, Multimedia Telephony's approach is pre-IMS centric. The goal is to create within IMS building blocks which mimic pre-IMS voice-centric telephony, with the hope (illusion?) that a multimedia communication experience can be created through the reuse of these basic building blocks that totally ignore the capabilities of IMS.

The reader can make its own opinion on the advantages and drawbacks of both approaches.

For my part, if I was an operator, I would be very suspicious about suppliers coming with a story of a Multimedia Telephony server defined as an extension of a short-term Telephony Application Server, and would ask them about the positioning of this product with regards to CPM.

On the other hand, I would mandate from the potential suppliers of IMS Messaging products to provide a CPM-ready solution with a clear roadmap. Considering that IMS Messaging is a brand new IMS specification, it may be a big mistake to purchase in 2008 or 2009 a solution that has no clear path towards the next big thing: CPM.

Links to publicly available specifications:
OMA CPM: nothing as this is work in progress
Multimedia Telephony Requirements: TS 22.173
Multimedia Telephony Architecture: section 4.16 in TS 23.228 (the AS for Multimedia Telephony is unambiguously called TAS)
Multimedia Telephony Protocol Details: TS 24.173
Architecture for IMS Centralized Services: TS 23.292

Christophe

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

Co-existence of Conservative & Progressive Application Layers

In my last post, I described two IMS application layers, which may be seen either as conflicting or as complementing each other.

The conservative IMS application layer is the one that can be seen right now in early IMS deployments. It either re-implements legacy services (e.g. telephony) or implements new ones in a legacy silo and black box manner (e.g. push to talk, early presence).

The progressive IMS application layer is essentially in the mind of a few people and in some labs (actually it is interesting to see that NEPs tend to promote IMS using rather progressive demos, while at the same time they only propose a very conservative application layer to their customers). The OMA Converged IP Messaging (CPM) work item might be the very first attempt at standardizing something in the progressive IMS application layer, but it is not very advanced yet.

The progressive application layer would fully exploit the multimedia capabilities, fixed mobile convergence, and powerful service control characteristics of IMS and its core protocol, SIP. It would also be based on a new generation of open service platforms, provided by leading IT companies, and able to optimally combine the protocols and services originating from the IMS, Internet and IT domains.

Alternative But Compatible Communication Paradigms

A major difference between the conservative and progressive application layers is that the former recreates communication silos (e.g. voice, messaging, voice bursts, video) while the latter would permit the user to freely switch between communication media (e.g. messaging to voice), and to arbitrarily mix content, data, and communication components in a single session. In this context, a progressive IMS application layer is as much about integrating services together as it is about delivering new services.

Multimedia communication is a superset of legacy single medium communication. While it is possible to combine multiple media components in a multimedia session, it is also possible to start a multimedia session with a single component (e.g. voice), keep this single component during the session, and terminate the session as it started, with this single component.

Consequently, a progressive IMS application layer supporting multimedia communication can accomodate:
- Users whose communication style is still formatted by decades of silo communication services, and a habit not to mix communication and data/content services;
- IMS clients that are specialized in the support of one or few media components (e.g. voice-only clients);
- Interaction between multimedia communication clients and silo communication clients.

The last bullet is of particular importance, as it permits multimedia communication to be introduced without any disruption. Multimedia communication clients can interwork with each other and use the full potential of SIP multimedia sessions, as they can interwork with silo communication clients and, through IMS circuit-switched gateways, with legacy telephones.

When a multimedia communication client interworks with a silo communication client, content of the session is limited by the capability of the silo communication client. End-to-end negotiation/re-negotiation of the session (possibly with the support of network entities) will ensure the coherence of the session content between the endpoints (e.g. the attempt to re-negotiate a voice session into a video one will be rejected if the multimedia communication client interacts with a voice-only client).

Different Public User Identities For Different Services

Let us consider the situation in which the operator has deployed application servers in the conservative application layer, which support voice services (e.g. call control, conferencing), videotelephony, push to talk, and IMS messaging (though I think it would be better to avoid deploying a messaging silo in IMS).

The operator is now introducing a progressive application layer which is able, for a start, to support any of the above media in the same session, with the possibility to freely switch between them, both for 2-party calls and conferencing. Note that once you have the right multimedia architecture in the progressive application layer, you can incrementally improve its media support over time (i.e. you can add new media support as needed or possible).

How can these two application layers, supporting different user experiences, co-exist in the same network?

The answer is simple:
- As access to the IMS application layer is determined by service profiles stored in the HSS (*), a service profile can provide access to the silo communication services, while another can provide access to multimedia communication services.
- As service profiles are associated to Public User Identities (IMPUs), some IMPUs can be link to a silo communication experience, while others can be associated to a multimedia communication experience.
- As the IMS application layer clearly distinguishes between the different parties of a session, it is possible for users with different service profiles to communicate, with each accessing its own (conservative or progressive) set of services.

This implies that users which do not use IMS services (e.g. legacy telephony users), users with a conservative IMS service profile, and users with a progressive IMS service profile can all communicate together. Obviously, users with a progressive IMS service profile will enjoy a richer communication experience with users sharing a similar service profile and users making use of rich Internet clients.

This also implies that the same user can alternatively benefit from a conservative or progressive service profile depending on the public user identity it uses, i.e. the persona it has decided to take.

While this is not a mandatory approach, a quite convenient way to allocate IMPUs for conservative and progressive application layers could be the following:
- Legacy identities based on E.164 numbers (e.g. tel:+151412345) remain associated to a silo communication experience.
- New IMS identities based on SIP URIs (e.g. sip:user@operator.com) are associated to the new communication experience (however, in order to be contacted by legacy phones, there should still be an E.164 alias associated to the SIP URI).

This clear distinction based on identity types would permit to clearly introduce the new service paradigm in the mind of users as new email-like user identities are introduced. The new addressing approach based on SIP URIs would also permit to better support fixed mobile service convergence, as these identities do not have to be associated to a specific access type (in comparison to mobile and fixed E.164 numbers).

From Black Boxes To Open Service Platforms

Another possible difference between a conservative and a progressive application layer lies in the way the application layer is implemented. A conservative application layer will typically make use of proprietary platforms dedicated to the support of a single service (e.g. push to talk), while the progressive application layer will make use of standard and open service platforms (e.g. J2EE or JAIN SLEE based), permitting the co-location of services, as well as faster service development and evolution cycles.

Let us imagine that an operator initially deploys a 1st generation presence server, implemented on a proprietary platform, and totally dedicated to the support of presence, without any possibility to co-locate presence with services that make use of it as an enabler (e.g. incoming call handling based on presence).

As part of the introduction of a progressive application layer, the operator has the possibility to change from a server (black box) to an application (white box) paradigm. Presence can now be deployed as an application on a set of service platform instances, and be co-located with other applications according to, e.g. signaling traffic optimization criteria.

How can the migration from a silo implementation to a horizontal implementation take place?

The answer relies once more in the usage of service profiles.

The operator can decide to deploy the new presence application in parallel to the existing silo server(s). New subscribers will be allocated to the new presence implementation through a service profile pointing at the new presence implementation address.

The operator can then start the migration of existing subscribers from the old implementation to the new one at the pace it decides.

The migration implies a change of application server address in the service profiles stored in the HSS. A priori, existing clients need not be impacted by the change (i.e. no need to change the configuration in the IMS client) and the transition from the old implementation to the new one can therefore be transparent to them.

Co-existence and Smooth Transition

Comments to my recent posts as well as emails I received tend to paint a quite pessimistic picture about the ability of the telecom industry to use IMS for something else than the re-creation of pre-IMS service silos.

However, as a technician, I can tell that one of the "cool" features of IMS is that it can accommodate the co-existence and interworking between services implemented in the traditional telecom silo way and services (or more appropriately a user experience) making use of new paradigms. Moreover, IMS can enable a smooth and seamless transition from one to the other.

If the industry ever misses its necessary re-invention, I hope it will have the decency not to blame the technology for it :)

Christophe

(*): I often mention IMS service profiles and initial filter criteria, but never described them in details. I could dedicate a few posts to this. However, as describing standard features is not the most exciting type of post to write, I hesitate to do it. If you think this would be needed, just email me or write a comment.

Conservative & Progressive Application Layers

The IMS and related IETF specifications define a long list of ingredients that can be used to make a lot of meals (from the pizza to the gourmet menu). The only problem is that so far nobody has delivered any cookbook for it.

From this set of ingredients, you can roughly implement two application layers: a conservative and a progressive one.

I believe that these two application layers make sense, for different and complementary reasons.

The conservative application layer basically re-implements legacy services (e.g. telephony) or services which follow the typical silo mindset of legacy telecommunication services (e.g. push to talk) over an architecture which can support them, but is far from being used at its full potential. They are usually implemented with the support of black boxes in the application layer.

Everything standardized and delivered today in the context of IMS can be tagged as "conservative".

The most important service in the conservative IMS application layer is telephony. It makes sense to implement (first line) telephony services on IMS, for fixed operators who want to phase out their old, heterogeneous and expensive circuit-switched infrastructure. It also makes sense for mobile operators who wish to extend cellular telephony over circuit-switched to IMS-based telephony making use of unlicensed wireless access (e.g. WiFi, WiMax).

As for the other early IMS services implemented in a silo manner like push to talk, IMS messaging, or services combining voice on circuit-switched with data transfer (e.g. pictures, video streaming) on IMS, they may address short term business opportunities.

A great advantage with IMS services implemented in the conservative application layer is that they fit perfectly with legacy organizations, legacy business models, legacy standardization-driven development lifecycles, legacy relationships between operators and vendors, and legacy mindsets. This is not surprising as this application layer is the direct result of all this legacy.

The conservative application layer is certainly necessary to the progressive one, as it constitutes an initial motivation for operators to deploy IMS, as it does not change everything overnight for them, and as it can be seen as a first step towards something else.

This something else is the progressive application layer, which is necessary to the conservative one as it shows that IMS can play a significant role in the rapidly changing world of converging Internet, telecommunications and advanced IT.

I do not believe in the benefit of an IMS network that would limit itself to re-creating a telecommunication world that is clearly reaching its limits. This is a reason why I find the concept of communication services, as pushed by some in 3GPP, very dangerous, as it seems to define as a target an IMS application layer based on the recreation of service silos that are only marginally different from the existing ones.

Most of my posts on this blog are about the progressive application layer, but to make it short I see it based on the three pillars I introduced in my very first posts on this blog.

Multimedia Communication permits two major things:

- Switching between alternative communication means without stopping a session (e.g. messaging to voice, voice to video, video to messaging)

- Freely combining communication, content and application sharing within the same session.

IMS-enabled fixed mobile convergence permits to potentially provide every service to every device using any type of access technology to connect with the network. This is a network and user-centric convergence, which does not rely on any specific feature from devices, other than their ability to register with IMS. The key IMS concept enabling this convergence is the ability for the user to share an identity between multiple devices.

Finally, the inherent characteristics of SIP as a protocol and IMS as a powerful service framework (many posts related to this), combined with an extensive use of web services, service mashups and Service Oriented Architecture principles, can lead to an explosion of new service opportunities. These are typically services for which my 8 year old son and my telecom illiterate neighbour might have better ideas than me. Some of these services might have very short lifecycles and may target niche market segments.

Such a progressive IMS application layer might be more about a new user experience than a set of easily identifiable services. It may come with a new set of partnerships between telecom operators and 3rd parties, as well as new business models.

In order to be possible, such a progressive application layer must be supported by advanced and open service platforms, enabling the agility required by new services, as well as the possibility to optimally connect and combine the IMS, Internet and IT domains.

Such a progressive application layer will take time to happen, and comes with many challenges. Some of these challenges are technical, but I would tend to think that most are cultural and organizational, and nothing at the moment ensures that the telecom industry will be able to exploit the potential of the technology and to successfully deploy an optimal IMS application layer.

The difficulties associated to the progressive application layer make me think that it is urgent to create a common understanding of what this progressive application layer would be able to deliver and how it may look like. This blog is a modest attempt at contributing to this.

I also believe that operators should adopt an iterative and empirical experience of what IMS can deliver, beyond the wonderful voice and rich voice services.

For this, it is important to have IMS deployed, initially for the support of a conservative application layer, with the consideration that this conservative application layer can only be a first step and not an end in itself.

Once IMS has been deployed the question can shift from "do we really need IMS?" to "how can we make an optimal use of this f*** IMS we spent so much f*** money on?".

In my mind, an optimal scenario is one of operators deploying IMS to support initial products based on a conservative application layer. Then, in parallel, they start investing time and thoughts about the progressive application layer, speaking to vendors they are not used to, trialling ideas, exploring different directions, and starting to deploy simple innovative services to explore the market and the power of the technology. Slowly, the progressive application layer would mature, grow in terms of usage, and define a new user experience. Then, one day, it could fully take control and replace the conservative application layer.

I really see two physically separated application layers (through some overlaps may exist), using different service platforms and delivering different types of services.

The burgeoning progressive application layer needs not to disrupt the business generated by the conservative one. On the other hand, I do not believe that it is realistic to think that a conservative application layer can smoothly evolve towards a progressive one. There is a clear revolutionary step, and it is better to start the progressive application layer from a clean shit (of course, I am making quite arbitrary statements here, that need to be adapted and possibly corrected on a case by case basis).

For instance, you may decide that in order to support telephony services on IMS you can rely on black box application servers that just deliver the usual goods in a cost effective manner, while multimedia communication and associated services making use of such an enabler like presence will be delivered on a new generation of service platforms, to be introduced in parallel.

The conservative and progressive application layers would co-exist and even interwork for some years. In the next post I will explain of this can be done.

Christophe

PS: I have a few slides on this subject, that I had the opportunity to present in a conference. Feel free to email me to get them.

IMS for Operators with Mobile & Fixed Units

In previous posts I described how I think IMS is currently perceived by many fixed operators and by mobile operators.

Operators that have both types of organization will obviously combine the fixed and mobile perceptions. As there are important differences between them, it might not help having a consolidated view on IMS at the company level. However, it is also likely that, for reasons explained before, IMS is a topic that is more on the radar of the fixed unit. This makes that the overall perception of IMS in the company is likely to be close to the one of a fixed operator.

However, the key IMS keyword for a fixed and mobile operator is likely to be convergence.

The only problem is to define what IMS-based fixed mobile convergence is, and to answer such a basic question as: how many IMS does it take to converge?

If you ask the question to each of the fixed and mobile organization, they are likely to provide one of the following answers:

- It takes two IMS core network for fixed mobile convergence: one for the converged fixed network and one for the converged mobile network.

- It takes only one IMS core network, as long as our organization owns it. Otherwise, we believe that IMS is a bad technology.

As I already had the opportunity to explain, I believe that not only fixed mobile convergence requires a single network, it also requires a unification of the fixed/mobile subscriber into a single converged subscriber. This unification will impact the whole company, and will need to be performed in several steps.

For the operator, the possibility to deploy a unique network shared between mobile and fixed access certainly represents an important opportunity for cost savings. It also certainly promises a better user experience for customers, including interesting possibilities for convergent services, available across all the devices connected to the network.

However, in the short and mid-term, IMS is also likely to be an important source of headaches. Being linked to fixed mobile convergence, which is a topic that will touch all the organizations of the operator and will eventually lead to a major redefinition of the company, IMS is a highly organizational and political topic for operators with mobile and fixed units.

Consequently, a key question associated to the deployment of IMS for such an operator is the following: should the re-organization of technical units start before IMS deployment, or can it start later, once IMS has been deployed and is already supporting several services?

My 2 cents to this very difficult question is that it may be good to provide a minimum of clarification concerning the future of the company and its existing organizations, and maybe even more than this, if the operator does not want to see an anti-IMS coalition being formed in organizations which do not know what their future will be.

This said, I believe that an operator that successfully handles the FMC challenges has good assets for success in the future telecom world, by its deep understanding of both the mobile and fixed domains, and by its established footprint as both a mobile and fixed operator.

Typically, in a case where a mobile operator would hesitate to deploy an innovative service because of the hurdle to get the relevant support in mobile handsets combined with doubts about its business case, a converged operator could decide to first deploy the service on open fixed devices (e.g. a PC), see how successful it is, and then drive the porting of the service on mobile handsets once it is confident that there is a clear demand for it. Similarly, a converged operator may from the beginning conceive services that will be accessible through fixed and mobile devices.

As a conclusion I would say that an operator with fixed and mobile units certainly faces the biggest challenges for deploying IMS, because of the FMC-enabling nature of IMS, while it may at the same time have the most interesting opportunities, thanks to the same FMC-enabling nature of IMS.

Christophe

Three Axes for IMS: #1 Fixed Mobile Convergence

I personally see three areas where IMS and SIP can dramatically modify the telco and Internet landscape. When I write "IMS and SIP" this is because SIP has intrinsic capabilities that are independent from IMS, and can be exploited within the Internet, while on the other hand the IMS specifications define a specific architecture for a SIP network, an architecture that has its own merits on top of those from SIP. I will certainly come back on this.

In this entry I will describe the area for which IMS is mostly mentioned: Fixed Mobile Convergence.

At the moment, in the industry FMC is often equalled to the ability of a mobile handset to connect to both the mobile and fixed network, through the support of dual cellular / WiFi (or Bluetooth) access. The term is also tightly linked to voice services, and the industry tends to compare the merits of UMA and IMS/VCC as alternative implementations of FMC. The skeptics then argue that FMC will not reach the mass in the next few years, due to the need to have hybrid devices to support it.

For me, the role of IMS into Fixed Mobile Convergence can be much more important than the support of dual mode devices and Voice Call Continuity (VCC), which permits to smoothly switch from WiFi to cellular access, and vice versa.

A first level of IMS-based convergence is technological. Basically, IMS is the common standard for next generation fixed (TISPAN), cable (PacketCable) and mobile (3GPP, 3GPP2) networks. Such an understanding of IMS as an FMC technology is very limited, as it may lead to the conclusion that an operator with fixed and mobile networks can converge through the deployment and interworking of separate fixed and mobile core networks. This technical convergence would lead to a certain homogeneity between fixed and mobile networks, the ability for both to support very similar services, and the possibility to find synergies between the fixed and mobile organizations of the operator. Fine, but is this enough?

The next level goes one step further: if IMS is the common standard for next generation fixed and mobile networks, it is possible to achieve FMC through the deployment of a unique IMS core network for fixed and mobile access. Moving from two separate fixed and mobile networks to a single shared one clearly has cost-related advantages, both from a CAPEX and an OPEX perspective. You can also assume that the user experience will benefit from this homogeneous core network support. Fine, but is this enough? Limited to core network unification, FMC still considers that mobile and fixed subscribers are different users.

The last level brings FMC at the user level, and for this relies on the intrinsic features of the SIP protocol. Through IMS, it is possible to finally unify the mobile and fixed dimensions of a human being into one. IMS permits to associate to users access independent public user identities (e.g. sip:user@operator.com, tel:+33123456) that can be concurrently registered from multiple devices using different access technologies. For instance, a user can concurrently register the same identity(ies) from its mobile device, PC, Television set, and fixed phone.

When a SIP request is addressed to this identity, the network implements (standard SIP) mechanisms to alert the user on the different devices or to look for the best device to reach the user. The basic mechanism for this is called "forking", and the ability to more intelligently select devices is based on IETF RFCs relating to callee capabilities (the ability to register the services and features supported by a device) and caller preferences (the ability to instruct how forking should be performed according to callee capabilities).

In IMS, public user identities are associated to so-called "service profiles" stored in the network user database, the HSS. This service profile determines how SIP requests generated from or addressed to the identity will be routed to IMS applications. It therefore constitutes the key for the door to IMS services. The fact that this key is associated to a user identity and that this user identity can be shared across devices and access technologies makes that all services deployed on IMS are inherently converged, i.e. uniformly accessible from all devices and access technologies employed by the user. Service implementation can then adapt the delivery of the service to the specific characteristics of a device or the access technology it uses.

It is important to note that such a user-centric fixed mobile convergence is totally network-based and does not require that devices be able to connect to the network through several access technologies. This means that IMS-based convergence does not put any other requirement on devices than their ability to register with and access IMS over IP. Once the IMS core network is deployed, all IMS-enabled devices making use of an IMS-compatible access (e.g. WiFi, WiMax, xDSL, GSM, UMTS, Cable) can be converged.

Obviously, these services are not limited to voice. The other two axes for the exploitation of IMS capabilities will provide a certain view on what IMS services can be about.

Christophe