Defining an IMS Strategy

As a set of specifications or as a set of products provided by telecom suppliers, IMS is not the answer about how to ensure a bright future for telecom operators.

Basically, IMS should be perceived as a toolkit, which can be used alternatively or successively in various manners leading to drastically different results. As a consequence, an operator needs to define a short, mid and long term strategy based on IMS that suits its business strategy, and it has to take the adequate measures to apply this strategy. Here, we are touching the biggest IMS issue. It is not technical but rather cultural, practical and organisational.

In this post, I will try to outline some potential elements of an IMS strategy.

Deploying IMS

While some operators may simply decide to deploy IMS as part of their network evolution roadmap, many require an initial motivation to take the decision to go for it.

At the time being, the main triggers for deciding to deploy an IMS network are certainly the following:

- Replacement of the legacy circuit-switched network for fixed telephony services (IMS used as PSTN emulation subsystem).

- Deployment of a carrier grade VoIP solution for fixed residential customers, possibly with mobile/fixed convergence services including or not call contuinity between fixed and cellular access (knowned as voice call continuity).

- Deployment of carrier grade enterprise services including for instance business trunking, IP centrex or fixed mobile convergence.

- Deployment of a compelling set of mobile services through the Rich Communication Suite (RCS) or something else.

- Deployment or migration of an IPTV solution making use of IMS.

- Deployment of a selected set of IMS-enabled fixed mobile services.

However, such initial motivations are not always strong enough to validate investments in IMS.

For instance, a fixed operator may wonder why it should invest in IMS to reimplement a telephony service whose revenues are rapidly decreasing and which is likely to eventually be offered for free. Likewise, the usage of IMS for a specific service like IPTV or RCS or for a specific business segment like enterprise may not be economically worth for the operator.

It is therefore necessary for the operator to have a strategy for extending the usage of IMS beyond its initial deployment scope in order to have an optimal return on investment. Such a strategy is also fundamental for the operator to decide on future investments.

More especially, any decision to eventually replace a pre-IMS service implementation (e.g. telephony, messaging, IPTV) with an IMS one may impact the investment and evolution plan for the pre-IMS implementation.

The Future of Telephony

The future of existing telephony services and their implementation is a tricky issue that needs to be addressed carefully.

Basically, IMS permits to:

- Re-implement classical telephony services for legacy terminals and narrowband access (IMS as a PSTN emulation subsystem in ETSI TISPAN)

- Implement a new generation of voice-centric telephony services for new terminals (e.g. SIP phones) and broadband access

- Implement a new multimedia communication experience, in which voice is only a media component among others, whether they are related to person to person communication (e.g. messaging, video), content (e.g. streaming video, files) or data (e.g. events, application sharing, shared browsing).

The operator needs to clearly identify these services, decide which ones it wants to deploy, how, and in which timeframe.

Once this diversity has been understood and associated decisions have been taken, the operator can start to think about the implementation of related value-added services. For instance, are or should the value added services be the same or be different for each variant? Should they be implemented on the same or different platforms?

The operator can also think, if relevant with its plans, about how these different types of voice-related services should co-exist and possibly interwork.

The relationship between IMS and classical telephony services is of particular interest. It goes beyond the question of replacing the circuit-switched core network with an IMS based IP network as the two networks will co-exist for some time, and during this transition phase the support of value-added telephony services for both may be a question in itself.

The operator may have the choice between several alternatives and decide to opt for one or to evolve from one to the other over time:

- Using different service implementations in both networks (e.g. Intelligent Network in CS and a Telephony Application Server (TAS) in IMS)

- Reusing legacy Intelligent Network solution(s) in IMS

- Re-implementing services on a new platform able to support both IN and IMS ISC interfaces

- Reusing the IMS TAS for delivering value-added services to circuit-switched voice, in replacement to Intelligent Network servers (ongoing standardisation in 3GPP as IMS Centralized Services)

The future of messaging

In mobile networks, various messaging services can exist such as SMS, MMS and IMPS (OMA standard for mobile Instant Messaging).

IMS messaging has the potential to emulate all these messaging services and to add more to the user experience. The operator may therefore have to decide if and when it wants to eventually replace all of the existing messaging services and how it wants to manage the transition phase during which IMS messaging takes off and co-exists with them.

Moreover, as for voice, the multimedia nature of IMS makes that messaging may eventually cease to exist as a standalone service and be part as a multimedia component, of a more global and powerful multimedia communication paradigm. Should the operator skip the silo IMS messaging step and go directly to the multimedia communication service or should it implement one after the other? If so, how should the migration be performed?

IMS as a multi-service platform

An important feature of the IMS service architecture is its ability to support the harmonious co-existence of multiple services related to communication, content and data. This is a discriminating feature compared to a non-IMS SIP network, which lacks a standard service architecture and requires ad-hoc and often cumbersome support for the co-existence of several services, with limited multivendorship possibilities, and this until the architecture explodes after the hack too much (as this happens with all silo architectures whose limits are pushed too much).

An advantage of using an IMS core network as a multi-service platform is its ability to factorize and make coherent such functions as service discovery, user identification, user authentication, QoS and policy control, security, detection of the access technology used by the subscriber for service adaptation purpose (e.g. UMTS vs. LTE, xDSL vs FTTH) or interworking among operators, among others.

There are important cost savings to be achieved through deploying multiple services on IMS, both in terms of simplifying service implementation and harmonizing the support of functions common to multiple services.

There can also be important benefits related to the centralized knowledged in the IMS of service usage by subscribers, like the ability to apply QoS policies that take into account the multiple services used in parallel from the same home or device.

The operator needs to prepare and plan for the gradual support of new services and the porting of existing ones on IMS. This implies, among other things, not to take architectural decisions related to IMS that are specific to one service and may prevent the deployment of new ones in the future. To take a simplistic example, an Initial Filter Criteria routing all SIP INVITEs to a TAS may work as long IMS is used to support a single telephony service. On the other hand, it can be a source of nightmare as soon as an IPTV or IMS Messaging service (both making use of INVITEs as well) is introduced.

Using IMS as a multi-service platform is not always straightforward for operators which are used to deploy silo services and whose decision processes and organizations are defined according to this paradigm. An IMS strategy may therefore include organizational and decision process changes as well.

IMS for new services

I have often read that IMS cannot support new services. This is a wrong assessment.

The versatile nature of the SIP protocol, illustrated by the invaluable concept of event packages, the ability to integrate the IMS application layer in a more global SOA (Service Oriented Architecture) and UOA (User Oriented Architecture) framework, and the possibility to strongly integrate IMS with the Internet and its services create thousands of opportunities for new services, many of which are not connected to person to person communication.

The operator needs to define a strategy related to this opportunity for innovation: whether it wants to use this opportunity, how, what changes need to be done in organizations, skills and practices.

IMS for a new user experience

Possibly more important than new services, IMS permits to create a brand new user experience which makes that the frontier between services as we know them can totally disappear.

As already mentioned above, multimedia sessions permit to deliver communication, content and data services in a combined context.

Moreover, IMS-based fixed mobile convergence has the potential of eventually making the device and access technology used by the subscriber a mere detail of service delivery. Using a converged subscription, a user could access all its services from all its device, from all access technologies (whether fixed or mobile) and with the same identity.

Such a full convergence cannot happen overnight due to various reasons related to organizations, existing business processes, cultures, regulation, and to a much lesser extent, technical issues.

The operator must therefore plan and prepare for these evolutions, defining clear steps towards a the target. For instance, the operator may initially decide to use the cost savings aspect of IMS based fixed mobile convergence, by sharing the same IMS core network between fixed and mobile subscriptions. It also must decide if and how it eventually wants to support full convergence. For instance, will the operator eventually offer only converged subscriptions or will it permit subscribers to chose between converged and non-converged subscriptions? In this latter case, what would be the implications?

Managing the complexity of the IMS application layer

This blog has often tried to describe the fantastic power of the SIP protocol and the IMS service architecture to deliver rich services.

One of the outstanding features of the service architecture is its ability to combine services or service logic components residing in the devices, in the operator's network and across different operators' networks, the Internet or Enterprise networks, in a very flexible manner.

There are basically two composition mechanisms:

- Implicit composition: device and network based service logic or services are chained in the SIP signalling path.

- Explicit composition: device and network based service logic or services make use of each other through an appropriate interface like SIP, web services, HTTP, RTSP, H.248 or another protocol.

While very powerful from a functional perspective, this potential leads to new complexity related to distribution, compared to the traditionally centralized implementation of telecommunications services.

The operator must therefore find ways to deal with this complexity by addressing issues like the definition of relevant compositio handling functions like the SCIM, the management of service composition data like Initial Filter Criterias and SCIM information, the addressing of potentially redundant or conflicting functions across different servers, or the determination of approaches to measure quality of experience or determine root causes for potential problems.

Optimizing the IMS application layer

These distribution and composition mechanisms also lead to potentially critical optimization issues.

These optimization issues may for instance relate to:

- End-to-end performance if too many physical servers are involved in service delivery. In an extreme case, a spectacular service on paper may simply be irrealistic in practice due to disqualifying delays in service delivery to the end user.

- The load of IMS entities, more especially the S-CSCF and application servers, which are essential components in service delivery and composition.

- The cost of deploying and operating services if the application layer is too heterogeneous and too distributed or if features are duplicated across multiple servers.

- The impact of the failure of a server, for instance an application server, on subscribers. For instance, how many users will be impacted by the failure of an AS and for which services?

The operator must therefore define an optimal strategy to deploy services, which optimizes the user experience while minimizing costs and risks. This issue has to deal with service platforms and service topology. For instance, IMS offers alternatives to the dedication of an application server to a certain service for a large portion of subscribers by permitting on the contrary an application server to support a variety of interdependent services for a smaller subset of subscribers.

Service Platforms

The choice of service platforms is a key component of an IMS strategy, though only one component among others.

An operator has basically the choice between two alternatives for a service platform:

- A black box delivered by a service supplier.

- An open service platform delivered by an IT vendor, usually called Service Development Platforms (SDPs) in a telecom context, on which services are applications delivered by application providers or implemented in-house by the operator.

Concerning SDPs, the operator has further choices between alternatives like IT-centric platforms (e.g. J2EE, .Net) or telecom centric ones (e.g. JAIN SLEE, OSA application servers).

Each approach has its advantages and drawbacks, and these may differ depending on the considered timeframe. The operator should therefore define criteria permitting to select the most appropriate platform for a given service in the short, mid and long term, and prepare for the potential migration from one to the other, when appropriate.

IMS clients and devices

The best package of IMS services is useless if it is not adequately supported by clients and devices.

The operator must address such key issues like:

- The distribution of service logic between devices and the network. Note that depending on the characteristics of a device (e.g. high end vs low end, mobile vs. fixed), a given service may require different implementations or implementation variants for access by different devices.

- The distribution of service logic and IMS support between different devices on the customer premises, e.g. a home gateway and end-devices.

- The management of IMS client updates to support new IMS services.

- Optimizing device management by using IMS-intrinsic benefits.

- Spreading IMS support in the wider range of devices.

- Presenting IMS services in an optimal way to end-users in order to make them attractive and make their access and usage intuitive.

Conclusion

IMS by itself is not an answer to the challenges an operator will face in the future. An operator should define a coherent strategy comprising which components of the IMS potential it wants to use, in which timeframe and how.

While many operators have already deployed IMS or are planning to do so, usually with a well defined short term objective, I have the feeling that only a few are actively working on a mid and long term IMS strategy.

This is a pity, because defining such a strategy would permit to:

- Help IMS acceptance in the company by outlining the short, mid and long term benefits expected from it.

- Anticipate on changes required in organizations, practices, and skills to apply the strategy. By doing so, speed up the implementation of the strategy.

- Have a better control of short and mid term investments, for instance by avoiding excessive investments in implementations or services whose lifetime will be shortened by the implementation of the IMS strategy.

As you may infer from this post, I have put a lot of thoughts in these topics. Do not hesitate to contact me on this.

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

A Bulding Block Approach to Standardization

For decades, the telecommunications industry has standardized solutions from A to Z, with little if any reuse of existing specifications when creating new ones. The progressive migration from circuit switched to IP based services did not initially change this fact much: MMS or OMA IMPS (that I take as an example in this post) are typical examples of creating telco-specific standards based on a loose reuse of IETF ones (SMTP for MMS, HTTP for OMA IMPS).

This has changed with IMS, and more especially its SIP component. 3GPP and the IETF collaborate with each other, and needed extensions to the SIP protocol due to IMS requirements are under the control of the IETF.

By importing IETF specifications into telecom standards, 3GPP implicitly accepted the building block approach to specifications that is common place in the Internet domain. In this post I will try to describe this approach and its benefits.

Building block standardization of SIP

SIP is a textbook example of a building block approach to standardization. The people and groups in charge of specifying SIP constantly try to apply the following rules:
- Do not reinvent the wheel. Reuse and adapt existing specifications if they fulfill your requirements. Only create when needed.

- Make everything as generic as possible. Even if your requirements are very precise, try to make your solution generic enough to be reused for other requirements.

Here follow some examples of how this was applied to SIP standardization:

- SIP sessions make use of the Session Description Protocol (SDP), which was specified prior to SIP. In effect, it is possible to use SDP without SIP.

- SIP SUBSCRIBE and NOTIFY methods were initially created to support a very specific requirement, actually related to the telecom domain (the support of the telephony Automatic Call Back service with SIP). However, it was decided to make the concept a generic and extensible means to distribute event notifications in a SIP network through event packages (see the first draft for SUBSCRIBE/NOTIFY here). When a part of the IETF community decided to support presence through SIP, they simply had to reuse the event package specification and create two presence-specific event packages. While the requirement was initially very specific, it gave birth to a concept that is fundamental for SIP and constantly evolving through the creation of new event packages. It is actually remarkable that this is a telephony -related requirement that led to a SIP concept which opens the door to a large variety of non-telephony related applications of the protocol.

- In the Instant Messaging (IM) area, presence was initially no more than a single state, describing if a recipient could accept an IM. The IETF decision to support presence through the inclusion of an XML document in the body of SIP methods, and allowing extensions to the basic schema, permitted the definition of presence to be gradually extended to become a large set of information about users (or services), their communication means, terminals and applications.

- SIP PUBLISH was initially created specifically for a client to remotely update presence information. The first versions of the draft were tightly linked to the presence event package and made impossible the reuse of PUBLISH in different contexts (see the very first draft here). However, the IETF community rapidly ensured the possibility to reuse PUBLISH for all existing and future event packages. PUBLISH therefore contributed to the enrichment of SIP-based presence, but at the same time a requirement initially scoped to presence contributed to the enrichment of the whole SIP protocol.

- Instant Messaging through SIP was initially supported only through the creation of a new SIP method: MESSAGE. However, it rapidly emerged that this approach was far from optimal to support all potential requirements associated to instant messaging: the concept of chat, which embeds IMs in a specific dialog context, the need to potentially exchange large documents via IM (e.g. a video file) while SIP is a control protocol and not a transport one like HTTP, or the need to support potentially high IM traffic while a SIP infrastructure might not have been implemented with this purpose in mind. It took time and several tries for the IETF community to address these requirements, and the final decision was to reuse the concept of SIP session as well as another protocol to transport an IM within the session. As a protocol like HTTP was not optimal to support the requirements for this IM transport protocol, it was decided to specify a new one called MSRP. This decision makes the comparison between Jabber/XMPP and SIP to support IM very biased. Maybe Jabber/XMPP is a better protocol than SIP for IM. However, Jabber/XMPP was initially specified and optimized for it, making its extension for, say VoIP, far from straightforward. On the other hand, in a SIP context, IM can be perceived as one communication component among others in a multimedia session.

OMA IMPS vs. IETF Presence and IM

The vertical standardization mindset that still prevailed a few years ago in the telecom community can be illustrated with OMA IMPS (initially called Wireless Village), a mobile specification to support instant messaging, chat rooms and presence.

Instead of reusing IM and presence related protocols available in the Internet, the Wireless Village group decided to specify a client to server protocol and a server to server protocol that would be specific to the mobile telecom domain, just reusing HTTP as a semantic-less transport protocol for OMA IMPS commands.

The group also decided to define IM, chat rooms and presence as tightly coupled together from a protocol and an architecture perspective, and to tightly link presence information to the mobile context.

In order to support its requirements, the Wireless Village group had to define various kinds of user lists (or groups) serving different purposes. Instead of creating a generic user group concept, they decided that each group fulfilling a specific purpose was a distinct object. Consequently, each group object led to a set of specific commands in the protocol, for creating/deleting the group, adding/removing elements to it, etc. With such an approach, if you define, say 4 types of user groups and 6 management commands, you end up with 24 distinct commands in the protocol.

In comparison, to address similar objectives, the IETF decided to decouple various concerns.

While presence is a concept originated in an IM context, the IETF decoupled one from the other, permitting each to evolve independently, thus permitting presence to apply to a much broader scope than simply IM.

By reusing the SIP session concept for session-based IM, the IETF permitted both the implementation of IM-specific systems, and multimedia systems using IM as one component among others in a SIP session.

The approach to address user groups and associated management, specified in RFCs related to XCAP, followed this approach:

- A user group is a user group, no matter what it is used for. The same user group can serve different purposes, and the set of applications for user groups is not arbitrarily bounded.

- A user group is user data, and there might be other user data that require similar access and management. No need to specialize access and management methods to user groups.

Consequently, XCAP is an HTTP-based protocol defining a few data management methods. The data itself is specified in XML, and there exist specifications for these data being user groups. As one of the requirements associated to data management was to be able to notify a user about changes made to data, the IETF decided to use a SIP event package. In effect, the IETF specifications for user data management include the joint usage of XCAP and SIP.

Building block standardization approach in IMS

The building block mindset to specifications has spread to IMS and non IMS standardization into 3GPP.

For instance, despite a terminology which is heavily related to SIP sessions (e.g. CSCF - Call Session Control Function), the IMS core network can be seen as a SIP connectivity network able to route SIP signaling, whether it is session-related or not, within an IMS domain, across IMS domains, and between IMS and non-IMS SIP domains.

In this context, IMS Presence, Messaging, and Chat Rooms are implemented as independent applications on top of the IMS core network and that make use of it. Once again, the comparison with OMA IMPS is quite interesting:

- OMA IMPS specifications lead to an implementation based on a network of IMPS servers over the mobile IP network. An IMS implementation relies on deploying application servers on top of an IMS core network. The IMS core network directly supports some of the requirements that are supported vertically in the OMA IMPS specifications (and implementations), like user authentication or routing and interfacing between various operators' OMA IMPS networks.

- OMA IMPS specifications tightly link the concepts of IM, presence and user groups. On the other hand, IMS specifications treat each of them as independent enablers which can be used together or in different contexts.

- OMA IMPS specifications were totally under the control of the Wireless Village group, and then OMA. On the other hand, by reusing IETF specifications, IMS specifications directly benefit from the evolutions performed in the IETF community, including some originating from people and companies which do not belong in the telecom or IMS domains.

A quite similar comparison can be applied to MMS and the equivalent support through IMS messaging.

Another interesting example is the 3GPP Generic User Profile specification, which permits to provide a centralized and homogeneous access to user data actually residing in various locations (e.g. HLR, HSS, AuC, application servers) and normally accessed through a variety of protocols (e.g. MAP, Diameter, LDAP). At the beginning of the erratic standardization process for GUP, 3GPP intended to standrdize a specific GUP protocol as well as a specific GUP schema to describe user data. Later on, it was decided to align on the specifications for Liberty Alliance, which define web services permitting 3rd party service providers to access user data owned by the network operator. As a consequence, GUP can be used directly as the means to access user data in network databases to support the Liberty Alliance web services exposed to 3rd parties.

The GUP specifications were also made generic enough to clearly distinguish between the methods used to access and manage user data and the data itself, that needs to be specified by instantiating and extending the generic GUP schema. On the other hand, the GUP specifications also include a SOAP-based user data modification notification mechanism, which duplicates what SIP event packages can and do support for XCAP. However, one can argue that the usage scope of GUP is broader than IMS and cannot rely on a protocol that 3GPP only uses in the context of IMS.

Some advantages associated to building block standardization

Reusing existing specifications instead of defining them from scratch permits to speed up the standardization process.

A protocol component or an application performing a generic task can be implemented once and reused several times, leading to faster development and validation.

In some cases, building blocks can be re-arranged with others to create new solutions. I gave the example of session-based messaging which, by applying the concept of SIP session to instant messaging, permits to integrate IM as one component among others in a multimedia SIP session.

Christophe

An IMS Application Server in Context

The figure above (click to enlarge) shows how an IMS application server can fit in a service delivery context that includes a legacy telecommunications environment, the Internet, the IT environment of the users it provides services to, and (of course) the IMS.

This picture might not be perfect (though I like the shades of blue), but let me know if you can find much better in the current IMS literature.

A specific instance of an IMS application server may only implement a subset of the features shown in this figure, depending on the capabilities of the platform supporting it, and its potential specialization based on the logic it supports.

It is not the purpose of this post to discuss the technologies that can be used to support such an IMS application server. However, if you look for platforms able to support most of what is implied here, J2EE and JAIN SLEE are certainly the best candidates, and a combination of both might be the winning ticket right now.

Pre-IMS Context (white boxes, black arrows)

The white boxes and black arrows represent the typical pre-IMS context of an application server, that applies to most current Service Delivery Platforms (SDPs).

Applications implemented on the application server can make use of a set of network capabilities such as call control, location, SMS, MMS.

Each set of capabilities is supported by a dedicated network server (e.g. switch, location server) and through a specific network to network interface (e.g. INAP, MLP).

On top of these protocols, the typical SDP provides for the service logic it hosts such features as horizontalization (e.g. hiding of the underlying stove pipes), homogenization (e.g. via a set of similar APIs), simplification (e.g. hiding details of ugly telecom protocols), and abstraction (e.g. permitting to manipulate a call at a high level).

It also exposes the capabilities to 3rd party service providers, through CORBA APIs (e.g. Parlay Classic) or web services (e.g. Parlay X).

The set of capabilities available to service logic in the SDP and to 3rd party service providers is limited and static. It followed a very slow standardization and implementation process, starting with the standardization of the network enabler (e.g. IN), and finishing with the implementation of (standardized) web services (e.g. call control). This means several years.

IMS, and more generally the move to all-IP can change all this and make the picture more colorful.

Where is the IMS Core Network? (lower part)

You might have noticed that the figure does not show any IMS core network entity (e.g. CSCFs, HSS, gateways).

This is not because they are not there or they are not important to the IMS service architecture. Actually, without them, the IMS service architecture would not exist at all!

The point is that the IMS core network itself is of limited relevance from an application perspective, compared to the sophisticated SIP routing mechanisms it provides. This is an aspect that is usually overlooked, as the IMS core network is often the tree that hides the forest to those who try to understand the IMS service architecture.

For instance, I believe that ISC (IMS Service Control) should not be considered as an interface between the S-CSCF and the IMS application server, like INAP is an interface between a switch and an Intelligent Network server. ISC is just the SIP road that permits to connect the IMS application server to the IMS/SIP motorway that connects all the blue entities in the lower half of the picture.

One of my core beliefs is that, among all the benefits the IMS core network can provide to its application layer, one of the most important should be its transparency. An application should only care about what the IMS architecture can provide to it, not about the sophisticated details of how this is done. The application should only know that by issuing this SIP message to this user identity, it will be able to magically access this enabler (e.g. the presence information of this user), and that is all. This is unfair for the hundreds of pages that specify the IMS core network, and the thousands of workers that implement or will operate it, but life is unfair.

SOA and UOA (upper vs. lower parts)

As I wrote in an earlier post, the IMS service architecture as it is depicted in 3GPP specifications is like a picture of a person which would only show its lower half. The reason for this is that 3GPP IMS specifications are core network centric, and only address the relationship between the IMS application server and the core network.

Whereas the pre-IMS application server only exposes a few web services to (hypothetical) 3rd party applications, the future application server should be an integral part of a service oriented architecture, in which applications deployed in the operator's domain could as much be consumers of 3rd party services as they expose some, and could as well integrate with the user's IT environment (e.g. calendar, applications running at home or in the office).

This Internet and IT -centric dimension of the application layer is complemented with its IMS and SIP counterpart (SIP is not the only service protocol that will be used in the IMS, and IMS is not the only network making use of SIP), which adds user orientation to the global service architecture.

To over-simplify, the service oriented architecture routes service requests according to the identity of services, while the user oriented architecture enabled by IMS and SIP can route service requests according to user identities, service identities, or a combination of both. As a consequence, the identity of a user placed in a SIP message (as originator or recipient) may impact service routing and direct the SIP service request to network-based applications serving the user, client or endpoint applications serving the user, or the user itself.

In terms of semantic, it is time for the large part of the telecom industry that still ignores it to understand that the concept of SIP session is much broader than its legacy "call" counterpart, and that SIP is not limited to session control. There are other SIP methods and mechanisms which could be of great interest in the future application layer (e.g. SIP event packages), and which sometimes overlap with the semantic usually associated to web services (e.g. will you use a web service or a SIP SUBSCRIBE to access user information?).

IMS Capabilities: Numerous, Dynamic and Everywhere (lower part left)

The semantic power of SIP, as well as its extreme extensibility and versatility compared to telecom protocols (just look at the rate new SIP drafts pop up in the IETF) make that capabilities usable by applications can be varied, dynamic and multiple.

These capabilities will seldomly be located in standardized network servers like today.

Some will be located in IMS application servers. Every new IMS application exhibiting a SIP interface to end users might be usable as an enabler by other applications using the same SIP interface. Some of these applications could themselves be used as enablers, and so on,

Other capabilities will be located in endpoint servers and devices connected to the IMS, including those associated to end users in a fixed mobile converged environment (e.g. mobile phone, PC at home, home gateway, set top box, fixed phone). Every new application deployed in these endpoints and devices may give birth to new enabling capabilities usable by the IMS application layer. Just to take an example, there exists today a SIP event package that can be used to monitor the activity of a user on a keyboard.

Access to these enablers located in network application servers, IMS devices and enpoint servers, can cross network boundaries. This is, an application located in operator X's network can access an enabler located in or registered with operator Y's network or in the Internet. For instance, an application associated to John, subscriber of operator X, can access the presence of Alice, subscriber of operator Y, and the presence of Bob, located in the Internet.

Web Services, SOA: Much More Possibilities (upper part center)

The multiplicity and dynamicity of IMS service capabilities permits the operator to offer a much richer and differentiated set of IMS services to 3rd party service providers.

Besides the usual communication-related suspects, a large portion of these services are likely to be informational: information about the user, its preferences, its data, its applications, its devices, its activity, etc. It will be the responsibility of the operator to preserve the intimacy and privacy of the users.

The dynamic approach implies that operators will have to rely less on standards and more on differentiation in order to attract third party service providers. This is one example, among others, about the need for the telecom industry to find a new balance between standardization and differentiation.

Web services are not the only way to integrate 3rd party services in the operator's offer. This integration can also be performed on a more horizontal axis.

3rd Party Services Integrated Through End-to-End SIP (bottom part right)

3rd party applications located in the IMS (e.g. in a different operator's network) or in a non-IMS network (e.g. the Internet) can have an end-to-end SIP interaction with the IMS clients of the operator's subscribers. These rd party applications may either be network-based (e.g. implemented in an IMS application server) or device/endpoint server based.

This end-to-end service interaction can be placed under the control of the IMS application server, as soon as the service profile of the user is provisioned with an initial filter criteria that identifies end-to-end SIP signaling between the user and the 3rd party application.

For instance, routing of SIP signaling to the IMS application server may be determined by the fact that the SIP request is addressed to a specific SIP URI (e.g. sip:this_service@3P_SP.com), a specific SIP URI domain (e.g. 3P_SP.com), or because the SIP request explicitly identifies a 3rd party application in a SIP header or in an SDP (session description protocol) body. For instance, the name of a game could appear in the session description of a SIP INVITE aiming at starting a gaming session.

Service logic inserted in the signaling path between the user and the 3rd party service can serve various purposes: control, charging, monitoring, adding value. Do not overlook the latest item: telecommunications should not be only about control and charging.

3rd Party Services Through SIP Indirection or Inclusion in SIP Session (same)

This is just a variant of the previous one.

This case differs from the one above because SIP interaction only takes place between the user and the service logic hosted in the IMS application server.

The 3rd party logic or content is accessed/controlled through other protocol(s) than SIP (e.g. HTTP, RTSP, web services).

I already gave an example of such an integration through SIP indirection. In the future, I will post another one showing inclusion of 3rd party content in a SIP session controlled by the operator.

The Ut Reference Point (lower part left)

The picture shows the support of the Ut interface which, in the IMS service architecture, permits an IMS client to interface with the IMS Application Server using XCAP (HTTP-based protocol that manipulates XML documents) for service data management.

I extended this interface to HTTP in general, as it is very important to permit that IMS clients interact with service logic through advanced web-based user interfaces. Other relevant protocols may be added as needed.

Conversion Between SIP and Non-IMS Protocols (upper part right)

It can be rightfully argued that this should not be part of the SOA layer, but please bear with it.

The IMS service architecture makes it very convenient to detect and divert SIP signaling which needs to be converted into another protocol (e.g. Jabber/XMPP, OMA IMPS CSP) to an IMS application server serving as gateway towards this other protocol. Conversely, the IMS Application Server can receive non-IMS messages and convert them towards SIP for interaction with IMS clients.

This approach is currently used in 3GPP for the support of SMS over generic IP access (which encapsulates legacy SMS's into SIP IMS Messaging).

Note that the IMS core network only supports protocol conversion from/to legacy circuit-switched networks for voice calls. The rest is up to the application layer.

Christophe

IMS for Mobile Operators

I will try to dedicate a series of posts to analyze how I think IMS is perceived by different types of operators.

I will first focus on mobile operators, as this is a world I have known for years. I will then speak about fixed operators, and finally about operators that have both fixed and mobile organizations. Unfortunately I have too little knowledge about cable operators to dare saying anything about them.

IMS was an invention of the mobile industry, as its standadization started as early as 2000 in 3GPP (with initial work started the year before in the AT&T Wireless -led 3G.IP initiative).

The positioning of IMS in the cellular world cannot be voice-centric, for the simple reason that 3GPP specified a softswitch architecture as part of 3GPP R4, which permits to support VoIP within the mobile core network while keeping circuit-switched channels on the cellular access. Many mobile operators have deployed or are currently deploying this new architecture, and this is not to replace it with IMS in the next few years.

This is why, from the begining, 3GPP defined IMS as a network initially for "new multimedia services" and then, years later, to eventually replace the circuit-switched core network and therefore support legacy services as well (at least those that still make sense at the time).

An issue is that 3GPP never came up with a clear definition or list of such "multimedia services" (though it could be rightly argued that this was not the role of 3GPP to do it), and little progress has been made to this respect in the last years.

There are other important handicaps for using IMS in a mobile context:
- Current cellular access cannot efficiently support real time media over IP (e.g. conversational voice or video)
- Mobile handsets are still closed devices, and introducing openness and innovation into them is a slow and difficult process.

A consequence is that mobile operators will try to think of IMS in terms of "innovative services". However, the telco industry has shown so far little proficiency in creating innovative IMS services, and even when it does it faces the challenge to implement the relevant support for these services in mobile handsets and in application servers.

Push To Talk Over Cellular (PoC) was the first mobile IMS service to appear. The idea was to adapt a successful enterprise group walkie talkie service implemented on a circuit-switched network to the residential mass market and IMS. PoC has the (technical) advantage of relying on talk bursts instead of real time bidirectional voice. From a business perspective, the results are mixed, to say the least.

Then came so-called combinational or rich voice services, which try to combine a voice call established using the circuit-switched network with a data session over IMS. The approach permits to address the cellular voice over IMS problem, by integrating circuit-switched voice with non real time IMS services. It requires mobile handsets able to concurrently use circuit-switched and packet-switched sessions, with a client that transparently combines them for the end user. This approach led to "Push To X" services, permitting for instance to send pictures or to stream a unidirectional video during a voice call. Whether they are successful or not, such services are certainly not enough to support a convincing IMS business case.

IMS Messaging might deliver very interesting services for mobile operators, but this part of IMS/SIP standardization is not totally mature (at least from an implementation perspective), and in the meantime operators tend to directly support Internet IM integration (e.g. Google, Yahoo). The positioning of IMS Messaging with legacy SMS and MMS (with risks of cannibalization) is also an issue to consider. On the other hand, and unless I am mistaken, the positioning of IMS messaging with the pre-IMS mobile IM standard called OMA IMPS (formerly Wireless Village) is currently being addressed by this latter finally not taking off.

IMS Presence might also be very interesting, but presence is an enabler more than a service, and interesting applications of this enabler have not spread too much in the public sphere. A related issue associated to presence is that few know what the real potential of this enabler is, as many still associate it only to Instant Messaging or the basic indication of the ability/willingness of a user to communicate.

One of the latest trends for mobile operators is to link IMS to...VoIP, but not through cellular access. Voice over IMS is possible for dual mode mobile handsets making use of WiFi. IMS may therefore be used to provide VoIP services on WLANs, more especially for enterprises or for residential customers at home or in hotspots. In this area, IMS can be seen as the long-term solution while UMA is more a tactical alternative.

There is no question that IMS is part of the normal mobile evolution roadmap for mobile operators. However, their main problem is to decide when it makes sense to start deploying IMS, and with which services they should start. This is a reason why most mobile operators are still in an exploration phase.

Christophe