comment on this article

The test requirements for assessing VoLTE call quality

The wireless industry is making significant investments to implement Voice over LTE (VoLTE) in 4G LTE networks. Alongside the need to at least match the audio quality of 2G or 3G legacy networks, it is important to ensure that a VoLTE call consumes a comparable amount of power.

Implementing VoLTE on top of the LTE infrastructure is complex. Different network elements have to work together and performance must be analysed, optimised, tested, reanalysed, further optimised and retested. The high level architecture for VoLTE is shown in fig 1.

In the early days, the IMS client – which registers and establishes calls via IMS – ran on the application processor and consumed a lot of power. Nowadays, the IMS functionality for voice has been transferred to the modem, reducing power consumption significantly.



Besides implementation specific aspects of VoLTE, the industry has agreed on an 'IMS Profile for Voice and SMS', which lists the minimum functions and features that a terminal and its network must support. Besides defining mandatory basic IMS capabilities, the document mandates support of several core features for the radio and packet. Amongst other features, it requires support for discontinuous reception, or DRX. This is crucial for optimising VoLTE power consumption.

DRX and its two modes
Two DRX modes have been defined – idle and connected (cDRX). Idle mode is generally defined as the state in which no RRC connection exists between device and network. Theoretically, there is a paging radio network temporary identifier (P-RNTI) on the physical downlink control channel (PDCCH) every 1ms.

Monitoring the channel constantly would impact a device's battery life, so LTE includes a mode for discontinuous monitoring of the PDCCH. The DRX in idle mode allows the device to only monitor certain subframes in a specific radio frame for its paging message. For the rest of the time, the user equipment (UE) enters sleep mode to conserve battery power.

The initial configuration for the Idle DRX cycle can come from higher layers and therefore can be device specific. But it can also be broadcast using a Type 2 system information block, where it is common to all devices in a particular cell. Based on the set parameters, the terminal determines the radio frame subframes in which it will look for paging messages.

The relevant DRX mechanism for VoLTE and power consumption is cDRX, in which the network sets certain parameters while sending a message. What are these parameters and how do they impact the overall mechanism?

Assuming the UE receives a scheduling grant for either the downlink or uplink, the terminal would always reset the drx-inactivityTimer, which has a flexible length of up to 2.56s. If the device does not receive another scheduling grant, it will not reset the timer, which will continue to run. At some point, the timer will expire, which triggers the move into the DRX cycle. There are two DRX cycles – short and long.



The device indicates its support for both cycles during the registration and attach process. The UE submits its capabilities to the network, which includes its feature group indicator, a 32bit bitmap in which bits 4 and 5 indicate support for the long and short DRX cycles. For VoLTE, long DRX cycle support is mandatory, but the short DRX cycle is optional.

A range of different parameters can be set to a variety of values. The longer the two cycles, the shorter the timers and more battery power will be saved during an active connection. But, for VoLTE, these parameters need to be carefully selected. Most importantly, the short and/or long DRX cycle(s) need to match the 20ms duration of a voice packet. So the two cycles should be set to 20ms or 40ms, allowing up to two voice packets to be received. The onDurationTimer and drx-InactivityTimer should also be set to minimal values.

Test set up
There is a lot to test: VoLTE functionality in general, but also audio quality and power consumption. The test set up required to validate all of this in a lab based environment is shown in fig 2. Firstly, the network emulator must emulate an LTE network according to the latest standards and specifications. It must also allow a VoLTE capable device to register with it and make it possible to establish either a mobile originated or mobile terminated IMS based voice call.

Meanwhile, the base station emulator must provide the required audio functionality, including Adaptive Multi-Rate codecs for wideband and narrowband (AMR-WB, AMR-NB) with their respective codec rates. In addition, the test set needs to support DRX functionality according to latest standards. This functionality is available from Rohde & Schwarz' CMW500 wideband radio communication tester.

Audio quality during a VoLTE call can be tested using an audio generator and analyser which uses the latest methodologies and R&S' UPV audio analyser is the instrument of choice here, because it supports PESQ and POLQA. Two standards are in place for subjective audio quality measurements: perceptual evaluation of speech quality (PESQ); and perceptual objective listening quality assessment (POLQA), used during VoLTE calls.

The ITU-T has also adopted POLQA as a standard. Also known as Recommendation P.863, this makes it possible to predict speech quality by means of digital speech analysis. In fact, it is a reference measurement with which a known reference audio waveform is played through the system under test. The received, but degraded, waveform is then compared to the ideal waveform using POLQA to obtain a mean opinion score ranging from 1 to 4.5; everything more than 4 could be considered outstanding. For figures of less than 4, some may notice degradation in audio quality.

Finally, the terminal's current drain during an active call, especially when DRX is activated, can be determined using R&S' NGMO2.

A reasonable amount of automation is required to carry out this type of testing, because audio quality is typically tested separately for downlink and uplink. Both AMR-WB and AMR-NB codecs are normally tested, including their respective codec rates: AMR-WB offers nine codecs; AMR-NB has eight and testing them all is important.

Finally, it is necessary to verify the impact of DRX settings on audio quality and power consumption – DRX settings must not be allowed to compromise audio quality. Here, automation is key and this can be accomplished using the R&S CMWrun sequencer software.

CMWrun collects samples from the NGMO2 as a subroutine and displays the current drain from the phone over time. That makes it independent of the master script which, in this example, is establishing a VoLTE call to measure audio quality with and without DRX. The subroutine can be used with any CMWrun script; for instance, to measure the current drain of a device under test when it is in idle mode.

If VoLTE is implemented correctly, power consumption is comparable to phone calls made over 3G networks, with high audio quality. It is essential to test and verify this, especially on the device side..

Andreas Roessler is technology manager, North America, with Rohde & Schwarz USA.

Author
Andreas Roessler

Comment on this article


This material is protected by MA Business copyright See Terms and Conditions. One-off usage is permitted but bulk copying is not. For multiple copies contact the sales team.

What you think about this article:


Add your comments

Name
 
Email
 
Comments
 

Your comments/feedback may be edited prior to publishing. Not all entries will be published.
Please view our Terms and Conditions before leaving a comment.