1、【終端案例】部分CSFB終端在弱覆蓋環(huán)境下短信頻繁重發(fā)問題案例分析一、故障現(xiàn)象用戶反饋在使用過程中概率性出現(xiàn)短信重發(fā)現(xiàn)象，手機通信大師后臺關(guān)于中國移動M811的詳細情況如下：1. 地點：花都區(qū)三東大道飛翔商務(wù)大廈2. 終端：增城客戶手機；3. 網(wǎng)絡(luò)環(huán)境：所處4G網(wǎng)絡(luò)信號比較弱，但又不會自動轉(zhuǎn)到3G/2G網(wǎng)絡(luò)4. 測試過程：終端在未打開數(shù)據(jù)連接的情況下，從16：21分開始發(fā)送短信內(nèi)容到號碼為的接收端，手機短信界面一直顯示“正在發(fā)送.”，此時接收端則一直在接收短信“我們都要”的內(nèi)容，直到16：35分結(jié)束，此時接收端一共接收了163條短信，被測手機才提示短信發(fā)送成功。發(fā)送端和接收端的界面如下： =&

2、gt;二、故障原因分析2.1故障處理流程圖：2.2 復(fù)測情況使用主流CSFB手機：華為D2、iPhone 5S、移動M811（商用版）、移動M811（高通改良版）進行現(xiàn)場復(fù)測：注：高通修改嘗試次數(shù)和等待timer，將原始的每條240/5的發(fā)送頻率改為150/50，即modem只負責在網(wǎng)絡(luò)不回復(fù)ack的情況下retry 3次，而不是48次。其他廠家大部分是按照3次或者5次來設(shè)計的重發(fā)流程。高通發(fā)布了改良測試版。終端型號有無重發(fā)平均重發(fā)次數(shù)移動M811（商用版）有41.17移動M811（高通改良版）有9.67華為D2有2.75iPhone 5S無無2.3分析過程2.3.1終端側(cè)根據(jù)RIL Log分

3、析結(jié)論：由于終端一直未收到網(wǎng)絡(luò)給回復(fù)的ack，導(dǎo)致modem啟動重發(fā)機制。而modem重發(fā)設(shè)定240s的重試時間（5s一個周期），所以一條短信發(fā)到modem最多能重發(fā)240/5=48次。可以通過修改重試時間與周期來減少重發(fā)的次數(shù)，但是為什么沒有收到網(wǎng)絡(luò)回復(fù)的ack還需要網(wǎng)絡(luò)側(cè)來調(diào)查確認。在中國移動M811側(cè)通過撥號*1973461#進行ril log和modem log的捕獲，下面是modem log的分析過程：1、短信第一次發(fā)送后，終端定時等待網(wǎng)絡(luò)回復(fù)rp_ackMSG 08:21:51.867 wms.c 01496 Putting 100 WMS_CMD_MSG_SEND (client

4、 18, as_id 0, appInfo_ptr 0x0b9eecf8)MSG 08:21:51.902 wmscm_gw.c 00578 MO SMS Message Sent to MN 0MSG 08:21:51.902 wmsmsg.c 04214 wms_msg_send_gw() returns 0MSG 08:21:51.902 qmi_wms.c 03608 Ignoring send event until WMS_MSG_EVENT_SUBMIT_REPORT received2、終端未收到網(wǎng)絡(luò)回復(fù)的rp_ack, 流程進入重發(fā)。MSG 08:22:00.902 wmsm

5、sg.c 16972 got WMS_MO_RETRY_TIMER_SIGMSG 08:22:03.902 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIGMSG 08:22:05.902 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIGMSG 08:22:06.902 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIGMSG 08:22:06.902 wmscm_gw.c 00578 MO SMS Message Sent to MN 0/重新發(fā)送短信 MSG 08:22:06.902 wms

6、msg.c 04214 wms_msg_send_gw() returns 0 MSG 08:22:06.902 wmsmsg.c 17310 wms_msg_sent_gw for Record 03、收到NAS層error報告MSG 08:22:07.605 wmscm_gw.c 00361 Received NAS report for WMS MSG 08:22:07.606 wms.c 01891 got WMS_RPT_Q_SIGMSG 08:22:07.606 wmscm_gw.c 00140 Error during msg submit WMS_RPT_LL_ERRORMSG

7、 08:22:07.606 wmsmsg.c 15087 MO SMS Failure Cause Value = 212MSG 08:22:07.607 wmsmsg.c 14873 NAS error status: 1MSG 08:22:07.607 wmsmsg.c 06514 On LL_ERROR or SIP_TEMP_ERROR, retry allowed? 1/Lower層出現(xiàn)錯誤，導(dǎo)致短信重發(fā)。 MSG 08:22:07.607 wmsmsg.c 15193 Prepare to retryMSG 08:22:09.902 wmsmsg.c 16972 got WMS_M

8、O_RETRY_TIMER_SIGMSG 08:22:10.903 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIGMSG 08:22:11.903 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG/重新發(fā)送短信MSG 08:22:11.903 wmscm_gw.c 00578 MO SMS Message Sent to MN 0 MSG 08:22:13.903 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG MSG 08:22:14.903 wmsmsg.c 16972 got WMS

9、_MO_RETRY_TIMER_SIG MSG 08:22:15.903 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG MSG 08:22:16.903 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG /未收到網(wǎng)絡(luò)回復(fù)rp_ack，短信重新發(fā)送。MSG 08:22:16.903 wmscm_gw.c 00578 MO SMS Message Sent to MN 0 MSG 08:22:16.903 wmsmsg.c 04214 wms_msg_send_gw() returns 0 MSG 08:22:16.903 w

10、msmsg.c 17310 wms_msg_sent_gw for Record 0./這樣的重發(fā)流程一直進行了40多次，都未收到網(wǎng)絡(luò)回復(fù)的rp_ack，直到重試次數(shù)用完。MSG 08:25:42.913 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG MSG 08:25:43.913 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG MSG 08:25:44.913 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG MSG 08:25:45.913 wmsmsg.c 16972 got W

11、MS_MO_RETRY_TIMER_SIG MSG 08:25:46.915 wmsmsg.c 16972 got WMS_MO_RETRY_TIMER_SIG MSG 08:25:46.915 wmscm_gw.c 00578 MO SMS Message Sent to MN 0 MSG 08:25:46.915 wmsmsg.c 04214 wms_msg_send_gw() returns 0 MSG 08:25:46.915 wmsmsg.c 17310 wms_msg_sent_gw for Record 0 /最后一次重新發(fā)送仍未收到網(wǎng)絡(luò)回復(fù)的rp_ack，最終上報給上層短信發(fā)送

12、失敗。 MSG 08:25:46.545 qcril_qmi_sms.c 04003 RIL0qmi_cb qcril_qmi_sms_command_cb: msg_id (0x20) QMI_WMS_RAW_SEND_REQ MSG 08:25:46.545 qcril_qmi_sms.c 00958 RIL0qmi_cb qcril_mo_sms_cb: QMI_WMS_RAW_SEND_RESP received with error QMI_ERR_MESSAGE_DELIVERY_FAILURE短信發(fā)送失敗上報給上層后，framework層啟動重發(fā)機制，然后在modem又會重復(fù)以上

13、的流程，直到framework層最后一次重發(fā)返回發(fā)送成功。2.3.2終端側(cè)根據(jù)高通信令的分析結(jié)論：終端在發(fā)送短信的過程中，在收到網(wǎng)絡(luò)發(fā)送的cp ack消息后，網(wǎng)絡(luò)先發(fā)送rrc重配消息，在終端上報rrc重配完成后，網(wǎng)絡(luò)側(cè)沒有收到A5測量報告導(dǎo)致計時器超時，這時網(wǎng)絡(luò)下發(fā)rrc release消息釋放連接。終端重新搜網(wǎng)，最后重新登記在38350頻點。具體分析過程如下：1. 手機發(fā)送短信前工作頻點手機開始工作在38350頻點，289小區(qū)信號強度rsrp -107.252. 短信發(fā)送過程a) 手機發(fā)送短信內(nèi)容b) 網(wǎng)絡(luò)回復(fù)cp_ack3. 網(wǎng)絡(luò)進行RRC重配a) 網(wǎng)絡(luò)發(fā)送RRC重配消息RRC重配消息第一

14、個頻點為37900b) 終端回復(fù)RRC重配完成4. 網(wǎng)絡(luò)發(fā)送rrc release由于網(wǎng)絡(luò)下發(fā)了RRC release，導(dǎo)致終端RRC被釋放，隨后重新找網(wǎng)絡(luò)，仍然MSG 09501/02/12LTE RRC/High/CRP 05:12:46.172 lte_rrc_crp.c 02117 CRP: Processing Connection Release messageMSG 09501/00/12LTE RRC/Low/CRP 05:12:46.172 lte_rrc_crp.c 02223 CRP: Release cause is otherMSG 09501/02/12LTE RR

15、C/High/CRP 05:12:46.172 lte_rrc_crp.c 02253 CRP: redirectionInformation presentMSG 09501/00/12LTE RRC/Low/CRP 05:12:46.172 lte_rrc_crp.c 02265 CRP: LTE -> LTE frequency redirectionMSG 09501/00/12LTE RRC/Low/CRP 05:12:46.172 lte_rrc_crp.c 00579 CRP: Sent Connection Release Started IndMSG 09501/00/

16、12LTE RRC/Low/CRP 05:12:46.172 lte_rrc_crp.c 02993 CRP: Started connection release timer重定向之后還是搜索到38350頻點仍然在38350，搜索一段時間后，仍然在38350，沒有37900頻點的小區(qū)2.3.3 MME側(cè)信令跟蹤結(jié)論：從MME的信令來看，終端在不斷發(fā)起連接建立和釋放，在測試的4分鐘時間里，發(fā)起了42次連接的請求和釋放，兩次請求發(fā)起平均間隔6秒多，每次連接請求和釋放之間平均間隔1秒多。基本上SGS接口過來的downlink unidata（RP Ack）都是在UE CONTEXT RELEASE

17、 COMPLETE之后收到，此時用戶處于IDLE態(tài)，MME已無法下發(fā)此信令到終端，導(dǎo)致終端認為短信沒有發(fā)送成功，從而不斷重發(fā)而進行循環(huán)，最終240秒超時。按照協(xié)議正常短消息發(fā)送流程如下圖： 通過分析核心網(wǎng)的信令跟蹤，現(xiàn)在問題出在第9步，MME在收到第9部的downlink unidata消息之前就收到了enodeb發(fā)出的S1釋放消息，用戶變成了idel態(tài)，MME無法把downlink unidata消息透傳給手機，所以短消息流程失敗， 這種異常情況在短消息協(xié)議中有相關(guān)說明，“ 當發(fā)送或接受短信過程中，和用戶狀態(tài)變化沖突，例如用戶從忙的狀態(tài)變?yōu)榭臻e態(tài)，或發(fā)生切換，短信過程可能終止 ” 可以參照短

18、消息協(xié)議23040： When the transmission or reception of a short message coincide with a change of state in the MS, i.e. from busy to idle or from idle to busy, or during a handover, the short message transfer might be aborted 結(jié)論1、由于投訴地點LTE信號較差，導(dǎo)致終端上報A2事件啟動異頻測量，而基站下發(fā)的異頻37900頻點在投訴地點無信號(如下地圖所示附近無合適37900站點)，未上報A5的測量報告，導(dǎo)致基站側(cè)計時器超時將此終端重定向至高優(yōu)先級即37900頻點(rrc release)，此后終端回到idle態(tài)，導(dǎo)致MME透傳的ACK消息未收到。2、手機回到idle態(tài)后由于無合適的頻點為37900的小區(qū)信號，故終端又重選回頻點為38350的原小區(qū)，此后終端的短信重發(fā)機制導(dǎo)致了該流程重復(fù)進行。三、解決措施1、規(guī)范化終端的短信重發(fā)機制：目前發(fā)現(xiàn)中國移動M811的機制為每5秒重發(fā)，240秒超時；華為D2每5秒重發(fā)，30秒超時。需要將這些終端的短信重發(fā)機制規(guī)范，使用戶具備一致的用戶體驗；中國移動