精品文档SA盲检出错CCE分配失败导致下行调度问题.docx
- 文档编号:27112044
- 上传时间:2023-06-27
- 格式:DOCX
- 页数:12
- 大小:474.68KB
精品文档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相关配置纳入日常参数核查,避免其他原因导致参数配置错误,影响到用户感知。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 精品 文档 SA 检出 CCE 分配 失败 导致 下行 调度 问题