LoRaWAN
LoRaWAN 网络架构
LoRaWAN 网络由三个基本网络元素组成：
- 设备。
- 基站。
- 网络服务器。
基站的工作是将 LoRa 与其覆盖区域中的设备对话。真正的网络控制在于云，换句话说，就是网络服务器。
您可以将 LoRaWAN 视为具有虚拟化网络层的网络。设备使用 LoRaWAN 协议与网络服务器通信并建立 LoRaWAN 网络。如果多个基站正在监听您的设备，则所有基站都会将您的数据包转发到网络服务器，这意味着 LoRaWAN 设备未本地化到某个单元。
图 1：通用网络架构
通常，网络拓扑看起来像是单跳星型网络。然而，可能存在这样的情况：在作为基站和设备之间的中间人的无线电路径中涉及中继器。目前的标准规范不允许有多个中继器。
LoRaWAN 标准规格
LoRa 联盟负责标准化 LoRaWAN 协议。已经有两个主要的官方发布的标准规范和一些修复版本：
- LoRaWAN 规范 v1.0.X。
- LoRaWAN 规范 v1.1。
规范 v1.0 和 v1.0.X 有一些差异。最新的规范 v1.1 在网络控制如何表达方面有很大不同。v1.1 中的一些显着特性是改进的安全原语和对漫游的支持。所有规格都向后兼容。区域参数规范解决了与世界各地无线电规则有关的区域限制，增加了这些标准文件。
LoRaWAN 设备类
LoRaWAN 规范定义了三种不同类型的设备类：
- A 类。
- B 类。
- C 类。
LoRaWAN 设备始终作为 A 类设备启动。如果需要，它可以稍后切换到另一个类。但是，B 类和 C 类是互斥的。
A 类
A 类是必需的设备类。所有 LoRaWAN 设备必须实现 A 类。该类包括电池供电的传感器和执行器，没有延迟限制。这是最节能的通信类。
在 A 类中，设备始终启动通信周期。当设备发送数据报时，它会在特定延迟后打开两个接收窗口。这些延迟的时间和接收窗口本身的长度受到区域限制。然而，传输是需要的。但是，它是根据类似 Aloha 机制之后的占空比限制来安排或传输的。
图 2：A 类时序图
B 类
B 类设备允许在预定时间接收插槽。为此，基站发出时间同步信标。这确保了在此特定时间，接收器或设备正在收听。B 类设备适用于延迟受限设备，并且设备使用与网络信标同步的时隙通信。
基站每 128 秒发送一个信标，并且所有 B 类节点在 128 秒周期内被分配一个时隙，并被告知何时收听。
图 3：B 类时序图
信标保护时间在每个信标之前，并且在该时间段内不能放置 ping 时隙。ping 插槽是一个 30ms 的单元，您可以将其分配给 B 类设备。信标保留是发送实际信标的时间段。信标窗口是您可以打开并分配 ping 插槽的时间段。
- 信标周期 = 128 秒。
- 保留信标 = 2.120 秒。
- 信标卫士 = 3 秒。
- 信标窗口 = 122.880 秒。
总的来说，信标窗口中可以有 4,096 个 30ms 的 ping 槽。
注意: Mbed LoRaWAN 栈目前不支持 B 类。
C 类
C 类设备主电源或具有足够的电源供应。这些设备在不发送时往往保持监听模式。
C 类设备尽可能经常在 RX2 窗口监听。在打开 RX1 窗口之前，这些设备需要在传输之后立即打开 RX2 窗口。换句话说，您可以使用 RECV_DELAY1 时间来侦听 RX2。在 RX1 窗口结束时，设备打开一个连续的 RX2 窗口，直到发生另一次传输。
图 4：C 类时序图
LoRaWAN 连接类型
LoRaWAN 规范定义了两种连接到接入网络的方法。
- 空中激活（OTAA）。
- 通过个性化激活（ABP）。
空中激活（OTAA）
OTAA 包括设备和网络服务器之间的 MAC 消息交换。设备向网络服务器发送 JOIN REQUEST，其中包含应用程序 EUI，设备 EUI 和设备随机数（随机值）。设备 EUI 类似于 MAC 地址，并且唯一地标识网络中的设备。应用程序 EUI 是网络服务器分配给设备的应用程序标识符（带外方式）。JOIN REQUEST 以未加密的形式发送到网络服务器。作为响应，网络服务器向设备发送 JOIN ACCEPT 消息，该消息通过使用另一个密钥（app 密钥）加密，该密钥是网络提供商提供给设备（带外），就像 app EUI 一样。然后，设备使用此应用密钥，app nonce（随机值或网络提供商的唯一值），网络 ID 和设备随机数（另一个随机值）来本地计算网络会话密钥和应用会话密钥。
个性化激活（ABP）
个性化设备具有存储在 NVRAM 中的安全密钥（优选地是安全元件），并且这些密钥在制造时被烧制到设备。
使用 ABP 配置的设备被认为是连接设备，因为它们不需要与网络协商并且可以立即与网络通信。存储在设备中的实体由设备地址和两个会话密钥（网络会话密钥和应用会话密钥）组成。
LoRaWAN 数据消息类型
您可以使用 LoRaWAN 协议发送两种类型的数据消息：
- 未经证实的消息（火灾和遗忘类型的数据报）。
- 来自另一端的确认消息（需要确认）。
对于已确认的消息，外出到网络或由设备发送，网络服务器在设备打开的两个 RX 窗口内发送确认。如果没有收到确认，则设备等待等于给定确认超时的时间段然后重试。
Arm Mbed LoRaWAN 栈
Arm Mbed OS 装载了一个小型，安全，线程安全的 LoRaWAN 栈（遵循 LoRaWAN 规范的 v1.0.2），具有庞大的开发人员基础。
设计架构
栈按逻辑顺序分层，并且具有高度可配置性。它目前支持 LoRaWAN 设备的 A 类和 C 类。
图 5：Mbed LoRaWAN 栈类层次结构
Arm Mbed LoRaWAN 解决方案包含四个设计组件，丰富了应用程序以及作为 LoRaWAN 设备运行的所有必要工具：
- Mbed LoRa 无线电驱动程序：由应用程序构建并传递给栈。
- Mbed LoRaWAN 栈，MAC 控制器层：控制栈的操作。
- Mbed LoRaWAN 栈，PHY 层：计算并提供用于 MAC 控制器层处理的区域 PHY 参数。
- 应用程序和栈之间共享的 EventQueue 用于同步。应用程序需要构造一个 EventQueue 对象并将其传递给栈。
Mbed LoRa 无线电驱动器
Mbed LoRa 无线电驱动程序位于 Mbed OS 树之外。Arm 支持 SX1272 和 SX1276 LoRa 无线电，这是最广泛使用的 LoRa 终端设备无线电芯片组。
Arm Mbed OS 包含一个纯虚拟类 LoRaRadio，您可以使用它来继承并提供 Mbed LoRa 无线电驱动程序，以补充 Mbed 应用程序和 Mbed LoRaWAN 栈。您可以在 LoRaRadio API 参考中找到对 LoRaRadio 类的完整参考。
LoRa 无线电驱动程序支持 RTOS 和非 RTOS 环境。对于 RTOS 环境，驱动程序使用线程和信令机制推迟中断以进行延迟处理。对于非 RTOS 环境，驱动程序共享用户线程。第三方驱动程序是 LoRaRadio 类的实现，可以使用 Mbed OS 提供的任何同步方法，并且可以在内部使用任何传输进行寄存器访问。最重要的先决条件是：
- LoRaRadio 概述的公共 API 的可用性。
- 从 MAC 控制器层获取 radio_events_t。
radio_events_t 是一组 Mbed 回调，指向 MAC 控制器层中的方法来处理无线电生成的中断。当应用程序构造一个 LoRaRadio 对象并将其传递给栈时，MAC 控制器层将 radio_events_t 与相应的中断处理器绑定。无线电驱动程序需要接受 radio_events_t 并为特定中断调用适当的回调。
示例：构造 LoRaRadio 对象
应用程序构造 LoRaRadio 对象并将其传递给栈：
SX1272_LoRaRadio radio(PIN_NAMES,...);
LoRaWANInterface lorawan(radio);
示例：radio_events_t 的内部处理
栈在 radio_events_t 结构中设置回调，并将这些回调提供给无线电驱动程序：
// setting up callbakcs in radio_events_t
radio_events.tx_done = mbed::callback(this, &LoRaWANStack::tx_interrupt_handler);
radio_events.rx_done = mbed::callback(this, &LoRaWANStack::rx_interrupt_handler);
radio_events.rx_error = mbed::callback(this, &LoRaWANStack::rx_error_interrupt_handler);
radio_events.tx_timeout = mbed::callback(this, &LoRaWANStack::tx_timeout_interrupt_handler);
radio_events.rx_timeout = mbed::callback(this, &LoRaWANStack::rx_timeout_interrupt_handler);
_loramac.bind_radio_driver(radio);
radio.lock();
// actual initialization of the radio driver with the radio_events_t
radio.init_radio(&radio_events);
radio.unlock();
示例：无线电生成中断
无线电驱动程序使用以 radio_events_t 格式接收的回调来通知上层后处理中断。
if (signal & GENERATE_TX_DONE) {
radio_events->tx_done();
}
Mbed LoRaWAN 栈：MAC 控制器层
MAC 控制器层由各种较小的单元组成。每个单元执行特定任务。
LoRaWANStack 类
LoRaWANStack 类是监督单元。它运行栈的状态机。一方面，它为 LoRaWANInterface 提供了一个粘合层，后者又为应用程序提供了一个网络接口。另一方面，它控制着系统的其他单位之间的分工。该类负责处理无线电驱动程序生成的中断，管理状态并将应用程序请求的作业委派给下一个较低的单元，换句话说，LoRaMac 类。
LoRaMac 类
LoRaMac 类构成核心 MAC 功能。它执行 LoRaWANStack 委派的操作，并为各种 MAC 指示或需要进一步后处理的确认提升适当的标志。此类也可用于使用 LoRaWANTimer 跟踪计时器，使用 LoRaMacCrypto 执行加密操作，使用 LoRaMacCommand 处理 MAC 命令以及使用 LoRaMacChannelPlan 类处理通道计划。总的来说，LoRaMac 类使用较小的单元处理作业，并提供对LoRaWANStack 上执行的操作的指示或确认。
虽然 LoRaWANStack 处理中断，但 PHY 层（LoRaPHY）的实际控制权在于 LoRaMac。它使用 TX 数据路径上的 LoRaPHY 类对物理无线电进行编码和写入，并在 RX 数据路径上进行解码。
LoRaWANTimer 类
此类保留栈的时基。为简单起见，它从 EventQueue 中提取系统时基。
LoRaMacCrypto 类
您可以使用 LoRaMacCrypto 类使用 Mbed TLS 对 LoRaWAN 数据包进行编码和解码。
LoRaMacCommand 类
您可以使用 LoRaMacCommand 类处理来自网络的传入 MAC 命令，并为传出消息中的 MAC 命令生成适当的响应。
LoRaMacChannelPlan 类
您可以使用 LoRaMacChannelPlan 类来促进给定 LoRaPHY 的通道规划。
Mbed LoRaWAN 栈：PHY 层
该栈具有一个抽象类 LoRaPHY，它为上层提供 PHY 层 API。图 5 显示了 LoRaPHY 类的 10 个实现，根据 LoRaWAN 区域参数规范（LoRaWAN 规范 v1.0.2 的补充文档）中提供的定义。
LoRaPHY 的实现在结构中声明这些参数，然后 API 用于计算上层的各种系统参数。如果需要，他们可以覆盖 LoRaPHY 提供的方法；否则，使用 LoRaPHY 中提供的实现。
目前，在运行时不可能更改 PHY。在使用 Mbed 配置系统编译应用程序之前，必须选择 PHY 层：
"target_overrides": {
"*": {
"lora.phy": {
"help": "LoRa PHY region: EU868, AS923, AU915, CN470, CN779, EU433, IN865, KR920, US915, US915_HYBRID",
"value": "EU868"
}
}
}
EventQueue
Arm Mbed LoRaWAN 栈是事件驱动的。为了降低整个系统的复杂性，它使用了应用程序传递给栈的 EventQueue。两者都共享此事件队列。这可确保栈和应用程序在相同的上下文中运行。
应用程序发送某些事件以响应各种网络级别的操作。有关这些事件的详细讨论，请访问 LoRaWAN 事件文档。
连接程序
本节讨论与网络连接范例相关的 Mbed LoRaWAN 栈中的流和相应的状态更改。有关连接过程的详细 API 参考，请访问 LoRaWANInterface API 文档。查找 connect() 或 connect(lorawan_connect_t) API。
图 6：连接范例流程
一旦激活完成，Arm Mbed LoRaWAN 栈就会向应用程序发送 CONNECTED 事件。如果栈未收到 JOIN ACCEPT 消息，则在将 JOIN_FAILURE 事件发送到应用程序之前，堆栈将重试特定次数。
发送消息
有关传出消息的详细 API 参考，请访问 LoRaWANInterface API 文档。寻找 send() API。例如：
/**send an Unconfirmed message*/
lorawan.send(port, data, length, MSG_UNCONFIRMED_FLAG);
发送未经证实或已确认的消息的流程如下所示：
图 7：未确认的消息流
图 8：确认的消息流
对于未确认的消息，当发生传输并且两个 RX 窗口时隙都已过去时，栈会向应用程序发送 TX_DONE 事件（在传输之后的 C 类中，因为在 C 类中从未经过 RX2）。
对于已确认的消息，栈在收到 ack 时向应用程序发送 TX_DONE 事件。如果它没有收到确认，则栈会自动重试给定次数，并在必要时调整数据速率。
如果 TX 数据路径出错，则生成 TX_TIMEOUT 或 TX_FALURE 事件。
接收消息
有关传出消息的详细 API 参考，请访问 LoRaWANInterface API 文档。寻找 receive() API。
栈中有两种类型的 receive() 方法。第一个类似 POSIX，您需要告诉您希望接收的端口（而不是 Posix 格式的套接字 ID）：
/**this means receive any confirmed or unconfirmed message at port my_port*/
lorawan.receive(my_port, buffer, length, MSG_UNCONFIRMED|MSG_CONFIRMED_FLAG);
// OR
/** Port and flags are given out*/
lorawan.receive(data, length, port_out, flags_out);
Receive APIs return LORAWAN_STATUS_WOULD_BLOCK if there is nothing to read. The RX_DONE event informs the application when the stack receives something for the application. In response to this event, the application can choose to use any of the receive methods given above to retrieve received data.
The flow for reception looks like this:
图 9：接收消息流
自动处理待处理数据和 MAC 命令
默认情况下，如果网络服务器端的任何数据等待传递到设备，或者有任何需要立即上行链路的 MAC 命令响应，则栈会自动处理该情况。
- 当由网络服务器发送的上一个下行链路消息中设置的 fPending 位指示的未决数据时，如果没有另外配置，则堆栈将自动生成空的外发消息。在这种情况下，应用程序不会收到 TX_DONE。应用程序可以根据未决数据的接收来接收后续的 RX_DONE 事件。
- 如果 MAC 命令需要立即响应，则栈会自动生成空上行链路（如果未另行配置）。TX_DONE 事件被抑制，因为它是自动上行链路。
在进行自动上行链路事务时，如果尝试执行数据上行链路，则会收到 LORAWAN_STATUS_WOULD_BLOCK 错误消息。
应用程序可以修改此行为，并选择不关闭此功能来发送自动上行链路。例如：
"lora.automatic-uplink-message": {
"help": "Stack will automatically send an uplink message when lora server requires immediate response",
"value": false
}