LoRaWAN终端OTAA入网问题及解决办法

LoRaWAN终端OTAA入网问题及解决办法

OTAA方式入网

LoRaWAN™Specification V1.02（下称“LoRaWAN协议”）为终端定义了2种入网方式：

Over-The-Air-Activation(OTAA)和Activation By Personalization(ABP)；

因OTAA的灵活度和安全性更高，更多的终端产品选择该方式接入LoRaWAN网络。通常，一组终端的OTAA入网流程如下图：

终端#1~终端#N依次向LoRaWAN Server发起OTAA入网请求（Join Request），Server依次做出响应（Join Accept），完成入网过程。

关于OTAA和ABP更经典的介绍，推荐“RimeLink”大神的博文

http://blog.csdn.net/jiangjunjie_2005/article/details/54345432

多终端并发入网测试

LoRaWAN协议举例了一种工作场景，这里称之为“并发入网”，在这种场景下，多个终端会“同时”向服务器发起入网请求，并对网络造成一定的影响：

我们使用“12台集成了LoRaWAN终端的温湿度采集器”，配合LoRaWAN网关和服务器搭建了测试环境。在确保所有设备均无故障的情况下，测试多终端并发入网场景。

 

温湿度采集器：

网关：

服务器：

 

理想的测试结果：每台终端执行下图1~4步操作，顺利完成入网和温湿度数据交互。

实际的测试结果：08、11、12号终端执行了上图“1->2->3->4(-)”的流程，即——终端执行完入网流程，且周期发送温湿度数据，但服务器丢弃了终端发送的数据。

 

问题原因分析

经查，故障发生时，8号终端记录自己的DevAddr为“26 04 2F F3”，且使用该地址向服务器周期发送温湿度数据，但服务器上显示该终端DevAddr应为“26 04 22 13”，如下图：

同时，2号终端记录自己的DevAddr也为“26 04 2F F3”，且与服务器上的Device Address一致，如下图：

DevAddr在LoRaWAN协议中被定义为终端的短地址（short device address），它在终端采用OTAA方式入网时，由服务器分配，并通过Join Accept报文发送给终端，做为终端入网成功后与服务器交互的通信地址使用。

显然，8号终端使用的DevAddr错误，它未使用服务器分配的DevAddr（26 04 22 13）与服务器通信，且与2号终端的DevAddr（26 04 2F F3）发生了重复。

那么，为何8号终端会错误的获得了2号终端的DevAddr呢，只有一种合理的解释：

发生并发入网时，8号终端与2号终端恰好工作在相同的频率和速率下，导致8号终端也接收了服务器发送给2号终端的Join Accept报文（携带DevAddr），并认为自己入网成功！

通过对终端的仿真调试，打印终端接收到的Join Accept报文，验证了该原因。

 

解决方法

目前，有两种方法可以解决并发入网失败的问题，如下：

1．终端实现“伪随机”离散入网，可以将DevAddr代入随机函数，生成入网时间，这样有效降低终端同时入网的概率，“躲掉”该问题。

2．从协议层面解决问题，在Join Accept中增加用以区分终端的字段，使终端能够识别出Join Accept是否为发送给自己的响应报文，这样可以从根本上杜绝并发入网失败的问题，但这需要标准上的支持，否则，会导致各厂家生产的终端与服务器不兼容。

 

有问有答，互相帮助，就在LoRaWAN论坛：

http://lora.timeddd.com