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

GSMA RCS 5.2 vs RCS 5.1 summary

The GSMA RCS 5.2 is the outcome of efforts made by GSMA and many global operators to extend the existing GSMA RCS features in a way to accommodate the current market trends. 

First of all, many clarifications have been made on the Network based Message Storage features. As the RCS 5.x represents the IP based converged communication service, there have been evolution in how to integrate the legacy messaging service features from the RCS blackbird version which addresses UX/UI based legacy integration. Since then, the RCS 5.1 incorporated the network based integration for legacy messaging services by adopting the Interworking Function from OMA CPM. As of now RCS 5.2 provides the details relating to synchronization of Conversation History for locally stored legacy messages at the device. Secondly, the RCS 5.2 accommodated the audio message feature, which is to enable audio recording and send it as an audio message using file transfer. Lastly, the RCS 5.2 allowed the RCS Extensions, which is a kind of RCS variant where some operator specific additional features can be deployed on top of the RCS application. The RCS Extensions utilizes all or part of RCS infrastructure and capabilities. This way, the GSMA opens the gate of RCS to potential added features, thereby seems expecting to expand the RCS territory with more flexibility. This seems also the reflection of the current market trends where some operators are partnering with prominent OTT services and some are already coming up with their own OTT services based on RCS infrastructure. 

Other than the above, there are more added features such as message revocation, Common File Store, etc. The following is the brief summary of additional features of GSMA RCS 5.2 compared to the RCS 5.1.

1. Network based Message Storage

The Network based Message Storage has been incorporated into the RCS architecture in order to provide consistent and unified communication environment across multiple devices. The Message Storage stores all the RCS user's conversation history and synchronizes it to RCS user's multiple devices, i.e., by user's request, periodically, etc. The following are some of main features that have been clarified in the RCS 5.2 compared to RCS 5.1.

Synchronization of SMS/MMS

In RCS, all the SMS/MMS messages are supposed to traverse the Interworking Function(IWF). The outgoing RCS message towards legacy messaging users is converted to the corresponding SMS/MMS before being sent out and the incoming SMS/MMS is converted to the RCS message before being forwarded to the Messaging Server via the IWF. In case there is an IP-SM-GW in the underlying network, the RCS system may interwork with it based on operator's policy to send/receive SMS messages. While interworking RCS messages, all the SMS/MMS are stored in the network based Message Storage as an RCS message within the RCS system, which means some of required SIP headers will also be stored including Conversation Id, Contribution Id, IMDN-Message-Id, etc. In RCS, the dedicated root folder for RCS messages, "RCSMessagesStore", has been specified where all the RCS messages are stored and the folder itself can not be removed or modified by the RCS user.

When there is no available data connection, the RCS client shall send/receive SMS/MMS directly through the CS network. In this case any sent/received SMS/MMS reaching the device can not be stored in the network based Message Storage. Rather, they will be stored locally in the device. Therefore when they are to be synchronized, both RCS client and the RCS system shall consider the correlation between new SMS/MMS(stored at the device) and already stored SMS/MMS(at the Message Storage). As the locally stored SMS/MMS does not have any relevant information such as Conversation ID and Contribution ID, there should be other way for correlation check. In case of multiple devices environment, the other device will also have to perform correlation check while synchronization. As for SMS/MMS, whether to perform the correlation check will be determined based on the provisioning configurations(i.e., SMS MESSAGE STORE, MMS MESSAGE STORE). 

The GSMA RCS 5.2 specifies the following additional information that needs to be considered for correlation check:

• message-context = "pager-message"|"multimedia-message", indicates what type of legacy messaging has been used upon sending/receiving the legacy messages.
• RCS-SMS-Content : 140 bytes payload of sent/received SMS message. 
• Message-ID: globally unique message identifier for Multimedia Message.

The SMS correlation check shall be performed based on From/To and RCS-SMS-Content, whereas the Message-ID is used to correlate the MMS. Once the message is synchronized, the message will be identified by the folder name, UID and UID Validity.

2. Common File Store

The Common File Store is used for permanent store of file contents that are delivered via File Transfer. The Common File Store also provides synchronization functionality of file contents across multiple devices. The Common File Store is differentiated from the Contents Server in a sense that the Contents Server is required only for "indirect file delivery" without synchronization or file localization purpose, meaning that the file itself is delivered via the Contents Store while the location url of the stored file in the Contents Server is delivered through a chat session or a standalone messaging. The Contents Server is only focused on delivering the file content. There hasn't been any considerations of permanent file store. The Common File Store shall stand side by side with the Message Storage. The Message Storage is used to store the signaling information whereas the file itself will be stored in the Common File Store. 

The RCS 5.2 provides additional functional block named the File Localization Function, which is the function block to fetch the remotely stored file in another Common File Store possibly located in other operator's network. When the File Transfer request is delivered to the recipient RCS user, the Messaging Server in the recipient RCS user's serving network shall modify the included location url of the file in a way that the recipient RCS user's request for file download always go through the File Localization Function. Upon receiving the file download request from the user, the File Localization Function fetches the target file stored in an indicated location and store it in the Common File Store of the RCS user at home network.  Once the file is stored in the Common File Store of the recipient RCS user's home network, the other devices of the RCS user can also access and download the stored file.

3. Audio message

The RCS 5.2 supports the delivery of audio messages of an RCS user. The RCS user can record the voice messages on his/her phone and deliver it to one or more recipients. When the audio message is recorded, the AMR encoding shall be supported and the maximum duration shall be adjusted based on the provisioning configuration(i.e., MAX RRAM DURATION). When the audio message is to be delivered, the recipient RCS user may receive the audio message information such as time, date, duration, etc. 

The audio message is sent using standards File Transfer mechanism. Therefore all the file transfer related features will be applied as follows:

• MSRP or HTTP based file transfer according to DEFAULT FT MECH
• Store and Forward
• Auto acceptance
• IMDN notifications

4. RCS Extensions

The RCS Extension is the type of variants of the RCS application which may adopt all or part of RCS features and may have additional features on top of the RCS application. With the RCS Extension feature, the operators may come up with their own specialized services. The RCS Extension can utilize all or part of RCS infrastructure and the RCS infrastructure shall be able to accommodate such applications with proper feature identifiers. For this purpose, the corresponding ICSI and IARI has been specified. Operators can enable/disable the RCS Extension in the RCS client using a provisioning configuration mechanism and/or a system request message using EUCR. 

Once allowed, the RCS Extension may communicate with other RCS clients or with another RCS Extension of the same kind. As part of control for the RCS Extension, the operators may limit the maximum size of an MSRP message of an RCS Extension.

5. Message revocation

The RCS client or the RCS system can revoke the sent RCS messages when the RCS client or the RCS system didn't receive the corresponding delivery notifications yet. As the message revocation can only be done when the message hasn't yet been delivered for sure, the message revocation request shall be handled by the terminating RCS system properly. Upon receiving the message revocation request, the terminating RCS system will remove the target RCS message. 

NOTE the message revocation is not user driven, rather a device or Messaging Server on the originating network. 

From the terminating RCS system perspectives, the followings are cases where the message revocation would end up with a failure:

• The SMS/MMS interworking has been done already.
• The message is already stored in the Common Message Store.
• The delivery notification has already been received from the recipient's RCS client.

6. Summary

One of the most impressive features in the RCS 5.2 is the concept of RCS Extension in my view. The RCS Extension represents an evolutionary direction of the RCS service, as it provides a lot of flexibility to operators in terms of business model. The operators may come up with their own feature added RCS service or 3rd-party OTT services by way of using all or part of RCS infrastructures and related technologies. This could be a good news for operators. With an RCS Extension, it seems the GSMA RCS has taken one more step closer to the RCS monetization along with some of known ways such as Network API Gateway. 

Secondly, the Common File Store might be another feature that can provide operators with another vision of RCS service in terms of monetization. As the Common File Store is a warehouse of multimedia contents of RCS users, the contents can be potentially distributed across another RCS users. If the Common File Store is deployed on top of cloud, it could be utilized as a cloud based contents sharing platform being combined with the RCS platform. Even thought there are already some prominent services such as Dropbox and Google Drive, it would be better off and more efficient for Common File Store if the RCS platform can be used as distribution channels.

Lastly, the legacy messaging service interworking feature has been one of major functions in the RCS service in terms of integrated messaging. The RCS blackbird provided way of how to integrate the legacy messages and the IP chat messages. The integrated UX/UI recommended in the RCS blackbird shows how to converge the RCS user's communication experiences for different messaging services. The RCS 5.x adopted the OMA CPM Architecture, thereby provided the network based interworking with legacy messaging service. The RCS 5.2 recommends the way of how to synchronize the locally stored legacy messages between the device and the network based Message Storage. This feature shows how the integration of RCS features and legacy messaging services is getting completed.

Red Mouse