Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
CHANNELS     ZARAM    |  TWDM-PON SFP+ ONU  |  XGSPON 10G SFP+ ONT  |  Use cases  | Evolution of FTTH Access Network    

 

Evolution of GSMA RCS standards
January 21, 2014 | By Red Mouse (beeno71@gmail.com)
Online viewer:
Comments (2)
10
SUMMARY
The evolution of technical standards for the Rich Communication Services has been driven by market needs. The Open Mobile Alliance (OMA) has specified the technical details of SIMPLE IM and the Converged IP Messaging (CPM) on the basis of IMS and SIP technologies. The concept of such technologies reflected the prevailing PC-based messaging services around the mid-2000s. Since the smartphone era around the late-2000s, operator-centered eco-system started to collapse and many Over-The-Top (OTT) communication services started to take off in the market with their free messaging and voice call services, thereby threatening traditional revenue of operators. The operators reacted to such threats by coming up with the Rich Communication Suite (RCS) technologies specified by GSMA. The standards for RCS are still evolving, incorporating various requirements for time-to-market service features and also considering business models.
 
     

Table of Contents  

1. Introduction
2. The advent of IP Messaging Service and evolution towards Converged IP

3. OTT vs Operators

4. Joyn

5. Adoption of CPM architecture in RCS

6. RCS r4 and RCSe merged into RCS r5.x

7. SIMPLE IM 2.0

8. CPM 2.0

9. RCS blackbird

10. Summary

 

 

1. Introduction


When the GSM Association (GSMA) has specified the Rich Communications Suite evolved (RCSe) standards with the brand name of "Joyn" for the first time in April 2011, many global telecom companies expected that Joyn could become a counterpart against the existing and prominent Over-The-Top (OTT) services such as Whatsapp, Viber, Line, etc. From operator's view, these OTT services had been growing dramatically by piggybacking on telcos’ established infrastructure, and they were even taking telcos’ revenue sources by providing free mVoIP and messaging service features.


In Korea, big three telcos (i.e., SK Telecom, KT and LG U+) started Joyn service at the end of 2012, and also in Europe, specifically in Spain and Germany, global companies like Vodafone and Orange, began the same service as well.
It’s been almost three years since then. Unlike the initial speculation, the Joyn service in those countries didn't gain much popularity, whereas OTT services are steadily growing in the market. This made most of other telcos who haven’t started the service yet hesitate to launch their own services. Even those who were already providing the service are also hesitating with further investment on their service. 


Despite the low popularity of Joyn, Rich Communication Suite (RCS) technologies and the related specifications in GSMA have been evolving to keep up with the market trends. This article will skim over the roadmap of evolving communication technologies in terms of global standards, which would help you better understand about how the telecommunication industry is endeavoring to be in line with the market trends.

 

 

Figure 1. The chronological roadmap of messaging standards

 


2. The advent of IP Messaging Service and evolution towards Converged IP Messaging


The Open Mobile Alliance (OMA) specified the SIMPLE IM technology as the first IP-based messaging technology back in the mid-2000s. The SIMPLE IM provides typical SIP-based messaging features such as one-to-one and group session-based messaging (i.e., chat). This SIMPLE IM became the basis of the following technical standards of communication technologies.

 

Since 2005, the OMA MWG Working Group (currently known as COM WG) started developing Converged IP Messaging (CPM) technologies ([1] in the Figure 1), which adopted many service features and technologies from SIMPLE IM. The CPM provides a converged communication service feature by integrating legacy messaging services (e.g., SMS, MMS, email, etc.) into new services like IP chat features, voice streaming, video streaming, etc. The CPM also offers some features, specifically targeting users with more than one device, to provide them with the converged communication environment and consistent user experiences across their devices.

 

 

Strictly speaking, the converged communication environment and consistent user experiences had already been widely accepted by users via PC-based messenger services such as ICQ, AOL, MSN messenger, etc. even before the OMA came up with OMA CPM. Such 3rd-party services were already providing many services like chat, presence information sharing, SMS/MMS integration, file transfer, conversation history backup features on top of IP network. Therefore such standards activities by the OMA can be interpreted as an effort of many global operators to bring the similar user experiences to the mobile environment, hoping to add up another revenue source by providing those service features -that are already proven successful - in their own networks.

 


3. OTT vs Operators


Since iPhone tapped into the market in the late 2000s, all device manufacturers started to come up with their own smartphones. The arrival of these new smartphones since then has changed many things in the eco-system of telecom industry. Thanks to Apple's AppStore and Google Android Market (now known as Google Play), 3rd-party application developers could become service providers by themselves. The operator-centered vertical value chain collapsed, and lots of 3rd-party services started to come out for free. Many tech leaders started to claim that operators will become a dumb-pipe in the end.

 

The operators lost negotiation power in the market as consumers are eager to stick to free OTT services. There were some attempts to regulate the traffic from the OTT services. However, it was banned by the market and by the law under the name of the network neutrality. Some OTT services such as Viber, Line, Whatsapp became heroes in the messaging market as they flourished. Many 3rd-party services which have successfully grabbed the early market of the smartphone era started to overpass traditional operators.

 

With the advent of prominent OTT services, operators started to lose their traditional key territories such as messaging and voice call. OTT service providers who managed to dominate the early market kept growing as a result of lock-in effect. Revenues from messaging service of operators plummeted along with traffic.

 

These radical changes in the market drove global operators to gather in GSMA to find a way to stand against threats from the OTT services. And they decided to kick off RCS project within the GSMA to provide enriched IP-based communication services. The RCS service requirements were specified and many technical details to meet the requirements were adopted from the OMA SIMPLE IM and CPM. The RCS specification has been developed and published up to RCS r4.0 ([2],[4] in the Figure 1).

 


4. Joyn
 

 

The RCS r4.0 included most of advanced features of OMA SIMPLE IM and CPM. However there was no operator coming up with RCS service as they were skeptical about the benefits and feasibilities of the service. It might look too complicated to implement RCS r4.0 due to technical difficulties and various service features involved. While operators were developing technical standards and hesitating to build RCS service out of whatever reasons, the number of OTT subscribers was soaring in the market, causing operators’ revenues to decline further.

 

Given the circumstances, the operators might have felt that they needed a time-to-market service, something that is simple enough to build within a short period of time. As a result of such discussion, they came up with a simple RCS service called "Joyn". The service is based on RCSe, which is last updated to RCSe r1.2.2 ([3] in the Figure 1). Main features of RCSe r1.2.2 are:

  • HTTP-based Configuration Provisioning for primary device (i.e., PS-access device): Provisioning of service related configurations to RCS-enabled device.
  • Service Capability Discovery: Procedures to find a contact who has RCS capabilities.
  • IP Messaging (i.e., one-to-one chat, group chat)
  • Store and Forward in one-to-one chat: Temporarily stores messages if the recipient RCS user is not available, and then forwards them when the user becomes available. 
  • one-to-one File Transfer
  • Image sharing based on GSMA [IR.79]: Real time image sharing with a peer engaged in a voice call.
  • Video sharing based on GSMA [IR.74]: Real time video sharing with a peer engaged in a voice call.
  • Social Presence Information sharing (i.e., anonymous fetch, optional): Viewing of contact's social presence information such as portrait icon, free text, favorite link, availability, etc.


5. Adoption of CPM architecture in RCS


The GSMA RCS has adopted OMA SIMPLE IM architecture in the beginning of RCS work. As the RCS is updated to r4.0, it has updated the architecture by adopting OMA CPM, which introduces several more components on top of SIMPLE IM architecture, that is, network-based Message Storage and Interworking Function.

 

<Source: GSMA RCS5.0>

Figure 2. Overall RCS architecture

 

The network-based Message Storage is used to store an RCS user's conversation history and synchronize conversation history across the user's multiple devices. The Interworking Function is used to integrate legacy messaging services such as SMS and MMS in the network side. The Email interworking function in OMA CPM was not included in RCS.

 

6. RCS r4 and RCSe merged into RCS r5.x


The GSMA RCS r5 is based on RCS r4 and RCSe r1.2.2 ([5] in the Figure 1). All the technologies and service features of the two have been merged into RCS r5. As of now, RCS r5 has evolved up to RCS r5.4. The RCS r5.x intends to integrate all the communication features on the basis of IP network. Legacy messaging services such as SMS & MMS are integrated into IP Chat features.

 

IP Voice/Video call features are integrated with VoLTE service and they support various supplementary services. All of these communication services are presented to users with an Integrated UX/UI. Main features of RCS r5.1 can be summarized as follows: 

  • The Configuration Provisioning has been extended in RCS r5.1 in a way to accommodate non-PS access device and RCS user's secondary device. A number of configuration parameters also have been added.
  • The Standalone Messaging gives the same user experiences as SMS/MMS in a sense that both are session-less communications. There are two types of modes defined in Standalone Messaging based on the size of message to be sent:
    • The Pager Mode message delivery (<=1,300 bytes)
    • The Large Message Mode message delivery (>1,300 bytes)
  • The Multimedia within the IP chat session has been allowed in RCS r5.1. RCS users can send multimedia content within an IP chat session. In case the multimedia content is bigger than what is allowed within a chat session, it is sent using File Transfer mechanism. The file transfer session will be separated from the existing chat session in order to be processed in parallel. Even when the content is sent as File Transfer and in a separate session, the RCS user can still view the transferred multimedia content within the same conversation context of the existing chat session.
  • The Store and Forward in a group chat improves the reliability of message delivery in a group chat session. A participant who has been disconnected involuntarily from the group session due to connectivity loss, battery drain, etc. can rejoin the group session after the device regains its connectivity. The rejoining participant can receive all the RCS messages that were missed while he/she was disconnected (basic store and forward). Even those who joined the group session late can also receive a full conversation history (full store and forward).
  • The Group session restart (Long Lived Group) catches up the current user experiences provided in OTT services where users can start a chat session by sending any message in a conversation thread stored in a local device. In RCS r5.1, a group chat session will be released if the inactivity timer is expired. After the group session is closed, the conversation history will remain in the participants’ local devices as long as they do not delete it. So, any of the users can re-start the same group session by sending a new chat message or a file within the conversation history thread. In order for the group session to be re-started, the group session identity should be kept in the RCS system. If the group session can’t be re-started because the corresponding group session identifier was removed from the RCS system, the RCS client may automatically attempt to start a new group session.
  • The HTTP and MSRP based File Transfer is used for HTTP or MSRP for File Transfer. In case of using HTTP, the file to be sent is uploaded to a certain content storage in the network by an originator and the location URL of the stored object is obtained in return. The location URL is sent via a chat session or as a standalone message to the recipient. The recipient can retrieve the file from the received location URL.
  • The File Transfer thumbnail preview is used to send a thumbnail to the recipient along with other file information such as file name, file type, file size, etc. within the file transfer request. The recipient RCS user may determine whether to accept the file transfer request or not based on this information.
  • The File Transfer pause and resume is used to pause file transfer while the file transfer is in progress, and resume whenever wanted. File transfer can also be paused unexpectedly due to other reasons, for example, connectivity loss. If the file transfer is resumed by either end user later on, the file can be transferred from the location where it was paused. To resume a paused transfer in multiple-device environment, the RCS user needs to use the same device. Otherwise the file transfer will start from the beginning as there is no file fragment in that device.
  • The File Transfer Store and Forward is used to store a file temporarily when the recipient is not available, and then have it transferred later when the recipient becomes available.
  • The File Transfer in a group session is used to transfer a file within the context of a group session.
  • The Social Presence Information has been enriched in RCS r5.1 by accommodating the location information of an RCS user. The Social Presence Information is supposed to be shared between RCS users who have established social presence relationship with each other.
  • The VIP contact is the type of contact whose change in social presence information is notified in real time to an RCS user. If the contact with whom RCS user is in social presence relationship is not a VIP contact, the RCS user needs to perform one-time subscription to that contact to view his/her social presence information.
  • The network-based Personal Black list can be created/deleted/modified by RCS users. Any RCS messages or communication attempt from a contact who is in the blacklist will be blocked.
  • The Geolocation Sharing push/pull is used to share geolocation information between RCS users. An RCS user can push his/her location information to an RCS contact (push) or request the contact's location information (pull).
  • The Contents Sharing is used to share an image or video clip in real time between RCS users. In RCSe, the Contents Sharing feature has dependency on the existing voice call session, which means Contents Sharing feature is available only when there is an existing voice call session. Whereas, the Contents Sharing feature in RCS r5.1 is independent from the voice call session. RCS users can use contents sharing service as a standalone service feature.
  • The network-based Message Storage is used to store the conversation history of an RCS user. The conversation history stored in the network-based Message Storage can be synchronized with one or more devices of an RCS user. The network-based Message Storage feature provides the user with the consistent user experience across multiple devices.
  • The Legacy Messaging Interworking is a supporting feature in RCS r5.1, which includes SMS and MMS. Given this feature, all the conversation history is integrated in the same conversation thread regardless of messaging types.
  • The IP Voice/Video call and VoLTE is integrated in RCS r5.1 along with IP chat features.


7. SIMPLE IM 2.0


Since the OMA SIMPLE IM 1.0 was adopted by the RCS in the beginning, the RCS has evolved with additional features. The OMA SIMPLE IM 2.0 has an intention to fill the gap between RCS and SIMPLE IM ([6] in the Figure 1).

  • Delivery of notifications for IM sent within one-to-one IM session
  • Delivery of out-of-session notifications
  • Store and Forward for messages and notifications sent within the one-to-one IM


8. CPM 2.0


The CPM 1.0 architecture was adopted by RCS r4.0 and the RCS r4.0 has evolved into RCS r5.x accommodating RCSe features. Like SIMPLE IM 2.0, the OMA CPM 2.0 has an intention to fill the gap between RCS and CPM 1.0 ([7] in the Figure 1). The CPM 2.0 has also included some clarifications for the previous version. 

  • Store and Forward in a group session
  • Support of Closed Group, Long Lived Group
  • Support of live recording of chat messages
  • Interworking over Network-Network-Interface (NNI) with SIMPLE IM 2.0
  • File Transfer while having ongoing CPM session
  • Store and Forward in file transfer
  • File Transfer pause and resume
  • Support of maximum file size policy
  • Support of thumbnail preview in file transfer


9. RCS blackbird


Chronologically speaking, it was only after the RCS r5.1 came out for time-to-market that the RCS blackbird was specified ([8] in the Figure 1). However, speaking from a service feature point of view, the RCS blackbird is an intermediary version between RCSe and RCS r5.x. The RCS blackbird includes most of RCSe features except the Presence related functions.

 

It also has many features from RCS r5.x in a way to provide the similar user experiences. For example, the RCS blackbird integrates legacy messaging features on UX/UI level through internal interworking between RCS and SMS/MMS clients within a device. Currently, the RCS blackbird has been updated up to release 4.0.

 


10. Summary


The RCS service features have been evolving from RCSe to RCS blackbird and to RCS r5.x. The RCSe includes the basic IP chat features and the RCS blackbird focuses on messaging and integrated communications from UX/UI perspective.

 

The RCS r5.x has integrated all the features in a box, where IP chat, legacy messaging, IP Voice/Video call, VoLTE service are converged and provides users with unified user experiences. Feature-wise, the RCS technology branded as "Joyn" seems to surpass the existing OTT features. Users can enjoy the same user experiences as previous communication services when making calls or sending messages and at the same time, their user experiences will be enriched based on the benefits the RCS brings on top of IP network. While the GSMA is coming up with time-to-market service requirements, the OMA is providing technical details to support those requirements by upgrading SIMPLE IM and CPM. The 3GPP is cooperating with the GSMA and the OMA from core network perspectives by considering technical details to be implemented.

 

In this way, many Standards Developing Organizations (SDOs) are working in harmony with each other to come up with competitive communication service features and technologies.

 


References


[1] GSMA, “RCS-e Advanced Communications: Services and Client Specifications”, v1.2.2 July
[2] GSMA, “Rich Communication Suite 5.1 Advanced Communications: Services and Client Specifications”, v4.0 November
[3] OMA, “OMA-RD-IM-V2_0-20120731-C”, v2.0 July
[4] OMA, “OMA-RD-CPM-V2_0-20130611-C”, v2.0 June 2013

 

 

Wiki 2015-09-02 15:22:07

I would like to know how IP voice/video call is synchronized with VoLTE and ViLTE

최홍주 2015-09-03 10:05:04

If the question is about how those two are convereged from user's persepctive, I'd say they will be converegd at the UX/UI level in principal. Upon request from the user for voice/video call, the UE will determine what to use between possible options (e.g., IP voice/video or VoLTE/ViLTE) based on the device capabilities and settings, contact's capabilities and network environment including SP's poilcy. Please refer to the section 3.9 and 3.10 in RCS r5.3 for technical implementation.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (174)
5G (7) Backbone (2) Backhaul (3) Blockchain (1) CDN (1) Carrier Ethernet (3) Charging (1) DHCP (4) ECM (2) EMM (16) EPS (2) Google (1) HLS (1) HTTP Adaptive Streaming (3) Handover (5) IPTV (4) Initial Attach (2) IoT (2) Korea (1) LTE (39) LTE Identification (2) LTE-A (1) MPLS (2) Mobility (2) NAT (7) Netflix (1) Network Architecture (3) Network Protocol (20) New Radio (1) OTT (1) PCRF (3) QoS (3) RCS (3) SDF (2) SDN/NFV (3) SK Telecom (1) Samsung (3) Security (5) Sk Telecom (1) Transparent Cache (1) Video Streaming (4) VoLTE (2) Wi-Fi (1) YouTube (2)
Password confirmation
Please enter your registered comment password.
Password