Chronologically, 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 and the RCS r5.1 provides converged IP communication service feature. The RCS blackbird provides the intermediary service features between two different versions 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, thereby it tries to provide the same level of unified and consistent user experiences with RCS r5.1. The Voice over Wi-Fi 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 when they were using traditional communication services.
As of now, the RCS blackbird standards has been published up to r4.0 where some of main features have been removed compared to the previous version i.e., RCS blackbird r3.0, for the purpose of time-to-market service. This article is based on the RCS blackbird r3.0 as it has full set of functionalities of RCS blackbird.
NOTE Each column of the table in the following sections shows added features on top of the previous one (i.e., appears on the left column) unless stated otherwise.
1. Configuration Provisioning
The configuration provisioning is a procedure to provision service related configurations to RCS enabled devices. The RCS enabled device uses received configuration parameters to access IMS Core and to RCS service. Therefore this procedure is supposed to happen at least once right before the UE registers to the IMS Core for the first time.
Provisioning over non-PS network
Compared to the RCSe where only PS access device has been 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 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)
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 e.g., IMS based authentication, UE IP address based authentication, 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 can not authenticate the device using the same way as for PS-access device, because the device is typically assigned with the private IP address. Furthermore, the secondary device that is sharing the same identity with the primary device can't obtain the IMSI properly.
When there is no other way to authenticate the device, the configuration server may perform OTP based authentication. The configuration server generates the 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.x, 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.
Network-initiated Provisioning
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.
The user message can be sent e.g., to inform the user of new terms and policies or service related notices. The user message is unidirectional in many cases though, the configuration server may require user interactions when it needs a user's consent relating to changes of terms and policies. 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.
RCS BB configuration parameter
The configuration parameters consist of various type of Management Objects (MO) with high granularity for each service feature e.g., 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.
2. Service Capability Discovery
The Service Capability Discovery is a procedure to find service capabilities of contacts in the address book in order to figure out whether the contact is an RCS user or not. The presence based Service Capability Discovery is to use presence technology to obtain the capabilities of a certain group of contacts. The SIP OPTIONS based Service Capability Discovery is to use 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 known or (2) when the contact is regarded as non-RCS user or (3) for real-time fetch of contact's capabilities. 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, to which the presence based methodology is applied.
In RCS BB, the Service Capability Discovery function is extended in a way to support multiple devices environment. But, the presence based Service Capability Discovery feature has been disabled.
NOTE the RCS BB has been developed with the intention of providing time-to-market service. Given this, many complicated features such as presence have been removed as a whole.
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 the target user, aggregates responses from each multiple device and sends the response to the originating RCS client. The capabilities of an RCS client is determined based on collected capabilities from 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.
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
- New user discovery when a new contact has been added
The RCS BB recommends to use RCS BB specific parameter to mitigate the 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 is still valid.
NOTE The RCS 5.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.
The one-to-one chat is to establish the chat session between two RCS users. When an RCS user sends 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.
The RCS BB reuses all the IP chat features of RCSe and it supports multiple devices as well. The multiple devices control 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
The one-to-one session extension is to extend the one-to-one chat session to a group chat session by inviting another RCS user. This feature has been removed in the RCS blackbird but incorporated in the RCS r5.1.
The Group Chat is to establish the chat session for more than three 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 participants information for this event.
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, the participant 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 readers 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
The basic store-and-forward function is applied to the 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 the participant leaves the 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
The full store and forward feature is applied to the 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 the group session(Long Lived Group)
After the 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, geo-location 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 before including but not limited to participant information, group policy, etc. 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 the group session
The participant can rejoin the group session after involuntary leaving(e.g., connectivity loss, battery drain, etc). In order to be able 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.
The delivery notification shall be supported in a group session so the originating participant can figure out the status of the sent message. In case one or more of the target RCS clients do not support the IMDN capability, the RCS AS shall be able to generate the IMDN on behalf of target RCS clients. In order to reduce the IMDN traffic, the RCS AS may aggregate received IMDNs from each participant's RCS client before sending it to the originator. If the originating user has multiple devices, the RCS AS shall be able to pinpoint the specific device which has sent the corresponding RCS message.
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.
NOTE The displayed notification in a group session will also be supported in RCS r5.1.
Support of multiple devices
In the RCS BB, only the primary device can used for a group chat for consistency in user experiences regarding the re-joining and re-starting of a group session. As the conversation history is not shared across multiple devices in the RCS BB, the user can not 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 the 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.
Group Session Policy
The service provider can define various policies regarding the groups session. For instance, the group chat session is released when there is only one participant left in the group session or there is no exchanged messages 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. The 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.
5. File Transfer
The file transfer is a unidirectional transfer of discrete media such as audio clip, video clip, images, binary files, etc. From user experience perspectives, the file can be transferred either within the context of a chat session or as a standalone message. Technically, the file transfer is always realized as a separate session from the existing chat session so the user can proceed the chat without interruption due to file transfer. Upon sending the 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.
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, the sender shall upload the file to a network-based file repository before sending the file transfer request and obtain the 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.
NOTE The Standalone Messaging is a unidirectional messaging feature similar to SMS and MMS, which has been incorporated in the RCS r5.x.
Group File Transfer (HTTP)
The file can be sent to multiple recipients within the 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.
NOTE It is allowed in RCS r5.x to send multimedia contents within the chat session. Therefore if the file size is small enough the file can also be sent within the chat session. If the file size is bigger than allowed, the multimedia contents shall be sent using file transfer mechanism as a separate session.
Store and Forward (HTTP)
When the recipient is not available, the file transfer request is locally stored in the RCS AS. 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 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 message, the recipient's RCS client may retrieve the thumbnail preview first before retrieving the actual file.
Pause and Resume (HTTP)
The file transfer can be interrupted before the file transfer is completed out of some reasons e.g., loss of connectivity, battery drain, cancellation by a user. After the file transfer is paused, either end user can resume the file transfer. In this case the file is transferred from 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. Otherwise, the file will be transferred from the start.
The HTTP based File Transfer requires IMDN delivery. The delivery notification is send back to the file sender when the recipient RCS client receives the 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.
The RCS user can enable the auto acceptance of the 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. Considering the file transfer pause and resume situation, the auto acceptance shall be allowed only in the primary device for consistency.
The RCS users can share the location information with each other. The location information can only be shared after reactive authorization. The geo-location push function is to send his/her own location information to another RCS user and the geo-location pull function is to request the location information of another RCS user. The RCS enabled device may use the GPS function embedded in the device to obtain the location information. The received geo-location information can be viewed on the map of the device(i.e., shows-on-the-map feature) based on the device capability. In RCS BB r3.0, only the geolocation push function is supported.
NOTE The geolocation push function has also been removed in RCS BB r4.0.
7. vCard exchange
The 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.
NOTE The concept of Personal Contact Card (PCC) came from the OMA Converged Address Book (CAB) where the 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 who can view his contact card and what items can be viewed in his/her contact card.
NOTE This feature has been removed in RCS BB r4.0
8. Contents Sharing
The 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.
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.
9. 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. RCS users do not have to distinguish the legacy messaging from the IP chat.
The RCS BB does not provide network based legacy messaging interworking, 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 recommeds 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. The RCS r5.1 adopts 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. Therefore, the SMS/MMS client is not necessary in the RCS enabled device. 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 target resolution.
10. 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.
NOTE This feature has been removed in the RCS BB r4.0.
NOTE The RCS r5.1 combines all the voice call features together, VoLTE, CSFB and IP Voice call. Therefore the Voice over Wi-Fi feature in the RCS BB r3.0 can be regarded as an intermediary step towards all-in-one call features.
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 the 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 .
NOTE This feature has been removed in the RCS BB r4.0.
Even though it does not fully accommodate RCS r5.1 features, the RCS blackbird shows the evolutionary direction of communication technology. Technically supported or not, at least, the RCS blackbird 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 LINE, Viber, Whatsapp, 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 users 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 communication services 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 ultimately compete with the OTT service providers in the long term.
Last updated: July 2015
Red Mouse
