1

An Mformation Whitepaper

PROVISIONING RCS SERVICES ON ENDPOINTS – THE RIGHT APPROACH

1

Provisioning RCS Services on Endpoints – The Right Approach

This paper examines the issues presented to mobile operators provisioning Rich Communication Suite (RCS) services on various endpoints, outlining the options and recommending the most effective approaches.

Introduction – Rich Communication Suite (RCS)

RCS provides an IP-based service that can be used to support a number of competitive services such as phonebook with presence, instant messaging and multimedia calling. These services are designed to compete with non-operator services such as WhatsApp, MSN and BlackBerry Messenger. However, with operator support, RCS services can be utilized across a greater range of networks and devices. This protects an operator from the loss of messaging revenue and provides a more advanced, higher-margin service offering. These types of services are attractive to consumers because they do not rely on any single vendor’s implementation and they can be ubiquitous across many devices and networks. Additionally, as RCS is IP-based, these services will work well in an LTE network, but can also run alongside 3G networks, enabling them to be eased onto the market.

RCS service definitions are developed by the GSMA and are based on standards and specifications from OMA and 3GPP. RCS services are designed to combat the threat of OTT providers such as Skype and Whatsapp by integrating tightly with the device phone book and allowing cross-network interoperability for multi-media data services. RCS currently comes in two flavors, RCS-e and RCS 5.x:

RCS-e is a minimal subset of the RCS and is marketed under the joyn brand name. It provides dual and multi-party instant messaging as well as multimedia content sharing supporting the sharing of pictures, videos and files during a voice call.

2

RCS 5.x, of which RCS-e is a subset, supports all of the RCS-e services as well as IP voice and video communication with presence and location sharing.

RCS 5.x requires significantly more investment in infrastructure compared to RCS-e, and RCS-e is seen as a stepping-stone to the full IP-based video and messaging infrastructure that full implementation of RCS 5.x will bring.

Provisioning RCS Services

RCS services are client-rich, and, like many client communication services, require some form of provisioning. At the simplest level, this is needed to make the services work so that they can be adopted. But provisioning also enables the customer to be billed for the service, activating a revenue stream. Provisioning applies not only to parameters that are service-specific, such as the location of the server and the access point to use, but also user-specific parameters such as the identity and credentials of the user. It is also important to note that the RCS specifications mandate that no consumer access to the provisioning information is available on the device, so there is no option for the consumer to provision RCS services themselves. The intent of the provisioning requirements of the RCS-e specification is to ensure that the services ‘just work’ out of the box, in the same way as other long standing telecom services such as voice, SMS and MMS. Some of the RCS services might also need software or application deployed on the end point to complete the provisioning process.

RCS services are all-IP. At first glance this may seem to be a real advantage, as they are suited to any network type and well placed to take advantage of the latest LTE technologies. However, this also presents challenges, as the most prevalent method of provisioning to date is to use circuit-switched SMS, which is not native to the IP infrastructure. This has meant that the decision about which technology to use for RCS provisioning is not a straightforward choice.

RCS services are based around the IMS architecture, which, in conjunction with LTE, allows for roaming using a breakout model. With this model, when the device roams away from the consumer’s local network, instead of the data traffic being directed to the home network (as is the case in UMTS and GPRS), the data session can be performed locally—the operator picks up roaming fees and the end user has a greatly improved data experience. The consequence for RCS is that to achieve this, local breakout settings are required—as more operators come on stream, this implies a level of continuous provisioning.

3

HTTPS-Driven Provisioning

Within the RCS-e 1.2 specification, there is detailed a provisioning mechanism that relies on HTTPS. This approach works by the device connecting to the provisioning server in its local network each time the device starts. The device uses HTTPS to send its current profile version to the provisioning server. If the version in the provisioning server is higher, a new profile is returned.

There are a number of issues with this approach:

Devices must constantly poll the provisioning server, regardless of whether a profile needs configuring. In fact, the number of times when provisioning is actually performed will be very small—less than 1% of the time—even though the system and surrounding network will have to be dimensioned to ensure that it can cope with the level of traffic caused by constant polling.

This mechanism is optimized specifically for RCS services; it is not evident that other services could utilize its capabilities. This means that the mobile operator may have to consider deploying two systems for provisioning, one for RCS via HTTPS and one for other legacy services such as browsing, MMS, email, etc.

HTTPS provisioning requires the upgrade of the local packet data network so that the DHCP server is used to redirect the device to the provisioning server. Because the DHCP server is in the home network, it is not possible to use it when a subscriber roams abroad. This would mean that if a subscriber purchased or swapped phones while abroad, the RCS service would not work. How significant this would be depends to a large degree on the characteristics of the territory; in some countries, such as Japan, it probably does not matter, as the amount of roaming traffic is small, but in many European territories this could be a serious shortcoming.

To support the local breakout model, RCS settings will change over time as operators build agreements with each other for the localization of data traffic. Because HTTPS provisioning only operates in the home network, it would not be possible to improve the consumer’s data experience when an issue is detected. Instead, the local breakout settings could only be updated when the consumer returns to the home network.

As the contact with the provisioning server only occurs during the initial boot of the device, this limits the number of use cases for this mechanism, other than initial provisioning. A key example is the case of customer care intervention when a repair, removal or update of a profile is required to complete a query from a subscriber.

4

Because the HTTPS provisioning approach relies on toggling the device off and then on again, any communication with the customer care representative would be lost at that point, making the intervention very cumbersome, if not impossible.

Because the device will utilize the cellular connection each time it restarts, it will be using wireless data capacity regardless of whether the subscriber wants to or not. The actual amount of data is not particularly significant—in the region of 1 Kbyte per day—but some customers may be annoyed at this, particularly if it puts them above their data billing thresholds. Also, as the access points are configured as part of the provisioning process, it is not even possible to direct this data onto a free-to-use APN. The biggest impact of this issue may be the increased number of billing queries and refunds that may be required.

Given the above, mobile operators should be very careful when considering an HTTPS provisioning option for RCS services. On the face of it, it seems simple enough to pull the profile via HTTPS, but there are significant operational overheads and shortcomings that need to be well understood before selecting this option.

Client-Initiated OMA DM Provisioning

OMA DM (device management) is defined by the Open Mobile Alliance and provides a framework for the implementation of a large number of services, including the configuration of services such as RCS.

Provisioning of RCS services, as captured in the GSM specification, also allows for a "client-initiated" approach. Client-initiated means that when a new SIM card is inserted into a device, the OMA DM client will initiate a session with the provisioning server, which will insert the provisioning profile for RCS onto the device. As OMA DM is already used for provisioning other services, RCS services can easily be included in the provisioning flow, making a clean user experience without the need for SMS. OMA DM has a significant advantage compared to OMA CP (legacy SMS-based provisioning) in that, because it is IP-based, it can transfer large payloads to and from the device. This is essential for the configuration of large items such as security certificates.

To be able to initiate an OMA DM session, the device must be bootstrapped to the provisioning server. There are a number of ways of achieving this—the device can have the bootstrap settings installed at the manufacturer or they can be transferred from the SIM at SIM insertion. Alternatively, bootstrap settings can be sent via OMA CP from the provisioning server, assuming that SMS is available.

5

Server-Initiated OMA DM Provisioning

Server-initiated OMA DM provisioning does not suffer from the drawbacks of HTTPS-based transport. In this case, the server is initiating the OMA DM session rather than the client. It is useful for initial provisioning, subsequent provisioning, repair or even removal of service settings. Software update features such as application deployment and firmware udpates are also availabale.

For RCS, subsequent provisioning can be used for the provisioning of local breakout information, to improve the end-user experience when a subscriber is using RCS services outside of their local network. A key benefit of server-initiated OMA DM is that it allows the continuous maintenance of these settings regardless of the location of the device. As these settings are directly related to improving the roaming experience, the ability to update them at any time is a key advantage.

Server initiation relies on an SMS bearer to kick off the OMA DM session, so some form of SMS would be required for this mechanism. This does not, however, need to be circuit-switched SMS, as the RCS standard provides for IP-based SMS. If IP-based SMS has already been provisioned at SIM insertion, then it can be used to initiate the management session. Once this mechanism is in place, it can be used not only for RCS but for other OMA DM services such as firmware upgrade and application management.

Legacy OMA CP Provisioning

OMA CP (client provisioning) is defined by the Open Mobile Alliance and is used widely in GPRS and UMTS networks. The mechanism relies on SMS to deliver the payload, which means that the provisioning content is limited to the characteristics of the SMS service—characterized by low payloads and high latency. OMA CP is well understood and widely deployed; at first glance it would seem that using it to provision RCS would amount to just adding a few more services to a simple, well-understood mechanism. But there are issues to keep in mind if we consider this a bit further.

OMA CP is not considered to be, and was never designed to be critical to service enablement; it is more of a helper feature for data services such as browsing and MMS. The business case is driven by the fact that it is much easier for a consumer to receive a batch of settings in a group of circuit-switched SMS messages than it would be to type them in by hand. Because of this, the usual device implementations vary and can involve user interaction. SMS itself does not provide any guarantees on latency and is not optimized for large payloads (RCS services can have 60+ parameters). Also, RCS services are designed to

6

work out of the box—put the SIM in the device and start using the service without any user interaction.

RCS is an IP-only service. This means that circuit-switched SMS may not always be available, either because the device does not support it or the network does not provide it, which is the case in an all-LTE network. It would seem unwise to roll out a service such as RCS, which is used to provide a richer alternative to circuit-switched SMS, while wedding the use of it to the circuit-switched SMS technology it is intended to replace.

Other Provisioning Techniques

A range of other techniques are available for RCS provisioning, each with their own advantages and disadvantages. Two are considered here, pre-loading RCS settings in the device and pre-loading them in the SIM.

RCS settings can be burnt into the device at manufacturer; all the subscriber would need to do is to insert the SIM card into the device. The challenge with this approach is that the RCS settings are specific to an individual subscriber, so the manufacturer would have to somehow make sure that the specific device went to the right subscriber. As SIM cards are freely interchangeable among devices and subscribers, this is a very difficult challenge.

Alternatively, the RCS settings could be burnt into the SIM card; this would overcome the issue of subscriber-specific settings, as the SIM card is subscriber-specific. The issue would be more one of client-SIM interoperability. RCS is a complex service with up to 60+ parameters that need to be provisioned; it would be a real challenge to ensure that each SIM card vendor could interoperate with a critical mass of phone types. It is also anticipated that RCS will change over time, and the cost of repeatedly re-deploying new, updated SIM cards could be prohibitive.

Future Benefits of OMA DM Provisioning

The core to RCS provisioning is the ability to set up the IP Multimedia Subsystem (IMS) on behalf of a subscriber. So far, we have covered the provisioning of these newer, richer communication services, but there is also a transformation occurring for the more traditional voice and text services. This is being driven by technological changes as “all-IP” begins to replace the traditional wireless standards of SS7 (Signaling System No. 7), eroding the cost benefits and flexibility that a single underlying technology brings.

The provisioning technologies detailed herein not only enable RCS services but can also be used to facilitate sister services—SMS over IP and voice over LTE (VoLTE). As the

7

provisioning of services becomes critical to the customer experience—and to the revenue of the mobile operator—a rigorous mechanism is needed to ensure that RCS configurations can survive connectivity, network and device failures, and can recover without any noticeable disturbance to the consumer. OMA DM is seen as key to ensuring this, as it has the capability of not only writing settings but also reading them and repairing them. Once SMS over IP has been provisioned, further management actions can occur that are driven by the management server; this is particularly useful for customer care interaction as it enables the customer care agent to initiate a management session remotely. Using SMS over IP for management has two key advantages over circuit-switched SMS: 1) It does not required circuit-switched SMS, and therefore will work in an all LTE network, and 2) It is all-IP, so it will work wherever there is connectivity, whether the user is on a corporate network or a wireless LAN in a coffee shop, which is particularly useful when performing a repair on an issue that is cellular related.

The extensibility of OMA DM also means that multiple services can be managed in a single seamless session—the RCS services can be provisioned, followed by voice over LTE and SMS over IP as well as browsing and synchronization, followed by a firmware upgrade, all in the same management action from a single management server. Since the emergence of mobile data services at the turn of the millennium, the number of services that require provisioning is only increasing; previous services do not disappear (e.g., browsing), instead more services are simply added.

Conclusions

Within this paper we have covered all the major mechanisms for RCS provisioning. Other than burning the RCS information into the SIM card or the device, there are three key techniques for RCS service provisioning: HTTPS, OMA CP and OMA DM. HTTPS provides an Internet-style mechanism that is very much inspired by the traditional Internet, using DCHP to direct the device to the management server, but it is unclear whether this approach will be suitable for the demands of mobile operators given roaming needs and scaling challenges. Although OMA CP may do the job initially, it is unlikely to be fit for the purpose if the mobile network moves towards all-IP. Only OMA DM provides a solution that counters all of these challenges while building on the benefits of a well-proven technology and without requiring investment in multiple, diverse technologies.

8

The table below summarizes the benefits of each of the major solutions for RCS provisioning.

Characteristic OMA CP HTTPS OMA DM No network impact ● ● Customer not billed ● ● Supports Roaming ● ● Single Management Server ● ● Supports Customer Care ● ● Works on all-LTE network ● ● Works without CS/SMS ● ● Large Payload ● ● No Consumer Interaction ● ● Out-of-network Bootstrap ● Resilient Configuration ●

Given the diversity of device implementations, it is unlikely that the market will move in one direction simultaneously. OMA CP configuration is already here and is strongly supported by device vendors and OEMs alike. OMA DM is supported as well, but not as strongly, probably because of its higher capabilities and associated complexity. Therefore, initially at least, it is likely that to be able to support RCS for a wide range of devices, it may be sensible to support both OMA CP and OMA DM, assuming that the network allows it. With regard to HTTPS, the impact on the network in terms of equipment, capacity and management servers is so large that care should be taken to ensure that the rest of the ecosystem (RCS clients, OEMs, etc.) are fully committed to the approach before embarking on this choice.

9

CONTACT US If you would like to receive additional information on our company and our innovative mobility management solutions, please feel free to contact us. Mformation Software Technologies, LLC 581 Main Street, Suite 640 Woodbridge, NJ 07095 Tel: +1 732 692 6200 Fax: +1 732 549 7542 www.mformation.com info@mformation.com

© Mformation Software Technologies LLC. All rights reserved