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