PDCP

Packet Data Convergence Protocol

 Introduction
• The Packet Data Convergence Protocol (PDCP) layer :
This layer processes Radio Resource Control (RRC) messages in the
control plane and Internet Protocol (IP) packets in the user plane.
There is one PDCP entity per radio bearer.

• Each layer receives a Service Data Unit (SDU) from a higher

layer, for which the layer provides a service, and outputs a
Protocol Data Unit (PDU) to the layer below.
 PDCP Functions
• Header Compression and decompression for user plane data.

• Security Functions:
- Ciphering and deciphering for user & control plane data.
- Integrity protection and verification for control plane data

• Handover Support Functions:

- Seamless Handover
- Lossless Handover

• Discard for user plane data due to timeout

 Architecture – For (User - Plane PDCP)
PDCP SDUs

Retransmission
buffer

PDCP
Numbering Reordering buffer
layer

ROHC Protocol
ROHC Compressor ROHC De-Compressor

Compressed Deciphering
PDCP SDUs Ciphering
ROHC
feedback
Determining
ROHC COUNT
feedback
Adding the PDCP Treating the PDCP
header header
PDCP PDUs
 For Control-Plane PDCP
PDCP SDUs

Verification of
Numbering
integrity

Calculation of
Deciphering
MAC-I

Ciphering Determining
COUNT

PDCP PDUs
 1.Header Compression
• Header compression using the Robust Header Compression
(ROHC) protocol defined by the IETF
• Header compression is very important because there is no
support for the transport of voice services via the Circuit-
Switched (CS) domain.
• To compress the IP/UDP/RTP header which is typically used
for Voice over IP (VoIP) services.
• UEs which support VoIP have to support at least one profile
for compression of RTP, UDP and IP
• ROHC header compression operates by allowing both the
sender and the receiver to store the static parts of the header
(e.g. the IP addresses of the sender/receiver), and to update
these only when they change.
Supported header compression protocols.

Reference Usage

RFC 4995 No compression

RFC 3095, RFC 4815 RTP/UDP/IP
RFC 3095, RFC 4815 UDP/IP
RFC 3095, RFC 4815 ESP/IP
RFC 3843, RFC 4815 IP
RFC 4996 TCP/IP
RFC 5225 RTP/UDP/IP
RFC 5225 UDP/IP
RFC 5225 ESP/IP
RFC 5225 IP
• The most important use case for ROHC is VoIP.

• for the transport of a VoIP packet which contains a payload of

32 bytes, the header added will be 60 bytes for the case of
IPv6 and 40 bytes for the case of IPv4 – i.e. an overhead of
188% and 125% respectively.

• Overhead can be compressed to four to six bytes.

 2.Security
• The implementation of security, by ciphering (of both control
plane (RRC) data and user plane data) and integrity protection
(for control plane (RRC) data only), is the responsibility of the
PDCP layer.
• A PDCP Data PDU counter (known as ‘COUNT’ in the LTE
specifications) is used as an input to the security algorithms.
• The COUNT value increments for each PDCP Data PDU during
an RRC connection; it has a length of 32 bits in order to allow
an acceptable duration for an RRC connection.
• Loss of synchronization occurring could be minimized by
increasing the length of SN.
• The actual SN length depends on the configuration and type
of PDU.
• Replay Attack: where the attacker tries to resend a packet that
has been intercepted previously
• The use of the COUNT value also provides protection against
attacks.
• Integrity protection is realized by adding a field known as
‘Message Authentication Code for Integrity’ (MAC-I) to each
RRC message.

• MAC-I = AS keys + The message itself + Radio bearer ID + The

direction + COUNT value
• If the integrity check fails, the message will be
discarded and treated as if it had not been
received.
• Ciphering is realized by performing an XOR
operation with the message and a ciphering
stream
• Ciphering can only be applied to PDCP Data
PDUs. Control PDUs (such as ROHC feedback
or PDCP status reports) are neither ciphered
nor integrity protected.
 Ciphering Stream
• AS Keys + Radio Bearer ID + the direction+
Count value Ciphering algorithm
Ciphering Stream
 3.Hand Over
• Handover is performed when the UE moves
from the coverage of one cell to the coverage
of another cell.
Seamless Handover
Lossless Handover
• Seamless Handover

It is applied to all radio bearers carrying control plane

and user plane radio bearers (RLC UM).
Seamless handover is designed to minimize complexity
(because no context has to be transferred b/w the source
and target Enb at handover) and delay , but may result in
loss of some SDUs.
At handover, for radio bearers to which seamless
handover applies, the PDCP entities including the header
compression contexts are reset, and the COUNT values
are set to zero.
• Loss Less Handover:

This lossless handover function is used mainly for delay-

tolerant services.
Lossless handover is applied for radio bearers that are
mapped on RLC Acknowledged Mode (AM).
For lossless handover, the header compression protocol is
reset in the UE because the header compression context is
not forwarded from the source eNodeB to the target eNodeB.
In normal transmission while the UE is not handing over from
one cell to another, the RLC layer in the UE and the eNodeB
ensures in-sequence delivery.
In Handover cases eNodeB Wont forward RLC context to
Target eNodeB but PDCP context.
 Lossless handover in the uplink.

Gateway

3
1 4
5
2
6
4
Source EnodeB Target EnodeB

Packets 1 3
Packets3 and 4are
1,2,3,4 and 5 2 4
Acknowledged retransmitted.alth
have been
3 packets 1and 2 5 ough packet 4 has
transmitted
4 6 already been
received
5
UE Handover UE

1 2 3 4 5 6 3 4 5 6
 Lossless handover in the downlink.
Gateway

LP 10
5 9
4 8
3 Indicates “last
packets” 7
2
6
1
LP 5 4 3
Source EnodeB Target EnodeB

Packets 1,2,3 4 6
Packets3 and 4are
and 4 have 3 5
Acknowledged retransmitted.alth
been 4
2 packets 1and 2 ough packet 4 has
transmitted 3
1 already been
received
4

2 UE Handover UE
1

Packets 1,2 and 4 are received

 Discard of Data Packets
• The data rate that is available on the radio interface is smaller
than the data rate available on the network interfaces.
• when the data rate of a given service is higher than the data
rate provided by the LTE radio interface, this leads to buffering
in the UE and in the eNodeB.
• Due to the buffering, the variations in the instantaneous data
rate are then seen by the application only as some jitter in the
transfer delay.
• This may lead to a large loss of data at handover if lossless
handover is not applied to the bearer, or to an excessive delay
for real time applications.
• when the data rate of an application exceeds the available
data rate in a part of the internet.
• An application may then detect this loss of packets and adapt
its data rate to the available data rate.
 PDCP PDU Formats

• PDCP PDUs for user plane data comprise a

‘D/C’ field in order to distinguish Data and
Control PDUs.

D/C PDCP SN Data MAC-I

Key features of PDCP Data PDU format.

 PDCP Data PDU formats.

Sequence
PDU type D/C field MAC-I Applicable RLC Modes
number length

User plane long SN Present 12 bits Absent AM / UM

User plane short SN Present 7 bits Absent UM

Control plane Absent 5 bits 32 bits AM / UM

Interspersed ROHC feedback /

D/C PDU type
PDCP status report

Key features of PDCP Control PDU format.