SlideShare a Scribd company logo
1 of 5
Download to read offline
ABSTRACT
The Enhanced Voice Services (EVS) codec was standardized by
3GPP in 2014. This codec offers significant gains in voice quality,
efficiency, channel error robustness over any other existing speech
codec and far better music quality. Operators run voice services on
a large installed base of 3GPP Circuit-Switched (CS) 2G (GERAN)
or 3G (UTRAN) radio networks. These networks offer mobile
voice service either as HD voice using the AMR-WB codec, or as
traditional narrowband (NB) voice service, based on the AMR
codec. Voice over LTE (VoLTE) is currently being deployed
throughout the world with HD Voice. The EVS codec will be first
introduced as a straightforward VoLTE upgrade. It is also expected
that EVS will be deployed over 3G CS networks. This paper
describes system aspects relating to EVS codec introduction in
VoLTE and CS networks as well as interworking and mobility with
legacy systems and services.
Index Terms— EVS, HD voice, VoLTE
1. INTRODUCTION
Since the introduction of GSM mobile telephony, created by the
European Telecommunications Standards Institute (ETSI) in the
early 1990’s, the world has witnessed a tremendous technical
revolution in the area of mobile communication that has penetrated
everybody’s life and changed human society disruptively. Even
though mobile telephony triggered this development, users did not
experience a lot of changes in this service. However, in reality
mobile operators have steadily improved their voice service
offerings with optimizations in terms of quality, system capacity
and robustness in fast growing mobile systems. The 3rd Generation
Partnership Project (3GPP) speech codec standards from GSM Full
Rate (FR) [1] over Half Rate (HR) [2] and Enhanced Full Rate
(EFR) [3] to the Adaptive Multi-Rate (AMR) codec [4] mark
milestones of this development. Only recently users have started
experiencing substantial quality improvements. This change came
with the introduction of HD (high-definition) voice providing
wideband (WB) audio with a frequency range from ca. 50 – 7000
Hz compared to traditional NB voice with about 100 – 3500 Hz.
HD voice leads to noticeably enhanced and more natural speech
quality. AMR-WB [5], the codec used for HD voice in 3GPP
systems, was standardized in year 2001, only three years after
AMR. Nevertheless, it took still until year 2009 before its first
deployment in a real life network. Reasons were manifold:
technical, infrastructural and commercial. This picture changed
with the advent of Voice-over-IP (VoIP) and Over-The-Top (OTT)
voice services, offering WB speech quality. Mobile operators
understood that investments into voice quality were a necessary
means to maintain their own service offerings attractive and to
avoid customer churn. HD voice now turns into a big success [6].
The mobile industry and operators hope to continue this
success story by service evolution towards even higher quality
voice services. It is understood that 3GPP voice services have to
remain leading edge, even after roll-out of HD voice, in order to
succeed in a fierce competition environment. Consequently, in year
2010 3GPP launched the standardization of a new codec for
“Enhanced Voice Services”, targeted to become the successor of
the current HD voice codec AMR-WB in LTE networks [7][8].
The EVS codec standard [9]-[19] was successfully finalized in
September 2014, meeting or exceeding the standardization goals.
The goals were to enable clear benefits over existing AMR-WB
based 3GPP voice services in terms of overall service quality,
efficiency and interoperability. The EVS codec offers a toolbox of
high performance properties and features comprising: high-quality
super-wideband (SWB) and fullband (FB) voice; high-
capacity/high-quality NB and WB voice; high-quality music/non-
speech signal performance; and high robustness to error-prone
VoIP transmission frameworks. SWB voice ranges from about 20 –
15000 Hz, while FB voice extends to about 20000 Hz covering the
complete human audible spectrum. In addition, the EVS codec
maintains backward compatibility with AMR-WB, thus avoiding
interoperability problems or any hard-cut decisions against AMR-
WB during its introduction.
This paper provides insights in solutions for the complex task
to bridge the gap between legacy voice services and cutting edge
EVS, given the heterogeneity of existing 3GPP systems. The paper
first describes voice services in 3GPP systems covering legacy CS
networks and 4G Packet-Switched (PS) systems with LTE access,
i.e. VoLTE [20]. Adaptation principles at call setup and during the
call are then addressed as well as interoperability aspects under
various system configuration and mobility scenarios. The
conclusion of the paper sketches the envisioned smooth migration
path towards the new EVS.
2. VOICE IN 3GPP SYSTEMS
2.1. Voice in CS networks
Like the earlier 3GPP speech codecs GSM FR, GSM HR and GSM
EFR, AMR was originally developed and standardized by ETSI for
CS mobile telephony in the GSM system. The AMR standard for
that system (more general GERAN) includes besides the speech
codec [21] further components such as channel coding [22], rate
adaptation and in-band rate control [23]. The codec comprises 8
modes with net bitrates from 4.75 to 12.2 kbps. AMR rate
adaptation allows selecting the most suitable mode for a given
radio channel condition, hence choosing the mode that enables best
possible quality. Together with FR/HR traffic channel adaptation
this allows operators flexibly trading speech quality against system
capacity. A cornerstone of the adaptation in GERAN is the
feedback channel, allowing signaling codec mode requests (CMR),
i.e. adaptation commands, back from the receiving end to the
sending end. The AMR concept is discussed in detail in [24].
Based on its merits in comparison with other contenders like
G.729 [25], EVRC [26], MPEG-4 Audio [27], and for
interoperation with AMR in GERAN systems, 3GPP selected
SYSTEM ASPECTS OF THE 3GPP EVOLUTION TOWARDS
ENHANCED VOICE SERVICES
Stefan Bruhn, Tomas Frankkila, Frédéric Gabin, Karl Hellwig, Maria Hultström
Ericsson AB
AMR in 1999 as the mandatory codec for the new UMTS.
Compared to GERAN, AMR adaptation in UTRAN serves a
different purpose, namely load control [28].
Like AMR, AMR-WB was originally specified for GERAN
and UTRAN networks. All principles and mechanisms related to
adaptation were retained. The codec includes 9 different modes,
from 6.60 to 23.85 kbps. In order to harmonize interworking, 3GPP
agreed on one mandatory configuration with a set of modes (active
codec set (ACS)) that all GERAN and UTRAN infrastructure must
support. This mode set comprises the three lower rate modes of
AMR-WB 6.60, 8.85 and 12.65. Even today when AMR-WB is
operated in VoLTE networks using its highest mode 23.85, for
backward compatibility with CS networks the three low rate modes
must always be included in a mode set.
The new EVS codec was originally developed for PS multi-
media telephony services over LTE. However, its strong
performance has triggered interest to standardize it as well for use
in voice services in UTRAN CS networks. Accordingly, 3GPP
launched a work item “EVSoCS” [29] in September 2014 with the
objective to enable users of 3G services to benefit from the
enhanced user experience, system capacity and interoperability
provided by EVS. It will be of main importance to make sure that
EVS can be introduced into 3G CS systems at minimum system
impact. The work item is currently ongoing and is expected to be
finalized by December 2015.
2.2. Voice over LTE (VoLTE)
With VoLTE, the operator offers a carrier-grade voice service by
ensuring Quality of Service (QoS) with the use of Guaranteed Bit
Rate (GBR) bearers for voice. VoLTE makes use of the Real-time
Transport Control Protocol (RTCP) associated with the Real-time
Transport Protocol (RTP) [30] to monitor voice quality. Although
even OTT services could benefit from the excellent quality,
efficiency and robustness of the EVS codec, they cannot guarantee
a carrier-grade service when using best effort bearers without QoS.
VoLTE enables telephony – including emergency services –
and messaging over the 4G networks. The GSM Association
(GSMA) specified VoLTE in their PRD IR.92 IMS Profile for
Voice and SMS [20]. The VoLTE profile is a subset of the 3GPP
IMS standard functionalities [31].
The goal of the VoLTE profile is to accelerate adoption by
simplifying the implementation. This is achieved via careful
selection of the most appropriate features. The objective is on its
way to being accomplished: according to GSA (the Global mobile
Suppliers Association) by July 2015: “25 operators in 16 countries
have commercially launched VoLTE-based HD voice service,
compared to just 3 launched in March 2014. Many more launches
are anticipated in 2015” [32].
From the first version of the profile, VoLTE terminals must
support AMR codec and optionally support AMR-WB codec. From
version 9.0 of the profile they also must support the AMR-WB
codec; the EVS codec is mandatory for SWB and FB and
recommended for NB and WB. However, all VoLTE terminals on
the market are HD Voice capable and hence support AMR-WB.
HD voice can therefore be enabled where operators have chosen to
implement AMR-WB in network entities terminating the user
plane (for example, Media Gateways (MGW), Media Resource
Function Processors (MRFP), Conferencing Units and Application
Servers). Although EVS is not mandatory for VoLTE terminals
supporting WB, GSMA is currently in the process of adding EVS
operated in WB modes to the list of allowed codecs in the HD
voice minimum requirements [33].
The EVS codec includes, besides EVS primary modes, AMR-
WB interoperable (IO) modes enabling interworking with AMR-
WB implementations. The EVS AMR-WB IO modes offer
improved quality over the original AMR-WB modes [34].
Therefore the standard allows a VoLTE terminal to use its EVS
implementation operated with AMR-WB IO modes in place of the
AMR-WB codec.
The EVS encoder adapts the bitrate of each frame based on a
received Codec Mode Request. These rate adaptation operations
generally follow the principle introduced with AMR and are
described in section 3. VoLTE uses the RTP [30] carriage of user
plane information between end-points. Each encoded frame is
encapsulated as a payload in the RTP protocol. The RTP payload
format for EVS is specified in Annex A of 3GPP TS 26.445 [13]. It
actually defines two formats, a compact format and a header-full
format. The former offers efficient transmission without any
payload header. The latter format in contrast enables encapsulating
several frames in the payload and also enables signaling CMR.
The Session Description Protocol (SDP) [35] is used by end-
points to describe the session parameters. The session
establishment for the VoLTE call requires a negotiation between
end-points as their capabilities may differ. End-points could be
VoLTE terminals, but also MGWs for transcoding or other
Application Servers that may be used e.g. for producing call-
progress tones. This negotiation uses the Offer/Answer model [36]
that is used between these end-points. In the case of a Mobile
Originated call, the VoLTE terminal originating the call sends an
SDP offer, describing all its capabilities. This includes in particular
media capabilities like the list of codecs supported and associated
modes of audio bandwidth, bitrates, type of RTP packetization and
desired bearer bandwidth.
It is one important design requirement that the call setup time
be minimized so as to improve user experience. Although the
Offer/Answer mechanisms can resolve complex heterogeneous
cases of media capabilities to result in compatible session
characteristics, it is important to minimize the number of
handshakes. For this reason it is for example mandatory to support
all codec modes for AMR and AMR-WB, respectively, and to offer
all of them in a so-called “open-offer”. An “open-offer” defines no
specific mode set. This enables the distant VoLTE client or MGW
to produce an answer compatible to its capabilities in just one
handshake. Furthermore, the operator’s network can also tailor the
offered SDP in a Session Border Gateway (SBG) to apply a
particular policy like e.g. limiting the maximum bitrate or
restricting to SWB operation. Applying a particular policy in the
network, rather than in customized devices, also has the advantage
that it becomes applicable to inbound roamers. Finally, sending an
“open-offer” improves interworking as described in section 4.
Once the session is negotiated and bearers are established, RTP
packets can be transmitted and received over the UDP [37] ports of
the VoLTE terminals. Any conversational voice service requires a
low end-to-end delay for good interactivity of the conversations.
The LTE radio bearers used for voice traffic are configured to
minimize delay by setting the RLC (Radio Link Control) layer in
unacknowledged mode. This is made possible by the inherent
robustness of the AMR, AMR-WB and EVS decoder to lost
packets. Furthermore, in a packet based system, packets experience
different transmission delays and this delay variation, the jitter,
must be handled by receivers. The standard defines minimum
performances for the jitter management. Also, the EVS codec
comes with a specified jitter manager [16].
Enabling VoLTE to VoLTE calls with the EVS codec within an
existing VoLTE infrastructure requires minimal upgrades. For the
VoLTE terminal, besides EVS codec support, there are
requirements on the acoustic and speech enhancements functions.
These requirements depend on the supported audio bandwidth;
more evolved requirements than for HD voice apply if the service
shall be operated with SWB or FB audio bandwidth. The network
upgrades are limited to the modification of policy functions
allowing the negotiation of the EVS codec end-to-end. For
example a policy could be to limit the maximum bitrate of
operation to 13.2 kbps to benefit from the same network
dimensioning as AMR12.2 kbps and AMR-WB 12.65 kbps, yet
still allowing to provide excellent SWB voice quality. There is no
requirement to implement any particular policy between EVS end-
points, but an operator may choose to do so by configuring the
policies in the SBG. Further, multiparty conferencing requires
upgrade of the Media Resource Function. A system view of the
network impact of EVS introduction is provided in Figure 1. The
changes required enabling end-to-end VoLTE to 3G Circuit
Switched EVS calls and operation with switching to 2G or 3G
(Single Radio Voice Call Continuity - SRVCC) are described in
section 4.
3. CALL SETUP AND IN-CALL ADAPTATION
3.1. Call setup
Call setup works differently in CS and PS 3GPP systems but
follows similar principles. The general purpose is the definition of
operation parameters of the used codec(s) for the subsequent call
and of the range within which in-call adaptation is allowed.
For AMR and AMR-WB, call setup procedures essentially
determine the codec modes (bitrates) among which adaptation is
possible during the call. For interoperability reasons, a mode set
should be chosen that comprises at least some common low-rate
modes that are generally supported, even when roaming within or
among various networks.
For EVS applications in VoLTE, TS 26.445 Annex A [13]
specifies parameters related to EVS primary and AMR-WB IO
mode operation. Bit rate can be specified as a single value or a
range of bitrates. Likewise, audio bandwidth can be defined as a
single value or a range from NB to a given maximum audio
bandwidth. Parameters may be specified individually per call
direction or jointly for both directions.
For EVSoCS, the call setup is not yet standardized. It is
however envisioned that suitable call control protocol information
elements are specified allowing defining similar operation
configurations as for PS. Such kind of harmonization will greatly
facilitate EVS interoperability between CS and PS (VoLTE)
domains.
3.2. In-call adaptation
In this paper, in-call adaptation refers to adaptation of the codec
application layer. Adaptation of lower protocol layers (e.g. power
control, adaptation of modulation schemes, transport format
combination selection based on available power, cell and transport
network load adaptations, etc.) occurs frequently. It is system
specific for e.g. the radio access technology used. Such kind of
adaptation is not covered here.
In-call adaptation has the general purpose, described in section
2.1, to adjust the coding mode to changed system conditions, in
order to optimize capacity or service quality. A changed condition
requiring selecting a new coding mode may also occur in case of a
cell hand-over where the previously used codec mode may not be
supported any longer or not be suitable. For AMR and AMR-WB,
adaptation is possible with respect to bitrate. For EVS, audio
bandwidth is an important further adaptation dimension.
Adaptation of the audio bandwidth may e.g. become necessary
when the audio front- or backend changes. Adaptation of the
encoding audio bandwidth in response to a change of input audio
bandwidth is done autonomously by the encoder up to a given
maximum audio bandwidth. A change of the output audio
bandwidth may on the other hand trigger a CMR from the
receiving end to the sending end, accordingly adjusting the
maximum audio bandwidth for encoding. A change of encoding
bitrate may also result in a changed audio bandwidth since not all
audio bandwidths are supported by all bitrates.
A further important adaptation dimension of the EVS codec is
the capability to switch between EVS primary modes and AMR-
WB IO modes. This kind of adaptation is crucial when a terminal
moves between cells with EVS support and cells supporting HD
voice but not EVS. Especially during roll-out of VoLTE this may
frequently occur since VoLTE coverage may exist only for hot
spots while other areas are still only covered by 3G or 2G networks
offering HD voice. The possibility to adapt seamlessly between
EVS primary modes and AMR-WB IO modes ensures always
highest possible service quality and the avoidance of call
discontinuities due to codec changes that might otherwise occur.
This also avoids the need to use transcoding between networks
with EVS and with only HD voice support. Transcoding would
degrade quality and require operator investments.
For VoLTE, CMRs are transmitted in-band as part of the RTP
payload format or using RTCP. The use of CMR is generally
preferable due to lower latency and lower signaling overhead. For
AMR and AMR-WB, the RTP payload format [38] specifies a
CMR field as part of the payload header. Likewise for EVS, the
EVS RTP payload format specifies a CMR field supporting
requests for bitrate, audio bandwidth, EVS primary or AMR-WB
IO modes and further features.
Codec mode adaptation for EVSoCS is not yet specified.
However, it is desirable to allow adaptation along the same
dimensions as for EVS in VoLTE. A complication in UTRAN is
that rate control is maximum rate control. This means that any rate
up to the maximum may be chosen by autonomous decisions by the
Figure 1: Network impact - EVS codec (green = impacted)
VoLTE
Terminal
Core Network
IMS Core
CS Core
eNodeB
NodeB
2G/3G
Terminal
ATCF/
SBG
ATGW/
BGF
MRF
EVS for
Conferencing
Interworking
and
EVS-AMR-WB
Fast SRVCC
RNC
RNC
EVS
enabled
3G
Terminal
NodeB
PSTNInternet/
WiFi
Fixed broadband
access (e.g. DECT)
Acronyms used:
ATCF Access Transfer Control Function
ATGW Access Transfer Gateway
BGF Border Gateway Function
MRF Media Resource Function
MSC Mobile Switching Center Server
PSTN Public Switched Telephone Network
MGWMSC
Radio Network Controller (RNC), depending on the available radio
resource, and by the terminal, depending on instantaneous transmit
power needs for a codec mode in relation to certain transmit power
limits. Uplink rate control commands are signaled to the terminal
by means of the Radio Resource Control (RRC) protocol rather
than in-band CMR. Similarly, for downlink rate control, RNC
sends Rate Control Request (RC-Req) messages to the CS Core.
This concept is too limited for EVS with its additional adaptation
dimensions. It is therefore envisioned that the existing adaptation
signaling is combined with additional in-band CMR signaling. The
terminal and likewise MGW in the CS Core would receive both
kinds of adaptation signaling messages and merely combine them
in a suitable way.
4. INTEROPERABILITY ASPECTS
4.1. Interworking between VoLTE and CS networks
Interworking between public land mobile networks (PLMN) is a
strong point of the VoLTE specification. When OTT service
providers only create islands of compatible clients, operators can
enable their subscribers using VoLTE native client to communicate
with any other PSTN phone or 3GPP VoLTE or CS compatible
terminal, be it under 2G, 3G or 4G/Wi-Fi coverage (see also Figure
1).
An EVS VoLTE call between two operator’s networks requires
EVS enabled VoLTE clients, but also that the interworking
agreement between operators implements compatible policies. For
example, if one operator forces EVS VoLTE calls within its
network to negotiate only SWB modes and the other restricts EVS
VoLTE calls to only WB modes, no compatible EVS mode can be
found to operate transcoder free. The agreement between operators
can only operate when VoLTE terminals use “open-offer” at
session negotiation. Indeed, an important motivation of the “open-
offer” is to guarantee that tandem free interworking can be
established with any other remote terminal and network, regardless
of whether the remote network is 2G/GSM, 3G/WCDMA,
4G/LTE, WiFi, fixed, non-3GPP or anything else, no matter what
configuration that terminal and network allows.
When operating between VoLTE and CS networks, an upgrade
is required to the Media Gateway to handle transcoding from and
to different codecs. When EVS is supported on both sides,
transcoder free interworking can be achieved. This is only possible
if the subset of EVS modes operated on the CS side is compatible.
By sending an “open-offer”, the VoLTE terminal allows the
network to limit the EVS modes to the ones compatible with the
CS side. In order to achieve backwards compatibility and
interworking with CS networks with transcoder free operation
(TrFO), for optimal performance and resource utilization, it is
required that the three lowest AMR-WB codec modes are included
in the VoLTE mode set. Backwards compatibility with transcoding
is always a possibility.
When operating between two CS networks with EVS, it can be
a challenge for operators to agree on a single codec set. The
standard can limit the relevant sets but should not limit the
flexibility offered to operators to run their networks at their
preferred operating points. One proposal that can improve the
situation is if the EVSoCS mode sets are constructed such that the
lowest bitrates are always included and when an audio bandwidth
is offered, all smaller audio bandwidths are also offered. With this
principle, it is always possible to find a compatible set enabling
TrFO between CS networks.
4.2. Mobility and AMR-WB backward compatibility of EVS
Mobility is an essential feature of mobile communication systems
and continuity of voice calls is expected by moving users. The
introduction of LTE made the CS fallback and SRVCC handovers
from VoLTE to 2G/3G systems essential. Typically, the SRVCC
procedure requires the addition of a transcoding function in the
path. This comes with speech interruptions and with added costs.
As described in section 2.2, a subset of the EVS modes is
compatible with the AMR-WB codec. In addition to allowing an
EVS implementation to efficiently replace an AMR-WB
implementation, this also enables transcoder free operation
between an end-point operating EVS and the other operating
AMR-WB under the condition that a compatible mode set is used.
In the case of SRVCC during an EVS VoLTE-VoLTE call,
assuming the used codec in the target CS network is known, it is
well possible to avoid any transcoding function and minimize
speech interruptions in the following way: If the target codec is
EVS over CS, the gateway can – prior to the switch – control the
EVS codec rate used by the VoLTE terminal such that it is
compatible with the target EVS set. During the switch, no
interruption due to incompatibility of speech modes is experienced.
Likewise, if the target codec is AMR-WB, the gateway would –
prior to the switch – make sure that the VoLTE terminal uses
AMR-WB IO modes that are compatible with the target AMR-WB
mode set.
5. CONCLUSION
Today 3GPP voice services are globally implemented in a large
variety of 3GPP systems that have been continuously evolving like
the service itself. Improvements to service quality and system
efficiency/capacity have been the driver of that evolution under the
fundamental constraint to warrant interworking with legacy
systems and devices. HD voice is now broadly deployed and
VoLTE is taking off. 3GPP has standardized a new codec for EVS
over LTE and launched the standardization process to make EVS
available even for 3G CS networks. This will take the evolution to
its next stage.
Despite large system heterogeneity the evolution towards EVS
proceeds along a smooth migration path. It turns out that
underlying principles of codec adaptation at call setup and in-call
have not substantially changed since they were first time applied
with AMR. This means that there are many commonalities which
facilitate a smooth evolution. Careful design of suitable hand-over
mechanisms supporting efficient interworking and service
continuity in various mobility and roaming cases is another
essential component of this. One important aspect with the
introduction of the new EVS is that it can be done with minimum
system impact. In case the system already supports VoLTE based
HD voice no other network upgrades than just adding EVS codec
support to the control plane are necessary. Further upgrades of
SBG/BGF will enable transcoder free interworking with CS 2G/3G
HD voice deployments and transcoding to other HD voice codecs
in e.g. the fixed-network or Internet realms. Migration towards
EVS will be smooth even in terms of radio network planning. EVS
can operate in its high-quality SWB modes providing natural voice
sound unprecedented in mobile telephony at rates no larger than
required for existing HD voice. The deployment in an operator-
controlled network with QoS mechanisms in place ensures
guaranteed telecom grade service quality. This is a substantial
advantage over OTT voice services that, in contrast, cannot
guarantee good voice service quality for the users.
6. REFERENCES
[1] 3GPP TS 46.001, “Full Rate Speech Processing Functions”.
[2] 3GPP TS 46.002, “Half Rate Speech Processing Functions”.
[3] 3GPP TS 46.051, “GSM Enhanced full rate speech
processing functions: General description”.
[4] 3GPP TS 26.071, “Mandatory speech CODEC speech
processing functions; AMR speech Codec; General
description”.
[5] 3GPP TS 26.171, “Speech codec speech processing
functions; Adaptive Multi-Rate - Wideband (AMR-WB)
speech codec; General description”.
[6] Mobile HD voice Global Update report, GSA, April 23,
2015.
[7] S. Bruhn et al., “Standardization of the new 3GPP EVS
Codec” Proc. ICASSP, April 2015.
[8] SP-140151, 3GPP Work Item Description “Codec for
Enhanced Voice Services”.
[9] 3GPP TS 26.441, “Codec for Enhanced Voice Services
(EVS); General overview”.
[10] 3GPP TS 26.442, “Codec for Enhanced Voice Services
(EVS); ANSI C code (fixed-point)”.
[11] 3GPP TS 26.443, “Codec for Enhanced Voice Services
(EVS); ANSI C code (floating-point)”.
[12] 3GPP TS 26.444, “Codec for Enhanced Voice Services
(EVS); Test sequences”.
[13] 3GPP TS 26.445, “Codec for Enhanced Voice Services
(EVS); Detailed algorithmic description”.
[14] 3GPP TS 26.446, “Codec for Enhanced Voice Services
(EVS); Adaptive Multi-Rate - Wideband (AMR-WB)
backward compatible functions”.
[15] 3GPP TS 26.447, “Codec for Enhanced Voice Services
(EVS); Error concealment of lost packets”.
[16] 3GPP TS 26.448, “Codec for Enhanced Voice Services
(EVS); Jitter buffer management”.
[17] 3GPP TS 26.449, “Codec for Enhanced Voice Services
(EVS); Comfort Noise Generation (CNG) aspects”.
[18] 3GPP TS 26.450, “Codec for Enhanced Voice Services
(EVS); Discontinuous Transmission (DTX)”.
[19] 3GPP TS 26.451, “Codec for Enhanced Voice Services
(EVS); Voice Activity Detection (VAD)”.
[20] GSMA IR.92 IMS Profile for Voice and SMS.
[21] 3GPP TS 26.090, “Mandatory Speech Codec speech
processing functions; Adaptive Multi-Rate (AMR) speech
codec; Transcoding functions”.
[22] 3GPP TS 45.003, “Channel coding”.
[23] 3GPP TS 45.009, “Link adaptation”.
[24] S. Bruhn et al., “Concepts and solutions for link adaptation
and inband signaling for the GSM AMR speech coding
standard”, IEEE 49th
VTC, 1999.
[25] ITU-T Recommendation G.729, “Coding of speech at 8
kbit/s using conjugate-structure algebraic-code-excited linear
prediction (CS-ACELP)”.
[26] 3GPP2 C.S0014, “"Enhanced Variable Rate Codec, Speech
Service Option 3 for Wideband Spread Spectrum Digital
Systems".
[27] ISO/IEC 14496-3 (MPEG-4 version 1) Audio Part.
[28] M. Karlsson et al., “Joint Capacity and Quality Evaluation
for AMR Telephony Speech in WCDMA Systems”, IEEE
56th
VTC, 2002.
[29] SP-140485, 3GPP Work Item Description “Support of EVS
in 3G Circuit-Switched Networks”.
[30] IETF RFC 3550, RTP: A Transport Protocol for Real-Time
Applications.
[31] 3GPP TS 26.114, “IP Multimedia Subsystem (IMS);
Multimedia telephony; Media handling and interaction”.
[32] July 22, 2015: GSA confirms 422 LTE networks launched,
Cat 6 LTE-Advanced deployments setting the pace,
(http://www.gsacom.com/news/gsa_430.php).
[33] Minimum Technical Requirements for use of the HD Voice
Logo with LTE issued by GSMA (Annex F), Version 1.0, 4
April 2014.
[34] 3GPP TR 26.952, “Codec for Enhanced Voice Services
(EVS); Performance characterization”.
[35] IETF RFC 4566, “SDP: Session Description Protocol”.
[36] IETF RFC 3264, “An Offer/Answer Model with Session
Description Protocol (SDP)”.
[37] IETF RFC 768, “User Datagram Protocol”.
[38] IETF RFC 4867 (2007), "RTP Payload Format and File
Storage Format for the Adaptive Multi-Rate (AMR) and
Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs".

More Related Content

What's hot

Unicast or Multicast for IP Video? Yes!
Unicast or Multicast for IP Video? Yes!Unicast or Multicast for IP Video? Yes!
Unicast or Multicast for IP Video? Yes!Cisco Service Provider
 
IBOC TECHNOLOGY
IBOC TECHNOLOGYIBOC TECHNOLOGY
IBOC TECHNOLOGYDj Tibi
 
Globtel AIR Solution
Globtel AIR SolutionGlobtel AIR Solution
Globtel AIR SolutionPavle Mikuz
 
Globtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access SolutionGlobtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access SolutionPavle Mikuz
 
Globtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access SolutionGlobtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access SolutionPavle Mikuz
 
Hammer Fiber Optics Holdings Corp. Investor Deck
Hammer Fiber Optics Holdings Corp. Investor DeckHammer Fiber Optics Holdings Corp. Investor Deck
Hammer Fiber Optics Holdings Corp. Investor DeckRedChip Companies, Inc.
 
AIR Gigabit Fixed Wireless Last Mile Solution
AIR Gigabit Fixed Wireless Last Mile SolutionAIR Gigabit Fixed Wireless Last Mile Solution
AIR Gigabit Fixed Wireless Last Mile SolutionPavle Mikuz
 
Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...
Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...
Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...Pavle Mikuz
 
Introducing the Cambium Networks PMP 450 from WAV
Introducing the Cambium Networks PMP 450 from WAVIntroducing the Cambium Networks PMP 450 from WAV
Introducing the Cambium Networks PMP 450 from WAVWAV Inc.
 
Hmmr Presentation Global Online Growth Conference Oct 2016
Hmmr Presentation Global Online Growth Conference Oct 2016Hmmr Presentation Global Online Growth Conference Oct 2016
Hmmr Presentation Global Online Growth Conference Oct 2016RedChip Companies, Inc.
 
Advanced Radio over IP
Advanced Radio over IPAdvanced Radio over IP
Advanced Radio over IPComms Connect
 
Comtech sspi vsat_day_2010
Comtech sspi vsat_day_2010Comtech sspi vsat_day_2010
Comtech sspi vsat_day_2010SSPI Brasil
 
Sumavision Wide Screen
Sumavision Wide ScreenSumavision Wide Screen
Sumavision Wide ScreenZCorum
 

What's hot (20)

Unicast or Multicast for IP Video? Yes!
Unicast or Multicast for IP Video? Yes!Unicast or Multicast for IP Video? Yes!
Unicast or Multicast for IP Video? Yes!
 
IBOC TECHNOLOGY
IBOC TECHNOLOGYIBOC TECHNOLOGY
IBOC TECHNOLOGY
 
Globtel AIR Solution
Globtel AIR SolutionGlobtel AIR Solution
Globtel AIR Solution
 
Globtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access SolutionGlobtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access Solution
 
Globtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access SolutionGlobtel AIR Fixed Wireless Access Solution
Globtel AIR Fixed Wireless Access Solution
 
Catv
CatvCatv
Catv
 
Hammer Fiber Optics Holdings Corp. Investor Deck
Hammer Fiber Optics Holdings Corp. Investor DeckHammer Fiber Optics Holdings Corp. Investor Deck
Hammer Fiber Optics Holdings Corp. Investor Deck
 
AIR Gigabit Fixed Wireless Last Mile Solution
AIR Gigabit Fixed Wireless Last Mile SolutionAIR Gigabit Fixed Wireless Last Mile Solution
AIR Gigabit Fixed Wireless Last Mile Solution
 
Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...
Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...
Globtel AIR Solution - True potential of the Gigabit Fixed Wireless Access So...
 
Introducing the Cambium Networks PMP 450 from WAV
Introducing the Cambium Networks PMP 450 from WAVIntroducing the Cambium Networks PMP 450 from WAV
Introducing the Cambium Networks PMP 450 from WAV
 
Alessio Murroni - Cambium Networks
Alessio Murroni - Cambium NetworksAlessio Murroni - Cambium Networks
Alessio Murroni - Cambium Networks
 
IPTV Basics
IPTV BasicsIPTV Basics
IPTV Basics
 
Cable tv
Cable tvCable tv
Cable tv
 
Epmp brochure 09-16_final
Epmp brochure 09-16_finalEpmp brochure 09-16_final
Epmp brochure 09-16_final
 
Hmmr Presentation Global Online Growth Conference Oct 2016
Hmmr Presentation Global Online Growth Conference Oct 2016Hmmr Presentation Global Online Growth Conference Oct 2016
Hmmr Presentation Global Online Growth Conference Oct 2016
 
Advanced Radio over IP
Advanced Radio over IPAdvanced Radio over IP
Advanced Radio over IP
 
Comtech sspi vsat_day_2010
Comtech sspi vsat_day_2010Comtech sspi vsat_day_2010
Comtech sspi vsat_day_2010
 
IPTV DOC
IPTV DOCIPTV DOC
IPTV DOC
 
Sumavision Wide Screen
Sumavision Wide ScreenSumavision Wide Screen
Sumavision Wide Screen
 
Cambium - delivering superfast wireless broadband services
Cambium - delivering superfast wireless broadband servicesCambium - delivering superfast wireless broadband services
Cambium - delivering superfast wireless broadband services
 

Similar to System aspects of the 3GPP evolution towards enhanced voice services

En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8Saurabh Verma
 
En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8Saurabh Verma
 
Analysis of VoIP Traffic in WiMAX Environment
Analysis of VoIP Traffic in WiMAX EnvironmentAnalysis of VoIP Traffic in WiMAX Environment
Analysis of VoIP Traffic in WiMAX EnvironmentEditor IJMTER
 
Capacity utilization and admission control in the downlinkof WMAX
Capacity utilization and admission control in the downlinkof WMAX Capacity utilization and admission control in the downlinkof WMAX
Capacity utilization and admission control in the downlinkof WMAX marwaeng
 
1 ma197 1e_voice_and_sms_in_lte
1 ma197 1e_voice_and_sms_in_lte1 ma197 1e_voice_and_sms_in_lte
1 ma197 1e_voice_and_sms_in_lteDivyansh Gupta
 
4K and DVB-S2X: How Operators Can Be Cost-Effective
4K and DVB-S2X: How Operators Can Be Cost-Effective4K and DVB-S2X: How Operators Can Be Cost-Effective
4K and DVB-S2X: How Operators Can Be Cost-EffectiveST Engineering iDirect
 
Circuit-Switched Voice Services over HSPA
Circuit-Switched Voice Services over HSPACircuit-Switched Voice Services over HSPA
Circuit-Switched Voice Services over HSPAGeorgios Giannakopoulos
 
An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...
An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...
An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...Cisco Service Provider
 
Fixed Mobile Convergence
Fixed Mobile ConvergenceFixed Mobile Convergence
Fixed Mobile Convergencedanigem
 
Vo ip on 3gpp lte network a survey
Vo ip on 3gpp lte network a surveyVo ip on 3gpp lte network a survey
Vo ip on 3gpp lte network a surveyAlexander Decker
 
52319921 huawei-node-b-manual
52319921 huawei-node-b-manual52319921 huawei-node-b-manual
52319921 huawei-node-b-manualShelton Siziba
 
060626 huawei umts end to-end solution (1)
060626 huawei umts end to-end solution (1)060626 huawei umts end to-end solution (1)
060626 huawei umts end to-end solution (1)Raymund Cortez
 
4G wireless
4G wireless4G wireless
4G wirelessPavan K
 

Similar to System aspects of the 3GPP evolution towards enhanced voice services (20)

VoLTE Performance
VoLTE PerformanceVoLTE Performance
VoLTE Performance
 
2 amrwb
2 amrwb2 amrwb
2 amrwb
 
En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8
 
En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8En tv article_for_3gpp_web_site_v8
En tv article_for_3gpp_web_site_v8
 
Analysis of VoIP Traffic in WiMAX Environment
Analysis of VoIP Traffic in WiMAX EnvironmentAnalysis of VoIP Traffic in WiMAX Environment
Analysis of VoIP Traffic in WiMAX Environment
 
Mobile HD Voice: Global Update report (GSA - November 3, 2015)
Mobile HD Voice: Global Update report (GSA - November 3, 2015)Mobile HD Voice: Global Update report (GSA - November 3, 2015)
Mobile HD Voice: Global Update report (GSA - November 3, 2015)
 
Capacity utilization and admission control in the downlinkof WMAX
Capacity utilization and admission control in the downlinkof WMAX Capacity utilization and admission control in the downlinkof WMAX
Capacity utilization and admission control in the downlinkof WMAX
 
1 ma197 1e_voice_and_sms_in_lte
1 ma197 1e_voice_and_sms_in_lte1 ma197 1e_voice_and_sms_in_lte
1 ma197 1e_voice_and_sms_in_lte
 
4K and DVB-S2X: How Operators Can Be Cost-Effective
4K and DVB-S2X: How Operators Can Be Cost-Effective4K and DVB-S2X: How Operators Can Be Cost-Effective
4K and DVB-S2X: How Operators Can Be Cost-Effective
 
Circuit-Switched Voice Services over HSPA
Circuit-Switched Voice Services over HSPACircuit-Switched Voice Services over HSPA
Circuit-Switched Voice Services over HSPA
 
An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...
An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...
An SDN Based Approach To Measuring And Optimizing ABR Video Quality Of Experi...
 
Broadcast Direct-to-Home (DTH)
Broadcast Direct-to-Home (DTH)Broadcast Direct-to-Home (DTH)
Broadcast Direct-to-Home (DTH)
 
Fixed Mobile Convergence
Fixed Mobile ConvergenceFixed Mobile Convergence
Fixed Mobile Convergence
 
LTE 4G
LTE 4GLTE 4G
LTE 4G
 
Vo ip on 3gpp lte network a survey
Vo ip on 3gpp lte network a surveyVo ip on 3gpp lte network a survey
Vo ip on 3gpp lte network a survey
 
52319921 huawei-node-b-manual
52319921 huawei-node-b-manual52319921 huawei-node-b-manual
52319921 huawei-node-b-manual
 
060626 huawei umts end to-end solution (1)
060626 huawei umts end to-end solution (1)060626 huawei umts end to-end solution (1)
060626 huawei umts end to-end solution (1)
 
Hfc dwdm
Hfc dwdmHfc dwdm
Hfc dwdm
 
4G wireless
4G wireless4G wireless
4G wireless
 
LTE Engg Seminar
LTE Engg SeminarLTE Engg Seminar
LTE Engg Seminar
 

More from Ericsson

Ericsson Technology Review: Versatile Video Coding explained – the future of ...
Ericsson Technology Review: Versatile Video Coding explained – the future of ...Ericsson Technology Review: Versatile Video Coding explained – the future of ...
Ericsson Technology Review: Versatile Video Coding explained – the future of ...Ericsson
 
Ericsson Technology Review: issue 2, 2020
 Ericsson Technology Review: issue 2, 2020 Ericsson Technology Review: issue 2, 2020
Ericsson Technology Review: issue 2, 2020Ericsson
 
Ericsson Technology Review: Integrated access and backhaul – a new type of wi...
Ericsson Technology Review: Integrated access and backhaul – a new type of wi...Ericsson Technology Review: Integrated access and backhaul – a new type of wi...
Ericsson Technology Review: Integrated access and backhaul – a new type of wi...Ericsson
 
Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...
Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...
Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...Ericsson
 
Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...
Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...
Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...Ericsson
 
Ericsson Technology Review: The future of cloud computing: Highly distributed...
Ericsson Technology Review: The future of cloud computing: Highly distributed...Ericsson Technology Review: The future of cloud computing: Highly distributed...
Ericsson Technology Review: The future of cloud computing: Highly distributed...Ericsson
 
Ericsson Technology Review: Optimizing UICC modules for IoT applications
Ericsson Technology Review: Optimizing UICC modules for IoT applicationsEricsson Technology Review: Optimizing UICC modules for IoT applications
Ericsson Technology Review: Optimizing UICC modules for IoT applicationsEricsson
 
Ericsson Technology Review: issue 1, 2020
Ericsson Technology Review: issue 1, 2020Ericsson Technology Review: issue 1, 2020
Ericsson Technology Review: issue 1, 2020Ericsson
 
Ericsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economy
Ericsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economyEricsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economy
Ericsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economyEricsson
 
Ericsson Technology Review: 5G migration strategy from EPS to 5G system
Ericsson Technology Review: 5G migration strategy from EPS to 5G systemEricsson Technology Review: 5G migration strategy from EPS to 5G system
Ericsson Technology Review: 5G migration strategy from EPS to 5G systemEricsson
 
Ericsson Technology Review: Creating the next-generation edge-cloud ecosystem
Ericsson Technology Review: Creating the next-generation edge-cloud ecosystemEricsson Technology Review: Creating the next-generation edge-cloud ecosystem
Ericsson Technology Review: Creating the next-generation edge-cloud ecosystemEricsson
 
Ericsson Technology Review: Issue 2/2019
Ericsson Technology Review: Issue 2/2019Ericsson Technology Review: Issue 2/2019
Ericsson Technology Review: Issue 2/2019Ericsson
 
Ericsson Technology Review: Spotlight on the Internet of Things
Ericsson Technology Review: Spotlight on the Internet of ThingsEricsson Technology Review: Spotlight on the Internet of Things
Ericsson Technology Review: Spotlight on the Internet of ThingsEricsson
 
Ericsson Technology Review - Technology Trends 2019
Ericsson Technology Review - Technology Trends 2019Ericsson Technology Review - Technology Trends 2019
Ericsson Technology Review - Technology Trends 2019Ericsson
 
Ericsson Technology Review: Driving transformation in the automotive and road...
Ericsson Technology Review: Driving transformation in the automotive and road...Ericsson Technology Review: Driving transformation in the automotive and road...
Ericsson Technology Review: Driving transformation in the automotive and road...Ericsson
 
SD-WAN Orchestration
SD-WAN OrchestrationSD-WAN Orchestration
SD-WAN OrchestrationEricsson
 
Ericsson Technology Review: 5G-TSN integration meets networking requirements ...
Ericsson Technology Review: 5G-TSN integration meets networking requirements ...Ericsson Technology Review: 5G-TSN integration meets networking requirements ...
Ericsson Technology Review: 5G-TSN integration meets networking requirements ...Ericsson
 
Ericsson Technology Review: Meeting 5G latency requirements with inactive state
Ericsson Technology Review: Meeting 5G latency requirements with inactive stateEricsson Technology Review: Meeting 5G latency requirements with inactive state
Ericsson Technology Review: Meeting 5G latency requirements with inactive stateEricsson
 
Ericsson Technology Review: Cloud-native application design in the telecom do...
Ericsson Technology Review: Cloud-native application design in the telecom do...Ericsson Technology Review: Cloud-native application design in the telecom do...
Ericsson Technology Review: Cloud-native application design in the telecom do...Ericsson
 
Ericsson Technology Review: Service exposure: a critical capability in a 5G w...
Ericsson Technology Review: Service exposure: a critical capability in a 5G w...Ericsson Technology Review: Service exposure: a critical capability in a 5G w...
Ericsson Technology Review: Service exposure: a critical capability in a 5G w...Ericsson
 

More from Ericsson (20)

Ericsson Technology Review: Versatile Video Coding explained – the future of ...
Ericsson Technology Review: Versatile Video Coding explained – the future of ...Ericsson Technology Review: Versatile Video Coding explained – the future of ...
Ericsson Technology Review: Versatile Video Coding explained – the future of ...
 
Ericsson Technology Review: issue 2, 2020
 Ericsson Technology Review: issue 2, 2020 Ericsson Technology Review: issue 2, 2020
Ericsson Technology Review: issue 2, 2020
 
Ericsson Technology Review: Integrated access and backhaul – a new type of wi...
Ericsson Technology Review: Integrated access and backhaul – a new type of wi...Ericsson Technology Review: Integrated access and backhaul – a new type of wi...
Ericsson Technology Review: Integrated access and backhaul – a new type of wi...
 
Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...
Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...
Ericsson Technology Review: Critical IoT connectivity: Ideal for time-critica...
 
Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...
Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...
Ericsson Technology Review: 5G evolution: 3GPP releases 16 & 17 overview (upd...
 
Ericsson Technology Review: The future of cloud computing: Highly distributed...
Ericsson Technology Review: The future of cloud computing: Highly distributed...Ericsson Technology Review: The future of cloud computing: Highly distributed...
Ericsson Technology Review: The future of cloud computing: Highly distributed...
 
Ericsson Technology Review: Optimizing UICC modules for IoT applications
Ericsson Technology Review: Optimizing UICC modules for IoT applicationsEricsson Technology Review: Optimizing UICC modules for IoT applications
Ericsson Technology Review: Optimizing UICC modules for IoT applications
 
Ericsson Technology Review: issue 1, 2020
Ericsson Technology Review: issue 1, 2020Ericsson Technology Review: issue 1, 2020
Ericsson Technology Review: issue 1, 2020
 
Ericsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economy
Ericsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economyEricsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economy
Ericsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economy
 
Ericsson Technology Review: 5G migration strategy from EPS to 5G system
Ericsson Technology Review: 5G migration strategy from EPS to 5G systemEricsson Technology Review: 5G migration strategy from EPS to 5G system
Ericsson Technology Review: 5G migration strategy from EPS to 5G system
 
Ericsson Technology Review: Creating the next-generation edge-cloud ecosystem
Ericsson Technology Review: Creating the next-generation edge-cloud ecosystemEricsson Technology Review: Creating the next-generation edge-cloud ecosystem
Ericsson Technology Review: Creating the next-generation edge-cloud ecosystem
 
Ericsson Technology Review: Issue 2/2019
Ericsson Technology Review: Issue 2/2019Ericsson Technology Review: Issue 2/2019
Ericsson Technology Review: Issue 2/2019
 
Ericsson Technology Review: Spotlight on the Internet of Things
Ericsson Technology Review: Spotlight on the Internet of ThingsEricsson Technology Review: Spotlight on the Internet of Things
Ericsson Technology Review: Spotlight on the Internet of Things
 
Ericsson Technology Review - Technology Trends 2019
Ericsson Technology Review - Technology Trends 2019Ericsson Technology Review - Technology Trends 2019
Ericsson Technology Review - Technology Trends 2019
 
Ericsson Technology Review: Driving transformation in the automotive and road...
Ericsson Technology Review: Driving transformation in the automotive and road...Ericsson Technology Review: Driving transformation in the automotive and road...
Ericsson Technology Review: Driving transformation in the automotive and road...
 
SD-WAN Orchestration
SD-WAN OrchestrationSD-WAN Orchestration
SD-WAN Orchestration
 
Ericsson Technology Review: 5G-TSN integration meets networking requirements ...
Ericsson Technology Review: 5G-TSN integration meets networking requirements ...Ericsson Technology Review: 5G-TSN integration meets networking requirements ...
Ericsson Technology Review: 5G-TSN integration meets networking requirements ...
 
Ericsson Technology Review: Meeting 5G latency requirements with inactive state
Ericsson Technology Review: Meeting 5G latency requirements with inactive stateEricsson Technology Review: Meeting 5G latency requirements with inactive state
Ericsson Technology Review: Meeting 5G latency requirements with inactive state
 
Ericsson Technology Review: Cloud-native application design in the telecom do...
Ericsson Technology Review: Cloud-native application design in the telecom do...Ericsson Technology Review: Cloud-native application design in the telecom do...
Ericsson Technology Review: Cloud-native application design in the telecom do...
 
Ericsson Technology Review: Service exposure: a critical capability in a 5G w...
Ericsson Technology Review: Service exposure: a critical capability in a 5G w...Ericsson Technology Review: Service exposure: a critical capability in a 5G w...
Ericsson Technology Review: Service exposure: a critical capability in a 5G w...
 

Recently uploaded

Swan(sea) Song – personal research during my six years at Swansea ... and bey...
Swan(sea) Song – personal research during my six years at Swansea ... and bey...Swan(sea) Song – personal research during my six years at Swansea ... and bey...
Swan(sea) Song – personal research during my six years at Swansea ... and bey...Alan Dix
 
Pigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions
 
costume and set research powerpoint presentation
costume and set research powerpoint presentationcostume and set research powerpoint presentation
costume and set research powerpoint presentationphoebematthew05
 
Human Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR SystemsHuman Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR SystemsMark Billinghurst
 
Understanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitectureUnderstanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitecturePixlogix Infotech
 
Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024BookNet Canada
 
Streamlining Python Development: A Guide to a Modern Project Setup
Streamlining Python Development: A Guide to a Modern Project SetupStreamlining Python Development: A Guide to a Modern Project Setup
Streamlining Python Development: A Guide to a Modern Project SetupFlorian Wilhelm
 
Bluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdfBluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdfngoud9212
 
Unlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power SystemsUnlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power SystemsPrecisely
 
Key Features Of Token Development (1).pptx
Key  Features Of Token  Development (1).pptxKey  Features Of Token  Development (1).pptx
Key Features Of Token Development (1).pptxLBM Solutions
 
Benefits Of Flutter Compared To Other Frameworks
Benefits Of Flutter Compared To Other FrameworksBenefits Of Flutter Compared To Other Frameworks
Benefits Of Flutter Compared To Other FrameworksSoftradix Technologies
 
Science&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdfScience&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdfjimielynbastida
 
Making_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptx
Making_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptxMaking_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptx
Making_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptxnull - The Open Security Community
 
Artificial intelligence in the post-deep learning era
Artificial intelligence in the post-deep learning eraArtificial intelligence in the post-deep learning era
Artificial intelligence in the post-deep learning eraDeakin University
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Enterprise Knowledge
 
Install Stable Diffusion in windows machine
Install Stable Diffusion in windows machineInstall Stable Diffusion in windows machine
Install Stable Diffusion in windows machinePadma Pradeep
 
Scanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsScanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsRizwan Syed
 

Recently uploaded (20)

Swan(sea) Song – personal research during my six years at Swansea ... and bey...
Swan(sea) Song – personal research during my six years at Swansea ... and bey...Swan(sea) Song – personal research during my six years at Swansea ... and bey...
Swan(sea) Song – personal research during my six years at Swansea ... and bey...
 
Pigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food ManufacturingPigging Solutions in Pet Food Manufacturing
Pigging Solutions in Pet Food Manufacturing
 
costume and set research powerpoint presentation
costume and set research powerpoint presentationcostume and set research powerpoint presentation
costume and set research powerpoint presentation
 
Human Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR SystemsHuman Factors of XR: Using Human Factors to Design XR Systems
Human Factors of XR: Using Human Factors to Design XR Systems
 
Understanding the Laravel MVC Architecture
Understanding the Laravel MVC ArchitectureUnderstanding the Laravel MVC Architecture
Understanding the Laravel MVC Architecture
 
Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
Transcript: #StandardsGoals for 2024: What’s new for BISAC - Tech Forum 2024
 
Streamlining Python Development: A Guide to a Modern Project Setup
Streamlining Python Development: A Guide to a Modern Project SetupStreamlining Python Development: A Guide to a Modern Project Setup
Streamlining Python Development: A Guide to a Modern Project Setup
 
Bluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdfBluetooth Controlled Car with Arduino.pdf
Bluetooth Controlled Car with Arduino.pdf
 
Unlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power SystemsUnlocking the Potential of the Cloud for IBM Power Systems
Unlocking the Potential of the Cloud for IBM Power Systems
 
The transition to renewables in India.pdf
The transition to renewables in India.pdfThe transition to renewables in India.pdf
The transition to renewables in India.pdf
 
Key Features Of Token Development (1).pptx
Key  Features Of Token  Development (1).pptxKey  Features Of Token  Development (1).pptx
Key Features Of Token Development (1).pptx
 
Benefits Of Flutter Compared To Other Frameworks
Benefits Of Flutter Compared To Other FrameworksBenefits Of Flutter Compared To Other Frameworks
Benefits Of Flutter Compared To Other Frameworks
 
Science&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdfScience&tech:THE INFORMATION AGE STS.pdf
Science&tech:THE INFORMATION AGE STS.pdf
 
Making_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptx
Making_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptxMaking_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptx
Making_way_through_DLL_hollowing_inspite_of_CFG_by_Debjeet Banerjee.pptx
 
Hot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort Service
Hot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort ServiceHot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort Service
Hot Sexy call girls in Panjabi Bagh 🔝 9953056974 🔝 Delhi escort Service
 
Artificial intelligence in the post-deep learning era
Artificial intelligence in the post-deep learning eraArtificial intelligence in the post-deep learning era
Artificial intelligence in the post-deep learning era
 
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024
 
Install Stable Diffusion in windows machine
Install Stable Diffusion in windows machineInstall Stable Diffusion in windows machine
Install Stable Diffusion in windows machine
 
Scanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL CertsScanning the Internet for External Cloud Exposures via SSL Certs
Scanning the Internet for External Cloud Exposures via SSL Certs
 
Vulnerability_Management_GRC_by Sohang Sengupta.pptx
Vulnerability_Management_GRC_by Sohang Sengupta.pptxVulnerability_Management_GRC_by Sohang Sengupta.pptx
Vulnerability_Management_GRC_by Sohang Sengupta.pptx
 

System aspects of the 3GPP evolution towards enhanced voice services

  • 1. ABSTRACT The Enhanced Voice Services (EVS) codec was standardized by 3GPP in 2014. This codec offers significant gains in voice quality, efficiency, channel error robustness over any other existing speech codec and far better music quality. Operators run voice services on a large installed base of 3GPP Circuit-Switched (CS) 2G (GERAN) or 3G (UTRAN) radio networks. These networks offer mobile voice service either as HD voice using the AMR-WB codec, or as traditional narrowband (NB) voice service, based on the AMR codec. Voice over LTE (VoLTE) is currently being deployed throughout the world with HD Voice. The EVS codec will be first introduced as a straightforward VoLTE upgrade. It is also expected that EVS will be deployed over 3G CS networks. This paper describes system aspects relating to EVS codec introduction in VoLTE and CS networks as well as interworking and mobility with legacy systems and services. Index Terms— EVS, HD voice, VoLTE 1. INTRODUCTION Since the introduction of GSM mobile telephony, created by the European Telecommunications Standards Institute (ETSI) in the early 1990’s, the world has witnessed a tremendous technical revolution in the area of mobile communication that has penetrated everybody’s life and changed human society disruptively. Even though mobile telephony triggered this development, users did not experience a lot of changes in this service. However, in reality mobile operators have steadily improved their voice service offerings with optimizations in terms of quality, system capacity and robustness in fast growing mobile systems. The 3rd Generation Partnership Project (3GPP) speech codec standards from GSM Full Rate (FR) [1] over Half Rate (HR) [2] and Enhanced Full Rate (EFR) [3] to the Adaptive Multi-Rate (AMR) codec [4] mark milestones of this development. Only recently users have started experiencing substantial quality improvements. This change came with the introduction of HD (high-definition) voice providing wideband (WB) audio with a frequency range from ca. 50 – 7000 Hz compared to traditional NB voice with about 100 – 3500 Hz. HD voice leads to noticeably enhanced and more natural speech quality. AMR-WB [5], the codec used for HD voice in 3GPP systems, was standardized in year 2001, only three years after AMR. Nevertheless, it took still until year 2009 before its first deployment in a real life network. Reasons were manifold: technical, infrastructural and commercial. This picture changed with the advent of Voice-over-IP (VoIP) and Over-The-Top (OTT) voice services, offering WB speech quality. Mobile operators understood that investments into voice quality were a necessary means to maintain their own service offerings attractive and to avoid customer churn. HD voice now turns into a big success [6]. The mobile industry and operators hope to continue this success story by service evolution towards even higher quality voice services. It is understood that 3GPP voice services have to remain leading edge, even after roll-out of HD voice, in order to succeed in a fierce competition environment. Consequently, in year 2010 3GPP launched the standardization of a new codec for “Enhanced Voice Services”, targeted to become the successor of the current HD voice codec AMR-WB in LTE networks [7][8]. The EVS codec standard [9]-[19] was successfully finalized in September 2014, meeting or exceeding the standardization goals. The goals were to enable clear benefits over existing AMR-WB based 3GPP voice services in terms of overall service quality, efficiency and interoperability. The EVS codec offers a toolbox of high performance properties and features comprising: high-quality super-wideband (SWB) and fullband (FB) voice; high- capacity/high-quality NB and WB voice; high-quality music/non- speech signal performance; and high robustness to error-prone VoIP transmission frameworks. SWB voice ranges from about 20 – 15000 Hz, while FB voice extends to about 20000 Hz covering the complete human audible spectrum. In addition, the EVS codec maintains backward compatibility with AMR-WB, thus avoiding interoperability problems or any hard-cut decisions against AMR- WB during its introduction. This paper provides insights in solutions for the complex task to bridge the gap between legacy voice services and cutting edge EVS, given the heterogeneity of existing 3GPP systems. The paper first describes voice services in 3GPP systems covering legacy CS networks and 4G Packet-Switched (PS) systems with LTE access, i.e. VoLTE [20]. Adaptation principles at call setup and during the call are then addressed as well as interoperability aspects under various system configuration and mobility scenarios. The conclusion of the paper sketches the envisioned smooth migration path towards the new EVS. 2. VOICE IN 3GPP SYSTEMS 2.1. Voice in CS networks Like the earlier 3GPP speech codecs GSM FR, GSM HR and GSM EFR, AMR was originally developed and standardized by ETSI for CS mobile telephony in the GSM system. The AMR standard for that system (more general GERAN) includes besides the speech codec [21] further components such as channel coding [22], rate adaptation and in-band rate control [23]. The codec comprises 8 modes with net bitrates from 4.75 to 12.2 kbps. AMR rate adaptation allows selecting the most suitable mode for a given radio channel condition, hence choosing the mode that enables best possible quality. Together with FR/HR traffic channel adaptation this allows operators flexibly trading speech quality against system capacity. A cornerstone of the adaptation in GERAN is the feedback channel, allowing signaling codec mode requests (CMR), i.e. adaptation commands, back from the receiving end to the sending end. The AMR concept is discussed in detail in [24]. Based on its merits in comparison with other contenders like G.729 [25], EVRC [26], MPEG-4 Audio [27], and for interoperation with AMR in GERAN systems, 3GPP selected SYSTEM ASPECTS OF THE 3GPP EVOLUTION TOWARDS ENHANCED VOICE SERVICES Stefan Bruhn, Tomas Frankkila, Frédéric Gabin, Karl Hellwig, Maria Hultström Ericsson AB
  • 2. AMR in 1999 as the mandatory codec for the new UMTS. Compared to GERAN, AMR adaptation in UTRAN serves a different purpose, namely load control [28]. Like AMR, AMR-WB was originally specified for GERAN and UTRAN networks. All principles and mechanisms related to adaptation were retained. The codec includes 9 different modes, from 6.60 to 23.85 kbps. In order to harmonize interworking, 3GPP agreed on one mandatory configuration with a set of modes (active codec set (ACS)) that all GERAN and UTRAN infrastructure must support. This mode set comprises the three lower rate modes of AMR-WB 6.60, 8.85 and 12.65. Even today when AMR-WB is operated in VoLTE networks using its highest mode 23.85, for backward compatibility with CS networks the three low rate modes must always be included in a mode set. The new EVS codec was originally developed for PS multi- media telephony services over LTE. However, its strong performance has triggered interest to standardize it as well for use in voice services in UTRAN CS networks. Accordingly, 3GPP launched a work item “EVSoCS” [29] in September 2014 with the objective to enable users of 3G services to benefit from the enhanced user experience, system capacity and interoperability provided by EVS. It will be of main importance to make sure that EVS can be introduced into 3G CS systems at minimum system impact. The work item is currently ongoing and is expected to be finalized by December 2015. 2.2. Voice over LTE (VoLTE) With VoLTE, the operator offers a carrier-grade voice service by ensuring Quality of Service (QoS) with the use of Guaranteed Bit Rate (GBR) bearers for voice. VoLTE makes use of the Real-time Transport Control Protocol (RTCP) associated with the Real-time Transport Protocol (RTP) [30] to monitor voice quality. Although even OTT services could benefit from the excellent quality, efficiency and robustness of the EVS codec, they cannot guarantee a carrier-grade service when using best effort bearers without QoS. VoLTE enables telephony – including emergency services – and messaging over the 4G networks. The GSM Association (GSMA) specified VoLTE in their PRD IR.92 IMS Profile for Voice and SMS [20]. The VoLTE profile is a subset of the 3GPP IMS standard functionalities [31]. The goal of the VoLTE profile is to accelerate adoption by simplifying the implementation. This is achieved via careful selection of the most appropriate features. The objective is on its way to being accomplished: according to GSA (the Global mobile Suppliers Association) by July 2015: “25 operators in 16 countries have commercially launched VoLTE-based HD voice service, compared to just 3 launched in March 2014. Many more launches are anticipated in 2015” [32]. From the first version of the profile, VoLTE terminals must support AMR codec and optionally support AMR-WB codec. From version 9.0 of the profile they also must support the AMR-WB codec; the EVS codec is mandatory for SWB and FB and recommended for NB and WB. However, all VoLTE terminals on the market are HD Voice capable and hence support AMR-WB. HD voice can therefore be enabled where operators have chosen to implement AMR-WB in network entities terminating the user plane (for example, Media Gateways (MGW), Media Resource Function Processors (MRFP), Conferencing Units and Application Servers). Although EVS is not mandatory for VoLTE terminals supporting WB, GSMA is currently in the process of adding EVS operated in WB modes to the list of allowed codecs in the HD voice minimum requirements [33]. The EVS codec includes, besides EVS primary modes, AMR- WB interoperable (IO) modes enabling interworking with AMR- WB implementations. The EVS AMR-WB IO modes offer improved quality over the original AMR-WB modes [34]. Therefore the standard allows a VoLTE terminal to use its EVS implementation operated with AMR-WB IO modes in place of the AMR-WB codec. The EVS encoder adapts the bitrate of each frame based on a received Codec Mode Request. These rate adaptation operations generally follow the principle introduced with AMR and are described in section 3. VoLTE uses the RTP [30] carriage of user plane information between end-points. Each encoded frame is encapsulated as a payload in the RTP protocol. The RTP payload format for EVS is specified in Annex A of 3GPP TS 26.445 [13]. It actually defines two formats, a compact format and a header-full format. The former offers efficient transmission without any payload header. The latter format in contrast enables encapsulating several frames in the payload and also enables signaling CMR. The Session Description Protocol (SDP) [35] is used by end- points to describe the session parameters. The session establishment for the VoLTE call requires a negotiation between end-points as their capabilities may differ. End-points could be VoLTE terminals, but also MGWs for transcoding or other Application Servers that may be used e.g. for producing call- progress tones. This negotiation uses the Offer/Answer model [36] that is used between these end-points. In the case of a Mobile Originated call, the VoLTE terminal originating the call sends an SDP offer, describing all its capabilities. This includes in particular media capabilities like the list of codecs supported and associated modes of audio bandwidth, bitrates, type of RTP packetization and desired bearer bandwidth. It is one important design requirement that the call setup time be minimized so as to improve user experience. Although the Offer/Answer mechanisms can resolve complex heterogeneous cases of media capabilities to result in compatible session characteristics, it is important to minimize the number of handshakes. For this reason it is for example mandatory to support all codec modes for AMR and AMR-WB, respectively, and to offer all of them in a so-called “open-offer”. An “open-offer” defines no specific mode set. This enables the distant VoLTE client or MGW to produce an answer compatible to its capabilities in just one handshake. Furthermore, the operator’s network can also tailor the offered SDP in a Session Border Gateway (SBG) to apply a particular policy like e.g. limiting the maximum bitrate or restricting to SWB operation. Applying a particular policy in the network, rather than in customized devices, also has the advantage that it becomes applicable to inbound roamers. Finally, sending an “open-offer” improves interworking as described in section 4. Once the session is negotiated and bearers are established, RTP packets can be transmitted and received over the UDP [37] ports of the VoLTE terminals. Any conversational voice service requires a low end-to-end delay for good interactivity of the conversations. The LTE radio bearers used for voice traffic are configured to minimize delay by setting the RLC (Radio Link Control) layer in unacknowledged mode. This is made possible by the inherent robustness of the AMR, AMR-WB and EVS decoder to lost packets. Furthermore, in a packet based system, packets experience different transmission delays and this delay variation, the jitter, must be handled by receivers. The standard defines minimum performances for the jitter management. Also, the EVS codec comes with a specified jitter manager [16].
  • 3. Enabling VoLTE to VoLTE calls with the EVS codec within an existing VoLTE infrastructure requires minimal upgrades. For the VoLTE terminal, besides EVS codec support, there are requirements on the acoustic and speech enhancements functions. These requirements depend on the supported audio bandwidth; more evolved requirements than for HD voice apply if the service shall be operated with SWB or FB audio bandwidth. The network upgrades are limited to the modification of policy functions allowing the negotiation of the EVS codec end-to-end. For example a policy could be to limit the maximum bitrate of operation to 13.2 kbps to benefit from the same network dimensioning as AMR12.2 kbps and AMR-WB 12.65 kbps, yet still allowing to provide excellent SWB voice quality. There is no requirement to implement any particular policy between EVS end- points, but an operator may choose to do so by configuring the policies in the SBG. Further, multiparty conferencing requires upgrade of the Media Resource Function. A system view of the network impact of EVS introduction is provided in Figure 1. The changes required enabling end-to-end VoLTE to 3G Circuit Switched EVS calls and operation with switching to 2G or 3G (Single Radio Voice Call Continuity - SRVCC) are described in section 4. 3. CALL SETUP AND IN-CALL ADAPTATION 3.1. Call setup Call setup works differently in CS and PS 3GPP systems but follows similar principles. The general purpose is the definition of operation parameters of the used codec(s) for the subsequent call and of the range within which in-call adaptation is allowed. For AMR and AMR-WB, call setup procedures essentially determine the codec modes (bitrates) among which adaptation is possible during the call. For interoperability reasons, a mode set should be chosen that comprises at least some common low-rate modes that are generally supported, even when roaming within or among various networks. For EVS applications in VoLTE, TS 26.445 Annex A [13] specifies parameters related to EVS primary and AMR-WB IO mode operation. Bit rate can be specified as a single value or a range of bitrates. Likewise, audio bandwidth can be defined as a single value or a range from NB to a given maximum audio bandwidth. Parameters may be specified individually per call direction or jointly for both directions. For EVSoCS, the call setup is not yet standardized. It is however envisioned that suitable call control protocol information elements are specified allowing defining similar operation configurations as for PS. Such kind of harmonization will greatly facilitate EVS interoperability between CS and PS (VoLTE) domains. 3.2. In-call adaptation In this paper, in-call adaptation refers to adaptation of the codec application layer. Adaptation of lower protocol layers (e.g. power control, adaptation of modulation schemes, transport format combination selection based on available power, cell and transport network load adaptations, etc.) occurs frequently. It is system specific for e.g. the radio access technology used. Such kind of adaptation is not covered here. In-call adaptation has the general purpose, described in section 2.1, to adjust the coding mode to changed system conditions, in order to optimize capacity or service quality. A changed condition requiring selecting a new coding mode may also occur in case of a cell hand-over where the previously used codec mode may not be supported any longer or not be suitable. For AMR and AMR-WB, adaptation is possible with respect to bitrate. For EVS, audio bandwidth is an important further adaptation dimension. Adaptation of the audio bandwidth may e.g. become necessary when the audio front- or backend changes. Adaptation of the encoding audio bandwidth in response to a change of input audio bandwidth is done autonomously by the encoder up to a given maximum audio bandwidth. A change of the output audio bandwidth may on the other hand trigger a CMR from the receiving end to the sending end, accordingly adjusting the maximum audio bandwidth for encoding. A change of encoding bitrate may also result in a changed audio bandwidth since not all audio bandwidths are supported by all bitrates. A further important adaptation dimension of the EVS codec is the capability to switch between EVS primary modes and AMR- WB IO modes. This kind of adaptation is crucial when a terminal moves between cells with EVS support and cells supporting HD voice but not EVS. Especially during roll-out of VoLTE this may frequently occur since VoLTE coverage may exist only for hot spots while other areas are still only covered by 3G or 2G networks offering HD voice. The possibility to adapt seamlessly between EVS primary modes and AMR-WB IO modes ensures always highest possible service quality and the avoidance of call discontinuities due to codec changes that might otherwise occur. This also avoids the need to use transcoding between networks with EVS and with only HD voice support. Transcoding would degrade quality and require operator investments. For VoLTE, CMRs are transmitted in-band as part of the RTP payload format or using RTCP. The use of CMR is generally preferable due to lower latency and lower signaling overhead. For AMR and AMR-WB, the RTP payload format [38] specifies a CMR field as part of the payload header. Likewise for EVS, the EVS RTP payload format specifies a CMR field supporting requests for bitrate, audio bandwidth, EVS primary or AMR-WB IO modes and further features. Codec mode adaptation for EVSoCS is not yet specified. However, it is desirable to allow adaptation along the same dimensions as for EVS in VoLTE. A complication in UTRAN is that rate control is maximum rate control. This means that any rate up to the maximum may be chosen by autonomous decisions by the Figure 1: Network impact - EVS codec (green = impacted) VoLTE Terminal Core Network IMS Core CS Core eNodeB NodeB 2G/3G Terminal ATCF/ SBG ATGW/ BGF MRF EVS for Conferencing Interworking and EVS-AMR-WB Fast SRVCC RNC RNC EVS enabled 3G Terminal NodeB PSTNInternet/ WiFi Fixed broadband access (e.g. DECT) Acronyms used: ATCF Access Transfer Control Function ATGW Access Transfer Gateway BGF Border Gateway Function MRF Media Resource Function MSC Mobile Switching Center Server PSTN Public Switched Telephone Network MGWMSC
  • 4. Radio Network Controller (RNC), depending on the available radio resource, and by the terminal, depending on instantaneous transmit power needs for a codec mode in relation to certain transmit power limits. Uplink rate control commands are signaled to the terminal by means of the Radio Resource Control (RRC) protocol rather than in-band CMR. Similarly, for downlink rate control, RNC sends Rate Control Request (RC-Req) messages to the CS Core. This concept is too limited for EVS with its additional adaptation dimensions. It is therefore envisioned that the existing adaptation signaling is combined with additional in-band CMR signaling. The terminal and likewise MGW in the CS Core would receive both kinds of adaptation signaling messages and merely combine them in a suitable way. 4. INTEROPERABILITY ASPECTS 4.1. Interworking between VoLTE and CS networks Interworking between public land mobile networks (PLMN) is a strong point of the VoLTE specification. When OTT service providers only create islands of compatible clients, operators can enable their subscribers using VoLTE native client to communicate with any other PSTN phone or 3GPP VoLTE or CS compatible terminal, be it under 2G, 3G or 4G/Wi-Fi coverage (see also Figure 1). An EVS VoLTE call between two operator’s networks requires EVS enabled VoLTE clients, but also that the interworking agreement between operators implements compatible policies. For example, if one operator forces EVS VoLTE calls within its network to negotiate only SWB modes and the other restricts EVS VoLTE calls to only WB modes, no compatible EVS mode can be found to operate transcoder free. The agreement between operators can only operate when VoLTE terminals use “open-offer” at session negotiation. Indeed, an important motivation of the “open- offer” is to guarantee that tandem free interworking can be established with any other remote terminal and network, regardless of whether the remote network is 2G/GSM, 3G/WCDMA, 4G/LTE, WiFi, fixed, non-3GPP or anything else, no matter what configuration that terminal and network allows. When operating between VoLTE and CS networks, an upgrade is required to the Media Gateway to handle transcoding from and to different codecs. When EVS is supported on both sides, transcoder free interworking can be achieved. This is only possible if the subset of EVS modes operated on the CS side is compatible. By sending an “open-offer”, the VoLTE terminal allows the network to limit the EVS modes to the ones compatible with the CS side. In order to achieve backwards compatibility and interworking with CS networks with transcoder free operation (TrFO), for optimal performance and resource utilization, it is required that the three lowest AMR-WB codec modes are included in the VoLTE mode set. Backwards compatibility with transcoding is always a possibility. When operating between two CS networks with EVS, it can be a challenge for operators to agree on a single codec set. The standard can limit the relevant sets but should not limit the flexibility offered to operators to run their networks at their preferred operating points. One proposal that can improve the situation is if the EVSoCS mode sets are constructed such that the lowest bitrates are always included and when an audio bandwidth is offered, all smaller audio bandwidths are also offered. With this principle, it is always possible to find a compatible set enabling TrFO between CS networks. 4.2. Mobility and AMR-WB backward compatibility of EVS Mobility is an essential feature of mobile communication systems and continuity of voice calls is expected by moving users. The introduction of LTE made the CS fallback and SRVCC handovers from VoLTE to 2G/3G systems essential. Typically, the SRVCC procedure requires the addition of a transcoding function in the path. This comes with speech interruptions and with added costs. As described in section 2.2, a subset of the EVS modes is compatible with the AMR-WB codec. In addition to allowing an EVS implementation to efficiently replace an AMR-WB implementation, this also enables transcoder free operation between an end-point operating EVS and the other operating AMR-WB under the condition that a compatible mode set is used. In the case of SRVCC during an EVS VoLTE-VoLTE call, assuming the used codec in the target CS network is known, it is well possible to avoid any transcoding function and minimize speech interruptions in the following way: If the target codec is EVS over CS, the gateway can – prior to the switch – control the EVS codec rate used by the VoLTE terminal such that it is compatible with the target EVS set. During the switch, no interruption due to incompatibility of speech modes is experienced. Likewise, if the target codec is AMR-WB, the gateway would – prior to the switch – make sure that the VoLTE terminal uses AMR-WB IO modes that are compatible with the target AMR-WB mode set. 5. CONCLUSION Today 3GPP voice services are globally implemented in a large variety of 3GPP systems that have been continuously evolving like the service itself. Improvements to service quality and system efficiency/capacity have been the driver of that evolution under the fundamental constraint to warrant interworking with legacy systems and devices. HD voice is now broadly deployed and VoLTE is taking off. 3GPP has standardized a new codec for EVS over LTE and launched the standardization process to make EVS available even for 3G CS networks. This will take the evolution to its next stage. Despite large system heterogeneity the evolution towards EVS proceeds along a smooth migration path. It turns out that underlying principles of codec adaptation at call setup and in-call have not substantially changed since they were first time applied with AMR. This means that there are many commonalities which facilitate a smooth evolution. Careful design of suitable hand-over mechanisms supporting efficient interworking and service continuity in various mobility and roaming cases is another essential component of this. One important aspect with the introduction of the new EVS is that it can be done with minimum system impact. In case the system already supports VoLTE based HD voice no other network upgrades than just adding EVS codec support to the control plane are necessary. Further upgrades of SBG/BGF will enable transcoder free interworking with CS 2G/3G HD voice deployments and transcoding to other HD voice codecs in e.g. the fixed-network or Internet realms. Migration towards EVS will be smooth even in terms of radio network planning. EVS can operate in its high-quality SWB modes providing natural voice sound unprecedented in mobile telephony at rates no larger than required for existing HD voice. The deployment in an operator- controlled network with QoS mechanisms in place ensures guaranteed telecom grade service quality. This is a substantial advantage over OTT voice services that, in contrast, cannot guarantee good voice service quality for the users.
  • 5. 6. REFERENCES [1] 3GPP TS 46.001, “Full Rate Speech Processing Functions”. [2] 3GPP TS 46.002, “Half Rate Speech Processing Functions”. [3] 3GPP TS 46.051, “GSM Enhanced full rate speech processing functions: General description”. [4] 3GPP TS 26.071, “Mandatory speech CODEC speech processing functions; AMR speech Codec; General description”. [5] 3GPP TS 26.171, “Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; General description”. [6] Mobile HD voice Global Update report, GSA, April 23, 2015. [7] S. Bruhn et al., “Standardization of the new 3GPP EVS Codec” Proc. ICASSP, April 2015. [8] SP-140151, 3GPP Work Item Description “Codec for Enhanced Voice Services”. [9] 3GPP TS 26.441, “Codec for Enhanced Voice Services (EVS); General overview”. [10] 3GPP TS 26.442, “Codec for Enhanced Voice Services (EVS); ANSI C code (fixed-point)”. [11] 3GPP TS 26.443, “Codec for Enhanced Voice Services (EVS); ANSI C code (floating-point)”. [12] 3GPP TS 26.444, “Codec for Enhanced Voice Services (EVS); Test sequences”. [13] 3GPP TS 26.445, “Codec for Enhanced Voice Services (EVS); Detailed algorithmic description”. [14] 3GPP TS 26.446, “Codec for Enhanced Voice Services (EVS); Adaptive Multi-Rate - Wideband (AMR-WB) backward compatible functions”. [15] 3GPP TS 26.447, “Codec for Enhanced Voice Services (EVS); Error concealment of lost packets”. [16] 3GPP TS 26.448, “Codec for Enhanced Voice Services (EVS); Jitter buffer management”. [17] 3GPP TS 26.449, “Codec for Enhanced Voice Services (EVS); Comfort Noise Generation (CNG) aspects”. [18] 3GPP TS 26.450, “Codec for Enhanced Voice Services (EVS); Discontinuous Transmission (DTX)”. [19] 3GPP TS 26.451, “Codec for Enhanced Voice Services (EVS); Voice Activity Detection (VAD)”. [20] GSMA IR.92 IMS Profile for Voice and SMS. [21] 3GPP TS 26.090, “Mandatory Speech Codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec; Transcoding functions”. [22] 3GPP TS 45.003, “Channel coding”. [23] 3GPP TS 45.009, “Link adaptation”. [24] S. Bruhn et al., “Concepts and solutions for link adaptation and inband signaling for the GSM AMR speech coding standard”, IEEE 49th VTC, 1999. [25] ITU-T Recommendation G.729, “Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)”. [26] 3GPP2 C.S0014, “"Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems". [27] ISO/IEC 14496-3 (MPEG-4 version 1) Audio Part. [28] M. Karlsson et al., “Joint Capacity and Quality Evaluation for AMR Telephony Speech in WCDMA Systems”, IEEE 56th VTC, 2002. [29] SP-140485, 3GPP Work Item Description “Support of EVS in 3G Circuit-Switched Networks”. [30] IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications. [31] 3GPP TS 26.114, “IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction”. [32] July 22, 2015: GSA confirms 422 LTE networks launched, Cat 6 LTE-Advanced deployments setting the pace, (http://www.gsacom.com/news/gsa_430.php). [33] Minimum Technical Requirements for use of the HD Voice Logo with LTE issued by GSMA (Annex F), Version 1.0, 4 April 2014. [34] 3GPP TR 26.952, “Codec for Enhanced Voice Services (EVS); Performance characterization”. [35] IETF RFC 4566, “SDP: Session Description Protocol”. [36] IETF RFC 3264, “An Offer/Answer Model with Session Description Protocol (SDP)”. [37] IETF RFC 768, “User Datagram Protocol”. [38] IETF RFC 4867 (2007), "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs".