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

配電房附近的這臺網關因為上行負載極大，若也被分配到較多附近節點的下行請求，由于網關是半雙工，在下行時勢必會導致一定數量上行數據包的丟失。而若選擇其他稍遠處空閑網關下行，則可以避免該問題。使用算法一時無法做到負載均衡。

那么如何解決呢？我們下期再進行詳細分析，敬請關注。