A、如果UE在掉話前發(fā)生了切換，并且UE發(fā)送完重配置完成消息后直到掉話前一直沒(méi)有收到任何RNC下發(fā)的信令，可能重配置完成消息RNC沒(méi)有收到，從而定時(shí)器超時(shí)后釋放鏈路。原因可能是重配置消息的功率太低，造成RNC沒(méi)有收到，對(duì)此需要提高“配給Node B的上行目標(biāo)信噪比”
B、如果UE在掉話前發(fā)生了切換，并且UE發(fā)送完重配置完成消息后直到掉話前一直沒(méi)有收到任何RNC下發(fā)的信令，可能RNC收到了且下發(fā)了測(cè)量控制消息，但UE沒(méi)有收到測(cè)量控制，由于測(cè)量控制消息采用AM模式，需要在一定的時(shí)間內(nèi)收到接收端對(duì)AM模式數(shù)據(jù)的確認(rèn)，最終導(dǎo)致UE的RLC層發(fā)生了RLC不可恢復(fù)錯(cuò)誤
C、如果掉話前發(fā)生了原因?yàn)闊o(wú)線鏈路失敗的小區(qū)更新，說(shuō)明掉話區(qū)域的下行鏈路質(zhì)量惡化，建議針對(duì)覆蓋、干擾、鄰區(qū)漏配等原因進(jìn)行排查
D、如果掉話前網(wǎng)絡(luò)側(cè)信令顯示Node B上報(bào)了無(wú)線鏈路失敗指示，則說(shuō)明Node B出現(xiàn)上行失步，說(shuō)明掉話區(qū)域的上行鏈路質(zhì)量惡化。建議針對(duì)覆蓋、干擾、鄰區(qū)漏配、功率參數(shù)設(shè)置等問(wèn)題進(jìn)行排查

A、檢查掉話點(diǎn)的覆蓋情況，排除覆蓋問(wèn)題導(dǎo)致的掉話。如果問(wèn)題區(qū)域存在覆蓋問(wèn)題，則首先解決覆蓋問(wèn)題
B、檢查基站、RNC設(shè)備工作狀態(tài)是否正常，是否存在可能影響到業(yè)務(wù)或切換正常進(jìn)行的告警
C、分析掉話前的信令流程，進(jìn)行進(jìn)一步的分析
D、呼叫重建不支持等原因也會(huì)導(dǎo)致掉話的發(fā)生，建議具體的掉話原因直接根據(jù)RNC側(cè)信令跟蹤文件里Iu Release Command消息中攜帶的原因直接判斷

A、在同步保持階段，NodeB在收到"無(wú)線鏈路失步指示次數(shù)"個(gè)失步指示后，將啟動(dòng)"無(wú)線鏈路失效定時(shí)器
B、在收到"無(wú)線鏈路同步指示次數(shù)"個(gè)同步狀態(tài)指示，NodeB將停止和復(fù)位"無(wú)線鏈路失效定時(shí)器
C、如果"無(wú)線鏈路失效定時(shí)器"超時(shí)，基站物理層向基站高層匯報(bào)失步?；靖邔油ㄟ^(guò)NBAP協(xié)議,向RNC發(fā)送"RADIO LINK RESTORE FAILURE"消息
D、RNC收到"RADIO LINK RESTORE FAILURE"消息,啟動(dòng)"收到RL失敗等待定時(shí)器

A、由于現(xiàn)在實(shí)現(xiàn)的原因，不是UE在GSM網(wǎng)絡(luò)上發(fā)測(cè)量報(bào)告，然后網(wǎng)絡(luò)觸發(fā)UE 小區(qū)改變命令，然后UE重選到TD網(wǎng)絡(luò)
B、由于現(xiàn)在實(shí)現(xiàn)的原因，UE通過(guò)測(cè)量的方式?jīng)Q定重選到TD網(wǎng)絡(luò)，與idle模式下重選相似，故RRC connection request的原因是系統(tǒng)間小區(qū)重選，而不是系統(tǒng)間小區(qū)改變，所以，從整個(gè)信令流程已無(wú)法判斷與idle時(shí)重選的異同
C、由于現(xiàn)在實(shí)現(xiàn)的原因，通過(guò)RA和LA更新后，收到網(wǎng)絡(luò)側(cè)MODIFY PDP CONTEXT REQUEST (NETWORK TO MS DIRECTION)和UE回MODIFY PDP CONTEXT ACCEPT消息
D、首先，由BSS向UE發(fā)送RR-Cell Change Order 消息，UE接收到該消息后執(zhí)行向TD-SCDMA的小區(qū)重選過(guò)程，與目標(biāo)RN核心網(wǎng)建立信令連接，并觸發(fā)路由區(qū)更新過(guò)程。其中，在RRC Connection Establishment 過(guò)程中，“Establishment cause”IE為Inter-RAT cell change order，并具有較高的優(yōu)先級(jí)。

A、SRNC重定位準(zhǔn)備定時(shí)器超時(shí)處理策略:SRNC重定位準(zhǔn)備定時(shí)器超時(shí)(SRNC在該定時(shí)器超時(shí)前未收到CN下發(fā)的Relocation Command或Relocation Preparation Failure),SRNC上報(bào)Relocation Cannel給CN,同時(shí)開(kāi)啟SRNC重定位取消定時(shí)器。
B、SRNC重定位定時(shí)器超時(shí)處理策略:SRNC重定位定時(shí)器超時(shí)(SRNC在該定時(shí)器超時(shí)前未收到CN下發(fā)的Iu Release Command或UE上報(bào)的RB Relocation Failure),CN下發(fā)Iu Release Request給SRNC,同時(shí)開(kāi)啟SRNC重定位取消定時(shí)器。
C、SRNC重定位取消定時(shí)器超時(shí)處理策略:SRNC重定位取消定時(shí)器超時(shí)(SRNC在該定時(shí)器超時(shí)前未收到CN下發(fā)的Relocation Cannel ACK),SRNC上報(bào)Iu Release Request給CN釋放鏈路。
D、TRNC目標(biāo)側(cè)等待UU側(cè)重定位完成定時(shí)器超時(shí)處理策略: TRNC目標(biāo)側(cè)等待UU側(cè)重定位完成定時(shí)器超時(shí)(TRNC在該定時(shí)器超時(shí)前未收到UE上發(fā)的RB Reconfiguration Complete或CN下發(fā)的Iu Release Command),TRNC上報(bào)Iu Release Request給CN釋放鏈路。