System Information Department Technology Stack

author：廖宝众

createTime：2022-04-09

updateTime：2022-04-14

2022-04-14:培训结束

# LoRa和LoRaWAN的区别

# LoRa

LoRa 是物理层的一种无线射频技术，实现原理由Semtech公司内部私有，具有专利保护。

虽然大家习惯使用LoRa这个简称来描述涉及LoRa相关的设备、网关、系统和平台，但是严谨地说，LoRa仅指代这种物理层技术。

# LoRaWAN

LoRaWAN 是基于LoRa这种无线射频技术而设计的一个MAC层协议。

不同于LoRa这种商业私有协议专利保护的技术，LoRaWAN是由LoRa联盟组织定义的一套开放式的协议，只要加入联盟就可以参与讨论和制定LoRaWAN。

# 区别和联系

在绝大部分情况下，LoRa和LoRaWAN是整合的，LoRa是LoRaWAN的底层支持，LoRaWAN是LoRa的上层设计。但这并不是严格要求，LoRaWAN的底层支持也可以是其他物理层协议，比如G/FSK，LoRa的上层设计也可以不是LoRaWAN，比如Symphony Link。

# LoRa/LoRaWAN的优点和缺点

# 技术层面

  • 优点：传输距离远、功耗低、抗干扰能力强
    • 在理论情况下，使用单个LoRa节点的信号传输距离在几公里到十几公里，甚至国外有公司实验了使用普通LoRa模块从卫星到地球的LoRa数据通信。现场环境复杂、干扰信号多、遮挡物多、天线质量较差等因素均会影响实际效果
    • 在理论情况下，单颗5号电池最长能够使用几年而不更换。通讯频率、载荷大小、使用环境等因素均会影响功耗和电池寿命
    • 在理论情况下，低于地板值20dB的信号，也能够被LoRa设备接收到。而在大部分无线通讯技术中，信号要求必须高于地板值才能被接收。
  • 缺点：
    • 带宽窄，单位时间内能够传输的数据量较少。主要是受限于开窗机制、帧编码机制、网关信道少等因素影响
    • 半双工。传统的LoRa网关不能同时上下行消息，这个缺点也能够通过安装多个模块解决，而且最新的模块据说原生支持全双工。

# 市场层面

  • 优点：技术较新，历史包袱较少，减少了从业者的研发投入，有利于一些公司实现弯道超车，而且使用的是非授权频段，无需许可证和费用即可使用，而且可根据应用需求灵活搭建各种小型、大型、以及层级的私有网络
  • 缺点：市场的不确定性，由于全球范围内没有一个具有显著代表性的商务应用作为借鉴，这方面的前景还需要各从业者不断探索

# LoRa相关的生态环境

2015年3月，Semtech为促进其他公司共同参与到LoRa生态中，于2015年3月联合Actility、Cisco和IBM等多家厂商共同发起创立LoRa联盟，经过5年的发展，目前在全球拥有超过500个会员。中国市场是LoRa全球生态建设中非常重要的部分。2018年，阿里巴巴、腾讯、京东等互联网巨头均以最高级别会员身份加入LoRa联盟，同时中兴克拉科技、各地方广电、浙江联通、联通物联网公司等LoRa生态伙伴也在各地积极部署LoRa网络。可见，LoRa在中国已经形成了融合运营商（中国联通、中国铁塔等）、互联网巨头（阿里、腾讯、京东等），以及解决方案商、模块提供商和网关制造商的庞大生态体系。国内LoRa产业链企业数量已超过1500家，且以每年50%的增速发展。 罗万目前也是LoRa联盟的一员，且曾经出现在2020年的年度汇报上。

# LoRa的相关知识

由于LoRa是个私有协议，我们仅介绍几个我们普遍关注的点：

  • 信号 RSSI。信号值一般为负值，越接近0表示信号越强。

  • 信噪比 SNR。信噪比一般为负十几到正几十，值越大表示信号越好。

  • 数率 DR。数率一般为0~7的索引值，值越大表示数率越高，和SF是负相关的关系。

  • 扩频因子 SF。扩频因子一般为7~12的值，值越大表示抗干扰能力越强，同时每帧能传输的有效数据量越少，和DR是负相关的关系。

  • 频点 Frequency。频点值为设备将数据帧发出时使用的频率值，是频段中的某个具体的值。

  • 频段 Band。也就是频率值区间，比如从863MHz-870MHz。依据分配规划和法律法规，每个地区所能使用的频段不一样，比如863MHz-870MHz可以使用在欧洲和非洲某些地区。

  • CN470。CN470是目前在中国主要使用的频段，经历过几个版本，后期的版本相对于早期版本有非常大的变化，以至于不能够相互兼容和迭代。

    • 早期版本（1.0、1.0.1、1.0.2、1.0.3） 上行频道有96个，470.3MHz-489.3MHz，下行频道有48个，500.3MHz-509.7MHz。上行时，在96个频点中随机跳频发送，下行rx1频点根据上行频点对48取模，下行rx2默认频点固定。
    • 新版本（1.0.4、1.1） 主要区别在于频道分成了20MHz TypeA、20MHz TypeB、26MHz TypeB、26MHz TypeB这4个频点计划，节点不再从96个频点中随机跳频，而是从出厂时已经划分好了使用哪个频点计划，并且只能够在这个计划内跳频。按照规范要求，2021年11月就需要开始使用这种频道规划。

  • 最大载荷（以1.0.2 CN470为例）

    SF 最大应用载荷字节数
    12 51
    11 51
    10 51
    9 115
    8 222
    7 222

# LoRaWAN的相关知识

LoRaWAN的内容较多，我们先列举几个我们普遍关注的点：

  • Class A/B/C。 针对不同的应用场景，LoRaWAN定义了三种节点运行模式，分别是Class A（ALL）、Class B（Beacon）、Class C（Continuously Listening）。 三种网络模式中，Class A是所有LoRa网络都必须支持的模式，也是最常用的网络模式。这三个模式设计并不复杂，其实就是在网络灵活性、可用性和节能之间的一个平衡。Class A最节能，但是灵活性相对较低，例如下行数据只能依赖于上行数据的时间。Class C最耗电，但是也是上行和下行数据发送最灵活的。
    • Class A模式主要提供低功耗上行连接，处于Class A模式的节点可以在任意时间发起上行传输，并只在传输结束时打开两个下行接收窗口，此时接收来自网关ACK。Class A模式下，网关无法主动连接到节点，当无数据传输时，节点处于休眠状态，因此该模式下节点能耗最低。
    • Class B模式提供节点与网关的周期性连接，该模式下网关节点周期性向节点广播信标帧，保持节点与网关的时间同步。
    • Class C模式提供节点与网关的持续性连接，该模式下节点始终处于唤醒状态，因此能耗最高。
  • DevEUI。由于IEEE授权分配的设备全球唯一标识。
  • DevAddr。每个设备入网成功后，给该设备分配的一个会话地址。
  • FCnt。MAC层每个消息都包含的一个计数器字段。上行和下行消息各有一个，每次消息成功的上行或者下行后，都会在下一次消息上行或下行中将其加1。
  • Slot。表示网关的LoRa模块的插槽索引值。0表示第一个插槽，1表示第二个。GWMP协议里的字段。
  • Channel。表示某个接收频点在LoRa模块接收频点组里的索引值。LoRaWAN将某个频段里面所有频点进行分组，比如每16个为一组。而每个模块接收8个，16个频点需要2个模块接收，那么就有slot0-channel0、slot0-channel1、...、slot0-channel7、slot1-channel0、slot1-channel1、...、slot1-channel7这16个组合。
  • time。表示网关接收的消息的UTC时间。
  • tmms。表示网关接收的消息的GPS时间。
  • tmst。表示网关接收完消息时的一个网关内部时间戳。
  • NetID。表示一个LoRaWAN网络的唯一标识。理论上这个ID应该向联盟申请分配，方便管理，但是我们公司目前还没有，使用的是自定义的值。

# 协议文档

  • 目前LoRaWAN 规范经历了有1.0、1.0.1、1.0.2、1.0.3、1.0.4、1.1这6个版本
  • 配套的区域参数规范有1.0、1.0.2、1.0.3、2-1.0.0、2-1.0.1、201.0.2、1.1ra、1.1rb这8个版本
  • 多播组规范用于对多播的管理和控制，只有1.0.0版本，2.0.0版本目前还在候选阶段
  • 分段数据块传输规范用于管理、控制分块的数据传输，目前只有1.0.0版本
  • 应用层时钟同步规范用于校准设备时间，只有1.0.0版本
  • 固件管理规范用于管理设备的固件包，目前还在候选阶段
  • 多包接入规范用于查询设备实现的应用层协议以及协议包格式，目前还在候选阶段
  • GWMP协议文档用于规范网关和服务之间的消息交互格式，目前只有1个版本
  • DLMS over LoRaWAN用于实现在LoRaWAN通讯层基础上传输DLMS消息，目前有1个版本
  • SCHC描述了在LoRaWAN的分包协议，目前有1个版本共2个文档

# 主规范的改动

# Revision 1.0

  • Lorawan1.0版本提出

# Revision 1.0.1

  • 明确了Rx窗口的起始时间的定义
  • 在NA字段处为DR2矫正了最大载荷大小
  • 7.2.2章节矫正了下行数据速率范围的印刷问题
  • 7.2.2章节介绍了使用编码率4/5的必要性来保证最大空中时间<400ms
  • 6.2.5章节矫正了关于JoinAccept的MIC计算
  • 5.2章节明确了NBRep字段而且把它重命名为NBTrans
  • 移除了在MAC层不加密应用层载荷的可能性移除了4.3.3.2图表。如果未来应用层有安全性的必要，那么在应用层载荷将会可使用任意方法被加密，然后在MAC层使用指定的默认的lorawan加密机制重加密
  • 矫正了FHDR的字段大小的印刷问题
  • 7.2.5章节矫正了当ChMaskCntl等于6、7时影响的频点
  • 明确了6.2.5章节描述JoinResp帧的RX1 slot 数率的语句
  • 7.2.7章节移除DRoffset表的后半部分，因为显然DR>4从来不会被上行使用
  • 7.1章节移除了EU868Mhz频段显式的duty cycle限制的实现
  • 5.4和5.7章节使RXtimingSetupAns和RXParamSetupAns变成粘性的MAC指令，避免设备的隐藏状态问题
  • 为中国470-510MHz metering band增加了频率计划
  • 为澳洲915-928MHz ISM band增加了频率计划

# Revision 1.0.2

  • 抽取出第7章物理层描述，现在它将会被独立成为lorawan地区物理层定义文档
  • 矫正ADR backoff(补偿)序列描述图表4.3.1.1(ADR_ACK_LIMIT替代了ADR_ACK_DELAY)
  • 矫正了18.2章节的标题格式问题，之前是在1.0.1的19.2章节
  • 增加了DLChannelReq MAC指令，这个指令用来修改设备预期下行帧的频率
  • 增加了TXParamSetupReq MAC指令，这个指令用来远程修改某些区域的设备的最大TX dwell time和最大的无线发射功耗
  • 5.2章节增加了设备在一个block中处理多个ADRReq指令的可能性
  • 明确了AppKey的定义

# Revision 1.0.3

  • 为lorawan 1.1规范引入了Class B章节
  • 在Class A章节增加了DeviceTimeReq/Ans MAC指令，这些指令对于Class B的信号获取来说是必要的，BeaconTimingReq/Ans被遗弃了
  • 矫正了错误的GPS纪元引用
  • 矫正了各种印刷错误

# Revision 1.0.4

  • 语法规范化的整理
  • 增加BCP 14的说明
  • 用JoinEUI替代AppEUI，JoinNonce替代AppNonce
  • 明确Class B和Class C操作模式作为Class A的附加
  • 明确Class A的Rx窗口的打开条件
  • RP002作为附件
  • 物理层数据包定义为Packets，正如[RP002]中定义的一样
  • MAC层数据包定义为Frames
  • 明确对超过最大帧长的帧的处理
  • 明确FPending
  • 移除MAX_FCNT_GAP
  • 明确FCnt的用法和行为
  • FCnt一直是32位，而且必须被ABP设备持久化
  • 大于224的Fort不会被丢弃
  • 使用Frame来称呼MAC层数据包
  • 帧类型名(比如unconfirmed data uplink) 的编辑一致性
  • Join-Request和Join-Accept的编辑一致性
  • 明确空帧也是有效的
  • 明确ADR行为
  • 改善了ADR Backoff(补偿)例子
  • 在FCtrl字段定义了Class B位（而不是只在Class B字段）
  • MAC指令处理和粘性MAC指令总览（包含优先级和回应）
  • 最大、最小和不变LinkADRReq的TXPower
  • 额外的ADR明确
  • 明确LinkCheckAns和定义RadioStatus字段作为SNR
  • 明确MAC指令的强制性
  • 明确NewChannelReq/DLChannelReq的非必要性，对于固定频点计划的区域
  • 要求DevNonce一直增加
  • 为后端实现增加对齐DevAddr AddrPrefix的定义
  • 要求所有的设备拥有一个关联的DevEUI，即使是ABP设备
  • 明确在考虑其他配置值时CFList的处理
  • Class C设备在网络给它发下行之前必须成功上行一次
  • 明确重发补偿
  • 默认的Ping slot和频率参考于[RP002]
  • 要求至少对一个多播组的支持
  • 定义了Class B的单播和多播的下行中FPending的解释
  • 定义了PingSlotInfoAns
  • 为SF8到SF12定义了Beacon帧格式
  • Beacon传输随机化为了松散同步的网关
  • 增加一个时间精度字段Prec给Beacon，用来描述源网关的精确度，同时添加了对它的用法描述
  • 定义了Lat/Lng字段给beacon的GPS协同字段
  • 明确了下行路由更新条件在cell change
  • 明确了在Class C下行至上的Class A下行优先级
  • 明确了单播和组播的RXC参数和逻辑模型
  • 更新了所有的有信息量的例子
  • 从服务下发的MAC指令只能被发送在Class A的downlink。注意常规的上行传输是被预期的在Class B和C
  • 增加了一个最小功耗控制范围
  • 对于Class B和Class C确认下行帧，ACK不应该在一个超时时间后再次出现
  • 强制duty cycle限制在每一个带Toff的上行帧
  • 修改了PingSlotChannelReq回应机制（在所有上行帧上重复，直到下一个Class A的下行帧，f.k.a sticky answer）
  • 确认过Class A的下行之后，NS在发送一个ClassB或者ClassC的确认下行帧之前应该等待一个上行帧
  • 建议发送RxParamSetupAns（ClassC启用）和PingSlotChannelAns越快越好

# Mac指令

由于LoRaWAN是MAC层的协议，对于调用者（应用层）而言，LoRaWAN仅暴露载荷给外部，而大部分通讯协议都有自己内部的一套自我调节协议，在LoRaWAN协议中，这部分叫做Mac指令，用于调节通讯表现，这部分对应用是透明的、无感知的。 比如1.0.2有如下10种指令：

  • LinkCheckReq Used by an end-device to validate its connectivity to a network.
  • LinkCheckAns Answer to LinkCheckReq command. Contains the received signal power estimation indicating to the end-device the quality of reception (link margin).
  • LinkADRReq Requests the end-device to change data rate, transmit power, repetition rate or channel.
  • LinkADRAns Acknowledges the LinkRateReq.
  • DutyCycleReq Sets the maximum aggregated transmit duty-cycle of a device
  • DutyCycleAns Acknowledges a DutyCycleReq command
  • RXParamSetupReq Sets the reception slots parameters
  • RXParamSetupAns Acknowledges a RXSetupReq command
  • DevStatusReq Requests the status of the end-device
  • DevStatusAns Returns the status of the end-device, namely its battery level and its demodulation margin
  • NewChannelReq Creates or modifies the definition of a radio channel
  • NewChannelAns Acknowledges a NewChannelReq command
  • RXTimingSetupReq Sets the timing of the of the reception slots
  • RXTimingSetupAns Acknowledges RXTimingSetupReq command
  • TxParamSetupReq Used by the network server to set the maximum allowed dwell time and Max EIRP of end-device, based on local regulations
  • TxParamSetupAns Acknowledges TxParamSetupReq command
  • DlChannelReq Modifies the definition of a downlink RX1 radio channel by shifting the downlink frequency from the uplink frequencies (i.e. creating an asymmetric channel)
  • DlChannelAns Acknowledges DlChannelReq command

# 实现架构

我们这里引用官方的一个架构图来展示LoRaWAN网络各部件的关系，同时列举一些注意事项。 img

  • 一个上行消息能够被多个网关接收到，意味着服务器能够收到多份一样的消息
  • 一个下行消息只能被一个网关接收到，意味着服务器需要有一套逻辑来选择下发的网关，如果选择错误，那么很有可能会造成消息丢失，而且占用了空中时间占用了可用信道
  • 由于信道数量的局限性，终端节点的设计中应该避免大量设备同时发送数据，造成相互干扰，应该把数据发送的时间点和信道都随机离散开
  • 由于LoRa数率的限制和网关硬件本身的结构限制，应该尽可能的减少下行消息发送的量和频次，否则会造成丢包

# 网关实现

在传统意义上而言，网关的功能是两种不同网络之间的一个桥梁，放在LoRaWAN领域也是如此。LoRa网关将收到的LoRa射频信号数据发送给以太网。 目前我们的网关使用的单个LoRa模块支持8个上行信道，1个下行信道，但在使用时要注意半双工的特性。

# 部署和使用流程

  1. 核心网部署 核心网部署时，需要注意配置各种网络参数，会话相关的参数
  2. 网关部署 网关部署时，需要注意网关的8个上行信道频点配置
  3. 节点部署 节点部署时，需要注意触发节点入网，因为有些节点并非重新上电后就立刻重新请求入网
  4. 下行消息 下行消息前，按照一般要求，需要等待节点发送一个上行消息后，才能将下行消息发送给节点

← LoRa与LoRaWAN理论基础 →