PROVISIONING RCS SERVICES ON ENDPOINTS - THE RIGHT APPROACH - An Mformation Whitepaper
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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.
1 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.
2HTTPS-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.
3Because 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.
4Server-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
5work 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
6provisioning 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.
7The 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.
8CONTACT 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 9
You can also read
