目錄

1 站內(nèi)切換，隨機接入失敗導致切換失敗
2 站內(nèi)切換，切換完成丟失導致切換失敗
3 X2切換，源側等待上下文釋放命令超時
4 X2切換，S1PathSwitch失敗導致切換失敗
5 切換隨機接入失敗觸發(fā)重建，重建重配失敗而掉話
6 eNB未響應UE切換測量報告，信道質(zhì)量惡化而掉話
7 切換命令丟失導致切換失敗
8 X2切換，Preamble丟失導致切換失敗
9 X2切換，目標側等待S1PathSwitchAck超時導致切換失敗
10 X2切換，隨機接入失敗觸發(fā)重建，重建完成丟而掉話
11 站內(nèi)切換，隨機接入失敗觸發(fā)重建，重建失敗而掉話

12 站內(nèi)切換，切換完成丟失觸發(fā)重建，重建失敗而掉話





可以通過CHR分析切換問題，以下舉例給出CHR分析切換問題的方法。

1 站內(nèi)切換，隨機接入失敗導致切換失敗

CHR中記錄的釋放原因值為

usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT，如下圖。


Step1：“掉話前最后10條信令”分析

備注：目前Insightsharp不支持解析“掉話前最后10條信令”，需要用內(nèi)部工具UMAT解析。

首先在CHR中找到本次掉話的CallID，再在UMAT中過濾出該CallID的相關記錄。從CHR記錄的掉話前最后10條信令可以看到，eNB等待切換完成5s定時器超時后向核心網(wǎng)發(fā)起釋放請求。



Step2: 分析L2_SRB_LOG，判斷UE是否收到切換命令

切換命令HARQ反饋為ACK，說明UE收到了切換命令，如下圖：





Step3：查找L2_L1_DEDI_PREAMBLE，分析切換隨機接入過程是否成功

專用Preamble收到了10條（Preamble最大重傳次數(shù)配置為10次），說明UE沒有收到RAR而進行了Preamble重傳，并且達到最大重傳次數(shù)10。

綜合以上分析可知，本次站內(nèi)切換失敗原因為隨機接入失敗。


2站內(nèi)切換，切換完成丟失導致切換失敗

CHR中記錄的釋放原因值為

usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT，如下圖。

Step1：“掉話前最后10條信令”分析

eNB發(fā)切換命令后未收到切換完成。（CHR獲取CallID，在UMAT中過濾出該CallID信息）





Step2: 分析L2_SRB_LOG，判斷UE是否收到切換命令

切換命令HARQ反饋為ACK，說明UE收到了切換命令，如下圖：




Step3：查找L2_L1_DEDI_PREAMBLE，分析切換隨機接入過程是否成功

專用Preamble收到了1條，說明UE發(fā)送一次Preamble即收到了RAR。

綜合以上分析，本次切換失敗原因為切換完成丟失。當然，也不能完全排除隨機接入失敗導致的切換失�。║E沒有收到RAR，而重發(fā)的Preamble eNB均沒有收到）。


3X2切換，源側等待上下文釋放命令超時

CHR中記錄的掉話釋放原因值為

usRelCause: UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAIL




Step1：“掉話前最后10條信令”分析

最后10條信令顯示：源側沒有收到目標側的X2上下文釋放命令，定時器超時（Timer 15s）釋放用戶。




Step2：切換流程分析

1）源側基站CHR的L2_SRB_LOG顯示切換命令HARQ反饋為ACK，說明UE收到了切換命令。

2）源側基站CHR的cell_RR_RSP字段中查找本次呼叫的CRNTI=630

3）目標側基站CHR的Ho In info字段中查找SRS CRNTI=630的話單。由于目標側站點CHR該時段信息已被沖掉，因此無法繼續(xù)分析。如果有目標側的信息，可以分析切換隨機接入是否成功，是否收到切換完成，etc。



4X2切換，S1PathSwitch失敗導致切換失敗

Step1：源側CHR分析

1）切換命令HARQ反饋為ACK，說明UE收到了切換命令


2）該UE在切換源側的CRNTI=1457；


3）切換測量報告中的RSRP：S_RSRP=-112dBm ；N_RSRP=-108dBm

4）“掉話前最后10條信令”分析：等待X2_Context_Rel_CMD超時釋放用戶，切換失敗。需要通過目標側CHR進一步分析切換失敗原因。


Step2：目標側CHR分析

1）過濾HoInInfo的usSrsCrnti字段，找到usSrsCrnti=1457的記錄，即為該UE本次切換的目標側信息。


2）“掉話前最后10條信令”分析：目標側收到了切換完成；由于核心網(wǎng)回復S1_PATH_SWITCH_REQ_FAIL導致切換失敗。


綜合以上分析可知，本次切換失敗原因為S1PathSwitch失敗，非無線側原因。


5切換隨機接入失敗觸發(fā)重建，重建重配失敗而掉話


Step1：“掉話前最后10條信令”分析，切換失敗重建回源側，eNB等待重建重配完成超時（5s）釋放用戶。


Step2：重建原因分析，切換隨機接入失敗觸發(fā)重建



6eNB未響應UE切換測量報告，信道質(zhì)量惡化而掉話

Step1: “掉話前最后10條信令”分析

UE不斷上報切換測量報告（切換目標小區(qū)PCI320），但eNB未下發(fā)切換命令（懷疑沒有配置鄰區(qū)關系）；從測量報告信息可知，UE所在服務小區(qū)下行信號較弱，RSRP~=-122dBm。





Step2：掉話原因分析

UEM_UECNT_REL_UE_RLC_UNRESTORE_IND /*L2上報RLC重傳次數(shù)達到最大值時的無法恢復指示消息*/

該釋放原因包括兩種場景：1）SRB RLC達最大重傳次數(shù)；2）DRB RLC達最大重傳次數(shù)。

L2_SRB_LOG記錄了L2檢測到異常前（比如，RLC達最大重傳次數(shù)）最后8條下行SRB的調(diào)度情況；

DRB_64MS（size=16）記錄了L2檢測到異常（比如，RLC達最大重傳次數(shù)）前16*64ms時間內(nèi)下行DRB的調(diào)度情況。

下圖顯示，掉話前SRB正常，隨后DRB出現(xiàn)大量NACK/DTX（DRB_64MS[4~16]均為NACK/DTX）。


綜合以上分析可知，eNB未響應UE切換測量報告，導致信道質(zhì)量惡化，DRB RLC達最大重傳次數(shù)而掉話（eNB檢測到RLC達最大重傳次數(shù)后約延遲30s釋放）。


7切換命令丟失導致切換失敗

CHR中記錄的掉話釋放原因值為5，即UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAIL


Step1：“掉話前10條信令分析”：源測等待上下文釋放命令超時而釋放用戶。


Step2：源測CHR分析：切換命令的HARQ重傳次數(shù)達到最大（ucHarqReTransTimes=4）且HARQ反饋狀態(tài)為2（DTX），說明UE沒有收到切換命令。


綜合以上分析：本次切換失敗的原因為切換命令丟失。

8X2切換，Preamble丟失導致切換失敗

CHR中記錄的掉話釋放原因值為5，即UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAIL


Step1：“掉話前10條信令分析”：源測等待上下文釋放命令超時而釋放用戶。


Step2：源測CHR分析：

（1）切換命令的HARQ反饋為1（ACK），說明UE收到了切換命令。

（2）通過RbCellRrRsp字段的usCrnti，確定源測的CRNTI=524。






Step3：目標側CHR分析：

（1）通過HoInInfo字段，查找usSRSCRnti=524的話單。

（2）目標側CHR無L1上報Preamble字段，L2_L3釋放Preamble與分配Preamble的間隔為2s，說明Preamble丟失。




綜合以上分析：本次切換失敗的原因為Preamble丟失。


9X2切換，目標側等待S1PathSwitchAck超時導致切換失敗




Step1：“掉話前最后10條信令”分析：源側等待上下文釋放命令超時釋放用戶。


Step2：源測CHR分析：

（1）切換命令的HARQ反饋為ACK，說明UE收到了切換命令。

（2）RbCellRrRsp字段顯示源測的CRNTI=1006





Step3：目標側CHR分析

（1）目標側CHR的HoInInfo字段，查找usSRSCRNTI=1006


（2）目標側最后10條信令顯示：目標側收到了切換完成消息，等待S1PathSwitchAck超時（15s）釋放用戶。


綜上所述：X2切換過程中，核心網(wǎng)未響應目標eNB的S1PathSwitchReq，導致切換失敗。

10X2切換，隨機接入失敗觸發(fā)重建，重建完成丟而掉話

CHR中記錄的重建原因值

ucRestCause：1 即Handover Failure。說明重建是切換失敗觸發(fā)的。


Step1：“掉話前10條信令分析”：切換失敗后，重建回源測，eNB等待重建完成消息超時（5s）下發(fā)重建拒絕，釋放用戶。


Step2：重建原因分析：隨機接入失敗觸發(fā)重建。



11站內(nèi)切換，隨機接入失敗觸發(fā)重建，重建失敗而掉話





Step1：“掉話前10條信令”分析

（1）測量報告中S_RSRP=-112dBm，N_RSRP=-110dBm

（2）源小區(qū)PCI=198，目標小區(qū)PCI=200，查找工參，發(fā)現(xiàn)源小區(qū)和目標小區(qū)在一個eNB內(nèi)，說明是站內(nèi)切換。

（3）UE切換失敗后觸發(fā)重建，重建失��；UE可能接入其他小區(qū)，導致MME主動發(fā)起釋放。


Step2：重建原因分析：隨機接入失敗觸發(fā)重建，重建到目標側。


Step3：源測CHR分析：切換命令的HARQ反饋為ACK，說明UE收到了切換命令。

Step4：目標CHR分析：L1上報Preamble次數(shù)為24次，說明UE沒有收到RAR，不斷上報Preamble。




綜合以上分析：本次切換失敗觸發(fā)重建的原因是RAR丟，重建失敗而掉話。


12站內(nèi)切換，切換完成丟失觸發(fā)重建，重建失敗而掉話





Step1：“掉話前10條信令”分析

（1）測量報告中S_RSRP=-103dBm，N_RSRP=-101dBm

（2）源小區(qū)PCI=314，目標小區(qū)PCI=313，查找工參，發(fā)現(xiàn)源小區(qū)和目標小區(qū)在一個eNB內(nèi)，說明是站內(nèi)切換。

（3）UE切換失敗后觸發(fā)重建，重建失�。籙E可能接入其他小區(qū)，導致MME主動發(fā)起釋放。


Step2：重建原因值分析：重建請求中ulCellId=1（PCI=313），說明重建到目標側。重建請求中攜帶的重建原因ucReestablishmentCause=2，即Other Failure。說明不是切換隨機接入失敗觸發(fā)的重建。


Step3：源測CHR分析：切換命令的HARQ反饋為ACK，說明UE收到了切換命令。

Step4：目標側CHR分析：L1上報收到Preamble次數(shù)為1，說明UE發(fā)送一次專用Preamble就收到了RAR，隨機接入成功。


綜合以上分析：本次切換失敗觸發(fā)重建的原因為切換完成丟，切換失敗后UE重建到目標側，重建失敗而掉話。