4.1 主流IoT通信技术概览
4.1.1 窄带物联网（NB-IoT）技术特点与应用场景
想象一个场景：市政部门需要监控全市几十万个智能水表。水表深埋在楼栋管井甚至地下室里，远程抄表系统必须能穿透多层混凝土，并且让设备靠电池运行数年。传统蜂窝网络？覆盖不到井盖以下，模组功耗高、价格贵。通信业的解决思路很直接：从常规蜂窝频谱中切出一段极窄的带宽，然后专门为这类“报个数字就睡”的设备设计一套空中协议。这条技术路线最终演化为窄带物联网（Narrowband IoT, NB-IoT）。
NB-IoT 是 3GPP 在早期版本中定义的 LPWA（Low-Power Wide-Area，低功耗广域网）蜂窝技术，与 eMTC（enhanced Machine-Type Communication，增强型机器类通信）共同构成移动运营商面向海量物联网终端的标准承载方案。它运行在授权频段，因此在网络可靠性、安全性和服务质量保障方面具备天然优势——这一点，工作在非授权频谱的替代方案（如 LoRa）在同等监管条件下无法直接复制。芯片和模组厂商在后续版本中发布了 Cat-NB2（Category NB2）产品，通过改进上行资源分配和调制方式，将峰值速率提升到更高水平，同时保持了向后兼容。
NB-IoT 在设计上两个最突出的工程指标是覆盖增强和超低功耗。3GPP 标准定义了若干覆盖等级（CE level），依次增加下行重复传输次数。通过重复发送，系统能将链路预算提升到足以穿透地下室甚至密封井盖的水平——代价是占用更长的空中时间和更低的峰值速率。一个典型的测量场景：一个位于地下二层的智能水表，在高覆盖等级下发送一个 200 字节的小数据包，基站需要接收数次重复后才能成功解码，单次传输的空口时间可能从几十毫秒延长到几百毫秒。
终端的省电依赖两个互补的机制：
- 省电模式（Power Saving Mode, PSM）：设备上报数据后立即进入深度休眠，核心网仍保留其会话上下文和 IP 地址；待设备按预设定时器或外部触发唤醒，直接恢复连接，无需重新附着网络。PSM 的休眠时长可以显著延长。
- 扩展不连续接收（Extended Discontinuous Reception, eDRX）：设备以较长周期（可达数小时）短暂监听寻呼信道，其余时间保持射频休眠。适合需要被动唤醒的场景（如平台主动下发配置到电表）。
配合这两项，典型待机电流可以被压到极低的水平。一个例子：用两节 AA 碱性电池供电的智能水表，每日一次数据上报，覆盖等级设为中等——从电路板设计上看，续航可支撑数年。不过，真实续航受上报频率、电池容量、环境温度、芯片制程以及模组厂商提供的省电参数（如 eDRX 周期设置）等多因素影响，不同数据手册间差异明显，应以厂商实测为准。表 4-1 汇总 NB-IoT 的关键标准参数。
| 参数项 | 标准值/量级 | 说明 |
|---|---|---|
| 载波带宽 | 180 kHz | 固定占用一个 LTE 资源块，不可动态分配，这是“窄带”名称的直接来源 |
| 下行/上行峰值速率（Cat-NB1） | 约 26 / 66 kbps | Rel-13 口径的载波峰值速率 |
| 下行/上行峰值速率（Cat-NB2） | 约 127 / 159 kbps | Rel-14 引入，向下兼容 Cat-NB1 |
| 覆盖等级（CE level） | 多级 | 级别越高重复次数越多，覆盖越深，时延和功耗也越大 |
| 最大耦合损耗（MCL） | 164 dB | 较基础 LTE 提升约 20 dB，是“穿透井盖/地下室”能力的量化来源 |
| PSM 休眠时长 | 数小时至数十天，标准上限约 413 天 | 由周期性 TAU 定时器（T3412 extended）控制 |
| eDRX 寻呼周期 | 秒级至约 2.91 小时 | NB-IoT 空闲态标准上限约 2.91 小时，配置越长越省电、下行越迟钝 |
| 待机电流（PSM/eDRX 启用） | 微安级（模组数据手册典型值） | 取决于芯片实现、系统时钟设计和是否保留 RTC |
| 工作频段 | 多种 LTE 频段 | 运营商可优先选取低频段部署 |
表4-1 NB-IoT 关键参数概览
注：表中峰值速率、MCL 与 PSM/eDRX 上限为 3GPP 标准值或由标准参数推导的量级（载波峰值速率口径见 TS 36.306 等规范，定时器上限见 TS 24.008/TS 23.682）；运营商实际开通的网络能力、套餐限速与实测值应与标准值分开看待。
设备类别方面，3GPP 定义了 Cat-NB1 和 Cat-NB2 两类。Cat-NB2 引入了更灵活的上行资源分配，同时调整了重复传输次数上限。模组厂商已能提供 Pin2Pin 兼容的多模产品（NB-IoT + GSM 或 NB-IoT + LTE-M），这使得同一块电路板可通过贴装不同模组快速切换网络制式。但问题在于，不同厂商的模组在功耗控制、AT 指令集、固件升级接口上依然存在差异——开发者在更换模组供应商时仍需要做适配——碎片化并未因此消失。这会为后续 4.2 节讨论的统一接入层设计埋下伏笔。
NB-IoT 最成熟的应用场景是固定位置、低频上报的资产监控。“智能抄表”几乎成了这项技术的代名词——水表、气表、电表通过 NB-IoT 每日或每小时上报用量数据，运营商确保网络可达，平台负责计费和异常告警。另一主流方向是市政设施监控：智能井盖（监测开合与倾斜）、独立式烟雾报警器（检测到火警时立即上报）、垃圾桶满溢检测（触发清运调度）。这三类场景有一个共同特征：设备安装后几乎不移动，对实时性要求不高（秒级到分钟级响应足够），但必须有运营商网络覆盖做基数保障。
从更广的视角看，NB-IoT 是运营商从“连接人”向“连接物”扩张的一张核心底牌。它不追求高吞吐或几十毫秒级别的超低时延，而是用最窄的射频管道和极低的功耗，把海量、低频、省电的终端挂进运营商的蜂窝体系。这种“少即是多”的设计哲学，正是 3GPP 在 LPWA 方向给出的标准答案。
4.1.2 LoRa 与 LoRaWAN：非授权频段的 LPWAN 路线
上一节讨论的NB-IoT绑定运营商授权频段，意味着每台设备都必须插SIM卡、按流量缴费。但在实际工程中，大量场景需要的是：在一片广阔区域（几公里乃至更远）内部署数百到数千个传感器，电池扛数年，且整张网络完全由用户自己控制、无月租。这正是LoRa和LoRaWAN所占据的生态位：工作在免授权频段，绕开运营商，把网络的控制权交回给项目方。
LoRa物理层最初由Semtech公司发明，至今仍是Semtech的专有技术；在其之上，由LoRa联盟制定并开放维护的组网规范就是LoRaWAN。需要澄清的是，这条路线的“非授权频段”并不等于“私有封闭”——LoRaWAN是开放联盟规范，任何厂商都可以按规范实现兼容设备，生态内的互操作认证由联盟负责。它工作在免授权Sub-GHz频段，各国分配不同，但普遍落在400–900 MHz之间。其核心技术是扩频调制：发射机将窄带信号在较宽频谱上“展宽”，接收机用相同扩频码将其“压缩”回来。这种做法的直接效果是：同频段的其他窄带信号不会被正确解扩，只会被视为背景噪音滤除，因此抗干扰能力显著强于同功率下的窄带FSK（频移键控）信号。
通过调整扩频因子（Spreading Factor, SF），工程师可以在传输速率和覆盖距离之间灵活取舍。SF越高，链路预算越大，覆盖越远，但有效数据速率越低。这一机制使得LoRa在非授权频段上实现了覆盖公里的能力，涵盖城郊、农场乃至开阔乡村。工程上，这相当于在免授权频段复现了NB-IoT的覆盖范围，且完全脱离运营商基础设施。
LoRa物理层解决的是调制问题，而让设备真正互通的是其上的网络协议——LoRaWAN（Long Range Wide Area Network）。LoRaWAN采用星形拓扑，定义了四类角色：终端节点、网关（Gateway）、网络服务器和（可选）应用服务器。终端通过单跳LoRa无线信号与一个或多个网关通信；网关仅负责将LoRa射频包转换为IP数据包，不解析业务逻辑，直接转发给云端网络服务器；所有协议处理（去重、校验、确认、下行调度）集中由网络服务器完成。这种“哑网关”设计显著降低了网关硬件成本与运维复杂度，且单台网关理论上可服务大量终端节点。架构如下所示。
LoRaWAN另一个关键设计是定义了三种终端工作模式：
- Class A（双向通信，终端主动上行）：终端随时可上行发送，发送后立即打开两个短接收窗口等待下行。这是最省电的模式，因为下行必须等待终端先发数据。
- Class B（固定时隙下行）：终端在Class A基础上，还会在由网络服务器信标同步的预定时刻额外打开接收窗口，允许服务器在确定时刻下发指令，功耗介于A和C之间。
- Class C（连续接收下行）：终端几乎持续监听，仅在发送瞬间关闭接收，下行时延最低但功耗最高。
这使得开发者可以在同一网络中混搭不同设备：大部分传感器用Class A，阀门或执行器用Class C，按需选择。
LoRaWAN的典型应用集中在需自建广覆盖、低速率网络的场景：智慧农业（土壤湿度监测、气象站）、资产追踪（集装箱、牲畜）、远程抄表（水表、气表），以及环境监测（森林火灾预警、空气质量）。这些终端常部署在无运营商蜂窝信号覆盖的区域，或用户不愿支付月租费。
对比上一节的NB-IoT，两者同属LPWA阵营，但设计哲学和成本结构差异显著，如下表定性对比：
| 对比维度 | NB-IoT | LoRa / LoRaWAN |
|---|---|---|
| 工作频段 | 授权频段（运营商分配） | 免授权Sub-GHz（地域分配差异明显） |
| 峰值速率 | 较低 | 极低，随SF调整 |
| 典型功耗 | 较低 | 极低（Class A待机可达微安级） |
| 部署模式 | 必须加入运营商网络 | 自建网关或使用公有网关服务 |
| 成本结构 | 模组成本 + 运营商资费 | 模组成本 + 网关及服务器建设成本，无持续资费 |
实际选型核心在于业务是否依赖运营商、是否需要全球漫游、以及资费预算与自建工程的权衡。对希望完全控制网络、终端规模在数百至数千级别、且不希望产生月租费用的项目，LoRa通常更灵活。反之，若已有运营商覆盖、需要高可靠性SLA、且省去网关运维，NB-IoT更省心。不少项目采取双模策略：信号覆盖好的区域走NB-IoT，偏远区域走LoRaWAN，由应用层统一管理，这已是成熟做法。
4.1.3 5G URLLC与mMTC：蜂窝网络的IoT增强
上一节的LoRaWAN适合自建网的极低速率场景。但当工程场景从“数公里传个温度”延伸到“毫秒级控制机械臂”，对速率和时延的要求急剧提升，同时依旧依赖运营商广覆盖来免去自建网维护负担。5G给出的答案不只是“更快的手机网”，它专门为IoT划出了两个全新的服务维度。
5G为物联网定义了两类应用场景——URLLC（超可靠低时延通信，Ultra-Reliable Low-Latency Communication）和 mMTC（大规模机器类通信，massive Machine Type Communication）。它们与增强移动宽带（Enhanced Mobile Broadband, eMBB）共同构成三大场景方向——这一划分由 ITU-R 在 IMT-2020 愿景中提出，3GPP 随后在 5G 标准中予以落实。在IoT语境下，这两者代表两条截然不同的权衡线：一条提高无线链路在严格时限内成功传输的概率，另一条追求海量连接和长电池寿命。需要先划清边界：URLLC 的指标主要约束无线接入及其服务能力，不能单凭“用了 5G”就宣称控制回路已经获得端到端确定性。端到端结果还取决于终端、无线接入、回传、核心网、边缘计算、现场网络和控制器共同构成的时延与可靠性预算。
URLLC：极低时延与高可靠性的工程代价
URLLC的核心目标是在给定时限内以高概率完成传输。在5G新空口（New Radio, NR）设计中，促成URLLC的关键机制包括灵活时隙与mini-slot。传统LTE以子帧为重要调度时间单位；5G NR 的 mini-slot 可以用更少的 OFDM 符号（正交频分复用符号）进行调度，从而缩短空口等待时间。但从控制器产生指令到执行器动作，仍要把回传、核心网、边缘应用、现场总线和执行器响应纳入预算。急停等安全功能应由经过安全认证的本地回路承担，不能把公网或普通 5G 切片当作唯一保护通道。
代价同样明显：URLLC通常需要更密的覆盖、可保障的无线资源、严格同步，以及对终端和网络全链路的联合设计。候选用例包括机器人协同、运动控制辅助链路和车路协同等低时延高可靠通信；它是否能进入闭环控制，必须以现场测量、失效分析和安全等级要求为准。在工厂部署中，URLLC 网络还可能与 IT 流量隔离，并配合边缘计算、工业以太网或 TSN 完成端到端工程设计。
mMTC：深度覆盖下的海量连接
mMTC走向另一极：不要求快，要求多和省。其核心是连接密度——每单位面积支持极高数量的设备。在此场景下，5G提供的不是大带宽，而是极强的链路预算和深度覆盖能力——让藏在井盖下、地下室角落的环境监测节点也能稳定上报数据。
mMTC的工程实现并非从零开始，它直接继承了LTE-M（eMTC）和NB-IoT的设计遗产。在5G标准中，这两者被纳入mMTC的支撑技术，并在NR的兼容模式下继续演进。NB-IoT和eMTC已经能够支持极高的连接密度。5G NR进一步通过更窄的带宽配置和扩展不连续接收（eDRX），让终端待机电流进一步降低，实现更长续航。所以，当我们说“5G连接水表”时，本质上用的仍是NB-IoT的机制，只不过它作为5G网络的一部分被统一接纳和管理。这种继承关系意味着：已经在使用NB-IoT模组的设备，在适配了5G核心网切片后，可以直接连接到mMTC切片，无需更换硬件。
一张网络，多种切片：5G IoT的融合架构
URLLC和mMTC并非孤立运行。在5G核心网的网络切片能力下，一张物理网络可以虚拟出多个逻辑网络：一个切片给工厂的工业机器人（URLLC），一个切片给全市的智能路灯（mMTC），另一个切片给高吞吐的视频监控（eMBB）。这种架构使得IoT平台不再需要“两套网络”，而是通过统一的5G接入层和核心网汇聚差异极大的设备类型。但从平台角度看，每个切片上报的数据格式可能不同，平台侧仍需利用统一的协议适配层把这些异构数据归一。
URLLC场景工程检查表：部署高可靠应用前请确认——
- [ ] 端到端时延预算是否包括空口、回传和核心网处理时间
- [ ] 终端是否支持超短反馈（如HARQ快速重传）
- [ ] 网络切片是否由运营商在核心网侧开放（部分运营商需额外签约）
- [ ] 高可靠场景是否额外采用冗余编码或双链路备份
mMTC场景工程检查表：部署海量连接前请确认——
- [ ] 终端是否已预集成NB-IoT/eMTC驱动
- [ ] 海量连接场景是否评估过并发上报对网关/平台的写入压力
- [ ] 模组的功耗模型是否适配当前场景的上报周期
- [ ] NB-IoT/eMTC设备在接入5G mMTC切片时是否需要升级固件
4.1.4 WiFi/BLE/Zigbee：室内短距通信的选择
前几节覆盖的是公里级广域网，场景切换到室内——智能家居、写字楼桌面、工厂车间、可穿戴设备——通信距离缩回几十米，业务诉求立刻变得五花八门。有的设备靠纽扣电池要撑一年，有的需要实时传输视频流，还有的则要几十个节点自动组网相互中继。“远”不再是刚需，“省、快、稳、易组网”之间如何取舍，成为每一次选型绕不开的核心。
WiFi、BLE（低功耗蓝牙，Bluetooth Low Energy） 和 Zigbee 是室内短距的三个主流候选，各自在功耗、速率、组网能力上押注了不同的权衡。没有哪个方案能覆盖所有场景，但有一个判断框架可以帮工程师在方案定型前筛掉错误选项。
协议栈深度：天然在线与强制网关
三个候选者在协议栈深度上存在根本差异。WiFi是三者中唯一走完整TCP/IP栈、允许设备直接访问互联网的协议，设备上电即可与云端通信。BLE物理层采用自有GFSK（高斯频移键控，Gaussian Frequency Shift Keying）调制规范，Zigbee底层复用IEEE 802.15.4标准；两者设计时都瞄准极小数据包传输，通常不具备直接的IP寻址能力，因此设备必须经过网关进行协议转换才能上云。
工程选型的第一步就是判断：你的场景需要一个能独立联网的设备，还是可以接受必须搭配网关的方案。前者增加模组成本和功耗，后者则引入网关这一额外的故障点和维护开销。
WiFi：基础设施存量与功耗代价
当手机和家电已经配好WiFi时，开发者很自然地会想“直接用WiFi不就行了？”。这个选择是否划算，取决于三点：功耗预算、节点数量和mesh组网需求。
WiFi（802.11系列）以高速率为设计目标，单流吞吐覆盖数十到数百Mbps的区间，适合视频监控、大屏互动和OTA升级。代价是高功耗——模组持续传输时的电流远高于另外两个方案，工程上很少用于电池供电的设备。组网模式是典型的星型，每个终端直接连接AP，节点间不中继。
IEEE 于 2016 年批准、2017 年出版的 WiFi HaLow（IEEE 802.11ah，WiFi 联盟标准化）工作于Sub-1 GHz频段，以牺牲峰值速率换取更远的覆盖和更低的功耗，但终端生态和芯片产能尚不及主频段产品成熟。另一个方向是较新版本的标准引入了正交频分多址（Orthogonal Frequency Division Multiple Access, OFDMA）和目标唤醒时间（Target Wake Time, TWT），后者允许设备规划休眠时间窗，在保持标准兼容性的前提下降低浅休眠态功耗——这对电池供电类摄像头和门锁有实际价值，但距BLE级别的超低功耗仍有鸿沟。
从工程角度看，WiFi在室内场景的核心优势不在于省电或自组网，而在于基础设施存量。几乎每个家庭和办公室都有WiFi路由器，手机天然支持WiFi连接。如果项目中的设备属于有源供电的大带宽需求品（如安防摄像头、智能音箱），WiFi的“即插即联”特性可以省去网关采购和配置成本。
BLE：超低功耗与网状扩容
BLE与WiFi形成鲜明互补。BLE把功耗压到了极低水平：在典型广播间隔下，纽扣电池可支撑数月乃至一年的定时上报或事件触发（典型范围），这对需要长期免维护的场景具有工程吸引力。代价是速率受限——BLE 5.x的物理层典型峰值速率在Mbps量级，通信距离在室内为十米级（典型视距，无遮挡可拓展至几十米，规范中的长距编码PHY还能再远一档）。测距则是另一回事：Bluetooth 6.0（2024年9月发布）引入的Channel Sounding机制让两台BLE设备能以厘米级精度进行安全测距，数字车钥匙、存在感知类应用已经商用——但这是“测得准”，不是“传得远”，常规通信距离仍是十米级量级。BLE的传统角色是点对点设备（如手机连手环），但BLE SIG引入BLE Mesh规范后，节点可通过“管理型泛洪”相互中继，形成覆盖更大区域的mesh网络。
BLE Mesh的最大工程价值在于保持了BLE的超低功耗：中继节点也能用电池供电。工程代价是mesh拓扑下端到端时延增加到数十到数百毫秒，不适合对实时性敏感的控制场景（如工业现场设备互锁）。典型应用包括智能灯控、传感器网络和可穿戴设备。
Zigbee：标准化互操作与成熟mesh生态
Zigbee是为智能家居和楼宇自动化设计的短距低速mesh协议。节点分为三种角色：**协调器负责建网与维护，路由器负责中继，终端设备不中继以省电。Zigbee联盟后来统一了此前分散的应用层规范（如ZHA、ZLL），使不同厂商的设备可在同一网络上互操作。ZCL（Zigbee Cluster Library，Zigbee集群库）**定义了设备暴露的标准功能（如“开关”“调光”“温度测量”），应用层开发不必关心底层协议栈细节。
与BLE Mesh相比，Zigbee的大规模mesh在工业级部署中可达数百至上千节点——与BLE Mesh的组网规模量级相近——但ZCL定义更细致，跨厂商互操作更成熟。瓶颈在于几乎所有Zigbee设备都必须通过协调器才能连接互联网——网关不是可有可无，而是架构固有特征。
工程选型：从场景出发，而非从协议出发
下表从关键工程维度对比三种技术。参数为典型范围，基于各芯片数据手册和技术联盟规范中常见的量级，具体值依实际产品浮动。
| 参数 | WiFi（802.11系列） | BLE（5.x系列） | Zigbee（3.0） |
|---|---|---|---|
| 工作频段 | 2.4/5/6 GHz 免授权 | 2.4 GHz 免授权 | 2.4 GHz 免授权，可选Sub-GHz |
| 物理层标准 | IEEE 802.11 | 私有（BLE SIG定义） | IEEE 802.15.4 |
| 典型峰值速率 | 数十至数百Mbps | Mbps量级 | 250 kbps |
| 通信距离（室内） | 数十米 | 十米级（典型视距） | 十至百米 |
| 功耗等级 | 高 | 极低 | 低 |
| 典型节点数/网络 | 数十至数百（受AP容量制约） | 数千级（mesh模式） | 数百至数千（mesh模式） |
| 组网模式 | 星型（AP为中心） | 点对点、广播、mesh | tree/mesh（协调器-路由器-终端） |
| 设备模组成本 | 中等 | 低 | 低至中等 |
上表之外还有一条绕不开的现实约束：频段共存。2.4 GHz 是 Wi-Fi、BLE、Zigbee 三家共用的免授权频段，彼此之间没有优先级——Wi-Fi 一次大流量传输就可能把同频段的 Zigbee 链路压出重传甚至断连，BLE 的自适应跳频也会周期性地撞上 Zigbee 信道。各联盟都定义了共存机制（如 BLE 的自适应跳频避让被占信道），但工程上真正起作用的是频道规划、天线隔离与吞吐预算。在设备密集的环境（一栋楼里既有数百个 Wi-Fi 终端又有成片传感器），共存问题应与功耗、带宽一起进入选型清单，而不是上线后再补救。
工程选型检查清单：
- 功耗预算：设备是电池供电还是有源供电？电池供电直接排除WiFi（BLE是首选，Zigbee次之）。
- 带宽需求：是否需要在设备上传输视频、大文件OTA或有实时性要求？是则只能用WiFi。
- 节点规模与互操作性：超过一定数量的节点且希望多厂商设备互通，Zigbee凭借ZCL规范的成熟度更稳定。
- 网关接受度：是否接受引入网关设备？若不接受，则只能选WiFi；若能接受，BLE和Zigbee均可选。
- 批量OTA频率：设备是否需要频繁远程升级？WiFi在此场景占优；BLE升级速率低；Zigbee若OTA太频繁，网络负载会挤占业务通道。
三个过滤器都过不了的场景——例如几十个电池供电的传感器、不需要密集OTA、能接受网关作为故障点——Zigbee通常是长期运维成本最低的选择。但实际工程中三者并不互斥。很多高端智能家居网关同时集成了Zigbee协调器、BLE Mesh和WiFi，让不同场景的设备落在最适合的协议上。这背后的统一接入问题，我们在下面会展开讨论。
4.1.5 技术对比与选型建议
从 NB-IoT 到 Zigbee，每种物理层和 MAC 机制都对应着一组特定的工程约束。当面对一个真实项目时，五个维度——距离、速率、功耗、成本、部署便捷性——之间强冲突几乎不可能同时满足。更高的速率对应更高的信噪比和模组功耗；更远的距离需要更大的链路预算，通常以牺牲速率为代价。选型的本质是“按场景权重排序”。
下面这张雷达图以五边形轴展示六种技术在五项约束上的相对侧重。注意这是工程归纳的定性框架，不反映实测基准或标准化数据；各维度分数为定性比较，不可用于精确选型决策。
将雷达图上的相对优势落地到工程决策，可以拆成三类典型场景。
第一类：广覆盖、低频上报。 远程抄表、农业环境监测、井盖倾斜告警。设备靠电池供电，数月甚至数年上报一次，且常处于信号死角。LPWAN 阵营（NB-IoT 和 LoRa）是唯一现实选择。NB-IoT 的优势在现成的运营商基础设施：模组插 SIM 卡，平台对接核心网即可通信，无须自建网元。LoRa 适用于信号盲区、边境或业务方希望完全掌控网络的场景——代价是需自行架设网关并通过 LoRaWAN 连接网络服务器。还要注意一条免授权频段的监管硬约束：占空比（duty cycle）。例如欧盟 868 MHz 频段规定每台设备的累计发射时间占比不得超过 1%，单个终端单位时间内能发出的上行数据因此有明确上限，上报周期、包长和确认策略都必须围绕这条红线设计，不能想发就发；我国 470-510 MHz 频段的信道与发射时间限制同样需要在设计阶段核对当地无线电管理规定。判断标准：已有运营商覆盖且接受流量费，NB-IoT 是默认候选项；想要控制长期运营成本或避免依赖运营商，LoRa 更灵活。
第二类：室内高带宽与实时交互。 视频监控、大屏互动、智能音箱。只有 WiFi 能稳定传输高清视频流并支持在线固件升级，但其高功耗决定了只能用市电供电。BLE 和 Zigbee 走省电路线，在电池供电设备中主导。BLE 因手机生态成熟，在可穿戴设备和近场配网中胜出；Zigbee 凭借成熟的 mesh 自组网协议栈，在楼宇自动化（灯光、传感器网络）更稳定。典型混合方案：摄像头走 WiFi，窗帘电机走 Zigbee，门锁走 BLE——三网在同一个智能家居网关处汇聚。多协议共存，是工程常态。
第三类：移动性高、时延敏感。 AGV 调度、远程控制、工业机器人协同。5G URLLC 可以为移动段提供低时延、高可靠的无线承载，但端到端确定性仍需现场网络、边缘计算和控制系统共同保证；若设备运动路径固定且布线可行，工业以太网往往更直接。这里还要澄清一个关于 mMTC 的常见误读：mMTC 是 ITU 在 IMT-2020 愿景中定义的场景类别，不是一项独立的新空口技术，在 3GPP 体系中主要由 NB-IoT 和 eMTC 等技术承接，所以并不存在“5G mMTC 与 NB-IoT 二选一”的简单比较。
多协议共存不是理想，是常态。 同一个智慧园区可能同时存在门锁（BLE）、路灯（LoRa）、摄像头（WiFi）、水管压力传感器（NB-IoT）。每台设备只跑一种协议，但工程系统往往是三到五种协议的拼盘。真正难点不在协议本身，而在平台侧如何将这些不同链路的数据归一成统一的设备模型和业务接口。选型表的最后一行应该写：无论选哪种协议入网，最终都要在平台层面收口。
4.1.6 站在 2026 年的连接演进：RedCap、NTN、Wi-Fi 7、Matter/Thread 与 TSN
早期分类已经不够描述“5G-Advanced/RedCap、卫星 NTN、Wi-Fi 6/6E/7、Matter over Thread、工业 TSN”并行发展的现实（定性归纳，具体时间线请以标准组织公告为准）。它们不是替代已有 LPWAN 或 Wi-Fi 的“下一代”，而是在特定约束下的补充选项。选型时应按需求约束落到决策路径：
低功耗、低数据率、广域覆盖
→ LoRaWAN / NB-IoT
中等带宽、5G 网络已覆盖、移动或高可靠
→ 5G RedCap / eRedCap（3GPP Release 17/18）
无地面网络、远洋/偏远、可接受较大时延
→ 3GPP NTN（IoT NTN 或 NR NTN）
家庭与商业空间设备互操作、低功耗 mesh
→ Matter over Thread / Wi-Fi
高密办公/高清视频/AR
→ Wi-Fi 6E / Wi-Fi 7
工业实时控制、亚毫秒时延与确定性调度
→ 工业以太网 + TSN（IEEE 802.1）几点补充说明：
- RedCap 与 eRedCap：作为 5G NR 的“中速物联网”类型，用于摄像头、可穿戴、工业无线传感等对 NB-IoT 太窄、对 5G eMBB 又过重的场景。选型时应确认目标运营商的商用范围和模组供货，避免把 3GPP 规范存在等同于商业可用。
- 中国蜂窝物联格局：2G/3G 退网进入收尾阶段，存量中速物联网连接正由 LTE Cat.1 承接，NB-IoT 在低频小数据场景持续演进；5G-A（3GPP Rel-19 已于 2025 年 12 月冻结）将无源物联（Ambient IoT）这类不依赖电池的终端纳入标准化视野。这条演进线同样遵循“标准在先、商用在后”，落地节奏以运营商在网能力为准。
- NTN：卫星与蜂窝融合适合远洋、油气、林业和跨国资产追踪。链路预算和往返时延远大于地面网络，业务侧要按小时级心跳而非秒级遥测设计。
- Wi-Fi 7：MLO、320MHz 频宽和 4K-QAM 提升的是室内高密和低时延，不改变端侧功耗结构；纽扣电池设备仍应留在 BLE/Zigbee/Thread。
- Matter 与 Thread：Matter 定义应用层设备模型和调试流程；Thread 只是承载之一。现行版本锚点为 Matter 1.5（2025-11）与 Thread 1.4（2024-09），选型时先确认目标设备认证所依据的版本。若目标是与消费级生态互操作，Matter 是可行入口；工业协议互操作仍以 OPC UA、Modbus 为主。
- TSN：解决“网络确定性”，让以太网可承载 PLC 之间的实时同步；它不是无线技术，也不适合替代 5G URLLC，两者可以在同一工厂协同（URLLC 覆盖移动段，TSN 覆盖固定骨干）。
工程上仍建议保持“一台设备一种主链路 + 平台侧归一”的结构：新增技术只是在原来六种上叠加，不是全部替换；平台设备模型、认证、审计和 OTA 应对每一种新链路复用同一套接口，而不是每引入一种新协议就复制一套后端。