16-PDCP Header Compression

RAN Feature Description
Table of Contents
Table of Contents
Chapter 16 PDCP Header Compression...................................................................................16-1
16.1 Introduction................................................................................................................... 16-1
16.1.1 Definition............................................................................................................. 16-1
16.1.2 Purposes............................................................................................................ 16-1
16.1.3 Terms and Abbreviations....................................................................................16-2
16.2 Availability..................................................................................................................... 16-5
16.2.1 Network Elements Involved................................................................................16-5
16.2.2 Software Releases............................................................................................. 16-5
16.2.3 Miscellaneous..................................................................................................... 16-5
16.3 Impact........................................................................................................................... 16-6
16.3.1 On System Performance....................................................................................16-6
16.3.2 On Other Features.............................................................................................. 16-6
16.4 Technical Description.................................................................................................... 16-6
16.4.1 PDCP Header Compression Configuration Model..............................................16-6
16.4.2 Overview of Header Compression......................................................................16-6
16.4.3 System Architecture............................................................................................ 16-7
16.4.4 Process for Header Compression.....................................................................16-10
16.4.5 Implementation of PDCP Header Compression by Huawei RNC.....................16-16
16.5 Capabilities................................................................................................................. 16-18
16.6 Implementation........................................................................................................... 16-18
16.6.1 Enabling PDCP Header Compression..............................................................16-18
16.6.2 Reconfiguring PDCP Header Compression Parameters..................................16-19
16.6.3 Disabling PDCP Header Compression.............................................................16-20
16.7 Maintenance Information.............................................................................................16-20
16.7.1 Alarms............................................................................................................... 16-20
16.7.2 Counters........................................................................................................... 16-20
16.8 References.................................................................................................................. 16-22
Huawei Technologies Proprietary

i
List of Figures
List of Figures
Figure 16-1 PDCP Header Compression configuration model............................................16-6
Figure 16-2 Block diagram of header compression.............................................................16-7
Figure 16-3 UMTS structure for the PS domain..................................................................16-8
Figure 16-4 User plane of the protocol stack for the PS domain.........................................16-9
Figure 16-5 PDCP structure in the radio interface protocol architecture.............................16-9
Figure 16-6 Process for header compression...................................................................16-10
Figure 16-7 Exponentially increasing period after a change.............................................16-14

ii
List of Tables
List of Tables
Table 16-1 NEs required for PDCP header compression....................................................16-5
Table 16-2 RAN products and related versions...................................................................16-5
Table 16-3 PDCP header compression counters...............................................................16-21

iii
Chapter 16 PDCP Header Compression

16.1 Introduction
16.1.1 Definition
The Packet Data Convergence Protocol (PCDP) is an important component of the
protocols of the radio interface L2. It provides the following functions:
Transfer of packet data
Header compression and decompression of IP data streams
Lossless SRNS relocation
Traffic measurement
The general process of PDCP header compression is as follows:

1)
The redundant protocol headers are compressed before being transmitted on a

link.
2)
The packets are decompressed to their original status when they are received at
the other end of the link.
16.1.2 Purposes
PDCP header compression is applied for the following purposes.
I. Reducing Header Overhead

The common size of a TCP segment in bulk transfer over a medium speed link is 512
bytes. When a TCP segment is tunneled, the size of an IPv4, IPv6, or TCP header is
100 bytes. Thus, IPv6 and TCP headers account for 19.5% of the whole size, and
IPv4 and TCP headers account for 11.7%. After PDCP header compression, however,
the headers only account for less than 1% of the whole size. PDCP header
compression greatly reduces header overhead.
In addition, for speech services, a packet with huge amount of data comes with
significant delay. Small packets must be the first choice for short end-to-end delay.
For this purpose, the header overhead can be reduced to a large extent by PDCP
header compression.
II. Shortening Response Time

When a large header is transmitted over a low speed link, echoing of characters takes
more than 100200 ms, which is the maximum tolerable time for people not to feel
that the system is sluggish.

1
PDCP header compression shortens response time and improves the echoing rate of
characters.
III. Reducing Packet Loss Rate

After PDCP header compression, fewer bits are transmitted for each packet.
Therefore, the packet loss rate is lower for a given Bit Error Rate (BER).
16.1.3 Terms and Abbreviations

I. Terms
Term
Subheader
Description
An IPv6 base header, an IPv6 extension header, an IPv4 header,
a UDP header, or a TCP header.
Subheader
A chain of subheaders.
chain
Compress
The act of reducing the size of a header by removing header

fields or reducing the size of header fields.
This is done in such a way that a decompressor can re-form the
header if its context state is identical to the context state used in
compression of the header.
Decompress
The act of restoring the original header.
Context
A small unique number that identifies the context used to
identifier (CID)
decompress a compressed header.

CIDs are carried in full headers or compressed headers.
Context
A bit string that the compressor uses to compress a header and

the decompressor uses to decompress a header.
It is the uncompressed version of the last header that the
compressor sends or the decompressor receives over the link.
The context for a packet stream is associated with a CID. In
addition, the context for a non-TCP packet stream is associated
with a generation.
Generation
A number that is incremented whenever the context with a

specified CID changes.
A generation is specific for a non-TCP packet stream and carried
by a full or compressed non-TCP header. Each new version of
the context with a specified CID is associated with a generation.

2
Term
Packet stream
Description
A sequence of packets that have similar headers and share a
context.
Full header
An uncompressed header that updates or refreshes the context

for a packet stream.
It carries a CID. For a non-TCP packet stream, a full header also
carries a generation.
Regular
An uncompressed header that carries neither a CID nor a
header
generation.
Incorrect
A situation where a decompressed header is different from the
decompression
header before compression.

Usually, incorrect decompression is due to context mismatch
between the compressor and decompressor or due to bit errors
during transmission of the compressed header.
Differential
A compression technique where the compressed value of a
coding
header field is the difference between the current value of the

field and the value of the same field in the previous header in the
same packet stream.
By differential coding, the decompressor obtains the value of the
field by adding the value in the compressed header to its context.
Multi-hop
Data are forwarded by multiple uncertain routers before reaching

the destination.
II. Abbreviations
Abbreviation
Full Spelling
ARPU
Average Revenue Per User
BER
Bit Error Rate
CN
Core Network
FTP
File Transfer Protocol
HC
Header Compression
GGSN
Gateway GPRS Support Node
GPRS
General Packet Radio Service

3
Abbreviation
Full Spelling
GSM
Global System for Mobile communications
GTP-U
GPRS Tunneling Protocol for User Plane
IP
Internet Protocol
IPv4
Internet Protocol version 4
IPv6
Internet Protocol version 6
MTU
Maximum Transfer Unit
PDCP
Packet Data Convergence Protocol
QoS
Quality of Service
RAB
Radio Access Bearer
RB
Radio Bearer
RFC
Request For Comments
RLC
Radio Link Control
RNC
Radio Network Controller
RTP
Real-Time Transport Protocol
RTT
Round Trip Time
SAP
Service Access Point
SDU
Service Data Unit
SGSN
Serving GPRS Support Node
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
UE
User Equipment
UTRAN
UMTS Terrestrial Radio Access Network
WCDMA
Wideband Code Division Multiple Access

4
16.2 Availability
16.2.1 Network Elements Involved
Table 1.1 describes the NEs involved with PDCP header compression.
Table 1.1 NEs required for PDCP header compression
UE
NodeB
RNC
MSC
MGW
SGSN
GGSN
HLR
Server
Note:
: not required
: required
Note:
This chapter describes only the availability of the UE and the RNC.
16.2.2 Software Releases

Table 1.1 describes the versions of RAN products that support PDCP header
compression.
Table 1.1 RAN products and related versions
Product
RNC
BSC6800
Version
Remark
V100R002 and later
Support IPv4 header
releases
compression
V100R006 and later
Support IPv4 and IPv6 header
releases
compressions
16.2.3 Miscellaneous
PDCP header compression is an optional feature of Huawei UMTS RAN. The
corresponding license must be bought to enable the feature.

5
16.3 Impact
16.3.1 On System Performance
None.
16.3.2 On Other Features

None.
16.4 Technical Description

16.4.1 PDCP Header Compression Configuration Model
The configuration model for PDCP Header Compression is as show in Figure 1.1.
RNC
RadioClass
GlobalParaClass
FRC.Class
CORRMALGOSWITCH.Class
Max control header size[byte]
Channel class algorithm switch
Max CID value for TCP connections

Max CID value for non-TCP connections
Max number of compressed non-TCP headers
Max time for sending compressed headers[s]
RFC2507 default parameter switch
Figure 1.1 PDCP Header Compression configuration model
16.4.2 Overview of Header Compression

The IP protocol, transport protocols like TCP or UDP, and optional application
protocols are described in the header of a packet. Data in a header serves longdistance transport over multiple links or multi-hop network. The header includes the
following data:
Source IP address
Destination IP address

6
Port information
Protocol ID
Sequence number
Error checking information
For TCP packets in telecommunications, many fields are constant and others change
with small and predictable values. Depending on whether the fields remain constant
or change in specific patterns, some fields can be either excluded from each packet
or represented in a smaller number of bits. This is described as header compression.
Header compression uses the concept of packet stream context. A context is a set of
data about field values and value change patterns in the packet header. For each
packet stream, the context is formed at the compressor and the decompressor. After
the context is established on both sides, the compressor can compress the packets.
Figure 1.1 shows the block diagram of header compression.
Packet stream
Packet stream in
forward direction
Header
compression
Compressed packets
Header
decompression
Feedback
Context
Context
Figure 1.1 Block diagram of header compression

To initiate compression of the headers of a packet stream, a full header carrying a
CID is transmitted over the link. The compressor and decompressor store most fields
of this full header as the context. The context contains the fields of the headers
whose values are constant. Thus, these fields need not be sent over the link at all, or
only change little between consecutive headers. Then, only a few bits are required to
send the difference from the previous value, instead of sending the absolute value.
Any change in fields that are expected to be constant in a packet stream will cause
the compressor to send a full header again to update the context at the
decompressor. If the contexts are the same at the compressor and the decompressor,
headers can be decompressed to the original ones. Thus, a header compression
scheme provides mechanisms to update the context at the decompressor and to
detect or avoid incorrect decompression.
16.4.3 System Architecture

I. UMTS Structure for the PS Domain
Figure 1.1 shows the UMTS structure for the Packet Switched (PS) domain.
7
The header compression function is provided by the RNC. Packet data is transferred
from the Internet or other external networks to the RNC by the GGSN and SGSN
through the GPRS Tunnel Protocol (GTP). The RNC relays the packet data to the UE.
Uu
lu
VLR
USIM
Cu
lub
HLR
NodeB
SGSN
RNC
ME
GGSN
Internet
NodeB
UE
UTRAN
CN
External
networks
Figure 1.1 UMTS structure for the PS domain
II. User Plane of the Protocol Stack for the PS Domain

As shown in Figure 3.1, the user plane has a layered protocol structure. It transfers
user data through data transfer control procedures. Header compression is performed
by PDCP.
After receiving data from the PS domain through the GTP-U tunnel, the RNC
processes the data as follows:
1)
Performs header compression.
2)
Sends the compressed data to the RLC module on the lower layer.
3)
Further processes the data on lower layers and then sends the data to the UE
through the Uu interface.
After receiving the data, the UE processes the data as follows:

1)
Processes the data on the lower layers.
2)
Sends the data to the PDCP sub layer and decompresses it.
3)
Sends the data to the application layer.
That is the process of downlink data transfer. The uplink data transfer is of the same
principle.

8
Application
E.g., IP,
PPP
E.g., IP,
PPP
Relay
Relay
PDCP
PDCP
GTP-U
GTP-U
GTP-U
GTP-U
RLC
RLC
UDP/IP
UDP/IP
UDP/IP
UDP/IP
MAC
MAC
AAL5
AAL5
L2
L2
L1
ATM
ATM
L1
L1
Uu
Iu-PS
UE
UTRAN
L1
Gn
3G SGSN
Gi
3G GGSN
Figure 3.1 User plane of the protocol stack for the PS domain
III. PDCP Structure in the Radio Interface Protocol Architecture

Figure 1.1 shows the PDCP structure in the radio interface protocol architecture.
Radio bearers
PDCP-SDU
PDCP-SAPs
...
PDCP sublayer
C-SAP
PDCP entity
PDCP entity
HC protocol
type 1
SDU
numbering
HC protocol
type 2
HC protocol
type 1
HC protocol
type 2
PDCP entity
HC protocol
type 1
RLC-SDU
...
UM-SAP
AM-SAP
TM-SAP RLC
Figure 1.1 PDCP structure in the radio interface protocol architecture

The PDCP sub layer contains many PDCP entities.
Every PS domain Radio Access Bearer (RAB) is associated with one Radio Bearer
(RB), which in turn is associated with one PDCP entity. Each PDCP entity is

9
associated with one or two (one for each direction) RLC entities, depending on the
RB characteristic (namely, unidirectional or bidirectional) and RLC mode.
PDCP in the RNC and UE performs header compression on IP data streams at the
transmitting entity, and header decompression at the receiving entity. The headers
include TCP/IP and RTP/UDP/IP ones for IPv4 and IPv6. Every PDCP entity uses
zero, one, or several different header compression protocol types.
16.4.4 Process for Header Compression

Figure 1.1 shows the process for header compression.
Input
Output
Feedback
Header request
algorithm
Compressor
Yes
Compressible chain
of header judgment
algorithm
Decompression
fails again?
Packet stream
judgment algorithm
Twice algorithm
No
Yes
Packet
stream type
Non-TCP
Slow-start algorithm
Decompression
fails?
No
TCP
Decompressor
Periodic header
refresh algorithm
Figure 1.1 Process for header compression

The process involves the following algorithms:
Compressible Chain of Subheader Judgment Algorithm
Packet Stream Judgment Algorithm

10
Twice Algorithm for TCP Packet Streams
Header Request Algorithm for TCP Packet Streams
Compression Slow-Start Algorithm for Non-TCP Packet Streams
Periodic Header Refresh Algorithm for Non-TCP Packet Streams
I. Compressible Chain of Subheader Judgment Algorithm

A compressible subheader can be one of the following:
An IPv6 base header
An IPv6 extension header
A TCP header
A UDP header
An IPv4 header
The compressible chain of subheaders extends from the beginning of the
header. It includes the following two types:
A chain beginning from but not including the first header that is not an IPv4
header, an IPv6 base or extension header, a TCP header, or a UDP header
A chain beginning from and including the first TCP header, UDP header,
fragment header, Encapsulating Security Payload (ESP) header, or IPv4 header
for a fragment
Both types fit a chain of subheaders that contain a fragment header and ends at a
tunneled IPX packet. Since the second type gives a shorter chain, the compressible
chain of subheaders stops at the fragment header.
An implementation MUST NOT compress more than the initial MAX_HEADER (Max
control header size [byte]) bytes of a header. An implementation MUST NOT
partially compress a subheader. Thus, the part of the header that is stored as context
and is compressed is the longest initial sequence of entire subheaders that is not
larger than MAX_HEADER (Max control header size [byte]) bytes.
Parameter:

11
Parameter Name
Max control header size[byte]
Parameter ID
MAXHEADER
GUI Range
6065535
Physical Range& Unit
byte
Default Value
168
Optional/Mandatory
Optional
MML Command
SET FRC
Description:
As a PDCP specified parameter, it indicates the maximum control header size in
bytes that may be compressed.
Configuration Rule and Restriction:

MAXHEADER (Max control header size [byte]) is configurable only if
RFC2507DEFPARASWITCH (RFC2507 default parameter switch) is enabled.
II. Packet Stream Judgment Algorithm

The compressor uses the criterion that it finds appropriate to group packets into
packet streams. To determine which packet stream a packet belongs to, a
compressor performs the following:
1)
Checks the compressible chain of subheaders.
2)
Checks the contents of an upper layer protocol header, such as TCP or UDP.
3)
Checks if the defining fields of compressible chain of subheaders are changed.
If too many fields are used for identification, performance might suffer because more
CIDs will be used and the wrong CIDs might be reused when new flows need CIDs. If
too few fields are used for identification, performance might suffer because there are
too frequent changes to the context.
The CID spaces for TCP and non-TCP are separate. Therefore, a TCP CID and a
non-TCP CID never identify the same context even if they have the same value.
When the same number of bits is used for the CIDs, it only doubles the available CID
space. The maximum CID value configured for TCP is called TCPSPACE (Max CID v
alue for TCP connections). The maximum CID value configured for non-TCP is calle
d NONTCPSPACE (Max CID value for non-TCP connections).
12
Parameter:
Parameter Name
Max CID value for TCP connections
Parameter ID
TCPSPACE
GUI Range
3255
None
Default Value
15
Optional/Mandatory
Optional
MML Command
SET FRC
Description:
As a PDCP specified parameter, it indicates the maximum CID value used for TCP
connections.
Parameter Name
Max CID value for non-TCP connections
Parameter ID
NONTCPSPACE
GUI Range
365535
None
Default Value
15
Optional/Mandatory
Optional
MML Command
SET FRC
Description:
As a PDCP specified parameter, it indicates the maximum CID used for non-TCP
connections.
TCPSPACE (Max CID value for TCP connections) is configurable only if

RFC2507DEFPARASWITCH (RFC2507 default parameter switch) is enabled.
NONTCPSPACE (Max CID value for non-TCP connections) is configurable

only if RFC2507DEFPARASWITCH (RFC2507 default parameter switch) is
enabled.

13
III. Twice Algorithm for TCP Packet Streams

In this algorithm, the decompressor computes a checksum to check if its context has
been updated properly. If the checksum fails, the error might be caused by a lost
segment that did not update the context properly. If the lost segment contained the
same delta as the current, the delta of the current segment is then added to the
context again. The decompressor recomputes the checksum and, if successful,
continues to deliver packets. If the repair fails, the delta is applied again, that is,
adding the delta and recomputing the checksum.
Analysis of traces of diverse TCP bulk transfers shows that applying the delta of the
current segment one or two times repairs the context for 83% to 99% of all singlesegment losses in the data stream. For the acknowledgment stream, the success rate
is lower due to the delayed acknowledgment mechanism of TCP. The Twice
mechanism repairs the context for 53% to 99% of the losses in the acknowledgment
stream.
IV. Header Request Algorithm for TCP Packet Streams

After the Twice algorithm fails, another recovery mechanism, called Header Request,
is available for repairing the context at the decompressor. When failing to repair the
context after a loss, the decompressor requests a complete header from the
compressor. This is possible only when bidirectional links are used, because the
decompressor must communicate with its compressor. The decompressor sends a
context state message to the compressor when making a header request. The
context state message can include all compressed packet streams that need a
context update.
V. Compression Slow-Start Algorithm for Non-TCP Packet Streams

To help the decompressor recover quickly from loss of a full header that has changed
the context, full headers are sent periodically with an exponentially increasing period
after a change in the context, as shown in Figure 1.1. This technique avoids an
exchange of messages between the compressor and decompressor. Such exchanges
are costly for wireless mobiles, because more power is consumed by the transmitter
and delay can be introduced by switching between transmission and reception.
| . | . ...| . . . . | . . . . . . . . |. . . . . . . . . . . . . . . . | ..............................
| : full header
. : compressed header
Figure 1.1 Exponentially increasing period after a change

Figure 1.1 shows how packets are sent after a change in the context. The
compressor keeps a variable F_PERIOD for each non-TCP packet stream. The
14
variable keeps track of how many compressed headers are sent between full
headers. When the headers of a non-TCP packet stream change so that its context
changes, a full header is sent and F_PERIOD is set to 1. After F_PERIOD
compressed headers are sent, a full header is sent. F_PERIOD is doubled each time
a full header is sent during compression slow-start.
VI. Periodic Header Refresh Algorithm for Non-TCP Packet Streams

To avoid losing too many packets when a receiver loses its context, there is an upper
limit, F_MAX_PERIOD (Max number of compressed non-TCP headers), on the
number of compressed headers in a non-TCP packets stream. These compressed
headers might be sent between header refreshes. If a packet is to be sent and
F_MAX_PERIOD (Max number of compressed non-TCP headers) compressed
headers have been sent after the last full header was sent for this packet stream, a
full header must be sent.
To avoid long periods of disconnection for low data rate packet streams, there is also
an upper limit, F_MAX_TIME (Max time for sending compressed headers[s]), on
the time between full headers in a non-TCP packet stream. If a packet is to be sent
and more than F_MAX_TIME (Max time for sending compressed headers[s])
seconds have passed after the last full header was sent for this packet stream, a full
header must be sent.
Parameter:
Parameter Name
Max number of compressed non-TCP headers
Parameter ID
F_MAX_PERIOD
GUI Range
165535
None
Default Value
256
Optional/Mandatory
Optional
MML Command
SET FRC
Description:
As a parameter specified in PDCP, it indicates the maximum number of
compressed non-TCP headers that may be sent without a full header. The word
"compressed" means some unnecessary header information is not transmitted with
the packet data so as to save network resource.

15
Parameter Name
Parameter ID
Max time for sending compressed headers[s]

F_MAX_TIME
GUI Range
1255
Default Value
Optional/Mandatory
Optional
MML Command
SET FRC
Description:
As a PDCP specified parameter, it indicates the maximum duration for sending
compressed headers after the last full header is sent.
F_MAX_PERIOD (Max number of compressed non-TCP headers) is

configurable only if RFC2507DEFPARASWITCH (RFC2507 default parameter
switch) is enabled.
F_MAX_TIME
(Max
time
for
sending
compressed
headers[s])
is
configurable only if RFC2507DEFPARASWITCH (RFC2507 default parameter

switch) is enabled.
16.4.5 Implementation of PDCP Header Compression by Huawei RNC

I. Overview
The implementation of PDCP header compression by Huawei RNC completely
complies with the IP Header Compression (IPHC) protocol RFC2507.
II. Parameters Configured for the Implementation by Huawei
FRC_PDCP_COMPRESS_SWITCH (Channel class algorithm switch)

When it is checked and the PDCP header compression license is enabled, the
PDCP header compression algorithm will be applied in the RNC.
PDCP_IPV6_HEAD_COMPRESS_SWITCH (Channel class algorithm switch)

When it is checked and the PDCP header compression function is enabled, the
PDCP header compression algorithm for IPv6 will be applied in the RNC.
RFC2507DEFPARASWITCH (RFC2507 default parameter switch)

16
It is the default parameter switch of RFC2507.

Parameter:
Parameter Name
Parameter ID
CHSWITCH:
FRC_PDCP_COMPRESS_SWITCH
GUI Range
01
None
Default Value
Optional/Mandatory
Optional
MML Command
SET CORRMALGOSWITCH
Description:
When it is checked and the PDCP header compression license is enabled, the
PDCP header compression algorithm will be applied in the RNC.
Parameter Name
Parameter ID
CHSWITCH:
PDCP_IPV6_HEAD_COMPRESS_SWITCH
GUI Range
01
None
Default Value
Optional/Mandatory
Optional
MML Command
SET CORRMALGOSWITCH
Description:
When it is checked and the PDCP header compression function is enabled, the
PDCP header compression algorithm for IPv6 will be applied in the RNC.

17
Parameter Name
Parameter ID
RFC2507DEFPARASWITCH
GUI Range
DISABLE, ENABLE
None
Default Value
ENABLE
Optional/Mandatory
Optional
MML Command
SET FRC
Description:
16.5 Capabilities
None.
16.6 Implementation
16.6.1 Enabling PDCP Header Compression
I. Hardware Installation
This feature does not need extra hardware.
II. License Update

To activate the license for PDCP header compression, perform the following steps:
1)
Get the new license.
2)
Download the license to the BAM installation directory\FTP\license through FTP.
3)
Execute the ACT LICENSE command on the M2000 or the RNC LMT to activate
the new license.
III. Data Configuration

To configure the parameters for the PDCP header compression, perform the following
steps:
1)
Execute the SET CORRMALGOSWITCH command to enable the following

switches:

18
2)
Execute the SET FRC command to enable the switch

RFC2507DEFPARASWITCH and configure the following parameters:
FMAXPERIOD
FMAXTIME
MAXHEADER
TCPSPACE
NONTCPSPACE
IV. Verification of the Enabled Feature

Execute the LST CORRMALGOSWITCH or the LST FRC command to check if the
activation succeeds.
V. Examples
// Enable the FRC_PDCP_COMPRESS_SWITCH and the
PDCP_IPV6_HEAD_COMPRESS_SWITCH.
SET CORRMALGOSWITCH: ChSwitch=FRC_PDCP_COMPRESS_SWITCH1&PDCP_IPV6_HEAD_COMPRESS_SWITCH-1;
// Verify the feature activation.
LST CORRMALGOSWITCH: LstFormat=VERTICAL;
// The result indicates that the activation succeeds.
// Enable the RFC2507DEFPARASWITCH and configure relevant parameters.

SET FRC: Rfc2507DefParaSwitch=ENABLE, FMaxPeriod=256, FMaxTime=5,
MaxHeader=168, TcpSpace=15, NonTcpSpace=15;;
// Verify the feature activation.
LST FRC: LstFormat=VERTICAL;
// The result indicates that the activation succeeds.
16.6.2 Reconfiguring PDCP Header Compression Parameters

I. Switch Adjustment
Execute the SET CORRMALGOSWITCH command to adjust the following switches:
Execute the SET FRC command to adjust the switch RFC2507DEFPARASWITCH.
II. Parameter Reconfiguration Verification

Execute the LST CORRMALGOSWITCH or the LST FRC command to check if the
reconfiguration succeeds.

19
III. Examples
// Disable the PDCP_IPV6_HEAD_COMPRESS_SWITCH.
SET CORRMALGOSWITCH: PDCP_IPV6_HEAD_COMPRESS_SWITCH-0;
// Verify the reconfiguration.
// The result indicates that the reconfiguration succeeds.
// Disable the RFC2507DEFPARASWITCH.

SET FRC: RFC2507DEFPARASWITCH=DISABLE;
// Verify the reconfiguration.
LST FRC: LstFormat=VERTICAL;
// The result indicates that the reconfiguration succeeds.
16.6.3 Disabling PDCP Header Compression

I. Switch Disabling
Execute the SET CORRMALGOSWITCH or the SET FRC to disable the switches.
II. Verification of the Disabled Feature

Execute the LST CORRMALGOSWITCH or the LST FRC to check if the deactivation
succeeds.
III. Examples
// Disable the FRC_PDCP_COMPRESS_SWITCH and the
SET CORRMALGOSWITCH: ChSwitch=FRC_PDCP_COMPRESS_SWITCH0&PDCP_IPV6_HEAD_COMPRESS_SWITCH-0;
// Verify the deactivation.
// The result indicates that the deactivation succeeds.
16.7 Maintenance Information

16.7.1 Alarms
None.

20
16.7.2 Counters
The related counters belong to RNC -> RNC PDCPGTPU, where RNC refers to the
measurement type, and RNC PDCPGTPU refers to the measurement unit. Table 1.1
describes the counters.
Table 1.1 PDCP header compression counters
Counter
Description
VS.PDCP.DL.IPV4
Number of IPV4 PDCP instances on DL
VS.PDCP.UL.IPV4
Number of IPV4 PDCP instances on UL
VS.PDCP.DL.IPV6
Number of IPV6 PDCP instances on DL
VS.PDCP.UL.IPV6
Number of IPV6 PDCP instances on UL
VS.PDCP.DL.PPP
Number of PPP PDCP instances on DL
VS.PDCP.UL.PPP
Number of PPP PDCP instances on UL
VS.PDCP.DL.2507.TCP
Number of DL data flows with TCP contexts
VS.PDCP.DL.2507.Other
Number of DL data flows with NONTCP

Contexts
VS.PDCP.DL.NoCompress
Number of DL packets not compressed
VS.PDCP.UL.DecompressError
Number of UL packets with error in extraction
VS.PDCP.DL.PktSize.Mean
Average size of DL packets
VS.PDCP.UL.PktSize.Mean
Average size of UL packets
VS.PDCP.DL.PktHeader.Mean
Average size of DL packet headers
VS.PDCP.UL.PktHeader.Mean
Average size of UL packet headers
VS.GTP.DL.PktDist.1.200
Number of DL packets with 0200 bytes
VS.GTP.DL.PktDist.1001.Max
Number of DL packets with 1001 bytes and

above
VS.GTP.UL.PktDist.1.200
Number of UL packets with 0200 bytes

21
Counter
Description
VS.GTP.UL.PktDist.1001.Max
Number of UL packets with 1001 bytes and

above
VS.PDCP.DL.HdrCompressRatio
Compression ratio of DL packet headers
VS.PDCP.DL.PktCompressRatio
Compression ratio of DL packets
16.8 References
RFC2507 IP Header Compression
3GPP TS 25.323 V5.2.0 (2002-09) "Packet Data Convergence Protocol (PDCP)

Specification"

22

16-PDCP Header Compression

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

16-PDCP Header Compression

Enviado por

Direitos autorais:

Formatos disponíveis

RAN Feature Description

Huawei Technologies Proprietary

RAN Feature Description

Huawei Technologies Proprietary

RAN Feature Description

Huawei Technologies Proprietary

RAN Feature Description

Chapter 16 PDCP Header Compression

Chapter 16 PDCP Header Compression

Transfer of packet data

Header compression and decompression of IP data streams

Lossless SRNS relocation

The general process of PDCP header compression is as follows:

The redundant protocol headers are compressed before being transmitted on a

I. Reducing Header Overhead

II. Shortening Response Time

Huawei Technologies Proprietary

RAN Feature Description

Chapter 16 PDCP Header Compression

III. Reducing Packet Loss Rate

16.1.3 Terms and Abbreviations

The act of reducing the size of a header by removing header

The act of restoring the original header.

A small unique number that identifies the context used to

decompress a compressed header.

A bit string that the compressor uses to compress a header and

A number that is incremented whenever the context with a

Huawei Technologies Proprietary

RAN Feature Description

Chapter 16 PDCP Header Compression

An uncompressed header that updates or refreshes the context

An uncompressed header that carries neither a CID nor a

A situation where a decompressed header is different from the

header before compression.

A compression technique where the compressed value of a

header field is the difference between the current value of the

Data are forwarded by multiple uncertain routers before reaching

Average Revenue Per User

Bit Error Rate

File Transfer Protocol

Gateway GPRS Support Node

General Packet Radio Service

Huawei Technologies Proprietary

RAN Feature Description

Chapter 16 PDCP Header Compression

Global System for Mobile communications

GPRS Tunneling Protocol for User Plane

Internet Protocol version 4

Internet Protocol version 6

Maximum Transfer Unit

Packet Data Convergence Protocol

Radio Access Bearer

Request For Comments

Radio Link Control

Radio Network Controller

Real-Time Transport Protocol

Round Trip Time

Service Access Point

Service Data Unit

Serving GPRS Support Node

Transmission Control Protocol

User Datagram Protocol

UMTS Terrestrial Radio Access Network

Wideband Code Division Multiple Access