窄頻物聯網(Narrow Band Internet of Thing, NB-IoT)為低功耗廣域網路(Low Power Wide Area Network, LPWAN)分類中，工作於執照頻段(Licensed Band)的技術，雖然起步較晚，但由於是3GPP組織所規範，且具有非常成熟的行動通訊網路生態系統，是NB-IoT的最大優勢。其相關標準已於2016年6月在3GPP Release 13中大致底定，本文將以此版本，介紹NB-IoT的主要核心網路技術，包括架構、傳輸方式，以及相關的呼叫流程(Call Flow)等。
NB-IoT核心網路依據物聯網的小數據封包、低功耗等特性，對移動管理實體(MME)、服務閘道(S-GW)，和封包數據網路閘道(P-GW)做了最佳化並整合在同一節點，稱之為行動物聯網服務閘道器(CIoT Serving Gateway Node, C-SGN)，如圖1。此最佳化後的架構，可輕易的實現在虛擬的核心網路架構上，以面對各式各樣的NB-IoT應用。
 |
| 圖1 最佳化CIoT架構(非漫遊架構) |
NB-IoT核心網路的最佳化包括了控制平面(Control Plane, C-plane)和用戶平面(User Plane, U-plane)，使得小數據封包亦可傳輸於C-plane上，如圖2中的路徑，其概念如同於大賣場中，若消費者只購買少量物品，除了一般的收銀台外，亦可經由特定的快速通道結帳。本文主要以C-plane的CIoT最佳化介紹NB-IoT核心網路的運作方式。
 |
| 圖2 NB-IoT數據封包傳輸路徑 |
若CIoT手機端(UE)選擇路徑傳送或接收資料時，則數據封包是傳輸在C-plane的非存取層(Non-Access Stratum, NAS)訊號(Signaling)中，CIoT UE也可指定欲使用數據封包網路閘道器(PDN)連接的IP類型，如IPv4，IPv6，或IPv4/6等。此外，數據封包也可以傳輸在既有用戶層(U-Plane)上，主要是依據CIoT UE在Attach程序或PDN連線請求中，說明要選擇C-plane或U-plane與應用伺服器(Application Server, AS)建立連線，端看「Preferred Network Behaviour」的指標中CIoT UE支援的類型，但對AS來說並不會知道核心網路是透過何種方式傳送與接收CIoT UE的數據封包。
另外一種於路徑上傳送或接收數據封包的傳輸模式為NIDD(Non-IP Data Delivery)，依照CIoT UE建立PDN連線時，PDN Type是否為「Non-IP」來決定，反之，若為IPv4，IPv6，或IPv4/6的話則為IP傳輸模式。NIDD傳輸模式在設定CIoT UE的APN(Access Point Name)時，必須與AS綁定，確認PDN連接是建立於此相關聯的APN之上，因此每個APN將對應到一特定的AS。由於已無IP地址傳輸數據封包，因此在P-GW上必須要有CIoT UE的ID與AS的IP地址與通訊埠號碼(Port Number)的對應關係，才能將數據封包正確傳送在SGi的界面上，這種方式稱為UDP/IP的點對點隧道(Point-to-Point (PtP) Tunneling)技術，而隧道的參數，也就是目的地IP地址與UDP通訊埠號碼需事先配置於P-GW上，而對CIoT UE和AS之間傳送的資料來說，P-GW是一個透明(Transparent)傳輸的節點。對於上行的Non-IP資料，P-GW對其進行UDP/IP的封裝並傳送至AS，對於下行的Non-IP資料，P-GW則會解除UDP/IP的封裝並傳送至CIoT UE。其他的點對點隧道技術尚有PMIPv6/GRE、L2TP和GTP-C/U等，皆規範於3GPP TS 23.401中。一般來說，使用Non-IP的傳輸模式將比IP的傳輸模式有更佳的安全性且省電，因為CIoT UE將不會曝露於IP網路中，也不需要額外的IP封裝過程。
在圖2中，路徑則會經過服務能力揭露功能(Service Capability Exposure Function, SCEF)節點，此路徑只支援NIDD傳輸模式。SCEF為NB-IoT新增加的節點，其透過應用程式介面(Application Programming Interface, API)向AS提供服務，而非直接發送資料，使得電信營運商不再成為純傳輸管道的功能，未來將能對物聯網的資料進行大數據分析以創造嶄新的商業價值。
SCEF架構如圖3，由於安全性的考量，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或與計費、安全相關之網路節點。
 |
| 圖3 SCEF架構 |
綜合以上三種傳輸模式，在此表列出優缺點的比較(表1)。
 |
| 表1 三種傳輸模式優缺點比較表 |
SCEF相關呼叫流程
若CIoT UE欲透過傳輸路徑傳送或接收小數據封包，則MME會啟動建立T6a界面的程序，如圖4：
 |
| 圖4 T6a連線建立程序 |
此外，SCEF也會藉由HSS對AS進行認證的程序，如圖5，以提高網路的安全性：
 |
| 圖5 經由SCEF的NIDD傳輸模式建立程序 |
支援CIoT UE資料速率控制
CIoT UE資料的速率可由兩種方式控制：Serving PLMN速率控制以及APN速率控制。
Serving PLMN Rate Control
Serving PLMN的速率控制主要是保護MME可正常傳送除了NB-IoT以外的控制訊息，尤其是當CIoT UE大量傳送或接收資料的時候。在PDN連線建立時，若傳輸路徑為圖2中的，則MME會傳送Serving PLMN速率控制(Rate Control)的命令給P-GW，若為路徑時，則將命令傳送給SCEF。
Serving PLMN Rate Control可由電信營運商自行設定於MME，其語法如：X NAS Data PDUs per deci hour，其中X應為一不小於10的整數，且上行與下行速率可分別限制。MME可能會強制丟棄或延後傳送NAS數據封包，因此CIoT UE或P-GW/SCEF應依照此速率限制傳送上行或下行的數據封包。
APN Rate Control
APN的速率控制是設定於P-GW或SCEF上，同樣上行與下行速率可分別限制，格式為單位時間內可傳送X個NAS數據封包，其中X為一正整數。CIoT UE需同意上行的速率限制，否則P-GW或SCEF可能會強制丟棄或延後傳送NAS數據封包。
其他核心網路增強功能
NB-IoT核心網路除了CIoT的最佳化與SCEF之外，3GPP Release 13對網路架構還做了以下特性的增強：
DECOR
針對特定的UE或使用者，如M2M裝置，電信營運商可在同一個PLMN(Public Land Mobile Network)建立多個DCN(Dedicated Core Networks)以提供特定的服務，而選擇哪一個DCN則是根據「UE Usage Type」的指標來判斷，此UE與某DCN中MME/SGSN的對應關係須事先於HSS中設定。一般來說，DCN會應用到無線存取網路(Radio Access Networks, RAN)共享(Sharing)的概念，如圖6，可將Core Network A看成一般LTE網路，而Core Network B為一NB-IoT的DCN。
 |
| 圖6 RAN Sharing基礎架構 |
若UE的資訊不足以選擇特定的DCN，則RAN側將選擇預設的DCN並透過重定向的機制把NAS訊息轉送至特定的DCN，此機制說明於圖7中，若預設DCN的MME發現此UE屬於其他特定的DCN，則傳送「Reroute NAS Message Request」給RAN節點並透過網路節點選擇功能(Network Node Selection Function, NNSF)，傳送「Initial UE Message/UL-Unitdata」給此特定DCN的MME。
 |
| 圖7 NAS訊息的重定向程序 |
HLCom
以C-plane的CIoT最佳化為例，若CIoT UE進入較長的省電模式以至於核心網路無法將SCS/AS傳送的Downlink(DL)資料傳送給CIoT UE，則這些DL的資料會儲存在S-GW，此種機制即稱為高延遲通訊(High Latency Communication, HLCom)，主要是因為當S-GW傳送「DDN(Downlink Data Notification)」給MME且MME回傳「DDN Failure」以告知S-GW需暫存DL的資料，其保留DL資料的時間會隨著CIoT UE離線的模式而有所不同。當CIoT UE於此保留時間內連上核心網路時，S-GW即將這些暫存的DL資料傳送給CIoT UE。
GROUPE
此特性可以用單一指令驅動一個群組中的多個CIoT UE，例如，若需要對某一特定群組的CIoT UE更改QoS以符合策略，則P-GW可以用一個控制訊息來修改與此群組相關聯所有CIoT UE的傳輸速率以減少傳送大量相同的控制訊息。
MONTE
在3GPP Release 13中，針對MTC(Machine Type Communication)裝置，監測(Monitoring)增強的特性可檢查網路狀況並回報事件，此時，核心網路可能會做相對應的處理，如限制對資料的存取，或減少分配的資源。在3GPP系統中的MTC裝置，可監測下列事件：
在3GPP TR 23.789中提出了四種解決方案，以下僅說明第一種解決方案：Monitoring via HSS，如圖8，SCS/AS可透過API傳送「Monitoring Request」給SCEF以訂閱欲監測的事件，SCEF再透過Sh界面傳送「Sh-Subs-Notif」給HSS。若此SCS/AS已經過HSS認證且接受此監測事件的請求，則會回覆「Sh-Subs-Notif Resp」給SCEF，SCEF再傳送「Monitoring Request Response」給SCS/AS以通知成功完成配置。
 |
| 圖8 透過HSS的監測架構模型 |
隨著3GPP持續修訂NB-IoT的標準，許多晶片供應商也都提出相關的解決方案，預料未來幾年內，NB-IoT相較於其他LPWAN的技術來說，在市場上將有大幅度的成長。您可以在http://www.taics.org.tw/ 獲取更多關於NB-IoT核心網路更詳細技術細節。
(本文由台灣資通產業標準協會提供；作者為工業技術研究院資訊與通訊研究所寬頻網路系統整合測試技術部工程師)