Executive Summary

RCS Business Messaging is seeing the strongest momentum since its inception

Many MNOs are still in the process of evaluating RCS and the different ways of implementing it. This whitepaper looks to provide non-technical guidance for MNOs by showing the end-to-end ecosystem and RCS Business Messaging (RBM) message flows. This whitepaper will also report on the hands-on RCS and RBM experiences of Vodafone, Deutsche Telekom, Telefonica, KDDI, AT&T and China Mobile as they work towards a fully enabled network for RBM.

The main message expressed by all ecosystem players who contributed to this Whitepaper is get started with RCS Business Messaging as soon as possible. This whitepaper is a resource that can support this process.

 

Overview of RCS Business Messaging landscape

The demand for RCS Business Messaging (RBM)

In the current age of product commoditization enterprises are differentiating themselves more and more through providing superior customer experience. Messaging with SMS has proven its success as the channel of choice for personalized, timely and meaningful engagement between the enterprise brand and their Consumers.

RCS as an upgrade to A2P SMS Messaging and the features that it can provide give operators an opportunity to take more of the revenue share of digital marketing spend. These features mean that RCS can be used to replace app development and email campaigns by brands.

According to Statista, Digital Marketing budgets will grow at 10% CAGR to $399bn by 2020.SMS Business Messaging growth has, however, slowed 3% CAGR (Compound Annual Growth Rate) to $64bn. Conversely, MobileSquared forecasts RCS Business Messaging to grow from naught to $12bn in only 4 years’ time, with additional huge upside from search, advertising and customer care markets.

Live RCS brand campaigns have shown incredible uplifts in engagement rates and revenues compared to SMS campaigns.  The GSMA website hosts a wide variety of videos and resources on these RCS showcases. Therefore, this whitepaper will not focus on the use cases but on how to make them come to life.

The Roles and Players in RBM

Identifying all the involved players and roles is key to a deeper understanding of RBM end to end. For more details, please refer to the GSMA document “WA.09 – RCS Ecosystem Principles”.

To begin with, there are two main players: the enterprise brand and the individual mobile subscriber. The brand wants to send over some communication to its target recipients, the individual users with an RCS capable mobile device.

As you are aware the Mobile Network Operator (MNO) supplies the user with a SIM card and its associated connectivity contract. The MNO has a relationship with the user based on secure identity. As a result, SMS is more trusted by end-users than any other app for business messages, a relationship RCS can adopt and build upon (MEF Mobile Fraud report 2017).

To enable RBM the MNO also has to enable its network for Person to Person (P2P) RCS. According to the RCS specifications, this is achieved by enhancing the IMS network function with a designated RCS Application Server (AS) function. The IMS is like the general-purpose switch (think old fashioned operator connecting wires) but completely operated on IP basis using the so-called SIP protocol. The IMS can handle Voice over LTE (VoLTE) or Voice over WIFI, but with the help of the add-on called the RCS AS function, it can also manage RCS messages and RCS capabilities like sending a file from one RCS handset to another RCS device. We’ll talk more about deployment options in the next chapter, but it is worth noting that vendors are offering as an option ‘RCS in a box’, which pretty much emulates an IMS with Application Servers – so you can also RCS enable your network holistically for P2P without having an IMS or touching your IMS.

Supporting P2P RCS is, however, not yet sufficient for transacting RCS business messages. For that, the network needs another component, called MaaP (Messaging as a Platform). Distinguishing P2P from business messaging already on a protocol as well as network element level was one of the learnings from 25+ years of operating SMS, where the lack of separation of the two channels made the monetization of A2P SMS for the MNOs much harder. The MaaP instance gives the MNO full control over which chatbot with which ServiceID is allowed on its network. Think of the ServiceID not only as the identifier to the chatbot but also as the key to the look and feel of the chatbot: its sender name, its logo and colour scheme

As established in the SMS world, there are traffic aggregators whose job it is to connect and service many brands with their specific messaging needs, aggregate their traffic and send it to the right MNO. The RCS Aggregator removes the complexity for the MNO of handling hundreds of accounts, but it also abstracts the different networks from the brand. Additionally, the brand benefits from value-added tools the aggregator is offering like higher-level APIs or slick User Interfaces to create, manage and evaluate the mobile engagement. Concretely for RCS, we are talking about chatbot and campaign design tools. It might include artificial intelligence for Natural Language Processing and intent analysis that helps determine automatically the best response to a user.

We now have finally all the relevant roles to follow the flow of an RBM message from origin to destination. Of course, these are roles, which means that the MNO could also act as an RCS aggregator.

The A2P RBM Flow

Let’s start with a simplified A2P scenario: The brand wants to send out e.g. a reminder message to the end-user that he can pick-up the ordered purchase. We are starting from the moment the chatbot has received that trigger from the supply chain management system – i.e. the chatbot knows the content of the message as well as the target phone number (MSISDN).

The first step is to find out which MNO the phone number belongs to. Figuring out the country is fairly straight forward based on the international prefix. But given that Mobile Number Portability (MNP) is supported in most countries a dedicated lookup is needed for determining the actual MNO, who has issued the SIM card associated to that MSISDN. Given that already today such MNP lookups are commonly used for routing SMS effectively, there are several vendors and solutions available.
Next, the RCS Aggregator has a list of which MNO is served by which MaaP and its associated IP address – you could call this Routing to the correct MaaP.

Now, the actual RCS communication can commence: Asking the MaaP about the RCS capability of the specific MSISDN (in order to determine if an SMS fallback is needed). After these enquiries, the RCS message can be submitted to the MaaP instance. The MaaP instance then hands the message over to the IMS with its RCS AS, which eventually delivers it to the end-user.

One of the strengths of RBM is its full transparency on reporting the state of the message with regards to its delivery status, being read or not, a suggested action being clicked etc. All of these events are messaged back to the chatbot, which allows for detailed reaction to the user’s feedback. It enables also vast data analysis possibilities (unknown to SMS) that can be used to optimize campaigns e.g. by A/B testing different message options.

The P2A RBM Flow

To complete this overview, we also need to mention P2A in contrast to the so far discussed A2P direction. P2A is how the internet works: it is not the website that contacts you, it is the user to discover the right website and actively browse it. For example, a consumer may contact an RCS Customer Carebot by clicking a deep link on a brands website.  Analysts like MobileSquared predict RBM traffic to follow suit and being dominated by P2A sessions.

For P2A to work, the chatbot needs to register itself in a way that allows it to be discovered. There are currently different approaches to the topic of chatbot discovery. Samsung’s RCS client offers a dedicated chatbot tab for browsing and searching chatbots. The MNO configures the RBM directory service provider that handles the entries. The directory service may be the MNO’s or one provided by a third-party.

Another way is to offer RCS P2A Deep Links, i.e. links on a website or 2D barcodes that seamlessly initiate an RCS chat session when clicked or scanned. These links trigger and leverage directly the RCS client on the end-user phone, which not all clients support yet. Google believes in promoting Web URL-links to chatbots as part of e.g. their general search results or map service. Unlike Deep Links the URL-link method is requiring the MSISDN of the end-user to be additionally determined and transmitted and the first RCS message sent is actually an A2P. The advantage is that URL-links can be deployed today as a pragmatic workaround to overcome constraints with RCS P2A Deep Links. Finally, there are other ways, like manually typing in the chatbot name or ID or using an SMS to initiate the RCS chat.

Regardless of the method, the technical key is for the user to find the chatbot ServiceID, which its RCS client can use to invite the chatbot onto a chat session. From then on, each message behaves as shown before on the A2P call flow.

All these call flows simplistically read “MaaP, Managed by MNO”. The next chapter will show that there are actually several options for an MNO to deploy MaaP.

RBM Deployment Options

From on-premise to fully hosted

The on premise way for MNOs to deploy new services is to buy the necessary equipment and software, deploy them on premise, get personnel trained on operating them and offer them to the market.

Assuming a country with three MNOs, this would then look like the following figure:

Each MNO has its own network enabled for RCS (via its IMS and an RCS AS, see the previous chapter) and it runs its own MaaP instance, which offers interfaces to Aggregators. With this setup, the RBM services are offered under the T&Cs of the MNO.

Alternative to self-managed on-premise solutions, the MNO has the choice of outsourcing RBM and P2P RCS in various degrees. In the next figure, MNO#2 has chosen a hosted solution for RCS and RBM, where a third-party is providing all these services in its data centers on behalf of MNO#2. Potentially, MNO#2 could select different third-parties for the RBM MaaP and the P2P RCS enabling. In any case, the services are still offered under the T&Cs of MNO#2

Finally, MNO#3 has opted to not enable its network with RCS, at least for now. In that case, the MNO#3 subscribers could still be doing RCS if a third-party Cloud RCS solution is implemented in that country. In this case, the RCS and RBM services will be offered under the T&Cs of the Cloud RCS provider.

As for selecting the deployment model for MaaP, the MNO should also select the method(s) it wants to support for chatbot discovery as described in the previous P2A chapter.

Every MNO has its own story

In this chapter, we’d like to go through real life experiences that MNOs across the world have on deploying their RBM service.

Summary

One common thread that comes up is ensuring you have a broad awareness of the RBM Ecosystem and steps needed to implement MAAP which this whitepaper has broadly covered.

RBM Platform Selection

When selecting your platform, the first decision is “make or buy?”. If you can make it, you have fullest control and flexibility as attested by Vodafone. It just might not be the fastest option.

So, if you opt for buy, you need to determine if you want to buy the software license and deploy it all on-premise into your own datacenter. That will give you maximum control but might involve some significant upfront investment for software and hardware. KDDI has for example chosen this path.

Alternatively, you can buy and decide to get the solution hosted by a third party in an external cloud or datacenter on behalf of your network. This should be the fastest route to RCS/RBM enable your network, at the cost of only partial control and some dependency towards the hosting partner. There is always an option to move to your own platform once the service is launched.

Commercially, hosted solutions typically come with a revenue share on RBM but less initial investment by Operators, whereas on-premise deployments are done typically with upfront software license fees and yearly software support fees.

The following blog, produced by GSMA ‘RCS goes Mainstream’ provides a wider picture of the deployment options for RCS.

Wider RCS Ecosystem

Apart from selecting the appropriate platform solution, there are other aspects each MNO should consider and explore:

• Talk to your OEM phone vendors – agree support and testing procedures
• Talk to the other MNOs in your country – see if there is common interest like the example of Japan showed. Agree on how interconnections will be handled, GSMA’s MoU is the document to get started there.
• Leverage the wide resources from GSMA on their website

About the Authors

About the GSMA

The GSMA represents the interests of mobile operators worldwide, uniting more than 750 operators with over 350 companies in the broader mobile ecosystem, including handset and device makers, software companies, equipment providers and internet companies, as well as organisations in adjacent industry sectors. The GSMA also produces the industry-leading MWC events held annually in Barcelona, Los Angeles and Shanghai, as well as the Mobile 360 Series of regional conferences.

For more information, please visit the GSMA corporate website at www.gsma.com.

Follow the GSMA on Twitter: @GSMA.

The GSMA RCS initiative brings together the mobile industry’s leading operators, vendors and service providers to shape the RCS specification and implementation. Participating operators have the opportunity to work with software and handset developers, and product and technology experts, to shape the personal and business messaging future for the mobile industry.

For more information on the Future Networks Programme and its work on RCS, please visit www.gsma.com/futurenetworks/rcs/.

Giovanni Benini, Partner at Global Telco Consult, a consultancy firm focused on all aspects of messaging.

For more information please visit the GTC website www.GlobalTelcoConsult.com.