G3-PLC Keepalive网络维护机制设计

王蓉 邵镜昇 张健宏

(杭州万高科技股份有限公司 浙江杭州 310000)

电力系统本身所支持的通信方式多种多样，电力线载波通信技术利用电力线缆作为信号传输媒介，在不同网络节点间交换信息与数据[1-2]，是一种无需额外物理媒介的有线通信方式，也是构建智能电网的重要手段。G3-PLC 路由机制是一种国际通用的电力线载波通信技术体系，具有自愈、自组织、多跳式等特性的mesh网络拓扑结构[3]，近年来逐渐受到广泛关注[4]。高速电力线载波抄表方案的网络架构由物理层、数据链路层和应用程序层组成[5]，但现有的G3-PLC 标准仅定义了物理层和数据链路层，并未规定具体的网络维护方法。在没有合适的网络维护机制设计时，路由端因意外导致原网络失效（复位、频段更换等）后，表端并不知情，会保持当下已组网状态，不进行重新入网的动作，但实际上这种状态下该载波网络并不能再进行抄表、上报等动作，影响正常使用。

为继续抄表作业，可以手动对表端进行复位，但多数情况下表端数量远超路由端，且分布较广，逐一手动复位工程量大；也可以设定一个长时间不通信后自动复位时间，但该时间一般设置的较长，将导致抄表等作业长时间卡顿。为解决上述问题，各应用平台拟定了不同的网络维护方案。以下是两种较为常用或得到过批量运用的方案。

方案一：定时发送数据帧确认状态。建立连接时，关联一组定时器，当定时器倒计时结束时，向对方发送探测数据包。如果能收到回复帧，说明连接仍在继续；如果对方因重新启动等原因已失去连接，则无法收到回复帧，可以认为连接已失效[6]，需要重新建立连接。这种方法协议简单，实现方便，但不能保证及时发现连接失效状况，响应存在迟滞。

方案二：路由端在重启后发送私有“广播召唤”数据包让表端重新入网。当路由端因意外使原网络失效后，为更快通知所属网络中的表计重新关联到本集中器，集中器在组建新网络成功后，将下发私有“广播召唤”数据包，当从模块收到时，延时原报文中定义的时间后复位并重新入网，并且优先以收到报文中定义的频段内尝试。该方法能及时恢复正常组网状态，但因广播召唤仅在重启后发送，若有从节点因干扰或其他原因，未能及时收到广播召唤，则无法重新入网，这些节点无法再进行正常的抄读、上报等任务，直至长时间不通信后自动复位。这种方法虽然保证了时效性，但抗干扰效果不佳，存在个别节点长时间无法通信的隐患。

本文根据大量现场使用经验，提出了一种更为灵活高效的网络维护方案，该方案不仅可以在路由重启时保障表端迅速响应，也能在日常运作时维护网络，并已在Vango V63xx+V600x 平台上运用Vango Keepalive私有机制得以实现。

1 Vango Keepalive网络维护机制设计方案

1.1 环境架构

在典型的电网环境中，电表及搭载于上的表端通信模块分布于各个区域内，因与集中器间的物理距离、线路干扰等原因，产生自然分级，可与搭载于集中器上的路由模块直接通信的称之为一跳节点，一跳节点可收到一跳广播信号，需要一跳节点进行中继的称为二跳节点，可收到二跳广播信号，以此类推。基本环境如图1所示。

图1 基本环境架构示意图

当电网环境上电后，万高模块Keepalive 机制即开始启动。集中器将提供主节点地址给路由模块（CCO），路由模块根据主节点地址换算成台区编号（PAN ID），Keepalive机制则用台区标编号作为发送Keepalive帧参数之一，用以区分确认对应的集中器。路由模块借由电力线载波通道发出keepalive帧，表模块（STA）接收到上一跳的Keepalive帧后，等待一段时间后，再转送Keepalive帧给下一跳模块。后续以此类推。

将环境架构图1切换为实际拓扑图后即为图2。

图2 实际拓扑结构示意图

Keepalive机制是以广播的方式借助中继节点一跳一跳地扩散出去，确保每个能组上网的表模块都可以接收到维护信号并响应这些信息。

1.2 重启复位实现

路由模块透过Keepalive 帧广播通知全部组网上的表模块关于该台区的状态信息，其中包含了Keepalive 序号（SEQ）。路由模块重启时，SEQ 会被更新，数值将增加1，以此示意该台区申请重新入网动作。

表模块收到Keepalive 帧后，会与自身记录的SEQ进行对比，如果收到的SEQ 与模块本身纪录的SEQ 相同，则认为当前网络状态正常，保持状态不变；若收到的SEQ 与模块本身纪录的SEQ 不同，则认为当前网络已失效，需执行重新入网流程，故表模块从已入网状态转换为未入网状态，再次执行入网流程，同时更新表模块Idle Time，重新计数8 h 复位定时器，并转送Keepalive帧信息。即当路由模块重启时，会更新Keepalive序号，表模块会收到与本身记录不同的Keepalive 序号，因此转换为重新入网状态。该方法保障了网络失效后能够及时恢复[7]。

机制发送方式源码如下：

因线路干扰等原因，表端可能未能及时收到路由模块发出的Keepalive 帧，因此路由端设计为重复定时发送维护封包，通过多次尝试提升成功率。为规避多次发送造成的重复复位问题，故广播帧中夹带的SEQ等信息，还能使表端对该类型帧能进行有效分析，当SEQ 与集中器一致则无需复位，从而支持路由模块定时对表模块进行网络维护，而不是如广播召唤数据包一样仅在重启阶段发送，有效避免了部分从节点未及时收到错过复位消息的隐患。根据实际使用经验设置发送间隔周期为30 min，若有从节点未及时收到重启后的Keepalive封包，也有机会在下一次Keepalive封包转发时完成重新入网，无需等待较长的“无通信自主复位时间”，优化了系统运转效率，提升了系统稳定性。

1.3 设备正常运作阶段网络维护

区别于定时发送数据帧和广播召唤这两种方案，Keepalive机制用途更加广泛。不仅可用于实现重启复位，也可用于设备正常运作阶段定时的网络维护。能够让路由端更清晰地掌握拓扑信息，传递相位信息，让表端确认自身是否离网等，相关运作流程见图3。

图3 Keepalive机制运作流程图

表模块收到上一跳Keepalive 帧后，将进行转发等待，之后将收到的Keepalive 帧封包内的跳数加一后再进行转发。后续以此类推。表模块有两组周期定时器，其一为转发等待时间（Forwarding Wait Time, FTW），将使用20 s内的随机数再加上10 s的跳数阶级倍数。

当定时器时间到后转发Keepalive 帧。另一定时器是重置转发时间（Reset Forwarding Time, RFT），将根据实际需求设置重置转发时间，在这期间内收到任何Keepalive帧，皆视为无效封包，合理减轻网络负担。等待机制方法源码如下：

该运作流程有效保障Keepalive 机制运行稳定，集中器执行抄表业务或线路上有表模块正在入网等，也基本不会对Keepalive机制的执行造成影响。

Keepalive 帧中包含Keepalive 序号（SEQ）、台区编号（Pan ID）、跳数（Hop-Count）、相位（phase）等信息，网络维护机制信息说明表见表1。

表1 网络维护机制信息说明表

这些信息的传递能有效进行网络维护，并辅助完成以下扩展功能。

（1）网络拓扑采集：G3-PLC 标准并未对网络拓扑获取进行具体规定，使用Keepalive 机制，路由端可以获取表端跳数信息，从而掌握当前拓扑。

（2）相位信息传递：搭配过零检测电路，Keepalive机制可以传递相位信息，完善载波网络维护必备信息。

（3）加速异常状态侦测：电力线载波通信网络在运行过程中，链路质量容易受到信道时变造成的影响，可能会出现通信链路失效的问题[8]，Keepalive 机制能有效提升表端发现该问题的效率。基于路由端定时发送与表端相应转发规则，从节点若在4 个Keepalive 周期（2 h），均未收到Keepalive帧，可以判定自己已离线，并进行自行复位再次寻找可靠路由。

2 实验验证与分析

为充分证明所提网络维护机制的有效性，本文在Vango V63xx+V6000平台上进行了实验验证。

2.1 Vango V63xx+V6000平台

V6306 是一个窄带电力线通信处理器芯片，集成了一个32位MCU，一个32位DSP，两个UART接口，一个SPI Master 控制器，一个SPI Slave 接口，1 个I2C 主Master 接口，PLC MAC/PHY 层功能和仿真前端。加上Vango的大电流驱动的线路驱动器芯片（V6000），它形成了一个完整的调制解调器解决方案平台，支持窄带PLC标准。

该平台已通过由日本TÜV Rheinland 实验室进行的G3-PLC协议相关认证，包括FCC频段和CENELEC_A频段。

2.2 Keepalive机制有效性验证

此次验证中，应用端使用通用协议，路由端通信协议采用GDW 1376.2，表端通信协议采用DL/T645[9]。

首先搭建载波通信环境，使表端和集中器端至于同一通信网络中，并对表模块和路由模块进行监控。让表端和集中器端正常组网，并通过1376.2 协议查询入网情况，如表2所示。

使用串口工具模拟集中器[10]，对路由模块应用串口发送AFN=10H-F2（查询从节点信息），得到当前有1个从节点应答，从节点地址为：000300019805，该地址与实际表号相符合。串口发送AFN=10H-F21（查询网络拓扑信息）确认，结果与10H-F2一致，可以确认该从节点已入网。之后手动复位路由端，通过AFN=03HF10（本地通信模块运行模式信息，重启时会推上行报文，可见表3）确认路由模块已重启。

表3 重启复位AFN

监控表端接收报文，观测到在3 s 后，表端收到Keepalive 帧，并能解析出SEQ、PAN_ID、Phase 等讯息。之后进入重新入网流程，并转发keepalive帧，详见图4。证明Keepalive 机制在路由模块重启后，可使表模块进行重新入网，有效避免手动操作，且响应时间较短，运作高效。

监听表端接收报文，观测到在30 min后，表端收到Keepalive 帧，证明路由端进行了定时发送，如图5 所示。重复多次发送能有效避免第一批未收到Keepalive帧的模块一直处于通信异常状态，且不会影响已正常入网模块状态。

图5 30 min后表端监听报文

以上测试证实Keepalive 机制符合理论预期，能有效进行网络维护。

3 结语

本文首先介绍了两种较为常见的网络维护机制设计方案，针对目前方案的问题，提出了Vango设计并在自研平台已实现的一种Keepalive 网络维护机制。不同于以往方案只考虑单一因素，改进方案要同时考虑时效性和可靠性，在保证路由重启后表端能及时入网的基础上，确保了单次未能重入网模块能在较短时间内恢复正常工作状态。另一方面，该机制更加灵活易扩展，在正常工作状态亦可进行网络维护，可协助路由端确认拓扑状态、掌握相位讯息，在链路失效时，加速表端确认速度。最后通过实验验证该机制的可行性。未来研究方向将考虑在已有机制下，根据实际需求扩展相应内容，使机制更具有实际工程使用价值，适用于不同的应用环境和市场。