企业物联网架构师花费大量时间评估硬件和连接技术，却较少花时间规划决定设备、网络和平台之间通信方式的协议栈。 这种失衡往往会在部署后以集成问题的方式显现：设备无法向平台进行身份验证；数据以头端无法解析的格式到达；由于未根据设备可用内存对 OTA 传输协议进行验证，导致固件更新失败；以及因各层之间协议不匹配而产生的安全漏洞。
物联网协议栈是一套分层的标准体系，每一层都规范了数据从物理传感器传输到应用程序过程中的不同方面。每一层的选择既会限制也会影响相邻层的选择，而这些选择之间的相互作用决定了整个协议栈是作为一个协调一致的系统运行，还是作为一组各自经过验证的组件运行——后者会在接口处产生摩擦。
本文从物理连接层开始，逐层剖析物联网协议栈直至应用层，涵盖了与企业部署相关的标准、各层的权衡取舍，以及决定该协议栈能否在大规模部署中保持稳定性的集成考量因素。
物理层和接入层：蜂窝通信标准
物理层和接入层决定了设备如何与网络建立无线连接。对于企业物联网而言，有必要厘清相关蜂窝通信标准及其相互间的定位关系，因为围绕这些技术的营销术语往往不够精准，这可能会影响部署决策。
NB-IoT （窄带物联网、3GPP Release 13 及后续版本） 在授权频谱内的180kHz信道中运行，既可在LTE 载波的带内工作，也可在LTE 保护带中工作，或以独立部署方式在重新规划的GSM 频谱上工作。关键物理层特性：
- 最大下行吞吐量：在单音模式下约为 250 kbps
- 最大上行吞吐量：约250kbps
- 链路预算：最大耦合损耗为164dBm，比GPRS
- 延迟：典型数据传输（包括建立连接）的延迟为1.6至10秒，因此不适用于需要亚秒级响应的应用
- 双工模式：仅支持半双工
LTE-M（LTE-MTC、Cat-M1、3GPP Release 13） 在LTE 频谱内的1.4MHz信道中运行，并支持全双工通信。关键物理层特性：
- 最大下行吞吐量：约1Mbps
- 最大上行吞吐量：约1Mbps
- 链路预算：最大耦合损耗为155.7dBm，比GPRS
- 延迟：建立连接后，数据传输延迟为10至15毫秒
- 全双工模式：支持全双工，可实现语音和双向实时数据传输
5G 物联网（IoT）的NR 引入了两类相关设备：RedCap（功能缩减版，3GPP Release 17），面向需要比LTE-M更高吞吐量、但比全功能5G NR UE更低功耗的中端物联网设备；以及适用于高带宽物联网应用的标准5G NR。 RedCap的目标吞吐量为5至25Mbps，与完整的5G NR相比，其功耗和复杂度均有所降低，填补了LTE-M与完整的5G 之间的空白——这一空白历史上一直由4G Cat-4设备占据。
物理层的选择决定了其上方每一层的上限和下限。如果基于NB-IoT 设计用于亚秒级双向通信的协议栈，在应用层协议尚无机会发挥作用之前，就会在物理层出现故障。
网络层：物联网的IP地址分配与路由
大多数企业物联网设备通过 IPv4 或 IPv6 进行通信，但决定这些地址如何分配和管理的网络层配置会产生一些运营影响，而这些影响在物理层规范中并未体现。
私有APN 架构 是面向具有数据安全或合规要求的企业物联网部署的标准网络层配置。私有APN 不会将设备流量通过运营商的共享公共APN路由至公共互联网，而是从设备到企业的后端基础设施建立一条专用的网络路径。私有APN 上的流量不会经过公共互联网，这对于以下方面至关重要：
- 在数据不得离开企业网络边界的相关垂直领域中遵守监管合规要求
- 攻击面缩小，因为无法从公共互联网直接访问这些设备
- 确定性路由，因为私有APN 流量遵循预定义的网络路径，而非公共互联网路由
物联网中的IPv6 之所以重要，是因为IPv4地址耗尽使得大规模物联网部署难以实现逐个设备的单独寻址。例如，部署一百万台智能电表，每台都需要一个可路由的IP地址以供头端发起通信，这将面临实际的IPv4地址分配限制，而IPv6则消除了这一限制。此外，在设备需要无需通过NAT即可单独可达的架构中，IPv6还简化了端到端的寻址过程。
CGNAT 注意事项 当运营商级NAT位于设备与企业后端之间时，会影响部署——这正是大多数面向消费者的标准物联网资费套餐的默认配置。CGNAT会阻止发往设备的入站连接，这意味着任何需要由头端发起与单个设备通信的架构，都必须采用私有APN 、始终保持连接的设备发起连接，或者由设备与后端平台维持持久会话。 在设计阶段未考虑 CGNAT 的架构师，往往会在集成测试阶段才发现这一问题，届时采取补救措施的成本将更高。
传输层：物联网数据传输的协议选择
传输层负责管理数据在设备与平台之间如何被封装，以及如何可靠地（或有意地不可靠地）传输。企业物联网中主流的传输协议各自在不同方面进行了权衡，以适应不同的应用场景。
MQTT（消息队列遥测传输） 是目前部署最广泛的、用于蜂窝网络连接设备的物联网传输协议。其发布-订阅架构、轻量级开销（最小2字节的固定报头）以及对三种QoS级别的支持，使其非常适合资源受限的设备在可能不可靠的连接上频繁传输小数据包：
- QoS 0（至多一次）：发送即忘，无需确认，开销最低
- QoS 1（至少一次）：保证送达并返回确认，可能出现重复
- QoS 2（仅一次）：保证单次交付，开销最大
MQTT 的持久会话功能允许设备在连接中断后重新建立连接，并接收在离线期间由消息代理排入队列的消息，这对在 PSM 中周期性无法联系的NB-IoT 设备而言至关重要。
CoAP（受限应用协议） 专为资源最为受限的设备设计，在这些设备上，MQTT对TCP的要求会产生无法接受的开销。CoAP运行于UDP 之上，采用与HTTP类似的请求-响应模型，但具有针对受限环境优化的二进制报头，并支持“观察”功能以实现类似发布-订阅的行为。对于NB-IoT 设备而言，由于TCP连接管理的开销会显著影响功耗预算，因此CoAP是理想的传输协议选择。
AMQP（高级消息队列协议） 主要应用于后端集成层，而非设备到云端层。其更丰富的消息路由功能、对事务的支持以及与企业级消息代理的兼容性，使其成为连接物联网平台与企业后端系统的标准传输协议：这些后端系统包括ERP、资产管理以及运营技术平台，它们通常需要支持AMQP的消息代理。
HTTPS/REST 对于具备充足计算资源的物联网设备而言，HTTPS/仍具有重要意义，且当REST API 集成方式的简便性超过HTTP的开销时，其优势尤为突出。高端物联网网关、边缘计算节点以及具备4G或5G 连接能力的设备通常采用REST 进行平台集成，特别是在那些负责管理后端集成的运维团队更熟悉WebAPI 模式，而非MQTT代理配置的部署场景中。
安全层：身份验证和Encryption 标准
物联网中安全协议的选择因边缘设备的计算和内存限制而变得复杂，这使得企业IT环境中通用的安全协议在资源受限的硬件上难以实施，甚至无法实施。
TLS 1.2 和 TLS 1.3 是计算资源充足的物联网设备的标准加密协议。 与 TLS 1.2 相比，TLS 1.3 通过在握手序列中省去一次往返通信，从而降低了握手延迟，这对NB-IoT 和LTE-M 设备尤为重要，因为这些设备每次无线电传输都会产生可测量的功耗。TLS 中的密码套件选择对物联网至关重要：在平衡安全性与计算效率的物联网部署中，推荐采用 ECDHE 密钥交换和 AES-128-GCM 的组合。
DTLS（数据报 TLS） 是 CoAP 部署的合适安全协议，为基于UDP 的传输提供了与 TLS 相当的安全保障。
基于 X.509 证书的相互身份验证 是企业级大规模物联网部署中推荐采用的设备认证机制。预共享密钥虽然更易于实现，但在设备数量庞大的情况下会引发密钥管理问题：若需在数百万台已部署设备上轮换已被破解的预共享密钥，将导致运维负担过重。而带有独立设备标识的 X.509 证书，允许对单个设备进行证书轮换和吊销，且不会影响设备群中的其他设备。
硬件安全模块（HSM）和可信执行环境（TEE） 对于处理敏感数据或在存在未经授权方物理访问设备风险的企业物联网设备而言，其重要性日益凸显。将私钥存储在受硬件保护的元件中而非固件内存中，即使设备固件遭到破坏，也能防止密钥被提取。
在部署之前，必须对安全协议栈进行端到端的验证。如果某台设备虽然正确实现了 TLS，但连接到一个未强制执行双向身份验证的平台端点，那么其安全架构就只是不完整的。物联网中的安全验证必须覆盖从设备到平台的整个握手路径，包括网络层（私有APN ）、传输层（TLS 配置）和应用层（身份验证令牌处理和会话管理）。
数据格式和Device Management 协议
应用层是协议决策对平台集成复杂性产生最直接影响的地方。
LwM2M（轻量级M2M，OMA SpecWorks） 是一种专为物联网设计的设备管理协议，在单一协议框架内涵盖了设备注册、固件 OTA 更新分发、远程配置以及遥测报告等功能。其数据模型采用标准化的对象和资源层次结构，使设备管理平台能够与任何符合 LwM2M 标准的设备进行交互，而无需进行针对特定设备的集成工作。 对于需要管理大规模异构设备群的企业部署而言，LwM2M 的标准化管理模型可显著降低向设备群中添加新设备类型时的集成开销。
FOTA（空中固件更新）协议的考虑因素 在应用层，这些考虑因素在部署设计阶段往往未被充分规定。物联网设备的固件更新包大小可能从数十千字节到数兆字节不等。FOTA协议需要考虑以下方面：
- 中断的传输恢复，因为NB-IoT 或LTE-M设备在固件下载过程中可能会失去连接
- 支持增量更新，仅传输已更改的固件段而非完整镜像，从而减少传输量并降低功耗
- 如果新固件在设备上验证失败，则具备回滚功能
数据序列化格式 应用层的选择会影响传输效率和平台集成的复杂度。JSON 虽被广泛支持且易于人类阅读，但对于资源受限的设备而言，与二进制格式相比存在显著的开销。CBOR（简洁二进制对象表示法）在二进制编码中提供了与 JSON 相当的表达能力，通常可将有效载荷大小缩减 50% 至 70%。 对于高频传输或功耗预算紧张的NB-IoT 设备而言，CBOR相较于JSON带来的有效载荷减少，可直接转化为更长的电池续航时间和更低的数据成本。
企业级协议栈一致性
上述协议栈的决策并非独立运作。如果一个部署方案在物理层选择NB-IoT ，在传输层选择基于TCP的MQTT，在安全层选择带完整握手过程的TLS 1.2，那么所构建的协议栈中，传输层和安全层的开销可能会占据设备功耗预算的大部分，从而削弱了最初选择NB-IoT 所基于的能效考量。 对于功耗受限的NB-IoT 设备，采用基于UDP 并结合DTLS的CoAP协议栈更为合理；而对于功耗预算更为充裕的LTE-M设备，基于TCP并结合TLS的MQTT协议栈则是更合适的选择。
协议栈的一致性对于连接基础设施也至关重要。在一种部署方案中，设备通过采用静态IP地址的私有APN 连接，利用MQTT与云代理通信，并采用X.509双向认证；这种部署方案对连接管理平台提出了具体要求：私有APN 的配置、静态IP地址的分配，以及与设备身份基础设施集成的证书生命周期管理。
KORE的连接基础设施为企业协议栈提供了网络层基础，包括私有APN 配置、静态IP分配，以及覆盖40多家运营商合作伙伴和200多个国家的多运营商连接服务。ConnectivityPro 平台提供SIM卡生命周期管理和网络策略控制功能，这些功能管理着部署所运行的任何应用协议栈底层的连接层。该基础设施已在各垂直领域部署了2100多万张活跃SIM卡，在这些领域中，协议栈的一致性直接影响运营结果；该基础设施旨在支持生产环境部署所需的各种企业物联网连接配置。
要正确构建协议栈，必须结合相邻层的情况对每一层进行评估，并在大规模部署到硬件之前，对整个协议栈进行端到端的验证。由协议不匹配引发的集成问题是可以解决的，但在测试台上解决这些问题的成本远低于在实际环境中解决。
请与KORE 连接工程师沟通，了解您所使用的物联网协议栈在网络层的基础设施要求。
发布于2026年5月29日。