1、產品名稱Product name密級Confidentiality levelWCDMA RNP內部公開產品版本Product versionTotal 35pages 共35頁2.0WCDMA RNO 專題指導書 接入問題分析 (僅供內部使用）For internal use only擬制:Prepared byURNP-SANA日期：Date2004-12-22審核:Reviewed by日期：Date審核:Reviewed by日期：Date批準:Granted by日期：Date華為技術有限公司Huawei Technologies Co., Ltd.版權所有 侵權必究All righ

2、ts reserved修訂記錄Revision record日期Date修訂版本Revision version修改描述 change Description作者Author2004-08-23100確定大綱官仕國2004-11-03100初稿完成官仕國2004-12-20100根據評審意見修改官仕國目 錄1概述72接入失敗分類定義73接入失敗分析流程及方法83.1分類數據分析流程8路測數據分析流程8話統數據分析流程13跟蹤數據分析流程15告警數據分析流程15用戶投訴分析流程153.2調整措施15工程參數15小區參數164典型接入失敗問題分析174.1尋呼問題17尋呼相關信道功率配置不合適17

3、尋呼時UE進行位置更新17UE隱式分離引起尋呼失敗184.2小區重選問題18現象和分析18解決方法204.3RRC建立問題21上行接入信道參數設置不合適21AICH信道功率設置不合適24FACH信道功率設置不合適24下行專用信道初始功率配置不合適274.4RAB和RB建立問題27RNC直接拒絕RAB的建立請求27IUB口準入拒絕28UE回應RB建立失敗造成的RAB建立失敗28空中接口RB建立失敗造成的RAB建立失敗284.5信令流程沒有完成出現切換失敗29現象和分析29解決方法314.6鑒權問題31失敗原因是MAC Failure31同步失敗（sync failure）314.7加密問題31問

4、題描述和分析31解決方法324.8設備異常問題32NodeB異常32手機異常345網優各階段關注點365.1單站測試階段365.2優化前評估階段365.3RF優化階段365.4參數優化階段365.5網優項目驗收階段366附錄：接入過程介紹36圖目錄圖1 路測數據或跟蹤數據的分析流程9圖2 主叫UE信令流程10圖3 尋呼問題分析流程圖11圖4 RRC連接建立問題分析流程圖13圖5 話統數據分析流程15圖6 UE的信令19圖7 UE第一次發送接入請求時的信號質量19圖8 UE第二次發送接入請求時的信號質量20圖9 UE的信令21圖10 RNC的單用戶跟蹤信令21圖11 下行信號質量22圖12 24

5、8號小區有規律的干擾23圖13 干擾局部放大圖23圖14 UE的信令25圖15 第一次發起接入請求時的信號強度25圖16 RNC的單用戶跟蹤信令26圖17 第一次發起接入請求時的信號強度27圖18 UE的信令30圖19 RNC的單用戶跟蹤31圖20 斷鏈前的信號強度31圖21 UE的信令34圖22 RNC的單用戶跟蹤信令34圖23 出問題時的信號強度34圖24 UE的信令35圖25 下行信號質量36WCDMA RNO 專題指導書 接入問題分析關鍵詞：接入、接通率、FACH、功率配比、RAB、鑒權、加密、話統摘 要：接通率是網絡KPI中的一個重要的指標，隨著網絡優化階段的不同優化的方法和重點會有

6、所不同，本文從話統、路測和跟蹤數據幾個方面來闡述接通率的優化方法，并通過大量的案例來描述各類問題的定位和分析方法。縮略語清單：縮略語英文全名中文解釋FACHForward access channel前向接入信道RACHRandom access channel隨機接入信道AICHAcquisition indication channel確認指示信道RBRadio bearer無線承載RRCRadio resource control無線資源控制1 概述本文的主要目的是詳細描述接入問題的定位流程和思路，包括從路測數據、話統數據等來分析接入失敗問題的原因。接入相關的知識介紹不是本文的重點，具體

7、可以參考資料【1】。在第四章中對典型的接入相關的問題進行了分類匯總，并詳細分析了原因和定位過程。第五章結合了網絡優化各個階段的特點列出了不同的關注點。2 接入失敗分類定義數據分析工具Analyser按照如下的原則來定義接入失敗，主叫UE在發出RRC Connection Request后，滿足下面任何一個條件都認為是接入失敗：a、 收到RRC Connection Reject消息；b、 UE在收到RRC Connection setup消息后收到或是發出了RRC Connection Release消息；c、 在Call setup過程中收到任何的BCCH上的消息；d、 定時器超時，即在UE

8、發送了RRC Connection Request后 3秒鐘（T300）內沒有收到RRC Connection setup消息。數據分析工具TEMS按照下面的原則來定義接入失敗（對于主叫語音業務）：a、 隨機接入失敗：撥號后RRC Connection Request消息沒有發送；b、 RRC Connection Setup消息沒有收到：UE發送了RRC Connection Request消息后沒有收到RRC Connection Setup消息c、 RRC Connection Complete消息沒有發出：UE在接收到RRC Connection Setup消息后，沒有發出RRC Co

9、nnection Setup Complete消息。d、 UE收到消息RRC Connection Reject：UE收到RRC Connection Reject消息并且沒有重發RRC Connection Request進行嘗試。e、 UE沒有收到測量控制消息：UE在發出RRC Connection Complete消息后沒有收到測量控制消息。 f、 沒有發出CM Service Request：UE在收到測量控制消息后沒有發出CM Service Request。g、 UE收到Service Request Reject消息：UE收到了Service Request Reject消息。h

10、、 UE沒有收到Call Proceeding消息：UE在發送了CC SETUP消息后沒有收到Call Proceeding消息。i、 UE沒有收到RB Setup消息：UE收到Call Proceeding消息后，沒有收到RB Setup消息。j、 UE沒有發出RB Setup Complete消息：UE在接收到RB Setup消息后，沒有發出RB Setup Complete消息。k、 Alert or Connect消息沒有收到：UE在發出RB Setup Complete消息后，沒有收到Alert or Connect消息。l、 UE沒有發出Connect Acknowlege消息：U

11、E收到Alert or Connect消息后，沒有發出Connect Acknowlege消息。RNC后臺的跟蹤數據沒有定義接入失敗，不過可以根據Call Setup的流程來區分是否是接入失敗，可以參考TEMS的接入失敗定義。話統數據中將接入的過程分成多個過程進行成功率統計，包括：CN_PAGE_IDLE_UE_SUCC_RATE，CN尋呼IDLE模式下的UE的成功率；UTRAN_PAGE1_SUCC_RATE ，UTRAN發起Page1尋呼，收到響應的成功率；RRC_SETUP_SUCC_RATE/RRC_REJ_RATE ，RRC建立成功率和RRC建立拒絕率；RRC_A

12、BNORM_REL_RATE，RRC被異常釋放的比率；RB_SETUP_SUCC_RATE，RB建立成功率；RAB_SETUP_SUCC_RATE，RAB指派成功率；通過這些指標可以獲得各個階段的成功率。3 接入失敗分析流程及方法3.1 分類數據分析流程3.1.1 路測數據分析流程1. 數據分析主流程如果某個用戶有路測數據或同時有單用戶跟蹤的數據，可以按照以下的流程進行分析：分析數據NYNYYNYYYNNNYN是否RRC連接建立失敗鑒權加密是否失敗RAB建立是否失敗是否是主叫失敗是否有Call Fail是否收到尋呼切換導致接入失敗尋呼問題RRC建立問題鑒權加密問題RAB或RB建立問題參考切換導

13、致掉話異常問題圖1 路測數據或跟蹤數據的分析流程1） 測試數據的獲取路測數據一般采用Agilent的E6474或者是我司開發的工具Probe連接上測試終端來獲得，RNC的單用戶跟蹤數據在RNC的操作維護臺記錄，建議使用TMSI來進行單用戶跟蹤，這樣可以記錄RRC建立的消息；RNC記錄CDL的數據。2） 確定是否有Call Fail和相應的時間通過路測數據分析軟件，比如Analyzer軟件或DA，確定發生Call Fail的時間，以及Call Fail前后Scanner采集的導頻信息、手機采集的激活集和監視集的信息以及信令流程。通過消息對齊手機采集的信令和RNC的單用戶跟蹤的時間，同時找到RNC

14、單用戶跟蹤的相應的出問題的時間點。由于不同的數據分析軟件對Call Fail的定義不一樣，比如TEMS定義UE重發一次RRC Connection Request消息為一次接入失敗，而Analyzer則認為這是一種正常的情況。如果使用Analyzer分析數據，需要通過人工統計RNC的單用戶跟蹤信令和UE的信令（或者使用文字查找工具）獲得UE重發RRC Connection Request的時間點。3） 問題分析結合RNC的單用戶跟蹤和UE的信令流程，按照圖1的流程確定在哪一處出現失敗。然后按照后續的各個子流程分析和解決問題，主要包括尋呼問題、RRC建立問題、RAB和RB建立問題、鑒權加密問題、

15、設備異常問題等。2. 尋呼問題分析流程尋呼問題一般都表現為：主叫完成RAB指派以及CC Setup，在等待Alerting消息的時候收到CN發來的Disconnect直傳消息，參見圖2。被叫從UE的信令流程一般看不出異常，但也出現過UE收到Page消息而沒有發起RRC連接建立請求。從被叫的RNC單用戶跟蹤可以看出收到CN下發的Page消息，但沒有后續的消息。圖2 主叫UE信令流程 CC CALL PROCEDING本應該在CC SETUP之后尋呼問題RNC是否下發pageUE是否收到page是否功率配比偏低是否是重選問題NYYNYNYN設備異常問題根據覆蓋情況調整功率配比優化小區重選參數異常問

16、題轉RRC建立問題圖3 尋呼問題分析流程圖出現尋呼問題的原因主要有圖示的幾類：RNC沒有下發page消息、尋呼信道或尋呼指示信道的功率偏低、UE發生小區重選等。1） 如果是RNC收到CN下發的page消息后UU口沒有下發，可能是尋呼信道的容量不夠（現階段由于網絡負載很低，出現的概率很小，在以后網絡負載較高時，可能會出現UU口page消息阻塞的情況），或者是設備異常。2） 如果RNC下發了page消息，而UE沒有收到，首先查看UE的駐留小區和監視小區的Ec/Io。如果駐留小區和監視小區的CPICH信道的Ec/Io都很低（低于-12dB），那么要么是PCH信道或者是PICH信道的功率偏低，或者是這

17、個點的覆蓋太差。3） 如果UE駐留小區的信號偏低而監視小區的信號較好，那么可能是小區重選的問題。還有就是在尋呼的時候UE從3G重選到2G或者是跨LAC的重選。3. RRC連接建立問題分析流程RRC連接建立失敗的問題通過UE的信令流程和RNC的單用戶跟蹤可以獲得。RRC連接建立的過程主要包括幾個步驟：UE通過RACH信道發送RRC Connection Request消息，RNC通過FACH信道發送RRC Connection Setup消息，UE在建立下行專用信道并同步后通過上行專用信道發送RRC Connection Setup CMP消息。RRC建立失敗一般有下面幾類原因：上行RACH的問

18、題、下行FACH功率配比問題、小區重選參數問題、下行專用初始發射功率偏低、上行初始功控問題、擁塞問題、設備異常問題等。在這些問題中尤其上行RACH的問題、下行FACH功率配比問題、小區重選參數問題、設備異常問題出現的概率比較高。1） UE發出RRC Connection Request消息，RNC沒有收到，如果此時的下行CPICH的Ec/Io不是太低（比如大于-14dB），一般都是RACH的問題，可能是上行的開環功控估計不準或、Preamble的功率攀升不夠或者是UE的輸出功率比要求值偏低等原因。2） RNC收到UE發的RRC建立請求消息后，下發了RRC Connection Setup消息而

19、UE沒有收到。查看此時的CPICH的Ec/Io，如果低于-12dB（因為基線的配置是基于Ec/Io為-12dB配置的），而且檢視集中沒有質量更好的小區，那么是覆蓋的問題可以適當提高FACH的功率。如果此時檢視集中有更好的小區，則可能是小區重選的問題，可以適當調整小區重選參數加快小區重選。3） UE收到RRC Connection Setup消息而沒有發出Setup Complete消息，如果此時下行的信號質量正常，那么可能是手機異常。否則可能是下行專用信道初始功率過低導致下行不能同步。4） UE發出RRC Setup Complete消息而RNC沒有收到，由于上行初始功控會讓UE的發射功率上升

20、，這種問題出現出現的概率很小。如果出現這類問題可以適當提高專用信道的Constant Value值。RRC建立問題UE是否發出請求消息RNC是否收到請求消息RNC是否發出建立消息UE是否收到建立消息UE是否發出建立完成消息RNC是否收到建立完成消息手機異常問題調整PRACH或AICH信道參數其他問題調整FACH信道功率調整下行初始發射功率調整上行專用信道開環功控參數是否發生小區重選優化小區重選參數NYNYNYNNYYNYNY圖4 RRC連接建立問題分析流程圖3.1.2 話統數據分析流程分析話統指標時，要先看RNC RAB建立成功率指標和RRC建立成功率指標，掌握網絡運行的整體情況后，再有針對性

21、地對小區性能統計。分析時一般采取過濾法，先找出指標明顯異常的小區分析，此時很可能是版本、硬件、傳輸、天饋或者數據配置出了問題導致的異常，可以結合NodeB和RNC的告警首先從這幾個方面檢查，同時按小區統計的話統指標里面也包括了一些原因值，比如RRC_REJ_CONG_CELL 表明RRC建立拒絕的原因為"congestion"。如無明顯異常，根據指標將各扇區載頻進行統計分類，可整理出各重點指標較差小區列表，對于這些小區進一步細分話統指標，比如RRC建立失敗看是主叫的原因還是被叫的原因等。然后可以在問題比較嚴重的小區重點路測重現和解決問題。1.分析RNC話統中和接入

22、相關的指標2.分析基于CELL的和接入相關的話統指標3.檢查系統告警是否異常3.1解決設備異常問題4.RRC建立成功率偏低6.RB建立成功率偏低5.RAB建立成功率偏低7.尋呼成功率偏低4.1解決RRC建立失敗問題5.1解決RAB建立失敗問題6.1解決RB建立失敗問題7.1解決尋呼失敗問題結束YYYYYNNNNN圖5 話統數據分析流程1. 分析RNC話統中和接入相關的指標與接入相關的指標主要包括RRC的建立成功率、RAB的建立成功率、RB的建立成功率以及Page的成功率。這些指標的計算可以參考話統分析指導書。RRC建立成功率和RAB的建立成功率即反映了網絡的接通率。通過分析這幾個指標了解網絡接

23、通率的現狀，同時獲得是什么業務的什么指標偏低需要提高。2. 分析基于CELL的和接入相關的指標在第1步的基礎上再分析按CELL統計的相應指標，可以獲得偏低的指標在網絡中的小區分布。對于指標特別差的小區重點分析。另外在按CELL統計的指標里面有一些問題原因的統計，比如對應RB建立失敗的原因，有按照配置不支持、失敗原因為“Configuration Unsupported”、 物理信道故障、“physicalChannelFailur”等原因統計的失敗次數。3. 檢查系統是否有告警異常檢查話統指標明顯較差的小區和RNC的告警信息，看是否有有設備異常。4. 分析和解決各指標偏低的問題（需補充）如何通

24、過話統來解決接通率的問題還需要后續積累經驗3.1.3 跟蹤數據分析流程跟蹤數據主要是RNC的單用戶跟蹤和各個接口的信令跟蹤，分析方法可以參考路測數據的分析流程。3.1.4 告警數據分析流程（暫缺）3.1.5 用戶投訴分析流程（暫缺）3.2 調整措施3.2.1 工程參數工程參數可調整的不多，主要有天線的方向角、下頃角、天線的波瓣寬度以及天線的增益等。一般來說主要在解決覆蓋導致的接入問題的時候會考慮調整這些工程參數。比如覆蓋的盲區通過增加站點、提高附近覆蓋小區的天線增益或者減小附近小區的天線下頃角等方法。在進行這些調整的時候注意對小區原來的覆蓋區域的信號質量的影響。3.2.2 小區參數下面列出了與

25、接入問題相關性比較大的幾個參數，在定位接入失敗的問題時，可以根據具體原因調整這些參數的設置：1. FACH信道的發射功率該參數定義了FACH的發射功率。該參數設置過小，會使得小區邊緣UE不能正確接收FACH承載的業務和信令，影響下行公共信道覆蓋，從而最終影響小區覆蓋，設置過大，則會對其它信道產生干擾，并且占用下行發射功率，影響小區容量。基線中FACH信道的功率為-1dB是基于覆蓋小區邊緣CPICH的Ec/Io為-12dB，如果現場的覆蓋更差，需要根據邊緣的CPICH的Ec/Io的大小相應的提高FACH的功率。2. PCH信道的發射功率該參數定義了PCH的發射功率。該參數設置過小，會使得小區邊緣

26、UE無法正確接收尋呼信息，增加尋呼的時延，導致尋呼成功率低，從而影響接入成功率。設置過大則浪費功率，增加了下行干擾。3. PICH信道的發射功率該參數定義了PICH的發射功率。該參數設置過小，會使得小區邊緣UE無法正確接收尋呼指示信息，導致呼叫時延增加，也有可能進行讀取PCH信道的誤操作，浪費UE電池，并影響下行公共信道覆蓋，從而最終影響小區覆蓋；由于PICH信道是連續發射的，所以設置過大，則會對其它信道產生干擾，并且占用下行發射功率，影響小區容量，所以建議不增加如果為了增加PICH的覆蓋可以減小NP值為18。減小NP會減小UU口的尋呼容量，在建網初期NP為18尋呼容量足夠，而且18也是業界的

27、典型配置。4. 小區重選參數測量遲滯2（Qhyst2s）根據R準則，當前服務小區測量值加上遲滯后參與小區重選排序。參數值的大小與小區所在地區的慢衰落特性相關。該參數主要防止當UE處于小區邊緣時由于慢衰落使得小區重選結果出現乒乓，從而可能導致頻繁的位置更新（空閑模式）、URA更新（URA_PCH）或小區更新（CELL_FACH，CELL_PCH)增加網絡信令負載，同時也增加了UE的電池損耗。5. 小區重選參數重選遲滯時間Treselections如果其它小區信號質量（UE測量的CPICH Ec/No）在該參數指定的時間內始終優于當前駐留小區的質量，則UE重選該小區作為駐留小區。該參數用于防止UE

28、在小區間的乒乓重選。6. 小區重選參數Sintrasearch同頻小區測量的啟動門限，當本小區的Ec/Io低于QRelxmin+2*Sintrasearch時啟動同頻小區測量。該參數影響會影響小區重選的速度，進而影響UE的一次接入成功率和IU口的一次尋呼成功率。在對UE的耗電影響比較小的情況下，建議將該值盡量設大。7. 小區重選參數Qoffset2臨小區的信號質量參與R準則評估前需要先減一個偏置即為Qoffset2。對于普通的單層小區，該參數可以設置為0，而通過Qhyst來達到相同的目的。建議一般不做調整。8. AICH信道的發射功率該參數設置過小，會使得小區邊緣UE無法正確接收捕獲指示，影響

29、下行公共信道覆蓋。基線中該參數配置為-6dB，從優化結果來看，AICH的功率在下行的覆蓋中一般沒有問題，而且該信道是連續發射的，如果提高功率會占用較大的下行容量。9. PRACH的相關參數對應上行PRACH的問題，需要調整PRACH的相應參數，包括preamble的重傳次數、preamble的功率攀升步進、preamble和Message和功率偏差等參數。這些參數相互制約，在出現PRACH信道的問題時，建議調整preamble的重傳次數，當前基線設置為8，建議設置為20避免PRACH的問題。4 典型接入失敗問題分析4.1 尋呼問題4.1.1 尋呼相關信道功率配置不合適和尋呼相關的有PICH和P

30、CH兩個信道，當這兩個信道的功率配置偏低不能滿足UE的解調的要求時，UE不能正確的接收尋呼消息。基線參數中PCH的功率設置為-2dB，PICH的功率設置為-7dB，根據參數優化的結果，這個功率配置可以確保小區信號質量為-12dB的尋呼要求。如果網絡的覆蓋比-12dB更差，可以考慮提高PCH的功率和減小NP值。在沒有UE的路測數據和RNC的單用戶跟蹤數據的情況下，如果尋呼的指標偏差，可以先分析網絡的覆蓋情況的分布圖，看是否有必要提高這兩個信道的功率配比。4.1.2 尋呼時UE進行位置更新這種情況通常發生在UE正在進行3G到2G的重選。當UE重選到2G，還沒有完成位置更新時，對此UE的尋呼消息在U

31、MTS網絡中下發，UE將收不到。一般3G到2G的重選需要5s的時間，在這5秒中對該UE的尋呼將會失敗。當UE的LAC變化也有可能會出現尋呼失敗，不過UE重選到目標小區和位置更新的時間比較短，從IU口來看不會出現尋呼失敗。4.1.3 UE隱式分離引起尋呼失敗UE一般情況下要周期性的進行位置更新，這個時間通常設置為2小時。核心網也有一個定時器，一般該定時器要比周期性位置更新的定時器要長，在定時器設置的時間內沒有收到該用戶的位置更新就會發起隱式分離，同時會將該用戶的呼叫允許標準清除，那么對該用戶的尋呼將會失敗。出現這種情況可能的原因是：UE長時間處于覆蓋的盲點，現在的網絡一般是GSM全覆蓋，在沒有U

32、MTS網絡覆蓋的情況下將會重選到GSM，所以這種情況的可能性不大。還有一種是誤操作比如直接拔掉手機電池或者直接拔掉USIM卡。4.2 小區重選問題4.2.1 現象和分析一個典型的小區重選導致RRC Connection Request重發的現象：圖6 UE的信令兩次UE重發請求消息之間的時間間隔大概是1.2S。圖7 UE第一次發送接入請求時的信號質量圖8 UE第二次發送接入請求時的信號質量按照系統基線配置的參數，Treselection為1，Qhyst2為2dB，Qoffset2為0dB，Sintrasearch為5。當目標小區的信號優于本小區的信號時，最快也需要1秒鐘才可以重選完成。因此目標

33、小區和本小區的信號變化類似上面描述的現象，那么小區重選參數優化的余地不大。因為Treselection最小只能設置為1。如果設置為0，那么因為我們的DRX最小只能設置為0.64秒，導致相當于重選的時間需要8*DRX，遠大于1秒。并且如果Treselection設置為0，那么協議規定目標小區需要比原小區的Ec/Io高3dB。統計多次小區重選的時間大概在1.21.4秒。4.2.2 解決方法為了盡量減少小區重選的時間，曾經將Qhyst2修改為0，SintraSearch修改為7，測試發現在步行測試時會出現乒乓小區重選，而重選的時間沒有減小。所以建議Qhyst2保持為2dB不變，而SintraSear

34、ch的設置盡可能的使UE早點啟動同頻測量。在對UE的功耗影響不大的前提下，建議Sintrasearch設置為7。4.3 RRC建立問題4.3.1 上行接入信道參數設置不合適1. 現象和分析下面是一次接入過程的相關信息：圖9 UE的信令圖10 RNC的單用戶跟蹤信令將時間對齊后發現RNC響應的是UE發上來的第二個RRC建立請求消息。此時的下行信號質量參見圖11。圖11 下行信號質量從圖3的信號質量可以看出，此時下行的信號質量很好，上行的信號應該不會很差。為什么上行第一次不能接入呢？后來在Warwick辦公室靜止測試，問題重現。每次在半個小時內必定回出現，有時出現4次RRC建立請求重傳不成功導致C

35、all Fail。對應的分析RNC根據TMSI跟蹤的信令，RNC沒有收到RRC Connection Request消息。這個小區的信號強度：RSCP為-60-70dBm，Ec/No為-2-4dB。根據先前的干擾分析，在該小區存在有規律的干擾參見下圖：圖12 248號小區有規律的干擾圖13 干擾局部放大圖注：每個干擾的持續時間大概在40秒左右，圖4最后一個尖峰不是和前面一樣的周期性干擾。只持續了很短的時間（一個樣點）。干擾在早上8：00到晚上9：00中，其他的時間沒有干擾。開始懷疑是干擾導致的問題。采樣數據，結合RNC的消息、UE的消息以及記錄的RTWP，發現在出現Call Fail時（UE發

36、了4次RRC建立請求）在前后1分鐘內都沒有干擾。所以這個問題可能和干擾還沒有關系。做了以下的測試來定位問題的原因1、采用高通手機（6200）進行了測試，在1個多小時的呼叫中，沒有出現一次類似的現象。在這個期間干擾依然存在。這說明高通的測試手機沒有問題。2、為了排除AICH的問題，將AICH的功率提高到0dB，測試moto手機，還是有問題。即問題的出現與AICH功率大小沒有關系。3、將AICH的功率恢復到-7dB，將Preamble的重傳次數從8提高為20次。測試了1個多小時，問題沒有出現。4、由于是在室內靜止測試，信號很穩定，并且信號很強，Ec/Io為-3左右，RSCP為-50dBm左右。懷疑

37、是否是在信號很好的地方MOTO的功率估計有問題，通過加下行負載將下行的Ec/Io降低到-7dB左右，問題依舊。5、為了進一步確定不是干擾導致的問題，在晚上10點以后測試，這個時候從RTWP來看沒有干擾，測試了1個多小時還是出現了4次重發Request的現象，另外還有兩次Call Fail。通過UE的系統消息和NodeB的干擾記錄對比分析，干擾確實及時更新了。有Request重傳的時間段里，前后系統消息里的干擾水平都沒變（-105dB）。這進一步說明moto Request重傳問題與外部干擾無關。通過以上的測試可以得到這樣的結論：該問題和上行干擾沒有關系，和AICH的功率配置也沒有關系。由于高通

38、手機6200也沒有問題，說明是MOTO上行RACH信道的問題。2. 解決方法修改Preamble的重傳次數在pilot網中測試，沒有再出現這種問題。4.3.2 AICH信道功率設置不合適AICH信道的功率配比直接影響UE對AI的解調，如果這個功率偏低會導致UE解調AI誤碼，將不能完成接入的過程。AICH的功率較早前設置為-12dB，這類問題比較多。現在的基線配置-6dB，完全可以滿足已知的MOTO、高通、NEC等手機的AICH在Ec/Io為-12dB情況下的解調。不過AICH的解調性能不同品牌的UE差別較大，對于沒有測試過的UE在出現PRACH的問題時需要關注AICH的功率配比。4.3.3 F

39、ACH信道功率設置不合適1. 現象和分析圖6是UE的信令。圖14 UE的信令以下是駐留小區和監測小區的信號強度：圖15 第一次發起接入請求時的信號強度說明：第二列是駐留小區的信號強度，第3列是駐留小區的擾碼，第四、五列是最好的監視小區的信號強度和擾碼號。兩個小區的信號一直在波動。圖16 RNC的單用戶跟蹤信令由于下行覆蓋比較差，這一次UE發起了接入請求，RNC收到了RRC建立請求消息并且下發了RRC建立消息，但下行的信號比較差，UE沒有收到。2秒鐘后UE發起第二次接入時候的信令和信號強度：圖17 第一次發起接入請求時的信號強度UE第二次發起接入請求的時候，下行信號的強度在-13dB左右，接入成

40、功。可以看出當下行信號Ec/Io低于-12dB以后不能保證下行FACH的正確接收。當前的FACH的功率配比是-1dB，這個配比值是在外場測試出FACH的Ec/No和功率配比值的關系曲線后假設小區邊緣的Ec/Io為-12dB的情況下給出的。為了提高FACH在-14dB情況下的接收成功率，同時結合我們異系統測量的啟動測量門限，建議將FACH的功率配比提高2dB。2. 解決方法修改FACH的功率配比為+1dB后測試，在KPI測試路線上沒有發現UE下行接收不到RRC Setup消息導致接入失敗的問題。4.3.4 下行專用信道初始功率配置不合適下行的初始發射功率有RNC根據當前的Ec/Io計算獲得，并且

41、在上下行已經同步進行內環功控前，初始發射功率維持不變。所以如果這個功率計算的偏小的話會導致UE下行不能同步導致RRC建立失敗。當出現UE收到RRC Connection Setup消息而沒有發RRC Connection Setup Complete消息時，可以查看UE發射接入請求時的Ec/Io和下行的碼域發射功率來確認是否是下行初始發射功率的問題。當前RNC計算的初始功率發射功率大部分情況來說是偏高的，所以出現這類問題的概率較小。4.4 RAB和RB建立問題4.4.1 RNC直接拒絕RAB的建立請求參數設置非法導致RNC直接回應RAB建立失敗在商用網絡的發生概率很小，一般是由特殊用戶的特殊操

42、作造成的。主要場景是：用戶PS業務的上行開戶和激活申請信息超過了手機的能力，導致RNC直接回應拒絕。例如：某特殊用戶的開戶能力是上下行384K，而其使用的手機上行最大能力只是64K，在用戶使用AT命令或者手機終端軟件（索愛手機終端軟件可以任意設置激活申請的QoS）設置激活PDP的QoS信息中上下行最大速率均為384K，這樣在RNC收到RAB指派請求時，發現請求的上行最大速率超過了UE的能力，將直接返回RAB建立失敗，不發起RB建立過程。由于參數設置錯誤超過UE能力的情況造成的RAB建立失敗后，SGSN會重新協商發起新的RAB指派，直到UE能力可以支持，最終完成RAB指派，對于用戶來說，這次PD

43、P激活仍然可以成功，指示獲得的最大速率為UE能力所能支持的最大速率。但是，如果UE的PDP激活請求中QoS設置要求的最小保證速率都超過了UE的能力，那么雖然網絡協商了較低的速率接受UE的PDP激活請求，但是當UE發現PDP激活接受消息中網絡協商的速率小于其最小保證速率時，會發起去激活PDP請求，最終無法完成PDP激活。4.4.2 IUB口準入拒絕這類問題在香港的網絡出現比較頻繁，在pilot網中有很多小區的IUB用于業務的AAL2的帶寬只能支持一個384k的業務，如果已經存在一個12.2k的語音業務，再激活PS384k業務，則IUB口會因為帶寬受限拒絕。表現為RAB assignment Re

44、sponse原因為申請速率不可獲得，然后SGSN會重選協商發起RAB指配。在話統里面表現為一次RAB建立失敗。在基于CELL的話統中有區分不同失敗原因的RAB建立失敗的統計，通過這些指標可以初步獲得RAB建立失敗的原因。4.4.3 UE回應RB建立失敗造成的RAB建立失敗UE回應RB建立失敗主要是由于用戶的錯誤行為造成。第一種情況是，用戶在已經有下行128K的數據業務時，收到了VP業務的RB建立請求（VP主叫或者被叫），由于大部分終端不支持下行同時進行VP和高速（大于等于64K）PS業務，UE直接回應RB建立失敗，原因是unsupported configuration。另一種情況是主叫3G終

45、端進行VP業務的被叫方駐留在GSM網絡，不支持VP業務，這樣在RNC收到RAB指派請求后，核心網Call Proceeding后立刻下發Disconnect命令（原因為Bearer capability not authorized），而此時UE在剛收到RB_SETUP命令，還沒來得及完成RB建立，收到該Disconnect后會馬上發起回應RB建立失敗，RNC返回RAB建立失敗，原因為failure in radio interface procudure。索愛Z1010終端經過測試可以穩定支持VP和PS128K的多RAB建立，Moto終端則不支持，會直接回應RB建立失敗，更多的終端和更新版本

46、的終端能力還需要不斷驗證確認。現在對于用戶這些行為造成的RAB建立失敗，在RNC B03D205版本的KPI統計中，只能通過PS（/CS）_RAB_SETUP_FAIL_PARAM_CELL來反映，不夠直觀，在后續的KPI版本統計中應該針對這樣的情況有更明確具體的話統點，明確用戶要求QoS高于簽約情況的話統點、UE自身判斷能力不足的話統點和被叫能力不足的話統點，通過這些話統點的指標可以更客觀分析網絡的質量。4.4.4 空中接口RB建立失敗造成的RAB建立失敗另一種RB建立失敗是RB建立命令沒有響應，導致RNC認為RB建立失敗。商用網絡中出現最多的是這種由于空中接口信號質量不好導致的RB建立失敗

47、。在過程上表現為RB建立命令沒有收到ACK或者沒有收到RB建立完成命令。這樣的情形主要出現在弱信號區，造成信號弱的原因有兩種情況，一種是UE沒有駐留在最優小區發起接入，另一種是覆蓋不好。UE沒有駐留在最優小區發起接入，會在RB建立過程中希望活動集更新加入最優小區（同時信號快速變化導致駐留小區信號快速下降），但是由于流程不能嵌套進行（網絡和終端都不支持），活動集更新只能等待RB建立完成后進行，導致RB建立過程在弱信號小區進行，容易出現失敗。對于這種情況需要提高同頻小區重選的啟動門限和速度，使得UE盡快駐留在最優小區，在最優小區發起接入，對于初期負載比較低的網絡，UE同頻小區重選啟動門限可以設置為

48、-4dB，Treselction為1，對于不同LAC邊界的小區，這些參數可以設置的低一些，減少位置更新和小區更新的信令流量。覆蓋不好造成的RB建立失敗分為上行和下行質量不滿足兩種情況。下行覆蓋引起的情況表現為UE無法收到RB建立命令，下行覆蓋質量不滿足部分原因是UE的解調性能不佳造成，部分原因是需要RF優化來解決的。上行覆蓋引起的情況表現為UE收到了RB建立命令，但是RAN收不到RB建立的ACK，這種情況往往是由于上行信令階段的外環功控性能不夠好所致，可以通過提高初始上行SIRtarget的方法來避免，在現階段的商用網絡中上行初始SIRtarget可以設置為較高的5dB，在提高上行信令處理性能

49、的同時對于網絡上行容量基本沒有影響。4.5 信令流程沒有完成出現切換失敗4.5.1 現象和分析UE在RRC建立完成到RAB指派之間或RB建立完成之后都有可能進行切換。如果在這個期間切換失敗會給用戶帶來感觀上的接入失敗。參見下面的一個例子，在Anylze軟件里表現為一次接入失敗。圖18 UE的信令相對應的RNC記錄的單用戶跟蹤：圖19 RNC的單用戶跟蹤此時的小區的信號強度：圖20 斷鏈前的信號強度從RNC的信令可以看出來121號小區信號很快的變差了，此時要加入56號小區，但是RNC下發的ActiveSet Update消息UE已經接收不到。4.5.2 解決方法此類問題的解決方法，主要是調整軟切

50、換的參數，使得目標小區盡早的加入。具體可以參考掉話分析指導數。4.6 鑒權問題4.6.1 失敗原因是MAC Failure1. 問題描述和分析此問題一般在剛開始使用新卡時經常出現，主要原因是沒有將USIM卡和HLR中給該用戶設置相同的Ki和OP（OPc）導致鑒權失敗，原因值為Mac Failure。定位方法：檢查開戶信息中的該IMSI的Ki值和OP（OPc）值是否相同。2. 解決方法因為USIM卡中已經有默認的Ki和OP（OPc），但通過讀卡器無法讀出此值，所以開戶時預先清楚此USIM卡的Ki和OP（OPc）或重新將USIM卡的Ki和OPc值燒成與HLR中相同的值。4.6.2 同步失敗（syn

51、c failure）1. 問題描述和分析USIM認為從VLR/SGSN收到的SQN不滿足要求，返回同步失敗，由于HLR內部處理機制的問題，進行鑒權計算的進程不能區分CS域鑒權請求和PS域鑒權請求，所以無法分別分配CS和PS的SQN的Index值，導致在CS域和PS域交叉進行時USIM卡會覆蓋原來的PS域或CS域的SQN值，結果偶爾會出現同步失敗。2. 解決方法同步失敗后會再進行一次鑒權，此時因為根據USIM卡中保存的SQN值重新取了鑒權集，所以不會同時出現兩次失敗情況。HLR計劃在V62版本中解決此問題。4.7 加密問題4.7.1 問題描述和分析手機不支持配置的加密算法、RNC和核心網加密模式

52、配置不匹配，如：MSC只配置了加密算法UEA0，而RNC只設置為支持UEA1，此時Iu接口會出現加密模式拒絕。在RRC Connect Setup CMP消息中看手機上報的能力是否支持。目前不支持加密的終端有：NEC 單模手機，NEC C606，NEC C616支持的終端有：Nokia 7600，Nokia 6650，Moto A835，高通6200，高通6250，西門子U15查看MSC或SGSN跟RNC選擇的加密模式是不是匹配，即MSC或SGSN支持的加密模式和RNC支持的加密模式必須要有相同的。4.7.2 解決方法更換手機或網絡側選擇非加密模式，MSC和SGSN可以選擇全部的加密模式，RNC根據