1.1.1 NB-IoT接入网主要协议流程

在了解 NB-IoT 相关技术原理之前，有必要对一些术语概念进行澄清。蜂窝物联网技术（CIoT）是一个总体的范畴，当然还有Sidelink这样的物物数据传输技术，严格来说也属于蜂窝物联网的范畴。总体上，CIoT细分为窄带物联网（NB-IoT）和非NB-IoT两个领域（非NB-IoT包括带宽受限UE或者覆盖增强UE等eMTC物联网技术），NB-IoT技术相对比较独立，承接了某些GSM标准化组织早期的研究基因，但更多地受到LTE标准设计的影响。从接入网来看，NB-IoT 等终端的工作状态与 LTE 一样分为两种：RRC_IDLE（空闲态）和RRC-CONNETED（连接态），但也有一些细节上的不同，例如NB-IoT没有互操作的属性，这意味着 NB-IoT的终端无法切换、重定向以及 CCO（Cell Change Order）到2/3/4G网络，NB-IoT终端只具备E-UTRA状态（只有一种工作模式，这里E-UTRA不等同于LTE的E-UTRA）；NB-IoT终端在连接态下不读系统消息，而4G终端在连接态下可以获取系统消息；NB-IoT终端在连接态不提供任何信道反馈，即没有信道状态信息（Channel State Information，CSI）上报，NB-IoT也没有了切换机制，同时也不提供测量报告（Measurement Reporting，MR）；另外在NB-IoT里关于上行速率调度机制也不具备，相比较而言，MTC 终端由于其源自 LTE，因此这些基本的机制还和 LTE 大网技术保持一致，但也有一些细微的区别，我们在后续章节中会提及。

系统消息和系统帧号获取

在 LTE 系统中，UE 要想进行小区驻留，获取系统消息，首先需要获取主信息块（Master Information Block，MIB），为了保证MIB的正确解读，LTE系统以40ms为一周期，每个周期之内重复发送4次MIB从而提高MIB获取的可靠性。而相比之下，NB-IoT 更加保守，以 640ms 为一周期，每个周期内分 8次传送完 MIB-NB，每次传输 MIB-NB的一部分。那么每次传输的部分有多大？按以下方式计算：BCH 传输块 34bit，加上 CRC 奇偶校验 16bit，再加上进行速率匹配传递到物理层窄带物理广播信道（Narrowband Physical Broadcast Channel，NPBCH）的符号，一共 1600bit，因为是分 8 次传完，所以在 80ms子周期内每次传输200bit，重复8次进行传输，在每个无线帧的0号子帧中发送，在下一个 80ms 子周期中传输下一个 NPBCH的 200bit 符号，依次延续直到传输完1600bit，即传输完MIB-NB。由于NB-IoT技术对时延不敏感，这种设计举措进一步提升了MIB-NB获取和解码的可靠性，不过某些芯片设计就不可能像LTE那样在系统消息侦听过程中进行一些解码时延优化，例如10ms内解读完第一个PBCH就可以获取MIB消息，而在之后的30ms不去进行重复侦听。NB-IoT芯片需要完完整整侦听完640ms才能确定MIB-NB的消息实体，这也注定导致NB-IoT的芯片在开机驻留的时间会比较长。

LTE系统中以80ms为周期发送系统消息块（System Information Block，SIB）SIB1消息，每个周期之内重复发送4次SIB1消息，起始位置在系统帧号（System Frame Number，SFN）SFN mod8=0（即无线帧0, 8, 16, 24, …）的5号子帧中发送。NB-IoT里面的SystemInformationBlockType1-NB (SIB1-NB） 以2560ms为周期进行发送，SIB1-NB以 16个连续的无线帧作为基本发送单位，在4号子帧上固定发送。

在一个2560ms周期内按照相同时间间隔重复发送，重复次数可分别为4、8、16。SIB1-NB的传输块大小以及 2560ms 内的循环次数在 MIB-NB 中的schedulingInfoSIB指明，如图1-1所示。

schedulingInfoSIB 中取值为 0～15，通过该值可以分别确定承载 SIB1-NB的 NPDSCH 重复次数（见表 1-1），以及 NPDSCH中承载 SIB1-NB的传输块（Transport Block Size，TBS）大小（见表1-2）， I _TBS 为schedulingInfoSIB中的取值。

根据获取的SIB1-NB在2560ms周期内的重复次数以及小区PCID就可以得知SIB1-NB的起始帧位置，见表1-3。

UE 通过解读 SIB1-NB 获取到两个重要信息：一个是调度消息接收窗长（Scheduling Information Window，SI-Window），如图 1-2 所示；另外一个是schedulingInfoList（调度信息清单）。SIB1-NB中schedulingInfoList包含的信息要比LTE SIB1中的schedulingInfoList（见图1-3）所包含的信息丰富得多，其不仅包含了时频资源信息，同时也包含了传输块信息，如图1-4所示。

SI-WindowLength 由基站可配，对于所有的 SI 消息都是一致的。配置 SI消息的原则如下：SI以周期窗的方式进行下发，每一个SI消息对应一个SI窗（一个SI消息可以跨越占用多个SI窗），不同SI消息的窗不互相交叠，这意味着UE需要依序串行解码SI消息。为了获取SI系统消息，UE首先需要确定SI窗的起始位置

(H-SFN*1024+SFN） mod T =FLOOR( x /10）+Offset

式中， x =( n -1）* w ， n 为 SI 系统消息在 SI 消息列表中的序号，例如 SIB2-NB序号为1， w 为SI窗长； T =si-Periodicity；Offset=si-RadioFrameOffset。

SI 窗起始于满足以上计算无线帧的系统帧号 SFN的 0 号子帧。接下来在SI接收窗内，UE通过si-RepetitionPattern获知SI窗内每次重复传输SI消息的起始无线帧，并通过downlinkBitmap明确可用子帧（SIB1-NB中可选配置，从左至右比特为 1 表示对应 0～9 下行子帧可用）或者该无线帧中除了 NPSS/NSSS/NPBCH/SIB1-NB的子帧作为起始子帧，并根据传输块（TBS）的大小，决定2个子帧连续传输或者是8个子帧连续传输（120bit以下采取2个连续子帧传输，120bit以上采取8个连续子帧传输），如果承载SI消息的连续子帧无法满足在一个无线帧内，则顺延至下一个无线帧。SI消息采取窗内重复、窗外循环的方式进行传输。

LTE中SIB1系统消息在时域是按照固定调度方式传输的，UE通过SI-RNTI获取相应的频域位置，而其他SI系统消息则是动态调度的，在SI接收窗内时域、频域（在频域上可以重复传输多次 SI 消息）和 TBS 都是可以配置的，因此需要通过SI-RNTI动态解码PDCCH获取详细的时频资源配置和TBS格式。而NB-IoT中SIB1-NB以及SI-NB的时频域资源和TBS都是根据高层消息固定调度配置的，SI-RNTI在这里仅仅作为摆设，没有实际的作用。

值得一提的是，UE如何获取H-SFN和SFN？UE可以通过解码MIB-NB的低位2bit，结合解码成功SIB1-NB的高位8bit确定超帧号（H-SFN）。另外，SFN通过解码MIB-NB获取SFN高位4bit，并结合解码640ms的NPBCH隐式获取低位6bit，这样就可以确定具体的无线帧号（SFN），如图1-5和图1-6所示。

NB-IoT网络侧除了MIB-NB的系统消息改变可以通过两种方式通知终端。一种是Paging寻呼的方式，UE通过侦听寻呼消息的方式确认系统消息是否发生了改变，原理流程如图1-7所示。如果NB-IoT系统消息发生了改变，会在modification period（变更周期，定义见图1-8）下发携带systemInfoModification字段的寻呼消息，在接下来的modification period中改变系统消息。UE需要在每个变更周期中尝试侦听modificationPeriodCoeff次寻呼中是否携带systemInfo Modification，如果都没有，则说明在这个变更周期内系统消息未发生改变。

如果该 UE 在 RRC_IDLE 状态时配置的非连续接收（Discontinuous Reception，DRX）周期长于系统消息变更周期，并且寻呼消息中携带了systemInfoModification-eDRX字段，那么UE在下一个eDRX中获得周期的边界获取变更的系统消息。如果说系统消息的变更周期边界可以被定义为(H-SFN*1024+SFN） mod 4096=0，即变更周期为4096个无线帧（SFN）（协议规定变更周期不小于40.96s），那么eDRX的获取周期边界就通过超帧H-SFN mod 1024=0来定义，即eDRX的获取周期为1024个超帧（H-SFN），如图1-9所示。

另外一种情况是通过MIB-NB中系统参数标签systemInfoValueTag来指示，UE 可以通过收到的该值与存储的值进行比对，如果不同则判定系统消息发生了改变，这种判定方式尤其针对 UE 短暂脱网重搜的场景进行设计（由于脱网导致没有收到系统消息变更的寻呼），现网中基站侧一般采取系统消息变更一次，该标签值同步增量+1的方式，32个值进行循环。在NB-IoT中，系统消息变更流程通知 UE 系统消息发生了改变，而 SIB1-NB 中的 systemInfoValue TagSI 字段明确了具体哪些系统消息发生了改变。LTE 中则不会对具体哪些系统消息变更予以明确。同时值得注意的是，LTE 中系统参数标签systemInfoValueTag是在SIB1中下发的，另外在LTE（R13之前的版本）也不涉及对于eDRX（超长DRX周期）的处理。

NB-IoT层3信令流程

NB-IoT 数据传输模式分为三种：第一种是通过非接入层（Non Access Stratum，NAS）控制面信令传送小数据，不需要建立专用无线承载（Dedicated Radio Bearer，DRB），协议中称为control plane CIoT optimization，简称CP数据优化传输模式；第二种是采取传统控制与用户面分离的模式，通过建立DRB承载传输数据；第三种是第二种数据传输模式的优化，只需要通过接入层信令交互就可以恢复用户面承载，从而使优化省去了一些NAS层信令交互，协议中称为user plane CIoT optimization，简称UP数据优化传输模式。第一种和第三种数据传输模式是相较 LTE 而言，NB-IoT 中特有的数据传输模式。另外，NB-IoT没有SRB2 消息，取而代之的是使用SRB1bis作为专属逻辑信道的信令承载，而仅支持控制面消息优化模式的NB-IoT终端只能建立使用SRB1bis。在RRC的专用信令承载SRB1建立之时，SRB1bis被隐式地建立起来，但是需要等到安全模式之后才被真正使用，由于 PDCP 层负责安全模式处理，因此SRB1bis 与 SRB1 根本的区别在于有没有 PDCP 层承载，由此可见，SRB1bis是没有 PDCP 层的。SRB1 采用逻辑信道标识 1，SRB1bis 采用逻辑标识 3。DLInformationTransfer-NB/ULInformation Transfer-NB/RRCConnection Release-NB/RRCConnectionSetupComplete-NB/UECapability Enquiry-NB/ UECapability Information-NB 等信令都可以采取 SRB1bis 承载，其中 RRCConnectionSetup-Complete-NB只能采取SRB1bis承载，由于RRC ConnectionSetupComplete-NB在安全模式建立之前触发，故协议在这里融合了 UP 数据优化传输模式和 CP数据优化传输模式的需求，只采取 SRB1bis 作为信令承载。NB-IoT 终端最多可支持2 个 DRB，而仅支持CP 优化数据传输模式的终端则不需要支持DRB以及相关流程。

NB-IoT层3信令流程整体上借鉴和复用了LTE信令流程。由于新增了UP数据优化传输模式，NB-IoT空口信令对应新增了RRC connection resume（RRC连接恢复）流程（见图1-10），该流程不适用于CP数据优化传输模式。

恢复是针对“挂起”流程而言的，为了使得 NB-IoT 终端更加省电，协议设计了“挂起-恢复”流程（注：协议标准中，该流程也可以适用 LTE 演进网络），网络侧通过RRCConnectionRelease-NB消息中释放原因值（ReleaseCause-NB）中的rrc-Suspend字段告诉终端RRC连接被挂起，UE存储接入层协议栈上下文和resumeIdentity，同时从连接态转变为RRC_IDLE（空闲态）。

挂起针对RRC层已建立的至少1个DRB，因此对于CP数据优化传输模式来说，“挂起-恢复”流程是不适用的。恢复流程会重新激活安全模式和重新建立信令及数据承载，相比RRCConnectionRequest-NB，不需要有后续安全模式控制流程了。这样可以使得终端快速“恢复”与网络侧的连接。对于终端的“恢复”请求，网络侧可能会恢复之前“悬挂”起的RRC连接，或者拒绝恢复请求，或者建立一个新的 RRC 连接，RRC 恢复请求消息及恢复/建立原因如图 1-11和图1-12所示，RRC连接挂起消息及信令流程如图 1-13所示。关于“恢复-挂起”流程，后面的章节会有更详细的阐述，这里不做过多展开。

当 UE 发出 RRCConnectionResumeRequest-NB，而网络侧的响应消息为RRCConnecionSetup-NB 时，这意味着网络侧建立一个新的 RRC 连接，那么UE 需要将之前存储的 AS 上下文以及 resumeIdentity 丢弃，并且通知高层 UE连接恢复被“回退”成新的RRC连接了，信令流程如图1-14所示。如同RRC连接请求一样，RRC连接恢复请求也同样受定时器T300控制，T300超时后底层清空，RRC连接流程终止，后续行为取决于终端个性化实现。

协议规定，CP数据优化传输模式是NB-IoT终端必须支持的功能设计，而UP数据优化传输模式则不然。RRCConnectionSetupComplete-NB消息体中只含 UP 数据优化传输模式的可选择支持字段，表征终端是否可支持UP 数据优化传输模式，如图1-15所示。

而对那些非NB-IoT的终端，比如eMTC终端或者LTE演进版本的终端，UP 数据优化传输模式和 CP 数据优化传输模式都是可选项，RRCConnection SetupComplete消息里根据终端实际能力，选填这两个字段进行上报，如图1-16所示。