2. LoRaWAN 网络架构：四个角色的分工与协作

好，咱们进入正题。LoRaWAN 网络架构，说白了就是四个角色在干活：终端节点、网关、网络服务器、应用服务器。很多人刚接触时容易搞混，尤其是网关和网络服务器的区别。我刚开始做项目时也踩过这个坑，今天咱们一次讲清楚。

2.1 终端节点：最前线的“哨兵”

终端节点就是那些传感器、执行器，比如温湿度计、水表、烟感。它们负责采集数据，或者接收指令做动作。

核心特点：

• 低功耗：一颗电池用几年，这是 LoRa 的看家本领。
• 低成本：芯片几块钱，适合大规模部署。
• 单向或双向通信：大部分场景是上行（数据上报），少数需要下行（控制指令）。

我在项目中遇到过一个问题：客户说节点上报数据不稳定。排查后发现，是节点发射功率设置得太低，导致网关收不到。嗯，这里要注意：发射功率不是越大越好，但也不能太小，得根据实际距离和遮挡物来调。

2.2 网关：数据的中转站

网关是 LoRaWAN 网络里的“二传手”。它负责：

• 接收终端节点发来的 LoRa 射频信号
• 把数据打包成 IP 包，通过以太网、4G 或 WiFi 转发给网络服务器
• 反过来，把网络服务器的下行指令转成 LoRa 信号发给节点

网关和路由器的区别：很多人以为网关就是 LoRa 路由器。其实不是。网关不做数据解析，它只做协议转换——从 LoRa 无线到 TCP/IP 有线。

2.3 网络服务器：整个网络的大脑

网络服务器是 LoRaWAN 架构里最核心的部分。它负责：

• 数据去重：同一个节点发来的数据，可能被多个网关收到。网络服务器会过滤掉重复包。
• MAC 层处理：包括入网认证、确认帧、速率自适应（ADR）等。
• 下行调度：决定什么时候、通过哪个网关给节点发指令。
• 安全加密：管理会话密钥，保证数据不被篡改。

为什么会需要网络服务器？因为网关是“傻”的，它只管转发。真正的智能决策都在网络服务器里。举个例子：

// 伪代码：网络服务器的去重逻辑
function deduplicate(packets):
    seen = {}
    for pkt in packets:
        // 用 DevAddr + FCnt + MIC 判断是否重复
        key = pkt.DevAddr + ":" + pkt.FCnt + ":" + pkt.MIC
        if key not in seen:
            seen[key] = pkt
    return seen.values()

这段代码看着简单，但实际项目中，网络服务器每秒可能要处理成千上万个包。性能优化是个大课题。

2.4 应用服务器：数据的最终归宿

应用服务器是离用户最近的一层。它负责：

• 数据解析：把网络服务器传来的二进制数据，转成人类能看懂的格式（比如温度 25.3°C）。
• 业务逻辑：比如温度超过阈值就报警，或者定时生成报表。
• 用户接口：提供 API 或 Web 界面，让用户查看数据、下发指令。

应用服务器和网络服务器之间，通常通过 MQTT 或 HTTP 通信。我个人习惯用 MQTT，因为它是推送式的，实时性更好。

2.5 四个角色的协作流程

咱们用一个实际例子串一遍：

1. 终端节点采集到温度 25.3°C，打包成 LoRa 数据包，通过射频发出去。
2. 网关 A 和 网关 B 都收到了这个包。它们各自加上接收信号强度（RSSI），通过互联网转发给网络服务器。
3. 网络服务器收到两个包，发现是重复的，只保留一个。然后解密、校验，把有效载荷推送给应用服务器。
4. 应用服务器解析数据，显示在仪表盘上。如果温度超过阈值，触发报警。

你看，整个过程环环相扣。任何一个环节出问题，数据就传不到用户手里。

2.6 一张表总结

角色	主要功能	通信方式	典型设备
终端节点	数据采集、执行指令	LoRa 射频	传感器、执行器
网关	协议转换、数据转发	LoRa + 以太网/4G	LoRa 网关
网络服务器	MAC 层处理、去重、安全	TCP/IP	ChirpStack、TTN
应用服务器	数据解析、业务逻辑	MQTT/HTTP	用户自建平台

好，这一章就到这里。下一章咱们聊终端节点的入网流程，那是另一个容易出坑的地方。