手机性能测试经验分享

上传人:博****1 文档编号:568677029 上传时间:2024-07-26 格式:PPT 页数:24 大小:244.50KB
返回 下载 相关 举报
手机性能测试经验分享_第1页
第1页 / 共24页
手机性能测试经验分享_第2页
第2页 / 共24页
手机性能测试经验分享_第3页
第3页 / 共24页
手机性能测试经验分享_第4页
第4页 / 共24页
手机性能测试经验分享_第5页
第5页 / 共24页
点击查看更多>>
资源描述

《手机性能测试经验分享》由会员分享,可在线阅读,更多相关《手机性能测试经验分享(24页珍藏版)》请在金锄头文库上搜索。

1、手机性能测试经验分享1,主叫流程2,通话切换3.常见问题主叫流程PS主主CSLinkchannelestablishmentrequestSynchronizationburstSynchronizationburstSABMCCCallProceedingRTdefinitioninformationrequestRTdefinitioninformationacknowledgeSCCHLinkchannelassignmentSCCHFACCH/SACCHUAFACCH/SACCHCCSetupFACCH/SACCHFACCH/SACCHFACCH/SACCHFACCH/SACCHRTf

2、unctionrequestFACCH/SACCHRTfunctionrequestresponse链路信道建立请求消息终端链路信道指配消息(信道的频点和时隙的位置)同步突发脉冲,在呼叫建立过程和切换建立时隙的频率和时间同步。启动多帧传输模式,设置异步通信对SABM的响应多帧通信建立建立呼叫的初始信息(承载能力,设施,主被叫号码)申请接受区域信息(终端切换的参数)向PS通告区域信息通知终端切换模式主叫呼叫流程对语音是否加密,密钥移动参数,是否需要鉴权,鉴权的算法,寻呼类型鉴权过程释放FACCH信道确认链路释放主叫屏幕开始进入计时界面和通话有关的硬件被打开,microphone,receiver

3、,ADPCM编码,主叫手机进入等待通话阶段主叫呼叫流程300f0020081a571a1a4426800044RT-L1pchinformationpaging消息(8bytes,从08开始)。最后的44则是CS的RSSI指示0.92240330002440039353438bfpmsendrssiindicationtoMMIPM层向MMI层发送RSSI信息2.125300f0020081a571a1a393aa00043RT-L1pchinformation2.12540330002430039353438bfpmsendrssiindicationtoMMI2.500502b000000

4、0c000000803837353931353035pmgetMOcallcommandfromMMI,pm从MMI得到主叫指令(用户在按了talk键)2.500400d00510300pmsendtchestablishrequesttoMM2.500340200b937MMgetTCHestablishmentreqfromPM2.500330200310300MMsendTCHestablishmentrequesttoRRMM向RT发送建立TCH的请求2.5003016000300RTL1startmonitL1开始找寻基站2.781304b009e01132e500139RTCS_I

5、D2.781304b009e01133e25014aRTCS_ID这个即是RSSI最好的CS2.953300f0020081a571855aa8160004eRTCSlinkcchreq手机向基站发送请求分配业务信道的请求3.470300f00200800000000000000004eRTCSlinkcchrereq重发请求4.453300f00200800000000000000004eRTCSlinkcchrereq5.860300400200701RT-L1primitive5.953300f0020081a571a1a7a34a0004bRT-L1pchinformation6.47

6、0300f0020081a571323a38100004aRT-L1pchinformation6.15630120004200801020212a0810000RT-L1lchassignmentL1向RT发送信道发配成功消息6.1883009000500RT-L1UwaveINDL1向RT发送U波检测成功信息6.21930200006 RTL2facchestreqRT向L2发送FACCH建立请求,下面是建业务通道,约定业务信道载频和时隙6.2192601003f81000000000000000000000000000000000000l2tol1datareq-facchL2向L1发送

7、FACCH数据传送请求6.23528010010020100froml1inffacch从L1收到FACCH6.2972701001001010002738100000000000000000000000000000fromL1datafacch6.297301900061103RTL2sacchestreqRT向L2发送SACCH建立请求6.2972600003f090000l2tol1datareqsacchL2向L1发送SACCH数据传送请求6.31328000010020000froml1infsacch6.3282700001001000002730b0000fromL1data-s

8、acch6.328301800071101RTMMtchestcfmorindRT向MM发送业务信道建立确认信息6.3283303003104000000MMgetTCHestablishmentconfirmfromRR6.34441160001pmsendccsetuprequesttocc发送ccsetup请求,说明pm发给ccsetup消息6.34435980000000003808ca40000000000000000000000000000.CCCS:SETUPCC向基站发送SETUP消息6.3602a0100012402l2iformatfacch6.36026010002040

9、0a200450101050403808ca46c0e0080303537l2tol1data req-(facch)L2向L1发送数据传输请求,通过FACCH传输6.37528010010020100froml1inffacch6.375260100020402a20038353538373134307009803837353931356.43827010010010100047181000000000000000000000000000000000000fromL1datafacch6.531270100100101000470c900450181020000000000000000000

10、0000000fromL1datafacch6.53135020045018102CCPM:CALL-PROCEEDINGCC的建立RT 消息/鉴权/释放FACCH6.54730220007RTCSfunctionreqRTfunctionrequest6.75030240043050910001517c0RTL1CSenckeysetRTencryptionkeyset6.766315f0007 RT-PMfuncfmRT向PM发送RTfunctionrequest确认信息6.781500b005101pmsendfunctionrequesttoMMMMfunctionrequest6.7

11、81340000a53dMMgetfunctionrequestfromPM6.844320600 MMgetauthreqfromnetMMauthenticationrequest6.844320700 MMsendauthrsptonetMMauthenticationrequestresponse6.8443401005102MMsendfunctionconfirmtoPMMMfunctionrequest确认信息鉴权成功后被叫网络开始和被叫进行连接6.9382b000011070104l2releaseindication6.938302300070101RTPMdrel7.172

12、2c0000450181011e028288l2sendtomsgtol3172350100450181011e028288CCPM:ALERT7.188504d00PM-ADPCMenter commu7.1882700001001000004084e5100fromL1data-sacch7.20327000010010000041a4fe001fromL1data-sacch7.2032d0000010600ffl2rxallifrmbeforesendingtol37.2032c000045018107l2sendtomsgtol37.203260000d10d0000l2tol1da

13、tareq-sacch7.20335070045018107CCPM:CONNECT当被叫向网络传送CCAlerting时主叫方听到回铃音当被叫向网络传送CCConnect时主被方开始正式通话如被叫没有和网络连接成功则会听到网络提示音根据以上,可以在测试MO时,我们无需听回铃音来判断主叫方是否与网络连接,只要看到计时开始就算成功MO一次.Alerting/connect切换基本介绍1)基站和手机都有权利发起切换。2)FER是怎么得到的:检验1.2s内即240帧的误帧数,它通过检测UW(识别字)中的16bit或32bit的数据是否正确,还有检验CRC是否正确,在通信信道里CRC是CI(逻辑信道标

14、识)SA+I共180bit数据产生的16bit的数据,在控制信道里它是由PR(前导码)CAC(公共接入信道)共170bit数据产生的16个bit的数据,其中PR在控制时隙中为了更好的实现位时钟同步,它的数据是固定不便的62bit的数据,通信信道里的PR为6bit。PS:在待机是FER值永远不会高于1。3)手机侧如何判断做什么切换:在此以手机侧发起切换为例子,当RSSI值波动不大,但FER很大时,说明收到干扰,但此时离原来的CS的距离没什么变化,只是这个TCH信道不能用,则一般执行TCH切换;当RSSI值下降,此时一般来说FER也会升高,则是说明原CS不能使用需要执行RECALL切换。无缝切换比

15、较特殊,在每个支持无缝切换的手机中会有一系列的参数来确定无缝切换的门限,总的说是还是看RSSI和FER来确定判断:RSSI: 强信号区- RSSI-1 当RSSI在某一瞬间跨区跳变则做无缝 次强区- RSSI-2 切换,3个门限依照不同的手机确定, 次弱区- RSSI-3 228的RSSI-1为40,RSSI-2为36FER:当在1.2秒内FER突然高于一个特定值时,手机做无缝切换。4)3种切换在流程上的区别:recalling切换在流程上和主叫流程相仿,只是少了Alerting和鉴权俩个步骤,而TCH切换因为不需要重新选择基站则不需要进行建链。无缝切换与recalling的区别:2ports

16、status,在新的链路上CCsetup之后断开原语音通道,所以无缝切换基本对用户通话不产生影响。基本介绍5)切换的典型log语句:在分析R200协议前,简单介绍一下Sanyoprotocol:(1)06:06140000330329001a401010RSSI-FER(No.1TCH)RSSI(33)andFER(03),(2)06:0677778301830b013383393534382c1801ba33为RSSI值,83为FER值39为待机切换目标基站电平值,35为待机电平切换值(开始寻找别的基站)34为通话电平切换值(开始寻找别的基站),38为通话切换目标基站电平值(3)06:073

17、3ca00TR306P(newCSmonitor)T/Ohandoverstart(普通切换)(4)06:073f00339e01123012033c00HandoverCCHMonitormonitorCS,CS-ID(9e0112301203)andRSSI(3c)(5)06:071201001900009e01105e2803cch_est_req切换的目标基站CS-ID(6)06:093e2e00000000000000Uwavetestingenddisplay信道检测,最后一位为00表示此信道没有干扰(7)06:10310701450185071c0691a203020101Res

18、ponsehandoverend(成功切换)基本介绍R200protocol:(1)2971.573302a0008RTdorecallinghandover开始做recalling切换(2)9.414315a000702RT-PMhandoverstart9.41431ca0008RTPORT1-PORT2monitorreq开始做seamless切换(3)42.15130c900201001RT-L1tchchangecompletedinseamless42.15130c9000701aaRT-L1tchchangecompletedinseamless42.16131cc000701R

19、TPORT1PMhandoverswitchorrecallend结束切换流程(5)248.80830270008RTPMhandoverstart200.16831ca0008RTPORT1-PORT2monitorreq开始做seamless切换200.16840330005422637333438d5pmsendrssiindicationtoMMI200.178443b0002a0pmsendhostartindicationtoMMI200.17830ca003201RTPORT2-PORT1monitorreq200.178800100011a45L1cchmonit寻找新的可用的

20、满足seamless切换的载频没有monit到任何合适基站如果找到会在次列出基站列表200.418300400f20dRT-L1primitive200.41831cc000100aaRTPORT1PMhandoverswitchorrecallend200.4284b390060b6pmsendmmihoendindwhenseamlesswaittch200.428506000200.43849480052180001a0pmsendccsmhoendreqinglobalfunction200.438359f000001010000CCCSlinkcchreq在找到新CS后,向新的CS做

21、业务信道分配请求886.014300f00200800000000000000003bRT-L1pchinformation886.0543004002007010aRT-L1primitive886.114300f00200800000000000000003bRT-L1pchinformation886.915300f00200800000000000000003cRT-L1pchinformation887.016300f0020081a571875258510003cRT-L1pchinformation887.1163011002008ffffffffff851000RT-L1nul

22、lscchinformation887.216300f00200800000000000000003cRT-L1pchinformation887.266300400f201RTCSlinkcchreq向该基站重新请求业务信道常见问题2.TR101P:200ms,4次超时结束切换Startconditions:WithoutunwantedsignalintheTCHdesignatedby“Linkchannelassignment”Stopconditions:“Synchronizationestablishment”reception887.647800c00140529400aL1i

23、ndicationuwavetoRT887.64730040020020100RT-L1primitive887.6573009000300aaRT-L1uwaveIND在获得业务信道以后,向该信道发送同步信息.887.657800a00054d0002L1esttch887.857300400f202RTCSlinkcchrereq重新请求信道在log中我们能发现在建链中存在大量的TR001和TR101超时,这个是无法避免的,但是他们的存在确实对手机在弱信号区的切换有很大的影响,常见问题3.掉话:1.网络主动断线引起掉话, 106.973 2d 00 00 00 02 7e 07 l2 rx

24、 all ifrm before sending to l3 106.983 27 00 00 00 00 04 06 8e 40 21 from L1 data -sacch 106.983 2d 00 00 00 03 43 01 l2 rx all ifrm before sending to l3 107.003 27 00 00 00 00 04 18 0d 24 00 from L1 data -sacch 107.003 2d 00 00 01 04 04 81 l2 rx all ifrm before sending to l3 107.003 2c 00 00 45 01

25、07 45 08 03 02 85 90 l2 send to msg to l3 107.003 26 00 00 00 04 b1 0d l2 to l1 data req -(sacch) 107.003 35 45 00 45 01 07 45 08 03 02 85 90 CC PM: DISCONNECT 此时的掉话往往没有征兆,突然断线,这个现象不是我们软件协议所能控制的,在现实log中此类的断线比例也不是很高,所以我们一般不对这种掉线分析。 2.新的TCH建立失败而掉话.(切换流程中)1)同步超时: 37.634 30 41 00 0e f2 0d RT TRMONITP Ti

26、mer Out 37.634 30 4b 00 9e 01 11 ae a6 02 RT CS_ID 37.634 30 4b 00 9e 01 11 ae a6 02 39 RT CS_ID 找到一个合适的基站 37.634 31 57 00 01 02 02 09 00 RT - CS link cch req 向该CS做建TCH请求 37.634 80 1c 00 02 03 L1 ready to tx scch 38.896 30 04 00 f2 01 RT CS link cch req 重新请求 38.896 80 1c 00 05 03 L1 ready to tx scch

27、 38.976 30 0f 00 20 08 00 00 00 00 00 00 00 00 36 RT - L1 pch information 38.996 80 11 00 07 0a L1 scch tx cfm 38.996 30 04 00 20 07 00 0a RT PM handover switch or recall end 切换停止 39.697 48 39 00 00 47 pm send ho end indication to MMI in HO 40.709 30 04 00 f2 14 RT CS link cch req 向该CS做建TCH请求 195.89

28、1 80 1c 00 02 05 L1 ready to tx scch 196.052 30 0f 00 20 08 00 00 00 00 00 00 00 00 3c RT - L1 pch information 196.082 80 11 00 07 0a L1 scch tx cfm . 211.263 80 12 00 04 01 0a aa 14 be 13 14 24 00 a2 18L1 rx NULL msg 211.303 50 63 00 f5 0a 02 00 00 00 04 08 211.303 50 5f 00 211.303 34 0a 00 51 0b 0

29、0 00 MM get PM a disc command TCH建立时间太长,超过PMTIMER(15S),从而掉话. 在切换中都要重新建立TCH,所以一半以上的掉话都是由于TCH建立失败而导致.常见问题3.switch back失败而掉话(切换不成功而switch back) 444.960 80 01 00 00 37 L1 cch monit 444.960 80 01 00 00 36 L1 cch monit 444.970 30 04 00 f2 0d RT - L1 primitive 444.970 30 41 00 0e f2 0d RT TRMONITP Timer Ou

30、t 没有合适的基站进行HO切换 444.970 80 0a 00 03 22 02 01 L1 est tch 445.922 30 04 00 f2 0c RT PM handover switch or recall end 445.922 48 39 00 00 22 pm send ho end indication to MMI in HO 445.922 50 60 00 447.023 30 04 00 f2 14 RT - L1 primitive 447.033 30 48 00 0d f2 14 RT TRDLRELP Timer Out SendRT“Radio-chan

31、neldisconnectioncomplete”在现实中有大半掉线情况由于switchback失败而导致.一般手机在弱信号区因为话音质量的降低而导致连续的切换,用来保证手机不掉话。所以我们在性能测试时会听到连续的DI-DI-声,在切换过程中如果切换不成功,手机可以重新回到原来的TCH信道上进行通话,因为即使是在切换过程中原来的通信的载频会一直发送同步信息到手机,此时手机只需要重新同步就可以切换到原来的载频,我们叫这种为SwitchBack。常见问题4.因为等待某些消息而触发定时器而导致掉线:259.41328010010020200froml1inf-facch259.45335b100CC

32、CS:RELEASE-COMPLETE259.4532400001108020001084545010e5a080285e6l2datareq259.61426010001023f8100000000000000000000000000000000l2tol1datareq-(facch)259.63428010010020200froml1inf-facch259.66435b500CCPM:RELEASE-COMPLETE259.6745008005008pmsenddiscrequesttoRT在上层协议里有很多的定时器,当在log中发现例如上面类似的“TC303PTIMEOUT”超时而

33、导致掉线的,则可以查阅相关资料来得到掉线的原因.5.协议流程的不健壮而导致掉话:流程一的修改:原先协议的处理:recallingHO(TCH建立失败)-转而做switchback(失败)掉话修改为:recallingHO(TCH建立失败)-转而做switchback(失败)-转而recallingHO(TCH建立失败)-转而做switchback(失败)-转而recallingHO流程二的修改:原先协议的处理:TCHSWITCHHO(失败)-转而做switchback(失败)-recallingHO(TCH建立失败)-转而做switchback(失败)掉话修改为:TCHSWITCHHO(失败)-转而做switchback(失败)-recallingHO(TCH建立失败)-转而做switchback(失败)-转而做recallingHO228手机在做3次切换,2次SwitchBack后仍然未成功切换后会掉话,如果在切换中还有其他超时的话,用户将听到大约30秒中的DI-DI声,但往往网络信号不会在30S内持续很弱,如果在这几十秒中信号恢复正常,这样使得手机又可以正常通话,这样掉话现象就会改善.常见问题Game Over谢谢各位

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 商业/管理/HR > 营销创新

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号