Content for  TS 38.321  Word version:  18.3.0

The Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission. The MAC entity may be configured with zero, one, or more SR configurations. An SR configuration consists of a set of PUCCH resources for SR across different BWPs and cells. For a logical channel or for SCell beam failure recovery (see clause 5.17) and for consistent LBT failure recovery (see clause 5.21), at most one PUCCH resource for SR is configured per BWP. For a logical channel serving a radio bearer configured with SDT, PUCCH resource for SR is not configured for SDT. For beam failure recovery of BFD-RS set(s) of Serving Cell, up to two PUCCH resources for SR is configured per BWP. For positioning measurement gap activation/deactivation request, a dedicated SR configuration is configured. Each SR configuration corresponds to one or more logical channels and/or to SCell beam failure recovery and/or to consistent LBT failure recovery and/or to beam failure recovery of a BFD-RS set and/or to positioning measurement gap activation/deactivation request. Each logical channel, SCell beam failure recovery, beam failure recovery of a BFD-RS set and consistent LBT failure recovery, may be mapped to zero or one SR configuration, which is configured by RRC. The SR configuration of the logical channel that triggered a BSR (clause 5.4.5) or a DSR (clause 5.4.9) or the SCell beam failure recovery or the beam failure recovery of a BFD-RS set or the consistent LBT failure recovery (clause 5.21) (if such a configuration exists) or positioning measurement gap activation/deactivation request (clause 5.25) is considered as corresponding SR configuration for the triggered SR. Any SR configuration may be used for an SR triggered by Pre-emptive BSR (clause 5.4.7) or Timing Advance reporting (clause 5.4.8). RRC configures the following parameters for the scheduling request procedure:

• sr-ProhibitTimer (per SR configuration);
• sr-TransMax (per SR configuration).

The following UE variables are used for the scheduling request procedure:

• SR_COUNTER (per SR configuration).

If an SR is triggered and there are no other SRs pending corresponding to the same SR configuration, the MAC entity shall set the SR_COUNTER of the corresponding SR configuration to 0. When an SR is triggered, it shall be considered as pending until it is cancelled. All pending SR(s) for BSR triggered according to the BSR procedure (clause 5.4.5) prior to the MAC PDU assembly shall be cancelled and each respective sr-ProhibitTimer shall be stopped when the MAC PDU is transmitted and this PDU includes a Long, Refined Long or Short BSR MAC CE which contains buffer status up to (and including) the last event that triggered a BSR (see clause 5.4.5) prior to the MAC PDU assembly. All pending SR(s) for BSR triggered according to the BSR procedure (clause 5.4.5) shall be cancelled and each respective sr-ProhibitTimer shall be stopped when the UL grant(s) can accommodate all pending data available for transmission. The MAC entity shall for each pending SR not triggered according to the BSR procedure (clause 5.4.5) for a Serving Cell: Only PUCCH resources on a BWP which is active at the time of SR transmission occasion are considered valid. As long as at least one SR is pending, the MAC entity shall for each pending SR: The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for BSR, which was initiated by the MAC entity prior to the MAC PDU assembly and which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU includes a BSR MAC CE which contains buffer status up to (and including) the last event that triggered a BSR (see clause 5.4.5) prior to the MAC PDU assembly; or
• the UL grant(s) can accommodate all pending data available for transmission.

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for SL-BSR, which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and the ongoing Random Access procedure was initiated by the MAC entity prior to the MAC PDU assembly, and this PDU includes an SL-BSR MAC CE which contains buffer status up to (and including) the last event that triggered an SL-BSR (see clause 5.22.1.6) prior to the MAC PDU assembly; or
• the SL grant(s) can accommodate all pending data available for transmission, and the ongoing Random Access procedure was initiated by the MAC entity prior to the sidelink MAC PDU assembly.

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for SL-CSI reporting, which has no valid PUCCH resources configured, if:

• the SL grant can accommodate SL-CSI reporting MAC CE for transmission.

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for SL-DRX command indication, which has no valid PUCCH resources configured, if:

• the SL grant can accommodate SL-DRX command indication for transmission.

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for BFR of an SCell, which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU contains a MAC CE for BFR which includes beam failure recovery information of that SCell; or
• the SCell is deactivated (as specified in clause 5.9) and all triggered BFRs for SCells are cancelled.

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for BFR of a BFD-RS set of a Serving Cell, which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU contains an Enhanced BFR MAC CE or a Truncated Enhanced BFR MAC CE which includes beam failure recovery information of that BFD-RS set of the Serving Cell.

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for consistent LBT failure recovery, which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU includes an LBT failure MAC CE that indicates consistent LBT failure for all the SCells that triggered consistent LBT failure; or
• all the SCells that triggered consistent LBT failure recovery are deactivated (see clause 5.9).

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for Sidelink consistent LBT failure recovery, which has no valid PUCCH resources configured, if one of the following conditions is met:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU includes an SL LBT failure MAC CE that indicates Sidelink consistent LBT failure; or
• all the triggered Sidelink consistent LBT failure recovery are cancelled (see clause 5.31.2).

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for positioning measurement gap activation/deactivation request, which has no valid PUCCH resources configured, if:

• the Positioning Measurement Gap Activation/Deactivation Request MAC CE that triggers the SR corresponding to the Random Access procedure has already been cancelled.

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for Timing Advance report, which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU includes a Timing Advance Report MAC CE (see clause 5.4.8).

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for DSR, which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU includes either a DSR MAC CE or
• all the PDCP SDUs associated with the DSR (see clause 5.4.9); or
• all the PDCP SDUs associated with the DSR have been discarded (see clause 5.4.9).

The MAC entity may stop, if any, ongoing Random Access procedure due to a pending SR for SL-PRS Resource Request, which has no valid PUCCH resources configured, if:

• a MAC PDU is transmitted using a UL grant other than a UL grant provided by Random Access Response or a UL grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload, and this PDU includes a SL-PRS Resource Request MAC CE (see clause 5.22.1.12).

The Buffer Status reporting (BSR) procedure is used to provide the serving gNB with information about UL data volume in the MAC entity. RRC configures the following parameters to control the BSR:

• periodicBSR-Timer;
• retxBSR-Timer;
• logicalChannelSR-DelayTimerApplied;
• logicalChannelSR-DelayTimer;
• logicalChannelSR-Mask;
• logicalChannelGroup, logicalChannelGroupIAB-Ext;
• sdt-LogicalChannelSR-DelayTimer;
• additionalBS-TableAllowed.

Each logical channel may be allocated to an LCG using the logicalChannelGroup. The maximum number of LCGs is eight except for IAB-MTs configured with logicalChannelGroupIAB-Ext, for which the maximum number of LCGs is 256. The MAC entity determines the amount of UL data available for a logical channel according to the data volume calculation procedure in TS 38.322 and TS 38.323. A BSR shall be triggered if any of the following events occur for activated cell group:

• UL data, for a logical channel which belongs to an LCG, becomes available to the MAC entity; and either
• this UL data belongs to a logical channel with higher priority than the priority of any logical channel containing available UL data which belong to any LCG; or
• none of the logical channels which belong to an LCG contains any available UL data.

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 CE plus its subheader, in which case the BSR is referred below to as 'Padding BSR';
• retxBSR-Timer expires, and at least one of the logical channels which belong to an LCG contains UL data, 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, the MAC entity shall: For Regular and Periodic BSR, the MAC entity for which logicalChannelGroupIAB-Ext is not configured by upper layers shall: For Regular and Periodic BSR, the MAC entity for which logicalChannelGroupIAB-Ext is configured by upper layers shall: For Padding BSR, the MAC entity for which logicalChannelGroupIAB-Ext is not configured by upper layers shall: For Padding BSR, the MAC entity for which logicalChannelGroupIAB-Ext is configured by upper layers shall: For BSR triggered by retxBSR-Timer expiry, the MAC entity considers that the logical channel that triggered the BSR is the highest priority logical channel that has data available for transmission at the time the BSR is triggered. The MAC entity shall: A MAC PDU shall contain at most one BSR MAC CE, even when multiple events have triggered a BSR. The Regular BSR and the Periodic BSR shall have precedence over the padding BSR. The MAC entity shall restart retxBSR-Timer upon reception of a grant for transmission of new data on any UL-SCH. All triggered BSRs may be cancelled when the UL grant(s) can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the BSR MAC CE plus its subheader. All BSRs triggered prior to MAC PDU assembly shall be cancelled when a MAC PDU is transmitted and this PDU includes a Long, Refined Long, Extended Long, Short, or Extended Short BSR MAC CE which contains buffer status up to (and including) the last event that triggered a BSR prior to the MAC PDU assembly.

The Power Headroom reporting procedure is used to provide the serving gNB with the following information:

• Type 1 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for UL-SCH transmission per activated Serving Cell;
• Type 2 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for UL-SCH and PUCCH transmission on SpCell of the other MAC entity (i.e. E-UTRA MAC entity in EN-DC, NE-DC, and NGEN-DC cases);
• Type 3 power headroom: the difference between the nominal UE maximum transmit power and the estimated power for SRS transmission per activated Serving Cell;
• MPE P-MPR: the power backoff to meet the MPE FR2 requirements for a Serving Cell operating on FR2;
• DPC: the adjustment to maximum output power for a given power class for a Serving Cell operating on FR1;
• DPC_BC: the adjustment to maximum output power for a given power class for a Band Combination operating on FR1.

RRC controls Power Headroom reporting by configuring the following parameters:

• dpc-Reporting-FR1;
• phr-AssumedPUSCH-Reporting;
• phr-PeriodicTimer;
• phr-ProhibitTimer;
• phr-Tx-PowerFactorChange;
• phr-Type2OtherCell;
• phr-ModeOtherCG;
• multiplePHR;
• mpe-Reporting-FR2;
• mpe-ProhibitTimer;
• mpe-Threshold;
• numberOfN;
• mpe-ResourcePoolToAddModList;
• twoPHRMode.

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

• phr-ProhibitTimer expires or has expired and the path loss has changed more than phr-Tx-PowerFactorChange dB for at least one RS used as pathloss reference for one activated Serving Cell of any MAC entity of which the active DL BWP is not dormant BWP since the last transmission of a PHR in this MAC entity when the MAC entity has UL resources for new transmission;
• phr-PeriodicTimer expires;
• upon configuration or reconfiguration of the power headroom reporting functionality by upper layers, which is not used to disable the function;
• activation of an SCell of any MAC entity with configured uplink of which firstActiveDownlinkBWP-Id is not set to dormant BWP;
• activation of an SCG;
• addition of the PSCell except if the SCG is deactivated (i.e. PSCell is newly added or changed);
• phr-ProhibitTimer expires or has expired, when the MAC entity has UL resources for new transmission, and the following is true 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 transmission on this cell, and the required power backoff due to power management (as allowed by P-MPRc as specified in TS 38.101-1, TS 38.101-2, and TS 38.101-3) for this cell has changed more than phr-Tx-PowerFactorChange dB since the last transmission of a PHR when the MAC entity had UL resources allocated for transmission or PUCCH transmission on this cell.
• Upon switching of activated BWP from dormant BWP to non-dormant DL BWP of an SCell of any MAC entity with configured uplink;
• if dpc-Reporting-FR1 is configured, ΔP_PowerClass / ΔP_{PowerClass, CA} / ΔP_{PowerClass, EN-DC} / ΔP_{PowerClass, NR-DC} reporting is triggered upon uplink duty cycle exceedance or upon return to the power class after the duty cycle exceedance, as specified in TS 38.101-1 and TS 38.101-3).
• if mpe-Reporting-FR2 is configured, and mpe-ProhibitTimer is not running:
  • the measured P-MPR applied to meet FR2 MPE requirements as specified in TS 38.101-2 is equal to or larger than mpe-Threshold for at least one activated FR2 Serving Cell since the last transmission of a PHR in this MAC entity; or
  • the measured P-MPR applied to meet FR2 MPE requirements as specified in TS 38.101-2 has changed more than phr-Tx-PowerFactorChange dB for at least one activated FR2 Serving Cell since the last transmission of a PHR due to the measured P-MPR applied to meet MPE requirements being equal to or larger than mpe-Threshold in this MAC entity.
  in which case the PHR is referred below to as 'MPE P-MPR report'.

If the MAC entity has UL resources allocated for a new transmission the MAC entity shall: All triggered PHRs shall be cancelled when there is an ongoing SDT procedure as in clause 5.27 and the UL grant(s) can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the PHR MAC CE plus its subheader.

The Pre-emptive Buffer Status reporting (Pre-emptive BSR) procedure is used by an IAB-MT to provide its parent IAB-DU(s) or IAB-donor-DU(s) with the information about the amount of the data expected to arrive at the IAB-MT from its child node(s) and/or UE(s) connected to it. If configured, Pre-emptive BSR may be triggered for the specific case of an IAB-MT if any of the following events occur:

• UL grant is provided to child IAB node or UE;
• BSR is received from child IAB node or UE.

IAB-MT may report Extended Pre-emptive BSR (as defined in clause 6.1.3.1) if the MAC entity of the IAB-MT is configured with logicalChannelGroupIAB-Ext by upper layers. Otherwise IAB-MT may report Pre-emptive BSR (as defined in clause 6.1.3.1). The MAC entity shall: A MAC PDU shall contain at most one Pre-emptive BSR MAC CE or Extended Pre-emptive BSR MAC CE, even when multiple events have triggered a Pre-emptive BSR. All triggered Pre-emptive BSR(s) shall be cancelled when a MAC PDU is transmitted and this PDU includes the corresponding Pre-emptive BSR MAC CE or Extended Pre-emptive BSR MAC CE.

The Timing Advance reporting procedure is used in a non-terrestrial network or an air to ground network to provide the gNB with an estimate of the UE's Timing Advance value (i.e., TTA as defined in the UE's TA formula, see clause 4.3.1 of TS 38.211). RRC controls Timing Advance reporting by configuring the following parameters:

• offsetThresholdTA;
• timingAdvanceSR.

A Timing Advance report (TAR) shall be triggered if any of the following events occur:

• upon indication from upper layers to trigger a Timing Advance report;
• 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 the current estimate of the Timing Advance value and the last reported Timing Advance value is equal to or larger than offsetThresholdTA, if configured.

The MAC entity shall: A MAC PDU shall contain at most one Timing Advance Report MAC CE, even when multiple events have triggered a Timing Advance report. The Timing Advance Report MAC CE shall be generated based on the latest available estimate of the UE's Timing Advance value prior to the MAC PDU assembly. All triggered Timing Advance reports shall be cancelled when a MAC PDU is transmitted and this PDU includes a Timing Advance Report MAC CE.

The Delay Status Reporting (DSR) procedure is used to provide the serving gNB with delay status of LCGs. This delay status for an LCG includes remaining time, which is the smallest remaining value of the running PDCP discardTimers among PDCP SDUs that are buffered for the LCG but have not been transmitted in any MAC PDU as specified in clause 7.3 of TS 38.323, and the total amount of delay-critical UL data for the LCG according to the data volume calculation procedure specified in clause 5.5 in TS 38.322 and clause 5.15 in TS 38.323 for the associated RLC and PDCP entities, respectively. RRC controls the DSR procedure by configuring the following parameter:

• remainingTimeThreshold (per LCG): the threshold on remaining time for triggering a DSR for a logical channel within an LCG.

If an LCG is configured for delay status reporting, the MAC entity shall for each logical channel within the LCG: If there is at least one DSR pending, the MAC entity shall: A PDCP SDU is considered to be associated with a DSR if it has not been transmitted in any MAC PDU and is a delay-critical PDCP SDU (as defined in TS 38.323) associated with the logical channel which triggered the DSR. A MAC PDU shall contain at most one DSR MAC CE. A MAC PDU shall not contain a DSR MAC CE if it includes all PDCP SDUs associated with all the pending DSRs. After a DSR is triggered, it is considered as pending until it is cancelled. The MAC entity shall cancel a pending DSR, when all the PDCP SDUs associated with the DSR have been discarded, or when a MAC PDU is transmitted and this MAC PDU includes a DSR MAC CE that contains the delay information of all the PDCP SDUs associated with the DSR (as described in the clause 6.1.3.72), or when a MAC PDU is transmitted and this MAC PDU includes all the PDCP SDUs associated with the DSR.