第1章 NB-IoT技术概述

1.1 NB-IoT系统技术特点

下一代移动通信系统（5G）的重要属性之一是支持海量万物互联，这意味着下一代通信网络构建的目的不仅是为用户提供更高的速率，同时也需要有效提供支持物联网的系统架构。这在协议标准里得到体现，3GPP 目前的标准文档中并没有直接为 NB-IoT、eMTC 等物联网技术单独立书作传，接入网协议中对于NB-IoT一般采取独立章节进行描述，eMTC与LTE进行了融合。核心网协议中则对 eMTC/NB-IoT/LTE 采取了融合升级，这样也表明了一种架构设计理念，物联网的关键技术（例如物理层的调制/解调技术）借鉴了LTE，同时又是LTE技术的某种方向上的演进，而在接入网信令流程和核心网信令流程层面与LTE大体是一致的，从系统研发层面而言相对更加平滑和迅速。

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） modT=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[1]消息，取而代之的是使用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所示。

1.1.2 NB-IoT/LTE开机同步机制

任何通信系统的终端在开机的时候都需要与网络进行同步，同步是为了更准确地获取网络消息，开机时的同步指的一般是下行同步，下行同步涉及两个流程—频率同步和时间同步，一般先有频率同步，再有时间同步。

LTE的终端在频率同步时候采取 100kHz 精度的方式步进搜索，先确认中间部署主同步信号（Primary Synchronization Signal，PSS）的6个PRB的位置，再计算出中心频率。举例计算一下，band41 对应的中心频率范围是 2496～2689.9MHz，跨度 193.9MHz。每一个在 band41 内可设置的中心频率都是以2496MHz作为设置起点，并以100kHz整数倍作为间隔的方式进行设置，因此100kHz作为栅格基本精度扫描，恰恰对应上了每一个可能被设置的中心频点。

如何确认中间部署的6个PRB呢？协议上并没有进行规范。这里可能取决于芯片厂家的实现。一种可能的解决方案是以100kHz作为锁频步长，1.08MHz作为基本窗长，这样每步进一次，就做一次基于已知PSS序列的相关，这样的好处是可以直接进行精细同步，准确确定中心频点的位置，但是劣势也是显而易见的，采取这种方式芯片进行处理对于计算的代价太大，效率太低，从而可能初次开机时间拉长很多，同时涉及全频段全制式搜索，需要芯片具备不同的相关窗长，无形中增加了芯片的代价。另一种可能的解决方案是，每隔100kHz的步进就进行一次探测（其实就是尝试捕获一下能量脉冲），以 Band41的 D1频段举例，D1频段范围为2575～2595MHz，中心频点2585MHz，那么终端在首次开机，假设以Band41作为起始搜索频段，从起始频点2496MHz开始，搜完6个PRB最多需要探测脉冲[(2585MHz-2496MHz）/0.1MHz]+1=891次，过程中，如果出现了连续11次捕获脉冲呈现[01111011110]这种模式，则可以认为基本捕获了中间6个PRB的位置，同时也确定了中心频点，接下来就可以根据芯片预先存储的PSS序列与接收到的序列做相关，这样不但可以精准确认中心频率，同时也获取了实际的PSS码，同时也确定了后续参考信号（Reference Signal，RS）的位置，频率同步阶段至此就完成了。

NB-IoT的传输带宽为180kHz，在与LTE频谱共存的时候存在三种部署模式，分别为独立模式（Stand-alone）、带内模式（In-band）和保护带模式（Guard-band），三种组网模式如图 1-17 所示。当 UE 开机搜寻 NB-IoT 载频时，并不知道具体部署在哪里，也不知道采取以上三种模式的哪一种部署。

为了解决终端零中频接收导致的本振泄漏问题，NB-IoT 组网中采取独立模式/保护带模式/带内模式（不同 PCI）与带内模式，相同物理小区标识（Physical Cell Identifier，PCI）的下行OFDM符号频率偏置是不一样的，独立模式部署/保护带模式/带内模式（不同PCI）采取错频1/2子载波间隔（7.5kHz）的方式进行调制发射。而带内模式（相同PCI）则需严格与LTE子载波保持正交，同时基于LTE系统的中心子载波进行必要的频率错位，这种错位UE事先不得而知，主要取决于网络侧的配置。而网络侧配置需要考虑两方面的因素：一是不能与 LTE 系统的 PSS/SSS 冲突，SSS 即辅同步信号（Secondary Synchronization Signal），这意味着不能配置在中间6个PRB位置；另一方面需要考虑是否能够被UE开机扫频搜索到。类似于LTE终端开机搜网过程，NB-IoT终端也采取 100kHz 栅格扫频步进的方式尝试捕获 NB-IoT的锚定载波中心频点。理论上，NB-IoT也可以选择上述两种 LTE频率同步解决方案进行开机同步，不过第二种方案相比第一种方案而言理论上有一定的劣势，因为 NB-IoT的传输带宽与 100kHz 太接近，很难采取特定采样图的方式确定频域位置。最直接的方式就是采取 180kHz 频率同步窗、100kHz 步进的方式，即第一种开机搜网方案。针对UE的这种搜索方式，NB-IoT如果采取带内部署模式，需要配置在特定的一些 PRB 上，满足搜索频宽恰好是 100kHz的整数倍。以带宽为10MHz的LTE为例，NB-IoT可以被配置在第4、9、14、19、30、35、40、45 PRB上。

下行同步不仅涉及频域同步过程，还有时域同步过程。时域同步主要体现在解码PSS与SSS信号获取确定的时间位置。由于LTE/NB-IoT的PSS配置在特定子帧上，故锁定LTE或者NB-IoT的PSS也可以采取两种方式：

1）频域与时域异步搜索方式，即首先通过步进100kHz初始锁定频域（频域卷积），在时域滚动采样，满足一个无线帧周期之后再步进锁频下一个100kHz，依此方式循环直到成功解码出PSS。

2）频域与时域同步搜索方式，即通过步进100kHz进行初始锁定频域（频域卷积），在下一个子帧间隔后继续进行频域步进。

从以上可选的两种时、频域同步方式可以看出，频域同步和时域同步过程不是完全割裂的，而是有机地结合在一起。至于芯片具体采取哪种方式进行同步处理，取决于具体实现，以同步效率优先为准则。

值得注意的一点是，由于LTE的下行DC子载波的存在（LTE在DC子载波不传输数据是为了解决零中频接收带来的本振泄漏），NB-IoT部署在LTE高位 PRB（图 1-17 中 LTE 中心频点的右侧）的中心频点，与以 100kHz 进行步进锁频的预期位置有 2.5kHz的频偏，故协议规定针对 10MHz 和 20MHz 带宽LTE系统，以带内模式（In-band）进行NB-IoT部署的中心频点与100kHz栅格精度可以偏差 2.5kHz；而对于 3MHz、5MHz 和 15MHz 带宽的 LTE 系统，以带内模式进行 NB-IoT 部署的中心频点与 100kHz 栅格精度可以偏差 7.5kHz（1.4MHz的LTE无法进行NB-IoT的带内部署），这意味着终端在100kHz锁频过程中，每次需要尝试轮询 5 组栅格偏置以正确锁定频率，分别为{-7.5kHz,-2.5kHz, 0kHz, 2.5kHz, 7.5kHz}，详见表1-4。

当UE成功进行下行同步并且成功解码MIB-NB中的operationModeInfo参数指示与 LTE 是 Inband-SamePCI 共存模式后，UE 需要进一步获取 eutra-CRS-SequenceInfo参数，通过表1-4中的定义映射关系，UE可以获知NB-IoT在频域中占用LTE的PRB位置（）以及具体频率偏置，从而可以进行基于OFDM调制传输下行数据的正确解调（参见1.2.1节关于下行基于OFDM调制的时域连续信号计算公式）。