volte depl oyment and the radio acc ess net work/media/white...

Rev. A 08/12

VoLTE DEpLoymEnT anD ThE raDio accEss nETwork The LTE User Equipment PerspectiveAugust 2012

SPIRENT1325 Borregas Avenue Sunnyvale, CA 94089 USA

Email: [email protected] Web: http://www.spirent.com

AmERIcAS 1-800-SPIRENT • +1-818-676-2683 • [email protected]

EuRoPE ANd ThE mIddlE EAST +44 (0) 1293 767979 • [email protected]

ASIA ANd ThE PAcIfIc +86-10-8518-2539 • [email protected]

© 2012 Spirent. All Rights Reserved.

All of the company names and/or brand names and/or product names referred to in this document, in particular, the name “Spirent” and its logo device, are either registered trademarks or trademarks of Spirent plc and its subsidiaries, pending registration in accordance with relevant national laws. All other registered trademarks or trademarks are the property of their respective owners.

The information contained in this document is subject to change without notice and does not represent a commitment on the part of Spirent. The information in this document is believed to be accurate and reliable; however, Spirent assumes no responsibility or liability for any errors or inaccuracies that may appear in the document.

VoLTE Deployment and the Radio Access Network The LTE User Equipment Perspective

Spirent white paper • i

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Dedicated Bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

semi-Persistent scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Robust Header Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

transmission time Interval Bundling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Lte Voice and Legacy Voice services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Considerations for Lte Ue Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

1 • sPIRent wHIte PaPeR


IntRoDUCtIon

one promise of Long term evolution (Lte)

is the availability of a relatively flat, all-IP

access technology that provides a bandwidth-

efficient method of delivering multiple types

of user traffic simultaneously . Indeed, the

ability to deploy Voice over IP (VoIP) services

such as Voice over Lte (VoLte), while also

allowing high-rate data transfers, is one of the

principal drivers for the evolution to Lte .

In the context of deploying VoLte, a lot of

emphasis has been placed on the realization

of an IP Multimedia subsystem (IMs) and its

associated session Initiation Protocol (sIP) in

a wireless environment . Undeniably, IMs and

sIP are key to deploying VoIP services such as

VoLte in Lte networks .

It is IMs that provides the interconnect and gateway functionalities that allow VoIP

devices to communicate with non-VoIP devices or even non-wireless devices . sIP

defines the signaling necessary for call establishment, tear-down, authentication,

registration and presence maintenance, as well as providing for supplementary services

like three-way calling and call waiting .

without sIP signaling, or at least a proprietary equivalent, it would not be possible to

provide VoIP telephony services . without IMs or its equivalent, VoIP services would be

limited to establishing calls between two VoIP users on the same network, and would

not allow calls to users on parallel or legacy technologies . therefore, it is no wonder

that recent User equipment (Ue) testing and measurement has focused on two areas:

• the Ue’s ability to establish and maintain connectivity with an IMs network, including all of the registration, authentication, security and mobility associated with this connectivity

• the Ue’s conformance to sIP signaling protocol and sIP procedures/call flows, including any number of extensions that may be used in different deployment scenarios

corresponding literature

wHIte PaPeR

IMs architecture: the Lte User

equipment Perspective

RefeRenCe GUIDe

IMs Procedures and Protocols: the Lte User

equipment Perspective

PosteRs

Lte and the Mobile Internet

IMs/VoLte Reference Guide

http://www.spirent.com/White-Papers/Mobile/LTE_User_Equipment_Perspective

http://www.spirent.com/White-Papers/Mobile/~/~/~/link.aspx?_id=7642C427E76C4541A607CB5603D24806&_z=z

http://www.spirent.com/White-Papers/Mobile/~/~/~/~/link.aspx?_id=4F6A81287BDF4C4FB00382CA97485D7F&_z=z

http://www.spirent.com/White-Papers/Mobile/~/~/~/~/link.aspx?_id=5DCCB9B719D741B4AB0C8B947672FEAD&_z=z

sPIRent wHIte PaPeR • 2


Voice over LTE

Objective: To deliver “carrier-grade” (or “telco-grade”) voice services that are perceived by subscribers to be as good as, if not better than, legacy circuit-switched voice services.

However, to focus development and testing only on these two areas would overlook

the most significant goal of VoLte: to delivery “carrier-grade” (or “telco-grade”) voice

services that are perceived by subscribers to be as good as, if not better than, legacy

circuit-switched voice services . this concept fundamentally differentiates VoLte from

other VoIP services . Deploying IMs and sIP will provide VoIP service in an Lte network,

but VoLte raises the bar to provide the “carrier-grade” voice service that is the vital

objective of Lte networks and operators .

ensuring “carrier-grade” voice requires the marriage of IMs and sIP with a number of

Lte Radio access network (Ran) features . It is this combination of IMs, sIP and Ran

features that ultimately provides the “carrier-grade” VoLte experience . the remainder

of this white paper will identify this set of Ran features and how each of these features

improves the quality of VoLte service .



DeDICateD BeaReRs

one might ask why any of the many existing VoIP clients could not be installed on an

Lte Ue and used to provide carrier-grade voice services . the answer is competition for

resources . as we all know, over-the-air bandwidth is a finite and precious commodity,

even with the increased spectral efficiency offered by Lte . we also know that the

number of applications using IP data and the total amount of data bandwidth these

applications consume continues to grow at an exponential rate . each of these

applications and their associated data must compete for that finite bandwidth .

from a network’s perspective, the encoded voice packets generated by an off-the-shelf

VoIP client are notionally indistinguishable from the data traffic associated with an

email download, viewing a Youtube video, web browsing, or any number of a host of

other applications . the network will attempt to multiplex all of this “generic” packet

data traffic, not only from a single user but from all users, onto a single shared channel .

In Lte, these channels are the Physical Downlink and Physical Uplink shared Channels

(PDsCH/PUsCH) . Residing in these physical channels will be at least one evolved

Packet system (ePs) bearer . the ePs bearer provides a logical connection between the

Ue and a Public Data network (PDn) Gateway (PDn-Gw) . typically, a Default ePs Bearer

will be established to provide a logical connection between the Ue and an Internet

PDn-Gw for the purpose of delivering this generic data traffic between the Ue and one

or more application servers (e .g . web server) .

one downside of the Default ePs Bearer is that there is no control over quality of

service . a “best effort” strategy is used to deliver all of the generic traffic between the

Ue and the Internet PDn . when the finite resources of the network are overwhelmed,

data traffic queuing takes place, leading to unforeseeable latency or dropped packets .

this is obviously undesirable, or even unacceptable, for real-time applications such as a

voice call .

Dedicated Bearers

Benefit: Dedicated Bearers allow VoLTE audio traffic to be separated from all other traffic and delivered with a higher QoS level



to overcome the best effort delivery of all indistinguishable traffic over a single ePs

Default Bearer, Lte introduces the concept of an ePs Dedicated Bearer . a Dedicated

Bearer allows certain types of data traffic to be isolated from all other traffic (for

example, VoIP traffic from ftP file download) . each Dedicated Bearer (there can be

multiple Dedicated Bearers establishing virtual connections to one or more PDn-Gws)

is associated with a traffic flow template (tft) . a tft defines which traffic, based

on source/destination IP addresses and tCP/UDP ports, should be delivered on a

particular Dedicated Bearer . typically for VoLte, after sIP signaling is used to establish

a voice session and negotiate the session parameters (e .g . which audio codec, bit rate,

transport protocols and ports will be used for audio), an ePs Dedicated Bearer between

the Ue and an IMs PDn-Gw is established for the express purpose of transporting

encoded voice packets . Refer to figure 1 for an example of the traffic usage of a Default

Bearer vs . a Dedicated Bearer .

further, each Dedicated Bearer can have different service quality attributes specified .

In Lte, a combination of Resource type (Guaranteed Bit Rate vs . non-Guaranteed Bit

Rate), Packet Delay Budget (the maximum acceptable end-to-end delay between the

Ue and the PDn-Gw), Priority (which can be dropped when network resources become

scarce) and Packet error Loss Rate (the maximum acceptable rate of IP packets that are

not successfully received by the PDCP layer) are used to define a set of Qos (Quality of

service) Class Identifier (QCI) levels, refer to table 1 .

Figure 1: EPS Bearer: Default vs. Dedicated



table 2 provides a definition of standardized QCI values . a Dedicated Bearer

established to carry VoLte traffic may typically be assigned a QCI value of ‘1’, indicating

a guaranteed bit rate (largely consistent with the fairly predictable output of a vocoder),

a maximum end-to-end latency of 100ms and a maximum tolerance 10-2 for IP packet

loss . traffic on a Dedicated Bearer with QCI=1 would be prioritized over all “best

effort” traffic on the Default Bearer .

as other applications are deployed in the future, multiple dedicated bearers may be

used, each with a different QCI value . for example, a video telephony implementation

may choose to transport audio using a Dedicated Bearer with QCI=1 and place video on

a different Dedicated Bearer with QCI=2 . this would indicate that both audio and video

should be prioritized over best effort traffic . It also indicates that audio traffic is more

important to deliver with lower latency (100ms packet delay budget vs . 150ms) while

video traffic is more sensitive to packet errors (10-3 packet error loss rate vs . 10-2) .

QCIResource

Type PriorityPacket Delay Budget (ms)

Packet Error Loss Rate Example Services

1 GBR 2 100 10 -2 Conversational Voice

2 GBR 4 150 10 -3 Conversational Video (live streaming)

3 GBR 5 300 10 -6 non-conversational video (buffered streaming)

4 GBR 3 50 10 -3 Real-time gaming

5 non-GBR 1 100 10 -6 IMs signalling

6 non-GBR 7 100 10 -3 Voice, Video (live streaming), interactive gaming

7 non-GBR 6 300 10 -6 Video (buffered streaming)

8 non-GBR 8 300 10 -6 tCP-based (www, email, ftP)

9 non-GBR 9 300 10 -6

Table 2 – Standardized QCI Values

attributes for Qos class identifier (Qci)

Attribute Description

Resource type Guaranteed Bit Rate vs . non-Guaranteed Bit Rate

Packet Delay Budget Maximum acceptable end-to-end delay between the Ue and the PDn-Gw

Packet error Loss RateMaximum acceptable rate of IP packets that are not successfully received by the PDCP layer

allocation Retention PriorityValue assigned for scheduling when capacity is reached, with “1” being highest level

Table 1: QoS Class Identifier for LTE



seMI-PeRsIstent sCHeDULInG

as mentioned above, shared channels (PDsCH/PUsCH) are used at the physical

layer to transport the data carried by the logical bearers . since these channels are

shared amongst all of the users on an enodeB, there must be a way to allocate these

channels to avoid multiple users trying to simultaneously use the same resource . In

the frequency domain an Lte carrier is divided into a number of subcarriers (currently

anywhere from six to one hundred depending on the bandwidth of the Lte carrier) . In

the time domain each subcarrier is grouped into 0 .5ms time slots during which either

six or seven of ofDM symbols can be delivered, depending on whether the system is

using normal or extended cyclic prefixes (inter-symbol guard periods) . see the 3GPP’s

ts 36 .211 document for details . this results in a time-frequency grid of subcarriers and

time slots (refer to figure 2) . a grouping of twelve subcarriers in one time slot duration

is known as a Resource Block (RB) . an RB is

the minimum allocation of the Lte physical

layer resource that can be granted to a Ue .

a pair of physical control channels is used to

grant RBs to Ues operating on the network .

the Ue uses the Physical Uplink Control

Channel (PUCCH) to request allocation of the

PUsCH, and the Ue is granted both uplink and

downlink allocations via the Physical Downlink

Control Channel (PDCCH) . the PDCCH

identifies which subframes (a subframe is

two slots) a Ue should decode on the PDsCH,

and which Ues are allowed to transmit in each

uplink subframe on the PUsCH .

since every RB on the downlink and uplink

must be granted, VoLte introduces a

challenge: granting control channel overhead

becomes too great for the necessary persistent

and near continuous allocation of RBs to

deliver the relatively small packets typical of a

VoIP-based conversation . Figure 2: LTE Physical Layer Resource Block



semi-Persistent scheduling (sPs) was introduced to minimize granting overhead

for applications such as VoLte . sPs takes advantage of the fairly consistent and

predictable transmission pattern of VoLte packets (e .g ., a VoLte implementation might

typically be sending an encoded voice packet every 20ms) to make a persistent grant

of uplink and downlink RBs rather than scheduling each uplink and download RB

individually . a persistent grant removes the need to make a separate grant for each

20ms of encoded audio . a Radio Resource Control (RRC) message is used to establish

the periodicity of the recurring RB grant . the green boxes in figure 3 illustrate the sPs-

scheduled RBs for a VoLte call . as shown by the orange box in figure 3, additional RBs

can be dynamically scheduled for data traffic while sPs is enacted (e .g . enable a web

page download while on a VoLte call) .

one potential downside of sPs could occur in situations where there is silence during a

VoLte conversation . If the sPs grant is maintained during silent periods, physical layer

resources are wasted . that is why sPs is “semi-persistent”; when it makes sense, an

sPs grant can be cancelled . If the Ue does not transmit audio packets over a number of

network-defined transmission opportunities, the uplink grant will implicitly expire . on

the downlink, the network has the option of using an RRC message to cancel the grant .

thus the right balance can be struck between reducing control channel overhead and

maximizing efficiency in the use of shared data channels .

Figure 3: Semi-Persistent Scheduling

Semi-Persistent Scheduling

Benefit: SPS greatly reduces the overhead associated with scheduling small and periodic VoLTE audio packets, thus reducing processing overhead and providing more bandwidth to accommodate additional users



RoBUst HeaDeR CoMPRessIon

typical VoLte calls consist of relatively small encoded audio packets being transmitted

every 20ms . In fact, the size of the encoded data is smaller than the headers for the

protocols that are used to transport the encoded data . Real-time transport Protocol

(RtP) is a standardized packet format used for media streams such as VoLte audio . the

User Datagram Protocol (UDP) then provides a transport-layer mechanism for the RtP

stream between two Internet Protocol (IP) endpoints . In the case of VoLte, this would

be between the IMs voice client in the Ue and a Media Gateway in the IMs core . finally,

an IP layer is used to establish network interworking . In the case of IPv6, which is

typically used for VoLte deployments, the combination of RtP, UDP and IP headers can

be around 40 to 60 bytes long .

to reduce the size of headers used to deliver VoLte audio, Robust Header Compression

(RoHC) is employed . RoHC is used over the air interface to conserve the precious

bandwidth of the radio access network (refer to figure 4 .) RoHC takes advantages of

the redundancy of some headers in various protocol layers, as well as the redundancy

of information contained in the headers of subsequent packets in the same audio

stream, to greatly reduce the size of the header overhead . the 40 to 60 bytes of header

length can be reduced to as little as 3 to 4 bytes . with RoHC enabled, a VoLte encoded

audio transmission using the wideband-aMR codec is reduced from around 75 bytes to

around 35 bytes .

Figure 4: RoHC Compression and Decompression at the UE and eNodeB



It should be noted that there are actually multiple usage profiles defined for RoHC:

• Profile 0: Uncompressed – Packets that cannot be compressed with the following profiles

• Profile 1: RtP – Compress packets using IP/UDP/RtP protocol headers

• Profile 2: UDP – Compress packets using IP/UDP protocol headers

• Profile 3: esP – Compress packets using IP/esP protocol headers

• Profile 4: IP – Compress packets using IP protocol headers

• Profile 7: RtP/UDP-Lite/IP – Compress packets using RtP/UDP-Lite/IP protocol headers

• Profile 8: UDP-Lite/IP – Compress packets using UDP-Lite/IP protocol headers

the above example of VoLte transmission compression ratios assumed the use of RoHC

Profile 1 .

Robust Header Compression

Benefit: RoHC can achieve a nearly 50% reduction in the size of VoLTE audio transmissions, thus decreasing bandwidth needed for any single call and increasing the overall number of users on an eNodeB site



DIsContInUoUs ReCePtIon

Packet-based voice services such as VoLte encode periods of audio conversation

(VoLte is typically 20ms periods) and then rapidly burst-transmit the encoded period of

audio to the receiver for decoding and playback over the 20ms period . when viewing

over-the-air transmissions, it is apparent that each encoded audio packet transmission

is followed by a period of no transmission .

Discontinuous Reception (DRX) takes advantage of these silent periods to turn off the

Rf receiver of the Ue, as well as other entities such as a/D converters and digital signal

processors associated with downlink demodulation . this reduces the drain on the

device’s battery and increases talk and standby usage time . RRC messaging is used to

enable DRX and establish the Ue receiver’s on/off pattern .

Given that the network established the DRX pattern, it will know when the Ue is

monitoring the PDCCH and know when to schedule downlink data to the Ue . selection

of the DRX pattern must carefully be determined based on the latency requirements of

the application and the need to receive any possible retransmissions . Having too long

of a “sleep” period may lead to latency greater than the desired performance based on

the QCI value in use . Refer to figure 5 for an illustration of a DRX pattern .

Figure 5: DRX Pattern



DRX can also operate in one of two different modes: Long DRX and short DRX . Long

DRX has the Ue receiver disabled for a longer period of time, and could be applicable

during periods of silence in the conversation when audio packets are sent less

frequently . However, when audio is consistently present, short DRX can be used and a

cycle can be mapped to the periodic arrival of audio packets . switching between Long

DRX and short DRX is controlled by the enodeB’s MaC Layer and/or an activity timer at

the Ue . Refer to figure 6 for an illustration of Long and short DRX .

Figure 6: Long and Short DRX

Discontinuous Reception

Benefit: DRX helps save the UE’s battery life during a VoLTE call by allowing the UE to turn off its receiver in between reception of audio packets



tRansMIssIon tIMe InteRVaL BUnDLInG

Lte introduces a shorter transmission time Interval (ttI) than was offered in previous

cellular technologies . specifically, a 1ms subframe is defined as the ttI . since

resource scheduling is done for each ttI, a smaller ttI facilitates low over-the-air

latency for real-time applications . VoLte is an example of an application that benefits

from this short 1ms ttI .

However, the short ttI does lead to uplink issues in select scenarios, most notably at

the edges of enodeB coverage . when an enodeB detects that a Ue is at a cell edge

where reception is deteriorating and the Ue cannot increase its transmit power, the

enodeB can initiate ttI bundling via RRC messaging . In essence, this means the Ue

will increase the error detection and correction associated with each data transmission

by transmitting over multiple ttIs (for example, bundling four consecutive ttIs) . with

this enhanced error detection and correction, overall latency is less than when using a

single ttI .

figure 7 shows how ttI bundling helps deliver lower-latency VoLte data at cell edges,

where data errors are expected . Rather than wait for the HaRQ process (normal HaRQ

interlace period is 8ms) to ask for a retransmission of data with new error detection/

correction bits, ttI bundling assumes that data will need to be retransmitted . In

ttI bundling a number of data packets are pre-emptively packed into a single HaRQ

interlace period . each packet contains the same source data coded with 4 different sets

of error detection/correction bits . also, HaRQ retransmission adds HaRQ aCK/naCK

overhead that ttI bundling does not .

Transmission Time Interval Bundling

Benefit: TTI Bundling increases the uplink efficiency at cell edges by using multiple bundled TTIs to transmit increased error detection and correction data

Figure 7: Effect of TTI bundling on latency



Lte VoICe anD LeGaCY VoICe seRVICes

while IMs-based VoLte, deployed with the Ran features mentioned above, will provide

a high-quality voice experience when a user is in Lte coverage, consideration must also

be given to these same users when not in Lte coverage or when leaving Lte coverage .

this is especially important given that most initial Lte deployments will not be as

ubiquitous as the underlying 3G coverage . this will certainly lead to situations in

which a Ue on an active VoLte call will need to transition that call to a legacy network

as the Ue roams out of Lte coverage .

In early deployments of Lte, there are two general approaches to handling scenarios

when the Ue moves out of Lte coverage: single radio solutions such as Circuit-switched

fallBack (CsfB) and dual radio solutions such as simultaneous Voice-and-Lte (sVLte) .

with either interim approach, voice traffic is being handled by the legacy circuit-

switched networks and they are not, at the root, Lte solutions .

a second phase in Lte voice evolution introduces VoLte and utilizes a single radio

solution that seamlessly maintains voice service as the Ue moves in and out of areas

with Lte coverage . this involves completing a seamless handover from VoLte to

legacy circuit-switched voice technology . often referred to as single Radio Voice Call

Continuity (sRVCC), this allows a Ue, at the proper time and with the proper direction

from the network, to handover and retune from Lte to a legacy GsM or UMts network

(or even a 1X network in the case of legacy 3GPP2) and simultaneously transition

the audio stream from VoLte packet-switched delivery to GsM/UMts (or 1X) circuit-

switched delivery . this provides for a cost-effective Ue (a single radio design is used)

that can perform voice services in the most efficient manner (VoLte when in Lte

coverage; circuit-switched otherwise) and deliver a positive user experience (calls are

maintained even when the Ue moves out of Lte coverage) . Refer to figure 8 for an

illustration of a network topology supporting sRVCC .

Single Radio Voice Call Continuity

Benefit: SRVCC provides for a quality user experience by maintaining voice calls when VoLTE becomes unavailable due to loss of LTE coverage



this is not without complications, however . Implementation of sRVCC must take into

account that the network and the Ue are trying to accomplish at least three non-trivial

tasks in near simultaneous fashion while minimizing any disruption to the real-time

voice call that is in progress:

• the Ue must retune to a new frequency (and most likely retune to a new band) as it switches from Lte to the legacy network

• the Ue must acquire and begin transmitting on the legacy network

• Both the network and the Ue must transition from delivering audio packets via a packet-switched solution to a circuit-switched delivery

as a result of this complexity, commercial deployment of sRVCC is not expected until

2013 at the earliest .

ConsIDeRatIons foR Lte Ue DeVeLoPeRs

every one of the Ran and mobility features mentioned above is not only needed to

make carrier-grade VoLte deployments a reality, it also requires implementation

within the Ue to complete deployment, presenting a new level of complexity in Ue

development and testing . Ue engineers will need virtually unlimited configurability

of IMs procedures and sIP signaling to verify the incorporation of Ran features in the

Ue and the management of mobility scenarios and handovers that will occur between

Lte and 3G technologies . for each of the Ran features described in this paper, some

considerations for Ue developers are listed below . although not exhaustive, this list is

meant to provide a broad view of the complexity involved in Ue development in pursuit

of carrier-grade VoLte .

Figure 8: SRVCC in an LTE + UMTS deployment



dedicated Bearers:

at the end of the sIP negotiation to start a VoLte call, the evolved Packet Core (ePC)

of the network will initiate the Dedicated ePs Bearer Context activation Procedure

to establish the bearer for the audio traffic . the Ue must be able to complete this

procedure and use the Dedicated Bearer .

sps:

the Ue must be able to support RRC messaging specifying periodicity of recurring RB

grant; sPs-Config Information element is described in detail in the 3GPP’s ts 36 .331

document . the Ue will also need to manage switching on/off sPs based on Data

Quality (QCI) and traffic . sPs behavior is defined in 36 .321 .

roHc:

the Ue must be able to support compression and decompression of header information

for different traffic types: UDP, RtP, IP as defined in the Ietf’s RfC 4995 (for RtP & UDP)

and RfC 4996 (for tCP/IP) .

drx:

the Ue must have ability to switch between long and short DRx in response to all the

relevant timers (as defined in ts 36 .321) .

tti Bundling:

the Ue must be able to transmit over multi ttI and receive, per ts 36 .321 . note that

while many discussions of ttI bundling treat the bundle size as an arbitrary even

number, ts 36 .321 defines ttI_BUnDLe_sIZe as 4 .

srVcc:

the Ue must be able to complete the Lte to legacy network handover as well as change

its audio traffic from packet-switched to circuit-switched .

iMs network emulation:

support of all necessary functionality for successful VoLte deployment requires a

network emulation test solution that provides complete integration of IMs infrastructure

emulation, a fully implemented and configurable ePC and a programmable enodeB

implementation . further, the network emulation solution requires incorporation

of multiple radio access technologies (Lte plus wCDMa/GsM) along with the tight

coupling of the ePC to generate and coordinate the mobility scenarios necessary to

verify the Ue’s sRVCC implementation .



sUMMaRY

IMs and sIP are necessary technologies for deployment of VoIP in an Lte environment,

but it is ultimately the introduction of Lte Ran features that creates the differentiation

between VoLte and VoIP . specifically;

• Dedicated Bearers allow for the prioritization of VoLte audio packets over all other best-effort traffic

• semi-Persistent scheduling reduces the complexity and overhead of the continuous allocation of downlink and uplink physical layer resource blocks to transport the audio traffic

• Robust Header Compression reduces the bandwidth associated with the headers used to transport relatively small encoded audio packets

• Discontinuous Reception helps conserve battery life of the Ue during a VoLte call

• transmission time Interval Bundling overcomes the limitation of using short (1ms) ttIs at cell boundaries

• sRVCC provides the mechanism to maintain an active voice call as a Ue moves from Lte coverage to legacy networks

while much focus has been placed in testing a Ue’s IMs connectivity and sIP signaling

conformance, ultimate success of carrier-grade VoLte deployments will depend on fully

integrated testing of a Ue’s signaling along with the negotiation, establishment and

usage of the associated Ran features mentioned above .

as discussed in this paper, carrier-grade VoLte presents unique technical challenges

and considerations for the Ue engineer . spirent is a global leader in Lte device testing

and is well positioned to assist in addressing the challenges and test requirements

early on in the development cycle . spirent’s Cs8 Device tester provides all of the

components necessary to support development and testing of a Ue’s VoLte capability

during the research and development phases of the Ue lifecycle .

this white paper is the third in a series of tools aimed to educate and support Ue

developers as they contribute to the deployment of IMs/VoLte . Please see spirent

website (www .spirent .com) for other free white papers, recorded seminars, posters and

other resources that may be helpful to the Ue developer .

volte depl oyment and the radio acc ess net work/media/white...

Documents