真皮沙发~~~~

竹凳 顺便卖瓜子糖

附件呢？楼主赶紧传上来学习学习啊

下载,学习中..

附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢附件呢

1．测试过程中手机发起上行的PDPdeactivated消息
在DTFTP下载测试中，MS已成功登录FTPServer，并已经开始下载数据，FTP下载进度为9％，在经过一次小区重选后，我们发现在事件列表中有PDPDeactivated的消息，在层三消息中可以看到是手机发起的上行消息，之后的FTP下载不能继续进行，在一系列的Ping fail后，FTP掉线。
由于DT测试中掉线率是考核指标，对每一次的掉线事件都必须认真分析。针对此类事件，我们与CDS仪表厂商共同分析，认为发生这种情况可能有三种原因：一是手机在测试过程中电缆的某个接口发生了松动，这样手机可能会发出PDP去激活申请；二是手机本身存在一些问题；三是测试用的笔记本电脑可能存在一些问题。
由于上述几种情况都属于外在原因，不能代表网络的真实情况，在计算掉线时不应计算这种情况，在仪表生成的测试报告中需手工将手机上发PDP去激活而导致的掉线情况排除。但是手机上发PDP去激活消息后的一系列Pingfail会影响到DT测试的覆盖率，生成报告有相应的无覆盖的时间及记载里程，同样应手工排除手机上发PDP去激活情况对应的无覆盖里程。

2．登录服务器与开始下载数据之间发生小区重选导致掉线
DTFTP下载设置为循环下载，在某一次下载开始时，手机发起尝试连接FTPServer，经过用户名、密码验证后，成功登录FTPServer，之后发生小区重选。
登录服务器与开始下载数据之间发生小区重选的事件主要有三种表现形式。
①成功登录FTPServer之后发生小区重选，然后开始下载数据，可以正常下载数据直至全部下载成功，此类情况占多数比例。
②成功登录FTPServer之后发生小区重选，然后开始下载数据，不能下载数据，连续的PingSuccess后掉线，此类情况占少数比例。
③成功登录FTPServer之后发生跨LAC、RAC的小区重选，然后发生LAU、RAU，随后的下载数据无法完成，在连续的PingSuccess后掉线，此类情况占较少数比例。
在DTFTP测试中可能会遇到上述三种情况。在同样的由小区A重选至小区B时，多数会正常下载，偶尔也会发生不能正常下载的情况。此类问题CDS仪表厂商的分析为：Pingsuccess表明手机至服务器的IP链路是通畅的，只是FTP服务器程序与客户端程序的会话链路中断,因为处于下载阶段，而服务器在发生了小区重选后不再有任何数据下传，所以应该是服务器程序认为链路发生了某种异常从而终止了这个下载连接。由于手机至服务器的IP链路是通畅的，建议手工排除此类FTP掉线。在后续的验证测试中，笔者经过许多次的测试对比，发现此类情况可能与测试车速有关，在严格遵守GPRSDT的限速标准：小于45 km/h后，几乎不再发生此类掉线，但是严格限速之前，基本上每次测试都会发生一次此类掉线，所以将严格遵守GPRS限速标准作为解决此类问题的建议。

3．小区T3212值设置不一导致掉线
当同一个LAC下不同小区的T3212（周期性位置更新）值设置不一致时，在发生小区重选时会引发LAU、RAU（Periodicupdating）。目前现网将位置区LAC与路由区RA设置为一致，当发生LAU时必然触发RAU。频繁的LAU、RAU会导致DTFTP下载延迟加大，严重时会导致掉线。
此类问题的解决办法为：统一LAC区内所有小区的T3212值，尽量减少不必要的LAU、RAU次数。

4．WAPpagerefresh（页面刷新）中的问题
问题描述：GPRSCQT测试中的WAP页面刷新项目，在同一天测试的多个CQT点都发生第二次WAP页面文本刷新失败。
在测试过程中发现WAP页面刷新第二次总是失败后，笔者手工指定WAP网页刷新地址，随后的测试中第二次失败的问题消失。此类WAP页面刷新失败不属于网络故障，应在生成报告中手工排除。

5．GPRS PDPactivate fail问题
问题描述：GPRSCQT测试中的PDP激活测试项，在CQT点某酒店的测试过程中，GPRSPDPactivate失败多次。
在分析该CQT点PDP激活失败率高的原因时，发现其他CQT点的PDP激活指标都非常好，成功率达到100%，而该CQT点的PDP激活成功率只有67.3%，在对比不同CQT点的小区参数时发现，该CQT点的小区参数BS_PA_MFRMS与其他CQT点设置不一致，该CQT点此项参数值为2，而其他CQT点的参数值为5。工程经验建议：同片区域的此参数设为一个值。由此将该CQT点的小区参数BS_PA_MFRMS参数由原来的2改为5后，重启BTS，PDP激活失败的问题随之消失。

6．GPRS Ping测试出现不规则失败的问题
问题描述：在GPRSCQT测试中的Ping测试，出现不规则的多次Ping失败。从CDS测试仪表的GPRS时间图上看到，在进行Ping测试的同时，RLC层的流量明显增加，而理论上在GPRS时间图上不应该显示很多的RLC层的流量。据此，笔者怀疑在Ping测试的同时，测试仪表同时在运行一些其他的进程，而这些进程占用了GPRS流量，相应地影响了Ping测试的正常进行。从CDS仪表附加的数据抓包协议中，笔者的分析得到确认。
从Ping测试的记录中找到第一次Pingsuccess的时间记录，在数据协议中找到对应的时间点，手机与FTPServer的IP地址与设置相符。首先是MS向FTP Server发送Echo（ping）request，紧接着FTP Server下发相应消息：Echo（ping）reply 。但在Ping测试同时，以手机的IP地址为源地址向未知IP地址发出的连接，出现了多个未知的目的IP地址。
针对Ping测试中发现的许多未知IP地址，笔者对Ping测试的拨号网络做了相应的分析。GPRS拨号网络有两个：cmwap、cmnet，在cmwap上支持WAP、Kjava、WAP图铃、MMS等业务，在cmnet上支持Ping、FTPdownload/upload业务。目前笔记本＋数据卡使用GPRS方式登录Internet，使用的就是cmnet拨号网络。Ping测试是GPRSCQT测试中第一个使用cmnet拨号网络的测试项，拨通cmnet相当于连接上Internet，测试仪表使用的笔记本电脑中的Windows自动更新、杀毒软件自动更新、MSN等软件会自动发起搜索，这样无形中增加了GPRSRLC层的数据流量，同时也影响了Ping的正常测试。
将笔记本电脑的系统及软件的自动更新关闭后，Ping测试100%成功，在数据协议中也没有未知的IP地址。
经过共同分析及实际验证，Ping测试出现不规则失败的原因为测试仪表没有关闭自动更新功能，导致在拨通cmnet后自动连接Internet，影响了Ping的正常测试。此类的Ping失败也不属于网络故障，属于测试中的异常情况。

我花钱、大家看。

:lol :lol :lol

能再详细一些就好了。