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