GSMA Advanced Messaging – RCS Universal Profile

Rich Communication Services (RCS) has been around for a couple of years without any major success (actually the number of RCS deployments has been declining). There were many reasons. From the technical point of view it was caused by very ambitious design at the times where there was a little experience with IP-based technologies in operators’ networks, along with the lack of good enough RCS clients. That has changed and in the November 2016 we got a new standard called RCS Universal Profile (RCS UP) created by GSMA.

It contains a set of Advanced Calling and Messaging features and agreed enablers – such as application to person messaging (chatbots) and conversational commerce (the seamless integration of transactions and messaging).

Update: GSMA in June, 2017 released the version 2 of RCS Universal Profile. This document also introduces the key enablers for Messaging as a Platform (MaaP). MaaP includes support for Application-to-Person messaging, Rich Cards, privacy control and spam protection to open up an A2P RCS business.

 

To date 46 Mobile Network Operators and 12 manufacturers, covering a subscriber base of 4.7 billion people globally, have committed to supporting a single, standard implementation of the Universal Profile. That means that the profile will be implemented by most smartphones makers (similarly as in the case of VoLTE/VoWifi). They are Alcatel, ASUS, General Mobile, HTC, Intex Technologies, Lava International Ltd., LG Electronics, Lenovo/Motorola, Samsung Electronics and ZTE,. Moreover the standard is supported by mobile OS providers Google and Microsoft. Therefore the devices will be equipped (as from Q2 2017) with a built-in Advanced Messaging app, so consumers will be able to text, chat and share media without the need to download any special application. (However a usage of app is also an option supported by RCS Universal Profile.)

Update: We have got the first smartphone with RCS UP support – more here. 

It is worthwhile to mention that Google is playing an important role because it bought Jibe – one of a few useful RCS clients, and has developed a universal Android client based on the GSMA RCS UP. Google along with Sprint in US and Rogers in Canada announced that they’re rolling out with their RCS Messaging based on RCS UP at the end of the last year. Besides, as GSMA says, Google is offering a carrier hosted service for Operators to launch and manage Advanced Messaging services to their customers without deploying the RCS or even IMS infrastructure.

Update: We have got some more RCS  UP deployments in Europe and Asia this year – more here. 

Update: Australia – more here

Update: Sprint and Rogers now support RCS Interconnect! – more here. 

 

So what does offer the RCS Universal Profile?

• 1-to-1 Messaging

  • Follows the Open Mobile Alliance (OMA) Converged IP Messaging (CPM) technical realization defined by RCS 6.0 and extended by functionality provided in RCS UP. The RCS 6.0 defines features:
    • Store and forward
    • Interworking of Chat to SMS/MMS
    • Message revocation request of Chat messages
    • Message revocation processing of Chat messages
    • “Delivered” message notification
    • “Displayed” message notification
    • Delivery of notifications (delivered and displayed) outside a session
    • IsComposing indications
    • Local Black List
    • Personal Network Blacklist
    • Local Conversation History
    • Support for the Common Message Store
    • User Alias (Display Name)
    • Multimedia during a chat conversation
  • In order for the RCS 1-to-1 Chat service to be used it shall be enabled by the service provider via the configuration parameter CHAT AUTH and the client shall be registered in IMS.
  • The client configuration parameter CHAT MESSAGING TECHNOLOGY  shall be set to 1.
  • For the Service Providers that have deployed other RCS versions with RCS Chat 1-to-1 service based on OMA SIMPLE IM procedures, deploying an OMA SIMPLE IM to OMA CPM and vice versa interworking function will be needed.
  • Note that multimedia content within a Chat session is not permitted. Therefore, in the SDP of the SIP INVITE request and response, the a=accept-wrapped-types attribute shall only include text/plain and message/imdn+xml. To transfer multimedia content during a chat, File Transfer is used.

• Group Chat

  • Allows service providers to implement the Group Chat experience based on SIMPLE IM or CPM. Only CPM is supported as messaging technology. The RCS 6.0 defines features:
    • Interworking of participants in a Group Chat to SMS/MMS
    • “Delivered” message disposition
    • “Displayed” message disposition
    • IsComposing indications
    • Local Black List
    • Local Conversation History
    • Support for the Common Message Store
    • User Alias (Display Name)
    • Long lived Group Chat
    • Store and Forward feature
    • Closed Group Chat
    • Leaving a Group Chat
  • In order for the Group Chat service to be used it shall be enabled by the service provider via the configuration parameter GROUP CHAT AUTH and the client shall be registered.
  • For the Service Providers that have deployed other RCS versions with RCS Group Chat service based on OMA SIMPLE IM procedures, deploying an OMA SIMPLE IM to OMA CPM and vice versa interworking function will be needed.

• File Transfer

  • The File Transfer functionality can be implemented using MSRP or HTTP. The RCS UP only supports File Transfer via HTTP. Therefore the client configuration parameter FT DEFAULT MECH defined in RCS 6.0 is provided by the service provider with the fixed value “HTTP”.
  • An RCS contact is considered to be File Transfer capable if the File Transfer via HTTP capability is present.

• Audio Messaging

  • Audio Message is a File Transfer specific content type as specified in RCS 6.0. Audio Messaging uses the File Transfer requirements and technical procedures to exchange AMR Audio Messages such as:
    • Procedures for handling File Transfer interruptions and failures,
    • Use of Delivery Notifications
    • Rules for Auto-Accept
    • Use of a local device blacklist
    • Rules for managing shortage of space for local storage
  • Any contact having the File Transfer capability is seen as being compatible with Audio Messaging.

• Messaging for Multi-Device

  • Multi-device service is limited to messaging service only (i.e. voice and video for multi-device are deferred to next release of the RCS UP). The multi-device service offers the following RCS services:
    • 1-to-1 Chat,
    • Standalone Messages
    • Group Chat
    • Audio Messaging
    • Geolocation Push
    • File Transfer as defined in this profile.
  • Multi-device is using backup, restore, and synchronization features via Common Message Store (CMS) as described in RCS 6.0.
  • The messaging for multi-device technical realization provided in this section is based on the direct delivery model for CPM session based messaging that is defined in CPM 2.1 and endorsed by RCS 6.0.

• Green Button Promise for Voice and Green Button Promise for IP Video Call Services

  VoLTE  (IR.92 voice) is a technical enabler for delivering a voice call service when in LTE coverage. VoWifi (IR.51 voice) is another technical enabler for delivering voice call service under Wi-Fi access. IR.92 and IR.51 voice are profiles of the 3GPP Multimedia Telephony service taking access specific differences into account. The clients are expected to support the common set of procedures and the access specific functions described in VoLTE and VoWifi standards. Traditional CS voice services are delivered on 2G/3G networks. RCS IP Voice call is not supported for primary devices.
  The Green Button Promise for voice describes the behavior of the voice calling function on RCS/VoLTE devices under various coverage conditions delivered through VoLTE, Wi-Fi Calling and CS voice calling services.
  Similarly for video (ViLTE IR.94 + Video over Wifi).

•  Enriched Voice Calling

  • The Enriched Voice Calling functionality evolves the current voice call experience throughout all phases of a voice call: before, during and after the voice call. Enriched Voice Calling covers the following functional areas:
    • Pre-call experience: Enrichment of the voice call before the voice call is started. A calling user can “compose” and share content that the called party sees when receiving the voice call.
    • In-call experience: Enrichment of the voice call during the voice call. Either party can share content during a voice call.
    • Post call experience: Enrichment in case a voice call could not be connected. A calling party can “compose” additional information that will be included with the missed call information on called party’s device when a call remains unanswered.
  • These features are to be provided only with Voice Services as described in “Green Button Promise for Voice” feature in RCS UP standard.
  • The Pre-call experience is implemented by the Call composer service, described in RCS 6.0
  • The in-call services are constituted of the following main services:
    • “Live Video”: In case the voice call is end to end IR.92/IR.51 voice call and the video service is available, “Live” Video shall be implemented as an end to end IR.94/IR.51 conversational video call based on procedures described in VoLTE/VoWifi standards.
      • In this case, the RCS Video Share service shall not be available to the user. In any other case, RCS Video Share service shall be used.
      • For the cases of IR.92/IR.51 voice interwork to legacy, RCS Video Share service is used. RCS Video Share service is possible to be established over LTE or EPC integrated Wi-Fi access.
      • If the device is in a IR.92 / IR.51 voice call, the availability of the upgrade to video call shall rely on the contact header negotiation during the call establishment (SIP INVITE and response).
    •  Sharing any file during a call.
    • Exchanging messages: Implemented via 1-1 messaging.
    • Location Push
  •  The technical realization of the Post-call experience is described in GSMA Enriched Calling TS.

As we can see the new RCS standard is from a great part based on RCS 6.0.  So it’s not less ambitious than the previous RCS versions. On the other hand the timing is now much better, operators already know what it means to support millions of subscribers over IP, how to implement voice service and simple messaging (SMS over IP). The Advanced Messaging is just the next logical step. Last but definitely not least this time there will be a native support for RCS directly in smart phones. Let’s see if the RCS UP will be as successful as it’s older brothers VoLTE and VoWifi.