VoLTE Features Discussion

We always talk about features for enabling VoLTE, i.e VoLTEenable itself and others are Robust Header Compression(ROHC), TTI bundling.
Most important thing is to undertsand this three feature concept, mainly two of them are much critical features ROHC & TTIbundling which are need for VoLTE, let disucsse them one by one:

Brief descriptions:

  1. ROHC is to compress the large size VoLTE packets.

  2. TTI bundling is for recovering link budget for Voice calls.

Detailed information:

  1. ROHC (Robust Header Compression)

ROHC is a kind of algorithm to compress the header of various IP packets. In case of IPv4, the size of uncompressed IP header is 40 bytes and in case of IPv6, the size of uncompressed IP header is 60 bytes.

Only 40 bytes and 60 bytes ? It sounds pretty small. Why do these matters ?

If it is ordinary packet application like file transfer or browsing, it would not be a big issue since the size of data being transferred would be very huge comparing to the size of header. So the overhead created by IP header would not be a big issue. But in some applications (e.g, VoIP, short message, gaming etc) the size of data being transferred tend to be small and they generate very frequent transactions, in this case overhead created by IP header gets very large. In this case, it would be huge benefit if we can come up with any method to reduce the size of IP header and ROHC is one of these method defined by RFC 3095. Ideal compression rate of ROHC is to reduce the size of header (40 or 60 bytes in original size) to only 1 or 2 bytes.

Basic idea of this compression method is pretty simple which can be described as follows.

i) At the start of a session (the initiation state), the transmitter and reciever sends the full size header without any compression.

ii) From step i), both transmitter and reciever extract all the information from the header and store them.

iii) After the initial transaction, the transmitter sends only those information that is different from the header information exchanged at the initial transaction. (Since a lot of information in the header would not change during the whole session, the size of changing part would become very small. So transmitting only the changing part would create the effect like data compression).

iv) Now perform real compression for the data still remaining after step iii)

Reference:

TTI Bundling:

Generally, the overall link budget in an LTE network is constrained by the maximum allowable path loss (MAPL) on the physical uplink shared channel (PUSCH). When evaluating MAPL for the PUSCH, key assumptions have to do with the modulation and coding scheme (MCS) for uplink transmissions and the number of resource blocks (RBs) the UE will be transmitting when at cell-edge. If we choose MCS and RBs to maximize coverage; e.g., an MCS which includes QPSK and 1 RB for uplink, this can cause issues when we want to support voice in the LTE network.
Voice over LTE (VoLTE) supports adaptive multi-rate coders (AMR). Without going into too many details, if we were to use a common AMR rate like 12.23 kbps or 12.65 kbps (wideband), which are fairly typical, we run into the issue that the only way to send this in the uplink using 1 RB would be to segment the packet – which causes other inefficiencies and issues. So, the alternative solution is to not fragment the packet and use 2 RBs for the uplink transmission.
Back to our link budget, by increasing the requirement for the number of uplink RBs at cell-edge from 1 RB to 2 RBs, we must consider the impact on receiver sensitivity – in particular, the amount of noise bandwidth the eNB receiver would have to overcome would increase by 3 dB. This would have the effect of reducing the PUSCH MAPL by 3 dB. We could improve the chance of the UE’s uplink packet success by adding more Hybrid ARQ (HARQ) transmissions. A typical configuration would allow 3 or 4 HARQ transmissions and the uplink reliability could be improved by increasing this to let’s say 8 transmissions. Now the problem isn’t so much link budget (coverage), but delay. For AMR speech, we have only 20 milliseconds between successive packets and each HARQ transmission (with A/N) in the uplink will take 8 milliseconds (8x8 = 64 milliseconds delay is far too long for speech). This is where TTI bundling can help.
TTI Bundling creates bundles of HARQ transmissions, where each transmission is sent in successive 1 millisecond transmission time intervals (TTIs). Specifically, a bundle will include four HARQ transmissions over four TTIs. This can allow us to have as many as 8 HARQ transmissions within the 20 millisecond window for AMR speech.

So, with TTI-Bundling and the maximum number of HARQ transmissions set to 8, we can overcome the link budget deficit created when changing the number of uplink RBs in a TTI from 1 to 2 on the PUSCH. There are some drawbacks to TTI Bundling which must be considered:
• TTI Bundling is for uplink only,
• When TTI Bundling is in use, the UE is limited to a maximum of 3 RBs in a TTI,
• The UE can only use QPSK with TTI Bundling,
• All radio bearers (not just the Data Radio Bearer for voice) will be subject to TTI Bundling.
This being the case, the eNB should have a criteria for turing on TTI Bundling for a UE which would include an indication that the UE is in a cell-edge condition (e.g., poor SINR), and only if the UE is using a service like voice (QCI =1) where the minimum number of RBs in a TTI is increased.
Semi-Persistent Scheduling (SPS)
As the importance of supporting voice in LTE networks (VoLTE) increases, concerns arise regarding the number of simultaneous voice calls that can be handled. One of the primary constraints is the amount of capacity on the Physical Downlink Control Channel (PDCCH). As a quick review, the PDCCH carries all allocation information for both the downlink and uplink shared channels, PDSCH and PUSCH respectively. Each allocation is carried as Downlink Control Information (DCI) and the size of the DCI depends upon several factors including whether it is for uplink or downlink allocation.

Since the PDCCH is limited size (generally, 3 OFDM symbol times), there is a limit as to how many DCIs can be carried in a subframe (1 ms). This can in-turn limit the number of UEs which can receive an allocation for that subframe when using dynamic scheduling (a 1:1 PDCCH-to-PxSCH method.

In order to support more allocations, without increasing the size of the PDCCH, we can use semi-persistent scheduling (SPS). With SPS, the UE is pre-configured by the eNB with an SPS-RNTI (allocation ID) and a periodicity. Once pre-configured, if the UE were to receive an allocation (DL / UL) using the SPS-RNTI (instead of the typical C-RNTI), then this one allocation would repeat according to the pre-configured periodicity.

During SPS, certain things remain fixed for each allocation : RB assignments, Modulation and Coding Scheme, etc. Because of this, if the radio link conditions change, a new allocation will have to be sent (PDCCH). Also, any incremental redundancy (HARQ subsequent transmissions) will be separately scheduled using dynamic scheduling. Also, to avoid wasting resources when a data transfer is completed, there are several mechanisms for deactivating SPS (explicit, inactivity timer, etc.).
So, with SPS which is well suited to periodic communication like voice, we can support many more allocations with the same PDCCH resource. This can allow more simultaneous VoLTE calls.

VoLTE: Air Interface Impacts
Voice over LTE (VoLTE) is getting a great deal of attention in the industry as we move away from circuit-switched calls. LTE, as defined in Release 8 of the 3GPP specifications includes several air interface capabilities that can be used to help VoLTE, but have for the most part not been used up to now.
To get an idea of the impacts, let’s review the Uu protocol stack:

When we establish dedicated communications over the air between a UE and an eNB, we create radio bearers. For each radio bearer, Signaling Radio Bearer (SRB) or Data Radio Bearer (DRB) which is established on the Radio Resource Control (RRC) connection, RRC signaling is used to establish the configuration of the various protocol stack layers. For example, for internet communcation it would be important to allow Radio Link Control (RLC) layer retransmissions.
For VoLTE, there are several air interface capabilities which we may use. These include: Robust Header Compression (RoHC), Unacknowledge Mode (UM) RLC, semi-persistent scheduling (SPS), and Transmission Time Interval (TTI) bundling.

Robust Header Compression (RoHC) takes an IP packet header and strips off the information that is already established between the UE and eNB, like the destination IP address. The effect can be significant for relatively small payload packets like voice, especially those using IPv6. In this case we could reduce the size of the header from 60 Bytes to 3 Bytes relative to the voice payload of about 30 Bytes.
Unacknowledge Mode (UM) RLC allows the eNB to monitor error rates without actually retransmitting packets. This is particularly useful for real-time bearers, like voice since retransmission can delay the packet to the point that it is no longer useful.
Semi-Persistent Scheduling (SPS) allows the eNB to establish a periodicity with the UE for resource allocation; thereby, significantly reducing overhead on the somewhat limited downlink control channel.
TTI Bundling allows as many as eight Hybrid ARQ (HARQ) transmissions to be sent in the uplink within the 20 millisecond (voice packet rate) timeframe. Additional HARQ transmissions can improve the reliability for cell-edge users.
As was mentioned, these are not new features. They are however features which will find usefulness in support of VoLTE.

LTE Link Budget and Uplink Throughput
When considering the LTE link budget, we focus a great deal on the uplink shared data channel (PUSCH) since it is often found to be our limiting link. Since the mobile’s transmit power and the environmental margins are generally established and out of our control, we look to several other factors that can combine to impact our PUSCH link budget including: mobile speed, modulation and coding, minimum uplink data rate, etc. If we assume that we are designing for some average mobile speed (e.g., mobile, but slow moving), then we must look to our requirements for the minimum uplink data rate to help us determine our link budget.
We know that the minimum allocation to a UE is 1 Resource Block (RB) over a subframe. Assuming QPSK with 1/3 rate encoding (to know our SNR requirement from TS 36.104), we can quickly calculate a throughput of about 96 Kbps (or 67 Kbps at cell edge where we expect 70% reliability). So, now we need to decide if an uplink throughput of 67 Kbps is sufficient for our applications and user experience requirements. This might be fine for texing or updating email, but would definitely become a problem for users trying to do uplink live streaming video.
A possible solution is for a higher minimum uplink throughput is to increase the number of RBs a mobile at cell edge can use from one to two; thereby, giving us about 130 Kbps uplink throughput for the cell-edge user. This change will impact the noise bandwidth which the receiver must overcome (part of receiver sensitivity) by 3 dB, reducing our Maximum Allowable Path Loss (MAPL) for the PUSCH.
In the end, it is important when designing for LTE to clearly define the minimum uplink throughput requirement at cell edge as this will directly impact our MAPL. So, if you plan to use features like uplink live streaming, include this in the planning and design phase of the network otherwise there will be some users who are unable to benefit from these services.
Hallway Conversations and Link Budgets
Many times when discussing link budget to someone new to the topic, a simple analogy helps. Consider you and I are having a hallway conversation and you start to walk away, at some point as you’re walking down this long hallway you will no longer be able to hear me. This is the maximum separation between transmitter and receiver, or in cellular parlance the Maximum Allowable Path Loss (MAPL). Extending our example, it is clear that if I speak louder you will be able to hear me from further away. Along the same line, how well you hear will be a factor as well. If it is my 83 year old father, with poor hearing – his receiver sensitivity is not as good as mine. I joke however that he has tower-mounted amplifiers (hearing aids) to improve his overall receiver noise figure. Finally, to end the analogy, if there are several people milling about in the hallway, then the maximum separation is reduced again by the environment. So, in this simple analogy we have the three components of our link budget transmitter power, environmental margins, and receiver sensitivity.
Capturing Traffic in an LTE Underlay Cell
There are several scenarios where a cell is deployed as a lower-power underlay to the macro cell network including in a building, at a stadium, at a shopping mall. From a cell selection or handover perspective, these cells may not achieve the relatively better criteria when compared to the overlaying macro cell.
A simple mechanism to address this would be the use of the LTE defined A4 measurement event as a trigger in the eNB for handover to the underlay cell. The A4 measurement event is threshold based as opposed to using a relative criteria, such that the event occurs when the UE measures a neighbor above the threshold. If this measurement event is used by the eNB to trigger a handover, then UEs can be attracted to the underlay cell.

RACH Access Success in LTE
During initial access of the LTE network, there are several factors that can affect the UE’s ability to successfully establish communication with the eNB. Typically, these issues are related to coverage and UEs operating at or near the defined cell edge.
Some of the parameters available to improve access success include Qrxlevmin, which defines the edge of coverage from a cell selection perspective, and the open-loop power parameters used by the UE to determine at what power to send a Preamble on the Physical Random Access Channel (PRACH).
As a means of example, let’s take some quick assumptions:
• Qrxlevelmin = -115 dBm
• InitialTargetPower = -107 dBm
• Reference Signal Power (as transmitted from eNB) = 18 dBm
• UE’s maximum transmit power = 23 dBm
Using these assumptions, a mobile that receives the downlink Reference Signal Receive Power (RSRP) at -114 dBm will consider itself to be within the coverage of the cell during cell selection (assuming no offsets are applied).
Calculating the Path Loss (PL) using RS Power and UE measured RSRP:
PL = 18 - (-114) = 132 dB
This PL value can be used the mobile will determine how much uplink power it requires to achieve InitialTargetPower for the initial preamble transmission: 132 + (-107) = 25 dBm. For a UE whose maximum power is 23 dBm, we can see that the UE doesn’t have enough power to achieve the desired InitialTargetPower for the Preamble transmission. While it can attempt Preamble several times to improve the chance of success, it loses the ability to ramp up power for the subsequent Preamble attempts.
To improve the success of RACH during initial access, settings for the selection Qrxlevelmin and /or the InitialTargetPower should be made so that UEs at the edge of the cell can achieve the desired signal strength.

Admin note: this post was updated with image below.

2 Likes

Hello @India5G.

I think you can update your list.

You need to care at least of:

  • Bearers
  • SRVCC
  • RoHC (as you already mentioned)
  • TTI Bundling (as you already mentioned)
  • Semi-Persistent Scheduling
  • Packet Aggregation
  • UL Packet Segmentation
  • DRX

Adding more features or functionalities which may or may not be needed everywhere.

  • Dedicated mobility events for QCI1: perform mobility with different values of RSRP/RSRQ than QCI8/9/internet bearer.
  • SRVCC delay upon QCI1 setup: adds extra delay to trigger a SRVCC to avoid aSRVCC and bSRVCC.
  • InactivityTimer delay: during call setup, depending on early media and ringback tone, UEs may go to RRC_IDLE during the SIP signaling, causing the call setup to fail. The feature adds extra time for inactivityTimer while the call is setup.
  • Codec Adaptation: some vendors support (never trialed) VoLTE codec adaptation based on eNB implementation.

Dear All,
Anyone can tell me if Network having 2 Carrier F1 & F2 and if we want to dedicate F1 only for VoLTE calls. Is it possible ? if yes how we can ?

yes its possible , exclude F2 by voic prio parameter , put -1. and make F1 as 7( highest prio)

Also worthy to check service comparison between (VoLTE and Data Service).

Main points :point_down:

  • Service setup
  • Service release
  • Service duration
  • Packet type
  • PDCP,RLC,MAC …

Credits: :point_down: