Lorawan协议说明书

对

FRMPayload

进行修改，

FRMPayload

从

< br>MACPayload

传到应用层，

以及从应用层传到< /p>

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

B0

0x49

4

1

4

4

1

1

len(msg)

4

x

Dir

0x00

DevAddr

FCntUp

or

0x00

FCntDown

方向字 段

(

Dir

)

在上行帧时为

0

，在下行帧时为

1.

LoRaWAN

第

4

< br>章，主要讲述了

MAC

帧格式，对所有涉及的字段都做了 解释。

千言万语汇成一句话，哦不，汇成一个表。

数

Dev

Addr

FC

trl

F

Cn

FO

pts

据

帧

头

Prea

mble

PH

DR

PHDR

_CRC

MH

DR

FHDR

t

数

据

帧

M

AC

层

PH

Y

层

FP

ort

FRMPa

yload

M

C

IC

R

C

Prea

mble

PH

DR

PHDR

_CRC

MH

DR

MACPayload

M

C

IC

R

C

Prea

mble

PH

DR

PHDR

_CRC

PHYPayload

C

R

C

< /p>

好了，帧格式是大家随手都能看到的东西，本尊作为

IoT

小能手，如果不能提出一

些稍有深度的信息增量，就对不起这个称号了 。所以，有些协议设计层面的心得要

分享下：

1.

特别酷的

ADR(

速率自适应

)

机制

这个章节中最亮眼的莫过于速率自适应机制，简直是为

LoRa

网络量身定做

的：一旦使能了

FCtrl

中的

ADR

位， 距离近信号好的节点用高速率，距离远

信号弱的节点用低速率，不小心被调高了速率，则 自动降下来。这样，尽可

能地提高了传输速率，也有效提高了网络容量。我已经见过不少 厂家，拿这

个协议的公知特点当产品卖点了。

2.

可同时携带数据和命令的

MAC

帧

一般来 说，应用除了数据，出于管理需要，肯定还会涉及命令。比如基站要

查询节点状态，或者 节点要请求变更信道等。所以

LoRaWAN

协议设计上利

用

FOpts

把数据和命令揉在一个

MAC

帧里，这样可以提高交互效率，有效

地 降低功耗。

这在寸土寸金，

哦不，

寸库 仑

(

电量单位

)

寸金的物联网应用中，

是一个很有必要的设计。

3

源码解析

这章的处理基本都在

srcmacLoRaMac.c

中，下面按照

MAC

帧格式的字段逐个解

析下。

< br>

3.1 MAC

层

MHDR

< br>在

LoRaWAN

的数据

API

中处理了

MHDR

，

< br>这个字段内容比较少，

就按需选择了消

息类型是

confirm

还是

unconfirm

。

另外在管理

A PI

中的

Join- Req

的消息类型。

具体可见

LoRaMacMcpsRequest()

和

LoRaMacMlmeRequest()

这两个函数。

3.2 MACPayload

MACPayload

的组帧都在

PrepareFrame()

这个函数中处理，将

macHdr

和

macPayload

的

fCtrl

、

FPo rt

、

FRMPayload

都传递进 去，完成整个

MAC

层的数据组

帧。< /p>

LoRaMacBuffer

就存放了

MACPayload

的数据，这个变量的组帧和协议字段定义 是

一一对应。

MACPayload

的 组帧处理，在大流程上是对

join

和数据两种类型的帧分

别处理，用两个

case

分开。

为了方便阅览，我把函数代码框架提炼了出来。

LoRaMacStatus_t PrepareFrame( LoRaMacHeader_t *macHdr, LoR

aMacFrameCtrl_t *fCtrl, uint8_t fPort, void *fBuffer, uint

16_t fBufferSize )

{

switch( macHdr-> )

{

case FRAME_TYPE_JOIN_REQ:

...//

省略

break;

case FRAME_TYPE_DATA_CONFIRMED_UP:

NodeAckRequested = true;

//Intentional falltrough

case FRAME_TYPE_DATA_UNCONFIRMED_UP:

...

fCtrl->Req = AdrNextDr( fCtrl->, true,

&lsDatarate );

...

if( SrvAckRequested == true )

{

SrvAckRequested = false;

fCtrl-> = 1;

}

LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr ) & 0xFF;

LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr >> 8 ) & 0

xFF;

LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr >> 16 ) &

0xFF;

LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr >> 24 ) &

0xFF;

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

LoRaMacBuffer[pktHeaderLen++] = UpLinkCounter & 0xFF;

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

FF;

// Copy the MAC commands which must be re-send in

to the MAC command buffer

memcpy1(&MacCommands Buffer[MacCommandsBufferIndex], MacCo

mmandsBufferToRepeat, MacCommandsBufferToRepeatIndex );

MacCommandsBufferIndex += MacCommandsBufferToRep

eatIndex;

if( ( payload != NULL ) && ( payloadSize > 0 ) )

{

if( ( MacCommandsBufferIndex <= LORA_MAC_COMMAND_MAX_LENGT

H ) && ( MacCommandsInNextTx == true ) )

{

fCtrl->en += MacCommandsBufferIndex;

// Update FCtrl field with new value of Op

tionsLength

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 ca

se the device does not receive a downlink anymore

MacCommandsBufferToRepeatIndex = ParseMacCommand

sToRepeat( MacCommandsBuffer, MacCommandsBufferIndex, MacC

ommandsBufferToRepeat );

if( MacCommandsBufferToRepeatIndex > 0 )

{

MacCommandsInNextTx = true;

}

MacCommandsBufferIndex = 0;

if( ( payload != NULL ) && ( payloadSize > 0 ) )

{

LoRaMacBuffer[pktHeaderLen++] = framePort;

if( framePort == 0 )

{

LoRaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, L

oRaMacNwkSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoR

aMacPayload );

}

else

{

LoRaMacPayloadEncrypt( (uint8_t* ) payload, payloadSize, L

oRaMacAppSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, LoR

aMacPayload );

}

memcpy1( LoRaMacBuffer + pktHeaderLen, LoRaMacPayload, pay

loadSize );

}

LoRaMacBufferPktLen = pktHeaderLen + payloadSiz

e;

LoRaMacComputeMic( LoRaMacBuffer, LoRaMacBufferPktLen, LoR

aMacNwkSKey, LoRaMacDevAddr, UP_LINK, UpLinkCounter, &mic

);

LoRaMacBuffer[LoRaMacBufferPktLen + 0] = mic & 0xFF;

LoRaMacBuffer[LoRaMacBufferPktLen + 1] = ( mic >> 8 ) & 0xF

F;

LoRaMacBuffer[LoRaMacBufferPktLen + 2] = ( mic >> 16 ) & 0x

FF;

LoRaMacBuffer[LoRaMacBufferPktLen + 3] = ( mic >> 24 ) & 0x

FF;

LoRaMacBufferPktLen += LORAMAC_MFR_LEN;

break;

case FRAME_TYPE_PROPRIETARY:

...//

省略

break;

default:

return LORAMAC_STATUS_SERVICE_UNKNOWN;

}

return LORAMAC_STATUS_OK;

}

Join-request

的组帧 处理对应协议第

6

章

6.2.4 Join-request message

。

数据帧的组帧处 理则稍微复杂些，尤其是

FHDR

，下面逐个字段讲解下

FHDR

。

3.2.1 MACPayload

中的

FHDR

?

中的

DevAddr

LoRaMacBuffer[pktHeaderLen++] = ( LoRaMacDevAddr ) & 0xFF;

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

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

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

?

中的

FCtrl

首先

ADR

位段是在传入

PrepareFrame()

之前，就做了处理。

= AdrCtrlOn;

接着

AdrAckReq

位段，在长期失联情况下会发送

AdrAckReq

确认链路。

fCtrl->Req = AdrNextDr( fCtrl->, true,

&lsDatarate );

最后

F0ptsLen

位段，会在下面计算完

FOpts

之后更新。

?

中的

FCnt

LoRaMacBuffer[pktHeaderLen++] = UpLinkCounter & 0xFF;

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

这个

< br>UpLinkCounter

会在物理层发送完成后会按照协议进行累加。可以看 到这是个

32

位计数器，按照协议规定，

“

如果采用

32

位帧计数，