網(wǎng)優(yōu)大數(shù)據(jù)定位算法研究與應(yīng)用課件

網(wǎng)優(yōu)大數(shù)據(jù)定位算法研究與應(yīng)用山西移動2017年7月網(wǎng)優(yōu)大數(shù)據(jù)定位算法研究與應(yīng)用山西移動1基于OTT定位平臺及應(yīng)用

2基于軟硬采相結(jié)合的樓宇KPI分析目錄

3基于MR的高負荷小區(qū)分流1基于OTT定位平臺及應(yīng)用2基于軟硬采相結(jié)合的樓采集層…數(shù)據(jù)預(yù)處理共享層應(yīng)用層

16年底OTT平臺已在全省11地市推廣應(yīng)用，支撐日常集中分析中的覆蓋分析和網(wǎng)絡(luò)結(jié)構(gòu)分析。目前平臺日處理160G的MR北向文件，生成87億采樣點數(shù)據(jù)。實現(xiàn)對全省城區(qū)34萬棟樓宇進行覆蓋評估，占比74%，對全省城區(qū)1-5級道路、高速和高鐵全段進行覆蓋評估。應(yīng)用常駐用戶識別算法對居民區(qū)、寫字樓、高校、城中村等重點場景進行長期覆蓋質(zhì)量評估。McGbIuPSGnLTE-S1LTE-S6aLTE-SGs……編解碼子系統(tǒng)編解碼子系統(tǒng)解碼合成關(guān)聯(lián)回填預(yù)統(tǒng)計業(yè)務(wù)識別解碼合成關(guān)聯(lián)回填預(yù)統(tǒng)計業(yè)務(wù)識別數(shù)據(jù)加載數(shù)據(jù)關(guān)聯(lián)數(shù)據(jù)聚合數(shù)據(jù)統(tǒng)計數(shù)據(jù)挖掘分布式實時流處理系統(tǒng)分布式數(shù)據(jù)庫FTP/WebService/CS道路模擬測試室內(nèi)模擬測試特殊場景分析樓宇透視競對分析用戶級分析網(wǎng)絡(luò)規(guī)劃4G倒流問題點……無覆蓋區(qū)域識別系統(tǒng)管理層接口管理日志管理配置管理系統(tǒng)自監(jiān)控外部系統(tǒng)接口1.1OTT平臺架構(gòu)-平臺功能采…數(shù)共應(yīng)16年底OTT平臺已在全省11地市推廣MR數(shù)據(jù)采集：3臺采集服務(wù)器，實時采集北向服務(wù)器中的MRO數(shù)據(jù)

（每天MRO數(shù)據(jù)約160G）。數(shù)據(jù)庫服務(wù)器：2臺存儲服務(wù)器，存儲及運算匹配后的OTT數(shù)據(jù)業(yè)支大數(shù)據(jù)平臺租戶：需每天關(guān)聯(lián)1.2T的MRO文件，XDR及指紋庫數(shù)據(jù)，租戶分配1T內(nèi)存、300CPU、300T存儲，每天8點開始前1天數(shù)據(jù)的計算，計算時長約10小時。新增httpcontent_ul和httpcontent_dl字段每天8T，保留3天數(shù)據(jù)應(yīng)用端：1臺服務(wù)器提供BS訪問的WEB服務(wù)器和提供CS訪問及數(shù)據(jù)預(yù)處理1.1OTT平臺架構(gòu)-IT架構(gòu)MR數(shù)據(jù)采集：3臺采集服務(wù)器，實時采集北向服務(wù)器中的MRO數(shù)1.1OTT平臺架構(gòu)-數(shù)據(jù)處理Hadoop集群1.實時從北向MR服務(wù)器采集15分鐘粒度MR文件，解析形成txt格式文件2.將解析后的MR數(shù)據(jù)通過FTP實時上傳到業(yè)支大數(shù)據(jù)平臺接口機3.接口機的flume程序再將MR文件上傳到業(yè)支租戶的HDFS目錄下4.堡壘機采用Spark處理架構(gòu)，通過大數(shù)據(jù)平臺的Oozie調(diào)度模塊關(guān)聯(lián)MR和XDR及指紋庫的計算5.通過業(yè)支大數(shù)據(jù)平臺的FTP分發(fā)模塊，將計算結(jié)果輸出到本地數(shù)據(jù)庫中6.將數(shù)據(jù)應(yīng)用處理結(jié)果進行分發(fā)和呈現(xiàn)123456網(wǎng)管域業(yè)支域硬采數(shù)據(jù)S1-MME/SGS/S6a硬采解析服務(wù)器用戶面數(shù)據(jù)S1-U統(tǒng)一DPI設(shè)備網(wǎng)管設(shè)備采集側(cè)新增httpcontent_ul和httpcontent_dl字段：解出http請求及響應(yīng)報文的content部分，按照16進制碼流輸出在xdr（S1-U）后面，即在原來的xdr增加字段httpcontent_ul和httpcontent_dl。上行長度要求小于3000字節(jié)，下行長度要求小于1500字節(jié)。數(shù)據(jù)安全：XDR信息入庫前業(yè)支大數(shù)據(jù)平臺已對關(guān)鍵信息進行脫敏處理，廠家無法接觸到用戶信息1.1OTT平臺架構(gòu)-數(shù)據(jù)處理Hadoop集群1.實時從北1.1OTT平臺架構(gòu)-搭建中遇到的問題數(shù)據(jù)問題調(diào)度問題網(wǎng)絡(luò)問題接口機問題OTT平臺搭建的問題問題問題定位解決措施MR數(shù)據(jù)缺失1.MR北向服務(wù)器IP地址發(fā)生變化導(dǎo)致MR采集服務(wù)器無法連通1.與網(wǎng)管中心商議，后續(xù)網(wǎng)管涉及MR北向服務(wù)器的操作必須郵件或工單至網(wǎng)優(yōu)中心；2.OMC側(cè)未開啟測量任務(wù)2.通過工單明確MR常態(tài)化及全量開啟時間段，每地市指定MR負責人，常態(tài)化臨時關(guān)閉及全量測量項開啟前必須通知網(wǎng)優(yōu)中心相關(guān)負責人；3.MR全量開啟后，MR采集服務(wù)器無法全部解析3.擴容采集服務(wù)器；http字段無法錄入大數(shù)據(jù)平臺1.需求提出錯誤，OTT平臺需要16進制文本格式的原始碼流，而非提出的二進制的原始碼流1.按照16進制文本格式入庫2.http原始碼流沒有明確的關(guān)鍵字，不能錄入業(yè)支大數(shù)據(jù)平臺庫中2.DPI解析廠家對HTTP碼流進行標識網(wǎng)絡(luò)不通涉及網(wǎng)管網(wǎng)和業(yè)支網(wǎng)兩個域，需要打通網(wǎng)絡(luò)MR采集服務(wù)器與接口機打通，本地數(shù)據(jù)庫服務(wù)器與接口機打通網(wǎng)絡(luò)數(shù)據(jù)處理中需在網(wǎng)管網(wǎng)和業(yè)支網(wǎng)來回切換網(wǎng)管網(wǎng)和業(yè)支網(wǎng)分屬兩個域?qū)~號進行VPN授權(quán)接口機會停止工作，導(dǎo)致文件不上傳每天對6TMR數(shù)據(jù)進行上傳，分配的資源無法滿足接口機賬戶下的空間進行擴容Oozie調(diào)用Spark程序經(jīng)常失敗隊列資源不足、隊列調(diào)度優(yōu)先級低和集群的調(diào)度方式等方面存在問題對調(diào)度優(yōu)先級由最低提升至中級，并進行硬件擴容上傳指紋庫時無法長時間連接堡壘機堡壘機只能通過業(yè)支4A云桌面進行操作，云桌面因為有超時斷開的機制（超時門限在20分鐘以內(nèi)），導(dǎo)致與堡壘機的ssh連接會中斷設(shè)置長任務(wù)保護機制，對于長任務(wù)操作，保護時間延長1.1OTT平臺架構(gòu)-搭建中遇到的問題數(shù)據(jù)問題調(diào)度問題網(wǎng)絡(luò)用戶常駐地數(shù)據(jù)庫常駐樓宇常駐小區(qū)道路柵格指紋庫MRXDR高速運動用戶靜止用戶未知狀態(tài)用戶1.2重點工作1-經(jīng)緯度信息回填關(guān)聯(lián)位置采樣點未關(guān)聯(lián)位置采樣點更新指紋庫道路指紋回填道路回填采樣點更新用戶常駐地指紋庫常駐位置經(jīng)緯度回填關(guān)聯(lián)位置采樣點未關(guān)聯(lián)位置采樣點常駐用戶識別常駐用戶非常駐用戶OTT高精度指紋庫回填關(guān)聯(lián)、運動狀態(tài)識別高精度OTT采樣點MR回填率不足5%仿真指紋庫回填常駐用戶可以回填32%的MR采樣點OTT指紋庫可以回填46%，剩余采樣點使用仿真指紋庫回填整體MR100%回填位置信息

OTT數(shù)據(jù)直接關(guān)聯(lián)MR信息，位置信息回填率不足5%，通過識別常駐用戶識別、搭建OTT指紋庫、傳統(tǒng)仿真指紋庫進行全量MR采樣點經(jīng)緯度回填。用戶常駐地數(shù)據(jù)庫道路柵格指紋庫MRXDR高速運動用戶靜止用戶通過建立用戶常駐位置模型，識別常駐區(qū)域，通過OTT數(shù)據(jù)對常駐用戶賦值經(jīng)緯度信息。1、基于用戶周期性潮汐類別對用戶常駐位置進行場景劃分：常駐類型說明時段特征白天常駐適用于普通上班族的工作地常駐位置模型9:00-12:0014:00-17:00晚上常駐適用于在晚上工作的人群和家庭常駐位置模型17:00-24:00夜間常駐適用于在夜間工作的人群和家庭常駐位置模型0:00-9:002、用戶小區(qū)駐留時長（頻次）算法：空閑態(tài)3、用戶分場景常駐位置(小區(qū)組)建模算法：常駐類型算法白天常駐位置用戶在連續(xù)15天內(nèi)的9:00—12:00&14:00—17:00至少8天在同一小區(qū)下空閑態(tài)駐留頻次+業(yè)務(wù)態(tài)駐留頻次≥3，則該小區(qū)判定為一個該用戶的白天常駐小區(qū)晚上常駐位置用戶在連續(xù)15天內(nèi)的17:00—24:00至少8天在同一小區(qū)下空閑態(tài)駐留頻次+業(yè)務(wù)態(tài)駐留頻次≥3，則該小區(qū)判定為一個該用戶的晚上常駐小區(qū)夜間常駐位置用戶在連續(xù)15天內(nèi)的0:00—9:00至少8天在同一小區(qū)下空閑態(tài)駐留頻次+業(yè)務(wù)態(tài)駐留頻次≥3，則該小區(qū)判定為一個該用戶的夜間常駐小區(qū)4、用戶分場景常駐位置模型（小區(qū)組）輸出：用戶(IMSI)白天常駐CI1、CI2……CIN（輸出0-N個小區(qū))晚上常駐CI1、CI2……CIN（輸出0-N個小區(qū))夜間常駐CI1、CI2……CIN（輸出0-N個小區(qū))業(yè)務(wù)態(tài)基于S1_MME消息的TAU_TYPE=3的TAU，（T3412，現(xiàn)網(wǎng)設(shè)置為54min），即用戶在持續(xù)空閑態(tài)1小時內(nèi)一定會觸發(fā)TAU_TYPE=3的TAU，以小時粒度統(tǒng)計用戶在對應(yīng)小區(qū)下的駐留小時頻次基于S1-U消息各類話單，例，用戶單天特定時段內(nèi)在同一小區(qū)的3個小時時段均產(chǎn)生過S1-U話單記錄即認為在該小區(qū)的業(yè)務(wù)態(tài)駐留頻次為31.2重點工作1-常駐用戶識別通過建立用戶常駐位置模型，識別常駐區(qū)域，通過OTT數(shù)據(jù)對常駐

隨著各大互聯(lián)網(wǎng)公司（百度、騰訊、阿里巴巴）的LBS業(yè)務(wù)（基于位置服務(wù)LocationBasedService）的高速發(fā)展，已經(jīng)獲取了準確的用戶位置分布和遷徙規(guī)律的大數(shù)據(jù)！

目前我們已經(jīng)使用互聯(lián)網(wǎng)公司中OTT數(shù)據(jù)來支撐4G覆蓋優(yōu)化工作，在競對分析、無覆蓋區(qū)域識別、新建場景覆蓋需求、流量經(jīng)營等方面需要借助互聯(lián)網(wǎng)公司的全量用戶進行輔助分析。

OTT數(shù)據(jù)支撐4G弱覆蓋區(qū)域優(yōu)化目前無法支撐全量用戶分析，需要借助互聯(lián)網(wǎng)數(shù)據(jù)無覆蓋競對新場景覆蓋流量經(jīng)營1.3重點工作2-全量用戶挖掘隨著各大互聯(lián)網(wǎng)公司（百度、騰訊、阿里巴巴）的L目前國內(nèi)主要用戶大數(shù)據(jù)平臺有高德（阿里巴巴系）、百度、騰訊，對三家位置數(shù)據(jù)，高德數(shù)據(jù)優(yōu)勢為商家數(shù)據(jù)和住戶的門牌位置信息；百度優(yōu)勢為導(dǎo)航、道路熱力分布；騰訊優(yōu)勢為用戶的位置分布數(shù)據(jù)較為豐富。最終決定優(yōu)先解析騰訊系位置數(shù)據(jù)。POI信息準確且量大，但是用戶數(shù)相對較少主要為道路用戶較多，居民區(qū)用戶少且不連續(xù)用戶呈現(xiàn)多且集中，位置數(shù)據(jù)準確1.3重點工作2-互聯(lián)網(wǎng)全量數(shù)據(jù)對比目前國內(nèi)主要用戶大數(shù)據(jù)平臺有高德（阿里巴巴系）APP在呈現(xiàn)前發(fā)送請求APP，可以get到了對應(yīng)的網(wǎng)頁用Python的requests庫模擬請求返回25*25攜帶經(jīng)緯度和用戶數(shù)的柵格信息Get到含有位置信息數(shù)據(jù)的頁面最終爬取到的全量用戶信息1.3重點工作2-微信全量用戶信息挖掘

通過微信中的應(yīng)用APP爬取到全量用戶的位置信息。太原一天微信用戶分布太原一天MR分布圖APP在呈現(xiàn)前發(fā)送請求APP，可以get到了對應(yīng)的網(wǎng)頁用Py1、有用戶無4G覆蓋區(qū)域：新建企業(yè)用戶覆蓋需求區(qū)域2、發(fā)現(xiàn)新用戶覆蓋需求：1.3重點工作2-全量用戶信息應(yīng)用3、指導(dǎo)室分建設(shè)-覆蓋：太原太榆路公路局宿舍區(qū)域有微信用戶較多，但是大部分區(qū)域無MR采樣點呂梁市新建兩個礦區(qū)，從微信來看該區(qū)域已經(jīng)投入使用，有4G網(wǎng)絡(luò)需求太原恒大綠洲小區(qū)，微信用戶較多且分布較密集，但是4G覆蓋較差，建議通過室分解決深度覆蓋問題5、競對輔助分析：移動聯(lián)通電信朔州市右玉縣用戶分布，山岔口村用戶較多，聯(lián)通有站點覆蓋，但是移動缺少站點晉中大學(xué)城從用戶分布來看主要集中在理工大和醫(yī)科大學(xué)中5棟宿舍樓3、指導(dǎo)室分建設(shè)-容量：1、有用戶無4G覆蓋區(qū)域：新建企業(yè)用戶覆蓋需求區(qū)域2、發(fā)現(xiàn)新三弱一無問題庫權(quán)重過濾集中優(yōu)化、規(guī)劃優(yōu)化規(guī)劃集中優(yōu)化督辦平臺分公司現(xiàn)場優(yōu)化規(guī)劃設(shè)計審核平臺分公司現(xiàn)場勘察歸檔庫重點問題庫需求庫樓宇弱覆蓋道路弱覆蓋街區(qū)弱覆蓋微信無覆蓋輸出樓宇面積、高度、覆蓋指標，面積大于3000平米，高度大于20米，室分需求輸出弱覆蓋路段距離，弱覆蓋指標，四級五級弱覆蓋距離低于200米，微站需求輸出街區(qū)弱覆蓋，包含樓宇等?；揪嚯x>500米，高度平均<30米，宏站需求用微信用戶匹配4G覆蓋，過濾有用戶無覆蓋區(qū)域,結(jié)合場景規(guī)劃宏站或者室分

根據(jù)精準定位，對網(wǎng)絡(luò)覆蓋問題進行集中優(yōu)化以及以及自上而下的規(guī)劃，有效解決深度覆蓋問題“深入難”，“定位難”，“優(yōu)化難”以及“跟蹤難”的問題。根據(jù)業(yè)務(wù)密度，用戶特性，劃分高校、商城、VIP重要場景。按照覆蓋率低于80%，并且競對指標超過5%規(guī)則匹配街區(qū)。結(jié)合用戶投訴位置，樓宇，匹配街區(qū)，定位覆蓋情況按照小區(qū)高流大于600M；高倒大于300M標準匹配街區(qū)。業(yè)務(wù)密度高倒高流用戶投訴競爭對手小區(qū)維度優(yōu)點：評估方便缺點：弱覆蓋區(qū)域無法確定。定位困難，效率低，針對單一小區(qū)進行優(yōu)化柵格維度優(yōu)點：弱覆蓋區(qū)域定位準確缺點：解決后弱覆蓋區(qū)域發(fā)生變化，評估困難街區(qū)維度結(jié)合小區(qū)和柵格維度對全省按照街、路進行劃分為固定區(qū)域，對區(qū)域進行整體分析評估。分析問題街區(qū)時，按照室外柵格和室內(nèi)物業(yè)點進行聚類，得到弱覆蓋問題區(qū)域分析維度1.4重點工作3-OTT平臺支撐集中分析??

三弱一無問題庫權(quán)重過濾集中優(yōu)化、規(guī)劃優(yōu)化規(guī)劃集中優(yōu)化督辦平臺集中優(yōu)化功能樓宇覆蓋渲染樓宇弱覆蓋匯聚街區(qū)覆蓋渲染室外弱覆蓋區(qū)域1.4重點工作3-OTT平臺支撐集中分析識別街區(qū)中的室內(nèi)覆蓋情況，輸出“點”弱覆蓋樓宇進行分析室外專題功能通過街區(qū)進行“面”的弱覆蓋區(qū)域識別識別街區(qū)中的室外覆蓋情況，輸出“線”弱覆蓋路段及室外區(qū)域進行分析集中優(yōu)化功能樓宇覆蓋渲染樓宇弱覆蓋匯聚街區(qū)覆蓋渲染室外弱覆蓋通過多維度數(shù)據(jù)關(guān)聯(lián)輸出優(yōu)化/規(guī)劃區(qū)域：通過樓宇分析，支撐深度覆蓋分析，輸出競對劣化樓宇：1.4重點工作3-OTT平臺支撐集中分析通過多維度數(shù)據(jù)關(guān)聯(lián)輸出優(yōu)化/規(guī)劃區(qū)域：通過樓宇分析，支撐深度支撐集中分析-精準規(guī)劃、自上而下提出需求MR弱覆蓋：累計輸出問題點1046余處，聯(lián)合地市規(guī)劃宏站706，室分28，微站59，其他納入優(yōu)化。城區(qū)場景：室分：根據(jù)樓宇面積、高度、覆蓋指標，面積大于3000平米，高度大于20米，弱覆蓋占比超過30%的建筑微站：居民住宅小區(qū)或者城區(qū)五級弱覆蓋距離低于200米宏站：根據(jù)街區(qū)弱覆蓋指標，包含樓宇信息等。弱覆蓋占比超過30%，距離周邊最近基站距離>500米，界區(qū)內(nèi)建筑物高度平均<30米。農(nóng)村場景：弱覆蓋區(qū)域中心距離最近基站大于1000米，覆蓋率低于70%納入宏站需求競對弱覆蓋：累計輸出問題點4532余處，聯(lián)合地市規(guī)劃宏站1815，皮站13，室分75，微站153，其他納入優(yōu)化。競對小區(qū)選取規(guī)則：移動MR覆蓋率低于80%，競對高于80%（“我弱他強”）1、移動覆蓋率弱于競對的小區(qū)周圍300-500米內(nèi)有競對基站無移動基站，規(guī)劃宏站；2、農(nóng)村場景：移動覆蓋率弱于競對的小區(qū)和競對已共站（100米內(nèi)），周圍500-1000米存在競對孤站（且互為孤站），規(guī)劃宏站；3、城區(qū)場景：移動覆蓋率弱于競對的小區(qū)（A基站）覆蓋方向存在另一移動基站（B基站），且A基站和B基站中間存在競對基站，規(guī)劃微站高流高倒高投訴：累計輸出問題點243余處，聯(lián)合地市規(guī)劃宏站138，室分1，微站5，其他納入優(yōu)化。高倒高流日均倒流流量大于400M或日均2G流量大于600M或該小區(qū)下出現(xiàn)過投訴，該小區(qū)周邊500米內(nèi)無4G基站。高域選：累計輸出問題點366余處，聯(lián)合地市規(guī)劃宏站311，室分13，微站24，其他納入優(yōu)化。4G到2G日均總回落次數(shù)大于100次，4G小區(qū)覆蓋方向500米無4G站。結(jié)合OTT大數(shù)據(jù)定位，從MR覆蓋、競對覆蓋、高流高倒高投訴以及高域選幾個維度，總計輸出規(guī)劃需求2376個，新規(guī)劃1017個，已有規(guī)劃1369個。1.4重點工作3-OTT平臺支撐六期規(guī)劃支撐集中分析-精準規(guī)劃、自上而下提出需求MR弱覆蓋：累計輸出1基于OTT定位平臺及應(yīng)用

2基于軟硬采相結(jié)合的樓宇KPI分析目錄

3基于MR的高負荷小區(qū)分流1基于OTT定位平臺及應(yīng)用2基于軟硬采相結(jié)合的樓2.1軟硬采數(shù)據(jù)應(yīng)用MR軟硬采XDROTT信令數(shù)據(jù)+MR數(shù)據(jù)+OTT經(jīng)緯度VOLTE接通率單用戶異常信令回溯異常事件原因及地理緯度聚類數(shù)據(jù)關(guān)聯(lián)數(shù)據(jù)聚類關(guān)聯(lián)軟采中Uu、X2、MRO和硬采中S1-MME、S6a、S10等數(shù)據(jù)，并根據(jù)OTT數(shù)據(jù)進行經(jīng)緯度回填數(shù)據(jù)過濾按照異常信令反饋原因?qū)Φ艟€、未接通、VOLTE掉話等11項指標按照異常信令反饋原因進行歸類對UU口給出的異常事件關(guān)聯(lián)MR中覆蓋、干擾、質(zhì)差進行地理緯度的聚類，輸出異常樓宇信息及無線原因

17年初在應(yīng)用服務(wù)器中接入運城市1000個小區(qū)的軟/硬采數(shù)據(jù)進行應(yīng)用研究，目前已實現(xiàn)軟采、硬采、OTT數(shù)據(jù)的合成，按照樓宇級別輸出掉線、未接通、切換失敗等11項KPI指標，通過軟/硬采各個接口反饋原因值進行歸類，UU事件通過關(guān)聯(lián)MR信息后輸出異常事件無線側(cè)原因。2.1軟硬采數(shù)據(jù)應(yīng)用MR軟硬采XDROTT信令數(shù)據(jù)+MR數(shù)2.2軟硬采數(shù)據(jù)應(yīng)用-軟硬采數(shù)據(jù)關(guān)聯(lián)分析算法2.2軟硬采數(shù)據(jù)應(yīng)用-軟硬采數(shù)據(jù)關(guān)聯(lián)分析算法2.2軟硬采數(shù)據(jù)應(yīng)用—異常事件的信令流程分析算法以4G系統(tǒng)內(nèi)切換失敗事件為例1截取異常事件3問題歸類2異常信令節(jié)點歸屬Interface=1為UU口，Procedurestatus=0為成功，從而判斷異常事件是否發(fā)生在UU口切換失敗發(fā)生在UU口，關(guān)聯(lián)MR信息確定無線問題；發(fā)生在X2或S1口給出failurecause原因注：

Interface=1軟采數(shù)據(jù)UU口；

Interface=2軟采數(shù)據(jù)X2口；Interface=5硬采數(shù)據(jù)S1口；流程圖中按中國移動統(tǒng)一DPI設(shè)備技術(shù)規(guī)范-LTE信令采集解析服務(wù)器接口規(guī)范2.1，最新的2.2.0與2.1字段定義不一致，如Procedurestatus字段2.1中取值為0成功、1失敗、255超時，2.2中為1成功、2失敗、3超時Procedurestatus=0為成功，不為0為失敗和超時2.2軟硬采數(shù)據(jù)應(yīng)用—異常事件的信令流程分析算法以4G系統(tǒng)2.3軟硬采數(shù)據(jù)應(yīng)用-樓宇級異常事件分析基站間切換失敗異常事件次數(shù)X2切換問題樓宇下鉆詳單，發(fā)現(xiàn)向二水泥廠-2和嶺西動-2小區(qū)切換失敗，UU口反饋原因為UE超時查看異常節(jié)點前MR信息發(fā)現(xiàn)RSRP差，問題定位2.3軟硬采數(shù)據(jù)應(yīng)用-樓宇級異常事件分析基站間切換失敗異常1基于OTT定位平臺及應(yīng)用

2基于軟硬采相結(jié)合的樓宇KPI分析目錄

3基于MR的高負荷小區(qū)分流1基于OTT定位平臺及應(yīng)用2基于軟硬采相結(jié)合的樓高負荷小區(qū)影響：高負荷小區(qū)表現(xiàn)為RRC在線用戶數(shù)、主控/基帶板CPU負荷和PRB利用率激增，導(dǎo)致RRC建立成功率等指標惡化，用戶上網(wǎng)速率慢等問題，用戶感知變差進一步引發(fā)用戶投訴，17年5月由于容量問題導(dǎo)致的客戶投訴占比從年初的0.5%上升至1.5%。容量問題導(dǎo)致投訴占比0.5%1.5%17年1月17年5月高負荷優(yōu)化項目背景山西網(wǎng)絡(luò)容量現(xiàn)狀目前有0.21%的高負荷待擴容小區(qū)，LTE高負荷問題導(dǎo)致現(xiàn)網(wǎng)投訴激增及網(wǎng)絡(luò)質(zhì)量下降分析處理需綜合考慮覆蓋、容量、質(zhì)量、資源等方面，目前缺乏完整的解決方案，各地市處理思路不統(tǒng)一優(yōu)化方案不成熟當前LTE共站小區(qū)中，流量差大于5G的小區(qū)占比66%，存在忙閑不均，利用率低資源利用率低傳統(tǒng)優(yōu)化效率低傳統(tǒng)優(yōu)化對參數(shù)調(diào)整效果無法精準評估，需多次對比，反復(fù)調(diào)整，效率偏低3.1高容量小區(qū)分流-項目背景高負荷小區(qū)影響：高負荷小區(qū)表現(xiàn)為RRC在線用戶數(shù)、主控/基帶通過MR計算出鄰區(qū)中符合分流的小區(qū)周邊站點是否故障通過匹配MR數(shù)據(jù)，判斷周邊小區(qū)距離，關(guān)聯(lián)告警信息，判斷小區(qū)周邊300米以內(nèi)是否有故障小區(qū)，并結(jié)合歷史性能數(shù)據(jù)，判斷高負荷出現(xiàn)時間與告警時間吻合；MR中鄰區(qū)電平是否過低通過MR數(shù)據(jù)，識別出覆蓋滿足要求的目標鄰區(qū)（鄰區(qū)RSRP大于-110dBm且鄰區(qū)采樣點占比大于10%的小區(qū)）；鄰區(qū)是否全部高負荷關(guān)聯(lián)性能數(shù)據(jù)，判斷輸入的鄰區(qū)是否全部高負荷（參考擴容標準）；是否異頻鄰區(qū)低負荷匹配MR，判斷滿足交疊覆蓋和低負荷的鄰區(qū)是否為異頻鄰區(qū)，若存在異頻則優(yōu)先選擇負載均衡調(diào)整策略；是否同頻鄰區(qū)低負荷匹配MR，判斷滿足交疊覆蓋和低負荷的鄰區(qū)是否全部為同頻鄰區(qū)，若是則直接選擇切換/重選參數(shù)調(diào)整策略。3.2高容量小區(qū)分流-解決方案通過MR計算出鄰區(qū)中符合分流的小區(qū)周邊站點是否故障通過匹配M負載均衡精準預(yù)估均衡效果考慮乒乓切換精確輸出參數(shù)門限精準預(yù)估均衡效果采集小區(qū)忙時話統(tǒng)數(shù)據(jù)對比集團標準，根據(jù)用戶數(shù)和PRB利用率評估出需均衡用戶數(shù)/RB數(shù)比例；基于MR數(shù)據(jù)解析現(xiàn)有用戶數(shù)和占用RB數(shù)，結(jié)合用戶服務(wù)小區(qū)RSRP和鄰區(qū)RSRP，代入A2/A4門限值或CIO配置值可精確預(yù)估切出用戶/RB比例，預(yù)判參數(shù)調(diào)整動作能否滿足負荷要求。精確輸出參數(shù)門限現(xiàn)有負載均衡算法初始開啟時基本采用默認值，根據(jù)效果對比多次進行參數(shù)調(diào)整；本項目根據(jù)話統(tǒng)評估的用戶/RB需分流比例，基于MR數(shù)據(jù)服務(wù)小區(qū)和鄰區(qū)RSRP，采用迭代算法計算出最優(yōu)A2/A4組合門限值，一次調(diào)整即可達到均衡效果?？紤]乒乓切換負載均衡算法開啟后，邊緣重疊覆蓋場景將引入兵乓切換的大量增加，本次優(yōu)化方案考慮乒乓切換增加比例，大于門限則不適合采用負載均衡策略，進入切換參數(shù)優(yōu)化評估環(huán)節(jié)。3.2高容量小區(qū)分流-負載均衡算法負載均衡精準預(yù)估均衡效果考慮乒乓切換精確輸出參數(shù)門限精準預(yù)估

負載均衡參數(shù)優(yōu)化算法算法輸入根據(jù)鄰區(qū)RSRP和負荷情況篩選出目標鄰區(qū)（鄰區(qū)RSRP大于-110dBm且采樣點占比大于10%、負荷低于擴容標準*80%）；

解析高負荷小區(qū)忙時MR數(shù)據(jù)中所有用戶的MR.LteScRSRP、MR.LteNcRSRP、MR.LteNcPci、MR.LteNcEarfcn、MR.LteScPUSCHPRBNum、MR.LteScPDSCHPRBNum；負載均衡參數(shù)計算流程如右圖，通過迭代算法輸出滿足要求的最優(yōu)（A2，A4）組合，計算過程涉及公式如下：公式一：X1=（現(xiàn)有用戶數(shù)Y-用戶數(shù)擴容門限Z）/現(xiàn)有用戶數(shù)Y+2%公式二：公式三：切換/重選參數(shù)計算流程如右圖，統(tǒng)計（A-B）小于門限值M的用戶數(shù)占比X2，取X2大于目標均衡用戶占比時的M最小值作為CIO調(diào)整值基準；計算過程除上述3個公式外還包括如下公式：公式四：CIO=（M+a3-offset+hysteresis）3.2高容量小區(qū)分流-MR計算分流門限負載均衡參數(shù)優(yōu)化算法算法輸入負載均衡參數(shù)計算公式二選取太原富士康工業(yè)園區(qū)進行算法試點，根據(jù)高負荷小區(qū)判斷原則篩選出5個高負荷小區(qū)進行分