3GPP TSG-RAN WG2 Meeting #109-e-Bis	R2-200xxxx

Online, 20 April–30 April 2020

Agenda item:	5.3.1

Source:	Samsung

Title:	Report of [AT109bis-e][003][NR15] MAC Maintenance (Samsung)

Document for:	Discussion and Agreement

1	Introduction

This is to report the result of the following email discussion in RAN2#109bis-e Meeting [1].

[AT109bis-e][003][NR15] MAC Maintenance (Samsung)

Scope: Treat all tdocs for AI 5.3.1

Part 1: Determine which issues that need resolution, find agreeable proposals. Deadline: April 23 0700 UTC

Part 2: For the parts that are agreeable, discussion will continue to agree on CRs.

2	Discussion

2.1	UL Skipping

Regarding the UL skipping operation, RAN2 sent the LS R2-1916572 last November, and received the reply LS in R2-2002515. According to the reply LS (which is not conclusive), the following contributions were submitted under the agenda item 5.3.1:

UL Skipping

R2-2002515	Reply LS on UL skipping (R1-2001376; contact: vivo) RAN1 LS in Rel-15 NR_newRAT-Core To:RAN2

Proposed to be noted

R2-2003610	Further discussion on UL skipping for UCI multiplexing Huawei, HiSilicon discussion Rel-15 NR_newRAT-Core

R2-2003594	CR to 38.321 on UCI transmission in the case the overlapping PUSCH transmission is skipped ZTE, Sanechips CR Rel-15 38.321 15.8.0 0731 - F NR_newRAT-Core

R2-2002780	Discussion on the UL skipping vivo discussion

From the discussion papers above, the following options are on the table:

-	Option 1: MAC does not generate a MAC PDU, and UCI is sent on PUCCH (i.e. RAN1 specification has to be updated even though RAN1 did not conclude last meeting.).

-	Option 2: MAC generates a MAC PDU when UCI multiplexing on UL-SCH is needed, and thus UCI is sent on PUSCH.

-	Option 3: No transmission i.e. UCI is dropped.

-	Option 4: Leave it to RAN1 with other option like in R2-2003610.

-	Option 5: Wait for RAN1

-	…

Please provide the company input to the following table. You may add another option above.

Company	Which option do you support?	Additional comments/suggestion
Samsung	Option 1	Even if RAN1 was not able to conclude the issue last meeting, we understand that Option 1 should be the intended behaviour.
LG	Option 1
vivo	For legacy UE, Option 3. For new UEs, Option 4 or Option 2.	As the Rel-15 UE is already in the market, we should not change the legacy UE behaviours. However we should also clarify what UE behaviours are allowed according to the current specification, to facilitate the UE implementation and the test. As Option 1 prvodied in the previous RAN2 meeting has got lots of concerns from many RAN1 companies, RAN1 can probably discuss the potential solutions first to avoid the some potential issues.
Huawei	Option 4 (Focus on RAN2 part only: MAC doesn't generate a MAC PDU)	Generally we understand that the principle of MAC for Option 1, 3 and 4 is the same that no MAC PDU is generated, which can be considered as a guidance from RAN2 to go a step further. How to transmit the UCI in this case should be part of RAN1 work. More specifically, according to RAN1 feedback, it is clear that RAN1 has concerns on the uncertainty of UCI transmission overlapping with PUSCH. So we should avoid back-forth discussions. From RAN2 perspective, we think it is sufficient to just indicate that MAC doesn't generate a TB in this case, then leave RAN1 to conclude UCI transmission regardless of Option 1, 3 and 4 since we cannot decide L1 functionality which is totally invisible to MAC spec.
Ericsson	Option 5	We understand there was no specific action to RAN2 in the incoming LS R2-2002515. We also understand that RAN1 will discuss this issue and we think RAN2 should give them that that time to discuss.
ZTE	Option 2 or option 4 or option 3	Since the CSI reporting is puncturing transmission which can be studied in RAN1, RAN2 only can be responsible for determining whether to generate a padding PDU for multiplexing the CSI on PUSCH or do nothing. If we go for doing noting, it shall be left to RAN1 discussion.

Conclusion:

[will be drafted after having input from companies]

2.2	BFR

Regarding BFR, the following contributions were (re-)submitted, and one says some changes are needed and the other explains that nothing is needed.

R2-2002612	Clarification on the Random Access parameters for BFR Samsung discussion Rel-15 NR_newRAT-Core

R2-2003481	Correction on the RACH parameters for BFR Huawei, HiSilicon CR Rel-15 38.321 15.8.0 0728 - F NR_newRAT-Core

R2-2003484	Correction on the RACH parameters for BFR Huawei, HiSilicon CR Rel-16 38.321 16.0.0 0729 - A NR_newRAT-Core

Please provide the company input to the following table.

Company	Is any change needed to the specification? (Yes/No)	Additional comments/suggestion
Samsung	No	We provided our understanding in R2-2002612.
LG	No
vivo	No	Agree with Samsung.
Huawei	Yes	Firstly, regarding rsrp-ThresholdSSB, based on the field description in RRC spec, this parameter is used for CF-BFR only but it is not reflected in MAC spec, so we think it is necessary to clarify it in MAC to align with RRC spec. Secondly, regarding PowerRampingStep and initialReceivedTargetPower in BFR Config, according to RAN1 LS, we think it is clear that they are specific to CF-BFR only, and there is no reason to apply these two parameters for CB-BFR so the clarification is needed as well.
Ericsson	No	We think no change is needed in the specification.
ZTE	Partly yes	For the parameter rsrp-ThresholdSSB, we share the same view with HW, it can not be found any explict description in MAC specifcation where the rsrp-ThresholdSSB for RACH case other than BFR can be applied although we all know it shall be from RACH-ConfigCommon. For the parameter PowerRampingStep things, we share the same view with Samsung. No need to change anything.

Conclusion:

[will be drafted after having input from companies]

2.3	Others

One contribution is submitted to discuss the issue from RAN1:

Others

R2-2003643	UL grant overridden between configured grant and RAR grant ASUSTeK discussion Rel-15 NR_newRAT-Core

The contribution above wants to confirm RAN2 understanding which interpretation is correct when both configured grant and RAR grant are available in MAC layer and their corresponding PUSCHs overlap with each other:

-	Interpretation 1: RAR grant takes precedence over configured grant

-	Interpretation 2: Up to UE implementation

Please provide the company input to the following table.

Company	Which interpretation is correct?	Additional comments/suggestion
Samsung	Interpretation 1	No changes are needed to MAC. From our understanding, NOTE 3 is for the activation scenario with DCI (and thus it has to send the CG confirmation MAC CE) where it is left to UE implementation. In other cases, RAR grant should take precedence over periodic occasions of CG grants, as specified in MAC.
LG	Interpretation 1
vivo	Interpretaiton 1	Agree with Samsung on the legacy UE behavious. However there may be issues for the Rel-16 IIOT work item. As IIOT already agreed that: An uplink grant addressed to CS-RNTI with NDI=1 (retransmission of CG) is a dynamic grant in prioritization. An uplink grant addressed to CS-RNTI with NDI=0 ((re-)activation of type 2 CG) is a configured grant in prioritization. Then it seems that the Rel-16 UE behaivours are different for the Rel-15 UE. Maybe this issue could be resolved in the IIOT work item.
Huawei	Interpretation 1
Ericsson	We understand the root of the paper comes from a discussion in RAN1 and that the same paper (more or less) has been submitted to RAN1. If there is a question in RAN1 how 38.321 should be interpreted in this case, RAN1 should send an LS.
ZTE	Interpretation 1

Conclusion:

[will be drafted after having input from companies]

3	Conclusion

3.1	UL Skipping

3.2	BFR

3.3	Others

4	References

[1]	R2-109bis-e Chair MainSession 20-04-20 0800 UTC.docx