1. Introduction

Chronologically speaking, the RCS Blackbird (RCS BB) has been published by GSM Association (GSMA) after the RCS r5.1 came out. The RCSe focuses on a simple IP chat feature while the RCS r5.1 provides converged IP communication service feature. The RCS BB provides the intermediary service features between two different versions (i.e., RCSe and RCS r5.1) by integrating legacy messaging functions (i.e., SMS, MMS) and IP chat function at UX/UI level and adopting many other functions from RCS r5.1. This way, it tries to provide the same level of unified and consistent user experiences with RCS r5.1. The Voice over WiFi (VoWiFi) and IP video call service features are also supported through the best effort network along with VoIP break-in and break-out functions, which enables RCS users to communicate with CS/PS voice call users in the same way as they use traditional communication services.

2. Configuration Provisioning

The configuration provisioning is a procedure to provision service-related configurations to RCS enabled devices. An RCS enabled device uses received configuration parameters to access IMS core and RCS service. Therefore this procedure is supposed to happen at least once right before UE registers to the IMS core for the first time.

Table 1. Configuration Provisioning

n Provisioning over non-PS Network
Compared to the RCSe where only PS access devices are covered, the RCS BB supports multiple devices by considering non-PS access devices. The RCS BB can be installed and used from any device with/without SIM card through either PS or Wi-Fi access network. The following is a possible situation where an RCS enabled device accesses the configuration server via non-PS network.

• User's primary device connecting via Wi-Fi
• User's secondary device without or ignoring a SIM card (with the primary identity)

n SMS-based Authentication using One Time Password (OTP)
In case the RCS enabled device accesses the configuration server through the PS network, there can be several options for a configuration server to authenticate the UE, for example, IMS based authentication, UE IP address based authentication, etc., according to the operator's policy.

When the RCS enabled device accesses the configuration server via non-PS network such as Wi-Fi, the configuration server cannot authenticate the device using the same way as for PS-access device, because the device is typically assigned with a private IP address. Furthermore, the secondary device that is sharing the same identity with the primary device can't obtain an IMSI properly.

When there is no other way to authenticate the device, the configuration server may perform OTP based authentication. The configuration server generates an OTP and sends it to the primary device of the user using SMS. It is preferred that the SMS with OTP is transparently delivered to the RCS client without user interaction. If not possible, the OTP is delivered as a standard SMS so the user can manually input the received OTP to the RCS client regardless of whether the RCS client is running on the primary device or on the secondary device.

Note: In RCS r5.1, the OTP can also be delivered using End User Confirmation Request (EUCR) as an alternative way to using SMS. In this case, the OTP is included in the XML body of SIP MESSAGE and delivered to the RCS client via IMS network.

n Network-initiated Provisioning (reconfiguration)
The configuration server can trigger the RCS client to initiate the configuration provisioning, e.g., in the following situations:

• Changes in service related configurations
• Version updates of RCS client
• Activating the disabled RCS client in a user's device

The triggering notification is sent as an SMS or EUCR. Upon receiving the configuration triggering notification, the RCS enabled device de-registers from the IMS core before initiating a new configuration procedure.

n User Messages using EUCR
The user message can be sent, for example, to inform a user of new terms and policies or service related notices. The user message is unidirectional in many cases and so the configuration server may require user interactions when the user's consent relating to changes of terms and policies is required. The user messages can either be provided as part of a configuration XML document delivered in the response to provisioning request or be sent as a standalone message. Upon receiving the user message, the RCS client shall determine whether to pop it up to the user or not.

n RCS BB Configuration Management
The configuration parameters consist of various type of Management Objects (MO) with high granularity for each service feature like presence, XDMS, IP chat, file transfer, contents sharing, IP voice/video call, etc. They also contain network management objects such as IMS/SIP related configurations as specified in the 3GPP [TS24.229], APN configurations, etc. The service provider can enable/disable the RCS client installed in the UE and can even control the behavior of that RCS client somehow. In principle, the RCS BB covers all the configuration parameters as defined in RCS r5.1, but many of those parameters are set to be a certain value, as such the corresponding functionalities are to be used in a limited way or disabled.

3. Service Capability Discovery

The service capability discovery is a procedure to find service capabilities of a contact in the address book in order to figure out whether the contact is an RCS user or not. This functionality can be realized in two ways based on the applied technology and use cases in which it is used within the RCS service context: Presence based and SIP OPTIONS based. The presence based service capability discovery uses presence technology to obtain the capabilities of a contact or a group of contacts. But, the SIP OPTIONS based service capability discovery uses SIP OPTIONS message to obtain the capabilities of a contact. The SIP OPTIONS based service capability discovery can be applied (1) when the capabilities of a contact is not determined, (2) when the contact is determined as non-RCS user, or (3) for real-time fetch of contact's capabilities whenever the user attempts to communicate with that contact. Once the contact turns out to be an RCS user as a result of service capability discovery, the contact information will be added to the RCS contacts list. Once the RCS contact list is created, the UE can apply the presence based methodology for that group. One of the advantages to adopt the presence technology for service capability discovery is that it supports group based function (i.e., list-subscription and back-end subscription), thereby reducing traffic between the UE and the network.

In RCS BB, the presence based service capability discovery feature has been disabled to avoid the complexity and for time-to-market service. Therefore all the service capability discovery features will work only when using the SIP OPTIONS based technology.

Table 2. Service Capabilities Discovery

n OPTIONS AS for SIP OPTIONS based Service Capability Discovery
The OPTIONS AS is used to support multiple devices. It performs service level forking for incoming SIP OPTIONS towards multiple devices of a target user, aggregates responses from each multiple device, and sends the response to the originating RCS client. The capabilities of an RCS client are determined based on collected capabilities from the user's multiple devices, but at the same time the RCS client also needs to consider the network status at the moment. For instance, even though the RCS client supports IP video call, if the network does not support the proper QoS (e.g., bandwidth) at the moment, the IP video call capability of the RCS client will be disabled.

n Capability Exchange Optimization
The SIP OPTIONS based service capability discovery has a known issue that it can possibly cause heavy traffic sporadically. When a user installs the RCS client and subscribes to the service for the first time, the RCS client accesses the user's native address book in the UE and performs the SIP OPTIONS based service capability discovery procedure for each contact as capabilities of all the contacts are unknown to RCS client. Therefore each RCS client will make as much amount of traffic as the number of contacts stored in the address book. Furthermore, the RCS client is supposed to fetch the capabilities of the target contact in real time whenever the user attempts to communicate with that contact.

The following shows some scenarios where service capability discovery procedure is supposed to take place:

• First time service capability discovery when the RCS client is invoked for the first time
• Periodic service capability discovery when the polling timer is expired
• Real time service capability discovery when the RCS user initiates any communication to any contact
• New user discovery when a new contact has been added

The RCS BB recommends to use RCS BB specific parameter to mitigate heavy traffic. For instance, MESSAGING CAPABILITIES VALIDITY indicates the valid time of the obtained capabilities of a contact. The RCS client does not send a SIP OPTIONS in any case when the capabilities of a contact are still valid.

Note: The RCS r5.1 incorporates the presence based service capability discovery. The SIP OPTIONS fallback mechanism is to attempt the presence based capabilities discovery at first and if it fails, the RCS client may fall back to the SIP OPTIONS mechanism which would be the way to reduce SIP OPTIONS traffic.

4. One to One Chat

The one-to-one chat is to establish a chat session between two RCS users. When an RCS user sends an IP chat invitation (i.e., SIP INVITE), the message is delivered to the RCS recipient via IMS core. If the recipient RCS user is not available at the moment, the IP chat invitation can be temporarily stored in the RCS AS and forwarded to the recipient when he/she becomes available. Once the message arrives at the recipient, the recipient's RCS client sends back Instant Message Disposition Notification (IMDN) messages i.e., delivered and displayed, to inform the originating user of the message delivery status. The "IsComposing" message can also be sent towards the peer end when a user is typing a message.

Table 3. One to One Chat

The RCS BB reuses all the IP chat features of RCSe and it supports multiple devices as well. The multiple devices control like message forking shall be performed by the RCS AS rather than IMS core. The service level forking is applied to the IP chat invitation. The RCS AS distributes the IP chat invitation to all or some of multiple devices of the recipient. When the recipient RCS client responds from one of his/her device, the other chat invitations sent towards other devices shall be cancelled. The forking mechanism is not applied to the IMDN coming from the recipient RCS client even though the originating RCS user has multiple devices, because the IMDN is supposed to be delivered to the specific originating device which initiated the corresponding IP chat invitation.

Note: One-to-one session extension is to extend a one-to-one chat session to a group chat session by inviting another RCS user(s). This feature has been removed in the RCS BB but incorporated in the RCS r5.1.

5. Group Chat

Group chat is to establish a chat session for more than two participants. The ad-hoc group chat indicates the way of selecting participants where the user selects contacts one by one from the address book. It is distinguished from pre-defined group chat where the participants are selected based on the pre-defined group list in the address book. Within the group session, when a participant newly joins or leaves the group chat, the other participants are informed of that participant information for this event.

Table 4. Group Chat

n Store and Forward in a Group Session (Basic, Full)
The RCS BB extends the user experiences of store and forward in a one-to-one chat to a group chat. With store and forward function, participants can receive missing conversation history when he/she enters the group session late or when rejoining the group session after involuntary disconnection.

Note: The RCS BB standards specifically addresses that the store and forward function in a group session is not technically supported but the same user experiences shall be provided. From reader’s perspective, it seems not clear how to implement the store and forward user experiences without technical realization of the corresponding function. Given this reason, the store and forward function in a group session has been included in this article as an RCS BB feature.

(1) Basic store and forward 
Basic store and forward function is applied to a rejoining participant who was disconnected involuntarily from the group session. The participant's involuntary leaving can be detected by the RCS AS based on e.g., no-answer timer expiry, 480 Temporarily Unavailable error response from the IMS core. Operators can also define specific conditions when the participant's RCS client is regarded as having been involuntarily disconnected. In order to realize this function, the RCS AS shall be aware of RCS user's service capabilities in advance. If the participant's involuntary leaving is detected and the participant's RCS client supports store and forward capability, the RCS AS shall take the role of end point for a while on behalf of the disconnected participant's RCS client. If the RCS AS does not support store and forward capability, the RCS AS shall release the group session of that participant.

Note: If a participant leaves a group session voluntarily by sending SIP BYE, the participant will be removed from the list of participants and that RCS user won't be able to rejoin the group session unless he/she is invited to the group session by other participants again.

(2) Full store and forward
Full store and forward feature is applied to a RCS user who joins the group session late. In case the RCS user does not answer to the group session invitation and the RCS client supports full store and forward function, the RCS AS shall take the role of the end point on behalf of the RCS client. As a result, the group session invitation is accepted by the RCS AS serving that RCS user and the media session is established accordingly. The RCS user can receive the missing conversation history after he/she joins the group session late. If the RCS user declines the group session invitation by sending 603 Decline, the RCS AS discards the stored messages.

Restart a Group Session (Long Lived Group)
After a group session is released out of inactivity among participants, any participant in the group session can restart the group session by initiating a chat, file transfer, geolocation sharing, contents sharing, etc within the existing conversation thread stored in his/her RCS client. The RCS AS taking the role of conference focus shall have the group session identity at the moment when the request is received. The restarted group session shall have the same attributes as the previous one. If the group session identity does not exist when the group session restart is requested, the RCS AS responds with 404 Not Found error response and the RCS client may attempt to initiate a new group session with the same attributes. The automatic restart of group session after the 404 Not Found response shall be seamlessly done by the RCS client.

Rejoining a Group Session
A participant can rejoin the group session that he/she was in, after involuntary leaving (e.g., due to connectivity loss, battery drain, etc). In order to rejoin the group session, the RCS client shall be able to keep the group session identity for a while even after it was disconnected.

IMDN in a Group Session
Delivery notification shall be supported in a group session so the originating participant can figure out the status of sent message(s). In case one or more of the target RCS clients do not support the IMDN capability, the RCS AS shall be able to generate IMDN(s) on behalf of that target RCS clients. The RCS AS may aggregate received IMDNs from each participant's RCS client before sending it to the originator in order to reduce the IMDN traffic. If the originating user has multiple devices, the RCS AS shall also be able to pinpoint the specific device from which the corresponding RCS message was sent, and sends the IMDN to that specific originating user’s device.

Note: The aggregation of the delivery notification at the RCS AS should be the best effort function as the delivery notification from some of target RCS clients can be received very late depending on the network status. The late delivery notification will be sent as a separate message.

Support of Multiple Devices
In the RCS BB, only the primary device can be used for a group chat for consistency in user experiences regarding re-joining and re-starting of a group session. As conversation history is not shared across multiple devices in the RCS BB with the absence of the centralized message storage, a user cannot re-join or re-start the group session using other device than the one which was used for the group chat. In case the RCS user responds to a group chat session invitation from the secondary device while the previous group chat was done in the primary device, the conversation history will be broken in the new device as the previous conversation history is stored in the primary device. From user experience perspective, the user can re-join/re-start the group session only from the device where the corresponding group conversation history is stored. The RCS AS shall also be able to send a group session invitation to a specific device of the user which was used for that conversation.

Group Session Policy
Service providers can define various policies regarding group sessions. For instance, a group chat session is released when there is only one participant left in the group session or there is no exchanged message during pre-defined session time interval (i.e., IM SESSION TIMER).

Auto Acceptance
The provisioning parameter IM SESSION AUTO ACCEPT GROUP CHAT is always set to be enabled in the RCS BB, meaning there is no reactive authorization for the group chat session invitation. Auto acceptance of a group chat session is supported only in the primary device as the group chat is enabled only in the primary device.

6. 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 either within the context of a chat session or as a standalone message. Technically, file transfer is always realized as a separate session from any existing chat session so the user can proceed the chat without interruption due to the file transfer. Upon 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.

Table 5. File Transfer

HTTP based File Transfer
The RCS BB supports both Media Session Relay Protocol (MSRP) based file transfer and HTTP based file transfer. In RCS BB, the HTTP based file transfer is used as a default. The RCS BB supports several enhanced features, such as thumbnail preview, pause and resume, group file transfer, and store and forward in HTTP based file transfer. The same enhanced features for the MSRP based file transfer are included in the RCS r5.1.

In order to perform HTTP based file transfer, a sender shall upload a file to a network-based file repository before sending a file transfer request and obtain a location URL of the stored file in return. The location URL is sent to the recipient using IP chat or standalone messaging. Upon receiving the file transfer request and if it is accepted, the recipient can retrieve the file from the received location URL.

Group File Transfer (HTTP)
A file can be sent to multiple recipients within a group session. The RCS AS taking the role of conference focus will distribute the file transfer request to the recipients and each recipient retrieves the file from the network-based repository indicated by the received location URL.

Store and Forward (HTTP)
When the recipient is not available, the file transfer request is locally stored in the RCS AS temporarily and the message will be retrieved and forwarded to the recipient when the recipient becomes available. The file temporarily stored in the network-based repository can be deleted when the valid timer for that file is expired.

Thumbnail Preview (HTTP)
The location URL of the thumbnail preview can be delivered to the recipient within the file transfer request along with the location URL of the file. Upon receiving the file transfer request, the recipient's RCS client may retrieve the thumbnail preview first before retrieving the actual file.

Pause and Resume (HTTP)
File transfer can be interrupted before it is completed out of some reasons e.g., due to loss of connectivity, battery drain, cancellation by a user. After the file transfer is paused, either end user can resume the file transfer. Upon resuming, the file is transferred from the point where the file transfer was interrupted. In order for the user to resume the file transfer, he/she needs to use the same device that was used for the previous file transfer. Otherwise, the file will be transferred from the start.

Support of Multiple Devices
When an RCS recipient has multiple devices, the file transfer request is forked to the recipient’s multiple devices and accepted by one of those devices based on the recipient’s selection. Once the file transfer request is accepted from one of recipient’s multiple devices, other file transfer requests sent to other devices shall be cancelled. The pause and resume function will only be applied to the user’s device which was used for the corresponding file transfer session.

IMDN (HTTP)
The HTTP based file transfer requires IMDN delivery. The delivery notification is sent back to the file sender when the recipient RCS client receives a file transfer request including the location URL of the stored file. The displayed notification is sent when the recipient retrieves the file from the location indicated by the received location URL.

Auto Acceptance
An RCS user can enable the auto acceptance of file transfer. Once the auto acceptance is enabled, the file transfer request is accepted without reactive authorization. The auto acceptance of the file transfer shall be valid only within the pre-defined maximum file size. The auto acceptance shall be allowed only from the primary device for consistency with the file transfer pause and resume.

7. Geolocation Sharing

Table 6. Geolocation Sharing

RCS users can share the location information with each other. The location information can only be shared after reactive authorization. The geolocation push function is to send his/her own location information to another RCS user and the geolocation pull function is to request the location information of another RCS user. An RCS enabled device may use the GPS function embedded in the device to obtain the location information. The received geolocation information can be viewed on the map of the device (i.e., shows-on-the-map feature) based on the device capability.

Note: This feature has been removed in RCS BB r4.0

8. vCard Exchange

RCS users can edit their own personal contact information, which could be informal contact card or business card. The format of this personal contact card is based on the standard vCard format. This personal vCard can be shared with another RCS users using file transfer mechanism.

Table 7. vCard Exchange

Note: The concept of Personal Contact Card (PCC) came from the OMA Converged Address Book (CAB) where users can define multiple personal contact cards and share them with other users based on the personalized filters. The filters are applied to the contact to whom the PCC is to be shared. As such, the users can control the authorized contact who can access his/her contact card and items that can be viewed by that person.

Note: This feature has been removed in RCS BB r4.0

9. Contents Sharing

Contents sharing is to share an image or a video in real time between RCS users. End users can see the same contents either while they are engaged in a voice call or outside the voice call session. The GSMA IR.74 and IR.79 defines the mechanism where the contents can be shared only when both users are engaged in the voice call session. Whereas the GSMA IR.84 introduces technical approaches to provide the video sharing function as a standalone service.

Table 8. Contents Sharing

The RCS BB adopts the contents sharing feature of the RCSe, which is based on GSMA IR.79 and IR.74. In both RCSe and RCS BB, the contents sharing is available only when users are engaged in an active voice call. The image sharing uses the file transfer mechanism. The video sharing is performed end-to-end between RCS users through the IMS network. As the video sharing has a dependency on the active voice call session, the video sharing session will become unavailable when the existing voice call session is released or suspended by other telephony services such as call on hold, call waiting, call forwarding, etc. The multiple devices feature is not supported in the contents sharing as the feature is only valid for the device that is engaged in the active voice call.

10. Integrated Messaging

The most important aspect of advanced messaging service is that it converges user experiences. Different silos of the legacy messaging services (i.e., SMS, MMS, IP chat, email, etc) are converged all together.

Table 9. Integrated Messaging

The RCS BB does not provide network based legacy messaging interworking feature. Rather it takes an approach to provide integrated user experiences at UX/UI level. With the absence of network based legacy messaging interworking function, the RCS client needs to combine the IP chat feature with SMS/MMS features internally within the device. The RCS BB recommends two approaches as below:

(1) Converged Inbox UX/UI
The IP chat thread and SMS/MMS thread are combined within the same RCS client but each thread is separately viewed using different windows.

Note: This feature has been removed in the RCS BB r4.0.

(2) Integrated Messaging UX/UI
The IP chat conversation thread and SMS/MMS conversation thread is managed within the same context. All the conversation history with the same contact(s) is viewed in the same messaging window. The RCS user may be able to figure out the type of received/sent messages based on the iconic representation of each message. The RCS BB recommends the integrated messaging UX/UI for native RCS client.

Note: In case the RCS user has multiple devices, the consistency of user experiences as to conversation history can be broken as the SMS/MMS can only be received from the primary device. This inconsistency is covered in the RCS r5.1 by adopting the network based message storage which enables all the multiple devices synchronized to have the same conversation history.

Note: When it comes to RCS r5.1, the legacy messaging interworking function is realized by the RCS AS rather than the RCS client. The RCS client always sends RCS message (i.e., IP message) and the RCS AS determines whether to forward the RCS message to another RCS user or to legacy messaging users based on the resolved target user.

11. IP Voice Call (Voice over Wi-Fi Call)

The voice over Wi-Fi call in RCS BB is provided through the best effort network. Within the limited bandwidth of best effort network, the voice over Wi-Fi call shall provide the best quality of voice as much as possible. The RCS user can make a voice over Wi-Fi call towards CS users (i.e., break-out) and also receive a voice over Wi-Fi call from the CS users (i.e., break-in) based on the operator's policy. The voice over Wi-Fi call shall support minimum set of telephony value added services such as caller-ID, communication on hold and communication waiting.

Table 10. IP Voice Call

Note: This feature has been removed in the RCS BB r4.0.

12. IP Video Call

The IP video call in RCS BB is provided through the best effort network. The IP video call shall provide the best quality of video within the given bandwidth. While an RCS user is engaged in a full duplex IP video call, the user can pause the video streaming from his/her side, thereby downgrades the full duplex IP video call to the simplex IP video call. The IP video call shall also support the minimum set of value added service such as caller ID, communication on hold and communication waiting.

Table 11. IP Video Call

Note: This feature has been removed in the RCS BB r4.0.

13. Summary

Even though it does not fully accommodate RCS r5.1 features, the RCS BB shows the evolutionary direction of communication technology. Technically supported or not, at least, the RCS BB provides RCS users with converged communication experiences at UX/UI level. This movement is also in the same context with the existing prominent OTT service providers such as Viber, Whatsapp, LINE, etc. which has been already providing converged user experiences.

Contrary to many OTT services becoming widely common among a lot of users nowadays, it seems to have been proven that the operator's RCSe service has totally failed at this moment in time. Many prominent OTT service providers have been enforcing lock-in effects in their services as more and more subscribers are joining the service. They are not merely messaging services any more. Rather, they are building the eco-system on top of which all type of contents such as game, music, photos, money transfer, are being shared and executed.

The failure of RCSe seems not coming from the lack of service features, but more likely from the lack of stability of the service and the incompleteness of user experiences. The operators might need to learn the mindset of OTT service provides, that is, the sensitivity to user’s behavior, openness, building win-win strategies based on the equal eco-system, fast and adaptive reaction, etc. Rather than competing with the OTT service providers, operators need to focus on replacing the legacy communication services with the IP based converged communication service with the proven quality of user experiences based on their underlying network. Only after that, operators may be able to move forward to build their own eco-system and compete with the OTT service providers in the long term.

References

[1] GSMA, “Joyn Blackbird Product Definition Document”, v3.0 Jan 2014
[2] GSMA, “Joyn Blackbird Product Definition Document”, v4.0 Oct 2014
[3] GSMA, “RCS5_1_advanced_communications_specification”, v4.0 Nov 2013