connect 失败_LTE 模式以及GSM模式下呼叫转移设置失败分析

问题：需要确定为何在IMS 上失败以及fall back to GSM retry，为何仍然报错？

QCAT 分析

QCAT 过滤0X1544(QMI_MCS_QCSI_PKT)qmi 消息，再找关键字：

voice_sups|query_|voice_get_|SS_sups_failure|failure_cause, 在问题时间点附近找到以下报错：failure_cause = QMI_FAILURE_CAUSE_ILLEGAL_SS_OPERATION

QXDM 分析

SS failed问题CM LOG关键点打印

>>CM supscmd 4, CM_SUPS_CMD_INTERROGATE 定义在cm.h 枚举enum cm_sups_cmd_e{…}

后面CM_ INTERROGATE_SS_CONF是对CM_ INTERROGATE_SS_REQ的确认，这样一对REQ/CONF 表示一个完整的请求-处理-响应过程。

SS 在IMS 失败原因分析

从截图log分析，因为IMS失败，IMS 模块要求去CS 上重试，最后由CM触发了ESR。

ESR (extend service request)OTA log:

在ESR前面，发现CM有如下打印：

fallback reason: 1 去代码里查发现cm.h里面定义：CM_IPSUPS_FAILURE_CAUSE_PDP_FAILURE,

至此触发ESR过程fallback to gsm的原因找到，应该是PDP_FAILURE导致tcp socket error，

需要进一步分析PDP异常的原因。

Check DS Fail

Error 26 Dss_errors_def.h DSS_ERROR_CONNECT_OPERATION_FAILED = 26

Error 49 Dss_errors_def.h DSS_ERROR_SHUTDOWN_OPERATION_FAILED = 49

SS 在GSM 失败原因分析

此例子中，触发了ESR, CSFB 到GSM上去，但是在CS上仍然失败，所以过滤UMTS OTA log，看是否与网络有交互，如下：

看到两条SS相关的信令：SS/Register, SS/Release Complete。

SS/Release Complete信令内容如下：

可以看到SS/Release Complete 信令携带了return_error_comp错误字段，且error_code[0]=16指明错误代码，因此下一步可以让方案商协助分析或者自己查看3GPP nas协议，确定是否是协议中定义场景。

SS 属于NAS 层业务，以上错误字段的定义请见协议24.080-f00-《Mobile radio interface layer 3-Supplementary services specification;Formats and coding》。

进一步，在以上SS/Release Complete OTA log 时间点附近过滤出以下trace log：

Wireshark分析"查询呼叫转移"状态的pcap包

LTE网络下，查询"呼叫转移"查询状态，UE使用HTTP GET方法与IMS侧AS(application sever)交互。方便协议分析，可以使用QCAT 工具将.isf文件转换成.pcap文件，然后使用Wireshark工具打开。尝试通过tcpdump工具在手机上去抓取，但是没有抓到相关包，疑问中！！

QCAT 时序图

通过QCAT的"View"-"Call Follow Analysis"工具可以看到模块之间的时序图，通过它能直观地看到所有与Call 相关的modem 模块的交互过程，可以帮助确定问题所在模块(层)。

以下为一个呼叫转移增值业务查询的时序截图：

a) CM模块下发CM_INTERROGATE_SS_REQ 给MN，

b) MN的CNM发送MMCNM_EST_REQ要求MM做连接建立动作

c) MM发送MS_MM_请求给RR

d) RR又发MPH_START_GSM_MODE_REQ给GL1(物理层)

…

一层层反馈，给client以XXX_CNF 确认消息

e) CM模块最终收到CM_INTERROGATE_SS_CNF 确认，流程完成。

CM_INTERROGATE_SS_REQ 触发：

CM_INTERROGATE_SS_CNF 确认：

结论：无论是IMS域还是CS域，从OTA信令以及错误码基本可以判断为核心网侧的问题。如果想深入继续深入分析，可以通过tcpdump 再抓取TCP/IP 完整数据包使用wireshark工具解析。