5.4 UL-SCH data transfer
38.3213GPPMedium Access Control (MAC) protocol specificationNRRelease 17TS
5.4.1 UL Grant reception
Uplink grant is either received dynamically on the PDCCH, in a Random Access Response, configured semi-persistently by RRC or determined to be associated with the PUSCH resource of MSGA as specified in clause 5.1.2a. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To perform the requested transmissions, the MAC layer receives HARQ information from lower layers. An uplink grant addressed to CS-RNTI with NDI = 0 is considered as a configured uplink grant. An uplink grant addressed to CS-RNTI with NDI = 1 is considered as a dynamic uplink grant.
If the MAC entity has a C-RNTI, a Temporary C-RNTI, or CS-RNTI, the MAC entity shall for each PDCCH occasion and for each Serving Cell belonging to a TAG that has a running timeAlignmentTimer or a running cg-SDT-TimeAlignmentTimer and for each grant received for this PDCCH occasion:
1> if an uplink grant for this Serving Cell has been received on the PDCCH for the MAC entity’s C-RNTI or Temporary C-RNTI; or
1> if an uplink grant has been received in a Random Access Response:
2> 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 CS-RNTI or a configured uplink grant:
3> consider the NDI to have been toggled for the corresponding HARQ process regardless of the value of the NDI.
2> if the uplink grant is for MAC entity’s C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured;
3> stop the cg-RetransmissionTimer for the corresponding HARQ process, if running.
2> stop the cg-SDT-RetransmissionTimer for the corresponding HARQ process, if running.
2> deliver the uplink grant and the associated HARQ information to the HARQ entity.
1> else if an uplink grant for this PDCCH occasion has been received for this Serving Cell on the PDCCH for the MAC entity’s CS-RNTI:
2> if the NDI in the received HARQ information is 1:
3> consider the NDI for the corresponding HARQ process not to have been toggled;
3> start or restart the configuredGrantTimer for the corresponding HARQ process, if configured;
3> stop the cg-RetransmissionTimer for the corresponding HARQ process, if running;
3> stop the cg-SDT-RetransmissionTimer for the corresponding HARQ process, if running;
3> deliver the uplink grant and the associated HARQ information to the HARQ entity;
3> if a logical channel associated with a DRB configured with survivalTimeStateSupport is multiplexed in the MAC PDU stored in the HARQ buffer for the corresponding HARQ process:
4> trigger activation of PDCP duplication for all configured RLC entities of the DRB.
2> else if the NDI in the received HARQ information is 0:
3> if PDCCH contents indicate configured grant Type 2 deactivation:
4> trigger configured uplink grant confirmation.
3> else if PDCCH contents indicate configured grant Type 2 activation:
4> trigger configured uplink grant confirmation;
4> store the uplink grant for this Serving Cell and the associated HARQ information as configured uplink grant;
4> initialise or re-initialise the configured uplink grant for this Serving Cell to start in the associated PUSCH duration and to recur according to rules in clause 5.8.2;
4> stop the configuredGrantTimer for the corresponding HARQ process, if running;
4> stop the cg-RetransmissionTimer for the corresponding HARQ process, if running.
For each Serving Cell and each configured uplink grant, if configured and activated, the MAC entity shall:
1> if the MAC entity is configured with lch-basedPrioritization, and the PUSCH duration of the configured uplink grant 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 the PUSCH duration of a MSGA payload for this Serving Cell; or
1> if the MAC entity is not configured with lch-basedPrioritization, and the PUSCH duration of the configured uplink grant does not overlap with the PUSCH duration of an uplink grant received on the PDCCH or in a Random Access Response or the PUSCH duration of a MSGA payload for this Serving Cell:
2> set the HARQ Process ID to the HARQ Process ID associated with this PUSCH duration;
2> if, for the corresponding HARQ process, the configuredGrantTimer is not running and cg-RetransmissionTimer is not configured and cg-SDT-RetransmissionTimer is not configured (i.e. new transmission):
3> if there is an on-going CG-SDT procedure and PDCCH addressed to the MAC entity’s C-RNTI has been received; or
3> if there is no on-going CG-SDT procedure:
4> consider the NDI bit for the corresponding HARQ process to have been toggled;
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
2> else if the cg-RetransmissionTimer for the corresponding HARQ process is configured and not running, then for the corresponding HARQ process:
3> if the configuredGrantTimer is not running, and the HARQ process is not pending (i.e. new transmission):
4> consider the NDI bit to have been toggled;
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
3> else if the previous uplink grant delivered to the HARQ entity for the same HARQ process was a configured uplink grant (i.e. retransmission on configured grant):
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
2> else if the cg-SDT-RetransmissionTimer is configured and not running for the corresponding HARQ process;
3> if the configured uplink grant is for the initial transmission for the CG-SDT with CCCH message (i.e., initial new transmission); or
3> if the configuredGrantTimer is not running or not configured, and PDCCH addressed to the MAC entity’s C-RNTI has been received after the initial transmission of the CG-SDT with CCCH message (i.e., subsequent new transmission):
4> consider the NDI bit to have been toggled;
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
3> else if the previous uplink grant delivered to the HARQ entity for the same HARQ process was a configured uplink grant for initial transmission of CG-SDT with CCCH message or for its retransmission; and
3> if PDCCH addressed to the MAC entity’s C-RNTI has not been received (i.e., retransmission for initial CG-SDT transmission):
4> consider the NDI bit to have not been toggled;
4> deliver the configured uplink grant and the associated HARQ information to the HARQ entity.
For configured uplink grants neither configured with harq-ProcID-Offset2 nor with cg-RetransmissionTimer, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol/periodicity)] modulo nrofHARQ-Processes
For configured uplink grants with harq-ProcID-Offset2, the HARQ Process ID associated with the first symbol of a UL transmission is derived from the following equation:
HARQ Process ID = [floor(CURRENT_symbol / periodicity)] modulo nrofHARQ-Processes + harq-ProcID-Offset2
where CURRENT_symbol = (SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot + slot number in the frame × numberOfSymbolsPerSlot + symbol number in the slot), and numberOfSlotsPerFrame and numberOfSymbolsPerSlot refer to the number of consecutive slots per frame and the number of consecutive symbols per slot, respectively as specified in TS 38.211 [8].
For configured uplink grants configured with cg-RetransmissionTimer, the UE implementation selects an HARQ Process ID among the HARQ process IDs available for the configured grant configuration. If the MAC entity is configured with intraCG-Prioritization, for HARQ Process ID selection, the UE shall prioritize the HARQ Process ID with the highest priority, where the priority of HARQ process is determined by the highest priority among priorities of the logical channels that are multiplexed (i.e. the MAC PDU to transmit is already stored in the HARQ buffer) or have data available that can be multiplexed (i.e. the MAC PDU to transmit is not stored in the HARQ buffer) in the MAC PDU, according to the mapping restrictions as described in clause 5.4.3.1.2. If the MAC entity is configured with intraCG-Prioritization, for HARQ Process ID selection among initial transmission and retransmission with equal priority, the UE shall prioritize retransmissions before initial transmissions. The priority of a HARQ Process for which no data for logical channels is multiplexed or can be multiplexed in the MAC PDU is lower than the priority of a HARQ Process for which data for any logical channels is multiplexed or can be multiplexed in the MAC PDU. If the MAC entity is not configured with intraCG-Prioritization, for HARQ Process ID selection, the UE shall prioritize retransmissions before initial transmissions. The UE shall toggle the NDI in the CG-UCI for new transmissions and not toggle the NDI in the CG-UCI in retransmissions.
NOTE 1: CURRENT_symbol refers to the symbol index of the first transmission occasion of a bundle of configured uplink grant.
NOTE 2: A HARQ process is configured for a configured uplink grant where neither harq-ProcID-Offset nor harq-ProcID-Offset2 is configured, if the configured uplink grant is activated and the associated HARQ process ID is less than nrofHARQ-Processes. A HARQ process is configured for a configured uplink grant where harq-ProcID-Offset2 is configured, if the configured uplink grant is activated and the associated HARQ process ID is greater than or equal to harq-ProcID-Offset2 and less than sum of harq-ProcID-Offset2 and nrofHARQ-Processes for the configured grant configuration.
NOTE 3: If the MAC entity receives a grant in a Random Access Response (i.e. MAC RAR or fallbackRAR), or addressed to Temporary C-RNTI or determines a grant as specified in clause 5.1.2a for MSGA payload and if the MAC entity also receives an overlapping grant for its C-RNTI or CS-RNTI, requiring concurrent transmissions on the SpCell, the MAC entity may choose to continue with either the grant for its RA-RNTI/Temporary C-RNTI/MSGB-RNTI/the MSGA payload transmission or the grant for its C-RNTI or CS-RNTI.
NOTE 4: In case of unaligned SFN across carriers in a cell group, the SFN of the concerned Serving Cell is used to calculate the HARQ Process ID used for configured uplink grants.
NOTE 5: If cg-RetransmissionTimer is not configured, a HARQ process is not shared between different configured grant configurations in the same BWP.
For the MAC entity configured with lch-basedPrioritization, priority of an uplink grant is determined by the highest priority among priorities of the logical channels that are multiplexed (i.e. the MAC PDU to transmit is already stored in the HARQ buffer) or have data available that can be multiplexed (i.e. the MAC PDU to transmit is not stored in the HARQ buffer) in the MAC PDU, according to the mapping restrictions as described in clause 5.4.3.1.2. The priority of an uplink grant for which no data for logical channels is multiplexed or can be multiplexed in the MAC PDU is lower than either the priority of an uplink grant for which data for any logical channels is multiplexed or can be multiplexed in the MAC PDU or the priority of the logical channel triggering an SR.
For the MAC entity configured with lch-basedPrioritization, if the corresponding PUSCH transmission of a configured uplink grant is cancelled by CI-RNTI as specified in clause 11.2A of TS 38.213 [6] or cancelled by a high PHY-priority PUCCH transmission as specified in clause 9 of TS 38.213 [6], this configured uplink grant is considered as a de-prioritized uplink grant. If this de-prioritized uplink grant is configured with autonomousTx, the configuredGrantTimer for the corresponding HARQ process of this de-prioritized uplink grant shall be stopped if it is running. If this de-prioritized uplink grant is configured with autonomousTx, the cg-RetransmissionTimer for the corresponding HARQ process of this de-prioritized uplink grant shall be stopped if it is running.
When the MAC entity is configured with lch-basedPrioritization, for each uplink grant delivered to the HARQ entity and whose associated PUSCH can be transmitted by lower layers, the MAC entity shall:
1> if this uplink grant is received in a Random Access Response (i.e. in a MAC RAR or fallback RAR), or addressed to Temporary C-RNTI, or is determined as specified in clause 5.1.2a for the transmission of the MSGA payload:
2> consider this uplink grant as a prioritized uplink grant.
1> else if this uplink grant is addressed to CS-RNTI with NDI = 1 or C-RNTI:
2> if there is no overlapping PUSCH duration of a configured uplink grant which was not already de-prioritized, in the same BWP, whose priority is higher than the priority of the uplink grant; and
2> if there is no overlapping PUCCH resource with an SR transmission which was not already de-prioritized and the simultaneous transmission of the SR and the uplink grant is not allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCH-Groups, and the priority of the logical channel that triggered the SR is higher than the priority of the uplink grant:
3> consider this uplink grant as a prioritized uplink grant;
3> consider the other overlapping uplink grant(s), if any, as a de-prioritized uplink grant(s);
3> consider the other overlapping SR transmission(s), if any, as a de-prioritized SR transmission(s), except for the SR transmission(s) whose simultaneous transmission is allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCH-Groups;
3> if the de-prioritized uplink grant(s) is a configured uplink grant configured with autonomousTx whose PUSCH has already started:
4> stop the configuredGrantTimer for the corresponding HARQ process of the de-prioritized uplink grant(s);
4> stop the cg-RetransmissionTimer for the corresponding HARQ process of the de-prioritized uplink grant(s).
1> else if this uplink grant is a configured uplink grant:
2> if there is no overlapping PUSCH duration of another configured uplink grant which was not already de-prioritized, in the same BWP, whose priority is higher than the priority of the uplink grant; and
2> if there is no overlapping PUSCH duration of an uplink grant addressed to CS-RNTI with NDI = 1 or C-RNTI which was not already de-prioritized, in the same BWP, whose priority is higher than or equal to the priority of the uplink grant; and
2> if there is no overlapping PUCCH resource with an SR transmission which was not already de-prioritized and the simultaneous transmission of the SR and the uplink grant is not allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCH-Groups, and the priority of the logical channel that triggered the SR is higher than the priority of the uplink grant:
3> consider this uplink grant as a prioritized uplink grant;
3> consider the other overlapping uplink grant(s), if any, as a de-prioritized uplink grant(s);
3> if the de-prioritized uplink grant(s) is a configured uplink grant configured with autonomousTx whose PUSCH has already started:
4> stop the configuredGrantTimer for the corresponding HARQ process of the de-prioritized uplink grant(s);
4> stop the cg-RetransmissionTimer for the corresponding HARQ process of the de-prioritized uplink grant(s).
3> consider the other overlapping SR transmission(s), if any, as a de-prioritized SR transmission(s), except for the SR transmission(s) whose simultaneous transmission is allowed by configuration of simultaneousPUCCH-PUSCH or simultaneousPUCCH-PUSCH-SecondaryPUCCHgroup or simultaneousSR-PUSCH-diffPUCCH-Groups.
NOTE 6: If the MAC entity is configured with lch-basedPrioritization and if there is overlapping PUSCH duration of at least two configured uplink grants whose priorities are equal, the prioritized uplink grant is determined by UE implementation.
NOTE 7: If the MAC entity is not configured with lch-basedPrioritization and if there is overlapping PUSCH duration of at least two configured uplink grants, it is up to UE implementation to choose one of the configured uplink grants.
NOTE 8: If the MAC entity is configured with lch-basedPrioritization, the MAC entity does not take UCI multiplexing according to the procedure specified in TS 38.213 [6] into account when determining whether the PUSCH duration of an uplink grant overlaps with the PUCCH resource for an SR transmission.
5.4.2 HARQ operation
5.4.2.1 HARQ Entity
The MAC entity includes a HARQ entity for each Serving Cell with configured uplink (including the case when it is configured with supplementaryUplink), which maintains a number of parallel HARQ processes.
The number of parallel UL HARQ processes per HARQ entity is specified in TS 38.214 [7].
Each HARQ process supports one TB.
Each HARQ process is associated with a HARQ process identifier. For UL transmission with UL grant in RA Response or for UL transmission for MSGA payload, HARQ process identifier 0 is used.
NOTE: When a single DCI is used to schedule multiple PUSCH, the UE is allowed to map generated TB(s) internally to different HARQ processes in case of LBT failure(s), i.e. UE may transmit a new TB on any HARQ process in the grants that have the same TBS, the same RV and the NDIs indicate new transmission.
The maximum number of transmissions of a TB within a bundle of the dynamic grant or configured grant or the uplink grant received in a MAC RAR is given by REPETITION_NUMBER as follows:
– For a dynamic grant, REPETITION_NUMBER is set to a value provided by lower layers, as specified in clause 6.1.2.1 of TS 38.214 [7];
– For a configured grant, REPETITION_NUMBER is set to a value provided by lower layers, as specified in clause 6.1.2.3 of TS 38.214 [7];
– For an uplink grant received in a MAC RAR, REPETITION_NUMBER is set to a value provided by lower layers, as specified in clause 6.1.2.1 of TS 38.214 [7].
If REPETITION_NUMBER > 1, after the first transmission within a bundle, at most REPETITION_NUMBER – 1 HARQ retransmissions follow within the bundle. For both dynamic grant and configured uplink grant, and uplink grant received in a MAC RAR 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 triggered without waiting for feedback from previous transmission according to REPETITION_NUMBER for a dynamic grant or configured uplink grant or uplink grant received in a MAC RAR unless they are terminated as specified in clause 6.1 of TS 38.214 [7]. Each transmission within a bundle is a separate uplink grant delivered to the HARQ entity.
For each transmission within a bundle of the dynamic grant or uplink grant received in a MAC RAR, the sequence of redundancy versions is determined according to clause 6.1.2.1 of TS 38.214 [7]. For each transmission within a bundle of the configured uplink grant, the sequence of redundancy versions is determined according to clause 6.1.2.3 of TS 38.214 [7].
For each uplink grant, the HARQ entity shall:
1> identify the HARQ process associated with this grant, and for each identified HARQ process:
2> if the received grant was not addressed to a Temporary C-RNTI on PDCCH, and the NDI provided in the associated HARQ information has been toggled compared to the value in the previous transmission of this TB of this HARQ process; or
2> if the uplink grant was received on PDCCH for the C-RNTI and the HARQ buffer of the identified process is empty; or
2> if the uplink grant was received in a Random Access Response (i.e. in a MAC RAR or a fallback RAR); or
2> if the uplink grant was determined as specified in clause 5.1.2a for the transmission of the MSGA payload; or
2> if the uplink grant was received on PDCCH for the C-RNTI in ra-ResponseWindow and this PDCCH successfully completed the Random Access procedure initiated for beam failure recovery; or
2> if the uplink grant is part of a bundle of the configured uplink grant, and may be used for initial transmission according to clause 6.1.2.3 of TS 38.214 [7], and if no MAC PDU has been obtained for this bundle:
3> if there is a MAC PDU in the MSGA buffer and the uplink grant determined as specified in clause 5.1.2a for the transmission of the MSGA payload was selected; or
3> if there is a MAC PDU in the MSGA buffer and the uplink grant was received in a fallbackRAR and this fallbackRAR successfully completed the Random Access procedure:
4> obtain the MAC PDU to transmit from the MSGA buffer.
3> else if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a fallbackRAR:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
3> else if there is a MAC PDU in the Msg3 buffer and the uplink grant was received in a MAC RAR; or:
3> if there is a MAC PDU in the Msg3 buffer and the uplink grant was received on PDCCH for the C-RNTI in ra-ResponseWindow and this PDCCH successfully completed the Random Access procedure initiated for beam failure recovery:
4> obtain the MAC PDU to transmit from the Msg3 buffer.
4> if the uplink grant size does not match with size of the obtained MAC PDU; and
4> if the Random Access procedure was successfully completed upon receiving the uplink grant:
5> indicate to the Multiplexing and assembly entity to include MAC subPDU(s) carrying MAC SDU from the obtained MAC PDU in the subsequent uplink transmission;
5> obtain the MAC PDU to transmit from the Multiplexing and assembly entity.
3> else if this uplink grant is a configured grant configured with autonomousTx; and
3> if the previous configured uplink grant, in the BWP, for this HARQ process was not prioritized; and
3> if a MAC PDU had already been obtained for this HARQ process; and
3> if the uplink grant size matches with size of the obtained MAC PDU; and
3> if none of PUSCH transmission(s) of the obtained MAC PDU has been completely performed:
4> consider the MAC PDU has been obtained.
3> else if the MAC entity is not configured with lch-basedPrioritization; or
3> if this uplink grant is a prioritized uplink grant:
4> obtain the MAC PDU to transmit from the Multiplexing and assembly entity, if any;
3> if a MAC PDU to transmit has been obtained:
4> if the uplink grant is not a configured grant configured with autonomousTx; or
4> if the uplink grant is a prioritized uplink grant:
5> deliver the MAC PDU and the uplink grant and the HARQ information of the TB to the identified HARQ process;
5> instruct the identified HARQ process to trigger a new transmission;
5> if the uplink grant is a configured uplink grant:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers;
6> start or restart the cg-RetransmissionTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
6> if the configured uplink grant is for the initial transmission for CG-SDT with CCCH message:
7> start or restart the cg-SDT-RetransmissionTimer, if configured, for the corresponding HARQ process when the transmission is performed.
5> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
5> if cg-RetransmissionTimer is configured for the identified HARQ process; and
5> if the transmission is performed and LBT failure indication is received from lower layers:
6> consider the identified HARQ process as pending.
3> else:
4> flush the HARQ buffer of the identified HARQ process.
2> else (i.e. retransmission):
3> if the uplink grant received on PDCCH was addressed to CS-RNTI and if the HARQ buffer of the identified process is empty; or
3> if the uplink grant is part of a bundle and if no MAC PDU has been obtained for this bundle; or
3> if the uplink grant is part of a bundle of the configured uplink grant, and the PUSCH duration of the uplink grant overlaps with an uplink grant received in a Random Access Response (i.e. MAC RAR or fallbackRAR) or an uplink grant determined as specified in clause 5.1.2a for MSGA payload for this Serving Cell; or:
3> if the MAC entity is not configured with lch-basedPrioritization and this uplink grant is part of a bundle of the configured uplink grant, and the PUSCH duration of the uplink grant overlaps with a PUSCH duration of another uplink grant received on the PDCCH; or:
3> if the MAC entity is configured with lch-basedPrioritization and this uplink grant is not a prioritized uplink grant:
4> ignore the uplink grant.
3> else:
4> deliver the uplink grant and the HARQ information (redundancy version) of the TB to the identified HARQ process;
4> instruct the identified HARQ process to trigger a retransmission;
4> if the uplink grant is addressed to CS-RNTI; or
4> if the uplink grant is addressed to C-RNTI, and the identified HARQ process is configured for a configured uplink grant:
5> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
4> if the uplink grant is a configured uplink grant:
5> if the identified HARQ process is pending:
6> start or restart the configuredGrantTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers;
5> start or restart the cg-RetransmissionTimer, if configured, for the corresponding HARQ process when the transmission is performed if LBT failure indication is not received from lower layers.
5> if the configured uplink grant is for the retransmission of the initial transmission of the CG-SDT with CCCH message:
6> start or restart the cg-SDT-RetransmissionTimer for the corresponding HARQ process when transmission is performed.
4> if the identified HARQ process is pending and the transmission is performed and LBT failure indication is not received from lower layers:
5> consider the identified HARQ process as not pending.
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.
When configuredGrantTimer or cg-RetransmissionTimer or cg-SDT-RetransmissionTimer is started or restarted by a PUSCH transmission, it shall be started at the beginning of the first symbol of the PUSCH transmission.
5.4.2.2 HARQ process
Each HARQ process is associated with a HARQ buffer.
New transmissions are performed on the resource and with the MCS indicated on PDCCH or indicated in the Random Access Response (i.e. MAC RAR or fallbackRAR), or signalled in RRC or determined as specified in clause 5.1.2a for MSGA payload. Retransmissions are performed on the resource and, if provided, with the MCS indicated on PDCCH, or on the same resource and with the same MCS as was used for last made transmission attempt within a bundle, or on stored configured uplink grant resources and stored MCS when cg-RetransmissionTimer or cg-SDT-RetransmissionTimer is configured. If cg-RetransmissionTimer is configured, retransmissions with the same HARQ process may be performed on any configured grant configuration if the configured grant configurations have the same TBS. If cg-SDT-RetransmissionTimer is configured, retransmission for the initial CG-SDT transmission with the same HARQ process may be performed on any configured grant configuration if the configured grant configurations have the same TBS.
When cg-RetransmissionTimer is configured and the HARQ entity obtains a MAC PDU to transmit and LBT failure indication is received from lower layer, the corresponding HARQ process is considered to be pending. For a configured uplink grant, configured with cg-RetransmissionTimer, each associated HARQ process is considered as not pending when:
– a transmission is performed on that HARQ process and LBT failure indication is not received from lower layers; or
– the configured uplink grant is initialised and this HARQ process is not associated with another active configured uplink grant; or
– the HARQ buffer for this HARQ process is flushed.
If the HARQ entity requests a new transmission for a TB, the HARQ process shall:
1> store the MAC PDU in the associated HARQ buffer;
1> store the uplink grant received from the HARQ entity;
1> generate a transmission as described below.
If the HARQ entity requests a retransmission for a TB, the HARQ process shall:
1> store the uplink grant received from the HARQ entity;
1> generate a transmission as described below.
To generate a transmission for a TB, the HARQ process shall:
1> if the MAC PDU was obtained from the Msg3 buffer; or
1> if the MAC PDU was obtained from the MSGA buffer; or
1> if 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 or the MSGA buffer:
2> if there are neither NR sidelink transmission nor transmission of V2X sidelink communication at the time of the transmission; or
2> if the transmission of the MAC PDU is prioritized over sidelink transmission or can be simultaneously performed with sidelink transmission:
3> instruct the physical layer to generate a transmission according to the stored uplink grant.
If a HARQ process receives downlink feedback information, the HARQ process shall:
1> stop the cg-RetransmissionTimer, if running;
1> if acknowledgement is indicated:
2> stop the configuredGrantTimer, if running.
If the configuredGrantTimer expires for a HARQ process, the HARQ process shall:
1> stop the cg-RetransmissionTimer, if running;
1> stop the cg-SDT-RetransmissionTimer, if running.
1> if a PDCCH addressed to the MAC entity’s C-RNTI has not been received after initial transmission for the CG-SDT with CCCH message to which the configuredGrantTimer corresponds:
2> indicate failure to perform SDT procedure to the upper layer.
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 sidelink grant for NR sidelink transmissionand configured grant(s) for transmission of V2X sidelink communication on SL-SCH as determined in clause 5.14.1.2.2 of TS 36.321 [22] at the time of the transmission, and neither the NR sidelink transmission is prioritized as determined in clause 5.22.1.3.1a nor the transmission(s) of V2X sidelink communication is prioritized as determined in clause 5.14.1.2.2 of TS 36.321 [22]; or
– if there are both a sidelink grant NR sidelink transmission and configured grant(s) for transmission of V2X sidelink communication on SL-SCH as determined in clause 5.14.1.2.2 of TS 36.321 [22] at the time of the transmission, and the MAC entity is able to perform this UL transmission simultaneously with the NR sidelink transmission and/or the transmission(s) of V2X sidelink communication; or
– if there is only configured grant(s) for transmission of V2X sidelink communication on SL-SCH as determined in clause 5.14.1.2.2 of TS 36.321 [22] at the time of the transmission, and either none of the transmission(s) of V2X sidelink communication is prioritized as determined in clause 5.14.1.2.2 of TS 36.321 [22] or the MAC entity is able to perform this UL transmission simultaneously with the transmission(s) of V2X sidelink communication; or
– if there is only a sidelink grant for NR sidelink transmission at the time of the transmission, and if the NR sidelink transmission is not prioritized as determined in clause 5.22.1.3.1a, or there is a sidelink grant for NR sidelink transmission at the time of the transmission and the MAC entity is able to perform this UL transmission simultaneously with the NR sidelink transmission; or
– if there are both a sidelink grant for NR sidelink transmission and configured grant(s) for transmission of V2X sidelink communication on SL-SCH as determined in clause 5.14.1.2.2 of TS 36.321 [22] at the time of the transmission, and either only the of NR sidelink transmission is prioritized as determined in clause 5.22.1.3.1a or only the transmission(s) of V2X sidelink communication is prioritized as determined in clause 5.14.1.2.2 of TS 36.321 [22] and the MAC entity is able to perform this UL transmission simultaneously with the prioritized NR sidelink transmission or the transmission of V2X sidelink communication:
NOTE 1: Among the UL transmissions where the MAC entity is able to perform the transmission of NR 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 2: Among the UL transmissions that the MAC entity is able to perform simultaneously with all transmission(s) of V2X 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 3: Among the UL transmissions where the MAC entity is able to perform the NR sidelink transmission prioritized simultaneously with all transmission(s) of V2X 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 4: If there is configured grant(s) for transmission of V2X sidelink communication on SL-SCH as determined in clause 5.14.1.2.2 of TS 36.321 [22] at the time of the transmission, and the MAC entity is not able to perform this UL transmission simultaneously with the transmission(s) of V2X 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
5.4.3.1.1 General
The Logical Channel Prioritization (LCP) procedure is applied whenever a new transmission is performed.
RRC controls the scheduling of uplink data by signalling for each logical channel per MAC entity:
– 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).
RRC additionally controls the LCP procedure by configuring mapping restrictions for each logical channel:
– allowedSCS-List which sets the allowed Subcarrier Spacing(s) for transmission;
– maxPUSCH-Duration which sets the maximum PUSCH duration allowed for transmission;
– configuredGrantType1Allowed which sets whether a configured grant Type 1 can be used for transmission;
– allowedServingCells which sets the allowed cell(s) for transmission;
– allowedCG-List which sets the allowed configured grant(s) for transmission;
– allowedPHY-PriorityIndex which sets the allowed PHY priority index(es) of a dynamic grant for transmission;
– allowedHARQ-mode which sets the allowed uplinkHARQ-mode for transmission.
The following UE variable is used for the Logical channel prioritization procedure:
– Bj which is maintained for each logical channel j.
The MAC entity shall initialize Bj of the logical channel to zero when the logical channel is established.
For each logical channel j, the MAC entity shall:
1> increment Bj by the product PBR × T before every instance of the LCP procedure, where T is the time elapsed since Bj was last incremented;
1> if the value of Bj is greater than the bucket size (i.e. PBR × BSD):
2> set Bj to the bucket size.
NOTE: The exact moment(s) when the UE updates Bj between LCP procedures is up to UE implementation, as long as Bj is up to date at the time when a grant is processed by LCP.
5.4.3.1.2 Selection of logical channels
The MAC entity shall, when a new transmission is performed:
1> select the logical channels for each UL grant that satisfy all the following conditions:
2> the set of allowed Subcarrier Spacing index values in allowedSCS-List, if configured, includes the Subcarrier Spacing index associated to the UL grant; and
2> maxPUSCH-Duration, if configured, is larger than or equal to the PUSCH transmission duration associated to the UL grant; and
2> configuredGrantType1Allowed, if configured, is set to true in case the UL grant is a Configured Grant Type 1; and
2> allowedServingCells, if configured, includes the Cell information associated to the UL grant. Does not apply to logical channels associated with a DRB configured with PDCP duplication within the same MAC entity (i.e. CA duplication) when CA duplication is deactivated for this DRB in this MAC entity; and
2> allowedCG-List, if configured, includes the configured grant index associated to the UL grant; and
2> allowedPHY-PriorityIndex, if configured, includes the priority index (as specified in clause 9 of TS 38.213 [6]) associated to the dynamic UL grant; and
2> allowedHARQ-mode, if configured, includes the uplinkHARQ-mode for the HARQ process associated to the UL grant.
NOTE: The Subcarrier Spacing index, PUSCH transmission duration, Cell information, and priority index are included in Uplink transmission information received from lower layers for the corresponding scheduled uplink transmission.
5.4.3.1.3 Allocation of resources
Before the successful completion of the 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 or the uplink grant for the transmission of the MSGA payload. The source MAC entity shall select only the logical channel(s) corresponding to DAPS DRB(s) during DAPS handover.
The MAC entity shall, when a new transmission is performed:
1> allocate resources to the logical channels as follows:
2> logical channels selected in clause 5.4.3.1.2 for the UL grant 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);
2> decrement Bj by the total size of MAC SDUs served to logical channel j above;
2> if any resources remain, all the logical channels selected in clause 5.4.3.1.2 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.
NOTE 1: The value of Bj can be negative.
If the MAC entity is requested to simultaneously transmit multiple MAC PDUs, or if the MAC entity receives the multiple UL grants within one or more coinciding PDCCH occasions (i.e. on different Serving Cells), it is up to UE implementation in which order the grants are processed.
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 a UL grant size that is equal to or larger than 8 bytes (when eLCID is not used) or 10 bytes (when eLCID is used) while having data available and allowed (according to clause 5.4.3.1) for transmission, the MAC entity shall not transmit only padding BSR and/or padding.
The MAC entity shall:
1> if the MAC entity is configured with enhancedSkipUplinkTxDynamic with value true and the grant indicated to the HARQ entity was addressed to a C-RNTI, or if the MAC entity is configured with enhancedSkipUplinkTxConfigured with value true and the grant indicated to the HARQ entity is a configured uplink grant:
2> if there is no UCI to be multiplexed on this PUSCH transmission as specified in TS 38.213 [6]; and
2> if there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.212 [9]; and
2> if the MAC PDU includes zero MAC SDUs; and
2> if the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR:
3> not generate a MAC PDU for the HARQ entity.
1> else if the MAC entity is configured with skipUplinkTxDynamic with value true and the grant indicated to the HARQ entity was addressed to a C-RNTI, or the grant indicated to the HARQ entity is a configured uplink grant:
2> if there is no aperiodic CSI requested for this PUSCH transmission as specified in TS 38.212 [9]; and
2> if the MAC PDU includes zero MAC SDUs; and
2> if the MAC PDU includes only the periodic BSR and there is no data available for any LCG, or the MAC PDU includes only the padding BSR:
3> not generate a MAC PDU for the HARQ entity.
Logical channels shall be prioritised in accordance with the following order (highest priority listed first):
– MAC CE for C-RNTI, or data from UL-CCCH;
– MAC CE for (Enhanced) BFR, or MAC CE for Configured Grant Confirmation, or MAC CE for Multiple Entry Configured Grant Confirmation;
– MAC CE for Sidelink Configured Grant Confirmation;
– MAC CE for LBT failure;
– MAC CE for Timing Advance Report;
– MAC CE for SL-BSR prioritized according to clause 5.22.1.6;
– MAC CE for (Extended) BSR, with exception of BSR included for padding;
– MAC CE for (Enhanced) Single Entry PHR, or MAC CE for (Enhanced) Multiple Entry PHR;
– MAC CE for Positioning Measurement Gap Activation/Deactivation Request;
– MAC CE for the number of Desired Guard Symbols;
– MAC CE for Case-6 Timing Request;
– MAC CE for (Extended) Pre-emptive BSR;
– MAC CE for SL-BSR, with exception of SL-BSR prioritized according to clause 5.22.1.6 and SL-BSR included for padding;
– MAC CE for IAB-MT Recommended Beam Indication, or MAC CE for Desired IAB-MT PSD range, or MAC CE for Desired DL Tx Power Adjustment;
– data from any Logical Channel, except data from UL-CCCH;
– MAC CE for Recommended bit rate query;
– MAC CE for BSR included for padding;
– MAC CE for SL-BSR included for padding.
NOTE 2: Prioritization among MAC CEs of same priority is up to UE implementation.
The MAC entity shall prioritize any MAC CE listed in a higher order than ‘data from any Logical Channel, except data from UL-CCCH’ over NR sidelink transmission.
5.4.3.2 Multiplexing of MAC Control Elements and MAC SDUs
The MAC entity shall multiplex MAC CEs and MAC SDUs in a MAC PDU according to clauses 5.4.3.1 and 6.1.2.
NOTE: Content of a MAC PDU does not change after being built for transmission on a dynamic uplink grant, regardless of LBT outcome.
5.4.4 Scheduling Request
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 BFD-RS set(s) and/or to positioning measurement gap activation/deactivation request. Each logical channel, SCell beam failure recovery, beam failure recovery of 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 the SCell beam failure recovery or the beam failure recovery of 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 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:
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:
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 [19]; 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:
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> 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.
NOTE 1: Except for SR for SCell beam failure recovery, the selection of which valid PUCCH resource for SR to signal SR on when the MAC entity has more than one overlapping valid PUCCH resource for the SR transmission occasion is left to UE implementation.
NOTE 2: If more than one individual SR triggers an instruction from the MAC entity to the PHY layer to signal the SR on the same valid PUCCH resource, the SR_COUNTER for the relevant SR configuration is incremented only once.
NOTE 3: When the MAC entity has pending SR for SCell beam failure recovery and the MAC entity has one or more PUCCH resources (other than PUCCH resources of pending SR for beam failure recovery of BFD-RS set) overlapping with PUCCH resource for SCell beam failure recovery for the SR transmission occasion, the MAC entity considers only the PUCCH resource for SCell beam failure recovery as valid. When the MAC entity has pending SR for beam failure recovery of a BFD-RS set of Serving Cell and the MAC entity has one or more PUCCH resources (other than PUCCH resources of pending SR for beam failure recovery) overlapping with PUCCH resource for beam failure recovery of that BFD-RS set for the SR transmission occasion, the MAC entity considers only the PUCCH resource for beam failure recovery of that BFD-RS set as valid.
NOTE 4: For a UE operating in a semi-static channel access mode as described in TS 37.213 [18], PUCCH resources overlapping with the set of consecutive symbols where the UE does not transmit before the start of a next channel occupancy time are not considered valid.
NOTE 5: If the MAC entity is configured with lch-basedPrioritization, the MAC entity does not take UCI multiplexing according to the procedure specified in TS 38.213 [6] into account when determining whether the valid PUCCH resource for the SR transmission can be signalled by the physical layer and the SR transmission occasion overlaps with the PUSCH duration of an uplink grant of a MSGA payload.
NOTE 6: When the MAC entity has PUCCH resource for pending SR for SCell beam failure recovery overlapping with PUCCH resource for pending SR for beam failure recovery of BFD-RS set for the SR transmission occasion, it’s up to UE implementation to select PUCCH resource for SCell beam failure recovery or PUCCH resource for beam failure recovery of BFD-RS set
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 and/or SL-CSI reporting, 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 and/or SL-CSI reporting MAC CE 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 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.
5.4.5 Buffer Status Reporting
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, logicalChannelGroup-IAB-Ext;
– sdt-LogicalChannelSR-DelayTimer.
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 logicalChannelGroup-IAB-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 TSs 38.322 [3] and 38.323 [4].
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’.
NOTE 1: When Regular BSR triggering events occur for multiple logical channels simultaneously, each logical channel triggers one separate Regular 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 logicalChannelGroup-IAB-Ext is not 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> report Long BSR for all LCGs which have data available for transmission.
1> else:
2> report Short BSR.
For Regular and Periodic BSR, the MAC entity for which logicalChannelGroup-IAB-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 logicalChannelGroup-IAB-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 logicalChannelGroup-IAB-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.
NOTE 2: UL-SCH resources are considered available if the MAC entity has been configured with, receives, or determines an uplink grant. If the MAC entity has determined at a given point in time that UL-SCH resources are available, this need not imply that UL-SCH resources are available for use at that point in time.
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, 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.
NOTE 3: MAC PDU assembly can happen at any point in time between uplink grant reception and actual transmission of the corresponding MAC PDU. BSR and SR can be triggered after the assembly of a MAC PDU which contains a BSR MAC CE, but before the transmission of this MAC PDU. In addition, BSR and SR can be triggered during MAC PDU assembly.
NOTE 4: Void
NOTE 5: If a HARQ process is configured with cg-RetransmissionTimer and if the BSR is already included in a MAC PDU for transmission on configured grant by this HARQ process, but not yet transmitted by lower layers, it is up to UE implementation how to handle the BSR content.
5.4.6 Power Headroom Reporting
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.
RRC controls Power Headroom reporting by configuring the following parameters:
– phr-PeriodicTimer;
– phr-ProhibitTimer;
– phr-Tx-PowerFactorChange;
– phr-Type2OtherCell;
– phr-ModeOtherCG;
– multiplePHR;
– mpe-Reporting-FR2;
– mpe-ProhibitTimer;
– mpe-Threshold;
– numberOfN;
– mpe-ResourcePool;
– 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;
NOTE 1: The path loss variation for one cell assessed above is between the pathloss measured at present time on the current pathloss reference and the pathloss measured at the transmission time of the last transmission of PHR on the pathloss reference in use at that time, irrespective of whether the pathloss reference has changed in between. The current pathloss reference for this purpose does not include any pathloss reference configured using pathlossReferenceRS-Pos in TS 38.331 [5].
– 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 [14], TS 38.101-2 [15], and TS 38.101-3 [16]) 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 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 [15] 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 [15] 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’.
NOTE 2: 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 PCMAX,f,c/PH when a PHR is triggered by other triggering conditions.
NOTE 3: If a HARQ process is configured with cg-RetransmissionTimer and if the PHR is already included in a MAC PDU for transmission on configured grant by this HARQ process, 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 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 [6] 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 [6] for NR Serving Cell and clause 5.1.1.2 of TS 36.213 [17] 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[6] 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[6] 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 [6] for NR Serving Cell and clause 5.1.1.2 of TS 36.213 [17] for E-UTRA Serving Cell.
4> if this MAC entity has UL resources allocated for transmission on this Serving Cell; or
4> 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:
5> obtain the value for the corresponding PCMAX,f,c field from the physical layer.
5> if mpe-Reporting-FR2 is configured and this Serving Cell operates on FR2 and this Serving Cell is associated to this MAC entity:
6> obtain the value for the corresponding MPE field from the physical layer.
5> if mpe-Reporting-FR2-r17 is configured and this Serving Cell operates on FR2 and this Serving Cell is associated to this MAC entity:
6> obtain the value for the corresponding MPEi field from the physical layer;
6> obtain the value for the corresponding Resourcei field 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 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> 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> 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 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.
5.4.7 Pre-emptive Buffer Status Reporting
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 logicalChannelGroup-IAB-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.
NOTE: Pre-emptive BSR may be used for the case of dual-connected IAB node. It is up to network implementation to work out the associated MAC entity or entities which report the Pre-emptive BSR, and the associated expected amount of data reported by any such entity or entities. For the case of dual-connected IAB node, if two ingress BH RLC channels belonging to the same ingress LCG are mapped to two different egress Cell Groups (corresponding to different parent nodes), there may be ambiguity in Pre-emptive BSR calculations and interpretation by the receiving parent node(s) and the IAB node reporting pre-emptive BSR.
5.4.8 Timing Advance Reporting
The Timing Advance reporting procedure is used in a non-terrestrial 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 TS 38.211 [8] clause 4.3.1).
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 current information about Timing Advance and the last reported information about Timing Advance 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.
NOTE: UL-SCH resources are considered available if the MAC entity has been configured with, receives, or determines an uplink grant. If the MAC entity has determined at a given point in time that UL-SCH resources are available, this need not imply that UL-SCH resources are available for use at that point in time.
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 the corresponding Timing Advance Report MAC CE.