1．測試過程中手機發(fā)起上行的PDPdeactivated消息
在DTFTP下載測試中，MS已成功登錄FTPServer，并已經開始下載數據，FTP下載進度為9％，在經過一次小區(qū)重選后，我們發(fā)現在事件列表中有PDPDeactivated的消息，在層三消息中可以看到是手機發(fā)起的上行消息，之后的FTP下載不能繼續(xù)進行，在一系列的Ping fail后，FTP掉線。
由于DT測試中掉線率是考核指標，對每一次的掉線事件都必須認真分析。針對此類事件，我們與CDS儀表廠商共同分析，認為發(fā)生這種情況可能有三種原因：一是手機在測試過程中電纜的某個接口發(fā)生了松動，這樣手機可能會發(fā)出PDP去激活申請；二是手機本身存在一些問題；三是測試用的筆記本電腦可能存在一些問題。
由于上述幾種情況都屬于外在原因，不能代表網絡的真實情況，在計算掉線時不應計算這種情況，在儀表生成的測試報告中需手工將手機上發(fā)PDP去激活而導致的掉線情況排除。但是手機上發(fā)PDP去激活消息后的一系列Pingfail會影響到DT測試的覆蓋率，生成報告有相應的無覆蓋的時間及記載里程，同樣應手工排除手機上發(fā)PDP去激活情況對應的無覆蓋里程。

2．登錄服務器與開始下載數據之間發(fā)生小區(qū)重選導致掉線
DTFTP下載設置為循環(huán)下載，在某一次下載開始時，手機發(fā)起嘗試連接FTPServer，經過用戶名、密碼驗證后，成功登錄FTPServer，之后發(fā)生小區(qū)重選。
登錄服務器與開始下載數據之間發(fā)生小區(qū)重選的事件主要有三種表現形式。
①成功登錄FTPServer之后發(fā)生小區(qū)重選，然后開始下載數據，可以正常下載數據直至全部下載成功，此類情況占多數比例。
②成功登錄FTPServer之后發(fā)生小區(qū)重選，然后開始下載數據，不能下載數據，連續(xù)的PingSuccess后掉線，此類情況占少數比例。
③成功登錄FTPServer之后發(fā)生跨LAC、RAC的小區(qū)重選，然后發(fā)生LAU、RAU，隨后的下載數據無法完成，在連續(xù)的PingSuccess后掉線，此類情況占較少數比例。
在DTFTP測試中可能會遇到上述三種情況。在同樣的由小區(qū)A重選至小區(qū)B時，多數會正常下載，偶爾也會發(fā)生不能正常下載的情況。此類問題CDS儀表廠商的分析為：Pingsuccess表明手機至服務器的IP鏈路是通暢的，只是FTP服務器程序與客戶端程序的會話鏈路中斷,因為處于下載階段，而服務器在發(fā)生了小區(qū)重選后不再有任何數據下傳，所以應該是服務器程序認為鏈路發(fā)生了某種異常從而終止了這個下載連接。由于手機至服務器的IP鏈路是通暢的，建議手工排除此類FTP掉線。在后續(xù)的驗證測試中，筆者經過許多次的測試對比，發(fā)現此類情況可能與測試車速有關，在嚴格遵守GPRSDT的限速標準：小于45 km/h后，幾乎不再發(fā)生此類掉線，但是嚴格限速之前，基本上每次測試都會發(fā)生一次此類掉線，所以將嚴格遵守GPRS限速標準作為解決此類問題的建議。

3．小區(qū)T3212值設置不一導致掉線
當同一個LAC下不同小區(qū)的T3212（周期性位置更新）值設置不一致時，在發(fā)生小區(qū)重選時會引發(fā)LAU、RAU（Periodicupdating）。目前現網將位置區(qū)LAC與路由區(qū)RA設置為一致，當發(fā)生LAU時必然觸發(fā)RAU。頻繁的LAU、RAU會導致DTFTP下載延遲加大，嚴重時會導致掉線。
此類問題的解決辦法為：統(tǒng)一LAC區(qū)內所有小區(qū)的T3212值，盡量減少不必要的LAU、RAU次數。

4．WAPpagerefresh（頁面刷新）中的問題
問題描述：GPRSCQT測試中的WAP頁面刷新項目，在同一天測試的多個CQT點都發(fā)生第二次WAP頁面文本刷新失敗。
在測試過程中發(fā)現WAP頁面刷新第二次總是失敗后，筆者手工指定WAP網頁刷新地址，隨后的測試中第二次失敗的問題消失。此類WAP頁面刷新失敗不屬于網絡故障，應在生成報告中手工排除。

5．GPRS PDPactivate fail問題
問題描述：GPRSCQT測試中的PDP激活測試項，在CQT點某酒店的測試過程中，GPRSPDPactivate失敗多次。
在分析該CQT點PDP激活失敗率高的原因時，發(fā)現其他CQT點的PDP激活指標都非常好，成功率達到100%，而該CQT點的PDP激活成功率只有67.3%，在對比不同CQT點的小區(qū)參數時發(fā)現，該CQT點的小區(qū)參數BS_PA_MFRMS與其他CQT點設置不一致，該CQT點此項參數值為2，而其他CQT點的參數值為5。工程經驗建議：同片區(qū)域的此參數設為一個值。由此將該CQT點的小區(qū)參數BS_PA_MFRMS參數由原來的2改為5后，重啟BTS，PDP激活失敗的問題隨之消失。

6．GPRS Ping測試出現不規(guī)則失敗的問題
問題描述：在GPRSCQT測試中的Ping測試，出現不規(guī)則的多次Ping失敗。從CDS測試儀表的GPRS時間圖上看到，在進行Ping測試的同時，RLC層的流量明顯增加，而理論上在GPRS時間圖上不應該顯示很多的RLC層的流量。據此，筆者懷疑在Ping測試的同時，測試儀表同時在運行一些其他的進程，而這些進程占用了GPRS流量，相應地影響了Ping測試的正常進行。從CDS儀表附加的數據抓包協(xié)議中，筆者的分析得到確認。
從Ping測試的記錄中找到第一次Pingsuccess的時間記錄，在數據協(xié)議中找到對應的時間點，手機與FTPServer的IP地址與設置相符。首先是MS向FTP Server發(fā)送Echo（ping）request，緊接著FTP Server下發(fā)相應消息：Echo（ping）reply 。但在Ping測試同時，以手機的IP地址為源地址向未知IP地址發(fā)出的連接，出現了多個未知的目的IP地址。
針對Ping測試中發(fā)現的許多未知IP地址，筆者對Ping測試的撥號網絡做了相應的分析。GPRS撥號網絡有兩個：cmwap、cmnet，在cmwap上支持WAP、Kjava、WAP圖鈴、MMS等業(yè)務，在cmnet上支持Ping、FTPdownload/upload業(yè)務。目前筆記本＋數據卡使用GPRS方式登錄Internet，使用的就是cmnet撥號網絡。Ping測試是GPRSCQT測試中第一個使用cmnet撥號網絡的測試項，撥通cmnet相當于連接上Internet，測試儀表使用的筆記本電腦中的Windows自動更新、殺毒軟件自動更新、MSN等軟件會自動發(fā)起搜索，這樣無形中增加了GPRSRLC層的數據流量，同時也影響了Ping的正常測試。
將筆記本電腦的系統(tǒng)及軟件的自動更新關閉后，Ping測試100%成功，在數據協(xié)議中也沒有未知的IP地址。
經過共同分析及實際驗證，Ping測試出現不規(guī)則失敗的原因為測試儀表沒有關閉自動更新功能，導致在撥通cmnet后自動連接Internet，影響了Ping的正常測試。此類的Ping失敗也不屬于網絡故障，屬于測試中的異常情況。