Making RCS work: the architecture of RBM
Rich Communication Services (RCS) is often touted as the Next Big Thing, but even its strongest evangelists acknowledge that its adoption and rollout has been slow. While enterprises are attracted by its many advanced features, opening up new opportunities for mobile marketing, making those features available in a consistent way has been difficult and slowed down by fragmentation. We looked at these issues, and recent developments, in a previous article. There we noted how progress is beginning to take shape – more and more operators are adopting the latest GSMA Universal Profile, and enterprises are starting to develop more ambitious use cases to test out the format. But how is this being achieved? Let’s consider the elements necessary to make A2P RCS – often called RCS Business Messaging (RBM) – a reality.
Perhaps the first thing to consider is of course infrastructure – the hardware and software with which RCS communications are handled by operators. For P2P messaging between subscribers on the same network, this can be handled by the network’s RCS core platform. However, this incorporates more than just a messaging server. RCS is IP based (as opposed to SS7, like SMS), and it can carry a variety of data types and formats, so it also requires a content server and an IMS (or IP Multimedia Subsystem).
This allows the core platform to handle all the operations necessary for subscribers to send messages, images, and even files (via FTP), as well as handling the system information that enables things like delivery and read receipts. The platform can itself be built and run by the operator, or it can be hosted for the MNO by another company. Jibe from Google was one of the first such hosted solution, but now other companies are beginning to offer hosting services to operators looking for a low-cost, quick route to enabling Rich Communication Services on their networks.
In order for subscribers on different networks to communicate the network operators need to interconnect their RCS platforms, either through interworking agreements or through a hub which connects to multiple MNOs, much as they do with SMS currently.
A slightly more complex arrangement is involved in enabling RCS Business Messaging, which comprises the A2P and P2A functions of RCS. Again, some of this is very similar to how A2P SMS works: enterprises and brands will usually work with a messaging aggregator (rather than contract with every operator in their target region) who will process their messages and send them to the correct network. More specifically, to each network’s MaaP.
What is a MaaP?
This is another instance of a recent trend for following the “[x] as a [y]” naming formula for new systems and services, in order to create an arcane acronym – in this case “Messaging as a Platform.” A MaaP is actually a network interface which checks RCS readiness for Business Messaging and routes the messages. Each network will have a MaaP, and the aggregator, once it receives a message from a client, will pass that message on to the appropriate MaaP depending on the MSISDN (the subscriber’s phone number) it is being sent to. The MaaP asks the IMS to check whether the subscriber’s phone can receive RCS messages – which in time will be almost everyone with an Android OS. If they can, it delivers the message over the core platform, if they cannot it will inform the aggregator. In most cases, this will mean the aggregator will simply send an alternative SMS version of the message via the operator’s Short Message Service Centre (SMSC).
But why is a MaaP necessary for RBM? Why can A2P (and P2A) messages not be sent directly through a network’s core RCS platform? Simply put, it is because the MaaP is one of the components that makes RCS so valuable to enterprise clients. A MaaP handles and verifies service-IDs, which identify enterprises to subscribers. This is good news for subscribers – and the network – as it ensures they know who is sending the messages. But it is also good for the senders themselves, as it enables custom branding which creates a more professional and engaging experience, like Nottingham Forrest FC’s recent campaign. (Plus, in verifying the identity of a sender to the recipient, this system reduces the potential damage to a brand that can be caused by fraud and spam.)
As with the core platform, some MNOs have developed their own MaaP, while others are turning to hosted MaaPs.
RCS as a channel for dialogue
Although it sounds complex, there really are only a few parts necessary to getting RBM functioning. Once these elements are in place it becomes comparatively simple to begin sending RCS messages to subscribers. Multimedia elements – such as images and logos – are handled by a content management system (CMS) which is usually managed by the aggregator. So, all a brand has to do is settle on a message, upload their media, and begin.
Chatbots, another exciting new technology, have proven a big draw with several enterprises looking to exploit RCS for interactive marketing, since the two technologies synergize well. They also offer new kinds of functionality, and even the potential to extend core business functions – such as checking one’s bank balance and interest – or perform routine customer service.
Incidentally, this is another function of the MaaP – part of its job in verifying sender-IDs is registering chatbots. When an enterprise creates a chatbot they register its sender-ID with their aggregator, who in turn registers it on the MaaPs to which they are connected. When a user contacts a chatbot their smartphone connects to the MaaP, finds the sender-ID and initiates a chat session. (Some Samsung devices in markets where RCS is already launched have a chatbot search tab in their contacts app which facilitates this process by making it easier to find a company’s chatbot.) The MaaP then processes the two-way messages that constitute the chat session.
Rich Communication Services is generally credited as being more secure. This is largely because of the aforementioned rigor in assigning and handling sender-IDs: subscribers can easily tell the difference between a genuine sender and an attempt at fraud. Also, companies that send lots of spam, or don’t respect subscriber requests to opt-out, risk losing their sender-ID and therefore their ability to use RCS.
It is also encrypted, although there is some controversy around this. RCS messages are encrypted while in transit, making it difficult for criminals to intercept messages, an improvement over SMS. On the other hand, there is no end-to-end encryption, where only the participants have they keys required to decrypt and read a message. It is unclear why this is; one possibility is the complex regulatory environment and the many involved players (which is partly why RCS standards took so long to become, well…standardized). This doesn’t mean that end-to-end encryption is impossible: one representative from Google, which is often cited as the main culprit, recently suggested to The Verge that “we can address those things. … I’m sure we can evolve the standard to handle these cases.”
Whether it is P2P, A2P, or P2A, RCS promises to enhance messaging in ways that operators and enterprises have been hoping for since the early days of MMS. There is more functionality, more flexibility, and a better all-round experience. And, as we have just seen, it is becoming clearer how to get these features into the hands of users. There is even a growing number of international interconnections, as the organizers of MWC19 demonstrated with their RCS service introducing attendees to this year’s conference.
Launching RBM isn’t quite a case of simply deploying the technology and flicking a switch – although hosted solutions do make this process easier – but it should now be simple to see how operators and enterprises can join their peers already using RCS messaging, and the steps involved in running an RBM campaign.
GMS are excited about this evolution of mobile messaging, and to offer our expertise and guidance in exploring its opportunities.