Fixed Mobile Convergence(s)

The term "fixed mobile convergence" is very ambiguous. In this post, I will try to clarify the concept by distinguishing between different types of convergence and by positioning IMS with regards to them.

Device convergence

This type of convergence essentially relies on the ability of a device to connect to a single or to separate networks using either fixed or mobile access (typically WiFi behind xDSL and GSM/UMTS).

UMA (Universal Mobile Access), also called Generic Access Network (GAN) in 3GPP, is a potential solution for this type of convergence, as it permits to add an IP access to the mobile core network while keeping the higher level signaling stacks, thus enabling standard handover between, e.g. WiFi and cellular access. UMA/GAN requires the support of a dedicated "base station" in the access network to add the new access to the mobile core.

The IMS Voice Call Continuity (VCC) specification supports a similar feature, but this time handover is performed through switching between an IMS core network and the mobile core network. An issue with VCC is that voice services are supported across two different core networks (IMS and the pre-IMS mobile core), which may cause trouble with regards to the execution of value added services that should be unified or at least coherent across the two networks. The 3GPP IMS Centralized Services (ICS) initiative could be a way to address this issue, by locating value added voice services for both IMS and the pre-IMS mobile core network in a single IMS Telephony Application Server (TAS)

Overall, device convergence suffers from the significant hurdle to rely on dual mode devices, with the need for associated market penetration. It may also face technical issues related for instance to the quality of user experience or battery consumption. Note that this is the only type of convergence which relies on the ability of a device to connect to the network through different access types.

Service convergence

Service convergence relies on the support of convergence through service implementation.

Typically, fixed and mobile devices each access their own network through their specific access. A service is then made convergent by an ad hoc implementation permitting the coherent delivery of the service across the different access technologies and devices. This generally implies federation between fixed and mobile identities, the usage of a converged service profile and a consolidation of fixed and mobile OSS/BSS functions in order to deliver a coherent provisioning and a converged bill.

The drawback with this approach is that services have to be made convergent one by one, either by totally service-specific implementations or by the integration with a usually proprietary convergence framework dealing for instance with identity federation and shared fix / mobile service profiles. This type of convergence may be costly to support, difficult to evolve, and may sometimes be limited due to technical issues.

Network convergence

Network convergence relies on the ability of a core network to support different types of devices using different access technologies.

A single IMS core network may for instance support a variety of access technologies among GSM, UMTS, LTE, Femtocells, WiFi, WiMax, xDSL, FTTH, circuit-switched fixed access and cable, and consequently the devices making use of them.

IMS based network convergence requires the ability of the device to connect with IMS, either through native or acquired internal support, through a home gateway or through a network gateway. On the other hand, it does not require the device to support various access technologies (like WiFi and GSM/UMTS).

Taken in isolation, network convergence is essentially a cost reduction feature as it permits to avoid deploying access-specific core networks, thus cutting in the CAPEX and OPEX of the operator. Fixed and mobile devices can still make use of different user identities associated to different service profiles, and providing access to discriminated services or service implementations.

However, network convergence can also be seen as a support facilitating the implementation of service convergence, as it implies the support of the same (IMS) protocols by the devices (or through gateways) as well as a unified access to application servers through the unique core network. IMS-based network convergence can therefore be used to support convergent services in a more cost effective and simplified manner.

Network convergence is currently a strong IMS driver for operators deploying new access technologies (e.g. WiMax, LTE) or targeting specific convergent services (e.g. enterprise FMC, converged messaging) across these new or legacy access technologies.

In addition, IMS-based network convergence can also be seen as a step towards the ultimate goal of user convergence.

User convergence

User convergence relies on the support of a unique converged subscription possibly making use of converged user identities (i.e. user identities shared between fixed and mobile devices). It builds and extends upon network convergence.

In this approach, the operator provisions a unique user profile in the HSS, which may include converged identities, separate fixed and mobile identities if needed, and access specific information like authentication methods and credentials (e.g. UMTS AKA for mobile and SIP digest for fixed).

In the most advanced scenario, the user can concurrently register the same user identity (e.g. sip:john.smith@operator.com) from multiple fixed and mobile devices. The service profile stored in the HSS and associated to the shared identity supports converged access to IMS application servers, which associate a converged user profile to this identity. In this approach, every service deployed on the IMS framework and associated to a converged identity is de facto converged because immediately accessible from various devices using vaious accesses.

SIP requests addressed to the converged identity (e.g. incoming calls, incoming instant messages) can be handled intelligently by the IMS core network (and possibly the application layer) with a panel of strategies ranging from alerting the user or delivering the request (e.g. an IM) on several devices to selecting the most appropriate one according to various criteria such as user preferences, device capabilities and more dynamic information such as presence.

Other interesting features include session mobility (currently worked on in the IETF and 3GPP) permitting to transfer an ongoing session from one device to another, as well as the possibility to deliver the different components of a multimedia session over different devices (CPM requirement), like delivering the video component of a voice/video session to the TV and the voice one to the mobile phone.

I had the opportunity to describe user oriented convergence in a previous post, but I will use this one to demystify prejudices that sometimes exist about it.

First, while IMS can eventually support user convergence, it will not mandate it for all users. An operator implementing a coherent IMS strategy will be able to offer convergent subscriptions while keeping the possibility to offer mobile and fixed specific subscriptions as well (using IMS network convergence in this case). Moreover, even for converged subscriptions, the operator will be able to keep separate fixed and mobile identities if the user wishes it or for access to specific services. This is only a matter of user profile provisioning in network databases.

Second, user convergence does not necessarily mean the impossibility to distinguish between fixed and mobile access for:
- Service discrimination: some services may remain fixed or mobile specific.
- Service implementation discrimination: variants may still exist between the implementations of a service depending on the access used to deliver it.
- Charging discrimination: differentiated fixed and mobile charging may apply as long as users are informed about it, possibly in an interactive manner before service delivery.

The key element permitting to support these differentiations is the fact that all SIP signalling originating from a device includes an identification of the access technology it uses (e.g. UMTS, xDSL). This information can be used for service routing in the network (i.e. definition of initial filter criteria) or within service logic prior to or while delivering the service. A device switching from one access to another during service delivery would inform the network about it, for instance by initiating session re-negotiation, thus permitting the network and services to dynamically adapt to the change.

User convergence will not happen overnight, as it implies, besides the addressing of pending technical issues, major changes related to organizations, processes, business models, OSS and BSS, as well as regulation. However, I cannot imagine that it will never happen, whether this is under the control of operators using IMS or through disruptive players using alternative solutions enabled by all-IP networks.

Conclusion

IMS can support all types of convergence: device convergence, service convergence, network convergence, and user convergence.

Personally, I consider that device convergence and service convergence are of a limited and tactical appeal, due to the limitations and costs they imply. Moreover, to support them, IMS is only a candidate framework among others, which alone may not justify an investment.

The real interest of IMS for fixed mobile convergence appears when network and user convergence are part of the roadmap for the operator. These targets justify the usage of IMS for device and service convergence, as an initial step towards a more ambitious strategy combining both network and user convergence. Network convergence in itself can be used as an intermediate step towards user convergence, which will be a true revolutionary aspect of IMS, together with its ability to support multimedia communication, to combine services and to merge the Internet and telecommunications domains.

Who reads The IMS Lantern?

As a complement to my latest post on IMS deployments, I think that an analysis of the audience of The IMS Lantern can provide interesting insights about the IMS community all over the world.

Since June 2007, this blog generated over 41,000 visits from 132 countries.

Worldwide audience

From a continental perspective, Europe accounts for half of the traffic and generated more than twice as many visits as the Americas and Asia, which are head to head.

However, the USA are, by a large margin, the country which tops the others in terms of traffic.

Here are the top 20 countries:

1.	United States
2.	France
3.	India
4.	Germany
5.	United Kingdom
6.	Sweden
7.	Canada
8.	Spain
9.	South Korea
10.	Switzerland
11.	Italy
12.	Netherlands
13.	Japan
14.	Slovenia
15.	Israel
16.	China
17.	Singapore
18.	Taiwan
19.	Austria

Companies

Visits come from three main types of companies:

- Big network equipment vendors including those leading on the IMS market, but not only.

- Operators, mainly from the USA, Canada, France, Spain, Germany, South Korea, Japan and Australia.

- Application service suppliers, with a huge domination from India.

However, a significant part of the traffic is also generated by smaller vendors providing equipments, services or OSS/BSS systems, by suppliers of service platforms, and by research centers, engineering schools and universities.

Subjects of interest

Visitors are mainly interested in posts describing technical details about the IMS service architecture, IMS identities, the SCIM, and IMS data management. This may hint at a deficiency in the way the literature, courses and IMS specifications address these topics.

Just behind come posts dedicated to the innovative features of SIP and the IMS service architecture, like the User Oriented Architecture (UOA), fixed mobile convergence, multimedia SIP sessions and CPM, and the various service patterns I had the opportunity to describe. I am personally very happy to see that CPM, which is by far the most ambitious IMS standardization initiative, attracts a lot of curiosity and is often entered as a keyword in search engines. Moreover, the post dedicated to it is the one visitors spend the most time on. Another source of more personal satisfaction is to see that the concept of User Oriented Architecture that I associated to the IMS has started to spread outside of the blog, even if it is far from having reached mainstream acceptance yet.

The IMS Lantern therefore seems to be accessed as both an educational and thought-provoking resource on the IMS.

Sources of traffic

Visits mainly come from search engines with IMS-related queries and from people who regularly visit the blog or get notified about new posts.

A smaller portion of the traffic comes from links on other sites (mainly blogs addressing telecom or technological topics). I have done very little to advertise The IMS Lantern on the Internet, but do not hesitate to link to it if you have the opportunity to do so.

Influence

Does The IMS Lantern have an influence on the work of some people or companies in the industry?

I know from direct contacts and some references visible on the Internet that The IMS Lantern has influenced research activities, the writing of theses, articles and even a book that will be published in the coming months.

It is a great source of motivation for me to learn that others can benefit from what I am writing and I have no problem with the reuse of ideas and information I am providing through this blog. So don't be shy: if this blog has a direct or indirect influence on what you are doing, just let me know.

A List of IMS Deployments

While I was doing research for this post, I stumbled upon a March announcement which provides an ideal introduction to it.

Infonetics Research issued a 2008 4th quarter report claiming that:
- Worldwide sales of IMS equipment nearly doubled in 2008 over 2007, up 94%
- Unlike many other markets during the worldwide economic crisis, the IMS equipment market is expected to grow in 2009 and 2010
- Infonetics’ IMS Deployment Tracker shows Ericsson, Alcatel Lucent, Nokia Siemens (NSN), NEC, and Huawei leading the way with core IMS equipment

In this post, I am trying to list done or ongoing deployments of IMS core networks all over the world. This list is based on publicly available contracts announcements and, in case I was not able to find such material, public evidence or strong hints that such deployments were at least under way. When available, I mention the date of the contract, the supplier of the core network, and the intended focus of the deployment, at least in its initial phase. Otherwise, question marks replace the information.

My intention is to maintain this list over time, based on new annoucements as well as the additions or corrections you might be able to give to me by email (cgourraud at yahoo.ca) or by posting a comment. For instance, in many cases, a press release relates to a contract signed at a group level or for a specific country for service providers operating over several ones, and any precision on the actual country(ies) targeted for deployment would be useful.

I hope this list can be of interest to you. The idea came to me from recurent requests to provide information of IMS deployments in Europe, North America and Asia.

Europe

Armenia
ArmenTel: 8/2008, Ericsson, Fixed Network -> FMC

Austria
Mobilkom: 1/2009, Nortel, Mobile network

Azerbaidjan
Delta Telecom: 9/2008, Alcatel Lucent, WiMax network

Belgium
Belgacom: 4/2008, Alcatel Lucent, Fixed network

Bulgaria
Vivatel: 11/2008, NSN, Mobile network

Cyprus
CYTA: 12/2006, Ericsson, FMC

Czech Republic
Eurotel: 12/2005, NSN, Mobile network
Vodafone: 9/2007, Ericsson, Enterprise FMC

Denmark
TDC: 6/2005, Ericsson, Enterprise

Estonia
Elion: 9/2006, Ericsson, Fixed network

France
Bouygues Telecom: ?, ?, RCS
France Telecom/Orange: ?, ?, RCS
Hub Telecom: 11/2008, Alcatel Lucent, Enterprise FMC
SFR: ?, ?, RCS

Germany
Arcor: ?, ?, ?
Deutsche Telekom: ?, in-house solution?, ?
T-Mobile: ?, ?, RCS
Vodafone: 7/2007, Ericsson, Consumer & Enterprise

Greece
Hella Online: 1/2008, Ericsson, Fixed network

Greenland
Tele Greenland: 1/2008, Ericsson, FMC

Hungary
Magyar Telekom: 7/2006, Huawei, FMC
T-Mobile & T-Com: 7/2006, Huawei, Mobile network / FMC

Ireland
O2 Ireland: 8/2006, Ericsson, Mobile network
Vodafone: 7/2008, Ericsson, Mobile network

Italy
Telecom Italia: 2/2005, Ericsson, Fixed network
Telecom Italia Mobile: 2005, Ericsson?, RCS
Wind Telecomunicazioni: ?, ?, RCS

Netherlands
KPN: 9/2006, Alcatel Lucent, Fixed PSTN replacement

Poland
Exatel: 10/2007, Alcatel Lucent, Fixed network
Netia: 9/2005, Alcatel Lucent, Fixed network / Enterprise services
Telekomunikacja Polska: 3/2007, Ericsson, FMC

Portugal
Optimus: 3/2006, Ericsson, Mobile network
Portugal Telecom: ?, 2007?, FMC / PSTN replacement
Sonaecom: 7/2008, Ericsson, Fixed network/IPTV
TMN: 6/2005, NSN, RCS
Vodafone: 7/2007, Ericsson, FMC

Russia
Comstar: planned in 2009, to be selected, fixed network / PSTN replacement
Sibirtelecom: 6/2006, Nortel, ?

Spain
Telefonica: 4/2005, Ericsson, Fixed network
Telefonica/O2: ?, ?, RCS

Sweden
Com Hem: 6/2007, NSN, Fixed network
Telenor: 7/2007, Ericsson, Enterprise FMC
TeliaSonera: 5/2007, NSN, FMC?

Switzerland
Swisscom: 2/2007, Ericsson, FMC

Turkey
Turkcell: ?, ?, Mobile network / FMC

UK
BT: 4/2005, Ericsson?, Fixed PSTN replacement

North America

Canada
Bell Canada: ?, ?, FMC
Rogers Cantel: ?, ?, ?

USA
AT&T: 10/2005, Alcatel Lucent, Mobile network
Bellsouth - now AT&T (USA): 11/2005, Alcatel Lucent, Fixed network
Cox Communications: 2007?, ?, Cable network
Sprint Nextel: ?, ?, FMC
SureWest Communications: 4/2008, Alcatel Lucent, Fixed network
TerreStar Networks: 7/2007, Alcatel Lucent, Satellite and Cellular convergence
Time Warner Cable: 4/2009, NSN, Cable network
Verizon Communications: 3/2007 - 2/2008, Alcatel Lucent & NSN , Mobile network/PSTN network replacement/FMC

South America

Brazil
Brasil Telecom: 5/2008, Ericsson, Mobile network


Asia & Oceania

Australia
Commander Communications: 9/2005, Ericsson, Fixed network
Telstra: ?, Alcatel Lucent?, ?

China
Beijing Netcom: 4/2007, Ericsson, Fixed network
China Mobile: ?, ?, RCS
China Netcom: ?, Alcatel Lucent?, ?
China Unicom: 7/2007, Alcatel Lucent, Mobile network
Fujian Telecom: 12/2006, NSN, FMC

Hong Kong
NWT: 7/2006, Alcatel Lucent, Fixed network
SmarTone-Vodafone: 4/2008, Ericsson, Mobile network

Indonesia
Telkomsel: 8/2006, NSN, Mobile network

Japan
KDDI: 1/2006, NEC, RCS
NTT: ?, ?, ?
Softbank Mobile: 12/2006, Ericsson, Mobile network
Softbank Mobile: 9/2008, NEC, Femtocells network

Malaysia
Celcom: 7/2006, NSN, Mobile network

Philippines
Globe Telecom: 9/2006, NSN, FMC

South Korea
KTF: ?, ?, RCS
SK Telecom: 2005 or 2006, ?, FMC/RCS

Taiwan
Chungwa Telecom: 12/2007, NSN, Fixed network
FarEasTone: 9/2006, Ericsson, Mobile network

Vietnam
Saigon Postel Telecommunication: 11/2006, Ericsson, Fixed network

Middle East & Africa

Bahrain
Mena Telecom: 8/2007, Motorola, WiMax network

Pakistan
Wateen Telecom: 5/2006, Motorola, Fixed network

South Africa
Telkom: 2008?, ?, ?

Uganda
Warid Group: 10/2007, Huawei, Mobile/WiMax network

Defining an IMS Strategy

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

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

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

Deploying IMS

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

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

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

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

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

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

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

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

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

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

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

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

The Future of Telephony

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

Basically, IMS permits to:

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

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

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

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

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

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

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

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

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

- Reusing legacy Intelligent Network solution(s) in IMS

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

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

The future of messaging

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

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

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

IMS as a multi-service platform

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

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

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

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

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

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

IMS for new services

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

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

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

IMS for a new user experience

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

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

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

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

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

Managing the complexity of the IMS application layer

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

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

There are basically two composition mechanisms:

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

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

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

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

Optimizing the IMS application layer

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

These optimization issues may for instance relate to:

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

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

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

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

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

Service Platforms

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

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

- A black box delivered by a service supplier.

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

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

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

IMS clients and devices

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

The operator must address such key issues like:

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

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

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

- Optimizing device management by using IMS-intrinsic benefits.

- Spreading IMS support in the wider range of devices.

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

Conclusion

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

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

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

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

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

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

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

Christophe

The Service Broker / SCIM market

The concepts of SCIM or Service Broker were introduced in 3GPP IMS specifications, but so far have never been adequately defined (I had the opportunity to address this topic several times).

However, this does not mean that there are no SCIM or Service Broker products (or product components) on the market!

Light Reading has just issued a report called Combining Telco Services: The Network Service Broker Opportunity. As they provide a list of vendors they have surveyed for their report, I decided to have a look at what these companies actually provide by looking at documentation available on their web sites. In this post I will summarize my findings, which are only based on my (potentially erroneous or biased) interpretation of usually high level product descriptions.

Call Control / IN Centric Service Broker / SCIM

Most of these products are presented as equally applicable to Intelligent Networks and IMS, which in some cases might mean that the product is an Intelligent Network one that has been upgraded to support SIP, or that the supplier hopes that what is good for IN will also be good for (telephony-centric) IMS.

As described by Aepona, their Service Broker is primarily a proxy Service Switching Function (SSF) between the switch and multiple IN servers (thus permitting service invocation in multiple servers, what a switch is usually unable to do). As an IMS "SCIM", it performs a similar function between the S-CSCF and multiple ASs. Because of its dual SIP/IN nature, the Service Broker can also serve as a gateway between IMS and IN (the "IM SSF" entity in 3GPP IMS specifications).

The description of the AppTrigger's Ignite Application Session Controller (ASC) includes a "SCIM+". Like Aepona's Service Broker, ASC sits between the network and the "application cloud". IMS is explicitly listed along legacy TDM networks that can appear below the ACS, but the figure on the web page does not show IMS at all, only entities of a fixed IP access network. The product supports Parlay X, MAP/CAMEL and SIP. It also supports SIP to IN interworking (IM SSF).

OpenCloud is the supplier of a JAIN SLEE platform, a standardized Java service execution platform that was initially targeted at new generation IN services (IN services implemented in Java on an open platform and possibly using non-call related service capabilities like location or SMS as part of their logic). Such a platform can also support SIP and Diameter interfaces and can therefore be positioned as a SIP AS platform as well. On their page, Opencloud speak about a Service Interaction SLEE (SIS) for IN, and another one for IMS. The SIS supports service interaction and composition. The SIS can also offload an IN server by supporting some IN logic itself (logic as it is based on an IN service platform).

jNetX is another supplier of a JAIN SLEE platform. I was not able to find any information about a SCIM or Service Broker on their site, but if they have one it is very likely to be similar to what Aepona, AppTrigger and Opencloud offer.

I could not find a precise description of Tekelec's TekSCIM Service Mediator. However, as it is supposed to provide a seamless experience to TDM and IMS users, and its IMS role is to manage and simplify complex service interactions, I assume this is more or less the same type of product.

These products often have a clear interest in a TDM IN context, and I think this should be the primary reason why an operator might be interested in them. On the other hand, I am more doubtful about their value in an IMS context, even for the support of telephony services, and this for the following reasons:

- An IMS S-CSCF has the capability to chain several ASs in SIP signalling, so such a feature supported by a SCIM/SB would be functionally redundant.

- Call control Service Interaction Management is an important issue that has never been addressed in a satisfactory generic manner in IN networks, more especially when implemented in a standalone box outside of application servers. Why would this change now and more especially in an IMS context?

- Unless it is used to emulate the TDM network, IMS is a very different type of network, and SIP has nothing to do with INAP or CAP. What is good and necessary for TDM is not obviously good and necessary in IMS.

- Providing added value call control services in IMS is necessary, but it is not what operators will make money with. A SCIM/SB centered around voice-centric call control is by no means the magic box that will solve all operators' IMS related problems.

- The interest of an IM SSF function is questionable. IN platforms are often old and costly, and operators often have to fully rely on the supplier of the platform for developing new services. Is it interesting for operators to extend the life of these platforms for many years by positioning them in their long term IMS strategy? On the contrary, many would prefer to replace their IN servers by new application servers able to control TDM calls as well as IMS ones, and this is exactly what the ongoing 3GPP IMS Centralized Services (ICS) initiative is trying to achieve.

TCAP / Web Services Gateway

Convergin's Accolade WCS SCIM seems to be a gateway supporting translation between TCAP and web services. It is not clear to me if this is only this and if it is limited to TCAP (leaving the task of supporting CAP, MAP or INAP to the application) or if it also supports a direct translation of these protocols to web services.

The first thing to say is that this does not correspond at all to what someone can expect from a product called "SCIM".

The second thing to say is that, whether the name is appropriate or not, this component can be very interesting in an IMS context, when it is associated to an IP-centric service platform, which lacks native support of legacy SS7-based protocols to access legacy service capabilities in the TDM network. This is typically the case of J2EE platforms supporting SIP servlets for IMS, which are offered by well known companies like IBM, Oracle or Sun.

These platforms are ideal to implement innovative IMS applications which can combine usage of SIP, HTTP, Diameter and web services, thus permitting convergence between the Internet, Enterprise IT and the new Telco domains. So far, the lacking capability has been the possibility to conveniently connect with the legacy TDM telco world (OSA/Parlay gateways have not proved to be simple and cost effective enough).

I do not think that such a product would allow a J2EE server to become a suitable platform to implement classical IN services. On the other hand, they could permit to implement new TDM-centric services that make use of IMS enablers like presence or instant messaging, or IMS-centric services that need to use TDM capabilities like starting a pure TDM call.

Consequently, this is not a surprise if Convergin seems to be in business with the J2EE suppliers I mentioned.

SIP-level Orchestration Engine

This is the approach adopted by suppliers of J2EE platforms (IBM, Oracle/BEA, Sun?), which usually clearly distinguish between the need to orchestrate web services, using a standard like BPEL, and the need to orchestrate services invoked through SIP requests. Differences may lie in both semantical and performance aspects.

In this context, the SCIM/SB corresponds to the concept of application router, defined in JSR 289, the latest SIP servlets specification. The original mechanism specified for invoking SIP servlet applications, based on servlet mapping rules that are quite similar to web servlet mapping rules in the fact that they rely on a quite simplistic analysis of incoming SIP messages, has proved to be inadequate for a proper selection and composition of IMS services hosted by a J2EE platform. The application router permits to replace the servlet mapping rules by an intelligent component tailored to the needs of the operator.

The intelligence itself is not standardized, and this is therefore an important differentiation area for suppliers or for operators who may decide to specify and possibly implement their own application router.

The service invocation and chaining logic may take into account subscription information (which services the user is subscribed to) as well as other information related to the user, such as presence, service preferences (e.g. the user wants this service to be executed at certain times) or calendar information.There might also be more or less sophisticated rules related to the composition of services.

The ideas for a SCIM I exposed on this blog fit in this context, with the concern to remain as simple as possible and avoid too much intelligence, complexity and processing delays in this component. I think that the suppliers of J2EE platforms are trying to offer the possibility for more sophisticated rules, adding both more potential and more risks to the concept.

Global Orchestration Engine

This seems to be the case for the Alcatel-Lucent Service Broker, implemented by Bell Labs, which is part of the Alcatel Lucent Service Delivery Platform (SDP). The component supports both SIP and web services interfaces, and examples given illustrate access to user subscription information, service preferences, presence, as well as access to other services like IPTV through web services.*

This Service Broker therefore seems to be an integrated equivalent to the combination of a web services orchestration engine and a SIP application dispatcher as proposed by J2EE suppliers.

A potential reason for this difference is that Alcatel Lucent provide their own SIP servlets container, which is a standalone component that needs to be integrated with a third party J2EE platform for converged services. The service broker would therefore permit integration with J2EE web containers (integration which is much tighter in J2EE platforms supporting both web and SIP servlets) and would transfer web services orchestration to the Alcatel Lucent SIP-centric component as well.

Such an approach might offer advantages, more especially in terms of performance, but could also come with associated complexity, a lack of compliance to web services orchestration standards, and the gain obtained through a tighter integration of different orchestrations may also lead to less flexibility for the operator. However, this would be an aspect to investigate.

Service Management Mediation

Leapstone's CCE ServiceBroker is a tool that applies both to legacy networks and IMS. It aims at making easier the management and provisioning of packaged services, including subscriber management and live management of composition and interaction rules between blended services.

From an IMS perspective, this means that the operator may use serviceBroker to define service composition rules and to generate appropriate data for an HSS (Initial Filter Criteria) and a SCIM, as well as for other network databases.

As such, ServiceBroker appears to be a management complement associated to what is usually called a SCIM or Service Broker. More generally, this is a service and subscriber management mediation tool as can already be found on the
market, but enriched with IMS-specific service composition requirements.

Such a tool is very important but also requires ad-hoc adaptations in order to fit in specific environments, considering that management interfaces are usually vendor-specific. Concerning the SCIM/SB, this is even worse as this component is not standardized and leaves room for very different implementations, as can be seen in this post.

Other SCIMs / Service Brokers

Considering the list provided by Light Reading, I was not able to find anything about the Ericsson and Huawei implementations of the concept.

Conclusions

The concept of SCIM / Service Broker, which is part of IMS specifications but has never been specified, leaves room to multiple interpretations and very different products claiming this label can be found on the market.

You can basically find two mainstream interpretations:

- The SCIM / SB is a standalone component that takes care of classical call control and IN issues related to the support of multiple application servers and complex interactions between call control services. The concept is primarily aimed at legacy networks and is also promoted as being equally applicable (and important) for IMS. The telephony context is clear and while everyone can have its own opinion on the interest of such a product for IMS, I will assume that no-one can seriously claim that this component will help an operator finding new sources of revenue with IMS (the key term here is "leveraging", applied to TDM and IMS in the context of telephony).

- The SCIM / SB is a component part of a service delivery platform, and its aim is to complement what the IMS core network component called S-CSCF can do for the composition and "blending" of several services. Such a SCIM / SB can be specialized in SIP-level orchestration (a dedicated engine will do the equivalent for web services) or can address both SIP and web services orchestration.

The first interpretation is closer to the initial motivation for introducing the concept in 3GPP specifications, while the second is closer to what the real IMS need actually is.

A major architecture difference between the two interpretations is that the first one is a standalone product standing between the IMS core network and application servers, while the second is an added-value component of a more comprehensive product usually called service delivery platform in the telecom context (an application server in its own right).

The description I made of a SCIM on this blog is essentially one of the second category. However, since then I thought a little bit about what a standalone SCIM / SB could be, in the terms of which value it could provide to a SCIM / SB embedded in a service platform can do.

I cannot divulge here the content of these thoughts, as they are being discussed with a customer company of Arismore, but to make it short I think there is a lot of added-value a standalone SCIM / Service Broker could add to a service platform -embedded one, while being very different from what the market has to offer right now. More especially, such a product would have no relationship to IN and call control.

If you are knowledgeable in some of the products I surveyed in this post, do not hesitate to contact me in order to correct or complement it. I will gladly compile and post feedbacks, including those that make a point against my assertions.

Christophe

Course on the IMS Application Layer

Through my company Arismore, I am offering a 2-day course on the IMS application layer. It can be delivered either in French or in English (all the material is in English). There are sessions regularly organized in my company's premises in Saint-Cloud, Paris, France, which are open to individuals. The course can also be delivered on site, within or outside Europe.

What makes this course unique is that, while others usually provide a litteral description of IMS specifications and essentially concentrate on the IMS core network, largely overlooking the IMS service architecture, sometimes even delivering misleading information, this one totally concentrates on this domain in which resides the true potential of IMS for differentiation and revenue generation (both for operators and suppliers). You can take this course after a regular IMS one, but my experience shows that even IMS novices can follow it without missing any core network background.

The course does not only describe IMS application-related specifications that span multiple standardization organizations (3GPP, the IETF, OMA, ETSI TISPAN). It also helps understanding what lies behind them, by providing revealing insights on how they were produced (e.g. historical timeline, assumptions, mistakes, conflicts between companies, need to address specific issues), shows in details how they effectively work, explains how they can optimally be exploited to deliver innovative services or innovatively deliver existing ones, and finally addresses the main opportunities and challenges that IMS brings to the industry. After this course, the student can understand what IMS can deliver, why there exist so many conflicting perceptions of IMS, and why IMS is as much a challenge as a promise.

Several on site sessions have been given or are planned in the near future, and the response has been so positive that these sessions usually lead to discussions about further collaboration between the customer company and Arismore.

Contact me at cgourraud@yahoo.ca if you are interested in either an on site session or in a session organized in our offices in Paris (planned dates can be found in the side bar of the blog).

Here follows a description of the course. You can also request from me a slightly more detailed powerpoint content description.

Part 1: The IMS Service Architecture

This is the most comprehensive part of the course. It addresses several objectives: understanding how the IMS service architecture works (dynamic view), getting an overview of the specifications (static view), understanding the drivers behind standardization decisions (motivations, design by accident, pending issues), understanding how the architecture can be used (application layer architecture, service patterns).

Standardized topics include:
- Overview of the architecture
- IMPUs & PSIs
- ISC usage scenarios & examples
- Details of ISC
- Service profiles and initial filter criterias (iFCs)
- OSA SCS / IM SSF / SIP AS
- MRFC/MRFP
- SCIM & Service Broker
- IMS Communication Services
- User Data Management (Sh, OMA XDM, GUP)

The service features of SIP are treated as a specific topic. It highlights the potential of the protocol when used in IMS or in other networks:
- Multimedia sessions
- Event packages
- Routing alternatives (SIP forking, callee capabilities/caller preferences), GRUUs)
- Support of Group Services
- Combination with other protocols (content indirection, SIP REFER, SIP session, body in SIP message)
- Interoperability aspects (between SIP profiles, between SIP and other protocols)

Service oriented features specific to the IMS service architecture, and complementing the intrinsic SIP ones are also detailed. This part permits to understand the value IMS adds on other SIP-based networks:
- Service composition
- Logic mutualization
- Personalization / Differentiation of user experience
- Simple access to services
- Service flexibility / agility
- Authorization to services
- Unlimited service scalability
- Multi-vendorship / Differentiation for each service
- Service anthropomorphism
- Usage of a single identity for multiple services

Part 2: IMS standardized services and enablers

This part covers IMS services and enablers standardized or under standardization in 3GPP, OMA and ETSI TISPAN. As for Part 1, background information about the standardization process is given.

User data services & enablers:
- Presence (IETF, 3GPP, OMA specifications)
- Group Management / Group Services

Voice oriented services & enablers:
OMA Push To Talk Over Cellular (Poc) V1 and V2
3GPP Combining circuit-switched and IMS services (CSI)
3GPP Voice Call Continuity (VCC)
3GPP/TISPAN Multimedia Telephony (MMTel)
3GPP IMS Centralized Services (ICS)
3GPP Conferencing

Messaging services & enablers:
OMA SIP Push
Messaging (IETF IM, 3GPP IMS Messaging, OMA SIMPLE IM)
3GPP SMS over generic IP access
OMA Converged IP Messaging (CPM) - Messaging part

Multimedia services & enablers:
OMA Converged IP Messaging (CPM) - Multimedia part
TISPAN IPTV

This part ends with a description of the Rich Communication Suite (RCS) initiative

Part 3: Opportunities & Challenges

This final part addresses essential topics which go beyond IMS specifications.

It is structured around the following topics:
- Fixed Mobile Convergence (from technical to user oriented convergence: opportunities and challenges)
- Which role(s) for the operators (e.g. bitpipe provider, intelligent pipe/channel provider, service provider with more or less control)
- Exploiting IMS Capabilities (e.g. User Oriented Architecture, Distributed Service Architecture, need for optimizing the IMS service architecture)
- Service Platforms (e.g. black boxes vs. open platforms, JAIN SLEE, J2EE)
- IMS as a service integration framework (different types of IMS services, how to integrate non-IMS services into IMS, relationship to 3rd party service providers)

Christophe

3GPP Communication Services

In the past, I had the opportunity to write three posts (here and there and there) about the 3GPP concept of Communication Service. These posts were written in the heat of possibly major IMS-defining decisions being taken, in order to warn about some risks related to some options. Time has passed and the concept is now (nearly totally) specified in IMS. In this post I will describe Communication Services and how they can be used by operators.

Definition

According to TS 23.228, "an IMS communication service is a type of communication defined by a service definition that specifies the rules and procedures and allowed medias for a specific type of communication and that utilises the IMS enablers."

Examples of Communication Services are OMA Push To Talk over Cellular (PoC) or OMA SIMPLE Instant Messaging (also called IMS Messaging in 3GPP specifications).

In other words a Communication Service is a set of communication media and the rules that govern the possible (i.e. permitted) transactions between them. For instance, OMA SIMPLE Instant Messaging only permits SIP sessions to include messaging components. Trying to upgrade a messaging session into a voice session is not part of the OMA SIMPLE IM service, and can be considered as a violation of the OMA SIMPLE IM Communication Service.

A Communication Service is identified in SIP signalling through an IMS Communication Service Identifier (ICSI). The format as well as an example of ICSI can be found in TS 24.229:urn-xxx:3gpp-service.ims.icsi.mmtel (Multimedia Telephony).

An IMS application can use a Communication Service to be delivered to the end-user. For instance, an application could push content to a user by using the OMA SIMPLE IM Communication Service. Such an application can be identified in SIP signalling through an IMS Application Reference Identifier (IARI) for which TS 24.229 also provides an example: g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-application.ims.iari.game-v1". Note that IARIs are only meaningful for IMS clients and are totally ignored by IMS core network entities. This is why I will not mention them much in the following.

The list of Communication Services associated to a user is provisioned in the service profile of the user in the HSS. This list is used by the S-CSCF for its processing of SIP requests. It is also provisioned in IMS clients for usage.

The IETF draft describing the necessary SIP extensions to support the concept of Communication Service states that all the information required for a network to understand the service requested by a user should be derivable from the SIP request (e.g. by looking at the SDP and the request-uri in a SIP INVITE), without the need for an explicit identifier like an ICSI. It accordingly states that the ICSI is a way for the network to save computational resources required to inspect the SIP request. I would tend to disagree with this analysis. First, the ICSI does not only define how a user wants to start the session, it also explicitly defines that the user will not try or may not be allowed to later renegotiate the session in a way that is not specified by the service definition. Moreover, an IMS S-CSCF will not make the economy of analyzing the request, as it will have to ensure that the ICSI and both the initial and subsequent INVITEs in the session are coherent one with the others. Therefore, the usage of Communication Services will rather increase the need for computational resources in the S-CSCF than lower it.

What Communication Services could have been

The company which introduced the concept of Communication Service in 3GPP had a quite radical proposal of how it would be used:
- The usage of a Communication Service would have been mandatory in all SIP requests initiated by an IMS client. A side-effect was that all IMS applications would have had to rely on a Communication Service, thus strongly limiting opportunities for IMS services.
- Two SIP clients would not have been able to set up a session together if they did not share the same Communication Service. This would have implied that a client supporting OMA SIMPLE IM and a client able to support both messaging and voice within the same SIP session would not be able to establish a session together, even if they shared a common media component permitting to communicate. This would also have implied that a SIP client without any knowledge of IMS-specific ICSIs would not have been able to set up sessions with an IMS client.
- Usage of Communication Services totally relied on the IETF-specified Contact and Accept-Contact headers (in which ICSIs and IARIs would have been included as media feature tags), thus using a standard IETF header in a non-standard way and adding to interoperability issues with non-IMS SIP clients.

Would have they been accepted, these proposals would have raised important barriers to service innovation in the IMS domain, and would have caused huge interoperability problems between IMS and non-IMS clients, de facto creating a walled garden out of IMS.

A side effect is that the concept would have created a two-tiered IMS application layer, with application servers supporting (standardized) Communication Services at the bottom, and application servers supporting applications making use of Communication Services at the top. The lower tier would typically have consisted of standardized services implemented as black boxes supplied by classical network equipment suppliers, and the (rather power-less) upper tier by open platforms provided by IT suppliers (more or less what you can find in a pre-IMS telecommunications network, with OSA/Parlay usually defining the frontier between the two layers). This two-tiered architecture would have been reproduced within IMS clients.

However, in their current state, due to the involvement of the IETF and the consensus imposed by companies which did not endorse this original view, 3GPP specifications are quite far from this.

General benefits of Communication Services

Communication Services can be useful to all operators, even if their strategies clearly differ, as long as each operator has options about how it wants to use them. Representing an operator, I had in the past the opportunity to discuss the issue with the supplier promoting the concept. After expressing my concerns about it and hearing their arguments in its favor, I told them: "Communication Services are fine with me as long as, as an operator, I can use them when I see an interest for it and not use them when I do not see any". Since then, this possibility to use Communication Services a la carte is what has been specified.

These usage options start at the IMS client, which may but is not mandated to insert an ICSI (and possibly IARI) in a SIP request it generates. They also exist further in the processing of SIP signalling by the IMS core network, as you will see below.

But first, let us consider the aspects of Communication Services that may appeal to all operators.

Communication Services can make the life of operators easier in some aspects.

Put a label on a service, transport this label end-to-end in SIP signalling, and you get a practical handle for charging (more especially when several operators and/or transit network suppliers are involved in the end-to-end communication), QoS and policy control, and to set your initial filter criteria for involving ASs supporting the service. However, this does not mean that the IMS core network should ease on its processing. For instance, current IMS specifications permit to charge a session based on both accounting information related to SIP signalling (e.g. this is a messaging session with a beginning and an end) and media level information (e.g. this is indeed messaging that goes through). It would be risky for an operator to assume that because an ICSI states that the session is about messaging and messaging only, this is actually the case. If so, Communication Services could be a great weapon for fraud.

The usage of ICSIs in users' service profiles to determine the routing to application servers can be of great interest as I will illustrate now. Imagine that an IMS client initiates an INVITE for messaging while the operator has deployed OMA IM SIMPLE, OMA CPM and OMA PoC V2, which all may start with such an INVITE. The operator may face the tricky challenge to decide to which application server the request should be routed in the case where the user is subscribed to at least two of these services. By placing an ICSI identifying the service it wants to use, the IMS client indicates to the network that this is this service and not this one that it intends to use.

Passed these basic, different handling of communication services are possible, which map to different strategies.

The two sections below describe these potential differences. What is common between both is that an IMS client may insert an ICSI in a SIP request it generates, but this is not a mandatory standard procedure. When a client wants to use a communication service (and possibly a specific application making use of it), it inserts the ICSI in a header called P-Preferred-Service. It may also include the ICSI and IARI in Accept-Contact headers (currently 3GPP is not clear about the exact procedure for this).

Communication Services for advanced user control

The S-CSCF serving a user (the originating one for requests initiated by the user, the terminating one for requests received by the user) may be mandated to insert an ICSI in all the requests it receives. For doing so, it compares the request with the list of ICSIs provisioned in the user's service profile for a match. This ICSI is inserted in a P-Asserted-Service header created by the S-CSCF. In the case where the IMS client created a P-Preferred-Service header, it is removed by the S-CSCF, and it is possible that the ICSI inserted by the S-CSCF and the original ICSI are different. The S-CSCF will also insert an ICSI in SIP requests which did not have any P-Preferred-Service header.

When an ICSI inserted by a user does not match the request (e.g. the user inserted an OMA SIMPLE IM ICSI and actually has an SDP body for a voice session) or the ICSI in the SIP request is not in the list of authorized ICSIs in the user's service profile, or the S-CSCF cannot map the request to any of the ICSIs authorized for the user, the S-CSCF may simply reject the request.

Once a SIP session has started, the S-CSCF may also reject renegotiations of the session that do not correspond to the service definition (e.g. a user tries to upgrade an OMA SIMPLE IM session to voice).

More liberal usages of Communication Services

An operator may inhibit all the restrictive behavior of the S-CSCF by not provisioning any ICSI in the service profile of a user. In this case, an IMS client can still insert an ICSI in a SIP request (the ICSI may have been provisioned in the client or may be hard-coded) and the ICSI may still be used to route the request to an application server, for charging, QoS or policy control, but the S-CSCF cannot insert an asserted ICSI and reject any request. Note that such an ICSI cannot be trusted by the core network but an AS can be used for this purpose.

If an operator provisions ICSIs in the service profile of the user, it can still decide that the S-CSCF should not reject requests as in the specification this decision is left to the operator's policy. The S-CSCF will just insert the P-Asserted-Service header.

Finally, even if the most restrictive S-CSCF behavior could apply, its potential impossibility to unambiguously associate one ICSI to a request (e.g. the user is authorized to use an OMA SIMPLE IM and an OMA CPM ICSI while both services can start with a messaging session) mandates it not to insert any ICSI in the request, de facto inhibiting its restrictive processing.

Interoperability with non-IMS cients

The IETF solved the potential interoperability issues between IMS and non-IMS clients by clearly discriminating between, on the one hand the usage of ICSIs and IARIs in the SIP Accept-Contact and Contact headers, which comply with the IETF procedures for a SIP client to declare its capabilities to a network (so-called callee capabilities) and for a SIP client to indicate preferences or instruct a SIP network about how the request it generated should be routed/forked (so-called caller preferences), and on the other hand the usage of ICSIs for network-centric usage within an IMS network (definition of two 3GPP specific headers: P-Preferred-Service and P-Asserted-Service).

Based on 3GPP procedures, a non-IMS client may receive a SIP request from an IMS client that includes a P-Asserted-Service header, but this header will simply be ignored and will not impact processing in the non-IMS client.

ICSIs and IARIs populated in the Accept-Contact header do not create interoperability problems either, as this header can (optionally) be used by a client to help selecting an application to be contacted but is primarily aimed at SIP proxies, instructing them about how to route the request.

However, there might still be a case where an IETF-compliant usage of Accept-Contact may prevent an IMS client to initiate a session with a non-IMS client: if the Accept-Contact header that includes the ICSI or IARI also includes both the "explicit" and "require" parameters, it instructs the SIP proxy not to route the request to a SIP client that did not explicitly declared its support of the ICSI (or IARI). As non-IMS clients are very likely not to being even aware of IMS ISCIs and IARIs, the IMS client would never be able to set up a session with them (however, the funny thing is that a non-IMS client would be able to set up a session with an IMS one).

At the moment, 3GPP did not decide on how ICSIs and IARIs should be used in Accept-Contact, but the risk I just mentioned is explicitly stated as a note in TS 24.229, which indicates that some companies are very wary about the issue. In any case, there is a need to clarify this aspect, and this might have to be done either globally (e.g. an IMS client shall not use these two parameters for ICSIs, but it might use them for some IARIs if the corresponding application requires it), or service per service, unless it is left to the decision of the operator.

Potential issues with ICSIs

To be used for advanced control, ICSIs require additional provisioning in the service profile of the user (HSS) as well as in IMS clients.

ICSIs now make the S-CSCF service aware, as it has to be able to compare ICSIs to SIP requests and SDP bodies into session initiation and session re-negotiation requests. At best this may imply a reconfiguration of the S-CSCF each time a new communication service is introduced (standardized or operator-specific). At worst this may imply an upgrade of the S-CSCF.

The S-CSCF processing of ICSIs (checking if a request matches the ICSI in it, trying to find an ICSI for a request without any, checking if session renegotiation matches what is permitted for an ICSI) will add to resource consumption and end-to-end delays. In the case where ICSIs do not significantly simplify other procedures of the IMS core network (and I do not think they will), this is a pure loss for core network characteristics. This might be a minor factor, but it could also be an important one once IMS traffic grows in important proportions.

Any future for Communication Services used for control?

In its current state of specification, the concept of Communication Service can be used both by liberal operators and by operators wishing to exert a strong control over their customers.

In the liberal approach, ICSIs can be used to facilitate the routing of service requests to the right application server(s). No constraining behavior of the S-CSCF will be mandated, and while ICSIs can be used as a convenient way to identify a service (for instance in charging records), they will not significantly help the task of core network entities in their processing (e.g. generating accurate charging records).

In the controlling approach, ICSIs can be used as a means to check that users only access (typically silo) services they are explicitly authorized to use, and that they cannot escape control (at least at SIP level) during the session.

Maybe the controlling approach will be used by some operators. However, considering the facts that ICSIs do not only come with benefits and that users may be led to draw comparisons between operators with a strong controlling and a more liberal approach, I am not sure right now that Communication Services are promised to a bright IMS future. Future will tell.

Christophe

References:
Definitions and requirements: TS 23.228 chapter 4.13
Detailed procedures by IMS client: TS 24229 chapters 5.1.1.2.1 (declaration of supported ICSIs as callee capabilities at registration), 5.1.2A.1 (generation of SIP request), 5.1.2A.2 (reception of SIP request)
Detailed procedures by S-CSCF: TS 24.229 chapter 5.4.3.2 (originating requests), 5.4.3.3 (terminating requests)
Communication Services in Service Profiles: TS 29.228 Appendix B (B.2 and B.2.1A)