KPI指標(biāo)提升RRC建立成功率篇電子版本

1、Good is good, but better carries it.精益求精，善益求善。KPI指標(biāo)提升RRC建立成功率篇-HYPERLINKRRC建立成功率提升（作者：南京KPI提升團(tuán)隊(duì)）BuildExcellentTD-SCDMANetwork概述本文檔主要用于指導(dǎo)KPI提升中對(duì)RRC建立成功率指標(biāo)的提升，對(duì)于RRC建立中常見的問題進(jìn)行分析并給出定位思路和解決方案，用于提升RRC建立成功率。背景知識(shí)正常情況下，RRC過程的典型流程圖如下：定位思路使用CDLMR對(duì)一個(gè)RNC下的CDL進(jìn)行分析，找到該下在該小區(qū)下進(jìn)行小區(qū)詳細(xì)跟蹤或者收集問題小區(qū)的文件，對(duì)照典型流程確認(rèn)問題出現(xiàn)在那一步，然后進(jìn)

2、入不同的分析流程。節(jié)號(hào)判斷條件判斷條件為是的處理方法判斷條件為否的處理方法3.1信令跟蹤（或者文件）未看到RRCCONNECTIONREQUEST進(jìn)入“未收到RRCCONNECTIONREQUEST的定位”一節(jié)進(jìn)入.2節(jié)3.2信令跟蹤（或者文件）中看到RRCCONNECTIONREQUEST消息，但是未看到RADIOLINKSETUPREQUEST消息進(jìn)入“未發(fā)送RADIOLINKSETUPREQUEST的定位”一節(jié)進(jìn)入.節(jié)；3.3信令跟蹤（或者文件）中看到未發(fā)送RRCCONNECTIONSETUP消息進(jìn)入“發(fā)送RRCCONNECTIONREJECT定位”一節(jié)進(jìn)入.節(jié)3.4信令跟蹤（或者文件）

3、中看到發(fā)送RRCCONNECTIONSETUP消息，但是基站的沒有增加進(jìn)入“未收到RRCCONNECTIONSETUP消息”一節(jié)進(jìn)入.節(jié)3.5未收到基站上報(bào)的RADIOLINKRESTOREINDICATION進(jìn)入“未收到RADIOLINKRESTOREINDICATION的定位”一節(jié)進(jìn)入.節(jié)3.6信令跟蹤（或者文件）中收到RADIOLINKRESTOREINDICATION消息，但未收到終端返回的RRCCONNECTIONSETUPCOMPLETE進(jìn)入“未收到RRCCONNECTIONSETUPCOMPLETE的定位”一節(jié)無定位方法未收到RRCCONNECTIONREQUEST的定位首先判斷

4、小區(qū)狀態(tài)，小區(qū)狀態(tài)為非激活態(tài)，進(jìn)行小區(qū)故障的定位過程，定位方法不在本文檔范圍，小區(qū)狀態(tài)為激活狀態(tài)（一般用戶應(yīng)該可以駐留在該小區(qū)），后續(xù)定位轉(zhuǎn)入4.1.2；用戶在問題小區(qū)進(jìn)行撥打測(cè)試，對(duì)象樹-邏輯頻點(diǎn)-查詢載波性能隨即接入情況統(tǒng)計(jì)查詢FPACH響應(yīng)數(shù)目是否一直增加（見圖4.1.2-1），如果計(jì)數(shù)不增加。需要檢查以下兩項(xiàng)，F(xiàn)PACH響應(yīng)數(shù)目正常增加轉(zhuǎn)入4.1.3；考慮隨機(jī)接入功率配置問題：查看網(wǎng)絡(luò)側(cè)設(shè)置SYNC_UL的期望接收功率大小，過小則會(huì)影響基站SYNC_UL的接收性能，一般經(jīng)驗(yàn)值設(shè)置90dbm；查看FPACH的發(fā)送功率設(shè)置大小，一般設(shè)置低于PCCPCH功率3db；確認(rèn)設(shè)備運(yùn)行正常，小區(qū)布配

5、正確圖4.1.2-1SYNC_UL統(tǒng)計(jì)查詢方法在基站側(cè)和RNC側(cè)進(jìn)行RACH計(jì)數(shù)統(tǒng)計(jì)，基站側(cè)RACH計(jì)數(shù)統(tǒng)計(jì)進(jìn)行的收發(fā)統(tǒng)計(jì)抓取方法見“4.3.1節(jié)基站抓取”；側(cè)統(tǒng)計(jì)方法：在測(cè)小區(qū)所在的上抓取rnc_tpss_cell_statis_query（CellID，0），其中“ulCchFpRachRecvDataCntr”為計(jì)數(shù)；小區(qū)所在的確認(rèn)：可以通過查詢動(dòng)態(tài)表rDanytableCellId中對(duì)應(yīng)小區(qū)的RTPADSP地址，確定小區(qū)所DSP。在計(jì)算小區(qū)所在單板和DSP方法：ulRTPABoardDSPAddr:2198274349=0 x8307012D,12D就是1-2-13單板；07就是DSP

6、ID。一般基站有增加的話，的也是有增加的，如果基站的有增加，但是側(cè)RACH眉頭增加，進(jìn)入.1.4提取基站的公共日志和主控板所有日志（SCT/CCU）交由基站產(chǎn)品維護(hù)人員分析后，決定如何定位。未發(fā)送RADIOLINKSETUPREQUEST的定位這種情況一般是資源分配失敗，RNC會(huì)發(fā)送RRCCONNECTIONREJECT消息給終端，失敗原因常見的是無線資源和本地資源兩種，定位此類問題需要在中找到對(duì)應(yīng)小區(qū)建立失敗的用戶信令，一般在RRCCONNECTIONREQUEST消息后有一條資源分配失敗的消息RRM_DCA_RESOURCES_ALLOCATION_FAILURE，根據(jù)消息中的EventP

7、ara字段查詢“錯(cuò)誤碼表”給出的失敗原因進(jìn)一步定位，常見的原因有：上下行碼資源判決失敗/上行獨(dú)立載波判決失敗下行獨(dú)立載波判決失?。▽?duì)應(yīng)的EventPara為0 x080100060 x08010007/0 x080100110 x08010012）：檢查該小區(qū)下各載波狀態(tài)和小區(qū)用戶情況，如果載波狀態(tài)正常，在線用戶數(shù)所占用的資源總合小于小區(qū)總的無線資源，需要檢查和算法設(shè)置是否合適，無異常的話收集出現(xiàn)失敗的側(cè)文件、小區(qū)詳細(xì)跟蹤、配置數(shù)據(jù)發(fā)給產(chǎn)品維護(hù)團(tuán)隊(duì)基站組組分析；如果載波狀態(tài)異常，需要收集基站的公共日志和CCU的43、22000號(hào)日志發(fā)給產(chǎn)品維護(hù)團(tuán)隊(duì)基站組分析“載波故障的原因”。上行ATM資源判

8、決失敗下行ATM資源判決失敗上行下行ATM資源判決都失敗，需要檢查該小區(qū)所在基站的數(shù)據(jù)鏈路參數(shù)配置中的帶寬資源配置是否合適,一般情況一個(gè)載波大概對(duì)應(yīng)2M的ATM資源,因此5載波小區(qū)應(yīng)該有10M的數(shù)據(jù)鏈路帶寬資源,如果和這個(gè)數(shù)據(jù)差距比較大的話,可能會(huì)出現(xiàn)這種帶寬資源判決失敗的情況；其他EventPara取值不常見，出現(xiàn)的話提供文件，數(shù)據(jù)配置文件發(fā)給產(chǎn)品維護(hù)團(tuán)隊(duì)分析定位；發(fā)送RRCCONNECTIONREJECT定位（假擁塞）查看失敗用戶收集文件，對(duì)應(yīng)小區(qū)下已經(jīng)有RADIOLINKSETUPREQUEST消息，但是還是發(fā)送有RRCConnectionReject消息，此情況屬于一種假擁塞的情況，根

9、據(jù)消息中給出的EventPara查詢“錯(cuò)誤碼表”，根據(jù)錯(cuò)誤碼表給出的原因進(jìn)一步定位。0 x09070100/0 x090701002(FP配置過程中節(jié)點(diǎn)同步失敗(發(fā)送到最大次數(shù))FP配置過程中傳輸信道同步失敗(發(fā)送到最大次數(shù))如果RRCConnectionReject消息消息中給出的錯(cuò)誤碼為“0 x09070100/0 x090701002”，一般情況下是0 x09070100，那么就是節(jié)點(diǎn)（傳輸信道）同步失敗導(dǎo)致的RRC建立失敗。這種情況實(shí)際目前沒有好的定位方案,只有在比較容易復(fù)現(xiàn)時(shí)可以定位,總的思路是在和基站作一些信息收集，發(fā)給產(chǎn)品團(tuán)隊(duì)進(jìn)行數(shù)據(jù)分析，確認(rèn)問題出在還是基站具體方法見下:確認(rèn)問

10、題小區(qū)所在的接口板架框槽信息以及小區(qū)數(shù)據(jù)鏈路對(duì)應(yīng)的PVC信息和信息。圖一為承載方式，位置在“承載集”“信息集”問題小區(qū)對(duì)應(yīng)的數(shù)據(jù)鏈路。圖一承載方式數(shù)據(jù)鏈路信息圖二為承載方式，位置在“承載集”“協(xié)議棧子層”問題小區(qū)對(duì)應(yīng)通道。進(jìn)行小區(qū)詳細(xì)跟蹤，確認(rèn)由于節(jié)點(diǎn)同步失敗導(dǎo)致RRC建立失敗用戶所在DSP，找到RRCCONNECTIONREQUEST消息下倒數(shù)第二條RDBS_RDBS_LC_ALLOCATE_RSP_MSG，該消息種給出了用戶分配的RTPA的架框槽和DSP信息。使用測(cè)試診斷命令進(jìn)行RTPA和接口板之間的媒體面連通性測(cè)試，其中RTPA的架框槽和DSP信息就是（2）中得到的信息，接口板的架框槽信

11、息是（1）中得到的，CPU選擇2。多進(jìn)行測(cè)試，如果測(cè)試不通過的話，需要檢查RTPA和接口板之間的物理連接，但是物理連接出問題的情況還是比較少的。媒體面連通性測(cè)試正常的話，說明RTPA到接口板之間的數(shù)據(jù)通道正常，需要進(jìn)入（4）繼續(xù)定位；如果以上排查后仍不能確認(rèn)問題所在，需要抓取LOG給研發(fā)定位，RNC側(cè)需要利用腳本生成工具生成一些腳本，運(yùn)行(6)節(jié)插件中給出的腳本生成工具，并按照（1）中給出的單板信息或者局內(nèi)VPI，VCI信息（ATM方式），VLANID，端口號(hào)（IP方式）信息，這樣在腳本生成工具所放目錄會(huì)生成一個(gè)腳本批處理文件。比如：1-2-1-2_CASA_script.txt。RNC側(cè)LO

12、G抓?。?jiǎn)栴}出現(xiàn)前RNC側(cè)小區(qū)所在執(zhí)行1-2-1-2_CASA_script.txt同時(shí)進(jìn)行小區(qū)詳細(xì)跟蹤，在問題復(fù)現(xiàn)后再次執(zhí)行該腳本?；緶y(cè)試LOG抓?。禾崛』镜墓踩罩竞椭骺匕逅腥罩菊页龉?jié)點(diǎn)同步失敗的頻點(diǎn)在基站上對(duì)應(yīng)的DSP，使用LMT-B連接基站，對(duì)象樹-小區(qū)資源-查詢載波FP信息，查看節(jié)點(diǎn)同步失敗的DSP的計(jì)數(shù)，多次查詢，查看本地頻點(diǎn)收到的節(jié)點(diǎn)同步幀和收到后回給RNC的節(jié)點(diǎn)同步幀數(shù)目上是否對(duì)應(yīng)。信令跟蹤中獲取用戶RRC信令所建立的數(shù)據(jù)鏈路或IP通道信息的方法：進(jìn)行小區(qū)詳細(xì)跟蹤，確認(rèn)用戶建立RRC時(shí)分配的PATH和CID或者，找到RADIOLINKSETUPRESPONSE消息下的一條

13、TNSS_NF_ESTABLISH_REQ消息，其中攜帶了需要的信息，其中圖三為承載方式，圖四為方式。圖三承載方式的數(shù)據(jù)鏈路信息圖四承載的通道信息運(yùn)行腳本生成工具錯(cuò)誤碼為其它取值當(dāng)失敗原因?yàn)槠渌≈禃r(shí)，主要可能和RNC相關(guān)，此時(shí)需要進(jìn)行信令跟蹤，并對(duì)應(yīng)失敗時(shí)刻收集CDL文件和運(yùn)行日志。從運(yùn)行日志和CDL中進(jìn)一步分析深層原因。終端未收到RRCCONNECTIONSETUP的定位由于RNC側(cè)層二配置已經(jīng)成功，此時(shí)終端沒有收到RRCCONNECTIONSETUP消息此時(shí)首先從基站側(cè)查詢確定基站是否收到RRCCONNECTIONSETUP,查詢方法見4.4.1查詢小區(qū)主頻點(diǎn)的RACH、FACH計(jì)數(shù)對(duì)象

14、樹-小區(qū)資源-邏輯頻點(diǎn)-查詢小區(qū)的FACH。信息，隔幾S刷新一次，查看RACH增加過程中，F(xiàn)ACH是否有增加。IUB口問題的可能性比較少，如果有增加，說明RNC正常下發(fā)了，此時(shí)如果UE沒有收到，需要按照4.4.2節(jié)查看空口的問題,如果沒有增加,需要提取基站告警日志,RNC側(cè)信令跟蹤,并按照4.3.1節(jié)的方法生成腳本文件在接口板上執(zhí)行(問題出現(xiàn)前和出現(xiàn)后各執(zhí)行1次).將發(fā)給產(chǎn)品維護(hù)團(tuán)隊(duì)定位檢查空口問題首先需要從RRCCONNECTIONREQUEST消息中確定該用戶所在為位置和接入時(shí)刻的PCCPCHRSCP，消息中給出的是協(xié)議值，真實(shí)值和協(xié)議值的換算關(guān)系是：真實(shí)值=協(xié)議值-116如果真實(shí)值小于-

15、95的話，有可能和弱覆蓋有關(guān)，此時(shí)需進(jìn)一步提取該小區(qū)下的ISCP報(bào)表，因?yàn)樯舷滦袩o線環(huán)境一般是一致的，因此上行時(shí)隙ISCP可以作為一個(gè)參考。未收到RADIOLINKRESTOREINDICATION的定位此時(shí)基站沒有檢測(cè)到上行同步數(shù)據(jù)，需要收集該需要基站進(jìn)一步定位提取基站公共日志和業(yè)務(wù)失敗頻點(diǎn)對(duì)應(yīng)的DSP所在板卡的50號(hào)日志。提供業(yè)務(wù)失敗的CRNC_CCID，發(fā)給基站產(chǎn)品維護(hù)定位。未收到RRCCONNECTIONSETUPCOMPLETE的定位已經(jīng)完成節(jié)點(diǎn)同步，說明終端收到了RRCCONNECTIONSETUP消息，這種情況一種可能是終端發(fā)生了系統(tǒng)間或者系統(tǒng)內(nèi)的小區(qū)重選，目前這種情況僅僅對(duì)于用

16、戶發(fā)生了內(nèi)的小區(qū)重選可以定位，其它兩種情況因?yàn)樯婕暗狡渌黂NC和GSM,因此暫時(shí)沒辦法定位.具體定位方法見.6.1,如果還是無法定位，那么按照.6.2給出的方法進(jìn)行LOG收集.終端重選到其它這個(gè)主要從CDL文件中分析,看看在終端出現(xiàn)問題的時(shí)間點(diǎn)后是否有相同的TMS/IMSI的RRCCONNECTIONREQUEST消息,例如下面從CDL的LOG可以看出：第一次RRC請(qǐng)求，網(wǎng)絡(luò)已經(jīng)收到，UE連接建立原因：OriginatingConversationalCall；Iub資源已經(jīng)建好，并且下發(fā)FACH，其中FACH中攜帶的期望接收上行功率-102dbm；這里REQ測(cè)量的PCCPCH_RSCP是25；而40秒后，UE換小區(qū)在6692小區(qū)的RACH測(cè)量上報(bào)PCCPCH_RSCP是17，發(fā)生小區(qū)重選，同一時(shí)間RNC刪除27661小區(qū)Iub資源；在6692小區(qū)又重選到27661小區(qū)發(fā)起接入，在27661小區(qū)接入成功。一般這種情況需要檢查小區(qū)下的小區(qū)選擇和重選參數(shù)設(shè)置不合適:小區(qū)選擇與重選-同頻小區(qū)測(cè)量門限；小區(qū)選擇與重選-異頻小區(qū)測(cè)量門限；小區(qū)選擇與重選-Gs