根據(jù)不同的應(yīng)用場(chǎng)景需求，目前NB-IoT水表主要有以下幾種方案：

圖1 幾種常見NB水表方案

接下來將從NB-IoT水表上電開機(jī)、模組初始化、入網(wǎng)判斷、業(yè)務(wù)邏輯四個(gè)環(huán)節(jié)來詳細(xì)講述，以下業(yè)務(wù)流程僅供參考，需根據(jù)實(shí)際應(yīng)用場(chǎng)景測(cè)試及調(diào)整，以達(dá)到最佳性能及功耗要求。

上電開機(jī)及模組初始化

M5310-A上電后自動(dòng)開機(jī)，MCU通過控制模組VBAT腳電源開或斷來控制模組開機(jī)或關(guān)機(jī)。模組開機(jī)后串口自動(dòng)打印開機(jī)信息(默認(rèn)波特率9600)，一般在接收到開機(jī)完成打印的“M5310-A OK”后或者開機(jī)后延時(shí)3-5秒發(fā)送第一條指令：AT，模組上電后MCU需發(fā)送的AT指令如下：

圖2 M5310-A模組開機(jī)流程及異常處理

MCU判斷M5310-A是否正常開機(jī)主要有兩種方式，第一主要通過串口AT是否響應(yīng)判斷，第二還可通過模組VDD_EXT是否有1.8V電壓做判斷，第二種使用較少。

如圖2 M5310-A開機(jī)及初始化異常主要檢查電池電壓是否過低，SIM卡是否接觸不良，如果模組啟動(dòng)過程中頻繁自動(dòng)重啟則檢查RST引腳是否有干擾或啟動(dòng)瞬時(shí)電流過大拉低電源電壓造成。根據(jù)上表中不同的情況MCU可以作相應(yīng)記錄或者指示燈提示，方便檢修人員識(shí)別故障。

注：NB水表MCU程序中只要可配置的參數(shù)應(yīng)全部做成變量形式，如指令重發(fā)次數(shù)、指令超時(shí)等待時(shí)間等，保證重要參數(shù)后期可通過平臺(tái)下發(fā)指令修改。

入網(wǎng)判斷

基于NB-IoT基站一個(gè)扇區(qū)同一時(shí)間只有12-36個(gè)信道可用，大量NB-IoT水表入網(wǎng)需做好錯(cuò)峰處理，錯(cuò)峰算法主要采用時(shí)間離散法。駐網(wǎng)環(huán)節(jié)比較關(guān)鍵，駐網(wǎng)成功與否及時(shí)間長(zhǎng)短主要取決于外部信號(hào)質(zhì)量及水表自身天線射頻性能，具體入網(wǎng)AT流程見下圖：

圖3 模組入網(wǎng)判斷流程

一般NB-IoT水表協(xié)議規(guī)定，需上傳模組及網(wǎng)絡(luò)相關(guān)信息，所以上表中有獲取NB網(wǎng)絡(luò)信息相關(guān)指令，需要上傳的參數(shù)一般有：IMEI、RSRP、SNR、CELLID、ECL、CCLK、IMSI、PCI等。

圖4 駐網(wǎng)相關(guān)名詞解釋

幾種典型場(chǎng)景的入網(wǎng)時(shí)間介紹及異常處理，圖5駐網(wǎng)評(píng)估時(shí)間及信號(hào)判斷標(biāo)準(zhǔn)僅供參考，實(shí)際請(qǐng)以實(shí)網(wǎng)測(cè)試為準(zhǔn)：

圖5 幾種典型場(chǎng)景的入網(wǎng)時(shí)間介紹及異常處理

入網(wǎng)異常判斷及原因和處理方法

當(dāng)發(fā)送AT+CEREG?返回+CEREG:0,2 時(shí)代表模組正在嘗試駐網(wǎng)，長(zhǎng)時(shí)間保持此返回值可能信號(hào)較差或者是首次駐網(wǎng)需要較長(zhǎng)時(shí)間，解決辦法主要為使用AT+NBAND鎖頻段(異地首次入網(wǎng))及網(wǎng)優(yōu)優(yōu)化網(wǎng)絡(luò)及查看射頻天線設(shè)計(jì)及性能(通過查CSQ RSRP SNR發(fā)現(xiàn)信號(hào)較差時(shí))；當(dāng)發(fā)送AT+CEREG?返回+CEREG:0,3時(shí)代表基站拒絕模組入網(wǎng)，這可能是SIM卡欠費(fèi)參數(shù)不合法或者基站及核心網(wǎng)參數(shù)配置異常造成，可先排除SIM卡，具體分析原因需分析模組側(cè)入網(wǎng)過程LOG及基站側(cè)log排查；當(dāng)發(fā)送AT+CEREG?返回+CEREG:0,0時(shí)代表sim卡不可用或不合法、當(dāng)?shù)責(zé)oNB基站， 頻段不對(duì) 、協(xié)議棧沒開 、模組剛開始啟動(dòng)還在入網(wǎng)過程中 、基站并發(fā)數(shù)超限等，重點(diǎn)需檢查SIM卡及查看當(dāng)?shù)厥欠裼蠸IM卡運(yùn)營(yíng)商N(yùn)B基站。

由圖5及大量NB-IoT水表運(yùn)營(yíng)經(jīng)驗(yàn)得出結(jié)論：駐網(wǎng)異常絕大部分原因?yàn)镾IM異常及NB-IoT基站信號(hào)及參數(shù)配置異常，現(xiàn)實(shí)中可占到90%以上。上表中可以看到模組清頻也是NB-IoT水表乃至所有NB-IoT產(chǎn)品中必須要做的一個(gè)動(dòng)作，下面重點(diǎn)介紹一下NB清頻含義及操作。

NB-IoT水表清頻邏輯及操作方法

NB-IoT 水表一般在連續(xù)2次出現(xiàn)入網(wǎng)超時(shí)或2-3次數(shù)據(jù)發(fā)送失敗情況下，便會(huì)執(zhí)行異常處理流程-清頻操作，清頻操作的主要目的是清除模組存儲(chǔ)的先驗(yàn)頻點(diǎn)，讓模組重啟后開始全頻段搜網(wǎng)，搜索到當(dāng)前信號(hào)最優(yōu)的小區(qū)駐網(wǎng)，從而提高后續(xù)網(wǎng)絡(luò)交互速度和性能，更省電。

清頻操作尤其在NB水表剛安裝在異地，第一次駐網(wǎng)時(shí)可能需要，還有網(wǎng)優(yōu)對(duì)基站做過調(diào)整后一般也需要執(zhí)行清頻；一般由MCU程序邏輯觸發(fā)。

M5310-A清頻操作步驟如下：

發(fā)送AT+CFUN=0，直到模組返回OK,此步驟包含基站交互步驟根據(jù)不同信號(hào)環(huán)境，最長(zhǎng)等待時(shí)間可達(dá)40秒。一定要等到模組返回執(zhí)行完畢OK才能發(fā)送下一條指令，此過程中模組阻塞，對(duì)其他AT指令無響應(yīng)；發(fā)送AT+NCSEARFCN,執(zhí)行清頻操作，模組返回OK代表執(zhí)行成功；清頻執(zhí)行成功后延時(shí)3-5秒關(guān)機(jī)重啟，延時(shí)是為了讓模組內(nèi)部執(zhí)行完畢。必須延時(shí)等待，否則清頻可能失敗。

NB-IoT水表兩個(gè)技術(shù)關(guān)鍵點(diǎn)

NB水表最關(guān)鍵的兩點(diǎn)是駐網(wǎng)和省電，一個(gè)NB-IoT水表一般壽命為6-8年。NB-IoT單表一般規(guī)定一天上傳一次數(shù)據(jù)，傳完數(shù)據(jù)后大部分時(shí)間處于PSM休眠或關(guān)機(jī)。所以電池容量需要經(jīng)過嚴(yán)謹(jǐn)測(cè)試計(jì)算，目前M5310-A水表項(xiàng)目使用中主要采用兩種節(jié)電方式：開關(guān)機(jī)和PSM，關(guān)于兩種方式優(yōu)劣可查看OneMO社區(qū)其他專題貼討論；在大型項(xiàng)目中單小區(qū)NB-IoT設(shè)備密集，需考慮離散時(shí)間入網(wǎng)，才能保證所有設(shè)備都能成功駐網(wǎng)并上傳數(shù)據(jù)，離散時(shí)間入網(wǎng)算法在此不做深入談?wù)摗Ｄ壳绊?xiàng)目中水表一般設(shè)計(jì)在凌晨0-8點(diǎn)內(nèi)離散上傳數(shù)據(jù)，第一次駐網(wǎng)或上傳數(shù)據(jù)失敗，延時(shí)半小時(shí)至1小時(shí)(可下發(fā)設(shè)置參數(shù))再上傳一次，一天最多2次(默認(rèn))，此參數(shù)可平臺(tái)下發(fā)設(shè)置，范圍0~4；一般M5310-A NB-IoT水表連續(xù)幾天都未駐網(wǎng)成功，也不會(huì)阻止其后續(xù)開機(jī)駐網(wǎng)，這樣的方式主要應(yīng)對(duì)外部基站或者SIM卡臨時(shí)異常，經(jīng)排查恢復(fù)后水表可以繼續(xù)上傳數(shù)據(jù)，此機(jī)制下電池容量也是經(jīng)過計(jì)算符合要求的。

基于M5310-A NB水表數(shù)據(jù)傳輸架構(gòu)

NB-IoT水表項(xiàng)目一般數(shù)量巨大，可達(dá)幾萬(wàn)到幾百萬(wàn)只，此時(shí)接入服務(wù)器將面臨較大考驗(yàn)，主要兩種方式，當(dāng)前大多采用接入OneNET平臺(tái)：

免費(fèi)使用CoAP協(xié)議接入中移OneNET平臺(tái)(強(qiáng)大的負(fù)載均衡能力)，平臺(tái)可輕松應(yīng)對(duì)上億級(jí)設(shè)備接入。再由平臺(tái)HTTP推送或MQ消息隊(duì)列及各種API接口和上級(jí)水務(wù)管理平臺(tái)數(shù)據(jù)交互。利用TCP/UDP等接入客戶自建服務(wù)器，成本較大開發(fā)周期長(zhǎng)穩(wěn)定性較差。

圖6 基于OneNET的NB水表方案架構(gòu)

注：對(duì)于入戶NB-IoT單表下行數(shù)據(jù)一般采用緩存命令A(yù)PI下發(fā)到OneNET平臺(tái)，因?yàn)樗泶蠖鄶?shù)時(shí)間都是休眠或關(guān)機(jī)狀態(tài)，只有每日上線時(shí)才能收到平臺(tái)緩存的命令。

基于M5310-A的NB-IoT水表業(yè)務(wù)流程

注意每天的業(yè)務(wù)數(shù)據(jù)發(fā)送完成后模組水表AT+MIPLUPDATE更新在平臺(tái)的lifetime，然后進(jìn)入PSM或者關(guān)機(jī)：

圖7 基于OneNET的NB-IoT水表業(yè)務(wù)流程(僅供參考)

注：一天之內(nèi)數(shù)據(jù)補(bǔ)發(fā)2次未成功(可下發(fā)命令修改補(bǔ)發(fā)次數(shù))，放棄本次上報(bào)，在下一次周期到時(shí)補(bǔ)報(bào)。

基于M5310-A的NB-IoT水表業(yè)務(wù)數(shù)據(jù)典型報(bào)文模型及組包方式

LwM2M數(shù)據(jù)流格式需要遵從IPSO(智能設(shè)備國(guó)際標(biāo)準(zhǔn)化協(xié)議)標(biāo)準(zhǔn)，NB-IoT水表上電后需要?jiǎng)?chuàng)建水司定制的IPSO數(shù)據(jù)流，平臺(tái)自動(dòng)對(duì)水表上傳的數(shù)據(jù)流進(jìn)行識(shí)別和呈現(xiàn)，第三方應(yīng)用通過對(duì)這些數(shù)據(jù)流進(jìn)行讀寫操作，完成和水表的數(shù)據(jù)交互。在該規(guī)范中，共定義了3種對(duì)象及資源ID，所有水表廠商應(yīng)統(tǒng)一遵循以下定義上傳下發(fā)數(shù)據(jù)，分別如下表所示，抄表數(shù)據(jù)上傳使用對(duì)象ID為 3200，資源ID 為5505，具體的描述方法如下：

指令下發(fā)以及執(zhí)行結(jié)果上報(bào)使用的對(duì)象ID以及資源ID相同，對(duì)象ID為 3202，資源ID 為5605，具體的描述方法如下：

以下為NB-IoT水表周期上報(bào)數(shù)據(jù)的一個(gè)示例：

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

C22B91301C20E0DE3EA9E91D2BCD5924112254E4751E0AEA2FB40B9A0854BA5399C0725A1081F21E12C805E9

17E7138……”,0,0,147

其中加粗部分為有效數(shù)據(jù)，即下面介紹的水表報(bào)文經(jīng)AES加密后的二進(jìn)制數(shù)據(jù)。

NB-IoT水表報(bào)文格式及組包原則

所有數(shù)據(jù)盡量打包在一起上傳，減小數(shù)據(jù)交互次數(shù)；且盡量減小每包字節(jié)大小，有利于省電。一般NB-IoT水表每天周期上傳數(shù)據(jù)只有1包，是由整天記錄的各種數(shù)據(jù)合并的，數(shù)據(jù)包小于500字節(jié)，下表為典型水表報(bào)文格式及組包方式，僅供參考：

表1 典型水表報(bào)文格式及組包方式

注：報(bào)文數(shù)據(jù)域中TLV數(shù)據(jù)包含實(shí)時(shí)數(shù)據(jù)，周期數(shù)據(jù)，密集周期數(shù)據(jù)，普通告警數(shù)據(jù)，即時(shí)告警數(shù)據(jù)等多種數(shù)據(jù)。

表2 報(bào)文中數(shù)據(jù)域TLV數(shù)據(jù)組包格式

表3 TLV中數(shù)據(jù)ID規(guī)范示例

NB水表發(fā)送數(shù)據(jù)異常時(shí)的處理措施

發(fā)送數(shù)據(jù)異常主要有以下三種情況，即可分為三種處理方式：

在OneNET指令交互中超時(shí)時(shí)間內(nèi)(一般2-5秒)未收到OK或收到error，重發(fā)2-3次仍異常直接重啟模組，適用范圍所有OneNET指令。(AT+MIPLCREATE因存在網(wǎng)絡(luò)交互，超時(shí)時(shí)間應(yīng)設(shè)置20-40秒；在OneNET指令交互中超時(shí)時(shí)間內(nèi)未收到異步EVENT事件碼回復(fù)，或或回復(fù)失敗EVENT事件碼，則重發(fā)2-3次，此異常一般為外部網(wǎng)絡(luò)較差引起，典型指令有：MIPLCREATE、MIPLOPEN、MIPLUPDATE、MIPLNOTIFY，此類指令超時(shí)時(shí)間應(yīng)設(shè)置20-40秒；第二種異常涉及網(wǎng)絡(luò)交互的指令經(jīng)過重發(fā)仍未收到正確相應(yīng)，則讓模組進(jìn)入PSM或者關(guān)機(jī)，等待每天的補(bǔ)發(fā)或者下一天的上報(bào)周期。

注：對(duì)于NB-IoT水表一般會(huì)設(shè)置每次喚醒或開機(jī)交互窗口時(shí)間(一般為3-5分鐘)，超過此時(shí)間則強(qiáng)制模組進(jìn)入休眠或者關(guān)機(jī)，達(dá)到省電的目的；另外AT指令重發(fā)次數(shù)和單條超時(shí)時(shí)間應(yīng)根據(jù)實(shí)際應(yīng)用場(chǎng)景多次測(cè)試找出最優(yōu)值。

總結(jié)

以上是生活随笔為你收集整理的m5310模组数据上传至onenet_硬核干货！基于M5310-A的NB-IoT水表通信模块软件业务逻辑分享...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。