LPWAN深度解析：LoRa、NB-IoT、Sigfox选型与实战避坑指南

做物联网项目做到第三年的时候，我头一次认真研究LPWAN，是因为接了个地下管网监测的单子。甲方要求在一百多个检查井里装水位传感器，一节电池顶两年，井盖盖上以后还能把数据传回三公里外的云平台。Wi-Fi、蓝牙、Zigbee全算了一遍，没有一个能同时满足这四个字：低功耗、远距离。后来方案里写入了LPWAN，这个项目才真正落地。

LPWAN的全称是Low Power Wide Area Network，国内通常叫低功耗广域网。它不是一个具体技术，而是一类技术的总称，解决的核心问题是：用极低的功耗，把公里级别的无线连接稳定做出来。说人话就是——让一个电池供电的小传感器，在没人管的情况下，安静地跑上好几年，还能把数据传到几公里外。

这篇文章就是围绕LPWAN的一次深度拆解。我会把LoRa、NB-IoT、Sigfox这三条主流技术路线的底层逻辑讲清楚，再给出一套我实际做项目时用的计算方法，最后聊聊那些链路预算表上看不见的坑。内容偏工程实操，适合正在做物联网方案选型、或者刚接触LPWAN想搞明白原理的工程师。

1. 先搞清楚一个问题：无线连接为什么只能“二选一”

1.1 短距无线和蜂窝网之间的空当

在LPWAN出现之前，物联网设备做无线连接，基本只有两个选择。

第一类是短距无线：Wi-Fi、蓝牙、Zigbee，以及后来很火的Z-Wave、Thread。这类技术的共同特点是覆盖范围就在几十米到一百米量级，站在路由器旁边测速可以跑满百兆，但穿一堵承重墙就掉一半信号。Wi-Fi功耗高，不适合电池设备；蓝牙和Zigbee功耗低，但为了压低功耗，发射功率也相应缩水，通信距离就上不去。这类技术适合的场景是智能家居、可穿戴设备——设备就在你身边，电源也好解决，不需要跟几公里外通信。

第二类是蜂窝网：2G、3G、4G，现在还有5G。覆盖确实广，全国任何有基站的地方都能连上，而且带宽大，能传视频。但代价也摆在明面上：模块贵，当年一个4G模块要几十上百块；功耗高，动不动几瓦的峰值功率，电池根本扛不住；还要插SIM卡、交流量费、做运营商入网认证。对用电不愁、数据量大的车载、安防监控这类场景，蜂窝网很合适，但对一个“每天只传几十字节状态”的传感器来说，有点像拿卡车运一封信。

中间这个空当，就是LPWAN的生存空间。传感器数据量极小，位置却可能散布在几平方公里甚至更大的范围里，且大多数没有供电条件，只能靠电池。这里真正要的不是“更快”，而是“更久更远更便宜”。

1.2 LPWAN到底重新平衡了什么

LPWAN的聪明之处，是它调整了“无线通信成本”的分配方式。

传统的无线通信追求高吞吐、低时延，所有物理层设计都在为这个目标服务，代价就是功率高、模块复杂、成本降不下来。LPWAN反过来，它把速率压到极低——通常在0.3kbps到50kbps之间——用这个“慢”换取了几样东西：更远的覆盖、更低的功耗、更简单的协议和更低的模块成本。

可以这样理解：Wi-Fi像开私家车，快，但烧油多、停车费贵；LPWAN像寄平信，一封信两块八，一个星期才送到，但一个月寄三十封也花不了多少钱。物联网里绝大多数业务，本来就是平信级别的业务——水位、温度、湿度、设备状态、位置信息，数据量以字节计算，时延可以容忍到秒级甚至分钟级。

除了低速率，LPWAN还有一个共同点：网络结构呈星型或类星型。终端直接连网关或基站，不经过多级路由。这一点跟Zigbee这类Mesh网络完全不同。Mesh网络里节点之间互相转发，优点是节点可以互相“借道”，缺点是每个节点都要随时准备帮别人转发数据，睡眠就不可能睡得太死，网络越大时延越难控制。LPWAN选择让终端只跟自己最近的基站通信，终端大部分时间可以深度睡眠，只在需要上报时醒来，发完继续睡。

正是这种“平时关机、偶尔醒一下”的机制，才让无线通信的平均功耗降到了微安级别。这是LPWAN低功耗的真正来源，而不是某些宣传里说的“用了某种神奇芯片”。

2. 三大技术流派的底层逻辑：LoRa、NB-IoT、Sigfox

LPWAN这个概念下面，真正在工程上大规模落地的主要是三条技术路线：LoRa/LoRaWAN、NB-IoT、Sigfox。这三家解决的问题一样，但底层的思路完全不同，用一句话概括：LoRa靠扩频，NB-IoT靠把蜂窝网变窄，Sigfox靠把消息变短。

2.1 LoRa：把信号埋在噪声下面的扩频技术

LoRa很特别，其他无线技术都在努力把信号功率集中，它却反着来，把信号能量摊开到一个很宽的频带上发送。这种调制方式的学名叫Chirp Spread Spectrum，中文叫啁啾扩频。

怎么理解呢？想象在一间很吵的房间里普通人说话，你很难听清对方说什么。但如果对方不直接说话，而是用一种只能在某个频率范围里扫过的“滑音”来表达，你的耳朵会更容易在背景噪声里把它识别出来。LoRa就是这样，每一个bit的信息用一长串频率连续变化的chirp来编码，接收端用同样方式的chirp做相关运算，即使信号功率低于噪声底，也能把信息解调出来。

这就是LoRa接收灵敏度能到-137dBm甚至更低的原因。相比Wi-Fi常见的-90dBm左右，-137dBm意味着可以接收比噪声还低20dB的信号，相当于在嘈杂房间的角落听见一根针落地的声音。代价是速率极低，SF12 + 125kHz带宽时有效速率只有250bps左右，传10字节payload都需要一秒量级。但物联网上报数据从来不在乎快，在乎的是能不能传到。

工程上需要注意一点：LoRa只是物理层调制方式，LoRaWAN才是真正定义网络协议的MAC层标准，包括终端如何入网、如何省电、如何做加密、基站和服务器之间怎么通信。很多人把两者混为一谈。实际项目中你选的模块是LoRa芯片，组网还是要走LoRaWAN协议，否则不同厂商的模块没办法互通。LoRaWAN把终端分成Class A、B、C三种模式，最基本的是Class A：终端发一条上行消息后，在固定的两个时间窗打开接收窗口等下行。这是我们最常用的模式，最省电，但下行只能在终端醒来之后做。

2.2 NB-IoT：把蜂窝网“砍窄”成适合物联网的样子

NB-IoT的思路完全不是从零设计一种通信技术，而是在成熟的LTE基础上做减法。LTE一个物理资源块是180kHz带宽，NB-IoT干脆整个上行和下行都只用180kHz，丢掉那些物联网用不上的能力，把天线复杂度、基带复杂度降下来，同时借助LTE已有的重传机制，把覆盖做上去。

重传是NB-IoT提升覆盖的核心手段之一。同一个数据块，基站会多次重复发给终端，终端也把数据重复发给基站，接收端合并多次接收的能量来解调，等效于把路径损耗预算从传统LTE的140dB左右拉到了164dB。164dB的MCL（最大耦合损耗）意味着终端在比设计标准远很多的位置、甚至地下室里，依然能注册上网。

NB-IoT工作在运营商的授权频段上，这是它跟LoRa最本质的区别。LoRa用的是ISM免授权频段，谁都能用；NB-IoT用的是运营商拍来的频谱，别人不能乱用，所以干扰可控、服务质量有保障。代价是必须由运营商建网，终端需要插SIM卡或者eSIM，还要付资费。但好处也很明显：你不用关心网关在哪、信号覆盖怎么样，因为网络是运营商运维的。

我做项目时对NB-IoT最深的感受是：模块本身的技术指标不差，但能不能用得好，很大程度取决于你所在地区运营商的覆盖和网络调优。同一个模块，在A城市地下室信号满格，在B城市路边树荫下可能入网都要重试多次。这个不确定性在项目选址阶段就要考虑进去。

2.3 Sigfox的极简主义：每条消息短到不用分帧

Sigfox走了一条更极端的路。它使用超窄带技术，每条上行消息占用的带宽只有100Hz左右，一次传输的消息用户payload最长12字节（实际可用更少），上行速率约100bps。因为没有复杂的分帧和纠错编码，接收机可以在极低的信噪比下解调，链路预算做到149dB左右，覆盖也不错。

Sigfox最巧妙的设计，或者说最商业化的设计，是网络本身不由终端用户建设。Sigfox公司自己或者授权合作伙伴在各地部署基站，用户买Sigfox模块，按年付订阅费，就可以在全网范围内上报消息。这让它有点像“物联网界的邮局”——不管你身在何方，只要把那封信投进邮箱，邮局负责送。

这个模式听起来很好，实际用起来有几个掣肘。一是下行能力弱，每天也就允许少数几条下行，而且每条很短，基本只能用于设备配置，别指望做实时控制。二是网络覆盖依赖当地Sigfox运营商的经营状况，有些地区运营商退出，设备就变成一堆废铁。近几年Sigfox业务在全球收缩明显，选型时如果它背后没有本地强运营方，风险是实实在在的。

2.4 三大技术流派关键参数对照

这张表不是让你抄完就拍板，但它能帮你快速排除明显不适配的方向。在后续章节里，我会讲清楚排除之后怎么用数据做最终选型。

3. 链路预算、电池寿命和容量的计算门道

3.1 链路预算：从-137dBm到-164dBm到底意味着什么

无线工程师做无线覆盖评估，第一个要做的就是链路预算。公式不复杂：

链路余量 = 发射功率 + 发射天线增益 + 接收天线增益 - 路径损耗 - 接收灵敏度 - 其他损耗

链路余量是正数且越大，链路越可靠。一般工程上要求余量至少留10~20dB，不能刚好卡在0dB，因为环境会变化：雨雪、树木枝叶含水量、金属物体移动、邻频干扰，都会让信号在某个时间段突然变差。

举个例子。某LoRa终端发射功率20dBm，终端天线增益2dBi，网关天线增益3dBi，终端到网关的距离为3km，对应自由空间路径损耗大约110dB（470MHz频段）。那么：

接收信号功率 = 20 + 2 + 3 - 110 = -85dBm

如果网关接收灵敏度是-137dBm，则链路余量 = -85 - (-137) = 52dB。看起来余量充足，但你注意，这个计算用的是自由空间模型，现实中有地面反射、建筑遮挡、树木吸收，真实路径损耗可能比自由空间大20到30dB。所以余量留52dB不是浪费，是给自己留安全垫。

NB-IoT的164dB最大耦合损耗是怎么理解呢？它表示从终端发射功率23dBm出发，信号经过164dB衰减后，接收端还能解调。23 - 164 = -141dBm，也就是说基站接收机等效灵敏度做到了-141dBm。这个数字看起来比LoRa的-137dBm更好，但请注意，这是通过多次重复传输、合并接收获得的，实打实付出的代价是时延变长、终端活跃时间变长、功耗上升。

我在实际项目中不会只盯着这些极限值。极限灵敏度是实验室数据，真实环境里，一个LoRa节点在SF12下能稳定跑3km，换成SF7（速率变快、灵敏度变差）可能只能跑1.5km。所以链路预算算完之后，一定要去现场做打点测试。选点的原则是：最远点、遮挡最严重的位置、以及金属结构密集的区域，都要放测试终端，每个点位至少测20次以上再统计丢包率。

3.2 电池寿命估算：真正耗电的不是发射那一下

很多新手做电池寿命估算时，会错误地把“发射电流”当成大头，然后得出一个过于乐观或者过于悲观的结论。实际上，LPWAN终端真正的生命线是睡眠电流。

我们做一个具体的估算。某LoRaWAN节点，每天上报一次，每次发射10字节payload，使用SF7、带宽125kHz，发射时间大约50ms。发射时电流按120mA算，接收窗口按两个窗口各20ms、电流约40mA算，睡眠电流按3uA算。一天的功耗构成：

• 发射耗电：120mA × 0.05s ≈ 6mAs
• 接收耗电：40mA × 0.04s ≈ 1.6mAs
• 睡眠耗电：3uA × 86400s ≈ 259mAs

等于睡眠这一项占据了总耗电的绝大部分。如果用一节2300mAh的锂亚电池，按可用容量80%计算，理论寿命大约是：

2300mAh × 0.8 / (平均电流大约3.1uA) ≈ 593,548小时 ≈ 67年

这个数算出来明显超过电池自放电寿命，实际项目里一节锂亚电池的自放电和钝化会让有效寿命降到5~8年。所以结论很清楚：做长寿命LPWAN节点，选一颗睡眠电流小于2uA甚至1uA的MCU，比纠结发射时能否省几毫安电流重要得多。睡眠电流每高1uA，电池寿命可能直接砍掉三分之一。

NB-IoT的情况更复杂一些。NB-IoT终端每次上报前要经历搜网、同步、注册、发送、连接释放整个流程，如果PSM配置不好，终端在空闲期也可能消耗几百uA甚至毫安级电流。我实测过一个NB-IoT模块，在信号较好的地方（RSRP约-90dBm），每天上报一次，PSM配置合理，平均电流能压到30uA左右；但在信号弱到-115dBm的环境，同样的上报频率，平均电流飙到了300uA以上，电池寿命从几年直接缩水到半年。这就是为什么NB-IoT项目必须拿着实际使用位置的信号强度去做功耗评估。

3.3 单网关能带多少节点：扩频因子、Airtime与冲突

LoRaWAN网络的容量评估是另一个容易翻车的地方。厂商宣传里写“单网关支持几万个节点”，那是建立在每个节点每天只发几条消息且SF分布理想的极限假设下。

LoRaWAN是纯ALOHA协议，节点发消息不看别人有没有在发，冲突了就会丢包。评估容量要用“空中时间”Airtime来做。Airtime跟三个参数直接相关：扩频因子SF、带宽BW、payload长度。SF7时，10字节payload的Airtime大约是46~56ms；SF12时相同payload的Airtime飙到1.4秒以上，相差将近30倍。所以ADR（自适应数据速率）非常关键——把距离网关近的节点调到SF7或SF8，让它们占用更短的Airtime，才能把网关整个频域的容量甩出来。

做个粗略计算：假设一个8通道LoRaWAN网关，每个通道每小时可以承载的空中时间上限约3600秒，考虑冲突余量取20%有效利用率，即每个通道720秒有效传输时间。如果所有节点都用SF7，每节点每小时上报一次，每次占用0.05秒，那么单通道每小时能承载720 / 0.05 = 14400次传输，8个通道就是11.5万次。理论上可以带很多节点。

但这是极端理想情况。现实里远距离节点必须用SF10~SF12，Airtime大幅拉长，而且数据上报是随机时间点触发的，短时间内可能扎堆。做工程估算时，我通常按“峰值时段每网关每小时最多支持节点数 = 8通道 × 3600秒 × 0.15利用率 / 平均Airtime”来算，再按峰值流量是平均流量3~5倍的系数倒推节点数。这么算下来，一个8通道网关，如果节点每小时上报一次、大部分用SF7，稳定带2000到3000个节点没有问题；如果全部要用SF12，那可能只能带几百个。规划网关密度前，先把这个数字算清楚。

4. 实战落地时绕不开的四个坑

4.1 选型先看三件事，不是看谁的信号“看上去远”

选LPWAN技术时，大多数人第一反应是看覆盖距离，谁的链路预算大选谁。这个思路有个致命问题：链路预算只是纸面参数，真实网络好不好用，取决于你能不能控制它的部署和运营。

我的选型习惯是问三个问题。

第一个问题：数据量多大、上报频率多高？如果每天上报一次、每次几字节，LoRa、NB-IoT、Sigfox都够用。如果每小时上报一次、每次发几十个字节，Sigfox的12字节用户payload上限会是一个硬卡点，LoRa和NB-IoT更合适。如果数据量大到几百KB一次，LPWAN整个品类都出局，应该转LTE Cat.1甚至5G。

第二个问题：网络谁建设、谁维护？用户现有环境中没有运营商覆盖，或者希望在矿山、农场、水利这些偏远场景自己有掌控权的，优先LoRa——网关一买，覆盖自己做主。城市里尤其是地下空间、表计这类，运营商基站已经覆盖到位的，NB-IoT能省掉自建网关的运维成本。Sigfox则要看当地运营方是否稳定，几年后还在不在。

第三个问题：终端能不能容忍较高的峰值电流和入网时延？NB-IoT弱信号下入网时间可能长达数秒甚至数十秒，平均功耗指数级上升。LoRa终端没有入网注册流程（入网后保持激活状态），每次上报就是秒醒秒发。如果设备靠能量采集供电，比如太阳能板+电容，LoRa这种快速发射的机制比NB-IoT更容易设计。

去年给一个水厂做设备状态监测，我在这三个问题上卡了两个小时，最后拍板LoRa而不是NB-IoT，核心原因就是现场没有运营商信号，且甲方要求网络完全内网化，数据不许出园区。选对了路线，后面实施会顺利很多。

4.2 网关安装的高度和天线，直接影响两倍以上的覆盖半径

LoRa项目里，网关位置选得好不好，对覆盖半径的影响是倍数级的。自由空间里路径损耗随距离平方增加，但实际地面场景还要叠加第一菲涅尔区遮挡和地面反射。网关天线从2米高度升到10米，覆盖半径翻倍是常态，有些开阔场景甚至能翻三四倍。

我看到过最典型的翻车案例：客户把LoRa网关放在室内机柜里，外置天线躺倒在机柜底部，旁边就是一大块金属背板。测试时终端离网关两百米都丢包，后来我们把天线用馈线引到屋顶，同一个终端在八百米外还能稳定上报。问题不在设备，而在天线位置。

天线选型也有讲究。全向玻璃钢天线适合覆盖四周，定向八木天线适合远程定点中继。馈线越短越好，线缆损耗是实打实的——一个3dB损耗的馈线，等于发射功率直接砍半。我在现场做网关安装检查时，一定会确认天线周围至少1米内没有大型金属物体，天线竖直安装，且避雷措施到位。另一个容易忽略的点是LoRa网关的发射功率远没有终端大，网关到终端的下行链路往往比上行差，所以网关天线增益和位置高度，直接决定你的下行能不能覆盖到远点。

4.3 上下行不平衡：LoRa不是用来做控制的

LPWAN很多资料在讲低功耗，但对下行能力一笔带过。实际上，下行受限是LPWAN最大的隐性约束。

以LoRaWAN Class A为例，终端平时处于深度睡眠，它完全不知道服务器什么时候有消息要发给自己。只有它主动发上行消息之后，才在1秒和2秒左右打开两个接收窗口等下行。这意味着服务器要给某个终端发指令，必须等这个终端下一次主动上报。如果你的业务是远程开关阀门、远程升级固件、远程调整参数，这种不确定的分钟级甚至小时级时延会让你很痛苦。

Class C模式可以解决时延问题——终端几乎一直开着接收窗口，服务器随时能下发指令。代价是终端几乎不睡觉，功耗回升到毫安级，这对电池供电场景基本不可接受。Class B通过GPS或网关同步信标做定时接收窗口，功耗折中，但工程实现复杂，实际应用也不多。

NB-IoT虽然有寻呼机制，下行时延比LoRa好很多，但终端在PSM模式下同样存在“睡着了收不到消息”的问题，只能等终端主动发起数据业务或者寻呼窗口到来。Sigfox的下行能力更是弱到只能做设备配置级别。

所以，如果你在做一个双向控制的物联网系统，别天真地以为用了LPWAN就能像4G一样随时遥控。比较务实的架构是“节点主动订阅”模式：控制指令先缓存在服务器，节点每次上报数据时顺带拉取待执行指令并执行。这样既保持了节点的低功耗，又能完成控制任务，代价是把控制时延变成上报周期的倍数。做智能灌溉、远程阀门这类项目，我会先跟甲方确认能接受的最长控制延迟，再倒推上报频率。

4.4 免授权频段的干扰和占空比，比想象中麻烦

LoRa和Sigfox用的都是免授权ISM频段，这个频段的好处是无需申请、免费使用，坏处是大家都能用——对讲机、无线抄表、工业遥控器、其他LoRa网络，全都挤在一起。

LoRa的扩频调制确实有很强的抗干扰能力，它可以接收比干扰信号低20dB的目标信号，但这是有限度的。我做过一个工厂项目，现场有一台变频器的宽频噪声恰好压在两个上报信道上，导致那一片区域的节点丢包率从1%飙升到30%。排查了很久才发现是产线运行噪声，最后解决方案是换信道、调SF参数，并在干扰源附近加了一个中继节点。

另外，免授权频段还有法规层面的占空比限制。比如欧洲868MHz频段要求每个频带每小时发射时间不超过1%，意味着一个节点每小时最多只能发射36秒。中国470-510MHz频段也有相应的微功率短距离设备管理要求，设备需要遵守单次发射时间、功率上限等规定。具体的数值每年都在调整，项目正式落地前要去查当地最新的无线电管理规定，别等设备批量部署了才发现违规。

这里有个实用检查手段：在部署地做一个24小时频谱扫描，记录底噪水平和干扰源出现的时间段。如果底噪比理想值高很多，说明这个频段环境不太干净，要么换频段，要么提高发射功率或改SF参数。真正好的LPWAN部署，不是把买来的设备装上去就完事，而是先花一两天把现场无线环境摸清楚。

我自己做LPWAN项目快四年，最大的体会是：这项技术适合的场景鲜明，但也有明显的边界。它适合“小数据、长周期、分布广、难供电”的设备，不适合对速率、时延、双向实时性有要求的业务。每一次项目选型，我都会把数据量、上报频率、网络覆盖范围、运营成本、电池寿命这五件事写在纸上算一遍，而不是盲目追新。LPWAN解决不了所有物联网连接问题，但在它擅长的领域，它确实是目前性价比最高、工程上最可靠的答案。