5 Procedures

36.3223GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Radio Link Control (RLC) protocol specificationRelease 15TS

5.1 Data transfer procedures

5.1.1 TM data transfer

5.1.1.1 Transmit operations

5.1.1.1.1 General

When submitting a new TMD PDU to lower layer, the transmitting TM RLC entity shall:

– submit a RLC SDU without any modification to lower layer.

5.1.1.2 Receive operations

5.1.1.2.1 General

When receiving a new TMD PDU from lower layer, the receiving TM RLC entity shall:

– deliver the TMD PDU without any modification to upper layer.

5.1.2 UM data transfer

5.1.2.1 Transmit operations

5.1.2.1.1 General

When delivering a new UMD PDU to lower layer, the transmitting UM RLC entity shall:

– set the SN of the UMD PDU to VT(US), and then increment VT(US) by one.

5.1.2.2 Receive operations

5.1.2.2.1 General

The receiving UM RLC entity shall maintain a reordering window according to state variable VR(UH) as follows:

– a SN falls within the reordering window if (VR(UH) – UM_Window_Size) <= SN < VR(UH);

– a SN falls outside of the reordering window otherwise.

When receiving an UMD PDU from lower layer, the receiving UM RLC entity shall:

– either discard the received UMD PDU or place it in the reception buffer (see sub clause 5.1.2.2.2);

– if the received UMD PDU was placed in the reception buffer:

– update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop t-Reordering as needed (see sub clause 5.1.2.2.3);

When t-Reordering expires, the receiving UM RLC entity shall:

– update state variables, reassemble and deliver RLC SDUs to upper layer and start t-Reordering as needed (see sub clause 5.1.2.2.4).

For NB-IoT:

– The receiving side of an RLC entity shall behave such that the timer value of t-Reordering is 0, if not configured.

5.1.2.2.2 Actions when an UMD PDU is received from lower layer

When an UMD PDU with SN = x is received from lower layer, the receiving UM RLC entity shall:

– if VR(UR) < x < VR(UH) and the UMD PDU with SN = x has been received before; or

– if (VR(UH) – UM_Window_Size) <= x < VR(UR):

– discard the received UMD PDU;

– else:

– place the received UMD PDU in the reception buffer.

5.1.2.2.3 Actions when an UMD PDU is placed in the reception buffer

When an UMD PDU with SN = x is placed in the reception buffer, the receiving UM RLC entity shall:

– if rlc-OutOfOrderDelivery is configured:

– if all byte segments of the UMD PDU are received:

– reassemble the RLC SDU using the byte segments of the UMD PDU, remove RLC headers when doing so and deliver the reassembled RLC SDU to upper layer if not delivered before;

– if x falls outside of the reordering window:

– update VR(UH) to x + 1;

– reassemble RLC SDUs from any UMD PDUs with SN that falls outside of the reordering window, remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in ascending order of the RLC SN if not delivered before;

– if VR(UR) falls outside of the reordering window:

– set VR(UR) to (VR(UH) – UM_Window_Size);

– if an UMD PDU with SN = VR(UR) has already been received:

– update VR(UR) to the SN of the first UMD PDU with SN > current VR(UR) that has not been received;

– reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in ascending order of the RLC SN if not delivered before;

– if t-Reordering is running:

– if VR(UX) <= VR(UR); or

– if VR(UX) falls outside of the reordering window and VR(UX) is not equal to VR(UH)::

– stop and reset t-Reordering;

– if t-Reordering is not running (includes the case when t-Reordering is stopped due to actions above):

– if VR(UH) > VR(UR):

– start t-Reordering;

– set VR(UX) to VR(UH).

5.1.2.2.4 Actions when t-Reordering expires

When t-Reordering expires, the receiving UM RLC entity shall:

– update VR(UR) to the SN of the first UMD PDU with SN >= VR(UX) that has not been received;

– reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in ascending order of the RLC SN if not delivered before;

– if VR(UH) > VR(UR):

– start t-Reordering;

– set VR(UX) to VR(UH).

5.1.3 AM data transfer

5.1.3.1 Transmit operations

5.1.3.1.1 General

The transmitting side of an AM RLC entity shall prioritize transmission of RLC control PDUs over RLC data PDUs. The transmitting side of an AM RLC entity shall prioritize retransmission of RLC data PDUs over transmission of new AMD PDUs.

The transmitting side of an AM RLC entity shall maintain a transmitting window according to state variables VT(A) and VT(MS) as follows:

– a SN falls within the transmitting window if VT(A) <= SN < VT(MS);

– a SN falls outside of the transmitting window otherwise.

The transmitting side of an AM RLC entity shall not deliver to lower layer any RLC data PDU whose SN falls outside of the transmitting window.

When delivering a new AMD PDU to lower layer, the transmitting side of an AM RLC entity shall:

– set the SN of the AMD PDU to VT(S), and then increment VT(S) by one.

The transmitting side of an AM RLC entity can receive a positive acknowledgement (confirmation of successful reception by its peer AM RLC entity) for a RLC data PDU by the following:

– STATUS PDU from its peer AM RLC entity.

When receiving a positive acknowledgement for an AMD PDU with SN = VT(A), the transmitting side of an AM RLC entity shall:

– set VT(A) equal to the SN of the AMD PDU with the smallest SN, whose SN falls within the range VT(A) <= SN <= VT(S) and for which a positive acknowledgment has not been received yet.

– if positive acknowledgements have been received for all AMD PDUs associated with a transmitted RLC SDU:

– send an indication to the upper layers of successful delivery of the RLC SDU.

5.1.3.2 Receive operations

5.1.3.2.1 General

The receiving side of an AM RLC entity shall maintain a receiving window according to state variables VR(R) and VR(MR) as follows:

– a SN falls within the receiving window if VR(R) <= SN < VR(MR);

– a SN falls outside of the receiving window otherwise.

When receiving a RLC data PDU from lower layer, the receiving side of an AM RLC entity shall:

– either discard the received RLC data PDU or place it in the reception buffer (see sub clause 5.1.3.2.2);

– if the received RLC data PDU was placed in the reception buffer:

– update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop t-Reordering as needed (see sub clause 5.1.3.2.3).

When t-Reordering expires, the receiving side of an AM RLC entity shall:

– update state variables and start t-Reordering as needed (see sub clause 5.1.3.2.4).

For NB-IoT;

– The receiving side of an RLC entity shall behave such that the timer values of t-Reordering and t-StatusProhibit are 0, if not configured.

5.1.3.2.2 Actions when a RLC data PDU is received from lower layer

When a RLC data PDU is received from lower layer, where the RLC data PDU contains byte segment numbers y to z of an AMD PDU with SN = x, the receiving side of an AM RLC entity shall:

– if x falls outside of the receiving window; or

– if byte segment numbers y to z of the AMD PDU with SN = x have been received before:

– discard the received RLC data PDU;

– else:

– place the received RLC data PDU in the reception buffer;

– if some byte segments of the AMD PDU contained in the RLC data PDU have been received before:

– discard the duplicate byte segments.

5.1.3.2.3 Actions when a RLC data PDU is placed in the reception buffer

When a RLC data PDU with SN = x is placed in the reception buffer, the receiving side of an AM RLC entity shall:

– if rlc-OutOfOrderDelivery is configured:

– if all byte segments of the AMD PDU are received:

– reassemble the RLC SDU using the byte segments of the AMD PDU, remove RLC headers when doing so and deliver the reassembled RLC SDU to upper layer if not delivered before;

– if x >= VR(H)

– update VR(H) to x+ 1;

– if all byte segments of the AMD PDU with SN = VR(MS) are received:

– update VR(MS) to the SN of the first AMD PDU with SN > current VR(MS) for which not all byte segments have been received;

– if x = VR(R):

– if all byte segments of the AMD PDU with SN = VR(R) are received:

– update VR(R) to the SN of the first AMD PDU with SN > current VR(R) for which not all byte segments have been received;

– update VR(MR) to the updated VR(R) + AM_Window_Size;

– reassemble RLC SDUs from any byte segments of AMD PDUs with SN that falls outside of the receiving window and in-sequence byte segments of the AMD PDU with SN = VR(R), remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before;

– if t-Reordering is running:

– if VR(X) = VR(R); or

– if VR(X) falls outside of the receiving window and VR(X) is not equal to VR(MR):

– stop and reset t-Reordering;

– if t-Reordering is not running (includes the case t-Reordering is stopped due to actions above):

– if VR (H) > VR(R):

– start t-Reordering;

– set VR(X) to VR(H).

5.1.3.2.4 Actions when t-Reordering expires

When t-Reordering expires, the receiving side of an AM RLC entity shall:

– update VR(MS) to the SN of the first AMD PDU with SN >= VR(X) for which not all byte segments have been received;

– if VR(H) > VR(MS):

– start t-Reordering;

– set VR(X) to VR(H).

5.2 ARQ procedures

ARQ procedures are only performed by an AM RLC entity.

5.2.1 Retransmission

The transmitting side of an AM RLC entity can receive a negative acknowledgement (notification of reception failure by its peer AM RLC entity) for an AMD PDU or a portion of an AMD PDU by the following:

– STATUS PDU from its peer AM RLC entity.

When receiving a negative acknowledgement for an AMD PDU or a portion of an AMD PDU by a STATUS PDU from its peer AM RLC entity, the transmitting side of the AM RLC entity shall:

– if the SN of the corresponding AMD PDU falls within the range VT(A) <= SN < VT(S):

– consider the AMD PDU or the portion of the AMD PDU for which a negative acknowledgement was received for retransmission.

When an AMD PDU or a portion of an AMD PDU is considered for retransmission, the transmitting side of the AM RLC entity shall:

– if the AMD PDU is considered for retransmission for the first time:

– set the RETX_COUNT associated with the AMD PDU to zero;

– else, if it (the AMD PDU or the portion of the AMD PDU that is considered for retransmission) is not pending for retransmission already, or a portion of it is not pending for retransmission already:

– increment the RETX_COUNT;

– if RETX_COUNT = maxRetxThreshold:

– indicate to upper layers that max retransmission has been reached.

When retransmitting an AMD PDU, the transmitting side of an AM RLC entity shall:

– if the AMD PDU can entirely fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity:

– deliver the AMD PDU as it is except for the P field (the P field should be set according to sub clause 5.2.2) to lower layer;

– otherwise:

– segment the AMD PDU, form a new AMD PDU segment which will fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity and deliver the new AMD PDU segment to lower layer.

When retransmitting a portion of an AMD PDU, the transmitting side of an AM RLC entity shall:

– segment the portion of the AMD PDU as necessary, form a new AMD PDU segment which will fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity and deliver the new AMD PDU segment to lower layer.

When forming a new AMD PDU segment, the transmitting side of an AM RLC entity shall:

– only map the Data field of the original AMD PDU to the Data field of the new AMD PDU segment;

– set the header of the new AMD PDU segment in accordance with the description in sub clause 6.;

– set the P field according to sub clause 5.2.2.

5.2.2 Polling

An AM RLC entity can poll its peer AM RLC entity in order to trigger STATUS reporting at the peer AM RLC entity.

5.2.2.1 Transmission of a AMD PDU or AMD PDU segment

Upon assembly of a new AMD PDU, the transmitting side of an AM RLC entity except for NB-IoT shall:

– increment PDU_WITHOUT_POLL by one;

– increment BYTE_WITHOUT_POLL by every new byte of Data field element that it maps to the Data field of the RLC data PDU;

– if PDU_WITHOUT_POLL >= pollPDU; or

– if BYTE_WITHOUT_POLL >= pollByte;

– include a poll in the RLC data PDU as described below.

Upon assembly of an AMD PDU or AMD PDU segment, the transmitting side of an AM RLC entity shall:

– if both the transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC data PDU awaiting for acknowledgements) after the transmission of the RLC data PDU; or

– if no new RLC data PDU can be transmitted after the transmission of the RLC data PDU (e.g. due to window stalling);

– include a poll in the RLC data PDU as described below.

NOTE: E mpty RLC buffer (excluding transmitted RLC data PDU awaiting for acknowledgements) should not lead to unnecessary polling when data awaits in the upper layer. Details are left up to UE implementation.

To include a poll in a RLC data PDU, the transmitting side of an AM RLC entity shall:

– set the P field of the RLC data PDU to "1";

– set PDU_WITHOUT_POLL to 0, except for NB-IoT;

– set BYTE_WITHOUT_POLL to 0, except for NB-IoT;

After delivering a RLC data PDU including a poll to lower layer and after incrementing of VT(S) if necessary, the transmitting side of an AM RLC entity shall:

– set POLL_SN to VT(S) – 1;

– if t-PollRetransmit is not running:

– start t-PollRetransmit;

– else:

– restart t-PollRetransmit;

5.2.2.2 Reception of a STATUS report

Upon reception of a STATUS report from the receiving RLC AM entity the transmitting side of an AM RLC entity shall:

– if the STATUS report comprises a positive or negative acknowledgement for the RLC data PDU with sequence number equal to POLL_SN:

– if t-PollRetransmit is running:

– stop and reset t-PollRetransmit.

5.2.2.3 Expiry of t-PollRetransmit

Upon expiry of t-PollRetransmit, the transmitting side of an AM RLC entity shall:

– if both the transmission buffer and the retransmission buffer are empty (excluding transmitted RLC data PDU awaiting for acknowledgements); or

– if no new RLC data PDU can be transmitted (e.g. due to window stalling):

– consider the AMD PDU with SN = VT(S) – 1 for retransmission; or

– consider any AMD PDU which has not been positively acknowledged for retransmission;

– include a poll in a RLC data PDU as described in clause 5.2.2.1.

5.2.3 Status reporting

An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and/or negative acknowledgements of RLC PDUs (or portions of them).

Except for NB-IoT, RRC configures whether or not the status prohibit function is to be used for an AM RLC entity. For NB-IoT, RRC configures whether or not the status reporting due to detection of reception failure of an RLC data PDU is to be used for an AM RLC entity.

Triggers to initiate STATUS reporting include:

– Polling from its peer AM RLC entity:

– When a RLC data PDU with SN = x and the P field set to "1" is received from lower layer, the receiving side of an AM RLC entity shall:

– if the PDU is to be discarded as specified in clause 5.1.3.2.2; or

– if x < VR(MS) or x >= VR(MR):

– trigger a STATUS report;

– else:

– delay triggering the STATUS report until x < VR(MS) or x >= VR(MR).

NOTE 1: This ensures that the RLC Status report is transmitted after HARQ reordering.

– Detection of reception failure of an RLC data PDU, except for an NB-IoT UE not configured with enableStatusReportSN-Gap:

– The receiving side of an AM RLC entity shall trigger a STATUS report when t-Reordering expires.

NOTE 2: The expiry of t-Reordering triggers both VR(MS) to be updated and a STATUS report to be triggered, but the STATUS report shall be triggered after VR(MS) is updated.

When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall:

– if t-StatusProhibit is not running:

– at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and deliver it to lower layer;

– else:

– at the first transmission opportunity indicated by lower layer after t-StatusProhibit expires, construct a single STATUS PDU even if status reporting was triggered several times while t-StatusProhibit was running and deliver it to lower layer;

When a STATUS PDU has been delivered to lower layer, the receiving side of an AM RLC entity shall:

– start t-StatusProhibit.

When constructing a STATUS PDU, the AM RLC entity shall:

– for the AMD PDUs with SN such that VR(R) <= SN < VR(MS) that has not been completely received yet, in increasing SN order of PDUs and increasing byte segment order within PDUs, starting with SN = VR(R) up to the point where the resulting STATUS PDU still fits to the total size of RLC PDU(s) indicated by lower layer:

– for an AMD PDU for which no byte segments have been received yet::

– include in the STATUS PDU a NACK_SN which is set to the SN of the AMD PDU;

– for a continuous sequence of byte segments of a partly received AMD PDU that have not been received yet:

– include in the STATUS PDU a set of NACK_SN, SOstart and SOend

– set the ACK_SN to the SN of the next not received RLC Data PDU which is not indicated as missing in the resulting STATUS PDU.

5.3 SDU discard procedures

When indicated from upper layer (i.e. PDCP) to discard a particular RLC SDU, the transmitting side of an AM RLC entity or the transmitting UM RLC entity shall discard the indicated RLC SDU if no segment of the RLC SDU has been mapped to a RLC data PDU yet.

5.4 Re-establishment procedure

RLC re-establishment is performed upon request by RRC, and the function is applicable for AM, UM and TM RLC entities.

When RRC indicates that an RLC entity should be re-established, the RLC entity shall:

– if it is a transmitting TM RLC entity:

– discard all RLC SDUs;

– if it is a receiving UM RLC entity:

– when possible, reassemble RLC SDUs from UMD PDUs with SN < VR(UH), remove RLC headers when doing so and deliver all reassembled RLC SDUs to upper layer in ascending order of the RLC SN, if not delivered before;

– discard all remaining UMD PDUs;

– if it is a transmitting UM RLC entity:

– discard all RLC SDUs;

– if it is an AM RLC entity:

– when possible, reassemble RLC SDUs from any byte segments of AMD PDUs with SN < VR(MR) in the receiving side, remove RLC headers when doing so and deliver all reassembled RLC SDUs to upper layer in ascending order of the RLC SN, if not delivered before;

– discard the remaining AMD PDUs and byte segments of AMD PDUs in the receiving side;

– discard all RLC SDUs and AMD PDUs in the transmitting side;

– discard all RLC control PDUs.

– stop and reset all timers;

– reset all state variables to their initial values.

5.5 Handling of unknown, unforeseen and erroneous protocol data

5.5.1 Reception of PDU with reserved or invalid values

When an RLC entity receives an RLC PDU that contains reserved or invalid values, the RLC entity shall:

– discard the received PDU.