转载： https://blog.csdn.net/kakamilan/article/details/121192611?spm=1001.2014.3001.5501
https://www.ekuibu.com/forum.php?mod=viewthread&tid=284
在论坛上看到这么一个问题：
做随机接入时，UE接收MSG4，如果译码正确需要反馈ACK；如果译码不正确，则不需要反馈NACK。是这样的吗？
另外，反馈ACK时，是使用SIB1里面的公共的PUCCH资源吗？还是可以使用UE专属的PUCCH资源？
对于译码错误或者竞争解决失败，是不需要反馈NACK的，因为对于Temporary C-RNTI加扰的PDSCH也没有HARQ重传一说，基站侧接收到NACK还是DTX的后续处理都是一样的，认为随机接入失败。所以，可以在译码正确且竞争解决成功的时候反馈ACK。
楼主请问个问题，为什么msg4不会有重传？ 目前所在的公司msg4是做了重传处理的。 我理解您说的是ue可以不反馈nack, 但是物理层还是会给mac层一个harq 反馈，然后mac还是可以进行重传吧？
MAC可进行重传。
楼主下面的文章中也提到了，有的地方将msg4分为了两部分：Contention Resolution和RRC Setup。 目前公司实现中Contention Resolution和RRC Setup对应的harq反馈都是在common pucch资源上。之后的下行就会在专用pucch资源上。
个人理解为什么在rrc_setup里面对应的harq反馈还用common pucch资源，是因为基站这边是在common pucch资源上去检测，而rrc_setup_complete还没上来，两边还没同步好，
这个可能看两遍具体的实现，UE能不能及时的解析出来PUCCH 资源，然后基站这边只是PHY去哪个资源上解析。只要两边都协调好没有问题，最保险的就是在msg4harq反馈还是在pucch common上反馈，后面就在专用的pucch资源上反馈。
在38.213协议的8.4节中的描述
In response to the PDSCH receptionwith the UE contention resolution identity, the UE transmits HARQ-ACKinformation in a PUCCH.
在38.321协议中5.3.2.2节的描述。
1> if the HARQ process isassociated with a transmission indicated with a Temporary C-RNTI and theContention
Resolution is not yet successful(see clause 5.1.5); or
1> if the HARQ process isassociated with a transmission indicated with a MSGB-RNTI and the Random Access
procedure is not yet successfullycompleted (see clause 5.1.4a); or
对于是使用SIB1里面的公共的PUCCH资源还是UE专属的PUCCH资源这个问题，
首先，如果通常所谓的MSG4中不携带RRCSetup，而只携带了Contention Resolution，而UE专属的PUCCH资源在RRCSetup中，所以在反馈ACK时候可能就没有专属PUCCH资源，此时使用SIB1里面指示的PUCCH资源。
其次，如果Contention Resolution和RRC Setup在同一个PDSCH中，那么要看UE的实现方式。
1）如果是在接收到调度MSG4的DCI的时候就计算PUCCH资源，那么这个时候只能使用SIB1中指示的PUCCH资源
2）如果是在确定要反馈ACK，且只提前一个Slot调度时候来确定PUCCH资源，此时对于物理层来说，可能已经获得了RRC Setup中指示的PUCCH资源。
38.213协议9.2.1节中的描述
If a UE does not have dedicated PUCCHresource configuration, provided by PUCCH-ResourceSet in PUCCH-Config, a PUCCHresource set is provided by pucch-ResourceCommon through an index to a row ofTable 9.2.1-1 for size transmission of HARQ-ACK information on PUCCH in aninitial UL BWP of PRBs…
上面这个图化的不是很清晰。
从协议描述来看，还不能很明确地看出基站是在什么PUCCH resource上发送MSG4的ACK，不过从基站侧的处理流程来看，当其调度MSG4的DCI之后，应该就是确定了SIB1中指示的PUCCH resource位置，后续就期望在上面接收ACK反馈。
————————————————
版权声明：本文为CSDN博主「5G菜鸟成长日记」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kakamilan/article/details/121192611
