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

三星中国通信研究院 2011-06-02,三星i9008终端重庆问题 分析报告,针对重庆移动提出的i9008终端问题，近期使用新版本(kd1)与老版本(jj4)在重庆进行实地对比测试，复现相关问题。 目前测试中出现的问题如下所列，下面逐一进行分析： 问题1、老版本终端通话过程中死机，出现bd 问题2、新版本测试中出现一次call mute 问题3、新版本终端有一部比其他终端更容易出现3g到2g切换 问题4、新版本终端出现一次掉话,测试背景和结果,问题1-现象描述,在重庆移动办公室复现终端问题，老版本终端在通话过程中发生死机现象 从存储的log流程看，发生bd_hwlrf_2_4_1时终端正在td网络下通话过程中，由于网络配置了异系统测量，终端会按照测量控制配置测量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-原因分析,硬件锁存错误的原因： 寄存器读写时偶发的电平毛刺干扰，导致寄存器读写失败； 硬件锁存错误导致的后果： 2g与3g时间同步计算错误，在两个连续3g帧读取到相同的2g帧号，使3g侧调度的2g活动执行时间重叠，引起2g的射频冲突，这样就导致了异常中断。具体过程如下图所示 ： 硬件锁存错误发生概率较低，硬件跟踪复现困难。,问题1-原因分析,出错流程,问题1-结论,异常中断导致终端在通话过程中死机重启协议栈，导致掉话。 解决方案： 由软件增加保护措施，当检测到前后两次2、3g帧中断时间差相同时（例如上页图中3g侧连续两次读取的2g帧号为m），则对后一次的2、3g时间映射计算进行校正，从而使2g测量命令的执行时间不会重叠。 该bd只出现在老版本上，新版本上已经合并了patch解决了该问题。在对比测试中新版本没有出现该问题。,问题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 flow 2. 该问题所抓的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 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发出的声音就是静音(带有杂音)，所以对端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，并进行了大量测试验证,计划下次发布新版本时解决该问题。,问题3-现象描述,在重庆移动办公楼测试终端语音通话过程中发现， 有一个新版本终端在测试中比其他终端更容易发生 从3g到2g的切换。,问题3-原因分析,在cs rb建立成功后，网络会下发测量控制消息，给终端配置异系统测量的相关参数终端会启动异系统测量监控gsm临区信号强度，一旦满足3a事件触发条件，会上报3a事件测量报告给网络，网络下发切换命令，终端会根据切换命令配置切换到gsm小区上并保持语音通话。 以下为测量控制中一个gsm临小区的参数，问题终端即容易向该gsm小区切换 interratcellid 1, technologyspecificinfo gsm : interratcellindividualoffset 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-原因分析,经过抓取同一时间同一地点一对终端的log发现，保持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服务小区rscp的测量结果会保持低于-92dbm，而该处gsm小区本身很强，超过5秒后终端发送3a测量报告。由于网络还配置了周期性上报发射功率的测量控制，网络侧应该也会监测到问题终端在切换前发射功率的增长。,问题3原因分析,校准原理和导致问题的原因 相同型号的手机基于相同的硬件平台甚至是相同的设计，而这相同器件的平台有或多或少的偏差，由此而组合的手机性能就有一定的差异。因此，校准的目的是调整这种差异。但不能意味着校准通过的手机性能一定良好，因为校准过程也只是选择其中一些参考点来计算，而且还需要标准终测仪来验证这种差异是否合格。 校准流程如下图所示：,问题3原因分析,校准对rx和tx分别进行。rx通路，手机终端首先通过rf cable(如图所示）对终端测试仪的波形进行接收，然后通过rs232/usb 把这些经过手机射频前端的信号送给pc处理，得出接收通路的接收增益；同理，tx通路，手机终端首先发射信号到终测仪，然后终测仪会把接收来自经过手机射频前端的信号最后送给pc处理，得出发送通路的增益。 校准的过程对信号（-25-116）分为若干段进行，并对每段又分为若干抽样点来进行拟合。3g切2g的图线来看，两端偏离较多，中间段跟正常的曲线又比较吻合，而正常的曲线两端的信号要稍强于中间段。从校准原理来看，可能在这个信号字段内的校准增益存在误差，而由此带来该射频前端在该信号字段内的敏感。,问题3-结论,上报3a测量报告时从测量结果和触发时间看满足协议规定的参数，在满足参数设定的触发条件后才上报，从切换流程看协议栈软件处理正常，但问题终端的异常测量结果导致该终端与其他终端行为不同。 由于该问题集中在一台终端，其他终端没有此问题，终端个体射频校准问题的可能性较大。 从与正常终端的测量结果对比来看无论td还是gsm差异都比较大，需要在实验室重新校准并确认校准数据正确写入终端flash中，再在同样环境进行验证测试。,问题4-现象描述,新版本终端在语音通话过程中掉话,问题4-原因分析,主叫侧终端流程 41018|11:01:06.561| 974478| 7357|l23rrc trlc|tra_sys_send_to_pc_out |rlc_data_req |measurementreport 41070|11:01:06.617| 974478| 7369| trlcl23rrc|tra_sys_send_to_pc_in |rlc_data_ind |rrcconnectionrelease : later-than-r3 releasecause unspecified 41071|11:01:06.626| 974478| 7369|l23rrc trlc|tra_sys_send_to_pc_out |rlc_data_req |rrcconnectionreleasecomplete 43293|11:02:07.129|1007245| 3088| tmacl23rrc|tra_sys_send_to_pc_in |mac_pcch_ind |pagingtype1 43299|11:02:07.129|1007245| 3088|l23rrc trlc|tra_sys_send_to_pc_out |rlc_data_req |rrcconnectionrequest 43405|11:02:07.350|1007245| 3132| trlcl23rrc|tra_sys_send_to_pc_in |rlc_data_ind |rrcconnectionreject : r3 rejectioncause congestion, waittime 4 45361|11:02:11.365|1007245| 3934|l23rrc trlc|tra_sys_send_to_pc_out |rlc_data_req |rrcconnectionrequest 45442|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|l23rrcasalmf|tra_sys_send_to_pc_out |rr_data_ind |setup_down 409734|01:49:35.452|1423143| 4952|asalmfl23rrc|tra_sys_send_to_pc_in |rr_data_req |call_confirmed 410831|01:49:37.131|1423143| 5287| trlcl23rrc|tra_sys_send_to_pc_in |rlc_data_ind |radiobearersetup : later-than-r3 411311|01:49:37.870|1423143| 5435|l23rrc trlc|tra_sys_send_to_pc_out |rlc_data_req |radiobearersetupcomplete 411462|01:49:38.101|1423143| 5481|asalmfl23rrc|tra_sys_send_to_pc_in |rr_data_req |alerting_up 414948|01:49:42.125|1425997| 6285|asalmfl23rrc|tra_sys_send_to_pc_in |rr_data_req |connect_up 415467|01:49:42.457|1426070| 6353|l23rrcasalmf|tra_sys_send_to_pc_out |rr_data_ind |connect_acknowledge 463090|01:50:28.579|1436063| 7385|l23rrcasalmf|tra_sys_send_to_pc_out |rr_data_ind |disconnect_down cause_value 9f -001- 03 bit(s) - class_normal_event: 0x01 - 9f -1111 04 bit(s) normal_unspecified = 0x0f (15) 463100|01:50:28.579|1436063| 7385|asalmfl23rrc|tra_sys_send_to_pc_in |rr_data_req |release_up 463501|01:50:28.893|1436132| 7449|l23rrcasalmf|tra_sys_send_to_pc_out |rr_data_ind |release_complete_down 463790|01:50:29.133|1436184| 7497| trlcl23rrc|tra_sys_send_to_pc_in |rlc_data_ind |rrcconnectionrelease : later-than-r3 463791|01:50:29.133|1436184| 7497|l23rrc trlc|tra_sys_send_to_pc_out |rlc_data_req |rrcconnectionreleasecomplete,问题4-原因分析,主叫侧log缺少起呼过程，在正常语音通话保持过程中，测量到的服务小区rscp和终端发射功率都比较稳定，掉话前下行数据无crc错，突然收到网络下发的rrc链接释放消息，原因为unspecified。之后过了一分钟左右，收到寻呼，但rrc链接建立被拒绝，原因是congestion。 被叫侧在主叫侧被释放后很快也收到网络下发的disconnect消息，原因同样是unspecified，之后被叫侧正常释放。 从ue侧的log来看，在掉话之前，下行无错包，但上行发射功率tx_power 一直保持最大值25dbm来发送，时间提前量(tadv)在掉话之前也是异常的大，有11chips. 但在掉话之后重新rrc建立成功之后tadv 恢复到 2chips。从物理意义上来讲，每个chip 映射到空间距离是243米。掉话之前的时间提前量 11243米，显然是异常值， 并且对于定点测试来讲，显然是不合理的。在现场在同样地点又抓了一个正常的log来检查，且都是在10号小区，发现时间提前量都是保持在 1chip 左右，进一步说明网络侧在掉话之前给ue配置的时间提前量是异常的。,问题4-结论,在ue侧下行接收正常的情况下，nw侧配置的时间提前量值突然异常，ue根据这个时间提前量来发送上行数据，而此时已经偏离了nw的检测窗，所以，nw一直无法正确接收ue发送来的上行数据，接收功率