NB-IoT核心網

大家都知道的，儘管LTE和NB-IoT一脈同氣，但LTE的設計目標是高速率、大流量，而NB-IoT為物聯網「間歇傳送小數據」而生，兩者方向相反。因此，LTE核心網EPS也不再適應NB-IoT應用，需要對其進行優化。

為了提升NB-IoT系統的小數據的傳輸效率，3GPP SA2工作組於2015年7月開始研究CIoT EPS優化構架，提出了CIoT EPS需支持四大功能：

支持超低功耗物聯網終端

支持每小區連接大量物聯網設備

支持窄帶頻譜無線接入技術

支持物聯網增強覆蓋

並進行功能簡化，裁剪了LTE EPS的四項功能：

不提供緊急呼叫服務

不支持流量卸載，如本地lP接入(LIPA)和選擇性IP流量卸載

在EPS連接管理上，只支持IDLE模式下的重選，不支持CONNECTED模式下的切換

不支持建立GBR承載和專用承載

最終，3GPP提出了兩種優化方案：控制面優化傳輸方案（ C-Plane CIoT EPS optimization）和用戶面優化傳輸方案（U-Plane CIoT EPS optimization）。對於物聯網終端，必須支持「控制面優化傳輸方案」，可選支持「用戶面優化傳輸方案」。

控制面優化傳輸方案

控制面優化傳輸方案使得小數據包可以傳輸於控制面上，數據以非接入層協議數據單元（NAS PDU）的格式封裝於控制面信令消息來傳輸，其概念如同商場購物，若消費者只購買少量商品，可經由指定的快速通道結賬。

這一方案可在傳輸數據時減少了控制面信令開銷，因此有助於降低終端功耗和減少使用頻帶。

如上圖所示，控制面優化傳輸方案支持IP數據和非IP數據傳輸，傳輸路徑可分為兩條：通過S-GW傳送到P-GW再傳送到應用伺服器（CIoT Services）；通過SCEF（Service Capability Exposure Function）連接到應用伺服器，該路徑僅支持非IP數據傳輸。

根據傳輸路徑和是否支持IP數據傳輸，可分為三種傳輸模式：

傳輸路徑（IP數據傳輸）

傳輸路徑為S-GW到P-GW再到應用伺服器，可沿用現有的IP通信技術快速部署NB-IoT，缺點是安全性低，且不經過SCEF，電信運營商仍為管道角色。

傳輸路徑（非IP數據傳輸）

傳輸路徑仍為S-GW到P-GW再到應用伺服器，但由於已無IP地址傳輸數據包，因此在P-GW上必須要有NB-IoT終端的ID與AS的IP地址+埠號的對應關係，才能將數據包正確傳送在SGi的界面上，這種方式稱為UDP/IP的點對點隧道(Point-to-Point (PtP) Tunneling)技術。隧道的參數，也就是目的地IP地址與UDP埠號需事先配置於P-GW上，對NB-IoT終端和AS之間傳送的數據來說，P-GW是一個透明的傳輸節點。

這種方式安全性高且省電，但需要開發新的點對點隧道技術。

傳輸路徑（非IP數據傳輸）

即通過SCEF傳遞Non-IP數據，這條路徑僅支持非IP數據傳輸，屬於Non-IP專屬解決方案。這種方式優點較多，安全性高、省電，且運營商能創造新的商業價值，但需新建SCEF網元節點，需開發新的API技術。

SCEF

SCEF為NB-IoT新增加的節點，其通過API介面向AS提供服務，而非直接發送數據，使得電信營運商不再只是管道，而是可以將業務能力安全地開放給第三方業務供應商，實現對物聯網的大數據分析以創造新的商業價值。

SCEF構架如上圖所示，鑒於安全性考慮，SCEF放置於運營商信任的網域中(Trust Domain)，並通過OMA(Open Mobile Alliance)，GSMA(Groupe Speciale Mobile Association)，或其他標準組織(Standardisation Bodies, SDOs)的API接入服務，同時，SCEF的API支持多種不同類型，如DIAMETER、RESTful APIs與XML over HTTP等，使得SCEF可以更靈活應用於不同的網路中。Network Entity則指HSS、MME、P-GW、PCRF或與計費、安全相關的網路節點。

C-SGN

C-SGN，即CIoT Serving Gateway Node，是控制面優化傳輸方案引入的新節點，該節點是由LTE EPS的控制面節點MME、用戶面節點S-GW和P-GW的最小化功能合併而成的單個邏輯實體，C-SGN功能也可以部署在現網EPS的MME中。

HLCom

在控制面優化傳輸方案中，可引入了HLCom機制，即Optimization to support High Latency Communication，該機制將下行數據緩存在S-GW中。由於NB-IoT終端通過PSM和eDRX等技術來間歇性接收數據，以達到省電的目的，當NB-IoT終端在休眠狀態時，S-GW將下行數據緩存，直到終端被喚醒後才將這些緩存的數據下發給終端。

用戶面優化傳輸方案

數據傳輸的方式與LTE EPS一樣採用用戶面承載，但是，該優化方案在RRC層引入了掛起（Suspend）和恢復（Resume）兩種新狀態以適應物聯網數據的間歇傳輸特性，同時要求NB-IoT終端、eNB和MME存儲連接信息，以快速恢復重建連接，簡化信令流程，提升傳輸效率。

經過這麼一優化，承載可以按需的方式建立，因而可降低終端功耗和支持單小區大規模物聯網設備連接。該方案除了支持現有EPS功能外，還可以支持通過P-GW傳輸非IP數據。

RRC Suspend流程

如上圖所示，該過程由eNB激活，釋放NB-IoT終端與eNB之間的RRC連接，以及eNB與S-GW之間的S1-U承載。

步驟（1）和（2）：

eNB發送UE Context Suspend Request，並通過MME向S-GW發起釋放與NB-IoT終端相關的承載信息。

步驟（3）：

S-GW釋放eNB與NB-IoT終端相關的S1-U承載。具體而言，S-GW僅釋放eNB地址和下行隧道端點標識符（TEID），並繼續存儲其他信息。

步驟（4）和（5）：

在S-GW處完成S1-U承載釋放後，eNB通過MME接收UE Context Suspend Response通知。

步驟（6）和（7）：

eNB存儲NB-IoT終端的Access Stratum (AS)信息、S1-AP連接信息和承載信息，並向NB-IoT終端發送RRC Connection Suspend消息。

步驟（8）：

MME為NB-IoT終端存儲S1-AP連接信息和承載信息，並進入IDLE狀態。

步驟（9）：

當接收到來自eNB的RRC Connection Suspend消息後，NB-IoT終端存儲AS信息，並IDLE狀態。

RRC Resume流程

如上圖所示，該過程重新建立（恢復）處於Suspend狀態的NB-IoT UE與eNB之間的RRC連接，以及eNB與S-GW之間的釋放的S1-U承載。Resume過程由NB-IoT啟動和激活。

步驟（1）和（2）：

首先使用由RRC Suspend過程中存儲的AS信息來恢復與網路的連接。

步驟（3）：

此時，eNB對NB-IoT終端執行安全檢查，並向NB-IoT終端提供恢復的無線承載列表，且同步NB-IoT UE和eNB之間的EPS承載狀態。

步驟（4）：

eNB向MME發送UE Context Resume Request，以通知其與NB-IoT終端的連接已經安全地恢復。

步驟（5）和（6）：

從eNB接收到該恢復通知後，MME恢復NB-IoT終端的S1-AP連接信息和承載信息，進入CONNECTED狀態，並向eNB發送UE Context Resume Response消息（包括S-GW地址和S1-AP連接信息）。

步驟（7）：

現在NB-IoT終端可以向S-GW發送上行數據。

步驟（8 ）和（9）：

MME通過Modify Bearer Request消息向S-GW發送eNB地址和下行鏈路TEID，以重建NB-IoT終端與S-GW之間的下行鏈路的S1-U承載。

步驟（10）和（11）：

S-GW向MME發送Modify Bearer Response消息，然後開始傳輸下行數據。

值得一提的是，當S-GW接收到下行數據的同時NB-IoT終端處於Suspend狀態，此時，S-GW將緩存數據包，同時在S-GW和MME之間初始化Downlink Data Notification過程，然後MME尋呼NB-IoT終端，由此通過NB-IoT終端啟動激活連接Resume流程。

通信路上，一起走！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！