NB-IOT大连接业务规模化应用的关键技术研究

摘 要

针对智慧水表、智慧路灯等NB-IOT大连接业务场景应用面临的容量小、速率慢、深度覆盖不足、高干扰、数据并发冲突，导致的上行/查询成功率低、终端电池耗电快、在线升级难、测试量大，项目无法交付的问题，端到端的提出上下行数据错峰发送、VPN专网方案去除心跳包、大话务模型参数优化提升容量、大网异频插花组网降干扰、高低频混合组网提覆盖、终端控制指令采集NB信号指令、升级包分段纠错等创新解决方案，以友商1/3的投资成本完成项目交付。归纳并提出NB-IOT垂直行业应用开发中必须遵循的网络使用规范与建议，以及网络统计分析功能，为NB-IOT大连接场景的规模化推广应用提供参考与指导。

关键词

NB-IOT、物联网、垂直行业应用、大连接、数据并发冲突、网业协同、容量、干扰、数据发送错峰、互联网专网方案

概述

NB-IOT垂直行业应用属新技术、新业务，全球各厂家与运营商均无大连接规模化应用的成熟经验。福州联通承接了两个政府示范性NB物联网项目，其中智慧水表10万台，智慧路灯5.5万台，均为各自行业内最大规模的商用项目，连接数超过当期全国联通NB项目总连接数的50%，且都具备大连接业务并发的特点，对NB窄带物联网的容量是个巨大的挑战。

项目初期遇到以下问题，导致无法交付：1）终端上线成功率低、查询应答成功率低；2）深度覆盖差导致电池耗电；3）终端控制器在线升级成功率低，严重影响项目整改进度；4）NB没有MR上报，水表项目要求提供每梯三个楼层所有终端信号电平，测试量巨大；

针对NB大连接并发业务场景，从终端控制器、无线网络、组网方式及物联网应用平台，端到端的提出上下行数据错峰发送、VPN专网方案去除心跳包、大话务模型参数优化提升容量、大网异频插花组网降干扰、高低频混合组网提覆盖、终端控制指令采集NB信号指令、升级包分段纠错等创新解决方案.

在不扩容、不加站的情况下：水表项目上报率从不到80%提升到97%以上；路灯项目查询成功率从约35%提升到96%以上，投资成本仅为南京友商同类项目的35%，并解决了海量测试问题。归纳并提出NB-IOT垂直行业应用开发中必须遵循的网络使用规范与建议，以及网络统计分析功能，为NB-IOT大连接场景的规模化推广应用提供参考与指导。

1.1NB项目业务模型及特点

NB－IOT系统由端到端各网元组成，如下：

图1：NB-IOT系统结构图

1）水表项目业务特点及需求：

智慧水表使用电池供电；业务为每天上报一次，水表自主发起；每个居民小区一般安装几百上千台水表，安装在外墙、地下室或电梯厅边有防火铁门的小房间内等。

2）路灯项目业务特点及需求：

使用市电供电，不存在电池寿命问题；业务上具有上下行双向数据发送需求，分为三类：A、事件型，包括路灯上电上报、故障告警实时上报，B、周期型，包括电流电压状态查询上报、链路维持心跳包，C、控制型，包括人工或自动根据需求进行开关灯控制；连接方面，每隔20米道路两侧一盏路灯，有的路灯有高低两盏灯两个NB终端，每个小区接入50~150盏。

NB物理网大连接业务问题及解决方案

针对智慧水表与智慧路灯上线成功率低、查询应答成功率低等问题，从终端、无线网络、组网结构、应用平台进行了全面的分析，发现主要存在以下问题：

1)大连接业务并发冲突，信道容量不足

2)数据并发冲突重传导致上行干扰抬升，进一步降低数据发送成功率

3)终端频繁发送心跳包，加大网络负荷与并发冲突

4)下行小区间干扰，降低容量，并影响数据发送成功率

5)终端在线升级慢，成功率低，影响整改进度

6)弱覆盖区域电池耗电、数据发送成功率低

7)NB终端不上报MR，无法后台采集信号质量，而客户要求海量测试

8)应用平台缺乏统计分析能力，问题定位、分析效率慢

针对上述问题，从终端控制器、无线网络、组网方式及物联网应用平台提出了端到端的创新解决方案，如下：

2.1上行错峰，解决终端接入并发冲突及干扰问题

分析发现单小区下路灯超过50台时，接入与查询成功率明显恶化，分析应该为容量受限，同时后台发现基站上行底噪严重超标，最大值高达-75db左右。

图2：NB某基站上行底噪趋势图

上图绿色为底噪最大值、蓝色为底噪平均值，在晚上开灯时段上行底噪抬升，关灯时段恢复正常，可以排除外部干扰影响。

2.1.1NB容量分析

图3：NB PRACH信道结构

如上图所示，NB每个载波最多12个PRACH子载波占用12*3.75kHz，PRACH资源与PUSCH资源共享。

NB接入过程符合泊松分布模型，碰撞概率P与每秒接入次数G关系：

P＝1－e-G/(竞争前导数量*每秒物理随机接入信道数量)

NB共12个子载波即12个竞争前导，每秒物理随机接入信道（PRACH）数量=1000/PRACH周期（ms）。

按碰撞概率P=10%计算，每秒可接入次数：

G＝ln(1/(1-P)×竞争前导数量*1000/PRACH周期=ln(1/(1-10%))×12×（1000/PRACH周期）=1.264×1000/PRACH周期

NB-IOT制式为增强覆盖，不同覆盖等级0、1、2，设不同的重复次数。根据协议每次PRACH资源占用5.6ms，不同覆盖等级下PrachRepetitionCount=2/4/32为例，各覆盖等级PRACH资源占用时长如下表所示：

当用户分布处于典型场景，覆盖等级0/1/2用户分布比例为5:3:2时，PRACH周期可设置为640ms，保证各覆盖等级用户均有机会接入，按该用户模型：

每秒接入次数为G＝1.264×（1000/640）＝1.975

覆盖等级0每小时接入次数＝G×3600＝7110

覆盖等级1每小时接入次数＝G×3600×3/5＝4266

覆盖等级2每小时接入次数＝G×3600×2/5＝2844

说明NB在时间上离散平均接入时，PRACH周期为640ms，每小时可接入1.42万用户，具有大容量的特性，但每秒只能同时接入4个用户。

但是由于路灯项目所有终端上电时同时尝试接入，虽然冲突可以重发，但必然导致接入信令风暴，引起上线成功率低。

2.1.2上行干扰抬升分析

经分析，上行底噪抬升是由于终端并发接入冲突和上行多次重复发送失败，导致功率竞争引起。终端功控机制在两种情况将以最大发射功率发送：

（1）NB只有12个PRACH信道，如果同时并发接入用户数大于12个，发生接入冲突，终端为了保证接入就会按照最大功率发射。跟踪某上行干扰小区发现，接入用户超过12个的占比为11.76%。

（2）上行数据发送失败：根据协议终端在PUSCH发送上行报文的时候，如果连续失败超过两次，为了保证报文发送，终端将按照最大功率发送。该基站一次发送成功率仅19.28%，二次发送失败达到6.83%，而且一旦失败多次发送。

表3：NB某基站重传次数统计

2.1.3上行数据发送错峰解决方案

针对上行并发冲突，对终端控制器升级，进行错锋上报，算法建议如下：

1、智能水表每天0点~8点之间上报1次数据，平台上设置每个终端上报的时间点T（从0点开始的秒数）在0点~8点之间随机离散开，假设每30秒上报一批，共有8×3600/30=960个上报时间点，设T = (SN mod 960) × 30s；其中 SN为水表的序列号。

2、若所有路灯接入延时300秒，算法举例如下：

每间隔X秒上报一批Y个，间隔X：1~8秒可调，每次上报个数Y=300/X（个），则每盏灯的接入延迟=（路灯ID最后两位 MOD Y）×X（秒）；

测试验证路灯上线成功率从低于40%，稳定到75%以上；

2.2查询错峰，解决查询成功率低问题

2.2.1问题分析

智慧路灯需要下达指令，进行灯况查询或开关灯控制。由于物联网平台同时对NB小区下所有终端同时下发指令，造成寻呼排队，流程冲突等问题，同时又带来上行数据发送的并发问题。寻呼容量计算如下：

不同覆盖等级每个寻呼信道可寻呼的用户数如下表所示：

表4：不同覆盖等级寻呼用户数

上表计算覆盖等级0，以TMSI为例，一个UE-Identity=8+3=40bit，再附加上PagingUE-Identity   CHOICE(2bit)和Extension(1bit),则需要43bit，对于覆盖等级0用户，RRC头开销为8bit。下行缺省配置MSC＝10，查NPDSCH对应的TBS表，TBS＝680bit，因此（680－8）/43=15.62个，因此只能最大承载15个用户。

NB（寻呼密度）＝T/64,表示每64个无线帧有1个子帧用于寻呼，决定了NB-IOT系统的寻呼容量，无线帧＝10ms。

寻呼容量＝NB×每个寻呼信道寻呼的用户数，并换算成每秒寻呼用户数，计算如下：

表5：不同覆盖等级寻呼容量

每个NB小区寻呼容量在3~23个/秒之间，而一个NB小区有50~150盏路灯，如果平台直接下发查询，明显寻呼容量不足，会造成寻呼排队。

用户跟踪log显示，某单用户核心网20：11在S1口侧下发寻呼消息，UU口基站侧在20：32才最终跟踪到，排队延迟高达21分钟左右。经查基站日志，发现在寻呼下发时刻，基站已经有980个寻呼消息待发送。寻呼排队引起了查询响应延时，导致查询失败。

2.2.2解决方案：

优化终端通信控制协议，增加控制指令集，使得终端具备错峰、重传、轮循等算法参数配置功能，实施错峰查询，包括：并发数、并发时间间隔、跳跃因子及巡检等待时间、自动巡检周期、查询次数等，可根据不同场景试出最佳平衡点。错峰算法如下：

设置：1）并发数=X个，2）并发间隔=Y秒，3）跳跃因子=Z，则每条路段每次查询X盏路灯，间隔Y秒，再查询下一批X盏，每次下发的路灯编号间隔Z。

例：X=6，Y=10，Z=5，则第一次下发路灯编号0、5、10、15、20、25；间隔10秒后，第二次下发 1、6、11、16、21、26；

经过测试验证，路灯查询成功率从35%提升到78%以上。

2.3VPN专网接入方案，解决心跳包带来的网络负荷问题；

2.3.1问题分析：

项目测试过程，发现终端频繁发送心跳包数据，大幅增加了网络的负荷。沟通得知，由于路灯项目需要从IOT平台下发控制指令，需要保持IP地址不变，所以应用开发厂家通过心跳包维持。

路灯心跳包周期项目初期设30秒，心跳包业务模型如下：

表6：心跳包业务模型

一个心跳包有8条信令，其中随机接入MSG1~5共5条、上行心跳包及平台应答两条，以及RRC链路释放一条，进一步增加接入冲突及网络负荷。

2.3.2解决方案：

采用VPN专网方案，为每个NB终端设备分配一个固定的私网IP地址，经NAT协议地址后，通过互联网GRE隧道模式访问物联网平台服务器。同时将SIM卡的APN由公网APN：snbiot改为专网APN：fjfrdz01s.nb.gziot。

经过测试验证，改专网后数据交互大幅减少，上行底噪得到大幅度改善，查询成功率也从约78%，进一步提升到了85%~88%。

2.4大话务模型参数优化提升网络容量

智慧水表每小区接入500个以上终端，智慧路灯每小区需接入可高达100个以上终端，终端数量多并且NB通过重复发送获得信道增益，易发生业务风暴，造成网络容量不足。

参数优化思路：大连接情况下，减少上行重复次数、增大冲突解决定时器时长及失败后的惩罚时间，加大前导传送最大次数及终端反复接入失败的惩罚时长。使得用户接入离散化，减少业务风暴，参数调整如下：

在错峰机制、VPN方案解决心跳包问题以及大话务量模型参数优化，三种措施实施后，路灯全网查询成功率提升到了90~92%。

2.5根据NB不移动性，采用大网异频插花组网解决网内干扰

解决全网系统性问题后，路灯项目应用平台查询分析发现部分路段查询成功率低，同时从网络侧后台统计发现信号覆盖等级低（RSRP与SINR均会触发），现场测试发现由于NB覆盖增强10db，网内重叠覆盖及模三干扰较LTE更加严重，考虑到水表深度覆盖问题，不能大幅度压倾角。

LTE大网异频插花组网，由于SINR值过好，拖得很远，信号已经衰弱仍不容易容发生异频切换，如果移动过程遇到拐弯遮挡、或进入室内等情况，来不及切换，易脱网，所以一般不采用。但是，考虑到NB终端不具备移动性，所以大胆尝试NB大网异频插花组网，且异频信号干净、覆盖效果好，尝试关闭部分NB站点。如下图所示：为提升南三环路的查询应答率，下图红色为关闭小区、绿色为原1452频点，蓝色为新增的1454频点。

图4：异频插花组网调整方案

方案实施后，路灯最密集的南三环路上线率与查询成功率从85~90%稳定提升到95%以上。统计指标看，因SINR变好覆盖等级最好的0级比例提升到90%以上。

2.6通过AT指令控制终端上报信号质量，减少海量测试

NB水表项目量大、终端分散，电池替换成本高，为避免深度覆盖不足带来的终端电池寿命缩短问题，客户要求住宅小区每楼梯抽测高中低三层水表，NB水表项目开通261个居民小区，需要测试1万多个采样点。NB为了省电无MR上报，无法网管获取，测试工作量巨大。

解决方案：增加通信指令集，通过平台控制终端信号质量上报控制功能

与研究院及模组、物理网应用厂家研讨，在平台与终端之间增加通信协议指令与字段，支持AT命令采集上报NB终端的RSSI、RXQUAL、PCI等质量与参数信息。AT命令的格式遵循3GPP相关标准（3GPPTS27.005specification），如信号查询指令AT+CSQ:<rssi>,<ber>。采用查询方式，即解决了海量现场测试问题，同时非周期上报，也不会带来终端的耗电问题。

2.7优化终端升级程序与算法，实现批量快速升级

物联网应用是针对每个应用需求独立开发的，调测升级问题不可避免，但是终端安装分布广，现场升级施工难度大，需终端支持用NB网络在线升级能力。项目过程，发现错峰、轮询、重传等算法问题，必须进行终端在线升级解决，但是NB带宽窄、速率慢，环境恶劣，导致升级成功率低，严重阻碍项目交付进度。

解决方案：拆包检测重传，批处理自动升级

一是升级程序500Byte，一次数据发送周期长，成功率低，把程序拆分成58个包，逐个包检测重传，并把重传次数从5次增加到20次。虽然时间加长了，但是保证基本都可以成功。二是通过开发自动升级脚本，利用夜间通宵升级。

升级效率从每晚二十几盏，提升到在三四百台盏，升级周期缩短到原来的1/15。

总结

NB虽然具有广覆盖、低功耗、大连接、低成本等优势，但是也存在容量低、速率慢、数据并发冲突、弱覆盖区模组耗电等问题。从两个项目存在的问题可以看出，NB业务能否正常使用，不仅在于网络自身，更取决于网业协同，如果NB终端及应用开发未根据NB-IOT特点合理使用网络，终端数据发送未做错峰、频繁发送心跳包、数据发送周期过短、重发机制不合理等问题，会给网络带来灾难性影响。

参考文献

1、赵静,《低速率物联网蜂窝通信技术现场及发展趋势》 移动通信.2016,40(7)

2、戴国华，余骏华 《NB-IoT的产生背景、标准发展以及特性和业务研究》 移动通信.2016,40(7)

3、卢斌《NB-IoT物联网覆盖增强技术探讨》 移动通信.2016,40(19)

4、程闽明等《NB-IoT网络RRC连接成功率问题分析与处理》 移动通信.2018,42(10)

5、刘玮等《NB-IoT关键技术与规划仿真方法》 电信科学.2016年第Z1期:

6、郭宝,刘毅,张阳《 NB_IoT组网规划分析》  移动通信.2018,42(3)

7、胡泽妍等《NB_IoT网络部署方案探讨》 邮电设计技术.2018(7)

8、邢剑卿、3GPP_NB_IoT空口容量浅析，移动通信，2016年12月

9、黄韬，刘昱，张诺亚，NB-IoT独立部署下的容量性能分析，移动通信，2017年第17期