根据不同的应用场景需求，目前NB-IoT水表主要有以下几种方案：

图1 几种常见NB水表方案

接下来将从NB-IoT水表上电开机、模组初始化、入网判断、业务逻辑四个环节来详细讲述，以下业务流程仅供参考，需根据实际应用场景测试及调整，以达到最佳性能及功耗要求。

上电开机及模组初始化

M5310-A上电后自动开机，MCU通过控制模组VBAT脚电源开或断来控制模组开机或关机。模组开机后串口自动打印开机信息(默认波特率9600)，一般在接收到开机完成打印的“M5310-A OK”后或者开机后延时3-5秒发送第一条指令：AT，模组上电后MCU需发送的AT指令如下：

图2 M5310-A模组开机流程及异常处理

MCU判断M5310-A是否正常开机主要有两种方式，第一主要通过串口AT是否响应判断，第二还可通过模组VDD_EXT是否有1.8V电压做判断，第二种使用较少。

如图2 M5310-A开机及初始化异常主要检查电池电压是否过低，SIM卡是否接触不良，如果模组启动过程中频繁自动重启则检查RST引脚是否有干扰或启动瞬时电流过大拉低电源电压造成。根据上表中不同的情况MCU可以作相应记录或者指示灯提示，方便检修人员识别故障。

注：NB水表MCU程序中只要可配置的参数应全部做成变量形式，如指令重发次数、指令超时等待时间等，保证重要参数后期可通过平台下发指令修改。

入网判断

基于NB-IoT基站一个扇区同一时间只有12-36个信道可用，大量NB-IoT水表入网需做好错峰处理，错峰算法主要采用时间离散法。驻网环节比较关键，驻网成功与否及时间长短主要取决于外部信号质量及水表自身天线射频性能，具体入网AT流程见下图：

图3 模组入网判断流程

一般NB-IoT水表协议规定，需上传模组及网络相关信息，所以上表中有获取NB网络信息相关指令，需要上传的参数一般有：IMEI、RSRP、SNR、CELLID、ECL、CCLK、IMSI、PCI等。

图4 驻网相关名词解释

几种典型场景的入网时间介绍及异常处理，图5驻网评估时间及信号判断标准仅供参考，实际请以实网测试为准：

图5 几种典型场景的入网时间介绍及异常处理

入网异常判断及原因和处理方法

当发送AT+CEREG?返回+CEREG:0,2 时代表模组正在尝试驻网，长时间保持此返回值可能信号较差或者是首次驻网需要较长时间，解决办法主要为使用AT+NBAND锁频段(异地首次入网)及网优优化网络及查看射频天线设计及性能(通过查CSQ RSRP SNR发现信号较差时)；当发送AT+CEREG?返回+CEREG:0,3时代表基站拒绝模组入网，这可能是SIM卡欠费参数不合法或者基站及核心网参数配置异常造成，可先排除SIM卡，具体分析原因需分析模组侧入网过程LOG及基站侧log排查；当发送AT+CEREG?返回+CEREG:0,0时代表sim卡不可用或不合法、当地无NB基站， 频段不对 、协议栈没开 、模组刚开始启动还在入网过程中 、基站并发数超限等，重点需检查SIM卡及查看当地是否有SIM卡运营商NB基站。

由图5及大量NB-IoT水表运营经验得出结论：驻网异常绝大部分原因为SIM异常及NB-IoT基站信号及参数配置异常，现实中可占到90%以上。上表中可以看到模组清频也是NB-IoT水表乃至所有NB-IoT产品中必须要做的一个动作，下面重点介绍一下NB清频含义及操作。

NB-IoT水表清频逻辑及操作方法

NB-IoT 水表一般在连续2次出现入网超时或2-3次数据发送失败情况下，便会执行异常处理流程-清频操作，清频操作的主要目的是清除模组存储的先验频点，让模组重启后开始全频段搜网，搜索到当前信号最优的小区驻网，从而提高后续网络交互速度和性能，更省电。

清频操作尤其在NB水表刚安装在异地，第一次驻网时可能需要，还有网优对基站做过调整后一般也需要执行清频；一般由MCU程序逻辑触发。

M5310-A清频操作步骤如下：

发送AT+CFUN=0，直到模组返回OK,此步骤包含基站交互步骤根据不同信号环境，最长等待时间可达40秒。一定要等到模组返回执行完毕OK才能发送下一条指令，此过程中模组阻塞，对其他AT指令无响应；发送AT+NCSEARFCN,执行清频操作，模组返回OK代表执行成功；清频执行成功后延时3-5秒关机重启，延时是为了让模组内部执行完毕。必须延时等待，否则清频可能失败。

NB-IoT水表两个技术关键点

NB水表最关键的两点是驻网和省电，一个NB-IoT水表一般寿命为6-8年。NB-IoT单表一般规定一天上传一次数据，传完数据后大部分时间处于PSM休眠或关机。所以电池容量需要经过严谨测试计算，目前M5310-A水表项目使用中主要采用两种节电方式：开关机和PSM，关于两种方式优劣可查看OneMO社区其他专题贴讨论；在大型项目中单小区NB-IoT设备密集，需考虑离散时间入网，才能保证所有设备都能成功驻网并上传数据，离散时间入网算法在此不做深入谈论。目前项目中水表一般设计在凌晨0-8点内离散上传数据，第一次驻网或上传数据失败，延时半小时至1小时(可下发设置参数)再上传一次，一天最多2次(默认)，此参数可平台下发设置，范围0~4；一般M5310-A NB-IoT水表连续几天都未驻网成功，也不会阻止其后续开机驻网，这样的方式主要应对外部基站或者SIM卡临时异常，经排查恢复后水表可以继续上传数据，此机制下电池容量也是经过计算符合要求的。

基于M5310-A NB水表数据传输架构

NB-IoT水表项目一般数量巨大，可达几万到几百万只，此时接入服务器将面临较大考验，主要两种方式，当前大多采用接入OneNET平台：

免费使用CoAP协议接入中移OneNET平台(强大的负载均衡能力)，平台可轻松应对上亿级设备接入。再由平台HTTP推送或MQ消息队列及各种API接口和上级水务管理平台数据交互。利用TCP/UDP等接入客户自建服务器，成本较大开发周期长稳定性较差。

图6 基于OneNET的NB水表方案架构

注：对于入户NB-IoT单表下行数据一般采用缓存命令API下发到OneNET平台，因为水表大多数时间都是休眠或关机状态，只有每日上线时才能收到平台缓存的命令。

基于M5310-A的NB-IoT水表业务流程

注意每天的业务数据发送完成后模组水表AT+MIPLUPDATE更新在平台的lifetime，然后进入PSM或者关机：

图7 基于OneNET的NB-IoT水表业务流程(仅供参考)

注：一天之内数据补发2次未成功(可下发命令修改补发次数)，放弃本次上报，在下一次周期到时补报。

基于M5310-A的NB-IoT水表业务数据典型报文模型及组包方式

LwM2M数据流格式需要遵从IPSO(智能设备国际标准化协议)标准，NB-IoT水表上电后需要创建水司定制的IPSO数据流，平台自动对水表上传的数据流进行识别和呈现，第三方应用通过对这些数据流进行读写操作，完成和水表的数据交互。在该规范中，共定义了3种对象及资源ID，所有水表厂商应统一遵循以下定义上传下发数据，分别如下表所示，抄表数据上传使用对象ID为 3200，资源ID 为5505，具体的描述方法如下：

指令下发以及执行结果上报使用的对象ID以及资源ID相同，对象ID为 3202，资源ID 为5605，具体的描述方法如下：

以下为NB-IoT水表周期上报数据的一个示例：

AT+MIPLNOTIFY=0,0,3200,0,5505,6,227,"68383639393735303336383232333936002002FFC8FFF7000D68E11F0100

C22B91301C20E0DE3EA9E91D2BCD5924112254E4751E0AEA2FB40B9A0854BA5399C0725A1081F21E12C805E9

17E7138……”,0,0,147

其中加粗部分为有效数据，即下面介绍的水表报文经AES加密后的二进制数据。

NB-IoT水表报文格式及组包原则

所有数据尽量打包在一起上传，减小数据交互次数；且尽量减小每包字节大小，有利于省电。一般NB-IoT水表每天周期上传数据只有1包，是由整天记录的各种数据合并的，数据包小于500字节，下表为典型水表报文格式及组包方式，仅供参考：

表1 典型水表报文格式及组包方式

注：报文数据域中TLV数据包含实时数据，周期数据，密集周期数据，普通告警数据，即时告警数据等多种数据。

表2 报文中数据域TLV数据组包格式

表3 TLV中数据ID规范示例

NB水表发送数据异常时的处理措施

发送数据异常主要有以下三种情况，即可分为三种处理方式：

在OneNET指令交互中超时时间内(一般2-5秒)未收到OK或收到error，重发2-3次仍异常直接重启模组，适用范围所有OneNET指令。(AT+MIPLCREATE因存在网络交互，超时时间应设置20-40秒；在OneNET指令交互中超时时间内未收到异步EVENT事件码回复，或或回复失败EVENT事件码，则重发2-3次，此异常一般为外部网络较差引起，典型指令有：MIPLCREATE、MIPLOPEN、MIPLUPDATE、MIPLNOTIFY，此类指令超时时间应设置20-40秒；第二种异常涉及网络交互的指令经过重发仍未收到正确相应，则让模组进入PSM或者关机，等待每天的补发或者下一天的上报周期。

注：对于NB-IoT水表一般会设置每次唤醒或开机交互窗口时间(一般为3-5分钟)，超过此时间则强制模组进入休眠或者关机，达到省电的目的；另外AT指令重发次数和单条超时时间应根据实际应用场景多次测试找出最优值。