根據不同的應用場景需求，目前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指令重發次數和單條超時時間應根據實際應用場景多次測試找出最優值。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。