[资料]

LoRaWAN协议格式与中文手册下载

2018-10-29 22:55:00 3391 lorawan 物联网

1、LoRaWAN 介绍 LoRaWAN是由LoRa联盟推出的一个低功耗广域网规范，这一技术可以为电池供电的无线设备提供区域、国家或全球的网络。LoRaWAN瞄准了物联网中的一些核心需求，如安全地双向通讯、移动化和本地服务。该技术无需本地复杂配置，即可以让智能设备实现无缝互操作性，给物联网领域的用户、开发者和企业自由操作权限。

LoRaWAN网络架构是一个典型的星形拓扑结构，由终端、网关和服务器组成。在这个网络架构中，LoRa网关是一个透明的中继，连接前端终端设备和后端中央服务器。网关与服务器通过标准IP连接，而终端设备采用单跳与一个或多个网关通信，所有的节点均是双向通信。
终端与网关之间的通信是在不同频率和数据传输速率基础上完成的，数据速率选择需要在传输距离和消息时延之间权衡。由于采用了扩频技术，不同数据传输速率通信不会互相干扰，且会创建一组“虚拟化”的频段来增加网关容量。LoRaWAN网络数据传输速率范围为0.3 kbps至50 kbps，为了最大化终端设备电池寿命和整个网络容量，LoRaWAN网络服务器通过一种速率自适应（ADR）方案来控制数据传输速率和每一终端设备的射频输出。
适用于物联网的覆盖全国的网络需要解决诸如关键性基础设施、机密的个人数据或社会公共服务等安全通信的问题，这方面一般采用多层加密的方式来解决：
· 唯一网络密钥（EU164）并保证网络层安全
· 唯一应用密钥（EU164）并保证应用层端到端的安全
· 设备特别密钥（EUI128）
LoRaWAN网络各节点具有多层级安全方案，保证各类应用的不同需求：
· 双向通信终端设备（A等级）：处于A等级的终端设备允许双向通信，每一终端设备上行传输会伴随着两个下行接收窗口。终端设备的传输槽是基于其自身通信需求，其微调是基于一个随机的时间基准（ALOHA协议）。A等级的终端设备应用中功耗最低，在终端发送一个上行传输信号后才能与服务器进行下行通信，与服务器任何时候的下行通信都只能是在上行通信之后。
· 具有预设接收槽的双向通信终端设备（B等级）：B等级的终端设备会在预设时间中开放多余的接收窗口，为了达到这一目的，终端设备会同步从网关接收到一个Beacon，这一方式会让服务器了解终端设备正在“倾听”。
· 具有最大接收槽的双向通信终端设备（C等级）：C等级的终端设备几乎持续为接收窗口开放，只在传输时关闭。
2、CLASS A    在上一节中提到LoRaWAN有A、B、C三种类型的终端，它们都具有CLASS A设备的特性。处于A等级的终端设备允许双向通信，每一终端设备上行传输会伴随着两个下行接收窗口。终端设备的传输槽是基于其自身通信需求，其微调是基于一个随机的时间基准（ALOHA协议）。A等级的终端设备应用中功耗最低，在终端发送一个上行传输信号后才能与服务器进行下行通信，与服务器任何时候的下行通信都只能是在上行通信之后。
3.1上行消息    LoRaWAN中将消息分成上行和下行两种类型。上行消息指的是终端节点通过一个或多个网关转发给服务器的消息。消息格式如下：

上行消息物理层上采用的是lora radio的显示格式，其中Preamble、PHDR、PHDR_CRC和CRC部分都是由lora radio硬件填充，PHYPayload是用户数据段。消息的完整性有CRC保证。
3.2下行消息
下行消息是指服务器通过唯一一个网关转发给终端的消息，消息格式如下：

  下行消息物理层上采用的是lora radio的显示格式，其中Preamble、PHDR、PHDR_CRC由lora radio硬件填充，PHYPayload是用户数据段。为了使消息尽量短小提高带宽利用率，下行消息物理层中没有使用CRC。
3.3 接收窗口
终端在每次上行报文最后一个字节传输完成之后都会打开两个短暂的接收窗口。如下图所示，在上行消息传输完成之后，等待了RECEIVE_DELAY1时间后打开第一个接收窗口RX1，在等待RECEIVE_DELAY2之后打开第二个接收窗口RX2。第一个接收窗口RX1中使用的是和刚才传输的上行报文相同的频点和速率，第二个窗口RX2采用的是之前设置好的频点和速率，窗口的频点和速率可以通关mac命令来设置。

接收窗口时间长度至少满足让终端lora radio能够检测到下行消息的有效前导码。如果服务器端有下行报文要发送给终端，服务器会在终端两个窗口开始时发送。如果终端在两个接收窗口期间检测到前导码，接收状态会一直保持到收完整个下行消息为止。同时，如果终端在第一个窗口内收到给自己的报文，同时MIC（消息完成码）验证正确，那么终端将不会打开第二个接收窗口。

注意：所有的终端设备在上一次发送上行消息后在两个窗口内没有收到服务器下行消息之前或者第二个接收窗口失效之前，不能发起下一次上行消息。
3、LoRaWAN帧格式
本章节主要介绍LoRaWAN中的帧格式。如下图所示LoRaWAN中的消息分成3层，从外到内一次是物理层、MAC层、和数据层。

3.1 MAC 层（PHYPayload）

LoRaWAN中所有上下行消息都有PHYPayload，包括了一个字节的MHDR（mac帧头）、MACPayload(mac消息)以及4字节的MIC（校验）信息。

13.1.1 MHDR

Mac帧头长度为1字节，低两位表示LoRaWAN的版本号，中间3位保留做后续使用，最高3位是消息类型。

LoRaWAN中一共有一下8种MAC消息类型。

其中Join Request和Join Accept消息在端点空中激活时使用。

Unconfirmed Data Up、Unconfirmed Data Down、Confirmed Data Up、Confirmed Data Down这四种类型用作数据消息传输使用，其中Confirmed 类型消息需要对端回复ACK。数据消息中可以同时包括mac命令和应用数据。Proprietary消息为用户自定义类型消息，此类消息不能被标准协议栈解析。

3.1.2 MAC Payload

数据消息的MAC Payload段又叫做“data frame”，包括了FHDR帧头、端口号FPort和帧的数据段。

3.1.2.1 FHDR

帧头由4字节的终端设备短地址Devaddr，1字节的帧控制域字段FCtrl，2字节长度的帧计数器以及最多15个字节长度的帧选项字段(用作传输MAC命令)组成。

下行数据帧头中FCtrl域内容如下：

上行数据帧头中FCtrl域内容如下：

ADR：LoRaWAN中网关上lora radio可以监听多种速率，这使得终端设备的组网灵活性大大加强，终端设备可以自适应调整自身速率ADR来连接网关，当终端设备启用ADR后会自动选择最高的传输速率来和网关通信。

移动的终端设备最好使用一种固定的速率和网关通信，因为在移动的环境下终端设备的无线电磁环境不稳定，这会使得ADR很难管理。

当帧头中ADR位置1的时候，服务器会根据当前收到的节点信号质量通过下行消息中的MAC命令来控制终端的速率。ADR功能可以通过终端或者服务器来配置，为了增加终端的电池供电时间和扩大网络的容量，ADR最好使能。

如果服务器给终端设备优化的传输速率高于了终端默认的传输速率，那么终端就必须定期确认服务器还能收到上行报文。每次上行报文传输后，终端都会增加ADR_ACK_CNT计数器，当该计数器达到ADR_ACK_LIMIT而没有收到服务器的下行消息时，终端就会在帧头将ADRACKReq置1来先服务器请求。服务器收到该请求后就会在ADR_ACK_DELAY时间内发送一个下行消息给终端设备，同时终端设备收到该下行消息后就会将ADR_ACK_CNT计数器清零。在该下行消息中ACK位不必置1，因为终端设备在上行消息后的接收窗口内能收到下行消息同时也表网关依然能收到终端设备的消息。另外一种情况就是如果终端发送了带ADRACKReq的上行消息后再ADR_ACK_DELAY时间内仍然没有收到网关的下行消息就说明网关和终端设备间的连接已经断开了，这种情况下终端设备就要尝试用一种更低的速率（传输速率和传输距离成反比）来尝试与网关建立连接。如果上行报文次数达到了ADR_ACK_LIMIT后还是没能连接成功，那么继续使用更低的速率。

ACK：当收到一个confirmed消息时，接收端应该在帧头中间ACK置1。如果消息是有终端发出来的，那么服务器就要在终端设备的两个接收窗口期间发生ACK消息给终端设备。如果消息是由服务器发送的，终端设备可以自行选择什么时候回复ACK消息给服务器。ACK消息只是给上一条接收消息，而且不会重发。

消息重传过程：当一个confirmed消息发出后在一定时间内没有收到ACK确认，那么就要对消息重传，重传次数可以本地设置或者通过服务器来配置。如果终端设备重传次数达到了最大次数都还没收到ACK确认，那么终端设备就需要降低速度来重新和服务器连接。

FPending：该位只会出现在下行消息中，表示网关中有很多条消息要发送给终端，终端设备在要马上进行下一次上行消息的传输来接收网关消息。

FCnt：每个终端设备中都有两个16位或者32位计数器，FCntUP用来计数发送给服务器的上行消息个数，FCntDown用来计数收到的下行消息。同时在服务器上对应给每个终端设备也有上下行计数器。当终端设备完成加入网络之后终端和服务器上的计数器就会先清零。发送报文中Fcnt是发送报文计数。

FOptsLen：表示数据帧中FOpts段的长度。FOpts用来传输MAC命令。如果该长度为0，一味着消息中不带FOpts，如果FOpts中带有mac命令，那么FPort不能端口0。

mac命令不能同时出现在FOpts和paylaoda中。

3.1.2.2 FPort

如果数据帧中payload部分不为空，那么Fport必须存在。如果FPort的值为0表明了FRMPaload中只能包含有mac命令。FPort为1-223为应用使用，224-255保留后续使用。

上图中N表示payload最大字节数，N <= M - 1 - （FHDR长度），其中M标志最大MAC payload长度。

3.1.2.3 FRMPayload与加密

如果消息中包括了FRMPayload，那么FRMPayload必须在计算MIC之前进行加密。加密使用128bit密匙的标准AES算法。

默认情况下对应所有的FPort的FRMPayload的加密解密过程都是由软件中LoRaWAN层来完成的，FPort为0时传输的是MAC命令，加密时用NwkSkey，FPort为其他值时用AppSkey加密。

加密时，首先将pld = FRMPayload按照每16字节分成一段进行加密，假如分成了k段。

然后会生成k个Ai段，Ai表示如下，Dir表示方向上行为0，下行为1.FCntUp和FCntDown表示上下行消息计数，i表示对应的k段序列号。

接着将Ai进行加密，加密后得到16字节长度的Si，组成S。加密公式如下，其中的K表示加密密匙。

最后在将FRMPayload的每个字节与S的每个字节进行异或操作来加密。对应的解密过程也是一样的对已经加密的FRMPayload再进行一次加密就相当于对起进行解密。

除了0之外的所有FPort也可以选择通过应用层用户自己给数据加密解密。具体加密算法见协议4.4章节。

3.1.3 MIC

Mic是消息完整码，用来对传输数据做校验，通过AES加密，MIC的计算公式如下：

其中，

。

B0定义如下，Dir表示方向上行为0，下行为1.FCntUp和FCntDown表示上下行消息计数。Len为msg的字节数。

4、MAC Command
   MAC命令用于服务器和节点MAC层之间的通信管理。单个数据帧中可以包括多个MAC命令，命令既可以放在数据帧的FOpts部分也可以单独作为一帧数据进行传输。放在FOpts中时MAC命令不会被加密而且不能超过15个字节，数据帧单独传输MAC命令时将命令放在FRMPayload中，数据帧的Fport端口号为0，最大长度不能超过规定的数据长度，由于FRMPayload部分会被加密，因此传输的MAC命令也是加密的。为了防止MAC命令被窃取最好采用单独的数据帧传输。

MAC命令包含了1个字节命令标识CID，同时不同的命令后面还有不同长度的后续字段。MAC命令列表如下：

上表中只给出了MAC命令的类型和介绍并没有给出命令后数据的具体长度，下面将详细介绍每条命令的用途。
4.1 连接状态检测命令
当终端想要验证与网络的连接情况时，终端会发送LinkCheckReq命令给服务器，该命令无后续数据。

服务器收到由一个或者多个网关转发过来的LinkCheckReq后，返回一个LinkCheckAns命令给终端并带有两个字节长度的数据。

margin是8位无符号整数，取值0-254代表服务器收到最近的LinkCheckReq的无线信号强度。GwCnt表示有多少个网关成功收到了终端发出的LinkCheckReq命令。

4.2 ADR命令
  服务器通过LinkADRReq 命令来实现终端的速率自适应ADR功能。

针对不同频段的无线信号，DataTate和TXPower都有相应的规范，例如下表对应的是433M带宽对应的几种速率和发射功率。详情见协议文档第7章节。



ChMask长度为16位，每一位代表一个频段对应的可用通道（比如，433M频段可以用的有433.175、433.375、433.575三个无线频段的通道），对应为0的一位代表通道不可用，为1代表可用。

Redundancy中4位长度的NbRep表示上行消息的重复发送次数，该设置只对unconfirmed上行消息有效，有效范围是1-15，默认值为1，如果该值为0，那么使用默认值。NbRep用于当服务器想获取节点的信号Qos使用，终端每重复一次上行发送就会进行调频到下一个可用频段。ChMaskCntl用于对Chmask的控制，当可用频段超过16个时该值不为0.

当终端收到LinkADRReq后回复LinkADRReq命令给服务器。对应位设置成功是为1，失败为0，失败后终端按照原来的配置运行。

4.3 终端上报周期设置命令
服务器用DutyCycleReq 命令来设置终端节点的上报周期，设定的周期对于所有的通道都一致。

终端最大的上报周期为：

MaxDutyCycle取值范围为0-15，如果该值为255表示终端保持无线电静默模式，相当于关闭该终端。如果该值为0代表使用默认的上报周期。

终端收到DutyCycleReq 命令后回复DutyCycleAns命令给服务器，该命令不带数据。
4.4 接收窗口设置命令
RXParamSetupReq命令用来设置上行消息后的第二个窗口，命令的格式如下：

RX1DRoffset定义的是第一个接收窗口上下行速率之差，默认值为0；RX2DataRate定义的是第二个接收窗口的下行数据速率。Frenquency定义第二个接收窗口的无线通道频段。

终端设备收到RXParamSetupReq后回复RXParamSetupAns给服务器。如果回复的3个ack有一个为0，那么设置不成功，终端设备参数保持不变。

4.5 终端状态查询命令
服务器使用DevStatusReq命令来查询终端节点的状态。该命令没有带数据，如果终端收到该命令，那么终端回复DevStatusAns给服务器，命令格式如下：

其中Battery代表终端的电池电量，0表示采用非电池供电，1-244表示电池的电量1为最小255最大，255表示电池电量测量失败。Margin的低6位表示接受到DevStatusReq的无线信号强度，范围-32-31.
4.6 增加或者修改无线通道命令
NewChannelReq可以用于添加新的无线通道或者修改目前存在的无线通道。

其中ChIndex 表示新增或修改通道的序列号，对于协议中已经制定好的通道修改是无效的，可以对规定好的通道外的通道进行设置，最多不超过16个通道。Freq对应的是设置的通道中心频率，Freq X 100为真实频率，当Freq为0时相当于禁用该通道。DrRange的低4位和高4位分别表示该通道上最小和最大速率。

终端收到NewChannelReq命令后回复NewChannelAns给服务器，如果status中低2两位任意1位为0代表添加通道不成功。

4.7 TX与RX时间间隔设置命令
RXtimingSetupReq命令用来设置终端上行数据发送完成后打开第一个接收窗口的时延，第二个窗口在第一个接收窗口打开后1s开始。

   其中Del为4位整数，取值范围为0-15，单位为s，其中0和1都表示时延1s，最大为15s。终端收到RXTimingSetupReq后回复RXTimingSetupAns给服务器，不带数据。

5、终端设备激活
终端设备需要经过激活才能加入到LoRaWAN网络中，终端设备在部署或者重启后有两种激活方式，一种是无线激活OTAA以及本地激活ABP。
5.1 终端参数
   在终端设备出场时设备内保存了终端设备标识DevEUI、应用标识AppEUI以及AES-128密匙AppKey。在终端设备激活后，会保存设备地址DevAddr、网络会话密匙NwkSKey、应用会话密匙AppSKey。
5.1.1 DevEUI
DevEUI是终端设备的全球唯一标识，相当于mac地址。
5.1.2 AppKey
AppKey是终端设备的应用提供商提供的密匙，用来生成AppSKey和NwkSKey。
5.1.3 DevAddr
DevAddr是32位的终端设备网络地址，在网络中每个设备的网络地址是唯一的。高7位是网络号NwkId标识不同的网络，低25位是分配给终端的网络地址。

5.1.4 AppEUI
AppEUI全球唯一地标识了终端设备的应用提供商，长度为64位，在终端设备激活之前就已经保存在终端中。

5.1.5 NwkSKey
网络会话密匙NwkSKey在服务器与终端设备的消息中用来计算消息完整码MIC，来验证消息的正确性，同时在只传输MAC命令的消息中用来加密和解密数据段。
5.1.6 AppSKey
应用会话密匙AppSKey在服务器与终端设备的消息中用来计算消息完整码MIC，来验证消息的正确性，同时在传输应用数据的消息中用来加密和解密数据段。
5.2 无线激活
终端设备在部署或者与服务器之间连接断开后都要通过无线激活步骤来与服务器建立连接。从终端的角度来看加入网络的过程包括两个MAC消息与服务器的交换，分别是join request和join accept。
5.2.1 Join-request
终端发送Join-request消息给服务器（hex）：

00 01 02 03 04 05 06 07 08 39 7d 39 84 30 34 51 04 7f a2 c0 fd 1d e5

MHDR	MAC Payload			MIC
00	01 02 03 04 05 06 07 08	39 7d 39 84 30 34 51 04	7f a2	c0 fd 1d e5
Join-request	AppEUI	DevEUI	DevNoce	MIC

MHDR类型：

MIC的计算公式如下：

其中AppKey定义为128位:

#define LoRaWAN_APPLICATION_KEY { 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF, 0x00 }

组网请求后第一个接收窗口时延5s

#define JOIN_ACCEPT_DELAY1 5000000

第二个接收窗口6s

#define JOIN_ACCEPT_DELAY2 6000000

终端设备发送join request消息来向服务器发起入网请求，请求消息中包含了AppEUI、DevEUI以及2字节长度的DevNone。

DevNone是一个随机值，服务器保存了每个终端设备过去使用过的DevNone值，如果查询到该值已经出现过，那么服务器就忽虐该入网请求。

该入网请求是没有加密的，消息的完整码MIC的计算公式如下：

5.2.2 Join-accept
服务器发送Join-accept消息给终端（hex）：

01 13 4f bc 00 00 01 01 00 00 01 06 01 ff ff ff ff

MHDR	MAC Payload					MIC
20	13 4f bc	00 00 01	01 00 00 01	06	01	ff ff ff ff
Join-accept	AppNonce	NetId	DevAddr	DlSetting	RxDelay	MIC

消息中DlSetting为6，表示接收窗口速率为6，RxDelay为1，表示上行消息发送完成后1s后打开第一个接收窗口。

在服务器收到入网请求后，如果当前终端被允许加入到网络中服务器会返回Join-accept给终端设备。如果终端不允许加入到网络中，服务器是不会发送任何消息的。Join-accept消息发送时就和普通的下行消息一样，但是时延用的是JOIN_ACCEPT_DELAY1或者JOIN_ACCEPT_DELAY2而不是RECIEVE_DELAY1或者RECIEVE_DELAY2，同时发送通道的速率和频点和终端上行消息的两个窗口RX1和RX2一样。

Join-accept消息由3字节的AppNonce、3字节的网络号NetID、和4字节的终端网络地址DevAddr、1字节的接收窗口设置、1字节的窗口时延以及可选的最长为16字节的通道频率设置组成。

AppNonce是由服务器生成的实际值，终端设备用其来生成NwkSkey和AppSKey，算法如下：

Join-accept消息的MIC计算如下：

Join-accept消息通过AppKey来加密，加密方法如下：

NetID总共长度为24位，其中低7位和DevAddr中的高7位一样表示网络ID，剩余的高17位由网络操作者使用。在这里网络ID唯一的标识一个网络，相邻或者重叠的网络各自的网络ID不一样。

DLsetting是对下行消息进行控制，格式如下，内容见4.4节中给出的详细描述。

5.3 本地激活
在有些情况下，终端设备可以直接本地激活，本地激活直接将终端设备绑定在特定的网络上而不经过无线激活的两个步骤。

本地激活意味着终端的网络地址DevAddr以及两个会话密匙NwkAskey、AppSKey都保存在终端设备中。且终端设备在启动前就要保存有网络相关的参数。同时还要保证NwkAskey、AppSKey两个值是唯一的，这样才能保证网络的安全。
6、CLASS B
在LoRaWAN的CLASS A类设备中，必须首先由终端设备发起上行消息后，服务器才能发送下行消息给终端设备。这种就不使用与服务器上应用程序需要主动发送数据给终端的应用场景。CLASS B类设备中，终端节点可以在设定的时间打开接收窗口，而同时也具有A类设备的特性。

B类设备这种特性是通过网关有规律地发送BEACON，让终端设备和网关之间保持时间同步，这样网关就可以控制终端在预定的时间打开额外的接收窗口（称之为ping slot）。

终端由A类设备转换为B类设备是由终端设备上的应用层来决定的。如果服务器的应用层要让终端设备从A类转换为B类设备，就要在终端设备发送了上行消息后将命令发送给终端，同时终端设备需要在应用层去解析这个命令，在LoRaWAN层是不能处理的。
6.1 网关与终端同步机制
为了让网络能支持B类设备，所有的网关必须同步地发送带有时间基准的beacon消息给终端。只有基于相同的时间基准，终端设备才能周期的打开接收窗口（ping slot）。服务器通过最近一次从网关获得的终端设备上行消息信号质量来决定由哪个网关来发起beacon。因此，如果终端设备是移动的同时检测到beacon发送者身份发生了变化，终端设备就必须发送上行消息给服务器来更新下行的路由数据库（通过那个网关发送给终端设备）。

终端设备在启动后首先以A类设备来加入到网络中，如果终端的应用层要将设备转换为B类，整个过程如下：

终端设备将LoRaWAN层调整到B类，LoRaWAN层会开始搜索beacon，如果搜索到beacon就返回BEACON_LOCK服务原语给应用层，没有搜索到就发回BEACON_NOT_FOUND给应用层。为了加快搜寻beacon的过程LoRaWAN层会主动发送BeaconTimingReq消息给服务器。
根据接收到的beacon信号强度和终端电池使用情况，终端设备应用层会选择ping slot的速度的周期，这些都是要给设备的LoRaWAN层使用的。
当设备变成B类后，在每个上行消息的mac层都要将FCTRL的Class B位置为1.这样服务器就能知道设备变成了B类。Mac层会自动打开接收窗口来接收beacon和pingslot。当终端设备成功接收到beacon后会将beacon内容和信号强度发送给应用层。在pingslot中收到下行消息时就如同A类设备接收下行消息一样。
移动终端要周期发送包含当前位置信息的上行消息给服务器来更新路由。另外终端设备的应用层也可以通过判断收到的beacon内容来判断终端是否在移动。
如果终端设备在一段时间内没有收到beacon，表明了与网络间的同步已经断了。mac层就必须通知应用层已经变为了A类设备，上行消息将不再将FCTRL的Class B置位，这样服务器就知道终端不再是B类设备。应用程序后面也可以继续周期地搜索beacon来重新变为B类设备。

在上面这个B类设备例子中，Beacon的周期是128s，同时终端设备每30ms打开一个ping slot接收上行数据。大部分的ping slot里服务器都没有数据发送下来，因此终端设置在ping slot开始后只要没检测到有radio的前导码就马上关闭接收信道。如果检测到前导码就会将无线数据接收下来，然后mac层开始检测目的地址是否正确，然后校验完整码是否正确，最后将正确的数据交给应用层处理。
6.2 上行消息格式

B类设备的上行消息格式和A类设备基本一致，在A类设备中Fctrl的RFU在B类设备中变成了Class B，表示该终端是B类设备。而下行消息AB类设备是一样的。
6.3 下行ping消息格式6.3.1 物理层格式
在B类设备中下行的ping格式和A类设备下行格式一样，但是使用的通道频率可能不同。
6.3.2 单播和组播
在B类设备中下行消息分为单播和组播，单播消息只发送给当个终端，组播消息可以同时发送给多个终端。组播内的终端设备必须要具备相同的组播地址和相关的加密密匙。在LoRaWAN的协议规定中没有制定远程组建组播组的方法，组播只能通过出场或者终端应用层来配置。
6.3.2.1 单播消息格式
B类设备ping中下行消息格式和处理方法和A类设备一样。每收到一个下行消息都要计数。
6.3.2.2 组播消息格式
组播消息格式和单播消息基本一致除了有以下一些不同之处：

组播消息不允许包含MAC命令，无论是在FOpt中还是端口号为0的消息中。因为组播消息没有单播消息类似的认证。
帧头中ACK和ADRACKReq必须为0.消息类型MType必须为无需回复的下行消息Unconfirmed Data Down。
下行消息中FPending位为1表示还有组播消息没发送，在下一个组播接收时隙继续接收，如果为0，表示下一个组播接收时隙不一定会有数据。终端设备可以根据该位来评估接收时隙的冲突优先级。

6.4 Beacon获取和追踪终端设备在由A类转换到B类之前，必须要先获取网络Beacon的时间来同步终端内部时间。

终端设备一旦转换为B类就要周期的搜寻网络Beacon来同步自己的内部时间。如果有时候没有收到beacon，那么设备就要逐渐的延长beacon和ping slot的接收窗口时间来消除时钟漂移。
6.4.1 最小Beacon-less运行时间
在终端设备没收到Beacon后，要求设备至少能保持B类状态运行120分钟（从上一次接收到Beacon开始计算）。这种没有Beacon的临时B类运行状态叫做Beacon-less状态，改状态下就要靠设备内部时钟来工作。

在Beacon-less状态下所有的单播、组播和Beacon接收时隙都要逐渐的延长来消除终端设备内部的时间漂移与网络产生的时间差。

6.4.2 Beacon-less下接收窗口调整
在这120分钟内如果终端设备收到了beacon消息，那么Beacon-less状态就要继续持续120分钟来让终端设备消除时间漂移和重置接收时隙长度。
6.4.3 减少时间漂移
终端设备可以通过接收Beacon来同步校准设备内部的时间。同时终端内部的晶振偏移是与温度直接相关的，因此终端内部还可以通过采集温度来校准时间漂移。
6.5 下行时隙 6.5.1 定义
B类终端设备在运行时必须精确的打开接收时隙来接收beacon，这一节就主要讲接收的时间要求。

两次Beacon开始之间的时间间隔叫做Beacon period，Beacon的传输是从BEACON_RESERVED开始的时候。在每个Beacon开始传输之前都有一段保护时间，防止其他时隙冲突。保护时间的长度至少为信道内最长的帧传输的时间。因此ping slot可用的时间是BEACON_RESERVED结束到下一个beacon前的保护时间开始。

Beacon实际的传输时间比BEACON_RESERVED要短的多，这段时间还可以以后留给网络管理传输报文使用。上图中的BEACON_WINDOW这段时间又被分成0-4095共4096个ping slots，每个ping slot时间为30ms。

在终端设备中通过时隙号N来计算在Beacon开始后Ton秒来打开接收窗口。最后一个ping slot开始的时间为beacon开始后的beacon_reserved + 4095*30ms = 129470ms.

6.5.1 时隙随机化
为了减少系统性的碰撞和防止窃听，终端设备获取的时隙编号是随机的，而且每个beacon_period都会改变。用于计算随机时隙值得参数如下：

在每个 beacon_period开始时终端设备和服务器都要计算新的随机值来确定接收时隙，计算时采用key值为0的AES加密算法：

终端打开接收时隙的时间为：

如果终端既有单播也有组播，那么上面的计算公式就要算两次，一次使用单播地址，一次使用组播地址。如果单播和组播的接收时隙碰撞了，优先接收组播。在服务器上如果单播和组播时隙重叠了，那么在上个多播报文上标记上FPending可以避免。

时隙的随机分配可以防止单播和组播报文在系统时隙碰撞，如果在当前beacon_period出现了碰撞，那么下个beacon_period就应该可以避免。
6.6 CLASS B MAC命令
在A类设备中所有的MAC命令对于B类设备同样适用，除此之外还有一下B类设备特有的MAC命令。

6.6.1 PingSlotInfoReq命令
终端设备使用PingSlotInfoReq命令来告知服务器自己的pingslot周期和速率，该命令只适用于单播，组播的pingslot周期和速率上报由应用层自己定义。命令格式如下：

命令数据长度为1字节，其中周期Periodicity长度为3位，周期计算公式如下，当Periodicity为0时，表示设备每1S打开一个接收pingslot，当Periodicity为7时，表示每128打开一个pingslot，这也是LoRaWAN B类支持的最大周期。

Data rate代表了终端每个pingslot的接收速率，Data rate的值和A类设备中LinkAdrReq命令中定义的值一样。

服务器在发送B类设备的下行消息前必须先知道终端的pingslot速率和周期，所以设备在从A类转换为B类之前必须先发送PingSlotInfoReq命令来告知服务器，然后服务器发送PingSlotInfoAns命令给设备。如果终端设备要改变ping'slot的设备，那么设备先必须先变A类设备，然后再发送PingSlotInfoReq给服务器，在收到服务器响应后在使用新参数工作为B类设备。
6.6.2 BeaconFreqReq 命令
  服务器发送BeaconFreqReq 命令给终端设备来修改beacon接收的信道中心频点。

频率Frequency是24位长度的无符号整形，表示方式和A类设备中NewChannelReq表示方式一样。范围是100HZ-1.67GHZ，终端设备收到命令后检查无线硬件是否支持该频段，如果不支持返回错误给服务器。

如果Frequency值为0，终端设备使用默认的beacon频段进行接收，同时还保留跳频搜寻beacon的机制。一个非0Frequency使终端设备使用该固定的频段进行beacon接收。
6.6.3 PingSlotChannelReq命令
服务器发送PingSlotChannelReq命令给终端设备来设置pingslot的信道。

频率Frequency是24位长度的无符号整形，表示方式和A类设备中NewChannelReq表示方式一样。范围是100HZ-1.67GHZ，终端设备收到命令后检查无线硬件是否支持该频段，如果不支持返回错误给服务器。如果Frequency值为0，终端设备使用默认的beacon频段进行接收。

DrRange的低4位和高4位分别表示该通道上最小和最大速率。

终端设备收到PingSlotChannelReq命令后回复PingSlotChannelAns给服务器，消息合适如下，对应位为1表示这种成功，否则失败。

6.6.4 BeaconTimingReq命令
终端发送该命令给服务器来获取下一次beacon时间和通道，该命令后面没有数据。

BeaconTimingReq & BeaconTimingAns 机制用来加速终端设备的beacon搜寻过程。如果服务器在一段时间内收到多个BeaconTimingReq 请求，他可能只会回复其中一部分请求。因此终端设备不一定在发送请求后马上就能收到响应。终端设备最好一个小时内不要发送超过一次的BeaconTimingReq请求。
6.6.5 BeaconTimingAns命令
服务器发送该命令来相应BeaconTimingReq，格式如下：

Delay是16位无符号整数，从该下行命令结束到下一次beacon开始的时间RTime:

在多个beacon发送通道的网络中，channel代表下一次beacon发送的通道。对于beacon通道固定的网络，该值为0.
7、BEACON7.1 BEACON 物理层结构
网关设备除了转发终端设备与服务器间的数据外，还要周期性的（BEACON_INTERVAL）发送Beacon来给终端设备和网关提供终端同步机制。所有的Beacon在无线芯片的物理层都是采用的隐式模式，发送出去的报文不包括头和CRC只有前导码和数据段。格式如下：

前导码长度为10，beacon的长度与无线芯片的物理层有关，采用不同频段对应的beacon长度可能会有所不同。
7.2 Beacon格式
   Beacon的BCNPayload部分由网络部分和网关相关部分组成，如下表所示：

网络相关部分由NetID、Time和CRC组成，其中NetID唯一的标识了发送Beacon的网络，时间戳Time是以秒为单位的标准格林威治时间（1970-1-1 00:00:00开始），8位或者16位的CRC校验取决于物理层的设置。CRC-16计算NETID和Time的校验，CRC-8取CRC-16的低8位。

终端可能会收到多个网关发出的Beacon，网关相关部分就是为了让终端来区分不同的网关。当包括RFU时应该填0，同样网关相关部分GwSpecific和RFU还有CRC-16来保护。

如下是一个US900的beacon：

空中传播的顺序如下：

移动的B类终端还要解析Beacon中网关相关部分，当检测到不同网关的Beacon时还要通知服务器自己位置移动了。

当网络中有多个网关时，多个网关都会同时发送beacon，如果终端设备在多个网关的覆盖重叠区内，终端节点会收到多个beacon，而信号最强的网关发出的Beacon更容易被接受到。
7.3 GwSpecific格式
   GwSpecific的格式如下：

其中InfoDesc表示了Info数据段应该怎么解读。

对于只有一个全向GPS天线的网关，InfoDesc的值为0广播的是该GPS坐标。对于有3向天线的网关，InfoDesc等于0、1、2分别代表三个天线的GPS坐标值。Info定义如下：

Info长度为6字节，分别表示网关地理位置的GPS经度和纬度。南北纬度Lat由24位的有符号数表示，-223 代表南纬90度，223 代表北纬90度，赤道对应的值为0。东西经度Lng由24位的有符号数表示，-223 代表西经180度，223 代表东经180度，格林威治对应的值为0。
7.4 Beacon时间
Beacon每128s发送一次，每一次发送的时间为BT = k * 128 +NWKID + TBeaconDelay，BT为世界标准时间UTC 1970-1-1起经过的秒数。这里加上NWKID也为了让不同网络的Beacon不会再时间上冲突。

这里的TBeaconDelay是网络中协定好的时延，范围在0-50ms，在网络中所有的网关都要按照TBeaconDelay时延后再发送beacon。所有的终端设备ping slot用的参考时间都是beacon的发送时间，因此服务器的下行报文时间也要把TBeaconDelay算进去。
7.5 服务器下行路由更新
当服务器要通过CLASS B的下行slot给终端设备发送消息时，首先发给离终端设备最近的路由器（通过终端设备最近一次的上行消息确认），再由路由器转发给终端设备。因此服务器上必须保存有终端设备的大致位置。

当B类设备位置发生了变化，就需要定期发送上行消息给服务器来让服务器更新新的路由。这个消息可以是confirmed或者unconfirmed消息，消息中app数据段可以为空。终端设备有一下两种更新路由方案。

周期发送上行消息，这是最简单地方法，终端设备不用解析Beacon中网关相关部分。适用于低速移动或者静止的终端设备，对上行报文的周期也没有特殊要求。
当检测到Beacon中网关发送改变时发送上行报文。当检测到网关发生变化时随机时延一个时间（0-120）发送上行消息给服务器。

如果服务器没有及时收到终端设备的路由更新，会造成服务器的下行slot终端设备收不到下行消息。这种情况就只有等终端设备下一次发送上行消息才能重新更新路由。
8、CLASS C
当终端设备有充足的电源提供，不用担心耗电问题时，设备可以不用减少接收时间来省电。这时设备就可以工作在C类。

C类设备不具备B类设备的特性，更类似于A类设备。C类设备中会尽可能地打开RX2接收窗口，当终端设备没有在发送或者打开RX1窗口接收时就一直打开RX2接收。并没有特殊的消息告诉服务器终端设备为C类，在节点加入网络时服务器的appserver中就要知道该终端设备为C类。（通过appeui确定或者deveui确定）
8.1 C类设备的第二个接收窗口

在C类设备中与A类设备一样在发送上行消息后都会有两个接收窗口，但是在c类设备中在有需要发送上行消息之前都不会关闭第二个接收窗口，同时在发送完成后，第一个接收窗口打开前也会打开RX2，这样在任何时间都有可能在RX2上接收到下行消息。
8.2 C类设备的组播下行消息
与B类设备类似，C类设备也有可能会接收到组播下行消息。组播地址和APPSKEY和NWKSKEY都由应用层来实现。同样还有一下对组播消息的限制。