CS 12.2K接通率專題優(yōu)化報(bào)告

1、12.2K接通率專題優(yōu)化報(bào)告 Build Excellent TD-SCDMA Network 目錄1專題概述31.1目的31.2內(nèi)容31.3計(jì)劃32優(yōu)化原理及流程42.1無線接通率定義及流程42.1.1無線接通率定義42.1.2接入系統(tǒng)信令流程52.2無線接通率分析流程92.2.1話統(tǒng)數(shù)據(jù)分析102.2.2TOP小區(qū)分析及測試152.2.3RRC接通率分析172.2.4RAB接通率分析192.2.5其他原因引起的接通率分析213優(yōu)化前的網(wǎng)絡(luò)評估223.1網(wǎng)絡(luò)分析223.1.1 KPI分析223.2問題發(fā)現(xiàn)（CDLMR分析結(jié)果）263.2.1 主要問題分類264專題優(yōu)化內(nèi)容284.1RRC接通

2、率優(yōu)化284.1.1RRC:RNC給NB發(fā)RL Setup后5秒內(nèi)又發(fā)RL Delete284.1.2RRC: 1次RRC Setup無響應(yīng)(未收到RL Restore Indication)314.2RAB接通率優(yōu)化354.2.1RAB: RAB建立過程和CellUpdate并發(fā)354.2.2RAB: RNC給CN發(fā)了RAB Setup Failure（其它失?。?84.3提升無線接通率的專項(xiàng)優(yōu)化-小區(qū)合并技術(shù)424.3.1 小區(qū)合并技術(shù)424.3.2 解決場景424.3.3解決過程424.3.4小區(qū)合并測試結(jié)果：454.4提升無線接通率專項(xiàng)優(yōu)化-變頻技術(shù)455.優(yōu)化前后對比465.1優(yōu)化后

3、的KPI情況（一周）465.1.1全網(wǎng)的KPI情況465.1.2各RNC的KPI情況（一周時(shí)間）465.2優(yōu)化前后KPI對比情況（一周時(shí)間）475.2.1全網(wǎng)優(yōu)化前后指標(biāo)對比475.2.2各RNC優(yōu)化前后指標(biāo)對比485.3專題優(yōu)化總結(jié)48版權(quán)所有，侵權(quán)必究第2頁,共34頁1 專題概述1.1 目的本次CS12.2K接通率專項(xiàng)優(yōu)化項(xiàng)目的目的： 1) 提升CS域無線接通率到集團(tuán)要求的水平；2) 減少干擾、擁塞、故障、切換等問題引起的CS域接通率指標(biāo)，降低CS域掉話率，改善網(wǎng)絡(luò)KPI指標(biāo)，提升用戶的體驗(yàn)；1.2 內(nèi)容本次專題優(yōu)化的主要內(nèi)容是提升CS12.2K的接通率。通過對現(xiàn)網(wǎng)的評估，梳理出接通率優(yōu)化

4、的思路，以及各種優(yōu)化手段，解決現(xiàn)網(wǎng)存在的問題，達(dá)到提升接通率的目的。1.3 計(jì)劃優(yōu)化項(xiàng)目工作時(shí)間優(yōu)化內(nèi)容優(yōu)化原理及流程8.25-8.26無線接通率定義及接入流程無線接通率分析流程優(yōu)化前的網(wǎng)絡(luò)評估8.26-8.26KPI分析問題發(fā)現(xiàn)（CDLMR分析結(jié)果）主要問題分類專題優(yōu)化內(nèi)容8.27-8.28RRC接通率優(yōu)化RAB接通率優(yōu)化提升無限接通率的專項(xiàng)優(yōu)化優(yōu)化前后對比8.30-9. 6優(yōu)化后KPI情況優(yōu)化前后KPI對比情況總結(jié)2 優(yōu)化原理及流程2.1 無線接通率定義及流程2.1.1 無線接通率定義語音無線接通率相關(guān)的幾個(gè)重要參數(shù)定義如下：TD語音無線接通率 = 會(huì)話類業(yè)務(wù)RRC建立成功率×語

5、音業(yè)務(wù)RAB建立成功率注意：（1） 在RRC階段不知道業(yè)務(wù)來源于那個(gè)域（在R6協(xié)議中，RRC請求階段已經(jīng)有域標(biāo)識了），因此RRC連接建立成功率只能按業(yè)務(wù)、主被叫分開；而RAB建立成功率可以按業(yè)務(wù)、域分開；這兩個(gè)比率不存在一一對應(yīng)關(guān)系； （2） 對于單UE多次RRC Connection Request消息，在統(tǒng)計(jì)的時(shí)候只統(tǒng)計(jì)一次；（3） 如果UE的RRC請求發(fā)不上來，會(huì)影響路測指標(biāo)，不會(huì)影響網(wǎng)管指標(biāo)；（4） CS域RRC連接建立成功率為請求原因?yàn)镃S域的RRC建立統(tǒng)計(jì)總和；（5） PS域無線接通率計(jì)算的是RRC連接建立總成功率，而CS語音業(yè)務(wù)無線接通率計(jì)算的是CS域RRC連接建立成功率，故不同

6、原因的RRC建立成功率對PS、CS業(yè)務(wù)的無線接通率影響不同。（6） 對于RRC建立完成后至RAB建立前,消息交互中的失敗流程不會(huì)記入接通率的統(tǒng)計(jì)中，其間涉及到RNC需要處理的消息有用戶Iu信令連接的建立和完整性保護(hù)和加密；后續(xù)的非接入層交互消息也不會(huì)影響接通率，但對用戶感受有影響。2.1.2 接入系統(tǒng)信令流程（1） CS語音業(yè)務(wù)主叫流程（被叫略）分析CS呼叫流程圖，可以將呼叫分為RRC過程、RAB過程、其他非接入層交互三部分，后續(xù)的分析過程也分這三部分來分析。2.2 無線接通率分析流程無線接通率分析可如下圖所示：開始獲取全網(wǎng)RRC和RAB建立成功率變化趨勢話務(wù)統(tǒng)計(jì)數(shù)據(jù)指標(biāo)是否滿足要求結(jié)束TOP

7、小區(qū)分析YN站點(diǎn)是否異常提交排障組檢查YRRC建立問題NRRC TOP小區(qū)調(diào)整實(shí)施，網(wǎng)優(yōu)分析，算法分析RAB建立問題RAB TOP小區(qū)調(diào)整實(shí)施，網(wǎng)優(yōu)分析，算法分析是否可以推廣到全網(wǎng)全網(wǎng)修改措施實(shí)施YYY流程圖說明：1. 獲取全網(wǎng)的RRC和RAB建立成功率指標(biāo)以及趨勢，至少需要分析3天1周左右的數(shù)據(jù)；2. 如果全網(wǎng)的接通率指標(biāo)一直偏低，分析面向小區(qū)的RRC和RAB建立成功率指標(biāo)，把面向小區(qū)的RRC建立成功率指標(biāo)和RAB建立成功率從低到高的順序進(jìn)行排序，優(yōu)先分析成功率低而且建立失敗絕對次數(shù)也多的小區(qū)；進(jìn)行小區(qū)接通率分析； 3. 找出影響指標(biāo)的TOP小區(qū)，根據(jù)RNC側(cè)和NodeB側(cè)告警信息，確認(rèn)這些

8、TOP小區(qū)是否存在設(shè)備故障，并且參考施工信息，確認(rèn)是否這些TOP小區(qū)正在更換，排除這些因素后，后續(xù)決定這些小區(qū)是否需要參數(shù)調(diào)整。4. 根據(jù)RRC和RAB建立成功率分析結(jié)果，對Top小區(qū)實(shí)施優(yōu)化措施；優(yōu)化措施實(shí)施后對比該小區(qū)的接通率指標(biāo)是否改善；分析優(yōu)化措施是否可以推廣的全網(wǎng)，如果可以的話安排全網(wǎng)的實(shí)施，分析實(shí)施后的指標(biāo)是否滿足要求，如果滿足要求，那么結(jié)束接通率優(yōu)化；否則，重新進(jìn)行TopN小區(qū)優(yōu)化；2.2.1 話統(tǒng)數(shù)據(jù)分析因無線接入的主要流程和性能統(tǒng)計(jì)都在RNC側(cè)實(shí)現(xiàn)，下面我們根據(jù)現(xiàn)網(wǎng)常用的2個(gè)分析方法分別進(jìn)行說明：1） KPI+CDL分析法：根據(jù)KPI分析CDL，可以按KPI指標(biāo)將某個(gè)指標(biāo)最差

9、的10個(gè)小區(qū)和對應(yīng)時(shí)段找出來，然后分析CDL中的失敗流程和消息；該方法適用所有小區(qū)，可以分析已經(jīng)發(fā)生的呼叫，進(jìn)行簡單初步定位。2） 信令跟蹤分析法：分析信令跟蹤，可具體跟蹤到消息交互和RNC內(nèi)部消息交互。該方法只適合針對某小區(qū)或UE進(jìn)行小范圍即時(shí)跟蹤，可以看到局間消息交互，也可以跟蹤到RNC內(nèi)部部分消息交互，方便詳細(xì)定位和分析問題。（1） KPI+CDL分析法根據(jù)KPI的統(tǒng)計(jì)功能，首先找出指標(biāo)比較差的RNC，再根據(jù)該RNC分時(shí)段分小區(qū)的統(tǒng)計(jì)量化出哪些小區(qū)在拉指標(biāo)的后腿，然后根據(jù)對應(yīng)時(shí)段的CDL分析出原因來。這些工作要充分使用KPI、CDL的統(tǒng)計(jì)過濾功能，能在很短時(shí)間內(nèi)找出最差時(shí)段和最差小區(qū)，以

10、及初步原因。1 ： KPI分析主要是針對其中比較差的指標(biāo)進(jìn)行統(tǒng)計(jì)，可以先從全天KPI指標(biāo)中找出KPI比較差的RNC和指標(biāo)。2 ： 從該RNC分時(shí)段分小區(qū)的統(tǒng)計(jì)量化出哪些小區(qū)在影響指標(biāo)。3 ：分析該時(shí)段CDL文件，查看原因。CDL自動(dòng)分析結(jié)果可以導(dǎo)出UE接入表中的“UE建立原因”和“呼叫結(jié)果”，常見失敗原因有如下幾類：RRC signal process fail、Signal Link setup fail、traffic setup fail（Signal Link setup fail與RRC signal process fail的最大區(qū)別是，前者是指Iu口信令建立失敗或UE的安全模式控

11、制建立失敗導(dǎo)致的釋放，后者是指RRC過程建立失敗，前者失敗不會(huì)影響接入成功率指標(biāo)，不是優(yōu)化重點(diǎn)關(guān)注對象）；對于RRC過程失敗，沒有單一消息可以過濾，但可以根據(jù)關(guān)鍵字小區(qū)ID過濾搜索；RAB建立過程，可以根據(jù)RB Setup Failure消息來過濾，初步得到失敗原因，可以根據(jù)其消息攜帶的不同原因來區(qū)分那些釋放為接入失敗。4：設(shè)備排查一般必現(xiàn)的問題，在網(wǎng)絡(luò)優(yōu)化不能解決的情況下，多數(shù)懷疑為設(shè)備異常導(dǎo)致，一定要進(jìn)行設(shè)備方面的健康檢查與故障排查。以前文廣州御景軒為例，進(jìn)行設(shè)備排查如下：1、 提取基站告警日志，沒有發(fā)現(xiàn)異常告警；2、 分析機(jī)房提取的2個(gè)RRU 61號日志，確認(rèn)RRU時(shí)隙方向有沒有問題；3

12、、 分析DLCP內(nèi)存日志，只有頻點(diǎn)1有用戶，在TS3有數(shù)據(jù)發(fā)送，而且功率正常；頻點(diǎn)0只有公傳，而且功率也沒有問題，沒看到有什么異常；4、 通過提取分析RRU日志，發(fā)現(xiàn)此站發(fā)生過RRU退服又恢復(fù),而且期間沒有過小區(qū)刪建。5、 最后復(fù)位RRU，問題依舊，沒有解決。6、 新通過RRU布配，將RRU上的2個(gè)通道更換，進(jìn)行復(fù)測，小區(qū)恢復(fù)正常，確認(rèn)是這2個(gè)通道故障。最終，基站恢復(fù)正常，小區(qū)正常。如果不是設(shè)備方面的問題，則對其根據(jù)實(shí)際情況，進(jìn)行RRC接入優(yōu)化與RAB的接入優(yōu)化分析。2.2.2 RRC接通率分析（1） RRC過程分析（建立在DCH）RRC過程主要就是在UE上發(fā)了RRC Connection R

13、equest消息后，初始直傳消息前，具體流程如下圖：1、 UE在RACH上發(fā)RRC CONNECTION REQ；2、 RNC接收到RRC CONNECTION REQ后，配置L2資源并和NodeB建立IUB接口上的RL鏈路；3、 RNC向UE發(fā)RRC CONNECTION SETUP；4、 UE回復(fù)RRC CONNECTION SETUP COMPLETE。統(tǒng)計(jì)RRC接通率的起始點(diǎn)是RNC收到RRC CONNECTION REQ，終止點(diǎn)是RNC收到RRC CONNECTION SETUP COMPLETE。因此影響RRC接通率的RRC建立失敗，主要是后面三步?jīng)]有成功而導(dǎo)致的。（2） RRC連

14、接建立失敗分析以外場出現(xiàn)的情況看，出現(xiàn)以下問題：1、 終端不發(fā)RACH，在基站側(cè)看不到RACH信道計(jì)數(shù)增加；（該情況不影響KPI指標(biāo)）2、 終端發(fā)了RACH，在RNC側(cè)看到RACH增加，同時(shí)看到RRC Connection Setup下發(fā)，但終端收不到FACH；3、 RNC收到了RRC Connection Setup，返回RRC Connection Reject消息；4、 終端能夠收到 RRC Connection Setup，但不回RRC Connection Setup complete；終端能夠收到 RRC Connection Setup，終端回RRC Connection Set

15、up complete，但RNC側(cè)收不到；（3） RRC連接建立CheckList檢查類別檢查項(xiàng)RRC接通率低（KPI指標(biāo)分析）1、統(tǒng)計(jì)各小區(qū)各時(shí)段的RRC接通率；2、找出影響RRC接通率的TOP10小區(qū)的對應(yīng)時(shí)段，統(tǒng)計(jì)該小區(qū)所有時(shí)段的RRC擁塞率和ISCP統(tǒng)計(jì)；3 、如果對應(yīng)時(shí)段存在擁塞率高的小區(qū)，可以根據(jù)CDL及告警信息進(jìn)一步確認(rèn)擁塞的真正原因，比如小區(qū)容量不夠、參數(shù)配置不合理或設(shè)備異常，根據(jù)具體原因進(jìn)行擴(kuò)容、參數(shù)調(diào)整或排障處理；4、如果小區(qū)的擁塞率不高，可以根據(jù)CDL、信令跟蹤或UE側(cè)LOG進(jìn)一步分析RRC建立失敗的原因，比如參數(shù)配置不合理、終端或網(wǎng)絡(luò)設(shè)備異常，根據(jù)具體原因參數(shù)調(diào)整或排障

16、處理。RRC接通率低（信令流程分析）1 檢查RRC接入失敗信令流程，判斷接入失敗發(fā)生在那個(gè)網(wǎng)元或交互過程中；2 是否為UE處理異常，如果是檢查UE是否發(fā)生異?；騌NC下發(fā)的配置消息是否不正確；3是否為NB處理異常，如果是檢查NB告警是否存在異常，或參數(shù)配置不合理導(dǎo)致；4 RNC如果沒有發(fā)送RRC Connection Setup或發(fā)送了RRC Connection Reject消息，請檢查下面列表內(nèi)容：1) 小區(qū)狀態(tài)、各載波、時(shí)隙狀態(tài)是否正常，碼資源是否充足；2) 上行時(shí)隙類型設(shè)置是否為合理，時(shí)隙預(yù)留是否設(shè)置；3) CAC算法中接納判決是否配置為碼判決；4) UE是否在DCH上接入5) 檢查帶

17、寬資源，導(dǎo)致的失敗,5 嘗試更換不同終端，更換載波接入，接入失敗的概率。2.2.3 RAB接通率分析（1） RAB過程分析RAB過程是指CN給RNC下發(fā)了RAB Assignment Request消息后，RNC給CN回RAB Assignment Response消息前，具體流程如下圖：從流程分析，RNC收到RNANP ASSIGNMENT REQ，會(huì)進(jìn)行如下的步驟：² RNC分配無線資源² RNC向NodeB發(fā)起無線鏈路重配置流程² RNC在空口上向UE發(fā)起RB SETUP流程² 在IU接口上回復(fù)RNANP ASSIGNMENT RSP消息給CN從以

18、上流程可以看出，影響RAB建立失敗的因素都會(huì)影響RAB指派的成功率指標(biāo)。（2） RAB連接建立失敗分析所有影響RAB建立失敗的因素都會(huì)影響RAB指派的成功率指標(biāo)，主要包括4部分：1、 RNC收到RAB指派消息后，立即返回RAB建議失敗，常見原因?yàn)镽NC內(nèi)部分配資源失??；2、 向NodeB發(fā)起無線鏈路重配置流程過程可能失敗，主要的現(xiàn)象一般是NodeB回復(fù)無線鏈路重配置失??；3、 RNC在空口上向UE發(fā)起RB SETUP流程，UE收不到或RNC收不到UE回復(fù)的重配置完成消息；Iu口Iuup建立或Gtpu建立過程失敗。（3） RAB連接建立CheckList檢查類別檢查項(xiàng)CS域RAB接通率（指標(biāo)分析

19、）1、統(tǒng)計(jì)各小區(qū)各時(shí)段的CS域RAB接通率2、找出影響CS域RAB接通率的TOP10小區(qū)的對應(yīng)時(shí)段，統(tǒng)計(jì)該小區(qū)所有時(shí)段的CS擁塞率和ISCP統(tǒng)計(jì)3、如果對應(yīng)時(shí)段存在CS域RAB擁塞率高的小區(qū)，可以根據(jù)CDL及告警信息進(jìn)一步確認(rèn)擁塞的真正原因，比如小區(qū)容量不夠、參數(shù)配置不合理或設(shè)備異常，根據(jù)具體原因進(jìn)行擴(kuò)容、參數(shù)調(diào)整或排障處理；4、如果小區(qū)的擁塞率不高，可以根據(jù)CDL、信令跟蹤或UE側(cè)LOG進(jìn)一步分析CS域RAB建立失敗的原因，比如參數(shù)配置不合理、網(wǎng)絡(luò)覆蓋、空口質(zhì)量、終端或網(wǎng)絡(luò)設(shè)備異常等原因，根據(jù)具體原因參數(shù)調(diào)整或排障處理。PS域RAB接通率（指標(biāo)分析）1、統(tǒng)計(jì)各小區(qū)各時(shí)段的PS域RAB接通率2

20、、找出影響PS域RAB接通率的TOP10小區(qū)的對應(yīng)時(shí)段，統(tǒng)計(jì)該小區(qū)所有時(shí)段的CS擁塞率和ISCP統(tǒng)計(jì)3、如果對應(yīng)時(shí)段存在PS域RAB擁塞率高的小區(qū)，可以根據(jù)CDL及告警信息進(jìn)一步確認(rèn)PS域RAB擁塞的真正原因，比如小區(qū)容量不夠、參數(shù)配置不合理或設(shè)備異常，根據(jù)具體原因進(jìn)行擴(kuò)容、參數(shù)調(diào)整或排障處理；4、如果小區(qū)的擁塞率不高，可以根據(jù)CDL、信令跟蹤或UE側(cè)LOG進(jìn)一步分析PS域RAB建立失敗的原因，比如參數(shù)配置不合理、終端或網(wǎng)絡(luò)設(shè)備異常，根據(jù)具體原因參數(shù)調(diào)整或排障處理。RAB接通率（信令流程分析）1 檢查RAB接入失敗信令流程，判斷接入失敗發(fā)生在那個(gè)網(wǎng)元或交互過程中；2 是否為UE處理異常，如果是

21、檢查UE處理異?；騌NC下發(fā)的配置消息不正確導(dǎo)致；3是否為NB處理異常，如果是檢查NB告警是否存在異常，或RNC參數(shù)配置不合理導(dǎo)致；4 RNC處理異常，請檢查下面列表內(nèi)容：1) 載波、時(shí)隙狀態(tài)是否正常，碼資源是否充足；2) 上行時(shí)隙類型設(shè)置是否為合理，時(shí)隙預(yù)留是否設(shè)置；3) CAC算法中各種接納算法設(shè)置是否合理；4) 對于PS業(yè)務(wù)，需要檢查PS算法和HSDPA算法中的門限設(shè)置是否合理5) 檢查IUCS、IUPS的數(shù)據(jù)鏈路配置是否正確；IUPS在IP方式下偶聯(lián)配置是否正確。5 嘗試更換不同終端，更換載波接入；PS用戶可以嘗試不同速率進(jìn)行接入。2.2.4 其他原因引起的接通率分析一些非RRC，RA

22、B類的接入失敗對網(wǎng)絡(luò)KPI指標(biāo)沒有影響。但是這些問題卻能導(dǎo)致路測指標(biāo)下降，影響用戶感知，同樣需要網(wǎng)絡(luò)優(yōu)化人員進(jìn)行解決，如下：檢查類別檢查項(xiàng)其他過程失敗1、非接入層消息交互失敗，根據(jù)信令跟蹤或UE LOG進(jìn)一步確認(rèn)失敗原因；2、安全模式控制過程失敗，分析是哪個(gè)網(wǎng)元返回的失敗消息，如果為CN或UE，需要進(jìn)一步根據(jù)消息確認(rèn)原因；如果是RNC拒絕SMC過程，需要根據(jù)信令跟蹤分別檢查CN和UE提供的加密和完保算法是否匹配。3 優(yōu)化前的網(wǎng)絡(luò)評估3.1 網(wǎng)絡(luò)分析3.1.1 KPI分析通過OMT提取最近一周的KPI進(jìn)行CS12.2K的接通率分析，情況如下：（1）趨勢分析日期CS12.2K無線接通率RRC連接建

23、立成功率（CS12.2K）RAB指派成功率（CS12.2K）2011-8-1999.42%99.55%99.87%2011-8-2099.36%99.49%99.87%2011-8-2199.35%99.50%99.85%2011-8-2299.44%99.54%99.89%2011-8-2399.43%99.55%99.88%2011-8-2499.41%99.53%99.87%2011-8-2599.38%99.50%99.88%全網(wǎng)的KPI情況從上表全網(wǎng)KPI情部，可以看到CS域RRC連接建立成功率均為99.52%左右，語音業(yè)務(wù)RAB指配建立成功率為99.87%左右，CS12.2K語音業(yè)

24、務(wù)無線接通率均為99.40%，且全國平均水平99.48%相差0.08%左右。指標(biāo)相差不大主要做好TOP 10小區(qū)的處理就可以達(dá)到平均水平。各RNC的KPI情況（一周時(shí)間）網(wǎng)元日期CS12.2K無線接通率RRC連接建立成功率（CS12.2K）RAB指派成功率（CS12.2K）26842011-8-1899.55%99.71%99.84%26842011-8-1999.49%99.60%99.88%26842011-8-2099.61%99.75%99.86%26842011-8-2199.40%99.63%99.77%26842011-8-2299.53%99.68%99.86%26842011

25、-8-2399.60%99.70%99.90%26842011-8-2499.46%99.56%99.90%26842011-8-2599.51%99.59%99.92%26852011-8-1899.41%99.55%99.86%26852011-8-1999.29%99.41%99.89%26852011-8-2099.25%99.47%99.78%26852011-8-2199.30%99.43%99.87%26852011-8-2299.39%99.51%99.88%26852011-8-2399.45%99.59%99.85%26852011-8-2499.37%99.49%99.8

26、8%26852011-8-2599.38%99.51%99.87%26862011-8-1899.31%99.46%99.84%26862011-8-1999.29%99.44%99.85%26862011-8-2099.28%99.42%99.86%26862011-8-2199.36%99.47%99.88%26862011-8-2299.37%99.51%99.86%26862011-8-2399.38%99.49%99.89%26862011-8-2499.32%99.44%99.88%26862011-8-2599.27%99.40%99.87%RNC2684的CS12.2K無線接通

27、率指標(biāo)很穩(wěn)定，且指標(biāo)水平維持全國平均中等。且RNC2685/2685CS12.2K無線接通率指標(biāo)有待提高0.12-0.08%，依據(jù)KPI指標(biāo)可以分析處主要是RRC接通率有些低引起的。且會(huì)重點(diǎn)優(yōu)化其指標(biāo)。（2）TOP N小區(qū)查找TOP N小區(qū)的KPI情況（一周時(shí)間）RNC標(biāo)識小區(qū)標(biāo)識小區(qū)語音RRC連接請求次數(shù)語音RRC連接建立失敗次數(shù)語音RRC連接建立成功率語音RAB連接請求次數(shù)語音RAB連接建立失敗次數(shù)語音RAB連接建立成功率DT_TD語音業(yè)務(wù)無線接通率268610952云城圍墩T2143695.80%1480100%95.80%268511943羅定市政廣場T3269797.40%27919

28、9.64%97.05%268611123云城云浮中專T34851397.32%4950100%97.32%268511823羅定華天龍制衣廠T3389897.94%384199.74%97.69%268610693云城高峰T3389798.20%377199.73%97.94%268610771云城科技局T1543798.71%573199.83%98.54%268610673云城翠石路T3638798.90%727199.86%98.77%268511272郁南柴場T2617798.87%6150100%98.87%268511911羅定農(nóng)行T1694798.99%7320100%98.99

29、%268610671云城翠石路T1886699.32%938399.68%99.01%268611071云城云龍村委T1640699.06%6720100%99.06%分析上表TOP N小區(qū)情況，發(fā)生CS域RRC連接建立成功率低的小區(qū)較多，而語音業(yè)務(wù)RAB指配建立成功率低的小區(qū)較少。（3）CDL分析應(yīng)用CDLMR工具對兩天的全網(wǎng)CDL進(jìn)行了分析，得出如下情況：RRC趨勢分析RNC ID總發(fā)起次數(shù)總失敗次數(shù)總失敗比例(%)268553630519300.36%268669321318790.27%26842445064090.17%RAB趨勢分析RNC ID總發(fā)起次數(shù)總失敗次數(shù)總失敗比例(%)2

30、6862169333860.18%26851692562440.14%268484728630.07%3.2 問題發(fā)現(xiàn)（CDLMR分析結(jié)果）3.2.1 主要問題分類通過上述KPI+CDL分析，可以發(fā)現(xiàn)部分RNC/小區(qū)都存在RRC/RAB指標(biāo)差或失敗的情況。通通過CDLMR工具分析得到的主要失敗原因及占比如下：（1）CS12.2K的RRC主要失敗原因及占比編號失敗原因失敗次數(shù)失敗原因比例(%)1RNC給NB發(fā)RL Setup后5秒內(nèi)又發(fā)RL Delete208449.41%21次RRC setup REQ無響應(yīng)(發(fā)送RRC Setup,收到RL Restore Indication)138232

31、.76%31次RRC setup REQ無響應(yīng)(發(fā)送RRC Setup, 未收到RL Restore Indication)43310.27%42次RRC setup REQ無響應(yīng)(發(fā)送RRC Setup, 未收到RL Restore Indication)2736.47%53次RRC setup REQ無響應(yīng)(發(fā)送RRC Setup, 未收到RL Restore Indication)330.78%64次RRC setup REQ無響應(yīng)(發(fā)送RRC Setup, 未收到RL Restore Indication)60.14%7超過4次RRC setup REQ無響應(yīng)(發(fā)送RRC Setup,

32、 未收到RL Restore Indication)50.12%81次RRC setup REQ無響應(yīng)(未發(fā)送RRC Setup, 未收到RL Restore Indication)10.02%92次RRC setup REQ無響應(yīng)(發(fā)送RRC Setup, 收到RL Restore Indication)10.02%從上表分析，RRC失敗原因?yàn)椤?次RRC Setup無響應(yīng)(未收到RL Restore Indication)”最多，此類問題原因較多，優(yōu)化工作中重點(diǎn)核查參數(shù)及基站側(cè)設(shè)備隱性故障；失敗原因?yàn)椤癛NC給NB發(fā)RL Setup后5秒內(nèi)又發(fā)RL Delete”次多，優(yōu)化工作中重點(diǎn)檢查無

33、線環(huán)境、設(shè)備告警及傳輸質(zhì)量。（2）CS12.2K的RAB主要失敗原因及占比編號失敗原因失敗次數(shù)失敗原因比例1RAB建立過程和CellUpdate并發(fā)173796.88%2RB Setup Failure:無效配置362.01%3RRM_ALLOCATE_RESOURCES_FAILURE:下行碼需求失敗120.67%4RRM_ALLOCATE_RESOURCES_FAILURE:上行碼需求失敗80.45%從上表分析，RAB失敗原因?yàn)椤癛B Setup Failure:無效配置”最多，優(yōu)化中重點(diǎn)檢查參數(shù)及RAB建立的信道屬性；失敗原因?yàn)椤癛NC給CN發(fā)了RAB Setup Failure(未出現(xiàn)

34、RRM_ALLOCATE_RESOURCES_FAILURE或其原因未知):其它失敗”次多，優(yōu)化中檢查RNC設(shè)備告警/資源情況和傳輸質(zhì)量；失敗原因?yàn)椤癛AB建立過程和CellUpdate并發(fā)”較多，優(yōu)化中檢查參數(shù)設(shè)置及無線境優(yōu)化。4 專題優(yōu)化內(nèi)容根據(jù)上述網(wǎng)絡(luò)優(yōu)化前的分析結(jié)果，此次專題優(yōu)化主要是對現(xiàn)網(wǎng)存在的問題，進(jìn)行分類優(yōu)化方法。優(yōu)化的順序?yàn)?，先進(jìn)行RRC接通率優(yōu)化，再是RAB接通率優(yōu)化，以及小區(qū)合并技術(shù)專項(xiàng)優(yōu)化手段。4.1 RRC接通率優(yōu)化4.1.1 RRC:RNC給NB發(fā)RL Setup后4秒內(nèi)又發(fā)RL DeleteKPI統(tǒng)計(jì)及CDLMR分析統(tǒng)計(jì)KPI統(tǒng)計(jì)： RNC標(biāo)識小區(qū)標(biāo)識小區(qū)語音RRC

35、連接請求次數(shù)語音RRC連接失敗次數(shù)會(huì)話類RRC連接建立成功率語音RAB連接請求次數(shù)會(huì)話類RAB連接建立成功率語音業(yè)務(wù)無線接通率268511272郁南柴場T2617798.87%615100%98.87%268511943羅定市政廣場T3269797.40%279100%97.40%268511823羅定華天龍制衣廠T3389897.94%384100%97.94%268610771云城科技局T1543798.71%573100%98.71%268610693云城高峰T33891795.63%37799.73%95.37%268511911羅定農(nóng)行T1694798.99%732100%98.99

36、%268611123云城云浮中專T34851397.32%495100%97.32%268610673云城翠石路T3638798.90%727100%98.90%問題現(xiàn)象在對日常KPI接通指標(biāo)進(jìn)行分析時(shí)，發(fā)現(xiàn)如上小區(qū)的RRC建立成功率很低，嚴(yán)重影響上全網(wǎng)語音的業(yè)務(wù)接通率指標(biāo)，從統(tǒng)計(jì)來看，這些小區(qū)失敗次數(shù)占了總RRC失敗次數(shù)的18%左右。CDL信令分析如下：分析定位思路通過分析CDL發(fā)現(xiàn)，rnc能下發(fā)RRC CONNETION SETUP ，但是沒有收到UE的RRC CONNECTION SETUP COMMPLETE 消息。根據(jù)現(xiàn)象初步懷疑可能存在二種情況導(dǎo)致RRC發(fā)RRC CONNETION

37、 SETUP，但是沒有收到UE的RRC CONNECTION SETUP COMMPLETE 消息。1、 一種由于無線環(huán)境。UE未收到RRC CONNETION SETUP。2、 RNC發(fā)出RRC CONNETION SETUP后NB透傳的時(shí)候，由于基站設(shè)備故障導(dǎo)致沒有發(fā)出去。針對兩種情況進(jìn)行分析，現(xiàn)網(wǎng)測試中也發(fā)現(xiàn)了這種的現(xiàn)象；SPAN Outum中表現(xiàn)為RCSP很好，SIR也很好，但是UE測顯示為上發(fā)RRC Connection Request，之后無響應(yīng)；對應(yīng)CDL中觀察RNC此時(shí)確實(shí)已經(jīng)下發(fā)了RRC CONNETION SETUP，基本可以確定是NB的原因。根據(jù)上面的推理結(jié)果，懷疑NB某

38、個(gè)單元可能出現(xiàn)問題；聯(lián)系基站組的同事，查看43號日志，發(fā)現(xiàn)無線鏈路建立后，APB不斷的向APS 報(bào)編號為23449的告警，如下：一直在做無線鏈路建立和刪除，g_u8ApsRecMsgCycle0     Time:  2011-8-25  11:26:4    SFN: 3768    Opcode: O_APBAPS_ALARM_INFO    u16AlarmNo=23449    u8AlarmValue=25

39、5    u8AlarmClearFlag=0    u16RepeatTimes=1    s8Content=File:/apb_pi_dedi_meas_rpt.c,Line:187, Key Parameters:32344,_g_u8ApsRecMsgCycle1     Time:  2011-8-25 11:26:4    SFN: 3788    Opcode: O_APBAPS_

40、ALARM_INFO    u16AlarmNo=23449    u8AlarmValue=255    u8AlarmClearFlag=0    u16RepeatTimes=1    s8Content=File:/apb_pi_dedi_meas_rpt.c,Line:187, Key Parameters:32344,_g_u8ApsRecMsgCycle2     Time:  20

41、11-8-25  11:26:5    SFN: 3808    Opcode: O_APBAPS_ALARM_INFO    u16AlarmNo=23449    u8AlarmValue=255    u8AlarmClearFlag=0    u16RepeatTimes=1    s8Content=File:/apb_pi_dedi_meas_rpt.c,Line:

42、187, Key Parameters:32344,分析：1、上面告警顯示無線鏈路建立、刪除都是正常的，出現(xiàn)這個(gè)告警是因?yàn)镻L上報(bào)專用測量值越界2、但是關(guān)鍵的問題是，rnc下發(fā)的RRC CONNECTION SETUP消息后，基站側(cè)有沒有丟包？也就是要確定fach是否有丟包的可能。然后看了一下這個(gè)站的43號日志，從上午8點(diǎn)到12點(diǎn)，總共刪除了400多次無線鏈路； 3、現(xiàn)在的問題是這是有人為的，有目的的反復(fù)刪建無線鏈路，還是RNC自動(dòng)要求基站刪建無線鏈路。4、分析了dsp日志，發(fā)現(xiàn)OM配置的天線類型不正確，導(dǎo)致FC記錄的天線位置有誤。根據(jù)dsp日志顯示的天線類型不正確作為切入點(diǎn)進(jìn)行了分析，提取O

43、M下24號日志中記錄的OMFC_PARA_UPDATE消息，查看配置， BBU的24號日志顯示.ant_type=0x0002，F(xiàn)C認(rèn)為這種配置是有問題的，原來的天線配置是只有0和1，但后來在天線參數(shù)表中確實(shí)加了極化陣2（antArrayType），但PL只接受線陣0和圓陣1的取值，這就說明即使OM將ant_type配成了2，物理層也是按照線陣0或者是1來處理的，優(yōu)化解決措施修改了天線方位角，然后“生成動(dòng)態(tài)配置文件antenna.cfg復(fù)位基站”通過這種方法此類問題可以得到規(guī)避，觀察修改了配置文件后的站點(diǎn)，均已恢復(fù)正常。4.1.2 RRC: 1次RRC Setup無響應(yīng)(未收到RL Resto

44、re Indication)KPI統(tǒng)計(jì)及CDLMR分析統(tǒng)計(jì)KPI統(tǒng)計(jì)： RNC標(biāo)識小區(qū)標(biāo)識小區(qū)語音RRC連接請求次數(shù)語音RRC連接失敗次數(shù)會(huì)話類RRC連接建立成功率語音RAB連接請求次數(shù)會(huì)話類RAB連接建立成功率語音業(yè)務(wù)無線接通率268610952云城圍墩T2143695.80%148100%95.80%268611071云城云龍村委T1640699.06%672100%99.06%268610952云城圍墩T2143695.80%148100%95.80%268511342郁南舊永光大酒店T2231597.84%218100%97.84%268511852羅定舊車站T2475598.95%5

45、02100%98.75%268611041云城英東體育館T1224597.77%236100%97.77%268610773云城科技局T3392598.72%402100%98.48%268611022云城興云西路T2308598.38%332100%98.38%268611071云城云龍村委T1640699.06%672100%99.06%268511882羅定龍園T2821599.39%86599.88%99.28%問題現(xiàn)象TMSI號為：4807f8ce的用戶，通過RNC2686小區(qū)10651云城初城工業(yè)區(qū)T1進(jìn)行接入申請，出現(xiàn)RRC Setup無響應(yīng)（未收到RL Restore Indi

46、cation）。情況如下圖：分析定位思路從圖上看RNC下發(fā)了RRC CON SETUP消息，但沒有收到UE返回的完成消息，UE多次發(fā)起RRC Connection Request請求，但RRC完成消息一直沒有上來，導(dǎo)致上行不能同步，Uu定時(shí)器超時(shí)后，RL被刪除。（注：CDL中同一UE在同小區(qū)同時(shí)段上報(bào)的RRC Connection Request消息只顯示一個(gè)）這種現(xiàn)象有3種可能：1）UE沒有收到；2）UE收到了沒有回響應(yīng)；3）UE返回的完成消息沒有發(fā)送的RNC。分析如下：1） UE沒有收到RRC CON SETUP消息，這種情況可能是NB存在FACH未下發(fā)或無線環(huán)境影響，干擾或其他因素，導(dǎo)致

47、FACH數(shù)據(jù)終端未收到。此種情況下，RRC建立成功率比較低，UE一般再次重新接入或者過段時(shí)間再次接入可能會(huì)成功。此類問題檢查的方法可以通過LMT-B檢查告警，看看是否存在異常告警，另外，可以根據(jù)FACH和RACH計(jì)數(shù)器的計(jì)數(shù)變化情況來進(jìn)一步分析基站側(cè)有無成功將RNC下發(fā)的RRC Connection Setup消息下發(fā)到空口；同時(shí)檢查空口信號、C/I以及-B上是否存在異常告警。上圖LOG顯示UE重發(fā)RRC請求間隔很短，故這種可能性最大。云城初城工業(yè)區(qū)T1下行覆蓋和干擾情況正常，可以排查此類原因?；竟收锨闆r為：無故障，也可以排查此類原因。RNC IDCell ID小區(qū)名站型管理狀態(tài)8-25運(yùn)行

48、狀態(tài)8-25故障情況268610651云城初城工業(yè)區(qū)T1EMB5116激活正常無2） UE收到了RRC CON SETUP消息沒有回響應(yīng)，可能是終端異常導(dǎo)致。從CDLMR分析結(jié)果可知，在這小區(qū)里有多個(gè)用戶出現(xiàn)此問題，且都不是同一廠商的終端，故也可以排除與終端有關(guān)。3）UE返回的RRC Connection Setup Complete消息沒有發(fā)送的RNC，需要檢查空口信號，看看RSCP、C/I、UE發(fā)射功率等參數(shù)是否存在異常，或跟蹤終端底層LOG，察看終端側(cè)LOG上UE是否收到RNC返回的確認(rèn)幀，如果收到，說明該消息是在RNC內(nèi)部丟失，需要RNC進(jìn)一步定位；也可以在NB上抓取消息收發(fā)，檢查NB

49、是否有數(shù)據(jù)發(fā)送、出窗等告警；如果RRC建立在DCH上，可能UE沒有與基站建立同步，可以嘗試修改空閑模式的T312，將該參數(shù)配置的大一些。云城初城工業(yè)區(qū)T1上行干擾情況正常，也可以排查此類原因。ISCP:RNC標(biāo)識小區(qū)標(biāo)識載波標(biāo)識CELL 標(biāo)識載頻值TS1平均干擾TS1最大干擾TS2平均干擾TS2最大干擾2686106511云城初城工業(yè)區(qū)T110096-108.361-81-108.699-872686106512云城初城工業(yè)區(qū)T110120-108.247-81-108.448-842686106513云城初城工業(yè)區(qū)T210112-108.184-80.5-108.225-85.5268610

50、6514云城初城工業(yè)區(qū)T310071-107.806-81-107.911-852686106515云城初城工業(yè)區(qū)T410088-108.193-78.5-108.252-842686106516云城初城工業(yè)區(qū)T510080-108.166-82.5-108.232-78.5UP:RNC標(biāo)識小區(qū)標(biāo)識小區(qū)Up0平均干擾Up0最大干擾Up53平均干擾Up53最大干擾Up107平均干擾Up107最大干擾268610651云城初城工業(yè)區(qū)T1-108.542-107-108.862-102-110.547-105.5排查了上下行干擾、設(shè)備故障等問題后，對云城初城工業(yè)區(qū)T1進(jìn)行了相關(guān)接入?yún)?shù)的核查，沒發(fā)現(xiàn)

51、異常，從資源角度分析發(fā)現(xiàn)，RRC Setup無響應(yīng)用戶均占此小區(qū)的10096頻點(diǎn)。UE IDRNC ID接入小區(qū)接入頻點(diǎn)TS1碼道分配TS3碼道分配失敗原因38334268610651100968/7;16/15;16/16;RRC Setup無響應(yīng)37718268610651100968/7;16/1;16/2;RRC Setup無響應(yīng)37677268610651100968/7;16/11;16/12;RRC Setup無響應(yīng)37076268610651100638/7;16/15;16/16;RRC Setup無響應(yīng)32813268610651100638/7;16/1;16/2;RRC

52、 Setup無響應(yīng)37601268610651100638/7;16/9;16/10;RRC Setup無響應(yīng)32875268610651100638/7;16/11;16/12;RRC Setup無響應(yīng)33132268610651100638/7;16/13;16/14;RRC Setup無響應(yīng)33165268610651100638/7;16/15;16/16;RRC Setup無響應(yīng)這樣可以判斷問題與基站側(cè)相關(guān)載波/DSP工作狀態(tài)有關(guān)。優(yōu)化解決措施通過LMT-B查看，基站側(cè)沒有任何告警。測試工程師到現(xiàn)場驗(yàn)證測試，后臺側(cè)信令跟蹤可以收到UE發(fā)上來的“RRC Connection Request”，且RNC下發(fā)了“RRC Connection Setup”消息，但UE卻始終沒收到，判斷為DSP隱性問題，通知基站工程師更換相應(yīng)BPOF后，問題解決。上圖為恢復(fù)后的信令截圖4.2 RAB接通率優(yōu)化4.2.1 RAB: RAB建立過程和CellUpdate并發(fā)KPI統(tǒng)計(jì)及CDLMR分析統(tǒng)計(jì)KPI統(tǒng)計(jì)cdl分析： RNC標(biāo)識小區(qū)標(biāo)識小區(qū)語音RRC連接請