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
 
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

   
 
Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
 
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
 
banner
banner
Why RCS Failed?
July 10, 2018 | By Houman Sadeghi Kaji @ Lotus Communication Inc.
Online viewer:
Comments (0)
3

Houman Sadeghi Kaji who is Experienced Board Member with a demonstrated history of working in the telecommunications industry. Skilled in Wi-Fi offloading/on loading Network Design, 4G, Diameter, MNO, MVNE, MVNO and Reliability Engineering.

 
 

Houman Sadeghi Kaji

Chief Innovation Officer (CIO) at Lotus Communication Inc.

 

 

All Articles by Houman Sadeghi Kaji 

 
     
  How to contribute your article to Netmanias.com !  
     
  List of Contributors  

 

 
     
 

How Standards Define Themselves to Death


Steve Austin, The Six Million Dollar Man, was – Better…Stronger…Faster… That was the hope of RCS (Rich Communication Services).

 

RCS started its journey at the GSMA in 2008 with the promise to allow service providers to deliver “OTT like” services with interoperability across service providers and managed quality of service as it is provided by those that own the network. By being better than what OTT can offer, users would vote for those services of the service provider.

 

Where was the market back then?
 

Looking at OTT on mobile at that time, things were still kind of preliminary.

 

Skype – Mainly used on desktops, Skype for mobile was in its infancy

 

WeChat – didn’t exist, launched in 2011

 

WhatsApp – Didn’t exist, launched in 2009

 

Facebook Messaging – Project Titan for user to user messaging was launch in 2010 and mobile messenger app was launched in 2011

 

Viber – Didn’t exist, launched in 2010

 

You get the point…

 

The important things to conclude from this data are:

  • Back then, when RCS started, there was still plenty of market share for it to capture
     
  • The OTTs listed above took the market by storm working vertically (a specific service) and not horizontally (many services for a specific segment/region)
     
  • They are all islands…didn’t wait for any standards
     
  • Oh…and they are all free


Why RCS lost to OTTs?


RCS has standardised itself to death in 2 ways.

 

It has insisted on trying to define and standardise everything possible rather than sticking to the bare minimum. Due to this, it lost a lot of time and left little room for flexibility to those who wanted to deploy it. RCS and the brand “Joyn” defined everything all the way up to the user experience, what the address book should look like and what the user would see on each and every screen.

 

On top of that, RCS standardization tries to capture requirements from 2 camps, what was known previously as RCS and RCSe, later to be unified under the Blackbird standard version. This move sounds great but Blackbird still includes different options for doing pretty much the same thing. When you define multiple ways to send a message and to implement presence-based features, the life of the developer becomes more complex.

 

The promise of RCS was valid
 

The promise of RCS was, and even today still is a valid one. It has been proven to be valid through the success of OTT players such as WhatsApp that provide some of the RCS services but in a proprietary way.

 

Different from VoLTE, that has good technical and business reasons to replace Circuit Switched voice, RCS doesn’t enjoy the network ownership advantage, OPEX savings and enhanced user experience compared to using an OTT service for the same purpose.

 

The major benefit of RCS could have been cross service provider interoperability.

 

Other assumed benefits, such as a unified user experience, are not more than a pipe dream as not all device vendors will vote for what join has defined (i.e. Apple). Given that, we are left with an application, at least on some of the devices, and not a pre-integrated experience that comes pre-loaded on the device.

 

The enhanced address book and integration with the phone’s address book has come to the OTT applications user experience a long time ago. Given the ubiquitous nature of some of them (who of my friends doesn’t have WhatsApp? None!), the benefit of RCS interoperability is losing its advantage.

 

There was another option


The other option was to put time-to-service at a higher priority than top to bottom standardization work.

 

Time-to-service as priority #1 doesn’t translate to zero standards, it translates to standardizing only what really needs to be standardized as was done in WebRTC, while leaving the rest for the implementers.

 

In context of RCS that would mean APIs (e.g. send message, get contact…) for applications to use the RCS service for launching innovative services and things related to payload (e.g. how a file is transferred between clients).

 

Service providers and RCS server vendors would provide client SDKs based on which the service provider could launch its own services. Additionally, they would provide them to developers to build services with and integrate them into other applications.

 

Conclusion
 

Reality has proven that even in places where standards exist, once communication crosses between services and networks, it goes through mediation servers. We see more coupling between clients and servers today, something that contradicts the goal of standards, to enable zero vendor lock. This reality is apparent today in every type of real-time communication – UC, IP-PBX, VoLTE and WebRTC. There is no reason why it will be different in RCS and therefore waiting runs the risk of missing the opportunity.

 
     
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
 
 
 
 

[HFR Private 5G: my5G]

 

Details >>

 

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

View All (854)
4.5G (1) 5G (101) AI (7) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) BSS (1) Big Data (2) Billing (1) Blockchain (3) C-RAN/Fronthaul (18) CDN (4) CPRI (4) Carrier Ethernet (3) Charging (1) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) EDGE (1) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (56) KT (43) Korea (20) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (4) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slice (1) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) Private 5G (10) QoS (3) RCS (4) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (35) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password