1.svg 2.svg

CN
EN

搜索

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

2024/01/12

浏览量:1287

a1img19-1121.jpg

  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的下行请求。


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


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

助力万物互联
稳稳支撑你的需求