TD－LTE系统UE端PDCCH信道的研究与实现

李小文，罗 佳

(重庆邮电大学通信与信息工程学院，重庆 400065)

1 PCCCH简介

PDCCH(Physical Downlink Control Channel，物理下行控制信道)承载下行控制信息DCI(Downlink Control Information，下行控制信息)［1］，包括用于下行和上行数据传输的调度信息和上行功率控制信息等，是接收端用户实现数据解调的重要依据［1-2］。针对PDCCH所承载的调度信息和不同数据的传输模式，TD-LTE定义了11种不同的DCI格式［3］，每种格式的用途各不相同，每种DCI格式的比特长度是根据系统带宽和基站配置的天线端口数具体计算所得［2-3］。

为了支持链路自适应技术，并尽量降低终端盲检测DCI格式的复杂度，PDCCH以控制信道单元(Control Channel Element，CCE)为基本单元来进行资源分配［2］。每个CCE由9个REG组成，每个REG包含4个RE，每个RE对应2 bit(PDCCH采用QPSK调制，1个符号对应2 bit)，即一个CCE对应36个RE，72 bit。根据承载的DCI比特长度和信道状况，基站可以选择使用1/2/4/8个CCE来承载一个DCI，称为 CCE 聚合等级(CCE Aggregation level)［2］，这4 种聚合等级对应4种PDCCH格式0/1/2/3，如表1所示。

而且为了进一步简化译码的过程，LTE对CCE进行连续编号，0～NCCE-1。并且要求带有PDCCH格式的DCI格式的第一个CCE序号i应满足i mod n=0［2］。下行可用的总CCE资源NCCE=，NREG为下行子帧控制区域除去给CSRS、PCFICH和PHICH分配的资源后，剩下资源对应的REG个数［2］。

表1 TD-LTE系统支持的PDCCH格式

2 UE端PDCCH处理流程

接收端是发送端的逆过程，PDCCH接收端处理流程如图1所示。首先，接收端接收到发送端的数据后，进行解资源映射，将资源栅格中映射有PDCCH的信息提取出来。从初始位置开始判断资源粒子(k′，l′)代表的资源粒子组有没有被分配给PCFICH以及PHICH使用，如果没被占用则取出此资源粒子组。如果被占用则判断下一个OFDM符号的资源粒子组有没有被分配给PCFICH以及PHICH使用，直到L个OFDM符号，L由PCFICH的值决定。再回到第一个OFDM符号继续判断，以此类推，先时域后频域依次取出PDCCH资源粒子组。

图1 接收端PDCCH处理流程

将解映射得到的数据进行解四元符号组循环移位，发送端移位公式为

式中:Mquad=Msymb/4是四元符号组的数目;是小区ID号;是发送端移位后的数据;w(p)是发送端移位前的数据。根据式(1)，接收端只需把发送端移到前面的个数据重新移到序列后面即可。

把上面得到的数据进行解四元符号组交织，完成发送端交织前数据流的恢复。解交织的过程为:已知交织矩阵的列数为32，再根据四元符号组的数目，得到交织矩阵的行数和要添加NULL比特数。根据表2中列排列形式的值，依次判断该值是否大于要添加的NULL比特数，如果小于说明交织矩阵该列的第1行为NULL比特，此列的剩余行为数据，剩余行的数据依次从四元符号组序列中读取(每个数据为一个四元符号组)，依次类推可得到交织前的矩阵。然后按行读取，去除NULL比特，就得到所需数据。

表2 交织列变换表

由于本方案的解预编码和层映射模块放在了信号检测模块完成，所以经过解四元符号组移位和交织后的数据进入解调模块。

PDCCH是采用QPSK方式进行调制(表3)，接收端采用Max-Log-Map算法进行软解调［4］，直接将接收数据的实部、虚部分别代入下式，即

表3 QPSK调制映射

接收端采用的是软解调，所以要根据发送端伪随机序列c(i)的值来解扰。如果c(i)的值为1，则解调出来的数据d(i)乘以-1，如果c(i)的值为0，则接收到的数据d(i)乘以1。

通过以上各个模块，到解扰后可以得到一串数据，这串数据一般包含着多PDCCH信道的数据，即发送端信道复用的数据，得到这串数据，接下来的工作就是盲检，通过盲检测得到正确的发送端发送的DCI信息比特流。

1)根据PCFICH的CFI解码过程得到的CFI值，确定控制区域所占的OFDM符号个数，然后根据公式NCCE=计算得到可用于PDCCH的总的CCE数。

2)根据UE所处的状态，找到对应的RNTI类型，再查询协议36.213表7.1-5［5］和表4确定UE需要监视的DCI格式及其对应的CCE搜索空间类型，然后根据公式计算所需检测的DCI格式对应的CCE搜索空间的起始位置［4］。

表4 PDCCH搜索空间

3)选取聚合等级为L∈{1，2，4，8}的CCE资源，进行DCI盲检测。根据DCI格式支持的搜索空间类型，按照先公共搜索空间后UE专用搜索空间的顺序进行盲检测(图2)，接着计算对应搜索空间的起始位置，然后在对应搜索空间内按L由小到大(或由大到小)的顺序读取L个CCE数据，再进行解速率匹配，即恢复发送端咬尾卷积编码后的三路输出，然后Viterbi译码，即恢复发送端信息添加CRC后的比特流，最后进行CRC解扰及校验，如果CRC校验成功，则记录此DCI格式信息，否则起始位置向后偏移L个CCE，重复上述过程，执行下一次检测，如此循环，直到检测完该聚合等级L对应的所有PDCCH候选。若检测完一个聚合等级仍然没有CRC校验成功，则进行下一个聚合等级L的检测，直到UE获得了所需的DCI格式或者所有的聚合等级检测完为止。

图2 公共搜索空间及UE专用搜索空间的PDCCH候选盲检测尝试

将盲检测成功时记录下的DCI格式信息进行比特分离，即将DCI信息比特流按照发送端的比特位构成完成相应的分离，为PDSCH完成数据解析做准备。例如，对于DCI 0包含的比特信息有:资源分配类型指示位、资源块分配、子集选择、偏移量、调制编码方式、HARQ进程号、新数据指示、冗余版本号、PUCCH功率控制、下行任务索引指示位 DAI［3］。

3 PDCCH接收端处理的DSP实现

PDCCH信道的解资源映射作为一个单独的程序，然后进入PDCCH信道的主程序，主程序主要包括:解四元符号组循环移位和交织模块、解调模块、解扰模块、盲检测模块、解速率匹配模块、Viterbi译码模块、CRC校验模块、DCI比特分离模块。由于本方案的解预编码和层映射模块放在了信号检测模块完成，所以就不再写入PDCCH信道的主程序了。

3.1 解资源映射模块

首先，求出需要解出的四元符号组个数M，可得M=TxPDCCHSeqLen/4。对于这4个OFDM符号，每个所包含的RE个数存入REG矩阵(根据天线端口数的不同而不同)。求出前4个OFDM符号中没有被PCFICH和PHICH占用的REG 编号，分别存入矩阵N1，N2，N3，N4中，将PDCCH所占用OFDM符号的频域起始位置统一初始化为1，即j_freq(1，i)=1。从第一个OFDM符号开始判断，令i=1，判断第i个OFDM符号的时频域位置情况，当满足当下REG序号没有被PCFICH或PHICH占用，且当下频域是PDCCH占用的OFDM符号中的最小时，完成当下REG中PDCCH的数据提取，完成解映射。若时频大小不满足此条件，则进入下一个OFDM符号的判断，依次循环判断，直至M个四元符号组都完成解映射。PDCCH资源映射过程如图3所示，解映射是一样的规则。

图3 PDCCH资源映射过程

在DSP实现中，为验证数据的正确性，将MATLAB仿真过程信号检测模块的输出数据流转换成CCS数据导入解资源映射模块，并将运行输出结果导出，分别取出其实部、虚部的表示，在MATLAB中分别进行转换、合并，最后将输出数据与MATLAB中PDCCH解资源映射输出数据进行相除，得到其数据比对值。由图4可看出比对值呈一条直线，说明CCS与MATLAB每个点的相对大小是一致的，正确完成了PDCCH的解资源映射，验证了本实现方案的正确性和可行性。在信号检测模块，由于要进行数据的计算，所以在转化时的量化操作会存在精度损失，但是只要波动平缓，不出现某个点或某些点的严重偏离，就说明精度损失是一致的［6-7］，数据得到正确的计算。

图4 数据比对值

3.2 解四元符号组循环移位模块

输入的数据序列长度为RxWp_shiftlen，四元组符号个数GroupNum=RxWp_shiftlen/4，提取这部分需要恢复移至前面的数据段:((GroupNum-j)×4+1):RxWp_shiftlen，同样需要将发送端移至前面的数据段移至后面，提取这部分需要恢复移至后面的数据段:1:(GroupNum-j)×4，这样重新移位拼组后得到最终的Rxfour_map()序列，即恢复发送端循环移位之前的序列。

3.3 解四元符号组交织模块

首先得到输入序列的长度TxPre_OutLen=length(dk)，四元符号组个数Mquad=TxPre_OutLen/4，交织矩阵列数:colm=32，行数R=ceil(Mquad/32)，空比特个数N=R×colm-Mquad，从交织表的第1列开始处理，i=1，对于第i列，由交织后序列(即输入序列)及交织表计算得到发送端四元符号组交织前的数据流相应元素的存放位置c。分两种情况计算:对于交织表的当下列k≤空比特个数N，c=((32-N+k-1)×4+d)+(b-1)×32×4，其中，b表示已处理的行数，d表示四元符号组元素序号;对于交织表的当下列k＞空比特个数N，c=(k-N-1)×4+d+(b-1)×32×4。依次处理，直至处理完32列，即i=32。

3.4 解调模块

解调部分采用软解调，用16 bit表示1个输入的软信息，高8位为符号扩展位，低8位为有符号的软信息。首先判断是单天线、双天线还是四天线，由于单天线和双、四天线在预编码上的处理不同，所以需要分别对判断值赋值。解调时，复值符号的实部解调为奇比特位，虚部解调为偶比特位。得到的软比特信息按先前的发送数据顺序排列。

3.5 解扰模块

将0x80000001作为x1初始的32 bit赋给另一个寄存器。计算生成输出序列长度循环次数放在寄存器B0中，x1，x2生成1600 bit所需要的循环次数放在B1中，按32 bit为单位，分别计算x1以及x2序列，并用新生成的32 bit去更新两个32 bit寄存器，同时再将新生成的两个32 bit数进行异或。根据计数器的值判断生成的比特数是否为1600，若是，则将上面异或得到的结果作为扰码序列的一个字输出，作为尾比特进行处理。若c(i)的值为1，令解调输出序列乘以-1;如果c(i)的值为0，令解调输出序列乘以1，完成解扰。

3.6 盲检测模块

在DSP软件实现时，依据DCI格式支持的搜索空间类型:DCI 1C、3、3A 只支持公共搜索空间;DCI 1、1B、1C、1D、2、2A、2B只支持UE 专用搜索空间;DCI 0、1A 支持两种搜索空间，本文设计了3个子函数分别对应上述3种情况的DCI格式盲检测:int Blind_detectDCIcommonspace(void)，int Blind_detectDCI_UEspecific(void)，int Blind_detectDCI1A(void)。同时，将 RNTI值、传输模式［4］均设为枚举型，将RNTI、传输模式、DCI格式都依次编号。

本文采用C语言对上述3个函数进行具体的DSP设计和实现，下面以DCI 1A为例，它支持2个搜索空间，其盲检测过程对应子函数:int Blind_detectDCI1A(void)，它的程序具体实现步骤为:

1)先搜索公共搜索空间。其搜索的起始位置编号为0的CCE，然后从该位置取8个CCE的数据，接着以格式1A的比特长度和8个CCE对应的比特长度进行解速率匹配，再进行Viterbi译码和16位CRC校验。

2)若CRC校验成功，则表明检测到的DCI格式的比特长度跟DCI格式1A一样，但是由于格式0和格式1A的长度相同，所有需要进一步判断检测到的数据首个比特的flag标志位，如flag为1，则判为格式1A，否则判为格式0，则转入下一步。

3)若CRC校验失败，则CCE起始位置偏移8个CCE，再取8个CCE的数据，同理通过解速率匹配、Viterbi译码、16位CRC校验模块，如此循环，直到CRC校验成功或循环次数达到PDCCH候选集2为止，若CRC校验成功，则返回相应的DCI格式标志位为1。

4)若聚合等级L=8搜索完后，仍没有成功，则重新设定搜索起始位置为编号为0的CCE，再按照步骤1、2、3的算法进行聚合等级L=4搜索。

5)若DCI格式1A在公共搜索空间搜索没有成功，则转入UE专用搜索空间进行搜索，即分别计算每个聚合等级L=8、4、2、1的起始位置，然后以该起始位置依次取L个CCE数据进行类似上述公共空间的盲检测循环，直至搜索到DCI格式1A。

在CCS中实现时，将DCI 0的数据输出首地址存为RxDCI0，将其他的DCI格式数据输出首地址存为RxDCI1，直接寻址即可对数据流进行操作。对11种DCI格式分别依次赋值以区分盲检测出的是哪种DCI格式，为DCI比特分离做准备，节省了寄存器的使用。

3.7 解速率匹配模块

与发送端相对应，接收到解扰后的数据进行解速率匹配，然后解卷积编码的子块交织，最后得到3路比特流，作为Viterbi译码器的输入数据。

输入数据的首地址为RxDeRateMatch_InputData，输入数据长度RxDeRateMatch_E分别存入寄存器A4，B4中。

1)解速率匹配:从盲检搜索得到一串长度为E的数据，如果E≥K′(K′为比特收集的长度)说明发送端将数据重复了，则直接截取前K′个值作为解速率匹配用即可;如果E＜K′，说明发送端将数据截短了，则将数据后面添加(K′-E)个0，然后再作为解速率匹配用的数据。

2)从1)得到的数据即为发送端比特收集后的K′个数据(K′=3D)，因为发送端是打掉了NULL比特的(实际DSP实现时根本没加入NULL比特)，所以只需将这K′个数据拆分成相等的3路数据(K′/3)，各自进行解子块交织即可。在解子块交织时可像发送端一样，3路通过偏移地址并行操作，一并完成，最后输出的数据仍然存放在一个首地址指示的存储空间即可，以备Viterbi译码模块调用。

3)解交织:首先应该有一个DCI格式的原始数据的长度值L，按照发送端添加CRC长度得到卷积编码前的长度，亦即编码后各路码流的长度D，根据D≤(其中=32)，求出交织矩阵的行数，然后求出NULL比特的个数:N=-D，从而构造

D出交织矩阵，将步骤2)中的K′/3个数据按列读入、按行读出进行反交织，最后解出各路数据。

3.8 Viterbi译码模块

Viterbi译码算法作为一种最大似然算法，译码的基本原理如图5所示，依次标准的Viterbi译码算法总共分4个部分组成:分支和累积度量计算、加比选操作、幸存路径存储、路径回溯。

图5 Viterbi译码基本原理图

根据MATLAB仿真程序算法，入口参数有:待译码的3路输入数据的首地址、输入数据长度(单路的长度)、输出数据首地址、路径度量state_metric动态表首地址、幸存路径survivor_state动态表首地址、幸存路径状态序列state_sequence首地址。

需要开辟的空间(最小单元1 byte，每个数据占1 byte):

1)输入矩阵input(当前状态，下一状态)=输入比特，可由状态转移矩阵求得规律如下:

判断公式:(下一状态-(当前状态＞＞1))＞0，则输出1;否则，输出0。输出矩阵output(当前状态，输入比特)=常量表64×2，DSP中存储:在DSP实现中只需存储0，2，4，6，8，…，60，62 行的第一个元素即可，共32 个值。

2)路径度量state_metric一维表64×2。

3)幸存路径survivor_state(当前时刻状态，当前时刻)=64×3×K，K为码块长度，加比选遗留下所有路径，DSP中存储:先存第1列，再存第2列，以此类推，依据此表回溯，得到幸存路径状态序列state_sequence。

查找规则:前一时刻状态的偏移地址=当前时刻×64+当前时刻状态。

4)幸存路径状态序列state_sequence，一维表，即最后检查此表码块首末状态是否相同，按照此表译码输出。

在DSP软件实现中，在码块大小为50 bit时，通过在CCS3.3上仿真运行程序，在理想信道情况下，整个译码过程耗时46256个指令周期，此时因为输入数据没有错误，译码程序只迭代了一次就得到了正确译码输出;在信道条件极差的情况下，译码程序需迭代3次才能译码输出，此时译码耗时为132455个指令周期。TMS320C64x芯片的主频一般为1 GHz，一个指令周期耗时为1 ns，因此本DSP实现可达到约377.49～1080.90 kbit/s的译码速率，且误比特率相当低，满足系统的译码要求。

3.9 CRC校验模块

计算得到输入比特流长度lengthdecoder，通过CRC类型得知校验多项式CrcPoly及多项式长度Lengthgen，根据加扰情况来确定加扰序列RNTI，并根据RNTI，将CRC序列进行解扰，将解扰后的CRC序列部分再次拼接到信息序列后，将组合后的序列和CRC校验多项式进行按位异或，若结果为0，则CRC校验正确，说明DCI为发送端所发送的;否则，盲检测失败。如果存在另一种DCI格式，则进入下一个DCI格式的判断。

3.10 DCI比特分离

此程序的实现主要是利用移位的思想以及用于比特位存储的寄存器的分配方式。对于DCI格式的每个信息，都设置为全局变量。通过寻址的方式来进行这些相应信息的比特位存储。比如，在提取MCS信息后，将MCS这个全局变量的地址进行临时存放，然后将信息存到这个地址指向的寄存器存储空间即可。同理进行其他信息存储的操作。

通过程序运行及调试，比对DCI的每个信息构成，得出的最终结果与发送端的DCI信息一致，从而验证了UE端PDCCH处理方案的可行性。

4 性能分析与总结

在DSP实现中，通过指令并行，尽量优化程序循环体，减少或消除程序中的“NOP”指令［6-7］，以常规 CP 为例，各个模块的运算cycles数统计如表5所示。

表5 各模块的执行周期数 cycle

可看出，当运用TMS320C64x DSP芯片实现时，完全可以满足LTE系统实时性信号处理的要求。

本文从理论分析出发，根据TD-LTE系统特性，提出了一种简单的DCI接收的实现方案，详细讲述了在DSP中的实现方法，并在TMS320C64x DSP芯片上加以实现。程序运行结果表明，提出的方案能够满足TD-LTE系统的需求，具有可行性和高效性。该方案已经应用于TD-LTE射频一致性测试系统的开发中［8］。

［1］沈嘉，索士强，全海洋，等.3GPP长期演进(LTE)技术原理与系统设计［M］.北京:人民邮电出版社，2008:280-315.

［2］3GPP TS 36.211 v9.1.0，3rd Generation partnership project;technical specification group radio access network;evolved universal terrestrial radio access(E-UTRA);physical channels and modulation(Release 9)［S］.2010.

［3］3GPP TS 36.212 v9.1.0，3rd Generation partnership project;technical specification group radio access network;evolved universal terrestrial radio access(E-UTRA);multiplexing and channel coding(Release 9)［S］.2010.

［4］张红霜.LTE系统中的软解调研究［J］.电子测试，2010(6):6-9.

［5］3GPP TS 36.213 v9.0.0，3rd Generation partnership project;technical specification group radio access network.evolved universal terrestrial radio access(E-UTRA).physical layer procedures(Release 9)［S］.2009.

［6］TI Incorporated.TMS320C64x/C6-4x+DSP CPU and Instruction Set ReferenceGuide［EB/OL］.［2012-12-20］.Http://www.ti.com.cn，2008.

［7］TI Incorporated.TMS320C6000系列DSP编程工具与指南［M］.田黎育，何佩琨，朱梦宇，译.北京:清华大学出版社，2006.

［8］3GPP TS 36.521 v9.1.0，3rd Generation partnership project;technical specification group radio access network;evolved universal terrestrial radio access(E-UTRA);user equipment(UE)conformance specification Radio transmission and reception Part 1:conformance testing;(Release 9)［S］.2010.