三安服務熱線：400-0330-211
華為提供NB-IoT端到端解決方案的支持，提供多種開放能力供合作伙伴快速集成應用。提供海思的NB-IoT芯片，基站網絡和Ocean Connect連接管理平臺。開發者可以根據芯片/模組開發手冊進行終端的開發，基于IoT平臺進行APP Server開發。 ● Device：NB-IoT終端（如智能水表、智能氣表等）通過空口連接到eNodeB。 ● eNodeB：主要承擔空口接入處理和小區管理等相關功能，通過S1-lite接口與IoT核心網進行連接，將非接入層數據轉發給高層網元處理。 ● IoT Core：承擔與終端非接入層交互的功能，將IoT業務相關數據轉發到IoT平臺進行處理。 ● IoT Platform：IoT聯接管理平臺匯聚從各種接入網得到的IoT數據，根據不同類型轉發給相應的業務應用進行處理。 ● APP Server：是IoT數據的最終匯聚點，根據客戶的需求進行數據處理等操作。
| 步驟 | 執行 |
|---|---|
| step1 | 模組上電，初始化USIM卡 |
| step2 | 搜索小區信號 |
| step3 | 附著到NB網絡，進入connect狀態 |
| step4 | 激活PDN,獲得IP地址，建立PDN承載 |
| step5 | 建立用戶數據鏈接，收發用戶數據 |
| step6 | 一段時間無數據交互后，依次進入Drx(Idle)、PSM狀態 |
| step7 | 等待上發用戶數據，或TAU（跟蹤區域更新）再進入connect狀態 |
在模組進入PSM狀態后IP地址會保留，若PSM狀態時模組請求發送數據，模組會轉化為connect狀態，但模組不會重新獲取IP，還是以之前的IP發送數據。即：模組上電成功獲取IP后，任何時刻查詢其IP地址都是同樣的IP值。
- 以下為NB模組（利爾達和移遠都可以）測試步驟，方框內為發送相應指令后，NB模組返回的數據；
第一步：開機/重啟，模塊已經正常啟動！
REBOOTING REBOOT_CAUSE_APPLICATION_AT Neul OK
第二步：AT+NBAND? 查看當前頻段信息，確定是否和模塊型號對應，默認移動/聯通 8，電信模塊需要將NBAND設置為5，之后重啟模塊
第三步：AT+NBAND=5 電信模塊，設置頻段為850MHZ
第四步：AT+NRB 重啟模塊
REBOOTING REBOOT_CAUSE_APPLICATION_AT Neul OK
第五步：AT+NBAND? 再次查詢模塊頻段信息，確認設置成功
+NBAND:5 OK
第六步：AT+NCONFIG? 查詢配置信息，主要包括自動連接使能配置信息，默認使能
+NCONFIG:AUTOCONNECT,TRUE // 自動連接網絡 +NCONFIG:CR_0354_0338_SCRAMBLING,TRUE 開啟了擾碼功能 +NCONFIG:CR_0859_SI_AVOID,TRUE +NCONFIG:COMBINE_ATTACH,FALSE +NCONFIG:CELL_RESELECTION,FALSE +NCONFIG:ENABLE_BIP,FALSE OK
第七步：AT+CFUN? 模塊是否處于全工作模式，打開射頻電路，搜索信號，如果返回0，請確定AUTOCONNECT值是否為TRUE，以及是否安裝NBIOT專用SIM卡
+CFUN:1 OK
第八步：AT+CIMI 查詢IMSI信息，如果返回具體數值，說明已經正常識別SIM卡
460111176314533 OK
第九步：AT+CSQ 查詢信號強度，返回的第一個數值代表信號強度，0-31代表有信號，數值越大信號越強，99代表沒有NBIOT網絡信號，第二個參數還沒有實施，一直為99
+CSQ:21,99 OK
第十步：AT+NUESTATS 查詢模塊狀態
Signal power:-842 Total power:-718 TX power:-32768 TX time:0 RX time:2472 Cell ID:79044177 ECL:255 SNR:-16 EARFCN:2506 PCI:3 RSRQ:-148 OK
第十一步：AT+CGATT? 查詢是否模塊附著成功，返回1代表成功；網絡分為測試網絡和商用網，SIM也分為測試卡和商用卡，確保一一對應才能附著成功，具體網絡信息和SIM卡信息可跟運營商確認
+CGATT:1 OK
第十二步：AT+CEREG? 查詢網絡注冊狀態，第二個數值返回1代表：網絡注冊成功，返回2代表：正在注冊網絡，注冊時間和信號強度有關
+CEREG:0,1 OK
第十三步：AT+CSCON? 查看模塊工作的連接狀態，第二個返回數值代表模塊的工作狀態，1代表CONNECT連接狀態，0代表IDLE睡眠狀態，如果沒有數據交互，在CONNECT狀態持續20秒，之后進入IDLE狀態；如果仍然沒有數據交互，10秒之后從IDLE狀態進入PSM深度睡眠狀態，此時模塊不在接收任何下行數據，如果需要下行傳輸數據必須在CONNECT 和 IDLE狀態下進行
+CSCON:0,0 OK
第十四步：AT+NSOCR=DGRAM,17,5683,1 創建UDP SOCKET 傳輸信道，DGRAM和17固定，5683代表本地端口號，1代表使能接收下行數據；最多可創建7個SOCKET傳輸信道，返回數值代表信號ID號，在發送和接收數據時需要指定
0 OK
第十五步：AT+NSOST=0,...,####,3,303132 發送UDP數據，0代表UDP SOCKET信道ID，...代表遠程服務器的IP地址（公網IP地址），####代表遠程服務器端口號，3代表發送的字符個數（發送了3個字符），303132代表“012”3個hex表示的字符；返回值代表成功從0信道發送了3個字節的數據（我這里測試發送了74個字節）
AT+NSOST=0,54.223.248.94,9502,74,FFAAD0D00000490F3836353335323033303030313031390000041F0000000000000000026B44F8FCF700F1000000020018020A6C002600004D380000000000000000000200000644628E 0,74 OK
1.如果遠程服務端接收模塊發送的數據，必須在30s = ( CONNECT狀態20s + IDLE狀態10s ) 之內發送下行數據，否則在沒有數據交互的情況下模塊會進入PSM深度睡眠狀態，將 無法再接收到任何下行數據，但是此時模塊仍然可以再次發送數據； 2.模塊可以在CONNECT + IDLE + PSM任何狀態下發送數據，只能CONNECT + IDLE 狀態下 接接收數據； 3.只需要執行一次AT+NSOCR命令創建UDP SOCKET信道，之后任何模式下直接執行 AT+NSOST發送數據
第十六步：+NSONMI:0,67 信息代表模塊接收到新的數據，需要讀取，如果不及時讀取，接收到下一條數據，將不會主動上報該信息；但可以連續讀??；0代表 UDP SOKECT信道，67代表有67個字節數據需要讀取。
+NSONMI:0,67
第十七步：AT+NSORF=0,3 讀取數據；0代表UDP SOCKET 信道，3代表需要讀取數據字節長度；需要從返回值中提取出有效數據303132，代表字符“012”
0,54.223.248.94,9502,67,FFAAD1D10000430F3836353335323033303030313031390000015E8569078F03C000000002000801C1000000030012000000140000003C000003C20000000400080198,0 OK
1．+NSONMI主動上報信息說明，如果模塊接收到多包數據，但是沒有使用AT+NSORF 命令讀取數據，那么只會在第一次接收到數據時上報 +NSONMI 信息，此后不在主動上報，直到執行 AT+NSORF 讀取數據之后才會上報。
第十八步：AT+NSOCL=0 關閉UDP SOCKET 傳輸信道
OK
- 南向設備：開發者自行開發的終端硬件設備（包含多個傳感器和MCU）。
- 北向應用：開發者自行開發的服務端應用（基于華為OceanConnect物聯網平臺提供的RESTful接口）。
- NB-IoT：窄帶物聯網，華為等公司主推的物聯網通訊用蜂巢網絡。
- NB芯片/模組：類似于3G/4G通信模組，將設備端數據打包發送到指定平臺的硬件模塊。
- SoftRadio：用于模擬NB模組、基站、核心網的PC端軟件，可用于在缺乏NB模組和NB實網環境時的設備對接調試。
- OceanConnect：華為物聯網全聯接平臺，南向設備和北向應用通過該平臺交換數據和信令。
- 設備Profile文件：描述設備“是什么”、“能干什么”的json格式文件，上傳到OceanConnect平臺（上傳時是zip包格式），設備綁定平臺和提供服務的關鍵配置文件。
- 編解碼插件：用來對NB設備上報的數據進行解碼，同時對下發給NB設備的信令進行編碼的插件，對接前需上傳到OceanConnect平臺。
概念：信令下發是另一個物聯網的基本業務。應用服務器通過物聯網平臺，發送信令到南向設備，而設備也將做出一些對應的響應。
流程： 1. 應用創建信令(命令的相關項需要和設備Profile中的描述一致)，發送到平臺； 2. 如果平臺判斷設備在線，則立即下發信令；如果平臺判斷設備離線，則 信令將緩存于平臺的數據庫中； 3. 南向設備在某時刻上報數據，平臺收到數據后，將檢索對應設備在數據庫中是否存在有效未下發的信令，如有，則下發該信令； 4. 信令通過編解碼插件進行編碼（json到16進制碼流），并被發送到設備端； 5. 設備收到信令，執行完畢，返回信令執行結果； 6. 平臺收到上述執行結果，通過編解碼插件的解析，獲取信令執行的結果，修改對應的信令狀態。
概念：信令下發是另一個物聯網的基本業務。應用服務器通過物聯網平臺，發送信令到南向設備，而設備也將做出一些對應的響應。
流程： 1. 應用創建信令(命令的相關項需要和設備Profile中的描述一致)，發送到平臺； 2. 如果平臺判斷設備在線，則立即下發信令；如果平臺判斷設備離線，則信令將緩存于平臺的數據庫中； 3. 南向設備在某時刻上報數據，平臺收到數據后，將檢索對應設備在數據庫中是否存在有效未下發的信令，如有，則下發該信令； 4. 信令通過編解碼插件進行編碼（json到16進制碼流），并被發送到設備端； 5. 設備收到信令，執行完畢，返回信令執行結果； 6. 平臺收到上述執行結果，通過編解碼插件的解析，獲取信令執行的結果，修改對應的信令狀態。
