Professional Documents
Culture Documents
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.
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.
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 smallless than 1% of the timeeven 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
consumers 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.
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 significantin 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.
work out of the boxput 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.
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.
The table below summarizes the benefits of each of the major solutions for RCS provisioning.
Characteristic
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
OMA CP
HTTPS
OMA DM
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.
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