5 NR user plane protocol

38.4253GPPNG-RANNR user plane protocolRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

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.

– 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.

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).

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;

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 starting from the last "Highest successfully delivered NR PDCP Sequence Number" for RLC AM if received, or the hosting node may send up to this amount of data per bearer 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;

– 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.

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.

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.

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									Number of Octets
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					1	Octet 4
Field 6									2	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 always an integer number of octets. The payload part is octet aligned (by adding ‘Padding Bits’ when needed). The total size of the frame shall not exceed 1018 octets (see TS 29.281 [2]).

The receiver should be able to remove an additional Future Extension field that may be present.
See description of Future Extension field in A.1.

Padding octets may be added at the end of the frame, see Padding in 5.5.3.24

5.5.2 Frame format for the NR user plane protocol

5.5.2.1 DL USER DATA (PDU Type 0)

This frame format is defined e.g. to allow the corresponding node to detect lost NR-U packets and may be associated with the transfer of a Downlink PDCP PDU.

The following shows the respective DL USER DATA frame.

NOTE 1: All information elements defined in Figure 5.5.2.1-1 are also applicable to E-UTRA PDCP. With this understanding, each instance of NR PDCP can be replaced by E-UTRA PDCP.

Bits									Number of Octets
7	6	5		4	3	2	1	0
PDU Type (=0)					Spare	DL Discard Blocks	DL Flush	Report polling	1
Spare			Request OutofSeq Report		Report Delivered	User data existence flag	Assistance Info. Report Polling Flag	Retransmission flag	1
NR-U Sequence Number									3
DL discard NR PDCP PDU SN									0 or 3
DL discard Number of blocks									0 or 1
DL discard NR PDCP PDU SN start (first block)									0 or 3
Discarded Block size (first block)									0 or 1
…
DL discard NR PDCP PDU SN start (last block)									0 or 3
Discarded Block size (last block)									0 or 1
DL report NR PDCP PDU SN									0 or 3
Padding									0-3

Figure 5.5.2.1-1: DL USER DATA (PDU Type 0) Format

5.5.2.2 DL DATA DELIVERY STATUS (PDU Type 1)

This frame format is defined to transfer feedback to allow the receiving node (i.e. the node that hosts the PDCP entity) to control the downlink user data flow via the sending node (i.e. the corresponding node).

The following shows the respective DL DATA DELIVERY STATUS frame. The Figure shows an example of how a frame is structured when all optional IEs (i.e. those whose presence is indicated by an associated flag) are present.

Absence of such an IE changes the position of all subsequent IEs on octet level.

NOTE 1: All information elements defined in Figure 5.5.2.2-1 are also applicable to E-UTRA PDCP unless specified otherwise in section 5.5.3. With this understanding, each instance of NR PDCP can be replaced by E-UTRA PDCP.

Bits											Number of Octets
7		6		5		4	3	2	1	0
PDU Type (=1)							Highest Transmitted NR PDCP SN Ind	Highest Delivered NR PDCP SN Ind	Final Frame Ind.	Lost Packet Report	1
Spare	Feedback Delay Ind.		NR-U SN Ind.		Delivered NR PDCP SN Range Ind		Data rate Ind.	Retransmitted NR PDCP SN Ind	Delivered Retransmitted NR PDCP SN Ind	Cause Report	1
Desired buffer size for the data radio bearer											4
Desired Data Rate											0 or 4
Number of lost NR-U Sequence Number ranges reported											0 or 1
Start of lost NR-U Sequence Number range											0 or (6* Number of reported lost NR-U SN ranges)
End of lost NR-U Sequence Number range
Highest successfully delivered NR PDCP Sequence Number											0 or 3
Highest transmitted NR PDCP Sequence Number											0 or 3
Cause Value											0 or 1
Successfully delivered retransmitted NR PDCP Sequence Number											0 or 3
Retransmitted NR PDCP Sequence Number											0 or 3
Number of successfully delivered out of sequence PDCP Sequence Number range											0 or 1
Start of successfully delivered out of sequence PDCP Sequence Number range											0 or (6* Number of successfully delivered out of sequence PDCP Sequence Number range)
End of successfully delivered out of sequence PDCP Sequence Number range
NR-U Sequence Number of Polling Frame											0 or 3
Feedback Delay Result											0 or 4
Padding											0-3

Figure 5.5.2.2-1: DL DATA DELIVERY STATUS (PDU Type 1) Format

5.5.2.3 ASSISTANCE INFORMATION DATA (PDU Type 2)

This frame format is defined to allow the node hosting the PDCP entity to receive assistance information.

The following shows the respective ASSISTANCE INFORMATION DATA frame.

NOTE 1: All information elements defined in Figure 5.5.2.3-1 are also applicable to E-UTRA PDCP unless specified otherwise in section 5.5.3.

Bits										Number of Octets
7	6	5	4		3		2	1	0
PDU Type (=2)				PDCP Dupl. Ind.		Assistance Info. Ind.		UL Delay Ind.	DL Delay Ind.	1
Spare									PDCP Duplication Activation Suggestion	1
Number of Assistance Information Fields										0 or 1
Assistance Information Type										0 or (2*Number of Assistance Info Fields + sum of Number of octets for Radio Quality Assistance Information Fields)
Number of octets for Radio Quality Assistance Information Fields
Radio Quality Assistance Information
UL Delay DU Result										0 or 4
DL Delay DU Result										0 or 4

Description: The padding is included at the end of the frame to ensure that the NR user plane protocol PDU length (including padding and the Future Extension) is (n*4– 2) octets, where n is a positive integer. If there is any Future Extension, the padding should be added after the Future Extensions.

Description: This field indicates the number of octets for Radio Quality Assistance Information exists. For Average CQI, Average HARQ Failure, Average HARQ Retransmissions, DL Radio Quality Index, UL Radio Quality Index, this field shall indicate as “1.” For Power Headroom Report, this filed shall indicate octet length of Power Headroom Report as defined in 3GPP TS 36.321[4] and 3GPP TS 38.321[5].

Value range: {0..2⁸-1}.

Field length: 1 octets.

5.5.3.45 Assistance Information Indication

Description: This field indicates the presence of the Number of Assistance Information Fields.

Value range: {0= Number of Assistance Information Fields not present, 1= Number of Assistance Information Fields present}.

5.5.3.46 UL Delay Indicator

Description: This parameter indicates the presence of the UL Delay DU Result. This information element is not applicable to E-UTRA PDCP.

Value range: {0= UL Delay DU Result not present, 1= UL Delay DU Result present}.

Field length: 1 bit.

5.5.3.47 DL Delay Indicator

Description: This parameter indicates the presence of the DL Delay DU Result. This information element is not applicable to E-UTRA PDCP.

Value range: {0= DL Delay DU Result not present, 1= DL Delay DU Result present}.

Field length: 1 bit.

5.5.3.48 UL Delay DU Result

Description: This field indicates UL delay measured at the corresponding node in milliseconds for the concerned DRB over Uu interface. It is encoded as an Unsigned32 binary integer value. The node hosting PDCP entity shall, if supported, use this information to calculate the total UL delay for the concerned DRB and report to the UPF for the purpose of QoS monitoring as specified in [8]. This information element is not applicable to E-UTRA PDCP.

Value range: {0..2³²-1}.

Field length: 4 octets.

5.5.3.49 DL Delay DU Result

Description: This field indicates DL delay measured at the corresponding node in milliseconds for the concerned DRB over Uu interface. It is encoded as an Unsigned32 binary integer value. The node hosting PDCP entity shall, if supported, use this information to calculate the total DL delay for the concerned DRB and report to the UPF for the purpose of QoS monitoring as specified in [8]. This information element is not applicable to E-UTRA PDCP.

Value range: {0..2³²-1}.

Field length: 4 octets.

Not applicable.

5.6 Handling of unknown, unforeseen and erroneous protocol data

Void.

Annex A (informative):
Example of using future Extension