5.2 网络架构四要素与角色分工
5.2 网络架构四要素与角色分工
本节摘要：把 LoRaWAN 网络拆成终端、网关、网络服务器、应用服务器四个角色，逐一指明各自能做什么、不能做什么，看懂"下行指令如何逆向走进终端"，为入网与 Class 做铺垫。承接 5.1 定位，通往 5.3。
LoRaWAN 网络虽叫"协议"，实际是一套四件套协作系统。每个角色都很"专制"——只做自己那件事，不越权。本节把四件套逐一立起来，再看一条下行指令怎么逆向走回终端。
四件套各自是谁
- 终端（End Device）：采集与执行的基层。设了城市中的传感器/执行器，按规定醒来上报，平时休眠。
- 网关（Gateway / Concentrator）：透明的射频中继。它并车听一大片频段、把收到的上行原样转发给网服，对业务内容一无所知，也不会解密。
- 网络服务器（Network Server）：网络的大脑。负责入网认证、报文去重、ADR 速率调节、下行调度，管理的是一切"网络层"事务。
- 应用服务器（Application Server）：业务的码头。接收网服转来的应用载荷并用 AppSKey 解密，把业务数据交给应用。
一次上行，四个角色各干了啥
用一张流程图把"一条上行（终端→应用）"每跳的分工钉清：
有意思的一点：网关对内容"一无所知"，而网络服务器也只见网络层、不见业务明文——应用载荷从终端到应用服务器全程用 AppSKey 加密，即使网关和网服是中立的或已被入侵，也读不到业务数据。
角色分工怎么看齐下行
下行（云→终端）是 LoRaWAN 更讲究的一环，因为终端平时在睡觉。设想"给某只阀门下达关闭指令"：
- 应用服务器把指令交给网络服务器，指明目标 DevAddr。
- 网络服务器查该终端所属网关、当前的接收窗口与数据速率，调度好下行时机。
- 指令下行到对应网关，网关在终端预约的接收窗口唤醒它。
- 终端在窗口内收下、校验 MIC、解密，执行动作。
所以下行不是"想发就发"，而是"得等终端醒来"——这直接引出 5.3 的接收窗口（Class）概念，是把"睡着"的省电哲学落实成协议的关键。
一张表把四件套对齐
| 角色 | 职责 | 不该管 | 关键数据 |
|---|---|---|---|
| 终端 | 采集/执行、按时上报、收下行 | 不做网关路由 | DevAddr、帧计数 |
| 网关 | 透明中继、收听频段 | 不解密、不懂业务 | 网关 ID |
| 网络服务器 | 入网去重、ADR、下行调度 | 不解应用明文 | NwkSKey、会话状态 |
| 应用服务器 | 解密应用载荷、对接业务 | 不管网络拓扑 | AppSKey、业务语义 |
一个常被弄错的边界
许多人以为"LoRaWAN 安全是因为加密了"，更准确的图景是：加密分两把钥匙，一把归网络层（NwkSKey）、一把归应用层（AppSKey），由网络服务器与应用服务器分开保管。这样即使网络被攻破，应用也不失身；反之应用被攻破，网络仍可照常认证。搞清这条边界，5.5 细讲密钥体系时才不会乱。
💡 关键直觉：LoRaWAN 的安全设计"按责任拆钥"——谁管网络、谁管业务，各有独立密钥，这种分层防的是"一处失守、全线溃堤"。
一次上行再追到"帧级"看看各角色动了什么
前面说"网关不解密、网服只见网络层"，还停在口头上。把四个角色对上"上行帧"实际做了什么，逐个对号：
| 环节 | 这一跳对"上行帧"做了什么 | 它拿到的钥匙 |
|---|---|---|
| 终端 | 打帧：填 DevAddr+帧计数、用 NwkSKey 算 MIC、用 AppSKey 加密应用载荷 | NwkSKey + AppSKey |
| 网关 | 原样转发，校验一下射频有效性 | 无（不碰密钥） |
| 网络服务器 | 校验 MIC、去重、按 ADR 调参、解密网络层头、剥离应用载荷 | NwkSKey |
| 应用服务器 | 用 AppSKey 解密应用载荷，交给业务 | AppSKey |
这张表把"分层拆钥"落到实处：MIC（消息完整性校验）由 NwkSKey 保护，业务明文由 AppSKey 保护。哪一层被攻破，影响的只是该层能看的部分——这正是四件套分工的价值。
一个多网关场景：去重为什么是网服的活
LoRaWAN 常有多台网关同时听到同一台终端的同一帧（建网成本低就多布网关）。若各自把这一帧转发上去，应用就会收到好几份重复。于是去重（Dedup）坚决由网络服务器统一做：它按帧序号（帧计数）+ 终端标识比对，只保留一份交网上游。也正是因为去重权归一在网服，网关才可以"笨得透明"——它不需要记账，只负责把可能重复的听到全交给网服，由网服去重。理解这一步，你就明白为什么 LoRaWAN 的拓扑敢把这么多判断集中到一台云端服务器上。
一个真实排查：网关说"接到了"应用却说"没收到"
现场最常见的怪现象是"网关数据显示收到，可应用侧就是没有"。顺着四件套的分工排查会立刻聚焦到两层：先看网络服务器去重/解密是否把该帧当成重复丢掉了，或 NwkSKey 与网服对不上导致 MIC 校验失败被弃；再看应用服务器是否因 AppSKey 不符解不出明文，或载荷格式解析出错被丢弃。若两者都正常，才回到射频链路看丢包。用"逐角色对号"的思路排，而不是一上来就怀疑天线，能省掉大量无效折腾。
💡 一个小提示：LoRaWAN 的排障和 MQTT/CoAP 的排障有个重要差异——它多了一个"实物射频"环节（电平、干扰、占空比），但四件套的逻辑层问题（钥匙、去重、丢包）往往更先被怀疑。把"先逻辑钥匙、再网络去重、最后射频"作为排查次序，命中率最高。
本节要点回顾
- 要点一：四要素是终端、网关、网络服务器、应用服务器，各司其职不越权。
- 要点二：网关透明转发、不解密；网络服务器管网络层；应用服务器才解业务数据。
- 要点三：下行要靠终端在预约的接收窗口醒来，不能想发就发。
- 要点四：NwkSKey 归网络层、AppSKey 归应用层，分开保管实现分层防御。
四件套就位，5.3 该让终端"醒来"了——三种接收窗 Class 与 OTAA 入网流程。