HSDPA130故障排查手冊

1、基站故障手冊DSP 開發(fā)部算法科 Symbol 開發(fā)組2008-6-10修改記錄版本號擬制人/修改人擬制/修改日期更改理由主要更改內(nèi)容（寫要點即可）徐曉聃2008-6-10無創(chuàng)建注1：每次更改歸檔文件（指歸檔到事業(yè)部或公司檔案室的文件）時，需填寫此表。注2：文件第一次歸檔時，“更改理由”、“主要更改內(nèi)容”欄寫“無”。目錄1概述52工具53故障5速率較差7NACK數(shù)目多7平均CQI接近最大碼率7周期性NACK較多7凱明終端8重郵終端8無特定規(guī)律8No Data較多8灌包速率正常8灌包速率不正常9SICH miss較多9單SCCH10多SCCH10凱明終端10重郵終端10平均CQI較低11速率呈梳

2、狀11單UE11多UE11其他12CQI出現(xiàn)異常值12凱明終端且上下行在時隙切換點旁12速率恢復(fù)很慢12保持不住12UE發(fā)起PDP去激活12RTWP或ISCP過高13無線鏈路失敗13速率低13其他14BLER與配置目標(biāo)不一致14GBR無法滿足141 概述本文基站HSDPA故障排查，同時用于故障總結(jié)和分析，為日后開發(fā)和維護(hù)提供資料。2 工具表 2.1名稱用途來源LMT查看基帶長期統(tǒng)計信息，包括流量，物理層性能等內(nèi)容隨版本發(fā)布DSP監(jiān)控工具查看基帶打印信息，修改全局變量等DSP監(jiān)視和控制工具隨版本發(fā)布VTCDLogViewNodeB單板軟件狀態(tài)監(jiān)控工具隨版本發(fā)布OMCRRNC后臺網(wǎng)管工具，用于修改

3、配置參數(shù)，查看iub口信令等隨版本發(fā)布DUMeterPC端流量統(tǒng)計工具商業(yè)軟件Flashget下載工具，注意須使用1.x版本，可以控制線程數(shù)目商業(yè)軟件3 故障故障排查可以參考圖3.1故障索引，從故障樹根部鑒別故障現(xiàn)象，直至找到最頂葉故障，得到故障索引，即可從本文中得到故障原因和解決方法。其中有些故障出現(xiàn)多種故障現(xiàn)象，可逐個排查解決。附件為MindMananger格式的故障索引圖，以供未來修改使用。圖 3.1 故障索引圖3.1 速率較差現(xiàn)象描述：DUMeter看到UE速率較差，達(dá)不到空口能力。故障分析：待子Case進(jìn)一步分析解決方法：待子Case進(jìn)一步分析3.1.1 NACK數(shù)目多現(xiàn)象描述：關(guān)閉

4、NodeB CQI外環(huán)處理，即修改相應(yīng)載波的DSP全局變量gatBhsmDebugPack. tDebugCtrl. ucCqiOutLoop為0(DSP監(jiān)控工具)，NACK平均數(shù)目(LMT)較高，高于15%以上。故障分析：待子Case進(jìn)一步分析解決方法：待子Case進(jìn)一步分析3.1.1.1 平均CQI接近最大碼率現(xiàn)象描述： 平均CQI(LMT)接近當(dāng)前碼道最大碼率，如表3.1所示。表 3.1UE能力等級最大碼率對應(yīng)CQI1TS DSCH2TS DSCH3TS DSCH4TS DSCH5TS DSCH134563-465063-79445763-101241525963131539505660

5、63故障分析：由于最高碼率基本上沒有編碼冗余，因此對空口環(huán)境要求很高。13的手機在室內(nèi)環(huán)境可能達(dá)到，其余16QAM手機基本無法滿足。但由于手機一般上報CQI高于其接收能力，因此可能會出現(xiàn)無法接收正確其要求的CQI現(xiàn)象。解決方法：修改OAM參數(shù)wSchMaxTbsEn為03.1.1.2 周期性NACK較多現(xiàn)象描述：NACK每隔一段時間突發(fā)性增多，呈周期性變化。故障分析：待子Case進(jìn)一步分析解決方法：待子Case進(jìn)一步分析3.1.1.2.1 凱明終端現(xiàn)象描述：使用終端為凱明終端。故障分析：凱明終端自帶CQI外環(huán)，會根據(jù)接收BLER自行調(diào)節(jié)CQI。如果信道條件較好會上調(diào)CQI，從而導(dǎo)致接收不正確，

6、接下來自行調(diào)節(jié)回能正確接收等級。這個過程會周期性發(fā)生。解決方法：無。3.1.1.2.2 重郵終端現(xiàn)象描述：使用終端為重郵終端。故障分析：目前原因未知，猜測與凱明終端自身能力有關(guān)。其特點是在CQI一定的情況下仍然發(fā)生周期性NACK增多的現(xiàn)象，下調(diào)CQI并不能改善這個現(xiàn)象。 解決方法：無。3.1.1.3 無特定規(guī)律現(xiàn)象描述：發(fā)生NACK的次數(shù)和頻度并無特定規(guī)律故障分析：發(fā)生NACK說明譯碼發(fā)生錯誤，難以明確定位，但一般與空口質(zhì)量或者UE解調(diào)能力有關(guān)系。 解決方法：檢查下行3.1.2 No Data較多現(xiàn)象描述：平均No Data(未接收到數(shù)據(jù))數(shù)目較多(LMT)。故障分析：待子Case進(jìn)一步分析解

7、決方法：待子Case進(jìn)一步分析3.1.2.1 灌包速率正?，F(xiàn)象描述：停止下載，使用RNC的灌包功能(VTCD上輸入SetHsdpaFlag 1) ,觀察速率，速率符合空口容量。故障分析：RNC灌包是從PDCP層發(fā)送數(shù)據(jù)的，因此故障發(fā)生在非接入層。解決方法：1. 更換下載終端，包括PC機，下載軟件或者終端。2. 增加或減少下載線程數(shù)。經(jīng)驗表明，一般4線程下載能得到較好的速率。3. 檢查上行鏈路，是否上傳的TCP包被正確接收。4. 擴大上行鏈路容量，經(jīng)驗表明，上行64kbps可以滿足絕大多數(shù)業(yè)務(wù)，但低于此值在高速率時有影響。備注：也可以通過觀察RLC緩存數(shù)據(jù)量定位，如果RLC緩沖區(qū)數(shù)據(jù)量。通過DS

8、P監(jiān)控工具觀看BHSM模塊打印，中間RlcDataSize即表征RLC緩沖數(shù)據(jù)量，經(jīng)驗表明，低于2000左右時已經(jīng)非常小。3.1.2.2 灌包速率不正?，F(xiàn)象描述：停止下載，使用RNC的灌包功能(VTCD上輸入SetHsdpaFlag 1) ,觀察速率，速率仍然不符合空口容量。故障分析：灌包仍然不正常說明問題發(fā)生在接入層，發(fā)生故障的原因也有很多，目前已知的有：1. Iub口丟包，或者帶寬不夠發(fā)生擁塞。2. 申請業(yè)務(wù)流量不足以滿足空口容量。3. 空口丟包導(dǎo)致RLC窗卡死無法滑動，如NACK過多，或者Discard timer定時器刪除超時包等。4. 上行RLC包接收不對，或者延時過大。解決方法：1

9、. 檢查Iub接口a) 檢查BCCS板，老版本的BCCS板無法承受過高速率，發(fā)生丟包；b) 檢查IIA板，是否IIA板丟包(LogView登錄IIA板，輸入m2，觀察是否發(fā)送接收包數(shù)目相等)；c) 檢查AAL2鏈路帶寬是否滿足速率要求，AAL2有保留帶寬，因此配置的帶寬必須大于業(yè)務(wù)速率才可。2. 檢查申請的業(yè)務(wù)，需要根據(jù)RNC信令RAB配置，檢查業(yè)務(wù)速率和保證速率。3. 檢查空口是否正常，以及MAC-HS配置(如T1，Discard timer是否過小等等)，可進(jìn)一步參考章節(jié)。4. 檢查上行是否正常，或者提升上行伴隨信道帶寬。經(jīng)驗表明，上行64kbps可以滿足絕大多數(shù)業(yè)務(wù)，但低于此值在高速率時

10、有影響。5. 把相關(guān)業(yè)務(wù)改為RLC-UM模式，以排除RLC層滑窗的影響，有利于進(jìn)一步排查問題。3.1.3 SICH miss較多現(xiàn)象描述：平均SICH miss (丟失)數(shù)目較多(LMT)，或者SICH誤解碼/虛警較多(DSP監(jiān)控工具查看BHSM打印，SICH上報TbsIdx出現(xiàn)異常值)。注意到室內(nèi)環(huán)境一般不會出現(xiàn)。故障分析：待子Case進(jìn)一步分析解決方法：待子Case進(jìn)一步分析3.1.3.1 單SCCH現(xiàn)象描述： 系統(tǒng)配置SCCH僅一條故障分析： 出現(xiàn)這種故障一般問題都發(fā)生在功控上，SICH或者SCCH功率過低都有可能導(dǎo)致這種故障。解決方法：1. 檢查SCCH/SICH功率配置，包括最大最小

11、發(fā)送功率，SICH目標(biāo)SIR target，SCCH 目標(biāo)BLER?？梢赃m量提高功率配置，減小BLER配置，看是否有改善。2. 檢查物理層TPC字和所測到的SIR是否正常(DSP監(jiān)控工具查看BPCM和DBPCM打印)。目前系統(tǒng)的功控經(jīng)過長期驗證，應(yīng)該沒有問題，出現(xiàn)這種問題，應(yīng)重點關(guān)注是否UE的功控有問題。3.1.3.2 多SCCH現(xiàn)象描述： 系統(tǒng)配置SCCH多條故障分析：待子Case進(jìn)一步分析解決方法：待子Case進(jìn)一步分析3.1.3.2.1 凱明終端現(xiàn)象描述：使用終端為凱明終端。故障分析： 凱明終端在切換SCCH時會發(fā)生丟失SCCH的現(xiàn)象。這個問題目前沒有找到原因，但可以確認(rèn)是終端問題。解決

12、方法：無備注：在系統(tǒng)配置RR調(diào)度算法，且連續(xù)調(diào)度次數(shù)較低時，這個問題可能會同時引發(fā)SICH上行功率過高。3.1.3.2.2 重郵終端現(xiàn)象描述：使用終端為重郵終端。故障分析： 重郵終端在某些情況下，多個SCCH會導(dǎo)致其SICH丟失頻率提高，原因未知，可能和功控有關(guān)系。新版本似乎已經(jīng)沒有這個現(xiàn)象了。解決方法：提高SICH目標(biāo)SIR有助于改善這個問題。3.1.4 平均CQI較低現(xiàn)象描述：平均CQI較低故障分析：CQI是UE接收質(zhì)量的直接量化值。因此空口質(zhì)量和設(shè)備/UE解調(diào)能力是決定CQI的唯一因素。解決方法： 1. 檢查下行，改善下行質(zhì)量。如增加DSCH功率，減少干擾等等，使用屏蔽箱或者有線直連有利

13、于排查問題。2. UE射頻或解調(diào)能力限制。3. 系統(tǒng)射頻或調(diào)制能力限制。4. 改善覆蓋。3.1.5 速率呈梳狀現(xiàn)象描述：DuMeter上速率表現(xiàn)為周期性深溝，呈梳狀。故障分析：待子Case進(jìn)一步分析解決方法：待子Case進(jìn)一步分析3.1.5.1 單UE現(xiàn)象描述：下載終端UE數(shù)目少于SCCH數(shù)目故障分析：單UE對NodeB而言相當(dāng)于專有信道，因此速率發(fā)生梳狀一般發(fā)生在高層。目前已知的故障有：由于TCP狀態(tài)包未及時回傳，導(dǎo)致TCP窗卡死，周期性reset后方可下發(fā)數(shù)據(jù)，從而出現(xiàn)梳狀。這個故障與RNC一個bug有關(guān)。 解決方法：減少下載線程數(shù)，可有效改善此現(xiàn)象。解決此故障需RNC和CN人員排查。3.

14、1.5.2 多UE現(xiàn)象描述：下載終端UE多于SCCH數(shù)目故障分析：多UE下由于PF算法調(diào)度測量的關(guān)系，調(diào)度間隔較長，使得UE數(shù)據(jù)發(fā)送有明顯間隔，出現(xiàn)深溝。 解決方法：以下方法可有效改善，但由于PF算法的特點，除第一種方法外，不可能完全解決：1. 修改wSchOrigAlgSel為1，改為RR調(diào)度算法；2. 修改OAM參數(shù)，增大wSchPfrRFctr，改善調(diào)度間隔；3. 修改OAM參數(shù)，修改wSchPfQosAlgSel為3，選擇QOS算法。3.1.6 其他3.1.6.1 CQI出現(xiàn)異常值現(xiàn)象描述：SICH上報TbsIdx出現(xiàn)異常值(DSP監(jiān)控工具查看BHSM模塊打印)故障分析：協(xié)議規(guī)定UE必

15、須在可能的范圍內(nèi)盡可能早的上報CQI，但不同UE的實現(xiàn)情況不一樣，因此可能使得系統(tǒng)和UE所計算的RU數(shù)目不一致，導(dǎo)致系統(tǒng)下發(fā)TBS不能滿足UE要求。解決方法：修改gatBhsmDebugPack. tDebugCtrl. ucCqiOutLoop，為0時關(guān)閉提前上報，為1時提前上報。(DSP監(jiān)控工具)注意有延時，需要約半分鐘生效。備注：此故障可能與.1有關(guān)系，需參考分析。3.1.6.2 凱明終端且上下行在時隙切換點旁現(xiàn)象描述：凱明終端，且該UE上下行碼道在時隙切換點兩旁，如2/4配置，UE上行伴隨在時隙2，DSCH在時隙3。故障分析：終端方案問題，在切換點旁會使得下行接收效果較差 解決方法：修

16、改該終端的上下行位置，使得其不在時隙切換點旁，如2/4配置，UE上行伴隨在時隙2，DSCH遷至?xí)r隙4。3.1.6.3 速率恢復(fù)很慢現(xiàn)象描述：UE速率較低且平穩(wěn)后會逐漸恢復(fù)，但恢復(fù)時間很長 故障分析：由于CQI外環(huán)算法的影響，目前采用的方法是下調(diào)快，上調(diào)慢，因此會造成這種現(xiàn)象。 解決方法：關(guān)閉CQI外環(huán)，即修改相應(yīng)載波的DSP全局變量gatBhsmDebugPack. tDebugCtrl. ucCqiOutLoop為0(DSP監(jiān)控工具)?；蛘咝薷纳险{(diào)系數(shù)，減小OAM參數(shù)中的wSchTbsUpThr數(shù)值。3.2 保持不住現(xiàn)象描述：UE無法長期保持在線，或者頻繁發(fā)起Cell Update流程。故障

17、分析：待子Case進(jìn)一步分析解決方法：待子Case進(jìn)一步分析3.2.1 UE發(fā)起PDP去激活現(xiàn)象描述：接入流程順利，但UE主動發(fā)起去激活。灌包模式下可能看到短暫速率或者撥號軟件報告PPP協(xié)議終止。故障分析：發(fā)生故障的原因一般是無法滿足UE的需求。解決方法：檢查RAB配置，是否不滿足UE要求的接入/保證速率。檢查UE的配置，以及AT命令REQ和MIN兩組命令。備注：有些情況下PC端軟件甚至PC本身也會導(dǎo)致這種情況，可嘗試更換PC端以排除此情況。3.2.2 RTWP或ISCP過高現(xiàn)象描述：接收寬帶總功率RTWP或者干擾總功率ISCP過高(LMT)。正常情況下一般都在-110db左右。故障分析：RT

18、WP和ISCP都是上行空口質(zhì)量的重要表征，出現(xiàn)這種情況要排除空口干擾。解決方法：1. 檢查空載下RTWP和ISCP，排除設(shè)備自身問題或干擾源。2. 逐次接入UE，檢查UE所引起的RTWP或者ISCP提升，排除UE問題。這種現(xiàn)象在重郵終端上尤為頻繁。3. 增大調(diào)度算法連續(xù)調(diào)度次數(shù)，OAM參數(shù)wSchContinueNum。凱明手機可能會出現(xiàn)這種問題。備注：需甄別SICH和上行伴隨碼道。由于SCCH/SICH功控的固有缺陷，SICH發(fā)生問題的可能性較高。3.2.3 無線鏈路失敗現(xiàn)象描述：NodeB或者UE上報無線鏈路失敗。 故障分析：無線鏈路失敗是伴隨信道發(fā)生失步，一般原因是干擾或者功率受限。解決方法：1. 檢查上下行覆蓋，增大功率授權(quán)。2. 檢查上下行干擾。3. 接入較多UE時有時減少基站期望接收功率可能能改善。3.2.4 速率低現(xiàn)象描述：UE速率很低，UE上報Cell Update的原因是RLC不可恢復(fù)故障。 故障分析：UE速率較低時，NodeB緩存數(shù)據(jù)硫量很低，導(dǎo)致RLC層狀態(tài)包無法及時下發(fā)，導(dǎo)致RLC reset直