ZXTR RNS故障排查指導(dǎo)手冊(業(yè)務(wù)類分冊)(XXXX-R10)

1、 圖 2.24。圖 STYLEREF 2 s2.2SEQ 圖 * ARABIC s 24 IuPS UserPlane數(shù)據(jù)對接流程CS業(yè)務(wù)排查流程CS業(yè)務(wù)排查流程見REF _Ref189448279 h圖 2.25。圖 STYLEREF 2 s2.2SEQ 圖 * ARABIC s 25CS業(yè)務(wù)排查流程UE開機(jī)注冊失敗排查流程UE開機(jī)注冊失敗排查流程見REF _Ref189448348 h圖 2.26。圖 STYLEREF 2 s2.2SEQ 圖 * ARABIC s 26UE開機(jī)注冊失敗排查流程RRC連接故障排查流程上報(bào)過程簡單介紹要像排查RRC連接上報(bào)困難，首先要了解UE的上報(bào)過程以及RN

2、C的處理過程?？傮w來說包括兩個(gè)大的部分：隨機(jī)接入過程；RNS的處理過程；隨機(jī)接入過程隨機(jī)接入過程相對簡單，是耳熟能詳?shù)臇|西了，就不過多介紹了，不知道請自己找的文檔看看吧，簡單說明一下如何簡單確定隨機(jī)接入成功了？簡單來說，就是UE在UpPTS上發(fā)送了SYNC-UL，NODEB在FPACH上發(fā)送了響應(yīng)，這樣UE就可以在RACH上進(jìn)行上報(bào)RRC連接請求了?？梢酝ㄟ^LMT來看UE是否上報(bào)了UP，基站是否在FPACH上響應(yīng)了。方法如下：從lmt上也可以看到UE上報(bào)了UP,FPACH上也有包下發(fā)，注意要看是否有效簽名個(gè)數(shù)和FPACH包是從0開始增加的，正常情況下如果從0開始增加，就說明UE可以和基站進(jìn)行同

3、步；參考REF _Ref184202491 h圖 2.27。圖 STYLEREF 2 s2.2SEQ 圖 * ARABIC s 27 LMT上關(guān)于IP和FPACH的截圖RNS的處理過程介紹完了隨機(jī)接入過程后，重點(diǎn)介紹RNS的處理過程。我們把RNS的處理分成基站和RNC的處理。UE上報(bào)了RRC連接請求消息后，首先發(fā)到TBPE單板上解出來，通過BCCS然后到IIA，通過中間傳輸傳輸?shù)降絉NC的SDTB單板，然后內(nèi)部交換到IMAB單板，然后到小區(qū)建立了的RUB單板上解出來FP包，通過用戶面送到RCB單板；排查流程圖參考REF _Ref184203707 h圖 2.28。圖 STYLEREF 2 s2

4、.2SEQ 圖 * ARABIC s 28 RRC上報(bào)困難排查流程TBPE單板上的RACH包在UE可以成功隨機(jī)接入后，在RACH信道上上報(bào)了RRC連接請求，可以使用logview登陸到TBPE單板使用FpmHelp后通過命令FpmShowRachInfo查看TBPE單板上的包統(tǒng)計(jì)，正常情況如下紅色標(biāo)記：= Fpm Rach Info = * Fpm Rach Normal Info * dwRachRecvDspDataNum = 10* dwRachSendFPFrameNum = 10* dwRachRecvDLNodeSyncNum = 0* Fpm Rach Error Info *

5、dwRachULDataCrciErrNum = 0* dwRachULDataNotFindTrCHNum = 0* dwRachCrciNumErrNum = 0* dwRachFrameLenErrNum = 0* dwRachSendULFrameToMacErrNum = 0* dwRachULTfiErrNum = 0* dwRachULDataLenErrNum = 0* = Fpm Rach Info = *注意：FACH包出窗在查看FACH包統(tǒng)計(jì)的時(shí)候，可能會(huì)有FACH包出窗的情況出現(xiàn)，這時(shí)可以考慮修改私有數(shù)據(jù)表R_FACH中的ToWAS和ToWAE來改大窗口試試，同時(shí)在小區(qū)

6、參數(shù)中修改引用的索引。但是注意測試完畢后要修改回來。檢查IIA和TBPE之間的包收發(fā)進(jìn)行了TBPE和IIA之間的包收發(fā)測試，使用如下命令查看了包統(tǒng)計(jì)情況：TBPA上觀察AAL2包數(shù)據(jù)統(tǒng)計(jì)函數(shù) DispMACSAR(),主要可以查看gdwMacCount是否增加在TBPA上啟動(dòng)收發(fā)任務(wù) sp TBPATopTaskEntry在IIA上啟動(dòng)外網(wǎng)自環(huán) EnetOutLoopSet 1IIA上查看AAL2包統(tǒng)計(jì)數(shù)據(jù)： m2,用于查看兩邊收發(fā)包數(shù)據(jù)是否遞增結(jié)果如下：AAL2 MAC收包總數(shù):975, 發(fā)包總數(shù):921, 錯(cuò)誤總數(shù):0value = 47 = 0 x2f = /IIA-m2AAL2 MAC

7、收包總數(shù):984, 發(fā)包總數(shù):939, 錯(cuò)誤總數(shù):0value = 47 = 0 x2f = /查看RNC和NODEB之間的接口板上PVC收發(fā)包RACH的AAL2通道上是否收發(fā)正常，在IMAB板上和IIA單板上都有一套命令可以查看PVC上是否有收發(fā)包的命令，這個(gè)命令在我們排查問題中很有幫助，這里在羅唆一下：AtmlmShowPvcByStatus：查看PVC配置IMAB-AtmlmShowPvcByStatusPVC (STATUS = 0) LIST:PVCID R_UNIT R_PHY R_VPI R_VCI B0_UNIT B0_PHY B0_VPI B0_VCI B1_UNIT B1_

8、PHY B1_VPI B1_VCI205 6 0 0 131 6 1 1 131 - - - -PVCs count is 180 which Status = 0.BSP_PrintSet 0 x20,1：打開統(tǒng)計(jì)功能apcReadIVT 0,R_PHY,R_VPI,R_VCI，查看RNC在OMCB這條PVC上是否給NODEB發(fā)送了數(shù)據(jù)；IMAB-apcReadIVT 0,0,0,131，重點(diǎn)關(guān)注：ITotCellsRx : 654481627ITotCellsTx : 654481618 /需要關(guān)注該統(tǒng)計(jì)是否在遞增apcReadIVT 0,B0_PHY,B0_VPI,B0_VCI查看RNC

9、通過光口或IMA接收到NODEB回的OMCB的報(bào)文的統(tǒng)計(jì)用下面的命令；IMAB-apcReadIVT 0,1,1,131，重點(diǎn)關(guān)注：ITotCellsRx : 654594297ITotCellsTx : 654594345 / 需要關(guān)注該統(tǒng)計(jì)是否在遞增RUB上是否收到了RACH包由于目前外場的RUB單板比較多，所以可以考慮閉塞RUB單板，僅僅剩下一塊單板的方法來確定UE就在這塊RUB單板上上報(bào)數(shù)據(jù)，使用RDS工具登陸RUB上，使用ShowRnluDetailStat查看：查看是否RACH上有包統(tǒng)計(jì)增長見REF _Ref189474574 h圖 2.29。圖 STYLEREF 2 s2.2SE

10、Q 圖 * ARABIC s 29 RACH包統(tǒng)計(jì)RAB指派失敗排查流程RAB指派失敗排查流程見REF _Ref189450065 h圖 2.210。圖 STYLEREF 2 s2.2SEQ 圖 * ARABIC s 210RAB指派失敗排查流程PS業(yè)務(wù)類故障一般情況下，我們說PS業(yè)務(wù)有問題，前提是CS業(yè)務(wù)正常，如果CS業(yè)務(wù)都不正常，先處理CS業(yè)務(wù)問題。上節(jié)講述的CS業(yè)務(wù)故障排查同樣適用于PS業(yè)務(wù)，本節(jié)不再描述。本節(jié)重點(diǎn)針對數(shù)據(jù)包的分片、重組統(tǒng)計(jì)進(jìn)行描述。目前RNC對于Iu-PS口的配置策略是在2個(gè)框上分別占用1塊APBE單板，此單板上只使用一個(gè)光口配置Iu-PS，每個(gè)光口上配置2條IPOA及

11、其路由，這樣就形成了40M*4=160M的負(fù)荷分擔(dān)配置。RNC在建立Iu-PS承載時(shí)會(huì)在局內(nèi)進(jìn)行輪選，這樣RNC上行數(shù)據(jù)在本業(yè)務(wù)生命周期內(nèi)就只在此IPOA上進(jìn)行發(fā)送，對于CN側(cè)的處理，CN在下行發(fā)送數(shù)據(jù)包時(shí)對每個(gè)數(shù)據(jù)包進(jìn)行輪選IPOA，實(shí)現(xiàn)數(shù)據(jù)包的負(fù)荷分擔(dān)發(fā)送方式。所以也就是說RNC側(cè)的負(fù)荷分擔(dān)只是對業(yè)務(wù)的負(fù)荷分擔(dān)而CN的負(fù)荷分擔(dān)是對數(shù)據(jù)包的負(fù)荷分擔(dān)。在3G系統(tǒng)中，數(shù)據(jù)業(yè)務(wù)下載速率達(dá)不到要求或流量為零，通常是困擾業(yè)務(wù)測試的重要問題，也是很難排查的問題，它牽涉到網(wǎng)元有核心網(wǎng)，RNC，NODEB，此外還牽涉到終端，應(yīng)用層工具和外部網(wǎng)等，通常需要從系統(tǒng)的角度來排查，本文重點(diǎn)從無線接入網(wǎng)的角度提供幾點(diǎn)

12、排查思路。PS的故障現(xiàn)象有：從外場應(yīng)用和各種測試的經(jīng)驗(yàn)看，影響速率的主要問題有：單板硬件問題；AAL5通道配置問題；Iu/Iub口帶寬配置問題；空口參數(shù)問題；簽約速率和DRBC問題；其他，如終端問題，RNC和NODEB版本問題，筆記本性能問題等等；用戶面故障排查思路RNC系統(tǒng)中的分組域媒體流路徑見REF _Ref189475094 h圖 2.31。圖 STYLEREF 2 s2.3SEQ 圖 * ARABIC s 21分組域媒體流沿著上圖中黑色箭頭指示的方向，是分組域媒體流從Nodeb/RNC到CN的方向，CN到Nodeb/RNC的方向剛好相反，這里不畫出來了。上圖中，黑色線表示Iub/Iur

13、口分組域媒體流，藍(lán)色線表示Iu口PS域媒體流。分組域媒體流到達(dá)RNC系統(tǒng)時(shí)，首先到達(dá)APBE單板，APBE簡單處理之后，傳給RUB單板，RUB單板在用戶面處理之后，傳給RGUB單板。分組域媒體流和ZXWR RNC MCS子系統(tǒng)中的APBE、RUB和RGUB單板都有關(guān)。從上圖我們可以看出，問題排查的關(guān)鍵技術(shù)點(diǎn)。我們可以在CN、RNC、NODEB控制和排查的問題有HLR（歸屬位置寄存器）簽約，GTPU，PDCP，RLC，MAC，F(xiàn)P，物理層，空口參數(shù)（功率）。相關(guān)參數(shù)設(shè)置1、HLR簽約，找到CN的HLR受理臺(tái)，找到對應(yīng)的UE，查看UE的上下行鏈路的速率是否是你期望的值。另外注意一下有保證速率和傳輸

14、延遲。保證速率可以比你簽的速率小一些，如384，保證速率可以是64，傳輸延遲一般10ms。2、檢查OMCR上PS相關(guān)的配置數(shù)據(jù)，查看路由配置是否正常。經(jīng)驗(yàn)：有時(shí)，前后臺(tái)同步?jīng)]有將IP地址同步到前臺(tái)，可以在RPU單元上用ip_print_route命令查看路由表中是否有我們配上去的地址，如沒有可再次進(jìn)行整表同步。3、檢查完CN的簽約沒有問題，就找到RNC的OMCR后臺(tái)，找到對應(yīng)的子業(yè)務(wù)類型，該目錄下有對應(yīng)的PDCP，RLC，MAC，F(xiàn)P，物理層的一些配置，一般情況下可以采用默認(rèn)配置即可。如果出現(xiàn)PS不通或速率很低的情況需要逐層檢查這些參數(shù)是否正確。4、PDCP層參數(shù)檢查,采用默認(rèn)值即可，一般選擇

15、頭信息不出現(xiàn)，無損重定位指示不出現(xiàn)。因?yàn)槟壳邦^壓縮不支持，無損重定位也不支持。5、RLC層參數(shù)檢查，一般默認(rèn)配置即可，主要是POLL機(jī)制，可以找一個(gè)好的環(huán)境，把對應(yīng)的業(yè)務(wù)參數(shù)比較一下是否一致。要查看RRC配置給UE和用戶面的RB的SIZE上下行大小是否一樣，并且和MAC層的TFS中的SIZE對應(yīng)?？梢酝ㄟ^信令查看RRC SETUP，RB SETUP，用戶面的SUCIUSETUP，SUCIURBSETUP中的信元。6、MAC層參數(shù)，主要是TFS，TTI，一般PS384的TFS為0*336,1*336,2*336,4*336,8*336,12*336，TTI為10ms。其他的業(yè)務(wù)TTI一般為20m

16、s。例如PS64K的TTI為20ms，TFS為0*336,1*336,2*336,4*336。注意要分上下行，找到子業(yè)務(wù)類型中對應(yīng)的上下行參數(shù)配置區(qū)。 如果不知道速率和TFS，TTI的關(guān)系，可按下面的方法簡單計(jì)算。例如384K業(yè)務(wù)，為12*336，TTI為10ms,為336。計(jì)算得到速率R為384Kbit/s。所以你可以以此為公式判斷有關(guān)參數(shù)是否超出了鏈路能力。6、FP的參數(shù)主要是TOAWS，TOAWE，如果發(fā)現(xiàn)FP總是不斷的時(shí)間調(diào)整，上報(bào)的TOA值較大，可以和NODEB人協(xié)商，是否以上兩個(gè)參數(shù)設(shè)置不合理。7、物理層參數(shù)，主要是CFTC對應(yīng)的是否正常，這是控制上行物理控制信道和物理數(shù)據(jù)信道有關(guān)

17、功率的參數(shù)，一般采用默認(rèn)值，如果需要修改找專門的人士咨詢。另外如果啟動(dòng)壓縮模式，壓縮模式參數(shù)設(shè)置不合理也會(huì)導(dǎo)致速率異常。打孔可設(shè)為80以上。具體可以與專業(yè)人士確認(rèn)。8、利用showRnlu (DspNo)可以排查某塊DSP上的用戶面協(xié)議統(tǒng)計(jì)信息?；蛑苯觭howRnlu可以看到所有DSP的統(tǒng)計(jì)和。clearRnlu （DspNo），表示清空某個(gè)DSP的統(tǒng)計(jì)，clearRnlu表示清空所有DSP的統(tǒng)計(jì)。也可以直接查看某個(gè)協(xié)議層的統(tǒng)計(jì)。如showIuup DspNo，showPdcp DspNo，showRlc DspNo，showMac DspNo，showDfp DspNo，showCfp Ds

18、pNo。我們以一次統(tǒng)計(jì)為例，統(tǒng)計(jì)一個(gè)DSP上的信息。IUUP統(tǒng)計(jì)*Iuup statical information * Rfci信息 RfciIndex Uplink downlink * 0 29784 30329 * 1 31790 33724 * 2 0 0 * 3 0 0 * 4 0 0 * 5 0 0 * 6 0 0 * 7 0 0 * 8 0 0 * 9 0 0 * 向?qū)Χ税l(fā)送的初始化幀 90 * 從對端收到的初始化幀Ack 90 * 從對端收到的初始化幀Nack 0 * 等待初始化幀的超時(shí)次數(shù) 0 * 向?qū)Χ税l(fā)送的時(shí)間調(diào)整幀 182 * 從對端收到的時(shí)間調(diào)整幀Ack 182 *

19、 從對端收到的時(shí)間調(diào)整幀Nack 0 * 等待時(shí)間調(diào)整幀的超時(shí)次數(shù) 0 * * 向?qū)Χ税l(fā)送的速率控制幀 0 * 向控制面發(fā)送錯(cuò)誤指示幀 0 * 向?qū)Χ税l(fā)送的錯(cuò)誤指示幀 0 * 從對端收到的錯(cuò)誤指示幀 0 * 從Uu口收到的數(shù)據(jù)PDU 194662 * 向Iu口發(fā)送的數(shù)據(jù)PDU 71514 * 從Iu收到的數(shù)據(jù)PDU 72481 * 向Uu發(fā)送的數(shù)據(jù)PDU 131350 * 收到下行數(shù)據(jù)的空幀PDU 0 * 下行數(shù)據(jù)益處緩沖的個(gè)數(shù)PDU 10 * 放入發(fā)送隊(duì)列時(shí)失敗的個(gè)數(shù) 0 * 得不到發(fā)送隊(duì)列空間的個(gè)數(shù) 0 *這是IUUP的統(tǒng)計(jì)信息，正常情況下，黑體部分為上行，黑斜體部分為下行。若只有PING

20、包，比例關(guān)系和上下行速率比例基本一致。若有關(guān)隊(duì)列和緩存溢出，說明用戶面IUUP內(nèi)存不夠。PDCP統(tǒng)計(jì)*Pdcp statical information * 上行:從Rlc 收到的數(shù)據(jù) 9980 * 上行:向Iuup發(fā)送的數(shù)據(jù) 9940 * 上行:處理過程丟失數(shù)據(jù) 40 * 下行:從Iuup收到的數(shù)據(jù) 8138 * 下行:向Rlc 發(fā)送的數(shù)據(jù) 8138 * 下行:處理過程丟失數(shù)據(jù) 0 * 下行:回調(diào)緩沖區(qū)已滿的數(shù)據(jù) 0 * 從RLC收到的ack or nack 7912 * 上行:收到的壓縮頭幀 0 * 上行:收到的fullhead幀 0 * 上行:發(fā)送到CN的數(shù)據(jù)幀 0 * 下行:發(fā)送的壓縮

21、頭幀 0 * 下行:發(fā)送的fullhead幀 0 * 下行:接收到CN的數(shù)據(jù)幀 0 * 重定位:反傳到CN的數(shù)據(jù) 0 * 重定位:接收的反傳數(shù)據(jù) 0 *注意黑斜體部門的數(shù)目應(yīng)該很接近，若只有PING包，上下行的數(shù)據(jù)統(tǒng)計(jì)和上下行的速率基本一致。若下行回調(diào)數(shù)據(jù)區(qū)滿或下行處理過程中數(shù)據(jù)丟失，說明PDCP緩存不夠。若從RLC收到的ack or nack同下行:向Rlc 發(fā)送的數(shù)據(jù) 相差很大，超過40%-50%，說明無線口的鏈路的質(zhì)量有問題，解決方法見1.3節(jié)。RLC統(tǒng)計(jì)=Send=SUFI NO_MORE Send Counter = 2SUFI WINDOW Send Counter = 0SUFI

22、 ACK Send Counter = 27893SUFI LIST Send Counter = 382SUFI BITMAP Send Counter = 0SUFI RList Send Counter = 0SUFI MRW Send Counter = 0SUFI MRW_ACK Send Counter = 0Report Lost Pdus to UE = 3545=Recv=SUFI NO_MORE Recv Counter = 105SUFI WINDOW Recv Counter = 0SUFI ACK Recv Counter = 13152SUFI LIST Recv

23、Counter = 324SUFI BITMAP Recv Counter = 0SUFI RList Recv Counter = 1SUFI MRW Recv Counter = 0SUFI MRW_ACK Recv Counter = 0Report Lost Pdus from UE = 381Insert Data Sdu Success = 0Insert Data Sdu Fail = 0Recv Data Sdu Frm Upper = 10716Recv Data To be Segmented = 10716Recv Data Pdu Frm Mac = 64110Recv

24、 Invalid Data Pdu Frm Mac = 107Recv Status Pdu Frm Mac = 13257Send Data Pdu to Mac = 33156Send Status Pdu to Mac = 27895Am Rlc Send Reset Pdu to Peer = 222Am Rlc Send Reset Ack Pdu to Peer = 32Am Rlc Recv Reset Pdu from Peer = 32Am Rlc Recv Reset Ack Pdu from Peer = 7如果鏈路正常，RLC統(tǒng)計(jì)中主要是NO_MORE和ACK，如果接收

25、到的LIST，BITMAP，RLIST相對ACK的比例較大，說明RNC側(cè)RLC發(fā)送的包在空間丟失較多，說明下行鏈路質(zhì)量不好。如果RLC發(fā)送的LIST較多，說明上行UE發(fā)送的很多包丟失，上行鏈路質(zhì)量不好。另外如果發(fā)送的RESET較多或接收的RESET較多，也說明空中質(zhì)量差。MAC統(tǒng)計(jì) =MAC-d 統(tǒng)計(jì)= Mac-d 上行接收自 DFP PDU: 211153 Mac-d 上行接收自 CMAC PDU: 0 Mac-d 上行接收自DFP的空包 PDU: 63894 Mac-d 上行丟棄自DFP的空包 PDU: 0 Mac-d 上行發(fā)送到RLC的空包 PDU: 63894 Mac-d 上行發(fā)送到

26、RLC PDU: 210912 Mac-d 下行接收自 RLC PDU: 184946Mac-d 下行發(fā)送到 FP PDU: 184641 Mac-d 下行發(fā)送到 CMAC PDU: 117 Mac-d 下行發(fā)送空包到 FP PDU: 0 =MAC -c統(tǒng)計(jì)= Mac-c/sh 下行接收自 RLC PDU: 2035 Mac-c/sh 下行接收自 DMAC PDU: 31 Mac-c/sh 下行接收自DMAC并丟棄 PDU: 0 Mac-c/sh 下行發(fā)送到 FP PDU: 2060 Mac-c/sh 上行發(fā)送到 RLC PDU: 339 Mac-c/sh 上行發(fā)送到 DMAC PDU: 0M

27、AC一般沒有問題，主要是看他和RLC之間有沒有層間丟包。注意不一定完全相等，統(tǒng)計(jì)上有時(shí)間差，但相差極小。MAC-D和MAC-C之間的數(shù)據(jù)信息主要是從公共傳輸信道上出去的信令和建立在FACH上的業(yè)務(wù)數(shù)據(jù)。主要看Mac-d下行發(fā)送到 CMAC PDU和Mac-c/sh 下行接收自DMAC PDU基本一致。IurCfp統(tǒng)計(jì)=IurCfpU 統(tǒng)計(jì)= IurCfpU 回調(diào)接收數(shù)據(jù)包 0 IurCfpU 下行發(fā)送數(shù)據(jù)包 95 IurCfpU 下行發(fā)送控制包 0 IurCfpU 上行接收數(shù)據(jù)包 0 IurCfpU 上行接收控制包 0 =IurCfpC 統(tǒng)計(jì) = IurCfpC 回調(diào)接收數(shù)據(jù)包 17 IurC

28、fpC 上行發(fā)送數(shù)據(jù)包 0 IurCfpC 上行發(fā)送控制包 0 IurCfpC 下行接收數(shù)據(jù)包 17 IurCfpC 下行接收控制包 0IurCfp主要是UE在FACH態(tài)下的信令和業(yè)務(wù)。IurCfpU表示MAC-D側(cè)的IurCfp，IurCfpC表示MAC-C側(cè)的IurCfp。兩個(gè)接口上對應(yīng)方向上的數(shù)據(jù)基本一致。DFP統(tǒng)計(jì) DFP INFO dfp send data to node = 177973 dfp recv data from node = 167934 dfp srnc callback discard data = 0 dfp recv tb from node = 21115

29、3 dfp recv data head crc error = 0 dfp recv data payload crc error = 0dfp recv data crci error = 6565dfp frame len error for TFI = 0 dfp recv ctrl frame = 22486 dfp send ctrl frame = 3695 dfp send OLPC frame = 373 dfp recv TB from MacD = 184641 dfp send TB to MacD = 211153 dfp recv total Fp from Nod

30、eb = 190628 dfp send total Fp to Nodeb = 181668dfp Ul Macro Proc Fp Num = 100506dfp Dl Macro Send Fp Num = 122824 dfp Ul Macro Discard Fp Num = 1 dfp DRnc Iur Dl Recv Fp Num = 144156 dfp DRnc Iur Ul Send Fp Num = 142305 dfp DRnc Iur callback disc data = 0 dfp DRnc Iub Dl Send Fp Num = 144156 dfp DRn

31、c Iub Ul Recv Fp Num = 145613 dfp DRnc Iub callback disc data = 0 dfp DRnc Ul Macro Proc Fp Num = 0 dfp SRnc Iur Dl Send Fp Data Num = 68903 dfp SRnc Iur Ul Recv Fp Data Num = 38565 dfp SRnc Iur Dl Send Fp Ctrl Num = 1626 dfp SRnc Iur Ul Recv Fp Ctrl Num = 11944 dfp Node Sync send Fp Num = 597 dfp N

32、ode Sync recv Fp Num = 646 dfp Trans Sync send Fp Num = 1168 dfp Trans Sync recv Fp Num = 7453 dfp Period Sync send Fp Num = 1508 dfp Period Sync recv Fp Num = 538 dfp DRnc Node Sync send Fp Num = 49 dfp DRnc Node Sync recv Fp Num = 0 dfp DRnc Trans Sync send Fp Num = 0 dfp DRnc Trans Sync recv Fp N

33、um = 0DFP中比較重要的一個(gè)統(tǒng)計(jì)信息是dfp recv data crci error，如果占dfp recv tb from node的比例較大，說明上行鏈路質(zhì)量有問題，見1.3節(jié)。另外如dfp frame len error for TFI，dfp recv data head crc error，dfp recv data payload crc error占dfp recv tb from node的比例較大說明是RNC連接設(shè)備如DRNC，NODEB有問題或和我們理解的不一致，尤其是歐洲廠商的設(shè)備，請直接和他們聯(lián)系。CFP統(tǒng)計(jì) CFP INFO Cpch Fp recieve d

34、ata total : 0Pch Fp recieve data total : 48044Pch Fp send data total : 2132Pch Fp Receive time adjust : 0Fach Fp recieve data total : 96103Fach Fp send data total : 2062Fach fp Receive time adjust : 2Rach Fp recieve data total : 2281Rach Fp send to Mac total : 2281Rach Fp recieve buf full num : 0Rec

35、eive data Crci Error : 1941Put data in queue : 0Send data normally : 0Send data Error : 0Send data abnormally : 0Discard data in queue num : 0the total of data re-sended : 13the failure total of data re-sended : 0the total of data drnc queue : 286472the failure total of data drnc : 0Send Node Sync n

36、um on PCH : 0Send Node Sync num on FACH : 9Recv Node Sync num on PCH : 0Recv Node Sync num on FACH : 9Send Tran Sync num on PCH : 11Send Tran Sync num on FACH : 22Recv Tran Sync num on PCH : 11Recv Tran Sync num on FACH : 22Send Period Sync num on PCH : 48054Send Period Sync num on FACH : 96112Recv

37、Period Sync num on PCH : 48033Recv Period Sync num on FACH : 96066CFP的統(tǒng)計(jì)主要是UE處于FACH態(tài)時(shí)RACH和FACH上的包，注意如果UCIU和CCIU在不再一塊DSP上，需要找到改CCIU對應(yīng)的UCIU所在那個(gè)DSP上,和UCIU的統(tǒng)計(jì)信息對應(yīng)起來，一般情況下都在DCH態(tài)，查看數(shù)據(jù)統(tǒng)計(jì)，不會(huì)來看CFP的東西,。用戶面統(tǒng)計(jì)信息的聯(lián)合排查一、如何推斷上行鏈路質(zhì)量是否正常1： 上行的鏈路質(zhì)量可以直接通過DFP統(tǒng)計(jì)的上行CRCI錯(cuò)誤是否占從NODEB總共收到的TB塊比例比較小，10%以內(nèi)正常。2： 看RLC統(tǒng)計(jì)的發(fā)送的LIST占A

38、CK的比例是否較小，10%以內(nèi)正常。3： 看PDCP統(tǒng)計(jì)的從RLC收到的ack or nack同下行:向Rlc 發(fā)送的數(shù)據(jù) 相差不大，30%以內(nèi)正常。4：看PDCP的下行:處理過程丟失數(shù)據(jù)或下行:回調(diào)緩沖區(qū)已滿的數(shù)據(jù)是否較多，目前PS的數(shù)據(jù)都緩存在PDCP，如果上行質(zhì)量較差，RLC狀態(tài)包不能及時(shí)回來清除確認(rèn)的SDU，會(huì)導(dǎo)致PDCP溢出。二、如何推斷下行鏈路質(zhì)量是否正常1： 看RLC統(tǒng)計(jì)的接收的LIST，BITMAP，RLIST占ACK的比例是否較小，10%以內(nèi)正常。2： 看PDCP的下行:處理過程丟失數(shù)據(jù)或下行:回調(diào)緩沖區(qū)已滿的數(shù)據(jù)是否較多，目前PS的數(shù)據(jù)都緩存在PDCP，如果下行質(zhì)量較差，會(huì)

39、導(dǎo)致PDCP溢出。三、若上下行空口質(zhì)量很好，PS業(yè)務(wù)還是不正常，就要排除是否用戶面層間有丟包。1：下行數(shù)據(jù)脈絡(luò)軌跡。IUUP： 從Iu收到的數(shù)據(jù)PDU 向Uu發(fā)送的數(shù)據(jù)PDUPDCP： 下行:從Iuup收到的數(shù)據(jù)下行:向Rlc 發(fā)送的數(shù)據(jù)RLC ：Recv Data Sdu Frm UpperRecv Data To be SegmentedSend Data Pdu to Mac （分割轉(zhuǎn)化的RLC的PDU） Send Status Pdu to Mac MACD：DCH狀態(tài)：Mac-d 下行接收RLC PDUMac-d 下行發(fā)送到 FP PDUFACH狀態(tài)：Mac-d 下行接收RLC PD

40、UMac-d 下行發(fā)送到 CMAC PDU若UE處于DCH態(tài)DFP： dfp recv TB from MacDdfp send data to node （轉(zhuǎn)化為FP幀）若UE處于FACH態(tài)IurCfpU：IurCfpU 下行發(fā)送數(shù)據(jù)包再找到發(fā)送的小區(qū)所在的板子和DSP，查找如下信息。IurCfpC：IurCfpC 回調(diào)接收數(shù)據(jù)包 IurCfpC 下行接收數(shù)據(jù)包Cfp：Fach Fp recieve data total（轉(zhuǎn)化為FP幀）Fach Fp send data total 通過以上數(shù)據(jù)軌跡，在數(shù)據(jù)沒有轉(zhuǎn)化格式之前應(yīng)該基本相同。RLC和PDCP之間不超過50%。如果PDCP顯示自己的

41、緩存溢出，從OMCR檢查RLC的發(fā)送窗口是否合適。384K的窗口512，其他的256就已經(jīng)足夠了，一些比較小的業(yè)務(wù)，如8K，128的窗口足夠。2：上行數(shù)據(jù)脈絡(luò)軌跡。若UE處于DCH態(tài)DFP：dfp recv tb from node MACD上行接收自 DFP PDU Mac-d上行發(fā)送到 RLC PDU:若UE處于FACH態(tài)IurCfpU：IurCfpU 回調(diào)接收數(shù)據(jù)包 IurCfpU 上行接收數(shù)據(jù)包 MACD 上行接收自 CMAC Mac-d上行發(fā)送到 RLC PDU:RLC： Recv Data Pdu Frm Mac Recv Invalid Data Pdu Frm Mac Recv

42、 Status Pdu Frm Mac 正常情況下Invalid Data應(yīng)該很少，由于長度或碼元錯(cuò)誤引起的。RLC對于發(fā)向PDCP的數(shù)據(jù)沒有統(tǒng)計(jì)，直接看PDCP即可。PDCP： 上行:從Rlc 收到的數(shù)據(jù) 9980 上行:向Iuup發(fā)送的數(shù)據(jù) 9940 上行:處理過程丟失數(shù)據(jù) 40上行處理由于空間不夠，可能會(huì)丟失一些數(shù)據(jù)，但不能超過10%。IUUP： 從Uu口收到的數(shù)據(jù)PDU 向Iu口發(fā)送的數(shù)據(jù)PDU上行數(shù)據(jù)的排查一般只要確定用戶面層間沒有大面積的丟包即可，一般用戶面丟包的可能性很小，如果丟包，應(yīng)該是PDCP的數(shù)據(jù)區(qū)長度，RLC的窗口大小，邏輯信道大小，傳輸信道的緩存等等，這些都經(jīng)過長期測試

43、，出問題的可能極小。這只能證明用戶面沒有問題，如果還有PS業(yè)務(wù)不行，進(jìn)入底層以太網(wǎng)的數(shù)據(jù)統(tǒng)計(jì)檢查。終端、筆記本、下載工具問題 終端問題目前階段，終端的功能和性能參差不齊。在作PS業(yè)務(wù)出現(xiàn)問題時(shí)要了解終端的功能和性能，看看是否是終端問題。一般可采取使用多個(gè)終端來對比測試。筆記本問題基于TCP協(xié)議的業(yè)務(wù)，其速率受TCPWindowSize的影響，其中終端更改過程如下：1進(jìn)入注冊表進(jìn)行編輯見REF _Ref189476492 h圖 2.32。圖 STYLEREF 2 s2.3SEQ 圖 * ARABIC s 22 注冊表編輯2打開相關(guān)注注冊表項(xiàng)，見REF _Ref189476557 h圖 2.33：

44、HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpip圖 STYLEREF 2 s2.3SEQ 圖 * ARABIC s 23 注冊表編輯_更改TcpWindowSize值3新建字符串值TcpWindowSize，取值為65535：當(dāng)PS業(yè)務(wù)遇到問題時(shí)，比較相同簽約，相同終端，比較不同性能筆記本之間的差異，以判斷是否跟筆記本性能相關(guān)。并發(fā)類業(yè)務(wù)故障排查思路并發(fā)類業(yè)務(wù)種類較多，所以可能出現(xiàn)的問題也會(huì)較多。在系統(tǒng)保證了CS和PS業(yè)務(wù)分別建立時(shí)沒有問題的情況下，并發(fā)業(yè)務(wù)不能正常建立，可以考慮更換終端或者詢問終端是否支持所做的并發(fā)業(yè)務(wù)，并發(fā)業(yè)務(wù)種類

45、請參考REF _Ref188240863 h表 2.41，表格中以三星T578系統(tǒng)測試部的測試結(jié)果為參考。表 STYLEREF 2 s2.4SEQ 表 * ARABIC s 21 并發(fā)業(yè)務(wù)測試情況表CS12.2KCS64K短信彩信JAVA流媒體WAP呼入呼出呼入呼出發(fā)送接收發(fā)送接收下載播放瀏覽WAP業(yè)務(wù)Y支持Y支持YYNY支持，但不能同時(shí)進(jìn)行支持，但不能同時(shí)進(jìn)行彩信YYYYYYYY支持，發(fā)完彩信后可做YY短信YYYYYYYYYYYCS64KNNNNYYNYNNNJAVA下載YNYNNYNYNNN定位流媒體YNYNNYNYNNN并發(fā)業(yè)務(wù)故障的排查思路主要放在信令流程上是否可以走通，因?yàn)樵谇皟蓚€(gè)小

46、節(jié)中如果CS和PS的業(yè)務(wù)都不存在問題，那么并發(fā)業(yè)務(wù)只要信令正常，業(yè)務(wù)就可以建立，前提是CN上簽約了相應(yīng)的業(yè)務(wù)，UE支持此類業(yè)務(wù)。那么我們把并發(fā)業(yè)務(wù)的信令分為三個(gè)大類：1CS電路域類業(yè)務(wù)信令流程（CS12.2K和CS64K）：此類業(yè)務(wù)的信令流程請參考章節(jié)2.1，包含兩種，主叫和被叫信令流程。注意，CS12.2K和CS64K在RAB指派中的速率不同。2PS分組域類業(yè)務(wù)信令流程（彩信，JAVA，流媒體和WAP）：此類業(yè)務(wù)的信令流程請參考章節(jié)2.2，他們的信令流程都是PDP激活，只是在RAB指派中的速率和業(yè)務(wù)類型會(huì)有所不同。3短信類業(yè)務(wù)信令流程：短信業(yè)務(wù)沒有RAB建立，他們是在RB4上發(fā)送的，這樣我們

47、在信令上首先看到RRC建立，然后是直傳消息，之后就是資源的釋放。值得注意的是，在并發(fā)業(yè)務(wù)中，如果終端首先做PS業(yè)務(wù)，此時(shí)終端處于CELL_DCH或者CELL_FACH狀態(tài)，如果此時(shí)終端做被叫，會(huì)看到PAGING TYPE2，比常見的被叫信令多一條這個(gè)信令。常見故障現(xiàn)象常見故障現(xiàn)象如下：先做PS業(yè)務(wù)，然后被叫CS業(yè)務(wù)失??；先做PS業(yè)務(wù)，然后主叫CS業(yè)務(wù)失??；先做CS業(yè)務(wù)，后做PS業(yè)務(wù)失敗。常見故障原因以及排查思路并發(fā)類故障外場遇見的幾乎沒有，如果在CS和PS單獨(dú)業(yè)務(wù)都正常的情況下，并發(fā)業(yè)務(wù)基本不會(huì)出現(xiàn)問題。并發(fā)類故障原因請參考REF _Ref188264626 h表 2.42：表 STYLERE

48、F 2 s2.4SEQ 表 * ARABIC s 22 并發(fā)類常見故障原因故障分類常見故障原因并發(fā)類故障終端不支持并發(fā)業(yè)務(wù)；CN沒有進(jìn)行正確業(yè)務(wù)簽約；終端或者筆記本參數(shù)設(shè)置問題；有的并發(fā)業(yè)務(wù)沒有必要，例如CS12.2K和CS64K并發(fā)；無線或者傳輸資源不夠使用；CN或者RNS沒有下發(fā)第二類尋呼；3G小區(qū)內(nèi)切換類業(yè)務(wù)故障排查思路切換的種類繁多，可以分為Node B內(nèi)小區(qū)切換，RNC內(nèi)小區(qū)切換，跨RNC小區(qū)切換。從大體上可以分為兩類：第一，RNC內(nèi)的小區(qū)切換；第二，跨RNC的小區(qū)切換。故障排查上也有些許不同：RNC內(nèi)小區(qū)切換常見故障現(xiàn)象切換的故障現(xiàn)象大體分為兩類：1切換的信令流程不正確；2CS切換

49、信令正確，但是切換后沒有聲音或者有雜音；3PS切換信令正確，但是切換后速率異常；常見故障原因業(yè)務(wù)類故障的常見原因REF _Ref188414926 h表 2.51：表 STYLEREF 2 s2.5SEQ 表 * ARABIC s 21 RNC內(nèi)小區(qū)切換故障表故障分類常見故障原因信令流程不正確RNC沒有下發(fā)測量控制，或者測量控制消息不準(zhǔn)確；目標(biāo)小區(qū)Iub口傳輸資源不夠使用；目標(biāo)小區(qū)無線資源不夠使用；目標(biāo)小區(qū)干擾過高，導(dǎo)致切換完成消息（物理信道重配置完成或者RB重配置完成）不能上報(bào)；CS切換后無聲或者有雜音CN沒有給RNC發(fā)送數(shù)據(jù)包或者全部是靜音幀；UU口用戶面數(shù)據(jù)包異常；RUB單板故障；終端故

50、障；PS切換后速率異常CN存在問題，可以通過驗(yàn)證多個(gè)RNC來確定；UU口用戶面數(shù)據(jù)包異常；RUB單板故障；終端故障；跨RNC的小區(qū)之間切換常見故障現(xiàn)象切換的故障現(xiàn)象大體分為兩類：1切換的信令流程不正確，此處的信令流程和RNC內(nèi)小區(qū)切換略有不同；2CS切換信令正確，但是切換后沒有聲音或者有雜音；3PS切換信令正確，但是切換后速率異常；常見故障原因業(yè)務(wù)類故障的常見原因REF _Ref188414926 h表 2.51，注意鄰接關(guān)系的配置多了一個(gè)外部小區(qū)的數(shù)據(jù)配置。23G切換類業(yè)務(wù)故障排查思路常見故障現(xiàn)象切換的故障現(xiàn)象大體分為兩類：1切換的信令流程不正確；2CS切換信令正確，但是切換到2G后沒有聲音

51、或者有雜音；3PS切換信令正確，但是切換后速率上不來；常見故障原因常見故障原因請參考REF _Ref188865918 h表 2.61：表 STYLEREF 2 s2.6SEQ 表 * ARABIC s 21 2/3G切換失敗常見原因表故障分類常見故障原因信令流程不正確UE頻繁重選，導(dǎo)致電話無法撥通，不能切換；RNC沒有下發(fā)測量控制，或者測量控制消息不準(zhǔn)確；UE故障，沒有上報(bào)測量報(bào)告；CN信令流程異常導(dǎo)致切換失敗，例如CS從3G切換到2G不釋放Iu和Iub口資源，PS切換路由區(qū)更新失敗，PS切換沒有RAB指派等等；3G小區(qū)Iub口傳輸資源不夠使用（針對PS域切換）；3G小區(qū)無線資源不夠使用（針

52、對PS域切換）；CS切換到2G后無聲或者有雜音（CS不存在從2G到3G的切換）請2G查看原因； PS切換后速率異常CN存在問題，可以通過驗(yàn)證多個(gè)RNC來確定；UU口用戶面數(shù)據(jù)包異常；RUB單板故障；終端故障；HS業(yè)務(wù)故障排查思路常見故障現(xiàn)象1、物理信道重配置失??；2、終端無法接入；3、HS呼叫不成功；4、下載速率不理想。常見故障原因常見故障原因請參考REF _Ref213657999 h表 2.71：表 STYLEREF 2 s2.7SEQ 表 * ARABIC s 21 HS故障表格故障現(xiàn)象常見故障分類物理信道重配置失敗Sich和Prach配置的碼道沖突；當(dāng)配置有多條Scch/Sich時(shí)，不

53、同的Scch的信道號(hào)是否沖突，不同的Sich的功率配置是否正確；沒有看到RNC發(fā)送給NODEB物理信道重配置消息（檢查RNC和NODEB是否配置了支持HS）；RNC上參數(shù)配置錯(cuò)誤；TBPE單板的DSP0或者DSP11有故障。終端無法接入此類問題可以到CS類故障排查中查看原因HS呼叫不成功上行64k時(shí)，由于SF2，所以目標(biāo)時(shí)隙僅存在連續(xù)8個(gè)上行空閑碼道是不夠；主要是看信令來定位下載速率不理想用數(shù)據(jù)卡而電腦未接外部電源，如果用數(shù)據(jù)卡測試，而便攜電腦無外部電源，此時(shí)速率會(huì)大大下降；數(shù)據(jù)卡是否存在過熱現(xiàn)象；終端收到的信號(hào)強(qiáng)度是否足夠；Iub口配置的帶寬是否足夠站點(diǎn)的RTWP和ISCP過高，存在干擾；U

54、E問題，例如死機(jī)；如果發(fā)現(xiàn)承載Scch或承載下行伴隨Dpch的時(shí)隙的TCP（發(fā)射載波動(dòng)率）較高，說明此時(shí)Ue的接收信號(hào)不好，或已經(jīng)有Ue工作不正常；如果發(fā)現(xiàn)承載HsDsch的時(shí)隙的發(fā)射載波功率波動(dòng)較大，說明經(jīng)常無用戶被調(diào)度，可以查看No Data統(tǒng)計(jì)量，是否是因?yàn)闊o數(shù)據(jù)可發(fā)，所以經(jīng)常下行發(fā)射載波動(dòng)率會(huì)降低；如果功率無異常，但整體速率不高，則首先查看上報(bào)的CQI值，如果CQI偏低，但Nack不多，則可能是由于外部HS-DSCH信道的有干擾，但干擾還未大到產(chǎn)生Nack的地步；No Answer較多，從目前的情況來看，主要是因?yàn)闇y試點(diǎn)信號(hào)太差，只能換點(diǎn)測試查看Lmt的Ue統(tǒng)計(jì)信息的“上行信道的TB塊

55、數(shù)”和“上行信道錯(cuò)誤TB塊個(gè)數(shù)”，如果發(fā)現(xiàn)錯(cuò)誤包過多，說明上行質(zhì)量很差，如果發(fā)現(xiàn)上行正確數(shù)據(jù)包過少（比如10幾），或幾乎沒有，則說明Ue的應(yīng)答包沒有發(fā)上來，可以更換電腦重新測試。LMT上的數(shù)據(jù)分析方法Ack、Nack、No Answer、No Data和重傳超時(shí)重傳超時(shí)參數(shù)說明了在Node B物理層傳輸失敗，需要高層重傳的次數(shù)，當(dāng)存在大量的重傳超時(shí)時(shí)，會(huì)導(dǎo)致速率大幅下降，此時(shí)下行Scch信道或Dsch信道質(zhì)量可能較差，可通過Ack、Nack和No Answer的數(shù)量確定。Ack表示Hsdpa數(shù)據(jù)傳輸正確，Nack表示Scch發(fā)送正確，但DSch數(shù)據(jù)Ue接收錯(cuò)誤，No Answer表示Scch數(shù)

56、據(jù)Ue接收錯(cuò)誤。因此，Ack表示Scch和Dsch信道都比較好，大量Nack表示Dsch信道可能有惡化，大量No Answer表示Scch信道可能存在惡化。當(dāng)存在大量Nack或No Anser時(shí)，由于物理層重傳的影響，會(huì)導(dǎo)致下行速率降低，此時(shí)可能下行Scch信道或Dsch信道有惡化，可結(jié)合上報(bào)Cqi和發(fā)射碼功率及Aoa測量上報(bào)進(jìn)行分析。No data表示Node B調(diào)度該Ue時(shí)，該Ue無數(shù)據(jù)可發(fā)。No Data會(huì)導(dǎo)致空口速率下降，No Data的最主要的原因是因?yàn)镽nc無數(shù)據(jù)可發(fā)或Rnc發(fā)送窗滿，由于影響Rnc數(shù)據(jù)量和Rnc滑窗的數(shù)據(jù)都在上行伴隨Dpch上傳輸，因此出現(xiàn)No Data時(shí)，很可能

57、上行伴隨Dpch信道質(zhì)量已經(jīng)下降了。上行伴隨Dpch數(shù)據(jù)Lmt提供了“上行信道的TB塊數(shù)”和“上行信道錯(cuò)誤TB塊個(gè)數(shù)”，這2可參數(shù)都是一直累加的，我們可以通過差分計(jì)算出每上報(bào)周期（500ms）內(nèi)的上行伴隨Dpch正確數(shù)據(jù)塊個(gè)數(shù)和錯(cuò)誤數(shù)據(jù)塊個(gè)數(shù)，而當(dāng)錯(cuò)誤數(shù)據(jù)塊個(gè)數(shù)較多時(shí)，說明Rlc層或應(yīng)用層的數(shù)據(jù)確認(rèn)包未發(fā)送到發(fā)送端，此時(shí)就可能導(dǎo)致Rnc無數(shù)據(jù)可發(fā)或Rnc窗滿，導(dǎo)致Node B無數(shù)據(jù)可發(fā)，最后導(dǎo)致空口速率下降。如果上行伴隨Dpch的錯(cuò)包較多，則可以通過查看上行伴隨Dpch的接收信號(hào)碼功率和SIR來具體分析。Cqi平均值該值由Ue上報(bào)到Node B，Node B根據(jù)Cqi的值確定下行速率（下行發(fā)送

58、數(shù)據(jù)包的大小），Ue主要根據(jù)信道質(zhì)量來確定Cqi的值，但具體計(jì)算方法不祥，但Cqi下降表示Dsch信道有惡化，從實(shí)測數(shù)據(jù)看，Cqi對信道惡化的敏感程度，不是很敏感（即惡化后，雖然Cqi會(huì)降低，但還是會(huì)出現(xiàn)很多Nack）。發(fā)射碼功率和AOA測量下行的發(fā)射碼功率應(yīng)該保持一個(gè)較穩(wěn)定的值，當(dāng)發(fā)射碼功率突然提高時(shí)，說明此時(shí)下行伴隨Dpch信道所在的時(shí)隙信道質(zhì)量可能有惡化（存在干擾），所以Ue要求Node B提高發(fā)射功率，保持一定的信噪比。對定點(diǎn)測試而言，Aoa測量值也應(yīng)該保持一個(gè)定值，但尤其是在近場的環(huán)境下，由于多徑的影響，可能會(huì)導(dǎo)致Aoa測量有波動(dòng)，當(dāng)Aoa存在波動(dòng)時(shí)，由于多徑效應(yīng)的影響，可能此時(shí)的U

59、e下載速率會(huì)下降。接收碼功率和AOA測量從被測Sir可以直接看出上行伴隨Dpch的信道質(zhì)量，如果Sir比較穩(wěn)定，但此時(shí)對應(yīng)的接收碼功率上升，說明此時(shí)上行信道有干擾，但干擾不是很嚴(yán)重，通過Ue提高發(fā)射功率，還可以維持較好的信道質(zhì)量，如果Sir明顯下降，則說明此時(shí)上行伴隨Dpch已經(jīng)惡化，且無法通過Ue提升功率來保證信道質(zhì)量，此時(shí)可以查看時(shí)隙的Iscp（時(shí)隙的干擾信號(hào)功率，在載波信息里），如果Iscp明顯上升，就明確了確實(shí)有較強(qiáng)的干擾功率，如果Iscp無明顯變化，說明信道質(zhì)量的惡化可能是因?yàn)樯闲行盘?hào)已經(jīng)很弱了，應(yīng)該可以和接收信號(hào)碼功率對應(yīng)起來。典型故障案例摘要本章舉幾個(gè)典型案例，介紹各種業(yè)務(wù)類故障

60、的排查思路。CS業(yè)務(wù)類典型案例手機(jī)開機(jī)后無法注冊網(wǎng)絡(luò),從信令跟蹤上看信令沒有到CN,只有IUB口信令的交互分析:信令沒有走到CN,只有IUB口的信令交互,一般情況下是IUB口的對接數(shù)據(jù)出了問題,具體的例子如下： 故障案例1【故障現(xiàn)象】手機(jī)開機(jī)后,出現(xiàn)RL鏈路無法到達(dá)NODEB,導(dǎo)致RRC連接失敗,手機(jī)無法注冊,信令跟蹤見REF _Ref136849136 h圖3.11。圖 STYLEREF 2 s3.1SEQ 圖 * ARABIC s 21 RL建立失敗之一【可能原因】RL的建立是由NCP控制，如上是RL鏈路的建立請求根本就沒有發(fā)送到NODEB,有可能NCP鏈路出了問題，而導(dǎo)致RL鏈路的建立請