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

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

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 4^th 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 T_A 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 55^th 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 T_B. Check 2: Is (T_B – T_A) = 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’,E₁=’0’, LI₁=’L1’ bytes), 2 RLC DL SDUs of L1 bytes)	–	–
9	In the search space of the 3^rd 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, E₁=’0’, LI₁=’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 9^th 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’, E₁=’1’, LI₁=’ L2’ bytes, E₂=’0’, LI₂=’L2’ bytes), three RLC DLSDUs of size L2 bytes)	–	–
13	In the search space of the 3^rd 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, E₁=’1’, LI₁=’10’, E₂=’0’, LI₂=’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 (I_TBS=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 (I_TBS=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 + 220 UL RLC SDU) + 8 bytes Padding)). NOTE 3: UL grant of440 bits (I_TBS=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 + 310 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

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 4^th 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 6^th 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 3^rd 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 3^rd 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 6^th 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 3^rd 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 65 + L-(65) 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 3^rd 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 (I_TBS=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 (I_TBS=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 (I_TBS=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 (I_TBS=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 (I_TBS=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.