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 網絡維護機制。不同于以往方案只考慮單一因素，改進方案要同時考慮時效性和可靠性，在保證路由重啟后表端能及時入網的基礎上，確保了單次未能重入網模塊能在較短時間內恢復正常工作狀態。另一方面，該機制更加靈活易擴展，在正常工作狀態亦可進行網絡維護，可協助路由端確認拓撲狀態、掌握相位訊息，在鏈路失效時，加速表端確認速度。最后通過實驗驗證該機制的可行性。未來研究方向將考慮在已有機制下，根據實際需求擴展相應內容，使機制更具有實際工程使用價值，適用于不同的應用環境和市場。