CDMA 1X 语音业务流程二、OTA LOG 分析3、其它层MSG消息

68 阅读 0 评论 45 点赞

我是靠谱客的博主儒雅睫毛，最近开发中收集的这篇文章主要介绍CDMA 1X 语音业务流程二、OTA LOG 分析3、其它层MSG消息，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

前言：

本文主要介绍3GPP2 中CDMA 1x 语音呼叫流程，并从Modem software 的多个模块来分析成功呼叫一个Voice Call的事件和状态，并通过示例来介绍怎样查看Call Fail的原因。

一、1x 始呼语音呼叫全流程

流程说明： (以同MSC, 不同BSC间呼叫举例)
1. MS在空中接口的接入信道上向BS发送带层2证实请求的始发消息以请求业务.
2. BS收到始发消息后向MS发送基站证实指令.
3. BS构造一个CM业务请求消息并放入完全层3信息消息中将其发送给MSC, 带了被叫号码(IMSI、MDN)和业务选择, 业务选择表示此次呼叫的业务类型和无线口传输速率. 对于电路型呼叫, BS可以请求MSC分配首选的地面电路.
4. MSC给BSC回CC消息表示SCCP的连接已经建立, 对CR消息进行确认.
5. MSC给HLR发位置请求, CM对被叫号码进行分析.
6. MSC向BS发送指配请求消息, 以请求BS分配无线资源, 如果地面电路在MS和BS之间使用, 那么消息中将包括关于该地面电路的信息. 如果在CM业务请求中BS请求了首选的地面电路并且MSC可以支持该地面电路, 那么MSC将在分配请求消息中使用该地面电路；否则MSC将指配不同的地面电路. 指配无线通道类型 (从业务选择中分析得到), 指示无线口的速率和类型.
7. 如果有用于该呼叫的业务信道, 并且MS不在业务信道上, BS将在空中接口的寻呼信道上发送信道指配消息 (带MS 的地址)以启动无线业务信道的建立.
8. MS 开始在分配的反向业务信道上发送前同步码 (TCH 前同步).
流程说明： (以同MSC, 不同BSC间呼叫举例)
9. 获取反向业务信道后, BS将在前向业务信道上向MS发送带层2证实请求的基站证实指令.
10. MS收到基站证实指令后发送移动台证实指令, 并且在反向业务信道上传送空的业务信道数据 (空TCH数据).
11. BS向MS发送业务连接消息/业务选择响应消息, 以指定用于呼叫的业务配置, MS开始根据指定的业务配置处理业务.
12. 收到业务连接消息后MS响应一条业务连接完成消息.
13. 无线业务信道和地面电路均建立并且完全互通后BS向MSC发送指配完成消息, 并认为呼叫进入通话状态.
14. 如果是本局呼叫, HLR不去MSC分配漫游号码, 在ROUTINGINFO中带LOCALTERMINATION, 表示手机在服务请求MSC内. 对于本局呼叫, MSCMAP到VDB要求分配漫游号码 (TLDN), 然后再给CCB回响应.

二、OTA LOG 分析

由于我们是无法去分析基站和网络的数据，通常是针对手机数据进行分析。通过使用QXDM抓取手机log后，通过过滤OTA LOG, 我们首先是查看OTA的通话流程是否正确。使用QXDM抓取log的方法可参照“高通平台通话流程”一文。
为方便书写，以下用MO Call 表示始呼Call, 用UE表示移动台，用NW表示网络。一个成功的始呼Call 的OTA 流程包括如下:

其中点击每一条OTA LOG,会在下方显示这条log中的具体内容。

1、ATA LOG Access/Origination

msg_type = 4 (0x4) (Origination)
esn = 2159202449 (0x80b2d091) /*包括手机的ESN 和IMSI */
imsi_s[LO] = 2113392384 (0x7df7cf00) (748-002-3879)
service_option = 3 (0x3) (EVRC 8K Voice)

以下就只单独说明部分log中的参数。

2、Page/Order 网络回复Access/Origination

OTA LOG [0x1007/007] Page/Order 06:56:18.840

ack_seq = 3 (0x3)

msg_seq = 7 (0x7)

valid_ack = 1 (0x1)

imsi_s[LO] =2113392384 (0x7df7cf00) (748-002-3879)

order = 16 (0x10) (Base Station Acknowledgement Order)

可以通过ack_seq和msg_seq 或者 imsi 尾号找到这条order

3、Page/ExtendedChannel Assignment 回应Origination

网络信道分配，包含信道信息

OTA LOG Page/Extended Channel Assignment 06:56:19.180 Length:

msg_id = 21 (0x15) (Extended Channel Assignment)

ack_seq = 3 (0x3)

msg_seq = 0 (0x0)

imsi_s[LO] =2113392384 (0x7df7cf00) (748-002-3879)

4、Forward/Order回复Reverse//Order

OTA LOG [0x1008/001] Forward/Order 06:56:19.641 Length: 0008

ack_seq = 0 (0x0)

msg_seq = 0 (0x0)

order = 16 (0x10) (Mobile Station Acknowledgement Order)

5、Forward/ServiceConnect 网络发起服务连接

OTA LOG [0x1008/020] Forward/ServiceConnect 06:56:19.681 Length: 0031

msg_type = 20 (0x14) (Service Connect)

ack_seq = 7 (0x7)

msg_seq = 1 (0x1)

service_option = 3 (0x3) (EVRC 8K Voice)

6、Reverse/Order 回复网络的ServiceConnect

OTA LOG Reverse/Order 06:56:19.702 Length:

7、Reverse/ServiceConnect Completion MT 回复连接完成

OTA LOG [0x1005/014] Reverse/ServiceConnect Completion 06:56:19.741 Length: 0006

MSG [01002/01] Digital CallProcessing/Medium 06:56:19.861 rxtx.c 01881 Duplicate, Ack Reqd.Msg_seq: 1

所有OTA 的消息及其的参数取值在协议C.S0005-F_ v1.0_cdma2000_ 1x_UppperLayer_20121210中可查看到。

3、其它层MSG消息

CDMA中对Call 的处理主要是CallManager中完成，Call Manager会对call进行处理，并且下发命令到其他层进行处理，同时也会显示关于Call 当前的服务信息和mode信息等。在查看OTA log后我们接下来会主要关注CM，QCRIL和QMI等模块。

3.1 AndroidQCRIL

用UE打电话时，首先是在UI的电话软件中进行，因此call是首先通过UI下发，发到RIL层，再通过QMI消息发送给Modem.

MO Call 首先可以在Androidqcril层看到UI下发给QCRIL的始呼消息：REQUEST_DIAL

MSG [00063/02] AndroidQCRIL/High 06:55:59.416 qcril.c 05132 RIL[0][main] onRequest: UI --- RIL_REQUEST_DIAL (10) ---> RIL [RID 0,token id 1208, data len 12]

4. CM

接下来我们可以通过查看CM中的消息，能看到call orig 或者orig 的cmd。CM还会打印当前Call的type， mode, 以及serve type等

MSG [00005/02] Call Manager/High 06:56:17.220 cmcall.c 06884 =CM= cmcall_orig_proc start

5、 QMI
这里的call是UI发起的，因此是由AP侧发给BP侧，所以我们可查看RX来确认UE是否收到Call，以及Call 的type是否正确。
LOG [0x138E] QMI Link 1 RX PDU 06:56:03.028 Length: 0032
MsgType = QMI_VOICE_DIAL_CALL_MSG
calling_number = { 49, 48, 48, 48, 48 }
call_type = VOICE
service_type = VOICE_DIAL_CALL_SRV_TYPE_CDMA_AUTOMATIC