VoLTE Optimization Guide – Part 1

Before beginning with VoLTE optimization, it will be good to go through the VoLTE Capacity Planning article. For optimization, there are some aspects of VoLTE that we should understand. The VoLTE traffic is sent over QCI-1 which has a delay budget of 100ms – sometimes it is increased a bit but it is in the range of 100 to 150ms. This means that if there is a VoLTE packet that has not been successfully transmitted or received within 100ms, the packet will be discarded. Lets consider an example, if the eNB needs to send Packet-1 and it tries to send it to the UE but due to bad radio conditions or lack of resources or unavailability of scheduling opportunities, the packet could not be successfully delivered to the UE and the 100ms delay budget is reached, the eNB will discard that packet and the packet will be lost. Another thing is that the VoLTE traffic is RLC UM (Unacknowledged Mode) while data traffic is RLC AM (Acknowledged Mode). The difference between these modes is that in AM mode, the data traffic is sent over the air and if it fails (HARQ initial transmission and re-transmission), the RLC layer will send the data traffic again over the air. This can be done multiple times and it is configurable (usually between 8 to 32 times). However, in case of UM mode, the VoLTE traffic is sent over the air and if it fails HARQ then there will be no further re-transmission and the packet will be considered lost. In order to improve VoLTE quality, MOS and user experience, we need to minimize the loss of VoLTE packets and that is what VoLTE quality optimization is all about.

VoLTE & DRX

VoLTE DRX is usually different comapred to other services. The VoLTE traffic usually generates a packet every 20ms as explained under VoLTE Capacity Dimensioning so ideally, DRX cycle should be 20ms. In simple words, the UE can wake up every 20ms for On-Duration time, receive its VoLTE packet and then go back to sleep. However, Apple handsets require 40ms DRX cycle so most of the networks are configured with a 40ms cycle. This can create challenges especially considering the 100ms delay budget of VoLTE service.

Lets understand this based on the Figure-1 below. If there is no DRX, then a packet comes in the eNB buffer can be transmitted any time to the UE. The blue blocks in the Figure-1 show scheduling opportunity. If the first or second transmission are not successful, there are still many opportunities to re-transmit the packet (depending on maximum configured HARQ re-transmission threshold).

Now, consider a scenario, where we have DRX cycle of 20ms. In this case, there are 5 scheduling opportunities for the UE to be scheduled. This is still good and it has a high probability that the UE will get the packet within 100ms.

However, if we look at the 40ms cycle, then the UE has 2 or 3 scheduling opportunities to receive the packet within 100ms. This makes it very important that the first transmission is successful otherwise the packet might be lost. Also, since the cycle is 40ms and the VoLTE packet is generated every 20ms, so this means that there will be 2 packets bundled in each 40ms scheduling interval.

Lets look at it from another angle. If the UE wakes up for 10ms and then sleeps for 30ms, it will have a 40ms cycle.

If the UE fails to decode the packet on the PDSCH, the UE will send a NACK and the eNB will retransmit the packet after 8ms.

Now, consider the scenario, where the UE wakes up and at that moment, the eNB sends a VoLTE packet to the UE. However, the UE was not able to decode the PDCCH. In this case, the UE will not send any NACK as the UE does not even know that there was a packet sent to the UE. The eNB will consider this a DTX and resend the packet after 8ms. But if the second packet is also not received due to PDCCH, the UE will go back to sleep for 30ms and the eNB will not be able to schedule that packet.

Moreover, if the On-duration time is less – for instance, if the On-Duration time is 5ms and sleep time is 35ms, then the UE will only have one opportunity to receive the PDCCH successfully in order to receive the packet. So, bigger the sleep time and lesser the On-Duration time, higher the probability of packet loss but it will reduce battery consumption.

All of this also applies for uplink but in uplink, the UE can send a scheduling request which can bring the UE out of the sleep mode – however, if the initial grant is not big enough for the packet, the UE needs to send BSR and the scheduling for that will be done in the On-Duration time.

PDCCH Improvement

There are many features in different vendors to improve PDCCH decoding capability for VoLTE – especially in case of DRX with short on-duration time, it is very important that PDCCH is as robust as possible as explained in the previous part of this article. The PDCCH structure is made up of CCEs and it has multiple aggregation layers as described in PDCCH Capacity Enhancement article. In a nutshell, higher the aggregation layer, better the decoding capability of the PDCCH. For VoLTE, there are options that can increase the PDCCH aggregation layer and thus it can make the PDCCH more reliable than the data channel. Another aspect is the power increase on PDCCH for VoLTE traffic. This can also be done in nearly all the vendors, but usually the power is taken away from other sub-carriers so it is a compromise. However, for VoLTE optimization, it is better to utilize all the PDCCH enhancements available.

VoLTE Pre-Allocation

Another feature that some vendors have is VoLTE preallocation. This is similar to data preallocation or prescheduling and it allocates dummy uplink grants to the UE with fixed intervals. So, if the UE needs to send some data, it can send it in those allocations otherwise, it can just send padding data. This helps in scenarios where the UE is failing to get SR/BSR based grants easily and it also works with DRX cycle so it reduces the impact of DRX on VoLTE but it also increases battery consumption.

Robust MCS

Apart from PDCCH, the PDSCH also needs to be more robust for VoLTE traffic. This can be done by using a lower MCS for VoLTE. For instance, if the user is using 64QAM for data, and if there is a VoLTE packet, then the user can be scheduled on 16QAM for that TTI so that the VoLTE packet will have a lower BLER and a higher chance of successful decoding.

TTI Bundling

This is a basic feature for VoLTE and it improves uplink quality. What it does is that a UE in bad radio coverage will be instructed to send multiple copies of the data in successive TTIs. So, a UE if it needs to send one packet in subframe-1, it will be asked to send copies of that packet in subframe-2, 3 and 4 as well. These copies used different redundancy versions (RV) and improve the decoding gain at the receiver side. However, there is another catch here. When the UE is moved to TTI bundling, the DRX is disabled. So, it means that the TTI Bundling thresholds can be tuned to improve VoLTE quality and also to disable DRX as well which will in turn increase scheduling opportunities for users in poor radio conditions.

Delay Prioritized Scheduling

This is another enhancement that is available in all the vendors. With this enhancement, the VoLTE packets are prioritized based on the amount of time they have spent in the buffer. So, if there is a VoLTE packet in the buffer for 60ms and there is another packet for 20ms, then the packet with 60ms will be prioritized in the next scheduling opportunity. This is important because of the packet delay budget of 100ms – the packet waiting for 60ms is in a higher danger of getting discarded so it should be prioritized first.

Intelligent Grant Size Allocation

As there are multiple codecs in the network, so there would be different packet sizes for different calls. Consider, a UE using WB 12.65 codec and it has to send one packet to the eNB. The UE will send a scheduling request and based on this, the eNB will send an uplink allocation to the UE. This 12.65 codec might have a size of around 70 to 75 bytes so if the eNB sends an uplink allocation of 80 bytes, the UE can send this packet easily in that allocation. However, if another UE is using WB 23.85 then it will need around a 100 bytes to send that packet and if the eNB still sends a 80 byte allocation based on scheduling request, the UE cannot send the whole packet in that allocation. So, the UE will send a BSR asking for another allocation that is able to fit 100 bytes which will increase delay. Some vendors have introduced this enhancement that keeps averaging the size of allocations requested by the UE and then based on that, adaptively changes the initial allocation size which reduces the delay and improves uplink quality.

RoHC

Robust Header Compression is a feature that compresses the header of the VoLTE packet which reduces the overall packet size. As explained in VoLTE Capacity Dimensioning, a WB 23.85 codec has a payload size of around 60 bytes while the header size (IP, UDP, RTP) is around 40 to 45 bytes. So, the total size of the packet will be around 100~105 bytes. Now, if RoHC is enabled, it can compress the header part to 2 to 3 bytes and thus, the total packet size will reduce to somewhere around or below 65 Bytes. This is important especially for uplink because smaller packet size can be sent on lesser number of resources and thus, it increases power per RE and improves uplink VoLTE link budget and reduces packet loss.

Note: The example above is based on IPv4. In case of IPv6, the header size will be bigger – around 60 to 65 bytes. However, the RoHC will still compress it to 2 to 3 bytes.

Bonus video – The following VoLTE Optimization video session explains data channel resource optimization using context based compression algorithm known as Robust Header Compression (RoHC). A basic compression mechanism is explained followed by detailed working of RoHC and how it can improve VoLTE call quality as well. The session also discusses the E2E compression-decompression traffic flow during a RoHC VoLTE Call.

HARQ Enhancements

As explained above, in data radio bearer, the RLC mode is AM. The flow is that the data is sent from RLC layer to MAC/PHY and then transmitted over the air. If the UE fails to decode it, it will send a NACK and the MAC/PHY will re-transmit the data over the air. This re-transmission is HARQ based re-transmission. Usually it is set to 4 or 5 i.e after 4 or 5 re-transmissions the HARQ failure is pegged and RLC will then re-transmit the data and it will undergo another HARQ process of 4 to 5 re-transmissions. This can be done in data radio bearers as they are delay tolerant but with VoLTE, where we have a strict delay budget of 100 ms, we cannot use this process. That is why, the RLC mode in VoLTE is UM and this means that once the HARQ fails, there will be no re-transmission from RLC and thus the packet is lost.

So, in order to cater for this, we can increase number of re-transmissions over HARQ for VoLTE traffic and this can provide more reliability for VoLTE.

Codec Specific Coverage

As explained before, there are multiple codecs in VoLTE. There will be NB (Narrow-Band), WB (Wide-Band) or even the new codecs like EVS. Each codec has differet rates and each rate has a different packet size. Bigger the packet size, more resources it will take and uplink coverage might become a limiting link. For instance, at RSRP of -115, the UE might be getting along fine with NB 12.2 but on the same RSRP, the UE might have packet losses on WB 23.85. So, it is important to understand the proportion of codecs in your network and then plan the SRVCC threshold accordingly. A very low SRVCC threshold might increase VoLTE drops and reduce VoLTE quality.

B-SRVCC Issue

However, if we increase the SRVCC threshold to a higher value, we can have B-SRVCC or A-SRVCC issues. These are VoLTE drops during SRVCC (if the core does not support these procedures). Let me explain, how this works in a simple manner. If my 4G to 3G IRAT Handover threshold is -118 dBm RSRP and my SRVCC threshold is -110 dBm RSRP then consider a UE at the RSRP of -112 dBm will be on LTE using data only. Since, the UE is using data at the moment and has no VoLTE bearer so -118 dBm threshold will be effective at the moment. Now, if the UE initiates a VoLTE call at this point, the system will start a QCI-1 setup but it will see that the UE is at -112 while for QCI-1, the SRVCC should happen at -110 dBm. So, the system will initiate a SRVCC procedure – if this SRVCC happens before-alerting, the E2E system might not be able to process this SRVCC as the VoLTE bearer is not yet fully established. This might result in a drop and this is called B-SRVCC. If this happens during alerting phase, then it is called A-SRVCC. Usually, the networks support A-SRVCC but not all the networks support B-SRVCC as it needs some updates in the core.

In order to tackle it from RAN side, the easiest way is to keep SRVCC threshold close to IRAT handover thresholds to reduce the probability of this issue. Another thing that some vendors have introduced is a timer that prevents SRVCC after QCI1 initiation. So, if the QCI1 setup is being initiated and the UE sends a MR for SRVCC, the eNB will not entertain the MR until that timer expires. This also reduces the chances of B-SRVCC.

These are all the basics for VoLTE Quality Optimization. In the next article, I will cover VoLTE optimization from Drop Rate & Call Setup Time perspective. Stay tuned! Also, if this has been helpful, then please subscribe to our Youtube channel – Our Technology Planet for more exciting stuff and videos.

The following two tabs change content below.

• Bio
• Latest Posts

Ali Khalid

Senior Solution Architect at Ericsson SCU, Australia | 5G NR | VoLTE | LTE-A | Massive MIMO | NB-IoT

Ali Khalid is a Senior LTE/VoLTE RNPO, NB-IoT and 5G Solution Architect who has successfully led and delivered a number of projects in different regions across the globe including Pakistan, Bahrain, UAE, Qatar, Oman, KSA, Nigeria, Turkey, Poland and Japan. He is currently working in Strategic Competence Unit (SCU), a highly experienced global team at Ericsson, Australia. In case of any questions or feedback, please feel free to drop a comment below or connect with him on LinkedIn.

Latest posts by Ali Khalid (see all)

• 5G Coverage Expansion Analysis – Find The Optimal 5G Coverage Threshold For Your Network - November 9, 2024
• 5G Coverage Expansion - November 9, 2024
• 5G SA Cell Search & Network Entry Matrix - July 18, 2023