LoRaWAN 网络是典型的星型架构网络，但单节点的广播数据也可以同时被多个网关收到并同时上报NS服务器，对于此消息有下行需求时，需要通过NS服务器的下行网关选择算法，选择合适网关进行下行。
一个健全的算法需要考虑到不同网关的网络延时、空口负载、信号质量及任务队列选择最优网关进行下行，确保下行消息可靠送达并使整体网络负载趋于均衡。
利记APP的下行选择算法也随着NS服务器的更新在不断迭代升级，我们在上篇中对两种常用的算法进行分析描述，今天将继续通过仿真一起看看各种算法在实际应用场景中是如何表现的。
一、现有算法缺陷及优化算法提出
算法一：信号质量优先法
算法简化流程图如下：
缺陷：
1、该算法仅以信号质量作为选择标准，NS可以选择出距离节点最近的网关，但是没有考虑网关网络延迟，若选择的网关为4G网关，网络波动严重，将产生大量下行丢包。
2、未考虑网关上行负载情况，遇到第三章中所述的负载问题时也无法进行有效处理。
算法二：影响因子得分加权法
算法简化流程图如下：
缺陷：
1、遇到第三章中所述的上下行链路不对等问题时，算法可能因为其他网关的网络延迟及通信负载较好而选择极远处网关下行而导致丢包
2、经过模拟测试，网关网络延迟大于450ms时，任何下行数据都将失败，使用权重来考虑该因素并不合理。
3、其实该算法的几个权重值都很难定夺，任何的影响因子出现较为极限的情况时，都会使最终得分有失合理性，很难通过权重值平衡各种极限情况。
算法三：利记APPUnicore 3.0 下行选择算法
考虑到现有算法的缺点并结合实际应用场景可能遇到的问题，现提出一种新的解决办法，由于核心部分涉及公司机密，故简单介绍其特点如下：
1、充分进行网络负载均衡，保证网络内所有网关的下行负载处于健康状态，面对个别网关网络拥堵的状况时可以很好地将任务均分给附近网关。
2、网关的下行充分考虑下行质量，所有的下行保证处于安全边际内，不会因为个别因素的影响而选择信号质量在安全边际外的网关下行。保证上下行链路双向可达。
3、可以处理较大的网络波动，保证选择的下行网关不受网络波动影响。
二、算法仿真
基于Python实现上述三种算法并对实际应用场景进行图形化建模，用以分析算法的执行情况。效果图如下：
该算法仿真基于以下原理与假设：
1、在1*1的正交坐标轴内以随机生成或手动指定的方式确定网关数量及坐标位置。网关位置以红色三角进行标注
2、网关属性包含上行负载及下行负载，每个网关的上行负载可手动设定，且为静态值，与下行负载没有任何直接联系。网关的下行负载在仿真算法中动态计算，网关每处理一个下行请求都会累加下行负载
3、坐标轴1*1区域内以均匀分布的方式随机生成指定数量的坐标点，代表有下行需求的节点，坐标点与网关的距离代表上行信息的信号质量，距离越远信号质量越差。
4、无需考虑实际环境中建筑、树林等遮挡物带来的信号衰减，因为坐标轴内的点位置即代表上行信号质量，并非现实中的节点位置。
5、每随机生成一个下行需求点，运行指定的下行选择算法，选择出最优网关下行后，该网关下行负载增加，并将该点以该网关对应的颜色标注在坐标轴内。
6、不考虑下行速率及TOA时间，将网关的上下行通信占空比抽象为简单的数值，每有一个下行请求，网关下行负载+0.1。
7、假定下行点数量即为周期时间内整个系统需要处理的下行请求，且网关计算动态负载的周期与这个周期时间一致。因此增加点数量即为模拟更高频次的下行请求，且代码中动态负载只需累加即可无需循环计算。
8、为简化算法模拟过程，假定周期时间都所有网关的网络延时均正常。
9、处理完所有点的下行请求后坐标轴内会显示大量着色节点，代表单位时间内对应网关处理的下行请求。
10、代码运行结束后各网关的上下行负载情况会以表格的形式打印出来。
三、算法对比
手动设定网关位置及各网关上行负载，模拟出常规及各种特殊情况，对比三种不同算法的表现，验证算法效果。
算法一：信号质量优先法
算法二：影响因子得分加权法
算法三：利记APPUnicore 3.0 下行选择算法
【常规情况】
条件：下行请求数量1000 / 网关数量3 / 随机分布 / 网关上行轻负载
结果：算法一无负载均衡；算法二负载均衡效果差；算法三负载均衡效果佳
结果分析：
算法一和算法二在网关分布均匀且个网关上行负载无明显差距的情况下，呈现的效果类似，基本是按照就近原则择优，图上可以看到明显的三条明显的分界线，即网关两两连线的中垂线。最终的网关上下行负载都不是很均匀。
算法三中无明显边界线，距离网关较近处的节点选择下行时较为灵活，点位分布存在交叉区域，而较偏远的点则选择了信号质量最好的网关下行。网络负载也做到了很理想的均衡。
【部分网关位置较偏远】
条件：下行请求数量1000 / 网关数量3 / 随机分布 / 网关上行轻负载 / 网关分布不均匀
结果：算法一无负载均衡；算法二负载均衡效果差、部分下行可能丢包；算法三下行质量可靠、负载均衡效果尚可。
结果分析：
该情况下选取的三个网关位置中，两个的位置较偏远。由于下行行请求散点是均匀分布，难以按照设想随意调整分布密度，因此改变网关位置其实相当于改变下行请求的分布情况。该情况下下行请求主要集中于中央网关的附件，下面看下三种算法对于这种情况的处理。
算法一由于仅判断信号质量，在下行请求分布不均匀时，下行负载严重不均衡。
算法二可以注意带红圈标注处的情况，由于网关负载在加权求和的算法中占有一定权重，因此当右上角网关负载较小时，得分较高。红圈内的绿色点即是因此原因被分配给了该网关来下行。然而这么偏远位置的节点本身信号质量已经很差，还要选择非最近网关下行，很可能遇到第三章所述的上下行不对等问题，而导致下行失败。且由最终的下行负载情况可以看出负载分布也是差距悬殊。若调整网关负载所占的得分权重，调大则上下行不对等问题更加明显，调小则负载分布更加不均匀。存在一定的局限性。
算法三中右上角网关自身附近的下行请求较少，但是算法给他分配了大量中间网关附近的下行请求，最大程度地帮助整个系统分担下行负载。并且该网关仅响应自己安全边际内的下行，对于偏远点全部交由最近的网关处理以保障通信成功率。最终的下行负载情况虽然没有做到完全均衡，但是优于前两者。
【某网关负载较重情况】
条件：下行请求数量1000 / 网关数量5 / 随机分布 / 单网关上行重负载 / 网关分布较均匀
结果：算法一无负载均衡；算法二负载均衡效果差；算法三负载均衡效果好。
结果分析：
这是一种较为常见的情况，区域内分布了五台网关，最右侧网关覆盖的节点较多，且上行负载较大，设定值为17.5%，主要关注各算法对这个高负载网关的处理。
算法一仅判断信号质量，不判断负载情况，最右处网关在已有17.5%的上行负载时依然需要处理26.9%的下行负载。
算法二在上一个模拟场景中暴露出负载权重过大的缺陷，本场景中未改变负载权重。可以看出相对于算法一，算法二由于网关负载在加权求和的算法中占有一定权重，已经起到了一定效果，将网关4的下行负载降低了一些，但是在该场景下，相对于上个场景反而显得负载的权重太小，无法处理好大负载网关。
算法三中可以看到左侧的网关都向右分担了更多的下行任务，最终网关4的下行负载仅为12.9%，相比于其他算法有明显提升。
四、总结
综合以上仿真结果——
算法一由于为考虑网关负载情况，在负载均衡的处理上完全由节点与网关的位置决定，虽然能保证从信号最优网关下行，但是缺点在于无法做到负载均衡。
算法二在将考虑到了各类影响因素，设定不同的权重进行加权求和，看似可以通过权重因子的调节灵活地调整算法以应对各种情况，但是在仿真的模拟情况二和情况三中，使用相同的权重，却暴露出相反方向的问题，也就是说权重因子无论如何调节都无法同时处理这两种情况。并且在负载均衡方面算法二也仅是相对于算法一有一点点提升。
算法三在上述模拟情况及其余大量随机测试中没有暴露出问题，算法从设计角度已经保证了远处节点可以得到最佳网关的响应，并且在负载均衡方面拿出近处节点灵活分配，最大程度的做到负载均衡。
