Companies within the wireless industry, and network operators in particular, are investing significant resources worldwide to implement Voice over LTE (VoLTE) in currently deployed 4G LTE networks. Besides the concern of achieving at least the same high-standard audio quality that is possible today through 2G or 3G legacy networks, it is just as important to ensure that a VoLTE call consumes a comparable amount of power as on 2G or 3G networks. It is up to the device manufacturer to ensure this during the design process and up to the operator to verify this with lab and field-based testing.
VoLTE Power Efficiency Depends on Implementation
The high-level architecture that today’s smartphones use for VoLTE is shown in Figure 1. The device has an application processor that runs the operating system (OS), usually Android, iOS, Windows or an OEM-specific OS. All applications run on the device interface to the application processor and use the provided functionality. In addition, there is the modem, or chip, that is designed to support real-time operation to accommodate radio and control functions (for LTE, for example) that depend heavily on timing. Often, hardware accelerators are used for dedicated functions. Finally, there is the audio subsystem, which connects to the device’s loudspeaker and microphone. The audio subsystem realizes such functions as the conversion from analog to digital and vice versa, or provides advanced functionality, such as background noise cancellation, to optimize audio quality. In the early days, the IMS client – which was required to perform the registration and establish calls via IMS – ran on the application processor. That consumed a lot of power, because the processor was essentially running all the time, even during a voice call. Nowadays, the IMS functionality for voice has been transferred to the modem. This allows the application processor to enter sleep mode and lowers power consumption significantly.
What Defines VoLTE?
Besides the implementation-specific aspects of VoLTE, the industry has also agreed on what is referred to as an “IMS Profile for Voice and SMS.” In the latest version of this document, dated March 2013 and published by the GSM Association (GSMA), several minimum requirements for functions and features are listed that a terminal and its network must support in order to ensure interoperable, high-quality IMS-based telephony service via Long Term Evolution (LTE) radio access. Besides defining mandatory basic IMS capabilities and supplementary services for telephony, real-time media negotiation, transport and codecs, this document also mandates support of several core features for the radio and packet. Among other PHY/MAC features, it requires support for discontinuous reception (DRX). DRX is crucial for optimizing VoLTE in terms of power consumption in order to maximize the device’s battery life. Therefore, we need to take a closer look at how DRX works.
DRX and its Two Modes
Two DRX modes have been defined for LTE: the idle state and the connected state. The latter is often referred to as connected DRX (cDRX). Let’s examine the differences.
Idle mode is generally
defined as the state in which no RRC connection exists between the device and the network. However, the device should be able to listen to paging messages for details on incoming connections, system information changes or public warning system (PWS) notifications. Theoretically, there is a paging radio network temporary identifier (P-RNTI) on the physical downlink control channel (PDCCH) every 1 ms. Having to monitor the channel constantly would heavily impact a device’s battery life. Therefore, LTE includes a mode for discontinuous monitoring of the PDCCH for paging messages. This is commonly known as the DRX in idle mode. In this mode, the device only monitors certain subframes in a specific radio frame for its paging message. The reminder of the time, the UE enters sleep mode to conserve battery power. The initial configuration for the Idle DRX cycle can come from higher layers – non-access stratum (NAS) signaling – and can, therefore, be device specific. As an alternative, it can be broadcasted using a Type 2 system information block (SIB) as a default paging cycle. In that case, it is cell specific and common to all devices in that 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, as mentioned above, connected DRX. Here, the network sets certain parameters while sending a message, such as an RRCConnectionReconfiguration message including all relevant parameters, during the call setup. What are these parameters and how do they impact the overall mechanism?
Assuming that the device, the user equipment (UE), receives a scheduling grant for either the downlink or uplink (see Figure 2), the terminal would always reset the drx-inactivityTimer. This timer can have a flexible length of up to 2.56 seconds. Let’s assume further that the device does not receive another scheduling grant in the next subframe, nor in any of the subsequent subframes. In such a case, the device would not reset the timer, which would continue to run. At some point, depending on the settings, the timer will expire, which then triggers the device to move into the DRX cycle. At this point, it is important to understand that 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 (FGI). The FGI is a 32-bit bitmap, where bits 4 and 5 indicate support for the long and short DRX cycles. For VoLTE, long DRX cycle support is mandatory, but short DRX cycle is optional.
In our example, we assume that the device supports both DRX cycles, which is the current state of the art for leading-edge smartphones. As soon as the inactivity timer expires, the device switches to the short DRX cycle [Figure 3]. Both the short and long DRX cycles are defined by an on period, the onDurationTimer, and by a sleep period during which the receiver can be turned off. For the on period, the terminal still monitors the PDCCH for incoming scheduling grants. The duration of inactivity is defined by the shortDRX-Cycle, which could last up to 640 ms. The drxShortCycleTimer indicates the number of short DRX cycles, which can be any number between 1 and 16, before the device moves to the long DRX cycle. During the long DRX cycle [Figure 4], the device also monitors the downlink for the timeset by the onDurationTimer, but the sleep period is then even longer for the short DRX cycle. That makes it possible to preserve even more battery power. Typically, the long DRX cycle is set in multiples of the short DRX cycle. If, for instance, the short DRX cycle is defined at 40 ms, the long DRX cycle might be set to 320 ms.
As can be seen in Figure 2 to 4, the different parameters could be set to a wide variety of values. They could be set to optimize for power consumption. The longer the two cycles are, the shorter the timers are, and the greater the battery power saving will be during an active connection. But for VoLTE, these parameters need to be carefully selected. First, and most importantly, the short and/or long DRX cycle(s) need to match the duration of a voice packet, which is 20 ms. Consequently, the two cycles should be set to 20 ms – or to 40 ms, which would allow reception of up two voice packets. Second, the onDurationTimer and drx-InactivityTimer should be set to minimal values. Those are the rules of thumb for a VoLTE-only connection. For VoLTE plus data, it might be necessary to at least change the last of those parameters in order to ensure an acceptable data rate and user experience. All DRX settings are network-based settings. Service providers verify different combinations during extensive drive testing for LTE network optimization for VoLTE support, and they make configurations based on the data gathered on the network. However, this could imply that different DRX settings could be in place in different areas and different markets. Furthermore, the question remains as to what happens with the audio quality when cDRX is active. In short, there is a lot to test: VoLTE functionality in general, audio quality and power consumption in particular.
Ensuring Optimization for VoLTE, Including Battery Performance
As explained in the previous paragraph, there is a lot to test when it comes to VoLTE, including audio quality and power consumption. What is required to validate all of this on a device in a lab-based environment? First, a network emulator that is capable of emulating an LTE network according to the latest standards and specifications. Furthermore, the emulator needs to provide IMS functionality that a VoLTE-capable device can register with, and it must make it possible to establish either a mobile-originated or mobile-terminated voice call based on IMS. Third, the base station emulator needs to provide the required audio functionality, including audio codecs, such as the Adaptive Multi-Rate (AMR) codec for Wideband and Narrowband (AMR-WB, AMR-NB) with its respective codec rates. In addition, the test set needs to support DRX functionality according to latest standards [2, 3]. All this is available with the Rohde & Schwarz R&SCMW500 wideband radio communication tester.
To test audio quality during a VoLTE call, an audio generator and analyzer is required that is able to generate and analyze audio waveforms using the latest methodologies. Today, two standards are in place for performing subjective audio quality measurements: perceptual evaluation of speech quality (PESQ) and perceptual objective listening quality assessment (POLQA), whereby the latter is used for audio quality measurements during VoLTE calls. The ITU-T has also adopted POLQA as a standard. Also known as Recommendation P.863, this standard 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, degraded waveform is then compared to the ideal waveform using the POLQA algorithm to obtain a mean opinion score (MOS). The MOS could range from 1 to 4.5, whereby everything above a value of 4 could be considered outstanding audio quality. For figures below 4, certain individuals may notice degradation in audio quality. The R&S UPV audio analyzer is the instrument of choice for testing audio quality independently of the underlying methodology, because it supports both PESQ and POLQA.
Testing the terminal’s current drain during an active call, especially when DRX is activated, requires a power supply that replaces the device’s battery. The R&S NGMO2 provides the resolution needed to do this type of testing.
A good amount of automation is required to carry out this type of testing, because audio quality is typically tested separately for downlink and uplink. Usually, both the AMR-WB and AMR-NB codecs are tested, including the respective codec rates. AMR-WB offers nine different codecs; AMR-NB has eight codec rates. Why are there different codec rates and why is testing them important? During an active VoLTE connection, it is possible to change the audio codec during the call. For example, when the network is very congested (during times such as the morning hours), and the packet loss rate that is measured on the realtime transport protocol (RTP) packet order arriving at the receiver increases, both parties may agree to change to a more robust codec rate. So it is important to test different codec rates for each audio codec. The audio quality is tested using reference waveforms. Reference waveforms are defined in ITU-T P.863 for the following languages: American English, British English, Chinese (Mandarin), Czech, Dutch, French, German, Italian, Japanese, Swedish, and Swiss German It is important to keep in mind that there are male and female versions and that the waveform is about 8 seconds long. Finally, it is necessary to verify the impact of the DRX settings on the audio quality and power consumption. DRX settings that the device will experience throughout the network must not be allowed to compromise the audio quality in any way. Here, automation is key. Test automation can be easily achieved using the R&S CMWrun sequencer software, which controls the R&S CMW500 wideband radio communication tester, the R&S UPV audio analyzer and the R&S NGMO2 power supply. The entire test setup for testing VoLTE calls, including audio quality and power consumption for different audio codecs and codec rates, and separately for downlink and uplink, is shown in Figure 5.
R&S CMWrun collects samples from the R&S NGMO2 and displays the current drain from the phone over time [Figure 6]. The x-axis shows the momentary current that the phone is drawing, and the y-axis represents the time. Specific trigger events (e.g. LTE attach, or IMS registration) have been implemented. For them, measurements providing more details (i.e. more samples) are used and displayed. This monitoring of power consumption runs as a subroutine. 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 R&S 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 into networks and devices along with its optimizations, such as DRX, power consumption is actually comparable to phone calls over today’s legacy 3G networks, while maintaining the same high-standard audio quality. It is essential to test and verify this upfront, especially on the device side. Advanced test and measurement equipment allows design engineers to simultaneously test every aspect of VoLTE devices– functionality and performance, including audio quality and power consumption.
This article originally appeared in the January/February print issue. Click here to read the full issue.