VoLTE

suifeng20061001

Whitepaper
Voice Over LTE VoLTE
esting FTTx Networks Featuring PONs
Systems sdfsdf
TABLE OF CONTENTS
1. Motivations for Enabling Voice over LTE
2. Requirements for Voice over LTE
3. LTE Voice Options
4. Overview of GSMA PRD IR.92 5. Service Continuity 6. Voice over LTE Verification
7. Summary
8. References
Motivations for Enabling Voice over LTE
The motivation for the deployment of 3GPP Long-term Evolution (LTE) mobile broadband technology is simple: All things considered, LTE delivers to carriers the lowest cost-per-transported bit. That said, the adage that “voice pays the bills” still applies: though in decline, carriers continue to derive the bulk of their revenues from voice and integrated messaging services.
In the context of LTE, this presents a dilemma. A fundamental aspect of legacy technologies such as GSM, UMTS, and cdma2000 is that they possess integrated services1: voice, voice supplementary services (e.g., call forwarding), short messaging, etc. In contrast, LTE makes no such provisions: it is subscriber service-agnostic. Further, LTE is a pure packet technology, with no inherent conception of a circuit-switched (CS) bearer, on which legacy voice services depend.
Because of the realities of the cellular revenue model – and, indeed, because cellular subscribers expect service continuity – the question arises: How can we best deliver voice and other legacy services via LTE? As with any engineering exercise, this requires articulation of the requirements.
Requirements for Voice over LTE
The requirements for voice2 over LTE (VoLTE) solutions fall into one – or both – of two categories: the requirements of cellular subscribers, and the requirements of cellular carriers. The most important of these requirements are as follows.
Subscriber Requirements
Telephony – Subscribers, first and foremost, expect replication of legacy cellular telephony services. The expectation of support for voice and messaging services is intuitive. But supplementary services – and the management thereof – are also required. While this might seem like a trivial requirement, the implementation of supplementary services in the context of VoLTE isn’t necessarily obvious. Further, subscribers – not to mention regulators – have clear expectations on the availability and performance of emergency calling services. Additionally, video telephony is fast becoming a basic expectation for subscribers.
Quality – Subscribers also require call quality that’s not noticeably different from that of existing telephony services. This presents a technical challenge in that LTE is a purely packet-switched (PS) system, and the maintenance of quality-of-service (QoS) in PS systems is notoriously challenging – especially over the parts of the channel outside the cellular carrier’s purview.
Ubiquity – Subscribers’s expectations in terms of service ubiquity go only one way over time: up. This means that both local and wide-area mobility must be supported – transparently – by any VoLTE solution. In technical terms, this means seamless inter-RAT (IRAT) operations as well as domestic and international roaming.
Battery – In order to be viable, a VoLTE solution cannot result in significantly higher battery consumption than is experienced with legacy voice services.
Carrier Requirements
Cost – For cellular carriers, a minimized total cost of ownership is the fundamental requirement. But costs can be manifested in a multitude of ways. For example:
Efficiency – The more efficient a technology is, the more traffic can be handled per node and per megahertz of transmission capacity. This is particularly important over the air interface, since radio spectrum is one of a carrier’s most precious assets: Spectrum procurement – unlike equipment procurement – is costly, regulated, and time-consuming.
Complexity – Reduced network complexity was a fundamental principle employed during the design of LTE. As complexity increases, the required hardware and the software development effort – particularly with terminal devices –
1 Indeed, GSM and UMTS terminals are, strictly speaking, Integrated Services Digital Network (ISDN) terminals.
2 For the remainder of this document, “voice over LTE” and “VoLTE” will be used generically to denote voice, voice supplementary services, short messaging services, and all other legacy subscriber services.
increases. So an excessively complex voice solution is not desirable.
Reusability – Solutions which permit the reuse of existing infrastructure – or are designed to have a long lifespan – are desirable.
It is with these requirements in mind that we evaluate the various options to deliver VoLTE.
LTE Voice Options
There is a diversity of options when it comes to solving the LTE voice problem. These range from multi-radio solutions, to solutions which tunnel legacy signaling through LTE, to “pure” SIP-based voice-over-IP (VoIP) solutions, to not using LTE for voice at all, instead relying on legacy networks to provide voice facilities. These are, of course, in addition to VoIP solutions which originated in the fixed broadband world – like Skype – which now have mobile incarnations. (These are, in some contexts, referred to as “over-the-top” solutions.) The major solutions to deliver VoLTE are as follows.
VoIP Adopted from Fixed Broadband
Voice-over-IP solutions like Skype, Google Talk, and Windows Live Messenger are used increasingly on mobile devices, and they are attractive in a number of ways, not least of which being that they exist today and are well-proven. These solutions have large user bases and are relatively cheap, which could not unreasonably be said to be two sides of the same coin.
However, having not evolved in the cellular world, fixed broadband voice solutions have shortcomings which show through when used in a cellular context. First, there is little bearer integration, which means that quality of service (QoS) cannot be guaranteed, especially during mobility to the oldest network technologies. While this can be improved to a degree in the fixed broadband world by “throwing bandwidth” at the problem, it is a non-trivial challenge in the mobile world where bandwidth is precious. Further, the number of fixed broadband VoIP solutions is large, with many utilizing proprietary technology and thus, mostly unable to interoperate. Most importantly, these services are delivered via third parties and are thus out of the carrier’s control.
Simultaneous Voice and LTE
Some of the earliest LTE deployments addressed the LTE voice issue by utilizing a dual-radio solution in which the mobile device is simultaneously connected to both the LTE and a legacy network, the latter of which being used to supply voice and messaging services. The advantages of such “simultaneous voice and LTE” (SVLTE) solutions are that, as the name implies, voice and LTE data services are supported simultaneously. Moreover, no network-to-network (NNI) interface is required; the two networks operate completely independently of each other and require no upgrades to support SVLTE.
Unfortunately, SVLTE solutions add significant complexity in terms of mobile device hardware, since two completely independent baseband and RF chains are required, with obvious cost implications. Further, SVLTE solutions have proven to be power-hungry in practice, with an unsatisfying user experience in terms of battery life. And since the LTE and legacy cells don’t necessarily have identical coverage footprints, the user experience during mobility can be less than desired.
Circuit-switched Fallback
Circuit-switched fallback (CSFB) is another solution to the LTE voice problem. With CSFB, a mobile device which is camped on LTE temporarily switches to a legacy radio access technology (RAT) in order to originate or receive a voice call. After the voice call completes, the mobile device can return to LTE. CSFB is an attractive LTE voice solution since it leverages existing infrastructure and accounts for differing states of network evolution amongst carriers – a key consideration in the context of roaming.
CSFB-capable mobile devices need not switch to a legacy RAT in order to send or receive SMS, since the processing of those messages can be handled by legacy systems. Short messages can be tunneled to or from the LTE network via the SGs network-to-network interface (NNI). Another option is SMS-over-IMS, which also permits the exchange of SMS without leaving LTE which has the added advantage of not requiring an NNI.
However, CSFB necessarily does not permit simultaneous voice and LTE data access. It also increases call setup delays as the mobile device must perform cell reselection and synchronization before proceeding with call setup. Further, field experience has shown that after a CSFB call completes, mobile devices can “stick” to the legacy network (e.g., due to packet data transfer), temporarily preventing the user from experiencing the full benefits of LTE.
Voice over LTE via Generic Access
Voice over LTE via generic access (VoLGA) is a true voice-over-LTE solution which enables LTE mobile devices to
access legacy systems and services without having to leave the LTE domain. VoLGA leverages an emulation
principle, with the LTE network appearing to be a legacy BSC/RNC from the MSC’s perspective, and with the legacy
MSC appearing to be an application function from the LTE mobile device’s perspective. Legacy call control messaging
is tunneled directly to and from the LTE mobile device, so the legacy call model is unchanged.
VoLGA is attractive because it relies on principles and technologies that already have been proven in the field.
Unlicensed mobile access (UMA) – in which compatible devices received voice call processing services from cellular
MSCs via Wi-Fi access – has been in the field for years. VoLGA also offers the added advantage of not requiring any
changes to legacy systems, as it was designed specifically to hide the nature of the access network from the core
network.
Even given its appeal on paper, VoLGA was not able to achieve a critical mass of industry support, with some terming
it backward-looking in the sense that it would require LTE to continue to rely on legacy calling paradigms and systems
rather than embracing newer calling paradigms like Session Initiation Protocol (SIP).
GSMA IR.92
Given the limitations of the VoLTE solutions articulated above, a group of cellular carriers and technology vendors
organized under the banner “One Voice”. While not strictly part of its mandate, the One Voice initiative focused on a
“pure” VoIP solution for VoLTE. The initial work of One Voice specified a minimum set of IP Multimedia Subsystem
(IMS) features to enable VoIP-based VoLTE. The GSM Association (GSMA) refined and completed this effort, which
is codified in the GSMA permanent reference document (PRD) IR.92.
IR.92 is appealing because it is VoIP-based and thus forward-looking, and because it leverages the investments in
IMS made by the cellular industry. But since IR.92 is a pure VoIP solution, there is substantial complexity introduced,
in particular, to enable interworking with legacy systems.
A summary of the key aspects of IR.92 is as follows.
Overview of GSMA PRD IR.92
The GSMA’s PRD IR.92 – IMS Profile for Voice and SMS – is, as its name indicates, a profile as opposed to a
technical specification. That is, rather than specifying new technologies, this document defines how the frameworks
and facilities already defined by 3GPP should be configured and utilized in a manner that permits, in particular,
interoperability between mobile devices and serving networks, as wells as amongst networks.
The reference architecture implied by IR.92 is as follows:
UE eNodeB S-GW P-GW CSCF
MMTel
IP-SMGW
Thus, in addition to the mandatory LTE nodes, IR.92 VoLTE relies on the IMS (CSCF) and the Multimedia Telephony
(MMTel) server. IR.92 captures the way in which these nodes are to be configured, connected, and utilized in order to
deliver voice services.
It is interesting to note that, for VoLTE calls, the VoIP “control plane” and “user plane” both are multiplexed on to the
LTE user plane. Thus, VoLTE call control is performed outside the purview of the LTE network. This is a good
illustration of how, unlike legacy cellular technologies, subscriber services in LTE are non-integrated.
Given that LTE subscriber services are non-integrated, and pursuant to the aforementioned subscriber requirements,
IR.92 addresses voice call control including supplementary services, voice media flows, supplementary service
management, and short messaging. And with the carrier requirements in mind, IR.92 also addresses a number of
“under-the-hood” aspects of the LTE radio access network and core network. A summary of IR.92’s requirements in
these areas is as follows.
Call Control
SIP Registration
Intuitively, IR.92 requires the mobile device to indicate its support for MMTel-based supplementary services during
SIP registration. And if the device supports SMS-over-IP, it is required to indicate so as well. Devices are further
required to supply their IMEI during SIP registration, which permits carriers to implement management policies in the
P-CSCF which are device or device class specific.
IR.92-compliant devices are required to support network-initiated de-registration, so that the network can forcibly
detach a mobile device, for example, during an IMS maintenance action.
SIP Authentication
IR.92 leverages the existing mechanisms for IMS authentication, i.e., IMS Authentication and Key Agreement (IMSAKA).
VoLTE are expected to have installed a Universal Integrated Circuit Card (UICC) equipped with the IMS
Services Identity Module (ISIM) application. The ISIM application contains the credentials critical to authentication
such as the subscriber’s IP Multimedia Private Identity (IMPI), the home carrier’s domain name, and a shared secret
key (which is also used in the encryption process).
If the ISIM application is absent from the UICC, IMS-AKA procedures can still be performed using the credentials
contained in the Universal Services Identity Module (USIM) application. The legacy GSM SIM and CDMA CSIM
applications are not supported.
SIP Addressing
IR.92 requires compatible mobile devices and networks to support specific addressing or “dialing” capabilities. Support
for both SIP-native B-party addresses as well as telephony-based addresses is mandatory. The former enables calling
between devices known to be IMS-capable, while the latter permits interoperability with legacy fixed and mobile
networks and devices. IR.92 specifically requires support for home-local numbers, and allows for support of geo-local
numbers.
SIP Call Processing
An originating mobile device, according to IR.92, must specify that it wants the call to be to be handled by an MMTel
server. This is accomplished by setting the IMS Communication Service Identifier (ICSI) in the communication
invitation to point to the MMTel service. This results in calls being looped – by the Serving CSCF (S-CSCF) – through
the MMTel server in each subscriber’s home network, as shown in the following simplified call control path:
UEO P-CSCFO S-CSCFO I-CSCFT S-CSCFT P-CSCFT UET
MMTelO MMTelT
It is the MMTel server that implements – among other things – the telephony-equivalent supplementary services such
as call barring and call forwarding (see below).
With SIP, on which IMS is based, call control and bearer (transport) control are essentially independent. This is by
design. But in the context of IR.92 there are two situations in which it is desirable to have some communication
between the two domains. The first is during call session establishment. It is possible that a terminating device could
accept a call invitation (and alert the terminating subscriber), but subsequently turn out that there are insufficient
bearer resources to support the call. This results in a so-called “ghost call”. This is not normally a problem in legacy circuit-switched systems because call and bearer control are relatively more coupled. In order to minimize the possibility of this occurrence, IR.92 requires the use of the SIP preconditions framework. This ensures that the terminating subscriber is not notified of the incoming call unless it is certain that there are sufficient resources to support the call (at the required QoS).
The second situation in which call and bearer control require some communication is in the context of call drops and call establishment failures. If, for example, communication between the LTE/SAE network and the internet is lost, or if the radio link fails, IR.92 requires the IMS call session to be reestablished or cleared gracefully on both the mobile device side and on the network side.
In order to ensure at least some level of communication between parties, IR.92 requires terminating devices to accept a communication session even if they cannot support some parts of it. For example, if a certain terminating device can support the audio codec but not the video codec requested by the originator, the device is required to accept the audio portion of the call. IR.92 also requires support for call “upgrades”, such as voice-only to voice plus video.
VoLTE emergency calls must be supported natively by both the mobile device and the network according to IR.92. However, it is acknowledged that IMS rollout will take some time, and that local regulations could necessitate that emergency calls be placed over a legacy network, so redirection to a legacy system for emergency call processing is permitted.
P-CSCF Discovery
IMS calls are processed by the subscriber’s S-CSCF in the home network. The connection to the S-CSCF is, however, indirect, via a local or “proxy” CSCF (P-CSCF). Since the P-CSCF varies with time and the mobile device’s serving network, an important step in the enablement of voice calling capabilities is the determination – or “discovery” – of the P-CSCF. IR.92 requires the mobile device to discover the P-CSCF address from the core network during the IMS PDN connectivity establishment process. This ensures that the serving network can point the mobile device to the optimal P-CSCF at runtime.
Note that the use of a P-CSCF facilitates lawful intercept activities in the visited network, as call control signaling is de-tunneled at the P-CSCF.
Supplementary Services
The IR.92 standard names a specific set of legacy supplementary services that are to be replicated for VoLTE. They are (going by the legacy names):