22.3.2 RLC

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

22.3.2.1 NB-IoT / AM RLC / Correct use of sequence numbering / Concatenation and reassembly / Polling for status

22.3.2.1.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE transmits the first PDU }

then { UE sets the Sequence Number field equal to 0 if RLC layer was newly established or to the last used sequence number +1}

}

(2)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE transmits subsequent PDUs }

then { SN incremented by 1 for each PDU transmitted }

}

(3)

with { UE in RRC_CONNECTED state }

ensure that {

when { The UE receives an AMD PDUs containing concatenated RLC }

then { The UE reassembles the RLC SDUs in accordance with the Framing Info and Length Indicators indicated in AMD PDUs }

}

(4)

with { UE in RRC_CONNECTED state }

ensure that {

when { The UE has multiple RLC SDUs in the transmission buffer that fits into the available AMD PDU size }

then { The UE concatenates the RLC SDUs in the transmission buffer into an AMD PDU and transmits it}

}

(5)

with { UE in RRC_CONNECTED state and using AM RLC }

ensure that {
when { last data in the buffer was transmitted }

then { UE transmits a Poll }

}

(6)

with { UE in RRC_CONNECTED state and using AM RLC }

ensure that {
when { the t-PollRetransmit timer expires }

then { UE transmits a Poll }

}

22.3.2.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 4.2.1.3.2 , 4.2.1.3.3, 5.1.3.1.1, 6.2.1.4, 6.2.2.3, 6.2.2.6 & 7.1. Unless otherwise stated these are Rel-13 requirements.

[TS 36.322, clause 4.2.1.3.2]

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall:

– segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer.

The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ):

– if the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the RLC data PDU into AMD PDU segments;

– the number of re-segmentation is not limited.

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD PDU segments from RLC data PDUs to be retransmitted, it shall:

– include relevant RLC headers in the RLC data PDU.

[TS 36.322, clause 4.2.1.3.3]

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:

– detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs;

– reorder the RLC data PDUs if they are received out of sequence;

– detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;

– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.

At the time of RLC re-establishment, the receiving side of an AM RLC entity shall:

– if possible, reassemble RLC SDUs from the RLC data PDUs that are received out of sequence and deliver them to upper layer;

– discard any remaining RLC data PDUs that could not be reassembled into RLC SDUs;

– initialize relevant state variables and stop relevant timers.

[TS 36.322, clause 5.1.3.1.1]

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.

[TS 36.322, clause 6.2.1.4]

AMD PDU consists of a Data field and an AMD PDU header.

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and consists of E(s) and LI(s).

An AM RLC entity is configured by RRC to use either a 10 bit SN or a 16 bit SN. The length of the fixed part of the AMD PDU header is two and three bytes respectively. The default values for SN field length used by an AM RLC entity is 10 bits.

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU header consists of an odd number of LI(s) and the length of the LI field is 11 bits, four padding bits follow after the last LI. The default value for LI field length used by an AM RLC entity is 11 bits.

Figure 6.2.1.4-1: AMD PDU with 10 bit SN (length of LI field is 11 bits) (No LI)

Figure 6.2.1.4-2: AMD PDU with 10 bit SN (length of LI field is 11 bits) (Odd number of LIs, i.e. K = 1, 3, 5, …)

Figure 6.2.1.4-3: AMD PDU with 10 bit SN (length of LI field is 11 bits) (Even number of LIs, i.e. K = 2, 4, 6, …)

Figure 6.2.1.4-4: AMD PDU with 10 bit SN (length of LI field is 15 bits)

[TS 36.322, clause 6.2.2.3]

Length: 10 bits or 16 bits (configurable) for AMD PDU and AMD PDU segments. 5 bits or 10 bits (configurable) for UMD PDU.

The SN field indicates the sequence number of the corresponding UMD or AMD PDU. For an AMD PDU segment, the SN field indicates the sequence number of the original AMD PDU from which the AMD PDU segment was constructed from. The sequence number is incremented by one for every UMD or AMD PDU.

[TS 36.322, clause 6.2.2.6]

Length: 2 bits.

The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 6.2.2.6-1.

Table 6.2.2.6-1: FI field interpretation

Value

Description

00

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

01

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

10

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

11

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

[TS 36.322, clause 7.1]

This sub clause describes the state variables used in AM and UM entities in order to specify the RLC protocol. The state variables defined in this subclause are normative.

All state variables and all counters are non-negative integers.

All state variables related to AM data transfer can take values from 0 to 1023 for 10 bit SN or from 0 to 65535 for 16 bit SN. All arithmetic operations contained in the present document on state variables related to AM data transfer are affected by the AM modulus (i.e. final value = [value from arithmetic operation] modulo 1024 for 10 bit SN and 65536 for 16 bit SN).

All state variables related to UM data transfer can take values from 0 to [2[sn-FieldLength] – 1]. All arithmetic operations contained in the present document on state variables related to UM data transfer are affected by the UM modulus (i.e. final value = [value from arithmetic operation] modulo 2[sn-FieldLength]).

AMD PDUs and UMD PDUs are numbered integer sequence numbers (SN) cycling through the field: 0 to 1023 for 10 bit SN and 0 to 65535 for 16 bit SN for AMD PDU and 0 to [2[sn-FieldLength] – 1] for UMD PDU.

When performing arithmetic comparisons of state variables or SN values, a modulus base shall be used.

VT(A) and VR(R) shall be assumed as the modulus base at the transmitting side and receiving side of an AM RLC entity, respectively. This modulus base is subtracted from all the values involved, and then an absolute comparison is performed (e.g. VR(R) <= SN < VR(MR) is evaluated as [VR(R) – VR(R)] modulo 1024 <= [SN – VR(R)] modulo 1024 < [VR(MR) – VR(R)] modulo 1024).

VR(UH) – UM_Window_Size shall be assumed as the modulus base at the receiving side of an UM RLC entity. This modulus base is subtracted from all the values involved, and then an absolute comparison is performed (e.g. (VR(UH) – UM_Window_Size) <= SN < VR(UH) is evaluated as [(VR(UH) – UM_Window_Size) – (VR(UH) – UM_Window_Size)] modulo 2[sn-FieldLength] <= [SN – (VR(UH) – UM_Window_Size)] modulo 2[sn-FieldLength] < [VR(UH) – (VR(UH) – UM_Window_Size)] modulo 2[sn-FieldLength]).

The transmitting side of each AM RLC entity shall maintain the following state variables:

a) VT(A) – Acknowledgement state variable

This state variable holds the value of the SN of the next AMD PDU for which a positive acknowledgment is to be received in-sequence, and it serves as the lower edge of the transmitting window. It is initially set to 0, and is updated whenever the AM RLC entity receives a positive acknowledgment for an AMD PDU with SN = VT(A).

b) VT(MS) – Maximum send state variable

This state variable equals VT(A) + AM_Window_Size, and it serves as the higher edge of the transmitting window.

c) VT(S) – Send state variable

This state variable holds the value of the SN to be assigned for the next newly generated AMD PDU. It is initially set to 0, and is updated whenever the AM RLC entity delivers an AMD PDU with SN = VT(S).

d) POLL_SN – Poll send state variable

This state variable holds the value of VT(S)-1 upon the most recent transmission of a RLC data PDU with the poll bit set to “1”. It is initially set to 0.

The transmitting side of each AM RLC entity shall maintain the following counters:

a) PDU_WITHOUT_POLL – Counter

This counter is initially set to 0. It counts the number of AMD PDUs sent since the most recent poll bit was transmitted.

b) BYTE_WITHOUT_POLL – Counter

This counter is initially set to 0. It counts the number of data bytes sent since the most recent poll bit was transmitted.

c) RETX_COUNT – Counter

This counter counts the number of retransmissions of an AMD PDU (see subclause 5.2.1). There is one RETX_COUNT counter per PDU that needs to be retransmitted.

The receiving side of each AM RLC entity shall maintain the following state variables:

a) VR(R) – Receive state variable

This state variable holds the value of the SN following the last in-sequence completely received AMD PDU, and it serves as the lower edge of the receiving window. It is initially set to 0, and is updated whenever the AM RLC entity receives an AMD PDU with SN = VR(R).

b) VR(MR) – Maximum acceptable receive state variable

This state variable equals VR(R) + AM_Window_Size, and it holds the value of the SN of the first AMD PDU that is beyond the receiving window and serves as the higher edge of the receiving window.

c) VR(X) – t-Reordering state variable

This state variable holds the value of the SN following the SN of the RLC data PDU which triggered t-Reordering.

d) VR(MS) – Maximum STATUS transmit state variable

This state variable holds the highest possible value of the SN which can be indicated by “ACK_SN” when a STATUS PDU needs to be constructed. It is initially set to 0.

e) VR(H) – Highest received state variable

This state variable holds the value of the SN following the SN of the RLC data PDU with the highest SN among received RLC data PDUs. It is initially set to 0.

Each transmitting UM RLC entity shall maintain the following state variables:

a) VT(US)

This state variable holds the value of the SN to be assigned for the next newly generated UMD PDU. It is initially set to 0, and is updated whenever the UM RLC entity delivers an UMD PDU with SN = VT(US).

Each receiving UM RLC entity shall maintain the following state variables:

a) VR(UR) – UM receive state variable

This state variable holds the value of the SN of the earliest UMD PDU that is still considered for reordering. It is initially set to 0. For RLC entity configured for STCH, it is initially set to the SN of the first received UMD PDU.

b) VR(UX) – UM t-Reordering state variable

This state variable holds the value of the SN following the SN of the UMD PDU which triggered t-Reordering.

c) VR(UH) – UM highest received state variable

This state variable holds the value of the SN following the SN of the UMD PDU with the highest SN among received UMD PDUs, and it serves as the higher edge of the reordering window. It is initially set to 0. For RLC entity configured for STCH, it is initially set to the SN of the first received UMD PDU.

22.3.2.1.3 Test description

22.3.2.1.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

UE:

None.

Preamble

– The UE is in state 2B-NB according to [18] the exceptions listed in table 22.3.2.1.3.1-1 with test loop mode G closed.

Table 22.3.2.1.3.1-1: RLC Settings

Parameter

Value

t-PollRetransmit-r13

ms4000

22.3.2.1.3.2 Test procedure sequence

If the start RLC UL and DL sequence numbers to be used at start of test body are non zero, but X and Y respectively due to transmission/reception of RLC PDU’s in preamble on bearer to be used, then any sequence number ‘n’ in test procedure maps as :

UL SQN n maps to SQN X+n MOD 1024 &

DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.2.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence

2

The SS transmits 4 AMD PDUs such that 1 AMD PDU is sent every NPDCCH period onwards , each containing an RLC DL SDU including a PRBS of 288 bits.

<–

AMD PDU (SN=0)

AMD PDU (SN=1)

AMD PDU (SN=2)

AMD PDU (SN=3)

2A

In the search space of the 4th NPDCCH period after the first transmission at step 2 the SS schedules 4 consecutive UL grants of size 328 bits (Note 1)

2B

Check: Does the UE transmit 4 AMD PDUs, with only the last one having the poll bit set ? Record time TA when the PDU with the poll bit set is received at the SS.

–>

AMD PDUs

1,2,5

P

3

In the search space of the 55th NPDCCH period after the first transmission at step 2 the SS schedules continuous UL grants of size 328 bits (Note 1)

4

Check 1: Does the UE transmit an AMD PDU with a SN in range 0 to 3 and P=1?

Record time TB.

Check 2: Is (TB – TA) = t-PollRetransmit-r13?

–>

AMD PDU

6

P

5

Upon receiving the Poll, the SS transmits an RLC Status Report.

<–

STATUS PDU

6

Check: Does the UE retransmit an AMD PDU within 5 sec?

–>

AMD PDU

6

F

7

SS stops periodic grant allocation

8

The SS transmits an AMD PDU including two RLC DL SDUs of size L1 bytes each with poll bit set to ‘0’. The RLC DL SDUs include a PRBS of 160 bits.

<–

AMD PDU(AMD PDU header(D/C=’1’, RF=’0’, P=’0’, FI=’00’,E=’1’, SN=’4’,E1=’0’, LI1=’L1’ bytes), 2 RLC DL SDUs of L1 bytes)

9

In the search space of the 3rd NPDCCH period after the transmission at step 8 t he SS allocates an UL grant of size 456 bits (Note 2).

<–

(UL grant, 456 bits)

10

Check: Does the UE transmit two RLC UL SDUs within an AMD PDU with FI field set to ‘00’, first E field in the fixed part set to ‘1’, first E field in the extension part set to ‘0’, first LI field set to 20 bytes?

–>

AMD PDU(AMD PDU header(P=’1’, FI=’00’, E=’1’,SN=4, E1=’0’, LI1=’20’) ), two RLC UL SDUs of size 20 bytes)

3, 4

P

11

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=5)

12

In the search space of the 9th NPDCCH period after the transmission at step 11 the SS transmits an AMD PDU including three RLC DL SDU of size L2 bytes with P field set to "0". The RLC DL SDUs include a PRBS of 80 bits.

<–

AMD PDU(AMD PDU header(D/C=’1’, RF=’0’, P=’0’, FI=’00’,E=’1’, SN=’5’, E1=’1’, LI1=’ L2’ bytes, E2=’0’, LI2=’L2’ bytes), three RLC DLSDUs of size L2 bytes)

13

In the search space of the 3rd NPDCCH period after the transmission at step 12 the SS schedules an UL grant of size 440 bits. (Note 3).

<–

(UL grant, 440 bits)

14

Check: Does the UE transmit three RLC UL SDUs within an AMD PDU with FI field set to “00”, first E field in the fixed part set to ‘1’, first E field in the extension part set to ‘1’, first LI field set to 10 bytes, second E field in the extension part set to ‘0’, second LI field set to 10 bytes and P field set to “1”?

–>

AMD PDU(AMD PDU header(P=’1’, FI=’00’, SN=5, E1=’1’, LI1=’10’, E2=’0’, LI2=’10’), three RLC ULSDUs of size 10 bytes)

3, 4

P

15

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=6)

NOTE 1 UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC PDU subheader, 1 byte Short BSR + 38 bytes MAC SDU(16-bit RLC AMD PDU header + 288-bit UL RLC SDU)).

NOTE 2: UL grant of 456 bits (ITBS=9, =2, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 2 byte MAC PDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 44 bytes MAC SDU(4 bytes RLC AMD PDU header + 2*20 UL RLC SDU) + 8 bytes Padding)).

NOTE 3: UL grant of440 bits (ITBS=3, =6, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 2 bytes MAC PDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 35 bytes MAC SDU(5 bytes RLC AMD PDU header + 3*10 UL RLC SDU) + 15 bytes Padding)).

Table 22.3.2.1.3.2-2: Void

22.3.2.1.3.3 Specific message contents

None.

22.3.2.2 NB-IoT / AM RLC / Receiver status triggers

22.3.2.2.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state, configured for enableStatusReportSN-Gap and using AM RLC }

ensure that {
when { Reception failure of an RLC data PDU is detected }

then { UE initiates Status Reporting }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }

ensure that {
when { Polling from peer AM RLC entity is detected and the sequence number of the PDU that carries the Poll is less than VR(MS) }

then { UE initiates Status Reporting }

}

(3)

Void

(4)

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }

ensure that {
when { the UE needs to send a Status Report and the UL grant is not large enough to accommodate the whole report }

then { UE includes as many NACK SNs in the Status Report as allowed by the UL grant }

}

22.3.2.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.2.3. Unless otherwise stated these are Rel-13 requirements.

[TS 36.322, clause 5.2.3]

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

22.3.2.2.3 Test description

22.3.2.2.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

UE:

None.

Preamble

– The UE is in state 2B-NB according to [18] the exceptions listed in table 22.3.2.2.3.1-1 with test loop mode G closed.

Table 22.3.2.2.3.1-1: RLC settings

Parameter

Value

t-PollRetransmit-r13

ms4000

enableStatusReportSN-Gap-r13

true

22.3.2.2.3.2 Test procedure sequence

If the start RLC UL and DL sequence numbers to be used at start of test body are non zero, but X and Y respectively due to transmission/reception of RLC PDU’s in preamble on bearer to be used, then any sequence number ‘n’ in test procedure maps as :

UL SQN n maps to SQN X+n MOD 1024 &

DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.2.2.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence.

Size of each RLC UL SDU #1 – #6 is PRBS of 288 bits (36 octets). The size of the RLC SDUs used in downlink is L.

1

The SS transmits 3 AMD PDUs with SN=0, 1, 2. The SS sets the P field of all the AMD PDUs to 0

<–

AMD PDU (SN=0, P=0)

AMD PDU (SN=1, P=0)

AMD PDU (SN=2, P=0)

2

In the search space of the 4th NPDCCH period after the first transmission at step 1 the SS schedules 3 consecutive UL grants with a time spacing of 3 NPDCCH cycles of size 328 bits. (Note 1)

<–

(UL grants, 328 bits)

2A

The UE transmits RLC UL SDU#1.

–>

(RLC UL SDU#1)

2B

The UE transmits RLC UL SDU#2.

–>

(RLC UL SDU#2)

2C

The UE transmits RLC UL SDU#3.

–>

(RLC UL SDU#3)

3

The SS transmits a STATUS PDU

<–

STATUS PDU

4

Void.

5

The SS starts the UL periodic grant transmission of size 40 bits. (Note 2)

6

The SS transmits 1 AMD PDUs with SN= 4. The SS sets the P field to 0

<–

AMD PDU (SN=4, P=0)

7

Check 1: Does the UE transmit a Status Report with NACK_SN=3 and ACK_SN=5?

–>

STATUS PDU

1

P

8

The SS stops to allocate any uplink grant.

9

In the search space of the 6th NPDCCH period after step 8 the SS transmits 1 AMD PDU with SN=3. The SS sets the P field to 1.

<–

AMD PDU (SN=3, P=1)

10

In the search space of the 3rd NPDCCH period after the transmission at step 9 the SS schedules 1 UL grant of size 40 bits. (Note 2)

<–

(UL grant, 40 bits)

11

Check: Does the UE transmit a Status Report with no NACK_SN and ACK_SN=5?

–>

STATUS PDU

2

P

12

In the search space of the next NPDCCH period after the transmission at step 10 the SS schedules 2 UL grants of size 328 bits. (Note 1)

<–

(UL grant, 328 bits)

13

The UE transmits RLC UL SDU#4.

–>

(RLC UL SDU#4)

14

The UE transmits RLC UL SDU#5.

–>

(RLC UL SDU#5)

15

The SS transmits a STATUS PDU

<–

STATUS PDU

16-23

Void

24

The SS transmits an AMD PDU with SN=5 and P=0, and an AMD PDU with SN=11 and P=1.

<–

AMD PDU (SN=5, P=0)

AMD PDU (SN=11, P=1)

25

In the search space of the 3rd NPDCCH period after the transmission at step 24 the SS schedules an UL grant of size 72 bits. (Note 3)

<–

(UL Grant)

Steps 26a1 and 26b1 depend on the UE behaviour; the "lower case letter" identifies a step sequence that takes place if a specific behaviour happens

26a1

Check: Does the UE transmit a Status Report with ACK_SN=8 and 2 NACK_SNs: 6 and 7?

–>

STATUS PDU

4

P

26b1

Check: Does the UE transmit a Status Report with ACK_SN=10 and 4 NACK_SNs: 6, 7, 8 and 9?

–>

STATUS PDU

4

P

27

In the search space of the 6th NPDCCH period the SS transmits an AMD PDU with SN=6 and P=1.

<–

AMD PDU (SN=6, P=1)

28

In the search space of the 3rd NPDCCH period after step 27 the SS schedules an UL grant of size 72 bits. (Note 4)

<–

(UL Grant)

29

Check: Does the UE transmit a Status Report with ACK_SN=12 and 4 NACK_SNs: 7, 8, 9 and 10?

–>

STATUS PDU

4

P

30

The SS transmits 4 AMD PDU with SN=7, 8, 9, 10.

NOTE: AMD PDUs with SN 5 to 11 carry RLC DL SDU #6. It is segmented in 6*5 + L-(6*5) octets.

<–

AMD PDU (SN=7, P=0)

AMD PDU (SN=8, P=0)

AMD PDU (SN=9, P=0)

AMD PDU (SN=10, P=0)

31

In the search space of the 3rd NPDCCH period after step 30 the SS schedules 1 UL grant of size 392 bits. (Note 5)

<–

(UL grant, 328 bits)

32

The UE loopbacks a STATUS PDU with SN_ACK=12 and the complete RLC UL SDU.

–>

(RLC UL SDU#6)

33

The SS transmits a STATUS PDU

<–

STATUS PDU

Note 1: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time. (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC PDU subheader, 1 byte Short BSR + 38 bytes MAC SDU(16-bit RLC AMD PDU header + 288-bit UL RLC SDU)).

Note 2: UL grant of 40 bits (ITBS=3, =0, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and (8-bit short BSR + 2x 8-bit MAC PDU subheader + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 1bit padding).

Note 3: UL grant of 72 bits (ITBS=2, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit (a Status Report with ACK_SN and 2 NACK_SNs (3x 8-bit MAC PDU subheader +8-bit Short BSR + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 2 x (12-bit NACK_SN/E1/E2) + 1-bit Padding) ) or (a Status Report with ACK_SN and 4 NACK_SNs (8-bit MAC PDU subheader +4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 4 x (12-bit NACK_SN/E1/E2) +1-bit padding)).

Note 4: UL grant of 72 bits (ITBS=2, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and 4 NACK_SNs (8-bit MAC PDU subheader + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 4 x (12-bit NACK_SN/E1/E2) +1-bit padding).

Note 5: UL grant of 392 bits (ITBS=8, =2, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time. (MAC subheader: 1 byte Short BSR subheader + 4 bytes MAC PDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 2 bytes MAC SDU(2 bytes RLC STATUS PDU) + 38 bytes MAC SDU(16-bit RLC AMD PDU header + 288-bit UL RLC SDU) + 2 bytes MAC Padding).

22.3.2.2.3.3 Specific message contents

None.

22.3.2.3 NB-IoT / AM RLC / In sequence delivery of upper layers PDUs/ Different numbers of length indicators

22.3.2.3.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives duplicate AMD PDUs }

then { UE discards the duplicate AMD PDUs }

}

(2)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives an AMD PDU with a SN gap }

then { UE sends STATUS PDU to request retransmissions of PDUs in the SN gap}

}

(3)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives PDUs within a SN gap }

then { RLC reassembles and reorders the AMD PDUs and deliver them to the upper layer in sequence }

}

(4)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives an AMD PDU or an AMD PDU segment with no LI field }

then { UE correctly decodes the received AMD PDU or AMD PDU segment }

}

(5)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives an AMD PDU or an AMD PDU segment more than one LI field }

then { UE correctly decodes the received AMD PDU or AMD PDU segment }

}

22.3.2.3.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.322, clause 4.2.1.3.3. Unless otherwise stated these are Rel-13 requirements.

[TS 36.322, clause 4.2.1.3.3]

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:

– detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs;

– reorder the RLC data PDUs if they are received out of sequence;

– detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;

– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.

At the time of RLC re-establishment, the receiving side of an AM RLC entity shall:

– if possible, reassemble RLC SDUs from the RLC data PDUs that are received out of sequence and deliver them to upper layer;

– discard any remaining RLC data PDUs that could not be reassembled into RLC SDUs;

– initialize relevant state variables and stop relevant timers.

[TS 36.322, clause 6.2.2.5]

Length: 11 bits for RLC UM, 11 bits or 15 bits for RLC AM. The length of the LI field for RLC AM is configured by upper layers.

The LI field indicates the length in bytes of the corresponding Data field element present in the RLC data PDU delivered/received by an UM or an AM RLC entity. The first LI present in the RLC data PDU header corresponds to the first Data field element present in the Data field of the RLC data PDU, the second LI present in the RLC data PDU header corresponds to the second Data field element present in the Data field of the RLC data PDU, and so on. The value 0 is reserved.

22.3.2.3.3 Test description

22.3.2.3.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

UE:

– None.

Preamble:

– The UE is in state 2B-NB according to [18] the exceptions listed in table 22.3.2.3.3.1-1 with test loop mode G closed.

Table 22.3.2.3.3.1-1: RLC settings

Parameter

Value

t-PollRetransmit-r13

ms4000

enableStatusReportSN-Gap-r13

true

22.3.2.3.3.2 Test procedure sequence

If the start RLC UL and DL sequence numbers to be used at start of test body are non zero, but X and Y respectively due to transmission/reception of RLC PDU’s in preamble on bearer to be used, then any sequence number ‘n’ in test procedure maps as :

  • UL SQN n maps to SQN X+n MOD 1024 &
  • DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.2.3.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence. Size of each RLC UL SDU #1 – #3 is PRBS of 256 bits (32 octets), size of each RLC UL SDU #4 – #16 is PRBS of 80 bits (10 octets). The size of the RLC SDUs used in downlink is L.

1

The SS transmits an AMD PDU to the UE. This PDU carries RLC DL SDU#1 without LI field.

<–

AMD PDU#1 (SN=0)

2

The SS transmits an AMD PDU to the UE. This PDU carries RLC DL SDU#1 without LI field.

<–

AMD PDU#1 (SN=0)

2A

In the search space of the 3rd NPDCCH period after the transmission at step 2 the SS schedules an UL grant of size 296 bits. (Note 1)

<–

(UL Grant)

3

Check: Does the UE transmit RLC UL SDU#1?

–>

(RLC UL SDU#1)

1,4

P

4

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=1)

5

The SS transmits an AMD PDU to the UE. This PDU contains RLC DL SDU#2, and the 1st part of RLC DL SDU#3.

<–

AMD PDU#2 (SN=1)

5A

In the search space of the 3rd NPDCCH period after the transmission at step 5 the SS schedules an UL grant of size 296 bits. (Note 1)

<–

(UL Grant)

6

Check: Does the UE transmit RLC UL SDU#2 with the poll bit set?

–>

(RLC UL SDU#2)

1

P

7

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=2)

8

The SS transmits an AMD PDU to the UE. This PDU contains RLC DL SDU#2, and the 1st part of RLC DL SDU#3.

<–

AMD PDU#2 (SN=1)

8A

In the search space of the 3rd NPDCCH period after the transmission at step 8 the SS schedules an UL grant of size 296 bits. (Note 1)

<–

(UL Grant)

9

Check: Does the UE transmit RLC UL SDU#2?

–>

(RLC UL SDU#2)

1

F

10

The SS transmits an AMD PDU to the UE. This PDU contains the 2nd part of RLC DL SDU#3.

<–

AMD PDU#3 (SN=2)

10A

In the search space of the 3rd NPDCCH period after the transmission at step 10 the SS schedules an UL grant of size 296 bits. (Note 1)

<–

(UL Grant)

11

Check: Does the UE transmit RLC UL SDU#3?

–>

(RLC UL SDU#3)

1

P

12

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=3)

13

The SS transmits an AMD PDU to the UE. This PDU contains the last part of RLC DL SDU#6.

<–

AMD PDU#6 (SN=5)

14

The SS transmits an AMD PDU to the UE. This PDU contains the 2nd part of RLC DL SDU#5, and the 1st part of RLC DL SDU#6.

<–

AMD PDU#5 (SN=4)

15

The SS does not allocate any uplink grant.

16

The SS transmits an AMD PDU to the UE. This PDU carries RLC DL SDU#4 and the 1st part of RLC DL SDU#5.

<–

AMD PDU#4 (SN=3)

17

In the search space of the 3rd NPDCCH period after step 16 the SS schedules an UL grant of size 504 bits sufficient for the UE to loopback the PRBS parts of RLC DL SDU#4, RLC DL SDU#5 and RLC DL SDU#6 and report RLC Status PDU. (Note 2)

<–

(UL grant)

18

Check: Does the UE transmit a STATUS PDU with ACK_SN=6 and an AMD PDU containing RLC UL SDU#4, RLC UL SDU#5 and RLC UL SDU#6 in its data field?

–>

STATUS PDU and AMD PDU (RLC UL SDU#4, RLC UL SDU#5, RLC UL SDU#6)

3

P

19

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=4)

20

The SS transmits an AMD RLC PDU to the UE. This PDU contains the last part of RLC DL SDU#9.

<–

AMD PDU#9 (SN=8, P=1)

20A

In the search space of the 3rd NPDCCH period after step 20 the SS schedules an UL grant of size 88 bits. (Note 3)

<–

(UL Grant)

21

Check: Does the UE transmit a STATUS PDU NACK_SN/E1/E2 fields set correctly to inform SS of missing PDUs #7, #8, (ACK_SN=9, NACK_SN= 6, NACK_SN= 7)?

–>

STATUS PDU

2

P

22

The SS transmits an AMD PDU to the UE. This PDU contains RLC DL SDU#8, and the 1st part of RLC DL SDU#9.

<–

AMD PDU#8 (SN=7)

23

The SS does not allocate any uplink grant.

24

In the search space of the 3rd NPDCCH period after step 24 the SS schedules The SS transmits an AMD PDU to the UE. This PDU carries SDU#7.

<–

AMD PDU#7 (SN=6)

24A

an UL grant of size 328 bits sufficient for the UE to loopback the PRBS parts of RLC DL SDU#7, RLC DL SDU#8 and RLC DL SDU#9 and report RLC Status PDU. (Note 4)

<–

(UL grants)

25

Check: Does the UE transmit a STATUS PDU with ACK_SN=9 and an AMD PDU containing RLC UL SDU#7, RLC UL SDU#8 and RLC UL SDU#9 in its data field?

–>

STATUS PDU and AMD PDU (RLC UL SDU#7, RLC UL SDU#8, RLC UL SDU#9)

3

P

26

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=5)

27

The SS transmits an AMD PDU to the UE. This PDU contains RLC DL SDU#10, RLC DL SDU#11 and RLC DL SDU#12 with two LI fields.

<–

AMD PDU#10 (SN=9)

28

In the search space of the 3rd NPDCCH period after step 27 the SS schedules an UL grant of size 328 bits sufficient for the UE to loopback the PRBS parts of RLC DL SDU#10, RLC DL SDU#11 and RLC DL SDU#12. (Note 5)

<–

(UL grant)

29

Check: Does the UE transmit an AMD PDU containing RLC UL SDU#10, RLC UL SDU#11 and RLC UL SDU#12 in its data field?

–>

AMD PDU (RLC UL SDU#10, RLC UL SDU#11, RLC UL SDU#12)

5

P

30

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=6)

31

The t-PollRetransmit-r13 timer for AMD PDU#11 expires and SS assumes that the transmission of AMD PDU#11 containing RLC DL SDU#13, RLC DL SDU#14, RLC DL SDU#15 and RLC DL SDU#16 is failed and considers AMD PDU#11 for re-transmission.

32

The SS transmits an AMD PDU segment to the UE. This PDU segment contains RLC DL SDU#13 without LI field.

<–

AMD PDU segment (SM=10)

33

In the search space of the 3rd NPDCCH period after step 32 the SS schedules an uplink grant of size 208 bits allowing the UE to transmit 1 RLC SDU. (Note 6)

<–

(UL grant)

34

Check: Does the UE transmit a STATUS PDU with NACK_SN=10, SOStart, SOEnd and ACK_SN=11 and an AMD PDU containing RLC UL SDU#13 in its data field?

–>

AMD PDU (RLC UL SDU#13)

4

P

35

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=7)

36

The SS transmits AMD PDU segment to the UE. This PDU segment contains SDU#14, SDU#15 and SDU#16 with two LI fields.

<–

AMD PDU segment

37

In the search space of the 3rd NPDCCH period after step 32 the SS schedules an UL grant of size 328 bits sufficient for the UE to loopback the PRBS parts of RLC DL SDU#14, RLC DL SDU#15 and RLC DL SDU#16. (Note 5)

<–

(UL grant)

38

Check: Does the UE transmit an AMD PDU containing RLC UL SDU#14, RLC UL SDU#15 and RLC UL SDU#16 in its data field?

–>

AMD PDU (RLC UL SDU#14, RLC UL SDU#15, RLC UL SDU#16)

5

P

39

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=8)

NOTE 1: UL grant of 296 bits (ITBS=9, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time. (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC PDU subheader, 1 byte Short BSR + 34 bytes MAC SDU(16-bit RLC AMD PDU header + 256 bit UL RLC SDU))

NOTE 2: UL grant of 504 bits (ITBS=10, =2, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report and a AMD PDU (a 4 byte Status Report with ACK_SN and 1 NACK_SN (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + (12-bit NACK_SN/E1/E2) + 5-bit Padding) or ACK_SN and 2 NACK_SN (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 2*(12-bit NACK_SN/E1/E2) + 1-bit Padding) + a 35 bytes RLC AMD PDU(5 bytes RLC AMD PDU header + 3*10 bytes UL RLC SDU) + 6 bytes MAC PDU subheader + 1 byte Short BSR + n bytes MAC Padding).

NOTE 3: UL grant of 88 bits (ITBS=6, =0, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and 2 NACK_SNs (4 bytes MAC PDU subheader + 1 byte Short BSR + 5 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 2 x (12-bit NACK_SN/E1/E2) + 1-bit Padding) + 1 byte MAC Padding ).

NOTE 4: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report and a AMD PDU.

NOTE 5: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a AMD PDU (4 bytes MAC PDU subheader + a 35 bytes RLC AMD PDU(5 bytes RLC AMP PDU header + 3*10 bytes UL RLC SDU) + 1 byte Short BSR + 1 byte MAC Padding).

NOTE 6: UL grant of 208 bits (ITBS=4, =2, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time. (MAC subheader: 1 byte Padding subheader + 1 byte Short BSR subheader + 2 bytes MAC PDU subheader + 1 byte MAC PDU subheader, 1 byte Short BSR + 12 bytes MAC SDU(2 bytes RLC AMD PDU header + 10 bytes bit UL RLC SDU) + 8 bytes MAC SDU (8 bytes of RLC STATUS PDU with NACK_SN and SOstart+SOend fields)

22.3.2.3.3.3 Specific message contents

None.

22.3.2.4 NB-IoT / AM RLC / Re-segmentation RLC PDU / SO, FI, LSF / Re-transmission of RLC PDU

22.3.2.4.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state }

ensure that {
when { AMD PDU to be retransmitted does not fit in new allocated TBS }

then { UE segments AMD PDU into AMD PDU segments }

}

(2)

with { UE in RRC_CONNECTED state }

ensure that {
when { AMD PDU segment to be retransmitted does not fit in new allocated TBS }

then { UE resegments AMD PDU segment to fit TBS }

}

(3)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives a STATUS PDU including a NACK_SN for missing AMD PDUs, RETX_COUNT < maxRetxThreshold }

then { UE successfully retransmits missing AMD PDUs }

}

(4)

with { UE in RRC_CONNECTED state }

ensure that {
when { an AMD PDU or a portion of an AMD PDU is considered for retransmission and if RETX_COUNT = maxRetxThreshold }

then { UE indicates to upper layers that max retransmission has been reached }

}

22.3.2.4.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 4.2.1.3.2, 5.2.1, 6.2.1.4 and 6.2.1.5. Unless otherwise stated these are Rel-13 requirements.

[TS 36.322, clause 4.2.1.3.2]

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall:

– segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer.

The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ):

– if the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the RLC data PDU into AMD PDU segments;

– the number of re-segmentation is not limited.

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD PDU segments from RLC data PDUs to be retransmitted, it shall:

– include relevant RLC headers in the RLC data PDU.

[TS 36.322, clause 5.2.1]

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.

[TS 36.322, clause 6.2.1.4]

AMD PDU consists of a Data field and an AMD PDU header.

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and consists of E(s) and LI(s).

An AM RLC entity is configured by RRC to use either a 10 bit SN or a 16 bit SN. The length of the fixed part of the AMD PDU header is two and three bytes respectively. The default values for SN field length used by an AM RLC entity is 10 bits.

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU header consists of an odd number of LI(s) and the length of the LI field is 11 bits, four padding bits follow after the last LI. The default value for LI field length used by an AM RLC entity is 11 bits.

Figure 6.2.1.4-1: AMD PDU with 10 bit SN (length of LI field is 11 bits) (No LI)

Figure 6.2.1.4-2: AMD PDU with 10 bit SN (length of LI field is 11 bits) (Odd number of LIs, i.e. K = 1, 3, 5, …)

Figure 6.2.1.4-3: AMD PDU with 10 bit SN (length of LI field is 11 bits) (Even number of LIs, i.e. K = 2, 4, 6, …)

Figure 6.2.1.4-4: AMD PDU with 10 bit SN (length of LI field is 15 bits)

[TS 36.322, clause 6.2.1.5]

AMD PDU segment consists of a Data field and an AMD PDU segment header.

AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an extension part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU segment header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension part of the AMD PDU segment header itself is byte aligned and consists of E(s) and LI(s).

AM RLC entity is configured by RRC to use either a 10 bit SN or a 16 bit SN. When a 10 bit SN is used, the SO field is 15 bits, and when a 16 bit SN is used, the SO field is 16 bits. The length of the fixed part of the AMD PDU segment header is four and five bytes respectively. The default values for SN field length and SO field length used by an AM RLC entity are 10 bits and 15 bits, respectively.

An AMD PDU segment header consists of an extension part only when more than one Data field elements are present in the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU segment header consists of an odd number of LI(s) and the length of the LI field is 11 bits, four padding bits follow after the last LI. The default value for LI field length used by an AM RLC entity is 11 bits.

Figure 6.2.1.5-1: AMD PDU segment with 10 bit SN (No LI)

Figure 6.2.1.5-2: AMD PDU segment with 10 bit SN (length of LI field is 11 bits) (Odd number of LIs, i.e. K = 1, 3, 5, …)

Figure 6.2.1.5-3: AMD PDU segment with 10 bit SN (length of LI field is 11 bits) (Even number of LIs, i.e. K = 2, 4, 6, …)

Figure 6.2.1.5-4: AMD PDU segment with 10 bit SN (length of LI field is 15 bits)

[TS 36.331, clause 5.3.11.3]

The UE shall:

1> upon T310 expiry; or

1> upon T312 expiry; or

1> upon random access problem indication from MCG MAC while neither T300, T301, T304 nor T311 is running; or

1> upon indication from MCG RLC that the maximum number of retransmissions has been reached for an SRB or for an MCG or split DRB:

2> consider radio link failure to be detected for the MCG i.e. RLF;

2> if AS security has not been activated:

3> if the UE is a NB-IoT UE:

4> perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause ‘RRC connection failure’;

3> else:

4> perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause ‘other’;

2> else:

3> initiate the connection re-establishment procedure as specified in 5.3.7;

[TS 36.331, clause 5.3.12]

Upon leaving RRC_CONNECTED, the UE shall:

1> reset MAC;

1> stop all timers that are running except T320, T322, T325, T330;

1> if leaving RRC_CONNECTED was triggered by suspension of the RRC:

1> else:

2> release all radio resources, including release of the RLC entity, the MAC configuration and the associated PDCP entity for all established RBs;

2> indicate the release of the RRC connection to upper layers together with the release cause;

1> if leaving RRC_CONNECTED was triggered neither by reception of the MobilityFromEUTRACommand message nor by selecting an inter-RAT cell while T311 was running:

2> enter RRC_IDLE and perform procedures as specified in TS 36.304 [4, 5.2.7];

22.3.2.4.3 Test description

22.3.2.4.3.1 Pre-test conditions

System Simulator:

– Ncell 1 and Ncell 11.

– System information combination 2 as defined in TS 36.508 [18] clause 8.1.4.3.1 is used.

UE:

None.

Preamble

– The UE is in state 2B-NB on Ncell 1 according to [18] the exceptions listed in table 22.3.2.4.3.1-1 with test loop mode G closed.

Table 22.3.2.4.3.1-1: RLC Settings

Parameter

Value

t-PollRetransmit-r13

ms4000

22.3.2.4.3.2 Test procedure sequence

Table 22.3.2.4.3.2-0 shows the cell configurations used during the test. The configuration T0 indicates the initial conditions. The configuration marked “T1” is applied at the points indicated in the Main behaviour description in Table 22.3.2.4.3.2-1.

Table 22.3.2.4.3.2-0: Cell configuration changes over time

Parameter

Unit

Ncell 1

Ncell 11

Remarks

T0

NRS EPRE

dBm/15kHz

-85

“Off”

Power level “Off” is defined in TS 36.508 Table 8.3.2.2.1-1

T1

NRS EPRE

dBm/15kHz

-85

-79

If the start RLC UL and DL sequence numbers to be used at start of test body are non zero, but X and Y respectively due to transmission/reception of RLC PDU’s in preamble on bearer to be used, then any sequence number ‘n’ in test procedure maps as:

UL SQN n maps to SQN X+n MOD 1024 &

DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.2.4.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message/PDU/SDU

0

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence.

1

The SS transmits one AMD PDU containing RLC DL SDU#1 in its data field. The SDU includes a PRBS of 400 bits.

<–

AMD PDU#1

2

In the search space of the 3rd NPDCCH period after the first transmission at step 1 the SS schedules one UL grant (Note 6)

<–

(UL grant, 440 bits)

3

The UE transmits an AMD PDU with the same data contents as received in the corresponding PRBS part of DL PDU#1.

–>

AMD PDU#1 (SN=0)

4

In the 5th NPDCCH period after the transmission at step 1the SS transmits one AMD PDU containing RLC DL SDU#2 in its data field. The SDU includes a PRBS of 400 bits.

<–

AMD PDU#2

5

In the search space of the 8th NPDCCH period after the first transmission at step 1 the SS schedules one UL grant (Note 6)

<–

(UL grant, 440 bits)

6

The UE transmits an AMD PDU with the same data contents as received in the corresponding PRBS part of DL PDU#2?

–>

AMD PDU#2 (SN=1)

7

The SS transmits a STATUS PDU. This PDU nacks the AMD PDU with SN=0. NACK_SN=0 and ACK_SN=2.

<–

STATUS PDU

8

In the 3rd and 4th NPDCCH period after the transmission at step 7 the SS schedules 1 UL grant of size 296 bits (Note 1, Note 4)

<–

(UL grants, 296 bits)

9

Check: Does the UE transmit an AMD PDU segment with SO=0, LSF=0 and the same data contents at the corresponding received positions as in the original AMD PDU?

–>

AMD PDU#1 segment 1 (SN=0)

1,3

P

10

Check: Does the UE transmit an AMD PDU segment with SO=<x>, LSF=1 and the same data contents at the corresponding received positions as in the original AMD PDU? (Note 3)

–>

AMD PDU#1 segment 2 (SN=0)

1,3

P

11

The SS transmits a STATUS PDU. This PDU nacks the AMD PDU with SN=0. NACK_SN=0, SOStart=0, SOEnd=<x-1> and ACK_SN=2. (Note 3, Note 5)

<–

STATUS PDU

12

In the 3rd and 4th NPDCCH period after the transmission at step 11 the SS schedules 1 UL grant of size 208 bits (Note 2) (Note 4)

<–

(UL grants, 208 bits)

13

Check: Does the UE transmit an AMD PDU segment with SO=0, LSF=0 and the same data contents at the corresponding received positions as in the original AMD PDU?

–>

AMD PDU#1 segment 1, 1st part(SN=0)

2,3

P

14

Check: Does the UE transmit an AMD PDU segment with SO=<y>, LSF=0 and the same data contents at the corresponding received positions as in the original AMD PDU? (Note 3)

–>

AMD PDU#1 segment 1, 2nd part (SN=0)

2,3

P

15

The SS transmits a STATUS PDU. This PDU acks the AMD PDUs with SN=0 and SN=1. ACK_SN=2.

<–

STATUS PDU

16

The SS transmits one AMD PDU containing RLC DL SDU#3 in its data field. The SDU includes a PRBS of 400 bits.

<–

AMD PDU#3

17

In the search space of the 5th NPDCCH period after the transmission at step 16 the SS schedules one UL grant (Note 6)

<–

(UL grant, 440 bits)

18

The UE transmits an AMD PDU containing the corresponding PRBS part of DL PDU#3 in its data field.

–>

AMD PDU#3 (SN=2)

EXCEPTION: Step 19 to 20 shall be repeated maxRetxThreshold times

(let i be the loop counter, i=1,…, maxRetxThreshold)

19

The SS transmits an RLC STATUS PDU. ACK_SN=3 and NACK_SN=2.

<–

STATUS PDU

19A

In the search space of the ((i +1) * 5)th NPDCCH period after the transmission at step 16 the SS schedules one UL grant (Note 6).

<–

(UL grant, 440 bits)

20

Check: Does the UE retransmit the AMD PDU not yet acknowledged?

–>

AMD PDU#3 (SN=2)

3

P

21

The SS transmits an RLC STATUS PDU. ACK_SN=3 and NACK_SN=2.

<–

STATUS PDU

21A

The SS changes Ncell 11 levels according to row "T1" in Table 22.3.2.4.3.2-0

22

Check: Does UE transmit an RRCConnectionRequest-NB message ?

–>

RRC: RRCConnectionRequest-NB

4-

P –

23 – 26

UE performs TAU procedure based on steps 2 to 5 of Generic test procedure in TS 36.508 subclause 8.1.5A.5 to takes place on Ncell 11.

27

The SS transmits an RRCConnectionRelease-NB message.

<–

RRC: RRCConnectionRelease-NB

Note 1: UL grant of 296 bits (ITBS=9, =1, see TS 36.213 Table 16.5.1.2-2) is chosen such that UE will segment into 2 AMD PDUs. MAC PDU of 296 bits=39 bytes fits an AMD PDU payload of >= 25 bytes + 2 bytes AMD PDU header + 2 bytes of segment header + X bytes spare for MAC header and possible RLC STATUS PDU and BSR report.

Note 2: UL grant of 208 bits (ITBS=4, =2, see TS 36.213 Table 16.5.1.2-2) is chosen such that UE will segment into 2 AMD PDUs. MAC PDU of 208 bits=26 bytes fits an AMD PDU payload of >= 13 bytes + 2 bytes AMD PDU header + 2 bytes of segment header + x bytes spare for MAC header and possible RLC STATUS PDU and BSR report.

Note 3: The values x and y depend upon the need of the UE to add RLC STATUS PDU and BSR report. The TBS has been chosen to ensure that the PDUs to be resegmented can be carried in 2 segments.

Note 4: 40 ms gap between transmissions both in DL and UL respectively allows for possible repetitions.

Note 5: As <x> becomes available in step 8 only the transmission in step 10 can only be scheduled afterwards. This requires a 100 ms activation time.

Note 6: UL grant of 440 bits (ITBS=3, =6, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time.

Note 7: Void.

22.3.2.4.3.3 Specific message contents

None.

22.3.2.5 NB-IoT / AM RLC / Segmentation and Reassembly / AMD PDU reassembly from AMD PDU segments / Re-ordering of RLC PDU segments

22.3.2.5.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 00 }

then { UE correctly decodes the received AMD PDU or AMD PDU segment }

}

(2)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 01 }

then { UE correctly decodes the received AMD PDU or AMD PDU segment }

}

(3)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 11 }

then { UE correctly decodes the received AMD PDU or AMD PDU segment}

}

(4)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 10 }

then { UE correctly decodes the received AMD PDU or AMD PDU segment }

}

(5)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives AM PDU segments }

then { UE delivers reassembled RLC SDU to upper layer}

}

(6)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives RLC AM PDU segments without segment header extension part }

then { UE correctly reassembles RLC AMD PDU segments into RLC AMD PDUs }

}

(7)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives RLC AM PDU segments with segment header extension part }

then { UE correctly reassembles RLC AMD PDU segments into RLC AMD PDUs }

}

(8)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives duplicate RLC AM PDU segments }

then { UE discards duplicate RLC AMD PDU segments }

}

(9)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives RLC AM PDU segments out of sequence }

then { UE delivers reassembled RLC SDU to upper layer }

}

(10)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives RLC AMD PDU segments with segments lost }

then { UE transmits STATUS PDU to request retransmission of missing segments }

}

(11)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives overlapping RLC AMD PDU segments }

then { UE discards duplicate RLC AMD PDU byte segments }

}

(12)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives RLC AM PDU segments }

then { UE reorders RLC AMD PDU segments received out of sequence }

}

(13)

with { UE in RRC_CONNECTED state }

ensure that {
when { enableStatusReportSN-Gap-r13 }

then { Set VR(MS) to SN of the first AMD PDU with SN >= VR(X) for which not all byte segments have been received }

}

22.3.2.5.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 4.2.1.3.3, 5.1.3.2.1, 5.1.3.2.2, 5.1.3.2.3, 6.2.1.4, 6.2.1.5 and 6.2.2.6.

[TS 36.322, clause 4.2.1.3.3]

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:

– reorder the RLC data PDUs if they are received out of sequence;

– detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;

– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.

[TS 36.322, clause 5.1.3.2.1]

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.

[TS 36.322, clause 5.1.3.2.2]

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.

[TS 36.322, clause 5.1.3.2.3]

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

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

[TS 36.322, clause 6.2.1.4]

AMD PDU consists of a Data field and an AMD PDU header.

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and consists of E(s) and LI(s).

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU header consists of an odd number of LI(s) and the length of the LI field is 11 bits, four padding bits follow after the last LI. The default value for LI field length used by an AM RLC entity is 11 bits.

[TS 36.322, clause 6.2.1.5]

AMD PDU segment consists of a Data field and an AMD PDU segment header.

AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an extension part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU segment header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension part of the AMD PDU segment header itself is byte aligned and consists of E(s) and LI(s).

An AMD PDU segment header consists of an extension part only when more than one Data field elements are present in the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU segment header consists of an odd number of LI(s) and the length of the LI field is 11 bits, four padding bits follow after the last LI. The default value for LI field length used by an AM RLC entity is 11 bits.

[TS 36.322, clause 6.2.2.6]

Length: 2 bits.

The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 6.2.2.6-1.

Table 6.2.2.6-1: FI field interpretation

Value

Description

00

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

01

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

10

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

11

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

22.3.2.5.3 Test description

22.3.2.5.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

UE:

None.

Preamble:

– The UE is in state Loopback Activated (state 2B-NB) according to [18] and the exceptions listed in table 22.3.2.5.3.1-1 with test loop mode G closed.

Table 22.3.2.5.3.1-1: RLC settings

Parameter

Value

t-PollRetransmit-r13

ms4000

enableStatusReportSN-Gap-r13

true

22.3.2.5.3.2 Test procedure sequence

If the start RLC UL and DL sequence numbers to be used at start of test body are non zero, but X and Y respectively due to transmission/reception of RLC PDU’s in preamble on bearer to be used, then any sequence number ‘n’ in test procedure maps as:

  • UL SQN n maps to SQN X+n MOD 1024 &
  • DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.2.5.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

Note: In steps 0 to 17 the size of the RLC SDUs used in uplink will be 33 octets. The size of the RLC SDUs used in downlink is L.

0

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence

1

The SS transmits AMD PDU#1 containing a complete RLC DL SDU#1 (FI field = 00).

<–

AMD PDU#1(SN=0)

1A

In the search space of the 3rd NPDCCH period after the transmission at step 1 the SS schedules one UL Grant of size 328 bits, sufficient for one RLC UL SDU to be looped back (Note 1).

<–

Uplink Grant

2

Check: Does the UE transmit RLC UL SDU#1?

–>

(RLC UL SDU#1) (SN=0)

1

P

3

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=1)

4

The SS transmits AMD PDU#2 containing the first segment of RLC DL SDU#2 (FI field = 01).

<–

AMD PDU#2(SN=1)

5

The SS transmits AMD PDU#3 containing the second segment of RLC DL SDU#2 (FI field = 11).

<–

AMD PDU#3(SN=2)

6

The SS transmits AMD PDU#4 containing the last segment of RLC DL SDU#2 (FI field = 10).

<–

AMD PDU#4(SN=3)

6A

In the search space of the 3rd NPDCCH period after the transmission at step 6 the SS schedules one UL Grant of size 328 bits, sufficient for one RLC UL SDU to be looped back (Note 1).

<–

Uplink Grant

7

Check: Does the UE transmit RLC UL SDU#2?

–>

(RLC UL SDU#2) (SN=1)

2,3,4

P

8

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=2)

9

The t-PollRetransmit-r13 timer for RLC DL PDU#5 expires and SS assumes that the transmission of AMD PDU#5 containing a complete RLC DL SDU#3 and a complete RLC DL SDU#4 is failed and consider RLC DL PDU#5 for re-transmission

10

The SS transmits AMD PDU segment containing a complete RLC DL SDU#3 (FI field = 00).

<–

AMD PDU#5 segment(SN=4)

10A

In the search space of the 3rd NPDCCH period after the transmission at step 10 the SS schedules one UL Grant of size 392 bits, sufficient for one STATUS PDU and one RLC UL SDU to be looped back (Note 11).

<–

Uplink Grant

11

Check: Does the UE transmit a STATUS PDU with NACK_SN=4 with SOStart=L and SOEnd=32767 (special SOEnd value) and ACK_SN=5 and an AMD PDU containing RLC SDU#3?

–>

(RLC UL SDU#3) (SN=2)

STATUS PDU

1

P

12

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=3)

13

The SS transmits AMD PDU segment containing the first segment of RLC DL SDU#4 (FI field = 01).

<–

AMD PDU#5 segment(SN=4)

14

The SS transmits AMD PDU segment containing the second segment of RLC DL SDU#4 (FI field = 11).

<–

AMD PDU#5 segment(SN=4)

15

The SS transmits AMD PDU segment containing the last segment of RLC DL SDU#4 (FI field = 10).

<–

AMD PDU#5 segment(SN=4)

15A

In the search space of the 3rd NPDCCH period after the transmission at step 15 the SS schedules one UL Grant of size 392 bits, sufficient for one STATUS PDU and one RLC UL SDU to be looped back (Note 12).

<–

Uplink Grant

16

Check: Does the UE transmit a STATUS PDU with ACK_SN=5 and an AMD PDU containing RLC UL SDU#4?

–>

(RLC UL SDU#4) (SN=3)

STATUS PDU

2,3,4

P

17

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=4)

Note: In steps 18 to 51 the size of the RLC SDUs used in uplink will be 16 octets. The size of the RLC SDUs used in downlink is L.

18

The SS transmits an AMD PDU containing the first part (8 bytes) of RLC DL SDU#5 in its data field. This PDU is in error (SN falls outside of the receiving window) and is to be discarded by the UE.

<–

AMD PDU#6 (SN=WindowSize+3)

19

The SS transmits an AMD PDU containing RLC DL SDU#6 (L bytes) in its data field with the P-bit set.

<–

AMD PDU#7 (SN=6, P=1)

20

In the search space of the 3rd NPDCCH period after the transmission at step 19 the SS schedules one UL Grant of size 72 bits, sufficient for one RLC STATUS PDU (Note 2).

<–

Uplink Grant

21

The UE transmits a STATUS PDU with NACK_SN field indicating missing PDU#5. ACK_SN=7, NACK_SN=5.

–>

STATUS PDU

22

The SS transmits an AMD PDU segment of AMD PDU#6 (AMD PDU#6 carries RLC DL SDU#5) containing the first 8 bytes of RLC DL SDU#5 in its data field. SO=0 and LSF=0. No header extension part is provided.

<–

AMD PDU#6 (SN=5)

segment 1

23

The SS transmits an AMD PDU segment of AMD PDU#6 (AMD PDU#6 carries RLC DL SDU#5) containing the last L-8 bytes of RLC DL SDU#5 in its data field with the P-bit set. SO=8 and LSF=1. No header extension part is provided.

<–

AMD PDU #6 (SN=5, P=1)

segment 2

24

In the search space of the 3rd NPDCCH period after the transmission at step 23 the SS schedules one UL Grant of size 56 bits, sufficient for one RLC STATUS PDU (Note 3).

<–

Uplink Grant

25

Check: Does the UE transmit a STATUS PDU with ACK_SN=7, thus acknowledging the reception of PDUs with SN=5 and SN=6, and no NACK_SN provided?

–>

STATUS PDU

6

P

25A

In the search space of the next NPDCCH period after the transmission at step 24 the SS schedules one UL Grant of size 328 bits, sufficient for two RLC UL SDUs to be looped back (Note 4).

<–

Uplink Grant

26

Check: Does the UE transmit RLC UL SDU#5 and RLC UL SDU#6?

–>

AMD PDU (RLC UL SDU#5, RLC UL SDU#6) (SN=4)

5

P

27

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=5)

28

The SS transmits an AMD PDU segment of AMD PDU#8 (AMD PDU#8 carries RLC DL SDU#7 and RLC DL SDU#8) containing the last L-8 bytes of RLC DL SDU#8 in its data field, with the P-bit set. FI=10, SO=(L+8) and LSF=1. No header extension part is provided.

<–

AMD PDU#8 (SN=7, P=1)

segment 2

29

In the search space of the 3rd NPDCCH period after the transmission at step 28 the SS schedules one UL Grant of size 104 bits, sufficient for one RLC STATUS PDU (Note 5).

<–

Uplink Grant

30

The UE transmits a STATUS PDU NACK_SN field for receipt of PDU#8. ACK_SN=8, NACK_SN=7, SOStart=0/SOEnd=L+7.

–>

STATUS PDU

31

The SS transmits an AMD PDU segment of AMD PDU#8 (AMD PDU#8 carries RLC DL SDU#7 and RLC DL SDU#8) containing RLC DL SDU#7 (L bytes) and the first 8 bytes of SDU#8 in its data field, with the P-bit set. FI=01, SO=0 and LSF=0. Header extension part present: E in fixed part header=1, E in extension part header=0, LI=L.

<–

AMD PDU#8 (SN=7, P=1)

segment 1

32

In the search space of the 3rd NPDCCH period after the transmission at step 31 the SS allocates one UL Grant of size 56 bits, sufficient for one RLC STATUS PDU (Note 3).

<–

Uplink Grant

33

Check: Does the UE transmit a STATUS PDU with ACK_SN=8?

–>

STATUS PDU

7

P

33A

In the search space of the next NPDCCH period after the transmission at step 32 the SS schedules one UL Grant of size 328 bits, sufficient for one RLC UL SDU to be looped back (Note 4).

<–

Uplink Grant

34

Check: Does the UE transmit RLC UL SDU#7 and RLC UL SDU#8?

–>

AMD PDU (RLC UL SDU#7, RLC UL SDU#8) (SN=5)

5,9

P

35

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=6)

36

The SS transmits an AMD PDU segment of AMD PDU#9 (AMD PDU#9 carries RLC DL SDU#9) containing the first 8 bytes of RLC DL SDU#9 in its data field. SO=0 and LSF=0. No header extension part is provided.

<–

AMD PDU#9 (SN=8)

segment 1

37

The SS transmits an AMD PDU segment of AMD PDU#9 (AMD PDU#9 carries RLC DL SDU#9) containing the first 8 bytes of RLC DL SDU#9 in its data field. SO=0 and LSF=0. No header extension part is provided.

<–

AMD PDU#9 (SN=8)

segment 1

38

The SS transmits an AMD PDU segment of AMD PDU#9 (AMD PDU#9 carries RLC DL SDU#9) containing the last L-8 bytes of RLC DL SDU#9 in its data field, with the P-bit set. SO=8 and LSF=1. No header extension part is provided.

<–

AMD PDU#9 (SN=8, P=1)

segment 2

39

In the search space of the 3rd NPDCCH period after the transmission at step 38 the SS schedules one UL Grant of size 56 bits, sufficient for one RLC STATUS PDU (Note 3).

<–

Uplink Grant

40

Check: Does the UE transmit a STATUS PDU with ACK_SN=9, thus acknowledging the reception of PDUs with SN=4 to SN=8, and no NACK_SN provided?

–>

STATUS PDU

8

P

40A

In the search space of the next NPDCCH period after the transmission at step 39 the SS schedules one UL Grant of size 176 bits, sufficient for one RLC UL SDU to be looped back (Note 6).

<–

Uplink Grant

41

Check: Does the UE transmit RLC UL SDU#9?

–>

(RLC UL SDU#9) (SN=6)

5

P

42

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=7)

43

The SS transmits an AMD PDU segment of AMD PDU#11 (AMD PDU#11 carries RLC DL SDU#11) containing the last L-8 bytes of RLC DL SDU#11 in its data field, with the P-bit set. This AMD PDU segment is sent with SN=10. SO=8 and LSF=1. No header extension part is provided.

<–

AMD PDU#11 (SN=10, P=1)

segment 2

44

In the search space of the 3rd NPDCCH period after the transmission at step 43 the SS schedules one UL Grant of size 144 bits, sufficient for one RLC STATUS PDU (Note 7).

<–

Uplink Grant

45

Check: Does the UE transmit a STATUS PDU with ACK_SN=11, thus acknowledging the reception of PDUs with SN=4 to SN=10, and NACK_SN=9, E1/E2 field for receipt of PDU#9 and NACK_SN=10, SOStart=0/SOEnd=7 for segment 1 of PDU#11?

–>

STATUS PDU

10

P

46

The SS transmits an AMD PDU segment of AMD PDU#11 (AMD PDU#11 carries RLC DL SDU#11) containing the first 8 bytes of RLC DL SDU#11 in its data field. SO=0 and LSF=0. No header extension part is provided.

<–

AMD PDU#11 (SN=10)

segment 1

47

The SS transmits one AMD PDU containing RLC DL SDU#10 (L bytes) in its data field, with the P-bit set.

<–

AMD PDU#10 (SN=9, P=1)

48

In the search space of the 3rd NPDCCH period after the transmission at step 47 the SS schedules one UL Grant of size 56 bits, sufficient for one RLC STATUS PDU (Note 3).

<–

Uplink Grant

49

The UE transmits a STATUS PDU with ACK_SN=11, thus acknowledging the reception of PDUs with SN=4 to SN=10, and no NACK_SN provided.

–>

STATUS PDU

49A

In the search space of the next NPDCCH period after the transmission at step 48 the SS schedules one UL Grant of size 328 bits, sufficient for two RLC UL SDUs to be looped back (Note 4).

<–

Uplink Grant

50

Check: Does the UE transmit RLC UL SDU#10 and RLC UL SDU#11?

–>

AMD PDU (RLC UL SDU#10, RLC UL SDU#11) (SN=7)

6,9

P

51

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=8)

Note: In steps 52 to 62 the size of the RLC SDUs used in uplink will be 10 octets. The size of the RLC SDUs used in downlink is L.

52

The SS transmits an AMD PDU segment of AMD PDU#12 (AMD PDU#12 carries RLC DL SDU#12, RLC DL SDU#13 and RLC DL SDU#14) containing the last L-6 bytes of RLC DL SDU#13 and the complete RLC DL SDU#14 (L bytes) in its data field, with the P-bit set. FI=10, SO= L+6 and LSF=1. Header extension part present: E in fixed part header=1, E in extension part header=0, LI=L-6.

<–

AMD PDU#12 (SN=11, P=1)

segment 3

53

In the search space of the 3rd NPDCCH period after the transmission at step 52 the SS schedules one UL Grant of size 104 bits, sufficient for one RLC STATUS PDU (Note 5).

<–

Uplink Grant

54

The UE transmits a STATUS PDU NACK_SN field for receipt of PDU#12. ACK_SN=12, NACK_SN=11, SOStart=0/SOEnd= L+5.

–>

STATUS PDU

55

The SS transmits an AMD PDU segment of AMD PDU#12 (AMD PDU#12 carries RLC DL SDU#12, RLC DL SDU#13 and RLC DL SDU#14) containing the last L-6 bytes of RLC DL SDU#12 and the first 6 bytes of RLC DL SDU#13 in its data field, with the P-bit set. FI=11, SO=6 and LSF=0. Header extension part present: E in fixed part header=1, E in extension part header=0, LI=L-6.

<–

AMD PDU#12 (SN=11, P=1)

segment 2

56

In the search space of the 3rd NPDCCH period after the transmission at step 55 the SS schedules one UL Grant of size 104 bits, sufficient for one RLC STATUS PDU (Note 5).

<–

Uplink Grant

57

The UE transmits a STATUS PDU NACK_SN field for receipt of PDU#12. ACK_SN=12, NACK_SN=11, SOStart=0/SOEnd=5.

–>

STATUS PDU

11

P

58

The SS transmits an AMD PDU segment of AMD PDU#12 (AMD PDU#12 carries RLC DL SDU#12, RLC DL SDU#13 and SDU#14) containing the first 6 bytes of SDU#12 in its data field, with the P-bit set. FI=01, SO=0 and LSF=0. No header extension part is provided.

<–

AMD PDU#12 (SN=11, P=1)

segment 1

59

In the search space of the 3rd NPDCCH period after the transmission at step 58 the SS schedules one UL Grant of size 56 bits, sufficient for one RLC STATUS PDU (Note 3).

<–

Uplink Grant

60

Check: Does the UE transmit a STATUS PDU with ACK_SN=12, thus acknowledging the reception of PDUs with SN=4 to SN=11, and no NACK_SN provided?

–>

STATUS PDU

11

P

60A

In the search space of the next NPDCCH period after the transmission at step 59 the SS schedules one UL Grant of size 328 bits, sufficient for three RLC UL SDUs to be looped back (Note 8).

<–

Uplink Grant

61

Check: Does the UE transmit RLC UL SDU#12, RLC UL SDU#13 and RLC UL SDU#14?

–>

AMD PDU (RLC UL SDU#12, RLC UL SDU#13, RLC UL SDU#14) (SN=8)

11

P

62

The SS transmits a STATUS PDU.

<–

STATUS PDU (ACK SN=9)

Note: In steps 63 to 93 the size of the RLC SDUs used in uplink will be 32 octets. The size of the RLC SDUs used in downlink is L.

63

The SS transmits one AMD PDU containing RLC DL SDU#22 (L bytes) in its data field to the UE. SN=19 indicates the loss of 7 PDUs.

<–

AMD PDU#20 (SN=19)

64

The SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#15 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#13, which contained RLC DL SDU#15 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#13 (SN=12)

segment 1

65

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#16 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#14, which contained RLC DL SDU#16 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#14 (SN=13)

segment 2

66

The SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#17 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#15, which contained RLC DL SDU#17 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#15 (SN=14)

segment 1

67

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#18 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#16, which contained RLC DL SDU#18 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#16 (SN=15)

segment 2

68

The SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#18 in its data field to the UE. This AMD PDU segment carries part 1of AMD PDU#16, which contained RLC DL SDU#18 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#16 (SN=15)

segment 1

69

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#15 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#13, which contained RLC DL SDU#15 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#13 (SN=12)

segment 2

70

The SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#16 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#14, which contained RLC DL SDU#16 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#14 (SN=13)

segment 1

71

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#17 in its data field to the UE. This AMD PDU segment carries part 2 of PDU#15, which contained RLC DL SDU#17 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#15 (SN=14)

segment 2

72

The SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#21 in its data field to the UE. This AMD PDU segment carries part 1 of PDU #19, which contained RLC DL SDU#21 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#19 (SN=18)

segment 1

73

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#20 in its data field to the UE. This AMD PDU segment carries segment 2 of AMD PDU#18, which contained RLC DL SDU#20 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#18 (SN=17)

segment 2

73A

In the search space of the 3rd NPDCCH period after the transmission at step 73 the SS allocates one UL Grant of size 144 bits, sufficient for one RLC STATUS PDU (Note 9).

<–

Uplink Grant

73B

Check: Does the UE transmit a Status Report with NACK_SN=16, NACK_SN=17 with SOStart=0 and SOEnd=15, and NACK_SN=18 with SOStart=16 and SOEnd=32767 (special SOEnd value), and ACK_SN=20?

–>

STATUS PDU

13

P

74

In the search space of the next NPDCCH period after the transmission at step 73A the SS schedules four UL Grants of size 296 bits, each one sufficient for one RLC UL SDU to be looped back (Note 10).

<–

Uplink Grant

75

Check: Does the UE transmit an RLC UL SDU containing SDU#15 in its data field?

–>

(RLC UL SDU#15) (SN=9)

12

P

76

Check: Does the UE transmit an RLC UL SDU containing SDU#16 in its data field?

–>

(RLC UL SDU#16) (SN=10)

12

P

77

Check: Does the UE transmit an RLC UL SDU containing SDU#17 in its data field?

–>

(RLC UL SDU#17) (SN=11)

12

P

78

Check: Does the UE transmit an RLC UL SDU containing SDU#18 in its data field?

–>

(RLC UL SDU#18) (SN=12)

12

P

79

The SS transmits an RLC STATUS PDU to the UE. This PDU acks PDUs up to those including SDU#18. ACK_SN=13.

<–

STATUS PDU

80

Void

81

Void

82

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#21 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#19, which contained RLC DL SDU#21 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#19 (SN=18)

segment 2

83

The SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#20 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#18, which contained RLC DL SDU#20 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#18 (SN=17)

segment 1

84

The SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#19 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#17, which contained RLC DL SDU#19 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#17 (SN=16)

segment 1

85

In the search space of the 3rd NPDCCH period after the transmission at step 84 the SS schedules one UL Grant of size 104 bits, sufficient for one RLC STATUS PDU (Note 5).

<–

Uplink Grant

86

Check: Does the UE transmit a Status Report with NACK_SN=16 with SOStart=16 and SOEnd=32767 (special SOEnd value), and ACK_SN=20?

–>

STATUS PDU

13

P

87

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#19 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#17, which contained RLC DL SDU#19 (L bytes)in its data field. SO=16 and LSF=1.

<–

AMD PDU#17 (SN=16)

segment 2

88

In the search space of the 3rd NPDCCH period after the transmission at step 87 the SS schedules four UL Grants of size 296 bits, each one sufficient for one RLC UL SDU to be looped back (Note 10).

<–

Uplink Grant

89

Check: Does the UE transmit an RLC UL SDU containing SDU#19 in its data field?

–>

(RLC UL SDU#19) (SN=13)

12

P

90

Check: Does the UE transmit an RLC UL SDU containing SDU#20 in its data field?

–>

(RLC UL SDU#20) (SN=14)

12

P

91

Check: Does the UE transmit an RLC UL SDU containing SDU#21 in its data field?

–>

(RLC UL SDU#21) (SN=15)

12

P

92

Check: Does the UE transmit an RLC UL SDU containing SDU#22 in its data field?

–>

(RLC UL SDU#22) (SN=16)

12

P

93

The SS transmits an RLC STATUS PDU to the UE. This PDU acks PDUs up to those including SDU#21. ACK_SN=17.

<–

STATUS PDU

Note 1: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 2 bytes MAC SDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 35 bytes MAC SDU(2 bytes RLC AMD PDU header + 33 bytes UL RLC SDU) + 1 byte Padding).

Note 2: UL grant of 72 bits (ITBS=2, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and NACK_SN (2 bytes Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader + 1 byte Short BSR + 4 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 12-bit NACK_SN/E1/E2 + 5-bit Padding)).

Note 3: UL grant of 56 bits (ITBS=1, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN (2 bytes Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader + 1 byte Short BSR + 2 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 1bit padding)).

Note 4: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 2 bytes Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 36 bytes MAC SDU (4 bytes RLC AMD PDU header + 2*16 UL RLC SDU)).

Note 5: UL grant of 104 bits (ITBS=3, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and NACK_SN (2 bytes Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader + 1 byte Short BSR + 8 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 12-bit NACK_SN/E1/E2 + 30-bit SOstart/SOend + 7-bit Padding)).

Note 6: UL grant of 176 bits (ITBS=1, =4, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 18 bytes MAC SDU(2 bytes RLC AMD PDU header + 16 UL RLC SDU)).

Note 7: UL grant of 144 bits (ITBS=5, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and 2 NACK_SNs ( (1 byte Short BSR subheader + 2 byte MAC SDU subheader + 1 byte Padding subheader + 1 byte Short BSR + 9 bytes RLC Status PDU ( 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 12-bit NACK_SN/E1/E2 + (12-bit NACK_SN/E1/E2 + 30-bit SOstart/SOend) + 3-bit Padding) + 4 byte Padding) or (2 bytes Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader + 1 byte Short BSR + 13 bytes RLC Status PDU ( 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 2 x (12-bit NACK_SN/E1/E2 + 30-bit SOstart/SOend) + 5-bit Padding)) ).

Note 8: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 2 bytes MAC SDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 35 bytes MAC SDU(5 bytes RLC AMD PDU header + 3*10 UL RLC SDU) + 1 byte Padding).

Note 9: UL grant of 144 bits (ITBS=5, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and 3 NACK_SNs (1 byte Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader + 1 byte Short BSR + 14 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 12-bit NACK_SN/E1/E2 +2*(12-bit NACK_SN/E1/E2 + 30-bit SOstart/SOend) + 1-bit Padding)).

Note 10: UL grant of 296 bits (ITBS=9, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 34 bytes MAC SDU(2 bytes RLC AMD PDU header + 32 bytes UL RLC SDU)).

Note 11: UL grant of 392 bits (ITBS=8, =2, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Padding subheader + 1 byte Short BSR subheader + 2 bytes MAC SDU subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 35 bytes MAC SDU(2 bytes RLC AMD PDU header + 33 bytes UL RLC SDU) + 8 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 12-bit NACK_SN/E1/E2 + 30-bit SOstart/SOend + 7-bit Padding)).

Note 12: UL grant of 392 bits (ITBS=8, =2, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 2 bytes MAC SDU subheader + 2 byte MAC SDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 35 bytes MAC SDU(2 bytes RLC AMD PDU header + 33 bytes UL RLC SDU) + 2 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 1bit padding) + 5 bytes Padding).

22.3.2.5.3.3 Specific message contents

None.

22.3.2.6 NB-IoT / UM RLC / Correct use of sequence numbering / Concatenation, segmentation and reassembly / SC-MCCH and SC-MTCH

22.3.2.6.1 Test Purpose (TP)

(1)

with { UE in E-UTRAN RRC IDLE state and receiving an SC-PTM service }

ensure that {
when { UE receives UMD PDU on SC-MTCH containing a FI field set to 00 }

then { UE correctly decodes the received UMD PDU }

}

(2)

with { UE in E-UTRAN RRC IDLE state and receiving an SC-PTM service }

ensure that {
when { UE receives UMD PDU on SC-MTCH containing a FI field set to 01 }

then { UE correctly decodes the received UMD PDU }

}

(3)

with { UE in E-UTRAN RRC IDLE state and receiving an SC-PTM service }

ensure that {
when { UE receives UMD PDU on SC-MTCH containing a FI field set to 11 }

then { UE correctly decodes the received UMD PDU }

}

(4)

with { UE in E-UTRAN RRC IDLE state and receiving an SC-PTM service }

ensure that {
when { UE receives UMD PDU on SC-MTCH containing a FI field set to 10 }

then { UE correctly decodes the received UMD PDU }

}

}

(5)

with { UE in E-UTRAN RRC IDLE state and receiving an SC-PTM service }

ensure that {

when { UE receives UM PDUs on SC-MTCH with SN gap }

then { UE delivers them to the upper layer in sequence }

}

}

(6)

with { UE in E-UTRAN RRC IDLE state and receiving an SC-PTM service }

ensure that {

when { UE receives UM PDUs on SC-MTCH with SN falls outside of reordering window }

then { UE delivers them to the upper layer in sequence }

}

}

(7)

with { UE in E-UTRAN RRC IDLE state and receiving an SC-PTM service }

ensure that {

when { UE receives UM PDU on SC-MTCH with Length Indicator value larger than RLC PDU size }

then { UE discards the RLC PDU }

}

}

22.3.2.6.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.322, clauses 4.2.1, 5.1.2.2, 6.2.1.3, 6.2.2.6 and 7.2.

[TS 36.322, clause 4.2.1]

The description in this sub clause is a model and does not specify or restrict implementations.

RRC is generally in control of the RLC configuration. For NB-IoT, RRC configurable parameters are specified in RLC-Config-NB [5].

An RLC entity can be configured to perform data transfer in one of the following three modes: Transparent Mode (TM), Unacknowledged Mode (UM) or Acknowledged Mode (AM). Consequently, an RLC entity is categorized as a TM RLC entity, an UM RLC entity or an AM RLC entity depending on the mode of data transfer that the RLC entity is configured to provide. For NB-IoT, RLC UM is only supported for SC-MCCH and SC-MTCH.

[TS 36.322, clause 5.1.2.2]

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

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.

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

– 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 the reception buffer contains an UMD PDU with SN = VR(UR):

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

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

[TS 36.322, clause 6.2.1.3]

An UM RLC entity is configured by RRC to use either a 5 bit SN or a 10 bit SN. When the 5 bit SN is configured, the length of the fixed part of the UMD PDU header is one byte. When the 10 bit SN is configured, the fixed part of the UMD PDU header is identical to the fixed part of the AMD PDU header, except for D/C, RF and P fields all being replaced with R1 fields. The extension part of the UMD PDU header is identical to the extension part of the AMD PDU header (regardless of the configured SN size).

[TS 36.322, clause 6.2.2.5]

Length: 11 bits for RLC UM, 11 bits or 15 bits for RLC AM. The length of the LI field for RLC AM is configured by upper layers.

The LI field indicates the length in bytes of the corresponding Data field element present in the RLC data PDU delivered/received by an UM or an AM RLC entity. The first LI present in the RLC data PDU header corresponds to the first Data field element present in the Data field of the RLC data PDU, the second LI present in the RLC data PDU header corresponds to the second Data field element present in the Data field of the RLC data PDU, and so on. The value 0 is reserved.

[TS 36.322, clause 6.2.2.6]

Length: 2 bits.

The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 6.2.2.6-1.

Table 6.2.2.6-1: FI field interpretation

Value

Description

00

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

01

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

10

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

11

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

[TS 36.322, clause 7.2]

a) AM_Window_Size

This constant is used by both the transmitting side and the receiving side of each AM RLC entity to calculate VT(MS) from VT(A), and VR(MR) from VR(R). AM_Window_Size = 512 when a 10 bit SN is used, AM_Window_Size = 32768 when a 16 bit SN is used.

b) UM_Window_Size

This constant is used by the receiving UM RLC entity to define SNs of those UMD PDUs that can be received without causing an advancement of the receiving window. UM_Window_Size = 16 when a 5 bit SN is configured, UM_Window_Size = 512 when a 10 bit SN is configured and UM_Window_Size = 0 when the receiving UM RLC entity is configured for MCCH, MTCH, SC-MCCH, SC-MTCH or STCH for sidelink communication.

22.3.2.6.3 Test description

22.3.2.6.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

– System information combination 5 as defined in TS 36.508[18] clause 8.1.4.3.1 is used in Ncell 1.

– SCPTMConfiguration-NB as defined in TS 36.508[18] Table 8.1.6.1-15a is transmitted on SC-MCCH.

UE:

– E-UTRAN NB-IoT UE supporting SC-PTM services.

Preamble:

– UE is in NB-IoT UE Registered, Connected mode, UE Test Mode Activated (State 2A-NB) according to TS 36.508 [18] in Ncell 1(serving cell) with the UE Test Mode Activated.

– The UE is made interested in receiving SC-PTM service in the PLMN of Ncell 1 with MBMS Service ID 1.

22.3.2.6.3.2 Test procedure sequence

Table 22.3.2.6.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS transmits an RRCConnectionRelease-NB message to release RRC connection and move to RRC_IDLE.

<–

RRC: RRCConnectionRelease-NB

2

Wait for a period equal to the SC-MCCH repetition period for the UE to receive SCPTMConfiguration-NB message.

3

The generic procedures described in TS 36.508 subclause TS 36.508, clause 8.1.5A.2.3 and 8.1.5.2B.3 is performed on Ncell 1 to close UE test loop Mode F.

4

The SS transmits an RRCConnectionRelease-NB message to release RRC connection and move to RRC_IDLE.

<–

RRC: RRCConnectionRelease-NB

5

Wait for a period equal to the SC-MCCH repetition period for the UE to receive SCPTMConfiguration-NB message.

6

The SS transmits UMD PDU#1 containing a complete RLC SDU#1 (FI field = 00).

<–

UMD PDU#1 (SN=0)

7

The SS transmits UMD PDU#2 containing the first segment of RLC SDU#2 (FI field = 01).

<–

UMD PDU#2 (SN=1)

8

The SS transmits UMD PDU#3 containing the second segment of RLC SDU#2 (FI field = 11).

<–

UMD PDU#3 (SN=2)

9

The SS transmits UMD PDU#4 containing the last segment of RLC SDU#2 (FI field = 10).

<–

UMD PDU#4 (SN=3)

10

The generic procedures described in TS 36.508 subclause TS 36.508, clause 8.1.5A.2.3 are performed

11

The SS transmits an UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST message.

<–

RRC: DLInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST

12

UE responds with UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE.

–>

RRC: ULInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE

13

Check: Is the number of reported MBMS Packets received on the SC-MTCH in step 12 equal to 2?

1,2,3,4

P

14

The SS transmits an RRCConnectionRelease-NB message to release RRC connection and move to RRC_IDLE.

<–

RRC: RRCConnectionRelease-NB

15

Wait for a period equal to the SC-MCCH repetition period for the UE to receive SCPTMConfiguration-NB message.

16

The SS transmits UMD PDU#5 containing a complete RLC SDU#3.

<–

UMD PDU#5 (SN=6)

17

The SS transmits UMD PDU#6 containing a complete RLC SDU#4.

<–

UMD PDU#6 (SN=8)

18

The generic procedures described in TS 36.508 subclause TS 36.508, clause 8.1.5A.2.3 are performed

19

The SS transmits an UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST message.

<–

RRC: DLInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST

20

UE responds with UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE.

–>

RRC: ULInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE

21

Check: Is the number of reported MBMS Packets received on the SC-MTCH in step 20 equal to 4?

5

P

22

The SS transmits an RRCConnectionRelease-NB message to release RRC connection and move to RRC_IDLE.

<–

RRC: RRCConnectionRelease-NB

23

Wait for a period equal to the SC-MCCH repetition period for the UE to receive SCPTMConfiguration-NB message.

24

The SS transmits UMD PDU#8 containing a complete RLC SDU#4.

<–

UMD PDU#8 (SN=8)

25

The SS transmits UMD PDU#7 containing a complete RLC SDU#5.

<–

UMD PDU#7 (SN=7)

26

The generic procedures described in TS 36.508 subclause TS 36.508, clause 8.1.5A.2.3 are performed

27

The SS transmits an UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST message.

<–

RRC: DLInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST

28

UE responds with UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE.

–>

RRC: ULInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE

29

Check: Is the number of reported MBMS Packets received on the SC-MTCH in step 28 equal to 6?

6

P

30

The SS transmits an RRCConnectionRelease-NB message to release RRC connection and move to RRC_IDLE.

<–

RRC: RRCConnectionRelease-NB

31

Wait for a period equal to the SC-MCCH repetition period for the UE to receive SCPTMConfiguration-NB message.

32

The SS transmits UMD PDU#9 containing first segment of RLC SDU#6.

<–

UMD PDU#9 (SN=9)

33

The SS transmits UMD PDU#10 containing last segment of RLC SDU#6, first segment of RLC SDU#7 and with Length Indicator that points beyond the end of the UMD PDU#11.

<–

UMD PDU#10 (SN=10)

34

The SS transmits UMD PDU#11 containing last segment of RLC SDU#7.

<–

UMD PDU#11 (SN=11)

35

The generic procedures described in TS 36.508 subclause TS 36.508, clause 8.1.5A.2.3 are performed

36

The SS transmits an UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST message.

<–

RRC: DLInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER REQUEST

37

UE responds with UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE.

–>

RRC: ULInformationTransfer-NB

TC: UE TEST LOOP MODE F SCPTM PACKET COUNTER RESPONSE

38

Check: Is the number of reported MBMS Packets received on the SC-MTCH in step 37 greater than 6?

7

F

39

The SS transmits an RRCConnectionRelease-NB message to release RRC connection and move to RRC_IDLE.

<–

RRC: RRCConnectionRelease-NB

22.3.2.6.3.3 Specific message contents

Table 22.3.2.6.3.3-1: ACTIVATE TEST MODE (preamble)

Derivation Path: 36.508, Table 8.1.5.2A.4-1, condition UE TEST LOOP MODE F.

Table 21.1.4.3-2: CLOSE UE TEST LOOP (step 3, Table 22.3.2.6.3.2-1)

Derivation Path: 36.508, Table 8.1.5.2B.4-1, condition UE TEST LOOP MODE F

Table 22.3.2.6.3.3-3: SCPTMConfiguration-NB (preamble and all steps)

Derivation Path: 36.508, Table 8.1.6.1-15a

22.3.2.7 NB-IoT / AM RLC / Receiver status triggers / Non-zero t-Reordering configured

22.3.2.7.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state, configured for enableStatusReportSN-Gap and using AM RLC }

ensure that {
when { Reception failure of an RLC data PDU is detected }

then { UE initiates Status Reporting when t-Reordering expires }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }

ensure that {
when { Polling from peer AM RLC entity is detected and the sequence number of the PDU that carries the Poll is greater than or equal to VR(MS) }

then { UE waits until VR(MS) becomes greater than the sequence number of the PDU with the Poll before initiating Status Reporting }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state, configured for enableStatusReportSN-Gap and using AM RLC }

ensure that {
when { t-Reordering expires }

then { UE sets VR(MS) to SN of the first AMD PDU with SN >= VR(X) for which not all byte segments have been received }

}

22.3.2.7.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.1.3.2.1, 5.1.3.2.3, 5.1.3.2.4, 5.2.3.

[TS 36.322, clause 5.1.3.2.1]

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.

[TS 36.322, clause 5.1.3.2.3]

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

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

[TS 36.322, clause 5.1.3.2.4]

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

[TS 36.322, clause 5.2.3]

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

22.3.2.7.3 Test description

22.3.2.7.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

UE:

None.

Preamble

– The UE is in state 2B-NB according to [18] the exceptions listed in table 22.3.2.7.3.1-1 with test loop mode G closed.

– The HARQ process 0 is used for DL and UL transmissions as default.

Table 22.3.2.7.3.1-1: RLC settings

Parameter

Value

t-PollRetransmit-r13

ms4000

t-Reordering-r14

ms1600-v1310

enableStatusReportSN-Gap-r13

true

22.3.2.7.3.2 Test procedure sequence

If the start RLC UL and DL sequence numbers to be used at start of test body are non zero, but X and Y respectively due to transmission/reception of RLC PDU’s in preamble on bearer to be used, then any sequence number ‘n’ in test procedure maps as:

UL SQN n maps to SQN X+n MOD 1024 &

DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.2.7.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence.

Note: In steps 1 to 25 the size of each RLC UL SDU #1 – #6 is PRBS of 288 bits (36 octets). The size of the RLC SDUs used in downlink is L.

1

The SS transmits 3 AMD PDUs with SN=0, 1, 2. The SS sets the P field of all the AMD PDUs to 0

<–

AMD PDU#1 (SN=0, P=0)

AMD PDU#2 (SN=1, P=0)

AMD PDU#3 (SN=2, P=0)

2

In the search space of the 4th NPDCCH period after the first transmission at step 1 the SS schedules 3 consecutive UL grants with a time spacing of 3 NPDCCH cycles of size 328 bits. (NOTE 1)

<–

(UL grants, 328 bits)

3

The UE transmits RLC UL SDU#1.

–>

(RLC UL SDU#1)

4

The UE transmits RLC UL SDU#2.

–>

(RLC UL SDU#2)

5

The UE transmits RLC UL SDU#3.

–>

(RLC UL SDU#3)

6

The SS transmits a STATUS PDU

<–

STATUS PDU

7

The SS starts the UL periodic grant transmission of size 40 bits. (NOTE 2)

8

The SS transmits 1 AMD PDUs with SN=4 and P=0.

Record time TA.

<–

AMD PDU#5 (SN=4, P=0)

9

Check 1: Does the UE transmit a Status Report with NACK_SN=3 and ACK_SN=5?

Record time TB

Check 2: (TB – TA) = t-Reordering?

(NOTE 3)

–>

STATUS PDU

1

P

10

The SS stops to allocate any uplink grant.

11

In the search space of the 6th NPDCCH period after step 10 the SS transmits 1 AMD PDU with SN=3. The SS sets the P field to 1.

<–

AMD PDU#4 (SN=3, P=1)

12

In the search space of the 3rd NPDCCH period after the transmission at step 11 the SS schedules 1 UL grant of size 40 bits. (NOTE 2)

<–

(UL grant, 40 bits)

13

Check: Does the UE transmit a Status Report with no NACK_SN and ACK_SN=5?

–>

STATUS PDU

14

Starting with the search space of the next NPDCCH period after the transmission at step 12 the SS schedules 2 consecutive UL grants of size 328 bits. (NOTE 1)

<–

(UL grant, 328 bits)

15

The UE transmits RLC UL SDU#4.

–>

(RLC UL SDU#4)

16

The UE transmits RLC UL SDU#5.

–>

(RLC UL SDU#5)

17

The SS transmits a STATUS PDU

<–

STATUS PDU

18

The SS starts the UL periodic grant transmission of size 40 bits. (NOTE 2)

19

In the search space of the 6th NPDCCH period after step 18 the SS transmits an AMD PDU with SN=5 and P=0.

<–

AMD PDU#6 (SN=5, P=0)

19A

In the search space of the 7th NPDCCH period after step 18 the SS transmits an AMD PDU with SN=7 and P=1.

<–

AMD PDU#8 (SN=7, P=1)

20

Check: Does the UE transmit a Status Report in next 960 ms?

–>

STATUS PDU

2

F

21

In the search space of the 15th NPDCCH period after the transmission at step 19 the SS transmits an AMD PDU with SN=6 and P=0.

NOTE: AMD PDUs with SN 5, 6 and 7 carry RLC SDU #6.

(NOTE 4)

<–

AMD PDU#7 (SN=6, P=0)

22

Check: Does the UE transmit a Status Report with no NACK_SN and ACK_SN=8?

–>

STATUS PDU

2

P

23

The SS stops periodic grant and assigns 1 UL grant of size 328 bits. (NOTE 1)

<–

(UL grant, 328 bits)

24

The UE transmits RLC SDU#6.

–>

(RLC SDU#6)

25

The SS transmits a STATUS PDU

<–

STATUS PDU

Note: In steps 26 to 48 the size of the UL RLC SDU #7-#11 used in uplink will be 32 octets. The size of the RLC SDUs used in downlink is L.

26

The SS transmits one AMD PDU containing RLC DL SDU#11 (L bytes) in its data field to the UE. SN=12 indicates the loss of 4 PDUs.

<–

AMD PDU#13 (SN=12)

27

In the search space of the 3rd NPDCCH period after the transmission at step 26 the SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#7 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#9, which contained RLC DL SDU#7 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#9 (SN=8)

segment 1

28

In the search space of the 6th NPDCCH period after the transmission at step 26 the SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#8 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#10, which contained RLC DL SDU#8 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#10 (SN=9)

segment 2

29

In the search space of the 9th NPDCCH period after the transmission at step 26 the SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#7 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#9, which contained RLC DL SDU#7 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#9 (SN=8)

segment 2

30

In the search space of the 12th NPDCCH period after the transmission at step 26 the SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#8 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#10, which contained RLC DL SDU#8 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#10 (SN=9)

segment 1

31

In the search space of the 15th NPDCCH period after the transmission at step 26 the SS transmits one AMD PDU segment containing 16 bytes of RLC DL SDU#10 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU #12, which contained RLC DL SDU#10 (L bytes) in its data field. SO=0 and LSF=0.

<–

AMD PDU#12 (SN=11)

segment 1

32

Wait for t-Reordering to run out at the UE side. (NOTE 5).

33

In the search space of the 28th NPDCCH period after the transmission at step 26 the SS allocates one UL Grant of size 104 bits, sufficient for one RLC STATUS PDU (NOTE 5, 6).

<–

Uplink Grant

34

Check: Does the UE transmit a Status Report with NACK_SN=10, NACK_SN=11 with SOStart=16 and SOEnd=32767 (special SOEnd value), and ACK_SN=13?

–>

STATUS PDU

3

P

35

Starting with the search space of the next NPDCCH period after the transmission at step 33 the SS schedules two consecutive UL Grants of size 296 bits, each one sufficient for one RLC UL SDU to be looped back (NOTE 7).

<–

Uplink Grant

36

The UE transmits RLC UL SDU#7.

–>

(RLC UL SDU#7)

37

The UE transmits RLC UL SDU#8.

–>

(RLC UL SDU#8)

38

The SS transmits a STATUS PDU.

<–

STATUS PDU

39

The SS transmits one AMD PDU segment containing L-16 bytes of RLC DL SDU#10 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#12, which contained RLC DL SDU#10 (L bytes) in its data field. SO=16 and LSF=1.

<–

AMD PDU#12 (SN=11)

segment 2

40

Wait for t-Reordering to run out at the UE side. (NOTE 5).

41

In the search space of the 28th NPDCCH period after the transmission at step 39 the SS schedules one UL Grant of size 40 bits, sufficient for one RLC STATUS PDU (NOTE 5, 2).

<–

Uplink Grant

42

Check: Does the UE transmit a Status Report with NACK_SN=10 and ACK_SN=13?

–>

STATUS PDU

3

P

43

The SS transmits one AMD PDU containing RLC DL SDU#9 (L bytes) in its data field to the UE.

<–

AMD PDU#11 (SN=10)

44

Starting with the search space of the 3rd NPDCCH period after the transmission at step 43 the SS schedules three consecutive UL Grants of size 296 bits, each one sufficient for one RLC UL SDU to be looped back (NOTE 7).

<–

Uplink Grant

45

The UE transmits RLC UL SDU#9.

–>

(RLC UL SDU#9)

46

The UE transmits RLC UL SDU#10.

–>

(RLC UL SDU#10)

47

The UE transmits RLC UL SDU#11.

–>

(RLC UL SDU#11)

48

The SS transmits a STATUS PDU.

<–

STATUS PDU

NOTE 1: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time. (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC PDU subheader, 1 byte Short BSR + 38 bytes MAC SDU(16-bit RLC AMD PDU header + 288-bit UL RLC SDU)).

NOTE 2: UL grant of 40 bits (ITBS=3, =0, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and (8-bit short BSR + 2x 8-bit MAC PDU subheader + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 1bit padding).

NOTE 3: The Timer tolerances for t-Reordering is the transmission time of periodic grant and AMD PDU with SN=4 + handling time on UE side.

NOTE 4: With an NPDCCH period of 64ms 15 NPDCCH periods are 0.96s i.e. the transmission at step 21 happens at about 60% of t-Reordering expiry (1.6s).

NOTE 5: With an NPDCCH period of 64ms 28 NPDCCH periods are 1.792s i.e. the transmission at step 33/41 happens later than t-Reordering expiry (1.6s) + 10%.

NOTE 6: UL grant of 104 bits (ITBS=3, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and 2 NACK_SNs (1 byte Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader + 1 byte Short BSR + 9 bytes RLC Status PDU (4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 12-bit NACK_SN/E1/E2 + (12-bit NACK_SN/E1/E2 + 30-bit SOstart/SOend) + 3-bit Padding)).

NOTE 7: UL grant of 296 bits (ITBS=9, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 34 bytes MAC SDU(2 bytes RLC AMD PDU header + 32 bytes UL RLC SDU)).

22.3.2.7.3.3 Specific message contents

Table 22.3.2.7.3.3-2: RRCConnectionSetup-NB (preamble, Table 22.3.2.7.3.2-1)

Derivation path: 36.508 table 8.1.6.1-14

Information Element

Value/remark

Comment

Condition

RRCConnectionSetup-NB ::= SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE {

rrcConnectionSetup-r13 SEQUENCE {

radioResourceConfigDedicated-r13 SEQUENCE {

physicalConfigDedicated-r13 SEQUENCE {

twoHARQ-ProcessesConfig-r14

true

}

}

}

}

}

}

22.3.2.7a NB-IoT / NTN / AM RLC / Receiver status triggers / extended t-Reordering configured

22.3.2.7a.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state and twoHARQ-ProcessesConfig is set to TRUE }

ensure that {
when { t-ReorderingExt-r17 is configured }

then { UE ignores the value signalled by t-Reordering-r14 and uses the extended value t-ReorderingExt-r17 }

}

22.3.2.7a.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.1.3.2.3, 5.1.3.2.4, 7.1 and TS 36.331 clause 6.7.3. Unless otherwise stated these are Rel-17 requirements.

[TS 36.322, clause 5.1.3.2.3]

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

[TS 36.322, clause 5.1.3.2.4]

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

[TS 36.322, clause 7.1]

This sub clause describes the state variables used in AM and UM entities in order to specify the RLC protocol. The state variables defined in this subclause are normative.

All state variables and all counters are non-negative integers.

All state variables related to AM data transfer can take values from 0 to 1023 for 10 bit SN or from 0 to 65535 for 16 bit SN. All arithmetic operations contained in the present document on state variables related to AM data transfer are affected by the AM modulus (i.e. final value = [value from arithmetic operation] modulo 1024 for 10 bit SN and 65536 for 16 bit SN).

All state variables related to UM data transfer can take values from 0 to [2[sn-FieldLength] – 1]. All arithmetic operations contained in the present document on state variables related to UM data transfer are affected by the UM modulus (i.e. final value = [value from arithmetic operation] modulo 2[sn-FieldLength]).

AMD PDUs and UMD PDUs are numbered integer sequence numbers (SN) cycling through the field: 0 to 1023 for 10 bit SN and 0 to 65535 for 16 bit SN for AMD PDU and 0 to [2[sn-FieldLength] – 1] for UMD PDU.

When performing arithmetic comparisons of state variables or SN values, a modulus base shall be used.

VT(A) and VR(R) shall be assumed as the modulus base at the transmitting side and receiving side of an AM RLC entity, respectively. This modulus base is subtracted from all the values involved, and then an absolute comparison is performed (e.g. VR(R) <= SN < VR(MR) is evaluated as [VR(R) – VR(R)] modulo 1024 <= [SN – VR(R)] modulo 1024 < [VR(MR) – VR(R)] modulo 1024).

VR(UH) – UM_Window_Size shall be assumed as the modulus base at the receiving side of an UM RLC entity. This modulus base is subtracted from all the values involved, and then an absolute comparison is performed (e.g. (VR(UH) – UM_Window_Size) <= SN < VR(UH) is evaluated as [(VR(UH) – UM_Window_Size) – (VR(UH) – UM_Window_Size)] modulo 2[sn-FieldLength] <= [SN – (VR(UH) – UM_Window_Size)] modulo 2[sn-FieldLength] < [VR(UH) – (VR(UH) – UM_Window_Size)] modulo 2[sn-FieldLength]).

The transmitting side of each AM RLC entity shall maintain the following state variables:

a) VT(A) – Acknowledgement state variable

This state variable holds the value of the SN of the next AMD PDU for which a positive acknowledgment is to be received in-sequence, and it serves as the lower edge of the transmitting window. It is initially set to 0, and is updated whenever the AM RLC entity receives a positive acknowledgment for an AMD PDU with SN = VT(A).

b) VT(MS) – Maximum send state variable

This state variable equals VT(A) + AM_Window_Size, and it serves as the higher edge of the transmitting window.

c) VT(S) – Send state variable

This state variable holds the value of the SN to be assigned for the next newly generated AMD PDU. It is initially set to 0, and is updated whenever the AM RLC entity delivers an AMD PDU with SN = VT(S).

d) POLL_SN – Poll send state variable

This state variable holds the value of VT(S)-1 upon the most recent transmission of a RLC data PDU with the poll bit set to “1”. It is initially set to 0.

The transmitting side of each AM RLC entity shall maintain the following counters:

a) PDU_WITHOUT_POLL – Counter

This counter is initially set to 0. It counts the number of AMD PDUs sent since the most recent poll bit was transmitted.

b) BYTE_WITHOUT_POLL – Counter

This counter is initially set to 0. It counts the number of data bytes sent since the most recent poll bit was transmitted.

c) RETX_COUNT – Counter

This counter counts the number of retransmissions of an AMD PDU (see subclause 5.2.1). There is one RETX_COUNT counter per PDU that needs to be retransmitted.

The receiving side of each AM RLC entity shall maintain the following state variables:

a) VR(R) – Receive state variable

This state variable holds the value of the SN following the last in-sequence completely received AMD PDU, and it serves as the lower edge of the receiving window. It is initially set to 0, and is updated whenever the AM RLC entity receives an AMD PDU with SN = VR(R).

b) VR(MR) – Maximum acceptable receive state variable

This state variable equals VR(R) + AM_Window_Size, and it holds the value of the SN of the first AMD PDU that is beyond the receiving window and serves as the higher edge of the receiving window.

c) VR(X) – t-Reordering state variable

This state variable holds the value of the SN following the SN of the RLC data PDU which triggered t-Reordering.

d) VR(MS) – Maximum STATUS transmit state variable

This state variable holds the highest possible value of the SN which can be indicated by “ACK_SN” when a STATUS PDU needs to be constructed. It is initially set to 0.

e) VR(H) – Highest received state variable

This state variable holds the value of the SN following the SN of the RLC data PDU with the highest SN among received RLC data PDUs. It is initially set to 0.

Each transmitting UM RLC entity shall maintain the following state variables:

a) VT(US)

This state variable holds the value of the SN to be assigned for the next newly generated UMD PDU. It is initially set to 0, and is updated whenever the UM RLC entity delivers an UMD PDU with SN = VT(US).

Each receiving UM RLC entity shall maintain the following state variables:

a) VR(UR) – UM receive state variable

This state variable holds the value of the SN of the earliest UMD PDU that is still considered for reordering. It is initially set to 0. For RLC entity configured for STCH, it is initially set to the SN of the first received UMD PDU.

b) VR(UX) – UM t-Reordering state variable

This state variable holds the value of the SN following the SN of the UMD PDU which triggered t-Reordering.

c) VR(UH) – UM highest received state variable

This state variable holds the value of the SN following the SN of the UMD PDU with the highest SN among received UMD PDUs, and it serves as the higher edge of the reordering window. It is initially set to 0. For RLC entity configured for STCH, it is initially set to the SN of the first received UMD PDU.

[TS 36.331, clause 6.7.3]

t-ReorderingExt

Timer for reordering in TS 36.322 [7], in milliseconds.

The UE shall use the extended value t-ReorderingExt-r17, if present, and ignore the value signalled by t-Reordering-r14.

E-UTRAN may configure t-ReorderingExt only if twoHARQ-ProcessesConfig is set to TRUE.

Conditional presence

Explanation

twoHARQ

The field is mandatory present if twoHARQ-ProcessesConfig is set to TRUE. Otherwise, the field is not present and, if previously configured, the timer is released.

22.3.2.7a.3 Test description

22.3.2.7a.3.1 Pre-test conditions

System Simulator:

– Ncell 1 is configured according to Table 8.1.4.2-3 and Table 8.1.4.2-5 in TS 36.508 [18].

– System information combination 8 as defined in TS 36.508 [18] clause 8.1.4.3.1.1 is used.

UE:

– The UE is in Automatic PLMN selection mode.

– The UE’s positioning engine (e.g., standalone GNSS receiver) should be enabled to allow it to acquire the position. This could be done by use of AT command, such as AT+CPOS or other commands. Otherwise, or in addition any other suitable method may also be used, e.g., GNSS simulator.

Preamble

– The UE is in state 2B-NB according to TS 38.508 [18] clause 8.1.5.2B with the exceptions listed in table 22.3.2.7a.3.1-1 with test loop mode G closed.

– The HARQ process 0 is used for DL and UL transmissions as default.

Table 22.3.2.7a.3.1-1: RLC settings

Parameter

Value

t-PollRetransmit-r13

ms4000

t-Reordering-r14

ms1600-v1310

enableStatusReportSN-Gap-r13

true

22.3.2.7a.3.2 Test procedure sequence

If the start RLC UL and DL sequence numbers to be used at start of test body are non zero, but X and Y respectively due to transmission/reception of RLC PDU’s in preamble on bearer to be used, then any sequence number ‘n’ in test procedure maps as:

UL SQN n maps to SQN X+n MOD 1024 &

DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.2.7a.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence.

Note: In steps 1 to 8 the size of each RLC UL SDU #1 – #3 is PRBS of 288 bits (36 octets). The size of the RLC SDUs used in downlink is L.

1

The SS transmits 3 AMD PDUs with SN=0, 1, 2. The SS sets the P field of all the AMD PDUs to 0

<–

AMD PDU#1 (SN=0, P=0)

AMD PDU#2 (SN=1, P=0)

AMD PDU#3 (SN=2, P=0)

2

In the search space of the 4th NPDCCH period after the first transmission at step 1 the SS schedules 3 consecutive UL grants with a time spacing of 3 NPDCCH cycles of size 328 bits. (NOTE 1)

<–

(UL grants, 328 bits)

3

The UE transmits RLC UL SDU#1.

–>

(RLC UL SDU#1)

4

The UE transmits RLC UL SDU#2.

–>

(RLC UL SDU#2)

5

The UE transmits RLC UL SDU#3.

–>

(RLC UL SDU#3)

6

The SS transmits a STATUS PDU

<–

STATUS PDU

7

The SS starts the UL periodic grant transmission of size 40 bits. (NOTE 2)

8

The SS transmits 1 AMD PDUs with SN=4 and P=0.

Record time TA.

<–

AMD PDU#5 (SN=4, P=0)

9

Check 1: Does the UE transmit a Status Report with NACK_SN=3 and ACK_SN=5?

Record time TB

Check 2: (TB – TA) = t-ReorderingExt-r17?

(NOTE 3)

–>

STATUS PDU

1

P

NOTE 1: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time. (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC PDU subheader, 1 byte Short BSR + 38 bytes MAC SDU(16-bit RLC AMD PDU header + 288-bit UL RLC SDU)).

NOTE 2: UL grant of 40 bits (ITBS=3, =0, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit a Status Report with ACK_SN and (8-bit short BSR + 2x 8-bit MAC PDU subheader + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 1bit padding).

NOTE 3: The Timer tolerances for t-ReorderingExt is the transmission time of periodic grant and AMD PDU with SN=4 + handling time on UE side.

22.3.2.7a.3.3 Specific message contents

Table 22.3.2.7a.3.3-1: RRCConnectionSetup-NB (preamble, Table 22.3.2.7a.3.2-1)

Derivation path: TS 36.508 [18] table 8.1.6.1-14

Information Element

Value/remark

Comment

Condition

RRCConnectionSetup-NB ::= SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE {

rrcConnectionSetup-r13 SEQUENCE {

radioResourceConfigDedicated-r13 SEQUENCE {

srb-ToAddModList-r13 SEQUENCE (SIZE (1)) OF SRB-ToAddMod-NB-r13 SEQUENCE {

1 entry

SRB-ToAddMod-NB-r13[1] SEQUENCE {

rlc-Config-r13 CHOICE {

explicitValue CHOICE {

am SEQUENCE {

ul-AM-RLC-r13 SEQUENCE {

t-PollRetransmit-r13

ms400

maxRetxThreshold-r13

t2

}

dl-AM-RLC-r13 SEQUENCE {

enableStatusReportSN-Gap-r13

true

}

}

}

}

rlc-Config-v1430 SEQUENCE {

t-Reordering-r14

ms1600-v1310

}

rlc-Config-v1700 SEQUENCE {

t-ReorderingExt-r17 CHOICE {

Setup

ms3200

}

}

}

}

physicalConfigDedicated-r13 SEQUENCE {

twoHARQ-ProcessesConfig-r14

true

}

}

}

}

}

}

22.3.2.8 NB-IoT / UM RLC / Correct use of sequence numbering / Concatenation, segmentation and reassembly / Duplicate detection / User plane

22.3.2.8.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives a 5 bit SN configured UMD PDU containing a FI field set to 00 }

then { UE correctly decodes the received UMD PDU }

}

(2)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives a 5 bit SN configured UMD PDU containing a FI field set to 01 }

then { UE correctly decodes the received UMD PDU }

}

(3)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives a 5 bit SN configured UMD PDU containing a FI field set to 11 }

then { UE correctly decodes the received UMD PDU }

}

(4)

with { UE in RRC_CONNECTED state }

ensure that {
when { UE receives a 5 bit SN configured UMD PDU containing a FI field set to 10 }

then { UE correctly decodes the received UMD PDU }

}

(5)

with { UE in RRC_CONNECTED state }

ensure that {

when { The UE receives UMD PDUs containing concatenated RLC SDUs}

then { The UE reassembles the RLC SDUs in accordance with the Framing Info and Length Indicators indicated in UMD PDUs }

}

(6)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE transmits the first PDU }

then { UE sets the Sequence Number field equal to 0 if RLC layer was newly established or to the last used sequence number + 1 }

}

(7)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE transmits subsequent PDUs }

then { SN incremented by 1 for each PDU transmitted }

}

(8)

with { UE in RRC_CONNECTED state }

ensure that {

when { The UE has multiple RLC SDUs in the transmission buffer that fits into the available UMD PDU size }

then { The UE concatenates the RLC SDUs in the transmission buffer into one UMD PDU and transmits it}

}

(9)

with { UE in RRC_CONNECTED state }

ensure that {

when { The UE has RLC SDU in the transmission buffer that does not fit into the available UMD PDU size }

then { The UE segments the RLC SDU in accordance with the Framing Info and Length Indicators indicated in UMD PDUs }

}

(10)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives a 5 bit SN configured UM PDU with Length Indicator value larger than RLC PDU size }

then { UE discards the RLC PDU }

}

(11)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives duplicate UMD PDUs whose SN is within the reordering window }

then { UE discards the duplicate UMD PDUs }

}

(12)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives UM PDUs with SN gap and with t-Reordering not configured }

then { UE delivers them to the upper layer in sequence }

}

22.3.2.8.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.322, clauses 4.2.1, 5.1.2.2.1, 5.1.2.2.2, 5.1.2.2.3, 5.1.2.2.4, 6.2.1.3, 6.2.2.5, 6.2.2.6, 7.2 and TS 36.331, clauses 6.7.3.2.

[TS 36.322, clause 4.2.1]

The description in this sub clause is a model and does not specify or restrict implementations.

RRC is generally in control of the RLC configuration. For NB-IoT, RRC configurable parameters are specified in RLC-Config-NB [5].

An RLC entity can be configured to perform data transfer in one of the following three modes: Transparent Mode (TM), Unacknowledged Mode (UM) or Acknowledged Mode (AM). Consequently, an RLC entity is categorized as a TM RLC entity, an UM RLC entity or an AM RLC entity depending on the mode of data transfer that the RLC entity is configured to provide.

[TS 36.322, clause 5.1.2.2.1]

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.

[TS 36.322, clause 5.1.2.2.2]

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.

[TS 36.322, clause 5.1.2.2.3]

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

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

[TS 36.322, clause 5.1.2.2.4]

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

[TS 36.322, clause 6.2.1.3]

Except for NB-IoT, an UM RLC entity is configured by RRC to use either a 5 bit SN or a 10 bit SN. For NB-IoT, an UM RLC entity uses a 5 bit SN. When the 5 bit SN is used, the length of the fixed part of the UMD PDU header is one byte. When the 10 bit SN is used, the fixed part of the UMD PDU header is identical to the fixed part of the AMD PDU header, except for D/C, RF and P fields all being replaced with R1 fields. The extension part of the UMD PDU header is identical to the extension part of the AMD PDU header (regardless of the configured SN size).

Figure 6.2.1.3-1: UMD PDU with 5 bit SN (No LI)

Figure 6.2.1.3-3: UMD PDU with 5 bit SN (Odd number of LIs, i.e. K = 1, 3, 5, …)

[TS 36.322, clause 6.2.2.5]

Length: 11 bits for RLC UM, 11 bits or 15 bits for RLC AM. The length of the LI field for RLC AM is configured by upper layers.

The LI field indicates the length in bytes of the corresponding Data field element present in the RLC data PDU delivered/received by an UM or an AM RLC entity. The first LI present in the RLC data PDU header corresponds to the first Data field element present in the Data field of the RLC data PDU, the second LI present in the RLC data PDU header corresponds to the second Data field element present in the Data field of the RLC data PDU, and so on. The value 0 is reserved.

[TS 36.322, clause 6.2.2.6]

Length: 2 bits.

The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 6.2.2.6-1.

Table 6.2.2.6-1: FI field interpretation

Value

Description

00

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

01

First byte of the Data field corresponds to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

10

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field corresponds to the last byte of a RLC SDU.

11

First byte of the Data field does not correspond to the first byte of a RLC SDU.

Last byte of the Data field does not correspond to the last byte of a RLC SDU.

[TS 36.322, clause 7.2]

b) UM_Window_Size

This constant is used by the receiving UM RLC entity to define SNs of those UMD PDUs that can be received without causing an advancement of the receiving window. UM_Window_Size = 16 when a 5 bit SN is used, UM_Window_Size = 512 when a 10 bit SN is used and UM_Window_Size = 0 when the receiving UM RLC entity is configured for MCCH, MTCH, SC-MCCH, SC-MTCH or STCH for sidelink communication.

[TS 36.331, clause 6.7.3.2]

The IE RLC-Config-NB is used to specify the RLC configuration of SRBs and DRBs.

RLC-Config-NB information element

— ASN1START

RLC-Config-NB-r13 ::= CHOICE {

am SEQUENCE {

ul-AM-RLC-r13 UL-AM-RLC-NB-r13,

dl-AM-RLC-r13 DL-AM-RLC-NB-r13

},

…,

um-Bi-Directional-r15 NULL,

um-Uni-Directional-UL-r15 NULL,

um-Uni-Directional-DL-r15 NULL

}

[TS 36.323, clause 6.2.4]

Figure 6.2.4.1 shows the format of the PDCP Data PDU when a 7 bit SN length is used. This format is applicable for PDCP Data PDUs carrying data from DRBs mapped on RLC UM or in NB-IoT DRBs mapped on RLC AM and on RLC UM.

Figure 6.2.4.1: PDCP Data PDU format for DRBs using 7 bit SN

22.3.2.8.3 Test description

22.3.2.8.3.1 Pre-test conditions

System Simulator:

– Ncell 1

UE:

None.

Preamble:

– The UE is in state 3A-NB according to [18] with test loop mode A activated.

22.3.2.8.3.2 Test procedure sequence

Table 22.3.2.8.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

0A-0H

The generic test procedure in TS 36.508 clause 8.1.5A.9 is performed to establish radio bearers with the RLC UM settings in User Plane.

0I-0J

The generic test procedures in TS 36.508 clause 8.1.5.2B.3 is performed to close UE test loop Mode A.

Note: In steps 1 to 9 the size of the RLC SDUs will be 34 octets.

1

The SS does not respond to PRACH preambles transmitted by UE for Uplink transmission, but instead allocates the UL C-RNTI grant on NPDCCH when specified in the test sequence.

2

The SS transmits UMD PDU#1 containing a complete RLC SDU#1 (FI field = 00).

<–

UMD PDU#1 (SN=0)

3

In the search space of the 3rd NPDCCH period after the transmission at step 2 the SS schedules one UL Grant of size 328 bits, sufficient for one RLC UL SDU to be looped back (Note 1).

<–

Uplink Grant

4

Check: Does the UE transmit an UMD PDU with SN = 0 containing RLC SDU#1?

–>

(RLC UL SDU#1) (SN=0)

1,6

P

5

The SS transmits UMD PDU#2 containing the first segment (11 octets) of RLC SDU#2 (FI field = 01).

<–

UMD PDU#2 (SN=1)

6

In the NPDCCH period following step 5 the SS transmits UMD PDU#3 containing the second segment (12 octets) of RLC SDU#2 (FI field = 11).

<–

UMD PDU#3 (SN=2)

7

In the NPDCCH period following step 6 the SS transmits UMD PDU#4 containing the last segment (11 octets) of RLC SDU#2 (FI field = 10).

<–

UMD PDU#4 (SN=3)

8

In the search space of the 3rd NPDCCH period after the transmission at step 7 the SS schedules one UL Grant of size 328 bits, sufficient for one RLC UL SDU to be looped back (Note 1).

<–

Uplink Grant

9

Check: Does the UE transmit an UMD PDU with SN = 1 containing RLC SDU#2?

–>

(RLC UL SDU#2) (SN=1)

2,3,4,7

P

Note: In steps 10 to 12 the size of the RLC SDUswill be 17 octets.

10

SS transmits an UMD PDU#5 containing complete RLC SDU#3 and RLC SDU#4. Header of UMD PDU#5 contains FI=’00’, E=’1’, SN=4, E1=’0’, LI1=’17’.

<–

UMD PDU#5 (RLC SDU#3 and RLC SDU#4)

(FI=’00’, E=’1’, SN=4, E1=’0’, LI1=’17’)

11

In the search space of the 3rd NPDCCH period after the transmission at step 10 the SS schedules one UL Grant of size 328 bits, sufficient for two RLC UL SDUs to be looped back (Note 2).

<–

Uplink Grant

12

Check: Does UE transmit RLC SDU#3 and RLC SDU#4 within UMD PDU with FI field set to ‘00’, E field in the fixed part set to ‘1’, first E field in the extension part set to ‘0’ and first LI field set to 17 bytes?

–>

(RLC UL SDU#3 and RLC UL SDU#4) (SN=2)

5,8

P

Note: In steps 13 to 17 the size of the RLC SDUs will be 54 octets.

13

The SS transmits UMD PDU#6 containing a complete RLC SDU#5 (FI field = 00).

<–

UMD PDU#6 (SN=5)

14

In the search space of the 3rd NPDCCH period after the transmission at step 13 the SS schedules three UL Grants of size 176 bits, each one sufficient for one segment of RLC UL SDU to be looped back (Note 3).

15

Check: Does UE transmit first part (18 octets) of RLC SDU#5 within UMD PDU with FI field set to ‘01’ and E field in the fixed part set to ‘0’?

–>

(first part of RLC UL SDU#5) (SN=3)

9

P

16

Check: Does UE transmit second part (18 octets) of RLC SDU#5 within an UMD PDU with FI field set to ‘11’and E field in the fixed part set to ‘0’?

–>

(second part of RLC UL SDU#5) (SN=4)

9

P

17

Check: Does UE transmit last part (18 octets) of RLC SDU#5 within an UMD PDU with FI field set to ‘10’and E field in the fixed part set to ‘0’?

–>

(last part of RLC UL SDU#5) (SN=5)

9

P

Note: In steps 18 to 25 the size of the RLC SDUs will be 17 octets.

18

The SS transmits UMD PDU#7 containing first segment (9 octets) of RLC SDU#6 (FI field = 01).

<–

UMD PDU#7 (SN=6)

19

In the NPDCCH period following step 18 the SS transmits UMD PDU#8 containing last segment (8 octets) of RLC SDU#6, first segment (9 octets) of RLC SDU#7 and with Length Indicator that points beyond the end of the UMD PDU#8 (FI field = 11).

<–

UMD PDU#8 (SN=7)

20

In the NPDCCH period following step 19 the SS transmits UMD PDU#9 containing last segment (8 octets) of RLC SDU#7 and a complete RLC SDU#8 (FI field = 10).

<–

UMD PDU#9 (SN=8)

21

In the search space of the 3rd NPDCCH period after the transmission at step 20 the SS schedules one UL Grant of size 328 bits, sufficient for one RLC UL SDU to be looped back (Note 4).

<–

Uplink Grant

22

Check: Does the UE transmit an UMD PDU with SN = 6 containing RLC SDU#8?

–>

(RLC UL SDU#8) (SN=6)

10

P

23

The SS transmits UMD PDU#11 containing a complete RLC SDU#9(FI field = 00).

<–

UMD PDU#11 (SN=10)

24

In the search space of the 3rd NPDCCH period after the transmission at step 23 the SS schedules one UL Grant of size 176 bits, sufficient for one RLC UL SDU to be looped back (Note 5).

<–

Uplink Grant

25

Check: Does the UE transmit an UMD PDU with SN = 7 containing RLC SDU#9?

–>

(RLC UL SDU#9) (SN=7)

12

P

26

The SS transmits UMD PDU#1 containing a complete RLC SDU#1 (FI field = 00) same as step 2.

<–

UMD PDU#1 (SN=0)

27

In the search space of the 3rd NPDCCH period after the transmission at step 26 the SS schedules one UL Grant of size 328 bits, sufficient for one RLC UL SDU to be looped back (Note 1).

<–

Uplink Grant

28

Check: Does the UE transmit an UMD PDU with SN = 0 containing RLC SDU#1 in the next 5s?

–>

(RLC UL SDU#1) (SN=0)

11

F

Note 1: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 2 bytes MAC SDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 35 bytes MAC SDU(1 byte RLC UMD PDU header + 34 bytes UL RLC SDU) + 1 byte Padding).

Note 2: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 37 bytes MAC SDU (3 bytes RLC UMD PDU header + 2*17 bytes UL RLC SDU)).

Note 3: UL grant of 176 bits (ITBS=1, =4, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 19 bytes MAC SDU(1 byte RLC UMD PDU header + 18 bytes one part of UL RLC SDU)).

Note 4: UL grant of 328 bits (ITBS=10, =1, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Short BSR subheader + 2 bytes MAC SDU subheader + 1 byte Padding subheader, 1 byte Short BSR + 18 bytes MAC SDU(1 byte RLC UMD PDU header + 17 bytes UL RLC SDU) + 18 bytes Padding).

Note 5: UL grant of 176 bits (ITBS=1, =4, see TS 36.213 Table 16.5.1.2-2) is chosen to allow the UE to transmit one PDU at a time (MAC subheader: 1 byte Padding subheader + 1 byte Short BSR subheader + 1 byte MAC SDU subheader, 1 byte Short BSR + 18 bytes MAC SDU(1 byte RLC UMD PDU header + 17 bytes UL RLC SDU)).

22.3.2.8.3.3 Specific message contents

Table 22.3.2.8.3.3-1: DRB-ToAddMod-NB-DEFAULT(bid) (Step 0G, Table 22.3.2.8.3.2-1)

Derivation Path: 36.331 clause 6.7.3

Information Element

Value/remark

Comment

Condition

DRB-ToAddMod-NB-DEFAULT(bid) ::= SEQUENCE {

bid is the bearer identity 1.

eps-BearerIdentity-r13

bid+4

drb-Identity-r13

bid

pdcp-Config-r13

PDCP-Config-NB-DRB

rlc-Config-r13

RLC-Config-NB-DRB-UM

logicalChannelIdentity-r13

bid+3

logicalChannelConfig-r13

LogicalChannelConfig-NB-DRB

rlc-Config-v1430

Not present

}

Table 22.3.2.8.3.3-2: RLC-Config-NB-DRB-UM (Table 22.3.2.8.3.3-1)

Derivation Path: 36.331 clause 6.7.3

Information Element

Value/remark

Comment

Condition

RLC-Config-NB-DRB-UM ::= CHOICE {

um-Bi-Directional-r15

NULL

}