3GPP TSG RAN WG2 Meeting #113bis-e R2-21xxxxx

e-Meeting, 12th – 20th April, 2021

Agenda item:	6.1.3.1

Source:	Samsung

Title:	Report of Offline 016: MAC II (Samsung)

Document for:	Discussion and Decision

1	Introduction

This document is a report of the following offline discussion:

[AT113bis-e][016][NR16] MAC II (Samsung)

Scope: Treat R2-2102774, R2-2102723, R2-2102845, R2-2103427, R2-2103435, R2-2102791, R2-2102778, R2-2103436, R2-2102763,

Phase 1, determine agreeable parts, Phase 2, for agreeable parts Work on CRs.

Intended outcome: Report and Agreed-in-principle CRs

Deadline: Schedule A

Bundling related

Treat by email, if needed CB on-line.

R2-2102774	CG Bundle Configured with AutonomousTx	Samsung	discussion	Rel-16	NR_IIOT-Core

R2-2102723	Autonomous transmission and bundling	CATT	discussion	NR_IIOT-Core

R2-2102845	Discussion on CGT handling in the case of autonomous transmission and bundling	Huawei, HiSilicon	discussion	Rel-16	NR_IIOT-Core

R2-2103427	CG timer handling upon de-prioritization of bundled PUSCH	Ericsson	discussion	Rel-16	NR_IIOT-Core

R2-2103435	Consideration on the CGT behavior for CG bundling transmission	ZTE Corporation, Sanechips	discussion	Rel-16	NR_IIOT-Core

R2-2102791	Corrections on MAC handling of uplink grants within a bundle	CATT	CR	Rel-16	38.321	16.4.0	1070	-	F	NR_IIOT-Core

R2-2102778	CG Bundle Configured with LCH-based Prioritization	Samsung	CR	Rel-16	38.321	16.4.0	1069	-	F	NR_IIOT-Core

R2-2103436	Correction of 38.321 on priority handling for bundling CG transmission	ZTE Corporation, Sanechips	CR	Rel-16	38.321	16.4.0	1085	-	F	NR_IIOT-Core

IIoT other

R2-2102763	Clarification on which uplink grants participate to the intra-UE prioritization procedure	CATT, Samsung, Ericsson	CR	Rel-16	38.321	16.4.0	1066	-	F	NR_IIOT-Core

2	Discussion

2.1 Joint Configuration of AutonomousTx and CG Bundling

The first issue posted in the previous meeting is how configuredGrantTimer (CGT) is started/stopped and whether any problem of joint configuration of AutonomousTx and CG bundling exists.

R2-2101744 Configured grant timer handling upon PUSCH cancellation for bundle case ASUSTeK CR Rel-16 38.321 16.3.0 1047 - F NR_IIOT-Core how to handle CGT in the case of autonomous transmission and bundling is postponed

The reason for the postponement was that companies had different understanding on the current behavior. Fortunately, according to the contributions submitted to RAN2#113bis-e, companies seem to have a common understanding on the current MAC specification (TS 38.321 v16.4.0). In particular, the following common understandings are observed (ZTE (R2-2103435), CATT (R2-2102723), Ericsson (R2-2103427), Huawei (R2-2102845), Samsung (R2-2102774)):

Observation 1: All uplink grants of a bundle are delivered altogether simultaneously with the initial grant of the bundle by the UL Grant reception procedure to the HARQ entity.

Observation 2: Each grant within the bundle is independently subject to the grant prioritization procedure.

Observation 3: CGT is only started/restarted by the initial transmission for the bundling CG transmission.

Based on the observations above, we may have two problematic cases that CGT is stopped (The corresponding HARQ process is not reserved anymore.) but Autonomous Transmission is not performed:

Observation 4:

< Case 1 >

Transmission of 1st TB is completely performed.

Transmission of 2nd TB is de-prioritized. CGT is stopped

Autonomous Transmission is not performed. (because the 1st TB has been transmitted)

< Case 2 >

Transmission of 1st TB is de-prioritized CGT is stopped.

Transmission of 2nd TB is transmitted.

Autonomous Transmission is not performed. (because the 2st TB has been transmitted)

Q1) Do companies confirm Observations 1-4 above? (only for the current UE behaviour.)

Company	Yes/No	Comment, if you do not agree any of Observations.
Ericsson	Yes	We agree with the observation 4, but do not agree with that case (1) and (2) are necessarily problematic/error cases (at least from UE point of view), since UE actions are clear.
Apple	Yes	- Although observation 1 is the implicit understanding, there are multiple ways to handle this in implementation, and we prefer not to specify this. - Observation 2/3: We share the rapporteur’s understanding. - Observation 4: Autonomous transmission is not performed in both cases. However, once the CG timer is stopped, another grant can theoretically overwrite the HARQ buffer. This is quite a corner case though.
ZTE	Yes	We share the same view with Ericsson. As described from our contribution, the current UE behavior is crystal clear we are not sure whether the case 1 and case 2 is problematic case which shall be improved.
LG	Yes	For Observation4, we think there can be another cases, which seems more general cases, where part of CG bundles are de-prioritized by e.g., DG or SR transmission.
Xiaomi	Yes	We think the case 1 and 2 are corner cases which shall not be enhanced, as the gNB would anyway be able to use the dynamic scheduling for retransmission.
Lenovo	Yes	We agree with the observations made by the rapporteur. However we are also not sure whether the cases addressed here are really a problem as network is aware of this and can handle it.
Nokia	Yes but	We have introduced AutoTX for CG because the gNB may not know whether a CG has been skipped or deprioritized at the gNB side. If gNB knows there is a TB that has been generated by the UE and stored in some HARQ process, the gNB can simply assign the Re-TX grant and AutoTX is no longer needed. For Case 1 and Case 2, at least one TB will be completely transmitted anyway, so apparently the gNB can know there is some TB in the UE, and we can simply rely on gNB implementation to allocate the Re-TX grant.

Although all the submitted contributions have quite similar understanding, companies have difference views how to resolve the problem. Based on the contributions, we have four options:

Option A. If any one of the PUSCH transmission of the bundled CG is not complete, UE autonomously transmits on the next bundled CG occasion. (Ericsson (R2-2103427))

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 any one of PUSCH transmission(s) of the obtained MAC PDU has not been completely performed: 4> consider the MAC PDU has been obtained.

Option B-1. If none of the PUSCH transmission of the bundled CG is complete, UE autonomously transmits on the next bundled CG occasion. + No enhancement of CGT operation (ZTE (R2-2103435))

- No TP/CR is expected.

Option B-2. If none of the PUSCH transmission of the bundled CG is complete, UE autonomously transmits on the next bundled CG occasion. + CGT is stopped only if a part of bundle is de-prioritized and none of PUSCH transmission is complete. (Samsung (R2-2102774))

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 deprioritized uplink grant is configured with autonomousTx and none of PUSCH transmission(s) of the stored PDU has been completely performed, the configuredGrantTimer for the corresponding HARQ process of this de-prioritized uplink grant shall be stopped if it is running.

Option C. A CG is not expected to be configured with both bundled transmissions (Rep > 1) and AutonomousTx. (CATT (R2-2102723), Huawei (R2-2102845))

- We may need an RRC CR not to allow the configuration with both bundled transmissions (Rep > 1) and AutonomousTx.

Q2) Please indicate your preferred option.

- A) If any one of the PUSCH transmission of the bundled CG is not complete, UE autonomously transmits on the next bundled CG occasion.

- B1) If none of the PUSCH transmission of the bundled CG is complete, UE autonomously transmits on the next bundled CG occasion. + No enhancement of CGT operation

- B2) If none of the PUSCH transmission of the bundled CG is complete, UE autonomously transmits on the next bundled CG occasion. + CGT is stopped only if a part of bundle is de-prioritized and none of PUSCH transmission is complete.

- C) CG is not expected to be configured with both bundled transmissions (Rep > 1) and AutonomousTx.

Company	Preferred Option	Comment, if you do not agree any of Observations.
Ericsson	Either one of the below is okay A) Leave for network configuration /implementation (no CR) = B1??	For B1), it is our understanding for this option the UE follows what is written in the MAC spec Rel-16. For example, if only one of the PUSCH transmission of the bundled CG is complete, the UE cannot autonomously transmit on the next bundled CG, as per observation 4 in the first question. Maybe it would be good to clarify the B1 further. For B2). It does not resolve an extension of the case (2) in the observation 4 above. The extension is for three TBs Transmission of 1st TB and 2nd TB are de-prioritized Transmission of 3rd are transmitted. It is our understanding that the CR would stop the CG timer at the end of the 2nd TB transmission. This understanding is per for the observation 2: Observation 2: Each grant within the bundle is independently subject to the grant prioritization procedure. Thus, during the grant prioritization for each bundle, there is a possibility to stop the CG timer. In a nutshell, timer can be stopped for each PUSCH transmission of the bundle rather than the end of the bundle. It is only in the end of the bundle that the UE knows that none of the PUSCH transmission of the bundled CG is complete, and it is only at that moment that UE knows that the configuredGrantTimer shall be stopped. We don’t see any easy ways to capture this in the already complicated MAC spec. We have also provided analysis in the paper R2-2103427 to show that option a) is better: A retransmission would most likely be needed and so the autonomous transmission in the next CG bundle occasion (which would otherwise not be used, as in the option b) can reduce the delay of this MAC PDU. For option b, it is not guaranteed that the network can always detect the transmission, e.g., in the case that only one out of eight bundled PUSCH transmissions is not de-prioritized. For option b, in the other unlikely (but may still happen) case in which the gNB successfully decodes the MAC PDU from the first bundle with only part of the PUSCH transmissions, there is no way for the network to stop the autonomous transmission in the second bundle that leads to a resource waste. For example, if only one out of eight bundled PUSCH transmissions is de-prioritized. For C), it is fine not to further optimize UE actions when both are configured, but there is no need to add network configuration restriction.
Apple	B2	Solution B2 seems sufficient and simple enough. In our understanding, the network may be able to decode the data even from an incomplete set of repetitions depending on the configuration. If a single transmission occasion within a bundle is deprioritized, we assume this happens on purpose. If the network is unable to recover the UL data from a set of (incompletely) received RVs, it can schedule a retransmission of the bundle over DG. Minor addition to the TP for B2: "stored PDU" should read "stored MAC PDU". Secondly, we have a general remark on the solution approach. It has been agreed (e.g., in R2-2011075) to stop the configuredGrantTimer to allow autonomous transmission. One drawback here is that, once the configureGrantTimer is stopped, a new transmission might overwrite the HARQ buffer. And this may destroy a MAC PDU awaiting autonomous transmission (or in an extreme case, even the TB in the HARQ buffer during an ongoing repetition … the latter though is not expected, proper implementation should prevent that). The likelihood for such an incident to occur is higher when the configuredGrantTimer is set to multiple periodicity values. It may be a very corner case! Now autonomous transmission and TB repetitions are separate mechanisms that, in the scenario, would both apply to the same MAC PDU and the same HARQ process. If it’s the same HARQ process and the same MAC PDU anyway, the CG timer may as well continue to run. A potential way around that problem might be: 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 or this uplink grant is configured with autonomousTx for which a MAC PDU to transmit is already stored in the HARQ buffer, and cg-RetransmissionTimer is not configured (i.e. new transmission): 3> consider the NDI bit for the corresponding HARQ process to have been toggled; 3> deliver the configured uplink grant and the associated HARQ information to the HARQ entity. And then remove all places where the CG timer is stopped to prevent the running timer from blocking autonomous transmission (e.g., as in CR 0997, R2-2011075). Above alternative may require more thinking for possible side-effects. In general, we are fine with solution B2. But if companies want to address the additional problem, then the alternative above is one option.
ZTE	B1	For A, we can not tell any differences between the following two sentences actually, the “any one” + “not” seems equaling to the “none” if any one of PUSCH transmission(s) of the obtained MAC PDU has not been completely performed: (The suggestion from A) V.S 3> if none of PUSCH transmission(s) of the obtained MAC PDU has been completely performed: (The current spec) For B1, as explained in our contribution, the current spec is crystal clear on UE behavior on autonomous TX for CG bundling transmission which is if anyone of the PUSCH transmission within a bundle for a MAC PDU is successfully performed, the autonomous TX is disabled for this MAC PDU. Just note that, NW can be aware of the transmission via DMRS or power detection of the successful PUSCH transmission and would schedule a re-transmission intentionally. For B2, to correct CGT behavior to make the CGT keep running when the retransmission within a bundling is canceled is aiming for preventing the next CG bundling with the same HARQ process ID from generating a new MAC PDU if the CGT is long enough, we do not think it is a critical issue shall be modified since the NW anyway can be aware of this situation and use a CI-RNTI to disable the next CG bundling occasion. For C, we also agree with Ericsson that there is no need to take additional NW restriction on this especially the current UE behavior is clear based on the current specification.
LG	B1 in Rel-16. Open to discuss B2 for Rel-17.	In our understanding, when at least one CG is not transmitted due to de-prioritization within a bundle, solution A aims at allowing retransmission in the next CG bundle while CGT is not running whereas solution B2 aims at allowing retransmission within the current CG bundle by not stopping the CGT. However, for A, the autonomous retransmission may still not be possible in the next CG bundle because of the yellow highlighted text: 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 any one of PUSCH transmission(s) of the obtained MAC PDU has not been completely performed: 4> consider the MAC PDU has been obtained. If the last configured grant of the previous CG bundle is a prioritized uplink grant, which is already delivered to HARQ entity as a bundle, the condition is not met for autonomous retransmission in the next CG bundle (as illustrated below). Our understanding of B2 is to stop the CGT at the time of de-prioritized uplink grant by looking at the transmissions occurred so far within the CG bundle. Regarding the example scenario raised by Ericsson (illustrated below), the MAC does not even start CGT for 1st and 2nd CG. And, on 3rd CG within the bundle, the UE starts the CGT and B2 lets the MAC not to stop CGT at the end of 3rd CG because at least one of CG bundle is transmitted. Even for the case where CGT is running due to transmission on the 1st CG within the bundle (as illustrated below), B2 means that, the MAC decides not to stop on either 2nd CG or 3rd CG within the CG bundle because at least one of bundle was transmitted on 1st CG. Thus, retransmission on the 4th CG within the bundle is possible. With B2, the CGT is kept running and the next CG bundle wouldn’t be delivered to HARQ entity at all but the network can schedule a retransmission while CGT is running. For B1/ Without any specification change, the B1 implies that the network copes with this case by providing dynamic grant for retransmission. To avoid overriding by other MAC PDU in the next CG bundle, the retransmission grant should be provided earlier than the start of the next CG bundle. We are generally fine with B1 as network have options to avoid this situation and nothing seems broken even it happens. However, if bundle size is large and the CG is de-prioritized at the early stage within the CG bundle, resource waste might be large and the retransmission by the network may not be guaranteed. To resolve this, we are open to discuss in Rel-17.
Xiaomi	B1	As Rel-16 is frozen, B1 would still work without causing critical issues. For other solutions, we are open to discuss in Rel-17.
Lenovo	B1	We are fine to rediscuss other options for Rel-17 if majority of companies sees a need for this.
Nokia	B1	For A, it implies we may still have some transmissions in the bundle that are complete, so in this case we may rely on gNB implementation based on what we explained in Q1. For B2, we think current CG timer mechanism is already sufficient and we do not see further enhancement is needed. For C, it is a bit restrictive from gNB implementation perspective. Therefore we think B1 is the simplest way to close this issue.

Companies seem to agree that all uplink grants of a bundle are delivered altogether simultaneously with the initial grant of the bundle by the UL Grant reception procedure to the HARQ entity. (Observation 1 above) However, the current text may be unclear. CATT (R2-2102791) proposed to add a NOTE to clarify this.

Q3). Do companies agree to add the following NOTE?

NOTE 6: All uplink grants associated with a transmission within a bundle are delivered to the HARQ entity along with the first uplink grant of the bundle.

Note that the exact TP can be further discussed after we agree the reason for the change.

Company	Yes/No	Comment, if any
Ericsson	No strong view	The existing MAC spec is clear, although it is not straightforward and explicitly written. On the other hand, we are fine to follow the majority view. If agreed, we need to discuss if a similar note needs to be added for the dynamic grant. Otherwise, it may mean that, for dynamic grant, the bundle is NOT delivered together.
Apple	No	The implied behaviour is already clear enough in the current spec. We prefer not to specify this explicitly as there are multiple ways to handle this in implementation. No need to add a note in the late stage of Rel-16.
ZTE	No	The note is to describe the UE inner behavior which is not appropriate to capture in the spec.
LG	No	The intention, in our understanding, is to deliver the configured grants within the bundle safely to the HARQ entity even if CGT is running for that bundle. We think sensible UE can handle this even without limiting the UE behaviour.
Xiaomi	No	It seems that all companies have the same understanding. Not sure if the NOTE helps at any point.
Lenovo	No	We don’t think that the NOTE is required as the interpretation of the MAC spec is already clear in our understanding and also usually, we don’t specify UE implementation aspects.
Nokia	No but	We don’t think this is needed but okay to add if majority of companies support this.

2.2 CG Bundle configured with lch-basedPrioritization

When lch-basedPrioritization is configured, the current text implies that the bundling grant for retransmission is ignored if PUSCH duration is overlapped with other PUSCH duration of another UL grant addressing from PDCCH. CATT (R2-2102791), ZTE (R2-2103436) and Samsung (R2-2102778) all pointed out the problem and the TPs aim the same. The rapporteur thinks we can directly discuss the detail of the TP.

Q4) Please indicate your preferred option.

A) R2-2102791

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.

B) R2-2103436

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 MAC entity is not configured with lch-basedPrioritization and the 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 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 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 configured with lch-basedPrioritization and this uplink grant is not a prioritized uplink grant: 4> ignore the uplink grant.

C) R2-2102778

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 MAC entity is not configured with lch-basedPrioritization, and the 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 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 configured with lch-basedPrioritization and this uplink grant is not a prioritized uplink grant: 4> ignore the uplink grant.

D) No CR is necessary.

Company	Preferred Option	Comment, if any
Ericsson	Option C	Per the observation 2 in the question 1 Observation 2: Each grant within the bundle is independently subject to the grant prioritization procedure. In our view, the change in option C is sufficient. Since it is cleaner, this option is preferred.
Apple	A	We prefer this variant because the overlap with RAR or MSGA needs to be handled regardless of lch-basedPrioritization.
ZTE	A and B(Proponent)	We also prefer to make the handling to collision case between retransmission of the bundling and PUSCH transmission received in RAR unified in both R15 and R16.
LG	C	Option C is simple and sufficient.
Xiaomi	C	The text of Option C seems clean and sufficient.
Lenovo	B	Overlapping case with RAR and MSGA needs to be handled regardless of lch-basedPrioritization as pointed out by others.
Nokia	C	We prefer the option with minimal spec. change.

2.3 UL Grants Participating to the Intra-UE Prioritization

In R2-2102763 (CATT, Samsung, Ericsson), it is pointed out that in the current MAC specification, it could be erroneously understood that uplink grants filtered out by the legacy procedure (i.e. the case that the uplink grant is not delivered to the HARQ entity) would still participate to the intra-UE prioritization procedure. More specifically, if the UE does not deliver the uplink grant to the HARQ entity, it is expected to be discarded at this stage and, specifically, to not participate to the following prioritization procedure text. Hence, it is proposed to clarify that only the uplink grant delivered to the HARQ entity participated in the prioritization, as follows:

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

Q5) Do companies agree the proposed change of R2-2102763? Note that the exact TP can be further discussed after we agree the reason for the change.

Company	Yes/No	Comment, if any
Ericsson	Yes
Apple	Yes	The delivery of an UL grant to the HARQ entity happens before intra-UE prioritization, and only those grants need to be considered in the grant prioritization. A sensible implementation might consider just the delivered grants already with the current text, but it’s good to clarify the intended behaviour in the specification.
ZTE	Yes
LG	No	It seems straightforward and sensible UE implementation should only consider the uplink grant delivered to the HARQ entity for prioritization.
Xiaomi	Yes
Lenovo	Yes
Nokia	Yes

2.4 CG Configured with AutonomousTx

In the current MAC specification, autonomousTx is configured per CG configuration. To align with other parts of MAC specification, Samsung (R2-2102774) proposed the TP.

Q6) Do companies agree the following proposed change?

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 deprioritized uplink grant is a configured grant configured with autonomousTx, the configuredGrantTimer for the corresponding HARQ process of this de-prioritized uplink grant shall be stopped if it is running.

Company	Yes/No	Comment, if any
Ericsson	No	Not sure if we understand the intention of the change. It is clear for us that “this de-deprioritized uplink grant” refers to the uplink grant described in the sentence before (i.e., a configured grant cancelled by CI-RNTI or a high PHY-priority PUCCH). In other words, it is already known from the context that it is a configured grant.
Apple	Yes
ZTE	No	We think the current spec is clear enough since the autonomousTx only can be configured to CG configuration.
LG	No	As autonomousTx is only for CG, the text is already clear to be applied to configured grant. Also, due to this in the sentence, there shouldn’t be no mis-understanding of this sentence.
Xiaomi	No	As commented by other companies, autonomousTx is only for CG.
Lenovo	No	We don’t see a need for this clarification
Nokia	No	The wording “this deprioritized uplink grant” is clearly referring to the grant described in the previous sentence: “… this configured uplink grant is considered as a de-prioritized uplink grant.” So we do not see any possibility of confusion here.

3	Conclusion