5.4.4 下行控制信息(DCI)设计的改进

5G NR系统的下行控制信息(DCI)基本沿用了LTE DCI的结构和设计,定义了各种DCI格式(DCI Format),如表5-9所示。其中R15 NR作为基础5G版本,只定义了4种用于UE-specific数据调度的DCI(Scheduling DCI)和4种支持功率控制(Power Control)、灵活TDD、URLLC功能的组公共控制DCI(Group-common DCI)。随着R16中5G增强技术的引入,又新增加了4种UE-specific DCI和3种Group-common DCI,并对一种Group-common DCI进行了增强扩展。

表5-9 5G NR R15、R16版本定义的DCI Format

NR标准为了降低PDCCH盲检测的复杂度,希望尽量控制DCI Format的数量。因此,在R15版本中只定义了4种用于UE-specific数据调度的DCI(Scheduling DCI),下行、上行各2种。与LTE类似,DCI Format 0_0和1_0为回落DCI格式(Fallback DCI),用于在特殊情况下提供最基本的DCI功能,相对完整的Scheduling DCI格式DCI Format 0_1和1_1,省略了一些支持增强性能的域,其余的域尽可能固定,少依赖RRC配置。DCI Format 2_0用来传输SFI(Slot Format Indicator,时隙格式指示符),以动态指示时隙结构,具体将在5.6节中介绍。DCI Format 2_1用来传输下行预清空指示(Pre-emption Indication),支持URLLC与eMBB业务的灵活复用,具体将在15.7节中介绍。DCI Format 2_2用来传输PUSCH、PUCCH的功率控制(TPC,Transmit Power Control)指令,DCI Format 2_3用来传输SRS(Sounding Reference Signal,信道探测参考信号)的TPC指令。

R16 NR标准中新增的DCI Format主要是为了引入各种5G垂直行业增强技术。为了在增强URLLC技术中提高PDCCH的传输可靠性,新增了DCI Format 0_2和1_2两种压缩DCI(Compact DCI)格式,具体将在15.1节中介绍。为了引入NR V2X(车联网)技术,新增了DCI Format 3_0和3_1两种sidelink调度DCI格式,具体将在第17章中介绍。为了引入IAB(Integrated Access-backhaul,集成接入与回传)、NR-U(NR非授权频谱通信,具体将在第18章中介绍)、双激活协议栈切换等新特性扩展等技术,扩展了DCI Format 2_0,并新增了DCI Format 2_5。为了在增强URLLC技术中引入上行发送取消(UL Cancallation)技术,新增了DCI Format 2_4,具体将在15.7节中介绍。为了引入终端节能信号(UE Power Saving Signal),新增了DCI Format 2_6,具体将在第19章中介绍。

单纯从DCI结构设计的角度,NR标准主要研究了如下两个方向的增强。

1.两阶DCI(2-stage DCI)的取舍

2-stage DCI是一个在NR标准化早期得到广泛研究的DCI增强设计。传统的PDCCH工作机制在本章中已经作了详细介绍,这种一步式(Single-stage)PDCCH已经在3GPP标准中应用了多代,即通过在搜索空间内对PDCCH Candidate进行盲检测,一次性获取DCI中的全部调度信息。理论上讲,这种Single-stage DCI设计存在盲检测复杂度较高、不完成整个DCI的解码就无法获取调度信息、检测时延相对较大的问题。因此,无论在LTE标准化的晚期(如sTTI项目中)还是NR研究阶段,均有一些公司提出引入两阶DCI(2-stage DCI)技术。

2-stage DCI的基本原理是将一次调度的DCI至少分为两个部分传输,具体可以大致分为两类:第一类2-stage DCI大致如图5-46(a)所示,即两步(Stage)均位于PDCCH内,但各自相互独立编码,典型设计是第1步(1st-stage)位于PDCCH的第1个符号,第2步(2nd-stage)位于第2、3个符号,终端可以不用等待整个DCI解码完成,先用最快速度解出1st-stage DCI,开始为解调PDSCH做准备,等解出2nd-stage DCI后,PDSCH的解调工作可以更快完成,有利于实现低时延业务。1st-stage DCI通常包含终端开始PDSCH解码必须尽早知道的“快调度信息”,如时频资源分配、MIMO传输模式、调制编码阶数(Modulation and Coding Scheme,MCS)等。即使基站调度器还未对剩余的“慢调度信息”[如冗余版本(Redundancy Version,RV)、新数据指示符(New Data Indicator,NDI)]作出最后决定,仍可以先通过1st-stage DCI把“快调度信息”发给终端,便于终端开始对PDCCH进行初步的解调处理。等基站确定了“慢调度信息”后,再通过2nd-stage DCI发给终端,用于对PDSCH进行完整解码。

图5-46 2-stage DCI原理示意

2-stage DCI的一个典型应用场景是HARQ操作[33],当PDSCH的初次传输已经发给终端后,基站需要等待PUCCH中反馈的HARQ-ACK信息,暂时还不知道传输是否成功。但此时已经可以用1st-stage DCI为下一次PDSCH传输调度时频资源、MIMO模式和MCS等(这些参数通常只取决于信道条件),等收到了HARQ-ACK信息,如果是NACK,则用1st-stage DCI调度的PDSCH资源传输上一次下行数据的重传版本(通过2nd-stage DCI指示与重传数据相匹配的RV和NDI);如果是ACK,则用1st-stage DCI调度的PDSCH资源传输新的下行数据(通过2nd-stage DCI指示新数据相匹配的RV和NDI)。这种方法对加快与PDCCH同一个时隙内的PDSCH的接收能发挥一定作用,但对调度PUCCH(即使和PDCCH同时隙,一般也相隔数个符号)和后续时隙中的PDSCH起不到加速作用,因为这些信道本身就给终端留有充分的接收时间。另外,分割成两部分的DCI长度变短,可能有利于对齐各种DCI的尺寸,从而降低PDCCH盲检测复杂度。

另一种略不相同的2-stage DCI结构如图5-46(b)所示,即1st-stage DCI中包含2nd-stage DCI的资源位置信息,可以使终端直接找到2nd-stage DCI,避免对2nd-stage DCI进行盲检测。一种典型的结构是2nd-stage DCI不位于PDCCH内,而位于被1st-stage DCI调度的PDSCH内。终端通过1st-stage DCI中的“快调度信息”获知PDSCH的时频资源,而2nd-stage DCI位于PDCCH资源内某个预设的位置,可以自动在PDSCH中找到2nd-stage DCI并解码,再从2nd-stage DCI中获取“慢调度信息”。相对第一种2-stage DCI结构,这种结构进一步简化了2nd-stage DCI的接收,节省了终端搜索2nd-stage DCI的功耗,且可以降低PDCCH的开销,因为2nd-stage DCI被卸载到了PDSCH中。而且PDSCH可以使用更灵活的传输格式(如PDSCH可以使用多种调制阶数,而PDCCH只能使用QPSK调制),有利于提高2-stage DCI的传输效率。需要注意的是,第二种2nd-stage DCI只能用于PDSCH的调度,不可能用于PUSCH的调度,因为终端需要提前获得PUSCH的全部调度信息来对PUSCH进行准备、编码,不可能把2nd-stage DCI放在PUSCH内。

但是,2nd-stage DCI也具有一系列的缺点[33-34]

首先,将一个DCI分成两个部分分开编码,会降低PDCCH信道编码的编码效率,从而可能带来PDCCH的传输性能损失。

其次,2nd-stage DCI可能会降低DCI的可靠性,因为两个部分都必须正确解码才能获得完整的调度信息,任何一部分有误检均会造成调度信息的错误。

再次,2nd-stage DCI仅在对PDCCH解码有很高时延要求的场景(如上所述示例)有增益,而Single-stage DCI作为成熟、可靠的方法,在NR标准里肯定是要支持的(如Fallback DCI还是适合使用Single-stage DCI)。这样2nd-stage DCI只能在Single-stage DCI之外起到额外的辅助作用,不能替代Single-stage DCI,终端需要同时支持两种DCI结构,这增加了终端的复杂度。

最后,2-stage DCI还有可能增大DCI开销,因为两个部分的DCI分别需要添加CRC(Cyclic Redundancy Check,循环冗余校验)。

经过研究,R15 NR标准最终决定暂不采用2-stage DCI,仍只采用传统的Single-stage DCI。但在R16 NR V2X标准中,最终在侧链路采用了两阶控制信息结构,即2-stage SCI(Sidelink Control Information,侧链路控制信息),具体见第17章。

2.组公共控制DCI(Group-common DCI)的引入

常规的DCI主要以终端的资源分配为中心[包括下行(Downlink)、上行(Uplink)和侧行链路(Sidelink)],但也有些和终端资源调度没有直接联系的信息需要动态的通知给终端。要在DCI中传递这些信息,有两个可选的方法。

· 方案1:在负责调度数据信道的DCI(Scheduling DCI)中插入一个域(Field)将这些信息顺带发送给终端。

· 方案2:设计一种单独的DCI Format,专门传输这些信息。

在NR标准中,这两种方案都有所采用。方案1的一个典型的例子是BWP切换(BWP Switching)的切换指令。如4.3节所述,这个指令是通过在Scheduling DCI中插入一个BWP指示符(BWP Indicator)实现的,DL BWP Switching通过下行Scheduling DCI(DCI Format 1_1)中的BWP Indicator触发,UL BWP Switching通过上行Scheduling DCI(DCI Format 0_1)中的BWP Indicator触发,虽然BWP Switching其实和终端的资源调度并没有直接的关系。这个方法的优点是避免增加一种新的DCI Format。终端在单位时间里能够完成的PDCCH盲检测(Blind Detection)的次数是有限的,需要搜索的DCI Format种类越多,每种DCI Format能分到的检测次数就越少。重用Scheduling DCI传输一些物理层指令(PHY Command)可以避免终端同时检测过多的DCI Format,节省有限的终端PDCCH盲检测次数。这种方法的缺点也是显而易见的:通常只有和终端有业务往来时才会发送Scheduling DCI,没有PDSCH、PUSCH调度时,是不需要发送Scheduling DCI的。如果在没有业务需要调度时发送Scheduling DCI,则为了传递一条PHY Command,需要把资源调度相关的Field(如TDRA、FDRA Field)都置零,相当于“空调度”,此时DCI中绝大部分Field都是无效的,对DCI的容量浪费很大。好在类似BWP Switching这样的PHY Command是UE-specific的,影响的只是一个终端的DCI开销。但如果是影响诸多终端的PHY Command也用UE-specific的Scheduling DCI传输,那DCI开销就浪费太多了。

因此,方案2也一直研究之中,首先关注的是针对小区级(Cell-specific)公共信息的公共控制信令(Common DCI),其次也关注容量很小的UE-specific指令。在LTE标准中的一个典型例子就是PCFICH信道,它通知的是整个小区的PDCCH Control Region的长度,因此用UE-specific DCI发送这个信息是很浪费的,也完全没有必要,因此专门设计了PCFICH信道。在NR研究阶段,是否需要保留类似LTE PDFICH这样的信道(PCFICH-like Channel),也是一个讨论的焦点。这样一个Common DCI除了可以用来发送Control Region的长度[即LTE中的CFI(Control Format Indicator,控制格式指示符)],还可以考虑用来发送时隙结构(Slot Format)、预留的资源(Reserved Resource)及对非周期信道状态信息(Aperiodic CSI-RS)的配置信息等。因此,5G NR标准引入了组公共控制信息(Group-common DCI),和UE-specific DCI配合使用。经研究,Reserved Resource(在5.7节具体介绍)、Aperiodic CSI-RS最终还是更适合在UE-specific DCI中传输,SFI是Cell-specific信息,最适合用Group-common DCI传输,而下行Pre-emption Indication、上行Cancellation Indication、TPC指令等信息虽然是UE-specific信息,但经过平衡考虑,最终决定采用Group-common DCI,其中一个原因是这些信息的尺寸较小。需要注意的是,用于PUSCH/PUCCH的TPC指令除了可以在DCI Format 2_2这个Group-common DCI中传输,也可以分别在DCI Format 0_1、DCI Format 1_1这两个UE-specific DCI中传输,可见小容量的UE-specific控制信息在UE-specific DCI和Group-common DCI中都可以传输,基站可以根据不同应用场景灵活选择,如在有上下行数据调度时可以顺便通过DCI Format 0_1、DCI Format 1_1发送TPC指令,在没有上下行数据调度时可以通过DCI Format 2_2发送TPC指令。

Group-common DCI虽然由一组UE公共接收,但它实际上是一个携带多个UE-specific控制信息的“公共容器”,由一个个的UE-specific信息块(Block)构成。以DCI Format 2_2为例,被配置了TPC-PUSCH-RNTI或TPC-PUCCH-RNTI的终端均可以打开这个“公共容器”,然后再从这个“公共容器”找出属于自己的TPC指令。如图5-47所示,假设一个DCI用于给4个终端传输TPC指令,则这个DCI包含4个Block,这个终端组中的终端分别被配置对应一个Block,每个终端接收DCI Format 2_2后,根据配置的Block编号(Block Number)读取对应的Block中的TPC指令,并忽略其他Block中的信息。

图5-47 通过Group-common DCI传输UE-specific控制信息