GSMA RCS Universal Profile overview

GSMA Universal Profile is a technical enabler for advanced communications that has been published in November 2016. To specify its features and relevant technical documents, 47 operators and 11device manufacturers and 2 mobile OS providers have committed to supporting a single, standard implementation of the Universal Profile. Since this new RCS specification has come out, Google renewed its Android Messages to be compliant with Universal Profile and provided it as a pre-loaded messaging application to several carrier partners, i.e., Sprint, Rogers, Telnor. The Android Messages has integrated native OEM applications such as SMS, MMS. Subscribers of those carriers can manually select the default messaging application between OEM SMS client and Android Messages.

I. Standards roadmap of Advanced Communications

The OMA has specified the IP based messaging service and relevant technical specification, i.e., SIMPLE IM, in early 2000. Since then, the OMA developed the concept of Converged IP Communication on top of SIMPLE IM by incorporating voice/video media streaming, interworking with legacy messaging services and more affluent features in IP messaging.

(1)     GSMA RCS 1.0 has adopted OMA SIMPLE 1.0 in its early stage. The RCS 2.0 incorporated new requirements for multiple devices where the mobile device with SIM card is a primary device and the secondary device shares the MSISDN of the primary device. RCS 3.0 enhances some of features in the previous versions by, e.g., including sharing location information in the Social Presence Information, providing the list of participants in a group chat, Contents Sharing without voice calling, etc.

(2)     GSMA defines its own brand name, Joyn, to promote RCS implementation and marketization. The first version of Joyn, HotFix (HF), is mainly based on RCS 2.0 features. There were several operators who have started Joyn HF commercial service e.g., SKT, LG U+ and KT in South Korea, Vodafone and Orange. But, they failed to penetrate the market as existing OTT services were already dominating the market. The Joyn HF’s service features were not attractive enough to compete with OTT services. Moreover it was provided as OTT application so it was even harder to attract locked users to change their communication tools. The monetization strategy of Joyn HF was unclear. All in all, majority of operators were hesitating to plunge themselves into RCS.

(3)     RCS4.0 adopts OMA CPM 1.0. as a baseline, which represents “Converged IP Messaging”. It includes some of advanced features that were not handled in SIMPLE IM such as Standalone Messaging, Legacy Messaging service interworking, Network based Common Message Storage, etc. The concept of CPM is to converge all the type of communications such as IP Chat, IP voice/video and legacy messaging services, CS voice/video calling, etc.

(4)     IP-SM-GW is a 3GPP Network Element (NE) that converts and relays the SIP messages to SMS and vice versa. Originally, the CPM 1.0 supports the interface with IP-SM-GW to provide SMS interworking. As RCS 4.0 takes the CPM 1.0 as a baseline, the IP-SM-GW interface has also been included in the RCS.

(5)     RCS 5.0 merges Joyn HF and RCS 4.0. Meanwhile OMA reflects the added features in RCS 5.0 to CPM 2.0 e.g., notifications within a chat session, closed chat, long-lived group chat, file transfer pause and resume, etc. to cope with GSMA RCS.

(6)     OMA also reflects the enhanced features in RCS 5.0 to SIMPLE IM 2.0 i.e., stored and forward, display notification to cope with GSMA RCS.

(7)     GSMA has published the new version of Joyn, that is, RCS Blackbird which mostly focuses on relatively simple features and integrated user experiences to meet time-to-market. The RCS Blackbird excluded Presence and the relevant features, IP voice calling, etc, for simplicity. There were many RCS players at the moment. Among them, Marvenir was acquired by MiTel and again by Xura. Jibe Mobile was acquired by Google and currently playing the key role in developing cloud based Google RCS. NewPace was acquired by Samsung. There are also WIT Software, InterOp technologies, NeuSoft, Nable Communications, etc.

(8)     Many of excluded features in RCS Blackbird e.g., Presence, Network based SMS interworking, etc., have been re-incorporated into RCS Crane.

(9)     Google joined in GSMA RCS initiative in implementing RCS Universal Profile specifications based on RCS 6.0 and RCS 5.3.

II. Service features

(1)    Auto Configuration Provisioning

The configuration provisioning is a procedure to provision service related configurations to RCS enabled devices. The configuration parameters contain various parameters relating to user authentication and authorization, IMS access point, RCS service features, RCS client’s behavior control, user preferences, roaming behaviors, etc. This procedure occurs as part of service activation when the RCS client is invoked for the first time and thereafter may occur upon device reboot, service provider’s request, SIM swap, etc.

Upon receiving the provisioning request from the RCS client, ACS may perform IMSI based user authentication as a default. If it fails, the ACS switches to OTP based authentication where the OTP is generated by the ACS and sent to the user’s primary device using SMS or End User Confirmation Request (EUCR) message. This SMS fallback may occur in the following context:

• The RCS client can’t access the SIM card.
• The RCS client accesses through Wi-Fi.

Service provider may initiate the configuration provisioning as per RCS updates, configuration parameters updates, T&C updates, etc. In this case, the ACS triggers the RCS client  by sending notification to initiate the procedure.

(2)    IMS registration

Once the auto configuration provisioning is completed, the RCS client accesses the IMS core using the provisioned IMS parameters. If RCS client is embedded in the UE being provided as an opt-out service, the P-CSCF discovery occurs during the UE’s initial attachment. Otherwise, the RCS may use the P-CSCF information obtained from the provisioning configuration parameters.

(3)    Service Capability Discovery

The service capability discovery is a procedure to figure out service capabilities of a contact in the address book to determine whether the contact is an RCS user or not. It occurs right after the RCS client successfully registers to the IMS network. The service capability discovery may occur more often in the following context:

• Initial address book scan at the very first time discovery during service activation.
• New user discovery when a new contact is added to the address book
• Periodic polling based on polling period (Provisioning parameters)
• Real-time fetch when a user attempts to communicate with another user
• Refresh as per user's request

As frequent service discovery can cause heavy traffic in the network, service providers need to regulate the traffic using relevant configuration parameters. There are two ways to implement this feature as below. Which one to use as a default for service capability discovery will be determined by the provisioned configuration parameter.

• The presence based service capability discovery
• The SIP OPTIONS based service capability discovery

(4)    Standalone Messaging

The standalone messaging provides uni-directional messaging service experience as it technically does not establish conversational session between users. The pager mode message is used when the message size is less than one MTU (1300 bytes) in which case the message is delivered using SIP MESSAGE. If the message size is bigger than one MTU, RCS client will switch to large mode message using SIP INVITE and MSRP to deliver the message. Deferred Message delivery is the same feature as store-and-forward in 1-1/group chat where the message is temporarily stored in the server when the recipient’s RCS client is not available to receive the message. When the RCS client becomes available, the stored message is retrieved and delivered to the target RCS client.

(5)    One to one Chat

The one to one chat is a session based messaging between two users where the message is delivered through MSRP session. The IMDN (i.e., delivered, displayed) indicates the delivery status of the message and it is mandatory in RCS to support ‘delivered’ IMDN for each message. The IsComposing (or IsTyping) notification indicating the peer status of typing the reply message is also supported. When the recipient is not available to receive the message due to e.g., connectivity loss, battery drain , the message is temporarily stored in the server. when the recipient's RCS client becomes available within the expiry time, the stored message is retrieved and delivered to the RCS client. The temporarily stored message will be discarded after the timer is expired. If the message has not been delivered yet, the originator can also revoke the sent message.

(6)    Group Chat

Group chat is a session based messaging among more than two participants. The ad-hoc group chat session can be created by selecting more than one contacts from the address book or by inviting another RCS user in a one-to-one chat. When the group chat session request is received, the recipient’s RCS client may automatically accept the request on behalf of the user or the RCS user may explicitly accept or decline the group chat request as per user's preference.

NOTE the auto acceptance for group chat is set to ‘1’ in BB and CR but it is configurable in UP.

The participant information indicates the participant's status of joining or leaving the group chat and it is informed to all the other participants whenever the event occurs. Once a participant leaves the group chat session explicitly, the leaving participant can rejoin the group chat only when he/she is invited by another participant. If the participant leaves the group chat unexpectedly due to e.g., connectivity loss, battery drain, the participant can rejoin the group chat as long as the client retains the conference-uri of the group chat session. In this case, the store-and-forward mechanism is applied to the missing conversation history when the leaving participant rejoins.

When the group chat session has been released out of inactivity, a participant can restart the group chat session by sending any messages within the conversation thread of the group chat. 

(7)    File transfer

File transfer is a unidirectional transfer of discrete media such as audio clip, video clip, images, binary files, etc. Files can be transferred within the context of a chat session or a standalone message. Technically, file transfer session is established separated from the existing chat session so the user can proceed the chat without interruption. But the transferred file appears in the same context within the ongoing conversation thread. When sending a file transfer request, the originating RCS client includes file information such as file type, size, thumbnail preview based on which the recipient may determine whether to accept the file transfer request or not.

Two different ways to implement the file transfer in RCS are MSRP and HTTP, but they don't make any differences in terms of user experience. The HTTP based file transfer is similar to indirect message delivery, that is, the file object is uploaded to the contents server and the RCS client obtains the location url of the stored object. As a result, it is the location url that is sent to the recipient's RCS client alongside the file information rather than the file object. Upon receiving the location url, the recipient may determine to download the file object or decline the file transfer. In principle, file transfer session can be established only with an explicit acceptance by the recipient but auto acceptance can also be applied according to the configuration.

In case the file transfer is interrupted out of e.g., connectivity loss, or paused by the either end user, the process can resume when the network connectivity is recovered or as per user's request. If the file transfer is not completed yet, the either end user may also cancel the file transfer. Once file transfer is completed, the corresponding IMDN is sent to the originating RCS client. In the same way as one-to-one chat and group chat, the store-and-forward mechanism is applied to the file transfer when the file can’t be delivered due to unavailability of the recipient.

Upon sending a large file, RCS client may warn the user of the maximum size limit. The maximum file size is configured by service provider in the provisioning parameter.

(8)    Geolocation Sharing 

RCS user can send his/her own geolocation to another RCS contact. The geolocation information can be sent through the existing IP chat session or in a separate file transfer session. Once the geolocation information is received, the recipient's RCS client may show it on the map available in the handset e.g., google map. 

(9)    Audio messaging

RCS user can record the audio message and sends it to one or more RCS contacts by re-using file transfer mechanism. The detailed features of audio messaging are same as file transfer.

(10)     Black list

RCS user can maintain (i.e., add, revoke) the local black list in his/her own device. Once an RCS contact is selected as a blacklist by the user, any of conversation attempt from that contact e.g., 1-1 chat, group chat, file transfer, geolocation push, enriched calling, etc are not notified to the user.

(11)     Centralized Message Store (CMS)

The CMS is used for back-up and synchronization of conversation history between the network repository and one or more RCS clients. RCS client needs to get authenticated to access the CMS using either AKA or basic authentication method. All the RCS messages such as IP chat, file transfer, IMDN and legacy messages (e.g., SMS, MMS) are stored in the CMS according to relevant configuration parameters. Event Reporting Framework enables RCS client to send a notification to RCS server indicating the message flag updates e.g., “\seen”, “\deleted”. Upon receiving the notification, the RCS server updates the corresponding message status stored in the CMS and in turn, the updates will be synchronized towards other multiple devices if any. 

(12)     Legacy Messaging Interworking 

RCS integrates legacy messaging services and IP messaging service. The integration of legacy messaging services can be implemented either by the RCS client at local device or by providing legacy interfaces (e.g., SMPP, MM4) from the RCS server. The client level integration includes the integration of message composer, message database, conversation history thread and receipt notification. The messaging service type to be used for sending a message is determined by the RCS client considering the access network availability and capability of the recipient’s RCS client. If legacy messaging interworking is supported by the RCS server, all the messages sent by the RCS client should be RCS message and the messages are converted and forwarded towards the recipient’s UE through legacy network if the recipient is not an RCS user. 

To assure the message delivery, the RCS supports two different modes i.e., Client Fallback to SMS (CFS) and Network Fallback to SMS (NFS). When the CFS is enabled, the undelivered message can be sent as SMS either manually or automatically according to user preference. When the NFS is enabled, the RCS server is responsible for fallback to SMS when the message delivery fails. The CFS and NFS mechanisms are applied to 1-1 chat and file transfer.

(13)     Multiple devices

The multiple devices environment should be considered across most of RCS features. When the RCS user uses a secondary device for RCS, the SMS based authentication is applied as the secondary device won’t be able to access the SIM card and therefore can't obtain user’s IMSI number and the UE will access the network through Wi-Fi. Upon IMS registration, RCS client needs to support ways to represent multiple device instance such as gruu, UUID, etc. RCS server also needs to support application level forking for service capability discovery, 1-1/group chat and file transfer. Upon service capability discovery, the RCS server aggregates the responses from each multiple RCS clients of the recipient and send it back to the originating RCS client. Audio messaging and Geolocation push reuses the file transfer mechanism. The conversation history stored in the Centralized Message Store (CMS) is synchronized across multiple devices. With Event Reporting Framework incorporated, the message status of each stored message is also synchronized in real time.

(14)     Voice Calling 

RCS supports Green Button Promise for voice calling which converges CS voice calling and IP voice calling. Typically, user can choose which one to use depending on the network quality and RCS client's service capabilities. RCS voice calling also supports emergency calling, supplementary services and DTMF detection. The seamless voice call continuity shall be supported when the access network changes.

(15)     Video Calling 

RCS supports Green Button Promise for video calling which converge CS video calling and IP video calling. Typically, user can choose which one to use depending on the network quality and RCS client's service capabilities. The seamless video call continuity shall be supported when the access network changes. When the network quality is not enough for video, the video calling may downgrade to voice calling as per client's decision. 

(16)     Enriched calling 

The Pre-call sharing enables users to share information such as call priority, subject, image and geolocation before voice calling session is established. The In-call sharing is to share image, file,  live-video or live sketch during voice calling. The In-call sharing media session is subject to existing voice calling session therefore the sharing feature is disabled when the voice call session is released, put on hold or affected by any supplementary service. The Post-call sharing is to share a note or voice message after the voice calling session has been released. 

III. Remarks

The main purpose of RCS is to evolve existing legacy communications to IP based ones by converging all type of communication services. But behind the scene, this evolution has more implications than that. As of recent, the A2P messaging (i.e., business messaging) has come into picture as a way to monetize the RCS messaging. Even though SMS traffic is expected to increase for a while along with increasing needs for A2P messaging, more and more A2P messaging aggregators are already turning their eyes to cheaper OTT messages from SMS, which is never surprise considering the customer size of those prominent OTT services. It is obvious that SMS which already lost its ground in P2P messaging will also lose its ground in A2P messaging sooner rather than later. The concept of Messaging As a Platform (MAAP) envisages long term strategy of RCS on top of which 3rd-party service providers are placed and provide various services such as Chat Bot. The Chat bot is becoming another prominent way for enterprise to engage with their customers. Many of OTT services are adopting Chat Bot to provide enterprises with another way to communicate with their customers. Most of operators are already lagging behind in this battle with OTT service providers as they stick to legacy messaging.

Red Mouse

References

[1] GSMA RCS UP, "RCS Universal Profile Service Definition Document v1.0" 16th Nov 2016