GSMA RCS Architecture Quick Review

GSMA RCS(Rich Communication Suite) 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, Social Presence Information sharing reflecting recent market needs that have been proven by many social network services. 

I. SIMPLE IM architecture

Fig 1. SIMPLE IM Architecture

The SIMPLE IM enabler consists of IM Client, IM Server and the 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 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 interwork with the XDM Client internally within the UE in order to access the IM XDMS.

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



II. CPM Architecture

Fig 2. CPM Architecture

The CPM has been motivated to provide all-in-one communication service by supporting all the multimedia types (e.g., voice, video, text, etc) and all the different communication services (e.g., IP chat, voice call, video call, legacy messaging services, etc). Thereby, the CPM intends to destroy silos between different legacy communication services and merge them on top of SIP/IP network. The CPM users do not have to select any specific type of messaging service, rather they just do communicate with a contact.

On the basis of SIMPLE IM architecture, the CPM has added a few functional components. The Conversation Server provides the same but extended functionalities compared with IM Server of the SIMPLE IM and has additional interfaces to ISF, IWF and Message Storage Server. The Interworking Selection Function (ISF) determines what type of legacy messaging service is to be used among SMS, MMS and Email to reach the 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 and the converted message, i.e., SMS, MMS, Email, is forwarded to the corresponding legacy network. The network based Message Storage Server stores and retrieves a Conversation History by interworking with the Conversation Server. The Conversation History can also be synchronized across multiple devices of a CPM user thereby the CPM user can be provided with the consistent user experience using any 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.


III. RCS Architecture

The RCSe has adopted the IM Server from SIMPLE IM and reuses 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 and Interworking Function. The Video Sharing Server provides the 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.

The authentication of the RCS enabled device is subject to the security mechanism of 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 severs. Each application server may need to support its own authorization mechanism unless the underlying network provides the proper functionalities.

Fig 3. RCS Architecture

The Provisioning Server provisions service related configuration parameters to user devices. The configuration parameters consists 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 a default configuration provisioning technologies. As an alternative way for an operator that might not have such a functional component  in their network, the GSMA also specifies HTTP(S) based configuration provisioning. The Provisioning Server may need a back-end integration with 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 specification, rather it is going to be an implementation issue.

The Presence Server is based on OMA SIMPLE Presence v1.1 architecture. It is used in RCS context to support the Social Presence Information Sharing and the presence based Service Capability Discovery features. The 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. 

The XDMS manages RCS user's profile 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 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).

The Conversation Server is based on the IM Server of OMA SIMPLE IM v1.0 or the Conversation Server of OMA CPM v1.0. The Conversation Server consists of PF and CF. The PF provides the NNI 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 IWF via SIP/IP Core. The Conversation Server acts as a IMAPv4 Client to store the Conversation History in the centralized Message Storage. 

The Message Storage Server stores and retrieves all the RCS messages and contents exchanged among RCS clients. In case the 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 shall act as a IMAPv4 client. 

The Video Sharing Server provides Video Sharing Service feature based on GSMA IR.74 in RCSe and from RCS r1.0 to 3.0. The GSMA IR.74 specifies that the video sharing session is dependent on the existing voice session. The 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, the RCS user can establish 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.  

The IWF performs protocol conversion between RCS messages and legacy messages like SMS and MMS and forwards the converted messages to non-RCS users and vice versa. The IWF consists of SMS-IWF and the MMS-IWF functional components and may include 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).

The OAS(Options AS) 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 the recipient(i.e., the contact) has multiple devices, the OAS has to perform service level forking and aggregates the results from individual recipient's device. The OPTIONS AS may have an SIP interface with the Messaging Server from which the SIP OPTIONS can be forwarded or it can have a direct interface with the RCS Client through the IMS Core. 

***

The RCS 5.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. The operator also needs to find a way to enhance performance of the RCS system as the OMA based presence technologies and SIP OPTIONS based Capability Discovery procedure does highly likely cause heavy traffic in the network. Some traffic optimization methodologies has been already suggested in the GSMA RCS specifications though, operators may need to find more ways reduce the possible traffic overloads. The architectural and functional simplification and traffic optimization are keys to provide robust and stable RCS service and it is only the start of providing qualified RCS service that might be competitive to existing OTT services. 


REFERENCES

[1] OMA SIMPLE IM, "OMA-AD-SIMPLE_IM-V2_0_20120731-C", URL: http://www.openmobilealliance.org
[2] OMA CPM, "OMA-AD-CPM-IM-V2_0-20130611-C", URL: http://www.openmobilealliance.org
[3] OMA XDM, "OMA-AD-XDM-V1_1-20080627-A", URL: http://www.openmobilealliance.org
[3] GSMA RCSe, "RCSe Advanced Communications: Service and Client specification", v1.2.2, Jul,2012

[4] GSMA RCS 5.1 "Rich Communication Suite 5.1 Advanced Communications: Service and Client specification", v4.0, Nov 2012


Last updated: July 2015

Red Mouse