22.3.1 MAC

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

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, PCMAX, 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, PCMAX, 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: TA 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 NTA x where NTA = TA 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:

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

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

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.

[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

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 TA 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 40th 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 TA 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 56th 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 58th 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 88th 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 90th 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 (ISF=1, ITBS=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 (ISF=2, ITBS=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 (ISF=1, ITBS=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 (ISF=0, ITBS=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.

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

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 (ITBS=3, IRU=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 (ITBS=3, IRU=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 (ITBS=0, IRU=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 (ITBS=0, IRU=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 (ITBS=4, IRU=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.

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

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:

– 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, CQI/PMI/RI/PTI/CRI on PUCCH shall not be reported.

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 (Rmax * 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 

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

Rmax=64
(Note 1)

}

}

}

}

}

}

}

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

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, ni , i=0,1,…,N-1. The redundancy version of the NPUSCH transmission in jth block of B consecutive NB-IoT UL slots ni , 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 ni. 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 ITBS is restricted to 0 ≤ ITBS ≤ 10 i.e. ISF/IMCS combinations with IMCS = 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

TBSUL

[bits]

UL RLC SDU size

[bits]

56 < TBsize ≤1000 (Note)

TBSUL – 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 = (TBSUL – 56) / 8

Table 22.3.1.6.3.2-2: TB sizes and ISF/ITBS combinations used for UL and DL

DL

UL

S.No

ISF

IMCS = ITBS

TBSDL

IRU

IMCS / ITBS

TBSUL

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 ISF, DL IMCS, IRU and UL IMCS

2

SS looks up for TBSUL in table 22.3.1.6.3.2-1 as per the execution counter

EXCEPTION: Steps 3 to 6 are performed for TBSUL>56

3

SS creates one UL RLC SDU of size TBSUL, 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 1st AMD PDU of the RLC SDU created at step 3.

<–

DCI N1 format with ISF, DL IMCS

MAC PDU with 1st AMD PDU of the DL RLC SDU

4A

IF TBSDL < 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 2nd AMD PDU of the RLC SDU created at step 3.

<–

DCI N1 format with ISF, DL IMCS

MAC PDU with 2nd 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 TBSDL < 100 bits, otherwise i=2.

(NOTE 2)

<–

DCI N1 format with ISF, DL IMCS

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 IRU and UL IMCS

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

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]

– HARQ process number – 1 bit. This field can only be present if 2 HARQ processes are configured and the corresponding DCI format is mapped onto the UE specific search space given by the C-RNTI as defined 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, random access procedure initiated by a NPDCCH order, and notifying SC-MCCH change. The DCI corresponding to a NPDCCH order is carried by NPDCCH.

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

– If the format N1 CRC is scrambled by C-RNTI or RA-RNTI:

– 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

– Else if the format N1 CRC is scrambled by a G-RNTI:

– Information for SC-MCCH change notification – 2 bits as defined in section 5.8a of [6]

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.2 of [3]

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

– Carrier indication of NPRACH – 4 bits as defined in section 16.3.2 of [3]. This field is only present if ul-ConfigList is configured and the UE indicates the multiCarrier-NPRACH capability.

– 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]

– HARQ process number – 1 bit. This field can only be present if 2 HARQ processes are configured and the corresponding DCI format is mapped onto the UE specific search space given by the C-RNTI as defined in [3].

When the format N1 CRC is scrambled with a RA-RNTI or a G-RNTI, then the following fields among the fields above are reserved for RA-RNTI and not present for G-RNTI:

– New data indicator

– HARQ-ACK resource

If the number of information bits in format N1 is less than that of format N0 and the format N1 CRC is not scrambled by G-RNTI, 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. A UE indicating Category NB2 shall also indicate Category NB1.

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

Category NB2

2536

2536

6400

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

Category NB2

2536

2536

[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 carriers 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 carriers 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.

For a NPDCCH UE-specific search space, if the UE is configured with higher layer parameter twoHARQ-ProcessesConfig

– the NDI and HARQ process ID as signalled on NPDCCH, and the TBS, as determined above, shall be delivered to higher layers,

otherwise

– the NDI as signalled on NPDCCH, and the TBS, as determined above, shall be delivered to higher layers. HARQ process ID of 0 shall be assumed.

[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

872

6

88

176

256

392

504

600

808

1032

7

104

224

328

472

584

680

968

1224

8

120

256

392

536

680

808

1096

1352

9

136

296

456

616

776

936

1256

1544

10

144

328

504

680

872

1032

1384

1736

11

176

376

584

776

1000

1192

1608

2024

12

208

440

680

904

1128

1352

1800

2280

13

224

488

744

1032

1256

1544

2024

2536

[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, ni , i=0,1,…,N-1. The redundancy version of the NPUSCH transmission in jth block of B consecutive NB-IoT UL slots ni , 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 ni 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 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

1224

8

120

256

392

536

680

808

1096

1384

9

136

296

456

616

776

936

1256

1544

10

144

328

504

680

872

1000

1384

1736

11

176

376

584

776

1000

1192

1608

2024

12

208

440

680

1000

1128

1352

1800

2280

13

224

488

744

1032

1256

1544

2024

2536

For a NPDCCH UE-specific search space, if the UE is configured with higher layer parameter twoHARQ-ProcessesConfig

– the NDI and HARQ process ID as signalled on NPDCCH, and the RV and TBS, as determined above, shall be delivered to higher layers,

otherwise

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

22.3.1.6a.3 Test description

22.3.1.6a.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 ITBS is restricted to 0 ≤ ITBS ≤ 10 i.e. ISF/IMCS combinations with IMCS = 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.6a.3.2 Test procedure sequence

Table 22.3.1.6a.3.2-1: RLC SDU size used as test data

UE Category

TBSUL

[bits]

UL RLC SDU size

[bits]

Category NB2

56 < TBsize ≤2536 (Note)

TBSUL – 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 = (TBSUL – 56) / 8

Table 22.3.1.6a.3.2-2: TB sizes and ISF/ITBS combinations used for UL and DL for NB2

DL

UL

S.No

ISF

IMCS = ITBS

TBSDL

IRU

IMCS / ITBS

TBSUL

1

0

13

224

0

10/10

144

2

1

13

488

1

10/10

328

3

2

13

744

2

10/10

504

4

3

11

776

3

10/10

680

5

3

12

904

3

10/10

680

6

3

13

1032

3

10/10

680

7

4

9

776

4

8/8

680

8

4

10

872

4

9/9

776

9

4

11

1000

4

10/10

872

10

4

12

1128

4

10/10

872

11

4

13

1256

4

10/10

872

12

5

8

808

5

7/7

712

13

5

9

936

5

8/8

808

14

5

10

1032

5

9/9

936

15

5

11

1192

5

10/10

1000

16

5

12

1352

5

10/10

1000

17

5

13

1544

5

10/10

1000

18

6

6

808

6

5/5

680

19

6

7

968

6

6/6

808

20

6

8

1096

6

7/7

1000

21

6

9

1256

6

8/8

1096

22

6

10

1384

6

9/9

1256

23

6

11

1608

6

10/10

1384

24

6

12

1800

6

10/10

1384

25

6

13

2024

6

10/10

1384

26

7

5

872

7

4/4

680

27

7

6

1032

7

5/5

872

28

7

7

1224

7

6/6

1000

29

7

8

1352

7

7/7

1224

30

7

9

1544

7

8/8

1384

31

7

10

1736

7

9/9

1544

32

7

11

2024

7

10/10

1736

33

7

12

2280

7

10/10

1736

34

7

13

2536

7

10/10

1736

Table 22.3.1.6a.3.2-3: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

Steps 1 to 7 are repeated as per table 22.3.1.6a.3.2-2 with values of ISF, DL IMCS, IRU and UL IMCS

1

SS looks up for TBSUL in table 22.3.1.6a.3.2-1 as per the execution counter

2

SS creates one UL RLC SDU of size TBSUL, embeds it in an ESM DATA TRANSPORT and DLInformationTransfer-NB and puts the resulting DL RLC SDU into one RLC AMD PDU

(NOTE 1)

3

SS gets current timing and NPDCCH period M is the next NPDCCH period which can be used by the SS for a DL transmission.

4

At NPDCCH period M+1 the SS sends a DCI format N1 and a MAC PDU containing an RLC AMD PDU of the DL RLC SDU created at step 10 with polling field ‘P’ set to ‘1’.

( NOTE 2)

<–

DCI N1 format with ISF, DL IMCS

MAC PDU with AMD PDU of the DL RLC SDU

5

In the NPDCCH period M+3 after the transmission at step 4 the SS allocates an uplink grant for the UL TBS according to 22.3.1.6a.3.2-2.

<–

(UL Grant)

DCI N0 format with IRU and UL IMCS

6

CHECK: Does UE return an RLC SDU with the same content as created and embedded in the ESM DATA TRANSPORT at step 2 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

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.6a.3.3 Specific message contents

None.

22.3.1.7 NB-IoT / RACH Procedure / Contention free random access (CFRA)

22.3.1.7.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state and ra-CFRA-Config is configured and timeAlignmentTimer has expired }

ensure that {

when { SS sends NPDCCH order to the C-RNTI assigned to UE and ra-PreambleIndex signalled is not 000000 }

then { UE sends a prach preamble calculated by given ra-PreambleIndex in the NPDCCH Order and parameters in currently used PRACH resource }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state and ra-CFRA-Config is configured, has transmitted PRACH Preamble after reception of PDCCH order with ra-PreambleIndex not set to 000000 }

ensure that {

when { UE receives a Random Access response containing a RAPID corresponding to the UE in RA Response window }

then { UE considers the Random Access procedure successfully completed }

}

22.3.1.7.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.1.1, 5.1.2, 5.1.4; TS 36.312, clause 6.4.3.2.

[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, the Random Access procedure is performed on the anchor carrier or one of the non-anchor carriers for which PRACH resource has been configured in system information.

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]:

– for NB-IoT, the use of contention free random access ra-CFRA-Config.

[TS 36.321, clause 5.1.2]

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

– For BL UEs or UEs in enhanced coverage, select the PRACH resource set corresponding to the selected enhanced coverage level.

– If, except for NB-IoT, ra-PreambleIndex (Random Access Preamble) and ra-PRACH-MaskIndex (PRACH Mask Index) have been explicitly signalled and ra-PreambleIndex is not 000000:

– the Random Access Preamble and the PRACH Mask Index are those explicitly signalled;

– 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:

– if ra-CFRA-Config is configured:

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

– else:

– 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. A UE supporting multi-tone Msg3 shall only select the single-tone Msg3 Random Access Preambles group if there is no multi-tone Msg3 Random Access Preambles group.

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

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

[TS 36.321, clause 5.1.4]

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, and regardless of the prioritization of V2X sidelink communication described in subclause 5.14.1.2.2:

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

– if the SCell is configured with ul-Configuration-r14, ignore the received UL grant otherwise process the received UL grant value and indicate it to the lower layers;

– if, except for NB-IoT, 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 UE is an NB-IoT UE, ra-PreambleIndex was explicitly signalled and it was not 000000 (i.e., not selected by MAC) and ra-CFRA-Config is configured:

– consider the Random Access procedure successfully completed.

– the UL grant provided in the Random Access Response message is valid only for the configured carrier.

– else:

– if the Random Access Preamble was selected by the MAC entity; or

– if the UE is an NB-IoT UE, the ra-PreambleIndex was explicitly signalled and it was not 000000 and ra-CFRA-Config is not configured:

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

[TS 36.312, clause 6.4.3.2]

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

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

– If the format N1 CRC is scrambled by C-RNTI or RA-RNTI:

– 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

– Else if the format N1 CRC is scrambled by a G-RNTI:

– Information for SC-MCCH change notification – 2 bits as defined in section 5.8a of [6]

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.2 of [3]

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

– Carrier indication of NPRACH – 4 bits as defined in section 16.3.2 of [3]. This field is only present if ul-ConfigList is configured and the UE indicates the multiCarrier-NPRACH capability.

– 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]

– HARQ process number – 1 bit. This field can only be present if 2 HARQ processes are configured and the corresponding DCI format is mapped onto the UE specific search space given by the C-RNTI as defined in [3].

When the format N1 CRC is scrambled with a RA-RNTI or a G-RNTI, then the following fields among the fields above are reserved for RA-RNTI and not present for G-RNTI:

– New data indicator

– HARQ-ACK resource

If the number of information bits in format N1 is less than that of format N0 and the format N1 CRC is not scrambled by G-RNTI, zeros shall be appended to format N1 until the payload size equals that of format N0.

22.3.1.7.3 Test description

22.3.1.7.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

UE:

None.

Preamble:

– The UE shall be in Connected Mode State 2-NB according to TS 36.508 [18].

22.3.1.7.3.2 Test procedure sequence

Table 22.3.1.7.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS does not transmit Timing Advance command.

2

The SS waits for 3s (TA Timer expiry).

3

The SS transmits a NPDCCH order to C-RNTI assigned to the UE on NPDCCH

<–

NPDCCH order (sub-carrier index := 5)

4

Check: Does the UE transmit a preamble on NPRACH with RAPID corresponding to subcarrier index provided in step 3? (NOTE 1)

–>

NPRACH Preamble

1

P

5

The SS transmits a MAC PDU addressed to UE RA-RNTI, containing a matching RAPID.

<–

Random Access Response

6

Check: Does the test result of generic test procedure in TS 36.508 subclause 8.1.5A.8 indicate that the UE is in RRC_CONNECTED state?

2

P

NOTE 1: The Random Access Preamble is set to nprach-SubcarrierOffset + nprach-NumCBRA-StartSubcarriers + (ra-PreambleIndex modulo (nprach-NumSubcarriers – nprach-NumCBRA-StartSubcarriers)), i.e. RAPID = 12+8+(5mod(12-8)) = 21.

22.3.1.7.3.3 Specific message contents

Table 22.3.1.7.3.3-1: RadioResourceConfigCommonSIB-NB-DEFAULT in SystemInformationBlockType2-NB (preamble, Table 22.3.1.7.3.2-1)

Derivation Path: 36.508 Table 8.1.6.3-9

Information Element

Value/remark

Comment

Condition

RadioResourceConfigCommonSIB-NB-DEFAULT ::= SEQUENCE {

nprach-Config-v1330 ::= SEQUENCE {

nprach-ParametersList-v1330 ::= SEQUENCE {

{

nprach-NumCBRA-StartSubcarriers-r13

n8

}

}

nprach-Config-v1530

NPRACH-ConfigSIB-NB-v1530-DEFAULT

TDD

}

Table 22.3.1.7.3.3-2: RRCConnectionSetup-NB (preamble, Table 22.3.1.7.3.2-1)

Derivation path: 36.508 table 8.1.6.1-14

Information Element

Value/remark

Comment

Condition

RRCConnectionSetup-NB ::= SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE {

rrcConnectionSetup-r13 SEQUENCE {

radioResourceConfigDedicated-r13 SEQUENCE {

mac-MainConfig-r13 CHOICE {

explicitValue-r13 SEQUENCE {

timeAlignmentTimerDedicated-r13

sf10240

needs to be long enough to ensure time alignment timer does not time out before the end of testcase

ra-CFRA-Config-r14

true

}

}

}

}

}

}

22.3.1.8 NB-IoT / RACH Procedure / Non-anchor carrier

22.3.1.8.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_IDLE state and SystemInformationBlockType22-NB with IE nprach-ParametersList-r14 is broadcast }

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 numRepetitionsPerPreambleAttempt from Random Access Preambles group using the non-anchor NPRACH resource corresponding to enhanced coverage level 0}

}

22.3.1.8.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clauses 5.1.1.

[TS 36.321, clause 5.1.1]

– if the UE is an NB-IoT UE:

– the available set of PRACH resources supported in the Serving Cell on the anchor carrier, nprach-ParametersList, and on the non-anchor carriers, in ul-ConfigList.

– for EDT, the available set of PRACH resources associated with EDT on anchor carrier, nprach-ParametersList-EDT, and on the non-anchor carriers, in ul-ConfigList.

– 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 and nprach-NumCBRA-StartSubcarriers as specified in TS 36.211 [7, 10.1.6.1]. 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 anchor carrier PRACH resource present in nprach-ParametersList and zero or one PRACH resource for each non-anchor carrier signalled in ul-ConfigList.

– for EDT, each enhanced coverage level has zero or one anchor carrier PRACH resource present in nprach-ParametersList-EDT and zero or one PRACH resource for each non-anchor carrier signalled in ul-ConfigList.

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

– when multiple carriers provide PRACH resources for the same enhanced coverage level, the UE will randomly select one of them using the following selection probabilities:

– the selection probability of the anchor carrier PRACH resource for the given enhanced coverage level, nprach-ProbabilityAnchor, is given by the corresponding entry in nprach-ProbabilityAnchorList

– the selection probability is equal for all non-anchor carrier PRACH resources and the probability of selecting one PRACH resource on a given non-anchor carrier is (1- nprach-ProbabilityAnchor)/(number of non-anchor NPRACH resources)

22.3.1.8.3 Test description

22.3.1.8.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

NB-IoT Operation Mode set to standalone

– System information combination 6 as defined in TS 36.508[18] clause 8.1.4.3.1.1.

SystemInformationBlockType22-NB as specified in Table 22.3.1.8.3.3-1.

UE:

None.

Preamble:

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

22.3.1.8.3.2 Test procedure sequence

Table 22.3.1.8.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

0A

SS adjusts SystemInformationBlockType22-NB to indicate the NPRACH Probablity Anchor is set to zero and notifies the UE of change of System Information

<–

Paging-NB

0B

Wait for 90 seconds for UE to read updated SystemInformationBlockType22-NB

1

The SS transmits a Paging message including a matched identity.

<–

Paging-NB

2

Check: Does the UE transmit a preamble on NPRACH on non-anchor carrier in ul-ConfigList in SystemInformationBlockType22-NB?

–>

NPRACH Preamble

1

P

3

The SS transmits a MAC PDU addressed to UE RA-RNTI, containing a matching RAPID.

<–

Random Access Response

4

UE sends an RRCConnectionRequest-NB message?

–>

MAC PDU (RRCConnectionRequest-NB)

5

The SS transmits a valid MAC PDU containing “UE Contention Resolution Identity” MAC control element with matching “Contention Resolution Identity” and CCCH message (RRCConnectionSetup-NB containing configuration of UE-specific search space).

<–

MAC PDU (UE Contention Resolution Identity, RRCConnectionSetup-NB)

6

UE sends an RRCConnectionSetupComplete-NB message ?

–>

RRCConnectionSetupComplete-NB

22.3.1.8.3.3 Specific message contents

Table 22.3.1.8.3.3-1: SystemInformationBlockType22-NB (preamble)

Derivation Path: 36.508 Table 8.1.4.3.3-8

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType22-NB-r14 ::= SEQUENCE {

dl-ConfigList-r14 SEQUENCE (SIZE (1.. maxNonAnchorCarriers-NB-r14)) OF DL-ConfigCommon-NB-r14 SEQUENCE {

1 entry

DL-ConfigCommon-NB-r14[1] SEQUENCE {

dl-CarrierConfig-r14

DL-CarrierConfigCommon-NB-DEFAULT1

pcch-Config-r14 SEQUENCE {

npdcch-NumRepetitionPaging-r14

Not present

pagingWeight-r14

w1

}

}

}

ul-ConfigList-r14 SEQUENCE (SIZE (1.. maxNonAnchorCarriers-NB-r14)) OF UL-ConfigCommon-NB-r14 SEQUENCE {

1 entry

FDD

UL-ConfigCommon-NB-r14[1] SEQUENCE {

ul-CarrierFreq-r14

Uplink EARFCN for non-anchor carrier under test.

For Signalling test cases, see 36.508 clause 8.3.2.3. Use the anchor carrier EARFCN + 2.

nprach-ParametersList-r14 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-Parameters-NB-r14 SEQUENCE {

1 entry

nprach-Parameters-r14 SEQUENCE {

nprach-Periodicity-r14

ms640

nprach-StartTime-r14

ms8

nprach-SubcarrierOffset-r14

n12

nprach-NumSubcarriers-r14

n12

nprach-SubcarrierMSG3-RangeStart-r14

oneThird

npdcch-NumRepetitions-RA-r14

r16

npdcch-StartSF-CSS-RA-r14

v4

npdcch-Offset-RA-r14

zero

nprach-NumCBRA-StartSubcarriers-r14

n8

npdcch-CarrierIndex-r14

Not present

}

}

}

}

pagingWeightAnchor-r14

w1

nprach-ProbabilityAnchorList-r14 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-ProbabilityAnchor-NB-r14 SEQUENCE {

nprach-ProbabilityAnchor-r14

oneHalf

}

ul-ConfigList-r15 SEQUENCE (SIZE (1.. maxNonAnchorCarriers-NB-r14)) OF UL-ConfigCommonTDD-NB-r15 SEQUENCE {

1 entry

TDD

tdd-UL-DL-AlignmentOffset-r15

khz0

nprach-ParametersListTDD-r15 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-ParametersTDD-NB-r15 SEQUENCE {

1 entry

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

}

}

}

}

Table 22.3.1.8.3.3-2: DL-CarrierConfigCommon-NB-DEFAULT1

Derivation Path: 36.508 clause 8.1.6.3-1A

Information Element

Value/remark

Comment

Condition

DL-CarrierConfigCommon-NB -DEFAULT::= SEQUENCE {

dl-CarrierFreq-r14

Downlink EARFCN for non-anchor carrier under test.

For Signalling test cases, see 36.508 clause 8.3.2.3. Use the anchor carrier EARFCN + 2.

}

Table 22.3.1.8.3.3-3: SystemInformationBlockType22-NB (Step 0A)

Derivation Path: 22.3.1.8.3.3-1

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType22-NB-r14 ::= SEQUENCE {

nprach-ProbabilityAnchorList-r14 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-ProbabilityAnchor-NB-r14 SEQUENCE {

nprach-ProbabilityAnchor-r14

zero

}

}

22.3.1.9 NB-IoT / Correct HARQ process / 2 HARQ processes

22.3.1.9.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state and twoHARQ-ProcessesConfig configured }

ensure that {

when { the UE receives MAC PDUs for 2 HARQ processes and results in successful decode }

then { the UE transmits ACKs for the corresponding HARQ processes }

}

(2)

with { UE in E-UTRA RRC_CONNECTED state and twoHARQ-ProcessesConfig configured }

ensure that {

when { UE receives uplink grants on NPDCCH for 2 HARQ processes respectively }

then { UE transmits uplink MAC PDUs on the resources indicated by the UL grants addressed to the corresponding HARQ processes }

}

22.3.1.9.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clauses 5.3.2.1and clauses 5.4.2.1.

[TS 36.321, clause 5.3.2.1]

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

[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 or two UL HARQ processes.

22.3.1.9.3 Test description

22.3.1.9.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.9.3.2 Test procedure sequence

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

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

DL SQN n maps to SQN Y+n MOD 1024.

Table 22.3.1.9.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

EXCEPTION: Steps 1 to 6 run 2 times using process X for each iteration (X=0,1).

1

The SS transmits a MAC PDU containing a MAC SDU with a RLC SDU of 38 bytes in an AMD PDU with polling field ‘P’ set to ‘0’ on HARQ process X.

(NOTE 1)

<–

NPDCCH (DCI N1)

MAC PDU (R/R/E/LCID MAC sub-header (E=’0’, LCID= ‘0011’), 40 bytes MAC SDU)

(RLC SN=0)

2

Check: Does the UE send a HARQ ACK?

–>

HARQ ACK

1

P

3

The SS allocates an UL grant on HARQ process X, allowing the UE to return the RLC SDU as received in step 1.

<–

Uplink Grant

4

Check: Does the UE transmit a MAC PDU corresponding to UL grant in step 3?

–>

MAC PDU(RLC SN=0)

2

P

5

SS transmits an RLC STATUS PDU on HARQ process X to acknowledge correctly received data.

<–

MAC PDU (RLC STATUS PDU(RLC SN=1))

6

The UE sends HARQ ACK for the RLC STATUS PDU of step 5.

–>

HARQ ACK

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

22.3.1.9.3.3 Specific message contents

Table 22.3.1.9.3.3-1: RRCConnectionSetup-NB (preamble, Table 22.3.1.9.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 {

srb-ToAddModList-r13 SEQUENCE (SIZE (1)) OF SEQUENCE {

1 entry

SRB-ToAddMod-NB-r13 SEQUENCE {

rlc-Config-v1430 SEQUENCE {

t-Reordering-r14

ms1600-v1310

}

}

}

physicalConfigDedicated-r13 SEQUENCE {

twoHARQ-ProcessesConfig-r14

true

}

}

}

}

}

}

22.3.1.10 NB-IoT / RACH Procedure / Early contention resolution

22.3.1.10.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_IDLE state }

ensure that {

when { UE has sent a CCCH UL MAC PDU with earlyContentionResolution is set to TRUE and UE receive a PDCCH transmission addressed to its Temporary C-RNTI contains a UE Contention Resolution Identity MAC control element matches the 48 first bits of the CCCH SDU transmitted in Msg3}

then { UE considers this Contention Resolution successful }

}

22.3.1.10.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.300, clause 10.1.5.1; TS 36.321, clauses 5.1.5, TS 36.331, clauses 5.3.3.3.

[TS 36.300, clause 10.1.5.1]

Contention Resolution on DL:

– Early contention resolution shall be used i.e. eNB does not wait for NAS reply before resolving contention;

– For NB-IoT, for initial access, RRC connection resume procedure and RRC Connection Re-establishment procedure, eNB may transmit MAC PDU containing the UE contention resolution identity MAC control element without RRC response message;

NOTE: In Release 13, NB-IoT UEs do not support the MAC PDU containing the UE contention resolution identity MAC control element without RRC response message for initial access, RRC connection resume procedure and RRC Connection Re-establishment procedure.

– Not synchronised with message 3;

– HARQ is supported;

– Addressed to:

– The Temporary C-RNTI on PDCCH for initial access and after radio link failure;

– The C-RNTI on PDCCH for UE in RRC_CONNECTED.

– HARQ feedback is transmitted only by the UE which detects its own UE identity, as provided in message 3, echoed in the Contention Resolution message;

– For initial access, RRC Connection Re-establishment procedure and EDT for Control Plane CIoT EPS Optimizations, no segmentation is used (RLC-TM).

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

Once Msg3 is transmitted, the MAC entity shall:

– except for a BL UE or a UE in enhanced coverage, or an NB-IoT UE, start mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission;

– for a BL UE or a UE in enhanced coverage, or an NB-IoT UE, start mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission of the bundle in the subframe containing the last repetition of the corresponding PUSCH transmission;

– 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:

– the UL grant or DL assignment contained in the PDCCH transmission is valid only for the configured 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.

[TS 36.331, clause 5.3.3.3]

The UE shall set the contents of RRCConnectionRequest message as follows:

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

2> if the UE supports multi-tone transmission, include multiToneSupport;

2> if the UE supports multi-carrier operation, include multiCarrierSupport;

2> if the UE supports DL channel quality reporting and cqi-Reporting is present in SystemInformationBlockType2-NB:

3> set the cqi-NPDCCH to include the latest results of the downlink channel quality measurements of the serving cell as specified in TS 36.133 [16];

NOTE 2: The downlink channel quality measurements may use measurement period T1 or T2, as defined in TS 36.133 [16]. In case period T2 is used the RRC-MAC interactions are left to UE implementation.

2> set earlyContentionResolution to TRUE;

22.3.1.10.3 Test description

22.3.1.10.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.10.3.2 Test procedure sequence

Table 22.3.1.10.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS transmits a Paging message including a matched identity.

<–

Paging-NB

2

The UE transmit a preamble on NPRACH

–>

NPRACH Preamble

3

The SS transmits a MAC PDU addressed to UE RA-RNTI, containing a matching RAPID.

<–

Random Access Response

4

Check: Does UE send an RRCConnectionRequest-NB message with earlyContentionResolution set to TRUE?

–>

MAC PDU (RRCConnectionRequest-NB)

5

The SS transmits a valid MAC PDU containing “UE Contention Resolution Identity” MAC control element with matching “Contention Resolution Identity”.

<–

MAC PDU

(UE Contention Resolution Identity)

6

The SS transmits RRCConnectionSetup-NB message.

<–

MAC PDU

(RRCConnectionSetup-NB)

7

Check: Does UE send an RRCConnectionSetupComplete-NB message?

–>

RRCConnectionSetupComplete-NB

1

P

22.3.1.10.3.3 Specific message contents

Table 22.3.1.10.3.3-1: RRCConnectionRequest-NB (step 4, Table 22.3.1.10.3.2-1)

Derivation Path: 36.331 clause 8.1.6.1-10

Information Element

Value/remark

Comment

Condition

RRCConnectionRequest-NB ::= SEQUENCE {

criticalExtensions CHOICE {

rrcConnectionRequest-r13 SEQUENCE {

ue-Identity-r13

Any allowed value

earlyContentionResolution-r14

TRUE

}

}

}

22.3.1.11 NB-IoT / Scheduling Request / Without HARQ ACK

22.3.1.11.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_CONNECTED state and with sr-WithoutHARQ-ACK-Config configured }

ensure that {
when { PRACH resource for SR configured and UE has UL data available for transmission and UE has no UL-SCH resources available and sr-ProhibitTimer is not running }

then { the UE transmits a SR on one valid PRACH resource }

}

22.3.1.11.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.321, clause 5.4.4, TS 36.213, clauses 16.2.1.2.1, 16.5.3 and TS 36.331, clause 5.3.10.18.

[TS 36.321, clause 5.4.4]

The Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission.

When an SR is triggered, it shall be considered as pending until it is cancelled. All pending SR(s) shall be cancelled and sr-ProhibitTimer and ssr-ProhibitTimer shall be stopped when a MAC PDU is assembled and this PDU includes a BSR which contains buffer status up to (and including) the last event that triggered a BSR (see clause 5.4.5), or, if all pending SR(s) are triggered by Sidelink BSR, when a MAC PDU is assembled and this PDU includes a Sidelink BSR which contains buffer status up to (and including) the last event that triggered a Sidelink BSR (see clause 5.14.1.4), or, if all pending SR(s) are triggered by Sidelink BSR, when upper layers configure autonomous resource selection, or when the UL grant(s) can accommodate all pending data available for transmission.

As long as one SR is pending, the MAC entity shall for each TTI:

– if no UL-SCH resources are available for a transmission in this TTI:

– For NB-IoT:

– if the MAC entity has no valid resource for SR together with acknowledgement of the data in this TTI and no valid PRACH resource for SR configured in any TTI:

– initiate a Random Access Procedure (see clause 5.1), and cancel all pending SRs in the first subframe containing PRACH for preamble transmission.

– else:

– if the MAC entity has valid resource for SR together with acknowledgement of the data in this TTI:

– instruct the physical layer to signal the SR together with acknowledgement of the data;

– cancel, if any, initiated Random Access Procedure for SR.

– else:

– if the MAC entity has valid PRACH resource for SR configured in this TTI and sr-ProhibitTimer is not running:

– instruct the physical layer to signal the SR on one valid PRACH resource for SR.

– start the sr-ProhibitTimer in the subframe containing the last repetition of the corresponding SR transmission.

[TS 36.213, clauses 16.2.1.2.1]

If the UE is configured with higher layer parameter sr-WithoutHARQ-ACK-Config, the setting of the UE transmit power for SR transmission without HARQ-ACK is defined as follows.

The UE transmit power for SR transmission in NB-IoT UL slot i for the serving cell is given by:

[dBm]

where,

is the configured UE transmit power defined in [6] in NB-IoT UL slot i for serving cell .

is {1/3} for NPRACH format 2 and {1}for NPRACH format 0/1.

is signalled from higher layers for serving cell .

is signalled from higher layers for serving cell .

is defined in Subclause 16.2.1.1.1.

[TS 36.213, clause 16.5.3]

If the UE is configured with higher layer parameter sr-WithoutHARQ-ACK-Config, the UE is configured with Narrowband Random access channel parameters (NPRACH configuration) for SR transmission by higher layers.

The UE shall, if requested by higher layers for transmitting SR, start transmission of a narrowband random access preamble on the NB-IoT carrier configured in sr-NPRACH-Resource at the next available NPRACH resource, unless the transmission would overlap with any subframe(s) of NPDSCH reception. The narrowband preamble is transmitted on the allocated subcarrier and a number of NPRACH repetitions for the associated NPRACH repetition level as indicated by higher layers. The narrowband random access preamble is transmitted with transmission power as determined in subclause 16.2.1.2, commencing on the indicated NPRACH resource.

[TS 36.331, clause 5.3.10.18]

The UE shall:

1> apply sr-WithHARQ-ACK-Config, if included;

1> apply sr-WithoutHARQ-ACK-Config, if included;

1> apply sr-SPS-BSR-Config, if included;

22.3.1.11.3 Test description

22.3.1.11.3.1 Pre-test conditions

System Simulator:

– Ncell 1

UE:

None.

Preamble:

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

22.3.1.11.3.2 Test procedure sequence

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

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

DL SQN n maps to SQN Y+n MOD 1024

Table 22.3.1.11.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

The SS does not allocate any uplink grant and has a valid PRACH resource for SR.

1

The SS transmits a MAC PDU containing RLC PDU with polling field ‘P’ set to ‘0’ and a RLC SDU.

<–

MAC PDU(RLC SN=0)

2

Check: Does the UE transmit a scheduling request by using configured narrowband random access preamble on NPRACH?

–>

SR

1

P

3

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

4

UE transmits a MAC PDU containing a RLC SDU.

–>

MAC PDU(RLC SN=0)

22.3.1.11.3.3 Specific message contents

Table 22.3.1.11.3.3-1: RadioResourceConfigDedicated-NB-SRB in RRCConnectionSetup-NB (preamble)

Derivation Path: 36.508 Table 8.1.6.3-10

Information Element

Value/remark

Comment

Condition

RadioResourceConfigDedicated-NB-SRB ::= SEQUENCE {

schedulingRequestConfig-r15

SchedulingRequestConfig-NB-r15

}

Table 22.3.1.11.3.3-2: SchedulingRequestConfig-NB-r15 (Table 22.3.1.11.3.3-1)

Derivation Path: 36.331 clause 6.7.3.2

Information Element

Value/remark

Comment

Condition

SchedulingRequestConfig-NB-r15 CHOICE {

sr-WithoutHARQ-ACK-Config-r15 CHOICE {

setup ::= SEQUENCE {

sr-ProhibitTimer-r15

2

sr-NPRACH-Resource-r15 ::= SEQUENCE {

nprach-CarrierIndex-r15

0

nprach-ResourceIndex-r15

1

nprach-SubCarrierIndex-r15 CHOICE {

nprach-Fmt0Fmt1-r15

26

}

p0-SR-r15

0

alpha-r15

al0

}

}

}

}

22.3.1.12 NB-IoT / RACH Procedure / Non-anchor carrier / Preamble format 2

22.3.1.12.1 Test Purpose (TP)

(1)

with { UE in E-UTRA RRC_IDLE state and SystemInformationBlockType23-NB with IE nprach-ParametersListFmt2-r15 is broadcast }

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 numRepetitionsPerPreambleAttempt from Random Access Preambles group using the non-anchor NPRACH resource corresponding to enhanced coverage level 0}

}

22.3.1.12.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clauses 5.1.1 and TS 36.331, clauses 5.2.2.4.

[TS 36.321, clause 5.1.1]

– if the UE is an NB-IoT UE:

– the available set of PRACH resources supported in the Serving Cell on the anchor carrier, nprach-ParametersList, and on the non-anchor carriers, in ul-ConfigList.

– for EDT, the available set of PRACH resources associated with EDT on anchor carrier, nprach-ParametersList-EDT, and on the non-anchor carriers, in ul-ConfigList.

– 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 and nprach-NumCBRA-StartSubcarriers as specified in TS 36.211 [7, 10.1.6.1]. 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 anchor carrier PRACH resource present in nprach-ParametersList and zero or one PRACH resource for each non-anchor carrier signalled in ul-ConfigList.

– for EDT, each enhanced coverage level has zero or one anchor carrier PRACH resource present in nprach-ParametersList-EDT and zero or one PRACH resource for each non-anchor carrier signalled in ul-ConfigList.

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

– when multiple carriers provide PRACH resources for the same enhanced coverage level, the UE will randomly select one of them using the following selection probabilities:

– the selection probability of the anchor carrier PRACH resource for the given enhanced coverage level, nprach-ProbabilityAnchor, is given by the corresponding entry in nprach-ProbabilityAnchorList

– the selection probability is equal for all non-anchor carrier PRACH resources and the probability of selecting one PRACH resource on a given non-anchor carrier is (1- nprach-ProbabilityAnchor)/(number of non-anchor NPRACH resources)

[TS 36.331, clauses 5.2.2.4]

1> if the NB-IoT UE supports NPRACH resources using preamble format 2:

2> if schedulingInfoList indicates that SystemInformationBlockType23-NB is present and the UE does not have stored a valid version of this system information block:

3> acquire SystemInformationBlockType23-NB;

22.3.1.12.3 Test description

22.3.1.12.3.1 Pre-test conditions

System Simulator:

– Ncell 1.

NB-IoT Operation Mode set to standalone.

– System information combination 7 as defined in TS 36.508[18] clause 8.1.4.3.1.1.

SystemInformationBlockType2-NB as specified in Table 22.3.1.12.3.3-1 and SystemInformationBlockType22-NB as specified in Table 22.3.1.12.3.3-3.

UE:

None.

Preamble:

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

22.3.1.12.3.2 Test procedure sequence

Table 22.3.1.12.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

SS adjusts SystemInformationBlockType22-NB to indicate the NPRACH Probability Anchor is set to zero and notifies the UE of change of System Information.

<–

Paging-NB

2

Wait for 90 seconds for UE to read updated SystemInformationBlockType22-NB

3

The SS transmits a Paging message including a matched identity.

<–

Paging-NB

4

Check: Does the UE transmit a preamble on NPRACH on non-anchor carrier in ul-ConfigList-v1530 in SystemInformationBlockType23-NB?

–>

NPRACH Preamble

1

P

5

The SS transmits a MAC PDU addressed to UE RA-RNTI, containing a matching RAPID.

<–

Random Access Response

6

UE sends an RRCConnectionRequest-NB message.

–>

MAC PDU (RRCConnectionRequest-NB)

7

The SS transmits a valid MAC PDU containing “UE Contention Resolution Identity” MAC control element with matching “Contention Resolution Identity” and CCCH message (RRCConnectionSetup-NB containing configuration of UE-specific search space).

<–

MAC PDU (UE Contention Resolution Identity, RRCConnectionSetup-NB)

8

UE sends an RRCConnectionSetupComplete-NB message.

–>

RRCConnectionSetupComplete-NB

22.3.1.12.3.3 Specific message contents

Table 22.3.1.12.3.3-1: SystemInformationBlockType2-NB (preamble)

Derivation Path: 36.508 Table 8.1.4.3.3-1

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType2-NB-r13 ::= SEQUENCE {

radioResourceConfigCommon-r13 SEQUENCE {}

RadioResourceConfigCommonSIB-NB-DEFAULT

See table 22.3.1.12.3.3-2

}

Table 22.3.1.12.3.3-2: RadioResourceConfigCommonSIB-NB-DEFAULT (preamble)

Derivation Path: 36.508 Table 8.1.6.3-9

Information Element

Value/remark

Comment

Condition

RadioResourceConfigCommonSIB-NB-DEFAULT ::= SEQUENCE {

nprach-Config-v1530 SEQUENCE {

tdd-Parameters-r15

Not present

fmt2-Parameters-r15 SEQUENCE {

nprach-ParametersListFmt2-r15 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-ParametersFmt2-NB-r15 SEQUENCE {

1 entry

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

npdcch-CarrierIndex-r15

Not present

}

}

nprach-ParametersListFmt2EDT-r15

Not present

}

edt-Parameters-r15

Not present

}

nprach-Config-v1550

Not present

}

Table 22.3.1.12.3.3-3: SystemInformationBlockType22-NB (preamble)

Derivation Path: 36.508 Table 8.1.4.3.3-8

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType22-NB-r14 ::= SEQUENCE {

dl-ConfigList-r14 SEQUENCE (SIZE (1.. maxNonAnchorCarriers-NB-r14)) OF DL-ConfigCommon-NB-r14 SEQUENCE {

1 entry

DL-ConfigCommon-NB-r14[1] SEQUENCE {

dl-CarrierConfig-r14

DL-CarrierConfigCommon-NB-DEFAULT1

pcch-Config-r14 SEQUENCE {

npdcch-NumRepetitionPaging-r14

Not present

pagingWeight-r14

w1

}

}

}

ul-ConfigList-r14 SEQUENCE (SIZE (1.. maxNonAnchorCarriers-NB-r14)) OF UL-ConfigCommon-NB-r14 SEQUENCE {

1 entry

UL-ConfigCommon-NB-r14[1] SEQUENCE {

ul-CarrierFreq-r14

Uplink EARFCN for non-anchor carrier under test.

For Signalling test cases, see 36.508 clauses 8.3.2.3. Use the anchor carrier EARFCN + 2.

nprach-ParametersList-r14 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-Parameters-NB-r14 SEQUENCE {

1 entry

nprach-Parameters-r14 SEQUENCE {

nprach-Periodicity-r14

ms640

nprach-StartTime-r14

ms8

nprach-SubcarrierOffset-r14

n12

nprach-NumSubcarriers-r14

n12

nprach-SubcarrierMSG3-RangeStart-r14

oneThird

npdcch-NumRepetitions-RA-r14

r16

npdcch-StartSF-CSS-RA-r14

v4

npdcch-Offset-RA-r14

zero

nprach-NumCBRA-StartSubcarriers-r14

n8

npdcch-CarrierIndex-r14

Not present

}

}

}

}

pagingWeightAnchor-r14

w1

nprach-ProbabilityAnchorList-r14 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-ProbabilityAnchor-NB-r14 SEQUENCE {

nprach-ProbabilityAnchor-r14

oneHalf

}

}

Table 22.3.1.12.3.3-4: DL-CarrierConfigCommon-NB-DEFAULT1

Derivation Path: 36.508 clause 8.1.6.3-1A

Information Element

Value/remark

Comment

Condition

DL-CarrierConfigCommon-NB -DEFAULT::= SEQUENCE {

dl-CarrierFreq-r14

Downlink EARFCN for non-anchor carrier under test.

For Signalling test cases, see 36.508 clauses 8.3.2.3. Use the anchor carrier EARFCN + 2.

}

Table 22.3.1.12.3.3-5: SystemInformationBlockType22-NB (Step 1)

Derivation Path: 22.3.1.12.3.3-3

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType22-NB-r14 ::= SEQUENCE {

nprach-ProbabilityAnchorList-r14 SEQUENCE (SIZE (1.. maxNPRACH-Resources-NB-r13)) OF NPRACH-ProbabilityAnchor-NB-r14 SEQUENCE {

nprach-ProbabilityAnchor-r14

zero

}

}