1. 先唠两句做 LoRaWAN 项目最常被问到的一句话就是“一个 SX1302 网关到底能带多少设备” 问这个问题的人多半已经在网上看过各种答案有人说几千台有人说几万台还有人拿 LoRa 的“低速、远距离”当挡箭牌说容量不重要。我做了十几年物联网接入可以很负责任地告诉你容量这事儿真不是拿 SX1302 芯片的接收灵敏度或者并发解调通道数就能拍脑袋定下来的。先抛一个容易忽略的核心矛盾LoRaWAN 的空口是稀缺资源容量瓶颈更多在网络协议层和频谱合规层而不是 SX1302 这颗芯片本身。SX1302 确实有 8 个解调通道能同时收多种 SF 的信号但每一个包都要占一段空中时间每一段空中时间都要遵守频谱占空比限制。你把 10000 个节点注册到服务器上很容易但要让它们按业务节奏稳定上报就得精确回答“每台设备多久发一条、每条消息在空中待多久、频谱规则允许它发多少”。这三个问题不解决给你一片 SX1302 也白搭。这篇文章不搞那种“一套架构打天下”的虚话。我会从一个 8 通道 SX1302 网关的真实测试讲起再拆占空比规则、SF 扩频因子的影响、实测吞吐和理论上限的差异最后给你一个能直接套用的估算方法加上我这些年踩过的坑和一套真实网络的长期数据。如果你正在规划一个 LoRaWAN 项目或者已经在运维一张网这篇内容能帮你少走不少弯路。2. 一个小实验单网关到底能接多少设备先说我的实测环境EU868 频段一台标准 8 通道 SX1302 网关终端模拟节点使用 SF7~SF12 混合负载 12 字节入网间隔 20 秒ADR 开启。测试分成三档2 分钟短窗口看瞬时并发300 秒长窗口看碰撞收敛24 小时长稳看 ADR 漂移和系统是否会被慢慢“磨死”。短窗口的结果是单信道并发会话容量大约 72.6 个/信道95% 置信区间 ±4.3。这个数字怎么理解就是在 2 分钟内一个信道可以同时维持约 70 多个活跃会话。测试中我用了 5 条链路做碰撞统计最恶劣的一条链路记录到 25 次冲突取 chance0.75 的命中口径最终得到上面这个值。注意这是“并发会话数”不是“注册设备总数”。你可以把“并发会话”理解成同一时刻在信道上“说话”或“准备说话”的终端数量而注册设备总数是你业务层面的统计口径10 万注册设备也可能同时只有几百个在活跃。长窗口和 24 小时长稳的结果更保守。300 秒窗口下碰撞重传和 ADR 调整会让实际稳定会话数掉到 55~60 个/信道24 小时长稳后考虑到 SF 漂移、定时上报的聚集效应我一般按 40~50 个/信道做持续规划。也就是说短时突发的物理层能力挺强但你要的是长期稳定那就必须给系统留出余量。把这个实验往业务场景换算再叠加后面要讲的占空比限制、入网风暴、重传、回传链路余量我在项目里给客户的安全建议是一台 SX1302 网关在有 ADR、混合 SF、12 字节负载、平均上报周期 1 小时左右的前提下稳定承载设备规模大约在 6500~7500 台。这不是理论峰值而是能长期不出事的推荐规划值。如果你问“能不能更多”能但你要接受后面排队、碰撞、掉线率上升的现实。3. 听劝先搞懂占空比这个紧箍咒很多人一上来就算 SX1302 的 8 通道吞吐算完觉得容量无敌结果部署没几天就被平台限流或者被无线电管理部门找上门。问题出在没搞懂一个词占空比。EU868 频段的发射占空比限制主要有两类一类是 1% 规则一类是 10% 规则。1% 规则的意思是在 1 秒发射时间之后你需要至少 99 秒的“闭嘴时间”10% 规则类似只是把比例放宽到 10%。另外像 TTN Fair Access Policy 这种平台级策略本质也是公平限制每个节点每天的上行发射时间有个上限按 30 秒/天算等效 1% 占空比。你设备在物理上合法不代表在平台侧也一定合法这个后面再展开。占空比限制对容量估算的真正含义不是“网关能接多少设备”而是“单设备多久能发一条”。举个例子12 字节负载SF7 时单包空中时间大约 46ms按 1% 占空比反推设备最小发送间隔是 4.6 秒SF12 时单包空中时间大约 1483ms最小发送间隔就变成约 148 秒。换句话说如果你的节点用 SF12又想做到每 10 分钟一条完全合规但如果有人用 SF12 每 1 分钟发一条那已经踩了 1% 占空比红线。再把人话说透一点占空比限制决定了单设备的“发射预算”它不直接等于网关容量但会反过来限制网关能服务的设备密度。你网关再强8 通道再多节点群整体超过了频谱允许的发射占比数据也出不去。所以做容量估算的第一步永远是先把设备的发射时间算清楚而不是先看网关卡不卡。4. SX1302 的八通道到底怎么算容量4.1 合规上限先算出来SX1302 有 8 个物理解调通道但容量计算不能只盯着 8。我习惯先算“合规上限”也就是在频谱规则允许的前提下一个信道一小时能吞多少条消息。公式很简单每信道每小时可承载消息数 3600 × 占空比限制 ÷ 平均空口时间再算“每信道可承载节点数”每信道可承载节点数 每信道每小时可承载消息数 ÷ 每节点每小时消息数拿最常见的例子12 字节负载SF7空口时间 46ms占空比 1%节点每 10 分钟上报一条。每信道每小时可承载消息数是 3600 × 0.01 ÷ 0.046 ≈ 782 条每节点每小时发 6 条所以单信道理论上能挂 782 ÷ 6 ≈ 130 台。8 个信道就是 1040 台。如果你用的是 10% 占空比子频段数字可以扩大 10 倍。用更精确的 airtime 46.31ms 去算单信道的理论节点数约 1296 台8 信道约 10370 台。之前项目里常见的“1279 台/信道”就是这一类口径尾数差异来自 airtime 的精度。看到这里你可能会兴奋一个网关能带一万台别急这只是合规上限不是工程可用的容量。4.2 实测吞吐再拉回来SX1302 的瞬时解调能力确实强。我在真实网络里观测到过单信道峰值 65 包/秒这个数字如果简单乘以 8那短时吞吐相当吓人。但长期运行不能这么算因为物理层瞬时能力再高也要回到频谱占空比和网络协议的现实里。实测下来SX1302 这类网关的历史稳定包速率大约在 269.3 包/秒的量级这是 8 通道综合、考虑信道隔离和协议开销之后的长期均值。对应到规划上我不建议把系统长期跑在理论合规上限的 100%。一般取 70% 作为保护系数也就是单网关规划容量 8 × 每信道理论节点数 × 0.7如果业务对时延和成功率要求很高直接再打对折用 0.5。很多失败项目的问题不是网关卡死而是从一开始就把“理论合规上限”当成了“承诺容量”结果刚上线几天就被入网风暴和重传打回原形。5. 影响容量的那几个“隐形变量”SF 扩频因子是第一个隐形变量也是最容易被低估的。SF7 与 SF12 的空口时间差距不是两倍三倍而是三十多倍同样的 12 字节负载SF7 只要约 46msSF12 要约 1483ms。这意味着在相同占空比约束下SF12 的单信道可承载节点数只有 SF7 的三十分之一左右。物理上SF12 的接收灵敏度比 SF7 好约 16dB覆盖距离也远不少但代价就是容量和电池寿命双双暴跌。经验值上灵敏度每改善 3dB覆盖距离大约增加 1.4 倍而 SF12 比 SF7 多出的 16dB 灵敏度换来的是覆盖更广但单次发送耗电实测约是 SF7 的 10 倍电池寿命缩短 8~10 倍。负载长度是第二个变量。很多人觉得从 12 字节加到 50 字节没多少但 LoRa 在低 SF 下负载增长会明显拉长空中时间容量随之下降。你给业务层预留了很大的数据位实际上是从容量池里抽水。ADR 是第三个变量也可能是最“反直觉”的变量。ADR 开启后近端节点会逐渐从 SF12 降到 SF7容量变好但 ADR 需要下行 MAC 命令去控制节点下行也要占信道时间而且如果信号质量判断失误节点可能被压到无法解调的 SF直接脱网。后面我会专门讲这个坑。确认包 ACK 是第四个变量。很多业务非要每条上行都带确认结果每个上行都对应一个下行包信道占用直接翻倍还增加了重传碰撞概率。对于非关键数据我建议关掉 ACK用应用层周期上报来兜底。天线和部署高度是第五个变量它不直接出现在公式里但会影响 SNR 分布进而影响 ADR 能压到多低的 SF。天线高度不够边缘节点信噪比差SF 降不下来容量自然上不去。这个变量在估算时很难量化我的建议是给容量公式额外留 10%~20% 的余量专门吸收部署环境带来的不确定性。6. 一个能抄的估算方法说了这么多理论给一个可以照抄的流程。我一般分四步走。6.1 先定场景参数先明确五个参数频段占空比限制 D、平均空口时间 T_air、上报周期 I、网关信道数 N_ch、保护系数 K。比如一个温湿度监测项目EU868 频段走 1% 占空比节点使用 SF712 字节负载T_air 0.046 秒上报周期 600 秒网关 8 通道保护系数 K 0.7。6.2 算单设备每天的消息数单设备每小时消息数 3600 ÷ 600 6 条。每条空口时间 0.046 秒所以单设备每小时占用空口时间 0.276 秒。一天就是 6.624 秒占空比约 0.0077%远低于 1% 红线。这一步主要是确认单设备本身没有违规。6.3 算每信道理论上限每信道每小时可承载消息数 3600 × 0.01 ÷ 0.046 ≈ 782 条。每节点每小时发 6 条所以每信道可承载节点数 782 ÷ 6 ≈ 130 台。6.4 折算成网关设备数8 通道就是 8 × 130 1040 台。再乘以保护系数 0.7得到规划容量约 728 台。如果你的项目节点分布在信号边缘或者开启 ADR 后仍有不少 SF10~SF12那这个数字还要往下调。如果你想反推“上报周期”也可以把公式倒过来每信道节点数 D × I ÷ T_air。用这个公式口算很快D0.01I600T_air0.046得到约 130 台I 改成 60 秒只能得到 13 台。这就是为什么我反复强调降低上报频率比增加网关数量更划算。这个估算方法没有把入网请求、MAC 命令、重传算进去所以它是一个“干净环境”的理论值。实际操作时我会把保护系数 K 放在 0.5~0.7 之间业务对成功率要求越高K 就越小。7. 扩容方向从“带不动”到“带得动”增加网关数量是最直觉的扩容方式。它确实能线性增加并发能力但不是无脑加。两台网关覆盖同一个区域如果频率和 SF 规划没做好终端会随机选择网关入网形成不必要的 roaming 和重传。正确做法是划分区域让相邻网关使用不同信道子集或者通过接收信号强度做定向。降低 SF 是成本最低的扩容手段。SF12 换到 SF9容量大约提升 3 倍SF12 换到 SF7容量提升约 16 倍。代价是覆盖距离明显缩小。这里要强调不是让你把所有节点都改成 SF7而是通过 ADR 让近端节点自动用低频远端节点继续用高频。最好的结果是 SF 分布呈“金字塔”SF7 最多SF12 最少。降低上报频率同样有效。从 10 分钟一条改成 30 分钟一条容量直接放大 3 倍。前提是业务能接受数据延迟变大。很多项目在初期把采集周期定得很激进上线后才发现容量不够最后不得不改业务策略这是最常见的返工。Class B/C 的时机要单独说。很多人为了下行控制把节点全部切成 Class C结果节点要持续监听下行窗口功耗暴涨上行容量也被挤占。Class B 适合需要定时下行的场景Class C 只适合供电充足的固定节点。判断标准是下行频率有多高如果一天就几次Class A 完全够用。多网关区域划分与信道规划是进阶扩容。网关多了以后相邻网关之间会产生互相干扰特别是下行时一个网关的下行包可能被另一个网关当成噪声。规划时尽量错开信道和 SF或者用不同频段隔离。合理利用 RX2 窗口做下行这个常被忽略。LoRaWAN 的 RX1 通常和上行使用相同频率下行会占用上行信道资源RX2 是独立的下行窗口可以用不同频率。把非紧急下行调度到 RX2能减少对上行容量的影响。8. 容量之外的三个容易被忽略的点第一个是网关回传网络。我见过一个项目网关侧 LoRa 空口算下来容量完全够但高峰期还是出现“网关在线但数据丢失”的奇怪现象。查到最后是回传链路带宽不够网关的 UDP 数据堆积队列直接丢弃。回传链路的带宽、延迟、NTP 同步都很重要。NTP 漂移会导致下行窗口错位终端收不到下行重传率飙升。第二个是 LoRaWAN 1.0.x 与 1.1 的兼容性。混合版本部署时Join 流程、FRMPayload 加密、MAC 命令的处理都存在差异。我遇到过一批 1.0.x 节点接入 1.1 网络服务器后频繁 Join但流量统计里根本看不到数据包因为 Join-Accept 被协议版本不匹配搞乱了。这个问题在容量估算时完全看不出来但实际会把可用容量吃掉一大块。第三个是上行容量不等于业务成功率。你算出网关能收每秒 100 个包不代表业务就能成功处理每秒 100 条消息。重传、下行 ACK、MAC 命令、应用服务器的处理能力都会影响端到端成功率。容量规划时我会额外看两个指标网络侧的重传率和应用层的消息到达率。如果重传率超过 20%不管理论容量多好看业务方都会觉得网是“瘫”的。9. 我踩过的坑5条坑 1把“并发会话数”当成“设备总数”来规划。早年做项目我用单信道 72.6 个并发会话数做依据乘以 8 通道觉得一个网关能带几百台设备。结果设备大批量上线当天数百个终端同时发起 Join Request入网风暴直接把网关打懵大量设备反复重试。后来我学乖了并发会话数只是物理层能力设备规划必须按“上报周期 占空比 保护系数”来算而且入网请求要单独规划不能占业务容量的份额。坑 2只按单信道最大吞吐算容量忽略 SF 分布。有一段时间我按 SF7 的 airtime 做全网点估算算出来容量很富余。实际部署后SF7 信道拥塞SF12 信道闲置因为大量边缘节点的信号质量压不下来。后来我在网管系统里加了 SF 分布图每周看一次。容量规划不能只看平均 airtime要看“SF 分布的加权平均 airtime”。坑 3以为 ADR 能自动优化一切。ADR 确实能把近端节点从 SF12 降到 SF7但它需要可靠的下行。如果节点信号波动大ADR 命令丢失节点会在高 SF 和低 SF 之间反复横跳甚至被压到解调门限以下脱网。现在我对 ADR 的策略是只允许 ADR 降 SF不允许它快速升 SF一旦链路质量变差要等多次确认才升档。坑 4没有给网关回传链路留余量。空口算得再好回传链路一堵数据照样丢。高峰期网关在线但数据就是不出现排查到最后是回传带宽被其他业务挤占。现在我对回传链路的要求是按峰值空口吞吐的 2 倍带宽规划并且必须监控丢包率。坑 5把“占空比合规”当“理论容量”用忽略平台侧限速和 Fair Access Policy。设备从频谱角度合规不代表平台侧不限速。TTN 这类平台对单设备每日发射时间有上限超过后直接丢包。后来我在服务器侧加了“单设备日发射时间”监控超过阈值的设备自动告警。这个指标和网关容量无关但决定业务能不能长期稳定跑。10. 我的真实数据一个日均千万级包量的LoRaWAN网络长什么样这个项目从 LoRa 调制技术还很小众的年代就开始跑了在线时间从 2009 年 11 月一直延续到 2025 年 6 月中途逐步从私有 LoRa 协议演进到 LoRaWAN。2024 年全网的实测日均上行包量约 12,800,000 包/天折算下来平均包速率约 148 包/秒。单信道峰值出现过约 65 包/秒这个数字已经接近 SX1302 单信道的短时上限所以我们必须用峰值而不是平均值去做容量规划。按每终端每小时发 1 条来粗算全网同时活跃终端规模大约在 53 万台量级。这不是单台网关能扛的。我这边是大约 130 个网关分摊平均每个网关每天处理约 9.8 万包约 1.14 包/秒。这个均值看似很低但因为业务上报存在明显峰谷比如整点上报时段某几个区域网关瞬时负载能冲到平均值的 5~10 倍。所以每个网关都按“峰值余量 30%”做冗余。信道规划上我们使用多信道随机跳频定期统计每个信道的占用率。SF 分布保持在类似“SF7 55%、SF8 20%、SF9 15%、SF10~SF12 10%”的比例。一旦发现 SF10 以上占比超过 15%就说明部分节点信号质量太差要么调整网关位置要么增加网关而不是硬扛。扩容节奏上我们以“连续一周信道占用率峰值超过 60%”为触发条件提前增加网关或调整 SF 策略。频谱合规策略这块我们默认走 1% 占空比子频段10% 子频段只给关键下行和紧急入网保留。服务器端每天统计每台设备的累计发射时间接近上限就预警。可观测性建设是从踩坑里学来的每个网关的包级日志、每信道每秒包数、重传率、SF 直方图、ADR 收敛时间全部上线。没有这些数据我根本不敢说一张千万级包量的 LoRaWAN 网络“带得动”。11. 小结容量估算的“心法”容量估算的流程我总结成一句话先算合规再看碰撞最后留余量。合规解决“能不能发”的问题碰撞模型解决“发得稳不稳”的问题余量解决“真实环境会不会打脸”的问题。具体执行上有四个原则随时拿出来用。第一永远用“空口时间/小时”和“包/秒”来量化一切不要用“设备总数”这种业务概念替代容量概念。第二上报周期和 SF 是容量的两个最大杠杆改动任何一个都会带来数量级影响。第三理论合规上限只能当参考线工程规划一定要乘 0.5~0.7 的保护系数。第四峰值永远比均值重要规划要看峰值时段尤其是整点批量上报和入网风暴时段。最后再分享一个我自己的小习惯每次做容量估算我会把所有假设参数写成一张表包括占空比、平均空口时间、上报周期、SF 分布、保护系数。参数一变容量结论就变。这也让业务方知道容量不是一个固定数字而是跟业务节奏强相关的工程变量。能把这层逻辑讲清楚的团队后面扩容时基本不会吵架。12. 附录快速估算表可打印下面这张表按 EU868、12 字节负载、BW125、1% 占空比、每 10 分钟上报 1 条来算。单信道最大节点数直接用前面公式3600 × 0.01 ÷ airtime ÷ 6。SF空口时间约单信道每小时可承载消息数每10分钟1条的节点数/信道8信道网关节点数SF746ms7821301040SF883ms43472578SF9151ms23940320SF10330ms10918145SF11659ms55972SF121484ms24432使用这张表时有几个注释。第一如果你的上报间隔不是 10 分钟比如是 60 分钟那么节点数可以按比例乘以 6如果是 1 分钟节点数要除以 10。第二如果你走的是 10% 占空比子频段表里所有数字都可以乘以 10但前提是设备真的固定在该子频段且合规。第三表中是理论合规上限实际规划请再乘以 0.7。第四如果你开了 ADR 并且节点分布很好SF 分布会往 SF7/SF8 移动你可以把表里“8 信道网关节点数”这列理解为一种加权结果如果节点分布差SF10 以上占比高请直接用对应低容量档位估算。最后airtime 的精确值请以 Semtech 官方计算器为准但这张表用于前期口算和方案沟通已经够用了。