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、SigfoxLPWAN这个概念下面真正在工程上大规模落地的主要是三条技术路线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 三大技术流派关键参数对照对比项LoRa / LoRaWANNB-IoTSigfox调制方式Chirp扩频CSS窄带OFDMLTE裁剪超窄带BPSK工作频段免授权ISM频段中国470-510MHz、欧868MHz、美915MHz运营商授权频段如Band 8/20等免授权ISM频段868/902MHz典型带宽125kHz/250kHz180kHz100Hz级用户数据速率0.3kbps~50kbps上行约20kbps左右约100bps接收灵敏度-137dBm左右约-130dBm重传后等效更高极低信噪比可解调最大链路预算约157dB约164dB约149dB下行能力Class A弱Class C强但费电下行较完整支持短消息极弱每天几条组网方式自建网关运营商基站运营商专网资费模式无流量费自己买网关按SIM卡和流量计费按年订阅典型模块成本十几到几十元几十元十几到几十元适合场景工业、农业、自建网络场景智慧城市、表计、有运营商覆盖的场景极低频次上报且运营方明确的场景这张表不是让你抄完就拍板但它能帮你快速排除明显不适配的方向。在后续章节里我会讲清楚排除之后怎么用数据做最终选型。3. 链路预算、电池寿命和容量的计算门道3.1 链路预算从-137dBm到-164dBm到底意味着什么无线工程师做无线覆盖评估第一个要做的就是链路预算。公式不复杂链路余量 发射功率 发射天线增益 接收天线增益 - 路径损耗 - 接收灵敏度 - 其他损耗链路余量是正数且越大链路越可靠。一般工程上要求余量至少留10~20dB不能刚好卡在0dB因为环境会变化雨雪、树木枝叶含水量、金属物体移动、邻频干扰都会让信号在某个时间段突然变差。举个例子。某LoRa终端发射功率20dBm终端天线增益2dBi网关天线增益3dBi终端到网关的距离为3km对应自由空间路径损耗大约110dB470MHz频段。那么接收信号功率 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~56msSF12时相同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~SF12Airtime大幅拉长而且数据上报是随机时间点触发的短时间内可能扎堆。做工程估算时我通常按“峰值时段每网关每小时最多支持节点数 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解决不了所有物联网连接问题但在它擅长的领域它确实是目前性价比最高、工程上最可靠的答案。