Sie sind auf Seite 1von 183

2

Validating VoLTE
Preface
VoLTE: Better Voice, More Profitable Data
The writing is on the wall for the traditional mobile service business model. Revenues from
voice services, the industrys bread and butter for decades, comprise a smaller percentage
of the total each year. Data traffic continues to explode, taxing networks without fully
offsetting losses on the voice side.
Also, the ability of mobile operators to capitalize on the rising popularity of smartphones,
tablets, video, and Rich Communications Services (RCS) is compromised by over the top
providers. OTT players piggy-back VoIP, messaging, chat, and location services on top of
operators networks, often for free.
ARCChart predicts that by 2016 the installed base of OTT mobile VoIP subscribers alone will
exceed 500 million.
1
Skype and GoogleTalk have nearly a billion registered users worldwide.
By offering increased functionality at little to no cost, these services raise user tolerance for
lower-grade performance while serving to relegate multi-million-dollar networks to providing
the pipes.
Needless to say, mobile operators worldwide have gone on the offensive. Many have
embarked on aggressive, innovative strategies to:
Protect their share of diminishing voice revenues
Improve the economics of service delivery and average revenue per user (ARPU)
Profit from the growth of data by fast-tracking their own compelling new services
VoLTE stands to protect existing revenues while reducing opex and staunching the flow of
revenues to OTT playersif providers can guarantee quality. Needless to say, the road is
long, with many more decisions and challenges looming large.
Validating VoLTE: A Lab to Live Challenge
As they roll out VoLTE services, mobile operators need new ways of ensuring maximum
quality and high ROI. Both can be accomplished by validating designs and performance in the
lab, before and after deployment. From early on in the planning and prototype stages through
the day-to-day monitoring of live production networks, life-cycle strategies are now needed
to achieve predictable service delivery and optimize visibility.
1 ARCChart Voice over LTE: market analysis and forecasts, April 2012
3
Validating VoLTE
Why Read This Book?
To extract the needed benefits from investments in VoLTE, and LTE in general, operators need
to get deployments right the first time. To that end, this book presents a step-by-step guide
for validating VoLTE implementations cost-effectively in the lab prior to deployment.
This includes evaluating:
Device and network performance
Interoperability
Quality of Service and Quality of Experience
Network visibility and monitoring
Before embarking on the 40+ detailed test procedures contained in the Test Case section,
lets begin by taking a closer look at the current state of VoLTE, operator deployment plans,
and the elements needed to optimize deployments.
About Ixia
The most trusted names in networking trust Ixia solutions
to optimize equipment, networks, services, and applications.
We help deliver innovative, differentiated offerings, improve
management and visibility, and ensure a high-quality,
always-on user experience.
Leading mobile operators worldwide use Ixias award-
winning LTE solutions to accelerate and optimize 4G
deployments and speed new services to market. A
comprehensive suite of products and services are used to
test, assess, and optimize key technology initiatives:
Network performance, compliance, and security
Visibility into applications and services that
accelerates troubleshooting and enhances
monitoring performance
Securing mission-critical networks and services against attack
Cloud /virtualization and data center initiatives
For more information about Ixia, visit www.ixiacom.com. Also check out our groundbreaking
new book, Small Cells, Big Challenge: A Definitive Guide to Designing and Deploying HetNets.
4
Validating VoLTE
TABLE OF CONTENTS
CHAPTER 1
VoLTE Market Drivers and Benefits .................................................................................. 9
Protecting Voice Revenues........................................................................................... 9
Monetizing Quality ................................................................................................... 10
Improving the Economics of Service Delivery ............................................................ 11
Increased Spectrum Efficiency ................................................................................... 11
Improved Battery Life .................................................................................................. 11
Fast-Tracking Profitable New Services .................................................................... 12
More than Just Voice ................................................................................................. 12
Faster Call Setup .........................................................................................................13
The Appeal of Convenience .........................................................................................13
Improving Existing Voice Quality ................................................................................13
Operator Deployment Plans: How Much, How Soon? .................................................13
CHAPTER 2
What is VoLTE? 15
Circuit Switched Fallback (CSFB) .............................................................................15
Importance of QoS and Policy Control to Enable VoLTE ............................................ 16
CHAPTER 3
Challenges To Deploying VoLTE .......................................................................................19
Validating New Devices and Configurations ...............................................................19
Interoperability in Increasingly Multi-vendor Environments .................................... 20
Signaling .................................................................................................................... 20
Fallback ..................................................................................................................... 21
Ensuring Quality of Experience (QoE) ....................................................................... 21
Impact on value-added services ................................................................................ 21
Stress / Scalability ..................................................................................................... 22
CHAPTER 4
Validating VoLTE Lab to Live ...................................................................................... 25
Critical Test Capabilities ............................................................................................. 26
Realism / Traffic Generation ...................................................................................... 26
Subscriber Modeling .................................................................................................. 27
Load Testing ............................................................................................................... 28
QoS / Service Validation ............................................................................................ 28
Live Network Monitoring ............................................................................................ 28
Scope of Testing ......................................................................................................... 29
5
Validating VoLTE
CHAPTER 5
VoLTE Test Configurations ...............................................................................................31
Test Configuration: VoLTE Client End to End Across the Network ............................ 32
Test Configuration: UE/eNodeB Emulation
Across the VoLTE Network ............................................................................. 33
Test Configuration: IMS Isolation ............................................................................... 34
Test Configuration: eNodeB Isolation ......................................................................... 35
Test Configuration: EPC Isolation ............................................................................... 36
CHAPTER 6
VoLTE Test Cases: Overview ........................................................................................... 39
Test Case Format .......................................................................................................40
CHAPTER 7
Section 1: VoLTE Setup ................................................................................................... 43
LTE Attach Call Flow .................................................................................................. 43
IMS Registration Call Flow ......................................................................................... 44
Test Case 1: IMS Registration ..................................................................................... 45
Test Case 2: IMS Registration with IMS AKA ............................................................ 47
Test Case 3: SIP Subscribe Procedure ...................................................................... 49
Test Case 4: SIP De-Registration on UE Power Down ...............................................51
Test Case 5: SIP De-Registration on Network Release ............................................. 52
CHAPTER 8
Section 2: VoLTE Voice-Only Call ................................................................................... 55
Measuring Quality of Voice ........................................................................................ 55
Test Case 6: VoLTE Voice-Only Call with Wideband AMR ........................................ 59
Test Case 7: VoLTE Call Release Initiated by the Calling Party .................................. 62
Test Case 8: VoLTE Call Release Initiated by the Called Party ................................... 63
Test Case 9: Redirect VoLTE Call to Voice Mail after Called Party is Busy ............... 64
Test Case 10: Redirect VoLTE Call Not Answered to Voice Mail ................................ 66
Test Case 11: Originator Cancels the Call Before Ringing ......................................... 68
Test Case 12: Originator Cancels Call after Ringing ................................................. 70
Test Case 13: Loss of PDN Connectivity .................................................................... 72
Test Case 14: Loss of SIP Signaling ........................................................................... 74
Test Case 15: Loss of Media Bearer .......................................................................... 76
Test Case 16: Voice Call Waiting, Second-Party Hold ................................................ 78
Test Case 17: Voice Call Switch Hold ..........................................................................81
Test Case 18: Voice Third Call Redirect to Voice Mail ............................................... 84
Test Case 19: Handover During VoLTE Voice-Only Call ............................................. 86
Test Case 20: DTMF Tone Handling ........................................................................... 88
6
Validating VoLTE
Test Case 21: VoLTE Emergency Registration ............................................................91
Test Case 22: VoLTE Emergency Call ........................................................................ 92
CHAPTER 9
Section 3: VoLTE SMS ..................................................................................................... 95
Test Case 23: VoLTE Send SMS ................................................................................. 96
CHAPTER 10
Section 4: VoLTE Video and Voice Call ........................................................................... 99
Test Case 24: VoLTE IR.94 Registration with IMS
AKA Authentication ...................................................................................... 102
Test Case 25: VoLTE 2-Way Video Call with 2-Way Audio ..................................... 103
Test Case 26: VoLTE Video Call Originator Terminates ........................................... 105
Test Case 27: VoLTE Video Call, Called Party Terminates ....................................... 107
Test Case 28: Change of Video Parameters ............................................................. 109
Test Case 29: Video Call a User Stops Video ........................................................ 111
Test Case 30: Video Third Call Redirect to Voice Mail on Ignore ............................. 113
Test Case 31: Video Call Accepted as Voice Only ..................................................... 115
Test Case 32: Voice Call Transition to Video Call Accepted ..................................... 117
Test Case 33: Voice Call Transition to Video Call Ignored/
Time-out .................................................................................................................... 119
Test Case 34: Voice Call Transition to Video Call Rejected ...................................... 121
Test Case 35: Handover During VoLTE Video Call ................................................... 123
Test Case 36: Video Call Put on Hold ...................................................................... 125
Test Case 37: Video Call Switch Hold ...................................................................... 128
Test Case 38: Video Third Call Redirect to Voice Mail .............................................. 131
CHAPTER 11
Section 5: Advanced VoLTE Testing .............................................................................. 135
Test Case 39: Voice Ad-Hoc Multi-Party Conference .............................................. 136
Test Case 40: Video Ad-Hoc Multi-Party Conference ............................................. 140
Test Case 41: Multitasking + Video Call ................................................................... 144
Test Case 42: VoLTE Video Load Scenario .............................................................. 146
CHAPTER 12
Section 6: Real-World VoLTE Subscriber Modeling .......................................................149
Test Case 43: Airbus A380 Landing ........................................................................ 150
Test Case 44: Power Outage Restored ..................................................................... 151
Test Case 45: High-Density Financial District ......................................................... 152
Test Case 46: Rush Hour Commuter Traffic .............................................................153
Test Case 47: Large University ................................................................................ 154
7
Validating VoLTE
CHAPTER 13
Monitoring Challenges, Solutions, and Best Practices ...................................................157
CHAPTER 14
Best Practices for Monitoring VoLTE in EPCs ...............................................................163
Key Performance Indicators for Monitoring VoLTE .................................................. 165
CHAPTER 15
Ixia VoLTE Test Solutions ...............................................................................................169
IxLoad Access ...........................................................................................................170
IxLoad ....................................................................................................................... 171
Key Features ............................................................................................................. 171
Wireless Triple-Play Bundle ....................................................................................173
Xcellon-Ultra NP Load Module .................................................................................. 174
Key Features ............................................................................................................. 174
XAir Module ...............................................................................................................175
Key Features .............................................................................................................175
r10 Wideband Radio Head .........................................................................................176
Key Features .............................................................................................................176
High-Performance Chassis .......................................................................................177
Key Features .............................................................................................................178
Ixia Hardware Configuration for VoLTE Testing .............................................................179
One-Sector Configuration .........................................................................................179
Three-Sector Configuration ......................................................................................179
Six-Sector Configuration ......................................................................................... 180
References ................................................................................................................... 182
Chapter 1
VoLTE Market Drivers and Benets
9
Chapter 1: VoLTE Market Drivers and Benefits
Validating VoLTE
CHAPTER 1
VoLTE Market Drivers and Benefits
Operators can leverage VoLTE to:
Protect critical voice revenues from attrition
Improve the economics and efficiency of service delivery (including leveraging LTEs
improved spectral efficiency to re-farm 2G/3G resources)
Fast-track compelling new services
Maximize quality while simultaneously delivering HD voice alongside data
Lets take a closer look.
Protecting Voice Revenues
According to Informa Research & Telecoms, voice accounted for $634 billion in mobile
service revenues in 2013, more than 60% of the worldwide total. As data traffic continues to
surge, voice revenues will continue to suffer attritionInforma estimates a drop of roughly
9% by 2018but theyll still represent a massive global market of $579B.
1,400
1,200
1,000
800
600
400
200
0
2013 2018
634
Voice Data
385
579
675
Source: Informa Telecoms & Media
10 Chapter 1: VoLTE Market Drivers and Benefits
Validating VoLTE
VoLTE helps protect voice revenues now and into the future by delivering higher-quality,
HD voice, faster call setup times, and other advantages. More importantly, VoLTE positions
operators to guarantee quality in order to prevent losses to OTT services.
Monetizing Quality
VoLTE becomes one of first services to fully leverage the end-to-end quality of service (QoS)
capabilities built into IMS-based LTE networks. Operators can marketand monetizethis
advantage by making deals with OTT providers seeking to differentiate on quality, and by
rolling out their own premium services to generate new revenues.
By fully leveraging IMS and the QoS mechanisms
inherent in LTE, VoLTE supports HD voice as well as
services based on guaranteed quality. The question
is: how much will customers pay for it?
Services like Skype, Facebook, WhatsApp, and Fring
have proven wildly popular, introducing functionality
and novelty at virtually no cost. But history has
shown that users will pay for real-time services like
GoToMeeting and Microsoft Lync to ensure higher
quality and security. Business customers in particular
still shy away from any free or low-cost service that
delivers a less than satisfactory experience, and may
be inclined to pay a premium to bolster their own
customer service.
To offset revenue loss to OTT services, operators
have two viable options for monetizing quality: 1) they
can partner with or sell to OTT provider seeking differentiation, or 2) launch compelling paid
services that let customers do something more, better, or cheaper. OTT providers that cant
guarantee service quality on their own may do well to pay to leverage it.
Either way, VoLTE figures to leave mobile operators at a clear advantageif they can deliver
a superior QoE.
HD voice could bring
landline call quality to
cell phones and could be
offered as a premium
service to those tired
of repeating what they
think they heard on the
other end of the line.
Lars Johnsson, senior
director of product marketing for
mobile LTE platforms at Broadcom
11
Chapter 1: VoLTE Market Drivers and Benefits
Validating VoLTE
Improving the Economics of Service Delivery
By basically allowing voice and data services to be delivered over a single network via a
single radio interface, LTE offers unique advantages for improving the economics of service
infrastructures.
Increased Spectrum Efficiency
Voice calls also consume less bandwidth on LTE
than they do on legacy networks so that the same
spectrum can be used to deliver nearly twice as
many calls with VoLTE than using 3G services. And
obviously, migrating a fair percentage of voice load
off of 2G/3G networks onto LTE frees up existing
bandwidth. The migration to VoLTE in turn allows
2G/3G spectrum to be reused for LTE.
LTE may also pave the way for operators to avail
themselves of a wider range of spectral frequencies.
Typically handled in the 1850-2150MHz, bands, voice
might be able to migrate to 850MHz or use higher
bands above 2150MHz.
Ultimately, better use of spectrum makes for better
quality, which in turn leads to higher subscriber
satisfaction and retention.
Improved Battery Life
LTE promises to improve device battery life, some say as much as 40%. According to
Broadcom, the biggest benefit of VoLTE calls may be that they put far less drain on a phones
battery than 3G voice calls. The positive net impact of LTE on battery life performance is
becoming widely acknowledged since devices dont have to maintain contact with two distinct
networks to run voice and data applications.
There is a technical case
to be made for a mass
movement to VoLTE. The
technology would make
roaming easier, alleviate
concerns with spectrum,
and leverage backhaul.
VoLTE is easier on the
battery life of phones
compared to 3G.
Mind Commerce
12 Chapter 1: VoLTE Market Drivers and Benefits
Validating VoLTE
Fast-Tracking Profitable New Services
VoLTE unlocks the future of profitable voice. Mobile operators can leverage LTE and RCS to
develop innovative new services and offer attractive service bundles and rate plans.
To date, nearly 200 LTE deployments have gone live, supporting some 160 million
subscriptions. Early deployments have been predominately data-only, and some providers
have deployed without using IMS.
The exclusion of voice is likely to change, however, as LTE rapidly gains traction in North
America, Asia Pacific, and other regions throughout the world. Operators migrating voice to
4G networks can increasingly benefit from the technological and economic advantages of
LTE and IMS to improve quality and profitability.
45%
40%
35%
30%
25%
20%
15%
10%
5%
0%
K
o
r
e
a
J
a
p
a
n
U
S
A
S
i
n
g
a
p
o
r
e
A
u
s
t
r
a
l
i
a
C
a
n
a
d
a
S
w
e
d
e
n
S
a
u
d
i

A
r
a
b
i
a
U
K
G
e
r
m
a
n
y
R
u
s
s
i
a
Source: Informa Telecoms & Media
LTE to mobile subscribers penetration, Jun-13
More than Just Voice
By leveraging the superior QoS capabilities inherent in IMS and LTE, operators are free to
roll out a wide variety of innovative and compelling new services. Coupling VoLTE with Rich
Communications Services (RCS) supports real-time video chat and messaging.
While the availability of convenient, feature-rich applications and services from their trusted
service provider may appeal to customers in and of itself, the real selling point once again is
likely to be the higher quality network operators can provide.
13
Chapter 1: VoLTE Market Drivers and Benefits
Validating VoLTE
Faster Call Setup
VoLTE delivers sub-second call setup times, a major improvement upon 3G call setups taking
approximately 3 seconds. True VoLTE also significantly improves upon interim LTE solutions
using CSFB where the latency resulting from handoffs to circuit-switched networks result in
setup times exceeding 4 seconds.
The Appeal of Convenience
VoLTE-based services also have the advantage of not requiring either or both parties
to download specific clients or applications. Nor are customers limited to calling other
subscribers on one providers network.
Improving Existing Voice Quality
For a time, the evolution of voice traffic to LTE may even improve the quality of voice calls
over 3G. With more bandwidth available, operators have more flexibility to prioritize services
to enhance the quality of voice calls without significantly compromising the performance of
data applications.
While the benefits of rolling out VoLTE are clear and compelling, the challenges are many and
formidable.
Operator Deployment Plans: How Much, How Soon?
Informa Telecoms & Media predicts that 2014 will be the breakthrough year for voice over
LTE (VoLTE). Other estimates expect steadily accelerating deployments through 2018.
North America VoLTE Subcribers, VoLTE Revenue and VoLTE POP
Revenues US ($M) Subscribers and POP in Thousands, 2013-2018
2013 2014 2015 2016 2017 2018 CAGR
2014-2018
VoLTE
Subscribers
13 300 4,250 13,250 38,300 71,250 293%
VoLTE Revenues
(US $M)
$2 $29 $467 $2,199 $7,140 $15,595 383%
VoLTE POP 300 30,000 120,000 210,000 300,00 350,000 85%
Source: MindCommerce
Lets take a look at whats involved in getting there.
Chapter 2
What is VoLTE?
15
Chapter 2: What is VoLTE?
Validating VoLTE
CHAPTER 2
What is VoLTE?
Voice-over-LTE, VoLTE, leverages the multimedia telephony (MMTel) service, the standardized
IMS-based (IP Multimedia System) VoIP service designed to replace existing circuit-switched
voice. By implementing the GSMA VoLTE IR.92 specification based on global 3GPP standards,
mobile operators can deliver a new conversation experience of enriched voice, enlivened
video, and intuitive messaging.
While migrating voice to an all-IP packetized infrastructure, VoLTE unlocks richer
conversation services and lays a foundation for operators to offer toll-grade quality using
well-defined quality of service (QoS) mechanisms. Rich Communications Services (RCS),
marketed under joyn by GSMA, complement VoLTE by defining:
Enhanced phonebook service capabilities and contact information such as presence
and service discovery
Enhanced messaging enabling a variety of options including chat, emoticons,
location share, and file sharing
Enriched calls featuring multimedia content-sharing during voice calls, video calls,
and video sharing
After years of debate over alternative technology proposals, VoLTE has emerged as the
hands-on favorite for supporting new rich-media services with broad industry support from
both the vendor and operator communities. Initial launches and trials began in 2012 and will
ramp aggressively during the next five years.
Circuit Switched Fallback (CSFB)
Until we get to VoLTE, initial LTE deployments are focused on data applications with circuit-
switched fallback used to deliver interim voice services for LTE subscribers. With CSFB,
an incoming or outgoing voice call forces a radio fallback from LTE to the legacy 2G or 3G
service. Any 4G data is stopped at this point, limiting voice and texting to slower legacy 3G
mobile services.
CSFB will primarily use narrowband codecs, and not the AMR-WB (Adaptive Multi-Rate
Wideband) used for HD audio. Additionally, it will not enable all-IP services such as video
calls.
16 Chapter 2: What is VoLTE?
Validating VoLTE
Importance of QoS and Policy Control to Enable VoLTE
By nature, cellular systems are constrained by finite radio spectrum and transport resources.
Voice, video, and other rich media applications each have unique traffic-handling and QoE
requirements such that resource issues cannot economically be solved the old way, by
simply over-provisioning the network.
For VoLTE rollouts to succeed in delivering superior QoE, efficient partitioning of wireless
network resources is needed. End-to-end QoS is essential. LTE networks must be able
to identify and treat service flows with well-known QoS characteristics for latency, jitter,
packet loss, and error rates. The network must deliver guaranteed QoS end-to-end from the
user equipment (phone or tablet) all the way to external TDM-based networks.
Advanced policy and charging control (PCC) is a major advancement in LTE networks
compared to previous wireless generations. PCC allows operators to adopt fair-use policies
limiting subscriber service abuse for example, bandwidth hogs such as file sharingand
helping to maintain network performance during peak traffic times.
Policy management, the process of applying operator-defined rules for resource allocation
and network usage, plays a fundamental role in implementing QoS in mobile broadband by
enabling efficient allocation of network resources. Policy enforcement, in turn, involves
service data flow detection and applies QoS rules to individual service data flows.
Since different services have varying QoS requirements in terms of packet delay tolerance,
acceptable packet loss rates, and required minimum bit rates, granular control of service
quality is critical. As such, QoS and policy management are essential to differentiated
services and related challenges.
17
Chapter 2: What is VoLTE?
Validating VoLTE
Chapter 3
Challenges To Deploying VoLTE
19
Chapter 3: Challenges To Deploying VoLTE
Validating VoLTE
CHAPTER 3
Challenges To Deploying VoLTE
The flipside of being able to deliver voice and data over one network is that those networks
must now be optimized for both voice and data. Delivering high-quality voice is more
challenging, and doing so in the form of data packets even more so.
Aside from the sheer novelty of this undertaking, VoLTE involves lots of new moving pieces,
unproven technologies, and interdependencies. Major challenges to ensuring successful
deployments out of the gate include:
Validating New Devices and Configurations
By 2016, ARCChart expects the installed base of VoLTE-enabled handsets to top 74 million.
Such devices are already available in Korea and other countries leading adoption. Informa
expects to see many more devices available in many more countries by the end of 2014, and
all of these new devices need to be evaluated for performance, interoperability, and reliability.
At the network level, some operators have counted as many as sixty distinct network
components that come into play for a VoLTE call to be completed. Some of these are LTE-
specific devices, others are non-3GPP components like application servers, DNS, and
firewalls.
Along with the obvious interoperability challenges, subsystems like firewalls and DNS can
become bottlenecks. Devices, subsystems and end-to-end service infrastructures must be
validated thoroughly to keep costly issues from occurring upon deployment.
20 Chapter 3: Challenges To Deploying VoLTE
Validating VoLTE
Interoperability in Increasingly Multi-vendor Environments
With so many more components in play, many more vendors are in play as well. Many of
the interfaces involved in VoLTE are also prone to customization by vendors, including
critical Diameter protocols used in the EPC core, and Session Initiation Protocol (SIP)
implementations within IMS.
The traditional model of relying upon one or even a handful of trusted vendors to validate
performance becomes unwieldy and impractical. Mobile network operators must directly take
control of ensuring interoperability, scalability, and the ultimate end-user experience.
Nor is each provider evaluating their own networks sufficient. Interoperability validation must
further extend to effecting seamless roaming, and billing, between multiple operators.
Signaling
Spikes in hard-to-predict signaling traffic are already occurring due to smartphones
generating up to 20x the signaling traffic of traditional phones. Signaling volumes may
actually overwhelm infrastructures, leading to costly and embarrassing outages.
VoLTE is expected to significantly increase the amount of signaling traffic in the network. To
help handle the load, Diameter routing agents (DRA) are deployed in the EPC core to provide
intelligent switching and mediation between different devices and networks. DRAs handle
load balancing, and play a vital role in scalability.
This approach changes the traditional topology, adding, essentially, a single point of failure.
Though redundant DRAs are usually deployed, the function itself represents a highly
centralized processing point. If, for example, policy server queries could not be completed,
voice calls would be stopped in their tracks.
Operators must be assured that DRAs will perform as expected. Devices and configurations
must be evaluated for interoperability, failovers, and performance under realistic stress and
overload conditions.
21
Chapter 3: Challenges To Deploying VoLTE
Validating VoLTE
Fallback
VoLTE is not a forklift upgrade; its a whole new deal. Until every mobile phone in use
supports it, operators will need to support legacy air-links and provide seamless fallback to
2G/3G networks where LTE is unavailable.
For the foreseeable future, VoLTE calls will leverage CSFB and Single Radio Voice Call
Continuity (SRVCC) to move from packetized networks to circuit-switched infrastructures.
These techniques may involve extra signaling to the core network and SRVCC servers via
IMS. The impact of the extra steps on performance, capacity, scalability, security, and QoE
must be measured.
Aside from the actual handovers, operators need to coordinate and integrate billing systems,
monitoring, and backhaul between both infrastructures and across all protocols. They must
also maintain the continuity of mandated services such as CALEA and Lawful intercept.
Ensuring Quality of Experience (QoE)
For VoLTE to be worth the formidable investment, it not only has to deliver better quality than
what OTT players provide, but exceed what 2G/3G networks deliver as well. Early indicators
point to lower latencies and faster connection speeds, but operators may need to back these
claims with hard data in order to satisfy businesses and savvy consumers.
Impact on value-added services
What impact will increased complexity have on features like Call Waiting, forwarding,
voicemail, and conferencing? In migrating voice to LTE, operators need to be sure
subscribers satisfaction with the features theyve come to rely on wont be compromised.
22 Chapter 3: Challenges To Deploying VoLTE
Validating VoLTE
Stress / Scalability
Does voice get prioritized effectively as the network become stressed? Where are the new
bottlenecks and congestion points? What happens when failovers occur?
QoS and reliability must be assessed under realistic load and high-stress conditions to
ensure satisfaction and bring high-risk surprises to light before they do damage.
23
Chapter 3: Challenges To Deploying VoLTE
Validating VoLTE
Chapter 4
Validating VoLTE Lab to Live
25
Chapter 4: Validating VoLTE Lab to Live
Validating VoLTE
CHAPTER 4
Validating VoLTE Lab to Live
To date, service providers worldwide have relied heavily upon equipment manufacturers to
validate the performance both of their own devices and overall network designs. Today, in
the face of steadily rising traffic volumes and expectations for quality, this approach is far too
risky.
Most operators networks increasingly consist of equipment from multiple vendors.
And obviously, each network is unique such that operators need to test their specific
configurations, services, and traffic mixes to find potential issues and bottlenecks. Having the
flexibility to quickly roll out new services or charging plans without going back to the vendor
every time the network changes proves a valuable advantage over time.
With so many new and moving pieces involved, ensuring a high-quality VoLTE rollout requires
end-to-end validation that begins in the lab and continues into the live network. Life-cycle
validation strategies are needed, and should include:
Design, planning and device selection. Throughout design, operators need an
efficient means of evaluating prospective devices and proposed network designs.
Prototyping services. Before going
live, new services should be modeled
and tested against realistic scenarios,
including high-stress conditions, at
scale.
Visibility monitoring. Once things get up
and running, operators need to maintain
visibility into the network, making sure
that the tools and solutions used to
monitor and optimize performance and
security are functioning optimally. This
includes making sure each tool receives
the data it needs automatically and
efficiently. Ultimately, operators want
to have easy access to a networks KPIs.
Problem resolution. Whether issues arise in the field or in the data center, operators
must be able to take actionable data back to the test lab to devise ideal solutions.
Visibility solutions gather data on KPIs and traffic patterns that can be used to inform
testing in the lab that quickly replicates and resolves issues.
Throughout the process, the ultimate quality of voice, video, and other applications and
services must be assessed, not with a focus on protocol testing, but on measuring the quality
of the end-user experience with voice, video, messaging, and the other services.
A botched VoLTE would not
only compromise customers
satisfaction and loyalty, but have
larger implications as well since
first responders the healthcare
industry, local, state and
federal government, as well as
businesses all rely upon cellular
voice.
IGR
26 Chapter 4: Validating VoLTE Lab to Live
Validating VoLTE
Critical Test Capabilities
VoLTE testing should focus on end-to-end service validation versus individual device (node)
testing. Network operators do not need to duplicate their vendors development testing, but
rather measure the expected user experience.
To do this effectively, testing must be performed with all the components that will be used
in the live network. Since maintaining a lab-based replica of the entire live network is
not practical or cost-effective, purpose-built test systems can be used much more cost-
effectively.
These systems must be able to subject devices and configurations to high-stress, high-
scale conditions. In general, a VoLTE test system must support functional, performance, and
stability testing of SIP-based VoIP network components as well as a wide mix of voice, video,
and data applications.
Using an automated, repeatable, and proven approach enables operators to assess the impact
of each decision they make on device and network performance, as well as the ultimate
quality of experience delivered. Validation strategies and test methodologies should include
several critical components and capabilities:
Realism / Traffic Generation
Its common for equipment manufacturers to state performance metrics in terms of specific
or best case configurations and use models. Operators rolling out VoLTE need more
realistic assessments based on actual or intended network configurations.
Test systems must be able to provide high-rate emulation of video, voice over IP (VoIP),
VoLTE, data, and peer-to-peer protocols and application traffic. Performance, scalability, and
capacity should all be benchmarked under realistic traffic conditions. Operators must be
able to assess the subscriber experience in the face of mobility, system overload, and even
device failure on a large-city scale. This includes simulating peak conditions, power outages,
security threats, and other unforeseeable events.
For VoLTE, end-to-end test coverage encompasses everything from the wireless base
stations to the Internet core. Operators need to be able to evaluate the entire LTE/VoLTE
network as a whole, and also isolate individual subsystems such as the RAN, EPC, and the
IMS core. Test tools must support SIP, SDP, H.323, MGCP, H.248, SKINNY, and RTP/RTCP
protocols with voice codecs, in addition to video and data/web protocols.
27
Chapter 4: Validating VoLTE Lab to Live
Validating VoLTE
Test solutions must also be capable of testing a variety of network components in LTE and
IMS topologies, including:
SIP proxies and registrar servers
Media gateways
Call agents
Session border controllers (SBCs) and application-layer gateways
Application servers
EUTRAN components (eNodeB)
EPC components (S-GW, P-GW, MME, HSS, PCRF)
IMS components (x-CSCF)
Important traffic emulation and SIP test functionalities include the ability to:
Simulate SIP endpoints behind one or many SIP proxies
Simulate SIP proxy and SIP registrar server
Maintain full control over SIP state machines, messages, and contents
Create any test case, including negative testing
Subscriber Modeling
An extension of the realism needed to validate new services is the ability for operators to
define subscriber types (residential, corporate, SMB, etc.) complete with the correlating
application profiles. By modeling the use and mobility patterns of actual subscribers, testers
gain accurate insight into network capacity and the QoE achieved for each rich media or
differentiated service.
28 Chapter 4: Validating VoLTE Lab to Live
Validating VoLTE
Load Testing
Since most issues occur at high scale, operators cant qualify performance, scalability,
and resiliency just by using a handful of actual client devices as has been done in the past.
Realistic traffic must be generated at realistic scale to simulate high-load or stress conditions
where network and application performance might suffer.
This means modeling peak usage and varying times throughout the day, simultaneously
generating data, voice, and video protocols to emulate the respective multimedia traffic loads.
QoS / Service Validation
As noted earlier, policy management will play an increasingly integral role in enabling new
services such as VoLTE as well as new business models to emerge. Operators must be able
to assess and implement policies on multiple devices simultaneously, measuring the QoS
capabilities of each along with the end-to-end performance achievable across the overall
network.
Live Network Monitoring
LTE/VoLTE solutions require large, complex networks with many moving parts. Even with
extensive planning and lab testing, the final network may bog down under load, or as a result
of a failure.
For example, a software upgrade to one component in a chain might result in an
incompatibility with neighboring components. Network monitoring allows issues to be
identified before they become serious problems, and to troubleshoot any problems that might
occur.
29
Chapter 4: Validating VoLTE Lab to Live
Validating VoLTE
General Requirements on Network-based VoLTE Measurements
1
Requirement Explanation
Complete Monitoring of
Network VoLTE traffic
24/7 Monitoring of every data flow with regard to SIP
signaling and Voice Media
Network Visibility Ability to filter KPI results with regard to mobile network
elements (APNs, gateways, eNodeBs, Cells, P-CSCFs)
Device Visibility Ability to filter KPI results with regard to the Individual
Device and Device Models
Subscriber Visibility Ability to filter KPI results with regard to the Individual
subscriber
Near Real Time Availability of results 10 minutes after capturing from
network traffic
Scope of Testing
The comprehensive benchmarking needed to optimize VoLTE deployments includes:
Functional / feature testing
Interoperability testing
Capacity planning
QoS and policy control assessment
QoE measurement
Ongoing validation to maximize value throughout the service life-cycle.
So lets take a look at some real-world test cases, then at the challenges and best practices
for ongoing network monitoring and visibility.
1 Velocent Systems, VoLTE KPIs for Network-based Monitoring, 2013
Chapter 5
VoLTE Test Congurations
31
Chapter 5: VoLTE Test Configurations
Validating VoLTE
CHAPTER 5
VoLTE Test Configurations
To ensure a reliable VoLTE service, testing must occur under a variety of VoLTE test
configurations. Operators will test end-to-end from the UE to the external networks; they
will also need to isolate a sub-system, such as the EPC, to understand its scalability or to
isolate a network problem. Generally, product development teams are more concerned with
testing individual components like an eNodeB, whereas system test groups need to look at
the network more holistically.
Common test configurations include:
1. End-to-end system test. In this scenario the test tool must emulate UEs with SIP
agents over the Uu interface (RF), generating voice and SMS traffic into the LTE
eNodeB. On the other side of the network under test, the tool emulates land-based
SIP user agents or the PSTN.
2. Isolation of the evolved packet core (EPC). In this configuration the test tool
supports the emulation of millions of mobile subscribers and hundreds of eNodeBs
generating voice and SMS traffic directly into the EPC. On the other side of the
network, the entire core network is emulated by replicating the behavior of the Proxy
Call Session Control Function P-CSCF and all other devices behind it.
3. Isolation of the combined EPC and IMS core. In this scenario mobile subscribers
and eNodeBs are emulated on one side and land-based SIP user agents are emulated
on the other.
The following VoLTE test cases can be run from a number of points within the LTE network.
To ensure full functionality, it is important that full end-to-end tests (VoLTE client to VoLTE
client) are performed. This will validate that all network elements are operating correctly
across the VoLTE network. It is possible and preferable in certain cases to test under
different configurations. These are considered below.
32 Chapter 5: VoLTE Test Configurations
Validating VoLTE
Test Configuration: VoLTE Client End to End Across the Network
This configuration represents the deployed network, with UEs connecting end to end across
the network. Testing under this scenario involves Ixia emulation (indicated in diagrams using
yellow highlights) of the LTE UEs and possibly SIP/PSTN clients or additional core servers
e.g., web/video servers available through the Internet Access Point Name APN, all other
elements are real.
The Test Case section is written with this configuration.
33
Chapter 5: VoLTE Test Configurations
Validating VoLTE
Test Configuration: UE/eNodeB Emulation Across the
VoLTE Network
This configuration brings in the emulation of the eNodeB (eNodeB) with the UE. The eNodeB,
with its air interface operation and scheduling challenges, can often be the key element of
impairment. This test configuration allows direct validation that the rest of the wired network
is operating correctly.
This configuration is also useful for testing VoLTE load in the network, by allowing much
greater loading of the EPC and IMS than is possible solely through UE emulation. Each
eNodeB is limited to less than a Gbps of traffic, whereas the LTE EPC can handle tens to
hundreds of gigabits per second (Gbps) of traffic, along with the IMS and MME servers that
can handle thousands of signaling transactions per second.
34 Chapter 5: VoLTE Test Configurations
Validating VoLTE
Test Configuration: IMS Isolation
This configuration involves emulation of the PCRF directly to the IMS core. This will validate
the signaling functionality and also can validate the expect IMS load capacity.
35
Chapter 5: VoLTE Test Configurations
Validating VoLTE
Test Configuration: eNodeB Isolation
While the eNodeB does not directly process the IMS (SIP) signaling used for VoLTE, it is the
element most likely to introduce impairment of VoLTE operation from achieving high signal
quality. Ensuring fast and effective eNodeB operation is essential to VoLTE operation.
The eNodeB has strong challenges in scheduling the UEs for their Uplink (UL) and Downlink
(DL) transmissions. By its nature, a VoLTE stream has small voice packets with small inter-
arrival times. eNodeB functionality like Semi-Persistent Scheduling, TTI Bundling, and Robust
Header Compression RoHC are all designed to assist VoLTE operation, but add complexity
that must be examined. By testing an eNodeB in isolation, additional focus can be applied to
validating this functionality.

36 Chapter 5: VoLTE Test Configurations
Validating VoLTE
Test Configuration: EPC Isolation
Isolating the EPC with emulation of the UE/eNodeBs and IMS network allows focused
investigation of issues that may be affecting VoLTE operation from within the EPC.
37
Chapter 5: VoLTE Test Configurations
Validating VoLTE
Chapter 6
VoLTE Test Cases: Overview
39
Chapter 6: VoLTE Test Cases: Overview
Validating VoLTE
CHAPTER 6
VoLTE Test Cases: Overview
The following sections propose a set of VoLTE test cases that ensure correct operation
across a VoLTE network. These test cases are approached from the perspective of a full
end-to-end VoLTE test across the network from UE to UE. This is the first test configuration
illustrated in the Test Configuration section. All other Test Configurations can be used to run
these scenarios.
The test cases can be divided into the following sections:
Section 1: Setup/Registration
Section 2: Voice
Section 3: SMS
Section 4: Video
Section 5: Advanced
Section 6: Subscriber Modeling
40 Chapter 6: VoLTE Test Cases: Overview
Validating VoLTE
Test Case Format
Each of the test cases presented will follow the following format.
Test Case Number: Title
Title describes the key scenario of the test (e.g. VoLTE voice-only call)
Description
Scenario overview
Diagram that shows the critical network elements and positive results for the test
case
UE1 is the default for result pass criteria if another UE is not identified
Initial State
Numbered pretest configuration details
May include earlier test scenarios denoted by number
Test Steps
Numbered bullets of each test step in the call flow
Messages can be shown in a different font with key parameters identified:
SIP REGISTER FROM:<PhoneNumber>@ims P:ASSERTED_ID
Cell_ID
Results
Numbered checks to be met to pass the test case
41
Chapter 6: VoLTE Test Cases: Overview
Validating VoLTE
Chapter 7
Section 1: VoLTE Setup
43
Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
CHAPTER 7
Section 1: VoLTE Setup
LTE Attach Call Flow
Before a VoLTE test scenario can be run, it is assumed that the UE has gone through the
Attach process. This handles the underlying LTE-based signaling and configuration before the
VoLTE (IMS) signaling is started.
The following diagram shows the call flow.
2. Attach Request
3. Attach Request
4. Update Location Request
6. Update Location Ack (IMS APN, QCI 5)
7. Create Session Request (IMS APN, QCI 5)
8. CCR (Initial, IMS APN, QCI 5)
9. CCA (PCC Rules for default bearer)
10. Create Session Response (IMS APN, QCI 5, UE IP address, PCSCF address
11. Initial Context Setup Request / Attach accept (IMS APN, QCI5, UE IP address, PCSCF address
12. RRC Connection Reconfiguration / Attach Accept (IMS APN, QCI5, UE IP address, PCSCF address
13. RRC Connection Reconfiguration Complete
14. Initial Context Setup Response
15. Direct Transfer (Attach Complete)
16. UL NAS Transport (Attach Complete)
17. Modify Bearer Request
18. Modify Bearer Response
Uplink data
Downlink data
eNodeB MME S/PGW
1. RRC Setup
SPR query
CSFB registration
4. Authentication
HSS PCRF SPR
44 Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
IMS Registration Call Flow
The UE must register with the IMS network. This allows its presence to be updated.
This call flow looks like this:
ICSCF HSS
(SM1) Register
(SM2) Register
(SM3) Register
(CM1) AVReq
(CM2) AVReqResp
(SM4) 4xx Auth_Challenge
(SM5) 4xx Auth_Challenge
(SM6) 4xx Auth_Challenge
(SM7) Register
CxSelectionInfo
CxPut
CxPut
CxPull
CxQuery
(SM8) Register
(SM9) Register
(SM10) 2xx Auth_Ok
(SM11) 2xx Auth_Ok
(SM12) 2xx Auth_Ok
UE PCSCF SCSCF
45
Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Test Case 1: IMS Registration
Description
A UE will register with the IMS to allow VoLTE services using MD5 Digest Authentication.

Initial State
1. UE is EPS attached and has the default bearer activated for VoLTE APN
Test Steps
1. UE sends a REGISTER message to home network (to S-CSCF via P-CSCF and
I-CSCF) to perform SIP registration with a public user identity:
REGISTER FROM:<PhoneNumber>@ims P:ASSERTED_ID Cell_ID
2. UE receives SIP 401 Unauthorized response from the IMS core (P-CSCF):
401 Challenge Random challenge (RAND)
3. UE sends a second REGISTER with calculated response (RES) based on a shared
secret and previously received RAND
4. UE receives a SIP 200 OK response from the S-CSCF routed back via all the CSCFs
46 Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Results
1. UE successfully receives 401 with Random Challenge (RAND)
2. UE successfully receives SIP 200 OK
47
Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Test Case 2: IMS Registration with IMS AKA
Description
A UE will register with the IMS to allow VoLTE services using IMS AKA authentication.
Initial State
1. UE is EPS attached and has the default bearer activated for VoLTE APN
Test Steps
1. UE sends a REGISTER message to home network (to S-CSCF via P-CSCF and
I-CSCF) to perform SIP registration with a public user identity:
REGISTER FROM:<PhoneNumber>@ims P:ASSERTED_ID Cell_ID
2. UE receives SIP 401 Unauthorized response from the IMS core (P-CSCF):
401 Challenge
Random challenge (RAND) Network authentication token (AUTN)
Authentication scheme (IMS authentication and key agreement AKA)
3. UE sends a 2nd REGISTER with calculated response (RES) based on a shared secret
and previously received RAND
4. UE receives a SIP 200 OK response from the S-CSCF routed back via all the CSCFs
48 Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Results
1. UE successfully receives 401 with Random Challenge (RAND) and AKA fields
2. UE successfully receives SIP 200 OK
49
Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Test Case 3: SIP Subscribe Procedure
Description
A UE subscribes for an Event of Notification from the IMS network. Event notifications are
used in services including automatic callback services (based on terminal state events),
buddy lists (based on user presence events), message waiting indications (based on mailbox
state change events), and PSTN and Internet Interworking status (based on call state events).
Initial State
1. UE is EPS attached and has the default bearer activated for VoLTE APN
2. UE has successfully Registered to the IMS network
Test Steps
1. UE initiates Subscribe indicating Event subscription:
SIP SUBSCRIBE (REG-EVENT) (Event: reg), new Dialog
2. UE receives 200 OK indicating subscription has been accepted and containing
Expires header field to indicate the actual duration for which the subscription will
remain active (unless refreshed)
3. UE receives SIP NOTIFY(REG-EVENT), sends 200 OK
50 Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Results
1. UE receives 200 OK in response to SUBSCRIBE
2. UE receives SIP NOTIFY(REG-EVENT)
51
Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Test Case 4: SIP De-Registration on UE Power Down
Description
A Registered UE powers down and causes de-registration from the IMS network.

Initial State
1. UE is EPS attached and has the default bearer activated for VoLTE APN
2. UE is Registered with the IMS network and is in Idle or Connected state
Test Steps
1. UE is powered down causing a de-registration, by sending a REGISTER request to
the S-CSCF with expiry time set to 0:

REGISTER Expiry Time:0
2. The S-CSCF clears all temporary information it has for UE and updates the HSS
3. UE receives a 200 OK response from the S-CSCF
Results
1. UE successfully receives 200 OK to deregister
52 Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Test Case 5: SIP De-Registration on Network Release
Description
A Registered UE is released from the Network. This can happen for various reasons
(reported stolen, unpaid bills, administrative reasons).
Initial State
1. UE is EPS attached and has the default bearer activated for VoLTE APN
2. UE is Registered with the IMS network and is in Idle or Connected state
Test Steps
1. S-CSCF sends a NOTIFY message with registration-state information to UE:
NOTIFY Deactivated Event
2. UE sends a 200 OK back to S-CSCF to acknowledge de-registration
Results
1. UE successfully receives Notify Deactivated Event
53
Chapter 7: Section 1: VoLTE Setup
Validating VoLTE
Chapter 8
Section 2: VoLTE Voice-Only Call
55
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
CHAPTER 8
Section 2: VoLTE Voice-Only Call
This section provides test cases that focus on IR.92 Voice calls only. VoLTE through dedicated
bearers provides the quality difference to VoIP over the top traffic.
PCSCF SCSCF AS ICSCF SCSCF AS PCSCF
Kristinas home network Jennifers home network
Dedicated bearer
(QC11) established
Ringing
User
Answers
Dedicated bearer
(QC11) established
HSS
UPDATE
INVITE
100 Trying
PRACK
200 (OK)
200 (OK)
180 (Ringing)
200 (OK)
ACK
183
INVITE
100 Trying
183
PRACK
200 (OK)
UPDATE
200 (OK)
180 (Ringing)
200 (OK)
ACK
INVITE
INVITE
183
PRACK
PRACK
200 (OK)
UPDATE
UPDATE
200 (OK)
180 (Ringing)
200 (OK)
ACK
ACK
100 Trying
183
200 (OK)
180 (Ringing)
INVITE
100 Trying
183
200 (OK)
200 (OK)
180 (Ringing)
200 (OK)
INVITE
INVITE
183
LIR
LIA
PRACK
PRACK
200 (OK)
UPDATE
UPDATE
200 (OK)
200 (OK)
180 (Ringing)
ACK
ACK
100 Trying
183
200 (OK)
200 (OK)
180 (Ringing)
200 (OK)
ACK
INVITE
183
200 (OK)
UPDATE
200 (OK)
180 (Ringing)
200 (OK)
PRACK
Measuring Quality of Voice
Speech quality in a telephony system is a subjective judgment that depends on technical
attributes of the system and the participants speaking and listening preferences. A mean
opinion score (MOS) provides a numerical indication of the quality of transmission, in the
range of 1 to 5 (see table).
56 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Mean Opinion Score
MOS Quality
5 Excellent
4 Good
3 Fair
2 Poor
1 Bad
There are 2 types of MOS algorithms:
1. Perceptual/Subjective (POLQA and PESQ)
Perceptual Objective Listening Quality Analysis
Perceptual Objective Listening Quality Analysis (POLQA) is the voice quality
testing standard for fixed, mobile, and IP-based networks that was adopted as
ITU-T Recommendation P.863 and successor to P.862/PESQ. POLQA provides
strong support for testing of new wideband 4G/LTE networks delivering HD-
quality voice services. POLQA is particularly important for measuring QoE of
wideband HD voice mobile calls in the 7 kHz and 14 kHz frequency range.

The POLQA perceptual measurement algorithm is the joint development of
OPTICOM, SwissQual, and TNO.
Perceptual Evaluation of Speech Quality
Perceptual evaluation of speech quality (PESQ) is a mechanism that measures
the quality of speech in the automated way as defined by ITU-T standard
P.862. PESQ is an objective measurement method that predicts the results
of subjective listening tests. The PESQ algorithm produces results analogs
with the subjective MOS standard. A mapping between PESQ results and MOS
was defined after the release of the P.862 recommendation. PESQ-LQ (PESQ-
listening quality) is defined in ITU-T Rec. P.862.1, and improves the correlation
with subjective test results at the high and low ends of the scale. It is important
to measure both values: PESQ-LQ and PESQ-LE (listening effort).

PESQ is a full-reference method designed for end-to-end quality of voice
assessment using a psycho-acoustic and cognitive model. PESQ analyzes the
degraded audio signal (the signal after passing through the communication
system) versus the reference (the signal injected in the system). The method
requires access to actual audio information in both reference and degraded
signals, performs level and time alignment to accommodate attenuations and
delays, process the disturbances and finally applies the cognitive model. This
is done using signal processing algorithms requiring considerable processing
power.




57
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
The ITU-T P.800 specification defines methods for subjective determination of
transmission quality. These methods use a large number of human subjects who
listen to sentences read aloud by professional male and female speakers and
transmitted over the telephony system. The listeners rate the quality of the individual
audio signals, which are averaged into a MOS score.
2. Network Packet Transmission Based (E-Model and R-Factor)
In packet networks, quality of voice measurements can be performed by assessing
the packets transmission using the E-Model and then generating the metric R-Factor.
As defined by ITU-T G.107, R-Factor combines a number of values measuring the
effect of various impairments; some of these are:
The effect of coding/decoding defined as constants for every codec
Jitter, packet loss, and delay
The effect of audio signal capture (mouth to microphone) and reproduction
(speaker to ear), defined as a constant
The E-Model does not require reference signal information as it does not look at the actual
audio content of the degraded signal. This method requires far less processing power than
PESQ.
The R-Factor method predicts a user satisfaction on a scale from 0 to 100, where 100 is the
highest satisfaction. A formula is defined for conversions between R-Factor and MOS. For
example, a perfect transmission with the codec G.711 has an R-Factor of 94 and a MOS of 4.4.
R-Factor
R-Factor User Satisfaction
91-100 Very satisfied
81-90 Satisfied
71-80 Some users dissatisfied
61-70 many users dissatisfied
51-60 Nearly all users dissatisfied
0-50 Not recommended
58 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
R-Factor and PESQ both characterize a voice transmission system; the former considers the
packet networks impairments, while the latter compares the received audio signal with the
expected signal. Beside the effect of the impairments of the transmission network, PESQ also
captures the effects of trans-coding, voice activity detector, echo cancelation, and any other
type of audio signal alteration.
Because the PESQ algorithm is computationally intensive, it is not practical to use it for
testing the speech quality on high-scale devices or systems. However, if E-Model is used
exclusively, some issues may remain hidden if the system performs audio signal processing.
The best practice is to combine the two methods by performing E-Model measurement on all
calls and PESQ on a smaller percentage of them.
59
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 6: VoLTE Voice-Only Call with Wideband AMR
Description
This test case details the fundamental VoLTE scenario of a user-to-user call using Wideband
AMR.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are subscribed with the IMS network and are available
Test Steps
1. UE
1
initiates the call by sending INVITE message to UE
2
:

INVITE SDP
a=rtpmap
99 AMR-WB/16000
2. UE
2
responds with 183 Session Progress
3. UE
1
sends PRACK for reliability of the provisional response
4. UE
2
sends 180 Ringing
5. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the voice codec to be used
60 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
6. SIP call is established, RTP streaming starts; Voice Dedicated Bearer is configured
at this stage
7. PCRF receives the 183 response and forwards it to UE
1
, but in addition sends a
Diameter AA Request (AAR) with session information from SDP (IPs, ports, media
and codecs, bandwidth)
8. PCRF creates policy rules based on the session information from AAR and sends the
Rx AA Answer (AAA) with a success value towards P-CSCF
9. PCRF also sends the created policy rule to P-GW using a diameter re-auth request
(RAR); P-GW uses this information to enforce QoS and to apply traffic policy for
voice media (PCEF)
10. P-GW also recognizes that is no bearer established for the provided QCI and ARP
pair so it initiates a new dedicated bearer creation using this QoS information; for
this P-GW sends Create Bearer Request to MME
11. MME allocates EPS bearer identity for this dedicated bearer and sends it together
with EPS bearer QoS and TFT info to the UE in a Session Management Request
inside the Bearer Setup Request to the eNodeB
12. eNodeB maps the EPS bearer QoS to the radio bearer QoS and sends a RRC
Connection Reconfiguration message to the UE; this RRC Reconfig contains also a
session management request sent by MME
13. UE stores the new bearer QoS settings and EPS bearer identity and uses the TFT
to identify voice traffic flow coming from the application layer and matches uplink
traffic to right radio bearer
14. After configuration, the UE returns the RRC Connection Reconfiguration Complete
message to the eNodeB
15. eNodeB acknowledges the bearer activation to the MME with a Bearer Setup
Response
16. MME acknowledges the bearer activation to the S/P-GW by sending a Create Bearer
Response with Success outcome
17. Moving from the default bearer to dedicated if QCI matched and MBR received in
Create Bearer Request is higher than configured value
18. Call is maintained for 3 minutes
19. UE
1
on hangup initiates a BYE
20. UE
2
responds with 200 OK
61
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Results
1. Successful SIP Signaling execution to complete the INVITE process; ACK is received
by UE
2
2. Successful initiation of the Voice stream, with correct properties, on a dedicated
bearer (QCI=1)
3. QoE assessment of MOS and PESQ for voice quality
MOS should have a value > 4.1 (Excellent)
62 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 7: VoLTE Call Release Initiated by the Calling Party
Description
In this scenario the VoLTE call release is initiated by the Calling party.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are subscribed with the IMS network and are involved in a bidirectional
voice call for the last 3 minutes, with UE1 being the call initiator
Test Steps
1. UE
1
sends a BYE that is propagated through IMS proxies to UE
2
2. UE
2
responds with 200 OK, which is propagated through the network to UE
1
Results
1. UE
2
receives BYE from his P-CSCF
2. UE
1
receives 200 OK from his P-CSCF
63
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 8: VoLTE Call Release Initiated by the Called Party
Description
In this scenario the VoLTE call release is initiated by the Called party.
v

Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are subscribed with the IMS network and are involved in a bidirectional
voice call for the last 3 minutes, with UE1 being the call initiator
Test Steps
1. UE
2
sends a BYE that is propagated through IMS proxies to UE
1
2. UE
1
responds with 200 OK, which is propagated through the network to UE
1
Results
1. UE
1
receives BYE from P-CSCF
2. UE
2
receives 200 OK from P-CSCF
64 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 9: Redirect VoLTE Call to Voice Mail after Called Party
is Busy
Description
This test explores a case where the called party rejects incoming call (BUSY scenario) and
the voice mail forwarding is triggered.
Initial State
1. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
initiates the call by sending INVITE message containing SDP with 2-way audio/
video info towards UE
2
via IMS network (P,I,S-CSCF proxies)
2. UE
2
responds with 180 Ringing without SDP, which is propagated back to UE
1
3. UE
2
sends 486 Busy Here response
4. Upon receiving 486 Busy Here message S-CSCF proxy on UE
2
side will forward it to
TAS (Telephony Application Services) module
5. TAS will trigger the Call Forwarding Procedure for UE
2

6. UE
1
receives UPDATE (with SDP offer) from S-CSCF
7. UE
1
responds with 200 OK UPDATE (with SDP answer) to S-CSCF
65
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
8. A voice prompt is played (RTP stream is sent from Voice Mail Server to UE
1
); after
the prompt, UE
1
can deposit his voice message to be delivered to UE
2
voice mail box
(RTP stream is sent from UE1 to Voice Mail Server)
9. After RTP streams for voice mail stop, UE
1
receives BYE from S-CSCF
Results
1. UE
2
sends 486 Busy Here
2. UE
1
receives UPDATE with SDP offer
3. UE
1
sends 200 OK UPDATE
66 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 10: Redirect VoLTE Call Not Answered to Voice Mail
Description
This test explores a case where the called party doesnt answer incoming call and forwarding
to voice mail is triggered.
Initial State
1. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
initiates the call by sending INVITE message containing SDP with 2-way audio
(a=sendrecv) info towards UE
2
via IMS network (P,I,S-CSCF proxies)
2. UE
2
responds with 180 Ringing with SDP, which is propagated back to UE
1
3. UE
2
does not answer the incoming call, as a result Call Forward No Answer timer
expires at TAS for UE
2
4. TAS sends CANCEL for the call to UE
2
through S-CSCF
5. UE
2
sends 200 OK to S-CSCF as response to CANCEL; S-CSCF forwards the 200
OK to TAS module
6. UE
2
sends 487 Request Terminated to S-CSCF; which forwards 487 to TAS module
7. TAS responds with an ACK, which is propagated through S-CSCF to UE
2
67
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
8. TAS triggers Call Forward procedure for Voice Mail
9. UE
1
receives 181 Call is Being Forwarded from S-CSCF
10. Voice Mail receives INVITE with SDP offer
11. Voice Mail responds with 180 Ringing and 200 OK (with SDP answer) to UE
1
via
S-CSCF
12. UE
1
sends ACK
13. A voice prompt is played (RTP stream is sent from Voice Mail Server to UE
1
); after
the prompt, UE
1
can deposit his voice message to be delivered to UE
2
Voice Mail
(RTP stream is sent from UE
1
to Voice Mail Server)
14. After RTP streams for voice mail are stopped, UE
1
receives BYE from S-CSCF
Results
1. UE
2
receives CANCEL
2. UE
2
sends 487 Request Terminated
3. UE
1
receives 181 Call is Being Forwarded
4. UE
1
receives 200 OK

68 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 11: Originator Cancels the Call Before Ringing
Description
This test case explores a VoLTE scenario where the originator changes his mind and cancels
the call before receiving 180 Ringing.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are subscribed with the IMS network and are available
Test Steps
1. UE
1
initiates the call by sending INVITE message to UE
2

2. UE
2
responds with 100 Trying
3. UE
1
sends CANCEL
4. UE
2
responds with 200 OK
5. UE
2
sends 487 Request Terminated
6. UE
1
sends ACK
69
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Results
1. UE
2
receives CANCEL
2. UE
1
receives 200 OK
3. UE
1
receives 487 Request Terminated

70 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 12: Originator Cancels Call after Ringing
Description
This test case explores a VoLTE scenario where the originator changes his mind and cancels
the call after receiving 180 Ringing.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are subscribed with the IMS network and are available
Test Steps
1. UE
1
initiates the call by sending INVITE message to UE
2
2. UE
2
responds with 100 Trying
3. UE
2
sends 180 Ringing
4. UE
1
sends CANCEL C_seq=1
5. UE
2
responds with 200 OK
6. UE
2
sends 487 Request Terminated
7. UE
1
sends ACK
71
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 12: Originator Cancels Call after Ringing
Description
This test case explores a VoLTE scenario where the originator changes his mind and cancels
the call after receiving 180 Ringing.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are subscribed with the IMS network and are available
Test Steps
1. UE
1
initiates the call by sending INVITE message to UE
2
2. UE
2
responds with 100 Trying
3. UE
2
sends 180 Ringing
4. UE
1
sends CANCEL C_seq=1
5. UE
2
responds with 200 OK
6. UE
2
sends 487 Request Terminated
7. UE
1
sends ACK
Results
1. UE
1
receives 180 Ringing
2. UE
2
receives CANCEL
3. UE
1
receives 200 OK
4. UE
1
receives 487 Request Terminated

72 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 13: Loss of PDN Connectivity
Description
In this Negative Test scenario, a call is re-established after PDN connectivity loss. This is an
implicit detach by the network.
Initial State
1. UE
1
and UE
2
are VoLTE Registered
2. UE
1
has initiated an ongoing voice call with UE
2
3. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
Test Steps
1. UE
1
loses PDN connectivity
2. UE
2
receives BYE request with 503 Service Unavailable response code:
BYE: Reason header
503 Service Unavailable
3. UE
1
re-establishes PDN connection by sending NAS Attach request + PDN
Connectivity request
4. After bearer configuration the UE returns the RRC Connection Reconfiguration
Complete message to the eNodeB
73
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
5. UE
1
sends REGISTER and completes the IMS Registration procedure
6. UE
1
re-initiates the call by sending INVITE message to UE
2
7. UE
2
responds with 183 Session In Progress
8. UE
1
sends PRACK for reliability
9. UE
2
sends 180 Ringing
10. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the voice codec to be used in this call
11. PGW initiates a new dedicated bearer, UE
1
receives RRC Connection Reconfiguration
12. SIP call is established, RTP streaming starts. Voice Dedicated Bearer is configured
at this stage
13. Call is maintained for 3 minutes
14. UE
1
on hangup initiates a BYE
15. UE
2
responds with 200 OK
Results
1. Successful PDN Re-Connection
2. Successful Call Re-establishment
3. UE
1
receives 183 Session In Progress

74 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 14: Loss of SIP Signaling
Description
In this Negative Test scenario, a call is re-established after a signaling bearer loss.
Initial State
1. UE
1
and UE
2
are VoLTE Registered
2. A voice call is established between UE
1
and UE
2
(UE1 initiated) and is ongoing for 1
minute
3. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
Test Steps
1. UE
1
loses SIP signaling
2. UE
2
receives BYE request with 503 Service Unavailable response code
3. BYE 503 Service Unavailable
4. PGW/network initiates a new dedicated bearer for SIP signaling, UE
1
receives RRC
Connection Reconfiguration
5. After bearer configuration the UE returns the RRC Connection Reconfiguration
Complete message to the eNodeB
6. UE1 sends REGISTER and completes the IMS Registration procedure. SIP signaling
uses dedicated bearer (QCI=5)
75
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
7. UE
1
re-initiates the call by sending INVITE message to UE2
8. UE
2
responds with 183 Session Progress
9. UE
1
sends PRACK for reliability
10. UE
2
sends 180 Ringing
11. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the voice codec to be used in this call; SIP call is established,
RTP streaming starts
12. Call is maintained for 3 minutes
13. UE
1
on hangup initiates a BYE
14. UE
2
responds with 200 OK
Results
1. UE
2
Receives 503 Service Unavailable
2. Call Re-establishment
3. UE
1
receives 183 Session In Progress

76 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 15: Loss of Media Bearer
Description
In this Negative Test scenario, a call is re-established after loss of the Media Bearer.
Initial State
1. UE
1
and UE
2
are VoLTE Registered
2. A voice call is established between UE
1
and UE
2
(UE
1
initiated) and is ongoing for 1
minute
3. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
Test Steps
1. UE
1
loses the media bearer, this could be the result of a radio connection loss
2. UE
2
receives BYE request with 503 Service Unavailable response code:

BYE 503 Service Unavailable
3. UE
1
regains radio connectivity
4. UE
1
re-establishes PDN connection by sending NAS Attach request + PDN
Connectivity request
77
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
5. After bearer configuration UE
1
returns the RRC Connection Reconfiguration Complete
message to the eNodeB
6. UE
1
sends REGISTER and completes the IMS Registration procedure
7. UE
1
re-initiates the call by sending INVITE message to UE2
8. UE
2
responds with 183 Session Progress
9. UE
1
sends PRACK for reliability
10. UE
2
sends 180 Ringing
11. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the voice codec to be used in this call
12. PGW initiates a new dedicated bearer. UE
1
receives RRC Connection Reconfiguration
with Activate dedicated EPS bearer context
13. SIP call is established, RTP streaming starts
14. Call is maintained for 3 minutes
15. UE
1
on hangup initiates a BYE
16. UE
2
responds with 200 OK
Results
1. UE
2
Receives BYE
2. Call Re-establishment
3. UE
1
Receives 183 Session In Progress

78 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 16: Voice Call Waiting, Second-Party Hold
Description
This scenario describes a user in a call who accepts an incoming call putting the current
user on hold.
Initial State
1. UE
1
, UE
2
, and UE
3
are VoLTE Registered
2. A voice call is established between UE
1
and UE
2
and is ongoing for 1 minute
3. RTP media packets are using dedicated bearer (QCI=1 and GBR)
Test Steps
1. UE
3
initiates a voice call to UE
1
and sends INVITE with SDP Offer:

INVITE SDP
audio=AMR-WB, AMR
2. A Call-Waiting screen indication is presented on UE
1
, which sends 180 Ringing to
UE
3
3. UE
3
responds with PRACK for reliability
79
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
4. UE
1
responds with 200 OK
5. UE
1
accepts the voice call from UE
3
and sends Re-INVITE with SDP Offer to UE
2
,
which is put on Hold

Re-INVITE: SDP
audio=sendonly
6. UE
2
sends 200 OK with SDP Answer to UE
1


200 OK: SDP Answer: SDP
audio=recvonly
7. UE
1
responds with ACK
8. Audio streams between UE
1
and UE
2
are put on Hold
9. UE
1
sends 200 OK with SDP Answer to UE
3
:

200 OK: SDP Answer
audio=AMR-WB
10. At this point RTP voice streams are exchanged between UE
1
and UE
3
on dedicated
bearer (QCI=1 and GBR), establishing an ongoing Voice call
11. UE
1
hangs-up voice call with UE
3
and sends BYE to UE
3
12. UE
3
responds with 200 OK
13. UE
1
switches back to the voice call with UE
2
by sending UE
2
RE-INVITE with SDP
offer to UE
2
:

RE-INVITE: SDP Offer
audio=sendrecv
14. UE
2
responds with 200 OK containing SDP Answer:

200OK: SDP Answer
audio=sendrecv
15. At this point RTP voice streams are exchanged again between UE
1
and UE
2
on a
dedicated bearer (QCI=1 and GBR). The call takes 60 seconds
16. UE
1
on hangup initiates a BYE
17. UE
2
responds with 200 OK, which reaches UE
1

80 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Results
1. UE
1
receives INVITE from UE
3
2. UE
2
receives Re-INVITE with SDP:

audio=sendonly
3. UE
1
receives 200 OK with SDP:

audio=recvonly
4. UE
3
receives 200 OK with SDP:

audio=AMR-WB
5. UE
3
receives BYE
6. UE
1
receives 200 OK
7. UE
2
receives Re-INVITE with SDP:

audio=sendrecv
8. UE
1
receives 200 OK with SDP:

audio=sendrecv
9. UE
2
receives BYE

81
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 17: Voice Call Switch Hold
Description
A user puts existing call on hold for incoming call. The user then switches hold back to the
original call and resumes.
Initial State
1. UE
1
, UE
2
and UE
3
are VoLTE Registered
2. A voice call is established between UE
1
and UE
2
and is ongoing for 1 minute; RTP
voice packets are sent in both ways
Test Steps
1. UE
1
places the call on hold by sending INVITE to UE
2
with SDP media attributes:

INVITE SDP
audio=AMR-WB, AMR
m=audio
a=sendonly
2. UE
2
responds with 200 OK with SDP media attributes:

m=audio
a=recvonly
3. UE
1
sends INVITE to UE
3
82 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
4. UE
3
responds with 200 OK
5. RTP voice packets are sent both ways between UE
1
and UE
3
on dedicated bearer
(QCI=1, GBR)
6. UE
1
puts the call with UE
3
on hold and switches back to UE
2
by sending INVITE to
UE
3
with SDP media attributes:

audio=AMR-WB, AMR
m=audio
a=sendonly
and sending INVITE to UE
2
with new SDP media attributes:
audio=AMR-WB, AMR
m=audio
a=sendrecv
7. UE
2
responds with 200 OK with SDP media attributes:

audio=AMR-WB, AMR
m=audio
a=sendrecv
8. UE
3
responds with 200 OK with SDP media attributes:

audio=AMR-WB, AMR
m=audio
a=recvonly
9. RTP voice packets are sent both ways between UE
1
and UE
2
on dedicated bearer
(QCI=1, GBR)
10. UE
1
ends the call by sending BYE to UE
1
11. UE
2
responds with 200 OK
12. UE
1
sends INVITE to UE
3
with SDP media attributes
13. UE
3
responds with 200 OK with SDP media attributes
14. RTP voice packets are sent both ways between UE
1
and UE
3
on dedicated bearer
(QCI=1, GBR)
15. UE
1
ends the call by sending BYE to UE
3
16. UE
3
responds with 200 OK
83
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Results
1. UE
1
receives INVITE with SDP media attributes
2. UE
3
receives INVITE with SDP media attributes
84 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 18: Voice Third Call Redirect to Voice Mail
Description
The User in a call allows an incoming call to go to Voice Mail.
Initial State
1. UE
1
, UE
2
and UE
3
are VoLTE Registered
2. A voice call is established between UE
1
and UE
2
and is ongoing
3. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
Test Steps
1. UE
3
initiates a voice call to UE
1
and sends INVITE with SDP Offer:

INVITE SDP
audio=AMR-WB, AMR
2. A Call-Waiting screen indication is presented on UE
1
3. UE
1
sends 180 Ringing to UE
3
85
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
4. UE
1
selects Ignore action
5. UE
1
sends 486 Busy Here, which propagates to TAS; TAS will initiate INVITE, which
is routed through S-CSCF to voice mail system
6. UE
3
receives 183 Session Progress with SDP Answer:

183 Session Progress SDP
audio=AMR-WB, AMR
7. UE
3
responds with PRACK
8. A voice prompt is played to UE
3
indicating to record voice message after the signal
9. At this stage RTP voice packets are sent both ways between UE
3
and voice mail
system. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
10. On hangup UE
2
receives BYE and UE
1
receives 200 OK
Results
1. UE
1
receives INVITE with SDP Offer:

audio=AMR-WB, AMR
2. UE
1
sends 486 Busy Here
3. UE
3
receives 183 Session In Progress with SDP Answer:

audio=AMR-WB, AMR
4. RTP packets are sent using Dedicated Bearers (QCI=1,GBR)
86 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 19: Handover During VoLTE Voice-Only Call
Description
This test case explores user VoLTE quality under a handover situaton. This handover may
be Intra-eNodeB, Inter-eNodeB handover across frequencies, bands or duplexing (FDD/
TDD). This may invoke an X2, S11 or S1 with MME/S-GW reallocaton.
Initial State
1. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
calls UE
2
successfully establishing SIP call and RTP packets are sent and
received on Dedicated Bearer (QCI=1)
2. After 90 seconds UE
1
provides RRC Measurement Reports that detail better reception
of Sector C than Sector A
3. The eNodeB then directs UE
1
to perform a handover across these sectors by sending
RRC Connection Reconfiguration (Handover Command)
4. UE
1
performs a RACH procedure on the target sector/eNodeB and should send a RRC
Connection Reconfiguration Complete message to the target if the procedure was
successful
87
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
5. A DRB is established successfully between UE
1
and target eNodeB
6. Voice call continues for 30-60 seconds more
7. UE
1
ends the call by sending BYE; UE
2
responds with 200 OK
Results
1. UE
1
receives RRC Connection Reconfiguration (Handover Command)
2. Handover signaling is successful
3. New Radio Bearer to the target Sector is setup successfully
4. RTP packets are using Dedicated Bearers (QCI=1)
5. QoE assessment of MOS and PESQ for voice quality
MOS is expected to have a value > 4.1
6. Voice stream Packet Loss < 0.001
7. Voice stream Jitter unaffected
88 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 20: DTMF Tone Handling
Description
Here the user accepts and responds with DTMF during a VoLTE call.
Initial State
1. UE
1
is VoLTE Registered
Test Steps
1. UE
1
initiates a call by sending INVITE message to a SIP client (DTMF host)

SDP contains narrowband and wideband codec support for both speech and DTMF
(telephone-event):

INVITE SDP m=audio 49152 RTP/AVPF 97 98 99 100 101 102
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:99 telephone-event/16000/1
a=fmtp:99 0-15
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-change-capability=2; max-red=220
a=rtpmap:101 AMR/8000/1
a=fmtp:101 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:102 telephone-event/8000/1
a=fmtp:102 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
89
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
2. UE
2
responds with 183 Session Progress
3. UE
1
sends PRACK for reliability
4. UE
2
sends 180 Ringing
5. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the codec to be used in this call:

200 OK SDP
m=audio 49152 RTP/AVPF 97 98 99 100 101 102
a=rtpmap:97 AMR-WB/16000/1
a=fmtp:97 mode-change-capability=2; max-red=220
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1\
a=rtpmap:99 telephone-event/16000/1
a=fmtp:99 0-15
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-change-capability=2; max-red=220
a=rtpmap:101 AMR/8000/1
a=fmtp:101 mode-change-capability=2; max-red=220; octet-align=1
a=rtpmap:102 telephone-event/8000/1
a=fmtp:102 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
6. SIP call is established, RTP streaming starts
7. PGW initiates new Dedicated Bearers (QCI=1, GBR). UE
1
and UE
2
receive RRC
Connection Reconfiguration with Activate dedicated EPS bearer context
8. Call is maintained for as long as 5 digits are sent as DTMF tones (bidirectional)
The tone duration of a DTMF event shall be at least 65ms and the pause duration
in-between two DTMF events shall be at least 65ms
RTP media packets are using dedicated bearer (QCI=1, GBR)
9. UE
1
on hangup initiates a BYE
10. UE
2
responds with 200 OK
11. UE
1
receives 200 OK
90 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Results
1. DTMF are correctly decoded at UE
1
2. DTMF are correctly sent by UE
1

91
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 21: VoLTE Emergency Registration
Description
This scenario describes a user performing an Emergency Registration in preparation for an
Emergency call.
Initial State
1. UE
1
is already attached and creates an Emergency PDN or UE is not attached and it
needs to perform an Emergency Attach to LTE network
2. UE
1
received the DNS address and the dedicated P-CSCF IP addresses from P-GW
Test Steps
1. UE
1
sends a REGISTER to P-CSCF, which forwards it through IMS network to
S-CSCF
2. UE
1
receives 401 UNAUTHORIZED challenge:

SIP 401 Challenge
Random challenge (RAND) Network authentication token (AUTN)
Authentication scheme (IMS authentication and key agreement
AKA)
3. UE
1
sends a second REGISTER with calculated response (RES) based on a shared
secret and previously received RAND
4. UE
1
receives a SIP 200 OK response from the S-CSCF routed back via IMS proxy-
servers
Results
1. UE
1
successfully receives 401 with Random Challenge (RAND) and AKA fields
2. UE
1
successfully receives SIP 200 OK
92 Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Test Case 22: VoLTE Emergency Call
Description
This scenario describes the situation where a user needs to perform an emergency call. The
US uses 911, the European Union has standardized 112 for dialing an Emergency call.
Initial State
1. UE
1
has completed an emergency registration
Test Steps
1. UE
1
sends INVITE with Emergency Service URN (Uniform Resource Name):

INVITE urn
service:sos
2. UE
1
receives 200 OK and responds to P-CSCF with ACK
Results
1. UE
1
successfully receives 200 OK
93
Chapter 8: Section 2: VoLTE Voice-Only Call
Validating VoLTE
Chapter 9
Section 3: VoLTE SMS
95
Chapter 9: VoLTE Test Case Section 3: Video and SMS
Validating VoLTE
CHAPTER 9
Section 3: VoLTE SMS
The Short Message Service (SMS) allows standardized short text messages over the
network. This allowed data transmission over the Circuit Switched 3G network. In LTE
all transmissions are data packets. SMS still remains a key customer feature. VoLTE
encompasses SMS support.

96 Chapter 9: VoLTE Test Case Section 3: Video and SMS
Validating VoLTE
Test Case 23: VoLTE Send SMS
Description
This scenario describes an SMS scenario between VoLTE-enabled UEs.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
sends MESSAGE request to UE
2
:

MESSAGE Content-Type=application/vnd.3gpp2.sms,
SMS encapsulated SMS P2P
2. UE
1
receives 200 OK
3. UE
2
receives MESSAGE request
4. UE
2
sends 200 OK
5. UE
1
receives Delivery ACK for MESSAGE request
6. UE
1
sends 200 OK
97
Chapter 9: VoLTE Test Case Section 3: Video and SMS
Validating VoLTE
Results
1. UE
2
receives MESSAGE request
2. UE
1
receives Delivery ACK for MESSAGE request

Chapter 10
Section 4: VoLTE Video and Voice Call
99
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
CHAPTER 10
Section 4: VoLTE Video and Voice Call
IR.94 defines video support in addition to the IR.92-specified voice operation. Video is
supported through the configuration of an additional Dedicated Bearer with QCI=2 to handle
the video RTP stream. Similar to voice, a variety of codecs may be used. A video call implies
both voice and video operation.
Measuring IP Video Quality
The perceptual quality of video transmitted across IP networks is susceptible to degradation
from a number of transmission network sources, including frame errors caused by packet
loss, discard of packets due to excessive delay/jitter, and discard of packets due to arrival
sequencing errors. Simply relying on packet loss statistics, however, is not an accurate way
to measure video quality as perceived by viewers. The same degree of packet loss may cause
obvious distortion or may not even be noticed by the end user, depending on which video
frame types are impaired.
100 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
In addition, impairments can be introduced during the encoding/decoding process by the
codec itself or an inappropriately low bitrate. The video content (the level of detail and motion
on-screen) can also have a significant impact on the visibility of problems. Furthermore,
perceptual quality is affected by subjective factors, including human reaction time and
the recency effect. Coupled with the type of content, such as fast motion, high detail, or
frequent scene changes, the quality of experience for the viewer will vary even under the
same impairment conditions.
Each of these objective and subjective factors must be taken into consideration to accurately
estimate IP video perceptual quality.
Video Quality Metrics
Although there is no video quality ITU standard, video quality methods are provided by some
companies. Telchemy is one such company that is recognized by the industry. VQmon/HD
provides real-time perceptual quality scores, performance statistics, and extensive diagnostic
data for monitored video streams in the form of the TVQM (Telchemy Video Quality Metrics)
data set.
VQM metrics reported by VQmon/HD fall into two main categories:
1. Perceptual Quality Metrics including mean opinion scores (MOS) for picture
quality (MOS-V), audio quality (MOS-A), and combined audio-video quality
(MOSAV), expressed in a range of 1 to 5, with 5 being best. For picture quality,
both relative MOS (which does not consider the resolution of the display, frame
rate, or progressive vs. interlaced scanning) and absolute MOS (which includes
consideration of these factors) are reported.
TVQM perceptual quality metrics also include an estimated peak signal-to-noise ratio
(ESPR) in dB, and a set of metrics indicating the severity level (on scale of 0-10) of
several degradation factors, including packet loss, jitter, codec type, etc.
2. Video Stream Metrics including video stream description (image size, codec type,
frame rate, etc.); content and scene analysis (detail and motion level) metrics; frame
statistics indicating the number and proportion of each frame type (I, B, P, SI, and
SP) received/impaired/lost/discarded; average and maximum bandwidth for each
frame type and for the stream overall; video stream jitter and delay metrics; and
interval metrics.
101
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
The table below lists some of the perceptual quality metrics reported by VQmon/HD,
including acceptable ranges for each.
Acronym Permitted
Range
VQmon Scaled
Range
Description
MOS-V 1-5 1-5 VQmon Picture Quality. A VQmon
MOS representing video service
picture quality. The score also
considers the original video
quality (before encoding and
transmission) and the video
contents sensitivity against video
packet loss/discard.
EPSNR 0-60 dB 0-60 dB VQmon/HD Estimated Peak Signal
to Noise Ratio. A measurement of
the quality of a video signal. This
corresponding to the maximum
possible signal energy versus the
energy of the noise.
102 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 24: VoLTE IR.94 Registration with IMS
AKA Authentication
Description
This test case describes an IR.94 UE IMS Registration flow.
Initial State
UE
1
is EPS attached and has the default bearer activated for VoLTE APN
UE
1
has obtained P-CSCF IP address
Test Steps
1. A SIP Register is initiated from UE to P-CSCF, uses Contact header field to indicate
video media support:
Contact: sip:user@example.com
audio
video
2. The rest of the steps are similar with those for an IR.92 only UE registration; see
Test Case 2
Results
1. UE
1
successfully receives 401 with Random Challenge (RAND) AKA
2. UE
1
successfully receives SIP 200 OK
103
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 25: VoLTE 2-Way Video Call with 2-Way Audio
Description
This scenario describes a 2-way video VoLTE call with 2-way audio.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
sends SIP INVITE message containing SDP offer (UE
1
s IP address and ports for
bi-directional audio and video media) to P-CSCF
2. UE
2
responds with 183 Session Progress
3. UE
1
sends PRACK for reliability
4. UE
2
sends 180 Ringing
5. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the voice codec and H.264 as the video codec to be used in this
call
6. SIP call is established, RTP streaming starts. Voice and video dedicated bearers are
configured at this stage
104 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
7. The rest of the steps are similar with a simple 2-way VoLTE voice call per
Test Case 6
Results
1. Successful SIP Signaling execution to complete the INVITE process; ACK is received
by UE
2
2. Successful initiation of a voice stream, with correct properties, on a dedicated
bearer (QCI=1)
3. Successful initiation of a video stream, with correct properties, on a dedicated
bearer (QCI=2)
4. RTP packets are using dedicated bearers
5. QoE assessment of MOS and PESQ for voice quality and MDI (Media Delivery Index)
with DF (Delay Factor) and MLR (Media Loss Rate) components
MOS is expected to have a value > 4.1
Maximum acceptable DF is between 9 and 50ms
Maximum acceptable MLR = 0.0005
6. Successful teardown of the call by UE
1
, BYE is responded with 200 OK
105
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 26: VoLTE Video Call Originator Terminates
Description
This scenario describes a 2-way video and audio VoLTE call where the call originator
terminates it.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
sends SIP INVITE message containing SDP offer (UE
1
s IP address and ports for
bi-directional audio and video media) to P-CSCF
2. UE
2
responds with 183 Session Progress
3. UE
1
sends PRACK for reliability
4. UE
2
sends 180 Ringing
5. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the voice codec and H.264 as the video codec to be used in this
call
6. SIP call is established, RTP streaming starts and lasts for 2 minutes. Voice and video
dedicated bearers are configured at this stage
106 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
7. UE
1
sends BYE
8. UE
2
responds with 200 OK
Results
1. Successful teardown of the call by UE
1
, BYE is responded with 200 OK

107
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 27: VoLTE Video Call, Called Party Terminates
Description
This scenario describes a 2-way video and audio VoLTE call where the called party
terminates the call.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
sends SIP INVITE message containing SDP offer (UE
1
s IP address and ports for
bi-directional audio and video media) to P-CSCF
2. UE
2
responds with 183 Session Progress
3. UE
1
sends PRACK for reliability
4. UE
2
sends 180 Ringing
5. UE
2
responds with 200 OK and receives ACK; 200 OK contains a SDP answer that
selects AMR-WB as the voice codec and H.264 as the video codec to be used in this
call
108 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
6. SIP call is established, RTP streaming starts and lasts for 2 minutes. Voice and video
dedicated bearers are configured at this stage
7. UE
2
sends BYE
8. UE
1
responds with 200 OK
Results
1. Successful teardown of the call by UE
2
, BYE is responded with 200 OK
109
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 28: Change of Video Parameters
Description
During a call, UE
1
initiates a change of video parameters, driven by the IMS application,
negotiating up or down depending on the call quality. Network initiation of reconfiguration is
possible by the PCEF to Bandwidth shape or the PCRF to Service downgrade.
Initial State
1. UE
1
and UE
2
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
, AMR-WB and H.264 are used
Test Steps
1. UE
1
sends UE
2
Re-INVITE with SDP Offer
2. UE
2
responds with 200 OK with SDP answer accepting the new parameters
3. Updated MBR/GBR of the media streams is now established
4. After 3 minutes UE
2
ends the call by sending BYE to UE
1
5. UE
1
responds with 200 OK
110 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Results
1. UE
2
receives Re-INVITE with SDP Offer containing new video (H.264) parameters
2. UE
1
receives 200 OK
3. UE
1
receives BYE
4. UE
2
receives 200 OK
111
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 29: Video Call a User Stops Video
Description
The user in this video call disables the video functionality but continues with voice. This
allows users an important privacy capability.
Initial State
1. UE
1
and UE
2
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
and is ongoing
3. RTP media packets are using dedicated bearers (QCI=1, GBR for voice and QCI=2,
GBR for video)
Test Steps
1. UE
1
sends RE-INVITE to UE
2
with SDP Offer:

RE-INVITE SDP
m=video RTP/AVP 21
a=recvonly
1. UE
2
accepts stream stop and sends 200 OK with SDP Answer:

200 OK SDP
m=video RTP/AVP 21
a=sendonly
112 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
2. RTP video media stream from UE
1
to UE
2
stops. Between UE
1
and UE
2
exists a 2-way
voice call and a video stream from UE
2
to UE
1
3. Call is maintained for 3 minutes
4. UE
1
on hangup initiates a BYE
5. UE
2
responds with 200 OK, which reaches UE
1
Results
1. UE
1
sends RE-INVITE to close video
2. UE
1
receives a 200 OK
3. Voice continues between UE
1
and UE
2
4. RTP video packets are sent from UE
2
to UE
1
only

113
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 30: Video Third Call Redirect to Voice Mail on Ignore
Description
This scenario describes an incoming call going to voice Mail.
Initial State
1. UE
1
, UE
2
, and UE
3
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
and is ongoing
3. RTP media packets are using Dedicated Bearers (QCI=1, GBR for voice and QCI=2,
GBR for video)
Test Steps
1. UE
3
initiates a video call to UE
1
and sends INVITE with SDP Offer:
INVITE SDP
audio=AMR-WB, AMR
video=H.264
114 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
2. A Call-Waiting screen indication is presented on UE
1
, which sends 180 Ringing to
UE
3
3. UE
1
selects Ignore action
4. UE
1
sends 486 Busy Here, which propagates to TAS; TAS will initiate INVITE, which
is routed through S-CSCF to voice mail system
5. UE
3
receives 183 Session Progress with SDP Answer:

183 Session Progress SDP
audio=AMR-WB, AMR
6. UE
3
responds with PRACK for reliability
7. A voice prompt is played to UE
3
, which can deposit his voice only message after the
signal
8. At this stage RTP voice packets are sent both ways between UE
3
and voice mail
system. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
9. On hangup UE
2
receives BYE and UE
1
receives 200 OK
Results
1. UE
1
receives INVITE with SDP Offer:

audio=AMR-WB, AMR
video=H.264
2. UE
1
sends 486 Busy Here
3. UE
3
receives 183 Session Progress with SDP Answer:

audio=AMR-WB, AMR
115
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 31: Video Call Accepted as Voice Only
Description
This scenario describes a situation when a call initiated with video sharing is accepted as a
voice only call.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. UE
1
and UE
2
are VoLTE Registered and available
Test Steps
1. UE
1
sends INVITE to UE
2
with SDP offer:

INVITE SDP
video=H.264
audio=AMR-WB, AMR
2. UE
2
displays incoming call notification as Video Call and prompts user with options
to Accept Video Call, Accept Voice-Only, Ignore
3. UE
2
responds with 180 Ringing, which is propagated back through IMS network to
UE
1
4. UE
1
sends PRACK to UE
2
for reliability
116 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
5. UE
2
user selects Accept Voice-Only and UE
2
sends 200 OK to UE
1
with HD voice
only SDP answer (no video support):

200 SDP
video=port 0
audio=AMR-WB
6. UE
1
receives 200 OK with the SDP Answer and responds with ACK. SIP call is
now established, RTP voice streaming starts with AMR-WB codec; voice Dedicated
Bearer is created at this stage and follows the same procedure as in Test Case 6
7. Call is maintained for 3 minutes
8. UE
1
on hangup initiates a BYE
9. UE
2
responds with 200 OK, which reaches UE
1
Results
1. UE
2
sends 200 OK for voice only
2. UE
1
receives 200 OK to Invite process assigned for voice only

117
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 32: Voice Call Transition to Video Call Accepted
Description
This scenario describes a voice call that is upgraded to a video call
.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. A VoLTE voice call has been setup between UE
1
and UE
2
and RTP voice streams are
exchanged between user devices on a dedicated bearer (QCI=1 and GBR)
Test Steps
1. UE
2
sends Re-INVITE to UE
1
with voice and video SDP offer:

Re-INVITE SDP
video=H.264
audio=AMR-WB
2. UE
1
accepts request to upgrade the call with video support and sends 200 OK:

200 OK SDP
video=H.264
audio=AMR-WB
118 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
3. RTP video streaming starts with H.264 codec; a new dedicated bearer for video
streaming is configured at this stage (QCI=2 with GBR) and follows the same
procedure as voice dedicated bearer in Test Case 6
4. Voice call continues and is maintained for 3 minutes
5. UE
1
on hangup initiates a BYE
6. UE
2
responds with 200 OK, which reaches UE
1
Results
1. UE
1
receives Re-INVITE
2. UE
2
receives 200 OK with SDP Answer containing H.264 video support
3. Successful initiation of voice and video streams, with correct properties, on a
dedicated bearer (QCI=1, QCI=2)
119
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 33: Voice Call Transition to Video Call Ignored/
Time-out
Description
This scenario describes a situation where a request to upgrade voice call to video call is
ignored.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. A VoLTE voice call has been setup between UE
1
and UE
2
and RTP voice streams are
exchanged on dedicated bearer (QCI=1 and GBR) between these users
Test Steps
1. UE
2
sends Re-INVITE to UE
1
with voice and video SDP offer:

Re-INVITE SDP
video=H.264
audio=AMR-WB
2. UE
1
ignores display message to upgrade the call with video
3. Call upgrade times out and TAS sends CANCEL to UE
1
4. UE
1
responds with 200 OK
120 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
5. UE
1
sends 487 Request Terminated to P-CSCF, which forwards it to TAS through
S-CSCF
6. TAS responds with 603 Decline, which is propagated to UE
2
7. Voice call continues and is maintained for 3 minutes
8. UE
1
on hangup initiates a BYE
9. UE
2
responds with 200 OK, which reaches UE
1
Results
1. UE
1
receives Re-INVITE
2. UE
1
sends 487 Request Terminated to P-CSCF
3. UE
2
receives 603 Decline
121
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 34: Voice Call Transition to Video Call Rejected
Description
This scenario describes a situation where a request to upgrade voice call to video call is
rejected.
Initial State
1. UE
1
and UE
2
are EPS attached and have the default bearer activated on VoLTE APN
2. A VoLTE voice call has been setup between UE
1
and UE
2
and RTP voice streams are
exchanged between user devices on a dedicated bearer (QCI=1 and GBR)
Test Steps
1. UE
2
sends Re-INVITE to UE
1
with voice and video SDP offer:

Re-INVITE SDP
video=H.264
audio=AMR-WB
2. UE
1
rejects option to upgrade to a video call and sends 603 Decline, which is
propagated back to UE
2
3. Voice only call continues for 3 minutes
4. UE
1
on hangup initiates a BYE
5. UE
2
responds with 200 OK, which reaches UE
1
122 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Results
1. UE
1
receives Re-INVITE
2. UE
2
receives 603 Decline
123
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 35: Handover During VoLTE Video Call
Description
This test case explores user VoLTE video call quality under a handover situation.
This handover may be Intra-eNodeB, Inter-eNodeB handover across frequencies, bands or
duplexing (FDD/TDD). This may invoke an X2, S11 or S1 with MME/S-GW reallocation.
Initial State
1. UE
1
and UE
2
are VoLTE Registered and available.
Test Steps
1. UE
1
calls UE
2
successfully establishing a 2-way video and audio call. RTP packets
are sent and received on Dedicated Bearer (QCI=1, GBR for voice and QCI=2, GBR for
video)
2. After 90 seconds UE
1
provides RRC Measurement Reports that detail better reception
of Sector C than Sector A
3. The eNodeB then directs UE
1
to perform a handover across these sectors by sending
RRC Connection Reconfiguration (Handover Command)
4. UE
1
performs a RACH procedure on the target sector/eNodeB
124 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
5. UE
1
sends a RRC Connection Reconfiguration Complete message to the target
eNodeB on success
6. A DRB is established successfully between UE
1
and target eNodeB
7. Call continues for 30-60 seconds more
8. UE
1
ends the call by sending BYE. UE
2
responds with 200 OK
Results
1. UE
1
receives RRC Connection Reconfiguration (handover Command)
2. Handover signaling is successful
3. New Radio Bearer to target sector is setup successfully
4. RTP packets are using Dedicated Bearers (QCI=1 for voice and QCI=2 for video)
5. QoE assessment of MOS and PESQ for voice quality and MDI (Media Delivery Index)
with DF (Delay Factor) and MLR (Media Loss Rate) components.
MOS is expected to have a value > 4.1
Maximum acceptable DF is between 9 and 50ms
Maximum acceptable MLR = 0.0005
6. Voice stream Packet Loss < 0.001
7. Voice stream Jitter unaffected
125
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 36: Video Call Put on Hold
Description
Here an existing video call is put on hold to initiate a new video call.
Initial State
1. UE
1
, UE
2
, and UE
3
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
and is ongoing
3. RTP media packets are using dedicated bearer (QCI=1, GBR for voice and QCI=2,
GBR for video)
Test Steps
1. UE
3
initiates a video call to UE
1
and sends INVITE with SDP Offer:
INVITE SDP Offer
audio=AMR-WB, AMR
video=H.264
2. A Call-Waiting screen indication is presented on UE
1
, which sends 180 Ringing to
UE
3
3. UE
3
responds with PRACK for reliability
4. UE
1
responds with 200 OK
126 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
5. UE
1
accepts the video call from UE
3
and sends Re-INVITE with SDP Offer to UE
2
,
which is put on Hold:

Re-INVITE SDP
audio=sendonly
6. UE
2
sends 200 OK with SDP Answer to UE
1
:

200 OK SDP
audio=recvonly
7. UE
1
responds with ACK
8. Audio streams between UE
1
and UE
2
are put on Hold
9. UE
1
sends 200 OK with SDP Answer to UE
3
:

200 OK SDP
audio=AMR-WB
10. At this point RTP voice and video streams are exchanged between UE
1
and UE
3

on Dedicated Bearers (QCI=1, GBR for voice and QCI=2, GBR for video); video call
between UE
1
and UE
3
takes 30 seconds
11. UE
1
hangs-up video call with UE
3
and sends BYE to UE
3
12. UE
3
responds with 200 OK
13. UE
1
switches back to the video call with UE
2
by sending UE
2
RE-INVITE with SDP
offer to UE
2
:

RE-INVITE SDP
audio=sendrecv
video=sendrecv
14. UE
2
responds with 200 OK containing SDP Answer:

200 OK SDP
audio=sendrecv
video=sendrecv
15. At this point RTP voice and video streams are exchanged again between UE
1
and UE
2

on Dedicated Bearers (QCI=1, GBR for voice and QCI=2, GBR for video); the call takes
60 seconds
16. UE
1
on hangup initiates a BYE
17. UE
2
responds with 200 OK
127
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Results
1. UE
1
receives the INVITE from UE
3
2. UE
1
receives the 200 OK with SDP Answer from UE
2
128 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 37: Video Call Switch Hold
Description
A user puts an existing call on hold for incoming video call. The user then switches hold back
to the original call.
Initial State
1. UE
1
, UE
2
, and UE
3
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
and is ongoing
3. RTP media packets are using Dedicated Bearers (QCI=1 and GBR for voice, QCI=2
and GBR for video)
Test Steps
1. UE
3
initiates a video call to UE
1
and sends INVITE with SDP Offer:
INVITE: SDP Offer
video=H.264
audio=AMR-WB, AMR
2. A Call-Waiting screen indication is presented on UE
1
, which sends 180 Ringing to
UE
3
3. UE
3
responds with PRACK for reliability
4. UE
1
responds to PRACK with 200 OK




129
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
5. UE
1
accepts the video call from UE
3
and sends Re-INVITE with SDP Offer to UE
2
,
which is put on Hold:

Re-INVITE: SDP
audio=sendonly
video=sendonly
6. UE
2
sends 200 OK with SDP Answer to UE
1
:

200 OK: SDP Answer: SDP:
audio=recvonly
video=recvonly
7. UE
1
responds with ACK
8. Audio and video streams between UE
1
and UE
2
are put on Hold
9. UE
1
sends 200 OK with SDP Answer to UE
3
:

200 OK SDP
video=H.264
audio=AMR-WB
10. At this point RTP voice streams are exchanged between UE
1
and UE
3
on a dedicated
bearer (QCI=1 and GBR) establishing an ongoing video call
11. UE
1
hangs-up video call with UE
3
and sends BYE to UE
3
12. UE
3
responds with 200 OK
13. UE
1
switches back to the video call with UE
2
by sending RE-INVITE with the SDP
offer:

RE-INVITE SDP
audio=sendonly
video=sendonly;
14. UE
2
responds with 200 OK containing SDP Answer:

200 OK SDP
audio=recvonly
video=recvonly
15. At this point RTP voice streams are exchanged again between UE
1
and UE
2
on a
dedicated bearer (QCI=1 and GBR); video call takes 60 seconds
16. UE
1
on hangup initiates a BYE
17. UE
2
responds with 200 OK, which reaches UE
1
130 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Results
1. UE
1
receives INVITE with SDP media attributes
2. UE
3
receives INVITE with SDP media attributes
131
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Test Case 38: Video Third Call Redirect to Voice Mail
Description
This scenario describes a user allowing an incoming video call to go to Voice Mail.
Initial State
1. UE
1
, UE
2
, and UE
3
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
and is ongoing
3. RTP voice and video media packets are using Dedicated Bearers (QCI=1 and GBR for
voice and QCI=1, GBR for video)
Test Steps
1. UE
3
initiates a video call to UE
1
and sends INVITE with SDP Offer:
INVITE SDP
audio=AMR-WB, AMR
video=H.264
2. A Call-Waiting screen indication is presented on UE
1
, which sends 180 Ringing to
UE
3
132 Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
3. UE
1
selects Ignore action
4. UE
1
sends 486 Busy Here, which propagates to TAS; TAS initiates INVITE, which is
routed through S-CSCF to voice mail system
5. UE
3
receives 183 Session Progress with SDP Answer:

183 Session Progress SDP
audio=AMR-WB, AMR
6. UE
3
responds with PRACK for reliability
7. A voice prompt is played to UE
3
, which can deposit a voice message after the signal
8. At this stage, RTP voice packets are sent both ways between UE
3
and voice mail
system; RTP voice media packets are using dedicated bearer (QCI=1 and GBR)
9. On hangup UE
2
receives BYE and UE
1
receives 200 OK
Results
1. UE
1
receives INVITE with SDP Offer:

audio=AMR-WB, AMR
video=H.264
2. UE
1
sends 486 Busy Here
3. UE
3
receives 183 Session Progress with SDP Answer:

audio=AMR-WB, AMR
133
Chapter 10: Section 4: VoLTE Video and Voice Call
Validating VoLTE
Chapter 11
Section 5: Advanced VoLTE Testing
135
Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
CHAPTER 11
Section 5: Advanced VoLTE Testing
This section details advanced VoLTE testing scenarios, including multi-party calling and
multi-tasking.
136 Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
Test Case 39: Voice Ad-Hoc Multi-Party Conference
Description
Here a user in a call brings in a called third user for a multi-party conference.
Initial State
1. UE
1
, UE
2
and UE
3
are VoLTE Registered
2. A voice call is established between UE
1
and UE
2
; RTP voice packets are sent both
ways
Test Steps
1. UE
1
puts UE
2
on hold by sending Re-INVITE with SDP Offer:

Re-INVITE
m=audio
a=sendonly
2. UE
2
responds with 200 OK with SDP Answer:

m=audio
a=recvonly
3. UE
1
sends ACK to UE
2
137
Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
4. UE
1
establishes a voice call with UE
3
5. UE
1
puts UE
3
on hold by sending Re-INVITE with SDP Offer:

Re-INVITE
m=audio
a=sendonly
6. UE
3
responds with 200 OK with SDP Answer
7. UE
1
sends ACK to UE
3
8. UE
1
creates a conference by sending INVITE to conference URI, with SDP Offer:

INVITE
m=audio
a=sendrecv
9. UE
1
receives 200 OK with SDP Answer from the Media Server
10. UE
1
sends ACK
11. At this moment an active RTP path for voice is created between UE
1
and Media
Server
12. UE
1
sends SUBSCRIBE to TAS
13. UE
1
receives 200 OK from TAS
14. TAS sends NOTIFY to UE
1
for current conference events
15. UE
1
invites UE
2
to conference by sending REFER request
16. The REFER request contains REFER TO header that indicates UE
2
and REPLACE
header indicating that this REFER request will replace UE
1
to UE
2
call leg
17. UE
1
receives 202 Accepted to acknowledge REFER request
18. UE
1
receives NOTIFY with the status of REFER
19. UE
1
sends 200 OK
20. UE
2
receives INVITE without SDP
21. UE
2
answers with 200 OK with SDP Offer that includes media codec set that was
utilized in the initial call with UE
1
22. UE
2
receives ACK with SDP Answer
138 Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
23. At this moment an active RTP path for voice is created between UE
2
and Media
Server
24. UE
1
receives NOTIFY about successfully performed joining to conference
25. UE
1
sends 200 OK
26. UE
1
receives NOTIFY about UE
2
successfully joined the conference
27. UE
1
sends 200 OK
28. UE
1
disconnects the dialog between UE
1
and UE
2
by sending BYE
29. UE
1
invites UE
3
to conference by sending REFER request
30. The REFER request contains REFER TO header that indicates UE
3
and REPLACE
header indicating that this REFER request will replace UE
1
to UE
3
call leg
31. UE
1
receives 202 Accepted to acknowledge REFER request
32. UE
1
receives NOTIFY with the status of REFER
33. UE
1
sends 200 OK
34. UE
3
receives INVITE without SDP
35. UE
3
answers with 200 OK with SDP Offer that includes media codec set that was
utilized in the initial call with UE
1
36. UE
3
receives ACK with SDP Answer
37. At this moment an active RTP path for voice is created between UE
3
and Media
Server
38. UE
1
receives NOTIFY about successfully performed joining to conference
39. UE
1
sends 200 OK
40. UE
1
receives NOTIFY about UE
3
successfully joined the conference
41. UE
1
sends 200 OK
42. UE
1
disconnects the dialog between UE
1
and UE
3
by sending BYE
43. RTP voice media packets are exchanged in both ways between each UE and the
Media Server



139
Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
44. RTP voice packets are using Dedicated Bearers (QCI=1, GBR)
45. UE
1
ends the conference call by sending BYE
46. UE
2
and UE
3
receive BYE and respond with 200 OK
47. UE
1
receives 200 OK
Results
1. UE
1
receives 200 OK with SDP Answer from the Media Server after starting the
multi-party conference
2. Voice Bearers are correctly established for all 3 UEs

140 Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
Test Case 40: Video Ad-Hoc Multi-Party Conference
Description
Here a user in a call brings in a called third user for a multi-party conference.
Initial State
1. UE
1
, UE
2
, and UE
3
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
; RTP voice and video packets are
sent in both ways between UE
1
and UE
2
Test Steps
1. UE
1
puts UE
2
on hold by sending Re-INVITE with SDP Offer:

Re-INVITE
m=audio
a=sendonly
m=video
a=sendonly
141
Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
2. UE
2
responds with 200 OK with SDP Answer:

m=audio
a=recvonly
m=video
a=recvonly
3. UE
1
sends ACK to UE
2
4. UE
1
establishes a voice call with UE
3
5. UE
1
puts UE
3
on hold by sending Re-INVITE with SDP Offer:

Re-INVITE
m=audio
a=sendonly
m=video
a=sendonly
6. UE
3
responds with 200 OK with SDP Answer
7. UE
1
sends ACK to UE
3
8. UE
1
creates a conference by sending INVITE to conference URI, with SDP Offer:

INVITE
m=audio
a=sendrecv
m=video
a=sendrecv
9. UE
1
receives 200 OK with SDP Answer from the Media Server
10. UE
1
sends ACK
11. At this moment an active RTP path for voice and video is created between UE
1
and
Media Server
12. UE
1
sends SUBSCRIBE to TAS
13. UE
1
receives 200 OK from TAS
14. TAS sends NOTIFY to UE
1
for current conference events
15. UE
1
invites UE
2
to conference by sending REFER request
16. The REFER request contains REFER TO header that indicates UE
2
and REPLACE
header indicating that this REFER request will replace UE
1
to UE
2
call leg
142 Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
17. UE
1
receives 202 Accepted to acknowledge REFER request
18. UE
1
receives NOTIFY with the status of REFER
19. UE
1
sends 200 OK
20. UE
2
receives INVITE without SDP
21. UE
2
answers with 200 OK with SDP Offer that includes media codec set that was
utilized in the initial call with UE
1
22. UE
2
receives ACK with SDP Answer
23. At this moment an active RTP path for voice is created between UE
2
and Media
Server
24. UE
1
receives NOTIFY about successfully performed joining to conference
25. UE
1
sends 200 OK
26. UE
1
receives NOTIFY about UE
2
successfully joined the conference
27. UE
1
sends 200 OK
28. UE
1
disconnects the dialog between UE
1
and UE
2
by sending BYE
29. UE
1
invites UE
3
to conference by sending REFER request
30. The REFER request contains REFER TO header that indicates UE
3
and REPLACE
header indicating that this REFER request will replace UE
1
to UE
3
call leg
31. UE
1
receives 202 Accepted to acknowledge REFER request
32. UE
1
receives NOTIFY with the status of REFER
33. UE
1
sends 200 OK
34. UE
3
receives INVITE without SDP
35. UE
3
answers with 200 OK with SDP Offer that includes media codecs set that was
utilized in the initial call with UE
1
36. UE
3
receives ACK with SDP Answer
37. At this moment an active RTP path for voice and video is created between UE
3
and
Media Server
38. UE
1
receives NOTIFY about successfully performed joining to conference
39. UE
1
sends 200 OK
40. UE
1
receives NOTIFY about UE
3
successfully joined the conference
143
Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
41. UE
1
sends 200 OK
42. UE
1
disconnects the dialog between UE
1
and UE
3
by sending BYE
43. RTP voice and video media packets are exchanged in both ways between each UE
and the Media Server
44. RTP voice packets are using Dedicated Bearers (QCI=1, GBR)
45. RTP video packets are using Dedicated Bearers (QCI=2, GBR)
46. UE
1
ends the conference call by sending BYE
47. UE
2
and UE
3
receive BYE and respond with 200 OK
48. UE
1
receives 200 OK
Results
1. UE
1
receives 200 OK with SDP Answer from the Media Server after starting the
Multi-party conference
2. Voice and video Bearers are correctly established for all 3 UEs

144 Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
Test Case 41: Multitasking + Video Call
Description
This scenario examines the effect of other default bearer traffic activity on the video call
quality.
Initial State
1. UE
1
, UE
2
, and UE
3
are VoLTE Registered
2. A video call is established between UE
1
and UE
2
and is ongoing
Test Steps
1. Another application is opened on UE
2
; UE
2
sends a Re-INVITE to UE
1
; SDP media
description for video has attribute set to sendonly:

m=video RTP/AVP 21
a=sendonly
2. UE
1
replies with 200 OK:

video=H.264
a=recvonly
audio=AMR-WB
3. The video stream is stopped from UE
1
to UE
2
145
Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
4. UE
2
returns to VoLTE application and sends Re-INVITE to UE
1
with SDP Offer:

m=video RTP/AVP 21
a=sendrecv
5. UE
1
responds with 200 OK and SDP Answer:

video=H.264(sendrecv)
audio=AMR-WB
6. Both voice and video RTP packets are sent both ways between UE
1
and UE
2
Results
1. UE
1
receives Re-INVITE with sendonly attribute for video
2. UE
1
receives Re-INVITE with sendrecv attribute for video
3. RTP voice media packets are using Dedicated Bearers (QCI=1, GBR for voice and
QCI=2, GBR for video)
4. QoE assessment of MOS and PESQ for voice quality and MDI (Media Delivery Index)
with DF (Delay Factor) and MLR (Media Loss Rate) components:
MOS is expected to have a value > 4.1
Maximum acceptable DF is between 9 and 50ms
Maximum acceptable MLR = 0.0005
146 Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
Test Case 42: VoLTE Video Load Scenario
Description
This test case explores user VoLTE quality under load conditions. While UEs load the eNodeB
the VoLTE quality should not decrease.
Initial State
1. UE
1
... UE
200
are VoLTE Registered
2. Video calls are established between UE
1
and UE
101
UE
100
and UE
200
and is ongoing
Test Steps
1. UE
1...100
initiate video calls to UE
101...200
following the process in Test Case 25
2. An Invite rate of 10 per second should be used
3. While ramping the voice and video, quality should be monitored to ensure quality
remains excellent
147
Chapter 11: Section 5: Advanced VoLTE Testing
Validating VoLTE
Results
1. Monitor voice and video quality MOS score > 4.1
2. Media one-way delay under 150ms
Chapter 12
Section 6: Real-World VoLTE
Subscriber Modeling
149
Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling
Validating VoLTE
CHAPTER 12
Section 6: Real-World VoLTE Subscriber Modeling
To understand how your VoLTE network and services will perform while in actual use, testing
needs to employ subscriber traffic and patterns that happen in real life. You may know how
your network handles a particular type and constant load of traffic, but what happens to it
when an airbus lands and most of the 879 passengers and crew turn on and use their phones
all at once? Or when power is restored in a city?
The key to understanding the impact of these real-world events is to use real-world
subscriber modeling that subjects an eNodeB to a challenging array of real-world scenarios.
To target key performance metrics with real-world subscriber modeling, be sure your
performance testing includes:
Full-featured LTE UE emulation with FDD, TDD, DRX, etc.
High capacity and rate, and multiple UE ranges, each with UE-specific properties
Mobile application modeling with voice, video, and data traffic that includes QoE
(MOS, PESQ) and QoS measurements
Complex signaling operation including Attach, Detach, Handover, TAU, and Idle Mode
LTE Inter- and Intra-eNodeB handover across all connected sectors
Channel modeling that allows UE cell center/edge simulation with LTE DL Fast
Fading emulations including Pedestrian, Vehicle, Urban, and High-Speed Train
150 Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling
Validating VoLTE
Test Case 43: Airbus A380 Landing
Description
This scenario involves an Airbus A380 landing at Heathrow, passengers turning on cell
phones with data roaming getting updates, and making VoLTE calls.
Initial State
1. UE
1
.. UE
1000
are registered for the LTE network per sector
Test Steps
1. UEs initiate attaches at a rate of 50/s
2. 1000 UEs with VoLTE services commence IMS Registration
Rate of 10 UE/s
3. 50 UEs initiate VoLTE connections to held messages
4. 50 UEs download stored SMSs
Results
1. RAN and core infrastructure handle Attaches at 50/s
2. 10 UE/s successfully complete IMS Registration
3. Successful download of stored voice messages
4. Successful download of stored SMS
151
Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling
Validating VoLTE
Test Case 44: Power Outage Restored
Description
In this case, after a city regional power outage is restored, the network experiences an
Attach Storm, with all succeeding UEs attempting IMS Registration.
Initial State
1. UE
1
.. UE
1000
are registered for the LTE network per sector
Test Steps
1. UEs initiate attaches at a rate of 100/s
2. Successful UEs immediately start IMS Registration
Results
1. Successful handling of Attach Storm with UEs backing off
a) Actual attach rate < 100/s
2. IMS Registrations sustained at Attach rate
152 Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling
Validating VoLTE
Test Case 45: High-Density Financial District
Description
Extensive smart phone use and VoLTE operation occur in this model.





Initial State
1. UE
1
.. UE
1000
are registered for the LTE network per sector
2. UEs initiate attaches at a rate of 10/s
3. Successful UEs immediately start IMS Registration
Test Steps
1. All UEs start HTTP downloads at 72kbps
2. Rotating 250 UEs initiate 3 minute VoLTE voice and video calls
Results
1. All UEs achieve 72Mbps aggregate HTTP download
2. Rotating 250 UEs successfully complete VoLTE calls
Each VoLTE call has a voice and video MOS of Excellent
153
Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling
Validating VoLTE
Test Case 46: Rush Hour Commuter Traffic
Description
This scenario emulates commuters making VoLTE calls that include extensive mobility.
Initial State
1. UE
1
.. UE
1000
are registered for the LTE network per sector
2. UEs initiate attaches at a rate of 10/s
3. Successful UEs immediately start IMS Registration
Test Steps
1. Rotating 250 UEs initiate 10 minute VoLTE voice and video calls
2. All UEs eNodeB handover every 4 minutes
Back and forth between 2 UEs or round patterns over multiple eNodeBs
3. Idle and connected mobility HO (Inter/Intra) and TAU
Results
1. Rotating 250 UEs successfully complete 10 minute VoLTE calls
Each VoLTE call has a voice MOS of Excellent
2. Each UE hands-over successfully without a failure
154 Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling
Validating VoLTE
Test Case 47: Large University
Description
This test case employs savvy smart phone use with a triple-play mixture of traffic types.
Initial State
1. UE
1
.. UE
1000
are registered for the LTE network per sector
2. UEs initiate attaches at a rate of 10/s
3. Successful UEs immediately start IMS Registration
Test Steps
1. Rotating 300 UEs initiate 1 minute HTTP download
2. Rotating 100 UEs initiate 10 minute FTP download
3. Rotating 250 UEs initiate 5 minute VoLTE voice and video calls
4. UEs will be entering and exiting Idle
Results
1. All UEs successfully run HTTP, FTP, and VoLTE sessions
2. Rotating 250 UEs successfully complete 5 minute VoLTE calls
Each VoLTE call has a voice and video MOS of Excellent
155
Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling
Validating VoLTE
Chapter 13
Monitoring Challenges, Solutions
and Best Practices
157
Chapter 13: Monitoring Challenges, Solutions and Best Practices
Validating VoLTE
CHAPTER 13
Monitoring Challenges, Solutions, and Best
Practices
Building, maintaining, and enhancing a modern, large-scale network in a major undertaking.
Its both hard to know when youve built and optimized it well, and its even harder to know
why its gone wrong when it does. No network can anticipate every possible combination
of uses, nor anticipate what long term changes will be required. In order to properly
troubleshoot, maintain, and grow networks, it is important to use the appropriate tools.
Network monitoring tools are one component that has been evolving since the 1990s.
Monitoring tools vary in their usage and specialization. Among the more commonly deployed
tools are:
Network performance monitors
Application performance monitors
Network analyzers
Network data recorders
Security components:
Intrusion prevention system (IPS)
Security forensics recorder
Data loss prevention
Security information and event management (SIEM)
Some tools, such as network analyzers, capture raw network traffic for use in generating
statistics or analyzing failed sessions. Other tools, such as application performance monitors,
understand the protocols associated with particular interactions and can be used to obtain
high-level statistics, such as the number of web visits executed per hour. Still other tools
provide important functionality, such as intrusion detection/prevention and data loss
prevention.
In addition to analyzing good network usage, they can be used to watch for overloads,
faults, and inappropriate usage. In this way monitoring tools can help network operators
identify issues before they become serious problems. They may be used to highlight:
Too little or too much traffic
Dropped packets
158 Chapter 13: Monitoring Challenges, Solutions and Best Practices
Validating VoLTE
Excessive retransmissions
Irrelevant traffic
They can be directed to isolate particular problems with a specific service, user, interaction,
event, or security violation. In all cases, these tools rely on receiving copies of traffic from
locations throughout the network. The more places that they receive traffic from, the more
monitoring, detection, and analysis can be performed. Ultimately, this means that problems
can be identified and resolved quicker.
For example, Figure 1 shows a simplified network associated with a data center and
associated monitoring tools.
Network Performance Monitor
Server Farm
Network
Internet
Optimum Level
Intrusion Detection System
App Performance Monitor
Network Data Recorder
Network Analyzer
Simplified Data Center Network with Tools
The red lines connecting the network switches to the tools indicate where information is
gathered from in the network, while the red bars the utilization of the tools. Some tools
are grossly underutilized or oversubscribed. Information gathering relies on three types of
network elements:
SPAN ports a term coined by Cisco. SPAN ports mirror the data being handled by
a switch to the SPAN port. The mirrored data can be collected from an individual
switch port, multiple switch ports, specific VLANs, or using other criteria.
159
Chapter 13: Monitoring Challenges, Solutions and Best Practices
Validating VoLTE
Optical TAPs devices that passively collect data transmitted over a network
connection. Figure 2 is an example of a set of tap that is used to collect data from
multiple optical Ethernet cables; the data is forwarded to analysis tools.
Passive Optical Taps
Inline bypass a device that actively forwards the data flowing through a connection
to a monitoring tool. Figure 3 is an example of such a device from NetOptics. The
data connection flows through the two left hand ports, with copies coming out of the
two right hand ports.

Bypass Tap
In order for monitoring tools to have complete visibility throughout the network, they would
need to be connected to a majority of nodes in the network. This is clearly impractical for a
number of reasons:
A network connection would be required between every network location and every
network tool. With a limited number of SPAN ports per switch (typically just one
or two), TAPs, bypasses and switches would be required on a scale as large as the
original network.
Each tool would be very expensive, requiring a large number of input ports and a
large degree of processing power to sort through vast amount of network traffic.
Ultimately, several copies of each tool would be required.
160 Chapter 13: Monitoring Challenges, Solutions and Best Practices
Validating VoLTE
Confidential data could be exposed in a massive way. Confidential data generally
flows without encryption within a network. Such data would be received by a
number of the networking tools and may eventually be exposed outside of the
organization.
The solution to this problem is a network packet broker, such as the Ixia Anue Net
Tool Optimizer (NTO). The use of this type of device is shown in Figure 4.
Network Performance Monitor
Server Farm
Network
Internet Ixia Anue
Net Tool
Optimizer
TM
Optimum Level
Intrusion Detection System
App Performance Monitor
Network Data Recorder
Network Analyzer
Network Visibility Tool
Network data is collected once from each significant network node and sent to the network
visibility tool, which distributes the data to the network monitoring tools. The network
visibility tools can perform several functions that make them especially valuable and operate
at their intended capacity. The Ixia Anue NTO product line, for example, has the following
features:
Filtering. This is perhaps the most important NTO feature, since each type of tool
may only be interested in particular protocols, port numbers, source or destination
addresses, or source nodes in the network. The NTO performs this filtering function,
forwarding only the desired packets to the tools. This allows the tools to concentrate
on their job, without having to wade through irrelevant data.

The filtering function can also be used to concentrate particular streams of data
to specific tools. For example, a denial of service attack on a networks DMZ may
require analysis. The NTOs filter function can be used to quickly focus attention on
the incoming port, filtering on particular ports and protocols. This data can then be
forwarded to an IPS or other tool for real-time analysis.
161
Chapter 13: Monitoring Challenges, Solutions and Best Practices
Validating VoLTE
De-duplication. With network feeds coming from multiple places in the network,
duplicate packets are guaranteed. The de-duplication process removes the copies,
allowing monitoring tools to concentrate on flow analysis.
Buffering. Bursty traffic on data center and wireless core networks can easily
overload monitoring tools if not buffered through the network visibility tool. This
would result in the loss of data, perhaps at a critical time. The NTO maintains a
substantial buffer to help with such bursty traffic.
Packet trimming. Most monitoring tools are only interested in the first few packet
headers. The NTO can trim the packet, so that each monitoring tool only receives the
information it is interested in. This also helps with buffering, both in the tool and the
NTO.
Packet trimming also plays an important role in maintaining data confidentiality.
Packet payload data, which may contain user names, passwords, account numbers
and other private data, can be removed before it is sent to monitoring tools or
recorded.
Load balancing. Data centers and wireless core networks are large entities that can
require multiple copies of monitoring tools. The NTO can direct traffic to different
tool instances in order to balance load and ensure that there is no loss of data. It is
important, however, that data for each session be directed to a single tool instance.
Easy integration. Growing networks tend to use network links that vary in technology
and speed, for example from 10/100 Fast Ethernet copper links to 100 Gbps fiber
optic links. Network visibility tools must offer plug-in options to receive data from
each type and speed.
Automation. Most monitoring tools are used to keep tabs on general network health,
with alarms that go off when programmed limits are exceeded. Others, such as IPS
systems, watch for security events. In either case, it may be important to gather
additional information at the time of the alarm or event. NTO provides this capability,
for example by sending high resolution data from particular network nodes to a
forensic recorder when an alarm or event occurs.
Ultimately, aggregation and load balancing, along with other features allow operators to
efficiently scale their monitoring solutions. Operators also save on CAPEX, by minimizing
optical taps, bypasses, and analysis tools.
Chapter 14
Best Practices for Monitoring VoLTE in EPCs
163
Chapter 14: Best Practices for Monitoring VoLTE in EPCs
Validating VoLTE
CHAPTER 14
Best Practices for Monitoring VoLTE in EPCs
Monitoring EPC networks that handle VoLTE traffic is critical to ensure capacity,
performance, and quality. The essential components of the radio access network (RAN)
and evolved packet core are shown in the figure below, connected to an Ixia Anue Net Tool
Optimizer (NTO) and network monitoring probes/tools.
Radio Access Network Evolved Packet Core and Applications
S6a
S11 Gx
S5/S8
HSS
MME
PCRF
P-GW S-GW
S1-U
S1-MME
LTE-Uu
eNodeB
Monitoring probes
Ixia Anue Net Took Optimizer

SGi
Rx
Operators IP Services
(for example, IMS, PSS)
Monitored RAN and EPC Networks
Most of the monitoring can be done in the EPC even though the connection between UEs and
eNodeBs is external to the EPC. Visibility into the EPC network can be obtained through taps
at critical EPC network connections, as shown in the table below.
Location Signal(s) Information
eNodeB
to S-GW
S1-U Defines the user plane between eNodeB and serving gateway
(S-GW). GTP-U is used for the per-bearer user plane tunneling
and inter-eNodeB path switching during handover. It provides
non-guaranteed delivery of user plane PDUs between the eNodeB
and the S-GW.
MME to
S-GW
S11 ontrols the creation and modifications of tunnels using
GTP-C. Used by the MME to control path switching and bearer
establishment in the serving gateway and PDN gateway. Keeps
control- and user-plane procedures in sync for a UE. For
handover, it is used to relocate the SGW when appropriate,
establish a direct or indirect forwarding tunnel for user-plane
traffic, and manage the user data traffic flow.
EPC Monitored Signals
164 Chapter 14: Best Practices for Monitoring VoLTE in EPCs
Validating VoLTE
Special monitoring tools have been developed to work with EPCs. One such tool is OneVu
from Velocent, which monitors EPC health and can measure quality of experience (QoE)
for subscribers. Subscriber sessions, encapsulated in GTP sessions, are automatically
correlated for best results.
EPCs, however, are very large affairs since they need to handle hundreds of RANs and
millions of users. Analysis of that many VoLTE sessions requires the use of multiple tool
instances of tools. A network visibility switch, such as the Ixia Anue NTO, can load balance
multiple tool boxes, but special processing is needed to ensure that each monitoring probe
receives all messages for particular GTP sessions. For that purpose, Ixia offers the GTP
Session Controller (GSC), which is connected as shown in the figure below.
Radio Access Network Evolved Packet Core and Applications
S6a
S11 Gx
S5/S8
HSS
MME
PCRF
P-GW S-GW
S1-U
S1-MME
LTE-Uu
eNodeB
Monitoring probes
Ixia Anue Net Took Optimizer

SGi
Rx
Operators IP Services
(for example, IMS, PSS)
GSC Positioning in EPC Network
The GSC receives sessions from the NTO as shown in the figure, or directly from EPC
network taps. It offloads session correlation from the monitoring tools, improving their
performance. It does this with:
GTP-session awareness groups together all messages for a session for forwarding
to the monitoring tools.
Session distiller samples and filters data to reduce traffic sent to tools to essential
information. VoLTE traffic alone can be analyzed.
Load balance automatically load balances sessions across monitoring tools, able to
distribute load according to tool capacity.
High capacity able to handle over 25 million subscribers.
Robust carrier grade reliability.
165
Chapter 14: Best Practices for Monitoring VoLTE in EPCs
Validating VoLTE
Key Performance Indicators for Monitoring VoLTE
Network taps can be placed throughout the EPC to monitor VoLTE performance, but the
key locations are the S11 interface between the MME and the S-GW and the S1-U interface
between the eNodeB and the S-GW.
Key performance indicators (KPIs) for VoLTE are defined for multiple protocol layers. The
most important for estimating users QoE include
Mean opinion score (MOS)
Percentage of failed call attempts
Percentage of dropped calls
Lower level KPIs are also critical to understanding VoLTE performance and quality. These are
found in the several tables below:
KPI Units
# of successful Register
transactions
Signaling rate per time interval
# of successful Invite
transactions
Signaling rate per time interval
# of concurrent calls Mean number of parallel SIP sessions
Mean call duration Average over duration for a SIP session over all call legs
# on-net calls Number of calls with both call legs inside the VoLTE
network
# off-net calls Number of calls with only one call leg inside the VoLTE
network
# of AMR calls Number of calls using advanced multirate
# of AMR-WB calls Number of calls using advanced multirate-wideband
# of VoLTE subscribers Number of distinct subscribers with at least one VoLTE call
during a measurement period
SIP Signaling Usage KPIs
166 Chapter 14: Best Practices for Monitoring VoLTE in EPCs
Validating VoLTE
KPI Units
Mean Register durations Mean duration of a successful Register transaction
measured between Register to 200 Register OK messages
Mean Invite duration Mean duration of a successful Register transaction
measured between Invite to 200 Register OK messages
Register success ratio (# of successful Register transactions) divided by the
(# of all Register transactions)
Invite success ratio (# of successful Invite transactions) divided by the
(# of all Invite transactions)
Register failure status code
ratio
(# of Register transactions with failure status codes)
divided by the (# of all Register transactions), per status
code (3xx, 4xx, 5xx and 6xx)
Invite failure status code
ratio
(# of Invite transactions with failure status codes) divided
by the (# of all Invite transactions), per status code (3xx,
4xx, 5xx and 6xx)
Invite cancel ratio (# of cancelled Invite transactions) divided by the
(# of all Invite transactions)
Signaling Accessibility and Retainability KPIs
KPI Units
# of voice media
connections
Number of dedicated bearers for VoLTE audio
Mean voice media call
duration
Mean duration of dedicated bearer
Mean throughput per call Mean data throughput within dedicated bearers, per
direction
Total aggregated
throughput
Total data throughput over all dedicated bearers, per
direction
# of concurrent calls Mean number of parallel RTP connections
Time per CODEC operation
mode
Total call time per CODEC operational bitrate
Voice Media Usage KPIs
167
Chapter 14: Best Practices for Monitoring VoLTE in EPCs
Validating VoLTE
KPI Units
Mean fraction of packets
lost
Mean packet loss as obtained from RTCP receiver report
per direction
Mean jitter Mean jitter as obtained from RTCP receiver report per
direction
Mean delay Mean delay as obtained from RTCP receiver report per
direction
Mean MOS Mean opinion score calculated from packet loss, jitter, and
delay according to ITU-T G107 and G107-1.
Mean MOS critical Mean opinion score calculated as above during QoE
monitoring intervals where jitter, delay, or packet loss
indicate considerable QoE impairment.
Time fraction with MOS
critical
Percentage of time when MOS critical is in effect
Mean fraction of packets
lost during MOS critical
Mean percentage of packets lost during MOS critical times
Mean jitter during MOS
critical
Mean jitter during MOS critical times
Mean delay during Mean delay during MOS critical times
Voice Media Quality KPIs
Chapter 15
Ixia VoLTE Test Solutions
169
Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
CHAPTER 15
Ixia VoLTE Test Solutions
Ixias VoLTE test solutions measure voice quality end-to-end, from the UE through to the IMS
core network. Operators can easily compare and contrast the voice quality of OTT service
to operator-provided voice services. Using best-in-class industry algorithms, operators
can measure the MOS of voice quality before going live. Additionally, Ixias solutions test
the functionality, scalability, and resiliency of LTE infrastructure components and new IMS
networks that support VoLTE-based services.
Ixias VoLTE test solutions offer:
Full-featured VoIP SIP/IMS testing over wireless stacks
Hardware-accelerated RTP over GTP that can scale up to more than 72,000 calls per
load module
Flexible functional and negative testing achieved with user control of SIP messaging
and content
Precise QoS measurements of voice quality under stress conditions
Ability to model complex mobility scenarios, such as intra or inter eNodeB
handovers, X2- or S1-based handovers, and S-GW relocations
Control plane measurements such as call setup time and time to media when the
network is under stress conditions
Simultaneous generation of other types of stateful traffic such as HTTP and video
MME/eNodeB and LTE Access simulations for testing access and core network
simultaneously
An Rx Diameter interface that is coordinated with the SIP/SDP for S-GW+P-GW and
PCRF isolation testing
170 Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
IxLoad Access
Ixias LTE IxLoad Access test solution performs UE emulation that can achieve the test cases
outlined in this book. It builds on the IxLoad platform that extends from easy to configure
layers 4-7 voice, video, and data traffic into UE emulation. It provides the highest density UE
emulation on the market, with1,000 connected active UEs simulated per board, high traffic,
LTE feature rich, channel modeling, and mobility. This allows realistic subscriber modeling to
replicate field issues and prove out capacity planning assumptions.
The following components are used to achieve comprehensive VoLTE testing:
Ixia Test Solution Function
IxLoad Software platform for full layer 4-7 testing,
includes test creation, execution, analysis, and
reporting
Wireless Triple-Play Bundle Software package with stateful replay and
emulation for video, VoIP, VoLTE, data, and
peer-to-peer protocols
Xcellon-Ultra NP Application traffic generation load module
XAir LTE UE emulation load module
r10 Radio Head LTE RF interface to LTE base stations, tunable
to support all LTE bands
XM/XG Chassis Ultra-high density and scalable chassis
171
Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
IxLoad
IxLoad is a unified test solution for testing all aspects of wireless networks end-to-end,
including LTE base stations, core network components, and the IMS subsystem. IxLoad
supports a broad set of test applications measuring the scalability and capacity of data
applications, the quality of rich media services, and the evaluation of security vulnerabilities.
Key Features
Measures voice quality by a mean opinion score using E-model and perceptual
estimation of speech quality (PESQ) algorithms
High RTP performance supports more than one million concurrent calls with media
per chassis
Measures control plane and media latency, which can be used to understand call
setup latency
Support of the GSMA IR.92 specification
Emulation of SIP endpoints to initiate and receive voice calls and SMS texts over
eGTP
Emulation of the IMS network (P-CSCF and MGW)
AMR and AMR-WB codecs
AKAv1 and AKAv2 authentication
Default and dedicated bearers
172 Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
IxLoads comprehensive VoLTE emulation includes:
Device Under Test Emulated Nodes
eNodeB UE eNodeB, MME, S-GW
MME HSS, eNodeB, S-GW, MME
S-GW MME, eNodeB, PDN-GW
PDN-GW S-GW, PCRF, IP Core
Network UE, IP Core
More information:
http://www.ixiacom.com/pdfs/datasheets/ixload_volte.pdf

173
Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
Wireless Triple-Play Bundle
Ixias IxLoad Wireless Triple-Play Bundle provides a comprehensive solution for testing
wireless multiplay networks and services. IxLoad emulates hundreds of thousands of
subscribers using the full range of voice, video, and data services. Its unique subscriber
modeling provides mixes of wireless user traffic to be applied over time, allowing service
providers to ensure quality of experience throughout the entire day. IxLoad is designed for
use by NEMs in their R&D facilities and for use by service providers and enterprises in their
pre-deployment labs. Ixias chassis and load modules provide the scale needed to match the
capacity of any device or system.
Available protocols include:
Service Protocols
Internet HTTP, P2P, FTP, SMTP, POP3, CIFS
Video
IGMP, RTSP, Adobe Flash Player, Microsoft
Silverlight, Apple HLS, MPEG2, and H.264/
AVC
Voice
SIP, MGCP, H.323, H.248, Cisco Skinny, FAX
over IP, video conferencing, and PSTN
Infrastructure DNS, DHCP, LDAP, and AAA
Encapsulation/security
DHCP, IPsec, PPP/L2TP with integrated 802.1x
and NAC authentication
174 Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
Xcellon-Ultra NP Load Module
Ixias Xcellon-Ultra NP load module is the highest-performing and most scalable application
traffic generation solution available in the industry. They offer complete layer 2-7 packet
generation, routing, and application testing functionality in a single XM load module. Xcellon-
Ultra NPs CPU count and NP architecture create a powerful application traffic generation
platform that emulates millions of real-world application flows, including voice, video, and
massive amounts of data.
Key Features
Flexible resource allocation for optimized L4-7 testing performance
Wire-speed layer 2-3 traffic generation and analysis, high-performance routing/
bridging protocol emulation, and true layer 4-7 application subscriber emulation and
traffic generation
Twelve 1GbE ports and one 10GbE port per module
Compatible with XG12, XM12, or XM2 chassis
More information:
http://www.ixiacom.com/pdfs/library/quick_ref_sheets/xcellon-np-qrs.pdf
175
Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
XAir Module
Ixias XAir module is the next-generation hardware for LTE UE emulation. It delivers
unparalleled LTE performance in the smallest footprint, providing the industrys highest UE
density. This module allows LTE Advanced feature support. With Ixias XM and XG platforms,
you can easily support multiple sectors.
The XAir module supports complex subscriber modeling with:
1000 UEs per sector
Voice (VoLTE), video, and data traffic support
QoE analysis and scoring of each traffic stream
Mobility over multiple sectors
Channel modeling per UE
Each XAir board supports one sector, with 1GE ports connected to the IxLoad Xcellon-Ultra
NP chassis. It supports a direct CPRI interface to an eNodeB or to Ixias Remote Radio Head
r10 units that cover all FDD and TDD frequency bands.
Key Features
Highest density LTE UE emulation starting at 1000 connected active UEs per board
Built-in high accuracy 10MHz clock for eNodeB synchronization
Fully compatible with the Ixia XM and XG chassis and load modules for seamless
testing with other Ixia hardware and test applications
More information:
http://www.ixiacom.com/pdfs/datasheets/xair-module.pdf
176 Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
r10 Wideband Radio Head
Ixias r10 Wideband Radio Head chassis for LTE and WiMAX testing supports a range of
bandwidths and provides a user-friendly interface for simplified remote control of the test
platform. A proven market leader as a base station or multiple UE emulator, the module is
primarily aimed at LTE base station conformance testing.
Key Features
Handles LTE UE radio modulation from 690 to 2690 MHz
FDD or TDD LTE technologies
Supports 5/10/15/20 MHz channel bandwidths
177
Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
High-Performance Chassis
Ixias VoLTE test solutions are powered by three chassis options:
Chassis Photo Description
XG12
XG12 is Ixias latest chassis technology,
and is the test and measurement industrys
highest port density test system for Ethernet.
12 Slots
Size: 19w x 19.21h x 27.2d
(48.26cm x 48.79cm x 69.09cm)
97 lbs. (44.1 kg) average shipping
weight
Supports XM Form Factor (XMFF)
load modules
Allows full 12-slot use of the newest
high-performance load modules, such
as XAir
XM12
XM12 High Performance features the highest
port density and performance in the industry
for lab-based, rack-mounted operation.
12 Slots
Size: 17.7w (19.0w including rack
ears ) x 17.5h x 21.0d (45.5cm x
44.5cm x 53.3cm)
83 lbs. (37.65 kg) empty, 88 lbs.
(39.92 kg) average shipping weight
Supports XM Form Factor (XMFF)
load modules
UL and CE safety approval
certifications; valid when the unit is
operating from 200-240VAC mains
178 Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
XM2
XM2 is ideal for desktop testing, smaller
scale tests, and remote monitoring.
2 Slots
Size: 14w (19.0w including rack
ears) x 4.5h x 19.25d (35.6cm
x 11.4cm x 48.9cm) with built-in
carrying handle.
25 lbs. (11.3 kg) empty, 30 lbs. (13.61
kg) average shipping weight
Supports XM Form Factor (XMFF)
load modules
Key Features
Ultra-high density and scalability
Automation, unified APIs, and centralized management
Multiuser operation
Full range of interface support
Hot swappable
Backward/forward compatibility
More Information:
Chassis Overview:
http://www.ixiacom.com/pdfs/library/quick_ref_sheets/ixia-core-qrs.pdf
XG12 Chassis:
http://www.ixiacom.com/products/network_test/chassis/display?skey=ch_optixia_
xg12
XM12 Chassis:
http://www.ixiacom.com/pdfs/datasheets/ch_optixia_xm12.pdf
XM2 Chassis:
http://www.ixiacom.com/pdfs/datasheets/ch_optixia_xm2.pdf
179
Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
Ixia Hardware Configuration for VoLTE Testing
Carriers can configure Ixias modular VoLTE test platforms to suit their current needs while
offering a simple path to grow their system as services expand. Ixia provides the industrys
highest density of UE emulation up to 6000 UEs in one XG12 chassis. Ixias platform
performance supports very high rate operation, including up to 300 attach attempts per
second. Following are examples of how the platform can be configured for testing one to six
sectors.
One-Sector Configuration
This configuration of an XM2 chassis with one XAir load module, one Xcellon-Ultra NP load
module, and one r10 Radio Head supports 1000 connected UEs.
Three-Sector Configuration
This configuration of an XM12 or XG12 chassis with three XAir load modules, three Xcellon-
Ultra NP load modules, and three r10 radio head module supports 3000 connected UEs.
180 Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
Six-Sector Configuration
This configuration of an XG12 chassis with six XAir load modules, six Xcellon-Ultra NP load
modules, and six r10 Radio Head modules supports 6000 connected UEs.
181
Chapter 15: Ixia VoLTE Test Solutions
Validating VoLTE
182 References
Validating VoLTE
References
Specification Version Name
GSMA IR.92 3.0, Dec 2010 IMS Profile for Voice and
SMS
GSMA IR.94 3.0, July 2012 IMS Profile for
Conversational Video
Service
3GPP TS 23.228 9.4.0 IP Multimedia Subsystem
(IMS); Stage 2
3GPP TS 24.229 9.60 IP Multimedia Call Control
Protocol Based on SIP and
SDP, Stage 3
3GPP TS 33.203 9.5.0 R9 Access Security for IP-
based Services
RFC 3261 June 2002 SIP: Session Initiation
Protocol
RFC 3550 July 2003 RTP: A Transport Protocol
for Real-Time Applications
RFC 3551 July 2003 RTP Profile for Audio and
Video Conferences with
Minimal Control
RFC 4867 April 2007 RTP Payload Format and
File Storage Format for the
Adaptive Multi-Rate (AMR)
and Adaptive Multi-Rate
Wideband (AMR-WB) Audio
Codecs

Das könnte Ihnen auch gefallen