【正文】 g Score）給出建議（Suggestion），根據(jù)經(jīng)驗對于Adding Neighbour或To Be Determined建議，都要增加相應的鄰區(qū)關系。同頻鄰區(qū)優(yōu)先級優(yōu)化的原理：首先在M2000打開兩兩小區(qū)切換測量開關，然后統(tǒng)計一定時段（一般要求一周以上）統(tǒng)計兩兩小區(qū)軟切換的嘗試次數(shù)（），然后根據(jù)這個次數(shù)從多到少的順序?qū)ε渲绵弲^(qū)的優(yōu)先級進行優(yōu)化。需要注意的是，基于話統(tǒng)的鄰區(qū)優(yōu)先級優(yōu)化的前提是網(wǎng)絡必須有足夠的話務，否則結果不可信；而且打開了兩兩小區(qū)切換測量開關后，注意統(tǒng)計一段時間后必須關閉，以免影響RNC性能。具體操作上可以使用Nastar，把待檢查的RNC MML腳本導入NASTAR，然后使用NASTAR的“Oneway Neighbor Check”功能分析，如下圖：圖 35 Oneway Neighbor Check根據(jù)分析結果，經(jīng)過確認核實后（有些情況下特殊的切換策略可能需要配置單向鄰區(qū)），增加漏配的反向鄰區(qū)即可。異頻鄰區(qū)漏配的優(yōu)化可依照如下原則進行：l 按照與第一層異頻頻鄰區(qū)關系優(yōu)化同樣的方法，全網(wǎng)范圍內(nèi)盡量增加第二層異頻鄰區(qū)關系。 異系統(tǒng)鄰區(qū)優(yōu)化在存在共站GSM小區(qū)的情況下，把與本小區(qū)的天線方向角最近的共站GSM小區(qū)和該GSM小區(qū)的所有GSM鄰區(qū)作為本小區(qū)的異系統(tǒng)鄰區(qū)即可，并保持與該小區(qū)的鄰區(qū)關系同步更新。 章節(jié)小結本章節(jié)主要在華為現(xiàn)有商用網(wǎng)絡的經(jīng)驗基礎上，結合工具現(xiàn)狀，向一線介紹當前可行的且較為高效的鄰區(qū)優(yōu)化方案。章節(jié)介紹網(wǎng)絡接入性能的評估方法、測試方法、數(shù)據(jù)分析方法、常見問題和處理方法；同時章節(jié)內(nèi)容可以在網(wǎng)絡KP指標優(yōu)化以及網(wǎng)絡運行維護過程中，指導工程師定位和解決接入類問題。在路測中，常見的接入失敗問題包括語音呼叫失敗、VP呼叫失敗和PDP激活失敗。 Assistant軟件中接入失敗定義對于CS主叫，接入失敗事件定義：UE 發(fā)出 RRC REQUEST，其中的 IE establish cause是Originating Conversational Call，但是沒有收到直傳消息alerting。l 初始直傳和安全模式建立過程失?。篣E在發(fā)出RRC CONNECTION SETUP COMPLETE之后，沒有發(fā)出NAS SETUP消息。l RAB指配完成后的失?。篣E發(fā)送RB SETUP COMPLETE之后，主叫UE收到CN發(fā)來的DISCONNECT/RELEASE消息；或者主叫UE等待CONNECT或者ALERTING超時，發(fā)起call clearing 過程；或者收到alerting之前UE進入idle狀態(tài)，開始接收系統(tǒng)消息————————————————————————————————————————協(xié)議規(guī)定UE發(fā)出CM SERVICE REQUEST之后啟動定時器T303，如果在T303超時之前UE沒有收到CALL PROCEEDING、ALERTING、CONNECT或者RELEASE COMPLETE消息，則開始clearing過程。對于CS被叫，接入失敗事件定義：被叫UE收到paging type 1的尋呼，但是沒有發(fā)送原因值為Terminating Conversational Call的RRC CONNECTION REQUEST，或者發(fā)送之后沒有發(fā)送alerting直傳消息給CN。l 初始直傳和安全模式建立過程失敗：UE在發(fā)出RRC CONNECTION SETUP COMPLETE之后，沒有收到SETUP 直傳消息；或者UE發(fā)出RELEASE COMPLETE；或者UE收到CN的DISCONNECT消息。l RAB指配完成后的失?。篣E發(fā)送RB SETUP COMPLETE之后，被叫UE收到CN發(fā)來的DISCONNECT/RELEASE消息。 TEMS軟件中接入失敗定義TEMS軟件中，對于主叫語音業(yè)務按照下面的原則來定義接入失敗：l 隨機接入失?。簱芴柡驲RC Connection Request 消息沒有發(fā)送。l RRC Connection Complete消息沒有發(fā)出：UE在接收到RRC Connection Setup消息后，沒有發(fā)出RRC Connection Setup Complete消息。l UE沒有收到測量控制消息：UE在發(fā)出RRC Connection Complete消息后沒有收到測量控制消息。l UE收到Service Request Reject 消息：UE發(fā)出CM Service Request后收到了Service Request Reject消息。l UE沒有收到RB Setup消息：UE收到Call Proceeding消息后，沒有收到RB Setup消息。l Alert or Connect消息沒有收到：UE在發(fā)出RB Setup Complete消息后，沒有收到Alert or Connect消息。 接入失敗分析流程針對接入問題，分析流程如下：圖 41 接入失敗問題分析流程首先通過路測數(shù)據(jù)分析軟件，確定發(fā)生Call Fail的時間，并獲得Call Fail前后Scanner采集的導頻信息、手機采集的激活集和監(jiān)視集的信息以及信令流程。結合RNC的單用戶跟蹤和UE的信令流程，按照接入失敗問題分析流程的流程確定在哪一處出現(xiàn)失敗，然后按照后續(xù)的各個子流程分析和解決問題，主要包括尋呼問題、RRC建立問題、鑒權加密問題、安全模式問題、PDP激活問題、RAB和RB建立問題等。 尋呼問題分析尋呼問題一般都表現(xiàn)為：主叫完成RAB指派以及CC Setup，在等待Alerting消息的時候收到CN發(fā)來的Disconnect直傳消息。圖 42 尋呼問題主叫UE信令流程尋呼問題的原因主要有：l RNC沒有下發(fā)Paging消息l 尋呼信道或?qū)ず糁甘拘诺赖墓β势蚻 UE發(fā)生小區(qū)重選等 RNC沒有下發(fā)Paging消息如果RNC收到CN下發(fā)的paging消息后UU口沒有下發(fā)，可能是尋呼信道的容量不夠（現(xiàn)階段由于網(wǎng)絡負載很低，出現(xiàn)的概率很小，在以后網(wǎng)絡負載較高時，可能會出現(xiàn)UU口paging消息阻塞的情況），或者是設備異常。如果駐留小區(qū)和監(jiān)視小區(qū)的CPICH信道的Ec/Io都很低（低于12dB），可能是PCH信道或者PICH信道的功率偏低，或者是這個點的覆蓋太差。請參考案例小區(qū)重選導致RRC Connection Request重發(fā) 。請參考案例 UE進行位置更新導致尋呼失敗 。RRC連接建立的過程主要包括幾個步驟：l UE通過RACH信道發(fā)送RRC Connection Request消息。RRC 建立失敗一般有下面幾類原因：l 上行 RACH 的問題l 下行 FACH 功率配比問題l 小區(qū)重選參數(shù)問題l 下行專用初始發(fā)射功率偏低l 上行初始功控問題l 擁塞問題l 設備異常問題等在這些問題中尤其上行RACH的問題、下行FACH功率配比問題、小區(qū)重選參數(shù)問題、設備異常問題出現(xiàn)的概率比較高。l 如果此時下行CPICH的Ec/Io不是太低（比如大于14dB），一般都是RACH的問題。n UE的輸出功率比要求值偏低：屬于UE本身性能問題，更換UE。n 小區(qū)半徑設置參數(shù)不合理：小區(qū)半徑參數(shù)設置過小，會導致NodeB無法同步小區(qū)半徑范圍外的UE，造成接入失敗，這主要發(fā)生在農(nóng)村、郊區(qū)等廣覆蓋場景。RRC Connection Reject中拒絕原因值包含2種：congestion和unspecified。需要檢查網(wǎng)絡負載情況，包括功率、碼、CE等資源的占用情況，確定是由于那種資源不足導致的擁塞，然后給出相應的擴容手段。 RNC下發(fā)的RRC Connection Setup消息UE沒有收到該問題的可能原因有以下幾種：l 覆蓋差l 小區(qū)選擇與重選參數(shù)不合理具體檢查方法可以查看此時CPICH的Ec/Io，如果低于12dB（因為缺省是基于Ec/Io為12dB配置的），而且監(jiān)視集中沒有質(zhì)量更好的小區(qū)，那么是覆蓋的問題；如果此時監(jiān)視集中有更好的小區(qū)，則可能是小區(qū)重選的問題。在無法增強覆蓋的情況下，可參照現(xiàn)網(wǎng)PCPICH Ec/Io的覆蓋情況適當提高FACH的功率。對于小區(qū)選擇與重選引起的接入問題，可以通過調(diào)整小區(qū)選擇與重選參數(shù)，加快小區(qū)選擇與重選的速度，可以解決小區(qū)選擇與重選參數(shù)不合理造成的RRC連接建立失敗問題。由于UE發(fā)出RRC CONNECTION REQUEST是在PRACH信道的前導（preamble）被UTRAN側(cè)收到之后，以當時preamble的功率為基準，再在RACH信道上發(fā)出的。因此在某些覆蓋較差的區(qū)域，有可能出現(xiàn)RACH信道和FACH信道的覆蓋不平衡，使得UTRAN側(cè)能夠收到UE的RRC建立請求，而UE不能收到RNC發(fā)出的RRC CONNECTION SETUP。否則可能是下行專用信道初始功率過低導致下行不能同步，可以通過調(diào)整業(yè)務下行 Eb/No 解決。如果出現(xiàn)這類問題可以適當提高專用信道的Constant Value值，從而提高UE的上行DPCCH初始發(fā)射功率。該參數(shù)如果設置過大，有可能會使得用戶初始建鏈時帶來的上行干擾過大；如果設置過小，則會使得上行同步時間加長，甚至導致初始同步失敗?！猂RC CONNECTION SETUP COMPLETE是通過上行DPCH發(fā)送的，而UE根據(jù)收到的IE“DPCCH_Power_offset”和測量得的CPICH_RSCP的值計算出上行DPCCH的初始功率?！? 鑒權問題分析當出現(xiàn)鑒權失敗時，需要根據(jù)UE回復給網(wǎng)絡的鑒權失敗消息中給出的原因值進行分析。 MAC Failure手機終端在對網(wǎng)絡鑒權時，檢查由網(wǎng)絡側(cè)下發(fā)的鑒權請求消息中的AUTN參數(shù)，如果其中的MAC信息錯誤，終端會上報鑒權失敗消息，原因值為MAC Failure，如下所示：圖 44 鑒權失敗原因MAC Failure造成該問題的主要原因包括：l 非法用戶。 Sync Failure鑒權失敗的另外一種情況是手機終端檢測到AUTN消息中的SQN的序列號錯誤，引起鑒權失敗，原因值為Synch failure（同步失?。?，如下所示：圖 45 鑒權失敗原因Synch failure造成該問題的主要原因包括：l 非法用戶。 安全模式問題分析安全模式控制過程是由網(wǎng)絡側(cè)用來向無線接入網(wǎng)側(cè)發(fā)送加密信息的。安全模式命令正常流程如下所示：圖 46 安全模式控制安全模式拒絕信令流程如下所示：圖 47 安全模式拒絕導致安全模式拒絕通常的原因包括：l 手機能力問題，手機不支持配置的加密算法。對于由于手機能力造成的加密模式拒絕，只能通過更換手機來解決。如果加密模式不同，需要將MSC和SGSN設置為選擇全部的加密模式，RNC根據(jù)實際情況選擇UEA0或UEA1。 PDP激活失敗問題分析PDP激活失敗主要是UE發(fā)出Activate PDP Context Request后收到Activate PDP Context Reject。 UE側(cè)APN設置問題如果Activate PDP Context Reject的原因值為“Missing or unknown APN”，原因多半是APN設置與CN側(cè)不一致。Probe、UE的APN設置方法參見Genex Probe聯(lián)機幫助文件。需要檢查UE側(cè)請求速率的設置，與HLR開戶速率對照?！猆E發(fā)起數(shù)據(jù)業(yè)務時，其QoS要求由Activate PDP Context Request消息中上報給系統(tǒng)，消息結果如下圖：圖 48 PDP激活請求信令詳細解析l Traffic Class業(yè)務類別：在PDP激活請求中，業(yè)務類別包括以下幾類，其中“Subscribed traffic class”表示UE不確定業(yè)務類別，由核心網(wǎng)按該用戶開戶信息等來確定。 0 0 0 Subscribed traffic class216。 0 1 0 Streaming class216。 1 0 0 Background class216。 max bit rate up為上行最大速率，下圖為64，對應64kbits/s。 max bit rate down為下行最大速率，下圖為104，對應為384kbits/s。 guar bit rate up為上行保證速率，下圖為0，即對上行保證速率不做要求。 guar bit rate down為下行保證速率，下圖為0，即對下行保證速率不做要求。216。216。216。216。————————————————————————————————————————252。另外如果PS業(yè)務為初次調(diào)試，也有可能是HLR開戶的APN與GGSN中使用的APN不一致，可找現(xiàn)場負責PS域核心網(wǎng)相關人員確認。 RAB或RB建立問題分析當RAB或RB建立失敗時，RNC會在RAB Assignment Response信令中回RAB指配建立失敗。常見的RAB/RB建立失敗問題包括：l 參數(shù)配置錯誤導致RNC直接拒絕RAB的建立請求l 準入拒絕l UE回應RB建立失敗造成的RAB 建立失敗l 空中接口RB建立失敗造成的RAB 建立失敗 參數(shù)配置錯誤導致RNC直接拒絕RAB的建立請求參數(shù)設置非法導致RNC直接回應RAB建立失敗在商用網(wǎng)絡的發(fā)生概率較小，一般是由特殊用戶的特殊操作造成的。例如：某特殊用戶的開戶能力是上下行384K，而其使用的手機上行最大能力只是64K，在用戶使用AT命令或者手機終端軟件設置激活PDP的QoS信息中上下行最大速率均為384K，這樣在RNC收到RAB指派請求時，發(fā)現(xiàn)請求的上行最大速率超過了UE的能力，將直接返回RAB建立失敗，不發(fā)起RB建立過程。對于用戶來說，這次PD