Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 38.321  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.1.2…   5.2…   5.4…   5.4.4…   5.5…   5.9…   5.18…   5.18.18…   5.19…   5.22…   5.22.1.4…   5.22.2…   5.23…   6…   6.1.3…   6.1.3.8…   6.1.3.11…   6.1.3.17…   6.1.3.21…   6.1.3.26…   6.1.3.31…   6.1.3.37…   6.1.3.42…   6.1.3.49…   6.1.3.53…   6.1.3.59…   6.1.3.64…   6.1.3.70…   6.1.3.74…   6.1.3.79…   6.1.4…   6.2…   7…

 

5.4.4  Scheduling Requestp. 73

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:
1 >
if this SR was triggered by Pre-emptive BSR procedure (see clause 5.4.7) prior to the MAC PDU assembly and a MAC PDU containing the relevant Pre-emptive BSR MAC CE is transmitted; or
1 >
if this SR was triggered by beam failure recovery (see clause 5.17) of an SCell and a MAC PDU is transmitted and this PDU includes a MAC CE for BFR which contains beam failure recovery information for this SCell; or
1 >
if this SR was triggered by beam failure recovery (see clause 5.17) for a BFD-RS set of a Serving Cell and a MAC PDU is transmitted and this PDU includes an Enhanced BFR MAC CE or a Truncated Enhanced BFR MAC CE which contains beam failure recovery information for this BFD-RS set of the Serving Cell; or
1 >
if this SR was triggered by beam failure recovery (see clause 5.17) of an SCell and this SCell is deactivated (see clause 5.9); or
1 >
if this SR was triggered by beam failure recovery (see clause 5.17) for a BFD-RS set of an SCell and this SCell is deactivated (see clause 5.9); or
1 >
if the SR is triggered by positioning measurement gap activation/deactivation request (see clause 5.25) and the Positioning Measurement Gap Activation/Deactivation Request MAC CE that triggers the SR has already been cancelled; or
1 >
if this SR was triggered by consistent LBT failure recovery (see clause 5.21) of an SCell and a MAC PDU is transmitted and the MAC PDU includes an LBT failure MAC CE that indicates consistent LBT failure for this SCell; or
1 >
if this SR was triggered by consistent LBT failure recovery (see clause 5.21) of an SCell and all the triggered consistent LBT failure(s) for this SCell are cancelled; or
1 >
if this SR was triggered by Timing Advance reporting (see clause 5.4.8) and all the triggered Timing Advance reports are cancelled; or
1 >
if this SR was triggered by DSR procedure (see clause 5.4.9) and the DSR that triggered the SR has been cancelled:
2 >
cancel the pending SR and stop the corresponding sr-ProhibitTimer, if running.
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:
1 >
if the MAC entity has no valid PUCCH resource configured for the pending SR; and
1 >
if there is no ongoing LTM cell switch; and
1 >
if rach-lessHO is not configured:
2 >
initiate a Random Access procedure (see clause 5.1) on the SpCell and cancel the pending SR.
1 >
else, for the SR configuration corresponding to the pending SR:
2 >
when the MAC entity has an SR transmission occasion on the valid PUCCH resource for SR configured; and
2 >
if sr-ProhibitTimer is not running at the time of the SR transmission occasion; and
2 >
if the PUCCH resource for the SR transmission occasion does not overlap with a measurement gap:
3 >
if the PUCCH resource for the SR transmission occasion overlaps with neither a UL-SCH resource whose simultaneous transmission with the SR is not allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCH-Groups nor an SL-SCH resource; or
3 >
if the MAC entity is able to perform this SR transmission simultaneously with the transmission of the SL-SCH resource; or
3 >
if the MAC entity is configured with lch-basedPrioritization, and the PUCCH resource for the SR transmission occasion does not overlap with the PUSCH duration of an uplink grant received in a Random Access Response or with the PUSCH duration of an uplink grant addressed to Temporary C-RNTI or with the PUSCH duration of a MSGA payload, and the PUCCH resource for the SR transmission occasion for the pending SR triggered as specified in clause 5.4.5 overlaps with any other UL-SCH resource(s), and the physical layer can signal the SR on one valid PUCCH resource for SR, and the priority of the logical channel that triggered SR is higher than the priority of the uplink grant(s) for any UL-SCH resource(s) where the uplink grant was not already de-prioritized and its simultaneous transmission with the SR is not allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCHgroups, and the priority of the uplink grant is determined as specified in clause 5.4.1; or
3 >
if both sl-PrioritizationThres and ul-PrioritizationThres are configured and the PUCCH resource for the SR transmission occasion for the pending SR triggered as specified in clause 5.22.1.5 overlaps with any UL-SCH resource(s) carrying a MAC PDU, and the value of the priority of the triggered SR determined as specified in clause 5.22.1.5 is lower than sl-PrioritizationThres and the value of the highest priority of the logical channel(s) in the MAC PDU is higher than or equal to ul-PrioritizationThres and any MAC CE prioritized as described in clause 5.4.3.1.3 is not included in the MAC PDU and the MAC PDU is not prioritized by upper layer according to TS 23.287; or
3 >
if an SL-SCH resource overlaps with the PUCCH resource for the SR transmission occasion for the pending SR triggered as specified in clause 5.4.5, and the MAC entity is not able to perform this SR transmission simultaneously with the transmission of the SL-SCH resource, and either transmission on the SL-SCH resource is not prioritized as described in clause 5.22.1.3.1a or the priority value of the logical channel that triggered SR is lower than ul-PrioritizationThres, if configured; or
3 >
if an SL-SCH resource overlaps with the PUCCH resource for the SR transmission occasion for the pending SR triggered as specified in clause 5.22.1.5, and the MAC entity is not able to perform this SR transmission simultaneously with the transmission of the SL-SCH resource, and the priority of the triggered SR determined as specified in clause 5.22.1.5 is higher than the priority of the MAC PDU determined as specified in clause 5.22.1.3.1a for the SL-SCH resource; or
3 >
if an SL-PRS resource overlaps with the PUCCH resource for the SR transmission occasion for the pending SR triggered as specified in clause 5.4.5, and the MAC entity is not able to perform this SR transmission simultaneously with the transmission of the SL-PRS resource, and either transmission on the SL-PRS resource is not prioritized as described in clause 5.22.1.3.1a or 5.22.1.3.1b or the priority value of the logical channel that triggered SR is lower than ul-PrioritizationThres, if configured; or
3 >
if an SL-PRS resource overlaps with the PUCCH resource for the SR transmission occasion for the pending SR triggered as specified in clause 5.22.1.5, and the MAC entity is not able to perform this SR transmission simultaneously with the transmission of the SL-PRS resource, and the priority of the triggered SR determined as specified in clause 5.22.1.5 is higher than the priority of the MAC PDU and SL-PRS, if available, determined as specified in clause 5.22.1.3.1a for the SL-PRS resource:
4 >
consider the SR transmission as a prioritized SR transmission.
4 >
consider the other overlapping uplink grant(s), if any, as a de-prioritized uplink grant(s), except for the overlapping uplink grant(s) whose simultaneous transmission is allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCH-Groups;
4 >
if the de-prioritized uplink grant(s) is a configured uplink grant configured with autonomousTx whose PUSCH has already started:
5 >
stop the configuredGrantTimer for the corresponding HARQ process of the de-prioritized uplink grant(s);
5 >
stop the cg-RetransmissionTimer for the corresponding HARQ process of the de-prioritized uplink grant(s).
4 >
if SR_COUNTER < sr-TransMax:
5 >
instruct the physical layer to signal the SR on one valid PUCCH resource for SR;
5 >
if LBT failure indication is not received from lower layers:
6 >
increment SR_COUNTER by 1;
6 >
start the sr-ProhibitTimer.
5 >
else if lbt-FailureRecoveryConfig is not configured:
6 >
increment SR_COUNTER by 1.
4 >
else:
5 >
notify RRC to release PUCCH for all Serving Cells;
5 >
notify RRC to release SRS for all Serving Cells;
5 >
clear any configured downlink assignments and uplink grants;
5 >
clear any PUSCH resources for semi-persistent CSI reporting;
5 >
if rach-lessHO is not configured:
6 >
initiate a Random Access procedure (see clause 5.1) on the SpCell and cancel all pending SRs.
3 >
else:
4 >
consider the SR transmission as a de-prioritized SR transmission.
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 was initiated by the MAC entity prior to the sidelink 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 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.
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 SL 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 SL consistent LBT failure; or
  • all the triggered SL 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:
  • the DSR that triggered the SR has been cancelled (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).
Up

5.4.5  Buffer Status Reportingp. 78

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;
  • additionalBSR-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:
1 >
if the BSR is triggered for a logical channel for which logicalChannelSR-DelayTimerApplied with value true is configured by upper layers and SDT procedure is not on-going according to clause 5.27:
2 >
start or restart the logicalChannelSR-DelayTimer.
1 >
else if BSR is triggered for a logical channel for which logicalChannelSR-DelayTimerApplied with value true is configured by upper layers and SDT procedure is on-going according to clause 5.27:
2 >
start or restart logicalChannelSR-DelayTimer with the value as configured by the sdt-LogicalChannelSR-DelayTimer.
1 >
else:
2 >
if running, stop the logicalChannelSR-DelayTimer.
For Regular and Periodic BSR, the MAC entity for which logicalChannelGroupIAB-Ext is not configured by upper layers shall:
1 >
if for at least one LCG configured with additionalBSR-TableAllowed, the amount of UL data available for transmission is within the buffer sizes specified in Table 6.1.3.1-3:
2 >
report Refined Long BSR for all LCGs which have data available for transmission;
1 >
else:
2 >
if more than one LCG has data available for transmission when the MAC PDU containing the BSR is to be built:
3 >
report Long BSR for all LCGs which have data available for transmission.
2 >
else:
3 >
report Short BSR.
For Regular and Periodic BSR, the MAC entity for which logicalChannelGroupIAB-Ext is configured by upper layers shall:
1 >
if more than one LCG has data available for transmission when the MAC PDU containing the BSR is to be built:
2 >
if the maximum LCG ID among the configured LCGs is 7 or lower:
3 >
report Long BSR for all LCGs which have data available for transmission.
2 >
else:
3 >
report Extended Long BSR for all LCGs which have data available for transmission.
1 >
else:
2 >
report Extended Short BSR.
For Padding BSR, the MAC entity for which logicalChannelGroupIAB-Ext is not configured by upper layers shall:
1 >
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:
2 >
if more than one LCG has data available for transmission when the BSR is to be built:
3 >
if the number of padding bits is equal to the size of the Short BSR plus its subheader:
4 >
report Short Truncated BSR of the LCG with the highest priority logical channel with data available for transmission.
3 >
else:
4 >
report Long Truncated BSR of the LCG(s) with the logical channels having data available for transmission following a decreasing order of the highest priority logical channel (with or without data available for transmission) in each of these LCG(s), and in case of equal priority, in increasing order of LCGID.
2 >
else:
3 >
report Short BSR.
1 >
else if the number of padding bits is equal to or larger than the size of the Long BSR plus its subheader:
2 >
report Long BSR for all LCGs which have data available for transmission.
For Padding BSR, the MAC entity for which logicalChannelGroupIAB-Ext is configured by upper layers shall:
1 >
if the number of padding bits is equal to or larger than the size of the Extended Short BSR plus its subheader but smaller than the size of the Extended Long BSR plus its subheader:
2 >
if more than one LCG has data available for transmission when the BSR is to be built:
3 >
if the number of padding bits is smaller than the size of the Extended Long Truncated BSR with zero Buffer Size field plus its subheader:
4 >
report Extended Short Truncated BSR of the LCG with the highest priority logical channel with data available for transmission.
3 >
else:
4 >
report Extended Long Truncated BSR of the LCG(s) with the logical channels having data available for transmission following a decreasing order of the highest priority logical channel (with or without data available for transmission) in each of these LCG(s), and in case of equal priority, in increasing order of LCGID.
2 >
else:
3 >
report Extended Short BSR.
1 >
else if the number of padding bits is equal to or larger than the size of the Extended Long BSR plus its subheader:
2 >
report Extended Long BSR for all LCGs which have data available for transmission.
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:
1 >
if the Buffer Status reporting procedure determines that at least one BSR has been triggered and not cancelled:
2 >
if UL-SCH resources are available for a new transmission and the UL-SCH resources can accommodate the BSR MAC CE plus its subheader as a result of logical channel prioritization:
3 >
instruct the Multiplexing and Assembly procedure to generate the BSR MAC CE(s) as defined in clause 6.1.3.1;
3 >
start or restart periodicBSR-Timer except when all the generated BSRs are long or short Truncated or Extended long or short Truncated BSRs;
3 >
start or restart retxBSR-Timer.
2 >
if a Regular BSR has been triggered and logicalChannelSR-DelayTimer is not running:
3 >
if there is no UL-SCH resource available for a new transmission; or
3 >
if the MAC entity is configured with configured uplink grant(s) and the Regular BSR was triggered for a logical channel for which logicalChannelSR-Mask is set to false; or
3 >
if the UL-SCH resources available for a new transmission do not meet the LCP mapping restrictions (see clause 5.4.3.1) configured for the logical channel that triggered the BSR:
4 >
trigger a Scheduling Request.
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.
Up

5.4.6  Power Headroom Reportingp. 81

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;
  • DPCBC: 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, ΔPPowerClass / ΔPPowerClass, CA / ΔPPowerClass, EN-DC / ΔPPowerClass, 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:
1 >
if it is the first UL resource allocated for a new transmission since the last MAC reset:
2 >
start phr-PeriodicTimer.
1 >
if the Power Headroom reporting procedure determines that at least one PHR has been triggered and not cancelled; and
1 >
if the allocated UL resources can accommodate the MAC CE for PHR which the MAC entity is configured to transmit, plus its subheader, as a result of LCP as defined in clause 5.4.3.1:
2 >
if multiplePHR with value true is configured:
3 >
for each activated Serving Cell with configured uplink associated with any MAC entity of which the active DL BWP is not dormant BWP; and
3 >
for each activated Serving Cell with configured uplink associated with E-UTRA MAC entity:
4 >
if this MAC entity is configured with twoPHRMode:
5 >
if this Serving Cell is configured with multiple TRP PUSCH repetition and the MAC entity this Serving Cell belongs to is configured with twoPHRMode:
6 >
obtain two values of the Type 1 or the value of Type 3 power headroom for the corresponding uplink carrier as specified in clause 7.7 of TS 38.213 for NR Serving Cell.
5 >
else:
6 >
obtain the value of the Type 1 or Type 3 power headroom for the corresponding uplink carrier as specified in clause 7.7 of TS 38.213 for NR Serving Cell and clause 5.1.1.2 of TS 36.213 for E-UTRA Serving Cell.
4 >
else (i.e. this MAC entity is not configured with twoPHRMode):
5 >
if this Serving Cell is configured with multiple TRP PUSCH repetition and the MAC entity this Serving Cell belongs to is configured with twoPHRMode:
6 >
if there is at least one real PUSCH transmission at the slot where the PHR MAC CE is transmitted:
7 >
obtain the value of the Type 1 power headroom of the first real transmission of the corresponding uplink carrier as specified in clause 7.7 of TS 38.213 for NR Serving Cell.
6 >
else if there is no real PUSCH transmission at the slot where the PHR MAC CE is transmitted:
7 >
obtain the value of the type 1 power headroom of the reference PUSCH transmission associated with the SRS-ResourceSet with a lower SRS-resourceSetID or the value of the type 3 power headroom for the corresponding uplink carrier as specified in clause 7.7 of TS 38.213 for NR Serving Cell.
5 >
else:
6 >
obtain the value of the Type 1 or Type 3 power headroom for the corresponding uplink carrier as specified in clause 7.7 of TS 38.213 for NR Serving Cell and clause 5.1.1.2 of TS 36.213 for E-UTRA Serving Cell.
4 >
if this MAC entity is configured with phr-AssumedPUSCH-Reporting:
5 >
if this MAC entity has UL resources allocated for transmission on this Serving Cell; or
5 >
if the other MAC entity, if configured, has UL resources allocated for transmission on this Serving Cell and phr-ModeOtherCG is set to real by upper layers:
6 >
if dynamicTransformPrecoderFieldPresenceDCI-0-1-r18 or dynamicTransformPrecoderFieldPresenceDCI-0-2-r18 is set to enabled in the active BWP of this Serving Cell:
7 >
obtain the value for the corresponding PCMAX,f,c field for assumed PUSCH from the physical layer if available, as specified in clause 7.7 of TS 38.213.
6 >
obtain the value for the corresponding PCMAX,f,c field from the physical layer.
4 >
else (i.e. if this MAC entity is not configured with phr-AssumedPUSCH-Reporting):
5 >
if this MAC entity has UL resources allocated for transmission on this Serving Cell; or
5 >
if the other MAC entity, if configured, has UL resources allocated for transmission on this Serving Cell and phr-ModeOtherCG is set to real by upper layers:
6 >
obtain the value for the corresponding PCMAX,f,c field from the physical layer.
6 >
if mpe-Reporting-FR2 is configured and this Serving Cell operates on FR2 and this Serving Cell is associated to this MAC entity:
7 >
obtain the value for the corresponding MPE field from the physical layer.
6 >
if mpe-Reporting-FR2-r17 is configured and this Serving Cell operates on FR2 and this Serving Cell is associated to this MAC entity:
7 >
obtain the value for the corresponding MPEi field from the physical layer;
7 >
obtain the value for the corresponding Resourcei field from the physical layer.
6 >
if dpc-Reporting-FR1 is configured and ΔPPowerClass /ΔPPowerClass, CA/ΔPPowerClass, EN-DC/ΔPPowerClass, NR-DC reporting is triggered and this Serving Cell operates on FR1 and this Serving Cell is associated to this MAC entity:
7 >
obtain the value for the corresponding DPC field(s) from the physical layer.
3 >
if phr-Type2OtherCell with value true is configured:
4 >
if the other MAC entity is E-UTRA MAC entity:
5 >
obtain the value of the Type 2 power headroom for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity);
5 >
if phr-ModeOtherCG is set to real by upper layers:
6 >
obtain the value for the corresponding PCMAX,f,c field for the SpCell of the other MAC entity (i.e. E-UTRA MAC entity) from the physical layer.
3 >
instruct the Multiplexing and Assembly procedure to generate and transmit the Enhanced Multiple entry PHR as defined in clause 6.1.3.49 if this MAC entity is configured with mpe-Reporting-FR2-r17 or the Enhanced Multiple Entry PHR for multiple TRP MAC CE as defined in clause 6.1.3.51 if this MAC entity is configured with twoPHRMode or the Multiple Entry PHR with assumed PUSCH MAC CE as defined in clause 6.1.3.78 if this MAC entity is configured with phr-AssumedPUSCH-Reporting or the Multiple Entry PHR MAC CE as defined in clause 6.1.3.9 otherwise based on the values reported by the physical layer.
2 >
else (i.e. Single Entry PHR format is used):
3 >
if this MAC entity is configured with twoPHRMode:
4 >
obtain two values of the Type 1 power headroom from the physical layer for the corresponding uplink carrier of the PCell.
3 >
else:
4 >
obtain the value of the Type 1 power headroom from the physical layer for the corresponding uplink carrier of the PCell.
3 >
if this MAC entity is configured with phr-AssumedPUSCH-Reporting:
4 >
if dynamicTransformPrecoderFieldPresenceDCI-0-1-r18 or dynamicTransformPrecoderFieldPresenceDCI-0-2-r18 is set to enabled in the active BWP of this Serving Cell:
5 >
obtain the value for the corresponding PCMAX,f,c field for assumed PUSCH from the physical layer, if available, as specified in clause 7.7 of TS 38.213.
3 >
obtain the value for the corresponding PCMAX,f,c field from the physical layer;
3 >
if mpe-Reporting-FR2 is configured and this Serving Cell operates on FR2:
4 >
obtain the value for the corresponding MPE field from the physical layer.
3 >
if mpe-Reporting-FR2-r17 is configured and this Serving Cell operates on FR2 and this Serving Cell is associated to this MAC entity:
4 >
obtain the value for the corresponding MPEi field from the physical layer;
4 >
obtain the value for the corresponding Resourcei field from the physical layer.
3 >
if dpc-Reporting-FR1 is configured and this Serving Cell operates on FR1:
4 >
obtain the value for the corresponding DPC field from the physical layer.
3 >
instruct the Multiplexing and Assembly procedure to generate and transmit the Enhanced Single entry PHR as defined in clause 6.1.3.48 if this MAC entity is configured with mpe-Reporting-FR2-r17 or the Enhanced Single Entry PHR for multiple TRP MAC CE as defined in clause 6.1.3.50 if this MAC entity is configured with twoPHRMode or the Single Entry PHR with assumed PUSCH MAC CE as defined in clause 6.1.3.78 if this MAC entity is configured with phr-AssumedPUSCH-Reporting or the Single Entry PHR MAC CE as defined in clause 6.1.3.8 otherwise based on the values reported by the physical layer.
2 >
if this PHR report is an MPE P-MPR report:
3 >
start or restart the mpe-ProhibitTimer;
3 >
cancel triggered MPE P-MPR reporting for Serving Cells included in the PHR MAC CE.
2 >
start or restart phr-PeriodicTimer;
2 >
start or restart phr-ProhibitTimer;
2 >
cancel all triggered PHR(s).
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.
Up

5.4.7  Pre-emptive Buffer Status Reporting |R16|p. 86

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:
1 >
if the Pre-emptive Buffer Status reporting procedure determines that at least one Pre-emptive BSR has been triggered and not cancelled:
2 >
if UL-SCH resources are available for a new transmission and the UL-SCH resources can accommodate the Extended Pre-emptive BSR or Pre-emptive BSR MAC CE plus its subheader as a result of logical channel prioritization:
3 >
instruct the Multiplexing and Assembly procedure to generate the Extended Pre-emptive BSR or Pre-emptive BSR MAC CE as defined in clause 6.1.3.1.
2 >
else:
3 >
trigger a Scheduling Request.
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.
Up

5.4.8  Timing Advance Reporting |R17|p. 86

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:
1 >
if the Timing Advance reporting procedure determines that at least one TAR has been triggered and not cancelled:
2 >
if UL-SCH resources are available for a new transmission and the UL-SCH resources can accommodate the Timing Advance Report MAC CE plus its subheader as a result of logical channel prioritization:
3 >
instruct the Multiplexing and Assembly procedure to generate the Timing Advance Report MAC CE as defined in clause 6.1.3.56.
2 >
else
3 >
if timingAdvanceSR is configured with value enabled:
4 >
trigger a Scheduling Request.
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.
Up

5.4.9  Delay status reporting |R18|p. 87

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 PDCP discardTimers among SDUs buffered for the LCG 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.6 in TS 38.323 for the associated RLC and PDCP entities, respectively.
RRC controls the DSR procedure by configuring the following parameter:
  • remainingTimeThreshold: the threshold on remaining time for triggering a DSR for an LCG.
If an LCG is configured for delay status reporting, the MAC entity shall:
1 >
if the smallest remaining value of the PDCP discardTimers among all the data buffered for the LCG that has not been transmitted in any MAC PDU or reported as data volume in a DSR MAC CE becomes below remainingTimeThreshold of the LCG; and
1 >
if there is no DSR pending for the LCG since the last transmission of a DSR MAC CE:
2 >
trigger a DSR for the LCG.
If there is at least one DSR pending, the MAC entity shall:
1 >
if UL-SCH resources are available for a new transmission and the UL-SCH resources can accommodate the DSR MAC CE plus its subheader as a result of logical channel prioritization:
2 >
instruct the Multiplexing and Assembly procedure to generate the DSR MAC CE;
1 >
else if there is no pending SR already triggered by the DSR procedure for the same logical channel as of this DSR:
2 >
trigger a Scheduling Request.
An SDU is considered to be associated with a DSR if it is associated with the LCG which triggered the DSR and the remaining value of its PDCP discardTimer is below remainingTimeThreshold.
A MAC PDU shall contain at most one DSR MAC CE. The MAC entity shall not include a DSR MAC CE in a MAC PDU if the MAC PDU can accommodate the 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, either when all the SDUs associated with the DSR have been discarded, or when a MAC PDU is transmitted and this MAC PDU includes either all the SDUs associated with the DSR or a DSR MAC CE that contains the delay information of all the SDUs associated with the DSR (as described in the clause 6.1.3.72).
Up

Up   Top   ToC