• 关于MTK平台CC相关的Log查询


    关于MTK平台CC相关的Log查询

    在外场问题中,经常会出现通话相关的故障。这里简单总结一下通话相关log的分析点:

     

    主叫方:主叫方,是指主动发起通话的一方。

    1. 初步定位问题,

    用户发起通话时,AP端的拨号指令最终会通过AT到达modem,所以可以通过查看radio_log中相关的拨号AT指令来判断问题出现在AP还是BP。

    11-04 11:06:06.397   484   487 D AT      : AT> ATD13711349140;

    11-04 11:06:06.397   484   487 D AT      : ATD13711349140;

    如果出现问题的时间点没有对应的ATD指令,可以推断AP端没有向Modem发送拨号指令,基本可以断定是AP的问题;如果ATD已经下发,可以将问题归属到modem端。

    • AP端,

    定位AP端的问题主要根据main_log来跟踪代码的执行流程。

    在MTK Androd平台上大致的执行流程如下:

    OutgoingCallBroadcast.java

    PhoneGlobals.getInstance().callController.placeCall(intent);

    CallController.java

    CallStatusCode status = placeCallInternal(intent);

    PhoneUtils.placeCall (***);

    PhoneUtils.java

    Connection = app.mCM.dial(phone, numberToDial);

    CallManager.java

    Result = basePhone.dial(dialString);

    GsmPhone.java

    Return mCT.dial(newDialString, uusInfo);

    cm.dial(*****,  obtainCompleteMessage(EVENT_DIAL_CALL_RESULT));

    此后,AP端通过RIL.java将拨号发送至libril,最终到达modem。

    • Modem端,

    Modem这边的问题主要通过modem log来排查:

     

    图表 A  MT端正常Modem log示例

    PS:可以通过AT+ECPI来查看当前的CC的状态。其中,各字段的值可以参考MTK  AT文档。

     

     

    被叫方:

    1、  粗步定位:

    Modem接收到寻呼消息时,会通过检测TMSI来判断是否是对于自身的寻呼。如果是,对其进行响应,并向AP上报RING。

    11-04 10:54:09.154   482   497 D AT      :

    11-04 10:54:09.154   482   497 D AT      : RING

    11-04 10:54:09.154   482   497 D AT      : AT< RING

    11-04 10:54:09.154   482   497 D AT      : RIL_URC_READER:RING

    11-04 10:54:09.154   482   497 D AT      : RIL_URC_READER Enter processLine

    11-04 10:54:09.154   482   497 D RIL     : Nw URC:RING

    11-04 10:54:09.154   482   497 D RIL     : receiving RING!!!!!!

    11-04 10:54:09.154   482   497 D RIL     : receiving first RING!!!!!!

    • AP端,

    RIL.java中接收到下层上报的RING信息之后,会通知CallTracker.java。此中,会将来电信息通知到在其中注册的Handler。

    一般而言,这期间一般没有什么问题。

    •  Modem端,

    正常MT端的modem log如下:

     

     

    图表 B  MO端正常Modem log示例

     

     

    通常的问题有如下:

    l  没有接收到Paging消息:

    [NW->MS] RRC__PAGING_TYPE1

    [3G SMART PAGING] Smart Paging Enable = 1,Level2 Enable = 0,Learning CN Domain = 2,SmartPaging_Available = 0,is_Risk_RNC = 1

    PGD_TMSI: 4B 54 B 1E

    Paging record 2 is for this UE.

    CN Paging: CS_DOMAIN, TMSI_TYPE, RRC_PagingCause_terminatingConversationalCall

    RRCE: Starts the timer RRCE_PendingPagingTmr_TIMER_ID for 3 seconds and 0 milliseconds

    MSG_ID_RATCM_RRCE_PAGE_IND

    MSG_ID_MM_RATCM_PAGE_IND

    MS is paged with TMSI_TYPE

    [MS->NW] MM__PAGING_RESPONSE

     

    以上是UE对Paging的正常响应,可以通过参看MM__PAGING_RESPONSE消息来检测UE是否对问题时间点的寻呼进行响应。

     

    PS: TMSI是MT与网络交互的过程中,网络给MT发送的一个临时的识别码。modem log中可以查看到:

    [RRM]  TMSI value 4b54b1e

     

  • 相关阅读:
    java8 快速实现List转map 、分组、过滤等操作
    Centos7系统备份与恢复
    BDI3000仿真器命令
    MIPS32地址映射和TLB
    三层交换机之报文转发流程
    三层交换机之搜索引擎
    三层交换机之端口丢包问题分析
    嵌入式Linux之虚拟内存管理
    Windows网络命令大全
    三层交换机之端口镜像(Mirror)
  • 原文地址:https://www.cnblogs.com/caidi/p/3542843.html
Copyright © 2020-2023  润新知