More feature stories by year:
Return to: 2013 Feature Stories
CLIENT: IMAGINATION TECHNOLOGIES
February 2013: Pipeline
Consumers today expect a rich communication experience from their smartphones, tablets and PCs, meaning they expect to be able to share photos, multimedia, files, contacts, locations, and status updates and have multiparty video and audio chats. The challenge has been to enable developers of mobile apps to provide these kinds of real-time services anywhere, anytime in an easy-to-use and reliable manner. Now the Rich Communication Services (RCS) initiative does just that, allowing these services to be performed in a standardized, universal way across all future cellular communication devices.
In fact, RCS offers much more for future applications. While app markets have spurred an explosion of exciting, creative products, so far those apps can only communicate via users who've downloaded the same ones. There is no consistent way to perform this communication, so it's currently impossible to connect different applications on different users' devices, nor is it possible to sync them with cloud-based services in a standardized way. Furthermore, the performance of the underlying real-time communication varies widely between applications and across different network conditions.
Although RCS Release 1 specifications were issued by the GSM Association (GSMA) in 2008, followed by Release 2 in '09, RCS really only took off in 2010, when the "big five" European carriers — Deutsche Telekom, Orange, Telecom Italia, Telefónica, and Vodafone — announced their plans to launch a subset of RCS named RCS-e (the E is for "enhanced") across several European markets by 2011 to provide users with a consistent set of rich communication services, including a network address book, user presence and status, file exchange, and video calling. Last year GSMA announced the "joyn" branding for RCS-e, which Orange, Telefónica and Vodafone introduced in Spain.
Parallel to the debut of joyn in 2012, RCS has evolved quickly from RCS-e to RCS 5.2, and is now positioned for a worldwide rollout. While early RCS-e rollouts have successfully engaged end users in rich communication, there is still a challenge when it comes to users' preference and familiarity with common non-RCS applications found in app stores, such as WhatsApp and the Korean-based KakaoTalk, which dispense similar functionality to initial RCS-e services. During the initial launch of RCS the greater community of application developers wasn't involved, and was in fact competing against it.
In 2012 the GSMA also debuted the RCS API initiative, giving birth to the RCS service-delivery API (application programming interface). The concept of API allows app developers to do what they do best — develop great apps — while service providers do what they do best — offer rich communication services that are reliable, high performance and always on, and fully leverage the capabilities of next-gen mobile devices and networks.
A key positive differentiator of the RCS API is that it converts the entire world of over-the-top (OTT) applications — which have been a thorn in the side of carriers — into a carrier's best friend, and vice versa. Developing exciting new applications for consumers requires creativity and innovation, and to date that hasn't been the forte of carriers, nor has the development of robust real-time communication and digital signal processing (DSP) subsystems been high on the list of mobile app developers. The RCS API enables each to do what they do best. In the new paradigm carriers are neither a dumb pipe nor mere distributors of apps — they are suppliers of rich communication services.
The RCS client framework must first perform an IMS registration, at which time the client is authenticated and the service capabilities of the client identified. Upon completion of IMS registration the application can utilize any of the rich communication capabilities, and multiple applications can use these services simultaneously (Fig. 1).
Fig. 1: RCS application architecture
An application may first use the network address book to select contacts to communicate with, then check the presence information to identify both the capabilities of those contacts on their current devices (capabilities exchange) and the status of the contacts ("busy," "in a meeting," "available"). Then the application may engage those who are available. It can also engage users in gameplay, file sharing, and real-time multiparty video, audio chat and so on.
Historically speaking, OTT applications have yielded only best-effort service for voice and video, and generally haven't offered the best battery life for these real-time, processing-intensive functions. By being tightly integrated with regular cellular service, which works everywhere, RCS can significantly outperform current OTT applications and produce a superior rich-communication experience by offering higher-quality voice and video and better battery life, which requires full leverage of both the capabilities of the service provider's infrastructure and those of the end user's device.
However, providing superior voice, video and battery life across a wide range of operating conditions requires sophisticated DSP algorithms in order to mitigate packet losses, jitter and other network conditions. It also requires full integration with the end user's device hardware, including hardware video acceleration, cameras and on-board processing resources. It's the job of the RCS client framework to supply sophisticated, power-optimized, high-performance voice, video and processing resources while simultaneously giving application developers an easy-to-use set of APIs so they can focus on developing the next generation of exciting gaming, communication and shared rich-communication experience apps instead of struggling with the real-time signal processing required to deliver that high level of performance.
Not all RCS client solutions are equal when it comes to high-quality optimized performance. With quality of service (QoS), for instance, the IR.92 standard for voice over LTE (VoLTE) provides guaranteed QoS on VoLTE calls, and the IR.94 standard does the same for video over LTE. RCS 5.0 integrates both IR.92 and IR.94 capability into the RCS client, but they're optional, so look for a client that offers full integration.
Other integral factors include:
The key challenge for developers is to combine their creativity and innovation with the power of RCS to bring forth the next generation of connected apps. This requires a paradigm shift, from a world where an app is a "one-trick pony" that only talks to others of its kind, and does so using non-optimized proprietary methods, to a world of connected apps that utilize the universality of the RCS service set (network address book, presence, etc.), rich multimode communication (audio, video, messaging) and the superior performance of real-time services (e.g., reliable multiparty voice and video) to provide a fully integrated end-user experience that can be shared with people all over the world.
The array of applications that can benefit from integrating RCS is virtually limitless. Any application for which users need to communicate using voice, video or chat, or for which knowing a user's status is important, can use RCS APIs, from consumer entertainment, including building interactive communities, to business applications like customer relationship management (CRM). Embedded device applications can also utilize RCS — in the exact same way as mobile-device apps.
The further challenge for developers is to do all of the above across a vast expanse of devices while imparting a natural and intuitive native-user experience on any and all of the devices. Ease of use is critical: developers of in-demand apps often say that even "grandma or grandpa" should be able to use their products, not to mention kids.
This multidevice challenge is very familiar to app developers who need a "write once, run anywhere" solution for end users, who may be using form factors ranging from smartphones, tablets and connected PCs/laptops to embedded devices. Plus, these devices span different operating systems and can have vastly different hardware capabilities: low-cost or legacy devices have minimal or no hardware acceleration and lower display resolutions, memory and CPU constraints, while high-end devices support resolutions and capabilities that were unheard of only a year ago. Many applications need to work on a wide cross-section of these devices to be viable.
While RCS itself does not directly resolve these issues, multiplatform RCS software development kits (SDKs) do, supplying standardized RCS across the full scope of devices and operating systems, thus ensuring native device integration and allowing app developers to deliver a rich communication experience to end users (developing once, running anywhere) with the assured high performance that RCS conveys. SDKs often incorporate many additional capabilities, providing further benefits to app developers.
Lastly, for some applications there are challenges such as security, authentication, single sign-on, and so on. A benefit of RCS is that these capabilities are inherent in RCS itself.
This year we'll see a series of factors align to ignite a rich-communication revolution on cellular devices, including smartphones, tablets and cellular-enabled laptops and PCs. These factors include the rapid deployment of LTE by carriers worldwide, providing ample bandwidth for rich communication; deployment of an interoperable rich communication service by many cellular carriers; a move to full RCS 5.2, which includes IR.92 VoLTE and IR.94 video over LTE with guaranteed QoS; and the use of RCS APIs. Any one of these factors is sufficient to drive major change, but together they represent a quantum leap forward for next-generation applications, making full use of rich communication services.
Return to: 2013 Feature Stories