TDLTE網(wǎng)優(yōu)KPI指標優(yōu)化工作指導(dǎo)手冊V

TD-LTE網(wǎng)優(yōu)KPI指標優(yōu)化工作指導(dǎo)手冊項目名稱文檔編號版本號作者版權(quán)所有大唐移動通信設(shè)備有限公司本資料及其包含的所有內(nèi)容為大唐移動通信設(shè)備有限公司(大唐移動)所有,受中國法律及適用之國際公約中有關(guān)著作權(quán)法律的保護。未經(jīng)大唐移動書面授權(quán)，任何人不得以任何形式復(fù)制、傳播、散布、改動或以其它方式使用本資料的部分或全部內(nèi)容，違者將被依法追究責任。文檔更新記錄日期更新人版本備注2013-7-17王學斌V0.0.1創(chuàng)建2013-7-31王學斌盧顥V0.0.2添加RRC、ERAB、掉線CDL信令流程及失敗原因2013-9-20王學斌、張發(fā)厚、索志剛、魏曉東、閆俊霖、徐世勛編寫案例2013-9-29徐世勛增加章節(jié)2.KPI優(yōu)化的工作流程及內(nèi)容2013-10-23王學斌、周曉華、王會慶V0.0.5增加案例2013-10-24徐世勛V0.0.6匯總及增加KPI問題處理工單模板2013-11-5徐世勛V0.0.7根據(jù)評審意見進行修改2013-11-8童志堅V0.0.8增加童志堅整理的案例：3.5.2小區(qū)上行功控參數(shù)設(shè)置問題2014-4-8王學斌V1.0.0接受文檔中全部修訂內(nèi)容，增加兩個切換案例，刪除4個與版本相關(guān)的案例。2014-4-23王學斌V1.0.1資源受限導(dǎo)致上下文建立失敗的案例2014-11-3王學斌V1.0.2新增R9和R10協(xié)議不兼容導(dǎo)致切換失敗問題案例

目錄1 前言 52 KPI優(yōu)化的工作流程及內(nèi)容 52.1 KPI優(yōu)化工作總體流程 52.2 KPI優(yōu)化工作內(nèi)容 6 KPI數(shù)據(jù)生成 6 KPI數(shù)據(jù)分析 7 問題處理 7 問題跟蹤和核查 82.3 KPI優(yōu)化工作邏輯圖 82.4 KPI優(yōu)化工作模板和示例 93 RRC連接建立成功率優(yōu)化 103.1 理論介紹 103.2 指標定義 103.3 CDL信令流程及失敗原因 11 正常過程 11 異常過程 113.4 優(yōu)化方法介紹 12 上行隨機接入的問題 14 小區(qū)重選參數(shù)問題 14 下行初始發(fā)射功率偏低問題 15 上行初始功控問題 153.5 相關(guān)案例介紹分析 15 小區(qū)重選參數(shù)問題 15 小區(qū)上行功控參數(shù)設(shè)置問題 17 小區(qū)測試開關(guān)參數(shù)問題 19 全頻帶高干擾導(dǎo)致接入失敗問題 214 ERAB建立成功率 234.1 理論介紹 234.2 指標定義 254.3 CDL信令流程及失敗原因 25 正常過程 25 異常過程 264.4 相關(guān)案例介紹分析 29 路由關(guān)系未配無法接入的問題 29 網(wǎng)關(guān)IP配置錯誤導(dǎo)致無法附著 30 安全參數(shù)配置問題 32 資源受限導(dǎo)致上下文建立失敗 335 切換成功率優(yōu)化 355.1 理論介紹 355.2 指標定義 355.3 CDL信令流程 36 正常過程 365.4 優(yōu)化方法介紹 38 切換信令流程 38 涉及話統(tǒng)打點 40 切換問題分類 425.5 相關(guān)案例介紹分析 45 切換目標側(cè)準備失敗 45 切換算法參數(shù)配置不當 46 小區(qū)個性偏移參數(shù)調(diào)整案例 48 切換時終端接入到非源和目標小區(qū)導(dǎo)致核心網(wǎng)釋放用戶問題 49 鄰區(qū)移動網(wǎng)絡(luò)碼配置錯誤導(dǎo)致S1切換失敗 52 開啟防乒乓切換開關(guān)導(dǎo)致不切換 54 配置垃圾鄰區(qū)導(dǎo)致只上報MR不觸發(fā)切換 58 終端發(fā)A3切換測量報告后，不觸發(fā)異頻切換 61 R9和R10協(xié)議不兼容導(dǎo)致切換失敗問題 636 無線掉線率優(yōu)化 656.1 理論介紹 656.2 指標定義 676.3 CDL失敗原因 67 空口超時引起的掉話 67 激活檢測——UE不活動 75 激活檢測——UE丟失（版本及后續(xù)版本無此類問題） 75 其他錯誤引起的掉話 766.4 相關(guān)案例介紹分析 77 切換不及時問題 77 鄰區(qū)漏配問題 79 核心網(wǎng)問題 81 幀頭未對齊導(dǎo)致的干擾問題 84前言話統(tǒng)KPI是中國移動考核項之一，也是對網(wǎng)絡(luò)質(zhì)量的最直觀反映。日常話統(tǒng)監(jiān)測是進行網(wǎng)絡(luò)性能檢測的一種有效手段。通過日監(jiān)測，識別突發(fā)問題小區(qū)，將問題消除在初級階段。通過周監(jiān)測，識別網(wǎng)絡(luò)性能持續(xù)短木板小區(qū)，針對性的進行提升優(yōu)化。話統(tǒng)KPI主要包括以下幾大類：接入性指標、保持性指標、移動性指標、業(yè)務(wù)量指標、產(chǎn)品運行類指標、系統(tǒng)可用性指標和網(wǎng)絡(luò)資源利用率指標。通過上述重點話統(tǒng)KPI指標的監(jiān)測，可以達到：識別突發(fā)問題、風險提前預(yù)警、話統(tǒng)KPI的穩(wěn)定與提升，目前TD-LTE系統(tǒng)需要重點關(guān)注的話統(tǒng)KPI指標如下表：指標分類數(shù)據(jù)來源具體的KPI指標接入性指標無線側(cè)RRC連接建立成功率ERAB建立成功率無線接通率保持性指標無線掉話率（ERAB異常釋放）移動性指標小區(qū)eNodeB內(nèi)切換出成功率小區(qū)eNodeB間切換出成功率業(yè)務(wù)量指標上、下行業(yè)務(wù)平均吞吐量量上、下行PRB平均利用率產(chǎn)品運行類指標無線側(cè)單板CPU最大占用率單板CPU平均占用率系統(tǒng)可用性指標無線側(cè)無線網(wǎng)絡(luò)退服比例網(wǎng)絡(luò)資源指標無線側(cè)上行PRB資源使用的平均個數(shù)下行PRB資源使用的平均個數(shù)KPI優(yōu)化的工作流程及內(nèi)容KPI優(yōu)化工作總體流程KPI優(yōu)化工作流程圖KPI優(yōu)化工作內(nèi)容KPI數(shù)據(jù)生成工作內(nèi)容：使用預(yù)定義和自定義的統(tǒng)計項及模板生成KPI性能報表，通過OMCClient提取KPI報表，輸出KPI報表和重要指標失敗原因列表給KPI數(shù)據(jù)分析人員。KPI報表生成和提取相關(guān)操作請參考《LTEKPI模板指導(dǎo)手冊》。根據(jù)KPI報表數(shù)據(jù)，選擇KPI指標最差Top小區(qū)。TOP小區(qū)的選擇：對某項指標按照失敗率最高進行排序，選取前20個小區(qū)，再對這20個小區(qū)進行失敗次數(shù)分析，失敗次數(shù)大于20次的（RRC連接、切換、掉線等按失敗次數(shù)大于20次為標準，ERAB建立失敗指標按次數(shù)大于10次為標準）作為TOP小區(qū)進行分析

；另外需要對指標再進行失敗次數(shù)的降序排序，如果有小區(qū)失敗次數(shù)很多失敗率也較高但是未在之前選的TOP小區(qū)中，也需要將這些小區(qū)作為TOP小區(qū)分析。KPI數(shù)據(jù)生成工作所需輸入、工具和技術(shù)、輸出如圖所示：KPI數(shù)據(jù)分析工作內(nèi)容：KPI指標變化趨勢分析：根據(jù)KPI報表數(shù)據(jù)，分析全網(wǎng)KPI指標變化趨勢，尤其是存在設(shè)備版本升級或參數(shù)全網(wǎng)性修改后，需要持續(xù)至少一周重點監(jiān)測KPI指標變化趨勢；TOP小區(qū)分析：根據(jù)TOP小區(qū)列表、重要指標失敗原因列表、歷史告警信息、網(wǎng)管數(shù)據(jù)、CDL日志、IOT數(shù)據(jù)、復(fù)測終端LOG等信息進行分析。先查看告警信息，確認有設(shè)備故障類告警是否和TOP小區(qū)關(guān)聯(lián)，再使用與基站軟件版本匹配的CDLBrowser工具進行指標統(tǒng)計和失敗信令流程分析確認TOP小區(qū)產(chǎn)生的原因，CDLBrowser工具使用方法請參考《CDL分析工具使用手冊》。KPI數(shù)據(jù)分析工作所需輸入、工具及技術(shù)、輸出如圖所示：問題處理工作內(nèi)容：1）通過CDL分析能夠明確定位TOP小區(qū)問題后，給出問題處理建議輸出給相關(guān)問題處理人員：參數(shù)修改問題導(dǎo)給維護人員調(diào)整（和標定參數(shù)不一致的大規(guī)模參數(shù)修改需和SE確認）；網(wǎng)絡(luò)優(yōu)化問題給出優(yōu)化建議導(dǎo)給網(wǎng)優(yōu)人員；由于設(shè)備故障引起的KPI指標惡化問題導(dǎo)給排障人員處理；定位確認為產(chǎn)品缺陷要及時提交BUG推動和跟蹤版本解決。2）通過CDL分析無法明確定位TOP小區(qū)產(chǎn)生原因的問題，需要復(fù)測后結(jié)合終端側(cè)log再進一步分析。問題處理工作所需的輸入、工具及技術(shù)、輸出如圖所示：問題處理：輸入、工具及技術(shù)、輸出問題跟蹤和核查工作內(nèi)容：問題跟蹤和核查環(huán)節(jié)，主要依據(jù)問題列表、KPI問題處理工單、BUG/CR/RR編號，內(nèi)部討論推動和核查問題解決，和外部其它環(huán)節(jié)溝通確認問題進展，以形成問題閉環(huán)，最終輸出KPI優(yōu)化報告。問題跟蹤和核查工作所需的輸入、工具及技術(shù)、輸出如圖所示：問題跟蹤和核查：輸入、工具及技術(shù)、輸出KPI優(yōu)化工作邏輯圖綜合KPI優(yōu)化工作流程和內(nèi)容，KPI優(yōu)化工作邏輯圖如下：KPI優(yōu)化工作邏輯圖KPI優(yōu)化工作模板和示例KPI優(yōu)化工作參考模板KPI報表示例RRC連接建立成功率優(yōu)化理論介紹RRC連接建立過程分為兩個階段：準備階段和實施階段。在準備階段中，UE會根據(jù)NAS層的觸發(fā)原因和系統(tǒng)廣播中的接入限制信息，通過一系列檢查來判斷自己是否被允許進行接入過程，如果可以，則執(zhí)行后續(xù)的實施階段；否則UE的RRC將啟動相應(yīng)的定時器，在該定時器超時前UE無法發(fā)起任何接入過程。上述機制的目的是負荷擁塞控制，當網(wǎng)絡(luò)負荷較重時限制某些UE進行接入。指標定義RRC連接建立是指處于空閑狀態(tài)的UE或待開機的UE準備發(fā)起一個呼叫或響應(yīng)尋呼時發(fā)起的過程。處于降低接入時延的考慮，LTE系統(tǒng)將RRC連接建立過程設(shè)計發(fā)生在ENB和MME之間的S1連接建立前，也就是在ENB尚未從MME獲得任何UE上下文前，ENB需要將RRC連接建立完畢，因此該過程主要建立最基本的SRB1。RRC連接建立成功意味著UE與網(wǎng)絡(luò)建立了信令連接，是進行其他業(yè)務(wù)的基礎(chǔ)。RRC連接建立成功率主要通過話務(wù)統(tǒng)計結(jié)果獲得，推薦的公式為：RRC建立成功率=[RRC連接建立完成次數(shù)]/[RRC連接請求次數(shù)（不包括重發(fā)）]；公式中相關(guān)各指標的具體統(tǒng)計方式如下所示：指標指標描述RRC連接請求次數(shù)小區(qū)接收UE的RRCConnectionRequest消息次數(shù)（不包括重發(fā)）RRC連接建立完成次數(shù)小區(qū)接收UE返回的RRCConnectionSetupComplete消息次數(shù)RRC建立失敗次數(shù)資源分配失敗而導(dǎo)致連接建立失敗的次數(shù)UE無應(yīng)答而導(dǎo)致連接建立失敗的次數(shù)小區(qū)發(fā)送RRCConnectionReject消息次數(shù)CDL信令流程及失敗原因正常過程圖RRC建立過程正常流程每當在CDLlog中發(fā)現(xiàn)一條UU接口RRCConnectionRequest消息時，代表某一個UE連接建立的開始，此后所有的消息都可以提取相同的CellUeIndex和CELLID。當看到RRCConnectionSetup和RRCConnectionSetupComplete消息時，標志著RRC建立正常流程的結(jié)束。異常過程RRC連接建立完成超時圖RRC連接建立完成超時每當在CDLlog中發(fā)現(xiàn)一條UU接口RRCConnectionRequest消息時，代表某一個UE連接建立的開始，此后所有的消息都可以提取相同的CellUeIndex和CELLID。當看到UU接口的RRCConnectionSetup和RRC事件類接口的RRC_OVERTIME消息，并且第3條消息的定時器類型字段為RAC_TIMER_W_RRC_SETUP_CMPLT時，標志著RRC連接建立完成超時。RRC連接建立拒絕圖RRC連接建立拒絕每當在CDLlog中發(fā)現(xiàn)一條UU接口RRCConnectionRequest消息時，代表某一個UE連接建立的開始，如圖2.10所示。第1、2條消息為UU接口的RRCConnectionRequest、RRCConnectionReject，2條消息有相同的小區(qū)標識與UeIndexCell，是連接建立發(fā)生時基站為UE新分配的索引。優(yōu)化方法介紹LTE系統(tǒng)內(nèi)RRC連接建立失敗問題的可能原因大概分為如下幾條：RRC建立失敗主要的原因有：上行隨機接入信道功率問題、小區(qū)重選參數(shù)問題、下行初始發(fā)射功率偏低、上行初始功控問題、擁塞問題或設(shè)備異常問題等。當出現(xiàn)RRC連接建立成功率低的問題時，首先按照上述問題分類，了解相關(guān)問題的范圍，然后根據(jù)空口信號質(zhì)量、參數(shù)配置、干擾和上下行功率調(diào)整及設(shè)備告警等方面入手逐一排查解決，排除這些影響RRC連接建立成功率的客觀因素，逐步提升該指標的成功率。RRC連接建立的過程主要包括以下3個個步驟：RRC連接建立成功信令流程（1）首先UE通過SRB0發(fā)送RRCConnectionSetupRequest消息（注：SRB0一直存在，用來傳輸映射到CCCH的RRC信令。）此消息主要攜帶UE初始（NAS）表示以及該連接建立的原因等信息，此高層消息會觸發(fā)UE的底層試題進行基于競爭的隨機接入過程，RRC連接建立請求消息就對應(yīng)于底層隨機接入過程中的Msg3（2）通過底層的競爭接入沖突解決機制，UE接收到ENB的RRCConnectionSetup消息，建立了UE與ENodeB之間的SRB1，NodeB為SRB1配置RLC層和邏輯層信道的屬性。ENB還在此信令中對PHY/MAC/RLC/PDCP等各個實體的配置參數(shù)進行配置，RRC連接建立消息就對應(yīng)于底層隨機接入過程中的Msg4。UE收到NodeB的rrcConnectionSetup信令后，UE和ENB之間的SRB1就建立起來了。（3）在UE接收到RRCConnectionSetup消息后，向ENB發(fā)送一個RRCConnectionSetupComplete消息。此消息中攜帶有上行方向的初始NAS層的信令消息（如AttachRequest，TAURequest，ServiceRequest等），ENB收到此消息后，將其中的NAS消息轉(zhuǎn)發(fā)給MME用于建立S1連接。在第（2）步中，如果ENB拒絕為UE建立RRC連接，則通過SRB0回復(fù)一條RRC連接拒絕消息RRCConnectionReject。在該RRC連接拒絕消息中，網(wǎng)絡(luò)側(cè)可以可選地攜帶一個禁止呼叫的定時器T302，該定時器和系統(tǒng)廣播中的接入限制信息共同決定了UE是否被允許發(fā)起接入過程。一般RRC連接建立問題的定位方法如下，通用流程：RRC連接建立問題RRC連接建立問題N設(shè)備異常問題UE是否發(fā)出請求消息N設(shè)備異常問題UE是否發(fā)出請求消息YY調(diào)整隨機接入上行初始接收目標功率相關(guān)參數(shù)ENB是否收到請求消息N調(diào)整隨機接入上行初始接收目標功率相關(guān)參數(shù)ENB是否收到請求消息NYYNNENB是否發(fā)出建立消息ENB相關(guān)其他問題ENB是否發(fā)出建立消息ENB相關(guān)其他問題YYUE是否收到RRC建立消息NN是否發(fā)生小區(qū)重選UE是否收到RRC建立消息NN是否發(fā)生小區(qū)重選調(diào)整下行公共信道功率調(diào)整下行公共信道功率YY優(yōu)化小區(qū)重選參數(shù)YY優(yōu)化小區(qū)重選參數(shù)UE是否發(fā)出RRC建立完成消息NUE是否發(fā)出RRC建立完成消息N調(diào)整下行初始發(fā)射功率調(diào)整下行初始發(fā)射功率YY調(diào)整上行專用信道開環(huán)功控參數(shù)NENB是否收到建立完成消息調(diào)整上行專用信道開環(huán)功控參數(shù)NENB是否收到建立完成消息YY上行隨機接入的問題UE發(fā)出RRCConnectionRequest消息，ENB沒有收到，如果此時的下行信道質(zhì)量正常，一般是隨機接入?yún)?shù)中的初始接收目標功率設(shè)置偏低的問題。小區(qū)重選參數(shù)問題ENB收到UE發(fā)的RRC建立請求消息后，下發(fā)了RRCConnectionSetup消息而UE沒有收到。查看此時的SINR，如果偏低，而且監(jiān)視集中沒有質(zhì)量更好的小區(qū)，則是覆蓋的問題可以適當提高下行公共信道的功率。如果此時監(jiān)視集中有更好的小區(qū)，則可能是小區(qū)重選的問題，可以適當調(diào)整小區(qū)重選參數(shù)加快小區(qū)重選。下行初始發(fā)射功率偏低問題UE收到RRCConnectionSetup消息而沒有發(fā)出RRCConnectionSetupComplete消息，如果此時下行的信號質(zhì)量正常，則可能是手機異常，否則可能是下行初始功率過低導(dǎo)致下行不能同步。上行初始功控問題UE發(fā)出RRCConnectionSetupComplete消息而ENB沒有收到，由于上行初始功控會讓UE的發(fā)射功率上升，如果是UE的發(fā)射功率不足導(dǎo)致，可以適當提高上行信道的初始期望功率和調(diào)整量等參數(shù)。相關(guān)案例介紹分析小區(qū)重選參數(shù)問題問題描述：

華電集團專項2小區(qū)接入率很低，且主要集中在15點到16點之間，查看小區(qū)無告警。由于接入失敗次數(shù)過多，影響全網(wǎng)一天的KPI指標數(shù)據(jù)。問題分析：從CDL信令看UE發(fā)起隨機接入申請，UE發(fā)出RRCConnectionRequest后ENB下發(fā)RRCconnectionsetup消息，終端無響應(yīng)，造成RRC連接建立完成超時，導(dǎo)致RRC建立失敗。定位過程：從最近一次的測量上報消息中可以看出，源小區(qū)PCI為254，此時測量到的rsrpResult值為23，由此可以計算出RSRP的值為23-141=-118dbm左右。而測量到的相鄰目標小區(qū)PCI為62，rsrpResult值為34，小區(qū)RSRP在-107dbm左右。由此可以初步分析相關(guān)的場景是UE所處位置的信號質(zhì)量不好，且存在模3干擾，最終導(dǎo)致RRC連接建立定時器超時后RRC連結(jié)建立失敗。解決建議：查看基站配置后，該小區(qū)的參考信號功率為15，已經(jīng)為最大。故不存在下行初始發(fā)射功率偏低問題。通過現(xiàn)場復(fù)測抓取log進一步分析，排除天線安裝問題以及工參設(shè)置問題、排除存在大面積的弱覆蓋問題。通過log分析，發(fā)現(xiàn)存在PCI模三干擾嚴重，重新進行規(guī)劃，修改小區(qū)的PCI。解決效果：修改PCI后，RRC接入率有所提，KPI指標數(shù)據(jù)恢復(fù)正常。小區(qū)上行功控參數(shù)設(shè)置問題問題現(xiàn)象NBYZ技偵大樓FHTL-0從7月13日開始，RRC接入請求次數(shù)變多還有伴隨著大量失敗，每天RRC成功率基本在20%左右，失敗發(fā)生在忙時時段，影響全網(wǎng)KPI。問題分析：查看小區(qū)狀態(tài)以及通道駐波均沒有問題，從CDL中看：均是ENB下發(fā)RRCsetup之后終端無響應(yīng)造成RRC連接超時，導(dǎo)致RRC接入失敗。查看基本上是UEID為1和3的用戶的失敗，但是查看最近的RSRP均較高。定位過程：查看小區(qū)的IOT以及小區(qū)狀態(tài)正常，對此小區(qū)進行核查，發(fā)現(xiàn)參數(shù)在非持續(xù)調(diào)度功率設(shè)置上出現(xiàn)問題，當此小區(qū)是-95，全網(wǎng)當時都已經(jīng)改成-70，通過對全網(wǎng)此參數(shù)的核查，發(fā)現(xiàn)還有NBYZ理工學院2FHTL-2也是設(shè)置為-95，指標也很差。解決建議：效果：把小區(qū)的非持續(xù)調(diào)度功率從-95修改到-70以后指標明顯有提升：網(wǎng)元友好名時間RAB建立成功率分母[單位:次]RAB建立成功率分子[單位:次]RRC連接建立成功率分母[單位:次]RRC連接建立成功率分子[單位:次]RRC建立成功率NBYZ技偵大樓FHTL-02013/7/115151787798.72%NBYZ技偵大樓FHTL-02013/7/123535545398.15%NBYZ技偵大樓FHTL-02013/7/134440956063.16%NBYZ技偵大樓FHTL-02013/7/1420141273023.62%NBYZ技偵大樓FHTL-02013/7/1520141273023.62%NBYZ技偵大樓FHTL-02013/7/161351752514.29%NBYZ技偵大樓FHTL-02013/7/171271272318.11%NBYZ技偵大樓FHTL-02013/7/1834315316011.30%NBYZ技偵大樓FHTL-02013/7/1954501218771.90%NBYZ技偵大樓FHTL-02013/7/201919262596.15%NBYZ技偵大樓FHTL-02013/7/2113132020100.00%NBYZ技偵大樓FHTL-02013/7/2247475151100.00%NBYZ技偵大樓FHTL-02013/7/2322222828100.00%小區(qū)測試開關(guān)參數(shù)問題問題現(xiàn)象：在月苑二試擴L-3小區(qū)下收不到該小區(qū)信號，無法接入該小區(qū)，導(dǎo)致該路段信號較弱，較大區(qū)域形成弱覆蓋。問題分析：測試車輛在月苑南路自西向東行駛至和墨香路交叉口區(qū)域，在交叉口區(qū)域該站下無法收到該小區(qū)信號，導(dǎo)致該路段覆蓋較差，嚴重影響下載速率，機房核查小區(qū)狀態(tài)正常，無告警情況。圖一在后臺對比核查參數(shù)發(fā)現(xiàn)，小區(qū)加載開關(guān)打開，且?guī)д鎸嵱脩舻哪M快開關(guān)關(guān)閉，導(dǎo)致用戶終端無法接入。MAC測試開關(guān)里有小區(qū)加載開關(guān)和帶真實用戶的模擬加載開關(guān)，小區(qū)加載開關(guān)打開的話，帶真實用戶的模擬加載開關(guān)就會生效。當需要加擾測試時需要把小區(qū)加載開關(guān)打開，而此時如果帶真實用戶的模擬加載開關(guān)關(guān)閉，表示小區(qū)處于模擬用戶加載情況，真實用戶不能接入，如果帶真實用戶的模擬加載開關(guān)打開，表示是用真實用戶進行加載，則真實用戶可以接入。月苑二試擴小區(qū)正是由于小區(qū)處于模擬加載狀態(tài)，且關(guān)閉了帶真實用戶的模擬加載開關(guān)導(dǎo)致測試終端搜不到小區(qū)信號，無法正常接入；解決建議：關(guān)閉小區(qū)加載開關(guān)解決效果：關(guān)閉小區(qū)加載開關(guān)后，終端能正常搜到小區(qū)信號，且接入正常。如下圖：問題總結(jié)對于無法接入小區(qū)的問題，建議處理措施：核查小區(qū)狀態(tài)和告警以及硬件問題情況。核查是否由參數(shù)問題導(dǎo)致小區(qū)加載開關(guān)默認關(guān)閉，在現(xiàn)網(wǎng)中進行模擬加載等測試時，測試完成后需要對參數(shù)及時進行恢復(fù)。全頻帶高干擾導(dǎo)致接入失敗問題干擾定義：在每個子幀輪詢一次后都會統(tǒng)計出在100個PRB中每個PRB的IOT值，當IOT值高于10的PRB個數(shù)大于等于3時為高IOT，查詢18次（早9:00到晚18:00每個小時一次數(shù)據(jù)，統(tǒng)計上行兩個時隙），如果同一個站點(包括3個小區(qū))超過6次干擾判定為干擾小區(qū)，其中IOT超過20為干擾嚴重小區(qū)，IOT在10~20之間的為干擾普通小區(qū)；如同一個小區(qū)多于6次超過80個PRB的IOT大于15判定為全頻帶高干擾小區(qū)。問題描述：寧波城市元年-2小區(qū)無線接通率只有59.38%，從信令流程上看到的是存在大量基站收不到終端發(fā)上來的RRCConnectionSetupComplete消息：問題分析：檢查基站狀態(tài)正常，查看小區(qū)無相關(guān)原因告警，從指標趨勢看，平均分布在每個時段；從CDL信令看UE發(fā)起由于enb給UE發(fā)起RRCConnectionRequest后ENB下發(fā)RRCconnectionsetup消息，但未收到終端上發(fā)的RRCConnectionSetupComplete消息，造成RRC連接建立完成超時，導(dǎo)致RRC連接建立失敗。查詢上行低噪，發(fā)現(xiàn)較多的PRB都存在較高的IOT值。對小區(qū)的IOT進行監(jiān)控，可以看到高干擾，并且鄰區(qū)并無大量用戶。解決效果：6月21日將城市元年-2小區(qū)PGC開關(guān)打開，該小區(qū)前后一周的KPI數(shù)據(jù)如下：ERAB掉線率無線接通率無線掉線率2013-6-140.56%59.38%5.26%2013-6-153.59%85.71%60.00%2013-6-160.00%82.14%0.00%2013-6-171.44%82.54%11.54%2013-6-180.68%89.31%3.57%2013-6-192.71%57.25%27.27%2013-6-200.00%100.00%0.00%14日-20日平均值1.28%79.48%15.38%2013-6-21

（打開PGC開關(guān)）0.33%97.44%0.00%2013-6-220.52%100.00%5.88%2013-6-230.00%98.39%0.00%2013-6-241.44%62.79%12.50%2013-6-251.18%92.86%6.82%2013-6-260.36%92.98%2.00%2013-6-270.73%96.00%2.38%2013-6-280.89%97.30%3.23%22日-28日平均值0.73%91.47%4.69%其中6月20日KPI數(shù)據(jù)異常，在未打開PGC開關(guān)的情況下各項KPI指標都非常好，查看KPI原始數(shù)據(jù)確認是當天業(yè)務(wù)量太少：RAB建立成功率分母[單位:次]RAB建立成功率分子[單位:次]RRC連接建立成功率分母[單位:次]RRC連接建立成功率分子[單位:次]無線接通率1919643859.38%1010282485.71%1313282382.14%2726494282.54%5756888089.31%22221387957.25%4455100.00%6767787697.44%如上述表格數(shù)據(jù)說明，在打開PGC開關(guān)后，無線接通率有所提升。ERAB建立成功率理論介紹涉及話統(tǒng)打點圖1圖2如圖1或圖2中A點所示，當eNodeB收到來自MME的INITIALCONTEXTSETUPREQUEST或者E-RABSETUPREQUEST消息時統(tǒng)計該指標。如果INITIALCONTEXTSETUPREQUEST或者E-RABSETUPREQUEST消息中要求同時建立多個E-RAB，則相應(yīng)指標根據(jù)業(yè)務(wù)的QCI按具體的E-RAB建立數(shù)目分別進行累加。如圖1或圖2中B點所示，當eNodeB向MME發(fā)送E-RABSETUPRESPONSE或者INITIALCONTEXTSETUPRESPONSE消息時統(tǒng)計該指標。如果E-RABSETUPRESPONSE或者INITIALCONTEXTSETUPRESPONSE消息中同時攜帶多個E-RAB的建立，則相應(yīng)指標按各個業(yè)務(wù)的QCI分別進行累加。指標指標描述小區(qū)E-RAB嘗試建立總次數(shù)用戶嘗試發(fā)起E-RAB建立流程的總次數(shù)小區(qū)E-RAB建立成功總次數(shù)用戶發(fā)起E-RAB建立流程，建立成功的總次數(shù)小區(qū)E-RAB建立失敗原因核心網(wǎng)問題導(dǎo)致E-RAB建立失敗次數(shù)傳輸層問題導(dǎo)致E-RAB建立失敗次數(shù)無線層問題導(dǎo)致E-RAB建立失敗次數(shù)無線資源不足導(dǎo)致E-RAB建立失敗次數(shù)安全模式配置失敗導(dǎo)致ERAB建立失敗次數(shù)此外，話統(tǒng)還針對各QCI進行了ERAB嘗試建立次數(shù)和ERAB建立成功次數(shù)的統(tǒng)計。由于目前很少用到不同的QCI，業(yè)務(wù)基本以QCI＝6的業(yè)務(wù)為主，所以不需要關(guān)注具體的業(yè)務(wù)類別的ERAB統(tǒng)計。指標定義ERAB建立成功率＝小區(qū)E-RAB建立成功總次數(shù)/小區(qū)E-RAB嘗試建立總次數(shù)×100％小區(qū)無線接通率＝RRC建立成功率×ERAB建立成功率。CDL信令流程及失敗原因正常過程上下文建立過程基本流程上下文建立過程基本流程上下文建立流程是以S1InitialContextSetupRequest開始，此后所有的消息都可以提取相同的eNBUEID。S1InitialContextSetupResponse消息標志著上下文建立基本流程的結(jié)束。S1InitialContextSetupRequest消息的詳細解碼結(jié)果中，E-RABToBeSetupListCtxtSUReq里面的承載個數(shù)等于1時，意味著這次上下文建立過程只是建立默認承載；而當此值大于1時，則意味著這次上下文建立過程除了建立默認承載外還要建立專用承載。在S1InitialContextSetupResponse消息的詳細解碼結(jié)果中，E-RABSetupListCtxtSURes里面的承載個數(shù)代表建立成功的默認承載和專用承載數(shù)目，E-RABList里面的承載個數(shù)代表建立失敗的默認承載和專用承載數(shù)目。專用承載建立基本流程專用承載建立基本流程專用承載建立流程以S1ERABSetupRequest消息開始，此后所有的消息都可以提取相同的eNBUEID。S1ERABSetupResponse消息標志著專用承載建立基本流程的結(jié)束。異常過程上下文建立過程中等待UE能力信息超時上下文建立過程中等待UE能力信息超時當看到UECapabilityEnquiry和S1InitialContextSetupFailure消息并且第3條消息的valueCause字段的值為failure-in-radio-interface-procedure時，標志著上下文建立流程中UE能力信息超時。上下文建立過程中等待安全模式完成超時上下文建立過程中等待安全模式完成超時當看到SecurityModeCommand和S1InitialContextSetupFailure消息并且最后一條消息的valueCause字段的值為failure-in-radio-interface-procedure時，標志著上下文建立流程中安全模式命令消息超時。上下文建立過程中等待RRC重配完成超時上下文建立過程中等待RRC重配完成超時當看到RRCConnectionReconfiguration和S1InitialContextSetupFailure消息并且最后一條消息的valueCause字段的值為failure-in-radio-interface-procedure時，標志著上下文建立流程中空口重配置消息超時。上下文建立過程中AS安全失敗上下文建立過程中AS安全失敗當看到SecurityModeFailure消息時，標志著上下文建立流程中安全配置失敗。上下文建立過程中傳輸錯誤上下文建立過程中傳輸錯誤當看到S1InitialContextSetupFailure消息并且其詳細解碼中的valueCause字段為transport-resource-unavailable時，標志著上下文建立流程中傳輸錯誤。上下文建立過程中內(nèi)部其他錯誤上下文建立過程中內(nèi)部其他錯誤當看到S1InitialContextSetupFailure消息并且其詳細解碼中的valueCause字段不為failure-in-radio-interface-procedure、transport-resource-unavailable和encryption-and-or-integrity-protection-algorithms-not-supported時，標志著上下文建立流程中內(nèi)部其他錯誤。專用承載建立過程中等待RRC重配完成超時專用承載建立過程中等待RRC重配完成超時當看到RRCConnectionReconfiguration和S1UEContextReleaseRequest消息并且最后一條消息的valueCause字段的值為failure-in-radio-interface-procedure時，標志著專用承載建立流程中空口重配置消息超時。相關(guān)案例介紹分析路由關(guān)系未配無法接入的問題問題描述：

蘭州LTE示范站，連接的是華為核心網(wǎng)，基站開通后，SCTP鏈路正常建立，小區(qū)正常，但是終端無法附著成功。問題分析：通過信令流程分析，在終端RRC建立完成，鑒權(quán)、安全流程完成后，核心網(wǎng)下發(fā)了終端上下文建立的請求，之后基站直接回復(fù)了上下文建立失敗，失敗原因valueCause:transport:transport-resource-unavailable，如下圖：定位過程：根據(jù)信令流程提示，通過查看失敗信令的前一條信令，核心網(wǎng)下發(fā)上下文建立請求消息中，攜帶的sgwiP地址如下圖，轉(zhuǎn)化成十進制是：：而在基站的傳輸配置中，檢查路由配置關(guān)系中發(fā)現(xiàn)，基站路由中沒有添加到這個網(wǎng)段的路由，所以導(dǎo)致了終端由于沒有傳輸路由而上下文建立失敗。解決效果：現(xiàn)場添加完成該網(wǎng)段路由后，終端附著成功，業(yè)務(wù)正常。網(wǎng)關(guān)IP配置錯誤導(dǎo)致無法附著問題描述：

南京統(tǒng)計KPI指標發(fā)現(xiàn)南體分校試擴LERAB建立全部失敗，全天失敗次數(shù)在兩萬多次，嚴重影響了全網(wǎng)指標。問題分析：通過提取該站的CDLlog分析發(fā)現(xiàn)，終端RRC建立已完成，鑒權(quán)和安全也已通過，核心網(wǎng)下發(fā)了終端上下文建立的請求后，基站直接回復(fù)了上下文建立失敗，失敗原因valueCause:transport:transport-resource-unavailable，通過ATP跟蹤信令流程和CDL看到的結(jié)果一樣，如下圖：定位過程：從CDLlog中的InitialContextSetupRequest消息中transportLayerAddress'01100100010001001111110100010001'B

對應(yīng)的是，通過核查確認核心網(wǎng)側(cè)的SGWIP確定是。對enb側(cè)的路由設(shè)置進行檢查，S1鏈路斷鏈恢復(fù)后，該基站的路由中包含的路由。而后通過仔細核查該路由關(guān)系，發(fā)現(xiàn)該條路由關(guān)系中網(wǎng)關(guān)IP地址：29和基站的IP地址:45不在同一個網(wǎng)段內(nèi)，檢查原始規(guī)劃數(shù)據(jù)，發(fā)現(xiàn)和規(guī)劃數(shù)據(jù)不一致，所以導(dǎo)致了終端由于傳輸錯誤而上下文建立失敗。解決效果：現(xiàn)場修改網(wǎng)關(guān)IP地址后，終端成功附著，業(yè)務(wù)正常。安全參數(shù)配置問題問題描述：福州移動使用三星S4終端無法附著，查看CDL，失敗原因是“SecurityModeFailure”。問題分析：1、查看目前基站安全開關(guān)為關(guān)閉，當此開關(guān)關(guān)閉時，基站默認選擇空算法EIA0進行完保。（協(xié)議規(guī)定安全開關(guān)關(guān)閉時，ENB默認一種算法進行完保，大唐目前默認空算法EIA0）查看安全開關(guān)節(jié)點：LMT-全局參數(shù)配置-全局測試開關(guān)-HL全局測試開關(guān)2、通過WIRESHARK抓包，終端上報的能力中，不支持空算法EIA0，所以終端接入時，基站使用默認空算法，導(dǎo)致終端安全模式失敗。定位結(jié)果：打開安全開關(guān)，基站根據(jù)配置算法的優(yōu)先級和終端支持的算法來選擇對應(yīng)適合的，即可保證終端完保通過。解決建議：按信令流程分析，當安全失敗時，一般都是基站設(shè)置的算法終端部支持，所以首先查看安全開關(guān)是否關(guān)閉，如果關(guān)閉則打開。安全開關(guān)打開后，如果終端不支持第一優(yōu)先級算法，則會根據(jù)算法優(yōu)先級一一選擇。解決效果：打開安全開關(guān)后，三星S4終端能夠成功附著。資源受限導(dǎo)致上下文建立失敗問題描述：南京華東電子管廠試擴L-2ERB失敗7435次，失敗集中在不同時間段內(nèi)！嚴重影響全網(wǎng)KPI指標。用CDL統(tǒng)計失敗原因為等待UE能力超時和等待安全模式完成超時。修改ENB定時器等待安全模式超時為10s，失敗還是很高。問題分析：分析CDL信令， 上下行都有比較多的信令多次重傳不成功丟棄,其中

"UE能力"和"安全模式"相關(guān)的信令丟失主要集中在上行。用CDL統(tǒng)計失敗原因為等待UE能力超時和等待安全模式完成超時，但具體分析了一下，發(fā)現(xiàn)cdl的統(tǒng)計是錯誤的，ue能力查詢發(fā)了718條，收到ue能力消息714條。安全命令1177條，安全響應(yīng)619條。基本都是安全響應(yīng)消息上不來，沒有ue能力上不來的情況。主要原因是safecommand下去之后，終端沒有反應(yīng)，并且基站很短時間就釋放了（看cdl是一或者兩個半幀）懷疑安全參數(shù)配置有問題。檢查完保算法以及安全加密等參數(shù)沒有發(fā)現(xiàn)問題，但是從KPI指標上發(fā)現(xiàn)ERAB建立失敗次數(shù)較多的時候基本發(fā)生在忙時（8：00到19點之間），而晚上則沒有REAB失敗情況。分析異常日志發(fā)現(xiàn)在ERAB建立失敗的時候伴隨有SR資源分配失敗的告警。查看基站配置文件，UPPS上單符號發(fā)sounding開關(guān)為打開，這樣的配置下小區(qū)支持的最大用戶數(shù)僅為4（半幀數(shù)）*1（符號數(shù)）*2（頻分）*3（碼分）=24個，分析原因是由于用戶數(shù)達到最大，導(dǎo)致資源分配不出來。定位結(jié)果：安全命令沒有響應(yīng)的失敗，是由于分配ERAB資源失敗導(dǎo)致上下文建立失敗。解決建議：修改UPPS上單符號發(fā)sounding開關(guān)為關(guān)閉，可支持48個用戶。如果還不能滿足需求的話可更改其他相關(guān)參數(shù)，如修改SRS上報周期為40ms，可支持更多的用戶數(shù)。解決效果：現(xiàn)場提取最近幾天的KPI指標，修改后指標已經(jīng)恢復(fù)，ERAB建立成功率達到平均99.54%切換成功率優(yōu)化理論介紹切換成功率是移動保持類的重要指標之一，按照涉及的網(wǎng)元關(guān)系可以分為ENB內(nèi)切換成功成功率、ENB間（包括X2切換和S1切換）切換成功率。切換成功率的高低，直接影響用戶感受，是運營商重點考核的KPI指標之一。指標定義切換（Handover）是移動通信系統(tǒng)的一個非常重要的功能。作為無線鏈路控制的一種手段，切換能夠使用戶在穿越不同的小區(qū)時保持連續(xù)的通話。切換成功率是指所有原因引起的切換成功次數(shù)與所有原因引起的切換請求次數(shù)的比值。切換主要的目的是保障通話的連續(xù)，提高通話質(zhì)量，減小網(wǎng)內(nèi)越區(qū)干擾，為UE用戶提供更好的服務(wù)。切換成功率主要通過話務(wù)統(tǒng)計結(jié)果獲得，推薦的公式為：ENB間切換成功率=(ENB間S1切換出成功次數(shù)+ENB間X2切換出成功次數(shù))/(ENB間S1切換出執(zhí)行請求次數(shù)+ENB間X2切換出執(zhí)行請求次數(shù))ENB內(nèi)切換成功率=eNB內(nèi)切換出成功次數(shù)/eNB內(nèi)切換出請求次數(shù)*100%1）ENB間切換相關(guān)的指標描述如下：指標指標描述小區(qū)eNodeB間切換出嘗試次數(shù)小區(qū)eNodeB間切換出嘗試次數(shù)小區(qū)eNodeB間切換出成功次數(shù)小區(qū)eNodeB間切換出成功次數(shù)小區(qū)切換出失敗次數(shù)核心網(wǎng)原因?qū)е虑袚Q出準備失敗次數(shù)目標小區(qū)無響應(yīng)導(dǎo)致切換出準備失敗次數(shù)目標小區(qū)回復(fù)切換準備失敗消息導(dǎo)致切換出準備失敗次數(shù)源小區(qū)接收到測量報告后不觸發(fā)切換請求指示導(dǎo)致切換失敗次數(shù)源小區(qū)發(fā)送切換取消導(dǎo)致切換出失敗次數(shù)2）ENB內(nèi)切換相關(guān)的指標描述如下：指標ID指標描述小區(qū)eNodeB內(nèi)切換出嘗試次數(shù)小區(qū)eNodeB內(nèi)切換出嘗試次數(shù)小區(qū)eNodeB內(nèi)切換出成功次數(shù)小區(qū)eNodeB內(nèi)切換出成功次數(shù)小區(qū)切換出失敗次數(shù)目標小區(qū)無響應(yīng)導(dǎo)致切換出準備失敗次數(shù)目標小區(qū)回復(fù)切換準備失敗消息導(dǎo)致切換出準備失敗次數(shù)源小區(qū)接收到測量報告后不觸發(fā)切換命令導(dǎo)致切換失敗次數(shù)源小區(qū)發(fā)送切換取消導(dǎo)致切換出失敗次數(shù)CDL信令流程正常過程總體流程圖：X2切換源側(cè)正常流程：UU接口MeasurementReport消息代表UE測量上報流程的開始，也就是X2切換源側(cè)流程的第1條消息。第2、3條消息為X2接口的X2HandoverRequest和X2HandoverRequestAcknowledge消息，注意對于X2切換源側(cè)來講，第2條消息為發(fā)送，第3條消息為接收。第4條消息是UU接口的RRCConnectionReconfiguration，注意在這條消息asn解碼后的內(nèi)容中，必須存在mobilityControlInfo字段。X2切換目標側(cè)正常流程：每當在CDLlog中發(fā)現(xiàn)一條接收方向的X2接口X2HandoverRequest消息時，代表X2切換目標側(cè)流程的開始。第2條消息為X2接口的X2HandoverRequestAcknowledge，注意這兩條消息對于X2切換目標側(cè)來講，分別為接收、發(fā)送。第3、4、5、6條消息分別為UU接口的RRCConnectionReconfigurationComplete、S1接口的S1PathSwitchRequest消息和S1PathSwitchRequestAcknowledge消息以及X2接口的X2UEContextRelease消息。優(yōu)化方法介紹LTE系統(tǒng)內(nèi)所有切換問題最終都可以歸納為ENB間的小區(qū)間切換和ENB內(nèi)的小區(qū)間切換等。根據(jù)現(xiàn)網(wǎng)處理該問題的案例和現(xiàn)網(wǎng)實施的經(jīng)驗，影切換問題的可能原因大概分為如下幾條：硬件傳輸故障（載頻壞、合路天饋問題）；數(shù)據(jù)配置不合理；擁塞問題；時鐘問題；干擾問題；覆蓋問題及上下行不平衡；當出現(xiàn)切換成功率低的問題時，首先按照切換問題分類，了解切換問題的范圍，然后根據(jù)硬件、數(shù)據(jù)配置、擁塞、時鐘、干擾、覆蓋等方面入手逐一排查解決，排除這些影響切換成功率的客觀因素，然后根據(jù)自動鄰區(qū)優(yōu)化提升切換成功率。切換信令流程1．基站內(nèi)小區(qū)間切換信令流程，如圖1所示：圖1：基站內(nèi)小區(qū)間切換信令流程2．基站間S1切換測試流程，如圖2所示：圖2：S1切換源基站側(cè)信令流程3．基站間X2切換測試流程，如圖3所示：圖3：X2切換目標基站側(cè)信令流程涉及話統(tǒng)打點小區(qū)eNodeB內(nèi)同頻切換出嘗試次數(shù)：如圖中A點所示，在eNodeB內(nèi)切換過程中，當小區(qū)接收到UE的MeasurementReport消息后，切換判決要進行eNodeB內(nèi)切換時，上述測量指標加1。各指標的具體統(tǒng)計方式如下所示：源小區(qū)和目標小區(qū)頻點相同，指標L.HHO.IntraeNB.IntraFreq.PrepAttOut加1。小區(qū)eNodeB內(nèi)同頻切換出成功次數(shù)：圖1圖2如圖1中C點所示，在eNodeB內(nèi)切換過程中，當eNodeB目標小區(qū)收到UE返回的RRCConnectionReconfigurationComplete消息后，等待切換過程中的緩存數(shù)據(jù)轉(zhuǎn)發(fā)完成時統(tǒng)計相應(yīng)指標，如果切換過程中源小區(qū)和目標小區(qū)頻點相同，指標L.HHO.IntraeNB.IntraFreq.ExecSuccOut加1；或者如圖2中C點所示，在eNodeB內(nèi)切換過程中，當eNodeB目標小區(qū)收到UE返回的RRCConnectionReestablishmentComplete消息時，如果切換過程中源小區(qū)和目標小區(qū)頻點相同，指標L.HHO.IntraeNB.IntraFreq.ExecSuccOut加1。切換問題分類切換分類需要在分析切換成功率問題之前確定如下幾方面內(nèi)容：首先，通過話統(tǒng)分析確定切換失敗的范圍，如果是所有小區(qū)切換成功率低，要從切換特性參數(shù)、硬件傳輸、系統(tǒng)時鐘來檢查問題；其次，其他情況則過濾得出TOPN最差小區(qū)，針對小區(qū)按照如下的步驟進行排查問題。第三，查詢切換性能測量中的出小區(qū)切換和入小區(qū)切換成功率，來分析是切出失敗還是切入失敗。再分析問題小區(qū)的出小區(qū)和入小區(qū)切換性能測量，從出小區(qū)性能測量中找出是往哪些小區(qū)切換失敗，分析所有這些切入失敗的小區(qū)“入小區(qū)切換失敗次數(shù)（由于擁塞）”和“話務(wù)量（業(yè)務(wù)信道）”和“擁塞率”，確認是否目標小區(qū)擁塞導(dǎo)致切換失敗。（1）硬件和傳輸故障硬件故障的現(xiàn)象表現(xiàn)為：告警系統(tǒng)上報相應(yīng)的告警信息。首先要排除這些硬件故障告警，若硬件故障告警恢復(fù)，則查看話務(wù)統(tǒng)計信息和分析切換指標。硬件故障的情形如下：ENB傳輸管理單元；ENB載頻故障；ENB天饋故障；處理過程：檢查硬件數(shù)據(jù)配置，如果出現(xiàn)故障的小區(qū)及其相鄰小區(qū)的數(shù)據(jù)配置在近期沒有修改，突然出現(xiàn)切換問題，則應(yīng)首先考慮是否ENB硬件故障造成。若該ENB下只有一個小區(qū)出現(xiàn)切換問題，則考慮是否由該小區(qū)本身的硬件故障造成，如部分載頻損壞，引起呼叫切換到該載頻時失敗。對于上述問題，可以采用閉塞部分載頻的方式來驗證。若閉塞某個載頻后，切換成功率恢復(fù)正常，則可以查看是否該載頻故障，或與該載頻相關(guān)的BBU或天饋故障。若某載頻的上下行信號嚴重不平衡，則會經(jīng)常造成切換問題，如頻繁切換、切換成功率下降等。（2）數(shù)據(jù)配置不當數(shù)據(jù)配置不當導(dǎo)致的故障現(xiàn)象表現(xiàn)為：UE不發(fā)起切換或過多的發(fā)起切換，從而影響切換成功率。由于切換判決算法受切換參數(shù)的控制，如果切換參數(shù)配置不當，可能導(dǎo)致MS不發(fā)起切換或過多的發(fā)起切換，此時可從以下方面來考慮：數(shù)據(jù)配置中的切換門限設(shè)置是否合理避免因切換門限設(shè)置過大導(dǎo)致難切換現(xiàn)象，或設(shè)置過小導(dǎo)致頻繁切換現(xiàn)象，設(shè)置合理的切換保證不發(fā)生乒乓切換，各門限的設(shè)置參考《LTE無線網(wǎng)絡(luò)和業(yè)務(wù)參數(shù)標定手冊》,一般不要出現(xiàn)大幅偏離基線值的情況。數(shù)據(jù)配置中的切換候選小區(qū)參數(shù)設(shè)置是否合理；避免因鄰區(qū)漏配導(dǎo)致UE無法切換到該鄰區(qū)；數(shù)據(jù)配置中的切換遲滯設(shè)置是否合理；避免因切換遲滯設(shè)置過大導(dǎo)致難切換現(xiàn)象，或設(shè)置過小導(dǎo)致頻繁切換現(xiàn)象；當切換發(fā)生異常時，需要快速檢查一下切換定時器，保證切換定時器不低于設(shè)定的默認值。（3）目標小區(qū)擁塞目標小區(qū)擁塞的故障現(xiàn)象表現(xiàn)為：UE發(fā)起切換請求后申請不到信道而切換失敗。導(dǎo)致小區(qū)擁塞的原因如下：小區(qū)下用戶數(shù)目激增，超過設(shè)計用戶數(shù)；網(wǎng)優(yōu)參數(shù)設(shè)置不當，導(dǎo)致小區(qū)吸收了過多用戶；切換參數(shù)設(shè)置不當，導(dǎo)致切入小區(qū)的用戶數(shù)增多；當目標小區(qū)出現(xiàn)擁塞導(dǎo)致切換失敗后，為避免UE試圖再次切換到此目標小區(qū)，應(yīng)對目標小區(qū)進行懲罰。建議將“懲罰處理允許”設(shè)為“是”。查看擁塞小區(qū)信道狀態(tài)是否正常，如果載頻故障或信道狀態(tài)異常，首先排除相關(guān)故障。（4）時鐘問題時鐘不同步、時鐘不穩(wěn)是引起切換掉話的重要原因，應(yīng)注意保持基站時鐘穩(wěn)定，否則會因為時鐘不穩(wěn)，引起切換失敗以及掉話過多。時鐘參考源異常，基站時鐘與其他基站時鐘之間可能出現(xiàn)偏差，導(dǎo)致UE在切換時可能出現(xiàn)異常。解決時鐘失鎖以及參考源異常問題，首先需要檢查告警：首先檢查是否存在時鐘相關(guān)告警，如果存在，則根據(jù)告警處理手冊進行處理，然后觀察切換成功率。（5）干擾問題網(wǎng)絡(luò)存在較大的干擾，容易引起接收質(zhì)量下降，導(dǎo)致干擾切換或者質(zhì)差切換增多，從一定程度上降低了現(xiàn)網(wǎng)的服務(wù)質(zhì)量，影響用戶的感受，甚至一定程度上影響切換成功率。干擾問題主要通過路測發(fā)現(xiàn)現(xiàn)網(wǎng)存在的干擾大的小區(qū)或者頻點，然后通過調(diào)整天饋傾角，更換頻點，調(diào)整發(fā)射功率和小區(qū)覆蓋范圍等常規(guī)的RF優(yōu)化手段解決。也可以通過輔助手段，登記干擾帶測量，來估計下行的干擾情況。（6）覆蓋問題及上下行平衡信號覆蓋問題的現(xiàn)象表現(xiàn)為：切換成功率低、用戶直觀感受差。信號覆蓋問題主要存在三類，一類是越區(qū)覆蓋，由于邊緣門限設(shè)置過低，基站功率過大，傾角不合適導(dǎo)致越區(qū)覆蓋，形成同頻干擾，影響切換成功率；一類是孤島效應(yīng)引起的切換成功率低，如服務(wù)小區(qū)的覆蓋遠遠超過其鄰區(qū)，且未與其鄰區(qū)的鄰區(qū)配置相鄰關(guān)系，這種情況容易在服務(wù)小區(qū)的邊緣發(fā)生切換失?。蝗醺采w形成的覆蓋漏洞。信號覆蓋問題主要通過網(wǎng)優(yōu)的路測報告發(fā)現(xiàn)現(xiàn)網(wǎng)的覆蓋問題，通過RF優(yōu)化解決。相關(guān)案例介紹分析切換目標側(cè)準備失敗問題描述：海南提取KPI指標發(fā)現(xiàn)多站存在切換成功率較低的問題。對象標識ENBLTE_切換成功率[單位:%]五指山避暑山莊-DLH-348329188.89五指山電視局-DLH-248332133.33五指山二中-DLH-348330954.67五指山經(jīng)濟住用房-DLH-348331044.55五指山農(nóng)聯(lián)社-DLH-248330072.13五指山水岸別墅路燈桿-DLH-14832903.39五指山水岸別墅路燈桿-DLH-248329045.91五指山水岸別墅路燈桿-DLH-348329091.30五指山新華路人民法院-DLH-248331181.58五指山中學學生宿舍-DLH-24832996.34問題分析：提取幾個站點的CDL分析統(tǒng)計發(fā)現(xiàn)，所有切換成功率較低的站點均是切向五指山賓館（483322），失敗原因為切換目標側(cè)準備失敗，源側(cè)在發(fā)起X2HandoverRequest后目標基站直接回復(fù)X2HandoverPreparationFailure

，攜帶原因為：unspecified，由此可以判斷是目標側(cè)基站的問題。檢查目標側(cè)基站的配置文件，小區(qū)ID配置成功了505152，正確配置應(yīng)該為012。因為在源側(cè)的外部鄰區(qū)里我們加的關(guān)系是012，目標側(cè)在查詢本地小區(qū)Id時失敗，所以在切換時根本沒有該目標小區(qū)，從而導(dǎo)致切換失敗。解決建議：修改小區(qū)ID為012，出現(xiàn)這種問題很可能是開站時配置文件導(dǎo)入錯誤，建議在今后開站時盡量檢查一下配置文件的準確性。切換算法參數(shù)配置不當問題描述：寧波KPI分析發(fā)現(xiàn)華東物資城-1小區(qū)和世紀商務(wù)-1小區(qū)切換失敗次數(shù)較多。問題分析：通過分析CDL發(fā)現(xiàn)，切換失敗原因主要為切換源側(cè)切換準備階段超時。華東物資城-1小區(qū)PCI為307，世紀商務(wù)-1小區(qū)PCI為416，不存在模式3干擾的情況。在切換發(fā)生本小區(qū)與目標小區(qū)信道環(huán)境比較差，源小區(qū)RSRP為-115dbm，目標小區(qū)RSRP為-110dbm，顯然有些過晚切換。查看CDL日志，發(fā)現(xiàn)之前信號較好的時候上報了MR沒有切換，查看UE來源，確認是發(fā)生了乒乓切換，剛剛從PCI=415小區(qū)切換入PCI=307小區(qū)后，又往回切。但兵乓切換檢測開關(guān)限制他的回切時間，導(dǎo)致切換過晚，失敗較多。解決建議：經(jīng)過評估與分析，當前乒乓切換的時間門限配置為5s，門限過長，為了減少乒乓切換抑制對切換造成的影響，建議將乒乓切換的時間門限由5s改為3s。解決效果：通過把乒乓切換的時間門限配置為3s，經(jīng)觀察華東物資城-1小區(qū)的指標有明顯提升，切換率大大得到提高，也不再是TOP小區(qū)。小區(qū)個性偏移參數(shù)調(diào)整案例問題描述：紅色框內(nèi)問題路段占用NBHS培羅成大樓FHTL-0小區(qū)，占用該小區(qū)后SINR差。問題分析：問題路段主覆蓋小區(qū)應(yīng)為NBHS交郵樓-0（PCI：114）小區(qū)，但實際在該問題路段經(jīng)常由NBHS交郵樓-0（PCI：114）小區(qū)切換到NBHS培羅成大樓-0（PCI：135）小區(qū)，兩小區(qū)在問題路段RSRP相差不大，切過去占用NBHS培羅成大樓-0（PCI：135）小區(qū)后SINR很差，且兩小區(qū)存在模3干擾，嘗試將NBHS培羅成大樓-0（PCI：135）小區(qū)功率降低，但依然會切換到該小區(qū)，解決建議：問題路段存在模3干擾，且周邊道路都沒占用NBHS培羅成大樓-0（PCI：135）小區(qū)，我們將該小區(qū)信號參考功率降到-15，加NBHS交郵樓-0（PCI：114）小區(qū)到NBHS培羅成大樓-0（PCI：135）小區(qū)個性偏移-5（加到NBHS交郵樓-0抑制向NBHS培羅成大樓-0小區(qū)切換）解決效果：通過調(diào)整小區(qū)功率，又修改小區(qū)個性偏移參數(shù)，問題路段不再占用NBHS培羅成大樓-0（PCI：135）小區(qū)，而是由主覆蓋小區(qū)來覆蓋，SINR明顯改善。切換時終端接入到非源和目標小區(qū)導(dǎo)致核心網(wǎng)釋放用戶問題問題描述：寧波LTE小區(qū)，KPI分析五金批發(fā)-2的CDL日志，切換失敗統(tǒng)計為核心網(wǎng)釋放，原因為normalrelease；問題分析：LTE終端切換流程：UE占用五金批發(fā)FHTL-2_302小區(qū)由東向西進入江東城建FHTL-0_21切換失敗如下圖：通過CDL信令分析，源小區(qū)測收到EPC下發(fā)的S1UEContextReleaseCommand；目標測也沒有收到重配置完成的消息；失敗原因值：normalrelease；查看終端側(cè)LOG，發(fā)現(xiàn)終端并沒有收到切換的重配置消息，在源小區(qū)的信號降低到一定程度的時候失步。然后UE發(fā)起了重建立請求重建到第三個小區(qū)姚隘路FHTL-0_336,由于UE重新接入了新的小區(qū)，所以核心網(wǎng)釋放了源小區(qū)的UEContext。從姚隘路FHTL-0側(cè)的CDL日志可以看出，基站只收到了單獨的一條重建立消息，并沒有該UE的上下文消息，所以重建立被拒絕。解決建議：根據(jù)測試結(jié)果，發(fā)現(xiàn)在切換失敗的位置下行的干擾比較嚴重，該處存在4個主覆蓋小區(qū)RSRP相差在6dB以內(nèi)，且存在鄰小區(qū)PCI模3相等：針對該處問題做了如下的優(yōu)化：

（1）江東城建FHTL-0_21和江東城建FHTL-1_22兩個小區(qū)的PCI對調(diào)；

（2）姚隘路FHTL-0_336小區(qū)功率降到-15；

（3）錦達賓館FHTL-0_93小區(qū)功率調(diào)到12；

（4）體育館FHTL-2_277小區(qū)功率調(diào)整到6；調(diào)整前測試40次失敗4次，調(diào)整后測試40次失敗0次。解決效果：通過以上的修改，經(jīng)觀察五金批發(fā)-2小區(qū)的指標有明顯提升，切換率得到提高。效果如圖：鄰區(qū)移動網(wǎng)絡(luò)碼配置錯誤導(dǎo)致S1切換失敗問題描述：9月26日，10點至11點佛手湖試擴L-1通過S1切換至頂山食品廠請求了13次，且全部切換失敗。查看小區(qū)無告警。查詢小區(qū)無上行干擾，由于S1切換失敗次數(shù)較多，影響全網(wǎng)的S1切換成功率占比。問題分析：從CDL信令看，在2013-9-2610:10:49時刻，UE在佛手湖試擴L-1主服務(wù)下上發(fā)MeasurementReport，堯勝村東試擴L-1發(fā)出S1HandoverRequire，EPC回復(fù)S1HandoverPreparationFailure，原因值為：unknown-targetID。通過CDL切換統(tǒng)計功能，發(fā)現(xiàn)S1切換失敗的目標基站都是329277，可以初步判斷出是佛手湖試擴L-1到目標基站329277（頂山食品廠）的小區(qū)的切換出現(xiàn)問題。從mapinfo中，目標基站頂山食品廠試擴L屬于佛手湖試擴L-1小區(qū)正打方向覆蓋銜接基站，首先核查源基站小區(qū)和目標基站狀態(tài)均正常，且無上行干擾和告警故障等。其次核查佛手湖試擴L-1小區(qū)和頂山食品廠試擴L存在鄰區(qū)關(guān)系，且X2鏈路配置正常。通過佛手站告警信息可以知道是由于存在X2連接的狀態(tài)下沒有查到鄰基站信息。但是根據(jù)佛手站的配置文件，存在329277站的基站信息。如圖，鄰基站移動網(wǎng)絡(luò)碼是00，但是外部鄰區(qū)和鄰小區(qū)關(guān)系中都為08。錯誤的mcc和mnc會導(dǎo)致獲取鄰基站信息失敗。所以S1切換失敗，根據(jù)切換準備失敗的原因，是EPC沒有對端基站信息。解決建議：刪除配置錯誤的鄰區(qū)關(guān)系，重新添加，修改鄰區(qū)中的移動網(wǎng)絡(luò)碼由08→00解決效果：鄰區(qū)重新調(diào)整后，可以進行正常的X2切換，且切換成功。開啟防乒乓切換開關(guān)導(dǎo)致不切換問題描述： 9月21日下午福州LTE簇13摸底測試過程中，由閩侯上街金橋物業(yè)_2(PCI:208)往閩侯上街_1（PCI:234）切換成功，在目標小區(qū)駐留約2秒后，由于拐角RSRP波動，滿足A3事件觸發(fā)條件，UE上報A3事件的MR后，未收到ENB下發(fā)的帶有MobilityControlInfo信息的RRCConnectionReconfiguration消息，無法完成切換最終導(dǎo)致UE發(fā)起小區(qū)重選，業(yè)務(wù)中斷。問題分析： 目前福州項目LTE同頻采用A3事件作為切換依據(jù)，按切換必須進行的三步（測量、判斷、執(zhí)行），參照以下簡易空口切換流程逐步進行分析。否否是否下發(fā)A3測量控制是否上報A3測量報告是否收到RRC重配消息請求切換是是否否否是是否上發(fā)RRC重配完成消息切換算法未開啟、A3測量未配置無滿足條件的合適小區(qū)、A3測量條件過于苛刻鄰區(qū)漏配或錯配、基站故障、上行干擾導(dǎo)致基站未收到MR、開啟乒乓切換算法UE不支持或其他問題 從信令可以看出UE已經(jīng)上報A3事件MR，但是未收到ENB下發(fā)的RRC重配消息切換請求。 首先檢查是否鄰區(qū)漏配或錯配，通過查看閩侯上街_1的測量控制消息（攜帶measConfig信息的RRCConnectionReconfiguration消息）中第7個同頻測量小區(qū)即為PCI:234，同時核查外部鄰區(qū)參數(shù)、X2鏈路配置確認鄰區(qū)相關(guān)參數(shù)配置無誤。 后臺登錄LMT檢查源基站和目標基站都無告警，提取該時段源基站(閩侯上街_1（PCI:234）)CDL日志，分析X2和S1口信令，可以看到上一次由閩侯上街金橋物業(yè)_2(PCI:208)切換到閩侯上街_1（PCI:234）成功后，基站測已經(jīng)收到UE上報的MR，且與UE測上報的MR一致，但是并未下發(fā)RRC重配消息請求切換，至此基本能排除上行干擾導(dǎo)致基站無法收到或正確解析MR。 查看基站RRM接口消息，發(fā)現(xiàn)有RRM判斷測量報告處理結(jié)果為失?。≧RM_HC_MEAS_HDLFAILURE）,即基站判決未通過，而正常的切換流程RRM判斷通過后會有RRM_HC_MEAS_HDLSUCCESS，然后CPM層再給RAC層發(fā)送切換請求，切換才得以繼續(xù)進行。 最后檢查閩侯上街_1的切換算法配置(小區(qū)>小區(qū)算法>切換)如下，防用戶乒乓切換開關(guān)為打開，用于判斷乒乓切換的目標小區(qū)停留時間門限為5秒，即如果由A小區(qū)切后B小區(qū)后，5秒內(nèi)如果UE上報MR中為A小區(qū)，基站判斷此次切換為乒乓切換，而導(dǎo)致切換判決不通過，空口直觀表現(xiàn)為上報MR但無法切換，或切換過慢。解決措施： 乒乓切換對速率、掉線率和信令負荷都會有一定影響，應(yīng)當盡量避免發(fā)生乒乓切換。抑制乒乓切換有效的方法有： >控制好覆蓋，合理設(shè)置切換帶； >適當調(diào)整A3參數(shù)（遲滯、偏移值、觸發(fā)時延），以及CIO； >合理應(yīng)用防乒乓切換算法。 而實際的某些優(yōu)化場景中，必須要發(fā)生乒乓切換才能保證業(yè)務(wù)連續(xù)性。針對類似場景從用戶感知出發(fā)，可以考慮關(guān)閉防乒乓切換算法，或降低乒乓切換判斷時間以允許乒乓切換。處理效果： 結(jié)合現(xiàn)場無線環(huán)境，RF調(diào)整無法有效的控制該拐角處主覆蓋，選擇關(guān)閉防乒乓切換算法，調(diào)整后現(xiàn)場復(fù)測，UE由閩侯上街金橋物業(yè)_2(PCI:208)往閩侯上街_1（PCI:234）切換成功，駐留3秒后，上報MR，基站下發(fā)RRC重配消息請求切換，最終切換完成，業(yè)務(wù)未中斷。配置垃圾鄰區(qū)導(dǎo)致只上報MR不觸發(fā)切換問題描述：

麗水多站發(fā)現(xiàn)只上報MR后，不觸發(fā)切換。重新刪除所有鄰小區(qū)后再添加問題解決，可以正常切換。問題分析：查看CDL：UE上發(fā)MR之后，鄰小區(qū)的PCI為79（LSJY東渡FHTL-1），從RRM_MRH_MEAS_PRT_HDL_RESULT信令可以看出基站判決目標小區(qū)為本小區(qū)的鄰小區(qū)，但是后面一條RRM_HC_MEAS_HDLFAILURE中的詳細解碼中判決為沒有EUTRAN鄰區(qū)關(guān)系，但是查看小區(qū)的鄰小區(qū)和EUTRAN鄰小區(qū)以及SCTP鏈路均正常。出現(xiàn)這種情況說明基站側(cè)沒有找到目標鄰區(qū)，一種情況是一種情況是鄰區(qū)配置的不正確，因為鄰小區(qū)關(guān)系和外部鄰小區(qū)有關(guān)聯(lián)關(guān)系。另一種情況就是上報的是除了鄰區(qū)外的未知小區(qū)。但查看鄰區(qū)配置里有PCI為79的外部鄰區(qū)以及鄰小區(qū)關(guān)系。查看異常告警日志，不斷上報查詢相鄰ENB小區(qū)配置信息出錯和獲取有效的目標小區(qū)失敗的告警。再次核查鄰小區(qū)關(guān)系發(fā)現(xiàn)3個小區(qū)均添加有基站ID為415000的鄰區(qū)，而外部鄰區(qū)卻不存在此基站ID，導(dǎo)致高層在進行數(shù)據(jù)效驗時一直不過，從而不斷上報查詢相鄰ENB小區(qū)配置信息出錯的告警。此基站ID占用的鄰小區(qū)索引都比較靠前，全部占用了3個小區(qū)的索引1和2，基站一直找不到以下正常存在的鄰小區(qū)關(guān)系，所以即使終端上報了MR，也不能正常觸發(fā)切換。解決建議：現(xiàn)場刪除多余的垃圾鄰小區(qū)關(guān)系后，切換正常。出現(xiàn)此種問題很有可能是在開站時使用的配置數(shù)據(jù)就已經(jīng)存在了垃圾鄰區(qū)，而簇優(yōu)化時也沒有將此垃圾鄰區(qū)刪除，造成不能切換。建議外場在開站以及鄰區(qū)核查時加強對垃圾鄰小區(qū)的核查和定期刪除。終端發(fā)A3切換測量報告后，不觸發(fā)異頻切換問題描述：云南師大商學院動感廳室分站點，為E頻段小區(qū)（基站ID=5513）往師大商學院站點，為F頻段小區(qū)（基站ID=2129）能夠成功切換，但反之，師大商學院往學院動感廳室分小區(qū)無法完成切換。問題分析：通過提取師大商學院宏基站F頻段小區(qū)的CDL日志分析，源小區(qū)收到了終端上報的測量報告，測量報告中也上報了PCI=1（學院動感廳室分）E頻段小區(qū)。如下圖：但根據(jù)終端上報的測量報告中的MeasId，對應(yīng)測量的RRC重配置消息來看，終端上報的測量報告標識不是切換的A3測量。而是用于小區(qū)干擾協(xié)調(diào)算法的A3測量，所以不會觸發(fā)切換。消息如下圖：通過對比檢查宏站的基站配置文件，發(fā)現(xiàn)異頻載波信息中“小區(qū)重選頻點優(yōu)先級”配置的是1，而小區(qū)重選公共參數(shù)中“小區(qū)重選優(yōu)先級”配置的是3；目前我們基站的異頻切換是基于A2+A3算法，A3為相同頻率優(yōu)先級的切換算法，如果外場要觸發(fā)A3的異頻測量，這兩個優(yōu)先級必須配置相同。解決建議：現(xiàn)場將參數(shù)配置進行修改，把宏基站的“小區(qū)重選優(yōu)先級”設(shè)置相同，問題得到解決。R9和R10協(xié)議不兼容導(dǎo)致切換失敗問題問題描述：

近期多地出現(xiàn)跨廠家切換失敗問題，有華為切向我們大唐失敗的，也有中興切向我們大唐失敗的?？蛻舯容^關(guān)注。問題分析：分析華為切向我們的CDL，華為基站在向我們發(fā)起X2切換請求后，我們直接回復(fù)X2HandoverPreparationFailure，解析失敗的原因為：transfer-syntax-error 失敗的pucch-ConfigDedicated對比正常的pucch-ConfigDedicated：分析中興切向我們的CDL，在源側(cè)中興基站發(fā)起切換請求后，我們回復(fù)了切換響應(yīng)，但之后由于沒有在目標基站完成隨機接入，從而源側(cè)發(fā)起了切換取消命令。定位過程：根據(jù)R9協(xié)議，華為作為源側(cè)給我們傳遞的pucch-ConfigDedicated中tdd-AckNackFeedbackMode字段有問題，該字段在TDD下必須存在。而華為與大唐對協(xié)議的支持能力不同，當終端上報R10能力時，華為是按照R10協(xié)議實現(xiàn)的ACK/NACK反饋，而大唐仍然用R8/R9協(xié)議中的描述做校驗，所以出現(xiàn)了問題。也就是說在R10中，當系統(tǒng)使用pucch-Format信元表征反饋模式，可以不需攜帶tdd-AckNackFeedbackMode信元。切換失敗時，終端就是R10的，華為使用了pucch-Format信元表征反饋模式，大唐按照R8/9中的描述強制校驗了tddAckNackFeedbackMode信元導(dǎo)致出錯。參考協(xié)議：根據(jù)中興的反饋，現(xiàn)場通過GRANDSII手機測試信令如下：

切換失敗時，切換的RRCConnectionReconfiguration消息的mobilityControlInfo的專用資源配置如下：

切換成功時，切換的RRCConnectionReconfiguration消息的mobilityControlInfo的專用資源配置如下：最終確認為終端從R10切換到R9時天線配置時出現(xiàn)了該問題引起切換失敗。定位結(jié)果：

華為的站向我們的切換時由于切換請求中AS-CONFIG字段中缺少了tdd-AckNackFeedbackMode字段，而這個字段在R10中被修改為了可選，導(dǎo)致我們切換準備失敗，這個問題可以通過HL修改代碼來進行規(guī)避。中興的站向我們切換時，AS-CONFIG字段中存在了tdd-AckNackFeedbackMode字段，并且我們可以成功解析并且成功回復(fù)了ACK的消息，但是我們的ACK字段中不包含R10字段，終端不認導(dǎo)致中興的基站給我們發(fā)送了切換取消，這種情況在608版本中只能通過fullconfig來進行解決。無線掉線率優(yōu)化理論介紹ERAB異常釋放：圖1圖2如圖1中A點所示，當eNodeB向MME發(fā)送E-RABRELEASEINDICATION消息，當相應(yīng)承載有數(shù)傳且釋放原因不為