VoLTE Basics: Planning & Dimensioning

In normal LTE networks, the users are sent to legacy CS networks (2G/3G) via CSFB mechanism whenever they have to make a voice call. CSFB is a good solution and it has evolved alot but still it takes longer time. The alternate solution is to have the voice session over LTE which is known as VoLTE (Voice over LTE). A VoLTE call is much quicker to setup as there is no fall back required to another RAT and also it has a better quality due to more bandwidth and advanced features.

However, VoLTE is basically a PS call and it has its own challenges. VoLTE Call Setup Success Rate, Call Drop Rate and Quality are major issues that operators face after enabling VoLTE. In this article, I will explain the VoLTE basics along with capacity planning and dimensioning

VoLTE Call Setup

Traditionally, a VoLTE user attachs to the LTE network using both QCI-9 and QCI-5. QCI-9 is the default bearer for data while QCI-5 acts as the default bearer for voice and it carries SIP signaling. When a call needs to be setup, an additional bearer is added for QCI-1 which is a GBR bearer and all voice data (RTP packets) are sent over this bearer. From KPI’s perspective, the ERAB setup success rate of QCI-1 can be used as a VoLTE call setup success rate but from Drive Test or CEM’s perspective, there are many other factors that need to be taken care of. For instance, an ERAB setup of QCI-1 might be successful but the call might still fail on SIP or issues related a/b-SRVCC.

Lets try to visualize the call setup process for a VoLTE call. Party-A will initiate a RRC connection with cause code of mo-data and after RRC setup completion, it will share with the network that it has VoPS (VoLTE) capability and it prefers to use VoLTE. The core will initiate ERAB setup inside Initial Context Setup Request of QCI-9 and QCI-5 for the UE. Once, the RABs have been setup, the Party-A will send a SIP-Invite over QCI-5 which is the message initiating the VoLTE call. This message carries the Party-B’s number and the network finds out both the Party-A and Party-B. It can also carry the supported codecs and based on this, the codecs are negotiated for the call. Once the network receives the SIP-Invite, it will response with a SIP message 100-trying which just indicates what the name suggests that the network is trying to setup the call.

A simplified VoLTE call setup diagram

Network forwards the SIP-Invite to Party-B and Party-B can respond with 100-trying and it can also send 183-Session In Progress which is a precondition scenario which triggers the QCI-1 addition and it can contain codec information as well. After SIP-183, the Party-A and the Party-B get the QCI-1 and this is done by ERAB setup request from the MME. The eNBs serving both the parties send RRC Connection Reconfiguration to the users adding the DRBs for QCI-1. This is followed by 180-Ringing which is the alerting message indicating that the connection has been setup and the call can be received. A SIP-200-OK in the end shows a successful call setup.

Mobility & Codecs

Considering LTE has a higher capacity, most of the VoLTE to VoLTE calls use WB codecs which provide better quality. For instance, a VoLTE to VoLTE call might use AMR WB 23.85 while a normal call in 3G might be using a AMR NB 12.2. So, it means that it requires more bandwidth for a call using 23.85 kbps compared to a call using 12.2 kbps and therefore, it has a better quality as well. However, a higher codec needs better radio conditions. So, if a VoLTE call is using WB 12.65, it might be able to sustain a reasonable quality till -113 dBm RSRP and -5 dB SINR (empirical values) but the same call on WB 23.85 will need a higher RSRP/SINR values. Empirically, a 23.85 call has a 6 to 8% smaller cell radius compared to a 12.2/12.65 based call. So, the planning of the A2 threshold of SRVCC should consider the codec distribution as well. If the network is supposed to use WB 23.85 for most of the calls then SRVCC thresholds should be planned accordingly. However, in case of a TrFO scenario, the VoLTE calls might be using NB12.2 or lower codecs because most of the networks will have much more voice traffic on 3G compared to VoLTE. So, if a VoLTE user makes a call to another user who is on 3G which supports NB12.2 (RAN or handset support), then the call will be setup on NB 12.2 and therefore, the VoLTE user will also use NB 12.2 even though his handset supports WB codecs. So, most of the calls initially use NB even in a VoLTE setup. If 3G network has WB codecs activated (for instance 12.65) then the proportion of WB codecs on VoLTE will also increase and therefore, the average voice quality will also improve.

Another aspect that should be considered in the initial design is the concept of HoIT in VoLTE. HoIT is Handover Interruption Time and it is usually measured for VoLTE using QXDM. Ideally it should be less than 50 ms for VoLTE and that is usually fine in case of intra-frequency X2 handovers. However, it is difficult to maintain for inter-frequency handovers. Moreover, inter-frequency handovers also bring gap mode or compressed mode as during inter-frequency handover process, the user needs to go into gap mode to measure the other frequency. Therefore, it is a good idea to keep the thresholds such that intra-frequency handovers are always preferred and inter-frequency handovers should be avoided as much as possible.

VoLTE Capacity Dimensioning

Lets consider an example with a VoLTE codec of AMR-WB 23.85 kbps. Since, VoLTE generates packets after every 20 ms so in 1000 ms, there would be 50 packets (1000/20 = 50). Now we know that the codec generates 23.85 kilobits per second and it generates 50 packets per second so each AMR-WB 23.85 packet will be 477 bits (23850/50 = 477). This is the size of the VoLTE payload but there will be overheads like headers (IP, UDP, RTP) that needs to be added to each packet for VoLTE dimensioning. A typical IPv4 header is around 20 Bytes and overall, the overhead will be around 40 to 45 bytes. Lets assume 45 bytes (360 bits) of overhead which means that the total bits per VoLTE packet will be around 837 bits (477 + 360). So, in one second, we will have 41.85 kilobits (837 bits per packet * 50 packets per second). This means that a typical VoLTE data rate for AMR-WB 23.85 codec will be around 42 kbps. If RoHC is enabled in the network, the packet size will go down as it compresses the headers to around 1 to 2 bytes. I will cover this in my next article on VoLTE optimization.

Lets have a look at what it means in terms of capacity. If I add one VoLTE user who makes a call on the cell with 10MHz, it will take 42 kbps from the cell. If the user count is increased to 10 simultaneous calls, then the capacity impact will be around 420 kbps and so on. Similarly, if I have 200 users, they will take away around 8.4 Mbps (42kbps*200). Looking at it like this does not show any significant impact of VoLTE on the cell capacity. However, there is another dimension to this calculation. Under normal scenarios, VoLTE users take 1 to 2 RBs per packet but they can take multiple CCEs for each allocation (2, 4 or 8). For each VoLTE user, a PDCCH grant will be given which will tell the VoLTE user where is its packet located on the PDSCH. The PDCCH uses CCEs to provide the scheduling information and the CCEs can be used in groups of 1, 2, 4 or 8 depending on the radio conditions of the user. So, if there are 200 VoLTE users and they are evenly distributed in time, then each TTI will have 10 VoLTE users. This can be calculated based on the fact that 10 users in TTI0 will need to be scheduled in TTI20, TTI40, TTI60 and so on. So, next 10 users will be scheduled in TTI1, TTI21, TTI41 and onwards. This means that if there are 200 users and the VoLTE TTI is 20, so the number of users per TTI with even distribution will be 200/20 = 10. Now if we have 10 users per TTI and and each user takes 2 RBs for the above mentioned packet size then we will have PDSCH overhead of 20 RBs per TTI. In 10MHz, we have 50 PRBs so this is not an issue. However, in 10 MHz, we have around 40 CCEs if PDCCH uses all the 3 symbols and if each user takes 4 CCEs then all the 40 CCEs will be consumed by these 10 VoLTE users and there will be nothing left for the data users.

Example of PDCCH and PDSCH utilization in VoLTE

This signifies the point that VoLTE which is a small packet service can consume more control resources compared to data resources and thus its capacity should also be dimensioned from the control (PDCCH) perspective. Features like Semi-Persistent Scheduling were introduced to tackle this issue of VoLTE. I will cover this in the VoLTE optimization topic later.

Another aspect of VoLTE is that it has a more even uplink and downlink utilization. In typical LTE networks that are data driven, most of the usage is in the downlink direction. As the uplink usage is much lesser so uplink interference is much lower and this has encouraged many vendors to use more aggressive uplink power control algorithms. However, when VoLTE users start to increase, they have an almost equivalent amount of traffic in downlink and uplink. So, as the VoLTE usage increases, the uplink interference increases and the impact of interference is higher on VoLTE since it is a UM (Un-acknowledged RLC Mode) service with a very strict delay budget. Therefore, it is a good idea to revisit uplink power control parameters and interference margins as the VoLTE usage increases.

VoLTE Erlangs & Traffic

As VoLTE is PS so there are counters for VoLTE traffic that provide the values in bytes. However, as the CS traffic uses Erlangs so there is a requirement for VoLTE traffic to also be expressed in terms of Erlangs. There are counters that peg the amount of time in seconds or milliseconds when the VoLTE packets were scheduled and summing them up and expressing them in hourly units can provide Erlangs. We can also make approximations between Erlangs and Bytes if we know the codec distribution. For instance, in the above mentioned scenario of 23.85 kbps codec, we know that the user will actually be generating 42 kilobits per second. If we factor this to hour by multiplying it by 3600, we can get the amount of bits generated for one Erlang. However, the VoLTE time counters peg for each interval irrespective of the number of VoLTE users in that interval. For instance, if there were 10 VoLTE users simultaneously making the call, the Erlang time counter might still peg just 1 unit. So, in this case the traffic will be much higher than Erlangs unless there is a counter or factor that is embedded in the Erlang calculation to factor multiple users. At the moment, VoLTE traffic is not high and VoLTE capacity is much higher compared to 2G and 3G cells so this issue is not really observed but it is good to know about it when making Erlang and PS traffic calculations. Another aspect is to know the codec distribution as each codec generates a different number of bytes. Moreover, RoHC also changes the bits per packet significantly. Lastly, there is a difference between talk spurts traffic and silent period traffic. During silent period, SID packets are generated every 160 ms instead of 20 ms and the size is around 40 bits for the SID. So, this should also be factored in the calculation and understanding. In short, it is very difficult to calculate exact values of data from given Erlangs but an approximation can be made based on above assumptions.

Handset Compatibility Issues

Another thing that VoLTE introduces is the handset issues. Many handsets have compatibility problems with various VoLTE features. For instance, there are some handsets that fail to work with RoHC properly and changes need to be done at the network side to resolve this issue. This issue can be detected using RoHC counters in the OSS. Similarly, Apple phones require a different set of DRX parameters compared to other handsets. Iphones use a 40 millisecond VoLTE TTI while most of the other handsets use a 20 millisecond TTI. This means that most of the phones generate VoLTE packets after every 20 ms while iPhones generate VoLTE packets after 40 ms by bundling two VoLTE packets together. So, Apple recommends using a 40 ms DRX cycle with 4 ms On Duration and DRX Inactivity timer. However, this provides a small active window and since VoLTE Packet Delay Budget is 100 ms so this configuration usually has a higher packet loss. A packet delay budget of 100 ms means that if a VoLTE packet has stayed in the buffer of the eNB or the UE for a 100 ms, it will be discarded and the packet will be lost. So, if we use a 20 ms periodicity then in 100 ms, a user will have 5 opportunities to send or receive packets but in case of 40 ms periodicity, the user will only have 2 or 3 opportunities so the probability increases for a packet discard. How to tackle all these issues and their work-arounds will be explained in my next article on VoLTE Optimization!

The following two tabs change content below.

Ali Khalid

5G SME & Solution Architect | NB-IoT | VoLTE | Massive MIMO at Ooredoo Oman
Ali Khalid is a Senior LTE/VoLTE RNPO Expert and 5G Solution Architect who has successfully delivered a number of LTE RNPO Projects in different regions across the globe including Pakistan, Bahrain, UAE, Qatar, Nigeria, Turkey and Oman. In case of any questions or feedback, please feel free to drop a comment below or connect with him on LinkedIn.

19 thoughts on “VoLTE Basics: Planning & Dimensioning”

  1. can you deep-dive more into the REP gap analysis area? most networks are pretty much deployed and stable, yet the audio quality aspects,are becoming more into focus. sometimes after handover or Due to poor layer management, we have a lot of ping-ponging between layers. from a more holistic approach can this be,attributing to the underlying audio issues experienced?

    1. Yeah the VoLTE quality is one of the major issues being faced by nearly all the operators. I will cover this in detail under VoLTE Call Quality section in the next article.

  2. Thank you very Much sir, the most awaited topic .
    thanks a lot.

    Please share some Knowledge on NR-IOT and Massive MIMO . please please sir

  3. Hi Ali sir,
    First of all, big fan of your blogs.
    “Traditionally, a VoLTE user attachs to the LTE network using both QCI-9 and QCI-5”
    Are the QCI5 and QCI9 both included in the PDN connectivity request EVERYTIME the UE attaches (or comes back from a different RAT to LTE) or only QCI9 is included. What I mean is UE always sends both QCIs in attach request?
    And for a network that has not activated its Volte services yet and uses the common CSFB method, we still see “Initial E-RAB QCI5” attempts. So in that case, the QCI5 is just setup and not used or something else? Could u plz explain that in some detail?

    1. For a network without VoLTE, there should not be any QCI-5 attempts. If there are QCI-5 attempts then the core is configured in that way but they are not required. For a network with VoLTE configured, any UE which has VoLTE capability and configured to use VoLTE by core, should get both QCI-5 and QCI-9 every time it setups a connection (ERAB).

  4. Jazakallahukhairan ali khaleed for VoLTE Basics: Planning & Dimensioning aRTICLE…may allah(swt) increase your knowledge in deen and duniya…………….aameen

  5. As always you have very nice description,
    Can you clarify to me, whats the best value for UL Target BLER in VOLTE
    Should we use a value less that 10 percent
    what do you think about reducing BLER to 6 to enhance VoLTE MOS and quality
    Thank you

    1. Thanks Kamel. Yeah, a lower BLER for VoLTE in uplink will be better as higher BLER targets are used for achieving higher throughputs and VoLTE does not require much data rates but it does require reliability.

      1. My concern is that with lower bler volte, it will be difficult for enb to convers and should uses higher MCS to get it, then impacting the coverage

        1. Yeah lower IBLER target, decreases MCS (more robust) and increases PRBs but it can increase RLC segmentation which can cause packet loss so a trade-off needs to be maintained.

      2. AoA Ali , really a good article and summarized everything beautifully in a simple way.

        Regarding BLER Target , yes understand setting Low BLER for VOLTE , will improve quality but as per my understanding, with Low BLER Target , a small MCs will be assigned and packet loss for cell centr users will improve and may be quality as well, but for Cell edge users no of RLC segments of uplink voice services increase and packet loss may increase and a subsequent loss of quality and possible Call drop ,( since cell edge user already in Poor Radio )
        Please comment on this understanding.

        Reason why i ask this is that Nokia use a lower BLER target by default and their average MOS is better than huawei . HUAWEI Introduced a similar parameter ‘ SinrAdjTargetIblerforVoLTE’ based on customer request and when we chnaged it to 1 or 2 or even 5 , we did not see much of an impact but a possible packet loss increase.
        Understand Huawei parameter may not work in same way as Nokia . Your comment will be highly awaited on this parameter and above question

        1. You are absolutely right. Increase in RLC segmentation due to lower TBS is bad for VoLTE. So, a tradeoff needs to be achieved where we get the most robust MCS without exceeding the RLC segmentation. Regarding the parameter, the working and allocation of MCS/PRB/TBS for Nokia and Huawei are different. In case, there was no improvement even after changing the IBLER targets, then it might mean that the packet loss issue faced over there is not related to HARQ retransmissions – it might be related to PDCCH or DRX or other possible issues πŸ™‚

  6. Hi, Many Mubeen – might be a good option to do a similar pitch for VoWFI – to go with VoLTE – if you’ve time etc

  7. Hello,
    Please share more VOLTE issue and thier workaround also share knowledge of VoWFI including vowifi timers, handover in detail (LTEVOwifi and vice versa)

Leave a Reply

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