NB-IoT模组选型及项目初始必看！

一、NB-IoT模组选型考虑因素

NB-IoT模组的选型评估工作对于项目能否顺利实施至关重要。前期评估验证阶段若未做充分的工作，很可能项目进行到一半发现NB-IoT模组并不适合当前应用场景，造成项目时间和前期投入全部白费，实际客户支撑中我们经常遇到类似情况。

以下为NB-IoT模组选型中应做评估的常见问题（仅供参考，评估应以实测为准）：

 

表1---NB-IoT模组选型常见需考虑因素

 

评估项	限制因素	选型建议
电池功耗评估（节电要求）	水表应用电池一般9AH（7年）	平均每天3.5mAH（每天1次）
并发能力	NB-IoT单基站12个并发设备	当使用MQTT  、需发心跳、数据交互频繁(分钟级)、设备密度极大等情况时，不建议使用NB-IoT或需慎重评估
延时及丢包要求	NB-IoT平均延时约10秒，有丢包概率，NB-IoT信号受环境影响较大	重要报警信号不允许丢失、实时性要求高等场景不适用
实时下行要求	必须开通专用APN及连OneNET	实时下行与低功耗矛盾，一般NB-IoT为上行的接收下行
传输速率要求	一般小于5KB/S	不适合传图片等大文件，单次应小于500 BYTE
定位能力	GNSS可选N10SG,基站LBS尚未完善	LBS定位精度差速度快，GNSS功耗高定位速度慢
使用位置	如高层，井盖下，地下车库，郊区（信号覆盖一般为城区）	以上地点需实测评估NB-IoT信号质量
语音及短信	暂不支持	暂不支持
应用数据传输频率	如不需节电也建议不超1次每小时，需结合设备分布密度考虑	建议每天不超过3次（表计类）

 

二、NB-IoT并发能力限制原因 

本文重点讨论NB-IoT应用目前最大痛点--并发能力限制，对选型使用的影响。首先看一下NB-IoT这个痛点的原因是什么？主要是带宽太小，就像公路太窄能同时通行的车就特别少，下图可见：

图1 NB-IoT并发能力有限的原因

 

图2 常见蜂窝网络制式带宽对比

 

由上图可知：根据设计，LTE（4G）系统支持多种频率带宽配置：1.4MHz, 3MHz, 5MHz, 10MHz, 15MHz, 20MHz其中，最大的是20MHz(现网常规配置)，最小的是1.4MHz。

为什么是20MHz呢？

因为LTE被设计为最多允许110组子载波（1组=12个）同时传输。

110 ×（15KHz×12）= 19800 KHz ≈ 20 MHz。

因此如果说4G LTE是高速公路，NB-IoT就是乡间小路，并发能力实在有限啊。没法比，没法比。

 

三、NB-IoT应用中的常见误区及注意事项

客户甲：我听说是超大容量，单基站最多可以让5万个设备一起工作。

正解：这里所说的5万个设备容量是指设备深度休眠状态下，基站仍保持其注册信息，一旦睡眠中恢复不用再重新驻网连接。要是同时醒来，网络就直接崩溃了2333，更别说同一时间只允许12个设备同时做数据业务，这个超大容量和并发能力完全是两个概念啊，好不好。

客户乙：我听说NB-IoT是超低功耗的，那我电池选2000mAH肯定足够了呗。

正解：NB-IoT的超低功耗是指其可以进入uA级深度休眠，实际收发数据那也是20-300mA级别的功耗，还和外部信号环境关系很大。实际使用务必根据各自应用场景实测电池消耗量并留足余量。

 

 

NB-IOT并发限制注意事项：

（1）NB-IoT接入能力主要考虑两方面：RRC最大连接用户数和有效RRC连接用户数。目前华为和中兴的最大RRC连接用户数约为600个。

（2）现网NB-IOT单小区上行只有12个NPRACH子载波(12个信道)，若基站配置 NPRACH 周期为 320ms，1 s可同时接入设备数（驻网）为36个。

（3）终端集中接入导致网络底噪提升、接入指标下降；终端满功率发射导致网络干扰抬升；终端未做错峰优化、网络容量有限，造成网络拥塞设备接入困难。

（4）终端所处的信号覆盖等级不同（ECL0 1 2），网络接入及数据收发速度及成功率不同，某项目设备分布按覆盖等级强中弱6:3:1分布，60 s可并发接入用户数约 60 个（仅供参考）

（5）需注意模组驻网时和发送数据时（idle态不占用信道）都占用信道资源（12个），因此当有大量设备在驻网时，发送数据容易失败。

 

重要声明：以上数据仅供参考，均为理论数据；现实应用务必以实测为准，实验是检验真理的唯一标准哦。

 

四、NB-IoT应用客户选型实例

前段时间有个客户给我说他板子都做好了，正在写单片机程序；说调试很挺顺利用的OneMO M5311模组，MQTT的协议；再加把劲就可以做完了，我一听MQTT心里闪过一丝不祥的念头，赶紧问他具体的应用场景怎样的。

客户君描述：我这个是医院里病房用的病床呼叫警报器，还可以下发广播；每2分钟发一次MQTT心跳,病人有情况会按下按钮，通过NB-IoT网络消息传到护士站，护士站也可以下发指令，每个病床收到触发特定广播如火灾警报，大家快跑什么的。

听完他的描述，我是崩溃的；犹豫了半秒是否告诉他残酷的真相：您好，你这个项目白做了！

这个客户就是典型的做项目前未对NB-IoT的网络能力特别是并发能力做评估得，直接先做再说；这个案例中客户未考虑到几个因素：

（1）设备太密集，一个病房5张病床，一层100-150个设备，一栋楼600-800设备。

（2）客户并未调研医院周围NB-IoT信号如何，基站有几个。

（3）最大的问题使用MQTT协议 2分钟发一次心跳，如此大量的设备基站肯定拥塞崩溃了

（4）护士站一键全部下行到病床，对于一个NB-IoT小区，同一时间只允许1个下行，因为只有一个下行通道；本例中这一键下去大部分设备都无法收到这个消息。如果是火灾广播告警后果很严重。

（5）NB-IoT单个设备和批量使用时很可能出现完全不同的效果，原因就是现网网络信号千差万别及NB-IoT并发能力限制导致的，实际应用最好应有小批量模拟测试评估阶段。

（6）最容易被忽略的一个因素，感情公共的NB-IoT基站就你一家在用吗，万一同一个地方还有甲乙丙丁几个厂家都布置了NB-IoT设备，那更是雪上加霜了，实际上随着NB-IoT物联设备的普及这种情况很常见，比如周边小区可能有几百个NB-IoT水表街上有几十个NB-IoT井盖等设备。

通过以上耐心的解释，客户无奈的接受了现实，不得不改换方案重头再来，流下了悔恨的泪水，估计夜深人静时扇了自己几个耳光为啥做项目前没有充分的评估NB-IoT是否适合自己的应用场景，没有提前咨询OneMO的FAE工程师，没有去看OneMO官网大量实践经验总结的避坑文章和视频，在此感叹：希望悲剧不要重演。