LoRaWAN 核心技术体系详解

LoRaWAN（Long Range Wide Area Network）是基于LoRa扩频调制技术的低功耗广域网（LPWAN） 协议标准，由LoRa联盟制定，专为物联网设备的远距离、低功耗、低成本通信需求设计，广泛应用于智能抄表、环境监测、资产追踪等场景。

一、 核心定位与设计目标

  1. 技术基础：LoRa是物理层（PHY）的扩频调制技术，LoRaWAN是基于LoRa的媒体访问控制层（MAC） 协议，定义了终端、网关、服务器的交互规则。
  2. 核心目标
    • 远距离：单网关覆盖半径可达1-10km（城市环境）、10-30km（郊区/农村环境）；
    • 低功耗：终端电池寿命可达数年（Class A设备，占空比<1%）；
    • 大容量：单网关可接入数千台终端设备；
    • 低成本：终端与网关硬件成本低，无需布线，支持免授权ISM频段。

二、 网络架构

LoRaWAN采用星型拓扑，核心由4类实体组成（1.1版本架构，1.0版本无独立Join Server）：

实体核心功能关键特性
终端设备（End Device, ED）数据采集、指令执行、入网请求分Class A/B/C三类，支持OTAA/ABP入网，低功耗设计
网关（Gateway, GW）透明转发射频帧（上行→服务器，下行→终端）多信道接收，无终端密钥，仅做数据中继，不解析内容
网络服务器（Network Server, NS）终端鉴权、帧过滤、速率适配（ADR）、下行调度管理终端会话，存储网络层密钥，支持多网关协同
Join Server（JS，1.1版本新增）密钥管理、入网鉴权、会话密钥推导存储根密钥AppKey，负责跨网漫游鉴权，隔离安全风险
应用服务器（Application Server, AS）应用层数据解密、业务逻辑处理、指令下发存储应用层密钥AppSKey，对接用户业务系统

三、 核心技术特性

1. 终端设备类别（Class A/B/C）

LoRaWAN定义三类终端，平衡功耗与实时性，是协议的核心差异化设计：

类别接收窗口机制功耗水平典型应用
Class A上行发送后，开启两个短接收窗口（RX1/RX2），其余时间休眠最低（电池寿命数年）智能抄表、土壤传感器、温湿度监测
Class B在Class A基础上，增加周期性接收时隙（由网关信标同步）中等智能停车、资产追踪（需定时下行指令）
Class C持续监听下行信道，仅在发送上行数据时短暂关闭接收最高工业控制、实时告警（需超低延迟下行）

2. 自适应数据速率（ADR）

网络服务器根据终端上行数据的RSSI（接收信号强度） 和SNR（信噪比），动态调整终端的扩频因子（SF） 和带宽（BW）：

  • 信号好时：降低SF、增大BW → 提升传输速率、降低功耗；
  • 信号差时：提高SF、减小BW → 提升通信可靠性、延长传输距离。

核心价值：在覆盖范围内，最大化终端电池寿命与网络容量。

3. 频段与调制

  • 频段：使用全球免授权ISM频段，区域适配性强：
    • 欧洲：868MHz；北美：915MHz；中国：470-510MHz；东南亚：923MHz。
  • 调制技术：采用CSS（啁啾扩频调制），抗干扰能力强，支持非视距（NLOS）通信。
  • 传输速率：0.3kbps ~ 50kbps（由SF和BW决定）。

四、 入网方式

LoRaWAN支持两种入网方式，OTAA为推荐方式，安全性更高：

1. 空中激活（OTAA）

  • 核心特点：动态协商会话密钥，无人工预置，安全性高，支持漫游（1.1版本）；
  • 关键参数：1.0版本用DevEUI/AppEUI/AppKey；1.1版本用DevEUI/JoinEUI/AppKey；
  • 流程简述：终端发送Join Request → 服务器鉴权 → 下发加密Join Accept → 终端推导会话密钥 → 完成入网。

2. 预置激活（ABP）

  • 核心特点：人工预置会话密钥（NwkSKey/AppSKey）和终端地址（DevAddr），入网速度快；
  • 局限性：密钥静态存储，易泄露；不支持漫游；终端更换网络需重新配置参数；
  • 适用场景：对入网速度要求极高、无漫游需求的封闭场景。

五、 版本演进与核心差异

LoRaWAN的两大主流版本为1.0.x和1.1，核心差异聚焦于安全、漫游与架构：

对比维度LoRaWAN 1.0.xLoRaWAN 1.1
核心架构NS/AS合设，无独立JS新增Join Server，JS/NS/AS三层分离
标识体系AppEUI（64bit）JoinEUI（替代AppEUI），支持漫游路由
密钥体系两层密钥（NwkSKey/AppSKey）四层密钥（AppKey/NwkKey/SNwkSKey/AppSKey），分层隔离
Join Accept加密AES-128-ECB（安全性低）AES-128-CTR（抗重放攻击，安全性高）
漫游能力不支持原生支持跨运营商/跨区域漫游
重入网机制无，需重新走完整OTAA支持Type 0/1/2三种Rejoin，快速恢复会话
安全风险单密钥泄露影响网络+应用层密钥分层存储，风险隔离

六、 典型应用场景

LoRaWAN的低功耗、广覆盖特性，适配物联网“最后一公里” 的海量场景：

  1. 智慧城市：智能路灯、垃圾桶监测、井盖监测、智慧停车；
  2. 智慧能源：水电燃气抄表、充电桩监测、光伏电站运维；
  3. 智慧农业：土壤墒情监测、灌溉控制、牲畜定位、温室环境监测；
  4. 工业物联网：设备状态监测、资产追踪、厂区环境监测；
  5. 环境监测：空气质量监测、水质监测、噪声监测、地质灾害预警。

七、 部署与开发关键注意事项

  1. 频段合规：严格遵循目标区域的频段、发射功率、占空比限制（如中国470MHz频段占空比≤1%）；
  2. 设备选型：根据业务场景选择终端类别（优先Class A），确认支持OTAA和ADR；
  3. 密钥管理：AppKey需严格保密，禁止终端代码明文存储；1.1版本需确保JS与终端的AppKey一致；
  4. 网关部署：选择高处部署（如楼顶），避免遮挡，确保覆盖范围与信号质量；
  5. 兼容性：1.1版本终端可向下兼容1.0网络（关闭漫游功能），1.0终端无法接入1.1网络。

八、OTAA详解

LoRaWAN的OTAA（Over-The-Air Activation）空中激活是终端设备安全入网的标准方式，核心优势是动态协商会话密钥，无需人工预置参数，安全性远高于ABP（预置激活）。其流程在 1.0.x版本 和 1.1版本 存在关键差异（1.1新增独立Join Server和漫游能力），以下分版本详细拆解完整流程。

（一）、 核心前提：终端与服务器预置参数

OTAA的核心是终端和服务器共享根密钥与唯一标识，参数需严格一一对应，且AppKey必须保密存储（禁止终端代码明文写死）。

版本终端预置参数服务器预置参数参数作用
1.0.xDevEUI（64bit，设备唯一ID）
AppEUI（64bit，应用标识）
AppKey（128bit，根密钥）		同终端参数（存储在NS/AS合设的服务器）DevEUI识别设备
AppEUI绑定应用
AppKey推导会话密钥
1.1DevEUI（64bit）
JoinEUI（64bit，替代AppEUI，绑定Join Server）
AppKey（128bit）		DevEUI+JoinEUI+AppKey（存储在独立Join Server）
NS存储网络标识NetID		JoinEUI路由至对应JS
JS负责鉴权和密钥推导

（二）、 OTAA 完整流程（4步核心交互）

1.0.x无独立Join Server，鉴权和密钥推导由网络服务器（NS）+ 应用服务器（AS） 合设的节点完成。以下是LoRaWAN 1.0.4版本中OTAA入网的详细流程：分为 Join Request（入网请求）→ Join Accept（入网接受）→ 会话密钥推导 → 首次上行通信 四个阶段，采用非对称加密 + 对称加密结合的方式保障安全。

1. 阶段1：终端发送 Join Request 消息（上行）

终端设备上电后，首先在指定的入网信道（LoRaWAN 1.0定义了固定的Join信道，如中国470MHz频段为信道0-7）发送Join Request帧，帧结构与传输规则如下：

  • 帧结构（共23字节，固定长度）：
    字段长度内容说明
    MHDR1字节消息头：MType=000（标识为Join Request） + RFU=00 + Major=00（LoRaWAN R1版本）
    AppEUI8字节终端预置的应用标识，小端序传输（低字节在前）
    DevEUI8字节终端唯一标识，小端序传输
    DevNonce2字节终端生成的随机数，不可重复使用（防止重放攻击，需本地记录已使用的DevNonce）
    MIC4字节消息完整性校验码，由AppKey加密（AES-128-CMAC算法）生成，覆盖MHDR+AppEUI+DevEUI+DevNonce
  • 传输规则：
    • 采用固定扩频因子（SF）和带宽（BW）（如SF12、125kHz），确保网关高概率接收；
    • 可重复发送（间隔随机，避免冲突），直到收到Join Accept或达到最大重试次数。
2. 阶段2：网关转发 Join Request 至网络服务器（NS）

网关收到Join Request后，不解析帧内容（透明转发），通过IP链路将消息封装为JSON格式发送至网络服务器，同时携带以下辅助信息：

  • 网关标识（Gateway EUI）；
  • 接收信号强度（RSSI）、信噪比（SNR）；
  • 接收信道与频率。
3. 阶段3：网络服务器验证并回复 Join Accept 消息（下行）

这是OTAA流程的核心阶段，服务器需完成身份验证 + 生成会话参数 + 加密下发三个动作。

（1） 服务器身份验证

网络服务器收到Join Request后，执行以下校验步骤：

  1. 提取AppEUI和DevEUI，在设备注册表中查询对应的AppKey；
  2. 用查询到的AppKey，通过AES-128-CMAC算法重新计算MIC，与消息中的MIC对比：
    • 若不一致 → 丢弃消息，拒绝入网；
    • 若一致 → 验证通过，继续下一步。
  3. 校验DevNonce的唯一性：检查该DevEUI是否曾使用过相同的DevNonce，若重复 → 判定为重放攻击，拒绝入网。
（2） 服务器生成会话参数

验证通过后，服务器生成3个关键会话参数：

  • NetID（24bit）：网络服务器的唯一标识，用于区分不同LoRaWAN网络；
  • DevAddr（32bit）：分配给终端的临时网络地址，用于后续数据通信的地址标识（非唯一，可复用）；
  • AppNonce（32bit）：服务器生成的随机数，与终端的DevNonce配合推导会话密钥。
（3） 服务器加密并发送 Join Accept 消息

Join Accept是加密的下行消息，核心是防止会话参数被窃听，具体流程：

  1. 构建明文Join Accept帧（共12字节）：
    字段长度内容说明
    MHDR1字节MType=010（Join Accept） + RFU=00 + Major=00
    AppNonce3字节服务器生成的随机数
    NetID3字节网络标识
    DevAddr4字节分配给终端的网络地址
    DLSettings1字节下行接收窗口参数（如RX1偏移、RX2频率/速率）
    RxDelay1字节接收窗口延迟（默认1s，即RxDelay=1）
  2. 加密处理：
    • 用AppKey对明文Join Accept帧进行AES-128-ECB模式加密（ECB是LoRaWAN 1.0的规定，1.1版本优化为CTR模式）；
    • 加密后的密文作为下行发送内容，无需额外MIC（加密本身已保障完整性）。
  3. 下行发送规则：
    • 服务器通过网关，在终端Join Request发送后的RX1窗口（默认1s后）或RX2窗口（默认2s后）下发Join Accept；
    • 下行速率由终端上行速率决定（RX1速率与上行速率对应，RX2为固定速率，如SF12、125kHz）。
4. 阶段4：终端解密 Join Accept 并推导会话密钥

终端在RX1/RX2窗口接收到Join Accept密文后，执行以下操作完成入网：

（1） 解密 Join Accept 帧

终端使用本地预置的AppKey，通过AES-128-ECB解密，还原出明文帧，提取关键参数：AppNonce、NetID、DevAddr、DLSettings、RxDelay。

（2） 推导会话密钥（核心步骤）

基于AppKey、AppNonce、NetID、DevNonce四个参数，终端和服务器独立推导出两个128bit的会话密钥（双方推导结果完全一致），用于后续数据通信加密：

会话密钥推导算法（AES-128-ECB）作用
NwkSKey（网络会话密钥）输入参数：AppKey + 固定字符串 0x01 + AppNonce + NetID + DevNonce加密网络层数据（如MAC命令）、计算消息MIC
AppSKey（应用会话密钥）输入参数：AppKey + 固定字符串 0x02 + AppNonce + NetID + DevNonce加密应用层数据（如传感器采集的业务数据）

推导规则遵循LoRaWAN 1.0规范：密钥推导的输入字节流需按 [0x01/0x02] + AppNonce(3B) + NetID(3B) + DevNonce(2B) + 填充0x00至16B 的格式拼接，再用AppKey进行AES-ECB加密，输出即为128bit会话密钥。

（3） 完成入网，进入数据通信阶段

终端存储DevAddr、NwkSKey、AppSKey后，即完成OTAA入网流程。后续终端可使用这些参数发送上行数据帧（如Unconfirmed Data Up或Confirmed Data Up），服务器也可使用会话密钥向终端下发数据。

（三）、 LoRaWAN 1.1 版本 OTAA 流程（新增Join Server，支持漫游）

1.1版本重构架构，引入独立Join Server（JS），实现“密钥管理与网络解耦”，支持跨运营商漫游，流程分为5个阶段。

OTAA是LoRaWAN 1.1终端无预配置接入网络的核心方式，通过“前置准备→Join请求→Join响应→密钥派生→会话建立→Rejoin维护”的完整流程，实现动态密钥协商与安全接入，全程加密且支持漫游，核心依赖DevEUI/JoinEUI身份标识与Nonce计数器防重放。

1. OTAA前置核心条件（规范6.1.1）

终端与网络侧需提前完成以下配置，否则无法启动激活流程：

  • 终端侧预存信息（均为出厂/预配置，非易失性存储）：
    • JoinEUI（8字节）：关联终端所属的Join Server，用于路由激活请求；
    • DevEUI（8字节）：终端全球唯一标识，全网不可重复；
    • NwkKey（128位AES密钥）：网络层根密钥，用于身份校验与网络会话密钥派生；
    • AppKey（128位AES密钥）：应用层根密钥，仅用于应用会话密钥派生，网络侧无法解密应用数据。
  • 网络侧配置：
    • Join Server/Network Server已注册终端的JoinEUI、DevEUI、NwkKey、AppKey；
    • 终端与网关工作在同一频段（支持频段自动识别的终端可跳过频段预配置）。
2. OTAA完整激活流程（规范6.2.1-6.2.3）
2.1 第一步：终端发起Join-request（规范6.2.2）

终端上电后或会话丢失时，主动发送Join-request消息，触发激活流程：

  • 消息结构（共18字节）：
    字段长度（字节）说明
    JoinEUI8目标Join Server标识，路由激活请求
    DevEUI8终端唯一身份标识
    DevNonce2终端计数器，上电初始为0，每次发送递增，永不重复
  • 传输规则：
    • 信道与数据率：在指定Join信道（区域专属）随机跳频发送，建议多数据率尝试（提升成功率）；
    • 加密与校验：消息本身不加密，但需通过NwkKey计算4字节MIC（公式：cmac = aes128_cmac(NwkKey, MHDR | JoinEUI | DevEUI | DevNonce)），防止重放攻击；
    • 占空比限制：首小时累计发送时间≤36秒，后续按区域规范执行（如EU868频段≤0.1%）。
2.2 第二步：网络侧响应Join-accept（规范6.2.3）

网关将Join-request透传至Network Server（NS），经校验后由Join Server生成Join-accept响应：

  • 校验流程（NS/JS协同）：
    1. NS提取Join-request中的DevEUI，查询对应Join Server；
    2. JS验证DevNonce（需大于终端历史最大值）与MIC合法性，通过则生成Join-accept参数；
    3. NS将Join-accept通过网关下发至终端。
  • 消息结构（基础12字节，含可选CFList时为28字节）：
    字段长度（字节）说明
    JoinNonce3JS计数器，终端唯一，永不重复
    Home_NetID3终端归属网络标识，用于漫游识别
    DevAddr4动态分配的终端短地址（32位）
    DLSettings1下行参数（含OptNeg位、RX1DRoffset等）
    RxDelay1收发延迟（默认1秒，范围0-15秒）
    CFList（可选）16区域信道列表，覆盖终端默认信道配置
  • 传输规则：
    • 加密方式：用NwkKey（普通Join）或JSEncKey（Rejoin触发）AES-128加密，终端需解密后获取参数；
    • 下发时机：在终端RX1/RX2窗口发送，延迟为JOIN_ACCEPT_DELAY1（默认1秒）或JOIN_ACCEPT_DELAY2（默认2秒）；
    • 终端校验：接收后验证MIC与JoinNonce（需大于历史值），通过则进入密钥派生阶段。
2.3 第三步：会话密钥派生（规范6.2.5）

终端与网络侧基于相同参数独立派生会话密钥，无需直接传输，是OTAA安全性核心：

  • 派生触发条件：终端成功解密Join-accept并校验通过。
  • 派生参数：NwkKey/AppKey + JoinNonce + DevNonce + JoinEUI（1.1版本）/NetID（1.0兼容）。
  • 密钥派生结果（1.1版本分离设计，规范图49）：
    • 网络层会话密钥（由NwkKey派生）：
      • FNwkSIntKey：上行网络层消息MIC校验密钥；
      • SNwkSIntKey：下行网络层消息MIC校验密钥（支持漫游场景）；
      • NwkSEncKey：网络层数据加密密钥（加密FOpts/MAC命令）；
    • 应用层会话密钥（由AppKey派生）：
      • AppSKey：应用层业务数据（FRMPayload）加密/解密密钥。
  • 兼容1.0网络：若Join-accept中OptNeg位为0（1.0网络），则AppSKey由NwkKey派生，SNwkSIntKey/NwkSEncKey与FNwkSIntKey相同。
2.4 第四步：会话建立与初始化（规范6.1.2.6）

密钥派生完成后，终端与网络侧同步初始化会话状态，激活完成：

  • 终端侧：
    • 存储DevAddr、所有会话密钥；
    • 重置帧计数器（FCntUp=0、AFCntDown=0、NFCntDown=0）；
    • 启用默认信道或CFList配置的信道，进入数据传输状态。
  • 网络侧（NS/AS）：
    • 记录终端会话上下文（DevAddr、密钥、计数器初始值）；
    • 准备接收终端上行数据，或发起下行通信。

注意：终端不会发送专门的“激活成功确认消息”，而是通过后续首条上行数据（携带RekeyInd命令）间接向网络侧确认激活成功，网络侧接收后完成会话同步。

具体确认机制（规范5.10 + 6.2.3）：

a. 终端侧触发：终端完成密钥派生和会话初始化后，会在首次发送的上行数据（可能是业务数据或空帧）的FOpts字段中，携带RekeyInd命令（CID=0x0B）。

  • RekeyInd包含终端支持的LoRaWAN版本（Minor=1），用于告知网络侧“新会话密钥已生效”；
  • 终端会在所有上行帧中重复携带RekeyInd，直到收到网络侧的RekeyConf响应。

b. 网络侧确认：

  • Network Server收到含RekeyInd的上行数据后，验证MIC（基于新派生的会话密钥）和帧计数器（FCntUp=0），确认终端已成功激活并同步新会话上下文；
  • 网络侧回复RekeyConf命令（CID=0x0B），告知终端“网络侧已同步新会话”，终端收到后停止发送RekeyInd，激活确认流程结束。
3. OTAA关键维护机制：Rejoin-request（规范6.2.4）

终端激活后，若会话丢失、漫游或密钥需更新，通过Rejoin-request维持连接，共3种类型：

3.1 Rejoin-request类型与用途
类型核心字段用途传输规则
0NetID + DevEUI重置终端上下文（信道、密钥、计数器），支持漫游切换网络占空比≤0.1%，RJcount0计数器递增
1JoinEUI + DevEUI恢复网络侧丢失的会话状态占空比≤0.01%，RJcount1计数器递增
2NetID + DevEUI仅更新密钥/DevAddr，保留信道参数仅响应ForceRejoinReq命令触发
3.2 Rejoin流程
  1. 终端发送Rejoin-request（含对应类型字段与RJcount计数器）；
  2. 网络侧验证MIC与RJcount（需递增），通过则下发Join-accept；
  3. 终端重复“密钥派生→会话初始化”流程，维持或恢复连接。

（四）、 OTAA 关键机制与安全保障

  1. 重放攻击防护

    • 终端的DevNonce不可重复：终端需本地存储已使用的DevNonce，断电后需保留，避免重复使用导致入网被拒；
    • 服务器校验DevNonce唯一性：同一DevEUI的DevNonce不能重复，防止攻击者重放旧的Join Request。

  2. 密钥隔离性

    • AppKey仅用于入网阶段的密钥推导，不直接参与数据加密；
    • 会话密钥（NwkSKey/AppSKey）为临时密钥，终端可通过重新发起OTAA流程更新密钥，进一步提升安全性。
    • 1.1版本的四层密钥体系，实现网络层与应用层密钥分离，单密钥泄露不影响整体安全；

  3. 接收窗口机制

    • 终端发送Join Request后，会开启两个接收窗口：RX1（1s后）和RX2（2s后），确保高概率接收Join Accept；
    • 若未收到Join Accept，终端会随机延迟一段时间后重发Join Request，避免信道冲突。

  4. 加密传输

    • Join Accept全程加密，会话参数不会明文传输；

  5. 会话密钥临时化

    • 终端可通过重新发起OTAA或Rejoin流程更新会话密钥，降低长期使用风险。

（五）、 LoRaWAN 1.0 OTAA 与 1.1 版本的差异

对比项LoRaWAN 1.0.xLoRaWAN 1.1
核心标识AppEUI（64bit）替换为JoinEUI（64bit），适配漫游场景
加密模式Join Accept采用AES-ECB加密采用AES-CTR加密，安全性更高
密钥体系两层密钥（NwkSKey/AppSKey）四层密钥（AppKey/NwkKey/SNwkSKey/AppSKey）
服务器架构NS/AS合设，无独立JS新增Join Server，JS/NS/AS三层分离
路由逻辑无，直接由NS鉴权由JoinEUI路由至对应JS
漫游支持不支持原生支持跨运营商/跨区域漫游
重入网机制无，需重新走完整OTAA支持Type 0/1/2 Rejoin，快速恢复会话

（六）、 部署与调试注意事项

  1. 信道匹配：终端需使用网络侧定义的Join信道发送Join Request，否则网关无法接收；
  2. 速率适配：RX1的下行速率需与上行速率对应（如上行SF10 → 下行SF11），RX2为固定速率，需与服务器配置一致；
  3. DevNonce管理：终端需实现DevNonce的非易失性存储（如写入Flash），避免掉电后重复；
  4. 加密算法合规：严格遵循AES-128-ECB加密规则，禁止自定义加密方式，否则会导致解密失败。
# 物联网 # 网络协议 # 网络安全
Logo
魔乐社区

魔乐社区（Modelers.cn) 是一个中立、公益的人工智能社区，提供人工智能工具、模型、数据的托管、展示与应用协同服务，为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作，由全产业链共同建设、共同运营、共同享有，推动国产AI生态繁荣发展。

更多推荐

小参数・大码力・易部署 | Qwen3.6-27B上线魔乐社区，基于昇腾的部署教程来了

继一周前模型开源发布后，千问再度开源Qwen3.6-27B —— 一个拥有270亿参数的稠密多模态模型，也是社区呼声最高的模型规格。Qwen3.6-27B 依然支持多模态思考与非思考模式，在智能体编程方面达到了旗舰级表现，全面超越前代开源旗舰 Qwen3.5-397B-A17B（总参数397B / 激活参数17B的MoE模型）。作为稠密架构，它无需MoE路由即可部署，是开发者在实用、可广泛部署规模

avatar 魔乐社区
cover

量化挑战赛冠军专访：4小时啃下W4A8量化，我靠的是这些经验

avatar 魔乐社区
cover

替你试过了，消费级显卡可以跑的开源文生图SOTA模型，顶级渲染、高密度文本绘图

avatar 魔乐社区