RRC常見問題處理思路

./RRC連接擁塞與無響應(yīng)處理思路背景隨著TD-SCDMA網(wǎng)絡(luò)二期工程接近尾場聲,全國的網(wǎng)絡(luò)建設(shè)卻緊隨其后開展起來,在網(wǎng)絡(luò)建設(shè)的初期階段,由于基站建設(shè)問題、基站故障問題等造成優(yōu)化的困難,本文就在處理RRC相關(guān)的部分問題,結(jié)合現(xiàn)場實(shí)際情況,為現(xiàn)場的網(wǎng)優(yōu)人員提供此類問題的一種解決思路。RRC連接過程的信令流程UE處于空閑模式下,當(dāng)UE的非接入層請求建立信令連接時(shí),UE將發(fā)起RRC連接建立過程。每個(gè)UE最多只有一個(gè)RRC連接。當(dāng)RNC接收到UE的RRCCONNECTIONREQUEST消息,由其無線資源管理模塊RRM根據(jù)特定的算法<CAC算法>確定是接受還是拒絕該RRC連接建立請求,如果接受,則再判決是建立在專用信道還是公共信道。對于RRC連接建立使用不同的信道,則RRC連接建立流程也不一樣。這樣一來,對于RRC連接的信令過程可以大致分為以下幾個(gè)過程：呼叫接入控制過程〔主要由UE發(fā)起請求,RNC來控制無線鏈路的建立過程RRC建立完成過程RRC連接過程的基本信令流程如下圖：相對應(yīng)在,在信令跟蹤工具看到的過程如下圖〔此為手動信令跟蹤得來,沒有打開部消息跟蹤：如果對應(yīng)的TKIT自動生成的CT數(shù)據(jù),則過程如下：圖中：FP為幀協(xié)議〔NodeB與RNC同步使用,此時(shí)的同步只是針對于用戶的新的無線鏈路的同步,并不是整個(gè)NodeB與RNC的同步RRC失敗分析RRC連接失敗發(fā)生RRC連接建立的過程中,RRC連接一般發(fā)生在如下情況下：UE開機(jī)UE關(guān)機(jī)位置區(qū)更新UE進(jìn)行主叫業(yè)務(wù)UE進(jìn)行被叫業(yè)務(wù)參考協(xié)議25331,RRC連接失敗的原因被分成了兩類：Unspecified〔未定義Congestion〔擁塞但在我司的RRC連接失敗的原因則根據(jù)信令過程,同時(shí)參考協(xié)議被分成了三類：Unspecified〔未定義Congestion〔擁塞NoReply〔未響應(yīng)在日常優(yōu)化的過程中,RRC連接失敗則增加了一種情況,變成了一種現(xiàn)象和三種原因,這新增的一種現(xiàn)象就是在路測中UE已經(jīng)發(fā)起了RRCConnectionRequest但經(jīng)過T300超時(shí)并且N300超數(shù),從而造成起呼失敗。但這種情況也有可能系統(tǒng)側(cè)已經(jīng)進(jìn)行了處理,RNC已經(jīng)下發(fā)了RRCConnectionSetup但終端沒有收到?！沧ⅲ呵皟煞N失敗的原因在信令表示中均表現(xiàn)為RRCConnectionReject,只是其Cause值不同,需要展開信令來看失敗的原因下面針對各個(gè)階段的失敗,結(jié)合相關(guān)的信令與硬件組成,逐個(gè)分析各種失敗的原因。3.1RRCConnectionRequestN300+T300超時(shí)〔數(shù)--路測UE一直上報(bào)RRCCONNECTIONREQ,但后臺信令跟蹤上看不到任何信令過程〔使用RTV工具的小區(qū)信令跟蹤,不要使用IMSI進(jìn)行信令跟蹤,如果使用IMSI進(jìn)行信令的跟蹤,則有可能造成由于CommonID沒有下來而不顯示相關(guān)的信令,本原因針對系統(tǒng)側(cè)根據(jù)沒有收到任何信令的情況。3.1.1信令流程階段發(fā)生失敗的信令階段如下圖所示〔圖中標(biāo)注的eq\o\ac<○,1>：3.1.2常見原因可能是由于UpPch所在位置存在干擾,。如果是特定終端出現(xiàn)該現(xiàn)象,而其他終端沒有問題,則隨機(jī)接入過程出現(xiàn)問題,可能存在UpPCH的干擾,導(dǎo)致網(wǎng)絡(luò)側(cè)解錯終端上行包,使得RNC看不到任何消息首先檢查NODEB的RACH統(tǒng)計(jì)有無上行數(shù)據(jù)包,如果沒有,但簽名個(gè)數(shù)與簽名碰撞個(gè)數(shù)一直在不停地增加,則可能存在上行UpPCH干擾?；蛘呤墙y(tǒng)計(jì)LMT對UpISCP的測量〔其測量與在KPI統(tǒng)計(jì)的POS干擾統(tǒng)計(jì)一致,但精度更高,測量為500ms一次統(tǒng)計(jì),取整個(gè)測量時(shí)段的平均值,而KPI統(tǒng)計(jì)的測量為15分鐘粒度取平均值通過CT工具檢查UPPCH上的干擾通過性能統(tǒng)計(jì),查看UPPOS上的UP干擾統(tǒng)計(jì)可以利用掃頻儀在特定終端天線口處檢測終端上行信號強(qiáng)度是否正常；如果是普遍現(xiàn)象,則需要檢查UpPch所在位置的干擾,如存在干擾則需要考慮對UpPch位置進(jìn)行漂移。終端問題,重啟UE看能否接入NodeB問題：重啟基站3.1.3解決辦法對各地外場的數(shù)據(jù)分析后,Up干擾有兩大類型：出現(xiàn)干擾平臺〔從當(dāng)?shù)卣麄€(gè)網(wǎng)絡(luò)來說,出現(xiàn)平臺的概率并不高,但除去干擾平臺后的干擾曲線基本正常,對于這類干擾通過基帶匹配是能判斷出干擾信號源構(gòu)成的,這樣基帶可以：〔1匹配出干擾源小區(qū),網(wǎng)優(yōu)調(diào)整〔方位角、俯仰角或擾碼、頻點(diǎn)〔2基帶做干擾消除,以消除干擾。干擾曲線整體抬高〔從當(dāng)?shù)卣麄€(gè)網(wǎng)絡(luò)來說,出現(xiàn)干擾曲線整體抬高的概率較高。對于這種情況可以采集數(shù)據(jù)看看基帶匹配處理后的結(jié)果,需要以Upsfifting的方式來克服此問題。3.2RRCConnectionReject〔CongestionUE上報(bào)RRCCONNECTIONREQ,但很快RNC就回了信令RREConnectionReject,并且其所帶的Cause值為"Congestion",產(chǎn)生這種原因主要是因?yàn)镽RM算法的進(jìn)行判決的結(jié)果,呼叫接納控制〔CAC是無線資源管理〔RRM中的一個(gè)重要組成部分。CACM模塊根據(jù)小區(qū)當(dāng)前的無線資源和負(fù)荷情況以及呼叫的服務(wù)質(zhì)量〔QoS,按照一定的算法,對新的呼叫請求可能產(chǎn)生的負(fù)荷增加量進(jìn)行預(yù)測,然后依據(jù)一定的接入準(zhǔn)則,決定對新的呼叫是允許接入還是拒絕接入。CAC的目的是在防止系統(tǒng)出現(xiàn)負(fù)荷過載和保證呼叫的服務(wù)質(zhì)量〔QoS的前提下,盡可能保證并提高系統(tǒng)的容量。3.2.1信令流程階段信令發(fā)生的階段如下圖所示〔圖中標(biāo)注的eq\o\ac<○,2>具體的信令節(jié)點(diǎn)如下：根據(jù)信令流程也就是說當(dāng)RLSetupResponse已經(jīng)完成后,才會出現(xiàn)這種情況。重要信令解釋信令消息過程解釋HYPERLINKrrcConnectionRequestUE發(fā)送RRC連接請求,請求接入網(wǎng)絡(luò)；HYPERLINKrrcConnectionRejectRNC可能因一些原因無法為UE建立RRC資源,因此發(fā)送RRC連接拒絕,拒絕UE的接入請求；3.2.2常見原因小區(qū)碼道資源不足,沒有足夠的碼道為UE分配〔特殊地：UE只支持單載頻,而主載頻上已沒有剩余的碼道資源；干擾或功率受限,軟資源接納失??；傳輸資源申請或帶寬接納失??；3.2.3解決方法針對兩種不同的原因采用不同的措施來解決,下面分別進(jìn)行描述資源不足造成的失敗查看小區(qū)的話務(wù)量〔PS業(yè)務(wù)流量,看一下小區(qū)是不是真的存在資源不足〔碼道資源；通過LMT查看一下功率資源情況,是否存在TCP資源不足的問題。如果存在小區(qū)的話務(wù)量不多,而且TCP占用正常仍會出現(xiàn)擁塞造成的起呼失敗,同時(shí)又不存在任何告警信息,則在動態(tài)數(shù)據(jù)庫管理中查看服務(wù)小區(qū)狀態(tài),是不是存在載頻資源被閉塞的現(xiàn)象〔在此處閉塞是不存在任何告警信息的。查看公共測量值和配置的接納門限,是否為功率干擾等軟資源受限；查看小區(qū)剩余的碼道資源數(shù)看是否有足夠的剩余資源如果是真正存在資源不足的情況,可以建議進(jìn)行擴(kuò)容。小區(qū)硬件故障一般存在兩種故障,一種是可以通過告警管理進(jìn)行顯示的故障,一種是小區(qū)本身沒有任何告警信息,屬于隱性故障。對于有告警存在的,解決之；如果不存在故障,不得己而為之的方法是對小區(qū)或RRU進(jìn)行重啟,以驗(yàn)證。CAC參數(shù)檢查：如下圖檢查CAC相關(guān)參數(shù)。傳輸資源受限查看Iub口帶寬大小是否受限；3.3RRCConnectionReject〔Unspecified一旦RNC通過了CAC的驗(yàn)證,RNC會請滶NodeB配置相應(yīng)的無線鏈路資源,一般情況下最少建立一條無線鏈路,在這個(gè)過程中,由于各種不同的原因造成的失敗,RNC將給UE發(fā)送Cause為"Unspecified"的Reject。3.2.1信令流程階段信令發(fā)生的階段如下圖所示〔圖中標(biāo)注的eq\o\ac<○,3>根據(jù)信令流程也就是說出現(xiàn)RLSetupFailure的現(xiàn)象,才會出現(xiàn)這種情況。3.2.2常見原因基站小區(qū)的故障造成。3.2.3解決方法解決基站小區(qū)的故障。3.4NoReply原因造成RRC失敗在CAC和RLSetup都已經(jīng)完成后,RNC將發(fā)送RRCConnectionSetup信令給UE,如果在規(guī)定的時(shí)間,沒有收到UE的RRCConnectionComplete信令,那么系統(tǒng)側(cè)將會判斷本次RRC過程失敗,并且其原因值為"NoReply"3.2.1信令流程階段信令發(fā)生的階段如下圖所示〔圖中標(biāo)注的eq\o\ac<○,3>重要信令解釋信令消息過程解釋HYPERLINKrrcConnectionRequestUE發(fā)送RRC連接請求,請求接入網(wǎng)絡(luò)；RadioLinkSetupReqeustIUB口消息,建立無線鏈路RadioLinkSetupResponseHYPERLINKrrcConnectionSetup空口消息,RNC向UE發(fā)送RRC建立,建立信令無線承載資源RadioLinkDeleteReqeustIUB口消息,刪除無線鏈路RadioLinkDeleteResponse根據(jù)信令流程也就是說出現(xiàn)在RNC發(fā)出了RRCConnectionSetup信令后,并且在規(guī)定的時(shí)間沒有收到UE的回應(yīng)消息,才會出現(xiàn)這情況。從整個(gè)信令的流程來看,RRCConnectionSetup信令首先從RNC的控制面發(fā)出,經(jīng)過部處理,通過RNC與NodeB之間的接口板,再經(jīng)過傳輸線路到NodeB與RNC的接口板,然后在NodeB部處理,再通過RRU經(jīng)Uu口到UE。在這個(gè)環(huán)節(jié)中每一個(gè)環(huán)節(jié)出現(xiàn)問題都會出現(xiàn)沒有響應(yīng)的現(xiàn)象。從路測終端側(cè)看,終端未收到RRC連接建立消息,由于終端在上報(bào)RRC請求后,收不到網(wǎng)絡(luò)側(cè)RRC建立,會重發(fā)RRC請求,據(jù)此可以判斷網(wǎng)絡(luò)側(cè)下發(fā)的RRC建立消息終端未收到,需要在下行方向,排查問題,如Iub口傳輸丟包、FACH信道配置不正確。3.2.2常見原因1RNC硬件存在故障RNC部處理板或?qū)ν獾慕涌诎逭趩栴},不能正確地將RRCConnectionSetup信令發(fā)送給NodeB2傳輸存在問題從RNC到NodeB之間的傳輸存在問題,傳輸誤碼較大,丟包較多,造成不能正確地將RRCConnectionSetup信令發(fā)送給NodeB3NodeB存在問題NodeB的某個(gè)板子存在問題,有可能不能正確地接收RNC傳送來的信令,也能可能不能將信令在FACH完整地傳送給RRU4RRU存在問題RRU不能正確地接收UE上發(fā)的RRCConnectionSetupComplete信令,或是不能正確地將RRCConnectionSetup信令作傳送給UE5參數(shù)設(shè)置存在問題SCCPCH的功率參數(shù)設(shè)置存在問題,導(dǎo)致UE無確接收RRU傳來的信令由于下行功率不足或存在下行干擾等原因,UE未收到RNC發(fā)送的RRCCONNECTIONSETUP消息；UE收到了RRCCONNECTIONSETUP消息,也上發(fā)了RRCCONNECTIONSETUPCOMPLETE消息,但由于上行功率不足或存在上行干擾等原因,RNC未收到該消息；6終端問題UE收到了RRCCONNECTIONSETUP消息,但由于消息錯誤或UE部錯誤等原因,UE未發(fā)送RRCCONNECTIONSETUPCOMPLETE消息；排查方法：3.2.3解決方法查看RRC建立的上行時(shí)隙干擾情況,如果發(fā)現(xiàn)時(shí)隙干擾很大,查看NODEB載扇是否正常,同時(shí)查看鄰小區(qū)是否有大量同頻鄰區(qū),若在話務(wù)量小的情況下,ISCP仍然很高,則干擾可能來自異系統(tǒng),如：GSM,PHS等；若網(wǎng)絡(luò)側(cè)沒有收到RRC建立完成消息：則調(diào)整后臺DPCH的期望接收功率,同時(shí)利用網(wǎng)規(guī)網(wǎng)優(yōu)手段,降低上行方向上的干擾；無效配置、配置不支持等配置錯誤：換個(gè)手機(jī)測試,若各廠家手機(jī)測試都有問題,將本小區(qū)RRC建立消息和正常小區(qū)的RRC建立消息進(jìn)行對比,查看配置是否正確；若UE未收到RRC建立消息：調(diào)整后臺下行最小發(fā)送功率,增加UE接收到RRC建立消息的幾率,或者調(diào)整周圍網(wǎng)絡(luò)的覆蓋、頻點(diǎn)、功率等,盡量降低下行方向上的干擾,或調(diào)整小區(qū)PCCPCH功率及公共信道、共享信道相關(guān)功率,確認(rèn)Iub口傳輸無問題；一般采用逐步判斷的方法來定位問題,步驟如下：確定RNC已經(jīng)收到了RRCConnectionRequest請求,并且已經(jīng)發(fā)出了RRCConnectionSetup信令確定RNC部的各個(gè)處理板之間數(shù)據(jù)傳輸沒有出現(xiàn)問題,可以使用系統(tǒng)工具RDS進(jìn)行各個(gè)處理板之間數(shù)據(jù)包的傳輸統(tǒng)計(jì),評估其丟包率。查看傳輸告警,以及傳輸?shù)牟扛婢?確保傳輸沒有問題查看NodeB的收包情況與RNC的送包數(shù)量一致,同時(shí)確定NodeB在FACH上正確完整地將數(shù)據(jù)傳出?！彩褂霉ぞ週OGVIW和LMT如果上以都不存在問題,重啟RRU或更換RRU進(jìn)行指標(biāo)觀察確定終端是否收到NodeB傳來的信令增加SCCPCH的功率,觀察指標(biāo)案例集錦本文匯總了TD外場出現(xiàn)過的RRC建立成功率低的部分案例,并按照原因進(jìn)行分類整理,以期對外場問題排查提供借鑒。本文所選案例中,部分參考了各地用服網(wǎng)優(yōu)整理的RRC建立成功率低問題處理總結(jié)。4.1CONGESTION原因：碼資源不足[故障現(xiàn)象]RRC呼通率低,從信令跟蹤上看,RNC收到rrcConnectionRequest請求之后,直接下發(fā)了rrcConnectionReject消息。RRC建立KPI統(tǒng)計(jì)失敗原因?yàn)镃ONGESTION.RNC版本：V2.00.200e2,基站版本：V2.00.200fP003。[排查方法]在OMCR性能管理中,篩選CONGESTION高的小區(qū)；提取KPI綜合分析〔CS/PS流量,初步分析是否和碼資源相關(guān)；如下表CONGESTION次數(shù)高的時(shí)段,PS流量很大,很有可能是碼資源不夠。19:00:001小時(shí)197119713室外小區(qū)214201124865.220:00:001小時(shí)197119713室外小區(qū)489473194474.921:00:001小時(shí)197119713室外小區(qū)56650117139222:00:001小時(shí)197119713室外小區(qū)602557168818.323:00:001小時(shí)197119713室外小區(qū)301291165699.8通過LMT小區(qū)載波測量查看小區(qū)碼資源配置及使用情況,并檢查一下有沒有載波〔或時(shí)隙被閉塞現(xiàn)象〔也可在OMCRNodeB動態(tài)數(shù)據(jù)管理中查看。[處理建議]如有載波〔或時(shí)隙被閉塞,則解開。小區(qū)擴(kuò)容[典型案例]4.2NOREPLY原因：BBUTBPHFPGA異常[故障現(xiàn)象]RRC呼通率低,從信令跟蹤上看,RNC發(fā)出rrcConnectionSetup請求之后,但沒有收到基站上報(bào)的RadioLinkRestoreIndication消息。RRC建立KPI統(tǒng)計(jì)失敗原因?yàn)镹OREPLY.RNC版本：V2.00.200e2,基站版本：V2.00.200fP003。[排查方法]在LMT上開啟本地小區(qū)載波測量,看在小區(qū)空載情況下,同時(shí)存在以下情況UPISCP值全為127注：UpIscp值在50以下屬于正常,前四個(gè)值不使用。上行時(shí)隙ISCP〔底噪值很大注：空載時(shí),Iscp值在-110左右屬于正常上行時(shí)隙RTWP后四天線值很大注：空載時(shí),BBURTWP值在-110左右屬于正常在OMCB上查詢基站通知消息,可以看到TBPH單板有大量"上行IQLink鏈路誤碼<198081164>"通知上報(bào)。采集RRU命令日志,看到testRTWP命令輸出值正常注：正常情況無UE接入時(shí),RRUShell顯示的RTWP是底躁,應(yīng)該在-69左右〔此時(shí)DSP監(jiān)控工具顯示的底躁應(yīng)該在-110dB左右,若低于-80dBm,則基本可認(rèn)為RRU無上行信號；若大于-60dBm,則底躁過高,存在干擾。[處理建議] 規(guī)避方法：復(fù)位小區(qū)所在TBPH單板。具體原因仍在定位。類似問題如果需要采集數(shù)據(jù),請按以下文檔采集:[典型案例]4.3NOREPLY原因：干放干擾[故障現(xiàn)象]RRC呼通率低,從信令跟蹤上看,RNC已經(jīng)下發(fā)了rrcConnectionSetup請求,且能收到基站上報(bào)的RadioLinkRestoreIndication消息,但收不到UE上報(bào)的rrcConnectionComplete消息。RRC建立KPI統(tǒng)計(jì)失敗原因?yàn)镹OREPLY.RNC版本：V2.00.200e2,基站版本：V2.00.200fP003。[排查方法]從LMT小區(qū)載波測量觀察,UpIscp和上行時(shí)隙ISCP功率正常。測試終端為凱明,測試時(shí)發(fā)現(xiàn)在R01覆蓋區(qū)域,各業(yè)務(wù)連接正常,但在干放覆蓋區(qū)域,手機(jī)一直無法接通。[處理建議]形成書面報(bào)告遞交移動,推動干放廠家積極解決。[典型案例]4.4NOREPLY原因：FACH出窗[故障現(xiàn)象]RRC呼通率低,從信令跟蹤上看,RNC已經(jīng)下發(fā)了rrcConnectionSetup請求,但沒有收到基站上報(bào)的RadioLinkRestoreIndication消息。RRC建立KPI統(tǒng)計(jì)失敗原因?yàn)镹OREPLY.RNC版本：V2.00.200e2,基站版本：V2.00.200fP003。[排查方法]打開LMT本地小區(qū)載波管理,如下圖；選中RRC建立失敗的小區(qū)載波,點(diǎn)擊資源分配查詢,查詢載波所在基帶板,如下圖,載波0在TBPE2上；在Logview中打開相應(yīng)的基帶板,待界面左上角的指示由紅色變成藍(lán)色之后,輸入TbpaInfoShow〔注意大小寫命令,確認(rèn)目標(biāo)小區(qū)是否在該基帶板上處理。如圖：確認(rèn)基帶板上只有目標(biāo)小區(qū),沒有其它小區(qū)〔注：上圖中,還有另一個(gè)小區(qū)20289駐留之后,輸入FpmShowFachInfo〔注意大小寫查詢該基帶板的收發(fā)包情況：如果該圖顯示紅色區(qū)域值數(shù)值相差很少,說明FACH幾乎沒有出窗；否則,說明FACH出窗嚴(yán)重〔即dwFachDLFrameTooEarlyNum,dwFachDLFrameTooLateNum兩個(gè)值比較大。由于rrcConnectionSetup消息是走FACH信道的,這可能導(dǎo)致rrcConnectionSetup消息發(fā)不到UE,從而導(dǎo)致RRC建立成功率降低。如果該基帶板上同時(shí)存在其它小區(qū),可以先閉塞其它小區(qū)相應(yīng)載波,使得該基帶板上只有目標(biāo)小區(qū),然后輸入FpmClear〔注意大小寫將基帶板原來保存的數(shù)據(jù)清空,過一定時(shí)間之后重新統(tǒng)計(jì)基帶板FACH收發(fā)包情況。注：上述方法只能排查FACH是否存在出窗。若要檢查FACH從RNC到NodeB有沒有丟失,需要與RNC側(cè)該小區(qū)FACH收發(fā)情況進(jìn)行比對。[處理建議] FACH包出窗有幾種原因RNC側(cè)老的用戶面處理板RUB板晶振有問題,按附件排查。典型案例：升級V2.00.200版本之后,有一塊RUB單板晶振異常,導(dǎo)致該RUB板上一塊DSP芯片上所有小區(qū)RRC建立成功率降低。RNC的控制面發(fā)給NodeB的TOWS和TOWE跟發(fā)給用戶面的不一致,導(dǎo)致NodeB這邊FACH出窗。按附件排查。備注:現(xiàn)場修改后證明對出窗沒有改善,建議出現(xiàn)出窗問題時(shí)在目前非衛(wèi)星傳輸配置下不必修改。傳輸丟包問題按照傳輸問題解決。4.5NOREPLY原因：RNCGUIM單板異常[故障現(xiàn)象]RRC呼通率低,從信令跟蹤上看,RNC已經(jīng)下發(fā)了rrcConnectionSetup請求,但沒有收到基站上報(bào)的RadioLinkRestoreIndication消息。RRC建立KPI統(tǒng)計(jì)失敗原因?yàn)镹OREPLY.RNC版本：V2.00.200e2,基站版本：V2.00.200fP003。[排查方法]OMCRRRCKPI統(tǒng)計(jì)TOP10顯示,多個(gè)小區(qū)出現(xiàn)NOREPLY原因的RRC連接失敗,沒有找到明顯較多的TOP小區(qū)。2009-05-0112712001002009-05-0210652002422009-05-0214303001012009-05-0311322001442009-05-0310652001182009-05-0410652002042009-05-0414303001392009-05-0414303001082009-05-0511482002142009-05-0515611001732009-05-0513593001092009-05-051225300102從NodeB側(cè)觀察,UpIscp、ISCP、RTWP功率水平都處于正常圍。在RNC側(cè)用戶面板上觀察FACH傳輸信道同步幀收發(fā)情況,收到的傳輸信道同步響應(yīng)幀數(shù)目明顯小于發(fā)出的請求數(shù)目。從NodeB基帶板FACH統(tǒng)計(jì)看,不存在FACH出窗現(xiàn)象。[處理建議] 可能原因RNCGUIM單板異常處理方法：對問題小區(qū)RUB板經(jīng)過的GUIM單板發(fā)起正常倒換操作。[典型案例]4.6NOREPLY原因：傳輸問題導(dǎo)致的RRC接入成功率低[故障現(xiàn)象]3-5944站點(diǎn)RRC呼通率低,從統(tǒng)計(jì)上看存在FACH較多的FACH出窗。<1>分析告警,發(fā)現(xiàn)該站點(diǎn)在版本升級后,一直有傳輸告警未恢復(fù)。站點(diǎn)名稱<局向>單板類型發(fā)生位置告警碼05944_六里橋IIASUBNET3,TP725944,MODULE1,1/2/15E1鏈路電信號丟失〔LOS<1029>05944_六里橋IIASUBNET3,TP725944,MODULE1,1/2/15E1鏈路電信號丟失〔LOS<1029>05944_六里橋IIASUBNET3,TP725944,MODULE1,1/2/15E1鏈路電信號丟失〔LOS<1029>05944_六里橋IIASUBNET3,TP725944,MODULE1,1/2/15E1鏈路電信號丟失〔LOS<1029><2>分析該站點(diǎn)配置,可以知道:由于該站只有一條E1是好的,懷疑是IMA帶寬不夠,業(yè)務(wù)數(shù)據(jù)傳輸占用帶寬較大情況下,FACH信道帶寬不足導(dǎo)致傳輸延遲,從而出窗?，F(xiàn)場在排除傳輸告警后,性能恢復(fù)為正常了。[排查方法] 略。[處理建議] 略。[典型案例] 吳海洋處理5944站點(diǎn)。4.7CONGESTIONREJ原因：RNC6接入成功率降低至90%[故障現(xiàn)象]從7月1日起RRC連接建立成功率下降6%左右。7月1日到22日RRC根據(jù)RRC連接失敗原因值進(jìn)行分析,發(fā)現(xiàn)RRC連接失敗原因值為congestion占的比例最大.連續(xù)三日對呼通率低TD站點(diǎn)進(jìn)行掃頻,都未發(fā)現(xiàn)有外部干擾,同時(shí)最嚴(yán)重的5個(gè)小區(qū)LMT跟蹤在不存在干擾、RRU溫度不高、無告警情況下,進(jìn)行。撥測發(fā)現(xiàn)RRC連接Reject還存在一定的概率。[排查方法]1,抓取信令跟蹤和管理日志,發(fā)現(xiàn)并沒有RRM的打印,縮小圍為UCPMC模塊出錯。2,打開DCMP系統(tǒng)的UCPMC打印,發(fā)現(xiàn)是UCPMC的wNumOfDchUe超過最大值2500而引起的RRCREJ.<2>[2009.07.2421:05:56]模塊:RNLC_UCPMC-RecievearrcConnectionRequest,StarttoCheckistheUeIdalreadyexistingintheRNC?inRnlcC2DRrcConnReqMsgHandler<1>[2009.07.2421:05:56]模塊:RNLC_UCPMC-NoSameUeintheRNC,continueRRCconnectproceedinRnlcC2DRrcConnReqMsgHandler.<1>[2009.07.2421:05:56]模塊:RNLC_UCPMC---UCPMC--gptImsiUeStatusList->wNumOfDchUe>=RNL_maxNrOfDchUe!<2>[2009.07.2421:05:56]模塊:RNLC_UCPMC---UCIC--ThenumberofNoPchUserreachmaxcountinRnlcC2DRrcConnReqMsgHandler!3,對于不能打開全部DCPM打印的采用存檢查方法來確認(rèn)該值是否異常。[處理建議]目前初步懷疑是該單板RCB板的個(gè)體問題。[典型案例]:經(jīng)過昨晚前后方排查,已經(jīng)定位,是1/2/6槽位RCB的2號CPU系統(tǒng)gptImsiUeStatusList全局變量超出2500最大值引起,當(dāng)UE選擇到該RCB單板時(shí),會導(dǎo)致RRCREJ,其他單板則不會。現(xiàn)場已經(jīng)通過復(fù)位RCB規(guī)避,經(jīng)過測試未發(fā)現(xiàn)RRCREJ情況。外場目前把該單板寄回所測試存復(fù)現(xiàn)。4.8NOREPLY原因:10241小區(qū)RRCREQ同時(shí)重復(fù)上報(bào)[故障現(xiàn)象]<1>接入成功率小時(shí)平均在80%左右本地小區(qū)識別碼小區(qū)類別RRC連接建立成功率<業(yè)務(wù)相關(guān)>RRC連接建立成功率10241室外小區(qū)0.00%53.85%10241室外小區(qū)0.00%26.92%10241室外小區(qū)100.00%93.33%10241室外小區(qū)100.00%68.75%10241室外小區(qū)100.00%100.00%10241室外小區(qū)100.00%94.44%10241室外小區(qū)100.00%100.00%10241室外小區(qū)100.00%100.00%10241室外小區(qū)100.00%89.66%10241室外小區(qū)93.75%90.91%10241室外小區(qū)100.00%95.74%10241室外小區(qū)100.00%92.86%<2>無告警,通知,FACH出窗也不明顯[排查方法]獲取該小區(qū)的信令,發(fā)現(xiàn)RRCREQ相隔10ms或者同時(shí)上來。使用MessageTrace跟蹤該小區(qū)所在CCMP系統(tǒng)的RNLC-AGENT的板間消息發(fā)現(xiàn)在149ms時(shí)同一個(gè)UE的RRCREQ從10241和10161小區(qū)上來。MessageTrace工具暫時(shí)未發(fā)布給外場,出現(xiàn)類似問題時(shí)向家里要。分析10241和10161小區(qū)配置的異同點(diǎn)10241小區(qū)主頻2022.4,擾碼90；10161小區(qū)主頻2022.4,擾碼90；兩者相同。站點(diǎn)距離相隔1.6KM。這兩個(gè)小區(qū)建立在同一個(gè)RUB板和CCMP系統(tǒng)中,所以能通過小區(qū)基本的信令跟蹤跟上,如果小區(qū)建立在不同的CCMP系統(tǒng),則信令跟蹤無法跟到重復(fù)現(xiàn)象。[處理建議]<1>臨時(shí)手段是修改RACH的時(shí)隙或者碼道,避免了同時(shí)解調(diào)的可能。<2>網(wǎng)優(yōu)優(yōu)化處理,需要修改擾碼頻點(diǎn)規(guī)劃,把其中一個(gè)站點(diǎn)的小區(qū)擾碼改掉。[典型案例]RRC連接成功率低4.9NOREPLY原因：3015小區(qū)<未定位>[故障現(xiàn)象]2009-07-1500:00:002009-07-1501:00:003014室外小區(qū)100.00%100.00%2009-07-1501:00:002009-07-1502:00:003014室外小區(qū)12.50%100.00%2009-07-1502:00:002009-07-1503:00:003014室外小區(qū)100.00%100.00%2009-07-1503:00:002009-07-1504:00:003014室外小區(qū)20.00%100.00%2009-07-1504:00:002009-07-1505:00:003014室外小區(qū)28.57%100.00%2009-07-1505:00:002009-07-1506:00:003014室外小區(qū)11.11%100.00%2009-07-1506:00:002009-07-1507:00:003014室外小區(qū)25.00%100.00%統(tǒng)計(jì)指標(biāo)該站的3個(gè)扇區(qū)RRC連接失敗率較高：對該站點(diǎn)告警信息進(jìn)行統(tǒng)計(jì),在7月份該站點(diǎn)無任何告警；對后臺LMT進(jìn)行跟蹤：3015扇區(qū)：主載波UPISCP基本正常,干擾功率在-110左右,但觀察一段時(shí)間發(fā)現(xiàn)UPISCP和干擾功率會在某一時(shí)間會有突發(fā)性的較大波動,輔載波：經(jīng)LMT觀察UPISCP一直較高,干擾功率也較大,UpIscp測量值干擾功率42:119:118:113:111:109:103:101:95:96:94:89:85:84:82:78:0.0:-103.2:-109.1:0.0:0.0:0.0:0.0:49:119:118:112:111:108:103:101:96:96:94:87:84:84:83:76:0.0:-102.5:-107.2:0.0:0.0:0.0:0.0:53:119:119:114:112:109:104:101:96:95:93:88:83:83:82:76:0.0:-10