基于天地圖的朔黃鐵路通信運維數(shù)據(jù)分析系統(tǒng)設(shè)計與實現(xiàn)

胡躍華

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

0 引言

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

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

1 相關(guān)技術(shù)

1．1 天地圖

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

1．2 Cloudera大數(shù)據(jù)平臺

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

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

2．1 總體架構(gòu)

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

圖1 Impala與Hive關(guān)系圖

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

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

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

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

3．1 基于Cloudera的數(shù)據(jù)ETL

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

圖3 原始數(shù)據(jù)

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

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

endTime=0;//事件結(jié)束時間

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

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

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

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

isStart=true;//更改開始標(biāo)志位true

startTime=item．currentTime;//記錄當(dāng)前時間為開始時間

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

isSuccess=false;//標(biāo)記上次事件結(jié)果為失敗

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

startTime=item．currentTime;

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

isSuccess=true;//標(biāo)記上次事件結(jié)果為成功

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

……}

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

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

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

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

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

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

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

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

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

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

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

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

}}

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

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

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

var config={

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

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

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

};

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

map．a(chǎn)ddOverLay(circle);//在地圖上添加點對象

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

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

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

圖4 數(shù)據(jù)更新策略流程圖

4 應(yīng)用效果

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

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

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

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

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

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

5 結(jié)論

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