VoLTE or RCS Voice Call?

Posted on December 31, 2014 by tttrainer

In the past shopping was much easier. When we wanted to buy a wash-
machine we went to a shop, found the one with a reasonable price. Maybe
there were two with similar feature set and price. Now we will open our web
browser and we will spend hours or even days comparing tons of features,
reading reviews and looking for some bargain price. The added value is
sometimes questionable are we really able to make a qualified decision?

It is similar with many OTT applications for calls and massaging. Which one is
the right or at least decent one? The big advantage is that usually we can try
it for free. Anyway what is the difference between a voice call performed
as VoLTE (or VoWiFi) and voice call which is transmitted via RCS?
The 4G networks were originally designed for pure data traffic. But the voice
service is a must have feature and right now it cant be fully replaced by
VoIP. The voice service has to be reliable and fully compatible with the
service from 3G (Blacklisting, Call diverting, Lawful intercept, Emergency
calls, DTFM, etc.) and has to allow seamless fallback in case the 4G coverage
is lost (eSRVCC). This new service is called VoLTE.

VoLTE is a very young technology. It was announced in the beginning of 2010

by GSMA. The aim was to create a standard way of delivering voice and
messaging services for Long-Term Evolution (LTE). Using IMS specifications
developed by 3GPP as its basis, GSMA have expanded upon the original
scope of One Voice work to address the entire end-to-end voice and SMS
ecosystem by also focusing on Roaming and Interconnect interfaces. This is
comprised of three sets of interfaces
The User Network interface (UNI) between the users equipment and
the operators network.
 The Roaming Network Network Interface (R-NNI) between the Home
and Visited Network.
The Interconnect Network Network Interface (I-NNI) between the
networks of the two parties making a call.
The work of GSMA VoLTE will also encompass

the continuity of Voice calls when a customer moves from LTE coverage
to an area where LTE coverage is not available, achieved through
Single Radio Voice Call Continuity (SRVCC).
Optimal Routing of bearers for Voice calls when customers
are Roaming.
Capabilities associated with the model of Roaming Hubbing.
Security and fraud threat audit.
The basic VoLTE standard is described in FCM.01 VoLTE Service Description
and Implementation Guide and GSMA IR.92.
The RCS service and relation to VoLTE/ViLTE is described in the North America
RCS Common Implementation Guidelines and also in the Enriched Calling
Technical Specification. Please check these documents as some information
in this post is maybe already outdated.
The most important IMS network elements are Telephony Application Server
(TAS), Breakout Gateway Control function (BGCF), Media Resource Function
(MRF), Media Gateway Control Function (MGCF) and Media Gateway (MGW).
 IMS for VoLTE

TAS
The TAS is an IMS Application Server providing support for a minimum set of
mandatory MultiMedia Telephony (MMTel) services as defined by 3GPP e.g.
supplementary service functionality, and profiled within GSMA IR.92.
BGCF
The BGCF is responsible for determining the next hop for routing of SIP
messages. This determination may be based on information received within
the SIP/SDP, internal configuration, and/or ENUM/DNS lookup. For CS Domain
terminations, the BGCF determines the network in which CS domain breakout
is to occur and selects the appropriate MGCF. For terminations in peer IMS
networks, the BGCF selects the appropriate IBCF to handle the interconnect
to the peer IMS domain.

MRF
The MRF is a common media resource function, for use by IMS Application
Servers and I/S-CSCFs, to provide media plane processing independent of
application types, e.g. transcoding, multiparty conferencing, network
announcements/tones, etc. under the control of TAS as well as basic media
processing functions to CSCFs. The media plane interfaces to MRFs are
defined by 3GPP reference Mb for RTP/RTCP transport.

ALG/AGW (IMS Application Level Gateway/IMS Access Gateway)

The IMS-ALG/IMS-AGW is responsible for the control/media plane at the
access point to the IMS network. It provides functions for Gate Control &
Local NAT, IP realm indication and availability, Remote NAT traversal support,
Traffic Policing, QoS Packet Marking, IMS Media Plane Security, etc. The IMS-
ALG/IMS-AGW may be implemented in an Access Session Border
Controller which may also incorporate the P-CSCF.
MGCF/MGW
The MGCF/MGW is responsible for the control/media plane interworking at
the network interconnect point to circuit-switched networks. This includes
interworking to CS Networks based on BICC/ISUP/SIP-I and may include
transcoding of the media plane.

That was an overview of VoLTE very basic architecture (were focused on IMS
only). The call flow is what we expect in IMS SIP Invite sent via TAS for
signalling and RTP via SBC for media. And it is more or less the stuff with
which operators have in their networks right now (end of 2014).

However there are just a very few RCS trials now. So what is the
difference? RCS defines several types of voice and video calls:
IP Voice Call (IR.92)
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
Media capabilities: audio, duplex
Contact address type: tel / SIP URI
IP Video Call (IR.94)
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI
RCS IP Voice Call (strong preference for no breakout (IP end to end))
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall
Media capabilities: audio, duplex
Contact address type: tel / SIP URI
RCS IP Video Call (strong preference for no breakout (IP end to
end))
Service-id: org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel.gsma.ipcall
Version: 1.0
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI
RCS IP Video Call (strong preference for no breakout (IP end to
end) and video media cannot be dropped)
Service-id: org.3gpp.urn:urn-7:3gpp-
service.ims.icsi.mmtel.gsma.ipcall.ipvideocallonly
Media capabilities: audio, video, duplex
Contact address type: tel/ SIP URI
NOTE: RCS IP Calls and IP Calls per IR.92/IR.94 can technically
interoperate. Whether such interoperability is provided is based on Service
Provider decision. In those cases the Service Provider should ensure that all
relevant capabilities are provided in the capability exchange (e.g. if IP Voice
Call (as per MMTEL) capability is provided, the RCS IP Voice Call capability
should be provided also).

What it means? It means that the voice service defined for VoLTE (IR.92) is a
subset of (greedy!) RCS. Although sometimes the RCS based voice calls are
presented as something completely else which has nothing to do with
traditional voice service, the standard says otherwise. On the other hand
standard is not producing any code and the trials mostly implement the RCS
IP Video Call as a separate service which doesnt reuse the existing
TAS/MMTEL. Hence at least for some transition period we cant expect all the
features which are supported by VoLTE already.
One of the reasons is the amount RCS clients. Not all clients are compatible
with a particular RCS deployment. There can be also a need to combine a
native handset client and RCS specific client. The standard is partially aware
of initial difficulties and defines modes of devices for the telephony service:

RCS-VoLTE mode: A device in RCS-VoLTE mode uses VoLTE to provide the

telephony service. When a device capable of VoLTE uses CS to provide
telephony service it is in RCS-CS mode (see below). RCS IP Voice/Video Calls
are not allowed for devices in RCS-VoLTE mode.
RCS-VoHSPA mode: A device in RCS-VoHSPA mode uses VoHSPA to provide
the telephony service. When a device capable of VoHSPA uses CS to provide
telephony service it is in RCS-CS mode (see below). RCS IP Voice/Video Calls
are not allowed for devices in RCS-VoHSPA mode;
RCS-AA mode: The mode of operation of an access agnostic RCS device
using RCS IP Voice/Video Call that cannot provide 3GPP/3GPP2 calls (e.g. a
PC notebook with an LTE stick or broadband access network connection, or a
tablet);
RCS-CS mode: The mode of operation of a device using CS voice as the
telephony service (e.g. a 2G/3G/HSPA smart phone without VoHSPA support
attached to the CS network for telephony, a CSFB attached RCS smart phone
in LTE, and RCS smart phone with CS and Wi-Fi connectivity). RCS IP
Voice/Video Calls are possible if available. NOTE: If during a transition period
a device provides both RCS and VoLTE clients as completely separate
implementations, the RCS client shall behave as a non-embedded client and
shall consider the device to be in RCS-CS mode whenever in cellular
coverage.

To sum this up, technically the RCS is covering also the VoLTE. Anyway in
practice operators are rolling out firstly with VoLTE and a full RCS is still a
sound of future and (for now) it is mostly connected with Instant Messaging
and Presence. If the operators allow to do a video chat or See-what-I-see
(SWIS) than they are mostly not applying supplementary services neither call
continuity. Right now we usually see RCS and VoLTE as two independent
services supported by two (or more) different Application Servers.
More details about VoLTE can be found in VoLTE in IMS post.