Lorawan协议说明书.docx

第1章 介绍
本文档描述了LoRaWAN网络协议，是针对电池供电的终端设备(不管移动还是固定位置)进行优化的一套网络协议。
LoRaWAN网络通常采用星型拓扑结构，由拓扑中的网关来转发终端与后台网络服务器间的消息。网关通过标准IP连接来接入网络服务器，而终端则通过单跳的 LoRa 或者 FSK 来和一个或多个网关通讯。虽然主要传输方式是终端上行传输给网络服务器，但所有的传输通常都是双向的。
终端和网关间的通讯被分散到不同的信道频点和数据速率上。数据速率的选择需要权衡距离和消息时长两个因素，使用不同数据速率的设备互不影响。LoRa的数据速率范围可以从 0.3kbps 到 50kbps。为了最大程度地延长终端的电池寿命和扩大网络容量，LoRa网络使用速率自适应(ADR)机制来独立管理每个终端的速率和RF输出。
虽然每个设备可以在任意信道，任意时间，发送任意数据，但需要注意遵守如下规定：
· 终端的每次传输都使用伪随机方式来改变信道。频率的多变使得系统具有更强的抗干扰能力。
· 终端要遵守相应频段和本地区的无线电规定中的发射占空比要求。
· 终端要遵守相应频段和本地区的无线电规定中的发射时长要求。
twowinter注：发射占空比，意思是发射时长占总时长的比例。按照无线电规定，每个设备不能疯狂发射霸占信道，总得给别人一点机会。
这份文档主要讲述协议细节，一些基于各地区规定的操作参数，例如发射占空比和发射时长等，在另一份文档[LoRaWAN地区参数]中做具体描述。将这份文档分开，是为了加入新地区参数时不影响基础的协议规范。
1.1 LoRaWAN Classes
所有的LoRaWAN设备都必须至少实现本文档描述的 Class A 功能。另外也可以实现本文档中描述的 Class B 和 Class C 及后续将定义的可选功能。不管怎么样，设备都必须兼容 Class A。
1.2 文档约定
MAC命令的格式写作 LinkCheckReq (粗斜体)，位和位域的格式写作 FRMPayload (粗体)，常量的格式写作 RECEIVE_DELAY1，变量的格式写作 N。
在本文档中，
· 所有多字节字段的字节序均采用小端模式
· EUI 是8字节字段，采用小端模式传输
· 默认所有RFU保留位都设为0
第2章 LoRaWAN Classes 类型介绍
LoRa 是由Semtech面向长距离、低功耗、低速率应用而开发的无线调制技术。本文档中，将 Class A 基础上实现了更多功能的设备称为“更高 class 终端”。
2.1 LoRaWAN Classes
LoRa网络包含基础LoRaWAN（称之为Class A）和可选功能（Class B，Class C）:

图1.LoRaWAN Classes
· 双向传输终端(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 
更加耗电，但同时从服务器下发给终端的时延也是最短的。
2.2 文档范围
这份LoRaWAN协议还描述了与 Class A 不同的其他 Class 的额外功能。更高 Class 的终端必须满足 Class A 定义的所有功能。
注意：物理层帧格式，MAC帧格式，以及协议中更高 class 和 Class A 相同的内容都写在了 Class A 部分，避免内容重复。
第3章 PHY 帧格式
LoRa 有上行消息和下行消息。
3.1 上行消息
上行消息是由终端发出，经过一个或多个网关转发给网络服务器。
上行消息使用 LoRa 射频帧的严格模式，消息中含有 PHDR 和 PHDR_CRC 。载荷有CRC校验来保证完整性。
PHDR，PHDR_CRC 及载荷 CRC 域都通过射频收发器加入。
上行 PHY:
Preamble
PHDR
PHDR_CRC
PHYPayload
CRC
图2.上行PHY帧格式
3.2 下行消息
下行消息是由网络服务器发出，经过单个网关转发给单个终端。
下行消息使用射频帧的严格模式，消息中包含 PHDR 和 PHDR_CRC。
下行 PHY:
Preamble
PHDR
PHDR_CRC
PHYPayload
图3.下行PHY帧格式
3.3 接收窗口
每个上行传输后终端都要开两个短的接收窗口。接收窗口开始时间的规定，是以传输结束时间为参考。

图4.终端接收时隙的时序图
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协议。
2 梳理解析
LoRaWAN第3章，主要是讲了接收窗口这回事，只要记住张图就行。

目前RX1一般是在上行后1秒开始，RX2是在上行后2秒开始。
3 源码分析
3.1 源码流程
在梳理这章节的对应代码时，自己手动做了张思维导图。有时是这样，代码再有层次感，也不及一个图。好，请收下。

3.2 发送完成就开始RX1和RX2延时
static void OnRadioTxDone( void )
{
...
// Setup timers
if( IsRxWindowsEnabled == true )
{
TimerSetValue( &RxWindowTimer1, RxWindow1Delay );
TimerStart( &RxWindowTimer1 );
if( LoRaMacDeviceClass != CLASS_C )
{
TimerSetValue( &RxWindowTimer2, RxWindow2Delay );
TimerStart( &RxWindowTimer2 );
}
if( ( LoRaMacDeviceClass == CLASS_C ) || ( NodeAckRequested == true ) )
{
TimerSetValue( &AckTimeoutTimer, RxWindow2Delay + ACK_TIMEOUT +
randr( -ACK_TIMEOUT_RND, ACK_TIMEOUT_RND ) );
TimerStart( &AckTimeoutTimer );
}
}
...
}
3.3 接收窗口的射频处理
从上面一步，我们已经清晰的知道，对应的处理肯定是在OnRxWindow1TimerEvent和OnRxWindow2TimerEvent中。 
这两个接收窗口的处理，会对速率和信道进行设置，按照LoRaWAN协议中文版_配套文件 地区参数(物理层) 中对各地区的要求分别进行处理。
比如这个470的处理，对上行信道对48取余得到下行信道。
RxWindowSetup( LORAMAC_FIRST_RX1_CHANNEL + ( Channel % 48 ) * LORAMAC_STEPWIDTH_
第4章 MAC帧格式
LoRa所有上下行链路消息都会携带PHY载荷，PHY载荷以1字节MAC头(MHDR)开始，紧接着MAC载荷(MACPayload)，最后是4字节的MAC校验码(MIC)。
射频PHY层：
Preamble
PHDR
PHDR_CRC
PHYPayload
CRC
图5.射频PHY结构(注意 CRC只有上行链路消息中存在)
PHY载荷：
MHDR
MACPayload
MIC
或者
MHDR
Join-Request
MIC
或者
MHDR
Join-Response
MIC
图6.PHY载荷结构
MAC载荷：
FHDR
FPort
FRMPayload
图7.MAC载荷结构
FHDR：
DevAddr
FCtrl
FCnt
FOpts
图8.帧头结构
图9.LoRa帧格式元素(即图5~8)
4.1 MAC层(PHYPayload)
Size (bytes)
1
1..M
4
PHYPayload
MHDR
MACPayload
MIC
MACPayload字段的最大长度M，在第6章有详细说明。
4.2 MAC头(MHDR字段)
Bit#
7..5
4..2
1..0
MHDR bits
MType
RFU
Major
MAC头中指定了消息类型(MType)和帧编码所遵循的LoRaWAN规范的主版本号(Major)。
4.2.1 消息类型(MType位字段)
LoRaWAN定义了六个不同的MAC消息类型：join request, join accept, unconfirmed data up/down, 以及 confirmed data up/down 。
MType
描述
000
Join Request
001
Join Accept
010
Unconfirmed Data Up
011
Unconfirmed Data Down
100
Confirmed Data Up
101
Confirmed Data Down
110
RFU
111
Proprietary
表1.MAC消息类型
· 4.2.1.1 Join-request and join-accept 消息
join-request和join-accept都是用在空中激活流程中，具体见章节6.2
· 4.2.1.2 Data messages
Data messages 用来传输MAC命令和应用数据，这两种命令也可以放在单个消息中发送。 
Confirmed-data message 接收者需要应答。 
Unconfirmed-data message 接收者则不需要应答。 
Proprietary messages 用来处理非标准的消息格式，不能和标准消息互通，只能用来和具有相同拓展格式的消息进行通信。
不同消息类型用不同的方法保证消息一致性，下面会介绍每种消息类型的具体情况。
4.2.2 数据消息的主版本(Major位字段)
Major位字段
描述
00
LoRaWAN R1
01..11
RFU
表2.Major列表
注意：Major定义了激活过程中(join procedure)使用的消息格式（见章节6.2）和MAC Payload的前4字节（见第4章）。终端要根据不同的主版本号实现不同最小版本的消息格式。终端使用的最小版本应当提前通知网络服务器。
4.3 MAC载荷(MACPayload)
MAC载荷，也就是所谓的“数据帧”，包含：帧头（FHDR）、端口（FPort）以及帧载荷(FRMPayload），其中端口和帧载荷是可选的。
4.3.1 帧头(FHDR)
FHDR是由终端短地址(DevAddr)、1字节帧控制字节(FCtrl)、2字节帧计数器(FCnt)和用来传输MAC命令的帧选项(FOpts，最多15个字节)组成。
Size(bytes)
4
1
2
0..15
FHDR
DevAddr
FCtrl
FCnt
FOpts
FCtrl在上下行消息中有所不同，下行消息如下：
Bit#
7
6
5
4
[3..0]
FCtrl bits
ADR
ADRACKReq
ACK
FPending
FOptsLen
上行消息如下：
Bit#
7
6
5
4
[3..0]
FCtrl bits
ADR
ADRACKReq
ACK
RFU
FOptsLen
· 4.3.1.1 帧头中 自适应数据速率 的控制(ADR, ADRACKReq in FCtrl)
LoRa网络允许终端采用任何可能的数据速率。LoRaWAN协议利用该特性来优化固定终端的数据速率。这就是自适应数据速率(Adaptive Data Rate (ADR))。当这个使能时，网络会优化使得尽可能使用最快的数据速率。
移动的终端由于射频环境的快速变化，数据速率管理就不再适用了，应当使用固定的数据速率。
如果ADR的位字段有置位，网络就会通过相应的MAC命令来控制终端设备的数据速率。如果ADR位没设置，网络则无视终端的接收信号强度，不再控制终端设备的数据速率。ADR位可以根据需要通过终端及网络来设置或取消。不管怎样，ADR机制都应该尽可能使能，帮助终端延长电池寿命和扩大网络容量。
注意：即使是移动的终端，可能在大部分时间也是处于非移动状态。因此根据它的移动状态，终端也可以请求网络使用ADR来帮助优化数据速率。
如果终端被网络优化过的数据速率高于自己默认的数据速率，它需要定期检查下网络仍能收到上行的数据。每次上行帧计数都会累加(是针对于每个新的上行包，重传包就不再增加计数)，终端增加 ADR_ACK_CNT 计数。如果直到ADR_ACK_LIMIT次上行(ADR_ACK_CNT >= ADR_ACK_LIMIT)都没有收到下行回复，它就得置高ADR应答请求位(ADRACKReq)。 网络必须在规定时间内回复一个下行帧，这个时间是通过ADR_ACK_DELAY来设置，上行之后收到任何下行帧就要把ADR_ACK_CNT的计数重置。当终端在接收时隙中的任何回复下行帧的ACK位字段不需要设置，表示网关仍在接收这个设备的上行帧。如果在下一个ADR_ACK_DELAY上行时间内都没收到回复(例如，在总时间ADR_ACK_LIMIT+ADR_ACK_DELAY之后)，终端必须切换到下一个更低速率，使得能够获得更远传输距离来重连网络。终端如果在每次ADR_ACK_LIMIT到了之后依旧连接不上，就需要每次逐步降低数据速率。如果终端用它的默认数据速率，那就不需要置位ADRACKReq，因为无法帮助提高链路距离。
注意：不要ADRACKReq立刻回复，这样给网络预留一些余量，让它做出最好的下行调度处理。
注意：上行传输时，如果 ADR_ACK_CNT >= ADR_ACK_LIMIT 并且当前数据速率比设备的最小数据速率高，就要设置 ADRACKReq，其它情况下不需要。
· 4.3.1.2 消息应答位及应答流程(ACK in FCtrl)
收到confirmed类型的消息时，接收端要回复一条应答消息(应答位ACK要进行置位)。如果发送者是终端，网络就利用终端发送操作后打开的两个接收窗口之一进行回复。如果发送者是网关，终端就自行决定是否发送应答。 
应答消息只会在收到消息后回复发送，并且不重发。
注意：为了让终端尽可能简单，尽可能减少状态，在收到confirmation类型需要确认的数据帧，需要立即发送一个严格的应答数据帧。或者，终端会延迟发送应答，在它下一个数据帧中再携带。
· 4.3.1.3 重传流程
当需要应答却没收到应答时就会进行重发，重发的个数由终端自己定，可能每个终端都不一样，这个参数也可以由网络服务器来设置调整。
注意：一些应答机制的示例时序图在第18章中有提供。
注意：如果终端设备重发次数到达了最大值，它可以降低数据速率来重连。至于后面是否再重发还是说丢弃不管，都取决于终端自己。
注意：如果网络服务器重发次数到达了最大值，它就认为该终端掉线了，直到它再收到终端的消息。一旦和终端设备的连接出现问题时，要不要重发都取决于网络服务器自己。
注意：在重传期间的数据速率回退的建议策略在章节18.4中有描述。
· 4.3.1.4 帧挂起位(FPending in FCtrl 只在下行有效)
帧挂起位(FPending)只在下行交互中使用，表示网关还有挂起数据等待下发，需要终端尽快发送上行消息来再打开一个接收窗口。
FPending的详细用法在章节18.3。
· 4.3.1.5 帧计数器(FCnt)
每个终端有两个计数器跟踪数据帧的个数，一个是上行链路计数器（FCntUp），由终端在每次上行数据给网络服务器时累加；另一个是下行链路计数器（FCntDown），由服务器在每次下行数据给终端时累计。 网络服务器为每个终端跟踪上行帧计数及产生下行帧计数。 终端入网成功后，终端和服务端的上下行帧计数同时置0。 每次发送消息后，发送端与之对应的 FCntUp 或 FCntDown 就会加1。 接收方会同步保存接收数据的帧计数，对比收到的计数值和当前保存的值，如果两者相差小于 MAX_FCNT_GAP （要考虑计数器滚动），接收方就按接收的帧计数更新对应值。如果两者相差大于 MAX_FCNY_GAP 就说明中间丢失了很多数据，这条以及后面的数据就被丢掉。
LoRaWAN的帧计数器可以用16位和32位两种，节点上具体执行哪种计数，需要在带外通知网络侧，告知计数器的位数。 
如果采用16位帧计数，FCnt字段的值可以使用帧计数器的值，此时有需要的话通过在前面填充0（值为0）字节来补足；如果采用32位帧计数， 
FCnt就对应计数器32位的16个低有效位(上行数据使用上行FCnt，下行数据使用下行FCnt)。
终端在相同应用和网络密钥下，不能重复用相同的FCntUp数值，除非是重传。
· 4.3.1.6 帧可选项(FOptsLen in FCtrl, FOpts) 
FCtrl 字节中的FOptsLen位字段描述了整个帧可选项(FOpts)的字段长度。
FOpts字段存放MAC命令，最长15字节，详细的MAC命令见章节4.4。
如果FOptsLen为0，则FOpts为空。在FOptsLen非0时，则反之。如果MAC命令在FOpts字段中体现，port0不能用(FPort要么不体现，要么非0)。
MAC命令不能同时出现在FRMPayload和FOpts中，如果出现了，设备丢掉该组数据。
4.3.2 端口字段(FPort)
如果帧载荷字段不为空，端口字段必须体现出来。端口字段有体现时，若FPort的值为0表示FRMPayload只包含了MAC命令；具体见章节4.4中的MAC命令。 FPort的数值从1到223(0x01..0xDF)都是由应用层使用。 FPort的值从224到255(0xE0..0xFF)是保留用做未来的标准应用拓展。
Size(bytes)
7..23
0..1
0..N
MACPayload
FHDR
FPort
FRMPayload
N是应用程序载荷的字节个数。N的有效范围具体在第7章有定义。
N应该小于等于： 
N <= M - 1 - (FHDR长度) 
M是MAC载荷的最大长度。
4.3.3 MAC帧载荷加密(FRMPayload)
如果数据帧携带了载荷，FRMPayload必须要在MIC计算前进行加密。 
加密机制是采用IEEE802.15.4/2006的AES128算法。
默认的，加密和加密由LoRaWAN层来给所有的FPort来执行。如果加密/解密由应用层来做更方便的话，也可以在LoRaWAN层之上给特定FPorts来执行，除了端口0。具体哪个节点的哪个FPort在LoRaWAN层之外要做加解密，必须要和服务器通过out-of-band信道来交互(见第19章)。
· 4.3.3.1 LoRaWAN的加密
密钥K根据不同的FPort来使用：
FPort
K
0
NwkSKey
1..255
AppSKey
表3: FPort列表
具体加密是这样： 
pld = FRMPayload 
对于每个数据帧，算法定义了一个块序列Ai，i从1到k，k = ceil(len(pld) / 16)：
Size(bytes)
1
4
1
4
4
1
1
Ai
0x01
4 x 0x00
Dir
DevAddr
FCntUp or FCntDown
0x00
i
方向字段(Dir)在上行帧时为0，在下行帧时为1. 
块Ai通过加密，得到一个由块Si组成的序列S。
Si = aes128_encrypt(K, Ai) for i = 1..k 
S = S1 | S2 | .. | Sk
通过异或计算对payload进行加解密：
· 4.3.3.2 LoRaWAN层之上的加密 
如果LoRaWAN之上的层级在已选的端口上(但不能是端口0，这是给MAC命令保留的)提供了预加密的FRMPayload给LoRaWAN，LoRaWAN则不再对FRMPayload进行修改，直接将FRMPayload从MACPayload传到应用层，以及从应用层传到MACPayload。
4.4 消息校验码(MIC)
消息检验码要计算消息中所有字段。 
msg = MHDR | FHDR | FPort | FRMPayload
MIC是按照[RFC4493]来计算：
cmac = aes128_cmac(NwkSKey, B0 | msg) 
MIC = cmac[0..3]
块B0的定义如下：
Size(bytes)
1
4
1
4
4
1
1
B0
0x49
4 x 0x00
Dir
DevAddr
FCntUp or FCntDown
0x00
len(msg)
方向字段(Dir)在上行帧时为0，在下行帧时为1.
LoRaWAN第4章，主要讲述了MAC帧格式，对所有涉及的字段都做了解释。
千言万语汇成一句话，哦不，汇成一个表。
数据帧头

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
CRC

好了，帧格式是大家随手都能看到的东西，本尊作为IoT小能手，如果不能提出一些稍有深度的信息增量，就对不起这个称号了。所以，有些协议设计层面的心得要分享下：
1. 特别酷的ADR(速率自适应)机制 
这个章节中最亮眼的莫过于速率自适应机制，简直是为LoRa网络量身定做的：一旦使能了FCtrl中的ADR位，距离近信号好的节点用高速率，距离远信号弱的节点用低速率，不小心被调高了速率，则自动降下来。这样，尽可能地提高了传输速率，也有效提高了网络容量。我已经见过不少厂家，拿这个协议的公知特点当产品卖点了。
2. 可同时携带数据和命令的MAC帧 
一般来说，应用除了数据，出于管理需要，肯定还会涉及命令。比如基站要查询节点状态，或者节点要请求变更信道等。所以LoRaWAN协议设计上利用FOpts把数据和命令揉在一个MAC帧里，这样可以提高交互效率，有效地降低功耗。这在寸土寸金，哦不，寸库仑(电量单位)寸金的物联网应用中，是一个很有必要的设计。
3 源码解析
这章的处理基本都在 \src\mac\LoRaMac.c 中，下面按照MAC帧格式的字段逐个解析下。
3.1 MAC层MHDR
在LoRaWAN的数据API中处理了MHDR，这个字段内容比较少，就按需选择了消息类型是confirm还是unconfirm。 
另外在管理API中的Join-Req的消息类型。
具体可见 LoRaMacMcpsRequest() 和 LoRaMacMlmeRequest() 这两个函数。
3.2 MACPayload
MACPayload 的组帧都在 PrepareFrame() 这个函数中处理，将macHdr和macPayload的fCtrl、FPort、FRMPayload都传递进去，完成整个MAC层的数据组帧。
LoRaMacBuffer就存放了MACPayload的数据，这个变量的组帧和协议字段定义是一一对应。MACPayload的组帧处理，在大流程上是对join和数据两种类型的帧分别处理，用两个case分开。
为了方便阅览，我把函数代码框架提炼了出来。
LoRaMacStatus_t PrepareFrame( LoRaMacHeader_t *macHdr, LoRaMacFrameCtrl_t *fCtrl, uint8_t fPort, void *fBuffer, uint16_t fBufferSize )
{
switch( macHdr->Bits.MType )
{
case FRAME_TYPE_JOIN_REQ:
...// 省略
break;
case FRAME_TYPE_DATA_CONFIRMED_UP:
NodeAckRequested = true;
//Intentional falltrough
case FRAME_TYPE_DATA_UNCONFIRMED_UP:
...
fCtrl->Bits.AdrAckReq = AdrNextDr( fCtrl->Bits.Adr, true, &LoRaMacParams.ChannelsDatarate );
...
if( SrvAckRequested == true )
{
SrvAckRequested = false;
fCtrl->Bits.Ack = 1;
}

LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr ) & 0xFF;
LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr >> 8 ) & 0xFF;
LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr >> 16 ) & 0xFF;
LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr >> 24 ) & 0xFF;

LoRaMacBuffer[pktHeaderLen++] = fCtrl->Value;

LoRaMacBuffer[pktHeaderLen++] = UpLinkCounter & 0xFF;
LoRaMacBuffer[pktHeaderLen++] = ( UpLinkCounter >> 8 ) & 0xFF;

// Copy the MAC commands which must be re-send into the MAC command buffer
memcpy1( &MacCommandsBuffer[MacCommandsBufferIndex], MacCommandsBufferToRepeat, MacCommandsBufferToRepeatIndex );
MacCommandsBufferIndex += MacCommandsBufferToRepeatIndex;

if( ( payload != NULL ) && ( payloadSize > 0 ) )
{
if( ( MacCommandsBufferIndex <= LORA_MAC_COMMAND_MAX_LENGTH ) && ( MacCommandsInNextTx == true ) )
{
fCtrl->Bits.FOptsLen += MacCommandsBufferIndex;

// Update FCtrl field with new value of OptionsLength
LoRaMacBuffer[0x05] = fCtrl->Value;
for( i = 0; i < MacCommandsBufferIndex; i++ )
{
LoRaMacBuffer[pktHeaderLen++] = MacCommandsBuffer[i];
}
}
}
else
{
if( ( MacCommandsBufferIndex > 0 ) && ( MacCommandsInNextTx ) )
{
payloadSize = MacCommandsBufferIndex;
payload = MacCommandsBuffer;
framePort = 0;
}
}
MacCommandsInNextTx = false;
// Store MAC commands which must be re-send in case the device does not receive a downlink anymore
MacCommandsBufferToRepeatIndex = ParseMacCommandsToRepeat( MacCommandsBuffer, MacCommandsBufferIndex, MacCommandsBufferToRepeat );
if( MacCommandsBufferToRepeatIndex > 0 )
{
MacCommandsInNextTx = true;
}
MacCommandsBufferIndex = 0;

if( ( payload != NULL ) && ( payloadSize > 0 ) )
{
LoRaMacBuffer[pktHeaderLen++] = framePort;

if( framePort == 0 )
{
LoRaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, LoRaMacNwkSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoRaMacPayload );
}
else
{
LoRaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, LoRaMacAppSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoRaMacPayload );
}
memcpy1( LoRaMacBuffer + pktHeaderLen, LoRaMacPayload, payloadSize );
}
LoRaMacBufferPktLen = pktHeaderLen + payloadSize;

LoRaMacComputeMic( LoRaMacBuffer, LoRaMacBufferPktLe