尧图网页设计 
一个永远在变的数字“你们的网关能带多少设备”这是每一个 LoRaWAN 方案沟通会上被问到的第一个问题也是每一个采购经理在 Excel 表里最先填的格子。答案不在任何一份产品手册里因为同一个网关在真实部署中可能服务700 台设备也可能服务 20,000 台。硬件没变变的只有部署条件。这并不是销售在吹牛。一个 SX1302 网关在某些假设下确实能扛住数万台传感器——只是这些假设几乎从不被明确写出来。于是同一套硬件诚实地覆盖了两个数量级的部署量差距不来自硬件来自覆盖。本文把 LoRaWAN 网关容量这件事拆开来讲清楚硬件能给你什么、ALOHA 协议会拿走什么、工程上有哪些可调节的旋钮、最后给一个开箱可用的估算公式与三步决策流程。一、网关硬件给了我们什么1.1 SX1302 集中器8 信道 × 16 解调器现代 LoRaWAN 网关几乎都基于 Semtech SX1302 集中器。要谈容量先把这颗芯片的内部结构看清楚。Semtech 官方数据手册给出的 SX1302 内部构成8 个 125 kHz 频率信道8 路同时监听不同的中心频率16 个 LoRa 解调器分两组8 个支持 SF5–SF12远距离低速档8 个支持 SF5–SF10近距离高速档1 个125 / 250 / 500 kHz 高速 LoRa 解调器1 个 (G)FSK 解调器兼容旧协议最多65 个可配置逻辑信道灵敏度 -141 dBm配 SX1250 射频前端相对上一代 SX1301 功耗降低约一个数量级。关键认知这 8 路频率信道和 16 个解调器是共享而非一对一绑定的。也就是说同一个频率信道、不同的 SF可以被不同解调器同时解码不同的频率信道、不同的 SF更可以同时解码。但是 16 不是一个大数字。当第 17 个包到达时它直接被丢弃没有排队没有重传请求——SX1302 的并发能力就到这里为止。这正是 SX1303 与 SX1302 的另一道分水岭开启 SX1303 的Fine Timestamp功能后并发上限从 16 降到 8——文章可参考本系列第 8 篇《LoRa 定位技术原理》。1.2 解调器被打爆是什么样子实战中网关容量很少被解调器卡住。被卡住的永远是空中时间。为了让你直观感受这一点先把 13 字节 payload、BW125 kHz、CR4/5 条件下的实测空中时间摆出来。这是用 Semtech 官方 LoRa 计算引擎基于 Semtech 内部 RF 物理模型算出的真实数据SF空中时间相对 SF7SF746.3 ms1.0×SF9164.9 ms3.6×SF10288.8 ms6.2×SF11577.5 ms12.5×SF121155.1 ms25×一台 SF12 设备消耗的网络资源相当于 25 台 SF7 设备。发的报文完全相同唯一的差别是它离网关更远、链路更差。这就是为什么在 LoRaWAN 工程里SF 分布比设备总数更能反映真实负载也是为什么覆盖做得越好、网关容量就越大——不是因为硬件升级是因为 SF7/SF8 的占比上去了。二、ALOHA所有估算的起点2.1 LoRaWAN 上行是 ALOHA 信道LoRaWAN 设备有话就说没有调度、没有信道预约、大多数地区没有发前监听。这意味着上行信道本质上是一个 ALOHA 信道。ALOHA 信道有一个不太友好的特性吞吐量随着负载上升到一个点后开始下降——不是平稳是掉头向下。超过峰值后越多传输反而带来越少成功接收因为冲突把包毁掉设备重传重传又制造更多冲突。这个峰值出现在大约 18% 的信道利用率。一旦突破这个数字网络就从工作直接塌成看起来像设备故障。LoRaWAN 在容量边界处的行为是非线性的。它不是慢慢变差是工作——然后崩溃。这种崩溃模式在监控大屏上会表现为设备随机掉线而不是网关满了——这就是为什么很多现场工程师找不到瓶颈。2.2 捕获效应6 dB 救一个包ALOHA 并不是完全无望。LoRa 有一个Capture Effect当两个包在同一信道同一 SF 上冲突时强度高约 6 dB 的那个包仍然可以被解出来。这意味着一个规划良好的网络设备离网关距离不同、路径损耗有梯度能跑赢教科书模型。这也是为什么覆盖规划做好 网关容量免费提升——把设备均匀铺在一个梯度上捕获效应才能发挥。但捕获效应不改变曲线的形状只是把整个曲线往右推一点。2.3 SF 成本曲线这是把上面的数字换成每小时频道预算之后的样子EU8688 信道可用频道预算每小时 8 信道 × 3600 秒 28,800 信道·秒/小时 ALOHA 可用预算 28,800 × 18% ≈ 5,200 信道·秒/小时接下来除以每台设备每小时消耗的空中时间理论容量就出来了。ThinkLink 知识库基于 13 字节 payload、8 信道网关、每小时一次的发送频率给出的官方测算SF 档位13 字节空中时间8 信道理论容量SF746.3 ms约 78.7 万SF9164.9 ms约 25.3 万SF121155.1 ms约 2.9 万注意这是理论上限假设没有任何冲突、没有任何重传、没有任何下行。**真实部署容量通常只有理论值的 30–50%**——这就是为什么手册上写的每信道几万台几乎从未在真实场景兑现过。三、决定容量的真实变量3.1 上行 vs 下行的不对称LoRaWAN 网关最反直觉的设计是它的上下行不对称上行8 个频率信道 16 个解调器并行接收——天然的多车道高速公路下行典型只有 1 个发射信道——单车道乡道所以下行拥堵是 LoRaWAN 规模化的最大隐患而它几乎不会出现在小规模部署里。一旦你跑过 1000 台设备下行就开始成为瓶颈Join Accept、ACK、MAC 命令——所有下行消息都要挤这唯一的发射信道。3.2 SF 分布被忽视的核心指标很多项目用设备总数评估 LoRaWAN 负载这是错的。正确的指标是 SF 加权后的总空中时间。举例某现场有 1000 台设备但其中 200 台在 SF12 滞留它们的等效负载约为 200 × 25 5000 台 SF7 设备。这个现场在1000 台设备的账本上是绿色的但在网络层面已经是红色的。如果你想知道自己的网络离 ALOHA 阈值还有多远最直接的方法是去网络服务器后台看过去 24 小时的 SF 分布直方图。SF12 占比超过 10% 就要警惕超过 20% 就该做覆盖优化。3.3 包大小第二被忽视的变量13 字节和 50 字节的 payload 在 SF12 下空中时间分别是 1155 ms 和 2468 ms——50 字节比 13 字节多消耗一倍的空中时间。很多团队一上来就把所有字段时间戳、设备 ID、传感器读数、电池电压、信号强度、固件版本、CRC打包上送。精简 payload 是扩容最便宜的方法——把 50 字节砍到 13 字节相同 SF 下的空中时间减半等同于容量翻倍。四、6 个可调节的扩容旋钮下面这套旋钮按成本从低到高排列。永远先调前几个再花钱买新硬件。旋钮 1 启用 ADR自适应数据速率ADR 是 LoRaWAN 协议内置的速率调节机制。不启用 ADR 等于自废一半容量——所有设备都会默认按 SF12 上报空中时间是 SF7 的 25 倍。启用 ADR 后NS 会根据链路预算建议设备切换到合适的 SF长期看 SF7/SF8 的占比应显著上升。踩坑提示服务端 ADR 在高负载时可能因下行拥堵而下发不及时设备会一直留在 SF12。本地 ADR让设备按本地 RSSI/SNR 自主调速更可靠。ManThink 自研的 EdgeBusEB边缘引擎就内置了本地 ADR。旋钮 2 慎用确认包Confirmed每次 Confirmed 上行都需要 1 个下行 ACK。下行是单车道。把非关键数据温湿度、电池电压、定期心跳从 Confirmed 切到 Unconfirmed把可靠性上移到应用层重试、去重、聚合可以显著降低下行流量——这是直接缓解下行瓶颈最便宜的方法。旋钮 3 错开入网时机上电即入网是经典反模式。想象 5000 台设备断电恢复后同时上电——它们几乎会在同一秒发起 Join Request下行 Join Accept 直接堵死。正确的做法按需入网连续 N 次上行失败再触发入网基于 UTC 的随机延迟每台设备用pseudo_random_delay (DevAddr 0xFF) × 100 ms错开ManThink EdgeBus 的入网保护机制就是这个套路内置随机延迟和入网重试避免大规模断电后的入网雪崩。旋钮 4 合理规划覆盖与网关密度一个不直观但被无数次验证的经验值部署场景网关密度参考城市密集区1–2 个/km²郊区 / 农村1 个 / 5–10 km²楼宇室内穿透 5–10 层每栋楼 1–2 个工厂车间每 5000–10000 m² 1 个密度太高同一区域 3 个网关都收到同一包浪费硬件但能换更高接收成功率密度太低则设备被推上高 SF整个网络负载爆掉。旋钮 5 精简 payload 与压缩应用层只上送必要字段丢弃冗余 ID 与时间戳大块数据用差分压缩只传增量多个小读数合并为一个周期性 packet二进制优于 ASCII把23.5转成int16直接省 2 字节旋钮 6 用边缘计算代替全部上送把告警判断、阈值过滤、数据聚合在网关或终端本地完成只把异常和汇总数据上送——这是 LoRaWAN 规模化的真正杀手锏。ManThink 的 EdgeBusEB正是为此设计在低功耗 MCUCortex-M0 即可上跑事件驱动的边缘计算逻辑让绝大多数时间不发包成为常态。这相当于把网关容量从每秒多少包提升到每天多少异常事件——量级完全不同。五、给个可用的估算公式5.1 三步估算流程Step 1 计算单设备每小时空中时间T_airtime packet_time(SF, payload_size) // 用 Semtech LoRa 计算器实测 T_device_hourly (3600 / send_interval_sec) × T_airtimeStep 2 计算网关每小时频道预算B_gateway_hourly 8 × 3600 × 0.18 5,184 信道·秒/小时Step 3 算理论容量留 50% 冗余N_max B_gateway_hourly / T_device_hourly N_recommended N_max × 0.55.2 一个实例某智慧农业项目1000 块土壤湿度传感器每 10 分钟上报一次payload 8 字节湿度 温度启用 ADR 后预计 SF7 占比 60%、SF8 占比 25%、SF9 占比 15%实测空中时间8 字节BW125CR4/5Semtech 计算器SF7 ≈ 41 msSF8 ≈ 77 msSF9 ≈ 164 ms加权平均空中时间T_avg 0.6 × 41 0.25 × 77 0.15 × 164 ≈ 69 ms每小时每设备占用T_device (3600 / 600) × 0.069 0.414 信道·秒/小时单网关理论容量N_max 5,184 / 0.414 ≈ 12,500 台加 50% 冗余后推荐部署上限N_recommended ≈ 6,200 台1000 台在这个容量下安全。一个 8 信道 SX1302 网关足够覆盖。对比如果覆盖做得差所有设备都在 SF12T_device 6 × 1.155 ≈ 6.93 信道·秒/小时 N_max 5,184 / 6.93 ≈ 748 台 N_recommended ≈ 374 台同样是 1000 台覆盖差的项目单网关根本扛不住必须立刻上第二个网关或优化天线部署。六、ManThink GD6 / GDO51 的容量实践6.1 GD6 开源网关ManThink GD6ESP32-S3 SX1302是面向中小规模部署的开源网关。典型应用单网关覆盖楼宇 1 栋3–8 层 室外 1–2 km²推荐设备规模500–3,000 台/网关含 ADRpayload 控制在 8–20 字节启用本地 ADR Unconfirmed 入网保护6.2 GDO518 商用网关ManThink GDO518 商用室外网关SX130216 频点 32 包并行解调推荐设备规模5,000–20,000 台/网关适合大规模城市级部署智慧城市、智慧农业、资产追踪支持 Docker 容器可在边缘侧跑 EB 边缘计算逻辑外置 SIM 卡槽 Debug 串口维护无需拆机实测案例江苏某智慧农业项目单 GDO518 网关带 8,000 台土壤传感器15 分钟上报一次payload 6 字节ADR 启用网络稳定运行 12 个月。七、5 个常见误区误区 1SX1303 等于容量更高错。SX1303 与 SX1302 引脚兼容、解调器数量相同但开启 Fine Timestamp 后并发上限从 16 降到 8。SX1303 的真正价值在定位精度不在吞吐。误区 2把接入设备数写成承载设备数很多方案用该 NS 已接入 XX 万台设备宣传这只是注册量不代表同时在线容量。真实容量看 SF 加权后的并发负载。误区 3扩容只买新网关错。绝大多数 LoRaWAN 网络只要做 3 件事就能扩容 3–5 倍启用 ADR、精简 payload、错开入网。买网关是最后一步。误区 4设备越多越要选 Class C错。Class C 持续接收功耗是 Class A 睡眠状态的 1000 倍以上。Class A 才是大规模部署的主力——下行带宽天然窄Class A 的上行后才有 RX 窗口反而匹配这个约束。误区 5所有设备都走确认包错。温湿度、电量、定期心跳这类可重发数据用 Unconfirmed告警、控制指令才用 Confirmed。下行带宽是稀缺资源别浪费在不需要可靠性的数据上。八、一张清单带走下次评估 LoRaWAN 部署容量按这个清单走用 Semtech LoRa 计算器实测目标 SF 与 payload 大小下的空中时间估算 SF 加权后的平均空中时间不要直接用 SF7 或 SF12用 ALOHA 18% 阈值 50% 冗余得到推荐设备数启用 ADR 本地 ADREB 自带关键数据 Confirmed非关键 Unconfirmed入网用 UTC 随机延迟或按需触发payload 尽量小二进制优于 ASCII边缘侧做告警与聚合减少上送单网关容量预估不足时先优化覆盖再考虑加网关九、结语回到开篇那个 Excel 表格里的格子一个 SX1302 网关能带多少设备如果非要一个数字典型值是 1,000 到 10,000 台/网关。但这个数字本身没有意义——它依赖于 SF 分布、payload 大小、上报频率、上下行比、入网策略、覆盖质量。容量是一个设计出来的结果不是买回来的参数。你买的硬件只是容量曲线的起点SF 分布、payload 治理、覆盖规划——这些软件层面的决策决定了同一套硬件能撑 700 台还是 20,000 台。对于大规模 LoRaWAN 部署唯一可靠的扩容顺序是ADR → payload 精简 → 入网错峰 → 边缘计算 → 覆盖优化 → 加网关把这六步走完绝大多数项目不需要再买第二台网关。参考资料Semtech 官方 LoRa 调制解调器计算工具https://lora-developers.semtech.com/resources/tools/calculators/lorawan-airs-time-and-duty-cycle-calculator/LoRa Alliance, RP002-1.0.4 LoRaWAN Regional Parameters2020LoRa Alliance, LoRaWAN L2 1.0.4 Specification2020Semtech,SX1302 Datasheet—Corecell Gateway Baseband ProcessorThinkLink 官方知识库《解密 LoRaWAN 网关容量》《LoRaWAN 网关容量解析》《一个 LoRa 网关的容量多大》“How Many Devices Can One LoRaWAN Gateway Really Handle?” — lorawan-consulting.com2024Semtech,LoRa Corecell Reference Design— SX1302CFD490GW1 / SX1302CFD915W1-HManThink 官方文档GD61x 配置手册 / EdgeBus 边缘计算 SDK LoRaWAN 网络容量估算：一个 SX1302 网关到底能带多少设备
一个永远在变的数字“你们的网关能带多少设备”这是每一个 LoRaWAN 方案沟通会上被问到的第一个问题也是每一个采购经理在 Excel 表里最先填的格子。答案不在任何一份产品手册里因为同一个网关在真实部署中可能服务700 台设备也可能服务 20,000 台。硬件没变变的只有部署条件。这并不是销售在吹牛。一个 SX1302 网关在某些假设下确实能扛住数万台传感器——只是这些假设几乎从不被明确写出来。于是同一套硬件诚实地覆盖了两个数量级的部署量差距不来自硬件来自覆盖。本文把 LoRaWAN 网关容量这件事拆开来讲清楚硬件能给你什么、ALOHA 协议会拿走什么、工程上有哪些可调节的旋钮、最后给一个开箱可用的估算公式与三步决策流程。一、网关硬件给了我们什么1.1 SX1302 集中器8 信道 × 16 解调器现代 LoRaWAN 网关几乎都基于 Semtech SX1302 集中器。要谈容量先把这颗芯片的内部结构看清楚。Semtech 官方数据手册给出的 SX1302 内部构成8 个 125 kHz 频率信道8 路同时监听不同的中心频率16 个 LoRa 解调器分两组8 个支持 SF5–SF12远距离低速档8 个支持 SF5–SF10近距离高速档1 个125 / 250 / 500 kHz 高速 LoRa 解调器1 个 (G)FSK 解调器兼容旧协议最多65 个可配置逻辑信道灵敏度 -141 dBm配 SX1250 射频前端相对上一代 SX1301 功耗降低约一个数量级。关键认知这 8 路频率信道和 16 个解调器是共享而非一对一绑定的。也就是说同一个频率信道、不同的 SF可以被不同解调器同时解码不同的频率信道、不同的 SF更可以同时解码。但是 16 不是一个大数字。当第 17 个包到达时它直接被丢弃没有排队没有重传请求——SX1302 的并发能力就到这里为止。这正是 SX1303 与 SX1302 的另一道分水岭开启 SX1303 的Fine Timestamp功能后并发上限从 16 降到 8——文章可参考本系列第 8 篇《LoRa 定位技术原理》。1.2 解调器被打爆是什么样子实战中网关容量很少被解调器卡住。被卡住的永远是空中时间。为了让你直观感受这一点先把 13 字节 payload、BW125 kHz、CR4/5 条件下的实测空中时间摆出来。这是用 Semtech 官方 LoRa 计算引擎基于 Semtech 内部 RF 物理模型算出的真实数据SF空中时间相对 SF7SF746.3 ms1.0×SF9164.9 ms3.6×SF10288.8 ms6.2×SF11577.5 ms12.5×SF121155.1 ms25×一台 SF12 设备消耗的网络资源相当于 25 台 SF7 设备。发的报文完全相同唯一的差别是它离网关更远、链路更差。这就是为什么在 LoRaWAN 工程里SF 分布比设备总数更能反映真实负载也是为什么覆盖做得越好、网关容量就越大——不是因为硬件升级是因为 SF7/SF8 的占比上去了。二、ALOHA所有估算的起点2.1 LoRaWAN 上行是 ALOHA 信道LoRaWAN 设备有话就说没有调度、没有信道预约、大多数地区没有发前监听。这意味着上行信道本质上是一个 ALOHA 信道。ALOHA 信道有一个不太友好的特性吞吐量随着负载上升到一个点后开始下降——不是平稳是掉头向下。超过峰值后越多传输反而带来越少成功接收因为冲突把包毁掉设备重传重传又制造更多冲突。这个峰值出现在大约 18% 的信道利用率。一旦突破这个数字网络就从工作直接塌成看起来像设备故障。LoRaWAN 在容量边界处的行为是非线性的。它不是慢慢变差是工作——然后崩溃。这种崩溃模式在监控大屏上会表现为设备随机掉线而不是网关满了——这就是为什么很多现场工程师找不到瓶颈。2.2 捕获效应6 dB 救一个包ALOHA 并不是完全无望。LoRa 有一个Capture Effect当两个包在同一信道同一 SF 上冲突时强度高约 6 dB 的那个包仍然可以被解出来。这意味着一个规划良好的网络设备离网关距离不同、路径损耗有梯度能跑赢教科书模型。这也是为什么覆盖规划做好 网关容量免费提升——把设备均匀铺在一个梯度上捕获效应才能发挥。但捕获效应不改变曲线的形状只是把整个曲线往右推一点。2.3 SF 成本曲线这是把上面的数字换成每小时频道预算之后的样子EU8688 信道可用频道预算每小时 8 信道 × 3600 秒 28,800 信道·秒/小时 ALOHA 可用预算 28,800 × 18% ≈ 5,200 信道·秒/小时接下来除以每台设备每小时消耗的空中时间理论容量就出来了。ThinkLink 知识库基于 13 字节 payload、8 信道网关、每小时一次的发送频率给出的官方测算SF 档位13 字节空中时间8 信道理论容量SF746.3 ms约 78.7 万SF9164.9 ms约 25.3 万SF121155.1 ms约 2.9 万注意这是理论上限假设没有任何冲突、没有任何重传、没有任何下行。**真实部署容量通常只有理论值的 30–50%**——这就是为什么手册上写的每信道几万台几乎从未在真实场景兑现过。三、决定容量的真实变量3.1 上行 vs 下行的不对称LoRaWAN 网关最反直觉的设计是它的上下行不对称上行8 个频率信道 16 个解调器并行接收——天然的多车道高速公路下行典型只有 1 个发射信道——单车道乡道所以下行拥堵是 LoRaWAN 规模化的最大隐患而它几乎不会出现在小规模部署里。一旦你跑过 1000 台设备下行就开始成为瓶颈Join Accept、ACK、MAC 命令——所有下行消息都要挤这唯一的发射信道。3.2 SF 分布被忽视的核心指标很多项目用设备总数评估 LoRaWAN 负载这是错的。正确的指标是 SF 加权后的总空中时间。举例某现场有 1000 台设备但其中 200 台在 SF12 滞留它们的等效负载约为 200 × 25 5000 台 SF7 设备。这个现场在1000 台设备的账本上是绿色的但在网络层面已经是红色的。如果你想知道自己的网络离 ALOHA 阈值还有多远最直接的方法是去网络服务器后台看过去 24 小时的 SF 分布直方图。SF12 占比超过 10% 就要警惕超过 20% 就该做覆盖优化。3.3 包大小第二被忽视的变量13 字节和 50 字节的 payload 在 SF12 下空中时间分别是 1155 ms 和 2468 ms——50 字节比 13 字节多消耗一倍的空中时间。很多团队一上来就把所有字段时间戳、设备 ID、传感器读数、电池电压、信号强度、固件版本、CRC打包上送。精简 payload 是扩容最便宜的方法——把 50 字节砍到 13 字节相同 SF 下的空中时间减半等同于容量翻倍。四、6 个可调节的扩容旋钮下面这套旋钮按成本从低到高排列。永远先调前几个再花钱买新硬件。旋钮 1 启用 ADR自适应数据速率ADR 是 LoRaWAN 协议内置的速率调节机制。不启用 ADR 等于自废一半容量——所有设备都会默认按 SF12 上报空中时间是 SF7 的 25 倍。启用 ADR 后NS 会根据链路预算建议设备切换到合适的 SF长期看 SF7/SF8 的占比应显著上升。踩坑提示服务端 ADR 在高负载时可能因下行拥堵而下发不及时设备会一直留在 SF12。本地 ADR让设备按本地 RSSI/SNR 自主调速更可靠。ManThink 自研的 EdgeBusEB边缘引擎就内置了本地 ADR。旋钮 2 慎用确认包Confirmed每次 Confirmed 上行都需要 1 个下行 ACK。下行是单车道。把非关键数据温湿度、电池电压、定期心跳从 Confirmed 切到 Unconfirmed把可靠性上移到应用层重试、去重、聚合可以显著降低下行流量——这是直接缓解下行瓶颈最便宜的方法。旋钮 3 错开入网时机上电即入网是经典反模式。想象 5000 台设备断电恢复后同时上电——它们几乎会在同一秒发起 Join Request下行 Join Accept 直接堵死。正确的做法按需入网连续 N 次上行失败再触发入网基于 UTC 的随机延迟每台设备用pseudo_random_delay (DevAddr 0xFF) × 100 ms错开ManThink EdgeBus 的入网保护机制就是这个套路内置随机延迟和入网重试避免大规模断电后的入网雪崩。旋钮 4 合理规划覆盖与网关密度一个不直观但被无数次验证的经验值部署场景网关密度参考城市密集区1–2 个/km²郊区 / 农村1 个 / 5–10 km²楼宇室内穿透 5–10 层每栋楼 1–2 个工厂车间每 5000–10000 m² 1 个密度太高同一区域 3 个网关都收到同一包浪费硬件但能换更高接收成功率密度太低则设备被推上高 SF整个网络负载爆掉。旋钮 5 精简 payload 与压缩应用层只上送必要字段丢弃冗余 ID 与时间戳大块数据用差分压缩只传增量多个小读数合并为一个周期性 packet二进制优于 ASCII把23.5转成int16直接省 2 字节旋钮 6 用边缘计算代替全部上送把告警判断、阈值过滤、数据聚合在网关或终端本地完成只把异常和汇总数据上送——这是 LoRaWAN 规模化的真正杀手锏。ManThink 的 EdgeBusEB正是为此设计在低功耗 MCUCortex-M0 即可上跑事件驱动的边缘计算逻辑让绝大多数时间不发包成为常态。这相当于把网关容量从每秒多少包提升到每天多少异常事件——量级完全不同。五、给个可用的估算公式5.1 三步估算流程Step 1 计算单设备每小时空中时间T_airtime packet_time(SF, payload_size) // 用 Semtech LoRa 计算器实测 T_device_hourly (3600 / send_interval_sec) × T_airtimeStep 2 计算网关每小时频道预算B_gateway_hourly 8 × 3600 × 0.18 5,184 信道·秒/小时Step 3 算理论容量留 50% 冗余N_max B_gateway_hourly / T_device_hourly N_recommended N_max × 0.55.2 一个实例某智慧农业项目1000 块土壤湿度传感器每 10 分钟上报一次payload 8 字节湿度 温度启用 ADR 后预计 SF7 占比 60%、SF8 占比 25%、SF9 占比 15%实测空中时间8 字节BW125CR4/5Semtech 计算器SF7 ≈ 41 msSF8 ≈ 77 msSF9 ≈ 164 ms加权平均空中时间T_avg 0.6 × 41 0.25 × 77 0.15 × 164 ≈ 69 ms每小时每设备占用T_device (3600 / 600) × 0.069 0.414 信道·秒/小时单网关理论容量N_max 5,184 / 0.414 ≈ 12,500 台加 50% 冗余后推荐部署上限N_recommended ≈ 6,200 台1000 台在这个容量下安全。一个 8 信道 SX1302 网关足够覆盖。对比如果覆盖做得差所有设备都在 SF12T_device 6 × 1.155 ≈ 6.93 信道·秒/小时 N_max 5,184 / 6.93 ≈ 748 台 N_recommended ≈ 374 台同样是 1000 台覆盖差的项目单网关根本扛不住必须立刻上第二个网关或优化天线部署。六、ManThink GD6 / GDO51 的容量实践6.1 GD6 开源网关ManThink GD6ESP32-S3 SX1302是面向中小规模部署的开源网关。典型应用单网关覆盖楼宇 1 栋3–8 层 室外 1–2 km²推荐设备规模500–3,000 台/网关含 ADRpayload 控制在 8–20 字节启用本地 ADR Unconfirmed 入网保护6.2 GDO518 商用网关ManThink GDO518 商用室外网关SX130216 频点 32 包并行解调推荐设备规模5,000–20,000 台/网关适合大规模城市级部署智慧城市、智慧农业、资产追踪支持 Docker 容器可在边缘侧跑 EB 边缘计算逻辑外置 SIM 卡槽 Debug 串口维护无需拆机实测案例江苏某智慧农业项目单 GDO518 网关带 8,000 台土壤传感器15 分钟上报一次payload 6 字节ADR 启用网络稳定运行 12 个月。七、5 个常见误区误区 1SX1303 等于容量更高错。SX1303 与 SX1302 引脚兼容、解调器数量相同但开启 Fine Timestamp 后并发上限从 16 降到 8。SX1303 的真正价值在定位精度不在吞吐。误区 2把接入设备数写成承载设备数很多方案用该 NS 已接入 XX 万台设备宣传这只是注册量不代表同时在线容量。真实容量看 SF 加权后的并发负载。误区 3扩容只买新网关错。绝大多数 LoRaWAN 网络只要做 3 件事就能扩容 3–5 倍启用 ADR、精简 payload、错开入网。买网关是最后一步。误区 4设备越多越要选 Class C错。Class C 持续接收功耗是 Class A 睡眠状态的 1000 倍以上。Class A 才是大规模部署的主力——下行带宽天然窄Class A 的上行后才有 RX 窗口反而匹配这个约束。误区 5所有设备都走确认包错。温湿度、电量、定期心跳这类可重发数据用 Unconfirmed告警、控制指令才用 Confirmed。下行带宽是稀缺资源别浪费在不需要可靠性的数据上。八、一张清单带走下次评估 LoRaWAN 部署容量按这个清单走用 Semtech LoRa 计算器实测目标 SF 与 payload 大小下的空中时间估算 SF 加权后的平均空中时间不要直接用 SF7 或 SF12用 ALOHA 18% 阈值 50% 冗余得到推荐设备数启用 ADR 本地 ADREB 自带关键数据 Confirmed非关键 Unconfirmed入网用 UTC 随机延迟或按需触发payload 尽量小二进制优于 ASCII边缘侧做告警与聚合减少上送单网关容量预估不足时先优化覆盖再考虑加网关九、结语回到开篇那个 Excel 表格里的格子一个 SX1302 网关能带多少设备如果非要一个数字典型值是 1,000 到 10,000 台/网关。但这个数字本身没有意义——它依赖于 SF 分布、payload 大小、上报频率、上下行比、入网策略、覆盖质量。容量是一个设计出来的结果不是买回来的参数。你买的硬件只是容量曲线的起点SF 分布、payload 治理、覆盖规划——这些软件层面的决策决定了同一套硬件能撑 700 台还是 20,000 台。对于大规模 LoRaWAN 部署唯一可靠的扩容顺序是ADR → payload 精简 → 入网错峰 → 边缘计算 → 覆盖优化 → 加网关把这六步走完绝大多数项目不需要再买第二台网关。参考资料Semtech 官方 LoRa 调制解调器计算工具https://lora-developers.semtech.com/resources/tools/calculators/lorawan-airs-time-and-duty-cycle-calculator/LoRa Alliance, RP002-1.0.4 LoRaWAN Regional Parameters2020LoRa Alliance, LoRaWAN L2 1.0.4 Specification2020Semtech,SX1302 Datasheet—Corecell Gateway Baseband ProcessorThinkLink 官方知识库《解密 LoRaWAN 网关容量》《LoRaWAN 网关容量解析》《一个 LoRa 网关的容量多大》“How Many Devices Can One LoRaWAN Gateway Really Handle?” — lorawan-consulting.com2024Semtech,LoRa Corecell Reference Design— SX1302CFD490GW1 / SX1302CFD915W1-HManThink 官方文档GD61x 配置手册 / EdgeBus 边缘计算 SDK