|
[size=17.1429px]
[size=17.1429px]客户: 某路灯行业客户
[size=17.1429px]日 期: 2020-06-18
[size=17.1429px]支持人员: 顾超杰
[size=17.1429px] 固件版本
[size=17.1429px]LR-Modem-CN470P-V2.21.14.190802.Release
[size=17.1429px] 项目背景
[size=17.1429px]1、项目为CLASS C路灯应用,项目位于某港口,节点、网关、NS均为利尔达产品,
[size=17.1429px]2、811个节点,使用利尔达CN470标准LoRaWAN模组,客户使用缺省配置参数,仅配置三要素及class C
[size=17.1429px]3、8个网关,均为4G网关,4G信号较差,平均网络延时100ms+,安装位置在灯杆上
[size=17.1429px]4、整个LoRaWAN网络信号覆盖较好,射频通信质量较好。4G网络存在一定波动。网关部署密度大,上行多路径包较多。
[size=17.1429px] 问题描述
[size=17.1429px]1. 部分节点入网成功后上行数据包在NS端均为mic校验错误
[size=17.1429px]
[size=17.1429px] 问题分析
[size=17.1429px]线索
[size=17.1429px] 1、异常出现在节点join成功后,join完成后节点定时上报数据,但每包数据的mic校验都错误
[size=17.1429px] 2、该现象为偶发异常,项目下有5个异常节点出现,且重新join后能恢复
[size=17.1429px] 3、NS端日志显示异常出现时间附近网关上报的rxpk内pingtime(网关最近一包心跳包的双向通信延时)较大,最大有8s。
[size=17.1429px]
[size=17.1429px]
[size=17.1429px] 4、NS前端显示所有异常节点出现异常前最后两次join使用的通信速率及频点相同
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]分析
[size=17.1429px] 1、数据包MIC在NS及节点侧各自计算,aes数据源为帧内容,秘钥为NwkSKey。因为数据crc校验通过则推断mic校验失败的原因在于双方NwkSKey不一致。
[size=17.1429px]
[size=17.1429px] 2、选择当前还存在异常的设备,根据其最后一次joinRequest中的DevNonce及最后一次JoinAccept中的AppNonce、DevID,和APPKEY手动计算出NwkSKey,与NS上计算的NwkSKey进行对比验证,完全一致,NS侧秘钥计算正确。
[size=17.1429px]
[size=17.1429px]
[size=17.1429px] 3、根据NS后台日志,复查异常节点的rxpk、txpk时间及网关的tmst时间,均无异常,但注意到最后一包JoinAccept的txpk被网关回复 "TOO EARLY"
[size=17.1429px] 4、rxpk内的data字段经base-64解密后获取JoinRequest内容,最后发现异常节点的最后两包JoinRequest内容完全一致,且所有异常节点都是如此。
[size=17.1429px] 问题结果
[size=17.1429px]1、综合以上信息,推断mic校验错误出现的原因:
[size=17.1429px] 节点发起JoinRequest时被多网关收到,大部分网关正常上报至NS,之后选择一个网关正常下发JoinAccept,节点侧入网成功。但是在整个join流程结束后,存在网络延迟极大的网关(十几秒后)才刚刚将节点的JoinRequest上报至NS,该延迟时间远超过NS端多路径包的接收窗口时间。因此NS当做新join包处理,再随机生成一个AppNonce并更新NwkSKey,并下发txpk给网关。网关根据tmst判断出该包时间错误,回复TOO EARLY,不进行下发。NS前端可以看到这最后两轮Join交互,但是实际节点已经在倒数第二轮Join中入网成功,而NS因为延迟上报的rxpk又更新了一次NwkSKey,两端秘钥不一致,导致后续数据mic校验错误。
[size=17.1429px]
[size=17.1429px]2、解决方案:
[size=17.1429px] 该问题由网关网络延迟极大(>10s)导致,客户已完成工程部署,优化4G网络环境可行性较低。因此从NS的角度增加对该异常的识别及处理机制即可:
[size=17.1429px] NS在Join处理流程中加入DevNonce去重处理:NS在下发JoinAccept的txpk后存储该JoinRequest内的DevEUI-DevNonce键值对,并在接收到JoinRequest时判断DevNonce,若与存储值重复则不处理这包rxpk。
[size=17.1429px]
[size=17.1429px] 总结
[size=17.1429px]1、按照以上解决方案处理后,经验证,所有设备工作稳定,异常状况不再复现。
[size=17.1429px]2、Lierda Unicore 3.0 网络服务器本身具备DevNonce判重(防止JoinRequest重放攻击)及网络波动状况下的多路径包处理能力。本次网络延时的时间大于处理预期因而导致异常。
[size=17.1429px]3、经本次NS服务器版本升级后,NS优化了对极差网络条件下LoRaWAN系统的稳定性。
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
|