Module 2 - VoLTE Performance Enhancing Features

 RLC Unacknowledged Mode

 TTI Bundling
 Robust Header Compression (RoHC)
 Discontinuous Reception (DRX)
 Multi-Target RRC Connection Re-establishment
 Voice Uplink coordinated multipoint reception (UL CoMP)
 RLC Segmentation Enhancement
 DL Power Boosting
 Reference Signal Power De-Boosting
 Dynamic/Semi Persistent Scheduling for VoLTE
 VoLTE Rate Control
RLC Unacknowledged Mode
RLC MODES OF OPERATION
RLC Unacknowledged Mode

 RLC UM
– supports concatenation and segmentation attempting to establish the original order of PDUs and
SDUs but does not perform any error recovery
– saves 8 bits overhead in each transport block compared with RLC AM.
– is a feature that is licensed per node and implemented per QCI.

 How does it work?

– RLC UM machine starts t-Reordering when detecting a gap, same as RLC AM.
– But when timer expires UM does not like AM do own retransmission but rather trusts lower layers to
have provided enough time for re-ordering.
– RLC UM ignores any gaps that might still occur and continues to deliver in ascending order to higher
layers.
– If any missing RLC SDUs arrive later they are discarded since they arrive outside re-ordering window
RLC in Unacknowledged Mode

 This feature is useful for services that tolerate a higher packet loss rate but require lower
latency.
 Parameters

 RlcPdcpParaGroup.RlcMode
– QCI 1-3: RlcMode_UM(Un-acknowledge Mode)
– QCI 4-6: RlcMode_AM(Acknowledge Mode)
– QCI 7: RlcMode_UM(Un-acknowledge Mode)
– QCI 8-9: RlcMode_AM(Acknowledge Mode)
– QCI 65-66: RlcMode_UM(Un-acknowledge Mode)
– QCI 69-70: RlcMode_AM(Acknowledge Mode)
RLC in Unacknowledged Mode

 In one eNB, the operator can configure up to three RLC in Unacknowledged Mode feature
bearers by setting the attribute rlcMode to UM for each Quality of Service Class Indicator
(QCI).

 RLC-UM works with the HARQ functionality.

RLC in Unacknowledged Mode - Handover

 The RLC mode of the bearers must not be changed during handover. If the RLC mode for the
bearers are different in the source and the target, the bearers are not setup in the target.

 The RLC mode is configured for each QCI by eNB. If the source eNB has a bearer with QCI
configured with the RLC UM feature and the target eNB has mapped the same QCI to RLC
AM, the bearer is rejected.
WHY DO WE NEED RLC UM?
LOFD-001048 TTI Bundling
LOFD-001048 TTI Bundling
 Why TTI Bundling?
 One of the key issues for the LTE users (not only limited to
VoIP users) is the UL coverage
– due to the limited transmission power it may happen that the
UE will not spend enough energy during one TTI to achieve
successful transmission towards eNB
• it may result in the number of retransmissions contributing to
additional delay which might be intolerable for delay-sensitive
services as VoIP

 TTI bundling is specified in 3GPP (TS 36.213, 36.321) to allow the

improved uplink performance for cell border UEs (which often hit the
maximum transmission power) and for reduced PDCCH load.

 TTI bundling allows for transmitting the same transport block in 4

consecutive UL subframes (also known as bundle size), which leads
to increased energy per transmitted bit and therefore improved
uplink link budget.
TTI Bundling from UE perspective

 One of the prerequisites for the TTI Bundling is support from the UE
– Depending on the release, whether UE is 3GPP Re8 compliant (accessStratumRelease=rel8) or
3GPP Re9 (or higher releases) compliant (accessStratumrelease>=rel9), different Feature Group
Indicators are used to inform the network of the TTI Bundling support

 UE is TTI Bundling capable if the following FGI bits are set to TRUE:
– In case of 3GPP Re8 compliant UE
• Bit 3 (TTI Bundling, SPS, 5bit RLC UM
SN, 7bit PDCP SN)
• Bit 7 (RLC UM)

– In case of 3GPP Re9 compliant UE

• Bit 28 (TTI Bundling)
 VoLTE – Handset Compatibility

 Feature Group Indicator for TTI Bundling

Supports TTI
Bundling
Prerequisites for the TTI Bundling – Bearer Combination

 Another prerequisite for the TTI Bundling is the proper bearer combination:
– the UE is candidate for switching to the TTI Bundling mode if at least one of the currently used
bearers is configured as a ‘TTI Bundling supporting’.

 If UE is a candidate for TTI Bundling the bearer combination is always checked at:
– E-RAB Setup
– E-RAB Release
– Incoming handover
– E-RAB modification
TTI Bundling entering criteria

 In eRAN8.1, the CellUlschAlgo.TtiBundlingTriggerStrategy parameter is introduced.

 When the TtiBundlingTriggerStrategy parameter is set
to SERVICE_VOIP(SERVICE_VOIP), TTI bundling applies to only VoLTE. Under this
parameter setting, the conditions for entering the TTI bundling state are as follows:
– The TtiBundlingSwitch of the eNodeB is turned on.
– The UE supports TTI bundling.
– The UE has only one QCI 1 dedicated bearer and stays in the talk spurts state. In addition, the UE
does not have data to transmit on the data bearer.
– The UL power of the UE is limited.
– The measured SINR is less than the target SINR for multiple consecutive times. The number of
consecutive times is specified by CellUlschAlgo.StatisticNumThdForTtibTrig.
 If the UE meets all these conditions, the eNodeB sends the UE an RRC Connection
Reconfiguration message, instructing the UE to enter the TTI bundling state.
TTI Bundling entering criteria

 When the TtiBundlingTriggerStrategy parameter is set

to SERVICE_MULTIAPP(SERVICE_MULTIAPP), TTI bundling can apply to VoLTE or a
combination of VoLTE and data. Under this parameter setting, the conditions for entering the
TTI bundling state are as follows:
– The TtiBundlingSwitch of the eNodeB is turned on.
– The UE supports TTI bundling.
– The UE has a QCI 1 dedicated bearer.
– The UL power of the UE is limited.
– The measured SINR is less than the target SINR for multiple consecutive times. The number of
consecutive times is specified by CellUlschAlgo.StatisticNumThdForTtibTrig.
 If the UE meets all these conditions, the eNodeB sends the UE an RRC Connection
Reconfiguration message, instructing the UE to enter the TTI bundling state.
 The target SINR is controlled by CellTtiBundlingAlgo.SinrThdToTrigTtib. If this parameter
is set to 255, the target SINR is dynamically calculated based on the size of voice packets.
TTI Bundling

 Intra-cell handover – procedure flow

UE eNB

TTI Bundling entering conditions fulfilled

RRCConnectionReconfiguration
PDSCH

RA Preamble
PRACH

Random Access Response PDCCH

PDSCH

Scheduled Transmission (Msg3)

PUSCH
Transmission in TTIB mode

Contention Resolution
PDCCH

RRCConnectionReconfigurationComplete
PUSCH

UL Grant
PDCCH
PUSCH
UL Data Transfer
TTI Bundling

 Intra-cell handover – provisioning of TTI Bundling configuration

 UE is provided with TTI Bundling configuration parameters via
 IE: RadioResourceConfigDedicated transferred via RRC: Connection Reconfiguration
message

When intra-cell HO is triggered to switch the UE from TTIB mode

into normal mode, the following configuration is used:
RadioResourceConfigDedicated IE • maxHARQ-Tx is set according to the harqMaxTrUl parameter
• ttiBundling set to ‘FALSE’
Semantic Description / • drx-config: choice = setup (if DRX will be used by the UE)
IE/Group Name
Comments
Omitted – not used for
srb-ToAddModList mac-MainConfig IE
reconfiguration
Omitted – not used for IE/Group Name Semantic Description / Comments
drb-ToAddModList ul-SCH-Config
reconfiguration
Omitted – not used for Set according to the
drb-ToReleaseList > maxHARQ-Tx harqMaxTrUlTtiBundling parameter when
reconfiguration
mac-MainConfig Present UE enters TTIB mode
Omitted – not used for > ttiBundling ‘TRUE’ if UE is entering TTIB mode,
sps-Config
reconfiguration
 choice: release
... drx-config DRX is deactivated if the UE enters TTIB
mode
phr-Config Omitted – set at RRC Connection Setup
…
TTI Bundling Mode Configuration – Intra-cell Handover

 Once the criteria for entering TTIB mode are fulfilled, eNB triggers intra-cell handover
procedure by sending RRC Connection Reconfiguration message towards the UE.

Intra-cell
Intra-cell HO
HO

max.
max. HARQ
HARQretransmissions
retransmissionsin
inTTIB
TTIB

UE
UE is
isentering
enteringTTIB
TTIBmode
mode
TTI Bundling
 Transmission characteristic in TTI Bundling mode (1/3)

TTI# 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2
1 2 4 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
UL grant on
PDCCH

Tx on PUSCH RV0 RV2 RV3 RV1 RV0 RV2 RV3 RV1

Decoding

ACK/NACK
on PHICH N N

1st bundle transmission Retransmission of bundle

HARQ RTT: 16 TTIs
TTI Bundling
 Transmission characteristic in TTI Bundling mode

TTI# 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2
1 2 4 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
UL grant on
PDCCH

Tx on PUSCH RV0 RV2 RV3 RV1 RV0 RV2 RV3 RV1

Decoding

ACK/NACK
on PHICH N N
3 PRBs
QPSK modulation only
 TTI Bundling

 Transmission characteristic in TTI Bundling mode

TTI 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

PDCCH                                                                                                        

328 328 328 328

PUSCH                                                                        
RV RV RV RV RV RV RV RV RV RV RV RV RV RV RV RV
0 2 3 1 0 2 3 1 0 2 3 1 0 2 3 1

Decodin                                                                                                        
g

PHICHInitial
   transmission
          N                 1st  retransmission
            N                 2nd  retransmission
            N               3
  rd retransmission
       

In total: 4 TB transmissions 8 TB transmissions 12 TB transmissions 16 TB transmissions

TTI Bundling

 Link Adaptation in TTI Bundling (1/2)

 Link Adaptation for UEs in TTI Bundling mode is separate from link adaption used for other
UEs

 Adaptive Modulation and Coding selects appropriate MCS for UL

transmission taking into account actual transmission reliability (BLER)

 Adaptive Transmission Bandwidth is responsible for defining maximum number of PRBs that
can be assigned to a particular UE by UL SCH
TTI Bundling

 Link Adaptation in TTI Bundling continued

 Because in TTIB mode the number of PRBs allocated to the UE is fixed
to 3, the only task of the LA is to select the MCS for the UL
transmission
– Link Adaptation in TTIB mode consists only of a function that performs AMC

– In TTI Bundling Mode, Link Adaptation may utilize MCS Index range that
goes from 0 to 24
– however with default setting of ulsMinTbs=104, Link Adaptation in TTI
Bundling will operate on MCS range from 2 to 24
– note that in TTI Bundling the Modulation Order is fixed to 2 and therefore
only QPSK modulation is possible

– The mechanism of MCS adjustment in TTIB mode works in the same way
as in normal mode with dedicated BLER target for TTIB →
ttiBundlingBlerTarget
TTI Bundling - Leaving Conditions

 The eNodeB does not instruct the UE to exit the TTI bundling state even when the UE has
data to transmit on the default bearer, needs to set up a new dedicated bearer, or stops the
voice service (QCI 1). The eNodeB instructs the UE to exit the TTI bundling state when the
UE meets the exit conditions, experiences handover or service drop, or needs to reestablish a
new connection.
– If the voice service is not released, the eNodeB instructs the UE to exit the TTI bundling state
through an RRC Connection Reconfiguration message when the measured SINR is greater than the
sum of the target SINR and the CellUlschAlgo.HystToExitTtiBundling parameter value for multiple
consecutive times. The number of consecutive times is specified by
the StatisticNumThdForTtibExit parameter.
– If the voice service is released, the eNodeB instructs the UE to exit the TTI bundling state through an
RRC Connection Reconfiguration message when the measured SINR is greater than MIN{(target
SINR + CellUlschAlgo.HystToExitTtiBundling), 6 dB} for multiple consecutive times. The number
of consecutive times is specified by the StatisticNumThdForTtibExit parameter.
TTI Bundling to Normal Mode Configuration – Intra-cell
Handover
 Once the leaving conditions are fulfilled, the intra-cell handover procedure is triggered to
switch the UE into normal UL transmission mode

HARQ
HARQretransmissions
retransmissionsin
innormal
normal mode
mode

UE
UEis
is leaving
leavingTTIB
TTIBmode
mode
Benefits And Characteristics

 Feature Benefits
– In poor RF, the SINR gain enables larger TB size, enabling the transmission of entire VoIP packet.
– More robust format, requires less retransmissions
– Improves quality delay sensitive services, such as VoIP

 Restrictions
– TTI Bundling is currently only valid for FDD.
– The feature is more suited to real-time services like VoIP that have small packets with stringent delay
requirements.

 Other characteristics
– 4 HARQ processes instead of 8
– HARQ Restransmission period is 16 ms instead of 8 ms
TTI Bundling Mode Started – TTI Trace Analysis

The uplink non-adaptive HARQ operation

requires a predefined RV sequence 0, 2, 3, 1
HARQ
HARQ process
process ID
ID is
is the
the same
same for
for for the bundled subframes
each of the bundled subframes (1)

The
The link
link adaptation
adaptation selects
selects only
only MCS
MCS due
due
After to
to fixed
fixed numer
numer of
of PRBs
PRBs (3).
(3). The
The effective
effective
After intra-cell
intra-cell HO
HO TTI
TTI bundling
bundling is
is
activated with new C-RNTI (8022) coding rate is reduced for the TTI bundle
and thus, MCS index can be increased
TTI Bundling – Counters

Counter ID Counter Name Counter Description

1526728496 L.Traffic.User.TtiBundling.Avg Average number of UEs on which TTI bundling takes effect in a cell
1526728911 L.Signal.Num.TtiBundling.Enter Number of messages sent for instructing UEs to enter TTI bundling mode
1526728912 L.Signal.Num.TtiBundling.Exit Number of messages sent for instructing UEs to exit TTI bundling mode
Network Impacts

 TTI bundling has the following impacts on network performance:

– TTI bundling increases PUSCH coverage, improves the MCS index in uplink weak-coverage areas,
and reduces the packet loss rate.

– However, this function increases signaling overheads because RRC messages are exchanged when
UEs enter and exit the TTI bundling state.

– When the number of TTI bundling mode reconfiguration messages (indicated by the counters 
L.Signal.Num.TtiBundling.Enter and L.Signal.Num.TtiBundling.Exit) increases, the average
board CPU usage (indicated by the counter VS.BBUBoard.CPULoad.Mean (%)) slightly increases.

– A UE in the TTI bundling state uses a high MCS index. This increases the probability of DTX for
PDSCH HARQ feedback and increases Downlink Packet Loss Rate.

– In this situation, you are advised to change the value of CellUciOnPuschPara.

DeltaOffsetAckIndexForTtiB from its default value 9 to 11 so that Downlink Packet Loss Rate
 does not increase much.
Network Impacts

 TTI bundling has the following impacts on network performance:

– TTI bundling uses a maximum of three PRBs, a modulation scheme of QPSK, and an MCS index no
higher than 10.

– When TTI bundling is enabled, no more than 504 bits can be transmitted within each TB, which
restricts the uplink throughput of UEs in the TTI bundling state.

– As signaling and voice services are given precedence over data on logical channels, the UEs will
preferentially transmit signaling and voice services, further restricting the uplink throughput of data
services.
Network Impacts

 (FDD) The enhanced TTI bundling algorithm has the following impacts on network
performance:
– The highest MCS index is no longer confined to 10. This may further increase the probability of DTX
for PDSCH HARQ feedback. As a result, the Downlink Packet Loss Rate (VoIP) increases.
– After RRC connections are reestablished, UEs stay in the TTI bundling state, during which a high
MCS index is used. This increases the probability of DTX for PDSCH HARQ feedback. As a result,
the Downlink Packet Loss Rate (VoIP) increases.Enhanced TTI bundling has better coverage
performance than common TTI bundling. However, enhanced TTI bundling uses a high MCS index,
which increases the probability of DTX for PDSCH HARQ feedback. Therefore, enhanced TTI
bundling is recommended only when the uplink packet loss rate is high and the downlink packet loss
rate is low.
 (FDD) When TTI bundling is enabled, setting CellTtiBundlingAlgo.R12TtiBundlingSwitch
 to ON has the following impacts on network performance:The highest MCS index is no longer
confined to 10. This may further increase the probability of DTX for PDSCH HARQ feedback.
As a result, the Downlink Packet Loss Rate (VoIP) increases.
LOFD-001017 RObust Header Compression (ROHC)
Robust Header Compression

 The ROHC feature provides a mechanism for efficiently compressing data packet headers.
This feature is specially designed for radio links with high bit error rates (BERs) and long
round trip time (RTT). Currently, ROHC can be used only for compressing voice packet
headers during QCI 1 and push to talk320bits
(PTT) services.

24bits 40bits 244bits

 Basic Framework

Packet Flow Compressed packets

DL direction Header Header
Compression Decompression
Feedback

Context Context
Benefits

 ROHC helps reduce header overheads and packet loss and shortens the response time,
improving network performance. Compared with other header compression mechanisms,
such as IP Header Compression (IPHC), ROHC has the following advantages:

 Robustness
– Due to its feedback mechanism, ROHC is robust on the radio links with a high BER and long RTT.

 High compression efficiency

– Some simple header compression algorithms, such as IPHC and Compressed Real-Time Transport
Protocol (CRTP), can compress the header to 2 bytes, while ROHC can achieve compression to as
small as 1 byte. Therefore, ROHC has higher compression efficiency.
RoHC– States of Operation

Compressor No header Compression Decompressor

States States
Initial state. In this phase compressor:
• sends complete uncompressed header information (static and non-static fields)
Initialization No Context
• initializes static parts of context or recovers after failure
and Refresh IR
• stays in this state until decompressor has received static information correctly

State activated after successful reception of context information. In this phase:

• all static fields and most of dynamic fields are compressed
First Order FO Static
• if some parts of a header change during transmission, context can be changed in FO state Context
• This phase persists until patterns of dynamic fields are acquired by decompressor

This state offers the most optimal compression

• only sequence number and partial checksum are transmitted
Second Order Full Context
• if header changes during the transmission compressor must switch back to First Order
SO state

Full Header Compression

RoHC

Uncompressed transmission Compressed transmission

IP/UDP/RTP header MAC header, RLC

consisting of header, VoIP Initial transmission,
“from now on “context” is initialized so
predictable and payload, CRC
assume that next transmissions
unpredictable fields - checksum - not
Destination IP is can be compressed
subjected to subjected to
10.0.0.10”
compression compression

10.0.0.1 6 10.0.0.1 x 6
0 0

10.0.0.1 3 3
0

10.0.0.1 7 7
0

10.0.0.1 0 0
0

10.0.0.1 1 1
0

10.0.0.1 8 8
0 Context - information
about all fields that are
Field predictable in In the course of
predictable and their
the course of transmission header fields
Unpredictable change patterns sent in
transmission – initialized in context do
field the beginning of
“Destination IP” not have to be transmitted
transmission to allow
header compression
RoHC Benefits

 Gross throughput per user is decreased by 46% when RoHC is used. Therefore, more voice
users can be scheduled or better voice codecs can be used
 Significant gain (2.5dB) can be achieved when using RoHC (lower MCS due to lower
throughput per user), which translates to 14% larger cell range
 Parameters:
– Rohc Activation Switch (eNB/Cell): activates the usage of PDCP Robust Header Compression
– Profiles: Indicates the compression profile supported by the eNodeB. or maximum number of ROHC
contexts used for a data radio bearer in one direction
 Performance Monitoring Counters:
– PDCP.UL/DRoHC.HdrCompRatio: Compression rate of headers of all uplink/downlink PDCP SDUs
after ROHC
– PDCP.URoHC.FailDecompRatio: Decompression failure rate of all uplink PDCP SDUs after the
ROHC
– Traffic.User.RoHC.Avg/Max: Average/Maximum number of UEs on which ROHC takes effect in a cel
– ChMeas.PRB.DL/UDrbUsed.Avg.VoIP: Average number of PRBs used by DRBs on the
PDSCH/PUSCH for downlink/Uplink VoIP services
ROHC Operating Modes

 ROHC operates in Unidirectional Mode (U-Mode), Bidirectional Optimistic Mode (O-Mode), or

Bidirectional Reliable Mode (R-Mode) mode. The ROHC reliability and overheads used for
transmitting feedback differ between modes.
 The initial operating mode of the compressor is U-Mode. After confirming packet reception by
the decompressor and receiving the expected-mode indication from the decompressor, the
compressor switches to O-Mode or R-Mode. The operating mode transition is determined by
the decompressor.
 When the eNodeB is the compressor, the UE works as the decompressor and triggers
operating mode transition for the eNodeB.
 When the eNodeB is the decompressor, it determines the target operating mode based on
the PdcpRohcPara.HighestMode parameter and instructs the UE to change the operating
mode.
– If the PdcpRohcPara.HighestMode parameter is set to R_MODE(Bi-Directional Reliable Mode),
the UE can switch to a higher mode (O-Mode or R-Mode) and stay in R-Mode.
– If the PdcpRohcPara.HighestMode parameter is set to O_MODE(Bi-directional Optimistic
Mode), the UE can switch to and stay in O-Mode.
ROHC Operating Modes

 In U-Mode,
– packets can be sent only from the compressor to the decompressor. Feedback channels are not
mandatory. Compared with O-Mode and R-Mode, U-Mode has the lowest reliability but requires the
minimum overheads for feedback.

 O-Mode
– In O-Mode, the decompressor can send feedback to indicate failed decompression or successful
context update. O-Mode combines U-Mode and feedback information. Therefore, it provides higher
reliability than U-Mode, yet generates less feedback than in R-Mode.
ROHC Operating Modes

 In R-Mode, context synchronization between the compressor and decompressor is ensured

only by the feedback. The compressor repeatedly sends the context updating packets until an
acknowledgment is received from the decompressor. R-Mode leads to greatest amount of
acknowledgment data and largest link overhead, but provides the highest reliability.

 Operating mode of ROHC used on the uplink

– This mode is determined by eNodeBs. In U-Mode, the compressor periodically switches to a lower
state, which decreases the compression efficiency. In O-Mode or R-Mode, the compressor does not
need to periodically switch to a lower state, which helps increase the compression efficiency.
Factors Affecting the ROHC Compression Efficiency

 The factors affecting the ROHC compression efficiency can be classified into factors that can
or those that cannot be controlled by the eNodeB.
 Of the factors that cannot be controlled by the eNodeB, the most significant are those having
to do with the service data. These factors are also the primary elements impacting ROHC
efficiency. They include:
– Header format of the data packets on a DRB
– Payload size of each data packet on a DRB
– Number of packet flows on a DRB
– Method used to handle data packet headers at the application layerI.
– Operating mode of ROHC used on the downlink
 The controllable factors include:
– Operating mode of ROHC used on the uplink
– Lower-layer transmission quality
RoHC Performance Monitoring
Counter ID Counter Name Description Principle
1526728522 L.PDCP.UL.RoHC.Hdr Compression rate of headers of all uplink PDCP SDUs after ROHC The compression efficiency
CompRatio has a negative correlation with
the values of these counters.
1526728523 L.PDCP.UL.RoHC.Pkt Compression rate of all uplink PDCP SDUs (including headers and
CompRatio payloads) after the ROHC

1526727349 L.PDCP.DL.RoHC.Hdr Compression rate of headers of all downlink PDCP SDUs after the
CompRatio ROHC

1526727350 L.PDCP.DL.RoHC.Pkt Compression rate of all downlink PDCP SDUs (including headers
CompRatio and payloads) after the ROHC

1526727351 L.PDCP.UL.RoHC.Fail Decompression failure rate of all uplink PDCP SDUs after the The decompression success
DecompRatio ROHC rate has a negative correlation
with the value of this counter.

1526728524 L.Traffic.User.RoHC.M Maximum number of UEs on which ROHC takes effect in a cell The number of UEs on which
ax ROHC takes effect has a
1526728525 L.Traffic.User.RoHC.A Average number of UEs on which ROHC takes effect in a cell positive correlation with the
vg values of these counters.

1526730883 L.ChMeas.PRB.DL.Dr Average number of PRBs used by DRBs on the PDSCH for These counters are used to
bUsed.Avg.VoIP downlink VoIP services observe the changes in the
number of RBs used in the
1526730884 L.ChMeas.PRB.UL.Dr Average number of PRBs used by DRBs on the PUSCH for uplink downlink and uplink by VoLTE
bUsed.Avg.VoIP VoIP services users before and after ROHC
is enabled.
LBFD-002017 DRX
Discontinuous Reception (DRX)

 DRX is a technology in which a UE can switch between active and sleep states.
– When the UE needs to receive downlink (DL) data or signaling, the UE turns on its receiver and
enters the active state.
– In other situations, the UE turns off its receiver and enters the sleep state to reduce power
consumption.
 Benefits
– Reduces power consumption and prolongs the standby time of the UE.
– The UE does not need to constantly monitor the physical downlink control channel (PDCCH).
– The UE can turn off its radio frequency (RF) receiver and other communication modules.
– Allows the UE to perform ANR measurement during the sleep time in DRX.
 DRX Parameters timers:
– OnDurationTimer
– DRXInactivityTimer
– DRXReTxTimer
– LongDrxCycle
– ShortDrxCycle
– DrxShortCycleTimer
– SupportShortDrx
Switching Between Active Time and Sleep Time
– OD: A DRX cycle starts.
– IA: A PDCCH message
indicating an initial DL data
transmission is received.
– R: The HARQ RTT Timer
expires.
– SR: A UL scheduling request is
sent.
– UR: A UL negative
acknowledgment (NACK) is
received, and retransmission is
required.
– RAR: A non-contention-based
random access response is
received.
– CR: Msg3 is sent in a random
access procedure.
Relationship with QCIs

 Services with different QoS class identifiers (QCIs) have different characteristics. The
following QCI-specific parameters are used to set DRX policies on a per QCI basis:
– DRX switch: DrxParaGroup.EnterDrxSwitch
 DRX timers:
– DrxParaGroup.OnDurationTimer
– DrxParaGroup.DRXInactivityTimer
– DrxParaGroup.DRXReTxTimer
– DrxParaGroup.LongDrxCycle
– DrxParaGroup.ShortDrxCycle
– DrxParaGroup.DrxShortCycleTimer
– DrxParaGroup.SupportShortDrx
Entry Conditions

 The DRX functionality is jointly controlled by the general DRX switch CellDrxPara.

DrxAlgSwitch and the QCI-specific DRX switch DrxParaGroup.EnterDrxSwitch.
 The UE enters DRX mode when all the following conditions are met:
 The CellDrxPara.DrxAlgSwitch parameter is set to ON.
 All the established bearers for the UE support DRX. That is, the DrxParaGroup.
EnterDrxSwitch parameter of each bearer is set to ON.
 One of the below conditions related to the CellDrxPara.FddEnterDrxThd parameter is met:
– The CellDrxPara.FddEnterDrxThd parameter is set to a value ranging from 0 to 999, and the
measured traffic volume is less than or equal to the value of the CellDrxPara.FddEnterDrxThd
 parameter in the period specified by the CellDrxPara.DataAmountStatTimer parameter.
– The CellDrxPara.FddEnterDrxThd parameter is set to 1000. Under this setting, the eNodeB does
not evaluate DRX entry based on the measured traffic volume; instead, the eNodeB directly instructs
the UE to enter DRX mode.
 The UE is neither in the state where it constantly performs gap-assisted measurement nor in
the transmission time interval (TTI) bundling state.
Exit Conditions

 The UE exits DRX mode in any of the following situations:

 The UE exits DRX mode when any of the following conditions is met.
– The QCI of a new service does not support DRX mode. That is, the DrxParaGroup.EnterDrxSwitch
 for this QCI is set to OFF.
– The traffic volume of the UE is high. That is, the traffic volume is higher than the threshold specified
by the CellDrxPara.FddExitDrxThd parameter in the period specified by the CellDrxPara.
DataAmountStatTimer parameter. NOTE:When the CellDrxPara.FddExitDrxThd parameter is set
to 1000, the UE does not exit DRX mode.
 The CellDrxPara.DrxAlgSwitch parameter is set to OFF, and the eNodeB instructs the UE to
exit DRX mode in the RRC connection reconfiguration procedure.
 The UE in connected mode experiences a radio link failure (RLF) when radio conditions
deteriorate.
 The eNodeB instructs the UE to exit DRX mode during a handover.
Exit Conditions

 The UE is in the TTI bundling state.

 When the UE starts a gap-assisted measurement, the eNodeB instructs the UE to exit DRX
mode if one of the following conditions is met:
– CellDrxPara.GapDrxExclusiveSwitch is turned on.
– CellDrxPara.VolteGapDrxExclusiveSwitch is turned on and the UE has a QCI 1 bearer.
 If both CellDrxPara.VolteGapDrxExclusiveSwitch and CellDrxPara.
GapDrxExclusiveSwitch are turned on, only CellDrxPara.GapDrxExclusiveSwitch is
considered.
DRX Parameters for VoLTE

 Long Cycle for VoLTE: LongDrxCycle parameter for QCI 1 be set to SF20(20 subframes).
 Short Cycle for VoLTE: VoLTE requires a suitable DRX cycle, for example, 20 ms or 40 ms.
 On Duration Timer for VoLTE: onDurationTimer parameter for QCI 1 be set to PDCCH SF10
 DRX Inactivity Timer for VoLTE: DrxInactivityTimer parameter for QCI 1 be set to PSF80
 DRX Retransmission Timer for VoLTE: DrxReTxTimer parameter for QCI 1 be set to SF8
 UE Inactive Timer for QCI1 Dynamic DRX
DRX - Performance Monitoring

 After activating this feature, use the following counters for monitoring:
– Cdrx.Enter.Num and Cdrx.Exit.Num: used to monitor how often a UE enters and exits DRX mode.
– Traffic.User.Cdrx.Avg: used to monitor the average number of UEs that enter DRX mode on the
network.
– Cdrx.Active.TtiNum and Cdrx.Sleep.TtiNum: used to indirectly monitor the power saving effect of
UEs on the network.
– Voip.Cdrx.Active.TtiNum and Voip.Cdrx.Sleep.TtiNum: used to monitor the power saving effect of
UEs performing VoIP services.
 Handover-related counters: used to monitor the handover performance of UEs in DRX mode
and the proportion of UEs in the DRX state during handovers.
Multi-Target RRC Connection Re-establishment
 A UE initiates RRC connection reestablishment in the following scenarios:
– An RLF occurs.
– A handover fails.
– An inter-RAT handover from E-UTRAN fails.
– The UE receives an integrity check failure indication from the physical layer.
– The RRC connection fails to be reconfigured.
 A UE detects an RLF when any of the following conditions is met:
– The timer specified by the UeTimerConst.T310 parameter expires.
– The random access fails and the timer specified by the UeTimerConst.T300, UeTimerConst.T301
, RrcConnStateTimer.T304ForEutran, RrcConnStateTimer.T304ForGeran, or UeTimerConst.
T311 parameter is not running.
– The maximum number of RLC retransmissions specified by the RlcPdcpParaGroup.
UeMaxRetxThreshold parameter has been reached.
Multi-Target RRC Connection Re-establishment

 Dependencies
– This feature requires the basic feature RRC Connection Re-establishment.
 This feature affects the following RAN features:
– Coverage-Triggered Inter-Frequency Handover
– Intra-LTE Handover
 Description
– The Multi-Target RRC Connection Re-establishment feature enables an eNodeB to extend its
functionality regarding UE connection re-establishment requests handling for a vaster range of cases
than the already existing basic feature RRC Connection Re-establishment.
 Benefits
– It is beneficial for a UE with a voice call set up, because it increases the chances for the UE to stay
connected and ensure it does not lose the voice connection.
– From an eNodeB perspective, the Key Performance Indicators (KPIs) related to UE/bearer
retainability are improved as the UE stays connected, so no abnormal releases occur.
– Reduced signaling between CN and RAN since the UE is not released and set up again.
– Reduced signaling between UE and RAN since the UE is not released and set up again
Feature overview
– If radio link failure or handover failure is detected, the UE attempts a connection re-establishment in
a cell located after a cell search. This cell can be any cell in any eNodeB, if it was configured by the
serving cell in its cell re-selection neighbor list shown in the system information.
– When the UE attempts connection re-establishment, it sends identification information such as Cell
Radio Network Temporary Identifier (C-RNTI) used in the cell where the failure occurred, the
Physical Cell Identity (PCI) of the cell where the failure occurred and a Message Authentication Code
(shortMAC-I).
– If the given cell/eNodeB finds the UE’s context and can successfully reinstate it, the eNodeB will
accept the re-establishment and the UE reconnects to the RAN. (See Figure 1).
– If resource shortage is detected and the eNodeB cannot handle the UE re-establishment request,
the re-establishment is rejected. See Figure 2. For more details on connection re-establishment can
be found in the 3GPP TS 36.331.

Figure 2 Failed RRC Connection Re-establishment

Figure 1 Successful RRC Connection Re-establishment

Feature Overview

 Basic functionality does not handle the situation when a UE attempts re-establishment during
an ongoing handover, or during other UE procedures.
– No cells apart from the one that is the UE’s serving cell are enabled to handle the UE’s re-
establishment request. In all the latter mentioned cases, the eNodeB will respond with an RRC
Connection Re-establishment Reject message to the UE’s RRC Connection Re-establishment
Request.
 The optional feature Multi-target RRC Connection re-establishment Introduces RRC
connection re-establishment in other cells than serving cell. Basic feature, RRC Connection
Re-establishment, supports only RRC Connection Reestablishment in serving cell.
– The additional cases where re-establishment is supported by this feature are the following:
– Re-establishment in another cell of the Serving eNodeB
– Re-establishment in another cell of another eNodeB, provided that there is an X2 connection and
that both eNodeBs are Ericsson eNodeBs
– Re-establishment during ongoing intra-eNodeB handover (according to the constraints of the
previous bullets as well as in Serving cell)
– Re-establishment during X2 inter-eNodeB handover (according to the constraints of the previous
bullets as well as in Serving cell)
– Re-establishment between different frequencies (according to the constraints of the previous bullets)
Restrictions and limitations

 Dependencies
 Since this feature is an update to the pre-existing RRC Reestablishment algorithm, it will only
become effective if:
– Basic RRC Reestablishment license is configured
– Basic RRC Reestablishment is enabled (parameter rrcConnReestActive in MO ENodeBFunction)

 While this feature aims to repair a connection that would otherwise drop, this is done on
a“best effort” basis and cannot be expected to mask true issues such as lack of coverage
 RRC Connection Reestablishment is still not supported during
– ongoing E-RAB set up/release/modify
– ongoing RRC Connection Reconfiguration
– other ongoing procedures other than handover
Call Flow Details

UE Serving eNB Target eNB 1 Target eNB 2 Target eNB 3 MME

› In unprepared cell:
If several cells with same
– UE context is fetched from serving
PCI existcell
RRCConnectionReestablishmentRequest(PCI=A, C-RNTI...)
in neighbor eNBs
Context not found!!
– In serving cell – same license controls the Lookup X2 related eNBs

sending of context that have a cell with PCI=A

Context Fetch Request

Context Fetch Request
Context Fetch Request
Context Fetch Response

Apply UE Context

Context Fetch Response Accept

RRCConnectionReestablishment

RRCConnectionReestablishmentComplete
S1: Path Switch Request

S1: Path Switch Request Acknowledge

RRCConnectionReconfiguration

RRCConnectionReconfigurationComplete

X2:Release UE Context
RRC Connection Reestablishment Procedure

 The UE sends an RRC Connection Reestablishment Request message to the eNodeB.

 The cause value contained in the message varies with the triggering cause of the RRC
connection reestablishment.
– This message contains the cause value "reconfigurationFailure" if the reestablishment is triggered
due to an RRC connection reconfiguration failure.
– This message contains the cause value "handoverFailure" if the reestablishment is triggered due to a
handover failure.
– This message contains the cause value "otherFailure" if the reestablishment is triggered due to a
radio link failure.
 In the cause value, the C-RNTI and physCellId IEs indicate the C-RNTI and physical cell ID of
the serving cell, respectively.
RRC Connection Reestablishment Procedure

 The eNodeB checks whether the context of the UE exists.

– If yes, the eNodeB proceeds to next step.
– If no, the source eNodeB sends an RLF Indication message to the target eNodeB based on the cell
information contained in the RRC Connection Reestablishment Request message. If the target
eNodeB has the UE context, the target eNodeB initiates the handover process. In the handover, the
target eNodeB transfers the UE context to the source eNodeB. The GlobalProcSwitch.
RrcReestOptSwitch parameter specifies whether the source eNodeB can implement RRC
connection reestablishment without UE contexts.
 The eNodeB authenticates the UE. If the security authentication information in the UE is
consistent with that in the eNodeB, the UE passes authentication. After the authentication, the
eNodeB releases original resources and then performs admission and resource allocation
again.
– When the GlobalProcSwitch.EnhancedRRCReestProtectThd parameter is set to 0 and the
number of RRC Connection Reestablishment Request messages containing the cause value
"reconfigurationFailure" sent by a UE within 1 minute exceeds the threshold specified by
the GlobalProcSwitch.RrcReestProtectThd parameter, the eNodeB rejects the subsequent RRC
connection reestablishment requests containing the same cause value sent by the UE and the UE
enters the RRC idle mode.
RRC Connection Reestablishment Procedure

 The GlobalProcSwitch.RrcReestProtectThd parameter is invalid when

the GlobalProcSwitch.EnhancedRRCReestProtectThd parameter is set to a non-zero
value. In this situation, RRC connection reestablishment protection is enabled. If the number
of RRC connection reestablishment requests sent by a UE to an eNodeB exceeds the
threshold specified by theGlobalProcSwitch.EnhancedRRCReestProtectThd parameter,
the eNodeB releases the UE and the UE enters the RRC idle mode.
 If the UE fails the authentication, the eNodeB rejects the RRC connection reestablishment
request of the UE.
 The eNodeB sends the UE an RRC Connection Reestablishment message containing the
information about the allocated resources. The UE reconfigures radio resources based on the
message, and then starts encryption and integrity protection again.
 The UE sends an RRC Connection Reestablishment Complete message to the eNodeB.
RLF Detection

 The eNodeB determines whether a UE experiences an RLF based on the following principles:
– If the TimeAlignmentTimer.TimeAlignmentTimer parameter is set to a value other
than INFINITY(Infinity), the eNodeB checks whether an RLF occurs based on the status of the time
alignment (TA) timer.
 If the timer does not expire then the radio link of the UE is functional.
 If the timer expires
– The eNodeB instructs the UE to initiate random access when the eNodeB needs to transmit data to
the UE.
– The UE initiates random access when the UE needs to transmit data to the eNodeB.
• If the synchronization is successful, the radio link of the UE recovers.
• If the synchronization fails, an RLF has occurred. In this case, the eNodeB releases the RRC connection for the
UE.
• If the GLOBALPROCSWITCH.UeLinkAbnormalDetectSwitch parameter is set to ON(On), the RLF detection
function is enabled. With this function, the eNodeB checks for an RLF based on the channel quality indicator
(CQI) reported by the UE. If the number of CQIs not received by the eNodeB within a specified period exceeds a
specified threshold, an RLF occurs. If the radio link is abnormal, the eNodeB releases the RRC connection for
the UE.
– When the eNodeB releases the RRC connection for a UE due to an RLF, it sends the EPC a UE
CONTEXT RELEASE REQUEST message containing cause value "Radio Connection With UE
Accessibility & Retainability – Parameter Summary

 EnhancedRRCReestProtectThd  DeprioritisationDeliverInd
– Indicates the protection threshold of the number of – The RRC connection reject-triggered cell
RRC connection reestablishments initiated by the reselection function is recommended in heavy-
same UE in an eNodeB above which the eNodeB traffic scenarios.
releases the UE.  T325
 RrcReestOptSwitch  UlSynTimerForQci
– PCI_CONFUSION_REEST_SWITCH,
 UeInactiveTimerPri(0~255;0)
S1_HANDOVER_REEST_SWITCH,
– Indicates the priority for the QCI-specific UE
NO_CONTEXT_REEST_SWITCH,
Inactivity Timer. Larger value is high
SEC_CMD_REEST_SWITCH,
WITH_X2_NO_NCELL_REEST_SWITCH  T300/301/302/304/310/311
 RrcConnPunishThd(0~100;0)  UuMessageWaitingTimer
– Certain UEs may repeatedly fail to access networks – timer governing the period the eNodeB waits for a
because of compatibility issues. If the number of response message from a UE when the UE is
RRC connection setup requests that the eNodeB running non-QCI1 services.
receives from a UE within the time specified by  UuMessageWaitingTimerQci1
T300+FilterReptRrcConnReqTimer exceeds the
 UeMaxRetxThreshold
threshold (a non-zero value), the eNodeB imposes
a penalty on the UE, rejecting RRC connection  TimeAlignmentTimer
setup requests from the UE.  UeInactiveTimerQci1
Connection Management – Performance Monitoring

 RRC Connection Setup Success Rate (Service)

– Calculation formula: {100} x ([L.RRC.ConnReq.Succ.Emc] + [L.RRC.ConnReq.Succ.HighPri] + [
L.RRC.ConnReq.Succ.Mt] + [L.RRC.ConnReq.Succ.MoData])/([L.RRC.ConnReq.Att.Emc] + [
L.RRC.ConnReq.Att.HighPri] + [L.RRC.ConnReq.Att.Mt] + [L.RRC.ConnReq.Att.MoData])
 RRC Connection Setup Success Rate (Signaling)
– Calculation formula: {100} x (L.RRC.ConnReq.Succ.MoSig)/(L.RRC.ConnReq.Att.MoSig)
 E-RAB Setup Success Rate (VoIP)
– Calculation formula: {100} x (L.E-RAB.SuccEst.QCI.1)/(L.E-RAB.AttEst.QCI.1)
 E-RAB Setup Success Rate (All Services)
– Calculation formula: {100} x (L.E-RAB.SuccEst)/(L.E-RAB.AttEst)
 Call Drop Rate (VoIP)
– Calculation formula: {100} x (L.E-RAB.AbnormRel.QCI.1)/(L.E-RAB.AbnormRel.QCI.1 + 
L.E-RAB.NormRel.QCI.1)
 Call Drop Rate (All Services)
– Calculation formula: {100} x (L.E-RAB.AbnormRel)/(L.E-RAB.AbnormRel + L.E-RAB.NormRel)
RRC setup failure (RRC.SetupFail.Cell)
Huawei Specific Counters - RRC Connection Reestablishment

 An RRC connection reestablishment is a UE-initiated process of recovering RRC connection

 The RRC Connection Reestablishment Reject message is an RRC signaling message sent
from the eNodeB to the UE.
 To inform the UE that the reestablishment is rejected by the eNodeB.

Counter ID Counter Name Description Original Release

1526727089 L.RRC.ReEst.ReconfFail.Rej Number of RRC connection reestablishment Earlier than V100R003C00
failures due to reconfiguration failures
1526727092 L.RRC.ReEst.HoFail.Rej Number of RRC connection reestablishment Earlier than V100R003C00
failures due to failed handovers
1526727093 L.RRC.ReEstFail.ResFail Number of RRC connection reestablishment V100R003C00
failures due to failed resource allocations
1526727094 L.RRC.ReEstFail.NoReply Number of RRC connection reestablishment V100R003C00
failures due to no responses from the UE
1526728270 L.RRC.ReEstFail.Rej Total number of RRC connection reestablishment V100R003C00
rejections
1526728271 L.RRC.ReEstFail.NoCntx Number of RRC connection reestablishment V100R003C00
failures due to unavailability of UE contexts
Observation – Radio Bearer Management

 On the U2000 client, start Uu and S1 interface tracing.

 Power on a UE and use it to access the network.
 View the Uu interface tracing result. If the result contains the RRC_CONN_REQ and
RRC_CONN_SETUP_CMP messages, as shown in Figure, signaling connection
management has been activated.

 View the S1 interface tracing result. If the result contains the S1AP_INITIAL_UE_MSG and
S1AP_INITIAL_CONTEXT_SETUP_RSP messages as shown in Figure, radio bearer
management has been activated.
Troubleshooting – Accessibility and Retainability

 Fault Description
– The E-RAB setup success rate deteriorates significantly.
 Fault Handling
– On the U2000 client, start S1 interface tracing and obtain the tracing result.

– View the tracing result to check whether there are a large number of
S1AP_INITIAL_CONTEXT_SETUP_FAIL messages. If yes, proceed to the next step. If not make a
h/w check or contact support
Troubleshooting – Accessibility and Retainability

 Fault Description
– The E-RAB setup success rate deteriorates significantly.
 Fault Handling
– Double-click an S1AP_INITIAL_CONTEXT_SETUP_FAIL message to view details, and check.

 Alarms
– ALM-29215: Cell RRC Connection Success Rate Too Low
– ALM-29216: Cell ERAB Setup Success Rate Too Low
– ALM-29217: Cell Call Drop Rate Too High
LOFD-081219 Inter-eNodeB VoLTE CoMP
Voice Uplink coordinated multipoint reception (UL CoMP)

 UL CoMP is similar to multiple-antenna reception.

– The difference is that the former uses multiple cells' antennas for reception while the latter uses a
single cell's antennas for reception.
 The following provides related definitions from cell and user equipment (UE) aspects.
– Macro cells involved in UL CoMP refer to cells with high transmit power and large coverage radius,
for example, cells served by macro or LampSite eNodeBs.
– Micro cells involved in UL CoMP refer to cells with low transmit power and small coverage radius, for
example, cells served by micro eNodeBs or cells served by macro or LampSite eNodeBs with low
transmit power.
 The eNodeB determines whether to enter or exit UL CoMP based on measurement reports
from UEs.
– When the eNodeB enters UL CoMP, it selects UL CoMP UEs and cooperating cells.
– When a UE does not have any cooperating cell, the eNodeB does not perform UL CoMP for this UE.
 UL CoMP performs joint reception in multiple cells based on multiple-cell interference
rejection combining (IRC), which is similar to single-cell IRC.
Voice Uplink coordinated multipoint reception (UL CoMP)

 UL CoMP Cell
 The serving and cooperating cells of a UE are collectively known as UL CoMP cells. The
cooperating cells collaborate with the serving cell for UL CoMP.
 The serving and cooperating cells can be macro, micro, or single frequency network (SFN)
cells. Accordingly, UL CoMP can be of the following types:
– Macro-macro UL CoMP: performed between macro cells
– Micro-micro UL CoMP: performed between micro cells
– Macro-micro UL CoMP: performed between macro and micro cells
– SFN UL CoMP: performed between SFN cells or between non-SFN and SFN cells
 UL CoMP UE
 A UL CoMP UE is a UE whose signals are jointly received by the antennas of multiple cells.
There are two types of UL CoMP UE:
– Type-1 UE: located in the overlapping area between the serving and cooperating cells. UL CoMP for
this type of UE is called type-1 UL CoMP.
– Type-2 UE: located in a cooperating cell of a type-1 UE and allocated physical resource blocks
(PRBs) that overlap the type-1 UE's PRBs. UL CoMP for this type of UE is called type-2 UL CoMP.
Inter-eNodeB VoLTE CoMP

 UEs performing VoLTE can be selected as a type-1 UE but cannot be selected as a type-2
UE.
 To enlarge the coverage area of VoLTE, UL CoMP is performed only for UEs to which QPSK
is applied.
 The differences are as follows:
– The A3 offset for this feature is specified by the UlCompA3OffsetForRelaxedBH parameter.
– If 3-cell UL CoMP is enabled, only one inter-BBU cooperating cell with its BBU connected to an IP
RAN can be selected for VoLTE CoMP.
– When the eNodeB detects that an eX2 interface is congested, it performs back-pressure on VoLTE
CoMP over this interface and removes the cooperating cell.
– When the eNodeB detects that the eX2 interface is no longer congested, it cancels back-pressure on
VoLTE CoMP over this interface and restores the cooperating cell.
– When the eNodeB detects that the eX2 interface is overloaded, it removes this interface and the
cooperating cell.
 When the eNodeB selects cooperating cells, it checks transmission load status and performs
transmission load control and congestion control.
VoLTE CoMP – Performance Management

 Counters for QCI 1 packet loss rates

 Parameter
LOFD-121202 VoLTE User Prior Access
Principles

 The mo-VoiceCall-v1280 information element (IE) has been added to the RRC Connection
Request message, indicating a cause of RRC connection setup, in 3GPP Release 12.

 The eNodeB identifies calling voice-service UEs based on this IE and performs differentiated
handling. Especially in heavy-load scenarios, the eNodeB identifies calling UEs during RRC
connection setup and takes measures to ensure voice quality, improving user experience.

 On a heavily loaded network, the eNodeB takes the following measures to allow preferential
access of voice service UEs over data service UEs and increase the success rate of voice
service setup:Optimizing admission control, congestion control, and flow control

 Raising the preemption priority of voice service UEs

Principles

 VoLTE user prior access for mobile-originated calls is controlled by the VoLTEMoPrefSwitch
option of the CellAlgoSwitch.VoLTESwitch parameter.

 As shown in Figure 7-8, the eNodeB sends a SIB2 carrying the voice service cause
indication. After receiving an RRC Connection Request message from a UE, the eNodeB
identifies the UE as a VoLTE calling UE based on the cause value in this message.
Principles

 After identifying a VoLTE calling UE, the eNodeB optimizes the following measures to
increase the call setup success rate and improve VoLTE UE performance:
– DRXDRX does not take effect on the default bearer of each identified voice service UE. This
eliminates the impact of sleep time on the SIP messages carried on the QCI 5 bearer and increases
scheduling probability for the SIP messages. DRX does not take effect until the QCI 1 bearer is set
up.
– Admission and congestion controlThe eNodeB increases the ARP of each identified VoLTE UE. This
allows the VoLTE UE to preempt the resources of low-ARP UEs when the number of UEs reaches
the maximum.
– Carrier aggregation (CA)The eNodeB reduces the probability of performing CA on each identified
VoLTE UE.
– Flow controlThe eNodeB increases the priorities of identified VoLTE UEs in flow control over RRC
Connection Request messages, reducing the number of VoLTE UEs under flow control.
 DRX, CA, and flow control are optimized by default. Optimization on admission and
congestion control is controlled by the CellRacThd.VolteArpOverride parameter.
Network Impacts

 When the number of UEs reaches the maximum, the identified VoLTE UEs can preempt the
resources of low-ARP UEs, increasing the call setup success rate and the service drop rate of
these low-ARP UEs.

 The identified voice service UEs do not use DRX on the default bearers. This prevents the
scheduling delay of SIP messages over the Uu interface due to the DRX-defined sleep time. If
the QCI 1 bearer is set up after the called UE answers the call, DRX parameter configuration
is delayed. In this case, the calling UE consumes more power when it has not entered the
DRX state yet.

 This function results in a larger value of the L.Traffic.BCH.TB.bits counter, which indicates a

larger number of bits of transport blocks transmitted on the broadcast channel (BCH).
Parameters used for activation

Parameter Parameter ID Option Setting Notes

Name
VoLTE Switch CellAlgoSwitch. VoLTEMoPrefSwitch The VoLTEMoPrefSwitch option specifies
VoLTESwitch whether to perform preferential processing for UEs
that initiate VoLTE services.
•If this option is deselected, the eNodeB does not
perform preferential processing for these UEs.
•If this option is selected, the eNodeB optimizes
procedures, such as admission, scheduling, and
flow control for these UEs to increase the VoLTE
call setup success rate.
VoLTE UE ARP CellRacThd. N/A This parameter specifies the ARP of the bearer to
Override VolteArpOverride be set up by sending initial UE context setup
requests to calling UEs that include the cause
value "mo-VoiceCall-v1280" in the RRC
connection requests.
•If this parameter is set to 0, the eNodeB does not
change ARP values.
•If this parameter is not set to 0 and the ARP value
delivered by the MME is greater than the
parameter value, the eNodeB can take the value
of this parameter as the ARP value for the UEs.
RLC Segmentation Enhancement
RLC Segmentation Enhancement

 The number of Uplink RLC segments is dependent on the TBS determined by UL scheduling.
The smaller the TBS, the large the number of uplink RLC segments. When channel quality is
poor and UL power is limited, a small TBS results in a large number of uplink RLC segments,
which causes:Long delay of voice packets
– Uplink voice packet loss (because voice packets wait in the UE buffer so long that the packet discard
timer expires)
– Large overhead of RLC and MAC headers
– Large consumption of control channel elements (CCEs) and resource blocks (RBs) by UL dynamic
scheduling of VoLTE services
 Uplink RLC segmentation enhancement restricts the TBS in UL dynamic scheduling to control
the number of uplink RLC segments for voice packets. This restriction improves voice quality
when channel quality is poor.
RLC Segmentation Enhancement

 The CellUlschAlgo.UlVoipRlcMaxSegNum parameter is introduced to control the maximum

number of uplink RLC segments for UEs not in the TTI bundling state.
– When the number of uplink RLC segments is less than or equal to the value of the CellUlschAlgo.
UlVoipRlcMaxSegNum parameter, the number is not restricted.
– When the number of uplink RLC segments is greater than the value of the CellUlschAlgo.
UlVoipRlcMaxSegNum parameter, the number is restricted. Based on the voice packet size and the
configured maximum number of RLC segments, a minimum TBS is guaranteed in UL dynamic
scheduling so that the number of uplink RLC segments decreases to this maximum number.
 This function takes effect when all the following conditions are met:
– The CellUlschAlgo.UlVoipRlcMaxSegNum parameter is set to a none-zero value.
– The GLOBALPROCSWITCH.LcgProfile parameter is set
to LCG_PROFILE_0 or LCG_PROFILE_2.
 This function does not take effect when one of the following conditions is met:
– The CellUlschAlgo.UlVoipRlcMaxSegNum parameter is set to 0.
– The GLOBALPROCSWITCH.LcgProfile parameter is set to LCG_PROFILE_1.
– The UE enters the TTI bundling state.
DL Power Boosting
Reference signal power de-boosting

Bad DL channel
Poor RSRQ = estimation
mobility issues =
Poor DL throughput
Reference signal power de-boosting

 There are two types of OFDM symbols

Symbol A does not carry the cell-specific Reference Signal
– Symbol B carries the cell-specific Reference Signal
 The ratio of PDSCH EPRE to RS EPRE is defined by ρA and ρB for each OFDM symbol
 P_PDSCH_B = P_PDSCH_A * ρB / ρA

– ρA refers to type A symbols (w/o RS)

Type B symbols
– ρB refers to type B symbols (with RS)

Subframe

Resource block = 12 subcarriers

ρB/ρA
PB One Antenna Port
Two and Four Antenna Ports
0 1 5/4
1 4/5 1
2 3/5 3/4
3 2/5 1/2 RS used by the antenna port 0

Type A symbol
Reference signal power de-boosting Configuration Management

 An eNodeB transmits CRS in all downlink subframes. CRS serves as a basis for downlink
channel estimation, which is used for data demodulation.
 The CRS power is indicated by the energy per resource element (EPRE) and is specified by
the PDSCHCfg.ReferenceSignalPwr parameter.
 The transmit RS power of an RRU is specified by the PDSCHCfg.ReferenceSignalPwr
 parameter. Generally, the PDSCHCfg.ReferenceSignalPwr parameter value is delivered in
SIB2. However, in the scenario where the repeater amplifies the transmit power of a small-
power RRU, the pass loss calculated based on the parameter value is incorrect if
the PDSCHCfg.ReferenceSignalPwr parameter value is delivered in SIB2. To prevent
miscalculations, the RS power delivered in SIB2 is now controlled by the CellAlgoSwitch.
RepeaterSwitch parameter.If the AntRsPwrSwitch(AntRsPwrSwitch) option of
the CellAlgoSwitch.RepeaterSwitch parameter is deselected, the PDSCHCfg.
ReferenceSignalPwr parameter value is delivered in SIB2.
Reference signal power de-boosting Configuration Management

 If the AntRsPwrSwitch(AntRsPwrSwitch) option of the CellAlgoSwitch.RepeaterSwitch
 parameter is selected, the RS power at the antenna is calculated based on
the CellChPwrCfg.AntOutputPwr and PDSCHCfg.ReferenceSignalPwr parameter values.
The formula is as follows:
– Configure the transmit power for the entire channel bandwidth at the antenna connector (specified by
the CellChPwrCfg.AntOutputPwr parameter).
– The maximum transmit power of the RRU is calculated based on the CRS power, P A, and PB and is
recorded as RruOutputPwr in the unit of dBm. The power gain of the transmit power at the antenna
connector to the transmit power of the RRU is calculated using the formula: Δ(dB) = 10log10
(CellChPwrCfg.AntOutputPwr parameter value x 1000) – RruOutputPwr. In the formula, the
original CellChPwrCfg.AntOutputPwr parameter value is in the unit of W and is converted to a
value in the unit of mW.
– The RS power at the antenna is calculated using the following formula: AntReferenceSignalPwr
(dBm) = PDSCHCfg.ReferenceSignalPwr parameter value + Δ (dB). Then, the calculated RS power
at the antenna is delivered in SIB2.
Reference signal power de-boosting - Example
dlChBw=10MHz (50 PRBs), dlMimoMode= Adaptive Open Loop MIMO,

 The even energy per Resource Element for 1 antenna system (1 TX Mode) is
• EPRE_0 = (pmax ) - 10 log (#PRB*12)
• EPRE_0 = (39dBm) – 10*log10 (50*12) = 11.21dBm

 The power of the Cell-specific Reference Symbols.

• P_CRS = EPRE_0 + dlRSboost
• P_CRS = 11.21dBm -3dB = 8.21dBm

 The power of PDSCH on OFDMsymbols without CRS.

 For 2 antenna system (MIMO TX diversity or Spatial Multiplexing) the parameter MIMO
compensation has to be subtracted from the even energy per Resource Element.
 P_PDSCH_A = EPRE_0
• P_PDSCH_A = 11.21dBm - 0dB = 11.21dBm
– p-a is the ratio between P_PDSCH_A to P_CRS
– p-a = 11.21dBm - 8.21dBm = 3dB
 The power of PDSCH on OFDMsymbols with CRS.
 With dlRsBoost index p-b is 0. From table we find ρB /ρA = 5/4.
• P_PDSCH_B = PSD_UE_PDSCH_A + 10* log10 (ρB /ρA)
• P_PDSCH_B = 11.21 + 10 * log10 (5/4) = 12.18dBm
 Reference signal power de-boosting
Example configurations

  Input Parameters Signaling   result: Power PDSCH RE

Max_TX_Pwr MAX TX BW Cell PWR MIMO RS RS ρB /ρA P_PDSCH P_PDSCH
  Pwr RED COMP BOOST Power (0,4) (1,2,3,5,6,)
  W dBm PRB dB dB dB dBM   dBm dBm

1 8 39.0 50 0 0 -3 8.2 1.25 12.2 11.2

2 8 39.0 50 0 0 0 11.2 1.00 11.2 11.2
3 8 39.0 50 0 3 -3 8.2 1.00 8.2 8.2
4 8 39.0 100 0 3 -3 5.2 1.00 5.2 5.2
5 60 47.8 100 0 0 0 17.0 1.00 17.0 17.0
6 60 47.8 100 0 0 3 20.0 1.00 17.0 17.0
7 60 47.8 100 0 3 0 17.0 1.00 14.0 14.0
8 60 47.8 100 0 3 3 20.0 1.00 14.0 14.0
9 60 47.8 100 0 0 6 23.0 1.00 17.0 17.0
10 60 47.8 100 0 0 -3 14.0 1.00 17.0 17.0
Dynamic/Semi Persistent Scheduling for VoLTE
Dynamic/Semi Persistent Scheduling for VoLTE

 Voice services have demanding requirements on delay.

 The scheduler have to optimizes handling of voice service priorities to ensure voice service
QoS.
 Uplink Dynamic Scheduling
– Priority of conversational voice (QCI of 1) is lower than the priorities of data retransmitted using
HARQ, signaling radio bearer 1 (SRB1), SRB2, and IMS signaling (QCI of 5), but higher than the
priorities of other initially transmitted data
– Uplink voice preallocation is introduced to reduce the delay of voice services. When the number of
UEs in a cell exceeds 50, the eNodeB can preallocate available uplink resources to only UEs
performing voice services.
– When the number of UEs in a cell is less than or equal to 50, the eNodeB retains the existing uplink
preallocation or uplink smart preallocation mechanism for all UEs.
 Downlink Dynamic Scheduling
– When dynamic scheduling is used, the scheduling priority is related to whether the DL Non-GBR
Packet Bundling feature is enabled
– When dynamic scheduling is used, the MCS selection policy is related to the value of
the VoipTbsBasedMcsSelSwitch parameter.
Capacity Enhancement

 Semi-persistent scheduling and power control

– When the capacity is low due to high PDCCH overheads, these features can be used to reduce
PDCCH overheads and therefore increase the maximum number of VoLTE users or the throughput
of data services (provided that the number of VoLTE users remains unchanged).
 Uplink delay-based dynamic scheduling
– When there are too many VoLTE users, this feature can be used to improve the performance of cell
edge users (CEUs) by sacrificing the performance of cell center users (CCUs) and increase the
proportion of satisfied VoLTE users.
 ROHC
– By compressing the headers of voice packets, this feature reduces air interface overheads and
increases the maximum number of VoLTE users or the throughput of data services (provided that the
number of VoLTE users remains unchanged).
Data Preparation (FDD)
Data Preparation (FDD)
VoLTE Rate Control
VoLTE Rate Control

 VoLTE Rate Control adjusts the AMR-NB/AMR-WB rate for uplink voice services depending
on the uplink channel quality and voice quality.
– When the uplink channel quality and voice quality are favorable, a high voice coding rate is used to
further improve voice quality.
– When the uplink channel quality and voice quality are poor, a low voice coding rate is used to reduce
the uplink packet loss rate and improve uplink voice coverage.
– In scenarios where downlink coverage is limited prior to uplink coverage (for example, in the
coverage area of a micro base station), UEs' uplink channel quality and voice quality may not meet
the conditions for using low voice coding rates. In such scenarios, it is difficult to trigger the decrease
of voice coding rates.
 The eNodeB determines whether to adjust the voice rate depending on the uplink channel
quality and voice quality. If yes, the eNodeB or SBC adjusts the voice rate of the UE. Voice
rate adjustment is controlled by the CellAlgoSwitch.UlAmrcMode parameter as the next
slide:
Voice rate adjusted by the eNodeB

 If this parameter is set to ULAMRC_ENB_CONTROL(ULAMRC_ENB_CONTROL), the

eNodeB adjusts the voice rate of the UE.
 If this parameter is set to ULAMRC_SBC_CONTROL(ULAMRC_SBC_CONTROL), the
eNodeB requests the SBC, through RTCP, to adjust the voice rate of the UE. If IMS signaling
is encrypted, the eNodeB cannot obtain the rate set supported by the UE. In this situation,
SBC can be used to perform voice rate control
Supported AMR services

 VoLTE Rate Control feature supports the following rates for AMR-NB services: 12.2 kbit/s, 7.4
kbit/s, and 4.75 kbit/s; the VoLTE Rate Control feature supports the following rates for AMR-
WB services: 23.85 kbit/s, 12.65 kbit/s, and 6.6 kbit/s. Both rates in each AMR group can be
allocated to a UE.
 AMR groups are controlled by the following parameters:
– VoiceAmrControl.VoiceAmrCtrlParaGroupId
– VoiceAmrControl. HighAmrCodingMode
– VoiceAmrControl. LowAmrCodingMode
– VoiceAmrControl.RsnThdForDecreasingAmr
– VoiceAmrControl.RsnThdForIncreasingAmr
AMR coding rate increase/decrease

 The AMR coding rate increases if the following conditions are both met:
– The TBS of the UE is greater than TbsUpTh.
– The uplink packet loss rate for services with a QCI of 1 is less than VoiceAmrControl.
PlrThdForIncreasingAmr for two consecutive times.
 If the UlAmrcExceedingInitialSw(UlAmrcExceedingInitialSw) option of
the CellAlgoSwitch.AmrcAlgoSwitch parameter is selected, the increased coding rate can
exceed the initial coding rate of this call. Otherwise, the increased coding rate cannot exceed
the initial coding rate of this call.
 The AMR coding rate will be decreased if the following conditions are both met:
– The TBS of the UE is less than TbsDownTh.
– The uplink packet loss rate for services with a QCI of 1 is greater than VoiceAmrControl.
PlrThdForDecreasingAmr for two consecutive times.
 The VoLTE Rate Control feature does not take effect in the following scenarios:
– The voice coding format is not AMR-NB or AMR-WB.
– RTP packets are encrypted. The number of rates in the intersection of the rate set supported by UEs
and the rate range configured is less than or equal to 1.
Uplink Voice Mute Recovery

 The uplink voice mute recovery function enables the eNodeB to detect UEs with uplink voice
mute. For such a UE, the eNodeB performs an intra-cell handover or releases the RRC
connection to attempt to recover the voice communication.
 The uplink voice mute recovery function is controlled by
the UlCallMuteRecoverSwitch(UlCallMuteRecoverSwitch) option of the CellUlschAlgo.
UlEnhencedVoipSchSw parameter. For an uplink voice mute UE, the processing is as
follows:
 If the voice mute is caused by PDCP or RLC abnormality, the eNodeB performs an intra-cell
handover on the UE to reconfigure the radio bearer.
 If the voice mute is caused by other reasons, the eNodeB releases the RRC connection for
the UE.
– If there is an another E-UTRA frequency, an inter-frequency blind redirection is performed, and the
RRC connection release message contains the E-UTRA frequency. NOTE:The voice service
redirection function is controlled by the CellAlgoSwitch.VolteRedirectSwitch parameter.
– If there is not another E-UTRA frequency, the eNodeB releases the RRC connection for the UE. The
RRC connection release message does not contain any other E-UTRA frequencies.
Target Rate Guarantee Based on User Types

 The eNodeB identifies different UE types by the QCI or SPID.

 By QCIOperators can specify different QCIs for default non-GBR bearers of different UE types
on the EPC. The eNodeB sets the QciPara.QciSpecificBestEffortGbrparameter to specify a
best-effort GBR corresponding to bearers with a specific QCI.
 By SPIDOperators can specify different SPIDs for different UE types on the EPC. The
eNodeB sets the SpidCfg.SpidSpecificBestEffortGbr parameter to specify a best-effort
GBR corresponding to the default non-GBR bearers of UEs with a specific SPID.
 Benefits
 The eNodeB preferentially schedules UEs with specified target rates to guarantee their target
rates. The Service Downlink Average Throughput of these UEs is increased.
Massive MIMO
Features
Feature ID Feature/Function Name Section
LEOFD-131301 Massive MIMO Introduction Basic Massive MIMO Functio
ns
LEOFD-13130101 Flexible Active-Unit
Management
LEOFD-13130102 Adaptive Transmission Mode

LEOFD-13130104 Power Beamforming

LEOFD-13130105 Antenna Fault Detection
LEOFD-131302 32T32R Massive MIMO See the corresponding
Package sections of the subfeatures.

LEOFD-13130201 UL 32-Antenna Receive DDB

Diversity

LEOFD-13130202 DL 32-Antenna Spatial DDB

Multiplexing

LEOFD-13130203 Massive MIMO Static Shared SSB

Beam on 32T32R

LEOFD-131303 DL 8-Layer MU-MIMO DDB

LEOFD-131304 DL 16-Layer MU-MIMO DDB
Introduction

 Massive MIMO is widely regarded as a key update of multiple-antenna technology in the 4.5G
era. It uses a large number of antenna arrays to perform 3D beamforming and multi-layer
multi-user multiplexing, significantly improving system capacity and 3D coverage.
 The following figure shows hardware evolution from traditional MIMO sites to massive MIMO
sites.
 Figure 3-1 Hardware evolution from traditional MIMO sites to massive MIMO sites
Function evolution from traditional MIMO to massive MIMO
Category Traditional MIMO Massive MIMO
Beamwidth can be adjusted on both the horizontal
Beamwidth can be adjusted only on the horizontal
Broadcast Beamforming and vertical planes, improving vertical-plane
plane.
network coverage.
Uplink multiple-antenna receive diversity (receive A maximum of eight antennas can be used for Up to 64 antennas can be used for uplink receive
diversity for short) uplink receive diversity. diversity.
Up to 4 layers can share the same time- Up to eight layers can share the same time-
Uplink multi-user MIMO (MU-MIMO for short)
frequency resource. frequency resource.
Traffic beamwidth can be adjusted on both the
Traffic beamwidth can be adjusted only on the
Downlink single-user (SU) beamforming horizontal and vertical planes, enhancing the
horizontal plane.
beamforming accuracy.
Downlink multi-user beamforming (MU Up to 4 layers can share the same time- A maximum of 16 layers (24 layers are available
beamforming for short) frequency resource. only for trial)
PDSCH beams are split, enabling independent-
scheduling UEs served by different PDCCH
Multi-user split SDMA in Massive MIMO (multi-
None beams to reuse the same PDCCH resource for
user split SDMA for short)
data transmission. This function further improves
the MU beamforming capacity.
Horizontal-plane weighting: The beam is divided
into multiple orthogonal beams in the horizontal
plane, and each beam is configured with
independent measurable CSI-RSs. The UE
Wide beam weighting, which performs
Massive MIMO TM9 hybrid precoding (TM9 selects the weighting value with the best
beamforming based on the PMI feedback of the
hybrid precoding for short) beamforming capability according to the
UE
channel state.
Vertical-plane weighting: The eNodeB performs
beamforming based on UEs' PMI feedback.
PDCCH beams are split, enabling independent-
PDCCH SDMA in massive MIMO (PDCCH scheduling UEs served by different PDCCH
None
SDMA for short) beams to reuse the same PDCCH resource for
data transmission.
Application Scenarios

 The main benefit of massive MIMO lies in improved cell coverage and capacity. A massive
MIMO site can be deployed on new sites or by reconstructing existing sites. Massive MIMO is
typically deployed in hotspot areas and for covering tall buildings.
 Hotspot coverage
– Massive MIMO can effectively improve system capacity through spatial multiplexing. Up to 8 layers
in the uplink for MU-MIMO pairing and up to 16 layers in the downlink for MU beamforming pairing
significantly improve the cell throughput and meet capacity demands in hotspot areas.
 Tall-building coverage
– In tall buildings, users are distributed across many floors, and a normal site cannot extend coverage
vertically very far. The vertical beamwidth (approximately 6.5°) makes it impossible for a traditional
site to cover multiple floors.
Broadcast Beamforming

 Basic massive MIMO functions include broadcast beamforming and TDLEOFD-121601

Massive MIMO Introduction. TDLEOFD-121601 Massive MIMO Introduction satisfies the
prerequisites for activating a massive MIMO cell.
 Broadcast beamforming enables the eNodeB to apply weighting on broadcast beams to
adjust the coverage scope of such beams.
 The weighting designed for typical coverage scenarios has been written into the antenna
weight file, which is included in the eNodeB software package. After the antenna weight file is
activated, the eNodeB configures broadcast beamwidth on both the horizontal and vertical
planes based on the setting of the BfAnt.CoverageScenario parameter, satisfying broadcast
coverage demands in various application scenarios. The vertical beamwidth of up to 35°
significantly improves the vertical coverage scope in tall-building scenarios. Table 4-1 lists
massive MIMO cell coverage solutions.
Other Features

 TDLEOFD-12160105 Antenna Fault Detection

– This feature enables the eNodeB to periodically check for antenna faults. The eNodeB reports ALM-
29243 Cell Capability Degraded upon detecting an antenna fault.
– In this situation, the value of the alarm parameter Specific Problem is Antenna channel
exceptions. The number of normal antennas can be determined based on the values of the TX
Channel Numbers In The Cell and TX Channel Numbers In The Cell parameters.
– This feature is free from parameter control. It is enabled by default for massive MIMO cells.

 TDLEOFD-12160101 Flexible Active-Unit Management

– To enhance system reliability, the following flexible active-unit management policy is supported in
massive MIMO scenarios:
– The cell works properly if 32 or more antennas are operational. In this situation, network
performance, such as the cell throughput, may deteriorate. The impact increases with the growth in
the number of faulty antennas.
– The massive MIMO cell is deactivated if fewer than 32 antennas are operational.
– This feature is free from parameter control. It is enabled by default for massive MIMO cells.
Other Features

 TDLEOFD-12160102 Adaptive Transmission Mode

– This feature enables UEs to work in a transmission mode that delivers the highest spectral efficiency
for any given set of channel conditions. This feature provides significantly better average cell
throughput than fixed transmission modes.
– The CellBfMimoParaCfg.BfMimoAdaptiveSwitch parameter controls the policy of adaptive
switching between transmission modes.
– For details about adaptive switching between transmission modes, see 
Optimized Adaptive Switching Between Transmission Modes.
 TDLEOFD-12160103 Dynamic SRS Allocation
– UE services are classified as either heartbeat, heavy-traffic, or normal services. Online UEs always
occupy sounding reference signal (SRS) resources, regardless of whether services are running or
not. Beamforming requires short-period SRS resources. If the UEs running only heartbeat services
consume short-period SRS resources, the beamforming performance for heavy-traffic UEs is
affected.
Other Features

 TDLEOFD-12160103 Dynamic SRS Allocation

– UE services are classified as either heartbeat, heavy-traffic, or normal services. Online UEs always
occupy sounding reference signal (SRS) resources, regardless of whether services are running or
not. Beamforming requires short-period SRS resources. If the UEs running only heartbeat services
consume short-period SRS resources, the beamforming performance for heavy-traffic UEs is
affected.
– When service-based dynamic SRS allocation is enabled, massive MIMO cells allocate long-period
SRS resources to UEs performing heartbeat services in order to save short-period SRS resources
and allocate more short-period SRS resources to the UEs performing heavy-traffic services while
retaining the SRS policy for UEs performing normal services. In this way, SRS resource allocation is
optimized, improving beamforming performance.
– This function is controlled by the SrvBasedSRSAdjAlgo option under the SRSCfg.
SrsCfgPolicySwitch parameter. When this option is selected, the massive MIMO cell identifies UE
service types and then reserves SRS resources for the UEs that are performing heavy-traffic
services within a fixed period. The reserved SRS resources are not available for the UEs that initially
access the network or perform heartbeat services.
Other Features

 TDLEOFD-12160104 Power Beamforming

– Power beamforming enables the eNodeB to adjust the phases and amplitudes in massive MIMO
scenarios based on how signals are weighted.

– With this function, the eNodeB calculates the weighting for each RF channel of the AAU using a
beamforming algorithm.

– It then allocates transmit power to each RF channel based on the amplitude corresponding to the
weighting, improving the channel power efficiency and the downlink user experience rate.

– This feature is free from parameter control. It is enabled by default for massive MIMO cells.
Network Analysis

 Benefits
– This feature increases power and array gains. Massive MIMO enables the eNodeB to adjust
broadcast beams and downlink traffic beams on both the horizontal and vertical planes, achieving
better uplink and downlink coverage performance than 8T8R multiple-antenna technologies. The
gain is more significant on the vertical plane.

 System capacity
– This feature improves the average cell capacity, peak cell throughput, average single-UE throughput,
and CEU throughput in both the uplink and downlink.

 Network performance
– This feature improves network coverage in both the uplink and downlink.
– Massive MIMO cells have a larger target SRS power for SRS power control than normal cells. This
increases the downlink spectral efficiency and cell throughput as well as SRS interference.
Hardware Requirements

 Base Station Models

– 3900 and 5900 series base stations
 Boards
– BBU: BBU3910 or BBU5900
– BBP: UBBPem
– Main control board: UMPTe
– A BBU3910 supports a maximum of four UBBPem boards. Each UBBPem supports a maximum of
two massive MIMO cells.
– Each BBU5900 supports a maximum of six UBBPem boards. Each UBBPem supports a maximum of
two massive MIMO cells.
 RF Modules
– The AAU5271 or AAU5281 is used.
THANK
THANK YOU
YOU