GT分流后TD掉話整治優(yōu)化

1、ostcom_b2000產品配置手冊td-scdma掉話問題分析優(yōu)化指導手冊- 4 - 內容介紹td-scdma網(wǎng)絡優(yōu)化掉話問題分析介紹了td-scdma網(wǎng)絡優(yōu)化中的掉話問題進行分析，包括掉話定義，分析流程和方法，常見掉話原因和典型掉話案例分析。本文分5章。l 概述。l 掉話定義：介紹路測和話統(tǒng)中掉話定義。l 掉話分析流程和方法:詳細介紹掉話分析的流程和分析方法。l 常見掉話原因分析：介紹覆蓋、鄰區(qū)關系、切換、干擾等造成掉話的原因及分析的方法。l 典型掉話案例分析：結合廣州td網(wǎng)絡優(yōu)化案例進行分析。讀者對象本書適合下列人員閱讀：l 參與網(wǎng)絡優(yōu)化的相關人員。目錄優(yōu)化指導手冊1-1前言iii內容介

2、紹iii讀者對象iii本書約定iii目錄- 1 -第1章概述1-1第2章掉話定義2-12.1路測的掉話定義2-12.2話統(tǒng)指標中的掉話定義2-1第3章掉話分析流程和方法3-13.1路測數(shù)據(jù)分析流程3-13.2話統(tǒng)數(shù)據(jù)分析流程3-33.3跟蹤數(shù)據(jù)分析流程3-63.4用戶投訴分析流程3-9第4章常見掉話原因分析4-14.1覆蓋差4-14.2鄰區(qū)漏配4-14.3切換掉話4-24.4干擾掉話4-24.5流程交互失敗4-34.6異常4-34.7調整措施4-34.7.1工程參數(shù)4-34.7.2小區(qū)參數(shù)4-3第5章典型掉話案例分析5-15.1鄰區(qū)漏配5-15.2乒乓切換5-25.3弱覆蓋5-3附錄a:縮略語

3、1附錄b：文檔修訂記錄2圖 31掉話分析流程樹3-1圖 32 掉話原因判斷3-2圖 33 呼叫跟蹤分析流程3-7圖 34用戶投訴分析流程3-9圖 51鄰區(qū)漏配調整前5-1圖 52鄰區(qū)漏配調整后5-1圖 53乒乓切換調整前5-2圖 54乒乓切換調整后5-2圖 55弱覆蓋調整前5-3圖 56弱覆蓋調整5-3td-scdma網(wǎng)絡優(yōu)化掉話問題分析第4章 常見掉話原因分析第1章 概述在網(wǎng)絡建設及運營中，掉話率（calldroprate）是反映網(wǎng)絡質量的重要指標之一；掉話問題也是日常網(wǎng)絡優(yōu)化面臨的一個常見問題。掉話問題對用戶的負面影響最直接，因此掉話率是運營商最為關注的指標之一。實際的網(wǎng)絡中，影響掉話率的

4、因素很多，包括硬件問題、干擾問題、覆蓋問題、切換問題、參數(shù)問題等。本文結合廣州td網(wǎng)絡建設和優(yōu)化的經(jīng)驗，對掉話的定義、分析流程和方法、原因分析等內容進行描述。4-4第2章 掉話定義2.1 路測的掉話定義從ue側記錄的空口信令上看，在通話過程（連接狀態(tài)下）中，如果空口的消息，滿足以下三個條件的任何一個：1）收到任何的bch消息（即系統(tǒng)消息）2）收到rrc release消息且釋放的原因值為not normal3）收到cc disconnect，cc release complete，cc release三條消息中的任何一條，而且釋放的原因為not normal clearing或者not nor

5、mal，unspecified。2.2 話統(tǒng)指標中的掉話定義廣義的掉話率應該包含cn和utran的掉話率，由于網(wǎng)優(yōu)重點關注與utran側的掉話率指標，本文掉話率描述也重點關注utran側的kpi指標分析。utran側相關指標就是rnc觸發(fā)釋放的各業(yè)務rab個數(shù)。主要包括兩個方面：（1）業(yè)務建立成功后，rnc向cn發(fā)送rab release request消息。（2）業(yè)務建立成功后，rnc向cn發(fā)送iu release request消息，其后收到cn發(fā)送的iu release command。從大的方面來講，掉話分為兩大類，信令面掉話和用戶面掉話；從流程上看，信令面掉話是rnc發(fā)起了iu re

6、lease request，用戶面掉話是rnc主動發(fā)起rab release request。需要說明的是ran話統(tǒng)掉話的定義只從iu接口的角度進行統(tǒng)計，統(tǒng)計了rnc主動發(fā)起的rab release請求次數(shù)和iu release請求次數(shù)。而路測掉話定義主要從空口的消息和非接入層的消息結合原因值來進行定義的，兩者不完全一致的。比如說，對于同時進行主被叫通話，工具記錄主叫的空口消息，如果被叫異常掉話，那么分析主叫的流程也會是一次掉話，但從話統(tǒng)上看，這次主叫是沒有掉話指標記錄的。所以兩者的定義是不完全一致的，在分析時要注意區(qū)分。第3章 掉話分析流程和方法3.1 路測數(shù)據(jù)分析流程圖 31掉話分析流程樹

7、圖 32 掉話原因判斷 準備數(shù)據(jù)路測軟件采集數(shù)據(jù)文件rnc記錄的單用戶跟蹤rnc記錄的cdl 獲取掉話位置采用路測數(shù)據(jù)處理軟件，比如analyzer和獲取掉話的時間和地點，獲取掉話前后scanner采集的導頻數(shù)據(jù)，手機采集的激活集和監(jiān)測集信息，信令流程等。 分析scanner主導小區(qū)變化情況主要分析主導小區(qū)的變壞情況，如果主導小區(qū)相對穩(wěn)定，進一步分析rscp和c/i情況；如果主導小區(qū)變化頻繁，需要區(qū)分主導小區(qū)變化快的情況，或者沒有主導小區(qū)的情況，然后進一步進行乒乓切換掉話分析。 分析scanner主導小區(qū)信號rscp和c/i觀察scanner最好小區(qū)rscp，c/i，根據(jù)不同的情況分別處理rs

8、cp差，c/i差，可以確定為覆蓋問題；rscp正常，c/i差（排除切換來不及導致的，同頻鄰區(qū)干擾），可以確定為導頻干擾問題；rscp正常，c/i正常，如果ue激活集中小區(qū)與scanner最好小區(qū)不一致，可能為鄰區(qū)漏配或者切換來不及導致的掉話；如果ue激活集中小區(qū)與scanner最好小區(qū)一致,可能為上行干擾或者異常掉話。 路測重現(xiàn)問題由于一次路測不一定能夠采集到定位掉話問題需要的所有信息，此時需要通過進一步路測來收集數(shù)據(jù)。通過進一步的路測也能確認該掉話點是隨機掉話的點或者固定掉話點，一般來說固定掉話點一定需要解決，而隨機掉話點則需要根據(jù)掉話發(fā)生的概率來確定是否需要解決。3.2 話統(tǒng)數(shù)據(jù)分析流程分

9、析話統(tǒng)指標時，要先看rnc掉話率指標和信令面掉話率指標，掌握了網(wǎng)絡運行的整體情況。同時對關注的小區(qū)（小區(qū)集合）針對性地分析，按小區(qū)（小區(qū)集合）得到更詳細的掉話指標。分析時可使用話統(tǒng)分析工具得到不同業(yè)務的掉話情況以及大致的掉話原因。話統(tǒng)分析應獲得指標明顯異常的小區(qū)分析，如果小區(qū)以前kpi良好，此時很可能是版本、硬件、傳輸、天饋或者數(shù)據(jù)出了問題導致的異常，可以結合告警首先從這幾個方面檢查。如無明顯異常，根據(jù)指標將各扇區(qū)載頻進行統(tǒng)計分類，可整理出各重點指標較差小區(qū)列表，對于這些小區(qū)進一步細分話統(tǒng)指標（如分析更多相關指標，分析小時間間隔，分析可能引起掉話的指標，如切換指標等），同時結合cdl看掉話的原

10、因。實際分析解決等問題時，在重點抓住某個指標分析的同時需要結合其他指標一起分析。需要說明的是話統(tǒng)只有在統(tǒng)計量較大時，指標數(shù)值才具有指導意義。例如，出現(xiàn)掉話率為50%并不就代表網(wǎng)絡差，只有在呼叫次數(shù)、呼叫成功次數(shù)、掉話總次數(shù)的絕對值都已具備統(tǒng)計意義時，這個數(shù)值才具有意義話統(tǒng)分析流程可以簡述如下：1. 分析rnc掉話率和信令面掉話率rnc掉話率統(tǒng)計rnc觸發(fā)釋放的各業(yè)務rab個數(shù)，主要包括兩個方面：（1）業(yè)務建立成功后，rnc向cn發(fā)送rab release request消息。（2）業(yè)務建立成功后，rnc向cn發(fā)送iu release request消息，其后收到cn發(fā)送的iu release

11、command。信令面掉話主要是rnc發(fā)起了iu release request。分析iu口連接釋放情況得到信令面掉話率。2. 分析掉話原因在話統(tǒng)分析中還分析引起掉話的主要原因，可分析以下主要指標：rab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足csconvrabrelreq_resrab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤csconvrabrelreq_rerrrab釋放請求次數(shù)，原因：傳輸層錯誤csconvrabrelreq_l2errrab釋放請求次數(shù)，原因：協(xié)議錯誤csconvrabrelreq_perrrab釋放請求次數(shù)，原因：非接入層錯誤csconvrabrelreq_naserrr

12、ab釋放請求次數(shù)，原因：雜項錯誤csconvrabrelreq_otherrrab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足psconvrabrelreq_resrab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤psconvrabrelreq_rerrrab釋放請求次數(shù)，原因：傳輸層錯誤psconvrabrelreq_l2errrab釋放請求次數(shù)，原因：協(xié)議錯誤psconvrabrelreq_perrrab釋放請求次數(shù)，原因：非接入層錯誤psconvrabrelreq_naserrrab釋放請求次數(shù)，原因：雜項錯誤psconvrabrelreq_otherr類似還有interactive、streami

13、ng、background類型的cs、ps業(yè)務。3. 分析小區(qū)（小區(qū)集合）的掉話率指標上述只是對整個網(wǎng)絡分析，我們可分析小區(qū)掉話率指標，主要需要分析小區(qū)“amr掉話率”、“vp掉話率”、“ps掉話率”、“硬切換掉話率”。 對所有小區(qū)分別用以上的指標進行排序，選擇指標特別差的小區(qū)或者最差的一些小區(qū)，進一步按照分析掉話原因。無線電路域掉話率電路域掉話的rab數(shù)目/電路域rab指派建立成功的rab數(shù)目*100%電路域掉話的rab數(shù)目rnc請求釋放的電路域rab數(shù)目+rnc請求釋放的電路域iu連接對應的rab數(shù)目。無線分組域掉線率分組域掉線的rab數(shù)目/分組域rab指派建立成功的rab數(shù)目*100%分

14、組域掉線的rab數(shù)目rnc請求釋放的分組域rab數(shù)目+rnc請求釋放的分組域iu連接對應的rab數(shù)目無線掉話率擴展cs/ps域因該原因掉話的rab數(shù)目/cs/ps域rab指派成功的rab數(shù)目*100%cs/ps域因該原因掉線的rab數(shù)目rnc請求釋放的cs/ps域rab數(shù)目（對應該原因值）rnc請求釋放的cs/ps域iu連接對應的rab數(shù)目（對應該原因值）電路域掉話的rab數(shù)目/電路域64k業(yè)務話務量*100%電路域掉話的rab數(shù)目rnc請求釋放的電路域rab數(shù)目+rnc請求釋放的電路域iu連接對應的rab數(shù)目。為分析不同速率的ps掉話情況，可分析指標rnc_ps_384k_rab_rel_c

15、ell_trig_by_rncrnc_ps_128k_rab_rel_cell_trig_by_rncrnc_ps_64k_rab_rel_cell_trig_by_rnc切換掉話率情況：hho_interfeq_drop_out_cell / hho_interfeq_out_cellhho_interfeq_drop_in_cell / hho_interfeq_in_cellhho_intrafeq_drop_out_cell/ hho_intrafeq_out_cellhho_intrafeq_drop_in_cell/ hho_intrafeq_in_cell通過上述這些掉話率的分析

16、，我們可獲得不同業(yè)務及其速率在網(wǎng)絡中的性能，可獲得切換掉話情況。重要的是通過這一步可獲得指標較差的小區(qū)以及時間段。釋放原因指標：rab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足csconvrabrelreq_resrab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤csconvrabrelreq_rerrrab釋放請求次數(shù)，原因：傳輸層錯誤csconvrabrelreq_l2errrab釋放請求次數(shù)，原因：協(xié)議錯誤csconvrabrelreq_perrrab釋放請求次數(shù)，原因：非接入層錯誤csconvrabrelreq_naserrrab釋放請求次數(shù)，原因：雜項錯誤csconvrabrelreq_oth

17、errrab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足psconvrabrelreq_resrab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤psconvrabrelreq_rerrrab釋放請求次數(shù)，原因：傳輸層錯誤psconvrabrelreq_l2errrab釋放請求次數(shù)，原因：協(xié)議錯誤psconvrabrelreq_perrrab釋放請求次數(shù)，原因：非接入層錯誤psconvrabrelreq_naserrrab釋放請求次數(shù)，原因：雜項錯誤psconvrabrelreq_otherr流程定時器超時指標：流程定時器超時可重點分析以下流程(主要分析請求與cmp次數(shù)，已經(jīng)相應超時次數(shù)統(tǒng)計指標)：rb_s

18、etuprb_recfgactive_set_updatephy_cfgrl failure指標：cell_updt_rl_fail_cell（下行失步）iub_rl_fail（上行失步）rtwp，tcp指標：rtwp均值、最大值tcp均值、最大值4. 檢查小區(qū)是否異常如果小區(qū)以前kpi正常，可檢查小區(qū)的告警，排除小區(qū)異常方面的原因。5. 分析掉話原因設備問題：按照2、3如果分析結果是傳輸、設備原因，則可歸類為設備問題。覆蓋差：按照2、3如果分析結果是空口原因，則可歸類為覆蓋差，無線環(huán)境變化塊等原因。切換導致的掉話：hho相關指標導致的掉話。干擾導致的掉話：分析rl failure、rtwp，

19、tcp相關指標，由于話統(tǒng)粒度粗，主要看整體情況，無法精確分析。從話統(tǒng)詳細分析掉話時，需按照掉話原因分類分析相關指標，必要時結合cdl分析。6. 通過路測重現(xiàn)問題由于話統(tǒng)給出了趨勢，并給出了可能的問題，具體問題的定位和分析還需要結合路測或者針對小區(qū)的cdl分析來進行。對于問題小區(qū)，一般都需要安排針對小區(qū)進行路測，跟蹤手機側和rnc的信令流程進行分析，詳細分析方法請參見路測數(shù)據(jù)分析流程。3.3 跟蹤數(shù)據(jù)分析流程跟蹤數(shù)據(jù)分析包括單用戶跟蹤消息分析，通常情況下，單用戶消息結合數(shù)據(jù)采集工具記錄的ue側數(shù)據(jù)，能夠基本上定位一些掉話問題；對于更加復雜的問題，需要配合cdl和實時狀態(tài)監(jiān)控來綜合分析。也有一些商

20、用手機的問題或者重點用戶的問題，沒有手機側記錄的消息，需要通過從單用戶跟蹤數(shù)據(jù)來分析和定位。單用戶跟蹤除了記錄單用戶的信令消息（iu，iur，iub，uu），同時需要記錄p-ccpch rscp、 c/i性能跟蹤，記錄ue的發(fā)射功率，記錄上行sir，sir target，記錄上行bler，記錄下行碼發(fā)射功率，如果是數(shù)據(jù)業(yè)務，還要進一步記錄上下行的業(yè)務量和吞吐量。圖 33 呼叫跟蹤分析流程1. 獲取單用戶跟蹤消息單用戶跟蹤消息需要事先在rnc上進行跟蹤，才能記錄相應的消息。根據(jù)imsi進行跟蹤記錄的消息用來分析掉話問題是足夠的。2. 獲取掉話點信息從單用戶跟蹤消息來看，掉話的定義是rnc主動發(fā)起

21、了rab釋放（消息名稱為ranap_rab_release_req），或者rnc主動發(fā)起iu釋放（消息名稱為ranap_iu_release_req）。前者對應為用戶面掉話，后者對應為信令面掉話。通過查找以上兩條消息，就可以或者掉話點的時間，以及掉話前的信令消息，以便進一步進行分析。3. 信令面掉話分析信令面掉話表現(xiàn)為手機或者rnc不能收到確認模式傳送的信令，產生srb復位，導致連接釋放。下行方向一般有這些消息手機不能收到而可能導致srb復位：安全模式過程，鑒權加密過程，測量控制，激活集更新，物理信道重配置，傳輸信道重配置，rb重配置以及3g到2g的切換命令（handover from utr

22、an command），手機是否收到這些命令需要手機側的跟蹤消息來確認；上行方向有以下的消息可能導致srb復位：測量報告，激活集更新完成，物理信道重配置完成，傳輸信道重配置完成，rb重配置完成，同樣需要rnc側的跟蹤消息來確認是否收到。4. 用戶面掉話分析用戶面掉話主要是trb復位，這種情況主要在ps業(yè)務上發(fā)生，voice和vp業(yè)務不會產生trb復位。一般可以通過確認掉話發(fā)生時的ue發(fā)射功率或者下行碼發(fā)射功率情況來輔助確認。當激活集中只有一條鏈路上，會由于rl failure導致rnc發(fā)起iu release， rl failure是上行失步引起的，但是下行失步會使ue關閉發(fā)射機，接著就造成上

23、行失步，在定位掉話是上行引起釋放還是下行引起的時候，需要分析掉話前手機的發(fā)射功率和實時狀態(tài)監(jiān)控的下行的碼發(fā)射功率來區(qū)分。下行覆蓋差、下行干擾強或者上行干擾都會導致trb復位。有時候數(shù)據(jù)業(yè)務由于重傳次數(shù)設置不合理，在切換來不及的情況下，trb比srb先產生復位，在分析時要注意區(qū)分。5. 異常掉話分析異常掉話一般指掉話無法從覆蓋、干擾等方面找到原因，也無法根據(jù)前面介紹的用戶面掉話或者信令面掉話原因來解釋，這種掉話往往是設備的異?；蛘呤鞘謾C的異常導致的。比如由于傳輸突然中斷導致的掉話、基站設備異常導致的掉話、手機突然死機等都會導致異常掉話。對于傳輸異常一般通過分析cdl或者參看告警來進一步分析；對于

24、基站設備異?？梢酝ㄟ^查詢基站狀態(tài)來確認，對于手機異常，需要通過分析手機記錄的數(shù)據(jù)來定位。6. 撥測，重現(xiàn)問題當已有的數(shù)據(jù)不足以定位掉話問題的時候，啟動更詳細的數(shù)據(jù)跟蹤，最好的辦法采用測試手機是在問題點進行撥測，重現(xiàn)問題，然后繼續(xù)進行分析。3.4 用戶投訴分析流程圖 34用戶投訴分析流程1. 了解用戶投訴用戶投訴發(fā)生的時候需要詳細記錄問題發(fā)生的時間，問題產生的地點，以及問題的具體現(xiàn)象。2. 檢查話統(tǒng)指標通過分析用戶投訴相關的話統(tǒng)指標，來進一步分析該投訴是某個用戶特有的問題還是網(wǎng)絡一般性的問題，對于一般性的問題，請參考話統(tǒng)指標的分析來進一步分析投訴。3. 檢查告警根據(jù)投訴的時間，查看cn，rnc或

25、者投訴地點對應基站的告警，看這些告警是否會產生相應的掉話，如果存在這個告警，試著消除和解決這個告警。4. 檢查cdlcdl記錄了用戶異常發(fā)生時候的信令，狀態(tài)等信息，通過分析cdl可以進一步了解投訴產生的原因。5. 投訴點撥測，重現(xiàn)問題對于話統(tǒng)分析，告警分析以及cdl分析都無法解決的問題，需要通過到現(xiàn)場撥測的方法進行問題重新，撥測的時候數(shù)據(jù)記錄的方法和路測方法相同，在某些場合，可能不適合記錄手機側信息，那么需要通過rnc來盡量多的記錄各種信息，特別需要記錄收集上報的c/i和rscp信息，以排除覆蓋問題導致的掉話。對于一些特別的地點，到現(xiàn)場撥測都不可能，那么需要通過用戶的手機號碼來獲取imsi，然

26、后在rnc啟動呼叫跟蹤，以便進一步定位問題。第4章 常見掉話原因分析4.1 覆蓋差td網(wǎng)絡覆蓋指標主要是p-ccpch的rscp、c/i。通常所說的覆蓋差，是指rscp小于100dbm。對覆蓋差問題進行分析是，通常要考慮上行覆蓋和下行覆蓋。上行覆蓋差還是下行覆蓋差的問題需要通過掉話前上行或者下行的專用信道功率來確認，需要采用以下的方法來確認：如果掉話前的上行發(fā)射功率達到最大值，并且上行的bler也很差或者從rnc記錄的單用戶跟蹤上看到nodeb上報rl failure，基本可以認為上行覆蓋差導致的掉話。如果掉話前，下行發(fā)射功率達到最大值，并且下行的bler很差，基本可以認為是下行覆蓋不行導致的

27、掉話。在合理的鏈路平衡情況下，而且上下行沒有干擾的情況下，上行和下行發(fā)射功率會同時受限，此時不一定要嚴格區(qū)分哪一方先出現(xiàn)受限。如果上下行嚴重不平衡，則應該初步判定為受限方向存在干擾。確認覆蓋的問題簡單直接的方式是直接觀察scanner采集的數(shù)據(jù)，若最好小區(qū)的rscp和c/i都很低，就可以認為是覆蓋問題。由于缺站、扇區(qū)接錯、功放故障導致站關閉等原因都會導致覆蓋差，在一些室內，由于過大的穿透損耗也會導致覆蓋太差，扇區(qū)接錯或者站點由于故障原因關閉等容易在優(yōu)化過程中出現(xiàn)，表現(xiàn)為其他小區(qū)在掉話點的覆蓋差，需要注意分析區(qū)別。4.2 鄰區(qū)漏配一般來講，初期優(yōu)化過程掉話占大多數(shù)是由于鄰區(qū)漏配導致的。對于同頻鄰

28、區(qū)，通常采用以下的辦法來確認是否為同頻鄰區(qū)漏配：方法一：觀察掉話前ue記錄的激活集c/i信息和scanner記錄的best server c/i信息，如果ue記錄的c/i很差，而scanner記錄的best server c/i很好；同時檢查scanner記錄best server擾碼是否出現(xiàn)在掉話前最近出現(xiàn)的同頻測量控制的鄰區(qū)列表中，如果測量控制的鄰區(qū)列表中中沒有擾碼，那么可以確認是鄰區(qū)漏配。方法二：如果掉話后ue馬上重新接入，如果ue重新接入的小區(qū)擾碼和掉話時的擾碼不一致，也可以懷疑是鄰區(qū)漏配問題，可以通過測量控制進一步進行確認（從掉話位置的消息開始往前找，找到最近一條同頻測量控制消息，檢

29、查該測量控制消息的鄰區(qū)列表）。方法三：有些ue會上報檢測集（detected set ）信息，如果掉話發(fā)生前檢測集信息中有相應的擾碼信息，也可以確認是鄰區(qū)漏配的問題。鄰區(qū)漏配導致的掉話也包括異頻鄰區(qū)漏配和異系統(tǒng)鄰區(qū)漏配。異頻鄰區(qū)漏配的確認方法和同頻幾乎相同，主要是掉話發(fā)生的時候，手機沒有測量或者上報異頻鄰區(qū)，而手機掉話后重新駐留到異頻鄰區(qū)上。異系統(tǒng)鄰區(qū)漏配表現(xiàn)為手機在3g掉話，掉話后手機重新選網(wǎng)駐留到2g網(wǎng)絡，從信號質量來看，2g網(wǎng)絡的質量很好（在掉話點用2g測試手機觀察rssi信號）。4.3 切換掉話切換導致掉話主要有兩類原因：切換來不及或者乒乓切換。從信令流程上cs業(yè)務表現(xiàn)為手機收不到激活

30、集更新命令（物理信道重配置），ps業(yè)務也有可能收不到激活集更新命令，也有可能在切換之前先發(fā)生trb復位。從信號上看，切換來不及主要有以下現(xiàn)象：1）拐角：源小區(qū)c/i陡降，目標小區(qū)c/i陡升（即突然出現(xiàn)就是很高的值）；2）針尖：源小區(qū)c/i快速下降后一段時間后上升，目標小區(qū)出現(xiàn)短時間的陡升。從信令流程上看，一般在掉話前手機上報了鄰區(qū)的1g或者2a測量報告，rnc也收到了測量報告，并下發(fā)了激活集更新消息，但ue收不到激活集更新消息。乒乓切換主要有以下兩種現(xiàn)象：1）主導小區(qū)變化快：2個或者多個小區(qū)交替成為主導小區(qū)，主導小區(qū)具有較好的rscp和c/i每個小區(qū)成為主導小區(qū)的時間很短；2）無主導小區(qū)：存在

31、多個小區(qū)，rscp正常而且相互之間差別不大，每個小區(qū)的c/i都很差。從信令流程上看，一般可以看到1個小區(qū)剛剛刪除，然后馬上要求加入，此時收不到rnc下發(fā)的激活集更新命令導致失敗。解決切換來不及導致的掉話，可以通過調整天線擴大切換區(qū)，也可以配置1g事件的切換參數(shù)使切換更容易發(fā)生，或者配置offset使目標小區(qū)能夠提前發(fā)生切換；解決乒乓切換帶來的掉話問題，可以調整天線使覆蓋區(qū)域形成主導小區(qū)，也可以配置1g事件的切換參數(shù)減少乒乓的發(fā)生等方法來進行。對于異頻切換和系統(tǒng)間切換，在切換前需要進行異頻或者異系統(tǒng)測量，測量啟動太遲，可能導致手機來不及測量目標小區(qū)的信號，從而產生掉話，也可能手機完成了測量，但下

32、發(fā)的異頻或者異系統(tǒng)切換請求手機不能正常接收而導致掉話。對于3g 2g系統(tǒng)間切換掉話的常見原因大概如下：鄰區(qū)漏配置，可以通過配置鄰區(qū)解決；信號變化太快導致掉話；手機問題，比如ue回切換失敗或者ue沒有上報異系統(tǒng)測量報告導致掉話等；物理信道重配置時發(fā)生最優(yōu)小區(qū)發(fā)生變更導致掉話，需要產品算法進行優(yōu)化；異系統(tǒng)小區(qū)配置過多導致掉話，可以通過優(yōu)化鄰區(qū)數(shù)目解決；lac區(qū)配置錯誤導致的掉話，可以通過數(shù)據(jù)配置檢查解決。4.4 干擾掉話下行和上行的干擾都會導致掉話。一般情況下，對于下行，當激活集p-ccpch rscp大于-85db，而激活集綜合c/i小于-9db產生了掉話，基本上可以認為是下行干擾的問題（當切換

33、不及時的時候，也可能出現(xiàn)服務小區(qū)rscp信號很好，但c/i很差；但此時監(jiān)測集小區(qū)rscp和c/i都很好）；對于上行rtwp比正常值（-107-105）超過10db，干擾時間超過23s，就有可能造成掉話，需要重點解決。下行的干擾通常是指導頻污染，指覆蓋地區(qū)存在3個以上的小區(qū)滿足切換條件，由于信號的波動常常出現(xiàn)激活集替換或者最優(yōu)小區(qū)發(fā)生變化，通常當激活集綜合質量不好（p-ccpch的c/i都在-3db左右波動），容易出現(xiàn)切換失敗導致srb復位，也可能出現(xiàn)trb復位。上行的干擾增加了連接模式的手機上行發(fā)射功率，從而產生過高的bler導致srb或者trb復位或者由于失步導致掉話。另外，在切換的時候，新

34、建鏈路由于上行干擾問題導致鏈路不能同步，從而造成該小區(qū)的切換成功率低，或者造成切換失敗而導致掉話。通常在沒有干擾的情況下，上下行是平衡的，也就是說掉話前上下行的發(fā)射功率都會接近最大值。但當干擾存在時，如果是下行的干擾，往往出現(xiàn)上行發(fā)射功率很小或者bler收斂的情況，但下行發(fā)射功率達到最大值同時也伴隨著下行bler不收斂；對于上行干擾，會存在同樣的表現(xiàn)，在實際分析可以通過這個方法來區(qū)分。4.5 流程交互失敗一些需要信令交互的流程，如amr控制、ue的狀態(tài)遷移等，常常會由于信號的原因，手機支持方面的原因或者ran設備和手機的配合問題，導致流程失敗，最后導致掉話。還有一種特殊情況就是在流程的交互過程

35、中，如rb建立，rb重配置等流程中，切換的測量報告不能及時處理，導致信號變差而掉話。這類問題需要針對特定的流程和手機進行分析，沒有一般性的處理方法。4.6 異常在排除了以上的原因之后，其他的掉話一般需要懷疑設備的問題，需要通過查看設備的日志，告警等進一步來分析掉話原因。比如：nodeb異常引起同步失敗，導致的鏈路不停增加和刪除,手機不上報1g測量報告導致掉話.這里需要重點注意的是測試手機異常死機引起的掉話問題，一般在撥測過程中容易出現(xiàn)這個問題，具體表現(xiàn)為路測記錄的數(shù)據(jù)中有一段時間沒有手機上報的信息。4.7 調整措施4.7.1 工程參數(shù)工程參數(shù)的調整可以調整站點的位置、天線的高度、下傾角、天線的波瓣寬度、天線增益以及方向角等。對于上行或下行覆蓋問題導致的掉話，增加站點是最好的辦法，同時可以考慮更改天線的高度、下傾角，也可以更換增益更高的天線或者增加塔放。對于針尖和拐角效應，通過天線調整也是比較有效的解決辦法，由于針尖效應和拐角效應往往出現(xiàn)在街道拐彎的地方或者兩條街道交界的地方，可以考慮通過天線的方向角和街道錯開一定的角度的方式來調整，但同時需要注意原來街道路邊商鋪的覆蓋不要有很大的影響。對于導頻干擾引起的覆蓋問題，可以通過調整某一個天線的工程參數(shù)，使該天線在干擾位置成為主導