【文章內(nèi)容簡介】 PS業(yè)務(wù)建立成功后 ， RNC向 CN PS發(fā)送 RAB R ELEASE REQUEST消息 ， 釋放原因為 “ OM Intervention”。 PS業(yè)務(wù)建立成功后 ， RNC向 CN PS發(fā)送 IU RELEASE REQUEST消息 ， 釋放原因為 “ OM Intervention”,其后 CN發(fā)送釋放原因 Rel ease due to UTRAN Generated Reason的 IU RELEASE COMMAND。 RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_UTRAN 含義： 統(tǒng)計每個小區(qū)上 UTRAN產(chǎn)生的原因引起 RNC觸發(fā)釋放的 PS域 RAB數(shù)目 測量點： PS業(yè)務(wù)建立成功后 ， RNC向 CN PS發(fā)送 RAB R ELEASE REQUEST消息 ， 釋放原因為 “ UTRAN Generated Reason”。 PS業(yè)務(wù)建立成功后 ， RNC向 CN PS發(fā)送 IU RELEASE REQUEST消息 ， 釋放原因為 “ UTRAN Generated Reason”,其后 CN發(fā)送釋放原因 Release due to UTRAN Generated Reason的 IU RELEASE COMMAND。 RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_RAB_PREM 含義： 統(tǒng)計每個小區(qū)上 RAB搶占引起 RNC觸發(fā)釋放的 PS域 RAB數(shù)目 測量點： PS業(yè)務(wù)建立成功后 ， RNC向 CN PS發(fā)送 RAB R ELEASE REQUEST消息 ， 釋放原因為 “ RAB preemption”。 PS業(yè)務(wù)建立成功后 ， RNC向 CN PS發(fā)送 IU RELEASE REQUEST消息 ， 釋放原因為 “ RAB preemption”,其后 CN發(fā)送釋放原因 “ Release due to UTRAN Generated Reason”的 IU RELEASE COMMAND。 RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_SRBRESET 含義： 統(tǒng)計每個小區(qū)上 RNC由于信令 RLC復(fù)位而觸發(fā)釋放 PS域 RAB個數(shù) 測量點： PS業(yè)務(wù)建立成功后 ， 由于 SRB復(fù)位 ， RNC向 CN PS發(fā)送 RAB RELEASE REQUEST消息 。 PS業(yè)務(wù)建立成功后 ， 由于 SRB復(fù)位 ， RNC向 CN PS 發(fā)送 IU RELEASE REQUEST消息 ， 其后 CN發(fā)送釋放原因 “ Release due to UTRAN Generated Reason”的 IU RELEASE COMMAND。 RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_TRBRESET 含義： 統(tǒng)計每個小區(qū)上 RNC由于業(yè)務(wù) RLC復(fù)位而觸發(fā)釋放的 PS域 RAB個數(shù) 測量點： PS業(yè)務(wù)建立成功后 ， 由于 TRB復(fù)位 ， RNC向 CN PS 發(fā)送 RAB RELEASE REQUEST消息 。 RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_GTPULOSS 含義： 統(tǒng)計每個小區(qū)上 RNC由于 GTPU異常而觸發(fā)釋放的 PS域 RAB個數(shù) 測量點： PS業(yè)務(wù)建立成功后 ， 由于 GTPU異常 ， RNC向 CN PS發(fā)送 RAB RELEASE REQUEST消息 。 話統(tǒng)指標(biāo)定義類別總結(jié)： 話統(tǒng)指標(biāo)對掉話的定義分為： CS掉話 : 面向?qū)ο蠼y(tǒng)計： RNC、 小區(qū) 面向業(yè)務(wù)統(tǒng)計： AMR 語音 、 VP業(yè)務(wù) PS掉話： 面向?qū)ο蠼y(tǒng)計 :RNC、 小區(qū) 話統(tǒng)指標(biāo)定義 課程內(nèi)容 第一章 掉話分類定義 第二章 常見掉話原因與掉話處理流程 第三章 掉話問題解決方法 第四章 掉話案例分析 第五章 網(wǎng)絡(luò)優(yōu)化各階段掉話關(guān)注點 第二章 常見掉話原因與掉話處理流程 ? 第一節(jié) 常見掉話原因 ? 第二節(jié) 路測數(shù)據(jù)分析流程 ? 第三節(jié) 話統(tǒng)數(shù)據(jù)分析流程 ? 第四節(jié) 信令跟蹤數(shù)據(jù)分析流程 ? 第五節(jié) 用戶投訴數(shù)據(jù)分析流程 常見掉話原因 ? 鄰區(qū)漏配 一般來講，初期優(yōu)化過程掉話占大多數(shù)是由于鄰區(qū)漏配導(dǎo)致的。對于同頻鄰區(qū)，通常采用以下的辦法來確認(rèn)是否為同頻鄰區(qū)漏配： 方法一：觀察掉話前 UE記錄的活動集 EcIo信息和 Scanner記錄的Best Server EcIo信息，如果 UE記錄的 EcIo很差，而 Scanner記錄的 Best Server EcIo很好；同時檢查 Scanner記錄 Best Server擾碼是否出現(xiàn)在掉話前最近出現(xiàn)的同頻測量控制中，如果測量控制中沒有擾碼，那么可以確認(rèn)是鄰區(qū)漏配。 方法二：如果掉話后 UE馬上重新接入，如果 UE重新接入的小區(qū)擾碼和掉話時的擾碼不一致，也可以懷疑是鄰區(qū)漏配問題，可以通過測量控制進一步進行確認(rèn)。 鄰區(qū)漏配導(dǎo)致的掉話也包括異頻鄰區(qū)漏配和異系統(tǒng)鄰區(qū)漏配。 常見掉話原因 ? 覆蓋問題 通常所說的覆蓋差，主要是指 RSCP不和 EcIo都很差。覆蓋的問題需要通過掉話前上行或者下行的專用信道功率來確認(rèn)，需要采用以下的方法來確認(rèn)： 如果掉話前的上行發(fā)射功率達到最大值，并且上行的 BLER也很差或者從 RNC記錄的單用戶跟蹤上看到 NodeB上報 RL failure，基本可以認(rèn)為上行覆蓋差導(dǎo)致的掉話；如果掉話前，下行發(fā)射功率達到最大值，并且下行的 BLER很差，基本可以認(rèn)為是下行覆蓋不行導(dǎo)致的掉話。 確認(rèn)覆蓋的問題簡單直接的方式： 直接觀察 Scanner采集的數(shù)據(jù)，若最好小區(qū)的 RSCP和 EcNo都很低，就可以認(rèn)為是覆蓋問題。 常見掉話原因 ? 切換問題 軟切換 /同頻導(dǎo)致掉話主要分為兩類原因：切換來不及或者乒乓切換。 從信令流程上 CS業(yè)務(wù)表現(xiàn)為手機收不到活動集更新命令（同頻硬切換時為物理信道重配置）， PS業(yè)務(wù)有時候會在切換之前先發(fā)生TRB復(fù)位。 從信號上看，切換來不及主要有以下兩種現(xiàn)象： 1）拐角：源小區(qū) EcIo陡將，目標(biāo)小區(qū) EcNo陡升（即突然出現(xiàn)就是很高的值）； 2）針尖：源小區(qū) EcIo快速下降后一段時間后上升，目標(biāo)小區(qū)出現(xiàn)短時間的陡升。 乒乓切換主要有以下兩種現(xiàn)象： 1）主導(dǎo)小區(qū)變化快： 2個或者多個小區(qū)交替成為主導(dǎo)小區(qū)，主導(dǎo)小區(qū)具有較好的 RSCP和 EcIo每個小區(qū)成為主導(dǎo)小區(qū)的時間很短； 2）無主導(dǎo)小區(qū)：存在多個小區(qū)， RSCP正常而且相互之間差別不大，每個小區(qū)的 EcIo都很差。 常見掉話原因 ? 干擾問題 一般情況下，對于下行，當(dāng) CPICH RSCP大于 85dB，而 EcIo小于13dB容易產(chǎn)生了掉話，基本上可以認(rèn)為是下行干擾的問題。對于上行 RTWP比正常值（ 104~105）超過 10dB，干擾時間超過2~3s，就有可能造成掉話。 對于下行，干擾可能是導(dǎo)頻污染引起。 常見掉話原因 ? 流程交互問題 一些需要信令交互的流程，如 AMR控制、 DCCC以及壓縮模式的啟停、 UE的狀態(tài)遷移等，常常會由于信號的原因，手機支持方面的原因或者 RAN設(shè)備和手機的配合問題，導(dǎo)致流程失敗，最后導(dǎo)致掉話。 這類問題需要針對特定的流程和手機進行分析，沒有一般性的處理方法。 常見掉話原因 ? 其他異常問題 在排除了以上的原因之后，其他的掉話一般需要懷疑設(shè)備的問題，需要通過查看設(shè)備的日志，告警等進一步來分析掉話原因。 例如：同步失敗導(dǎo)致的鏈路不停增加和刪除。 例如：手機不上報 1a測量報告導(dǎo)致掉話。 第二章 常見掉話原因與掉話處理流程 ? 第一節(jié) 常見掉話原因 ? 第二節(jié) 路測數(shù)據(jù)分析流程 ? 第三節(jié) 話統(tǒng)數(shù)據(jù)分析流程 ? 第四節(jié) 信令跟蹤數(shù)據(jù)分析流程 ? 第五節(jié) 用戶投訴數(shù)據(jù)分析流程 路測數(shù)據(jù)分析流程 ? 路測數(shù)據(jù)分析流程 1 準(zhǔn)備數(shù)據(jù) UE和 Scanner最好小區(qū)比較 穩(wěn)定 一致 N 2 獲取掉話 位置和時間 3 分析 Scanner主導(dǎo)小區(qū)信號變化 RSCP差 EcIo差 RSCP正常 EcIo差 RSCP正常 EcIo正常 鄰區(qū)漏配 上行干擾問題 切換不及時 確認(rèn)漏配 鄰區(qū)？ 覆蓋問題 異常掉話 導(dǎo)頻干擾問題 不一致 確認(rèn)上行 干擾？ 問題是否解決 4 重新路測 Y 主導(dǎo)小區(qū)信號穩(wěn)定？ 4 Scanner最優(yōu)小 RSCP 和 EcIO 乒乓切換問題 變化頻繁 Y N 路測數(shù)據(jù)分析流程 準(zhǔn)備數(shù)據(jù) 路測軟件采集數(shù)據(jù)文件 RNC記錄的單用戶跟蹤 RNC記錄的 CDL 獲取掉話位置 采用路測數(shù)據(jù)處理軟件，比如 Analyzer和獲取掉話的時間和地點，獲取掉話前后 Scanner采集的導(dǎo)頻數(shù)據(jù)，手機采集的活動集和監(jiān)視集信息，信令流程等。 分析 Scanner主導(dǎo)小區(qū)變化情況 主要分析主導(dǎo)小區(qū)的變換情況，如果主導(dǎo)小區(qū)相對穩(wěn)定，進一步分析 RSCP和 EcIo情況； 如果主導(dǎo)小區(qū)變化頻繁，需要區(qū)分主導(dǎo)小區(qū)變化快的情況，或者沒有主導(dǎo)小區(qū)的情況，然后進一步進行乒乓切換掉話分析。 路測數(shù)據(jù)分析流程 分析 Scanner主導(dǎo)小區(qū)信號 RSCP和 EcIo 觀察 Scanner最好小區(qū) RSCP， EcNo，根據(jù)不同