三星i9008终端重庆问题分析报告.ppt

资源描述

《三星i9008终端重庆问题分析报告.ppt》由会员分享，可在线阅读，更多相关《三星i9008终端重庆问题分析报告.ppt（24页珍藏版）》请在三一办公上搜索。

1、三星中国通信研究院2011-06-02,三星i9008终端重庆问题分析报告,针对重庆移动提出的i9008终端问题，近期使用新版本(KD1)与老版本(JJ4)在重庆进行实地对比测试，复现相关问题。目前测试中出现的问题如下所列，下面逐一进行分析：问题1、老版本终端通话过程中死机，出现BD问题2、新版本测试中出现一次Call Mute问题3、新版本终端有一部比其他终端更容易出现3G到2G切换问题4、新版本终端出现一次掉话,测试背景和结果,问题1-现象描述,在重庆移动办公室复现终端问题，老版本终端在通话过程中发生死机现象从存储的log流程看，发生BD_HWLRF_2_4_1时终端正在TD网络下通话过程

2、中，由于网络配置了异系统测量，终端会按照测量控制配置测量GSM小区信号强度。,问题1-原因分析,根据log中保存的数据分析，由硬件锁存的2G帧中断与3G帧中断的距离连续两次相同。即图中2G_FN(M)帧与3G_FN(N)的距离为a,2G_FN(M+1)帧与3G_FN(N+1)帧的距离为b,a与b相等。但是由于TD-SDMA的子帧长为5ms,GSM帧长约为4.615ms,连续两帧的相对位置不可能相等。由硬件锁存的b值错误。2G帧中断与3G帧中断的距离用来进行2G与3G的时间同步计算,问题1-原因分析,硬件锁存错误的原因：寄存器读写时偶发的电平毛刺干扰，导致寄存器读写失败；硬件锁存错误导致的后果：

3、2G与3G时间同步计算错误，在两个连续3G帧读取到相同的2G帧号，使3G侧调度的2G活动执行时间重叠，引起2G的射频冲突，这样就导致了异常中断。具体过程如下图所示：硬件锁存错误发生概率较低，硬件跟踪复现困难。,问题1-原因分析,出错流程,问题1-结论,异常中断导致终端在通话过程中死机重启协议栈，导致掉话。解决方案：由软件增加保护措施，当检测到前后两次2、3G帧中断时间差相同时（例如上页图中3G侧连续两次读取的2G帧号为M），则对后一次的2、3G时间映射计算进行校正，从而使2G测量命令的执行时间不会重叠。该BD只出现在老版本上，新版本上已经合并了patch解决了该问题。在对比测试中新版本没有出现

4、该问题。,问题2-现象描述,在重庆移动办公楼测试语音电话过程中出现call mute,问题2-原因分析,1.通话时声音数据流程如下:a.MT to MO:1-1.MT to MO audio data flow b.MO to MT:1-2.MT to MO audio data flow2.该问题所抓的log文件MO.bin和MT.bin是CP的log。从log中可以解析出来通话时对应于上面的(1)(4)4点的4个音频文件,说明分别如下：MTs CP TX(1):MT_2G_TX.wav MTs CP RX(2):MT_2G_RX.wav MOs CP TX(3):MO_3G_TX.wav

5、MOs CP RX(4):MO_3G_RX.wav,问题2-原因分析,1.MO到MT方向:MOs CP tx(MO_3G_Tx.wav)和MTs CP rx(MT_2G_Rx.wav)一直都有声音，所以在MO和MT的CP之间MO到MT方向的数据没有问题：2.MT到MO方向：MTs CP tx(MT_2G_Tx.wav)从7:56(与MO的开始对应)开始一直都是静音，间夹杂着少量”Zizi”的声音，MOs CP rx(MO_3G_Rx.wav)从头到尾和 MT_2G_Tx.wav保持一样，所以说明在MT和MO的BP之间MT到MO方向的数据也没有问题，MT发出的声音就是静音(带有杂音)，所以对端

6、MO 听起来像mute，实际上不是。,问题2-结论,1.CP MO/MT双方的声音都能从对端CP log中正确还原；2.AP 虽然这次未抓到AP log，但经过分析对比，发现i9008之前在其他城市出现过一种mute问题，现象与此次类似。对比两次问题的CP log发现情况一致：CP侧语音收发正常；当时AP侧Log的分析结果表明：AP Audio DSP内存被覆盖，指针被置空，因此AP无法从CP侧正常读取/发送语音数据,从而导致MO/MT双方都听不到对端声音。-对比两次Mute问题，从现象到CP状态都非常相似，怀疑是相同的AP问题导致。针对这一问题我司已有patch，并进行了大量测试验证,计

7、划下次发布新版本时解决该问题。,问题3-现象描述,在重庆移动办公楼测试终端语音通话过程中发现，有一个新版本终端在测试中比其他终端更容易发生从3G到2G的切换。,问题3-原因分析,在CS RB建立成功后，网络会下发测量控制消息，给终端配置异系统测量的相关参数终端会启动异系统测量监控GSM临区信号强度，一旦满足3A事件触发条件，会上报3A事件测量报告给网络，网络下发切换命令，终端会根据切换命令配置切换到GSM小区上并保持语音通话。以下为测量控制中一个GSM临小区的参数，问题终端即容易向该GSM小区切换 interRATCellID 1,technologySpecificInfo gsm:int

8、erRATCellIndividualOffset 0,bsic ncc 6,bcc 7,frequency-band dcs1800BandUsed,bcch-ARFCN 72,问题3-原因分析,以下为触发3A事件相关的参数 event3a:thresholdOwnSystem-90,w 0,thresholdOtherSystem-86,hysteresis 8,timeToTrigger ttt5000,结合以上参数，在TD 服务小区RSCP低于-92,GSM临区RSSI高于-84，且满足该条件5秒钟的情况下，会上报3A事件测量报告,问题3-原因分析,经过抓取同一时间同一地点一对终端的l

9、og发现，保持3分32秒后，问题终端发生3到2切换，而正常终端始终保持在3G。正常终端切换前测量结果：TD ScellRSCP 44(-72dbm),GSM cell RSSI 58(-52dbm),UE Txpower 66 正常终端测量值始终较稳定，无论TD还是GSM小区，测量到的信号强度波动不大，始终未满足触发3A事件的条件。问题终端切换前测量结果：TD ScellRSCP 22(-94dbm),GSM cell RSSI 63(-47dbm),UE Txpower 88 问题终端的TD测量结果波动较大。在问题终端发生切换前，该终端与正常终端测量结果存在较大差异，且问题终端在切换前对TD

10、服务小区RSCP的测量结果会保持低于-92dbm，而该处GSM小区本身很强，超过5秒后终端发送3A测量报告。由于网络还配置了周期性上报发射功率的测量控制，网络侧应该也会监测到问题终端在切换前发射功率的增长。,问题3原因分析,校准原理和导致问题的原因相同型号的手机基于相同的硬件平台甚至是相同的设计，而这相同器件的平台有或多或少的偏差，由此而组合的手机性能就有一定的差异。因此，校准的目的是调整这种差异。但不能意味着校准通过的手机性能一定良好，因为校准过程也只是选择其中一些参考点来计算，而且还需要标准终测仪来验证这种差异是否合格。校准流程如下图所示：,问题3原因分析,校准对RX和TX分别进行。RX通

11、路，手机终端首先通过RF cable(如图所示）对终端测试仪的波形进行接收，然后通过RS232/USB 把这些经过手机射频前端的信号送给PC处理，得出接收通路的接收增益；同理，TX通路，手机终端首先发射信号到终测仪，然后终测仪会把接收来自经过手机射频前端的信号最后送给PC处理，得出发送通路的增益。校准的过程对信号（-25-116）分为若干段进行，并对每段又分为若干抽样点来进行拟合。3G切2G的图线来看，两端偏离较多，中间段跟正常的曲线又比较吻合，而正常的曲线两端的信号要稍强于中间段。从校准原理来看，可能在这个信号字段内的校准增益存在误差，而由此带来该射频前端在该信号字段内的敏感。,问题3-结论

12、,上报3A测量报告时从测量结果和触发时间看满足协议规定的参数，在满足参数设定的触发条件后才上报，从切换流程看协议栈软件处理正常，但问题终端的异常测量结果导致该终端与其他终端行为不同。由于该问题集中在一台终端，其他终端没有此问题，终端个体射频校准问题的可能性较大。从与正常终端的测量结果对比来看无论TD还是GSM差异都比较大，需要在实验室重新校准并确认校准数据正确写入终端Flash中，再在同样环境进行验证测试。,问题4-现象描述,新版本终端在语音通话过程中掉话,问题4-原因分析,主叫侧终端流程41018|11:01:06.561|974478|7357|L23RRC TRLC|TRA_SYS_SE

14、.129|1007245|3088|TMACL23RRC|TRA_SYS_SEND_TO_PC_IN|MAC_PCCH_IND|pagingType143299|11:02:07.129|1007245|3088|L23RRC TRLC|TRA_SYS_SEND_TO_PC_OUT|RLC_DATA_REQ|rrcConnectionRequest43405|11:02:07.350|1007245|3132|TRLCL23RRC|TRA_SYS_SEND_TO_PC_IN|RLC_DATA_IND|rrcConnectionReject:r3 rejectionCause congestio

15、n,waitTime 445361|11:02:11.365|1007245|3934|L23RRC TRLC|TRA_SYS_SEND_TO_PC_OUT|RLC_DATA_REQ|rrcConnectionRequest45442|11:02:11.531|1007245|3968|TRLCL23RRC|TRA_SYS_SEND_TO_PC_IN|RLC_DATA_IND|rrcConnectionReject:r3 rejectionCause congestion,waitTime 4,问题4-原因分析,被叫侧终端流程409702|01:49:35.452|1423143|4951|L

16、23RRCASALMF|TRA_SYS_SEND_TO_PC_OUT|RR_DATA_IND|SETUP_DOWN409734|01:49:35.452|1423143|4952|ASALMFL23RRC|TRA_SYS_SEND_TO_PC_IN|RR_DATA_REQ|CALL_CONFIRMED410831|01:49:37.131|1423143|5287|TRLCL23RRC|TRA_SYS_SEND_TO_PC_IN|RLC_DATA_IND|radioBearerSetup:later-than-r3411311|01:49:37.870|1423143|5435|L23RRC

19、_TO_PC_IN|RR_DATA_REQ|RELEASE_UP463501|01:50:28.893|1436132|7449|L23RRCASALMF|TRA_SYS_SEND_TO_PC_OUT|RR_DATA_IND|RELEASE_COMPLETE_DOWN463790|01:50:29.133|1436184|7497|TRLCL23RRC|TRA_SYS_SEND_TO_PC_IN|RLC_DATA_IND|rrcConnectionRelease:later-than-r3463791|01:50:29.133|1436184|7497|L23RRC TRLC|TRA_SYS_

20、SEND_TO_PC_OUT|RLC_DATA_REQ|rrcConnectionReleaseComplete,问题4-原因分析,主叫侧log缺少起呼过程，在正常语音通话保持过程中，测量到的服务小区RSCP和终端发射功率都比较稳定，掉话前下行数据无CRC错，突然收到网络下发的RRC链接释放消息，原因为unspecified。之后过了一分钟左右，收到寻呼，但RRC链接建立被拒绝，原因是congestion。被叫侧在主叫侧被释放后很快也收到网络下发的DISCONNECT消息，原因同样是unspecified，之后被叫侧正常释放。从UE侧的log来看，在掉话之前，下行无错包，但上行发射功率TX_P

21、ower 一直保持最大值25dBm来发送，时间提前量(Tadv)在掉话之前也是异常的大，有11chips.但在掉话之后重新RRC建立成功之后Tadv 恢复到 2chips。从物理意义上来讲，每个chip 映射到空间距离是243米。掉话之前的时间提前量 11243米，显然是异常值，并且对于定点测试来讲，显然是不合理的。在现场在同样地点又抓了一个正常的log来检查，且都是在10号小区，发现时间提前量都是保持在 1chip 左右，进一步说明网络侧在掉话之前给UE配置的时间提前量是异常的。,问题4-结论,在UE侧下行接收正常的情况下，NW侧配置的时间提前量值突然异常，UE根据这个时间提前量来发送上行数

22、据，而此时已经偏离了NW的检测窗，所以，NW一直无法正确接收UE发送来的上行数据，接收功率每况愈低。NW在接收数据不正常，功率较低的情况下，要求UE抬升发射功率，UE侧一直抬升功率并且已经保持在最大的25dBm发射功率，由于时间提前量仍然异常偏离NW的检测窗，NW还是无法正常接收，最终上行失步，NW不得不释放RRC链接，最终导致掉话。因此，建议网络侧跟踪检查此异常配置。在UE侧下行接收正常的情况下，UE根据接收到的SS计算时间提前量来发送上行数据，掉话前后且在同一小区提前量值差距比较大，而NW反馈已经没有了上行接收功率，据此推测上行发送数据已经偏离了NW的检测窗，NW无法正确接收UE发送来的上

23、行数据。NW在连续接收数据不正常的情况下，会要求UE抬升发射功率，掉话log里没有抓到抬升的过程，但可以看到UE侧发射功率已经保持在最大的25dBm，无法继续抬升，NW还是无法正常接收UE上行，最终上行失步，NW不得不释放RRC链接，最终导致掉话。,问题4-结论,问题的关键在于时间提前量开始的异常点，是由于终端突然处理不正常；还是由于网络一步步抬升而来所导致。对于前者，这个log 中，下行接收数据一直较好，说明接收到的SS解调应该是没有问题的，基本上可以排除因为是解调不对的SS而导致提前量异常的可能性，如果说是硬件突然处理不正常导致异常，概率也比较小；对于后者，网络侧没有给出有效信息来跟踪这个信息，但从UE掉话的log 中还是找出疑点，在掉话之前，时间提前量已经异常了（前后对比），并且很有可能已经在网络检测窗之外了，但时间提前量还是从一个方向往更大的方向调整，直到掉话。所以，建议网络侧可以查查在异常的情况下的SS调整策略。据网络侧反馈，上行接收突然没有信号，建议网络侧在检测此段时间是否存在强干扰或者其他干扰因素。,

展开阅读全文