C-EVDORev.A經(jīng)典案例.ppt

C-EVDO Rev.A經(jīng)典案例,ISSUE 1.01,Page 2,了解1xEV-DO Rel0及DO RevA常見問題及其處理過程 掌握1xEV-DO Rel0及DO RevA的問題處理思路，測試方法，分析手段 通過案例的學(xué)習(xí)，盡快定位問題,學(xué)習(xí)完本課程，您將會：,目 標(biāo),Page 3,第1章 EVDO接入案例 第2章 EVDO掉話案例 第3章 EVDO速率案例 第4章 EVDO切換案例 第5章 EVDO其他案例,內(nèi)容介紹,Page 4,EVDO接入問題分類及分析建議,影響EVDO接入的主要問題： 1、會話建立過程中配置協(xié)商失敗 2、AN AAA/AAA鑒權(quán)失敗 3、接入?yún)?shù)設(shè)置不合理 4、覆蓋、容量問題 5、數(shù)據(jù)配置問題 6、單板異常、故障 分析建議： 1、為了減少不必要的流程，數(shù)據(jù)配置時(shí)應(yīng)盡量使用協(xié)議規(guī)定的缺省值； 2、跟蹤信令確認(rèn)鑒權(quán)結(jié)果（如鑒權(quán)失敗，需要進(jìn)一步在AAA服務(wù)器上檢 查用戶信息） 3、常用接入?yún)?shù)優(yōu)化 4、功率控制參數(shù)優(yōu)化 5、檢查業(yè)務(wù),Page 5,EVDO接入問題分類及分析建議,Page 6,EVDO接入案例AN AAA鑒權(quán),有時(shí)終端不主動發(fā)起接入鑒權(quán)，導(dǎo)致會話建立總是失敗，這時(shí)使用QPST工具檢查終端的設(shè)置。終端必須在1xEV界面配置了NAI和Password信息才會主動發(fā)起接入鑒權(quán)。 目前我司EVDO系統(tǒng)通過SMP軟參可以關(guān)閉接入鑒權(quán)過程，以便于沒有鑒權(quán)需求的展覽和外部測試局點(diǎn)節(jié)約成本，但涉及雙模切換項(xiàng)目時(shí)，為保證終端在EVDO系統(tǒng)獲得正確的“IMSI”，必須提供AN-AAA并配置正確的IMSI。 通過對維護(hù)臺上對A12接口的消息跟蹤來對分析AN AAA的鑒權(quán)問題,Page 7,EVDO接入案例AcAck消息多次重發(fā)導(dǎo)致DO會話建立成功率低 （1）,【現(xiàn)象描述】 在DO會話建立過程中，發(fā)現(xiàn)大量因?yàn)镠ardwareIDResponse消息沒有收到造成的會話建立失敗，經(jīng)過對比cait log和基站主控調(diào)試臺的信令，發(fā)現(xiàn)cait上顯示發(fā)出的HardwareIDResponse在基站并沒有收到。 【處理過程】 1、 分析現(xiàn)場數(shù)據(jù)話統(tǒng)：從話統(tǒng)數(shù)據(jù)中，發(fā)現(xiàn)Session Setup Failure的主要原因是NoHardWareIDRspReceived和NoUATICompleteReceived。 2、 通過對比分析現(xiàn)場的配置數(shù)據(jù)和實(shí)驗(yàn)室鏡像環(huán)境的開關(guān)狀態(tài)，發(fā)現(xiàn)現(xiàn)場的BTS打開了異步消息重發(fā)開關(guān)，從CAIT的消息中也可以看到BTS對異步控制信道上的ACACK Message和HardwareIDRequest Message都進(jìn)行了重發(fā)。打開測試環(huán)境的BTS的異步消息重發(fā)開關(guān)，此時(shí)出現(xiàn)了AT發(fā)送了HardwareIDResponse Message，而BTS未收到對應(yīng)的這條消息的會話建立失敗，因此推斷異步消息的重發(fā)對會話建立成功率有很大的影響。,Page 8,EVDO接入案例AcAck消息多次重發(fā)導(dǎo)致DO會話建立成功率低（2）,3、將此問題提交給高通，高通給出如下答復(fù)： a) From the log, while AT is sending the AC MAC capsule, AN sends the ACAck to terminate the sending. AN should not do that, if AN does not receive any AC MAC capsules. AC message printed out in Log means AC message has been packeted and ready to be sent. it does not mean this massage has been sent out. b) As we discussed, An should send ACAck while recieving access MAC capsule. According to standard, one ACAck is corresponding to dedicated one access MAC capsule. AN should not send more than one ACAck for one access MAC capsule. 【結(jié)論】 打開控制信道異步消息重發(fā)開關(guān)后，要將AcAck消息重發(fā)次數(shù)設(shè)置為0（默認(rèn)值是2，既重發(fā)3次）。,Page 9,EVDO接入案例接入搜索窗設(shè)置問題導(dǎo)致終端無法接入 （1）,【現(xiàn)象描述】 某EVDO實(shí)驗(yàn)局BSC版本為BSC6600-OMCV200R001ENGC01B010，BTS版本為BTS3612-OMCV200R001ENGC01B011，組網(wǎng)情況為1CBSC、2BTS，其中A站為S222站型(PN:8、176、344)、B站為S22(PN:324、492)站型，EVDO采用160頻點(diǎn)。 在覆蓋測試的過程中，關(guān)閉高通終端的接收分集增益，從基站處開始INCAR下載數(shù)據(jù)，業(yè)務(wù)保持到25公里左右就由于無線環(huán)境的原因產(chǎn)生掉話，掉話地點(diǎn)終端的接收電平在-90至-100dBm之間波動，發(fā)射電平在+13至+23dBm之間波動，C/I總小于-10db， 將終端拿到車外，進(jìn)行OUTDOOR STATIONARY測試，發(fā)現(xiàn)終端無法接入AN。設(shè)置DM2K連續(xù)短呼，從掉話點(diǎn)沿原路返回，在信號質(zhì)量比較好的地方也無法接入，直到距離靠近基站約15公里的地方才能正常接入，當(dāng)時(shí)的接收電平在-79至-86dBm之間波動，發(fā)射電平在-2左右波動，C/I為3db左右。 【處理過程】 1、 通過DM2K測試數(shù)據(jù)的回放，查看15公里內(nèi)的呼叫建立情況，發(fā)現(xiàn)信令流程正常，呼叫正常建立。但查看15公里之外的呼叫建立情況的時(shí)候，在手機(jī)發(fā)送ROUTE UPDATE和CONNECTION REQUEST消息后，空口無AN的應(yīng)答和TCA信令，因此手機(jī)提高功率繼續(xù)試探，仍無法接入。 2、 從BSC DEBUG調(diào)試臺上跟蹤信息，在15公里內(nèi)呼叫的時(shí)候，DEBUG看到的信令正常。但是在15公里之外呼叫的時(shí)候，BSC沒有收到手機(jī)的ROUTE UPDATE和CONNECTION REQUEST消息，說明問題出在BTS。 3、 查看是否有反向干擾，TELNET查看RSSI，長時(shí)間查看，結(jié)果該扇區(qū)的RSSI正常。,Page 10,EVDO接入案例接入搜索窗設(shè)置問題導(dǎo)致終端無法接入 （2）,4、 從空口看，15公里外呼叫的時(shí)候，信令已經(jīng)發(fā)送了，由于信號情況良好，沒有反向干擾，BTS應(yīng)該是收到了消息，但是不能處理或處理錯(cuò)誤。 5、 懷疑為反向接入搜索窗口的設(shè)置導(dǎo)致了基站不能處理手機(jī)上報(bào)消息，咨詢相關(guān)開發(fā)人員，了解到該版本的反向接入搜索窗口算法存在問題，導(dǎo)致最大的接入半徑為16公里。 6、 該版本的小區(qū)接入搜索窗口為128CHIPS，1CHIP相當(dāng)于244米，因此128*244=31.2公里左右，由于是往返，所以為15.5公里左右，因此只能在約15公里的范圍內(nèi)接入。而反向業(yè)務(wù)搜索窗的半徑是以手機(jī)上報(bào)位置為中心，以16公里為半徑的范圍。 該問題最終通過修改接入搜索窗口為512CHIPS（接入半徑理論值為64公里），問題解決。 【建議】 基站的搜索窗口對覆蓋的影響很大，反向的接入搜索窗口和業(yè)務(wù)搜索窗口要一致，如果兩者不一致，將會導(dǎo)致在某些區(qū)域手機(jī)在接入過程中的接收信號顯示良好，發(fā)射電平高的現(xiàn)象，與反向鏈路存在干擾問題現(xiàn)象類似，特別是在小區(qū)邊緣，信號覆蓋相對差一些的情況下，容易被誤認(rèn)為是反向干擾，建議在優(yōu)化過程中加以關(guān)注。,Page 11,EVDO接入案例BECM單板問題導(dǎo)致EVDO終端無法接入,【現(xiàn)象描述】 某EVDO局BSC版本為BSC6600-OMCV200R001ENGC01B010，BTS版本為BTS3612-OMCV200R001ENGC01B011，在測試過程中，發(fā)現(xiàn)PN324扇區(qū)出現(xiàn)信號很好但是始終無法接入的現(xiàn)象，在該扇區(qū)的近點(diǎn)，C/I達(dá)到了12-15之間，DRC達(dá)到了2.4576M的地點(diǎn)進(jìn)行測試，結(jié)果還是不能接入，而在之前對該扇區(qū)的測試中，沒有發(fā)現(xiàn)類似的現(xiàn)象。 【處理過程】 1、由于前一天對該扇區(qū)的覆蓋情況進(jìn)行過測試，也進(jìn)行過ACCESS和單用戶吞吐量的相關(guān)測試，并沒有出現(xiàn)過該問題。硬件安裝沒有變，軟件上只是昨天進(jìn)行了一次針對BSC的軟件升級，復(fù)位了BSC。 2、使用DM2K進(jìn)行空口消息跟蹤，發(fā)現(xiàn)在AT發(fā)起呼叫后，向AN發(fā)送ROUTE UPDATE和CONNECTION REQUEST，但是AN側(cè)對消息沒有響應(yīng)，沒有相應(yīng)的AC ACK和TRAFFIC CHANNEL ASSIGNMENT消息，因此無法接入。 3、在調(diào)試臺上跟蹤SPU，收到MS上報(bào)的接入請求，之后前向進(jìn)行業(yè)務(wù)指配，發(fā)TRAFFIC CHANNEL ASSIGNMENT給MS,然而手機(jī)卻沒有收TRAFFIC CHANNEL ASSINMENT消息，這一點(diǎn)在DM2K的測試過程中從信令可以看出。因此懷疑消息在經(jīng)過BTS處理的時(shí)候發(fā)生了錯(cuò)誤。 4、在BTS側(cè)也進(jìn)行ABIS口的跟蹤，得到的結(jié)果顯示BSC下發(fā)的TRAFFIC CHANNEL ASSIGNMENT消息被下到另外的扇區(qū)里了，手機(jī)接不到指配消息，所以無法接入。同時(shí)發(fā)現(xiàn)ROUTE UPDATE消息在經(jīng)過BECM板處理后，增加消息頭的時(shí)候發(fā)生錯(cuò)誤，從而導(dǎo)致TCA消息下發(fā)的目標(biāo)小區(qū)發(fā)生錯(cuò)誤，導(dǎo)致呼叫建立失敗。因此故障基本定位為該BECM板內(nèi)部有問題導(dǎo)致了無法正常接入的現(xiàn)象。 【結(jié)論】 該問題基本定位為單板內(nèi)部的軟件問題導(dǎo)致，從現(xiàn)象看單板在系統(tǒng)復(fù)位后，單獨(dú)對BECM板進(jìn)行一次復(fù)位，之后就不會出現(xiàn)這種現(xiàn)象，否則，可能會出現(xiàn)該問題。規(guī)避方法每次系統(tǒng)復(fù)位后，對BECM單板進(jìn)行復(fù)位，以規(guī)避該問題。,Page 12,EVDO接入案例1X與DO業(yè)務(wù)鏈路標(biāo)識沖突導(dǎo)致DO無法上網(wǎng)（1）,【現(xiàn)象描述】 N國S局CDMA 1xEVDO 1900網(wǎng)絡(luò)，1PDSN/1PCF/1AN/16BTS/48carrier，使用頻點(diǎn)613，S4/4/4配置，其中S3/3/3 for 1X，S1/1/1 for DO。路測到某基站A（升級網(wǎng)方式的DO基站）掉話，之后在該基站三個(gè)扇區(qū)下始終無法建立PPP連接。該基站當(dāng)前沒有任何未恢復(fù)告警。BSC版本V200R001C02B018 【處理過程】 1、在其他區(qū)域測試可以正常上網(wǎng)，確定并非整網(wǎng)問題，可以排除PCF上層的問題； 2、替換終端測試，現(xiàn)象依舊，排除終端問題，發(fā)生問題前終端一直使用正常，排除鑒權(quán)問題； 3、知會機(jī)房人員檢查該基站告警，由于不是單個(gè)載頻的問題，重點(diǎn)檢查了信道板芯片和時(shí)鐘板等的狀態(tài)，并沒有異常； 4、路測分析空口質(zhì)量良好，各指標(biāo)達(dá)到近點(diǎn)水平，但DRC一直維持在76.8kbps，終端側(cè)的信令分析，會話建立流程沒有完成，AT發(fā)送connectionrequest并沒有收到TCA消息，而是收到CC（控制信道）下發(fā)的connectiondeny消息，原因值”network busy”以及”protocol error”，從而結(jié)束流程； 5、問題集中在AN側(cè)為什么不能分配業(yè)務(wù)信道上以及為什么出現(xiàn)“協(xié)議錯(cuò)誤”這樣的錯(cuò)誤，類似地，可能是空口、CE、地面鏈路資源有問題。在BSC側(cè)繼續(xù)進(jìn)行用戶接口跟蹤，AT發(fā)的connectionrequest收到后，BSC直接釋放abis鏈路，如圖：,Page 13,EVDO接入案例1X與DO業(yè)務(wù)鏈路標(biāo)識沖突導(dǎo)致DO無法上網(wǎng)（2）,6、用LST BTSLNK檢查Abis鏈路配置，發(fā)現(xiàn)該基站一條1X鏈路和DO鏈路配置相同的業(yè)務(wù)鏈路標(biāo)識”1-248-3”，問題找到了，該基站從S3/3/3擴(kuò)容到S4/4/4時(shí)增加新的業(yè)務(wù)鏈路配置錯(cuò)誤導(dǎo)致DO載頻無法建立業(yè)務(wù)鏈路，DO無法上網(wǎng)。 7、維護(hù)臺上LST BTSLNK檢查，修改該基站的業(yè)務(wù)鏈路配置，測試DO業(yè)務(wù)恢復(fù)正常。 【結(jié)論】 這種鏈路配置錯(cuò)誤在維護(hù)臺上不會禁止執(zhí)行，也不會引起告警，有一定的隱蔽性，OMC對abis的容錯(cuò)和性能監(jiān)控方面應(yīng)加強(qiáng)。,Page 14,第1章 EVDO接入案例 第2章 EVDO掉話案例 第3章 EVDO速率案例 第4章 EVDO切換案例 第5章 EVDO其他案例,內(nèi)容介紹,Page 15,EVDO掉話問題分類及分析建議,導(dǎo)致EVDO掉話的主要問題： 1、覆蓋不足 2、空口/傳輸誤碼 3、干擾 4、切換失敗 分析建議： 1、路測、CQT測試，通過測試分析掉話原因； 2、收集話統(tǒng)數(shù)據(jù)及SPU日志，通過Nastar及OMStar分析掉話原因； 3、分析掉話用戶的CDR數(shù)據(jù) 4、查看系統(tǒng)告警、基站單板告警、傳輸告警 5、查看RSSI異常情況 6、PN的檢查及優(yōu)化 7、鄰區(qū)檢查及優(yōu)化,Page 16,EVDO掉話案例強(qiáng)分支加不進(jìn)來引發(fā)的連接釋放 （1）,【現(xiàn)象描述】 問題現(xiàn)象特征： a. 上層數(shù)據(jù)速率為0。DRC很差，PER很高。 b. 激活集PN80的EcIo較差，候選集分支PN96強(qiáng)度為-2.5dB，但是不能夠加入激活集。 【處理過程】 對CAIT數(shù)據(jù)的回放 疑問：為什么PN96無法加到激活集？ 無線場景分析 激活集分支PN80的信號越來越差，相鄰集分支PN96的信號越來越好；但是不能夠成功切換，導(dǎo)致掉話。,Page 17,EVDO掉話案例強(qiáng)分支加不進(jìn)來引發(fā)的連接釋放 （2）,問題原因 1. AT上報(bào)RU，要求增加PN96； 但是由于PN96的EcIo低于T_ADD，導(dǎo)致系統(tǒng)沒有響應(yīng)這條RU消息，沒有發(fā)起切換。 2. 后來，即使PN96的EcIo超過了T_ADD，AT再也不上報(bào)RU了，導(dǎo)致始終不能夠把PN96加入激活集。 3. PN96就成了一個(gè)強(qiáng)干擾，最終導(dǎo)致連接釋放。 問題的解決措施 1. 修改切換判決算法。 當(dāng)AT上報(bào)RU，RRM進(jìn)行增加分支軟切換判決時(shí)，缺省不使用T_ADD門限，只要是相鄰集分支，AT上報(bào)的RU中的Keep指標(biāo)為1，就增加這個(gè)分支。 安全起見，該修改用軟參控制，開關(guān)可控。 CCM周期的向AT下發(fā)ResetReport消息，強(qiáng)制觸發(fā)AT上報(bào)RU。安全起見，該修改用軟參控制，開關(guān)可控。 【結(jié)論】 由于AT的行為，在未達(dá)到T_ADD門限就上報(bào)RU。而系統(tǒng)未作處理。當(dāng)達(dá)到T_ADD門限時(shí)，AT又不上報(bào)RU，同樣未得到系統(tǒng)處理。導(dǎo)致較強(qiáng)的分支沒有及時(shí)被加入，而作為較強(qiáng)的干擾致使AT的連接斷連。在增加算法的兼容性后問題解決。,Page 18,第1章 EVDO接入案例 第2章 EVDO掉話案例 第3章 EVDO速率案例 第4章 EVDO切換案例 第5章 EVDO其他案例,內(nèi)容介紹,Page 19,EVDO速率問題分類及分析建議,影響EVDO前反向速率的主要因素： 1、無線覆蓋（C/I差，Tx高） 2、帶寬不足（CE不足、E1不足、業(yè)務(wù)鏈路帶寬配置不足、PVC帶寬不足、PDSN與PCF帶寬不足） 3、誤碼及重傳（空口誤碼、傳輸誤碼） 4、頻繁切換 5、終端及系統(tǒng)設(shè)置問題 分析建議： 1、路測、CQT測試，通過測試分析掉話原因； 2、從空口開始逐層檢查業(yè)務(wù)帶寬瓶頸（見下一頁圖）； 3、通過ping命令、iperf工具在FMR、PCF上進(jìn)行上下行時(shí)延及帶寬測試； 4、查看系統(tǒng)告警、基站單板告警 5、檢查終端設(shè)置是否正確（包括與終端相連的便攜機(jī)TCP窗口設(shè)置）； 6、檢查FTP服務(wù)器設(shè)置是否正確 7、檢查設(shè)備的配置數(shù)據(jù)（如是否固定了用戶下行最大速率） 8、避免頻繁切換,Page 20,EVDO速率問題分類及分析建議,分析DO下行速率過低，根據(jù)木桶最短板原理，應(yīng)該從底層開始，一層層分析判斷受限點(diǎn)，定位原因并解決。 一般，我們采用cait定位無線鏈路狀況，采用ping命令、iperf定位有線側(cè)鏈路狀態(tài)。,Page 21,EVDO速率案例反向功控參數(shù)設(shè)置不合理導(dǎo)致的下載速率低,【現(xiàn)象描述】 北京3G技術(shù)實(shí)驗(yàn)測試期間，發(fā)現(xiàn)定點(diǎn)的FTP下載速率總是不能穩(wěn)定在2Mbps上。 【處理過程】 通過CAIT觀察發(fā)現(xiàn)空口上前向經(jīng)常有突發(fā)的NAK幀。在總部的外場觀測，發(fā)現(xiàn)同樣現(xiàn)象，通過調(diào)整BSC的反向功控參數(shù)，抬升終端發(fā)射功率后，突發(fā)NAK幀的情況消失，F(xiàn)TP下載速率趨于穩(wěn)定在2Mbps以上。 【結(jié)論】 進(jìn)行FTP下載時(shí)通過CAIT或者在BSC的調(diào)試臺觀察誤碼率是否大于1，空口是否有很多NAK幀。前向發(fā)送大量NAK幀說明反向業(yè)務(wù)信道誤碼過高，提高了反向業(yè)務(wù)信道發(fā)射功率可以減少反向誤碼，改善反向應(yīng)答消息的解調(diào)成功率。這對數(shù)據(jù)業(yè)務(wù)（基于TCP/IP協(xié)議）很重要，所以可以改善前向數(shù)據(jù)速率。,Page 22,EVDO速率案例鏈路帶寬受限導(dǎo)致的DO下行速率過低,【現(xiàn)象描述】 在梧州聯(lián)通測試下載時(shí)，空口情況良好，不存在誤幀情況，前向穩(wěn)定申請2.4M，采用ftp下載，速率在1.8M到1.4M間振蕩，平均值無法突破1.6M，而理論分析，ftp下載應(yīng)該達(dá)到2M以上。 【處理過程】 通過iperf采用UDP發(fā)送測試，全鏈路帶寬穩(wěn)定在1.6M左右。通過分析，與2M的PVC帶寬有關(guān)，由于PVC效率在80左右，正好1.6帶寬 。 【結(jié)論】 通過調(diào)整DO的HAC，BPU，PPU，F(xiàn)MR之間的PVC帶寬到4M，采用UDP下載速率突破了2M。,Page 23,EVDO速率案例E1數(shù)目不足和業(yè)務(wù)鏈路配置錯(cuò)誤造成EV-DO數(shù)據(jù)業(yè)務(wù)下載速率低 （1）,【現(xiàn)象描述】 M國EV-DO網(wǎng)絡(luò)在完成所有安裝和配置之后，測試時(shí)單用戶使用EV-DO FTP下載業(yè)務(wù)的平均速率只有700800Kbps，使用內(nèi)部FTP服務(wù)器下載，單用戶平均速率依然很低。 【處理過程】 1、用CAIT測試空口質(zhì)量。測試結(jié)果表明C/I超過10dB，DRC始終為2.4Mbps，而且測試過程中沒有收到相鄰扇區(qū)或者基站的信號。這說明空口質(zhì)量很好，不是造成下載速率低的原因。 2、檢查連FTP服務(wù)器和接終端以及FTP服務(wù)器的PC的配置。確認(rèn)配置無誤后，單用戶平均下載速率依然保持在700800kbps。 3、檢查配置的E1數(shù)，發(fā)現(xiàn)每個(gè)EV-DO基站只配置了一條E1。但即使只有一條E1，單用戶平均下載速率應(yīng)該可以達(dá)到1.2Mbps，因?yàn)橐粭lE1的有效物理帶寬超過1.5M，所以E1數(shù)的限制還不是主要原因。不過每個(gè)EV-DO基站只配置一條E1也是不合理的。給測試基站再加一條E1后，單用戶平均下載速率可以達(dá)到1.5 Mbps。而根據(jù)經(jīng)驗(yàn)，配置2條E1后，單用戶平均下載速率應(yīng)該超過1.9Mbps，問題仍然沒有解決。 4、在配置2條E1后，用iperf測試從PDSN到PCF和從PDSN到MS的實(shí)際物理帶寬。測試結(jié)果為：PDSN和PCF之間的帶寬約為73M，屬于正常值；而PDSN和AT之間的帶寬只有1.5M。,Page 24,EVDO速率案例E1數(shù)目不足和業(yè)務(wù)鏈路配置錯(cuò)誤造成EV-DO數(shù)據(jù)業(yè)務(wù)下載速率低 （2）,5、檢查BSC的帶寬配置。用命令LST BTSLNK查詢BIE板和BTS間的帶寬設(shè)置，用命令LST ALPATH查詢BIE板和FMR板間的帶寬設(shè)置，在這一步終于發(fā)現(xiàn)了問題：之前為每個(gè)EV-DO基站配置了2條業(yè)務(wù)鏈路，但是每個(gè)EV-DO基站只配置了一塊EC板。 因此是E1數(shù)目不足和業(yè)務(wù)鏈路配置錯(cuò)誤造成EV-DO數(shù)據(jù)業(yè)務(wù)下載速率低。 在BSC和BTS側(cè)都刪除一條業(yè)務(wù)鏈路后，單用戶平均下載速率終于到達(dá)了2.0Mbps，問題得到解決。 【結(jié)論】 遇到EV-DO數(shù)據(jù)業(yè)務(wù)下載速率低的問題時(shí)，一般都可以從空口質(zhì)量、服務(wù)器的TCP/IP協(xié)議窗口配置、物理鏈路配置、業(yè)務(wù)鏈路數(shù)等幾個(gè)方面去查找原因。,Page 25,EVDO速率案例IMA組中一條E1未工作導(dǎo)致EVDO下行速率較低,【現(xiàn)象描述】 P國Z局CDMA450 1X網(wǎng)絡(luò)，某基站，站型S222，1X和EVDO各一載波，E1配置：1X一條E1，UNI方式；DO兩條E1，IMA方式。進(jìn)行EVDO前向空載速率測試，近站處無切換，C/I在10dB左右跳動，申請DRC為1.8-2.4Mbps，進(jìn)行FTP下載，速率平均在1M左右，最高只有1.4Mbps。 【處理過程】 采用逐步排查進(jìn)行分析： 1.通過無線資源監(jiān)控命令DSP DORADIORESINDICATION查看該站資源使用情況，測試扇區(qū)Active用戶數(shù)為1，其他扇區(qū)無用戶；并通過DSP BTSFLUS命令確認(rèn)前向沒有FLUS加載；排除了多用戶和FLUS加載的影響; 2. 檢查TCP參數(shù)，MTU為1500，TCP窗口為640000，沒有問題； 3. 查看Abis傳輸業(yè)務(wù)帶寬和PVC帶寬，分別配置為3.6M（IMA方式，兩條E1）和6M，依然沒有有問題； 4. 檢查歷史告警，無該站E1/T1告警，但通過DSP E1T1STAT查看EVDO配置的兩條E1工作狀態(tài)，發(fā)覺只有一條E1處于正常工作狀態(tài)；初步認(rèn)為是E1故障的原因； 5. 通過現(xiàn)場基站維護(hù)工程師的檢修，另一條E1工作恢復(fù)正常（據(jù)說是接口松動）；再進(jìn)行測試，平均速率在1.8Mbps左右，瞬時(shí)最高速率達(dá)到2M以上。問題得到解決。 【結(jié)論】 基站開通后，對EVDO來說，單站的撥測不能只看是否能傳輸數(shù)據(jù)，應(yīng)該同時(shí)關(guān)注實(shí)際傳輸速率，在對應(yīng)的無線環(huán)境和配置下是否正常。,Page 26,EVDO速率案例復(fù)雜組網(wǎng)下，中間鏈路問題導(dǎo)致下行速率受限 （1）,【現(xiàn)象描述】 廣西南寧EVDO實(shí)驗(yàn)局，通過FTP下載發(fā)現(xiàn)數(shù)據(jù)業(yè)務(wù)的下行速率很低，不到1Kbps，網(wǎng)頁打不開。 【處理過程】 1、檢查便攜和終端設(shè)置正常。 2、通過終端的Debug窗口觀察到Ec/Io在-1左右排除空口原因。 3、 檢查從BTS到HAC之間沿途的帶寬設(shè)置，均在4Mbps以上，現(xiàn)場只有1個(gè)DO單扇區(qū)，帶寬足夠。 4、該組網(wǎng)特別處是PCF與PDSN間多了兩個(gè)低端路由器，懷疑與路由器有關(guān)。通過PC機(jī)經(jīng)路由器、PDSN連接到服務(wù)器進(jìn)行FTP下載和網(wǎng)頁瀏覽均正常。開始檢查FMR、PPU、SPU的打印，未發(fā)現(xiàn)丟包。于是懷疑在路由器上可能大量丟包。聯(lián)系總部了解到2631E路由器最大只能接收1.5K的包，超過該值時(shí)，包會被拆分。初步估計(jì)路由器和3COM PDSN配合有問題，導(dǎo)致包被大量丟棄，速率超低。,Page 27,EVDO速率案例復(fù)雜組網(wǎng)下，中間鏈路問題導(dǎo)致下行速率受限（2）,5、修改PDSN的SYS_MTU值為1400后，速率達(dá)到1.3M。由于1.3Mbps的速率仍然遠(yuǎn)低于正常值，懷疑傳輸上仍然存在問題。 6、聯(lián)系數(shù)通的技術(shù)支持人員檢查后發(fā)現(xiàn)一臺2631未接地，在路由器上有明顯丟包。接地后，速率達(dá)到1.7Mbps。 7、此時(shí)離理想數(shù)值仍有差距，通過netpersec觀察，速率上不去在于每次下載10M文件過程中至少有一次大幅抖動，丟包很明顯。固定反向速率情況依舊。已確認(rèn)空口質(zhì)量沒有問題，利用帶寬測試工具通過UDP測試從分組域到終端的下行帶寬，發(fā)現(xiàn)能達(dá)到2M以上。 8、檢查PDSN和服務(wù)器側(cè)沒有問題，BSC配置也看不出什么問題。最后又回到了路由器上，經(jīng)過工程師現(xiàn)場定位發(fā)現(xiàn)南寧和梧州兩個(gè)路由器間的4對E1有1對E1自環(huán)上了，導(dǎo)致下載過程中速率抖動很大。修正后，速率穩(wěn)定，能夠達(dá)到2.1M，經(jīng)最后在國際會展中心地下室機(jī)房信號最強(qiáng)的地方測試，速率達(dá)到2.2M，峰值2.4M。 【結(jié)論】 此案例中有PDSN設(shè)置問題（最大包長問題），也有工程安裝問題（接地和自環(huán)），比較典型。,Page 28,EVDO速率案例傳輸誤碼率高造成EVDO數(shù)據(jù)業(yè)務(wù)速率低 （1）,【現(xiàn)象描述】 某地試驗(yàn)演示局，EVDO純數(shù)據(jù)系統(tǒng)（無語音業(yè)務(wù)）。PDSN流媒體1 BSC（小容量）2 O1 CBTS3606（雙E1）。在開通EVDO的CBSC及其中A基站后，測試其數(shù)據(jù)業(yè)務(wù)的速率只有1.4Mbps，而另一個(gè)B基站下行速率可達(dá)到2.3Mbps。 【處理過程】 1.檢查CBSC、CBTS數(shù)據(jù)及硬件，未發(fā)現(xiàn)錯(cuò)誤，檢查告警均正常，排除CBSS問題； 2.檢查由PDSN到PCF的A10、A11接口數(shù)據(jù)及數(shù)據(jù)網(wǎng)線均正常。同時(shí)對接在該P(yáng)DSN下另一廠家的EVDO設(shè)備業(yè)務(wù)速率在2M左右，所以排除PDSN設(shè)備及A10、A11接口問題； 3.由于基站B下行速率達(dá)到2.3M，所以排除BSC內(nèi)部框間連接及數(shù)據(jù)問題； 4.DRC申請的速率基本都是2.4Mbps，這就說明空口質(zhì)量非常好； 5.檢查基站ABIS口信令鏈路及維護(hù)鏈路帶寬為110K，業(yè)務(wù)鏈路帶寬為3.2M，所以配置PVC帶寬正常； 6.終端側(cè)的TCP窗口的大小對速率也有很大的影響，于是檢查TCP的設(shè)置參數(shù)：TcpWindowSize 0x0000ffff(WINDOWS XP) 排除了終端這邊的設(shè)置問題；,Page 29,EVDO速率案例傳輸誤碼率高造成EVDO數(shù)據(jù)業(yè)務(wù)速率低 （2）,7. ABIS接口采用2對E1組成的IMA，在物理上不存在瓶頸。采用“LST CBTSLNKERRCNT“命令檢查ABIS接口誤碼統(tǒng)計(jì)，發(fā)現(xiàn)兩條鏈路的每秒丟包個(gè)數(shù)(ERROR CONNT)基本為100200，確認(rèn)ABIS傳輸不正常，顯示如下： 2005/06/09/16/35/05: LINKID = 0 ERROR CONNT = 121, 2005/06/09/16/36/05: LINKID = 0 ERROR CONNT = 111, 2005/06/09/16/37/05: LINKID = 0 ERROR CONNT = 103, 2005/06/03/18/20/51: LINKID = 1 ERROR CONNT = 124, 2005/06/03/18/21/51: LINKID = 1 ERROR CONNT = 106, 2005/06/03/18/22/51: LINKID = 1 ERROR CONNT = 117, 2005/06/03/18/23/51: LINKID = 1 ERROR CONNT = 124, 2005/06/03/18/24/51: LINKID = 1 ERROR CONNT = 125, 2005/06/03/18/25/51: LINKID = 1 ERROR CONNT = 124, 問題定位到ABIS口數(shù)據(jù)及硬件，檢查ABIS數(shù)據(jù)正常。 檢查對應(yīng)ABIS接口傳輸設(shè)備，發(fā)現(xiàn)從BSC側(cè)DDF架到光傳輸之間、及BTS側(cè)DDF架到光傳輸之間均未接地，在安裝規(guī)范中要求光傳輸設(shè)備的輸入、輸出必須單端接地，否則將會產(chǎn)生相應(yīng)的誤碼； 8. 在光傳輸設(shè)備的維護(hù)臺上早已有傳輸誤碼告警，但由于原來該光傳輸是使用于GSM基站的ABIS接口，雖然傳輸?shù)恼`碼產(chǎn)生一定的話音質(zhì)量差，但由于語音的誤碼要求(1E-4)較EVDO傳輸誤碼(1E-6)小，所以客戶也未深究。但對于EVDO這樣數(shù)據(jù)傳輸時(shí)，光傳輸設(shè)備的誤碼直接造成下行速率下降；在DDF架進(jìn)行相應(yīng)接地后，測試業(yè)務(wù)下行速率達(dá)到2.2M（三星手機(jī)）。 【結(jié)論】 1、分析DO下行速率過低，根據(jù)木桶最短板原理，應(yīng)該從底層開始，一層層分析判斷受限點(diǎn)，定位原因并解決. 2、由于數(shù)據(jù)業(yè)務(wù)在傳輸通道中誤碼率及時(shí)鐘同步要求比語音業(yè)務(wù)高，所以在EVDO設(shè)備開局時(shí)注意系統(tǒng)時(shí)鐘的同步及精度。,Page 30,EVDO速率案例EC板緩存太大導(dǎo)致頻繁切換時(shí)DO Rev.A終端掉零,【現(xiàn)象描述】 使用AnyDATA終端（協(xié)商為DO Rev.A模式）進(jìn)行路測，在切換帶內(nèi)，經(jīng)常出現(xiàn)速率掉零，且長時(shí)間無法自動恢復(fù)，需要手動重啟FTP下載后，下載才能恢復(fù)正常。 【處理過程】 1、分析AT的log數(shù)據(jù)，發(fā)現(xiàn)在產(chǎn)生掉零的位置，空口環(huán)境變化非常劇烈，AT申請的DRC在0到1.2M之間劇烈波動，同時(shí)AT的RLP數(shù)據(jù)中增加了許多RLP Abort。 2、分析FMR和信道板的打印信息，發(fā)現(xiàn)信道板此時(shí)的緩沖隊(duì)列大多為滿的狀態(tài)。由于DRC由大到小變化非常迅速，又伴隨多次虛擬軟切換，每次虛擬軟切換都會將緩沖區(qū)中的數(shù)據(jù)全部清空，因此，F(xiàn)MR下發(fā)的重傳數(shù)據(jù)不能及時(shí)的發(fā)到AT，導(dǎo)致AT側(cè)產(chǎn)生RLP Abort，將錯(cuò)誤遺留到上層TCP層后，引發(fā)TCP的懲罰機(jī)制，導(dǎo)致速率降為0。 3、EC板的緩存默認(rèn)設(shè)置為32760byte，在大部分情況下切換是沒有問題的，但對于頻繁切換情況，由于產(chǎn)品的實(shí)現(xiàn)機(jī)制，在切換前需要清空原緩存，導(dǎo)致大量的數(shù)據(jù)靠上層的重傳來保證，大量的數(shù)據(jù)如果在AT的RLP定時(shí)器超時(shí)之前來不及重傳，則會產(chǎn)生大量的RLP Abort，傳遞到上層TCP層，從而導(dǎo)致掉零；但如果設(shè)置EC板的緩存值太小，由于擁塞控制機(jī)制，將會導(dǎo)致單用戶下載情況下速率達(dá)不到理論值。 【結(jié)論】 EC板緩存為代碼寫死參數(shù)，無維護(hù)臺命令可修改。通過多次測試發(fā)現(xiàn)設(shè)置EC板緩存為14000byte時(shí)，頻繁切換導(dǎo)致掉零問題和下載速率低問題都可以得到解決。但由于網(wǎng)絡(luò)的差異，不一定適合其它地方，對于特定的網(wǎng)絡(luò)，需要測試驗(yàn)證。,Page 31,EVDO速率案例FMR緩沖區(qū)不夠?qū)е骂l繁切換時(shí)DO Rel.0終端掉零,【現(xiàn)象描述】 使用AnyDATA終端（協(xié)商為DO Rel.0模式）進(jìn)行路測，在切換帶內(nèi)，經(jīng)常出現(xiàn)速率掉零，且長時(shí)間無法自動恢復(fù)，需要手動重啟FTP下載后，下載才能恢復(fù)正常。 【處理過程】 1、對比該時(shí)段前后Cait log，發(fā)現(xiàn)在GPS時(shí)間15:44:06.203時(shí)，AT發(fā)送了連續(xù)發(fā)送了兩條反向RLP消息，空洞長度分別為31842和25668字節(jié)，這樣的大空洞是導(dǎo)致速率掉零的直接原因。 2、回放Cait數(shù)據(jù)，在上述大片空洞產(chǎn)生之前都發(fā)生了虛擬軟切換 3、分析FMR調(diào)試臺打印也可以看到，這段時(shí)間內(nèi)切換很頻繁，開始的時(shí)候是0號分支作為主分支。當(dāng)2號分支發(fā)起Req時(shí)，基站緩沖區(qū)被清除，此時(shí)可以看到基站緩沖區(qū)數(shù)據(jù)量很大，幾乎是滿的。另外剛切換到2號分支，就發(fā)現(xiàn)2號分支連續(xù)幾秒鐘收到的反向幀都是誤幀。此時(shí)處于無主分支狀態(tài)?；居智宄彌_區(qū)，在這540ms內(nèi)有損失了200多個(gè)前向包和200多個(gè)重傳包。 4、基站上報(bào)的從空口發(fā)出去的FrameID和FMR發(fā)給BTS的FrameID相差很大。在虛擬軟切換時(shí)，基站會清空發(fā)送緩沖區(qū)，基站的緩沖區(qū)設(shè)定是32760字節(jié)，相當(dāng)于263個(gè)RLP包，而FMR只會記錄已發(fā)給BTS的10個(gè)包記錄，當(dāng)基站大量數(shù)據(jù)被清除時(shí)，要求傳輸?shù)臄?shù)據(jù)在FMR中找不到（基站剛把緩沖區(qū)填滿，就發(fā)生了虛擬軟切換），此時(shí)會在AT的RLP層產(chǎn)生一個(gè)大小為200多個(gè)包的空洞，只能依靠于TCP層的重傳，這會導(dǎo)致很大的速率波谷。 【結(jié)論】BTS EC板緩存與FMR的記錄相差太大是頻繁切換時(shí)DO Rel.0路測掉零的根本原因。 目前產(chǎn)品不支持命令修改，BSC版本V2R3C03B012最近版本已經(jīng)把記錄數(shù)寫死為270。,Page 32,EVDO速率案例HAC板不穩(wěn)定問題導(dǎo)致的DO用戶前反向速率出現(xiàn)周期性大的波動,【現(xiàn)象描述】 某EVDO局BSC版本為BSC6600-OMCV200R001ENGC01B010，BTS版本為BTS3612-OMCV200R001ENGC01B011。 EVDO的FTP下載傳輸速率很不穩(wěn)定，在基站附近，信號質(zhì)量很好，DRC為2.4576M和C/I為11-13的時(shí)候，單用戶的下載傳輸速率一般在30kBps到130kBps間，波動很大，上傳速率也出現(xiàn)類似的波動。 【處理過程】 1、由于本次測試使用的是局方的PDSN設(shè)備和FTP server，而局方的該設(shè)備之前一直運(yùn)行正常，所以可以先排除 PDSN和FTP服務(wù)器的問題。 2、對硬件安裝情況進(jìn)行檢查，設(shè)備安裝質(zhì)量無問題，之后重新制作網(wǎng)線，逐步更換我們的LAN SWITCH和局方PDSN 和我司PCF之間的連接網(wǎng)線，每次撥號測試，故障仍存在，檢查BTS的E1狀態(tài)，正常無告警。 3、據(jù)中研反饋，這種高通的手機(jī)由于存在下載半小時(shí)以上就會斷掉業(yè)務(wù)的問題，并且該問題當(dāng)時(shí)已經(jīng)和高通確認(rèn)。 但是現(xiàn)場的主要問題是速率的波動和平均速率低，和描述現(xiàn)象不是很一致。 4、檢查數(shù)據(jù)配置，沒有發(fā)現(xiàn)問題，重新安裝BAM，復(fù)位，發(fā)現(xiàn)FTP下載速率最大可以達(dá)到180kBps左右，但存在周 期性的大波谷。 5、懷疑帶寬的限制造成該問題，嘗試修改系統(tǒng)PVC帶寬后復(fù)位，發(fā)現(xiàn)波動更頻繁，性能比之前還要差。由于速率 十分不穩(wěn)定，修改回原始帶寬復(fù)位，速率變?yōu)椴▌訌?297kBps之間，更加不穩(wěn)定，不能恢復(fù)原來的相對穩(wěn)定 狀態(tài)。 6、由于多次復(fù)位系統(tǒng)后，每次速率變化都不太一樣，數(shù)據(jù)沒有變化（帶寬數(shù)據(jù)已經(jīng)改回），因此懷疑系統(tǒng)的軟件 或硬件部分存在不穩(wěn)定的因素，想起HAC板幾日來隨機(jī)出現(xiàn)幾次GE口告警，更換BSC的HAC板，重新測試，平均 吞吐量可以達(dá)到近點(diǎn)200kBps左右，反向吞吐量也可穩(wěn)定達(dá)到126kbps，問題解決。 【結(jié)論】 在處理問題的時(shí)候要關(guān)注告警信息，特別是新產(chǎn)品，出現(xiàn)的問題有的時(shí)候會比較多，很難定位，告警是比較重要的定位信息。,Page 33,EVDO速率案例由于便攜機(jī)TCP接收窗及FTP服務(wù)器TCP發(fā)送窗口太小，導(dǎo)致下行速率過低,【現(xiàn)象描述】 在外場測試時(shí)，DO的下載速率只有1M左右。 【處理過程】 1、下載時(shí)，空口情況良好，不存在誤幀情況，前向穩(wěn)定申請2.4M，通過iperf采用UDP發(fā)送測試，前向全鏈路帶寬確實(shí)達(dá)到2M。但FTP下載速率只有1M左右，且較穩(wěn)定，說明ftp進(jìn)入穩(wěn)定狀態(tài)，與TCP的慢啟動無關(guān)。采用多進(jìn)程下載能顯著提高下載速率， 2、檢查便攜注冊表的TcpWindowSize設(shè)置。Tcp窗口大小取8k字節(jié)的整數(shù)倍，并需要保證TcpWindowSize = 雙向時(shí)延速率，一般設(shè)置為64000Byte。例如建立撥號連接后從便攜ping網(wǎng)絡(luò)側(cè)服務(wù)器，如果往返時(shí)延是200ms，期望FTP下載速率為2Mbps，那么TcpWindowSize 0.2*2000000/8 = 50000字節(jié)，則比較合適的取值就是最近的64000字節(jié)。若是WinXP，還需檢查注冊表中DefaultRcvWindow；此值需要設(shè)置為65535，以保證便攜接收緩沖區(qū)足夠大。 3、分析表明，穩(wěn)定時(shí)，ftp速率與帶寬、延時(shí)以及發(fā)送接收窗大小相關(guān)。 4、經(jīng)檢查TCP接收窗大小為8k，可能存在瓶頸問題。 5、同理檢查并調(diào)整FTP服務(wù)器TCP發(fā)送窗口大小。 【結(jié)論】 通過調(diào)整窗便攜機(jī)TCP接收窗大小及FTP服務(wù)器TCP發(fā)送窗口大小，下載速率提高到預(yù)定目標(biāo)。,Page 34,EVDO速率案例PDSN不支持TCP/IP頭壓縮，導(dǎo)致下行速率受限,【現(xiàn)象描述】 在北京MTNET室內(nèi)測試時(shí)，采用3Com的PDSN下載速率可以達(dá)到2M左右，且較平穩(wěn)，但采用華為PDSN，只能在1.9M到1.6M左右振蕩，無法穩(wěn)定傳輸。 【處理過程】 下載時(shí)，空口情況良好，不存在誤幀情況，前向穩(wěn)定申請2.4M，通過iperf采用UDP發(fā)送測試，華為與3Com帶寬一樣，均達(dá)到2M，而且PDSN處理能力遠(yuǎn)大于單個(gè)終端。通過sniff觀察數(shù)據(jù)包，無丟包現(xiàn)象，無錯(cuò)誤斷言。通過協(xié)議匹配分析以及RRI對比觀察，發(fā)現(xiàn)采用3Com的PDSN，反向穩(wěn)定在38.476.8k之間，而采用華為的PDSN在9.6k到76.8k之間振蕩。可以分析得出：由于EVDO的反向速率自適應(yīng)與TCP IP的慢啟動協(xié)議正好產(chǎn)生振蕩。仔細(xì)分析，反向華為不支持IP頭壓縮而3Com支持。將3Com的IP頭壓縮取消，測試結(jié)果與采用華為的PDSN現(xiàn)象一致。將終端反向速率采用iperf提高到76.8k，穩(wěn)定一段時(shí)間，同時(shí)采用TCP下載，當(dāng)iperf終止傳輸時(shí)，TCP下載也能穩(wěn)定在1.9M以上。 【結(jié)論】 進(jìn)行FTP下載時(shí)通過CAIT或者在BSC的調(diào)試臺觀察誤碼率是否大于1，空口是否有很多NAK幀。前向發(fā)送大量NAK幀說明反向業(yè)務(wù)信道誤碼過高，提高了反向業(yè)務(wù)信道發(fā)射功率可以減少反向誤碼，改善反向應(yīng)答消息的解調(diào)成功率。這對數(shù)據(jù)業(yè)務(wù)（基于TCP/IP協(xié)議）很重要，所以可以改善前向數(shù)據(jù)速率。,Page 35,EVDO速率案例服務(wù)器C盤空間不夠?qū)е翬VDO下行速率低 （1）,【現(xiàn)象描述】 某試驗(yàn)EVDO局點(diǎn)，EVDO站開起來，經(jīng)過多次測試調(diào)整，EVDO下載速率約為800K，速率上不去，當(dāng)時(shí)C/I7，ABIS帶寬3.1M，搜索窗65000。 【處理過程】 空口質(zhì)量很好，不存在問題； 確保了測試終端、測試電腦設(shè)置無誤； 檢測設(shè)備： 1、 檢查PVC帶寬，站點(diǎn)的PVC帶寬為4M，這已經(jīng)夠用，排除此原因； 2、 檢查BTS E1工作及帶寬是否足夠，單個(gè)扇區(qū)共用了2兩E1專給該扇區(qū)用于DO使用，而且工作正常，排除此原因； 3、 因?yàn)橛糜跍y試使用，網(wǎng)絡(luò)沒有AAA模塊，呼叫不需要進(jìn)行鑒權(quán)，分析整個(gè)呼叫信令流程未能發(fā)現(xiàn)異常情況； 4、 對服務(wù)器PC建立的ftp相關(guān)參數(shù)進(jìn)行檢查，檢查相關(guān)參數(shù)后未能發(fā)現(xiàn)異常情況，在處理過程中，在外路測DO的時(shí)候（一直下載大文件），有時(shí)候會出現(xiàn)下載停頓的情況；給路測人員的感覺是，此情況與單PC在工作時(shí)出現(xiàn)內(nèi)存不夠的情形差不多；因此懷疑測試ftp服務(wù)器的內(nèi)存配置問題；可ftp服務(wù)器的內(nèi)存條配置2G左右，應(yīng)該夠用；,Page 36,EVDO速率案例服務(wù)器C盤空間不夠?qū)е翬VDO下行速率低 （2）,5、 無意間，用磁盤管理功能查看硬盤分區(qū)情況，系統(tǒng)自動告警說C盤硬盤空間不夠；細(xì)查C盤空間，發(fā)現(xiàn)C盤剩余空間為0，刪除C盤下的大量用于測試使用的多媒體文件，保留2G多的剩余空間。DO下載速率明顯上升，單用戶下載可以穩(wěn)定處于2M左右。問題獲得解決。 【結(jié)論】 1. 實(shí)際項(xiàng)目中，一些很細(xì)節(jié)的問題都有可能導(dǎo)致網(wǎng)絡(luò)質(zhì)量提升問題，如本案例因?yàn)閒tp服務(wù)器C盤空間不夠引起下載速率過低，一開始并沒能引起大家的注意； 2. 很多網(wǎng)絡(luò)問題，在想辦法排除故障的時(shí)候，往往一開始想到的就是復(fù)雜的技術(shù)問題，而忽略了小問題所帶來的影響； 3. 一些項(xiàng)目現(xiàn)場，管理等相關(guān)制度不完善，或者是制度執(zhí)行不理想。導(dǎo)致出現(xiàn)了些不該出現(xiàn)的問題。如此案例，在現(xiàn)場幾乎任何一個(gè)人都可以在ftp服務(wù)上拷貝操作，最后導(dǎo)致C盤磁盤空間滿了也不通知相關(guān)人員。,Page 37,EVDO速率案例EV-DO QoS速率權(quán)重設(shè)置錯(cuò)誤導(dǎo)致VOD視頻播放速率較低達(dá)不到理想的效果（1）,【現(xiàn)象描述】 某局點(diǎn)對BSC6600,BTS3606、PDSN升級后利用三星E159手機(jī)撥號后進(jìn)入VOD視頻點(diǎn)播網(wǎng)站進(jìn)行視頻播放，通過速度測試軟件測試的播放速率只有580Kbps，而升級前穩(wěn)定為1.4Mbps?，F(xiàn)場版本：BSC6600V200R003C02B014(061110)，BTS3606-0R001ENGC04B01520061110),PDSN9660V800R105C01B011, 組網(wǎng)：1個(gè)BSC6600、1個(gè)BTS3606、1個(gè)PDSN、1業(yè)軟的流媒體服務(wù)器。 【處理過程】 1、檢查EV-DO基站的業(yè)務(wù)鏈路帶寬，分配給DO的物理E1為兩條業(yè)務(wù)鏈路。帶寬設(shè)置沒有問題； 2、檢查便攜機(jī)參數(shù)設(shè)置，TCP窗口、IP頭壓縮等設(shè)置的均沒有問題； 3、由于只用一個(gè)手機(jī)連接到便攜機(jī)上進(jìn)行測試，所以不可能是由于用戶數(shù)過多引起的速率下降； 4、手機(jī)上信號滿格，并且測試手機(jī)就在離基站不到5米的地方，排除了無線環(huán)境差的原因； 5、檢查BSC參數(shù)設(shè)置：檢查TCP優(yōu)化開關(guān)LST MAPARA，將TCP優(yōu)化開關(guān)關(guān)閉后測試速率依然為580Kbps， 排除此開關(guān)的影響； 6、檢查腳本中的其他軟參 ，也沒有問題。,Page 38,EVDO速率案例EV-DO QoS速率權(quán)重設(shè)置錯(cuò)誤導(dǎo)致VOD視頻播放速率較低達(dá)不到理想的效果（2）,7、考慮到EV-DO可以針對同一個(gè)載頻下無線環(huán)境相似的不同等級用戶的數(shù)據(jù)業(yè)務(wù)呼叫前向平均傳輸 速率，是不是這個(gè)速率設(shè)置的過小而影響到整個(gè)前向速率呢？ 首先使用LST DOGP查詢EV-DO全局參數(shù)，查詢BSC已經(jīng)打開了QoS開關(guān)； 使用命令LST DOQOS: GRADE=GOLD;查詢金牌用戶的前向速率限制為585.6Kbps（GRADEFWDLMTRATE=FRATE5856） 使用命令MOD DOQOS: GRADE=GOLD, GRADEFWDLMTRATE=FRATE23424;將速率修改為2342.4后測 試，VOD播放速率正常。 【結(jié)論】 涉及到EV-DO的參數(shù)設(shè)置很多，希望大家在考慮正常數(shù)據(jù)配置問題的情況下，多檢查一下系統(tǒng)的參數(shù)配置。,Page 39,EVDO切換案例框間鏈路未配置導(dǎo)致EVDO切換失?。?）,【現(xiàn)象描述】 B國某CDMA450M EV-DO局點(diǎn)，反饋在配置反向搜索窗24chips基站和96chips基站之間EV-DO軟切換失敗，現(xiàn)象為速率陡降或者連接中斷?，F(xiàn)場BSS版本為V200R001C02B018，S3/3/3組網(wǎng)，2個(gè)1X頻點(diǎn)1個(gè)EV-DO頻點(diǎn)。 【處理過程】 導(dǎo)致EV-DO切換失敗或者速率陡降的原因有： 漏配EV-DO鄰區(qū)； BSC間切換區(qū)域； 導(dǎo)頻污染。 通過現(xiàn)場反饋BAM數(shù)據(jù)分析，發(fā)現(xiàn)鄰區(qū)漏配，進(jìn)一步通過打開EV-DO鄰區(qū)漏配檢測開關(guān)和BSC Runlog鄰區(qū)漏配記錄軟參，通過CBSSSTAR分析Runlog文件，檢測出漏配鄰區(qū)，反饋現(xiàn)場添加。具體命令如下： 1、MOD DORRMMP: DETECMISSPILOTSWITCH=ON;打開鄰區(qū)漏配檢測功能開關(guān)，此開關(guān)V1R3默認(rèn)關(guān)閉，V2R1/V2R2默認(rèn)打開。 2、MOD SOFTPARA: SRVMN=RRM, PRMNO=50, PRMV=“0x1“;打開寫日志開關(guān)，鄰區(qū)漏配檢測的結(jié)果就會被寫入到SPU日志中，然后用工具進(jìn)行分析后輸出鄰區(qū)腳本（與1X鄰區(qū)形式一致）。 （注意上述0x1指的是將RRM第50號軟參的bit0的值，由默認(rèn)值0修改為1，請使用LST SOFTPARA命令首先查詢該軟參設(shè)置值，然后將bit0設(shè)為1）。,Page 40,EVDO速率案例框間鏈路未配置導(dǎo)致EVDO切換失敗 （2）,增加鄰區(qū)后，測試結(jié)果表明部分切換成功，但還有很多切換失敗。 讓現(xiàn)場反饋?zhàn)钚翨AM數(shù)據(jù)，通過工程輔助系統(tǒng)還原檢查系統(tǒng)參數(shù)配置，發(fā)現(xiàn)現(xiàn)場配置有兩個(gè)EV-DO框，但框間未配置軟切換鏈路，進(jìn)一步發(fā)現(xiàn)測試區(qū)域基站分布在兩個(gè)EV-DO框里，通知現(xiàn)場配置EV-DO框間鏈路，測試結(jié)果表明EV-DO切換正常，問題得到解決。 【結(jié)論】 BSC配置有多個(gè)EV-DO框，框間也需要配置軟切換鏈路。 EV-DO切換失敗很多原因跟鄰區(qū)漏配有關(guān)，要充分利用CBSSSTAR鄰區(qū)漏配檢測功能發(fā)現(xiàn)漏配鄰區(qū)。,Page 41,第1章 EVDO接入案例 第2章 EVDO掉話案例 第3章 EVDO速率案例 第4章 EVDO切換案例 第5章 EVDO其他案例,內(nèi)容介紹,Page 42,EVDO切換問題分類及分析建議,影響EVDO切換的主要因素： 1、鄰區(qū)關(guān)系 2、切換參數(shù) 3、資源容量 4、終端及產(chǎn)品問題 分析建議： 1、通過路測分析掉話原因； 2、路測的同時(shí)在維護(hù)臺進(jìn)行空口信令跟蹤，檢查切換流程； 3、檢查鄰區(qū)（漏配、優(yōu)先級不合理） 4、檢查搜索窗大?。せ罴⒑蜻x集、相鄰集） 5、檢查切換門限（PILOTADD、PILOTCMP、PILOTDROP、PILOTDROPTIMER ，） 6、檢查設(shè)備告警 7、分析話統(tǒng)數(shù)據(jù),Page 43,EVD