【文章內(nèi)容簡(jiǎn)介】 0:0015分鐘長(zhǎng)島飯店_1020120100408 10:00:0015分鐘長(zhǎng)島飯店_1020220100408 10:00:0015分鐘長(zhǎng)島飯店_1020320100408 10:15:0015分鐘長(zhǎng)島飯店_1020110820100408 10:15:0015分鐘長(zhǎng)島飯店_1020210510620100408 10:15:0015分鐘長(zhǎng)島飯店_1020320100408 10:30:0015分鐘長(zhǎng)島飯店_1020110810820100408 10:30:0015分鐘長(zhǎng)島飯店_1020220100408 10:30:0015分鐘長(zhǎng)島飯店_10203107對(duì)于一些主要是因congestion原因?qū)е碌腞RC連接失敗率高的小區(qū)，或UP干擾嚴(yán)重的小區(qū)，通過(guò)本案例，應(yīng)考慮到該小區(qū)所在基站下掛TD微波拉遠(yuǎn)系統(tǒng)的情況，如果基站是否下掛了TD微波拉遠(yuǎn)系統(tǒng)，且近端機(jī)掉電，而遠(yuǎn)端機(jī)工作的話，可能會(huì)導(dǎo)致該基站所有小區(qū)出現(xiàn)嚴(yán)重UP干擾，從而導(dǎo)致RRC連接失敗congestion，影響接通率指標(biāo)。. RRC連接失敗unspecifiedRRC連接失敗unspecified 是3GPP ，一旦RNC通過(guò)了CAC的驗(yàn)證，RNC會(huì)請(qǐng)求Node B配置相應(yīng)的無(wú)線鏈路資源，一般情況下最少建立一條無(wú)線鏈路，RNC發(fā)送RadioLinkSetupRequest，在這個(gè)過(guò)程中，由于各種不同的原因造成的RadioLinkSetupFailure，RNC將給UE發(fā)送rrcConnectionReject，原因值為TRRC_unspecified，造成RRC連接請(qǐng)求失敗，由于該問題的誘因出現(xiàn)在RadioLinkSetup階段，因此該問題一般不會(huì)發(fā)生在空口，而在RNC至NodeB一段。引起RRC連接失敗unspecified的原因概括起來(lái)主要有三類：傳輸資源不足：E1承載不足導(dǎo)致的接納失敗，不僅在RAB指派過(guò)程中發(fā)生，在RRC連接過(guò)程中也可能發(fā)生，即E1既會(huì)影響RRC建立指標(biāo)，也會(huì)影響到RAB指派的指標(biāo)。傳輸不穩(wěn)定：傳輸不穩(wěn)定很有可能造成RRC建立失敗，一般情況下也伴隨著RAB建立失敗。小區(qū)單板故障：由于小區(qū)單板故障，有可能會(huì)引起板間丟包，需要更換單板，而載頻板的問題直接會(huì)影響到無(wú)線鏈路的建立。在TD異常話務(wù)工作中，RRC連接失敗unspecified的情況不是很多，下面首先對(duì)RRC連接失敗unspecified的信令流程進(jìn)行分析，再提供該問題的解決思路。其信令流程截圖如下：根據(jù)信令流程也就是說(shuō)出現(xiàn)RL Setup Failure的現(xiàn)象，才會(huì)出現(xiàn)這種情況。其信令所在階段如下圖中注釋部分標(biāo)記所示。根據(jù)RRC連接失敗unspecified的信令流程，結(jié)合長(zhǎng)沙公司在TD異常話務(wù)工作中遇到的情況，總結(jié)起來(lái)提供該問題的解決思路如下： 傳輸資源不足由于傳輸資源不足導(dǎo)致的RRC連接失敗unspecified，判定依據(jù)是信令上RRC建立過(guò)程中RL Setup Response后10ms左右就刪除RL，同時(shí)結(jié)合基站的E1數(shù)量、指標(biāo)中RAB建立失敗Iub bear_Operate fail次數(shù)，可共同判定是否由于E1擁塞導(dǎo)致的RRC Reject。遇到這種問題，需要通過(guò)傳輸擴(kuò)容，網(wǎng)絡(luò)整改等方法來(lái)解決。 傳輸不穩(wěn)定從信令上看，傳輸不穩(wěn)定導(dǎo)致的RRC連接失敗unspecified的信令特征是Node B給RNC回復(fù)RL Setup Response后，在5s左右直接進(jìn)行RL刪除。這種問題一般伴隨有傳輸告警，可以通過(guò)站點(diǎn)是否有傳輸告警，例如E1 IMA組處于非工作狀態(tài)（198081122）等，不但是看當(dāng)前告警，更重要的是看歷史告警，傳輸閃斷的故障對(duì)指標(biāo)影響更大，傳輸異常、傳輸瞬斷導(dǎo)致ERQ/ECF協(xié)商失敗，5S定時(shí)器超時(shí)后直接刪除鏈路。遇到這種問題，立即通知維護(hù)部門處理告警。 小區(qū)單板故障從信令上看，RNC下發(fā)RL Setup Response后，Node B直接回復(fù)RL Setup Fail，可以通過(guò)Node B內(nèi)部命令統(tǒng)計(jì)，確認(rèn)Node B控板與基帶板之間是否丟包。目前發(fā)現(xiàn)丟包的有TBPE、TBPH、SBMP，如果確認(rèn)丟包，可以直接更換單板。長(zhǎng)沙曾經(jīng)出現(xiàn)過(guò)由于小區(qū)單板故障產(chǎn)生的RRC連接失敗unspecified問題，如案例4所示。u 案例4 ：平安大廈TD小區(qū)RRC連接失敗案例2010年8月長(zhǎng)沙公司網(wǎng)優(yōu)中心發(fā)現(xiàn)CSZXR12_1314_平安大廈存在RRC連接失敗unspecifed的現(xiàn)象，并且據(jù)統(tǒng)計(jì)一直存在，并伴隨有Iub接口無(wú)線鏈路建立失敗，經(jīng)過(guò)網(wǎng)管統(tǒng)計(jì)如下：時(shí)間NODEBIub接口無(wú)線鏈路建立失敗個(gè)數(shù)，綜合原因 Hardware failureRRC連接失敗計(jì)數(shù)器，unspecified20100801CSZXR12_1314_平安大廈534920100802CSZXR12_1314_平安大廈242320100803CSZXR12_1314_平安大廈715720100804CSZXR12_1314_平安大廈211920100805CSZXR12_1314_平安大廈804820100806CSZXR12_1314_平安大廈403020100807CSZXR12_1314_平安大廈121120100808CSZXR12_1314_平安大廈433920100809CSZXR12_1314_平安大廈383020100810CSZXR12_1314_平安大廈231920100811CSZXR12_1314_平安大廈8168通過(guò)登錄平安大廈NodeB查看該基站IIP板數(shù)據(jù)包收發(fā)情況，可以發(fā)現(xiàn)存在收發(fā)數(shù)據(jù)包增速數(shù)量相差較大的情況，懷疑IIP板存在問題。3日更換IIP板，從上面表格的統(tǒng)計(jì)看未有成效，10日更換BCCS板，從上面表格統(tǒng)計(jì)看未有成效。時(shí)間服務(wù)小區(qū)Iub接口無(wú)線鏈路建立失敗個(gè)數(shù)，綜合原因 Hardware failureRRC連接失敗計(jì)數(shù)器，unspecified20100812CSZXR12_1314_平安大廈_13141232020100812CSZXR12_1314_平安大廈_131420020100812CSZXR12_1314_平安大廈_131430020100813CSZXR12_1314_平安大廈_13141594120100813CSZXR12_1314_平安大廈_131420020100813CSZXR12_1314_平安大廈_131430020100814CSZXR12_1314_平安大廈_13141201220100814CSZXR12_1314_平安大廈_131420020100814CSZXR12_1314_平安大廈_1314300首先與傳輸確認(rèn)四條傳輸是沒有誤碼的。同時(shí)查詢AAL鏈路確認(rèn)不擁塞。 通過(guò)KPI指標(biāo)查詢發(fā)現(xiàn)所有的RRC失敗全部集中在平安大廈TD1小區(qū)，通過(guò)基帶資源分配情況查詢得知該小區(qū)13141分配在4槽位TBPH單板的0/1/2載頻，其他兩個(gè)小區(qū)分配在11槽位單板。做載波調(diào)換測(cè)試將1區(qū)的載波資源更換到11槽位單板，2區(qū)的載波資源更換到4槽位單板，結(jié)果2區(qū)載波資源占用了4槽位TBPH板的3/4/5載頻。觀察統(tǒng)計(jì)結(jié)果，問題已經(jīng)解決。懷疑是4槽位TBPH板的0,1,2這三個(gè)載波有問題。時(shí)間NODEBIub接口無(wú)線鏈路建立失敗個(gè)數(shù)，綜合原因 Hardware failureRRC連接失敗計(jì)數(shù)器，unspecified20100815CSZXR12_1314_平安大廈372920100816CSZXR12_1314_平安大廈554420100817CSZXR12_1314_平安大廈745920100818CSZXR12_1314_平安大廈272120100819CSZXR12_1314_平安大廈0020100820CSZXR12_1314_平安大廈0020100821CSZXR12_1314_平安大廈00從這個(gè)案例可以看到，TBPH板的問題造成傳輸丟包，影響了RRC連接建立，從信令上來(lái)看，首先懷疑的是傳輸問題，實(shí)際上單板故障也會(huì)對(duì)傳輸造成影響。. RRC連接失敗no replyRRC連接失敗no reply是指終端發(fā)送RRC連接請(qǐng)求后，RNC回應(yīng)RRC Connection Setup，但是RNC未收到本該終端上發(fā)的RRC Connection Setup Response，這類問題在中興的網(wǎng)管中計(jì)為no reply，不是3GPP ，在CAC和RL Setup都已經(jīng)完成后，RNC將發(fā)送RRC Connection Setup 信令給UE，如果在規(guī)定的時(shí)間內(nèi)，沒有收到UE的RRC Connection Complete信令，那么系統(tǒng)側(cè)將會(huì)判斷本次RRC過(guò)程失敗，并且其原因值為No Reply。引起RRC連接失敗no reply的原因概括起來(lái)主要有三類：設(shè)備故障：RNC硬件故障、傳輸不穩(wěn)定、Node B單板故障、RRU設(shè)備故障等都有可能造成傳輸誤碼或者丟包，影響信令的