LoRaWAN 规范 1.0 （6）
LoRaWAN 规范1.0 （第六章部分）
最近在做LoRa， LoRaWAN协议略微复杂，边读边翻译，现在把部分关键的翻译分享给各位做物联网的同行。
当然里面掺杂了一些我的个人笔记，希望对大家有所帮助。
如果哪里有问题，欢迎应各位留言或者邮件指正。翻译很辛苦，转载请注明出处和源链接
- 英文原文链接： 《LoRaWAN Specification 1R0》
- LoRaWAN版本历史及协议格式说明
- 翻译原文链接：
声明
本文翻译版本部分已更新至LoRaWAN 1.0.2。
6 终端激活（End-Device Activation）
所有终端设备在正式加入LoRaWAN网络之前必须先进行初始化并激活。有两种激活方式：
无线激活（Over-The-Air Activation (OTAA)），设备部署和重置时使用;
手动激活（Activation By Personalization (ABP)），此时初始化和激活一步完成。
6.1 激活成功后存储在终端设备的数据
以下信息在激活成功后回存储在终端设备：设备地址（DevAddr）、应用ID（AppEUI）、网络会话密钥（NwkSKey）和应用会话密钥（AppKey）。
6.1.1 终端设备地址（DevAddr）
DevAddr是终端在当前网络中的识别码，大小32bits。结构如下：
Bit [31..25] [24..0] DevAddr bits NwkID NwkAddr 最高7位是网络ID（NwkID），用以区分有地域重叠的不同网络运营商和弥补有路由问题的网络。接下来的25bits，终端设备网络地址（NwkAddr），该地址可以有由网络管理员分配。
6.1.2 应用唯一识别ID（AppEUI）
AppEUI是 IEEE EUI64 的全球唯一应用ID，用以识别终端设备的应用服务提供商（等等）。AppEUI在进行激活操作之前就存储在终端设备中了。就是说AppEUI是出厂时烧录进去的。
6.1.3 网络会话密钥（NwkSKey）
NwkSKey是分配给终端设备的网络会话密钥。网络服务器和设备用它来计算和校验所有消息的MIC（消息一致码），来保证收发的数据一致。也可以用来对MAC负载（MAC命令放在Payload里面）的消息进行加/解密。
6.1.4 应用会话密钥（AppSKey）
AppSKey是分配给终端设备的应用会话密钥。网络服务器和设备用来对 应用指定的 Payload字段进行加解密。也可以用来计算和校验应用层MIC（可能存放在应用指定 消息的Payload中）。
6.2 无线激活（Over-the-Air Activation）
终端设备在与网络服务器交流（数据交换）之前，必须先通过加入过程加入网络服务器。每次终端设备会话的上下文丢失（与服务器通信断开）后都要重新加入。加入服务器之前，要使用以下信息初始化终端设备：全局唯一设备ID（DevEUI）、应用ID（AppEUI）、AES-128密钥（AppKey）。 AppEUI在上面6.1.2中有介绍。
* 注意：无线激活时，网络密钥初不会向初始化那样写死到终端，而是在终端加入网络时由网络层衍生并分发，该密钥用来对传输数据进行加密和校验。这样，终端设备能很方便的在不同的网络服务器和应用提供商之间切换。使用网络会话密钥和应用会话密钥*可以避免应用数据被网络供应商（网络服务器拥有者）解析或篡改，从而接入大量的网络服务器。
6.2.1 终端设备ID（DevEUI）
DevEUI是全球终端ID，符合 IEEE EUI64，用来唯一辨识终端设备。
6.2.2 应用密钥（AppKey）
AppKey是AES-128的应用密钥，由应用拥有者通过 应用指定的 根密钥衍生并分配给终端设备，根密钥只有应用供应商知晓和掌握。终端设备通过无线激活入网时，通过AppKey衍生会话密钥 NwkSKey和AppSKey，并分发相应的终端设备，用来加密和校验网络通讯和应用数据。
6.2.3 入网流程
从终端的角度看，和服务器交互的入网流程包含两个MAC消息：join request 和 join accept.
6.2.4 入网请求（Join-request message）
入网流程由终端发起，终端入网时发送入网请求，消息格式（MACPayoad）如下：
字节数 8 8 2 Join Request AppEUI DevEUI DevNonce 入网请求消息包含：AppEUI、DevEUI和终端设备产生的2字节的随机数（DevNonce）
DevNonce是个随机值，终端设备最近使用的一些(数量自定义)DevNonce会保存在网络服务器（NS）。如果终端发送的入网请求中的DevNonce在NS中可以查到，该请求就会被忽略。注意：该机制的目的是防止重放攻击(replay attacks)，避免其它人通过发送之前的入网请求来断开终端设备和网络的连接。
入网请求的消息一致性校验码（MIC）（见第4章MAC消息部分）通过下述算法计算：
cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce) MIC = cmac[0..3]入网请求以明文发送。
6.2.5 接受入网消息（Join-accept）
服务器同意终端入网后网络服务器（NS）会回复 接受入网 消息。接受入网使用
JOIN_ACCEPT_DELAY1或JOIN_ACCEPT_DELAY2（而不是RECEIVE_DELAY1 和RECEIVE_DELAY2），和普通消息一样发送。这两种接收窗口使用的信道频率和数据率与 RX1和RX2的接收窗口（见章节“物理层”之”接收窗口”）相同。入网请求被拒绝则服务器不发送任何数据。
接受入网消息包含以下字段：应用层随机数（AppNonce），3字节；网络ID（NetID）；终端地址（DevAddr）；介于 TX 和 RX（RxDelay） 之间的延迟；信道频率的一系列配置（CFList）。CFList相关内容见第7章。
大小（字节） 3 3 4 1 1 变长(16) 接受入网 AppNonce NetID DevAddr DLSeting RxDelay CFList AppNonce是由网络服务器产生的一个随机数或唯一ID，终端设备用它来衍生两个会话密钥：NwkSKey和AppSKey。衍生算法如下：
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce |NetID | DevNonce | pad16) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)接受入网的MIC计算方式如下：
cmac = aes128_cmac(AppKey,MHDR | AppNonce | NetID | DevAddr | DLSeting | RxDelay | CFList) MIC = cmac[0..3]消息本身采用 AppKey 加密，加密方式如下：
aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | DLSeting | RxDelay | CFList | MIC)注意：网络服务器加密接收入网消息使用的是 AEC ECB模式的解密算法。这样终端就不必再实现AES解密算法，只用AES加密即可。
NetID包含：NetID的7个最低有效位称作NwkID，即DevAddr（终端短址）的7个最高有效位。区域相邻或重叠的网络的NwkID不能相同。余下的17个最高有效位由网络运营商自由分配。
DLsetting字段含有下行配置：
位（Bits） 7 6:4 3:0 DLsettings RFU RX1DRoffset RX2 Data rate RX1DRoffset设置上下行数据速率之间的偏移（偏差），和终端设备交互的首个接收时隙（RX1）。（感冒好几天了，头懵，不知道该怎么翻译） offset默认为0。下行数据速率不能比上行的大。考虑到一些地区基站的最大功率密度限制，offset用来平衡上行和下行的无线链路余量。
上行和下行链路数据速率之间的确切关系见章节 “物理层（Physical Layer）”延时RxDelay规则和RXTimingSetupReq命令中的Delay字段相同。
6.3 手动激活(Activation by Personalization)
某些情况下，可以通过配置激活终端设备，（我）称为手动激活。手动激活跳过了(jion request-join accept) 入网过程，将一个终端设备和指定的服务器联系在一起。
手动激活需要把 DevAddr、NwkSKey以及AppSKey直接存放到终端设备，而不再需要（无线激活 （或空中激活、OTA激活、OTAA） 中的）DevEUI、AppEUI以及AppKey。终端设备启动时就已经具备了加入指定LoRa网络所需要的信息。
每一个终端设备都有一对唯一的 NwkSKey 和 AppSKey。这些协商的设备秘钥不能影响其它设备的通信安全。生成秘钥的流程应当保证这些秘钥不能通过公开的信息以任何方式推导出来。（比如：节点地址）。
PS
看到有些伙伴提问问题，由于本人的CSDN一般不在线。
为了方便交流，附个邮箱，有问题或者想法的朋友可以 
本文由 qingchuwudi 译制，除非另有声明，在不与原著版权冲突的前提下，本作品采用知识共享署名 3.0 中国大陆许可协议进行许可。
