1. Introduction

GSMA Rich Communication Suite (RCS) was originally based on OMA SIMPLE IM architecture in the beginning, but adopted OMA Converged IP Messaging (CPM) architecture from RCS r4.0. While the RCS r4.0 was updated to RCS r5.0 and onwards, there were more service features incorporated and more detailed technical points addressed but its architecture itself remained the same. The conceptual difference between the SIMPLE IM and the CPM is that the SIMPLE IM is focusing on implementing IP messaging features on top of SIP/IP core whereas the CPM is focusing on how to realize the converged user experiences among different communication technologies such as IP messaging, voice, video, etc. On top of CPM architecture, the RCS has specified additional value-added service features like contents sharing, location information sharing, and social presence information sharing, reflecting recent market needs that have been proven by many social network services.

2. SIMPLE IM Architecture

Figure 1. SIMPLE IM Architecture

The SIMPLE IM enabler consists of an IM client, IM server and IM XML Document Management Server (XDMS). The IM server breaks down into three functional components, i.e., controlling function, participating function and conversation history function. The participating function provides User Network Interface (UNI) towards the UE and the controlling function takes the role of conference focus, which is a centralized function that controls signaling procedures for a group communication service. The conversation history function interworks with an IM XDMS to store and retrieve the conversation history exchanged between SIMPLE IM users. The IM server also interworks with a Shared XDMS to retrieve IM related rules and policies. The IM client may internally interwork with the XDM client located within the UE in order to access the IM XDMS.

Note: Some interfaces and representations have been omitted in this diagram for simplicity. Please refer to the OMA SIMPLE IM [1] for the detailed architecture.

3. CPM Architecture

Figure 2. CPM Architecture

CPM has been developed to provide all-in-one communication service that can support all multimedia types (e.g., voice, video, text, etc.) and all different communication services (e.g., IP chat, voice call, video call, legacy messaging services, etc.). Thereby, the CPM is designed to destroy silos between different legacy communication services, and merge them on the SIP/IP network. So, CPM users can simply communicate with anyone in the contact without having to select a specific type of messaging service to use.

On the basis of SIMPLE IM architecture, the CPM has added a few functional components: conversation server and network-based message storage server. A Conversation Server provides the same but extended functionalities compared with IM server of the SIMPLE IM, and has additional interfaces to Interworking Selection Function (ISF), Interworking Function (IWF) and message storage server. The ISF determines what type of legacy messaging service is to be used among SMS, MMS and email to reach a target non-CPM user. Once it is determined, the selected respective Interworking Function (e.g., SMS-IWF, MMS-IWF, EMAIL-IWF) converts the CPM message to a legacy message accordingly. Then, the converted message, i.e., SMS, MMS, email, is forwarded to the corresponding legacy network. A network-based Message Storage Server stores and retrieves conversation history by interworking with the Conversation Server. The conversation history can also be synchronized across multiple devices of a CPM user, thereby ensuring the user can have the consistent user experience on any of his/her device.

Note: Many interfaces and representations have been omitted and tweaked in this diagram for simplicity. Please refer to the OMA CPM [2] for the detailed architecture.

4. RCS Architecture

The RCSe has adopted an IM server from SIMPLE IM and is reusing other service enablers like Presence and XDMS. The RCS r5.x enhances functionalities of each component and has also incorporated a few more functional components from OMA CPM such as Message Storage Server and Interworking Function. A video sharing server provides GSMA IR.94-based video sharing service, and the OPTIONS AS has been recommended to support multiple devices for SIP OPTIONS-based service capability discovery feature.

Authentication of an RCS-enabled device is subject to the security mechanism of the underlying network in principle. In this diagram, all the SIP traffic traverses the IMS network whereas the rest of the protocols traffic, i.e., XCAP, HTTP, MSRP and IMAPv4, will go through the respective direct interfaces between RCS client and the corresponding application servers. Each application server may need to support its own authorization mechanism unless the underlying network provides the proper functionalities.

Figure 3. RCS Architecture

A Provisioning Server provisions service-related configuration parameters to user devices. Configuration parameters consist of various Management Objects (MO) related with IP configurations for access points to the IMS network and RCS AS, authentication/authorization, and RCS service features (e.g., IP chat, file transfer, contents sharing, presence, XDMS, etc.). GSMA RCS allows operators to use OMA Data Management (DM) or OMA Contents Provisioning (CP) enablers as default configuration provisioning technologies. As an alternative way for an operator who might not have such functional components in their network, the GSMA also specifies HTTP(S)-based configuration provisioning. The provisioning server may need a back-end integration with the operator's NE(s) (e.g., HSS, BSS, etc.) to perform authorization for subscribers and to provide profile management functions. This back-end integration is not a scope of RCS specifications, but rather an implementation issue.

A Presence Server is based on OMA SIMPLE presence v1.1 architecture. It is used in RCS context to support social presence information sharing and presence-based service capability discovery features. Social presence information is a sharing object among RCS users which includes portrait icon, favorite link, free text, availability, willingness and geolocation information. Operators may further define their own items to provide a differentiated RCS service. The Presence Server interworks with the XDMS to store and retrieve social presence information, user's profile and RCS contacts list.

A XDMS manages RCS users’ profiles and various group information such as RCS contact group, blocked contact group, revoked contact group, etc. The XDMS is based on OMA XDM v1.0 and v2.0 architecture. Once the RCS client finishes service capability discovery procedure after it was invoked, it connects to the XDMS and performs directory service which is to retrieve all the RCS user's XML documents stored in the XDMS. If there is no XML document stored, which is typical when it is the first time access to RCS service, the RCS client shall create new XML documents (i.e., RCS contact group, user profile, user preference, group list) and upload them to the XDMS. The Presence Server has to support XCAP interface to store/retrieve these presence XML documents. The XDMS may include but not limited to shared XDMS, presence XDMS, aggregation proxy and additionally, the Cross Network Proxy subsystem for Network-Network Interface (NNI).

A Conversation Server is based on the IM server of OMA SIMPLE IM v1.0 or the conversation server of OMA CPM v1.0. It consists of Participating Function (PF) and Controlling Function (CF). The PF provides the UNI functionalities and handles all the RCS signaling and media control for one-to-one communication of IP chat, file transfer, standalone messaging, etc. All the RCS messages targeting to multiple recipients i.e., group communication, is forwarded to the CF. The CF takes the role of the conference focus by handling RCS group-related procedures. If the target user is resolved to be a non-RCS user, the Conversation Server shall interwork RCS messages to Interworking Function (IWF) via SIP/IP core. The Conversation Server acts as an IMAPv4 client to store the conversation history in the centralized message storage.

A Message Storage Server stores and retrieves all the RCS messages and contents exchanged among RCS clients. In case an RCS user has multiple devices, the conversation history can be synchronized across all the user's multiple devices using IMAPv4. The RCS user can create a new directory in the repository to manage his/her own conversation history. Any node that is to interwork with the Message Storage Server shall act as an IMAPv4 client.

A Video Sharing Server provides video sharing service feature based on GSMA IR.74 in RCSe and from RCS r1.0 to r3.0. The GSMA IR.74 specifies that video sharing sessions are dependent on existing voice sessions. A video sharing session is available only when there is an existing voice session. And if the voice session closes, the video sharing session shall also be closed along with the voice session. If the voice session is affected somehow by e.g., call on hold, call forwarding, etc., the video sharing session will also be closed. In the meantime, from RCS r4.0 and onwards, the RCS adopted the GSMA IR.84 for video sharing service. In GSMA IR.84 based video sharing service, the video sharing session does not have any dependency on the existing voice session. That is, an RCS user can establish a video sharing session regardless of whether there is an ongoing voice session or not. The video sharing server has an ISC interface with the IMS core.

IWF performs protocol conversion between RCS messages and legacy messages like SMS and MMS, and forwards converted messages to non-RCS users and vice versa. The IWF consists of SMS-IWF and MMS-IWF functional components, and it may include Interworking Selection Function (ISF). The ISF determines which legacy messaging service is to be used in order to relay the RCS messages to non-RCS users. The ISF may determine the specific IWF functional component based on contents type and contents length and/or the operator may define their own criteria to select the interworking function. The SMS-IWF can interwork either with the Short Message Service Center (SM-SC) or IP-SM-GW for SMS interworking. In case of SM-SC interworking, the SMPP interface is used and the SMS-IWF shall act as an end point of SIP realm. In case of IP-SM-GW interworking, the IP-SM-GW takes the role of SIP end point. Therefore, the SMS-IWF provides the SIP interface towards the IMS core to access the IP-SM-GW. The SMS-IWF shall also have an MSRP interface with the IP-SM-GW to deliver RCS messages. When it comes to MMS interworking, the MMS-IWF has an MM4 interface with the Multimedia Service Center (MMSC).

OPTIONS AS (OAS) provides SIP OPTIONS-based service capability discovery feature among RCS users. The service capability discovery can occur periodically based on polling time (provisioned by the provisioning server) or it can also take place per user request. The SIP OPTIONS-based service capability discovery is supposed to be applied to the non-RCS contact of an RCS user's address book. In case a recipient (i.e., a contact) has multiple devices, the OAS has to perform service-level forking and aggregate the results from the individual recipient's device. The OPTIONS AS may have an SIP interface with the Conversation Server from which the SIP OPTIONS can be forwarded or it can have a direct interface with the RCS client through the IMS core.

5. Summary

The RCS r5.x architecture is an extension of RCSe architecture. If an operator is already providing an RCSe service, the operator can evolve its RCSe service to the RCS r5.x service by adding up a few more functional components and upgrading the existing RCSe functional components accordingly. As the GSMA RCS is adopting various OMA technologies which has a lot of interfaces and complexities, operators may need to consider how to simplify the system architecture. The operators should determine what standards to be adopted and what standards can be omitted or replaced. They also need to find a way to enhance performance of the RCS system as the OMA-based presence technologies and SIP OPTIONS-based capability discovery procedure are highly likely to cause heavy traffic in the network. Some traffic optimization methodologies have been already suggested in the GSMA RCS specifications. But, still operators may need to find more ways to reduce possible traffic overloads. Realizing a simple architecture and traffic optimization would be the key to successful provision of robust and stable RCS service.

References

[1] OMA SIMPLE IM, "OMA-AD-SIMPLE_IM-V2_0_20120731-C", http://www.openmobilealliance.org
[2] OMA CPM, "OMA-AD-CPM-IM-V2_0-20130611-C", http://www.openmobilealliance.org
[3] OMA XDM, "OMA-AD-XDM-V1_1-20080627-A", http://www.openmobilealliance.org
[4] GSMA RCSe, "RCSe Advanced Communications: Service and Client specification", v1.2.2, Jul, 2012
[5] GSMA RCS 5.1 "Rich Communication Suite 5.1 Advanced Communications: Service and Client specification", v4.0, Nov 2012