LoRa Mac 说明书(1-2章)——激活过程

1 介绍

LoRa是Semtech公司开发的应用与长距离低功耗低数据传输量场景下的无线调制技术。本文档为潜在的使用电池供电的移动或者固定设备介绍了LoRa的MAC层。它进一步激励网络运营商、终端设备制造商或者两者考虑使用LoRa的MAC层的设计决策来获得给定场景下的最佳性能。

LoRa的网络拓扑通常是星形的，网关承担着节点和后台服务器之间的中继作用。网关和网络服务器通过标准的IP连接，同时网络节点通过单跳的LoRa通信连接到网关。所有的通信通常是双向的，通常从节点到后端服务器的上传链路是更重要的。

终端节点和网关直接的通信分布在不同频率的通道和所谓的扩频因子之间。本质上，选择不同的扩频因子是在通信距离和数据速率之间进行权衡，因此选择不同的扩频因子相互之间是不会产生干扰。根据选用的扩频因子不同，LoRa的传输速率可以分布在0.3kbps到40kbps。为了最大化终端电池的使用寿命和整体网络容量，LoRa网络基础设置和终端节点通过一种自适应数据速率(ADR)合作管理扩频因子和终端接口节点的RF。

对于时间的同步和通道信息的传输，网关定期进行广播信标。每个信标最少含有在给定网络内的用于随机访问的一组通道以及当前的GPS时间。信标的广播是由同一网络下没有干扰的网关同步完成的。

终端节点可以在任意时间，以任意可使用的速率在任意可以访问的信道进行传输，但是要遵循以下的规则：

• 在传输之前，终端节点使用Listen before Talk（LBT）来确保目标传输通道是空闲的。当测量时刻的信号强度小于RSSI_FREE_TH 的时候，通道就被认为是空闲的。如果通道是不空闲的，终端就会选择选择其他通道进行通信。
• 终端设备通过一个伪随机序列进行每次通信频率的改变，这样产生的频率使得系统更加稳定。

• 终端设备根据使用的子带确保最大的传输占空比

  Note: LoRa的Mac要求每个子带的占空比符合ETSI EN300.220标准。第五章中描述了这个规定的具体实现方法。

  LoRa网络对以下两类终端进行了区别：

• 双向传播设备(Class A): Class-A 类的终端设备允许在MAC层和应用层每个发送操作之后打开两个非常短的接受窗口。发送操作末尾和接受操作开头的时间间隔是被可以被配置的，但是对于同一网络来对的，所有的A类终端应该是相同的。
• 有同步接受槽的双向传输设备(Class B): Class-B 的终端设备在MAC层和应用层必须通过在网络中网关广播信标中包含的时间信息为基础进行调度。除此以外，和A类设备一样，两个接受窗口会在发送之后打开。
  Note: 本文档中所有的字节都是小端在前。

2 终端节点激活

在加入LoRa网络之前，每一个终端设备都要进行个性化设置然后进行激活。在激活过程中，以下的信息需要被存储在终端节点中:
- DevAddr: 一个32比特的Device Id对终端设备进行唯一标识。
- AppEUI: 一个全球唯一的EUI64格式的应用ID唯一表示了终端设备的应用提供者。
- NwkSKey： 每个设备特有的网络会话密钥被服务器和终端设备用来计算和确认所以数据的MIC 确保完整性。未来还被应用于对负载部分的MIC 数据进行加解密。
- AppSKey: 每个设备特有的应用会话密钥被服务器和终端节点用来加密和解密负载部分的应用相关数据。它也有可能被用来提供可选的应用层的MIC的计算和确认，该部分可选地加入数据负载中。

DevAddr：必须是所在网络中是唯一的，它的格式如下所示：

比特数	31-25	24-0
DevAddr	NwkID	NwkAddr

DevAddr的开头7比特是用来标识网络的，用来分隔开不同运营商的地域网络重叠区域并且解决漫游问题。后面的25比特数据，也就是终端的NwkAddr可以由管理员任意分配。
终端的激活共有两种方式，第一种方式over-the-air activation(OTAA)，用在终端节点被部署或者重置的时候。第二种active by personalization（ABP）,终端设备的个性化和激活是一步完成的。

2.1 Over-the-Air Activation

对于OTAA激活方式，终端设备在网络服务器进行数据交换之前必须遵循一个加入过程。一旦终端设备进行了重启或者上电就要重复进行加入过程。
加入过程需要终端设备提供各自的以下信息：
- DevEUI:一个全球唯一的EUI64格式的ID
- AppEUI:一个全球唯一的EUI64格式的应用ID
- AppKey:一个设备特有的AES-128应用密钥
DevEUI也称设备号，定义了每个设备全球唯一。除了AppEUI，设备商还为设备提供了应用密钥(AppKey)，最有可能的是通过从应用程序提供者控制的根密钥导出的。不管何时，一个节点终端通过OTAA激活的方式加入网络，AppKey用来分发加密和确认数据网络信息和应用数据的NwkSKey和AppSkey。

Note: 对于OATT，终端节点没有被初始化任何network key。反而，无论何时终端节点加入网络，设备唯一的网络会话密钥被分发后被用来在加密和确认网络层的传输。在这种情况下，终端节点在不同提供商的不同网络是可行的。同时使用网络会话密钥和应用会话密钥可以确保网络提供者无法获取应用数据。

从终端节点的角度，加入过程是加入请求(jion request)和(join accept)两部分组成的。加入工程总是由终端节点发送加入请求信息开始的:

字节数	8	8	2
加入请求	AppEUI	DevEUI	DevNonce

加入请求包括终端节点的AppEUI和DevEUI，最后是一个2字节的nonce。DevNone是一个随机值，是假设RSSI的随机性满足真随机性进行测量RSSI得到的。对于每一个终端设备，网络服务器对终端节点的DevNone的过去值保持跟踪，并且忽视与之前随机值相同的加入请求。
Note:这种机制是为了防止通过发送先前保存的加入请求信息，从而断开服务器端和节点之间连接的重放攻击。

在发送加入请求之前，终端设备需要监听信令。所有的网关会规则性广播信令，并且每个信令包含了给定网络内可用于随机访问的那些信道的信道指令。由于加入请求并不受特定发射时刻表的约束并且总是随机发送，所以加入请求必须在这些可以随机访问的信道之一发送。
Note：终端设备应该缓存给定网络的信标分配的信道信息以防止在连接丢失的情况下重新加入网络。在这种情况下，终端设备在重新加入网络前不需要等待信令。

加入请求信息的MIC值通过下式进行计算[RFC4493]：
cmac = aes128_cmac(AppKey，MHDR|AppEUI|DevEUI|DevNonece)
MIC = cmac[0..3]
加密请求的信息是不加密的。

在终端节点在被允许加入网络之前，网络服务器会反馈一个加入接受信息。加入接受信息在接受请求信息发送完成后的固定时间进行发送(JOIN_ACCEPT_DELAY)，如果加入请求不被接受，那么就不会有反馈信息给终端节点。

字节数	6	4	2
加入同意	AppNonce	DevAddr	RFU

加入接受信息包括一个6字节的AppNonce和一个4字节的DevAddr, AppNonce网络服务器提供的随机数或者特殊的ID，终端节点使用它进行NwkSKey和AppSKey的密钥生成，其生成方法如下：
NwkSKey = aes128_encrypt(AppKey,AppNonce|DevNonce|pad16)
AppSKey = aes128_encrypt(AppKey,DevNonce|AppNonce|pad16)
加入接受信息的MIC值通过如下进行计算[RFC4493]:
cmac = aes128_cmac(AppKey,MHDR|AppNonce|DevAddr|RFU)
mic = cmac[0:3]
加入接受信息本身也是被如下的AppKey进行加密的：
aes128_decrypt(AppKey,AppNonce|DevAdd|RFU|MIC)
网络服务器使用AES解密操作进行加密，终端节点使用AES加密操作进行解密，这样终端节点只要实现AES加密操作，而不需要AES解密操作。
注意：使用两次会话密钥是为了防止网络商窃听应用数据，在这样的设定下，应用的提供者必须在终端节点加入网络的过程中支持网络提供商并且为终端设备提供NwkSKey。同时，应用提供商向网络运营商承若，将承担终端设备所产生的任何流量费用，并保留对用于保护其应用数据的AppSKey完全控制权。

2.2 Activation by Personalization

对于某些网络，比如私有网络，OTAA过程可能过于复杂。对于这些网络，通过ABP可能是一个更好的方案，但是此时的代价是会降低系统的安全性，同时从组织的角度来看可能会更加复杂。它还将终端设备绑定到某个固定的网络，并且阻止其进行漫游。因此，在ABP方式下，节点只能呆在特定的LoRa网络中。

通过ABP方式进行激活，终端设备的DevAddr以及两个会话密钥NwkSKey 和AppSKey直接被写入到终端设备的，而不是DevEUI和AppKey。在这种情况下，终端节点从一开始就包含了个性化的信息。

Note:终端设备需要侦听到第一个信标信息，从而了解可以用于随机接入的信道。