LoRaWAN学习笔记2.1—LoRaWAN协议

LoRaWAN学习笔记2.1—LoRaWAN协议

       --樊渝江

      升特官方在2017年11月推出了LoRaWAN-Specification-v1.1，新协议在架构上有些变化，但大体没有变。等1.1推出一段时间后我会针对新协议修改一些服务器程序。

      言归正传，目前大家都还是使用的老版本协议LoRaWAN-Specification-v1.0.2版本，你能买到的并且支持LoRaWAN标准的产品，都是基于这个版本开发的，所以我们以此版本开始分析。这个版本熟悉了再去看1.1版本也不是什么难事，如果有那就是英语问题。

      在开始看的时候希望大家能先阅读一下《LoRaWAN-Specification-v1.0.2》，也有英语大神翻译的缩减版，名字叫《LoRa规范CLASS-A》，如果看英语困难就去看中文版本的吧，翻译的挺好。《LoRa规范CLASS-A》 下载 地址

      现在就让我们来见识见识这个协议。

      LoRaWAN的定义我在上一个笔记里已经讲过了，如果还不理解的话就翻翻上一篇，或者百度一下。现在我们直接开始干货。

LoRaWAN将终端通信模式分为了三类，分别为CLASSA,CLASS B,CLASS C。

      ClASS A：双向终端设备，通过在终端设备上行链路传输后开放两个下行链路窗口，使Class A 的设备可以双向通信。传输时隙由终端设备决定，该传输时隙基于其自身的通信需求，在随机时间基准（ALOHA型协议，全随机，当两个包频率相同，发射时间相同，1301会接收信号强度强的那个包，这是我实测过得。）上进行小变动。由于应用层只在终端设备上行链接传输后较短的时间内需要来自服务器的下行链路通信，因此 CLASS A 模式的设备是功耗最低的终端设备系统。服务器在其他任意时刻的下行链路都需要等待直到下一个确定的上行链路。服务器不能主动向终端发数据，必须等到终端上发了数据后才能给他下发数据。

 

      CLASS B：具有确定接收时隙的双向终端设备，CLASS B 设备考虑了更多接收时隙。除 CLASS A 的随机接收窗口外，CLASS B 设备会在确定的时间内打开额外的接收窗口。为保证终端设备在确定的时间内打开接收窗口，终端设备会从网关接收到一个时间同步信标。这使服务器知道终端设备何时在监听。这种方式就是时钟同步方式，能使系统的终端数更多，可惜1.0.2官方提供的源码中，并没有。在1.1协议中有描写Class B，希望源码中含有Class B模式。

     

      CLASS C：具有最大接收时隙的双向终端设备，CLASS C 的终端设备具有接近于连续地开放接收窗口，接收窗口只在传输时关闭。相对于CLASS A 和 CLASS B，CLASS C 终端设备会消耗更多的能量，但是在 CLASS C 模式下，服务器到终端设备通信的延时最短。

简单意思就是一直把接收打开，只有发送时不能接收，其他时间都在接收，对于有线供电且不考虑低功耗的可以考虑这种方式，这种方式服务器可以主动下发数据。

 

      官方要求LoRaWAN设备至少要有CLASS A功能，后面我们就围绕CLASS A讲，CLASS B目前在此版本协议中代码上还不支持，就没有深研究，懂了CLASS A ，CLASS C自然就明白了。

      下面我们就开始讲讲CLASS A的工作方式。

      上下行数据链路消息，上行是终端往服务器发，下行是服务器往终端发。

在CLASS A模式，终端和服务器的通信方式如下：终端发完数据后延时1s（RECEIVE_DELAY1）开启接收窗口1（以下称RX1）,RX1开启1s，如果在1s内RX1没收到数据，开启窗口2（以下称为RX2），接收到了就不需要开启RX2了。看图（图是我截的）：

 RECEIVE_DELAY1（接收延时1）：协议规定是1s（正负20us）,实际操作可以更具项目来调。

 RECEIVE_DELAY2（接收延时2）：协议规定是2s（正负20us）,实际操作可以更具项目来调。

 注：RX1开启时间为1s，RX2开启时间没有具体规定，只说了什么时候开，没说开多久，我设的3s，开久了浪费电。

     

      上行链路消息

 上行链路信息由终端设备通过一个或多个网关传输给网络服务器。下行设备使用LoRa 射频传输包显性模式，模式包括 LoRa 的物理数据头和它的 CRC 校验。有效负荷（PHYPayload）的完整性由 CRC 进行保护。无线收发器将 PHDR, PHDR_CRC 和有效负荷 CRC 字段插入其中。

上行链路 PHY：

 

下行链路信息

 每一个下行链路消息都由网络服务器通过唯一的网关转接传输给一个终端设备。下行消息使用射频数据包显性模式，该模式包括一个物理数据头和 CRC 头。

下行链路 PHY：

      注：下行没有CRC校验，而上行的有，如果是LoRaWAN标准协议包头为0x34，私有协议为0x12。

      我们需要的有用数据就在PHYPayload里,除了包头其他就不管了，硬件知道完成。

我总结了一个excel供大家参考，下载地址：http://download.csdn.net/download/fanyujiang2004/9964880

 此版本有点老，由于其他原因新版本的就没有上传了。

 可以清晰的看见上行通信包的结构，从上往下第一个是终端入网包(OTAA模式用)，第二个是入网成功后服务器下发的确认包（OTAA模式用），第三个是正常通信时的上行包，第四个是正常通信时的下行包。里面有很多名词定义，我们在后续分析包的时候会一一解释，文章的最后我也会写一个单独的表。

MHDR:

      MHDR为一个字节，通过位的组合来表示包的类型。

  MHDR 为0x00 就为入网申请包

                0x20就是入网成功的下行确认包

 通过分析MHDR中的第5位到第7位，就能确定数据包的类型。

 

入网申请包：

 入网包MIC计算方法cmac=aes128_cmac(AppKey,MHDR|AppEUI|DevEUI|DevNonce)
MIC=cmac[0..3]

 

 AppEUI：在 IEEE EUI64 具有全球唯一应用 ID，可以单独识别终端设备的应用服务提供商（等等）。AppEUI 在**程序执行前已储存在终端设备中。

 DevEUI：是全球终端 ID，符合 IEEE EUI64，用来唯一辨识终端设备。

 DevNonce：是个随机值，终端设备最近使用的一些(数量自定义)DevNonce 会保存在网络服务器（NS）。如果终端发送的入网请求中的 DevNonce 在 NS 中可以查到，该请求就会被忽略。取LoRa芯片的RSSI随机值，得到DevNonce。

 AppKey：是AES-128的应用**，**只有应用供应商知晓和掌握，在出厂的时候AppKey已经写在服务器和终端里，这两端储存的AppKey必须相同，要不然无法入网。终端设备通过无线**入网时，通过AppKey衍生会话** NwkSKey和AppSKey，并分发相应的终端设备，用来加密、校验网络通讯和应用数据。

 

入网同意下行包：

入网申请包中带有数据AppNonce（3字节）、NetID（3字节）、DevAddr（4字节）、DLSeting（1字节）、RxDelay（1字节）、CFList（0~16字节），而且整个MACPayload+MIC都被加密，加**匙是AppKey。

      计算方法如下：

      入网同意下行包加密

      aes128_decrypt(AppKey,AppNonce | NetID | DevAddr |DLSettings | RxDelay | CFList | MIC)

      MIC校验

      cmac =aes128_cmac(AppKey,MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay |CFList)

MIC = cmac[0..3]

      NwkSKey和AppSKey计算方法：

      NwkSKey =aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16) （pad16函数附加 0 字节以便于数据长度是一个 16 的倍数）

AppSKey = aes128_encrypt(AppKey, 0x02 |AppNonce | NetID | DevNonce | pad16)

      AppNonce：是由网络服务器产生的一个随机数或唯一 ID，终端设备用它来衍生两个会话**：NwkSKey 和 AppSKey，服务器也会利用公式算出这两个秘钥，两端都保存此秘钥。

NetID：NetID的低7位称作NwkID，这低7位也是DevAddr（终端短址）的高7位。区域相邻或重叠的网络的NwkID不能相同。余下的高17位由网络运营商*分配。

DevAddr：终端的短地址和DevEUI有对应关系。他的组成结构如下：

Bit	[31..25]	[24..0]
DevAddr	NwkID	NwkAddr

NwkAddr：终端设备网络地址，该地址可以有由网络管理员分配。 NwkID：在NetID中有解释

 DLSeting：结构如下：

Bits	7	6..4	3..0
DLsettings	RFU	DLsettings	RX2DataRate

RxDelay：遵循着在 RXTimingSetupReq 指令中的延时字段一样的惯例。默认0x00。 RX1Droffset 字段设置上行链路数据和被用作在第一接收时隙（RX1）中与终端设备通信的下行链路数据之前的偏移。偏移默认值为 0。下行数据率通常小于等于上行链路数据率。偏移量被用来考虑在某些区字段基站的最大功率密度限制以及平衡上行链路和下行链路射频通信线路的边界。上行链路和下行链路数据率的实际关系是有区域特异性的，并且在“物理层”部分会详细介绍。

 CFList：这个字段是根据不同地区的标准来设定的，如果是CN470标准的话，此字段为空。

 NwkSKey：是分配给终端设备的网络会话**。服务器和终端用它来计算和校验所有消息的MIC（消息一致码），来保证收发的数据一致。也可以用来对MAC负载（Fport为0时，MAC指令放在Payload里面）的消息进行加/解密。

 AppSKey：是分配给终端设备的应用会话**。服务器和终端用来对FRMPayload字段进行加解密。也可以用来计算和校验应用层MIC。