eRAN

ROHC Feature Parameter Description
Issue 01

Date 2016­03­07

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2016. 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: [email protected]

Contents
1 About This Document
1.1 Scope
1.2 Intended Audience
1.3 Change History
1.4 Differences Between eNodeB Types
2 Overview
2.1 Introduction
 2.2 Benefits
2.3 Related Concepts
3 Principles and Framework of ROHC
3.1 ROHC in E­UTRAN
3.2 Basic Framework
3.2.1 Compression Mechanism
3.2.2 Decompression Mechanism
3.3 ROHC States
3.3.1 Compressor States
3.3.2 Decompressor States
3.4 ROHC Operating Modes
3.4.1 Operating Mode Transition
3.4.2 U­Mode
3.4.3 O­Mode
3.4.4 R­Mode
3.5 Factors Affecting the ROHC Compression Efficiency
4 ROHC Procedure and Parameter Negotiation
4.1 Procedure for Starting ROHC upon Initial Access
4.2 Procedure for ROHC During a Handover
4.3 Procedure for ROHC upon RRC Connection Reestablishment
5 Related Features
6 Network Impact
7 Engineering Guidelines
7.1 When to Use ROHC
7.2 Deployment
7.2.1 Requirements
7.2.2 Data Preparation and Feature Activation
7.2.2.1 Data Preparation
7.2.2.2 Activation
7.2.3 Activation Observation
7.2.4 Deactivation
7.3 Performance Monitoring
7.4 Parameter Optimization
7.5 Troubleshooting
8 Parameters
9 Counters
10 Glossary
11 Reference Documents

1 About This Document

1.1 Scope
This document describes LOFD­001017 RObust Header Compression (ROHC), including its technical principles, related features, network impact, and engineering
guidelines.
This document applies to the following types of eNodeBs.

eNodeB Type Model

Macro 3900 series eNodeB

Micro BTS3202E
BTS3203E
BTS3911E

LampSite DBS3900 LampSite

Any managed objects (MOs), parameters, alarms, or counters described herein correspond to the software release delivered with this document. Any future updates will
be described in the product documentation delivered with future software releases.
This document applies only to LTE FDD. Any "LTE" in this document refers to LTE FDD, and "eNodeB" refers to LTE FDD eNodeB.

1.2 Intended Audience
This document is intended for personnel who:

Need to understand the features described herein
Work with Huawei products

1.3 Change History
This section provides information about the changes in different document versions. There are two types of changes:

Feature change
Changes in features and parameters of a specified version as well as the affected entities
Editorial change
Changes in wording or addition of information and any related parameters affected by editorial changes. Editorial change does not specify the affected
entities.

eRAN11.1 01 (2016­03­07)

This issue does not include any changes.

eRAN11.1 Draft A (2015­12­30)

Compared with Issue 04 (2015­09­30) of eRAN8.1, Draft A (2015­12­30) of eRAN11.1 includes the following changes.
Change Type Change Description Parameter Change Affected Entity

Feature change Added the CellAlgoSwitch.RohcSwitch cell­level Added the CellAlgoSwitch.RohcSwitch Macro, micro, and LampSite

parameter. For details, see 4.1 Procedure for Starting parameter. eNodeBs
ROHC upon Initial Access, 7.2.2.1 Data Preparation,
7.2.2.2 Activation, and 7.2.4 Deactivation.

Editorial change None None N/A

1.4 Differences Between eNodeB Types
Feature Support by Macro, Micro, and LampSite eNodeBs

Feature ID Feature Name Supported by Macro Supported by Micro Supported by LampSite

eNodeBs eNodeBs eNodeBs

LOFD­001017 RObust Header Compression (ROHC) Yes Yes Yes

Function Implementation in Macro, Micro, and LampSite eNodeBs

Function Difference

Intra­eNodeB neighboring Micro eNodeBs do not have intra­eNodeB neighboring cells. Descriptions of intra­eNodeB neighboring cells in this document apply
cells only to macro and LampSite eNodeBs, not to micro eNodeBs.

Profiles supported by Micro eNodeBs do not support profile 0x0003 or 0x0004. Descriptions of profiles 0x0003 and 0x0004 in this document apply only to
eNodeBs macro and LampSite eNodeBs, not to micro eNodeBs. For details, see 2.1 Introduction.
The GUI values of the PdcpRohcPara.Profiles parameter for micro eNodeBs do not include Profile0x0003(Profile0x0003) or
Profile0x0004(Profile0x0004).

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

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

Robustness
Due to its feedback mechanism, ROHC is robust on the radio links with a high BER and long RTT.
High compression efficiency
Some simple header compression algorithms, such as IPHC and Compressed Real­Time Transport Protocol (CRTP), can compress the header to 2 bytes,
while ROHC can achieve compression to as small as 1 byte. Therefore, ROHC has higher compression efficiency.

As shown in Figure 2­1, the header is compressed from 40 bytes to 1 byte. A smaller payload increases gains from the ROHC header compression.
Figure 2­1 ROHC header compression

In radio systems, the resources on the Uu interface are far more limited than the processing capability of processors. ROHC is suitable for radio systems, even though
it is more complex than other header compression schemes. It is mainly used for voice over IP (VoIP) services.

2.3 Related Concepts
Table 2­1 explains the concepts related to ROHC.
Table 2­1 Concepts related to ROHC

Concept Explanation

Compressor It is at the transmit (TX) end, and is responsible for compressing the header of a data packet 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 bearer (DRB) A DRB is a radio bearer that carries data on the user plane. Multiple DRBs can be established between a UE and the E­
UTRAN. One 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).
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, while dynamic fields change based on certain rules, such as the serial number.
Static fields are sent only when the compressor is in the Initialization and Refresh (IR) state, but dynamic fields are updated
in real time. For details, see A.1 "General classification" in IETF RFC 3095.
The number of concurrently active 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 need to negotiate the maximum number of contexts. The number of contexts for each bearer
that Huawei eNodeB supports meets the requirement for compressing a VoLTE service.

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 2­2 maps profile IDs to their corresponding protocols.
Table 2­2 Mapping between profile IDs and protocols

Profile ID Protocol Remarks

0x0001 RTP, User Datagram Protocol For details, see RFC 3095 and RFC 4815.
(UDP), and IP

0x0002 UDP and IP For details, see RFC3095 and RFC4815.

0x0003 Encapsulating Security Payload For details, see RFC 3095 and RFC 4815.

(ESP) and IP

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

NOTE:
ROHC can be used for Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) headers.

3 Principles and Framework of ROHC

3.1 ROHC in E­UTRAN
The ROHC entities are located in the user­plane PDCP entities in the UE and eNodeBs. Figure 3­1 shows the locations of the PDCP entities in the protocol stacks of
the UE and eNodeB.
Figure 3­1 Locations of the PDCP entities

As shown in Figure 3­2, ROHC entities are used only for header compression and decompression for data packets on the user plane. At ROHC startup, DRBs
between the UE and eNodeB have already been set up, and ROHC is performed on each DRB separately.
Figure 3­2 ROHC entities in PDCP entities

 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, it is the opposite. The
compressor is located within the UE, and the decompressor is located within the eNodeB.

3.2 Basic Framework
The ROHC framework defines the mechanism for header compression and decompression. Figure 3­3 shows the ROHC framework.
The compressor sends the header­compressed data packets and the information about the compression. The compressor and decompressor maintain the context at
the TX and RX ends respectively to ensure the context synchronization. The decompressor restores the data packets based on the context.
Figure 3­3 ROHC framework

3.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:
An IR packet, containing the profile and context, is sent only when the context is not established or needs to be updated.
To prevent errors from propagating, the compressor can add cyclic redundancy check (CRC) fields to compressed packets for the
decompressor to detect errors.
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) list. ROHC list compression applies
to ordered lists, which are constant between packets. Figure 3­4 presents the list structure.
Figure 3­4 List structure

The basic principle for list compression is as follows:

When a list remains unchanged for packets, compressed headers do not include the list information.
Small changes in the list are represented in compressed headers as additions (Insertion scheme), or deletions (Removal scheme), or both (Remove Then
Insert scheme).
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 for RTP CSRC lists.

3.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.

3.3 ROHC States

3.3.1 Compressor States
The ROHC compressor may operate in any of the following states:

Initialization and Refresh (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 invalid static part on the decompressor side. In this state, only IR packets (including uncompressed data packets and the
compression context) are sent.

First Order (FO) state
When the compressor detects any changes in the dynamic fields of the context, the compressor enters this state and sends the compressed packets.

Second Order (SO) state
This is the optimistic compression state, in which the compressor sends the data packets with the maximum compression efficiency. The compressor
operates in this state in most cases.

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:

Variations in the static part or dynamic part of packet headers
Feedback from the decompressor (ACK or NACK)
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 3.4 ROHC
Operating Modes.

3.3.2 Decompressor States
The ROHC decompressor operates in any of the following states:

No Context
If the context is not established yet or is unusable on the decompressor side, the decompressor operates in the No Context state.

Static Context
The decompressor enters this state when detecting that the dynamic fields in the context are invalid.

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 3­5.
Figure 3­5 State transition of the decompressor

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.
The decompressor switches to the Static Context state from the Full Context state when the dynamic fields in the context become invalid.
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.

3.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.

3.4.1 Operating Mode Transition
The initial operating mode of the compressor is U­Mode. After confirming packet reception by the decompressor and receiving the expected­mode indication from the
decompressor, the compressor switches to O­Mode or R­Mode. The operating mode transition is determined by the decompressor.

When the eNodeB is the compressor, the UE works as the decompressor and triggers operating mode transition for the eNodeB.
When the eNodeB is the decompressor, it determines the target operating mode based on the PdcpRohcPara.HighestMode parameter and instructs the
UE to change the operating mode.
If the PdcpRohcPara.HighestMode parameter is set to R_MODE(Bi­Directional Reliable Mode), the UE can switch to a higher mode (O­
Mode or R­Mode) and stay in R­Mode.
If the PdcpRohcPara.HighestMode parameter is set to O_MODE(Bi­directional Optimistic Mode), the UE can switch to and stay in O­Mode.

3.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 includes the context information in multiple transmitted data packets to ensure the context synchronization with the decompressor. In
addition, the compressor periodically switches to a lower state to ensure the context synchronization even if there are errors.
Figure 3­6 shows the state transition of the compressor in U­Mode.
Figure 3­6 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 is confident of the context reception by the decompressor after sending the data packets containing the context information multiple times.
If the compressor is confident that the decompressor has received some of the packets, the compressor in the IR state switches to the FO state. If the compressor is
confident that the decompressor has received much more 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, it 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.

3.4.3 O­Mode
In O­Mode, the decompressor can send feedback to indicate failed decompression or successful context update. O­Mode combines U­Mode and feedback information.
Therefore, it provides higher reliability than U­Mode, yet generates less feedback than in R­Mode. Figure 3­7 shows the state transition of the compressor in O­Mode.
STATIC_NACK means that there is no context or the static fields of the context are invalid. NACK means that dynamic fields of the context are invalid. ACK means
that the decompressor has successfully decompressed the compressed packets from the compressor. Update means that the decompressor is informed that the
packet headers are updated.
Figure 3­7 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 the compressor in the SO
state is aware of a need for an update in packet headers, it switches to the FO state.

3.4.4 R­Mode
In R­Mode, context synchronization between the compressor and decompressor is ensured only by the feedback. The compressor repeatedly sends the context
updating packets until an acknowledgment is received from the decompressor. R­Mode leads to greatest amount of acknowledgment data and largest link overhead,
but provides the highest reliability.
Figure 3­8 shows the state transition of the compressor in R­Mode.
Figure 3­8 State transition of the compressor in R­Mode

The compressor starts in the IR state. After the compressor receives an ACK message from the decompressor, the compressor switches to a higher state (FO or SO).
If a 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 aware of a need for an update
in packet headers, it switches to the FO state.
In the uplink, if ROHC uses the U­Mode, the eNodeB sends NACK(O) to the UE and switches over to the O­Mode when the number of consecutive CRC error packets
is greater than the threshold of automatic switchover to the O­Mode. This threshold is set to 6 by default. If ROHC uses the O­Mode or R­Mode, the eNodeB exits
ROHC when the number of consecutive CRC error packets is greater than the threshold of actively exiting ROHC. This threshold is set to 6 by default. When the
eNodeB exits ROHC, it will not enter ROHC again during this call.

3.5 Factors Affecting the ROHC Compression Efficiency
The factors affecting the ROHC compression efficiency can be classified into factors that can, and those that cannot, be controlled by the eNodeB.

Of the factors that cannot be controlled by the eNodeB, the most significant are those having to do with the service data. These factors are also the primary
elements impacting ROHC efficiency. They include:
Header format of the data packets on a DRB
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 size of each data packet on a DRB
Packets with smaller payloads have larger headers and higher 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 in only 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 on 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­Mode, the compressor does not need to periodically switch to a lower state, which helps increase the compression
efficiency.

The controllable factors include:
Operating mode of ROHC used on the uplink
This mode is determined by eNodeBs. In U­Mode, the compressor periodically switches to a lower state, which decreases the compression
efficiency. In O­Mode or R­Mode, the compressor does not need to periodically switch to a lower state, which helps increase the compression
efficiency.
Lower­layer transmission quality
In O­Mode or R­Mode, if a compressed packet cannot be successfully decompressed or a decompressed packet fails CRC, the decompressor
sends an NACK 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 verification failures and higher compression
efficiency.

4 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 the ROHC parameters.
After the parameter negotiation, the compressor or the decompressor performs header compression or decompression based on the negotiated ROHC parameters.
If an inter­eNodeB handover occurs, the ROHC parameters must be renegotiated. If an intra­eNodeB handover occurs, the ROHC parameters remain unchanged and
do not need to be renegotiated.

4.1 Procedure for Starting ROHC upon Initial Access
If both the compressor and the decompressor support ROHC, ROHC is started by default when a VoIP service bearer is set up but is not started for non­VoIP services
during initial access of a UE.
ROHC starts when the EPC initiates DRB setup for VoIP services. Figure 4­1 shows the procedure for starting ROHC.
Figure 4­1 Procedure for starting ROHC upon initial access

1. 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.
2. The eNodeB checks whether the PdcpRohcPara.RohcSwitch and CellAlgoSwitch.RohcSwitch parameters are set to ON(On). If the parameters are not
set to ON(On) or the service is not a VoIP service, the eNodeB does not start ROHC. If the parameters are set to ON(On) and the service is a VoIP
service, the eNodeB proceeds to the next step.

 NOTE:
If exceptions (such as voice quality deterioration and call failures) occur on certain UEs after ROHC is enabled, the network performance indicators may
deteriorate. To avoid this impact, enable LBFD­081103 Terminal Awareness Differentiation for the eNodeB. Then, you can deactivate ROHC for the specific
UEs. For details, see Terminal Awareness Differentiation Feature Parameter Description.
In the current version, the PdcpRohcPara.RohcSwitch and CellAlgoSwitch.RohcSwitch parameters jointly determine whether ROHC is enabled.
In later versions, the PdcpRohcPara.RohcSwitch parameter will be replaced by the CellAlgoSwitch.RohcSwitch parameter. The current version
supports configuration synchronization and delivery of eNodeB­level and cell­level parameters. If the eNodeB­level parameter is set to ON(On), whether the
function is provided in cells is determined by the eNodeB­level switch. If the eNodeB­level parameter is set to OFF(Off), whether the function is provided in
cells is determined by the cell­level switch. Therefore, you are advised to switch to the cell­level switch, then turn off the eNodeB­level switch, and avoid
using the eNodeB­level switch for ROHC afterwards.

3. The eNodeB checks whether it has the UE's ROHC capability information stored. If it does not, the eNodeB derives the information from the UE. If it does
have the information, the eNodeB continues the procedure.

 NOTE:
The ROHC capability of a UE is indicated by two parameters, which are the maximum number of concurrently active contexts supported by the UE
(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 Radio Resource Control (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's 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.

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 based on the following two profiles:
UE­supported profiles stored on the eNodeB
eNodeB­supported profiles specified by the PdcpRohcPara.Profiles parameter

 NOTE:
The compressor and decompressor that support any of the profiles listed in Table 2­2 also support profile 0x0000.

6. If the profiles intersection is null, the eNodeB does not start ROHC. If it is not null, 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 the DRBs are successfully set up, the UE and eNodeB begin to exchange data on the user plane. For both the uplink and downlink, the compressor
and decompressor operate within the ROHC framework.

4.2 Procedure for ROHC During a Handover
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­2 shows the procedure for
ROHC during a handover.
Figure 4­2 Procedure for ROHC during a handover

1. The UE sends a measurement report in the source cell.
2. 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.
3. After deciding to admit the handed­over UE, the target eNodeB calculates the ROHC parameters, which specify the maximum number of concurrently
active contexts and the profiles supported by both the UE and the target eNodeB. Then, the target eNodeB sends a Handover Request Acknowledge
message carrying the new ROHC parameters to the source eNodeB.

 NOTE:
The procedure for ROHC parameter calculation by the target eNodeB is the same as that by the source eNodeB. For details, see 4.1 Procedure for
Starting ROHC upon Initial Access.

4. 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.
5. The UE attempts to access the target cell.
6. 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.3 Procedure for ROHC upon RRC Connection Reestablishment
The ROHC procedure differs between target cells for RRC connection reestablishment.

If an RRC connection is reestablished with an intra­eNodeB cell, the original context for ROHC is retained.
If an RRC connection is reestablished with a cell served by another Huawei­deployed 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 new ROHC parameters differ from the original
parameters, the target eNodeB informs the UE of the new parameters.

 NOTE:
If an RRC connection is reestablished with a cell served by another eNodeB deployed by a different vendor, the reestablishment will fail.

5 Related Features
Prerequisite Features

None

Mutually Exclusive Features

None

Impacted Features

Feature ID Feature Name Description

LOFD­001016 Semi­Persistent Scheduling When ROHC is enabled, compressed packet sizes fluctuate, even during talk spurts, due

to changes in the quality of the radio channels, the ROHC operating mode used, and
variations in the dynamic fields of the packet headers at the application layer. Therefore,
ROHC impacts LOFD­001016 VoIP Semi­persistent Scheduling. If the packet size after
compression is greater than the maximum size allowable for semi­persistent scheduling,
the eNodeB uses dynamic scheduling for the data beyond the size limit.
When the UL normal or smart preallocation function is enabled, UL ROHC will yield few
gains in resource saving if the size of packets scheduled by the eNodeB in preallocation
is greater than the size of voice packets.

LOFD­110225 Uplink Data Compression When ROHC is enabled, compressed packet sizes fluctuate, even during talk spurts, due

to changes in the quality of the radio channels, the ROHC operating mode used, and
variations in the dynamic fields of the packet headers at the application layer. Therefore,
ROHC impacts LOFD­001016 VoIP Semi­persistent Scheduling. If the packet size after
compression is greater than the maximum size allowable for semi­persistent scheduling,
the eNodeB uses dynamic scheduling for the data beyond the size limit.
When the UL normal or smart preallocation function is enabled, UL ROHC will yield few
gains in resource saving if the size of packets scheduled by the eNodeB in preallocation
is greater than the size of voice packets.
6 Network Impact
System Capacity

Header field compression for voice packets in the ROHC framework reduces the resource blocks (RBs) used for voice service users in the case of same channel
quality and Adaptive Multirate (AMR) for data transmission. For example, if voice service users with 12.65 kbit/s 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 and will work normally.
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 size of the increase
depends on many factors, such as the following:

User locations
User quantity
Data service models (such as Full buffer and Burst)
RB usage
Availability of PDCCH control channel elements (CCEs)
ROHC operating mode
ROHC compression efficiency
Support and compatibility of UEs for ROHC
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 the following conditions are met:

RBs of a cell are limited.
PDCCH CCEs in the cell are adequate.
ROHC works normally.
Users are evenly distributed in the cell.
Users require a large data service volume.

However, the amount of feedback depends on the ROHC operating mode. More feedback uses more radio resources, which limits system capacity expansion. An
ROHC interoperability test (IOT) indicates that some voice over long term evolution (VoLTE) UEs are incompatible with ROHC. These UEs always transmit
uncompressed IR packets even after ROHC is enabled, the coverage or capacity gains expected for ROHC are not achieved, and the number of RBs used for voice
service users slightly increases.

Network Performance

ROHC 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 transmit power by about 1 dB to 2 dB and ensure voice quality,
for example, maintaining the voice quality at mean opinion score (MOS) of 3.0.
If all the UEs on the live network support ROHC, the compression efficiency can reach 15%.

7 Engineering Guidelines

7.1 When to Use ROHC
The ROHC feature is recommended when the operator provides the IMS­based VoIP services in the LTE network and the mainstream commercial VoLTE UEs have
passed IOT.

7.2 Deployment

7.2.1 Requirements
Other Features

For details, see 5 Related Features.

Hardware

None

License

The operator has purchased and activated the license listed in the following table for the feature.

Feature ID Feature Name Model License Control Item NE Sales Unit

LOFD­001017 RObust Header LT1S00ROHC00 RObust Header eNodeB per RRC Connected User

Compression (ROHC) Compression (ROHC)
(FDD)

7.2.2 Data Preparation and Feature Activation

7.2.2.1 Data Preparation
The following tables describe parameters that must be set to configure the ROHC feature.
Table 7­1 PdcpRohcPara

Parameter Name Parameter ID Setting Notes Data Source

ROHC switch PdcpRohcPara.RohcSwitch In later versions, the PdcpRohcPara.RohcSwitch parameter will be Engineering design

replaced by the CellAlgoSwitch.RohcSwitch(N/A,LTE FDD eNodeB)
parameter. The current version supports configuration synchronization and
delivery of eNodeB­level and cell­level parameters. If the eNodeB­level
parameter is set to ON(On), whether the function is provided in cells is
determined by the eNodeB­level switch. If the eNodeB­level parameter is set
to OFF(Off), whether the function is provided in cells is determined by the
cell­level switch. Therefore, you are advised to switch to the cell­level
switch, then turn off the eNodeB­level switch, and avoid using the eNodeB­
level switch for ROHC afterwards.
Parameter Name Parameter ID Setting Notes Data Source

ROHC Highest mode PdcpRohcPara.HighestMode This parameter applies to the uplink only. The highest operating mode of Engineering design

ROHC in the downlink is controlled by UEs.
The recommended value is O_Mode.
The reasons are as follows:
When U_Mode is used, if the radio link quality is poor, the
compression will be inefficient.
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 profiles PdcpRohcPara.Profiles Commercial VoLTE UEs do not support profiles 0x0003 and 0x0004 at Engineering design

present. As a result, set this parameter to Profile0x0001(Profile0x0001) or
Profile0x0002(Profile0x0002).
If this parameter is adjusted while the eNodeB is running, the adjustment
affects only new services (not ongoing services).

Table 7­2 CellAlgoSwitch

Parameter Name Parameter ID Setting Notes Data Source

ROHC switch GLOBALPROCSWITCH.ProtocolSupportSwitch It is recommended that this parameter is set to ON(On) when the Radio network

operator provides the IMS­based VoIP services in the LTE network planning
and the mainstream commercial VoLTE UEs have passed the
interconnection test.

7.2.2.2 Activation
Using the CME

For detailed operations, see CME­based Feature Configuration.

Using MML Commands

Run the MOD PDCPROHCPARA and MOD CELLALGOSWITCH commands with the ROHC switch set to ON(On) and the ROHC Highest mode and
Compression profiles parameters set as required.

MML Command Examples

//Enabling ROHC

Macro eNodeBs:
MOD PDCPROHCPARA:ROHCSWITCH=OFF,HIGHESTMODE=O_MODE,PROFILES=Profile0x0001‐1&Profile0x0002‐1&Profile0x0003‐0&Profile0x0004‐0; 
MOD CELLALGOSWITCH:LocalCellId=0,ROHCSWITCH=ON;
Micro eNodeBs:
MOD PDCPROHCPARA:ROHCSWITCH=OFF,HIGHESTMODE=O_MODE,PROFILES=Profile0x0001‐1&Profile0x0002‐1; 
MOD CELLALGOSWITCH:LocalCellId=0,ROHCSWITCH=ON;

7.2.3 Activation Observation
1. Start a Uu tracing task on the U2000 client.
2. Use an ROHC­capable UE to perform a VoIP service. Check the RRC_UE_CAP_INFO message, as shown in Figure 7­1, to determine whether the UE
supports ROHC and which profiles the UE supports.
Figure 7­1 RRC_UE_CAP_INFO message

3. Check the RRC_CONN_RECFG message to determine whether ROHC has been activated.
If the information elements (IEs) pdcp­Config > headerCompression > rohc are displayed, as shown in Figure 7­2, ROHC has been activated.
Go to 4.
If the IEs pdcp­Config > headerCompression > notUsed: NULL are displayed, ROHC has not been activated. The procedure ends.
 Figure 7­2 RRC_CONN_RECFG message

4. Check the performance counters on the U2000 client.

 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.

For downlink transmission, check the values of L.PDCP.DL.RoHC.HdrCompRatio and L.PDCP.DL.RoHC.PktCompRatio. Smaller values
indicate higher compression efficiency.
When ROHC is working under normal radio conditions, the values of the two counters are less than 1.
If ROHC is operating 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 values of the
two counters will be greater than or equal to 1. This happens with an extremely low probability.

For uplink transmission, check the values of the following performance counters:
L.PDCP.UL.RoHC.FailDecompRatio
A smaller value indicates a higher decompression success rate. If the value is 0, the decompression success rate is 100%.
L.PDCP.UL.RoHC.HdrCompRatio and L.PDCP.UL.RoHC.PktCompRatio.
Smaller values indicate higher compression efficiency.
When ROHC is working under normal radio conditions, the values of the two counters are less than 1.
If ROHC is operating 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 values of the two counters will be greater than or equal to 1. This happens with an extremely low probability.

7.2.4 Deactivation
Using the CME

For detailed operations, see CME­based Feature Configuration.

Using MML Commands

To deactivate the ROHC feature, run the MOD PDCPROHCPARA and MOD CELLALGOSWITCH commands with the ROHC switch set to OFF(Off).

Command examples

//Disabling ROHC
MOD PDCPROHCPARA:ROHCSWITCH=OFF;
MOD CELLALGOSWITCH:LocalCellId=0,ROHCSWITCH=OFF;

7.3 Performance Monitoring
After ROHC is enabled, monitor the counters listed in the following table.
Table 7­3 Performance counters to be monitored

Counter ID Counter Name Description Principle

1526728522 L.PDCP.UL.RoHC.HdrCompRatio Compression rate of headers of all uplink PDCP The compression

SDUs after ROHC efficiency has a negative
correlation with the values
1526728523 L.PDCP.UL.RoHC.PktCompRatio Compression rate of all uplink PDCP SDUs (including of these counters.
headers and payloads) after the ROHC

1526727349 L.PDCP.DL.RoHC.HdrCompRatio Compression rate of headers of all downlink PDCP

SDUs after the ROHC

1526727350 L.PDCP.DL.RoHC.PktCompRatio Compression rate of all downlink PDCP SDUs

(including headers and payloads) after the ROHC

1526727351 L.PDCP.UL.RoHC.FailDecompRatio Decompression failure rate of all uplink PDCP SDUs The decompression

after the ROHC success rate has a
negative correlation with
the value of this counter.

1526728524 L.Traffic.User.RoHC.Max Maximum number of UEs on which ROHC takes The number of UEs on

effect in a cell which ROHC takes effect
has a positive correlation
1526728525 L.Traffic.User.RoHC.Avg Average number of UEs on which ROHC takes effect with the values of these
in a cell counters.

1526730883 L.ChMeas.PRB.DL.DrbUsed.Avg.VoIP Average number of PRBs used by DRBs on the These counters are used

PDSCH for downlink VoIP services to observe the changes in
the number of RBs used
in the downlink and uplink
by VoLTE users before
 and after ROHC is
Counter ID Counter Name Description Principle
enabled.
1526730884 L.ChMeas.PRB.UL.DrbUsed.Avg.VoIP Average number of PRBs used by DRBs on the
PUSCH for uplink VoIP services

7.4 Parameter Optimization
None

7.5 Troubleshooting
None

8 Parameters
Table 8­1 Parameters

MO Parameter ID MML Command Feature Feature Description

ID Name

CellAlgoSwitch RohcSwitch MOD LOFD­ RObust Meaning:

CELLALGOSWITCH 001017 / Header Indicates whether to enable ROHC in a cell. If this parameter is set
LST TDLOFD­ Compression to ON, ROCH can be enabled for UEs supporting ROCH in the cell.
CELLALGOSWITCH 001017 (ROHC) If this parameter is set to OFF, ROCH cannot be enabled for UEs in
the cell.
If the eNodeB­level parameter PDCPROHCPARA.RohcSwitch is
set to ON, the setting of this cell­level parameter does not take
effect. If the eNodeB­level parameter
PDCPROHCPARA.RohcSwitch is set to OFF, the setting of this
cell­level parameter takes effect.
It is recommended that this parameter be set to ON when a cell
supports VoIP services.
GUI Value Range: OFF(Off), ON(On)
Unit: None
Actual Value Range: OFF, ON
Default Value: OFF(Off)

PdcpRohcPara Profiles MOD LOFD­ RObust Meaning:

PDCPROHCPARA 001017 / Header Indicates the compression profile supported by the eNodeB.
LST PDCPROHCPARA TDLOFD­ Compression Under the ROHC framework, header compression algorithms vary
001017 (ROHC) with protocols. Profiles define the header compression protocols
(such as RTP/UDP/IP or TCP/IP), which are under the same ROHC
framework, for specific types of packet streams. Each profile has a
unique identifier.
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), and profile 0x0004 (usage: IP; reference:
RFC 3843 and RFC 4815).
GUI Value Range: Profile0x0001(Profile0x0001),
Profile0x0002(Profile0x0002), Profile0x0003(Profile0x0003),
Profile0x0004(Profile0x0004)
Unit: None
Actual Value Range: Profile0x0001, Profile0x0002, Profile0x0003,
Profile0x0004
Default Value: Profile0x0001:On, Profile0x0002:On,
Profile0x0003:On, Profile0x0004:On

PdcpRohcPara HighestMode MOD LOFD­ RObust Meaning: Indicates the operating mode of ROHC. In Unidirectional

PDCPROHCPARA 001017 / Header Mode (U­Mode), packets are sent only from the compressor to the
LST PDCPROHCPARA TDLOFD­ Compression decompressor, and a feedback channel is not mandatory. Therefore,
001017 (ROHC) U­Mode is less reliable than Bidirectional Optimistic Mode (O­Mode)
and Bidirectional Reliable Mode (R­Mode), but its feedback­induced
overhead is 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)

PdcpRohcPara RohcSwitch MOD LOFD­ RObust Meaning:

PDCPROHCPARA 001017 / Header Indicates whether to enable ROHC.
LST PDCPROHCPARA TDLOFD­ Compression Set this parameter to ON if the eNodeB is expected to support VoIP
001017 (ROHC) or video services.
GUI Value Range: OFF(Off), ON(On)
Unit: None
Actual Value Range: OFF, ON
Default Value: OFF(Off)
MO Parameter ID MML Command Feature Feature Description
ID Name

GlobalProcSwitch ProtocolSupportSwitch MOD None None Meaning:

GLOBALPROCSWITCH Indicates whether the eNodeB supports some protocol­defined
LST procedures.
GLOBALPROCSWITCH SupportS1UeCapMatchMsg: If this option is selected, the eNodeB
can process and respond to the UE RADIO CAPABILITY MATCH
REQUEST message over the S1 interface. For details, see 3GPP
TS 36.413. If the option is deselected, the eNodeB cannot process
the UE RADIO CAPABILITY MATCH REQUEST message and
responds with an error indication message.
SupportS1UELocationInfoSwitch: The eNodeB reports the UE
location information in the E­RAB and UE context release messages
to the MME only if this option is selected. The messages include UE
CONTEXT RELEASE COMPLETE, E­RAB RELEASE
INDICATION, and E­RAB RELEASE RESPONSE. For details, see
3GPP TS 36.413.
SupportDrbRlcRelUecntSwitch: If this option is selected, the
eNodeB proactively releases UE contexts when the maximum
number of DRB RLC retransmission times is reached. If this option
is deselected, the eNodeB proactively releases UE bearers when
the maximum number of DRB RLC retransmission times is reached.
GUI Value Range:
SupportS1UeCapMatchMsg(SupportS1UeCapMatchMsg),
SupportS1UELocationInfoSwitch(SupportS1UELocationInfoSwitch),
SupportDrbRlcRelUecntSwitch(SupportDrbRlcRelUecntSwitch)
Unit: None
Actual Value Range: SupportS1UeCapMatchMsg,
SupportS1UELocationInfoSwitch, SupportDrbRlcRelUecntSwitch
Default Value: SupportS1UeCapMatchMsg:Off,
SupportS1UELocationInfoSwitch:Off,
SupportDrbRlcRelUecntSwitch:Off

9 Counters
Table 9­1 Counters

Counter ID Counter Name Counter Description Feature ID Feature Name

1526727349 L.PDCP.DL.RoHC.HdrCompRatio Compression rate of headers Multi­mode: None RObust Header Compression

of all downlink PDCP SDUs GSM: None (ROHC)
after the ROHC UMTS: None RObust Header Compression
LTE: LOFD­001017 (ROHC)
TDLOFD­001017

1526727350 L.PDCP.DL.RoHC.PktCompRatio Compression rate of all Multi­mode: None RObust Header Compression

downlink PDCP SDUs GSM: None (ROHC)
(including headers and UMTS: None RObust Header Compression
payloads) after the ROHC (ROHC)
LTE: LOFD­001017
TDLOFD­001017

1526727351 L.PDCP.UL.RoHC.FailDecompRatio Decompression failure rate of Multi­mode: None RObust Header Compression

all uplink PDCP SDUs after GSM: None (ROHC)
the ROHC UMTS: None RObust Header Compression
LTE: LOFD­001017 (ROHC)
TDLOFD­001017

1526728522 L.PDCP.UL.RoHC.HdrCompRatio Compression rate of headers Multi­mode: None RObust Header Compression

of all uplink PDCP SDUs GSM: None (ROHC)
after the ROHC UMTS: None RObust Header Compression
LTE: LOFD­001017 (ROHC)
TDLOFD­001017

1526728523 L.PDCP.UL.RoHC.PktCompRatio Compression rate of all uplink Multi­mode: None RObust Header Compression

PDCP SDUs (including GSM: None (ROHC)
headers and payloads) after UMTS: None RObust Header Compression
the ROHC (ROHC)
LTE: LOFD­001017
TDLOFD­001017

1526728524 L.Traffic.User.RoHC.Max Maximum number of UEs on Multi­mode: None RObust Header Compression

which ROHC takes effect in a GSM: None (ROHC)
cell UMTS: None RObust Header Compression
LTE: LOFD­001017 (ROHC)
TDLOFD­001017

1526728525 L.Traffic.User.RoHC.Avg Average number of UEs on Multi­mode: None RObust Header Compression

which ROHC takes effect in a GSM: None (ROHC)
cell UMTS: None RObust Header Compression
LTE: LOFD­001017 (ROHC)
TDLOFD­001017

1526730883 L.ChMeas.PRB.DL.DrbUsed.Avg.VoIP Average number of PRBs Multi­mode: None Basic Scheduling

used by DRBs on the GSM: None Basic Scheduling
PDSCH for downlink VoIP UMTS: None Adaptive SFN/SDMA
services
LTE: LBFD­002025
TDLBFD­002025
LOFD­070205

1526730884 L.ChMeas.PRB.UL.DrbUsed.Avg.VoIP Average number of PRBs Multi­mode: None Basic Scheduling

used by DRBs on the GSM: None Basic Scheduling
PUSCH for uplink VoIP UMTS: None Adaptive SFN/SDMA
services
LTE: LBFD­002025
TDLBFD­002025
LOFD­070205

10 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

11 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 Feature Parameter Description