TD網(wǎng)優(yōu)葵花寶典之業(yè)務(wù)異常過程分析篇

1、TD-SCDMA業(yè)務(wù)異常分析指導(dǎo)書目錄1業(yè)務(wù)異常過程31.1網(wǎng)絡(luò)側(cè)收不到RRC連接請(qǐng)求3總體描述3原因分析31.2RRC連接拒絕3總體描述3典型信令過程3原因分析41.3RRC連接建立超時(shí)4總體描述4典型信令過程4原因分析51.4RAB指派失敗6總體描述6典型信令過程61.5承載調(diào)整中的異常9總體描述9典型信令過程10原因分析111.6RNC內(nèi)切換過程中的異常11總體描述11典型信令過程111.7RNC間切換過程中的異常17總體描述17典型信令過程及異常分析171.8CS系統(tǒng)間切換過程中的異常21總體描述21典型信令過程及異常分析211.9PS系統(tǒng)間切換過程中的異常23總體描述23典型信令過程

2、及異常分析231.10保持過程中的掉話24總體描述24典型信令過程241 業(yè)務(wù)異常過程1.1 網(wǎng)絡(luò)側(cè)收不到RRC連接請(qǐng)求1.1.1 總體描述終端發(fā)起呼叫，從路側(cè)終端上可以看到RRC連接請(qǐng)求已經(jīng)發(fā)出，但網(wǎng)絡(luò)側(cè)看不到任何信令。1.1.2 原因分析可能是由于UpPch所在位置存在干擾，導(dǎo)致網(wǎng)絡(luò)側(cè)解錯(cuò)終端上行包，使得RNC看不到任何消息。n 如果是特定終端出現(xiàn)該現(xiàn)象，而其他終端沒有問題，則可以利用掃頻儀在特定終端天線口處檢測(cè)終端上行信號(hào)強(qiáng)度是否正常；n 如果是普遍現(xiàn)象，則需要檢查UpPch所在位置的干擾，如存在干擾則需要考慮對(duì)UpPch位置進(jìn)行偏移。1.2 RRC連接拒絕1.2.1 總體描述RNC收到

3、UE發(fā)送的RRC CONNECTION REQUEST消息后，可能因一些原因?qū)е聼o法為UE建立RRC資源，此時(shí)RNC會(huì)向UE發(fā)送RRC CONNECTION REJECT消息。此類異常影響發(fā)起業(yè)務(wù)的無線接通率KPI指標(biāo)。1.2.2 典型信令過程1. 信令截圖2. 重要信令解釋信令消息過程解釋rrcConnectionRequestUE發(fā)送RRC連接請(qǐng)求，請(qǐng)求接入網(wǎng)絡(luò)；rrcConnectionRejectRNC可能因一些原因無法為UE建立RRC資源，因此發(fā)送RRC連接拒絕，拒絕UE的接入請(qǐng)求；1.2.3 原因分析可能造成RRC連接拒絕的常見原因有：n 小區(qū)碼道資源不足，沒有足夠的碼道為UE分配

4、（特殊地：UE只支持單載頻，而主載頻上已沒有剩余的碼道資源）；n 干擾或功率受限，軟資源接納失敗；n 傳輸資源申請(qǐng)或帶寬接納失??；排查方法：n 查看小區(qū)剩余的碼道資源數(shù)看是否有足夠的剩余資源；n 查看公共測(cè)量值和配置的接納門限，是否為功率干擾等軟資源受限；n 查看Iub口帶寬大小是否受限；1.3 RRC連接建立超時(shí)1.3.1 總體描述RNC向UE發(fā)送RRC CONNECTION SETUP消息，在一定的時(shí)間之內(nèi)未收到UE上報(bào)的RRC CONNECTION SETUP COMPLETE消息，則表示RRC連接建立超時(shí)，將刪除建立的無線鏈路，該UE接入失敗，此類異常影響業(yè)務(wù)的無線接通率KPI指標(biāo)。1

5、.3.2 典型信令過程n 終端只發(fā)送一次RRC連接請(qǐng)求1. 信令截圖2. 重要信令解釋信令消息過程解釋rrcConnectionRequestUE發(fā)送RRC連接請(qǐng)求，請(qǐng)求接入網(wǎng)絡(luò)；RadioLinkSetupReqeustIUB口消息，建立無線鏈路RadioLinkSetupResponserrcConnectionSetup空口消息，RNC向UE發(fā)送RRC建立，建立信令無線承載資源RadioLinkDeleteReqeustIUB口消息，刪除無線鏈路RadioLinkDeleteResponse3. 異常分析 從路測(cè)終端側(cè)可以看到終端已經(jīng)收到RRC連接建立消息，并發(fā)送了RRC連接建立完成消息

6、，造成此現(xiàn)象的原因，多為上行方向上的RRC連接建立完成消息網(wǎng)絡(luò)側(cè)未收到，需要在上行方向上查找原因。n 終端只上報(bào)多次RRC連接請(qǐng)求1. 信令截圖2. 重要信令解釋信令消息過程解釋rrcConnectionRequestUE發(fā)送RRC連接請(qǐng)求，請(qǐng)求接入網(wǎng)絡(luò)；RadioLinkSetupReqeustIUB口消息，建立無線鏈路RadioLinkSetupResponserrcConnectionSetup空口消息，RNC向UE發(fā)送RRC建立，建立信令無線承載資源rrcConnectionRequest由于終端未收到網(wǎng)絡(luò)側(cè)下發(fā)的rrcConnectionSetup消息，終端會(huì)以網(wǎng)絡(luò)側(cè)配置的定時(shí)器（缺

7、省2秒），重復(fù)上報(bào)RRC鏈接請(qǐng)求。rrcConnectionSetuprrcConnectionRequestrrcConnectionSetuprrcConnectionRequestrrcConnectionSetupRadioLinkDeleteReqeustIUB口消息，刪除無線鏈路RadioLinkDeleteResponse3. 異常分析從路測(cè)終端側(cè)看，終端未收到RRC連接建立消息，由于終端在上報(bào)RRC鏈接請(qǐng)求后，收不到網(wǎng)絡(luò)側(cè)RRC鏈接建立，會(huì)重發(fā)RRC鏈接請(qǐng)求，據(jù)此可以判斷網(wǎng)絡(luò)側(cè)下發(fā)的RRC鏈接建立消息終端未收到，需要在下行方向，排查問題，如Iub口傳輸丟包、FACH信道配置不正

8、確。1.3.3 原因分析可能造成RRC建立超時(shí)的常見原因有：n 由于下行功率不足或存在下行干擾等原因，UE未收到RNC發(fā)送的RRC CONNECTION SETUP消息；n UE收到了RRC CONNECTION SETUP消息，也上發(fā)了RRC CONNECTION SETUP COMPLETE消息，但由于上行功率不足或存在上行干擾等原因，RNC未收到該消息；n UE收到了RRC CONNECTION SETUP消息，但由于消息錯(cuò)誤或UE內(nèi)部錯(cuò)誤等原因，UE未發(fā)送RRC CONNECTION SETUP COMPLETE消息；排查方法：n 查看RRC鏈接建立的上行時(shí)隙干擾情況，如果發(fā)現(xiàn)時(shí)隙干擾

9、很大，查看NODEB載扇是否正常，同時(shí)查看鄰小區(qū)是否有大量同頻鄰區(qū)，若在話務(wù)量小的情況下，ISCP仍然很高，則干擾可能來自異系統(tǒng)，如：GSM，PHS等； n 若網(wǎng)絡(luò)側(cè)沒有收到RRC建立完成消息：則調(diào)整后臺(tái)DPCH的期望接收功率，同時(shí)利用網(wǎng)規(guī)網(wǎng)優(yōu)手段，降低上行方向上的干擾；n 無效配置、配置不支持等配置錯(cuò)誤：換個(gè)手機(jī)測(cè)試，若各廠家手機(jī)測(cè)試都有問題，將本小區(qū)RRC建立消息和正常小區(qū)的RRC建立消息進(jìn)行對(duì)比，查看配置是否正確；n 若UE未收到RRC建立消息：調(diào)整后臺(tái)下行最小發(fā)送功率，增加UE接收到RRC建立消息的幾率，或者調(diào)整周圍網(wǎng)絡(luò)的覆蓋、頻點(diǎn)、功率等，盡量降低下行方向上的干擾，或調(diào)整小區(qū)PCCP

10、CH功率及公共信道、共享信道相關(guān)功率，確認(rèn)Iub口傳輸無問題；1.4 RAB指派失敗1.4.1 總體描述RNC收到CN下發(fā)的RAB指派消息后，會(huì)根據(jù)業(yè)務(wù)的QoS需求，在IUB口配置無線鏈路資源，在空口建立無線承載資源。此時(shí)，可能由于資源受限、空口超時(shí)等原因，RNC給CN回RAB指派失敗，會(huì)影響發(fā)起業(yè)務(wù)的無線接通率，RAB指派失敗消息中會(huì)填寫原因值，具體原因值參考常見非標(biāo)準(zhǔn)原因錯(cuò)誤碼對(duì)應(yīng)表。1.4.2 典型信令過程1.4.2.1 RNC資源申請(qǐng)失敗導(dǎo)致的RAB指派失敗1. 信令截圖2. 重要信令解釋信令消息過程解釋RabAssignmentRequestCN發(fā)送的RAB指派請(qǐng)求消息RabAssi

11、gnmentQueuedRNC向CN發(fā)送RAB排隊(duì)指示RabAssignmentFailRNC向CN發(fā)送RAB指派失敗消息，表示RAB指派過程失敗3. 異常分析n 檢查NodeB告警，確認(rèn)小區(qū)未出現(xiàn)閉塞、載頻刪除、載頻閉塞等情況；n 檢查DDM，確認(rèn)小區(qū)載頻、時(shí)隙均未處于屏蔽狀態(tài)；n 與默認(rèn)配置檢查，確認(rèn)相關(guān)License功能都處于打開狀態(tài)；n 與默認(rèn)配置進(jìn)行對(duì)比，檢查小區(qū)資源相關(guān)參數(shù)配置是否正確，如業(yè)務(wù)極限用戶數(shù)等信息，參考資源分配相關(guān)參數(shù)解釋；n 空載狀態(tài)下查看小區(qū)LMT測(cè)量，查看上下行底噪是否異常，如果發(fā)生異常需要排查干擾來源，或確認(rèn)NodeB設(shè)備是否有異常；n 查看小區(qū)話務(wù)量統(tǒng)計(jì)相關(guān)計(jì)

12、數(shù)器，確認(rèn)該小區(qū)是否屬于話務(wù)量較重的小區(qū)，如果確實(shí)屬于熱點(diǎn)小區(qū)，則需要通過增加頻點(diǎn)配置、增加HCS小區(qū)進(jìn)行補(bǔ)熱；1.4.2.2 RB建立超時(shí)導(dǎo)致的RAB指派失敗1. 信令截圖2. 重要信令解釋信令消息過程解釋RabAssignmentRequestCN發(fā)送的RAB指派請(qǐng)求消息RadioLinkReconfigurationPrepare無線鏈路重配過程，為該業(yè)務(wù)配置IUB口資源RadioLinkReconfigurationReadyRadioLinkReconfigurationCommitRadioBearerSetupRNC通過無線承載建立消息，為該業(yè)務(wù)建立空口資源RadioLinkRe

13、storeIndication無線鏈路恢復(fù)指示，表示UE采用新配置后已經(jīng)同步完成RabAssignmentFailRNC向CN發(fā)送RAB指派失敗消息，表示RAB指派過程失敗3. 異常分析發(fā)送RADIO BEARER SETUP給UE后，在一定時(shí)間內(nèi)未收到UE上發(fā)的RADIO BEARER SETUP COMPLETE消息，因超時(shí)導(dǎo)致RAB指派失敗，超時(shí)的原因可能為：n UE未收到RADIO BEARER SETUP消息，需要確認(rèn)Iub口是否存在丟包現(xiàn)象，下行是否存在強(qiáng)干擾或下行發(fā)射功率不足等情況，可以在LMT上觀察UE下行單碼道的發(fā)射碼功率，如果過小可以確認(rèn)是否功控存在問題，或適當(dāng)提高最小發(fā)射

14、功率，進(jìn)行測(cè)試；n UE收到了RADIO BEARER SETUP消息，發(fā)送了RADIO BEARER SETUP COMPLETE消息，但RNC未收到，可以從UE側(cè)確認(rèn)上行功率強(qiáng)度，或查看上行時(shí)隙是否存在干擾等，可適當(dāng)調(diào)整上行初始SIR值進(jìn)行測(cè)試；n UE收到了RADIO BEARER SETUP消息，但沒發(fā)送RADIO BEARER SETUP COMPLETE消息（消息錯(cuò)誤或UE內(nèi)部錯(cuò)誤等原因）；n 如果RRC鏈接建立中等場(chǎng)強(qiáng)屬于中強(qiáng)場(chǎng)，且RB建立的時(shí)隙無干擾，則終端對(duì)于RNC下發(fā)的物理資源配置支持可能存在問題，如部分終端不支持伴隨信道復(fù)用，不支持上行多時(shí)隙、多碼道等。1.4.2.3 R

15、B建立過程中小區(qū)更新導(dǎo)致RAB指派失敗1. 信令截圖2. 異常分析 RNC在分配物理資源后，下發(fā)RB建立，終端收到RB建立后上報(bào)小區(qū)更新，原因?yàn)镽L失敗，若小區(qū)更新場(chǎng)強(qiáng)屬于中強(qiáng)場(chǎng)，則終端對(duì)于RNC下發(fā)的物理資源配置可能存在無線性能問題，如部分終端不支持伴隨信道復(fù)用，不支持上行多時(shí)隙、多碼道等?？墒褂貌煌酒瑥S商的終端進(jìn)行對(duì)比測(cè)試，或調(diào)整RNC分配的物理資源（包括碼道數(shù)、時(shí)隙數(shù)等）。1.4.2.4 RB建立失敗導(dǎo)致RAB指派失敗1. 信令截圖 暫缺。2. 異常分析 RNC在分配物理資源后，下發(fā)RB建立，終端收到RB建立后上報(bào)RB建立失敗，若起呼點(diǎn)場(chǎng)強(qiáng)屬于中強(qiáng)場(chǎng)，則終端對(duì)于RNC下發(fā)的物理資源配置

16、可能存在不支持情況，如部分終端不支持伴隨信道復(fù)用，不支持上行多時(shí)隙、多碼道等?？墒褂貌煌酒瑥S商的終端進(jìn)行對(duì)比測(cè)試，或調(diào)整RNC分配的物理資源（包括碼道數(shù)、時(shí)隙數(shù)等）。1.4.2.5 其他原因?qū)е碌腞AB指派失敗 除空口超時(shí)以及資源分配失敗導(dǎo)致的RAB指派失敗外，還存在其他原因，如承載建立失敗，無線鏈路重配失敗等異常，會(huì)導(dǎo)致RAB指派過程執(zhí)行失敗，具體排查說明參考錯(cuò)誤碼中的相關(guān)內(nèi)容。1.5 承載調(diào)整中的異常1.5.1 總體描述此處的承載調(diào)整是指小區(qū)內(nèi)的物理資源（載頻、時(shí)隙）調(diào)整、業(yè)務(wù)速率改變、H2D、D2H等過程。1.5.2 典型信令過程1.5.2.1 空口超時(shí)導(dǎo)致的承載調(diào)整失敗1. 信令截圖

17、2. 重要信令解釋信令消息過程解釋RadioBearerReconfigurationRNC向UE發(fā)送無線承載重配置消息，將調(diào)整之后的無線承載通知UEIuReleaseRequestRNC向CN發(fā)送IU釋放請(qǐng)求消息，該消息用于RNC發(fā)起的UE釋放3. 異常分析參考RB建立超時(shí)導(dǎo)致的RAB指派失敗。1.5.2.2 RB重配失敗的承載調(diào)整失敗1. 信令截圖暫缺。2. 異常分析參考RB建立失敗導(dǎo)致RAB指派失敗。1.5.2.3 RB重配過程中小區(qū)更新導(dǎo)致的承載調(diào)整失敗1. 信令截圖暫缺。2. 異常分析參考RB建立過程中小區(qū)更新導(dǎo)致RAB指派失敗。1.5.2.4 RNC資源申請(qǐng)失敗導(dǎo)致的承載調(diào)整失敗

18、當(dāng)RNC物理資源不足時(shí)，網(wǎng)絡(luò)側(cè)收到上行或下行的4A測(cè)量報(bào)告時(shí)，則不會(huì)發(fā)起RB重配流程，維持當(dāng)前速率狀態(tài)。1. 信令截圖暫缺。2. 異常分析參考RNC資源申請(qǐng)失敗導(dǎo)致的RAB指派失敗。1.5.3 原因分析1.6 RNC內(nèi)切換過程中的異常1.6.1 總體描述RNC內(nèi)切換相關(guān)的異常主要有如下幾種典型場(chǎng)景：n 物理信道重配失敗：網(wǎng)絡(luò)側(cè)在下發(fā)physicalChannelReconfiguration消息后，終端回physicalChannelReconfigurationFailure消息，導(dǎo)致切換過程失敗，此類異常影響RNC內(nèi)切換成功率，但不會(huì)導(dǎo)致掉話；n 物理信道重配超時(shí)：網(wǎng)絡(luò)側(cè)在下發(fā)physic

19、alChannelReconfiguration消息后，終端沒有響應(yīng)，網(wǎng)絡(luò)側(cè)等待一段時(shí)間后，終端仍然未上報(bào)cellUpdate，超時(shí)后釋放，此類異常會(huì)同時(shí)影響切換成功率；n 小區(qū)更新后物理信道重配超時(shí)：網(wǎng)絡(luò)側(cè)在下發(fā)physicalChannelReconfiguration消息后，終端沒有響應(yīng)，網(wǎng)絡(luò)側(cè)等待一段時(shí)間后，終端上報(bào)cellUpdate，網(wǎng)絡(luò)側(cè)下發(fā)cellUpdateConfirm消息，終端響應(yīng)超時(shí)后釋放，此類異常會(huì)同時(shí)影響切換成功率；n 網(wǎng)絡(luò)側(cè)收到測(cè)量報(bào)告但未發(fā)起切換：網(wǎng)絡(luò)側(cè)收到終端上報(bào)的1G或2A測(cè)量報(bào)告，但未在目標(biāo)小區(qū)發(fā)起無線鏈路建立過程，也未向終端下發(fā)physicalChann

20、elReconfiguration，此類異常不會(huì)對(duì)KPI指標(biāo)造成直接影響；1.6.2 典型信令過程1.6.2.1 物理信道重配失敗1. 信令截圖：2. 信令分析：信令消息過程解釋measurementReport 網(wǎng)絡(luò)側(cè)收到終端1G/2A測(cè)量報(bào)告FpSAddReq 在目標(biāo)小區(qū)建立無線鏈路及承載，此案例中RL建立過程中夾雜了一條測(cè)量報(bào)告，該測(cè)量報(bào)告為2F測(cè)量報(bào)告，不影響切換過程，可以忽略；FpSAddRsp RadioLinkSetupRequest measurementReport RadioLinkSetupResponse FpSInitReq FpSInitRsp physicalCh

21、annelReconfiguration 網(wǎng)絡(luò)側(cè)向終端發(fā)起物理信道重配過程，終端回應(yīng)物理信道重配失敗，4失敗原因?yàn)槲锢韺油绞?，期間夾雜的測(cè)量報(bào)告為2F事件，不影響切換過程，可以忽略；RlmiUciuHelloForward RlmiUciuHelloFwdAck measurementReport measurementReport measurementReport physicalChannelReconfigurationFailureRadioLinkDeletionRequest 網(wǎng)絡(luò)側(cè)刪除目標(biāo)小區(qū)無線鏈路及承載；measurementReport RadioLinkDeleti

22、onResponse FpSRelReq measurementControl 網(wǎng)絡(luò)側(cè)重新向終端下發(fā)同頻及異頻測(cè)量控制消息或系統(tǒng)間測(cè)量；measurementControl OlpcParaInfo 原因分析及排查手段：查看PhysicalChannelReconfigurationFailure中攜帶的失敗原因，比如最常見的Failure cause為physical channel failure，表示UE無法在建立新的物理信道，即UE無法在新的信道配置上完成L1同步（UE在T312時(shí)間內(nèi)，收到N312個(gè)同步指示，即認(rèn)為新的信道建立成功）。造成這種現(xiàn)象的原因可能為物理信道所在的時(shí)隙干擾較大

23、，或目標(biāo)小區(qū)存在UP干擾。排查方法：n 查看各時(shí)隙干擾情況，如果發(fā)現(xiàn)時(shí)隙干擾很大，查看NODEB載扇是否正常，同時(shí)查看鄰小區(qū)是否有大量同頻鄰區(qū)，若在話務(wù)量小的情況下，ISCP仍然很高，則干擾可能來自異系統(tǒng)，如：GSM，PHS等；n 查看目標(biāo)小區(qū)UP干擾，若較大，則進(jìn)行UP位置偏移；n 時(shí)隙干擾經(jīng)常性偏大時(shí)，可以嘗試調(diào)低UE的上、下行開環(huán)功率；n 無效配置、配置不支持等配置錯(cuò)誤：換個(gè)手機(jī)測(cè)試，若各廠家手機(jī)測(cè)試都有問題，將本小區(qū)的重配消息和正常小區(qū)的重配消息進(jìn)行對(duì)比，查看配置是否正確；注：物理信道/RB重配失敗后測(cè)量控制下發(fā)說明：切換失敗后，RNC會(huì)重新下發(fā)測(cè)量控制消息，測(cè)量控制消息中攜帶鄰區(qū)列表

24、但不包含頻點(diǎn)擾碼等具體信息，如圖所示，因?yàn)橹暗臏y(cè)量控制消息中已經(jīng)攜帶了鄰區(qū)的擾碼、頻點(diǎn)等信息，UE側(cè)已經(jīng)保存了相關(guān)鄰區(qū)的詳細(xì)信息，因此網(wǎng)絡(luò)側(cè)不需要重新攜帶鄰區(qū)的詳細(xì)信息，只需要指示鄰區(qū)序號(hào)。1.6.2.2 物理信道重配超時(shí)信令消息過程解釋measurementReport網(wǎng)絡(luò)側(cè)收到終端1G/2A測(cè)量報(bào)告FpSAddReq在目標(biāo)小區(qū)建立無線鏈路及承載；FpSAddRspRadioLinkSetupRequestRadioLinkSetupResponseFpSInitReqFpSInitRspphysicalChannelReconfiguration網(wǎng)絡(luò)側(cè)向終端發(fā)起物理信道重配過程，定時(shí)時(shí)間

25、內(nèi)終端未發(fā)送物理信道重配完成消息，且在等待時(shí)間內(nèi)未上報(bào)小區(qū)更新；measurementReportUciuHelloForwardUciuHelloForwardAckSUciuMacMeasReportRadioLinkDeletionRequest網(wǎng)絡(luò)側(cè)刪除目標(biāo)小區(qū)無線鏈路及承載；RadioLinkDeletionResponseFpSRelReqIuReleaseRequest原因分析及排查手段：n UE收到了RECONFIGURATION消息，并發(fā)送了COMPLETE消息，但RNC未收到（上行功率不足或存在干擾等原因）；n UE收到了RECONFIGURATION消息，但沒發(fā)送COMP

26、LETE消息（消息錯(cuò)誤或UE內(nèi)部錯(cuò)誤等原因）；排查方法：n 若UE未收到重配消息：調(diào)整后臺(tái)下行最小發(fā)送功率，增加UE接收到重配消息的幾率，或者調(diào)整周圍網(wǎng)絡(luò)的覆蓋、頻點(diǎn)、功率等，盡量降低下行方向上的干擾；n 若網(wǎng)絡(luò)側(cè)沒有收到重配完成消息：則調(diào)整后臺(tái)DPCH的期望接收功率，同時(shí)利用網(wǎng)規(guī)網(wǎng)優(yōu)手段，降低上行方向上的干擾；1.6.2.3 小區(qū)更新后物理信道重配超時(shí)信令消息過程解釋measurementReport網(wǎng)絡(luò)側(cè)收到終端1G/2A測(cè)量報(bào)告FpSAddReq在目標(biāo)小區(qū)建立無線鏈路及承載；FpSAddRspRadioLinkSetupRequestRadioLinkSetupResponseFpSIn

27、itReqFpSInitRspphysicalChannelReconfiguration網(wǎng)絡(luò)側(cè)向終端發(fā)起物理信道重配過程，定時(shí)時(shí)間內(nèi)終端未發(fā)送物理信道重配完成消息，則等待終端上報(bào)小區(qū)更新；cellUpdate終端上報(bào)小區(qū)更新RadioLinkDeletionRequestRadioLinkDeletionResponseIuReleaseRequestIuReleaseCommandrrcConnectionReleaseIuReleaseCompletecellUpdaterrcConnectionReleasecellUpdateRadioLinkFailureIndicationrrc

28、ConnectionReleasecellUpdaterrcConnectionReleaseRadioLinkFailureIndicationRadioLinkDeletionRequestRadioLinkDeletionResponse原因分析及排查手段：可能原因?yàn)椋簄 UE未收到CONFIRM消息（下行功率不足或存在干擾等原因）；n UE收到了CONFIRM消息，并發(fā)送了COMPLETE消息，但RNC未收到（上行功率不足或存在干擾等原因）；n UE收到了CONFIRM消息，但沒發(fā)送COMPLETE消息（消息錯(cuò)誤或UE內(nèi)部錯(cuò)誤等原因）；排查方法：n 若UE未收到CONFIRM消息：調(diào)整

29、后臺(tái)下行最小發(fā)送功率，增加UE接收到CONFIRM消息的幾率，或者調(diào)整周圍網(wǎng)絡(luò)的覆蓋、頻點(diǎn)、功率等，盡量降低下行方向上的干擾；n 若網(wǎng)絡(luò)側(cè)沒有收到重配完成消息：則調(diào)整后臺(tái)DPCH的期望接收功率，同時(shí)利用網(wǎng)規(guī)網(wǎng)優(yōu)手段，降低上行方向上的干擾；1.6.2.4 網(wǎng)絡(luò)側(cè)收到測(cè)量報(bào)告但未發(fā)起切換1. 信令截圖：2. 信令分析：信令消息過程解釋measurementReport終端上報(bào)測(cè)量報(bào)告，在此案例中，測(cè)量報(bào)告為2A，實(shí)際情況中還可能出現(xiàn)1G測(cè)量報(bào)告的情況，但由于目標(biāo)小區(qū)物理資源不足或目標(biāo)小區(qū)存在異常導(dǎo)致無法分配資源，未發(fā)起RL建立及物理信道重配等后續(xù)流程；在此案例中，另一條測(cè)量報(bào)告為2F，2F事件不會(huì)

30、影響切換過程，可以忽略；measurementReportmeasurementControl網(wǎng)絡(luò)側(cè)重新下發(fā)同頻及異頻測(cè)量控制消息；measurementControl3. 原因分析及排查手段：一般為RNC資源申請(qǐng)失敗導(dǎo)致，如碼道資源不足，軟資源（功率、干擾）接納失敗等（此時(shí)信令跟蹤工具上沒有IUB口和空口消息）；可查看目標(biāo)小區(qū)剩余的碼道資源數(shù)看是否有足夠的剩余資源，并查看公共測(cè)量值和配置的接納門限，是否為功率干擾等軟資源受限。1.6.2.5 網(wǎng)絡(luò)側(cè)在RAB指派過程中收到測(cè)量報(bào)告1. 信令截圖：2. 原因分析及排查手段：RNC在收到CN RAB指派后，UE上報(bào)一個(gè)測(cè)量報(bào)告，但此時(shí)RNC在處理C

31、N RAB指派，無法同時(shí)處理測(cè)量報(bào)告，RNC緩存此條測(cè)量報(bào)告，等RAB指派完成后，在發(fā)起切換過程，由于此案例中測(cè)量報(bào)告中的目標(biāo)小區(qū)來自鄰RNC，因此發(fā)起了重定位流程。1.7 RNC間切換過程中的異常1.7.1 總體描述RNC間切換相關(guān)的異常主要有如下幾種典型場(chǎng)景，n CN側(cè)響應(yīng)RelocationPrepareFailure：n CN響應(yīng)超時(shí)；n CN響應(yīng)IuReleaseCommand；n 終端RB重配失敗；n 終端RB重配失敗；下面分別詳細(xì)描述各類異常發(fā)生的場(chǎng)景及原因，并給出對(duì)應(yīng)排查手段。1.7.2 典型信令過程及異常分析1.7.2.1 CN側(cè)響應(yīng)RelocationPrepareFail

32、ure1 異常描述當(dāng)S-RNC向CN發(fā)送Relocation Required消息后，CN向D-RNC發(fā)送Relocation Request，D-RNC側(cè)發(fā)起類似于業(yè)務(wù)接入的流程，分配信令、業(yè)務(wù)所需的物理資源，并建立無線鏈路及相應(yīng)承載，其中任何一個(gè)步驟發(fā)生異常，則會(huì)向CN響應(yīng)Relocation Failure消息，攜帶D側(cè)失敗的錯(cuò)誤碼，CN通過Relocation Preparation Failure消息透?jìng)髟撳e(cuò)誤碼到S-RNC，由于是重定位準(zhǔn)備階段流程發(fā)生異常，不會(huì)記入跨RNC切換失敗，因此不會(huì)影響任何KPI指標(biāo)，但此類異常會(huì)導(dǎo)致終端脫離源小區(qū)覆蓋而又無法切換，最終因覆蓋問題導(dǎo)致掉話。

33、2 信令過程由于比較難于搜集同一次跨RNC切換異常過程中S側(cè)和D側(cè)的信令，因此本部分未以截圖的形式給出行令流程。S側(cè)信令：信令消息過程解釋measurementReportRNC收到終端1G或2A測(cè)量報(bào)告，且目標(biāo)小區(qū)不歸屬于本RNC ，向CN發(fā)起重定位請(qǐng)求；RelocationRequiredRelocationPreparationFailureD側(cè)資源分配失敗，D側(cè)RNC向CN發(fā)送重定位失敗，CN向S側(cè)RNC發(fā)送重定位準(zhǔn)備失?。籱easurementControl向終端重新發(fā)送同頻/異頻測(cè)量建立消息；measurementControlD側(cè)信令：信令消息過程解釋RelocationRequ

34、est D側(cè)RNC收到CN發(fā)送的重定位請(qǐng)求，在D側(cè)進(jìn)行實(shí)例創(chuàng)建，承載建立、資源分配等操作，資源分配成功，則發(fā)起無線鏈路建立過程，如果其中某一步執(zhí)行失敗，如無線資源不足、承載建立失敗，則沒有無線鏈路建立過程；RadioLinkSetupRequestRNC發(fā)起無線鏈路建立，NodeB返回失敗；RadioLinkSetupFailureRelocationFailureRNC向CN發(fā)送重定位失敗消息，根據(jù)失敗的類型填寫消息中的錯(cuò)誤碼；IuReleaseRequestD側(cè)發(fā)起Iu連接釋放過程；IuReleaseCommandIuReleaseComplete3 原因分析及排查根據(jù)S側(cè)Relocati

35、on Preparation Failure消息或Relocation Failure消息中的錯(cuò)誤碼，參考非標(biāo)準(zhǔn)原因錯(cuò)誤碼對(duì)應(yīng)表中說明，進(jìn)行排查；1.7.2.2 CN響應(yīng)超時(shí)1 異常描述當(dāng)CN Iu口負(fù)荷過高或CN存在某種異常時(shí)，會(huì)不處理S側(cè)發(fā)送的Relocation Required消息，D側(cè)表現(xiàn)為看不到任何信令，S側(cè)在發(fā)送Relocation Required后會(huì)設(shè)置等待定時(shí)器，定時(shí)器時(shí)長(zhǎng)內(nèi)CN未響應(yīng)任何消息，則S側(cè)認(rèn)為對(duì)方狀態(tài)不可知，則發(fā)起Iu連接釋放過程，記作一次掉話，此類異常影響業(yè)務(wù)掉話率指標(biāo)。2 信令過程S側(cè)信令：信令消息過程解釋measurementReportRNC收到終端1G

36、或2A測(cè)量報(bào)告，且目標(biāo)小區(qū)不歸屬于本RNC ，向CN發(fā)起重定位請(qǐng)求；RelocationRequiredIuRelaseRequestCN在定時(shí)時(shí)間內(nèi)（典型配置為10s）未響應(yīng)，S側(cè)發(fā)起Iu連接釋放，釋放的原因?yàn)門RANAP_trelocprep_expiry，表示重定位準(zhǔn)備過程超時(shí)；IuReleaseCommandIuReleaseCompleteD側(cè)信令：D側(cè)未收到任何CN下發(fā)的信令消息。3 原因分析及排查需要確認(rèn)和CN的Iu口鏈路是否存在問題，如故障、擁塞等，重點(diǎn)在CN側(cè)排查問題。1.7.2.3 CN響應(yīng)IuReleaseCommand1 異常描述當(dāng)CN存在某種異常時(shí)，收到S側(cè)發(fā)送的Re

37、location Required消息，立即下發(fā)IuReleaseCommand，D側(cè)表現(xiàn)為看不到任何信令，此種異常不會(huì)導(dǎo)致任何KPI指標(biāo)異常，但會(huì)影響用戶感受。2 信令過程S側(cè)信令：信令消息過程解釋measurementReportRNC收到終端1G或2A測(cè)量報(bào)告，且目標(biāo)小區(qū)不歸屬于本RNC ，向CN發(fā)起重定位請(qǐng)求；RelocationRequiredIuReleaseCommandCN在很短時(shí)間內(nèi)（毫秒級(jí)）向S側(cè)下發(fā)IuReleaseCommand消息；IuReleaseCompleteD側(cè)信令：D側(cè)未收到任何CN下發(fā)的信令消息。3 原因分析及排查需要確認(rèn)和CN是否存在問題，如故障、擁塞等

38、，重點(diǎn)在CN側(cè)排查問題。1.7.2.4 終端RB重配失敗1 異常描述當(dāng)S-RNC向CN發(fā)送Relocation Required消息后，D側(cè)完成資源分配及建立過程，S側(cè)下發(fā)RB重配消息，由于終端在目標(biāo)側(cè)同步失敗，終端上報(bào)RB重配失敗消息，記作一次跨RNC切換失敗，此類異常影響系統(tǒng)RNC間切換成功率，此外該異常會(huì)導(dǎo)致終端脫離源小區(qū)覆蓋而又無法完成切換，最終因覆蓋問題導(dǎo)致掉話。2 信令過程S側(cè)信令：信令消息過程解釋measurementReportRNC收到終端1G或2A測(cè)量報(bào)告，且目標(biāo)小區(qū)不歸屬于本RNC ，向CN發(fā)起重定位請(qǐng)求；RelocationRequiredRelocationComma

39、ndD側(cè)RNC接納成功，通過RelcationCommand攜帶D側(cè)分配的物理資源；radioBearerReconfigurationRNC通過RB重配消息，將D側(cè)分配的資源信息通知終端；radioBearerReconfigurationFailure終端在目標(biāo)側(cè)物理層同步，或因?yàn)榕渲貌恢С值仍颍騍側(cè)RNC發(fā)送RB重配失敗消息；RelocationCancelS側(cè)RNC收到終端RB重配失敗消息后，向CN發(fā)送重定位取消，釋放D側(cè)分配的資源，并填寫對(duì)應(yīng)錯(cuò)誤碼；measurementControl向終端重新發(fā)送同頻/異頻測(cè)量建立消息；measurementControlRelocationC

40、ancelAcknowledgeCN向RNC發(fā)送重定位取消確認(rèn)消息D側(cè)信令：信令消息過程解釋RelocationRequestD側(cè)RNC收到CN重定位請(qǐng)求，分配資源；RadioLinkSetupRequest資源分配成功后，發(fā)起無線鏈路建立過程；RadioLinkSetupResponseRelocationRequestAcknowledge無線鏈路建立完成后，向CN發(fā)送重定位請(qǐng)求確認(rèn)消息，攜帶D側(cè)分配的資源，通過CN傳遞給S側(cè)；IuReleaseCommandS側(cè)RNC下發(fā)RB重配后，終端回應(yīng)RB重配失敗，S側(cè)RNC向CN發(fā)送重定位取消，CN向D側(cè)RNC發(fā)送的Iu釋放命令；RadioLin

41、kDeletionRequestD側(cè)釋放已經(jīng)分配的資源，并刪除無線鏈路；RadioLinkDeletionResponseIuReleaseComplete3 原因分析及排查排查方法參考物理信道重配失敗。1.7.2.5 終端RB重配超時(shí)1 異常描述當(dāng)S-RNC向CN發(fā)送Relocation Required消息后，D側(cè)完成資源分配及建立過程，S側(cè)下發(fā)RB重配消息，由于終端在目標(biāo)側(cè)同步失敗，終端上報(bào)RB重配失敗消息，記作一次跨RNC切換失敗，此類異常影響系統(tǒng)RNC間切換成功率，此外該異常會(huì)導(dǎo)致終端脫離源小區(qū)覆蓋而又無法完成切換，最終因覆蓋問題導(dǎo)致掉話。2 信令過程S側(cè)信令：信令消息過程解釋mea

42、surementReportRNC收到終端1G或2A測(cè)量報(bào)告，且目標(biāo)小區(qū)不歸屬于本RNC ，向CN發(fā)起重定位請(qǐng)求；RelocationRequiredRelocationCommandD側(cè)RNC接納成功，通過RelcationCommand攜帶D側(cè)分配的物理資源；radioBearerReconfigurationRNC通過RB重配消息，將D側(cè)分配的資源信息通知終端；IuReleaseRequestS側(cè)RNC等待CN下發(fā)的IuReleaseCommand超時(shí)，原因是定時(shí)時(shí)間內(nèi)終端未在D側(cè)上報(bào)RB重配完成消息，S側(cè)RNC向CN發(fā)送Iu連接釋放請(qǐng)求，發(fā)起Iu連接釋放過程。IuReleaseComm

43、andIuReleaseCompleteD側(cè)信令：信令消息過程解釋RelocationRequestD側(cè)RNC收到CN重定位請(qǐng)求，分配資源；RadioLinkSetupRequest資源分配成功后，發(fā)起無線鏈路建立過程；RadioLinkSetupResponseRelocationRequestAcknowledge無線鏈路建立完成后，向CN發(fā)送重定位請(qǐng)求確認(rèn)消息，攜帶D側(cè)分配的資源，通過CN傳遞給S側(cè)；IuReleaseCommandS側(cè)RNC下發(fā)RB重配后，定時(shí)時(shí)間內(nèi)終端無響應(yīng)，S側(cè)RNC向CN發(fā)送Iu釋放請(qǐng)求，CN向D側(cè)RNC發(fā)送的Iu釋放命令；RadioLinkDeletionReq

44、uestD側(cè)釋放已經(jīng)分配的資源，并刪除無線鏈路；RadioLinkDeletionResponseIuReleaseComplete3 原因分析及排查排查方法參考物理信道重配超時(shí)。1.8 CS系統(tǒng)間切換過程中的異常1.8.1 總體描述1.8.2 典型信令過程及異常分析1.8.2.1 重定位失敗1 信令過程2 原因分析及排查n TRANAP_relocation_failure_in_target_CN_RNC_or_target_system：在2G網(wǎng)絡(luò)側(cè)重定位失敗，原因不明，可能是GSM側(cè)資源分配問題； n TRANAP_unknown_target_rnc：可能原因如下：i. 23G CN

45、對(duì)接參數(shù)配置錯(cuò)誤：外場(chǎng)初期進(jìn)行23G測(cè)試時(shí)都是這個(gè)原因，正確配置后問題即可解決；ii. 在Not_BSICVerficationRequired配置，有時(shí)UE會(huì)上報(bào)非要求測(cè)量的頻點(diǎn)測(cè)量事件結(jié)果，也會(huì)出現(xiàn)此現(xiàn)象； n TRANAP_unspecified_failure：原因不明；1.8.2.2 UE返回handoverFromUTRANFailure1 信令過程2 原因分析及排查切換失敗的原因都為configurationUnacceptable時(shí)，目前認(rèn)為和UE能力有關(guān)，協(xié)議上規(guī)定，UE返回原因?yàn)閏onfigurationUnacceptable切換失敗的可能為：n UTRAN要求UE在不支

46、持的情況下進(jìn)行切換；或n UTRAN要求UE使用其不支持的配置；或n HANDOVER FROM UTRAN COMMAND消息中包含了信元“RAB information List”，并且這個(gè)信元不包含任何一個(gè)其信元“CN domain Identity”被設(shè)置為“CS domain”的信元“RAB info”。目前版本中HANDOVER FROM UTRAN COMMAND消息是不攜帶“RAB information List”信元的，因此應(yīng)該是和UE能力相關(guān)。1.8.2.3 UE上報(bào)CellUpdate1 信令過程2 原因分析及排查小區(qū)更新原因有以下幾種：1. TRRC_radiolin

47、kFailure：UE在收到切換請(qǐng)求后，如果無法接入GSM網(wǎng)絡(luò)，則會(huì)嘗試使用切換前的物理信道，如果無法同步上DCH則進(jìn)行原因?yàn)閞adiolinkFailure的小區(qū)更新，在出現(xiàn)的CS 23G切換失敗情況中；2. TRRC_re_enteredServiceArea：此原因比較奇怪，可能是不同廠家的UE實(shí)現(xiàn)方式不同，因?yàn)槿绻鸇CH同步失敗，應(yīng)該回原因radiolinkFailure；3. TRRC_rlc_unrecoverableError：原因不明，懷疑是UE回handoverFromUTRANFailure網(wǎng)絡(luò)側(cè)沒有收到；1.8.2.4 CN以非正常原因釋放IU原因不明，懷疑是3G CN沒

48、有收到2G CN的切換結(jié)束消息。1.9 PS系統(tǒng)間切換過程中的異常1.9.1 總體描述1.9.2 典型信令過程及異常分析1.9.2.1 CN下發(fā)正常釋放IU的消息3 信令過程4 原因分析及排查 2G核心網(wǎng)SGSN DNS錯(cuò)誤或者沒有配置3G SGSN地址解析，導(dǎo)致UE在收到Cell Change Order切換請(qǐng)求到2G網(wǎng)進(jìn)行路由更新時(shí)失敗，失敗原因?yàn)?Implicity_detached，之后UE重新進(jìn)行附著ATTACH在2G網(wǎng)絡(luò)接入GPRS業(yè)務(wù)，成功后HLR向舊的SGSN發(fā)送 CANCEL LOCATION，釋放T網(wǎng)中的用戶；表現(xiàn)在3G SGSN信令上為沒有收到SRNS 請(qǐng)求，收到CANC

49、EL LOCATION后正常釋放UE；無線側(cè)信令表現(xiàn)為下發(fā)Cell Change Order后，大概過715S收到CN下發(fā)的正常釋放IU消息；1.9.2.2 RNC主動(dòng)釋放用戶1 信令過程2 原因分析及排查原因及UE端處理的過程如典型信令5所述，可能為UE在進(jìn)行路由更新及ATTACH時(shí)間過長(zhǎng)，超過30S，導(dǎo)致RNC主動(dòng)異常釋放UE。1.10 保持過程中的掉話1.10.1 總體描述保持過程中的掉話是指用戶在掉話之前，未發(fā)起任何空口信令過程，或之前的信令交互過程已經(jīng)結(jié)束，處于穩(wěn)態(tài)下被網(wǎng)絡(luò)側(cè)發(fā)起Iu鏈接釋放過程。典型的保持過程中的掉話有用戶面RLC不可恢復(fù)錯(cuò)誤（Uciu Error）、NodeB上報(bào)

50、RL失敗、用戶未激活、用戶發(fā)起信令連接釋放指示等，此外用戶歸屬小區(qū)發(fā)生異常，如小區(qū)刪除、載頻不可用，或后臺(tái)發(fā)起小區(qū)公共資源重配，如小區(qū)公共信道重配，共享信道重配等。網(wǎng)絡(luò)側(cè)發(fā)起的保持過程中的掉話，在IuReleaseRequest消息中會(huì)攜帶釋放的原因碼或錯(cuò)誤碼，參考常見非標(biāo)準(zhǔn)原因錯(cuò)誤碼對(duì)應(yīng)表。保持過程中的掉話會(huì)影響對(duì)應(yīng)業(yè)務(wù)的掉話率指標(biāo)。1.10.2 典型信令過程1.10.2.1 UCIU ERROR導(dǎo)致的掉話1 異常描述RLC數(shù)據(jù)包的發(fā)送模式分為UM、AM、TM三種模式，分別為非確認(rèn)模式、確認(rèn)模式、透明模式。如果發(fā)送模式是AM模式，且該數(shù)據(jù)包打有polling標(biāo)志，終端在收到該數(shù)據(jù)包后需要向網(wǎng)

51、絡(luò)側(cè)發(fā)送ACK包，表示已收到，如果在定時(shí)間內(nèi)網(wǎng)絡(luò)側(cè)未收到終端ACK，則重發(fā)該數(shù)據(jù)包，并等待ACK，重發(fā)達(dá)到最大次數(shù)后，則向?qū)Χ藦?fù)位RLC層，RLC層復(fù)位后，對(duì)端任無響應(yīng)，繼續(xù)發(fā)起復(fù)位指示，如果已達(dá)到最大復(fù)位次數(shù)，則上報(bào)UciuError，指示對(duì)端RLC狀態(tài)不可知，網(wǎng)絡(luò)側(cè)發(fā)起Iu連接釋放請(qǐng)求。發(fā)生Uciu Error的RLC層數(shù)據(jù)有在SRB2或SRB3上傳輸?shù)腞RC信令或直傳消息，也有在DRB上傳輸?shù)臄?shù)據(jù)部分，可以通過用戶面上報(bào)的Uciu Error Ind指示中的RBid區(qū)別。2 信令過程n SRB2上的UciuErrorSRB2上發(fā)生的Uciu Error且直接導(dǎo)致RNC發(fā)起Iu釋放流程，大

52、多發(fā)生在如下場(chǎng)景：UE完成切換，下發(fā)多條測(cè)量控制消息，典型的場(chǎng)景下有7條，包括流量測(cè)量刪除/建立、2D/2F測(cè)量刪除，同頻測(cè)量（1G）建立、2條異頻測(cè)量建立（2A和2D/2F）、系統(tǒng)間測(cè)量（3A）。目前外場(chǎng)異頻鄰區(qū)配置數(shù)量較多，一般在15個(gè)以上，從切換完成后，網(wǎng)絡(luò)側(cè)向終端發(fā)送的數(shù)據(jù)總量看，一般在300byte左右，且該數(shù)據(jù)量與鄰區(qū)數(shù)量關(guān)系密切。由于所有測(cè)量都是采用AM模式發(fā)送的，如果是弱場(chǎng)情況下的切換，在空口質(zhì)量不好造成丟包，極易發(fā)生UciuError。案例一、UciuError伴隨CellUpdate失敗 在此案例中，UE切換完成后，網(wǎng)絡(luò)側(cè)下發(fā)了6條空口測(cè)量控制，順序?yàn)榱髁繙y(cè)量刪除、流量測(cè)量

53、建立、2D/2F異頻測(cè)量刪除、2D/2F異頻測(cè)量建立，同頻測(cè)量（1G）建立、異頻測(cè)量2A建立，如果該小區(qū)2/3G切換功能打開的話，還會(huì)下發(fā)一條系統(tǒng)間測(cè)量建立消息，近7秒后用戶面上報(bào)UciuError，在用戶面上報(bào)UciuError前，網(wǎng)絡(luò)側(cè)還收到了終端的一條測(cè)量報(bào)告，測(cè)量報(bào)告上報(bào)4s后，UE上報(bào)小區(qū)更新，原因?yàn)镽L失敗，場(chǎng)強(qiáng)為-90dBm，為弱場(chǎng)。從此案例分析看，弱場(chǎng)切換完成后，由于下行原因?qū)е翿NLU上報(bào)UciuError的可能性極高。信令截圖：案例二、UciuError伴隨RL失敗 在此案例中，UE切換完成后，網(wǎng)絡(luò)側(cè)下發(fā)了6條空口測(cè)量控制，用戶面上報(bào)UciuError，在用戶面上報(bào)UciuError前，NodeB上報(bào)RL失敗，從此案例分析看，切換完成后上行存在問題導(dǎo)致ACK包沒有反饋的可能性比較大，其中切換時(shí)目標(biāo)小區(qū)場(chǎng)強(qiáng)為-79dBm。信令截圖：案例三、UciuError不伴隨任何異常在此案例中，UE切換完成后，網(wǎng)絡(luò)側(cè)下發(fā)了6條空口測(cè)量控制，用戶面上報(bào)UciuError，在用戶面上報(bào)UciuError前，從信令流程上看不出上行還是下行出了異常，測(cè)量報(bào)告中目標(biāo)小區(qū)場(chǎng)強(qiáng)為-92dBm，從此案例看不出上行還是下行存在問題。案例四、UciuError前收到流量測(cè)量報(bào)告 在此案例中，UE切換完成后，網(wǎng)絡(luò)側(cè)下發(fā)了6條空口測(cè)量控制，用戶面上報(bào)