LTE質差小區處理指導書TIME\@"yyyy-M-d"2022-11-25第頁目錄1. 概述 42. LTE主要KPI介紹 42.1. 呼叫接入類指標 42.1.1. RRC建立成功率 42.1.2. E-RAB建立成功率 52.2. 呼叫保持類指標 62.2.1. LTE業務掉話率 62.2.2. UE上下文掉線率 92.3. 移動管理類指標 102.3.1. eNodeB內切換成功率 122.3.2. eNodeB間切換成功率 142.3.3. S1接口切換成功率 162.3.4. X2接口切換成功率 172.3.5. 系統內切換成功率 182.3.6. 同頻切換成功率 182.3.7. 異頻切換成功率 192.4. 業務完整類指標 192.4.1. 上行PDCPSDU丟包率 192.4.2. 下行PDCPSDU丟包率 192.5. 資源負荷類指標 192.5.1. 上行PRB平均利用率 192.5.2. 下行PRB平均利用率 193. 華為LTE主要KPI優化方法及案例 203.1. 呼叫接入類指標優化方法 203.1.1. 處理步驟 203.1.2. 呼叫接入類優化案例 213.2. 呼叫保持類指標優化方法 223.2.1. 處理步驟 233.2.2. 呼叫保持類優化案例 233.3. 移動管理類指標優化方法 253.3.1. 處理步驟 263.3.2. 移動管理類優化案例 264. 愛立信LTE主要KPI優化方法及案例 284.1. 接入類指標優化方法 284.1.1. 告警核查 284.1.2. 干擾核查 304.1.3. 準入控制分析 334.1.4. 檢查弱覆蓋 344.1.5. 接入類問題優化案例 344.2. 呼叫保持類指標優化方法 364.2.1. 分析流程 364.2.2. 弱覆蓋 384.2.3. 上行高干擾 384.2.4. PCI模3干擾 404.2.5. 傳輸故障 404.2.6. eNodB問題 404.2.7. 切換引起掉話 414.2.8. 檢查MME是否存在告警 424.3. 移動管理類指標優化方法 424.3.1. LTE切換異常現象 424.3.2. 切換問題分析流程 434.3.3. 切換主要問題 44概述本文根據成都聯通LTE網絡的差小區分析，結合LTE的KPI的基本原理，歸納總結接呼叫接入類指標，呼叫保持類指標，移動管理類指標，業務完整類指標，資源負荷類指標等5類主要的LTE指標差小區的問題及分析流程及案例。LTE主要KPI介紹呼叫接入類指標接入過程是手機開始與網絡連接的初始過程，主要包括隨機接入，RRC連接的建立，以及各種ERAB承載連接的建立。接入型對后續的保持性和移動性指標都有著重要的意義，同時接入性又直接影響用戶的感知度，因此優化接入性指標對與改善用戶感知度，提高保持性和移動性都有具體的重要意義。RRC建立成功率定義：RRC建立成功率=[RRC連接建立完成次數]/[RRC連接請求次數]*100%；圖1RRC連接請求次數（不包括重發）定義：如圖1中A點所示，當小區接收到UE發送的RRCConnectionRequest消息時，統計對應指標；RRC連接建立完成次數定義：如圖1中C點所示，當小區接收到UE返回的RRCConnectionSetupComplete消息時，統計對應指標。E-RAB建立成功率定義：E-RAB建立成功率=[E-RAB建立成功總次數]/[E-RAB建立嘗試總次數]*100%；圖2圖3E-RAB建立嘗試總次數定義：如圖2或圖3中A點所示，當eNodeB收到來自MME的INITIALCONTEXTSETUPREQUEST或者E-RABSETUPREQUEST消息時根據不同QCI類型統計該指標。如果INITIALCONTEXTSETUPREQUEST或者E-RABSETUPREQUEST消息中要求同時建立多個E-RAB，則相應指標根據業務的QCI按具體的E-RAB建立數目分別進行累加，同時，根據消息要求建立的E-RAB個數對E-RAB建立嘗試總次數進行累加，即指標L.E-RAB.AttEst累加。E-RAB建立成功總次數定義：如圖2或圖3中B點所示，當eNodeB向MME發送E-RABSETUPRESPONSE或者INITIALCONTEXTSETUPRESPONSE消息時根據不同QCI類型統計該指標。如果E-RABSETUPRESPONSE或者INITIALCONTEXTSETUPRESPONSE消息中同時攜帶多個E-RAB的建立成功結果，則相應指標按各個業務的QCI分別進行累加。同時，根據消息中攜帶的E-RAB建立成功個數，對E-RAB建立成功總次數進行累加，即指標L.E-RAB.SuccEst累加。呼叫保持類指標LTE業務掉話率定義：LTE業務掉話率=[E-RAB異常釋放總次數]/([E-RAB異常釋放總次數]+[E-RAB正常釋放總次數])*100%；圖4E-RAB異常釋放總次數定義：如圖4中A點所示，當eNodeB向MME發送E-RABRELEASEINDICATION消息，當釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，“SuccessfulHandover”時根據不同QCI類型統計指標L.E-RAB.AbnormRel.eNBTot.QCI.1~L.E-RAB.AbnormRel.eNBTot.QCI.9，當判斷相應承載有數傳時統計指標L.E-RAB.AbnormRel.QCI.1~L.E-RAB.AbnormRel.QCI.9。如果E-RABRELEASEINDICATION消息中要求同時釋放多個E-RAB，則相應指標按各個業務的QCI分別進行累加；如圖4中A點所示，當eNodeB向MME發送UECONTEXTRELEASEREQUEST消息，會釋放UE的所有E-RAB。當釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，“TimeCriticalHandover”，“HandoverCancelled”時根據不同QCI類型統計指標L.E-RAB.AbnormRel.eNBTot.QCI.1~L.E-RAB.AbnormRel.eNBTot.QCI.9，當判斷相應承載有數傳時統計L.E-RAB.AbnormRel.QCI.1~L.E-RAB.AbnormRel.QCI.9指標。如果被釋放用戶建立了多個E-RAB，則相應的指標統計多次。并且在MME回復UECONTEXTRELEASECOMMAND消息時，相應指標不會被重復記錄。圖5E-RAB正常釋放總次數定義：如圖5中A點所示，eNodeB主動發起的釋放，當eNodeB向MME發送E-RABRELEASEINDICATION消息時，如果釋放原因為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，或者判斷相應承載無數傳時，根據不同QCI統計相應指標。如果E-RABRELEASEINDICATION消息中要求同時釋放多個E-RAB，則相應指標按各個業務的QCI分別進行累加。同時，根據消息中攜帶的E-RAB個數對eNodeB正常釋放E-RAB的總次數進行累加，即指標L.E-RAB.NormRel累加。如圖5中A點所示，MME主動發起的釋放，當eNodeB收到來自MME的E-RABRELEASECOMMAND消息時，根據不同QCI統計相應指標。如果E-RABRELEASECOMMAND消息中要求同時釋放多個E-RAB，則相應指標按各個業務的QCI分別進行累加。同時，根據消息中攜帶的E-RAB個數對eNodeB正常釋放E-RAB的總次數進行累加，即指標L.E-RAB.NormRel累加。如圖5中A點所示，eNodeB主動發起的釋放，當eNodeB向MME發送UECONTEXTRELEASEREQEUST消息時，會釋放UE的所有E-RAB。如果釋放原因為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，“TimeCriticalHandover”，“HandoverCancelled”，或者判斷相應承載無數傳時，根據不同QCI統計相應指標。同時，根據消息中攜帶的E-RAB個數對eNodeB正常釋放E-RAB的總次數進行累加，即指標L.E-RAB.NormRel累加。并且在MME回復UECONTEXTRELEASECOMMAND消息時，相應指標不會被重復記錄。如圖5中B點所示，MME主動發起的釋放，當eNodeB收到來自MME的UECONTEXTRELEASECOMMAND消息時，會釋放UE的所有E-RAB，如果釋放原因不是切換類原因值，包括“SuccessfulHandover”，“PartialHandover”，“S1intrasystemHandovertriggered”，“S1intersystemHandovertriggered”，“X2Handovertriggered”，則根據不同的QCI統計相應指標。同時，根據具體業務數目對eNodeB正常釋放E-RAB的總次數進行累加，即指標L.E-RAB.NormRel累加。UE上下文掉線率定義：UE上下文掉線率=([UEContext異常釋放次數]/([UEContext異常釋放次數]+[UEContext正常釋放次數]))*100%；圖6UEContext異常釋放次數定義：如圖6中A點所示，當eNodeB向MME發送UECONTEXTRELEASEREQUEST消息，會釋放UE的所有E-RAB。當釋放原因不為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，“Timecriticalhandover”，“HandoverCancelled”時，測量指標L.UECNTX.AbnormRel加1。如圖6中A點所示，當eNodeB向MME發送S1RESET消息時，根據包含的上下文個數，指標L.UECNTX.Rel.S1Reset.eNodeB進行累加。如圖6中A點所示，當MME向eNodeB發送S1RESET消息時，根據包含的上下文個數，指標L.UECNTX.Rel.S1Reset.MME進行累加。圖7UEContext正常釋放次數定義：如圖7中A點所示，eNodeB主動發起的釋放，當eNodeB向MME發送UECONTEXTRELEASEREQEUST消息時，且釋放原因為“NormalRelease”，“Detach”，“UserInactivity”，“CSFallbacktriggered”，“UENotAvailableforPSService”，“Inter-RATRedirection”，“Timecriticalhandover”，“HandoverCancelled”時，該指標加1。并且在MME回復UECONTEXTRELEASECOMMAND消息時，該指標不會被重復記錄。如圖6中B點所示，MME主動發起的釋放，當eNodeB收到來自MME的UECONTEXTRELEASECOMMAND消息時，且如果釋放原因不是切換類原因值，包括“SuccessfulHandover”，“PartialHandover”，“S1intrasystemHandovertriggered”，“S1intersystemHandovertriggered”，“X2Handovertriggered”，則該指標加1。移動管理類指標切換事件概述：LTE主要有下面幾種類型測量報告：EventA1(Servingbecomesbetterthanthreshold)：表示服務小區信號質量高于一定門限，滿足此條件的事件被上報時，eNodeB停止異頻/異系統測量；類似于UMTS里面的2F事件；EventA2(Servingbecomesworsethanthreshold)：表示服務小區信號質量低于一定門限，滿足此條件的事件被上報時，eNodeB啟動異頻/異系統測量；類似于UMTS里面的2D事件；EventA3(Neighbourbecomesoffsetbetterthanserving)：表示同頻鄰區質量高于服務小區質量，滿足此條件的事件被上報時，源eNodeB啟動同頻切換請求；EventA4(Neighbourbecomesbetterthanthreshold)：表示異頻鄰區質量高于一定門限量，滿足此條件的事件被上報時，源eNodeB啟動異頻切換請求；EventA5(Servingbecomesworsethanthreshold1andneighbourbecomesbetterthanthreshold2)：表示服務小區質量低于一定門限并且鄰區質量高于一定門限；類似于UMTS里的2B事件；EventB1(InterRATneighbourbecomesbetterthanthreshold)：表示異系統鄰區質量高于一定門限，滿足此條件事件被上報時，源eNodeB啟動異系統切換請求；類似于UMTS里的3C事件；EventB2(Servingbecomesworsethanthreshold1andinterRATneighbourbecomesbetterthanthreshold2)：表示服務小區質量低于一定門限并且異系統鄰區質量高于一定門限，類似于UMTS里進行異系統切換的3A事件。測量事件判決條件eventA1事件進入條件：Ms-Hys>Thresh事件離開條件：Ms+Hys<ThresheventA2事件進入條件：Ms+Hys<Thresh事件離開條件：Ms-Hys>ThresheventA3事件進入條件：Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off事件離開條件：Mn+Ofn+Ocn+Hys<Ms+Ofs+Ocs+OffeventA4事件進入條件：Mn+Ofn+Ocn-Hys>Thresh事件離開條件：Mn+Ofn+Ocn+Hys<ThresheventA5事件進入條件：Ms+Hys<Thresh1&Mn+Ofn+Ocn-Hys>Thresh2事件離開條件：Ms-Hys>Thresh1orMn+Ofn+Ocn+Hys<Thresh2表1因此在我們優化過程中切換門限值至關重要，目前成都聯通也在陸續開通CA站點，我們會重點關注切換事件的同頻/異頻的停止與啟動門限精細優化，比如A2啟動門限過低會影響將導致切換不及時，原小區信號質量變差產生弱覆蓋現象，同樣影響速率，A2值設置過高，將導致異頻測量啟動過早，測量周期過長，對速率影響嚴重。eNodeB內切換成功率定義：eNodeB內切換成功率=[eNodeB內切換出成功次數]/[eNodeB內切換出執行次數]*100%；圖8eNodeB內切換出執行次數定義：如圖8中B點所示，在eNodeB內切換過程中，當eNodeB源小區向UE發送RRCConnectionReconfiguration消息時統計相應指標。各指標的具體統計方式如下所示：如果切換過程中源小區和目標小區為同頻，指標L.HHO.IntraeNB.IntraFreq.ExecAttOut加1。如果切換過程中源小區和目標小區為異頻，指標L.HHO.IntraeNB.InterFreq.ExecAttOut加1。如果切換過程中源小區和目標小區為異模式，指標L.HHO.IntraeNB.InterFddTdd.ExecAttOut加1。圖9eNodeB內切換出成功次數定義：如圖9中C點所示，在eNodeB內切換過程中，當eNodeB目標小區收到UE返回的RRCConnectionReconfigurationComplete消息后，等待切換過程中的緩存數據轉發完成時統計相應指標。如圖8中C點所示，在eNodeB內切換過程中，當eNodeB目標小區收到UE返回的RRCConnectionReestablishmentComplete消息時統計相應指標。如圖9中C點所示，在eNodeB內切換過程中，當eNodeB源小區收到UE返回的RRCConnectionReestablishmentComplete消息時統計相應指標。各指標的具體統計方式如下所示：如果切換過程中源小區和目標小區為同頻，指標L.HHO.IntraeNB.IntraFreq.ExecSuccOut加1。如果切換過程中源小區和目標小區為異頻，指標L.HHO.IntraeNB.InterFreq.ExecSuccOut加1。如果切換過程中源小區和目標小區為異模式，指標L.HHO.IntraeNB.InterFddTdd.ExecSuccOut加1。eNodeB間切換成功率定義：eNodeB間切換成功率=[eNodeB間切換出成功次數]/[eNodeB間切換出執行次數]*100%；圖10eNodeB間切換出執行次數定義：如圖10中B點所示，在eNodeB間進行X2接口切換過程中，當源eNodeB收到目標eNodeB的HANDOVERREQUESTACKNOWLEDGE消息后，向UE發送RRCConnectionReconfiguration消息時統計該指標。如圖10中B點所示，在eNodeB間進行S1接口切換過程中，當源eNodeB收到MME的HANDOVERCOMMAND消息后，源eNodeB向UE發送RRCConnectionReconfiguration消息時統計該指標。各指標的具體統計方式如下所示：如果切換過程中源小區和目標小區為同頻，指標L.HHO.IntereNB.IntraFreq.ExecAttOut加1。如果切換過程中源小區和目標小區為異頻，指標L.HHO.IntereNB.InterFreq.ExecAttOut加1。如果切換過程中源小區和目標小區為異模式，指標L.HHO.IntereNB.InterFddTdd.ExecAttOut加1。圖11圖12eNodeB間切換出成功次數定義：如圖11中C點所示，在eNodeB間進行X2接口切換過程中，當源eNodeB收到目標eNodeB的UECONTEXTRELEASE消息后，等待切換過程中的緩存數據轉發完成時統計相應指標。如圖11中C點所示，在eNodeB間進行X2接口切換過程中UE成功重建到目標eNodeB后，當源eNodeB收到目標eNodeB的UECONTEXTRELEASE消息后，等待切換過程中的緩存數據轉發完成時統計相應指標。如圖12中C點所示，在eNodeB間進行X2接口切換過程中UE成功重建到源eNodeB后，統計相應指標。如圖12中C點所示，在eNodeB間進行S1接口切換過程中，當源eNodeB收到MME的UECONTEXTRELEASECOMMAND消息后，等待切換過程中的緩存數據轉發完成時統計相應指標。如圖12中C點所示，在eNodeB間進行S1接口切換過程中UE成功重建到目標eNodeB后，當源eNodeB收到MME的UECONTEXTRELEASECOMMAND消息后，等待切換過程中的緩存數據轉發完成時統計相應指標。如圖12中C點所示，在eNodeB間進行S1接口切換過程中UE成功重建到源eNodeB后，統計相應指標。各指標的具體統計方式如下所示：如果切換過程中源小區和目標小區為同頻，指標L.HHO.IntereNB.IntraFreq.ExecSuccOut加1。如果切換過程中源小區和目標小區為異頻，指標L.HHO.IntereNB.InterFreq.ExecSuccOut加1。如果切換過程中源小區和目標小區為異模式，指標L.HHO.IntereNB.InterFddTdd.ExecSuccOut加1。S1接口切換成功率圖13當兩個eNodeB之間不存在X2接口，或X2接口不可用時，UE從當前所駐留的服務小區切換到另一eNodeB時，可采用基于S1接口的切換信令流程如圖13。定義：S1接口切換成功率=(([eNodeB間同頻切換出成功次數]+[eNodeB間異頻切換出成功次數])-([eNodeB間X2接口同頻切換出成功次數]+[eNodeB間X2接口異頻切換出成功次數]))/(([eNodeB間同頻切換出執行次數]+[eNodeB間異頻切換出執行次數])-([eNodeB間X2接口同頻切換出執行次數]+[eNodeB間X2接口異頻切換出執行次數]))*100%；X2接口切換成功率當兩個eNodeB之間存在X2接口時，UE從當前所駐留的服務小區切換到另一eNodeB時，可采用基于X2接口的切換。圖14圖15定義：X2接口切換成功率=([eNodeB間X2接口同頻切換出成功次數]+[eNodeB間X2接口異頻切換出成功次數])/([eNodeB間X2接口同頻切換出執行次數]+[eNodeB間X2接口異頻切換出執行次數])*100%系統內切換成功率定義：系統內切換成功率=([eNodeB內同頻切換出成功次數]+[eNodeB間同頻切換出成功次數]+[eNodeB內異頻切換出成功次數]+[eNodeB間異頻切換出成功次數])/([eNodeB內同頻切換出執行次數]+[eNodeB間同頻切換出執行次數]+[eNodeB內異頻切換出執行次數]+[eNodeB間異頻切換出執行次數])*100%同頻切換成功率定義：同頻切換成功率=([eNodeB內同頻切換出成功次數]+[eNodeB間同頻切換出成功次數])/([eNodeB內同頻切換出執行次數]+[eNodeB間同頻切換出執行次數])*100%；異頻切換成功率定義：異頻切換成功率=（+[eNodeB內異頻切換出成功次數]+[eNodeB間異頻切換出成功次數]）/([eNodeB內異頻切換出執行次數]+[eNodeB間異頻切換出執行次數])*100%業務完整類指標上行PDCPSDU丟包率定義：上行PDCPDSU丟包率=([上行PDCPSDU丟包數]/[上行PDCPSDU包總數])*100%；下行PDCPSDU丟包率定義：下行PDCPDSU丟包率=[下行PDCPSDU丟包數]/[下行PDCPSDU包總數]*100%；資源負荷類指標上行PRB平均利用率定義：上行PRB平均利用率=[上行PhysicalResourceBlock被使用的平均個數]/[上行可用的PRB個數]*100%；下行PRB平均利用率定義：下行PRB平均利用率=[下行PhysicalResourceBlock被使用的平均個數]/[下行可用的PRB個數]*100%；華為LTE主要KPI優化方法及案例呼叫接入類指標優化方法呼叫接入類指標分析流程：處理步驟小區是否存在異常告警；確認小區是否有干擾后臺取小區的系統上行每個PRB上檢測到的干擾噪聲的平均值，確認小區是否有上行干擾。如果有干擾，需確認是模三干擾，互調干擾，還是外部干擾；3）確認是否覆蓋問題1.檢查傳輸模式，確定小區存在弱覆蓋；2、對比64QAM和QPSK占比，可確定小區覆蓋異常；3、鄰區告警、故障等導致TOP小區存在弱覆蓋；4、天饋問題；5、無線環境差；6、基站規劃、建設、施工問題；7，天線權值配置與現場天線參數不一致。8.核查參考信號功率；4）確認是否高質差問題1.通過觀察小區上下行丟包率是否正常，斷定小區存在質差；2、通過后臺誤碼率跟蹤，如BLER>10%，確定小區存在高誤碼；5）確實是否是資源不足的問題可以通過后天話統查看：資源分配失敗而導致RRC連接建立失敗的次數，無線資源不足導致E-RAB建立失敗次數，這些話統確認是否小區資源不足導致接入失敗。6）確認是否是終端或是用戶行為異常需要通過對用戶進行后天信令跟蹤和前臺現場測試結合來確認問題原因；7）問題閉環。呼叫接入類優化案例CDF1730_大豐王橋2社_3小區接入失敗分析問題描述：CDF1730_大豐王橋2社_3小區的RRC建立成功率一直持續在98%左右。問題分析：核查該站是否有告警：無；后臺取小區的系統上行每個PRB上檢測到的干擾噪聲的平均值，都在-118左右，正常無干擾；分析主要RRC建立失敗的主要原因為：UE無應答而導致RRC鏈接建立失敗。由此可見主要問題是由于弱覆蓋導致的RRC建立失敗，由于該站點處在繞城附件的郊區，站間距離在1公里以上，檢查該小區的RS功率為15.2dBm，修改該小區的RS功率為16.2dBm后，問題解決。修改RS功率后，RRC建立成功率提升到99%以上，問題閉環。呼叫保持類指標優化方法呼叫保持類指標分析流程：處理步驟1）小區是否存在異常告警；2）對于eNodeB發起的原因為切換失敗的UEContext釋放：需要提取兩兩小區切換確定目標小區；1.確定目標小區運行情況，是否基站故障或異常告警；2.檢查鄰區間參數設置是否正確；3.檢查小區鄰區配置是否合理，進行鄰區合理性優化；4.檢查基站是否周邊站點缺少，如為孤站，可視為正常；3）對于eNodeB發起的原因為上行弱覆蓋的UEContext異常釋放：如果有是上行弱覆蓋導致的異常釋放，需要增加RS功率，或是RF優化解決。4）eNodeB發起的S1RESET導致的UEContext釋放次數現統計中eNodeB發起的S1RESET導致的UEContext釋放次數均為0，如統計出現釋放次數，需進行針對排查；檢查S1鏈路是否配置正確。5）對于eNodeB發起的原因為UELOST的UEContext釋放和eNodeB發起的原因為無線層問題的UEContext釋放：a.參數是否設置合理（1）.查詢掉線類定時器設置是否正確；（2）.如掉線率突增，查詢操作日志，確認是否有修改，導致小區異常；b.是否存在高干擾（1）.查看小區PCI復用是否合理，是否存在模三沖突；（2）.如每PRB上干擾噪聲平均值>-110dBm,確認小區存在上行干擾，同時可通過后臺跟蹤，確認干擾類型；c是否存在高質差（1）.通過觀察小區上下行丟包率是否正常，如丟包率偏高，基本斷定小區存在質差；（2）.通過后臺誤碼率跟蹤，如BLER>10%，確定小區存在高誤碼；d.是否存在弱覆蓋（1）.檢查傳輸模式，是否為TM3，如長時間為TM2，確認設置正確的情況下，基本確定小區存在弱覆蓋；（2）.對比64QAM和QPSK占比，如后者比例遠大于前者,可確定小區覆蓋異常；e.后天信令跟蹤和前臺現場測試（1）.安排前場人員現場測試，同時后臺通過信令跟蹤，配合查找問題原因；（2）.如果確認問題后，需第三方配合解決，轉發相關人員處理，做好跟蹤工作，直至問題閉環；呼叫保持類優化案例CDF3040_平樂古鎮_1小區高掉話失敗高問題分析1）問題描述：CDF3040_平樂古鎮_1小區高掉話失敗高2）問題分析核查該站是否有告警：無；后臺取小區的系統上行每個PRB上檢測到的干擾噪聲的平均值，都在-118左右，正常無干擾；檢查小區兩兩切換指標,主要切換向邛崍平樂_3小區切換失敗。從X2口的標準信令監控來看，主要切換失敗都是eNodeB=461188的3小區=邛崍平樂_3，和話統上的兩兩切換是對應的。檢查邛崍平樂_3告警情況，發現該站有射頻單元維護鏈路異常告警，BBUCPRI接口異常告警，小區服務能力下降告警。推動維護處理告警后，指標恢復，問題閉環。移動管理類指標優化方法移動管理類指標分析流程：處理步驟小區是否存在異常告警；參數核查，核查小區的切換參數是否正確合理排除核心網的原因請核心網配合對參數進行核查及信令跟蹤排查問題；后臺提取兩兩小區切換次數，找到失敗的目標小區核查外部小區和鄰區關系核查小區是否有干擾，確認是模三干擾，還是外部干擾是否存在弱覆蓋，RS功率，RF優化，新增站點是否存在資源不住引起的擁塞問題，擴容，新增站點閉環。移動管理類優化案例CDF0586_文家七里溝8組_3小區切換成功率低問題分析問題描述：CDF0586_文家七里溝8組_3小區切換成功率低，在80%多；問題分析：核查該站是否有告警：無；后臺取兩兩小區切換數據，顯示每天向CDF0654_多聯建材_2和CDF127931合作鎮清江社區_2切換失敗，這2個小區距離該基站超過5公里，冗余的外部小區，外部小區優化；該站位于光華大道二段附件，與愛立信交接區域（綠色—愛立信，藍色華為）存在模三干擾的。修改CDF0586_文家七里溝8組_3小區PCI由365修改為35。愛立信LTE主要KPI優化方法及案例接入類指標優化方法告警核查接入差小區處理流程第一步：檢查是否因硬件問題導致接入指標差(若RRC建立成功率很高，僅因為ERAB承載建立成功率低而引起接入指標差，可直接進入第三步準入控制分析)。硬件告警告警查詢相關操作，Event查詢，可以快速查看站點運行情況，核查是否發生故障。操作日志查詢：lgo歷史告警查詢：lga當前告警查詢：alt歷史Event查詢：lge站點硬件運行情況查詢：invhr站點硬件運行情況查詢：cabx站點運行log查詢：telogreadvswr查詢：lhrufuigetvswr常見影響KPI告警：TimingSyncFault（GPS信號不穩定）；SystemClockQualityDegradation（時鐘同步告警）；SectorEquipmentFunction=3(timeout_expired)；附告警查詢操作實物圖：天饋告警如果基站出現駐波告警會影響小區的接入性，有些天饋問題可能沒有告警，FFAX是檢測這類問題較方便的工具告警標識：VswrOverThreshold（駐波比告警，可以cabx查看RRU駐波比，一般駐波比設置為1.5db，小于1.5db就不會有告警）。信道檢查檢查Enode各個信道是否正常，若僅有PRACH、PDSCH、

PUSCH信道倒掉就會導致用戶不能接收到小區信息，數據業務的ERAB建立成功率為0，此種情況只需重啟基站或者信道就能恢復正常。其他告警其他告警如License、傳輸告警等同樣會影響小區的接入性。LicenseKeyFileFault（license失效或者沒有植入，所以導致這樣的告警）；GigabitEthernetLinkFault（1.傳輸光口光纖斷，2.傳輸光口沒有插光纖）；干擾核查檢查干擾主要包括:ULRSSI是否處于正常值范圍、模三干擾、直放站干擾。ULRSSILTE從統計上檢查ULRSSI的counter值：pmRadioRecInterferencePwr是否正常:一般認為-120dBm～-110dBm為合理范圍，但大于-105dBm時認為RSSI偏低，過來可能原因包括:TMA問題，天線問題，硬件故障(饋線/連接器/跳線)等，需要逐一排查；當大于-100dBm時認為RSSI偏高，過來原因包括:TMA問題，話務增加，干擾增加以及錯誤配置等，應檢查TMA，觀察話務量走勢，使用頻譜分析儀檢測干擾，檢查是否有錯(饋線接反)等。網管側查看統計方法：定義了IntferenceScanner統計，pmRadioRecInterferencePwr這個測量值激活定義好的測量scanner狀態=pdebIntferenceScanner激活后，IntferenceScanner為active狀態查看定義的統計=PST,IntferenceScanner為active狀態查看site實際底噪=pget.pmRadioRecInterferencePwr$pmRadioRecInterferencePwi[16]為底噪打點分布區間，本站多分布在【3】查詢pmRadioRecInterferencePwr參數含義=pmom.pmRadioRecInterferencePwr$16個區間對應的N+I分布值，【3】區間為-119~-118；一般N+I在=-106以上才有問題，不正常【11】正確情況，底噪應該多分布在【0】~【4】同PCI干擾定期進行全網一二級PCI沖突檢查，保證相同擾碼的復用距離不要過近造成干擾，PCI檢查工具可以使用XNOW。另外模三沖突需要大量DT測試數據發現。網管側PCI查看：指令：查看PCI：get^eutrancellfddphysicalPCI=physicalLayerCellIdGroup*3+physicalLayerSubCellId直放站干擾直放站干擾是目前存在的最普遍的上行干擾問題之一。直放站干擾分為無線直放站干擾和光纖直放站干擾。無線直放站實際上是一個寬頻放大器，它將整個移動上行和下行頻帶放大，實現信號覆蓋。無線直放站有合法直放站和非法直放站之分，合法直放站由于設置不好，會造成對基站的干擾，但較多的無線直放站干擾為非法私自安裝的無線直放站或MINI直放站，這是因為劣質的無線直放站價格便宜，在人口密度大，移動信號覆蓋不好的場所經常私自安裝。無線直放站的干擾特點是頻帶寬，占據整個上行，且幅度不穩定。光纖直放站干擾頻譜的底噪音較強，比正常業務情況下的噪音電平一般高20dB～30dB，干擾區域也較大，可造成該區域部分用戶無法正常使用手機，未接通、掉話等現象。光纖直放站的干擾特點是頻帶寬，占據整個上行，且幅度穩定。處理方法：拆除私自安裝的無線直放站或MINI直放站；用頻譜儀測試合法無線直放站接收施主基站信號的強度，如果信號較強建議加裝衰減器，確保接收到的施主基站信號強度在-70dBm左右。確保合法無線直放站的施主天線與重發天線有較好的隔離度，避免自激現象產生，同時建議施主天線的安裝高度不超過6層樓。根據現場實際情況，重新調整無線直放站的上、下行ATT值。上行ATT設置值＝下行ATT設置值＋5dB下行ATT設置值＝直放站下行額定輸出功率－2dBm為設置依據。排查是否存在其他運營商無線寬頻直放站的干擾。無線寬頻直放站也會因為器件的參數問題，放大聯通上行頻段內的一些頻點，對聯通上行頻段產生干擾。準入控制分析MpLoad統計counter：pmRrcConnEstabFailHighLoadpmRrcConnEstabFailOverload如果EnodeMpLoad負荷過高則會產生RRC建立受限，需要通過參數調整、RF優化、、新增站點、擴載波等方法可以降低Enode負荷。CULICENSE受限pmLicConnectedUsersMax（峰值用戶數）pmLicconnectedUsersLicense（LICENSE許可用戶數）當pmLicConnectedUsersMax/pmLicconnectedUsersLicense*100%>=75%將會影響用戶接入，因此建議采取相應解決措施。主要解決手段：CUlicense擴容、RF優化負荷分擔。話務熱點覆蓋分擔有時話務熱點區域用一個sector或site無法滿足話務需求，可以引入附近其他不擁塞小區覆蓋分擔話務，之后再考慮擴容。檢查弱覆蓋通過WMRR判斷是否存在弱覆蓋。弱覆蓋解決主要手段為:物理手段與參數調整手段物理手段:調整天線、處理阻擋、處理因天線性能或老化導致弱覆蓋等情況。參數調整:maximumTransmissionPower、PAPB、；檢查參qRxLevMin、qQualMin、觀察周圍是否有信號較強小區。注意提升qRxLevMin、qQualMin會較容易提升相關小區的接入指標，但可能造成真正的無法接入，不建議偏離default值過遠。Neighbor合理化。如果有較明顯的漏定鄰區，會導致UE在idle狀態時不容易駐留在最好的小區，導致起呼接入查。接入類問題優化案例案例：對比38個擴容站點的指標對比情況1：

業務量

（38個站點擴容前后業務量平均增長10.89%）2：

RRC建立成功率

（

提取實際忙時，38個站點平均提升2.75%）。3：ERAB建立成功率

（

提取實際忙時，38個站點平均提升1.76%）4：

切換成功率

（

提取實際忙時，38個站點平均提升0.73%）。呼叫保持類指標優化方法本流程主要關注數據業務的保持性指標。數據掉線愛立信的統計原因基本可分為6大類型不同的掉線原因相對有不同的處理方法，以下對不同原因的掉線分析排查清單和解決建議。分析流程counter：數據收集：1、計算保持性KPI公式及可能影響掉線counter原始數據；2、全網地圖文件(MapInfo圖層及googleearth文件)；3、最新全網database信息；4、差小區的告警信息；弱覆蓋UE檢測主服務小區及鄰小區都低于-100dBm，定義為弱覆蓋現象，可以通過現場工程師SSV_DT驗證及MRR測量信息收集是否存在四超站點(超高、超低、超近、超遠)、基站告警退服、鄰區漏配等原因導致RSRP<-100dBm，建議消除告警、鄰區優化、RF優化、增加新站加強覆蓋。上行高干擾從系統上檢查PUCCH和PUSCH的counter：pmRadioRecInterferencePwr是否正常目前2/3/4G基站共存導致系統干擾也大幅度提升，如天線隔離度不夠導致阻塞、互調、雜散干擾等，工程師需通過上站收集天饋信息、DT(DriverTest)數據BLER誤碼率及掃頻儀器來判斷干擾源，一般認為≤-110dBm為合理范圍，當＞-110dBm時認為存在上行干擾，可能原因包括：上行不同步(TDD)、廣電干擾，天線問題，硬件故障(饋線、連接器、跳線)等，需逐步排查干擾源。如果檢查結果值相對較高可以進行以下排查：問題小區是否固定一個時間段PUCCH和PUSCH值較高還是全天都處于偏高狀態。全天值都處于較高，需要發單處理要求檢查基站。是否有天線問題、硬件故障(饋線、連接器、跳線)，硬件問題。附近有沒有干擾源，特別是小區覆蓋隱私密度較高的建筑，如政府部門重要機構，軍區，醫院，學校等。如果有是否可以通過調整天線物理來解決。建議解決方案：一般在基站正常工作的情況下，掉線主要由于弱覆蓋區域、小區天線物理設置不合理導致過覆蓋或者重疊覆蓋高天饋調整通過RF優化有效控制覆蓋合理性。參數調整可以通過參數調整，如RS參考信號PA/PB等來進行優化。勘站及路測檢查站點是否廣告牌或者其它實物阻擋如美化天線，如有必要發單要求整改，另外通過路測檢查問題小區的信號是否處于重疊覆蓋區域。新開站點如果處于站點比較稀疏的區域容易造成掉線不因只加強PA/PB或者天線來增加覆蓋，而是盡量催開附件的規劃站點或者提新建站點來解決，相關列表記得長期維護并且時時更新。5、鄰近站點退服鄰近站點倒站導致問題小區附近區域覆蓋不連續，出現弱覆蓋而引起掉話幾率相對提高，應盡快發單處理倒站問題，并且暫時通過參數優化來暫時解決問題，直到倒站問題解決為止。建議可以暫時調整PA/PB來控制覆蓋。倒站問題解決后必須將相關參數恢復之前的值。6、直放站干擾應準確測量并記錄直放站的經緯度（拉遠位置），避免造成干擾。PCI模3干擾–將導致SINR始終處于最差的情形，且和系統負載不相關；這將導致UE匯報的CQI不能真實反映當時的無線信道質量；

–將引起UE對RSRP的測量困難、測量不準確、測量時間偏長；進而可能延誤切換的時機而導致掉線；解決方案：1、Mod3干擾首先進行RF優化調整,因為前期嚴格規劃PCI是經過對無線環境的衡量進行勘察規劃。2、如進行修改物理PCI時DT工程師圍繞基站扇區覆蓋范圍進行拉測，觀察前后SINR值、DL吞吐率變化是否有所提高。備注：兩個小區的PCImode3相等時，若信號強度接近，由于RS位置的疊加，會產生較大的系統內干擾，導致終端測量RS的SINR值較低，稱之為“PCImod3干擾”。傳輸故障檢查告警信息，看是否存在傳輸問題：觀察S1傳輸是否存在問題，解決傳輸故障；eNodB問題掉話由于某個時間段出現閃斷引起，可以通過hourly數據排查是從哪個時間段開始掉話率惡化，然后再對應當時是否告警或者其它部門當時對于問題小區有進行任何操作。檢查系統升級、是否打補丁等動作；切換引起掉話常見HO掉話可以分為4大問題類型：源小區的鄰區里是否存在和目標小區同頻的相同PCI鄰區；解決方案：并刪除不合理的鄰區；或者修改一條鄰區的PCI。T304配置過短目標小區是否存在上行干擾；查找干擾源排除干擾目標小區是否擁塞，或者License受限；如果問題小區出現多次擁塞掉話，應該注意是否附近的基站都有出現擁塞的問題，一般出現擁塞掉話的站點可能自己或者附近小區的接入率相對的差，主要是出現擁塞問題。解決方案：優化手段:查看服務小區及目標小區license是否受限申請擴容，或者修改切換參數（CIO）引導源小區向周邊其他小區切換進行分流;目標小區是否存在弱覆蓋；查看同頻/異頻切換門限否設置合理；查看周邊無線環境是否由于站點缺失導致弱覆蓋想象，新增基站加強覆蓋。檢查MME是否存在告警提取counter及查詢MME狀態是否存在負載過高及告警。移動管理類指標優化方法LTE切換異常現象UE向源小區發送測量報告后沒有收到切換命令UE在源區收到切換命令，在目標鄰小區發送隨機接入（MSG1）但是未收到隨機接入響應(MSG2)。小區之間乒乓切換。小區之間切換序列混亂。切換過程中數據中斷切換問題分析流程針對這些切換異常，應該從參數配置，鄰區配置，基站傳輸，硬件告警，上下行干擾等幾個方面入手分析問題。其中參數合理性檢查主要包括以下等幾個方面：鄰區漏定義鄰區PCI沖突目標鄰小區切換是否打開切換偏置設置合理性數據轉發功能是否打開切換主要問題鄰區配置不合理問題描述：通過統計觀察到到小區70736-4的切換成功率為0%，而到70272-2的切換嘗試次數為0。問題分析：經檢查配置發現70736-4和70272-2這兩個小區配置了相同的PCI，而且正確的目標切換小區應該是70272-2。問題解決：通過刪除70736-4的鄰區關系后，到70272-2的切換成功率恢復到100%。參數設置問題問題描述：通過觀察基站側統計發現有很多切換準備成功率為0%的鄰區關系，共同點是目標小區都屬于同一個基站(基站ID4506-70483)。問題分析：通過分析發現該基站(基站ID4506-70483)計數器pmHoPrepRejInLicMob的數值很高，計數器pmHoPrepRejInLicMob解釋：統計由于目標基站缺少切換相關的license而導致切換失敗的次數。問題解決：在激活目標基站的license之后，切換成功率恢復100%。無線環境問題問題描述：路測中武昌路段切換序列混亂，而且切換成功率較低。問題分析：通過測試log分析發現武昌路（紅圈1,2,3）主要占用SN黃海飯店2小區（PCI_238），SN黃海飯店2小區（PCI_238）天線掛高70m,越區覆蓋嚴重，問題解決：通過調整SN黃海飯店2小區（PCI_238）機械下傾角下壓到10度，控制越區減小對其他小區干擾。優化后武昌路主要占用世紀之星3小區信號（PCI74）（下圖紅框所示），信噪比改善，越區覆蓋消除，切換恢復正常。江蘇科技大學80周年校慶活動宗旨及目的2013年，江蘇科技大學走過了80年的風雨路，江蘇科技大學人秉承學校積淀了80年的“篤學明德，經世致用”的傳統，發揚“好學力行，求是創新，艱苦奮斗，自強不息”的精神，在建設高水平大學的努力之中取得了令人矚目的成就。為了回顧學校歷史，展示辦學成就，擴大學校知名度，激勵師生、校友愛校榮校的精神，增強社會各界關心、支持學校辦學的熱情，匯集各界力量，促進學校全面、快速、可持續發展，學校決定啟動建校80周年校慶籌備工作。（一）活動主題傳承、開拓、團結、創新（二）指導思想以鄧小平理論和“三個代表”重要思想為指導，深入貫徹落實科學發展觀和黨的十七大、十七屆三中、四中全會精神，以“展示黨的民族理論、民族政策、民族教育輝煌成就，江蘇科技大學將秉承“篤學明德、經世致用”的校訓，大力弘揚“船魂”精神，努力達到本科教學一流、優