數(shù)據(jù)業(yè)務(wù)測試流程及案例分析

數(shù)據(jù)業(yè)務(wù)測試流程及案例分析2024/3/11數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)概述（E）GPRS對GSM網(wǎng)絡(luò)的影響（E）GPRS的引入對已有的GSM話音業(yè)務(wù)有一定的影響，這是因為網(wǎng)絡(luò)干擾增加導致在小區(qū)邊緣的通信中斷概率增加，話音服務(wù)面積收縮，越區(qū)切換的掉話率有一定程度的升高。對于話音業(yè)務(wù)，其網(wǎng)絡(luò)規(guī)劃完成以后網(wǎng)絡(luò)的頻率干擾主要決定于頻率分配和話務(wù)量。（E）GPRS引入后，增加了GSM信道的利用率，而信道利用率的增加表現(xiàn)為網(wǎng)絡(luò)干擾的增加。經(jīng)實驗證明，（E）GPRS業(yè)務(wù)每增加5%，載干比(C/I)則下降0.21dB，當（E）GPRS業(yè)務(wù)占用60%信道時，載干比下降2dB。在（E）GPRS引入的初期，如果采用將PDCH配置在BCCHTRX的策略，則不會對語音業(yè)務(wù)產(chǎn)生影響，因為此時PDCH屬于BCCH頻率組，不會對屬于其它頻率組的TCH產(chǎn)生干擾，同時對屬于BCCH頻率組的TCH由于載干比較高，因此也不會產(chǎn)生太大影響。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)概述（E）GPRS網(wǎng)絡(luò)優(yōu)化與GSM網(wǎng)絡(luò)優(yōu)化的關(guān)系（E）GPRS網(wǎng)絡(luò)的優(yōu)化比GSM網(wǎng)絡(luò)的優(yōu)化更為復雜。GSM網(wǎng)絡(luò)作為（E）GPRS的承載網(wǎng)，與（E）GPRS共用基站和頻譜資源，這就決定了（E）GPRS網(wǎng)絡(luò)與GSM網(wǎng)絡(luò)優(yōu)化相互關(guān)聯(lián)，又相互制約。首先，（E）GPRS與GSM網(wǎng)絡(luò)優(yōu)化在整體上是一致的，加強GSM無線環(huán)境的優(yōu)化工作對于（E）GPRS的優(yōu)化十分重要。提升網(wǎng)絡(luò)整體載干比水平可以使更多的（E）GPRS手機享受高級的編碼方案，從而提高系統(tǒng)的吞吐量，使已在CS-2編碼方式下的手機進一步減少分組重發(fā)的比率，使實際數(shù)據(jù)傳輸速率達到最高。其次，（E）GPRS與GSM無線網(wǎng)絡(luò)優(yōu)化又存在沖突。由（E）GPRS引入的新增干擾，一定程度上使得話音質(zhì)量下降，切換掉話率提高，進而導致原有話音服務(wù)面積縮小。由于兩者使用同一頻段資源，因而在容量配置上存在著沖突。（E）GPRS若采用在CCCH上接入的方式，則CCCH的負荷將有較大的增加。（E）GPRS引入了靈活的話音、數(shù)據(jù)信道分配策略，無線資源調(diào)度變得更為復雜，將會導致切換次數(shù)的增加，因此對原網(wǎng)的接入成功率，切換成功率略有影響。當（E）GPRS網(wǎng)絡(luò)優(yōu)化和GSM網(wǎng)絡(luò)優(yōu)化發(fā)生沖突時，在現(xiàn)階段應(yīng)當以話音業(yè)務(wù)優(yōu)先。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)概述（E）GPRS服務(wù)與用戶群體之間的關(guān)系（E）GPRS網(wǎng)絡(luò)不同于GSM網(wǎng)絡(luò),GSM的資源使用方式是獨占式使用,一旦資源分配給移動臺,在用戶掛機之前會一直占用,用戶得到的服務(wù)質(zhì)量和其他移動臺無關(guān);（E）GPRS的資源使用方式是共享式使用,系統(tǒng)資源要按照QoS和用戶的需求進行共享式地動態(tài)分配,用戶得到的服務(wù)質(zhì)量和其他移動臺有直接的關(guān)系!數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)測試的影響因素影響測試指標的外在原因測試卡類別以及HLR參數(shù)的不同測試手機型號以及手機軟件版本的不同測試電腦型號、所安裝系統(tǒng)軟件以及應(yīng)用軟件安裝情況的不同測試軟件版本的不同測試人員測試方法以及現(xiàn)場判斷測試數(shù)據(jù)可靠性能力的不同數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)測試的影響因素（E）GPRS業(yè)務(wù)測試準備配備全球通測試卡若干，設(shè)置測試卡HLR數(shù)據(jù)如下：Priority:HighPriority;DelayClass:BestEffort;Reliability:Class3;PeakThroughput:2048kbit/s;MeanThroughput:BestEffort測試終端采用SAGEMOT290或SAGEMOT490;測試手機要求K或以上版本;手機設(shè)置為自動雙頻模式;串口速率設(shè)置為115200;時隙設(shè)置為3+1/4+1模式;測試模式設(shè)置為Data/Trace測試軟件采用CDS3.0以上版本測試電腦應(yīng)保證1.2G以上主頻，256M以上內(nèi)存;重新安裝WindowsXP操作系統(tǒng),不能安裝與測試無關(guān)的軟件;將托盤中的任何與網(wǎng)絡(luò)通訊相關(guān)的程序關(guān)閉,如MSN等;關(guān)閉Windows的自動更新功能數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)測試的影響因素（E）GPRS業(yè)務(wù)測試準備保證Ping和FTP的測試服務(wù)器正常工作。同時應(yīng)保證用戶具有上傳和下載數(shù)據(jù)的權(quán)限,保證可對服務(wù)器進行Ping和FTP測試被測城市應(yīng)保證其測試服務(wù)器在測試檢查期間的可用性，如果當?shù)胤?wù)器不能使用，測試人員將選擇異地服務(wù)器進行測試保證郵件系統(tǒng)的正常工作準備大小為150K，500K的文件若干確認WAP測試站點正常工作,由運營商指定數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)測試原則CQT測試原則測試時間：視客戶要求而定，通常安排在周一至周五9:00-19:00進行地點選擇原則：

1.在城市中選20-40個測試點。具體測試點分布要求:火車站、機場、三星級以上酒店、大型商場休閑區(qū)、大學學校、大型居民區(qū)、商務(wù)場所、旅游景區(qū)2.測試點按照地理、話務(wù)因素綜合考慮均勻分布，突出重點區(qū)域

3.在測試前測量當前位置的無線信號，檢查信號強度，確保在該點有（E）GPRS覆蓋，避免在測試過程中頻繁小區(qū)重選（重選次數(shù)控制在3-4次之內(nèi))數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS數(shù)據(jù)業(yè)務(wù)測試原則適用環(huán)境：市區(qū)主要道路和重要高速、鐵路干線測試時間：視客戶要求而定，通常安排在周一至周五9:00-19:00進行測試速度：在市區(qū)保持正常行駛速度，一般車速在30-35公里/小時，在高速公路上車速一般不應(yīng)低于70公里測試路線：要求均勻覆蓋市區(qū)主要街道，并且盡量不重復；環(huán)城高速、高架橋、市區(qū)到機場公路必須進行測試測試時長：根據(jù)城市的規(guī)模來定，也可以根據(jù)用戶的要求確定每個城市的測試時長DT測試原則數(shù)據(jù)業(yè)務(wù)測試流程及案例分析目錄Internet

（E）GPRS現(xiàn)狀與（E）GPRS業(yè)務(wù)測試概述

（E）GPRS業(yè)務(wù)測試內(nèi)容（E）GPRS業(yè)務(wù)測試工具介紹（E）GPRS專題優(yōu)化介紹及案例分析數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹（E）GPRS測試目的和分類測試目的：通過對市區(qū)重要場所和市區(qū)主要道路測試，從用戶感受的角度評估城市（E）GPRS網(wǎng)絡(luò)質(zhì)量，為（E）GPRS網(wǎng)絡(luò)優(yōu)化提供參考和依據(jù)按照測試形式可以分為兩類：路測（DT，DriveTest）、定點撥打測試(CQT，CallQualityTest)???數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹（E）GPRS測試項目（E）GPRSAttach時延、成功率測試（E）GPRSPDP激活時延、成功率測試Ping時延、成功率測試FTP下載、上傳速率WAP登陸、刷新時延、成功率測試WAP下載(圖鈴)速率、成功率測試Kjava下載成功率測試SMS點到點時延、成功率測試MMSPUSH時延、PUSH成功率、端到端成功率測試FTP下載、上傳速率WAP登陸、刷新時延、成功率測試WAP下載(圖鈴)速率、成功率測試CQTDT數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹CQT測試內(nèi)容定義和方法KPI定義測試方法精度統(tǒng)計粒度ATTACH平均附著時長各次attach成功的時間相加/成功attach的次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次ATTACH附著成功率（E）GPRS成功Attach次數(shù)/總嘗試次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次PDP激活平均時長各次PDP激活成功的時間相加/成功attach的次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次PDP激活成功率（E）GPRS成功PDP激活次數(shù)/總嘗試次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次ping平均時延各次ping成功的時間相加/ping成功的次數(shù)

使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次ping成功率ping成功的次數(shù)/ping嘗試次數(shù)×100％

使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹CQT測試內(nèi)容定義和方法KPI定義測試方法精度統(tǒng)計粒度WAP平均首頁顯示時間各次WAP首頁成功顯示的時間相加/WAP首頁顯示成功次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次WAP首頁登陸成功率WAP首頁顯示成功次數(shù)/嘗試WAP登陸次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次WAP平均頁面刷新時間各次WAP刷新成功顯示的時間相加/WAP刷新成功顯示次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次WAP頁面刷新成功率WAP頁面刷新成功次數(shù)/嘗試頁面刷新次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次WAP平均圖鈴下載速率實際成功下載數(shù)據(jù)量（Byte）/實際成功下載時間(秒)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01KBit/S10次WAP圖鈴下載成功率WAP鈴聲、圖片成功下載次數(shù)/嘗試鈴聲、圖片下載次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%5次圖片5次鈴聲數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹KPI定義測試方法精度統(tǒng)計粒度FTP下載速率實際下載數(shù)據(jù)量（Byte）/實際下載時間(秒)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01KB/S1次FTP上傳速率實際上傳數(shù)據(jù)量（Byte）/實際下載時間(秒)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01KB/S1次Kjava下載成功率下載成功次數(shù)/下載測試總次數(shù)×100%使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%5次MMS端到端PUSH平均時長各次PUSH成功的時間相加/成功PUSH的次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次MMS端到端PUSH成功率用戶成功接收PUSH消息條數(shù)／用戶應(yīng)接收PUSH消息條數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次MMS端到端成功率用戶成功提取彩信的次數(shù)／用戶嘗試提取彩信的次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次CQT測試內(nèi)容定義和方法數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹KPI定義測試方法精度統(tǒng)計粒度SMS端到端PUSH平均時長各次短信接收成功的時間相加/短信成功接收的次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次SMS端到端PUSH成功率用戶成功接收短信條數(shù)／用戶應(yīng)接收短信條數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次CQT測試內(nèi)容定義和方法數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹DT測試內(nèi)容定義和方法KPI定義測試方法精度FTP下載速率實際下載數(shù)據(jù)量（Byte）/實際下載時間(秒)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01KB/SFTP上傳速率實際上傳數(shù)據(jù)量（Byte）/實際下載時間(秒)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01KB/SWAP平均首頁顯示時間各次WAP首頁成功顯示的時間相加/WAP首頁顯示成功次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒WAP首頁登陸成功率WAP首頁顯示成功次數(shù)/嘗試WAP登陸次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%WAP平均頁面刷新時間WAP頁面刷新成功指被選擇瀏覽的頁面在60秒內(nèi)文本信息完整正確的顯示時長使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒WAP頁面刷新成功率WAP頁面刷新成功次數(shù)/嘗試頁面刷新次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹KPI定義測試方法精度WAP平均圖鈴下載速率實際成功下載數(shù)據(jù)量（Byte）/實際成功下載時間(秒)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01KBit/SWAP圖鈴下載成功率WAP鈴聲、圖片成功下載次數(shù)/嘗試鈴聲、圖片下載次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%覆蓋率

（E）GPRS覆蓋公里數(shù)/總測試距離（Km）×100%使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%掉線率掉線次數(shù)/總FTP下載嘗試次數(shù)×100%使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%平均RAU間隔時間總RAU次數(shù)/總測試時間使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒DT測試內(nèi)容定義和方法數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹KPI定義測試方法精度平均RAU間隔距離總RAU次數(shù)/總測試距離使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01km平均小區(qū)重選間隔時間總小區(qū)重選次數(shù)/總測試時間使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒平均小區(qū)重選間隔距離總小區(qū)重選次數(shù)/總測試距離使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01kmDT測試內(nèi)容定義和方法數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試項目介紹測試項目超時定義KPI超時時間KPI超時時間ATTACH附著時長15SFTP下載時長(CQT)180SPDP激活時長15SFTP下載時長(DT)180SMMS接收時長100S(有些設(shè)置為150S)SMS接收時長300SPing時長5SKjava下載時長300SWAP首頁顯示時間(CQT)60SWAP首頁顯示時間(DT)60SWAP頁面刷新時間(CQT)60SWAP頁面刷新時間(DT)60SWAP圖鈴下載時長(CQT)150SWAP圖鈴下載時長(DT)200S數(shù)據(jù)業(yè)務(wù)測試流程及案例分析目錄Internet

（E）GPRS現(xiàn)狀與（E）GPRS業(yè)務(wù)測試概述

（E）GPRS業(yè)務(wù)測試內(nèi)容（E）GPRS業(yè)務(wù)測試工具介紹（E）GPRS專題優(yōu)化介紹及案例分析數(shù)據(jù)業(yè)務(wù)測試流程及案例分析（E）GPRS測試軟件CDS的使用方法CDS用戶界面數(shù)據(jù)業(yè)務(wù)測試流程及案例分析測試中常見問題總結(jié)CDS4.0版本現(xiàn)在還不穩(wěn)定，在信令解碼（比如C/I、RxQual、Ms-TxPower等）中存在一些BUG在采集參數(shù)選項中CDS默認只采集GSMC/ITrace和RLC/MACControlMSG,其實LLCMSG等參數(shù)選項對事件的分析也能起到一定作用，最好將信令采集完整注意測試用筆記本電腦在安裝測試軟件前必須重裝操作系統(tǒng)，不能安裝與測試無關(guān)的其它軟件;將托盤中的任何與網(wǎng)絡(luò)通訊相關(guān)的程序關(guān)閉,如MSN等;關(guān)閉Windows的自動更新功能，否則會影響Ping、FTP等所有與數(shù)據(jù)上傳、下載有關(guān)的測試項目測試手機各參數(shù)一定要設(shè)置正確，測試手機必須為K或以上軟件版本數(shù)據(jù)業(yè)務(wù)測試流程及案例分析測試中常見問題總結(jié)WAP刷新不是刷新首頁，而是深度為3的隨機刷新準確設(shè)置測試項目時間間隔以及超時時間，這些測試項目屬性的設(shè)置對測試結(jié)果有很大影響每個測試點測試前需要重啟一下測試手機，這樣不僅可以清除緩存空間，也可以使測試手機選擇到最好小區(qū)WAP圖鈴下載的URL不同，下載速率的差別也很大WAP測試應(yīng)以所有文字信息全部顯示為準，所以應(yīng)在WAP測試時去掉設(shè)置中的“下載頁面中的圖標”選項當FTP測試中出現(xiàn)長時間無流量時，可讓司機適當降低車速MMS測試中最好選擇NOKIA智能手機做為測試終端（不同手機測試測試結(jié)果差別很大）數(shù)據(jù)業(yè)務(wù)測試流程及案例分析

（E）GPRS現(xiàn)狀與（E）GPRS業(yè)務(wù)測試概述

（E）GPRS業(yè)務(wù)測試內(nèi)容（E）GPRS業(yè)務(wù)測試工具介紹（E）GPRS專題優(yōu)化介紹及案例分析Internet目錄數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—ATTACH問題Attach優(yōu)化方法關(guān)閉SGSN鑒權(quán)檢查覆蓋防止頻繁的小區(qū)重選排查干擾，提高C/I檢查RACH或AGCH信道配置檢查靜態(tài)PS信道、動態(tài)PS信道配置檢查（E）GPRSENABLED參數(shù)設(shè)置檢查Gblinksload，調(diào)整NSEI配置數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—ATTACH問題Attach故障案例一:手機無法登陸（E）GPRS網(wǎng)絡(luò)問題描述某區(qū)域用戶反應(yīng)不能登陸（E）GPRS網(wǎng)絡(luò)，檢查網(wǎng)絡(luò)配置無異常，實地測試的確無法登陸（E）GPRS網(wǎng)絡(luò)。故障分析進行了（E）GPRS配置數(shù)據(jù)檢查，開通（E）GPRS功能小區(qū)的NSEI、NSVI、RAC等各項（E）GPRS參數(shù)配置均正確Pcu時隙負荷比較高。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—ATTACH問題Attach故障案例二:手機無法登陸（E）GPRS網(wǎng)絡(luò)問題描述：有用戶反映手機（E）GPRSAttach不能成功?，F(xiàn)象為手機發(fā)送Attachrequest，SGSN返回attachaccept消息，而后面BSC上發(fā)信令為LLCunkowninformation。故障分析：根據(jù)信令流程，BSS側(cè)負責TBF流的建立，后面應(yīng)為手機和SGSN的透傳信令，正常流程應(yīng)為手機向SGSN發(fā)送Attachcomplete。檢查BSC相關(guān)數(shù)據(jù)沒有發(fā)現(xiàn)問題。從全局測試來看，與SGSN對接的所有BSC下所帶基站都有相同問題情況，初步判斷為SGSN側(cè)的問題。經(jīng)SGSN的工程師檢查，有數(shù)據(jù)改動，即P-TMSI由原來的enable改為disable。導致P-TMSI無法分配，用戶無法上（E）GPRS。解決方法：將P-TMSI由disable調(diào)整為enable，故障解決。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—ATTACH問題Attach故障案例三:ATTACH失敗問題：頻繁的小區(qū)重選（60021→60332→60021）導致ATTACH時延過長（14.55s）。解決方案：提高60021CRH由8dB到10dB,調(diào)整60332RXLEVACCESSMIN由10dB到12dB數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—ATTACH問題Attach故障案例四:ATTACH失敗問題：網(wǎng)絡(luò)向手機發(fā)送PacketAccessReject消息作為對PacketResourceRequest消息的應(yīng)答，此消息中包含“Wait_Indication”域，其值賦予T3172，當手機收到PacketAccessReject消息后，啟動T3172，在T3172運行期間，網(wǎng)絡(luò)不允許手機在同一小區(qū)內(nèi)再次發(fā)起分組接入嘗試。該事件由無線資源緊張所致。解決方案：擴充靜態(tài)PS信道。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP激活優(yōu)化方法關(guān)閉SGSN鑒權(quán)檢查核心網(wǎng)各網(wǎng)元處理能力（DNS解析APN錯誤或者過慢、GGSN關(guān)于APN的配置數(shù)據(jù)不完整、DHCP或RADIUS服務(wù)器故障、HLR和SGSN對通配符APN格式的兼容性問題、SGSN和GGSN的GTP信令的兼容性問題、SGSN構(gòu)造APN的配置問題、GGSN處理過慢、DNS和GGSN的主備用狀態(tài)）防止頻繁的小區(qū)重選排查干擾，提高C/I檢查RACH或AGCH信道配置，提高接入和立即指配成功率檢查靜態(tài)PS信道、動態(tài)PS信道配置檢查Gblinksload，調(diào)整NSEI配置檢查（E）GPRS參數(shù)設(shè)置，合理設(shè)置DrxTimeMax、MFR、T3168數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例一:PDP激活失敗問題：在20022重選到20281后，由于20281AGCH緊張導致。解決方案：控制20281覆蓋范圍，適當增加20281AGCH配置。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例二:PDP激活失敗問題：由于連續(xù)發(fā)生兩次小區(qū)重選（CELLID:10071Channel:2—CELLID:111Channel:90—CELLID:114Channel:512）長時間無時隙分配引起PDP激活失敗。解決方案：提高60021CRH由6dB到10dB。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例三:PDP激活失敗問題：由于沒有申請到PS信道導致PDP激活失敗。解決方案：增加8540站點的靜態(tài)PS信道，將MFR由5調(diào)整到2。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例四:PDP激活失敗問題：在CQT測試時經(jīng)常出現(xiàn)偶爾PDP激活時延過長的現(xiàn)象。經(jīng)過對10個點100次的PDP激活測試,發(fā)現(xiàn)7次時延異常的現(xiàn)象，具體掛表結(jié)果如下：數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例四:PDP激活失敗正常情況下幾個接口上的耗時情況如下：數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例四:PDP激活失敗從幾次異常測試結(jié)果可以看出，主要耗時是在Gb口以下和Radius與WAP網(wǎng)關(guān)間，其中第六次GGSN與Radius間的耗時比較長，是因為GGSN第一次發(fā)送的Accountingrequest消息沒有被WAP網(wǎng)關(guān)接收到，也就是說，我們在WAP網(wǎng)關(guān)側(cè)沒有看到GGSN第一次發(fā)送的Accountingrequest消息，只看到了GGSN第二次重新發(fā)送的Accountingrequest消息，而且WAP網(wǎng)關(guān)收到后及時給予了響應(yīng)。導致這種現(xiàn)象的原因可能是Accountingrequest消息在傳輸中丟失或者Radius的處理異常。另外六次則是因為Gb口以下和Radius與WAP網(wǎng)關(guān)間的耗時過長。GGSN向Radius發(fā)送AccountingRequest消息，等待Radius的響應(yīng)，并啟動相應(yīng)的等待定時器，在相應(yīng)的WAP網(wǎng)關(guān)側(cè)，我們發(fā)現(xiàn)WAP網(wǎng)關(guān)在收到AccountingRequest消息后沒有給予響應(yīng)，由于GGSN沒有收到AccountingRequest消息的響應(yīng)消息，導致等待定時器超時，然后GGSN重新發(fā)送AccountingRequest消息，在相應(yīng)的WAP網(wǎng)關(guān)側(cè)，我們發(fā)現(xiàn)WAP網(wǎng)關(guān)此次給予了響應(yīng)，GGSN收到Radius轉(zhuǎn)發(fā)的AccountingResponse消息，這時GGSN才對手機的PDP激活請求進行響應(yīng)。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例四:PDP激活失敗正是由于Gi口的耗時過長，使得無線側(cè)的定時器超時而釋放了TBF資源，所以手機在接收PDP激活接受消息時，重新進行了TBF的建立，這又進一步增加了在無線口上的延時。因此，WAP網(wǎng)關(guān)的響應(yīng)過慢，是導致PDP激活時延過長根本原因。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例五:PDP激活失敗在中國移動集團公司第三方測試的準備工作中，發(fā)現(xiàn)（E）GPRSCQT的火車站測試點有PDP激活失敗的現(xiàn)象，并且多次測試問題始終存在。從信令來看，當下行的立即指配信息里出現(xiàn)了右圖中ARFCN為809的時候，PDP激活會不成功。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例五:PDP激活失敗809這個頻點是不正常的，但這是根據(jù)手機收到基站發(fā)出的層三消息解出來的。這個立即支配消息是為了分配下行的TBF，也就是意味著網(wǎng)絡(luò)已收到PDP激活申請且給手機回復了PDPactivateaccept消息，但此消息未能通過空中接口。當時懷疑是否因測試軟件導致，詢問CDS軟件研發(fā)工程師，回復軟件應(yīng)該沒有問題，也不像測試手機問題，所以網(wǎng)絡(luò)下發(fā)的消息編碼存在問題的可能性比較大。對同個BSC下的三晉國際飯店測試沒有發(fā)現(xiàn)同樣的問題。調(diào)整頻點和無線參數(shù)等也沒有解決問題，于是懷疑是否為基站的問題。重啟基站，重做基站數(shù)據(jù)，仍然沒有效果。將天線直接接到BTS機柜上測試看是否是因為分布系統(tǒng)的問題，但在測試中還是存在PDP激活失敗，所以也排除分布系統(tǒng)的問題。對GB口進行掛表測試，出現(xiàn)三次PDP激活失敗。這三次失敗在GB口信令中體現(xiàn)為：MS發(fā)給SGSNAPCR,然后SGSN都立即回復一個APAC給MS。但是在SGSN回復APAC給MS7s－8s后,在GB數(shù)據(jù)里發(fā)現(xiàn)了RSTA，在該信令中發(fā)現(xiàn)“RadiocontactlostwithMS”的信息，同時還有一個LLCD(=LLC-DISCARDED)的信令。見下圖：

數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例五:PDP激活失敗數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—PDP激活問題PDP故障案例五:PDP激活失敗總之,雖然在CDS的LOG里存在PDP失敗,但是從GB數(shù)據(jù)里反應(yīng)出的流程卻是完整的,而且SGSN都是在收到MS的APCR后就立即回復了APAC。因此分析結(jié)果表明這幾次的PDP激活失敗并非由核心網(wǎng)引起，可能是由無線側(cè)導致了手機未能收到SGSN發(fā)的APAC而產(chǎn)生TIMEOUT。由于無線質(zhì)量、（E）GPRS統(tǒng)計和參數(shù)、核心網(wǎng)、分布系統(tǒng)等都沒有問題，這時我們把重點放在基站硬件這一側(cè)。因為8593也會出現(xiàn)閃斷，懷疑是否因傳輸誤碼率過高而導致，所以要求更換傳輸，換完傳輸后進行測試，還是沒有效果。由于在8591測試時PDP激活成功率為100％，把8591的BTS和8593的BTS進行調(diào)換再測試。在調(diào)換完后的200次PDP激活測試中，8593沒有出現(xiàn)一次失敗，而原來好的小區(qū)8591出現(xiàn)了5次PDP激活失敗。最終更換了8593BTS，問題得到解決。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—Ping問題Ping優(yōu)化方法優(yōu)化PingServer,將PingServer搬到FW內(nèi)檢查覆蓋防止頻繁的小區(qū)重選排查干擾，提高C/I檢查靜態(tài)PS信道、動態(tài)PS信道配置檢查Gblinksload，調(diào)整NSEI配置檢查（E）GPRS參數(shù)設(shè)置，合理設(shè)置DrxTimeMax、MFR、T3168優(yōu)化測試測試電腦，關(guān)閉所有系統(tǒng)軟件以及應(yīng)用軟件的自動更新功能數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—Ping問題Ping故障案例一:不同時間間隔造成PING時延不同問題：Ping測試中時間間隔設(shè)置為4s-12s測試結(jié)果有很大差別。經(jīng)過核心網(wǎng)掛表測試發(fā)現(xiàn)Ping時延不穩(wěn)定是因為測試過程中出現(xiàn)其他一些數(shù)據(jù)包，這些垃圾數(shù)據(jù)包是由殺毒軟件和一些應(yīng)用軟件自動更新造成的。解決方案：重新安裝操作系統(tǒng)，不能安裝與測試無關(guān)的軟件，將托盤中的任何與網(wǎng)絡(luò)通訊相關(guān)的程序關(guān)閉，關(guān)閉Windows的自動更新功能。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—Ping問題Ping故障案例二:Ping失敗問題：PING失敗時誤碼率很高，查看網(wǎng)管指標發(fā)現(xiàn)此時干擾比較嚴重，但是其他時段幾乎沒有干擾，基本可以確定該干擾是外部干擾。解決方案：查找外部干擾。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—Ping問題Ping故障案例三:Ping失敗問題：由于小區(qū)的C/I低導致較高的BLER（小區(qū)BCCHC／I＝5.9）。查看規(guī)劃數(shù)據(jù)，微蜂窩8800、7660、8750是同BCCH。解決方案：控制8800、7660、8750覆蓋，調(diào)整8800、7660、8750頻點。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP優(yōu)化方法優(yōu)化WAP網(wǎng)關(guān)、移動夢網(wǎng)服務(wù)器、Gi口檢查覆蓋防止頻繁的小區(qū)重選排查干擾，提高C/I檢查靜態(tài)PS信道、動態(tài)PS信道配置檢查Gblinksload，調(diào)整NSEI配置檢查（E）GPRS參數(shù)設(shè)置，合理設(shè)置DrxTimeMax、MFR、T3168優(yōu)化測試測試電腦，關(guān)閉所有系統(tǒng)軟件以及應(yīng)用軟件的自動更新功能數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP故障案例一:WAP刷新失敗問題：出現(xiàn)WAPreply失敗的時候（E）GPRS的質(zhì)量為6級，從服務(wù)小區(qū)和鄰區(qū)的測量來看，存在著鄰頻的干擾。解決方案：更改頻點。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP故障案例一:WAP圖鈴下載速率低問題：通過分析看出RLC數(shù)據(jù)重傳率高，從OMC統(tǒng)計數(shù)據(jù)看Gblink的負荷在測試時段已高達64%，從而導致下載速率低。解決方案：重新調(diào)整NSEI以減低Gblinkload，從而提高（E）GPRSCQT的下載速率。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP故障案例三:WAP登陸失敗問題：在**賓館WAP登陸測試中，通過跟蹤Gb口發(fā)現(xiàn)，手機上行發(fā)送Get(URL=)，網(wǎng)絡(luò)側(cè)回復了一個PDU，具體內(nèi)容為：Yourrequestforaservicecouldnotbefulfilled,pleasetryagainorcontactyouroperatoriftheproblempersists。這種現(xiàn)象是因為移動夢網(wǎng)服務(wù)器出現(xiàn)問題。解決方案：與核心網(wǎng)工程師溝通解決。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP故障案例四:WAP登陸和刷新時延過長GB口WAP測試流程數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP故障案例四:WAP登陸和刷新時延過長WAP測試信令流程問題：信令分析發(fā)現(xiàn)，網(wǎng)關(guān)在CONNECT到CONNECTREPLY和GET到REPLY間存在響應(yīng)時延長，需重復發(fā)送GET請求,甚至會出現(xiàn)沒有響應(yīng)的情況，尤其是GET與REPLY間經(jīng)常出現(xiàn)較大的信令時延，有的甚至達到幾十秒,對手機訪問WAP速度有較大影響。我們初步認為打開WAP網(wǎng)頁時超過20秒以上的大時延基本都是由網(wǎng)關(guān)時延引起的。解決方案：核心網(wǎng)工程師針對WAP網(wǎng)關(guān)進行優(yōu)化。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP錯誤代碼含義—WTP層協(xié)議發(fā)生錯誤

數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP錯誤代碼含義—WSP層協(xié)議發(fā)生錯誤

數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—WAP問題WAP錯誤代碼含義—HTTP協(xié)議發(fā)生錯誤

數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—MMS問題MMS優(yōu)化方法優(yōu)化相關(guān)核心網(wǎng)網(wǎng)關(guān)及接口、移動Radius到省內(nèi)檢查覆蓋防止頻繁的小區(qū)重選排查干擾，提高C/I檢查靜態(tài)PS信道、動態(tài)PS信道配置檢查Gblinksload，調(diào)整NSEI配置檢查（E）GPRS參數(shù)設(shè)置，合理設(shè)置DrxTimeMax、MFR、T3168數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—MMS問題MMS故障案例一:MMS發(fā)送失敗問題：通過掛表發(fā)現(xiàn)手機首先PDP激活，APN為CMWAP，但是手機隨后沒有任何發(fā)起任何信令。這種情況是由于手機軟件進程吊死所致。解決方案：重裝手機操作系統(tǒng)。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—MMS問題MMS故障案例二:MMS接收失敗問題：通過掛表發(fā)現(xiàn)手機首先建立了WSP層的連接，然后發(fā)起GET請求接收彩信，隨后WAP網(wǎng)關(guān)將彩信在WTP分割后，向手機發(fā)送WTP層的分段，當傳送到第六個分段后該消息中的GTR和TTR都為0，說明該分段既不是整個消息中某組的最后一塊，也不是整個消息的最后一塊，但是手機卻回應(yīng)了ACK，緊接著又發(fā)起一個Transaction(Invoke)。這種情況是由于手機軟件故障所致。解決方案：重裝手機操作系統(tǒng)。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—MMS問題MMS故障案例三:MMS接收失敗問題：通過Gi口掛表發(fā)現(xiàn)手機在發(fā)起Get請求后，在10ms左右的時間連續(xù)多次重發(fā)Get請求（Get請求重發(fā)定時器為10s），導致WAP網(wǎng)關(guān)來不得處理手機的Session，從重發(fā)時間間隔來看，不可能是手機連續(xù)接收彩信。這種情況是由于手機軟件故障所致。解決方案：重裝手機操作系統(tǒng)。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—MMS問題MMS故障案例四:MMS發(fā)送失敗問題：通過掛表我們發(fā)現(xiàn)手機首先上行發(fā)送WSP層的Connect信令，建WSP層的連接，但是WAP網(wǎng)關(guān)沒有回應(yīng)ConnectReply，手機等待5秒后重Connect，但是始終沒有回應(yīng)ConnectReply，達到最大重發(fā)次數(shù)5次后，WSP層的建鏈失敗，最終導致彩信發(fā)送失敗。導致此次MMS發(fā)送失敗的原因為WAP網(wǎng)關(guān)過于繁忙沒有回應(yīng)ConnectReply。解決方案：請核心網(wǎng)工程師配合解決。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP優(yōu)化方法優(yōu)化FTPServer，將FTPServer搬到FW內(nèi)檢查覆蓋防止頻繁的小區(qū)重選排查干擾，提高C/I檢查靜態(tài)PS信道、動態(tài)PS信道配置檢查Gblinksload，調(diào)整NSEI配置調(diào)整DLB、ULB、DLBH、ULBH參數(shù)，動態(tài)調(diào)整CS的比例檢查（E）GPRS參數(shù)設(shè)置，合理設(shè)置DrxTimeMax、MFR、T3168、T3192打開CS3、CS4數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例一:FTP下載失敗問題：MS重選到小區(qū)41921后，DLTBF一直沒被建立導致長時間下行無數(shù)據(jù)傳輸，最終導致了PDP掉線.經(jīng)檢查該小區(qū)在測試時間段內(nèi)的（E）GPRSKPI：下行時隙分配擁塞率比較高，這是為什么沒能建立DLTBF的主要原因所在。解決方案：增加該小區(qū)靜態(tài)PS信道。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例二:FTP下載速率過低問題：第一次cellreselection（90→52）使數(shù)據(jù)傳輸恢復時間變長而導致長時間TBF掛起。之后重建時由于小區(qū)30553數(shù)據(jù)業(yè)務(wù)繁忙只申請到一條PS信道，在數(shù)據(jù)下傳過程中又發(fā)生了第二次cellreselection（52→80），然后因為數(shù)據(jù)傳輸恢復時間變長而導致長時間TBF掛起。在重建時小區(qū)30152數(shù)據(jù)業(yè)務(wù)繁忙導致一直申請不到下行的PS信道導致三次PING失敗，最終申請到了4條PS信道，下載成功。導致平均下載速率只有8.11kbit/s。解決方案：擴充30553、30152靜態(tài)PS信道；調(diào)整30553RXLEVACCESSMIN由10到12。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例三:FTP下載失敗問題：MS從43372重選到42093后，又從42093重選到1531后又頻繁重選回1531后，電平降到-94dBm，拖了一段時間后PDP掉線。解決方案：控制42093、1531覆蓋。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例四:FTP下載失敗問題：MS跨LAC從83重選到1483后，就頻繁的小區(qū)重選1483→18621→741，導致長時間的TBF掛起，最終PDP掉線。從地形看，該處是一座立交橋，橋下無主控區(qū)。解決方案：調(diào)整1483CRH由6到10，確定該地點的主控小區(qū)。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例五:FTP下載速率低問題：MS拿到的PDCH不穩(wěn)定，跳變頻繁，PS爭搶頻繁，導致了DLFTP速率低。解決方案：增加CI2631的靜態(tài)PS信道。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例六:FTP下載速率低案例說明：在**路和**橋路附近，手機從宏站小區(qū)重選至室外微蜂窩52484（八萬人體育館），BCCH＝109。由于室外微蜂窩主要是針對某個熱點地區(qū)，或者覆蓋比較差的區(qū)域采用的覆蓋方式。我們在（E）GPRS測試時，車經(jīng)過室外微蜂窩的時間比較短，盡量不要讓手機重選至這樣的小區(qū)，這樣會增加小區(qū)重選的次數(shù)和減少吞吐量。在這個案例中，我們發(fā)現(xiàn)這個小區(qū)主要是覆蓋八萬人體育場的外場，所以我們鼓勵慢速移動的手機占用此小區(qū)，快速移動的手機不要重選進這樣的小區(qū)。52484參數(shù)設(shè)置為：PET=20s，TEO=0。為了保證手機在一段時間內(nèi)不重選進此小區(qū)，設(shè)置PET＝20s，TEO＝30db，即在52484的信號出現(xiàn)在MS的鄰區(qū)20s內(nèi)給C2一個人為的衰減值30db，使其他小區(qū)的C1，C2大過本小區(qū)5s，這樣手機即不會選進室外微蜂窩。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例六:FTP下載速率低數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—FTP問題FTP故障案例六:FTP下載速率低問題：在復測時我們發(fā)現(xiàn)，在同一個地點，此時52484的C1=25，C2＝21，從15:40:33.764至15:53:586持續(xù)20s后，C2值升至53。由于復測時，車行駛的地方為一個交通燈口，車流量大、擁堵。我們原先設(shè)置的PET＝20s遠遠小于堵車的時間。解決方案：將這個小區(qū)的PET設(shè)置為200s，這樣小區(qū)重選發(fā)生的可能性就大大降低了。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—高BLERBLER概述BLER反應(yīng)信道受干擾的情況，但在小數(shù)據(jù)傳輸中可以看到下行BLER總是比較高，重傳的BLOCK中很大的一部分是由于PCU的無線傳輸特性決定的，PCU在下行傳輸時，判斷數(shù)據(jù)是否快要發(fā)送完了，在數(shù)據(jù)快要結(jié)束前N個BLOCK(N由PCU參數(shù)決定)的時候確定TBF快要結(jié)束，在下行TBF的結(jié)尾處最后的一個BLOCK發(fā)送之后而在對它的確認包回來之前，PCU重復發(fā)送這些未確認的BLOCK直到收到確認包。此時如果發(fā)生該BLOCK的接收錯誤，手機可以馬上從后面的BLOCK中獲得而不必要求重傳，手機在計算BLER的時候把這部分BLOCK也計算在內(nèi)，從而導致BLER的計算值比較高，因此小數(shù)據(jù)傳輸下行BLER并不代表系統(tǒng)真正的無線性能，在大數(shù)據(jù)量傳輸時的BLER可以真實的反映出系統(tǒng)的無線性能。測試中同時觀察C/I、質(zhì)量、手機發(fā)射功率、重傳率以及信道的RLC層速率，這些都是反應(yīng)信道質(zhì)量的重要指標。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—高BLERBLER案例1—內(nèi)部干擾問題問題：是該站點覆蓋小區(qū)，但是高BLER。解決方案：更改GTRX或者更換頻點。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—高BLERBLER案例2—小區(qū)重選問題問題：已經(jīng)越過了該小區(qū)的主控范圍，但是不向鄰小區(qū)重選。解決方案：調(diào)高該鄰小區(qū)的CRH。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—小區(qū)重選問題小區(qū)重選的時候手機會暫時中斷數(shù)據(jù)傳輸，在這里數(shù)據(jù)中斷的時長主要包括：重選后數(shù)據(jù)暫停的時間、TCPSlowStart啟動的時間，這一過程大約需要4~10秒，直至TCP正常傳輸。路測過程中，要特別注意觀察，是否有頻繁小區(qū)重選或乒乓小區(qū)重選發(fā)生，小區(qū)信號覆蓋過小或不穩(wěn)定都會導致頻繁、乒乓小區(qū)重選，同時還要注意觀察，是否由于小區(qū)重選參數(shù)設(shè)置不合理導致過覆蓋，這里注意對CRO、CRH等相關(guān)參數(shù)的調(diào)整。TCPSlowStart過程，在小區(qū)重選后數(shù)據(jù)暫停的時長約4~10秒，手機在新小區(qū)駐留后需要0.5~5秒的時間獲得資源分配，如果有資源可以分配的話，此時手機已經(jīng)有少量數(shù)據(jù)的發(fā)送和接收（通過IP分析軟件觀察），此時使用PING來檢驗就可以看到（E）GPRS連接已經(jīng)恢復。在TCP的數(shù)據(jù)連接恢復過程中再次發(fā)生的小區(qū)重選會嚴重影響給TCP的數(shù)據(jù)連接恢復。小區(qū)重選與路由更新概述數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—小區(qū)重選與路由更新問題小區(qū)重選與路由更新概述小區(qū)重選的時候手機會暫時中斷數(shù)據(jù)傳輸，在這里數(shù)據(jù)中斷的時長主要包括：重選后數(shù)據(jù)暫停的時間、TCPSlowStart啟動的時間，這一過程大約需要4~10秒，直至TCP正常傳輸。路測過程中，要特別注意觀察，是否有頻繁小區(qū)重選或乒乓小區(qū)重選發(fā)生，小區(qū)信號覆蓋過小或不穩(wěn)定都會導致頻繁、乒乓小區(qū)重選，同時還要注意觀察，是否由于小區(qū)重選參數(shù)設(shè)置不合理導致的過覆蓋現(xiàn)象，這里注意對CRO、CRH等相關(guān)參數(shù)的調(diào)整。TCPSlowStart過程，在小區(qū)重選后數(shù)據(jù)暫停的時長約4~10秒，手機在新小區(qū)駐留后需要0.5~5秒的時間獲得資源分配，如果有資源可以分配的話，此時手機已經(jīng)有少量數(shù)據(jù)的發(fā)送和接收（通過IP分析軟件觀察），此時使用PING來檢驗就可以看到（E）GPRS連接已經(jīng)恢復。在TCP的數(shù)據(jù)連接恢復過程中再次發(fā)生的小區(qū)重選會嚴重影響TCP數(shù)據(jù)連接的恢復。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—小區(qū)重選與路由更新問題DT測試中會發(fā)生小區(qū)重選，在重選后的數(shù)據(jù)中斷和恢復期間數(shù)據(jù)量非常小，TCP慢啟動之后，數(shù)據(jù)傳輸恢復?；謴蜁r間長度不一，這和重選時TCP數(shù)據(jù)傳輸當時的具體情況有關(guān)，一般4~10秒，極端惡劣情況下達1~2分鐘，但此時如果停止行駛，數(shù)據(jù)傳輸會在短時間內(nèi)恢復。FTP的數(shù)據(jù)傳輸在經(jīng)歷RAU的時候同時也進行了小區(qū)重選，此時的數(shù)據(jù)中斷情況同小區(qū)重選一樣，在RAU之后繼續(xù)的小區(qū)重選也會給TCP的數(shù)據(jù)連接恢復帶來負作用，路測過程中應(yīng)觀察重要路段或重要場所是否有不合理的RAU事件發(fā)生。在RAU之后可以使用PING來驗證（E）GPRS承載已經(jīng)恢復。小區(qū)重選與路由更新概述數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—小區(qū)重選與路由更新問題小區(qū)重選案例1—C2參數(shù)設(shè)置不合理問題問題：車輛沿機場高速從北向南行駛，紅圈處占用小區(qū)高教科研4（BCCH：560）。繼續(xù)南行，高教科研4的電平逐漸降低，低至－94dBm以下時，仍不發(fā)生小區(qū)重選。長時間電平小于－94dBm，造成無覆蓋。經(jīng)檢查發(fā)現(xiàn)此時該小區(qū)與相鄰小區(qū)的小區(qū)重選參數(shù)設(shè)置情況如下：數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—小區(qū)重選與路由更新問題小區(qū)重選案例1—C2參數(shù)設(shè)置不合理問題小區(qū)名Rexlev（dBm）RXLEVACCESSMINCRHCROTOC2高教科研4-103-100826023下墟3-80-10088028殷巷3-84-100810026解決方案：控制小區(qū)高教科研4（BCCH：560）的覆蓋，修改高教科研4小區(qū)CRO由26到20。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—小區(qū)重選與路由更新問題路由更新案例1—跨越SGSN路由區(qū)更新故障

每次穿越RAC區(qū)時，都發(fā)生掉線，且都伴隨著RAUFailure。通過仔細分析，SGSN內(nèi)的數(shù)據(jù)錯誤是導致這種路由更新失敗的原因。關(guān)系（E）GPRS路由更新的參數(shù)主要有3部分，即：(1)

每個MSC到SGSN的歸屬位置(2)

每個BSC到MSC的歸屬位置(3)

每個小區(qū)的歸屬的RAC區(qū)以上3個參數(shù)必須與現(xiàn)行網(wǎng)絡(luò)中硬件設(shè)備的連接一致才能保證（E）GPRS手機路由更新的正常進行。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—NSEI規(guī)劃NSEI規(guī)劃概述（E）GPRS協(xié)議棧BSSGP層中，為了便于管理，每個（E）GPRS小區(qū)被賦予了一個BSSGP虛連接BVC（NSEI＋BVCI），一個BVC必須隸屬于一個NSE。其中NSE為網(wǎng)絡(luò)服務(wù)設(shè)備實體，是全網(wǎng)統(tǒng)一編碼的，以NSEI來標識。一般來說一個BSC被劃分為一個服務(wù)實體，為了可擴展性，ZXG10系統(tǒng)中也允許BSC下掛若干個NSE。BSSGP虛連接（BVC）為不同的BSSGP實體間通訊提供了一種途徑。對等的PTP（點對點）、PTM（點對多）和信令實體間傳送BSSGPPDU時是以BVC為基礎(chǔ)的。每條虛連接都有一個標識，為BVCI，它能使底層網(wǎng)絡(luò)服務(wù)層將BSSGPPDU高效地路由到對等實體上。在一個網(wǎng)絡(luò)服務(wù)實體（NSE）下，每個（E）GPRS小區(qū)可由BVCI唯一標識，一個網(wǎng)絡(luò)服務(wù)實體有且僅有一條信令BVC（BVCI=0）。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—NSEI規(guī)劃NSEI規(guī)劃前在網(wǎng)絡(luò)優(yōu)化之前沒有優(yōu)化過NSEI，PCU的分配很是隨便，甚至一個站上的兩個小區(qū)都不在一個PCU下，這對（E）GPRSperformance有很大影響。因此,我們需要重新分配NSEI。比如下圖就是沒有經(jīng)過合理配置的NSEI：數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—NSEI規(guī)劃NSEI規(guī)劃后在優(yōu)化期間，PCU需要定期重新規(guī)劃，也即重新分配小區(qū)的NSEI，在物理位置上盡量靠近，這樣做的目的是為了在（E）GPRSDT的過程中避免頻繁的RAU，從而提高（E）GPRSDT的Performance。下圖就是經(jīng)過優(yōu)化過的NSEI分配：專題—NSEI規(guī)劃數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—NSEI規(guī)劃NSEI規(guī)劃案例2—FTP下載失敗問題：MS從CI1892重選到CI到481的同時跨了PCU，屬于Inter-PCU的CellReselection,導致了數(shù)據(jù)傳輸長時間的停頓，最終發(fā)生了PDP掉線。經(jīng)檢查發(fā)現(xiàn)CI1892的NSEI值與周圍站點不統(tǒng)一。解決方案：調(diào)整CI1892的NSEI值。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—BCCHTRX、TCHTRX（HF/NHF）下（E）GPRS性能比較BCCHTRX、TCHTRX（HF/NHF）下（E）GPRS性能比較 為明確了解BCCH載頻、TCH載頻在跳頻、非跳頻及不同編碼方式下FTP下載速率的變化情況，尋找特定小區(qū)進行了詳盡的測試，具體情況如下：無線環(huán)境好、接收電平強 測試地點設(shè)在一寫字樓內(nèi)，由于樓內(nèi)主要由微蜂窩覆蓋，周邊的無線環(huán)境較好，主控小區(qū)的電平遠遠高于相鄰小區(qū)，接收電平在－55dBm左右，在這種情況下通過測試發(fā)現(xiàn)，占用BCCH或TCH、跳頻或非跳頻之間的下載速率差異值不是很大。數(shù)據(jù)業(yè)務(wù)測試流程及案例分析專題—BCCHTRX、TC