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

Review of Typical SCIM Features

I presented how the SCIM was introduced in IMS specifications. In this post, I will provide my opinion on the relevance of the features usually associated to the SCIM.

Architecture Aspects

Before speaking about the functionality of the SCIM, let's consider architecture aspects.

I assume that the SCIM coordinates the execution of individual services on an application server, and does not only sequence the interactions at the application server level. For this, there are standardized mechanisms already, supported by the S-CSCF.

In order to coordinate service execution, the SCIM needs to individually access each service on an application server.

This implies a detailed knowledge of all the services to be invoked and the relationship between them. This is certainly one of the reasons why 3GPP SA2 is so reluctant to standardize a SCIM. This is a complex task and for the first time 3GPP would need to write specifications that address individual services, while so far they have managed to only address interactions between the network and application servers.

This also implies that the interface between the SCIM and application servers supports the identification of each and every service located on them. A nightmare.

A typical usage of the SCIM would permit it to invoke an individual service on AS1, then another one on AS2, and finally a 3rd one back on AS1. This would lead to a very inefficient service execution in the context of real time communication, more especially as a network protocol has to be used for all interactions between the SCIM and the application servers. A proper architecture may prevent such a bad service distribution to happen.

Consequently, from an architecture perspective, the SCIM should preferably be co-located with the services it coordinates. If not all services can be located on the server, the SCIM may use a protocol towards the remote servers, but only as an extension to its local duties. In TR 23.810, this would correspond to the "hybrid" case (section 5.3), in which one of the service brokers in an AS would also serve as a service broker towards other ASs.

Addressing Various Application Server Technologies

One of the main rationales given for introducing a SCIM, and this is part of TR 23.810, is the need to coordinate service exection between the different types of application servers defined in the IMS service architecture: SIP AS, OSA Gateway, IM SSF (gateway to CAMEL/IN).

A first question is: how relevant would it be for an operator to deploy these 3 technologies to implement IMS services?

The SIP AS is clearly a must. Most if not all IMS application servers that exist today are SIP ASs.

For me, a legacy CAMEL/IN server is usually the type of platform an operator has little control on, and is far from optimal to implement new IMS services. Even when using IMS initially for telephony, an operator should consider re-implementing telephony services on a new platform, in order to both benefit from advanced IT environments and enable services that do not only mimic the behavior of their circuit-switched counterparts, and can use such IMS/SIP capabilities as forking or presence.

There is one case where I find relevant the intention to access legacy IN services: when IMS is used to extend an existing circuit-switched telephony service towards VoIP. Basically, the user keeps its circuit-switched telephony services, but sometimes happens to use VoIMS instead of VoCS. In this case the same services must be shared between the two networks, and one option if for IMS to access the legacy services.

There are very few mass deployment of services based on OSA/Parlay, and the APIs (more especially call control) are not optimal for IMS. I think that only a few operators really think of deploying Parlay services over IMS, and if they do so, they might decide that they will concentrate their call control services on this solution.

A second question is: assuming that an operator deploys application servers of different technologies, will these application servers share the control of the same sessions?

This is a key question, as the SCIM would only need to coordinate the different application servers if they intend to impact the same SIP transaction, dialogue or session.

In the case where I see using CAMEL/IN for legitimate reasons, I wonder why there would need to be additional services implemented on a SIP AS. Conversely, if services are implemented on a SIP AS, why would there be the need to coordinate with services implemented on a CAMEL/IN SCP? Of course everything is possible in theory, but some options make more sense than others.

Personally, I see little need for a SCIM to integrate different AS technologies. In any case, the standardized AS chaining mechanism of the S-CSCF can provide support to this hypothetical need.

Service Interaction Management

Classical service interaction management is a voice and call control centric issue.

While I do not discuss the fact that IMS will deal with session control issues, both for voice and non-voice centric sessions, I have several arguments that may mitigate the need for standardizing an entity to handle service interaction management.

First, IMS is not a circuit-switched network, and there are IMS features which may permit to lower the need for service interaction management:

- IMS can support phone numbers (tel uris), but the most natural addressing for IMS and SIP is the SIP uri, which is like an email address (e.g. sip:user@domain). This means that many number translation services may not have a long term future in IMS.

- IMS is a multimedia network which will multiply the means to communicate between users. This may impact the need for call management services.

- SIP forking permits the network to search for a user on various devices. This will make some of the existing call control less relevant than before.

- Presence will permit more intelligent call management services, and will certainly reduce the number of services and the need for supporting service interaction management between them.

- IMS services can more easily interact with users, possibly asking them (caller, callee) how they wish to handle a call. This is in contrast with circuit-switched networks, which have poor user interfaces and therefore need to essentially work autonomously.

My point is not to say that the service interaction management issue will totally disappear in IMS, but that it is likely to be less critical than before, and may not require a standardized SCIM.

Another aspect is the following: how much money will an operator make with call control related services? I think that IMS has value only if it can support other services than voice or basic session control, and if the operator must invest money, this is for revenue generating services. For me, IMS will be successful if call management represents a tiny portion of the services it offers. In this context, the effort placed on addressing the service interaction management issue for IMS is out of proportion with its business importance.

For me, the focus of a part of the industry on service interaction management for IMS comes from the fact that technicians have been working on this issue for long, and prefer to stick to this comfortable topic than invest time and effort to address new problems.

And by the way, why would telecom experts now resolve for IMS the service interaction management issue that eluded them for so many years in the circuit-switched network?

Support of Multimedia Services

Some think that a SCIM is needed to support multimedia communication. By adding a SCIM to a push to talk server and an IMS messaging server, you would support sessions that mix both push to talk and messaging media.

Unfortunately it does not work this way. In order to support multimedia communication you need to have the right architecture in the application layer, and legacy monolithic servers need to be re-engineered for this. There is no magic box to change the situation.

Service Orchestration

The SCIM would be used for service orchestration, i.e. for composing different services together.
This is how I see it, but in order to comply a minimum with the entity introduced in IMS specifications, this orchestration must have something to do with the SIP protocol. Service orchestration related to web services, implemented via BPEL or something else, should not be mixed up with what can be done at the SIP level.

In a future post, I will present my view of a SCIM that can add value to IMS.

Christophe

Three Axes for IMS: #2 Multimedia Communication

As I wrote in the previous entry, I see three main axes around which the potential of IMS can be exploited.

After, fixed mobile convergence, the second one is Multimedia Communication.

Once again, the term is ambiguous, and I am not sure what was really meant when the name "IP Multimedia Subsystem" was initially cornered.

For some people with a classical telco culture, "multimedia" means more or less "voice and video telephony".

You already get closer to the truth if you consider that IMS is "multimedia" because it can support a variety of communication means, including, voice, video, messaging, and various enrichments of them.

My definition goes further and is directly derived from the SIP protocol and its session control capabilities.

Since its "capture" by the enterprise and telco domains, SIP has been wrongly labelled as a "VoIP" protocol. From the begining, the concept of SIP session was defined as a very generic rendez-vous mechanism. A SIP session can include any type of media and/or any type of application. You can set up a SIP session to play a game, watch a video, share a browsing experience with your friends, chat with them, or perform all of this in sequence or in parallel.

A SIP session therefore permits to share a service context between a user and an application, or between two or more users. Each service within the SIP session can use its own protocol(s), and SIP is just setting the framework for these protocols to be used between various endpoints until one of them decides to call it quits.

A SIP session can be re-negotiated at any time, as some media components can be added, removed or replaced at any time.

Here is a potential multimedia communication scenario: Mary receives a call set up request from Paul for a voice session. As she is currently sitting in a train, she answers that she prefers a chat session, which is then established. When leaving the train, she upgrades the session to voice so that she can speak while walking back home. Arrived at home, she transfers the ongoing session to her PC, and enriches it with a peer-to-peer game. After some time Paul decides to drop the voice component as he is losing and blames Mary's taunting comments for this. At the end of the game, they decide to share their web browsing and re-establish a voice component in order to jointly select on the web a restaurant for dinner.

Multimedia communication according to SIP is likely to revolutionize the way people communicate...unless SIP multimedia capabilities are never used to their full extent.

It is a fact that early IMS implementations totally ignore the multimedia capabilities of SIP. Whether the service is Push To Talk Over Cellular (kind of walkie-talkie for cellular handsets), VoIP, or Instant Messaging, the assumption is that a SIP session is composed of a unique medium negotiated at the begining of the session and valid until the end. Specific application servers have to be deployed in the network, which permit the SIP session to only include the medium specified for the service. While it is possible to extend the specification of the service to support one or more additional media, this will lead to the ad-hoc extension of the media support within the application server. An operator may therefore end up extending a push to talk server to support messaging, a messaging server to support voice, and a voice server to support gaming, without never truly supporting a multimedia communication experience, just "rich PoC", "rich messaging" or "rich voice" services.

For me there are three big challenges an operator will face regarding multimedia communication:
1) Deploy an IMS infrastructure which permits multimedia communication between IMS (and other SIP) endpoints.
2) Deploy applications that add value to the end-to-end multimedia experience of the users (thus making useful to have a network between them!).
3) Deploy applications which exploit the multimedia capabilities of SIP to provide the user with a unique and optimal service experience.

To be frank, at the moment the industry is still struggling with #1. However, it is a good sign that the Open Mobile Alliance (OMA) has started to work on the Converged IP Messaging (CPM) enabler, which tries to incorporate such a multimedia experience in the telco network.

Christophe