22.3.1 MAC

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.1.1 NB-IoT / RACH Procedure / Preamble Selected by MAC / Temporary C-RNTI

22.3.1.1.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_IDLE state }

ensure that {

when { UE has need to send a CCCH UL MAC PDU and UE is in enhanced coverage level 0}

then { UE transmits a random access preamble repeated numRepetitionPerPreambleAttempt from Random Access Preambles group and the NPRACH resource corresponding to enhanced coverage level 0}

}

(2)

with { UE in E-UTRA RRC_IDLE state }

ensure that {

when { UE has need to send a CCCH UL MAC PDU and UE is in enhanced coverage level 1}

then { UE transmits a random access preamble repeated numRepetitionPerPreambleAttempt from Random Access Preambles group and the NPRACH resource corresponding to enhanced coverage level 1}

}

(3)

with { UE in E-UTRA RRC_IDLE state }

ensure that {

when { UE has need to send a CCCH UL MAC PDU and UE is in enhanced coverage level 2}

then { UE transmits a random access preamble repeated numRepetitionPerPreambleAttempt from Random Access Preambles group and the NPRACH resource corresponding to enhanced coverage level 2}

}

(4)

with { UE in E-UTRA RRC_IDLE state after transmission of a NPRACH preamble as per enhanced coverage level 0 or 1}

ensure that {

when { SS does not answer with a matching Random Access Response but only non matching RAR within ra-ResponseWindowSize and PREAMBLE_TRANSMISSION_COUNTER_CE = maxNumPreambleAttemptCE for the corresponding coverage level + 1}

then { UE transmits a random access preamble repeated numRepetitionPerPreambleAttempt from Random Access Preambles group and the NPRACH resource corresponding to enhanced coverage level 1, 2 respectively}

}

(5)

with { UE in E-UTRA RRC_IDLE state after transmission of a NPRACH preamble }

ensure that {

when { SS does not answer with a matching Random Access Response but only non matching RAR within ra-ResponseWindowSize and PREAMBLE_TRANSMISSION_COUNTER <= preambleTransMax-CE }

then { UE retransmits the NPRACH preamble }

}

(6)

with { UE in E-UTRA RRC_IDLE state and transmitted NPRACH preamble }

ensure that {

when { UE receives during TTI window [RA_WINDOW_BEGIN—RA_WINDOW_END] MAC PDU containing multiple RAR’s but none of the subheaders contains a RAPID corresponding to the UE }

then { UE transmits a random access preamble in the next available Random Access occasion }

}

(7)

with { UE in E-UTRA RRC_IDLE state and transmitted NPRACH preamble }

ensure that {

when { SS transmits during RA Response window MAC PDU containing multiple RAR’s and one of the subheaders contains a RAPID corresponding to the UE }

then { UE transmits MAC PDU containing RRCConnectionRequest-NB and including Data Volume and Power Headroom Report (DPR) MAC control element }

}

(8)

with { UE in E-UTRA RRC_IDLE state and has transmitted Msg3 }

ensure that {

when { SS does not respond before contention resolution timer expiry }

then { UE transmits a random access preamble using a preamble in the same group of random access preambles as used for the previous preamble transmission }

}

(9)

with { UE in E-UTRA RRC_IDLE state and after transmitting a RACH MSG3 containing RRCConnectionRequest-NB message }
ensure that {
when { SS transmits a valid MAC PDU including ‘UE Contention Resolution Identity’ MAC control element but with un-matched ‘Contention Resolution Identity’ }
then { UE reinitiates RACH procedure }
}

(10)

Void

(11)

with { UE in E-UTRA RRC_IDLE state and after transmitting a RACH MSG3 containing RRCConnectionRequest-NB message }
ensure that {
when { SS transmits a valid MAC PDU containing RRCConnectionSetup-NB, including ‘UE Contention Resolution Identity’ MAC control element with matched ‘Contention Resolution Identity’ }
then { UE completes RACH procedure }
}

(12)

with { UE in E-UTRA RRC_IDLE state and having initiated a random access procedure }

ensure that {

when { The SS transmits a Timing Advance Command in a Random Access Response message }

then { the UE applies the received Timing Advance value in the next transmitted MAC PDU}

}

22.3.1.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clauses 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.4.5a, 6.1.3.10.

[TS 36.321, clause 5.1.1]

The Random Access procedure described in this subclause is initiated by a PDCCH order, by the MAC sublayer itself or by the RRC sublayer. Random Access procedure on an SCell shall only be initiated by a PDCCH order. If a MAC entity receives a PDCCH transmission consistent with a PDCCH order [5] masked with its C-RNTI, and for a specific Serving Cell, the MAC entity shall initiate a Random Access procedure on this Serving Cell. For Random Access on the SpCell a PDCCH order or RRC optionally indicate the ra-PreambleIndex and the ra-PRACH-MaskIndex, except for NB-IoT where the subcarrier index is indicated; and for Random Access on an SCell, the PDCCH order indicates the ra-PreambleIndex with a value different from 000000 and the ra-PRACH-MaskIndex. For the pTAG preamble transmission on PRACH and reception of a PDCCH order are only supported for SpCell. If the UE is an NB-IoT UE and is configured with a non-anchor carrier, perform the Random Access procedure on the anchor carrier.

Before the procedure can be initiated, the following information for related Serving Cell is assumed to be available for UEs other than NB-IoT UEs, BL UEs or UEs in enhanced coverage [8], unless explicitly stated otherwise:

– the available set of PRACH resources for the transmission of the Random Access Preamble, prach-ConfigIndex.

– the groups of Random Access Preambles and the set of available Random Access Preambles in each group (SpCell only):

The preambles that are contained in Random Access Preambles group A and Random Access Preambles group B are calculated from the parameters numberOfRA-Preambles and sizeOfRA-PreamblesGroupA:

If sizeOfRA-PreamblesGroupA is equal to numberOfRA-Preambles then there is no Random Access Preambles group B. The preambles in Random Access Preamble group A are the preambles 0 to sizeOfRA-PreamblesGroupA – 1 and, if it exists, the preambles in Random Access Preamble group B are the preambles sizeOfRA-PreamblesGroupA to numberOfRA-Preambles – 1 from the set of 64 preambles as defined in [7].

– if Random Access Preambles group B exists, the thresholds, messagePowerOffsetGroupB and messageSizeGroupA, the configured UE transmitted power of the Serving Cell performing the Random Access Procedure, P_{CMAX, c} [10], and the offset between the preamble and Msg3, deltaPreambleMsg3, that are required for selecting one of the two groups of Random Access Preambles (SpCell only).

– the RA response window size ra-ResponseWindowSize.

– the power-ramping factor powerRampingStep.

– the maximum number of preamble transmission preambleTransMax.

– the initial preamble power preambleInitialReceivedTargetPower.

– the preamble format based offset DELTA_PREAMBLE (see subclause 7.6).

– the maximum number of Msg3 HARQ transmissions maxHARQ-Msg3Tx (SpCell only).

– the Contention Resolution Timer mac-ContentionResolutionTimer (SpCell only).

NOTE: The above parameters may be updated from upper layers before each Random Access procedure is initiated.

The following information for related Serving Cell is assumed to be available before the procedure can be initiated for NB-IoT UEs, BL UEs or UEs in enhanced coverage [8]:

– …

– if the UE is a NB-IoT UE:

– the available set of PRACH resources supported in the Serving Cell, nprach-ParametersList.

– for random access resource selection and preamble transmission:

– a PRACH resource is mapped into an enhanced coverage level.

– each PRACH resource contains a set of nprach-NumSubcarriers subcarriers which can be partitioned into one or two groups for single/multi-tone Msg3 transmission by nprach-SubcarrierMSG3-RangeStart. Each group is referred to as a Random Access Preamble group below in the procedure text.

– a subcarrier is identified by the subcarrier index in the range:
[nprach-SubcarrierOffset, nprach-SubcarrierOffset + nprach-NumSubcarriers -1]

– each subcarrier of a Random Access Preamble group corresponds to a Random Access Preamble.

– when the subcarrier index is explicitly sent from the eNB as part of a PDCCH order ra-PreambleIndex shall be set to the signalled subcarrier index.

– the mapping of the PRACH resources into enhanced coverage levels is determined according to the following:

– the number of enhanced coverage levels is equal to one plus the number of RSRP thresholds present in RSRP-ThresholdsPrachInfoList.

– each enhanced coverage level has one PRACH resource present in nprach-ParametersList.

– enhanced coverage levels are numbered from 0 and the mapping of PRACH resources to enhanced coverage levels are done in increasing numRepetitionsPerPreambleAttempt order.

– the criteria to select PRACH resources based on RSRP measurement per enhanced coverage level supported in the Serving Cell rsrp-ThresholdsPrachInfoList.

– the maximum number of preamble transmission attempts per enhanced coverage level supported in the Serving Cell maxNumPreambleAttemptCE.

– the number of repetitions required for preamble transmission per attempt for each enhanced coverage level supported in the Serving Cell numRepetitionPerPreambleAttempt.

– the configured UE transmitted power of the Serving Cell performing the Random Access Procedure, P_{CMAX, c} [10].

– the RA response window size ra-ResponseWindowSize and the Contention Resolution Timer mac-ContentionResolutionTimer (SpCell only) per enhanced coverage level supported in the Serving Cell.

– the power-ramping factor powerRampingStep.

– the maximum number of preamble transmission preambleTransMax-CE.

– the initial preamble power preambleInitialReceivedTargetPower.

– the preamble format based offset DELTA_PREAMBLE (see subclause 7.6). For NB-IoT the DELTA_PREAMBLE is set to 0.

The Random Access procedure shall be performed as follows:

– Flush the Msg3 buffer;

– set the PREAMBLE_TRANSMISSION_COUNTER to 1;

– if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:

– set the PREAMBLE_TRANSMISSION_COUNTER_CE to 1;

– if the starting enhanced coverage level, or for NB-IoT the initial number of PRACH repetitions, has been indicated in the PDCCH order which initiated the Random Access procedure, or if the starting enhanced coverage level has been provided by upper layers:

– the MAC entity considers itself to be in that enhanced coverage level regardless of the measured RSRP;

– else:

– if the RSRP threshold of enhanced coverage level 3 is configured by upper layers in rsrp-ThresholdsPrachInfoList and the measured RSRP is less than the RSRP threshold of enhanced coverage level 3 and the UE is capable of enhanced coverage level 3 then:

– the MAC entity considers to be in enhanced coverage level 3;

– else if the RSRP threshold of enhanced coverage level 2 configured by upper layers in rsrp-ThresholdsPrachInfoList and the measured RSRP is less than the RSRP threshold of enhanced coverage level 2 and the UE is capable of enhanced coverage level 2 then:

– the MAC entity considers to be in enhanced coverage level 2;

– else if the measured RSRP is less than the RSRP threshold of enhanced coverage level 1 as configured by upper layers in rsrp-ThresholdsPrachInfoList then:

– the MAC entity considers to be in enhanced coverage level 1;

– else:

– the MAC entity considers to be in enhanced coverage level 0;

– set the backoff parameter value to 0 ms;

– for the RN, suspend any RN subframe configuration;

– proceed to the selection of the Random Access Resource (see subclause 5.1.2).

NOTE: There is only one Random Access procedure ongoing at any point in time in a MAC entity. If the MAC entity receives a request for a new Random Access procedure while another is already ongoing in the MAC entity, it is up to UE implementation whether to continue with the ongoing procedure or start with the new procedure.

[TS 36.321, clause 5.1.2]

The Random Access Resource selection procedure shall be performed as follows:

– …

– else, for NB-IoT, if ra-PreambleIndex (Random Access Preamble) and PRACH resource have been explicitly signalled:

– the PRACH resource is that explicitly signalled;

– if the ra-PreambleIndex signalled is not 000000:

– the Random Access Preamble is set to nprach-SubcarrierOffset + (ra-PreambleIndex modulo nprach-NumSubcarriers), where nprach-SubcarrierOffset and nprach-NumSubcarriers are parameters in the currently used PRACH resource.

– else:

– select the Random Access Preamble group according to the PRACH resource and the support for multi-tone Msg3 transmission.

– randomly select a Random Access Preamble within the selected group.

– else the Random Access Preamble shall be selected by the MAC entity as follows:

– If Msg3 has not yet been transmitted, the MAC entity shall, for NB-IoT UEs, BL UEs or UEs in enhanced coverage:

– expect for NB-IoT, select the Random Access Preambles group and the PRACH resource corresponding to the selected enhanced coverage level;

– for NB-IoT, select the PRACH resource corresponding to the selected enhanced coverage level, and select the Random Access Preambles group corresponding to the PRACH resource and the support for multi-tone Msg3 transmission;

– …

– except for NB-IoT, set PRACH Mask Index to 0.

– determine the next available subframe containing PRACH permitted by the restrictions given by the prach-ConfigIndex (except for NB-IoT), the PRACH Mask Index (except for NB-IoT, see subclause 7.3), physical layer timing requirements [2] and in case of NB-IoT, the subframes occupied by PRACH resources related to a higher enhanced coverage level (a MAC entity may take into account the possible occurrence of measurement gaps when determining the next available PRACH subframe);

– if the transmission mode is TDD and the PRACH Mask Index is equal to zero:

– …

– else:

– determine a PRACH within the determined subframe in accordance with the requirements of the PRACH Mask Index, if any.

– for NB-IoT UEs, BL UEs or UEs in enhanced coverage, select the ra-ResponseWindowSize and mac-ContentionResolutionTimer corresponding to the selected enhanced coverage level and PRACH.

– proceed to the transmission of the Random Access Preamble (see subclause 5.1.3).

[TS 36.321, clause 5.1.3]

The random-access procedure shall be performed as follows:

– set PREAMBLE_RECEIVED_TARGET_POWER to preambleInitialReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER – 1) * powerRampingStep;

– if the UE is a BL UE or a UE in enhanced coverage:

– the PREAMBLE_RECEIVED_TARGET_POWER is set to:
PREAMBLE_RECEIVED_TARGET_POWER – 10 * log10(numRepetitionPerPreambleAttempt);

– if NB-IoT:

– for enhanced coverage level 0, the PREAMBLE_RECEIVED_TARGET_POWER is set to:
PREAMBLE_RECEIVED_TARGET_POWER – 10 * log10(numRepetitionPerPreambleAttempt)

– for other enhanced coverage levels, the PREAMBLE_RECEIVED_TARGET_POWER is set corresponding to the max UE output power;

– if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:

– instruct the physical layer to transmit a preamble with the number of repetitions required for preamble transmission corresponding to the selected preamble group (i.e., numRepetitionPerPreambleAttempt) using the selected PRACH corresponding to the selected enhanced coverage level, corresponding RA-RNTI, preamble index or for NB-IoT subcarrier index, and PREAMBLE_RECEIVED_TARGET_POWER.

– else:

– instruct the physical layer to transmit a preamble using the selected PRACH, corresponding RA-RNTI, preamble index and PREAMBLE_RECEIVED_TARGET_POWER.

[TS 36.321, clause 5.1.4]

Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap or a Sidelink Discovery Gap for Transmission or a Sidelink Discovery Gap for Reception, the MAC entity shall monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize. If the UE is a BL UE or a UE in enhanced coverage, RA Response window starts at the subframe that contains the end of the last preamble repetition plus three subframes and has length ra-ResponseWindowSize for the corresponding coverage level. If the UE is an NB-IoT UE, in case the number of NPRACH repetitions is greater than or equal to 64, RA Response window starts at the subframe that contains the end of the last preamble repetition plus 41 subframes and has length ra-ResponseWindowSize for the corresponding coverage level, and in case the number of NPRACH repetitions is less than 64, RA Response window starts at the subframe that contains the end of the last preamble repetition plus 4 subframes and has length ra-ResponseWindowSize for the corresponding coverage level.

…

For NB-IoT UEs, the RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI=1+ floor(SFN_id/4)

where SFN_id is the index of the first radio frame of the specified PRACH.

The MAC entity may stop monitoring for Random Access Response(s) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted Random Access Preamble.

– If a downlink assignment for this TTI has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded, the MAC entity shall regardless of the possible occurrence of a measurement gap or a Sidelink Discovery Gap for Transmission or a Sidelink Discovery Gap for Reception:

– if the Random Access Response contains a Backoff Indicator subheader:

– set the backoff parameter value as indicated by the BI field of the Backoff Indicator subheader and Table 7.2-1, except for NB-IoT where the value from Table 7.2-2 is used.

– else, set the backoff parameter value to 0 ms.

– if the Random Access Response contains a Random Access Preamble identifier corresponding to the transmitted Random Access Preamble (see subclause 5.1.3), the MAC entity shall:

– consider this Random Access Response reception successful and apply the following actions for the serving cell where the Random Access Preamble was transmitted:

– process the received Timing Advance Command (see subclause 5.2);

– indicate the preambleInitialReceivedTargetPower and the amount of power ramping applied to the latest preamble transmission to lower layers (i.e., (PREAMBLE_TRANSMISSION_COUNTER – 1) * powerRampingStep);

– process the received UL grant value and indicate it to the lower layers;

– if ra-PreambleIndex was explicitly signalled and it was not 000000 (i.e., not selected by MAC):

– consider the Random Access procedure successfully completed.

– else, if the Random Access Preamble was selected by the MAC entity:

– set the Temporary C-RNTI to the value received in the Random Access Response message no later than at the time of the first transmission corresponding to the UL grant provided in the Random Access Response message;

– if this is the first successfully received Random Access Response within this Random Access procedure:

– if the transmission is not being made for the CCCH logical channel, indicate to the Multiplexing and assembly entity to include a C-RNTI MAC control element in the subsequent uplink transmission;

– obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity and store it in the Msg3 buffer.

NOTE: When an uplink transmission is required, e.g., for contention resolution, the eNB should not provide a grant smaller than 56 bits (or 88 bits for NB-IoT) in the Random Access Response.

NOTE: If within a Random Access procedure, an uplink grant provided in the Random Access Response for the same group of Random Access Preambles has a different size than the first uplink grant allocated during that Random Access procedure, the UE behaviour is not defined.

If no Random Access Response is received within the RA Response window, or if none of all received Random Access Responses contains a Random Access Preamble identifier corresponding to the transmitted Random Access Preamble, the Random Access Response reception is considered not successful and the MAC entity shall:

– if the notification of power ramping suspension has not been received from lower layers:

– increment PREAMBLE_TRANSMISSION_COUNTER by 1;

– if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:

– if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax-CE + 1:

– if the Random Access Preamble is transmitted on the SpCell:

– indicate a Random Access problem to upper layers;

– if NB-IoT:

– consider the Random Access procedure unsuccessfully completed;

– else:

– if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:

– if the Random Access Preamble is transmitted on the SpCell:

– indicate a Random Access problem to upper layers;

– if the Random Access Preamble is transmitted on an SCell:

– consider the Random Access procedure unsuccessfully completed.

– if in this Random Access procedure, the Random Access Preamble was selected by MAC:

– based on the backoff parameter, select a random backoff time according to a uniform distribution between 0 and the Backoff Parameter Value;

– delay the subsequent Random Access transmission by the backoff time;

– if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:

– increment PREAMBLE_TRANSMISSION_COUNTER_CE by 1;

– if PREAMBLE_TRANSMISSION_COUNTER_CE = maxNumPreambleAttemptCE for the corresponding enhanced coverage level + 1:

– reset PREAMBLE_TRANSMISSION_COUNTER_CE;

– consider to be in the next enhanced coverage level, if it is supported by the Serving Cell and the UE, otherwise stay in the current enhanced coverage level;

– select the Random Access Preambles group, ra-ResponseWindowSize, mac-ContentionResolutionTimer, and PRACH resource corresponding to the selected enhanced coverage level;

– if the UE is an NB-IoT UE:

– if the Random Access Procedure was initiated by a PDCCH order:

– consider the PRACH resource corresponding to the selected enhanced coverage level as explicitly signalled;

– proceed to the selection of a Random Access Resource (see subclause 5.1.2).

[TS 36.321, clause 5.1.5]

Contention Resolution is based on either C-RNTI on PDCCH of the SpCell or UE Contention Resolution Identity on DL-SCH. If the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage, the MAC entity shall use the mac-ContentionResolutionTimer for the corresponding enhanced coverage level if it exists.

Once Msg3 is transmitted, the MAC entity shall:

– start mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission;

– regardless of the possible occurrence of a measurement gap or Sidelink Discovery Gap for Reception, monitor the PDCCH until mac-ContentionResolutionTimer expires or is stopped;

– if notification of a reception of a PDCCH transmission is received from lower layers, the MAC entity shall:

– if the C-RNTI MAC control element was included in Msg3:

– if the Random Access procedure was initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains an UL grant for a new transmission; or

– if the Random Access procedure was initiated by a PDCCH order and the PDCCH transmission is addressed to the C-RNTI:

– consider this Contention Resolution successful;

– stop mac-ContentionResolutionTimer;

– discard the Temporary C-RNTI;

– if the UE is an NB-IoT UE and is configured with a non-anchor carrier:

– the UL grant or DL assignment contained in the PDCCH transmission on the anchor carrier is valid only for the non-anchor carrier.

– consider this Random Access procedure successfully completed.

– else if the CCCH SDU was included in Msg3 and the PDCCH transmission is addressed to its Temporary C-RNTI:

– if the MAC PDU is successfully decoded:

– stop mac-ContentionResolutionTimer;

– if the MAC PDU contains a UE Contention Resolution Identity MAC control element; and

– if the UE Contention Resolution Identity included in the MAC control element matches the 48 first bits of the CCCH SDU transmitted in Msg3:

– consider this Contention Resolution successful and finish the disassembly and demultiplexing of the MAC PDU;

– set the C-RNTI to the value of the Temporary C-RNTI;

– discard the Temporary C-RNTI;

– consider this Random Access procedure successfully completed.

– else

– discard the Temporary C-RNTI;

– consider this Contention Resolution not successful and discard the successfully decoded MAC PDU.

– if mac-ContentionResolutionTimer expires:

– discard the Temporary C-RNTI;

– consider the Contention Resolution not successful.

– if the Contention Resolution is considered not successful the MAC entity shall:

– flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer;

– if the notification of power ramping suspension has not been received from lower layers:

– increment PREAMBLE_TRANSMISSION_COUNTER by 1;

– if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:

– if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax-CE + 1:

– indicate a Random Access problem to upper layers.

– if NB-IoT:

– consider the Random Access procedure unsuccessfully completed;

– else:

– if PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:

– indicate a Random Access problem to upper layers.

– based on the backoff parameter, select a random backoff time according to a uniform distribution between 0 and the Backoff Parameter Value;

– delay the subsequent Random Access transmission by the backoff time;

– proceed to the selection of a Random Access Resource (see subclause 5.1.2).

[TS 36.321, clause 5.4.5a]

The Data Volume and Power Headroom reporting procedure is only applicable for NB-IoT UEs and is used to provide the serving eNB with information about the amount of data available for transmission in the UL buffers associated with the MAC entity, and to provide the serving eNB with information about the difference between the nominal UE maximum transmission power and the estimated transmission power for UL-SCH transmission for the Serving Cell. The reporting is done using the DPR MAC control element, which is sent in Msg3 together with a CCCH SDU.

[TS 36.321, clause 6.1.3.10]

The Data Volume and Power Headroom Report (DPR) MAC control element is identified by the MAC PDU subheader used for the CCCH MAC SDU, as specified in table 6.2.1-2. It does not add any additional subheader and is always placed before the CCCH MAC SDU.

It has a fixed size and consists of a single octet defined as follows (figure 6.1.3.10-1):

– Data Volume (DV): The Data Volume field identifies the total amount of data available across all logical channels and of data not yet associated with a logical channel after all MAC PDUs for the TTI have been built. The amount of data is indicated in number of bytes. It shall include all data that is available for transmission in the RLC layer, in the PDCP layer, and in the RRC layer; the definition of what data shall be considered as available for transmission is specified in [3], [4] and [8] respectively. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 4 bits. The values taken by the Data Volume field are shown in Table 6.1.3.10-1;

– Power Headroom (PH): This field indicates the power headroom level. The length of the field is 2 bits. The reported PH and the corresponding power headroom levels are shown in Table 6.1.3.10-2 below (the corresponding measured values in dB can be found in [9]);

– R: reserved bit, set to "0".

22.3.1.1.3 Test description

22.3.1.1.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

UE:

None.

Preamble:

– UE is in state Registered, Idle Mode (state 3-NB) according to [18] in Ncell 1.

22.3.1.1.3.2 Test procedure sequence

Table 22.3.1.1.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the Ncells at various time instants of the test execution. Row marked "T0" denotes the initial conditions after preamble, while columns marked "T1, T2 and T3" are to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 22.3.1.1.3.2-1: Time instances of cell power level and parameter changes

	Parameter	Unit	Ncell 1	Remark
T0	NRS-EPRE	dBm/15kHz	-70	The power level values are such that enhanced coverage level 0
T1	NRS-EPRE	dBm/15kHz	-90	The power level values are such that UE is in enhanced coverage level 1
T2	NRS-EPRE	dBm/15kHz	-110	The power level values are such that enhanced coverage level 2

Table 22.3.1.1.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
–	Exception: Steps 0-17E are repeated once for each time instant specified in table 22.3.1.1.3.2-1 by applying the Ncell 1 power level as per time instance.	–	–	–	–
0	The SS waits 15s to allow time to the UE to measure Ncell power level.
1	The SS transmits a Paging message including a matched identity.	<–	MAC PDU (Paging)	–	–
–	Exception: Steps 2, 4, 6, 9 & 13 is repeated for numRepetitionsPerPreambleAttempt-r13 times configured for corresponding CE level	–	–	–	–
2	Check: Does the UE transmit a preamble on NPRACH? NOTE: The RACH preamble is calculated based on same nprach-ParametersList-r13 parameters for corresponding CE level defined in SystemInformationBlockType2-NB	–>	NPRACH Preamble	1,2,3	P
3	The SS transmits Random Access Response with RAPID different to the transmitted Preamble in step 2, including T-CRNTI and not including Back off Indicator sub header.	<–	Random Access Response	–	–
4	Check: Does the UE transmit same preamble group as step 2 on NPRACH?	–>	NPRACH Preamble	1,2,3,5	P
5	The SS transmits a MAC PDU addressed to UE RA-RNTI, containing multiple RAR’s but none of the MAC sub headers contains a matching RAPID	<–	Random Access Response	–	–
6	Check: Does the UE transmit same preamble group as step 2 on NPRACH?	–>	NPRACH Preamble	1,2,3,6	P
7	The SS transmits a MAC PDU addressed to UE RA-RNTI, containing multiple RAR’s one of the MAC sub headers contains a matching RAPID	<–	Random Access Response	–	–
8	The UE transmits an RRCConnectionRequest-NB message including Data Volume and Power Headroom Report (DPR) MAC control element.	–>	MAC PDU (RRCConnectionRequest-NB)	7	P
9	Check: Does the UE transmit same preamble group as step 2 on NPRACH?	–>	NPRACH Preamble	1,2,3,8	P
10	The SS transmits a MAC PDU addressed to UE RA-RNTI, containing multiple RAR’s one of the MAC sub headers contains a matching RAPID	<–	Random Access Response	–	–
11	Check: Does the UE transmits an RRCConnectionRequest-NB message including Data Volume and Power Headroom Report (DPR) MAC control element.	–>	MAC PDU (RRCConnectionRequest-NB)	7	P
12	The SS transmits a valid MAC PDU including a ‘UE Contention Resolution Identity’ MAC control element with unmatched ‘Contention Resolution Identity’ and a CCCH message (RRCConnectionSetup-NB).	<–	MAC PDU (RRCConnectionSetup-NB)	–	–
13	Check: Does the UE transmit same preamble group as step 2 on NPRACH?	–>	NPRACH Preamble	9	P
14	Void	–	–	–	–
–	Exception: Steps 15 & 16 are repeated for numRepetitionsPerPreambleAttempt-r13 times configured for corresponding CE level	–	–	–	–
15	Check: Does the UE transmit a preamble on NPRACH? NOTE: The RACH preamble is calculated based on same nprach-ParametersList-r13 parameters for corresponding CE level +1 (if CE level is 0,1) or CE level 2 defined in SystemInformationBlockType2-NB	–>	NPRACH Preamble	4	P
16	Check: Does the UE transmit same preamble group as step 15 on NPRACH(PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax-CE (=7)+ 1)?	–>	NPRACH Preamble	4	P
17	The SS transmits a MAC PDU addressed to UE RA-RNTI, containing a matching RAPID.	<–	Random Access Response
17A – 17D	Steps 2 to 5 of the ‘Generic Test Procedure NB-IoT Control Plane CIoT MT user data transfer non-SMS transport’ as described in TS 36.508 [18] clause 8.1.5A.2.3 are performed.	–	–	–	–
17E	SS transmits an RRCConnectionRelease-NB message.	<–	MAC PDU (RRCConnectionRelease-NB)	–	–
18	SS sets Ncell 1 power level as per T0	–	–	–	–
18A	The SS waits 15s to allow time to the UE to measure Ncell power level.	–	–	–	–
19	The SS transmits a Paging message including a matched identity.	<–	MAC PDU (Paging)	–	–
20	Check: Does the UE transmit a preamble on NPRACH? NOTE: The RACH preamble is calculated based on same nprach-ParametersList-r13 parameters for corresponding CE level defined in SystemInformationBlockType2-NB	–>	NPRACH Preamble	1	P
21	SS respond to UE Random Access request by a Random Access Response with TA field within message set to 600 (NOTE 1)	<–	MAC PDU (Random Access Response (TA=600))	–	–
22	Check: Does UE send an RRCConnectionRequest-NB message? NOTE: The UL transmission is using the Timing Advance value sent by the SS in step 21	–>	MAC PDU (RRCConnectionRequest-NB)	12	P
23	The SS transmits a valid MAC PDU containing a “UE Contention Resolution Identity” MAC control element with matching “Contention Resolution Identity” and a CCCH message (RRCConnectionSetup-NB containing configuration of UE-specific search space).	<–	MAC PDU (RRCConnectionSetup-NB)	–	–
24	Void	–	–	–	–
25	Check: Does UE send an RRCConnectionSetupComplete-NB message? NOTE: The UL transmission is using the Timing Advance value sent by the SS in step 21	–>	MAC PDU (RRCConnectionSetupComplete-NB)	11	P
NOTE 1: T_A value of 600 has been chosen arbitrarily in the middle of the range 0 to 1282 and corresponds to 0.3125 ms (timing advance in ms = 1000 x N_TA x where N_TA = T_A ×16 and seconds according to TS 36.213 and TS 36.211).

22.3.1.1.3.3 Specific message contents

Table 22.3.1.1.3.3-1: NPRACH-ConfigSIB-NB-DEFAULT in SystemInformationBlockType2-NB in preamble

Derivation Path: 36.331 clause 6.7.3
Information Element	Value/remark	Comment	Condition
NPRACH-ConfigSIB-NB-DEFAULT ::= SEQUENCE {
rsrp-ThresholdsPrachInfoList-r13::= SEQUENCE {	2 entries
RSRP-Range[1]	61	-79 dBm
RSRP-Range[2]	41	-99 dBm
}
nprach-ParametersList-r13 ::= SEQUENCE {	3 entries	1: CE level 0 2: CE level 1 3: CE level 2
{
nprach-Periodicity-r13	ms640
nprach-StartTime-r13	ms8
nprach-SubcarrierOffset-r13	n12
nprach-NumSubcarriers-r13	n12
nprach-SubcarrierMSG3-RangeStart-r13	oneThird
maxNumPreambleAttemptCE-r13	n3
numRepetitionsPerPreambleAttempt-r13	n1
npdcch-NumRepetitions-RA-r13	r16
npdcch-StartSF-CSS-RA-r13	v4
npdcch-Offset-RA-r13	zero
}
{
nprach-Periodicity-r13	ms640
nprach-StartTime-r13	ms32
nprach-SubcarrierOffset-r13	n12
nprach-NumSubcarriers-r13	n12
nprach-SubcarrierMSG3-RangeStart-r13	oneThird
maxNumPreambleAttemptCE-r13	n3
numRepetitionsPerPreambleAttempt-r13	n2
npdcch-NumRepetitions-RA-r13	r16
npdcch-StartSF-CSS-RA-r13	v4
npdcch-Offset-RA-r13	zero
}
{
nprach-Periodicity-r13	ms640
nprach-StartTime-r13	ms128
nprach-SubcarrierOffset-r13	n12
nprach-NumSubcarriers-r13	n12
nprach-SubcarrierMSG3-RangeStart-r13	oneThird
maxNumPreambleAttemptCE-r13	n3
numRepetitionsPerPreambleAttempt-r13	n4
npdcch-NumRepetitions-RA-r13	r16
npdcch-StartSF-CSS-RA-r13	v4
npdcch-Offset-RA-r13	zero
}
}

Table 22.3.1.1.3.3-1A: NPRACH-ConfigSIB-NB-v1530-DEFAULT in SystemInformationBlockType2-NB in preamble

Derivation Path: 36.508 Table 8.1.6.3-17
Information Element	Value/remark	Comment	Condition
NPRACH-ConfigSIB-NB-v1530-DEFAULT ::= SEQUENCE {			TDD
tdd-Parameters-r15 SEQUENCE {
nprach-ParametersListTDD-r15 SEQUENCE (SIZE (1..maxNPRACH-Resources-NB-r13)) OF SEQUENCE {	3 entries	1: CE level 0 2: CE level 1 3: CE level 2
{
nprach-Parameters-r15 SEQUENCE {
nprach-Periodicity-r15	ms640
nprach-StartTime-r15	ms10
nprach-SubcarrierOffset-r15	n12
nprach-NumSubcarriers-r15	n12
nprach-SubcarrierMSG3-RangeStart-r15	oneThird
npdcch-NumRepetitions-RA-r15	r16
npdcch-StartSF-CSS-RA-r15	v4
npdcch-Offset-RA-r15	zero
nprach-NumCBRA-StartSubcarriers-r15	n8
}
}
{
nprach-Parameters-r15 SEQUENCE {
nprach-Periodicity-r15	ms640
nprach-StartTime-r15	ms40
nprach-SubcarrierOffset-r15	n12
nprach-NumSubcarriers-r15	n12
nprach-SubcarrierMSG3-RangeStart-r15	oneThird
npdcch-NumRepetitions-RA-r15	r16
npdcch-StartSF-CSS-RA-r15	v4
npdcch-Offset-RA-r15	zero
nprach-NumCBRA-StartSubcarriers-r15	n8
}
}
{
nprach-Parameters-r15 SEQUENCE {
nprach-Periodicity-r15	ms640
nprach-StartTime-r15	ms160
nprach-SubcarrierOffset-r15	n12
nprach-NumSubcarriers-r15	n12
nprach-SubcarrierMSG3-RangeStart-r15	oneThird
npdcch-NumRepetitions-RA-r15	r16
npdcch-StartSF-CSS-RA-r15	v4
npdcch-Offset-RA-r15	zero
nprach-NumCBRA-StartSubcarriers-r15	n8
}
}
}
}
}

Table 22.3.1.1.3.3-1B: NPRACH-ConfigSIB-NB-v1550-DEFAULT in SystemInformationBlockType2-NB in preamble

Derivation Path: 36.508 Table 8.1.6.3-18
Information Element	Value/remark	Comment	Condition
NPRACH-ConfigSIB-NB-v1550-DEFAULT ::= SEQUENCE {			TDD
tdd-Parameters-v1550 SEQUENCE {
nprach-ParametersListTDD-v1550 SEQUENCE (SIZE (1..maxNPRACH-Resources-NB-r13)) OF SEQUENCE {	3 entries	1: CE level 0 2: CE level 1 3: CE level 2
{
maxNumPreambleAttemptCE-v1550	n3
numRepetitionsPerPreambleAttempt-v1550	n1
}
{
maxNumPreambleAttemptCE-v1550	n3
numRepetitionsPerPreambleAttempt-v1550	n2
}
{
maxNumPreambleAttemptCE-v1550	n3
numRepetitionsPerPreambleAttempt-v1550	n4
}
}
}
}

Table 22.3.1.1.3.3-2: RACH-ConfigCommon-NB-DEFAULT in SystemInformationBlockType2-NB in preamble

Derivation Path: 36.508 Table 8.1.6.3-8
Information Element	Value/remark	Comment	Condition
RACH-ConfigCommon-NB-DEFAULT ::= SEQUENCE {
preambleTransMax-CE-r13	n7
rach-InfoList-r13 (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF SEQUENCE {	3 entries	1: CE level 0 2: CE level 1 3: CE level 2
{
ra-ResponseWindowSize-r13	pp10
mac-ContentionResolutionTimer-r13	pp8
}
{
ra-ResponseWindowSize-r13	pp10
mac-ContentionResolutionTimer-r13	pp8
}
{
ra-ResponseWindowSize-r13	pp10
mac-ContentionResolutionTimer-r13	pp8
}
}
}

Table 22.3.1.1.3.3-3: NPUSCH-ConfigCommon-NB-DEFAULT in SystemInformationBlockType2-NB in preamble

Derivation Path: 36.508 Table 8.1.6.3-6
Information Element	Value/remark	Comment	Condition
NPUSCH-ConfigCommon-NB-DEFAULT ::= SEQUENCE {
ack-NACK-NumRepetitions-Msg4-r13 (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF SEQUENCE {	3 entries	1: CE level 0 2: CE level 1 3: CE level 2
ACK-NACK-NumRepetitions-NB-r13	r8
ACK-NACK-NumRepetitions-NB-r13	r8
ACK-NACK-NumRepetitions-NB-r13	r8
}

Table 22.3.1.1.3.3-4: q-RxLevMin in SystemInformationBlockType1-NB in preamble

Derivation Path: 36.508 Table 8.1.4.3.2-3
Information Element	Value/remark	Comment	Condition
SystemInformationBlockType1-NB ::= SEQUENCE {
cellSelectionInfo-r13 SEQUENCE {
q-RxLevMin-r13	-70 (-140 dBm)
}
}

22.3.1.2 NB-IoT / Correct Handling of DL MAC PDU / Assignment / HARQ process / TimeAlignmentTimer expiry

22.3.1.2.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UE receives downlink assignment on the NPDCCH with a C-RNTI unknown by the UE and data is available in the associated subframe }

then { UE does not send any HARQ feedback on the HARQ process }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UE receives downlink assignment on the NPDCCH for the UE’s C-RNTI and receives a MAC PDU containing an single AMD PDU with no padding in the associated TTI in repetitions as per DL_REPETITION_NUMBER }

then { UE sends a HARQ feedback }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UE receives a MAC PDU containing multiple MAC SDUs each containing an AMD PDU and no padding }

then { UE successfully decodes the MAC PDU and forwards the AMD PDUs to higher layer }

}

(4)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when{ UE is receiving RLC PDUs in MAC PDUs with padding greater than 2 bytes }

then { UE acknowledges reception of the RLC PDUs }

}

(5)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UE is receiving RLC PDUs in MAC PDUs with padding equal to or less than 2 bytes }

then { UE acknowledges reception of the RLC PDUs }

}

(6)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { SS is transmitting a MAC control Timing Advance PDU with padding equal to or less than 2 bytes and no Data MAC PDU sub-headers followed by transmitting a RLC PDU }

then { UE acknowledges reception of the RLC PDU using the new Timing Advance }

}

(7)

with { UE in E-UTRA RRC_CONNECTED state and timeAlignmentTimer has expired }

ensure that {

when { SS sends downlink assignment on the NPDCCH with a C-RNTI assigned to UE and data is available in the associated subframe }

then { UE does not send any HARQ feedback on the HARQ process }

}

(8)

with { UE in E-UTRA RRC_CONNECTED state and timeAlignmentTimer has expired }

ensure that {

when { SS sends uplink grant on the NPDCCH with a C-RNTI assigned to UE }

then { UE does not send any MAC PDU }

}

(9)

with { UE in E-UTRA RRC_CONNECTED state and timeAlignmentTimer has expired }

ensure that {

when { SS sends NPDCCH order to the C-RNTI assigned to UE }

then { UE sends a prach preamble given in the NPDCCH Order }

}

22.3.1.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.321 clauses: 5.3.1, 5.3.2.1, 5.3.2.2., 6.1.2 & 6.2.1

[TS 36.321, clause 5.1.2]

– else, for NB-IoT, if ra-PreambleIndex (Random Access Preamble) and PRACH resource have been explicitly signalled:

– the PRACH resource is that explicitly signalled;

– if the ra-PreambleIndex signalled is not 000000:

[TS 36.321, clause 5.1.4]

For NB-IoT UEs, the RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI=1+ floor(SFN_id/4)

where SFN_id is the index of the first radio frame of the specified PRACH.

– if the Random Access Response contains a Backoff Indicator subheader:

– set the backoff parameter value as indicated by the BI field of the Backoff Indicator subheader and Table 7.2-1, except for NB-IoT where the value from Table 7.2-2 is used.

– else, set the backoff parameter value to 0 ms.

– if the Random Access Response contains a Random Access Preamble identifier corresponding to the transmitted Random Access Preamble (see subclause 5.1.3), the MAC entity shall:

– consider this Random Access Response reception successful and apply the following actions for the serving cell where the Random Access Preamble was transmitted:

– process the received Timing Advance Command (see subclause 5.2);

– process the received UL grant value and indicate it to the lower layers;

– if ra-PreambleIndex was explicitly signalled and it was not 000000 (i.e., not selected by MAC):

– consider the Random Access procedure successfully completed.

[TS 36.321, clause 5.3.1]

Downlink assignments transmitted on the PDCCH indicate if there is a transmission on a DL-SCH for a particular MAC entity and provide the relevant HARQ information.

When the MAC entity has a C-RNTI, Semi-Persistent Scheduling C-RNTI, or Temporary C-RNTI, the MAC entity shall for each TTI during which it monitors PDCCH and for each Serving Cell:

– if a downlink assignment for this TTI and this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI, or Temporary C‑RNTI:

– if this is the first downlink assignment for this Temporary C-RNTI:

– consider the NDI to have been toggled.

– if the downlink assignment is for the MAC entity’s C-RNTI and if the previous downlink assignment indicated to the HARQ entity of the same HARQ process was either a downlink assignment received for the MAC entity’s Semi-Persistent Scheduling C-RNTI or a configured downlink assignment:

– consider the NDI to have been toggled regardless of the value of the NDI.

– indicate the presence of a downlink assignment and deliver the associated HARQ information to the HARQ entity for this TTI.

[TS 36.321, clause 5.3.2.1]

There is one HARQ entity at the MAC entity for each Serving Cell which maintains a number of parallel HARQ processes. Each HARQ process is associated with a HARQ process identifier. The HARQ entity directs HARQ information and associated TBs received on the DL-SCH to the corresponding HARQ processes (see subclause 5.3.2.2).

The number of DL HARQ processes per HARQ entity is specified in [2], clause 7.

When the physical layer is configured for downlink spatial multiplexing [2], one or two TBs are expected per TTI and they are associated with the same HARQ process. Otherwise, one TB is expected per TTI.

For NB-IoT UEs or BL UEs or UEs in enhanced coverage, the parameter DL_REPETITION_NUMBER provides the number of transmissions repeated in a bundle. For each bundle, DL_REPETITION_NUMBER is set to a value provided by lower layers. Within a bundle, after the initial (re)transmission, DL_REPETITION_NUMBER-1 HARQ retransmissions follow. The HARQ feedback is transmitted for the bundle and a downlink assignment corresponding to a new transmission or a retransmission of the bundle is received after the last repetition of the bundle. A retransmission of a bundle is also a bundle.

In addition to the broadcast HARQ process, NB-IoT has one DL HARQ process.

The MAC entity shall:

– If a downlink assignment has been indicated for this TTI:

– allocate the TB(s) received from the physical layer and the associated HARQ information to the HARQ process indicated by the associated HARQ information.

– If a downlink assignment has been indicated for the broadcast HARQ process:

– allocate the received TB to the broadcast HARQ process.

NOTE: In case of BCCH and BR-BCCH a dedicated broadcast HARQ process is used.

[TS 36.321, clause 5.3.2.2]

For each TTI where a transmission takes place for the HARQ process, one or two (in case of downlink spatial multiplexing) TBs and the associated HARQ information are received from the HARQ entity.

For each received TB and associated HARQ information, the HARQ process shall:

– if the NDI, when provided, has been toggled compared to the value of the previous received transmission corresponding to this TB; or

– if the HARQ process is equal to the broadcast process and if this is the first received transmission for the TB according to the system information schedule indicated by RRC; or

– if this is the very first received transmission for this TB (i.e. there is no previous NDI for this TB):

– consider this transmission to be a new transmission.

– else:

– consider this transmission to be a retransmission.

The MAC entity then shall:

– if this is a new transmission:

– attempt to decode the received data.

– else if this is a retransmission:

– if the data for this TB has not yet been successfully decoded:

– combine the received data with the data currently in the soft buffer for this TB and attempt to decode the combined data.

– if the data which the MAC entity attempted to decode was successfully decoded for this TB; or

– if the data for this TB was successfully decoded before:

– if the HARQ process is equal to the broadcast process:

– deliver the decoded MAC PDU to upper layers.

– else if this is the first successful decoding of the data for this TB:

– deliver the decoded MAC PDU to the disassembly and demultiplexing entity.

– generate a positive acknowledgement (ACK) of the data in this TB.

– else:

– replace the data in the soft buffer for this TB with the data which the MAC entity attempted to decode.

– generate a negative acknowledgement (NACK) of the data in this TB.

– if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and the Contention Resolution is not yet successful (see subclause 5.1.5); or

– if the HARQ process is equal to the broadcast process; or

– if the timeAlignmentTimer, associated with the TAG containing the serving cell on which the HARQ feedback is to be transmitted, is stopped or expired:

– do not indicate the generated positive or negative acknowledgement to the physical layer.

– else:

– indicate the generated positive or negative acknowledgement for this TB to the physical layer.

The MAC entity shall ignore NDI received in all downlink assignments on PDCCH for its Temporary C-RNTI when determining if NDI on PDCCH for its C-RNTI has been toggled compared to the value in the previous transmission.

NOTE: When the MAC entity is configured with more than one serving cell, UE behaviours for storing data to the soft buffer is specified in [2].

NOTE: If the MAC entity receives a retransmission with a TB size different from the last valid TB size signalled for this TB, the UE behaviour is left up to UE implementation.

[TS 36.321, clause 6.1.2]

A MAC PDU consists of a MAC header, zero or more MAC Service Data Units (MAC SDU), zero, or more MAC control elements, and optionally padding; as described in Figure 6.1.2-3.

Both the MAC header and the MAC SDUs are of variable sizes.

A MAC PDU header consists of one or more MAC PDU subheaders; each subheader corresponds to either a MAC SDU, a MAC control element or padding.

A MAC PDU subheader consists of the five or six header fields R/F2/E/LCID/(F)/L but for the last subheader in the MAC PDU and for fixed sized MAC control elements. The last subheader in the MAC PDU and subheaders for fixed sized MAC control elements consist solely of the four header fields R/F2/E/LCID. A MAC PDU subheader corresponding to padding consists of the four header fields R/F2/E/LCID.

Figure 6.1.2-1: R/F2/E/LCID/F/L MAC subheader

Figure 6.1.2-1a: R/F2/E/LCID/L MAC subheader

Figure 6.1.2-2: R/F2/E/LCID MAC subheader

MAC PDU subheaders have the same order as the corresponding MAC SDUs, MAC control elements and padding.

MAC control elements are always placed before any MAC SDU.

Padding occurs at the end of the MAC PDU, except when single-byte or two-byte padding is required. Padding may have any value and the MAC entity shall ignore it. When padding is performed at the end of the MAC PDU, zero or more padding bytes are allowed.

When single-byte or two-byte padding is required, one or two MAC PDU subheaders corresponding to padding are placed at the beginning of the MAC PDU before any other MAC PDU subheader.

A maximum of one MAC PDU can be transmitted per TB per MAC entity. A maximum of one MCH MAC PDU can be transmitted per TTI.

Figure 6.1.2-3: Example of MAC PDU consisting of MAC header, MAC control elements, MAC SDUs and padding

[TS 36.321, clause 6.2.1]

The MAC header is of variable size and consists of the following fields:

– LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC control element or padding as described in tables 6.2.1-1, 6.2.1-2 and 6.2.1-4 for the DL-SCH, UL-SCH and MCH respectively. There is one LCID field for each MAC SDU, MAC control element or padding included in the MAC PDU. In addition to that, one or two additional LCID fields are included in the MAC PDU, when single-byte or two-byte padding is required but cannot be achieved by padding at the end of the MAC PDU. A UE of Category 0 [12] shall indicate CCCH using LCID "01011", otherwise the UE shall indicate CCCH using LCID "00000". The LCID field size is 5 bits;

– L: The Length field indicates the length of the corresponding MAC SDU or variable-sized MAC control element in bytes. There is one L field per MAC PDU subheader except for the last subheader and subheaders corresponding to fixed-sized MAC control elements. The size of the L field is indicated by the F field and F2 field;

– F: The Format field indicates the size of the Length field as indicated in table 6.2.1-3. There is one F field per MAC PDU subheader except for the last subheader and subheaders corresponding to fixed-sized MAC control elements and except for when F2 is set to 1. The size of the F field is 1 bit. If the F field is included; if the size of the MAC SDU or variable-sized MAC control element is less than 128 bytes, the value of the F field is set to 0, otherwise it is set to 1;

– F2: The Format2 field indicates the size of the Length field as indicated in table 6.2.1-3. There is one F2 field per MAC PDU subheader. The size of the F2 field is 1 bit. If the size of the MAC SDU or variable-sized MAC control element is larger than 32767 bytes, and if the corresponding subheader is not the last subheader, the value of the F2 field is set to 1, otherwise it is set to 0.

– E: The Extension field is a flag indicating if more fields are present in the MAC header or not. The E field is set to "1" to indicate another set of at least R/F2/E/LCID fields. The E field is set to "0" to indicate that either a MAC SDU, a MAC control element or padding starts at the next byte;

– R: Reserved bit, set to "0".

The MAC header and subheaders are octet aligned.

Table 6.2.1-1: Values of LCID for DL-SCH

Index	LCID values
00000	CCCH
00001-01010	Identity of the logical channel
01011-10111	Reserved
11000	Activation/Deactivation (4 octets)
11001	SC-MCCH, SC-MTCH (see note)
11010	Long DRX Command
11011	Activation/Deactivation (1 octet)
11100	UE Contention Resolution Identity
11101	Timing Advance Command
11110	DRX Command
11111	Padding
NOTE: Both SC-MCCH and SC-MTCH cannot be multiplexed with other logical channels in the same MAC PDU except for Padding.

For NB-IoT only the following LCID values for DL-SCH are applicable: CCCH, Identity of the logical channel, UE Contention Resolution Identity, Timing Advance Command, DRX Command and Padding.

Table 6.2.1-2: Values of LCID for UL-SCH

Index	LCID values
00000	CCCH
00001-01010	Identity of the logical channel
01011	CCCH
01100-10101	Reserved
10110	Truncated Sidelink BSR
10111	Sidelink BSR
11000	Dual Connectivity Power Headroom Report
11001	Extended Power Headroom Report
11010	Power Headroom Report
11011	C-RNTI
11100	Truncated BSR
11101	Short BSR
11110	Long BSR
11111	Padding

For NB-IoT only the following LCID values for UL-SCH are applicable: CCCH (LCID "00000"), Identity of the logical channel, C-RNTI, Short BSR and Padding.

Table 6.2.1-3: Values of F and F2 fields

Index of F2	Index of F	Size of Length field (in bits)
0	0	7
0	1	15
1	–	16

Table 6.2.1-4: Values of LCID for MCH

Index	LCID values
00000	MCCH (see note)
00001-11100	MTCH
11101	Reserved
11110	MCH Scheduling Information or Extended MCH Scheduling Information
11111	Padding
NOTE: If there is no MCCH on MCH, an MTCH could use this value.

22.3.1.2.3 Test description

22.3.1.2.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

– RRC-Connection-Setup-NB (preamble: Table 8.1.5.2.3-1, step 3 [18]) using parameters as specified in Table 22.3.1.2.3.3-1

UE:

None.

Preamble

– UE is in state NB-IoT UE Attach, Connected Mode, UE Test Loopback Activated (State 2B-NB) with test loop mode G and configured to return no data in UL according to [18] in Ncell 1.

22.3.1.2.3.2 Test procedure sequence

Table 22.3.1.2.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	SS transmits a downlink assignment to a C-RNTI different from the C-RNTI assigned to the UE on NPDCCH and transmits in the indicated downlink assignment a RLC PDU in a MAC PDU on NPDSCH.	<–	(NPDCCH (unknown C-RNTI)) MAC PDU	–	–
2	Check: Does the UE send any HARQ ACK on PUCCH?	–>	HARQ ACK/NACK	1	F
3	The SS transmits DCI N1 with Irep=2 resulting in 4 repetitions. The SS transmits a MAC PDU containing a MAC SDU with a RLC SDU of 38 bytes in an AMD PDU(SN=X+1) with polling field ‘P’ set to ‘1’ and repeats it in the next 3 consecutive TTIs; the SS shall generate a CRC error for each transmission causing the UE to send a NACK (NOTE 1, 2, 4)	<–	NPDCCH (DCI N1 )) MAC PDU (R/R/E/LCID MAC sub-header (E=’0’, LCID= ‘0011’), 40 bytes MAC SDU)	–	–
4	Check: Does the UE send HARQ NACK NPDSCH?	–>	HARQ NACK	2	P
–	EXCEPTION: Step 5 shall be repeated till HARQ ACK is received at step 6 (NOTE 11).	–	–	–	–
5	The SS indicates retransmissions on NPDCCH by transmitting DCI N1 with Irep=1 and NDI same as step 3 and transmits the same MAC PDU like step 3.		NPDCCH (DCI N1 )) MAC PDU (R/R/E/LCID MAC sub-header (E=’0’, LCID= ‘0011’), 40 bytes MAC SDU)
–	EXCEPTION: HARQ NACK from the UE should be allowed at step 6 (NOTE 11).	–	–	–	–
6	Check: Does the UE send HARQ ACK NPDSCH?	–>	HARQ ACK	2	P
7	The SS allocates an UL grant for UE to send the RLC status PDU (NOTE 3)	–	–	–	–
8	Check: Does the UE transmit a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDU in step 3?	–>	MAC PDU (RLC STATUS PDU (ACK_SN ‘X+2’))	2	P
9	The SS transmits DCI N1 with Irep=3 resulting in 8 repetitions. The SS transmits three MAC SDUs each containing a RLC SDU of 18, 19 or 21 bytes in an AMD PDU (SN=X+2 to X+4) with the polling field ‘P’ set to ‘1’ in the last AMD PDU and repeats it in the next 7 consecutive TTIs. (NOTE 1, 2, 5)	<–	NPDCCH (DCI N1 )) MAC PDU (2 x R/R/E/LCID/L MAC sub-header (E=’1’, LCID=‘0011’, F=’0’, L=’11’), R/R/E/LCID MAC sub-header (E=’0’, LCID=‘0011’), 19 bytes MAC SDU, 19 bytes MAC SDU, 21 bytes MAC SDU	–	–
10	Check: Does the UE send HARQ ACK NPDSCH?	–>	HARQ ACK	3	P
11	In the third NPDCCH period after the transmission at step 9 the SS allocates an UL grant for the UE to send the RLC status PDU (NOTE 3)	–	–	–	–
12	Check: Does the UE transmit a MAC PDU containing an RLC STATUS PDU acknowledging the reception of the AMD PDUs in step 5?	–>	MAC PDU (RLC STATUS PDU (ACK_SN ‘X+5’))	3	P
13	The SS transmits DCI N1 with Irep=4 resulting in 16 repetitions. The SS transmits a MAC PDU containing an RLC SDU in an AMD PDU with polling field ‘P’ set to ‘1’and repeats it in the next 15 consecutive TTIs. (NOTE 1, 2, 6)	<–	NPDCCH (DCI N1 )) MAC PDU(AMD PDU, 7-byte padding)	–	–
14	Check: Does the UE send HARQ ACK NPDSCH?	–>	HARQ ACK	4	P
15	In the third NPDCCH period after the transmission at step 13 the SS allocates an UL grant for the UE to send the RLC status PDU (NOTE 3)	–	–	–	–
16	Check: Does the UE transmit an RLC STATUS PDU with ACK_SN field equal to X+6?	–>	RLC STATUS PDU (ACK_SN ‘X+6’)	4	P
17	The SS transmits DCI N1 with Irep=5 resulting in 32 repetitions. The SS transmits a MAC PDU containing an RLC SDU in an AMD PDU with polling field ‘P’ set to ‘1’ and repeats it in the next 31 consecutive TTIs. (NOTE 1, 2, 7)	<–	NPDCCH (DCI N1 )) MACPDU(AMD PDU, one byte padding)	–	–
18	Check: Does the UE send HARQ ACK NPDSCH?	–>	HARQ ACK	5	P
19	In the third NPDCCH period after the transmission at step 17 the SS allocates an UL grant for the UE to send the RLC status PDU (NOTE 3)	–	–	–	–
20	Check: Does the UE transmit an RLC STATUS PDU with ACK_SN field equal to X+7?	–>	MAC PDU(RLC STATUS PDU (ACK_SN =X+7) )	5	P
21	The SS transmits a Timing Advance Command without any additional padding (i.e. TBS=16). Start Timer_1 = Time Alignment timer value. The Timing Advance Command indicates a T_A index of 31 resulting in no change of timing advance (see TS 36.213 clause 4.2.3)	<–	NPDCCH (DCI N1)) MAC Control PDU (Timing Advance)	–	–
22	Check: Does the UE send HARQ ACK NPDSCH?	–>	HARQ ACK	6	P
23	The SS waits for 39 NPDCCH periods. (NOTE 8)	–	–	–	–
24	In the 40^th NPDCCH period after the transmission at step 21 the SS transmit another Timing Advance MAC PDU (8 bits) with 1-byte padding (i.e. TBS=24). Restart Timer_1 = Time Alignment timer value The Timing Advance Command indicates a T_A index of 63 resulting in new timing advance to be applied at step 30. (NOTE 8)	<–	MAC Control Element (Timing Advance) + 1-byte padding	–	–
25	Check: Does the UE send HARQ ACK NPDSCH?	–>	HARQ ACK	6	P
26	The SS waits for 55 NPDCCH periods. (NOTE 9)	–	–	–	–
27	In the 56^th NPDCCH period after the transmission at step 24 the SS transmits MAC PDU containing one RLC SDU in an AMD PDU with polling field ‘P’ set to ‘1’. (NOTE 9)	<–	MAC PDU(AMD PDU (SN=X+7, P=1))	–	–
28	Check: Does the UE send HARQ ACK NPDSCH?	–>	HARQ ACK	6	P
29	In the 58^th NPDCCH period after the transmission at step 24 the SS allocates an UL grant for UE to send the RLC status PDU. (NOTE 3)	–	–	–	–
30	Check: Does the UE transmit an RLC STATUS PDU acknowledging the reception of the RLC PDU in step 27 with new Timing Advance?	–>	MAC PDU(RLC STATUS PDU (ACK_SN =X+8))	6	P
31	Wait for timeAlignmentTimer to expire in UE	–	–	–	–
32	In the 88^th NPDCCH period after the transmission at step 21 SS transmits a downlink assignment to C-RNTI assigned to the UE on NPDCCH and transmits in the indicated downlink assignment a RLC PDU with polling field ‘P’ set to ‘0’ in a MAC PDU on NPDSCH. (NOTE 10, NOTE 13)	<–	(NPDCCH (C-RNTI)) MAC PDU	–	–
33	Check: Does the UE send any HARQ ACK on PUCCH?	–>	HARQ ACK/NACK	7	F
34	In the 90^th NPDCCH period after the transmission at step 24 the SS allocates an UL grant for the UE. (NOTE 3)	–	–	–	–
35	Check: Does the UE transmit any UL MAC PDU?	–>	MAC PDU	8	F
36	The SS transmits a NPDCCH order to C-RNTI assigned to the UE on NPDCCH	<–	NPDCCH order (sub-carrier index := 13)	–	–
37	Check: Does the UE transmit a preamble on NPRACH with RAPID corresponding to subcarrier index provided in step 36?	–>	NPRACH Preamble	9	P
38	The SS transmits a MAC PDU addressed to UE RA-RNTI, containing a matching RAPID. (NOTE 12)	<–	Random Access Response	–	–
39	C-RNTI based contention resolution happens and causes the UE to be UL synchronised again. (NOTE 12)	–	–	–	–
NOTE 1: RLC SDU with size n contains a DLInformationTransfer-NB with ESM_DATA_TRANSPORT: 18 or 26 bits DLInformationTransfer-NB(PER encode: ‘0000000000’B + 8 bits ( length of DedicatedInfoNAS <= 127 bytes ) or 16 bits length ( 128 bytes <= length of DedicatedInfoNAS < 16383 bytes )) 1/2 byte Protocol discriminator ( SECURITY PROTECTED NAS MESSAGE ) 1/2 byte Security header type ( SECURITY PROTECTED NAS MESSAGE ) 4 bytes Message authentication code ( SECURITY PROTECTED NAS MESSAGE ) 1 byte Sequence number ( SECURITY PROTECTED NAS MESSAGE ) 1/2 byte Protocol discriminator ( ESM_DATA_TRANSPORT ) 1/2 byte EPS bearer identity ( ESM_DATA_TRANSPORT ) 1 byte Procedure transaction identity ( ESM_DATA_TRANSPORT ) 1 byte ESM data transport message identity ( ESM_DATA_TRANSPORT ) 2 bytes length indicator of the user data container ( ESM_DATA_TRANSPORT ) N bytes User data container contents ( UL RLC SDU ) 6 bits Aligned bits ( PER encode ) n = N+14 or N+15 bytes DL RLC SDU NOTE 2: The RLC SQN X is the last SQN used on SRB1bis before start of the test sequence. NOTE 3: NPDCCH period is 64ms according to TS 36.508 Table 8.1.6.3-3 [18]. NOTE 4: MAC PDU at step 3 and 5: 1 byte R/R/E/LCID MAC SDU sub-header 40 bytes MAC SDU containing RLC AMD PDU (2 bytes AMD header, 38 bytes RLC SDU) ⇒ TBS= 328 (I_SF=1, I_TBS=10) NOTE 5: MAC PDU at step 9: 4 bytes 2 x R/R/E/LCID/L MAC SDU sub-header 1 byte R/R/E/LCID MAC SDU sub-header 18 bytes MAC SDU containing RLC AMD PDU (2 bytes AMD header, 16 bytes RLC SDU) 19 bytes MAC SDU containing RLC AMD PDU (2 bytes AMD header, 17 bytes RLC SDU) 21 bytes MAC SDU containing RLC AMD PDU (2 bytes AMD header, 19 bytes RLC SDU) ⇒ TBS= 504 (I_SF=2, I_TBS=10) NOTE 6: MAC PDU at step 13: 2 bytes R/R/E/LCID/L MAC SDU sub-header 1 byte R/F2/E/LCID padding sub-header 18 bytes MAC SDU containing RLC AMD PDU (2 bytes AMD header, 16 bytes RLC SDU) 7 bytes padding ⇒ TBS= 224 (I_SF=1, I_TBS=7) NOTE 7: MAC PDU at step 17: 1 byte R/F2/E/LCID padding sub-header 1 byte R/R/E/LCID MAC SDU sub-header 16 bytes MAC SDU containing RLC AMD PDU (2 bytes AMD header, 14 bytes RLC SDU) ⇒ TBS= 144 (I_SF=0, I_TBS=10) NOTE 8: With an NPDCCH period of 64ms 40 NPDCCH periods are 2.56s i.e. the transmission at step 23 happens at about 50% of Timer_1 expiry (5.12s). NOTE 9: With an NPDCCH period of 64ms 56 NPDCCH periods are 3.584s i.e. the transmission at step 27 happens at about 70% of Timer_1 expiry (5.12s). NOTE 10: With an NPDCCH period of 64ms 88 NPDCCH periods are 5.632s corresponding to Timer_1 + 10%. NOTE 11: UE soft combiner implementation should have sufficient retransmissions to be able to successfully decode the data in its soft buffer. NOTE 12: The value of T-CRNTI and CRNTI are different at step 38/39. NOTE 13: The DL RLC Sequence number is incremented after step 32.

22.3.1.2.3.3 Specific message contents

Table 22.3.1.2.3.3-1: RRCConnectionSetup-NB

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 {
mac-MainConfig-r13 CHOICE {
explicitValue-r13 SEQUENCE {
timeAlignmentTimerDedicated-r13	sf5120	needs to be long enough to ensure time alignment timer not to time out before step 20
}
}
}
}
}
}

22.3.1.3 NB-IoT / Correct Handling of UL MAC PDU / Assignment / HARQ process / Padding

22.3.1.3.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives for a TTI an uplink grant with valid C-RNTI }

then { UE transmits UL MAC PDU repetitions as per UL_REPETITION_NUMBER }

}

(2)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives an UL Grant with toggled NDI, redundancy version = 0 in DCI format and has data available for transmission}

then { UE transmits a new MAC PDU in repetitions as per UL_REPETITION_NUMBER using redundancy versions alternating between 0,2 for each repetition}

}

(3)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE receives an UL Grant with un toggled NDI and redundancy version = 1 in DCI format }

then { UE retransmits the MAC PDU in repetitions as per UL_REPETITION_NUMBER using redundancy versions alternating between 2,0 for each repetition }

}

(4)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE inserts a R/R/E/LCID field in the MAC header and there is a subsequent R/R/E/LCID field to be inserted }

then { UE sets E field to 1 }

}

(5)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE inserts a R/R/E/LCID field in the MAC header and a MAC SDU or a MAC control element starts at the next byte }

then { UE sets E field to 0 }

}

(6)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE inserts the last MAC sub-header in the MAC PDU }

then { UE inserts a MAC sub-header consist solely of the four header fields R/R/E/LCID }

}

(7)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE is to transmit a MAC PDU with padding exceeding 2 bytes }

then { UE inserts the last MAC sub-header as a padding MAC subheader consisting solely of the four header fields R/R/E/LCID with LCID set to Padding and Padding goes to the end of the MAC PDU }

}

(8)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE is to transmit a MAC PDU with single-byte padding and there is a data MAC PDU sub-header present }

then { UE is inserting padding MAC PDU subheader before any other MAC PDU sub-header }

}

(9)

with { UE in RRC_CONNECTED state }

ensure that {

when { UE is to transmit a MAC PDU with two-byte padding and there is a data MAC PDU sub-header }

then { UE is inserting two padding MAC PDU subheaders before any other MAC PDU sub-header or one padding MAC PDU subheader as a last MAC PDU subheader }

}

22.3.1.3.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.321, clause 5.4.1, 5.4.2.1, 5.4.2.2, 6.1.2, 6.2.1. Unless otherwise stated these are Rel-13 requirements.

[TS 36.321, clause 5.4.1]

In order to transmit on the UL-SCH the MAC entity must have a valid uplink grant (except for non-adaptive HARQ retransmissions) which it may receive dynamically on the PDCCH or in a Random Access Response or which may be configured semi-persistently. To perform requested transmissions, the MAC layer receives HARQ information from lower layers. When the physical layer is configured for uplink spatial multiplexing, the MAC layer can receive up to two grants (one per HARQ process) for the same TTI from lower layers.

If the MAC entity has a C-RNTI, a Semi-Persistent Scheduling C-RNTI, or a Temporary C-RNTI, the MAC entity shall for each TTI and for each Serving Cell belonging to a TAG that has a running timeAlignmentTimer and for each grant received for this TTI:

– if an uplink grant for this TTI and this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI or Temporary C-RNTI; or

– if an uplink grant for this TTI has been received in a Random Access Response:

– if the uplink grant is for MAC entity’s C-RNTI and if the previous uplink grant delivered to the HARQ entity for the same HARQ process was either an uplink grant received for the MAC entity’s Semi-Persistent Scheduling C-RNTI or a configured uplink grant:

– consider the NDI to have been toggled for the corresponding HARQ process regardless of the value of the NDI.

– deliver the uplink grant and the associated HARQ information to the HARQ entity for this TTI.

– else, if this Serving Cell is the SpCell and if an uplink grant for this TTI has been received for the SpCell on the PDCCH of the SpCell for the MAC entity’s Semi-Persistent Scheduling C-RNTI:

– if the NDI in the received HARQ information is 1:

– consider the NDI for the corresponding HARQ process not to have been toggled;

– deliver the uplink grant and the associated HARQ information to the HARQ entity for this TTI.

– else if the NDI in the received HARQ information is 0:

– if PDCCH contents indicate SPS release:

– clear the configured uplink grant (if any).

– else:

– store the uplink grant and the associated HARQ information as configured uplink grant;

– initialise (if not active) or re-initialise (if already active) the configured uplink grant to start in this TTI and to recur according to rules in subclause 5.10.2;

– if UL HARQ operation is asynchronous, set the HARQ Process ID to the HARQ Process ID associated with this TTI;

– consider the NDI bit for the corresponding HARQ process to have been toggled;

– deliver the configured uplink grant and the associated HARQ information to the HARQ entity for this TTI.

– else, if this Serving Cell is the SpCell and an uplink grant for this TTI has been configured for the SpCell:

– if UL HARQ operation is asynchronous, set the HARQ Process ID to the HARQ Process ID associated with this TTI;

– consider the NDI bit for the corresponding HARQ process to have been toggled;

– deliver the configured uplink grant, and the associated HARQ information to the HARQ entity for this TTI.

NOTE: The period of configured uplink grants is expressed in TTIs.

NOTE: If the MAC entity receives both a grant in a Random Access Response and a grant for its C-RNTI or Semi persistent scheduling C-RNTI requiring transmissions on the SpCell in the same UL subframe, the MAC entity may choose to continue with either the grant for its RA-RNTI or the grant for its C-RNTI or Semi persistent scheduling C-RNTI.

NOTE: When a configured uplink grant is indicated during a measurement gap and indicates an UL-SCH transmission during a measurement gap, the MAC entity processes the grant but does not transmit on UL-SCH. When a configured uplink grant is indicated during a Sidelink Discovery gap for reception and indicates an UL-SCH transmission during a Sidelink Discovery gap for transmission with a SL-DCH transmission, the MAC entity processes the grant but does not transmit on UL-SCH.

For configured uplink grants, the HARQ Process ID associated with this TTI is derived from the following equation for asynchronous UL HARQ operation:

HARQ Process ID = [floor(CURRENT_TTI/semiPersistSchedIntervalUL)] modulo numberOfConfUlSPS-Processes,

where CURRENT_TTI=[(SFN * 10) + subframe number] and it refers to the subframe where the first transmission of a bundle takes place.

[TS 36.321, clause 5.4.2.1]

There is one HARQ entity at the MAC entity for each Serving Cell with configured uplink, which maintains a number of parallel HARQ processes allowing transmissions to take place continuously while waiting for the HARQ feedback on the successful or unsuccessful reception of previous transmissions.

The number of parallel HARQ processes per HARQ entity is specified in [2], clause 8. NB-IoT has one UL HARQ process.

When the physical layer is configured for uplink spatial multiplexing [2], there are two HARQ processes associated with a given TTI. Otherwise there is one HARQ process associated with a given TTI.

At a given TTI, if an uplink grant is indicated for the TTI, the HARQ entity identifies the HARQ process(es) for which a transmission should take place. It also routes the received HARQ feedback (ACK/NACK information), MCS and resource, relayed by the physical layer, to the appropriate HARQ process(es).

In asynchronous HARQ operation, a HARQ process is associated with a TTI based on the received UL grant except for UL grant in RAR. Except for NB-IoT, each asynchronous HARQ process is associated with a HARQ process identifier. For UL transmission with UL grant in RAR, HARQ process identifier 0 is used. HARQ feedback is not applicable for asynchronous UL HARQ.

When TTI bundling is configured, the parameter TTI_BUNDLE_SIZE provides the number of TTIs of a TTI bundle. TTI bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. Within a bundle HARQ retransmissions are non-adaptive and triggered without waiting for feedback from previous transmissions according to TTI_BUNDLE_SIZE. The HARQ feedback of a bundle is only received for the last TTI of the bundle (i.e. the TTI corresponding to TTI_BUNDLE_SIZE), regardless of whether a transmission in that TTI takes place or not (e.g. when a measurement gap occurs). A retransmission of a TTI bundle is also a TTI bundle. TTI bundling is not supported when the MAC entity is configured with one or more SCells with configured uplink.

Uplink HARQ operation is asynchronous for NB-IoT UEs, BL UEs or UEs in enhanced coverage except for the repetitions within a bundle.

For NB-IoT UEs, BL UEs or UEs in enhanced coverage, the parameter UL_REPETITION_NUMBER provides the number of transmission repetitions within a bundle. For each bundle, UL_REPETITION_NUMBER is set to a value provided by lower layers. Bundling operation relies on the HARQ entity for invoking the same HARQ process for each transmission that is part of the same bundle. Within a bundle HARQ retransmissions are non-adaptive and are triggered without waiting for feedback from previous transmissions according to UL_REPETITION_NUMBER. An uplink grant corresponding to a new transmission or a retransmission of the bundle is only received after the last repetition of the bundle. A retransmission of a bundle is also a bundle.

TTI bundling is not supported for RN communication with the E-UTRAN in combination with an RN subframe configuration.

For transmission of Msg3 during Random Access (see subclause 5.1.5) TTI bundling does not apply. For NB-IoT UEs, BL UEs or UEs in enhanced coverage, uplink repetition bundling is used for transmission of Msg3.

For each TTI, the HARQ entity shall:

– identify the HARQ process(es) associated with this TTI, and for each identified HARQ process:

– if an uplink grant has been indicated for this process and this TTI:

– if the received grant was not addressed to a Temporary C-RNTI on PDCCH and if the NDI provided in the associated HARQ information has been toggled compared to the value in the previous transmission of this HARQ process; or

– if the uplink grant was received on PDCCH for the C-RNTI and the HARQ buffer of the identified process is empty; or

– if the uplink grant was received in a Random Access Response:

– if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a Random Access Response:

– obtain the MAC PDU to transmit from the Msg3 buffer.

– else:

– obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity;

– deliver the MAC PDU and the uplink grant and the HARQ information to the identified HARQ process;

– instruct the identified HARQ process to trigger a new transmission.

– else:

– deliver the uplink grant and the HARQ information (redundancy version) to the identified HARQ process;

– instruct the identified HARQ process to generate an adaptive retransmission.

– else, if the HARQ buffer of this HARQ process is not empty:

– instruct the identified HARQ process to generate a non-adaptive retransmission.

When determining if NDI has been toggled compared to the value in the previous transmission the MAC entity shall ignore NDI received in all uplink grants on PDCCH for its Temporary C-RNTI.

[TS 36.321, clause 5.4.2.2]

Each HARQ process is associated with a HARQ buffer.

For synchronous HARQ, each HARQ process shall maintain a state variable CURRENT_TX_NB, which indicates the number of transmissions that have taken place for the MAC PDU currently in the buffer, and a state variable HARQ_FEEDBACK, which indicates the HARQ feedback for the MAC PDU currently in the buffer. When the HARQ process is established, CURRENT_TX_NB shall be initialized to 0.

The sequence of redundancy versions is 0, 2, 3, 1. The variable CURRENT_IRV is an index into the sequence of redundancy versions. This variable is up-dated modulo 4. For BL UEs or UEs in enhanced coverage see subclause 8.6.1 in [2] for the sequence of redundancy versions and redundancy version determination. For NB-IoT UEs see subclause 16.5.1.2 in [2] for the sequence of redundancy versions and redundancy version determination.

For NB-IoT UEs, BL UEs or UEs in enhanced coverage for UL_REPETITION_NUMBER for Mode B operation, the same redundancy version is used multiple times before cycling to the next redundancy version as specified in Subclause 16.5.1.2, 8.6.1 and 7.1.7.1 in [2].

New transmissions are performed on the resource and with the MCS indicated on PDCCH or Random Access Response. Adaptive retransmissions are performed on the resource and, if provided, with the MCS indicated on PDCCH. Non-adaptive retransmission is performed on the same resource and with the same MCS as was used for the last made transmission attempt.

For synchronous HARQ, the MAC entity is configured with a maximum number of HARQ transmissions and a maximum number of Msg3 HARQ transmissions by RRC: maxHARQ-Tx and maxHARQ-Msg3Tx respectively. For transmissions on all HARQ processes and all logical channels except for transmission of a MAC PDU stored in the Msg3 buffer, the maximum number of transmissions shall be set to maxHARQ-Tx. For transmission of a MAC PDU stored in the Msg3 buffer, the maximum number of transmissions shall be set to maxHARQ-Msg3Tx.

When the HARQ feedback is received for this TB, the HARQ process shall:

– set HARQ_FEEDBACK to the received value.

If the HARQ entity requests a new transmission, the HARQ process shall:

– if UL HARQ operation is synchronous:

– set CURRENT_TX_NB to 0;

– set HARQ_FEEDBACK to NACK;

– set CURRENT_IRV to 0;

– store the MAC PDU in the associated HARQ buffer;

– store the uplink grant received from the HARQ entity;

– generate a transmission as described below.

If the HARQ entity requests a retransmission, the HARQ process shall:

– if UL HARQ operation is synchronous:

– increment CURRENT_TX_NB by 1;

– if the HARQ entity requests an adaptive retransmission:

– store the uplink grant received from the HARQ entity;

– set CURRENT_IRV to the index corresponding to the redundancy version value provided in the HARQ information;

– if UL HARQ operation is synchronous:

– set HARQ_FEEDBACK to NACK;

– generate a transmission as described below.

– else if the HARQ entity requests a non-adaptive retransmission:

– if UL HARQ operation is asynchronous or HARQ_FEEDBACK = NACK:

– generate a transmission as described below.

NOTE: When receiving a HARQ ACK alone, the MAC entity keeps the data in the HARQ buffer.

NOTE: When no UL-SCH transmission can be made due to the occurrence of a measurement gap or a Sidelink Discovery Gap for Transmission, no HARQ feedback can be received and a non-adaptive retransmission follows.

NOTE: For asynchronous HARQ operation, UL retransmissions are triggered only by adaptive retransmission grants, except for retransmissions within a bundle.

To generate a transmission, the HARQ process shall:

– if the MAC PDU was obtained from the Msg3 buffer; or

– if Sidelink Discovery Gaps for Transmission are not configured by upper layers, and there is no measurement gap at the time of the transmission and, in case of retransmission, the retransmission does not collide with a transmission for a MAC PDU obtained from the Msg3 buffer in this TTI; or

– if Sidelink Discovery Gaps for Transmission are configured by upper layers, and there is no measurement gap at the time of the transmission and, in case of retransmission, the retransmission does not collide with a transmission for a MAC PDU obtained from the Msg3 buffer, and there is no Sidelink Discovery Gap for Transmission in this TTI; or

– if Sidelink Discovery Gaps for Transmission are configured by upper layers, and there is no measurement gap at the time of the transmission and, in case of retransmission, the retransmission does not collide with a transmission for a MAC PDU obtained from the Msg3 buffer, and there is a Sidelink Discovery Gap for Transmission, and there is no configured grant for transmission on SL-DCH in this TTI:

– instruct the physical layer to generate a transmission according to the stored uplink grant with the redundancy version corresponding to the CURRENT_IRV value;

– increment CURRENT_IRV by 1;

– if UL HARQ operation is synchronous and there is a measurement gap or Sidelink Discovery Gap for Reception at the time of the HARQ feedback reception for this transmission and if the MAC PDU was not obtained from the Msg3 buffer:

– set HARQ_FEEDBACK to ACK at the time of the HARQ feedback reception for this transmission.

After performing above actions, if UL HARQ operation is synchronous the HARQ process then shall:

– if CURRENT_TX_NB = maximum number of transmissions – 1:

– flush the HARQ buffer;

[TS 36.321, clause 6.1.2]

A MAC PDU consists of a MAC header, zero or more MAC Service Data Units (MAC SDU), zero, or more MAC control elements, and optionally padding; as described in Figure 6.1.2-3.

Both the MAC header and the MAC SDUs are of variable sizes.

A MAC PDU header consists of one or more MAC PDU subheaders; each subheader corresponds to either a MAC SDU, a MAC control element or padding.

Figure 6.1.2-1: R/F2/E/LCID/F/L MAC subheader

Figure 6.1.2-1a: R/F2/E/LCID/L MAC subheader

Figure 6.1.2-2: R/F2/E/LCID MAC subheader

MAC PDU subheaders have the same order as the corresponding MAC SDUs, MAC control elements and padding.

MAC control elements are always placed before any MAC SDU.

When single-byte or two-byte padding is required, one or two MAC PDU subheaders corresponding to padding are placed at the beginning of the MAC PDU before any other MAC PDU subheader.

A maximum of one MAC PDU can be transmitted per TB per MAC entity. A maximum of one MCH MAC PDU can be transmitted per TTI.

Figure 6.1.2-3: Example of MAC PDU consisting of MAC header, MAC control elements, MAC SDUs and padding

[TS 36.321, clause 6.2.1]

The MAC header is of variable size and consists of the following fields:

– R: Reserved bit, set to "0".

The MAC header and subheaders are octet aligned.

Table 6.2.1-1: Values of LCID for DL-SCH

Index	LCID values
00000	CCCH
00001-01010	Identity of the logical channel
01011-10111	Reserved
11000	Activation/Deactivation (4 octets)
11001	SC-MCCH, SC-MTCH (see note)
11010	Long DRX Command
11011	Activation/Deactivation (1 octet)
11100	UE Contention Resolution Identity
11101	Timing Advance Command
11110	DRX Command
11111	Padding
NOTE: Both SC-MCCH and SC-MTCH cannot be multiplexed with other logical channels in the same MAC PDU except for Padding

For NB-IoT only the following LCID values for DL-SCH are applicable: CCCH, Identity of the logical channel, UE Contention Resolution Identity, Timing Advance Command, DRX Command and Padding.

Table 6.2.1-2: Values of LCID for UL-SCH

Index	LCID values
00000	CCCH
00001-01010	Identity of the logical channel
01011	CCCH
01100-10101	Reserved
10110	Truncated Sidelink BSR
10111	Sidelink BSR
11000	Dual Connectivity Power Headroom Report
11001	Extended Power Headroom Report
11010	Power Headroom Report
11011	C-RNTI
11100	Truncated BSR
11101	Short BSR
11110	Long BSR
11111	Padding

For NB-IoT only the following LCID values for UL-SCH are applicable: CCCH (LCID "00000"), Identity of the logical channel, C-RNTI, Short BSR and Padding.

Table 6.2.1-3: Values of F and F2 fields:

Index of F2	Index of F	Size of Length field (in bits)
0	0	7
0	1	15
1	–	16

Table 6.2.1-4: Values of LCID for MCH

Index	LCID values
00000	MCCH (see note)
00001-11100	MTCH
11101	Reserved
11110	MCH Scheduling Information or Extended MCH Scheduling Information
11111	Padding
NOTE: If there is no MCCH on MCH, an MTCH could use this value.

22.3.1.3.3 Test description

22.3.1.3.3.1 Pre-test conditions

System Simulator:

– NCell 1.

UE:

– None.

Preamble:

– The UE shall be in State 2B-NB with test loop mode G (CP CIoT Optimisation) according to TS 36.508 [18].

22.3.1.3.3.2 Test procedure sequence

NOTE: In the Table 22.3.1.3.3.2-1 the LCID=’00011’ maps to SIB1bis in CP mode.

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.1.3.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The SS transmits a MAC PDU containing RLC PDU with polling field ‘P’ set to ‘0’ and an RLC SDU	<–	MAC PDU(RLC SN=0)	–	–
2	The SS shall schedule UL grants at the beginning of the next 10 UE specific search spaces, allowing the UE to return the RLC SDU as received in step 1, on NPDCCH, but with the C-RNTI different from the C-RNTI assigned to the UE.	<–	(UL Grant (unknown C-RNTI))	–	–
3	Check: Does the UE transmit a MAC PDU corresponding to grant in step 2?	–>	MAC PDU	1	F
4	SS transmits one UL Grant, allowing the UE to return the RLC SDU as received in step 1, on NPDCCH with the C-RNTI assigned to the UE.	<–	(UL Grant (C-RNTI))	–	–
5	Check: Does the UE transmit a MAC PDU corresponding to grant in step 4?	–>	MAC PDU(RLC SN=0)	1	P
6	SS transmits an RLC STATUS PDU to acknowledge correctly received data。	<–	RLC STATUS PDU(RLC SN=1)	–	–
7	The SS Transmits a MAC PDU containing RLC PDU with polling field ‘P’ set to ‘0’ and an RLC SDU of 16 bytes	<–	MAC PDU(RLC SN=1)	–	–
8	In the third NPDCCH period after DL transmission of step 7 the SS allocates one UL Grant of size 208 bits (Note 7), sufficient for one RLC SDU to be loop backed in slots within a repetition, and NDI indicates new transmission, and redundancy version = 0.	<–	Uplink Grant	–	–
9	Check: Does the UE transmit a MAC PDU including one RLC SDU, with redundancy version alternating between 0, 2 for each repetition? (Note 1)	–>	MAC PDU(RLC SN=1)	2	P
10	The SS allocates one UL Grant of size 208 bits (Note 7), sufficient for one RLC SDU to be loop backed in slots within a repetition, and NDI is the same with which in step 8, and redundancy version = 1.	<–	Uplink Grant
11	Check: Does the UE retransmit the MAC PDU in step 9, with redundancy version alternating between 2, 0 for each repetition? (Note 1)	–>	MAC PDU(RLC SN=1)	3	P
12	SS transmits an RLC STATUS PDU to acknowledge correctly received data.	<–	RLC STATUS PDU(RLC SN=2)	–	–
13	The SS Transmits a MAC PDU containing RLC PDU with polling field ‘P’ set to ‘1’ and an RLC SDU of 15 bytes	<–	MAC PDU(RLC SN=2)	–	–
14	In the third NPDCCH period after DL transmission of step 13 the SS allocates one UL Grant of size 176 bits. (Note 2)	<–	(UL grant)	–	–
15	Check: Does the UE return a MAC PDU of length 176 bits containing two MAC sub-headers where the first MAC sub-header have the Expansion bit ‘E’ set to ‘1’ and the second MAC sub-header has the Expansion bit ‘E’ set to ‘0’ and no length field? (Note 3)	–>	MAC PDU (MAC sub-header (E=’1’, LCID=’00011’, L=’ 17’), MAC sub-header (E=’0’, LCID=’00011’, no Length field present), AMD PDU(RLC SN=2), Status PDU) Or MAC PDU (MAC sub-header (E=’1’, LCID=’00011’, L=’ 2’), MAC sub-header (E=’0’, LCID=’00011’, no Length field present), Status PDU, AMD PDU(RLC SN=2))	4,5,6	P
16	SS transmits an RLC STATUS PDU to acknowledge correctly received data	<–	RLC STATUS PDU(RLC SN=3)	–	–
17	Void
18	The SS transmits a MAC PDU containing RLC PDU with polling field ‘P’ set to ‘0’ and an RLC SDU of 8 bytes	<–	MAC PDU(RLC SN=3)	–	–
19	In the third NPDCCH period after DL transmission of step 18 the SS transmits one uplink grant of size 176 bits. (Note 4)	<–	(UL grant)	–	–
20	Check: Does the UE transmit a MAC PDU with a MAC SDU of length 10 bytes and where the last MAC sub-header has the Extension field ‘E’ set to ‘0’ and the Logical Channel ID field ‘LCID’ set to ‘11111’?	–>	MAC PDU (BSR sub-header, MAC SDU sub-header, Padding MAC sub-header (E=’0’, LCID=’11111’),Short BSR, MAC SDU(RLC SN=3), padding)	7	P
20A	SS transmits an RLC STATUS PDU to acknowledge correctly received data.	<–	RLC STATUS PDU(RLC SN=4)
21	The SS transmits a MAC PDU containing RLC PDU with polling field ‘P’ set to ‘0’ and an RLC SDU of 11 bytes	<–	MAC PDU(RLC SN=4)	–	–
22	In the third NPDCCH period after DL transmission of step 21 the SS transmits one uplink grant of size 120 bits. (Note 5)	<–	(UL grant)	–	–
23	Check: Does the UE transmit a MAC PDU with a MAC SDU of length 13 bytes and with a padding MAC sub-header, with Extension field ‘E’ is set to ‘1’ and the Logical Channel ID field ‘LCID’ is set to ‘11111’, inserted before the MAC SDU sub-header?	–>	MAC PDU (Padding MAC-sub-header (E=’1’, LCID=’11111’), MAC SDU sub-header, MAC SDU)(RLC SN=4)	8	P
23A	SS transmits an RLC STATUS PDU to acknowledge correctly received data.	<–	RLC STATUS PDU(RLC SN=5)
24	The SS transmits a MAC PDU containing RLC PDU with polling field ‘P’ set to ‘0’ and an RLC SDU of 8 bytes	<–	MAC PDU(RLC SN=5)	–	–
25	In the third NPDCCH period after DL transmission of step 24 the SS transmits one uplink grant of size 120 bits. (Note 6)	<–	(UL grant)	–	–
26	Check: Does the UE transmit a MAC PDU with two padding MAC sub-headers, with Extension field ‘E’ is set to ‘1’ and the Logical Channel ID field ‘LCID’ is set to ‘11111’, inserted before the BSR sub-header and the MAC SDU sub-header. Or a MAC PDU with BSR sub-header with Extension field ‘E’ is set to ‘1’ and MAC SDU sub-header (R/R/E/LCID/F/L) inserted before the Padding MAC sub-header?	–>	MAC PDU (Padding MAC-sub-header#1 (E=’1’, LCID=’11111’), Padding MAC-sub-header#2 (E=’1’, LCID=’11111’), BSR sub-header, MAC SDU sub-header, Short BSR, MAC-SDU(RLC SN=5)) Or MAC PDU(BSR sub-header, MAC SDU sub-header, Padding MAC-sub-header(E=’0’, LCID=’11111’), Short BSR, MAC-SDU(RLC SN=5))	9	P
27	SS transmits an RLC STATUS PDU to acknowledge correctly received data	<–	RLC STATUS PDU(RLC SN=6)
NOTE 1: Transmission of a UL MAC PDU with a specific redundancy version by the UE is implicitly tested by receiving the UL MAC PDU correctly at SS. NOTE 2: UL grant of 176 bits (I_TBS=3, I_RU=2, see TS 36.213 Table 16.5.1.2-2) is chosen to enable UE to transmit two MAC SDUs, one of size 17 and one of size 2 bytes, in a MAC PDU (15 bytes RLC SDU + 2 bytes AMD PDU header + 2 bytes RLC Status PDU + 2 bytes MAC sub-header (7 bit LI) + one byte MAC sub-header (R/R/E/LCID) = 22 bytes = 176 bits). NOTE 3: MAC SDUs can come in any order NOTE 4: UL grant of 176 bits (I_TBS=3, I_RU=2, see TS 36.213 Table 16.5.1.2-2) is chosen such that the MAC PDU padding will be larger than 2 bytes. RLC SDU size is 8 bytes, size of AMD PDU header is 2 bytes, size of MAC header is 4 bytes (2 bytes for MAC SDU sub-header using 7-bit LI, 1 byte for BSR sub-header and 1 byte for padding MAC sub-header) and size of Short BSR is 1 byte, equals to 120 bits (15 bytes) and resulting into 56 bits padding. NOTE 5: UL grant of 120 bits (I_TBS=0, I_RU=4, see TS 36.213 Table 16.5.1.2-2) is chosen such that the MAC PDU padding will be a single byte. RLC SDU size is 11 bytes, size of AMD PDU header is 2 bytes and size of MAC header is 1 byte for MAC SDU sub-header, equals to 112 bits (14 bytes) and resulting into 1 single byte padding. NOTE 6: UL grant of 120 bits (I_TBS=0, I_RU=4, see TS 36.213 Table 16.5.1.2-2) is chosen such that the MAC PDU padding will be equal to 2 bytes. RLC SDU size is 8 bytes, size of AMD PDU header is 2 bytes, size of MAC header is 4 bytes (1 bytes for MAC SDU sub-header, 1 byte for Short BSR sub-header and 2 bytes for padding MAC sub-header) and size of Short BSR is 1 byte, equals to 120 bits (15 bytes) and resulting no padding at the end of the MAC PDU. NOTE 7: UL grant of 208 bits (I_TBS=4, I_RU=2, see TS 36.213 Table 16.5.1.2-2) is chosen. RLC SDU size is 16 bytes, size of AMD PDU header is 2 bytes and MAC header is 4 bytes (2 bytes MAC sub-header (7 bit LI), 1 byte for BSR sub-header and 1 byte for padding MAC sub-header) and size of Short BSR is 1 byte, equals to 23 bytes = 184 bits

22.3.1.3.3.3 Specific message contents

Table 22.3.1.3.3.3-1: Void

22.3.1.4 NB-IoT / Correct handling of MAC control information / Buffer status

22.3.1.4.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UL data arrives in the UE transmission buffer and no BSR has been triggered }

then { UE triggers a regular BSR and Reports a Short Buffer Status Reporting (BSR) }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when{RETX_BSR_TIMER expires and UE has pending data for transmission }

then { UE transmits a random access preamble }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { a Regular BSR has been triggered and UE has pending data for transmission and UE has only resources to send either BSR report or partial data }

then { UE transmits the BSR report }

}

(4)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { a Regular BSR has been triggered and UE has pending data for transmission and UE has only UL resources to send all pending data available for transmission, but UL grant is not sufficient to additionally accommodate the BSR MAC control element}

then { UE cancels the triggered BSR report and transmits the UL data}

}

(5)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { a Regular BSR has been triggered and UE has pending data for transmission and UE has UL resources to send all pending data including BSR }

then { UE transmits the UL data and reports buffer status reporting (BSR) that indicates there is no more data in the buffer}

}

(6)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UE transmits a MAC PDU and the number of padding bits is equal to or larger than the size of a Short BSR plus its subheader and the UE has available data for transmission form in the TTI where the BSR is transmitted }

then { UE triggers padding BSR and reports a Short BSR }

}

(7)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { periodicBSR-Timer expires and UE has buffered data in a TTI }

then { UE triggers a Periodic BSR and reports Short BSR and restarts the periodicBSR-Timer}

}

22.3.1.4.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.4.3.1, 5.4.5, 6.1.2, 6.1.3.1 and 6.2.1. Unless otherwise stated these are Rel-13 requirements.

[TS 36.321 clause 5.4.3.1]

For the Logical Channel Prioritization procedure, the MAC entity shall take into account the following relative priority in decreasing order:

– MAC control element for C-RNTI or data from UL-CCCH;

– MAC control element for BSR, with exception of BSR included for padding;

– MAC control element for PHR, Extended PHR, or Dual Connectivity PHR;

– MAC control element for Sidelink BSR, with exception of Sidelink BSR included for padding;

– data from any Logical Channel, except data from UL-CCCH;

– MAC control element for BSR included for padding;

– MAC control element for Sidelink BSR included for padding.

NOTE: When the MAC entity is requested to transmit multiple MAC PDUs in one TTI, steps 1 to 3 and the associated rules may be applied either to each grant independently or to the sum of the capacities of the grants. Also the order in which the grants are processed is left up to UE implementation. It is up to the UE implementation to decide in which MAC PDU a MAC control element is included when MAC entity is requested to transmit multiple MAC PDUs in one TTI. When the UE is requested to generate MAC PDU(s) in two MAC entities in one TTI, it is up to UE implementation in which order the grants are processed.

[TS 36.321 clause 5.4.5]

The Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data available for transmission in the UL buffers associated with the MAC entity. RRC controls BSR reporting by configuring the three timers periodicBSR-Timer, retxBSR-Timer and logicalChannelSR-ProhibitTimer and by, for each logical channel, optionally signalling logicalChannelGroup which allocates the logical channel to an LCG [8].

For the Buffer Status reporting procedure, the MAC entity shall consider all radio bearers which are not suspended and may consider radio bearers which are suspended.

For NB-IoT the Long BSR is not supported and all logical channels belong to one LCG.

A Buffer Status Report (BSR) shall be triggered if any of the following events occur:

– UL data, for a logical channel which belongs to a LCG, becomes available for transmission in the RLC entity or in the PDCP entity (the definition of what data shall be considered as available for transmission is specified in [3] and [4] respectively) and either the data belongs to a logical channel with higher priority than the priorities of the logical channels which belong to any LCG and for which data is already available for transmission, or there is no data available for transmission for any of the logical channels which belong to a LCG, in which case the BSR is referred below to as "Regular BSR";

– UL resources are allocated and number of padding bits is equal to or larger than the size of the Buffer Status Report MAC control element plus its subheader, in which case the BSR is referred below to as "Padding BSR";

– retxBSR-Timer expires and the MAC entity has data available for transmission for any of the logical channels which belong to a LCG, in which case the BSR is referred below to as "Regular BSR";

– periodicBSR-Timer expires, in which case the BSR is referred below to as "Periodic BSR".

For Regular BSR:

– if the BSR is triggered due to data becoming available for transmission for a logical channel for which logicalChannelSR-ProhibitTimer is configured by upper layers:

– start or restart the logicalChannelSR-ProhibitTimer;

– else:

– if running, stop the logicalChannelSR-ProhibitTimer.

For Regular and Periodic BSR:

– if more than one LCG has data available for transmission in the TTI where the BSR is transmitted: report Long BSR;

– else report Short BSR.

For Padding BSR:

– if the number of padding bits is equal to or larger than the size of the Short BSR plus its subheader but smaller than the size of the Long BSR plus its subheader:

– if more than one LCG has data available for transmission in the TTI where the BSR is transmitted: report Truncated BSR of the LCG with the highest priority logical channel with data available for transmission;

– else report Short BSR.

– else if the number of padding bits is equal to or larger than the size of the Long BSR plus its subheader, report Long BSR.

If the Buffer Status reporting procedure determines that at least one BSR has been triggered and not cancelled:

– if the MAC entity has UL resources allocated for new transmission for this TTI:

– instruct the Multiplexing and Assembly procedure to generate the BSR MAC control element(s);

– start or restart periodicBSR-Timer except when all the generated BSRs are Truncated BSRs;

– start or restart retxBSR-Timer.

– else if a Regular BSR has been triggered and logicalChannelSR-ProhibitTimer is not running:

– if an uplink grant is not configured or the Regular BSR was not triggered due to data becoming available for transmission for a logical channel for which logical channel SR masking (logicalChannelSR-Mask) is setup by upper layers:

– a Scheduling Request shall be triggered.

A MAC PDU shall contain at most one MAC BSR control element, even when multiple events trigger a BSR by the time a BSR can be transmitted in which case the Regular BSR and the Periodic BSR shall have precedence over the padding BSR.

The MAC entity shall restart retxBSR-Timer upon indication of a grant for transmission of new data on any UL-SCH.

All triggered BSRs shall be cancelled in case the UL grant(s) in this TTI can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the BSR MAC control element plus its subheader. All triggered BSRs shall be cancelled when a BSR is included in a MAC PDU for transmission.

The MAC entity shall transmit at most one Regular/Periodic BSR in a TTI. If the MAC entity is requested to transmit multiple MAC PDUs in a TTI, it may include a padding BSR in any of the MAC PDUs which do not contain a Regular/Periodic BSR.

All BSRs transmitted in a TTI always reflect the buffer status after all MAC PDUs have been built for this TTI. Each LCG shall report at the most one buffer status value per TTI and this value shall be reported in all BSRs reporting buffer status for this LCG.

NOTE: A Padding BSR is not allowed to cancel a triggered Regular/Periodic BSR, except for NB-IoT. A Padding BSR is triggered for a specific MAC PDU only and the trigger is cancelled when this MAC PDU has been built.

[TS 36.321 clause 6.1.2]

A MAC PDU consists of a MAC header, zero or more MAC Service Data Units (MAC SDU), zero, or more MAC control elements, and optionally padding; as described in Figure 6.1.2-3.

Both the MAC header and the MAC SDUs are of variable sizes.

A MAC PDU header consists of one or more MAC PDU subheaders; each subheader corresponds to either a MAC SDU, a MAC control element or padding.

Figure 6.1.2-1: R/F2/E/LCID/F/L MAC subheader

Figure 6.1.2-1a: R/F2/E/LCID/L MAC subheader

Figure 6.1.2-2: R/F2/E/LCID MAC subheader

MAC PDU subheaders have the same order as the corresponding MAC SDUs, MAC control elements and padding.

MAC control elements are always placed before any MAC SDU.

When single-byte or two-byte padding is required, one or two MAC PDU subheaders corresponding to padding are placed at the beginning of the MAC PDU before any other MAC PDU subheader.

A maximum of one MAC PDU can be transmitted per TB per MAC entity. A maximum of one MCH MAC PDU can be transmitted per TTI.

Figure 6.1.2-3: Example of MAC PDU consisting of MAC header, MAC control elements, MAC SDUs and padding

[TS 36.321 clause 6.1.3.1]

Buffer Status Report (BSR) MAC control elements consist of either:

– Short BSR and Truncated BSR format: one LCG ID field and one corresponding Buffer Size field (figure 6.1.3.1-1); or

– Long BSR format: four Buffer Size fields, corresponding to LCG IDs #0 through #3 (figure 6.1.3.1-2).

The BSR formats are identified by MAC PDU subheaders with LCIDs as specified in table 6.2.1-2.

The fields LCG ID and Buffer Size are defined as follow:

– LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is being reported. The length of the field is 2 bits;

– Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a logical channel group after all MAC PDUs for the TTI have been built. The amount of data is indicated in number of bytes. It shall include all data that is available for transmission in the RLC layer and in the PDCP layer; the definition of what data shall be considered as available for transmission is specified in [3] and [4] respectively. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits. If extendedBSR-Sizes is not configured, the values taken by the Buffer Size field are shown in Table 6.1.3.1-1. If extendedBSR-Sizes is configured, the values taken by the Buffer Size field are shown in Table 6.1.3.1-2.

Figure 6.1.3.1-1: Short BSR and Truncated BSR MAC control element

Figure 6.1.3.1-2: Long BSR MAC control element

Table 6.1.3.1-1: Buffer size levels for BSR

Index	Buffer Size (BS) value [bytes]	Index	Buffer Size (BS) value [bytes]
0	BS = 0	32	1132 < BS <= 1326
1	0 < BS <= 10	33	1326 < BS <= 1552
2	10 < BS <= 12	34	1552 < BS <= 1817
3	12 < BS <= 14	35	1817 < BS <= 2127
4	14 < BS <= 17	36	2127 < BS <= 2490
5	17 < BS <= 19	37	2490 < BS <= 2915
6	19 < BS <= 22	38	2915 < BS <= 3413
7	22 < BS <= 26	39	3413 < BS <= 3995
8	26 < BS <= 31	40	3995 < BS <= 4677
9	31 < BS <= 36	41	4677 < BS <= 5476
10	36 < BS <= 42	42	5476 < BS <= 6411
11	42 < BS <= 49	43	6411 < BS <= 7505
12	49 < BS <= 57	44	7505 < BS <= 8787
13	57 < BS <= 67	45	8787 < BS <= 10287
14	67 < BS <= 78	46	10287 < BS <= 12043
15	78 < BS <= 91	47	12043 < BS <= 14099
16	91 < BS <= 107	48	14099 < BS <= 16507
17	107 < BS <= 125	49	16507 < BS <= 19325
18	125 < BS <= 146	50	19325 < BS <= 22624
19	146 < BS <= 171	51	22624 < BS <= 26487
20	171 < BS <= 200	52	26487 < BS <= 31009
21	200 < BS <= 234	53	31009 < BS <= 36304
22	234 < BS <= 274	54	36304 < BS <= 42502
23	274 < BS <= 321	55	42502 < BS <= 49759
24	321 < BS <= 376	56	49759 < BS <= 58255
25	376 < BS <= 440	57	58255 < BS <= 68201
26	440 < BS <= 515	58	68201 < BS <= 79846
27	515 < BS <= 603	59	79846 < BS <= 93479
28	603 < BS <= 706	60	93479 < BS <= 109439
29	706 < BS <= 826	61	109439 < BS <= 128125
30	826 < BS <= 967	62	128125 < BS <= 150000
31	967 < BS <=1132	63	BS > 150000

Table 6.1.3.1-2: Extended Buffer size levels for BSR

Index	Buffer Size (BS) value [bytes]	Index	Buffer Size (BS) value [bytes]
0	BS = 0	32	4940 < BS <= 6074
1	0 < BS <= 10	33	6074 < BS <= 7469
2	10 < BS <= 13	34	7469 < BS <= 9185
3	13 < BS <= 16	35	9185 < BS <= 11294
4	16 < BS <= 19	36	11294 < BS <= 13888
5	19 < BS <= 23	37	13888 < BS <= 17077
6	23 < BS <= 29	38	17077 < BS <= 20999
7	29 < BS <= 35	39	20999 < BS <= 25822
8	35 < BS <= 43	40	25822 < BS <= 31752
9	43 < BS <= 53	41	31752 < BS <= 39045
10	53 < BS <= 65	42	39045 < BS <= 48012
11	65 < BS <= 80	43	48012 < BS <= 59039
12	80 < BS <= 98	44	59039 < BS <= 72598
13	98 < BS <= 120	45	72598 < BS <= 89272
14	120 < BS <= 147	46	89272 < BS <= 109774
15	147 < BS <= 181	47	109774 < BS <= 134986
16	181 < BS <= 223	48	134986 < BS <= 165989
17	223 < BS <= 274	49	165989 < BS <= 204111
18	274 < BS <= 337	50	204111 < BS <= 250990
19	337 < BS <= 414	51	250990 < BS <= 308634
20	414 < BS <= 509	52	308634 < BS <= 379519
21	509 < BS <= 625	53	379519 < BS <= 466683
22	625 < BS <= 769	54	466683 < BS <= 573866
23	769 < BS <= 945	55	573866 < BS <= 705666
24	945 < BS <= 1162	56	705666 < BS <= 867737
25	1162 < BS <= 1429	57	867737 < BS <= 1067031
26	1429 < BS <= 1757	58	1067031 < BS <= 1312097
27	1757 < BS <= 2161	59	1312097 < BS <= 1613447
28	2161 < BS <= 2657	60	1613447 < BS <= 1984009
29	2657 < BS <= 3267	61	1984009 < BS <= 2439678
30	3267 < BS <= 4017	62	2439678 < BS <= 3000000
31	4017 < BS <=4940	63	BS > 3000000

[TS 36.321 clause 6.2.1]

The MAC header and subheaders are octet aligned.

Table 6.2.1-1: Values of LCID for DL-SCH

Index	LCID values
00000	CCCH
00001-01010	Identity of the logical channel
01011-10111	Reserved
11000	Activation/Deactivation (4 octets)
11001	SC-MCCH, SC-MTCH (see note)
11010	Long DRX Command
11011	Activation/Deactivation (1 octet)
11100	UE Contention Resolution Identity
11101	Timing Advance Command
11110	DRX Command
11111	Padding
NOTE: Both SC-MCCH and SC-MTCH cannot be multiplexed with other logical channels in the same MAC PDU except for Padding

For NB-IoT only the following LCID values for DL-SCH are applicable: CCCH, Identity of the logical channel, UE Contention Resolution Identity, Timing Advance Command, DRX Command and Padding.

Table 6.2.1-2: Values of LCID for UL-SCH

Index	LCID values
00000	CCCH
00001-01010	Identity of the logical channel
01011	CCCH
01100-10101	Reserved
10110	Truncated Sidelink BSR
10111	Sidelink BSR
11000	Dual Connectivity Power Headroom Report
11001	Extended Power Headroom Report
11010	Power Headroom Report
11011	C-RNTI
11100	Truncated BSR
11101	Short BSR
11110	Long BSR
11111	Padding

For NB-IoT only the following LCID values for UL-SCH are applicable: CCCH (LCID "00000"), Identity of the logical channel, C-RNTI, Short BSR and Padding.

Table 6.2.1-3: Values of F and F2 fields:

Index of F2	Index of F	Size of Length field (in bits)
0	0	7
0	1	15
1	–	16

Table 6.2.1-4: Values of LCID for MCH

Index	LCID values
00000	MCCH (see note)
00001-11100	MTCH
11101	Reserved
11110	MCH Scheduling Information or Extended MCH Scheduling Information
11111	Padding
NOTE: If there is no MCCH on MCH, an MTCH could use this value.

22.3.1.4.3 Test description

22.3.1.4.3.1 Pre-test conditions

System Simulator:

– Ncell 1

– RRC Connection Setup (preamble: Table 8.1.5.2.3-1, step 3 [18]) using parameters as specified in Table 22.3.1.4.3.3-1

UE:

None.

Preamble:

– The UE is in Loopback Activated State 2B-NB with test loop mode G according to [18] on Ncell 1.

22.3.1.4.3.2 Test procedure sequence

Table 22.3.1.4.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Void	–	–	–	–
2	The SS transmits a MAC PDU containing two RLC SDUs of RLC UL SDU size 10 bytes. (Note 0)	<–	MAC PDU (2 RLC SDUs)	–	–
3	In the third NPDCCH period after DL transmission of step 2 the SS allocates an UL Grant of 32 bits. (Note 1)	<–	(UL Grant, 32 bits)	–	–
4	Check: Does the UE transmit a Short BSR with ‘Buffer size’ field set to value ‘6’ or bigger? (Note 2)	–>	MAC PDU (MAC Short BSR (Buffer Size=’6’ or bigger))	1,3	P
5	Wait for retxBSR-Timer expiry on UE side.	–	–	–	–
5A	Check: Does the UE transmit a preamble on NPRACH?	–>	NPRACH Preamble	2	P
5B	The SS transmits a Random Access Response containing a matching RAPID. (Note 7)	<–	Random Access Response	–	–
5C	The UE transmit a MAC PDU containing C-RNTI, BSR and a portion of loop backed first RLC SDU. (Note 2a)	–>	MAC PDU(C-RNTI, MAC Short BSR(Buffer Size=’4’ or bigger), portion of loop backed first RLC SDU)	–	–
6	The SS allocates an UL Grant of 176 bits before mac‑ContentionResolutionTimer expiry. (Notes 2b, 7)	<–	(UL Grant, 176 bits)	–	–
7	Check: Does the UE transmit a MAC PDU including a portion of loop backed first RLC SDU and second RLC SDUs? (Note 2b)	–>	MAC PDU (RLC AMD PDU with header, 2 RLC SDU)
7A	SS transmits an RLC STATUS PDU to acknowledge correctly received data.	<–	RLC STATUS PDU (ACK_SN=1)	–	–
8	The SS transmits a MAC PDU containing one RLC UL SDU of size 10 bytes. (Note 0)	<–	MAC PDU (1 RLC SDU)	–	–
9	In the third NPDCCH period after DL transmission of step 8 the SS allocates an UL Grant of 32 bits. (Note 1)	<–	(UL Grant, 32 bits)	–	–
10	Check: Does the UE transmit a Short BSR with Buffer size#1’ field set to value ‘1’ or bigger? (Note 2)	–>	MAC PDU (MAC Short BSR (Buffer Size=’1’ or bigger))	3	P
10A	In the third NPDCCH period after the transmission at step 9 the SS allocates an UL Grant of 104 bits. (Note 2c)	<–	(UL Grant, 104 bits)	–	–
10B	Check: Does the UE transmit a MAC PDU including the RLC SDU sent at step 8? (Note 2c)	–>	MAC PDU (SDU subheader, RLC AMD PDU with header, 1 RLC SDU)	–	–
10C	SS transmits an RLC STATUS PDU to acknowledge correctly received data	<–	RLC STATUS PDU (ACK_SN=2)	–	–
11	The SS transmits a MAC PDU containing three RLC UL SDUs of size 10 bytes. (Note 0)	<–	MAC PDU (3 RLC SDUs)	–	–
12	In the third NPDCCH period after the transmission at step 11 the SS allocates an UL Grant of 296 bits. (Note 3)	<–	(UL Grant, 296 bits)	–	–
13	Check: Does the UE transmit a MAC PDU including three RLC SDUs and not including any BSR? (Note 3)	–>	MAC PDU (padding, SDU subheader, RLC AMD PDU with header, 2 LIs, 3 RLC SDUs)	4	P
14	SS transmits an RLC STATUS PDU to acknowledge correctly received data	<–	RLC STATUS PDU (ACK_SN=3)	–	–
15	The SS transmits a MAC PDU containing two MAC SDUs, the first containing a 8 byte RLC UL SDU and the second containing a 7 byte RLC UL SDU. (Note 0)	<–	MAC PDU	–	–
16	In the third NPDCCH period after DL transmission of step 15 the SS allocates an uplink grant of size 256 bits. (Note 4)	<–	(UL grant, 256 bits)	–	–
17	Check: Does the UE return a MAC PDU of length 256 bits including 2 RLC SDUs, Padding and Short BSR with Buffer size(s) set to ‘0’? (Note 4)	–>	MAC PDU (Short BSR subheader, SDU subheader, padding subheader, short BSR, RLC AMD PDU with header, 1 LI, 2 RLC SDUs, padding)	5	P
18	SS transmits an RLC STATUS PDU to acknowledge correctly received data	<–	RLC STATUS PDU (ACK_SN=4)	–	–
19	The SS transmits a MAC PDU including an RLC SDU of RLC UL SDU size 12 bytes. (Note 0)	<–	MAC PDU	–	–
20	In the third NPDCCH period after DL transmission of step 19 the SS transmits an uplink grant of size 136 bits. (Note 4a)	<–	(UL grant, 136 bits)	–	–
21	Check: Does UE transmit a MAC PDU containing an RLC SDU and with a Short BSR indicating pending data (‘Buffer size’ field = ‘0’) for ‘LCG ID’ field set to ‘0’? (Note 4a)	–>	MAC PDU (Short BSR header, Short BSR(LCG ID=’00’, Buffer size=’0’), MAC SDU)	6	P
21A	SS transmits an RLC STATUS PDU to acknowledge correctly received data.	<–	RLC STATUS PDU (ACK_SN=3)
21B	The SS transmits an RRCConnectionRelease-NB message.	<–	RRC: RRCConnectionRelease-NB
21C	‘Generic Test Procedure NB-IoT Control Plane CIoT MT user data transfer non-SMS transport’ as described in TS 36.508 [18], clause 8.1.5A.2.3 are performed	–	–	–	–
22	The SS transmits a MAC PDU containing an RLC PDU, which contains 1 RLC UL SDU of size 14 bytes. (Note 0)	<–	MAC PDU (RLC PDU)	–	–
23	The SS sends an uplink grant of size 32 bits.	<–	(UL grant, 32 bits)	–	–
24	The UE transmits a short BSR report. (Note 6)	–>	MAC PDU (Short BSR header, Short BSR(LCG ID=’00’, Buffer size index > 0))	–	–
–	EXCEPTION: Steps 25 to 27 shall be repeated two times (Note 5).	–	–	–	–
25	Wait for periodicBSR-Timer expiry.	–	–	–	–
26	In the next NPDCCH period after periodicBSR -Timer expiry the SS sends an uplink grant of size 32 bits (Note 1)	–	(UL Grant, 32 bits)	–	–
27	Check: Does UE transmit a MAC PDU containing a Short BSR with ‘LCG ID’ field set to ‘00’ and Buffer Size Index > 0?	–>	MAC PDU (Short BSR header, Short BSR(LCG ID=’00’, Buffer Size index > 0))	7	P
Note 0: RLC SDU with size n contains a DLInformationTransfer-NB with ESM_DATA_TRANSPORT: 18 or 26 bits DLInformationTransfer-NB(PER encode: ‘0000000000’B + 8 bits ( length of DedicatedInfoNAS <= 127 bytes ) or 16 bits length ( 128 bytes <= length of DedicatedInfoNAS < 16383 bytes )) 1/2 byte Protocol discriminator ( SECURITY PROTECTED NAS MESSAGE ) 1/2 byte Security header type ( SECURITY PROTECTED NAS MESSAGE ) 4 bytes Message authentication code ( SECURITY PROTECTED NAS MESSAGE ) 1 byte Sequence number ( SECURITY PROTECTED NAS MESSAGE ) 1/2 byte Protocol discriminator ( ESM_DATA_TRANSPORT ) 1/2 byte EPS bearer identity ( ESM_DATA_TRANSPORT ) 1 byte Procedure transaction identity ( ESM_DATA_TRANSPORT ) 1 byte ESM data transport message identity ( ESM_DATA_TRANSPORT ) 2 bytes length indicator of the user data container ( ESM_DATA_TRANSPORT ) N bytes User data container contents ( UL RLC SDU ) 6 bits Aligned bits ( PER encode ) n = N+14 or N+15 bytes DL RLC SDU Note 1: 32 bits enables UE to transmit a MAC PDU with a MAC BSR header and a Short BSR (1 bytes). Note 2: UE triggers a Short BSR of type "Regular BSR" to report buffer status for one LCG for that TTI. The UE should not send any of the received RLC SDUs (segmented) due to Regular BSR has higher priority than U-plane logical channels. Note 2a: 88 bits for msg3 enable UE to transmit the CRNTI, BSR and user data (received in step 2), where 3 bytes belong first RLC SDU with FI=01 in its AMD PUD header, in a MAC PDU with 3 bytes MAC subheader: 1 byte CRNTI, 1 byte BSR, 1 byte SDU subheader 3 bytes MAC CE: 2 bytes CRNTI, 1 byte BSR 5 bytes MAC SDU: AMD PDU with 2 bytes header and a portion of 1 RLC SDU (3 bytes) ⇒ 11 bytes (TBS = 88) Note 2b: The UE has 17 bytes of user data (received in step 2) in the transmission buffer, where 17 bytes belong RLC SDU with FI=10 in its AMD PUD header. 176 bits enables UE to transmit the user data in a MAC PDU with 1 byte MAC subheader: 1 byte SDU subheader 21 bytes MAC SDU: AMD PDU with 4 bytes header and a portion of 1 RLC SDU (7 bytes) and 1 RLC SDUs (10 bytes) ⇒ 22 bytes (TBS = 176)Note 2c: The UE has 10 bytes of user data (received in step 8) in the transmission buffer. 104 bits enables UE to transmit the user data in a MAC PDU with 1 byte MAC subheader: 1 byte SDU subheader 12 bytes MAC SDU: AMD PDU with 2 bytes header and 1 RLC SDU (10 bytes) ⇒ 13 bytes (TBS =104) Note 3: The UE has 30 bytes of user data (received in steps 11) in the transmission buffer. 296 bits enables UE to transmit the user data in a MAC PDU with 2 bytes MAC subheader: 1 byte padding, 1 byte SDU subheader 35 bytes MAC SDU: AMD PDU with 5 bytes header (2 LIs) and 3 RLC SDUs (10 bytes each) ⇒ 37 bytes (TBS = 296) Note 4: The UE has 15 bytes of user data (received in steps 15) in the transmission buffer. 256 bits enables UE to transmit the user data in a MAC PDU with 4 bytes MAC subheader (1 byte BSR subheader, 2 bytes SDU subheader, 1 byte paddingr) 1 byte short BSR 19 bytes MAC SDU: AMD PDU with 4 bytes header (1 LI) and 2 RLC SDUs (7 and 8 bytes) 8 bytes padding ⇒ 32 bytes (TBS=256). Note 4a: The UE has 12 bytes of user data (received in steps 19) in the transmission buffer. 136 bits enables UE to transmit the user data in a MAC PDU with 2 bytes MAC subheader: 1 byte BSR subheader, 1 byte SDU subheader 1 byte short BSR 14 bytes MAC SDU: AMD PDU with 2 byte header and 12 bytes RLC SDU ⇒ 17 bytes (TBS=136). Note 5: One short BSR due to first expiry of periodicBSR-Timer and one short BSR due to second expire of periodicBSR-Timer. Note 6: The UE starts periodicBSR-Timer. Note 7: The value of T-CRNTI and CRNTI are different at step 5B/6.

22.3.1.4.3.3 Specific Message Contents

Table 22.3.1.4.3.3-1: RRCConnectionSetup-NB (Preamble)

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 {
mac-MainConfig-r13 CHOICE {
explicitValue-r13 SEQUENCE {
ul-SCH-Config-r13 SEQUENCE {
periodicBSR-Timer-r13	pp64
retxBSR-Timer-r13	pp16
}
}
}
}
}
}
}

Table 22.3.1.4.3.3-2: RRCConnectionSetup-NB (Step 21C, Table 22.3.1.4.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 {
mac-MainConfig-r13 CHOICE {
explicitValue-r13 SEQUENCE {
ul-SCH-Config-r13 SEQUENCE {
periodicBSR-Timer-r13	pp16
retxBSR-Timer-r13	pp64
}
}
}
}
}
}
}

22.3.1.5 NB-IoT / DRX operation / DRX cycle configured / Parameters configured by RRC / DRX command MAC control element reception

22.3.1.5.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { DRX cycle is configured and [(SFN * 10) + subframe number] modulo (DRX-Cycle) = drxStartOffset-r13 }

then { UE starts the OnDurationTimer-r13 and monitors the NPDCCH for OnDurationTimer-r13 NPDCCH subframes }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { DRX cycle is configured and a new DL transmission is indicated on the NPDCCH during Active Time }

then { After expiry of the HARQ RTT timer the UE starts or restarts the Drx-InactivityTimer-r13 and monitors the NPDCCH for Drx-InactivityTimer-r13 NPDCCH periods }

}

(3)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { DRX cycle is configured and when a HARQ RTT Timer expires and the data in the soft buffer of the corresponding HARQ process has not been successfully decoded }

then { UE starts the drx-RetransmissionTimer-r13 for the corresponding HARQ process and monitors the NPDCCH for drx-RetransmissionTimer-r13 consecutive NPDCCH periods }

}

(4)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { DRX cycle is configured and an uplink grant for a pending HARQ retransmission can occur in this NPDCCH period }

then { UE monitors the NPDCCH in this period }

(5)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { DRX cycle is configured and a DRX Command MAC control element is received }

then { UE successfully decodes the MAC control PDU }

}

(6)

Void

(7)

Void

22.3.1.5.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 3.1 and 5.7.

[TS 36.321, clause 3.1]

Active Time: Time related to DRX operation, as defined in subclause 5.7, during which the MAC entity monitors the PDCCH.

…

DRX Cycle: Specifies the periodic repetition of the On Duration followed by a possible period of inactivity (see figure 3.1-1 below).

Figure 3.1-1: DRX Cycle

drx-InactivityTimer: Except for NB-IoT, it specifies the number of consecutive PDCCH-subframe(s) after the subframe in which a PDCCH indicates an initial UL, DL or SL user data transmission for this MAC entity. For NB-IoT, it specifies the number of consecutive PDCCH-subframe(s) after the subframe in which the HARQ RTT timer or UL HARQ RTT timer expires.

drx-RetransmissionTimer: Specifies the maximum number of consecutive PDCCH-subframe(s) until a DL retransmission is received.

drxShortCycleTimer: Specifies the number of consecutive subframe(s) the MAC entity shall follow the Short DRX cycle.

drxStartOffset: Specifies the subframe where the DRX Cycle starts.

drx-ULRetransmissionTimer: Specifies the maximum number of consecutive PDCCH-subframe(s) until a grant for UL retransmission is received.

…

HARQ RTT Timer: This parameter specifies the minimum amount of subframe(s) before a DL HARQ retransmission is expected by the MAC entity.

…

onDurationTimer: Specifies the number of consecutive PDCCH-subframe(s) at the beginning of a DRX Cycle.

PDCCH: Refers to the PDCCH [7], EPDCCH (in subframes when configured), MPDCCH [2], for an RN with R-PDCCH configured and not suspended, to the R-PDCCH or, for NB-IoT to the NPDCCH.

PDCCH period (pp): Refers to the interval between the start of two consecutive PDCCH occasions and depends on the currently used PDCCH search space [2]. A PDCCH occasion is the start of a search space and is defined by subframe k0 as specified in section 16.6 of [2]. For an NB-IoT UE, if a timer duration is configured by upper layers in units of a PDCCH period, the calculation of number of PDCCH-subframes for the timer is done by multiplying the number of PDCCH periods with npdcch-NumRepetitions-RA when the UE uses the common search space or by npdcch-NumRepetitions when the UE uses the UE specific search space.

PDCCH-subframe: Refers to a subframe with PDCCH. For a MAC entity not configured with any TDD serving cell(s), this represents any subframe; for a MAC entity configured with at least one TDD serving cell, if a MAC entity is capable of simultaneous reception and transmission in the aggregated cells, this represents the union over all serving cells of downlink subframes and subframes including DwPTS of the TDD UL/DL configuration indicated by tdd-Config [8], except serving cells that are configured with schedulingCellId [8]; otherwise, this represents the subframes where the SpCell is configured with a downlink subframe or a subframe including DwPTS of the TDD UL/DL configuration indicated by tdd-Config [8].
For RNs with an RN subframe configuration configured and not suspended, in its communication with the E-UTRAN, this represents all downlink subframes configured for RN communication with the E-UTRAN.
For SC-PTM reception on a FDD cell, this represents any subframe of the cell except MBSFN subframes; for SC-PTM reception on a TDD cell, this represents the downlink subframes and subframes including DwPTS of the TDD UL/DL configuration indicated by tdd-Config [8] of the cell except MBSFN subframes.

…

UL HARQ RTT Timer: This parameter specifies the minimum amount of subframe(s) before a UL HARQ retransmission grant is expected by the MAC entity.

[TS 36.321, clause 5.7]

The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for the MAC entity’s C-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, Semi-Persistent Scheduling C-RNTI (if configured), eIMTA-RNTI (if configured), SL-RNTI (if configured), and CC-RNTI (if configured). When in RRC_CONNECTED, if DRX is configured, the MAC entity is allowed to monitor the PDCCH discontinuously using the DRX operation specified in this subclause; otherwise the MAC entity monitors the PDCCH continuously. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other subclauses of this specification. RRC controls DRX operation by configuring the timers onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimer (one per DL HARQ process except for the broadcast process), drx-ULRetransmissionTimer (one per asynchronous UL HARQ process), the longDRX-Cycle, the value of the drxStartOffset and optionally the drxShortCycleTimer and shortDRX-Cycle. A HARQ RTT timer per DL HARQ process (except for the broadcast process) and UL HARQ RTT Timer per asynchronous UL HARQ process is also defined (see subclause 7.7).

When a DRX cycle is configured, the Active Time includes the time while:

– onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimer or drx-ULRetransmissionTimer or mac-ContentionResolutionTimer (as described in subclause 5.1.5) is running; or

– a Scheduling Request is sent on PUCCH and is pending (as described in subclause 5.4.4); or

– an uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer for synchronous HARQ process; or

– a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after successful reception of a Random Access Response for the preamble not selected by the MAC entity (as described in subclause 5.1.4).

When DRX is configured, the MAC entity shall for each subframe:

– if a HARQ RTT Timer expires in this subframe:

– if the data of the corresponding HARQ process was not successfully decoded:

– start the drx-RetransmissionTimer for the corresponding HARQ process;

– if NB-IoT, start or restart the drx-InactivityTimer.

– if an UL HARQ RTT Timer expires in this subframe:

– start the drx-ULRetransmissionTimer for the corresponding HARQ process.

– if NB-IoT, start or restart the drx-InactivityTimer.

– if a DRX Command MAC control element or a Long DRX Command MAC control element is received:

– stop onDurationTimer;

– stop drx-InactivityTimer.

– if drx-InactivityTimer expires or a DRX Command MAC control element is received in this subframe:

– if the Short DRX cycle is configured:

– start or restart drxShortCycleTimer;

– use the Short DRX Cycle.

– else:

– use the Long DRX cycle.

– if drxShortCycleTimer expires in this subframe:

– use the Long DRX cycle.

– if a Long DRX Command MAC control element is received:

– stop drxShortCycleTimer;

– use the Long DRX cycle.

– If the Short DRX Cycle is used and [(SFN * 10) + subframe number] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle); or

– if the Long DRX Cycle is used and [(SFN * 10) + subframe number] modulo (longDRX-Cycle) = drxStartOffset:

– if NB-IoT:

– if neither HARQ RTT Timer nor UL HARQ RTT Timer is running, start onDurationTimer.

– else:

– start onDurationTimer.

– during the Active Time, for a PDCCH-subframe, if the subframe is not required for uplink transmission for half-duplex FDD UE operation, and if the subframe is not a half-duplex guard subframe [7] and if the subframe is not part of a configured measurement gap and if the subframe is not part of a configured Sidelink Discovery Gap for Reception, and for NB-IoT if the subframe is not required for uplink transmission or downlink reception other than on PDCCH; or

– during the Active Time, for a subframe other than a PDCCH-subframe and for a UE capable of simultaneous reception and transmission in the aggregated cells, if the subframe is a downlink subframe indicated by a valid eIMTA L1 signalling for at least one serving cell not configured with schedulingCellId [8] and if the subframe is not part of a configured measurement gap and if the subframe is not part of a configured Sidelink Discovery Gap for Reception; or

– during the Active Time, for a subframe other than a PDCCH-subframe and for a UE not capable of simultaneous reception and transmission in the aggregated cells, if the subframe is a downlink subframe indicated by a valid eIMTA L1 signalling for the SpCell and if the subframe is not part of a configured measurement gap and if the subframe is not part of a configured Sidelink Discovery Gap for Reception:

– monitor the PDCCH;

– if the PDCCH indicates a DL transmission or if a DL assignment has been configured for this subframe:

– if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:

– start the HARQ RTT Timer for the corresponding HARQ process in the subframe containing the last repetition of the corresponding PDSCH reception;

– else:

– start the HARQ RTT Timer for the corresponding HARQ process;

– stop the drx-RetransmissionTimer for the corresponding HARQ process.

– if the PDCCH indicates an UL transmission for an asynchronous HARQ process:

– start the UL HARQ RTT Timer for the corresponding HARQ process in the subframe containing the last repetition of the corresponding PUSCH transmission;

– except for NB-IoT, stop the drx-ULRetransmissionTimer for the corresponding HARQ process.

– if the PDCCH indicates a new transmission (DL, UL or SL):

– except for NB-IoT, start or restart drx-InactivityTimer.

– if the PDCCH indicates a transmission (DL, UL) for a NB-IoT UE:

– stop drx-InactivityTimer, drx-ULRetransmissionTimer and onDurationTimer.

– in current subframe n, if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC control elements/Long DRX Command MAC control elements received and Scheduling Request sent until and including subframe n-5 when evaluating all DRX Active Time conditions as specified in this subclause, type-0-triggered SRS [2] shall not be reported.

– if CQI masking (cqi-Mask) is setup by upper layers:

– in current subframe n, if onDurationTimer would not be running considering grants/assignments/DRX Command MAC control elements/Long DRX Command MAC control elements received until and including subframe n-5 when evaluating all DRX Active Time conditions as specified in this subclause, CQI/PMI/RI/PTI/CRI on PUCCH shall not be reported.

– else:

Regardless of whether the MAC entity is monitoring PDCCH or not, the MAC entity receives and transmits HARQ feedback and transmits type-1-triggered SRS [2] when such is expected.

NOTE: The same Active Time applies to all activated serving cell(s).

NOTE: In case of downlink spatial multiplexing, if a TB is received while the HARQ RTT Timer is running and the previous transmission of the same TB was received at least N subframes before the current subframe (where N corresponds to the HARQ RTT Timer), the MAC entity should process it and restart the HARQ RTT Timer.

NOTE: The BL UE and the UE in enhanced coverage waits until the last subframe of the configured MPDCCH search space before executing the next specified action.

22.3.1.5.3 Test description

22.3.1.5.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

– RRC Connection Setup (preamble: Table 8.1.5.2.3-1, step 3 [18]) using parameters as specified in Table 22.3.1.5.3.3-1

UE:

None.

Preamble:

– UE is in state NB-IoT UE Attach, Connected Mode, UE Test Loopback Activated (State 2B-NB) with test loop mode G and configured to return no data in UL according to [18] in Ncell 1.

22.3.1.5.3.2 Test procedure sequence

DRX parameters and search space parameters according to Table 22.3.1.5.3.3-1 result in periods as shown in the table below

Table 22.3.1.5.3.2-1: DRX parameters and search space parameters

Period/Timer	NPDCCH periods	Duration (ms)
NPDCCH period	1	256 (R_max * G)
DRX cycle	16	16 * 256 = 4096
On Duration	4	1024
Opportunity for DRX	12	3076
drx-InactivityTimer	4	1024
drx-RetransmissionTimer	6	1536
drx-ULRetransmissionTimer	24	6144

In the following figures illustrate timing for the different test purposes; NPDCCH periods are marked in

– green for DL transmission (no CRC error)

– red for DL transmission (CRC error)

– yellow for DL transmission of MAC DRX command CE

– blue for UL transmission

The relevant timer/period for the test purpose is marked in light yellow.

NPDCCH period	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
DRX cycle 1	← On Duration →				← Opportunity for DRX →
DRX cycle 1	← DRX cycle →
NPDCCH period	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
DRX cycle 2	← On Duration →				← Opportunity for DRX →
					← Inactivity Timer →
	← DRX cycle →

Figure 22.3.1.5.3.2-1: Timing for TP1 and TP2

NPDCCH period	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
DRX cycle 1	← On Duration →				← Retransmission Timer →
					← Inactivity Timer →
	← DRX cycle →
NPDCCH period	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
DRX cycle 2	← On Duration →				← Retransmission Timer →
					← Inactivity Timer →
	← DRX cycle →

Figure 22.3.1.5.3.2-2: Timing for TP3

NPDCCH period	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
DRX cycle 1	← On Duration →
					← ULRetransmission Timer …
	← DRX cycle →
NPDCCH period	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
DRX cycle 2	← On Duration →
	… ULRetransmission Timer →
	← DRX cycle →

Figure 22.3.1.5.3.2-3: Timing for TP4

Figure 22.3.1.5.3.2-4: Void

Figure 22.3.1.5.3.2-5: Void

Table 22.3.1.5.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	In the first NPDCCH period of the next DRX On Duration the SS schedules the DL transmission of a MAC PDU in the first search space candidate of the search space.	<–	MAC PDU	–	–
2	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 1?	–>	HARQ ACK	1	P
3	In the last NPDCCH period of the next DRX On Duration the SS schedules DL transmission of a MAC PDU in the last search space candidate of the search space.	<–	MAC PDU	–	–
4	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 3?	–>	HARQ ACK	1	P
5	Four NPDCCH periods after the transmission at step 3 the SS schedules the DL transmission of a MAC PDU in the last search space candidate of the search space. Note: Four NPDCCH periods is the duration of the drx-InactivityTimer	<–	MAC PDU	–	–
6	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 5?	–>	HARQ ACK	2	P
7	In the last NPDCCH period of the next DRX On Duration the SS schedules the DL transmission of a MAC PDU in the last search space candidate of the search space; the SS shall generate a CRC error for this transmission causing the UE to send a NACK but the SS shall not perform any retransmissions.	<–	Invalid MAC PDU	–	–
8	Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 7?	–>	HARQ NACK	1	P
9	In the next NPDCCH period the SS schedules the DL transmission of a (new) MAC PDU in the first search space candidate of the search space. Note: The NDI of the corresponding DCI indicates a new transmission	<–	MAC PDU	–	–
10	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 9?	–>	HARQ ACK	3	P
11	In the last NPDCCH period of the next DRX On Duration the SS schedules the DL transmission of a MAC PDU in the last search space candidate of the search space; the SS shall generate a CRC error for this transmission causing the UE to send a NACK but the SS shall not perform any retransmissions.	<–	Invalid MAC PDU	–	–
12	Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 11?	–>	HARQ NACK	1	P
13	Six NPDCCH periods after the transmission at step 11 the SS schedules the DL transmission of a (new) MAC PDU in the last search space candidate of the search space. Note 1: Six NPDCCH periods is the duration of the drx-RetransmissionTimer Note 2: The NDI of the corresponding DCI indicates a new transmission	<–	MAC PDU	–	–
14	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 13?	–>	HARQ ACK	3	P
15	In the last NPDCCH period of the next DRX On Duration the SS allocates an UL grant for UE in the last search space candidate of the search space.	<–	UL grant on PDCCH	–	–
16	Check: Does the UE transmit a Buffer Status Report on the UL indicating an empty buffer?	–>	Buffer Status Report MAC control element	–	–
17	24 NPDCCH periods after the transmission at step 15 the SS schedules the DL transmission of a MAC PDU in the last search space candidate of the search space. Note: 26 NPDCCH periods is the duration of the drx-ULRetransmissionTimer	<–	MAC PDU	–	–
18	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 17?	–>	HARQ ACK	4	P
19	In the third NPDCCH period of the next DRX On Duration the SS schedules the DL transmission of a MAC PDU in the first search space candidate of the search space; the SS shall generate a CRC error for this transmission causing the UE to send a NACK but the SS shall not perform any retransmissions.	<–	Invalid MAC PDU	–	–
20	Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 19?	–>	HARQ NACK	5	P
21	In the next NPDCCH period after the MAC PDU at step 19 was sent the SS schedules the DL transmission of a MAC PDU containing a DRX MAC Control element in the first search space candidate of the search space. Note 1: MAC PDU in step 19 causes drx‑InactivityTimer and onDurationTimer to be stopped at the UE and the UE starts the HARQ RTT. Note 2: Expiry of HARQ RTT timer at the end of the NPDCCH period causes start of drx-RetransmissionTimer and drx‑InactivityTimer. Note 3: The NDI of the corresponding DCI indicates a new transmission.	<–	MAC PDU(DRX MAC Control element)	–	–
22	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 21? Note: The UE sends the HARQ when it has successfully decoded the MAC PDU containing the DRX MAC Control element	–>	HARQ ACK	5	P
23-30	Void			–	–

22.3.1.5.3.3 Specific message contents

Table 22.3.1.5.3.3-1: RRCConnectionSetup-NB

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 {
mac-MainConfig-r13 CHOICE {
explicitValue-r13 SEQUENCE {
ul-SCH-Config-r13 SEQUENCE {
periodicBSR-Timer-r13	infinity
}
drx-Config-r13 SEQUENCE {
setup SEQUENCE {
onDurationTimer-r13	pp4	4 NPDCCH periods
drx-InactivityTimer-r13	pp4	4 NPDCCH periods
drx-RetransmissionTimer-r13	pp6	6 NPDCCH periods
drx-Cycle-r13	st4096	16 NPDCCH periods (Note 1)
drx-StartOffset-r13	0
drx-ULRetransmissionTimer-r13	pp24	24 NPDCCH periods
}
}
}
}
physicalConfigDedicated-r13 SEQUENCE {
npdcch-ConfigDedicated-r13 SEQUENCE {
npdcch-NumRepetitions-r13	r64	R_max=64 (Note 1)
}
}
}
}
}
}
}

Note 1: The default value of ‘npdcch-StartSF-USS’=4 and the specific value ‘npdcch-NumRepetitions-r13’=64 result in PDCCH period =256 for the UE specific search space.

22.3.1.5a NB-IoT / NTN / DRX / (UL)HARQ RTT

22.3.1.5a.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state with DRX cycle configured and a new DL transmission is indicated on the NPDCCH during Active Time }

ensure that {
when { After expiry of the HARQ RTT timer with the consideration of UE-eNB RTT }

then { UE starts or restarts the Drx-InactivityTimer-r13 and monitors the NPDCCH for Drx-InactivityTimer-r13 NPDCCH periods }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state and DRX cycle is configured }

ensure that {
when { when a HARQ RTT Timer expires with the consideration of UE-eNB RTT and the data in the soft buffer of the corresponding HARQ process has not been successfully decoded }

then { UE starts the drx-RetransmissionTimer-r13 for the corresponding HARQ process and monitors the NPDCCH for drx-RetransmissionTimer-r13 consecutive NPDCCH periods }

}

22.3.1.5a.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.321 clauses 3.1, 5.7, 7.7 and Annex C. Unless otherwise stated these are Rel-17 requirements.

[TS 36.321, clause 3.1]

drx-InactivityTimer: Except for NB-IoT UEs, BL UEs or UEs in enhanced coverage, it specifies the number of consecutive PDCCH-subframe(s) after the subframe in which a PDCCH indicates an initial UL, DL or SL user data transmission for this MAC entity. For NB-IoT UEs, it specifies the number of consecutive PDCCH-subframe(s) after the subframe in which the HARQ RTT timer or UL HARQ RTT timer expires. For BL UEs or UEs in enhanced coverage, it specifies the number of consecutive PDCCH-subframe(s) following the subframe containing the last repetition of the PDCCH reception that indicates an initial UL or DL user data transmission for this MAC entity.

drx-RetransmissionTimer: Specifies the maximum number of consecutive PDCCH-subframe(s) until a DL retransmission is received.

…

drx-ULRetransmissionTimer: Specifies the maximum number of consecutive PDCCH-subframe(s) until a grant for UL retransmission or the HARQ feedback is received.

…

UE-eNB RTT: For non-terrestrial networks, the sum of the UE’s Timing Advance value (see TS 36.211 [7], clause 8.1) and k_Mac.

UL HARQ RTT Timer: This parameter specifies the minimum amount of subframe(s) before a UL HARQ retransmission grant is expected by the MAC entity.

[TS 36.321, clause 5.7]

The MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for the MAC entity’s C-RNTI, TPC-PUCCH-RNTI, TPC-PUSCH-RNTI, Semi-Persistent Scheduling C-RNTI (if configured), UL Semi-Persistent Scheduling V-RNTI (if configured), eIMTA-RNTI (if configured), SL-RNTI (if configured), SL-V-RNTI (if configured), CC-RNTI (if configured), SRS-TPC-RNTI (if configured), and AUL C-RNTI (if configured). When in RRC_CONNECTED, if DRX is configured, the MAC entity is allowed to monitor the PDCCH discontinuously using the DRX operation specified in this clause; otherwise the MAC entity monitors the PDCCH continuously. When using DRX operation, the MAC entity shall also monitor PDCCH according to requirements found in other clauses of this specification. RRC controls DRX operation by configuring the timers onDurationTimer, drx-InactivityTimer, drx-RetransmissionTimer (for HARQ processes scheduled using 1ms TTI, one per DL HARQ process except for the broadcast process), drx-RetransmissionTimerShortTTI (for HARQ processes scheduled using short TTI, one per DL HARQ process), drx-ULRetransmissionTimer (for HARQ processes scheduled using 1ms TTI, one per asynchronous UL HARQ process), drx-ULRetransmissionTimerShortTTI (for HARQ processes scheduled using short TTI, one per asynchronous UL HARQ process), the longDRX-Cycle, the value of the drxStartOffset and optionally the drxShortCycleTimer and shortDRX-Cycle. A HARQ RTT timer per DL HARQ process (except for the broadcast process) and UL HARQ RTT Timer per asynchronous UL HARQ process is also defined (see clause 7.7).

When a DRX cycle is configured, the Active Time includes the time while:

– onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimer or drx-RetransmissionTimerShortTTI or drx-ULRetransmissionTimer or drx-ULRetransmissionTimerShortTTI or mac-ContentionResolutionTimer (as described in clause 5.1.5) is running; or

– a Scheduling Request is sent on PUCCH/SPUCCH and is pending (as described in clause 5.4.4); or

– an uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer for synchronous HARQ process; or

– mpdcch-UL-HARQ-ACK-FeedbackConfig is configured and repetitions within a bundle are being transmitted according to UL_REPETITION_NUMBER.

When DRX is configured, the MAC entity shall for each subframe:

– if a HARQ RTT Timer expires in this subframe:

– if the data of the corresponding HARQ process was not successfully decoded:

– start the drx-RetransmissionTimer or drx-RetransmissionTimerShortTTI for the corresponding HARQ process;

– if NB-IoT:

– if lower layers had indicated multiple TBs were scheduled for the associated expired HARQ RTT Timer:

– start or restart drx-InactivityTimer when all HARQ RTT Timers have expired;

– else:

– start or restart the drx-InactivityTimer.

– if an UL HARQ RTT Timer expires in this subframe:

– start the drx-ULRetransmissionTimer or drx-ULRetransmissionTimerShortTTI for the corresponding HARQ process.

– if NB-IoT:

– if lower layers had indicated multiple TBs were scheduled for the associated expired HARQ RTT Timer:

– start or restart drx-InactivityTimer when all HARQ RTT Timers have expired;

– else:

– start or restart the drx-InactivityTimer.

– if a DRX Command MAC control element or a Long DRX Command MAC control element is received:

– stop onDurationTimer;

– stop drx-InactivityTimer.

– if drx-InactivityTimer expires or a DRX Command MAC control element is received in this subframe:

– if the Short DRX cycle is configured:

– start or restart drxShortCycleTimer;

– use the Short DRX Cycle.

– else:

– use the Long DRX cycle.

– if drxShortCycleTimer expires in this subframe:

– use the Long DRX cycle.

– if a Long DRX Command MAC control element is received:

– stop drxShortCycleTimer;

– use the Long DRX cycle.

– If the Short DRX Cycle is used and [(SFN * 10) + subframe number] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle); or

– if the Long DRX Cycle is used and [(SFN * 10) + subframe number] modulo (longDRX-Cycle) = drxStartOffset:

– if NB-IoT:

– if there is at least one HARQ process for which neither HARQ RTT Timer nor UL HARQ RTT Timer is running, start onDurationTimer.

– else:

– start onDurationTimer.

– during the Active Time, for a PDCCH-subframe, if the subframe is not required for uplink transmission for half-duplex FDD UE operation, and if the subframe is not a half-duplex guard subframe, as specified in TS 36.211 [7], and if the subframe is not part of a configured measurement gap and if the subframe is not part of a configured Sidelink Discovery Gap for Reception, and for NB-IoT if the subframe is not required for uplink transmission or downlink reception other than on PDCCH; or

– during the Active Time, for a subframe other than a PDCCH-subframe and for a UE capable of simultaneous reception and transmission in the aggregated cells, if the subframe is a downlink subframe indicated by a valid eIMTA L1 signalling for at least one serving cell not configured with schedulingCellId, as specified in TS 36.331 [8] and if the subframe is not part of a configured measurement gap and if the subframe is not part of a configured Sidelink Discovery Gap for Reception; or

– monitor the PDCCH;

– if the PDCCH indicates a DL transmission or if a DL assignment has been configured for this subframe:

– if the UE is an NB-IoT UE, a BL UE or a UE in enhanced coverage:

– if lower layers have indicated scheduling of transmission of multiple TBs:

– start the HARQ RTT Timers for all HARQ processes corresponding to the scheduled TBs in the subframe containing the last repetition of the PDSCH corresponding to the last scheduled TB;

– else:

– start the HARQ RTT Timer for the corresponding HARQ process in the subframe containing the last repetition of the corresponding PDSCH reception;

– else:

– start the HARQ RTT Timer for the corresponding HARQ process;

– stop the drx-RetransmissionTimer or drx-RetransmissionTimerShortTTI for the corresponding HARQ process.

– if NB-IoT, stop drx-ULRetransmissionTimer for all UL HARQ processes.

– if the PDCCH indicates an UL transmission for an asynchronous HARQ process or if an UL grant has been configured for an asynchronous HARQ process for this subframe, or if the PDCCH indicates an UL transmission for an autonomous HARQ process or;

– if the uplink grant is a configured grant for the MAC entity’s AUL C-RNTI and if the corresponding PUSCH transmission has been performed in this subframe:

– if mpdcch-UL-HARQ-ACK-FeedbackConfig is not configured:

– if lower layers have indicated scheduling of transmission of multiple TBs:

– start the UL HARQ RTT Timers for all scheduled HARQ processes in the subframe containing the last repetition of the PUSCH corresponding to the last scheduled TB;

– else:

– start the UL HARQ RTT Timer for the corresponding HARQ process in the subframe containing the last repetition of the corresponding PUSCH transmission;

– stop the drx-ULRetransmissionTimer or drx-ULRetransmissionTimerShortTTI for the corresponding HARQ process;

– if mpdcch-UL-HARQ-ACK-FeedbackConfig is configured and an UL HARQ-ACK feedback has not been received on PDCCH until the last repetition of the corresponding PUSCH transmission:

– start or restart the drx-ULRetransmissionTimer for the corresponding HARQ process in the subframe containing the last repetition of the corresponding PUSCH transmission;

– if NB-IoT, stop drx-RetransmissionTimer for all DL HARQ processes.

– if the PDCCH indicates a new transmission (DL, UL or SL):

– except for an NB-IoT UE configured with a single DL and UL HARQ process and when PDCCH indicates the transmission is not for multiple TBs:

– start or restart drx-InactivityTimer.

– if the PDCCH indicates a transmission (DL, UL) for an NB-IoT UE:

– if the NB-IoT UE is configured with a single DL and UL HARQ process; or

– if the PDCCH indicates the transmission is for multiple TBs:

– stop drx-InactivityTimer.

– stop onDurationTimer.

– if the PDCCH indicates an UL HARQ-ACK feedback for an asynchronous UL HARQ process for a UE configured with mpdcch-UL-HARQ-ACK-FeedbackConfig:

– if the lower layer had indicated scheduling of transmission of multiple TBs:

– stop drx-ULRetransmissionTimer for the corresponding UL HARQ process(es).

– else if the PUSCH transmission is completed:

– stop drx-ULRetransmissionTimer for all UL HARQ processes.

– if the PDCCH indicates HARQ feedback for one or more HARQ processes for which UL HARQ operation is autonomous:

– stop the drx-ULRetransmissionTimer for the corresponding HARQ process(es).

– in current subframe n, if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC control elements/Long DRX Command MAC control elements received and Scheduling Request sent until and including subframe n-5 when evaluating all DRX Active Time conditions as specified in this clause, type-0-triggered SRS, as specified in TS 36.213 [2], shall not be reported.

– if CQI masking (cqi-Mask) is setup by upper layers:

– in current TTI n, if onDurationTimer would not be running considering grants/assignments/DRX Command MAC control elements/Long DRX Command MAC control elements received until and including TTI n-5 when evaluating all DRX Active Time conditions as specified in this clause, CQI/PMI/RI/PTI/CRI on PUCCH shall not be reported.

– else:

– in current TTI n, if the MAC entity would not be in Active Time considering grants/assignments/DRX Command MAC control elements/Long DRX Command MAC control elements received and Scheduling Request sent until and including TTI n-5 when evaluating all DRX Active Time conditions as specified in this clause, CQI/PMI/RI/PTI/CRI on PUCCH shall not be reported.

For NB-IoT, onDurationTimer may start within a PDCCH period and end within a PDCCH period. The UE shall monitor NPDCCH during these partial PDCCH periods while onDurationTimer is running.

Regardless of whether the MAC entity is monitoring PDCCH or not, the MAC entity receives and transmits HARQ feedback and transmits type-1-triggered SRS, as specified in TS 36.213 [2], when such is expected. The MAC entity monitors PDCCH addressed to CC-RNTI for a PUSCH trigger B, as specified in TS 36.213 [2], on the corresponding SCell even if the MAC entity is not in Active Time. when such is expected.

When the BL UE or the UE in enhanced coverage or NB-IoT UE receives PDCCH, the UE executes the corresponding action specified in this clause in the subframe following the subframe containing the last repetition of the PDCCH reception where such subframe is determined by the starting subframe and the DCI subframe repetition number field in the PDCCH specified in TS 36.213 [2], unless explicitly stated otherwise.

NOTE 1: The same Active Time applies to all activated serving cell(s).

NOTE 2: In case of downlink spatial multiplexing, if a TB is received while the HARQ RTT Timer is running and the previous transmission of the same TB was received at least N subframes before the current subframe (where N corresponds to the HARQ RTT Timer), the MAC entity should process it and restart the HARQ RTT Timer.

NOTE 3: The MAC entity does not consider PUSCH trigger B, as specified in TS 36.213 [2], to be an indication of a new transmission.

NOTE 4: For NB-IoT, for operation in FDD mode, and for operation in TDD mode with a single HARQ process, DL and UL transmissions will not be scheduled in parallel, i.e. if a DL transmission has been scheduled an UL transmission will not be scheduled until HARQ RTT Timer of the DL HARQ process has expired (and vice versa).

[TS 36.321, clause 7.7]

For each serving cell, in case of FDD configuration not configured with subframeAssignment-r15 and in case of Frame Structure Type 3 configuration on the serving cell which carries the HARQ feedback for this serving cell the HARQ RTT Timer is set to 8 subframes. For each serving cell, in case of TDD configuration or FDD with subframeAssignment-r15 configured on the serving cell which carries the HARQ feedback for this serving cell the HARQ RTT Timer is set to k + 4 subframes, where k is the interval between the downlink transmission and the transmission of associated HARQ feedback, as indicated in clauses 10.1 and 10.2 of TS 36.213 [2], and for an RN configured with rn-SubframeConfig, as specified in TS 36.331 [8] and not suspended, as indicated in Table 7.5.1-1 of TS 36.216 [11].

For each serving cell, for HARQ processes scheduled using Short Processing Time (TS 36.331 [8]) the HARQ RTT is set to 6 subframes for FDD and Frame Structure Type 3 and set to k + 3 subframes for TDD, where k is the interval between the downlink transmission and the transmission of associated HARQ feedback, as indicated in clauses 10.1 and 10.2 of TS 36.213 [2].

For each serving cell, for HARQ processes scheduled using short TTI (TS 36.331 [8]) the HARQ RTT is set to 8 TTIs if the TTI length is one slot or if proc-Timeline is set to n+4 set1, to 12 TTIs if proc-Timeline is set to n+6 set1 or n+6 set2 and to 16 TTIs if proc-Timeline is set to n+8 set2 for FDD and Frame Structure Type 3.

For TDD short TTI the HARQ RTT is set to k + 4 TTIs, where k is the interval between the downlink transmission and the transmission of associated HARQ feedback, as indicated in clauses 10.1 and 10.2 of TS 36.213 [2].

…

For NB-IoT, when single TB is scheduled by PDCCH or when multiple TBs are scheduled for the interleaved case when HARQ-ACK bundling is configured the HARQ RTT Timer is set to k+3+N + RTToffset +deltaPDCCH subframes, where k is the interval between the last subframe of the downlink transmission and the first subframe of the associated HARQ feedback transmission and N is the transmission duration in subframes of the associated HARQ feedback, and deltaPDCCH is the interval starting from the subframe following the last subframe of the associated HARQ feedback transmission plus 3 subframes to the first subframe of the next PDCCH occasion.

For NB-IoT, when multiple TBs are scheduled by PDCCH for the non-interleaved case or for the interleaved case when HARQ-ACK bundling is not configured, the HARQ RTT Timer is set to k+2*N+1 + RTToffset +deltaPDCCH subframes where k is the interval between the last subframe of the downlink transmission and the first subframe of the first HARQ feedback transmission and N is the transmission duration in subframes of the associated HARQ feedback, and deltaPDCCH is the interval starting from the subframe following the last subframe of the last HARQ feedback transmission plus 1 subframe to the first subframe of the next PDCCH occasion.

Except for NB-IoT and for HARQ processes scheduled using Short Processing Time and for short TTI, UL HARQ RTT Timer length is set to 4 subframes for FDD and Frame Structure Type 3, and set to k_ULHARQRTT subframes for TDD, where k_ULHARQRTT equals to the k_PHICH value indicated in Table 9.1.2-1 of TS 36.213 [2] if the UE is not configured with upper layer parameter symPUSCH-UpPts for the serving cell, otherwise the k_PHICH value is indicated in Table 9.1.2-3.

For NB-IoT, when single TB is scheduled by PDCCH the UL HARQ RTT timer length is set to 4 + RTToffset +deltaPDCCH subframes, where deltaPDCCH is the interval starting from the subframe following the last subframe of the PUSCH transmission plus 3 subframes to the first subframe of the next PDCCH occasion.

For NB-IoT, when multiple TBs are scheduled by PDCCH the UL HARQ RTT timer length is set to 1 + RTToffset +deltaPDCCH subframes, where deltaPDCCH is the interval starting from the subframe following the last subframe of the PUSCH transmission plus 1 subframe to the first subframe of the next PDCCH occasion.

For HARQ processes scheduled using Short Processing Time (TS 36.331 [8]), the UL HARQ RTT Timer length is set to 3 subframes for FDD and for Frame Structure Type 3, and set to k_ULHARQRTT subframes for TDD, where k_ULHARQRTT equals the value indicated in Table 7.7-1 and Table 7.7-2.

For HARQ processes scheduled using short TTI (TS 36.331 [8]), the UL HARQ RTT Timer length is set to 8 TTIs if the TTI length is one slot or if proc-Timeline is set to n+4 set1, to 12 TTIs if proc-Timeline is set to n+6 set1 or n+6 set2 and to 16 TTIs if proc-Timeline is set to n+8 set2 for FDD and Frame Structure Type 3. For TDD short TTI the UL HARQ RTT is set to k_ULHARQRTT TTIs, where k_ULHARQRTT equals the value indicated in Table 7.7-3, Table 7.7-4 and Table 7.7-5.

Table 7.7-1: k_ULHARQRTT for TDD Short Processing Time when special subframe configurations 0~9 is configured

TDD UL/DL Configuration	subframe index n
TDD UL/DL Configuration	0	1	2	3	4	5	6	7	8	9
0			3	3	6			3	3	6
1			3	3				3	3
2			3					3
3			3	3	3
4			3	3
5			3
6			3	3	5			3	3

Table 7.7-2: k_ULHARQRTT for TDD Short Processing Time applied when special subframe configuration 10 is configured

TDD UL/DL Configuration	subframe index n
TDD UL/DL Configuration	0	1	2	3	4	5	6	7	8	9
0		4	3	3	6		4	3	3	6
1		3	3	3			3	3	3
2		3	3				3	3
3		4	3	3	3
4		3	3	3
5		3	3
6		4	3	3	5		3	3	3

Table 7.7-3: k_ULHARQRTT for TDD short TTI applied when special subframe configurations 1, 2, 3, 4, 6, 7 and 8 are configured

TDD UL/DL Configuration	sTTI index n
TDD UL/DL Configuration	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
0					6	5	4	4	4	4					6	5	4	4	4	4
1					4	4	4	4							4	4	4	4
2					4	4									4	4
3					6	5	4	4	4	4
4					4	4	4	4
5					4	4
6					6	5	4	4	4	4					4	4	4	4

Table 7.7-4: k_ULHARQRTT for TDD short TTI applied when special subframe configurations 0, 5 and 9 are configured

TDD UL/DL Configuration	sTTI index n
TDD UL/DL Configuration	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
0					6	5	4	4	4	11					6	5	4	4	4	11
1					4	4	4	4							4	4	4	4
2					4	4									4	4
3					6	5	4	4	4	4
4					4	4	4	4
5					4	4
6					6	5	4	4	4	9					4	4	4	4

Table 7.7-5: k_ULHARQRTT for TDD short TTI applied when special subframe configuration 10 is configured

TDD UL/DL Configuration	sTTI index n
TDD UL/DL Configuration	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
0				7	6	5	4	4	4	11				7	6	5	4	4	4	11
1				5	4	4	4	4						5	4	4	4	4
2				4	4	4								4	4	4
3				7	6	5	4	4	4	4
4				5	4	4	4	4
5				4	4	4
6				7	6	5	4	4	4	9				5	4	4	4	4

NOTE: RTToffset = 0 in terrestrial networks and RTToffset = UE-eNB RTT in Non-terrestrial networks.

[TS 36.321, Annex C]

When a DRX timer is set to a value of X, and n denotes the subframe in which the related event is triggered according to the clause 5.7, the intended behaviours of each DRX timer are presented in the Table C-1 below:

Table C-1: Intended UE behaviour for DRX timers

DRX Timers	Intended UE behaviour ([x, y] means including subframe x and y)
drx-InactivityTimer	The MAC entity monitors PDCCH in PDCCH-subframes during the subframes [n+1, n+m]. The MAC entity starts or restarts drxShortCycleTimer, and uses Short DRX Cycle in the subframe n+m+1, if configured.
drx-InactivityTimerSCPTM	The MAC entity monitors PDCCH in PDCCH-subframes during the subframes [n+1, n+m].
mac-ContentionResolutionTimer or mac-ContentionResolutionTimer for the corresponding enhanced coverage level, if it exists	The MAC entity monitors PDCCH in PDCCH-subframes during the subframes [n+1, n+X].
drx-RetransmissionTimer or drx-ULRetransmissionTimer	The MAC entity monitors PDCCH in PDCCH-subframes during the subframes [n, n+m-1].
onDurationTimer or onDurationTimerSCPTM	The MAC entity monitors PDCCH in PDCCH-subframes during the subframes [n, n+m-1].
drxShortCycleTimer	The MAC entity uses the Short DRX Cycle during the subframes [n, n+X-1]. The MAC entity starts to use the Long DRX Cycle in the subframe n+X.
HARQ RTT Timer	The MAC entity starts drx-RetransmissionTimer in the subframe n+X, if needed.
UL HARQ RTT Timer	The MAC entity starts drx-ULRetransmissionTimer in the subframe n+X, if needed.
NOTE 1: For FDD, m is equal to X; for TDD, m is equal to the minimum number of subframes so that X PDCCH-subframes are included during the subframes [x, y]. NOTE 2: A MAC entity configured with eIMTA monitors PDCCH in some subframe(s) in addition to PDCCH-subframes, as specified in clause 5.7. NOTE 3: For BL UE or UE in enhanced coverage, m is equal to the minimum number of subframes so that X PDCCH-subframes are included during the subframes [x, y].

For drx-InactivityTimerSCPTM, drx-InactivityTimer, drx-RetransmissionTimer and drx-ULRetransmissionTimer, if X=0, the timer does not make the MAC entity to monitor the PDCCH.

The intended UE behaviours in Table C-1 are not applicable for NB-IoT.

For NB-IoT, the intended UE behaviour regarding setting the HARQ RTT Timer is shown in Figure C-1 and for the UL HARQ RTT Timer is shown in Figure C-2.

Figure C-1: Setting the HARQ RTT Timer for NB-IoT

Figure C-2: Setting the UL HARQ RTT Timer for NB-IoT

NOTE: UE-eNB RTT is taken into account when calculating the (UL) HARQ RTT timer.

22.3.1.5a.3 Test description

22.3.1.5a.3.1 Pre-test conditions

System Simulator:

– Ncell 1 is configured according to Table 8.1.4.2-1 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 with test loop mode G and configured to return no data in UL according to according to TS 38.508 [18] clause 8.1.5.1 in Ncell 1.

22.3.1.5a.3.2 Test procedure sequence

DRX parameters and search space parameters according to Table 22.3.1.5a.3.3-1 result in periods as shown in the table below

Table 22.3.1.5a.3.2-1: DRX parameters and search space parameters

Period/Timer	NPDCCH periods	Duration (ms)
NPDCCH period	1	256 (R_max * G)
DRX cycle	16	16 * 256 = 4096
On Duration	4	1024
Opportunity for DRX	12	3076
drx-InactivityTimer	4	1024
drx-RetransmissionTimer	6	1536
drx-ULRetransmissionTimer	24	6144

In the following figures illustrate timing for the different test purposes; NPDCCH periods are marked in

– green for DL transmission (no CRC error)

– red for DL transmission (CRC error)

– yellow for DL transmission of MAC DRX command CE

– blue for UL transmission

The relevant timer/period for the test purpose is marked in light yellow.

NPDCCH period	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
DRX cycle 1	← On Duration →				← Opportunity for DRX →
DRX cycle 1	← DRX cycle →
NPDCCH period	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
DRX cycle 2	← On Duration →				← Opportunity for DRX →
					← Inactivity Timer →
	← DRX cycle →

Figure 22.3.1.5a.3.2-1: Timing for TP1

NPDCCH period	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
DRX cycle 1	← On Duration →				← Retransmission Timer →
					← Inactivity Timer →
	← DRX cycle →
NPDCCH period	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
DRX cycle 2	← On Duration →				← Retransmission Timer →
					← Inactivity Timer →
	← DRX cycle →

Figure 22.3.1.5a.3.2-2: Timing for TP2

Table 22.3.1.5a.3.2-2: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	In the first NPDCCH period of the next DRX On Duration the SS schedules the DL transmission of a MAC PDU in the first search space candidate of the search space.	<–	MAC PDU	–	–
2	The UE transmits a HARQ ACK for the DL MAC PDU in Step 1.	–>	HARQ ACK	–	–
3	In the last NPDCCH period of the next DRX On Duration the SS schedules DL transmission of a MAC PDU in the last search space candidate of the search space.	<–	MAC PDU	–	–
4	The UE transmit a HARQ ACK for the DL MAC PDU in Step 3.	–>	HARQ ACK	–	–
5	Four NPDCCH periods after the transmission at step 3 the SS schedules the DL transmission of a MAC PDU in the last search space candidate of the search space. Note: Four NPDCCH periods is the duration of the drx-InactivityTimer-r13.	<–	MAC PDU	–	–
6	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 5?	–>	HARQ ACK	1	P
7	In the last NPDCCH period of the next DRX On Duration the SS schedules the DL transmission of a MAC PDU in the last search space candidate of the search space; the SS shall generate a CRC error for this transmission causing the UE to send a NACK but the SS shall not perform any retransmissions.	<–	Invalid MAC PDU	–	–
8	Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 7?	–>	HARQ NACK	1	P
9	In the next NPDCCH period the SS schedules the DL transmission of a (new) MAC PDU in the first search space candidate of the search space. Note: The NDI of the corresponding DCI indicates a new transmission.	<–	MAC PDU	–	–
10	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 9?	–>	HARQ ACK	2	P
11	In the last NPDCCH period of the next DRX On Duration the SS schedules the DL transmission of a MAC PDU in the last search space candidate of the search space; the SS shall generate a CRC error for this transmission causing the UE to send a NACK but the SS shall not perform any retransmissions.	<–	Invalid MAC PDU	–	–
12	Check: Does the UE transmit a HARQ NACK for the DL MAC PDU in Step 11?	–>	HARQ NACK	1	P
13	Six NPDCCH periods after the transmission at step 11 the SS schedules the DL transmission of a (new) MAC PDU in the last search space candidate of the search space. Note 1: Six NPDCCH periods is the duration of the drx-RetransmissionTimer-r13. Note 2: The NDI of the corresponding DCI indicates a new transmission	<–	MAC PDU	–	–
14	Check: Does the UE transmit a HARQ ACK for the DL MAC PDU in Step 13?	–>	HARQ ACK	2	P

22.3.1.5a.3.3 Specific message contents

Table 22.3.1.5a.3.3-1: RRCConnectionSetup-NB (Preamble, Table 22.3.1.5a.3.2-2)

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 {
mac-MainConfig-r13 CHOICE {
explicitValue-r13 SEQUENCE {
ul-SCH-Config-r13 SEQUENCE {
periodicBSR-Timer-r13	infinity
}
drx-Config-r13 SEQUENCE {
setup SEQUENCE {
onDurationTimer-r13	pp4	4 NPDCCH periods
drx-InactivityTimer-r13	pp4	4 NPDCCH periods
drx-RetransmissionTimer-r13	pp6	6 NPDCCH periods
drx-Cycle-r13	st4096	16 NPDCCH periods (Note 1)
drx-StartOffset-r13	0
drx-ULRetransmissionTimer-r13	pp24	24 NPDCCH periods
}
}
}
}
physicalConfigDedicated-r13 SEQUENCE {
npdcch-ConfigDedicated-r13 SEQUENCE {
npdcch-NumRepetitions-r13	r64	R_max=64 (Note 1)
}
}
}
}
}
}
}

Note 1: The default value of ‘npdcch-StartSF-USS’=4 and the specific value ‘npdcch-NumRepetitions-r13’=64 result in PDCCH period =256 for the UE specific search space.

Table 22.3.1.5a.3.3-2: SystemInformationBlockType31-NB (preamble, Table 22.3.1.5a.3.2-2)

Derivation Path: TS 36.508 [18], Table 8.1.4.3.3-10
Information Element	Value/remark	Comment	Condition
SystemInformationBlockType31-NB-r17 ::= SEQUENCE {
servingSatelliteInfo-r17 SEQUENCE {
k-Mac-r17	1
}
}

22.3.1.6 NB-IoT / DL-SCH / UL-SCH transport block size selection / DCI format N1/ N0

22.3.1.6.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UE on NPDCCH receives DCI format N1 indicating a resource assignment corresponding to number of subframes and a modulation and coding scheme }

then { UE decodes the received transport block of size corresponding to the read and and forwards it to higher layers }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state }

ensure that {

when { UE has pending data for transmission and receives a Resource Block Assignment corresponding to number of subframes and a modulation and coding scheme for NPUSCH scheduling }

then { UE transmits MAC PDU on NPUSCH on the granted resources using a transport block size corresponding to the read and }

22.3.1.6.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.212, clause 6.4.3.1, 6.4.3.2; TS 36.213, clauses 16.4.3.1, 16.4.1.5, 16.4.1.5.1; and TS 36.306 clause 4.1C.

[TS 36.212, clause 6.4.3.1]

DCI format N0 is used for the scheduling of NPUSCH in one UL cell.

The following information is transmitted by means of the DCI format N0:

– Flag for format N0/format N1 differentiation – 1 bit, where value 0 indicates format N0 and value 1 indicates format N1

– Subcarrier indication – 6 bits as defined in section 16.5.1.1 of [3]

– Resource assignment – 3 bits as defined in section 16.5.1.2 of [3]

– Scheduling delay – 2 bits as defined in section 16.5.1 of [3]

– Modulation and coding scheme – 4 bits as defined in section 16.5.1.2 of [3]

– Redundancy version – 1 bit as defined in section 16.5.1.2 of [3]

– Repetition number – 3 bits as defined in section 16.5.1.2 of [3]

– New data indicator – 1 bit

– DCI subframe repetition number – 2 bits as defined in section 16.6 in [3]

[TS 36.212, clause 6.4.3.2]

DCI format N1 is used for the scheduling of one NPDSCH codeword in one cell and random access procedure initiated by a NPDCCH order. The DCI corresponding to a NPDCCH order is carried by NPDCCH.

The following information is transmitted by means of the DCI format N1:

– Flag for format N0/format N1 differentiation – 1 bit, where value 0 indicates format N0 and value 1 indicates format N1

– NPDCCH order indicator – 1 bit

Format N1 is used for random access procedure initiated by a NPDCCH order only if NPDCCH order indicator is set to ‘1’, format N1 CRC is scrambled with C-RNTI, and all the remaining fields are set as follows:

– Starting number of NPRACH repetitions – 2 bits as defined in section 16.3.1 of [3]

– Subcarrier indication of NPRACH – 6 bits as defined in section 16.3.1 of [3]

– All the remaining bits in format N1 are set to one

Otherwise,

– Scheduling delay – 3 bits as defined in section 16.4.1 of [3]

– Resource assignment – 3 bits as defined in section 16.4.1.3 of [3]

– Modulation and coding scheme – 4 bits as defined in section 16.4.1.5 of [3]

– Repetition number – 4 bits as defined in section 16.4.1.3 of [3]

– New data indicator – 1 bit

– HARQ-ACK resource – 4 bits as defined in section 16.4.2 of [3].

– DCI subframe repetition number – 2 bits as defined in section 16.6 in [3]

When the format N1 CRC is scrambled with a RA-RNTI, then the following fields among the fields above are reserved:

– New data indicator

– HARQ-ACK resource

If the number of information bits in format N1 is less than that of format N0, zeros shall be appended to format N1 until the payload size equals that of format N0.

[TS 36.306, clause 4.1C]

The field ue-Category-NB defines a combined uplink and downlink capability in NB-IoT. The parameters set by the UE Category are defined in subclause 4.2. Tables 4.1C-1 and 4.1C-2 define the downlink and, respectively, uplink physical layer parameter values for each UE Category.

Table 4.1C-1: Downlink physical layer parameter values set by the field ue-Category-NB

UE Category	Maximum number of DL-SCH transport block bits received within a TTI	Maximum number of bits of a DL-SCH transport block received within a TTI	Total number of soft channel bits
Category NB1	680	680	2112

Table 4.1C-2: Uplink physical layer parameter values set by the field ue-Category-NB

UE Category	Maximum number of UL-SCH transport block bits transmitted within a TTI	Maximum number of bits of an UL-SCH transport block transmitted within a TTI
Category NB1	1000	1000

[TS 36.213, clause 16.4.1.3]

The resource allocation information in DCI format N1, N2 (paging) for NPDSCH indicates to a scheduled UE

– a number of subframes () determined by the resource assignment field () in the corresponding DCI according to Table 16.4.1.3-1.

– a repetition number () determined by the repetition number field () in the corresponding DCI according to Table 16.4.1.3-2.

Table 16.4.1.3-1: Number of subframes () for NPDSCH


0	1
1	2
2	3
3	4
4	5
5	6
6	8
7	10

Table 16.4.1.3-2: Number of repetitions () for NPDSCH


0	1
1	2
2	4
3	8
4	16
5	32
6	64
7	128
8	192
9	256
10	384
11	512
12	768
13	1024
14	1536
15	2048

The number of repetitions for the NPDSCH carrying SystemInformationBlockType1-NB is determined based on the parameter schedulingInfoSIB1 configured by higher-layers and according to Table 16.4.1.3-3.

[TS 36.213, clause 16.4.1.5]

The UE shall use modulation order, = 2.

To determine the transport block size in the NPDSCH, the UE shall first,

– if NPDSCH carries SystemInformationBlockType1-NB

– set to the value of the parameter schedulingInfoSIB1 configured by higher-layers

– otherwise

– read the 4-bit "modulation and coding scheme" field () in the DCI and set .

and second,

– if NPDSCH carries SystemInformationBlockType1-NB

– use subclause 16.4.1.5.2 for determining its transport block size.

– otherwise,

– read the 3-bit "resource assignment" field () in the DCI and determine its TBS by the procedure in subclause 16.4.1.5.1.

The NDI as signalled on NPDCCH, and the TBS, as determined above, shall be delivered to higher layers.

[TS 36.213, clause 16.4.1.5.1]

The TBS is given by the (,) entry of Table 16.4.1.5.1-1. For the value of the higher layer parameter operationModeInfo set to ‘00’ or ‘01’, .

Table 16.4.1.5.1-1: Transport block size (TBS) table


	0	1	2	3	4	5	6	7
0	16	32	56	88	120	152	208	256
1	24	56	88	144	176	208	256	344
2	32	72	144	176	208	256	328	424
3	40	104	176	208	256	328	440	568
4	56	120	208	256	328	408	552	680
5	72	144	224	328	424	504	680
6	88	176	256	392	504	600
7	104	224	328	472	584	680
8	120	256	392	536	680
9	136	296	456	616
10	144	328	504	680
11	176	376	584
12	208	440	680

[TS 36.213, clause 16.5.1.1]

The resource allocation information in uplink DCI format N0 for NPUSCH transmission indicates to a scheduled UE

a set of contiguously allocated subcarriers () of a resource unit determined by the Subcarrier indication field in the corresponding DCI,
a number of resource units () determined by the resource assignment field in the corresponding DCI according to Table 16.5.1.1-2,
a repetition number () determined by the repetition number field in the corresponding DCI according to Table 16.5.1.1-3.

The subcarrier spacing of NPUSCH transmission is determined by the uplink subcarrier spacing field in the Narrowband Random Access Response Grant according to subclause 16.3.3.

For NPUSCH transmission with subcarrier spacing, where is the subcarrier indication field in the DCI. is reserved.

For NPUSCH transmission with subcarrier spacing, the subcarrier indication field () in the DCI determines the set of contiguously allocated subcarriers () according to Table 16.5.1.1-1.

Table 16.5.1.1-1: Allocated subcarriers for NPUSCH with

Subcarrier indication field ()	Set of Allocated subcarriers ()
0 – 11
12-15
16-17
18
19-63	Reserved

Table 16.5.1.1-2: Number of resource units () for NPUSCH


0	1
1	2
2	3
3	4
4	5
5	6
6	8
7	10

Table 16.5.1.1-3: Number of repetitions () for NPUSCH.


0	1
1	2
2	4
3	8
4	16
5	32
6	64
7	128

[TS 36.213, clause 16.5.1.2]

To determine the modulation order, redundancy version and transport block size for the NPUSCH, the UE shall first

– read the “modulation and coding scheme” field () in the DCI, and

– read the “redundancy version” field () in the DCI, and

– read the "resource assignment" field () in the DCI, and

– compute the total number of allocated subcarriers (), number of resource units (), and repetition number () according to subclause 16.5.1.1.

The UE shall use modulation order, = 2 if . The UE shall useand Table 16.5.1.2-1 to determine the modulation order to use for NPUSCH if .

Table 16.5.1.2-1: Modulation and TBS index table for NPUSCH with

MCS Index	Modulation Order	TBS Index
0	1	0
1	1	2
2	2	1
3	2	3
4	2	4
5	2	5
6	2	6
7	2	7
8	2	8
9	2	9
10	2	10

NPUSCH is transmitted in N consecutive NB-IoT UL slots, n_i , i=0,1,…,N-1. The redundancy version of the NPUSCH transmission in j^t^h block of B consecutive NB-IoT UL slots n_i , is determined by, , where if , otherwise. Portion of NPUSCH codeword with as defined in clause 6.3.2 in [4] mapped to slot of allocated resource unit(s) is transmitted in NB-IoT UL slots n_i. for and for .

The UE shall use (,) and Table 16.5.1.2-2 to determine the TBS to use for the NPUSCH. is given in Table 16.5.1.2.1-1 if , otherwise.

Table 16.5.1.2-2: Transport block size (TBS) table for NPUSCH


	0	1	2	3	4	5	6	7
0	16	32	56	88	120	152	208	256
1	24	56	88	144	176	208	256	344
2	32	72	144	176	208	256	328	424
3	40	104	176	208	256	328	440	568
4	56	120	208	256	328	408	552	680
5	72	144	224	328	424	504	680	872
6	88	176	256	392	504	600	808	1000
7	104	224	328	472	584	712	1000
8	120	256	392	536	680	808
9	136	296	456	616	776	936
10	144	328	504	680	872	1000
11	176	376	584	776	1000
12	208	440	680	1000

Table 16.4.1.5.1-1: Transport block size (TBS) table


	0	1	2	3	4	5	6	7
0	16	32	56	88	120	152	208	256
1	24	56	88	144	176	208	256	344
2	32	72	144	176	208	256	328	424
3	40	104	176	208	256	328	440	568
4	56	120	208	256	328	408	552	680
5	72	144	224	328	424	504	680
6	88	176	256	392	504	600
7	104	224	328	472	584	680
8	120	256	392	536	680
9	136	296	456	616
10	144	328	504	680
11	176	376	584
12	208	440	680

The NDI as signalled on NPDCCH, and the RV and TBS, as determined above, shall be delivered to higher layers.

22.3.1.6.3 Test description

22.3.1.6.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

– MasterInformationBlock-NB / MasterInformationBlock-TDD-NB using parameters as specified in TS 36.508 [18] Table 8.1.4.3.2-1 with condition "Standalone"
NOTE: According to TS 36.213 [30] clause 16.4.1.5.1 for Inband Operation Mode I_TBS is restricted to 0 ≤ I_TBS ≤ 10 i.e. I_SF/I_MCS combinations with I_MCS = 11, 12 could not be tested

UE:

None.

Preamble:

– UE is in state NB-IoT UE Attach, Connected Mode, UE Test Loopback Activated (State 2B-NB) with test loop mode G and according to [18] in Ncell 1.

22.3.1.6.3.2 Test procedure sequence

Table 22.3.1.6.3.2-1: RLC SDU size used as test data

TBS_UL

[bits]

UL RLC SDU size

[bits]

56 < TB_size ≤1000 (Note)

TBS_UL– 56 (Note)

Note: UL MAC PDU contains 2 MAC SDUs (RLC STATUS PDU, RLC AMD PDU with a single RLC SDU):
2 bytes R/R/E/LCID/L header for 1st MAC SDU
1 byte R/R/E/LCID header for 2nd MAC SDU
2 bytes RLC STATUS PDU
2 bytes RLC AMD header
N bytes UL RLC SDU

⇒ N = (TBS_UL – 56) / 8

Table 22.3.1.6.3.2-2: TB sizes and I_SF/I_TBS combinations used for UL and DL

	DL			UL
S.No	I_SF	I_MCS = I_TBS	TBS_DL	I_RU	I_MCS/ I_TBS	TBS_UL
1	0	0	16	0	0/0	16
2	0	1	24	0	2/1	24
3	0	2	32	0	1/2	32
4	0	3	40	0	3/3	40
5	0	4	56	0	4/4	56
6	0	5	72	0	5/5	72
7	0	6	88	0	6/6	88
8	0	7	104	0	7/7	104
9	0	8	120	0	8/8	120
10	0	9	136	0	9/9	136
11	0	10	144	0	10/10	144
12	0	11	176	0	10/10	144
13	0	12	208	0	10/10	144
14	1	0	32	1	0/0	32
15	1	1	56	1	2/1	56
16	1	2	72	1	1/2	72
17	1	3	104	1	3/3	104
18	1	4	120	1	4/4	120
19	1	5	144	1	5/5	144
20	1	6	176	1	6/6	176
21	1	7	224	1	7/7	224
22	1	8	256	1	8/8	256
23	1	9	296	1	9/9	296
24	1	10	328	1	10/10	328
25	1	11	376	1	10/10	328
26	1	12	440	1	10/10	328
27	2	0	56	2	0/0	56
28	2	1	88	2	2/1	88
29	2	2	144	2	1/2	144
30	2	3	176	2	3/3	176
31	2	4	208	2	4/4	208
32	2	5	224	2	5/5	224
33	2	6	256	2	6/6	256
34	2	7	328	2	7/7	328
35	2	8	392	2	8/8	392
36	2	9	456	2	9/9	456
37	2	10	504	2	10/10	504
38	2	11	584	2	10/10	504
39	2	12	680	2	10/10	504
40	3	0	88	3	0/0	88
41	3	1	144	3	2/1	144
42	3	2	176	3	1/2	176
43	3	3	208	3	3/3	208
44	3	4	256	3	4/4	256
45	3	5	328	3	5/5	328
46	3	6	392	3	6/6	392
47	3	7	472	3	7/7	472
48	3	8	536	3	8/8	536
49	3	9	616	3	9/9	616
50	3	10	680	3	10/10	680
51	4	0	120	4	0/0	120
52	4	1	176	4	2/1	176
53	4	2	208	4	1/2	208
54	4	3	256	4	3/3	256
55	4	4	328	4	4/4	328
56	4	5	424	4	5/5	424
57	4	6	504	4	6/6	504
58	4	7	584	4	7/7	584
59	4	8	680	4	8/8	680
60	4	8	680	4	9/9	776
61	4	8	680	4	10/10	872
62	5	0	152	5	0/0	152
63	5	1	208	5	2/1	208
64	5	2	256	5	1/2	256
65	5	3	328	5	3/3	328
66	5	4	408	5	4/4	408
67	5	5	504	5	5/5	504
68	5	6	600	5	6/6	600
69	5	7	680	5	7/7	712
70	5	7	680	5	8/8	808
71	5	7	680	5	9/9	936
72	5	7	680	5	10/10	1000
73	6	0	208	6	0/0	208
74	6	1	256	6	2/1	256
75	6	2	328	6	1/2	328
76	6	3	440	6	3/3	440
77	6	4	552	6	4/4	552
78	6	5	680	6	5/5	680
79	6	5	680	6	6/6	808
80	6	5	680	6	7/7	1000
81	7	0	256	7	0/0	256
82	7	1	344	7	2/1	344
83	7	2	424	7	1/2	424
84	7	3	568	7	3/3	568
85	7	4	680	7	4/4	680
86	7	4	680	7	5/5	872
87	7	4	680	7	6/6	1000

Table 22.3.1.6.3.2-3: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Void.	–	–	–	–
–	EXCEPTION: Steps 1 to 8 are repeated as per table 22.3.1.6.3.2-2 with values of I_SF,DL I_MCS,I_RU and ULI_MCS	–	–	–	–
2	SS looks up for TBS_ULin table 22.3.1.6.3.2-1 as per the execution counter	–	–	–	–
–	EXCEPTION: Steps 3 to 6 are performed for TBS_UL>56	–	–	–	–
3	SS creates one UL RLC SDU of size TBS_UL, embeds it in an ESM DATA TRANSPORT and DLInformationTransfer-NB and splits the resulting DL RLC SDU into three RLC AMD PDUs ( if TBSDL < 100 bits ) or two equal sized RLC AMD PDUs ( if TBSDL > 100 bits ) (NOTE 1)	–	–	–	–
3A	SS gets current timing and NPDCCH period N is the next NPDCCH period which can be used by the SS for a DL transmission	–	–	–	–
4	At NPDCCH period N+1 the SS sends a DCI format N1 and a MAC PDU containing an RLC AMD PDU with polling field ‘P’ set to ‘0’ and containing the 1^st AMD PDU of the RLC SDU created at step 3.	<–	DCI N1 format with I_SF,DL I_MCS MAC PDU with 1^st AMD PDU of the DL RLC SDU	–	–
4A	IF TBS_DL < 100 bits At NPDCCH period N+2 the SS sends a DCI format N1 and a MAC PDU containing an RLC AMD PDU with polling field ‘P’ set to ‘0’ and containing the 2^nd AMD PDU of the RLC SDU created at step 3.	<–	DCI N1 format with I_SF,DL I_MCS MAC PDU with 2^nd AMD PDU of the DL RLC SDU	–	–
4B	At NPDCCH period N+i the SS sends a DCI format N1 and a MAC PDU containing an RLC AMD PDU with polling field ‘P’ set to ‘1’ and containing the last AMD PDU of the RLC SDU created at step 3. Where i=3 if TBS_DL < 100 bits, otherwise i=2. (NOTE 2)	<–	DCI N1 format with I_SF,DL I_MCS MAC PDU with last AMD PDU of the DL RLC SDU	–	–
5	In the NPDCCH period N+3 after the transmission at step 4B the SS allocates an uplink grant for the UL TBS according to 22.3.1.6.3.2-2	<–	(UL Grant) DCI N0 format with I_RU and ULI_MCS	–	–
6	CHECK: Does UE return an RLC SDU with the same content as created and embedded in the ESM DATA TRANSPORT at step 3 using the Resource unit Assignment and modulation and coding scheme as configured by the SS in step 5?	–>	MAC PDU containing RLC STATUS PDU and RLC AMD PDU with UL RLC SDU	1,2	P
7	The SS transmits an RLC STATUS PDU to acknowledge correctly received data	<–	RLC STATUS PDU	–	–
8	Void.			–	–
NOTE 1: DL RLC SDU with size n contains a DLInformationTransfer-NB with ESM_DATA_TRANSPORT:18 or 26 bits DLInformationTransfer-NB (PER encode: ‘0000000000’B + 8 bits ( length of DedicatedInfoNAS <= 127 bytes ) or 16 bits length ( 128 bytes <= length of DedicatedInfoNAS < 16383 bytes )) 1/2 byte Protocol discriminator ( SECURITY PROTECTED NAS MESSAGE ) 1/2 byte Security header type ( SECURITY PROTECTED NAS MESSAGE ) 4 bytes Message authentication code ( SECURITY PROTECTED NAS MESSAGE ) 1 byte Sequence number ( SECURITY PROTECTED NAS MESSAGE ) 1/2 byte Protocol discriminator ( ESM_DATA_TRANSPORT ) 1/2 byte EPS bearer identity ( ESM_DATA_TRANSPORT ) 1 byte Procedure transaction identity ( ESM_DATA_TRANSPORT ) 1 byte ESM data transport message identity ( ESM_DATA_TRANSPORT ) 2 bytes length indicator of the user data container ( ESM_DATA_TRANSPORT ) N bytes User data container contents ( UL RLC SDU ) 6 bits Aligned bits ( PER encode ) n = N+14 or N+15 bytes DL RLC SDU ⇒ to achieve the maximum TBS in UL (1000 bits) the DL RLC SDU needs to be segmented NOTE 2: setting of the poll bit causes the UE to insert an RLC Status PDU in the UL message of step 6

22.3.1.6.3.3 Specific message contents

None.

22.3.1.6a NB-IoT / DL-SCH / UL-SCH transport block size selection / DCI format N1 / N0 / Category NB2

22.3.1.6a.1 Test Purpose (TP)

Same as 22.3.1.6.

22.3.1.6a.2 Conformance requirements