Can the RCS Initiative Solve the IMS Client Conundrum?

By Ronald Gruia 
One of the issues hampering a wider IMS adoption has been a wider availability of endpoints (phones, handsets, PC or devices). Despite the fact that many carriers (particularly mobile operators), analysts (Yours Truly included1) and other industry participants have been flagging this issue for a long time, it still has not gotten the attention it deserves.

To put the problem in a different way: the entire IMS ecosystem has been committed to the idea of “open APIs” via a host of web services, much like Google Maps or Flickr can be accessed by other services. However, unlike in the web world, in the world of SIP-based IMS, the delivery of these combined services is more problematic. The key advantage of the web model is the browser because it is a universal client that can present any data from any site. Therefore, the same client can be potentially leveraged for hundreds of web-based services. On the other hand, there is no universal client for IMS, and that makes the client the weak link in that ecosystem.

Faced with the task of tackling this challenge, the IMS community has pursued a couple of strategies thus far: one is based on a service-by-service approach, in which IMS clients are configured as services get rolled out, and the other alternative is based on establishing an architecture in which the client is able to handle varying operator service scenarios. For large carriers, the service-by-service approach can be quite a challenge, since downloading millions of IMS clients to all the subscribers is not an easy task. In addition, this strategy can trigger other issues such as backward and forward compatibility, as not all subscribers will necessarily keep their clients up-to-date, so the operators will need to keep track of the different versions within the installed base.

The second option makes sense, but the efforts have been scattered thus far, and while folks were expecting organizations such as the 3GPP and the OMA (Open Mobile Alliance) to step up to the plate (on the mobile phone front), the progress has been slow. Thus far, the 3GPP and the OMA have only specified a few IMS client mandatory and optional primitives2, to ensure compatibility with applications such as PoC and VoIP-VCC, and enablers such as presence. The OMA has issued some provisions in its specification for PoC (push-to-talk application Version 1.0 — note: there is a more recent 2.0 up-issue dated April 2008) and other IMS services, such as presence and group management. In fact this PoC spec has been used as a blueprint by NTT DoCoMo, which issued an IMS push-to-talk client RFP about a couple of years ago. That tender was won by Ecrio , which claimed at the IMS World Forum held in Paris in April 2008 that it has reached the plateau of 30 million IMS phones deployed (corresponding to 45 different models).

While this is an important milestone, the IMS wireless client space will not flourish until there are more handset models available. While there have been some dual-mode handset models (supporting SIP or UMA) introduced over the past couple of years (such as the UMA-based Nokia 6136, Motorola V3 RAZR, 560 and A910, or the SIP-based Nokia E60, E70, N80, N91 and N92 or the Kyocera Graphite), the market is anxiously expecting new models to come out. Unquestionably, creating an IMS handset takes a lot more than simply putting a SIP stack on a phone.

Realizing this, some handset vendors have already started introducing their own proprietary client solutions, such as Ericsson’s ICP (IMS Client Platform), which is a pre-standard API framework available in downloadable form to Symbian and Windows OS based terminals. In other cases, the mobile phone vendors will opt to partner with ISVs (Independent Software Vendors), and work alongside mobile operators to jointly develop an IMS client.

The best way to deliver the so called “killer apps” is to help application developers innovate. With that in mind, some IMS vendors began evangelizing a new Java API (JSR281), which was positioned as an early possible solution to the client problem. The notion was to enable either operators or third-party developers to write Java applets that leveraged IMS capabilities. But the early results indicate that is not yet clear whether JSR281 will be answer. For instance, Ericsson’s Service Development Studio has been used by roughly 60 companies as of March 2008, while Google’s Android SDK3 has had already over 750,000 copies as of early March 2008. The developers’ hearts and minds have been more tuned to Ajax, Apple’s iPhone and Google’s Android SDKs.

The Advent of RCS

The industry took a bolder step to address this issue in February of this year, announcing the RCS (Rich Communication Suite) initiative at the Mobile World Congress in Barcelona. RCS is a joint effort of network infrastructure vendors (Ericsson and Nokia Siemens Networks initially, later followed by Alcatel Lucent), handset manufacturers (Nokia, Samsung and Sony Ericsson, subsequently joined by LG and Motorola) and service providers (Orange, Telecom Italia, Telefonica and TeliaSonera, followed by AT&T, NTT DoCoMo, Telenor, Telstra , TIM, TMN, SFR and SK Telecom).

The key goal of this consortium is to facilitate the transition of mobile communications towards rich communication. The initial baseline was to agree on a set of IMS standards-based features and then to propose implementation guidelines geared towards accelerating the adoption of convergent, interoperable, rich communications services. The set of these services was initially set to encompass applications such as a presence-enabled phonebook with built-in service capabilities, a “rich voice call” that can involve multimedia content sharing, and enhanced/conversational messaging (including chat and history).

Early tangible results are beginning to emerge from the RCS effort, including a demonstration of some services during the IMS World Forum event in Paris (recently held in April). The demo involved an IM chat that led to a gaming session and video sharing among three users, each having a different handset (Nokia, Samsung and Sony Ericsson ).

During the same event, a couple of operator executives (Luis Angel Galindo, Senior Manager of Strategy and Innovation for Mobile Services at Telefónica Moviles Spain and Philippe Lucas, VP International Standards & Industry Relationships at Orange) gave an overview about RCS, its key features, modus operandi, objectives and next steps. According to the presentation, the key goal of the RCS initiative is to zero in a basic set of services that all industry players can adhere to, and hopefully collaborate on to guarantee interoperability and the empowerment of presence. This also represents an attempt to distill all the functionality that IMS could potentially deliver and just focus on a few key benefits to ensure that the ecosystem could flourish, much like GSM did by concentrating on a couple of things (voice and roaming). Lucas stressed that the consortium has intentionally not formalized itself because it wants to reach some alignment without all the red tape associated with being an “official” association.

The presenters also gave an outlook of how the interoperability testing will continue, evolving from UNI (User-to-Network Interface) testing to NNI (Network-to-Network Interface) testing. Parallel to that will be intra and inter-operator testing activities and expansion to garner other potential members after successful NNI tests. The plan on record is to eventually have interoperable rich communication services commercially deployed in 2009.

Will RCS Deliver the Goods?

The main idea behind this initiative is to make RCS the standardized lowest common denominator IMS client that could be embedded on future handset models and some smart phones. This will ensure interoperability, economies of scale, and eventually reinvigorate the wider IMS marketplace. The good news is that RCS already counts with the top five handset vendors, and a growing list of the world’s largest operators and network equipment vendors. However, notably absent from the member list are Internet giants such as Google, Microsoft and Yahoo! (that have already well-established IM clients such as Google Talk, MSN Messenger and Yahoo Messenger). Other players missing from the list include IMS client vendors (such as CounterPath , Ecrio and Movial, among others), innovators such as Apple (iPhone) and other enablers such as Adobe (Flash).

Furthermore, there are many questions that still remain unanswered. How will operators adhering to RCS be able to achieve competitive differentiation? How “portable” will be an application from one operator to another one? Will there be a set of common RCS APIs available to third party developers? Will that set of APIs be in Java (JSR281) or AJAX (Asynchronous JavaScript and XML)? While many of these lingering issues are still to be resolved, RCS will also face the challenge from other competing efforts to win the hearts and minds of third-party developers that will be creating the “cool apps” (Adobe Air, Flex and Flash, Apple iPhone SDK and iTunes, Google Android and Gears, Microsoft CSF and Silverlight, and others). These other competing technologies will still flourish in parallel to RCS, and are perfectly capable to deliver next-gen IMS services today. One example is the CommuniGate Pronto UC IMS client, which relies on Adobe’s Flex 2 technology (a cross-platform development environment based on Adobe Flash). The company is partnering with Ericsson to bring Pronto to the IMS marketplace.

While it is early to gauge the success of RCS, the economies-of-scale the consortium can bring to the table represents an important advantage that should not be readily discounted. But it would be nice to eventually see a bit more flexibility and the opening of the RCS “semi walled garden” by bringing some of the above players into the RCS ecosystem after some initial milestones have been achieved.

Endnotes:

1 Please refer back to my June 2006 IMS Magazine article entitled “The Impact of IMS on Applications and UIs” and available at: www.tmcnet.com/ims/0606/analyst-the-impact-of-ims-on-application-and-uls.htm.

2 For further details (for release 1.0), please consult: www.openmobilealliance.org/Technical/release_program/docs/PoC/V1_0_2-20070905-A/OMA-RD-PoC-V1_0-20060609-A.pdf.

3 The SDK can be downloaded from: http://code.google.com/android/download.html.

Ronald Gruia (News - Alert) is Program Leader and Principal Analyst at Frost & Sullivan covering Emerging Communications Solutions. He can be reached at [email protected].

IMS Magazine Table of Contents