Danger! IMS Communication Services

You may not be aware of it, but the future of IMS is maybe being defined right now, in 3GPP, as a debate is raging around the concept of Communication Services and how it should be supported in SIP signalling.

If you need a practical exercise for navigating through the 3GPP web site, just access the directory for the ongoing CT Plenary meeting (TSG CT twice, then meeting #36, look for Communication Services).

In the worst case scenario, IMS may really become this telecommunications monster some have already wrongly denounced (at least until now).

For the second time since the begining of IMS standardization, the IETF had to raise its voice and is now warning 3GPP about the risk of a dangerous divergence between the IMS and non IMS SIP worlds. The first time, during the 2002-2003 winter, the danger was averted. Will it be the same this time?

Let's start by presenting Communication Services.

The concept of Communication Services was introduced in the 3GPP Release 7 of IMS by one of the most important network equipment providers.

There have been proposals for several requirements defining a new concept, but at the moment consensus could only be found on a subset of them. This subset is already very dangerous to those like me who believe that the hypothetical success of IMS is tightly linked to its ability to provide the best services to end-users and to freely interoperate with other IP networks, more especially the Internet.

In this post, I will introduce this light version of the concept. In another one I will present the more complete version, in case all proposed requirements would be included.

Communication Services: Light Version

The light version of Communication Services answers a concern shared by many operators, and clearly expressed by the GSM Association: the need to clearly identify IMS services for inter-operator settlement and charging.

The reasoning is the following.

An issue with SIP is that the protocol is so generic that it is hard to determine which service a user intends to use when its client issues a particular SIP message. For instance, SIP INVITE is used to setup a session. In a circuit-switched network, the ISUP equivalent is used to set up a voice call. In early IMS, a SIP INVITE may be used to start a voice session, but also a push to talk session, or a messaging session, or a videosharing session. It could also be a gaming session, an application sharing session, or a multimedia session combining several of the preceding components and/or others.

In this context, how do you want to interconnect different networks, possibly with transit ones in the middle, and still agree on how the money is shared between all parties? In other words, how can you preserve the telephony business model with IMS?

The simple (simplistic?) solution is to tag every initial or standalone SIP message with an ID identifying the service it requests.

A SIP INVITE starting a push to talk session will include a service identifier for push to talk. The same for a voice session, a messaging session, etc.

This reasoning leads to some issues, that have been described in this excellent IETF draft by Jonathan Rosenberg.

I will use my own words to describe some of these.

What is a Service?

The telecommunications industry has a silo thinking about communication services, which frontally clashes with the capabilities of the SIP protocol, and by ricochet with the interest of end-users.

In this silo thinking, push to talk is a pure walkie talkie service. It starts as walkie talkie, continues as walkie talkie, and ends as walkie talkie. And this until a standardization body decides that another communication medium is added to the definition of the push to talk service.

Similarly IMS session-based messaging is a service which is purely about messaging, from begining to end (OMA Converged IP Messaging is trying to change this). And so on.

However, SIP can support a much more powerful communication concept.

First, session setup follows a peer to peer negotiation process, during which the initial content of the session can be agreed on. Then, at any time, the session can be renegotiated between the peers. For instance, a messaging component can be replaced by a voice one, or be complemented with a game.

It is a fact that early IMS communication services (e.g. push to talk, voice) have been implemented as silos.

It can also be claimed that the push to talk feature tag that appears in a push to talk INVITE is already a de facto service identity for the push to talk service. But this is wrong: it is never written in push to talk specifications that this tag is a service identity and must be used as such (the specifications mandate to use the tag according to its IETF semantic).

The definition of a service identity as a standard IMS concept implies that the content of a session is frozen from the begining, and limited to the standard definition of the corresponding service. It also implies that this identity is used in many locations in the IMS infrastructure, for instance for service authorization, for service charging, for applying specific policies, as the element used to trigger specific service logic, as the element used to invoke a specific application in an IMS client, as an element used for agreement of the session setup between two IMS clients, etc.

Without the service identity concept, you can consider that early IMS service silos can be fixed through a re-engineering of service implementation. As IMS is still in early deployment stages, this fix could happen relatively smoothly for most.

With the concept duly standardized and impacting a large part of the IMS infrastructure implementation (core network, application layer, OSS/BSS, IMS clients), an evolution from silos to a more horizontal approach will be more complex, slow and costly. It may also not be standard compliant, if you want to go too fast.

Who Wins with this Approach?

Certainly some network equipment vendors, who can sell as many black boxes as they manage to define silo communication services. If a feature of these black boxes is to ensure that the service definition is not violated by SIP clients (i.e. "it is forbidden to upgrade a messaging session to a voice one, you naughty customer!"), the black boxes need to be involved in all IMS sessions, and therefore need to support all the carrier-gradeness characteristics which permit to sell them at outrageous prices.

Certainly not the end-user, who is condemned to an artificially limited communication experience, while it may experience a radically different one each time a non-IMS SIP client comes to its attention in the Internet. The temptation to bypass the telecom communication services might be big (why would you hesitate to have much better for a fraction of the price?).

What about operators?

They enjoy the comfort to keep on making business as usual (at least as long as there is some) and the relief not to have to reinvent their way of thinking about telecommunications in the few years to come. As a side effect, they gain expensive communication pipes, as they artificially limit the services they offer to their customers, and have to pay a high price for this, with the hope that they will charge a lot in return (does this ring a familar bell?).

Risks of an IMS Walled Garden

The draft from Jonathan Rosenberg is focusing on one particular issue: the usage of service identities by SIP/IMS clients.

If an IMS client is mandated to indicate the communication service it uses when it issues SIP signaling, and if this communication service ID is used by the peer client to accept the session, you run into potentially big interoperability problems with clients which are not ready for this (i.e. non IMS clients).

The approach would require that SIP clients share a knowledge of the communication services they can use. It also makes much more difficult for two clients to negotiate a compromise session if the optimal one is not possible.

In effect, the risk is to simply prevent communication between IMS and non IMS clients. Something that may be needed, if you do not want your IMS users to know that there is another SIP world in which communication does not have to be artificially limited.

The side effect is also to limit the set of IMS communication services to what the pace and imagination of telecom standardization and vendors can deliver. Good luck.

The picture I am drawing is quite dark, but I think it is not far from the potential IMS reality in front of us, would 3GPP decide to go the wrong way.

Christophe

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

Finding Your Way on the 3GPP Web Site

As requested last week by a reader, here is a post that will try to help you navigate through the 3GPP web site and its specifications.

The bad news is that 3GPP is a very big and complex standardization body. It usually takes time to understand how it works and to find what you need on the web site.

On the other hand, the good news is that 3GPP is a very structured and formal group. Moreover, all its specifications (including intermediate versions), contributions, and meeting minutes are available to everybody who can find its way to them.

Overview of 3GPP Work Items

In 3GPP, every standardization topic is associated to one or several work items. Each work item is defined in a work item description document (WID), which describes the topic, the reason for it, the companies initially supporting the work item, the 3GPP groups taking part into it, the specifications it will create or impact, as well as a preliminary roadmap.

New topics are proposed to 3GPP as WID drafts, and a certain number of companies needs to agree on a draft and place their name into it as a supporting company in order for the work item to be considered for inclusion in the current 3GPP release.

The 3GPP workplan is a convenient way to have an overview of all the work items, their roadmap and actualized completion status.

Individual WIDs referenced in the workplan are stored here. You can also get information on each there. The WID is a good starting point for your search on a specific topic. More especially, you will know which 3GPP working groups will be involved and the specifications or technical reports they will write.

In 3GPP, technical reports (TRs) are used to investigate a topic or perform a feasibility study. Once the report is completed, it might form the baseline for a Technical Specification (TS), lead to a few sentences added to one, or simply disappear in the void of failed 3GPP standardization attempts. Beware that a TR is interesting only if it is currently being worked on. Past TRs are just there for history and it is more important to look for how they possibly translated into specifications.

3GPP Working Groups

The 3GPP organization is presented here. You can click on each group to have more information.

In the context of IMS, the following groups are the most important.

TSG SA WG1 (SA1 in short) is responsible for producing requirements (stage 1 specifications, TS 22.xxx). The group belongs to operators.

TSG SA WG2 (SA2) defines the architecture (stage 2 specifications, TS 23.xxx). This is the most strategic and political group, controlled by the big Network Equipment Providers and by a few operators.

Other groups define the details of the procedures and protocols: TSG CT WG1 (CT1) is the group specifying SIP aspects and TSG CT WG4 (CT4) is the Diameter/HSS group. These groups are usually less political, and CT1 might even look like an annex of the IETF in 3GPP.

Finally, some groups address specific aspects such as security (SA3) or OSS/BSS (SA5).

3GPP Specifications

You can see the specifications related to each work item in the WID page indicated above. You can also have access to all 3GPP (and ETSI GSM) specifications in this matrix. This page is usually my entry point to the 3GPP web site, and I usually make a search on keywords to find the specifications or reports that relate to the topic of interest. When you click on the specification number, you can access all the past and current versions of the document.

Work in Progress / Contributions

The versions of the specifications (or technical reports) you can access from the matrix may not reflect the latest status of an ongoing activity.

If you want to closely follow an item in progress of analyze the positions of different companies on a specific topic (who is pushing for what? Who is championning this idea? Who is trying to block this item? Is this company active in the discussion?) you need access to the contributions and minutes of the working groups that takes care of the specification or report you are interested in.

To do this, you need to access the meetings of the working groups on the 3GPP FTP server.

Let's take the example of an SA2 meeting (architecture). You need to navigate though SA and then WG2. You then have access to all the past (and some future) meetings on this page.

As I am writing, the latest meeting for which contributions can be accessed is #57 in Beijing.

The agenda is interesting to see all the topics discussed, and more especially the agenda number associated to each of them. In Beijing, most of the meeting was dedicated to the System Architecture Evolution, but you can still find for instance "IMS Emergency" as agenda item 7.3.

The doclist permits to see in a table all the contributions submitted for the meeting, as well as the submitting companies. By screening via the agenda item number, you can find all the contributions submitted for the subject you are interested in.

These contributions are all stored in the Docs subdirectory. Some of the contributions are the ongoing versions of specifications and reports.

Others are Liaison Statements, which are the official way to communicate between 3GPP groups and between 3GPP and other standardization bodies (e.g. OMA, TISPAN, WiMax Forum). Liaison Statements are often interesting to look at.

The most important document to find your way in the meeting is the meeting report. Structured according to the agenda it documents the fate of all contributions (e.g. approved, noted, not addressed), as well as some (limited) feedback on the discussions related to these contributions.

It is not rare that an original contribution undergoes several modifications during the week, before being (hypothetically) approved. You therefore need to track the progress of the one you are interested in, and check which version was finally approved, if any.

More than the minutes themselves, the number and nature of modifications that a particular contribution underwent is the best indication of how disputed it was. And therefore how important it is to the different companies taking part in the discussion. Typically, if a contribution went through 5 successive versions, with the last one changing a single word to the previous, you can assume the discussion was quite tense.

There are some cases where the meeting did not have time to approve the latest version of a contribution. If it is assumed that this one is not contentious (or it is important to progress on this topic) it will be left for email approval.

You may then need to track the status of the contribution in the associated mailing list. Usually, the list of contributions left for email approval is sent out after the meeting, with a deadline. You can then follow email threads to see how it goes.

If you are not familiar with them, you might be surprised by the fact that most 3GPP contributions are short and focused. Often, a coherent idea pushed by a vendor is split in a family of related contributions. The reason is that companies prefer to have parts of a concept accepted in a meeting, rather than seeing everything rejected because of a single contentious aspect.

I hope this information will be of interest to some of you. My experience is that few people are able to efficiently exploit the mine of information accessible from 3GPP. It takes some practice time, but once you got used to it you are a 3GPP master.

The situation is different for OMA. First you need to be a member company to access most of the material. Then, it might the fact that I was formatted by 3GPP, I find the OMA web page very messy and I usually have a hard time finding what I want on it.

Christophe

Service Pattern: IMS Content Indirection

In this post I will describe a potential service use case making use of SIP and the IMS service architecture. Whether this use case is a realistic one or not is not the point. The intention is to use it to illustrate some of the remarkable service-related features of IMS.

SIP Preliminary Step to Content Access

John is browsing a web page providing access to content.

By clicking on a link embedded in the web page, he generates a SIP request (e.g. MESSAGE) addressed to a Public Service Identity (PSI) corresponding to the content (e.g. sip:content_000001@operator.com).

The service profile associated to John's Public User Identity (IMPU) defines that a request initiated by John and addressed to a specific SIP URI pattern to which the PSI corresponds (e.g. sip:content_*@operator.com) shall be routed to a SIP Application Server controlling access to the content.

The control application on the SIP AS does what it has to do, then sends a SIP request back to John's IMPU. This might be a SIP REFER that redirects John's client to a URI pointing at the content (e.g. an HTTP URI, an RTSP URI) or a new SIP MESSAGE with content indirection to the same URI. A difference between the two is that the REFER permits John's client to notify the control application of the result of the referring.

John then accesses the content using the protocol implied by the URI (e.g. HTTP, RTSP).

This use case is a typical content access one, which is preceded by a SIP preliminary step. This step uses the fact that a SIP URI can be embedded into a web page, with the indication of the SIP method to be generated if it is clicked on. See this link for more information on this.

What can it bring to add this SIP preliminary step to content access? What can be the type of logic implemented in the SIP application server?

Content Authorization Through the IMS Service Architecture

I already showed it in the Service Discovery And Configuration example and explained in the following post that the IMS service architecture can be used to support authorization to a specific service.

The SIP request initiated by John's client is routed to the SIP application server because there is an Initial Filter Criteria in John's service profile that determines this routing.

If there was no such initial filter criteria, there could be two possibilities:

- The PSI identifying the content is not routable in the IMS network. The request is rejected by the IMS core network and John cannot access the content.

- The PSI identifying the content is routable in the IMS network, either through a DNS entry or because the PSI itself is associated to a service profile that will route the request to a specific SIP AS. This SIP AS may perform various actions such as explaining to John why he could not access the content, propose John to subscribe to the type of content, provide John with a trial period, etc. The SIP AS may propose different options depending on, e.g. whether John is a subscriber of the operator or a subscriber of another operator.

Exploitation of 3GPP SIP Headers

The SIP request that reaches the SIP Application Server includes 3GPP SIP headers that can be of interest for the control application.

The P-Asserted-Identity header permits the SIP AS to know that the user was authenticated by the IMS core network, as well as the identity that was authenticated. Based on this identity, the application can further control the authorization of the user to access the content, and apply corresponding policies and/or user preferences. The user orientation of the IMS service architecture makes that John's request is routed to a SIP AS that is dedicated to John and naturally owns John's user profile data (the same service request by Mary would possibly reach another SIP AS dedicated to Mary).

Note that John may have different user identities (different personas) to which different policies/preferences may apply.

Note as well that P-Asserted-Identity is provided even if the user is not a subscriber of the operator, as the IMS security domain crosses operator network's boundaries. It might not be possible for the network to customize access to the content for a foreign user, but it may at least identify the user and know the operator it is subscribed to.

P-Access-Network-Info provides the control application with information about the access technology being used by the client (e.g. xDSL, UMTS, WiFi). This may help the application determine how content delivery should be performed.

The same header may also include information about the location of the user (e.g. a cell ID, a fixed location). This may help the application decide, e.g. which content server is optimal to deliver the content.

P-Visited-Network-ID provides the name of the network into which in the (mobile) user might be roaming. This may permit to apply inter-operator agreements to content delivery.

P-Charging-Function-Addresses provides the addresses of the charging nodes to which CDRs or charging events shall be sent. P-Charging-Vector provides charging IDs that should be used for the charging operation (the PSI for the content can also be relevant for charging).

The application therefore receives a set of information via the SIP message, which allow it to take a decision about whether the content should be delivered and how.

The control logic may impact the generation of the content URI that will be sent back to the user (e.g. some parameters might be added) and may possibly lead to interactions with the content server that will eventually deliver the content. These interactions could be based on web services or another protocol.

Additional Architectural Aspects

The control logic located in the SIP AS is the only SIP/IMS -related logic involved in the service delivery. The content server does not even need to be SIP aware.

The control logic located in the IMS may be owned by the operator while the content server might be owned by a 3rd party, either located in the IMS or in another network (e.g. the Internet).

The relationship between the control logic in the IMS and the content server can be very loose. Ideally, there would be no need for any interaction between the two prior to content delivery, but I do not know if it is possible. In any case, this interaction between the control logic in the IMS and the content server does not have to be based on SIP or another IMS protocol.

The control logic can be factorized and shared between multiple contents, possibly supplied by the operator and/or by various 3rd party service providers.

Delivering content through SIP indirection is simple but also provides limited opportunities for the operator to add value to the content. The next step is to deliver the content within a SIP session. I will present this use case in a future post.

Christophe

User Application Data: Opinions

After describing a panorama of the standards and technologies that can be used for user application data management and storage, here is a more subjective post.

User Data Distribution Can Be Managed!

Our industry has been struggling for years between two extremes:
- Distributing user data in application servers in order to optimize service delivery.
- Centralizing user data in order to simplify its management and ensure its integrity.

I think that with both the IMS service architecture and the Generic User Profile (GUP), we now have the tools to permit user data to reside where it is the most useful for service delivery, i.e. in the application servers hosting services.

As I tried to illustrate with the Automatic Service Discovery & Configuration example, and this is the same for presence, discovering the XCAP location of user data can be as easy as generating a SIP SUBSCRIBE addressed either to the identity of the user the data is associated to, or the identity of the service it applies to. The SIP/XCAP combo also permits to synchronize duplicates of user data with the master copy.

GUP is the exact equivalent in the web services sphere. GUP could be used to support centralized user data / subscription management, by hiding distribution details to the BSS system. See more below on GUP.

Exploiting Presence

Presence should be considered as one of the main sources of information related to the user, its devices and its applications.

This repository of user data will store both static and dynamic user-related data. This data will be populated/modified by the user, but also automatically by client and network based applications acting on behalf of the user, as well as network entities (e.g. IMS core, location server).

Presence data may be used by many applications, as an alternative to user application data specifically managed for them.

SIP and XCAP will be the natural protocols to access presence, according to 3GPP and IETF specifications.

Centralization for Common Application Data

User data that need to be shared between multiple applications can be stored in a centralized repository. Which one?

I do not like the idea of using the HSS as a user application data repository. Besides the potential impacts on HSS characteristics, another issue with this approach is that Diameter is not an optimal protocol for application data management. Moreover, the Sh reference point is very weak in terms of data management semantic, more especially compared to available alternatives. You have to realize that 3GPP specified the possibility to store application data in the HSS before GUP, XCAP, and CPS were defined.

I would like a centralized user repository to support SIP and XCAP in order to permit a smooth integration in the IMS service architecture. This means that the repository would be a SIP application server in the IMS architecture, and not a standalone XDMS as the OMA architecture seems to suggest.

This user repository could be based on the CPS architecture, which means that LDAP could also be an interface to it, and it would support GUP as well.

Therefore, overall, the user repository would be a SIP AS, using CPS as a backend data store, and supporting the GUP interface.

Generic User Profile & Liberty

I believe that Liberty and GUP would permit a strong integration of the future telecommunications network into a Service Oriented Architecture and into Web 2.0.

GUP is the optimal architecture and set of protocols to support Liberty in the operator's network.

I also think it should be used for subscription and user data management by the operator. Do you know that 3GPP specified the whole HSS data model using a GUP-compliant XML schema? This means that GUP could be imposed on suppliers right now as an open interface for HSS provisioning.

On the other hand, SIP/XCAP is a more lightweight approach to support access and management of user application data by IMS clients and IMS application servers.

It should be noted that at the moment the plans of most Network Equipment Providers to support GUP seem to be quite fuzzy, to say the least. There is therefore a risk that GUP remains a good idea on paper. At least as long as operators do not exert more pressure on their favorite vendors.

Common Profile Store to Break Silo Databases and for Coherent Data Modeling

In terms of actual database implementation, I think that the CPS approach is rolling and nothing will stop it. Some major suppliers have already embraced the concept and are offering HLRs and HSS's implemented on it. Others still resist, but will have to surrender sooner or later.

In the mid-term, all network databases (e.g. HLR, HSS, AAA) as well as some of the application servers will be implemented according to the CPS approach. All open service platforms (whether based on J2EE or JAIN SLEE) should integrate with a CPS.

Moreover, the CPS approach provides a unique opportunity to define a coherent model for user profile data across multiple network databases and application servers, while permitting application-specific extensions as required for a dynamic and differentiated service network.

Christophe

User Application Data: a Panorama

I tend to think that IMS and all-IP will make the telecommunications industry move from an era where the typical technical challenge was to design a specific solution for every problem to a new one where the main difficulty will be to select one solution among many candidates.

An illustration of this is user profile management and storage in the future application layer.

In this post I will try to make a panorama of standards and industry trends that may impact this topic in the years to come. In another one, I will express some personal opinions about the way to go.

User Profile Data in the HSS (Diameter, unspecified data format)

The Home Subscriber Server (called UPSF for fixed networks) is the database to store all the user data required by the IMS core network to fulfill its duties.

Additionally, the IMS service architecture has an interface between the HSS and the SIP Application Server called Sh.

This interface is based on Diameter and can be used by the application server for two purposes:

- Accessing user data normally stored in the HSS (or in the HLR), such as the user registration status, the S-CSCF that serves the user, or the service profile associated to the user.

- Storing application data in the HSS. This data is transparent to the HSS, i.e. it does not understand its format and semantic.

Sh supports a Diameter-based notification mechanism, permitting to alert the application server when data has been modified.

Most suppliers support the data repository feature of the HSS. It should be noted that the HSS is a mission critical database, which tends to constitute a major portion of the cost of an IMS core network. In this context, the application data repository feature of the HSS and associated questions (e.g. how much data will be stored in it? How much traffic will it generate?) raises questions about the required characteristics for the HSS and its eventual cost for an operator.

User Profile Data in SIP Application Servers (SIP/XCAP, XML)

In the IMS service architecture, there is a reference point called Ut between IMS clients and Application Servers that is used for service customization. This interface is based on XCAP, a simple HTTP based protocol specified in the IETF, which permits to access and manage data defined as XML documents.

The IMS service architecture therefore implies that a SIP application server can own the user data corresponding to the services it supports. This is a quite straightforward and optimized approach to co-locate user service data with the services that make use of them.

In the Automatic Service Discovery & Configuration example, I showed how a SIP event package (i.e. SUBSCRIBE, NOTIFY, PULBLISH) can be used by an IMS client to easily retrieve the XCAP location of user data associated to the user (SUBSCRIBE is addressed to one of the user's Public Identities) or to a specific service associated to the user (SUBSCRIBE is addressed to Public Service Identity). The XCAP URI can then be provided to the client in a NOTIFY. The event package also permits the client to monitor changes to the data (as in the IETF, a SIP event package is used to monitor changes in data manipulated using XCAP). These mechanisms can also be used within the network for an application server to retrieve user data in another application server.

XCAP Data Management Servers (XCAP, XML)

Based on XCAP, the Open Mobile Alliance (OMA) defined an architecture for user data management which consists of XCAP Data Management Servers (XDMS). You can see figures in this page from Tech-invite.

OMA decided to define a Shared XDMS storing common data between different services/enablers, as well as a specific XDMS for each of them (e.g. push to talk, presence, resource lists). Each of these XDMS is logically separated from the SIP application server supporting the corresponding service/enabler.

In practice, this ambiguous architecture is likely to lead to two implementation options:

1) The supplier decides to implement a network database called XDMS to store all XCAP data, i.e. OMA Shared XDMS and all the service/enabler -specific XDMS. This database is accessed through the XCAP protocol. A priori, it does not support any SIP event package, which may lead to synchronization problems with clients.

2) The supplier decides to combine each service/enabler specific XDMS in the SIP application server supporting the corresponding application. This approach is more in line with the 3GPP service architecture for which Ut (XCAP) and ISC (SIP) terminate to the same entity. It also corresponds to the user-profile-data-in-SIP-AS option above. It permits to support the SIP event package for monitoring of changes in the user data. The supplier may also decide to implement the Shared XDMS as a SIP AS.

Presence (SIP/XCAP, XML)

It might seem strange to list presence, a specific IMS service/enabler, as a potential data repository.

Actually, presence has considerably evolved since the early days when it only supported instant messaging and the IETF suggested to implement it as part of the basic SIP registrar function.

Through multiple extensions to its baseline XML schema, presence can now be considered as an extensive set of static and dynamic information about the user, its devices and its applications. In this context, presence can be seen as an essential repository of user data, that can be used as an enabler by many IMS applications.

In a network in which presence is a basic enabler associated to every user, some data currently considered as user application data, that the user manages service per service, may simply be part of the user's presence. To take a trivial example, presence may eventually make the explicit definition of forwarded-to-numbers for call management services totally irrelevant.

Presence is a specific example of the user-data-in-SIP-AS approach described above.

Generic User Profile (SOAP, XML)

GUP is a 3GPP standard, which is independent from IMS but that can optimally be used with it.

To make it short, GUP permits to define a virtual centralized user database, by enabling an homogeneous and centralized access to distributed user profile components, stored in network databases (e.g. HLR, HSS) and application servers.

The GUP location server is called GUP Server. A client application asks to access user data by providing the identity of the user (e.g. an IMS public identity) and the name of user profile components it wants to access. The GUP server either provides in return the address of the GUP data repository (e.g. an application server) or accesses the data on behalf of the application).

GUP interfaces are based on SOAP and the user data is defined according to a hierarchical XML schema (GUP does not specify the data itself). As GUP aims at supporting Liberty Alliance (set of web services towards 3rd party service providers) within the 3GPP network, GUP interfaces totally align with the Liberty Alliance Project specifications.

The GUP architecture can be compared to the user-data-in-SIP-AS approach in which:

- SOAP replaces SIP/XCAP to access and monitor changes in user data

- The GUP server and its location data plays the role the S-CSCF making use of service profiles endorses with SIP

More especially, the two approaches are able to dispatch a request based on the identity of a target user.

Common Profile Store (LDAP)

Every supplier or operator has its own name for this concept, but CPS is the term under which 3GPP has been addressing it.

CPS originates from a recent telecom industry trend which aims at changing the monolithic nature of network databases (e.g. HLR, HSS, AAA, application servers) into a multi-tiered IT architecture, in which the business logic of the database (e.g. Diameter features of HSS, MAP features from HLR) is physically separated from data storage. An LDAP server supporting telco-grade requirements (e.g. availability, capacity, performance) is shared between stateless business logic frontends implementing a variety of network entities.

CPS permits to optimize and rationalize the architecture of network databases. It also permits to reduce vendor locking achieved through monolithic network databases.

While it does not impose it, CPS also favors a more coherent modeling of user data across the various network databases and application servers, which permits to decrease operating costs and to foster new synergies.

In the context of IMS, CPS would permit to remove the need for a direct interface between the HSS and the HLR (required for Sh) by permitting user data sharing through access to the common backend.

Integration with open service platforms (e.g. J2EE, JAIN SLEE) would permit to use CPS for all applications implemented on these platforms.

So many possibilities... In the next post, I will provide personal opinions on them.

Christophe

Enabling Multimedia Communication

In my first post about multimedia communication, I mentioned three challenges to be addressed by operators. Today, I will write about the very first one: making multimedia communication possible.

As I wrote in the last post, the architectural problem is in the application layer. Monolithic application servers, which can only accept or support one or two media in a SIP sessions, add obstacles, more than value, to the fulfillment of a powerful IMS application layer.

While an option is to bypass the IMS application layer and allow peer to peer multimedia communication between endpoints, it does not permit the operator to add much value compared to a pure Internet alternative (besides core network aspects such as QoS). Neither can the operator have much control on the content of end-to-end sessions. It is therefore required to design an IMS application layer that can support multimedia sessions.

Separation of SIP and Media Control

The approach is straightforward: it is necessary to extract SIP session control logic from monolithic application servers (e.g. push to talk, session-based messaging) and to establish a one to many relationship between this SIP-centric application and the various media manipulation entities. This relationship should be dynamic and depend from the media components that are part of a session at a certain time.

The SIP centric application is implemented on a SIP Application Server. Its functionality differs from the one of an S-CSCF because it supports added-value and/or control features that are not part of a standard S-CSCF. This functionality implies control of media manipulation entities, user-specific features (e.g. preferences, added-value features, controls), as well as possibly HTTP-based interactions with the user(s) (e.g. web pages, XCAP).

In the 3GPP architecture, a SIP Application Server controlling multimedia sessions can be likened to a combined AS/MRFC (Media Resource Function Control), and the media entities to a set of specialized MRFPs (Media Resource Function Processor). This one to many relationship does not exist in the MRFC/MRFP architecture, as the MRF was initially introduced as an entity dedicated to a single media: voice.

The required architecture actually exists in RFC 4353 describing the framework for SIP conferencing (i.e. multiparty sessions). In the RFC, the SIP entity is called focus and the media manipulation ones are called mixers.

Personal and Shared Multimedia Communication Entities

Both the 3GPP MRF and RFC 4353 architectures support multiparty sessions, and more especially the need to mix media from different sources when more than two parties are part of a session. This is what I called a shared service in a previous post, as the conference server provides support to all the participants in the conference. In the remainder of this post, I will use the terms multimedia focus and media mixer for entities related to shared multimedia communication.

There can also be personalized multimedia communication support for each participant of a multimedia session, whether this is a 2-party or a multiparty session. This provides, if needed, individualized control and added value features for each user. The SIP control entity for a user, that I will call personal multimedia controller, is inserted in the SIP session through the service profile (initial filter criteria) associated to the user identity.

As for the shared multimedia communication entities, there is a dynamic one to many relationship between the personal multimedia controller and the entities manipulating the media components, that I will call media intermediaries (as the media passes through the entity, possibly with modification / enrichment). As of now, I have not seen such a personal multimedia support architecture described in a specification.

As a consequence, a multiparty session between John, Mary and Paul may involve one multimedia focus associated to a set of media mixers to support the conference, as well as personal multimedia controllers and media intermediaries for each of John, Mary and Paul.

For a 2-party session between John and Mary, the multimedia focus and media mixers are not necessary.

Tight Media Component Control

A typical pattern that is likely to be used for the most important communication media components (e.g. voice, video, messaging) in a multimedia session is the following.

The multimedia focus or the personal multimedia controller is inserted in the SIP signaling path at the beginning of the session. Then, depending on the media negotiated at the start of the session and re-negotiated during the session, the SIP application inserts / removes media mixers or media intermediaries by placing corresponding IP address / port information in the SDP (session description protocol) part of the SIP INVITE or re-INVITE. The media component therefore appears as a media peer of the user's client in the session.

A control interface permits the SIP application to control the media entity. 3GPP selected H.248 for the interface between the MRFC and the MRFP, but other protocols could be used for other types of media.

This approach has the advantage to be transparent to the client. It also permits a very tight control of the media by the network. In short, the user does not see and cannot prevent application control of the media component in the end-to-end session.

However, this approach is not realistic for all media components, more especially for application related ones (e.g. application sharing, whiteboard, gaming).

Looser Variants

A first variant is that, for a specific media component, there is no media mixer and/or media intermediary inserted in the media path. Media exchanges are performed end-to-end between endpoints. Potential media mixing can be performed by each client which receives media from all the other endpoints. In this approach, the operator does not control the media and does not add any non-core network value to its delivery. This is certainly applicable to a lot of application-specific interactions.

In the case where a media mixer or media intermediary is inserted in the media path, clients may take the responsibility for it, and not the SIP application in the network. The information required for the insertion (e.g. address of the media intermediary or media mixer) may be provided by the SIP application server, or acquired by any other means by the client. If there is a need for session participants to exchange information about media mixers (e.g. a whiteboard server), this can be done either under the control of the application server or not.

The control of the media mixer or media intermediary by the multimedia focus or personal multimedia controller may be tight, relatively loose, or may not exist at all (i.e. the control is purely performed by endpoints).

There might be multiple approaches, as I believe solutions for handling different types of media should be a compromise between control, the possibility to add value, flexibility, and time to market. You may imagine that a given media component is initially supported without any media intermediary/mixer in the network, which are added later when the operator has found ways to add value to the delivery of this particular media or wants greater control on it.

Support in Clients

Multimedia communication also requires relevant support in clients. Besides the ability of client APIs to support generic sessions filled in with any type of media, there is also the need for applications residing on the device to seamlessly be integrated into sessions. User Interface aspects should not be underestimated either, as it is important to support multimedia communication as intuitively as possible for the end user.

Christophe

PS: My apologies for writing "media" everywhere in this post, but I found out that not everybody knows that "media" is the plural for "medium". It hurts me though, as I studied latin during 5 years. In the same vein, the "s" at the end of "Initial Filter Criterias" is not correct as "criteria" is already the plural of "criterion". But this is the way this is written in 3GPP specs.

Status of Multimedia Communication

For me, multimedia communication is one of the three axes around which IMS can revolution telecommunications.

Multimedia communication is a central capability of the SIP protocol as specified by the IETF. It permits to combine and dynamically add, remove or replace any type of communication components (e.g. messaging, voice, video) and application components (e.g. gaming, shared browsing, whiteboard) whithin the same SIP session.

Multimedia communication should not be mixed up with early IMS rich voice services, which aim at adding specific media components to a voice-centric session. There might be - sensitive telecom people please directly jump to the next sentence - multimedia sessions without a voice component from beginning to end. However, voice is likely to remain the privileged way to communicate for long, and therefore one of the main components in multimedia sessions.

In this post I will try to describe the current status of multimedia communication in both existing IMS implementations and in standardization.

Implementations: Devices Can Do It, Application Layer Cannot

In my first post on multimedia communication I identified 3 related challenges for the operator. The first one is to simply enable multimedia communication in an IMS network.

Multimedia session management is a natural peer to peer feature of SIP, and can therefore be easily supported by devices. In the mobile industry, most of the IMS client frameworks I have seen are able to support multimedia sessions.

The IMS core network is not an issue either, as it can support any type of session.

Problems concentrate in the application layer, as early IMS application and media servers are dedicated to the support of single medium sessions, with the medium being voice, video, voice bursts (push to talk over cellular), or messaging.

This implies that as soon as an application server is chained in the signaling path of an IMS session, it is likely that this session can only support a single medium. "Fortunately", current IMS clients are implemented to also support a single medium in a session.

Standardization Overview

ETSI TISPAN seems to essentially see IMS as a new telephony network over IP. In cooperation with 3GPP, the group has been pushing for the standardization of services that simply replicate existing circuit-switched services.

OMA (Open Mobile Alliance) is the main standardization body for IMS services/enablers. This is therefore the main responsible for the extreme silo-ization of early IMS services.

However, this is also from OMA that the light may come through the Converged IP Messaging (CPM) work item. Despite its name (is it to deceive enemies of multimedia communication?) CPM requirements cover the full scope of multimedia communication, both for 2-party and for multiparty sessions. CPM might be THE most important item under specification these days.

By having a look at the contributions for CPM over the past months I have the feeling that this item has been strongly pushed by operators, and that apart from a few exceptions major telco vendors' involvement has been lagging a little bit.

Requirements have been defined, architecture work has just started.

I hesitate to even mention it but 3GPP has an R7 work item called "Multimedia Telephony". For me the terms "multimedia" and "telephony" cannot be associated, as telephony is an old circuit-switched centric concept, and it does not make sense to consider that multimedia communication can be reduced to a telephony service in which voice is replaced by several media components. Not only multimedia communication deals with combining multiple media components in a single session, but it also will totally change the way to communicate, and this new communication paradigm will not be called "telephony".

This said, the name accurately reflects the content of specifications: it might be about multimedia, but it is definitely about telephony. The current multimedia telephony specifications simply define how such services as call waiting, call hold or call barring can be implemented in IMS.

Why is it so Hard?

As usual this is mainly about culture and organizations.

For instance, voice has always been voice and messaging has always been messaging. In legacy networks, these services have nothing in common. They are owned by different organizations within the vendor and operator companies. These organizations do not speak to each other and multimedia communication could even threaten their very existence as separate entities.

OMA is a standardization that used to specify only silo services before IMS services were pushed in by a few companies. The OMA organization is totally fragmented, and the OMA architecture group has never been an overall architecture group, such as WG SA2 is in 3GPP.

There might also be a business issue: as a supplier, is it more interesting to implement and sell, say, 5 silo services, or is it better to integrate all these services in a more coherent and compact architecture?

When is There a Real Risk to Miss the Multimedia Communication Bandwagon?

The first risk is when standardization or a supplier proposes to "enrich" a silo service with one or two more media components, e.g. messaging added to push to talk. An operator may end up having in its network a voice server also supporting messaging, next to a messaging server also supporting voice. Suppliers may be happy to upgrade their silo servers, but the losers will be the operator and the end-user.

Otherwise, if you consider early IMS services for communication...

Voice-centric telephony is not an issue. The service is so important that it will remain for years, more especially as long as the circuit-switched network exists. It therefore makes sense for an operator to deploy IMS for voice telephony. However, as the motivation is usually cost reduction, the operator may prefer to minimize the costs for the IMS telephony application servers and go for cheap black boxes that implement the most important telephony added value services (unless the operator already uses an open platform like JAIN SLEE for IN). Investments for more open platforms can be targeted at multimedia communication and other IMS advanced services.

Push to talk over cellular is not a successful enough service to be an issue.

The real risk for an operator to waste money is for IMS session-based messaging. This chat and instant messaging service is very important, and an investment in a silo implementation may not be future proof.

In a next post, I will address architecture aspects for supporting multimedia communications.

Christophe

SOA & IMS: Same Fight?

Here is an excellent article about the difficulties for the Service Oriented Architecture (SOA) to be adopted in the IT community: Finding the Real Barrier to SOA Adoption.

I defend the idea that SIP and IMS can integrate with and extend SOA by adding user orientation to an approach which is service centric. I already started to describe some architectural aspects of IMS, and the possibility to implement service logic as a distributed set of individual services reusable by others.

This is therefore not a surprise that I can identify within the telecom industry the same types of problem with regards to IMS and SIP, that the author of this article does with SOA and the IT industry.

He states that IT organizations are the first barrier to SOA adoption. I also think that existing telco organizations play such a role for IMS.

SOA permits to solve some complexity issues that IT organizations want to maintain, for the sake of keeping their job. I would liken this to the subdued but real ongoing fight between some of the telco vendors, who want to maintain complexity in the IMS, and IT suppliers, who can help make IMS much simpler for service developers.

SOA forces to think differently, in terms of reusability, architecture, and distribution. This is the same for IMS, which could support a new service architecture, much more distributed and powerful than the legacy ones.

The reference to silos is explicitly linking to the application silos we know in our networks, and that start to be implemented as well on IMS.

The fear of the unknown is also a very common problem in our industry, as people just want to work on topics they have already been addressing for years. Just look at how current SCIM/Service Broker standardization is just a way to keep on working on the old IN service interaction management problem and not to think of what could be beyond voice.

I would add an IMS-specific problem related to SOA: many people in the telecom industry that defend SOA concepts do not want to accept the idea that IMS is more than just another telco network, and that it supports SOA-related concepts as well.

Christophe

Here is my SCIM

I am far from convinced that the SCIM, as it is usually promoted by suppliers, or as it is currently being standardized by 3GPP under the name of Service Broker, is an essential feature for an IMS that does not limit itself to the reimplementation of legacy telephony over IP.

It can be argued that what I am going to describe in this post is not a SCIM. I would prefer to give it another less ambiguous name, such as Service Dispatcher (Service Broker is already taken). The concept was already discussed with a big IT supplier, and may eventually be implemented as part of their service platform.

Personalized Service Chaining

For me, one of the great features of the IMS service architecture is the possibility to chain services on the SIP signalling path and to have this chaining personalized for each user.

IMS service chaining is based on service profiles, stored in the HSS, and associated to IMS Public User Identities (IMPUs). In practice the same service request originated by or addressed to two different IMPUs can be chained totally differently for each of these IMPUs. The two IMPUs may either be associated to different users, or may implement different personas for the same user.

Service chaining can be very interesting for composing IMS services. There might be several cases (see also this post):
- Two chained services may exert control on the same end-to-end SIP transaction or dialogue, without having to be aware of each other. This is for instance the case when a voice call continuity service (VCC) is composed with other session management services. As long as VCC and the other session management features are chained in the right order, end-to-end behavior will remain consistent. In practice, many typical service interaction management use cases can be solved through a proper chaining of services on SIP signalling.
- A service may impact end-to-end signalling with the knowledge of how service logic further down the chain will react to the change.
- A service may initiate new SIP interactions as a consequence of being in the SIP signalling path (e.g. send an IM to a user)
- A service may monitor SIP signalling without any intention to impact it (e.g. a messaging archive).

It is important to note that service chaining on SIP signalling is very interesting, but is not the panacea to address all service composition use cases. More especially, it may need to be complemented with more classical web service orchestration higher up in the service logic.

Need to Complement S-CSCF Service Chaining

I do not support the opinion that the current specification for service profiles (initial filter criterias) and for service chainiing by the S-CSCFare too limited and should be extended to handle more criteria such as time or presence information. I find that the current mechanism is both efficient and reasonably simple. If more advanced mechanisms are necessary, they should be implemented in the IT-centric application layer, possibly in the SCIM.

On the other hand, taken in isolation, S-CSCF -based service chaining is not enough, and it has the following issues:
1) It may lead to a heavy processing by the S-CSCF of SIP interactions with application servers, in addition to the other tasks it already has, i.e. virtually doing everything in the IMS core network (e.g. user registration & authentication, end-to-end SIP routing, generation of charging information, etc).
2) Multiple SIP based interactions between the S-CSCF and application servers may lead to bad end-to-end latency for service delivery. These latency issues may potentially lead the operator to limit service chaining for the sake of service usability.
3) Chaining actually concerns application servers, and not individual services hosted by each of these application servers.

Issues #1 and #2 should be addressed via service co-location. It should be possible for an operator to co-locate on the same server, for a given user, services that are likely to be chained together or that generate other SIP interactions (e.g. presence based service accesses presence).

This requires a change of mindset for service topology from a service centric to a user centric approach. Instead of having a server = service(s) approach in which, for instance, presence is implemented a dedicated server aiming at serving all users, personal services should be deployed as much as possible according to a server = users approach. In this context, presence, which is the prototype personal service, could be implemented as an application co-located with other applications using it as an enabler, on application server instances each serving a subset of the users.

Such a service co-location approach reinforces the need for the adoption of standard and open IT-centric service platforms that I already mentioned.

#3 requires the possibility to chain services together at a finer granularity than the S-CSCF, and to do it inside the application server itself. Service co-location makes this need even more essential.

Main Features of the SCIM

In this context, the SCIM performs in the application server, and at service level, what the S-CSCF does in the network and at application server level. Its role is therefore to select and chain the services that need to be executed when a SIP standalone or initial request reaches the application server.

The SCIM exploits and complements the IMS capability to have a personalized chaining (composition) of services on the signalling path associated to a SIP request. Of course, SIP requests may relate to a large variety of services, and are not limited to telephony or even to session control.

The SIP chaining mechanism of the SCIM is very similar to the one supported by the S-CSCF. The user "service profile" used by the SCIM might have similarities and differences with the initial filter criteria of the service profile used by the S-CSCF. All potential enrichments desired for chaining decisions can be implemented at the SCIM level.

The SCIM is one of the orchestration mechanisms supported by an IMS application server, which is SIP centric. Web Services oriented service orchestration is to be supported by a complementary component of the platform.

The platform is typically implemented as a JAIN SLEE or Java EE (J2EE) server supporting SIP servlets. In the latter case, the SCIM can be implemented as an application router in JSR 289.

Such a SCIM aims at enriching the user oriented nature of the IMS service architecture and at providing a highly customizable and differentiated service experience between IMS users. At the same time, it can fulfill many typical service interaction management use cases that are targeted by service broker standardization.

Other Potential Features for the SCIM

I like the idea of keeping a SCIM well focused and simple enough to be managed. However, the core functionality described above can be extended directly in the SCIM, or through some complementary components added to it.

Here follow some examples.

An IMS application server needs to follow some rules when interacting with the IMS core network. For instance, when a service initiates a SIP request out of the blue, it needs to include relevant information such as a an original ID for the SIP dialogue/transaction or a charging vector, and it may be mandated to route the request to a specific S-CSCF when this request is initiated on behalf of a user. This task may be handled by the SCIM, if it is not by another component or by the application itself.

As part of its service selection and chaining task, the SCIM may forward a SIP message to remote application servers. By doing so it partly takes over the responsibility of the S-CSCF and permits to offload the IMS core network from a part of application layer related SIP interactions.

A remote application server may not comply with IMS extensions to SIP, and may therefore not be able to exploit them (for instance, a non IMS application server may not be able to extract the asserted identity of the request initiator from the 3GPP specific P-Asserted-Identity header). In this case the SCIM may adapt SIP messages between between IMS and the non-IMS application server.

A remote application server may belong to a 3rd party service provider. The SCIM or a complementary component may support policies for interactions with this 3rd party.

The SCIM may possibly translate SIP requests into web service requests or other application-related interfaces.

July 6th 2007 update: I made another post on this subject, with figures.

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

Standardization: SCIM & Service Broker

Here is a first post of a series dedicated to the SCIM concept, which is part of IMS specifications.

In this post, I will describe how the concept was introduced, how it has been handled and actually how it is currently being addressed under a new name: Service Broker.

The SCIM

SCIM stands for "Service Capability Interaction Manager". This entity was first proposed in 3GPP in April 2001, in a contribution made by one of the major telco suppliers.

The purpose of the SCIM was "service capability coordination" (nothing more concrete). The contribution proposed the SCIM as a standalone entity located between the S-CSCF and the IMS application servers. It interfaced with the S-CSCF and the application servers through the same SIP+ reference point (which would later become ISC). Reasons given for its definition as a separate entity from the S-CSCF were that it logically belonged in the application layer and that, unlike the S-CSCF, it would use non standardized data to perform its duties.

This SCIM was clearly derived from the "service interaction management" issue, which is well known in Intelligent Networks, and deals with the coordinated execution of potentially conflictual call control -related services (e.g. call forwarding and call screening). The new IMS entity owed its name to the fact that 3GPP had just decided to standardize "service capabilities" instead of "services".

The contribution caused a little bit of trouble, as service interaction management is considered as a serious matter in telecommunications, and cannot be dismissed like that. However, other vendors did not want to start standardizing a SCIM in 3GPP, maybe because of the complexity of the issue, or because some already felt that IMS was not simply a voice-centric network.

The result was that two of the other vendors proposed to move up the SCIM in the service architecture, and instead of defining it as a standalone entity, they managed to get it located inside of the SIP Application Server. In a standardization body whose role is to standardize boxes and protocols between them, placing a box inside another box is a simple and diplomatic way to kill it from a standardization perspective.

As a consequence, the standardization of the SCIM was limited to a few fluffy sentences in a couple of 3GPP specifications. The SCIM could then be forgotten.

However, years later, as the IMS hype started, some operators started to ask for SCIMs, and some suppliers started to propose something called "SCIM".

It seems that, as the IMS application layer was under-defined, the SCIM became for some the magic box that would answer all the unresolved questions. This is to the point that there exists a Wikipedia entry for it (July 3rd 2007 update: the SCIM definition has been much extended since I originally wrote this post).

The Service Broker

At the begining of 2005, a new work item for 3GPP R7 was defined, which aimed at specifying a service broker in the context of OSA/Parlay, in order to "enable detection and resolution of service interaction". The work item proposal mentioned that the service broker could also support the IMS SCIM, but this was removed from the final version. However, the technical report initiated by 3GPP CT5 (OSA/Parlay) stated that the service broker "should be able of brokering non OSA applications, such as those hosted by a SIP AS and/or legacy services." In clear, the intention was to standardize the SCIM, and to make it part of an OSA/Parlay solution.

As an entity under the control of a group dedicated to OSA/Parlay, the service broker had no chance to be accepted as a SCIM. IMS is standardized by other 3GPP groups, and more especially 3GPP SA2 for its architecture. Some of the companies supporting the service broker therefore proposed to extract it from CT5 and to have it standardized by another group. 3GPP SA2 was reluctant to standardize it (same situation as in 2001 for the SCIM), but was asked to proceed.

The sample use cases given to motivate the need to standardize a service broker for IMS were totally voice-centric, thus clearly positioning the service broker in the same "service interaction management" context as the initial SCIM. I personally found that the use cases were artificial and exhibited a lack of knowledge of how the IMS service architecture works.

Progress on the service broker, documented in TR 23.810 as part of 3GPP R8, has been quite slow until now. At the time I am writing, the content of the TR (version 0.4) is still very high level, and nothing ensures that it will lead to anything concrete. The TR systematically refers to "SIP sessions", and the only example given is totally voice centric (freephone, voice activated dialling, call barring). Different architecture alternatives are given, including one (service broker in AS) which could lead to the conclusion that 3GPP should not further standardize the concept.

I am personally concerned when I see 3GPP devoting so much effort (OK, maybe not that much) to standardize a function without a clear understanding of the problems it is supposed to solve. There already exist parts of 3GPP specifications which are useless, and I would not be surprised if the service broker was also one of these, assuming that the current effort leads to a concrete outcome.

An example of dispensable 3GPP concept is the "subsequent filter criteria". sFCs were introduced at the same time as initial filter criteria (iFCs) and in theory permit an application server to dynamically set filter criteria in the S-CSCF after having been triggered through initial filter criteria. sFCs are the equivalent to dynamic triggers in IN, that permit an IN application to dynamically set new trigger points in the switch. The only problem with subsequent filter criteria is that they do not make sense with the decision to base ISC on SIP, because the concept is incompatible with basic SIP routing mechanisms. Though introduced in 3GPP R5, subsequent filter criteria have never been standardized and are likely to never be. I am citing subsequent filter criteria because the TR for the service broker mentions them (section 5.2), which seems to confirm the IN culture of contributors to the concept.

In the next post I will expose why I do not like ideas usually associated to the SCIM / Service Broker concept.

Christophe

Moving the Frontier between IT and Telco (part 2)

There has been an irresistible trend in the recent years for state-of-the-art IT technologies to find a room in telecommunications network, but so far this has still been relatively contained. I think that IMS can change all this and totally redefine the frontier between the IT and more classical Telco domains.

The IMS architecture clearly distinguishes between two types of SIP servers: core network ones (the CSCFs, the media gateways) which support basic IMS access, control and SIP connectivity, and application servers, which can basically support any SIP-related logic which is not standardized as a core functionality of the network.

I think this definition of an IMS application server by default (i.e. an AS is not a core network entity) might be the most accurate you can find at the moment. For instance, I believe that the 3GPP R7 Voice Call Continuity feature, which permits a voice call to be handed over between IMS and the circuit-switched network, should be considered as a core network feature, even if 3GPP decided to host it on a SIP Application Server.

Though the decision from 3GPP to locate a feature on a SIP application server rather than in the core network might not be considered as the ultimate criterion to draw the line between the IMS core network and application layer, I think that these two layers have fundamental differences, resulting into important implementation alternatives.

Stable vs. Dynamic Servers

An IMS core network entity is heavily standardized, both in terms of behavior and supported interfaces. There is very little room for non-standard extensions of these entities, both due to their role in the architecture, and the need to permit interoperability in a multivendor environment.

On the other hand, the standardization of the application layer is very limited. Some enablers like presence or IMS messaging are standardized (in 3GPP, the IETF, OMA), but this standardization should be seen as a minimal required set of features, that can be extended at will for differentiation. Moreover, the application layer should permit the deployment of applications that are not standardized at all.

If you believe in an IMS that supports innovative services for end-users, you need an application layer made of service platforms supporting applications with very short development cycles, that can be co-located (how many services will you deploy if you need one box for each of them?), and that can evolve very rapidly according to the wishes of end-users. Does this ring an Internet-related bell?

Show me the upper part of the IMS application layer!

The network-centric nature of 3GPP standardization makes that the IMS application layer is essentially specified according to its relationship to the SIP-centric IMS core network. This may give the impression that a "SIP Application Server" is only defined according to its support of SIP. This perception may have been reinforced by the SIP-centric nature of early IMS service platforms. This does not have to be.

For me, the IMS service architecture figure from the 3GPP specifications, which places the S-CSCF at the center, and the application servers at the margin, is like the photograph of a person that would only show the legs. In the context of the IMS application layer, the upper part of the body missing on the picture is SOA and Web Services oriented. It integrates IMS applications in the IT and Web 2.0 domains. To this respect, the Parlay X type of approach, which concentrates on the exposure of telecom services to 3rd parties is only one side of the coin, as IMS applications may as much consume 3rd party services as they can expose some.

I can send my version of the complete IMS application layer photograph to those of the readers interested. Just send an email to me (see my profile). It is in color...

Different SIP Traffic Patterns for Core Network and Application Layer Entities

All IMS SIP signalling for all IMS users goes through the IMS core network entities called CSCFs (more especially the S-CSCF).

If you consider John, the proportion of SIP messages that may originate from his devices or are addressed to him and are processed by an S-CSCF serving him is simple to calculate: 100 %. Similarly, all SIP messages originated or received by IMS application servers have to transit through CSCFs. The IMS core network is the SIP connectivity network, the IMS motorway, without which there is no IMS and no accessible IMS application or IMS client. This motorway is agnostic of the services it enables, and will treat in a similar way SIP messages used to establish a voice session, a gaming session, to access or update presence, to send instant messages, or to program your VCR for tonight's TV program.

This is not the same situation for the application layer. An application server hosts a set of services that may only apply to a subset of IMS users, and to a subset of the SIP signalling associated to these users. Typically, a presence server is only interested in presence-related signalling for the users it supports (the user centric nature of IMS permits to distribute users on several server instances).

You may imagine servers hosting very popular services, inducing a lot of SIP traffic, and others serving more niche services, or which use SIP more marginally than other protocols in their service delivery.

Finally, not all IMS services will have stringent latency requirements, as not all of them will be related to real time person to person communication.

Bottomline, there might be very different requirements in terms of scalability, reliability, and latency between IMS core network and application layer entities.

IT Invasion in the IMS Application Layer!

The way I see it, the IMS core network consisting of CSCFs, the HSS, border and voice gateways, is still a very telco-centric system, being highly standardized, essentially processing signalling, processing this signalling in a very systematic, service independent manner, having to be very scalable, reliable and highly responsive.

On the other hand, the IMS application layer is where innovation has to be introduced, it has to be very dynamic, with advanced interfaces towards end-users, and a deep integration with advanced IT and Internet systems. Requirements on capacity, reliability, latency, may be (slightly or significantly) more relaxed than for core network entities.

My opinion is that the whole IMS application layer should belong to the IT domain, with eventually most if not all applications being implemented on advanced, open, standardized service platforms provided by major IT vendors (e.g. J2EE). Application themselves will be implemented by software companies, including some located in garages.

This is a big difference with the current situation, in which most of the telco application layer is still implemented on closed, telco-specific platforms, and supplied by big telco vendors.

An essential point for me is that the IT domain will start on top of SIP (whether ISC or when the AS acts as a normal SIP enpoint) and not only on top of a web services gateway. IMS applications may equally use Web Services, SIP and other relevant protocols to deliver their goodies to end users, and if IMS can bring something to the Internet and IT communities, this is by introducing SIP as a another generic service control protocol, extending SOA into a User Oriented Architecture (UOA).

Christophe