本文翻译 J. Schlienz, D. Raddino的Narrowband  Internet of Things Whitepaper。本文仅限于个人学习，研究，交流，不得用于其他商业用途！

白皮书.docx

白皮书.docx

摘 要

作为第13版的一部分，3GPP已经指定了一种新的无线接口，即窄带物联网（NBIoT）。 NB-IoT针对机器类型流量进行了优化。 它保持尽可能简单，以降低设备成本并最大限度地减少电池消耗。 此外，它还适用于在困难的无线电条件下工作，这是某些机器类型通信设备的频繁操作区域。 尽管NBIoT是一个独立的无线电接口，但它与LTE紧密相连，而LTE也在其当前LTE规范的集成中显示出来。 在本白皮书中，我们介绍了NB-IoT技术，重点是与LTE的紧密连接。

目 录

1    简介
2    物理层
3    小区访问
4    数据传输
5    摘要和展望
6    参考文献

1    简介

机器类型通信（MTC）的一个特征是广泛的功能。 例如，监控摄像机必须在几乎静止的情况下提供大量的UL数据，而用于车队跟踪的设备在执行大量切换时具有少量数据。

另一类设备既没有这些功能。 例如，用于抄表的装置，如电，气或水的消耗。 它们通常是静止的，因此不需要优化的切换。 通常只传输少量数据，甚至不会对延迟敏感。 然而，与传统设备相比，这些MTC设备的数量可能变得非常大，甚至达到几个数量级。 使用现有的LTE技术会导致网络过载，因为尽管用户数据量很小，但信令量大致相同。 NB-IoT的第一个规范集中在这类设备上。

这些设备通常安装在没有电源的地方。 因此，它们完全依靠电池运行，更换电池可能非常昂贵，因为它们只能由经过培训的人员访问。 因此，在某些情况下，电池寿命甚至可以确定整个设备的寿命。 因此，优化的功耗对于正确的操作是必不可少的。 此外，这些地方的报道通常都很糟糕。 因此，必须显着改善室内覆盖范围，认为必要时高达23 dB。

由于需要大量的设备，因此必须处于低成本范围内。 作为目标，每个模块的价格范围应小于5美元。

为了评估可能的解决方案，在GERAN TSG [1]中的3GPP中讨论了一个研究项目。 除了上述功能之外，主要要求是与现有GSM，UMTS和LTE系统以及用于这些技术的硬件共存。

已经从该研究中确定了两种解决方案，即NB-IoT和EC-GSM，其中后者基于GSM标准。同时，还将纯LTE解决方案LTE-M引入3GPP。随着新设备类别cat-M1的推出，它继续在第12版中进行的优化。

在本白皮书中，介绍了NB-IoT。虽然它集成在LTE标准中，但它可以被视为一种新的空中接口。因此，它不与LTE向后兼容。通过指定从现有标准或其附近使用的时间和频率资源来实现共存。

白皮书的结构如下：我们首先概述更具体的要求和网络架构，并提供物理层的详细信息。在描述了对单元的访问之后，我们展示了如何通过空中接口传输数据包。最后，给出了该技术进一步发展的展望。

2    概 述

2.1    要求
根据前一章提到的一般MTC要求，推导出以下NB-IoT的标准特定要求：
●最大限度地减少信令开销，尤其是通过无线接口
●对整个系统（包括核心网络）的适当安全性
●延长电池寿命
●支持IP和非IP数据的传送[2,3]
●支持SMS作为部署选项[4]

为了满足这些要求，不支持LTE版本8/9的许多高级甚至基本功能[5]。 最引人注目的例子是处于连接状态的UE缺少切换。 仅支持空闲状态下的小区重选，甚至限制在NB-IoT技术内。 由于没有与其他无线电技术的交互，因此也不支持相关的功能。 例如，缺乏LTE-WLAN互通，用于设备内共存的干扰避免，以及用于监控信道质量的测量。

大多数LTE-Advanced功能也不受支持。 这涉及到例如 运营商聚合，双连接或设备到设备服务。 此外，没有QoS概念，因为NB-IoT不用于延迟敏感数据包。 因此，在NB-IoT中也不提供需要保证比特率的所有服务，例如实时IMS。 根据这些要求，3GPP使用与以前不同的方法。 而不是为所有类型的应用创建一个空中接口，用于小型非延迟敏感数据包的空中接口被分开并单独优化。 支持处理NB-IoT技术的UE用新的UE类别cat-NB1标记。

2.2    网络
2.2.1    核心网
为了向应用程序发送数据，定义了演进分组系统（EPS）中的蜂窝物联网（CIoT）的两种优化，用户平面CIoT EPS优化和控制平面CIoT EPS优化，见图2-1。 可以使用两种优化，但不限于NB-IoT设备。

在控制平面CIoT EPS优化上，UL数据从eNB（CIoT RAN）传送到MME。从那里，它们可以通过服务网关（SGW）传输到分组数据网络网关（PGW），或者传输到服务能力暴露功能（SCEF），然而这只能用于非IP数据分组。从这些节点开始，它们最终被转发到应用服务器（CIoT服务）。DL数据在相反的方向上通过相同的路径传输。在该解决方案中，没有建立数据无线电承载，而是在信令无线电承载上发送数据分组。因此，该解决方案最适合于不频繁和小数据分组的传输。

SCEF是专为机器类型数据设计的新节点。它用于通过控制平面传送非IP数据，并为网络服务提供抽象接口（身份验证和授权，发现和访问nework功能）。

利用用户平面CIoT EPS优化，数据以与传统数据业务相同的方式传输，即通过SGW和PGW通过无线电承载传输到应用服务器。因此，它在构建连接时产生一些开销，但是它有助于发送一系列数据包。此路径支持IP和非IP数据传输。

2.2.2    接入网
在整体接入网架构上，LTE没有区别[6],

eNB使用S1接口连接到MME和S-GW，区别在于携带NB-IoT消息和数据分组。 即使没有定义切换，在两个eNB之间仍然存在X2接口，这使得UE在进入空闲状态后能够快速恢复，有关详细信息，请参见第4.5.1节“RRC连接建立”， 即使是恢复过程是另一个eNB的情况。

2.3    频段
对于频带，使用与LTE中相同的频率编号，其中为NB-IoT定义了子集。 在第13版中，这些是以下band[7]：

值得一提的是，大多数频率都在现有LTE频段的较低范围内。 这反映出对于机器类型的通信，在困难的无线电条件下预期有许多设备。

3    物理层

3.1    操作模式
NB-IoT技术占用180 kHz带宽的频带[8]，其对应于LTE传输中的一个资源块。 通过此选择，可以使用以下操作模式：
●独立操作。 可能的情况是利用当前使用的GSM频率。 它们的带宽为200 kHz，在频谱的两侧仍然保留10 kHz的保护间隔
●保护频带操作，利用LTE载波保护频带内未使用

的资源块
●利用LTE载波内的资源块的带内操作

这些模式在下图中可视化：

对于独立操作，图中右侧的GSM载波仅作为示例示出，以指示这是可能的NB-IoT部署。 当然，该操作模式也可以在没有相邻GSM载波的情况下工作。

在带内操作中，LTE和NB-IoT之间的资源分配不是固定的。 然而，并非所有频率（即，LTE载波内的资源块）都被允许用于小区连接。 它们仅限于以下值：

如该表所示，不支持具有1.4MHz带宽的LTE频带的带内操作。 当为NB-IoT分配资源时，必须考虑LTE系统使用的资源之间的冲突，例如小区特定参考信号（CRS）或每个子帧开始时的下行链路控制信道。 这也通过不使用6个内部资源块反映在表3-1中，因为这些是为LTE中的同步信号分配的。

对于保护频带操作，UE仅与信号同步，其中频带完全在保护频带中。

 为了应对不同的无线电条件，可能有多达3个覆盖增强（CE）级别，CE级别0到CE级别2.CE级别0对应于正常覆盖，CE级别2对应于最坏情况，其中覆盖范围可能会被认为是非常贫穷。它取决于网络，定义了多少个CE级别。对于每个CE级，在小区中广播所接收的参考信号的功率阈值的列表。不同CE级别的主要影响是消息必须重复多次。

对于版本13，选择FDD半双工类型B作为双工模式。这意味着UL和DL在频率上是分开的，并且UE接收或发送，但不是同时接收或发送。另外，在从UL到DL的每个交换机之间或者反之亦然，在它们之间存在至少一个保护子帧（SF），其中UE有时间切换其发送器和接收器链。

3.2    下行链路
对于DL，三个物理信道
●NPBCH，窄带物理广播信道
  ●NPDCCH，窄带物理下行链路控制信道
●NPDSCH，窄带物理下行共享信道

和两个物理信号
●NRS，窄带参考信号
●NPSS和NSSS，
定义了主同步信号和辅助同步信号。 这些信道比LTE少，不包括物理多播信道PMCH，因为NB-IoT没有MBMS服务。

下图说明了传输通道与物理通道之间的连接：

MIB信息总是通过NPBCH传输，剩余的信令信息和数据通过NPDSCH传输。 NPDCCH控制UE和eNB之间的数据传输。

物理DL信道始终是QPSK调制的。 NB-IoT支持使用一个或两个天线端口AP0和AP1进行操作。 对于后一种情况，应用空频块编码（SFBC）。 一旦被选择，相同的传输方案适用于NPBCH，NPDCCH和NPDSCH。

与LTE类似，每个小区具有指定的物理小区ID（PCI），即窄带物理小区ID（NCellID）。 共定义了504个不同的NCellID值。 其值由辅助同步信号NSSS提供，请参见第第3.2.3节“同步信号”。

3.2.1    框架和槽结构
在DL中，使用具有正常循环前缀（CP）的15kHz子载波间隔来应用OFDM。 每个OFDM符号由12个子载波组成，以这种方式占用180kHz的带宽。 七个OFDMA符号捆绑在一个插槽中，因此插槽具有以下资源网格[9]：

对于一个资源块，这是与正常CP长度中的LTE相同的资源网格，这对于带内操作模式是重要的。 资源元素被定义为一个OFDMA符号中的一个子载波，并在图3-3中用一个方块表示。 这些资源元素中的每一个携带具有根据调制方案的值的复数值。

这些时隙以与LTE相同的方式总结为子帧和无线电帧：

有1024个循环重复的无线电帧，每个持续10ms。 无线电帧被划分为10个SF，每个SF由两个时隙组成。

除了系统帧之外，还定义了超帧的概念，其对系统帧周期的数量进行计数，即，每当系统帧号包装时它就递增。 它是一个10位计数器，因此超帧周期跨越1024个系统帧周期，对应于几乎3小时的时间间隔。

3.2.2    窄带参考信号
窄带参考信号（NRS）在所有可用于广播或专用DL传输的SF中传输，无论数据是否实际传输，请参见第3.2.5节“专用信道”了解更多详细信息。

根据传输方案，NRS可以在一个天线端口上传输，也可以在两个天线端口上传输。 它的值创建类似于LTE中的CRS，其中NCellID用于PCI。 映射序列如下图所示：

图3-5中所示的NRS映射另外在频率范围内由NCellID mod 6循环移位。 当在两个AP上发送NRS时，则在AP0上用于NRS的每个资源元素上，AP1上的相同资源元素被设置为零，反之亦然。

对于带内操作，LTE CRS也在NB-IoT频带中发送，用于不用于MBSFN的SF。利用NRS的结构，LTE CRS和NRS之间没有重叠，但是必须将CRS考虑在速率匹配和资源元素映射中。所有DL传输都不得使用这些资源元素，必须跳过它们。

带内操作的一个重点是NcellID。它可以与用于嵌入LTE小区的PCI相同或不同。这由MIB-NB中的opeartionMode参数指示，请参见第3.2.4节“窄带物理广播信道”，它区分带内操作与同一PCI的真或假。如果该参数设置为真，则NCellID和PCI相同，并且UE可以假设天线端口的数量与LTE小区中的相同。然后可以从任一参考信号集推断出信道。因此，LTE CRS端口0与NRS端口0相关联，并且CRS端口1与NRS端口1相关联。如果相同PCI被设置为假，则UE可以不采取任何这些假设。

3.2.3    同步信号
对于帧和子帧中的第一同步并且为了确定NCellID，重用主同步信号（PSS）和辅同步信号（SSS）的LTE概念。 利用这些信号，还可以在UE接收器中细化定时和频率估计。

为了将这些信号与其LTE对应物区分开，它们分别表示为NPSS和NSSS。 它们的结构如下图所示：

省略前3个OFDM符号，因为当NB-IoT以带内模式操作时，它们可以在LTE中承载PDCCH。 注意，在UE与NPSS和NSSS同步的时间期间，它可能不知道操作模式，因此该保护时间适用于所有模式。 此外，两个同步信号都被LTE的CRS打孔。 没有规定，哪个天线端口用于同步信号，这甚至可以在任何两个SF之间改变。

频域中的长度为11的Zadoff-Chu序列用于NPSS的序列生成。该序列是固定的，因此不携带关于小区的信息。它在每个无线电帧的SF5中发送，使得其接收允许UE确定帧边界。

NSSS序列从长度为131的频域Zadoff-Chu序列生成，二进制加扰并根据无线电帧号循环移位。NCellID是一个额外的输入参数，因此可以从序列中导出。与LTE类似，定义了504个PCI值。NSSS在每个偶数无线电帧的最后SF中发送。

对于带内操作，NPSS和NSSS的传输以及下一节中描述的NPBCH只能在PRB上进行，如表3-1所示。选择用于接收该信息的载波称为锚载波。

使用这种结构，UE不能将NB同步信号与LTE系统发送的信号混淆。因此，不存在错误检测的危险，并且具有任一技术的UE被自动路由到正确的频率范围。

3.2.4    窄带物理广播信道
NPBCH携带窄带主信息块（MIB-NB）。 MIB-NB包含34比特，并且在640ms的时间段内发送，即64个无线电帧。 其中提供了以下信息：
●4位表示系统帧号（SFN）的最高有效位（MSB），剩余的最低有效位（LSB）从MIB-NB启动中隐含地得出
●2比特，表示超帧号的两个LSB
●4位用于SIB1-NB调度和大小
●5位表示系统信息值标签
●1位，表示是否应用了访问类限制
●7位表示具有模式特定值的操作模式
●11个备用位，用于将来扩展

图3-7显示了它到物理资源的映射：

在物理层基带处理之后，将得到的MIB-NB分成8个块。 第一个块在第一个子帧（SF0）上发送，并分别在接下来的7个连续无线电帧的SF0中重复。 在以下无线电帧的SF0中，对BL2执行相同的过程。 继续该过程直到传输整个MIB-NB。 通过将SF0用于所有传输，如果NB-IoT被部署为带内操作，则避免NPBCH与LTE上的潜在MBSFN传输冲突。

NPBCH的SF结构如下图所示：

符号映射在NRS和LTE CRS周围，其中始终假设为NRS定义了两个天线端口，为CRS定义了4个天线端口。 该假设是必要的，因为UE仅通过读取MIB-NB来获得实际的天线端口信息。 频率范围内的参考信号位置由NSSS提供的NCellID给出。 尽管NCellID在带内操作中可能与PCI不同，但是其范围受到限制以使其指向相同的频率位置，因此UE已知频率范围内的CRS的循环移位。 同样，省略前3个OFDM符号以避免与LTE的控制信道的可能冲突。

3.2.5    专用频道
控制和共享信道的原理也适用于NB-IoT，定义窄带物理下行链路控制信道（NPDCCH）和窄带物理下行链路共享信道（NPDSCH）。 并非所有SF都可以用于传输专用DL信道。 在RRC信令中，可以用信号通知指示有效SF的10或40比特的位图，其以周期性方式应用。 对于SF未被指示为有效的情况，专用DL信道传输被推迟到下一个有效SF。

3.2.5.1    控制信道NPDCCH
NPDCCH指示哪个UE在NPDSCH中存在数据，在哪里找到它们以及它们重复的频率。 此外，在其中提供UL授权，示出UE将用于UL中的数据传输的资源。 最后，NPDCCH中还包含诸如寻呼或系统信息更新之类的附加信息。 NPDCCH子帧设计如下图所示：

用于NPDCCH的资源元素以绿色表示。 它们必须映射在蓝色显示的NRS周围，并且还围绕CRS（紫色）进行带内操作。 参数lNstart（由NB-SIB1用信号通知的控制区域大小）指示OFDM起始符号。 这种方式可以避免带内操作与LTE控制信道的冲突。 对于保护频带和独立操作模式，控制区域大小默认为0，这为NPDCCH提供了更多的资源元素。

在每个SF上，定义了两个窄带控制信道单元（NCCE），NCCE0和NCCE1。 它们在图3-9中以深绿色（NCCE0）和浅绿色（NCCE1）表示。 定义了两种NPDCCH格式来使用它们：
  ●NPDCCH格式0采用一个NCCE。 因此，它们中的两个可以在SF内传输。
  ●NPDCCH格式1同时采用NCCE。

 为了使UE以合理的解码复杂度找到控制信息，NPDCCH被分组到以下搜索空间中：

●Type-1公共搜索空间，用于分页
●Type-2公共搜索空间，用于随机访问
●UE特定的搜索空间
每个NPDCCH可以用RRC配置的上限重复若干次。 另外，类型2公共搜索空间和UE特定搜索空间由RRC提供，而类型1公共搜索空间由寻呼机会SF给出，参见第4.7章“寻呼”。

为每个UE分配不同的无线电网络临时标识符（RNTI），一个用于随机接入（RA-RNTI），一个用于寻呼（P-RNTI），以及在随机接入过程中提供的UE特定标识符（CRNTI）。 NPDCCH的CRC中隐含地指示了这些标识符。 因此，UE必须在其搜索空间中查找该RNTI，并且如果找到，则对NPDCCH进行解码。

版本13中定义了三种DCI格式，DCI格式N0，N1和N2 [10]：

当UE接收到NPDCCH时，它可以通过以下方式区分不同的格式：以用P-RNTI对CRC进行加扰的方式隐含地指示DCI格式N2。 如果用C-RNTI对CRC进行加扰，则消息中的第一位指示是否包含DCI格式N0或N1。 对于利用RA-RNTI对CRC进行加扰的情况，内容是受限制的DCI格式N1，其仅包括RACH响应所需的那些字段。

包括在DCI格式中的N0和N1是调度延迟，即NPDCCH结束与NPDSCH开始或NPUSCH开始之间的时间。 NPDSCH的延迟至少为5 SF，NPUSCH为8。 对于经由DCI格式N2的DL传输，调度延迟固定为10SF。

3.2.5.2    业务信道NPDSCH
NPDSCH SF具有与图3-9中所示的NPDCCH相同的结构。它从可配置的OFDM符号lNstart开始，并围绕NRS映射，并且对于带内操作，映射为LTE CRS。lNstart由用于带内操作的RRC信令提供，否则为0。

支持最大传输块大小（TBS）680位。传输块的映射跨越NSF SF。重复传输块，提供NRep相同的副本，使用SF交织在UE处进行优化接收。两个值NSF和NRep都在DCI中指示。生成的SF序列映射到为NPDSCH定义的NSF·NRep连续SF。

对于DL，没有对传输的自动确认，eNB在DCI中指示这一点。如果这样做，则UE使用NPUSCH格式2发送确认，参见章节3.3.2，“物理上行链路共享信道”，第19页。相关的定时和子载波也在该DCI中指示。

对所有操作模式都有多载波支持，请参见第35页上的第5.2.2节“多载波配置”，这意味着当UE处于连接状态时可以使用另一个载波。在空闲状态中，UE驻留在NB-IoT载波上，从该载波接收同步信号和广播信息，即锚载波。它通过在SIB2-NB中提供的相关UL载波中发送前导码，在那里等待寻呼或开始对移动始发数据或信令的接入。

SIB1-NB传输
SIB1-NB通过NPDSCH传输。它有256个无线电帧的周期，重复4,8或16次。传输块大小和重复次数在MIB-NB中指示。可以进行4,8或16次重复，并且分别定义4个传输块大小208,328,440和680位。SIB1-NB启动的无线电帧由重复次数和NCellID确定。SF4用于传输SIB1-NB的所有无线电帧中的SIB1-NB。由于其他传输参数也是固定的，因此控制信道中没有相关的指示。

SIB1-NB内容可以仅在每个修改周期上改变，其具有4096个无线电帧的长度，即40.96秒。这对应于4个SFN周期，这就是为什么在MIB-NB中指示超帧号的2个LSB。如果发生这样的修改，则使用DCI格式N2在NPDCCH中指示。

尽管通过NPDSCH发送，但是SIB1-NB资源被映射为如图3-8中所示的MIB-NB，即省略了前3个OFDM符号。这是必要的，因为UE知道从SIB1-NB开始的资源映射，因此它需要首先解码该SIB。

3.3    上行链路
对于上行链路（UL），两个物理信道
●NPUSCH，窄带物理上行链路共享信道
●NPRACH，窄带物理随机接入信道和
●定义DMRS，解调参考信号。

物理信道与相关传输信道之间的连接如下图所示：

除RACH传输外，所有数据都通过NPUSCH发送。 这还包括UL控制信息（UCI），其使用不同的格式发送。 因此，没有相当于LTE中的PUCCH。

3.3.1    时隙结构
在UL中，应用单载波频分多址（SC-FDMA），具有3.75kHz或15kHz子载波间隔。 eNB决定使用哪一个。 当应用15kHz子载波间隔时，UL的资源网格与DL的资源网格相同，请参见图3-3。 对于3.75kHz子载波间隔，时隙的资源网格具有修改的结构：

同样在一个时隙内有7个OFDM符号。 根据OFDM原理，3.75kHz子载波间隔的符号持续时间是15kHz的持续时间的四倍，这导致时隙长度为2ms。

3.3.2    物理上行链路共享信道
在物理UL共享信道NPUSCH上，定义了两种格式。 NPUSCH格式1用于UL-SCH上的UL传输信道数据，传输块不大于1000比特。 NPUSCH格式2携带UL控制信息（UCI），其在版本13中限于DL传输的确认。

映射传输块的最小单元是资源单元（RU）。 其定义取决于PUSCH格式和子载波间隔。

对于NPUSCH格式1和3.75kHz子载波间隔，RU由频率范围中的1个子载波和时间范围中的16个时隙组成，即RU具有32ms的长度。 在15 kHz子载波间隔上有4种选择：

对于NPUSCH格式2，RU总是由一个长度为4个时隙的子载波组成。 因此，对于3.75kHz子载波间隔，RU具有8ms持续时间并且对于15kHz子载波间隔2ms。
对于NPUSCH格式2，调制方案始终为BPSK。 NPUSCH格式1允许的调制取决于所选的RU：
●对于具有一个子载波的RU，可以使用BPSK和QPSK
●对于所有其他RU，应用QPSK

通过DCI格式N0在NPDCCH中指示用于UL-SCH传输的许可。 在该DCI中指示NPUSCH的开始时间，重复次数，用于一个传输块的RU的数量，以及包括它们在频率范围中的位置的子载波的数量。 此外，包含MCS索引，为一个子载波RU提供调制方案，另外，与RU的数量一起，提供传输块大小。

最后，通过应用逆傅里叶变换并且在循环前缀（CP）之前预先创建时间信号。 对于15kHz子载波间隔，此CP与使用普通CP的LTE相同，而对于3.75kHz，它是256个样本，对应于8.3μs。 对于后一种情况，每个时隙结束时的2304个采样（75μs）的周期保持为空，这用作保护间隔。 对于带内操作，该保护间隔可以用于在LTE系统中发送探测参考信号。

与DL传输相反，在可以配置是否应该确认传输的情况下，在相关DL中总是存在确认。

3.3.3    参考信号
在UL中，定义了解调参考信号（DMRS）。 它与数据复用，因此它仅在包含数据传输的RU中传输。 没有为UL定义MIMO传输，因此所有传输都使用单个天线端口。
 
根据NPUSCH格式，DMRS以每个时隙的一个或三个SCFDMA符号发送。 对于NPUSCH格式1，这些是图3-12中红色标记的符号。

从该图中可以看出，用于DMRS传输的SC-FDM符号取决于子载波间隔。 对于图3-13中所示的NPUSCH格式2也是如此：

DMRS符号由基本序列乘以相位因子构成。 它们具有与相关数据相同的调制。 对于NPUSCH格式2，DMRS符号以与针对LTE PUCCH格式1,1a和1b定义的相同的正交序列进行扩展。

3.3.4    随机接入信道
在随机接入信道NPRACH中，发送前导码。 第47页第4.4章“随机接入过程”中描述的相关随机接入过程可用于向小区发信号通知UE驻留在其上并希望获得接入。

前导码基于单个子载波上的符号组。 每个符号组具有循环前缀（CP），后跟5个符号。 以下结构显示了此序列：

定义了两种前同步码格式，格式0和格式1，它们的CP长度不同。 五个符号的持续时间为TSEQ = 1.333 ms，对于格式0，CP为TCP =67μs，对于格式1，CP为267μs，总长度分别为1.4 ms和1.6 ms。 要使用的前导码格式在系统信息中广播。

前导码由无间隙发送的4个符号组组成。跳频应用于符号组粒度，即每个符号组在不同的子载波上发送。通过构造，该跳跃被限制为连续的12个子载波集。取决于覆盖水平，小区可以指示UE将在每次重复时使用相同的传输功率重复前导码1,2,4,8,16,32,64或128次。

为每个CE组分别提供NPRACH资源。它们包括时间和频率资源的分配，并且周期性地发生，其中可以配置40ms和2.56s之间的NPRACH周期。它们在一段时间内的开始时间在系统信息中提供。重复次数和前导码格式决定了它们的结束。

在频率范围内，应用3.75kHz的子载波间隔。NPRACH资源占用12,24,36或48个子载波的连续集合，并且位于一组离散的子载波范围上。取决于小区配置，资源可以进一步划分为由支持msg3的多音传输的UE和不支持它的UE使用的资源。

图3-15显示了重复至少4次的前导码的示例。这里，每个蓝色矩形描述一个前导码符号组，如图3-14所示，因此前导码重复由四个矩形组成。

在12种可能性中，如果eNB没有针对有序前导码传输的情况提供，则UE选择用于传输第一前导码符号组的子载波。接下来的3个符号组由算法确定，该算法仅取决于第一个符号的位置。对于下一次重复的第一符号组的子载波选择，应用伪随机跳频，其中NCellID和重复次数用作输入。以下符号组的子载波选择再次仅取决于该结果。

该跳频算法的设计方式是第一子载波的不同选择导致从不重叠的跳频方案。因此，存在与分配给NPRACH的子载波一样多的不同的无拥塞前导码。不对NB-IoT进行进一步的划分，即，没有像LTE中应用的前导码索引那样的概念。

前导序列建立在Zadoff-Chu序列上，该序列取决于子载波位置。对载波频率的调制和上变频以与LTE相同的方式完成。

3.4    功率控制
3.4.1    上行链路
在UL中，发射功率取决于小区特定参数，所选RU和UE测量参数的组合[11]。 对于最多重复2次的情况，时隙i的功率由下式给出

如果重复次数超过两次，则传输功率通常由PCMAX，c（i）给出。

PCMAX，c（i）是时隙i上的小区特定最大发射功率。利用上述结构，发射功率可能永远不会超过该阈值。MNPUSCH，c取决于所选RU的带宽和子载波间隔，PO_NPUSCH，由RRC用信号通知的不同参数的组合，这取决于传输块是用于UL-SCH数据（j = 1）还是用于RACH消息（j = 2）。PLc是UE估计的路径损耗。该因子由αc（j）加权，对于NPUSCH格式1由RRC提供，否则应用固定值1。换句话说，该因子表示应补偿路径损耗的强度。

3.4.2    下行链路
DL传输功率是指NRS传输功率。其值被指示给UE以便估计路径损耗。对于携带NRS和所有SF的所有资源元素，它是恒定的。

对于NPBCH，NPDCCH和NPDSCH，发射功率取决于传输方案。如果仅应用一个天线端口，则功率与NRS相同，否则减少3dB。

如果使用带内操作模式并且samePCI值设置为true，则会出现特殊情况。然后，eNB可以另外用信号通知NRS功率与CRS功率的比率，使得UE也能够使用CRS进行信道估计。

4 小区访问

当UE接入小区时，其遵循与LTE相同的原理：它首先在适当的频率上搜索小区，读取相关的SIB信息，并开始随机接入过程以建立RRC连接。 通过此连接，它通过NAS层向核心网络注册，如果尚未完成的话。 在UE返回到RRC_IDLE状态之后，如果它具有要发送的移动始发数据，则它可以再次使用随机接入过程，或者等待直到它被寻呼。

4.1    协议栈和信令承载
协议层的一般原则是从LTE协议开始，将它们降低到最小，并根据NB-IoT的需要增强它们。这样，重复使用经过验证的结构和过程，同时防止来自未使用的LTE特征的开销。因此，从协议栈的角度来看，NB-IoT技术也可以被视为一种新的空中接口，同时建立在完善的基础之上。

其一个例子是承载结构。信令无线电承载部分地从LTE重用。存在用于通过CCCH逻辑信道发送的RRC消息的SRB0，以及用于使用DCCH逻辑信道的RRC消息和NAS消息的SRB1。但是，没有定义SRB2。

另外，定义了新的信令无线承载，SRB1bis。它使用相同的配置隐含地配置SRB1，但是没有PDCP。此通道扮演SRB1的角色，直到激活安全性，然后不再使用SRB1bis。这也意味着对于控制平面CIoT EPS优化，根本不使用SRB1bis，因为在此模式下没有安全激活。

协议栈与LTE相同，具有针对NB-IoT优化的功能：

4.2    系统信息
与LTE类似，系统信息用于广播对小区内的所有UE有效的信息。 由于广播系统信息占用资源并导致每个UE的电池消耗，所以它保持最小，以及其出现的大小。

因此，定义了一组系统信息块（SIB），其是为LTE定义的SIB的子集。 这些如下表所示：

SIB用后缀NB表示。 这些SIB中的每一个都用减少和修改的信息元素集定义，然而，内容的类型与LTE中的相同，例如， SIB16-NB描述了时间信息。 即使在带内操作的情况下，UE也专门使用这些SIB并忽略来自LTE的那些SIB。

UE始终必须具有通过SIB5-NB的有效版本的MIB-NB，SIB1-NB和SIB2NB。 如果操作需要其功能，则其他必须有效。 例如，如果在MIB-NB中指示接入禁止（AB），则UE需要具有有效的SIB14-NB。

系统信息获取和改变过程仅应用于RRC_IDLE状态。 期望UE在处于RRC_CONNECTED状态时读取SIB信息。 如果发生改变，则通过寻呼或直接指示通知UE。 eNB还可以将UE释放到RRC_IDLE状态以获取修改的系统信息。

4.2.1    调度

MIB-NB和SIB1-NB按第3.2章“下行链路”中的说明进行传输。剩余SIB信息的调度以与LTE类似的方式完成：SIB-NB消息被分组为SI消息，其中 然后在单独的SI窗口中传输。 不同SI消息的SI窗口不重叠。 它们的长度在SIB1-NB中指示，并且对于所有SI消息是相同的。 每条SIB和SI消息的最大大小为680位。

在SI窗口内，SI消息通过2或8个连续有效DL SF发送，具体取决于它们的传输块大小，并且可以重复多次。 调度信息在SIB1-NB中指示，因此在NPDCCH中没有必要的指示并且不需要SI-RNTI。

4.2.2    变更通知
如“SIB1-NB传输”中已经提到的，系统信息可能仅在修改周期的时间边界处改变并且用寻呼消息指示。一个例外是通过SIB14-NB指示的访问限制（AB）的变化，该信息可以在任何给定的时间点改变。这种例外背后的原因是AB参数可能需要在更短的时间范围内改变。当然，SIB16-NB没有通过寻呼通知表示，因为它会定期更改其内容。

指示SIB1-NB或SI消息中的更改的另一种方式是值标记的概念。关联字段systemInfoValueTag包含在MIB-NB中。该概念用于UE从覆盖范围外的位置返回到覆盖范围以及从更长的DRX周期返回的UE。在这些情况下，UE无法接收寻呼消息，因此它检查值标签。如果存在SIB更改，则会修改值标记。但是，如果超过24小时超出覆盖范围，则UE必须始终读取系统信息。

4.2.3    总结SIB采集
UE首先从NSSS获得NCellID。 通过读取MIB-NB中的schedulingInfoSIB1，它知道SIB1-NB大小和重复次数，并且可以推断其起始位置。 在SIB1中，指示其他SIB-NB消息的位置。 最后，借助于从MIB-NB获得的超帧号的2个LSB，UE知道何时检查SIB更新，是否通过修改的值标签或通过寻呼指示SIB改变。

4.3    小区选择和移动性

NB-IoT设计用于UE和网络之间的不频繁和短消息。假设UE可以在从一个小区服务的同时交换这些消息，因此，不需要在RRC_CONNECTED期间的切换过程。如果需要这样的小区改变，则UE首先进入RRC_IDLE状态并重新选择其中的另一个小区。

对于RRC_IDLE状态，为频率内和频率间小区定义小区重选[12]。这里，频率间是指180kHz载波，这意味着即使在嵌入同一LTE载波的带内操作中使用两个载波，这仍然被称为频率间重选。

为了找到小区，UE首先测量NRS的接收功率和质量。然后将这些值与SIB-NB提供的小区特定阈值进行比较。S标准指出如果两个值都高于这些阈值，则UE认为自己处于该小区的覆盖范围内。如果UE处于一个小区的覆盖范围内，则驻留在其上。

取决于所接收的NRS功率，UE可能必须开始小区重选。UE将该功率与重选阈值进行比较，该重选阈值对于频率内和频率间情况可以是不同的。从实际服务小区接收所有必需参数，不需要从其他小区读取SIB-NB。

在满足S标准的所有小区中，UE针对超过另一阈值的功率超出对小区进行排名。在该过程中添加滞后以防止过于频繁的小区重选，并且还可以针对频率内情况应用小区特定偏移。与LTE相反，不同频率没有优先级。UE最终选择适合的最高等级的小区，即，它可以从其接收正常服务。

当UE离开RRC_CONNECTED时，它不一定选择相同的载波来找到要驻留的小区。RRCConnectionRelease消息可以指示UE首先尝试找到合适小区的频率。仅当UE在该频率上没有找到合适的小区时，它还可以尝试在不同的频率上找到一个小区。

4.4    随机访问程序

RACH过程具有与LTE相同的消息流，但是，具有不同的参数[13]：

对于NB-IoT，RACH过程始终基于竞争，并从第3.3.4节“随机接入信道”中概述的前导码的传输开始。在来自eNB的相关响应之后，发送调度消息msg3，以便开始争用解决过程。最后将相关的争用解决消息发送到UE，以指示RACH过程的成功完成。

在发送前导码时，UE首先根据传输时间计算其RA-RNTI。然后在PDCCH中查找用RA RNTI加扰的DCI格式N1，其中指示了随机接入响应消息。UE期望在响应窗口内的该消息，其在最后的前导码SF之后开始3个SF并且具有在SIB2-NB中给出的CE相关长度。

如果前导码传输不成功，即没有接收到相关联的随机接入响应（RAR）消息，则UE发送另一个消息。这可以达到最大数量，这又取决于CE级别。对于未成功达到该最大数量的情况，如果配置了该级别，则UE前进到下一个CE级别。如果达到访问尝试的总次数，则向RRC报告相关的故障。

利用RAR，UE除了临时C-RNTI之外还获得定时提前命令。因此，以下msg3已经是时间对齐的，这对于通过NPUSCH进行传输是必需的。此外，RAR为msg3提供UL授权，包含用于msg3传输的所有相关数据。

其余过程如同在LTE中那样完成，即UE发送标识，并且在接收到指示该标识的争用解决时，随机接入过程被成功完成。

4.5    连接控制

由于系统不支持切换到不同的技术，RRC的状态模型变得非常简单（图4-3）。

如在LTE中，仅存在两种状态，RRC_IDLE和RRC_CONNECTED。 但是，没有转换到相关的UTRA和GSM状态，因为不支持切换到这些技术。 也没有切换到LTE，因为LTE被视为不同的RAT。

4.5.1     RRC连接建立

RRC连接建立具有与LTE系统相同的消息流：

利用RRCConnectionRequest，UE指示它想要连接到网络以及用于什么目的。此建立原因仅限于移动始发信令，移动始发数据，移动终止接入和特殊报告。延迟容忍流量没有建立原因，因为在NB-IoT中，假设所有流量都是延迟容忍的。除了建立原因之外，UE还指示其支持多音调业务和多载波支持的能力。尽管这些功能通常在自己的过程中发出信号，请参见第4.6章“UE功能传输”，这些功能必须在此处发出信号，以便eNB可以将其应用于此过程中的UL授权。

在用RRCConnectionSetup消息响应时，eNB提供信令无线电承载（SRB1），多达2个数据无线电承载（DRB）和协议的配置。最后，在RRCConnectionSetupComplete消息中，UE包括其所选择的PLMN和MME，并且可以搭载第一NAS消息。

在为用户平面CIoT EPS优化建立连接之后，以与具有仅限于NB-IoT的功能的LTE相同的方式完成安全和RRC连接重新配置过程。此外，还为此情况定义了RRC连接重建过程。对于控制平面CIoT EPS优化，不应用这些过程。

当eNB释放连接时，请参见第4.5.2章“RRC连接释放”，它也可以暂停UE。在这种情况下，UE转换到RRC_IDLE状态并存储当前AS上下文。它可以稍后恢复具有该上下文的RRC_CONNECTED状态。自动设置无线承载，并使用更新的密钥激活安全性。此外，可以更改AS上下文的部分内容。显然，这为不频繁的小数据分组的传输节省了相当大的信令开销。

RRC连接恢复如下图所示：

当UE被配置用于用户平面CIoT EPS优化并且配置有至少一个DRB时，可以仅应用恢复请求。 在接收到RRCConnectionResumeRequest时，eNB确定它是否接受该请求或者是否应该开始传统的RRC连接建立。 如果eNB不接受恢复请求，则切换回连接请求：

在这种情况下，UE释放存储的AS上下文，并且不再可能为稍后的连接恢复该AS上下文。

当eNB在MIB-NB中指示接入受制于接入类别限制并且广播SIB14-NB时，UE在其尝试建立之前首先在其想要连接移动发起的信令或数据时进行接入禁止检查。或恢复RRC连接。商业上可用的UE具有从0到9的访问类。在SIB14-NB中，存在关联的位图，其包含每个访问类的一个位。如果设置了与访问类关联的位，则禁止访问该单元。然后，UE必须等待SIB14-NB的更新以再次检查实际禁止状态。请注意，对于某些特殊数据，可能会跳过此访问限制检查，具体取决于SIB14-NB设置。

如果拒绝连接请求或恢复请求，例如因为不再有空闲资源，eNB会回复RRCConnectionReject。然后，UE必须等待拒绝消息提供的时间量。这样，当由于太多UE同时启动网络连接的任何原因，eNB可以防止过度干扰。如果拒绝是用于恢复过程，则eNB指示是否应当释放当前UE上下文或者进一步保存当前UE上下文以用于后续恢复请求。

4.5.2     RRC连接释放

RRC连接释放由eNB发起，如图4-7所示。

对于用户平面CIoT EPS优化，eNB可以在此指示与rrcSuspend标志的连接的暂停。 在这种情况下，UE存储AS上下文并且可以如上所述请求RRC连接恢复，否则AS上下文被删除并且UE可以仅使用完整的RRC连接建立来获得另一个RRC连接。

在该过程完成之后，UE进入RRC_IDLE状态。

4.6        UE能力转移

当UE连接到网络时，eNB既不知道UE建立在哪个版本上，也不知道其中支持的可选特征中的哪个。 为了获得此信息，定义了UE Capability Transfer procudure，如图4-8所示：

UE能力传输总是由eNB发起，因为UE不能知道eNB是否已经来自网络或来自先前会话的该信息。

这些功能包括UE构建的版本，UE类别，支持的频段列表以及建立多个承载的能力。 另外，UE可以指示其是否支持UL中的多载波操作和多音调传输。 此外，可以包含最大数量的RoHC上下文会话和支持的配置文件。该消息通常比相应的LTE消息小得多，因为省略了NB-IoT中不支持的所有LTE特征，如进一步的接入技术或载波聚合。

4.7    寻呼

寻呼用于触发RRC连接并指示用于处于RRC_IDLE模式的UE的系统信息的改变。

寻呼消息通过NPDSCH发送，并且可以包含要被寻呼的UE的列表和信息，无论寻呼是用于连接建立还是系统信息已经改变。在该列表中找到其ID的每个UE将其被寻呼的前向层转发到其上层，并且可以依次接收用于初始化RRC连接的命令。如果系统信息已经改变，则UE开始读取SIB1-NB并且可以从那里获得信息，必须再次读取哪些SIB。

处于RRC_IDLE状态的UE仅监视关于寻呼的一些SF，无线电帧子集内的寻呼时机（PO），寻呼帧（PF）。如果应用覆盖增强重复，则PO指的是重复内的第一次传输。PF和PO由SIB2-NB中提供的DRX周期和USIM卡提供的IMSI确定。DRX是用于节省电池寿命的DL控制信道的不连续接收。支持128,256,512和1024个无线电帧的周期，对应于1.28s和10.24s之间的时间间隔。

 由于确定PF和PO的算法也取决于IMSI，不同的UE具有不同的寻呼时机，其在时间上均匀分布。UE足以监视DRX周期内的一个寻呼时机，如果其中存在多个寻呼时机，则在它们中的每一个中重复寻呼。

扩展DRX（eDRX）的概念也可以应用于NB-IoT。这是使用第3.2.1章“帧和时隙结构”中概述的超帧来完成的。如果支持eDRX，则UE不监视寻呼消息的时间间隔可能会大大延长，向上差不多3小时。相应地，UE必须知道在哪个HFN以及该HFN内的哪个时间间隔，寻呼时间窗口（PTW），它必须监视寻呼。PTW由启动和停止SFN定义。在PTW内，PF和PO的确定以与未扩展DRX相同的方式完成。

5    数据传输

如第2.2.1章“核心网络”中所述，数据传输有两种方式，即控制平面CIoT EPS优化和用户平面CIoT EPS优化。 MME表示支持每个优化。 对于移动始发数据，UE可以在支持的选项中进行选择。 对于移动终止数据，MME选择优化并且可以考虑UE优先级，其在附连过程中用信号通知网络。

5.1    控制平面CIoT EPS优化

对于控制平面CIoT EPS优化，UE和eNB之间的数据交换在RRC级别完成。 在DL中，数据分组可以捎带在RRCConnectionSetup消息中或RRCConnectionSetupComplete消息中的UL中。 如果这还不够，可以使用DLInformationTransfer和ULInformationTransfer这两个消息继续数据传输：

所有这些消息中包含一个包含NAS信息的字节数组，在这种情况下，它对应于NB-IoT数据包。 因此，它对eNB是透明的，并且UE的RRC将所接收的DLInformationTransfer的内容直接转发到其上层。 在eNB和MME之间，通过S1-MME接口交换dedicatedInfoNAS。

对于此数据传输方法，不应用AS级别的安全性。 由于也没有RRC连接重新配置，它可以分别在RRC连接建立或恢复过程之后或期间立即开始。 当然，必须在RRC连接释放之后终止RRC连接。

5.2    用户平面CIoT EPS优化
在用户平面CIoT中，EPS优化数据通过网络在传统用户平面上传输，即eNB将数据转发到S-GW或从该节点接收数据。 为了保持UE复杂度低，可以同时仅配置一个或两个DRB。

必须区分两种情况：当先前的RRC连接被释放且指示可能的恢复操作时，请参见第4.5.2节“RRC连接释放”，可以请求连接作为恢复过程，如图4-5。 如果此恢复过程成功，则使用更新的密钥建立安全性，并且像在先前的连接中那样设置无线承载。 如果没有先前释放的恢复指示，或者如果eNB不接受恢复请求，则必须建立安全性和无线电承载，如下一节所示。

5.2.1    数据连接的建立和配置
建立RRC连接后，如图4-4或图4-6所示，第一步是建立AS级安全性。 这是通过初始安全激活过程完成的：

在SecurityModeCommand消息中，eNB向UE提供要应用于SRB1和DRB的加密算法，以及用于保护SRB1的完整性保护算法。 为LTE定义的所有算法也包括在NB-IoT中。 使用此消息，SRB1bis会自动更改为SRB1，SRB1用于以下控制消息。

激活安全性后，使用RRC连接重新配置过程设置DRB：

在重新配置消息中，eNB向UE提供无线承载，包括RLC和逻辑信道的配置。 后者包括用于根据实际要求平衡数据传输的优先级。 PDCP仅配置为DRB，因为SRB仅使用默认值。

在所包括的MAC配置中，提供缓冲器状态报告（BSR），调度请求（SR），时间对准和DRX的配置。 最后，物理配置提供了将数据映射到时隙和频率的必要参数。

5.2.2    多载波配置

RRCConnectionReconfiguration可以包含UL和DL中的附加载波的设置，非锚定载波。

当在DL中提供非锚定载波时，UE将接收该频率上的所有数据。这排除了仅在锚载波上接收的同步，广播信息和寻呼。可以提供指示允许的DL SF的位图。非锚定载波可以包含相当多的SF用于数据，因为它不需要同步和广播信息。

一旦配置了非锚定载波，UE就在其处于RRC_CONNECTED状态时单独监听该锚定载波。因此，UE仅需要一个接收器链。

 在UL中，同样的原则适用。如果配置了额外的UL载波，则UE仅将该一个用于数据传输，在该载波和锚载波中不存在同时传输。

对于DL和UL两者，当UE被释放到RRC_IDLE状态时，UE返回到其锚定载波。

调度示例如图5-4所示：

UE1配置有锚载波，UE2与DL和UL中的其他载波，以及UE3仅在DL上具有不同的载波。为简单起见，该图既不考虑下一节中解释的NPDCCH周期，也不考虑DL数据不允许的SF。它只能以示意图的方式解释。

即使在带内操作中，分配的DL载波也不限于表3-1中所示的值。该限制仅适用于那些发送NPSS，NSSS和NPBCH的载波，即可用作锚载波的载波。对于提供的DL频率，允许所有载波。

该结构允许推出NB-IoT宽带网络，尽管每个UE仅具有一个具有窄带宽可用的发送器/接收器链。同步，DL中广播和UL中的NPRACH资源的开销可以限于一个或视图对的载波，而其他的可以完全用于数据传输。由于接收和发送从不同时进行并且总是分别限制在一个频带，因此UE仅具有一个带宽为180kHz的发送器/接收器链就足够了。

5.2.3    接收控制信道
在RRC连接状态中，UE仅监视UE特定搜索空间（USS）以获得其UL授权和DL指派。 重新配置消息包含最大重复次数，其范围从1到2048，以2为2的幂。但是，实际重复次数可能更小，如下表所示：

对于实际重复次数小于其最大次数的情况，剩余的SF可以用于向另一个UE发送不同的NPDCCH。 例如，如果最大重复次数是4，则所有SF可以包含一个UE的DCI，或者两个SF可以分别用于两个UE中的每一个，或者每个SF用于不同的UE。 当然，UE必须监视所有这些候选者。

重配置消息还包含用于描述NPDCCH周期的参数。 关于此期间的开始，USS在开始时或在周期长度的1 / 8,1 / 4或3/8的偏移处开始。

5.2.4    传输UL数据信道
DCI格式N0指示用于在NPUSCH上传输的UL许可，包括所有相关参数。 一个传输块可以重复多次。 重复的安排取决于一个RU的子载波的数量，子载波间隔和重复的数量。 首先应该用图5-5所示的例子来说明：

对于15kHz子载波间隔的情况，在两个RU（a）上发送称为测试字（TW）的传输块，其中每个RU具有8个时隙（b）上的3个子载波的格式。总共应用8次重复。在图5-5中，Tn表示第一个RU的第n个时隙，Wm是第二个RU的第m个时隙。

在第一步骤中，发送两个时隙T1和T2。该对重复三次，因此这些插槽有4次传输。然后用接下来的两个插槽完成相同的过程。这一直持续到槽W7和W8成对传输四次。最后，由于现在有4次重复TW，传输序列再次重复，达到这种方式8次重复。

 在一般情况下，对于15kHz的子载波间隔总是进行两个时隙的第一次重复。在3.75 kHz子载波间隔上，分别为每个插槽完成。如果RU具有多于一个子载波，则第一次重复的总数是上限为4的总重复次数的一半，或者如果RU仅具有一个子载波，则为1次。在上面的例子中，这意味着如果有32次重复，序列生成将如图5-5（c）所示，但总序列将重复7次。

通常，序列映射到一组连续的槽。大量重复会发生异常。更准确地说，在256ms的传输之后，在NPUSCH传输继续之前产生40ms的间隙。该间隙是必要的，因为当UE在NPUSCH上发送时，它不能同时接收DL信道，并且可能因此失去与eNB的同步。在此间隙期间，再次微调同步。

5.2.5    接收DL数据信道
DCI格式N1指示DL分配，其描述在NPDSCH上在何处以及如何发送数据符号。其原理与UL基本相同，请参见图5-5中的示例，但数据包不会先分组到RU中。如果没有重复，则将数据分组连续映射到时隙中并在NPDSCH SF中发送。

对于存在重复的情况，映射类似于多音UL。首先将两个时隙的数据映射到一个SF，现在以总重复次数重复，再次上限为4。然后以相同的方式继续映射，直到发送所有SF。最后，重复整个结构，直到达到所需的重复次数。

当DL数据包含SIB-NB信息时有一个例外。在这种情况下，如图5-5（b）中的例子那样连续发送时隙，然后将整个块重复适当的次数。

传输间隙可以由RRC配置用于具有大量重复的NPDSCH传输。RRCConnectionReconfiguration消息可以提供重复次数有多大的信息，以便触发这种间隙，周期性和它们出现的长度。当间隙发生时，NPDSCH传输被推迟到间隙之后的下一个可用SF。这些间隙不适用于携带MIB-NB或SIB-NB信息的NPDSCH。

6    总结和展望

利用版本13中规定的NB-IoT技术，3GPP创建了一种新的蜂窝空中接口，完全适应典型机器类型通信的要求。它针对小的和不频繁的数据包进行了优化，并且避免了为此目的不需要的蜂窝功能。这样，UE可以以成本有效的方式保持并且仅需要少量的电池电力。

数据传输保持在180kHz的小频带。然而，由于多频带结构，可以使用广谱频率。信令部分可以减少到一个或仅少数NB-IoT载波，而其余的可以完全用于数据传输。这样，虽然单个UE仅具有相对窄带的发送器和接收器，但是相当大量的带宽用于数据传输。

随着第14版，NB-IoT的发展将继续[14]。根据目前的计划，NB-IoT将扩展到包括定位方法，例如所需的多播服务。用于软件更新或有关整个组的消息，移动性和服务连续性，以及用于增强NB-IoT技术应用领域的进一步技术细节。

7     参考文献

[1] 3GPP TR 45.820 V13.1.0, November 2015; Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT)

[2] 3GPP TS 23.272 V13.3.0, March 2016; Circuit Switched (CS) fallback in Evolved Packet System (EPS)

[3] 3GPP TS 23.401 V13.6.1, March 2016; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network

[4] 3GPP TS 23.682 V13.5.0, March 2016; Architecture enhancements to facilitate communications with packet data networks and applications

[5] 3GPP TS 36.331 V13.2.0, June 2016; Radio Resource Control (RRC); Protocol specification

[6] 3GPP TS 36.300 V13.4.0, June 2016; Overall description

[7] 3GPP TS 36.101 V13.4.0, June 2016; User Equipment (UE) radio transmission and reception

[8] 3GPP TS 36.201 V13.2.0, June 2016; LTE physical layer; General description

[9] 3GPP TS 36.211 V13.2.0, June 2016; Physical channels and modulation

[10] 3GPP TS 36.212 V13.2.0, June 2016; Multiplexing and channel coding

[11] 3GPP TS 36.213 V13.2.0, June 2016; Physical layer procedures

[12] 3GPP TS 36.304 V13.2.0, June 2016; User Equipment (UE) procedures in idle mode

[13] 3GPP TS 36.321 V13.2.0, June 2016; Medium Access Control (MAC) protocol specification 

[14] 3GPP RP-161324 3GPP Work Item Description Enhancements of NB-IoT