深扒 NB-IoT（2）| NB-IoT 协议栈剖析

这一讲主要给大家详细讲解下 NB-IoT 的协议栈，在讲协议栈之前先来了解下 NB 特有的数据传输方案，因为协议栈的有些知识点都是围绕 CP 和 UP 来讲解的。

一、数据传输方案

CIoT EPS 优化的目的，是为了提升 NB-IoT 对小数据以及 SMS 的支持。CIoT EPS 优化的内容包括控制面 CIoT 优化、用户面 CIoT 优化、无 PDN 连接的 EMM 注册、S1-U 接口的数据传输以及头压缩等。

1）CP 方案

无需建立空口数据无线承载（DRB）和 S1-U 连接，直接通过 NAS 消息传输数据，支持 IP 数据和非 IP 数据的传输。核心网新增网元 SCEF（Service Capability Exposure Function），用来支撑非 IP 数据随信令的传输。

3 GPP 已明确 CP 方案为必选方案 。

上行数据从基站发送到 MME 之后，有两条路径可选：一是发往 SGW 后再发往 PGW；二是发往 SCEF，再直接发给服务器。使用控制面的 CIoT 优化可以不再建立 DRB，但是只适用于低频率且低速率的数据业务传输。

使用控制面传输数据，主要是通过 RRC 信令中的 NAS 专有消息 dedicatedInfoNAS-r13 来携带用户数据。

从上图可以看出，如果是小于 100 字节的小包，终端只需要发 RRC Conn Setup Complete 一条携带 NAS 消息的信令就可以完成数据上报，可以极大简化终端的设计，降低信令开销和降低功耗。

2） UP 方案

增加 RRC-Suspended 状态，前一次传输数据的用户面连接被挂起，下次传输可恢复挂起的用户面连接，无需新建用户面连接。（用户面的 CIoT 优化，主要目的是简化从 RRC 空闲态到连接态变化的过程）

在支持用户面 CIoT EPS 优化时，RRC 连接释放消息中会携带 ResumeIdentity-r13 信元，用来给 UE 分配 Resume ID：

在 UE 执行 RRC 恢复时，需要携带该 Resume ID 给基站，重新激活保存的上下文：

与 CP 方案相比，UE 和基站需要保存用户面连接相关上下文。 

3 GPP 已明确 UP 方案为可选方案。 

上图是 3 个 RRC 状态的关系，下图从 RRC Connect 到 RRC Suspended 状态转换的信令流程，需要注意的是 RRC Connection Release 这条信令里面会携带释放原因 Suspend。

Suspend 流程的预置条件：NB-IoT UE 附着到 MME 并建立 UP 承载，处于 ECM-Connected 状态，至少建立了 1 个 DRB。

触发：eNodeB 检测到 Nbinactivitytimer 超时，发送 RRC connection release（suspended 指示）。

UE 动作：保存 UE AS 上下文，包括 RRC/PDCP/RLC/MAC 协议层配置、安全上下文、ROHC 状态、CRNTI 和当前小区的 PCI；

保存 resume identity，用于 RRC 连接恢复; 挂起所有的 SRB 和 DRB。

二、NB-IOT 协议栈介绍（主要对比 LTE 来看）

1）RRC 功能

从 RRC 的功能跟看，相比 LTE

没有变化的功能有：1）PLMN 及小区选择，2）准入控制，3）NAS 消息转发

取消的功能有：1）测量报告，2）切换及移动性管理

有变化的功能有 [括号内是变化的内容]：

1）系统消息广播 [系统消息块及内容差异]

2）小区重选 [不支持异系统重选，不支持基于 RSRQ 重选，不支持基于优先级重选]

3）无线资源管理 [支持 SRB1bis (CP-opt), 支持最多 2 个 DRB（UP-opt）, 支持 RRC suspend-resume 流程（UP-opt）]

4）寻呼/通知 [支持寻呼扩展流程，不支持 ETWS/CMAS]

NB/LTE RRC 层差异综合来看：

空闲态：

可以发起 RRC 连接恢复过程（仅 UP 模式)

终端/基站保持接入层的上下文（仅 UP 模式)

连接态:  

不支持网络控制的移动性（测量报告、切换）

不监听寻呼和系统消息

不支持 RRC 连接重建和重配置（仅 CP 模式）

无线承载管理：

信令无线承载：引入 SRB1bis；不支持 SRB2

数据无线承载：CP 模式不支持 DRB, UP 模式最多支持 2 个 DRB

2）PDCP 功能

这里就需要进行区分：

CP 模式整个 PDCP 层的功能全部砍掉；

UP 模式 PDCP 层的功能与 LTE 基本一致；

3） RLC 功能

没有变化的功能有：1）TM（透传模式），2）AM（确认模式），3）分段和重组，4）级联，5）纠错，6）重复检测

取消的功能有：UM（非确认模式）

有变化的功能有：UP 模式 RLC 重建，CP 模式没有 RLC 重建

可以看出 RLC 这次相对于 LTE 变化不是那么大

4） MAC 功能

没有变化的功能有：复用解复用

有变化的功能有:

1) 信道映射, 上下行信道简化

2) HARQ: 单 HARQ 进程，只支持异步自适应重传

3) 调度: 调度周期和资源，MCS 和 TBS，覆盖等级和重复次数

4) DRX: 只支持长周期 DRX, 空闲态和连接态 eDRX,

5) 随机接入：NPRACH 资源，覆盖等级

三、协议栈接口

1）S1 协议栈接口

• NB-IoT 与 LTE 可以共用同一个 S1 接口，连接到同一个 MME；也可以通过不同的 S1 接口，连接到不同的 MME

• 在配置 S1 接口时，需要配置对应 MME 支持 NB-IoT 的能力

根据 23.401 协议描述，MME 支持以下类型：

协议认可使用以下两种方式选择 MME：

• MME 重定向（DECOR）功能：如果 MME 不支持 NB，或者支持的类型不对，MME 会把消息返还给 eNB 并提供重新路由。

• eNB 配置 MME 能力：eNB 上配置哪些 MME 支持 NB，以及支持的类型。

2）X2 协议栈接口

• NB-IoT 和 LTE 可以共用 X2 接口。

• NB-IoT 不支持基于 X2 接口的切换，但是通过 X2 接口可以实现，支持基站间 RRC Connection Resume 流程；

3）支持 Non-IP data 传输

物联网场景之下，终端大多数都是 100 字节内小包为主，如果继续使用 IP 包的方式，IP 包头的开销会很大，例如：传输层是 UDP 就是 28 字节的话，28/100，光 IP 包头的开销就有 28%。

于是引入了 Non-IP 数据传输（Non-IP Data Delivery）, 即在数据传输的时候剥离掉 IP 层的封装，可以减小数据包的 payload，非常适用于物联网使用。

协议定义两种传输机制，建议使用单独 APN 支持 Non-IP 传输。

如果使用 Non-IP 传输，则需要在核心网新增网元 SCEF，MME 在终端接入的时候就可以从 HSS 获取过来的开户数据判断是否 Non-IP 的包，如果是 则走 SCEF，如果是普通的终端就接入 SGW。

好啦，本期就先介绍到这里，下一期会详细介绍 NB-IoT 物理层。感兴趣的童鞋们不要错过哦~