接入問題分析

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

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

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

4、題描述和分析31解決方法324.8設(shè)備異常問題32NodeB異常32手機(jī)異常345網(wǎng)優(yōu)各階段關(guān)注點(diǎn)365.1單站測(cè)試階段365.2優(yōu)化前評(píng)估階段365.3RF優(yōu)化階段365.4參數(shù)優(yōu)化階段365.5網(wǎng)優(yōu)項(xiàng)目驗(yàn)收階段366附錄：接入過程介紹36圖目錄圖1 路測(cè)數(shù)據(jù)或跟蹤數(shù)據(jù)的分析流程9圖2 主叫UE信令流程10圖3 尋呼問題分析流程圖11圖4 RRC連接建立問題分析流程圖13圖5 話統(tǒng)數(shù)據(jù)分析流程15圖6 UE的信令19圖7 UE第一次發(fā)送接入請(qǐng)求時(shí)的信號(hào)質(zhì)量19圖8 UE第二次發(fā)送接入請(qǐng)求時(shí)的信號(hào)質(zhì)量20圖9 UE的信令21圖10 RNC的單用戶跟蹤信令21圖11 下行信號(hào)質(zhì)量22圖12 24

5、8號(hào)小區(qū)有規(guī)律的干擾23圖13 干擾局部放大圖23圖14 UE的信令25圖15 第一次發(fā)起接入請(qǐng)求時(shí)的信號(hào)強(qiáng)度25圖16 RNC的單用戶跟蹤信令26圖17 第一次發(fā)起接入請(qǐng)求時(shí)的信號(hào)強(qiáng)度27圖18 UE的信令30圖19 RNC的單用戶跟蹤31圖20 斷鏈前的信號(hào)強(qiáng)度31圖21 UE的信令34圖22 RNC的單用戶跟蹤信令34圖23 出問題時(shí)的信號(hào)強(qiáng)度34圖24 UE的信令35圖25 下行信號(hào)質(zhì)量36WCDMA RNO 專題指導(dǎo)書 接入問題分析關(guān)鍵詞：接入、接通率、FACH、功率配比、RAB、鑒權(quán)、加密、話統(tǒng)摘 要：接通率是網(wǎng)絡(luò)KPI中的一個(gè)重要的指標(biāo)，隨著網(wǎng)絡(luò)優(yōu)化階段的不同優(yōu)化的方法和重點(diǎn)會(huì)有

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

7、可以參考資料【1】。在第四章中對(duì)典型的接入相關(guān)的問題進(jìn)行了分類匯總，并詳細(xì)分析了原因和定位過程。第五章結(jié)合了網(wǎng)絡(luò)優(yōu)化各個(gè)階段的特點(diǎn)列出了不同的關(guān)注點(diǎn)。2 接入失敗分類定義數(shù)據(jù)分析工具Analyser按照如下的原則來定義接入失敗，主叫UE在發(fā)出RRC Connection Request后，滿足下面任何一個(gè)條件都認(rèn)為是接入失?。篴、 收到RRC Connection Reject消息；b、 UE在收到RRC Connection setup消息后收到或是發(fā)出了RRC Connection Release消息；c、 在Call setup過程中收到任何的BCCH上的消息；d、 定時(shí)器超時(shí)，即在UE

8、發(fā)送了RRC Connection Request后 3秒鐘（T300）內(nèi)沒有收到RRC Connection setup消息。數(shù)據(jù)分析工具TEMS按照下面的原則來定義接入失?。▽?duì)于主叫語音業(yè)務(wù)）：a、 隨機(jī)接入失敗：撥號(hào)后RRC Connection Request消息沒有發(fā)送；b、 RRC Connection Setup消息沒有收到：UE發(fā)送了RRC Connection Request消息后沒有收到RRC Connection Setup消息c、 RRC Connection Complete消息沒有發(fā)出：UE在接收到RRC Connection Setup消息后，沒有發(fā)出RRC Co

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

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

11、E收到Alert or Connect消息后，沒有發(fā)出Connect Acknowlege消息。RNC后臺(tái)的跟蹤數(shù)據(jù)沒有定義接入失敗，不過可以根據(jù)Call Setup的流程來區(qū)分是否是接入失敗，可以參考TEMS的接入失敗定義。話統(tǒng)數(shù)據(jù)中將接入的過程分成多個(gè)過程進(jìn)行成功率統(tǒng)計(jì)，包括：CN_PAGE_IDLE_UE_SUCC_RATE，CN尋呼IDLE模式下的UE的成功率；UTRAN_PAGE1_SUCC_RATE ，UTRAN發(fā)起Page1尋呼，收到響應(yīng)的成功率；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指派成功率；通過這些指標(biāo)可以獲得各個(gè)階段的成功率。3 接入失敗分析流程及方法3.1 分類數(shù)據(jù)分析流程3.1.1 路測(cè)數(shù)據(jù)分析流程1. 數(shù)據(jù)分析主流程如果某個(gè)用戶有路測(cè)數(shù)據(jù)或同時(shí)有單用戶跟蹤的數(shù)據(jù)，可以按照以下的流程進(jìn)行分析：分析數(shù)據(jù)NYNYYNYYYNNNYN是否RRC連接建立失敗鑒權(quán)加密是否失敗RAB建立是否失敗是否是主叫失敗是否有Call Fail是否收到尋呼切換導(dǎo)致接入失敗尋呼問題RRC建立問題鑒權(quán)加密問題RAB或RB建立問題參考切換導(dǎo)

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

14、單用戶跟蹤的相應(yīng)的出問題的時(shí)間點(diǎn)。由于不同的數(shù)據(jù)分析軟件對(duì)Call Fail的定義不一樣，比如TEMS定義UE重發(fā)一次RRC Connection Request消息為一次接入失敗，而Analyzer則認(rèn)為這是一種正常的情況。如果使用Analyzer分析數(shù)據(jù)，需要通過人工統(tǒng)計(jì)RNC的單用戶跟蹤信令和UE的信令（或者使用文字查找工具）獲得UE重發(fā)RRC Connection Request的時(shí)間點(diǎn)。3） 問題分析結(jié)合RNC的單用戶跟蹤和UE的信令流程，按照?qǐng)D1的流程確定在哪一處出現(xiàn)失敗。然后按照后續(xù)的各個(gè)子流程分析和解決問題，主要包括尋呼問題、RRC建立問題、RAB和RB建立問題、鑒權(quán)加密問題、

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

16、題轉(zhuǎn)RRC建立問題圖3 尋呼問題分析流程圖出現(xiàn)尋呼問題的原因主要有圖示的幾類：RNC沒有下發(fā)page消息、尋呼信道或?qū)ず糁甘拘诺赖墓β势汀E發(fā)生小區(qū)重選等。1） 如果是RNC收到CN下發(fā)的page消息后UU口沒有下發(fā)，可能是尋呼信道的容量不夠（現(xiàn)階段由于網(wǎng)絡(luò)負(fù)載很低，出現(xiàn)的概率很小，在以后網(wǎng)絡(luò)負(fù)載較高時(shí)，可能會(huì)出現(xiàn)UU口page消息阻塞的情況），或者是設(shè)備異常。2） 如果RNC下發(fā)了page消息，而UE沒有收到，首先查看UE的駐留小區(qū)和監(jiān)視小區(qū)的Ec/Io。如果駐留小區(qū)和監(jiān)視小區(qū)的CPICH信道的Ec/Io都很低（低于-12dB），那么要么是PCH信道或者是PICH信道的功率偏低，或者是這

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

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

19、UE沒有收到。查看此時(shí)的CPICH的Ec/Io，如果低于-12dB（因?yàn)榛€的配置是基于Ec/Io為-12dB配置的），而且檢視集中沒有質(zhì)量更好的小區(qū)，那么是覆蓋的問題可以適當(dāng)提高FACH的功率。如果此時(shí)檢視集中有更好的小區(qū)，則可能是小區(qū)重選的問題，可以適當(dāng)調(diào)整小區(qū)重選參數(shù)加快小區(qū)重選。3） UE收到RRC Connection Setup消息而沒有發(fā)出Setup Complete消息，如果此時(shí)下行的信號(hào)質(zhì)量正常，那么可能是手機(jī)異常。否則可能是下行專用信道初始功率過低導(dǎo)致下行不能同步。4） UE發(fā)出RRC Setup Complete消息而RNC沒有收到，由于上行初始功控會(huì)讓UE的發(fā)射功率上升

20、，這種問題出現(xiàn)出現(xiàn)的概率很小。如果出現(xiàn)這類問題可以適當(dāng)提高專用信道的Constant Value值。RRC建立問題UE是否發(fā)出請(qǐng)求消息RNC是否收到請(qǐng)求消息RNC是否發(fā)出建立消息UE是否收到建立消息UE是否發(fā)出建立完成消息RNC是否收到建立完成消息手機(jī)異常問題調(diào)整PRACH或AICH信道參數(shù)其他問題調(diào)整FACH信道功率調(diào)整下行初始發(fā)射功率調(diào)整上行專用信道開環(huán)功控參數(shù)是否發(fā)生小區(qū)重選優(yōu)化小區(qū)重選參數(shù)NYNYNYNNYYNYNY圖4 RRC連接建立問題分析流程圖3.1.2 話統(tǒng)數(shù)據(jù)分析流程分析話統(tǒng)指標(biāo)時(shí)，要先看RNC RAB建立成功率指標(biāo)和RRC建立成功率指標(biāo)，掌握網(wǎng)絡(luò)運(yùn)行的整體情況后，再有針對(duì)性

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

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

23、通率的現(xiàn)狀，同時(shí)獲得是什么業(yè)務(wù)的什么指標(biāo)偏低需要提高。2. 分析基于CELL的和接入相關(guān)的指標(biāo)在第1步的基礎(chǔ)上再分析按CELL統(tǒng)計(jì)的相應(yīng)指標(biāo)，可以獲得偏低的指標(biāo)在網(wǎng)絡(luò)中的小區(qū)分布。對(duì)于指標(biāo)特別差的小區(qū)重點(diǎn)分析。另外在按CELL統(tǒng)計(jì)的指標(biāo)里面有一些問題原因的統(tǒng)計(jì)，比如對(duì)應(yīng)RB建立失敗的原因，有按照配置不支持、失敗原因?yàn)椤癈onfiguration Unsupported”、 物理信道故障、“physicalChannelFailur”等原因統(tǒng)計(jì)的失敗次數(shù)。3. 檢查系統(tǒng)是否有告警異常檢查話統(tǒng)指標(biāo)明顯較差的小區(qū)和RNC的告警信息，看是否有有設(shè)備異常。4. 分析和解決各指標(biāo)偏低的問題（需補(bǔ)充）如何通

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

25、接入問題相關(guān)性比較大的幾個(gè)參數(shù)，在定位接入失敗的問題時(shí)，可以根據(jù)具體原因調(diào)整這些參數(shù)的設(shè)置：1. FACH信道的發(fā)射功率該參數(shù)定義了FACH的發(fā)射功率。該參數(shù)設(shè)置過小，會(huì)使得小區(qū)邊緣UE不能正確接收FACH承載的業(yè)務(wù)和信令，影響下行公共信道覆蓋，從而最終影響小區(qū)覆蓋，設(shè)置過大，則會(huì)對(duì)其它信道產(chǎn)生干擾，并且占用下行發(fā)射功率，影響小區(qū)容量?；€中FACH信道的功率為-1dB是基于覆蓋小區(qū)邊緣CPICH的Ec/Io為-12dB，如果現(xiàn)場(chǎng)的覆蓋更差，需要根據(jù)邊緣的CPICH的Ec/Io的大小相應(yīng)的提高FACH的功率。2. PCH信道的發(fā)射功率該參數(shù)定義了PCH的發(fā)射功率。該參數(shù)設(shè)置過小，會(huì)使得小區(qū)邊緣

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

27、典型配置。4. 小區(qū)重選參數(shù)測(cè)量遲滯2（Qhyst2s）根據(jù)R準(zhǔn)則，當(dāng)前服務(wù)小區(qū)測(cè)量值加上遲滯后參與小區(qū)重選排序。參數(shù)值的大小與小區(qū)所在地區(qū)的慢衰落特性相關(guān)。該參數(shù)主要防止當(dāng)UE處于小區(qū)邊緣時(shí)由于慢衰落使得小區(qū)重選結(jié)果出現(xiàn)乒乓，從而可能導(dǎo)致頻繁的位置更新（空閑模式）、URA更新（URA_PCH）或小區(qū)更新（CELL_FACH，CELL_PCH)增加網(wǎng)絡(luò)信令負(fù)載，同時(shí)也增加了UE的電池?fù)p耗。5. 小區(qū)重選參數(shù)重選遲滯時(shí)間Treselections如果其它小區(qū)信號(hào)質(zhì)量（UE測(cè)量的CPICH Ec/No）在該參數(shù)指定的時(shí)間內(nèi)始終優(yōu)于當(dāng)前駐留小區(qū)的質(zhì)量，則UE重選該小區(qū)作為駐留小區(qū)。該參數(shù)用于防止UE

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

29、下行公共信道覆蓋?；€中該參數(shù)配置為-6dB，從優(yōu)化結(jié)果來看，AICH的功率在下行的覆蓋中一般沒有問題，而且該信道是連續(xù)發(fā)射的，如果提高功率會(huì)占用較大的下行容量。9. PRACH的相關(guān)參數(shù)對(duì)應(yīng)上行PRACH的問題，需要調(diào)整PRACH的相應(yīng)參數(shù)，包括preamble的重傳次數(shù)、preamble的功率攀升步進(jìn)、preamble和Message和功率偏差等參數(shù)。這些參數(shù)相互制約，在出現(xiàn)PRACH信道的問題時(shí)，建議調(diào)整preamble的重傳次數(shù)，當(dāng)前基線設(shè)置為8，建議設(shè)置為20避免PRACH的問題。4 典型接入失敗問題分析4.1 尋呼問題4.1.1 尋呼相關(guān)信道功率配置不合適和尋呼相關(guān)的有PICH和P

30、CH兩個(gè)信道，當(dāng)這兩個(gè)信道的功率配置偏低不能滿足UE的解調(diào)的要求時(shí)，UE不能正確的接收尋呼消息?；€參數(shù)中PCH的功率設(shè)置為-2dB，PICH的功率設(shè)置為-7dB，根據(jù)參數(shù)優(yōu)化的結(jié)果，這個(gè)功率配置可以確保小區(qū)信號(hào)質(zhì)量為-12dB的尋呼要求。如果網(wǎng)絡(luò)的覆蓋比-12dB更差，可以考慮提高PCH的功率和減小NP值。在沒有UE的路測(cè)數(shù)據(jù)和RNC的單用戶跟蹤數(shù)據(jù)的情況下，如果尋呼的指標(biāo)偏差，可以先分析網(wǎng)絡(luò)的覆蓋情況的分布圖，看是否有必要提高這兩個(gè)信道的功率配比。4.1.2 尋呼時(shí)UE進(jìn)行位置更新這種情況通常發(fā)生在UE正在進(jìn)行3G到2G的重選。當(dāng)UE重選到2G，還沒有完成位置更新時(shí)，對(duì)此UE的尋呼消息在U

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

32、MTS網(wǎng)絡(luò)覆蓋的情況下將會(huì)重選到GSM，所以這種情況的可能性不大。還有一種是誤操作比如直接拔掉手機(jī)電池或者直接拔掉USIM卡。4.2 小區(qū)重選問題4.2.1 現(xiàn)象和分析一個(gè)典型的小區(qū)重選導(dǎo)致RRC Connection Request重發(fā)的現(xiàn)象：圖6 UE的信令兩次UE重發(fā)請(qǐng)求消息之間的時(shí)間間隔大概是1.2S。圖7 UE第一次發(fā)送接入請(qǐng)求時(shí)的信號(hào)質(zhì)量圖8 UE第二次發(fā)送接入請(qǐng)求時(shí)的信號(hào)質(zhì)量按照系統(tǒng)基線配置的參數(shù)，Treselection為1，Qhyst2為2dB，Qoffset2為0dB，Sintrasearch為5。當(dāng)目標(biāo)小區(qū)的信號(hào)優(yōu)于本小區(qū)的信號(hào)時(shí)，最快也需要1秒鐘才可以重選完成。因此目標(biāo)

33、小區(qū)和本小區(qū)的信號(hào)變化類似上面描述的現(xiàn)象，那么小區(qū)重選參數(shù)優(yōu)化的余地不大。因?yàn)門reselection最小只能設(shè)置為1。如果設(shè)置為0，那么因?yàn)槲覀兊腄RX最小只能設(shè)置為0.64秒，導(dǎo)致相當(dāng)于重選的時(shí)間需要8*DRX，遠(yuǎn)大于1秒。并且如果Treselection設(shè)置為0，那么協(xié)議規(guī)定目標(biāo)小區(qū)需要比原小區(qū)的Ec/Io高3dB。統(tǒng)計(jì)多次小區(qū)重選的時(shí)間大概在1.21.4秒。4.2.2 解決方法為了盡量減少小區(qū)重選的時(shí)間，曾經(jīng)將Qhyst2修改為0，SintraSearch修改為7，測(cè)試發(fā)現(xiàn)在步行測(cè)試時(shí)會(huì)出現(xiàn)乒乓小區(qū)重選，而重選的時(shí)間沒有減小。所以建議Qhyst2保持為2dB不變，而SintraSear

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

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

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

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

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

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

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

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

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

43、P激活仍然可以成功，指示獲得的最大速率為UE能力所能支持的最大速率。但是，如果UE的PDP激活請(qǐng)求中QoS設(shè)置要求的最小保證速率都超過了UE的能力，那么雖然網(wǎng)絡(luò)協(xié)商了較低的速率接受UE的PDP激活請(qǐng)求，但是當(dāng)UE發(fā)現(xiàn)PDP激活接受消息中網(wǎng)絡(luò)協(xié)商的速率小于其最小保證速率時(shí)，會(huì)發(fā)起去激活PDP請(qǐng)求，最終無法完成PDP激活。4.4.2 IUB口準(zhǔn)入拒絕這類問題在香港的網(wǎng)絡(luò)出現(xiàn)比較頻繁，在pilot網(wǎng)中有很多小區(qū)的IUB用于業(yè)務(wù)的AAL2的帶寬只能支持一個(gè)384k的業(yè)務(wù)，如果已經(jīng)存在一個(gè)12.2k的語音業(yè)務(wù)，再激活PS384k業(yè)務(wù)，則IUB口會(huì)因?yàn)閹捠芟蘧芙^。表現(xiàn)為RAB assignment Re

44、sponse原因?yàn)樯暾?qǐng)速率不可獲得，然后SGSN會(huì)重選協(xié)商發(fā)起RAB指配。在話統(tǒng)里面表現(xiàn)為一次RAB建立失敗。在基于CELL的話統(tǒng)中有區(qū)分不同失敗原因的RAB建立失敗的統(tǒng)計(jì)，通過這些指標(biāo)可以初步獲得RAB建立失敗的原因。4.4.3 UE回應(yīng)RB建立失敗造成的RAB建立失敗UE回應(yīng)RB建立失敗主要是由于用戶的錯(cuò)誤行為造成。第一種情況是，用戶在已經(jīng)有下行128K的數(shù)據(jù)業(yè)務(wù)時(shí)，收到了VP業(yè)務(wù)的RB建立請(qǐng)求（VP主叫或者被叫），由于大部分終端不支持下行同時(shí)進(jìn)行VP和高速（大于等于64K）PS業(yè)務(wù)，UE直接回應(yīng)RB建立失敗，原因是unsupported configuration。另一種情況是主叫3G終

45、端進(jìn)行VP業(yè)務(wù)的被叫方駐留在GSM網(wǎng)絡(luò)，不支持VP業(yè)務(wù)，這樣在RNC收到RAB指派請(qǐng)求后，核心網(wǎng)Call Proceeding后立刻下發(fā)Disconnect命令（原因?yàn)锽earer capability not authorized），而此時(shí)UE在剛收到RB_SETUP命令，還沒來得及完成RB建立，收到該Disconnect后會(huì)馬上發(fā)起回應(yīng)RB建立失敗，RNC返回RAB建立失敗，原因?yàn)閒ailure in radio interface procudure。索愛Z1010終端經(jīng)過測(cè)試可以穩(wěn)定支持VP和PS128K的多RAB建立，Moto終端則不支持，會(huì)直接回應(yīng)RB建立失敗，更多的終端和更新版本

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

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

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

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

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

51、c failure）1. 問題描述和分析USIM認(rèn)為從VLR/SGSN收到的SQN不滿足要求，返回同步失敗，由于HLR內(nèi)部處理機(jī)制的問題，進(jìn)行鑒權(quán)計(jì)算的進(jìn)程不能區(qū)分CS域鑒權(quán)請(qǐng)求和PS域鑒權(quán)請(qǐng)求，所以無法分別分配CS和PS的SQN的Index值，導(dǎo)致在CS域和PS域交叉進(jìn)行時(shí)USIM卡會(huì)覆蓋原來的PS域或CS域的SQN值，結(jié)果偶爾會(huì)出現(xiàn)同步失敗。2. 解決方法同步失敗后會(huì)再進(jìn)行一次鑒權(quán)，此時(shí)因?yàn)楦鶕?jù)USIM卡中保存的SQN值重新取了鑒權(quán)集，所以不會(huì)同時(shí)出現(xiàn)兩次失敗情況。HLR計(jì)劃在V62版本中解決此問題。4.7 加密問題4.7.1 問題描述和分析手機(jī)不支持配置的加密算法、RNC和核心網(wǎng)加密模式

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