TD-LTE網優KPI指標優化工作指導手冊項目名稱文檔編號版本號作者版權所有大唐移動通信設備有限公司本資料及其包含的所有內容為大唐移動通信設備有限公司(大唐移動)所有,受中國法律及適用之國際公約中有關著作權法律的保護。未經大唐移動書面授權，任何人不得以任何形式復制、傳播、散布、改動或以其它方式使用本資料的部分或全部內容，違者將被依法追究責任。文檔更新記錄日期更新人版本備注2013-7-17王學斌.1創建2013-7-31王學斌盧顥V0.添加RRC、ERAB、掉線CDL信令流程及失敗原因2013-9-20王學斌、張發厚、索志剛、魏曉東、閆俊霖、徐世勛編寫案例2013-9-29徐世勛2013-10-23王學斌、周曉華、王會慶V0.0.5增加案例2013-10-24徐世勛V0.0.6匯總及增加KPI問題處理工單模板2013-11-5徐世勛V0.0.7根據評審意見進行修改2013-11-8童志堅V0.0.8

目錄1 前言 52 KPI優化的工作流程及內容 5 KPI優化工作總體流程 5 KPI優化工作內容 6 KPI數據生成 6 KPI數據分析 7 問題處理 7 問題跟蹤和核查 8 KPI優化工作邏輯圖 8 KPI優化工作模板和示例 93 RRC連接建立成功率優化 10 理論介紹 10 指標定義 10 CDL信令流程及失敗原因 11 正常過程 11 異常過程 11 優化方法介紹 12 上行隨機接入的問題 14 小區重選參數問題 14 下行初始發射功率偏低問題 15 上行初始功控問題 15 相關案例介紹分析 15 小區重選參數問題 15 小區上行功控參數設置問題 17 小區測試開關參數問題 19 ＳＣＴＰ內存池耗盡導致信令發送失敗問題 21 全頻帶高干擾導致接入失敗問題 244 ERAB建立成功率 27 理論介紹 27 指標定義 29 CDL信令流程及失敗原因 29 正常過程 29 異常過程 30 相關案例介紹分析 33 路由關系未配無法接入的問題 33 網關IP配置錯誤導致無法附著 35 安全參數配置問題 365 切換成功率優化 37 理論介紹 37 指標定義 38 CDL信令流程 39 正常過程 39 優化方法介紹 40 切換信令流程 41 涉及話統打點 43 切換問題分類 45 相關案例介紹分析 48 硬件和傳輸故障 48 鄰區漏配問題 50 鄰區數據配置不當 52 切換算法參數配置不當 54 小區個性偏移參數調整案例 55 切換時終端接入到非源和目標小區導致核心網釋放用戶問題 57 鄰區移動網絡碼配置錯誤導致S1切換失敗 60 開啟防乒乓切換開關導致不切換 62 終端發A3切換測量報告后，不觸發異頻切換 666 無線掉線率優化 68 理論介紹 68 指標定義 71 CDL失敗原因 71 空口超時引起的掉話 71 激活檢測——UE不活動 78 激活檢測——UE丟失 78 其他錯誤引起的掉話 79 相關案例介紹分析 80 切換不及時問題 80 核心網問題 82 激活檢測UE不活動和UE丟失造成的掉線分析 85 幀頭未對齊導致的干擾問題 88前言話統KPI是中國移動考核項之一，也是對網絡質量的最直觀反映。日常話統監測是進行網絡性能檢測的一種有效手段。通過日監測，識別突發問題小區，將問題消除在初級階段。通過周監測，識別網絡性能持續短木板小區，針對性的進行提升優化。話統KPI主要包括以下幾大類：接入性指標、保持性指標、移動性指標、業務量指標、產品運行類指標、系統可用性指標和網絡資源利用率指標。通過上述重點話統KPI指標的監測，可以達到：識別突發問題、風險提前預警、話統KPI的穩定及提升，目前TD-LTE系統需要重點關注的話統KPI指標如下表：指標分類數據來源具體的KPI指標接入性指標無線側RRC連接建立成功率ERAB建立成功率無線接通率保持性指標無線掉話率（ERAB異常釋放）移動性指標小區eNodeB內切換出成功率小區eNodeB間切換出成功率業務量指標上、下行業務平均吞吐量量上、下行PRB平均利用率產品運行類指標無線側單板CPU最大占用率單板CPU平均占用率系統可用性指標無線側無線網絡退服比例網絡資源指標無線側上行PRB資源使用的平均個數下行PRB資源使用的平均個數KPI優化的工作流程及內容KPI優化工作總體流程KPI優化工作流程圖KPI優化工作內容KPI數據生成工作內容：使用預定義和自定義的統計項及模板生成KPI性能報表，通過OMCClient提取KPI報表，輸出KPI報表和重要指標失敗原因列表給KPI數據分析人員。KPI報表生成和提取相關操作請參考《LTEKPI模板指導手冊》。根據KPI報表數據，選擇KPI指標最差TopN小區。TOPN小區的選擇：對某項指標按照失敗率最高進行排序，選取前20個小區，再對這20個小區進行失敗次數分析，失敗次數大于20次的（RRC連接、切換、掉線等按失敗次數大于20次為標準，ERAB建立失敗指標按次數大于10次為標準）作為TOP小區進行分析

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

華電集團專項2小區接入率很低，且主要集中在15點到16點之間，查看小區無告警。由于接入失敗次數過多，影響全網一天的KPI指標數據。問題分析：從CDL信令看UE發起隨機接入申請，UE發出RRCConnectionRequest后ENB下發RRCconnectionsetup消息，終端無響應，造成RRC連接建立完成超時，導致RRC建立失敗。定位過程：從最近一次的測量上報消息中可以看出，源小區PCI為254，此時測量到的rsrpResult值為23，由此可以計算出RSRP的值為23-141=-118dbm左右。而測量到的相鄰目標小區PCI為62，rsrpResult值為34，小區RSRP在-107dbm左右。由此可以初步分析相關的場景是UE所處位置的信號質量不好，且存在模3干擾，最終導致RRC連接建立定時器超時后RRC連結建立失敗。解決建議：查看基站配置后，該小區的參考信號功率為15，已經為最大。故不存在下行初始發射功率偏低問題。通過現場復測抓取log進一步分析，排除天線安裝問題以及工參設置問題、排除存在大面積的弱覆蓋問題。通過log分析，發現存在PCI模三干擾嚴重，重新進行規劃，修改小區的PCI。解決效果：修改PCI后，RRC接入率有所提，KPI指標數據恢復正常。小區上行功控參數設置問題問題現象NBYZ技偵大樓FHTL-0從7月13日開始，RRC接入請求次數變多還有伴隨著大量失敗，每天RRC成功率基本在20%左右，失敗發生在忙時時段，影響全網KPI。問題分析：查看小區狀態以及通道駐波均沒有問題，從CDL中看：均是ENB下發RRCsetup之后終端無響應造成RRC連接超時，導致RRC接入失敗。查看基本上是UEID為1和3的用戶的失敗，但是查看最近的RSRP均較高。定位過程：查看小區的IOT以及小區狀態正常，對此小區進行核查，發現參數在非持續調度功率設置上出現問題，當此小區是-95，全網當時都已經改成-70，通過對全網此參數的核查，發現還有NBYZ理工學院2FHTL-2也是設置為-95，指標也很差。解決建議：效果：把小區的非持續調度功率從-95修改到-70以后指標明顯有提升：網元友好名時間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%小區測試開關參數問題問題現象：在月苑二試擴L-3小區下收不到該小區信號，無法接入該小區，導致該路段信號較弱，較大區域形成弱覆蓋。問題分析：測試車輛在月苑南路自西向東行駛至和墨香路交叉口區域，在交叉口區域該站下無法收到該小區信號，導致該路段覆蓋較差，嚴重影響下載速率，機房核查小區狀態正常，無告警情況。圖一在后臺對比核查參數發現，小區加載開關打開，且帶真實用戶的模擬快開關關閉，導致用戶終端無法接入。MAC測試開關里有小區加載開關和帶真實用戶的模擬加載開關，小區加載開關打開的話，帶真實用戶的模擬加載開關就會生效。當需要加擾測試時需要把小區加載開關打開，而此時如果帶真實用戶的模擬加載開關關閉，表示小區處于模擬用戶加載情況，真實用戶不能接入，如果帶真實用戶的模擬加載開關打開，表示是用真實用戶進行加載，則真實用戶可以接入。月苑二試擴小區正是由于小區處于模擬加載狀態，且關閉了帶真實用戶的模擬加載開關導致測試終端搜不到小區信號，無法正常接入；解決建議：關閉小區加載開關解決效果：關閉小區加載開關后，終端能正常搜到小區信號，且接入正常。如下圖：問題總結對于無法接入小區的問題，建議處理措施：核查小區狀態和告警以及硬件問題情況。核查是否由參數問題導致小區加載開關默認關閉，在現網中進行模擬加載等測試時，測試完成后需要對參數及時進行恢復。ＳＣＴＰ內存池耗盡導致信令發送失敗問題問題描述：南京F鼓樓四條巷專項L基站RRC接入失敗率很高，查看指標時段趨勢，在有業務的時段都有RRC接入失敗率較高的問題存在。實時查看小區無上行干擾，由于RRC接入失敗次數較多，影響全網全天的KPI指標數據。問題分析：從指標劣化趨勢看，在7點左右統計的RRC接入失敗次數最多，一個時段內高達22次的失敗。從CDL信令看，UE在不斷的在做TAU更新，RRC接入失敗時是由于在隨機接入過程中，UE上發RRCConnectionRequest,ENB回復RRCConnectionSetup但可能UE未收到，導致RRC接入超時，ENB側未收到RRCConnectionSetupComplete消息，具體CDL信令情況如下：通過NAS解碼可以得出此為TAU過程：定位過程：從mapinfo中，目標基站F鼓樓四條巷專項L所處位置屬于邊緣覆蓋，F鼓樓四條巷專項L-2和F鼓樓四條巷專項L-3小區覆蓋方向無其他小區銜接覆蓋。查看EXCEPTION日志，對應失敗的時間點事

6:50

7:11

7:34

7:40，每個時間點都對應下面兩條告警。未知的消息和定時器超時，從CDL中統計失敗原因都是收到RRC建立完成消息超時。通過分析日志，發現６：０４－－６：３４半小時之間沒有發送接收成功任何ＳＣＴＰ信令；存在很多信令發送失敗的情況，原因為ＳＣＴＰ內存池耗盡。查看７１號日志以及ＯＳＰ控制臺日志，和配置文件里，發現對端和21

同時配置為客戶端和服務器，導致了基站SCTP內存池耗盡，消息發不出去，造成RRC接入失敗。解決建議：由于對端IP：和IP:21

同時配置為客戶端和服務器，這個配置觸發了ＳＣＴＰ內存耗盡，導致ＳＣＴＰ信令發送失敗的現象，刪除并只保留對端和21

配置為客戶端和服務器的其中一條。升級新版本對此配置錯誤加保護，同時解決內存泄露的問題，以及增加對內存耗盡后的保護，來根本解決此問題的再次發生。全頻帶高干擾導致接入失敗問題干擾定義：在每個子幀輪詢一次后都會統計出在100個PRB中每個PRB的IOT值，當IOT值高于10的PRB個數大于等于3時為高IOT，查詢18次（早9:00到晚18:00每個小時一次數據，統計上行兩個時隙），如果同一個站點(包括3個小區)超過6次干擾判定為干擾小區，其中IOT超過20為干擾嚴重小區，IOT在10~20之間的為干擾普通小區；如同一個小區多于6次超過80個PRB的IOT大于15判定為全頻帶高干擾小區。問題描述：寧波城市元年-2小區無線接通率只有59.38%，從信令流程上看到的是存在大量基站收不到終端發上來的RRCConnectionSetupComplete消息：問題分析：檢查基站狀態正常，查看小區無相關原因告警，從指標趨勢看，平均分布在每個時段；從CDL信令看UE發起由于enb給UE發起RRCConnectionRequest后ENB下發RRCconnectionsetup消息，但未收到終端上發的RRCConnectionSetupComplete消息，造成RRC連接建立完成超時，導致RRC連接建立失敗。查詢上行低噪，發現較多的PRB都存在較高的IOT值。對小區的IOT進行監控，可以看到高干擾，并且鄰區并無大量用戶。解決效果：6月21日將城市元年-2小區PGC開關打開，該小區前后一周的KPI數據如下：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開關）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數據異常，在未打開PGC開關的情況下各項KPI指標都非常好，查看KPI原始數據確認是當天業務量太少：RAB建立成功率分母[單位:次]RAB建立成功率分子[單位:次]RRC連接建立成功率分母[單位:次]RRC連接建立成功率分子[單位:次]無線接通率1919643859.38%1010282485.71%1313282382.14%2726494282.54%5756888089.31%22221387957.25%4455100.00%6767787697.44%如上述表格數據說明，在打開PGC開關后，無線接通率有所提升。ERAB建立成功率理論介紹涉及話統打點圖1圖2如圖1或圖2中A點所示，當eNodeB收到來自MME的INITIALCONTEXTSETUPREQUEST或者E-RABSETUPREQUEST消息時統計該指標。如果INITIALCONTEXTSETUPREQUEST或者E-RABSETUPREQUEST消息中要求同時建立多個E-RAB，則相應指標根據業務的QCI按具體的E-RAB建立數目分別進行累加。如圖1或圖2中B點所示，當eNodeB向MME發送E-RABSETUPRESPONSE或者INITIALCONTEXTSETUPRESPONSE消息時統計該指標。如果E-RABSETUPRESPONSE或者INITIALCONTEXTSETUPRESPONSE消息中同時攜帶多個E-RAB的建立，則相應指標按各個業務的QCI分別進行累加。指標指標描述小區E-RAB嘗試建立總次數用戶嘗試發起E-RAB建立流程的總次數小區E-RAB建立成功總次數用戶發起E-RAB建立流程，建立成功的總次數小區E-RAB建立失敗原因核心網問題導致E-RAB建立失敗次數傳輸層問題導致E-RAB建立失敗次數無線層問題導致E-RAB建立失敗次數無線資源不足導致E-RAB建立失敗次數安全模式配置失敗導致ERAB建立失敗次數此外，話統還針對各QCI進行了ERAB嘗試建立次數和ERAB建立成功次數的統計。由于目前很少用到不同的QCI，業務基本以QCI＝6的業務為主，所以不需要關注具體的業務類別的ERAB統計。指標定義ERAB建立成功率＝小區E-RAB建立成功總次數/小區E-RAB嘗試建立總次數×100％小區無線接通率＝RRC建立成功率×ERAB建立成功率。CDL信令流程及失敗原因正常過程上下文建立過程基本流程上下文建立過程基本流程上下文建立流程是以S1InitialContextSetupRequest開始，此后所有的消息都可以提取相同的eNBUEID。S1InitialContextSetupResponse消息標志著上下文建立基本流程的結束。S1InitialContextSetupRequest消息的詳細解碼結果中，E-RABToBeSetupListCtxtSUReq里面的承載個數等于1時，意味著這次上下文建立過程只是建立默認承載；而當此值大于1時，則意味著這次上下文建立過程除了建立默認承載外還要建立專用承載。在S1InitialContextSetupResponse消息的詳細解碼結果中，E-RABSetupListCtxtSURes里面的承載個數代表建立成功的默認承載和專用承載數目，E-RABList里面的承載個數代表建立失敗的默認承載和專用承載數目。專用承載建立基本流程專用承載建立基本流程專用承載建立流程以S1ERABSetupRequest消息開始，此后所有的消息都可以提取相同的eNBUEID。S1ERABSetupResponse消息標志著專用承載建立基本流程的結束。異常過程上下文建立過程中等待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時，標志著上下文建立流程中傳輸錯誤。上下文建立過程中內部其他錯誤上下文建立過程中內部其他錯誤當看到S1InitialContextSetupFailure消息并且其詳細解碼中的valueCause字段不為failure-in-radio-interface-procedure、transport-resource-unavailable和encryption-and-or-integrity-protection-algorithms-not-supported時，標志著上下文建立流程中內部其他錯誤。專用承載建立過程中等待RRC重配完成超時專用承載建立過程中等待RRC重配完成超時當看到RRCConnectionReconfiguration和S1UEContextReleaseRequest消息并且最后一條消息的valueCause字段的值為failure-in-radio-interface-procedure時，標志著專用承載建立流程中空口重配置消息超時。相關案例介紹分析路由關系未配無法接入的問題問題描述：

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

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

對應的是，通過核查確認核心網側的SGWIP確定是。對enb側的路由設置進行檢查，S1鏈路斷鏈恢復后，該基站的路由中包含的路由。基站的IP地址:45不在同一個網段內，檢查原始規劃數據，發現和規劃數據不一致，所以導致了終端由于傳輸錯誤而上下文建立失敗。解決效果：現場修改網關IP地址后，終端成功附著，業務正常。安全參數配置問題問題描述：福州移動使用三星S4終端無法附著，查看CDL，失敗原因是“SecurityModeFailure”。問題分析：1、查看目前基站安全開關為關閉，當此開關關閉時，基站默認選擇空算法EIA0進行完保。（協議規定安全開關關閉時，ENB默認一種算法進行完保，大唐目前默認空算法EIA0）查看安全開關節點：LMT-全局參數配置-全局測試開關-HL全局測試開關2、通過WIRESHARK抓包，終端上報的能力中，不支持空算法EIA0，所以終端接入時，基站使用默認空算法，導致終端安全模式失敗。定位結果：打開安全開關，基站根據配置算法的優先級和終端支持的算法來選擇對應適合的，即可保證終端完保通過。解決建議：按信令流程分析，當安全失敗時，一般都是基站設置的算法終端部支持，所以首先查看安全開關是否關閉，如果關閉則打開。安全開關打開后，如果終端不支持第一優先級算法，則會根據算法優先級一一選擇。解決效果：打開安全開關后，三星S4終端能夠成功附著。切換成功率優化理論介紹切換成功率是移動保持類的重要指標之一，按照涉及的網元關系可以分為ENB內切換成功成功率、ENB間（包括X2切換和S1切換）切換成功率。切換成功率的高低，直接影響用戶感受，是運營商重點考核的KPI指標之一。指標定義切換（Handover）是移動通信系統的一個非常重要的功能。作為無線鏈路控制的一種手段，切換能夠使用戶在穿越不同的小區時保持連續的通話。切換成功率是指所有原因引起的切換成功次數及所有原因引起的切換請求次數的比值。切換主要的目的是保障通話的連續，提高通話質量，減小網內越區干擾，為UE用戶提供更好的服務。切換成功率主要通過話務統計結果獲得，推薦的公式為：ENB間切換成功率=(ENB間S1切換出成功次數+ENB間X2切換出成功次數)/(ENB間S1切換出執行請求次數+ENB間X2切換出執行請求次數)ENB內切換成功率=eNB內切換出成功次數/eNB內切換出請求次數*100%1）ENB間切換相關的指標描述如下：指標指標描述小區eNodeB間切換出嘗試次數小區eNodeB間切換出嘗試次數小區eNodeB間切換出成功次數小區eNodeB間切換出成功次數小區切換出失敗次數核心網原因導致切換出準備失敗次數目標小區無響應導致切換出準備失敗次數目標小區回復切換準備失敗消息導致切換出準備失敗次數源小區接收到測量報告后不觸發切換請求指示導致切換失敗次數源小區發送切換取消導致切換出失敗次數2）ENB內切換相關的指標描述如下：指標ID指標描述小區eNodeB內切換出嘗試次數小區eNodeB內切換出嘗試次數小區eNodeB內切換出成功次數小區eNodeB內切換出成功次數小區切換出失敗次數目標小區無響應導致切換出準備失敗次數目標小區回復切換準備失敗消息導致切換出準備失敗次數源小區接收到測量報告后不觸發切換命令導致切換失敗次數源小區發送切換取消導致切換出失敗次數CDL信令流程正常過程總體流程圖：X2切換源側正常流程：UU接口MeasurementReport消息代表UE測量上報流程的開始，也就是X2切換源側流程的第1條消息。第2、3條消息為X2接口的X2HandoverRequest和X2HandoverRequestAcknowledge消息，注意對于X2切換源側來講，第2條消息為發送，第3條消息為接收。第4條消息是UU接口的RRCConnectionReconfiguration，注意在這條消息asn解碼后的內容中，必須存在mobilityControlInfo字段。X2切換目標側正常流程：每當在CDLlog中發現一條接收方向的X2接口X2HandoverRequest消息時，代表X2切換目標側流程的開始。第2條消息為X2接口的X2HandoverRequestAcknowledge，注意這兩條消息對于X2切換目標側來講，分別為接收、發送。第3、4、5、6條消息分別為UU接口的RRCConnectionReconfigurationComplete、S1接口的S1PathSwitchRequest消息和S1PathSwitchRequestAcknowledge消息以及X2接口的X2UEContextRelease消息。優化方法介紹LTE系統內所有切換問題最終都可以歸納為ENB間的小區間切換和ENB內的小區間切換等。根據現網處理該問題的案例和現網實施的經驗，影切換問題的可能原因大概分為如下幾條：硬件傳輸故障（載頻壞、合路天饋問題）；數據配置不合理；擁塞問題；時鐘問題；干擾問題；覆蓋問題及上下行不平衡；當出現切換成功率低的問題時，首先按照切換問題分類，了解切換問題的范圍，然后根據硬件、數據配置、擁塞、時鐘、干擾、覆蓋等方面入手逐一排查解決，排除這些影響切換成功率的客觀因素，然后根據自動鄰區優化提升切換成功率。切換信令流程1．基站內小區間切換信令流程，如圖1所示：圖1：基站內小區間切換信令流程2．基站間S1切換測試流程，如圖2所示：圖2：S1切換源基站側信令流程3．基站間X2切換測試流程，如圖3所示：圖3：X2切換目標基站側信令流程涉及話統打點小區eNodeB內同頻切換出嘗試次數：如圖中A點所示，在eNodeB內切換過程中，當小區接收到UE的MeasurementReport消息后，切換判決要進行eNodeB內切換時，上述測量指標加1。各指標的具體統計方式如下所示：源小區和目標小區頻點相同，指標L.HHO.IntraeNB.IntraFreq.PrepAttOut加1。小區eNodeB內同頻切換出成功次數：圖1圖2如圖1中C點所示，在eNodeB內切換過程中，當eNodeB目標小區收到UE返回的RRCConnectionReconfigurationComplete消息后，等待切換過程中的緩存數據轉發完成時統計相應指標，如果切換過程中源小區和目標小區頻點相同，指標L.HHO.IntraeNB.IntraFreq.ExecSuccOut加1；或者如圖2中C點所示，在eNodeB內切換過程中，當eNodeB目標小區收到UE返回的RRCConnectionReestablishmentComplete消息時，如果切換過程中源小區和目標小區頻點相同，指標L.HHO.IntraeNB.IntraFreq.ExecSuccOut加1。切換問題分類切換分類需要在分析切換成功率問題之前確定如下幾方面內容：首先，通過話統分析確定切換失敗的范圍，如果是所有小區切換成功率低，要從切換特性參數、硬件傳輸、系統時鐘來檢查問題；其次，其他情況則過濾得出TOPN最差小區，針對小區按照如下的步驟進行排查問題。第三，查詢切換性能測量中的出小區切換和入小區切換成功率，來分析是切出失敗還是切入失敗。再分析問題小區的出小區和入小區切換性能測量，從出小區性能測量中找出是往哪些小區切換失敗，分析所有這些切入失敗的小區“入小區切換失敗次數（由于擁塞）”和“話務量（業務信道）”和“擁塞率”，確認是否目標小區擁塞導致切換失敗。（1）硬件和傳輸故障硬件故障的現象表現為：告警系統上報相應的告警信息。首先要排除這些硬件故障告警，若硬件故障告警恢復，則查看話務統計信息和分析切換指標。硬件故障的情形如下：ENB傳輸管理單元；ENB載頻故障；ENB天饋故障；處理過程：檢查硬件數據配置，如果出現故障的小區及其相鄰小區的數據配置在近期沒有修改，突然出現切換問題，則應首先考慮是否ENB硬件故障造成。若該ENB下只有一個小區出現切換問題，則考慮是否由該小區本身的硬件故障造成，如部分載頻損壞，引起呼叫切換到該載頻時失敗。對于上述問題，可以采用閉塞部分載頻的方式來驗證。若閉塞某個載頻后，切換成功率恢復正常，則可以查看是否該載頻故障，或及該載頻相關的BBU或天饋故障。若某載頻的上下行信號嚴重不平衡，則會經常造成切換問題，如頻繁切換、切換成功率下降等。（2）數據配置不當數據配置不當導致的故障現象表現為：UE不發起切換或過多的發起切換，從而影響切換成功率。由于切換判決算法受切換參數的控制，如果切換參數配置不當，可能導致MS不發起切換或過多的發起切換，此時可從以下方面來考慮：數據配置中的切換門限設置是否合理避免因切換門限設置過大導致難切換現象，或設置過小導致頻繁切換現象，設置合理的切換保證不發生乒乓切換，各門限的設置參考《LTE無線網絡和業務參數標定手冊》,一般不要出現大幅偏離基線值的情況。數據配置中的切換候選小區參數設置是否合理；避免因鄰區漏配導致UE無法切換到該鄰區；數據配置中的切換遲滯設置是否合理；避免因切換遲滯設置過大導致難切換現象，或設置過小導致頻繁切換現象；當切換發生異常時，需要快速檢查一下切換定時器，保證切換定時器不低于設定的默認值。（3）目標小區擁塞目標小區擁塞的故障現象表現為：UE發起切換請求后申請不到信道而切換失敗。導致小區擁塞的原因如下：小區下用戶數目激增，超過設計用戶數；網優參數設置不當，導致小區吸收了過多用戶；切換參數設置不當，導致切入小區的用戶數增多；當目標小區出現擁塞導致切換失敗后，為避免UE試圖再次切換到此目標小區，應對目標小區進行懲罰。建議將“懲罰處理允許”設為“是”。查看擁塞小區信道狀態是否正常，如果載頻故障或信道狀態異常，首先排除相關故障。（4）時鐘問題時鐘不同步、時鐘不穩是引起切換掉話的重要原因，應注意保持基站時鐘穩定，否則會因為時鐘不穩，引起切換失敗以及掉話過多。時鐘參考源異常，基站時鐘及其他基站時鐘之間可能出現偏差，導致UE在切換時可能出現異常。解決時鐘失鎖以及參考源異常問題，首先需要檢查告警：首先檢查是否存在時鐘相關告警，如果存在，則根據告警處理手冊進行處理，然后觀察切換成功率。（5）干擾問題網絡存在較大的干擾，容易引起接收質量下降，導致干擾切換或者質差切換增多，從一定程度上降低了現網的服務質量，影響用戶的感受，甚至一定程度上影響切換成功率。干擾問題主要通過路測發現現網存在的干擾大的小區或者頻點，然后通過調整天饋傾角，更換頻點，調整發射功率和小區覆蓋范圍等常規的RF優化手段解決。也可以通過輔助手段，登記干擾帶測量，來估計下行的干擾情況。（6）覆蓋問題及上下行平衡信號覆蓋問題的現象表現為：切換成功率低、用戶直觀感受差。信號覆蓋問題主要存在三類，一類是越區覆蓋，由于邊緣門限設置過低，基站功率過大，傾角不合適導致越區覆蓋，形成同頻干擾，影響切換成功率；一類是孤島效應引起的切換成功率低，如服務小區的覆蓋遠遠超過其鄰區，且未及其鄰區的鄰區配置相鄰關系，這種情況容易在服務小區的邊緣發生切換失敗；弱覆蓋形成的覆蓋漏洞。信號覆蓋問題主要通過網優的路測報告發現現網的覆蓋問題，通過RF優化解決。相關案例介紹分析硬件和傳輸故障問題描述：5月27日，蔣王廟試擴L329138,00蔣王廟試擴L-2_2站內切換指標如下：服務小區名稱服務小區IDeNodeB內切換出成功次數eNodeB內切換出嘗試次數eNodeB內切換出失敗次數ENODE內切換成功率蔣王廟試擴L329138,00蔣王廟試擴L-2_2329138911281.82%32913856183.33%32913856183.33%32913846266.67%從KPI的統計表中可以看出，基站內切換成功率在一段集中的時間內較差，而之前的時間段ENB內切換成功率均為100%。問題分析：根據下圖上午MR計算出目標小區的RSRP為-90dBm，覆蓋良好。排查基站告警，在查詢基站告警日志發現在該時間段存在小區退服,傳輸故障，X2鏈路故障的告警。如果由于小區重復退服，可能導致站內切換成功率下降。告警名稱告警級別告警源網元類型產生時間小區退服,傳輸故障主要蔣王廟試擴L329138,小區2ENB2013-05-2720:38:16X2鏈路故障次要蔣王廟試擴L329138,SCTP鏈路2ENB2013-05-2720:02:05小區退服,傳輸故障主要蔣王廟試擴L329138,小區2ENB2013-05-2719:28:36問題解決：安排基站人員上站排查，重現建立X2鏈路后告警消除。解決效果：28日現場排除告警后提取當日指標進行驗證。下表為蔣王廟28日全天級指標，已有明顯提升。服務小區名稱服務小區IDeNodeB內切換出成功次數eNodeB內切換出嘗試次數eNodeB內切換出失敗次數ENODE內切換成功率蔣王廟試擴L329138329138261264398.86%鄰區漏配問題問題描述：

5月27日，新伊汽配商城搬遷試擴L3小區掉線率很高，查看指標時段趨勢，在有業務的時段都有掉線率較高的問題存在，查看小區無告警。實時查看小區無上行干擾，由于掉線次數較多，影響全網全天的KPI指標數據。問題分析：從CDL信令看，在2013-5-278:48:33時刻，UE發送3次測量報告后，enb沒有后續消息處理，UE無線環境質量繼續惡化，導致后續切換失敗，最終造成掉線。定位過程：從mapinfo中，查看目標小區櫻陀村試擴L1小區屬于源小區新伊汽配商城搬遷試擴L3小區的二層對打小區。從CDL信令中的MeasurementReport可以發現，在8:48:22時發了一次測量報告，測量報告中可以得出服務小區新伊汽配商城搬遷試擴L3小區PCI174的RSRP值為-83dBm，臨小區櫻陀村試擴L1小區PCI332的RSRP值為-77dBm。此時已經滿足切換條件，但未能完成切換。最終10秒后，UE無線環境質量開始惡化，ENB發起無線鏈路釋放，發生掉線。解決建議：首先對該小區的測量、鄰區配置、切換算法等相關參數進行檢查和優化處理；該小區臨區關系中未添加櫻陀村試擴L1小區。目標小區櫻陀村試擴L1小區屬于源小區新伊汽配商城搬遷試擴L3小區的二層對打小區。但距離較遠，要判斷櫻陀村試擴L1小區和新伊汽配商城搬遷試擴L3小區是否存在越區覆蓋問題，建議確認并控制櫻陀村試擴L1小區和新伊汽配商城搬遷試擴L3小區的覆蓋范圍。臨時規避辦法：添加對打小區櫻陀村試擴L1和新伊汽配商城搬遷試擴L3的雙鄰區關系，避免漏配鄰區導致的掉線問題。解決效果：添加鄰區后，目前新伊汽配商城搬遷試擴L3小區Kpi正常，掉線現象減少。鄰區數據配置不當問題描述：2012年4月20日測試發現NBHS維科上院FHTL-1PCI=487及NBHS青林灣西FHTL-0PCI=438之間切換失敗次數較多。從前臺測試LOG可以看出，占用NBHS維科上院FHTL-1PCI=487上報MR，目標小區NBHS青林灣西FHTL-0PCI=438，沒有響應，.42秒后上報第2個MR。問題分析：信令跟蹤的情況：第一個MR沒有反饋：第二個MR，啟動切換，但是切換準備失敗，反饋傳輸資源不足造成，最后還是完成切換，前臺測試切換至NBHS錦江年華FHTL-2PCI=320非NBHS青林灣西FHTL-0PCI=438。首先核查鄰區是否添加及添加正確性，根據LMT外部鄰區關系配置方法：除了小區測量-鄰小區關系；還有外部鄰小區-Eutran鄰小區；局向-鄰基站，這三個地方都要注意；另外對于鄰區關系配后SCTP鏈路是否成功建立，也需要關注；目前外場遇到的情況，排除空口無線環境，切換參數配置不合理，終端等原因后，一般問題都出在這里！發現NBHS維科上院FHTL-1PCI=487及NBHS青林灣西FHTL-0PCI=438兩個小區之間存在鄰區關系，但是查看配置文件，發現青林灣西鄰基站中未配置維科上院的鄰基站信息（200914及200894）。切換算法參數配置不當問題描述：寧波KPI分析發現華東物資城-1小區和世紀商務-1小區切換失敗次數較多。問題分析：通過分析CDL發現，切換失敗原因主要為切換源側切換準備階段超時。華東物資城-1小區PCI為307，世紀商務-1小區PCI為416，不存在模式3干擾的情況。在切換發生本小區及目標小區信道環境比較差，源小區RSRP為-115dbm，目標小區RSRP為-110dbm，顯然有些過晚切換。查看CDL日志，發現之前信號較好的時候上報了MR沒有切換，查看UE來源，確認是發生了乒乓切換，剛剛從PCI=415小區切換入PCI=307小區后，又往回切。但兵乓切換檢測開關限制他的回切時間，導致切換過晚，失敗較多。解決建議：經過評估及分析，當前乒乓切換的時間門限配置為5s，門限過長，為了減少乒乓切換抑制對切換造成的影響，建議將乒乓切換的時間門限由5s改為3s。解決效果：通過把乒乓切換的時間門限配置為3s，經觀察華東物資城-1小區的指標有明顯提升，切換率大大得到提高，也不再是TOP小區。小區個性偏移參數調整案例問題描述：紅色框內問題路段占用NBHS培羅成大樓FHTL-0小區，占用該小區后SINR差。問題分析：問題路段主覆蓋小區應為NBHS交郵樓-0（PCI：114）小區，但實際在該問題路段經常由NBHS交郵樓-0（PCI：114）小區切換到NBHS培羅成大樓-0（PCI：135）小區，兩小區在問題路段RSRP相差不大，切過去占用NBHS培羅成大樓-0（PCI：135）小區后SINR很差，且兩小區存在模3干擾，嘗試將NBHS培羅成大樓-0（PCI：135）小區功率降低，但依然會切換到該小區，解決建議：問題路段存在模3干擾，且周邊道路都沒占用NBHS培羅成大樓-0（PCI：135）小區，我們將該小區信號參考功率降到-15，加NBHS交郵樓-0（PCI：114）小區到NBHS培羅成大樓-0（PCI：135）小區個性偏移-5（加到NBHS交郵樓-0抑制向NBHS培羅成大樓-0小區切換）解決效果：通過調整小區功率，又修改小區個性偏移參數，問題路段不再占用NBHS培羅成大樓-0（PCI：135）小區，而是由主覆蓋小區來覆蓋，SINR明顯改善。切換時終端接入到非源和目標小區導致核心網釋放用戶問題問題描述：寧波LTE小區，KPI分析五金批發-2的CDL日志，切換失敗統計為核心網釋放，原因為normalrelease；問題分析：LTE終端切換流程：UE占用五金批發FHTL-2_302小區由東向西進入江東城建FHTL-0_21切換失敗如下圖：通過CDL信令分析，源小區測收到EPC下發的S1UEContextReleaseCommand；目標測也沒有收到重配置完成的消息；失敗原因值：normalrelease；查看終端側LOG，發現終端并沒有收到切換的重配置消息，在源小區的信號降低到一定程度的時候失步。然后UE發起了重建立請求重建到第三個小區姚隘路FHTL-0_336,由于UE重新接入了新的小區，所以核心網釋放了源小區的UEContext。從姚隘路FHTL-0側的CDL日志可以看出，基站只收到了單獨的一條重建立消息，并沒有該UE的上下文消息，所以重建立被拒絕。解決建議：根據測試結果，發現在切換失敗的位置下行的干擾比較嚴重，該處存在4個主覆蓋小區RSRP相差在6dB以內，且存在鄰小區PCI模3相等：針對該處問題做了如下的優化：

（1）江東城建FHTL-0_21和江東城建FHTL-1_22兩個小區的PCI對調；

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

（3）錦達賓館FHTL-0_93小區功率調到12；

（4）體育館FHTL-2_277小區功率調整到6；調整前測試40次失敗4次，調整后測試40次失敗0次。解決效果：通過以上的修改，經觀察五金批發-2小區的指標有明顯提升，切換率得到提高。效果如圖：鄰區移動網絡碼配置錯誤導致S1切換失敗問題描述：9月26日，10點至11點佛手湖試擴L-1通過S1切換至頂山食品廠請求了13次，且全部切換失敗。查看小區無告警。查詢小區無上行干擾，由于S1切換失敗次數較多，影響全網的S1切換成功率占比。問題分析：從CDL信令看，在2013-9-2610:10:49時刻，UE在佛手湖試擴L-1主服務下上發MeasurementReport，堯勝村東試擴L-1發出S1HandoverRequire，EPC回復S1HandoverPreparationFailure，原因值為：unknown-targetID。通過CDL切換統計功能，發現S1切換失敗的目標基站都是329277，可以初步判斷出是佛手湖試擴L-1到目標基站329277（頂山食品廠）的小區的切換出現問題。從mapinfo中，目標基站頂山食品廠試擴L屬于佛手湖試擴L-1小區正打方向覆蓋銜接基站，首先核查源基站小區和目標基站狀態均正常，且無上行干擾和告警故障等。其次核查佛手湖試擴L-1小區和頂山食品廠試擴L存在鄰區關系，且X2鏈路配置正常。通過佛手站告警信息可以知道是由于存在X2連接的狀態下沒有查到鄰基站信息。但是根據佛手站的配置文件，存在329277站的基站信息。如圖，鄰基站移動網絡碼是00，但是外部鄰區和鄰小區關系中都為08。錯誤的mcc和mnc會導致獲取鄰基站信息失敗。所以S1切換失敗，根據切換準備失敗的原因，是EPC沒有對端基站信息。解決建議：刪除配置錯誤的鄰區關系，重新添加，修改鄰區中的移動網絡碼由08→00解決效果：鄰區重新調整后，可以進行正常的X2切換，且切換成功。開啟防乒乓切換開關導致不切換問題描述： 9月21日下午福州LTE簇13摸底測試過程中，由閩侯上街金橋物業_2(PCI:208)往閩侯上街_1（PCI:234）切換成功，在目標小區駐留約2秒后，由于拐角RSRP波動，滿足A3事件觸發條件，UE上報A3事件的MR后，未收到ENB下發的帶有MobilityControlInfo信息的RRCConnectionReconfiguration消息，無法完成切換最終導致UE發起小區重選，業務中斷。問題分析： 目前福州項目LTE同頻采用A3事件作為切換依據，按切換必須進行的三步（測量、判斷、執行），參照以下簡易空口切換流程逐步進行分析。否否是否下發A3測量控制是否上報A3測量報告是否收到RRC重配消息請求切換是是否否否是是否上發RRC重配完成消息切換算法未開啟、A3測量未配置無滿足條件的合適小區、A3測量條件過于苛刻鄰區漏配或錯配、基站故障、上行干擾導致基站未收到MR、開啟乒乓切換算法UE不支持或其他問題 從信令可以看出UE已經上報A3事件MR，但是未收到ENB下發的RRC重配消息切換請求。 首先檢查是否鄰區漏配或錯配，通過查看閩侯上街_1的測量控制消息（攜帶measConfig信息的RRCConnectionReconfiguration消息）中第7個同頻測量小區即為PCI:234，同時核查外部鄰區參數、X2鏈路配置確認鄰區相關參數配置無誤。 后臺登錄LMT檢查源基站和目標基站都無告警，提取該時段源基站(閩侯上街_1（PCI:234）)CDL日志，分析X2和S1口信令，可以看到上一次由閩侯上街金橋物業_2(PCI:208)切換到閩侯上街_1（PCI:234）成功后，基站測已經收到UE上報的MR，且及UE測上報的MR一致，但是并未下發RRC重配消息請求切換，至此基本能排除上行干擾導致基站無法收到或正確解析MR。 查看基站RRM接口消息，發現有RRM判斷測量報告處理結果為失敗（RRM_HC_MEAS_HDLFAILURE）,即基站判決未通過，而正常的切換流程RRM判斷通過后會有RRM_HC_MEAS_HDLSUCCESS，然后CPM層再給RAC層發送切換請求，切換才得以繼續進行。 最后檢查閩侯上街_1的切換算法配置(小區>小區算法>切換)如下，防用戶乒乓切換開關為打開，用于判斷乒乓切換的目標小區停留時間門限為5秒，即如果由A小區切后B小區后，5秒內如果UE上報MR中為A小區，基站判斷此次切換為乒乓切換，而導致切換判決不通過，空口直觀表現為上報MR但無法切換，或切換過慢。解決措施： 乒乓切換對速率、掉線率和信令負荷都會有一定影響，應當盡量避免發生乒乓切換。抑制乒乓切換有效的方法有： >控制好覆蓋，合理設置切換帶； >適當調整A3參數（遲滯、偏移值、觸發時延），以及CIO； >合理應用防乒乓切換算法。 而實際的某些優化場景中，必須要發生乒乓切換才能保證業務連續性。針對類似場景從用戶感知出發，可以考慮關閉防乒乓切換算法，或降低乒乓切換判斷時間以允許乒乓切換。處理效果 結合現場無線環境，RF調整無法有效的控制該拐角處主覆蓋，選擇關閉防乒乓切換算法，調整后現場復測，UE由閩侯上街金橋物業_2(PCI:208)往閩侯上街_1（PCI:234）切換成功，駐留3秒后，上報MR，基站下發RRC重配消息請求切換，最終切換完成，業務未中斷。終端發A3切換測量報告后，不觸發異頻切換問題描述：云南師大商學院動感廳室分站點，為E頻段小區（基站ID=5513）往師大商學院站點，為F頻段小區（基站ID=2129）能夠成功切換，但反之，師大商學院往學院動感廳室分小區無法完成切換。問題分析：通過提取師大商學院宏基站F頻段小區的CDL日志分析，源小區收到了終端上報的測量報告，測量報告中也上報了PCI=1（學院動感廳室分）E頻段小區。如下圖：但根據終端上報的測量報告中的MeasId，對應測量的RRC重配置消息來看，終端上報的測量報告標識不是切換的A3測量。而是用于小區干擾協調算法的A3測量，所以不會觸發切換。消息如下圖：通過對比檢查宏站的基站配置文件，發現異頻載波信息中“小區重選頻點優先級”配置的是1，而小區重選公共參數中“小區重選優先級”配置的是3；目前我們基站的異頻切換是基于A2+A3算法，A3為相同頻率優先級的切換算法，如果外場要觸發A3的異頻測量，這兩個優先級必須配置相同。解決建議：現場將參數配置進行修改，把宏基站的“小區重選優先級”設置相同，問題得到解決。無線掉線率優化理論介紹ERAB異常釋放：圖1圖2如圖1中A點所示，當eNodeB向MME發送E-RABRELEASEINDICATION消息，當相應承載有數傳且釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“csfallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATredirection”時統計該指標，并且在MME回復E-RABRELEASECOMMAND消息時，該指標不會被重復記錄，如果E-RABRELEASEINDICATION消息中要求同時釋放多個E-RAB，則相應指標按各個業務的QCI分別進行累加；如圖2中A點所示，當eNodeB向MME發送UECONTEXTRELEASEREQUEST消息，會釋放UE的所有E-RAB。當有數傳且釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“csfallbacktriggered”，“UENotAvailableForPSService”，“Inter-RATredirection”時統計該指標，相應指標按各個業務的QCI分別進行累加。并且在MME回復UECONTEXTRELEASECOMMAND消息時，該指標不會被重復記錄。ERAB正常釋放次數：圖1圖2如圖1中A點所示，當eNodeB收到來自MME的E-RABRELEASECOMMAND消息時統計該指標，如果是MME主動發起的釋放，根據不同QCI統計對應指標；如果是eNodeB主動發起的釋放，當釋放原因為“NormalRelease”，“Detach”，“UserInact