LoRaWAN 網絡是典型的星型架構網絡，但單節點的廣播數據也可以同時被多個網關收到并同時上報NS服務器，對于此消息有下行需求時，需要通過NS服務器的下行網關選擇算法，選擇合適網關進行下行。

一個健全的算法需要考慮到不同網關的網絡延時、空口負載、信號質量及任務隊列選擇最優網關進行下行，確保下行消息可靠送達并使整體網絡負載趨于均衡。

利爾達的下行選擇算法也隨著NS服務器的更新在不斷迭代升級，我們在上篇中對兩種常用的算法進行分析描述，今天將繼續通過仿真一起看看各種算法在實際應用場景中是如何表現的。

現有算法缺陷及優化算法提出

算法一：信號質量優先法

算法簡化流程圖如下：

缺陷：

1、該算法僅以信號質量作為選擇標準，NS可以選擇出距離節點最近的網關，但是沒有考慮網關網絡延遲，若選擇的網關為4G網關，網絡波動嚴重，將產生大量下行丟包。

2、未考慮網關上行負載情況，遇到第三章中所述的負載問題時也無法進行有效處理。

算法二：影響因子得分加權法

算法簡化流程圖如下：

缺陷：

1、遇到第三章中所述的上下行鏈路不對等問題時，算法可能因為其他網關的網絡延遲及通信負載較好而選擇極遠處網關下行而導致丟包

2、經過模擬測試，網關網絡延遲大于450ms時，任何下行數據都將失敗，使用權重來考慮該因素并不合理。

3、其實該算法的幾個權重值都很難定奪，任何的影響因子出現較為極限的情況時，都會使最終得分有失合理性，很難通過權重值平衡各種極限情況。

算法三：利爾達Unicore 3.0 下行選擇算法
考慮到現有算法的缺點并結合實際應用場景可能遇到的問題，現提出一種新的解決辦法，由于核心部分涉及公司機密，故簡單介紹其特點如下：
1、充分進行網絡負載均衡，保證網絡內所有網關的下行負載處于健康狀態，面對個別網關網絡擁堵的狀況時可以很好地將任務均分給附近網關。
2、網關的下行充分考慮下行質量，所有的下行保證處于安全邊際內，不會因為個別因素的影響而選擇信號質量在安全邊際外的網關下行。保證上下行鏈路雙向可達。
3、可以處理較大的網絡波動，保證選擇的下行網關不受網絡波動影響。

算法仿真

基于Python實現上述三種算法并對實際應用場景進行圖形化建模，用以分析算法的執行情況。效果圖如下：

該算法仿真基于以下原理與假設：

1、在1*1的正交坐標軸內以隨機生成或手動指定的方式確定網關數量及坐標位置。網關位置以紅色三角進行標注

2、網關屬性包含上行負載及下行負載，每個網關的上行負載可手動設定，且為靜態值，與下行負載沒有任何直接聯系。網關的下行負載在仿真算法中動態計算，網關每處理一個下行請求都會累加下行負載

3、坐標軸1*1區域內以均勻分布的方式隨機生成指定數量的坐標點，代表有下行需求的節點，坐標點與網關的距離代表上行信息的信號質量，距離越遠信號質量越差。

4、無需考慮實際環境中建筑、樹林等遮擋物帶來的信號衰減，因為坐標軸內的點位置即代表上行信號質量，并非現實中的節點位置。

5、每隨機生成一個下行需求點，運行指定的下行選擇算法，選擇出最優網關下行后，該網關下行負載增加，并將該點以該網關對應的顏色標注在坐標軸內。

6、不考慮下行速率及TOA時間，將網關的上下行通信占空比抽象為簡單的數值，每有一個下行請求，網關下行負載+0.1。

7、假定下行點數量即為周期時間內整個系統需要處理的下行請求，且網關計算動態負載的周期與這個周期時間一致。因此增加點數量即為模擬更高頻次的下行請求，且代碼中動態負載只需累加即可無需循環計算。

8、為簡化算法模擬過程，假定周期時間都所有網關的網絡延時均正常。

8、處理完所有點的下行請求后坐標軸內會顯示大量著色節點，代表單位時間內對應網關處理的下行請求。

9、代碼運行結束后各網關的上下行負載情況會以表格的形式打印出來。

算法對比

手動設定網關位置及各網關上行負載，模擬出常規及各種特殊情況，對比三種不同算法的表現，驗證算法效果。

算法一：信號質量優先法

算法二：影響因子得分加權法

算法三：利爾達Unicore 3.0 下行選擇算法

【常規情況】

條件：下行請求數量1000 / 網關數量3 / 隨機分布 / 網關上行輕負載

結果：算法一無負載均衡；算法二負載均衡效果差；算法三負載均衡效果佳

結果分析：

算法一和算法二在網關分布均勻且個網關上行負載無明顯差距的情況下，呈現的效果類似，基本是按照就近原則擇優，圖上可以看到明顯的三條明顯的分界線，即網關兩兩連線的中垂線。最終的網關上下行負載都不是很均勻。

算法三中無明顯邊界線，距離網關較近處的節點選擇下行時較為靈活，點位分布存在交叉區域，而較偏遠的點則選擇了信號質量最好的網關下行。網絡負載也做到了很理想的均衡。

【部分網關位置較偏遠】

條件：下行請求數量1000 / 網關數量3 / 隨機分布 / 網關上行輕負載 / 網關分布不均勻

結果：算法一無負載均衡；算法二負載均衡效果差、部分下行可能丟包；算法三下行質量可靠、負載均衡效果尚可。

結果分析：

該情況下選取的三個網關位置中，兩個的位置較偏遠。由于下行行請求散點是均勻分布，難以按照設想隨意調整分布密度，因此改變網關位置其實相當于改變下行請求的分布情況。該情況下下行請求主要集中于中央網關的附件，下面看下三種算法對于這種情況的處理。

算法一由于僅判斷信號質量，在下行請求分布不均勻時，下行負載嚴重不均衡。

算法二可以注意帶紅圈標注處的情況，由于網關負載在加權求和的算法中占有一定權重，因此當右上角網關負載較小時，得分較高。紅圈內的綠色點即是因此原因被分配給了該網關來下行。然而這么偏遠位置的節點本身信號質量已經很差，還要選擇非最近網關下行，很可能遇到第三章所述的上下行不對等問題，而導致下行失敗。且由最終的下行負載情況可以看出負載分布也是差距懸殊。若調整網關負載所占的得分權重，調大則上下行不對等問題更加明顯，調小則負載分布更加不均勻。存在一定的局限性。

算法三中右上角網關自身附近的下行請求較少，但是算法給他分配了大量中間網關附近的下行請求，最大程度地幫助整個系統分擔下行負載。并且該網關僅響應自己安全邊際內的下行，對于偏遠點全部交由最近的網關處理以保障通信成功率。最終的下行負載情況雖然沒有做到完全均衡，但是優于前兩者。

【某網關負載較重情況】

條件：下行請求數量1000 / 網關數量5 / 隨機分布 / 單網關上行重負載 / 網關分布較均勻

結果：算法一無負載均衡；算法二負載均衡效果差；算法三負載均衡效果好。

結果分析：

這是一種較為常見的情況，區域內分布了五臺網關，最右側網關覆蓋的節點較多，且上行負載較大，設定值為17.5%，主要關注各算法對這個高負載網關的處理。

算法一僅判斷信號質量，不判斷負載情況，最右處網關在已有17.5%的上行負載時依然需要處理26.9%的下行負載。

算法二在上一個模擬場景中暴露出負載權重過大的缺陷，本場景中未改變負載權重。可以看出相對于算法一，算法二由于網關負載在加權求和的算法中占有一定權重，已經起到了一定效果，將網關4的下行負載降低了一些，但是在該場景下，相對于上個場景反而顯得負載的權重太小，無法處理好大負載網關。

算法三中可以看到左側的網關都向右分擔了更多的下行任務，最終網關4的下行負載僅為12.9%，相比于其他算法有明顯提升。

總結

綜合以上仿真結果——

算法一由于為考慮網關負載情況，在負載均衡的處理上完全由節點與網關的位置決定，雖然能保證從信號最優網關下行，但是缺點在于無法做到負載均衡。

算法二在將考慮到了各類影響因素，設定不同的權重進行加權求和，看似可以通過權重因子的調節靈活地調整算法以應對各種情況，但是在仿真的模擬情況二和情況三中，使用相同的權重，卻暴露出相反方向的問題，也就是說權重因子無論如何調節都無法同時處理這兩種情況。并且在負載均衡方面算法二也僅是相對于算法一有一點點提升。

算法三在上述模擬情況及其余大量隨機測試中沒有暴露出問題，算法從設計角度已經保證了遠處節點可以得到最佳網關的響應，并且在負載均衡方面拿出近處節點靈活分配，最大程度的做到負載均衡。