什么是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流程。