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

圖1 幾種常見NB水表方案

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

上電開機及模組初始化

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

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

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

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

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

入網(wǎng)判斷

基于NB-IoT基站一個扇區(qū)同一時間只有12-36個信道可用，大量NB-IoT水表入網(wǎng)需做好錯峰處理，錯峰算法主要采用時間離散法。駐網(wǎng)環(huán)節(jié)比較關(guān)鍵，駐網(wǎng)成功與否及時間長短主要取決于外部信號質(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)名詞解釋

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C22B91301C20E0DE3EA9E91D2BCD5924112254E4751E0AEA2FB40B9A0854BA5399C0725A1081F21E12C805E9

17E7138……”,0,0,147

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

NB-IoT水表報文格式及組包原則

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

表1 典型水表報文格式及組包方式

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

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

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

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

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

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

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

總結(jié)

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

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