LoRa 与 NB-IoT 低功耗广域网

引言

物联网里大量场景的共同画像是：设备分散在几公里甚至十几公里外，每个设备每天只上报几十字节，装一次电池要撑五年到十年，单价还要压到几十块。Wi-Fi 覆盖不到，蜂窝 4G 太耗电，Zigbee 距离太短，这类需求催生了 LPWAN（低功耗广域网）。

LPWAN 的核心矛盾是「距离、速率、功耗、成本」四者不可兼得。香农公式决定了同样的功率和带宽下，速率越低、灵敏度越高、距离越远，所以 LPWAN 走的都是「牺牲速率换距离」的路线：LoRa 用扩频把信号埋在噪声底下，NB-IoT 用重复传输和窄带宽换取覆盖增强。理解这一点，后面所有的参数取舍就都有了解释。

本文按「谱系 → LoRa 物理层 → 频段与占空比 → 耗时计算 → LoRaWAN 协议 → 入网与安全 → 帧结构 → NB-IoT → 省电机制 → 电池估算 → AT 命令 → 选型」的顺序展开。上层协议怎么接（CoAP、LwM2M）见 CoAP 与 LwM2M ，网关侧怎么汇聚见 边缘计算网关 。

目录

1. LPWAN 要解决的问题与谱系对比
2. LoRa 物理层：CSS 与扩频因子
3. 频段、带宽与占空比
4. ToA 计算与一帧耗时估算
5. LoRaWAN 协议栈与 Class A/B/C
6. OTAA 与 ABP 入网与安全
7. MAC 帧结构与帧计数
8. ADR、网关与网络服务器
9. NB-IoT 部署模式与覆盖增强
10. PSM 与 eDRX 省电机制
11. 电池寿命估算
12. NB-IoT 的 AT 命令序列
13. 选型对比表
14. 权衡取舍
15. 常见坑清单
16. 小结

1. LPWAN 要解决的问题与谱系对比

短距无线（Zigbee、BLE、Wi-Fi）的覆盖在几十米量级，需要自建密集的网关网络；蜂窝 4G 覆盖好但模组功耗高、单价高，电池撑不过几天。LPWAN 填的正是「几公里到几十公里、每天几十字节、电池数年」这段空白。

选型的第一个分岔是「有没有运营商网络可用、能不能接受每设备月租」。有运营商覆盖、设备数量不大、需要移动性或跨区域，NB-IoT 更省事；无运营商覆盖（如矿区、农场、地下管廊）、设备量大、想自建私有网络，LoRa 更划算。第二个分岔是「数据量和实时性」：NB-IoT 能跑 TCP、能收较大下行、延迟秒级；LoRaWAN 单帧载荷受限、下行窗口窄、延迟取决于 Class。

2. LoRa 物理层：CSS 与扩频因子

LoRa 的物理层是 Chirp Spread Spectrum（CSS，线性调频扩频）。它把每个符号编码成一个频率随时间线性扫过的 chirp，接收端用匹配滤波解扩，能把信号从噪声底下解出来，因此接收灵敏度可以低到 -137dBm（SF12、BW125）。

关键参数是扩频因子 SF（Spreading Factor），取值 7 到 12。每个符号携带 SF 个比特，SF 越大：

• 符号时间越长：T_sym = 2^SF / BW。BW125 时 SF7 是 1.024ms，SF12 是 32.768ms。
• 灵敏度越高、距离越远：SF 每加 1，灵敏度约改善 2.5dB。
• 速率越低、耗电越多：SF12 发一帧的空中时间是 SF7 的二十多倍。

数据速率 R_b = SF * BW / 2^SF * CR，其中 CR 是编码率 4/5 到 4/8（前向纠错，冗余越多抗干扰越强但速率越低）。BW125、SF7、CR4/5 对应 5469 bps；SF12 只有 293 bps。

这里有个著名的 LoRa「悖论」：SF 越大速率越低，但抗干扰和穿透更好。实际部署中要根据链路预算和占空比动态选 SF，这正是 ADR（自适应速率）要解决的问题。

3. 频段、带宽与占空比

LoRa 工作在非授权 ISM 频段，各地法规不同：

EU868 的 1% 占空比是最硬的约束：意思是每小时内单信道累计发射时间不能超过 36 秒。SF12 一帧 1.48 秒，算下来一小时最多发 24 帧，平均 150 秒一帧。这个限制直接决定了上报频率的上限，也解释了为什么欧洲的 LoRaWAN 设备上报周期普遍很长。

带宽有 125kHz、250kHz、500kHz 三档。带宽越宽速率越高但灵敏度越低（每翻倍损失 3dB），所以 125kHz 是覆盖优先的默认选择，500kHz 用于下行或近距离高速率场景。

发射功率 EU868 通常限 14dBm（25mW），部分子带允许到 16dBm；US915 允许到 20dBm 甚至 30dBm（受天线增益和 EIRP 限制）。功率和占空比是两个独立的约束，都要满足。

4. ToA 计算与一帧耗时估算

ToA（Time on Air）是 LoRa 工程计算的核心，它决定了占空比预算、电池寿命和网络容量。计算分三步。

T_sym     = 2^SF / BW
T_preamble = (n_preamble + 4.25) * T_sym          // n_preamble 默认 8

n_payload = 8 + max( ceil( (8*PL - 4*SF + 28 + 16*CRC - 20*IH)
                           / (4*(SF - 2*DE)) ) * (CR + 4), 0 )
// PL 载荷字节数, CRC=1 开, IH=0 显式头, DE=1 当 SF11/SF12 且 BW125

T_total   = T_preamble + n_payload * T_sym

其中 CR 取 1 到 4 对应编码率 4/5 到 4/8。下面这张表是 BW125、CR4/5、显式头、CRC 开启、前导 8、载荷 20 字节的实测值：

这张表解释了几件事。SF12 一帧 1.48 秒，在 EU868 的 1% 占空比下每小时只能发 24 帧，所以「SF 越大越好」是错的——它吃掉的是你的上报频率预算。载荷每增加 10 字节，SF12 下多约 330ms，所以 LoRaWAN 应用层要把数据压到极致（用差分、缩放、位域，20 字节能表达很多传感器值）。同一网络里所有设备共享信道，SF12 设备占用信道时间是 SF7 的 24 倍，网关容量会被少数远距离设备拖垮。

把公式固化成脚本，做占空比预算时直接跑，比查表可靠：

import math

def lora_toa(sf, bw_khz, payload_bytes, cr=1, preamble=8, crc=1, explicit_header=True):
    """返回单帧空中时间，单位毫秒。cr=1 表示 4/5，cr=4 表示 4/8"""
    bw = bw_khz * 1000
    t_sym = (2 ** sf) / bw                          # 符号时间，秒
    t_preamble = (preamble + 4.25) * t_sym

    de = 1 if (sf >= 11 and bw_khz == 125) else 0   # 低速率优化标志
    ih = 0 if explicit_header else 1
    num = 8 * payload_bytes - 4 * sf + 28 + 16 * crc - 20 * ih
    den = 4 * (sf - 2 * de)
    n_payload = 8 + max(math.ceil(num / den) * (cr + 4), 0)

    return (t_preamble + n_payload * t_sym) * 1000

for sf in range(7, 13):
    toa_ms = lora_toa(sf, 125, 20)
    frames = int(3600_000 / toa_ms * 0.01)          # EU868 1% 占空比
    print(f"SF{sf}: {toa_ms:7.1f} ms, 每小时最多 {frames:3d} 帧")

跑出来 SF7 是 61.7ms、每小时最多 583 帧，SF12 是 1482.8ms、每小时最多 24 帧，与表格一致。做预算时把所有设备的 ToA 乘上报频率求和，占用不要超过小时预算的 80%，剩下 20% 留给重传和下行。注意占空比是按「每个子频段」分别计算的，不是整个 868 频段合并算，跨子带部署可以规避部分限制。

5. LoRaWAN 协议栈与 Class A/B/C

LoRa 是物理层，LoRaWAN 是建在其上的 MAC 层协议（规范 1.0.4 与 1.1）。网络拓扑是星型：终端 → 网关 → 网络服务器 → 应用服务器。网关只做透明转发（把 LoRa 帧封进 UDP/IP 或 MQTT 送到网络服务器），不解析应用数据。

LoRaWAN 定义三个设备等级：

Class A 是基础，所有设备都必须支持。它的机制是：每次上行发送结束后，在 RX1 和 RX2 两个窗口监听下行。RX1 的延时 RECEIVE_DELAY1 默认 1 秒，用与上行相同的频率和速率；RX2 在 RECEIVE_DELAY2 默认 2 秒，用固定的第二接收窗口参数（EU868 是 869.525MHz、SF12）。服务器可以在任一窗口回复，设备两个窗口都要监听。

Class A 的代价是「只有上行后才能收下行」，所以服务器要下发指令必须等设备下次上报，延迟不可控。Class C 几乎一直开着接收机，功耗从 uA 级跳到 mA 级，只有市电设备才用得起。

6. OTAA 与 ABP 入网与安全

设备加入网络有两种方式。

ABP（Activation By Personalization）：把 DevAddr（设备地址）、NwkSKey（网络会话密钥）、AppSKey（应用会话密钥）直接烧进设备。优点是入网快、不需要握手，适合调试；缺点是密钥固定，一旦泄露无法轮换，且帧计数器一旦回滚（比如设备重烧固件）服务器会拒收。

OTAA（Over-The-Air Activation）：设备保存 DevEUI（设备唯一标识）、JoinEUI（应用标识，旧称 AppEUI）、AppKey（根密钥）。入网时设备发 Join Request，服务器验证后回 Join Accept，双方用 AppKey 派生出会话密钥 NwkSKey 和 AppSKey。

Join Request:  AppKey 对 (JoinNonce 相关字段) 计算 MIC，明文发送 DevEUI/JoinEUI/DevNonce
Join Accept:   服务器用 AppKey 加密下发 AppNonce/NetID/DevAddr/DLSettings/RxDelay，
               设备解密后用 AppNonce + NetID + DevNonce 派生 NwkSKey 与 AppSKey

OTAA 每次入网都会派生新密钥，DevNonce 递增防止重放（1.0.4 起服务器会记录 DevNonce，重复就拒绝）。生产环境应该用 OTAA，把 AppKey 存进安全元件或加密的 NVS 分区。1.1 版本还引入了 NwkKey 和 AppKey 分离、以及 Join Server 角色，安全模型更完整。

一个常见误区：OTAA 不是「一次入网永久有效」，服务器可能因 DevNonce 耗尽或会话过期要求重新入网，设备必须能优雅处理重新 Join，且要能保存会话上下文（session context）避免每次重启都重新 Join。

7. MAC 帧结构与帧计数

LoRaWAN 的 MAC 帧结构如下：

几个要点。FCnt 是 32 位帧计数器，低 16 位在帧里传输，高 16 位设备与服务器各自维护。服务器用 FCnt 做重放保护：收到的帧计数必须比上次大（或在一个容忍窗口内），否则丢弃。这就是为什么设备重烧固件后如果计数器归零会被服务器拒收——必须让服务器重置该设备的帧计数。

FRMPayload 最大 242 字节，但受占空比和 ToA 限制，实际应用很少超过 51 字节（这是很多云平台的默认上限）。确认帧（Confirmed）需要服务器回 ACK，会额外占用下行窗口和占空比预算，非关键数据应该用非确认帧（Unconfirmed）。

8. ADR、网关与网络服务器

ADR（Adaptive Data Rate）让网络服务器根据设备上报的链路质量动态调整它的 SF 和发射功率。设备在上行帧的 FCtrl 里带 ADR 位和「距离上次收到下行过了几个帧」的计数，服务器据此判断链路是否稳定，然后通过下行 MAC 命令（LinkADRReq）下发新的速率和功率。

ADR 的价值很大：设备初始用 SF12 入网，服务器很快把它降到 SF7，ToA 从 1.48 秒降到 62ms，占空比预算和电池寿命立刻改善二十多倍。但 ADR 有个陷阱——它假设设备位置固定。移动设备（如追踪器）用 ADR 会导致服务器按旧位置给速率，设备移动后链路变差却还在用高速率，丢包严重。移动场景应该关掉 ADR 或使用「移动 ADR」。

网络服务器是 LoRaWAN 的大脑，负责去重（同一帧被多个网关收到）、帧计数校验、MAC 命令、ADR、以及把解密后的应用数据转发给应用服务器。开源实现里 ChirpStack 最完整（Go 编写、支持 1.0.x/1.1、有 Web UI 和 REST API），The Things Stack（TTN 的开源版）社区版最省事。自建私有网络通常用 ChirpStack 加一个 LoRa 网关（如 SX1302 方案的 RAK 或 Seeed 网关）。

8.1 网关容量估算

LoRaWAN 网关有 8 到 16 个解调通道（SX1302 是 8 路，外加一个单独的 SF 高速通道），每个通道同一时刻只能解调一个 SF 的信号，同 SF 的两个包重叠就会碰撞。容量估算的简化模型：

每小时可承载帧数 = 通道数 × 3600 秒 × 目标信道占用率 / 平均单帧 ToA

以 8 通道、平均 SF9（ToA 205ms）、把信道占用率控制在 30% 为例，单网关每小时约承载 8 × 3600 × 0.3 / 0.205 ≈ 42000 帧，对应 1000 个设备每 86 秒上报一次。但这个数字极度依赖 SF 分布：如果大量设备停留在 SF12，单帧 ToA 涨到 1.48 秒，同样条件下容量掉到约 5800 帧/小时。所以网关规划必须先把设备按链路预算分档、估出 SF 分布，再算容量，而不是按设备总数一刀切。多网关部署时还要考虑重叠覆盖带来的去重开销，以及网关回传链路（4G 或有线）的带宽。

9. NB-IoT 部署模式与覆盖增强

9. NB-IoT 部署模式与覆盖增强

NB-IoT 是 3GPP R13 引入的蜂窝物联网标准，R14 增强了移动性和多播。它的载波带宽只有 180kHz，对应 LTE 的一个物理资源块（PRB），有四种部署方式：

上行用 SC-FDMA（单载波，峰均比低省电），下行用 OFDMA。子载波间隔有 15kHz（单音，最多 12 个）和 3.75kHz（单音，用于覆盖增强）两种。

覆盖增强（CE，Coverage Enhancement）是 NB-IoT 的核心卖点，分三个等级 CE0/CE1/CE2，通过重复传输（repetition）把 MCL（最大耦合损耗）分别推到 144dB、154dB、164dB。CE2 相比普通 LTE 有 20dB 的覆盖增益，代价是重复次数高达上百次，一帧要发好几秒、耗电剧增。这就是为什么 NB-IoT 在地下室、水表井这类深覆盖场景能工作，但速率极低、延迟极大。

发射功率通常 20dBm（100mW），比 LoRa 的 14dBm 高，加上授权频段干扰可控，这是它覆盖好的另一部分原因。

10. PSM 与 eDRX 省电机制

NB-IoT 有两种省电模式，理解它们是做电池寿命估算的前提。

PSM（Power Saving Mode）：设备发完数据后进入深度休眠，射频和信令全部关闭，只有 RTC 在跑，电流降到 5uA 量级（不同模组 3 到 10uA）。设备在此期间不可达，只能等它自己醒来上报。两个关键定时器：

• Active Timer（T3324）：从进入空闲到进入 PSM 的时间，通常设 10 到 60 秒，这段时间设备还可达。
• TAU（T3412）：跟踪区更新周期，即 PSM 最长休眠时间，通常设几小时到一天，R14 的 extended T3412 可到 310 小时（约 13 天）。

eDRX（extended Discontinuous Reception）：设备周期性地短暂醒来监听寻呼，然后继续睡。相比 PSM 的「完全不可达」，eDRX 保证了一定的下行可达性。eDRX 周期在空闲态下 NB-IoT 可以从 20.48 秒到 10485.76 秒（约 2.9 小时）。醒来监听寻呼的那一小段电流在 mA 级。

两者可以组合：先用 eDRX 保持数分钟到数小时的可达性，然后进入 PSM 长睡。配置通过 AT+CPSMS（PSM）和 AT+CEDRXS（eDRX）下发，网络侧可以拒绝或修改设备请求的值，最终生效的以网络下发的为准。

11. 电池寿命估算

电池寿命的本质是「总电量 ÷ 平均电流」。以一个 5Wh 电池（约等于 2 节 AA 或 1 节 18650）为例，要撑 10 年，平均电流必须低于：

10 年 = 10 * 365 * 24 = 87600 小时
平均电流上限 = 5 Wh / 3.6 V / 87600 h ≈ 15.9 uA   // 按 3.6V 折算

考虑到电池自放电和升压损耗，实际可用平均电流要压到 10uA 以下。这意味着休眠电流（5uA）几乎吃掉了全部预算，任何频繁的唤醒都会让寿命腰斩。

下面按每天上报 4 次的 NB-IoT 设备估算：

每天 4 次的通信电量约 4 × 175 uAh = 700 uAh，休眠 20 小时约 100 uAh，合计约 800 uAh/天。5Wh 电池按 3.6V 折 1389 mAh，理论寿命 1389 / 0.8 ≈ 1736 天，约 4.8 年。要撑到 10 年，必须把单次通信时间压下来（优化附着流程、减少重复传输）或降低上报频率。

LoRa 的估算逻辑相同但数字更漂亮：一次 SF7 上报的 ToA 只有 62ms，峰值电流约 44mA（14dBm），单次电量约 0.76 uAh，一天 4 次才 3 uAh，休眠电流主导，10 年很轻松。这就是 LoRa 在电池寿命上的优势来源——不是峰值电流低，而是发射时间短得多。

11.1 把平均电流压下来的手段

• 降低上报频率是最有效的手段，频率减半寿命就翻倍，先问业务是否真的需要每分钟上报。
• 缩短单次通信时间：NB-IoT 优化附着流程（复用 RRC 连接、减少不必要的 TAU）、LoRa 用 ADR 把 SF 降下来。
• 提高休眠质量：关掉未用的外设时钟，把悬空引脚配置成确定电平，关闭调试接口的漏电。
• 本地缓存聚合：多次采样攒成一帧发，通信次数降一个数量级，代价是数据延迟变大。
• 选对电池：锂亚硫酰氯（Li-SOCl2）自放电率每年不到 1%，是长寿命节点的首选，但内阻高、峰值电流能力弱，要并一个大电容应对发射瞬间的电流冲击。

12. NB-IoT 的 AT 命令序列

NB-IoT 模组（如移远 BC26、中移 M5311）都用 3GPP TS 27.007 风格的 AT 命令。一次典型的上报流程：

AT+CGSN                    // 读 IMEI，确认模组正常
AT+CFUN=1                  // 打开射频
AT+CGATT=1                 // 附着到网络
AT+CEREG?                  // 查注册状态，+CEREG: 0,1 表示已注册
AT+CSQ                     // 查信号质量，+CSQ: 20,99，第一个值 0-31 越大越好
AT+CPSMS=1,,,"01000001","00000001"   // 开 PSM，T3324=10s, T3412=2h（八位组编码）
AT+CEDRXS=1,5,"0100"       // 开 eDRX，周期编码

AT+NSOCR="UDP",17,5000,1   // 建 UDP socket，返回 socket id（如 0）
AT+NSOST=0,"1.2.3.4",5683,12,"0201AABBCCDDEEFF00112233"
                           // socket 0 发 12 字节 hex 数据到指定地址
AT+NSORF=0,128             // 读下行数据
AT+NSOCL=0                 // 关闭 socket

几个要点。AT+CPSMS 的后两个参数是八位组编码的定时器值，"01000001" 解出来是 T3324 = 10 秒（高 3 位是单位，低 5 位是值），T3412 的 "00000001" 单位是 2 小时（每单位 2 小时，最大 310 小时）。别手算，用厂商提供的编码工具或直接读模组文档的对照表。

发 CoAP 时用 AT+NSOST 发 UDP 到 5683 端口即可，CoAP 报文（含 CON/NON、token、option）自己按十六进制拼。这也是 CoAP 与 LwM2M 里讲的「NB-IoT 上跑 CoAP 而非 MQTT」的原因：CoAP 基于 UDP，头部只有 4 字节，不需要 TCP 握手和长连接保活，省电得多。

AT+CSQ 的信号值偏低（比如低于 10）时，设备应该考虑增加重复传输等级或检查天线。NB-IoT 的附着流程在弱信号下会触发大量重复传输，单次通信从 3 秒膨胀到几十秒，这是电池寿命的隐形杀手。

13. 选型对比表

一条经验线：设备数量超过几千、场地集中、想自己掌控网络和数据，选 LoRa；设备分散在全国、需要开箱即用、数据量或实时性要求高，选 NB-IoT。两者也常混合：NB-IoT 做骨干回传，LoRa 做本地汇聚。

14. 权衡取舍

一条贯穿的原则：LPWAN 的每一个参数都在「距离、速率、功耗、延迟」之间做交换，没有免费的午餐。做设计时先把占空比预算和电池预算算出来，再倒推能支持的上报频率和数据量，而不是先定需求再去撞限制。

15. 常见坑清单

1. 现象：设备入网后频繁掉线，日志显示 Join 失败。原因：DevNonce 被服务器记录且设备重启后重复使用。规避：把 DevNonce 持久化到 Flash 并递增，或确保能正确恢复会话上下文。
2. 现象：重烧固件后服务器不再接收数据。原因：帧计数器 FCnt 归零，被服务器的重放保护拒绝。规避：服务器侧重置该设备的帧计数，或把 FCnt 一起持久化。
3. 现象：EU868 下设备上报被网络静默丢弃。原因：超过 1% 占空比限制。规避：算清每小时的 ToA 总和，用 ADR 降 SF，或降低上报频率。
4. 现象：LoRa 实测距离远低于标称的十几公里。原因：天线净空不足、SF 选得太低、或城市环境遮挡严重。规避：天线离地高度和净空优先，用 SF12 做链路余量测试再逐级降。
5. 现象：NB-IoT 模组休眠电流远高于手册标称。原因：未真正进入 PSM（网络未下发 PSM 参数），或串口/GPIO 悬空漏电。规避：用 AT+CPSMS? 确认网络生效值，未用引脚配成下拉或输出。
6. 现象：NB-IoT 上行 CoAP 报文丢失且无响应。原因：NON 类型报文无 ACK，弱信号下重复传输失败无人知晓。规避：关键数据用 CON 类型，或用应用层确认。
7. 现象：SF12 设备把网关容量拖垮。原因：远距离设备长期占用信道，ToA 是 SF7 的 24 倍。规避：开 ADR，或给远距离设备设更长的上报周期做公平性调度。
8. 现象：LoRaWAN 下行指令迟迟收不到。原因：Class A 只在设备上行后的两个窗口可收下行。规避：改用 Class C（有电源）或让设备定期上行作为下行机会。
9. 现象：移动追踪器用 ADR 后丢包严重。原因：ADR 基于旧位置给速率，移动后链路变差不适应。规避：移动设备关闭 ADR，或使用移动 ADR 特性。
10. 现象：电池实测寿命远短于估算。原因：忽略了唤醒期间的峰值电流、模组附着重试、或电池低温容量衰减。规避：用库仑计实测完整工作周期，按最坏温度下的容量打折估算。

16. 小结

LPWAN 的选择可以归纳成一条决策链：先看有没有运营商覆盖和能不能接受月租，再看数据量、实时性和移动性，最后用占空比预算和电池预算校验可行性。LoRa 赢在电池寿命、自建网络和零月租，输在速率、下行能力和移动性；NB-IoT 赢在覆盖、速率和开箱即用，输在单次通信电量和月租成本。

技术上最需要建立直觉的是两件事：一是 ToA 与占空比的联动，它决定了 LoRa 网络能承载多少设备和多高的上报频率；二是 PSM 与 eDRX 的区别，它决定了 NB-IoT 设备是「深度不可达」还是「周期性可达」，直接影响应用层协议（推还是拉）的设计。

下一步建议：把 LPWAN 接上应用层协议，看 CoAP 与 LwM2M 怎么在窄带链路上做设备管理；把设备接入平台，看 物联网架构总览 里终端、网关、平台三段的分工；如果网络里需要跨节点时间同步（比如 LoRa 的 TDMA 或电力场景的采样对齐），参考 PTP 时间同步 。