概述

本文繼續使用小熊派IoT主板+NB28-A通信擴展板進行實驗。文中將描述 NB28-A/BC28-CNV 通信模組使用AT指令連接華為IoTDA平臺、發送和接收數據的詳細流程步驟，并對該流程中所涉及的AT指令做出了工作原理級別的注釋，以真正理解此通信交互過程。

@HISTORY
基本實驗過程請參考 #< IoT/HCIP/基于NB-IoT模組的AT指令實驗（小熊派IoT+NB28-A模組）>#，本文對其中 “NB28-A通信模組接入華為IoTDA平臺” 章節內容做展開說明。在進行AT指令測試前，會先簡單分析AT指令是如何從通信模組出發，經過了哪些路徑最終到達華為IoTDA平臺，主要涉及NB-IoT物聯網解決架構中，無線接入網和NB-IoT核心網層的相關基礎知識。

檢查通信環境

NB-IoT是4G時代的產物，但被納入5G及未來6G體系。 NB-IOT其作為4G LTE的衍生技術，其設計初衷是替代2G/3G的物聯網連接，尤其適用于智能表計、環境監測等靜態場景。NB-IoT具有比GSM高20dB的覆蓋增益，可以在地下車庫、地下室等信號難以到達的地方實現覆蓋 。5G通過兼容性升級（如Release 16支持NB-IoT與5G核心網對接）和功能擴展（如低功耗喚醒、衛星直連），增強了NB-IoT的廣覆蓋和移動性支持。NB-IoT 已被納入5G標準，成為5G時代物聯網的核心技術之一。它將與NR(New Radio)技術結合，滿足大規模機器連接(mMTC)場景的需求。預計6G將繼承5G的物聯網能力，并可能通過AI原生設計、通感一體化（通信與感知融合）等特性優化NB-IoT的性能。

該章節的AT實驗，尚未觸及IoTDA操作，只是在配置和檢查通信鏈路。也就是說，理論上，執行本章中的AT指令設置和查詢操作前，不必執行任何與平臺通信相關的PSK、CDP、DTLS等配置操作。上邊這個小結論也經過了我的實際驗證，我并沒有找到直接恢復出廠設置的辦法，只是通過最笨的配置覆蓋的方式，消除所有曾經執行過的正確或異常的配置信息。

若你之前進行過某些操作，或打開過UE功能，那么最好先臨時關閉。

通信模組固件

# 查詢固件信息
ATI

我先要強調的是如上版本，足夠完成HCIP-IoT2.5中的所有實驗。遇到問題，請先不要往固件上甩。
1、升級過程不是很簡單，我嘗試使用QFlash升級，暫時沒有成功。移遠通信的FAE說，為了升級這個NB28-A的固件，可能需要從通信板單獨引出串口，而不能直接使用主板上的多合一功能的USB數據線。
2、模組內現在的固件版本是BC28CNVBAR02A03，而針對此型號的最新固件版本是04（202503從移遠通信FAE獲取）。網絡中提及到一些BC28JAR01A08/09等固件升級包，這些是不適用于我們的BC28CNVBA通信模組的，不要瞎搞。

信號強度

//確認插好了SIM卡 //獲取SIM卡的ICCID（集成電路卡識別碼）
AT+NCCID
//響應
+NCCID:89860496162180471954//查詢SIM卡的PIN碼狀態，間接判斷SIM卡是否就緒
AT+CPIN?
//響應
+CPIN: READY//獲取信號強度指示
AT+CSQ
//響應
+CSQ:15,99

一般資料顯示最低要求為10，我們的NB28-A模組是沒有外置天線的，信號強度并不高，如上，我的才15-16的樣子。移遠通信的FAC告訴我15這個值，不太樂觀，可能會導致失敗，但我最終是成功了的，說明15還湊合。后來的一次測試中，我收到了 +CSQ:99,99 反饋。

也就是說信號強度無法檢測到，難道是昨天刮大風，基站壞了？原來是小問題，我當時處于AT+CFUN=0 即射頻關閉的狀態，此時 AT+CIMI 都無法調用，現象類似于SIM無法被識別。

CGATT指令參數 / 啥是PS域？

AT+CGATT 的參數說明中提到了（附著到）PS域的概念，我一開始并不太理解此概念。在成功完成一次實驗后，我倒回頭來重新測試該指令。對于BC28-CNV模組，即使我沒有配置PSK、沒有開啟DTLS、沒有正確配置CDP服務時，網絡附著狀態依然是正確的！那么這個PS域附著狀態到底是甚？當通信模組運行起來后，我們談及它是否成功附著到PS域這個問題，PS域在哪里？其對應什么實物設備？是基站？是路由器？還是什么移動通信供應商的某某系統或模塊？是什么呢？

作為小白，為了得到上述問題的答案，我費了不少功夫，整理了 #< IoT/HCIP/細致解讀 NB-IoT 無線接入層與核心網層 >#。結合該文的討論，

一個小結論是，在NB-IoT網絡中，所謂附著到PS域（分組交換域）的本質是通過EPC核心網的MME（移動性管理實體）完成移動性管理和會話管理。用戶（通信模組）附著到PS域的過程，本質上是與MME建立信令連接，并由MME協調其他核心網元（如SGW、PGW）完成數據承載的配置。

PS附著狀態：AT+CGATT

該命令用于將 MT 附著于 PS 域或將 MT 從 PS 域去附著。命令執行后，MT 保持在 V.250 命令狀態。如果MT已經處于請求的 <state> 設置狀態，則會忽略此命令，并返回OK響應。如果正在執行AT+CGATT，在附著或去附著注冊步驟完成之前，再次執行此命令會返回錯誤。如果未達到請求狀態，則會響應 ERROR 或 +CME ERROR: <err>。

注意參數說明，當state=1 時，自動選擇 AT+COPS=0，這可能是在HCIP-IoT實驗手冊中，并沒有提及AT+COPS指令執行過程的原因。

發送AT+CGATT，檢測網絡是否激活，為1激活，0未激活，若信號正常的情況下未激活，可以等待10s在發送試試。

#查詢命令
AT+CGATT?
#響應
+CGATT:1
#設置命令
AT+CGATT=<state>

PLMN 選擇：AT+COPS

在此之前，我只能大約意識到，通信模組上肯定是要有類似于手機信號接收和發送設備的硬件或模塊，不光可以接收中國移動信號，也可以接收中國聯通和中國電信的信號。實際上，
通信模組實現多運營商（如中國移動、中國聯通、中國電信）信號接收和發送的核心硬件模塊主要包括以下關鍵組件：多模多頻段射頻前端模塊、基帶處理單元、天線調諧器與多路復用器、SIM卡槽與eSIM技術。通信模組實現多運營商信號接收的硬件核心是多模射頻前端模塊和基帶芯片組，通過射頻開關、功率放大器、濾波器等電路動態適配不同頻段，結合SIM/eSIM技術實現網絡切換。
在射頻前端模塊中，“多模”指的是該模塊能夠支持多種通信制式或技術標準的能力。通信制式的多樣性，多模射頻前端需支持多種蜂窩網絡標準，例如：2G：GSM、CDMA；3G：WCDMA、TD-SCDMA；4G：TD-LTE、FDD-LTE；5G：Sub-6GHz、毫米波頻段。非蜂窩技術：Wi-Fi、藍牙、GPS 等。協議棧兼容性，基帶芯片需集成不同通信模式的協議棧，例如在4G/5G雙模芯片中，需同時處理LTE和NR（New Radio）的物理層協議。

#查詢指令
AT+COPS?
#我的響應
+COPS:0,2,"46000"
#@Note /在CFUN關閉設置的情況下COPS設置指令是無法執行的，提示524(UE 處于最小功能模式)異常
AT+COPS=0

先簡單說下，<mode> 網絡選擇模式，自動或手動，我這里為0自動。 <format> 運營商名稱格式，BC28下只有=2數字編碼格式一種選擇。 <oper> 是運營商信息 46000 代表中國移動（MCC=460，MNC=00）。MCC（Mobile Country Code），460 是中國唯一的移動國家代碼，全球通用。MNC（Mobile Network Code），00 是中國移動的國內網絡代碼（46000、46002、46004等用于細分業務），類似的，中國其他運營商標識，中國聯通（46001）、中國電信（46003）、中國廣電（46015）等。

再開始前，先普及幾個 AT+COPS 指令說明中提到的概念，

PLMN（Public Land Mobile Network，公共陸地移動網絡） 是由政府或運營商建立的移動通信網絡，用于為公眾提供無線通信服務。其核心標識由 MCC（移動國家碼） 和 MNC（移動網絡碼） 組成，例如中國移動的 PLMN 為 46000，中國聯通為 46001。與普通 SIM 卡相比，USIM 卡容量更大（支持 4G/5G 網絡）、安全性更高，且支持遠程管理（如 eSIM 技術）。EPS（Evolved Packet System，演進分組系統） 是 LTE（4G）網絡的核心架構，由以下兩部分組成：E-UTRAN（無線接入網）和 EPC（核心網）。

指令 AT+COPS 主要用以設置命令強制嘗試使用安裝在當前所選卡槽中的 USIM 卡來選擇和注冊 EPS 網絡運營商。參數 <mode> 用來設置找網動作，是由 UE 自動完成，還是通過該命令以特定的接入方式 <AcT>，強制選擇運營商 <oper>（由 <format> 指定）。這個指令的參數看起來很復雜，但通常情況下，我們都會配置mode為0，后邊的參數不需要。這條指令確實挺復雜，以后可能還要繼續探究，臨時先點到為止。mode == 0 是默認參數，我們初階應用中，可以不執行此命令。

CEREG指令參數 / 啥是EPS與EPC?

EPS網絡由運營商完全管理和控制。
EPS（Evolved Packet System） 是3GPP定義的4G LTE網絡的核心架構，由 EPC（Evolved Packet Core，演進分組核心網）和E-UTRAN（Evolved UMTS Terrestrial Radio Access Network，演進的UMTS陸地無線接入網）組成。EPC負責核心網功能，包括用戶認證、移動性管理、數據路由等，包含MME（移動管理實體）、SGW（服務網關）、PGW（PDN網關）等核心節點。E-UTRAN是無線接入網絡，對應LTE基站（eNodeB）。 EPS通過全IP架構實現高速數據傳輸和低延遲，支持多接入技術（如LTE、3G、Wi-Fi）的融合。

CEREG指令參數 / 啥是URC?

URC（Unsolicited Result Code） 是未經請求的結果碼，由設備主動上報的狀態信息，無需用戶主動查詢。例如，當網絡注冊狀態變化時，設備會自動發送+CEREG: 通知用戶。這里的設備是？用戶是？
上文中的設備：（不同于云端設備、不同于IoT終端設備）
指通信模組本身（如蜂窩模組、NB-IoT模組等），例如我們目前在使用的BC28-CNV。設備，負責與運營商網絡進行通信（如注冊、數據傳輸）。主動執行網絡狀態監測，并在事件觸發時（如網絡注冊狀態變化）生成URC。示例行為：
當模組從4G網絡切換至2G網絡時，自動通過串口發送+CEREG: 1，2。當網絡信號丟失時，發送+CEREG: 0表示未注冊。
上文中的用戶：
指控制通信模組的外部主控設備或應用程序（如單片機、嵌入式Linux主機、PC軟件、PC串口終端等）。用戶可以通過發送AT指令（如AT+CEREG=1）配置模組行為。接收并解析模組返回的響應（包括URC），根據狀態執行后續邏輯（如重連、告警）。示例行為：
主控單片機通過串口發送AT+CEREG=1，啟用URC功能。當收到+CEREG: 1,5（漫游注冊成功）時，主控程序記錄日志或通知用戶。

為什么需要URC？
1、實時性：用戶無需輪詢查詢狀態，降低通信開銷。
2、事件驅動：例如在物聯網設備中，當模組斷網時，主控程序可通過URC立即觸發故障恢復流程。
3、資源優化：避免主控端頻繁發送AT指令占用串口資源。

常見的URC/設備主動上報的狀態信息，
網絡注冊狀態（AT+CEREG的Stat響應參數）、信號丟失、網絡切換通知（如在2G/3G/4G/5G網絡間切換）、漫游狀態更新、服務拒絕（如SIM卡無效或網絡限制）、短信接收、來電顯示、PDP上下文激活/去激活、IP地址分配、低電量警告（部分模組支持）、硬件故障（部分模組支持）、小區切換通知、GPS定位數據、無線制式切換、NB-IoT/eMTC狀態（專用模組可能通過 +NUESTATS 上報窄帶物聯網連接狀態）、廠商的自定義事件和診斷信息等。URC的設計覆蓋了設備與網絡交互的全生命周期事件，從底層硬件狀態到高層業務邏輯均有涉及。開發中需根據具體模組手冊配置URC訂閱模式，并結合實際場景處理異步事件。

網絡注冊狀態：AT+CEREG

AT+CEREG 設置和查詢 EPS 網絡注冊狀態。Evolved Packet System 是演進分組核心網，是由移動網絡供應商全權管控的，特別要注意的是，在此提到的網絡注冊狀態其與IoTDA物聯網平臺還沒有扯上半丁點關系。

這條指令看上去也很復雜，我在我的環境下執行了查詢指令，

我的響應中，第二個值是<stat>，其取值含義為，

結合本小節及其前兩個小節，對于我們初學者，一個比較合適的配置是，

//設置/啟用URC功能
AT+CEREG=1
//響應
OK
//查詢
AT+CEREG?
//響應 /若沒有設置AT+CEREG=1，則查詢返回+CEREG:0,1
+CEREG:1,1

實踐結果表明，無論是否開啟URC功能，CEREG網絡注冊狀態查詢結果都是 stat==1 已注冊本地網絡。所謂 “本地網絡” 指用戶歸屬的運營商網絡（Home PLMN），即SIM卡所屬的運營商網絡。中國移動用戶的SIM卡在中國移動基站下注冊時，stat=1，若中國移動用戶漫游到其他運營商網絡（如中國聯通），則stat=5（已注冊漫游網絡）。

網絡附著和網絡注冊

我們進一步來區分下網絡附著狀態和網絡注冊狀態。這里提到的網絡都是指EPC核心網，而與平臺網絡無關。通信模組與核心網建立通信的過程，必須是先完成附著，才能發起注冊流程，盡管在我們的實驗中，這些是自動完成的。具體的，終端通過NAS信令（如Attach Request）向核心網發起附著；附著成功后，通過Service Request向基站申請資源，完成注冊（CEREG=1）。

@另外需要注意的是，要區分網絡注冊狀態和后文提到的消息注冊狀態，
前文提到AT+CEREG所謂的網絡注冊狀態是設備注冊移動通信供應商核心網的狀態，與IoTDA無關。而與IoTDA有關的狀態是后文將要講解的AT+NMSTATUS消息注冊狀態。如果沒有成功接入IoTDA，試圖查詢消息注冊狀態，將收到+NMSTATUS:REG_FAILED告警。

AT指令接入IoTDA完整流程

我們先實踐一次完整的AT指令接入IoTDA，然后再對每條指令進行展開說明。

#if //只要射頻打開CFUN=1/無論對云端的配置是否合理
//選擇運營商
AT+COPS=0
//PS域附著狀態
AT+CGATT?
//可選設置/啟用URC功能
AT+CEREG=1
//查詢網絡注冊狀態 /期望結果 +CEREG:1,1
AT+CEREG?
#endif//關閉協議棧/射頻功能
AT+CFUN=0//PSK_ID和PSK //秘鑰明碼 @note 若秘鑰不對將返回Error4 /這里IoTDA存在Bug，具體參見后文。
AT+QSETPSK=0,xxxxxxxxxxxx
//CDP服務器設置 /IP地址使用[ping 域名] 方式獲取
AT+NCDP=AT+NCDP=124.70.30.197,5684
//打開DTLS加密
AT+QSECSWT=1//打開協議棧/射頻
AT+CFUN=1
//檢查消息注冊狀態 //期望結果+NMSTATUS:MO_DATA_ENABLED
AT+NMSTATUS?//執行數據發送測試
AT+NMGS=5,00193C0064

設置 UE 功能：AT+CFUN

在HCIP-IOT實驗手冊中，AT+CFUN=1的功能被表述為打開協議棧功能，這似乎有些片面。

執行諸如 AT+NCDP 配置物聯網平臺服務器地址和端口前，通常先執行 AT+CFUN=0 關閉模組的射頻功能，主要原因如下：
1、模組處于全功能模式（AT+CFUN=1）時，射頻模塊會主動嘗試附著網絡并發送數據。此時修改關鍵參數（如NCDP）可能導致網絡連接中斷或協議棧異常。部分模組在全功能模式下會鎖定非易失性存儲（NV），禁止修改已保存的配置。
2、部分模組默認開啟自動注冊（如 AT+NCONFIG=AUTOCONNECT,TRUE），若未關閉射頻，模組可能在配置過程中嘗試連接舊服務器地址，導致配置失敗或數據錯亂。
3、射頻開啟時信號強度（AT+CSQ）可能波動，影響配置穩定性。之前有接觸過某手環主板的測試，在向衛星發射信號的瞬間，其電流可以高達恐怖的5A，可以想象嗎。

因此，
在進行相關配置前，最好先 “用戶關機”，這可能不是必須的，但建議養成良好的習慣。

設置秘鑰PSK：AT+QSETPSK

這里的PSK（預共享秘鑰）是你如下圖創建設備時，輸入的8-32個16進制字符（秘鑰創建和重置卡都是這么要求的）

這里有個巨大的BUG，我不知道問題具體出在哪里，只是在現象級搞清楚了。如上在AT+QSETPSK參數說明里，指出PSK是固定16位16進制數字，在平臺測設備創建卡（如上圖）和秘鑰重置窗（如下圖）中，要求是8-32位16進制數字，是矛盾的。

經過實踐可知（時間202503），如果上述PSK配置位數小于16位數字，則被判定為無效。測試使用9位、15位秘鑰，在串口終端中執行AT+QSETPSK=0,xxxx 指令時，均被反饋 +CME ERROR: 4，只有當秘鑰位數大于等于16位數字時，QSETPSK設置操作才能返回OK成功。咱就說，這坑不坑爹吧，至于這是平臺測的鑒權失敗？還是直接在通信模組測指令參數就校驗失敗？我尚分不清。
在這里，我曾經讓CME ERROR: 4（不支持該操作）坑了好一陣子，這里的不支持并不是沒有目標指令功能。在指令信號強度不足、當前指令參數錯誤、前置操作不合理（如CDP配置錯誤、秘鑰錯誤）等情況下均可能返回。因此所謂的不支持，可能需要解釋為在當前執行上下文中，目標操作無法完成用戶的期望或請求。

所謂設備認證類型，可參見LwM2M/CoAP協議鑒權。LwM2M/CoAP協議鑒權支持加密與非加密兩種接入方式，若設備采用非加密方式接入時，非加密端口為5683，在設備接入物聯網平臺時攜帶設備唯一標識nodeId，完成設備的接入鑒權；當設備采用加密方式接入時，加密業務數據交互端口為5684，使用DTLS/DTLS+傳輸層安全協議通道接入，并攜帶nodeId和密鑰以完成設備的接入鑒權。

若我們創建設備時不設置秘鑰，是不是就不用進行AT+QSETPSK操作呢？不是的，

另外，不要輕易暴露自己的設備序列號，因為不能重復注冊，

設置CDP服務器：AT+NCDP

參數 <IP_addr> 字符串型，為 LwM2M 物聯網平臺 IP 地址，支持 IPv4、IPv6 類型的 IP 地址或域名。參數 <port> 無符號整型，取值0~65535，默認值為 5683。若配置端口為 0，則使用默認端口；若沒有指定端口，則使用之前設置的端口；若沒有指定端口且之前未設置，則使用默認端口。那么什么是CDP服務呢？
開始的時候Deepseek高速我她是 Customer Data Platform Service 的縮寫，其實不是。正解 Connect Device Platform 可參考AT指令手冊縮寫附錄表，

在物聯網通信場景（尤其是NB-IoT模組配置）中提到的CDP服務，特指華為物聯網平臺中用于設備數據接入與管理的核心服務。在我們的實驗場景下她代表的即是華為云 IoTDA 服務平臺。CDP服務的核心功能包括，設備注冊與認證，數據采集與傳輸，指令下發與控制，協議轉換與適配。

特別要注意的是，參數配置后要重啟模組才能生效，重啟、要重啟， 在重啟前，新配置不會生效，即使你在配置CDP時，立即返回了OK。還要理解到，此參數會被自動保存到KV中，

KV存儲將參數以鍵（Key）和值（Value）的形式保存到模組的 非易失性存儲器（如Flash或EEPROM） 中，確保數據在斷電、重啟或深休眠（PSM）后仍能保留。更深層次的存儲機制，這里不再探討。

//如下執行返回 +CME ERROR: 4
AT+NCDP=xx,5683
//一個錯誤的地址(把正確域名刪了一大部分)，也可以返回OK /看來檢查有限啊
AT+NCDP=aps.cn-north-4.myhuaweicloud,5684

接入信息

從實例總覽 - 接入信息 - 設備接入，路徑中找到并復制，我的域名信息如下，

實際不支持域名

接下來是重點， 也是HCIP實驗最開始失敗的關鍵原因，
BC28手冊中如上描述 NCDP 指令的 <IP_addr> 參數可支持域名格式，但實際上這里存在BUG，使用(正確的)域名并不能成功接入華為云IoTDA平臺，至于BUG在哪個層次上，我目前分析不出來。我只談談我的測試，

//使用域名配置/重啟后不生效(以5分鐘為觀察期)
AT+NCDP=4b4d70ade3.st1.iotda-coaps.cn-north-4.myhuaweicloud.com,5684
//使用IPV4地址 /重啟10s后生效
AT+NCDP=124.70.30.197,5684

那么，如何獲取域名對應的IP地址呢，在本機cmd中運行ping命令，

理論上，你在不同機器上ping上述域名，得到的IP地址是一致的。如此，你在進CDP服務配置時，就先不要直接使用域名了，而是使用其實際對應的服務端IP地址。

端口號也不能錯

//使用IP地址，配置半生效?
AT+NCDP=124.70.30.197,5683

一個意外的實驗，陰差陽錯下我在DTLS開啟狀態下，測試了IP+5683配置，實驗結果如下，
重啟模組幾分鐘后收到 +QDTLSSTAT:3 異步事件，此事件是 DTLS（Datagram Transport Layer Security）協議連接狀態的反饋碼，表示 DTLS握手失敗。為了探個究竟，我也測試了不開啟DTLS，且使用非加密端口5683配置的情況，此時不會收到QDTLSSTAT事件。綜合測試發現，使用5683端口的情況下，無論DTLS是否開啟，NMGS等操作，都會返回ERROR:4錯誤。

我嘗試ping去掉s的域名，是不成功的，故現在我不能確定5683/CoAP的域名或IP地址。

DTLS模式：AT+QSECSWT

受限的應用協議，CoAP（Constrained Application Protocol），基于UDP的非加密協議，默認端口為5683，適用于資源受限設備，但數據傳輸未加密。CoAPS（CoAP Secure），在CoAP基礎上通過DTLS（Datagram Transport Layer Security）實現加密，端口通常為5684，提供端到端的數據安全保護。

與NCDP設置一樣，DTLS設置也會在進入深休眠或 AT+NRB 重啟后保存到 KV。不同的是，它不用重啟模組才能生效，而是立即生效。為了驗證DTLS設置的必要性，實驗過程如下，使用正確的CDP配置，但是不開啟DTLS，

//正確的CDP配置
AT+NCDP=124.70.30.197,5684
//不開啟DTLS /無法發送數據
AT+QSECSWT=0

在上述配置下，數據發送指令返回+CME ERROR: 4，即不開啟DTLS，在CoAPs協議下是不能發送數據的。因此，發送AT+QSECSWT=1，使能DTLS模式，是Coaps協議下通信的必選步驟。

設備在線狀態

設備的在線狀態，可能跟我們想象的不太一樣，此狀態不是實時的。

為了驗證下，云端設備是在什么情況下，或者說是在哪些必要操作后才變為在線狀態的，我無情的刪除-增加-刪除-增加我的云端設備，從測試結果我們可以看到，如下操作后，云端設備即變為在線，

//關閉射頻
AT+CFUN=0
//正確的PSK配置和設置
AT+QSETPSK=0,xxxx
//正確的CDP配置
AT+NCDP=124.70.30.197,5684
//開啟DTLS 
AT+QSECSWT=1
//重啟模組 /并等待大約10s
AT+NRB

而且后續測試過程還確定了，如果不在重啟模組時AT+QSECSWT=0，設備也不會從未就緒變為在線，這在此驗證了CoAPs下開啟DTLS操作的必要性。還要注意的是，與HCIP-IOT實驗手冊中描述的不一致，并不是在上報數據后，云端設備才會變為在線，而是完成與IoTDA的有效對接后即可。

已入網請使用

前邊 <設備在線狀態> 章節中的實驗過程已經表明，對于BC28系列模組，其會自動向iot平臺注冊。若注冊成功，就會看到兩條異步消息+QLWEVTIND:0和+QLWEVTIND:3，表明我們可以使用數據傳輸相關AT指令和平臺進行通訊啦，平臺設備也會變為在線。對于BC95，部分網絡資料顯示，可能確如實驗手冊中表述的那樣，要在執行 AT+NMGS 指令后，平臺設備才會在線，我沒有此模組，沒有進行實驗。

消息注冊狀態:AT+NMSTATUS

#指令
AT+NMSTATUS?
#響應
+NMSTATUS:MO_DATA_ENABLED

當模塊連接到 CDP 服務器時，該命令用于上報當前注冊狀態。當 LwM2M 處于 MO_DATA_ENABLED 狀態，則 UE 可以發送數據。

打開UE功能

發送AT+CFUN=1，打開UE功能，
也可以像HCIP-IOT實驗手冊中理解的那樣，對于本實驗而言，就是打開協議棧功能。在物聯網開發中，AT+CFUN=1是激活設備通信能力的“總開關”，其作用類似于操作系統的內核啟動。
CFUN未開啟的情況下，
發送數據，將返回 +CME ERROR: 4 錯誤碼。
AT+NMSTATUS? 消息注冊狀態將返回，+NMSTATUS:NO_UE_IP 異常。

@NOTE:
理論上 AT+CFUN=1 操作應該立即生效，但似乎=0設置是立即生效的，=1卻需要重啟才可以生效。

測試數據發送

AT+NMGS=5,00193C0064

實驗結果，

后續實驗

后續實驗過程，繼續參考 #< IoT/HCIP/基于NB-IoT模組的AT指令實驗（小熊派IoT+NB28-A模組）># 文章內容，不再贅述。

參考說明

< Quectel_BC28-CNV&BC95-CNV_AT命令手冊_V1.0 >
< Quectel_BC28-FBC95-GF_AT命令手冊_V2.2.pdf >

其他參考，不在逐個列舉了，可從CSDN資源中進行下載。部分資料可能在移遠通信的門戶上都下載不到，得找他們銷售再找到他們的技術支持才能獲取，這可能是一種變相營銷手段吧，沒怎么搞懂，怪麻煩的真是。點此下載。