在上期的文章裏，我們一起了解了 OceanConnect 物聯網平臺的部分內容。後臺也收到了不少小夥伴的提問，主要聚焦關於 NB-IoT 終端如何進行擁塞控制，以及如何定位上。今天我們就來講：
&NB-IoT 上行離散控制
&NB-IoT 下行擁塞控制
&NB-IoT 位置服務
&支持 Non-IP
NB-IoT 上行離散控制
大量設備併發接入網絡，造成網絡擁塞甚至雪崩。NB-IoT 上行離散控制是一種通過平臺統一爲設備分配上線時間，讓設備可以錯峯接入的特性。
實現原理
IoT 平臺新增上行離散微服務，提供調度分配算法。設備接入數分佈的生成，需要用戶到OP Portal上打開「設備併發接入控制」開關，打開後OP Portal的KPI中會統計每分鐘小區接入設備數並呈現在界面上。
打開開關時需要設置「無線側保活時長」參數，IoT 平臺收到設備的消息（設備註冊/數據上報/命令響應）時，如果距離上一次收到設備發送的消息時間超過設置的無線保活時長，則記錄爲一次新的設備接入事件，IoT 平臺的接入數統計加1。
上行離散業務流程如下：
平臺持續統計小區每分鐘接入設備個數。
1、設備首次上線時，會攜帶CELLID字段。
2、IoT 平臺根據CELLID統計每個小區每分鐘的設備接入數
3、應用向平臺請求調度，請求設備可上線的時間段。
4、平臺根據前一天統計的接入數分佈，識別最空閒的時隙爲應用請求的設備分配可上線時間段。
5、平臺將設備可上線的時間段返回給應用。
說明：若應用請求調度的設備自身可存儲上線時間，那麼平臺在計算出空閒時隙後，會直接下發命令到設備，通知設備更新上線時間；若設備本身不具備存儲上線時間的能力，則平臺將空閒時隙僅返回給應用。
6、應用可根據實際情況選擇對設備下發命令的時間。
特性價值
在 NB-IoT 網絡中，通過上行離散控制技術，實現控制設備的上線時間，可提高設備的上線率。
應用場景
當有大量的NB-IoT 設備需要上線時，爲保證設備上線率，可以使用該特性，使設備可以錯峯接入，提高設備上線率。
約束與影響
當前平臺只在設備註冊時查詢設備的小區ID，如果設備移動導致小區ID 變化，則平臺無法獲取實時的小區ID，因此設備移動會導致小區接入統計的不準，進一步影響上行離散的效果。
NB-IoT下行擁塞控制
NB-IoT 下行擁塞控制是一種通過 IoT 平臺控制併發尋呼數的特性，保證從 IoT 平臺或應用下發到網絡側的消息數不超過網絡處理能力，從而實現網絡擁塞控制。
實現原理
NB-IoT基於信令面的數據傳輸組網結構如圖所示：
NB-IoT基站的空口尋呼能力資源有限，並隨基站信號的覆蓋等級不同而變化。爲保證重要業務預留資源，有限的空口尋呼資源不能被完全佔用，需要對尋呼併發數進行控制。即同一個小區內，同一時間通過TMSI（Temporary Mobile Subscriber Identity）或IMSI(International Mobile Subscriber Identity)來尋呼終端的消息數量不能超過小區的尋呼能力。
如表1所示，在eRAN12.1SPC220版本在覆蓋等級0時，每一秒中最多支持15個通過 IMSI號來尋呼終端。
當應用跟設備進行通信時，會對處於空閒狀態的設備發送尋呼請求，如圖所示的數據傳輸流程，尋呼主要作用於5~7步。
說明： 如果設備與 IoT 平臺之間在 20 秒內有消息收發，則判定設備處於連接狀態，否則爲空閒狀態。
網絡側發起的數據傳輸流程如下:
如果當尋呼請求個數大於空口尋呼資源時，網絡會發生擁塞，基於以下兩個方面原因會進一步加劇網絡擁塞：
&&&如果IoT 平臺或應用下行消息的速度大於基站尋呼併發能力，基站會緩存尋呼請求。但下行消息等不到及時響應後，平臺或應用又會重發下行消息，可能會加劇擁塞。
&&&MME與UE之間尋呼不成功時，MME會重新給基站下發尋呼指令，同時MME還會擴大尋呼範圍，向多個基站下發尋呼指令。與此同時基站無法識別同一個設備的多次尋呼請求，因此隨着請求數增加，也會加劇基站的擁塞。
NB-IoT 下行擁塞控制實現流程如下：
****網絡應用 NA 向設備發出下行消息。
****IoT 平臺檢查是否需要對下行消息進行流控。流控判斷標準參考約束與影響。
是=>參考 3
否=>轉發給 MME 處理，參考 4
****判斷當前下行消息數是否超過小區空口尋呼資源閾值。
是=>判斷消息類別，如果是立即下發類型消息，直接報錯不下發，如果是緩存下發類型消息，將消息寫入到消息等待隊列等待下發。
否=>直接下發消息，針對空閒狀態的設備，MME 下發尋呼請求。
****針對空閒狀態的設備，MME 下發尋呼請求。
特性價值
在 NB-IoT 網絡中，通過下行擁塞控制技術，實現控制併發消息數，防止因短時間大量的尋呼指令搶佔尋呼資源導致網絡擁塞或雪崩等問題，同時爲重要業務預留一定的空口尋呼資源。
應用場景
當基站的空口尋呼資源有限且需要爲重要業務預留資源或者網絡可能發生擁塞時，針對立即下發及緩存下發兩種請求，實施下行擁塞控制，減少從IoT 平臺或應用下發到網絡側的尋呼數，從而實現網絡擁塞控制目標。
&&&針對立即下發的下行消息，如果基站小區尋呼併發數超過小區閾值時，則直接拒絕該請求，減少下發的下行消息數量。
&&&針對緩存下發的下行消息，如果基站小區尋呼併發數超過小區閾值時，則排隊等待，延遲下行消息的下發時間。
約束與影響
除以下情況外，IoT 平臺都會對下行消息進行控制：
A設備處於 eDRX 模式
B設備處於連接狀態
C設備的所歸屬的 Cell ID 未查詢到
D未通過 Post command 接口下發下行消息
**
NB-IoT 位置服務
**
NB-IoT 位置服務是指通過配置 IoT 平臺對接 GMLC（Gateway Mobile Location Center），可以使物聯網平臺集成 GMLC 的定位能力，通過測量無線信號來確定 NB-IoT 設備地理位置信息及其移動速度等能力。
實現原理
IoT 在 GMLC 中的位置
UE 通過 LPP 協議將 ECID(Enhanced Cell ID) 測量信息上報到 E-SMLC，後者進行位置計算並通過 GMLC 開放給 IoT 平臺。平臺向 NA 提供位置服務開放，可以支持應用實時查詢設備位置、訂閱或取消訂閱設備的功能，以下是三種功能的交互流程。
下圖中 LCS 爲 Location Service ，代表 IoT 平臺。
位置的實時查詢流程：
位置的訂閱通知消息流程：
取消位置訂閱通知消息流程：
特性價值
通過物聯網平臺集成 GMLC 的定位能力，實現對 NB-IoT 設備的位置定位。
應用場景
當應用或者 IoT 平臺查詢設備位置信息時使用該功能。
約束與影響
當前 IoT 平臺只支持對接一個 GMLC，不支持對接多個 GMLC。
支持 Non-IP
Non-IP 是指終端在接入平臺的時候不依賴 IP 地址，而是通過運營商分配的 ExternalID（外部 ID）獲取到 DeviceID，並用 DeviceID 與IoT 平臺進行交互，這樣可以確保終端不暴露在 IP 網絡上，從而避免一切基於 IP 技術的攻擊和遠程控制。
實現原理
Non-IP 端到端業務流程：
***應用下發命令到 IoT 平臺。
***IoT 平臺根據設備當前狀態（ PSM、DRX、eDRX 模式策略不同）決定緩存數據還是立即下發。
***IoT平臺感知到設備上線後，創建 NIDD（Non-IP Data Delivery，Non-IP 數據傳輸）下行投遞，下發命令到 SCEF，指定立即下發模式。
***SCEF 投遞數據到設備，同時反饋投遞結果到 IoT平臺。
***IoT平臺收到投遞結果，嚮應用上報命令已經到達設備。
***設備處理數據，處理完畢後，如果有命令執行結果，則上報給 SCEF。
***SCEF 收到命令執行結果，上報 IoT平臺。
***IoT平臺回覆收到數據。
***IoT平臺收到數據後，業務匹配該數據是命令執行結果，通知應用此次命令執行結果。
APP 尋址設備，仍然通過 DeviceID，平臺收到 APP 的 DeviceID 後轉換成 ExternalID，加上自身的 scwAsId（該 ID 由 SCEF 分配，平臺部署時配置），下發給 SCEF，SCEF 通過核心網尋址設備。
***SP 用戶從設備製造商處購買設備。
***設備製造商提供設備給 SP 用戶，並提供設備 IMEI。
***運營商客戶在運營商開戶 （比如購買 NB-IoT 設備 SIM 卡）。
***HSS 分配 ExternalID，保存 <externalID、IMSI>關係，返回該關係給運營商客戶。(注：實際局點中，***看運營商業務模型，有可能一次返回 <ExternalID、IMSI>。也有可能分兩步，先開戶返回 IMSI 給運營商客戶，運營商客戶用 IMSI 申請業務，再返回 <ExternalID、IMSI>關係。)
***運營商客戶將 <ExternalID、IMSI>關係同步給 SP 用戶。
***SP 用戶通過IoT平臺北向接口開戶，錄入 <IMEI、ExternalID>信息。
***IoT平臺返回 DeviceID 給 SP 用戶，後續 SP 用戶通過該 DeviceID 訪問設備。
若 ExternalID變更，則運營商客戶通知運營商變更 <ExternalID、IMSI>的關係，HSS 更新 <ExternalID，IMSI>關係，並通知 SCEF 變更，SP 用戶通過IoT 北向接口更新 <DeviceID、ExternalID>關係。
設備註冊流程如圖所示：
***設備註冊前，平臺需要已完成 NIDD（Non-IP Data Delivery，Non-IP 數據傳輸）配置。
***設備註冊報文到達 CIG 後，CIG 完成 SCEF over HTTP 的協議棧解析後，回覆 SCEF（Service ***Capability Exposure Function）。
***CIG 繼續解析 coap over LWM2M 之後，上報設備註冊消息到 CM。
***CM 處理設備註冊消息。
***CIG 同時組幀設備註冊響應報文，發送給 SCEF（Service Capability Exposure Function）。
特性價值
使用該特性後，NB-IoT 設備無需獲取公網 IP 地址，節省了公網 IP 資源，同時避免了因爲終端被控制，導致 IoT平臺收到基於 IP 網絡的 DDoS 攻擊。
應用場景
適用於 NB-IoT 設備使用的各種場景，防止終端數據在傳輸過程中被攻擊。
影響與限制
僅限於 NB-IoT設備使用該特性。