ROHC (eRAN13.1 04)

eRAN
ROHC Feature Parameter

Description
Issue 04
Date 2018-11-07
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2018. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. i

eRAN
ROHC Feature Parameter Description Contents
Contents
1 Change History.............................................................................................................................. 1
1.1 eRAN13.1 04 (2018-11-07)............................................................................................................................................1
1.2 eRAN13.1 03 (2018-08-27)............................................................................................................................................1
1.3 eRAN13.1 02 (2018-06-30)............................................................................................................................................1
1.4 eRAN13.1 01 (2018-04-10)............................................................................................................................................2
1.5 eRAN13.1 Draft A (2018-01-15) (FDD)........................................................................................................................2
1.6 eRAN13.1 Draft A (2017-12-30) (TDD)....................................................................................................................... 3
2 About This Document.................................................................................................................. 5

2.1 Applicable RAT.............................................................................................................................................................. 5
2.2 Features in This Document.............................................................................................................................................5
2.3 Differences Between FDD and TDD..............................................................................................................................5
3 Overview......................................................................................................................................... 6
4 ROHC...............................................................................................................................................7
4.1 Principles........................................................................................................................................................................ 7
4.1.1 Related Concepts......................................................................................................................................................... 7
4.1.2 Principles and Framework of ROHC...........................................................................................................................9
4.1.2.1 ROHC Entities in E-UTRAN................................................................................................................................... 9
4.1.2.2 Basic Framework.................................................................................................................................................... 10
4.1.2.2.1 Compression Mechanism.....................................................................................................................................11
4.1.2.2.2 Decompression Mechanism.................................................................................................................................12
4.1.2.2.3 Context Replication............................................................................................................................................. 12
4.1.2.3 ROHC States...........................................................................................................................................................12
4.1.2.3.1 Compressor States............................................................................................................................................... 12
4.1.2.3.2 Decompressor States............................................................................................................................................13
4.1.2.4 ROHC Operating Modes........................................................................................................................................ 14
4.1.2.4.1 Operating Mode Transition..................................................................................................................................14
4.1.2.4.2 U-Mode................................................................................................................................................................15
4.1.2.4.3 O-Mode................................................................................................................................................................15
4.1.2.4.4 R-Mode................................................................................................................................................................ 16
4.1.2.5 Factors Affecting the ROHC Compression Efficiency...........................................................................................17
4.1.3 ROHC Procedure and Parameter Negotiation........................................................................................................... 18
4.1.3.1 Procedure for Starting ROHC upon Initial Access.................................................................................................18
Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. ii

eRAN
ROHC Feature Parameter Description Contents
4.1.3.2 Procedure for ROHC During a Handover.............................................................................................................. 20

4.1.3.3 Procedure for ROHC upon RRC Connection Reestablishment............................................................................. 21
4.2 Network Analysis......................................................................................................................................................... 22
4.2.1 Benefits...................................................................................................................................................................... 22
4.2.2 Impacts.......................................................................................................................................................................23
4.3 Requirements................................................................................................................................................................ 25
4.3.1 Licenses..................................................................................................................................................................... 25
4.3.2 Software.....................................................................................................................................................................26
4.3.3 Hardware................................................................................................................................................................... 26
4.3.4 Others.........................................................................................................................................................................26
4.4 Operation and Maintenance..........................................................................................................................................26
4.4.1 Data Configuration.................................................................................................................................................... 26
4.4.1.1 Data Preparation..................................................................................................................................................... 26
4.4.1.2 Using MML Commands......................................................................................................................................... 28
4.4.1.3 Using the CME....................................................................................................................................................... 28
4.4.2 Activation Verification.............................................................................................................................................. 28
4.4.3 Network Monitoring.................................................................................................................................................. 31
5 Parameters..................................................................................................................................... 33
6 Counters........................................................................................................................................ 59
7 Glossary......................................................................................................................................... 63
8 Reference Documents................................................................................................................. 64
Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. iii

eRAN
ROHC Feature Parameter Description 1 Change History
1 Change History
This chapter describes changes not included in the "Parameters", "Counters", "Glossary", and
"Reference Documents" chapters. These changes include:
l Technical changes
Changes in functions and their corresponding parameters
l Editorial changes
Improvements or revisions to the documentation
1.1 eRAN13.1 04 (2018-11-07)

This issue includes the following changes.
Technical Changes
None
Editorial Changes
Revised descriptions in 4.4.3 Network Monitoring.
1.2 eRAN13.1 03 (2018-08-27)

Technical Changes
None
Editorial Changes
Revised descriptions in 4.2.2 Impacts.
1.3 eRAN13.1 02 (2018-06-30)

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 1

eRAN
Technical Changes
None
Editorial Changes
Revised the descriptions in the following sections:
l 4.2.2 Impacts
l 4.3.2 Software
1.4 eRAN13.1 01 (2018-04-10)

This issue introduces the following changes.
Technical Changes
None
Editorial Changes
Revised descriptions in this document.
1.5 eRAN13.1 Draft A (2018-01-15) (FDD)

This issue introduces the following changes to eRAN12.1 03 (2017-10-23).
Technical Changes
Change Description Parameter Change Base Station Model
Added the ROHC-TCP Added the Profile0x0006 l 3900 and 5900

function. For details, see the option to the series base stations
following sections: PdcpRohcPara.Profiles l DBS3900 LampSite
l 4.1.1 Related Concepts parameter. and DBS5900
l 4.1.2.2.3 Context LampSite
Replication l BTS3912E
l 4.4.1.1 Data Preparation l BTS3911E
Added the enhanced ROHC Added the l BTS3203E

feedback mechanism in O- ROHC_FEEDBACK_ENH l BTS3202E
Mode. For details, see 4.1.2.4.3 ANCEMENT_SW option to
O-Mode. the
PdcpRohcPara.RohcOptimiz
ationSwitch parameter.
Optimized the ROHC exit None

mechanism. For details, see
4.1.2.4.1 Operating Mode
Transition.

eRAN
Added the Added the

PdcpRohcPara.RohcSwitch PdcpRohcPara.RohcSwitch
parameter to the disuse list and parameter to the parameter
revised related descriptions in disuse list.
the document. For details, see
the following sections:
l 4.1.3 ROHC Procedure
and Parameter
Negotiation
l 4.1.3.3 Procedure for
ROHC upon RRC
Connection
Reestablishment
l 4.4.1 Data Configuration
Editorial Changes
Reorganized this document using a new template.
1.6 eRAN13.1 Draft A (2017-12-30) (TDD)

This issue introduces the following changes to eRAN TDD 12.1 03 (2017-10-23).
Technical Changes
Added the ROHC-TCP Added the Profile0x0006 l 3900 and 5900

function. For details, see the option to the series base stations
following sections: PdcpRohcPara.Profiles l DBS3900 LampSite
l 4.1.1 Related Concepts parameter. and DBS5900
l 4.1.2.2.3 Context LampSite
Replication l BTS3205E
l 4.4.1.1 Data Preparation
Added the enhanced ROHC Added the

feedback mechanism in O- ROHC_FEEDBACK_ENH
Mode. For details, see 4.1.2.4.3 ANCEMENT_SW option to
O-Mode. the
PdcpRohcPara.RohcOptimiz
ationSwitch parameter.
Optimized the ROHC exit None

mechanism. For details, see
4.1.2.4.1 Operating Mode
Transition.

eRAN
Added the Added the

PdcpRohcPara.RohcSwitch PdcpRohcPara.RohcSwitch
parameter to the disuse list and parameter to the parameter
revised related descriptions in disuse list.
the document. For details, see
the following sections:
l 4.1.3 ROHC Procedure
and Parameter
Negotiation
l 4.1.3.3 Procedure for
ROHC upon RRC
Connection
Reestablishment
l 4.4.1 Data Configuration
Editorial Changes
Reorganized this document using a new template.

eRAN
ROHC Feature Parameter Description 2 About This Document
2 About This Document
2.1 Applicable RAT

This document applies to FDD/TDD.
2.2 Features in This Document

This document describes the following FDD features.
Feature ID Feature Name Section
LOFD-001017 RObust Header 4 ROHC

Compression (ROHC)
This document describes the following TDD features.
Feature ID Feature Name Section
TDLOFD-001017 RObust Header 4 ROHC

Compression (ROHC)
2.3 Differences Between FDD and TDD

FDD FDD TDD TDD Difference Section
Feature Feature Feature Feature
ID Name ID Name
LOFD-001 RObust TDLOF RObust None 4 ROHC

017 Header D-00101 Header
Compressi 7 Compression
on (ROHC) (ROHC)

eRAN
ROHC Feature Parameter Description 3 Overview
3 Overview
ROHC provides a header compression mechanism for data packets. It is specially designed
for lowering the bit error rate and delay of radio links and saving radio resources.
This feature is applicable in the following scenarios:
l Voice packet header compression
This compression applies to QCI 1 voice bearers, QCIs 65 and 66 PTT bearers, or
bearers of extended QCIs for PTT services.
l Uplink Transmission Control Protocol (TCP)/IP packet header decompression
This decompression applies to services in acknowledged mode (AM) on the Radio Link
Control (RLC) layer. This decompression does not apply to QCI 1 voice bearers, QCIs
65 and 66 PTT bearers, or bearers of extended QCIs for PTT services.
The ROHC-TCP function decompresses the headers of uplink TCP/IP packets.

eRAN
ROHC Feature Parameter Description 4 ROHC
4 ROHC
4.1 Principles
ROHC reduces header overheads and packet loss and shortens the response time, improving
network performance. ROHC has the following advantages over other header compression
mechanisms, such as IP Header Compression (IPHC):
l High reliability:
Due to its feedback mechanism, ROHC is robust on the radio links with high BER and
long RTT.
l 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
compress headers into only 1 byte.
As shown in Figure 4-1, the header is compressed from 40 bytes to 1 byte. A smaller payload
increases gains from the ROHC header compression.
Figure 4-1 ROHC header compression
Despite that ROHC is more complex than other header compression schemes and requires
higher computing capabilities of a processor, it is suitable in radio systems where air interface
resources are more valuable. It is mainly used for voice over IP (VoIP) or TCP/IP services.
4.1.1 Related Concepts

Table 4-1 explains the concepts related to ROHC.

eRAN
Table 4-1 Concepts related to ROHC

Concept Explanation
Compressor It is at the transmit (TX) end, and is responsible for compressing the
packet header based on the profile and the context.
Decompressor It is at the receive (RX) end, and is responsible for restoring the packet
header based on the profile and the context.
Data radio A DRB is a radio bearer that carries data on the user plane.
bearer (DRB) l Multiple DRBs can be established between a UE and the E-UTRAN.
l Each DRB can carry one or more packet flows.
Packet flow A packet flow is a series of data packets using the same compression
algorithm and associated with a single context. For example, a voice
over Long Term Evolution (VoLTE) service is composed of two packet
flows, of which one is compliant with the Real-Time Transport Protocol
(RTP) and the other is compliant with the RTP Control Protocol (RTCP).
Context A context contains the information about compression and

decompression characteristics of a packet header. Each context is
identified by a unique context identifier (CID).
l Each context consists of static and dynamic fields.
– Static fields, such as the source and destination IP addresses,
remain unchanged within a particular packet flow. Static fields
are sent only when the compressor is in the Initialization and
Refresh (IR) state.
– Dynamic fields, such as the serial number, change based on
certain rules. Dynamic fields need to be updated in real time.
For details, see A.1 "General classification" in IETF RFC 3095.
l The number of concurrently activated contexts depends on the
processing capabilities of the compressor and decompressor. The
maximum number of contexts that an eNodeB or a UE supports is
user-defined. When ROHC is enabled, the compressor and
decompressor must negotiate the maximum number of contexts.
– For VoIP services, the number of contexts for each bearer that a
Huawei eNodeB supports meets a VoLTE service compressing
requirement.
– For TCP/IP services, a Huawei eNodeB supports a maximum of
16 contexts for each bearer.
Profile ROHC is an extensible framework consisting of different profiles for

packet flows compliant with different protocols. Profiles define the
compression modes for packet flows with different types of protocol
headers. Each profile is identified by a profile ID. Profile 0x0000
indicates that packet headers are not compressed.
Table 4-2 maps profile IDs to their corresponding protocols. Descriptions of profiles 0x0003
and 0x0004 in this document apply only to macro and LampSite eNodeBs, not to micro

eRAN
eNodeBs. If the PdcpRohcPara.Profiles parameter is set to Profile0x0003 or Profile0x0004

for micro eNodeBs, ROHC does not take effect.
Table 4-2 Mapping between profile IDs and protocols

Profile ID Protocol Remarks
0x0001 RTP, User For details, see RFC 3095 and RFC 4815.
Datagram
Protocol
(UDP), and IP
0x0002 UDP and IP
0x0003 Encapsulating
Security
Payload (ESP)
and IP
0x0004 IP For details, see RFC 3843 and RFC 4815.
0x0006 TCP/IP For details, see RFC 6846 and RFC 5795.
NOTE
ROHC can be used for Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) headers.
4.1.2 Principles and Framework of ROHC
4.1.2.1 ROHC Entities in E-UTRAN

The ROHC entities are located in the user-plane PDCP entities in the UE and eNodeBs.
Figure 4-2 shows the locations of the PDCP entities in the protocol stacks of the UE and
eNodeB.
Figure 4-2 Locations of the PDCP entities
As shown in Figure 4-3, ROHC entities are used only for header compression and
decompression for data packets on the user plane. When DRBs between the UE and eNodeB

eRAN
are already established, the UE and eNodeB can implement ROHC in each DRB
independently.
Figure 4-3 ROHC in PDCP
NOTE
In this figure, "Packets not associated with any PDCP SDU" provides decompression feedback.
For downlink services, the compressor is located within the eNodeB, and the decompressor is
located within the UE. For uplink services, the compressor is located within the UE, and the
decompressor is located within the eNodeB.
4.1.2.2 Basic Framework

The ROHC framework defines the mechanism for header compression and decompression.
Figure 4-4 shows the framework of ROHC that uses profile 0x0001.
l The compressor sends the header-compressed data packets (including the information
about the header compression).
l The compressor and decompressor maintain the context at the TX and RX ends
respectively to ensure the context consistency.
l The decompressor restores the data packets based on the context.

eRAN
Figure 4-4 ROHC framework
4.1.2.2.1 Compression Mechanism
Normal Compression
The normal header compression mechanism of ROHC is as follows:
1. The compressor identifies a packet flow based on the source IP address, destination IP
address, port number, and supported profile. Each packet flow is associated with a
context, which describes the characteristics of the header fields in the flow-specific
packets.
2. Based on the field characteristics, the compressor selects different coding schemes, such
as least significant bit (LSB) or Window-based LSB.
3. The compressor sends the IR packets to the decompressor to establish the context for
decompression. The context on the decompressor side is identical to that on the
compressor side for a given packet flow.
4. The compressor compresses the packet headers and transmits the packets.
5. If the compressor detects that the context has changed or receives feedback from the
decompressor that the decompression has failed, the compressor sends updated
information to the decompressor for context synchronization.
NOTE
l An IR packet, containing the profile and context, is sent only when no context is established or
needs to be updated.
l To prevent errors from propagating, the compressor can add cyclic redundancy check (CRC)
fields to compressed packets for the decompressor to detect errors.
l When a DRB carries more than one packet flow, each packet flow carries its associated CID to
inform the decompressor of its context.
List Compression
Certain information from packet headers to be compressed may be ordered into a list, such as
an RTP contributing source (CSRC) and TCP Option lists. ROHC list compression applies to
ordered lists, which are constant between packets. Figure 4-5 presents the list structure.
Figure 4-5 List structure
The basic principle for list compression is as follows:

eRAN
l When a list remains unchanged for packets, compressed headers do not include the list
information.
l Small changes in the list are represented in compressed headers as additions (Insertion
scheme), or deletions (Removal scheme), or both (Remove Then Insert scheme).
l The list can also be sent in its entirety (Generic scheme). This scheme is used during
context setup for ROHC or as required by the compressor.
Huawei eNodeBs support ROHC list compression only for RTP CSRC and TCP Option lists.
4.1.2.2.2 Decompression Mechanism

The header decompression mechanism of ROHC is as follows:
1. The decompressor receives the IR packets sent by the compressor to establish the
context.
2. The decompressor receives data packets with compressed headers, decompresses the
headers based on the context, sends the successfully decompressed packets to the upper
layer, and sends feedback to inform the compressor of successful decompression. If the
decompression fails, the decompressor discards the packets and informs the compressor
of the failure.
3. When the compressor updates the context, the decompressor receives the update
information and updates the context.
4.1.2.2.3 Context Replication

Context replication is an optional mechanism for ROHC-TCP context initialization. The
eNodeB supports the ROHC-TCP context replication. For short-lived TCP flows, the eNodeB
can establish new contexts based on the existing contexts, reducing the overhead during
context setup.
For details about the state transition mechanism of context replication, see "State Machine
with Context Replication" in IETF RFC 4164.
4.1.2.3 ROHC States
4.1.2.3.1 Compressor States

The ROHC compressor may operate in any of the following states:
l IR state
The IR state ranks the lowest. The compressor operates in this state when the static part
of the context on the decompressor side is not established yet or if the decompression
fails due to decompressor issues. In this state, only IR packets (including uncompressed
data packets and the compression context) are sent.
l First Order (FO) state
When the compressor detects any changes in the dynamic fields of the packet flow, the
compressor enters this state and sends the compressed packets.
l Second Order (SO) state
This is the optimal compression state, in which the compressor sends the data packets
with the maximum compression efficiency. The compressor operates in this state in most
cases.

eRAN
The compressor initially operates in the lowest compression state (IR) and switches gradually
to higher compression states (FO and SO). The compressor makes decisions about
compression state transitions based on the following criteria:
l Variations in the static part or dynamic part of packet headers
l Feedback from the decompressor (ACK or NACK)
l Periodic timeout
State transition of the compressor is related to the operating mode of ROHC. For the
compressor's state transition in different operating modes, see 4.1.2.4 ROHC Operating
Modes.
4.1.2.3.2 Decompressor States

The ROHC decompressor operates in any of the following states:
l No Context
If the context is not established yet or is unusable on the decompressor side, the
decompressor operates in the No Context state.
l Static Context
The decompressor enters this state when detecting that the dynamic fields in the context
are invalid.
l Full Context
The decompressor enters this state after a complete context is established based on
successful decompression of a data packet. In this state, the decompressor can
decompress the data packets compressed with the maximum compression efficiency.
For the state transition of the decompressor, see Figure 4-6.
Figure 4-6 State transition of the decompressor
l The decompressor initially operates in the No Context state. It enters the Full Context
state when the IR packet is successfully decompressed and a complete context is
established.
l The decompressor switches to the Static Context state from the Full Context state when
the dynamic fields in the context become invalid.
l In the Static Context state, the decompressor can switch back to the Full Context state
after restoring the context, or to the No Context state if the static fields in the context
also become invalid.

eRAN
4.1.2.4 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.
4.1.2.4.1 Operating Mode Transition

l For VoIP services, ROHC has the following benefits:
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 decompressor
determines the operating mode transition.
– When the eNodeB is the compressor, the UE functions 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.
n If the PdcpRohcPara.HighestMode parameter is set to R_MODE, the UE can
switch to a higher mode (O-Mode or R-Mode) and stay in R-Mode.
n If the PdcpRohcPara.HighestMode parameter is set to O_MODE, the UE
can switch to and stay in O-Mode.
l For TCP/IP services, ROHC has the following benefits:
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. The operating mode transition is
implemented by periodically updating the contexts and using the optimal method to
reduce the transmission data, improving the compression efficiency.
– Periodic context update
Before a feedback channel is established, the compressor switches back to a lower
state periodically and sends IR/IR-DYN (dynamic) data packets. The compressor
updates the contexts periodically until the feedback channel is established.
– Optimal method
n When the compressor sends to the decompressor for the first time, IR/IR-CR
packets are sent.
n Before confirming packet reception by the decompressor, the compressor
transmits the packet with least changed fields if a field changes.
NOTE
If ROHC uses the O-Mode or R-Mode, the eNodeB exits ROHC when any of the following conditions
are met.
l The number of consecutive CRC error packets is greater than the threshold for proactive exit from
ROHC (6 by default, unconfigurable).
l The number of consecutive CRC error packets which are in the state of FO or SO instead of IR or
IRDYN is greater than the threshold for proactive exit from ROHC (6 by default, unconfigurable).
When the eNodeB exits ROHC, ROHC parameters are negotiated only during inter-cell handovers and
reestablishment (corresponding to steps 2 to 3 in Figure 4-11). For details, see 4.1.3.2 Procedure for
ROHC During a Handover and 4.1.3.3 Procedure for ROHC upon RRC Connection
Reestablishment.

eRAN
4.1.2.4.2 U-Mode
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.
In U-Mode, the compressor sends a data packet carrying the context for many times to ensure
that the context on the decompressor side is synchronized. In addition, the compressor
periodically switches to a lower state to ensure the context synchronization even in error
conditions. Figure 4-7 shows the state transition of the compressor in U-Mode.
Figure 4-7 State transition of the compressor in U-Mode
The compressor initially operates in the IR state. With the optimistic approach, the
compressor switches to a higher state. State transition happens when the compressor confirms
that the decompressor has received the context after sending the data packets containing the
context information for multiple times.
If the compressor is informed that the decompressor has received some of the packets, the
compressor in the IR state switches to the FO state. If the compressor confirms that the
decompressor has received all packets, the compressor switches to the SO state.
Decompression may fail if the decompressor does not receive enough packets containing the
context. Therefore, the compressor must periodically switch back to a lower state. In the FO
state, the compressor periodically switches back to the IR state. In the SO state, the
compressor periodically switches back to the FO or IR state. If the packet header needs to be
updated, the compressor in the SO state switches back to the FO state.
4.1.2.4.3 O-Mode
In O-Mode, the decompressor can inform the compressor of successful or failed context
synchronization. O-Mode uses the context transmission method and feedback information of
U-Mode. Therefore, it provides higher reliability than U-Mode and leads to less feedback than
R-Mode.
Figure 4-8 shows the state transition of the compressor in O-Mode.
l STATIC_NACK means that there is no context or the static fields of the context are
invalid.

eRAN
l NACK means that dynamic fields of the context are invalid.

l ACK means that the decompressor has successfully received the packets from the
compressor.
l Update means that the decompressor is informed that the packet headers are updated.
Figure 4-8 State transition of the compressor in O-Mode
The compressor initially operates in the IR state and later switches to a higher state (FO or
SO) based on the optimistic approach principle or after receiving an ACK message from the
decompressor. If the compressor in a higher state receives a STATIC_NACK message, it
switches back to the IR state. If a compressor in the SO state is informed of a need for an
update in packet headers, it switches to the FO state.
ROHC feedback enhancement in O-Mode can adjust the feedback mechanism to restore
contexts of the UE and eNodeB as soon as possible, reducing the ROHC decompression
failure rate.
l When this function is enabled, the eNodeB immediately sends NACK or
STATIC_NACK messages to the UE after failing to decompress packets.
l When this function is disabled, the eNodeB sends NACK or STATIC_NACK messages
to the UE after a certain number of packets cannot be decompressed.
ROHC feedback enhancement in O-Mode is controlled by the
ROHC_FEEDBACK_ENHANCEMENT_SW option of the
PdcpRohcPara.RohcOptimizationSwitch parameter.
4.1.2.4.4 R-Mode
In R-Mode, sending feedback is the only method to ensure context synchronization between
the compressor and decompressor. The compressor repeatedly sends the context updating
packets until receiving acknowledgment from the decompressor. R-Mode leads to greatest
amount of acknowledgment data and largest link overhead, but provides the most reliable
contexts.
Figure 4-9 shows the state transition of the compressor in R-Mode.

eRAN
Figure 4-9 State transition of the compressor in R-Mode
The compressor initially operates in the IR state and later switches to a higher state (FO or
SO) based on the received ACK message from the decompressor. If the compressor in a
higher state receives a STATIC_NACK message, it switches back to the IR state. If a
compressor in the SO state is informed of a need for an update in packet headers, it switches
to the FO state.
4.1.2.5 Factors Affecting the ROHC Compression Efficiency

The factors affecting the ROHC compression efficiency can be classified into controllable or
uncontrollable ones by the eNodeB.
l Of the uncontrollable factors, 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
The header format determines the ROHC compression efficiency. The UE or the
eNodeB compresses the packet headers based on the header format using an
appropriate profile. In most cases, packets with larger-sized headers have higher
compression efficiency.
– Payload of each data packet on a DRB
The smaller the payload of a packet, the higher the proportion of headers to the total
data traffic and the higher the compression efficiency.
– Number of packet flows on a DRB
If the number of packet flows exceeds the maximum number of ROHC CIDs
supported by the UE or eNodeB, the UE or eNodeB can compress the packet
headers only in some packet flows. In this situation, the ROHC compression
efficiency decreases.
– Method used to handle data packet headers at the application layer
If UDP is used to transmit data at the application layer, the ROHC compression
efficiency drops when the UDP header checksum mechanism is enabled.
– Operating mode of ROHC used in the downlink
This mode is determined by UEs. In U-Mode, the compressor periodically switches
to a lower state, which decreases the compression efficiency. In O-Mode or R-

eRAN
Mode, the compressor does not need to periodically switch to a lower state, which
helps increase the compression efficiency.
l The controllable factors include:
– Operating mode of ROHC used in 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.
– Lower-layer transmission quality
In O-Mode or R-Mode, if a compressed packet fails to be decompressed or a
decompressed packet fails CRC, the decompressor sends a NACK message to the
compressor, and then the compressor switches to a lower state. In this case, the
compression efficiency decreases. Better lower-layer transmission quality leads to a
lower probability of decompression failures or CRC failures and higher
compression efficiency.
4.1.3 ROHC Procedure and Parameter Negotiation

ROHC starts when the EPC initiates DRB setup for VoIP services. When the DRBs are
established, the eNodeB and UE begin to negotiate ROHC parameters. After the parameter
negotiation, the compressor or the decompressor performs header compression or
decompression based on the negotiated ROHC parameters.
4.1.3.1 Procedure for Starting ROHC upon Initial Access

If both the compressor and the decompressor support ROHC and ROHC is enabled, ROHC
starts by default when a VoIP service bearer is set up during initial access of a UE. For
TCP/IP services, ROHC is started only when coverage is weak.
The EPC sends an E-RAB SETUP REQUEST message over the S1 interface, requesting that
the eNodeB set up DRBs for data transmission on the user plane and start ROHC. Figure
4-10 shows the procedure for starting ROHC.

eRAN
Figure 4-10 Procedure for starting ROHC upon initial access
1. ROHC is controlled by CellAlgoSwitch.RohcSwitch and corresponding

PdcpRohcPara.Profiles.
2. For VoIP services, go to step 3 in Figure 4-10 when a VoIP service bearer is set up.
For TCP/IP services, determine whether the coverage is weak. The threshold for
determining weak coverage is controlled by the
PdcpRohcPara.RohcTcpSinrTriggerThld parameter. If the SINR measured by the UE
is less than or equal to the threshold specified by the
PdcpRohcPara.RohcTcpSinrTriggerThld parameter, the next step is performed.
Otherwise, ROHC-TCP is not enabled.
3. The ROHC capability of a UE includes the maximum number of concurrent contexts
(MAX_CID) and the profiles supported by the UE. The UE informs the EPC about its
ROHC capability during the initial registration.
The eNodeB can acquire the profiles supported by the UE from the EPC or directly from
the UE. After the RRC connection is set up, the EPC sends an Initial Context Setup
Request message over the S1 interface to inform the eNodeB of the UE radio capability
reported by the UE during initial registration. If the eNodeB fails to obtain the UE's
ROHC capability information from the EPC, the eNodeB sends a UE Capability Enquiry
message over the Uu interface to query the UE's ROHC capability.

eRAN
4. The eNodeB compares the MAX_CID in the ROHC capability information reported by
the UE with the eNodeB-supported maximum number of concurrently active contexts
per UE, and chooses the smaller one as the maximum number of concurrent contexts
supported by the UE.
5. The eNodeB identifies the UE-supported profiles using the intersection of the following
two profiles:
– UE-supported profiles stored on the eNodeB
– eNodeB-supported profiles specified by the PdcpRohcPara.Profiles parameter
NOTE
If the compressor and decompressor support any of the profiles listed in Table 4-2, they support
profile 0x0000.
6. The eNodeB reallocates the number of concurrent contexts for each DRB of the UE
based on the maximum number of concurrent contexts supported by the UE. Then, the
eNodeB sends the reallocated number of concurrent contexts and the determined profiles
as the ROHC parameters to the UE through the Uu interface.
NOTE
The reallocation of the number of concurrent contexts does not lead to a change in the number of
concurrent contexts already allocated for the UE's DRBs.
The eNodeB can use an RRCConnectionReconfiguration or RRCConnectionReestablishment
message to inform the UE of the negotiated ROHC parameters.
7. After ROHC is started, the compressor and decompressor operate within the ROHC
framework for both the uplink and downlink.
4.1.3.2 Procedure for ROHC During a Handover

The ROHC procedure varies according to handover types:
l Intra-cell handover: ROHC parameters remain unchanged and do not need to be
renegotiated.
l Inter-cell handover: ROHC parameters must be renegotiated.
During an inter-eNodeB handover within the E-UTRAN, the source eNodeB informs the
target eNodeB of the ROHC capability of the UE, and the target eNodeB recalculates the
capability of the UE. After the handover, the UE and the target eNodeB operate with the
new ROHC parameters. Figure 4-11 shows the detailed procedure.

eRAN
Figure 4-11 Procedure for ROHC during a handover
a. The UE sends a measurement report in the source cell.

b. The source eNodeB makes a handover decision. If the eNodeB decides to perform
the handover, it sends a Handover Request message including the UE's ROHC
capability information to the target eNodeB.
c. After deciding to admit the handed-over UE, the target eNodeB calculates the
ROHC parameters, and then sends a Handover Request Acknowledge message
carrying the new ROHC parameters to the source eNodeB.
NOTE
The procedure for calculating ROHC parameters by the target eNodeB is the same as that by
the source eNodeB. For details, see 4.1.3.1 Procedure for Starting ROHC upon Initial
Access.
d. The source eNodeB sends an RRC Connection Reconfiguration message to instruct
the UE to perform the handover. The message carries the new ROHC parameters
sent by the target eNodeB.
e. The UE attempts to access the target cell.
f. After the UE successfully accesses the target cell, the UE and eNodeB begin data
transmission on the user plane using the new ROHC parameters.
NOTE
During the handover, the source cell does not transmit the ROHC context to the target cell.
The eNodeB reestablishes the corresponding context if the target cell decides to start ROHC.
If the X2 interface is not set up between the source and target eNodeBs, the handover is
performed over the S1 interface. In this case, the ROHC parameter negotiation process is the
same as that performed over the X2 interface.
4.1.3.3 Procedure for ROHC upon RRC Connection Reestablishment

The ROHC procedure differs between target cells for RRC connection reestablishment.

eRAN
l If an RRC connection is reestablished with the same cell, the original context for ROHC
is retained.
l If an RRC connection is reestablished with another cell, the original context for ROHC
needs to be renegotiated.
l If an RRC connection is reestablished with a cell served by another Huawei eNodeB, the
target eNodeB sends a Huawei proprietary message to the source eNodeB to learn the
UE's ROHC capability and then calculates the ROHC parameters. If the settings of new
ROHC parameters differ from those of the original ones, the target eNodeB informs the
UE of the new parameters in the first RRC_CONN_RECFG message after the RRC
connection is reestablished.
NOTE
If an RRC connection is reestablished with a cell served by another eNodeB deployed by a

different vendor, the procedure for ROHC upon RRC connection reestablishment will fail.
4.2 Network Analysis
4.2.1 Benefits
l For VoIP services, ROHC has the following benefits:
– Compresses the headers of voice packets. If all the UEs on the live network support
ROHC, the compression efficiency can reach 15%.
– Reduces the amount of data transmitted over the air interface. For voice service
users at the cell edge, it helps to reduce the number of Radio Link Control (RLC)
segments and decrease the voice packet delivery delay. It can increase the uplink
coverage by about 1 dB to 2 dB and ensure voice quality, for example, maintaining
the voice quality at a mean opinion score (MOS) of 3.0.
– Reduces the resource blocks (RBs) used for voice service users. For example, if
voice service users with 12.65 kbit/s Adaptive Multirate (AMR) transmission are
evenly distributed in a cell, the number of RBs used for these users will be reduced
by about 20% after ROHC is enabled. The RBs saved by ROHC can be used to
increase the data service throughput of the cell or the number of voice service users
in the cell. The amount of the increase depends on many factors, such as:
n User locations
n User quantity
n User data service model (such as full buffer and burst services)
n RB usage
n Availability of PDCCH control channel elements (CCEs)
n ROHC operating mode
n ROHC compression efficiency
n Support and compatibility of UEs for ROHC
n AMR used for voice service users
The increase in the data service throughput of a cell is positively correlated with the
number of RBs used for data service users if all the following conditions are met:
n RBs of a cell are limited.
n PDCCH CCEs in the cell are sufficient.

eRAN
n ROHC works properly.

n Users are evenly distributed and require a large data service volume in the cell.
l For TCP/IP services, ROHC has the following benefits:
– Compresses the headers of uplink TCP packets. If all the UEs on the live network
support ROHC, the compression efficiency can reach 20% to 50%.
– Reduces the amount of data transmitted over the air interface. For uplink TCP/IP
services in weak coverage networks, it helps to reduce the number of RLC
segments and improve the user throughput and uplink coverage by about 2 dB to 3
dB.
– Reduces the RBs used for voice service users. For UEs supporting ROHC-TCP, the
number of RBs used for these UEs will be reduced by about 15% after ROHC is
enabled.
4.2.2 Impacts
Network Impacts
ROHC reduces the amount of data transmitted over the air interface as well as the throughput.
VoLTE UEs found incompatible with ROHC in interoperability tests (IOTs) always transmit
uncompressed IR packets even after ROHC is enabled. In this case, the expected coverage or
capacity gains offered by ROHC are not achieved, and the number of RBs used for UEs
running voice services slightly increases.
However, the amount of feedback depends on the ROHC operating mode. More feedback
uses more radio resources, which limits system capacity expansion.

eRAN
Function Impacts
RAT Function Function Refer Description
Name Switch ence
FDD VoIP Semi- For the uplink, VoLTE When ROHC is enabled,
TDD Persistent the compressed packet sizes
Scheduling SpsSchSwitch fluctuate, even during
option of the talk spurts, due to
CellAlgoSwitc changes in the quality of
h.UlSchSwitch the radio channels, the
parameter ROHC operating mode
For the used, and variations in
downlink, the the dynamic fields of the
SpsSchSwitch packet headers at the
option of the application layer.
CellAlgoSwitc Therefore, ROHC has an
h.DlSchSwitch impact on semi-persistent
parameter scheduling. If the packet
size is greater than the
maximum size allowable
for semi-persistent
scheduling, the eNodeB
uses dynamic scheduling
for the data beyond the
size limit.
FDD Voice AmrVoiceFra VoLTE The smart AMR voice

TDD characteristic meSmartCove frame recovery function
awareness rySw option of provides higher gains
scheduling the when it is working with
CellUlschAlgo. ROHC.
UlEnhencedVoi
pSchSw
parameter
FDD Normal PreAllocationS Sched When the uplink normal

TDD preallocation witch option of uling or smart preallocation
the function is enabled,
CellAlgoSwitc ROHC will yield few
h.UlSchSwitch gains in resource saving
parameter in the uplink if the size of
packets scheduled by the
FDD Smart SmartPreAlloc Sched eNodeB in preallocation
TDD preallocation ationSwitch uling is greater than the size of
option of the voice packets.
CellAlgoSwitc
h.UlSchSwitch
parameter

eRAN
RAT Function Function Refer Description

Name Switch ence
TDD Uplink data BasicUdcSwitc Uplink Uplink data compression

compression h option of the Data and ROHC-TCP can be
CellAlgoSwitc Comp enabled simultaneously.
h.UdcAlgoSwit ressio However, for a given
ch parameter n UE:
(TDD) l Both uplink data
compression and
ROHC-TCP can take
effect simultaneously
on bearers with
different QCIs.
l Uplink data
compression and
ROHC-TCP cannot
take effect
simultaneously on
bearers with the same
QCI. The function
whose activation
conditions are met
first takes effect first.
The other function
can take effect only
after the function that
has taken effect
terminates.
4.3 Requirements
4.3.1 Licenses
The following are FDD license requirements.
Feature ID Feature Name Model Sales Unit
LOFD-001017 RObust Header LT1S00ROHC00 per RRC Connected User

Compression
(ROHC)
The following are TDD license requirements.

eRAN
Feature ID Feature Name Model Sales Unit
TDLOFD-0010 RObust Header LT1ST0ROHC per RRC Connected User

17 Compression 00
(ROHC)
4.3.2 Software
Prerequisite Functions
None
Mutually Exclusive Functions

None
4.3.3 Hardware
Base Station Models

No requirements
Boards
l For VoIP: no requirements
l For ROHC-TCP: The LMPT or LBBPc cannot be used.
RF Modules
No requirements
4.3.4 Others
l Before VoIP services are deployed, mainstream commercial VoLTE UEs need to pass
IOTs.
l Before TCP/IP services are deployed, mainstream commercial ROHC-TCP UEs need to
pass IOTs.
4.4 Operation and Maintenance
4.4.1 Data Configuration
4.4.1.1 Data Preparation

Table 4-3 and Table 4-4 describe the parameters used for function activation and
optimization, respectively.

eRAN
Table 4-3 Parameters used for activation

Parameter Parameter ID Option Setting Notes
Name
ROHC switch CellAlgoSwitc N/A Set this parameter to ON.

h.RohcSwitch
ROHC Highest PdcpRohcPara N/A This parameter applies to the

mode .HighestMode uplink only. The highest operating
mode of ROHC in the downlink is
controlled by UEs.
Set this parameter to the
recommended value O_MODE.
The reasons are as follows:
l When U-Mode is used, if the
radio link quality is poor, the
compression will be inefficient.
l R-Mode introduces more
feedback data than O-Mode
although these two modes have
similar compression efficiency.
In addition, frame loss may
occur on some VoLTE UEs
working in R-Mode.
Compression PdcpRohcPara Profile0x0001 l For VoIP services, you are

profiles .Profiles Profile0x0002 advised to select the
Profile0x0001 and
Profile0x0006 Profile0x0002 options of this
parameter because commercial
VoLTE UEs currently do not
support settings of
Profile0x0003 and
Profile0x0004 options.
l For TCP/IP services, select the
Profile0x0006 option if the
turbo start video function is
enabled. For details, see Video
Experience Optimization.
NOTE
If the PdcpRohcPara.Profiles parameter is adjusted during eNodeB operation, the adjustment affects
only new services instead of ongoing services.

eRAN
Table 4-4 Parameters used for optimization

Parameter Parameter ID Option Setting Notes
Name
ROHC PdcpRohcPara ROHC_FEEDB Select this option.

Optimization .RohcOptimizat ACK_ENHAN
Switch ionSwitch CEMENT_SW
4.4.1.2 Using MML Commands
Activation Command Examples

//Enabling ROHC
//Macro eNodeB
MOD CELLALGOSWITCH:LocalCellId=0,ROHCSWITCH=ON;
MOD PDCPROHCPARA:
HIGHESTMODE=O_MODE,PROFILES=Profile0x0001-1&Profile0x0002-1&Profile0x0003-0&Profil
e0x0004-0;
//Micro eNodeB
MOD CELLALGOSWITCH:LocalCellId=0,ROHCSWITCH=ON;
MOD PDCPROHCPARA: HIGHESTMODE=O_MODE,PROFILES=Profile0x0001-1&Profile0x0002-1;
Optimization Command Examples

MOD
PDCPROHCPARA:HIGHESTMODE=O_MODE,ROHCOPTIMIZATIONSWITCH=ROHC_FEEDBACK_ENHANCEMENT_S
W-1;
Deactivation Command Examples

//Disabling ROHC
//Macro eNodeB
MOD CELLALGOSWITCH:LocalCellId=0,ROHCSWITCH=OFF;
//Micro eNodeB
MOD CELLALGOSWITCH:LocalCellId=0,ROHCSWITCH=OFF;
4.4.1.3 Using the CME

For detailed operations, see CME-based Feature Configuration.
4.4.2 Activation Verification

Step 1 Start a Uu interface tracing task on the U2000 client.
Step 2 Use an ROHC-capable UE to perform a VoIP service. Check the RRC_UE_CAP_INFO

message to determine whether the UE supports ROHC and which profiles the UE supports.
As shown in Figure 4-12, if the value of any profile is TRUE, the UE supports ROHC and the
profiles with a value of TRUE.

eRAN
Figure 4-12 RRC_UE_CAP_INFO message
Step 3 Check the RRC_CONN_RECFG message over the Uu interface to determine whether ROHC
has been activated.
l If the information elements (IEs) pdcp-Config > headerCompression > rohc are
displayed, as shown in Figure 4-13, ROHC has been activated.
l If the IEs pdcp-Config > headerCompression > notUsed: NULL are displayed, as shown
in Figure 4-14, ROHC has not been activated.

eRAN
Figure 4-13 RRC_CONN_RECFG message (after activation)
Figure 4-14 RRC_CONN_RECFG message (before activation)
Step 4 Check the performance counters on the U2000 client after the ROHC feature has been
activated.
NOTE
ROHC can only be used on the user plane. Ensure that the values of the preceding performance counters
are collected when the eNodeB is transmitting user plane data.
l In the downlink: A smaller value of L.PDCP.DL.ROHC.Voice.HdrComp.Bytes/
L.PDCP.DL.ROHC.Voice.Hdr.Bytes or L.PDCP.DL.RoHC.PktCompRatio indicates
higher compression efficiency.
l In the uplink:
– A smaller counter value indicates a higher decompression success rate. If the
counter value is 0, the decompression success rate is 100%.
Decompression failure rate = L.PDCP.UL.RoHC.FailDecomp.VoLTE/
L.PDCP.UL.RoHC.TotalDecomp.VoLTE

eRAN
– A smaller value of L.PDCP.UL.ROHC.Voice.HdrComp.Bytes/

L.PDCP.UL.ROHC.Voice.Hdr.Bytes or L.PDCP.UL.RoHC.PktCompRatio
indicates higher compression efficiency.
NOTE
After ROHC is enabled, the values of L.PDCP.DL.ROHC.Voice.HdrComp.Bytes/

L.PDCP.DL.ROHC.Voice.Hdr.Bytes, L.PDCP.DL.RoHC.PktCompRatio,
L.PDCP.UL.ROHC.Voice.HdrComp.Bytes/L.PDCP.UL.ROHC.Voice.Hdr.Bytes, and
L.PDCP.UL.RoHC.PktCompRatio have the following characteristics:
l If ROHC is working under extreme conditions such as ping-pong handovers caused by very poor
radio conditions, the compressor sends only IR packets (data packets cannot be compressed)
which have more bytes than original packets, and the counter values are greater than or equal to
100%. This rarely occurs.
l If ROHC is working under normal radio conditions, the counter values are less than 100%.
----End
4.4.3 Network Monitoring

After ROHC is enabled, monitor the counters listed in the following table.
Table 4-5 Performance counters to be monitored

Counter ID Counter Description Principle
Name
1526728523 L.PDCP.UL.R Compression rate of all uplink Smaller values

oHC.PktComp PDCP SDUs (including headers indicate higher
Ratio and payloads) after the ROHC compression
efficiency.
1526727350 L.PDCP.DL.R Compression rate of all downlink
oHC.PktComp PDCP SDUs (including headers
Ratio and payloads) after the ROHC
1526745690 L.PDCP.UL.R Number of uplink VoLTE packets Decompression

oHC.FailDeco that fail to be decompressed in failure rate of
mp.VoLTE ROHC uplink VoLTE
packetsa. A
1526746015 L.PDCP.UL.R Number of uplink VoLTE packets
smaller counter
oHC.TotalDec that need to be decompressed in
value indicates
omp.VoLTE ROHC
a higher
decompression
success rate,
and a larger
counter value
indicates a
higher
decompression
failure rate.
1526728524 L.Traffic.User. Maximum number of UEs on The number of

RoHC.Max which ROHC takes effect in a cell UEs on which
ROHC takes
effect has a
positive

eRAN
Counter ID Counter Description Principle

Name
1526728525 L.Traffic.User. Average number of UEs on which correlation with

RoHC.Avg ROHC takes effect in a cell the values of
these counters.
1526746663 L.PDCP.UL.R Number of bytes of uplink voice ROHC

OHC.Voice.Hd service PDCP SDU headers before compression
rComp.Bytes ROHC-based header rate of uplink
decompression in a cell voice servicesb.
A smaller
1526746658 L.PDCP.UL.R Number of bytes of uplink voice
counter value
OHC.Voice.Hd service PDCP SDU headers after
indicates higher
r.Bytes ROHC-based header
compression
decompression in a cell
efficiency.
1526746657 L.PDCP.DL.R Number of bytes of downlink ROHC

OHC.Voice.Hd voice service PDCP SDU headers compression
rComp.Bytes after ROHC-based header rate of
compression in a cell downlink voice
servicesc. A
1526746662 L.PDCP.DL.R Number of bytes of downlink
smaller counter
OHC.Voice.Hd voice service PDCP SDU headers
value indicates
r.Bytes before ROHC-based header
higher
compression in a cell
compression
efficiency.
NOTE
a: Decompression failure rate of uplink VoLTE packets = L.PDCP.UL.RoHC.FailDecomp.VoLTE/

L.PDCP.UL.RoHC.TotalDecomp.VoLTE
b: ROHC header compression ratio of uplink voice services =
L.PDCP.UL.ROHC.Voice.HdrComp.Bytes/L.PDCP.UL.ROHC.Voice.Hdr.Bytes
c: ROHC header compression ratio of downlink voice services =
L.PDCP.DL.ROHC.Voice.HdrComp.Bytes/L.PDCP.DL.ROHC.Voice.Hdr.Bytes

eRAN
ROHC Feature Parameter Description 5 Parameters
5 Parameters
Table 5-1 Parameters

MO Parame MML Feature Feature Description
ter ID Comma ID Name
nd
PdcpRo Profiles MOD LOFD-0 RObust Meaning:

hcPara PDCPR 01017/ Header Indicates the compression profiles supported by the
OHCPA TDLOF Compre eNodeB.
RA D-00101 ssion
LST 7 (ROHC) Under the ROHC framework, header compression
PDCPR LAOFD Turbo algorithms vary with protocols. Profiles define the
OHCPA -131204 Start header compression protocols (such as RTP/UDP/IP
RA / Video or TCP/IP), which are under the same ROHC
TDLOF framework, for specific types of packet streams. Each
D-13120 profile has a unique identifier.
5 As defined by LTE specifications, the eNodeB
supports the following profiles:
Profile 0x0001 (usage: RTP/UDP/IP; reference: RFC
3095 and RFC 4815)
Profile 0x0002 (usage: UDP/IP; reference: RFC 3095
and RFC 4815)
Profile 0x0003 (usage: ESP/IP; reference: RFC 3095
and RFC 4815)
Profile 0x0004 (usage: IP; reference: RFC 3843 and
RFC 4815)
Profile 0x0006 (usage: TCP/IP; reference: RFC 6846)
GUI Value Range: Profile0x0001(Profile0x0001),
Profile0x0002(Profile0x0002),
Profile0x0006(Profile0x0006)
Unit: None

eRAN

nd
Actual Value Range: Profile0x0001, Profile0x0002,

Profile0x0003, Profile0x0004, Profile0x0006
Default Value: Profile0x0001:On, Profile0x0002:On,
Profile0x0003:On, Profile0x0004:On,
Profile0x0006:Off
PdcpRo RohcOp MOD LOFD-0 RObust Meaning:

hcPara timizatio PDCPR 01017/ Header Indicates whether to enable ROHC-related
nSwitch OHCPA TDLOF Compre optimization functions.
RA D-00101 ssion
LST 7 (ROHC) ROHC_FEEDBACK_ENHANCEMENT_SW:
PDCPR Indicates whether an eNodeB sends NACK feedback
OHCPA immediately after ROHC decompression failures
RA occur in the uplink when the HighestMode parameter
is set to O_MODE in the PdcpRohcPara MO. The
eNodeB immediately sends NACK feedback in the
previous scenario only if this option is selected. This
parameter applies only to LTE FDD and LTE TDD.
GUI Value Range:
ROHC_FEEDBACK_ENHANCEMENT_SW(ROHC
_FEEDBACK_ENHANCEMENT_SW)
Unit: None
Actual Value Range:
ROHC_FEEDBACK_ENHANCEMENT_SW
Default Value:
ROHC_FEEDBACK_ENHANCEMENT_SW:Off

eRAN

nd
PdcpRo Highest MOD LOFD-0 RObust Meaning: Indicates the operating mode of ROHC. In
hcPara Mode PDCPR 01017/ Header Unidirectional Mode (U-Mode), packets are sent only
OHCPA TDLOF Compre from the compressor to the decompressor, and a
RA D-00101 ssion feedback channel is not mandatory. Therefore, U-
LST 7 (ROHC) Mode is less reliable than Bidirectional Optimistic
PDCPR Mode (O-Mode) and Bidirectional Reliable Mode (R-
OHCPA Mode), but its feedback-induced overhead is
RA minimum compared with the overhead in O-Mode and
R-Mode. In O-Mode, the decompressor can send
feedback messages to the compressor to indicate
decompression failures or successful context updates.
O-Mode is more reliable than U-Mode and requires a
smaller amount of feedback than R-Mode. In R-Mode,
the reliability of context synchronization between the
compressor and the decompressor is higher than that
in any other mode. However, because of frequent
feedback, R-Mode causes the largest amount of link
overhead.
GUI Value Range: U_MODE(Unidirectional Mode),
O_MODE(Bi-directional Optimistic Mode),
R_MODE(Bi-Directional Reliable Mode)
Unit: None
Actual Value Range: U_MODE, O_MODE,
R_MODE
Default Value: O_MODE(Bi-directional Optimistic
Mode)
CellAlg RohcSw MOD LOFD-0 RObust Meaning:

oSwitch itch CELLA 01017/ Header Indicates whether to enable ROHC in the cell. If this
LGOSW TDLOF Compre parameter is set to ON, ROHC is enabled for UEs
ITCH D-00101 ssion supporting ROHC in the cell. If this parameter is set to
LST 7 (ROHC) OFF, ROHC is disabled in the cell.
CELLA LAOFD Turbo
LGOSW -131204 Start The value ON is recommended if VoIP and video
ITCH / Video services are ongoing in the cell.
TDLOF GUI Value Range: OFF(Off), ON(On)
D-13120 Unit: None
5
Actual Value Range: OFF, ON
Default Value: OFF(Off)

eRAN

nd
PdcpRo RohcTc MOD LAOFD Turbo Meaning: Indicates the SINR threshold for triggering
hcPara pSinrTri PDCPR -131204 Start ROHC TCP. This parameter controls the activation
ggerThl OHCPA / Video scope of ROHC TCP. When ROHC TCP is enabled
d RA TDLOF and a UE supports ROHC TCP, the eNodeB delivers
LST D-13120 the RRC connection reconfiguration message to the
PDCPR 5 UE to activate ROHC TCP if the uplink SINR of the
OHCPA UE periodically measured by the eNodeB is lower
RA than the threshold. In this case, the UE enters the
ROHC TCP state and performs ROHC TCP
compression on uplink TCP/IP packet headers. This
GUI Value Range: -5~10
Unit: dB
Actual Value Range: -5~10
Default Value: 0

eRAN

nd
CellAlg UlSchS MOD LOFD-0 VoIP Meaning:

oSwitch witch CELLA 01016/ Semi- Indicates whether to enable uplink scheduling
LGOSW TDLOF persisten functions for the cell.
ITCH D-00101 t
LST 6 Scheduli SpsSchSwitch: Indicates whether to enable semi-
CELLA LOFD-0 ng persistent scheduling during talk spurts of VoLTE
LGOSW 01048/ TTI services. If this option is selected, semi-persistent
ITCH TDLOF Bundlin scheduling is applied during talk spurts of VoLTE
D-00104 g services. If this option is deselected, dynamic
8 scheduling is applied during talk spurts of VoLTE
Dynami services. This option applies only to LTE FDD and
LBFD-0 c LTE TDD.
0101502 Scheduli
/ ng SinrAdjustSwitch: Indicates whether to adjust the
TDLBF Basic measured SINR based on ACK/NACK messages in
D-00101 Scheduli the UL hybrid automatic repeat request (HARQ)
502 ng processes. This option applies only to LTE FDD and
LBFD-0 LTE TDD.
MBR>G
02025/ BR PreAllocationSwitch: Indicates whether to enable
TDLBF Configu preallocation in the uplink. If this option is selected:
D-00202 ration (1) If the SmartPreAllocationSwitch option is
5
UL 2x2 deselected and a UE is in the discontinuous reception
LBFD-0 MU- (DRX) state, preallocation is disabled for the UE in
70102/ MIMO the uplink; (2) If the SmartPreAllocationSwitch option
TDLBF is deselected and the UE is not in the DRX state,
D-07010 UL 2x4 preallocation is enabled for the UE in the uplink; (3) If
2 MU- the SmartPreAllocationSwitch option is selected and
MIMO the SmartPreAllocationDuration parameter value is
LOFD-0
01002 AMC greater than 0, smart preallocation is enabled for the
Uplink UE in the uplink; (4) If the SmartPreAllocationSwitch
LOFD-0 option is selected and the SmartPreAllocationDuration
01058/ Coverag
e parameter value is 0, preallocation is disabled for the
TDLOF UE in the uplink. If this option is deselected,
D-00105 Improve
ment for preallocation is disabled for the UE in the uplink. If
8 bearer-level preallocation or bearer-level smart
Video
LBFD-0 preallocation is enabled for a QCI, cell-level
01006/ Enhance preallocation and cell-level smart preallocation do not
TDLBF d UL apply to UEs with the QCI. This option applies only to
D-00100 Frequen LTE FDD and LTE TDD.
6 cy
Selectiv UlVmimoSwitch: Indicates whether to enable multi-
LOFD-1 e user MIMO (MU-MIMO) in the uplink. If this option
20205 Scheduli is selected, the eNodeB performs MU-MIMO pairing
LBFD-0 ng among UEs based on related principles. UEs forming
60102 UL a pair transmit data using the same time-frequency
TDLEO 2x64 resources, which improves the system throughput and
FD-121 MU- spectral efficiency. This option applies only to LTE
60302 MIMO FDD and LTE TDD.

eRAN

nd
TDLEO UL 4- TtiBundlingSwitch: Indicates whether to enable

FD-121 Layer transmission time interval (TTI) bundling. If TTI
609 MU- bundling is enabled, more transmission opportunities
TDLEO MIMO are available to UEs within the delay budget for
FD-121 UL 8- VoLTE services on the Uu interface, thereby
610 Layer improving uplink coverage. This option applies only
MU- to LTE FDD and LTE TDD.
TDLOF
D-07022 MIMO SmartPreAllocationSwitch: Indicates whether to
2/ Scheduli enable uplink smart preallocation when the
LOFD-1 ng PreAllocationSwitch option is selected. If both the
31213 Based PreAllocationSwitch option and this option are
on Max selected and the SmartPreAllocationDuration
Bit Rate parameter in the CellPreallocGroup MO is set to a
value greater than 0, uplink smart preallocation is
enabled. Otherwise, uplink smart preallocation is
disabled. This option applies only to LTE FDD and
LTE TDD.
PuschDtxSwitch: Indicates whether the eNodeB uses
the PUSCH discontinuous transmission (DTX)
detection result during uplink scheduling. If this
option is selected for an LTE FDD cell, the eNodeB
determines whether to perform adaptive
retransmission, and also adjusts the CCE aggregation
level of the PDCCH carrying downlink control
information (DCI) format 0 based on the PUSCH
DTX detection result during uplink scheduling. If an
LTE FDD cell is established on an LBBPc, this option
takes effect only if the cell uses less than four RX
antennas and normal cyclic prefix (CP) in the uplink
and the SrsCfgInd parameter in the SRSCfg MO is set
to BOOLEAN_TRUE(True). Note that the LBBPc
does not support PUSCH DTX detection for VMIMO
UEs. For an LTE TDD cell, this option takes effect
only when the uplink-downlink subframe
configuration is set to SA2 or SA5. If this option takes
effect, the eNodeB adjusts the CCE aggregation level
based on the PUSCH DTX detection results. Note that
LTE TDD cells established on LBBPc boards do not
support PUSCH DTX detection. This option applies
only to LTE FDD and LTE TDD.
UlIblerAdjustSwitch: Indicates whether to enable the
uplink IBLER adjustment algorithm. If this option is
selected, the target IBLER is adjusted for UEs based
on the channel quality and fluctuation to increase the
cell throughput. This option applies only to LTE FDD
and LTE TDD. If this option is selected independently

eRAN

nd
for FDD cells with the UlTargetIBlerAdaptType

option deselected, the algorithm does not take effect.
UlEnhancedFssSwitch: Indicates whether to enable
uplink load-based enhanced frequency selective
scheduling. This option applies only to LTE FDD.
UlIicsAlgoSwitch: Indicates whether to enable the
uplink interference-intensity-based coordinated
scheduling (UL IICS) algorithm. If this option is
selected, interference can be reduced based on
accurate detection of user attributes and scheduling
resource coordination, increasing the cell edge
throughput. This option applies only to LTE TDD.
UlEnhancedSrSchSwitch: Indicates whether uplink re-
scheduling is performed only when the On Duration
timer for the DRX long cycle starts. Uplink re-
scheduling is required if the number of HARQ
retransmissions for a scheduling request (SR) reaches
the maximum value but the scheduling still fails. If
this option is selected, uplink re-scheduling is
performed only when the On Duration timer for the
DRX long cycle starts. If this option is deselected,
uplink re-scheduling is performed immediately when
the number of HARQ retransmissions for SR reaches
the maximum value but the scheduling still fails. It is
recommended that this option be selected for live
networks. This option applies only to LTE FDD and
LTE TDD.
SchedulerCtrlPowerSwitch: Indicates whether the
uplink scheduler performs scheduling without
considering power control restrictions. If this option is
selected, the uplink scheduler performs scheduling
without considering power control restrictions,
ensuring full utilization of the transmit power for all
UEs. If this option is deselected, the uplink scheduler
considers power control restrictions while performing
scheduling. In this case, the transmit power cannot be
fully used for UEs at the cell edge or between the cell
edge and cell center. This option applies only to LTE
FDD and LTE TDD.
UlMinGbrSwitch: Indicates whether to ensure uplink
minimum guaranteed bit rate (GBR). If this option is
selected, the minimum GBR of non-GBR services is
ensured by increasing the scheduling priority of UEs
whose non-GBR service rates are lower than the
minimum GBR of GBR services. This option applies
only to LTE FDD and LTE TDD.

eRAN

nd
UlMbrCtrlSwitch: Indicates whether to enable uplink

scheduling based on the maximum bit rate (MBR) and
guaranteed bit rate (GBR) on the GBR bearer. If this
option is selected, the eNodeB performs uplink
scheduling on GBR bearers based on the MBR and
GBR. If this option is deselected, the eNodeB
performs uplink scheduling on GBR bearers based
only on the GBR. This option applies only to LTE
FDD and LTE TDD.
MbrUlSchSwitch: Indicates whether the eNodeB
performs uplink scheduling based on the MBR. If this
option is selected, the eNodeB prioritizes UEs based
on the MBRs during uplink scheduling. This option
applies only to LTE FDD and LTE TDD.
UeAmbrUlSchSwitch: Indicates whether the eNodeB
performs uplink scheduling based on the aggregate
maximum bit rate (AMBR) of UEs. If this option is
selected, the eNodeB prioritizes UEs based on the
AMBRs of UEs during uplink scheduling. This option
UlEnhancedDopplerSwitch: Indicates whether to
enable enhanced uplink scheduling based on mobility
speed estimation. If this option is selected, enhanced
uplink scheduling based on mobility speed estimation
is enabled. In enhanced uplink scheduling based on
mobility speed estimation, the eNodeB uses Doppler
measurement results to identify low-speed UEs to
further improve uplink performance of low-speed
UEs. If this option is deselected, enhanced uplink
scheduling based on mobility speed is disabled.
Enhanced uplink scheduling based on mobility speed
takes effect only when the DopMeasLevel parameter
is set to CLASS_1(CLASS_1) and the
UlEnhancedDopplerSwitch option is selected. This
option does not apply to cells established on LBBPc
boards. This option applies only to LTE FDD.
UlRaUserSchOptSw: Indicates whether the eNodeB
raises the scheduling priority of UEs sending uplink
access signaling, including MSG5 and the RRC
Connection Reconfiguration Complete message. If
this option is selected, the eNodeB raises the
scheduling priority of UEs sending uplink access
signaling. If this option is deselected, the eNodeB
does not raise the scheduling priority of UEs sending
uplink access signaling. In NB-IoT scenarios with air
interface resource congestion, this option restricts the

eRAN

nd
number of preambles to perform flow control on UEs

accessing the cell.
UlLast2RetransSchOptSwitch: Indicates whether to

optimize the scheduling policy for the last two
retransmissions. If this option is selected, the
scheduling policy is optimized for the last two
retransmissions. If the UE transmit power is not
limited, adaptive retransmission is used, and the
number of RBs increases in the last two
retransmissions to increase the receive success rate of
the last two retransmissions and decrease uplink
RBLER. If this option is deselected, the scheduling
policy is not optimized for the last two
retransmissions. This option applies only to LTE FDD
and LTE TDD.
UlInterfFssSwitch: Indicates whether to enable

interference-based uplink frequency-selective
scheduling. This option applies only to LTE FDD.
UlSmallRBSpectralEffOptSw: Indicates whether to

improve the spectral efficiency of small RBs in the
uplink. If this option is selected, the spectral efficiency
of small RBs in the uplink is optimized, ensuring that
the transmission block size calculated based on
optimized spectral efficiency is not less than the traffic
volume to be scheduled. If this option is deselected,
the spectral efficiency of small RBs in the uplink is
not optimized. This option applies only to LTE FDD
and LTE TDD.
PuschUsePucchRbSwitch: Indicates whether PUCCH

RBs can be occupied by the PUSCH. In scenarios
with a single user: If this option is selected, PUCCH
RBs can be occupied by the PUSCH; if this option is
deselected, PUCCH RBs cannot be occupied by the
PUSCH. In scenarios with multiple users, PUCCH
RBs cannot be occupied by the PUSCH regardless of
the setting of this option. This option applies only to
LTE FDD and LTE TDD.
PuschDtxSchOptSwitch: If this option is selected, the

eNodeB determines whether to perform adaptive
retransmission based on the PUSCH DTX detection
result during uplink scheduling. This option takes
effect only when the uplink-downlink subframe
configuration SA2 or SA5 is used. If an LTE TDD cell
is established on an LBBPc, PUSCH DTX detection is
not supported. This option applies only to LTE TDD.

eRAN

nd
PrachRbReuseSwitch: If this option is selected, the

PUSCH and PRACH transmissions can use the same
resource. If this option is deselected, the PUSCH and
PRACH transmissions cannot use the same resource.
This option applies only to LTE FDD and LTE TDD.
ULFSSAlgoswitch: If this option is deselected, uplink
frequency-selective scheduling is disabled. If this
option is selected, uplink frequency-selective
scheduling is enabled. This option applies only to LTE
TDD.
SrSchDataAdptSw: Indicates whether to enable data
amount adaptation in SR-based scheduling. Data
amount adaptation in SR-based scheduling is enabled
only when this option is selected. This option applies
only to LTE FDD.
UlFssUserThdStSwitch: If this option is selected, the
UE number threshold is optimized for uplink
frequency selective scheduling. If this option is
deselected, the UE number threshold is not optimized
for uplink frequency selective scheduling. This option
HighOrderVMIMOSwitch: Indicates whether to
enable high order VMIMO. If this option is selected,
high order VMIMO is enabled. If this option is
deselected, high order VMIMO is disabled. This
option applies only to LTE TDD.
VMIMOReduceMCSRiseRBSwitch: Indicates
whether to perform uplink MU MIMO for UEs whose
MCS index is reduced in the downlink to increase the
number of available RBs in non-massive MIMO
scenarios, or whether the beam determination criteria
are loosened up for uplink MU MIMO pairing in
massive MIMO scenarios. In non-massive MIMO
scenarios: (1) If this option is selected, uplink MU
MIMO can be performed for UEs whose MCS index
is reduced to increase the number of available RBs.
(2) If this option is deselected, uplink MU MIMO
cannot be performed for UEs whose MCS index is
reduced to increase the number of available RBs. In
massive MIMO scenarios: (1) If the option is selected,
the eNodeB loosens up the beam determination
criteria for uplink MU MIMO pairing. (2) If this
option is deselected, the eNodeB does not loosen up
such criteria. This option applies only to LTE TDD.
VoLTEUeVmimoSwitch: Indicates whether VMIMO
pairing is performed for VoLTE UEs. If this option is

eRAN

nd
selected, VMIMO pairing is performed for VoLTE

UEs. If this option is deselected, VMIMO pairing is
not performed for VoLTE UEs. This option applies
only to LTE TDD.
TtiBundlingForVideoSwitch: Indicates whether to
enable TTI bundling for UEs running video services
in weak coverage areas. If this option is selected, TTI
bundling is enabled for UEs running video services in
weak coverage areas, improving video service
coverage at the cell edge. If this option is deselected,
TTI bundling is disabled for UEs running video
services in weak coverage areas. This option applies
only to LTE FDD.
GUI Value Range: SpsSchSwitch(SpsSchSwitch),
SinrAdjustSwitch(SinrAdjustSwitch),
PreAllocationSwitch(PreAllocationSwitch),
UlVmimoSwitch(UlVmimoSwitch),
TtiBundlingSwitch(TtiBundlingSwitch),
SmartPreAllocationSwitch(SmartPreAllocationS-
witch), PuschDtxSwitch(PuschDtxSwitch),
UlIblerAdjustSwitch(UlIblerAdjustSwitch),
UlEnhancedFssSwitch(UlEnhancedFssSwitch),
UlEnhancedSrSchSwitch(UlEnhancedSrSchSwitch),
SchedulerCtrlPowerSwitch(SchedulerCtrlPowerS-
witch), UlIicsAlgoSwitch(UlIicsAlgoSwitch),
UlMinGbrSwitch(UlMinGbrSwitch),
UlMbrCtrlSwitch(UlMbrCtrlSwitch),
MbrUlSchSwitch(MbrUlSchSwitch),
UeAmbrUlSchSwitch(UeAmbrUlSchSwitch),
UlEnhancedDopplerSwitch(UlEnhancedDopplerS-
witch), UlRaUserSchOptSw(UlRaUserSchOptSw),
UlLast2RetransSchOptSwitch(UlLast2RetransSchOpt
Switch), UlInterfFssSwitch(UlInterfFssSwitch),
UlSmallRBSpectralEffOptSw(UlSmallRBSpectralEf-
ficiencyOptSw), PuschUsePucchRbS-
witch(PuschUsePucchRbSwitch), PuschDtxSchOptS-
witch(PuschDtxSchOptSwitch),
ULFSSAlgoSwitch(ULFSSAlgoSwitch),
PrachRbReuseSwitch(PrachRbReuseSwitch),
SrSchDataAdptSw(SrSchDataAdptSw),
UlFssUserThdStSwitch(UlFssUserThdStSwitch),
HighOrderVMIMOSwitch(HighOrderVMIMOS-
witch), VMIMOReduceMCSRiseRBS-
witch(VMIMOReduceMCSRiseRBSwitch),
VoLTEUeVmimoSwitch(VoLTEUeVmimoSwitch),
TtiBundlingForVideoSwitch(TtiBundlingForVideoS-
witch)

eRAN

nd
Unit: None
Actual Value Range: SpsSchSwitch,
SinrAdjustSwitch, PreAllocationSwitch,
UlVmimoSwitch, TtiBundlingSwitch,
SmartPreAllocationSwitch, PuschDtxSwitch,
UlIblerAdjustSwitch, UlEnhancedFssSwitch,
UlEnhancedSrSchSwitch, SchedulerCtrlPowerSwitch,
UlIicsAlgoSwitch, UlMinGbrSwitch,
UlMbrCtrlSwitch, MbrUlSchSwitch,
UeAmbrUlSchSwitch, UlEnhancedDopplerSwitch,
UlRaUserSchOptSw, UlLast2RetransSchOptSwitch,
UlInterfFssSwitch, UlSmallRBSpectralEffOptSw,
PuschUsePucchRbSwitch, PuschDtxSchOptSwitch,
ULFSSAlgoSwitch, PrachRbReuseSwitch,
SrSchDataAdptSw, UlFssUserThdStSwitch,
HighOrderVMIMOSwitch, VMIMOReduceMCSRi-
seRBSwitch, VoLTEUeVmimoSwitch,
TtiBundlingForVideoSwitch
Default Value: SpsSchSwitch:Off,
SinrAdjustSwitch:On, PreAllocationSwitch:On,
UlVmimoSwitch:Off, TtiBundlingSwitch:Off,
SmartPreAllocationSwitch:On, PuschDtxSwitch:On,
UlIblerAdjustSwitch:Off, UlEnhancedFssSwitch:On,
UlEnhancedSrSchSwitch:On, SchedulerCtrlPowerS-
witch:Off, UlIicsAlgoSwitch:Off,
UlMinGbrSwitch:Off, UlMbrCtrlSwitch:Off,
MbrUlSchSwitch:Off, UeAmbrUlSchSwitch:Off,
UlEnhancedDopplerSwitch:On,
UlRaUserSchOptSw:Off,
UlLast2RetransSchOptSwitch:On,
UlInterfFssSwitch:Off, UlSmallRBSpectralEf-
fOptSw:Off, PuschUsePucchRbSwitch:Off,
PuschDtxSchOptSwitch:Off, ULFSSAlgoSwitch:On,
PrachRbReuseSwitch:Off, SrSchDataAdptSw:On,
UlFssUserThdStSwitch:Off, HighOrderVMIMOS-
witch:Off, VMIMOReduceMCSRiseRBSwitch:Off,
VoLTEUeVmimoSwitch:Off, TtiBundlingForVideoS-
witch:Off

eRAN

nd
CellAlg DlSchS MOD LOFD-1 Traffic Meaning:

oSwitch witch CELLA 10205/ Model Indicates whether to enable downlink scheduling
LGOSW TDLOF Based algorithms in a cell. This parameter includes the
ITCH D-11022 Perform following options:
LST 7 ance
CELLA LOFD-0 Optimiz FreqSelSwitch: Indicates whether to enable
LGOSW 01016/ ation frequency-selective scheduling. If this option is
ITCH TDLOF VoIP selected, data is transmitted on the frequency band of
D-00101 Semi- high channel quality. This option applies only to LTE
6 persisten FDD and LTE TDD.
LBFD-0 t
SpsSchSwitch: Indicates whether to enable semi-
0101502 Scheduli
persistent scheduling during talk spurts of VoLTE
/ ng
services. If this option is selected, semi-persistent
TDLBF Dynami scheduling is applied during talk spurts of VoLTE
D-00101 c services. If this option is deselected, dynamic
502 Scheduli scheduling is applied during talk spurts of VoLTE
ng services. This option applies only to LTE FDD and
LOFD-0
01109/ DL LTE TDD.
TDLOF Non-
MBSFNShutDownSwitch: Indicates whether to
D-00110 GBR
enable Multimedia Broadcast multicast service Single
9 Packet
Frequency Network (MBSFN) subframe shutdown. If
Bundlin
LOFD-0 this option is selected, MBSFN subframe shutdown is
g
01070/ applied. If this option is deselected, MBSFN subframe
TDLOF Symbol shutdown is not applied. This option takes effect only
D-00107 Power if the SymbolShutdownSwitch option of the
0 Saving PowerSaveSwitch parameter is selected. If the
TDLOF Scheduli MBSFNShutDownSwitch option is selected, the
D-07022 ng setting of the switch for mapping SIBs to SI messages
2/ Based becomes invalid. If the MBSFNShutDownSwitch
LOFD-1 on Max option is deselected, the setting of the switch for
31213 Bit Rate mapping SIBs to SI messages becomes valid. The
MBSFNShutDownSwitch option applies only to LTE-
LBFD-0 Basic
only base stations. This option applies only to LTE
02025/ Scheduli
FDD and LTE TDD.
TDLBF ng
D-00202 Aperiodi NonGbrBundlingSwitch: Indicates whether to enable
5 c CQI downlink non-GBR packet bundling. If this option is
LBFD-0 Reportin selected, delay of non-GBR services can be controlled
02031/ g in non-congestion scenarios. If this option is
TDLBF MBR>G deselected, delay of non-GBR services cannot be
D-00203 BR controlled. This option applies only to LTE FDD and
1 Configu LTE TDD.
LBFD-0 ration EnAperiodicCqiRptSwitch: Indicates whether to

70102/ Enhance enable enhanced aperiodic channel quality indicator
TDLBF d DL (CQI) reporting. If this option is selected, the eNodeB
D-07010 Frequen triggers aperiodic CQI reporting for a UE based on
2 cy downlink services of the UE and the interval at which

eRAN

nd
LBFD-0 Selectiv the UE sends periodic CQI reports. If this option is

60103 e deselected, UEs under non-frequency-selective
LOFD-0 Scheduli scheduling do not trigger aperiodic CQI reporting
81218 ng based on downlink services and trigger an aperiodic
Enhance CQI reporting if no valid periodic CQI reports are sent
LTROF in eight consecutive periodic CQI reporting periods.
D-11120 d
Extende This option applies only to LTE FDD and LTE TDD.
4/
TDLOF d QCI DlMbrCtrlSwitch: Indicates whether to enable
D-12110 MCPTT downlink scheduling based on the maximum bit rate
6 Voice (MBR) and guaranteed bit rate (GBR) on GBR
TDLBF Manage bearers. If this option is selected, the eNodeB
D-00200 ment performs downlink scheduling on GBR bearers based
5 DL on the MBR and GBR. If this option is deselected, the
Asynchr eNodeB performs downlink scheduling on GBR
LBFD-0 bearers based on the GBR only. This option applies
60101 onous
HARQ only to LTE FDD and LTE TDD.
LBFD-0
60103/ Optimiz MbrDlSchSwitch: Indicates whether the eNodeB
TDLBF ation of performs downlink scheduling based on MBR. If this
D-08010 CQI option is selected, the eNodeB prioritizes UEs based
2 Reportin on the MBRs during downlink scheduling. This
g parameter applies only to LTE FDD and LTE TDD.
LEOFD-
111305 Enhance UeAmbrDlSchSwitch: Indicates whether the eNodeB
d DL performs downlink scheduling based on per UE
LEOFD- Frequen aggregate maximum bit rates (UE-AMBRs). If this
111307 cy option is selected, the eNodeB prioritizes UEs based
TDLOF Selectiv on the UE-AMBRs during downlink scheduling. This
D-12110 e option applies only to LTE FDD and LTE TDD.
5 Scheduli
ng EpfEnhancedSwitch: Indicates whether to enable
enhanced proportional fair (EPF) enhancement for
Virtual
scheduling. EPF enhancement for scheduling is
4T4R
enabled only if this option is selected. This option
eMIMO applies only to LTE FDD and LTE TDD.
RRC AperiodicCqiTrigOptSwitch: Indicates whether to
and optimize triggering of aperiodic CQI reporting. If this
DRX option is selected, a UE performing initial access
Policy triggers aperiodic CQI reporting based on related
for trigger conditions after the DLMAC instance has been
Public established for 200 ms and the eNodeB receives
Safety MSG5. Consider that aperiodic CQI reporting is
triggered by invalid CQI reports in eight consecutive
CQI reporting periods. If cyclic redundancy check
(CRC) on aperiodic CQI reports fails, aperiodic CQI
reporting is not repeatedly triggered when DRX is
enabled; or aperiodic CQI reporting is triggered after
eight TTIs when DRX is disabled. If this option is
deselected, a UE performing initial access triggers

eRAN

nd
aperiodic CQI reporting based on related trigger

conditions after the DLMAC instance has been
established for 200 ms. Consider that aperiodic CQI
reporting is triggered by invalid CQI reports in eight
consecutive CQI reporting periods. If CRC on
aperiodic CQI reports fails, aperiodic CQI reporting is
triggered after eight TTIs, regardless of the DRX
status. This option applies only to LTE FDD and LTE
TDD.
VoipTbsBasedMcsSelSwitch: Indicates whether the
modulation and coding scheme (MCS) index is
selected based on the transport block size (TBS) in
downlink scheduling for VoLTE services. The MCS
index is selected based on the TBS in downlink
dynamic scheduling for VoLTE services only if this
option is selected. This option applies only to LTE
FDD and LTE TDD.
PagingInterfRandSwitch: Indicates whether to enable
interference randomization for paging messages. If
this option is selected, interference randomization is
enabled for paging messages. This option applies only
to LTE FDD and LTE TDD.
DlSingleUsrMcsOptSwitch: Indicates conditions for
lowering the MCS index for a single UE. If this option
is selected, the MCS index can be lowered for a UE if
the UE is the only UE to be scheduled in a
transmission time interval (TTI). If this option is
deselected, the MCS index can be lowered for a UE if
the threshold for the function of lowering the MCS
index to increase the number of RBs is reached and
the UE is the only UE to be scheduled in a TTI. This
option applies only to LTE FDD and LTE TDD.
UeSigMcsEnhanceSwitch: Indicates whether to
enable MCS optimization for UE signaling. If this
option is selected, MCS optimization for UE signaling
is enabled. For LTE FDD, the MCS index for UE
signaling is the same as the MCS index for data. For
LTE TDD, the MCS index for UE signaling is lowered
based on the MCS index for data. If this option is
deselected, a fixed low MCS index is used for UE
signaling. This option applies only to LTE FDD and
LTE TDD.
SubframeSchDiffSwitch: For TDD cells, this option
indicates whether to perform scheduling in subframes
3 and 8 based on the policy of increasing the number
of UEs scheduled in the uplink when uplink-downlink

eRAN

nd
configuration 2 is used. If this option is selected,

scheduling in subframes 3 and 8 is performed based
on the policy of increasing the number of UEs
scheduled in the uplink when uplink-downlink
configuration 2 is used. If this option is deselected, the
scheduling policy used in subframes 3 and 8 is the
same as that used in other downlink subframes when
uplink-downlink configuration 2 is used. For NB-IoT
cells, this option indicates whether to enable
scheduling priority optimization. If this option is
deselected, the scheduling priority of downlink
services is higher than that of uplink services for UEs
for which control plane CIoT EPS optimization is
used. If this option is selected, the scheduling priority
of downlink services is the same as that of uplink
services for UEs for which control plane CIoT EPS
optimization is used. This option applies only to LTE
TDD and NB-IoT.
TailPackagePriSchSwitch: Indicates whether to enable
scheduling of downlink connected tail packages in the
bearer. If this option is selected, the connected tail
package is scheduled preferentially in the next TTI,
which reduces the delay and increases the
transmission rate. If this option is deselected, the
scheduling policy of the connected tail package is the
same as other downlink subframes. This option
applies only to LTE TDD.
SIB1InterfRandSwitch: Indicates whether to enable
SIB1 interference randomization. If this option is
selected, interference randomization is enabled for
SIB1. This option applies only to LTE TDD.
FreqSelJudgeIgnorDopplerSwitch: Indicates whether
to ignore Doppler conditions. If this option is selected,
Doppler conditions are ignored during frequency
selective channel determination. If this option is
deselected, Doppler conditions are considered during
frequency selective channel determination. This
EnhExtQCISpsSchSwitch: Indicates whether to
enable semi-persistent scheduling during talk spurts of
PTT services with standardized QCI 65, standardized
QCI 66, or an enhanced extended QCI. If this option
is selected, semi-persistent scheduling is applied. If
this option is deselected, dynamic scheduling is
applied. This option applies only to LTE FDD and
LTE TDD.

eRAN

nd
DlVoipBundlingSwitch: Indicates whether to enable

active packet bundling for downlink VoLTE services.
Active packet bundling is enabled for downlink
VoLTE services only if this option is selected. If this
option is selected, PDCCH resources can be saved for
downlink data services or uplink services, thereby
increasing the VoLTE capacity for VoLTE services or
increasing the throughput of data services in mixed
service scenarios. However, the delay in VoLTE voice
packet scheduling will increase in the downlink and
MOSs may decrease. You are advised to deselect this
option if you prefer VoLTE performance and do not
expect MOS reduction. This option applies only to
LTE FDD and LTE TDD.
DlPacketLenAwareSchSw: Indicates whether to
enable packet length awareness performance
optimization in the downlink. Packet length awareness
performance optimization is enabled in the downlink
only if this option is selected. This option applies only
to LTE FDD and LTE TDD.
RLCArqFeedbackEnhancedSwitch: Indicates whether
to modify HARQ feedback results based on RLC
status reports when uplink-downlink configuration 2
is used. If this option is selected, the eNodeB modifies
HARQ feedback results based on RLC status reports
after receiving the reports. This prevents unnecessary
HARQ retransmissions. This option applies only to
LTE TDD.
PaReconfigOptSwitch: Indicates whether to enable PA
reconfiguration optimization. The optimization is
enabled when this option is selected. This option
RankRapidRptSwitch: Indicates whether to enable fast
rank reporting. If this option is selected, an aperiodic
CQI reporting is immediately triggered after
successful network access. If this option is deselected,
an aperiodic CQI reporting is not immediately
triggered after successful network access. This option
DlRLCStateReportSchDelaySw: Indicates whether to
enable optimization on the delay-based scheduling of
downlink RLC status reports. The optimization is
enabled when this option is selected. This option
SmallPktMcsSelectAlgoSw: Indicates whether to
enable MCS selection for small packets. If this option

eRAN

nd
is selected, the scheduler selects an MCS with a lower

index based on the amount of data to be initially
transmitted and the allocated TBS in each TTI on
condition that the allocated TB can carry the data. The
function is enabled only if this option is selected. This
SRB0SplitSchSw: Indicates whether to enable

separate scheduling of SRB0 and contention
resolution MCE. If this option is selected, SRB0 and
contention resolution MCE are separately scheduled.
BfUserPairPriorSwitch: Indicates whether to

preferentially allocate resources to paired
beamforming UEs for UE pairing features such as MU
beamforming and D-MIMO. If this option is selected,
the eNodeB preferentially allocates resources to
paired beamforming UEs for UE pairing features such
as MU beamforming and D-MIMO. This option
applies only to LTE TDD.
HarqAllocOptSwitch: Indicates whether to optimize

the allocation of HARQ processes. If this option is
selected, the downlink UE rate increases. This option
takes effect only when D-MIMO or massive MIMO is
enabled. This option applies only to LTE TDD.
Pusch32Switch: Indicates whether to enable the

PUSCH 3-2 feedback mode. If this option is selected,
UEs that support the PUSCH 3-2 feedback mode use
this mode to aperiodically report CQIs. If this option
is deselected, the mode cannot be used. This option
applies only to LTE FDD.
DlPreciseAmbrCtrlSwitch: Indicates whether to

enable precise downlink AMBR control. If this option
is selected, a more accurate optimization algorithm
applies to the AMBR control, which achieves more
accurate AMBR control. If this option is deselected,
the original AMBR control algorithm is used. This
GUI Value Range: FreqSelSwitch(FreqSelSwitch),
SpsSchSwitch(SpsSchSwitch),
MBSFNShutDownSwitch(MBSFNShutDownSwitch),
NonGbrBundlingSwitch(NonGbrBundlingSwitch),
EnAperiodicCqiRptSwitch(EnAperiodicCqiRptS-
witch), DlMbrCtrlSwitch(DlMbrCtrlSwitch),
MbrDlSchSwitch(MbrDlSchSwitch),
UeAmbrDlSchSwitch(UeAmbrDlSchSwitch),

eRAN

nd
EpfEnhancedSwitch(EpfEnhancedSwitch),
AperiodicCqiTrigOptSwitch(AperiodicCqiTrigOptS-
witch), VoipTbsBasedMcsSelS-
witch(VoipTbsBasedMcsSelSwitch),
PagingInterfRandSwitch(PagingInterfRandSwitch),
DlSingleUsrMcsOptSwitch(DlSingleUsrMcsOptS-
witch), SubframeSchDiffSwitch(SubframeSchDiffS-
witch), TailPackagePriSchS-
witch(TailPackagePriSchSwitch),
UeSigMcsEnhanceSwitch(UeSigMcsEnhanceSwitch),
FreqSelJudgeIgnorDopplerSwitch(FreqSelJudgeIgnor-
DopplerSwitch),
SIB1InterfRandSwitch(SIB1InterfRandSwitch),
EnhExtQCISpsSchSwitch(EnhExtQCISpsSchSwitch),
DlVoipBundlingSwitch(DlVoipBundlingSwitch),
DlPacketLenAwareSchSw(DlPacketLenAwar-
eSchSw), RLCArqFeedbackEnhanced-
Switch(RLCArqFeedbackEnhancedSwitch),
PaReconfigOptSwitch(PaReconfigOptSwitch),
RankRapidRptSwitch(RankRapidRptSwitch),
DlRLCStateReportSchDe-
laySw(DlRLCStateReportSchDelaySw),
SmallPktMcsSelectAlgoSw(SmallPktMcsSelectAl-
goSw), SRB0SplitSchSw(SRB0SplitSchSw),
BfUserPairPriorSwitch(BfUserPairPriorSwitch),
HarqAllocOptSwitch(HarqAllocOptSwitch),
Pusch32Switch(Pusch32Switch),
DlPreciseAmbrCtrlSwitch(DlPreciseAmbrCtrlSwitch)
Unit: None
Actual Value Range: FreqSelSwitch, SpsSchSwitch,
MBSFNShutDownSwitch, NonGbrBundlingSwitch,
EnAperiodicCqiRptSwitch, DlMbrCtrlSwitch,
MbrDlSchSwitch, UeAmbrDlSchSwitch,
EpfEnhancedSwitch, AperiodicCqiTrigOptSwitch,
VoipTbsBasedMcsSelSwitch, PagingInterfRand-
Switch, DlSingleUsrMcsOptSwitch,
SubframeSchDiffSwitch, TailPackagePriSchSwitch,
UeSigMcsEnhanceSwitch, FreqSelJudgeIgnorDop-
plerSwitch, SIB1InterfRandSwitch,
EnhExtQCISpsSchSwitch, DlVoipBundlingSwitch,
DlPacketLenAwareSchSw, RLCArqFeedbackEnhan-
cedSwitch, PaReconfigOptSwitch,
RankRapidRptSwitch, DlRLCStateReportSchDe-
laySw, SmallPktMcsSelectAlgoSw, SRB0SplitSchSw,
BfUserPairPriorSwitch, HarqAllocOptSwitch,
Pusch32Switch, DlPreciseAmbrCtrlSwitch
Default Value: FreqSelSwitch:Off, SpsSchSwitch:Off,
MBSFNShutDownSwitch:Off, NonGbrBundlingS-

eRAN

nd
witch:Off, EnAperiodicCqiRptSwitch:Off,
DlMbrCtrlSwitch:Off, MbrDlSchSwitch:Off,
UeAmbrDlSchSwitch:Off, EpfEnhancedSwitch:Off,
AperiodicCqiTrigOptSwitch:On, VoipTbsBasedMcs-
SelSwitch:On, PagingInterfRandSwitch:Off,
DlSingleUsrMcsOptSwitch:Off, SubframeSchDiffS-
witch:Off, TailPackagePriSchSwitch:Off,
UeSigMcsEnhanceSwitch:Off, FreqSelJudgeIgnor-
DopplerSwitch:Off, SIB1InterfRandSwitch:On,
EnhExtQCISpsSchSwitch:Off, DlVoipBundlingS-
witch:Off, DlPacketLenAwareSchSw:Off,
RLCArqFeedbackEnhancedSwitch:Off,
PaReconfigOptSwitch:Off, RankRapidRptSwitch:Off,
DlRLCStateReportSchDelaySw:Off,
SmallPktMcsSelectAlgoSw:Off,
SRB0SplitSchSw:Off, BfUserPairPriorSwitch:Off,
HarqAllocOptSwitch:Off, Pusch32Switch:Off,
DlPreciseAmbrCtrlSwitch:Off

eRAN

nd
CellUlsc UlEnhen MOD LBFD-0 Dynami Meaning:

hAlgo cedVoip CELLU 0101502 c Indicates whether to enable enhanced uplink
SchSw LSCHA / Scheduli scheduling for VoLTE services.
LGO TDLBF ng
LST D-00101 UlVoipPreAllocationSwitch: Indicates whether to
VoIP
CELLU 502 perform preallocation for VoLTE UEs during talk
Semi-
LSCHA LOFD-0 spurts when the number of RRC_CONNECTED UEs
persisten
LGO 01016/ exceeds 50 in a cell. Voice preallocation is performed
t
TDLOF only if this option is selected. This option applies only
Scheduli
D-00101 to LTE FDD.
ng
6 UlVoipDelaySchSwitch: Indicates whether to perform
TTI
LOFD-0 Bundlin delay-based scheduling on VoLTE UEs when there are
01048/ g a large number of VoLTE UEs and these UEs are
TDLOF evenly distributed. If this option is deselected, delay-
Voice based scheduling is not performed on VoLTE UEs. If
D-00104
Characte this option is selected, the scheduling priorities are
8
ristic calculated based on delays. This option applies only to
LOFD-0 Awarene
81229/ LTE TDD.
ss
TDLOF Scheduli UlVoIPLoadBasedSchSwitch: Indicates whether to
D-08122 ng enable adaptive selection of scheduling modes for
9 VoLTE UEs based on the cell load. Two scheduling
Active
TDLBF Scheduli modes are provided: dynamic scheduling and semi-
D-11110 ng of persistent scheduling. If this option is deselected,
1 Cell- adaptive selection of dynamic and semi-persistent
LBFD-0 Edge scheduling cannot be performed for VoLTE UEs based
81104/ Voice on the cell load. If this option is selected, dynamic and
TDLBF Users semi-persistent scheduling can be adaptively selected
D-08110 for VoLTE UEs based on the cell load.
UL
5 Compen UlVoipSchOptSwitch: Indicates whether to enable
LOFD-1 sation scheduling optimization for VoLTE UEs in the uplink.
20204/ Scheduli If this option is deselected, this function is disabled. If
TDLOF ng this option is selected, an uplink dynamic scheduling
D-12020 is triggered for VoLTE UEs adopting uplink dynamic
VoLTE
3 scheduling when the scheduling interval is greater
Coverag
LBFD-0 than the uplink scheduling interval threshold for
e
02025/ VoLTE UEs. This ensures timely uplink scheduling on
Enhance
TDLBF VoLTE UEs even when SR missing detections occur,
ment
D-00202 thereby avoiding packet loss caused by the expiration
Basic of the PDCP packet discarding timer.
5
Scheduli
TDLOF ng UlVoLTEDataSizeEstSwitch: Indicates whether to
D-11120 enable the estimation of traffic volume dynamically
8 Uplink scheduled for VoLTE services in the uplink. If this
Interfere option is deselected, this function is disabled. If this
nce option is selected, the eNodeB estimates the uplink
Coordin traffic volume that is dynamically scheduled for
ation VoLTE services, which shortens the VoLTE packet

eRAN

nd
delay, reduces the packet loss rate, and improves the

voice service quality.
UlVoipServStateEnhancedSw: Indicates whether to
enable enhanced determination of VoLTE service
states (either in talk spurts or silent period) in the
uplink. If this option is deselected, enhanced
determination is disabled. If this option is selected,
enhanced determination is enabled. Selecting this
option shortens the determination delay on voice
service states in the uplink, decreases the probability
of the voice service state being falsely determined as
in the silent period, decreases the voice packet loss
rate caused by SR missing detections when the
UlVoipSchOptSwitch option is selected, and improves
the voice quality, especially the voice quality during
initial accesses and handovers.
UlVoipRblerControlSwitch: Indicates whether to
enable retransmission optimization on uplink VoLTE
services. If this option is deselected, retransmission
optimization is disabled. If this option is selected,
retransmission optimization is applied, and an MCS
with a lower index is selected to decrease the voice
packet loss rate caused by uplink HARQ
retransmission failures when UEs running VoLTE
services perform uplink adaptive retransmissions.
UlEdgeActiveSchSwitch: Indicates whether to enable
active dynamic scheduling on VoLTE UEs located on
cell edges. If this option is deselected, this function is
disabled. If this option is selected, the eNodeB
estimates the volume of traffic to be dynamically
scheduled for VoLTE services in the uplink, and
actively schedules VoLTE UEs if fragmentation is
required due to limited uplink power according to the
estimation results. By doing so, the eNodeB reduces
the packet delay and timeout-caused packet loss rate
for VoLTE services, and improves voice service
quality. This option applies only to LTE TDD.
UlMcsRestraintAfterSpsRelSw: Indicates whether
MCS restriction takes effect on uplink dynamic
scheduling after uplink semi-persistent scheduling
release. If this option is deselected, this function is
disabled. If this option and the SpsSchSwitch option
of the UlSchSwitch parameter are selected, this
function is enabled, and the MCS for uplink dynamic
scheduling is restricted after uplink semi-persistent
scheduling release. In this way, the reliability of

eRAN

nd
uplink dynamic scheduling transmission after uplink

semi-persistent scheduling release can be guaranteed,
and voice quality improves.
SpsAndDrxOptSwitch: Indicates whether to enable
optimization of cooperation between semi-persistent
scheduling and DRX. If this option is deselected,
power control commands for semi-persistent
scheduling can be delivered during the DRX sleep
time. If this option is selected, power control
commands for semi-persistent scheduling can be
delivered only during the DRX On Duration period,
but not during the DRX sleep time.
UlCallMuteRecoverSwitch: Indicates whether to
enable voice mute recovery in the uplink. If this
option is selected, the eNodeB performs voice activity
detection (VAD) on UEs running voice services and
performs intra-cell handovers or releases the RRC
connections for UEs on which speech absence is
detected to recreate the radio bearers.
UlVoipCrosslayerOptSwitch: Indicates whether to
enable cross-layer optimization for VoLTE services in
the uplink. If this option is deselected, the
optimization is disabled. If this option is selected, the
eNodeB estimates the amount of data to be
dynamically scheduled in the uplink for voice services
after optimizing the PDCP SDU discarding timer,
eNodeB UM receiver-end reordering timer, and
maximum number of MAC-layer transmissions for
uplink services of QCI 1. Based on the estimation, the
eNodeB selects an optimum MCS and an optimum
RB number to decrease the uplink VoLTE packet loss
rate and improve voice service quality.
UlVoLTEContinuousSchSw: Indicates whether to
enable continuous scheduling for uplink VoLTE
services. The continuous scheduling function is
enabled only if this option is selected. When this
function is enabled, the eNodeB continuously
schedules VoLTE UEs during uplink talk spurts to
reduce uplink scheduling delay, packet delay and
packet jitter for VoLTE UEs and improve voice
service quality.
UlMixVoLTEOptSwitch: Indicates whether to enable
uplink voice and data service optimization. If this
option is deselected, the optimization is disabled. If
this option is selected, the eNodeB allocates
bandwidth suitable for scheduling voice packets for

eRAN

nd
VoLTE UEs performing both data and voice services.

This ensures preferential scheduling of voice services
and decreases the packet loss rate of QCI 1 services in
heavily loaded voice service scenarios. This option
VoLTEPwrOptSwitch: Indicates whether to enable
VoLTE power control optimization. If this option is
selected, the power of cell edge VoLTE UEs is
adjusted quickly. It is recommended that this option be
selected only in high-speed railway scenarios.
UlVoLTEDelaySchEnhancedSw: Indicates whether to
enhance delay-based dynamic scheduling
prioritization for VoLTE services in the uplink. If this
option is deselected, the eNodeB does not enhance
delay-based dynamic scheduling prioritization for
VoLTE services in the uplink. If this option is selected
and the UlDelaySchStrategy parameter in the
CellUlschAlgo MO is set to
VOIP_AND_DATA_DELAYSCH(VoIP and Data
Delay Scheduling), the eNodeB enhances delay-based
dynamic scheduling prioritization for VoLTE services
in the uplink. This option applies only to LTE TDD.
AmrVoiceFrameSmartCoverySw: Indicates whether to
enable smart recovery of AMR voice frames. If this
option is selected, the eNodeB recovers certain voice
frames with transmission errors based on the
importance of voice frames at the RLC layer. This
EnhancedUlVoipAmcSw: Indicates whether to enable
the enhanced uplink voice-specific AMC function. If
this option is selected, this function takes effect. For
UEs running voice services in LTE FDD cells, the
eNodeB selects an initial SINR adjustment value
based on the cell-specific adjustment value and
increases uplink power based on the RBLER. For UEs
running voice services in LTE TDD cells, the eNodeB
increases uplink power based on the RBLER. If this
option is deselected, this function does not take effect.
GUI Value Range: UlVoipPreAllocationS-
witch(UlVoipPreAllocationSwitch),
UlVoipDelaySchSwitch(UlVoipDelaySchSwitch),
UlVoIPLoadBasedSchS-
witch(UlVoIPLoadBasedSchSwitch),
UlVoipSchOptSwitch(UlVoipSchOptSwitch),
UlVoLTEDataSizeEstSwitch(UlVoLTEDataSizeEstS-

eRAN

nd
witch), UlVoipServStateEnhan-
cedSw(UlVoipServStateEnhancedSw),
UlVoipRblerControlSwitch(UlVoipRblerControlS-
witch), UlEdgeActiveSchSwitch(UlEdgeActiveSchS-
witch), UlMcsRestraintAfterSps-
RelSw(UlMcsRestraintAfterSpsRelSw),
SpsAndDrxOptSwitch(SpsAndDrxOptSwitch),
UlCallMuteRecoverSwitch(UlCallMuteRecoverS-
witch), UlVoipCrosslayerOptS-
witch(UlVoipCrosslayerOptSwitch),
UlVoLTEContinuousSchSw(UlVoLTEContinuousSch
Sw),
UlMixVoLTEOptSwitch(UlMixVoLTEOptSwitch),
VoLTEPwrOptSwitch(VoLTEPwrOptSwitch),
UlVoLTEDelaySchEnhan-
cedSw(UlVoLTEDelaySchEnhancedSw),
AmrVoiceFrameSmartCover-
ySw(AmrVoiceFrameSmartCoverySw),
EnhancedUlVoipAmcSw(EnhancedUlVoipAmcSw)
Unit: None
Actual Value Range: UlVoipPreAllocationSwitch,
UlVoipDelaySchSwitch, UlVoIPLoadBasedSchS-
witch, UlVoipSchOptSwitch, UlVoLTEDataSizeEstS-
witch, UlVoipServStateEnhancedSw,
UlVoipRblerControlSwitch, UlEdgeActiveSchSwitch,
UlMcsRestraintAfterSpsRelSw,
SpsAndDrxOptSwitch, UlCallMuteRecoverSwitch,
UlVoipCrosslayerOptSwitch,
UlVoLTEContinuousSchSw, UlMixVoLTEOptSwitch,
VoLTEPwrOptSwitch, UlVoLTEDelaySchEnhan-
cedSw, AmrVoiceFrameSmartCoverySw,
EnhancedUlVoipAmcSw
Default Value: UlVoipPreAllocationSwitch:Off,
UlVoipDelaySchSwitch:Off, UlVoIPLoadBasedSchS-
witch:Off, UlVoipSchOptSwitch:On,
UlVoLTEDataSizeEstSwitch:Off, UlVoipServStateEn-
hancedSw:On, UlVoipRblerControlSwitch:On,
UlEdgeActiveSchSwitch:Off, UlMcsRestraintAf-
terSpsRelSw:Off, SpsAndDrxOptSwitch:On,
UlCallMuteRecoverSwitch:Off, UlVoipCrosslayer-
OptSwitch:Off, UlVoLTEContinuousSchSw:Off,
UlMixVoLTEOptSwitch:Off,
VoLTEPwrOptSwitch:Off, UlVoLTEDelaySchEnhan-
cedSw:Off, AmrVoiceFrameSmartCoverySw:Off,
EnhancedUlVoipAmcSw:Off

eRAN

nd
CellAlg UdcAlg MOD TDLOF Uplink Meaning:

oSwitch oSwitch CELLA D-11022 Data Indicates whether to enable the uplink data
LGOSW 5 Compre compression algorithm in a cell.
ITCH LOFD-1 ssion
LST 21203/ Specifie BasicUdcSwitch: Indicates whether to enable the
CELLA TDLOF d User basic uplink data compression algorithm in a cell.
LGOSW D-12120 Coordin Basic uplink data compression algorithm is enabled
ITCH 5 ated only if this option is selected. This option applies only
Scheduli to LTE FDD and LTE TDD.
ng UlHCodeSwitch: Indicates whether to enable the
uplink HCode data compression algorithm in a cell.
The uplink HCode data compression algorithm is
enabled only if this option is selected. This option
GUI Value Range: BasicUdcSwitch(BasicUdcSwitch),
UlHCodeSwitch(UlHCodeSwitch)
Unit: None
Actual Value Range: BasicUdcSwitch,
UlHCodeSwitch
Default Value: BasicUdcSwitch:Off,
UlHCodeSwitch:Off

eRAN
ROHC Feature Parameter Description 6 Counters
6 Counters
Table 6-1 Counters

Counter ID Counter Name Counter Feature ID Feature Name
Description
1526727349 L.PDCP.DL.RoHC. Compression rate of Multi-mode: None RObust Header

HdrCompRatio headers of all GSM: None Compression
downlink PDCP (ROHC)
SDUs after the UMTS: None
RObust Header
ROHC LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017
NR: None
1526727350 L.PDCP.DL.RoHC. Compression rate of Multi-mode: None RObust Header

PktCompRatio all downlink PDCP GSM: None Compression
SDUs (including (ROHC)
headers and UMTS: None
RObust Header
payloads) after the LTE: Compression
ROHC LOFD-001017 (ROHC)
TDLOFD-001017
NR: None
1526727351 L.PDCP.UL.RoHC. Decompression Multi-mode: None RObust Header

FailDecompRatio failure rate of all GSM: None Compression
uplink PDCP SDUs (ROHC)
after the ROHC UMTS: None
RObust Header
LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017
NR: None

eRAN

Description
1526728522 L.PDCP.UL.RoHC. Compression rate of Multi-mode: None RObust Header

HdrCompRatio headers of all GSM: None Compression
uplink PDCP SDUs (ROHC)
after the ROHC UMTS: None
RObust Header
LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017
NR: None
1526728523 L.PDCP.UL.RoHC. Compression rate of Multi-mode: None RObust Header

PktCompRatio all uplink PDCP GSM: None Compression
SDUs (including (ROHC)
headers and UMTS: None
RObust Header
payloads) after the LTE: Compression
ROHC LOFD-001017 (ROHC)
TDLOFD-001017
NR: None
1526728524 L.Traffic.User.RoH Maximum number Multi-mode: None RObust Header

C.Max of UEs on which GSM: None Compression
ROHC takes effect (ROHC)
in a cell UMTS: None
RObust Header
LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017 Turbo Start Video
LAOFD-131204 Turbo Start Video
TDLOFD-131205
NR: None
1526728525 L.Traffic.User.RoH Average number of Multi-mode: None RObust Header

C.Avg UEs on which GSM: None Compression
ROHC takes effect (ROHC)
in a cell UMTS: None
RObust Header
LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017 Turbo Start Video
LAOFD-131204 Turbo Start Video
TDLOFD-131205
NR: None

eRAN

Description
1526745690 L.PDCP.UL.RoHC. Number of uplink Multi-mode: None RObust Header

FailDecomp.VoLTE VoLTE packets that GSM: None Compression
fail to be (ROHC)
decompressed by UMTS: None
RObust Header
ROHC in a cell LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017
NR: None
1526746015 L.PDCP.UL.RoHC. Number of uplink Multi-mode: None RObust Header

TotalDecomp.VoLT VoLTE packets that GSM: None Compression
E need to be (ROHC)
decompressed in UMTS: None
RObust Header
ROHC LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017
NR: None
1526746657 L.PDCP.DL.ROHC. Number of bytes of Multi-mode: None RObust Header

Voice.HdrComp.By downlink voice GSM: None Compression
tes service PDCP SDU (ROHC)
headers after UMTS: None
RObust Header
ROHC-based LTE: Compression
header compression LOFD-001017 (ROHC)
in a cell TDLOFD-001017
NR: None
1526746658 L.PDCP.UL.ROHC. Number of bytes of Multi-mode: None RObust Header

Voice.Hdr.Bytes uplink voice service GSM: None Compression
PDCP SDU headers (ROHC)
after ROHC-based UMTS: None
RObust Header
header LTE: Compression
decompression in a LOFD-001017 (ROHC)
cell TDLOFD-001017
NR: None
1526746662 L.PDCP.DL.ROHC. Number of bytes of Multi-mode: None RObust Header

Voice.Hdr.Bytes downlink voice GSM: None Compression
service PDCP SDU (ROHC)
headers before UMTS: None
RObust Header
ROHC-based LTE: Compression
header compression LOFD-001017 (ROHC)
in a cell TDLOFD-001017
NR: None

eRAN

Description
1526746663 L.PDCP.UL.ROHC. Number of bytes of Multi-mode: None RObust Header

Voice.HdrComp.By uplink voice service GSM: None Compression
tes PDCP SDU headers (ROHC)
before ROHC- UMTS: None
RObust Header
based header LTE: Compression
decompression in a LOFD-001017 (ROHC)
cell TDLOFD-001017
NR: None
1526747660 L.Traffic.User.RoH Average number of Multi-mode: None RObust Header

C.Voice.Avg UEs performing GSM: None Compression
voice services on (ROHC)
which ROHC takes UMTS: None
RObust Header
effect in a cell LTE: Compression
LOFD-001017 (ROHC)
TDLOFD-001017
NR: None
1526747894 L.Traffic.User.eMT Average number of Multi-mode: None eMTC Introduction

C.RoHC.Avg eMTC UEs with GSM: None eMTC Introduction
ROHC enabled
UMTS: None RObust Header
LTE: Compression
MLOFD-121280 (ROHC)
TDLEOFD-121611 RObust Header
Compression
LOFD-001017 (ROHC)
TDLOFD-001017
NR: None

eRAN
ROHC Feature Parameter Description 7 Glossary
7 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

eRAN
ROHC Feature Parameter Description 8 Reference Documents
8 Reference Documents
1. 3GPP TS 36.323, "Packet Data Convergence Protocol (PDCP) specification"

2. 3GPP TS 36.300, "Overall description"
3. 3GPP TS 36.331, "Radio Resource Control (RRC)"
4. 3GPP TS 36.413, "S1 Application Protocol (S1AP)"
5. IETF RFC 3095, "RObust Header Compression (ROHC)"
6. IETF RFC 4995, "The RObust Header Compression (ROHC) Framework"
7. IETF RFC 4815, "RObust Header Compression (ROHC): Corrections and Clarifications
to RFC 3095"
8. IETF RFC 3843, "RObust Header Compression(ROHC): A Compression Profile for IP"
9. VoLTE
10. Scheduling
11. Uplink Data Compression (TDD)
12. Video Experience Optimization

ROHC (eRAN13.1 04)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ROHC (eRAN13.1 04)

Uploaded by

Copyright:

Available Formats

eRAN

ROHC Feature Parameter

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. i

2 About This Document.................................................................................................................. 5

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. ii

4.1.3.2 Procedure for ROHC During a Handover.............................................................................................................. 20

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. iii

1.1 eRAN13.1 04 (2018-11-07)

1.2 eRAN13.1 03 (2018-08-27)

1.3 eRAN13.1 02 (2018-06-30)

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 1

1.4 eRAN13.1 01 (2018-04-10)

1.5 eRAN13.1 Draft A (2018-01-15) (FDD)

Added the ROHC-TCP Added the Profile0x0006 l 3900 and 5900

Added the enhanced ROHC Added the l BTS3203E

Optimized the ROHC exit None

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 2

Change Description Parameter Change Base Station Model

Added the Added the

1.6 eRAN13.1 Draft A (2017-12-30) (TDD)

Added the ROHC-TCP Added the Profile0x0006 l 3900 and 5900

Added the enhanced ROHC Added the

Optimized the ROHC exit None

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 3

Change Description Parameter Change Base Station Model

Added the Added the

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 4

2 About This Document

2.1 Applicable RAT

2.2 Features in This Document

Feature ID Feature Name Section

LOFD-001017 RObust Header 4 ROHC

This document describes the following TDD features.

Feature ID Feature Name Section

TDLOFD-001017 RObust Header 4 ROHC

2.3 Differences Between FDD and TDD

LOFD-001 RObust TDLOF RObust None 4 ROHC

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 5

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 6

Figure 4-1 ROHC header compression

4.1.1 Related Concepts

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 7

Table 4-1 Concepts related to ROHC

Context A context contains the information about compression and

Profile ROHC is an extensible framework consisting of different profiles for

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 8

eNodeBs. If the PdcpRohcPara.Profiles parameter is set to Profile0x0003 or Profile0x0004

Table 4-2 Mapping between profile IDs and protocols

0x0002 UDP and IP

0x0004 IP For details, see RFC 3843 and RFC 4815.

4.1.2 Principles and Framework of ROHC

4.1.2.1 ROHC Entities in E-UTRAN

Figure 4-2 Locations of the PDCP entities

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 9

Figure 4-3 ROHC in PDCP

4.1.2.2 Basic Framework

Issue 04 (2018-11-07) Copyright © Huawei Technologies Co., Ltd. 10

Figure 4-4 ROHC framework

4.1.2.2.1 Compression Mechanism

Figure 4-5 List structure