UMTS语音通话问题定位分析

1.引言

SS2-01项目上市后出现各种语音通话类问题，严重导致客诉、客退现象。

1.1 目的

通过本文介绍的语音问题分析定位方法，可使从事modem语音通话方面的相关同事更快、更精准的定位语音通话问题原因。

1.2 参考资料

【1】80-P0167-1EC_A_UMTS_GSM_Audio_Issue_Troubleshooting.pdf

 

2.Audio Issue定位方法

2.1语音数据的过滤和问题模块定位

       常见有两大类原因导致语音通话问题：第一种为多媒体模块处理后的音频出现异常而导致的语音问题，第二种为modem或者网络在处理和传输的过程中引入问题。首先介绍如何定位语音问题是那个模块引入的。

高通UMTS、GSM的音频包含如下三个模块：                                            

                                                                图2.1 modem取得的音频数据节点

以上行音频处理为例：

1. 首先终端从mic中收集到的上行语音数据会在多媒体模块进行处理，在日志中一般为PCM的格式存在。
2. 处理后的PCM语音数据为了匹配最终的空中接口，便于协议端的发送，需要进行信源编码，所以要经过ADSP（Vocoder）模块进行处理。
3. Vocoder模块处理完之后，最终将信源数据发送给modem协议栈，modem协议栈最终进行信道编码后发送给网络。

       从上面的音频处理流程就可以清晰的知道，其实modem拿到的音频数据，以及下行modem发送给音频处理模块的分水岭就是经过信源编码的vocoder packets音频数据，如下图：

       所以拿到Audio issue的问题日志时，我们首先要按照如下的方法确定问题是属于modem、网络引入的，还是属于多媒体模块处理本身就产生的问题。如下图用QCAT处理后的音频数据的4个节点，只有在节点2存在异常的时候是modem、网络引入的问题，其余节点出现异常均属于多媒体模块需要进行处理。                                                  

                                                        图2.3 QCAT处理后的音频数据节点

2.2Audio issue时间点的定位

       通过上述方案定位到问题为modem、网络存在异常后，接下来需要定位问题发生的时间点。精准的定位到问题发生时间点，才能正确的定位到问题发生的原因。而一般情况下测试所报的单通和断续问题，基本上是要研发这边去听语音通话内容，然后根据语音通话内容所在的相对时间点结合日志才能确定问题时间点。

    如下图首先在QCAT中过滤出空口日志和对应的Vocoder Packet日志，第一个Vocoder Packet包即对应此通电话的语音开始的绝对时间。                                

 QCAT过滤出来的音频数据，以下行的一段日志中的Rx音频数据为例：

diag_log_20160416_211346-diag_log_20160416_211819.isf.voc.rx，此段音频数据中包含了日志中所有通话的音频数据，所以首先要用音频播放器听出是第几通电话的第几分钟第几秒出现了问题，之后根据这通电话的在日志中的开始时间“+”从音乐播放器中听到的相对时间就可以定位到问题发生的时间点。

      如下是在第2通电话的4:10时间段出现了断续、听不清，那此时在日志中定位到的时间点就为13:15:01+(4:10-3:01)=13:16:10，之后在这个时间段去查看日志，定位问题。                         

                                                                        Cool Edit Pro 工具播放音频数据

3.Modem侧常见Audio Issue问题分析

3.1网络信号干扰引入的语音断续问题

       确定问题发生时间点之后，首先需要查看这个时间点通话时的信号质量，看看所在信道是否存在干扰，信噪比、BER和接收信号电平，一般多数情况下是因为网络信号质量比较差导致的Audio issue。其次查看，日志中的Vocoder Packet数据包，如果一直出现bad frame的指示，并且信号质量确实比较差，可以确定为网络原因导致。

       如下截图问题，很长一段时间下行的Rx Bad Frame Indicator =1，说明下行从网络拿到的音频帧都解析失败了，是坏帧，所以下行音频肯定异常。正常情况下，每20ms就会有一个语音帧，如果发现语音帧不是每20ms一个连续发送，则存在丢帧的可能，也会导致断续和短暂的单通问题的发生。                                                   

3.2 切换导致的断续问题

       GSM网络切换属于硬切换，即先与之前的小区断开连接后，再与新小区建立连接。所以在切换的过程中就有可能出现短暂的断续问题，尤其是当终端在通话过程中处于频繁切换的网络环境时，就会造成断续问题比较严重。

      为了说明为什么GSM切换会引入语音断续问题，可以从日志中看出GSM切换过程如下：

//通话过程中由于服务小区信号质量变差，邻区信号质量变好，手机收到网络下发的Handover Command消息。

02:34:46.573  [1C]  0x5B2F  GSM DSDS RR Signaling Message  --  Handover Command

02:34:46.573  rr_gprs_debug.c :IMsg: HANDOVER_COMMAND state RR_DATA_TRANSFER

 

//modem先停止和当前小区的L2的链接，并在L1配置要切换的目标小区的相关信息。

02:34:46.574  rr_gprs_debug.c  gs1:OMsg: DL_SUSPEND_REQ sent to L2

02:34:46.615  rr_gprs_debug.c  gs1:OMsg: MPH_HANDOVER_REQ sent to L1

02:34:46.615  l1_ded_if.c  gs1:MPH_HANDOVER_REQ to Cell 89 BSIC:42

 

//发起RACH并启动定时器，直到收到网络下发的Phy Info（RACH成功）或者定时器T3124超时（RACH失败）。

所以在这个状态下如果RACH很久没有成功，此时终端与网络之间处的状态是与之前小区已经断开连接，与新小区的连接还未成功建立，所以音频数据肯定无法正常传输。

02:34:46.675  rr_gprs_debug.c  gs1:OMsg: DL_RANDOM_ACCESS_REQ sent to L2

02:34:46.683  rr_inter_ho.c  04066  gs1:Starting T3124(320) TCH

LOG  GSM L1 Transmit Burst Metrics 02:34:46.688

Channel  = RACH

LOG  GSM L1 Transmit Burst Metrics  02:34:46.697

Channel  = RACH

……

MSG  02:34:46.808  rr_gprs_debug.c  04157  gs1:IMsg: PHYSICAL_INFORMATION state RR_DATA_TRANSFER

MSG  02:34:46.808          rr_inter_ho.c  04705  gs1:Stopping T3124

 

//RACH成功后，modem给网络发送HANDOVER_COMPLETE空口信令，但此时切换实质上并未真正的完成。

02:34:46.808          rr_inter_ho.c  00619  gs1:OMsg(NW,HANDOVER_COMPLETE(0)

02:34:46.809          [EF]  0x5B2F  GSM DSDS RR Signaling Message  --  Handover Complete

3.3网络异常发送homing Sequence

        正常通话过程中语音帧都是在不断的变化的，如果发现日志中的Vocoder Packet中的语音数据在很长的一段时间里是恒定不变的，或者只有几个数字在变化，这肯定是存在异常的。这种情况多数是因为网络侧存在异常，导致的在下行发送的Homing Sequence。

       不同语音编码格式的Homing Sequence如下，如果在日志中发现如下格式的网络发送的语音帧导致的下行无声，可以确定为网络异常：
AMR/NB：

1. { 0xF89D, 0x38CC, 0x0328, 0xF70F, 0xB182, 0x3D36, 0x0000, 0x0000, 0x0000,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},
2. { 0xF89D, 0x38CC, 0x03DF, 0xC062, 0xFB7F, 0x7F47, 0xBE00, 0x0000, 0x0000,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},
3. { 0xF871, 0x8BEF, 0x401E, 0xFE01, 0xCF60, 0x7CFB, 0xF803, 0xDC00, 0x0000,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},
4. { 0xF871, 0x8BEF, 0x4017, 0x01E2, 0x63E1, 0x60B8, 0xBC07, 0xB18E, 0x0000,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},
5. { 0xF871, 0x8BEF, 0x400D, 0xE036, 0x208F, 0xC4C1, 0xBA6F, 0x01B0, 0x0378,
   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},
6. { 0x6138, 0xC5F7, 0xA006, 0xFA07, 0x3C08, 0x7A5B, 0x1C69, 0xBC41, 0xCA68,
   0x3C82, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000},
7. { 0xF871, 0x8BD1, 0x4000, 0x0000, 0x00DA, 0xE4C6, 0x77EA, 0x2C40, 0xAD6B,
   0x3D80, 0x6C17, 0xC855, 0xC300, 0x0000, 0x0000, 0x0000, 0x0000},
8. { 0x0854, 0xDB96, 0xAAAD, 0x6000, 0x0000, 0x001B, 0x587F, 0x6683, 0x7940,
   0x9004, 0x1585, 0x4F10, 0xF6B0, 0x2403, 0xC7EA, 0x0000, 0x0000}

FR:
0x4820, 0xD617, 0x0284, 0x2480, 0x9249, 0x8924, 0x8002, 0x4924,0x2492, 0x0289, 0x2480, 0x9249, 0x8924, 0x8002, 0x4924, 0x2492, 0x0009

EFR:
0x085E, 0xB490, 0xFAAD, 0x603E, 0x3A18, 0x607B, 0x0C42, 0xC080,0x4805, 0x5800, 0x0000, 0x0000, 0x36B0, 0x0000, 0x0000, 0x0000, 0x0000

HR:
0x0371, 0xaf61, 0xc8f2, 0x8025, 0x31c0, 0x0000, 0x0000

AMR/WB:
1. {0x3100, 0x3800, 0x109c, 0x0130, 0x07f2, 0xfa22, 0xeb89, 0x8adb, 0x00d0,0x0000, 0x0000,   0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}
2. {0x0044, 0x000f, 0x550a, 0x5df1, 0x0f22, 0xd794, 0xfa01, 0x85a4, 0x44a7,0xc546, 0xe5e6, 0x0080, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000 }
3.{ 0x4650, 0x7700, 0xdeff, 0xf105, 0x675b, 0x8c8f, 0x70f7, 0xda07, 0xca82,0x5ad1, 0xde42, 0xc05a, 0xee44, 0x5ad3, 0x44e6, 0xd8d1, 0x0000 }
4. {0x18C1, 0xD40B, 0x90EB, 0xEF90, 0x080D, 0x203B, 0xD040, 0x2E94, 0x8000,0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000 }
5. {0x18C1, 0xEEC5, 0x36BA, 0x3A37, 0x9DE4, 0x41A7, 0x8C08, 0x0085, 0x21B2,0x2E0D, 0x8364, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}
6. {0x18C1, 0xEEC5, 0x36BA, 0x3A81, 0xC7E7, 0xF07C, 0x696D, 0x1693, 0x80C0,0x7C0F, 0x8041,        0x21FB, 0xB3F7, 0xB20E, 0xEDA5, 0x6CF8, 0x0000}

 

备注：补充一个小问题，如何判断此通语音通话采用的是那种语音编码格式呢？

终端通过QMI消息MsgType = QMI_VOICE_SPEECH_CODEC_INFO_IND上报给上层AP，本通电话所使用Speech Codec。

2016 Mar 14  11:18:04.217  [C4]  0x138F  QMI Link 1 TX PDU

   QmiVoiceSpeechCodecInfoIndTlvs[1] {

      Type = 17

      Length = 4

      SpeechCodecTypeTlv {

         Speech Codec = AMR_WB

      }

   }  

4.MTK平台Audio Issue问题定位

        MTK平台抓取的音频日志为后缀为.vm的日志，也是需要用工具处理后才能进行正常的播放，音频处理工具为Speech Analyzer，处理完之后的音频数据的所对应的音频节点如下图：

UL0.wav:进入MagiAIC的原始音频数据

UL1.wav DSP处理后的进入modem的音频数据

UL.wav是modem直接送给网络的音频数据

 

DL.wav 是下行链路直接传送给modem的音频数据

DL0.wav 是经过DSP处理后的音频数据

DL1.wav是语音话筒出来的音频数据

 

5.总结

        音频问题modem的协议栈引入问题的可能性不大，modem这边分析目的，主要是为了确定当时的网络是否存在异常。网络正常的情况下出现的音频问题，需要音频同事重点关注，必要时需要硬件同事协调，查看硬件的天线发射和接收性能。