NB-IoT 接入 5G 核心网丨边缘计算阅读周

#边缘计算阅读周# 

读书的人，有梦可做。

边缘计算社区联合6大出版社邀您一起阅读，一起做追梦人。

在近日结束的ITU-R WP5D#35会议上，3GPP技术正式被接受为ITU IMT-2020 5G技术标准。

此次通过的3GPP技术包含中国提交的3GPP NR + NB-IoT RIT，3GPP 提交的NR+LTE SRIT和NR RIT，以及韩国提交的3GPP NR RIT。这4个5G技术提交是等同的，并且都融合成3GPP技术，统一进入5G技术标准。

NB-IoT与NR一起成为ITU IMT-2020 5G技术标准，意味着NB-IoT正式成为5G mMTC场景的核心组成部分。

那NB-IoT是什么？

NB-loT属于一种低功耗广域网技术，它具备低成本、强覆盖、低功耗、大连接4个关键特点。从2016年首个NB-IoT标准发布以来，NB-IoT产业发展极为迅速。仅仅用了三年时间，NB-IoT已在全球50多个国家大规模商用。

NB-IoT将成为5G物联网的主流技术。

边缘计算社区今天要推荐一下人民邮电出版社7月份新推出的新书《窄带物联网(NB-IoT)标准协议的演进》，这可能是市面上介绍NB-loT最详细的一本书了。

由于NB-loT和5G息息相关，我们从书里摘选了NB-loT接入5G核心网部分内容。阅读一下，文末有惊喜。

与支持 LTE 接入5G核心网（5GC，5G Core）的需求类似，为进一步支持 NB-IoT 演进，Rel-16 中也包含了接入 5GC 的立项目标。最初的立项目标比较简单，但随着讨论深入，大部分 eLTE 讨论过的功能都在NB-IoT 中进行了讨论。

数据传输方案

最基本的，NB-IoT接入EPC支持CP优化和UP优化，其中，CP优化通过信令传输用户数据，UP 优化提供简化方式在UP传输用户数据。在讨论接入5GC 之初，有一致共识：

为保持终端省电的益处，NB-IoT 终端接入5GC仍然需要支持CP优化。但对用户面数据传输方案则有很多争议。对于 LTE 接入 5GC，即eLTE，UP数据传输方案基于新引入的 RRC_INACTIVE 态。因此对于NB-IoT接入5GC，首先要讨论是继续支持UP优化还是同样引入RRC_INACTIVE 态。

部分终端公司和运营商认为，Rel-16 终端需要达到与 Rel-13 相同的节能目标，目前 RRC_INACTIVE 尚不支持更长的 eDRX 周期，支持UP 优化是唯一可以保证终端节能目标的方案，此外要求 NB-IoT支持 UP 优化和 RRC_INACTIVE 两种 UP 方案，会增加终端复杂度和成本。而另一些公司则认为RRC_INACTIVE如果能够支持更长的eDRX周期，同样可以满足UE的节能要求。从 5GC 的标准以及 Ng 接口标准来看，已经支持 RRC_INACTIVE，因此该方案对核心网标准影 响最小。而对于终端复杂度，考虑到支持接入 5GC 需要支持一些新的 NAS 功能和安全机制，支 持 RRC_INACTIVE而增加的复杂度 / 成本可能仅占总体增加的复杂度 / 成本的一小部分。

支持 RRC_INACTIVE 还有如下好处。首先，RRC_INACTIVE 对频繁数据传输有优势。可以预期 Rel-16 NB-IoT 会支持更多样的应用，一旦 NB-IoT 终端在接入 5GC 时具有频繁数据传输的用例，RRC_INACTIVE 就可以成为常用的解决方案，仅需要为那些具有不频繁数据传输的终端配置更长的eDRX 周期来达到省电目的。但如果仅支持 UP 优化，对于那些具有频繁数据传输业务的终端，就只能容忍连接被频繁挂起和恢复，这将导致更多的信令开销以及终端功耗。

其次，Rel-15 NB-IoT 已支持 MO-EDT，Rel-16 即将支持 MT-EDT 和 PUR 功能，对于接入 5GC 的终端，如果能够支持 RRC_INACTIVE，那么可以仅释放空口连接而维持 Ng 接口，在下一次执行 EDT 或 PUR 传输时，仅需要恢复空中接口而避免 EPC 中恢复 S1接口的流程，数据可以直接通过激活的 Ng 接口在核心网和基站间传递，这样可以进一步缩短 EDT 或 PUR 流程并有助于终端节电。

但是讨论中也提到，支持 RRC_INACTIVE 态并支持更长 eDRX 周期，对核心网可能存在如下潜在影响。首先，终端在 RRC_INACTIVE 态下需要同时监听网络侧和 RAN 侧寻呼，为了最小化监听寻呼的功耗，需要在核心网和 RAN 寻呼之间对齐 PTW。因此，Ng 接口需要增强，以便核心网将所有 UE 特定寻呼周期参数传递给基站。其次，在配置较长 eDRX 周期的情况下，到达核心网的数据只能在特定窗口发送给终端，且这些窗口之间的间隔可能很大，此时可能需要 5GC 或基站支持较长时间缓存。

当然如果可以假设具有较长 eDRX 周期的 UE 通常很少进行频繁数据传输，缓存造成的问题也不会太大。最后，对核心网还有一个担心是为支持 RRC_INACTIVE 态的大量 IoT 设备维持激活的 Ng 接口会造成较大开销，但从实现角度来看，如果数据传输不频繁且设备移动性较低，维持激活的 Ng 接口及 N3 接口的开销主要在保持 AS 上下文，这种开销可能也不会明显大于支持 UP 优化造成的开销。

经过多轮讨论，最终决定对 Rel-16 NB-IoT 接入 5GC 仅支持 UP 优化的用户面数据传输方案，不支持新的 RRC_INACTIVE 态。之后，有公司提出可以参考 eLTE，采用 I-RNTI 作为恢复 ID，不再使用原有接入 EPC所使用的 Resume ID。主要有以下两个原因：

① Resume ID 长度为 40bit，其中，基站 ID 和终端 ID 两个部分的长度均为固定的 20bit，I-RNTI 则支持灵活的基站 ID 和终端 ID 的长度分配。

② 如果终端在同一个基站挂起和恢复连接，无论使用 Resume ID 或 I-RNTI 都不会造成问题，但是在移动场景下，且在特殊的旧基站和新基站都是既连接接入 5GC 的邻区，也连接接入 EPC 的邻区的场景下，使用 Resume ID 可能会存在问题。

详细来说，接入 5GC 的终端在A 基站挂起连接，此后在 B 基站尝试恢复连接。如果终端发送RRCConnectionResumeRequest消息给 B 基站且包含 Resume ID，即便 B 基站可以根据 Resume ID 中的基站 ID 识别出 A 基站，但 B 基站无法判定应该使用 Xn 接口恢复流程还是 X2 接口恢复流程去向 A 基站恢复终端上下文。如果 B 基站盲目选择 X2 接口流程去向 A 基站恢复终端上下文，A 基站也可以通过 Resume ID 查找到唯一的终端上下文，并通过 X2 接口带给 B 基站，但因为该终端原本在 A 基站是接入 5GC 的，其上下文是接入 5GC 的存储结构（但是用 Resume ID 来标识这种新结构的上下文），B 基站如果按照 X2 接口上下文响应消息的结构来解析，会导致上下文解析错误。

针对该问题，一个可能的方案是在 RRCConnectionResumeRequest 消息中携带一个额外的指示，向新基站指示终端虽然使用传统的 RRCConnectionResumeRequest 消息且包含传统的 Resume ID，但要向一个接入 5GC 的邻区恢复接入 5GC 存储结构的上下文，这样新基站就会触发正确的 Xn 接口流程。但是如果采纳该方案，eMTC 也需要采用相同的方案，但 eMTC 的 RRCConnectionResumeRequest 消息只剩余一个保留比特，大部分公司反对使用该比特用作上述区分需求，相应的，对 NB-IoT 也反对使用该方案。那么在传统的RRCConnectionResumeRequest 消息中使用新的 I-RNTI 就是比较容易达成一致的区分方式。

虽然在传统的 RRCConnectionResumeRequest 消息中使用新的 I-RNTI 可以解决上述问题并有灵活设定基站 ID 和终端 ID 长度的好处，但部分公司担心对现有标准中 UP 优化涉及的诸多流程有较大改动，而且 I-RNTI 主要用于 RRC_Inactive 态，并且还用于终端监听 RAN 区域寻呼，一旦引入该新标识，还需澄清 I-RNTI 不用于终端的寻呼监听。因此该方案也存在一定复杂度。

多轮讨论后RAN2 最终同意终端接入 5GC 时，在 RRCConnectionResumeRequest消息中使用 I-RNTI 作为恢复 ID。

具体的，终端和基站必选支持接入 5GC 的 CP 优化，可选支持 UP 优化，可选支持单独的 N3 用户数据传输。与接入 EPC 类似，基站需要通过开销消息指示其可选能力，即在SIB1-NB 中可选包含 up-CIoT-5GS-Optimisation 指示和 ng-U-DataTransfer 指示，这两个指示按 PLMN 配置。终端无须能力上报，但需要在 Msg5 RRCConnectionSetupComplete-NB 中包含 up-CIoT-5GS-Optimisation 和 ng-U-DataTransfer 字段，用于指示其对 UP 优化和 N3 数据传输的支持。空闲态使用 UP 优化的终端如果选择了不同的核心网类型，例如，从接入 EPC 的小区重选到接入 5GC 的小区，终端需要丢弃其 AS 层上下文和终端标识。

此外，对于 UP 优化，与接入 EPC 中传统的 UP 优化方案不同，接入 5GC 的 UP 优化采用与 eLTE 以及 MO-EDT 类似的在发送 Msg3 之前就提前激活 AS 安全的机制，相应的，基站需要在上次连接释放时将 NCC 参数发送给使用 UP 优化方案的终端。与之相关的还需考虑 DRB 何时恢复的问题。在 EDT 中，由于 Msg3 中就需要携带数据，很自然的，需要在发送 Msg3 之前激活安全的同时就提前恢复 DRB。

但对于接入5GC，不存在 Msg3/Msg4 携带数据的需求，因此提前恢复 DRB 的必要性不大。其次如果允许提前恢复 DRB，若终端是在一个新小区恢复连接（非连接挂起的小区），则新小区无法在接收 Msg3 时获知 DRB 是否在继续使用 ROHC 配置，会造成问题。

在 R15 UP MO-EDT 流程中就存在这个问题，为此引入限制，要求终端只有在相同小区恢复时才能应用继续使用 ROHC 的配置，只要终端在其他小区恢复连接，总需要重置 ROHC 协议。由此可见，支持 DRB 提前恢复必要性不大还会带来额外的复杂度，因此 RAN2 最后同意对于接入 5GC 且非 EDT 的场景，终端在收到 Msg4 的RRCConnectionResume-NB 消息之后再恢复 DRB。

另外，对 CP 优化和 UP 优化支持 Rel-15 中引入的 MO-EDT 功能。与接入 EPC 类似，基站需要在 SIB2-NB 中引入 cp-EDT-5GC 和 up-EDT-5GC 字段分别指示基站支持 CP-EDT 和 UP-EDT 优化。终端在能力上报中仅需要上报 earlyData-UP-5GC 来指示其对 UP-EDT 的支持。基站配置的 Rel-15 EDT PRACH 配置参数可以对接入 EPC 和接入 5GC 公用。

对 CP-EDT，对现有 EDT Msg3 进行关键扩展得到新的用于接入 5GC 的 EDT Msg3 RRCEarlyDataRequestNB 消息，并包含新的 48bit 的 5G S-TMSI，引入新的连接建立原因 mo-Data和mo-Exception Data，但不再支持 delayTolerantAccess 建立或恢复原因。

本文未经许可，不得转载

以上内容节选自人民邮电出版社的7月份新书《窄带物联网(NB-IoT)标准协议的演进:从R13到R16的5G物联网之路》，本书作者团队都是业界资深人士。

陆婷，华南理工大学博士毕业，2003年到今就职于中兴通讯。历任软件工程师、标准总监、技术预研专家等，牵头NB-IoT/eMTC多个版本的关键技术研究及高层标准制定工作。已申请发明专利数十项，参与5G国际标准总体方案等多个科技重大专项。 

方惠英，浙江大学硕士毕业，2003年到今在中兴通讯从事无线通信研发和技术研究工作。参加IEEE和3GPP等标准化组织工作13年，近年来主要负责3GPP NB-IoT和MTC等物联网相关课题的标准化工作，曾担任3GPP RAN1 MTC演进课题的联合报告人。 

袁弋非，国家特聘专家，清华大学本科和硕士毕业，美国卡内基-梅隆大学博士毕业，曾就职于朗讯贝尔实验室（Bell Labs）。2008年起在中兴通讯负责4G和5G移动通信关键技术研究和标准化。2020年1月调到中国移动研究院任&席专家，负责6G前沿技术研究。

戴博，哈尔滨工业大学硕士毕业，2006年到今在中兴通讯从事无线标准技术研究工作，参与了所有LTE版本的物理层标准制定和5G标准技术预研，近年来主要负责物联网标准技术研究工作和6G技术预研。 

沙秀斌，西南交通大学硕士毕业， 2001年到今就职于中兴通讯，先后从事CDMA产品的软件开发，WCDMA、TD-SCDMA、LTE产品的无线算法设计、仿真、外场测试以及NB-IoT的标准技术预研。

简单看了一下部分内容，这本书非常干，想了解NB-IoT的话，推荐购买此书。

新书上市，京东目前打五折，点击阅读原文即可购买。

新书上市一般是不赠送的，但是边缘计算社区经过耐心沟通。

还是从 人民邮电出版社 争取到5本做福利，赠送给大家。

在本文下方留言，分享您对NB-IoT的看法或者见解（不少于20字），评选5个精彩留言，送价值129元的《窄带物联网(NB-IoT)标准协议的演进:从R13到R16的5G物联网之路》一本。（全国包邮，一周发货）

活动时间截止到7月12日晚上6：30.

读书的人，有梦可做。边缘计算阅读周，一起做追梦人。

再次感谢 人民邮电出版社 对边缘计算社区的大力支持！