VoLTE Optimization Guide

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.

Figure-1 : VoLTE & DRX

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.

Figure-2 : VoLTE & On-Duration

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.

Figure-3 : TTI Bundling

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.

Figure-4 : RoHC

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.

Ali Khalid

5G NR | VoLTE | LTE-A | Massive MIMO | NB-IoT | NDO Network Specialist at Ericsson, Australia
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.

38 thoughts on “VoLTE Optimization Guide – Part 1”

  1. Hi,

    We have encountered a problem with VoLTE dropped calls with cause “insufficient bearer resources” connected with Secondary Cell Reconfiguration procedure followed by RRC Connection Reestablishment (reestablishmentCause : otherFailure) failure. do you have any idea what might be a reason for such a problems, please?

  2. Hi Khalid ….firstly thanks for the very well written blog. Even the discussions in comment section are very good. I have a question although it is now related to this particular post.

    What will be your take on VoLTE layering ? In a NW with 3 carrier, 2600, 1900, 700….how would you propose the LMS to be ? Steering more users towards lower carrier like 700 (high coverage, indoor penetration, better UL) or higher band like 2600 (quality layer ). What will be the advantages/disadvantages in your point of view of keeping users on 700 vs 2600 ?

    1. I think this is one of the most common debates on VoLTE – which layer to prefer. If you are looking for higher VoLTE MOS, then higher layers are better due to higher bandwidth and CQI. If you are looking for more VoLTE coverage then lower bands are better but they have quality issues and usually call quality is worse at cell edge – many operators faced choppy noise on low bands in indoor scenarios due to poor SINR and then shifted VoLTE traffic to higher layers.

  3. Hello Khalid
    you are best teacher of LTE
    I always follow your blogs ….thanks
    can you help me out for volte drops ( nokia system) . mostly pegging counters are :
    1) Due to inactivity
    2) due to HO timer

    1. Hari,
      you can try this
      1) If counter pegging “Due to Inactivity” User inactivity timer keep at lower side to cater higher number of Volte user shopping mall/railway Station/Stadium if your site having less user should increase user inactivity (IAT) timer.
      2) If counter pegging “Due to Inactivity” same case for HO timer check its value may be your also facing ping pong issue at same time if so increase HO timer.

  4. Dear Ali Bhai,

    Can you please comment in the RLC and PDCP SN Length for RLC UM mode. As I understand, the settings are different for Huawei and Ericsson. Ericsson recommends values of 7 & 5 for PDCP and RLC SN Length respectively. If different sites have different settings, who can it affect the VoLTE user?

  5. Hi
    Thanks a lot
    Can you give more information about packet loss related Call drop VoLTE?
    What will eNB, Core or UE do when having a lot of packet loss?

  6. 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 => increase from 4 or 5 to like 7 initial HARQ Re-Tx?

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

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

    Both statements contradicting each other?
    In first statement, no HARQ Re-Tx for VoLTE packet and in 2nd you said that there are still many opportunities for HARQ re-transmission

    1. In the first sentence, “If It fails HARQ” means HARQ procedure i.e. All HARQ transmission/retransmissions then there will be no further retransmission from the RLC layer.

  8. Thanks Ali Khalid!
    I know VoLTE is UM RLC, but i think packet loss and ERAB Drop QCI 1 are highly correlated.
    You can tell me know that : how many packets loss in how many times to CORE or UE initiate drop call VoLTE ?

    1. Yeah, in UEs there is a RTP timeout entity which is based on packet loss. If the UE fails to decode or receive packets until RTP timeout, it will drop the call.

      1. When a VoLTE Call drop because RTP time out ( CORE or UE initiate), KPI counter in eNB Ericsson consider which is normal or abnormal release?

  9. very well explained.
    just little confusion ….
    If Re transmissions are not happen in VoLTE due to locked Budget delay of 100ms then either we will increase the re transmission for HARQ Process, how it will cater this packet loss in VoLTE over RLC layer?

    1. If user is in bad radio conditions and we are sending 4 HARQ retx and all of them are failing – meaning packet loss. So, If we increase it to 6, for instance, then it will increase probability that the UE might be able to decode the packet.

  10. Hi Ali,

    Thanks for the well written article.

    Quick question – Is the Semi-Persistent Scheduling a basic feature or does it need to be manually activated? I could not find it in Ericsson documentation. The only scheduling algorithm option I came across for QCI-1 is Delay-Based Scheduling which is a mandatory Ericsson VoLTE feature.

  11. Can you please further explain about B-SRVCC and clear my confusion for below phrase:

    “if this SRVCC happens before-alerting

    Who gets “alerted” ?

      1. Hi Ali,

        First off, let me tell you that I am fond of your wonderfully concise and uncluttered technical pieces. It is like a breath of fresh air to see you writing after a while.
        Now coming back to the topic. I want to add that if Early Media is implemented and SRVCC is triggered before getting SIP 183 (session progress), it will be considered b-SRVCC. If 183 is received, then it will be considered a-SRVCC.

  12. Hi
    Thanks a lot
    Can you give more details about
    //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.//

    1. When UE needs to send some data on uplink, the UE needs to request for an Uplink Grant. This is done by sending a SR to the eNB. Based on SR, the eNB sends an uplink grant but that grant size can be a fixed static value. So, it is possible that the UE has more data to send so the UE will send BSR in this grant indicating the amount of data that needs to be sent.

      1. Thanks a lot
        Great

        Can you please add a part for Sip volte failure ( precondition failure, sip Time out , internal error,…)

  13. Good one… I have one doubt as VoLTE operation normally in UM mode then how and why UE sent ack/nack.

    1. MAC/PHY have HARQ to retransmit data over PHY. RLC has AM and UM for ARQ. So, in VoLTE RLC is UM but the HARQ is still available on MAC/PHY – ACK/NACK are for HARQ.

Leave a Reply

Your email address will not be published. Required fields are marked *