精品文档SA盲检出错CCE分配失败导致下行调度问题.docx

精品文档SA盲检出错CCE分配失败导致下行调度问题.docx

《精品文档SA盲检出错CCE分配失败导致下行调度问题.docx》由会员分享，可在线阅读，更多相关《精品文档SA盲检出错CCE分配失败导致下行调度问题.docx（12页珍藏版）》请在冰点文库上搜索。

精品文档SA盲检出错CCE分配失败导致下行调度问题

SA盲检出错CCE分配失败导致下行调度问题

SA盲检出错CCE分配失败，导致下行调度问题案例

【摘要】随着SA网络的即将商用，商用前SA网络各项性能验证是当前的主要目标，良好的用户感知体验，是树立中国电信5G品牌形象的基本。

5GSA商用给用户视觉带来最大的冲击莫过于高出4G网络10倍的下行速率体验，在合肥对各SA网络网格进行拉网测试时发现，在肥东县某区域出现在切换后调度包数不足，导致的下行速率下降，本案例通过对各项测试指标及参数、信令分析得出为盲检出错CCE分配失败，导致调度下降从而影响到下行速率问题，为后续相关问题分析建立优化基础，进一步提升用户感知的5G高速率。

【关键字】SA；CCE；调度；盲检；

【业务类别】网络优化

一、问题描述

在合肥肥东区域进行SA网格拉网测试时，发现NR小区PCI552等多个小区存在下行调度包数不足的问题，其下行调度包数大概率下降到1400或以下，严重影响了下载速率，如下图所示：

图1NR_DL_Rate_MAC速率变化趋势

图2NR_PDCCH_DL_Grant_count调度包数变化趋势

二、分析过程

2.1基础数据分析

通过分析切换前的正常小区和本小区的各项数据，DL_MCS值正常波动，如图3所示；

图3NR_DL_MCS变化趋势

DL_RB数在小区切换前的正常小区和本小区后，RB值变化无异常波动，如图4所示；

图4NR_DL_RB变化趋势

RI值切换前的正常小区和本小区后，RI至稍有波动，约在3左右波动，如图5所示；

图5NR_RI_DL变化趋势

2.2上行反馈对比

通过比对问题切换前后的PUSCH新到BLER值也正常波动，无明显劣化迹象，如图6所示；

图6NR_PUSCH_BLER变化趋势

再对问题切换前后上行RB数及上行调度包数波动值，波动均较为稳定，无异常，如图7所示；

图7UL_RB和UL_Grant_Count变化趋势

2.3现场定点测试

在NRPCI为552的小区下，进行定点速率测试验证，发现包数可以达到1600包；但是包数存在不稳定的情况，仍然存在包数小于1400包的问题。

2.4测试信令分析

对比正常调度小区和异常小区的重配消息，发现异常小区的CCE=4的候选集配置为2（nrofCandidatesAggregationLevel4：

聚合度是4对应的候选集个数），正常小区的CCE=4的候选集配置为4。

对比其他异常小区，发现其CCE=4的候选集均配置为2，如下图8所示；初步怀疑为候选集变小，导致盲检出错，进而CCE分配失败。

图8CCE=4的候选集错配为n2

2.5CCE原理简述

ØCCE组成

CCE，全称ControlChannelElements，是PDCCH（physicaldownlinkcontrolchannel）信道的基本组成单位，每个CCE由9个REG组成（参考下文中的示意图）。

CCE只用作PDCCH信道的映射，不用于小区参考信号、PCFICH信道和PHICH信道的映射，因此，组成CCE的REG或RE是不包括小区参考信号、PCFICH信道和PHICH信道等已经占用的RE或REG的。

如果用N_REG变量来表示除去PCFICH、PHICH信道占用之后还剩下的REG个数，那么每个下行子帧CCE的个数N_CCE=floor（N_REG/9）。

比如某个子帧控制区域总的REG个数等于88，其中PCFICH信道占了4个REG，PHICH信道占了6个REG，那么用于PDCCH的CCE个数=（88-4-6）/9=8.67=8个（向下取整）。

ØCCE的盲检测和搜索空间

在LTE里，每个PDCCH信道会映射到不同聚合等级（或不同个数）的CCE中。

在标识PDCCH信道的时候，除了使用聚合等级这个参数外，还需要CCE的起始位置索引这个参数。

由于下行或上行资源的动态调度是在eNB侧进行的，聚合等级和起始位置都由eNB侧分配，因此在某个下行子帧里，终端事先无法确切的知道PDCCH占用的CCE的聚合等级是多少，以及CCE的起始位置索引在哪里。

所以，对于终端来说，每次都是通过盲检测来获取PDCCH信道即CCE的位置的，而盲检测所消耗的时间是比较多的，因此协议也做了一些降低盲检测时间的约定：

（1）对于聚合等级，前文已经有描述，协议只约定了4种CCE聚合等级，即1、2、4、8，降低了盲检的可能性。

（2）对于不同的搜索空间（searchspace），允许使用的CCE聚合等级不同，候选位置（NumberofPDCCHcandidates）也是有限的，具体见下表所示。

对于UE专用空间（UE-specificsearchspace），可以使用1、2、4、8这四种聚合等级，而在公共空间（commonsearchspaces），综合考虑抗干扰和盲检测处理时间，只使用4、8这两种聚合等级。

CCE聚合等级最大是8，而可以使用的CCE总个数有可能比较多，比如可用CCE总个数N_CCE可以等于88这种值，因此聚合等级为8的PDCCH信道在CCE可用个数为88的控制区域中，存在着很多的可能性位置，这些可能的位置，我们称之为“候选位置集（setofPDCCHcandidates）”。

为了降低终端的盲检测时间，这些“候选位置”个数也是有限的，如上表所示，比如在公共搜索空间中，聚合等级为8的PDCCH信道，候选的位置只有2个。

如果终端在所有的候选位置经过盲检测，都没有找到PDCCH信道，则退出该盲检侧过程。

CCE候选位置在CCE空间中的位置如下图所示。

组成PDCCH信道的所有候选位置的每个CCE位置，都可以通过下面的公式计算得出。

从公式中可以看到，某个PDCCH信道的所有候选位置的CCE位置，与该PDCCH信道的聚合等级、搜索空间类型、子帧号、可用CCE总个数、RNTI等参数有关。

比如，某个PDCCH信道的聚合等级是4、属于公共空间、N_CCE=88、子帧号=0，从上文的表Table9.1.1-1中可以看到，此PDCCH信道的候选位置有4个，因此可以得到参数：

L=4，Yk=0，m=0～3，N_CCE=88，i=0～3。

通过上面的公式可以计算得到：

PDCCH候选位置1的CCE位置（m=0时的情况）：

第一个CCE位置：

4*[0mod（88/4）]+0=0；第二个CCE位置：

4*[0mod（88/4）]+1=1；第三个CCE位置：

4*[0mod（88/4）]+2=2；第四个CCE位置：

4*[0mod（88/4）]+3=3。

PDCCH候选位置2的CCE位置（m=1时的情况）：

第一个CCE位置：

4*[1mod（88/4）]+0=4；第二个CCE位置：

4*[1mod（88/4）]+1=5；第三个CCE位置：

4*[1mod（88/4）]+2=6；第四个CCE位置：

4*[1mod（88/4）]+3=7。

PDCCH候选位置3的CCE位置（m=2时的情况）：

第一个CCE位置：

4*[2mod（88/4）]+0=8；第二个CCE位置：

4*[2mod（88/4）]+1=9；第三个CCE位置：

4*[2mod（88/4）]+2=10；第四个CCE位置：

4*[2mod（88/4）]+3=11。

PDCCH候选位置4的CCE位置（m=3时的情况）：

第一个CCE位置：

4*[3mod（88/4）]+0=12；第二个CCE位置：

4*[3mod（88/4）]+1=13；第三个CCE位置：

4*[3mod（88/4）]+2=14；第四个CCE位置：

4*[3mod（88/4）]+3=15。

需要注意的是，根据上面的公式可以得到，公共空间的CCE范围是0～15，但UE专用空间的范围也可以落在0～15中，因此公共搜索空间和UE专用搜索空间是可以互相重叠的。

在同个子帧时刻，一旦某个CCE已经被分配，则不能再分配给其他用户。

以下图为例，在同个子帧，如果终端A分配的CCE范围是16～23，那么eNB就不能给终端B分配16～23这个范围的CCE。

正是由于在相同子帧里CCE位置的不可复用，或者说独占性，因此当小区中有多个UE需要传输数据，此时即便RB资源足够多，也可能会因PDCCH信道的CCE位置冲突而导致无法调度某个或某些UE。

比如说，某个系统的业务总流量可以达到Pbps，现有10个UE进行数据传输业务，每个UE的业务量占用的RB均较少，此时10个UE总的流量记为Mbps，可能就会有M

对于SIB、寻呼、RAR、TPC、集群组呼这些共享信道对应的PDCCH，需要在公共空间进行CCE的调度，其它的则在UE专用的搜索空间中调度。

（3）对于CCE起始位置索引，协议规定，某个PDCCH信道的起始位置索引，必须能整除CCE聚合等级。

比如某个PDCCH信道的CCE聚合等级是4，那么这个PDCCH信道的CCE起始位置索引可能是0、4、8、...等等，不能是2、3、5这种不能整除4的值。

如下图所示。

2.6CCE参数修改验证

修改CCE=4的候选集为4进行对比验证，如图11所示；UME网管修改位置PDCCHConfig参数_SearchSpace_聚合度是4对应的候选集个数；

图11CCE=4网管修改位置

修改后从测试数据统计来看，其调度包数统计均正常，统计结果为1600包左右，如下图12、13所示。

图12修改CCE后下行调度包数稳定在1600包左右

图13修改后速率基本在1000Mbps左右

核查其他异常小区，发现对应的CCE=4的候选集均配置为2。

修改该参数后进行拉网复测，所有调度包数均可达到1600包，问题得到解决。

三、解决措施

（1）该问题主要为参数配置问题，小区的CCE配置为4CCE，对应的候选集配置为2，导致可用的候选集减少，盲检出错概率增加，引起CCE分配失败导致；

（2）修改CCE=4对应的候选集为4（新版本默认推荐参数），问题得到解决；

（3）如果出现类似问题，可核查是否对应的候选集出错引起异常。

PS：

SearchSpace->nrofCandidatesAggregationLevel4（UE-specific），聚合度是4对应的候选集个数：

聚合度是4对应的候选集个数。

四、经验总结

SA下行速率影响的因素有很多，本案例通过对测试数据的基础分析、相关指标及参数、信令进行分析得出，CCE对应的候选集配置过小导致可用的候选集减少，盲检出错概率增加，引起CCE分配失败的风险，通过本案例的分析得出CCE配置会严重影响到下行调度包数，从而影响下行速率，通过本次分析结果，后续需要将CCE相关配置纳入日常参数核查，避免其他原因导致参数配置错误，影响到用户感知。