5 MAC procedures

36.3213GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Medium Access Control (MAC) protocol specificationRelease 17TS

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

5.1 Random Access procedure

5.1.1 Random Access Procedure initialization

The Random Access procedure described in this clause 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, as specified inTS 36.212 [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.

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, as specified in TS 36.331 [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 TS 36.211 [7].

– if Random Access Preambles group B exists, the thresholds, messagePowerOffsetGroupB and messageSizeGroupA, the configured UE transmitted power of the Serving Cell performing the Random Access Procedure, P_{CMAX, c}, as specified in TS 36.101 [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 clause 7.6).

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

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

NOTE 1: 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, as specified in TS 36.331 [8]:

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

– the available set of PRACH resources associated with each enhanced coverage level supported in the Serving Cell for the transmission of the Random Access Preamble, prach-ConfigIndex.

– for EDT, the available set of PRACH resources associated with EDT for each enhanced coverage level supported in the Serving Cell 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):

– except for EDT:

– if sizeOfRA-PreamblesGroupA is not equal to numberOfRA-Preambles:

– Random Access Preambles group A and B exist and are calculated as above;

– else:

– the preambles that are contained in Random Access Preamble groups for each enhanced coverage level, if it exists, are the preambles firstPreamble to lastPreamble.

– for EDT, the preambles that are contained in Random Access Preamble groups for each enhanced coverage level, if it exists, are the preambles firstPreamble to edt-LastPreamble if PRACH resources configured by edt-PRACH-ParametersCE are different from the PRACH resources configured by PRACH-ParametersCE for all enhanced coverage levels and edt-PRACH-ParametersCE for all other enhanced coverage levels, otherwise the preambles for EDT are the preambles lastPreamble+1 to edt-LastPreamble.

NOTE 2: When a PRACH resource is shared for multiple enhanced coverage levels, and enhanced coverage levels are differentiated by different preamble indices, Group A and Group B is not used for this PRACH resource.

– 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], clause 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)

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

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

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

– the configured UE transmitted power of the Serving Cell performing the Random Access Procedure, P_{CMAX, c}, as specified in TS 36.101 [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.

– for EDT, the Contention Resolution Timer mac-ContentionResolutionTimer configured for EDT (SpCell only) per enhanced coverage level supported in the Serving Cell.

– the power-ramping factor powerRampingStep and optionally powerRampingStepCE1.

– the maximum number of preamble transmission preambleTransMax-CE.

– the initial preamble power preambleInitialReceivedTargetPower and optionally preambleInitialReceivedTargetPowerCE1.

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

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

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 starting number of NPRACH 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 clause 5.1.2).

NOTE 3: 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.

NOTE 4: An NB-IoT UE measures RSRP on the anchor carrier.

5.1.2 Random Access Resource selection

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

– for BL UEs or UEs in enhanced coverage or NB-IoT UEs, if EDT is initiated by the upper layers:

– if the message size (UL data available for transmission plus MAC header and, where required, MAC control elements) is larger than the TB size signalled in edt-TBS for the selected enhanced coverage level for EDT; or

– if the PRACH resource associated with EDT for the selected enhanced coverage level is not available:

– indicate to upper layers that EDT is cancelled;

– for BL UEs or UEs in enhanced coverage, select the PRACH resource set corresponding to the selected enhanced coverage level. For EDT, the PRACH resource set shall correspond to the set associated with EDT for 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 if, for NB-IoT, 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:

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

– select the Random Access Preambles group corresponding to PRACH resource for EDT for the selected enhanced coverage level.

– else if the UE is a BL UE or UE in enhanced coverage and Random Access Preamble group B does not exist:

– select the Random Access Preambles group corresponding to the selected enhanced coverage level.

– else if the UE is an NB-IoT UE:

– if the UE supports carrier specific NRSRP thresholds for NPRACH resource selection and rsrp-ThresholdsPrachInfoList-r16 is signalled for a carrier in ul-ConfigList:

– if the measured RSRP is lower than the RSRP threshold corresponding to the selected enhanced coverage level in rsrp-ThresholdsPrachInfoList-r16:

– do not consider the PRACH resource on this non-anchor carrier for PRACH resource selection.

– randomly select one of the PRACH resources corresponding to the selected enhanced coverage level according to the configured probability distribution, and select the Random Access Preambles group corresponding 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. For EDT, the PRACH resource shall correspond to resource associated with EDT for the selected enhanced coverage level.

– else if Msg3 has not yet been transmitted, the MAC entity shall:

– if Random Access Preambles group B exists and any of the following events occur:

– the potential message size (UL data available for transmission plus MAC header and, where required, MAC control elements) is greater than messageSizeGroupA and the pathloss is less than P_CMAX,c(of the Serving Cell performing the Random Access Procedure) – preambleInitialReceivedTargetPower – deltaPreambleMsg3 – messagePowerOffsetGroupB;

– the Random Access procedure was initiated for the CCCH logical channel and the CCCH SDU size plus MAC header is greater than messageSizeGroupA;

– select the Random Access Preambles group B;

– else:

– select the Random Access Preambles group A.

– else, if Msg3 is being retransmitted, the MAC entity shall:

– select the same group of Random Access Preambles as was used for the preamble transmission attempt corresponding to the first transmission of Msg3.

– randomly select a Random Access Preamble within the selected group. The random function shall be such that each of the allowed selections can be chosen with equal probability;

– 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 clause 7.3), physical layer timing requirements, as specified in TS 36.213 [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);

– except for NB-IoT:

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

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

– randomly select, with equal probability, one PRACH from the PRACHs available in the determined subframe.

– else:

– randomly select, with equal probability, one PRACH from the PRACHs available in the determined subframe and the next two consecutive subframes.

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

5.1.3 Random Access Preamble transmission

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 the UE is an NB-IoT UE:

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

– for FDD if the UE supports enhanced random access power control and PowerRampingParameters-NB-v1450 is configured by upper layers, or for TDD:

– the MSG3_RECEIVED_TARGET_POWER is set to preambleInitialReceivedTargetPower + (PREAMBLE_TRANSMISSION_COUNTER_CE – 1) * powerRampingStep;

– for other enhanced coverage levels:

– for FDD if the UE supports enhanced random access power control and PowerRampingParameters-NB-v1450 is configured by upper layers, or for TDD; and

– if the starting enhanced coverage level was enhanced coverage level 0 or enhanced coverage level 1:

– if the MAC entity considers itself to be in enhanced coverage level 1 and if powerRampingStepCE1 and preambleInitialReceivedTargetPowerCE1 have been configured by upper layers:

– the PREAMBLE_RECEIVED_TARGET_POWER is set to preambleInitialReceivedTargetPowerCE1 + DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER_CE – 1) * powerRampingStepCE1 – 10 * log10(numRepetitionPerPreambleAttempt);

– the MSG3_RECEIVED_TARGET_POWER is set to preambleInitialReceivedTargetPowerCE1 + (PREAMBLE_TRANSMISSION_COUNTER_CE – 1) * powerRampingStepCE1;

– else:

– the PREAMBLE_RECEIVED_TARGET_POWER is set to preambleInitialReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER_CE – 1) * powerRampingStep – 10 * log10(numRepetitionPerPreambleAttempt);

– the MSG3_RECEIVED_TARGET_POWER is set to preambleInitialReceivedTargetPower + (PREAMBLE_TRANSMISSION_COUNTER_CE – 1) * powerRampingStep;

– else:

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

5.1.4 Random Access Response reception

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, and regardless of the prioritization of V2X sidelink communication described in clause 5.14.1.2.2, 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,as specified in TS 36.211 [7], plus three subframes and has length ra-ResponseWindowSize.

If the UE is a BL UE or a UE in enhanced coverage:

– if the random access preamble was transmitted in a non-terrestrial network:

– RA Response window starts at the subframe that contains the end of the last preamble repetition plus 3 + UE-eNB RTT subframes and has length ra-ResponseWindowSize for the corresponding enhanced coverage level;

– else:

– 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 enhanced coverage level.

If the UE is an NB-IoT UE:

– if the random access preamble was transmitted in a non-terrestrial network:

– RA Response window starts at the subframe that contains the end of the last preamble repetition plus X + UE-eNB RTT subframes and has length ra-ResponseWindowSize for the corresponding enhanced coverage level, where value X is determined from Table 5.1.4-1 based on the used preamble format and the number of NPRACH repetitions;

– else:

– RA Response window starts at the subframe that contains the end of the last preamble repetition plus X subframes and has length ra-ResponseWindowSize for the corresponding enhanced coverage level, where value X is determined from Table 5.1.4-1 based on the used preamble format and the number of NPRACH repetitions.

Table 5.1.4-1: Subframes between preamble transmission and RA Response Window in NB-IoT

TDD/FDD mode	Preamble format	Number of NPRACH repetitions	X
FDD	0 or 1	>= 64	41
FDD	0 or 1	< 64	4
FDD	2	>= 16	41
FDD	2	< 16	4
TDD	Any	Any	4

The RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI= 1 + t_id + 10*f_id

where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0≤ f_id< 6) except for NB-IoT UEs, BL UEs or UEs in enhanced coverage. If the PRACH resource is on a TDD carrier, the f_id is set to , where is defined in clause 5.7.1 of TS 36.211 [7].

For BL UEs and UEs in enhanced coverage, RA-RNTI associated with the PRACH in which the Random Access Preamble is transmitted, is computed as:

RA-RNTI=1+t_id + 10*f_id + 60*(SFN_id mod (Wmax/10))

where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0≤ f_id< 6), SFN_id is the index of the first radio frame of the specified PRACH, and Wmax is 400, maximum possible RAR window size in subframes for BL UEs or UEs in enhanced coverage. If the PRACH resource is on a TDD carrier, the f_id is set to , where is defined in clause 5.7.1 of TS 36.211 [7].

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) + 256*carrier_id

where SFN_id is the index of the first radio frame of the specified PRACH and carrier_id is the index of the UL carrier associated with the specified PRACH. The carrier_id of the anchor carrier is 0.

For NB-IoT UEs operating in TDD mode, 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) + 256*(H-SFN mod 2)

where SFN_id is the index of the first radio frame of the specified PRACH and H-SFN is the index of the first hyper frame of the specified PRACH. The PDCCH transmission and the PRACH resource are on the same carrier.

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 clause 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 clause 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 clause 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 (i.e. UL carrier used prior to this Random Access procedure).

– 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 the Random Access Preamble associated with EDT was transmitted and UL grant provided in the Random Access Response message is not for EDT:

– indicate to upper layers that EDT is cancelled due to UL grant not being for EDT;

– for CP-EDT, flush the Msg3 buffer.

– for UP-EDT, update the MAC PDU in the Msg3 buffer in accordance with the uplink grant received in the Random Access Response.

– if the Random Access Preamble associated with EDT was transmitted, the UL grant was received in a Random Access Response for EDT, and there is a MAC PDU in the Msg3 buffer:

– if the TB size according to edt-SmallTBS-Enabled and as described in clause 8.6.2 and 16.3.3 of TS 36.213 [2] does not match the size of the MAC PDU in the Msg3 buffer:

– the MAC entity shall update the MAC PDU in the Msg3 buffer in accordance with the TB size.

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

– if CP-EDT is cancelled due to the UL grant provided in the Random Access Response message not being for EDT:

– 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 1: 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 2: 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 behavior is not defined except for EDT.

If no Random Access Response or, for NB-IoT UEs, BL UEs or UEs in enhanced coverage for mode B operation, no PDCCH scheduling 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;

– else if the SCell where the Random Access Preamble was transmitted is configured with ul-Configuration-r14:

– delay the subsequent Random Access transmission until the Random Access Procedure is initiated by a PDCCH order with the same ra-PreambleIndex and ra-PRACH-MaskIndex;

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

– if the UE is an NB-IoT UE:

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

– select the PRACH resource in the list of UL carriers providing a PRACH resource for the selected enhanced coverage level for which the carrier index is equal to ((Carrier Indication from the PDCCH order) modulo (Number of PRACH resources in the selected enhanced coverage));

– consider the selected PRACH resource as explicitly signalled;

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

5.1.5 Contention Resolution

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:

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

– if Msg3 is transmitted on a non-terrestrial network:

– if, for EDT, edt-SmallTBS-Enabled is set to TRUE for the corresponding PRACH resource:

– start mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission of the bundle in the subframe corresponding to the last subframe of a PUSCH transmission corresponding to the largest TBS indicated by the UL grant plus UE-eNB RTT subframes.

– else:

– 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 plus UE-eNB RTT subframes.

– else:

– if, for EDT, edt-SmallTBS-Enabled is set to TRUE for the corresponding PRACH resource:

– else:

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

– the UL grant or DL assignment contained in the PDCCH transmission is valid only for the configured carrier (i.e. UL/DL carrier used prior to this Random Access procedure).

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

– for BL UEs or UEs in CE or NB-IoT UEs:

– if notification of a reception of a PDCCH transmission has been received from lower layers before mac-ContentionResolutionTimer expired; and

– if the MAC PDU received until the subframe that contains the last repetition of the corresponding PDSCH transmission is successfully decoded; and

– 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 if Msg3 was transmitted on a non-terrestrial network:

– if no notification of a reception of a PDCCH transmission addressed to the Temporary C-RNTI indicating an uplink grant for a Msg3 retransmission was received after the start of the mac-ContentionResolutionTimer:

– discard the Temporary C-RNTI;

– consider the Contention Resolution not successful.

– else:

– discard the Temporary C-RNTI;

– consider this Contention Resolution not successful.

– except for BL UEs or UEs in CE or NB-IoT UEs:

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

5.1.6 Completion of the Random Access procedure

At completion of the Random Access procedure, the MAC entity shall:

– discard explicitly signalled ra-PreambleIndex and ra-PRACH-MaskIndex, if any;

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

Upon successful completion of the Random Access procedure initiated for DAPS handover, the target MAC entity shall:

– indicate the successful completion of the Random Access Procedure to the upper layers.

In addition, the RN shall resume the suspended RN subframe configuration, if any.

5.2 Maintenance of Uplink Time Alignment

The MAC entity has a configurable timer timeAlignmentTimer per TAG. The timeAlignmentTimer is used to control how long the MAC entity considers the Serving Cells belonging to the associated TAG to be uplink time aligned, as specified in TS 36.331 [8].

The MAC entity shall:

– when a Timing Advance Command MAC control element is received and if a N_TA has been stored or maintained with the indicated TAG:

– except when the received Timing Advance Command MAC control element is addressed with a PUR-RNTI:

– apply the Timing Advance Command for the indicated TAG;

– start or restart the timeAlignmentTimer associated with the indicated TAG.

– when a Timing Advance Command is received in a Random Access Response message for a serving cell belonging to a TAG:

– if the UE is configured with pur-Config (see TS 36.331 [8]) and if a N_TA has been stored or maintained and no temporary N_TA has been stored:

– store current N_TA as temporary N_TA (see clause 5.4.7.2).

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

– apply the Timing Advance Command for this TAG;

– start or restart the timeAlignmentTimer associated with this TAG.

– else, if the timeAlignmentTimer associated with this TAG is not running:

– apply the Timing Advance Command for this TAG;

– start the timeAlignmentTimer associated with this TAG;

– when the contention resolution is considered not successful as described in clause 5.1.5, stop timeAlignmentTimer associated with this TAG.

– else:

– ignore the received Timing Advance Command.

– when the MAC entity is configured with rach-Skip or rach-SkipSCG:

– apply timing advance value indicated by targetTA in rach-Skip or rach-SkipSCG for the pTAG;

– start the timeAlignmentTimer associated with this TAG.

– when a timeAlignmentTimer expires:

– if the timeAlignmentTimer is associated with the pTAG:

– flush all HARQ buffers for all serving cells;

– notify RRC to release PUCCH/SPUCCH for all serving cells;

– notify RRC to release SRS for all serving cells;

– for NB-IoT, notify RRC to release all dedicated resources for SR;

– clear any configured downlink assignments and uplink grants;

– consider all running timeAlignmentTimers as expired;

– else if the timeAlignmentTimer is associated with an sTAG, then for all Serving Cells belonging to this TAG:

– flush all HARQ buffers;

– notify RRC to release SRS;

– notify RRC to release PUCCH/SPUCCH, if configured;

– clear any configured downlink assignments and uplink grants.

– upon indication from upper layers to start timeAlignmentTimer, if a N_TA has been stored or maintained with the indicated TAG:

– start or restart the timeAlignmentTimer associated with the indicated TAG.

When the MAC entity stops uplink transmissions for an SCell due to the fact that the maximum uplink transmission timing difference (as described in clause 7.9.2 of TS 36.133 [9]) or the maximum uplink transmission timing difference the UE can handle between TAGs of any MAC entity of the UE is exceeded, the MAC entity considers the timeAlignmentTimer associated with the SCell as expired.

The MAC entity shall not perform any uplink transmission on a Serving Cell, except the Random Access Preamble transmission and transmissions corresponding to a PUR-RNTI, when the timeAlignmentTimer associated with the TAG to which this Serving Cell belongs is not running. Furthermore, when the timeAlignmentTimer associated with the pTAG is not running, the MAC entity shall not perform any uplink transmission on any Serving Cell except the Random Access Preamble transmission on the SpCell.

The MAC entity shall not perform any sidelink transmission which is performed based on UL timing of the corresponding serving cell and any associated SCI transmissions when the corresponding timeAlignmentTimer is not running.

NOTE: A MAC entity stores or maintains N_TA upon expiry of associated timeAlignmentTimer, where N_TA is defined in TS 36.211 [7]. The MAC entity applies a received Timing Advance Command MAC control element and starts associated timeAlignmentTimer also when the timeAlignmentTimer is not running.

5.2a Maintenance of UL Synchronization

If upper layer informs that the UL synchronization is lost according to the clause 5.3.18 of TS 36.331 [8], the MAC entity shall:

– flush all HARQ buffers;

– not perform any uplink transmission.

If upper layer informs that the UL synchronization is restored for the SpCell according to the clause 5.3.18 of TS36.331 [8], uplink transmissions can be performed.

5.3 DL-SCH data transfer

5.3.1 DL Assignment reception

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, PUR-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, PUR-RNTI, or Temporary C‑RNTI:

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

– if this is the first downlink assignment corresponding to uplink transmission using previous preconfigured uplink grant for this PUR-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.

– else, if a downlink assignment for this TTI has been received for this Serving Cell on the PDCCH for the MAC entity’s Semi-Persistent Scheduling C-RNTI:

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

– consider the NDI not to have been toggled;

– indicate the presence of a downlink assignment and deliver 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 downlink assignment (if any);

– if the timeAlignmentTimer, associated with the TAG containing the serving cell on which the acknowledgement for the downlink SPS release is to be transmitted, is running:

– indicate a positive acknowledgement for the downlink SPS release to the physical layer.

– else:

– store the downlink assignment and the associated HARQ information as configured downlink assignment;

– initialise (if not active) or re-initialise (if already active) the configured downlink assignment to start in this TTI, or in TTI according to N=0 in clause 5.10.1 for short TTI, and to recur according to rules in clause 5.10.1;

– set the HARQ Process ID to the HARQ Process ID associated with this TTI;

– consider the NDI bit to have been toggled;

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

– else, if a downlink assignment for this TTI has been configured for this Serving Cell and there is no measurement gap in this TTI and there is no Sidelink Discovery Gap for Reception in this TTI; and

– if this TTI is not an MBSFN subframe or the MAC entity is configured with transmission mode tm9 or tm10:

– instruct the physical layer to receive, in this TTI, transport block on the DL-SCH according to the configured downlink assignment and to deliver it to the HARQ entity;

– set the HARQ Process ID to the HARQ Process ID associated with this TTI;

– consider the NDI bit to have been toggled;

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

– if the MAC entity is configured with rach-Skip or rach-SkipSCG and a UE Contention Resolution Identity MAC control element for this TTI has been received on the PDSCH indicated by the PDCCH of the SpCell addressed to the C-RNTI:

– indicate to upper layer the successful reception of a PDCCH transmission addressed to the C-RNTI.

For configured downlink assignments, the HARQ Process ID associated with this TTI is derived from the following equation:

– if the TTI is a subframe TTI:

– HARQ Process ID = [floor(CURRENT_TTI/semiPersistSchedIntervalDL)] modulo numberOfConfSPS-Processes,

where CURRENT_TTI=[(SFN * 10) + subframe number].

– else:

– HARQ Process ID = [floor(CURRENT_TTI/semiPersistSchedIntervalDL-sTTI)] modulo numberOfConfSPS-Processes-sTTI,

where CURRENT_TTI = [(SFN * 10 * sTTI_Number_Per_Subframe) + subframe number * sTTI_Number_Per_Subframe + sTTI_number]. Refer to 5.10.1 for sTTI_Number_Per_Subframe and sTTI_number.

For BL UEs or UEs in enhanced coverage, CURRENT_TTI refers to the TTI where first transmission of repetition bundle takes place.

When the MAC entity needs to read BCCH or BR-BCCH, the MAC entity may, based on the scheduling information from RRC:

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

– the redundancy version of the received downlink assignment for this TTI is determined by RV_K = ceiling(3/2*k) modulo 4, where k depends on the type of system information message.

– for SystemInformationBlockType1-BR

– if number of repetitions for PDSCH carrying SystemInformationBlockType1-BR is 4, k = floor(SFN/2) modulo 4, where SFN is the system frame number.

– else if number of repetitions for PDSCH carrying SystemInformationBlockType1-BR is 8, k = SFN modulo 4, where SFN is the system frame number.

– else if number of repetitions for PDSCH carrying SystemInformationBlockType1-BR is 16, k = (SFN*10+i) modulo 4, where SFN is the system frame number, and i denotes the subframe within the SFN.

NOTE: the set of subframes for SystemInformationBlockType1-BR when number of repetitions for PDSCH is 16 are given by Table 6.4.1-2 in TS 36.211 [7].

– for SystemInformation-BR messages, k=i modulo 4, i =0,1,…, n_s^w–1, where i denotes the subframe number within the SI window n_s^w;

– indicate a downlink assignment and redundancy version for the dedicated broadcast HARQ process to the HARQ entity for this TTI.

– else if a downlink assignment for this TTI has been received on the PDCCH for the SI-RNTI, except for NB-IoT;

– if the redundancy version is not defined in the PDCCH format:

– the redundancy version of the received downlink assignment for this TTI is determined by RV_K = ceiling(3/2*k) modulo 4, where k depends on the type of system information message: for SystemInformationBlockType1 message, k = (SFN/2) modulo 4, where SFN is the system frame number; for SystemInformation messages, k=i modulo 4, i =0,1,…, n_s^w–1, where i denotes the subframe number within the SI window n_s^w;

– indicate a downlink assignment and redundancy version for the dedicated broadcast HARQ process to the HARQ entity for this TTI.

When the MAC entity has SC-RNTI and/or G-RNTI, the MAC entity shall for each TTI during which it monitors PDCCH for SC-RNTI as specified in TS 36.331 [8] for UEs other than NB-IoT UEs, BL UEs or UEs in enhanced coverage and in clause 5.7a for NB-IoT UEs, BL UEs or UEs in enhanced coverage and for G-RNTI as specified in clause 5.7a and for each Serving Cell and cell that may be additionally configured as a Serving Cell according to the UE capabilities:

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

– attempt to decode the received data.

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

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

5.3.2 HARQ operation

5.3.2.1 HARQ Entity

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

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

When the physical layer is configured for downlink spatial multiplexing, as specified in TS 36.213 [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.

If the MAC entity is configured with blindSlotSubslotPDSCH-Repetitions or blindSubframePDSCH-Repetitions on a serving cell (TS 36.331 [8]), the parameter DL_REPETITION_NUMBER provides the number of transmissions repeated in a bundle for a downlink assignment received on that serving cell. For each bundle, DL_REPETITION_NUMBER and the redundancy version for each transmission within a bundle are set to values provided by lower layers. Within a bundle, after the initial (re-)transmission, DL_REPETITION_NUMBER-1 HARQ retransmissions follow. The HARQ feedback is sent only one time for the bundle and after the last transmission of the bundle.

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

The MAC entity shall:

– If a downlink assignment has been indicated for this TTI; or

– If this TTI is for a retransmission within a bundle:

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

5.3.2.2 HARQ process

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 clause 5.1.5); or

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

– if the HARQ process is not associated with a transmission indicated with a PUR-RNTI and 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 1: When the MAC entity is configured with more than one serving cell, UE behaviors for storing data to the soft buffer is specified in TS 36.213 [2].

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

5.3.3 Disassembly and demultiplexing

The MAC entity shall disassemble and demultiplex a MAC PDU as defined in clause 6.1.2.

5.4 UL-SCH data transfer

5.4.1 UL Grant reception

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 or preallocated by RRC or provided by RRC for transmission using PUR (see clause 5.4.7). 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, a UL Semi-Persistent Scheduling V-RNTI, a AUL 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 and for each SPS configuration that is indicated by the PDCCH addressed to UL Semi-Persistent Scheduling V-RNTI; or if the MAC entity has Preconfigured Uplink Resource RNTI, the MAC entity shall for each TTI 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, Preconfigured Uplink Resource 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, for the MAC entity’s UL Semi-Persistent Scheduling V-RNTI, or a configured uplink grant for which the UL HARQ operation was not autonomous:

– 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 an uplink grant for this TTI has been received for this Serving Cell on the PDCCH for the MAC entity’s Semi-Persistent Scheduling C-RNTI or for the MAC entity’s UL Semi-Persistent Scheduling V-RNTI; or if an uplink grant for this TTI has been received for this Serving Cell on the PDCCH for the MAC entity’s AUL 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 AUL release:

– trigger an AUL confirmation;

– if an uplink grant for this TTI has been configured:

– 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 PDCCH contents indicate AUL activation:

– trigger an AUL confirmation;

– 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 clause 5.23;

– 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 PDCCH contents indicate SPS release:

– if the MAC entity is configured with skipUplinkTxSPS:

– trigger an SPS confirmation;

– if an uplink grant for this TTI has been configured:

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

– clear the corresponding configured uplink grant (if any).

– else:

– if the MAC entity is configured with skipUplinkTxSPS:

– trigger an SPS confirmation;

– 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, or in TTI according to N=0 in clause 5.10.2 for short TTI, and to recur according to rules in clause 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 an uplink grant for this TTI has been configured for the Serving Cell and if UL HARQ operation is autonomous for the corresponding HARQ process:

– if the HARQ_FEEDBACK is set to ACK for the corresponding HARQ process or if there is no uplink grant previously delivered to the HARQ entity for the same HARQ process:

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

– if the aul-RetransmissionTimer is not running:

– if there is no uplink grant previously delivered to the HARQ entity for the same HARQ process; or

– if the previous uplink grant delivered to the HARQ entity for the same HARQ process was not an uplink grant received for the MAC entity’s C-RNTI; or

– if the HARQ_FEEDBACK is set to ACK for the corresponding HARQ process:

– 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 preallocated for the SpCell; or

– except for preconfigured uplink grant for PUR, if an uplink grant for this TTI has been configured for this Serving Cell:

– 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 or preallocated uplink grant, and the associated HARQ information to the HARQ entity for this TTI.

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

NOTE 2: 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 3: 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. When a configured uplink grant indicates an UL-SCH transmission during a V2X sidelink communication transmission and transmission of V2X sidelink communication is prioritized as described in clause 5.14.1.2.2, the MAC entity processes the grant but does not transmit on UL-SCH.

NOTE 4: The NDI transmitted in the PDCCH for the MAC entity’s AUL C-RNTI is set to ‘0’ (TS 36.212 [5]).

Except for NB-IoT, for configured uplink grants without harq-ProcID-offset, if UL HARQ operation is not autonomous, the HARQ Process ID associated with this TTI is derived from the following equation for asynchronous UL HARQ operation:

– if the TTI is a subframe TTI:

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

– else:

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

where CURRENT_TTI = [(SFN * 10 * sTTI_Number_Per_Subframe) + subframe number * sTTI_Number_Per_Subframe + sTTI_number] and it refers to the short TTI occasion where the first transmission of a bundle takes place. Refer to 5.10.2 for sTTI_Number_Per_Subframe and sTTI_number.

For preallocated 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/ul-SchedInterval)] modulo numberOfConfUL-Processes,

where CURRENT_TTI=subframe number and it refers to the subframe where the first transmission of a bundle takes place.

For configured uplink grants, if UL HARQ operation is autonomous, the HARQ Process ID associated with this TTI for transmission on this Serving Cell is selected by the UE implementation from the HARQ process IDs that are configured for autonomous UL HARQ operation by upper layers in aul-HARQ-Processes (TS 36.331 [8]).

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

– if the TTI is a subframe TTI:

– HARQ Process ID = [floor(CURRENT_TTI/semiPersistSchedIntervalUL)] modulo numberOfConfUlSPS-Processes + harq-ProcID-offset,

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

– else:

– HARQ Process ID = [floor(CURRENT_TTI/semiPersistSchedIntervalUL-sTTI)] modulo numberOfConfUlSPS-Processes-sTTI + harq-ProcID-offset,

If the MAC entity is configured with Short Processing Time or short TTI and if current_TTI is a subframe TTI, the HARQ Process ID associated with this TTI is derived from the following equation for synchronous UL HARQ operation:

HARQ Process ID = [SFN * number_of_UL_PUSCH_SFs_per_radio_frame + index_of_UL_PUSCH_SF] modulo number_of_UL_HARQ_processes.

where number_of_UL_PUSCH_SFs_per_radio_frame is the number of subframes that can be used for PUSCH (UL PUSCH subframe) per radio frame:

– For FDD serving cells and serving cells operating according to Frame structure Type 3, all 10 subframes in a radio frame represent UL PUSCH subframes;

– For TDD serving cells, all uplink subframes of the TDD UL/DL configuration indicated by tdd-Config, as specified in TS 36.331 [8] of the cell represent UL PUSCH subframes and additionally the subframes including UpPTS if the cell is configured with symPUSCH-UpPts-r14;

and index_of_UL_PUSCH_SF is the index of a subframe that can be used for PUSCH within the radio frame, and number_of_UL_HARQ_processes is the number of parallel HARQ processes per HARQ entity for subframe TTI as specified in TS 36.213 [2], clause 8.

5.4.2 HARQ operation

5.4.2.1 HARQ entity

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 TS 36.213 [2], clause 8. NB-IoT has one or two UL HARQ processes.

When the physical layer is configured for uplink spatial multiplexing, as specified in TS 36.213 [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 UE configured with a single HARQ process, each asynchronous HARQ process is associated with a HARQ process identifier. For UL transmission with UL grant in RAR and for transmission using PUR, HARQ process identifier 0 is used. HARQ feedback is not applicable for asynchronous UL HARQ except if mpdcch-UL-HARQ-ACK-FeedbackConfig is configured.

In autonomous HARQ operation, HARQ feedback is applicable.

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, in serving cells configured with pusch-EnhancementsConfig, serving cells operating according to Frame Structure Type 3, for HARQ processes scheduled using short TTI, for HARQ processes scheduled using Short Processing Time, and for HARQ processes associated with an SPS configuration with totalNumberPUSCH-SPS-STTI-UL-Repetitions or totalNumberPUSCH-SPS-UL-Repetitions except for the repetitions within a bundle.

For serving cells configured with pusch-EnhancementsConfig, 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 of the bundle is only received after the last repetiton of the bundle if mpdcch-UL-HARQ-ACK-FeedbackConfig is not configured. An uplink grant corresponding to a retransmission of the bundle is only received after the last repetition of the bundle. For UEs configured with mpdcch-UL-HARQ-ACK-FeedbackConfig, repetitions within a bundle are stopped if an UL HARQ-ACK feedback or an uplink grant corresponding to a new transmission of the bundle is received on PDCCH during the bundle transmission. A retransmission of a bundle is also a bundle.

For a SPS configuration with totalNumberPUSCH-SPS-STTI-UL-Repetitions or totalNumberPUSCH-SPS-UL-Repetitions (TS 36.331 [8]), the parameter totalNumberPUSCH-SPS-STTI-UL-Repetitions or totalNumberPUSCH-SPS-UL-Repetitions provides the number of transmission repetitions within a configured grant bundle. Bundling operation relies on the HARQ entity 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.

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 clause 5.1.5) TTI bundling does not apply. For UEs configured with pusch-EnhancementsConfig performing contention free Random Access, 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 addressed neither to a Temporary C-RNTI nor to a PUR-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 provided by RRC for transmission using PUR; 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:

– if the MAC PDU in the Msg3 buffer contains the Data Volume and Power Headroom Report MAC control element:

– the MAC entity shall update the Data Volume and Power Headroom Report MAC control element in the MAC PDU in the Msg3 buffer.

– if the UE is an NB-IoT UE and cqi-Reporting is configured by upper layers:

– the MAC entity shall update the MAC PDU in the Msg3 buffer in accordance with the DL channel quality measurement result.

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

– else if the uplink grant is a configured grant with totalNumberPUSCH-SPS-STTI-UL-Repetitions or totalNumberPUSCH-SPS-UL-Repetitions and if a retransmission within a bundle is triggered for another configured grant with totalNumberPUSCH-SPS-STTI-UL-Repetitions or totalNumberPUSCH-SPS-UL-Repetitions in this TTI:

– ignore the uplink grant.

– else if the MAC entity is configured with semiPersistSchedIntervalUL shorter than 10 subframes and if the uplink grant is a configured grant, and if the HARQ buffer of the identified HARQ process is not empty, and if HARQ_FEEDBACK of the identified HARQ process is NACK; or if the MAC entity is configured with ul-SchedInterval shorter than 10 subframes and if the uplink grant is a preallocated uplink grant, and if the HARQ buffer of the identified HARQ process is not empty, and if HARQ_FEEDBACK of the identified HARQ process is NACK:

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

– else:

– if the UL HARQ operation is synchronous, and the uplink grant is a preallocated uplink grant, and a MAC PDU has previously been obtained from the "Multiplexing and assembly" entity during this handover attempt:

– ignore the uplink grant;

– else:

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

– if a MAC PDU to transmit has been obtained:

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

– flush the HARQ buffer of the identified HARQ process.

– else:

– if the MAC entity is configured with skipUplinkTxSPS and if the uplink grant received on PDCCH was addressed to the Semi-Persistent Scheduling C-RNTI or to the UL Semi-Persistent Scheduling V-RNTI and if the HARQ buffer of the identified process is empty; or

– if UL HARQ operation is autonomous for the identified HARQ process and if the uplink grant is a configured UL grant and if the HARQ buffer of the identified process is empty; or

– if the previous uplink grant delivered to the HARQ entity for the same HARQ process was a configured uplink grant for which the UL HARQ operation was autonomous, and if the corresponding UL grant size was different from the UL grant size indicated by the uplink grant for this TTI:

– ignore the uplink grant;

– else:

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

– if UL HARQ operation is autonomous for the identified HARQ process and if the uplink grant is a configured UL grant:

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

– else:

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

– if the non-adaptive retransmission collides with a transmission of another HARQ process scheduled using Short Processing Time:

– instruct the identified HARQ process to generate a positive acknowledgement (ACK) of the data in the corresponding TB.

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 and PUR-RNTI.

5.4.2.2 HARQ process

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 serving cells configured with pusch-EnhancementsConfig, BL UEs or UEs in enhanced coverage see clause 8.6.1 in TS 36.213 [2] for the sequence of redundancy versions and redundancy version determination. For NB-IoT UEs see clause 16.5.1.2 in TS 36.213 [2] for the sequence of redundancy versions and redundancy version determination. For an SPS configuration with totalNumberPUSCH-SPS-STTI-UL-Repetitions or totalNumberPUSCH-SPS-UL-Repetitions (TS 36.331 [8]), the redundancy version for each transmission within a bundle are determined by rv-SPS-STTI-UL-Repetitions or rv-SPS-UL-Repetitions in the SPS configuration (TS 36.331 [8]).

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 clauses 16.5.1.2, 8.6.1 and 7.1.7.1 in TS 36.213 [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.

For autonomous HARQ, each HARQ process shall maintain a state variable HARQ_FEEDBACK, which indicates the HARQ feedback for the MAC PDU currently in the buffer, and a timer aul-RetransmissionTimer which prohibits new transmission or retransmission for the same HARQ process on the configured autonomous uplink when the timer is running.

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

– set HARQ_FEEDBACK to the received value;

– if running, stop the aul-RetransmissionTimer.

When an uplink grant addressed to C-RNTI is received for this HARQ process and if the UL HARQ operation is autonomous, the HARQ process shall:

– if running, stop the aul-RetransmissionTimer.

When PUSCH transmission is performed for this TB and if the uplink grant is a configured grant for the MAC entity’s AUL C-RNTI, the HARQ process shall:

– start or restart the aul-RetransmissionTimer.

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;

– else:

– if UL HARQ operation is autonomous asychronous:

– set HARQ_FEEDBACK to NACK.

– if the uplink grant was addressed to the AUL C-RNTI:

– set CURRENT_IRV to 0.

– else:

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

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

– if UL HARQ operation is autonomous:

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

– if both skipUplinkTxSPS and fixedRV-NonAdaptive are configured and the uplink grant of the initial transmission of this HARQ process was performed on a configured grant and UL HARQ operation is not autonomous; or

– if the uplink grant is a preallocated uplink grant:

– set CURRENT_IRV to 0;

– else if UL HARQ operation is autonomous:

– set CURRENT_IRV to the index corresponding to the redundancy version value selected by the UE implementation.

– generate a transmission as described below.

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

NOTE 2: When no UL-SCH transmission can be made due to the occurrence of a measurement gap or a Sidelink Discovery Gap for Transmission, or prioritization of V2X sidelink communication transmission described in clause 5.14.1.2.2, no HARQ feedback can be received and a non-adaptive retransmission follows.

NOTE 3: 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:

– if there is neither transmission of V2X sidelink communication on SL-SCH nor transmission of NR sidelink communication in this TTI; or

– if the transmission of the MAC PDU is prioritized over sidelink transmission:

– 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 not autonomous;

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

The transmission of the MAC PDU is prioritized over sidelink transmission or can be performed simultaneously with sidelink transmission if one of the following conditions is met:

– if there are both a configured grant for transmission of V2X sidelink communication on SL-SCH in this TTI and a sidelink grant for transmission of NR sidelink communication as described in clause 5.22.1.1 of TS 38.321 [24] at the time of the transmission, and neither the transmissions of V2X sidelink communication is prioritized as described in clause 5.14.1.2.2 nor the transmission of NR sidelink communication is prioritized as described in clause 5.22.1.3.1a of TS 38.321 [24]; or

– if there is only configured grant(s) for transmission of V2X sidelink communication on SL-SCH in this TTI, and either none of the transmissions of V2X sidelink communication is prioritized or the MAC entity is able to perform this UL transmission and the transmissions of V2X sidelink communication simultaneously; or

– if there is only a sidelink grant for transmission of NR sidelink communication in this TTI as described in clause 5.22.1.1 of TS 38.321 [24], and either no transmission of NR sidelink communication is prioritized as described in clause 5.22.1.3.1a of TS 38.321 [24] or the MAC entity is able to perform this UL transmission simultaneously with the transmission of NR sidelink communication; or

– if there are both a configured grant for transmission of V2X sidelink communication on SL-SCH in this TTI and a sidelink grant for transmission of NR sidelink communication as described in clause 5.22.1.1 of TS 38.321 [24] at the time of the transmission, and either only the transmissions of V2X sidelink communication is prioritized as described in clause 5.14.1.2.2 or only the transmission of NR sidelink communication is prioritized as described in clause 5.22.1.3.1a of TS 38.321 [24] and the MAC entity is able to perform this UL transmission simultaneously with the prioritized transmission of V2X sidelink communication or NR sidelink communication.

NOTE 4: Among the UL transmissions where the MAC entity is able to perform all transmissions of V2X sidelink communication prioritized simultaneously, if there are more than one UL transmission which the MAC entity is not able to perform simultaneously, it is up to UE implementation whether this UL transmission is performed.

NOTE 5: Among the UL transmissions that the MAC entity is able to perform simultaneously with the transmission of NR sidelink communication prioritized, if there are more than one UL transmission which the MAC entity is not able to perform simultaneously, it is up to UE implementation whether this UL transmission is performed.

NOTE 6: Among the UL transmissions where the MAC entity is able to perform all transmissions of V2X sidelink communication prioritized simultaneously with the transmission of NR sidelink communication prioritized, if there are more than one UL transmission which the MAC entity is not able to perform simultaneously, it is up to UE implementation whether this UL transmission is performed.

NOTE 7: If there is a sidelink grant for transmission of NR sidelink communication in this TTI as described in clause 5.22.1.1 of TS 38.321 [24] and the MAC entity is not able to perform this UL transmission simultaneously with the transmission of NR sidelink communication, and prioritization-related information is not available prior to the time of the transmission due to processing time restriction, it is up to UE implementation whether this UL transmission is performed.

5.4.3 Multiplexing and assembly

5.4.3.1 Logical channel prioritization

The Logical Channel Prioritization procedure is applied when a new transmission is performed.

RRC controls the scheduling of uplink data by signalling for each logical channel: priority where an increasing priority value indicates a lower priority level, prioritisedBitRate which sets the Prioritized Bit Rate (PBR), bucketSizeDuration which sets the Bucket Size Duration (BSD), and optionally allowedTTI-Lengths which sets the allowed TTI lengths. For NB-IoT, prioritisedBitRate, bucketSizeDuration and the corresponding steps of the Logical Channel Prioritisation procedure (i.e., Step 1 and Step 2 below) are not applicable.

The MAC entity shall maintain a variable Bj for each logical channel j. Bj shall be initialized to zero when the related logical channel is established, and incremented by the product PBR × TTI duration for each TTI, where PBR is Prioritized Bit Rate of logical channel j. However, the value of Bj can never exceed the bucket size and if the value of Bj is larger than the bucket size of logical channel j, it shall be set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.

Before the successful completion of the contention based Random Access procedure initiated for DAPS handover, the target MAC entity shall not select the logical channel(s) corresponding to non-DAPS DRB(s) for the uplink grant received in a Random Access Response. The source MAC entity shall select only the logical channel(s) corresponding to DAPS DRB(s) during DAPS handover.

The MAC entity shall perform the following Logical Channel Prioritization procedure when a new transmission is performed on an UL grant with a certain TTI length:

– The MAC entity shall allocate resources to the logical channels that are allowed to transmit using the TTI length of the grant, in the following steps:

– Step 1: All the allowed logical channels with Bj > 0 are allocated resources in a decreasing priority order. If the PBR of a logical channel is set to "infinity", the MAC entity shall allocate resources for all the data that is available for transmission on the logical channel before meeting the PBR of the lower priority logical channel(s);

– Step 2: the MAC entity shall decrement Bj by the total size of MAC SDUs served to logical channel j in Step 1;

NOTE 1: The value of Bj can be negative.

– Step 3: if any resources remain, all the allowed logical channels are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.

– The UE shall also follow the rules below during the scheduling procedures above:

– the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources of the associated MAC entity;

– if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant of the associated MAC entity as much as possible;

– the UE should maximise the transmission of data.

– if the MAC entity is given an UL grant size that is equal to or larger than 4 bytes while having data available for transmission, the MAC entity shall not transmit only padding BSR and/or padding (unless the UL grant size is less than 7 bytes and an AMD PDU segment needs to be transmitted);

– for transmissions on serving cells operating according to Frame Structure Type 3, the MAC entity shall only consider logical channels for which laa-UL-Allowed has been configured;

– if a logical channel has been configured with lch-CellRestriction and if PDCP duplication within the same MAC entity (i.e. CA duplication) is activated, for this logical channel the MAC entity shall consider the cells indicated by lch-CellRestriction to be restricted for transmission.

– for NB-IoT UEs, BL UEs or UEs in enhanced coverage, if edt-SmallTBS-Enabled is set to TRUE for the corresponding PRACH resource, the UE shall choose a TB size among the set of possible TB sizes as described in clauses 8.6.2 and 16.3.3 of TS 36.213 [2]

The MAC entity shall not transmit data for a logical channel corresponding to a radio bearer that is suspended (the conditions for when a radio bearer is considered suspended are defined in TS 36.331 [8]).

If the MAC PDU includes only the MAC CE for padding BSR or periodic BSR with zero MAC SDUs and there is no aperiodic CSI requested for this TTI, as specified in TS 36.213 [2], the MAC entity shall not generate a MAC PDU for the HARQ entity in the following cases:

– in case the MAC entity is configured with skipUplinkTxDynamic and the grant indicated to the HARQ entity was addressed to a C-RNTI; or

– in case the MAC entity is configured with skipUplinkTxSPS and the grant indicated to the HARQ entity is a configured uplink grant activated by the MAC entity’s Semi-Persistent Scheduling C-RNTI or by the MAC entity’s UL Semi-Persistent Scheduling V-RNTI; or

– in case the grant indicated to the HARQ entity is a configured uplink grant activated by the MAC entity’s AUL C-RNTI; or

– in case the grant indicated to the HARQ entity is a preconfigured uplink grant.

NOTE 1a: If at least one MAC PDU is to be generated for the HARQ entity for this TTI, the MAC entity generates MAC PDUs corresponding to all UL grants indicated to the HARQ entity for this TTI.

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 DPR;

– MAC control element for SPS confirmation;

– MAC control element for AUL confirmation;

– MAC control element for Timing Advance Report;

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

– MAC control element for DCQR and AS RAI, with exception of when DCQR is to be included in Msg3;

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

– MAC control element for DCQR and AS RAI, when DCQR is to be included in Msg3;

– MAC control element for Recommended bit rate query;

– MAC control element for BSR included for padding;

– MAC control element for Sidelink BSR included for padding.

When AS RAI has been triggered, DCQR and AS RAI MAC control element shall have higher priority than data from any Logical Channel, except data from UL-CCCH, only if after logical channel prioritization including AS RAI in the resulting MAC PDU does not require segmenting RLC SDU. Otherwise data from any Logical Channel shall have higher priority than DCQR and AS RAI MAC control element.

NOTE 2: 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.

5.4.3.2 Multiplexing of MAC Control Elements and MAC SDUs

The MAC entity shall multiplex MAC control elements and MAC SDUs in a MAC PDU according to clauses 5.4.3.1 and 6.1.2.

5.4.4 Scheduling Request

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.

If the MAC entity has resources for SR configured on only one of SPUCCH and PUCCH, that SR resource is valid for all logical channels. If the MAC entity has resources for SR configured on both PUCCH and SPUCCH, MAC entity shall consider all logical channels that have triggered an SR (and at retxBSR-Timer expiry, MAC entity shall consider all logical channels, belonging to a LCG, with data available for transmission):

– PUCCH resources for SR are valid if logicalChannelSr-Restriction is not configured, or if logicalChannelSr-Restriction allows SR on PUCCH, for any of the logical channels;

– SPUCCH resources for SR are valid if logicalChannelSr-Restriction is not configured, or if logicalChannelSr-Restriction allows SR on SPUCCH, for any of the logical channels.

If an SR is triggered and there is no other SR pending, the MAC entity shall set the SR_COUNTER and the SSR_COUNTER to 0.

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:

– Except for NB-IoT:

– if the MAC entity has no valid PUCCH nor valid SPUCCH resource for SR configured in any TTI:

– if the MAC entity is a MCG MAC entity and rach-Skip is not configured; or

– if the MAC entity is a SCG MAC entity and rach-SkipSCG is not configured:

– initiate a Random Access procedure (see clause 5.1) on the corresponding SpCell and cancel all pending SRs;

– else if this TTI is not part of a measurement gap or Sidelink Discovery Gap for Transmission, and if transmission of V2X sidelink communication is not prioritized in this TTI as described in clause 5.14.1.2.2:

– if the MAC entity has at least one valid SPUCCH resource for SR configured for this TTI and if ssr-ProhibitTimer is not running:

– if SSR_COUNTER < dssr-TransMax:

– increment SSR_COUNTER by 1;

– instruct the physical layer to signal the SR on one valid SPUCCH resource for SR;

– start the ssr-ProhibitTimer.

– else:

– notify RRC to release SPUCCH for all serving cells;

– if the MAC entity has no valid PUCCH resource for SR configured in any TTI:

– notify RRC to release PUCCH for all serving cells;

– notify RRC to release SRS for all serving cells;

– clear any configured downlink assignments and uplink grants;

– initiate a Random Access procedure (see clause 5.1) on the SpCell and cancel all pending SRs.

– if the MAC entity has at least one valid PUCCH resource for SR configured for this TTI and if sr-ProhibitTimer is not running:

– if SR_COUNTER < dsr-TransMax:

– increment SR_COUNTER by 1;

– instruct the physical layer to signal the SR on one valid PUCCH resource for SR;

– start the sr-ProhibitTimer.

– else:

– notify RRC to release PUCCH and SPUCCH for all serving cells;

– notify RRC to release SRS for all serving cells;

– clear any configured downlink assignments and uplink grants;

– initiate a Random Access procedure (see clause 5.1) on the SpCell and cancel all pending SRs.

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

NOTE 1: The selection of which valid PUCCH/SPUCCH resource for SR to signal SR on when the MAC entity has more than one valid PUCCH/SPUCCH resource for SR in one TTI or overlapping TTIs is left to UE implementation.

NOTE 2: SR_COUNTER is incremented for each SR bundle. sr-ProhibitTimer is started in the first TTI of an SR bundle.

5.4.5 Buffer Status Reporting

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, as specified in TS 36.331 [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 TS 36.322 [3] and TS 36.323 [4] or TS 38.323 [17] 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-Prohibit 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.

For NB-IoT or BL UEs:

– if rai-Activation is configured, and a buffer size of zero bytes has been triggered for the BSR, and the UE may have more data to send or receive in the near future:

– cancel any pending 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; or

– if sr-WithHARQ-ACK-Config is configured and there is valid resource for SR together with acknowledgement of the data in this TTI:

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

For EDT, the MAC entity shall not generate a BSR MAC control element if new transmission is for Msg3.

For CP-PUR, the MAC entity shall not generate a BSR MAC control element if new transmission is intended for preconfigured uplink grant.

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

NOTE 2: If UL HARQ operation is autonomous for the HARQ entity and if the BSR is already included in a MAC PDU for transmission by this HARQ entity, but not yet transmitted by lower layers, it is up to UE implementation how to handle the BSR content.

5.4.5a Data Volume and Power Headroom Reporting

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. For EDT, the Data Volume in DPR MAC control element is set to zero.

If enhancedPHR is configured and the UE supports extended power headroom reporting, the UE shall:

– if the UE supports power class 14dBm and the MAC entity considers itself to be in enhanced coverage level other than 0:

– report power headroom level using the DPR MAC control element;

– else:

– report extended power headroom level using the DPR MAC control element for Extended Power Headroom level reporting.

5.4.6 Power Headroom Reporting

The Power Headroom reporting procedure is used to provide the serving eNB with information about the difference between the nominal UE maximum transmit power and the estimated power for UL-SCH transmission or SRS transmission per activated Serving Cell and also with information about the difference between the nominal UE maximum power and the estimated power for UL-SCH and PUCCH/SPUCCH transmission on SpCell and PUCCH SCell.

The reporting period, delay and mapping of Power Headroom are defined in TS 36.133 [9] and TS 38.133 [19]. RRC controls Power Headroom reporting by configuring the two timers periodicPHR-Timer and prohibitPHR-Timer, and by signalling dl-PathlossChange which sets the change in measured downlink pathloss and the required power backoff due to power management (as allowed by P-MPR_c, see TS 36.101 [10] and TS 38.101-3 [21]) to trigger a PHR, as specified in TS 36.331 [8].

A Power Headroom Report (PHR) shall be triggered if any of the following events occur:

– prohibitPHR-Timer expires or has expired and the path loss has changed more than dl-PathlossChange dB for at least one activated Serving Cell of any MAC entity which is used as a pathloss reference since the last transmission of a PHR in this MAC entity when the MAC entity has UL resources for new transmission;

– periodicPHR-Timer expires;

– upon configuration or reconfiguration of the power headroom reporting functionality by upper layers, as specified in TS 36.331 [8], which is not used to disable the function;

– activation of an SCell of any MAC entity with configured uplink;

– addition of the PSCell (i.e. PSCell is newly added or PSCell is changed);

– prohibitPHR-Timer expires or has expired, when the MAC entity has UL resources for new transmission, and the following is true in this TTI for any of the activated Serving Cells of any MAC entity with configured uplink:

– there are UL resources allocated for transmission or there is a PUCCH/SPUCCH transmission on this cell, and the required power backoff due to power management (as allowed by P-MPR_c, see TS 36.101 [10] and TS 38.101-3 [21]) for this cell has changed more than dl-PathlossChange dB since the last transmission of a PHR when the MAC entity had UL resources allocated for transmission or PUCCH/SPUCCH transmission on this cell.

NOTE 1: The MAC entity should avoid triggering a PHR when the required power backoff due to power management decreases only temporarily (e.g. for up to a few tens of milliseconds) and it should avoid reflecting such temporary decrease in the values of P_CMAX,c/PH when a PHR is triggered by other triggering conditions.

NOTE 2: If UL HARQ operation is autonomous for the HARQ entity and if the PHR is already included in a MAC PDU for transmission by this HARQ entity, but not yet transmitted by lower layers, it is up to UE implementation how to handle the PHR content.

If the MAC entity has UL resources allocated for new transmission for this TTI the MAC entity shall:

– if it is the first UL resource allocated for a new transmission since the last MAC reset, start periodicPHR-Timer;

– if the Power Headroom reporting procedure determines that at least one PHR has been triggered and not cancelled, and;

– if the allocated UL resources can accommodate the MAC control element for PHR which the MAC entity is configured to transmit, plus its subheader, as a result of logical channel prioritization:

– if extendedPHR is configured:

– for each activated Serving Cell with configured uplink:

– obtain the value of the Type 1 or Type 3 power headroom;

– if the MAC entity has UL resources allocated for transmission on this Serving Cell for this TTI:

– obtain the value for the corresponding P_CMAX,c field from the physical layer;

– if simultaneousPUCCH-PUSCH is configured or a serving cell operating according to Frame Structure Type 3 with uplink is configured and activated:

– obtain the value of the Type 2 power headroom for the PCell;

– obtain the value for the corresponding P_CMAX,c field from the physical layer (see clause 5.1.1.2 of TS 36.213 [2]);

– instruct the Multiplexing and Assembly procedure to generate and transmit an Extended PHR MAC control element for extendedPHR as defined in clause 6.1.3.6a based on the values reported by the physical layer;

– else if extendedPHR2 is configured:

– for each activated Serving Cell with configured uplink:

– obtain the value of the Type 1 or Type 3 power headroom;

– if the MAC entity has UL resources allocated for transmission on this Serving Cell for this TTI:

– obtain the value for the corresponding P_CMAX,c field from the physical layer;

– if a PUCCH SCell is configured and activated:

– obtain the value of the Type 2 power headroom for the PCell and PUCCH SCell;

– obtain the values for the corresponding P_CMAX,c fields from the physical layer (see clause 5.1.1.2 ofTS 36.213 [2]);

– else:

– if simultaneousPUCCH-PUSCH is configured for the PCell or a serving cell operating according to Frame Structure Type 3 with uplink is configured and activated:

– obtain the value of the Type 2 power headroom for the PCell;

– obtain the value for the corresponding P_CMAX,c field from the physical layer (see clause 5.1.1.2 of TS 36.213 [2]);

– instruct the Multiplexing and Assembly procedure to generate and transmit an Extended PHR MAC control element for extendedPHR2 according to configured ServCellIndex and the PUCCH(s) for the MAC entity as defined in clause 6.1.3.6a based on the values reported by the physical layer;

– else if dualConnectivityPHR is configured:

– for each activated Serving Cell with configured uplink associated with any MAC entity:

– obtain the value of the Type 1 or Type 3 power headroom;

– if this MAC entity has UL resources allocated for transmission on this Serving Cell for this TTI or if the other MAC entity has UL resources allocated for transmission on this Serving Cell for this TTI and phr-ModeOtherCG is set to real by upper layers:

– obtain the value for the corresponding P_CMAX,c field from the physical layer;

– if simultaneousPUCCH-PUSCH is configured or a serving cell operating according to Frame Structure Type 3 with uplink is configured and activated:

– obtain the value of the Type 2 power headroom for the SpCell;

– obtain the value for the corresponding P_CMAX,c field for the SpCell from the physical layer (see clause 5.1.1.2 of TS 36.213 [2]);

– if the other MAC entity is E-UTRA MAC entity:

– obtain the value of the Type 2 power headroom for the SpCell of the other MAC entity.

– if phr-ModeOtherCG is set to real by upper layers:

– obtain the value for the corresponding P_CMAX,c field for the SpCell of the other MAC entity from the physical layer (see clause 5.1.1.2 of TS 36.213 [2]);

– instruct the Multiplexing and Assembly procedure to generate and transmit a Dual Connectivity PHR MAC control element as defined in clause 6.1.3.6b based on the values reported by the physical layer;

– else:

– obtain the value of the Type 1 power headroom from the physical layer;

– instruct the Multiplexing and Assembly procedure to generate and transmit a PHR MAC control element as defined in clause 6.1.3.6 based on the value reported by the physical layer;

– start or restart periodicPHR-Timer;

– start or restart prohibitPHR-Timer;

– cancel all triggered PHR(s).

5.4.7 Preconfigured Uplink Resource

5.4.7.1 Transmission using PUR

Transmission using PUR is initiated by the RRC layer. When transmission using PUR is initiated, RRC layer provides MAC with the following information:

– PUR-RNTI;

– Duration of PUR response window pur-ResponseWindowTimer;

– UL grant information.

If the MAC entity has a PUR-RNTI, the MAC entity shall for each TTI for which RRC layer has provided uplink grant for transmission using PUR:

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

After transmission using PUR, the MAC entity shall monitor PDCCH identified by PUR-RNTI in the PUR response window using timer pur-ResponseWindowTimer:

– if PUR was transmitted in a non-terrestrial network:

– the MAC entity shall start pur-ResponseWindowTimer at the subframe that contains the end of the corresponding PUSCH transmission plus 4 + UE-eNB RTT subframes.

– else:

– the MAC entity shall start pur-ResponseWindowTimer at the subframe that contains the end of the corresponding PUSCH transmission plus 4 subframes.

While pur-ResponseWindowTimer is running, the MAC entity shall:

– if the PDCCH transmission is addressed to the PUR-RNTI and contains an UL grant for a retransmission:

– restart pur-ResponseWindowTimer at the last subframe of a PUSCH transmission corresponding to the retransmission indicated by the UL grant plus 4 subframes.

– if L1 ACK for transmission using PUR is received from lower layers; or

– if PDCCH transmission is addressed to the PUR-RNTI and the MAC PDU is successfully decoded:

– stop pur-ResponseWindowTimer;

– if L1 ACK for transmission using PUR is received from lower layers or the MAC PDU contains only Timing Advance Command MAC control element:

– indicate to upper layers the transmission using PUR was successful;

– if repetition adjustment for transmission using PUR is received from lower layers:

– indicate the value of the repetition adjustment to upper layers.

– discard the PUR-RNTI.

– else if fallback indication for PUR is received from lower layers:

– stop pur-ResponseWindowTimer;

– indicate to upper layers PUR fallback indication is received;

– if repetition adjustment for transmission using PUR is received from lower layers:

– indicate the value of the repetition adjustment to upper layers.

– discard the PUR-RNTI.

– if the pur-ResponseWindowTimer expires:

– indicate to upper layers the transmission using PUR has failed;

– discard the PUR-RNTI.

5.4.7.2 Maintenance of PUR Uplink Time Alignment

MAC entity may be configured with timer pur-TimeAlignmentTimer by upper layers as specified in TS 36.331 [8], clause 5.3.8.3.

The MAC entity shall:

– when pur-TimeAlignmentTimer configuration is received from upper layers:

– start or restart pur-TimeAlignmentTimer.

– when pur-TimeAlignmentTimer is released by upper layers:

– stop the pur-TimeAlignmentTimer, if running.

– when a Timing Advance Command MAC control element is received or PDCCH indicates timing advance adjustment as specified in TS 36.212 [5] and if a N_TA has been stored or maintained:

– if the Timing Advance Command MAC control element or PDCCH indicating timing advance adjustment is addressed with a PUR-RNTI:

– apply the Timing Advance Command or the timing advance adjustment;

– start or restart the pur-TimeAlignmentTimer, if configured;

– indicate to upper layers that the Timing Advance value has been adjusted.

– upon considering a Random Access procedure successfully completed:

– start or restart the pur-TimeAlignmentTimer, if configured;

– indicate to upper layers that the Timing Advance value has been adjusted;

– if a temporary N_TA has been stored, delete the stored temporary N_TA.

– upon considering a Random Access procedure unsuccessfully completed, if a temporary N_TA has been stored:

– set the N_TA to the stored temporary N_TA;

– delete the stored temporary N_TA.

Upon request from upper layers, MAC entity shall indicate whether pur-TimeAlignmentTimer is running.

5.4.8 Access Stratum Release Assistance Indication

Access Stratum Release Assistance Indication is used to provide the serving eNB with information whether subsequent DL or UL transmission is expected. AS RAI uses the DCQR and AS RAI MAC Control Element. Upper layers trigger AS RAI.

For EDT and transmission using PUR, if AS RAI is triggered by upper layers but is not included in the resulting MAC PDU with the MAC SDU as a result of logical channel prioritization, AS RAI is cancelled, for other transmissions if AS RAI is not included in the resulting MAC PDU as a result of logical channel prioritization, AS RAI may be cancelled.

If rai-Activation is configured and a buffer size of zero bytes has been triggered for the BSR and no subsequent DL and UL data transmission is expected, and if rai-ActivationEnh is enabled and applicable as specified in TS 36.331 [8], it is up to UE to send BSR MAC control element or DCQR and AS RAI MAC control element.

5.4.9 Timing Advance Reporting

The UE may be configured to report information about UE specific timing advance during a Random Access procedure and in RRC_CONNECTED Mode.

The Timing Advance reporting procedure is used in a non-terrestrial network to provide the eNB with an estimate of the UE’s Timing Advance, see T_TA in TS 36.211 [7] clause 8.1.

Timing Advance reporting shall be triggered if any of the following events occur:

– if triggered by upper layers;

– upon configuration of offsetThresholdTA by upper layers, if the UE has not previously reported Timing Advance value to current Serving Cell;

– if the variation between current information about Timing Advance and the last reported information about Timing Advance is equal to or larger than offsetThresholdTA, if configured.

If the Timing Advance reporting procedure determines that at least one Timing Advance Report has been triggered and not cancelled:

– if the MAC entity has UL resources allocated for new transmission for this TTI, and;

– if the allocated UL resources can accommodate the Timing Advance Report MAC control element plus its subheader, as a result of logical channel prioritization:

– instruct the Multiplexing and Assembly procedure to generate the Timing Advance report MAC control element as defined in clause 6.1.3.20.

A MAC PDU shall contain at most one Timing Advance Report MAC CE, even when multiple events have triggered a Timing Advance report.

All triggered Timing Advance reports shall be cancelled when a Timing Advance Report MAC CE is included in a MAC PDU for transmission.

5.5 PCH reception

When the MAC entity needs to receive PCH, the MAC entity shall:

– if a PCH assignment has been received on the PDCCH for the P-RNTI:

– attempt to decode the TB on the PCH as indicated by the PDCCH information.

– if a TB on the PCH has been successfully decoded:

– deliver the decoded MAC PDU to upper layers.

5.6 BCH reception

When the MAC entity needs to receive BCH, the MAC entity shall:

– receive and attempt to decode the BCH;

– if a TB on the BCH has been successfully decoded:

– deliver the decoded MAC PDU to upper layers.

5.7 Discontinuous Reception (DRX)

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

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

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

– a Scheduling Request is sent on PUCCH/SPUCCH and is pending (as described in clause 5.4.4). If this Serving Cell is part of a non-terrestrial network, the Active Time is started after the Scheduling Request transmission that is performed when the SR_COUNTER is 0 for all the SR configurations with pending SR(s) plus the UE-eNB RTT; 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 clause 5.1.4) ; or

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

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

– if a HARQ RTT Timer expires in this subframe:

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

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

– if NB-IoT:

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

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

– else:

– start or restart the drx-InactivityTimer.

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

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

– if NB-IoT:

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

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

– else:

– start or restart the drx-InactivityTimer.

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

– stop onDurationTimer;

– stop drx-InactivityTimer.

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

– if the Short DRX cycle is configured:

– start or restart drxShortCycleTimer;

– use the Short DRX Cycle.

– else:

– use the Long DRX cycle.

– if drxShortCycleTimer expires in this subframe:

– use the Long DRX cycle.

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

– stop drxShortCycleTimer;

– use the Long DRX cycle.

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

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

– if NB-IoT:

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

– else:

– start onDurationTimer.

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

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

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

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

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

– else:

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

– else:

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

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

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

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

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

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

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

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

– else:

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

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

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

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

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

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

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

– start or restart drx-InactivityTimer.

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

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

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

– stop drx-InactivityTimer.

– stop onDurationTimer.

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

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

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

– else if the PUSCH transmission is completed:

– stop drx-ULRetransmissionTimer for all UL HARQ processes.

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

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

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

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

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

– else:

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

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

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

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

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

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

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

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

5.7a Discontinuous Reception (DRX) for SC-PTM

Each G-RNTI and, for NB-IoT UEs, BL UEs or UEs in enhanced coverage, each SC-RNTI of the MAC entity may be configured by RRC with a DRX functionality that controls the UE’s PDCCH monitoring activity for this G-RNTI and SC-RNTI as specified in TS 36.331 [8]. When in RRC_IDLE or RRC_CONNECTED, if DRX is configured, the MAC entity is allowed to monitor the PDCCH for this G-RNTI or SC-RNTI discontinuously using the DRX operation specified in this clause; otherwise the MAC entity monitors the PDCCH for this G-RNTI or SC-RNTI continuously. For each G-RNTI or SC-RNTI of the MAC entity, RRC controls its DRX operation by configuring the timers onDurationTimerSCPTM, drx-InactivityTimerSCPTM, the SCPTM-SchedulingCycle and the value of the SCPTM-SchedulingOffset for G-RNTI and for SC-RNTI. The DRX operation specified in this clause is performed independently for each G-RNTI and SC-RNTI and independently from the DRX operation specified in subcaluse 5.7.

When DRX is configured for a G-RNTI or for SC-RNTI, the Active Time includes the time while:

– onDurationTimerSCPTM or drx-InactivityTimerSCPTM is running.

When DRX is configured for a G-RNTI or for SC-RNTI as specified in TS 36.331 [8], the MAC entity shall for each subframe for this G-RNTI or SC-RNTI:

– if [(H-SFN * 10240 + SFN * 10) + subframe number] modulo (SCPTM-SchedulingCycle) = SCPTM-SchedulingOffset:

– start onDurationTimerSCPTM.

– during the Active Time, for a PDCCH-subframe:

– monitor the PDCCH;

– if the PDCCH indicates a DL transmission:

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

– start or re-start the drx-InactivityTimerSCPTM in the subframe containing the last repetition of the corresponding PDSCH reception.

– if the UE is an NB-IoT UE:

– stop onDurationTimerSCPTM;

– stop drx-InactivityTimerSCPTM;

– start the drx-InactivityTimerSCPTM in the first subframe of the next PDCCH occasion following the subframe containing the last repetition of the corresponding PDSCH reception.

– else:

– start or restart drx-InactivityTimerSCPTM.

NOTE: If H-SFN is not configured its value is set to 0 in the calculation of the starting subframe.

5.8 MAC reconfiguration

When a reconfiguration of the MAC entity is requested by upper layers, the MAC entity shall:

– upon addition of an SCell, initialize the corresponding HARQ entity;

– upon removal of an SCell, remove the corresponding HARQ entity;

– for timers apply the new value when the timer is (re)started;

– when counters are initialized apply the new maximum parameter value;

– for other parameters, apply immediately the configurations received from upper layers.

5.9 MAC Reset

If a reset of the MAC entity is requested by upper layers, the MAC entity shall:

– initialize Bj for each logical channel to zero;

– except for pur-TimeAlignmentTimer, if configured, stop (if running) all timers;

– except for pur-TimeAlignmentTimer, if configured, consider all timeAlignmentTimers as expired and perform the corresponding actions in clause 5.2;

– set the NDIs for all uplink HARQ processes to the value 0;

– stop, if any, ongoing RACH procedure;

– discard explicitly signalled ra-PreambleIndex and ra-PRACH-MaskIndex, if any;

– flush Msg3 buffer;

– cancel, if any, triggered Scheduling Request procedure;

– cancel, if any, triggered Buffer Status Reporting procedure;

– cancel, if any, triggered Power Headroom Reporting procedure;

– cancel, if any, triggered Recommended bit rate query procedure;

– cancel, if any, triggered Timing Advance Reporting procedure;

– flush the soft buffers for all DL HARQ processes;

– for each DL HARQ process, consider the next received transmission for a TB as the very first transmission;

– release, if any, Temporary C-RNTI.

If a partial reset of the MAC entity is requested by upper layers, for a serving cell, the MAC entity shall for the serving cell:

– set the NDIs for all uplink HARQ processes to the value 0;

– flush all UL HARQ buffers;

– stop all running drx-ULRetransmissionTimers;

– stop all running UL HARQ RTT timers;

– stop, if any, ongoing RACH procedure;

– discard explicitly signalled ra-PreambleIndex and ra-PRACH-MaskIndex, if any;

– flush Msg3 buffer;

– release, if any, Temporary C-RNTI.

5.10 Semi-Persistent Scheduling

Except for NB-IoT, multiple UL Semi-Persistent Scheduling configurations are supported per Serving Cell. For NB-IoT, UL Semi-Persistent Scheduling configuration is only supported for BSR per Serving Cell. On one Serving Cell, multiple UL configurations can be active simultaneously only for the same TTI length. Multiple UL/DL configurations can also be active simultaneously on different Serving Cells.

When Semi-Persistent Scheduling is enabled by RRC, the following information is provided, as specified in TS 36.331 [8]:

– Semi-Persistent Scheduling C-RNTI or UL Semi-Persistent Scheduling V-RNTI;

– Uplink Semi-Persistent Scheduling interval semiPersistSchedIntervalUL if short TTI in UL for the SpCell is not configured or semiPersistSchedIntervalUL–sTTI in UL for the SpCell if short TTI is configured and number of empty transmissions before implicit release implicitReleaseAfter, if Semi-Persistent Scheduling with Semi-Persistent Scheduling C-RNTI is enabled for the uplink;

– Uplink Semi-Persistent Scheduling interval semiPersistSchedIntervalUL and number of empty transmissions before implicit release implicitReleaseAfter for each SPS configuration, if Semi-Persistent Scheduling with UL Semi-Persistent Scheduling V-RNTI is enabled for the uplink;

– Whether twoIntervalsConfig is enabled or disabled for uplink, only for TDD;

– Downlink Semi-Persistent Scheduling interval semiPersistSchedIntervalDL if short TTI in DL for the SpCell is not configured or semiPersistSchedIntervalDL–sTTI if short TTI in DL for the SpCell is configured and number of configured HARQ processes for Semi-Persistent Scheduling numberOfConfSPS-Processes, if Semi-Persistent Scheduling is enabled for the downlink;

– sTTIStartTimeDl if short TTI in DL for the SpCell is configured and sTTIStartTimeUl if short TTI in UL for the SpCell is configured;

When Semi-Persistent Scheduling for uplink or downlink is disabled by RRC, the corresponding configured grant or configured assignment shall be discarded.

Semi-Persistent Scheduling is not supported for RN communication with the E-UTRAN in combination with an RN subframe configuration.

NOTE: When eIMTA is configured, if a configured uplink grant or a configured downlink assignment occurs on a subframe that can be reconfigured through eIMTA L1 signalling, then the UE behaviour is left unspecified.

5.10.1 Downlink

After a Semi-Persistent downlink assignment is configured, the MAC entity shall consider sequentially that the N^th assignment occurs in the TTI for which:

– subframe SPS is used:

– (10 * SFN + subframe) = [(10 * SFN_{start time} + subframe_{start time}) + N * semiPersistSchedIntervalDL] modulo 10240.

– slot or subslot SPS is used:

– (10 * SFN * sTTI_Number_Per_Subframe + subframe * sTTI_Number_Per_Subframe + sTTI_number) = [(10 * SFN_{start time} * sTTI_Number_Per_Subframe + subframe_{start time}* sTTI_Number_Per_Subframe + sTTIStartTimeDl) + N * semiPersistSchedIntervalDL-sTTI] modulo (10240 * sTTI_Number_Per_Subframe).

Where SFN_{start time}, subframe_{start time} and sTTIStartTimeDl are the SFN, subframe and sTTI_number, respectively, at the time the configured downlink assignment were (re-)initialised. The sTTI_Number_Per_Subframe is 6 when subslot TTI is configued and 2 when slot TTI is configured for short TTI operation. sTTI_number refers to the index of the short TTI, i.e., index of subslot or slot within the subframe.

For BL UEs or UEs in enhanced coverage SFN_{start time} and subframe_{start time} refer to SFN and subframe of the first transmission of PDSCH where configured downlink assignment was (re-)initialized.

5.10.2 Uplink

After a Semi-Persistent Scheduling uplink grant is configured, the MAC entity shall:

– if twoIntervalsConfig is enabled by upper layer:

– set the Subframe_Offset according to Table 7.4-1.

– else:

– set Subframe_Offset to 0.

– consider sequentially that the N^th grant occurs in the TTI for which:

– subframe SPS is used:

– (10 * SFN + subframe) = [(10 * SFN_{start time} + subframe_{start time}) + N * semiPersistSchedIntervalUL + Subframe_Offset * (N modulo 2)] modulo 10240.

– slot or subslot SPS is used:

– (10 * SFN * sTTI_Number_Per_Subframe + subframe * sTTI_Number_Per_Subframe + sTTI_number) = [(10 * SFN_{start time} * sTTI_Number_Per_Subframe + subframe_{start time} * sTTI_Number_Per_Subframe + sTTIStartTimeUl) + N * semiPersistSchedIntervalUL-sTTI+ Subframe_Offset * (N modulo 2) * sTTI_Number_Per_Subframe] modulo (10240 * sTTI_Number_Per_Subframe).

Where SFN_{start time}, subframe_{start time} and sTTIStartTimeUl are the SFN, subframe and sTTI_number, respectively, at the time the configured uplink grant were (re-)initialised. The sTTI_Number_Per_Subframe is 6 when subslot TTI is configued and 2 when slot TTI is configured for short TTI operation. sTTI_number refers to the index of the short TTI, i.e., index of subslot or slot within the subframe.

Except for NB-IoT, for TDD, the MAC entity is configured with semiPersistSchedIntervalUL shorter than 10 subframes, the N^th grant shall be ignored if it occurs in a downlink subframe or a special subframe.

Except for NB-IoT, if the MAC entity is not configured with skipUplinkTxSPS, the MAC entity shall clear the configured uplink grant immediately after implicitReleaseAfter, as specified in TS 36.331 [8], number of consecutive new MAC PDUs each containing zero MAC SDUs have been provided by the Multiplexing and Assembly entity, on the Semi-Persistent Scheduling resource.

If SPS confirmation 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 an SPS confirmation MAC Control Element as defined in clause 6.1.3.11;

– cancel the triggered SPS confirmation.

The MAC entity shall clear the configured uplink grant immediately after first transmission of SPS confirmation MAC Control Element triggered by the SPS release.

NOTE: Retransmissions for Semi-Persistent Scheduling can continue after clearing the configured uplink grant.

For NB-IoT UEs, BL UEs or UEs in enhanced coverage SFN_{start time} and subframe_{start time}refer to SFN and subframe of the first transmission of PUSCH where configured uplink grant was (re-)initialized.

In the event of a resource conflict between multiple UL SPS configurations configured with Uplink Semi-Persistent Scheduling V-RNTI, the UE behaviour is undefined.

In the event of a resource conflict in the same serving cell between the initial transmision within a configured grant bundle from multiple different UL SPS configurations configured with Uplink Semi-Persistent Scheduling C-RNTI, the UE behaviour is undefined.

For NB-IoT UEs, a configured uplink grant shall be used only for BSR or SPS confirmation transmission, and skipUplinkTxSPS is implicitly configured.

5.11 Handling of unknown, unforeseen and erroneous protocol data

When a MAC entity receives a MAC PDU for the MAC entity’s C-RNTI or Semi-Persistent Scheduling C-RNTI, or by the configured downlink assignment, containing reserved or invalid values, the MAC entity shall:

– discard the received PDU.

When a MAC entity receives a MAC PDU on MCH containing reserved values, or on DL-SCH containing reserved values for G-RNTI or SC-RNTI, or on SL-SCH, the MAC entity shall:

– ignore the MAC PDU subheaders containing reserved values and the corresponding MAC SDUs;

– in the MAC control elements, ignore the fields containing reserved values and the fields associated with the fields containing reserved values.

5.12 MCH reception

MCH transmission may occur in subframes configured by upper layer for MCCH or MTCH transmission. For each such subframe, upper layer indicates if signallingMCS or dataMCS applies. The transmission of an MCH occurs in a set of subframes defined by PMCH-Config. An MCH Scheduling Information MAC control element is included in the first subframe allocated to the MCH within the MCH scheduling period to indicate the position of each MTCH and unused subframes on the MCH. If pmch-InfoListExt is configured for an MCH, an Extended MCH Scheduling Information MAC control element is included in the first subframe allocated to the corresponding MCH within the MCH scheduling period to indicate the position of each MTCH and unused subframes on the MCH, and to indicate whether MTCH transmission is to be suspended. The MAC entity shall assume that the first scheduled MTCH starts immediately after the MCCH or the MCH Scheduling Information MAC control element or the Extended MCH Scheduling Information MAC control element if the MCCH is not present, and the other scheduled MTCH(s) start immediately after the previous MTCH, at the earliest in the subframe where the previous MTCH stops. When the MAC entity needs to receive MCH, the MAC entity shall:

– attempt to decode the TB on the MCH;

– if a TB on the MCH has been successfully decoded:

– demultiplex the MAC PDU and deliver the MAC SDU(s) to upper layers.

When the MAC entity receives the Extended MCH Scheduling Information MAC control element, the MAC entity shall indicate the MTCH(s) to be suspended to the upper layers.

NOTE: The MAC entity should continue receiving MCH until the MTCH is removed from the MCCH.

5.13 Activation/Deactivation of SCells

If the MAC entity is configured with one or more SCells, the network may activate and deactivate the configured SCells. The SpCell is always activated. The network activates and deactivates the SCell(s) by sending Activation/Deactivation and/or Hibernation MAC control element(s) described in clause 6.1.3.8 and 6.1.3.15 respectively. Furthermore, the MAC entity maintains a sCellDeactivationTimer timer per configured SCell (except the SCell configured with PUCCH/SPUCCH, if any) and deactivates the associated SCell upon its expiry. In case the sCellHibernationTimer is configured, it takes priority over sCellDeactivationTimer. The same initial timer value applies to each instance of the sCellDeactivationTimer and it is configured by RRC. The configured SCells are initially deactivated upon addition and after a handover unless the parameter sCellState is set to activated or dormant for the SCell within RRC configuration. The configured SCG SCells are initially deactivated after a SCG change unless the parameter sCellState is set to activated or dormant for the SCell within RRC configuration.

The MAC entity shall for each TTI and for each configured SCell:

– if the MAC entity is configured with an activated SCell upon SCell configuration or receives MAC control element(s) in this TTI activating the SCell, the MAC entity shall in the TTI according to the timing defined in TS 36.213 [2]:

– activate the SCell; i.e. apply normal SCell operation including:

– SRS transmissions on the SCell;

– if cqi-ShortConfigSCell is configured:

– CQI/PMI/RI/PTI/CRI reporting for the SCell using the short period of the CSI (CQI/PMI/RI/PTI/CRI) reporting resource configured by cqi-ShortConfigSCell according to the timing defined in TS 36.213 [2].

– else:

– CQI/PMI/RI/PTI/CRI reporting for the SCell using the configuration in cqi-ReportConfigSCell.

– PDCCH monitoring on the SCell;

– PDCCH monitoring for the SCell;

– PUCCH/SPUCCH transmissions on the SCell, if configured.

– start or restart the sCellDeactivationTimer associated with the SCell;

– if sCellHibernationTimer associated with the SCell is configured;

– start or restart the sCellHibernationTimer associated with the SCell.

– trigger PHR according to clause 5.4.6.

– else, if the MAC entity receives MAC control element(s) in this TTI deactivating the SCell; or

– if the sCellDeactivationTimer associated with the activated SCell expires in this TTI and sCellHibernationTimer is not configured:

– in the TTI according to the timing defined in TS 36.213 [2]:

– deactivate the SCell;

– stop the sCellDeactivationTimer associated with the SCell;

– clear any configured downlink assignments and uplink grants associated with the SCell;

– flush all HARQ buffers associated with the SCell.

– if PDCCH on the activated SCell indicates an uplink grant or downlink assignment; or

– if PDCCH on the Serving Cell scheduling the activated SCell indicates an uplink grant or a downlink assignment for the activated SCell; or

– if a MAC PDU is transmitted in a configured uplink grant or received in a configured downlink assignment:

– restart the sCellDeactivationTimer associated with the SCell;

– if sCellHibernationTimer associated with the SCell is configured;

– restart the sCellHibernationTimer associated with the SCell;

– if the SCell is activated and the cqi-ShortConfigSCell expires in this TTI, according to the timing defined in TS 36.213 [2]:

– apply SCell CQI/PMI/RI/PTI/CRI reporting for the SCell using the configuration in cqi-ReportConfigSCell;

– if the SCell is deactivated:

– not transmit SRS on the SCell;

– not report CQI/PMI/RI/PTI/CRI for the SCell;

– not transmit on UL-SCH on the SCell;

– not transmit on RACH on the SCell;

– not monitor the PDCCH on the SCell;

– not monitor the PDCCH for the SCell;

– not transmit PUCCH/SPUCCH on the SCell.

HARQ feedback for the MAC PDU containing Activation/Deactivation MAC control element shall not be impacted by PCell, PSCell and PUCCH SCell interruptions due to SCell activation/deactivation, as specified in TS 36.133 [9].

NOTE: When SCell is deactivated, the ongoing Random Access procedure on the SCell, if any, is aborted.

5.14 SL-SCH Data transfer

5.14.1 SL-SCH Data transmission

5.14.1.1 SL Grant reception and SCI transmission

In order to transmit on the SL-SCH the MAC entity must have at least one sidelink grant.

Sidelink grants are selected as follows for sidelink communication:

– if the MAC entity is configured to receive a single sidelink grant dynamically on the PDCCH and more data is available in STCH than can be transmitted in the current SC period, the MAC entity shall:

– using the received sidelink grant determine the set of subframes in which transmission of SCI and transmission of first transport block occur according to clause 14.2.1 of TS 36.213 [2];

– consider the received sidelink grant to be a configured sidelink grant occurring in those subframes starting at the beginning of the first available SC Period which starts at least 4 subframes after the subframe in which the sidelink grant was received, overwriting a previously configured sidelink grant occurring in the same SC period, if available;

– clear the configured sidelink grant at the end of the corresponding SC Period;

– else, if the MAC entity is configured by upper layers to receive multiple sidelink grants dynamically on the PDCCH and more data is available in STCH than can be transmitted in the current SC period, the MAC entity shall for each received sidelink grant:

– using the received sidelink grant determine the set of subframes in which transmission of SCI and transmission of first transport block occur according to clause 14.2.1 of TS 36.213 [2];

– clear the configured sidelink grant at the end of the corresponding SC Period;

– else, if the MAC entity is configured by upper layers to transmit using one or multiple pool(s) of resources as indicated in clause 5.10.4 of TS 36.331 [8] and more data is available in STCH than can be transmitted in the current SC period, the MAC entity shall for each sidelink grant to be selected:

– if configured by upper layers to use a single pool of resources:

– select that pool of resources for use;

– else, if configured by upper layers to use multiple pools of resources:

– select a pool of resources for use from the pools of resources configured by upper layers whose associated priority list includes the priority of the highest priority of the sidelink logical channel in the MAC PDU to be transmitted;

NOTE 1: If more than one pool of resources has an associated priority list which includes the priority of the sidelink logical channel with the highest priority in the MAC PDU to be transmitted, it is left for UE implementation which one of those pools of resources to select.

– randomly select the time and frequency resources for SL-SCH and SCI of a sidelink grant from the selected resource pool. The random function shall be such that each of the allowed selections (see TS 36.213 [2]) can be chosen with equal probability;

– use the selected sidelink grant to determine the set of subframes in which transmission of SCI and transmission of first transport block occur according to clause 14.2.1 of TS 36.213 [2];

– consider the selected sidelink grant to be a configured sidelink grant occurring in those subframes starting at the beginning of the first available SC Period which starts at least 4 subframes after the subframe in which the sidelink grant was selected;

– clear the configured sidelink grant at the end of the corresponding SC Period;

NOTE 2: Retransmissions on SL-SCH cannot occur after the configured sidelink grant has been cleared.

NOTE 3: If the MAC entity is configured by upper layers to transmit using one or multiple pool(s) of resources as indicated in clause 5.10.4 of TS 36.331 [8], it is left for UE implementation how many sidelink grants to select within one SC period taking the number of sidelink processes into account.

Sidelink grants are selected as follows for V2X sidelink communication:

– if the MAC entity is configured to receive a sidelink grant dynamically on the PDCCH and data is available in STCH, the MAC entity shall for each carrier configured in sl-V2X-ConfigDedicated for which a sidelink grant has been dynamically received on the PDCCH for this TTI:

– use the received sidelink grant to determine the number of HARQ retransmissions and the set of subframes in which transmission of SCI and SL-SCH occur according to clauses 14.2.1 and 14.1.1.4A of TS 36.213 [2];

– consider the received sidelink grant to be a configured sidelink grant for the carrier;

– if the MAC entity is configured by upper layers to receive a sidelink grant on the PDCCH addressed to SL Semi-Persistent Scheduling V-RNTI, the MAC entity shall for each SL SPS configuration and for each carrier configured in sl-V2X-ConfigDedicated for which a sidelink grant has been received on the PDCCH addressed to SL Semi-Persistent Scheduling V-RNTI either for this TTI or for this PDCCH occasion according to clause 3.1 of TS 38.321 [24]:

– if PDCCH contents indicate SPS activation:

– consider the received sidelink grant to be a configured sidelink grant for the carrier.

– if PDCCH contents indicate SPS release:

– clear the corresponding configured sidelink grant for the carrier.

– if the MAC entity is configured by upper layers to transmit using pool(s) of resources in one or multiple carriers as indicated in either clause 5.10.13.1 of TS 36.331 [8] or TS 38.331 [25] based on sensing, or partial sensing, or random selection only if upper layers indicates that transmissions of multiple MAC PDUs are allowed according to either clause 5.10.13.1a of TS 36.331 [8] or TS 38.331 [25], and the MAC entity selects to create a configured sidelink grant corresponding to transmissions of multiple MAC PDUs, and data is available in STCH associated with one or multiple carriers, the MAC entity shall for each Sidelink process configured for multiple transmissions:

– if there is no configured sidelink grant associated with the Sidelink process on any carrier allowed for the STCH as indicated by upper layers, as specified in TS 24.386 [15]:

– trigger the TX carrier (re-)selection procedure as specified in clause 5.14.1.5;

– else if there is a configured sidelink grant associated with the Sidelink process:

– if SL_RESOURCE_RESELECTION_COUNTER = 0 and when SL_RESOURCE_RESELECTION_COUNTER was equal to 1 the MAC entity randomly selected, with equal probability, a value in the interval [0, 1] which is above the probability configured by upper layers in probResourceKeep; or

– if neither transmission nor retransmission has been performed by the MAC entity on any resource indicated in the configured sidelink grant during the last second; or

– if sl-ReselectAfter is configured and the number of consecutive unused transmission opportunities on resources indicated in the configured sidelink grant is equal to sl-ReselectAfter; or

– if none of the configured sidelink grant(s) on the carrier(s) allowed for the STCH have radio resources available in this TTI to accommodate a RLC SDU according to clause 5.14.1.3.1 by using the maximum allowed MCS configured by upper layers in maxMCS-PSSCH and the MAC entity selects not to segment the RLC SDU; or

NOTE 4: If none of the configured sidelink grant(s) on the carrier(s) allowed for the STCH have radio resources available in this TTI to accommodate the RLC SDU according to clause 5.14.1.3.1, it is left for UE implementation whether to perform segmentation or sidelink resource reselection.

– if none of the configured sidelink grant(s) on the carrier(s) allowed for the STCH have radio resources available in this TTI, according to clause 5.14.1.3.1 to fulfil the latency requirement of the data in a sidelink logical channel according to the associated PPPP, and the MAC entity selects not to perform transmission(s) corresponding to a single MAC PDU; or

NOTE 5: If the latency requirement is not met, it is left for UE implementation whether to perform transmission(s) corresponding to single MAC PDU or sidelink resource reselection.

– if the pool of resources where the sidelink grant is configured for the Sidelink process, is reconfigured by upper layers:

– trigger the TX carrier (re-)selection procedure as specified in clause 5.14.1.5;

– clear the configured sidelink grant associated to the Sidelink process;

– flush the HARQ buffer associated to the Sidelink process;

– else if SL_RESOURCE_RESELECTION_COUNTER = 0 and when SL_RESOURCE_RESELECTION_COUNTER was equal to 1 the MAC entity randomly selected, with equal probability, a value in the interval [0, 1] which is less than or equal to the probability configured by upper layers in probResourceKeep:

– clear the configured sidelink grant, if available;

– randomly select, with equal probability, an integer value in the interval [5, 15] for the resource reservation interval higher than or equal to 100ms, in the interval [10, 30] for the resource reservation interval equal to 50ms or in the interval [25, 75] for the resource reservation interval equal to 20ms, and set SL_RESOURCE_RESELECTION_COUNTER to the selected value;

– use the previously selected sidelink grant for the number of transmissions of the MAC PDUs determined in clause 14.1.1.4B of TS 36.213 [2] with the resource reservation interval to determine the set of subframes in which transmissions of SCI and SL-SCH occur according to clauses 14.2.1 and 14.1.1.4B of TS 36.213 [2];

– consider the selected sidelink grant to be a configured sidelink grant;

– if the TX carrier (re-)selection procedure was triggered in above and one or more carriers have been (re-)selected in the Tx carrier (re-)selection according to clause 5.14.1.5:

– determine the order of the (re-)selected carriers, according to the decreasing order based on the highest priority of logical channels which are allowed on each (re-)selected carrier, and perform the following for each Sidelink process on each (re-)selected carrier according to the order:

– select one of the allowed values configured by upper layers in restrictResourceReservationPeriod and set the resource reservation interval by multiplying 100 with the selected value;

NOTE 6: How the UE selects this value is up to UE implementation.

– select the number of HARQ retransmissions from the allowed numbers that are configured by upper layers in allowedRetxNumberPSSCH included in pssch-TxConfigList and, if configured by upper layers, overlapped in allowedRetxNumberPSSCH indicated in cbr-pssch-TxConfigList for the highest priority of the sidelink logical channel(s) allowed on the selected carrier and the CBR measured by lower layers according to TS 36.214 [6] if CBR measurement results are available or the corresponding defaultTxConfigIndex configured by upper layers if CBR measurement results are not available;

– select an amount of frequency resources within the range that is configured by upper layers between minSubchannel-NumberPSSCH and maxSubchannel-NumberPSSCH included in pssch-TxConfigList and, if configured by upper layers, overlapped between minSubchannel-NumberPSSCH and maxSubchannel-NumberPSSCH indicated in cbr-pssch-TxConfigList for the highest priority of the sidelink logical channel(s) allowed on the selected carrier and the CBR measured by lower layers according to TS 36.214 [6] if CBR measurement results are available or the corresponding defaultTxConfigIndex configured by upper layers if CBR measurement results are not available;

– randomly select the time and frequency resources for one transmission opportunity from the resources indicated by the physical layer according to clause 14.1.1.6 of TS 36.213 [2], according to the amount of selected frequency resources. The selected time and frequency resources shall fulfil the physical layer requirements as specified in TS 36.101 [10], and the random function shall be such that each of the allowed selections can be chosen with equal probability;

– use the randomly selected resource to select a set of periodic resources spaced by the resource reservation interval for transmission opportunities of SCI and SL-SCH corresponding to the number of transmission opportunities of MAC PDUs determined in clause 14.1.1.4B of TS 36.213 [2];

– if the number of HARQ retransmissions is equal to 1:

– if there are available resources left in the resources indicated by the physical layer according to clause 14.1.1.6 of TS 36.213 [2] that meet the conditions in clause 14.1.1.7 of TS 36.213 [2] for more transmission opportunities:

– randomly select the time and frequency resources for one transmission opportunity from the available resources, according to the amount of selected frequency resources. The selected time and frequency resources shall fulfil the physical layer requirements as specified in TS 36.101 [10], and the random function shall be such that each of the allowed selections can be chosen with equal probability;

– use the randomly selected resource to select a set of periodic resources spaced by the resource reservation interval for the other transmission opportunities of SCI and SL-SCH corresponding to the number of retransmission opportunities of the MAC PDUs determined in clause 14.1.1.4B of TS 36.213 [2];

– consider the first set of transmission opportunities as the new transmission opportunities and the other set of transmission opportunities as the retransmission opportunities;

– consider the set of new transmission opportunities and retransmission opportunities as the selected sidelink grant.

– else:

– consider the set as the selected sidelink grant;

– use the selected sidelink grant to determine the set of subframes in which transmissions of SCI and SL-SCH occur according to clause 14.2.1 and 14.1.1.4B of TS 36.213 [2];

– consider the selected sidelink grant to be a configured sidelink grant;

– else, if the MAC entity is configured by upper layers to transmit using pool(s) of resources in one or multiple carriers as indicated in either clause 5.10.13.1 of TS 36.331 [8] or TS 38.331 [25], the MAC entity selects to create a configured sidelink grant corresponding to transmission(s) of a single MAC PDU, and data is available in STCH associated with one or multiple carriers, the MAC entity shall for a Sidelink process:

– trigger the TX carrier (re-)selection procedure as specified in clause 5.14.1.5;

– if one or more carriers have been (re-)selected in the Tx carrier (re-)selection according to clause 5.14.1.5:

– randomly select the time and frequency resources for one transmission opportunity of SCI and SL-SCH from the resources indicated by the physical layer according to clause 14.1.1.6 of TS 36.213 [2] , according to the amount of selected frequency resources. The selected time and frequency resources shall fulfil the physical layer requirement as specified in TS 36.101 [10], and the random function shall be such that each of the allowed selections can be chosen with equal probability;

– if the number of HARQ retransmissions is equal to 1:

– if there are available resources left in the resources indicated by the physical layer according to clause 14.1.1.6 of TS 36.213 [2] that meet the conditions in subcause 14.1.1.7 of TS 36.213 [2] for one more transmission opportunity:

– randomly select the time and frequency resources for the other transmission opportunity of SCI and SL-SCH corresponding to additional transmission of the MAC PDU from the available resources, according to the amount of selected frequency resources. The selected time and frequency resources shall fulfil the physical layer requirements as specified in TS 36.101 [10], and the random function shall be such that each of the allowed selections can be chosen with equal probability;

– consider a transmission opportunity which comes first in time as the new transmission opportunity and a transmission opportunity which comes later in time as the retransmission opportunity;

– consider both of the transmission opportunities as the selected sidelink grant;

– else:

– consider the transmission opportunity as the selected sidelink grant;

– use the selected sidelink grant to determine the subframes in which transmission(s) of SCI and SL-SCH occur according to clause 14.2.1 and 14.1.1.4B of TS 36.213 [2];

– consider the selected sidelink grant to be a configured sidelink grant.

NOTE 7: For V2X sidelink communication, the UE should ensure the randomly selected time and frequency resources fulfill the latency requirement.

NOTE 8: For V2X sidelink communication, when there is no overlapping between the chosen configuration(s) in pssch-TxConfigList and chosen configuration(s) indicated in cbr-pssch-TxConfigList, it is up to UE implementation whether the UE transmits and which transmitting parameters the UE uses between allowed configuration(s) indicated in pssch-TxConfigList and allowed configuration(s) indicated in cbr-pssch-TxConfigList.

The MAC entity shall for each subframe:

– for each configured sidelink grant occurring in this subframe:

– if SL_RESOURCE_RESELECTION_COUNTER = 1 for the Sidelink process associated with the configured sidelink grant and the MAC entity randomly selected, with equal probability, a value in the interval [0, 1] which is above the probability configured by upper layers in probResourceKeep:

– set the resource reservation interval for the configured sidelink grant equal to 0;

– if the configured sidelink grant corresponds to transmission of SCI:

– for V2X sidelink communication in UE autonomous resource selection:

– consider the selected transmission format to be SL-V2X-TxProfile for the highest priority of the sidelink logical channel(s) in the MAC PDU (TS 36.331 [8]);

– select a MCS which is, if configured, within the range that is configured by upper layers between minMCS-PSSCH and maxMCS-PSSCH included in pssch-TxConfigList associated with the selected transmission format and, if configured by upper layers, overlapped between minMCS-PSSCH and maxMCS-PSSCH indicated in cbr-pssch-TxConfigList associated with the selected transmission format for the highest priority of the sidelink logical channel(s) in the MAC PDU and the CBR measured by lower layers according to TS 36.214 [6] if CBR measurement results are available or the corresponding defaultTxConfigIndex configured by upper layers if CBR measurement results are not available;

NOTE 9: MCS selection is up to UE implementation if the MCS or the corresponding range is not configured by upper layers.

NOTE 10: For V2X sidelink communication, when there is no overlapping between the chosen configuration(s) included in pssch-TxConfigList and chosen configuration(s) indicated in cbr-pssch-TxConfigList, it is up to UE implementation whether the UE transmits and which transmitting parameters the UE uses between allowed configuration(s) indicated in pssch-TxConfigList and allowed configuration(s) indicated in cbr-pssch-TxConfigList.

– for V2X sidelink communication in scheduled resource allocation:

– consider the selected transmission format to be SL-V2X-TxProfile for the highest priority of the sidelink logical channel(s) in the MAC PDU (TS 36.331 [8]);

– select a MCS which is associated with the selected transmission format unless it is configured by upper layer;

– instruct the physical layer to transmit SCI corresponding to the configured sidelink grant;

– for V2X sidelink communication, deliver the configured sidelink grant, the associated HARQ information and the value of the highest priority of the sidelink logical channel(s) in the MAC PDU to the Sidelink HARQ Entity for this subframe;

– else if the configured sidelink grant corresponds to transmission of first transport block for sidelink communication:

– deliver the configured sidelink grant and the associated HARQ information to the Sidelink HARQ Entity for this subframe.

NOTE 11: If the MAC entity has multiple configured sidelink grants occurring in one subframe and if not all of them can be processed due to the single-cluster SC-FDM restriction, it is left for UE implementation which one of these to process according to the procedure above.

5.14.1.2 Sidelink HARQ operation

5.14.1.2.1 Sidelink HARQ Entity

The MAC entity is configured by upper layers to transmit using pool(s) of resources on one or multiple carriers as indicated in clause 5.10.13.1 of TS 36.331 [8]. For each carrier, there is one Sidelink HARQ Entity at the MAC entity for transmission on SL-SCH, which maintains a number of parallel Sidelink processes.

For sidelink communication, the number of transmitting Sidelink processes associated with the Sidelink HARQ Entity is defined in TS 36.331 [8].

For V2X sidelink communication, the maximum number of transmitting Sidelink processes associated with each Sidelink HARQ Entity is 8. A sidelink process may be configured for transmissions of multiple MAC PDUs. For transmissions of multiple MAC PDUs, the maximum number of transmitting Sidelink processes associated with each Sidelink HARQ Entity is 2.

A delivered and configured sidelink grant and its associated HARQ information are associated with a Sidelink process.

For each subframe of the SL-SCH and each Sidelink process, the Sidelink HARQ Entity shall:

– if a sidelink grant corresponding to a new transmission opportunity has been indicated for this Sidelink process and there is SL data, for sidelink logical channels of ProSe destination associated with this sidelink grant, available for transmission:

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

– deliver the MAC PDU and the sidelink grant and the HARQ information to this Sidelink process;

– instruct this Sidelink process to trigger a new transmission.

– else, if this subframe corresponds to retransmission opportunity for this Sidelink process:

– instruct this Sidelink process to trigger a retransmission.

NOTE: The resources for retransmission opportunities are specified in clause 14.2.1 of TS 36.213 [2] unless specified in clause 5.14.1.1.

5.14.1.2.2 Sidelink process

The Sidelink process is associated with a HARQ buffer.

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 updated modulo 4.

New transmissions and retransmissions either for a given SC period in sidelink communication or in V2X sidelink communication are performed on the resource indicated in the sidelink grant as specified in clause 5.14.1.1 and with the MCS selected as specified in clause 5.14.1.1.

If the sidelink process is configured to perform transmissions of multiple MAC PDUs for V2X sidelink communication the process maintains a counter SL_RESOURCE_RESELECTION_COUNTER. For other configurations of the sidelink process, this counter is not available.

If the Sidelink HARQ Entity requests a new transmission, the Sidelink process shall:

– set CURRENT_IRV to 0;

– store the MAC PDU in the associated HARQ buffer;

– store the sidelink grant received from the Sidelink HARQ Entity;

– generate a transmission as described below.

If the Sidelink HARQ Entity requests a retransmission, the Sidelink process shall:

– generate a transmission as described below.

To generate a transmission, the Sidelink process shall:

– if there is no uplink transmission; or if the MAC entity is able to perform uplink transmissions and transmissions on SL-SCH simultaneously at the time of the transmission; or if there is a MAC PDU to be transmitted in this TTI in uplink, except a MAC PDU obtained from the Msg3 buffer, and transmission of V2X sidelink communication is prioritized over uplink transmission; and

– if there is no Sidelink Discovery Gap for Transmission or no transmission on PSDCH at the time of the transmission; or, in case of transmissions of V2X sidelink communication, if the MAC entity is able to perform transmissions on SL-SCH and transmissions on PSDCH simultaneously at the time of the transmission:

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

– increment CURRENT_IRV by 1;

– if this transmission corresponds to the last transmission of the MAC PDU:

– decrement SL_RESOURCE_RESELECTION_COUNTER by 1, if available.

The transmission of the MAC PDU for V2X sidelink communication is prioritized over uplink transmissions if the following conditions are met:

– if the MAC entity is not able to perform all uplink transmissions and all transmissions of V2X sidelink communication simultaneously at the time of the transmission; and

– if uplink transmission is not prioritized by upper layer according to TS 24.386 [15]; and

– if thresSL-TxPrioritization is configured and the value of the highest priority of the sidelink logical channel(s) in the MAC PDU is lower than thresSL-TxPrioritization.

5.14.1.3 Multiplexing and assembly

For PDU(s) associated with one SCI, MAC shall consider only logical channels with the same Source Layer-2 ID-Destination Layer-2 ID pair.

Multiple transmissions within overlapping SC periods to different ProSe Destinations are allowed subject to single-cluster SC-FDM constraint.

In V2X sidelink communication, multiple transmissions for different Sidelink processes are allowed to be independently performed in different subframes.

5.14.1.3.1 Logical channel prioritization

The Logical Channel Prioritization procedure is applied when a new transmission is performed. Each sidelink logical channel has an associated priority which is the PPPP and optionally an associated PPPR. Multiple sidelink logical channels may have the same associated priority. The mapping between priority and LCID is left for UE implementation. If duplication is activated as specified in TS 36.323 [4], the MAC entity shall map different sidelink logical channels which correspond to the same PDCP entity onto different carriers in accordance with clause 5.14.1.5, or onto different carriers of different carrier sets (if configured in allowedCarrierFreqList for the corresponding destination). For a given sidelink logical channel, it is up to UE implementation which carrier set to select among the carrier sets configured in allowedCarrierFreqList (if configured) for the corresponding destination.

The MAC entity shall perform the following Logical Channel Prioritization procedure either for each SCI transmitted in an SC period in sidelink communication, or for each SCI corresponding to a new transmission in V2X sidelink communication:

– The MAC entity shall allocate resources to the sidelink logical channels in the following steps:

– Only consider sidelink logical channels not previously selected for this SC period and the SC periods (if any) which are overlapping with this SC period, to have data available for transmission in sidelink communication;

– Only consider sidelink logical channels which meet the following conditions:

– allowed on the carrier where the SCI is transmitted for V2X sidelink communication, if the carrier is configured by upper layers according to TS 36.331 [8] and TS 24.386 [15];

– having a priority whose associated threshCBR-FreqReselection is no lower than the CBR of the carrier when the carrier is (re-)selected in accordance with 5.14.1.5;

– Only consider one sidelink logical channel among sidelink logical channels corresponding to same PDCP entity, if duplication is activated as specified in TS 36.323 [4].

– Step 0: Select a ProSe Destination, having the sidelink logical channel with the highest priority, among the sidelink logical channels having data available for transmission and having the same transmission format as the one selected corresponding to the ProSe Destination;

NOTE: The sidelink logical channels belonging to the same ProSe Destination have the same transmission format.

– For each MAC PDU associated to the SCI:

– Step 1: Among the sidelink logical channels belonging to the selected ProSe Destination and having data available for transmission, allocate resources to the sidelink logical channel with the highest priority;

– Step 2: if any resources remain, sidelink logical channels belonging to the selected ProSe Destination are served in decreasing order of priority until either the data for the sidelink logical channel(s) or the SL grant is exhausted, whichever comes first. Sidelink logical channels configured with equal priority should be served equally.

– The UE shall also follow the rules below during the scheduling procedures above:

– the UE should not segment an RLC SDU (or partially transmitted SDU) if the whole SDU (or partially transmitted SDU) fits into the remaining resources;

– if the UE segments an RLC SDU from the sidelink logical channel, it shall maximize the size of the segment to fill the grant as much as possible;

– the UE should maximise the transmission of data;

– if the MAC entity is given a sidelink grant size that is equal to or larger than 10 bytes (for sidelink communication) or 11 bytes (for V2X sidelink communication) while having data available for transmission, the MAC entity shall not transmit only padding.

5.14.1.3.2 Multiplexing of MAC SDUs

The MAC entity shall multiplex MAC SDUs in a MAC PDU according to clauses 5.14.1.3.1 and 6.1.6.

5.14.1.4 Buffer Status Reporting

The sidelink Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of sidelink data available for transmission in the SL buffers associated with the MAC entity. RRC controls BSR reporting for the sidelink by configuring the two timers periodic-BSR-TimerSL and retx-BSR-TimerSL. Each sidelink logical channel belongs to a ProSe Destination. Each sidelink logical channel is allocated to an LCG depending on the priority and optionally the PPPR of the sidelink logical channel, and the mapping between LCG ID and priority and optionally the mapping between LCG ID and PPPR which are provided by upper layers in logicalChGroupInfoList, as specified in TS 36.331 [8]. LCG is defined per ProSe Destination.

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

– if the MAC entity has a configured SL-RNTI or a configured SL-V-RNTI:

– SL data, for a sidelink logical channel of a ProSe Destination, 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 TS 36.322 [3] and TS 36.323 [4] respectively) and either the data belongs to a sidelink logical channel with higher priority than the priorities of the sidelink logical channels which belong to any LCG belonging to the same ProSe Destination and for which data is already available for transmission, or there is currently no data available for transmission for any of the sidelink logical channels belonging to the same ProSe Destination, in which case the Sidelink BSR is referred below to as "Regular Sidelink BSR";

– UL resources are allocated and number of padding bits remaining after a Padding BSR has been triggered is equal to or larger than the size of the Sidelink BSR MAC control element containing the buffer status for at least one LCG of a ProSe Destination plus its subheader, in which case the Sidelink BSR is referred below to as "Padding Sidelink BSR";

– retx-BSR-TimerSL expires and the MAC entity has data available for transmission for any of the sidelink logical channels, in which case the Sidelink BSR is referred below to as "Regular Sidelink BSR";

– periodic-BSR-TimerSL expires, in which case the Sidelink BSR is referred below to as "Periodic Sidelink BSR";

– else:

– An SL-RNTI or an SL-V-RNTI is configured by upper layers and SL data is 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 TS 36.322 [3] and TS 36.323 [4] respectively), in which case the Sidelink BSR is referred below to as "Regular Sidelink BSR".

For Regular and Periodic Sidelink BSR:

– if the number of bits in the UL grant is equal to or larger than the size of a Sidelink BSR containing buffer status for all LCGs having data available for transmission plus its subheader:

– report Sidelink BSR containing buffer status for all LCGs having data available for transmission;

– else report Truncated Sidelink BSR containing buffer status for as many LCGs having data available for transmission as possible, taking the number of bits in the UL grant into consideration.

For Padding Sidelink BSR:

– if the number of padding bits remaining after a Padding BSR has been triggered is equal to or larger than the size of a Sidelink BSR containing buffer status for all LCGs having data available for transmission plus its subheader:

– report Sidelink BSR containing buffer status for all LCGs having data available for transmission;

– else report Truncated Sidelink BSR containing buffer status for as many LCGs having data available for transmission as possible, taking the number of bits in the UL grant into consideration.

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

– if the MAC entity has UL resources allocated for new transmission for this TTI and the allocated UL resources can accommodate a Sidelink BSR MAC control element plus its subheader as a result of logical channel prioritization:

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

– start or restart periodic-BSR-TimerSL except when all the generated Sidelink BSRs are Truncated Sidelink BSRs;

– start or restart retx-BSR-TimerSL;

– else if a Regular Sidelink BSR has been triggered:

– if an uplink grant is not configured:

– a Scheduling Request shall be triggered.

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

The MAC entity shall restart retx-BSR-TimerSL upon reception of an SL grant.

All triggered regular Sidelink BSRs shall be cancelled in case the remaining configured SL grant(s) valid for this SC Period can accommodate all pending data available for transmission in sidelink communication or in case the remaining configured SL grant(s) valid can accommodate all pending data available for transmission in V2X sidelink communication. All triggered Sidelink BSRs shall be cancelled in case the MAC entity has no data available for transmission for any of the sidelink logical channels. All triggered Sidelink BSRs shall be cancelled when a Sidelink BSR (except for Truncated Sidelink BSR) is included in a MAC PDU for transmission. All triggered Sidelink BSRs shall be cancelled, and retx-BSR-TimerSL and periodic-BSR-TimerSL shall be stopped, when upper layers configure autonomous resource selection.

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

All Sidelink 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 Sidelink BSRs reporting buffer status for this LCG.

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

5.14.1.5 TX carrier (re-)selection for V2X sidelink communication

The MAC entity shall consider a CBR of a carrier to be one measured by lower layers according to TS 36.214 [6] if CBR measurement results are available, or the corresponding defaultTxConfigIndex configured by upper layers for the carrier if CBR measurement results are not available.

If the TX carrier (re-)selection is triggered for a Sidelink process according to clause 5.14.1.1, the MAC entity shall:

– if there is no configured sidelink grant on any carrier allowed for the sidelink logical channel where data is available as indicated by upper layers (TS 36.331 [8] and TS 24.386 [15]):

– for each carrier configured by upper layers associated with the concerned sidelink logical channel:

– if the CBR of the carrier is below threshCBR-FreqReselection associated with the priority of the sidelink logical channel:

– consider the carrier as a candidate carrier for TX carrier (re-)selection for the concerned sidelink logical channel.

– else:

– for each sidelink logical channel, if any, where data is available and that are allowed on the carrier for which Tx carrier (re-)selection is triggered according to clause 5.14.1.1:

– if the CBR of the carrier is below threshCBR-FreqKeeping associated with priority of the sidelink logical channel:

– select the carrier and the associated pool of resources.

– else:

– for each carrier configured by upper layers on which the sidelink logical channel is allowed, if the CBR of the carrier is below threshCBR-FreqReselection associated with the priority of the sidelink logical channel;

– consider the carrier as a candidate carrier for TX carrier (re-)selection.

The MAC entity shall:

– if one or more carriers are considered as the candidate carriers for TX carrier (re-)selection:

– for each sidelink logical channel allowed on the carrier where data is available and Tx carrier (re-)selection is triggered:

– select one or more carrier(s) and associated pool(s) of resources among the candidate carriers with increasing order of CBR from the lowest CBR.

NOTE 1: It is left to UE implementation how many carriers to select based on UE capability.

NOTE 2: It is left to UE implementation to determine the sidelink logical channels among the sidelink logical channels where data is available and that are allowed on the carrier for which Tx carrier (re-) selection is triggered.

NOTE 3: If the MAC entity is configured by the upper layer to receive a sidelink grant dynamically on the PDCCH, it is left to UE implementation to determine which carriers configured by upper layer in sl-V2X-ConfigDedicated, as specified in TS 36.331 [8] are considered as selected carriers for the sidelink synchronization procedures in clauses 5.10.7, 5.10.8 and 5.10.8a of TS 36.331 [8].

5.14.2 SL-SCH Data reception

5.14.2.1 SCI reception

SCI transmitted on the PSCCH indicate if there is a transmission on SL-SCH and provide the relevant HARQ information.

The MAC entity shall:

– for each subframe during which the MAC entity monitors PSCCH:

– if SCI for this subframe has been received on the PSCCH for sidelink communication with a Group Destination ID of interest to this MAC entity:

– determine the set of subframes in which reception of the first transport blocks occur according to clause 14.2.2 of TS 36.213 [2] using the received SCI;

– store the SCI and associated HARQ information as SCI valid for the subframes corresponding to first transmission of each transport block;

– else if SCI for this subframe has been received on the PSCCH for V2X sidelink communication:

– determine the set of subframes in which reception of the transport block occur according to clause 14.1.2 of TS 36.213 [2] using the received SCI;

– store the SCI and associated HARQ information as SCI valid for the subframes corresponding to transmission(s) of the transport block;

– for each subframe for which the MAC entity has a valid SCI:

– deliver the SCI and the associated HARQ information to the Sidelink HARQ Entity.

5.14.2.2 Sidelink HARQ operation

5.14.2.2.1 Sidelink HARQ Entity

For each carrier, there is one Sidelink HARQ Entity at the MAC entity for reception of the SL-SCH, which maintains a number of parallel Sidelink processes.

Each Sidelink process is associated with SCI in which the MAC entity is interested. If SCI includes the Group Destination ID, this interest is as determined by the Group Destination ID of the SCI. The Sidelink HARQ Entity directs HARQ information and associated TBs received on the SL-SCH to the corresponding Sidelink processes.

The number of Receiving Sidelink processes associated with the Sidelink HARQ Entity is defined in TS 36.331 [8].

For each subframe of the SL-SCH, the Sidelink HARQ Entity shall:

– for each SCI valid in this subframe:

– allocate the TB received from the physical layer and the associated HARQ information to a Sidelink process, associate this Sidelink process with this SCI and consider this transmission to be a new transmission.

– for each Sidelink process:

– if this subframe corresponds to retransmission opportunity for the Sidelink process according to its associated SCI:

– allocate the TB received from the physical layer and the associated HARQ information to the Sidelink process and consider this transmission to be a retransmission.

5.14.2.2.2 Sidelink process

For each subframe where a transmission takes place for the Sidelink process, one TB and the associated HARQ information is received from the Sidelink HARQ Entity.

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 updated modulo 4.

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

– if this is a new transmission:

– set CURRENT_IRV to 0;

– store the received data in the soft buffer and optionally attempt to decode the received data according to CURRENT_IRV.

– else if this is a retransmission:

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

– increment CURRENT_IRV by 1;

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

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

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

– if the DST field of the decoded MAC PDU subheader is equal to the 16 MSB of any of the Destination Layer-2 ID(s) of the UE for which the 8 LSB are equal to the Group Destination ID in the corresponding SCI:

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

– else if the DST field of the decoded MAC PDU subheader is equal to any of the Destination Layer-2 ID(s) of the UE:

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

5.14.2.3 Disassembly and demultiplexing

The MAC entity shall disassemble and demultiplex a MAC PDU as defined in clause 6.1.6.

5.15 SL-DCH data transfer

5.15.1 SL-DCH data transmission

5.15.1.1 Resource allocation

In order to transmit MAC PDU(s) on SL-DCH, the MAC entity shall for every discovery period and each MAC PDU:

– if the MAC entity is configured by upper layers with a specific grant as specified in TS 36.331 [8]:

– using the specific grant determine the set of subframes in which a transmission of new MAC PDU(s) occur according to clause 14.3.1 of TS 36.213 [2];

– consider the determined set of subframes to be a configured grant for the corresponding discovery period;

– for every subframe, if the MAC entity has a configured grant occurring in that subframe, deliver the configured grant and the MAC PDU to the Sidelink HARQ Entity;

– clear the configured grant at the end of the corresponding discovery period.

NOTE: Mapping between grant and physical resources is specified in clause 9.5.6 of TS 36.211 [7].

– else if the MAC entity is configured with a single pool of resources by upper layers:

– select a random value p1 in the range from 0 to 1, where the random function shall be such that each of the allowed selections can be chosen with equal probability;

– if p1 is less than txProbability:

– select a random resource from the pool of resources (excluding any resources which are overlapping with PRACH or resources belonging to the subframes of resources already selected for transmissions on SL-DCH in this discovery period), where the random function shall be such that each of the allowed selections (see clause 14.3.1 of TS 36.213 [2]) can be chosen with equal probability;

– using the selected resource determine the set of subframes in which the transmission of a MAC PDU can occur according to clause 14.3.1 of TS 36.213 [2]

– consider the determined set of subframes to be a configured grant for the corresponding discovery period;

– for every subframe, if the MAC entity has a configured grant occurring in that subframe, deliver the configured grant and the MAC PDU to the Sidelink HARQ Entity;

– clear the configured grant at the end of the corresponding discovery period.

5.15.1.2 Sidelink HARQ operation

5.15.1.2.1 Sidelink HARQ Entity

There is one Sidelink HARQ Entity at the MAC entity for transmission on SL-DCH, which maintains one Sidelink process for each MAC PDU.

For each subframe of the SL-DCH the Sidelink HARQ Entity shall:

– if a grant and a MAC PDU has been delivered for this subframe to the Sidelink HARQ Entity:

– deliver the MAC PDU and the grant to the Sidelink process;

– instruct the Sidelink process to trigger a new transmission.

– else, if this subframe corresponds to retransmission opportunity for the Sidelink process:

– instruct the Sidelink process to trigger a retransmission.

5.15.1.2.2 Sidelink process

The Sidelink process is associated with a HARQ buffer.

The Sidelink 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. When the Sidelink 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.

The Sidelink process is configured with a maximum number of HARQ retransmissions by RRC: numRetx.

If the Sidelink HARQ Entity requests a new transmission, the Sidelink process shall:

– set CURRENT_TX_NB to 0;

– set CURRENT_IRV to 0;

– store the MAC PDU in the associated HARQ buffer;

– store the grant received from the Sidelink HARQ Entity;

– generate a transmission as described below.

If the Sidelink HARQ Entity requests a retransmission, the Sidelink process shall:

– increment CURRENT_TX_NB by 1;

– generate a transmission as described below.

To generate a transmission, the Sidelink process shall:

– if there is no uplink transmission, no transmission or reception on PSCCH, and no transmission or reception on PSSCH at the time of the transmission; or

– if there is a Sidelink Discovery Gap for Transmission at the time of transmission and if there is a MAC PDU to be transmitted in this TTI in uplink, which is not obtained from the Msg3 buffer:

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

– increment CURRENT_IRV by 1.

After performing above actions, the Sidelink process then shall:

– if CURRENT_TX_NB = numRetx:

– flush the HARQ buffer.

5.15.2 SL-DCH data reception

5.15.2.1 Sidelink HARQ operation

5.15.2.1.1 Sidelink HARQ Entity

There is one Sidelink HARQ Entity at the MAC entity for reception on the SL-DCH which maintains a number of parallel Sidelink processes. The Sidelink HARQ Entity directs HARQ information and associated TBs received on the SL-DCH to the corresponding Sidelink processes.

The number of receiving Sidelink processes per Sidelink HARQ Entity is specified in TS 36.331 [8].

For each subframe of the SL-DCH, the Sidelink HARQ Entity shall:

– receive the TB and the associated HARQ information from the physical layer;

– if this subframe corresponds to a new transmission opportunity:

– allocate the received TB (if any) and the associated HARQ information to a non-running Sidelink process and consider this transmission to be a new transmission.

– else, if this subframe corresponds to a retransmission opportunity:

– allocate the received TB (if any) and the associated HARQ information to its Sidelink process and consider this transmission to be a retransmission.

5.15.2.1.2 Sidelink process

For each subframe where a transmission takes place for the Sidelink process, one TB and the associated HARQ information is received from the Sidelink HARQ Entity.

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 updated modulo 4.

The Sidelink process shall:

– if this subframe corresponds to a new transmission opportunity:

– set CURRENT_IRV to 0;

– else, if this subframe corresponds to a retransmission opportunity:

– increment CURRENT_IRV by 1.

– if a TB was allocated to the Sidelink process:

– if this is a new transmission:

– optionally store the received data in the soft buffer and attempt to decode the received data according to the CURRENT_IRV.

– else if this is a retransmission:

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

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

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

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

– deliver the decoded MAC PDU to upper layers.

5.16 SL-BCH data transfer

5.16.1 SL-BCH data transmission

When instructed to send SL-BCH, the MAC entity shall:

– obtain the MAC PDU to transmit from SBCCH;

– deliver the MAC PDU to the physical layer and instruct it to generate a transmission.

5.16.2 SL-BCH data reception

When the MAC entity needs to receive SL-BCH, the MAC entity shall:

– receive and attempt to decode the SL-BCH;

– if a TB on the SL-BCH has been successfully decoded:

– deliver the decoded MAC PDU to upper layers.

5.17 Data inactivity monitoring

The MAC entity may be configured by RRC with a Data inactivity monitoring functionality, when in RRC_CONNECTED. RRC controls Data inactivity operation by configuring the timer DataInactivityTimer.

When DataInactivityTimer is configured, the MAC entity shall:

– if the MAC entity receives the MAC SDU for DTCH logical channel , DCCH logical channel, or CCCH logical channel; or

– if the MAC entity transmits the MAC SDU for DTCH logical channel, DCCH logical channel;

– start or restart DataInactivityTimer.

– if DataInactivityTimer expires, indicate the expiry of DataInactivityTimer to upper layers.

5.18 Recommended Bit Rate

The recommended bit rate procedure is used to provide the MAC entity with information about the bit rate which the eNB recommends. The bit rate is the recommended bit rate of the physical layer. Averaging window of default value 2000 ms will apply, as specified in TS 26.114 [16].

The eNB may transmit the Recommended bit rate MAC control element to the MAC entity to indicate the recommended bit rate for the UE for a specific logical channel and a specific direction (either uplink or downlink). Upon reception of a Recommended bit rate MAC control element the MAC entity shall:

– indicate to upper layers the recommended bit rate for the indicated logical channel and direction

The MAC entity may request the eNB to indicate the recommended bit rate for a specific logical channel and a specific direction. If the MAC entity is requested by upper layers to query the eNB for the recommended bit rate for a logical channel and for a direction (i.e. for uplink or downlink), the MAC entity shall:

– if a Recommended bit rate query for this logical channel and this direction has not been triggered:

– trigger a Recommended bit rate query for this logical channel, direction, and desired bit rate.

If the MAC entity has UL resources allocated for new transmission for this TTI the MAC entity shall:

– for each Recommended bit rate query that the Recommended Bit Rate procedure determines has been triggered and not cancelled:

– if bitRateQueryProhibitTimer for the logical channel and the direction of this Recommended bit rate query is configured, and it is not running; and

– if the MAC entity has UL resources allocated for new transmission for this TTI and the allocated UL resources can accommodate a Recommended bit rate MAC control element plus its subheader as a result of logical channel prioritization:

– instruct the Multiplexing and Assembly procedure to generate the Recommended bit rate MAC control element for the logical channel and the direction of this Recommended bit rate query;

– start the bitRateQueryProhibitTimer for the logical channel and the direction of this Recommended bit rate query

– cancel this Recommended bit rate query.

5.19 Activation/Deactivation of CSI-RS resources

The network may activate and deactivate the configured CSI-RS resources of a serving cell by sending the Activation/Deactivation of CSI-RS resources MAC control element described in clause 6.1.3.14. The configured CSI-RS resources are initially deactivated upon configuration and after a handover.

The MAC entity shall for each TTI:

– if the MAC entity receives an Activation/Deactivation of CSI-RS resources MAC control element in this TTI on a serving cell, the MAC entity shall indicate to lower layers the information regarding the Activation/Deactivation of CSI-RS resources MAC control element:

5.20 Preallocated uplink grant

When the preallocated uplink grant is configured by RRC, the following information is provided in ul-ConfigInfo:

– Uplink Scheduling interval ul-SchedInterval, starting subframe ul-StartSubframe of the preallocated uplink grant, the uplink grant ul-Grant and the number of HARQ process for the preallocated uplink grant numberOfConfUL-Processes.

When the preallocated uplink grant configuration is released by RRC, the corresponding preallocated uplink grant shall be discarded.

NOTE 1: When eIMTA is configured for the SpCell, if a preallocated grant occurs in a subframe that can be reconfigured through eIMTA L1 signalling, then the UE behaviour is left unspecified.

If ul-ConfigInfo is configured, the MAC entity shall:

– consider sequentially that the N^th grant occurs in the subframe for which:

– subframe = [N * ul-SchedInterval + ul-StartSubframe] modulo 10.

For TDD, the MAC entity is configured with ul-SchedInterval shorter than 10 subframes, the N^th grant shall be ignored if it occurs in a downlink subframe or a special subframe.

NOTE 2: Retransmissions for uplink transmissions using the preallocated uplink grant can continue after clearing the preallocated uplink grant.

5.21 SC-PTM Stop Indication

For NB-IoT UEs, BL UEs or UEs in enhanced coverage, the eNB may transmit the SC-PTM Stop Indication MAC control element to the MAC entity to indicate that the transmission of SC-MTCH associated with a G-RNTI is stopped as described in clause 6.1.3.12.

Upon reception of the SC-PTM Stop Indication MAC control element associated with a G-RNTI, the MAC entity shall:

– stop monitoring the PDCCH for this G-RNTI;

– indicate to upper layers that the associated MBMS session is stopped.

5.22 Entering Dormant SCell state

If the MAC entity is configured with one or more SCells, the network may transition configured SCells into Dormant State. Dormant State is not applicable for SpCell or PUCCH SCell. The network transitions SCell(s) in and out of Dormant State by sending Activation/Deactivation and/or Hibernation MAC control element as described in clause 6.1.3.8 and 6.1.3.15 respectively.

Furthermore, the MAC entity maintains two timers related to the dormant state:

– If configured, an sCellHibernationTimer timer per configured SCell (except the SCell configured with PUCCH, if any). Upon the timer expiry, the MAC entity hibernates the associated SCell if it is in activated state. The same initial timer value applies to each instance of the sCellHibernationTimer and it is configured by RRC.

– If configured, a dormantSCellDeactivationTimer per configured SCell (except the SCell configured with PUCCH, if any). Upon the timer expiry, the MAC entity deactivates the associated SCell if it is in dormant state. The same initial timer value applies to each instance of the dormantSCellDeactivationTimer and it is configured by RRC.

An SCell will be in Dormant SCell state upon SCell configuration in case the parameter sCellState is set to dormant for the SCell within RRC configuration. The configured SCG SCells are dormant after a SCG change in case the parameter sCellState is set to dormant for the SCell within RRC configuration.

The MAC entity shall for each TTI and for each configured SCell:

– if the MAC entity is configured with dormant SCell upon SCell configuration or receives MAC control element(s) in this TTI for transitioning the SCell into Dormant State:

– in the TTI according to the timing defined in TS 36.213 [2]:

– transition the SCell into Dormant State;

– stop the sCellDeactivationTimer associated with the SCell;

– if sCellHibernationTimer associated with the SCell is configured;

– stop the sCellHibernationTimer associated with the SCell;

– start or restart the dormantSCellDeactivationTimer associated with the SCell;

– clear any configured downlink assignments and uplink grants associated with the SCell;

– flush all HARQ buffers associated with the SCell.

– if the sCellHibernationTimer associated with the activated SCell expires in this TTI:

– in the TTI according to the timing defined in TS 36.213 [2]:

– hibernate the SCell;

– stop the sCellDeactivationTimer associated with the SCell;

– stop the sCellHibernationTimer associated with the SCell;

– start the dormantSCellDeactivationTimer associated with the SCell;

– clear any configured downlink assignments and uplink grants associated with the SCell;

– flush all HARQ buffers associated with the SCell.

– if the dormantSCellDeactivationTimer associated with the dormant SCell expires in this TTI:

– in the TTI according to the timing defined in TS 36.213 [2]:

– deactivate the SCell;

– stop the dormantSCellDeactivationTimer associated with the SCell;

– if the SCell is in Dormant State:

– not transmit SRS on the SCell;

– report CQI/PMI/RI/PTI/CRI for the SCell according to the periodicity indicated by cqi-ReportPeriodic-SCell-r15;

– not transmit on UL-SCH on the SCell;

– not transmit on RACH on the SCell;

– not monitor the PDCCH on the SCell;

– not monitor the PDCCH for the SCell;

– not transmit PUCCH on the SCell.

HARQ feedback for the MAC PDU containing Hibernation MAC control element shall not be impacted by PCell, PSCell and PUCCH SCell interruptions due to SCell activation/deactivation or hibernation (TS 36.133 [9]).

NOTE: When SCell is in Dormant State, any ongoing Random Access procedure on the SCell is aborted.

5.23 Autonomous Uplink

Autonomous uplink is supported on the SCells only. At most one autonomous uplink configuration is supported per SCell. Multiple autonomous uplink configurations can be activated and be active simultaneously when there is more than one SCell. Autonomous uplink and Uplink Semi-Persistent Scheduling cannot be active simultaneously on the same SCell.

When autonomous uplink is configured by RRC, the following information is provided in AUL-Config (TS 36.331 [8]):

– AUL C-RNTI;

– HARQ process IDs aul-HARQ-Processes that are configured for autonomous UL HARQ operation, the time period aul-RetransmissionTimer before triggering a new transmission or a retransmission of the same HARQ process using autonomous uplink;

– The bitmap aul-Subframes that indicates the subframes that are configured for autonomous UL HARQ operation.

When the autonomous uplink configuration is released by RRC, the corresponding configured grant shall be cleared.

If AUL-Config is configured, the MAC entity shall:

– consider that a configured uplink grant occurs in those subframes for which aul-Subframes is set to 1 (TS 36.331 [8]).

If AUL confirmation 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 an AUL confirmation MAC Control Element as defined in clause 6.1.3.16;

– cancel the triggered AUL confirmation.

The MAC entity shall clear the configured uplink grant for the SCell immediately after first transmission of AUL confirmation MAC Control Element triggered by the AUL release for this SCell.

NOTE: Retransmissions for uplink transmissions using autonomous uplink can continue after clearing the corresponding configured uplink grant.

5.24 Activation/Deactivation of PDCP duplication

If one or more DRBs are configured with PDCP duplication, the network may activate and deactivate the PDCP duplication for the configured DRB(s) by sending the PDCP Duplication Activation/Deactivation MAC CE described in clause 6.1.3.17. In addition, PDCP duplication for DRB(s) may be activated upon configuration by upper layers (TS 36.331 [8]).

Upon reception of a PDCP Duplication Activation/Deactivation MAC CE, the MAC entity shall for each DRB configured with duplication:

– if the MAC CE indicates that PDCP duplication for the DRB shall be activated:

– indicate the activation of PDCP duplication for the DRB to upper layers.

– if the MAC CE indicates that PDCP duplication for the DRB shall be deactivated:

– indicate the deactivation of PDCP duplication for the DRB to upper layers.

5.25 Transmission of Downlink Channel Quality Report

The MAC entity of a BL UE or UE in enhanced coverage may be configured by upper layers to report DL channel quality in Msg3. DL channel quality in Msg3 in RRC_CONNECTED is not reported.

If the UE is a BL UE or UE in enhanced coverage or an NB-IoT UE, a Downlink Channel Quality Report (DCQR) shall be triggered if any of the following events occur:

– DCQR Command MAC control element is received, in which case the DCQR is referred below to as "Regular DCQR";

– for BL UE or UE in enhanced coverage, transmission of DCQR in Msg3 is configured by upper layers in mpdcch-CQI-Reporting, in which case DCQR is referred below to as "Msg3 DCQR".

If any type of DCQR has been triggered:

– start performing DL channel quality measurements according to TS 36.133 [9].

If "Regular DCQR" has been triggered:

– if an uplink grant has been received on the PDCCH for MAC entity’s C-RNTI:

– instruct the Multiplexing and Assembly procedure to generate a DCQR and AS RAI MAC control element as defined in clause 6.1.3.19;

– cancel the triggered "Regular DCQR".

If "Msg3 DCQR" has been triggered:

– if an uplink grant has been received on the PDCCH for MAC entity’s RA-RNTI:

– if the allocated resources can accommodate a DCQR and AS RAI MAC control element plus its subheader as a result of logical channel prioritization:

– instruct the Multiplexing and Assembly procedure to generate a DCQR and AS RAI MAC control element as defined in clause 6.1.3.19;

– else if the uplink grant is not for EDT:

– if configured by upper layers in mpdcch-CQI-Reporting, use R and F2 fields in the MAC PDU subheader, to transmit the measurement outcome, as defined in clause 6.2.1;

– cancel the triggered "Msg3 DCQR".

5.26 Update of Differential Koffset

The network may provide and update the Differential Koffset of a Serving Cell in a non-terrestrial network by sending the Differential Koffset MAC CE described in clause 6.1.3.21.

The MAC entity shall:

– if the MAC entity receives a Differential Koffset MAC CE on a Serving Cell:

– indicate to lower layers the information regarding the Differential Koffset MAC CE.