LoRaWAN协议中文翻译

LoRaWAN网络通常采用星型拓扑结构，由拓扑中的网关来转发终端与后台网络服务器间的消息。网关通过标准IP连接来接入网络服务器，而终端则通过单跳的 LoRa 或者 FSK 来和一个或多个网关通讯。虽然主要传输方式是终端上行传输给网络服务器，但所有的传输通常都是双向的。

终端和网关间的通讯被分散到不同的信道频点和数据速率上。数据速率的选择需要权衡距离和消息时长两个因素，使用不同数据速率的设备互不影响。LoRa的数据速率范围可以从 0.3kbps 到 50kbps。为了最大程度地延长终端的电池寿命和扩大网络容量，LoRa网络使用速率自适应(ADR)机制来独立管理每个终端的速率和RF输出。

虽然每个设备可以在任意信道，任意时间，发送任意数据，但需要注意遵守如下规定：
终端的每次传输都使用伪随机方式来改变信道。频率的多变使得系统具有更强的抗干扰能力。
终端要遵守相应频段和本地区的无线电规定中的发射占空比要求。
终端要遵守相应频段和本地区的无线电规定中的发射时长要求。
发射占空比，意思是发射时长占总时长的比例。按照无线电规定，每个设备不能疯狂发射霸占信道，总得给别人一点机会。

所有的LoRaWAN设备都必须至少实现 Class A 功能

文档约定
MAC命令的格式写作 LinkCheckReq (粗斜体)，位和位域的格式写作 FRMPayload (粗体)，常量的格式写作 RECEIVE_DELAY1，变量的格式写作 N。

所有多字节字段的字节序均采用小端模式
EUI 是8字节字段，采用小端模式传输
默认所有RFU保留位都设为0

LoRa网络包含基础LoRaWAN（称之为Class A）和可选功能（Class B，Class C）

双向传输终端(Class A)： Class A 的终端在每次上行后都会紧跟两个短暂的下行接收窗口，以此实现双向传输。传输时隙是由终端在有传输需要时安排，附加一定的随机延时(即ALOHA协议)。这种Class A 操作是最省电的，要求应用在终端上行传输后的很短时间内进行服务器的下行传输。服务器在其他任何时间进行的下行传输都得等终端的下一次上行。

 划定接收时隙的双向传输终端(Class B)： Class B 的终端会有更多的接收时隙。除了Class A 的随机接收窗口，Class B 设备还会在指定时间打开别的接收窗口。为了让终端可以在指定时间打开接收窗口，终端需要从网关接收时间同步的信标 Beacon。这使得服务器可以知道终端正在监听。

 最大化接收时隙的双向传输终端(Class C)： Class C 的终端基本是一直打开着接收窗口，只在发送时短暂关闭。Class C 的终端会比 Class A 和 Class B
 更加耗电，但同时从服务器下发给终端的时延也是最短的。

PHY 帧格式

LoRa 有上行消息和下行消息。

3.1 上行消息
上行消息是由终端发出，经过一个或多个网关转发给网络服务器。

上行消息使用 LoRa 射频帧的严格模式，消息中含有 PHDR 和 PHDR_CRC 。载荷有CRC校验来保证完整性。

PHDR，PHDR_CRC 及载荷 CRC 域都通过射频收发器加入。

上行 PHY:
Preamble  PHDR  PHDR_CRC  PHYPayload CRC

下行消息
下行消息是由网络服务器发出，经过单个网关转发给单个终端。

下行消息使用射频帧的严格模式，消息中包含 PHDR 和 PHDR_CRC。

下行 PHY:
Preamble  PHDR  PHDR_CRC  PHYPayload

接收窗口
每个上行传输后终端都要开两个短的接收窗口。接收窗口开始时间的规定，是以传输结束时间为参考。

3.3.1 第一接收窗口的信道，数据速率和启动。
第一接收窗口 RX1 使用的频率和上行频率有关，使用的速率和上行速率有关。RX1 是在上行调制结束后的 RECEIVE_DELAY1 秒打开。上行和 RX1 时隙下行速率的关系是按区域规定，详细描述在[LoRaWAN地区参数]文件中。默认第一窗口的速率是和最后一次上行的速率相同。

3.3.2 第二接收窗口的信道，数据速率和启动。
第二接收窗口 RX2 使用一个固定可配置的频率和数据速率，在上行调制结束后的 RECEIVE_DELAY2 秒打开。频率和数据速率可以通过 MAC 命令(见 第5章)。默认的频率和速率是按区域规定，详细描述在[LoRaWAN地区参数]文件中。

3.3.3 接收窗口的持续时间
接收窗口的长度至少要让终端射频收发器有足够的时间来检测到下行的前导码。

3.3.4 接收方在接收窗口期间的处理
如果在任何一个接收窗口中检测到前导码，射频收发器需要继续激活，直到整个下行帧都解调完毕。如果在第一接收窗口检测到数据帧，且这个数据帧的地址和MIC校验通过确认是给这个终端，那终端就不必开启第二个接收窗口。

3.3.5 网络发送消息给终端
如果网络想要发一个下行消息给终端，它会精确地在两个接收窗口的起始点发起传输。

3.3.6 接收窗口的重要事项
终端在第一或第二接收窗口收到下行消息后，或者在第二接收窗口阶段，不能再发起另一个上行消息。

3.3.7 其他协议的收发处理
节点在LoRaWAN收发窗口阶段可以收发其他协议，只要终端能满足当地要求以及兼容LoRaWAN协议。

数据帧头					DevAddr	FCtrl	FCnt	FOpts
数据帧	Preamble	PHDR	PHDR_CRC	MHDR	FHDR				FPort	FRMPayload	MIC	CRC
MAC层	Preamble	PHDR	PHDR_CRC	MHDR	MACPayload						MIC	CRC
PHY层	Preamble	PHDR	PHDR_CRC	PHYPayload

ADR(速率自适应)机制: 一旦使能了FCtrl中的ADR位，距离近信号好的节点用高速率，距离远信号弱的节点用低速率，不小心被调高了速率，则自动降下来。这样，尽可能地提高了传输速率，也有效提高了网络容量

可同时携带数据和命令的MAC帧: LoRaWAN协议设计上利用FOpts把数据和命令揉在一个MAC帧里，这样可以提高交互效率，有效地降低功耗。

\src\mac\LoRaMac.c定义了 MAC帧格式的字段
1. MHDR，消息类型是confirm还是unconfirm以及Join-Req的消息类型。 LoRaMacMcpsRequest() 和 LoRaMacMlmeRequest() 这两个函数。

2. MACPayload 的组帧都在 PrepareFrame() 这个函数中处理，将macHdr和macPayload的fCtrl、FPort、FRMPayload都传递进去，完成整个MAC层的数据组帧。

LoRaMacBuffer就存放了MACPayload的数据，这个变量的组帧和协议字段定义是一一对应。MACPayload的组帧处理，在大流程上是对join和数据两种类型的帧分别处理，用两个case分开。

FHDR中的DevAddr(4Byte)

FHDR中的FCtrl:
  fCtrl.Bits.Adr = AdrCtrlOn;
  AdrAckReq 位段，在长期失联情况下会发送AdrAckReq确认链路
   F0ptsLen 位段

FHDR中的FCnt
  UpLinkCounter (2B) 这个UpLinkCounter会在物理层发送完成后会按照协议进行累加。可以看到这是个32位计数器，按照协议规定，“如果采用32位帧计数，FCnt就对应计数器32位的16个低有效位”。下行的也类似

FHDR中的FOpts
  把MAC命令放入F0pts中，并且更新F0ptsLen。MAC命令，要么使用非零的FPort来和数据一起传输，要么使用FPort0来单独传输。

MACPayload中的FPort
  在应用层一直传递进去的，协议栈默认是用了端口2。这个是后期大家在应用时要调整的，类似于IP端口，不同的端口对应不同的服务。

MAC解析
  在函数 PrepareFrame()的最后是调用LoRaMacComputeMic() 计算出整个MAC层的校验码

MAC命令，要么使用FPort0来单独传输，要么使用非零的FPort来和数据一起传输。

LoRaWAN出于网络管理需要，提出了9条MAC命令. CLAA(中国LoRa应用联盟)在9条命令以外还扩充了一些MAC命令

/*!
 * LoRaMAC note MAC commands
 *
 * LoRaWAN Specification V1.0.1, chapter 5, table 4
 */
typedef enum eLoRaMacMoteCmd
{
    /*!
     * LinkCheckReq
     */
    MOTE_MAC_LINK_CHECK_REQ = 0x02,
    /*!
     * LinkADRAns
     */
    MOTE_MAC_LINK_ADR_ANS = 0x03,
    /*!
     * DutyCycleAns
     */
    MOTE_MAC_DUTY_CYCLE_ANS = 0x04,
    /*!
     * RXParamSetupAns
     */
    MOTE_MAC_RX_PARAM_SETUP_ANS = 0x05,
    /*!
     * DevStatusAns
     */
    MOTE_MAC_DEV_STATUS_ANS = 0x06,
    /*!
     * NewChannelAns
     */
    MOTE_MAC_NEW_CHANNEL_ANS = 0x07,
    /*!
     * RXTimingSetupAns
     */
    MOTE_MAC_RX_TIMING_SETUP_ANS = 0x08,
}LoRaMacMoteCmd_t;



/*!
 * LoRaMAC server MAC commands
 *
 * LoRaWAN Specification V1.0.1 chapter 5, table 4
 */
typedef enum eLoRaMacSrvCmd
{
    /*!
     * LinkCheckAns
     */
    SRV_MAC_LINK_CHECK_ANS = 0x02,
    /*!
     * LinkADRReq
     */
    SRV_MAC_LINK_ADR_REQ = 0x03,
    /*!
     * DutyCycleReq
     */
    SRV_MAC_DUTY_CYCLE_REQ = 0x04,
    /*!
     * RXParamSetupReq
     */
    SRV_MAC_RX_PARAM_SETUP_REQ = 0x05,
    /*!
     * DevStatusReq
     */
    SRV_MAC_DEV_STATUS_REQ = 0x06,
    /*!
     * NewChannelReq
     */
    SRV_MAC_NEW_CHANNEL_REQ = 0x07,
    /*!
     * RXTimingSetupReq
     */
    SRV_MAC_RX_TIMING_SETUP_REQ = 0x08,
}LoRaMacSrvCmd_t;

MAC命令的接收处理
OnRadioRxDone()携带着MAC帧进来，经过层层筛选，最终到达ProcessMacCommands()来处理MAC命令。
 这里代码中涉及的两种处理方式，可以跟协议对应起来：port = 0时，MAC命令放在FRMPayload中，需要先解密再处理；port非零时，MAC命令放在fopts中。

if( port == 0 )
{
    if( fCtrl.Bits.FOptsLen == 0 )
    {
        LoRaMacPayloadDecrypt( payload + appPayloadStartIndex,
                               frameLen,
                               nwkSKey,
                               address,
                               DOWN_LINK,
                               downLinkCounter,
                               LoRaMacRxPayload );

        // Decode frame payload MAC commands
        ProcessMacCommands( LoRaMacRxPayload, 0, frameLen, snr );
    }
} else {
    if( fCtrl.Bits.FOptsLen > 0 )
    {
        // Decode Options field MAC commands. Omit the fPort.
        ProcessMacCommands( payload, 8, appPayloadStartIndex - 1, snr );
    }
}

MAC命令的发送及回复
MAC命令的发送及回复处理都在这个函数中，AddMacCommand()。

协议栈对MAC命令发送的处理还是比较简单的，都是放在Fopts中来传输，都在这个15字节的MacCommandsBuffer中。

节点加网:
1. 如果是空中激活OTAA，则需要准备 DevEUI，AppEUI，AppKey 这三个参数来join，即设备自身MAC地址和要使用的应用(应用ID和密钥)。
2. 如果是ABP激活，则直接配置 DevAddr，NwkSKey，AppSKey 这三个LoRaWAN最终通讯的参数，不再需要join流程。在这种情况下，这个设备是可以直接发应用数据的。

商用的LoRaWAN网络一般都是走OTAA流程，这样安全性才得以保证。

激活处理  \src\mac\main.c. 用一个宏(OVER_THE_AIR_ACTIVATION)分开两段，分别对应两种激活方式。

case DEVICE_STATE_JOIN:
{
#if( OVER_THE_AIR_ACTIVATION != 0 )
    MlmeReq_t mlmeReq;

    // Initialize LoRaMac device unique ID
    BoardGetUniqueId( DevEui );

    mlmeReq.Type = MLME_JOIN;

    mlmeReq.Req.Join.DevEui = DevEui;
    mlmeReq.Req.Join.AppEui = AppEui;
    mlmeReq.Req.Join.AppKey = AppKey;

    if( NextTx == true )
    {
        LoRaMacMlmeRequest( &mlmeReq );
    }
    DeviceState = DEVICE_STATE_SLEEP;
#else
    // Choose a random device address if not already defined in Comissioning.h
    if( DevAddr == 0 )
    {
        // Random seed initialization
        srand1( BoardGetRandomSeed( ) );

        // Choose a random device address
        DevAddr = randr( 0, 0x01FFFFFF );
    }

    mibReq.Type = MIB_NET_ID;
    mibReq.Param.NetID = LORAWAN_NETWORK_ID;
    LoRaMacMibSetRequestConfirm( &mibReq );

    mibReq.Type = MIB_DEV_ADDR;
    mibReq.Param.DevAddr = DevAddr;
    LoRaMacMibSetRequestConfirm( &mibReq );

    mibReq.Type = MIB_NWK_SKEY;
    mibReq.Param.NwkSKey = NwkSKey;
    LoRaMacMibSetRequestConfirm( &mibReq );

    mibReq.Type = MIB_APP_SKEY;
    mibReq.Param.AppSKey = AppSKey;
    LoRaMacMibSetRequestConfirm( &mibReq );

    mibReq.Type = MIB_NETWORK_JOINED;
    mibReq.Param.IsNetworkJoined = true;
    LoRaMacMibSetRequestConfirm( &mibReq );

    DeviceState = DEVICE_STATE_SEND;
#endif
    break;
}

参数配置. \src\apps\LoRaMac\classA\硬件平台\Comissioning.h

/*!
 * Mote device IEEE EUI (big endian)
 *
 * \remark In this application the value is automatically generated by calling
 * BoardGetUniqueId function
 */
#define LORAWAN_DEVICE_EUI                          { IEEE_OUI, 0x00, 0x00, 0x00, 0x00, 0x00 }

/*!
 * Application IEEE EUI (big endian)
 */
#define LORAWAN_APPLICATION_EUI                     { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
</code></pre>
<pre><code>
/*!
 * AES encryption/decryption cipher application key
 */
#define LORAWAN_APPLICATION_KEY                     { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }

/*!
 * Current network ID
 */
#define LORAWAN_NETWORK_ID ( uint32_t )0

/*!
 * Device address on the network (big endian)
 *
 * \remark In this application the value is automatically generated using
 * a pseudo random generator seeded with a value derived from
 * BoardUniqueId value if LORAWAN_DEVICE_ADDRESS is set to 0
 */
#define LORAWAN_DEVICE_ADDRESS ( uint32_t )0x00000000

/*!
 * AES encryption/decryption cipher network session key
 */
#define LORAWAN_NWKSKEY                             { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }

/*!
 * AES encryption/decryption cipher application session key
 */
#define LORAWAN_APPSKEY                             { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C }

LoRaWAN Class B层，这是为电池节点优化设计的，不管它是移动还是固定在某个位置。

Class B 的终端必须执行如下操作，为了获得服务端发起的下行消息，终端必须按要求开启一个固定间隔的接收窗口。

LoRaWAN Class B 就是在终端上增加一个经过同步的接收窗口。

LoRaWAN Class A 的限制之一就是终端发送数据使用的Aloha算法；这使得客户应用程序或者服务端不能在确定时间内联系上终端。Class B 的目的就是在Class A 终端随机上行后的接收窗口之外，让终端也能在可预见的时间内开启接收。Class B 是让网关周期发送信标来同步网络中的所有终端，为此终端需要在周期时隙的确定时间点打开一个短的接收窗口(叫做“ping slot”)。

 注意：是否要从Class A 切换到 Class B，这个要在终端的应用层进行处理。如果打算从网络端将Class A 切换到 Class B，客户程序只能利用终端 Class A的上行包来反馈一个下行包给节点，需要应用层上处理来识别这个请求 - 这个处理不在LoRaWAN层面。

下行同步网络的原理

对于一个支持ClassB的网络，所有网关必须发出同步广播一个信标，以给所有终端提供一个参考时间。基于这个时间参考，终端可以周期性地打开接收窗口，下文称之为“ping slot”，这个“ping slot”被网络建设者用于发起下行通信。网络使用ping slots其中之一来发起下行通讯的行为，称之为“ping”。用来发起下行通讯的网关，是network server根据终端最近一次上行包的信号传输质量来选择的。基于此，如果终端根据广播的信标帧发现网络发生了切换，它必须发出上行帧给network server，以使server端更新下行路径的数据库。

所有终端启动后，以Class A来加入网络。之后终端应用层可以切换到Class B。通过以下步骤来实现：

 终端应用层请求LoRaWAN层切换到Class B模式。终端的LoRaWAN层搜索信标帧，如果搜索到并且锁定了信标帧，那么就向应用层返回BEACON_LOCKED的服务原语，反之则返回BEACON_NOT_FOUND的服务原语。为了促进信标帧的搜索，LoRaWAN层可以使用稍后介绍的 “BeaconTimingReq” 消息。

 基于信标的强度和电池寿命，终端的应用层选择ping slot所需的数据速率和周期，这可以从LoRaWAN层获取到。

 一旦处于Class B模式，MAC层需要在所有上行帧的FCTRL字段中，将Class B的位域置为1。这个位用来通知server，设备已经切换到Class B模式。MAC层会给每个beacon和ping时隙来安排接收时隙。当成功接收信标，终端的LoRaWAN层将会转发beacon内容给应用层，同时携带测量的射频信号强度。终端的LoRaWAN层在安排beacon和ping时隙时，需要考虑可能的最大时钟偏移。当在ping时隙成功解调出下行帧，它的处理和Class A 的方式一样。

 移动的终端，必须周期性地通知network server其位置信息，以便确定下行路径。这是通过发送普通的(可能是空包)“unconfirmed”或者“confirmed”上行包来实现。终端的LoRaWAN层需要将Class B的位域置为1。如果应用程序通过解析beacon内容来判断节点移动，那将会使得这个事情变得更高效。这种情况下终端需要在beacon接收后随机延时一段时间(具体见章节15.5)再上行，避免上行帧冲突。

 如果在指定周期内没有接收到beacon(具体见章节12.2)，则意味着网络同步丢失。MAC层必须通知应用层切换回Class A。随后终端在上行帧的LoRaWAN层中将不再设置Class B的位域，用以通知network server终端不再处于 Class B 模式。终端的应用程序可以周期性地尝试切换回 Class B。在做这个处理时要先探寻下beacon。

例如，指定beacon周期是128秒，ping接收时隙的周期是32秒。大部分时候server并没有使用ping时隙，因此终端可以在接入信道时监听下是否有前导码，如果没有则立即关闭接收窗口。如果监测到前导码，则射频会持续接收，直到下行帧解调完毕。MAC层随后处理数据帧，检查确认地址域匹配和MIC校验有效之后再转发给应用层。

 

Class B 模式的上行帧

Class B 模式的上行帧和 Class A 的基本一样，除了帧头Fctrl字段的RFU位域有所不同。在 Class A 上行帧中这个位没有使用(RFU)，而在 Class B 中有使用。

Bit#	7	6	5	4	[3..0]
FCtrl bits	ADR	ADRACKReq	ACK	Class B	FOptsLen

上行帧中的 Class B 位域置为1，用于通知network server设备已切换到 Class B 模式，准备好接收下行ping包。

下行帧的FPending位域的定义是不变的，仍然和Class A的定义一样，表示server有多个下行帧要下发，设备应当继续接收。

下行ping帧格式(仅Class B)

11.1 物理帧格式

下行 Ping 使用和 Class A 下行帧相同的帧格式，但必须采用一个不同的信道频率计划。

11.2 单播和多播 MAC 消息

消息可以是单播和多播形式。单播消息发给单个终端，而多播消息发给多个终端。一个多播组里的设备共享相同的多播地址。LoRaWAN Class B 协议中并没有明确规定如何去建立这样的多播组，以及如何安全地分配多播密钥。这必须通过 节点个性化设置 或者 通过应用层 来实现。

11.2.1 单播 MAC 消息格式

单播下行 Ping 帧的 MAC 载荷格式和 Class A 的定义一样。终端的处理也采用相同的方式。同时也采用相同的帧计数，在收到 Class B ping 时隙或者 Class A 应答时隙时都进行递增处理。

11.2.2 多播 MAC 消息格式

多播帧和单播帧大部分都一样，仅有一些区别：

• 不允许携带 MAC 命令，既不能在 FOpt 字段里，也不能 port 0 时的载荷里携带，因为多播下行不像单播帧那样具备认证鲁棒性。
• ACK 和 ADRACKReq 的位必须为 0 。MType 字段必须为 “Unconfirmed Data Down”。
• FPending 位表示还有数据要传输。如果设置了这个位，将会在下个多播接收时隙里传输数据帧。如果没设置这个位，则不确定下个多播接收时隙是否会传输数据。这个位可以让终端来评估正在冲突的接收时隙的优先级。

Class C - 持续接收的终端

具备Class C 能力的终端，通常应用于供电充足的场景，因此不必精简接收时间。

Class C 的终端不能执行 Class B 。

Class C 终端会尽可能地使用 RX2 窗口来监听。按照 Class A 的规定，终端是在 RX1 无数据收发才进行 RX2 接收。为了满足这个规定，终端会在上行发送结束和 RX1 接收窗口开启之间，打开一个短暂的 RX2 窗口，一旦 RX1 接收窗口关闭，终端会立即切换到 RX2 接收状态； RX2 接收窗口会程序打开，除非终端需要发送其他消息。

 注意：没有规定节点必须要告诉服务端它是 Class C 节点。这完全取决于服务端的应用程序，它们可以在 join 流程通过协议交互来获知是否是 Class C 节点。


17.1 Class C 的第二接收窗口持续时间
Class C 设备执行和 Class A 一样的两个接收窗口，但它们没有关闭 RX2 ，除非他们需要再次发送数据。因此它们几乎可以在任意时间用 RX2 来接收下行消息，包括MAC命令和ACK传输的下行消息。另外在发送结束和 RX1 开启之间还打开了一个短暂的RX2窗口。


17.2 Class C 对多播下行的处理
和 Class B 类似，Class C 设备也可以接收多播下行帧。多播地址和相关的 NWKSKEY 及 APPSKEY 都需要从应用层获取。Class C 多播下行帧也有相同的限制：

 不允许携带MAC命令，既不能放在FOpts域中，也不能放在 port 0 的 payload 中，因为多播下行无法像单播帧那样具备相同的鲁棒性。

 ACK 和 ADRACKReq 位必须要为0。MType 域需要为  Unconfirmed Data Down 类型的数值。

 FPending 位表明有更多的多播数据要发送。考虑到 Classs C 设备在大部分时间处于接收状态，FPending位不触发终端的任何特殊行为。