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

知識水壩（豆丁網(wǎng) pologoogle）為您傾心整理（下載后雙擊刪除） 百度一下 知識水壩 TD-SCDMA 掉話問題分析 優(yōu)化指導手冊 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 目錄 - 1 - ostcom_B2000 產(chǎn)品配置手冊 - 2 - ostcom_B2000 產(chǎn)品配置手冊 - 3 - 內(nèi)容介紹 TD-SCDMA網(wǎng)絡優(yōu)化 掉話問題分析 介紹了 TD-SCDMA網(wǎng)絡優(yōu)化中的掉話問題進行分析，包括掉話定義，分析流程和方法，常見掉話原因和典型掉話案例分析。本文分 5章。 概述。 掉話定義：介紹路測和話統(tǒng)中掉話定義。 掉話分析流程和方法 :詳細介紹掉話分析的流程和分析方法。 常見掉話原因分析：介紹覆蓋、鄰區(qū)關系、切換、干擾等造成掉話的原因及分析的方法。 典型掉話案例分析：結合廣州 TD網(wǎng)絡優(yōu)化案例進行分析。 讀 者對象 本書適合下列人員閱讀： 參與網(wǎng)絡優(yōu)化的相關人員 。 目 錄 優(yōu)化指導手冊 . 1-1 前言 .錯誤 !未定義書簽。 內(nèi)容介紹 . - 3 - 讀者對象 . - 3 - 本書約定 . 錯誤 !未定義書簽。 目 錄 .- 3 - 第 1 章 概述 . 1-1 第 2 章 掉話定義 . 2-1 2.1 路測的掉話定義 . 2-1 2.2 話 統(tǒng)指標中的掉話定義 . 2-1 第 3 章 掉話分析流程和方法 . 3-1 3.1 路測數(shù)據(jù)分析流程 . 3-1 3.2 話統(tǒng)數(shù)據(jù)分析流程 . 3-3 ostcom_B2000 產(chǎn)品配置手冊 - 4 - 3.3 跟蹤數(shù)據(jù)分析流程 . 3-7 3.4 用戶投訴分析流程 . 3-10 第 4 章 常見掉話原因分析 . 4-1 4.1 覆蓋差 . 4-1 4.2 鄰區(qū)漏配 . 4-1 4.3 切換掉話 . 4-2 4.4 干擾掉話 . 4-2 4.5 流程交互失敗 . 4-3 4.6 異常 . 4-3 4.7 調(diào)整措施 . 4-3 4.7.1 工程參數(shù) .4-3 4.7.2 小區(qū)參數(shù) .4-3 第 5 章 典型掉話案例分析 . 5-1 5.1 鄰區(qū)漏配 . 5-1 5.2 乒乓切換 . 5-2 5.3 弱覆蓋 . 5-3 附錄 A:縮略語 .1 附錄 B：文檔修訂記錄 .2 圖 3-1掉話分析流程樹 . 3-1 圖 3-2 掉話原因判斷 . 3-2 圖 3-3 呼叫跟蹤分析流程 . 3-8 圖 3-4用戶投訴分析流程 . 3-10 圖 5-1鄰區(qū)漏配調(diào)整前 . 5-1 圖 5-2鄰區(qū)漏配調(diào)整后 . 5-1 圖 5-3乒乓切換調(diào)整前 . 5-2 圖 5-4乒乓切換調(diào)整后 . 5-2 圖 5-5弱覆蓋調(diào)整前 . 5-3 圖 5-6弱覆蓋調(diào)整 . 5-3 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 1 章 概述 1-1 第 1章 概述 在網(wǎng)絡建設及運營中，掉話率（ calldroprate）是反映網(wǎng)絡 質(zhì)量的重要指標之一；掉話問題也是日常網(wǎng)絡優(yōu)化面臨的一個常見問題。掉話問題對用戶的負面影響最直接，因此掉話率是運營商最為關注的指標之一。實際的網(wǎng)絡中，影響掉話率的因素很多，包括硬件問題、干擾問題、覆蓋問題、切換問題、參數(shù)問題等。本文結合廣州 TD網(wǎng)絡建設和優(yōu)化的經(jīng)驗，對掉話的定義、分析流程和方法、原因分析等內(nèi)容進行描述。 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 2 章 掉話定義 2-1 第 2章 掉話定義 2.1 路測的掉話定義 從 UE側(cè)記錄的空口信令上看，在通話過程（連接狀態(tài)下）中，如果空口的消息，滿足以下三個條件的任何一個： 1） 收到任何的 BCH消息（即系統(tǒng)消息） 2） 收到 RRC Release消息且釋放的原因值為 Not Normal 3） 收到 CC Disconnect， CC Release Complete， CC Release三條消息中的任何一條，而且釋放的原因為 Not Normal Clearing或者 Not Normal， Unspecified。 2.2 話統(tǒng)指標中的掉話定義 廣義的掉話率應該包含 CN和 UTRAN的掉話率，由于網(wǎng)優(yōu)重點關注與 UTRAN側(cè)的掉話率指標，本文掉話率描述也重點關注 UTRAN側(cè)的 KPI指標分析。 UTRAN側(cè)相關指標就是 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 release 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ū)分 。 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-1 第 3章 掉話分析流程和方法 3.1 路測數(shù)據(jù)分析流程 準 備 數(shù) 據(jù)獲 取 掉 話 時間 和 位 置鄰 區(qū) 露 配覆 蓋 分 析切 換 分 析干 擾 分 析異 常 分 析重 新 路 測重 現(xiàn) 問 題XYYYYYNNNNN圖 3-1掉話分析流程樹 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-2 準 備 數(shù) 據(jù) U E和S c a n n e r最 好 小 區(qū) 比 較穩(wěn) 定 一 致 N獲 取 掉 話 位 置 和 時 間 分 析 S c a n n e r主 導 小區(qū) 信 號 變 化 R S C P 差 C / I 差 R S C P 正 常 C / I 差 R S C P 正 常 C / I 正 常 鄰 區(qū) 漏 配 上 行 干 擾 問題切 換 不 及 時 確 認 漏 配 鄰 區(qū) ？ 覆 蓋 問 題 異 常 掉 話 導 頻 干 擾 問題 不 一 致 確 認 上 行 干 擾 ？ 問 題 是 否 解 決 重 新 路 測Y主 導 小 區(qū) 信 號穩(wěn) 定 ？ S c a n n e r 最 優(yōu) 小 區(qū)R S C P 和 C / I乒 乓 切 換 問題 變 化 頻 繁YN圖 3-2 掉話原因判斷 準備數(shù)據(jù) 路測軟件采集數(shù)據(jù)文件 RNC記錄的單用戶跟蹤 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-3 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ù)不同的情況分別處理 RSCP差， 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ù)分析流程 分析話統(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看掉話的原因。實際分析解決 等 問題時，在重點抓住某個指標分析的同時需要結合其他指標一起分析。 需要說明的是話統(tǒng)只有在統(tǒng)計量較大時，指標數(shù)值才具有指導意義。例如，出現(xiàn)掉話率為50%并不就代表網(wǎng)絡差，只有在呼叫次數(shù)、呼叫成功次數(shù)、掉話總次數(shù)的絕對值都已具備統(tǒng)計意義時，這個數(shù)值才具有意義 話統(tǒng)分析流程可以簡述如下： TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-4 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 COMMAND。信令面掉話主要是 RNC發(fā)起了 Iu Release Request。分析 IU口連接釋放情況得到信令面掉話率。 2. 分析掉話原因 在話統(tǒng)分析中還分析引起掉話的主要原因，可分析以下主要指標： Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足 CSConvRabRelReq_Res Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤 CSConvRabRelReq_RErr Rab釋放請求次數(shù)，原因：傳輸層錯誤 CSConvRabRelReq_L2Err Rab釋放請求次數(shù)，原因：協(xié)議錯誤 CSConvRabRelReq_PErr Rab釋放請求次數(shù)，原因：非接入層錯誤 CSConvRabRelReq_NASErr Rab釋放請求次數(shù)，原因：雜項錯誤 CSConvRabRelReq_OthErr Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足 PSConvRabRelReq_Res Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤 PSConvRabRelReq_RErr Rab釋放請求次數(shù)，原因：傳輸層錯誤 PSConvRabRelReq_L2Err Rab釋放請求次數(shù)，原因：協(xié)議錯誤 PSConvRabRelReq_PErr Rab釋放請求次數(shù)，原因：非接入層錯誤 PSConvRabRelReq_NASErr Rab釋放請求次數(shù)，原因：雜項錯誤 PSConvRabRelReq_OthErr 類似還有 interactive、 streaming、 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數(shù)目 RNCTD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-5 率 域 RAB指派建立成功的 RAB數(shù)目 *100% 請求釋放的分組域 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_CELL_TRIG_BY_RNC RNC_PS_128K_RAB_REL_CELL_TRIG_BY_RNC RNC_PS_64K_RAB_REL_CELL_TRIG_BY_RNC 切換掉話率情況： HHO_INTERFEQ_DROP_OUT_CELL / HHO_INTERFEQ_OUT_CELL HHO_INTERFEQ_DROP_IN_CELL / HHO_INTERFEQ_IN_CELL HHO_INTRAFEQ_DROP_OUT_CELL/ HHO_INTRAFEQ_OUT_CELL HHO_INTRAFEQ_DROP_IN_CELL/ HHO_INTRAFEQ_IN_CELL 通過上述這些掉話率的分析，我們可獲得不同業(yè)務及其速率在網(wǎng)絡中的性能，可獲得切換掉話情況。重要的是通過這一步可獲得指標較差的小區(qū)以及時間段。 釋放原因指標： Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足 CSConvRabRelReq_Res Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤 CSConvRabRelReq_RErr Rab釋放請求次數(shù)，原因：傳輸層錯誤 CSConvRabRelReq_L2Err Rab釋放請求次數(shù)，原因：協(xié)議錯誤 CSConvRabRelReq_PErr Rab釋放請求次數(shù)，原因：非接入層錯 CSConvRabRelReq_NASErr TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-6 誤 Rab釋放請求次數(shù)，原因：雜項錯誤 CSConvRabRelReq_OthErr Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層資源不足 PSConvRabRelReq_Res Rab釋放請求次數(shù)，原因：無線網(wǎng)絡層其他錯誤 PSConvRabRelReq_RErr Rab釋放請求次數(shù)，原因：傳輸層錯誤 PSConvRabRelReq_L2Err Rab釋放請求次數(shù)，原因：協(xié)議錯誤 PSConvRabRelReq_PErr Rab釋放請求次數(shù)，原因：非接入層錯誤 PSConvRabRelReq_NASErr Rab釋放請求次數(shù)，原因：雜項錯誤 PSConvRabRelReq_OthErr 流程定時器超時指標： 流程定時器超時可重點分析以下流程 (主要分析請求與 CMP次數(shù)，已經(jīng)相應超時次數(shù)統(tǒng)計指標 )： RB_SETUP RB_RECFG ACTIVE_SET_UPDATE PHY_CFG RL 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相關指標導致的掉話。 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-7 干擾導致的掉話：分析 RL Failure、 RTWP， TCP相關指標，由于話統(tǒng)粒度粗，主要看整體情況，無法精確分析。 從話統(tǒng)詳細分析掉話時，需按照掉話原因分類分析相關指標，必要時結合 CDL分析。 6. 通過路測重現(xiàn)問題 由于話統(tǒng)給出了趨勢，并給出了可能的問題，具體問題的定位和分析還需要結合路測或者針對小區(qū)的 CDL 分析來進行。對于問題小區(qū)，一般都需要安排針對小區(qū)進行路測，跟蹤手機側(cè)和 RNC 的信令流程進行分析，詳細分析方法請參見路測數(shù)據(jù)分析流程。 3.3 跟蹤數(shù)據(jù)分析流程 跟蹤數(shù)據(jù)分析包括單用戶跟蹤消息分析，通常情況下，單用戶消息結合數(shù)據(jù)采集工具記錄的 UE側(cè)數(shù)據(jù)，能夠基本上定位 一些掉話問題；對于更加復雜的問題，需要配合 CDL和實時狀態(tài)監(jiān)控來綜合分析。 也有一些商用手機的問題或者重點用戶的問題，沒有手機側(cè)記錄的消息，需要通過從單用戶跟蹤數(shù)據(jù)來分析和定位。單用戶跟蹤除了記錄單用戶的信令消息（ Iu， Iur， Iub， Uu），同時需要記錄 P-CCPCH RSCP、 C/I性能跟蹤，記錄 UE的發(fā)射功率，記錄上行 SIR， SIR Target，記錄上行 BLER，記錄下行碼發(fā)射功率，如果是數(shù)據(jù)業(yè)務，還要進一步記錄上下行的業(yè)務量和吞吐量。 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-8 獲 取 單 用 戶 跟蹤 消 息獲 取 掉 話 點 信息信 令 面 掉 話？用 戶 面 掉 話？異 常 掉 話 ？掉 話 問 題 解決 ？撥 測 ， 重 現(xiàn) 問題解 決 信 令 面 掉話解 決 用 戶 面 掉話解 決 異 常 掉 話YYYYNNNN圖 3-3 呼叫跟蹤分析流程 1. 獲取單用戶跟蹤消息 單用戶跟蹤消息需要事先在 RNC上進行跟蹤，才能記錄相應的消息。根據(jù) IMSI進行跟蹤記錄的消息用來分析掉話問題是足夠的。 2. 獲取掉話點信息 從單用戶跟蹤消息來看， 掉話的定義是 RNC主動發(fā)起了 RAB釋放（消息名稱為RANAP_RAB_RELEASE_REQ），或者 RNC主動發(fā)起 IU釋放（消息名稱為 RANAP_IU_RELEASE_REQ） 。前者對應為用戶面掉話，后者對應為信令面 掉話。通過查找以上兩條消息，就可以或者掉話點的時間，以及掉話前的信令消息，以便進一步進行分析。 3. 信令面掉話分析 信令面掉話表現(xiàn)為手機或者 RNC不能收到確認模式傳送的信令，產(chǎn)生 SRB復位 ，導致連接釋放。下行方向一般有這些消息手機不能收到而可能導致 SRB復位：安全模式過程，鑒權加密TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-9 過程，測量控制，激活集更新，物理信道重配置，傳輸信道重配置， RB重配置以及 3G到 2G的切換命令（ HANDOVER FROM UTRAN COMMAND），手機是否收到這些命令需要手機側(cè)的跟蹤消息來確認；上行方向有以下的消息可能導致 SRB復位：測量報告，激活集更新完成，物理信道重配置完成，傳輸信道重配置完成， RB重配置完成，同樣需要 RNC側(cè)的跟蹤消息來確認是否收到。 4. 用戶面掉話分析 用戶面掉話主要是 TRB復位，這種情況主要在 PS業(yè)務上發(fā)生 ， voice和 VP業(yè)務不會產(chǎn)生 TRB復位。一般可以通過確認掉話發(fā)生時的 UE發(fā)射功率或者下行碼發(fā)射功率情況來輔助確認。 當激活集中只有一條鏈路上，會由于 RL failure導致 RNC發(fā)起 Iu Release， RL failure是上行失步引起的，但是下行失步會使 UE關閉發(fā)射機，接著就造成上行失步，在定位掉 話是上行引起釋放還是下行引起的時候，需要分析掉話前手機的發(fā)射功率和實時狀態(tài)監(jiān)控的下行的碼發(fā)射功率來區(qū)分。 下行覆蓋差、下行干擾強或者上行干擾都會導致 TRB復位。有時候數(shù)據(jù)業(yè)務由于重傳次數(shù)設置不合理，在切換來不及的情況下， TRB比 SRB先產(chǎn)生復位，在分析時要注意區(qū)分。 5. 異常掉話分析 異常掉話一般指掉話無法從覆蓋、干擾等方面找到原因，也無法根據(jù)前面介紹的用戶面掉話或者信令面掉話原因來解釋，這種掉話往往是設備的異?；蛘呤鞘謾C的異常導致的。比如由于傳輸突然中斷導致的掉話、基站設備異常導致的掉話、手機突然死機等都會導 致異常掉話。對于傳輸異常一般通過分析 CDL或者參看告警來進一步分析；對于基站設備異?？梢酝ㄟ^查詢基站狀態(tài)來確認，對于手機異常，需要通過分析手機記錄的數(shù)據(jù)來定位。 6. 撥測，重現(xiàn)問題 當已有的數(shù)據(jù)不足以定位掉話問題的時候，啟動更詳細的數(shù)據(jù)跟蹤，最好的辦法采用測試手機是在問題點進行撥測，重現(xiàn)問題，然后繼續(xù)進行分析。 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-10 3.4 用戶投訴分析流程 了 解 用 戶 投訴檢 查 話 統(tǒng) 指標檢 查 告 警檢 查 C D L投 訴 問 題解 決撥 測 ， 重 現(xiàn)問 題YN圖 3-4用戶投訴分析流程 1. 了解用戶投 訴 用戶投訴發(fā)生的時候需要詳細記錄問題發(fā)生的時間，問題產(chǎn)生的地點，以及問題的具體現(xiàn)象。 2. 檢查話統(tǒng)指標 通過分析用戶投訴相關的話統(tǒng)指標，來進一步分析該投訴是某個用戶特有的問題還是網(wǎng)絡一般性的問題，對于一般性的問題，請參考話統(tǒng)指標的分析來進一步分析投訴。 3. 檢查告警 根據(jù)投訴的時間，查看 CN， RNC或者投訴地點對應基站的告警，看這些告警是否會產(chǎn)生相應的掉話，如果存在這個告警，試著消除和解決這個告警。 4. 檢查 CDL CDL記錄了用戶異常發(fā)生時候的信令，狀態(tài)等信息，通過分析 CDL可以進一步了解投訴產(chǎn)生的原因。 5. 投訴點撥 測，重現(xiàn)問題 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 3 章 掉話分析流程和方法 3-11 對于話統(tǒng)分析，告警分析以及 CDL分析都無法解決的問題，需要通過到現(xiàn)場撥測的方法進行問題重新，撥測的時候數(shù)據(jù)記錄的方法和路測方法相同，在某些場合，可能不適合記錄手機側(cè)信息，那么需要通過 RNC來盡量多的記錄各種信息，特別需要記錄收集上報的 C/I和RSCP信息，以排除覆蓋問題導致的掉話。對于一些特別的地點，到現(xiàn)場撥測都不可能，那么需要通過用戶的手機號碼來獲取 IMSI，然后在 RNC啟動呼叫跟蹤，以便進一步定位問題。 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 4 章 常見掉話原因分析 4-1 第 4章 常見掉話原因分析 4.1 覆蓋差 TD 網(wǎng)絡覆蓋指標主要是 P-CCPCH 的 RSCP、 C/I。 通常所說的覆蓋差，是指 RSCP 小于100dBm。 對覆蓋差問題進行分析是，通常要考慮上行覆蓋和下行覆蓋。上行覆蓋差還是下行覆蓋差的問題需要通過掉話前上行或者下行的專用信道功率來確認，需要采用以下的方法來確認： 如果掉話前的上行發(fā)射功率達到最大值，并且上行的 BLER也很差或者從 RNC記錄的單用戶跟蹤上看到 NodeB上報 RL failure，基本可以認為上行覆蓋差導致的掉話。 如果掉話前，下行發(fā)射功率達到最大值，并且下行的 BLER 很差，基本可以認為是下行覆蓋不行導致的掉話。 在合理的鏈路平衡情況下，而且上下行 沒有干擾的情況下，上行和下行發(fā)射功率會同時受限，此時不一定要嚴格區(qū)分哪一方先出現(xiàn)受限。如果上下行嚴重不平衡，則應該初步判定為受限方向存在干擾。 確認覆蓋的問題簡單直接的方式是直接觀察 Scanner采集的數(shù)據(jù)，若最好小區(qū)的 RSCP和C/I都很低，就可以認為是覆蓋問題。 由于缺站、扇區(qū)接錯、功放故障導致站關閉等原因都會導致覆蓋差，在一些室內(nèi)，由于過大的穿透損耗也會導致覆蓋太差，扇區(qū)接錯或者站點由于故障原因關閉等容易在優(yōu)化過程中出現(xiàn)，表現(xiàn)為其他小區(qū)在掉話點的覆蓋差，需要注意分析區(qū)別。 4.2 鄰區(qū)漏配 一般來講，初期優(yōu)化 過程掉話占大多數(shù)是由于鄰區(qū)漏配導致的。對于同頻鄰區(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ū)漏配問題，可以通過測量控制進一步進行確認（從掉話位置的消息開始往前找，找到最近一條同頻測量控制消息，檢查該測量控制消息的鄰區(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)絡，從信號質(zhì)量來看， 2G網(wǎng)絡的質(zhì)量很好（在掉話點用 2G測試手機觀察 RSSI信號）。 TD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 4 章 常見掉話原因分析 4-2 4.3 切換掉話 切換導致掉話主要有兩類原因：切換來不及或者乒乓切換。 從信令流程上 CS 業(yè)務表現(xiàn)為手機收不到激活集更新命令（物理信道重配置）， 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ū)：存在多個小區(qū)， RSCP正常而且相互之間差別不大，每個小區(qū)的 C/I都很差。 從信令流程上看，一般可以看到 1個小區(qū)剛剛刪除，然后馬上要求加入，此時收不到 RNC下發(fā)的激活集更新命令導致 失敗。 解決切換來不及導致的掉話，可以通過調(diào)整天線擴大切換區(qū)，也可以配置 1g事件的切換參數(shù)使切換更容易發(fā)生，或者配置 Offset使目標小區(qū)能夠提前發(fā)生切換 ； 解決乒乓切換帶來的掉話問題，可以調(diào)整天線使覆蓋區(qū)域形成主導小區(qū)，也可以配置 1g事件的切換參數(shù)減少乒乓的發(fā)生等方法來進行。 對于異頻切換和系統(tǒng)間切換，在切換前需要進行異頻或者異系統(tǒng)測量，測量啟動太遲，可能導致手機來不及測量目標小區(qū)的信號，從而產(chǎn)生掉話，也可能手機完成了測量，但下發(fā)的異頻或者異系統(tǒng)切換請求手機不能正常接收而導致掉話。 對于 3G 2G系統(tǒng)間切換 掉話的常見原因大概如下： 鄰區(qū)漏配置，可以通過配置鄰區(qū)解決； 信號變化太快導致掉話； 手機問題，比如 UE回切換失敗或者 UE沒有上報異系統(tǒng)測量報告導致掉話等； 物理信道重配置時發(fā)生最優(yōu)小區(qū)發(fā)生變更導致掉話，需要產(chǎn)品算法進行優(yōu)化； 異系統(tǒng)小區(qū)配置過多導致掉話，可以通過優(yōu)化鄰區(qū)數(shù)目解決； LAC區(qū)配置錯誤導致的掉話，可以通過數(shù)據(jù)配置檢查解決。 4.4 干擾掉話 下行和上行的干擾都會導致掉話。一般情況下，對于下行，當激活集 P-CCPCH RSCP大于-85dB，而激活集綜合 C/I 小于 -9dB 產(chǎn)生了掉話，基本上可以認為是下 行干擾的問題（當切換不及時的時候，也可能出現(xiàn)服務小區(qū) RSCP信號很好，但 C/I很差；但此時 監(jiān)測集 小區(qū) RSCP和C/I 都很好）；對于上行 RTWP 比正常值（ -107 -105）超過 10dB，干擾時間超過 2 3s，就有可能造成掉話，需要重點解決。 下行的干擾通常是指導頻污染 ，指覆蓋地區(qū)存在 3個以上的小區(qū)滿足切換條件，由于信號的波動常常出現(xiàn)激活集替換或者最優(yōu)小區(qū)發(fā)生變化，通常當激活集綜合質(zhì)量不好（ P-CCPCH 的C/I都在 -3dB左右波動），容易出現(xiàn)切換失敗導致 SRB復位，也可能出現(xiàn) TRB復位。 上行的干擾增加了連 接模式的手機上行發(fā)射功率，從而產(chǎn)生過高的 BLER導致 SRB或者 TRBTD-SCDMA 網(wǎng)絡優(yōu)化 掉話問題分析 第 4 章 常見掉話原因分析 4-3 復位或者由于失步導致掉話。另外，在切換的時候，新建鏈路由于上行干擾問題導致鏈路不能同步，從而造成該小區(qū)的切換成功率低，或者造成切換失敗而導致掉話。 通常在沒有干擾的情況下，上下行是平衡的，也就是說掉話前上下行的發(fā)射功率都會接近最大值。但當干擾存在時，如果是下行的干擾，往往出現(xiàn)上行發(fā)射功率很小或者 BLER收斂的情況，但下行發(fā)射功率達到最大值同時也伴隨著下行 BLER不收斂；對于上行干擾，會存在同樣的表現(xiàn)，在實際分析可以通過這個方法來區(qū)分。 4.5 流程 交互失敗 一些需要信令交互的流程，如 AMR 控制 、 UE 的狀態(tài)遷移等，常常會由于信號的原因，手機支持方面的原因或者 RAN 設備和手機的配合問題，導致流程失敗，最后導致掉話。還有一種特殊情況就是在流程的交互過程中，如 RB 建立， RB 重配置等流程中，切換的測量報告不能及時處理，導致信號變差而掉話。 這類問題需要針對特定的流程和手機進行分析，沒有一般性的處理方法。 4.6 異常 在排除了以上的原因之后，其他的掉話一般需要懷疑設備的問題，需要通過查看設備的日志，告警等進一步來分析掉話原因。比如： NodeB 異常引起同步失敗，導致的鏈 路不停增加和刪除 ,手機不上報 1g 測量報告導致掉話 .這里需要重點注意的是測試手機異常死機引起的掉話問題，一般在撥測過程中容易出現(xiàn)這個問題，具體表現(xiàn)為路測記錄的數(shù)據(jù)中有一段時間沒有手機上報的信息。 4.7 調(diào)整措施 4.7.1 工程參數(shù) 工程參數(shù)的調(diào)整可以調(diào)整站點的位置、天線的高度、下傾角、天線的波瓣寬度、天線增益以及方向角等。 對于上行或下行覆蓋問題導致的掉話，增加站點是最好的辦法，同時可以考慮更改天線的高度、下傾角，也可以更換增益更高的天線或者增加塔放。 對于針尖和拐角效應，通過天線調(diào)整也是比較有效的解決辦法，由于針尖效應和拐 角效應往往出現(xiàn)在街道拐彎的地方或者兩條街道交界的地方，可以考慮通過天線的方向角和街道錯開一定的角度的方式來調(diào)整，但同時需要注意原來街道路邊商鋪的覆蓋不要有很大的影響。 對于導頻干擾引起的覆蓋問題，可以通過調(diào)整某一個天線的工程參數(shù)，使該天線在干擾位置成為主導小區(qū)；也可以通過調(diào)整其他幾個天線參數(shù)，減小