White Paper

This white paper describes the requirements for VoLTE testing and monitoring as well as the phases of service deployment activities. It covers the lab validation phase during which EXFO’s Hawk family of analyzers (for interoperability testing) and the QualityAssurer series simulators (for functional testing) are used.

1. ExEcutivE OvErviEwVoice-over-LTE (VoLTE) is an essential technology transformation for mobile network operators (MNOs) once they deploy LTE. Major reasons for this transformation include the ability to:

› Introduce new services around unified communications and video capabilities

› Monetize the over-the-top (OTT), like communication services for new devices such as tablets

› Migrate voice traffic from more expensive 2G/3G networks to LTE to reduce the unit cost of serving traffic

The most challenging part of introducing VoLTE is providing traditional voice telephony service using packet bearers offered by LTE. Unlike for yet-to-be-introduced services, customers have very high expectations when it comes to traditional voice service, since it has been part of their mobile service for decades. It must offer high media quality. It must perform well under mobility and temporary congestion scenarios (e.g., subway station, crowded events). VoLTE must be able to seamlessly support other traditional supplementary services like multiparty conferencing and call-waiting. It must provide features to both post-paid and pre-paid customers as well as handle the effects of roaming. It must support regulatory features such as lawful intercept, emergency calls and priority calling. All of these are fundamental capabilities that VoLTE must provide for a seamless transition from 2G/3G circuit-switched voice service.

In order to successfully introduce VoLTE service, MNOs must implement rigorous testing and validation as well as enable network-wide monitoring and troubleshooting capabilities. EXFO’s product portfolio can help MNOs at each step:

› Lab validation: MNOs can use EXFO’s single simulator platform family, the QA-805, QA-813 and QA-604, to validate the IP multimedia service (IMS) and EPC infrastructures they will be deploying to support VoLTE. In the lab environment, EXFO’s PowerHawk Multi-User Analyzer can be used to monitor multiple interfaces simultaneously and correlate user and signaling traffic across them. The lab validation phase typically addresses both device and network interoperability testing, as well as network element robustness, capacity, functionality and interoperability testing objectives.

› Integration and deployment: EXFO’s M5 Software Analyzer can be used in the field-trial phase when MNOs want to determine the capabilities of the new VoLTE network elements and interfaces. When trials go to the full deployment phase, MNOs can rely on the PowerHawk Pro Distributed Analyzer platform to analyze live networks in real time.

› 24/7 service quality monitoring: EXFO’s BrixCall and PowerHawk Pro solutions provide a round-the-clock view of both VoLTE user and signaling traffic. These two platforms converge to a common user interface allowing full integration of both voice and other media analysis along with related IMS and LTE signaling across RAN, EPC and IMS core networks.

› Network troubleshooting: MNOs can use a TravelHawk Pro with M5 monitoring and distributed analysis tools, like BrixCall and PowerHawk Pro, to troubleshoot live network issues.

In this paper, we will be focusing on the lab validation phase during which interoperability between new VoLTE devices and the functional testing of new network elements are performed. Our primary objective is to emphasize the importance of this early phase for the eventual commercial success of VoLTE deployment. We will be publishing papers on how EXFO’s solutions will help VoLTE field trials, network rollout and 24/7 monitoring in the very near future.

2. voLtE DEvicE anD nEtwOrk ELEmEnt iOt

2.1 Use Case Testing interoperability between user equipment (UE) and various network elements is the first step an MNO must take in order to introduce this service. The MultiService Forum (MSF) has identified a set of test cases that apply to basic VoLTE interoperability testing. These include:

› Attach/Detach per UE to an evolved packet core (EPC) via eNodeB (eNB)

› Create/Delete a default bearer with related quality of service (QoS) using a policy control framework

› IMS registration

› IMS session establishment and teardown using a default bearer with related quality of service (QoS) using policy control framework

› MMTel service configuration and usage

voLtE testing and monitoring – Lab validation PhaseMurat Bilgic, Advisor, CTO Office; Tommi Tallgren, M5 Product Manager; Gerold Haase, Sales Specialist; Khanh Nguyen, Product Specialist; Marko Falck, Manager, Mobile Operator Solutions

© 2013 EXFO Inc. All rights reserved.

White Paper

In addition to this list, it is possible to add intra-LTE handover test cases to demonstrate:

› Active sessions over mobility between eNodeBs

› Active sessions during MME relocation

› Active sessions during S-GW relocation

Depending on the maturity of the MNO’s LTE deployment as well as the use of IMS technology in their core network, MNO teams can target some or all of these test cases. Typically, this phase is seen as a learning opportunity for various technology, engineering and operations teams within an MNO.

2.2 Testing Requirements

VoLTE interoperability testing requires the following network setup.

The fi rst two steps of interoperability testing may be trivial for an MNO whose LTE network is already operational. However, for those who are building their LTE networks and validating the basics of VoLTE, it is imperative to validate the successful attachment and creation of a default bearer. This requires UE signaling to eNodeB through Uu interface, communicating with EPC elements, authenticating through HSS and setting up an end-to-end LTE default bearer to carry IMS signaling. In order to ensure end-to-end IP QoS for VoLTE, all components must interoperate; signaling and user voice traffi c (RTP media) need to be mapped to the correct, assigned QoS class identifi er (QCI). The interaction between P-GW and PCRF will set the right levels of QoS.

The next step in interoperability testing is to validate IMS registration and session establishment between UE, IMS core network elements and MMTel AS while relying on the PCRF for policy control settings for bearer characteristics per the IR.92 specifi cation. Once the IMS session is established, UE and MMTel AS complete the MMTel session confi guration over the Ut interface, end to end.

The primary objective of these tests is to ensure that the UE and network elements interoperate successfully. This is done to complete the stages of signaling and establish a bearer to carry user voice traffi c over RTP between two UEs.

Another set of interoperability test cases involves maintaining IMS sessions while mobility events between eNodeBs, MMEs or S-GWs are observed.

Figure 1. VoLTE interoperability testing setup.

© 2013 EXFO Inc. All rights reserved.

White Paper

2.3 Test SolutionVoLTE interoperability testing typically takes place in the MNO lab environment, where network equipment belonging to one or more vendors are brought together with the necessary UEs, other traffi c generators, protocol analyzers and protocol simulators. Analyzers are used to monitor signaling and user traffi c. Simulators can be used in situations where a platform is not readily available or does not support a particular protocol version.

It is essential for the tester to see the network behavior in real-time and for test systems to illustrate and report the test results. Since the test environment (test network) will be used by multiple engineers, the analysis tool must be able to provide simultaneous access to multiple groups. EXFO’s PowerHawk can satisfy this need by allowing up to 10 simultaneous users.

End-to-end VoLTE IOT testing requires all eUTRAN and EPC interfaces to be analyzed. In order to analyze LTE signaling, the following interfaces are mandatory:

› S1-MME (session management analysis)

› S6a (deciphering keys, authentications)

› S11 (session signaling)

› X2 for handovers

The IMS signaling from S1-U (SIP/RTP/RTCP) also needs to be seamlessly correlated to the LTE session signaling. Pure packet core/IMS interfaces are also needed for true end-to-end analysis, including analysis of S5/8, SGi, Gx and IMS interfaces, including Rx, Mw, ISC, Sh, Cx.

Passive analysis with EXFO’s PowerHawk includes the full analysis of all LTE and SIP signaling over all interfaces. Protocol support includes 3GPP baselines support from REL8 to REL10. Session analysis has full correlation over all interfaces and natural deciphering capabilities. The VoLTE user plane (SIP/RTP/RTCP) is analyzed at session level with MOS/Rfactor as well as with details. EXFO’s M5/PowerHawk solution for the VoLTE IOT is capable of handling line-rate user plane and up to thousands of calls per second for signaling.

The image below illustrates a practical test-environment setup for VoLTE IOT.

Figure 2. EXFO’s test architecture for real-time analysis of VoLTE IOT.

© 2013 EXFO Inc. All rights reserved.

White Paper

The two diagrams below illustrate the capabilities of the analyzer software. In the first one, we can see the session level view that allows the user to analyze the SIP signaling and RTP media quality (in terms of mean opinion score). The second shows the deep-dive analysis capabilities of the analyzer that allows the user to go to a packet and information element level of detail.

Figure 3. VoLTE session analysis and correlations.

Figure 4. VoLTE message flow of one session in Message Sequence Chart and Detailed Decoding views from M5 Client.

© 2013 EXFO Inc. All rights reserved.

White Paper

3. FunctiOnaL tEsting OF voLtE nEtwOrk ELEmEnts

3.1 Use Case VoLTE requires the implementation of new IMS network elements and the integration with existing 2G/3G infrastructure, policy control framework as well as external networks such as GRX, PSTN and IN. Each of these integrations requires testing the functionality of new network nodes and the new functionalities of existing network nodes.

3.2 Testing RequirementsFor each implementation under test (IUT), different factors need to be considered for functional testing:

› eNodeB: Primary test activity that applies to scheduling capabilities, especially how traffic belonging to various QCI levels is treated.

› MME: Primary test activity that applies to testing the new SGs (signaling for SMS over IP as well as CSFB) and Sv (signaling for inter-technology voice handovers) interfaces. It will also be important to validate the robustness of handling signaling in MME reload scenarios.

› S-GW: Primary test activity that applies to the traffic handling capabilities of real-time services, like voice under load and the robustness of handling voice traffic (both IMS signaling and RTP media) in S-GW reload scenarios.

› P-GW: Primary test activity that applies to the traffic handling capabilities of real-time services like voice under load.

› HSS: Primary test activity that applies to testing the new IMS interfaces Rx (P-CSCF), Cx (I/S-CSCF) and Sh (MMTel AS) elements and handling the load capabilities resulting from additional signaling traffic introduced by IMS elements.

› CSCF nodes: Since these are typically new nodes, they need to be tested via all signaling interfaces as well as their load handling and robustness capabilities.

› MMTel AS: This new node has to be tested via its signaling interfaces and its user traffic (RTP media) capabilities. Its robustness under load and various network failure scenarios also need to be validated.

Network equipment manufacturers (NEMs) are the primary users of element functional testing. Throughout the development lifecycle, they subject their equipment to levels of testing that require scale, test coverage and a high level of automation along with reporting capabilities. Since networks are typically built from equipment provided by different NEMs, they need to test their portion in their own labs while emulating the rest of the network components.

For MNOs, the functional testing of every component may be a heavy burden. For this reason, they are strongly encouraged to perform the risk analysis of the network components that they are deploying and identify the critical elements that require functional testing, rather than rely on supplier test results. For example, HSS has a large impact on LTE service availability. Furthermore, when VoLTE is deployed, the signaling load on HSS will increase substantially. Throughout 2011 and in early 2012, we witnessed major MNO service disruptions due to HSS problems in North America and Japan. Running a functional test along with a load stress test will give an MNO the opportunity to prepare plans to deal with critical network node unavailability. This would include monitoring and recording the behavior of other network nodes.

3.3 Test SolutionGiven the high number of elements found in a VoLTE network, we are not going to cover each one separately. Instead, we will give two examples that show how EXFO’s simulators can be used to test new IMS network elements and the impact of VoLTE on eNodeB.

New IMS network elements P-CSCF, I-CSCF and S-CSCF are essential pieces in the IMS network because they select the right AS for a phone call. P-CSCF interacts with the EPC through the SGi interface, while UE communicates with the P-CSCF (logically) via the Gm interface using SIP. AS interfaces with HSS through the Sh interface to exchange subscriber profile, location and loading information using DIAMETER protocol. I/S-CSCF communicates with HSS through the Cx interface using DIAMETER protocol. The following diagram shows how EXFO’s QA-805 platform can be used to test the behavior of IMS Core and AS in one setup as well as I-CSCF and S-CSCF testing in a different setup.

© 2013 EXFO Inc. All rights reserved.

White Paper

Other IMS Core

IMS Core(P/I/S-CSCF)

Application Servers

Application Servers

IMSEndpoints

IMS TestTraffic

IMS TestTraffic

hssFlex

sipFlex

Other IMS Core

IMS TestIMS TestIMS TestTraffic

IMS TestIMS TestTrafficTrafficTraffic

hssFlexhssFlexhssFlexhssFlex

HSS

Application ServersServersServers

(I/S-CSCF)

IMSEndpoints

IMS TestTraffic

IMS TestTraffic

hssFlex

sipFlex

proxyFlex

hssFlexhssFlex

HSS

sipFlex

proxyFlex

P-CSCF

IUTproxyFlex

Other IMS Core

In the setup on the left, the entire IMS core is tested by emulating SIP clients using sipFlex and emulating HSS with the hssFlex software on QA platform. In this setup, we can emulate the impact of HSS performance on the IMS core. For example, it is possible to generate the Gm traffi c load under various network conditions resulting in a variance in traffi c mix for registrations, call attempts, de-registrations, while availability and responsiveness of HSS is emulated. Such a test would help MNO network planners and operations teams better understand IMS core network capabilities that are under stress.

The test setup on the right is an example of when a particular network element, such as S/I-CSCF, is tested, while the real MMTel AS is used with P-CSCF in the proxyFlex emulator. In this setup, it is possible to observe the behavior of S/I-CSCF in the following situations through hssFlex:

› Operator-assisted registration termination

› Operator blocks/unblocks subscriber

› Change of subscriber service bundles

› Changes in service provisioning

The possible test scenarios for S-CSCF behavior can be grouped as:

› Authentication, primarily in various failure scenarios (e.g., unknown users, unmatched identities, unsupported AUTH scheme, etc.)

› User profi le downloads

› Network initiated de-registration to verify that it triggers the de-registration of the user agent in the UE using the subscribe/notify mechanism

› Flood of registration and profi le updates from HSS

Similarly, the possible test scenarios for I-CSCF behavior can be grouped as:

› Registration, primarily in various failure scenarios (e.g., user barred for roaming, unmatched public and private identities, invalid users, etc.)

› Assignment of S-CSCF based on S-CSCF capabilities or best-fi t

› Interaction with subscriber location function triggering redirects to valid and invalid S-CSCF

There are other test scenarios where P-CSCF or AS can be the IUT. In P-CSCF testing, I/S-CSCF is emulated in proxyFlex, whereas P-CSCF is functionally tested for IPSec and SIP proxy requirements.

When AS is the IUT, P/I/S-CSCF can be emulated via proxyFlex, as shown in the following diagram.

Complete IMS test bedEmulate HSS and IMS subscribers with one platform, one module and one application

Figure 5. EXFO’s complete IMS test bed in action: a) end-to-end testing, b) I/S-CSCF as IUT

© 2013 EXFO Inc. All rights reserved.

White Paper

In this setup, the UEs (sipFlex) and HSS can be emulated to test the AS-over-ISC interface between the AS and S-CSCF as well as the Sh interface between the AS and HSS. In this test environment, a wide variety of features can be tested, such as presence, supplementary services and IM integration.

Another critical LTE network component required in the successful introduction of VoLTE is the eNodeB. Its primary function is to perform resource allocation for SIP signaling and voice bearers carrying voice as RTP/UDP/IP encapsulation. The most important aspect is trying to do this while competing traffi c, with various quality of service requirements, goes through the same interface. EXFO’s solution to this challenge is the RAN testing simulator platform.

RAN testing simulator enables eNB testing by simulating the S1 and X2 interfaces and supports testing on both the control and user plane. It can be used in the functional and load testing of the eNB. In functional testing, RAN testing simulator can send or receive protocol messages from the supported interfaces. It also generates and receives IP user-plane messages. In load testing, the RAN testing simulator simulates the heavy load of control-plane and user-plane traffi c. Transparent IP routing allows the testing of existing IP services. At the S1 interface, IP routing over SGi interface takes care of the automatic mapping of the IP user plane of UEs to GTP-U tunnels.

The following diagram shows how functional testing can be accomplished with RAN testing simulator. This setup can be enhanced by emulating the SIP (control) and RTP (user) traffi c for voice application and carrying both over the user plane through the S1-U interface. Equally important is that RAN testing simulator is capable of handling the interactions of mobility and session management with voice application capabilities.

© 2013 EXFO Inc. All rights reserved.

Complete IMS test bed

Figure 6. EXFO’s complete IMS test bed extended with IMS Core emulation.

Figure 7. EXFO’s eNodeB test bed.

White Paper

EXFO Headquarters > Tel.: +1 418 683-0211 | Toll-free: +1 800 663-3936 (USA and Canada) | Fax: +1 418 683-2170 | info@EXFO.com | www.EXFO.com

EXFO serves over 2000 customers in more than 100 countries. To find your local office contact details, please go to www.EXFO.com/contact.

WhitePaper016.2AN © 2013 EXFO Inc. All rights reserved. 2008

Printed in Canada 13/03

4. cOncLusiOnsIn this white paper, we described the requirements for VoLTE testing and monitoring along with the activity phases for service deployment. We revealed that lab validation, network integration, 24/7 network monitoring and troubleshooting are essential activities in VoLTE technology introduction. We also detailed the lab validation phase where interoperability testing and functional testing take place prior to live field trials. Considering the current level of maturity of VoLTE, we believe this is where most NEMs and MNOs will focus their efforts. Finally, we demonstrated how EXFO’s protocol analyzers and network simulators can be used effectively in the lab validation phase.