CDMA 1X 语音业务流程

前言：

本文主要介绍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

6、MO Call fail 分析

Call fail 的情形有很多种，我们以其中一种类型进行分析。
例如对于这种掉话的情况，或者如果Call在测试过程中掉话，或者是电话打不出去的情况，在OTA 看不到 第一条始呼消息，也就是UE没有始呼出去。有时候也可能是UE发起了始呼，但是没有成功，原因是没有收到网络确认的Order消息。

这时我们可以去CM层查看


这里我们可以查看到CM层中的EVENT和状态。对应MSG里面的参数，我们可以通过下载modem代码，并通过一些软件查看工具，如Source Insight去代码里查找对应的代码，如callevt =3, 是 “end” 的事件。

有些时候我们可以通过查看网络的信号来查看是否由于网络原因导致的Call fail

一般RSSI 小于-110就表明信号很差了。同事在androidqcril里也看查看当前的有效的网络，以及网络对应的信号强度。