静态上下文头部压缩（SCHC）和蜂窝物联网

本文翻译自以下论文的第3部分。Applied Sciences | Free Full-Text | Enabling Extremely Energy-Efficient End-to-End Secure Communications for Smart Metering Internet of Things Applications Using Static Context Header Compression (mdpi.com)https://www.mdpi.com/2076-3417/13/21/11921

3. 技术背景：SCHC和蜂窝物联网

3.1. NB-IoT

NB-IoT（窄带物联网）是由第三代合作伙伴计划（3GPP）标准化的一种LPWAN（低功耗广域网）技术，用于连接物联网应用[33]。它重用了LTE设计，通过简化其信道和信号的复杂性来适应受限的设备[34]。NB-IoT设计为占用180 kHz的频带宽度（LTE系统中的一个资源块），并处理重复传输以实现长距离和深层室内通信[35]。尽管NB-IoT比LTE简单，但数据可以通过具有不同特性的不同路径发送，包括带宽、确认和可靠性[36]。实际上，NB-IoT允许通过IP和非IP（NIDD）进行通信。有关NB-IoT的更多信息，请参考[35]及其中的参考文献。

3.2. SCHC框架

静态上下文头部压缩和分段（SCHC）是一个通用框架，提供压缩和分段机制。该框架在[37]中标准化，考虑到了受限环境和受限设备，这些通常在LPWAN中发现。图1显示了SCHC架构。在发送端，协议分析器解析数据包，逐项标记并标记每个字段，并提取其值。协议分析器应该能够使用适配的协议栈工作（例如，DLMS/UDP/IP）。然而，SCHC标准没有指定它的实现方式，而是留给了实现者。一旦识别出协议的字段（及其值），它们就与存储的压缩规则匹配。相同的压缩规则也提前存储在发送端和接收端。然后，如果数据包匹配存储的规则之一，则对数据包进行压缩。否则，将其以未压缩的形式发送。这些操作的结果是所谓的SCHC数据包。如果SCHC数据包大于L2层支持的最大传输单元（MTU），则应用分段。图2显示了应用于数据包的压缩和分段机制。如图所示，头部压缩产生了规则标识符（RuleID）和压缩残余。如果需要，分段会向SCHC数据包的块添加自己的头部以形成片段。SCHC基于使用一组预先定义的规则来进行通信。它们描述了压缩或解压缩头部或结构化数据的上下文。由于LPWAN数据包的内容通常高度可预测，因此可以派生并存储静态上下文。实际上，上下文必须提前在发送方（压缩器）和接收方（解压缩器）中存储。注意，上下文的配置和共享方式尚未标准化。图1. SCHC架构。

图2. 发送端执行的操作。

一旦通信双方共享了上下文，发送方就会传输规则标识符（RuleID），该标识符描述了用于压缩数据包的规则，然后是压缩残余，即压缩后剩余的比特。每个规则包含一个字段描述符列表，包括：

• 字段标识符（FID），指明协议和字段，如UDP目标端口。
• 字段长度（FL），表示字段的长度。长度可以是固定的或可变的。
• 字段位置（FP），表示字段的出现次数。大多数情况下，字段在数据包头部只出现一次。然而，有些字段可能会多次出现，例如在CoAP中。
• 方向指示器（DI），指示数据包的方向。
• 目标值（TV），用于与字段匹配的值。TV可以是任何类型的标量值，或者是更复杂的结构，如数组。
• 匹配操作符（MO），用于匹配字段值和TV。
• 压缩/解压缩操作（CDA），描述在压缩器中压缩字段和在解压缩器中恢复字段原始值的操作。

表2展示了一个压缩IPv6/UDP头部的规则示例。表中显示了IPv6和UDP头部的字段及其对应的字段描述符，包括字段标识符（FID）、字段长度（FL）、字段位置（FP）、方向指示器（DI）、目标值（TV）、匹配操作符（MO）和压缩/解压缩操作（CDA）。在这个示例中，压缩规则是为设备（Dev）和应用程序（App）之间的数据包设计的，这些数据包具有全局IPv6地址前缀（alpha::IID/64到gamma::1/64）。虽然一些字段具有静态值，如IPv6版本，但一些字段的值可以忽略，如IPv6长度。因此，这些值在发送端可以省略（不发送），并在接收端通过压缩规则或计算恢复。还重要的是规则需要指定方向（上行、下行或双向）。有关SCHC压缩的更详细信息，请参考RFC 8724 [37]。

在通信的另一端，接收方使用接收到的RuleID来识别压缩中使用的规则。通过使用这个规则和压缩残余，恢复原始数据包。注意，压缩器和解压缩器可以共享多个规则，以考虑多种数据包类型。SCHC可以用于压缩UDP和IP协议以及上层协议，如CoAP [38]和DLMS [39]。上层的压缩可以与其他层一起执行，即使用相同的规则，或者独立执行。当使用加密算法保护上层负载时，独立压缩上层变得至关重要。在这种情况下，可以使用多个SCHC层。

表2. IPv6/UDP压缩规则示例。Dev：设备；App：应用程序；Bi：双向；Up：上行；Dw：下行；MSB：最高有效字节；LSB：最低有效字节 [37]。

FID	FL (bits)	FP	DI	TV	MO	CDA
IPv6 Version	4	1	Bi	6	equal	not sent
IPv6 Diffserv	8	1	Bi	0	equal	not sent
IPv6 Flow Label	20	1	Bi	0	equal	not sent
IPv6 Length	16	1	Bi	_	ignore	compute
IPv6 Next Header	8	1	Bi	17	equal	not sent
IPv6 Hop Limit	8	1	Up	255	ignore	not sent
IPv6 Hop Limit	8	1	Dw	_	ignore	value-sent
IPv6 DevPrefix	64	1	Bi	alpha/64	equal	not sent
IPv6 DevIID	64	1	Bi	_	ignore	DevIID
IPv6 AppPrefix	64	1	Bi	gamma/64	equal	not sent
IPv6 AppIID	64	1	Bi	::1000	equal	not sent
UDP DevPort	16	1	Bi	8720	MSB(12) LSB
UDP AppPort	16	1	Bi	8720	MSB(12) LSB
UDP Length	16	1	Bi	_	ignore	compute
UDP checksum	16	1	Bi	_	ignore	compute

3.3. SCHC在NB-IoT上的应用

RFC 9391[31]定义了SCHC在NB-IoT上的三种可能用例。

在第一种用例中，SCHC在无线电链路上使用。这将需要将SCHC作为数据传输的协议栈的一部分，在终端设备和基站（即eNB）上放置。3GPP架构已经支持Robust Header Compression (ROHC)[40]。因此，SCHC可以在不需要重大更改的情况下部署在类似的架构中。

第二种用例建议SCHC在非接入层（NAS）上使用。在NB-IoT中，终端设备可以使用预先建立的安全性，并将小的上行数据插入初始上行消息中。这种传输称为非接入层数据（DoNAS）或控制平面CIoT EPS优化。与第一种用例相反，SCHC位于非接入层（NAS）协议层中。从网络的角度来看，SCHC将在网络的核心（移动性管理实体）中实现，而不是像第一种用例中的eNB（基站）。

第三种用例中，SCHC功能在设备的应用层和应用服务器或网络边缘的代理功能中实现。数据包在分组网关和应用服务器之间或在服务能力暴露功能（SCEF）和应用服务器之间传输，使用IP隧道或API调用。有关SCEF和API架构的更多信息可以在第4.4节中找到。在这两种情况下，在传输之前应用压缩。网络将像处理普通流量一样处理数据包，将其传递到另一端，而不需要任何特殊操作。这种用例特别有趣，将在本研究中予以考虑，因为它不需要对现有的3GPP规范进行任何更改，并且可以通过在非IP数据传输（NIDD）上启用IP地址，提供额外的互操作性层级。

SCHC作为设备级别的软件实现，不需要在硬件或组件方面进行额外投资。在网络方面，在网络边缘需要一个SCHC服务器，这仍然不需要改变现有的部署或规格。