作者：ManThink 技术团队 发布日期：2026-09-18 系列：LoRaWAN 技术阅读 · 第 14 期 · 行业趋势
2026 年，LoRaWAN 在楼宇领域已经是事实上的第一无线技术。LoRa 联盟 2025 年度报告（2026 年 2 月发布）确认，LoRaWAN 已跃居智慧建筑与设施管理领域的第一大无线技术，全球部署终端达 1.25 亿台，年复合增长率 25%。
同期的一个实测结论却和这种热度形成了刺眼的反差。
在一栋台湾现代化办公楼的测试中，工程师把一台 LoRaWAN 网关装在 1 层，然后把传感器分别放在：
同一台网关，同样的 65 米水平距离，垂直方向上只差两层楼，结论就从"稳定"变成"不可用"。
这个测试没有发现什么新原理，它只是把一句行业里说了很多年、但在项目排期表上总被压缩掉的话，重新摆到了台面上：在楼宇里，LoRaWAN 的有效覆盖单位不是平方米，是"分区"。一楼一网关，不是保守设计，是工程下限。
这篇文章想回答三个问题：LoRaWAN 在楼宇里到底走到了哪一步？真正卡住工程交付的是什么？以及，在一栋真实的楼里该怎么设计。
先看几组能说明问题的数据。
| 指标 | 数值 | 来源与口径 |
|---|---|---|
| LoRaWAN 全球部署终端 | 1.25 亿台，25% CAGR | LoRa Alliance 2025 年度报告（2026-02） |
| 联盟成员 / 认证设备 | 360 家成员（2025 年新增 57 家）/ 625+ 认证设备 | 同上 |
| 楼宇垂直市场地位 | 已跃居智慧建筑与设施管理第一大无线技术 | 同上 |
| 楼宇市场增速 | 2025-09 被联盟定义为 LoRaWAN 增长最快的垂直市场 | LoRa Alliance 2025-09-16 新闻稿 |
| LPWAN 整体连接数 | 4.39 亿（2024）→ 约 18 亿（2034） | Transforma Insights |
| 全球智能建筑自动化市场 | 2026 年突破 820 亿美元，同比 +12.7%，亚太贡献 >38% 增量 | 行业市场调查（2026） |
| 商业楼宇智能系统采用率 | 91% 受访业主/运营方已使用智能系统，单组织年均支出 >55 万美元 | ASHB 调研（2025-12） |
| 无线协议在新建商业建筑渗透率 | 已突破 60%（Zigbee 3.0 / Thread / Matter） | 同上 |
注：不同机构对"智慧楼宇 IoT"的口径差异很大——广义口径（含硬件、软件、服务全栈）有机构给出 2025 年 1158 亿美元、2032 年 2721 亿美元的预测；窄口径（智能建筑专业 IoT 平台）则为 14.1 亿美元（2025）→ 57.2 亿美元（2035）。引用时务必标明口径，否则会出现同一个市场差 800 倍的荒谬对照。
数据好看，但真正让楼宇业主把 LoRaWAN 写进预算表的，是另外三件事。
这是 2025-2026 年最大的变量。以前楼宇能效改造是"省钱项目"，业主可以拖；现在它变成了"合规项目"，有硬截止日期。
欧洲：
中国：
注意 GB 55015-2021 那条"断点续传"要求的杀伤力。它排除了大量低端传感器——设备必须在网络中断期间把数据存在本地，恢复后补传。这意味着传感器要有本地存储、要有时间戳、固件要有重传逻辑。这不是通信问题，是设备选型门槛。
有线方案的隐性成本一向被低估。行业数据给出的参考值：每路有线传感器的布线成本约 300 欧元（含线缆、桥架、管路、人工、开孔修复）。一栋 3 层办公楼布 200 个点位，光布线就是 6 万欧元，还不含停工损失和装修修复。
而 LoRaWAN 传感器装一个点位通常以分钟计，无需走线、无需桥管，整体安装成本可降低最多 60%。对于存量建筑、租赁物业、历史保护建筑（不允许开槽）而言，这几乎是唯一的可行路径。
LoRa 联盟认证设备已超过 625 款。更重要的是，主流厂商开始把"楼宇"当成一个独立产品线来做，而不是拿通用网关凑数。典型信号是楼宇协议的原生集成：新一代楼宇 IoT 网关已经把 BACnet/IP、BACnet MS/TP、Modbus TCP/RTU、KNX TP1、M-Bus 与 LoRaWAN 收进同一台设备，LoRaWAN 传感器数据可以直接作为 BACnet 对象出现在既有 BMS 里，不需要中间件。
这一条的意义被严重低估。楼宇自控行业在 BACnet 上积累了几十年，设施管理团队的整套工作流、图形化界面、报警逻辑都长在 BMS 上。LoRaWAN 能不能"说 BACnet"，决定了它是被请进弱电间，还是被挡在门外。
在讨论 LoRaWAN 的瓶颈之前，得先说清楚它凭什么进场。
| 场景特征 | 有线方案的问题 | LoRaWAN 的对应优势 |
|---|---|---|
| 存量建筑改造 | 开槽、穿管、破坏装修、需停业施工 | 免布线，非专业人员可安装 |
| 租赁物业 | 产权与租期限制，不便做固定改造 | 可拆卸、可迁移，随租约调整 |
| 表计集中在管井/地下室 | 强电井环境差，布线验收难 | 电池供电，直接贴在表箱旁 |
| 点位分散且后期会变 | 每加一个点位就要重新布线 | 加装传感器即接入，零施工 |
| 历史保护建筑 | 不允许破坏建筑结构 | 是唯一可行方案 |
注意最后两行。楼宇 IoT 最有价值的特性不是"无线"，而是**"可增量演进"**。
一个真实项目的典型路径是：先上漏水检测和机房环境监测（风险驱动），跑通后再加分项计量（能效驱动），再上空间利用和 IAQ（体验驱动）。楼宇里没有一个项目是一次性把 2000 个点位想清楚的。只有无线方案能承载这种"边跑边加"的节奏，而有线方案每加一次都是一次小型工程。
不是所有场景都适合 LoRaWAN。下面五个是 2026 年被反复验证、且经济性清晰的。
| 场景 | 典型上报频率 | 时延要求 | 是否需要下行 | 覆盖难度 | 电池预期 |
|---|---|---|---|---|---|
| 分项计量与能耗 | 5-15 分钟 | 中（可容忍分钟级延迟） | 低 | 高（管井/地下室） | 外部供电为主 |
| 当前环境质量 IAQ | 5-15 分钟 | 中 | 低 | 低（房间内） | 约 5 年 @4000 mAh |
| 水浸/漏水检测 | 事件触发 + 15 分钟心跳 | 高（分钟级告警） | 低 | 高（机房/管井） | 3-5 年 |
| 空间利用与在场 | 5-15 分钟 | 中 | 低 | 低 | 3-5 年 |
| 设备状态与预防性维护 | 15-60 分钟 | 低 | 中（阈值配置） | 中（设备层/屋顶） | 外部供电为主 |
几点需要说明：
上报频率的行业共识是 15 分钟起步，能用 1 小时就别用 15 分钟。 这不是保守，是容量算术的直接结果（见第五节）。北京地方标准要求"不低于 5 分钟/次"，指的是采集频率，不必然是上报频率——设备可以 5 分钟采一次、本地聚合后 15 分钟上报一次。这个区别在合规沟通时非常关键。
"是否需要下行"这一列几乎全是"低"，而这是 LoRaWAN 最大的结构性优势，也是它最大的结构性风险。 优势是因为楼宇监测以遥测为主；风险是因为一旦项目后期加了"控制"需求（开阀、开关灯、调设定值），下行压力会突然出现，而网络设计当初根本没为下行留预算。
一个实际案例可以说明经济性：迪拜某商业建筑部署 LoRaWAN 智能照明控制，一个月内照明能耗下降 25%，每月节省约 11,000 小时的点灯时间。这类数据一旦能拿到，投资回收期就以月为单位计算。
这是所有楼宇无线项目的第一个坑，也是最贵的一个坑。
LoRa 在 Sub-GHz 频段，比 2.4 GHz 的 Wi-Fi/Zigbee 穿透好得多。但"好得多"不等于"都能穿"。实测数据：
| 材料 | 厚度 | 单层衰减 |
|---|---|---|
| 普通砖墙 | 89 mm | 约 3.5 dB |
| 普通砖墙 | 178 mm | 约 5 dB |
| 普通砖墙 | 267 mm | 约 7 dB |
| 混凝土 | 102 mm | 约 12 dB |
| 混凝土 | 203 mm | 约 23 dB |
| 混凝土 | 305 mm | 约 35 dB |
| 钢筋混凝土 | 89 mm | 约 27 dB |
| 混凝土（衰减系数） | — | 8-12 dB/m |
| 金属管道 + 积水环境 | — | 每 10 米下降 25-30 dB |
把这组数字和链路预算放在一起看，结论就很清楚了：
以 22 dBm 发射功率、-148 dBm 灵敏度（理论极限）计算，LoRa 理论上可以穿透 3-5 堵普通砖墙，或者 1-2 堵混凝土墙。但"理论极限灵敏度"意味着 SNR 接近于零，误包率极高。工程上要留余量，实际可用穿透能力还要再打对折。
而楼宇里的真实情况是：你很少只穿一堵墙。
从 3 楼某个办公室的传感器，到 1 楼弱电间的网关，中间可能经过：办公室隔墙 → 走廊 → 楼板（混凝土）→ 另一层走廊 → 机房屏蔽门。四到五道衰减叠加，很容易超过 60 dB，直接击穿链路预算。
除了墙和楼板，楼宇里还有三类结构对 Sub-GHz 特别不友好：
金属风管（HVAC Ducting）。 金属是射频的天然屏蔽层。吊顶里成排的金属风管会形成不规则的反射面，制造出难以预测的死区。设备装在吊顶上方且紧邻风管时，衰减可能是自由空间的数倍。
电梯井。 钢筋混凝土围合 + 金属轿厢 + 竖向贯通结构，既屏蔽又反射。电梯井周边的房间是典型的覆盖黑洞。
Low-E 玻璃幕墙。 节能建筑普遍采用低辐射镀膜玻璃，其金属镀层对射频的衰减远高于普通玻璃。这带来一个反直觉结果：能效等级越高的现代建筑，室内无线覆盖反而越难做。 一个追求节能的建筑，顺手把无线信号也一起节了能。
另外还要注意配电房、变电间这类强电环境——不是射频衰减问题，是电磁本底噪声问题，会抬高接收机的噪声底。
回到引子那组实测数据，把它和行业其他测试放在一起：
| 测试 | 布置 | 结果 |
|---|---|---|
| 台湾办公楼实测 | 网关 1F，传感器同层 65 m | 稳定，可靠遥测 |
| 台湾办公楼实测 | 网关 1F，传感器 2F（上 1 层） | 可用，但信号余量下降，对遮挡敏感 |
| 台湾办公楼实测 | 网关 1F，传感器 3F（上 2 层） | 大幅衰减，丢包明显，不适合生产 |
| Robustel / Voytech 建筑项目 | 3 层办公室，200+ 传感器 | 部署成功 |
| Robustel / Voytech 概念验证 | 跨 14 层通信 | 可达（PoC 条件，非生产承诺） |
| 室内单层参考设计 | 网关吊顶居中，高 2.5-3 m | 覆盖半径 30-50 m，适合 <100 节点 |
| 多层建筑参考设计 | 每层 1 台，装在楼道/公共区吊顶 | 避免跨层穿墙，各层独立管理 |
初看 14 层通信和"上 2 层就不可用"是矛盾的。其实不矛盾——PoC 环境和生产环境的差别，在于余量。
PoC 时，网关和传感器可以刻意选位置、避开遮挡、取最佳路径；生产环境里，传感器位置由业务需求决定（漏水传感器必须在管井里，IAQ 传感器必须在人呼吸的高度），你没有选择权。PoC 证明的是"物理上可能"，生产需要的是"最差位置也能通"。
所以行业形成的经验法则是：
多层建筑，一层一台网关。这不是过度设计，是把"最差点位也能通"这件事写进架构。
对于超高层或楼板特别厚（钢筋混凝土承重楼板）的建筑，甚至要按"每两三层一台"来加密。
一句在行业里流传很广的话值得记住：
"一台装在楼顶的 500 美元网关，会打败一台藏在机房里的 2000 美元网关。"
安装位置的具体建议：
一个常见的反模式是：因为弱电间有现成电源和网口，就把网关一股脑全塞进去。方便施工和覆盖效果，在楼宇项目里经常是矛盾的。 正确的做法是先定覆盖分区，再去找这个分区里同时满足供电、回传和安装权限的位置。
这是楼宇项目从"能跑"到"跑不稳"最隐蔽的原因。多数容量讨论只算上行，而真正先撞墙的是下行。
LoRaWAN 网关在发射时是"聋"的——发送下行的那一刻，它收不到任何上行。
这意味着每一个下行帧的代价是双份的：
而在 8 路上行 / 1 路下行的典型网关架构下，下行资源本来就比上行稀缺一个数量级。
第一，确认上行（Confirmed Uplink）。 每一条确认上行都要一次下行 ACK。一个默认开启确认上行的设备团队，实际上让网关"每收一条就发一条"——这是行业里最常见的自伤型容量问题。
对于周期性传感器遥测，确认上行几乎永远没有意义：丢了一个温度读数，15 分钟后下一个就来了。把它关掉，下行负载能下降一个数量级。
第二，入网风暴（Join Storm）。 每次 Join Accept 都是一次下行。现场断电恢复后，所有设备同时尝试重新入网，每次入网都需要下行，网关一次只能发一条且要遵守占空比限制——一次 5 分钟的断电，可能演变成一小时的恢复期。
解法在固件层：设备的重入网退避时间必须随机化。这一条应该写进采购规格书，而不是等出了事再发现。
第三，MAC 命令、ADR 调整、配置下发、固件升级。 这些都走下行。FUOTA 尤其极端：一个 50-100 KB 的固件镜像，通过 LoRaWAN 多播下发通常需要数小时到数天。必须规划在低流量窗口执行。
LoRaWAN 的容量账本核心是一条规律：每降低一个扩频因子档位，设备的空口开销大约翻一倍。
| 数据速率 | 灵敏度（参考值） | 速率（参考值） | 相对空口开销 |
|---|---|---|---|
| SF7 | -124 dBm | 约 5.4 kbps | 1×（基准） |
| SF12 | -137 dBm | 约 0.25 kbps | 8-32× |
一个 20 字节载荷、每 15 分钟上报一次的容量对照（单网关理论上限）：
| 数据速率 | 上报间隔 | 单网关可承载设备数（理论上限） |
|---|---|---|
| SF7 | 15 分钟 | 约 18,000 |
| SF9 | 15 分钟 | 约 5,400 |
| SF10 | 15 分钟 | 约 2,900 |
| SF12 | 15 分钟 | 约 700 |
| SF9 | 60 分钟 | 约 21,000 |
| SF12 | 60 分钟 | 约 2,900 |
这张表解释了楼宇项目的核心矛盾：楼宇里信号最差的那些点位（管井、地下室、机房），恰恰会被 ADR 推到 SF10-SF12。而一个 SF12 设备消耗的空口资源，顶得上 8-32 个 SF7 设备。
于是出现一个反直觉结论：楼宇网络的容量瓶颈，往往不是"设备太多"，而是"信号太差的设备占比太高"。
换句话说——覆盖问题和容量问题是同一个问题。 网关布点合理、让设备降档到 SF7-SF9，本身就是最有效的扩容手段，比换更高通道数的网关有效得多。
| 噪声底抬升 | 影响 |
|---|---|
| +1 dB | 可感知 |
| +3 dB | 有效距离减半 |
| >6 dB | 严重影响性能 |
楼宇里噪声底的主要来源是 Wi-Fi、BLE、其他 Sub-GHz 设备（门禁、无线抄表、对讲）以及强电设备的宽带噪声。同一栋楼里如果已经有一套某厂商的私有 LoRa 抄表网络在跑，你的网关就一直在跟它抢空口。
这一条在项目评估阶段就应该实测。 一个 15 分钟的本底噪声扫描，可以避免后面几个月的诡异丢包排查。
根特大学的研究给出了一组很诚实的数字：当 1000 个节点同时以 1% 占空比上限发射时，单网关的丢包率最高可达 32%。
这不是 LoRaWAN 的缺陷，这是非授权频段的物理现实。它的含义是：单网关的容量天花板，比你按公式算出来的要低得多。 留冗余、做多网关覆盖，不是可选项。
楼宇项目最常见的误判之一：射频勘测显示 RSSI 全部达标，于是认为网络没问题；上线半年后开始出现随机丢包。
原因是三个被忽略的变量。
行业给出的"单网关支持 500-2000 节点"结论，隐含了非常具体的前提：混合 SF 分布、低频上报、极少下行。
把这些前提抽掉，数字立刻变化。一个更诚实的对照：
| 设备画像（20 字节载荷） | 单网关可承载数 |
|---|---|
| SF7，15 分钟一次 | 约 18,000 |
| SF9，15 分钟一次 | 约 5,400 |
| SF12，15 分钟一次 | 约 700 |
| SF9，1 小时一次 | 约 21,000 |
| SF12，1 小时一次 | 约 2,900 |
同一台硬件，上限从 700 到 21,000 都有。"一台网关能带多少设备"这个问题，在没有给定上报频率和 SF 分布之前，是没有答案的。
这个误解很普遍，且代价很高。
LoRaWAN 是"所有收到包的网关都上报、由网络服务器去重"的架构。所以两个网关覆盖同一片区域时：
容量随地理分隔增长，不随网关数量增长。 两台网关覆盖两个区域，大致是两倍容量；两台网关覆盖一个区域，买到的主要是保险。
唯一例外是通道数。在 64 通道计划（US915/AU915）下，网关可以跑在不同子频段，16 通道网关的双集中器确实带来双份并行路径。但 CN470/EU868 这类窄频段不适用这个逻辑。
而且还有一条：你从不独占信道。 同一栋楼里的其他 LoRaWAN 网络、其他运营商的设备、所有非授权频段用户，都在消耗同一份空口资源。这部分永远不会出现在你自己的容量计算里，但在繁忙城区可能占据相当比例。
这是楼宇区别于其他 IoT 场景的最大特点。
一个项目上线时可能只有 40 个漏水传感器（15 分钟心跳）。两年后，运维团队陆续加了：60 个分项计量、80 个 IAQ、30 个门磁、20 个空间利用。密度翻了五倍，而当初的网络设计是按 40 个点位做的。
如果原始设计没有为增长留出余量，网络会在某一天突然变得"难以管理"，然后被归因于"LoRaWAN 不稳定"。
正确的做法是在设计阶段明确三件事：
前面三个瓶颈都是技术性的，可以用工程解。第四个是组织性的，也更致命。
行业数据：约 70% 的企业 IoT 项目永远卡在 PoC 阶段，无法规模化。 原因几乎从来不是技术。
这个过程长这样：
PoC 成功了。一栋楼、10 个传感器、数据在仪表盘上跳动、领导点头、全量预算批准：12 个站点、500 个设备。
六个月后，项目停滞。那台带 10 个传感器很顺畅的网关扛不住流量；试点硬件的供应商不给批量价；IT 部门不批准你在树莓派上原型的网络架构；4 号站点的物业拒绝给你开屋顶权限。
这就是 "PoC 炼狱"。而它几乎总是由四个可预测的失败构成。
多数 PoC 的目标是"证明技术可行"，所以刻意选了最有利的条件：单站点、配合度高的物业、传感器摆在视距范围内、IT 安全作为"临时测试"放行、数据手工导出到 Excel。
这些条件在真实部署中一条都不成立。
建设性的做法是：故意让 PoC 暴露生产问题。
如果 PoC 没有暴露出问题，那它什么也没测出来。
三种最常见的技术债：
| PoC 做法 | 生产要求 | 迁移成本 |
|---|---|---|
| 树莓派跑 LNS | 需要冗余、备份、监控。ChirpStack 跑在标准服务器（2-4 核 / 8 GB RAM / SSD）可稳带数千设备 | 迁移不难，但必须一开始就规划 |
| 单网关 | 需要 N+1 冗余。网关凌晨 2 点掉线（断电/网口故障/硬件问题）时，背后所有传感器全部失联 | 需重新做布点规划 |
| 无 FUOTA 路径 | 固件需要升级：修 bug、打安全补丁、协议变更 | 没有 FUOTA = 500 个设备的问题要现场跑 500 次 |
最后一条尤其要命。选型时必须确认设备支持 FUOTA，并在 PoC 阶段就完整测通升级流程。
| 维度 | PoC 阶段 | 生产阶段 |
|---|---|---|
| 价格 | 经销商现货，刷卡即买 | 触发企业采购，批量价不会自动生效 |
| 交期 | 几天到货 | 8-16 周（元器件紧张期更久） |
| 认证 | 没人问 | IT 与合规会问：CE 标志？网络安全要求？供应链可靠性？ |
价格差异的量级值得算清楚：一个 80 欧元的传感器，在 500 台时可能降到 55 欧元——但也可能降不下来。500 台 × 25 欧元差价 = 12,500 欧元。这个数字必须在选定硬件平台之前谈定，而不是之后。
行业推荐的楼宇项目三阶段模型：
| 阶段 | 范围 | 设备数 | 周期 | 目的 |
|---|---|---|---|---|
| 阶段 1 · 概念验证 | 1 个楼层或 1 个分区 | 10-20 台 | 4 周 | 验证射频覆盖、网关位置、BMS 集成 |
| 阶段 2 · 试点 | 3-5 层或 1 整栋 | 50-100 台 | 8 周 | 验证扩展性、电池实际寿命、仪表盘可用性、运维工作流 |
| 阶段 3 · 全量部署 | 整栋或整个园区 | 200-2000+ 台 | 12-24 周 | 生产铺开，按楼层分阶段实施 |
注意阶段 2 的验证项里，"电池寿命"和"运维工作流"这两项只有试点能测，PoC 测不出来。这才是阶段 2 存在的理由——它不是"更大的 PoC"，它是不同性质的测试。
| 指标 | 目标值 |
|---|---|
| 上行成功率 | >98% |
| 链路边缘判定 | RSSI < -130 dBm 视为临界，需加网关或调整位置 |
日常要盯的：设备上行健康度（超过 2 倍预期间隔无上报即告警）、网关在线状态、电池电压趋势。月度看网络 KPI 和数据完整率（应收数据点 vs 实收）。
把前面所有分析收拢成 8 条可以直接写进设计文档的规则。
规则 1：先定业务结果，再定传感器清单。
不要从"买哪款传感器"开始。先回答：这栋楼的设施团队需要看到什么、自动化什么、阻止什么。
这两个目标对应的上报频率、时延要求、室内布点位置完全不同。同样面积的楼，一个要小时级环境数据、一个要准实时告警，网络设计可以差出一倍。
规则 2：网关布点按"分区"规划，不按"楼层"规划。
一栋楼的 RF 分区由以下因素决定，而不是照抄楼层图：混凝土核心筒、楼板厚度、金属风管走向、电梯井位置、Low-E 玻璃幕墙、技术间和配电房边界。
一个 800 平米的平层如果被两道混凝土墙切成三块，可能需要两台网关；而一个 3000 平米的开放办公区可能一台就够。
规则 3：一层一台网关是起点，不是终点。
把它当基线配置。然后对以下位置单独评估是否加密：
规则 4：上报间隔 15 分钟起步，能用 60 分钟就别用 15 分钟。
从 15 分钟改到 60 分钟，容量直接翻四倍，而绝大多数楼宇监测场景在运维上没有任何差别。
对合规有 5 分钟采集要求的项目，采用"本地 5 分钟采集 + 聚合后 15 分钟上报"的方式满足。
规则 5：关掉确认上行。
周期性遥测场景下，确认上行带来的下行放大效应远大于它提供的可靠性收益。只有真正"丢一条就出事"的事件型报文才值得用确认上行。
规则 6：上行时间随机抖动。
让设备不要整点齐发。这一条的成本是零，效果超出多数人预期。
规则 7：关键区域做 20-30% 覆盖重叠。
不是所有区域都要重叠，但"丢了这一条就出事故"的区域（漏水、冷库、机房）应该有第二个接收点。注意这是冗余，不是扩容——别把它算进容量预算里。
规则 8：预算 N+1 网关，而不是最小覆盖。
按覆盖所需台数 +1 报预算。多出来的那一台既是热备，也是后续加密的起点。
ManThink 的室内网关不是一款产品打天下，而是按"楼宇里的安装条件"分了四条线。
| 产品 | 定位 | 关键差异 | 供电与安装 | 适合的楼宇场景 |
|---|---|---|---|---|
| GD61x（GD614 / GD618） | ESP32-S3 室内开源网关 | 可选 SX1301 或 SX1302 集中器；Ethernet / Wi-Fi / 可选 4G；G 配置含 4G 模组与 PoE 模组 |
Type-C 5 V / DC 5-24 V / PoE（G）；单根外置 LoRa 天线 |
办公室、楼宇、园区、机房、小型工业现场；开发者与集成商自建 |
| GDI51 / GDI52 | 内置 ThinkLink 的室内网关 | GDI52 为工业型：铝合金外壳、新增 RS-485、DC 5-24 V 宽压 | GDI51：PoE / Type-C；GDI52：DIN 导轨安装 | 园区、大厦、楼宇等室内环境；GDI52 适合弱电间导轨柜 |
| GD73 | 高性能室内多通道网关 | SX1302、≥8 个上行信道、8 频点、16 解调器；灵敏度 -141 dBm（SF12/BW125）；发射功率 27 dBm（-1）/ 22 dBm（-2）；内置 TKL LoRaWAN 网络服务器与物联网平台 |
PoE / Type-C / DC 5-24 V；导轨安装；支持双网关冗余架构 | 大型楼宇、园区、工业现场、智慧物业；需要边缘计算与本地平台 |
| GDO51 | IP67 室外网关 | 最多 16 频点 / 32 信道 | PoE | 楼顶、园区室外、机房外延覆盖 |
选择逻辑可以简化成三句话：
楼宇改造里最贵的往往不是无线传感器，而是存量有线表计怎么接入。
ManThink 的做法是用 DTU 把有线协议转换成 LoRaWAN：
| 产品 | 供电 | 安装 | 接口 | 典型场景 |
|---|---|---|---|---|
| KC11 | AC 85-270 V | DIN 导轨 | RS-485 | 弱电间固定交流供电场景；大规模存量表计/仪表改造（已部署超 10 万台） |
| KC25 | DC 5-24 V | DIN 导轨 | RS-485 | 支持 EdgeBus 与 FUOTA |
| KC21 | 电池或外部供电 | 独立安装 | RS-485 | IP65，户外/恶劣环境 |
接入链路是标准的三段式，以一个真实设备为例：
建大仁科 UMxTH4xCN8F0 温湿度变送器（RS-485 / Modbus RTU）→ KC11 市电版 DTU（LoRaWAN Class C）→ ThinkLink 平台
这条路径的工程价值在于：它保留了建筑里已有的有线资产，只把"最后一跳"换成无线。 弱电间的 RS-485 表计不用拆、不用重接，加一个导轨式 DTU 就完成了无线化。
| 场景 | 对应产品 | 说明 |
|---|---|---|
| 温湿度 + 水浸 | KS52 | 可选点式或绳式水浸 |
| 温度（单点） | KS53 | DS18B20 或无探头版本 |
| 水浸（独立） | KS51 | 点式或绳式，电池或外部供电 |
| 室内空气质量 | KS61 | 86 盒式，四合一或七合一（温度 / 湿度 / TVOC / 光照度 / CO₂ / PM2.5 / 光照控制，功能位可单独使能） |
| 模拟量采集 | KS31 | 四通道 4-20 mA 或 0-10 V |
| 开关量状态 | KS32 | 干接点数字量输入 |
注意 KS61 的"功能使能位"设计——每一项（温度、湿度、TVOC、光照度、CO₂、PM2.5、光照控制）都可以通过位配置单独启用或禁用。这在合规场景下有用：北京要求 5 分钟采集频率的项目，可以只启用需要参与能耗指标计算的那几项，把上报负载压下来。
GD61x 不是楼宇全场景方案。
它的设计边界很明确：单根外置 LoRa 天线、面向室内、面向开发者和集成商的开放平台。它适合办公室、楼宇、园区、机房和小型工业现场的自建与定制场景。
如果你要的是：
选型的第一步不是比参数，是先说清楚你要自己搭多少。
把整篇文章压缩成四句话：
LoRaWAN 在楼宇已经是主流选择——1.25 亿台部署终端、25% 年增长、被 LoRa 联盟确认为楼宇领域第一大无线技术。驱动力不是技术炫技，是法规截止日期、改造经济性和产品生态成熟三件事同时到位。
技术瓶颈只有一个根因：余量。 穿墙衰减、SF 升高、空口开销放大、噪声底抬升——本质都是同一件事：链路余量被楼宇吃掉了。楼宇无线设计的所有工作，归根结底是把余量找回来。
工程上的答案是分区、降低上报频率、关掉确认上行、多做冗余。 这四条不需要买更贵的硬件，只需要在设计阶段做对。
真正的悬崖在组织侧，不在技术侧。 70% 的项目死在从 PoC 到生产的路上，死于 IT 安全评审、采购量价、安装权限和运维归属。PoC 如果没暴露问题，它就没测任何东西。
最后回到开头那个数字。
1 层到 3 层，65 米变成了"不可用"。这个结果之所以值得反复讲，不是因为它悲观，而是因为它可算。楼宇无线不像户外覆盖那样有大量不确定性——墙在那里、楼板厚度写在图纸上、材料衰减有实测值。这意味着只要在设计阶段认真做一次分区和余量计算，绝大多数覆盖问题是可以提前消除的。
楼宇是 LoRaWAN 最好的应用场景之一，恰恰因为它足够"不宽容"：它逼着工程团队把每一个参数都算清楚。
| 术语 | 说明 |
|---|---|
| LPWAN | Low-Power Wide-Area Network，低功耗广域网。特征是低功耗、广覆盖、大连接。分为授权频谱（NB-IoT / LTE-M）与非授权频谱（LoRaWAN / Sigfox） |
| LoRaWAN | 构建于 LoRa 物理层之上的开放 MAC 层协议，由 LoRa 联盟制定维护。星型拓扑，网关不负责跨网关通信 |
| SF（扩频因子） | Spreading Factor。取值 SF6-SF12。SF 越大，距离越远、抗干扰越强，但速率越低、空口开销越大 |
| ToA（空中时间） | Time on Air。一帧数据占用信道的时间 |
| ADR | Adaptive Data Rate，自适应数据速率。网络侧根据链路质量调整设备的 SF、发射功率与重传次数 |
| BACS | Building Automation and Control System，楼宇自动化与控制系统。欧盟 EPBD 对大型非住宅建筑强制要求 |
| BMS | Building Management System，楼宇管理系统 |
| BACnet | 楼宇自控领域主流开放标准协议。BMS 生态的事实标准 |
| KNX | 欧洲楼宇控制总线标准，KNX TP1 为双绞线物理层 |
| M-Bus | 仪表总线，常用于热量表、水表等计量设备 |
| BACS 法令（法国） | 法国落地的强制楼宇自动化要求，分阶段降低建筑能耗 |
| EPBD | Energy Performance of Buildings Directive，欧盟建筑能效指令。修订版 (EU) 2024/1275 要求 2026-05-29 前完成各国转换 |
| FUOTA | Firmware Update Over The Air，空中固件升级。LoRaWAN 1.1+ 及部分 1.0.4 设备支持 |
| MAC 命令 | LoRaWAN 协议层的管理指令，走下行 |
| 确认上行 | Confirmed Uplink。需要网络返回 ACK 的上行报文，每条消耗一次下行 |
| 噪声底 | Noise Floor。接收机处的本底噪声水平。抬升 3 dB 相当于有效距离减半 |
| 菲涅尔区 | Fresnel Zone。射频能量传输路径周围的椭球空间。即使视距通畅，物体侵入该区域也会造成干扰 |
标准与法规
行业数据
技术实测与工程参考
厂商产品文档
相关文章