VoLTE Performance

Improvement features
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.
Logic of Header Compression

Basic idea of this compression method is pretty simple which can be described as follows.
At the start of a session (the initiation state), the transmitter and receiver sends the full
size header without any compression.
From step i), both transmitter and receiver extract all the information from the header and
store them.
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).
Now perform real compression for the data still remaining after step iii).
Component (State) of ROHC Statemachine -Compressor

ROHC has three main states as illustrated below. Try to correlate these states with the overall
algorithm description that I mentioned above.
Component (State) of ROHC Statemachine - Decompressor

There are four different ROHC Profiles defined in RFC 3095 as follows.

Profile 0 (ROHC Uncompressed) : Compresses packets, which cannot be compressed by

any of the following profiles
Profile 1 (ROHC RTP) : Compresses packets with IP/UDP/RTP protocol headers
Profile 2 (ROHC UDP) : Compresses packets with IP/UDP protocol headers
Profile 3 (ROHC ESP) : Compresses packets with IP/ESP protocol headers
An Example : ROHC Compression - VoLTE
Benefits of RoHC
RoHC can achieve a nearly 50% reduction in the size of VoLTE audio transmissions, thus decreasing bandwidth
needed for any single call and increasing the overall number of users on an eNodeB site

Increase in cell range as with RoHC, lower MCS and lower throughput per user so increase in cell range.

Parameters to set: activate use of PDCP RoHC and maximum no. of RoHC contexts used for data radio bearer in
one direction
Possible application : VoLTE

One of the applications for which people are most actively talking about ROHC would be VoLTE
since there can be a lot of small data chunks carried by huge IP packets. For example, there
can be a cases where only around 30 bytes of voice data (coded data) carried with around 60
bytes of header. In this case, only header parts takes more resources than the real data itself.
So this kind of packet can be a good candidate for ROHC.

VoLTE has two kinds of packets.

1) SIP Signaling packet
2) Voice traffic packet.

The voice traffic part tend to be a very small data size but cause very frequent transmission.
So ROHC can be a very efficient solution to save network resources. But for SIP signaling part,
the header compression may not be so efficient because the size of SIP signaling packet tend
to be relatively huge comparing to header size. Of course, even in this case you can save a
little bit of resource, but the processing overhead caused by header compression processing
can be even bigger. So normally, ROHC does not apply to SIP signaling message packet.
Packet Segmentation
Packet segmentation wherein a VOIP payload is split into smaller size PDUs as shown in Figure
below.
The smaller PDUs will result in smaller transport blocks which can be decoded with better
accuracy.
One drawback of this method is the potential overhead increase due to segmentation due to
multiple headers needed.
For a typical VOIP payload, it has been shown that as we increase the segmentation factor from 1
to 8, the overhead increases from 14% to 55%.
Each PDU which is mapped into a transport block will need a separate PDCCH assignment
message which will contribute to control signal overhead for such a scheme.
There might be retransmissions of each of those transport blocks which will also potentially
increase the control signalling overhead.
In addition, since we are transmitting many small transport blocks, the chances of interpreting a
NACK as a ACK also increases proportionately with the increase in the segmentation size. Hence,
packet segmentation has many disadvantages when we consider the transmission of a VOIP like
payload from a power limited terminal.
TTI Bundling
TTI bundling is a technique used to send a transport block multiple times in consecutive subframes
without waiting for HARQ ACK/NACK messages.

TTI bundling is used to achieve successful transmissions

from power limited terminals.
The process as shown in Figure is typically triggered by
UE informing the eNB about its power limitations at the
present state.
This could for example happen at the edge of a cell when
the terminal has to send high power but is limited by the
power capability of the terminal.
This triggers the eNB to transmit the various redundancy
versions of the same transport block in consecutive
subframes or TTIs giving rise to the name TTI bundling.
A single PDCCH allocation is sufficient for the multiple
transmissions thus saving control overhead as compared
to the packet segmentation approach.
TTI Bundling Operation
TTI bundling enables up to 4 redundancy versions of the
same transport block to be sent in 4 consecutive
subframes.
A single RLC PDU is transmitted as multiple redundancy
versions in consecutive subframes using a single
common allocation.
The channel coding used in LTE enables easy
generation of the multiple redundancy versions from
which the transmissions in the TTI bundle are
generated.
A common RLC header is shared across the TTI bundle
and the same HARQ process identity is used for
multiple transmissions in the TTI bundle.
Combined processing of the redundant transmissions
When BLER increases and Link Adaptation has no more over multiple subframes leads to a better probability of
options for MCS/PRB reduction while radio conditions
for handover are not fulfilled, TTI Bundling can be
detection of the transport block. Thus, with limited
triggered to sustain the voice call quality before UE will power, the UE has a better chance of a successful
either change the cell or RF conditions becomes better. transmission with lesser latency using the TTI bundling
method.
Triggering Criterion
UE is transmitting with the lowest possible MCS index
UEs maximum PRB assignment is the lowest possible PRB assignment.
TTI BLER threshold is reached.

This trigger condition shall be checked with every UL transmission of the UEs and if the trigger condition is
fulfilled, the eNB shall inititate the process to start TTI bundling for the UE.
Semi-Persistent Scheduling
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).

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).
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.
 CDRX (Connected Mode DRX)
Even while there is no traffic between the network and UE, UE has to keep listening to Network. At
least it should be ready to decode PDCCH. It means UE has to be "ON" all the time even when there
is no traffic. But being ON all the time would drain the battery.
Solution: UE get into sleeping mode for a certain period of time and wake up again checking if there is any
data coming from the network and getting into sleeping mode again if there is no data and wake up again...
repeating this cycles. This kind of periodic repetition of "sleep mode and wake up mode" is called DRX
(Discontinuous Reception).
Implementing DRX may not be as simple as you may expected
because there should be well designed synchronization
between UE and Network.
So, Network decide when to let UE sleep and when to wake it up and
inform the timing to the UE using a RRC message.
Network informs UE of this timing using
RRC ConnectionReconfiguration or RRC Connection Setup as shown.
 The eNodeB configures the following RRC parameters for DRX. Entire DRX configuration is sent
under drx-config structure under MAC-MainConfig.
In RRC specification, almost all the DRX timer values are specified in terms of psfs. psf is a PDCCH
subframe in which UE listens for PDCCH.
drx-Inactivity-Timer specifies the number of consecutive PSFs for which the UE should be Active after successfully decoding
a PDCCH indicating a new transmission (UL or DL) . This timer is restarted upon receiving PDCCH for a new transmission (UL
or DL). Upon the expiry of this timer the UE should go to DRX mode.
shortDRX-Cycle is the first type of DRX cycle (if configured) that needs to be followed when UE enters DRX mode. This IE
indicates the length of the short cycle in subframes which include ON time followed by a possible OFF (inactivity) time.
drxShortCycleTimer expressed as multiples of shortDRX-Cycle. The timer value can vary from 1 to 16 (short DRX cycles). This
timer indicates the number of initial DRX cycles to follow the short DRX cycle before entering the long DRX cycle
longDRX-CycleStartOffset defines long DRX cycle length as well as the DRX offset. DRX offset is used to calculate the
starting subframe number for DRX cycle.
onDurationTimer specifies the number of consecutive PDCCH-subframe(s) at the beginning of each DRX Cycle (DRX ON).
i.e., is the number of subframes over which the UE shall read PDCCH during every DRX cycle before entering the power
saving mode (DRX OFF)
HARQ RTT Timer specifies the minimum amount of subframe(s) duration from the time new transmission is received and
before the UE can expect a retransmission of the same packet. This timer is fixed and not configured by RRC. For FDD the
HARQ RTT Timer is set to 8 subframes. For TDD the HARQ RTT Timer is set to k + 4 subframes, where k is the interval
between the downlink transmission and the transmission of associated HARQ feedback
drx-RetransmissionTimer indicates the maximum number of subframes for which UE should be monitoring PDCCH when a
retransmission from the eNodeB is expected by the UE.
DRX Command MAC Control Element
These timers the eNodeBs MAC can also control UEs DRX behavior by transmitting a command called DRX Command as a MAC
Control Element.
When the eNodeB doesnt have any (more) data to be sent to the UE, it can transmit DRX Command MAC CE to the UE. Upon
reception of DRX Command MAC CE, the UE enters short DRX cycle if configured, otherwise, the UE enters long DRX cycle.

DRX Operation
When there is no data activity for drx-InactivityTimer amount of time (i.e., upon expiry ofdrx-InactivityTimer) or DRX Command
MAC CE is received,
- if the Short DRX cycle is configured, then the UE should start or restartdrxShortCycleTimer and start using Short DRX Cycle. Else
if Short DRX cycle is not confired, the UE should use the Long DRX cycle
If drxShortCycleTimer expires, i.e., maximum number of short cycles are already used, then the UE should enter the Long DRX
cycle
If a DRX Command MAC control element is received, the UE should stop onDurationTimer and drx-InactivityTimer

UE Capability Information for DRX Supportability

Even though CDRX is a very important feature in terms of energy saving on UE side and a lot of live network enables this feature,
it is not the mandatory requirement on UE.

DRX improves battery consumption and lower number of HAQ retransmissions.

 RLF Handover
RLF handover is UE-based mobility and provides a recovery
mechanism when the backward handover signaling with the
source cell partially fails due to poor radio conditions.

When the UE detects radio link problems, it starts the RLF

timer, a typical setting for which is 500 ms or 1000 ms. The RLF
timer is carefully fine tuned by the service provider based upon
extensive drive tests within the network. Upon expiration of
the RLF timer, the UE searches for a suitable target cell and
attempts to re-establish its connection with the target cell
while remaining in connected-state.

The re-establishment is successful if the target cell has been

prepared by the source eNB (i.e. if the source eNB received the
Measurement Report from the UE).
RLF triggered handover allows for re-establishment even towards the unprepared cell
 RRC:RRCConnectionReestablishmentRequest sent by the UE to the cell B covers information about PCI, C-RNTI,
shortMAC-I used so far in serving cell A

Based on the received PCI value, Other eNB recognizes that the so far serving cell A does not belong to Other
eNB

This is the trigger for sending of X2AP: RLF INDICATION by Other eNB

The crucial information is that X2AP: RLF INDICATION message is sent to all eNBs for which NR is identified by
PCI signaled in RRC:RRCConnectionReestablishment (the serving eNB is one of them); this may happen because
PCI values 0503 are repeated in the network

The gain should come from the RRC establishment success rate improvement and therefore reduced mute
time, i.e. silence period due to the RLF and rrc connection re-establishment.