芯耀
与非AI
734
LoRaWAN标准协议已成为低功耗广域物联网领域应用最广泛的开源通信规范之一。根据 LoRa Alliance 发布的 LoRaWAN 链路层规范（TS001-1.0.4），该协议定义了终端设备的入网认证、数据加密、速率自适应等完整的 MAC 层机制，其中 Class A 与 Class C 两种设备类别构成了大多数实际部署的基础。本文将从 LoRa 与 LoRaWAN 的本质区别入手，系统解读协议的网络架构、设备类别、OTAA 入网流程以及网络服务器（NS）的核心作用，最后以 ChirpStack 开源 NS 与纵横智控 EG2000-LoRaWAN 方案为例，说明标准协议在工业场景中的落地路径。
关键要点
LoRa 是 Semtech 的物理层调制技术，LoRaWAN 是建立在 LoRa 之上的开放 MAC 层协议标准，二者分属 OSI 模型的不同层级。
LoRaWAN 网络由终端设备、网关、网络服务器（NS）、应用服务器（AS）四要素构成，网关仅做透明转发，协议处理集中在 NS。
Class A 采用"上行后开两个短接收窗口"机制，功耗最低；Class C 几乎持续监听，下行延迟最低，二者可在同一网关下混用。
OTAA 是 LoRaWAN 推荐的入网方式，通过 DevEUI/AppEUI/AppKey 三要素完成空中入网并派生会话密钥，安全性高于 ABP。
网络服务器（NS）承担入网管理、数据解密、多网关去重、MAC 指令处理四项核心功能，是整个协议网络的核心组件。
ChirpStack 是业界广泛使用的开源 LoRaWAN NS，将其内置到网关本地可实现断网不断业务的边缘自治架构。
LoRaWAN vs 私有LoRa：标准化的价值
在讨论 LoRaWAN 标准协议之前，需要先厘清一个长期存在的概念混淆：LoRa 与 LoRaWAN 并非同一事物。
LoRa（Long Range）是 Semtech 公司开发的物理层调制技术，采用线性调频扩频（Chirp Spread Spectrum, CSS）调制方式，工作在免授权 sub-GHz ISM 频段。LoRa 只定义了"比特如何在空中传输"——它对应 OSI 模型的物理层（PHY），LoRa 芯片本身只完成物理层的调制解调工作。
LoRaWAN 则是 LoRa Alliance 维护的开放网络通信协议标准，定义在 LoRa 物理层之上，对应 OSI 模型的 MAC 层。它规范了设备寻址、入网认证、消息加密、速率自适应、多信道并发等完整的网络层机制。当前广泛部署的链路层规范版本为 TS001-1.0.4（2020 年 10 月发布）。
理解这一区分后，"私有 LoRa"与"LoRaWAN 标准"的差异便清晰可见：
私有 LoRa 方案中，各厂商基于 LoRa 物理层自行定义 MAC 层协议，通常采用点对点透传模式，终端节点只能与同一品牌的网关通信，跨厂商设备无法互通。入网认证、数据加密、信道管理等机制因厂商而异，缺乏统一规范。
LoRaWAN 标准 方案则提供统一的 MAC 层规范，不同厂商生产的终端设备只要符合 LoRaWAN 规范即可在同一网络中互通，协议标准内置了 OTAA 入网认证、AES-128 端到端加密、多信道并发接收等机制。
| 对比维度 | 私有 LoRa | LoRaWAN 标准协议 |
|---|---|---|
| 协议标准 | 厂商自定义，无统一规范 | LoRa Alliance 开放标准（TS001-1.0.4） |
| 多厂商兼容 | 不支持，仅同品牌设备互通 | 支持，符合规范的设备均可接入 |
| 入网认证 | 无统一机制或厂商自定义 | OTAA 标准入网流程 |
| 数据加密 | 厂商可选实现 | AES-128 端到端加密（AppSKey/NwkSKey） |
| 多信道并发 | 通常单信道 | 支持多信道并发接收 |
| 网络服务器 | 通常无独立 NS 架构 | 标准 NS 架构，集中处理 |
| 适用规模 | 小规模点对点通信 | 大规模星型网络部署 |
在中国市场，LoRaWAN 标准协议的部署需遵循工信部 2019 年第 52 号公告的技术要求。该公告将 470–510 MHz 频段分配给微功率短距离无线电发射设备使用，规定发射功率限值 50 mW（e.r.p）、单次发射持续时间不超过 1 秒、占用带宽不大于 500 kHz，并要求民用计量仪表设备具备"发射前搜寻"等干扰规避功能。LoRaWAN 的信道活动检测（CAD）与跳频机制从技术上满足这些合规要求。
LoRaWAN网络架构四要素
LoRaWAN 采用星型拓扑（star-of-stars topology）网络架构，由四个功能要素协同完成端到端数据传输。每个要素在网络中承担明确且不可替代的职责：
| 网络要素 | 角色定位 | 核心功能 |
|---|---|---|
| 终端设备（End Device） | 传感器 + LoRaWAN 模组 | 采集数据并按 Class A/C 机制收发，执行入网与加密 |
| 网关（Gateway） | 射频收发 + IP 回传 | 透明转发 LoRa 射频数据至 NS，不做协议解析 |
| 网络服务器（NS） | 网络核心 | 入网管理 / 数据解密 / 多网关去重 / MAC 指令处理 |
| 应用服务器（AS） | 业务处理 | 解析应用数据 / 下发下行指令 / 对接业务平台 |
需要特别说明网关的"透明转发"特性：LoRaWAN 网关不做任何协议处理，它接收射频范围内的所有 LoRa 数据包，通过 IP 网络（以太网、4G、Wi-Fi 等）回传至网络服务器。一个终端设备的上行数据可能被多个网关同时接收，去重处理由 NS 完成。这种设计与 Wi-Fi/蜂窝网的"设备绑定单个基站"模式有本质区别——LoRaWAN 终端不与任何特定网关关联。
数据流向为单向链路：终端设备 → 网关 → 网络服务器（NS）→ 应用服务器（AS）→ 应用平台。上行数据沿此路径逐层传递，下行指令则逆向传输。NS 在整个链路中承担协议核心处理职责，是数据从射频信号转化为可用业务数据的关键节点。
Class A vs Class C：终端设备类别详解
LoRaWAN 规范定义了三种终端设备类别（Class A / B / C），其中 Class A 是所有设备必须实现的基础类别，Class B 通过网关信标同步实现定时接收窗口，Class C 则提供近乎持续的下行接收能力。在实际工业部署中，Class A 与 Class C 是使用最广泛的两种类别。
Class A：低功耗类别
Class A 采用 ALOHA 协议的接入机制：终端设备根据自身通信需求主动发起上行传输，上行结束后依次开启两个短暂的下行接收窗口——RX1 和 RX2。
RX1：在上行传输结束后 RECEIVE_DELAY1 秒开启，频率与上行频率相关，速率与上行速率相关。
RX2：若 RX1 未收到有效下行帧，则在上行传输结束后 RECEIVE_DELAY2 秒开启，使用固定可配置频率和速率。
两个接收窗口之外的时间，终端设备进入休眠状态，射频模块关闭。这使得 Class A 成为功耗最低的设备类别，适合电池供电的传感器长期运行。下行通信的代价是延迟——服务器只能在终端发起上行后的短暂窗口内下发数据，其余时间的下行请求必须等待下一次上行触发。典型应用包括电池供电的智能水表、燃气表、环境监测传感器等。
Class C：低延迟类别
Class C 终端在除发送时段外的几乎所有时间持续开启下行接收窗口。网关可在任意时刻向 Class C 设备下发指令，无需等待终端先发起上行。这使得 Class C 具有最低的下行通信延迟。
代价是功耗显著高于 Class A——射频接收模块几乎持续工作，不适合电池供电场景。Class C 适用于有市电供电、且需要实时下行控制的应用，如路灯控制、电磁阀控制、工业执行器等。
| 对比维度 | Class A | Class C |
|---|---|---|
| 下行接收窗口 | 上行后开启 RX1/RX2 两个短窗口 | 除发送时段外持续开启 |
| 功耗 | 最低（休眠占绝大部分时间） | 较高（接收模块持续工作） |
| 下行延迟 | 高（取决于上行发包间隔） | 最低（随时可下发） |
| 适用供电方式 | 电池供电 | 市电供电 |
| 典型应用 | 水表、燃气表、环境传感器 | 路灯控制、电磁阀、工业执行器 |
同一 LoRaWAN 网关可同时管理 Class A 与 Class C 设备，二者在同一网络中并存运行，由 NS 统一调度。
OTAA入网流程详解
OTAA（Over-The-Air Activation，空中激活）是 LoRaWAN 规范推荐的设备入网方式，通过空中接口完成设备身份认证与会话密钥协商，安全性高于预置密钥的 ABP 方式。
入网三要素
OTAA 入网依赖以下三个核心参数：
DevEUI：设备唯一标识，全球唯一 64 位标识符，通常基于设备 MAC 地址生成。
AppEUI（JoinEUI）：应用标识，64 位标识符，用于标识设备所属的应用/网络。
AppKey：应用密钥，128 位 AES 密钥，用于派生会话密钥及入网请求/响应的加密校验。
入网流程
OTAA 入网流程分为五个步骤：
终端发送 Join Request：终端生成随机数 DevNonce，连同 DevEUI 和 AppEUI 组成入网请求帧，用 AppKey 计算 MIC（消息完整性码）后发送。
NS 验证设备信息：网络服务器收到 Join Request 后，验证 DevEUI/AppEUI 是否已注册，检查 DevNonce 是否被重放，验证 MIC 完整性。验证通过后，NS 为设备分配 DevAddr（32 位设备地址）并生成会话密钥 AppSKey（应用会话密钥）和 NwkSKey（网络会话密钥）。
NS 回复 Join Accept：网络服务器生成 AppNonce 和 NetID，连同 DevAddr 组成入网接受帧，用 AppKey 加密后回复终端。
终端派生会话密钥：终端用 AppKey 解密 Join Accept，提取 AppNonce/NetID/DevAddr，基于 AppKey、AppNonce、NetID、DevNonce 派生出 AppSKey 和 NwkSKey。
入网完成：终端获得 DevAddr、AppSKey、NwkSKey 后，入网流程结束，可开始加密数据收发。
OTAA vs ABP
ABP（Activation By Personalization，个性化激活）是另一种入网方式：DevAddr、NwkSKey、AppSKey 在设备生产或配置时预置，设备无需经历入网流程即可直接收发数据。ABP 部署简单，但会话密钥固定不变，无法实现密钥轮换，安全性低于 OTAA。LoRaWAN 规范推荐生产环境使用 OTAA，ABP 适用于开发测试或固定密钥场景。
| 入网参数 | 说明 | 长度 |
|---|---|---|
| DevEUI | 设备唯一标识 | 64 bit |
| AppEUI | 应用/网络标识 | 64 bit |
| AppKey | 应用根密钥，派生会话密钥 | 128 bit |
| DevAddr | NS 分配的设备网络地址 | 32 bit |
| AppSKey | 应用会话密钥，端到端数据加密 | 128 bit |
| NwkSKey | 网络会话密钥，MAC 完整性校验 | 128 bit |
| DevNonce | 终端生成的随机数，防重放 | 16 bit |
网络服务器（NS）的核心作用
网络服务器是 LoRaWAN 网络的核心组件。网关只负责射频收发与透明转发，协议层面的处理逻辑集中在 NS。具体而言，NS 承担四项关键功能：
a. 入网管理：NS 处理终端发起的 OTAA Join Request，验证设备身份信息（DevEUI/AppEUI），检查 DevNonce 防重放，分配 DevAddr 并生成会话密钥（AppSKey/NwkSKey），完成 Join Accept 回复。
b. 数据解密：网关转发的是加密的 LoRaWAN 帧，NS 使用 NwkSKey 校验 MIC 消息完整性，使用 AppSKey 解密应用负载为明文数据。网关本身不参与解密——加密在终端与 NS/AS 之间端到端完成。
c. 去重处理：当多个网关同时收到同一终端的上行数据时（这在 LoRaWAN 星型拓扑中是常态），NS 去除重复帧，只输出一份有效数据至应用服务器，同时记录各网关的接收信号质量用于下行路径选择。
d. MAC 指令处理：NS 管理终端的速率自适应（ADR，Adaptive Data Rate），根据链路质量调整终端的扩频因子（SF7–SF12）和发射功率；管理占空比限制、信道配置切换、设备状态同步等 MAC 层指令。
NS 的部署位置直接影响网络的可靠性。传统模式下，NS 部署在云服务器上，网关通过 4G/以太网将数据回传至云端 NS 处理。这种方式在链路正常时运行良好，但存在两个结构性问题：一是断网时 NS 不可用，整个 LoRaWAN 网络随之瘫痪；二是需要额外的服务器成本和运维开销。
| 对比维度 | 传统云部署 NS | 边缘内置 NS |
|---|---|---|
| 部署位置 | 云服务器，网关远程回传 | 网关本地运行 |
| 延迟 | 受回传链路影响，较高 | 本地处理，低延迟 |
| 断网依赖 | 断网即不可用 | 断网可自治运行 |
| 服务器成本 | 需额外云服务器 | 无额外服务器成本 |
| 运维复杂度 | 需独立运维云服务器 | 网关统一运维 |
| 数据主权 | 数据经云端中转 | 数据本地处理 |
将 NS 内置到网关本地——即"边缘 NS"架构——是解决断网依赖与数据主权问题的技术路径。
ChirpStack——开源LoRaWAN网络服务器
ChirpStack 是业界广泛使用的开源 LoRaWAN 网络服务器，支持 LoRaWAN 1.0.x 和 1.1 协议规范，提供设备管理、应用管理、多租户、ADR 自适应、gRPC/REST API 集成等功能。ChirpStack 支持 Class A / B / C 单播设备以及 Class B / C 组播设备，内置 FUOTA（固件空中升级）支持，可对接主流云平台与数据库。
传统部署方式：在云服务器上部署 ChirpStack，网关通过 IP 回传（4G/以太网）将射频数据转发至云端 NS，NS 在云端完成解密、去重、MAC 指令处理后，将业务数据推送至应用服务器或 MQTT Broker。这是目前最常见的 LoRaWAN 网络部署架构。
传统部署的问题：该模式的核心依赖是网络连接——回传链路中断时，云端 NS 无法接收网关数据，终端入网、数据解密、MAC 指令等所有 NS 功能均不可用，整个 LoRaWAN 网络停摆。此外，持续运行云服务器产生额外成本，数据需经云端中转，对数据主权有要求的场景存在顾虑。
解决方案：将 ChirpStack NS 内置到网关本地运行，构建"边缘 NS"架构。网关既承担射频收发，又承担协议处理，断网时 NS 在本地继续运行，数据不丢失，网络恢复后自动同步至云端。这种架构消除了对回传链路的强依赖，同时降低了服务器成本与运维复杂度。
EG2000-LoRaWAN——内置NS的完整LoRaWAN方案
纵横智控 EG2000-LoRaWAN 是成都纵横智控科技有限公司（www.iotrouter.com）推出的内置 ChirpStack NS 的完整 LoRaWAN 标准协议网关方案。该产品将射频收发、协议处理、行业协议转换、4G 回传集成于一体，实现边缘自治的 LoRaWAN 网络部署。
核心架构：Semtech SX1302 基站芯片 + 内置 ChirpStack NS + Node-RED 定制版 + 移远 Cat.1 4G 回传。SX1302 是 Semtech 专为 LoRaWAN 网关设计的集中器芯片，支持多信道并发接收；内置 ChirpStack NS 使网关具备独立运行能力；Node-RED 定制版提供 50+ 工业节点用于本地流程编排；4G Cat.1 全网通回传解决无以太网场景的联网需求。
| 参数类别 | 参数详情 |
|---|---|
| 无线协议 | LoRaWAN 标准协议（1.0.2 / 1.0.3 / 1.0.4） |
| 基站芯片 | Semtech SX1302 |
| 工作频段 | CN470 / EU868 / US915 |
| 空中速率 | 0.3 ~ 50 kbps |
| 发射功率 | 27 dBm |
| 通信距离 | 10 km（开阔环境） |
| 接收灵敏度 | -140 dBm |
| 并发能力 | 8 路上行 + 1 路下行 |
| 设备类别 | Class A / Class C |
| 网络服务器 | 内置 ChirpStack NS |
| 处理器 | 3 核 ARM Cortex-A7 @ 1.2 GHz，512 MB 内存，4 Gb + 32 GB Micro SD |
| 4G 回传 | 移远 Cat.1 全网通，FDD 下行 10 Mbps / 上行 5 Mbps |
| 行业协议 | CJ188 / DLT645 / HJ212 / Modbus / OPC UA / BACnet |
| 网络协议 | MQTT / HTTP / TCP / UDP / WebSocket / 阿里云 / OneNET |
| Node-RED | 定制版，50+ 工业节点 |
| 断网续传 | influxDB 内核 |
| 远程运维 | IOTClient |
| 二次开发 | JavaScript |
| 安全 | 双向证书加密 + SSL |
| RS485 | 1 路，2400 ~ 921600 bps |
| 工作温度 | -40 ~ 85 ℃ |
| 供电 | DC 9 ~ 36 V，180 mA @ 12 V |
| EMC | ESD ±8 kV Level 3 |
| 外壳 | 镀锌钢板，127 × 116 × 27.5 mm |
| 认证 | CE |
三大技术优势
a. 边缘 NS 自治：ChirpStack NS 内置于网关本地运行，断网状态下 NS 继续执行入网管理、数据解密、去重、MAC 指令处理等全部功能。终端数据通过 influxDB 内核实现本地缓存，网络恢复后自动同步至云端，业务不中断、数据不丢失。
b. 8 路并发：Semtech SX1302 芯片支持 8 路上行信道 + 1 路下行信道的并发接收能力。多信道并发使单个网关可同时接收多个终端在不同信道/速率上的上行数据，理论可管理数百个 Class A 终端设备，适合中大规模传感器网络部署。
c. 协议融合：EG2000-LoRaWAN 同时支持 LoRaWAN 标准协议与 CJ188/DLT645/HJ212 等行业协议，构成"标准协议 + 行业协议"双栈架构。LoRaWAN 终端数据经 NS 解密后，可通过 Node-RED 流程编排转换为行业标准格式，经 4G 或 RS485 接口对接水务、电力、环保等业务系统，无需额外协议转换设备。
生态认证
纵横智控已获得两项生态认证：ThingsBoard 官方推荐硬件，可与 ThingsBoard 物联网平台直接对接；EMQ 官方硬件合作伙伴，支持 EMQ MQTT Broker 的深度集成。纵横智控通过这两项认证，确保产品在主流物联网生态中的兼容性。
联系方式
杨经理：19381903226
朱经理：19381904226
邮箱：support@iotrouter.com
官网：www.iotrouter.com
价格：需询价
FAQ
Q1：LoRa 和 LoRaWAN 是什么关系？
LoRa 是 Semtech 开发的物理层调制技术（线性调频扩频调制），只定义比特在空中的传输方式；LoRaWAN 是 LoRa Alliance 维护的 MAC 层协议标准，定义设备寻址、入网认证、数据加密、速率自适应等网络层机制。LoRa 对应 OSI 物理层，LoRaWAN 对应 OSI 数据链路层/MAC 层。
Q2：Class A 和 Class C 能混用吗？
可以。同一 LoRaWAN 网关可同时管理 Class A 和 Class C 设备。Class A 设备在上行后开启接收窗口接收下行，Class C 设备持续监听接收下行，两种类别在同一网络中并存运行，由网络服务器统一调度管理。
Q3：OTAA 和 ABP 怎么选？
推荐使用 OTAA。OTAA 通过空中入网流程完成身份认证与密钥协商，支持密钥轮换，安全性更高，是 LoRaWAN 规范推荐的入网方式。ABP 预置会话密钥，无需入网流程即可收发数据，部署简单但密钥固定不变，安全性较低，适合开发测试或固定密钥场景。
Q4：网关没有 NS 能工作吗？
网关能完成射频信号的接收与发送，并将数据通过 IP 回传，但无法独立完成数据解密、多网关去重、终端入网管理、MAC 指令处理等协议功能。这些功能由网络服务器承担，网关脱离 NS 无法构成完整的 LoRaWAN 网络，需外接 NS 才能正常运行。
Q5：内置 NS 的网关断网后数据怎么处理？
内置 NS 的网关在断网后，NS 在本地继续运行，终端入网、数据解密、去重、MAC 指令处理等功能不受影响。终端上行数据经 NS 解密后通过本地数据库（如 influxDB 内核）缓存，网络恢复后自动将缓存数据同步至云端应用平台，业务不中断，数据不丢失。
