胡躍華

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

0 引言

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

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

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

1．1 天地圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

startTime=0;//事件開始時(shí)間

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

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，同時(shí)看到Attach事件開始標(biāo)志

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

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

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

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

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

startTime=item．currentTime;

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

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

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

……}

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

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

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

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

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

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

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

(3)乒乓切換。乒乓切換指的是在進(jìn)行通信時(shí)，切換到目的小區(qū)后駐留時(shí)間過短又立即切回了源小區(qū)［15］。乒乓切換會(huì)產(chǎn)生不必要的開銷，增加了切換失敗的概率，同時(shí)也會(huì)對吞吐量產(chǎn)生影響。判斷乒乓切換是否發(fā)生的具體方法如下:篩選數(shù)據(jù)中所有的切換事件(handover)，記錄其中切換成功的事件，假設(shè)handover事件列表為listh，單個(gè)handover事件為一個(gè)三元組recordh=(currentTime，PCIpre，PCInext)，設(shè)定判定乒乓切換發(fā)生的最小時(shí)間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ā)生的時(shí)間、經(jīng)緯度以及PCI信息

}}

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

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

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

var config={

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

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

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

};

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

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

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

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

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

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

4 應(yīng)用效果

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

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

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

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

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

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

5 結(jié)論

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