故障現(xiàn)象

某LTE項(xiàng)目在做LTE新建站點(diǎn)X2切換測(cè)試時(shí)，發(fā)現(xiàn)在觸發(fā)A3事件后，UE上報(bào)多次測(cè)量報(bào)告，卻一直沒(méi)有切換命令下發(fā)，最終出現(xiàn)切換掉話。

故障分析

UE側(cè)上報(bào)多次測(cè)量報(bào)告后，從eNodeB側(cè)看到在源eNodeB發(fā)起了X2口切換請(qǐng)求消息。過(guò)了幾秒后收到切換請(qǐng)求響應(yīng)。最后，目標(biāo)eNodeB沒(méi)有收到切換完成消息導(dǎo)致切換失敗。UE重建最終被拒，導(dǎo)致掉話。

1. 從CXT記錄的數(shù)據(jù)以及eNodeB側(cè)的信令記錄可知，在源eNodeB，從發(fā)起X2口切換請(qǐng)求消息，到收到目標(biāo)eNodeB發(fā)送的切換請(qǐng)求響應(yīng)，時(shí)間間隔將近3秒。對(duì)于切換準(zhǔn)備來(lái)說(shuō)，這個(gè)響應(yīng)時(shí)間太長(zhǎng)。通過(guò)CXT觀測(cè)，在此期間目標(biāo)小區(qū)的RSRP陡降了大約15dB，這直接導(dǎo)致目標(biāo)eNodeB無(wú)法收到切換完成消息。同時(shí)，可以看到目標(biāo)eNodeB的X2口出現(xiàn)了HANDOVER_CANCEL消息，此時(shí)表明切換已經(jīng)失敗。

2. UE在切換失敗后立即發(fā)起重新建鏈請(qǐng)求，從信令看重建已成功。但重建成功后由于UE一直沒(méi)有收到SRB2/DRB1的重配置消息，待到RLC最大重傳次數(shù)滿足后即釋放了用戶上下文，這時(shí)再發(fā)起重建肯定被拒而造成連接釋放，因?yàn)檫@時(shí)eNodeB已沒(méi)有了用戶上下文。

HANDOVER_REQUEST消息與HANDOVER_REQUEST_ACKNOWLEDGE消息之間的時(shí)間間隔過(guò)長(zhǎng)是造成切換失敗和掉話的原因，如下圖所示。


故障處理

1. 檢查這兩個(gè)eNodeB的硬件是否有告警。
例如：檢查RRU工作狀態(tài)是否正常？是否存在X2鏈路告警？以及小區(qū)是否被閉塞等情況。
檢查結(jié)果：沒(méi)有發(fā)現(xiàn)告警信息。

2. 檢查數(shù)據(jù)配置。
例如：檢查本eNodeB的切換門限和遲滯等是否有特殊的配置？以及相應(yīng)的鄰區(qū)是否配置，并且是否配置正確等。
檢查結(jié)果：兩個(gè)eNodeB均使用默認(rèn)參數(shù)配置，未發(fā)現(xiàn)數(shù)據(jù)配置問(wèn)題。

3. 使用UE分別在兩個(gè)小區(qū)下做下載業(yè)務(wù)，發(fā)現(xiàn)UE在目標(biāo)小區(qū)下吞吐率很差，DUmeter顯示存在裂縫和掉底（速率陡降，但是隨即恢復(fù)）。開始懷疑是傳輸存在問(wèn)題。

4. 使用Ping命令檢查eNodeB到服務(wù)器的時(shí)延。
發(fā)現(xiàn)其中一個(gè)eNodeB到服務(wù)器的Ping時(shí)延很大，并且十分不穩(wěn)定。

5. 在服務(wù)器側(cè)使用Wireshark工具進(jìn)行抓包分析。
經(jīng)過(guò)分析，發(fā)現(xiàn)確實(shí)存在該eNodeB到服務(wù)器的回包時(shí)延過(guò)大的情況。

6. 知會(huì)傳輸工程師進(jìn)行傳輸問(wèn)題檢查。
傳輸工程師反饋說(shuō)發(fā)現(xiàn)該站點(diǎn)當(dāng)天確實(shí)突發(fā)出現(xiàn)傳輸閃斷問(wèn)題。

7. 傳輸閃斷問(wèn)題處理后再次進(jìn)行相同測(cè)試，切換成功。

總結(jié)

在X2切換測(cè)試時(shí)，如果發(fā)現(xiàn)掉話問(wèn)題：
1. 首先需要檢查告警和數(shù)據(jù)配置。確保硬件無(wú)告警，數(shù)據(jù)配置正常。

2. 其次做信令分析。不單是看信令的流程是否正常，小區(qū)信號(hào)質(zhì)量是否正常，關(guān)鍵要看各信令點(diǎn)的信令到達(dá)時(shí)間。如果信令到達(dá)時(shí)間不正常，那么很有可能是傳輸存在問(wèn)題。

3. 這時(shí)候可以再進(jìn)行傳輸抓包分析確認(rèn)。最后定位問(wèn)題原因，解決問(wèn)題。