LTE PDCP from eNodeB perspective

Packet Data Convergence Protocol (PDCP) is one of the User plane protocols in LTE. It is present in UE and eNodeB.  This protocol sends and receives packets to and from UE and eNodeB over air interface. This protocol works along with other L2 protocols RLC  (Radio Link Control) and MAC (Medium Access Control).

PDCP layer works on top of RLC and it transfers the UPLINK packets to the GTP layer which in turn tunnel the packets to core network (Evolved Packet Core - EPC).   It receives the downlink packets from GTP layer and send them onto RLC which in turn sends them to UE. That is PDCP layer sits in between RLC and GTP layers.

This particular post talks about PDCP layer details in eNodeB.  PDCP is user plane protocol. Control plane protocol RRC configures the PDCP entities in the user plane.

PDCP layer is described in 3GPP 36.323 standard.

PDCP functions : 

PDCP layer is expected to do following:

• Security function over the air interface :  
• Ciphering and Deciphering of user plane and control plane data.
• Integrity protection and verification for control plane data:  Note that there is no integrity protection offered to the user plane data.
• Sequence number is used to detect anti replays.
• Header compression and decompression for user plane data:  Note that there is no header compression for control plane data.  ROHC (RFC 4995) is used to reduce the headers to save bandwidth of air interface. ROHC is mandatory for voice traffic.  Note that in LTE, both voice and data use packet switching.  Typically for every 32 bytes of voice data around 40 bytes of headers are added (RTP, UDP, IP) in case of IPv4 and around 60 bytes get added in case of IPv6. That is quite a bit of overhead.  ROHC is expected to reduce the over head to few bytes.  For data traffic, ROHC is not mandatory, but it is good to have.
• Handover :  As discussed in earlier post  there are two types of handovers - seemless and lossless.  Seemless handover is typically used for radio bearers carrying control plane data and user plane data that is mapped to RLC UM (Unacknowledged mode).  In seemless handover,  header compression contexts are reset and Sequence numbers (COUNT) values are set to 0 in the target eNB.  PDCP SDUs that have not been transmitted will be sent to the X2 interface (S1 interface in case there is no X2 connectivity)  GTP tunnel to the target eNB.   Lossless handover is typically applied to the radio bearers that are mapped to RLC AM.  In this handover mode too,  header compression context is reset, that is,  ROHC context is not transferred to the target eNB. In lossless handover pending downlink packets -  PDCP SDUs for which no Acks are received from UE,  PDCP SDU which were not transmitted and new GTP packets that are coming from S1 interface in source eNB - are sent to the target eNB.  Similarly, uplink packets which are received out-of-order also sent to the target eNB. Control plane in source eNB sends the 'Next Transmit Seq num' and 'Next expected receive sequence number' to the target eNB for each RAB.  Optionally it also sends the bit map of PDCP sequence numbers of the packet which it would expect UE to retransmit.  This information is passed to the the target eNB via SN-STATUS-TRANSFER.  I guess this information would be used by target eNB PDCP to send the PDCP status transfer control message.
• Discard function :  This allows packets to be discarded if PDCP layer did not successfully send the packets for 'discard timeout' time.  
• Duplicate discarding : If PDCP layer receives duplicate packets (packets with same sequence number), the it discards them and does not send them to upper layers.

Some points to note :

PDCP specification goes in great lengths on PDCP data transfer procedures and details out internal implementation such as state variables to be maintained for received and transmit operations. These state variables are used to assign sequence numbers during transmit time and verify/discard/send up the packets which are received from RLC layer.  I will not go into those details here as the specification is very clear on them.  One thing to note is that these procedures are described from UE context. Same are valid for eNB PDCP implementation too. But note that UE PDCP transmits the UL packets to RLC  and receives DL packets from RLC.  In case of eNodeB,  PDCP layer transmits DL packets to RLC  and receives UL packet from RLC.  So, keep in mind while going through spec document.

There are two kinds of PDCP bearers:  SRB (Signalling Radio Bearer) and DRB (Dedicated Radio Bearer). There are only two SRBs - SRB1 and SRB2.  These are used by control plane protocol to send the packets to the UE.  DRBs are used for sending voice and data.  There would be as many DRBs as number of QoS streams.

There are two kinds of packets in PDCP -  Data packets and Control packets. Packets that are sent on  SRBs and DRBs use data packet format. Control packets are used by ROHC to provide feedback to the compressors from decompressors.  Control packets are also used by PDCP layer to send the PDCP sequence number status to the peer (Packet sequence numbers that are received out-of-order).  

As discussed before sequence numbers are sent along with the data packets to the  peer to do the in-order delivery of packets to its user entity.  To preserve the the bandwidth on the air, only least significant bits of sequence number is sent.  Most significant bits are called HFN.  Based on the window size, there are two sizes are chosen for sequence number that are sent along with the packet - 7 bits (User plane Short SN)  and 12 bits (User plane long SN). Typically short SN is used for UM mode and long SN is used for AM mode.

There is one PDCP context for radio bearer. PDCP context is identified by four tuples - Virtual Instance ID,  Sector ID,  C-RNTI and LCI (logical channel identifier). Please see this post for more details on virtual instance ID and sector ID.  Both sides of PDCP - RLC and GTP - would use same identifiers to identify the PDCP context. Hence only one search table is good enough (Implementation information).

There is one to one correspondence between PDCP SDU and PDCP PDU. That is there is no segmentation and concatenation functions in PDCP layer.  Addition of PDCP header,  applying compression and security on the PDCP SDU makes the PDCP PDU.  Similary deciphering, decompression and removal of PDCP header makes PDCP SDU from PDCP PDU.

PDCP Status report is expected to be generated as part of PDCP reestablishment if the RB is setup to send the status report. This report is sent for PDCP PDUs that are received from RLC (UPlink packets).  Fields that are to be sent along with the status report is described in section 5.3.1 of 36.323 spec.

PDCP Layer in eNB also may receive the PDCP Status report from the UE indicating out-of-order packets it had received. PDCP layer is expected to work on removing the PDCP SDUs that are pending in the transmit queue and acknowledged by the peer via status transfer message.  Also, it is expected to send the status report to control plane as CP may require to send to the target eNB if it is in handover stage for that UE.

I always wondered how and when PDCP generates the status reports. From the UL & DL Data transfer procedures in Section 5.1 of 36.323,  one can observe that the PDCP PDU on receive direction (from RLC) don't get stored in PDCP layer.  They are given to the upper layers immediately after Security and RoHC processing.  PDCP layer assumes that the packets are given in order by the RLC and hence don't need to store the packets to do inorder delivery to the upper layers.  Description of "PDCP Status Report" in section 5.3 of 36.323 says that status report is sent for the PDUs which were received out-of-order. It gives an impression that packets are stored in the PDCP layer for inorder delivery to the upper layers.  If not, how does PDCP layer send the bit map indications of the out-of-order packets.  So, I thought section 5.1 and section 5.3 are contradictory.  Then there is some enlightenment.  This only happens during PDCP reestablishment time.  Control plane protocols when they indicate reestablishment to the local RLC,  RLC layer sends the PDCP PDUs (RLC SDUs) it has to the PDCP layer as is basis. That is, there could be some missing packets at that time.  THis is only case, PDCP layer gets  the packets with some missing PDCP PDUs.  PDCP layer is also informed of reestablishment by the control plane.  PDCP upon receiving the packets from RLC layer is expected to send the status report to the peer with bitmap of packet sequence numbers so that the peer PDCP can remove the SDUs at its transmit side that were acknowledged in the status message.

I also had some confusion on PDCP discard for some time.  PDCP specification says that (Section 5.4 of 36.323) timer is started for every packet that is submitted to the PDCP layer by upper layers. If there is no successful transmission acknowledgment from the local RLC for the packet within 'discardTimer' timeout value, then PDCP can drop the packet.  I was thinking for some time that how does remote PDCP layer know about this drop. I thought remote peer waits on the packet (sequence number) endlessly . But from UL/DL data transfer procedures, it is clear that PDCP receiver does not wait on any missing sequence number packet as its window keeps moving right.

PDCP Interfaces:

PDCP layer interfaces with three neighboring modules -  RRC control plane,  RLC and GTP.  Ofcourse, there is initialization, configuration, monitoring etc.. Following sections describe the interface with RRC, RLC and GTP.

RRC to PDCP interface :  Following interface would need to be exposed by PDCP user plane layer to the RRC in control plane.

•  Interface to create PDCP Contexts for SRB and DRB in PDCP layer :  Parameters for this function at high level are:
• Virtual Instance ID,  Sector ID, C-RNTI (Cell - Radio network Temporary Identifier).
• LCI (logical channel identifier).
• Reference to the control plane:  Some opaque information to pass along with indications to the control plane.
• SRBOrDRB boolean flag
• If SRB:
• Unacknowledged or Acknowledged Mode
• If it is Unacknowledged, then the direction of the packets (Transmit only, Receive only or both).  In acknowledged mode, it is assumed that the directios is 'Both' always.
• Integrity Information (Y/N)
• Algorithm 
• Key
• Cipher information (Y/N):
• Algorithm
• Key.
• There is no RoHC for SRB.
• Sequence number size is not configured for SRB by RRC. Use configuration 'Default SN Size for SRBs' to find the sequence number size.
• If DRB:
•  Active/Inactive:  Normally it is active. But in handover cases,  target eNB might create the PDCP context as part of Handover preparation and program the PDCP starting TX sequence number and Receive expected sequence number and Bit map when the X2 protocols sends SN_STATUS_TRANSFER message (Refer to 36.300 Figure 10.1.2.1.1-1:  Intra MME/Service Gateway HO).  Since these two events happen at different times, it is required that PDCP does not start processing the packets until PDCP sequence numbers are known to it.  To facilitate this, I believe control plane first creates the PDCP context in 'Inactive' mode and activates it at later time using some other API function.  If PDCP receives the SDUs from the upper layer while it is inactive, it is expected to hold them from processing until it is activated. 
• Unacknowledged or Acknowledged Mode
• If it is Unacknowledged, then the direction of the packets (Transmit only, Receive only or both).  In acknowledged mode, it is assumed that the directios is 'Both' always.
  
• Integrity Information is not valid for DRB packets.
• Cipher information (Y/N):
• Algorithm
• Key.
• RoHC (Y/N)
• Profile IDs:  Bit mask of compression profiles (RTP/UDP/IP,  UDP/IP,  ESP/IP, IP, TCP/IP , v2 RTP/UDP/IP, v2 UDP/IP, v2 ESP/IP and v2 IP)
• maxCID:  Maximum flows.  
• Large CID is derived from the max CID.  If maxCID > 15, large_cid is true else large_cid is false.
• Sequence number size : 5 bits, 7 bits and 12 bits.
• Handover case:  if this PDCP context is established in target eNB, it also sends the PDCP sequence numbers and Bit map of packets that were not received by source eNB.
•  Interface to terminate PDCP contexts :  I am not sure whether there is any need to provide deletion of each individual bearer.  I have a feeling control plane does not delete each one of them.  So, it is required to have terminate bearer function for all bearers belonging to UE.  Parameters:
• Virtual Instance ID,  Sector ID, C-RNTI
• Interface to prepare PDCP context for re-establishment:  As part of this, PDCP is expected to wait for the packets sent by RLC which came in out-of-order from UE.  These packets would be processed and given to GTP-U.
• Interface to set PDCP reestablishment on per SRB and DRB basis in PDCP layer :  This interface function is expected to be called by control plane when it requires reestablishment of PDCP context.  This function is expected to send PDCP status transfer message to the UE and also it is expectedt set the Cipher and integrity information to the context. If there are any pending DL packets, they get retransmitted with new cipher context. Parameters:
• Virtual Instance ID, Sector ID, C-RNTI, LCI to identify the bearer.
•  Cipher Information (Y/N): As part of reestablishment new keys may be established.
• Algorithm
• Key
• In case of SRB, integrity information (Y/N):
• Algorithm
• Key 
• Please refer to the Section 5.2 of 36.323 to understand how to setup transmit and receive sequence number for different modes.
• ROHC context is reset if it is applicable.

•  Interface to indicate the handover of  DRBs:  This function is expected to be called by control plane in the source eNB as part of handover execution phase.  When the PDCP layer gets this indication from the control plane, it should start forwarding the un-acknowledged downlink packets and uplink packets that are received out-of-order. It is expected that this function is called by control plane after it instructs (re-establishment) RLC. 
•  Interface to send control messages via SRBs:  SRBs are used by control plane. This function can be called by control plane to send the packets on SRB.

PDCP to RRC interface: 

•  Interface to inform RRC of received Status Transfer message from peer : Using this interface point, PDCP informs the content of status transfer message to the control plane.  It sends the 'Reference information' that was set in the PDCP context by control plane during PDCP context creation. It helps control plane to corelate its context easily. Information from this indication would be used by RRC during handover execution phase.
•  Interface to inform SRB data indications : This interface function gives the messages received on SRB from peer PDCP to the control plane.

PDCP to RLC interface:

• Interface to send PDCP PDUs including PDCP control and data PDUs :  This interface point is needed to send the PDCP PDU to RLC.  RLC also uses same identification parameter to match its context as PDCP does. Parameters include Bearer identificatio (Virtual instance ID,  Sector ID, C-RNTI, LCI), PDCP PDU packet buffer and message ID.  It is expected that message ID is returned when the RLC calls ack function to provide success & failure of delivery.  It helps PDCP implementation to find the matching SDU, stop the discard timer and remove the entry.

RLC to PDCP interface :

• Interface to indicate the new PDCP PDUs (new packets) - Multiple of them:  This function can be used by RLC to give PDCP PDUs to the PDCP layer.   Multiple packets can be given at one time.  RLC might be buffering the packets if they come in out-of-order. When the missing packet comes along,  All those packets can be given at once. 
• Interface to indicate the pending PDCP PDUs - During reestablishment time (Multiple packets can be sent using one call) :  This function can be used by RLC to give pending PDCP PDUs in the RLC.  Along with the last packet, it can indicate that it is last packet. 
• Interface to indicate acknowledgment of PDU sent using PDCP to RLC interface functions :  This function is expected to be used by RLC to give success/failure ack to the PDCP PDUs that were sent to the RLC before.

PDCP to GTP interface:

• Interface to send PDCP SDUs to the GTP : This function is used by PDCP to give PDCP SDU (IP packet) to the GTP layer.
• Interface to send Downlink forwarding packets (Upon handover) to the GTP layer & Interface to send Uplink forwarding packets (Upon handover) to the GTP layer:  This function is called when the PDCP layer is informed of handover for a given context.  Both UL and DL packets are to be sent along with sequence number to the GTP. Last packet is expected to be indicated explicitly.  Since GTP waits for the last packet indication,  it is necessary that GTP is informed of 'no more packets indication' even if there are no packets to forward to target eNB.

GTP to PDCP interface:

• Interface for GTP layer to send new packets to the PDCP layer in downlink direction :  This function is called by PDCP upper layers to send the packets to PDCP.
• Interface for GTP layer to send DL-forwarded packets (During handover) & Interface for GTP layer to send UL-forwarded packets (During handover) : THis function is normally called in target eNB during handover execution phase.  These packets are sent to the PDCP layer with the sequence number. 

I have written this description based on my understanding of PDCP specifications. If somebody finds any inconsistency or if i had made any mistakes, please drop a comment or send an email.