LoRaWAN网络服务器算法--下行路径选择算法对比与仿真（上）

 

LoRaWAN 网络是典型的星型架构网络，但单节点的广播数据也可以同时被多个网关收到并同时上报NS服务器，对于此消息有下行需求时，需要通过NS服务器的下行网关选择算法，选择合适网关进行下行。
 

一个健全的算法需要考虑到不同网关的网络延时、空口负载、信号质量及任务队列选择最优网关进行下行，确保下行消息可靠送达并使整体网络负载趋于均衡。

利尔达的下行选择算法也随着NS服务器的更新在不断迭代升级，下面对两种常用的算法进行分析描述，并与利尔达Unicore 3.0 LoRaWAN NS服务器的最新下行选择算法进行仿真比较，通过仿真一起看看各种算法在实际应用场景中是如何表现的。

 

 

现有算法简述

LoRaWAN的NS服务器中常用以下两种下行选择算法，原理简介如下：
 

算法1：信号质量优先法
上行数据有下行需求时，对所有收到该包数据网关的接收信号质量（RSSI或SNR）进行比较，选择上行信号质量最佳的网关进行下行。

算法2：影响因子得分加权法
下行数据前，根据四点影响因子（RSSI、SNR、网关网络延迟、网关通信负载）对所有收到上行数据的网关进行打分，所有影响因子数值与网关优先度均呈负相关，所以将所有影响因子归一化后加权求和计算出网关得分，并选择分数最小的网关响应下行任务。

 

 

应用场景问题分析

在实际工程环境下，以上两种下行选择算法已经暴露出一些问题，下面对一些已知问题进行描述分析。

【上下链路不对等问题】
网关与节点使用的射频基带芯片不同（SX1301与SX1278/SX1276）决定了通信的上下行链路不会完全对等，网关侧基带芯片的接收灵敏度较高，且带有LNA低噪声放大器，可以解调更低信号强度与信噪比的LoRa数据，因此为了保证网关收到上行后，下行的消息可被节点收到，网关的发射功率会大于节点以补偿链路预算的差值。经外场实验测试。节点发射功率为19dBm时，网关需要使用24dBm左右的发射功率才能保证上下行链路平衡。然而因为不同国家对免费频段设备功率的限制，网关的发射功率很可能无法设定为24dBm。上下行链路不平衡会导致网络的下行变得不可靠，带来一些本可以避免的下行丢包。

下面以实际案例说明：
1、利尔达配合某客户在某园区部署了深度覆盖的LoRaWAN网络以接入车位锁、地磁、井盖报警器等应用，使用的是第三方的LoRaWAN NS 服务器。2平方公里左右的区域内部署了5台网关深度覆盖地上地下所有应用，然而在部署完成后的测试中缺频繁出现确认帧丢包的现象，排查后发现所有丢包都发生在下行链路，原因在于NS选择了园区外较远处其他项目下的网关下行，而节点的上行可以到达该网关，网关的下行节点缺收不到。
2、某路灯客户也出现过类似现象，距离网关200m内的节点却收不到下行。原因在于NS选择了极远处的一台网关下行导致下行丢包。
以上都暴露出NS下行路径选择的问题，即使上下行链路不对等，算法需要保证不选择信号极差的网关下行。使用算法二时面对该问题可能会无法有效地进行处理

【负载问题】
1、某项目中接入了水表、电表、温湿度、水浸报警等应用，电表的485转LoRaWAN设备集中安装于高压配电房内，数量大（几百只）且上报频次高（unconfirm帧5min周期），配电房附近部署了一台网关以保障配电房内的网络覆盖。而附近的水浸报警器使用Confirm帧通信并且在各类设备首次安装或集体断电时，该网关也需要响应大量JoinAccpet的下行请求。

配电房附近的这台网关因为上行负载极大，若也被分配到较多附近节点的下行请求，由于网关是半双工，在下行时势必会导致一定数量上行数据包的丢失。而若选择其他稍远处空闲网关下行，则可以避免该问题。使用算法一时无法做到负载均衡。

 

那么如何解决呢？我们下期再进行详细分析，敬请关注。