故障現(xiàn)象

某車企反饋車載物聯(lián)網(wǎng)終端4G下有時無法接收短信，導(dǎo)致車輛無法喚醒。查詢短信中心記錄，下發(fā)失敗原因有時是“用戶不在服務(wù)區(qū)”，有時是“用戶關(guān)機”。實際終端一直保持開機狀態(tài)。

故障分析

信令回溯分析

客戶反饋車載終端1759第一次出現(xiàn)短信下發(fā)失?。ǘ绦胖行挠涗浀淖R別原因值為“用戶不在服務(wù)區(qū)”），而且此后短信中心于17:53、17:54等時間多次重發(fā)始終失?。ǘ绦胖行挠涗浀淖R別原因值為“用戶關(guān)機”），如圖1所示。

回溯該終端的S1-MME接口信令，1759 MSC通過MME尋呼終端無響應(yīng)（對應(yīng)首次短信下發(fā)失?。?，后續(xù)終端恢復(fù)與MME信令交互，但短信重發(fā)一直失敗。由于信令回溯無SGs口信令，無法進一步分析。

模擬尋呼無響應(yīng)場景

此問題不太容易通過業(yè)務(wù)撥測復(fù)現(xiàn)，協(xié)調(diào)車企進行了模擬測試：終端進入空閑態(tài)后直接關(guān)電，給終端發(fā)短信，模擬尋呼無響應(yīng)場景，信令消息如圖2所示。

1925 主叫終端向車載終端發(fā)送短信，短信中心給UDM發(fā)送SRI消息，成功獲取車載終端當(dāng)前VLR信息。

1926 VLR通過SGs接口向MME發(fā)送Paging Request消息，攜帶短信業(yè)務(wù)指示，MME下發(fā)尋呼無響應(yīng)。

1935 VLR等待9秒后，通過SGs接口重發(fā)Paging Request消息，仍然無響應(yīng)。

1944 VLR等待9秒后，通過SGs接口向MME發(fā)Alert Request消息（此時VLR給短信中心返回失敗響應(yīng)消息）。

4.1944 短信中心給UDM發(fā)送REPORT SM DELIVERY STATUS REQUEST消息，攜帶原因值absentSubscriber，如圖3所示。

1943 短信中心重發(fā)短信，給UDM發(fā)送SRI消息，UDM返回MAP Error（absentSubscriber），短信下發(fā)失敗（短信中心記錄為用戶關(guān)機）。

1943 短信中心重發(fā)短信，結(jié)果同上。

5.1952 終端發(fā)起聯(lián)合附著流程，后續(xù)短信接收正常。類似的，如因?qū)ず羰。K端發(fā)起聯(lián)合TAU流程，短信業(yè)務(wù)也能自動恢復(fù)正常，如圖4所示。

短信重發(fā)始終失敗分析

6.通過對多個出現(xiàn)同樣短信業(yè)務(wù)長時間無法恢復(fù)問題的終端進行信令回溯分析，發(fā)現(xiàn)共同點：故障期間終端發(fā)送的TAU類型為TA Updating（純EPS TAU），而非正常的combined TA/LA updating（聯(lián)合TAU）。

經(jīng)與終端廠家聯(lián)合分析討論，獲知終端軟件版本有一個特殊設(shè)置：當(dāng)MME給終端發(fā)現(xiàn)TAU/Attach Accept消息中攜帶原因值#16 (MSC temporarily not reachable)時，終端會將其映射為#18 (CS domain not available)，進而變?yōu)镋PS Only模式，不再發(fā)起聯(lián)合TAU。沒有聯(lián)合TAU流程，MME無法向MSC更新用戶位置，MSC也無法向UDM更新用戶狀態(tài)，形成了死循環(huán)。

據(jù)終端廠家介紹，將#16 映射 #18是應(yīng)對2G退網(wǎng)的方案，在SGs口不可用時能讓終端仍然保持PS在線。鑒于當(dāng)前2G尚未正式退網(wǎng)，而車載終端又必須使用SGs短信，這種映射機制導(dǎo)致MT短信業(yè)務(wù)異常后無法自動恢復(fù)，不太合理。

故障處理

1.偶發(fā)尋呼失敗會導(dǎo)致短信下發(fā)失敗，只要終端恢復(fù)與MME交互，后續(xù)短信下發(fā)即可自動恢復(fù)，無需人工干預(yù)。如果終端較長時間未能恢復(fù)S1接口連接，短信重發(fā)可能有較大時延。

2.終端將#16映射為#18進而變?yōu)镋PS Only模式，造成短信業(yè)務(wù)始終無法自動恢復(fù)，通過重啟終端規(guī)避解決。后續(xù)終端廠家修改版本，取消原因值映射機制。