1、資料編碼產品名稱使用對象華為工程師產品版本編寫部門cdma網絡性能研究部資料版本1.1cdma性能案例分冊（do部分）擬 制：cdma&wimax網絡性能研究部日 期：整 理：日 期：審 核：日 期：批 準：日 期：華 為 技 術 有 限 公 司版權所有 侵權必究修訂記錄日期修訂版本描述作者目 錄第1章 連接建立類案例31.1 pcf丟包導致at重激活時延長31.2 相鄰載頻的搜索窗配置不相等導致ev-do接入失敗5第2章 切換類案例102.1 框間鏈路未配置導致ev-do切換失敗10第3章 do速率低案例123.1 abis傳輸亂序導致do rev.a單用戶下載速率低123.2 ec板緩存太

2、大導致頻繁切換時do rev.a終端掉零143.3 fmr緩沖區不夠導致頻繁切換時do rel.0終端掉零153.4 ev-do qos速率權重設置錯誤導致vod視頻播放速率較低達不到理想的效果173.5 e1數目不足和業務鏈路配置錯誤造成ev-do數據業務下載速率低19第4章 其他案例214.1 actix統計工具有誤導致路測大量rlp reset21關鍵詞：do 連接建立 切換 下行速率 鑒權摘 要：本文收集了網優工程師現場處理無線性能問題的案例，并按照連接建立、切換、do速率、其他等將案例分成四大類。詳細介紹了每一個案例的問題描述、原因分析、解決方案、經驗總結和備注，目的是讓網絡優化人員

3、學習前人的經驗從而達到快速處理類似問題的能力，并從中積累網優經驗，少走彎路。縮略語清單：縮略語 英文全名中文解釋abisabis interfaceabis接口（an-bts）a1a interfacea接口（msc-an）anaccess network接入網絡apaccess point接入點ataccess terminal接入終端bambackground administration module后管理模塊bscbase station controller基站控制器btsbase transceiver station基站收發信臺drcdata rate control數據速率控制

4、dridata ready indication數據準備指示ecenhanced channel processing board增強信道處理板ev-doevolution data optimized增強速率優化fmrframe processing (fp mac rlc) board幀處理板ftpfile transfer protocol文件傳輸協議ipinternet protocol因特網協議nidnetwork identification網絡標識pcfpacket control function分組控制功能pdsnpacket data serving node分組數據服務節

5、點pzidpacket zone identification分組區標識qosquality of service業務質量qxdmqualcomm extensible diagnostic monitor高通do a測試工具rlpradio link protocol無線鏈路協議rrmradio resource management無線資源管理sidsystem identification系統標識tcptransmission control protocol傳輸控制協議umair interface空中接口vodvideo on demand視頻點播第1章 連接建立類案例1.1 pcf

6、丟包導致at重激活時延長作者：吳鈺峰（45700）最小部門：cdma & wimax網絡性能研究部所屬產品：cdma bss來源：比拼測試關鍵字：at 重激活【現象、問題描述】r國比拼測試前，做at重激活預測試，發現重激活時延非常不穩定，有時只需要500ms左右，有時卻需要4000ms。【關鍵過程、根本原因分析】撥號連接，看到at進入idle后，使用下列命令ping ftp服務器：ping -n 1，測試10次，發現at進入dirmant態的時間變化也非常大（fmr的去激活定時器為30s）。分析用戶接口跟蹤，發現存在兩種呼叫流程，一種正常，一種異常，異常流程中bsc沒有收

7、到pcf發送的a9-update-a8-ack消息，如下圖：圖1-1 呼叫信令流程查詢ccm的a9 update a8超時定時器發現，使用的是默認值2000（單位為ms，即2s），正常的a9-update-a8響應時間應該為ms級的。我們修改該定時器為5000，經過多次測試，還是出現該問題。在pcf抓包，發現存在丟包現象。【結論、解決方案及效果】與開發人員進行確認，發現pcf的內部處理存在問題，修改之后問題得到解決。發現問題版本為v2r3c03b011，合入到了v2r3c03b012版本。【經驗總結、預防措施和規范建議】無。【備注】無。1.2 相鄰載頻的搜索窗配置不相等導致ev-do接入失敗作

8、者：黃遼（42271）最小部門：cbss產品技術服務部所屬產品：cdma bss來源：網絡優化關鍵字：接入失敗 位置更新 搜索窗【現象、問題描述】r局點有用戶投訴，ev-do呼叫接入時偶爾出現接入失敗的情況。對該地區進行路測，發現該小區有些地區的接入成功率非常高，但是有些地區則常常出現ev-do接入失敗的問題。同時在跟蹤該用戶的時候發現該用戶的at發送位置更新消息非常頻繁。【關鍵過程、根本原因分析】1、通過分析信令來檢查什么原因導致了呼叫接入失敗，發現在失敗時有如下異常流程出現：bsc連續發起兩次a9-setup-a8的消息圖1-2 bsc連續發起兩次a9-setup-a8的消息的信令在上述的

9、流程中，an在2ms的時間之內給同一個pcf發送了兩條a9-setup-a8 dri（數據準備指示）分別為1和0，要求建立a8鏈路。在bsc的v200r001c02b018sp0x系列的版本中，由于pcf的處理缺陷，如果pcf在極短的時間之內連續收到為同一個at的建立a8連接的請求，pcf會認為pcf與an的資源狀態不一致，所以pcf就通過第二條a11注冊請求消息，釋放相關的資源，把呼叫釋放到null態，在5秒之后，an給at發送了連接拒絕消息。2、分析為什么an會在極短的時間之內給pcf發送兩條a9-setup-a8。通過消息內容的分析，這兩條a9-setup-a8的dri分別等于1和0，由

10、于用戶有數據要傳，因此an會發送dri=1的a9-setup-a8消息，要求建立a8鏈路，在何種情況下會發送dri=0的a9-setup-a8消息呢？分析協議知道發送dri=0的a9-setup-a8消息原因有：l 用戶在休眠態下發生an間切換l 用戶在休眠態下發生1x與do之間的切換l 用戶在激活態的時候釋放呼叫l 會話進行配置協商后，發起的a8建立很明顯，前面的三種情況都不符合。3、分析相關的信令流程，可以看到，確實是在會話配置協商的同時，用戶發起了do呼叫接入，因此an在2ms的時間之內給pcf發送了兩條a9-setup-a8。圖1-3 an在2ms的時間之內給pcf發送了兩條a9-se

11、tup-a8的信令4、由此得到這個問題的根本原因：由于an在極短的時間內，對于同一個at的a8鏈路建立，給pcf發送了兩條a9-setup-a8，在v2r1的版本中，pcf對于這種特殊的場景的處理存在缺陷，拒絕了呼叫的接入。因此這個問題的產生與at頻繁進行會話的配置協商有關。at可能發起位置更新的場景：l 位置信息發生變化，比如：sin、nid和pzid，這三個id中的任何一個發生變化，at都會發起位置更新。l 會話的配置協商完成后，如果an支持位置更新，at就會發起位置更新。首先對at發送的locationnotification消息進行分析，可以發現所有的消息中的sid、nid和pzid的

12、值都是一樣的，據此可以排除位置信息發生變化這種原因。再通過對跟蹤的信令流程進行分析，可以發現at與an不斷地對搜索窗口的大小進行協商，對其中的兩條routeupdconfigrequest進行分析，可以看到相鄰集搜索窗口在8和9之間來回變動。圖1-4 rur消息相鄰集搜索窗口不同搜索窗的大小是會話建立時需要協商的參數，如果協商好的參數發生變化，那么肯定需要重新進行會話的配置協商。另外，根據abis-do-bts setup消息，我們找到了這個區域幾個主要的載頻，發現在配置腳本中，它們相鄰集的搜索窗口確實是不相等的：mod docnp: cn=2054, sctid=1, crrid=10, p

13、ilotincrement=4, srchwina=5, srchwinn=9, srchwinr=14, confirm=y;mod docnp: cn=2169, sctid=2, crrid=10, pilotincrement=4, srchwina=5, srchwinn=8, srchwinr=14, confirm=y;mod docnp: cn=2169, sctid=1, crrid=10, pilotincrement=4, srchwina=5, srchwinn=8, srchwinr=14, confirm=y;【結論、解決方案及效果】覆蓋這個區域的幾個主要載頻的相鄰

14、集搜索窗口配置不相等，導致了會話重新發起配置協商。分析頻繁位置更新的信令流程，發現at頻繁發起位置更新的原因：在一個切換區域中，幾個主要的載頻的搜索窗配置不相等，導致頻繁發起會話的配置協商過程，隨帶著at頻繁發起位置更新。圖1-5 頻繁位置更新的信令流程分析把這幾個載頻的相鄰集搜索窗口修改相等，修改后上述問題全部解決。【經驗總結、預防措施和規范建議】無。【備注】無。第2章 切換類案例2.1 框間鏈路未配置導致ev-do切換失敗作者：唐明通（39938）最小部門：俄羅斯代表處所屬產品：cdma bss來源：網絡優化關鍵字：ev-do切換 框間鏈路 鄰區漏配 cbssstar【現象、問題描述】b國

15、某cdma450m ev-do局點，反饋在配置反向搜索窗24chips基站和96chips基站之間ev-do軟切換失敗，現象為速率陡降或者連接中斷。現場bss版本為v200r001c02b018，s3/3/3組網，2個1x頻點1個ev-do頻點。【關鍵過程、根本原因分析】導致ev-do切換失敗或者速率陡降的原因有：l 漏配ev-do鄰區；l bsc間切換區域；l 導頻污染。通過現場反饋bam數據分析，發現鄰區漏配，進一步通過打開ev-do鄰區漏配檢測開關和bsc runlog鄰區漏配記錄軟參，通過cbssstar分析runlog文件，檢測出漏配鄰區，反饋現場添加。具體命令如下：1、mod do

16、rrmmp: detecmisspilotswitch=on;打開鄰區漏配檢測功能開關，此開關v1r3默認關閉，v2r1/v2r2默認打開。2、mod softpara: srvmn=rrm, prmno=50, prmv=0x1;打開寫日志開關，鄰區漏配檢測的結果就會被寫入到spu日志中，然后用工具進行分析后輸出鄰區腳本（與1x鄰區形式一致）。（注意上述0x1指的是將rrm第50號軟參的bit0的值，由默認值0修改為1，請使用lst softpara命令首先查詢該軟參設置值，然后將bit0設為1）。【結論、解決方案及效果】增加鄰區后，測試結果表明部分切換成功，但還有很多切換失敗。讓現場反饋最

17、新bam數據，通過工程輔助系統還原檢查系統參數配置，發現現場配置有兩個ev-do框，但框間未配置軟切換鏈路，進一步發現測試區域基站分布在兩個ev-do框里，通知現場配置ev-do框間鏈路，測試結果表明ev-do切換正常，問題得到解決。【經驗總結、預防措施和規范建議】bsc配置有多個ev-do框，框間也需要配置軟切換鏈路。ev-do切換失敗很多原因跟鄰區漏配有關，要充分利用cbssstar鄰區漏配檢測功能發現漏配鄰區。【備注】無。第3章 do速率低案例3.1 abis傳輸亂序導致do rev.a單用戶下載速率低作者：吳鈺鋒(45700)、葉國駿（47562）最小部門：cdma & wimax網絡

18、性能研究部所屬產品：cdma bss來源：比拼測試關鍵字：速率低 亂序【現象、問題描述】在b市無線環境非常好的情況下（drc申請速率為3.1mbps），使用do rev.a終端進行單用戶下載，即使同時使用兩個線程進行下載，平均下載速率也不超過2.5mbps。【關鍵過程、根本原因分析】考慮到組網的特殊性，bsc和bts分別與兩個匯聚路由相聯，兩個匯聚路由之間預留有3根e1口通過微波傳輸（如下圖），先在a市進行無線環境很好情況下單用戶下載，發現下載速率正常，可達2.8mbps。圖3-1 網絡結構圖使用ping測試abis傳輸的誤包率，發現誤包率非常低，沒有問題。通過qxdm測試發現，下載速率比正常

19、情況低300kbps的主要原因為abis口存在大量的rlp重傳，at側統計的總的重傳字節和接收到的新包字節數量幾乎相當，有大量數據是重復字節。采用逐段排除的方法，將fmr的接收、發送數據、ec板的接收數據，與at的接收數據進行對比，找出吞吐量損失的大致位置，然后通過該處的信息跟蹤進行精確定位，定位出丟失的包實際上是由于abis鏈路上產生了亂序，而rlp層無法分辯亂序還是丟包，從而引發了大量的rlp重傳。【結論、解決方案及效果】下載速率低主要原因是：abis口路由間ip傳輸導致數據亂序，最終導致大量rlp重傳。解決方案：1）推動客戶檢查了網絡，發現兩個匯聚路由器之間，3根e1中的1根存在時鐘配置

20、問題，修改后亂序包的比例從2%下降到0.1%以下，網絡質量得到優化；2）信道板增加了排序功能（bts計劃合入到v3r2c01版本中），rlp重傳大大減少。【經驗總結、預防措施和規范建議】在定位一些速率低等網上問題時，一定要考慮實際的網絡結構。由于我司產品驗證主要是在實驗室完成，而通常情況下實驗室無法考慮各種各樣的實際組網情況，所以在商用網中通常會出現這樣那樣的問題。【備注】無。3.2 ec板緩存太大導致頻繁切換時do rev.a終端掉零作者：吳鈺鋒(45700)、葉國駿（47562）最小部門：cdma & wimax網絡性能研究部所屬產品：cdma bss來源：比拼測試關鍵字：頻繁切換 掉零【

21、現象、問題描述】使用anydata終端（協商為do rev.a模式）進行路測，在切換帶內，經常出現速率掉零，且長時間無法自動恢復，需要手動重啟ftp下載后，下載才能恢復正常。【關鍵過程、根本原因分析】分析at的log數據，發現在產生掉零的位置，空口環境變化非常劇烈，at申請的drc在0到1.2m之間劇烈波動，同時at的rlp數據中增加了許多rlp abort。分析fmr和信道板的打印信息，發現信道板此時的緩沖隊列大多為滿的狀態。由于drc由大到小變化非常迅速，又伴隨多次虛擬軟切換，每次虛擬軟切換都會將緩沖區中的數據全部清空，因此，fmr下發的重傳數據不能及時的發到at，導致at側產生rlp a

22、bort，將錯誤遺留到上層tcp層后，引發tcp的懲罰機制，導致速率降為0。【結論、解決方案及效果】ec板的緩存默認設置為32760byte，在大部分情況下切換是沒有問題的，但對于頻繁切換情況，由于產品的實現機制，在切換前需要清空原緩存，導致大量的數據靠上層的重傳來保證，大量的數據如果在at的rlp定時器超時之前來不及重傳，則會產生大量的rlp abort，傳遞到上層tcp層，從而導致掉零；但如果設置ec板的緩存值太小，由于擁塞控制機制，將會導致單用戶下載情況下速率達不到理論值。通過多次測試發現設置ec板緩存為14000byte時，頻繁切換導致掉零問題和下載速率低問題都可以得到解決。注意：ec

23、板緩存為代碼寫死參數，無維護臺命令可修改。14000byte適用于r國，但由于網絡的差異，不一定適合其它地方，對于特定的網絡，需要測試驗證。【經驗總結、預防措施和規范建議】為了兼顧頻繁切換導致掉零問題和下載速率低問題，需要合理設置一個平衡值。【備注】無。3.3 fmr緩沖區不夠導致頻繁切換時do rel.0終端掉零作者：吳鈺鋒(45700)、葉國駿（47562）最小部門：cdma & wimax網絡性能研究部所屬產品：cdma bss來源：比拼測試關鍵字：頻繁切換 路測 掉零【現象、問題描述】使用anydata終端（協商為do rel.0模式）進行路測，在切換帶內，經常出現速率掉零，且長時間無

24、法自動恢復，需要手動重啟ftp下載后，下載才能恢復正常。【關鍵過程、根本原因分析】對比該時段前后cait log，發現在gps時間15:44:06.203時，at發送了連續發送了兩條反向rlp消息，空洞長度分別為31842和25668字節，這樣的大空洞是導致速率掉零的直接原因。回放cait數據，在上述大片空洞產生之前都發生了虛擬軟切換：圖3-2 在大片空洞產生之前發生了虛擬軟切換分析fmr調試臺打印也可以看到，這段時間內切換很頻繁，開始的時候是0號分支作為主分支。當2號分支發起req時，基站緩沖區被清除，此時可以看到基站緩沖區數據量很大，幾乎是滿的。另外剛切換到2號分支，就發現2號分支連續幾秒

25、鐘收到的反向幀都是誤幀。此時處于無主分支狀態。基站又清除緩沖區，在這540ms內有損失了200多個前向包和200多個重傳包。基站上報的從空口發出去的frameid和fmr發給bts的frameid相差很大。在虛擬軟切換時，基站會清空發送緩沖區，基站的緩沖區設定是32760字節，相當于263個rlp包，而fmr只會記錄已發給bts的10個包記錄，當基站大量數據被清除時，要求傳輸的數據在fmr中找不到（基站剛把緩沖區填滿，就發生了虛擬軟切換），此時會在at的rlp層產生一個大小為200多個包的空洞，只能依靠于tcp層的重傳，這會導致很大的速率波谷。【結論、解決方案及效果】bts ec板緩存與fmr

26、的記錄相差太大是頻繁切換時do rel.0路測掉零的根本原因。通過修改fmr的記錄（從10改為270），頻繁切換時do rel.0路測掉零問題得到了解決。注：fmr的記錄數需要調整的可能性非常小，目前產品不支持命令修改，bsc版本v2r3c03b012最近版本已經把記錄數寫死為270。【經驗總結、預防措施和規范建議】無。【備注】無。3.4 ev-do qos速率權重設置錯誤導致vod視頻播放速率較低達不到理想的效果作者：張柏林最小部門：cbss產品技術服務部 所屬產品：cdma bss來源：網絡優化關鍵字：vod 金牌用戶 qos dogp【現象、問題描述】某局點對bsc6600,bts360

27、6、pdsn升級后利用三星e159手機撥號后進入vod視頻點播網站進行視頻播放，通過速度測試軟件測試的播放速率只有580kbps，而升級前穩定為1.4mbps。現場版本：bsc6600v200r003c02b014(061110)，bts3606-0r001engc04b01520061110),pdsn9660v800r105c01b011,組網：1個bsc6600、1個bts3606、1個pdsn、1業軟的流媒體服務器。【關鍵過程、根本原因分析】1、檢查ev-do基站的業務鏈路帶寬，分配給do的物理e1為兩條業務鏈路。帶寬設置沒有問題；2、檢查便攜機參數設置，tcp窗口、ip頭壓縮等設置的

28、均沒有問題；3、由于只用一個手機連接到便攜機上進行測試，所以不可能是由于用戶數過多引起的速率下降；4、手機上信號滿格，并且測試手機就在離基站不到5米的地方，排除了無線環境差的原因；5、檢查bsc參數設置：l 檢查tcp優化開關lst mapara，將tcp優化開關關閉后測試速率依然為580kbps，排除此開關的影響；l 檢查腳本中的其他軟參：mod softpara: srvmn=smp, prmno=0, prmv=0x01;mod softpara: srvmn=ccm, prmno=31, prmv=0x0;mod softpara: srvmn=pcu, prmno=3, prmv=0

29、x1;mod dofmr: fn=4, inactivetlen=255, confirm=y;設置沒有錯誤；l 考慮到ev-do可以針對同一個載頻下無線環境相似的不同等級用戶的數據業務呼叫前向平均傳輸速率，是不是這個速率設置的過小而影響到整個前向速率呢？ 首先使用lst dogp查詢ev-do全局參數，查詢bsc已經打開了qos開關； 使用命令lst doqos: grade=gold;查詢金牌用戶的前向速率限制為585.6kbps（gradefwdlmtrate=frate5856） 使用命令mod doqos: grade=gold, gradefwdlmtrate=frate23424

30、;將速率修改為2342.4后測試，vod播放速率正常。【結論、解決方案及效果】金牌用戶速率的前向設置為frate5856，那么這個載頻下的用戶最高就只能以585.6的最高速率接入了，無法以其他更高速率接入。qos速率權重設置錯誤導致vod視頻播放速率偏低。修改此參數后vod播放速率恢復正常。【經驗總結、預防措施和規范建議】涉及到ev-do的參數設置很多，希望大家在考慮正常數據配置問題的情況下，多檢查一下系統的參數配置。【備注】無。3.5 e1數目不足和業務鏈路配置錯誤造成ev-do數據業務下載速率低作者：陳世進（60653）最小部門：無線網絡規劃部所屬產品：cdma bss來源：網絡優化關鍵字

31、：ev-do ftp下載 速率低【現象、問題描述】m國ev-do網絡在完成所有安裝和配置之后，測試時單用戶使用ev-do ftp下載業務的平均速率只有700800kbps，使用內部ftp服務器下載，單用戶平均速率依然很低。【關鍵過程、根本原因分析】造成ev-do數據業務速率低的原因一般有如下幾點：l 空口質量差；l abis帶寬不足；l bsc、pcf和pdsn間pvc帶寬設置不合理；l bsc和bts配置業務鏈路數不一致；l 連接終端和ftp服務器的pc配置錯誤。1、用cait測試空口質量。測試結果表明c/i超過10db，drc始終為2.4mbps，而且測試過程中沒有收到相鄰扇區或者基站的信

32、號。這說明空口質量很好，不是造成下載速率低的原因。2、檢查連ftp服務器和接終端以及ftp服務器的pc的配置。確認配置無誤后，單用戶平均下載速率依然保持在700800kbps。3、檢查配置的e1數，發現每個ev-do基站只配置了一條e1。但即使只有一條e1，單用戶平均下載速率應該可以達到1.2mbps，因為一條e1的有效物理帶寬超過1.5m，所以e1數的限制還不是主要原因。不過每個ev-do基站只配置一條e1也是不合理的。給測試基站再加一條e1后，單用戶平均下載速率可以達到1.5 mbps。而根據經驗，配置2條e1后，單用戶平均下載速率應該超過1.9mbps，問題仍然沒有解決。4、在配置2條e

33、1后，用iperf測試從pdsn到pcf和從pdsn到ms的實際物理帶寬。測試結果為：pdsn和pcf之間的帶寬約為73m，屬于正常值；而pdsn和at之間的帶寬只有1.5m。5、檢查bsc的帶寬配置。用命令lst btslnk查詢bie板和bts間的帶寬設置，用命令lst alpath查詢bie板和fmr板間的帶寬設置，在這一步終于發現了問題：之前為每個ev-do基站配置了2條業務鏈路，但是每個ev-do基站只配置了一塊ec板。【結論、解決方案及效果】因此是e1數目不足和業務鏈路配置錯誤造成ev-do數據業務下載速率低。在bsc和bts側都刪除一條業務鏈路后，單用戶平均下載速率終于到達了2.0mbps，問題得到解決。【經驗總結、預防措施和規范建議】遇到ev-do數據業務下載速率低的問題時，一般都可以從空口質量、服務器的tcp/ip協議窗口配置、物理鏈路配置、業務鏈路數等幾個方面去查找原因。【備注】無。第4章 其他案例4.1 actix統計