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

What is an IMS Service?

Considering the current fuzziness around IMS, it is a remarkable fact that there is not even a common understanding of what an IMS service is. For anybody who can't provide such a definition or is giving a wrong one, promoting IMS as the next big thing or dismissing it as the next big telco failure are equally blind statements.

In this post I will try to clarify this issue and provide my own definition.

In the following, I will often distinguish between SIP, the Internet protocol, and IMS, a specific architecture making use of SIP.

Often Heard

For many, an IMS service is a service that is developed specifically for IMS, and which uses SIP as its main, if not unique control protocol. Push to Talk over Cellular (PoC) or VoIP based on SIP and IMS are typical such services.

Another common statement is that IMS will not be used to develop new services, but to re-implement existing services with a new architecture and a new control protocol.

From these statements can be derived many interesting questions, including the following.

Aren't web services a better approach and isn't SOA a more adequate architecture to deliver services?

Isn't Jabber/XMPP a better protocol than SIP to support Instant Messaging?

Isn't the fate of SIP (and IMS) already sealed, considering that many of the most important companies delivering communication services to very large communities over the Internet have decided to go for alternative (standard or proprietary) protocols?

Is there any viable future for a network and a protocol that are inherently incapable to foster service innovation?

I will come back on these questions in the following, either directly or indirectly.

There will be be a huge (global) IMS and (global) SIP community, covering both telco networks and the Internet

First, while this is true that major communication applications running on the Internet do not all make use of SIP, it should be acknowledged that this is not the rule. The popular communication application provided by the company founded by the wealthiest man on earth is based on SIP, even if some "optimizations" brought to the protocol do not make it directly interoperable with other SIP-based clients. Th Gizmo project pushes forward the fact that SIP is a standard, and therefore permits interoperability. A famous Internet company uses both Jabber/XMPP and SIP for its communication services.

IMS is an architecture and a standard supported by standardization forums like 3GPP, 3GPP2, ETSI TISPAN, CableLabs, and the WiMax Forum. As a consequence, every operator in the world supporting a single or a combination of access technologies (ex. fixed broadband, cable, licensed or unlicensed radio access) should to at least consider IMS as a candidate in its roadmap. It is very likely that a significant number of operators will opt for IMS, thus creating a huge community of SIP and IMS users across the world.

The intrinsic capabilities of SIP as a control protocol (see Index for several posts on this subject), and the integration of SIP servlets support in all J2EE platforms, even in the versions that are not aimed at the telecommunications market, make that it is possible to eventually see SIP used in other domains that those which directly relate to telecommunications, and for applications which do not focus on person-to-person communication.

All in all, there is a high probability that the SIP community eventually exceeds in dramatic proportions all communities relying on other protocols for communication.

Note that as long as interoperability is ensured, there is no need for all parties in this community to rely on the same architecture or on the exact same SIP profile.

A very valid question is whether a non-IMS SIP community can supersede and eventually kill an IMS SIP community. The temptation of certain telecommunications actors to artificially create an IMS SIP walled garden by adding barriers in IMS standards between IMS SIP and non-IMS SIP clients and applications is an implicit invitation to a war, which may eventually damage the whole SIP ecosystem (however, it is important to note that many telco actors do not want such a fight and may find ways to eliminate these barriers - this may be stating the obvious, but the telco domain is not only standard-driven: business concerns are more fundamental). Otherwise, I guess that this is essentially a question of service offering and business model. If a user can benefit from similar or better services from an alternative service provider, and for a lower cost, it may be tempted to bypass the IMS-based offer.

SIP does not have to be the only communication protocol to be successful

Once again I am stating the obvious, but there is such a thing as protocol gateways, enabling interoperability between communication and control protocols, even if this conversion has to be adapted to semantical differences between protocols and may only address the common functionality between them. In the case where the protocols that need to interoperate are both standard, the conversion may itself be standard, as this is the case between SIP and XMPP (last time I checked the standardization of this particular gateway was work in progress).

An existing service can become an IMS one through integration

The thought that a service has to be specifically implemented in order to run on IMS and to be SIP-centric is wrong.

Access to a service can be preceded by a SIP interaction. The binding between SIP and the service specific protocol(s) usage can be supported by such SIP mechanisms as content indirection or the use of the SIP method REFER. I wrote a post on this subject, giving examples of this type of integration and describing some of the advantages associated to it.

Another way to integrate a non-IMS service with IMS is to encapsulate the delivery of the service within a SIP session: SIP is used to manage a session between the IMS client and the server supporting the non-IMS service (or an IMS application server acting on its behalf), while the service specific protocol(s) is (are) used to deliver the service within the session. I also described this approach here.

Integrating a service with IMS does not necessarily require that the existing implementation of the service be modified to incorporate components addressing the SIP specific logic. This SIP logic can be isolated and deployed on a SIP application server that is remote from the server supporting the legacy non-IMS logic, keeping the overall integration process simple from a service delivery perspective.

Yet another integration approach can be limited to IMS being used for service discovery, subscription and configuration, while service delivery is integrally supported outside of the IMS domain. I wrote a specific post on this subject.

This integration subject is a central topic of the article I wrote for the IEEE Vehicular Technology Magazine.

This means that a lot of future IMS services might already be out there. As an example, an existing Video on Demand (VoD) service might be integrated with IMS using the service discovery, subscription and configuration approach, and/or service delivery through content indirection, REFER, or within a SIP session. The service-specific protocol is RTSP and the binding between the service and IMS for content indirection or REFER is supported through the usage of the RTSP URI within SIP methods.

IMS can be used to combine multiple services

A non-IMS service delivered within a SIP session can be combined with other non-IMS services delivered within the same session, either simultaneously or sequentially. In order to optimize this combination from a user perspective, the IMS-based SIP logic might insert an intermediary on the media plane in order to mix/combine the different services at the media level. For instance, the media intermediary might mix the soundtrack of the video with another audio source, or insert textual messages in the video. See this post for an example.

Through an adequate conferencing support, the service can be shared between several users, and combined with person-to person communication components. For instance, the video of a VoD service can be viewed by different users in remote locations, who can exchange their comments through a messaging, a video or a voice communication component.

If there is the need to find a single reason to integrate a non-IMS service with IMS, then the possibility to combine it with person-to-person communication is this one, considering that communication is the core business of telecom operators. However, I hope I have illustrated in past posts that there could be other important motivations for such a combination.

Existing services can be enriched through SIP and IMS

IMS can support a large number of enablers implemented through application residing in SIP application servers or directly supported by terminals or endpoint servers connected to the IMS.

This permits existing services to be enriched with logic making use of IMS-based application like presence (providing information about the user, its communication means, its terminals, its applications) and group management (defining a standard way to access and manage groups of users, to which the service can be delivered simultaneously or which define who is authorized to access the service).

Enablers supported directly by terminals may enable real time communication between the service and the user, provide real time and accurate information about the user, its terminal(s) and its applications, or use SIP as a transport protocol to exchange service control semantic with a remote application server. SIP event packages may typically be used for this. For instance, existing event packages may permit the service to know if a user is currently involved in a SIP session or typing on its keyboard. New event packages can be defined permitting the service to access information or being notified about events related to the user, a terminal, or a specific application. A straightforward example is one where the service would retrieve the location of a GPS-enabled terminal.

Enrichment of an existing service through the usage of IMS-supported enabler(s) requires a modification of the existing service logic to make use of these enablers, even if the SIP/IMS specific part of it can be encapsulated through the usage of appropriate APIs.

Services can be delivered through complementary usage of SIP and other protocols and architectures

It would be a fundamental misunderstanding to believe that an IMS service has to uniquely or even essentially use SIP to be delivered.

The IETF applies a building block approach to specification, with a continuous concern to make every concept as generic as possible, and to always look at what has already been specified, even in adjacent application areas, prior to reinventing the wheel. SIP is a remarkable example of this, and as a result. The IETF community systematically tries to ensure that every SIP extension avoids to betray the spirit that governed the initial creation of the protocol, that every extension is made generic enough to be used beyond its initial purpose, and that mechanisms exist to combine SIP with other protocols that are optimized for fulfilling specific needs. SIP sessions, content indirection and SIP REFER are examples of mechanisms created to enable such a combination see here or in the Index). The building block approach to SIP specification is an interesting topic in itself, that I will address in the next post.

Another fundamental misunderstanding would be to believe that the IMS service architecture is incompatible with other service architectures and their associated protocols. It was specified from a SIP-centric perspective, focusing on the relationship between the IMS application layer and the IMS core network. However, 3GPP did not want to address the details of how the the IMS application layer would be implemented, leaving room for integration with other appropriate architectures and protocols.

As an example, SOA (Service oriented Architecture) and web services are not alternatives to IMS and its service architecture, but powerful complements to them and the usage of SIP as a service control protocol. I already wrote several times on this particular topic (just look at the IMS Lantern Index).

An important question is how the integration of IMS and SOA should be performed. At the moment, the prevailing understanding is that it should take place uniquely through the definition of web services, permitting to integrate a SIP-centric IMS with a web services and SOA -centric application layer. I believe that this view is incomplete and that the optimal integration between IMS and SOA should be more intimate, considering that IMS service logic should combine the direct usage of SIP and web services for service delivery, instead of only developing SIP-centric logic and web services -centric logic connected through a loose web services adaptation layer, similar to the one that connects the pre-IMS networks with SOA. I gave a name to this more intimate integration architecture, which extends both OSA and the standardized IMS service architecture: the User Oriented Architecture (UOA).

This distinction between a future service architecture integrating IMS and SOA solely through a web services adaptation layer (which makes that IMS is simply integrated in a SOA-centric service architecture) or through both a web services layer and direct usage of SIP by applications, might look artificial, but it provides alternatives considerations to the following issues:

- How to share a service context between IMS-centric logic and web services -centric logic? In the SOA-centric architecture, contextual information needs to be exchanged through web services defined between the IMS domain and the SOA domain, and may be limited to what is feasible or what has been done there. In a UOA architecture, this context can be naturally internal to the logic making use of both SIP and web services.

- Which IMS service enablers are provided to services in the application layer? In a SOA-centric application layer, this set of services enablers is limited to the set of web services exposing IMS capabilities to applications, while in a UOA architecture it can be extended to whathever the SIP protocol permits at any time. In a SOA-centric architecture, if no web service has been defined to expose a particular capability to applications, then no application will try to use this capability and the potential for innovative services will be limited. Typically, web services defined by people and organizations viewing IMS as a network and a set of standardized enablers like presence and group management are likely to miss most of the capabilities that are terminal and endpoint -related, as terminals and IMS endpoints tend to be considered more as consumers of network-based services than intrinsic parts of the service architecture. Will the set of web services exposing IMS capabilities to applications ever permit applications to access information generated by another application residing in an IMS terminal, like a game, if the service architecture assumes that IMS capabilities are only those that are accessible through web services defined by network people?

- How can IMS service enablers be used by applications? The synchronous nature of web service is likely to limit these enablers to those that can easily be rendered in a synchronous manner. In some cases, mapping the asynchronous capabilities of SIP to a synchronous interface might limit the usability of these capabilities or make them complex and unattractive to use. Directly using an asynchronous protocol like SIP to access asynchronous capabilities is likely to be simpler.

- Can all services be efficiently delivered to users? A complex architecture clearly discriminating between IMS/SIP -centric entities on the one hand, SOA/web services on the other hand, and forcing a web services -centric mapping between the two is likely to induce delays in the end-to-end delivery of services, as service delivery needs to cross several technical domains, while these delays could be largely reduced in a more integrated architecture.

- What is the cost for IMS services? The previous point hints at a more complex architecture induced by the definition of IMS and SOA -centric servers, and a gateway functionality between them. To this you can add the systematic duplication between web services and SIP interfaces induced by the SOA-centric architecture.

- How fast can new services be created and deployed? If you need to specify and implement a web service for each and every IMS capability, service creation is likely to be slower than if direct usage of SIP by applications is possible.

In addition to combining SIP with other IP and Internet service control and delivery protocols, like HTTP or RTSP, and integrating SOA and IMS, web services and SIP in a new service architecture called UOA, another important aspect that is not described in IMS specifications is to permit IMS applications to access capabilities available in pre-IMS telco networks, like user location (access to location servers), user registration status in the circuit-switched network, call control in the circuit-switched network, SMS, MMS or email as messaging enablers. Some of these enablers that are IP-based can be used in a straightforward manner. Others may require gateways between the IP and circuit-switched worlds, which may be based, on the usage of OSA/Parlay gateways but also on more specific protocol converters.

Therefore, the IMS service architecture can go well beyond the support of SIP and access to access to IMS-based enablers. Here is an overview of this scope.

Conclusions

An IMS service is a service that makes use of SIP and the IMS either centrally or marginally.

SIP itself and even more the combination of SIP with other protocols can give birth to a flurry of new services, some of them implemented on IMS.

The ability of SIP to combine various existing services of different types (communication, data, content, applications) can give birth to a new user experience, which is by itself a new service. This is an important matter to consider when comparing SIP with more purpose-centric protocols.

These new services can reach a huge community covering all the continents, all types of access technologies and spreading between telco domains, other business domains, and the Internet, possibly redefining the definitions of these domains.

IMS and SOA are not alternative architectures to deliver new services. They should rather be seen as building blocks permitting to create a new and more powerful service architecture called UOA.

This draws a potential future world, in which there might be a little bit of SIP everywhere, and consequently a a good potential for IMS to fit as a particular SIP service architecture deployed by telco operators.

However, history shows that the best technologies do not always prevail. In a possible future, the potential of SIP as a service control protocol used in different architectures including IMS, and/or IMS as a service architecture augmenting the intrinsic capabilities of SIP, might eventually fail. Conversely, would SIP and/or IMS be only used at a fraction of their potential (e.g. for VoIP and a limited set of additional services), they could still be a success.

Christophe

A Contribution from the Fraunhofer Institute FOKUS

Here is a first external contribution coming from the renowned Fraunhofer Institute FOKUS in Berlin. You will also find the main links featured in this post on the right side of the main page.

Here are excerpts from the email I received from Peter Weik:

My name is Peter Weik and I am working with the Fraunhofer Institute FOKUS in Berlin, Germany, an independent R&D organization for applied research in the telecommunications space. We have here been developing with own IMS prototypes and commercial IMS components now for several years in the context of the FOKUS Open IMS Playground (www.open-ims.org) in a true multi-vendor environment (www.open-ims.org/partner) for showing not only IMS interoperability (long before the first IMS interop events popped up) but also concepts around it (like e.g. application development or benchmarking of IMS components).

As you were asking in the latest post for links on what could be done, that exploit what IMS and SIP can offer to deliver innovative services I had to take on that opportunity as one of the lead developers of an open source project ;)

Well, you could spread the word even more via a blogpost that there is a free open source solution out there that has already enabled many IMS testbeds and developers: the Open IMS Core (www.openimscore.org).

The Open IMS Core is an implementation of IMS Call Session Control Functions (CSCFs) and a lightweight Home Subscriber Server (HSS), which together form the core elements of all IMS/NGN architectures as specified today within 3GPP, 3GPP2, ETSI TISPAN and the PacketCable initiative. The four components are all based upon open source software(e.g. the SIP Express Router (SER) or MySQL) and are available under the GPLv2. (You may know the project since it is also in the The March 2007 special issue of the IEEE Vehicular Technology Magazine on IMS, just three articles further onwards.) The whole idea behind the project is to enable IMS developments and to help an industry to adopt IMS concepts - all of it without huge investments necessary.

Besides sparking the development of two also freely available IMS clients (the IMS Communicator and the UCT IMS Client), it has also enabled some industry players, universities and R&D departments (see www.openimscore.org/quotes) and is used in current IMS interop events (e.g. at University of New Hampshire, http://www.iol.unh.edu/services/testing/voip/equipment.php#IMS).

But of course we are also looking at own application prototype developments as part of our recently started Open SOA Telco Playgroundxggveqt (www.opensoaplayground.org). What is possible with IMS was shown at our last IMS workshop in November 2007 with the IMS Community Mashup with Facebook (http://youtube.com/watch?v=b1OwDD6cyBY).

Christophe

Call For Contributions

I started the IMS Lantern 9 months ago, and since then published about 50 posts, which essentially try to explain and demonstrate how IMS can support innovative services and provide an innovative approach to access existing services.

The IMS Lantern is being read by people representing the whole array of organizations and companies involved in the telecommunications, including traditional operators, innovative service providers, state agencies, all the traditional equipment suppliers, many application service providers, IT companies, universities and research centers, consulting companies, and individuals having an interest in new technologies.

These organizations, companies and individuals have ideas, develop prototypes, demos or products making use of IMS and its capabilities.

What I would like to do is spreading information about what is being done or what could be done, that exploit what IMS and SIP can offer to deliver innovative services.

If you have something like this (an idea, a white paper, a demo, a product, a patent application), please contact me. I will post whatever information can be provided to me, with links to external documentation and web pages.

Christophe

An Index for The IMS Lantern

Here follows an index by themes of the posts on this blog. I will update it as new posts are published.

In bold are the posts that are important to me.

The Potential of IMS

Three Axes for IMS: #1 Fixed Mobile Convergence

Three Axes for IMS: #2 Multimedia Communication

Three Axes for IMS: #3 User Oriented Architecture

Does IMS Create a New Walled Garden?

IMS Service Features

IMS Service Logic Distribution

Conservative & Progressive Application Layers

Co-existence of Conservative & Progressive Application Layers

What is an IMS Service?

3GPP Multimedia Telephony & OMA CPM

Service Anthropomorphism




Fixed Mobile Convergence

Three Axes for IMS: #1 Fixed Mobile Convergence

IMS Public User Identities (IMPUs)

3GPP Multimedia Telephony & OMA CPM



Multimedia Communication

Three Axes for IMS: #2 Multimedia Communication

Status of Multimedia Communication

Enabling Multimedia Communication

Use Case: Multimedia Service Delivery

Conservative & Progressive Application Layers

3GPP Multimedia Telephony & OMA CPM



User Oriented Architecture (UOA) and Service Oriented Architecture (SOA)

SOA & IMS: Same Fight?

Three Axes for IMS: #3 User Oriented Architecture

Service Pattern: Automatic Service Discovery & Configuration

The Beatles & The Stones

An IMS Application Server in Context

A Contribution from the Fraunhofer Institute FOKUS

What is an IMS Service?

Service Anthropomorphism


The IMS Service Architecture

Beware of IMS Service Architecture Prejudices!

An IMS Application Server in Context

Conflicting Views on the IMS Service Architecture

IMS Service Routing: Big Picture

IMS Service Logic Distribution

IMS Service Features

Conservative & Progressive Application Layers

Co-existence of Conservative & Progressive Application Layers

IMS Service Interaction Use Cases: Part 1

IMS Service Interaction Use Cases: Part 2

IMS Service Interaction Use Cases: Part 3

What is an IMS Service?

3GPP Communication Services


The SCIM

Standardization: SCIM & Service Broker

Review of Typical SCIM Features

Here is my SCIM

More on the SCIM!



SIP

SIP Everywhere but NOT for Everything

Service Pattern: IMS Content Indirection

Use Case: Multimedia Service Delivery

Does IMS Create a New Walled Garden?

Moving the Frontier between IT and Telco (part 2)

What is an IMS Service?

A Building Block Approach to Standardization

An Article from Microsoft

3GPP Communication Services


IMS as Integration Framework

Service Pattern: Automatic Service Discovery & Configuration

Service Pattern: IMS Content Indirection

Use Case: Multimedia Service Delivery

What is an IMS Service?

A Building Block Approach to Standardization


IMS and the Internet

Does IMS Create a New Walled Garden?

IMS Service Interaction Use Cases: Part 1

Use Case: Multimedia Service Delivery

Conflicting Views on the IMS Service Architecture

An IMS Application Server in Context

IMS Communication Services: Uncut Version

A Building Block Approach to Standardization

Different Strategies for IMS

3GPP Communication Services


IMS Service Examples and Service Patterns

Service Pattern: Automatic Service Discovery & Configuration

Service Pattern: IMS Content Indirection

Public Service Identity Service Patterns

Use Case: Multimedia Service Delivery

IMS Communication Services: Uncut Version

IMS Service Interaction Use Cases: Part 1

IMS Service Interaction Use Cases: Part 2

IMS Service Interaction Use Cases: Part 3

What is an IMS Service?

Service Anthropomorphism


IMS Application Servers & Service Platforms

An IMS Application Server in Context

Moving the Frontier between IT and Telco (part 2)

IMS Service Routing: ISC for IMS Application Servers

Different Strategies for IMS



User Data

User Application Data: a Panorama

User Application Data: Opinions

A Building Block Approach to Standardization



Perception Issues with IMS

Why dedicating a blog to IMS?

A Classification of IMS Critics, Part 1

A Classification of IMS Critics, Part 2

IMS: Core Network or Service Framework?

Does IMS Create a New Walled Garden?

SOA & IMS: Same Fight?

Conflicting Views on the IMS Service Architecture

Danger! IMS Communication Services

IMS Communication Services: Uncut Version

IMS Communication Services: Latest News

The Beatles & The Stones

Conservative & Progressive Application Layers

What is an IMS Service?

3GPP Multimedia Telephony & OMA CPM

Different Strategies for IMS

3GPP Communication Services


Details on IMS Specifications

Finding Your Way on the 3GPP Web Site

IMS Public User Identities (IMPUs)

IMS Public Service Identities (PSIs)

IMS Service Routing: Big Picture

IMS Service Routing: Service Profile

IMS Service Routing: ISC for S-CSCF

IMS Service Routing: ISC for IMS Application Servers

Standardization: SCIM & Service Broker

User Application Data: a Panorama

Danger! IMS Communication Services

IMS Communication Services: Uncut Version

IMS Communication Services: Latest News

3GPP Multimedia Telephony & OMA CPM

IMS Standardization Tracking Report

3GPP Communication Services



General Views on the Industry

IMS for Mobile Operators

IMS for Fixed Operators

IMS for Operators with Mobile & Fixed Units

Moving the Frontier between IT and Telco (part 1)

Moving the Frontier between IT and Telco (part 2)

SOA & IMS: Same Fight?

A Building Block Approach to Standardization

Different Strategies for IMS

Defining an IMS Strategy

A List of IMS Deployments (regular updates to be expected)


External Contributions to the IMS Lantern

Call For Contributions

A Contribution from the Fraunhofer Institute FOKUS

An Article from Microsoft

IMS Standardization Tracking Report

Use Case: Multimedia Service Delivery

One of the three axes that would permit IMS to revolutionize the telecom world, together with user oriented convergence and the definition of a new service architecture combining the power of SOA with a new User Oriented service Architecture (UOA), would be the full exploitation of the multimedia capabilities supported by the SIP protocol.

This post presents an example which makes use of these multimedia capabilities.

IMS Service Features Illustrated with the Example

The example I present today shows, among other things...

How IMS can be used by an operator to deliver a multimedia service which includes content and application components, but not a single person-to-person communication one.

How IMS can be used to share a multimedia content and application experience between several users (not shown on the figure).

How IMS can be used to mix person-to-person communication with content and application sharing.

How non IMS and even non SIP-aware services can be integrated with IMS (i.e. a service delivered over IMS does not have to be specifically developed for it and does not necessarily require SIP-related application components).

How IMS can be used for an operator to offer to its subscribers services actually delivered by 3rd party service providers located in other domains, possibly including the Internet, without requiring a prohibitively strong technical coupling with them.

How IMS can permit an operator to add-value to multimedia content delivered to its subscribers by third party service providers.

That IMS Services might be highly distributed, with application logic running in devices and in a variety of application and content servers. The SIP logic itself might be confined to only a subset of these service entities.

Why the existing conferencing solutions available on the market are too limited, and why a more generic multimedia conferencing architecture is needed.

Description of the Service

In order to experience the multimedia service, the user starts a session addressed to a Public Service Identity (PSI) identifying the service. The PSI may be specific to the user and routed to the SIP AS according to the user's service profile (originating trigger). Alternatively, the PSI may be a shared, public one. In this case, the routing to the SIP AS may also be based on the user's service profile (i.e. users need to be authorized to access the service so that their service profile allows routing to the SIP AS), unless it is based on the normal resolution of the PSI to the SIP AS (i.e. all users can access the SIP AS when they issue a request addressed to it). I already described these routing alternatives here and also with another service use case.

The user negotiates (and possibly re-negotiates during the session) the content of the service through any appropriate interface. For instance by accessing a web page supported by the SIP AS. Alternatively, this could be through a client downloaded on the terminal and communicating with the SIP AS via an application to application interface, like the exchange of XML documents describing the desired content of the multimedia session.

The SIP AS then performs the required actions to deliver the content (e.g. files, streaming media, web pages, applications) within the session. Depending on the type of content, the desired control of the operator over the delivery, and the technical means available for each component, the SIP AS uses the appropriate mechanism for each of the components (which do not have to be co-located with the service control logic hosted by the SIP AS). This may include some of the following:

- Establishing a SIP session with the component endpoint and bridging this new session with the user to SIP AS one (typical B2BUA behavior).

- Controlling the delivery of the component via an appropriate non-SIP interface (e.g. web services, H.248) towards the component source and negotiating/re-negotiating the SIP session accordingly towards the user.

- Providing the user's terminal and/or the component source with appropriate information to establish an end-to-end connection. In an example, the SIP AS would provide within the session a URI (e.g. HTTP URI, FTP URI, RTSP URI) via SIP content indirection or a referral, permitting the user's terminal to directly connect with the component source. In another instance that I used when I was the architect of an IMS demo for an equipment supplier, the SIP AS retrieves from the source the information required to connect to a whiteboard server, and transmits it to the user's terminal, so that a whiteboard client connects to the server and interfaces with it through the relevant whiteboard protocol. In yet another instance, the SIP AS provides the component source with the information relevant to push the content to the user's terminal. In any of these instances, the SIP AS may keep a control interface towards the component source in order to terminate the delivery of the component when the service session is completed (the idea is to ensure that the component is not delivered anymore after the service session is ended).

During session establishment or session renegotiation for a specific component, the SIP AS may decide to insert a number of media-level intermediaries (typically media servers) between the user's terminal and the component source(s). In such a case there is no peer to peer connection between the user's terminal and the component source, as both connect to the intermediary which is under the control of the SIP AS. The potential control interface between the SIP AS and the intermediary in the network might be an alternative way for the SIP AS to synchronize the delivery of the service component with the service session (start/stop delivery). However, the usage of a media intermediary may serve other more added-value objectives, like combining/mixing different components together (e.g. inserting text information in a video stream), caching media for better delivery quality, transcoding media to fit the capabilities of the user's terminal, or inserting localized advertizement in the media stream (possibly to decrease the service fee to be paid by the user).

It should be noted that the component sources may be provided by the operator or by 3rd party service providers located in other domains, and possibly in the Internet. In this case, the operator acts as a service broker, adding value to individual components by integrating them in a single multimedia session, acting on the media plane, and providing the level of access (no need for the user to authenticate to each individual service component provider), the QoS and the security that can be expected by the user from its telecommunications operator.

The service session, which takes place between the user's terminal and the SIP AS (usage of SIP for the service may be confined to these two entities), may terminate when either the user or the SIP AS decides that it is time to. As for individual components in the session, their delivery may be terminated through either the user's terminal, the component source, or the SIP AS if it has the control means to do it.

Some of the Benefits of Using IMS to Deliver the Service

As I already described in an earlier post, using SIP has a prerequisite to access a service has numerous advantages for both the operator and the user, and using a SIP session to deliver the service even adds on top of this:

- The SIP signalling generated by the user's terminal and reaching the SIP AS transports meaningful service information, such as the authenticated identity of the user, information relevant to charging like the address of the charging nodes and correlation identifiers which will permit the billing system to correlate charging information generated at the media plane level (e.g. type and volume of media), at the IMS core network level (duration of the session), and at the SIP AS level (any additional application-level event), information about the location of the terminal (e.g. cell ID), and information about the access technology used by the terminal, which can be exploited by the SIP AS to optimize the delivery of the components.

- Routing of the SIP signalling between the user's terminal and the SIP AS may be directly linked to the authorization of the user to access the service (see above).

- The establishment and re-negotiation of the session permits the user's terminal and the SIP AS to re-use core network support to set the relevant QoS and security associations just like for a person-to-person voice or multimedia session.

- The SIP session determines a well defined context for the delivery of the service, with a clear begining and end.

- The session permits the coherent combination and aggregation of individual components within a multimedia service.

- The session offers the possibility for the operator to insert media-level intermediaries for both control and added-value purposes. This example thus illustrates how an operator can both use multimedia sessions to deliver its own services, and add value to peer-to-peer multimedia exchanges.

Some Possible Extensions to the Use Case

Though not supported by the standards today, the service could be extended with session continuity, permitting the terminal to switch from one access to another (e.g. WiFi to UMTS) without stopping the service session and the delivery of its components.

Currently under work in the IETF, session mobility would permit the user to transfer the ongoing session from a terminal to another (e.g. mobile phone to TV set) without stopping it. Such a transfer could be necessary from a convenience perspective (e.g. the user started the service on the run and is now at home, benefiting from terminal alternatives), or depending on the renegotiation of the service session (e.g. the user would like to add a component like an application, which is not available on the terminal he or she is using). It would also be possible for the user to receive the content or run applications on several terminals, each optimized for a subset of the components or applications.

While the example concentrated on the delivery of a mutimedia service to a single user, it would be possible to share the experience between multiple ones. This could be done by providing a conferencing entity to the architecture. As this conferencing support would not be limited to person-to-person communication (e.g. voice, messaging), this would require a more generic conferencing architecture than those proposed today by suppliers. I tried to describe a potential architecture in a past post. Sharing the same experience could imply the synchronization of applications on each of the users' terminals, permitting for instance shared browsing, a shared whiteboard, or multi-player gaming.

As soon as multiple users are involved in the service session, person-to-person communication would be an appreciated plus and would be enabled by the conferencing support permitting to add bi-directional communication components between the participants. Such a possibility would make the use case come back to the core concern of the operator: delivering person-to-person telecommunication.

A service supporting both the delivery of content/application and person-to-person communication may experience different modes. In addition to this example in which a service session is extended to communication, an alternative use case would see a communication session between two or more users extended to shared multimedia service delivery.

Everything is Possible, Nothing is Given

Obviously, such a service would require an adequate support in terminals (application architecture, application components and an intuitive user interface), a relevant architecture in the IMS application layer, the right agreements and technical settings between the operator, its SIP AS, and the 3rd parties and their servers, and an attractive business model for all the parties (the operator would need to find the right charging policy for its subscribers).

It would require that ongoing standardization efforts in 3GPP do not prevent, through artificial barriers, the delivery of such a service or similarly out-of-the-mainstream others. I will come back on this topic in a future post.

Christophe

Conflicting Views on the IMS Service Architecture

The two figures above both depict the IMS Service Architecture.

The first one is taken from the 3GPP specifications and is therefore the primary basis for anyone to understand the IMS Service Architecture.

The second one is my own representation of the IMS service architecture, based on the exact same specifications, and is therefore only accessible by the readers of this blog. As I have not seen so far a similar representation anywhere else, you can assume that this is not at the moment the mainstream perception of the IMS service architecture in the telco community.

IMS as a New Intelligent Network (IN)

The 3GPP representation of the IMS service architecture is network centric. It represents the IMS application layer solely according to its interface to the IMS core network, placed at the center of the figure with the S-CSCF.

This representation is potentially misleading as technicians with a classical telecom background can perceive the IMS service architecture as an IP replica of the Intelligent Networks that can be found in all existing fixed and mobile circuit-switched networks. Actually, I have seen this view supported numerous times, both by these people who know everything about telecommunications and by alleged IMS experts.

This IN perception of the IMS service architecture is re-inforced by the fact that two of the IMS application server types represented in the figure are tightly linked to IN: the IM SSF is a gateway between IMS and an IN application server, and the OSA gateway is usually (and rightly) perceived as being essentially an API on top of IN. Adding to the confusion, the terminology used for the IMS service architecture (e.g. trigger points) heavily borrows from IN (to be frank, some companies participating to IMS standardization did see this architecture as an IN one).

In an IN network, the (fixed or mobile) switch interfaces with the application server through a dedicated control interface (e.g. INAP, CAP, an IS.41 subset), which permits the application server to control the switch by issuing instructions to it. These instructions essentially serve the purpose to control voice calls, as the circuit-switched network is voice centric.

In such an architecture, the basic voice services are supported by the core network, which is complemented by application servers for the delivery of "supplementary" or "value-added" services.

With this kind of background, it is easy to perceive ISC as the IMS equivalent to INAP/CAP and the IMS application servers as an extension to the core network. Some might even argue that the IMS application layer is not needed, if you can implement all the required supplementary services within the S-CSCF.

IMS as a Totally New Service Architecture

However, the IN-oriented interpretation of the IMS service architecture does not resist a thorough analysis of the specifications that I tried to describe in past posts (here, there, there and there).

First, with the exception of the user registration part of the ISC reference point (which permits the S-CSCF to notify application servers about registration events, but does not permit the AS to block registrations), ISC cannot be seen as a logical interface between the S-CSCF and the application server.

On the contrary, ISC is only one branch in an end-to-end SIP interaction between the application server and other application-related entities. In such an interaction, the S-CSCF and the whole IMS core network only act as intermediaries and service-related routing functions between application-related entities. This is why I tend to represent the whole IMS core network as a SIP-oriented service bus supporting the IMS application layer (I will come back on this in a future post). This bus is essential for the IMS application layer, but its significance is close to zero from a service perspective. Suffice to say that it duly supports its service bus role, and that the best additional value it can offer to applications is to be totally transparent to them.

The second essential characteristic of IMS that dismisses the claims of an IN replica is that SIP is not the equivalent of SS7 over IP:
- SIP sessions are not voice calls. They are much more generic service sessions, which may even not include any voice or person-to-person communication component.
- SIP is not only about SIP sessions. Other SIP methods make SIP a very generic service control protocol.

With such a knowledge in mind, it is irrelevant to represent the IMS service architecture without representing what is on the other side of ISC (and other SIP-relate reference points supported in the IMS core network). My figure tries to represent all the possibilities.

However, this figure is still incomplete, as it focuses on the SIP dimension of the IMS service architecture. For a more complete view, look at this previous post.

The End-To-End IMS Service Architecture (SIP Dimension)

Many possibilities exist, that I already described in the past (here, there and there), but I will summarize below (note that the examples are very basic).

An IMS endpoint (terminal, endpoint application server) in the operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.

An IMS endpoint (terminal, endpoint application server) in another operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.

An endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. enterprise network, the Internet) initiates a service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence. Note that the non-IMS endpoint may either use SIP or another protocol to initiate the interaction. In the latter case, a protocol converter (e.g. Jabber to SIP) will translate the initial request into SIP.
Specific case: the non-IMS endpoint is an application server (e.g. Internet application requiring user's presence).

The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in the same operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user.

The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in another operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user of another operator.

The application server initiates a SIP service interaction with an endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. in an enterprise network or in the Internet). ISC is the first branch used in this interaction. Example: application server sends instant message to user in the Internet. Note that the non-IMS endpoint may either accept SIP requests or not. In the latter case, a protocol converter (e.g. SIP to Jabber) will translate the initial request to the required protocol.
Specific case: the non-IMS endpoint is an application server (e.g. presence server).

The application server initiates a SIP service interaction with another IMS application server in the same operator's domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.

The application server initiates a SIP service interaction with another IMS application server in another operator's IMS domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.

An IMS application server acts as an intermediary in any of the interactions listed above, plus the essential case where none of the service interaction endpoint is an IMS application server (e.g. two IMS devices, an IMS device and a non-IMS device, an IMS device and a non-IMS endpoint application server). The idea is for the intermediary AS to either control or add-value to the end-to-end interaction. ISC is a branch somewhere in the middle of the SIP signalling path. Note that several IMS ASs can be inserted as intermediaries in the signalling path, forming a chain of combined services. Examples: IMS AS authorizes and/or charges for access to service, IMS application server inserts media plane intermediary to improve user experience (e.g. media mixing, media transcoding).

User Oriented Service Routing

The SIP dimension of the IMS service architecture relies on two SIP routing mechanims:
1) Standard SIP routing (labelled in the figure as IETF SIP routing) based on the resolution of the target SIP address towards an endpoint.
2) IMS User Oriented and Service Profile based routing (labelled in the figure as user profile based routing), which permits to dynamically alter SIP routing on a user-per-user basis towards IMS application servers. The service profiles stored in the HSS can be seen as service routing routing under the control of the operator and modifiable over time. This permits to incrementally modify SIP routing as applications are added or removed from the network, and this without impacting endpoints.

This draws a service architecture which is very flexible in terms of service logic location (in service entities like application servers in the network, endpoint application servers, devices), very flexible in terms of location of service entities in different domains (the operator's domain, another operator's domain, an enterprise domain, the Internet) and very agile in its possibility to dynamically modify service logic at work in the network.

Christophe