VoLTE Book

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 industry’s “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 players—if 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

2

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, let’s 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 Ixia’s awardwinning 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.

3

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

4

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 5

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

6

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

7

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 LTE’s improved spectral efficiency to re-farm 2G/3G resources)

•

Fast-track compelling new services

•

Maximize quality while simultaneously delivering HD voice alongside data

Let’s 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 attrition—Informa estimates a drop of roughly 9% by 2018—but they’ll still represent a massive global market of $579B.

1,400 1,200 1,000 800

675

385

600 400 200

634

579

2013

2018

0 Voice

Data

Source: Informa Telecoms & Media

Chapter 1: VoLTE Market Drivers and Benefits

9

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 market—and monetize—this 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?

“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.”

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 — Lars Johnsson, senior still shy away from any free or low-cost service that director of product marketing for delivers a less than satisfactory experience, and may mobile LTE platforms at Broadcom 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 can’t 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 advantage—if they can deliver a superior QoE.

10


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.

“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

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 phone’s battery than 3G voice calls.” The positive net impact of LTE on battery life performance is becoming widely acknowledged since devices don’t have to maintain contact with two distinct networks to run voice and data applications.


11

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.

LTE to mobile subscribers penetration, Jun-13

a

y

Ru ss i

an rm

UK

Ge

Si

US A ng ap or e Au st ra lia Ca na da Sw ed Sa en ud iA ra bi a

n pa Ja

Ko re a

45% 40% 35% 30% 25% 20% 15% 10% 5% 0%

Source: Informa Telecoms & Media

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.

12


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 provider’s 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

VoLTE Revenues (US $M)

$2

$29

$467

VoLTE POP

300

30,000

120,000 210,000

$2,199

38,300

71,250

$7,140

$15,595

300,00

350,000

293% 383% 85%

Source: MindCommerce Let’s take a look at what’s involved in getting there. Chapter 1: VoLTE Market Drivers and Benefits

13

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 circuitswitched 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.

Chapter 2: What is VoLTE?

15

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 sharing—and 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.

16


Validating VoLTE


17

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 LTEspecific 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.

Chapter 3: Challenges To Deploying VoLTE

19

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.

20


Validating VoLTE

Fallback VoLTE is not a forklift upgrade; it’s 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 they’ve come to rely on won’t be compromised.


21

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.

22


Validating VoLTE


23

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.

•

A botched VoLTE would not only compromise customers’ satisfaction and loyalty, but have larger implications as well since Visibility monitoring. Once things get up and running, operators need to maintain first responders— the healthcare visibility into the network, making sure industry, local, state and that the tools and solutions used to federal government, as well as monitor and optimize performance and businesses— all rely upon cellular security are functioning optimally. This voice. includes making sure each tool receives the data it needs automatically and efficiently. Ultimately, operators want to have easy access to a network’s KPIs.

•

IGR

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.

Chapter 4: Validating VoLTE “Lab to Live”

25

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 costeffectively. These systems must be able to subject devices and configurations to high-stress, highscale 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 It’s 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.

26


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.


27

Validating VoLTE

Load Testing Since most issues occur at high scale, operators can’t 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.

28


Validating VoLTE

General Requirements on Network-based VoLTE Measurements1 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 let’s 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


29

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.

Chapter 5: VoLTE Test Configurations

31

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.

32


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.


33

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.

34


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 interarrival 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.


35

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.

36


Validating VoLTE


37

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

Chapter 6: VoLTE Test Cases: Overview

39

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:@ims… P:ASSERTED_ID Cell_ID

Results •

40

Numbered checks to be met to pass the test case


Validating VoLTE


41

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.

MME

eNodeB

S/PͲGW

HSS

PCRF

SPR

1.RRCSetup 2.AttachRequest 3.AttachRequest 4.Authentication 4.UpdateLocationRequest 6.UpdateLocationAck(IMSAPN,QCI5) 7.CreateSessionRequest(IMSAPN,QCI5) 8.CCR(Initial,IMSAPN,QCI5) 9.CCA(PCCRulesfordefaultbearer)

SPRquery

10.CreateSessionResponse(IMSAPN,QCI5,UEIPaddress,PͲCSCFaddress CSFBregistration 11.InitialContextSetupRequest/Attachaccept(IMSAPN,QCI5,UEIPaddress,PͲCSCFaddress 12.RRCConnectionReconfiguration/AttachAccept(IMSAPN,QCI5,UEIPaddress,PͲCSCFaddress 13.RRCConnectionReconfigurationComplete 14.InitialContextSetupResponse 15.DirectTransfer(AttachComplete) 16.ULNASTransport(AttachComplete) Uplinkdata 17.ModifyBearerRequest Downlinkdata

Chapter 7: Section 1: VoLTE Setup

18.ModifyBearerResponse

43

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:

UE

PͲCSCF

IͲCSCF

HSS

SͲCSCF

(SM1)Register (SM2)Register CxͲSelectionͲInfo (SM3)Register CxͲPut (CM1)AVͲReq (CM2)AVͲReqͲResp (SM4)4xxAuth_Challenge (SM5)4xxAuth_Challenge (SM6)4xxAuth_Challenge (SM7)Register (SM8)Register CxͲQuery (SM9)Register CxͲPut

(SM12)2xxAuth_Ok

44

(SM11)2xxAuth_Ok

(SM10)2xxAuth_Ok

CxͲPull


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:@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


45

Validating VoLTE Results

46

1.

UE successfully receives 401 with Random Challenge (RAND)

2.

UE successfully receives SIP 200 OK


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.


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:@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


47


48

1.

UE successfully receives 401 with Random Challenge (RAND) and AKA fields

2.

UE successfully receives SIP 200 OK


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.


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


49


50

1.

UE receives 200 OK in response to SUBSCRIBE

2.

UE receives SIP NOTIFY(REG-EVENT)


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.


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


51

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.


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.

52

UE successfully receives Notify Deactivated Event


Validating VoLTE


53

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. Kristina’shomenetwork

INVITE

PͲCSCF INVITE

100Trying

SͲCSCF INVITE 100Trying INVITE

183 PRACK

183 PRACK

Jennifer’shomenetwork

AS

IͲCSCF

SͲCSCF

100Trying

LIR LIA INVITE 100Trying

INVITE INVITE

183

183 PRACK PRACK

UPDATE

200(OK)

UPDATE

200(OK)

PͲCSCF

PRACK PRACK 200(OK)

100Trying 183

200(OK)

UPDATE UPDATE

200(OK)

UPDATE UPDATE 200(OK) 180(Ringing) 200(OK)

180(Ringing) 200(OK)

200(OK) 180(Ringing) 200(OK)

ACK

ACK

INVITE 183

PRACK 200(OK) Dedicatedbearer (QC11)established

200(OK)

180(Ringing) 180(Ringing) 200(OK) 200(OK) 200(OK) ACK ACK ACK

180(Ringing) ACK

200(OK)

183

183

200(OK) 200(OK) Dedicatedbearer (QC11)established

AS

HSS

200(OK)

UPDATE 200(OK)

180(Ringing)

180(Ringing)

200(OK)

200(OK)

Ringing

User Answers ACK

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).

Chapter 8: Section 2: VoLTE Voice-Only Call

55

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 HDquality 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 (PESQlistening 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.

56


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


57

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.

58


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.

UE1 and UE2 are EPS attached and have the default bearer activated on VoLTE APN

2.

UE1 and UE2 are subscribed with the IMS network and are available

Test Steps 1.

UE1 initiates the call by sending INVITE message to UE2: INVITE SDP a=rtpmap

99 AMR-WB/16000

2.

UE2 responds with 183 Session Progress

3.

UE1 sends PRACK for reliability of the provisional response

4.

UE2 sends 180 Ringing

5.

UE2 responds with 200 OK and receives ACK; 200 OK contains a SDP answer that selects AMR-WB as the voice codec to be used


59

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 UE1, 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. UE1 on hangup initiates a BYE 20. UE2 responds with 200 OK

60


Validating VoLTE Results 1.

Successful SIP Signaling execution to complete the INVITE process; ACK is received by UE2

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)


61

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.


2.

UE1 and UE2 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.

UE1 sends a BYE that is propagated through IMS proxies to UE2

2.

UE2 responds with 200 OK, which is propagated through the network to UE1

Results

62

1.

UE2 receives BYE from his P-CSCF

2.

UE1 receives 200 OK from his P-CSCF


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.


2.

UE1 and UE2 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.

UE2 sends a BYE that is propagated through IMS proxies to UE1

2.

UE1 responds with 200 OK, which is propagated through the network to UE1

Results 1.

UE1 receives BYE from P-CSCF

2.

UE2 receives 200 OK from P-CSCF


63

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.

UE1 and UE2 are VoLTE Registered and available

Test Steps

64

1.

UE1 initiates the call by sending INVITE message containing SDP with 2-way audio/ video info towards UE2 via IMS network (P,I,S-CSCF proxies)

2.

UE2 responds with 180 Ringing without SDP, which is propagated back to UE1

3.

UE2 sends 486 Busy Here response

4.

Upon receiving 486 Busy Here message S-CSCF proxy on UE2 side will forward it to TAS (Telephony Application Services) module

5.

TAS will trigger the Call Forwarding Procedure for UE2

6.

UE1 receives UPDATE (with SDP offer) from S-CSCF

7.

UE1 responds with 200 OK UPDATE (with SDP answer) to S-CSCF 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 UE1); after the prompt, UE1 can deposit his voice message to be delivered to UE2 voice mail box (RTP stream is sent from UE1 to Voice Mail Server)

9.

After RTP streams for voice mail stop, UE1 receives BYE from S-CSCF

Results 1.

UE2 sends 486 Busy Here

2.

UE1 receives UPDATE with SDP offer

3.

UE1 sends 200 OK UPDATE


65

Validating VoLTE

Test Case 10: Redirect VoLTE Call Not Answered to Voice Mail Description This test explores a case where the called party doesn’t answer incoming call and forwarding to voice mail is triggered.

Initial State 1.


Test Steps

66

1.

UE1 initiates the call by sending INVITE message containing SDP with 2-way audio (a=sendrecv) info towards UE2 via IMS network (P,I,S-CSCF proxies)

2.

UE2 responds with 180 Ringing with SDP, which is propagated back to UE1

3.

UE2 does not answer the incoming call, as a result Call Forward No Answer timer expires at TAS for UE2

4.

TAS sends CANCEL for the call to UE2 through S-CSCF

5.

UE2 sends 200 OK to S-CSCF as response to CANCEL; S-CSCF forwards the 200 OK to TAS module

6.

UE2 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 UE2


Validating VoLTE 8.

TAS triggers Call Forward procedure for Voice Mail

9.

UE1 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 UE1 via S-CSCF 12. UE1 sends ACK 13. A voice prompt is played (RTP stream is sent from Voice Mail Server to UE1); after the prompt, UE1 can deposit his voice message to be delivered to UE2 Voice Mail (RTP stream is sent from UE1 to Voice Mail Server) 14. After RTP streams for voice mail are stopped, UE1 receives BYE from S-CSCF

Results 1.

UE2 receives CANCEL

2.

UE2 sends 487 Request Terminated

3.

UE1 receives 181 Call is Being Forwarded

4.

UE1 receives 200 OK


67

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.


2.


Test Steps

68

1.

UE1 initiates the call by sending INVITE message to UE2

2.

UE2 responds with 100 Trying

3.

UE1 sends CANCEL

4.

UE2 responds with 200 OK

5.


6.

UE1 sends ACK



UE2 receives CANCEL

2.

UE1 receives 200 OK

3.

UE1 receives 487 Request Terminated


69

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.


2.


Test Steps

70

1.

UE1 initiates the call by sending INVITE message to UE2

2.

UE2 responds with 100 Trying

3.


4.

UE1 sends CANCEL C_seq=1

5.


6.


7.

UE1 sends ACK



UE1 receives 180 Ringing

2.

UE2 receives CANCEL

3.

UE1 receives 200 OK

4.

UE1 receives 487 Request Terminated


71

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.

UE1 and UE2 are VoLTE Registered

2.

UE1 has initiated an ongoing voice call with UE2

3.

RTP voice media packets are using dedicated bearer (QCI=1 and GBR)

Test Steps 1.

UE1 loses PDN connectivity

2.

UE2 receives BYE request with 503 “Service Unavailable” response code: BYE: Reason header

503 Service Unavailable

72

3.

UE1 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 Chapter 8: Section 2: VoLTE Voice-Only Call

Validating VoLTE 5.

UE1 sends REGISTER and completes the IMS Registration procedure

6.

UE1 re-initiates the call by sending INVITE message to UE2

7.

UE2 responds with 183 Session In Progress

8.

UE1 sends PRACK for reliability

9.


10. UE2 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, UE1 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. UE1 on hangup initiates a BYE 15. UE2 responds with 200 OK

Results 1.

Successful PDN Re-Connection

2.

Successful Call Re-establishment

3.

UE1 receives 183 Session In Progress


73

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.


2.

A voice call is established between UE1 and UE2 (UE1 initiated) and is ongoing for 1 minute

3.


Test Steps

74

1.

UE1 loses SIP signaling

2.

UE2 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, UE1 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) Chapter 8: Section 2: VoLTE Voice-Only Call

Validating VoLTE 7.


8.


9.


10. UE2 sends 180 Ringing 11. UE2 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. UE1 on hangup initiates a BYE 14. UE2 responds with 200 OK

Results 1.

UE2 Receives 503 Service Unavailable

2.

Call Re-establishment

3.

UE1 receives 183 Session In Progress


75

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.


2.

A voice call is established between UE1 and UE2 (UE1 initiated) and is ongoing for 1 minute

3.


Test Steps 1.

UE1 loses the media bearer, this could be the result of a radio connection loss

2.

UE2 receives BYE request with 503 “Service Unavailable” response code: BYE 503 Service Unavailable

76

3.

UE1 regains radio connectivity

4.

UE1 re-establishes PDN connection by sending NAS Attach request + PDN Connectivity request


Validating VoLTE 5.

After bearer configuration UE1 returns the RRC Connection Reconfiguration Complete message to the eNodeB

6.

UE1 sends REGISTER and completes the IMS Registration procedure

7.


8.


9.


10. UE2 sends 180 Ringing 11. UE2 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. UE1 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. UE1 on hangup initiates a BYE 16. UE2 responds with 200 OK

Results 1.

UE2 Receives BYE

2.

Call Re-establishment

3.

UE1 Receives 183 Session In Progress


77

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.

UE1, UE2, and UE3 are VoLTE Registered

2.

A voice call is established between UE1 and UE2 and is ongoing for 1 minute

3.

RTP media packets are using dedicated bearer (QCI=1 and GBR)

Test Steps 1.

UE3 initiates a voice call to UE1 and sends INVITE with SDP Offer: INVITE SDP audio=AMR-WB, AMR

78

2.

A “Call-Waiting” screen indication is presented on UE1, which sends 180 Ringing to UE3

3.

UE3 responds with PRACK for reliability Chapter 8: Section 2: VoLTE Voice-Only Call

Validating VoLTE 4.


5.

UE1 accepts the voice call from UE3 and sends Re-INVITE with SDP Offer to UE2, which is put on “Hold” Re-INVITE: SDP audio=sendonly

6.

UE2 sends 200 OK with SDP Answer to UE1 200 OK: SDP Answer: SDP audio=recvonly

7.

UE1 responds with ACK

8.

Audio streams between UE1 and UE2 are put on Hold

9.

UE1 sends 200 OK with SDP Answer to UE3: 200 OK: SDP Answer audio=AMR-WB

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

14. UE2 responds with 200 OK containing SDP Answer: 200OK: SDP Answer audio=sendrecv

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


79


UE1 receives INVITE from UE3

2.

UE2 receives Re-INVITE with SDP: audio=sendonly

3.

UE1 receives 200 OK with SDP: audio=recvonly

4.

UE3 receives 200 OK with SDP: audio=AMR-WB

5.

UE3 receives BYE

6.

UE1 receives 200 OK

7.

UE2 receives Re-INVITE with SDP: audio=sendrecv

8.

UE1 receives 200 OK with SDP: audio=sendrecv

9.

80

UE2 receives BYE


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.

UE1, UE2 and UE3 are VoLTE Registered

2.

A voice call is established between UE1 and UE2 and is ongoing for 1 minute; RTP voice packets are sent in both ways

Test Steps 1.

UE1 places the call on hold by sending INVITE to UE2 with SDP media attributes: INVITE SDP audio=AMR-WB, AMR m=audio a=sendonly

2.

UE2 responds with 200 OK with SDP media attributes: m=audio a=recvonly

3.

UE1 sends INVITE to UE3


81

Validating VoLTE 4.


5.

RTP voice packets are sent both ways between UE1 and UE3 on dedicated bearer (QCI=1, GBR)

6.

UE1 puts the call with UE3 on hold and switches back to UE2 by sending INVITE to UE3 with SDP media attributes: audio=AMR-WB, AMR m=audio a=sendonly

and sending INVITE to UE2 with new SDP media attributes: audio=AMR-WB, AMR m=audio

a=sendrecv

7.

UE2 responds with 200 OK with SDP media attributes: audio=AMR-WB, AMR m=audio a=sendrecv

8.

UE3 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 UE1 and UE2 on dedicated bearer (QCI=1, GBR)

10. UE1 ends the call by sending BYE to UE1 11. UE2 responds with 200 OK 12. UE1 sends INVITE to UE3 with SDP media attributes 13. UE3 responds with 200 OK with SDP media attributes 14. RTP voice packets are sent both ways between UE1 and UE3 on dedicated bearer (QCI=1, GBR) 15. UE1 ends the call by sending BYE to UE3 16. UE3 responds with 200 OK

82



UE1 receives INVITE with SDP media attributes

2.



83

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.


2.

A voice call is established between UE1 and UE2 and is ongoing

3.


Test Steps 1.

UE3 initiates a voice call to UE1 and sends INVITE with SDP Offer: INVITE SDP audio=AMR-WB, AMR

84

2.

A “Call-Waiting” screen indication is presented on UE1

3.

UE1 sends 180 Ringing to UE3 Chapter 8: Section 2: VoLTE Voice-Only Call

Validating VoLTE 4.

UE1 selects “Ignore” action

5.

UE1 sends 486 Busy Here, which propagates to TAS; TAS will initiate INVITE, which is routed through S-CSCF to voice mail system

6.

UE3 receives 183 Session Progress with SDP Answer: 183 Session Progress SDP audio=AMR-WB, AMR

7.

UE3 responds with PRACK

8.

A voice prompt is played to UE3 indicating to record voice message after the signal

9.

At this stage RTP voice packets are sent both ways between UE3 and voice mail system. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)

10. On hangup UE2 receives BYE and UE1 receives 200 OK

Results 1.

UE1 receives INVITE with SDP Offer: audio=AMR-WB, AMR

2.


3.

UE3 receives 183 Session In Progress with SDP Answer: audio=AMR-WB, AMR

4.

RTP packets are sent using Dedicated Bearers (QCI=1,GBR)


85

Validating VoLTE

Test Case 19: Handover During VoLTE Voice-Only Call Description This test case explores user VoLTE 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.


Test Steps

86

1.

UE1 calls UE2 successfully establishing SIP call and RTP packets are sent and received on Dedicated Bearer (QCI=1)

2.

After 90 seconds UE1 provides RRC Measurement Reports that detail better reception of Sector C than Sector A

3.

The eNodeB then directs UE1 to perform a handover across these sectors by sending RRC Connection Reconfiguration (Handover Command)

4.

UE1 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 Chapter 8: Section 2: VoLTE Voice-Only Call

Validating VoLTE 5.

A DRB is established successfully between UE1 and target eNodeB

6.

Voice call continues for 30-60 seconds more

7.

UE1 ends the call by sending BYE; UE2 responds with 200 OK

Results 1.

UE1 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


87

Validating VoLTE

Test Case 20: DTMF Tone Handling Description Here the user accepts and responds with DTMF during a VoLTE call.

Initial State 1.

UE1 is VoLTE Registered

Test Steps 1.

UE1 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

88


Validating VoLTE 2.


3.


4.


5.

UE2 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). UE1 and UE2 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)

9.

•

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)

UE1 on hangup initiates a BYE

10. UE2 responds with 200 OK 11. UE1 receives 200 OK


89


DTMF are correctly decoded at UE1

2. DTMF are correctly sent by UE1

90


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.

UE1 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.

UE1 received the DNS address and the dedicated P-CSCF IP addresses from P-GW

Test Steps 1.

UE1 sends a REGISTER to P-CSCF, which forwards it through IMS network to S-CSCF

2.

UE1 receives 401 UNAUTHORIZED challenge: SIP 401 Challenge Random challenge (RAND) Network authentication token (AUTN) Authentication scheme (IMS authentication and key agreement AKA)

3.

UE1 sends a second REGISTER with calculated response (RES) based on a shared secret and previously received RAND

4.

UE1 receives a SIP 200 OK response from the S-CSCF routed back via IMS proxyservers

Results 1.

UE1 successfully receives 401 with Random Challenge (RAND) and AKA fields

2.

UE1 successfully receives SIP 200 OK


91

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.

UE1 has completed an emergency registration

Test Steps 1.

UE1 sends INVITE with Emergency Service URN (Uniform Resource Name): INVITE urn service:sos

2.

UE1 receives 200 OK and responds to P-CSCF with ACK

Results 1.

92

UE1 successfully receives 200 OK


Validating VoLTE


93

Chapter 9 Section 3: VoLTE 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.

Chapter 9: VoLTE Test Case Section 3: Video and SMS

95

Validating VoLTE

Test Case 23: VoLTE Send SMS Description This scenario describes an SMS scenario between VoLTE-enabled UEs.

Initial State 1.


2.


Test Steps 1.

UE1 sends MESSAGE request to UE2: MESSAGE Content-Type=application/vnd.3gpp2.sms, SMS encapsulated SMS P2P

96

2.

UE1 receives 200 OK

3.

UE2 receives MESSAGE request

4.

UE2 sends 200 OK

5.

UE1 receives Delivery ACK for MESSAGE request

6.

UE1 sends 200 OK



UE2 receives MESSAGE request

2.

UE1 receives Delivery ACK for MESSAGE request


97

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.

Chapter 10: Section 4: VoLTE Video and Voice Call

99

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.

100


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 content’s 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.


101

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 •

UE1 is EPS attached and has the default bearer activated for VoLTE APN

•

UE1 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:[email protected] audio video

2.

The rest of the steps are similar with those for an IR.92 only UE registration; see Test Case 2

Results

102

1.

UE1 successfully receives 401 with Random Challenge (RAND) AKA

2.

UE1 successfully receives SIP 200 OK


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.


2.


Test Steps 1.

UE1 sends SIP INVITE message containing SDP offer (UE1’s IP address and ports for bi-directional audio and video media) to P-CSCF

2.


3.


4.


5.

UE2 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


103

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 UE2

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

6.

104

•


•

Maximum acceptable DF is between 9 and 50ms

•

Maximum acceptable MLR = 0.0005

Successful teardown of the call by UE1, BYE is responded with 200 OK


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.


2.


Test Steps 1.


2.


3.


4.


5.


6.

SIP call is established, RTP streaming starts and lasts for 2 minutes. Voice and video dedicated bearers are configured at this stage


105

Validating VoLTE 7.

UE1 sends BYE

8.


Results 1.

106



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.


2.


Test Steps 1.


2.


3.


4.


5.



107

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.

UE2 sends BYE

8.


Results 1.

108



Validating VoLTE

Test Case 28: Change of Video Parameters Description During a call, UE1 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.


2.

A video call is established between UE1 and UE2, AMR-WB and H.264 are used

Test Steps 1.

UE1 sends UE2 Re-INVITE with SDP Offer

2.

UE2 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 UE2 ends the call by sending BYE to UE1

5.



109


110

1.

UE2 receives Re-INVITE with SDP Offer containing new video (H.264) parameters

2.

UE1 receives 200 OK

3.

UE1 receives BYE

4.

UE2 receives 200 OK


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.


2.

A video call is established between UE1 and UE2 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.

UE1 sends RE-INVITE to UE2 with SDP Offer: RE-INVITE SDP m=video RTP/AVP 21 a=recvonly

1.

UE2 accepts stream stop and sends 200 OK with SDP Answer: 200 OK SDP m=video RTP/AVP 21 a=sendonly


111

Validating VoLTE 2.

RTP video media stream from UE1 to UE2 stops. Between UE1 and UE2 exists a 2-way voice call and a video stream from UE2 to UE1

3.

Call is maintained for 3 minutes

4.


5.

UE2 responds with 200 OK, which reaches UE1

Results

112

1.

UE1 sends RE-INVITE to close video

2.

UE1 receives a 200 OK

3.

Voice continues between UE1 and UE2

4.

RTP video packets are sent from UE2 to UE1 only


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.


2.


3.

RTP media packets are using Dedicated Bearers (QCI=1, GBR for voice and QCI=2, GBR for video)

Test Steps 1.

UE3 initiates a video call to UE1 and sends INVITE with SDP Offer: INVITE SDP audio=AMR-WB, AMR video=H.264


113

Validating VoLTE 2.


3.


4.

UE1 sends 486 Busy Here, which propagates to TAS; TAS will initiate INVITE, which is routed through S-CSCF to voice mail system

5.


6.

UE3 responds with PRACK for reliability

7.

A voice prompt is played to UE3, which can deposit his voice only message after the signal

8.

At this stage RTP voice packets are sent both ways between UE3 and voice mail system. RTP voice media packets are using dedicated bearer (QCI=1 and GBR)

9.

On hangup UE2 receives BYE and UE1 receives 200 OK

Results 1.

UE1 receives INVITE with SDP Offer: audio=AMR-WB, AMR video=H.264

2.


3.

UE3 receives 183 Session Progress with SDP Answer: audio=AMR-WB, AMR

114


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.


2.


Test Steps 1.

UE1 sends INVITE to UE2 with SDP offer: INVITE SDP video=H.264 audio=AMR-WB, AMR

2.

UE2 displays incoming call notification as “Video Call” and prompts user with options to “Accept Video Call”, “Accept Voice-Only”, “Ignore”

3.

UE2 responds with 180 Ringing, which is propagated back through IMS network to UE1

4.

UE1 sends PRACK to UE2 for reliability


115

Validating VoLTE 5.

UE2 user selects “Accept Voice-Only” and UE2 sends 200 OK to UE1 with HD voice only SDP answer (no video support): 200 SDP video=port 0 audio=AMR-WB

6.

UE1 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.


9.


Results

116

1.

UE2 sends 200 OK for voice only

2.

UE1 receives 200 OK to Invite process assigned for voice only


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.


2.

A VoLTE voice call has been setup between UE1 and UE2 and RTP voice streams are exchanged between user devices on a dedicated bearer (QCI=1 and GBR)

Test Steps 1.

UE2 sends Re-INVITE to UE1 with voice and video SDP offer: Re-INVITE SDP video=H.264 audio=AMR-WB

2.

UE1 accepts request to upgrade the call with video support and sends 200 OK: 200 OK SDP video=H.264 audio=AMR-WB


117

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.


6.


Results

118

1.

UE1 receives Re-INVITE

2.

UE2 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)


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.


2.

A VoLTE voice call has been setup between UE1 and UE2 and RTP voice streams are exchanged on dedicated bearer (QCI=1 and GBR) between these users

Test Steps 1.


2.

UE1 ignores display message to upgrade the call with video

3.

Call upgrade times out and TAS sends CANCEL to UE1

4.



119

Validating VoLTE 5.

UE1 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 UE2

7.

Voice call continues and is maintained for 3 minutes

8.


9.


Results

120

1.


2.

UE1 sends 487 Request Terminated to P-CSCF

3.

UE2 receives 603 Decline


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.


2.

A VoLTE voice call has been setup between UE1 and UE2 and RTP voice streams are exchanged between user devices on a dedicated bearer (QCI=1 and GBR)

Test Steps 1.


2.

UE1 rejects option to upgrade to a video call and sends 603 Decline, which is propagated back to UE2

3.

Voice only call continues for 3 minutes

4.


5.



121


122

1.


2.

UE2 receives 603 Decline


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.

UE1 and UE2 are VoLTE Registered and available.

Test Steps 1.

UE1 calls UE2 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 UE1 provides RRC Measurement Reports that detail better reception of Sector C than Sector A

3.

The eNodeB then directs UE1 to perform a handover across these sectors by sending RRC Connection Reconfiguration (Handover Command)

4.

UE1 performs a RACH procedure on the target sector/eNodeB


123

Validating VoLTE 5.

UE1 sends a RRC Connection Reconfiguration Complete message to the target eNodeB on success

6.

A DRB is established successfully between UE1 and target eNodeB

7.

Call continues for 30-60 seconds more

8.

UE1 ends the call by sending BYE. UE2 responds with 200 OK

Results

124

1.

UE1 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. •


•


•


6.

Voice stream Packet Loss < 0.001

7.

Voice stream Jitter unaffected


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.


2.


3.

RTP media packets are using dedicated bearer (QCI=1, GBR for voice and QCI=2, GBR for video)

Test Steps 1.

UE3 initiates a video call to UE1 and sends INVITE with SDP Offer: INVITE SDP Offer audio=AMR-WB, AMR video=H.264

2.


3.


4.



125

Validating VoLTE 5.

UE1 accepts the video call from UE3 and sends Re-INVITE with SDP Offer to UE2, which is put on “Hold”: Re-INVITE SDP audio=sendonly

6. UE2 sends 200 OK with SDP Answer to UE1: 200 OK SDP audio=recvonly

7.


8.

Audio streams between UE1 and UE2 are put on Hold

9.

UE1 sends 200 OK with SDP Answer to UE3: 200 OK SDP audio=AMR-WB

10. At this point RTP voice and video streams are exchanged between UE1 and UE3 on Dedicated Bearers (QCI=1, GBR for voice and QCI=2, GBR for video); video call between UE1 and UE3 takes 30 seconds 11. UE1 hangs-up video call with UE3 and sends BYE to UE3 12. UE3 responds with 200 OK 13. UE1 switches back to the video call with UE2 by sending UE2 RE-INVITE with SDP offer to UE2: RE-INVITE SDP audio=sendrecv video=sendrecv

14. UE2 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 UE1 and UE2 on Dedicated Bearers (QCI=1, GBR for voice and QCI=2, GBR for video); the call takes 60 seconds 16. UE1 on hangup initiates a BYE 17. UE2 responds with 200 OK

126



UE1 receives the INVITE from UE3

2.

UE1 receives the 200 OK with SDP Answer from UE2


127

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.


2.


3.

RTP media packets are using Dedicated Bearers (QCI=1 and GBR for voice, QCI=2 and GBR for video)

Test Steps 1.

UE3 initiates a video call to UE1 and sends INVITE with SDP Offer: INVITE: SDP Offer video=H.264 audio=AMR-WB, AMR

128

2.


3.


4.

UE1 responds to PRACK with 200 OK


Validating VoLTE 5.

UE1 accepts the video call from UE3 and sends Re-INVITE with SDP Offer to UE2, which is put on “Hold”: Re-INVITE: SDP audio=sendonly video=sendonly

6.

UE2 sends 200 OK with SDP Answer to UE1: 200 OK: SDP Answer: SDP: audio=recvonly video=recvonly

7.


8.

Audio and video streams between UE1 and UE2 are put on Hold

9.

UE1 sends 200 OK with SDP Answer to UE3: 200 OK SDP video=H.264 audio=AMR-WB

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

14. UE2 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 UE1 and UE2 on a dedicated bearer (QCI=1 and GBR); video call takes 60 seconds 16. UE1 on hangup initiates a BYE 17. UE2 responds with 200 OK, which reaches UE1


129


130

1.


2.



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.


2.


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.

UE3 initiates a video call to UE1 and sends INVITE with SDP Offer: INVITE SDP audio=AMR-WB, AMR video=H.264

2.



131

Validating VoLTE 3.


4.

UE1 sends 486 Busy Here, which propagates to TAS; TAS initiates INVITE, which is routed through S-CSCF to voice mail system

5.


6.


7.

A voice prompt is played to UE3, which can deposit a voice message after the signal

8.

At this stage, RTP voice packets are sent both ways between UE3 and voice mail system; RTP voice media packets are using dedicated bearer (QCI=1 and GBR)

9.

On hangup UE2 receives BYE and UE1 receives 200 OK

Results 1.

UE1 receives INVITE with SDP Offer: audio=AMR-WB, AMR video=H.264

2.


3.

UE3 receives 183 Session Progress with SDP Answer: audio=AMR-WB, AMR

132


Validating VoLTE


133

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.

Chapter 11: Section 5: Advanced VoLTE Testing

135

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.


2.

A voice call is established between UE1 and UE2; RTP voice packets are sent both ways

Test Steps 1.

UE1 puts UE2 on hold by sending Re-INVITE with SDP Offer: Re-INVITE m=audio

a=sendonly

2.

UE2 responds with 200 OK with SDP Answer: m=audio

a=recvonly

3.

136

UE1 sends ACK to UE2


Validating VoLTE 4.

UE1 establishes a voice call with UE3

5.


a=sendonly

6.

UE3 responds with 200 OK with SDP Answer

7.


8.

UE1 creates a conference by sending INVITE to conference URI, with SDP Offer: INVITE

m=audio

a=sendrecv

9.

UE1 receives 200 OK with SDP Answer from the Media Server

10. UE1 sends ACK 11. At this moment an active RTP path for voice is created between UE1 and Media Server 12. UE1 sends SUBSCRIBE to TAS 13. UE1 receives 200 OK from TAS 14. TAS sends NOTIFY to UE1 for current conference events 15. UE1 invites UE2 to conference by sending REFER request 16. The REFER request contains REFER TO header that indicates UE2 and REPLACE header indicating that this REFER request will replace UE1 to UE2 call leg 17. UE1 receives 202 Accepted to acknowledge REFER request 18. UE1 receives NOTIFY with the status of ‘REFER’ 19. UE1 sends 200 OK 20. UE2 receives INVITE without SDP 21. UE2 answers with 200 OK with SDP Offer that includes media codec set that was utilized in the initial call with UE1 22. UE2 receives ACK with SDP Answer


137

Validating VoLTE 23. At this moment an active RTP path for voice is created between UE2 and Media Server 24. UE1 receives NOTIFY about successfully performed joining to conference 25. UE1 sends 200 OK 26. UE1 receives NOTIFY about UE2 successfully joined the conference 27. UE1 sends 200 OK 28. UE1 disconnects the dialog between UE1 and UE2 by sending BYE 29. UE1 invites UE3 to conference by sending REFER request 30. The REFER request contains REFER TO header that indicates UE3 and REPLACE header indicating that this REFER request will replace UE1 to UE3 call leg 31. UE1 receives 202 Accepted to acknowledge REFER request 32. UE1 receives NOTIFY with the status of ‘REFER’ 33. UE1 sends 200 OK 34. UE3 receives INVITE without SDP 35. UE3 answers with 200 OK with SDP Offer that includes media codec set that was utilized in the initial call with UE1 36. UE3 receives ACK with SDP Answer 37. At this moment an active RTP path for voice is created between UE3 and Media Server 38. UE1 receives NOTIFY about successfully performed joining to conference 39. UE1 sends 200 OK 40. UE1 receives NOTIFY about UE3 successfully joined the conference 41. UE1 sends 200 OK 42. UE1 disconnects the dialog between UE1 and UE3 by sending BYE 43. RTP voice media packets are exchanged in both ways between each UE and the Media Server

138


Validating VoLTE 44. RTP voice packets are using Dedicated Bearers (QCI=1, GBR) 45. UE1 ends the conference call by sending BYE 46. UE2 and UE3 receive BYE and respond with 200 OK 47. UE1 receives 200 OK

Results 1.

UE1 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


139

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.


2.

A video call is established between UE1 and UE2; RTP voice and video packets are sent in both ways between UE1 and UE2

Test Steps 1.


a=sendonly m=video

a=sendonly

140


Validating VoLTE 2.

UE2 responds with 200 OK with SDP Answer: m=audio

a=recvonly m=video

a=recvonly

3.


4.

UE1 establishes a voice call with UE3

5.


a=sendonly m=video

a=sendonly

6.

UE3 responds with 200 OK with SDP Answer

7.


8.

UE1 creates a conference by sending INVITE to conference URI, with SDP Offer: INVITE

m=audio

a=sendrecv m=video

a=sendrecv

9.

UE1 receives 200 OK with SDP Answer from the Media Server

10. UE1 sends ACK 11. At this moment an active RTP path for voice and video is created between UE1 and Media Server 12. UE1 sends SUBSCRIBE to TAS 13. UE1 receives 200 OK from TAS 14. TAS sends NOTIFY to UE1 for current conference events 15. UE1 invites UE2 to conference by sending REFER request 16. The REFER request contains REFER TO header that indicates UE2 and REPLACE header indicating that this REFER request will replace UE1 to UE2 call leg


141

Validating VoLTE 17. UE1 receives 202 Accepted to acknowledge REFER request 18. UE1 receives NOTIFY with the status of ‘REFER’ 19. UE1 sends 200 OK 20. UE2 receives INVITE without SDP 21. UE2 answers with 200 OK with SDP Offer that includes media codec set that was utilized in the initial call with UE1 22. UE2 receives ACK with SDP Answer 23. At this moment an active RTP path for voice is created between UE2 and Media Server 24. UE1 receives NOTIFY about successfully performed joining to conference 25. UE1 sends 200 OK 26. UE1 receives NOTIFY about UE2 successfully joined the conference 27. UE1 sends 200 OK 28. UE1 disconnects the dialog between UE1 and UE2 by sending BYE 29. UE1 invites UE3 to conference by sending REFER request 30. The REFER request contains REFER TO header that indicates UE3 and REPLACE header indicating that this REFER request will replace UE1 to UE3 call leg 31. UE1 receives 202 Accepted to acknowledge REFER request 32. UE1 receives NOTIFY with the status of ‘REFER’ 33. UE1 sends 200 OK 34. UE3 receives INVITE without SDP 35. UE3 answers with 200 OK with SDP Offer that includes media codecs set that was utilized in the initial call with UE1 36. UE3 receives ACK with SDP Answer 37. At this moment an active RTP path for voice and video is created between UE3 and Media Server 38. UE1 receives NOTIFY about successfully performed joining to conference 39. UE1 sends 200 OK 40. UE1 receives NOTIFY about UE3 successfully joined the conference 142


Validating VoLTE 41. UE1 sends 200 OK 42. UE1 disconnects the dialog between UE1 and UE3 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. UE1 ends the conference call by sending BYE 47. UE2 and UE3 receive BYE and respond with 200 OK 48. UE1 receives 200 OK

Results 1.

UE1 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


143

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.


2.


Test Steps 1.

Another application is opened on UE2; UE2 sends a Re-INVITE to UE1; SDP media description for video has attribute set to “sendonly”: m=video RTP/AVP 21 a=sendonly

2.

UE1 replies with 200 OK: video=H.264 a=recvonly

audio=AMR-WB

3. 144

The video stream is stopped from UE1 to UE2 Chapter 11: Section 5: Advanced VoLTE Testing

Validating VoLTE 4.

UE2 returns to VoLTE application and sends Re-INVITE to UE1 with SDP Offer: m=video RTP/AVP 21 a=sendrecv

5.

UE1 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 UE1 and UE2

Results 1.

UE1 receives Re-INVITE with “sendonly” attribute for video

2.

UE1 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: •


•


•



145

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.

UE1... UE200 are VoLTE Registered

2.

Video calls are established between UE1 and UE101… UE100 and UE200 and is ongoing

Test Steps

146

1.

UE1...100 initiate video calls to UE101...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



Monitor voice and video quality MOS score > 4.1

2.

Media one-way delay under 150ms


147

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

Chapter 12: Section 6: Real-World VoLTE Subscriber Modeling

149

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.

UE1.. UE1000 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

150

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 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.


Test Steps 1.


2.

Successful UEs immediately start IMS Registration

Results 1.

Successful handling of Attach Storm with UEs backing off •

2.

a) Actual attach rate < 100/s

IMS Registrations sustained at Attach rate


151

Validating VoLTE

Test Case 45: High-Density Financial District Description Extensive smart phone use and VoLTE operation occur in this model.

Initial State 1.


2.


3.


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 •

152

Each VoLTE call has a voice and video MOS of “Excellent”


Validating VoLTE

Test Case 46: Rush Hour Commuter Traffic Description This scenario emulates commuters making VoLTE calls that include extensive mobility.

Initial State 1.


2.


3.


Test Steps 1.


2.

All UEs eNodeB handover every 4 minutes •

3.

Back and forth between 2 UEs or round patterns over multiple eNodeBs

Idle and connected mobility – HO (Inter/Intra) and TAU

Results 1.

Rotating 250 UEs successfully complete 10 minute VoLTE calls •

2.

Each VoLTE call has a voice MOS of “Excellent”

Each UE hands-over successfully without a failure


153

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.


2.


3.


Test Steps 1.

Rotating 300 UEs initiate 1 minute HTTP download

2.

Rotating 100 UEs initiate 10 minute FTP download

3.


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 •

154

Each VoLTE call has a voice and video MOS of “Excellent”


Validating VoLTE


155

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. It’s both hard to know when you’ve built and optimized it well, and it’s even harder to know why it’s 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

Chapter 13: Monitoring Challenges, Solutions and Best Practices

157

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.

Internet Optimum Level Network Performance Monitor

Intrusion Detection System

App Performance Monitor

Network

Network Data Recorder

Network Analyzer

Server Farm

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: •

158

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.



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.


159


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.

Internet

Ixia Anue Net Tool OptimizerTM Optimum Level Network Performance Monitor

Intrusion Detection System

App Performance Monitor

Network

Network Data Recorder

Network Analyzer

Server Farm

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 network’s DMZ may require analysis. The NTO’s 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.

160



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.


161

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 HSS S1-MME

MME

LTE-Uu

S11

S1-U

Gx S5/S8

S-GW

eNodeB

PCRF SGi

Rx Operator’s IP Services (for example, IMS, PSS)

P-GW

Ixia Anue Net Took Optimizer®

Monitoring probes

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 Chapter 14: Best Practices for Monitoring VoLTE in EPCs

163

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 HSS S1-MME LTE-Uu

S11

MME S1-U

Gx S5/S8

S-GW

eNodeB

PCRF SGi

Rx Operator’s IP Services (for example, IMS, PSS)

P-GW

Ixia Anue Net Took Optimizer®

Monitoring probes

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:

164

•

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.

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 Chapter 14: Best Practices for Monitoring VoLTE in EPCs

165

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 (# of Register transactions with failure status codes) ratio 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 166


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


167

Chapter 15 Ixia VoLTE Test Solutions

Validating VoLTE

CHAPTER 15

Ixia VoLTE Test Solutions Ixia’s 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, Ixia’s solutions test the functionality, scalability, and resiliency of LTE infrastructure components and new IMS networks that support VoLTE-based services. Ixia’s 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

Chapter 15: Ixia VoLTE Test Solutions

169

Validating VoLTE

IxLoad Access Ixia’s 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:

170

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


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


171

Validating VoLTE IxLoad’s 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

172


Validating VoLTE

Wireless Triple-Play Bundle Ixia’s 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. Ixia’s 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


173

Validating VoLTE

Xcellon-Ultra NP Load Module Ixia’s 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. XcellonUltra NP’s 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

174


Validating VoLTE

XAir Module Ixia’s XAir module is the next-generation hardware for LTE UE emulation. It delivers unparalleled LTE performance in the smallest footprint, providing the industry’s highest UE density. This module allows LTE Advanced feature support. With Ixia’s 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 Ixia’s 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


175

Validating VoLTE

r10 Wideband Radio Head Ixia’s 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

176

•

Handles LTE UE radio modulation from 690 to 2690 MHz

•

FDD or TDD LTE technologies

•

Supports 5/10/15/20 MHz channel bandwidths


Validating VoLTE

High-Performance Chassis Ixia’s VoLTE test solutions are powered by three chassis options:

Chassis

Photo

Description XG12 is Ixia’s latest chassis technology, and is the test and measurement industry’s highest port density test system for Ethernet.

XG12

•

12 Slots

•

Size: 19”w x 19.21”h x 27.2”d (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 High Performance features the highest port density and performance in the industry for lab-based, rack-mounted operation. •

12 Slots

•

Size: 17.7”w (19.0”w including rack ears ) x 17.5”h x 21.0”d (45.5cm x 44.5cm x 53.3cm)

•

83 lbs. (37.65 kg) empty, 88 lbs. (39.92 kg) average shipping weight

•


•

UL and CE safety approval certifications; valid when the unit is operating from 200-240VAC mains

XM12


177

Validating VoLTE XM2 is ideal for desktop testing, smaller scale tests, and remote monitoring. •

2 Slots

•

Size: 14”w (19.0”w including rack ears) x 4.5”h x 19.25”d (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

•


XM2

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:

178

•

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


Validating VoLTE

Ixia Hardware Configuration for VoLTE Testing Carriers can configure Ixia’s modular VoLTE test platforms to suit their current needs while offering a simple path to grow their system as services expand. Ixia provides the industry’s highest density of UE emulation – up to 6000 UEs in one XG12 chassis. Ixia’s 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 XcellonUltra NP load modules, and three r10 radio head module supports 3000 connected UEs.


179

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.

180


Validating VoLTE


181

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 IPbased 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

182

References

VoLTE Book

Recommend Documents