2024年4月23日发(作者：牢芷若)
杭州NB高负荷小区容量及底噪问题分析优化
实践案例
一、问题描述
NB-IOT网络具有大容量的特点，实验室模型下理论评估支持单小区5万个终端在网。
但本周杭州NB现网发生一起1000多个用户堆积在同一区域时，NB网络指标明显恶化，
RSSI显著抬升，以至于NB网络无法使用的问题，我们对该区域NB用户量和NB容量、
以及小区底噪相关问题进行分析探讨。
二、问题分析
2.1 大量NB终端导致网络无法使用
6月下旬开始杭州某区域周边多个NB-IoT小区RRC尝试次数总和由100次以下突然
上升到总和接近20万次/天，同时RRC连接成功率明显恶化，最低小区RRC连接成功率低
于20%，对网络指标造成明显影响：
通过与多方NB设备厂家以及基站用户监控，并通过现场排查，最终发现导致该区域
NB业务量迅速增长、指标明显恶化的原因，是某公司临时堆放了超过1200台NB终端设
备在一个2*2的小块区域，造成NB用户量庞大的同时，由于设备放置过于密集，集中产
生较大反向干扰，导致周边NB小区底噪RSSI太高30dbm以上，导致NB网络几乎无法
连接成功。
上图：小范围内堆积NB终端超过1200台（每箱60台*＞20箱）
大量NB设备导致NB小区底噪明显抬升
由于该区域不但有新堆放的大量NB设备，附近小区还有300台智能消防烟感终端，
以及100台以上已安装的智能地锁设备，即
该区域NB-IoT用户数
=超过1200临时堆放设备+300以上智能烟感+100智能地锁＞1600台设备
对问题区域（堆放终端的地点）进行NB-IoT网络覆盖测试，发现该区域最强NB小区
RSRP高达-50dbm，占用该小区时SINR在20以上，即NB网络覆盖质量良好，可排除网
络覆盖差引起区域指标差的问题。
在排除覆盖问题之后，需要对该区域NB小区指标恶化的原因进行网络容量方面排查。
区域现场测试NB网络覆盖质量良好
2.2 NB-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=αoffset·T］的时刻，
通过NPDCCH信道里面的新数据指示信息，通知UE发送新的上行数据或重传上行数据。
NB-IoT的1次上行数据传输进程的持续时间为：
T3=tNPDCCH+t4+tNPUSCH1+t5
NB-IoT定义了普通覆盖、扩展覆盖和极端覆盖3个覆盖等级，3个不同的覆盖等
级下，NPUSCH信道、NPDSCH信道、NPDCCH信道和NPRACH信道使用不同的
MCS和/或重复次数。
常规模型下，不同的覆盖等级条件下理论NB-IoT UE发送1次上行数据的持续
时间和1个子载波1天的上报次数如下表所示。
标准模型下NB上报次数/天
假设在MCL为144、154、164 dB（三个level）时的用户数的比例是4∶4∶2，
则1个上行子载波（15 kHz）每天可以发送上行数据的次数为：675000×40%+142
105×40%+12500×20%=329342次。NB-IoT上行共计有12个带宽为15 kHz的
子载波，假设有3个子载波用于NPRACH信道，则用于NPUSCH信道的子载波数
有9个；NPUSCH信道除了承载上行数据外，还要承载Attach请求、UE能力上报、
鉴权和加密等信令开销，假设业务和信令开销的比例为8∶2；假设重传率是10%，
则1个小区1天可以发送上行数据的次数为：329342×9×80%×（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连接成功率过低，并非完全是网络容量问题。
综上分析，无论从小区支持上报次数还是上报所需耗时占用网络资源来说，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小区上行调度算法配置如下：
从参数查询上来看，目前最大支持上行重复传输次数为64次，超过上述28次计算值，
在重复传输的情况下，有容量不足风险。
2.4 终端数量与上行底噪关联
我们从用户方面了解到近期该区域设备由1200台增加到1600台，而指标查询NB小
区底噪进一步增长，提升12dB左右：
区域NB终端数与RSSI变化
结合前期该区域NB终端数量，大致得到该区域NB终端数量与NB小区反向底噪RSSI
关系：
该区域NB-IoT终端数
400
RSSI指标
-128dBm
备注
所有终端零散分布
400台零散分布，800台放在一起（堆积在2*2
㎡范围内）
400台零散分布，1200台放在一起（堆积在2*2
㎡范围内）
1200 -104dbm
1600 -92dbm
问题区域NB终端数与小区底噪关系
我们与全网NB网络RRC连接次数TOP1小区对比，发现2个小区最大激活用户数相
当，但RSSI底噪却存在明显差异，主要区别是本小区有1200台终端堆叠在2*2平方米小
范围内，而另一小区设备数量虽然密集但相对分散（同一厂房内）：
NB小区RRC连
接次数（全天）
最大激活用
户数
RSSI指标 全天RRC连接成功率 备注
TOP2次数小区
（本异常小区）
400台零散分布，800
45 -92dBm 仅27% 台放在一起（堆积在2*2
㎡范围内）
1000台以上设备分布在
厂房内（非堆积在一起）
TOP1次数小区 42 -97dbm 75%
2个高负荷小区RSSI差异
由于无线信号功率强度与距离是指数下降关系，问题小区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），使主覆盖小区反而变成干扰信号的问题。
问题区域覆盖level保障方案
3、降低小区上行重复传输次数
结合2.3评估，在该区域大量终端密集堆放暂时无法解决的前提下，我们希望能减少终
端上行重复传输次数，避免因传输次数过大，造成容量不足问题。对主覆盖小区的上行初始
传输重复次数、ACK/NACK传输重复次数、Msg4的ACK/NACK传输重复次数均进行临
时调整，有效降低大量终端并发重复传输次数。由于该区域用户设备是临时堆放并非实际商
用，参数修改可能造成小区数据更新失败，但不会产生业务影响。
上行传输重复次数调整（临时调整方案）
调整前
调整后
问题区域NB小区上行重传参数调整方案
4、建议厂家以后增加设备电源开关
由于此次NB指标异常，是设备厂家大量终端临时堆放一起导致，建议厂家以后为终端
增加电源开关，在设备正式启用前避免因无法关闭且大量终端放置在一起时造成网络高负荷
问题。
四、优化效果
优化调整后，跟踪该区域主服务小区底噪RSSI下降约5dB，RRC连接成功率由30%
以下上升至80%以上，改善明显。
小区底噪和连接指标得到改善
三、经验推广
本案例主要分析了大量用户聚集情况下NB-IoT网络容量、底噪以及网络指标相关关
系。在NB -IoT网络高负荷、网络连接指标差以及由于NB终端数量过大造成底噪高问题
时，可参考进行网络优化调整，维护网络指标和良好用户感知。
2024年4月23日发(作者：牢芷若)
杭州NB高负荷小区容量及底噪问题分析优化
实践案例
一、问题描述
NB-IOT网络具有大容量的特点，实验室模型下理论评估支持单小区5万个终端在网。
但本周杭州NB现网发生一起1000多个用户堆积在同一区域时，NB网络指标明显恶化，
RSSI显著抬升，以至于NB网络无法使用的问题，我们对该区域NB用户量和NB容量、
以及小区底噪相关问题进行分析探讨。
二、问题分析
2.1 大量NB终端导致网络无法使用
6月下旬开始杭州某区域周边多个NB-IoT小区RRC尝试次数总和由100次以下突然
上升到总和接近20万次/天，同时RRC连接成功率明显恶化，最低小区RRC连接成功率低
于20%，对网络指标造成明显影响：
通过与多方NB设备厂家以及基站用户监控，并通过现场排查，最终发现导致该区域
NB业务量迅速增长、指标明显恶化的原因，是某公司临时堆放了超过1200台NB终端设
备在一个2*2的小块区域，造成NB用户量庞大的同时，由于设备放置过于密集，集中产
生较大反向干扰，导致周边NB小区底噪RSSI太高30dbm以上，导致NB网络几乎无法
连接成功。
上图：小范围内堆积NB终端超过1200台（每箱60台*＞20箱）
大量NB设备导致NB小区底噪明显抬升
由于该区域不但有新堆放的大量NB设备，附近小区还有300台智能消防烟感终端，
以及100台以上已安装的智能地锁设备，即
该区域NB-IoT用户数
=超过1200临时堆放设备+300以上智能烟感+100智能地锁＞1600台设备
对问题区域（堆放终端的地点）进行NB-IoT网络覆盖测试，发现该区域最强NB小区
RSRP高达-50dbm，占用该小区时SINR在20以上，即NB网络覆盖质量良好，可排除网
络覆盖差引起区域指标差的问题。
在排除覆盖问题之后，需要对该区域NB小区指标恶化的原因进行网络容量方面排查。
区域现场测试NB网络覆盖质量良好
2.2 NB-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=αoffset·T］的时刻，
通过NPDCCH信道里面的新数据指示信息，通知UE发送新的上行数据或重传上行数据。
NB-IoT的1次上行数据传输进程的持续时间为：
T3=tNPDCCH+t4+tNPUSCH1+t5
NB-IoT定义了普通覆盖、扩展覆盖和极端覆盖3个覆盖等级，3个不同的覆盖等
级下，NPUSCH信道、NPDSCH信道、NPDCCH信道和NPRACH信道使用不同的
MCS和/或重复次数。
常规模型下，不同的覆盖等级条件下理论NB-IoT UE发送1次上行数据的持续
时间和1个子载波1天的上报次数如下表所示。
标准模型下NB上报次数/天
假设在MCL为144、154、164 dB（三个level）时的用户数的比例是4∶4∶2，
则1个上行子载波（15 kHz）每天可以发送上行数据的次数为：675000×40%+142
105×40%+12500×20%=329342次。NB-IoT上行共计有12个带宽为15 kHz的
子载波，假设有3个子载波用于NPRACH信道，则用于NPUSCH信道的子载波数
有9个；NPUSCH信道除了承载上行数据外，还要承载Attach请求、UE能力上报、
鉴权和加密等信令开销，假设业务和信令开销的比例为8∶2；假设重传率是10%，
则1个小区1天可以发送上行数据的次数为：329342×9×80%×（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连接成功率过低，并非完全是网络容量问题。
综上分析，无论从小区支持上报次数还是上报所需耗时占用网络资源来说，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小区上行调度算法配置如下：
从参数查询上来看，目前最大支持上行重复传输次数为64次，超过上述28次计算值，
在重复传输的情况下，有容量不足风险。
2.4 终端数量与上行底噪关联
我们从用户方面了解到近期该区域设备由1200台增加到1600台，而指标查询NB小
区底噪进一步增长，提升12dB左右：
区域NB终端数与RSSI变化
结合前期该区域NB终端数量，大致得到该区域NB终端数量与NB小区反向底噪RSSI
关系：
该区域NB-IoT终端数
400
RSSI指标
-128dBm
备注
所有终端零散分布
400台零散分布，800台放在一起（堆积在2*2
㎡范围内）
400台零散分布，1200台放在一起（堆积在2*2
㎡范围内）
1200 -104dbm
1600 -92dbm
问题区域NB终端数与小区底噪关系
我们与全网NB网络RRC连接次数TOP1小区对比，发现2个小区最大激活用户数相
当，但RSSI底噪却存在明显差异，主要区别是本小区有1200台终端堆叠在2*2平方米小
范围内，而另一小区设备数量虽然密集但相对分散（同一厂房内）：
NB小区RRC连
接次数（全天）
最大激活用
户数
RSSI指标 全天RRC连接成功率 备注
TOP2次数小区
（本异常小区）
400台零散分布，800
45 -92dBm 仅27% 台放在一起（堆积在2*2
㎡范围内）
1000台以上设备分布在
厂房内（非堆积在一起）
TOP1次数小区 42 -97dbm 75%
2个高负荷小区RSSI差异
由于无线信号功率强度与距离是指数下降关系，问题小区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），使主覆盖小区反而变成干扰信号的问题。
问题区域覆盖level保障方案
3、降低小区上行重复传输次数
结合2.3评估，在该区域大量终端密集堆放暂时无法解决的前提下，我们希望能减少终
端上行重复传输次数，避免因传输次数过大，造成容量不足问题。对主覆盖小区的上行初始
传输重复次数、ACK/NACK传输重复次数、Msg4的ACK/NACK传输重复次数均进行临
时调整，有效降低大量终端并发重复传输次数。由于该区域用户设备是临时堆放并非实际商
用，参数修改可能造成小区数据更新失败，但不会产生业务影响。
上行传输重复次数调整（临时调整方案）
调整前
调整后
问题区域NB小区上行重传参数调整方案
4、建议厂家以后增加设备电源开关
由于此次NB指标异常，是设备厂家大量终端临时堆放一起导致，建议厂家以后为终端
增加电源开关，在设备正式启用前避免因无法关闭且大量终端放置在一起时造成网络高负荷
问题。
四、优化效果
优化调整后，跟踪该区域主服务小区底噪RSSI下降约5dB，RRC连接成功率由30%
以下上升至80%以上，改善明显。
小区底噪和连接指标得到改善
三、经验推广
本案例主要分析了大量用户聚集情况下NB-IoT网络容量、底噪以及网络指标相关关
系。在NB -IoT网络高负荷、网络连接指标差以及由于NB终端数量过大造成底噪高问题
时，可参考进行网络优化调整，维护网络指标和良好用户感知。