NR中，网络端会根据UE业务动态的调整BWP，进而改变频域资源范围；不同的BWP会配置CORESET/Searchspace确定不同的时频域资源，让UE在对应的资源上进行盲检接收DCI；通过DCI获得调度信息后，再去PDSCH对应的时域资源和频域资源上 decode data。
NR会针对一个上/下行 TB块用一个HARQ反馈ack/nack信息，也可以针对code Block Group进行HARQ反馈，即当一个TB块分为多个CBG码块组传输时，每个HARQ反馈bit信息对应一个CBG码块组；在没有下行空分复用时，一次调度传输一个TB块，一个HARQ进程对应一个TB块，在开启下行空分复用时，一次调度传输多个TB块（最多2个），一个HARQ进程对应1或者2个TB块。
所以最后UE根据会decode PDSCH data的成功与否，在PUCCH/PUSCH上以HARQ 的方式向网络端反馈ACK/NACK。
下面以2个例子的方式整理下PDCCH盲检收到DCI的后续流程，盲检之前的过程在PDCCH 中都有描述。
如下在frame 192 slot 10上收到C-RNTI 加扰的DCI 1_1，time resource Assignment=2 (也可以看下下截图中的其他DCI field的取值)
time resource Assignment=2 对应的pdsch-TimeDomainAllocationList 是 index 2那组数据 K0代表DL grant与DL transmission 时间偏移，即DCI 的时隙和调度PDSCH 的时隙偏移间隔, absent 时代表K0为0，在同一个slot 调度；K0 =1 则说明要在下一个slot 收PDSCH data，以此类推。
Log 中k0 都是缺省值 即默认为0在同一个slot调度。其中SLIV=68 ，mappingType 为Type A。
通过计算得知 SLIV=68 时 S =1 L =11 ；K0 =0 即在PDCCH 同一个时隙 从symbol 1 开始,长度为11 的symbol 区间去收PDSCH data。
遗憾的是这个PDSCH 显示CRC fail，即没有成功decode 到data，下面要反馈HARQ nack，要求网络端重传。
下一步要向网络反馈ACK.NACK， 之前DCI 1_1 PDSCH Harq Feedback Timing field 为 0 且 HARQ=15。PDSCH Harq Feedback Timing 与K1的确定有关系。
frame 192 slot 10 收到DCI 1_1，这里PDSCH Harq feedback Timing 是 0 对应配置消息中的dl – DataToUL-ACK 4；即需要在192/4 回复对应HARQ 的 ack/nack情况(这个过程在后面的PUCCH在展开叙述)。目前工具有问题 看不到UCI 信息，这个UCI先略过，我们继续看UE 接收的DCI 信息，看网络端有没有重传。
按时间顺序继续看，网络端在frame 193 slot 0上再次下发C-RNTI 加扰的DCI 1_1,HARQ=15 ，此时 NDI=0 没有翻转，说明是重传(这个在后面的HARQ部分再做解释)。
这次CRC pass ,之后的 HARQ 15的DCI 1_1 显示NDI 反转，说明是新传。至此完成一次DL data的接收过程。
下面再简单看一个HARQ ACK/NACK 过程。
DL 383/0 HARQ 15 383/5 HARQ 14 分别收到DCI 1_1；PDSCH Harq feedback Timing 是 0 对应配置消息中的dl – DataToUL-ACK 4；即需要在383/4 383/9 分别回复对应HARQ 的 ack/nack情况。
UE在383/4 383/9 分别回复对应HARQ 的 ack/nack情况。
