1.3.1RlFail_Report
常見原因
產(chǎn)生RLFail的直接原因是RNC判斷上行失敗造成，從目前的優(yōu)化經(jīng)驗(yàn)來看，主要有三個方面造成了這種原因
1）終端側(cè)出現(xiàn)異常
當(dāng)終端發(fā)生異常，沒有上發(fā)信號，導(dǎo)致基站側(cè)檢測不到上行信號而報無線鏈路失敗，終端側(cè)的異常包括：
a．終端本身出現(xiàn)異常，比如死機(jī)；
b．終端與SIM卡的連接出現(xiàn)異常，比如卡松動導(dǎo)致終端脫網(wǎng)等；
c．終端通話中終端斷電；
如果終端側(cè)出現(xiàn)異常，要重新作起業(yè)務(wù)，一般要對終端進(jìn)行重啟，終端重啟后將會進(jìn)行一次Location Update過程，這從系統(tǒng)側(cè)后臺信令上可以觀察到，并且從上次RL Failure導(dǎo)致掉話到下次重新作起業(yè)務(wù)來也將會有較大的時延，通常要超過30秒。
2）無線信道環(huán)境出現(xiàn)深衰落或者強(qiáng)干擾
無線信道環(huán)境出現(xiàn)深衰落或強(qiáng)干擾時，會導(dǎo)致基站沒有解對終端發(fā)出的上行信號而報RL Failure，如果是出現(xiàn)深衰落，下行鏈路的無線信道環(huán)境跟上行鏈路一樣，信道質(zhì)量變差，下行功率會抬升得比較高，并且UE會上報Cell Update。這種情況需要進(jìn)行用戶回訪和復(fù)測才能發(fā)現(xiàn)，用戶往往出在室內(nèi)弱場區(qū)域，解決方案是加強(qiáng)覆蓋，減少干擾。
3）基站側(cè)出現(xiàn)異常
基站解錯上行信號或接收不到上行信號而報無線鏈路失敗。此時基站應(yīng)該會出現(xiàn)告警，且基本上不能接入和保持住包括語音在內(nèi)的任何業(yè)務(wù)或終端了。
解決方法
針對該類原因產(chǎn)生的掉話，從以下幾個方面進(jìn)行優(yōu)化：
1）全網(wǎng)頻點(diǎn)、擾碼重新規(guī)劃，降低網(wǎng)絡(luò)干擾；
2）弱場優(yōu)化。對全網(wǎng)所有道路進(jìn)行遍歷，獲取覆蓋圖，對場強(qiáng)低于-90dBm的成片區(qū)域提補(bǔ)點(diǎn)需求；
3）23G互操作優(yōu)化，盡力確保2G能夠成功挽救3G弱場造成的掉話；
4）TOPN小區(qū)優(yōu)化，篩選該原因掉話原因較多的小區(qū)，進(jìn)行參數(shù)檢查、干擾排查以及覆蓋區(qū)域內(nèi)精細(xì)優(yōu)化。
5）分析CDT和CT數(shù)據(jù)，對發(fā)現(xiàn)的由于個別用戶引起的大量次數(shù)現(xiàn)象進(jìn)行統(tǒng)計，如果情況允許，進(jìn)行用戶回訪。
1.3.2RNLC_Ue_IntraRNCHo_TimeOut,
常見原因
造成RNLC_Ue_IntraRNCHo_TimeOut掉話的原因主要是由于RNC沒有收到UE上發(fā)的Phycial channel reconfiguration Complete消息，系統(tǒng)判定UE超時導(dǎo)致掉話，出現(xiàn)此類原因主要有以下幾個方面：
1）源小區(qū)的下行鏈路失敗
造成下行鏈路失敗可能是弱覆蓋或者下行鏈路干擾，UE與源小區(qū)之間已經(jīng)失步，導(dǎo)致UE無法收到系統(tǒng)下發(fā)的Phycial channel reconfiguration系統(tǒng)消息；
2）UE與目標(biāo)小區(qū)之間無法同步
UE在切換的過程中，必須要與目標(biāo)小區(qū)同步成功再能順利切換過去，如果無法同步將會導(dǎo)致切換失敗，造成UE與目標(biāo)小區(qū)無法同步的原因主要有：目標(biāo)小區(qū)上行鏈路存在干擾，周邊存在與目標(biāo)小區(qū)的擾碼有問題的小區(qū)（存在擾碼相關(guān)性差或者同擾碼組），目標(biāo)小區(qū)有同頻干擾現(xiàn)象，目標(biāo)小區(qū)信號很差存在弱覆蓋現(xiàn)象；
3）終端原因
4）基站故障
解決方法
針對此類掉話，解決的方案主要從以下幾個方面著手：
1）檢查源小區(qū)下行鏈路是否存在干擾，排查對源小區(qū)造成干擾的干擾源，系統(tǒng)內(nèi)主要是同頻干擾，天饋調(diào)整進(jìn)行覆蓋控制，或者修改頻點(diǎn)進(jìn)行解決；切換區(qū)域是否是弱覆蓋區(qū)域，如果是弱覆蓋區(qū)域，檢查能否通過天饋調(diào)整解決，不行增加基站；
2）排查目標(biāo)小區(qū)是否存在上行干擾，對目標(biāo)小區(qū)的頻點(diǎn)、擾碼進(jìn)行檢查，通過調(diào)整天饋、修改頻點(diǎn)、調(diào)整功率、修改擾碼等措施進(jìn)行解決，如果切換點(diǎn)存在弱覆蓋現(xiàn)象，建議增加基站加強(qiáng)覆蓋；
3）對目標(biāo)切換的目標(biāo)小區(qū)以及原小區(qū)進(jìn)行故障排查；
4）TOPN小區(qū)優(yōu)化，篩選該原因掉話原因較多的小區(qū)，進(jìn)行參數(shù)檢查、干擾排查以及覆蓋區(qū)域內(nèi)精細(xì)優(yōu)化；
5）分析CDT和CT數(shù)據(jù)，對發(fā)現(xiàn)的由于個別用戶引起的大量次數(shù)現(xiàn)象進(jìn)行統(tǒng)計，如果情況允許，進(jìn)行用戶回訪；
1.3.3RNLC_Ue_CellUpdate_TimeOut
常見原因
產(chǎn)生CellUpdate的直接原因是UE判斷下行失敗造成，當(dāng)UE在一定的時間內(nèi)沒有收到系統(tǒng)下發(fā)的消息，會認(rèn)為下行無線質(zhì)量惡化導(dǎo)，進(jìn)一步判斷下行失步后，此時UE會上報小區(qū)更新（CellUpdate），網(wǎng)絡(luò)側(cè)根據(jù)小區(qū)更新的目標(biāo)小區(qū)分配無線資源，因此小區(qū)更新（CellUpdate）有兩種可能性：
1)小區(qū)更新（CellUpdate）發(fā)生在本小區(qū)，如果來自在當(dāng)前歸屬小區(qū)，出于規(guī)避下行干擾的考慮將為終端分配新的物理資源，如果此時該小區(qū)剩余資源不足時，會出現(xiàn)小區(qū)更新資源不足而導(dǎo)致掉話。并且在本小區(qū)上報小區(qū)更新（CellUpdate）從另一方面也可以認(rèn)為部分RLC層參數(shù)（N315、T313等）配置不合理造成。
2)小區(qū)更新（CellUpdate）發(fā)生在其它小區(qū)，此種情況系統(tǒng)側(cè)同時報了RLFail基本上可以認(rèn)定是無線覆蓋的原因或是C/I較差造成。
UE上報小區(qū)更新（CellUpdate）后，在TRL fail wait CU（目前廣州為5s）時間內(nèi)如果更新成功，則可以重新建立業(yè)務(wù)。相反，則會產(chǎn)生原因?yàn)镽NLC_Ue_CellUpdate_TimeOut的掉話。
解決方法
針對該類原因產(chǎn)生的掉話，從以下幾個方面進(jìn)行優(yōu)化：
1）全網(wǎng)頻點(diǎn)、擾碼重新規(guī)劃，降低網(wǎng)絡(luò)干擾；
2) 全網(wǎng)參數(shù)參數(shù)檢查，重點(diǎn)是功率類參數(shù)、23G互操作參數(shù)檢查；
3）弱場優(yōu)化。對全網(wǎng)所有道路進(jìn)行遍歷，獲取覆蓋圖，對場強(qiáng)低于-90dBm的成片區(qū)域提補(bǔ)點(diǎn)需求；
4）23G互操作優(yōu)化，盡力確保2G能夠成功挽救3G弱場造成的掉話；
5）TOPN小區(qū)優(yōu)化，篩選該原因掉話原因較多的小區(qū)，進(jìn)行參數(shù)檢查、干擾排查以及覆蓋區(qū)域內(nèi)精細(xì)優(yōu)化。并結(jié)合CT分析，進(jìn)行道路優(yōu)化等；
1.3.4RNLC_Ue_RabOper_TimeOut
常見原因
對于RabOper_TimeOut引起的掉話，常見的有以下幾種可能性：
1）存在UPPCH的干擾，如果是硬切換的情況下會造成隨機(jī)接入過程的失敗，從而造成物理信道重配置失敗；
3）虛假的鄰小區(qū)關(guān)系造成物理信道重配置超時；
4）RB重配置參數(shù)設(shè)置不合理造成RB重配置超時；
5）功率參數(shù)配置不合理造成RB或物理信道重配置超時；
6）弱場切換失��；
7）并發(fā)業(yè)務(wù)RAB建立超時，統(tǒng)計為掉話。
解決方法
針對該類原因產(chǎn)生的掉話，從以下幾個方面進(jìn)行優(yōu)化：
1）全網(wǎng)頻點(diǎn)、擾碼重新規(guī)劃，降低網(wǎng)絡(luò)干擾；
2）弱場優(yōu)化。對全網(wǎng)所有道路進(jìn)行遍歷，獲取覆蓋圖，對場強(qiáng)低于-90dBm的成片區(qū)域提補(bǔ)點(diǎn)需求；
3）23G互操作優(yōu)化，確保TD網(wǎng)絡(luò)覆蓋空洞區(qū)域終端能夠下沉到2G；
4）TOPN小區(qū)優(yōu)化，篩選該原因掉話原因較多的小區(qū)，進(jìn)行參數(shù)檢查、干擾排查以及覆蓋區(qū)域內(nèi)精細(xì)優(yōu)化；
5）分析CDT和CT數(shù)據(jù)，對發(fā)現(xiàn)的由于個別用戶或者終端引起的大量次數(shù)現(xiàn)象進(jìn)行統(tǒng)計，如果情況允許，進(jìn)行用戶回訪；
6）針對并發(fā)業(yè)務(wù)建立過程中，RAB建立超時，引起Iu ReleaseReqest統(tǒng)計為掉話的類型，可以單獨(dú)分析，這類原因不屬于掉話；
1.3.5UCIU_error
常見原因
產(chǎn)生UCIU Error的直接原因是用戶出錯誤，RLC達(dá)到最大復(fù)位重發(fā)次數(shù)后產(chǎn)生的錯誤，產(chǎn)生此種錯誤的原因主要以下幾種原因：
1）RLC層發(fā)生了不恢復(fù)的錯誤；
2）參數(shù)配置錯誤；
3）無線覆蓋原因，其主要還是造成了RLC層的錯誤；
4）基站故障；
5）部分終端原因也會造成此這種原因的出現(xiàn)。
UCIU error表示RLC（無線鏈路控制層）不可恢復(fù)性錯誤。從結(jié)構(gòu)模型看，RLC層是比物理層高。發(fā)生UCIU error掉話，說明鏈路的RLC層出現(xiàn)故障。