ETSI TS 138 323 V16.8.0 (2023-01)
5G; NR; Packet Data Convergence Protocol (PDCP) specification (3GPP TS 38.323 version 16.8.0 Release 16)
5G; NR; Packet Data Convergence Protocol (PDCP) specification (3GPP TS 38.323 version 16.8.0 Release 16)
RTS/TSGR-0238323vg80
General Information
Standards Content (Sample)
TECHNICAL SPECIFICATION
5G;
NR;
Packet Data Convergence Protocol (PDCP) specification
(3GPP TS 38.323 version 16.8.0 Release 16)
3GPP TS 38.323 version 16.8.0 Release 16 1 ETSI TS 138 323 V16.8.0 (2023-01)
Reference
RTS/TSGR-0238323vg80
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2023.
All rights reserved.
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 2 ETSI TS 138 323 V16.8.0 (2023-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 3 ETSI TS 138 323 V16.8.0 (2023-01)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
1 Scope . 6
2 References . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 General . 8
4.1 Introduction . 8
4.2 Architecture . 8
4.2.1 PDCP structure . 8
4.2.2 PDCP entities . 9
4.3 Services . 10
4.3.1 Services provided to upper layers . 10
4.3.2 Services expected from lower layers . 10
4.4 Functions . 11
5 Procedures . 11
5.1 PDCP entity handling . 11
5.1.1 PDCP entity establishment . 11
5.1.2 PDCP entity re-establishment . 11
5.1.3 PDCP entity release . 13
5.1.4 PDCP entity suspend . 13
5.1.5 PDCP entity reconfiguration . 13
5.2 Data transfer . 14
5.2.1 Transmit operation . 14
5.2.2 Receive operation . 15
5.2.2.1 Actions when a PDCP Data PDU is received from lower layers . 15
5.2.2.2 Actions when a t-Reordering expires . 16
5.2.2.3 Actions when the value of t-Reordering is reconfigured . 17
5.2.3 Sidelink transmit operation . 17
5.2.4 Sidelink receive operation . 17
5.3 SDU discard . 17
5.4 Status reporting . 17
5.4.1 Transmit operation . 17
5.4.2 Receive operation . 18
5.5 Data recovery . 18
5.6 Data volume calculation . 18
5.7 Robust header compression and decompression . 19
5.7.1 Supported header compression protocols and profiles . 19
5.7.2 Configuration of ROHC . 20
5.7.3 Protocol parameters . 20
5.7.4 Header compression using ROHC . 20
5.7.5 Header decompression using ROHC . 21
5.7.6 PDCP Control PDU for interspersed ROHC feedback . 21
5.7.6.1 Transmit Operation . 21
5.7.6.2 Receive Operation . 21
5.8 Ciphering and deciphering . 21
5.9 Integrity protection and verification . 22
5.10 Handling of unknown, unforeseen, and erroneous protocol data . 23
5.11 PDCP duplication . 23
5.11.1 Activation/Deactivation of PDCP duplication . 23
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 4 ETSI TS 138 323 V16.8.0 (2023-01)
5.11.2 Duplicate PDU discard . 24
5.12 Ethernet header compression and decompression . 24
5.12.1 Supported header compression protocols . 24
5.12.2 Configuration of EHC . 24
5.12.3 Protocol parameters . 24
5.12.4 Header compression using EHC . 24
5.12.5 Header decompression using EHC . 25
5.12.6 PDCP Control PDU for EHC feedback . 25
5.12.6.1 Transmit Operation . 25
5.12.6.2 Receive Operation . 25
5.12.7 Simultaneous configuration of ROHC and EHC . 25
5.13 Uplink data switching . 25
6 Protocol data units, formats, and parameters . 26
6.1 Protocol data units . 26
6.1.1 Data PDU . 26
6.1.2 Control PDU . 26
6.2 Formats . 26
6.2.1 General . 26
6.2.2 Data PDU . 27
6.2.2.1 Data PDU for SRBs . 27
6.2.2.2 Data PDU for DRBs with 12 bits PDCP SN . 27
6.2.2.3 Data PDU for DRBs with 18 bits PDCP SN . 28
6.2.2.4 Data PDU for sidelink DRBs for groupcast and broadcast and for the sidelink SRB0 . 28
6.2.2.5 Data PDU for sidelink SRBs for unicast . 29
6.2.2.6 Data PDU for sidelink DRBs for unicast with 12 bits PDCP SN . 29
6.2.2.7 Data PDU for sidelink DRBs for unicast with 18 bits PDCP SN . 30
6.2.3 Control PDU . 31
6.2.3.1 Control PDU for PDCP status report . 31
6.2.3.2 Control PDU for interspersed ROHC feedback . 32
6.2.3.3 Control PDU for EHC feedback. 32
6.3 Parameters . 32
6.3.1 General . 32
6.3.2 PDCP SN . 32
6.3.3 Data . 33
6.3.4 MAC-I . 33
6.3.5 COUNT . 33
6.3.6 R . 33
6.3.7 D/C. 33
6.3.8 PDU type . 34
6.3.9 FMC . 34
6.3.10 Bitmap . 34
6.3.11 Interspersed ROHC feedback . 34
6.3.12 SDU Type . 34
6.3.13 K ID . 34
NRP-sess
7 State variables, constants, and timers . 35
7.1 State variables . 35
7.2 Constants . 35
7.3 Timers . 36
Annex A (normative): Ethernet Header Compression (EHC) protocol . 37
A.1 EHC principle . 37
A.2 EHC packet format and parameters . 38
A.2.1 EHC packet format . 38
A.2.1.1 EHC Full Header packet and EHC Compressed Header packet . 38
A.2.1.2 EHC feedback packet . 39
A.2.2 Parameters. 39
A.2.2.1 F/C. 39
A.2.2.2 CID . 39
Annex B (informative): Change history . 40
History . 41
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 5 ETSI TS 138 323 V16.8.0 (2023-01)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 6 ETSI TS 138 323 V16.8.0 (2023-01)
1 Scope
The present document provides the description of the Packet Data Convergence Protocol (PDCP).
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 38.300: "NG Radio Access Network; Overall description".
[3] 3GPP TS 38.331: "NR Radio Resource Control (RRC); Protocol Specification".
[4] 3GPP TS 38.321: "NR Medium Access Control (MAC) protocol specification".
[5] 3GPP TS 38.322: "NR Radio Link Control (RLC) protocol specification".
[6] 3GPP TS 33.501: "Security Architecture and Procedures for 5G System ".
[7] IETF RFC 5795: "The RObust Header Compression (ROHC) Framework".
[8] IETF RFC 3095: "RObust Header Compression (ROHC): Framework and four profiles: RTP,
UDP, ESP and uncompressed".
[9] IETF RFC 4815: "RObust Header Compression (ROHC): Corrections and Clarifications to RFC
3095".
[10] IETF RFC 6846: "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)".
[11] IETF RFC 5225: "RObust Header Compression (ROHC) Version 2: Profiles for RTP, UDP, IP,
ESP and UDP Lite".
[12] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access
Control (MAC) protocol specification".
[13] 3GPP TS 23.287: "Architecture enhancements for 5G System (5GS) to support Vehicle-to-
Everything (V2X) services".
[14] 3GPP TS 33.536: "Security Aspect of 3GPP Support for Advanced V2X Services".
[15] IEEE Standard 802.3™-2018: "Ethernet".
[16] 3GPP TS 24.587: "Vehicle-to-Everything (V2X) services in 5G System (5GS), Stage 3".
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 7 ETSI TS 138 323 V16.8.0 (2023-01)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
AM DRB: a data radio bearer which utilizes RLC AM.
DAPS bearer: a bearer whose radio protocols are located in both the source gNB and the target gNB during DAPS
handover to use both source gNB and target gNB resources.
Non-split bearer: a bearer whose radio protocols are located in either the MgNB or the SgNB to use MgNB or SgNB
resource, respectively.
NR sidelink communication: AS functionality enabling at least V2X communication as defined in TS 23.287 [13],
between two or more nearby UEs, using NR technology but not traversing any network node.
PDCP data volume: the amount of data available for transmission in a PDCP entity.
Split bearer: in dual connectivity, a bearer whose radio protocols are located in both the MgNB and the SgNB to use
both MgNB and SgNB resources.
Split secondary RLC entity: in dual connectivity, the RLC entity other than the primary RLC entity which is
responsible for split bearer operation. If the PDCP entity is associated with two RLC entities, the split secondary RLC
entity is the RLC entity other than the primary RLC entity. If the PDCP entity is associated with more than two RLC
entities, the split secondary RLC entity is configured by upper layers.
UM DRB: a data radio bearer which utilizes RLC UM.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
AM Acknowledged Mode
CID Context Identifier
DAPS Dual Active Protocol Stack
DRB Data Radio Bearer carrying user plane data
EHC Ethernet Header Compression
gNB NR Node B
HFN Hyper Frame Number
IETF Internet Engineering Task Force
IP Internet Protocol
MAC Medium Access Control
MAC-I Message Authentication Code for Integrity
PDCP Packet Data Convergence Protocol
PDU Protocol Data Unit
RB Radio Bearer
RFC Request For Comments
RLC Radio Link Control
ROHC RObust Header Compression
RRC Radio Resource Control
RTP Real Time Protocol
SAP Service Access Point
SCCH Sidelink Control Channel
SDU Service Data Unit
SLRB Sidelink Radio Bearer carrying NR sidelink communication
SN Sequence Number
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 8 ETSI TS 138 323 V16.8.0 (2023-01)
SRB Signalling Radio Bearer carrying control plane data
STCH Sidelink Traffic Channel
TCP Transmission Control Protocol
UDP User Datagram Protocol
UE User Equipment
UM Unacknowledged Mode
X-MAC Computed MAC-I
4 General
4.1 Introduction
The present document describes the functionality of the PDCP.
4.2 Architecture
4.2.1 PDCP structure
Figure 4.2.1.1 represents one possible structure for the PDCP sublayer; it should not restrict implementation. The figure
is based on the radio interface protocol architecture defined in TS 38.300 [2].
Figure 4.2.1-1: PDCP layer, structure view
The PDCP sublayer is configured by upper layers TS 38.331 [3]. The PDCP sublayer is used for RBs mapped on
DCCH, DTCH, SCCH, and STCH type of logical channels. The PDCP sublayer is not used for any other type of logical
channels.
Each RB (except for SRB0 for Uu interface) is associated with one PDCP entity. Each PDCP entity is associated with
one, two, three, four, six, or eight RLC entities depending on the RB characteristic (e.g. uni-directional/bi-directional or
split/non-split) or RLC mode:
- For split bearers, each PDCP entity is associated with two UM RLC entities (for same direction), four UM RLC
entities (two for each direction), or two AM RLC entities;
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 9 ETSI TS 138 323 V16.8.0 (2023-01)
- For RBs configured with PDCP duplication, each PDCP entity is associated with N UM RLC entities (for same
direction), 2 × N UM RLC entities (N for each direction), or N AM RLC entities, where 2 <= N <= 4;
- For DAPS bearers, each PDCP entity is associated with two UM RLC entities (for same direction, one for source
and one for target cell), four UM RLC entities (two for each direction on source cell and target cell), or two AM
RLC entities (one for source cell and one for target cell);
- Otherwise, each PDCP entity is associated with one UM RLC entity, two UM RLC entities (one for each
direction), or one AM RLC entity.
4.2.2 PDCP entities
The PDCP entities are located in the PDCP sublayer. Several PDCP entities may be defined for a UE. Each PDCP
entity is carrying the data of one radio bearer. A PDCP entity is associated either to the control plane or the user plane
depending on which radio bearer it is carrying data for.
Figure 4.2.2.1 represents the functional view of the PDCP entity for the PDCP sublayer; it should not restrict
implementation. The figure is based on the radio interface protocol architecture defined in TS 38.300 [2].
For split bearers and DAPS bearers, routing is performed in the transmitting PDCP entity.
A PDCP entity associated with DRB can be configured by upper layers TS 38.331 [3] to use header compression. In
this version of the specification, the robust header compression protocol (ROHC) and the Ethernet header compression
protocol (EHC) are supported. Each header compression protocol is independently configured for a DRB.
Figure 4.2.2-1: PDCP layer, functional view
ETSI
Packets not
associated to a
PDCP SDU
Packets not
associated to a
PDCP SDU
Packets not
associated to a
PDCP SDU
Packets not
associated to a
PDCP SDU
3GPP TS 38.323 version 16.8.0 Release 16 10 ETSI TS 138 323 V16.8.0 (2023-01)
Figure 4.2.2-2 represents the functional view of the PDCP entity associated with the DAPS bearer for the PDCP
sublayer; it should not restrict implementation. The figure is based on the radio interface protocol architecture defined
in TS 38.300 [2].
For DAPS bearers, the PDCP entity is configured with two sets of security functions and keys and two sets of header
compression protocols.
UE
UE
Transmitting PDCP entity Receiving PDCP entity
Transmission buffer: Sequence numbering
Header Decompression Header Decompression
Header Compression Header Compression
Packets associated Packets associated
to a PDCP SDU to a PDCP SDU
Packets associated Packets associated
to a PDCP SDU to a PDCP SDU
Reception buffer:
Integrity Protection Integrity Protection
Reordering, duplicte discarding
Ciphering Ciphering Integrity Verification Integrity Verification
Add PDCP header Deciphering Deciphering
Routing Remove PDCP Header
Radio Interface (Uu)
Figure 4.2.2-2: PDCP layer associated with DAPS bearer, functional view
4.3 Services
4.3.1 Services provided to upper layers
The PDCP layer provides its services to the RRC or SDAP layers. The following services are provided by PDCP to
upper layers:
- transfer of user plane data;
- transfer of control plane data;
- header compression;
- ciphering;
- integrity protection.
The maximum supported size of a PDCP SDU is 9000 bytes. The maximum supported size of a PDCP Control PDU is
9000 bytes.
4.3.2 Services expected from lower layers
A PDCP entity expects the following services from lower layers per RLC entity (for a detailed description see TS
38.322 [5]):
- acknowledged data transfer service, including indication of successful delivery of PDCP PDUs;
- unacknowledged data transfer service.
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 11 ETSI TS 138 323 V16.8.0 (2023-01)
4.4 Functions
The PDCP layer supports the following functions:
- transfer of data (user plane or control plane);
- maintenance of PDCP SNs;
- header compression and decompression using the ROHC protocol;
- header compression and decompression using the EHC protocol;
- ciphering and deciphering;
- integrity protection and integrity verification;
- timer based SDU discard;
- for split bearers and DAPS bearer, routing;
- duplication;
- reordering and in-order delivery;
- out-of-order delivery;
- duplicate discarding.
5 Procedures
5.1 PDCP entity handling
5.1.1 PDCP entity establishment
When upper layers request a PDCP entity establishment for a radio bearer for Uu or PC5 interface; or for NR sidelink
communication for groupcast and broadcast, when receiving the first PDCP PDU, and there is not yet a corresponding
PDCP entity, the UE shall:
- establish a PDCP entity for the radio bearer;
- set the state variables of the PDCP entity to initial values;
- follow the procedures in clause 5.2.
NOTE: The receiving PDCP entity of sidelink SRB0 and sidelink SRB1 is established same as NR sidelink
groupcast and broadcast.
5.1.2 PDCP entity re-establishment
When upper layers request a PDCP entity re-establishment, the UE shall additionally perform once the procedures
described in this clause for Uu or PC5 interface. After performing the procedures in this clause, the UE shall follow the
procedures in clause 5.2.
When upper layers request a PDCP entity re-establishment, the transmitting PDCP entity shall:
- for UM DRBs and AM DRBs, reset the ROHC protocol for uplink and start with an IR state in U-mode (as
defined in RFC 3095 [8] and RFC 4815 [9]) if drb-ContinueROHC is not configured in TS 38.331 [3];
- for UM DRBs and AM DRBs, reset the EHC protocol for uplink if drb-ContinueEHC-UL is not configured in
TS 38.331 [3];
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 12 ETSI TS 138 323 V16.8.0 (2023-01)
- for UM DRBs and SRBs, set TX_NEXT to the initial value;
- for SRBs, discard all stored PDCP SDUs and PDCP PDUs;
- apply the ciphering algorithm and key provided by upper layers during the PDCP entity re-establishment
procedure;
- apply the integrity protection algorithm and key provided by upper layers during the PDCP entity re-
establishment procedure;
- for UM DRBs, for each PDCP SDU already associated with a PDCP SN but for which a corresponding PDU has
not previously been submitted to lower layers, and;
- for AM DRBs for Uu interface whose PDCP entities were suspended, from the first PDCP SDU for which the
successful delivery of the corresponding PDCP Data PDU has not been confirmed by lower layers, for each
PDCP SDU already associated with a PDCP SN:
- consider the PDCP SDUs as received from upper layer;
- perform transmission of the PDCP SDUs in ascending order of the COUNT value associated to the PDCP
SDU prior to the PDCP re-establishment without restarting the discardTimer, as specified in clause 5.2.1;
- for AM DRBs whose PDCP entities were not suspended, from the first PDCP SDU for which the successful
delivery of the corresponding PDCP Data PDU has not been confirmed by lower layers, perform retransmission
or transmission of all the PDCP SDUs already associated with PDCP SNs in ascending order of the COUNT
values associated to the PDCP SDU prior to the PDCP entity re-establishment as specified below:
- perform header compression of the PDCP SDU using ROHC as specified in the clause 5.7.4 and/or using
EHC as specified in the clause 5.12.4;
- perform integrity protection and ciphering of the PDCP SDU using the COUNT value associated with this
PDCP SDU as specified in the clause 5.9 and 5.8;
- submit the resulting PDCP Data PDU to lower layer, as specified in clause 5.2.1.
When upper layers request a PDCP entity re-establishment, the receiving PDCP entity shall:
- process the PDCP Data PDUs that are received from lower layers due to the re-establishment of the lower layers,
as specified in the clause 5.2.2.1;
- for SRBs, discard all stored PDCP SDUs and PDCP PDUs;
- for SRBs and UM DRBs, if t-Reordering is running:
- stop and reset t-Reordering;
- for UM DRBs, deliver all stored PDCP SDUs to the upper layers in ascending order of associated COUNT
values after performing header decompression;
- for AM DRBs for Uu interface, perform header decompression using ROHC for all stored PDCP SDUs if drb-
ContinueROHC is not configured in TS 38.331 [3];
- for AM DRBs for PC5 interface, perform header decompression using ROHC for all stored PDCP IP SDUs;
- for AM DRBs for Uu interface, perform header decompression using EHC for all stored PDCP SDUs if drb-
ContinueEHC-DL is not configured in TS 38.331 [3];
- for UM DRBs and AM DRBs, reset the ROHC protocol for downlink and start with NC state in U-mode (as
defined in RFC 3095 [8] and RFC 4815 [9]) if drb-ContinueROHC is not configured in TS 38.331 [3];
- for UM DRBs and AM DRBs, reset the EHC protocol for downlink if drb-ContinueEHC-DL is not configured in
TS 38.331 [3];
- for UM DRBs and SRBs, set RX_NEXT and RX_DELIV to the initial value;
- apply the ciphering algorithm and key provided by upper layers during the PDCP entity re-establishment
procedure;
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 13 ETSI TS 138 323 V16.8.0 (2023-01)
- apply the integrity protection algorithm and key provided by upper layers during the PDCP entity re-
establishment procedure.
NOTE: After PDCP re-establishment on a sidelink SRB/DRB, UE determines when to transmit and receive with
the new key and discard the old key as specified in TS 33.536 [14].
5.1.3 PDCP entity release
When upper layers request a PDCP entity release for a radio bearer for Uu or PC5 interface, the UE shall:
- discard all stored PDCP SDUs and PDCP PDUs in the transmitting PDCP entity;
- for UM DRBs and AM DRBs, deliver the PDCP SDUs stored in the receiving PDCP entity to upper layers in
ascending order of associated COUNT values after performing header decompression, if not decompressed
before;
- release the PDCP entity for the radio bearer.
NOTE: For NR sidelink communication for groupcast and broadcast, the receiving PDCP entity release for an
SLRB is up to UE implementation.
5.1.4 PDCP entity suspend
When upper layers request a PDCP entity suspend, the transmitting PDCP entity shall:
- set TX_NEXT to the initial value;
- discard all stored PDCP PDUs;
When upper layers request a PDCP entity suspend, the receiving PDCP entity shall:
- if t-Reordering is running:
- stop and reset t-Reordering;
- deliver all stored PDCP SDUs to the upper layers in ascending order of associated COUNT values after
performing header decompression;
- set RX_NEXT and RX_DELIV to the initial value.
5.1.5 PDCP entity reconfiguration
When upper layers reconfigure the PDCP entity to configure DAPS, the UE shall:
- establish a ciphering function for the radio bearer and apply the ciphering algorithm and key provided by upper
layers for the ciphering function;
- establish an integrity protection function for the radio bearer and apply the integrity protection algorithm and key
provided by upper layers for the integrity protection function;
- establish a header compression protocol for the radio bearer and apply the header compression configuration
provided by upper layers for the header compression protocol.
When upper layers reconfigure the PDCP entity to release DAPS, the UE shall:
- release the ciphering function associated to the released RLC entity for the radio bearer;
- release the integrity protection function associated to the released RLC entity for the radio bearer;
- release the header compression protocol associated to the released RLC entity for the radio bearer.
NOTE 1: The state variables which control the transmission and reception operation should not be reset, and the
timers including t-Reordering and discardTimer keep running during PDCP entity reconfiguration
procedure.
ETSI
3GPP TS 38.323 version 16.8.0 Release 16 14 ETSI TS 138 323 V16.8.0 (2023-01)
NOTE 2: Before releasing the header compression protocol associated to the released RLC entity, how to handle all
stored PDCP SDUs received from the released RLC entity is left up to UE implementation.
NOTE 3: No special handling for the header compression protocol is defined to avoid potential security issue (e.g.
keystream reuse) for DAPS handover with no security key change.
5.2 Data transfer
5.2.1 Transmit operation
At reception of a PDCP SDU from upper layers, the transmitting PDCP entity shall:
- start the discardTimer associated with this PDCP SDU (if configured).
For a PDCP SDU received from upper layers, the transmitting PDCP entity shall:
- associate the COUNT value corresponding to TX_NEXT to this PDCP SDU;
NOTE 1: Associating more than half of the PDCP SN space of contiguous PDCP SDUs with PDCP SNs, when
e.g., the PDCP SDUs are discarded or transmitted without acknow
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...