协议38.213（fd0版本）里有这么一段描述：
A UE does not expect to detect a DCI format scheduling a PDSCH reception or a SPS PDSCH release and indicating a resource for a PUCCH transmission with corresponding HARQ-ACK information in a slot if the UE previously detects a DCI format scheduling a PUSCH transmission in the slot and if the UE multiplexes HARQ-ACK information in the PUSCH transmission.
这段话大意是说，如果UE在slot n检测到上行分配ul-grant，且对应的PUSCH数据在slot (n+k2)中发送，那么UE将不会去检测slot n到slot (n+k2)之间的下行资源分配dl-assignment，如下图所示。
为什么协议需要这么规定？接下来我们来分析这背后的逻辑。
首先，在LTE里，若UE需要在PUSCH中发送HARQ-ACK，UE会以打孔的形式（punctured）发送。而在NR里，由于HARQ时序的不固定，以及HARQ-ACK的比特数更多，所以会存在两种发送方式：
1、当HARQ-ACK比特数不超过2bits时，仍然采用类似LTE的打孔方式；
2、对超过2bits的HARQ-ACK，若仍然采用打孔的方式，将会增加PUSCH的码率，降低解调性能，因而采用速率匹配的方式（rate-matched）.
上面提到的两种方式：一个打孔，一个速率匹配，不懂最后是怎么操作的，加入pading?
这在38.300（fa0版本）协议里可以找到依据：
UCI multiplexing in PUSCH is supported when UCI and PUSCH transmissions coincide in time, either due to transmission of a UL-SCH transport block or due to triggering of A-CSI transmission without UL-SCH transport block:
- UCI carrying HARQ-ACK feedback with 1 or 2 bits is multiplexed by puncturing PUSCH;
- In all other cases UCI is multiplexed by rate matching PUSCH.
再来分析一下下面这种场景。
假定基站在slot n给UE下发了ul grant，对应的PUSCH在slot (n+4)。然后基站在slot (n+1)给UE下发了dl assignment，如果此时UE并没有检测到，即发生了漏检行为。那么此时对于UE来说，它并不知道基站已经给它发送了dl assignment，所以UE在slot (n+4)只会发送数据，而不会复用HARQ-ACK，但基站仍然会按照PUSCH+ACK的方式解码。
如果此时HARQ-ACK比特数只有1或2比特，采用的是打孔的方式，那么基站有可能能够解析到PUSCH中的数据，但如果此时HARQ-ACK比特数超过了2比特，基站将会以速率匹配的方式解析，此时PUSCH大概率会解码失败，如下图所示。
所以，协议为了避免这种情况发生，规定在ul_grant和PUSCH之间，UE不再接收dl_assignment。
上述在ul grant之后收到dl assignment的场景，有2种可选方式解决：
方案1：限制后续dl assignment对应的HARQ ACK的比特数，并以打孔的方式在PUSCH中复用ACK。但这种方式会增加PUSCH的码率，降低解调性能。
方案2：调度器在ul grant中预估后续需要发送的HARQ ACK比特数，UE基于该比特数，在PUSCH中进行速率匹配，这样即便dl assignment漏检，也不影响基站对PUSCH的解码。但这个方案的难点在于如何精准预估未来的HARQ比特数。
鉴于3GPP还未达成一致意见，目前仍然不支持ul grant之后继续处理dl assignment。
明白这个帖子说的什么含义：就是在发了ul_grant后，如果再发dl assignment的话，如果漏检可能不知道，会影响pusch的解码。 但目前基本都是这么做的
————————————————
版权声明：本文为CSDN博主「阿米尔C」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m_052148/article/details/115787997