5 X2 user plane protocol
36.4253GPPEvolved Universal Terrestrial Radio Access Network (E-UTRAN)Release 17TSX2 interface user plane protocol
5.1 General
The X2 UP protocol layer is using services of the transport network layer in order to allow flow control of user data packets transferred over the X2 interface.
5.2 X2 user plane protocol layer services
The following functions are provided by the X2 UP protocol:
– Provision of X2 UP specific sequence number information for user data transferred from the MeNB to the SeNB for a specific E-RAB configured with the split bearer option;
– Information of successful in sequence delivery of PDCP PDUs to the UE from SeNB for user data associated with a specific E-RAB configured with the split bearer option;
– Information of PDCP PDUs that were not delivered to the UE;
– Information of the currently desired buffer size at the SeNB for transmitting to the UE user data associated with a specific E-RAB configured with the split bearer option;
– Information of the currently minimum desired buffer size at the SeNB for transmitting to the UE user data associated with all E-RABs configured with the split bearer option.
5.3 Services expected from the X2 Transport Network Layer
The X2 user plane protocol layer expects the following services from the Transport Network Layer:
– Transfer of user data.
5.4 Elementary procedures
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 X2-U specific sequence number information at the transfer of user data carrying a DL PDCP PDU from the MeNB to the SeNB via the X2-U interface.
An X2 user plane instance making use of the Transfer of Downlink User Data procedure is associated to a single E-RAB only. The Transfer of Downlink User Data procedure is invoked whenever user data for that particular E-RAB needs to be sent across the X2-U interface.
The MeNB shall assign consecutive X2-U sequence numbers to each transferred X2-U packet.
The SeNB shall detect whether an X2-U packet was lost and memorise the respective sequence number after it has declared the respective X2-U packet as being "lost".
The SeNB shall transfer the remaining PDCP PDUs towards the UE and memorise the highest PDCP PDU sequence number of the PDCP PDU that was successfully delivered in sequence towards the UE.
NOTE: The Transfer of Downlink User Data procedure and the associated feedback of lost X2-U packets assist the MeNB in avoiding PDCP HFN de-synchronisation. If an E-UTRAN deployment decides to not use the Transfer of Downlink User Data procedure, PDCP HFN synchronization should be ensured by other means.
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 SeNB to the MeNB to allow the MeNB to control the downlink user data flow via the SeNB for the respective E-RAB. The SeNB may also transfer uplink user data for the concerned E-RAB to the MeNB together with a DL DATA DELIVERY STATUS frame within the same GTP-U PDU.
When the SeNB decides to trigger the Feedback for Downlink Data Delivery procedure it shall report:
a) the highest PDCP PDU sequence number successfully delivered in sequence to the UE among those PDCP PDUs received from the MeNB;
b) the desired buffer size in bytes for the concerned E-RAB;
c) the minimum desired buffer size in bytes for the UE;
d) the X2-U packets that were declared as being "lost" by the SeNB and have not yet been reported to the MeNB within the DL DATA DELIVERY STATUS frame.
NOTE: If an E-UTRAN deployment has decided not to use the Transfer of Downlink User Data procedure, d) above is not applicable.
The DL DATA DELIVERY STATUS frame shall also include an indication whether the frame is the last DL status report received in the course of releasing a bearer from the SeNB. When receiving such indication, if applicable, the MeNB considers that no more UL data is to be expected from the SeNB.
The MeNB, when receiving the DL DATA DELIVERY STATUS frame:
– regards the desired buffer size under b) and c) above as the amount of data desired from the SeNB being declared
– from the PDCP sequence number reported under a) above within the same frame, as well as from the most recently reported PDCP sequence number(s) of all other E-RABs established for the UE;
– as the momentary desired buffer sizes, independent of buffer sizes indicated in the past.
– is allowed to remove the buffered PDCP PDUs according to the feedback of successfully delivered PDCP PDUs;
– decides upon the actions necessary to take for PDCP PDUs reported other than successfully delivered.
After being reported to the MeNB, the SeNB removes the respective PDCP sequence numbers.
Figure 5.4.2.1-1: Successful Downlink Data Delivery Status
5.4.2.2 Unsuccessful operation
Void.
5.5 Elements for the X2 user plane protocol
5.5.1 General
In the present document the structure of frames are 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 |
|||||||||
|
Field 6 |
2 |
Octet 4 Octet 5 |
|||||||||
|
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 higher bit position (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).
On the X2 interface, 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 as "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 [3]).
The receiver should be able to remove an additional future extension field that may be present.
Padding octets may be added at the end of the frame, see Padding in 5.5.3.12.
5.5.2 Frame format for the X2 user plane protocol
5.5.2.1 DL USER DATA (PDU Type 0)
This frame format is defined to allow the SeNB to detect lost X2-U packets and is associated with the transfer of a Downlink PDCP PDU over the X2-U interface when the length of the PDCP SN is less than 16 bits.
The following shows the respective DL USER DATA frame.
|
Bits |
Number of Octets |
|||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
PDU Type (=0) |
spare |
1 |
||||||
|
X2-U Sequence Number |
2 |
|||||||
|
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 MeNB to control the downlink user data flow via the SeNB when the length of the PDCP SN is less than 16 bits.
|
Bits |
Number of Octets |
|||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
PDU Type (=1) |
Spare |
Final Frame Ind. |
Lost Packet Report |
1 |
||||
|
Highest successfully delivered PDCP Sequence Number |
2 |
|||||||
|
Desired buffer size for the E-RAB |
4 |
|||||||
|
Minimum desired buffer size for the UE |
4 |
|||||||
|
Number of lost X2-U Sequence Number ranges reported |
1 |
|||||||
|
Start of lost X2-U Sequence Number range |
4* (Number of reported lost X2-u SN ranges) |
|||||||
|
End of lost X2-U Sequence Number range |
||||||||
|
Padding |
0-3 |
|||||||
Figure 5.5.2.2-1: DL DATA DELIVERY STATUS (PDU Type 1) Format
5.5.2.3 DL DATA DELIVERY STATUS EXTENDED (PDU Type 2)
This frame format is defined to transfer feedback to allow the receiving MeNB to control the downlink user data flow via the SeNB when the length of the PDCP SN is 18 bits.
|
Bits |
Number of Octets |
|||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
PDU Type (=2) |
Spare |
Final Frame Ind. |
Lost Packet Report |
1 |
||||
|
Highest successfully delivered PDCP Sequence Number Extended |
3 |
|||||||
|
Desired buffer size for the E-RAB |
4 |
|||||||
|
Minimum desired buffer size for the UE |
4 |
|||||||
|
Number of lost X2-U Sequence Number ranges reported |
1 |
|||||||
|
Start of lost X2-U Sequence Number range Extended |
6* (Number of reported lost X2-U SN ranges) |
|||||||
|
End of lost X2-U Sequence Number range Extended |
||||||||
|
Padding |
0-3 |
|||||||
Figure 5.5.2.3-1: DL DATA DELIVERY STATUS EXTENDED (PDU Type 2) Format
5.5.2.4 DL USER DATA EXTENDED (PDU Type 3)
This frame format is defined to allow the SeNB to detect lost X2-U packets and is associated with the transfer of a Downlink PDCP PDU over the X2-U interface when the length of PDCP SN is 18 bits.
The following shows the respective DL USER DATA EXTENDED frame.
|
Bits |
Number of Octets |
|||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
|
PDU Type (=3) |
spare |
1 |
||||||
|
X2-U Sequence Number Extended |
3 |
|||||||
|
Padding |
0-3 |
|||||||
Figure 5.5.2.4-1: DL USER DATA (PDU Type 3) Format
5.5.3 Coding of information elements in frames
5.5.3.1 PDU Type
Description: The PDU Type indicates the structure of the X2 UP frame. The field takes the value of the PDU Type it identifies; i.e. "0" for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame.
Value range: {0=DL USER DATA, 1=DL DATA DELIVERY STATUS, 2=DL DATA DELIVERY STATUS EXTENDED, 3=DL USER DATA EXTENDED, 4-15=reserved for future PDU type extensions}
Field length: 4 bits
5.5.3.2 Spare
Description: The spare field is set to "0" by the sender and should not be interpreted by the receiver. This field is reserved for later versions.
Value range: (0–2n-1).
Field Length: n bits.
5.5.3.3 X2-U Sequence Number
Description: This parameter indicates the X2-U sequence number as assigned by the respective eNB when the length of PDCP SN is less than 16 bits.
Value range: {0..216-1}.
Field length: 2 octets.
5.5.3.4 Lost Packet Report
Description: This parameter indicates the presence of a list of lost X2-U packets in the respective X2 UP frame.
Value range: {0=Lost Frame List not present, 1=Lost Frame List present}.
Field length: 1 bit.
5.5.3.5 Final Frame Indication
Description: This parameter indicates whether the frame is the last DL status report as described in clause 5.4.2.1.
Value range: {0=Frame is not final, 1= Frame is final}.
Field length: 1 bit.
5.5.3.6 Highest successfully delivered PDCP Sequence Number
Description: This parameter indicates feedback about the in-sequence delivery status of PDCP PDUs at the SeNB towards the UE when the length of the PDCP SN is less than 16 bits.
Value range: {0..215-1}.
Field length: 2 octets.
5.5.3.7 Desired buffer size for the E-RAB
Description: This parameter indicates the desired buffer size for the concerned E-RAB as specified in clause 5.4.2.1.
Value range: {0..232-1}.
Field length: 4 octets.
5.5.3.8 Minimum desired buffer size for the UE
Description: This parameter indicates the minimum desired buffer size for all E-RABs established for the UE as specified in clause 5.4.2.1.
Value range: {0..232-1}.
Field length: 4 octets.
5.5.3.9 Number of lost X2-U Sequence Number ranges reported
Description: This parameter indicates the number of X2-U Sequence Number ranges reported to be lost.
Value range: {1.. 162}.
Field length: 1 octet.
5.5.3.10 Start of lost X2-U Sequence Number range
Description: This parameter indicates the start of an X2-U sequence number range.
Value range: {0..216-1}.
Field length: 2 octets.
5.5.3.11 End of lost X2-U Sequence Number range
Description: This parameter indicates the end of an X2-U sequence number range.
Value range: {0..216-1}.
Field length: 2 octets.
5.5.3.12 Padding
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.
Field Length: 0–3.
5.5.3.13 Highest successfully delivered PDCP Sequence Number Extended
Description: This parameter indicates feedback about the in-sequence delivery status of PDCP PDUs at the SeNB towards the UE when the length of the PDCP SN is 18 bits.
Value range: {0..218-1}.
Field length: 3 octets.
5.5.3.14 Start of lost X2-U Sequence Number range Extended
Description: This parameter indicates the start of an X2-U sequence number range when the length of the PDCP SN is 18 bits.
Value range: {0..224-1}.
Field length: 3 octets.
5.5.3.15 End of lost X2-U Sequence Number range Extended
Description: This parameter indicates the end of an X2-U sequence number range when the length of the PDCP SN is 18 bits.
Value range: {0..224-1}.
Field length: 3 octets.
5.5.3.16 X2-U Sequence Number Extended
Description: This parameter indicates the X2-U sequence number as assigned by the respective eNB when the length of PDCP SN is 18 bits.
Value range: {0..224-1}.
Field length: 3 octets.
5.5.4 Timers
Not applicable.
5.6 Handling of unknown, unforeseen and erroneous protocol data
Void.
Annex A (informative):
Change history
|
Change history |
||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
New |
|
2014-08 |
First draft version of this specification. |
0.0.0 |
||||
|
2014-08 |
Version edited during RAN3#85 |
0.1.0 |
||||
|
2014-08 |
MCC clean-up |
0.1.1 |
||||
|
2014-10 |
Version provided to RAN3#85bis with new TS number |
0.2.0 |
||||
|
2014-10 |
Version edited during RAN3#85bis |
0.3.0 |
||||
|
2014-11 |
Version edited during RAN3#86 |
0.4.0 |
||||
|
2014-12 |
Submitted for one-step approval |
1.0.0 |
||||
|
2014-12 |
RAN#66 |
RP-141980 |
Specification approved at RAN#66 and places under change control |
12.0.0 |
||
|
2015-03 |
RAN#67 |
RP-150351 |
0001 |
1 |
Correction on DL USER DATA (PDU Type 0) Format for multiple PDCP PDUs |
12.1.0 |
|
2015-12 |
RAN#70 |
RP-152099 |
0006 |
2 |
Extension of PDCP SN |
13.0.0 |
|
2016-06 |
RAN#72 |
RP-161043 |
0007 |
1 |
Correction on Extention of X2 SN |
13.1.0 |
|
2016-09 |
Corrected history table |
13.1.1 |
||||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
SA#75 |
Promotion to Release 14 without technical change |
14.0.0 |
||||
|
2018-03 |
RP#79 |
RP-180473 |
0010 |
1 |
F |
Avoiding exceeding the max size of the NR RAN Container |
14.1.0 |
|
2018-06 |
RP#80 |
RP-181245 |
0011 |
1 |
F |
Enabling future extendability of the RAN Container |
14.2.0 |
|
2018-06 |
SA#80 |
– |
– |
– |
– |
Promotion to Release 15 without technical change |
15.0.0 |
|
2020-07 |
SA#88-e |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
SA#95-e |
Promotion to Release 17 without technical change |
17.0.0 |
||||