胡躍華

(朔黃鐵路肅寧分公司，河北 肅寧 062350)

0 引言

朔黃鐵路公司開創(chuàng)了將LTE寬帶移動通信業(yè)務應用到鐵路中的先河，不僅在朔黃鐵路公司尚屬首次，在世界范圍內也屬于首例。該技術在鐵路通信網絡中的應用，可為朔黃鐵路的運輸及各部門的業(yè)務提供更大的帶寬、更多的信息、更安全的管理、更便捷的服務、更高速化的信息管理［1］。在這樣的背景下，加快LTE-R網絡故障的排查速度，提高網絡運行維護效率已經成為保障朔黃鐵路運輸能夠順利進行的趨勢。傳統(tǒng)的以人工排查為主的網絡運行維護方式已經不能夠滿足這種需求。總體來說，提高朔黃鐵路通信運維效率應當解決以下兩個主要問題:一是傳統(tǒng)的通信運維數據，以及分析結果大多以表格、圖片的形式存在，難以獲取鐵路沿線相關具體信息(如:地理位置信息、基站分布狀況、地形地貌等)，導致在分析數據時，不能對鐵路通信網絡的整體狀況進行全面的考慮，提高了發(fā)現(xiàn)故障，以及排除故障的難度;二是通信運維數據的數據量巨大，如果采用傳統(tǒng)的數據存儲及處理方法，存在著存儲空間不足且處理速度較慢、處理效率低下及用戶體驗較差等問題。目前，已有許多專家和學者針對通信網絡運行維護的問題進行了研究，大多集中在民用通信領域［2-4］;也有一些研究人員將GIS(Geographic Information System)技術引入網絡運行維護中，以提高數據分析的全面性，提升可視化效果［5-7］;還有學者將大數據技術應用到網絡運行維護中，以提高系統(tǒng)的數據存儲及處理能力［8-10］。

根據朔黃鐵路公司通信運維的實際需求，將GIS技術以及大數據技術綜合起來，設計并實現(xiàn)了一個基于GIS的通訊運維大數據分析系統(tǒng)。

1 相關技術

1．1 天地圖

天地圖即國家地理信息公共服務平臺，是由國家測繪地理信息局監(jiān)制的地理信息綜合服務平臺，是數字中國的重要組成部分，是運行于互聯(lián)網環(huán)境的國家地理信息公眾服務平臺，通過門戶網站向公眾提供權威、可信、統(tǒng)一的公益性地圖信息服務，通過二次開發(fā)接口提供地理信息服務、資源的增值應用開發(fā)環(huán)境［11］。目前市面上開放的地理信息系統(tǒng)主要有:Google Map、Bing map、百度地圖等。與這些平臺相比，天地圖除了能夠提供相對簡潔、易懂的二次開發(fā)接口之外，還具有一個重要的優(yōu)勢:天地圖采用的坐標系統(tǒng)為CGCS2000，同朔黃通信運維數據中所采用的WGS84坐標系統(tǒng)十分相似，兩個坐標系之間的偏差幾乎可以忽略，利用天地圖進行開發(fā)能夠提升系統(tǒng)與數據的兼容性，以及展示結果的準確性。

1．2 Cloudera大數據平臺

Cloudera是一個企業(yè)級的綜合數據管理平臺，用戶可以通過Cloudera中的工具快速、便捷地實現(xiàn)對Hadoop以及相關大數據組件的安裝和部署，同時，Cloudera也具有較高的數據安全性［12］。其中，Cloudera Impala提供了高效、便捷的大數據查詢服務［13］。不同于Apache Hive，Impala完全拋棄了MapReduce，省掉了MapReduce作業(yè)啟動的開銷，也省去了把中間結果寫入磁盤的步驟，在實時交互式查詢方面更加快捷，極大地提升了數據I/O的速度。Impala與Hive等的關系如圖1所示。

2 系統(tǒng)總體設計

2．1 總體架構

根據朔黃鐵路通信運維的需求，本文提出了一個基于GIS的朔黃鐵路通信運維大數據分析系統(tǒng)。為方便通信運維人員使用，將系統(tǒng)設計為B/S架構，不僅能夠省去安裝部署的工作，同時也能支持通信運維人員在多種終端進行使用。其中，服務端主要由Cloudera搭建的大數據集群提供支持，主要負責數據的存儲及處理;瀏覽器端主要利用天地圖及HTML5等來進行可視化展示。系統(tǒng)的總體架構如圖2所示。

圖1 Impala與Hive關系圖

圖2 系統(tǒng)的總體架構圖

2．2 系統(tǒng)功能設計

系統(tǒng)應當包括以下幾個主要功能:①數據ETL(Extraction-Transformation-Loading)。主要功能是對原始數據進行預處理，包括刪除無效值(如NULL值、空值等)、提取通信事件(如PING事件、Attach事件、Switch事件等);將數據文件類型轉化為CSV文件，上傳到HDFS，并通過Impala把這些數據鏈接到數據表中。②數據分析。數據分析指的是能夠對常見的通信故障(如越區(qū)覆蓋、弱覆蓋、乒乓切換等)進行建模，并根據模型從數據中篩查出常見的通信故障。③可視化展示。利用天地圖將分析結果和地理位置信息以及鐵路沿線基站信息進行集中展示，將存在問題的區(qū)域以直觀、形象的方式展示出來，為通信故障的排查提供輔助決策。

3 關鍵功能實現(xiàn)

3．1 基于Cloudera的數據ETL

數據ETL指的是數據的提取、轉化和加載。朔黃鐵路公司通信運維數據的原始數據大多以XLS和CSV的形式存在，且其中存在著NULL形式的無效值，通信事件如:Ping事件、Attach事件、Switch事件等則以原始信令的形式存在，需要將通信事件發(fā)生的時間，持續(xù)時間，事件結果等內容從原始數據中提取出來。原始數據如圖3所示。

圖3 原始數據

基于Cloudera的數據ETL主要分為以下幾個步驟:步驟一，將數據中存在的無效值“NULL”替換為空字符串;步驟二，從原始數據中提取關鍵事件，主要記錄事件是否成功以及事件的持續(xù)時間，以Attach事件的提取過程為例，通信事件提取過程的偽碼如下:

startTime=0;//事件開始時間

endTime=0;//事件結束時間

isSuccess=false;//事件是否成功

isStart=false;//事件是否開始

for(var item in rawData){//遍歷原始數據

if(item．event．contains(“LTE Msg Attach Request，LTE DataService Connect Request”)＆＆isStart=false)//當開始標志位false，同時看到Attach事件開始標志

isStart=true;//更改開始標志位true

startTime=item．currentTime;//記錄當前時間為開始時間

if(item．event．contains(“LTE Msg Attach Request，LTE DataService Connect Request”)＆＆isStart=true)//當開始標志位為true，同時看到Attach事件開始標志

isSuccess=false;//標記上次事件結果為失敗

duringTime=item．currentTime-startTime;//記錄持續(xù)時間

startTime=item．currentTime;

if(item．event．contains(“LTE Msg Attach Complete，LTE DataService Connect Success”)＆＆isStart=true)//當開始標志位為true，同時看到Attach事件結束標志

isSuccess=true;//標記上次事件結果為成功

duringTime=item．currentTime-startTime//記錄持續(xù)時間

……}

其它事件如:Ping事件、Switch事件提取方法和Attach事件相同;步驟三，將原始數據統(tǒng)一轉化為CSV格式，上傳到HDFS，并通過Impala的load函數，將數據添加到數據表中。

3．2 常見通信故障分析與建模

本功能模塊的主要功能是，針對朔黃鐵路通信運維過程中經常發(fā)現(xiàn)的:“越區(qū)覆蓋”、“弱覆蓋”、“乒乓切換”，這3種常見故障進行建模，并根據模型對原始數據進行分析，從而快速準確地從數據中排查出

此類故障，3種故障模型分別建立如下。

(1)弱覆蓋。弱覆蓋的判別方法較為簡單，對于每一條數據記錄，設定門限為Threshold，該記錄的RSRP值為Valuer，當Valuer＜=Threshold時，則判斷該記錄出現(xiàn)了弱覆蓋現(xiàn)象。

(2)越區(qū)覆蓋。越區(qū)覆蓋是指基站小區(qū)信號越過了本小區(qū)的覆蓋范圍，越區(qū)覆蓋到臨區(qū)，給臨區(qū)帶來嚴重的干擾，引起掉話、頻繁切換等［14］。

從數據中判斷越區(qū)干擾需要通過兩個參數進行判斷:①eNodeBID，即Evolved Node B，LTE中基站的名稱。②PCI(Physical Cell Identity)，物理小區(qū)標識。具體判斷步驟如下:步驟一，將當前數據點的兩個參數與基站信息表進行關聯(lián)，獲取當前連接的基站名稱、經緯度地址等信息;步驟二，根據當前數據點的經緯度信息，從基站信息表中獲取相鄰的兩個基站的名稱;步驟三，如果從相鄰兩個基站中不包含當前所連接的基站，則判定在當前數據點出現(xiàn)了越區(qū)覆蓋。

(3)乒乓切換。乒乓切換指的是在進行通信時，切換到目的小區(qū)后駐留時間過短又立即切回了源小區(qū)［15］。乒乓切換會產生不必要的開銷，增加了切換失敗的概率，同時也會對吞吐量產生影響。判斷乒乓切換是否發(fā)生的具體方法如下:篩選數據中所有的切換事件(handover)，記錄其中切換成功的事件，假設handover事件列表為listh，單個handover事件為一個三元組recordh=(currentTime，PCIpre，PCInext)，設定判定乒乓切換發(fā)生的最小時間minTime=1min，乒乓切換發(fā)生的模式為“ABA”，篩選乒乓切換事件的偽碼如下:

For(i=0;i＜listh．length;i++){

If(listh［i+1］．currentTime-listh［i］．currentTime＜60)//兩次handover事件相差1分鐘以內

If(listh［i+1］．PCInext==listh［i］．PCIpre){

//判定乒乓切換事件，記錄事件發(fā)生的時間、經緯度以及PCI信息

}}

3．3 基于天地圖的可視化展示

本功能主要利用天地圖API，將分析出的通信故障以及能夠反映通信狀況的關鍵指標如RSRP、SINR以及RSRQ等，在天地圖上展示出來，幫助運維人員快速定位故障發(fā)生位置，以及確定故障發(fā)生地點的基站和地理情況。為了實現(xiàn)以上功能需求，基于天地圖的可視化展示主要應當解決兩個問題:①如何利用天地圖繪制鐵路沿線通信狀況以及基站信息。②由于通信運維數據量巨大，而瀏覽器的渲染能力又十分有限，造成在展示時頁面響應速度緩慢，需要考慮一種方法在保證展示效果及準確性的同時提升頁面的響應速度。

針對問題一，研究了天地圖接口API，利用天地圖API提供的TCircle類來繪制圓點，不同顏色的圓點表示數據值的大小，利用天地圖API繪制不同顏色的點的代碼如下:

var config={

strokeColor:"red"，//圓邊線顏色(紅)

fillColor:"red"，//填充顏色(根據該點表示的信號值的大小不同)。

strokeStyle:"solid"http://圓邊線線的樣式，solid或dashed

};

var circle=new TCircle(new TLngLat(lon，lat)，radius，config);//創(chuàng)建一個點對象，并指定點的位置、半徑和配置信息

map．addOverLay(circle);//在地圖上添加點對象

針對問題二，采取的解決方案如下:首先在服務端利用Cloudera impala讀取HDFS中的數據，大大提升了數據讀取的速度。其次，在瀏覽器端采用“分層展示”的策略，當地圖所屬的層級較高時，無需過多展示數據的細節(jié)，所以，當需要繪制大量的數據時，根據層級的不同，對數據進行插值，層級越高，所需展示的數據則越少。同時，層級不同時，為保證所繪制圖形的大小不變，需要實時對繪制圖形的大小進行改變，當繪制的圖形為圓形時，半徑radius與層級zoom滿足如下關系

最后，由于查詢數據庫的速度較慢，在實現(xiàn)策略時應當盡可能減少查詢數據庫的次數?？紤]到在天地圖API中，鼠標滾輪可以觸發(fā)地圖層級的變化，數據庫的查詢操作應當在鼠標滾輪完全停止時進行。本文的策略是記錄最后一次鼠標滾動事件與當前時間的時間差，當時間差大于一定程度時，判斷當前地圖層級，與上一次發(fā)生數據更新時的地圖層級是否相同。如果是，更新數據、重繪地圖并記錄當前層級;反之，則不作任何操作。數據更新策略的算法流程如圖4所示。

在解決以上問題的基礎上，KPI關鍵指標和通信故障便能夠在天地圖上展示出來，具體思路如下:當展示KPI指標及通信事件時，根據KPI指標值的大小或者事件時延的大小來繪制不同顏色的點，根據前述方法將這些點繪制在地圖上，即可對鐵路沿線通信情況進行展示。當展示通信故障時，首先根據所展示通信故障的不同，利用3．2所建立故障模型對原始數據進行篩選，然后根據故障種類的不同，選擇有關的關鍵指標進行展示。例如，當展示弱覆蓋問題時，選擇RSRP指數進行展示，將RSRP值小于閾值的數據點挑選出來，根據RSRP值的大小，在天地圖上繪制不同顏色的點進行展示;當展示乒乓切換的點時，則主要關注PCI值，需要根據PCI值的不同繪制不同顏色的點;當展示越區(qū)覆蓋時，主要關注的則是數據點與基站之間的連接關系，首先繪制出所有沿線的基站，然后將發(fā)生越區(qū)覆蓋的數據點同實際連接的基站用連線表示出來，便可直觀地展示出越區(qū)覆蓋問題。

圖4 數據更新策略流程圖

4 應用效果

4．1 應用環(huán)境

設計的系統(tǒng)在朔黃鐵路公司進行了應用，部署環(huán)境為7臺浪潮英信NX5840的刀片服務器，CPU型號Xeon E5-2620 v2，內存容量為8 GB，操作系統(tǒng)為Centos6．5。其中一臺作為網站服務器，網站發(fā)布環(huán)境為Tomcat8．0和jdk1．8．0_91。

4．2 實現(xiàn)效果

為測試系統(tǒng)的實現(xiàn)效果，導入朔黃鐵路實際網絡運維數據進行測試，數據反映的是肅寧北到黃驊港區(qū)段的通信狀況。實現(xiàn)效果如圖5所示。

圖5(a)是對鐵路沿線通信RSRP指數的分析和展示，通過不同的顏色來指示不同的RSRP值;圖5(b)通過對原始數據的分析，展示出現(xiàn)乒乓切換問題的地區(qū)，可以看到對問題發(fā)生的地點和基站信息都能夠從圖中方便地獲取;圖5(c)展示的是出現(xiàn)越區(qū)覆蓋問題的地點和基站信息，可以看到圖中基站的覆蓋區(qū)域顯然超過了正常范圍;圖5(d)是對原始數據中Ping事件發(fā)生情況進行分析，并利用不同顏色的點展示出在鐵路沿線進行Ping事件時的時延情況。通過實現(xiàn)效果可以看出，本系統(tǒng)能夠直觀、形象地展現(xiàn)出鐵路沿線的通信狀況，并迅速地從數據中排查出存在的通信故障。

圖5 系統(tǒng)實現(xiàn)效果

5 結論

針對朔黃鐵路通信運維的具體需求，設計并實現(xiàn)了一個基于GIS以及大數據技術的朔黃鐵路通信運維大數據分析系統(tǒng)。利用Cloudera大數據平臺，解決了大規(guī)模通信運維數據存儲及處理的問題;通過數據ETL過程將原始通信運維數據進行清洗，并將通信事件如Ping事件、Attach事件、Switch事件等提取出來;對通信故障進行建模，使得本系統(tǒng)能夠將常見的通信故障如:越區(qū)覆蓋、乒乓切換、弱覆蓋等從數據中篩選出來，大大節(jié)約了人工的開支。天地圖API的使用，不僅能夠將鐵路沿線的通信狀況直觀、形象地展示出來，并能夠將周邊地理信息以及基站信息等一并展示給用戶，為故障排查和檢修提供了便利，大大提升了朔黃鐵路公司通信運維的效率，具有較高的實用價值。今后的工作將主要集中在豐富故障模型，提供常見問題的維修建議，真正實現(xiàn)整個通訊網絡的信息化管理。