案例-NB-IoT高负荷小区容量及底噪问题分析优化实践案例

杭州NB高负荷小区容量及底噪问题分析优化实践案例一,问题描述NB-IOT网络具有大容量的特点，实验室模型下理论评估支持单小区5万个终端在网。但本周杭州NB现网发生一起1000多个用户堆积在同一区域时，NB网络指标明显恶化，RSSI显著抬升，以至于NB网络无法使用的问题，我们对该区域NB用户量和NB容量、以及小区底噪相关问题进行分析探讨。二问题分析2.1大量NB终端导致网络无法使用6月下旬开始杭州某区域周边多个NB-IoT小区RRC尝试次数总和由100次以下突然上升到总和接近20万次/天，同时RRC连接成功率明显恶化，最低小区RRC连接成功率低于20%，对网络指标造成明显影响：问题区域NB-loTRRC连接尝试次数I?』R(nI?』R(n日nJ1°与E党。叶岑管内宙色«曷LnEGolcomE葛自，E"色&党&G?comEW含，co目品上CT%拓S上甲巴窝2，岑舀MIT，导co!—I屋壬自，％日壬，岑羿M耳导COI—I屋日含，co!—IDCU兰上?胃拓二ooow2,岑8冒号导COI—I屋BO上甲留窝G色，8竟胃，导COI—I屋吕言，00代1卜H杭州◎馆-MH209LFH_杭州KK馆-NE21DLF_H_杭［IfiXX馆-NB_21LLF_H_杭州XX酒店-NB.212LF_H_^!)f{XX酒店-NB_213^—LF_H_杭州XX酒店-

通过与多方NB设备厂家以及基站用户监控，并通过现场排查，最终发现导致该区域问题区域NB小区RRC连接成功率LF_Hj^州KX馆-N0_209—□=JL杭尚XX馆4JB_210LF_H_tni通过与多方NB设备厂家以及基站用户监控，并通过现场排查，最终发现导致该区域问题区域NB小区RRC连接成功率LF_Hj^州KX馆-N0_209—□=JL杭尚XX馆4JB_210LF_H_tni州XX馆-NB_211LF_H_杭州XX酒店-NB_212LIH_杭州XX酒店-NBJ13LIH.杭蝌XX酒店-NB_”4上图：小范围内堆积NB终端超过1200台（每箱60台*>20箱）

NB-loT小区15kHz®度下上行每个子载波上检测到

的干扰噪声的平均值（毫瓦分贝）853,5^0^8..^舀言曲国号胃日&曲国ooml:sr-?ssooga.853,5^0^8..^舀言曲国号胃日&曲国ooml:sr-?ssooga.与ssooa舄土Q-8ICK00图OE土Q-8ICKtwrnIwLiQ-STtKOCKO用土Q-8TtKconMgQgT—ro?00-00ddQ,舛瓷8ms备soosil田心。-ssz8SIIMGQ-BItKoon幻舛宏8£胃.岑oooz8日SQOOOZ00-00胃品母舛MooaIZ-gQ-sgzsd{K.qQ.BT—lw8典57富-gzzss^is^0-u

-2-4-14D大量NB设备导致NB小区底噪明显抬升由于该区域不但有新堆放的大量NB设备，附近小区还有300台智能消防烟感终端，以及100台以上已安装的智能地锁设备，即该区域NB-IoT用户数二超过1200临时堆放设备+300以上智能烟感+100智能地锁＞1600台设备对问题区域（堆放终端的地点）进行NB-IoT网络覆盖测试，发现该区域最强NB小区RSRP高达-50dbm,占用该小区时SINR在20以上，即NB网络覆盖质量良好，可排除网络覆盖差引起区域指标差的问题。在排除覆盖问题之后，需要对该区域NB小区指标恶化的原因进行网络容量方面排查。

2.2NB-IoT网络容量计算从公开资料来看，NB-IoT比2G、3G、4G有50-100倍的上行容量提升，在同一基站的情况下，NB-IoT可以比现有无线技术提供50-100倍的接入数。200KHz频率下面，根据实验室情况下仿真测试数据，在一般模型下，单个基站小区可支持5万个NB-IoT终端接实际上，NB-IoT单小区仅有180KHz带宽，仅相当于LTE单个PRB的资源，NB-IoT射频带宽为200KHz，下行速率:大于160kbps，小于250kbps，上行速率:大于160kbps，小于250kbps，NB-IoT是一个名副其实的低速网络。如果真有5万终端在线、下行250Kbps计算，如果可以同时产生业务传输，那平均下行速率仅5bps，传输1K数据需200秒以上，这在现实中是不切实际的。NB-IoT网络之所以支持大量用户同时在线，正是建立在NB业务低功耗、短暂唤醒、对时延性不明感、且可大量重传（最多可重传200次）的基础上，但实际情况下，不同行业不同业务的NB-IoT终端在网络实时性、唤醒周期、传输数据大小上都具有很大差异，不能简单以"5万用户"等固定值来评估NB小区容量。为了增强下行和上行覆盖，NB-IoT的NPDCCH、NPDSCH、NPUSCH、NPRACH等物理信道可以根据覆盖等级进行多次传输。同时NPDCCH和NPDSCH在不同的子帧进行传输，NB-IoT需要采用与LTE完全不同的容量规划方法。由于NB-IoT终端的成本低、处理能力弱，3GPP协议规定，NB-IoT的UE只能进行单进程传输，即某一个时刻只有1个进程传输下行数据或者上行数据。由于此次出现问题伴随NB小区底噪明显抬升，我们主要针对NB上行容量进行分析。NB-IoT的上行容量NB-IoT的上行数据传输进程如下图，eNodeB通过NPDCCH信道发送DCI格式N0的调度消息给UE，通知UE发送上行数据，经过t4时间后，UE通过NPUSCH信道发送上行数据给eNodeB，UE发送NPUSCH数据后的t5时间内不监听NPDCCH信道,eNodeB接收NPUSCH信道并解码出上行数据后，在满足（10nf+ns2）modT=aoffset・T］的时刻，通过NPDCCH信道里面的新数据指示信息，通知UE发送新的上行数据或重传上行数据。NPDCCHNPDCCHNPUSCHNPDCCHNPDCCHNPUSCHNB-IoT的1次上行数据传输进程的持续时间为：T3=tNPDCCH+t4+tNPUSCH1+t5NB-IoT定义了普通覆盖、扩展覆盖和极端覆盖3个覆盖等级，3个不同的覆盖等级下，NPUSCH信道、NPDSCH信道、NPDCCH信道和NPRACH信道使用不同的MCS和/或重复次数。常规模型下，不同的覆盖等级条件下理论NB-IoTUE发送1次上行数据的持续时间和1个子载波1天的上报次数如下表所示。MCL仙；/mstllAIUJM/mslimunz血/ms/jErlr^r/ms持续时间上报次数次/天）]4432242440I812867500015416064128224P32608142105\M192038416642688256691212500标准模型下NB上报次数庆假设在MCL为144、154、164dB（三个level）时的用户数的比例是4:4:2,则1个上行子载波（15kHz）每天可以发送上行数据的次数为：675000x40%+142105x40%+12500x20%=329342次。NB-IoT上行共计有12个带宽为15kHz的子载波，假设有3个子载波用于NPRACH信道，则用于NPUSCH信道的子载波数有9个；NPUSCH信道除了承载上行数据外，还要承载Attach请求、UE能力上报、鉴权和加密等信令开销，假设业务和信令开销的比例为8:2;假设重传率是10%,则1个小区1天可以发送上行数据的次数为：329342x9x80%x（1-10%）=2134137次。通过与NB厂家沟通了解到，该区域终端由于要求实时性较强，定时发送周期为半小时，即该区域1600个设备全天需产生有效上报次数二1600*48=76800次。2134137远大于76800次，即从上行容量上来说，一个NB小区足以支持该区域1600个NB终端运行。从终端上行时间来计算，按level2情况统计上行持续时间，假若单小区10个终端并行传输，所有终端在无冲突、依次上行传输的情况下，则完成单次上报次数预计耗时1600*608ms/12=81秒，远小于半小时上报周期间隔，即从理论上来说，问题区域单个小区完全可以支持1600个终端同时在网。从另一方面来看，全网NB小区指标统计分析发现问题小区RRC连接次数是全网TOP2，RRC连接次数比TOP1小区少30%，但RRC连接成功率却低了45%，可以进一步佐证问题小区RRC连接成功率过低，并非完全是网络容量问题。小区S祢MD-IdT小区连接建立翼过宓故」NBloPh区只版醐数NBloTRRC]g®建立成V」率(％J■■>七金杭通乂川匚捋12177687762U.720683879京杭区分松司LFH枷TWtZS环吨N日212中为864952361&0.2713&5426下城拱竺J-H金杭危箱牌通忐8362727S628T0.397332387急杭区分公司_F_HJA忡西闹万落圭了佳日_W13B.'，J35972369470.999305015西湖分局.F_H_杭州星供尢厦-KI日_82华为20876207520994060165下城拱墅_=_2_下沙元成村偲5J中兴14549_32979139%江干下沙.F_H_金杭^塔机膏N日华为1425310699075064B986定杭区吩公司F_HJ制1下城安府音务酒世R知彳B_81华为1004961050607523137下城拱墅厂_七金杭街全星材-N日』199547823078551521余枕区分松司_T_H_杭州野照的展入昼研*1华由931296530.993755363上城症江杭闲法华立和技园南匚1华丸9G4695440.9Q94256G9会杭且分公司LF_H_杭州下城段［Zfi环酒后-N日_?14华为916769210754990726下域拱墅-FH_^TM)W-NB_210913891100.996935872下城棋墅>H杭忡I下城感倍云厦-MB20&?861S66S0.721165069下城供筮LF2卜沙松台^EBLfflD中壬7631739996.9E%江干下沙综上分析，无论从小区支持上报次数还是上报所需耗时占用网络资源来说，1个NB小区都足以支撑该区域1600台设备在网，理论上可以排除网络容量不足导致该区域NB小区RRC连接成功率异常问题。2.3网络重传对容量影响我们上述分析计算发现，计算单小区全天上行传输次数2134137远大于该区域需要传输的次数76800次（以该区域1600台设备半小时上传一次计算）。但是考虑到1600台设备必定存在并行冲突（上行子载波仅12个），势必存在重复传输问题。NB-IoT网络上行初始传输ACK/NACK传输、Msg4的ACK/NACK传输均支持大量重复次数。从上述上行次数计算值来看，在保证1600台设备半小时传输均能顺利进行的情况下，该区域支持所有设备平均重复传输次数=2134137/76800^28次。从计算来看，如该区域终端平均上行发送次数超过28次，在单个小区主覆盖情

况下则会出现网络容量不足问题。从网管上查询发现，目前NB-IoT小区上行调度算法配置如下:亘询蝠区上行调度算注酉睦参数木地小区标诅精盖等堀二行衩始叩F上行花1蚱传输至真'舟致MEmcK传喻亘复布数腿傍输至真'次却1覆盖等级UMCS9重复次女1重复次能亘兵次数41覆盖等缀1IiCSCi重复次教£重复次数4亘宣次数$1覆盖等蛆PJ.CSO重亘次数笠重复'步数若亘妄点放皿HU、Jrr-iL日从参数查询上来看，目前最大支持上行重复传输次数为64次，超过上述28次计算值，在重复传输的情况下，有容量不足风险。2.4终端数■与上行底噪关联我们从用户方面了解到近期该区域设备由1200台增加到1600台，而指标查询NB小区底噪进一步增长，提升12dB左右：区域NB终端数与RSSI变化NB-loT区域NB终端数与RSSI变化的干扰噪声的平均值（毫瓦分贝）结合前期该区域NB终端数量大致得到该区域NB终端数量与NB小区反向底噪RSSI关系:

的干扰噪声的平均值（毫瓦分贝）该区域NB-IoT终端数RSSI指标备注400-128dBm所有终端零散分布1200-104dbm400台零散分布，800台放在一起（堆积在2*2m，范围内）1600-92dbm400台零散分布，1200台放在一起（堆积在2*2m，范围内）问题区域NB终端数与小区底噪关系我们与全网NB网络RRC连接次数TOP1小区对比，发现2个小区最大激活用户数相当，但RSSI底噪却存在明显差异，主要区别是本小区有1200台终端堆叠在2*2平方米小范围内，而另一小区设备数量虽然密集但相对分散（同一厂房内）：NB小区RRC连接次数（全天）最大激活用户数RSSI指标全天RRC连接成功率备注TOP2次数小区（本异常小区）45-92dBm仅27%400台零散分布，800台放在一起（堆积在2*2m，范围内）TOP1次数小区42-97dbm75%1000台以上设备分布在厂房内（非堆积在一起）2个高负荷小区凶$1差异由于无线信号功率强度与距离是指数下降关系，问题小区1200台终端之间距离几乎是0（每箱60台共20箱堆积在一起体积不超过5平方米），结合小区RSSI指标来看，我们可以判断问题小区底噪过高，主要因素是终端堆积过于密集有关。

图：问题区域1200台终端完全堆叠终端间距离几乎为0综上分析，问题区域有NB终端数量巨大（超过1600台），且大量终端过于密集（1200台堆在一起）导致小区底噪偏高，影响反向覆盖的同时由于上行重复传输次数设置较大，存在网络容量不足风险。三,优化方案1、要求设备厂家尽量避免将成多NB终端零距离堆叠在一起由于该区域NB终端正在持续运出至需求区域进行安装，但也有持续从厂家运进，从管理上来说执行较为困难;2、进一步提高网络覆盖质量从2.2分析我们可知，NB网络覆盖质量等级（level）对于重复传输次数有较大关联，目前现网配置level0等级上行传输次数最大4次，level2则为64次，重复传输次数相差达到16倍，提高NB网络覆盖质量，可以有效避免重复传输，减少大量终端上行并发数量，降低反向干扰和小区底噪。我们对该区域保留1路主覆盖小区（RSRP-50dbm左右），临时屏蔽另外4路次服务小区（RSRP均在-65~-85dBm之间，由于高于小区重选测量启动门限，均为可用信号且难以重选回主小区），避免终端占用到4路次小区时由于未达到小区重选门限（区域小区重选门限目前为-84dBm）,使主覆盖小区反而变成干扰信号的问题。问题区域覆盖哄保障方案3、降低小区上行重复传输次数结合2.3评估，在该区域大量终端密集堆放暂时无法解决的前提下，我们希望能减少终端上行重复传输