LTE后臺KPI指標優(yōu)化指導書(全集)

/1掉線率1．1指標定義無線掉線率＝（eNｏdｅB發(fā)起的S1RESＥＴ導致的UEConteｘt釋放次數(shù)＋UEConteｘt異常釋放次數(shù))/UEConｔext建立成功總次數(shù)*100％１.2指標分析及統(tǒng)計點介紹UＥConｔext異常釋放次數(shù)測量點：如圖1中A點所示，當ｅNodeＢ向MME發(fā)送ＵEＣONTEＸＴＲELＥASEREQＵＥST消息，會釋放UE的所有E-RＡＢ。當釋放原因不為“NｏｒmａlRｅｌｅase"，“Ｄｅtach"，“UserInａctｉvity”，“CSFallｂacktｒiggeｒed”，“UENｏtＡvａiｌaｂｌｅfoｒPSSerｖice”，“Iｎter－RATRedｉreｃｔiｏn”，“TiｍeCriｔicalHaｎdoveｒ”，“HandoｖerCａncelled"時，測量指標Ｌ．UECNＴX。AbｎoｒmRel加1。eＮodeＢ發(fā)起的S1REＳＥT導致的ＵＥContｅxt釋放次數(shù)測量點：如圖２中Ａ點所示，當eＮodｅB向MME發(fā)送Ｓ1RESET消息時，根據(jù)包含的上下文個數(shù),指標L.UＥCＮTX．Rｅl.S１Rｅsｅt.ｅNoｄeB進行累加UECoｎtｅxt建立成功總次數(shù)測量點：如圖3中B點所示，當eNodeB向ＭME發(fā)送ＩNIＴIAＬCONTEXＴSETＵPRＥSPOＮSE消息時統(tǒng)計該指標。消息中如果包括多個Ｅ－ＲAB，該指標也只統(tǒng)計一次。1。3TOP小區(qū)分析流程TＯＰ小區(qū)分析可通過OMC920提取異常釋放原因：□eNｏdｅB發(fā)起的原因為UELOＳT的ＵＥCｏntｅxt釋放次數(shù)□eNｏdeB發(fā)起的原因為切換失敗的UＥConteｘt釋放次數(shù)□ｅNｏdeB發(fā)起的原因為無線層問題的UＥContext釋放次數(shù)□eNoｄeB發(fā)起的S1RESＥT導致的ＵECoｎteｘt釋放次數(shù)?是否存在異常告警或傳輸閃斷1)通過ＬSＴALMAＦ查詢站點實時告警,參考歷史告警；２）通過DＳPBRD查詢單板運行情況；?通過提取兩兩小區(qū)切換，確定目標小區(qū)1）確定目標小區(qū)運行情況，是否基站故障或異常告警；2）檢查鄰區(qū)間參數(shù)設置是否正確；3）通過Maｐiｎfｏ檢查小區(qū)鄰區(qū)配置是否合理，進行鄰區(qū)合理性優(yōu)化；4）檢查基站是否周邊站點缺少，如為孤站,可視為正常;?檢查S1鏈路是否配置正確現(xiàn)統(tǒng)計中ｅNodeB發(fā)起的S1RESＥT導致的UＥCｏnteｘt釋放次數(shù)均為0，如統(tǒng)計出現(xiàn)釋放次數(shù)，需進行針對排查；?參數(shù)是否設置合理1）查詢掉線類定時器設置是否正確；(T31０、N3１1、N310、T３11、T301)２）如掉線率突增，查詢操作日志,確認是否有修改，導致小區(qū)異常；?是否存在高干擾1）通過Ｍａpｉnfo查看小區(qū)PCI復用是否合理，是否存在模三沖突；2）檢查小區(qū)時隙配比是否設置準確(DE：SA2\SＳＰ7；Ｆ:SＡ２\SSＰ5);3）如每PRB上干擾噪聲平均值〉-110ｄBm，確認小區(qū)存在上行干擾，同時可通過后臺跟蹤,確認干擾類型；小提示:判斷干擾類型時,可跟蹤后臺干擾檢測，如果RＢ0-RB99呈下坡圖,則為雜散干擾,如果為陡升陡降則為互調(diào)干擾，如果為上坡圖,則為阻塞干擾,如果干擾僅在RＢ40-RB80，則為廣電干擾,請大家知悉。?是否存在高質(zhì)差１)通過觀察小區(qū)上下行丟包率是否正常,如丟包率偏高,基本斷定小區(qū)存在質(zhì)差；2）通過后臺誤碼率跟蹤，如BＬER〉10％，確定小區(qū)存在高誤碼;?是否存在弱覆蓋１）檢查傳輸模式，是否為ＴM3,如長時間為TM2,確認設置正確的情況下,基本確定小區(qū)存在弱覆蓋；2）對比6４QAＭ和QPSK占比，如后者比例遠大于前者，可確定小區(qū)覆蓋異常；?現(xiàn)場測試及后臺跟蹤１)安排前場人員現(xiàn)場測試,同時后臺通過信令跟蹤，配合查找問題原因；2）如果確認問題后,需第三方配合解決，轉(zhuǎn)發(fā)相關(guān)人員處理，做好跟蹤工作，直至問題閉環(huán);２接通成功率2.1指標定義無線接通率＝RRC連接建立成功率＊E-ＲＡB建立成功率＝(ＲRC連接建立完成次數(shù)/RRＣ連接請求次數(shù)（不包括重發(fā))）＊E-RAB建立成功總次數(shù)/E—ＲAB建立嘗試總次數(shù)＊１０0%2。2指標分析及統(tǒng)計點介紹圖１中【A點】(１)指標L．RRC.CoｎnReq。Att加1，不統(tǒng)計重發(fā)的次數(shù)。Case1:eＮB下發(fā)RRＣ_Ｃonn_Setup消息后,在Ｔ３０0定時器超時前，收到相同的UeID發(fā)起的RRC_Cｏｎn_Reｑ（Ｓｅtup丟失,UEMAC沖突解決定時器超時后重發(fā)ＲRC_Conｎ_Rｅq，UeIＤ不變），記為一次重發(fā)ＲRＣ＿Ｃoｎn_Req消息。Cａsｅ２:T３00超時后，UＥ仍未收到RRＣ_Coｎｎ_Seｔuｐ,ＵE重新搜網(wǎng)，發(fā)起初始接入，UeＩＤ是?。皛239的隨機值或上層下發(fā)的TＭSI。eＮB側(cè)記為新的一次初始接入，Ｌ.RＲC.CｏｎｎReｑ。Aｔｔ加１。Ｃase３：發(fā)起Attach后會啟動T34１０定時器。如果UＥ發(fā)出ＲRC_Ｃonn＿Setｕｐ_Cmp后，ENB沒有收到,ＵE會在定時器超時后重新發(fā)起Atｔａｃh,ENＢ側(cè)記為新的一次初始接入；ＲRC_Coｎn_Ｓetuｐ＿Cmp丟失不會觸發(fā)重建,發(fā)起重建的前提是安全已經(jīng)激活.(２）如果RRCConnectionReｑuｅsｔ消息信元EstａｂlishｍentCauｓe為“eｍergeｎｃｙ”，指標L.RＲC.CoｎnReq。Atｔ.Emc加1。(3）如果RRCConnectioｎRequeｓt消息信元EstablishmｅntCause為“ｈｉghPｒiorｉtyAｃceｓs”,指標L.RRC。ConnRｅq。Att.HｉｇｈＰri加1。(４)如果ＲＲCConnectioｎRｅqｕesｔ消息信元EstablｉsｈmｅntCauｓe為“mt-Aｃｃesｓ”，指標L．ＲＲC。ConnRｅq．Ａtt。Mt加1。（5）如果RＲCConnectionRｅquｅst消息信元ＥsｔablishmentCaｕsｅ為“ｍo—Sｉngｎalling”,指標L。ＲRC.CoｎｎReq.Ａｔt.MoSig加1。（6)如果ＲRCConnectionReｑueｓt消息信元EstaｂlｉｓhｍentCaｕｓe為“mo—Data”,指標L.RＲC．ConｎRｅq.Ａtt。MoＤata加1.【B點】當eＮodeB下小區(qū)接收到UＥ發(fā)送的RRＣConｎeｃtｉoｎRｅｑｕest消息并下發(fā)RRCCoｎnectiｏｎSetup消息給UE時,指標L。RRC.CｏnnSeｔup加1?！荆命c】當eNodｅＢ收到ＵE返回的RRCConnectionSetupCｏmpletｅ消息時統(tǒng)計相應指標，L.RRC。ConnReq。Succ加1。RRCSetupＳucｃesｓRａt(yī)ｅ計算RＲCSetupSuccｅssRate=（L.ＲRC.CｏｎｎReｑ．Succ)/(L。RＲC．ＣｏnnＲeq。Aｔt)*1０0%圖2、３中【Ａ點】當eNodeB收到來自MME的E-RＡＢSETUPＲEQUEST或者ＩＮIＴIＡＬCONＴEＸＴSＥTＵPREQUＥST消息時統(tǒng)計該指標。如果Ｅ－RABＳETＵPRＥＱUEST或者INIＴIALCONTEXTSETUPRＥQＵＥSＴ消息中要求同時建立多個E—RAB，則相應指標按各個業(yè)務的QCI分別進行累加?！荆曼c】當MＭＥ收到來自ｅNodｅB的E-ＲＡBSＥTUＰRESPＯNSE或者INITIALCＯNTEXTSETUPRＥSPONSＥ消息時Ｅ-RAB建立成功次數(shù)累加。ＥRＡBSetupＳucceｓｓRatｅ計算公式EraｂSetuｐSuｃceｓｓRatｅ=（L。Ｅ—ＲAB。ＳucｃEｓt）/(L.Ｅ-ＲAB。AttＥsｔ）＊1０0％２。３TOP小區(qū)提取及分析流程１。TOP小區(qū)提取暫按以下方式操作（僅供參考，請根據(jù)網(wǎng)絡實際情況自定義):①ＲRC請求次數(shù)大于50次②接通率小于98%。③在一周之類重復出現(xiàn)2次以上的小區(qū).若前三種無法提取出ＴＯＰ小區(qū),可按RＲC，ERＡB建立失敗次數(shù)，分開求和后降序排列篩選ＲＲC和ERAB建立失敗的TOP小區(qū).2．TOP小區(qū)中ＲＲC和EＲＡＢ建立失敗次數(shù)原因值說明:①對小區(qū)ＲRC建立失敗次數(shù):□資源分配失敗而導致RＲＣ連接建立失敗的次數(shù)，指標ID：１5２67270８3；重點關(guān)注top資源是否足夠，包括top用戶數(shù),傳輸、PRＢ等;□UＥ無應答而導致RＲC連接建立失敗的次數(shù)，指標IＤ:１5267２7084；關(guān)注質(zhì)差、干擾、無線環(huán)境等；□小區(qū)發(fā)送RRＣＣoｎnecｔionRejecｔ消息次數(shù)，指標ID：152672８269；關(guān)注傳輸問題、是否擁塞、干擾；□因為ＳＲS資源分配失敗而導致RRC連接建立失敗的次數(shù),指標ID：152672８485；重點關(guān)注ＳRS帶寬、配置指示、配置方式、SRSＡＣＫ/ＮACＫ設置是否合理等；□因為ＰUCCH資源分配失敗而導致RＲC連接建立失敗的次數(shù)，指標ID:1526７２84８6；關(guān)注PUＣCH信道相關(guān)參數(shù)設置是否合理，CＱIRB數(shù)配置是否合理等；□流控導致的RRCConｎectionRｅquｅst消息丟棄次數(shù)，指標ID:1526７28489；關(guān)注擁塞，業(yè)務流控相關(guān)參數(shù)是否設置正確等；□流控導致的發(fā)送RＲCCoｎnectionＲejｅｃt消息次數(shù)，指標IＤ:1５２67２84９0；關(guān)注擁塞，業(yè)務流控相關(guān)參數(shù)是否設置正確等;②對小區(qū)Ｅ—ＲＡB建立失敗次數(shù):□因未收到ＵＥ響應而導致E—RAB建立失敗的次數(shù)，指標ＩD：15２672671７;處理建議：需排查覆蓋,干擾，質(zhì)差,EＮODEB參數(shù)設置錯誤,終端及用戶行為異常等原因?！鹾诵木W(wǎng)問題導致E-RAB建立失敗次數(shù)，指標ID:152６72827６；處理建議:需跟蹤信令,排查核心網(wǎng)問題（EPC參數(shù)設置，TAC碼設置的一致性，對用戶開卡限制,硬件故障方面排查）；□傳輸層問題導致Ｅ—ＲAB建立失敗次數(shù),指標ID：15２６7２82７７；處理建議:需查詢傳輸是否有故障，高誤碼,閃斷，傳輸側(cè)參數(shù)設置問題。□無線層問題導致E—ＲＡB建立失敗次數(shù),指標ＩD：1526728278；處理建議:處理建議：需排查覆蓋,干擾,質(zhì)差，ＥNODＥB參數(shù)設置錯誤，終端及用戶行為異常等原因?！鯚o線資源不足導致E—RAB建立失敗次數(shù),指標ＩＤ:１52672８２７9;處理建議：排查TOＰ小區(qū)資源是否足夠，是否故障引起，若存在資源不足問題，可考慮參數(shù)調(diào)整，流量均衡(小區(qū)選擇,重選和切換類參數(shù))；２、結(jié)合現(xiàn)場調(diào)整天饋，流量均衡；3、熱點區(qū)域,增補基站等；□安全模式配置失敗導致E—RAＢ建立失敗次數(shù)，指標ＩＤ：１5267２８280；處理建議：需排查覆蓋，干擾，質(zhì)差，ENＯDEB參數(shù)設置錯誤,終端及用戶行為異常等原因。?篩選TＯP小區(qū)RRＣ建立成功率ＴOP、Ｅ—RAB建立成功率TOＰ條件相同：建立成功率〈98％，連接請求次數(shù)極少.?是否存在干擾1)通過Mａｐｉnfo查看小區(qū)PCＩ復用是否合理,是否存在模三沖突;2)檢查小區(qū)時隙配比是否設置準確（ＤE:SA2\SＳP7;Ｆ:SA2＼SＳP5）3)如每PRＢ上干擾噪聲平均值＞－11０dBm,確認小區(qū)存在上行干擾,同時可通過后臺跟蹤，確認干擾類型；4）發(fā)送干擾組協(xié)助處理.?是否存在覆蓋問題１)檢查傳輸模式,是否為TM3,如長時間為TＭ2,確認設置正確的情況下，基本確定小區(qū)存在弱覆蓋；2）對比64QＡＭ和QPSK占比，如后者比例遠大于前者，可確定小區(qū)覆蓋異常；3）鄰區(qū)告警、故障等導致TＯP小區(qū)存在弱覆蓋;4)天饋問題；5)無線環(huán)境差；６）基站規(guī)劃、建設、施工問題；7）天線權(quán)值配置與現(xiàn)場天線參數(shù)不一致。8）核查參考信號功率是否偏低(常規(guī)設置９2,122,需結(jié)合現(xiàn)場設置）；?是否存在高質(zhì)差1）通過觀察小區(qū)上下行丟包率是否正常，如丟包率偏高,基本斷定小區(qū)存在質(zhì)差;2)通過后臺誤碼率跟蹤，如BＬER>10％，確定小區(qū)存在高誤碼；?是否存在資源不足1）參數(shù)調(diào)整,流量均衡；2)天饋調(diào)整,分擔流量；3)熱點區(qū)域,增補基站；?是否終端、用戶行為異常結(jié)合用戶投訴情況，安排前場人員現(xiàn)場測試,同時后臺通過信令跟蹤，配合查找問題原因；3切換成功率3．1指標定義(ｅNodｅＢ間同頻切換出成功次數(shù)+ｅNodeB間異頻切換出成功次數(shù)+ｅNodeB內(nèi)同頻切換出成功次數(shù)+ｅＮodeB內(nèi)異頻切換出成功次數(shù)－通過重建回源小區(qū)的eNｏdeＢ間同頻切換出執(zhí)行成功次數(shù)－通過重建回源小區(qū)的ｅNoｄeB間異頻切換出執(zhí)行成功次數(shù)－通過重建回源小區(qū)的eNodeB內(nèi)同頻切換出執(zhí)行成功次數(shù)－通過重建回源小區(qū)的eＮodeB內(nèi)異頻切換出執(zhí)行成功次數(shù))／(eNodeB間同頻切換出嘗試次數(shù)+eNodeB間異頻切換出嘗試次數(shù)+eNoｄeB內(nèi)同頻切換出嘗試次數(shù)+eNodeＢ內(nèi)異頻切換出嘗試次數(shù))＊100%３．2指標分析及統(tǒng)計點介紹1）核心網(wǎng)原因?qū)е虑袚Q出準備失敗

源小區(qū)收到來自MＭE的UECONTEXTRELEＡSＥＣOＭＭAＮD消息時，指標L。HＨO.Prｅp.FailOｕｔ．ＭＭＥ加１2）目標小區(qū)無響應導致切換出準備失敗在X２切換時,未收到對端eＮodeB發(fā)出的HANＤOVERREQUEＳＴＡCＫNOWＬEDEＧ消息及HＡNＤOVERＰＲEPAＲATＩOＮFAILUＲE消息;在S1接口切換時，未收到MME發(fā)出的ＨＡNDOVＥＲＣOＭＭAＮD消息及ＨＡNＤＯVEＲPREPARAＴIＯＮＦAＩLＵRE消息。指標Ｌ。HHO.Ｐｒep．ＦaiｌOut．NoReplｙ加1。3)目標小區(qū)回復切換準備失敗消息導致切換出準備失敗在X2接口切換過程中的切換準備階段，當源小區(qū)收到來自目標小區(qū)的HＡNDOVERPREPＡＲATIONFＡI