5 Xw user plane protocol

36.4653GPPEvolved Universal Terrestrial Radio Access Network (E-UTRAN) and Wireless Local Area Network (WLAN)Release 17TSXw interface user plane protocol

5.1 General

The Xw UP protocol layer is using services of the transport network layer in order to allow flow control of user data packets transferred over the Xw interface.

5.2 Xw user plane protocol layer services

For LWA option, the following functions are provided by the Xw UP protocol:

– Provision of Xw UP specific sequence number information for user data transferred from the eNB to the WT for a specific E-RAB configured with the LWA bearer option;

– Information of successful transmission towards or in sequence delivery to the UE of LWA PDUs from WT for user data associated with a specific E-RAB configured with the LWA bearer option;

– Information of LWA PDUs that were not transferred towards or not delivered to the UE;

– Information of the currently desired buffer size at the WT for transmitting to the UE user data associated with a specific E-RAB configured with the LWA bearer option;

– Information of the currently minimum desired buffer size at the WT for transmitting to the UE user data associated with all E-RABs configured with the LWA bearer option.

For LWIP option, the following functions are provided by the Xw UP protocol:

– Provision of Xw UP specific sequence number information for user data transferred from the eNB to the WT for a specific UE configured with the LWIP bearer option;

– Information of successful transmission towards the UE of LWIP PDUs from WT for user data of a UE configured with the LWIP bearer option;

– Information of LWIP PDUs that were not transferred towards the UE;

– Information of the currently desired buffer size at the WT for transmitting to the UE user data for a specific UE configured with the LWIP bearer option;

– Information of the currently minimum desired buffer size at the WT for transmitting to the UE user data for UEs configured with the LWIP bearer option.

5.3 Services expected from the Xw Transport Network Layer

The Xw 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 Xw-U specific sequence number information at the transfer of user data carrying a DL LWA PDU or DL LWIP PDU from the eNB to the WT via the Xw-U interface.

In LWA option, an Xw 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 Xw-U interface.

In LWIP option, an Xw user plane instance making use of the Transfer of Downlink User Data procedure is associated to a single UE only. The Transfer of Downlink User Data procedure is invoked whenever user data for that particular UE needs to be sent across the Xw-U interface.

The eNB shall assign consecutive Xw-U sequence numbers to each transferred Xw-U packet.

The WT shall detect whether an Xw-U packet was lost and memorise the respective sequence number after it has declared the respective Xw-U packet as being “lost”.

In LWA option, the WT shall transfer the remaining LWA PDUs towards the UE and memorise the highest Xw-U sequence number of the PDCP PDU that was successfully transferred towards or delivered to the UE.

NOTE: For LWA option, the Transfer of Downlink User Data procedure and the associated feedback of lost Xw-U packets assist the eNB 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, e.g. UE feedback.

In LWIP option, the WT shall transfer the remaining LWIP PDUs towards the UE and memorise the highest Xw-U sequence number of the LWIP PDU that was successfully transferred towards the UE.

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 WT to the eNB to allow the eNB to control the downlink user data flow via the WT for the respective E-RAB in LWA option or for respective UE in LWIP option. The WT may also transfer uplink user data for the concerned E-RAB to the eNB together with a DL DATA DELIVERY STATUS frame within the same GTP-U PDU.

When the WT decides to trigger the Feedback for Downlink Data Delivery procedure it shall report:

a) the highest Xw-U sequence number successfully transferred towards or delivered to the UE among those PDUs received from the eNB;

b) the desired buffer size in bytes for:

– for LWA option: the concerned E-RAB;

– for LWIP option: the concerned UE;

c) the minimum desired buffer size in bytes for the UE;

d) the Xw-U packets that were declared as being “lost” by the WT and have not yet been reported to the eNB 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 WT. When receiving such indication, if applicable, the eNB considers that no more UL data is to be expected from the WT.

The eNB, 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 WT being declared;

– for the LWA option: from the Xw-U sequence number reported under a) above within the same frame, as well as from the most recently reported Xw-U 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 or LWIP PDUs according to the feedback of successfully delivered PDCP or LWIP PDUs;

– decides upon the actions necessary to take for PDCP or LWIP PDUs reported other than successfully delivered.

After being reported to the eNB, the WT removes the respective Xw-U 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 Xw 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 Xw interface, the frame is transmitted starting from the lowest numbered octet. Within each octet, the bits are sent according to 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 [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 Xw user plane protocol

5.5.2.1 DL USER DATA (PDU Type 0)

This frame format is defined to allow the WT to detect lost Xw-U packets and is associated with the transfer of a Downlink LWA PDU over the Xw-U interface.

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

Xw-U Sequence Number

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 eNB to control the downlink user data flow via the WT.

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 Xw-U Sequence Number

3

Desired buffer size for the E-RAB or UE

4

Minimum desired buffer size for the UE

4

Number of lost Xw-U Sequence Number ranges reported

1

Start of lost Xw-U Sequence Number range

6* (Number of reported lost Xw-u SN ranges)

End of lost Xw-U Sequence Number range

Padding

0-3

Figure 5.5.2.2-1: DL DATA DELIVERY STATUS (PDU Type 1) 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 Xw 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-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 Xw-U Sequence Number

Description: This parameter indicates the Xw-U sequence number as assigned by the respective eNB.

Value range: {0..224-1}.

NOTE: For LWA PDUs there should be one-to-one mapping between PDCP SN and Xw-U SN.

Field length: 3 octets.

5.5.3.4 Lost Packet Report

Description: This parameter indicates the presence of a list of lost Xw-U packets in the respective Xw 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 Xw-U Sequence Number

Description:

In case of the LWA option, this parameter indicates feedback about the in-sequence delivery status of LWA PDUs at the WT towards, or to the UE.

In case of the LWIP option, this parameter indicates feedback about the in-sequence transmission status of LWIP PDUs at the WT towards the UE.

Value range: {0..224-1}.

Field length: 3 octets.

5.5.3.7 Desired buffer size for the E-RAB or UE

Description:

In case of the LWA option, this parameter indicates the desired buffer size for the concerned E-RAB as specified in clause 5.4.2.1.

In case of the LWIP option, this parameter indicates the desired buffer size for the concerned UE 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:

In case of the LWA option, this parameter indicates the minimum desired buffer size for all E-RABs established for the UE as specified in clause 5.4.2.1.

In case of the LWIP option, this parameter indicates the minimum desired buffer size 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 Xw-U Sequence Number ranges reported

Description: This parameter indicates the number of Xw-U Sequence Number ranges reported to be lost.

Value range: {1.. 162}.

Field length: 1 octet.

5.5.3.10 Start of lost Xw-U Sequence Number range

Description: This parameter indicates the start of an Xw-U sequence number range.

Value range: {0..218-1}.

Field length: 3 octets.

5.5.3.11 End of lost Xw-U Sequence Number range

Description: This parameter indicates the end of an Xw-U sequence number range.

Value range: {0..218-1}.

Field length: 3 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.4 Timers

Not applicable.

Annex A (informative):
Change history

Change history

Date

Meeting

TDoc.

CR

Rev

Cat

Subject/Comment

New Version

2015-08

RAN3#89

R3-151597

Draft skeleton TR

0.0.1

2015-09

RAN3#890bis

R3-152214

TR number update

0.0.2

2015-11

RAN3#90

R3-152420

TR number update

0.1.0

2015-11

RAN3#90

R3-152907

Agreements from RAN3#90

0.2.0

2016-01

RAN3#AH

R3-160007

TR number update

1.1.0

2016-02

RAN3#AH

R3-160150

Agreements from RAN3#AH

1.2.0

2016-02

RAN3#91

R3-160158

TR number update

1.3.0

2016-02

RAN#91

R3-160546

Agreements from RAN3#91

1.5.0

2016-03

71

RP-160437

MCC cleanup and submission for approval

2.0.0

2016-03

71

Upgraded to Rel-13 and placed under change control

13.0.0

2016-06

72

RP-161046

1

1

F

TS 36.465 correction for LWA

13.1.0

2016-06

72

RP-161046

3

2

F

Correction to the description of the Xw UP protocol services and Xw-U Sequence Number

13.1.0

2016-06

72

RP-161046

4

1

F

Correction to the range of the Xw-U Sequence Number

13.1.0

2017-03

RAN#75

RP-170535

0011

 

B

Enabling uplink data bearers

14.0.0

2017-03

RAN#75

RP-170543

0012

1

B

Enabling LWIP support over Xw

14.0.0

2017-09

RP-77

RP-171982

0017

1

A

Change of the name of the GTP container

14.1.0

2018-03

RP-79

RP-180473

0018

1

F

Avoiding exceeding the max size of the NR RAN Container

14.2.0

2018-06

RP-80

RP-181245

0019

1

F

Enabling future extendability of the Xn RAN Container

14.3.0

2018-06

Update to Rel-15 version (MCC)

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