ETSI TS 138 425 V17.3.0 (2023-05)

5G; NG-RAN; NR user plane protocol (3GPP TS 38.425 version 17.3.0 Release 17)

RTS/TSGR-0338425vh30

General Information

• Status: Not Published
• Technical Committee: 3GPP RAN 3 - lub specification, lur specification, lu specification and UTRAN & O&M
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Completion Date: 05-May-2023

Standards Content (Sample)

TECHNICAL SPECIFICATION
5G;
NG-RAN;
NR user plane protocol
(3GPP TS 38.425 version 17.3.0 Release 17)

3GPP TS 38.425 version 17.3.0 Release 17 1 ETSI TS 138 425 V17.3.0 (2023-05)

Reference
RTS/TSGR-0338425vh30
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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:
https://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.425 version 17.3.0 Release 17 2 ETSI TS 138 425 V17.3.0 (2023-05)
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 https://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.425 version 17.3.0 Release 17 3 ETSI TS 138 425 V17.3.0 (2023-05)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
1 Scope . 6
2 References . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 General . 7
4.1 General aspects . 7
5 NR user plane protocol . 7
5.1 General . 7
5.2 NR user plane protocol layer services . 7
5.3 Services expected from the Transport Network Layer . 8
5.4 Elementary procedures . 9
5.4.1 Transfer of Downlink User Data . 9
5.4.1.1 Successful operation. 9
5.4.1.2 Unsuccessful operation . 10
5.4.2 Downlink Data Delivery Status . 10
5.4.2.1 Successful operation. 10
5.4.2.2 Unsuccessful operation . 12
5.4.3 Transfer of Assistance Information . 12
5.4.3.1 Successful operation. 12
5.5 Elements for the NR user plane protocol . 13
5.5.1 General . 13
5.5.2 Frame format for the NR user plane protocol . 14
5.5.2.1 DL USER DATA (PDU Type 0) . 14
5.5.2.2 DL DATA DELIVERY STATUS (PDU Type 1) . 14
5.5.2.3 ASSISTANCE INFORMATION DATA (PDU Type 2) . 17
5.5.3 Coding of information elements in frames . 17
5.5.3.1 PDU Type . 17
5.5.3.2 Spare . 18
5.5.3.3 Report polling . 18
5.5.3.4 NR-U Sequence Number . 18
5.5.3.5 Desired buffer size for the data radio bearer . 18
5.5.3.6 Desired Data Rate . 18
5.5.3.7 DL Flush . 18
5.5.3.8 DL discard NR PDCP PDU SN . 19
5.5.3.9 DL Discard Blocks . 19
5.5.3.10 DL discard NR PDCP PDU SN start . 19
5.5.3.11 DL discard Number of blocks . 19
5.5.3.12 Discarded Block size . 19
5.5.3.13 Lost Packet Report . 19
5.5.3.14 Final Frame Indication . 19
5.5.3.15 Number of lost NR-U Sequence Number ranges reported . 20
5.5.3.16 Start of lost NR-U Sequence Number range . 20
5.5.3.17 End of lost NR-U Sequence Number range . 20
5.5.3.18 Highest Delivered NR PDCP SN Ind . 20
5.5.3.19 Highest successfully delivered NR PDCP Sequence Number . 20
5.5.3.20 Highest Transmitted NR PDCP SN Ind . 20
5.5.3.21 Highest transmitted NR PDCP Sequence Number . 20
5.5.3.22 Cause Report . 21
ETSI
3GPP TS 38.425 version 17.3.0 Release 17 4 ETSI TS 138 425 V17.3.0 (2023-05)
5.5.3.23 Cause Value . 21
5.5.3.24 Padding . 21
5.5.3.28 Void. 21
5.5.3.29 Retransmission flag . 21
5.5.3.30 Delivered Retransmitted NR PDCP SN Ind . 21
5.5.3.31 Retransmitted NR PDCP SN Ind . 21
5.5.3.32 Successfully delivered retransmitted NR PDCP Sequence Number . 22
5.5.3.33 Retransmitted NR PDCP Sequence Number . 22
5.5.3.34 Data Rate Indication . 22
5.5.3.35 PDCP Duplication Indication . 22
5.5.3.36 PDCP Duplication Activation Suggestion . 22
5.5.3.37 Number of Assistance Information Field . 22
5.5.3.38 Assistance Information Type . 22
5.5.3.39 Radio Quality Assistance Information . 23
5.5.3.40 Assistance Information Report Polling Flag . 23
5.5.3.41 Report Delivered . 23
5.5.3.42 DL report NR PDCP PDU SN . 23
5.5.3.43 User data existence flag . 23
5.5.3.44 Number of octets for Radio Quality Assistance Information Field . 23
5.5.3.45 Assistance Information Indication . 24
5.5.3.46 UL Delay Indicator . 24
5.5.3.47 DL Delay Indicator . 24
5.5.3.48 UL Delay DU Result . 24
5.5.3.49 DL Delay DU Result . 24
5.5.3.50 Delivered NR PDCP SN Range Ind . 24
5.5.3.51 Number of successfully delivered out of sequence PDCP Sequence Number range . 25
5.5.3.52 Start of successfully delivered out of sequence PDCP Sequence Number range . 25
5.5.3.53 End of successfully delivered out of sequence PDCP Sequence Number range . 25
5.5.3.54 Request OutOfSeq Report . 25
5.5.3.55 NR-U SN Ind. . 25
5.5.3.56 Feedback Delay Ind. 25
5.5.3.57 NR-U Sequence Number of Polling Frame . 26
5.5.3.58 Feedback Delay Result . 26
5.5.4 Timers . 26
5.6 Handling of unknown, unforeseen and erroneous protocol data . 26
Annex A (informative): Example of using future Extension . 27
A.1 Example of using Future Extension field . 27
A.1.1 New IE Flags . 27
Annex B (informative): Change history . 28
History . 29

ETSI
3GPP TS 38.425 version 17.3.0 Release 17 5 ETSI TS 138 425 V17.3.0 (2023-05)
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.425 version 17.3.0 Release 17 6 ETSI TS 138 425 V17.3.0 (2023-05)
1 Scope
The present document specifies the NR user plane protocol functions used within NG-RAN and, for EN-DC and LTE
UP-CP split within E-UTRAN. NR user plane protocol functions may reside in nodes terminating either the X2-U (for
EN-DC) or the Xn-U or the F1-U interface. User plane protocol functions support both E-UTRA PDCP and NR 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 29.281: "General Packet Radio System (GPRS) Tunnelling Protocol User Plane
(GTPv1-U)".
[3] 3GPP TS 37.340: "NR; Multi-connectivity; Overall description; Stage-2".
[4] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access
Control (MAC) protocol specification".
[5] 3GPP TS 38.321: "NR; Medium Access Control (MAC) protocol specification".
[6] 3GPP TS 36.322: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control
(RLC) protocol specification".
[7] 3GPP TS 38.322: "NR; Radio Link Control (RLC) protocol specification".
[8] 3GPP TS 23.501: "System Architecture for the 5G System".
[9] 3GPP TS 36.401: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
Architecture description".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP 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 3GPP
TR 21.905 [1].
Corresponding node: a node interacting with a node hosting PDCP for flow control. In an IAB network, this is the
IAB-DU serving the UE for the corresponding data radio bearer.
eNB-CP: as defined in TS 36.401 [9].
eNB-UP: as defined in TS 36.401 [9].
Master node: as defined in TS 37.340 [3].
Secondary node: as defined in TS 37.340 [3].
ETSI
3GPP TS 38.425 version 17.3.0 Release 17 7 ETSI TS 138 425 V17.3.0 (2023-05)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP 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
3GPP TR 21.905 [1].
EN-DC E-UTRA-NR Dual Connectivity
IAB Integrated Access and Backhaul
MBS Multicast/Broadcast Service
MR-DC Multi-RAT Dual Connectivity
MRB MBS Radio Bearer
PTM Point To Multipoint
4 General
4.1 General aspects
The NR user plane protocol is located in the User Plane of the Radio Network layer over either the Xn or the X2 or the
F1 interface or the W1 interface or the UP interface between eNB-CP and eNB-UP.
The NR user plane protocol is used to convey control information related to the user data flow management of data
radio bearers.
Each NR user plane protocol instance is associated to one data radio bearer only. There is one NR user plane instance
per GTP tunnel. When a GTP tunnel is set up, a new NR user plane instance is set up.
If configured, NR user plane protocol instances exist at the Master node and the Secondary node in the context of DC or
at nodes hosting F1-U protocol terminations or at nodes hosting W1-U protocol terminations or at eNB-CP and eNB-
UP. The NR user plane protocol supports direct communication between NR user plane protocol entities, regardless of
whether they terminate the same or different user plane interfaces.
NOTE: User data radio bearers may be setup for data forwarding purposes during Xn HO or during DC related
mobility without requiring the execution of any additional data radio bearer related user plane protocol
functions related to an NR user plane protocol instance.
On each data radio bearer, the NR user plane protocol operates with RLC AM or RLC UM.
In this version of the present document, NR user plane protocol data is conveyed by GTP-U protocol means, more
specifically, by means of the "NR RAN Container" GTP-U extension header as defined in TS 29.281 [2].
5 NR user plane protocol
5.1 General
The NR user plane protocol layer is using services of the transport network layer in order to allow flow control of user
data packets transferred from the node hosting PDCP to the corresponding node.
5.2 NR user plane protocol layer services
NOTE 1: In this section, NR user plane protocol layer services are also applicable to E-UTRA PDCP. With this
understanding, each instance of NR PDCP can be replaced by E-UTRA PDCP.
The following functions are provided by the NR user plane protocol:
- Provision of NR user plane specific sequence number information for user data transferred from the node hosting
NR PDCP to the corresponding node for a specific data radio bearer.
ETSI
3GPP TS 38.425 version 17.3.0 Release 17 8 ETSI TS 138 425 V17.3.0 (2023-05)
- Information of successful in sequence delivery of NR PDCP PDUs to the UE from the corresponding node for
user data associated with a specific data radio bearer.
- Information of NR PDCP PDUs that were not delivered to the UE or not transmitted to the lower layers.
- Information of NR PDCP PDUs transmitted to the lower layers for user data associated with a specific data radio
bearer.
- Information of downlink NR PDCP PDUs to be discarded for user data associated with a specific data radio
bearer;
- Information of the currently desired buffer size at the corresponding node for transmitting to the UE user data
associated with a specific data radio bearer.
- Information of the currently desired data rate in bytes at the corresponding node for transmitting to the UE user
data associated with a specific data radio bearer;
- Information of successful in sequence delivery of NR PDCP PDUs to the UE from the corresponding node for
retransmission user data associate with a specific data radio bearer;
- Information of NR PDCP PDUs transmitted to the lower layers for retransmission user data associated with a
specific data radio bearer.
- Information of the specific events at the corresponding node.
- Information on Radio Link Quality from the corresponding node for user data associated with a specific data
radio bearer.
- Information for QoS monitoring from the corresponding node for user data associated with a specific data radio
bearer.
5.3 Services expected from the Transport Network Layer
The NR user plane protocol layer expects the following services from the Transport Network Layer:
- Transfer of user data.
ETSI
3GPP TS 38.425 version 17.3.0 Release 17 9 ETSI TS 138 425 V17.3.0 (2023-05)
5.4 Elementary procedures
NOTE 1: In this section, NR user plane elementary procedures are also applicable to E-UTRA PDCP unless
specified otherwise. With this understanding, each instance of NR PDCP can be replaced by E-UTRA
PDCP unless specified otherwise.
5.4.1 Transfer of Downlink User Data
5.4.1.1 Successful operation
The purpose of the Transfer of Downlink User Data procedure is to provide NR-U specific sequence number
information at the transfer of user data carrying a DL NR PDCP PDU from the node hosting the NR PDCP entity to the
corresponding node.
An NR user plane protocol instance making use of the Transfer of Downlink User Data procedure is associated to a
single radio bearer only.
The node hosting the NR PDCP entity shall assign consecutive NR-U sequence numbers to each transferred NR-U
packet. A retransmitted NR PDCP PDU shall be assigned a new NR-U sequence number.
The node hosting the NR PDCP entity indicates to the corresponding node whether this NR-U packet is a
retransmission of NR PDCP PDU.
The node hosting the NR PDCP entity can indicate to the corresponding node to either discard all NR PDCP PDUs up
to and including a defined DL discard NR PDCP PDU SN or discard one or a number of blocks of downlink NR PDCP
PDUs.
If the Assistance Information Report Polling Flag is equal to 1, the corresponding node shall, if supported, send the
ASSISTANCE INFORMATION DATA to the node hosting the NR PDCP entity.
The corresponding node shall detect whether an NR-U packet was lost and memorise the respective sequence number
after it has declared the respective NR-U packet as being "lost".
The corresponding node shall transfer the remaining NR PDCP PDUs towards the UE and memorise the highest NR
PDCP PDU sequence number of the NR PDCP PDU that was successfully delivered (as defined in TS 36.322 [6] and
TS 38.322 [7]) in sequence towards the UE (in case RLC AM is used) and the highest NR PDCP PDU sequence
number of the NR PDCP PDU that was transmitted to the lower layers.
The corresponding node shall send the DL DATA DELIVERY STATUS if the Report Polling Flag is set to 1 or when
the NR PDCP PDU with the indicated DL report NR PDCP PDU SN has been successfully delivered, unless a situation
of overload at the corresponding node is encountered. The DL DATA DELIVERY STATUS sent as a response to a
specific DL report NR PDCP PDU SN shall be sent only when all PDCP PDU SNs up to this DL report NR PDCP PDU
have been successfully delivered in-sequence.
If the Request OutOfSeq Report is set to 1, the corresponding node shall, if supported, include the NR PDCP PDU
sequence number successfully delivered out of sequence in the DL DATA DELIVERY STATUS to the node hosting
the NR PDCP entity.
NOTE: The Transfer of Downlink User Data procedure and the associated feedback of lost NR-U packets assist
the node hosting the NR PDCP entity in avoiding NR PDCP HFN de-synchronisation. If a deployment
decides to not use the Transfer of Downlink User Data procedure, NR PDCP HFN synchronization
should be ensured by other means.
If the User data existence flag is set to 1, the corresponding node assumes that the node hosting the NR PDCP entity has
some user data for the concerned data radio bearer. The corresponding node decides whether and when to use DRX for
the UE (i.e. the corresponding node may indicate the UE to use DRX even if the flag is set to 1 and the received DL
USER DATA frame contains no user data).
ETSI
3GPP TS 38.425 version 17.3.0 Release 17 10 ETSI TS 138 425 V17.3.0 (2023-05)
node hosting corresponding
NR PDCP node
DL USER DATA
Figure 5.4.1.1-1: Successful Transfer of Downlink User Data
5.4.1.2 Unsuccessful operation
Void.
5.4.2 Downlink Data Delivery Status
5.4.2.1 Successful operation
The purpose of the Downlink Data Delivery Status procedure is to provide feedback from the corresponding node to the
node hosting the NR PDCP entity to allow the node hosting the NR PDCP entity to control the downlink user data flow
via the corresponding node for the respective data radio bearer. The corresponding node may also transfer uplink user
data for the concerned data radio bearer to the node hosting the NR PDCP entity together with a DL DATA
DELIVERY STATUS frame within the same GTP-U PDU.
The Downlink Data Delivery Status procedure is also used to provide feedback from the corresponding node to the
node hosting the NR PDCP entity to allow the node hosting the NR PDCP entity to control the successful delivery of
DL control data to the corresponding node.
When the corresponding node decides to trigger the feedback for Downlink Data Delivery procedure it shall report as
specified in section 5.2:
a) in case of RLC AM, the highest NR PDCP PDU sequence number successfully delivered in sequence to the UE
among those NR PDCP PDUs received from the node hosting the NR PDCP entity i.e. excludes those
retransmission NR PDCP PDUs;
NOTE 1: If the NR user plane protocol instance is associated a single RLC-AM entity for an MRB, specification
text in bullet a) is applicable.
For all other cases, if the NR user plane protocol instance is associated with an MRB configured with at
least one RLC AM entity and RLC-UM, the highest successfully delivered NR PDCP sequence number
indicates the combined feedback of the highest NR PDCP sequence number successfully delivered in
sequence to all the involved UEs for which the RLC AM entites have been configured, no retransmissions
are performed, and the highest NR PDCP sequence number transmitted to the lower layers for PTM.
b) the desired buffer size in bytes for the concerned data radio bearer or for the MRB;
c) optionally, the desired data rate in bytes associated with a specific data radio bearer configured for the UE or for
the MRB;
d) the NR-U packets that were declared as being "lost" by the corresponding node and have not yet been reported to
the node hosting the NR PDCP entity within the DL DATA DELIVERY STATUS frame;
e) if retransmission NR PDCP PDUs have been delivered, the NR PDCP PDU sequence number associated with
the highest NR-U sequence number among the retransmission NR PDCP PDUs successfully delivered to the UE
in sequence of NR-U sequence number;
f) if retransmission NR PDCP PDUs have been transmitted to the lower layers, the NR PDCP PDU sequence
number associated with the highest NR-U sequence number among the retransmission NR PDCP PDUs
transmitted to the lower layers in sequence of NR-U sequence number;
g) the highest NR PDCP PDU sequence number transmitted to the lower layers among those NR PDCP PDUs
received from the node hosting the NR PDCP entity i.e. excludes those retransmission NR PDCP PDUs;
ETSI
3GPP TS 38.425 version 17.3.0 Release 17 11 ETSI TS 138 425 V17.3.0 (2023-05)
NOTE 2: If the NR user plane protocol instance is associated with an MRB configured with RLC-UM entities only,
the highest NR PDCP PDU sequence number transmitted successfully to all lower layer instances is
reported.
NOTE 3: If a deployment has decided not to use the Transfer of Downlink User Data procedure, d), e) and f) above
are not applicable.
h) in case of RLC AM, the NR PDCP PDU sequence number successfully delivered out of sequence to the UE
among those NR PDCP PDUs received from the node hosting the NR PDCP entity i.e. excludes those
retransmission NR PDCP PDUs.
As soon as the corresponding node detects the successful RACH access by the UE for the corresponding data radio
bearer(s), the corresponding node shall send initial DL DATA DELIVERY STATUS frame to the node(s) hosting the
NR PDCP entity(ies). The node hosting NR PDCP entity may start sending DL data before receiving the initial DL
DATA DELIVERY STATUS frame. In case the DL DATA DELIVERY STATUS frame is sent before any NR PDCP
PDU is transferred to lower layers, the information on the highest NR PDCP PDU sequence number successfully
delivered in sequence to the UE and the highest NR PDCP PDU sequence number transmitted to the lower layers may
not be provided.
The DL DATA DELIVERY STATUS frame shall also include a final frame indication when this frame is the last DL
status report. When receiving such indication, the node hosting the NR PDCP entity considers that no more UL or DL
data is expected to be transmitted between the corresponding node and the UE.
The DL DATA DELIVERY STATUS frame may also include an indication of detected radio link outage or radio link
resume for the concerned data radio bearer. When receiving an indication of radio link outage detection, the node
hosting the NR PDCP entity considers that traffic delivery over the data radio bearer configured for the UE is
unavailable at the corresponding node both in UL and DL. When receiving an indication of radio link resume detection,
the node hosting the NR PDCP entity considers that traffic delivery over the data radio bearer configured for the UE is
available at the corresponding node both in UL and in DL. When receiving an indication of UL or DL radio link outage
detection, the node hosting the NR PDCP entity considers that traffic delivery over the data radio bearer configured for
the UE is unavailable at the corresponding node for UL or DL, depending on the indicated outage. When receiving an
indication of UL or DL radio link resume detection, the node hosting the NR PDCP entity considers that traffic delivery
over the data radio bearer configured for the UE is available at the corresponding node in UL or in DL, depending on
the indicated resume. These indications are not applicable to E-UTRA PDCP.
For report polling triggered reporting, the DL DATA DELIVERY STATUS frame may include the feedback delay
result and the NR-U sequence number of the frame where Report Polling Flag is included and that triggered the
signalling of the DL DATA DELIVERY STATUS.
The node hosting the NR PDCP entity, when receiving the DL DATA DELIVERY STATUS frame:
- regards the desired buffer size under b) and the data rate under c) above as the amount of data to be sent from the
hosting node:
- If the value of the desired buffer size is 0, the hosting node shall stop sending any data per bearer.
- If the value of the desired buffer size in b) above is greater than 0, the hosting node may send up to this
amount of data per bearer:
- first including the data to be retransmitted;
- then the new data, starting from the last "Highest successfully delivered NR PDCP Sequence Number"
for RLC AM if received, or starting from the last "Highest transmitted NR PDCP Sequence Number" for
RLC UM if received.
- The value of the desired data rate in c) above is the amount of data desired to be received in a specific
amount of time. The amount of time is 1 sec.
- The information of the buffer size in b) above and of the data rate in c) above is valid until the next DL
DATA DELIVERY STATUS frame is received.
- is allowed to remove the buffered NR PDCP PDUs of a RLC AM bearer, according to the feedback of
successfully delivered NR PDCP PDUs;
ETSI
3GPP TS 38.425 version 17.3.0 Release 17 12 ETSI TS 138 425 V17.3.0 (2023-05)
- decides upon the actions necessary to take for NR PDCP PDUs reported other than transmitted and/or
successfully delivered.
In case of RLC AM, after the highest NR PDCP PDU sequence number successfully delivered in sequence is reported
to the node hosting the NR PDCP entity, the corresponding node removes the respective NR PDCP PDUs. For RLC
UM, the corresponding node may remove the respective NR PDCP PDUs after transmitting to lower layers.

node hosting corresponding
NR PDCP node
DL DATA DELIVERY STATUS
Figure 5.4.2.1-1: Successful Downlink Data Delivery Status
5.4.2.2 Unsuccessful operation
Void.
5.4.3 Transfer of Assistance Information
5.4.3.1 Successful operation
NOTE 1: In this section, PDCP duplication and delay measurement related information are not applicable to E-
UTRA PDCP.
The purpose of the Transfer of Assistance Information procedure is to provide assistance information to the node
hosting the NR PDCP entity. Such information may be taken into consideration by the node hosting the NR PDCP
entity for UP management and optimisation procedures.
An NR user plane protocol instance making use of the Transfer of Assistance Information procedure is associated to a
single data radio bearer only.
The Transfer of Assistance Information procedure may be invoked if
- the corresponding node decides to send the Radio Quality Assistance Information and/or the PDCP duplication
activation suggestion to the node hosting the NR PDCP entity for the concerned data radio bearer or,
- the corresponding node decides to send the Radio Quality Assistance Information to the node hosting the NR
PDCP entity for the concerned RLC entity.
The Transfer of Assistance Information procedure may be invoked if the corresponding node is configured to perform
the QoS monitoring and to send the QoS monitoring results to the node hosting the NR PDCP entity for the concerned
data radio bearer.
The ASSISTANCE INFORMATION DATA frame may include one or more Radio Quality Assistance Information.
The information shall consist of the information indicated in the Assistance Information Type.
The ASSISTANCE INFORMATION DATA shall be sent, if supported, when the corresponding node receives a DL
USER DATA PDU including the Assistance Information Report Polling Flag set to 1.
The ASSISTANCE INFORMATION DATA frame may include the PDCP Duplication Activation Suggestion, which
informs the node hosting the NR PDCP entity of the suggestion from the corresponding node on whether to activate or
not activate DL PDCP duplication. The node hosting the NR PDCP entity may take this information into account to
take a decision on whether to activate or not activate PDCP duplication.
ETSI
Number of
Octets
3GPP TS 38.425 version 17.3.0 Release 17 13 ETSI TS 138 425 V17.3.0 (2023-05)
The ASSISTANCE INFORMATION DATA frame may include the UL Delay or/and DL Delay measured by the
corresponding node. The node hosting the NR PDCP entity may take this information into account to calculate the
whole UL or/and DL delay of RAN.
node hosting corresponding
NR PDCP node
ASSISTANCE INFORMATION
DATA
Figure 5.4.3.1-1: Successful Transfer of Assistance Information Data

5.5 Elements for the NR user plane protocol
5.5.1 General
In the present document the structure of frames is specified by using figures similar to figure 5.5.1-1.
Bits
7 6 5 4 3 2 1 0
Field 1 Field 2 1 Octet 1
Field 3 Field 4 2 Octet 2
Field 4 continue Spare Octet 3
Spare Field 5 Octet 4
Field 6 Octet 5
Octet 6
Field 6 continue Padding Bits
Future Extension 0-m
Padding 0-3
Figure 5.5.1-1: Example frame format
Unless otherwise indicated, fields which consist of multiple bits within an octet have the most significant bit located at
the highest bit position of the field (according to the bit numbers indicated above frame in figure 5.5.1-1). In addition, if
a field spans several octets, most significant bits are located in lower numbered octets (right of frame in figure 5.5.1-1).
The frame is transmitted starting from the lowest numbered octet. Within each octet, the bits are sent according
decreasing bit position (bit position 7 first).
Bits labelled "Spare" should be set to "0" by the sender and should not be checked by the receiver.
The header part of the frame is
...