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.

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.

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!

VoLTE Capacity Planning and Design: A Dimensioning Cheat Sheet

This video explains practical interactions between VoLTE capacity and LTE channels. It provides calculations with examples to ensure that anyone who has watched this video would be able to dimension and estimate VoLTE capacity for different configurations. In the end, it also provides projections for different VoLTE codecs that can be used as a quick cheat sheet instead of crunching numbers.

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

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.

Latest posts by Ali Khalid (see all)

• 5G SA Cell Search & Network Entry Matrix - July 18, 2023
• Top 5G Interview Question – 5G RACH Process - July 10, 2023
• 5G RSRP RSRQ SINR Conversion Mapping - June 30, 2023