NBIoT下载速率低提升案例.docx
- 文档编号:23333299
- 上传时间:2023-05-16
- 格式:DOCX
- 页数:13
- 大小:1.35MB
NBIoT下载速率低提升案例.docx
《NBIoT下载速率低提升案例.docx》由会员分享,可在线阅读,更多相关《NBIoT下载速率低提升案例.docx(13页珍藏版)》请在冰豆网上搜索。
NBIoT下载速率低提升案例
NB-IOT下载速率低提升案例
一、【问题描述】
在炎刘镇HN-寿县-炎刘工业园区-157245_210小区进行测试时,好点平均下载速率低,在8.2kbps左右。
测试截图如下:
二、【NB-IoT原理】
2.1NB-IoT概念
NB-IoT(NarrowBandInternetofThings)基于蜂窝的窄带物联网,只消耗约180KHz的带宽,可直接部署于GSM网络、UMTS网络或LTE网络,以降低部署成本、实现平滑升级。
3GPP为NB-IoT定义了3种部署模式:
“In-band模式”与传统LTE小区共享软硬件资源,利用原有LTE小区的一个或几个PRB作为NB-IoT载波;
“Stand-alone模式”不与传统LTE小区共享软硬件资源,利用例如GERAN系统中的频段资源,替换其中的1个或几个GSM载频,作为NB-IoT载波;或者建立一个全新的NB-IoT小区;
“Guard-band模式”与传统LTE小区共享软硬件资源,利用LTE载波保护频带内未用资源作为NB-IoT载波。
中国电信主要采用“Stand-alone模式”,本文讲述的内容均为NB-IOT的“Stand-alone模式”方面内容。
2.2NB-IoT组网方案
R13中NB-IoT支持频段为:
1、2、3、5、8、12、13、17、18、19、20、26、28、66。
NB-IoT部署RRU硬件支持的类型:
NB-IoT部署
频段
Stand-alone
In-band
中国电信
B5
FRCJ、FXCB
---
中国移动
B8
FXDB、FXDA
FXDB、FHDB、
中国联通
B8
FHDB
FXDB、FHDB
在B5频段上,Stand-alone模式下,现场最大硬件配置为:
ØFSMF+2*FBBC+6*FRCJ(12cell,6个1.4M-normalLTEcell,6个200KNB-IoTcell)
✧FSMFRF1/2/3---RCFJ,1.4M-normalLTE,2T2R;200K-NB-IoTcell
✧FBBC1RF1/2/4---RCFJ,1.4M-normalLTE,2T2R;200K-NB-IoTcell
✧FBBC2
2.3NB-IOT主要信令流程及部分信令解析
2.3.1Attach流程
NB-IOT的attach流程主要包括RRC建立、鉴权/安全模式、attach完成几个阶段。
2.3.2主要信道重复次数计算
NPDCCH重复次数计算:
a.查找“rrcConnectionSetup”中“npdcch-NumRepetitions-r13”的值,如下图值为8。
b.查找在“LTENB1ML1GMDCIInfo”中“DLGrantPresent=TRUE”时DCIRepetitionNumber的值,如下图值为1。
C.根据NPDCCH配置表查询,如npdcch-NumRepetitions-r13=8选择“Rmax>=8”行,DCIRepetitionNumber=1选择“01”行,对应“R”值为Rmax/4=8/4=2次,NPDCCH重复次数即为2。
NPDSCH重复次数计算:
查找在“LTENB1ML1GMDCIInfo”中“DLGrantPresent=TRUE”时RepetitionNumber的值,如下图值为0。
NPDSCH重复次数=2的0次方=1。
NPUSCH重复次数计算:
查找在“LTENB1ML1GMTXReport”中RepetitionNumber的值,如下图值为1.NPUSCH重复次数即为1。
三、【解决措施】
NB_IoT的业务需求不追求极限的速率。
因为NB_IoT是单工的方式实现。
在上下行的传输的过程中有确定的调度和数据传输的模式和时序安排。
要想达到较高的速率需要尽量减少传输中可优化的间隔,在时域上达到最大的利用率。
以及其他方面,使用更高的MCS,尽量控制各信道的重复次数、减少重传。
3.1NB_IoT速率的估算
上行:
一个上行发送周期的长度包括NPDCCH和NPUSCH的传送时长,以及之间的Delay。
如图示:
时长为:
2ms(2xNPDCCH)+8ms+32ms(NPUSCH)+3ms=45ms;
理论的持续速率为:
680bits/45ms=15.1kbps。
下行:
下行周期的时长为:
27ms;
理论的持续速率为:
680bits/27ms=26kbps。
每次传送以NPDCCH为起点,必须考虑NPDCCH的搜索空间,也就是一次数据调度发送(上行)和接收(下行)的周期。
需要由上述发送或接收的时长和用户搜索空间(USS)的较大值决定。
在下面的图中,用户搜索空间设置为32ms时,上行最小的调度周期会在满足NPDCCH搜索空间和传输周期,实际情况会是调度实际发生会是64ms。
此时理论持续速率为:
10.625kbps。
下行的传输周期在32ms以内,理论上可以匹配用户搜索空间的长度,但下行资源中还包含MIB,PSS,SSS,SIB等资源的占用,有时也会导致实际的调度周期超过32ms。
所以持续下行速率为10.6~21.2kbps。
在NB_IoT中,调度的频率是影响速率的重要因素。
调度的频率主要由用户搜索空间决定,但一个传输所需要的NPDCCH和分配的业务信道,以及相应要求的间隔必须可以容纳在一个搜索空间,否则就如上面的例子中一次传输占用了两个搜索空间。
即,实际调度的频率下降了。
因此,在NB_IoT中网络中,为了达到或接近理论的上下行速率,需要优化用户搜索空间T=Rmax*G。
Rmax:
npdcchMaxNumRepRa
G:
npdcchStartSfRa
优化设置调整如下。
CE0的搜索空间为32ms,CE1和CE2为64ms。
搜索空间偏置(npdcchOffsetRa)未证明对实际调度有明显影响。
待后续研究发现。
搜索空间T的值得确定与NPDCCH,NPUSCH,NPDSCH的重复次数有关,详见重复次数参数部分的补充。
3.2影响过程和速率的补充参数
RACH过程定时器
冲突解决定时器(raContResoTimNB)监控MSG4是否在计时器超时前收到;RA响应定时器(raRespWinSizeNB)监控MSG2是否在计时器超时前收到。
这两个定时器监控RACH过程,如果冲突解决定时器超时,此次RACH随机接入尝试失败,如未达到最大nprachMaxNumPreambleCE,重新进行RACH过程。
这两个定时器的原则是即保证有足够的尝试等待时间,有避免过长的无效等待,缩短随机接入过程重试(MSG1)的间隔。
在目前的配置下,在CE0的重试间隔是1280ms。
MAC层定时器参数
MAC层定时器参数tReTxBsrTimeNB,定义了在RRC建立时(Msg4)所携带的BSR信息没有得到响应,在定时器规定的时间重发。
此种现象在前期测试中尚未发现,优化的必要性不大。
MAC层定时器参数logicalChanSrProhibitTimerNB,定义了上行发包完成后,下一个数据包来到后启动RACH过程的时间间隔。
此参数对于上行灌包业务的速率有较大影响。
设置值较小时,现象上表现为上行发包业务的连续性好,速率较好。
(也需要与调度周期匹配)。
目前三个覆盖等级均设置为pp8,等待时间实际为256ms,512ms,512ms。
四、【优化方案实施与效果】
将HN-寿县-炎刘工业园区-157245_210小区进行如下配置参数调整。
修改相关参数优化后,好点下行平均速率在13.5kbps左右,得到明显提升。
中点、差点也较之前有明显提升。
调整后好点测试截图如下:
调整前后指标对比如下:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- NBIoT 下载 速率 提升 案例