ZXTRRNS（V1.21）故障排查指導手冊（業(yè)務類分冊）（-R1.0）中興通訊股份

修改統(tǒng)計版本號擬制人/修改人擬制/修改日期更改理由關鍵更改內容V1.21馬偉，李開彬/01/30新建提交初稿V1.30李開彬/11/5添加添加了HS部分內容注1：每次更改歸檔文件（指歸檔到事業(yè)部或企業(yè)檔案室文件）時，需填寫此表。注2：文件第一次歸檔時，“更改理由”、“關鍵更改內容”欄寫“無”。聲明本資料著作權屬中興通訊股份全部。未經著作權人書面許可，任何單位或個人不得以任何方法摘錄、復制或翻譯。侵權必究。和是中興通訊股份注冊商標。中興通訊產品名稱和標志是中興通訊專有標志或注冊商標。在本手冊中提及其它產品或企業(yè)名稱可能是其各自全部者商標或商名。在未經中興通訊或第三方商標或商名全部者事先書面同意情況下，本手冊不以任何方法授予閱讀者任何使用本手冊上出現任何標識許可或權利。本產品符合相關環(huán)境保護和人身安全方面設計要求，產品存放、使用和棄置應遵照產品手冊、相關協議或相關國法律、法規(guī)要求進行。因為產品和技術不停更新、完善，本資料中內容可能和實際產品不完全相符，敬請諒解。如需查詢產品更新情況，請聯絡當地辦事處。前言中興通訊自主開發(fā)TD-SCDMA第三代移動通信系統(tǒng)，由ZXTN（關鍵網部分）和ZXTR（無線網絡子系統(tǒng)）組成。ZXTR無線網絡子系統(tǒng)包含RNC（無線網絡控制器）和NodeB（無線基站），完成呼叫處理、無線資源分配管理、終端移動性管理、小區(qū)切換控制和無線接入功效。手冊說明本手冊是一套針對TD-SCDMA無線移動系統(tǒng)系列性資料，聚集了現在TD外場出現各類經典故障，并給出了常見問題處理思緒和經典案例分析，可作為日常維護時參考。全套手冊包含：《ZXTRRNS（V1.21）故障排查指導手冊－通用類分冊（信令篇）》《ZXTRRNS（V1.21）故障排查指導手冊－通用類分冊（工具篇）》《ZXTRRNS（V1.21）故障排查指導手冊－對接類分冊》《ZXTRRNS（V1.21）故障排查指導手冊－業(yè)務類分冊》《ZXTRRNS（V1.21）故障排查指導手冊－設備類分冊》《ZXTRRNS（V1.21）故障排查指導手冊－網管類分冊》本手冊為《第X分冊—設備類分冊》，關鍵介紹各類設備本身出現故障處理思緒，根據設備作出分類描述。目錄TOC\o"1-3"第1章常見故障分類 圖?2.24。圖STYLEREF2\s?2.2SEQ圖\*ARABIC\s24IuPSUserPlane數據對接步驟CS業(yè)務排查步驟CS業(yè)務排查步驟見REF_Ref\h圖?2.25。圖STYLEREF2\s?2.2SEQ圖\*ARABIC\s25CS業(yè)務排查步驟UE開機注冊失敗排查步驟UE開機注冊失敗排查步驟見REF_Ref\h圖?2.26。圖STYLEREF2\s?2.2SEQ圖\*ARABIC\s26UE開機注冊失敗排查步驟RRC連接故障排查步驟上報過程簡單介紹要像排查RRC連接上報困難，首先要了解UE上報過程和RNC處理過程。總體來說包含兩個大部分：隨機接入過程；RNS處理過程；隨機接入過程隨機接入過程相對簡單，是耳熟能詳東西了，就不過多介紹了，不知道請自己找文檔看看吧，簡單說明一下怎樣簡單確定隨機接入成功了？簡單來說，就是UE在UpPTS上發(fā)送了SYNC-UL，NODEB在FPACH上發(fā)送了響應，這么UE就能夠在RACH上進行上報RRC連接請求了。能夠經過LMT來看UE是否上報了UP，基站是否在FPACH上響應了。方法以下：從lmt上也能夠看到UE上報了UP,FPACH上也有包下發(fā)，注意要看是否有效署名個數和FPACH包是從0開始增加，正常情況下假如從0開始增加，就說明UE能夠和基站進行同時；參考REF_Ref\h圖?2.27。圖STYLEREF2\s?2.2SEQ圖\*ARABIC\s27LMT上相關IP和FPACH截圖RNS處理過程介紹完了隨機接入過程后，關鍵介紹RNS處理過程。我們把RNS處理分成基站和RNC處理。UE上報了RRC連接請求消息后，首先發(fā)到TBPE單板上解出來，經過BCCS然后到IIA，經過中間傳輸傳輸到到RNCSDTB單板，然后內部交換到IMAB單板，然后到小區(qū)建立了RUB單板上解出來FP包，經過用戶面送到RCB單板；排查步驟圖參考REF_Ref\h圖?2.28。圖STYLEREF2\s?2.2SEQ圖\*ARABIC\s28RRC上報困難排查步驟TBPE單板上RACH包在UE能夠成功隨機接入后，在RACH信道上上報了RRC連接請求，能夠使用logview登陸到TBPE單板使用FpmHelp后經過命令FpmShowRachInfo查看TBPE單板上包統(tǒng)計，正常情況以下紅色標識：===================FpmRachInfo=======================**FpmRachNormalInfo**dwRachRecvDspDataNum=10*dwRachSendFPFrameNum=10*dwRachRecvDLNodeSyncNum=0*FpmRachErrorInfo**dwRachULDataCrciErrNum=0*dwRachULDataNotFindTrCHNum=0*dwRachCrciNumErrNum=0*dwRachFrameLenErrNum=0*dwRachSendULFrameToMacErrNum=0*dwRachULTfiErrNum=0*dwRachULDataLenErrNum=0*===================FpmRachInfo=======================*注意：FACH包出窗在查看FACH包統(tǒng)計時候，可能會有FACH包出窗情況出現，這時能夠考慮修改私有數據表R_FACH中ToWAS和ToWAE來改大窗口試試，同時在小區(qū)參數中修改引用索引。不過注意測試完成后要修改回來。檢驗IIA和TBPE之間包收發(fā)進行了TBPE和IIA之間包收發(fā)測試，使用以下命令查看了包統(tǒng)計情況：TBPA上觀察AAL2包數據統(tǒng)計函數DispMACSAR(),關鍵能夠查看gdwMacCount是否增加在TBPA上開啟收發(fā)任務spTBPATopTaskEntry在IIA上開啟外網自環(huán)EnetOutLoopSet1IIA上查看AAL2包統(tǒng)計數據：m2,用于查看兩邊收發(fā)包數據是否遞增結果以下：AAL2MAC收包總數:975,發(fā)包總數:921,錯誤總數:0value=47=0x2f='/'IIA->m2AAL2MAC收包總數:984,發(fā)包總數:939,錯誤總數:0value=47=0x2f='/'查看RNC和NODEB之間接口板上PVC收發(fā)包RACHAAL2通道上是否收發(fā)正常，在IMAB板上和IIA單板上全部有一套命令能夠查看PVC上是否有收發(fā)包命令，這個命令在我們排查問題中很有幫助，這里在羅唆一下：AtmlmShowPvcByStatus：查看PVC配置IMAB->AtmlmShowPvcByStatusPVC(STATUS=0)LIST:PVCIDR_UNITR_PHYR_VPIR_VCIB0_UNITB0_PHYB0_VPIB0_VCIB1_UNITB1_PHYB1_VPIB1_VCI205600131611131--------PVC'scountis180whichStatus=0.BSP_PrintSet0x20,1：打開統(tǒng)計功效apcReadIVT0,R_PHY,R_VPI,R_VCI，查看RNC在OMCB這條PVC上是否給NODEB發(fā)送了數據；IMAB->apcReadIVT0,0,0,131，關鍵關注：ITotCellsRx:ITotCellsTx://需要關注該統(tǒng)計是否在遞增apcReadIVT0,B0_PHY,B0_VPI,B0_VCI查看RNC經過光口或IMA接收到NODEB回OMCB報文統(tǒng)計用下面命令；IMAB->apcReadIVT0,1,1,131，關鍵關注：ITotCellsRx:ITotCellsTx://需要關注該統(tǒng)計是否在遞增RUB上是否收到了RACH包因為現在外場RUB單板比較多，所以能夠考慮閉塞RUB單板，僅僅剩下一塊單板方法來確定UE就在這塊RUB單板上上報數據，使用RDS工具登陸RUB上，使用ShowRnluDetailStat查看：查看是否RACH上有包統(tǒng)計增加見REF_Ref\h圖?2.29。圖STYLEREF2\s?2.2SEQ圖\*ARABIC\s29RACH包統(tǒng)計RAB指派失敗排查步驟RAB指派失敗排查步驟見REF_Ref\h圖?2.210。圖STYLEREF2\s?2.2SEQ圖\*ARABIC\s210RAB指派失敗排查步驟PS業(yè)務類故障通常情況下，我們說PS業(yè)務有問題，前提是CS業(yè)務正常，假如CS業(yè)務全部不正常，先處理CS業(yè)務問題。上節(jié)講述CS業(yè)務故障排查一樣適適用于PS業(yè)務，本節(jié)不再描述。本節(jié)關鍵針對數據包分片、重組統(tǒng)計進行描述?，F在RNC對于Iu-PS口配置策略是在2個框上分別占用1塊APBE單板，此單板上只使用一個光口配置Iu-PS，每個光口上配置2條IPOA及其路由，這么就形成了40M*4=160M負荷分擔配置。RNC在建立Iu-PS承載時會在局內進行輪選，這么RNC上行數據在本業(yè)務生命周期內就只在此IPOA上進行發(fā)送，對于CN側處理，CN在下行發(fā)送數據包時對每個數據包進行輪選IPOA，實現數據包負荷分擔發(fā)送方法。所以也就是說RNC側負荷分擔只是對業(yè)務負荷分擔而CN負荷分擔是對數據包負荷分擔。在3G系統(tǒng)中，數據業(yè)務下載速率達不到要求或流量為零，通常是困擾業(yè)務測試關鍵問題，也是極難排查問題，它牽涉到網元相關鍵網，RNC，NODEB，另外還牽涉到終端，應用層工具和外部網等，通常需要從系統(tǒng)角度來排查，本文關鍵從無線接入網角度提供幾點排查思緒。PS故障現象有：從外場應用和多種測試經驗看，影響速率關鍵問題有：單板硬件問題；AAL5通道配置問題；Iu/Iub口帶寬配置問題；空口參數問題；簽約速率和DRBC問題；其它，如終端問題，RNC和NODEB版本問題，筆記本性能問題等等；用戶面故障排查思緒RNC系統(tǒng)中分組域媒體流路徑見REF_Ref\h圖?2.31。圖STYLEREF2\s?2.3SEQ圖\*ARABIC\s21分組域媒體流沿著上圖中黑色箭頭指示方向，是分組域媒體流從Nodeb/RNC到CN方向，CN到Nodeb/RNC方向剛好相反，這里不畫出來了。上圖中，黑色線表示Iub/Iur口分組域媒體流，藍色線表示Iu口PS域媒體流。分組域媒體流抵達RNC系統(tǒng)時，首先抵達APBE單板，APBE簡單處理以后，傳給RUB單板，RUB單板在用戶面處理以后，傳給RGUB單板。分組域媒體流和ZXWRRNCMCS子系統(tǒng)中APBE、RUB和RGUB單板全部相關。從上圖我們能夠看出，問題排查關鍵技術點。我們能夠在CN、RNC、NODEB控制和排查問題有HLR（歸屬位置寄存器）簽約，GTPU，PDCP，RLC，MAC，FP，物理層，空口參數（功率）。相關參數設置1、HLR簽約，找到CNHLR受理臺，找到對應UE，查看UE上下行鏈路速率是否是你期望值。另外注意一下有確保速率和傳輸延遲。確保速率能夠比你簽速率小部分，如384，確保速率能夠是64，傳輸延遲通常10ms。2、檢驗OMCR上PS相關配置數據，查看路由配置是否正常。經驗：有時，前后臺同時沒有將IP地址同時到前臺，能夠在RPU單元上用ip_print_route命令查看路由表中是否有我們配上去地址，如沒有可再次進行整表同時。3、檢驗完CN簽約沒有問題，就找到RNCOMCR后臺，找到對應子業(yè)務類型，該目錄下有對應PDCP，RLC，MAC，FP，物理層部分配置，通常情況下能夠采取默認配置即可。假如出現PS不通或速率很低情況需要逐層檢驗這些參數是否正確。4、PDCP層參數檢驗,采取默認值即可，通常選擇頭信息不出現，無損重定位指示不出現。因為現在頭壓縮不支持，無損重定位也不支持。5、RLC層參數檢驗，通常默認配置即可，關鍵是POLL機制，能夠找一個好環(huán)境，把對應業(yè)務參數比較一下是否一致。要查看RRC配置給UE和用戶面RBSIZE上下行大小是否一樣，而且和MAC層TFS中SIZE對應。能夠經過信令查看RRCSETUP，RBSETUP，用戶面SUCIUSETUP，SUCIURBSETUP中信元。6、MAC層參數，關鍵是TFS，TTI，通常PS384TFS為{0*336,1*336,2*336,4*336,8*336,12*336}，TTI為10ms。其它業(yè)務TTI通常為20ms。比如PS64KTTI為20ms，TFS為{0*336,1*336,2*336,4*336}。注意要分上下行，找到子業(yè)務類型中對應上下行參數配置區(qū)。假如不知道速率和TFS，TTI關系，可按下面方法簡單計算。比如384K業(yè)務，為12*336，TTI為10ms,為336。計算得到速率R為384Kbit/s。所以你能夠以此為公式判定相關參數是否超出了鏈路能力。6、FP參數關鍵是TOAWS，TOAWE，假如發(fā)覺FP總是不停時間調整，上報TOA值較大，能夠和NODEB人協商，是否以上兩個參數設置不合理。7、物理層參數，關鍵是CFTC對應是否正常，這是控制上行物理控制信道和物理數據信道相關功率參數，通常采取默認值，假如需要修改找專門人士咨詢。另外假如開啟壓縮模式，壓縮模式參數設置不合理也會造成速率異常。打孔可設為80以上。具體能夠和專業(yè)人士確定。8、利用showRnlu(DspNo)能夠排查某塊DSP上用戶面協議統(tǒng)計信息?；蛑苯觭howRnlu能夠看到全部DSP統(tǒng)計和。clearRnlu（DspNo），表示清空某個DSP統(tǒng)計，clearRnlu表示清空全部DSP統(tǒng)計。也能夠直接查看某個協議層統(tǒng)計。如showIuupDspNo，showPdcpDspNo，showRlcDspNo，showMacDspNo，showDfpDspNo，showCfpDspNo。我們以一次統(tǒng)計為例，統(tǒng)計一個DSP上信息。IUUP統(tǒng)計*Iuupstaticalinformation**Rfci信息RfciIndexUplinkdownlink**02978430329**200**300**400**500**600**700**800**900**向對端發(fā)送初始化幀90**從對端收到初始化幀Ack90**從對端收到初始化幀Nack0**等候初始化幀超時次數0**向對端發(fā)送時間調整幀182**從對端收到時間調整幀Ack182**從對端收到時間調整幀Nack0**等候時間調整幀超時次數0****向對端發(fā)送速率控制幀0**向控制面發(fā)送錯誤指示幀0**向對端發(fā)送錯誤指示幀0**從對端收到錯誤指示幀0**從Uu口收到數據PDU194662**向Iu口發(fā)送數據PDU71514**從Iu收到數據PDU72481**向Uu發(fā)送數據PDU131350**收到下行數據空幀PDU0**下行數據益處緩沖個數PDU10**放入發(fā)送隊列時失敗個數0**得不到發(fā)送隊列空間個數0*這是IUUP統(tǒng)計信息，正常情況下，黑體部分為上行，黑斜體部分為下行。若只有PING包，百分比關系和上下行速率百分比基礎一致。若相關隊列和緩存溢出，說明用戶面IUUP內存不夠。PDCP統(tǒng)計*Pdcpstaticalinformation**上行:從Rlc收到數據9980**上行:向Iuup發(fā)送數據9940**上行:處理過程丟失數據40**下行:從Iuup收到數據8138**下行:向Rlc發(fā)送數據8138**下行:處理過程丟失數據0**下行:回調緩沖區(qū)已滿數據0**從RLC收到ackornack7912**上行:收到壓縮頭幀0**上行:收到fullhead幀0**上行:發(fā)送到CN數據幀0**下行:發(fā)送壓縮頭幀0**下行:發(fā)送fullhead幀0**下行:接收到CN數據幀0**重定位:反傳到CN數據0**重定位:接收反傳數據0*注意黑斜體部門數目應該很靠近，若只有PING包，上下行數據統(tǒng)計和上下行速率基礎一致。若下行回調數據區(qū)滿或下行處理過程中數據丟失，說明PDCP緩存不夠。若從RLC收到ackornack同下行:向Rlc發(fā)送數據相差很大，超出40%-50%，說明無線口鏈路質量有問題，處理方法見1.3節(jié)。RLC統(tǒng)計======================Send============================SUFI[NO_MORE]SendCounter=2SUFI[WINDOW]SendCounter=0SUFI[ACK]SendCounter=27893SUFI[LIST]SendCounter=382SUFI[BITMAP]SendCounter=0SUFI[RList]SendCounter=0SUFI[MRW]SendCounter=0SUFI[MRW_ACK]SendCounter=0ReportLostPdustoUE=3545======================Recv============================SUFI[NO_MORE]RecvCounter=105SUFI[WINDOW]RecvCounter=0SUFI[ACK]RecvCounter=13152SUFI[LIST]RecvCounter=324SUFI[BITMAP]RecvCounter=0SUFI[RList]RecvCounter=1SUFI[MRW]RecvCounter=0SUFI[MRW_ACK]RecvCounter=0ReportLostPdusfromUE=381InsertDataSduSuccess=0InsertDataSduFail=0RecvDataSduFrmUpper=10716RecvDataTobeSegmented=10716RecvDataPduFrmMac=64110RecvInvalidDataPduFrmMac=107RecvStatusPduFrmMac=13257SendDataPdutoMac=33156SendStatusPdutoMac=27895AmRlcSendResetPdutoPeer=222AmRlcSendResetAckPdutoPeer=32AmRlcRecvResetPdufromPeer=32AmRlcRecvResetAckPdufromPeer=7假如鏈路正常，RLC統(tǒng)計中關鍵是NO_MORE和ACK，假如接收到LIST，BITMAP，RLIST相對ACK百分比較大，說明RNC側RLC發(fā)送包在空間丟失較多，說明下行鏈路質量不好。假如RLC發(fā)送LIST較多，說明上行UE發(fā)送很多包丟失，上行鏈路質量不好。另外假如發(fā)送RESET較多或接收RESET較多，也說明空中質量差。MAC統(tǒng)計======================MAC-d統(tǒng)計====================Mac-d上行接收自DFPPDU:211153Mac-d上行接收自CMACPDU:0Mac-d上行接收自DFP空包PDU:63894Mac-d上行丟棄自DFP空包PDU:0Mac-d上行發(fā)送到RLC空包PDU:63894Mac-d上行發(fā)送到RLCPDU:210912Mac-d下行接收自RLCPDU:184946Mac-d下行發(fā)送到FPPDU:184641Mac-d下行發(fā)送到CMACPDU:117Mac-d下行發(fā)送空包到FPPDU:0======================MAC-c統(tǒng)計====================Mac-c/sh下行接收自RLCPDU:2035Mac-c/sh下行接收自DMACPDU:31Mac-c/sh下行接收自DMAC并丟棄PDU:0Mac-c/sh下行發(fā)送到FPPDU:2060Mac-c/sh上行發(fā)送到RLCPDU:339Mac-c/sh上行發(fā)送到DMACPDU:0MAC通常沒有問題，關鍵是看她和RLC之間有沒有層間丟包。注意不一定完全相等，統(tǒng)計上有時間差，但相差極小。MAC-D和MAC-C之間數據信息關鍵是從公共傳輸信道上出去信令和建立在FACH上業(yè)務數據。關鍵看Mac-d下行發(fā)送到CMACPDU和Mac-c/sh下行接收自DMACPDU基礎一致。IurCfp統(tǒng)計======================IurCfpU統(tǒng)計================IurCfpU回調接收數據包0IurCfpU下行發(fā)送數據包95IurCfpU下行發(fā)送控制包0IurCfpU上行接收數據包0IurCfpU上行接收控制包0======================IurCfpC統(tǒng)計================IurCfpC回調接收數據包17IurCfpC上行發(fā)送數據包0IurCfpC上行發(fā)送控制包0IurCfpC下行接收數據包17IurCfpC下行接收控制包0IurCfp關鍵是UE在FACH態(tài)下信令和業(yè)務。IurCfpU表示MAC-D側IurCfp，IurCfpC表示MAC-C側IurCfp。兩個接口上對應方向上數據基礎一致。DFP統(tǒng)計DFPINFOdfpsenddatatonode=177973dfprecvdatafromnode=167934dfpsrnccallbackdiscarddata=0dfprecvtbfromnode=211153dfprecvdataheadcrcerror=0dfprecvdatapayloadcrcerror=0dfprecvdatacrcierror=6565dfpframelenerrorforTFI=0dfprecvctrlframe=22486dfpsendctrlframe=3695dfpsendOLPCframe=373dfprecvTBfromMacD=184641dfpsendTBtoMacD=211153dfprecvtotalFpfromNodeb=190628dfpsendtotalFptoNodeb=181668dfpUlMacroProcFpNum=100506dfpDlMacroSendFpNum=122824dfpUlMacroDiscardFpNum=1dfpDRncIurDlRecvFpNum=144156dfpDRncIurUlSendFpNum=142305dfpDRncIurcallbackdiscdata=0dfpDRncIubDlSendFpNum=144156dfpDRncIubUlRecvFpNum=145613dfpDRncIubcallbackdiscdata=0dfpDRncUlMacroProcFpNum=0dfpSRncIurDlSendFpDataNum=68903dfpSRncIurUlRecvFpDataNum=38565dfpSRncIurDlSendFpCtrlNum=1626dfpSRncIurUlRecvFpCtrlNum=11944dfpNodeSyncsendFpNum=597dfpNodeSyncrecvFpNum=646dfpTransSyncsendFpNum=1168dfpTransSyncrecvFpNum=7453dfpPeriodSyncsendFpNum=1508dfpPeriodSyncrecvFpNum=538dfpDRncNodeSyncsendFpNum=49dfpDRncNodeSyncrecvFpNum=0dfpDRncTransSyncsendFpNum=0dfpDRncTransSyncrecvFpNum=0DFP中比較關鍵一個統(tǒng)計信息是dfprecvdatacrcierror，假如占dfprecvtbfromnode百分比較大，說明上行鏈路質量有問題，見1.3節(jié)。另外如dfpframelenerrorforTFI，dfprecvdataheadcrcerror，dfprecvdatapayloadcrcerror占dfprecvtbfromnode百分比較大說明是RNC連接設備如DRNC，NODEB有問題或和我們了解不一致，尤其是歐洲廠商設備，請直接和她們聯絡。CFP統(tǒng)計CFPINFOCpchFprecievedatatotal:0PchFprecievedatatotal:48044PchFpsenddatatotal:2132PchFpReceivetimeadjust:0FachFprecievedatatotal:96103FachFpsenddatatotal:2062FachfpReceivetimeadjust:2RachFprecievedatatotal:2281RachFpsendtoMactotal:2281RachFprecievebuffullnum:0ReceivedataCrciError:1941Putdatainqueue:0Senddatanormally:0SenddataError:0Senddataabnormally:0Discarddatainqueuenum:0thetotalofdatare-sended:13thefailuretotalofdatare-sended:0thetotalofdatadrncqueue:286472thefailuretotalofdatadrnc:0SendNodeSyncnumonPCH:0SendNodeSyncnumonFACH:9RecvNodeSyncnumonPCH:0RecvNodeSyncnumonFACH:9SendTranSyncnumonPCH:11SendTranSyncnumonFACH:22RecvTranSyncnumonPCH:11RecvTranSyncnumonFACH:22SendPeriodSyncnumonPCH:48054SendPeriodSyncnumonFACH:96112RecvPeriodSyncnumonPCH:48033RecvPeriodSyncnumonFACH:96066CFP統(tǒng)計關鍵是UE處于FACH態(tài)時RACH和FACH上包，注意假如UCIU和CCIU在不再一塊DSP上，需要找到改CCIU對應UCIU所在那個DSP上,和UCIU統(tǒng)計信息對應起來，通常情況下全部在DCH態(tài)，查看數據統(tǒng)計，不會來看CFP東西,。用戶面統(tǒng)計信息聯合排查一、怎樣推斷上行鏈路質量是否正常1：上行鏈路質量能夠直接經過DFP統(tǒng)計上行CRCI錯誤是否占從NODEB總共收到TB塊百分比比較小，10%以內正常。2：看RLC統(tǒng)計發(fā)送LIST占ACK百分比是否較小，10%以內正常。3：看PDCP統(tǒng)計從RLC收到ackornack同下行:向Rlc發(fā)送數據相差不大，30%以內正常。4：看PDCP下行:處理過程丟失數據或下行:回調緩沖區(qū)已滿數據是否較多，現在PS數據全部緩存在PDCP，假如上行質量較差，RLC狀態(tài)包不能立即回來清除確定SDU，會造成PDCP溢出。二、怎樣推斷下行鏈路質量是否正常1：看RLC統(tǒng)計接收LIST，BITMAP，RLIST占ACK百分比是否較小，10%以內正常。2：看PDCP下行:處理過程丟失數據或下行:回調緩沖區(qū)已滿數據是否較多，現在PS數據全部緩存在PDCP，假如下行質量較差，會造成PDCP溢出。三、若上下行空口質量很好，PS業(yè)務還是不正常，就要排除是否用戶面層間有丟包。1：下行數據脈絡軌跡。IUUP：從Iu收到數據PDU向Uu發(fā)送數據PDUPDCP：下行:從Iuup收到數據下行:向Rlc發(fā)送數據RLC：RecvDataSduFrmUpperRecvDataTobeSegmentedSendDataPdutoMac（分割轉化RLCPDU）SendStatusPdutoMacMACD：DCH狀態(tài)：Mac-d下行接收RLCPDUMac-d下行發(fā)送到FPPDUFACH狀態(tài)：Mac-d下行接收RLCPDUMac-d下行發(fā)送到CMACPDU若UE處于DCH態(tài)DFP：dfprecvTBfromMacDdfpsenddatatonode（轉化為FP幀）若UE處于FACH態(tài)IurCfpU：IurCfpU下行發(fā)送數據包再找到發(fā)送小區(qū)所在板子和DSP，查找以下信息。IurCfpC：IurCfpC回調接收數據包IurCfpC下行接收數據包Cfp：FachFprecievedatatotal（轉化為FP幀）FachFpsenddatatotal經過以上數據軌跡，在數據沒有轉化格式之前應該基礎相同。RLC和PDCP之間不超出50%。假如PDCP顯示自己緩存溢出，從OMCR檢驗RLC發(fā)送窗口是否適宜。384K窗口512，其它256就已經足夠了，部分比較小業(yè)務，如8K，128窗口足夠。2：上行數據脈絡軌跡。若UE處于DCH態(tài)DFP：dfprecvtbfromnodeMACD上行接收自DFPPDUMac-d上行發(fā)送到RLCPDU:若UE處于FACH態(tài)IurCfpU：IurCfpU回調接收數據包IurCfpU上行接收數據包MACD上行接收自CMACMac-d上行發(fā)送到RLCPDU:RLC：RecvDataPduFrmMacRecvInvalidDataPduFrmMacRecvStatusPduFrmMac正常情況下InvalidData應該極少，因為長度或碼元錯誤引發(fā)。RLC對于發(fā)向PDCP數據沒有統(tǒng)計，直接看PDCP即可。PDCP：上行:從Rlc收到數據9980上行:向Iuup發(fā)送數據9940上行:處理過程丟失數據40上行處理因為空間不夠，可能會丟失部分數據，但不能超出10%。IUUP：從Uu口收到數據PDU向Iu口發(fā)送數據PDU上行數據排查通常只要確定用戶面層間沒有大面積丟包即可，通常見戶面丟包可能性很小，假如丟包，應該是PDCP數據區(qū)長度，RLC窗口大小，邏輯信道大小，傳輸信道緩存等等，這些全部經過長久測試，出問題可能極小。這只能證實用戶面沒有問題，假如還有PS業(yè)務不行，進入底層以太網數據統(tǒng)計檢驗。終端、筆記本、下載工具問題終端問題現在階段，終端功效和性能參差不齊。在作PS業(yè)務出現問題時要了解終端功效和性能，看看是否是終端問題。通常可采取使用多個終端來對比測試。筆記本問題基于TCP協議業(yè)務，其速率受TCPWindowSize影響，其中終端更改過程以下：1．進入注冊表進行編輯見REF_Ref\h圖?2.32。圖STYLEREF2\s?2.3SEQ圖\*ARABIC\s22注冊表編輯2．打開相關注注冊表項，見REF_Ref\h圖?2.33：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpip圖STYLEREF2\s?2.3SEQ圖\*ARABIC\s23注冊表編輯_更改TcpWindowSize值3．新建字符串值TcpWindowSize，取值為65535：當PS業(yè)務碰到問題時，比較相同簽約，相同終端，比較不一樣性能筆記本之間差異，以判定是否跟筆記本性能相關。并發(fā)類業(yè)務故障排查思緒并發(fā)類業(yè)務種類較多，所以可能出現問題也會較多。在系統(tǒng)確保了CS和PS業(yè)務分別建立時沒有問題情況下，并發(fā)業(yè)務不能正常建立，能夠考慮更換終端或問詢終端是否支持所做并發(fā)業(yè)務，并發(fā)業(yè)務種類請參考REF_Ref\h表?2.41，表格中以三星T578系統(tǒng)測試部測試結果為參考。表STYLEREF2\s2.4SEQ表\*ARABIC\s21并發(fā)業(yè)務測試情況表CS12.2KCS64K短信彩信JAVA流媒體WAP呼入呼出呼入呼出發(fā)送接收發(fā)送接收下載播放瀏覽WAP業(yè)務Y支持Y支持YYNY支持，但不能同時進行支持，但不能同時進行彩信YYYYYYYY支持，發(fā)完彩信后可做YY短信YYYYYYYYYYYCS64KNNNNYYNYNNNJAVA下載YNYNNYNYNNN定位流媒體YNYNNYNYNNN并發(fā)業(yè)務故障排查思緒關鍵放在信令步驟上是否能夠走通，因為在前兩個小節(jié)中假如CS和PS業(yè)務全部不存在問題，那么并發(fā)業(yè)務只要信令正常，業(yè)務就能夠建立，前提是CN上簽約了對應業(yè)務，UE支持這類業(yè)務。那么我們把并發(fā)業(yè)務信令分為三個大類：1． CS電路域類業(yè)務信令步驟（CS12.2K和CS64K）：這類業(yè)務信令步驟請參考章節(jié)2.1，包含兩種，主叫和被叫信令步驟。注意，CS12.2K和CS64K在RAB指派中速率不一樣。2． PS分組域類業(yè)務信令步驟（彩信，JAVA，流媒體和WAP）：這類業(yè)務信令步驟請參考章節(jié)2.2，她們信令步驟全部是PDP激活，只是在RAB指派中速率和業(yè)務類型會有所不一樣。3． 短信類業(yè)務信令步驟：短信業(yè)務沒有RAB建立，她們是在RB4上發(fā)送，這么我們在信令上首先看到RRC建立，然后是直傳消息，以后就是資源釋放。值得注意是，在并發(fā)業(yè)務中，假如終端首先做PS業(yè)務，此時終端處于CELL_DCH或CELL_FACH狀態(tài)，假如此時終端做被叫，會看到PAGINGTYPE2，比常見被叫信令多一條這個信令。常見故障現象常見故障現象以下：先做PS業(yè)務，然后被叫CS業(yè)務失?。幌茸鯬S業(yè)務，然后主叫CS業(yè)務失??；先做CS業(yè)務，后做PS業(yè)務失敗。常見故障原因和排查思緒并發(fā)類故障外場遇見幾乎沒有，假如在CS和PS單獨業(yè)務全部正常情況下，并發(fā)業(yè)務基礎不會出現問題。并發(fā)類故障原因請參考REF_Ref\h表?2.42：表STYLEREF2\s2.4SEQ表\*ARABIC\s22并發(fā)類常見故障原因故障分類常見故障原因并發(fā)類故障終端不支持并發(fā)業(yè)務；CN沒有進行正確業(yè)務簽約；終端或筆記本參數設置問題；有并發(fā)業(yè)務沒有必需，比如CS12.2K和CS64K并發(fā)；無線或傳輸資源不夠使用；CN或RNS沒有下發(fā)第二類尋呼；3G小區(qū)內切換類業(yè)務故障排查思緒切換種類繁多，能夠分為NodeB內小區(qū)切換，RNC內小區(qū)切換，跨RNC小區(qū)切換。從大致上能夠分為兩類：第一，RNC內小區(qū)切換；第二，跨RNC小區(qū)切換。故障排查上也有些許不一樣：RNC內小區(qū)切換常見故障現象切換故障現象大致分為兩類：1．切換信令步驟不正確；2．CS切換信令正確，不過切換后沒有聲音或有雜音；3．PS切換信令正確，不過切換后速率異常；常見故障原因業(yè)務類故障常見原因REF_Ref\h表?2.51：表STYLEREF2\s2.5SEQ表\*ARABIC\s21RNC內小區(qū)切換故障表故障分類常見故障原因信令步驟不正確RNC沒有下發(fā)測量控制，或測量控制消息不正確；目標小區(qū)Iub口傳輸資源不夠使用；目標小區(qū)無線資源不夠使用；目標小區(qū)干擾過高，造成切換完成消息（物理信道重配置完成或RB重配置完成）不能上報；CS切換后無聲或有雜音CN沒有給RNC發(fā)送數據包或全部是靜音幀；UU口用戶面數據包異常；RUB單板故障；終端故障；PS切換后速率異常CN存在問題，能夠經過驗證多個RNC來確定；UU口用戶面數據包異常；RUB單板故障；終端故障；跨RNC小區(qū)之間切換常見故障現象切換故障現象大致分為兩類：1．切換信令步驟不正確，此處信令步驟和RNC內小區(qū)切換略有不一樣；2．CS切換信令正確，不過切換后沒有聲音或有雜音；3．PS切換信令正確，不過切換后速率異常；常見故障原因業(yè)務類故障常見原因REF_Ref\h表?2.51，注意鄰接關系配置多了一個外部小區(qū)數據配置。23G切換類業(yè)務故障排查思緒常見故障現象切換故障現象大致分為兩類：1．切換信令步驟不正確；2．CS切換信令正確，不過切換到2G后沒有聲音或有雜音；3．PS切換信令正確，不過切換后速率上不來；常見故障原因常見故障原因請參考REF_Ref\h表?2.61：表STYLEREF2\s2.6SEQ表\*ARABIC\s212/3G切換失敗常見原因表故障分類常見故障原因信令步驟不正確UE頻繁重選，造成電話無法撥通，不能切換；RNC沒有下發(fā)測量控制，或測量控制消息不正確；UE故障，沒有上報測量匯報；CN信令步驟異常造成切換失敗，比如CS從3G切換到2G不釋放Iu和Iub口資源，PS切換路由區(qū)更新失敗，PS切換沒有RAB指派等等；3G小區(qū)Iub口傳輸資源不夠使用（針對PS域切換）；3G小區(qū)無線資源不夠使用（針對PS域切換）；CS切換到2G后無聲或有雜音（CS不存在從2G到3G切換）請2G查看原因；PS切換后速率異常CN存在問題，能夠經過驗證多個RNC來確定；UU口用戶面數據包異常；RUB單板故障；終端故障；HS業(yè)務故障排查思緒常見故障現象1、物理信道重配置失??；2、終端無法接入；3、HS呼叫不成功；4、下載速率不理想。常見故障原因常見故障原因請參考REF_Ref\h表2.71：表STYLEREF2\s2.7SEQ表\*ARABIC\s21HS故障表格故障現象常見故障分類物理信道重配置失敗Sich和Prach配置碼道沖突；當配置有多條Scch/Sich時，不一樣Scch信道號是否沖突，不一樣Sich功率配置是否正確；沒有看到RNC發(fā)送給NODEB物理信道重配置消息（檢驗RNC和NODEB是否配置了支持HS）；RNC上參數配置錯誤；TBPE單板DSP0或DSP11有故障。終端無法接入這類問題能夠到CS類故障排查中查看原因HS呼叫不成功上行64k時，因為SF＝2，所以目標時隙僅存在連續(xù)8個上行空閑碼道是不夠；關鍵是看信令來定位下載速率不理想用數據卡而電腦未接外部電源，假如用數據卡測試，而便攜電腦無外部電源，此時速率會大大下降；數據卡是否存在過熱現象；終端收到信號強度是否足夠；Iub口配置帶寬是否足夠站點RTWP和ISCP過高，存在干擾；UE問題，比如死機；假如發(fā)覺承載Scch或承載下行伴隨Dpch時隙TCP（發(fā)射載波動率）較高，說明此時Ue接收信號不好，或已經有Ue工作不正常；假如發(fā)覺承載Hs－Dsch時隙發(fā)射載波功率波動較大，說明常常無用戶被調度，能夠查看NoData統(tǒng)計量，是否是因為無數據可發(fā)，所以常常下行發(fā)射載波動率會降低；假如功率無異常，但整體速率不高，則首先查看上報CQI值，假如CQI偏低，但Nack不多，則可能是因為外部HS-DSCH信道有干擾，但干擾還未大到產生Nack地步；NoAnswer較多，從現在情況來看，關鍵是因為測試點信號太差，只能換點測試查看LmtUe統(tǒng)計信息“上行信道TB塊數”和“上行信道錯誤TB塊個數”，假如發(fā)覺錯誤包過多，說明上行質量很差，假如發(fā)覺上行正確數據包過少（比如10幾），或幾乎沒有，則說明Ue應答包沒有發(fā)上來，能夠更換電腦重新測試。LMT上數據分析方法Ack、Nack、NoAnswer、NoData和重傳超時重傳超時參數說明了在NodeB物理層傳輸失敗，需要高層重傳次數，當存在大量重傳超時時，會造成速率大幅下降，此時下行Scch信道或Dsch信道質量可能較差，可經過Ack、Nack和NoAnswer數量確定。Ack表示Hsdpa數據傳輸正確，Nack表示Scch發(fā)送正確，但DSch數據Ue接收錯誤，NoAnswer表示Scch數據Ue接收錯誤。所以，Ack表示Scch和Dsch信道全部比很好，大量Nack表示Dsch信道可能有惡化，大量NoAnswer表示Scch信道可能存在惡化。當存在大量Nack或NoAnser時，因為物理層重傳影響，會造成下行速率降低，此時可能下行Scch信道或Dsch信道有惡化，可結合上報Cqi和發(fā)射碼功率及Aoa測量上報進行分析。Nodata表示NodeB調度該Ue時，該Ue無數據可發(fā)。NoData會造成空口速率下降，NoData最關鍵原因是因為Rnc無數據可發(fā)或Rnc發(fā)送窗滿，因為影響Rnc數據量和Rnc滑窗數據全部在上行伴隨Dpch上傳輸，所以出現NoData時，很可能上行伴隨Dpch信道質量已經下降了。上行伴隨Dpch數據Lmt提供了“上行信道TB塊數”和“上行信道錯誤TB塊個數”，這2可參數全部是一直累加，我們能夠經過差分計算出每上報周期（500ms）內上行伴隨Dpch正確數據塊個數和錯誤數據塊個數，而當錯誤數據塊個數較多時，說明Rlc層或應用層數據確定包未發(fā)送到發(fā)送端，此時就可能造成Rnc無數據可發(fā)或Rnc窗滿，造成NodeB無數據可發(fā)，最終造成空口速率下降。假如上行伴隨Dpch錯包較多，則能夠經過查看上行伴隨Dpch接收信號碼功率和SIR來具體分析。Cqi平均值該值由Ue上報到NodeB，NodeB依據Cqi值確定下行速率（下行發(fā)送數據包大?。?，Ue關鍵依據信道質量來確定Cqi值，但具體計算方法不祥，但Cqi下降表示Dsch信道有惡化，從實測數據看，Cqi對信道惡化敏感程度，不是很敏感（即惡化后，即使Cqi會降低，但還是會出現很多Nack）。發(fā)射碼功率和AOA測量下行發(fā)射碼功率應該保持一個較穩(wěn)定值，當發(fā)射碼功率忽然提升時，說明此時下行伴隨Dpch信道所在時隙信道質量可能有惡化（存在干擾），所以Ue要求NodeB提升發(fā)射功率，保持一定信噪比。對定點測試而言，Aoa測量值也應該保持一個定值，但尤其是在近場環(huán)境下，因為多徑影響，可能會造成Aoa測量有波動，當Aoa存在波動時，因為多徑效應影響，可能此時Ue下載速率會下降。接收碼功率和AOA測量從被測Sir能夠直接看出上行伴隨Dpch信道質量，假如Sir比較穩(wěn)定，但此時對應接收碼功率上升，說明此時上行信道有干擾，但干擾不是很嚴重，經過Ue提升發(fā)射功率，還能夠維持很好信道質量，假如Sir顯著下降，則說明此時上行伴隨Dpch已經惡化，且無法經過Ue提升功率來確保信道質量，此時能夠查看時隙Iscp（時隙干擾信號功率，在載波信息里），假如Iscp顯著上升，就明確了確實有較強干擾功率，假如Iscp無顯著改變，說明信道質量惡化可能是因為上行信號已經很弱了，應該能夠和接收信號碼功率對應起來。經典故障案例摘要本章舉多個經典案例，介紹多種業(yè)務類故障排查思緒。CS業(yè)務類經典案例手機開機后無法注冊網絡,從信令跟蹤上看信令沒有到CN,只有IUB口信令交互分析:信令沒有走到CN,只有IUB口信令交互,通常情況下是IUB口對接數據出了問題,具體例子以下：故障案例1【故障現象】手機開機后,出現RL鏈路無法抵達NODEB,造成RRC連接失敗,手機無法注冊,信令跟蹤見REF_Ref\h圖?3.11。圖STYLEREF2\s?3.1SEQ圖\*ARABIC\s21RL建立失敗之一【可能原因】RL建立是由NCP控制，如上是RL鏈路建立請求根本就沒有發(fā)送到NODEB,有可能NCP鏈路出了問題，而造成RL鏈路建立請求沒有發(fā)送到NODEB【處理方法】此時能夠經過OMP打印、探針和NblommTest命令查看NCP鏈路狀態(tài),故障案例2【故障現象】手機開機后,RL鏈路建立請求抵達NODEB后,NODEB直接給RNC回失敗應答,信令見REF_Ref\h圖?3.12。圖STYLEREF2\s?3.1SEQ圖\*ARABIC\s22RL建立失敗之二【可能原因】一塊TBPA板對應一條CCP，在RRC建立過程中，RNC向NODEB發(fā)送RL建立請求，NODEB檢測CCP鏈路狀態(tài)（其中包含最少有一條CCP狀態(tài)是好，CCP和TBPA板對應關系是好），若CCP鏈路狀態(tài)不對,NODEB就會給RNC回RL建立失敗消息【處理方法】能夠經過OMP打印、探針和NblommTest命令查看CCP鏈路狀態(tài);查看CCP鏈路對應PVCVPI\VCI是否對應，在NODEB上是否配置CCP和TBPA對應關系故障案例3【故障現象】手機開機后，無法注冊網絡，信令跟蹤上能夠看到，RL鏈路建立成功，不過IUB口傳輸承載沒有建立，造成RRC建立失敗見REF_Ref\h圖?3.13。圖STYLEREF2\s?3.1SEQ圖\*ARABIC\s23RL建立失敗之三【可能原因】當NODEB和RNC之間RL鏈路建立成功后，說明RNC和NODEB之間信令已通，下面就是經過ALCAP來建立IUB口數據傳輸承載，此時將包含到ALCAP鏈路好壞、NODEBATM地址、AAL2鏈路狀態(tài)。見REF_Ref\h圖?3.14。圖STYLEREF2\s?3.1SEQ圖\*ARABIC\s24IUb口承載原理圖【處理方法】此時經過NblommTest查看小區(qū)建立狀態(tài)，BCCS打印上有可能公共信道出現不停刪建情況b)能夠經過OMP打印，可能看到“A2SPestablishingfailed”消息c)若出現以上打印，請仔細查看NODEB和RNC側對接數據：ATM地址不對、AAL2鏈路標識不對、AAL2PVC不對、ALCAP不對從信令跟蹤跟蹤上看，IUB口信令已經走完，RNC初始到CN消息失敗故障案例1【故障現象】手機注冊時，RNC發(fā)送UE初始消息到CN，沒有收到CN回送任何消息，造成RRC連接釋放，手機注冊失敗，見REF_Ref\h圖?3.15。圖STYLEREF2\s?3.1SEQ圖\*ARABIC\s25位置更新失敗之一【可能原因】RNC初始到CNUE初始消息，需要用到到CN信令鏈路，若消息無法送到CN，有可能是抵達CN信令鏈路不通造成【處理方法】能夠對一下RNC和CN本局信令點、MGW信令點、到MGW鏈路SLC，這些全部需要和CN對應對一下到MGW信令鏈路PVCVPI\VCI是否和CN對應故障案例2【故障現象】手機注冊時，RNC發(fā)送UE初始消息到CN，CN立即回送reject消息，位置更新拒絕――>拒絕原因：networkfailed，見REF_Ref\h圖?3.16。圖STYLEREF2\s?3.1SEQ圖\*ARABIC\s26位置更新失敗之二【可能原因】RNC發(fā)送到CNUE初始消息攜帶網絡信息和UE信息，即LAC，MNC，MCC，LAC，還有UEIMSI號，若CN拒絕注冊信息，可能RNC側和CN側以上數據沒有對應【處理方法】a)RNC側LAC、MCC可能CN不對應。而MNC不對將引發(fā)緊急呼叫，LAC不對應不影響CS，不過會影響PS，即PS附著時被拒b)CN側沒有給SIM卡放號故障案例3【故障現象】RNC所帶全部基站下打電話，全部出現位置更新被拒,CN失敗觀察中顯示“(VLR)VDB中沒有保留用戶安全上下文”【原因及處理方法】CS域安全變量中全部鑒權選項全部關閉,而完整性控制打開,造成上述問題。后修改安全變量,打開全部鑒權選項,CS正常CS電話不通_IUUP初始化失敗故障【故障現象】新開通RNC局，新配置IuCS局向數據，位置更新成功，打電話出現RAB指派失敗現象。從信令上看，CN給RNC下發(fā)了RAB指派，RNC回復了失敗消息，解開來看是iu_up_failure，見REF_Ref\h圖?3.17。圖STYLEREF2\s?3.1SEQ圖\*ARABIC\s27Iu_up_failure【故障分析】1、從打印上排查：從上述步驟能夠看出我們要打開RCB單板上RNLCUCPMC，SCPM，RPM，ALCAP模塊打印；同時還要打開RUB單板上RNLUIUUP模塊打印（中級即可）2、本故障從RNLC打印中看到以下信息：RPI68:RcvdEVENT_SCPM_RPM_RAB_SETUPMsg!CnDomain:0：說明針對某個UERPI收到了SCPM發(fā)送過來RAB建立消息；RNLC_RPM-RPI68:SentIuUPSetupREQtoUCI_U16434!：RPI給在用戶面標識某個UEUCIU發(fā)送了IUUP建立消息；RNLC_RPM-RPI68:RcvdIuUPSETUPRspMsg!：UCIU回復了IUUP建立成功消息；RNLC_RPM-RPI68:SentA2SUESTREQtoA2SP!：RPI向A2SP發(fā)送了AAL2建立消息；ALCAP-AAL2SPMESSAGE:ReceiveECFmessage!ECF.OSAID=66910,ECF.DSAID=265128：RNCA2SP模塊收到了CN回復AAL2建立成功消息；RNLC_RPM-RPI69:RcvdEV_A2SP_A2SU_ESTABLISH_CONMsg!：RPI收到了A2SPAAL2建立成功消息；RNLC_RPM-RPI69:SentIuupConfigReqtoUCI_U28722!：RPI給IUUP發(fā)送了配置消息，也就是IUUP初始化；然后在查看RNLU打?。喊l(fā)覺：IUUP模塊在給CN發(fā)送了初始化消息以后，沒有收到響應消息；上述過程只是為了介紹一下整個步驟在打印中怎樣表現，具體排查故障時，不是這么一步步去看，能夠開始就搜索IUUP是否建立成功，然后看AAL2建立是否成功；也能夠搜索某個UERPM實例號，比如RPI68，經過查看這個UE打印步驟來找到犯錯地方。此時定位到AAL2建立有問題。3、使用命令查看APBE，RUB，UIMU單板收發(fā)包情況：初始化幀是從RUB單板經過UIMU送到APBE，在發(fā)送到CN去，反之從APBEUIMURUB;從那篇著名“cs&ps調試手冊”中相關怎樣排查IUUP初始化失敗指導能夠得到怎樣進行故障定位，排查結果是出光口有數據，不過進光口沒有數據，更換了光纖后問題依舊，所以請CN同事查找問題原因，具體怎樣查看光口是否有數據在APBE單板上敲入以下命令：AtmlmShowPvcByStatus：查看PVC配置情況；BSP_PrintSet0x20,1：打開包統(tǒng)計打印；apcReadIVT0,0,vpi,vci：查看出光口是否有數據；apcReadEVT0,Connectiontag：其中Connectiontag需要從上一個命令中得到；apcReadIVT0,光口號，cvpi,cvci：查看進光口是否有數據；apcReadEVT0,Connectiontag：其中Connectiontag需要從上一個命令中得到；以我們這個環(huán)境為例，說明一下命令使用情況：APBE->AtmlmShowPvcByStatusPVC(CR_STATUS=0)LIST:PVCIDSTATR_UNITRPHYR_VPIR_VCIB0_UNITB0PHYB0_VPIB0_VCIB1_UNITB1PHYB1_VPIB1_VCI10110132115550--------30110033115150--------140110133116550--------150110034116150--------PVC'scountis4whichCr_Status=0.value=40=0x28='('APBE->BSP_PrintSet0x20,1ZTE3GUPBSPPrintSystemSettingFLAGSFLAGNAMESTATUS0x00000001BSP_DEBUG_INITOFF0x00000002BSP_DEBUG_RXOFF0x00000004BSP_DEBUG_TXOFF0x00000008BSP_DEBUG_INTOFF0x00000010BSP_DEBUG_STATUSOFF0x00000020BSP_DEBUG_INFOON0x00000040BSP_DEBUG_CTRLOFF0x00000080BSP_DEBUG_ERROROFF0x00000100BSP_DEBUG_RESETOFF0x00000200BSP_DEBUG_POLL_RXOFF0x00000400BSP_DEBUG_POLL_TXOFF0x00000800BSP_DEBUG_USR_LOWOFF0x00001000BSP_DEBUG_USR_MIDOFF0x0000BSP_DEBUG_USR_HIGHOFF0x00004000BSP_DEBUG_USR_URGENTOFFvalue=0=0x0APBE->apcReadIVT0,0,1,33ConnectiontypeofthePVC:VCconnection.ActivestateoftheVCis:1thevcIndexis1025lowbankFPortBitmap[30:0]is:0x1ISEFCIis:0x0IEDEnis:0x0IPDEn:0x0DestSubport:0x0QNR:0x0IGI:0x1IBE:0x101ICapF:0x0ITrClass:0x0IVQLength:0x0CCSource:0x0CCSink:0x0FMState:0x0FMDefType:0x0FMVPPropEn:0x0IPDIMCFilterPtr:0x0TST:0x0ICLPT:0x1ConnectionTag:0x3f7highbankFPortBitmap[39:31]:0x0IncrAState:0x0LimitA:0x0PolCFigA:0x0PMonEn:0x0ITotCellsRx:24ITotCellsTx:24TATA:0xa2272400TATB:0xa2272400IncrB:0x0LimitB:0x0PolCFigB:0x0value=0=0x0APBE->apcReadIVT0,6,5,50ConnectiontypeofthePVC:VCconnection.ActivestateoftheVCis:1thevcIndexis1026lowbankFPortBitmap[30:0]is:0x1ISEFCIis:0x0IEDEnis:0x0IPDEn:0x0DestSubport:0x0QNR:0x0IGI:0x1IBE:0x101ICapF:0x0ITrClass:0x0IVQLength:0x0CCSource:0x0CCSink:0x0FMState:0x0FMDefType:0x0FMVPPropEn:0x0IPDIMCFilterPtr:0x0TST:0x0ICLPT:0x1ConnectionTag:0x23f7highbankFPortBitmap[39:31]:0x0IncrAState:0x0LimitA:0x0PolCFigA:0x0PMonEn:0x0ITotCellsRx:0ITotCellsTx:0TATA:0xbdb34400TATB:0xbdb34400Incr