GSMA Universal Profile is a technical
enabler for advanced communications that has been published in November 2016.
To specify its features and relevant technical documents, 47 operators and 11device manufacturers and 2 mobile OS providers have committed to supporting a
single, standard implementation of the Universal Profile. Since this new RCS
specification has come out, Google renewed its Android
Messages to be compliant with Universal Profile and provided it as a pre-loaded
messaging application to several carrier partners, i.e., Sprint, Rogers,
Telnor. The Android Messages has integrated native OEM
applications such as SMS, MMS. Subscribers of those carriers can manually
select the default messaging application between OEM SMS client and Android
Messages.
I. Standards roadmap of Advanced
Communications
The OMA has specified the IP based
messaging service and relevant technical specification, i.e., SIMPLE IM, in
early 2000. Since then, the OMA developed the concept of Converged IP
Communication on top of SIMPLE IM by incorporating voice/video media streaming,
interworking with legacy messaging services and more affluent features in IP
messaging.
(1) GSMA RCS 1.0 has adopted OMA SIMPLE 1.0 in its early
stage. The RCS 2.0 incorporated new requirements for multiple devices where the
mobile device with SIM card is a primary device and the secondary device
shares the MSISDN of the primary device. RCS 3.0 enhances some of features in
the previous versions by, e.g., including sharing location information in the Social
Presence Information, providing the list of participants in a group chat,
Contents Sharing without voice calling, etc.
(2) GSMA defines its own brand name, Joyn, to promote RCS
implementation and marketization. The first version of Joyn, HotFix (HF), is mainly
based on RCS 2.0 features. There were several operators who have started Joyn HF
commercial service e.g., SKT, LG U+ and KT in South Korea, Vodafone and Orange.
But, they failed to penetrate the market as existing OTT services were already
dominating the market. The Joyn HF’s service features were not attractive
enough to compete with OTT services. Moreover it was provided as OTT
application so it was even harder to attract locked users to change their
communication tools. The monetization strategy of Joyn HF was unclear. All in all, majority
of operators were hesitating to plunge themselves into RCS.
(3) RCS4.0 adopts OMA CPM 1.0. as a
baseline, which represents “Converged IP Messaging”. It includes some of advanced
features that were not handled in SIMPLE IM such as Standalone Messaging,
Legacy Messaging service interworking, Network based Common Message Storage,
etc. The concept of CPM is to converge all the type of communications such as IP Chat, IP voice/video and legacy messaging services, CS voice/video calling, etc.
(4) IP-SM-GW is a 3GPP Network Element
(NE) that converts and relays the SIP messages to SMS and vice versa. Originally,
the CPM 1.0 supports the interface with IP-SM-GW to provide SMS interworking. As
RCS 4.0 takes the CPM 1.0 as a baseline, the IP-SM-GW interface has also been
included in the RCS.
(5) RCS 5.0 merges Joyn HF and RCS
4.0. Meanwhile OMA reflects the added features in RCS 5.0 to CPM 2.0 e.g., notifications within a chat session, closed chat,
long-lived group chat, file transfer pause and resume, etc. to cope with GSMA RCS.
(6) OMA also reflects the enhanced
features in RCS 5.0 to SIMPLE IM 2.0 i.e., stored and
forward, display notification to cope with GSMA RCS.
(7) GSMA has published the new version
of Joyn, that is, RCS Blackbird which mostly focuses on relatively simple
features and integrated user experiences to meet time-to-market. The RCS
Blackbird excluded Presence and the relevant features, IP voice calling, etc,
for simplicity. There were many RCS players at the moment. Among them, Marvenir
was acquired by MiTel and again by Xura. Jibe Mobile was acquired by Google and
currently playing the key role in developing cloud based Google RCS. NewPace
was acquired by Samsung. There are also WIT Software, InterOp technologies, NeuSoft, Nable Communications, etc.
(8) Many of excluded features in RCS
Blackbird e.g., Presence, Network based SMS interworking, etc., have been re-incorporated into RCS Crane.
(9) Google joined in GSMA RCS
initiative in implementing RCS Universal Profile specifications based on RCS 6.0 and RCS 5.3.
II. Service features
(1)
Auto Configuration Provisioning
The
configuration provisioning is a procedure to provision service related
configurations to RCS enabled devices. The configuration parameters
contain various parameters relating to user authentication and authorization, IMS access point, RCS service features, RCS client’s
behavior control, user preferences, roaming behaviors, etc. This procedure
occurs as part of service activation when the RCS client is invoked for the
first time and thereafter may occur upon device reboot, service provider’s
request, SIM swap, etc.
Upon receiving the provisioning request
from the RCS client, ACS may perform IMSI based user authentication as a
default. If it fails, the ACS switches to OTP based authentication where the OTP
is generated by the ACS and sent to the user’s primary device using SMS or End User Confirmation Request (EUCR) message. This SMS fallback may occur in the following context:
- The RCS client can’t access the SIM card.
- The RCS client accesses through Wi-Fi.
Service provider may initiate the configuration
provisioning as per RCS updates, configuration
parameters updates, T&C updates, etc. In this case, the ACS triggers the RCS
client by sending notification to initiate the procedure.
(2)
IMS registration
Once the auto configuration provisioning
is completed, the RCS client accesses the IMS core using the provisioned IMS
parameters. If RCS client is embedded in the UE being provided as an opt-out service,
the P-CSCF discovery occurs during the UE’s initial attachment. Otherwise, the RCS may use the P-CSCF information obtained from the provisioning configuration parameters.
(3)
Service Capability Discovery
The service capability discovery is a procedure to figure out service
capabilities of a contact in the address book to determine whether the contact
is an RCS user or not. It occurs right after the RCS client successfully registers to
the IMS network. The service capability discovery may occur more often in the
following context:
- Initial address book scan at the very first time discovery during service activation.
- New user discovery when a new contact is added to the address book
- Periodic polling based on polling period (Provisioning parameters)
- Real-time fetch when a user attempts to communicate with another user
- Refresh as per user's request
As frequent service discovery can
cause heavy traffic in the network, service providers need to regulate the
traffic using relevant configuration parameters. There are two ways to
implement this feature as below. Which one to use as a default for service capability
discovery will be determined by the provisioned configuration parameter.
- The presence based service capability discovery
- The SIP OPTIONS based service capability discovery
(4)
Standalone Messaging
The standalone messaging provides uni-directional
messaging service experience as it technically does not establish conversational session between users. The pager mode message is used when the message
size is less than one MTU (1300 bytes) in which case the message is delivered
using SIP MESSAGE. If the message size is bigger than one MTU, RCS client will
switch to large mode message using SIP INVITE and MSRP to deliver the message. Deferred
Message delivery is the same feature as store-and-forward in 1-1/group chat
where the message is temporarily stored in the server when the recipient’s RCS
client is not available to receive the message. When the RCS client becomes
available, the stored message is retrieved and delivered to the target RCS
client.
(5)
One to one Chat
The one to one chat is a session based
messaging between two users where the message is delivered through MSRP
session. The IMDN (i.e., delivered, displayed) indicates the delivery status of
the message and it is mandatory in RCS to support ‘delivered’ IMDN for each message.
The IsComposing (or IsTyping) notification indicating the peer status of typing
the reply message is also supported. When the recipient is not available
to receive the message due to e.g., connectivity loss, battery drain , the
message is temporarily stored in the server. when the recipient's RCS client becomes available within the
expiry time, the stored message is retrieved and delivered to the RCS
client. The temporarily stored message will be discarded after the timer is expired. If
the message has not been delivered yet, the originator can also revoke the sent
message.
(6)
Group Chat
Group chat is a
session based messaging among more than two participants. The ad-hoc group chat
session can be created by selecting more than one contacts from the address
book or by inviting another RCS user in a one-to-one chat. When the group chat session
request is received, the recipient’s RCS client may automatically accept the
request on behalf of the user or the RCS user may explicitly accept or decline
the group chat request as per user's preference.
NOTE the auto
acceptance for group chat is set to ‘1’ in BB and CR but it is configurable in
UP.
The participant
information indicates the participant's status of joining or leaving the group
chat and it is informed to all the other participants whenever the event occurs.
Once a participant leaves the group chat session explicitly, the leaving participant
can rejoin the group chat only when he/she is invited by another participant.
If the participant leaves the group chat unexpectedly due to e.g., connectivity
loss, battery drain, the participant can rejoin the group chat as long as the client retains the conference-uri of the group chat session. In this case,
the store-and-forward mechanism is applied to the missing conversation history when
the leaving participant rejoins.
When the group
chat session has been released out of inactivity, a participant can restart
the group chat session by sending any messages within the conversation thread
of the group chat.
(7)
File transfer
File transfer is
a unidirectional transfer of discrete media such as audio clip, video clip,
images, binary files, etc. Files can be transferred within the context
of a chat session or a standalone message. Technically, file transfer session
is established separated from the existing chat session so the user can proceed
the chat without interruption. But the transferred file appears in the same context within the ongoing conversation thread. When
sending a file transfer request, the originating RCS client includes file
information such as file type, size, thumbnail preview based on which the
recipient may determine whether to accept the file transfer request or not.
Two
different ways to implement the file transfer in RCS are MSRP and HTTP, but they don't make any differences in terms of user experience. The HTTP
based file transfer is similar to indirect message delivery, that is, the file
object is uploaded to the contents server and the RCS client obtains the location url of the stored object. As a result, it is the location url that is sent to the recipient's RCS client alongside the file information rather than the file object. Upon receiving the location url, the
recipient may determine to download the file object or decline the file transfer. In principle, file transfer session can be established only with an explicit acceptance by the recipient but auto acceptance
can also be applied according to the configuration.
In case
the file transfer is interrupted out of e.g., connectivity loss, or paused by
the either end user, the process can resume when the network connectivity is recovered
or as per user's request. If the file transfer is not
completed yet, the either end user may also cancel the file transfer. Once file
transfer is completed, the corresponding IMDN is sent to the originating RCS
client. In the same way as one-to-one chat and group chat, the store-and-forward mechanism is applied to the file transfer when the file can’t be delivered
due to unavailability of the recipient.
Upon
sending a large file, RCS client may warn the user of the maximum size limit. The maximum file size is configured by service provider in the provisioning parameter.
(8) Geolocation
Sharing
RCS user can send his/her own
geolocation to another RCS contact. The geolocation information can be sent
through the existing IP chat session or in a separate file transfer session. Once
the geolocation information is received, the recipient's RCS client may show it on the map
available in the handset e.g., google map.
(9) Audio
messaging
RCS user can record the audio message and sends
it to one or more RCS contacts by re-using file transfer mechanism. The detailed features of audio messaging are same as file transfer.
(10) Black list
RCS user can maintain (i.e., add, revoke) the local black list in his/her own device. Once an RCS contact is selected as a blacklist by the user, any of conversation attempt from that
contact e.g., 1-1 chat, group chat, file transfer, geolocation push, enriched
calling, etc are not notified to the user.
(11) Centralized Message Store (CMS)
The CMS is used for back-up and synchronization of conversation history between the network repository and one or more RCS clients. RCS client
needs to get authenticated to access the CMS using either AKA or basic
authentication method. All the RCS messages such as IP chat,
file transfer, IMDN and legacy messages (e.g., SMS, MMS) are stored in the
CMS according to relevant configuration parameters. Event Reporting Framework
enables RCS client to send a notification to RCS server indicating the message
flag updates e.g., “\seen”, “\deleted”.
Upon receiving the notification, the RCS server updates the corresponding
message status stored in the CMS and in turn, the updates will be synchronized towards other multiple devices if any.
(12) Legacy Messaging Interworking
RCS
integrates legacy messaging services and IP messaging service. The integration of legacy messaging services can be implemented either by the RCS client at local device or by providing legacy interfaces (e.g., SMPP, MM4) from the RCS server. The client level integration includes the integration of message composer, message database, conversation history thread and receipt notification. The messaging service type to be used for sending a message is determined by the RCS client
considering the access network availability and capability of the recipient’s RCS client. If legacy messaging interworking is supported by the RCS server,
all the messages sent by the RCS client should be RCS message and the messages are converted
and forwarded towards the recipient’s UE through legacy network if the recipient is not an RCS user.
To
assure the message delivery, the RCS supports two different modes i.e., Client Fallback to SMS (CFS) and Network Fallback to SMS (NFS). When the CFS is enabled, the undelivered message can be sent as SMS
either manually or automatically according to user preference. When the NFS is
enabled, the RCS server is responsible for fallback to SMS when the message
delivery fails. The CFS and NFS mechanisms are applied to 1-1 chat and file
transfer.
(13) Multiple devices
The
multiple devices environment should be considered across most of RCS features.
When the RCS user uses a secondary device for RCS, the SMS based authentication is applied as the
secondary device won’t be able to access the SIM card and therefore can't obtain user’s
IMSI number and the UE will access the network through Wi-Fi. Upon IMS registration, RCS client needs to support ways to represent multiple device instance such as gruu, UUID, etc. RCS server also needs to support
application level forking for service capability discovery, 1-1/group chat and file
transfer. Upon service capability discovery, the RCS server aggregates the responses from each multiple RCS clients of the recipient and send it back to
the originating RCS client. Audio messaging and Geolocation push reuses the file
transfer mechanism. The conversation history stored in the Centralized Message Store (CMS) is synchronized across multiple devices. With Event Reporting Framework
incorporated, the message status of each stored message is also synchronized in real time.
(14) Voice Calling
RCS
supports Green Button Promise for voice calling which converges CS voice calling and IP voice calling. Typically, user can choose which one to use depending on the
network quality and RCS client's service capabilities. RCS voice calling also supports
emergency calling, supplementary services and DTMF detection. The seamless
voice call continuity shall be supported when the access network changes.
(15) Video Calling
RCS
supports Green Button Promise for video calling which converge CS video
calling and IP video calling. Typically, user can choose which one to use depending on the network quality and RCS client's service capabilities. The seamless video call continuity shall be supported when the access
network changes. When the network quality is not enough for video, the video
calling may downgrade to voice calling as per client's decision.
(16) Enriched calling
The
Pre-call sharing enables users to share information such
as call priority, subject, image and
geolocation before voice calling session is established. The In-call sharing is to share image, file, live-video or live sketch during voice calling.
The In-call sharing media session is subject to existing voice calling session therefore the
sharing feature is disabled when the voice call session is released, put on
hold or affected by any supplementary service. The Post-call sharing is to
share a note or voice message after the voice calling session has been released.
III. Remarks
The main purpose of RCS is to evolve existing legacy communications to IP based ones by converging all type of communication services. But behind the scene, this evolution has more implications than that. As of recent, the A2P messaging (i.e., business messaging) has come into picture as a way to monetize the RCS messaging. Even though SMS traffic is expected to increase for a while along with increasing needs for A2P messaging, more and more A2P messaging aggregators are already turning their eyes to cheaper OTT messages from SMS, which is never surprise considering the customer size of those prominent OTT services. It is obvious that SMS which already lost its ground in P2P messaging will also lose its ground in A2P messaging sooner rather than later. The concept of Messaging As a Platform (MAAP) envisages long term strategy of RCS on top of which 3rd-party service providers are placed and provide various services such as Chat Bot. The Chat bot is becoming another prominent way for enterprise to engage with their customers. Many of OTT services are adopting Chat Bot to provide enterprises with another way to communicate with their customers. Most of operators are already lagging behind in this battle with OTT service providers as they stick to legacy messaging.
Red Mouse
References
[1] GSMA RCS UP, "RCS Universal Profile Service Definition Document v1.0" 16th Nov 2016