一. 來自“M5310-A硬件設計手冊V1.5”
- DCE：Data Communication Equipment
DTE：Data Terminal Equipment
- 模塊的三種工作模式：
| 模式 | 描述 |
|---|---|
| Active | 模塊處於活動狀態；所有功能正常可用，可以進行數據發送和接收；模塊在此模式下可切換到 Idle 模式或 PSM 模式。 |
| Idle | 模塊處於淺睡眠狀態，網絡保持連接狀態，可接收尋呼消息； 模塊在此模式下可切換至 Active 模式或者 PSM 模式。 |
| PSM | 模塊只有 RTC 工作，網絡處於非連接狀態，不可接收尋呼消息； 當DTE（Data Terminal Equipment）主動發送數據或者定時器T3412（與週期性更新相關）超時後，模塊將被喚醒。 |
- 不同模式下模塊功耗示意：
- NB-IOT主要用到兩種節電技術，分別是PSM（Power Saving Mode）和eDRX（Extended DRX）。
- PSM：模塊在PSM下的最大耗流爲5uA。PSM 主要目的是降低模塊功耗，延長電池的供電時間。
①模塊進入PSM的過程如下：模塊在與網絡端建立連接或跟蹤區更新（TAU）時，會在請求消息中申請進入PSM，網絡端在應答消息中配置T3324 定時器數值返回給模塊，並啓動可達定時器。當 T3324 定時器超時後，模塊進入PSM。
模塊在針對緊急業務進行連網或進行公共數據網絡初始化時，不能申請進入PSM。
②當模塊處於PSM模式時，將關閉大部分連網活動，包括停止搜尋小區消息、小區重選等。但是T3412定時器（與週期性TAU更新相關）仍然繼續工作。
③進入PSM後，網絡端將不能尋呼模塊，直到下次模塊啓動連網程序或TAU時，才能發起尋呼。
④模塊有兩種方式退出PSM，一種是DTE主動發送上行數據，模塊退出PSM；另外一種是當T3412定時器超時後，TAU啓動，模塊退出PSM。
⑤注意區分兩個定時器：T3324 定時器是定時進入PSM，T3412定時器是定時啓動TAU。
- eDRX（增強型不連續接收）技術：通過延長DRX時間，減少終端的DRX次數和頻率，從而達到節電目的。
①eDRX可工作於空閒模式和連接模式。
②連接模式下，eDRX把接收間隔擴展至10.24秒。
③空閒模式下，eDRX將尋呼監測和TAU更新間隔擴展至超過40分鐘。
④eDRX節電效果相比PSM差些，但它提高了下行通信鏈路的可到達性，較爲適合保持長連接等的應用。
- 模塊有兩個串口：調試串口和主串口。
主串口：TXD（發送數據到DTE設備的RXD端）、RXD（從DTE設備TXD端接收數據）、RI（振鈴提示）
調試串口：DBG_TXD（發送數據到DTE的串口）、DBG_RXD（從DTE的串口接收數據） - 模塊作爲DCE，並按照傳統的DCE-DTE方式連接。
- 主串口特點：
8個數據位，無奇偶校驗，1停止位。
用於AT命令的發送。
支持波特率：9600、115200。 - 調試串口：
僅用於軟件調試。
波特率爲921600bps。
會自動向外面輸出log信息。
log信息需要專門的軟件抓取解析。
二. 來自“M5310-A AT使用流程實例”
- 模組上電初始化是模組進行正常數據通信業務之前的必須要步驟，在初始化中，模組將會完成網絡搜索、駐網、附着等流程。
- 中移動模組上電初始化建議流程圖：
- 目前M5310-A已支持Band3/Band5/Band8/Band20/Band28頻段。模組本身支持自適應工作頻段功能，也支持鎖定頻段功能。
鎖頻操作的串口指令（鎖定 爲 Band 5和 Band 8）：
AT+NBAND=5,8 - UDP連接測試：
AT+NSOCR="DGRAM",17,0,1 //創建一個socket（17是UDP的協議標號，0表示隨機產生的本地socket編號）
AT+NSOST=0,183.230.40.158,5022,2,1024 //編號爲0的socket向地址183.230.40.18的端口5022，發送2bytes數據，數據是1024
//創建socket時，最後一位設置爲1時，模組會緩存接收到的數據。然後用下面命令，對socket 0中緩存區讀4bytes數據
AT+NSORF=0,4
AT+NSOCL=0 //關閉socket 0 - TCP連接測試（失敗）：
AT+NSOCR="STREAM",6,0,1 //創建一個socket（假設返回的是socket 0）
AT+NSOCO=0,183.230.40.158,5021 //連接到遠程服務器（在這裏失敗，顯示 +NSOCLI: 1，之後進行任何操作均爲ERROR）
AT+NSOSD=0,2,3132 //發送數據 - 上面的查了一下，該返回值應該是說明該socket被關閉，需要重新開始流程。可能是連接錯誤或者超時。猜測應該是該開發板不支持TCP。（關係也不大，主要用的可能還是中移的OneNET平臺，TCP可能不太用到）
三. 來自“M5310-A OneNET平臺接入流程指導手冊”
- AT+MIPLCREATE
①作用：該指令用於在模組端（即M5310-A）創建一個通訊設備實體，同一時間一個終端只允許存在一個通訊設備主體。
②命令格式：AT+MIPLCREATE=<totalsize>,<config>,<index>,<currentsize>,<flag>
③參數解釋：
a.totalsize：表示config 部分的長度，按ASCⅡ計數
b.config：具體的設備配置數據
c.index：配置數據分片參數
d.currentsize：當前分片部分數據長度
e.flag：配置數據流結束符
④使用例子：
AT+MIPLCREATE=49,130031F10003F2002304001100000000000000123138332E3233302E34302E34303A35363833000131F30008C000000000,0,49,0
（中間部分爲註冊碼，所有同一類型的終端設備都可以使用同一個同一設備註冊碼進行配置）
⑤返回值：
（ref是設備實例ID，用於後續操作）
+MIPLCREAT:<ref>
OK - AT+MIPLDELETE
①作用：用於在模組端刪除一個通訊設備實體
②命令格式：AT+MIPLCREATE=<ref> - AT+MIPLADDOBJ
①作用：用於在模組端添加一個待訂閱的object及其所需的instance。
②命令格式：AT+MIPLADDOBJ=<ref>,<objid>,<inscount>,<bitmap>,<atts>,<acts>
③參數說明：
a. ref：設備實例ID
b. objid：Object ID
c. inscount：實例個數
d. bitmap：實例位圖，字符串格式，每一個字符表示爲一個實例，1表示可用，0表示不可用。
e. atts：屬性個數，默認設置爲0即可。
f. acts：操作個數，默認設置爲0即可。
④使用例子：
AT+MIPLADDOBJ=0,3303,1,"1",1,0
AT+MIPLADDOBJ=0,3304,1,"1",1,0 - AT+MIPLDELOBJ
①作用：用於刪除一個已經訂閱的object及其所屬的instance。
②命令格式：AT+MIPLDELOBJ=<ref>,<objid> - AT+MIPLOPEN
①作用：用於在模組端向OneNET 平臺發起註冊登錄請求。
②命令格式：AT+MIPLOPEN=<ref>,<lifetime>[,<timeout>]
③參數說明：
a. lifetime：本次註冊平臺的生命週期，單位是s
b. timeout：註冊的超時時長，可選參數，默認爲30，單位爲s
④使用例子：
AT+MIPLOPEN=0,3000,30 - AT+MIPLNOTIFY
①作用：用於在模組端向OneNET 平臺上報指定資源的數據。
②命令格式：AT+MIPLNOTIFY=<ref>,<msgid>,<objid>,<insid>,<resid>,<type>,<len>,<value>,<index>,<flag>[,<ackid>]
③參數說明：
a. ref：設備實例ID
b. msgid：該resource所屬的instance observe操作時下發的msgid
c. objid：Object ID
d. insid：Instance ID
e. resid：Resource ID
f. type：上報資源的數據類型（1-string，2-opaque，3-integer，4-float，5-bool，6-hex_str）
g. len：value值的長度
h. index：指令序號。可以發N條報文，從N-1到0降序編號，0表示本次Notify指令結束
i. value：上報數據。
j. flag：消息標識，指示第一條或中間或最後一條報文。
④使用例子：
AT+MIPLNOTIFY=0,0,3303,0,5700,4,4,"29.8",0,0
AT+MIPLNOTIFY=0,0,3304,0,5700,4,4,"29.8",0,0
N. 雜七雜八的思考
- OneNET平臺支持多種協議的接入，但實際上不管用什麼協議，目的都是爲了數據的傳輸，只是適用場景不同而已。如LWM2M（NB-IOT）、EDP、MQTT、HTTP、TCP等。
那麼不管用什麼協議，設備端和雲端對數據做的無非還是類似於數據庫的基本操作，增刪查改，只是不同協議的API 存在一定差異。因此我要掌握的大概就是：硬件端怎麼實現、應用端怎麼實現這些增刪查改的操作。 - 既然OneNET支持這麼多種協議的接入，某種意義上好像就能實現所謂的統一，也和OneNET 的名稱符合。但有個問題就是，採用OneNET的平臺終究會存在一定的疑慮，例如中移物聯網靠譜嗎？相比起專門做雲服務器的廠家來說穩定嗎？
不過目前看來開發接入的便利性、和自由可控，兩者好像只能選其一。要穩定、自由可控，可以選擇類似阿里雲、騰訊雲的服務器，然後自己去完成相關的API編寫，理論上也能實現“統一”，可如果僅僅以一人之力，現實嗎？