IMS Service Routing: Big Picture

This post is the first in a series that will describe how the routing of SIP service-related requests is performed in the IMS.

Before going into the details of service profiles, initial filter criteria and the ISC (IMS Service Control) interface, I will start with an attempt at placing IMS service routing in the larger context of end-to-end SIP routing within IMS.

I think this is something missing in most representations of the IMS service architecture, which tend to fragment the overall perception of this architecture, and make it more difficult to comprehend for the novice.

The figure you can see at the top (click to enlarge) shows the end-to-end interaction between two IMS users. However, there exist variants related to which entity initiates the SIP interaction (IMS client or IMS AS), which entity terminates the SIP interaction (IMS client or IMS AS), and whether the end-to-end SIP interaction fully takes place between IMS entities or involves entities in an external network like the circuit-switched network or the Internet. I will address these variants below using specific colors.

Before describing what IMS SIP routing permits to achieve, let's start with one of its apparent limitations compared with how SIP can be used in a non-IMS network.

Restriction to IETF SIP Routing

The routing of a SIP request to its destination is based on the resolution of the request-uri address (IMPU or PSI in IMS) to one or several targets. However, before reaching its destination, the SIP request may traverse several servers, and the originator of the request may itself define in a specific Route header (part of) the path to be followed .

This may permit the client to decide the routing of the SIP request through a set of servers that will deliver added-value services.

This is not possible in the IMS. More precisely, whatever SIP route an IMS client may define in a SIP request it originates will be discarded by the IMS core network (the P-CSCF for that matter) and replaced by another route which ensures the phase 1 of IMS SIP routing described below.

Is this a limitation to the power of IMS, compared to what is possible in, say, the Internet? I don't think so.

I do not think that relying on a SIP client to determine a set of application servers supposed to add value to the end-to-end SIP interaction is a very pragmatic and agile approach to service delivery. The mechanism is limited by the knowledge and sophistication available in the SIP client, which may be put under pressure as soon as more than one application server needs to be inserted in the signalling route (which application servers? In which order?).

Then, you have to compare what is lost (the possibility for an IMS client to define a service route) with what is gained with the IMS architecture: service profile based routing.

The IMS routing of SIP requests based on service profiles (phases 2 and 5 below), is sophisticated, very agile and permits to keep IMS clients very simple, as they do not have to care about service-related routing. It also accurately reflects the business relationship between an IMS user paying an operator, and the operator providing value for money in return.

While some may look at the IMS architecture as a way to deprive users from their freedom to access the services they want to access (note anyway that the limitation is only in the route to access a destination, not the destination itself), others can see the same architecture as a way to simplify the life of users (and their devices) and to concentrate service-related complexity in the hands of those who are asking money for value.

Service Routing for Each Party (See Figure)

An important feature of the IMS service architecture, which is not apparent in figures taken from IMS specifications, is the fact that each party in a two-party or multiparty SIP interaction benefits from its own service routing, and therefore its own services.

As shown in the figure above, an end-to-end SIP interaction between John and Mary will first lead to the invocation of services associated to John (phase 2), and then to services associated to Mary (phase 5).

This feature is very natural for a telecommunications service architecture (it is similar to IN), but it is not to most of the non-IMS SIP implementations, more especially those supporting enterprise VoIP services. Typically, these non-IMS implementations will combine the execution of features that apply to all parties of a call. This difference is usually the most important one to overcome when porting a non-IMS application server on the IMS.

In the IMS architecture, a specific party in an end-to-end SIP interaction is either identified by an IMPU or a PSI. While the figure shows an example of IMPU to IMPU interaction, the following alternatives could also exist:

- IMPU to PSI: an IMS client or an AS-based application acting on behalf of a user interacts with an AS-based application identified by a PSI.

- PSI to IMPU: an AS-based application interacts with an IMS client.

- PSI to PSI: an AS-based application interacts with another AS-based application.

Here is a practical advice for when you define or analyze an IMS message flow: S-CSCFs do not hang just like that in the architecture; they always serve someone or something, and it certainly helps to make it explicit (see for instance the figures in this or the previous post).

Preliminary to the Description of End-To-End IMS Signalling

Here follows the decomposition of an end-to-end SIP interaction into 6 distinct phases.

But first a couple of things...

There is of course a pre-requisite: John is registered with IMS. This implies that his client discovered the P-CSCF it will be associated to (according to 3GPP or TISPAN procedures), and performed the IMS registration procedure leading to John's authentication, the association of an S-CSCF to him, and the setting up of a security association between its client and the P-CSCF.

The figure shows direct interfaces between different operators' networks. However, the GSM Association (GSMA) defined the possibility for 3rd party transit networks to be used in-between, in order to reduce the need for bilateral operator agreements.

Phase 1: routing of the SIP request to the S-CSCF serving the originating party

As described above, the P-CSCF removes any potential route defined by the IMS client and replaces it with a route to the S-CSCF serving the user in its home network. This route was defined during the IMS registration of the user, and may traverse an I-CSCF in case the home network wants to hide its network topology to the potential visited network (note that in practice a border gateway might be used instead).

Phase 2: service profile -based routing for originating user

The S-CSCF serving the originating party applies the service profile for the originating IMPU. This service profile consists of a list of initial filter criteria. It corresponds to the set of services the originating party is associated to. In practice, this means that the service route for the SIP request originated by John is defined by the operator and implemented by the S-CSCF.

In this phase, the S-CSCF may route the SIP request to 0, 1 or several application servers (one after the other in a signalling chain or pipe).

It is possible that one of the application servers terminates the SIP request (i.e. acts as a SIP User Agent). This may happen in three cases:

1) The request was addressed to a PSI hosted by the application server (e.g. user tries to access content)

2) The originating party issued a request addressed to itself, which was actually targeted at one of its services in the network. For instance, SIP requests that update the presence information of a user (PUBLISH for presence event package) are addressed to the user's own IMPU. Another example can be seen in the automatic service discovery and configuration example I described in an earlier post.

3) The application server terminates the request on behalf of the B-party. This may happen, for instance, with services that block traffic to unauthorized destinations. Another example could be the case where a service, potentially after having accessed the presence of the B-party, decides to transform an IMS instant message (SIP MESSAGE) into an email, an SMS, or an Internet IM. In this case, IMS SIP routing is terminated to be superseded by an alternative protocol outside of IMS.

Signalling path termination: the SIP interaction may terminate at phase 2 if one of the application servers decides to act as an endpoint for the SIP request.

IMS exit point: the SIP interaction may exit IMS at phase 2 if an application server serves as a gateway towards a different protocol/domain (e.g. email, SMS, MMS, Internet IM protocol). Note that phase 2 takes place before the IMS core network tries to route the SIP request based on the request-uri. This means that the request-uri might not be an IMS routable URI: it could be a URI specific to the protocol and/or domain to which the SIP request is actually targeted.

In case no application server terminates the SIP request, the S-CSCF proceeds with the next phase.

Phase 3: routing of the SIP request to the destination network
The S-CSCF routes the SIP request according to its request-uri.

In case the request-uri is a TEL URI, the S-CSCF may route the request to the circuit-switched network (see previous post - the request will be routed to the circuit-switched network when the TEL URI does not resolve into a SIP URI through ENUM).

Through DNS, the S-CSCF may also determine that the domain of the request-uri is resolved into a non-IMS network like the Internet.

IMS exit point: the SIP request is routed outside of IMS by the IMS core network if it is a TEL URI that does not resolve into a SIP URI, or if it is a SIP URI whose domain is outside of the IMS (e.g. in the Internet).

Side comment: to come back to the possibility for an IETF SIP client to define by itself a route towards application servers... If it is not possible for an IMS client to define such a route, it is possible for an IMS application server to do it on behalf of the client. This route could binclude application servers in the Internet and could be provided by the IMS client to the IMS AS through signalling or self-provisioning.

In case the B-party is an IMS user (same or different operator), DNS resolves the request-uri to an I-CSCF of the target operator, that acts as an entry point to its network. The request may traverse an I-CSCF of the originating network, in order to hide the network topology to the destination network (note that in practice a border gateway might be used instead).

Phase 4: routing of the SIP request to the S-CSCF serving the destination user

Either the B-party is registered with IMS or not.

If it is, the I-CSCF retrieves the location from the HSS and routes the request to the S-CSCF serving it.

If it is not, there is a procedure to dynamically allocate an S-CSCF to the B-party and to route the request to this S-CSCF. The rationale is that the B-party's IMS services in the network might need to be reachable even when the B-party is not available (e.g. presence, a voice call continuity server that will route the call to the circuit-switched network, a call forwarding service).

Alternative entry points to phase 4: instead of originating from the IMS and having followed phases 1 to 3, the request received by the I-CSCF may originate from the circuit-switched network (request is received from MGCF, i.e. signalling gateway with CS), or from a non-IMS network like the Internet.

IMS entry point: instead of an S-CSCF in the originating network, the request may come from the circuit-switched network (through an MGCF), or from a non-IMS SIP network (e.g. the Internet).

Phase 5: service profile -based routing for the terminating user

The S-CSCF serving the terminating party applies the service profile associated to the IMPU (or PSI) corresponding to the request-uri. This service profile consists of a list of initial filter criteria. It corresponds to a set of services associated to the terminating party.

In this phase, the S-CSCF may route the SIP request to 0, 1 or several application servers (one after the other).

It is possible that one of the application servers terminates the SIP request (i.e. acts as a SIP User Agent). This may happen in two cases:

1) The request was addressed to a PSI hosted by the application server (e.g. user tries to access content, user posts message in chat room). This is the case where an operator offers services to the world. Note that there exist alternative mechanisms to route a request to a PSI.

2) The application server terminates the request on behalf of the B-party. This might be the case for presence (the request was addressed to the B-party but was actually aimed at its presence server) and any other service acting on behalf of the terminating party (e.g. voice call continuity, call or message blocking or forwarding services).

Signalling path termination: the SIP interaction may terminate at phase 5 if one of the application servers decides to act as an endpoint for the SIP request.

IMS exit point: the SIP interaction may exit IMS at phase 5 if an application server serves as a gateway towards a different protocol/domain (e.g. email, SMS, MMS, Internet IM protocol).

Phase 6: delivery to the terminating party

In case there is still a SIP request to be delivered to a B-party, the S-CSCF routes the request to the P-CSCF(s) serving the B-party (there might be several in case several endpoints are registered with the same IMPU), which in turn contacts the device of the B-party.

SIP requests issued by application servers

This post essentially addressed the situation where the SIP request is initiated by an IMS client corresponding to an IMPU. However, to be complete, you also have to consider that IMS application servers are able to generate SIP requests, using either an IMPU or PSI as the originating party, and an IMPU or PSI as the request-uri.

When an AS issues a request with an IMPU as originating address, it is supposed to route it to an S-CSCF serving the IMPU. Starting with 3GPP R7, it is possible to allocate an S-CSCF to the IMPU even if it is not registered with IMS (i.e. the IMS AS issues a request on behalf of an IMPU which is not registered with IMS). IMS routing then proceeds with phase 2.

When an AS issues a request using a PSI as the originating party, it may either reach a S-CSCF serving the PSI, or route the request directly to an I-CSCF for the terminating party. Depending on the case, IMS routing then proceeds with phase 2 (the service profile is associated to the PSI) or directly with phase 4.

A specific case for having an IMS AS issuing a SIP request to the IMS is when it acts as a gateway towards another protocol and/or domain. This is the symetric case to what was described in purple for phases 2 and 5 above.

Christophe

There is no direct relationship to this post, but I just added the initial architecture proposed in 3GPP for the SCIM in the first post I wrote about it in May.

Public Service Identity Service Patterns

In this post, I will try to present some potential usage of Public Service Identities (PSIs) for the delivery of IMS services.

Services to the World

PSIs were standardized for this, but it might be useful to highlight it: PSIs permit an operator to provide services that are accessible from any SIP network.

This means that the IMS Lantern chat room from the previous post, or any content identified through a PSI, is potentially accessible to all IMS subscribers of the world, whether their subscription is a fixed, mobile, cable, or converged one.

This also means that the same service is accessible from non-IMS networks with SIP connectivity like the Internet.

Combination of Private/Restricted and Public Access to a PSI

The previous post might have given the impression that a PSI can either be accessed by a happy few or by everybody.

Actually, this does not have to be. A PSI can be accessed in one way by a happy few, and in another way by all the others, and the way a PSI is accessed can determine the logic that is executed to process the corresponding SIP request in the IMS application layer.

Private/Restricted access to a PSI is determined by the service profile associated to the originator of the SIP request addressed to the PSI (i.e. the service profile of the user includes one or several initial filter criteria that relate to the PSI and permit to route the request to an application server).

What happens for users who initiate a SIP request to the PSI and do not have a PSI-aware service profile?

The IMS core network will try to route the SIP request anyway, and then there are two cases:

1) There is no way to match the PSI to a physical address, i.e. there is no service profile associated to the PSI, and it is not defined in any DNS (or ENUM) server or in the HSS. In that case, the PSI is really accessible by a happy few.

2) There is a "public" PSI routing mechanism, i.e. one of the three mechanisms described in the previous post. In that case, the PSI is also accessible to everybody. The public access mechanism may route the request to another application server or to the same one as the private/restricted access procedure. In any case, it is possible for an application server to determine how the SIP request was routed to the application server (i.e. either as an originating or a terminating request), and consequently to apply a different logic for each case.

Automatic Service Discovery and Configuration

I already gave an example of this mechanism with the automatic service discovery and configuration service pattern. In this example, John is subscribed to Service X, and consequently benefits from the restricted access configuration information associated to the service. His girlfriend Mary is not subscribed to Service X. If she issues a request addressed to sip:ServiceX@operator.com in order to retrieve service X's configuration information, the request will be routed to an alternative service logic, which will deny access to the information.

Restricted Access for Management of Public User Groups

Another example would correspond to a user group identified by the PSI sip:Friends_of_IMS@operator.

Anybody can use this PSI to send an instant message to members of the group, access their presence information, or start a multimedia session with them (public access to the PSI). All these services are accessed through the initiation of an adequate SIP request addressed to the PSI (i.e. MESSAGE, SUBSCRIBE for presence event package, INVITE). Routing to the relevant application server is based on the service profile associated the PSI (i.e. MESSAGEs go to messaging server, SUBSCRIBEs for presence event package go to the resource list server, INVITEs go to the multimedia conferencing server).

On the other hand, only a few users can manage the user group, i.e. add/remove users to it. This implies that SIP requests that permit to access and modify the definition of the user group (SUBSCRIBE, PUBLISH for a group management event package) are restricted to a limited set of people. These people will have their service profile defined in such a way that their management requests to the sip:Friends_of_IMS@operator PSI will be routed to the application server managing the user group. The same management requests issued by a non authorized user will not be routed to any application server and will be rejected by the IMS core network (the service profile associated to the PSI does not define any routing for PUBLISH and SUBSCRIBE requests related to the group management event package).

Differentiated Access to Content (see figure, click to enlarge)

The third example is illustrated by the picture at the top. The PSI sip:This_Content@operator identifies a specific content (e.g. a video) that can be accessed through a SIP session initiated by the user.

Four application servers serve the same PSI.

A and B serve the subscribers of the operator who are authorized to access the content. Access to these application servers is based on the service profiles associated to each subscriber. The service profiles associated to subscribers in the partition #1 route the service request to A, while service profiles associated to subscribers in the partition #2 route the service request to B. Service logic on A and B delivers the content.

C serves the subscribers of the operator who are not authorized to access the content. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is the one of the operator shall be routed to C. The service logic on C may show a preview of the content and propose the user to subscribe to the content.

D serves subscribers of other operators and users from the Internet. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is not the one of the operator shall be routed to D. The service logic on D may propose the user to pay for viewing the content.

It would be possible to further discriminate between users trying to access the content. For instance, the service profile associated to the PSI could determine that SIP requests which do not include a P-Asserted-Identity header (i.e. requests originated from a non-IMS network) should be routed to an application server E.

Christophe

IMS Public Service Identities (PSIs)

After IMS Public User Identities (IMPUs), here is a first post on the second type of identity specified in 3GPP IMS specifications. I will start with the basics.

The concept of IMS Public Service Identity (PSI) was introduced in 3GPP R6. Like an IMPU, a PSI might be defined as a SIP URI (e.g. sip:service@operator) or a TEL URI (e.g. tel:1-234-567890).

To read about PSIs as defined in 3GPP, check chapters 4.3.6 and 5.4.12 of TS 23.228.

Definition (Sort of)

According to TS 23.228, PSIs identify "services which are hosted by application servers". The specification then states that PSIs are used to identify user groups (i.e. sets of users). Is a "user group" a "service"? I do not think so, and this makes the definition of a PSI in 3GPP specifications a little bit ambiguous or short to say the least.

For me, a PSI identifies an IMS service related resource. This might be the service itself (e.g. PSI to change session from 2-party to multiparty, PSI used to retrieve service configuration information), a service feature (e.g. PSI used for starting an ad-hoc push to talk session), a service instance (e.g. PSI identifying a pre-defined conference, PSI identifying a specific content, PSI identifying a specific chat room), a user group (e.g. request to PSI should be exploded to every user in the group identified by the PSI). A PSI could also identify a specific service parameter, a bundling of individual services...

My terminology might not be very accurate, and my own definition is certainly not complete, but basically a PSI identifies anything you might want to identify as the initiator or recipient of a SIP request, which is not an IMS user (for which an IMPU will be used instead). The definition for PSI is therefore directly linked to how SIP and IMS will be used for the delivery of future services. The more IMS and SIP are used to deliver innovative services in an innovative manner, the more the definition for a PSI might be extended.

Prior to its introduction in 3GPP specifications, the concept was not formalized but already existed in practice. For instance, 3GPP already mentioned in R5 the possibility to name a conference through a specific SIP or TEL URI. Similarly, pre-OMA specifications of Push To Talk Over Cellular also made use of a specific SIP URI to start an ad-hoc push to talk session. Concerning the IETF, though it has not been conceptualized as in 3GPP, the possibility to use a SIP URI for something else than a user is common practice (as I once read in an IETF SIP-related RFC: "In the Internet nobody knows you're a dog").

"Private" or "Restricted Access" PSIs

The terms "Private PSI" and "Restricted Access PSI" do not exist in 3GPP specifications, so do not look for them elsewhere than on this blog! Note that the association of the term "private" to an acronym whose first letter means "public" might be a hint for one of two things 1) the author of this blog writes nonsense, 2) 3GPP might not have selected the best name for the concept. You chose.

Private and Restricted Access PSIs are only usable by subscribers of the operator that owns the PSIs. As you will see below (*spoiler*) this is because their routing is based on service profiles associated to the users initiating SIP requests to them.

A Restricted Access PSI can be used by users who are explicitly authorized to access the resource identified by the PSI, i.e. their subscription permits access to the resource. For instance, a specific video streaming content is accessible to a set of users who have paid for it.

A Private PSI has a specific meaning to a limited set of users, possibly a single one. For instance, a user group consisting of John's family members and identified by a PSI like sip:MyFamily@operator, may be accessible by John alone, or John and the members of his family. Other IMS users (e.g. Mary) might have a user group with the same name, but for them this name will point at another group definition (e.g. another family).

Routing of SIP requests addressed to a Private or Restricted Access PSI is determined by the service profiles associated to the users who are authorized to use this PSI. More precisely, their service profile stored in the HSS includes one or several initial filter criteria(s) which determine(s) how a SIP request originating from this user and addressed to this PSI must be routed.

"Really Public" PSIs

"Really Public" PSIs are usable by anybody, including subscribers of other operators than the one that owns the PSI.

As they must be globally routable across various IMS domains (e.g. the request addressed to the PSI may originate from another IMS nettork or from the Internet), 3GPP had to define specific means to route SIP requests addressed to these PSIs. This is actually the reason why the concept was introduced in 3GPP specifications, and the reason for the name of the "public" in PSI.

3GPP was very generous with Really Public PSIs, as it standardized no less than 3 alternative ways to route them (4 if you count 2 sub-variants for subdomain based routing). Considering the complexity and cost induced by the standardization of options and alternative solutions (that need to be implemented and operated afterwards), I never understood why 3GPP (more especially operators) permitted this to happen. But who am I to complain?

Two of these alternatives lead to a very similar result as they route all SIP requests addressed to one PSI to a single application server (i.e. the PSI is the only criterion used to route the SIP request).

The first alternative is subdomain based routing. The PSI will look like sip:anything@service.operator. The "service.operator" subdomain will be resolved through DNS to the application server serving all the PSIs constructed with this subdomain. Sub-variants include the case where the subdomain is resolved to the AS in the network originating the request, and the one where this is the network serving the PSI that resolves the subdomain into the AS address.

The second alternative relies on an address stored in the HSS. When the request addressed to the PSI reaches a signalling entry point to the network serving the PSI (which is an I-CSCF), this I-CSCF matches the PSI with the address of an AS retrieved from the HSS.

The third mechanism is for me by far the most powerful from a service perspective. It consists in treating the PSI as an IMPU (IMS Public User Identity). This is, a service profile is associated to the "PSI user" (this term is used in the specifications) as it would be to an IMPU.

When a request addressed to the PSI is received by the I-CSCF, this one routes the request as if it was addressed to an IMPU (i.e. the HSS provides the I-CSCF with the address of an S-CSCF serving the PSI user). Routing of the PSI by the S-CSCF is then based on a set of initial filter criteria forming the service profile of the PSI.

This approach is interesting as it permits to make PSIs benefit from the service architecture defined for IMS users. More especially, it permits:
- To discriminate service routing of requests addressed to the PSI according to details of the SIP request. For instance, an INVITE for a voice session and an INVITE for a video session addressed to the same PSI may be routed to different specialized media servers. As another example, a subscription to presence (SUBSCRIBE for presence event package) and an instant message (MESSAGE) addressed to the same PSI could be routed either to a presence server or a messaging server.
- To chain several ASs on the signalling path of the SIP request, instead of routing it to a unique AS. For instance, a SIP MESSAGE addressed to the sip:The_IMS_Lantern_ChatRoom@operator PSI, a chat forum for this blog, could be routed through an archiving server, an anti-virus server, and an anti-spam server, prior to reaching its final destination: the chat room server that will dispatch it to all the users currently in the chat room.

Distinct vs. Wildcarded PSIs

Distinct PSIs are PSIs that are fully defined by the operator and provisionned as such in the HSS (e.g. sip:This_Service@operator, provisionned in the HSS with a matching application server address or a service profile).

Wildcarded PSIs permit an operator to provision PSI routing information in the HSS according to a naming pattern. All the PSIs sharing the same naming pattern will be routed the same way. For instance, sip:*_ChatRoom@operator is a wildcarded PSI that corresponds to the IMS Lantern chat room PSI introduced above.

Wildcarded PSIs permit to factorize service routing information between multiple PSIs. They also permit PSIs to be (partly) created by end users, and to be managed fully by an application server without involvement of the operator's provisioning system. For instance, I could create myself the name of the IMS Lantern chat room in the chat room server. No need to change any routing information in the HSS. Every request to the IMS Lantern chat room would be routed to the chat room server according to the wilcarded PSI it is based on.

Activation / De-activation of PSIs

An application server may activate or de-activate a PSI in the HSS through the Sh reference point (interface between an AS and the HSS based on Diameter).

This permits to have a greater application control on PSI routing information. You could imagine the case where a service is available only during certain hours of the day, or days of the week. A PSI could also be usable during a limited period (e.g. a sports event). There are certainly many other usages for the dynamic activation/de-activation of PSIs.

SIP Requests May Originate From a PSI

The IMS service architecture permits application servers to generate SIP requests towards users or other application servers.

It is possible for an AS to use a PSI as the originating address of a SIP request. This permits a service to identify itself as the originator of a service interaction towards a user or another application.

Future post(s) will show potential service patterns making use of PSIs (i.e. ideas on how to use the PSI ingredient to cook some IMS services).

Christophe

IMS Public User Identities (IMPUs)

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

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

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

Tel URIs: Smooth Migration From Legacy Telephony

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

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

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

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

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

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

SIP URIs: The Future of User Addressing

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

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

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

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

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

IMPUs Identify Users, Not a Specific Line or Device!

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

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

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

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

Multiple IMPUs for One User

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

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

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

One IMPU for All Services, Across All Devices

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

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

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

More Enablers for Services

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

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

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

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

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

Christophe

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

Co-existence of Conservative & Progressive Application Layers

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

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

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

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

Alternative But Compatible Communication Paradigms

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

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

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

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

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

Different Public User Identities For Different Services

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

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

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

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

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

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

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

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

From Black Boxes To Open Service Platforms

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

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

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

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

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

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

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

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

Co-existence and Smooth Transition

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

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

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

Christophe

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

Conservative & Progressive Application Layers

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

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

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

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

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

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

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

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

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

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

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

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

Multimedia Communication permits two major things:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Christophe

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

The Beatles & The Stones

The summary of a new report by Light Reading titled Telco Web 2.0 Mashups: A New Blueprint for Service Creation makes me think of the Beatles v. Stones battle.

Obviously, in the 60's the Beatles and the Rolling Stones were foes to death, and history can tell that only one of these two bands was great. Which one?

The report apparently highlights the need for operators to rapidly embrace a web services and service mashups approach. Fine, I totally agree with this.

My problem is when IMS and SIP are presented as an alternative to this approach. In this report this is clearly the bad one, as everybody knows that you cannot implement both web services and SIP/IMS and combine the two for an optimal usage.

When will the industry stop looking for the silver bullet? The unique technical solution, the unique business model that will answer all problems?

A core thesis I am trying to develop in this blog is that SOA/web services and IMS/SIP can be combined together to form a new paradigm (User Oriented Architecture) which, like the bands cited above would be more than the sum of its parts.

Another summary of the report cites JAIN SLEE as the service creation/execution environment in the context of IMS. I like JAIN SLEE and I think it can play an interesting role in IMS and across IMS and other networks.

However, it would be more interesting if the summary mentioned Java EE (J2EE) as well, as it could show that the Web Services / SIP picture is not that black and white. J2EE platforms fit very well in a web services world and I know at least three of the main J2EE platform suppliers which include SIP servlet support at the core of their platform. This means that there exist on the market platforms that can be used to implement services that are both web services and SIP/IMS centric. Unless of course this is strictly forbidden by both IMS and Web Services purists (I already had the opportunity to write about the artificial separation between IMS and Web Services chapels).

Why should the telecom industry just follow the steps of Internet companies and not try to bring its own contribution to the future, by integrating and enriching what exists today?

Christophe

IMS Communication Services: Latest News

Last week, the 3GPP CT plenary meeting decided to align on the IETF approach for the handling of communication services. This can be seen in a Liaison Statement to the IETF available on the 3GPP web site.

The worst has been avoided for now, as the alternative proposal (which lost) had two important drawbacks:
1) It reused a standard IETF mechanism (feature tag used in the Accept-Contact header) with a different, 3GPP-specific semantic.
2) It made the concept of communication service directly manipulated by IMS clients, which could have a huge impact on interoperability aspects with non IMS clients, and would have driven the implementation of mobile handsets for the years to come.

The IETF alternative limits the mandatory identification of communication services within the IMS network, which interprets SIP signaling generated by clients and derives the communication service ID from it.

Easier to Eventually Get Rid of It

As a network centric concept, the communication service ID is less intrusive and easier to control by operators (compared to the case where it would be client-centric). It can certainly be used for early IMS silo services, and then be discarded when more multimedia services are deployed.

This can therefore be a short-term concept serving short-term requirements.

The Concept Could Be Useful Even in the Long Term

Moreover, it could evolve into something actually interesting in the context of a more progressive vision of IMS services.

At the moment, the S-CSCF uses initial filter criteria in order to dispatch SIP requests to the application layer. The evaluation of filter criteria implies an analysis of the SIP requests (method, direction, content).

As the result of this analysis is not documented in the SIP request forwarded to the application server, the application server (potentially the SCIM into it) needs to perform a new and somehow redundant analysis of the SIP request in order to determine which services should be invoked.

A communication service ID header could permit an identification of the initial filter criteria that led to the forwarding to the application server, that could be used by the AS as part of its own analysis of the incoming SIP request.

Obviously, in this context the ID would not identify a service, but rather a set of criteria associated to a SIP request, and which can be used as information (among other) to invoke service logic in application servers.

Still Some Risks

From the LS to the IETF you cannot determine that the risk for communication services creating an IMS walled garden and limiting potential for service innovation has been averted for good.

The LS explicitly mentions the need to comply with requirements written in TS 23.228. The problem is that the most dangerous aspects of communication services are described in TS 23.228 (see last post).

On the other hand, the IETF could also rightly underline that TS 23.228 includes incompatible requirements, as I tried to explain in my last post. More especially, some requirements describing a 3GPP-specific concept of communication service directly conflict with others asking to preserve SIP capabilities and interworking with non-IMS networks.

In any case, one of the important requirements in TS 23.228 is that it should be possible for an IMS client or an IMS network not to make use of communication services. This optionality should ensure holes in the hypothetical walls of the IMS garden.

I am therefore reasonably confident that things will turn out in the right direction, once the IETF identifies these incompatibilities and proposes to resolve them by removing the dangerous requirements. The CT plenary decision from last week seems to express the importance that 3GPP places into being interoperable with other SIP networks.

Christophe

April 2009 update: the concept of Communication Service as finally specified is described here.

IMS Communication Services: Uncut Version

In my last post, I presented a light version of the 3GPP concept of Communication Service, which focuses on the identification in SIP signalling of the service a user intends to use.

However, the standardization of communication services started nearly 18 months ago, and from contributions to the subject you can draw a quite precise picture of what IMS services could be, would all the proposed requirements be approved by 3GPP and implemented in products.

The text below written in italic is my own rephrasing of requirements that were proposed for communication services (I usually try to stay close to the original wording). All these requirements can be found in public documents: contributions to 3GPP SA2, text in chapter 4.13 of TS 23.228 7.x.x, a draft submitted to the IETF, and contributions to 3GPP CT1.

A communication service is the aggregation of one or several media components. The rules that govern this aggregation are implemented by service logic. A service description specifies the possible behavior and states, e.g. the allowed media combination and state transitions. If an IMS client would like to perform a change in a session which is not part of the service definition, it shall establish a new session.

The lack of support of true multimedia making use of intrinsic SIP capabilities is not a defect of early IMS silo services, that needs to be fixed as soon as possible. This is a feature of 3GPP introduced in R7. Such a requirement could install silos in standard compliant IMS deployments for many years.

The approach is clearly restrictive. IMS clients are placed under control, and service logic is implemented to prevent them from accessing non allowed multimedia features.

Multimedia may be possible, but through multiple parallel sessions. Such an approach may imply a complex interface towards the end-user, who would need to explicitly control parallel sessions. Alternatively, it would require the implementation of a ad-hoc client able to hide the multiplicity of sessions to the end-user. This latter option would have the "merit" to both clearly identify what is needed (i.e. a single service session) and demonstrate that communication services prevent to do it in a natural way (i.e. a single SIP session). Simulating multimedia sessions through multiple more restricted sessions would certainly incur complexity and costs. No need to say that such strange SIP clients would be very different from non-IMS SIP clients, thus re-inforcing IMS as a world apart.

Communication services are either standardized (e.g. push to talk) or proprietary and specific to an operator or an enterprise.

Every SIP message initiated by an IMS client must include a requested IMS Communication Service. A session can only be started between two clients if they share the same IMS Communication Service. Within the client, the Communication Service ID is used to dispatch the message to the correct application.

The first statement seems to imply an opening of the concept to non standardized communication services including, why not?, more innovative and multimedia ones.

However, this openness looks very artificial when you see that communication service IDs must be part of all SIP signalling and directly govern the ability to start a session between two clients.

Let's take an example.

An operator decides to introduce a new communication client, enabling the user to freely switch between messaging/chat and voice communication inside one session. In a normal SIP world, such a client can establish sessions with voice-only clients, as well as with messaging-only clients. The only restriction is that the transition to another media component is not possible with these peer clients. The new service is therefore both compatible with legacy clients and with new or more sophisticated multimedia clients introduced by this and other service providers, in the IMS, in the enterprise or in the Internet.

In the wonderful world of communication services, the situation is different. The operator must create a new communication service ID for the service. Because this communication service ID is different from the voice-only and messaging-only ones, it is not possible to start a session with legacy clients. Session setup will also fail with (a priori) compatible clients introduced by other operators but using a different ID. As a consequence, the service will have great difficulties to take off as it is likely that most attempts to set up a session with it will fail. It is certainly better for the operator to wait for standardization to introduce the service.

As the concept of communication service does not exist outside of IMS, the mandatory nature of its usage makes interoperability with non IMS clients virtually impossible. Consequently, the new service will not even be able to setup sessions with clients that are not subject to communication service limitations.

The hypothetical adoption of the requirements described above would therefore both create an IMS walled garden and make very difficult the introduction of innovative and operator-specific multimedia services within this walled garden.

Added-value applications deployed over IMS must make use of Communication Services. When a client intends to access such an application, the SIP signalling must include two identities: the identity of the application and the identity of the communication service it uses.

There is plenty to say about this proposal...

First it gives the impression of a willingness to favor service innovation. However, in a context where communications services consist of voice, push to talk over cellular (i.e. voice without the quality) and messaging, how different can these applications be from those that can make use today of circuit switched voice, SMS and MMS?

The approach seems to enforce the usage of silos mimicking pre-IMS services, as the only way to deliver non standardized services in the IMS. Non standardized services need to follow the rails (pipes?) strictly and arbitrarily defined by standardization, and which are more or less the same as before. Any multimedia service that would make use of standard (e.g. RTSP) or application-level protocols that are not part of a communication service definition are outlawed by 3GPP standards.

You may imagine that new communication services, permitting more innovative services will be introduced in the future. In 3GPP R8? R9? In any case, this is likely to be in several years from a product perspective. Strictly controlled, innovation has to follow the roadmap defined by 3GPP and the companies that control it.

Another interesting aspect of this approach is that it creates a two-tiered IMS application layer in both IMS clients and in the network. This layered architecture is explicit in a figure introduced in TS 23.228 chapter 4.13.

The bottom part of this layer consists of the standardized communication services, which are very telco centric and demand carrier grade characteristics to control undisciplined clients. I guess classical network equipment providers are the best placed to deliver these as black boxes.

The upper part is the innovative one, the more IT layer. It has to rely on the lower part, certainly through a set of interfaces like OSA/Parlay or web services. As I wrote above, room for innovation is strictly limited.

In past posts, I described my belief that for the benefit of the industry, the whole IMS application layer should belong to advanced and open IT platforms, benefiting from the huge community of Java developers and the ability for people with good ideas to easily and rapidly develop them.

Communication services as described in these requirements would lead to a marginalization of this IT layer and its tight control by the telco one below. It would actually recreate the current telecom situation, in which there are so few ammunitions to create innovative services that innovation can hardly take place.

If you consider that there might be an ongoing fight between old school NEPs and IT companies (or NEPs clearly embracing an IT strategy) for the control of the future telecom application layer, communication services look like a powerful weapon for the former against the latter.

Communication services should not adversely impact interoperability with external SIP and circuit-switched networks. It shall be possible for IMS clients and IMS networks to support communication that do not make use of a communication service ID. The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

All these requirements can be found in TS 23.228 together with some of the seemingly contradicting requirements above. This shows that some companies in 3GPP (vendors, operators) do not support the idea of an IMS walled garden and are afraid of the potential consequences of communication services on the ability of IMS to innovate and to be open to other domains.

This is an important thing to take into account. 3GPP consists of a variety of visions which sometimes oppose each other. It would be wrong to say that 3GPP as a whole supports the most extreme definition of communication services, and I would tend to think that, well informed on the potentially negative effects of these concepts, the great majority of 3GPP companies would not endorse them.

Christophe

April 2009 update: the concept of Communication Service as finally specified is described here.