目錄
1 概述
2 掉話定位處理方法
2.1. 掉話率指標(biāo)分析流程
2.1.1. 全網(wǎng)話統(tǒng)指標(biāo)分析流程
2.1.2. Top小區(qū)掉話分析流程
2.2. 掉話問(wèn)題分類處理
2.2.1. 無(wú)線類問(wèn)題處理
2.2.2. 傳輸類問(wèn)題處理
2.2.3. 擁塞類問(wèn)題處理
2.2.4. 切換類故障處理
2.2.5. 核心網(wǎng)類故障處理
1 概述
本《LTE掉話優(yōu)化指導(dǎo)書(shū)》重點(diǎn)介紹了LTE系統(tǒng)內(nèi)掉話率指標(biāo)的優(yōu)化思路、分析方法、定位手段及典型案例；
本《指導(dǎo)書(shū)》結(jié)構(gòu)如下：
第一部分 主要從路測(cè)、標(biāo)準(zhǔn)接口、話統(tǒng)、CHR多角度出發(fā)給出了掉話的定義；
第二部分 給出了常見(jiàn)的掉話原因，掉話機(jī)制的介紹；
第三部分 介紹了掉話問(wèn)題的隔離定位分析方法；
第四部分 分享了掉話優(yōu)化的典型案例；
第五部分 介紹了CHR數(shù)據(jù)的分析方法，影響掉話的定時(shí)器介紹及重建的機(jī)制介紹。
2 掉話定位處理方法
2.1. 掉話率指標(biāo)分析流程
一旦當(dāng)?shù)粼扠PI指標(biāo)下降或者出現(xiàn)劇烈波動(dòng)的時(shí)候，首先要做的就是要把問(wèn)題梳理清楚、既問(wèn)題隔離；搞明白問(wèn)題出自哪里、問(wèn)題存在范圍，然后有的放矢的進(jìn)行有針對(duì)性的解決，掉話率指標(biāo)分析流程圖如下所示：
圖1 話統(tǒng)指標(biāo)分析流程圖
如上圖所示，針對(duì)掉話率KPI的分析思路，在獲取到掉話相關(guān)的Counter’指標(biāo)后，通常有需要從兩個(gè)方面入手：
1、是否是整網(wǎng)級(jí)別的掉話率指標(biāo)惡化：
2、是否是Top小區(qū)引起的指標(biāo)惡化；
2.1.1. 全網(wǎng)話統(tǒng)指標(biāo)分析流程
說(shuō)明：
1、首先需要在話統(tǒng)側(cè)獲取全網(wǎng)的掉話率指標(biāo)以及趨勢(shì)，掉話率趨勢(shì)分析至少需要分析1~2周左右的數(shù)據(jù)。如果全網(wǎng)的掉話率指標(biāo)突然偏高（高于驗(yàn)收值），一般下列因素會(huì)導(dǎo)致全網(wǎng)的掉話率突然增加，需要執(zhí)行以下的檢查：
a) 全網(wǎng)是否做過(guò)重大動(dòng)作，如割切、搬遷等；
b) 是否存在核心網(wǎng)側(cè)的版本變更或參數(shù)更改；
c) 是否存在eRAN側(cè)參數(shù)的更改，如定時(shí)器的修改、算法開(kāi)關(guān)的調(diào)整等；
d) 檢查系統(tǒng)是否做過(guò)版本升級(jí)、打補(bǔ)丁等動(dòng)作；對(duì)于eNodeB，可通過(guò)WebLMT或者M(jìn)2000執(zhí)行MML命令“LST SOFTWARE”進(jìn)行查詢，查詢結(jié)果顯示形式如下：
圖2 eNodeB軟件版本查詢結(jié)果
e) 全網(wǎng)話務(wù)量趨勢(shì)分析：分析是否由于話務(wù)量突然增加影響到掉話率上升；話務(wù)量的分析通�？赏ㄟ^(guò)e-RAB嘗試建立的次數(shù)及成功次數(shù)的分布來(lái)判斷；是否存在重大活動(dòng)如重要節(jié)假日或放號(hào)等；
2、在排除上述影響因素之后，如果全網(wǎng)的掉話率指標(biāo)依舊一直偏高，需要通過(guò)分析異常釋放原因值Counter，分析一下異常釋放原因分布的比例，針對(duì)引起掉話問(wèn)題分類原因進(jìn)行分析處理，如果：
a) L.E-RAB.AbnormRel.TNL原因較多：觀察S1口/X2口傳輸是否出現(xiàn)問(wèn)題，排查傳輸引起的告警，如閃斷等；
b) L.E-RAB.AbnormRel.Radio/L.E-RAB.AbnormRel.HOFailure原因較多：觀察網(wǎng)規(guī)是否合理，如PCI規(guī)劃、鄰小區(qū)規(guī)劃情況；
c) L.E-RAB.AbnormRel.MME原因較多：需要協(xié)調(diào)核心網(wǎng)一起進(jìn)行排查，但是由于核心網(wǎng)引起原因值并不記錄在eRAN側(cè)的L.E-RAB.AbnormRel之內(nèi)，所以該步驟可選；
3、在排除了以上原因之后，如果掉話率依舊沒(méi)有改善，建議反饋至問(wèn)題定位的下一環(huán)節(jié)進(jìn)行處理。
2.1.2. Top小區(qū)掉話分析流程
針對(duì)非全網(wǎng)性故障導(dǎo)致的指標(biāo)波動(dòng)或下降時(shí)，需要使用定位Top小區(qū)的思路對(duì)問(wèn)題進(jìn)行定位分析，Top小區(qū)的選取需要遵循如下規(guī)則：
A) Top小區(qū)的掉話率指標(biāo)要低于全網(wǎng)平均掉話率指標(biāo)；
B) 按照異常掉話絕對(duì)次數(shù)將小區(qū)進(jìn)行從大到小的降序排列；
在確定了Top小區(qū)后，需要按照如下流程進(jìn)行問(wèn)題的分析
1、首先針對(duì)Top小區(qū)進(jìn)行如下幾個(gè)動(dòng)作的核查：
a) Top小區(qū)是否做過(guò)重大動(dòng)作，如割切、搬遷等；
b) 檢查eNodeB側(cè)是否存在該Top小區(qū)相關(guān)的告警信息；檢查該小區(qū)所屬eNodeB的告警，確認(rèn)該小區(qū)沒(méi)有出現(xiàn)故障等信息；常見(jiàn)的告警如RRU相關(guān)的告警、通道相關(guān)的告警、傳輸相關(guān)的告警、基帶板相關(guān)的告警等
c) Top小區(qū)所在核心網(wǎng)是否存在參數(shù)更改；
d) Top小區(qū)是否存在OM操作，如去激活小區(qū)、重啟單板等；
e) Top小區(qū)話務(wù)量趨勢(shì)分析：分析是否由于話務(wù)量突然增加影響到掉話率上升；話務(wù)量的分析通�？赏ㄟ^(guò)e-RAB嘗試建立的次數(shù)及成功次數(shù)的分布來(lái)判斷；是否存在演唱會(huì)、大型體育賽事等；
f) 是否存在參數(shù)修改：需要檢查小區(qū)參數(shù)在掉話率異常期間是否存在修改，如定時(shí)器的修改、算法開(kāi)關(guān)的調(diào)整等，與掉話率相關(guān)參數(shù)的幾個(gè)重要參數(shù)如下表所示（后續(xù)將隨版本更新）；
2、然后，在排除上述影響因素之后，如果Top小區(qū)掉話率指標(biāo)依舊一直偏高，需要通過(guò)分析異常釋放原因值Counter，分析一下異常釋放原因分布的比例，針對(duì)引起掉話問(wèn)題分類原因進(jìn)行分析處理，如果：
a) L.E-RAB.AbnormRel.TNL原因較多：觀察S1口/X2口傳輸是否出現(xiàn)問(wèn)題，排查傳輸引起的告警，如閃斷等；
b) L.E-RAB.AbnormRel.MME原因較多：需要協(xié)調(diào)核心網(wǎng)一起進(jìn)行排查，但是由于核心網(wǎng)引起原因值并不記錄在eRAN側(cè)的L.E-RAB.AbnormRel之內(nèi)，所以該步驟可選；
c) L.E-RAB.AbnormRel.HOFailure原因較多：需要對(duì)切換失敗較高的小區(qū)進(jìn)行特定兩小區(qū)測(cè)量Counter的分析，對(duì)失敗次數(shù)最多的鄰小區(qū)關(guān)系進(jìn)行梳理，核查其鄰小區(qū)配置的合理性；并通過(guò)內(nèi)部CHR數(shù)據(jù)確認(rèn)下是否存在Top用戶（詳見(jiàn)切換類掉話分析）
d) L.E-RAB.AbnormRel.Cong原因較多：需要進(jìn)行負(fù)載均衡或者擴(kuò)容；
e) L.E-RAB.AbnormRel.Radio原因較多：需要查看是否存在Top用戶、弱覆蓋、干擾或者終端異常等原因。需要通過(guò)CHR日志進(jìn)行弱覆蓋、Top用戶的確認(rèn)。常見(jiàn)CHR內(nèi)部Top原因與實(shí)際掉話原因?qū)?yīng)關(guān)系如下表所示：
注：其中RF問(wèn)題包含了3.1章節(jié)中描述的鄰小區(qū)錯(cuò)/漏配、弱覆蓋、上下行干擾。
3、分析優(yōu)化措施是否可以全網(wǎng)復(fù)制，如果可以的話安排全網(wǎng)經(jīng)驗(yàn)復(fù)制，分析實(shí)施后的指標(biāo)是否滿足要求，如果滿足要求，那么結(jié)束掉話優(yōu)化；否則，重新進(jìn)行下一輪Top小區(qū)優(yōu)化；
4、在排除了以上原因之后，如果掉話率依舊沒(méi)有改善，建議反饋至問(wèn)題定位的下一環(huán)節(jié)進(jìn)行處理。
2.2. 掉話問(wèn)題分類處理
按照問(wèn)題定位分析流程，先由話統(tǒng)數(shù)據(jù)入手，再通過(guò)CHR數(shù)據(jù)進(jìn)行深入定位。
2.2.1. 無(wú)線類問(wèn)題處理
2.2.1.1. 問(wèn)題現(xiàn)象
在eNodeB側(cè)話統(tǒng)Counter定義中，如果異常釋放打點(diǎn)在L.E-RAB.AbnormRel.Radio Counter下，則可以判定為該掉話是由于無(wú)線側(cè)空口問(wèn)題導(dǎo)致的掉話。且是屬于非切換場(chǎng)景下引起的掉話。
2.2.1.2. 可能原因
針對(duì)原因值為Radio的掉話，主要是由于弱覆蓋，上行干擾、終端異常等原因?qū)е碌腞LC達(dá)到最大重傳次數(shù)、失步、信令流程交互失敗等
2.2.1.3. 處理步驟
確定該站點(diǎn)是否用戶多集中于弱覆蓋區(qū)域。通過(guò)獲取Top站點(diǎn)所在小區(qū)的小區(qū)全帶寬CQI的上報(bào)次數(shù)、PDSCH上各個(gè)MCS索引值的調(diào)度次數(shù)、PUSCH上各個(gè)MCS索引值的調(diào)度次數(shù)Counter指標(biāo)，觀察CQI及MCS的分布情況，是否如果整體分布情況都處于低階，則需要通過(guò)路測(cè)進(jìn)行確認(rèn)，并實(shí)施覆蓋調(diào)整。
如果該站點(diǎn)并未出現(xiàn)較多比例的弱覆蓋情況，則需要通過(guò)跟蹤上行干擾檢測(cè)信息，觀察是否存在上行干擾。
干擾檢測(cè)是通過(guò)分析采樣數(shù)據(jù)的頻譜及功率分布，監(jiān)測(cè)無(wú)線環(huán)境中的頻域與時(shí)域干擾。
圖3 M2000側(cè)上行干擾檢測(cè)跟蹤
如果該站點(diǎn)并未出現(xiàn)上行干擾，且話統(tǒng)數(shù)據(jù)無(wú)法得到有效結(jié)果，則可以通過(guò)CHR日志進(jìn)行深度問(wèn)題定位，觀察是否存在Top用戶，是否存在上下行的弱覆蓋：
首先、通過(guò)CHR數(shù)據(jù)查看是否存在Top用戶，Top用戶的分析參見(jiàn)附錄6.1.1.4章節(jié)內(nèi)描述，如果存在Top用戶，再分析一下該Top用戶掉話的規(guī)律，是終端問(wèn)題引起的還是弱覆蓋引起。
然后針對(duì)Top小區(qū)分析異常釋放的原因分布，無(wú)線類常見(jiàn)的內(nèi)部異常釋放原因值如下表所示：
通過(guò)UMAT工具查看最后10條信令；
1、通過(guò)InsightSharp分析L2調(diào)度信息，判斷是弱覆蓋還是突然不發(fā)數(shù)導(dǎo)致；
如果以上過(guò)程無(wú)法完成問(wèn)題的定位，需要采集如下日志反饋回下一環(huán)節(jié)進(jìn)行出咯
一鍵式日志：主要采集Top小區(qū)所在eNB的主控板及基帶板的單板日志
TTI跟蹤：主要指IFTS跟蹤及小區(qū)跟蹤，由于數(shù)據(jù)量較大，只需采集Top小區(qū)Top時(shí)間段即可
網(wǎng)絡(luò)配置：包括組網(wǎng)信息，工程參數(shù)， Top站點(diǎn)的配置文件
重大事件：是否存在集中放號(hào)，大規(guī)模測(cè)試，重大節(jié)日/活動(dòng)
2.2.1.4. 典型案例
待補(bǔ)充
2.2.2. 傳輸類問(wèn)題處理
2.2.2.1. 問(wèn)題現(xiàn)象
在eNodeB側(cè)話統(tǒng)Counter定義中，如果異常釋放打點(diǎn)在L.E-RAB.AbnormRel.TNLCounter下，則可以判定為該掉話是由于傳輸層問(wèn)題導(dǎo)致的掉話。
2.2.2.2. 可能原因
針對(duì)原因值為T(mén)NL的掉話，主要是由于eNodeB與MME之間傳輸異常，如S1接口傳輸閃斷導(dǎo)致。
2.2.2.3. 處理步驟
通過(guò)告警排查，核查是否存在傳輸方面的告警，再通過(guò)將傳輸告警排查后觀察掉話類指標(biāo)是否恢復(fù)。
通過(guò)M2000側(cè)查看該站點(diǎn)是否存在傳輸相關(guān)的告警
按照告警排查的建議進(jìn)行告警恢復(fù)
如果告警恢復(fù)后，指標(biāo)依舊異常（TNL的原因占比依舊很高），建議返回如下log進(jìn)行進(jìn)一步定位：
一鍵式日志：主要采集Top小區(qū)所在eNB的主控板及基帶板的單板日志
網(wǎng)絡(luò)配置：包括組網(wǎng)信息，工程參數(shù)， Top站點(diǎn)的配置文件
2.2.2.4. 典型案例
某局點(diǎn)在2011-12-11日掉話率突增
通過(guò)告警查詢，發(fā)現(xiàn)存在S1接口及SCTP接口的告警，在次日將告警排查后，指標(biāo)恢復(fù)
2.2.3. 擁塞類問(wèn)題處理
2.2.3.1. 問(wèn)題現(xiàn)象
在eNodeB側(cè)話統(tǒng)Counter定義中，如果異常釋放打點(diǎn)在L.E-RAB.AbnormRel.CongCounter下，則可以判定為該掉話是由于資源擁塞問(wèn)題導(dǎo)致的掉話。
2.2.3.2. 可能原因
針對(duì)原因值為Congestion的掉話，主要是由于eNodeB側(cè)無(wú)線資源擁塞導(dǎo)致的異常釋放，如達(dá)到最大用戶數(shù)等。
2.2.3.3. 處理步驟
一旦某Top小區(qū)出現(xiàn)長(zhǎng)時(shí)間的擁塞導(dǎo)致的掉話，短期內(nèi)可考慮打開(kāi)負(fù)載均衡算法/互操作以減輕本小區(qū)的負(fù)載，長(zhǎng)期來(lái)看，需要通過(guò)擴(kuò)容等方法解決，并在通過(guò)擁塞問(wèn)題解決后后觀察掉話類指標(biāo)是否恢復(fù)。
打開(kāi)MLB算法，觀察擁塞狀況是否有改善
如果未能解決，需要反饋如下信息：
一鍵式日志：主要采集Top小區(qū)所在eNB的主控板及基帶板的單板日志
網(wǎng)絡(luò)配置：包括組網(wǎng)信息，工程參數(shù)， Top站點(diǎn)的配置文件
2.2.3.4. 典型案例
待補(bǔ)充
2.2.4. 切換類故障處理
2.2.4.1. 問(wèn)題現(xiàn)象
在eNodeB側(cè)話統(tǒng)Counter定義中，如果異常釋放打點(diǎn)在L.E-RAB.AbnormRel.HOFailureCounter下，則可以判定為該掉話是由于切換出失敗導(dǎo)致的掉話。
2.2.4.2. 可能原因
針對(duì)原因值為Handover Failure引起的掉話，主要是由于用戶在移動(dòng)過(guò)程中由本小區(qū)切換出時(shí)失敗導(dǎo)致異常釋放。
2.2.4.3. 處理步驟
一旦某Top小區(qū)出現(xiàn)較多的由于切換出失敗導(dǎo)致的掉話，可以通過(guò)特定兩小區(qū)對(duì)的切換出Counter進(jìn)行切換失敗的進(jìn)一步定位。
獲取Top小區(qū)對(duì)應(yīng)的特定兩小區(qū)對(duì)的話統(tǒng)Counter
通過(guò)特定兩小區(qū)間的切換出測(cè)量Counter可獲知當(dāng)前Top站點(diǎn)所在小區(qū)與某個(gè)特定目標(biāo)小區(qū)的切換失敗次數(shù)，可針對(duì)失敗次數(shù)較高的目標(biāo)小區(qū)，進(jìn)行鄰小區(qū)關(guān)系的核查，切換參數(shù)的優(yōu)化。
在完成鄰小區(qū)關(guān)系的核查及優(yōu)化之后，可以通過(guò)導(dǎo)回Top源小區(qū)及目標(biāo)小區(qū)的CHR進(jìn)行是源小區(qū)切換命令UE沒(méi)有收到，還是目標(biāo)小區(qū)隨機(jī)接入不成功的分析。
CHR中常見(jiàn)的與切換失敗相關(guān)的內(nèi)部釋放原因值如下表所示：
在進(jìn)行切換關(guān)系優(yōu)化后，觀察指標(biāo)是否恢復(fù)；如果尚未恢復(fù)，建議提供如下信息做進(jìn)一步定位：
一鍵式日志：主要采集Top小區(qū)所在eNB的主控板及基帶板的單板日志
網(wǎng)絡(luò)配置：包括組網(wǎng)信息，工程參數(shù)， Top站點(diǎn)的配置文件
2.2.4.4. 典型案例
待補(bǔ)充
2.2.5. 核心網(wǎng)類故障處理
2.2.5.1. 問(wèn)題現(xiàn)象
在eNodeB側(cè)話統(tǒng)Counter定義中，如果異常釋放打點(diǎn)在L.E-RAB.AbnormRel.MMECounter下，則可以判定為該異常釋放是由于核心網(wǎng)主動(dòng)發(fā)起釋放導(dǎo)致的eRAB異常釋放。但是該類異常釋放并不統(tǒng)計(jì)在L.E-RAB.AbnormRel Counter下。
2.2.5.2. 可能原因
針對(duì)原因值為MME引起的異常釋放，主要是由于核心網(wǎng)在用戶業(yè)務(wù)保持過(guò)程中主動(dòng)發(fā)起的釋放所致。
2.2.5.3. 處理步驟
由于該原因?yàn)榉莈RAB側(cè)原因引起，需要通過(guò)核心網(wǎng)側(cè)相關(guān)信息進(jìn)行定位。
獲取Top小區(qū)S1接口的跟蹤消息；分析核心網(wǎng)主動(dòng)發(fā)起釋放的原因值分布；
將統(tǒng)計(jì)結(jié)果及相關(guān)信令流程與核心網(wǎng)相關(guān)工程師進(jìn)行交流。
關(guān)注樓主