GPRS業(yè)務測試流程及案例分析第1頁/共108頁GPRS數(shù)據(jù)業(yè)務概述GPRS現(xiàn)狀GPRS是當今世界移動通信技術(shù)向第三代邁進的主流技術(shù)，是第二代移動通信技術(shù)向第三代技術(shù)演進的一個非常重要、不可或缺的過程和里程碑，是介于第二代移動通信與第三代移動通信之間的2.5代移動通信技術(shù)。據(jù)統(tǒng)計，目前全世界有172個國家的400多個移動通信運營商采用了GSM標準，占全球總數(shù)的72%，已有99個國家的移動通信運營商投入了GPRS運營。其中，在全球移動通信客戶排名前10位的移動通信運營商中，已有沃達豐、法國電信和英國電信等7家選用了GPRS技術(shù)。中國移動在分析世界和中國通信的發(fā)展形勢后，緊跟世界主流技術(shù)，選擇了GPRS技術(shù)，并于1999年開始搭建GPRS實驗網(wǎng)。經(jīng)過4年多的建設和不斷完善,截止到2003年底中國移動GPRS網(wǎng)絡已經(jīng)覆蓋全國所有省(市、自治區(qū))，網(wǎng)絡遍布全國240多個大中城市。因此,如何保證廣大移動用戶隨時都能方便快捷地使用GPRS成為中國移動運營商的當務之急！第2頁/共108頁GPRS數(shù)據(jù)業(yè)務概述GPRS對GSM網(wǎng)絡的影響GPRS的引入對已有的GSM話音業(yè)務有一定的影響，這是因為網(wǎng)絡干擾增加導致在小區(qū)邊緣的通信中斷概率增加，話音服務面積收縮，越區(qū)切換的掉話率有一定程度的升高。對于話音業(yè)務，其網(wǎng)絡規(guī)劃完成以后網(wǎng)絡的頻率干擾主要決定于頻率分配和話務量。GPRS引入后，增加了GSM信道的利用率，而信道利用率的增加表現(xiàn)為網(wǎng)絡干擾的增加。經(jīng)實驗證明，GPRS業(yè)務每增加5%，載干比(C/I)則下降0.21dB，當GPRS業(yè)務占用60%信道時，載干比下降2dB。在GPRS引入的初期，如果采用將PDCH配置在BCCHTRX的策略，則不會對語音業(yè)務產(chǎn)生影響，因為此時PDCH屬于BCCH頻率組，不會對屬于其它頻率組的TCH產(chǎn)生干擾，同時對屬于BCCH頻率組的TCH由于載干比較高，因此也不會產(chǎn)生太大影響。第3頁/共108頁GPRS數(shù)據(jù)業(yè)務概述GPRS網(wǎng)絡優(yōu)化與GSM網(wǎng)絡優(yōu)化的關(guān)系GPRS網(wǎng)絡的優(yōu)化比GSM網(wǎng)絡的優(yōu)化更為復雜。GSM網(wǎng)絡作為GPRS的承載網(wǎng)，與GPRS共用基站和頻譜資源，這就決定了GPRS網(wǎng)絡與GSM網(wǎng)絡優(yōu)化相互關(guān)聯(lián)，又相互制約。首先，GPRS與GSM網(wǎng)絡優(yōu)化在整體上是一致的，加強GSM無線環(huán)境的優(yōu)化工作對于GPRS的優(yōu)化十分重要。提升網(wǎng)絡整體載干比水平可以使更多的GPRS手機享受高級的編碼方案，從而提高系統(tǒng)的吞吐量，使已在CS-2編碼方式下的手機進一步減少分組重發(fā)的比率，使實際數(shù)據(jù)傳輸速率達到最高。其次，GPRS與GSM無線網(wǎng)絡優(yōu)化又存在沖突。由GPRS引入的新增干擾，一定程度上使得話音質(zhì)量下降，切換掉話率提高，進而導致原有話音服務面積縮小。由于兩者使用同一頻段資源，因而在容量配置上存在著沖突。GPRS若采用在CCCH上接入的方式，則CCCH的負荷將有較大的增加。GPRS引入了靈活的話音、數(shù)據(jù)信道分配策略，無線資源調(diào)度變得更為復雜，將會導致切換次數(shù)的增加，因此對原網(wǎng)的接入成功率，切換成功率略有影響。當GPRS網(wǎng)絡優(yōu)化和GSM網(wǎng)絡優(yōu)化發(fā)生沖突時，在現(xiàn)階段應當以話音業(yè)務優(yōu)先。第4頁/共108頁GPRS數(shù)據(jù)業(yè)務概述GPRS服務與用戶群體之間的關(guān)系GPRS網(wǎng)絡不同于GSM網(wǎng)絡,GSM的資源使用方式是獨占式使用,一旦資源分配給移動臺,在用戶掛機之前會一直占用,用戶得到的服務質(zhì)量和其他移動臺無關(guān);GPRS的資源使用方式是共享式使用,系統(tǒng)資源要按照QoS和用戶的需求進行共享式地動態(tài)分配,用戶得到的服務質(zhì)量和其他移動臺有直接的關(guān)系!第5頁/共108頁GPRS數(shù)據(jù)業(yè)務測試的影響因素影響測試指標的外在原因

測試卡類別以及HLR參數(shù)的不同測試手機型號以及手機軟件版本的不同測試電腦型號、所安裝系統(tǒng)軟件以及應用軟件安裝情況的不同測試軟件版本的不同測試人員測試方法以及現(xiàn)場判斷測試數(shù)據(jù)可靠性能力的不同第6頁/共108頁GPRS數(shù)據(jù)業(yè)務測試的影響因素GPRS業(yè)務測試準備配備全球通測試卡若干，設置測試卡HLR數(shù)據(jù)如下：Priority:HighPriority;DelayClass:BestEffort;Reliability:Class3;PeakThroughput:2048kbit/s;MeanThroughput:BestEffort測試終端采用SAGEMOT290或SAGEMOT490;測試手機要求K或以上版本;手機設置為自動雙頻模式;串口速率設置為115200;時隙設置為3+1/4+1模式;測試模式設置為Data/Trace測試軟件采用CDS3.0以上版本測試電腦應保證1.2G以上主頻，256M以上內(nèi)存;重新安裝WindowsXP操作系統(tǒng),不能安裝與測試無關(guān)的軟件;將托盤中的任何與網(wǎng)絡通訊相關(guān)的程序關(guān)閉,如MSN等;關(guān)閉Windows的自動更新功能第7頁/共108頁GPRS數(shù)據(jù)業(yè)務測試的影響因素GPRS業(yè)務測試準備保證Ping和FTP的測試服務器正常工作。同時應保證用戶具有上傳和下載數(shù)據(jù)的權(quán)限,保證可對服務器進行Ping和FTP測試被測城市應保證其測試服務器在測試檢查期間的可用性，如果當?shù)胤掌鞑荒苁褂茫瑴y試人員將選擇異地服務器進行測試保證郵件系統(tǒng)的正常工作準備大小為150K，500K的文件若干確認WAP測試站點正常工作,由運營商指定第8頁/共108頁GPRS數(shù)據(jù)業(yè)務測試原則CQT測試原則測試時間：視客戶要求而定，通常安排在周一至周五9:00-19:00進行地點選擇原則：

1.在城市中選20-40個測試點。具體測試點分布要求:火車站、機場、三星級以上酒店、大型商場休閑區(qū)、大學學校、大型居民區(qū)、商務場所、旅游景區(qū)

2.測試點按照地理、話務因素綜合考慮均勻分布，突出重點區(qū)域

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

GPRS現(xiàn)狀與GPRS業(yè)務測試概述

GPRS業(yè)務測試內(nèi)容

GPRS業(yè)務測試工具介紹

GPRS專題優(yōu)化介紹及案例分析第11頁/共108頁GPRS測試項目介紹GPRS測試目的和分類測試目的：通過對市區(qū)重要場所和市區(qū)主要道路測試，從用戶感受的角度評估城市GPRS網(wǎng)絡質(zhì)量，為GPRS網(wǎng)絡優(yōu)化提供參考和依據(jù)按照測試形式可以分為兩類：路測（DT，DriveTest）、定點撥打測試(CQT，CallQualityTest)???第12頁/共108頁GPRS測試項目介紹GPRS測試項目GPRSAttach時延、成功率測試GPRSPDP激活時延、成功率測試Ping時延、成功率測試FTP下載、上傳速率WAP登陸、刷新時延、成功率測試WAP下載(圖鈴)速率、成功率測試Kjava下載成功率測試SMS點到點時延、成功率測試MMSPUSH時延、PUSH成功率、端到端成功率測試FTP下載、上傳速率WAP登陸、刷新時延、成功率測試WAP下載(圖鈴)速率、成功率測試CQTDT第13頁/共108頁GPRS測試項目介紹CQT測試內(nèi)容定義和方法KPI定義測試方法精度統(tǒng)計粒度ATTACH平均附著時長各次attach成功的時間相加/成功attach的次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次ATTACH附著成功率GPRS成功Attach次數(shù)/總嘗試次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次PDP激活平均時長各次PDP激活成功的時間相加/成功attach的次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次PDP激活成功率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次第14頁/共108頁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次鈴聲第15頁/共108頁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ù)／用戶應接收PUSH消息條數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次MMS端到端成功率用戶成功提取彩信的次數(shù)／用戶嘗試提取彩信的次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次CQT測試內(nèi)容定義和方法第16頁/共108頁GPRS測試項目介紹KPI定義測試方法精度統(tǒng)計粒度SMS端到端PUSH平均時長各次短信接收成功的時間相加/短信成功接收的次數(shù)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01秒10次SMS端到端PUSH成功率用戶成功接收短信條數(shù)／用戶應接收短信條數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%10次CQT測試內(nèi)容定義和方法第17頁/共108頁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%第18頁/共108頁GPRS測試項目介紹KPI定義測試方法精度WAP平均圖鈴下載速率實際成功下載數(shù)據(jù)量（Byte）/實際成功下載時間(秒)使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01KBit/SWAP圖鈴下載成功率WAP鈴聲、圖片成功下載次數(shù)/嘗試鈴聲、圖片下載次數(shù)×100％使用測試終端和測試軟件，自動記錄測試日志,由測試軟件統(tǒng)計功能給出0.01%覆蓋率

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)容定義和方法第19頁/共108頁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)容定義和方法第20頁/共108頁GPRS測試項目介紹測試項目超時定義KPI超時時間KPI超時時間ATTACH附著時長15SFTP下載時長(CQT)180SPDP激活時長15SFTP下載時長(DT)180SMMS接收時長100S(有些設置為150S)SMS接收時長300SPing時長5SKjava下載時長300SWAP首頁顯示時間(CQT)60SWAP首頁顯示時間(DT)60SWAP頁面刷新時間(CQT)60SWAP頁面刷新時間(DT)60SWAP圖鈴下載時長(CQT)150SWAP圖鈴下載時長(DT)200S第21頁/共108頁目錄Internet

GPRS現(xiàn)狀與GPRS業(yè)務測試概述

GPRS業(yè)務測試內(nèi)容

GPRS業(yè)務測試工具介紹

GPRS專題優(yōu)化介紹及案例分析第22頁/共108頁GPRS測試軟件CDS的使用方法CDS用戶界面第23頁/共108頁GPRS測試軟件CDS的使用方法CDS軟件裝載說明第24頁/共108頁測試中常見問題總結(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)絡通訊相關(guān)的程序關(guān)閉,如MSN等;關(guān)閉Windows的自動更新功能，否則會影響Ping、FTP等所有與數(shù)據(jù)上傳、下載有關(guān)的測試項目測試手機各參數(shù)一定要設置正確，測試手機必須為K或以上軟件版本第25頁/共108頁測試中常見問題總結(jié)WAP刷新不是刷新首頁，而是深度為3的隨機刷新準確設置測試項目時間間隔以及超時時間，這些測試項目屬性的設置對測試結(jié)果有很大影響每個測試點測試前需要重啟一下測試手機，這樣不僅可以清除緩存空間，也可以使測試手機選擇到最好小區(qū)WAP圖鈴下載的URL不同，下載速率的差別也很大WAP測試應以所有文字信息全部顯示為準，所以應在WAP測試時去掉設置中的“下載頁面中的圖標”選項當FTP測試中出現(xiàn)長時間無流量時，可讓司機適當降低車速MMS測試中最好選擇NOKIA智能手機做為測試終端（不同手機測試測試結(jié)果差別很大）第26頁/共108頁

GPRS現(xiàn)狀與GPRS業(yè)務測試概述

GPRS業(yè)務測試內(nèi)容

GPRS業(yè)務測試工具介紹

GPRS專題優(yōu)化介紹及案例分析Internet目錄第27頁/共108頁專題—ATTACH問題Attach優(yōu)化方法關(guān)閉SGSN鑒權(quán)檢查覆蓋防止頻繁的小區(qū)重選排查干擾，提高C/I檢查RACH或AGCH信道配置檢查靜態(tài)PS信道、動態(tài)PS信道配置檢查GPRSENABLED參數(shù)設置檢查Gblinksload，調(diào)整NSEI配置第28頁/共108頁專題—ATTACH問題Attach故障案例一:手機無法登陸GPRS網(wǎng)絡問題描述某區(qū)域用戶反應不能登陸GPRS網(wǎng)絡，檢查網(wǎng)絡配置無異常，實地測試的確無法登陸GPRS網(wǎng)絡。故障分析進行了GPRS配置數(shù)據(jù)檢查，開通GPRS功能小區(qū)的NSEI、NSVI、RAC等各項GPRS參數(shù)配置均正確檢查BSCBRP板配置，發(fā)現(xiàn)有一塊BRP板已經(jīng)配置了21個靜態(tài)GPRS信道和41個GPRS動態(tài)信道，總數(shù)超過了每塊BRP板上PS信道的配置要求解決方法調(diào)整該BRP板上配置的GPRS信道數(shù)，保存配置數(shù)據(jù)后業(yè)務恢復正常。第29頁/共108頁專題—ATTACH問題Attach故障案例二:手機無法登陸GPRS網(wǎng)絡

問題描述：有用戶反映手機GPRSAttach不能成功。現(xiàn)象為手機發(fā)送Attachrequest，SGSN返回attachaccept消息，而后面BSC上發(fā)信令為LLCunkowninformation。故障分析：根據(jù)信令流程，BSS側(cè)負責TBF流的建立，后面應為手機和SGSN的透傳信令，正常流程應為手機向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無法分配，用戶無法上GPRS。解決方法：將P-TMSI由disable調(diào)整為enable，故障解決。第30頁/共108頁專題—ATTACH問題Attach故障案例三:ATTACH失敗問題：頻繁的小區(qū)重選（60021→60332→60021）導致ATTACH時延過長（14.55s）。解決方案：提高60021CRH由8dB到10dB,調(diào)整60332RXLEVACCESSMIN由10dB到12dB第31頁/共108頁專題—ATTACH問題Attach故障案例四:ATTACH失敗問題：網(wǎng)絡向手機發(fā)送PacketAccessReject消息作為對PacketResourceRequest消息的應答，此消息中包含“Wait_Indication”域，其值賦予T3172，當手機收到PacketAccessReject消息后，啟動T3172，在T3172運行期間，網(wǎng)絡不允許手機在同一小區(qū)內(nèi)再次發(fā)起分組接入嘗試。該事件由無線資源緊張所致。解決方案：擴充靜態(tài)PS信道。第32頁/共108頁專題—PDP激活問題PDP激活優(yōu)化方法關(guān)閉SGSN鑒權(quán)檢查核心網(wǎng)各網(wǎng)元處理能力（DNS解析APN錯誤或者過慢、GGSN關(guān)于APN的配置數(shù)據(jù)不完整、DHCP或RADIUS服務器故障、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配置檢查GPRS參數(shù)設置，合理設置DrxTimeMax、MFR、T3168第33頁/共108頁專題—PDP激活問題PDP故障案例一:PDP激活失敗問題：在20022重選到20281后，由于20281AGCH緊張導致。解決方案：控制20281覆蓋范圍，適當增加20281AGCH配置。第34頁/共108頁專題—PDP激活問題PDP故障案例二:PDP激活失敗問題：由于連續(xù)發(fā)生兩次小區(qū)重選（CELLID:10071Channel:2—CELLID:111Channel:90—CELLID:114Channel:512）長時間無時隙分配引起PDP激活失敗。解決方案：提高60021CRH由6dB到10dB。第35頁/共108頁專題—PDP激活問題PDP故障案例三:PDP激活失敗問題：由于沒有申請到PS信道導致PDP激活失敗。解決方案：增加8540站點的靜態(tài)PS信道，將MFR由5調(diào)整到2。第36頁/共108頁專題—PDP激活問題PDP故障案例四:PDP激活失敗問題：在CQT測試時經(jīng)常出現(xiàn)偶爾PDP激活時延過長的現(xiàn)象。經(jīng)過對10個點100次的PDP激活測試,發(fā)現(xiàn)7次時延異常的現(xiàn)象，具體掛表結(jié)果如下：第37頁/共108頁專題—PDP激活問題PDP故障案例四:PDP激活失敗正常情況下幾個接口上的耗時情況如下：第38頁/共108頁專題—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)收到后及時給予了響應。導致這種現(xiàn)象的原因可能是Accountingrequest消息在傳輸中丟失或者Radius的處理異常。另外六次則是因為Gb口以下和Radius與WAP網(wǎng)關(guān)間的耗時過長。GGSN向Radius發(fā)送AccountingRequest消息，等待Radius的響應，并啟動相應的等待定時器，在相應的WAP網(wǎng)關(guān)側(cè)，我們發(fā)現(xiàn)WAP網(wǎng)關(guān)在收到AccountingRequest消息后沒有給予響應，由于GGSN沒有收到AccountingRequest消息的響應消息，導致等待定時器超時，然后GGSN重新發(fā)送AccountingRequest消息，在相應的WAP網(wǎng)關(guān)側(cè)，我們發(fā)現(xiàn)WAP網(wǎng)關(guān)此次給予了響應，GGSN收到Radius轉(zhuǎn)發(fā)的AccountingResponse消息，這時GGSN才對手機的PDP激活請求進行響應。第39頁/共108頁專題—PDP激活問題PDP故障案例四:PDP激活失敗正是由于Gi口的耗時過長，使得無線側(cè)的定時器超時而釋放了TBF資源，所以手機在接收PDP激活接受消息時，重新進行了TBF的建立，這又進一步增加了在無線口上的延時。因此，WAP網(wǎng)關(guān)的響應過慢，是導致PDP激活時延過長根本原因。第40頁/共108頁專題—PDP激活問題PDP故障案例五:PDP激活失敗在中國移動集團公司第三方測試的準備工作中，發(fā)現(xiàn)GPRSCQT的火車站測試點有PDP激活失敗的現(xiàn)象，并且多次測試問題始終存在。從信令來看，當下行的立即指配信息里出現(xiàn)了右圖中ARFCN為809的時候，PDP激活會不成功。第41頁/共108頁專題—PDP激活問題PDP故障案例五:PDP激活失敗809這個頻點是不正常的，但這是根據(jù)手機收到基站發(fā)出的層三消息解出來的。這個立即支配消息是為了分配下行的TBF，也就是意味著網(wǎng)絡已收到PDP激活申請且給手機回復了PDPactivateaccept消息，但此消息未能通過空中接口。當時懷疑是否因測試軟件導致，詢問CDS軟件研發(fā)工程師，回復軟件應該沒有問題，也不像測試手機問題，所以網(wǎng)絡下發(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)的信令。見下圖：

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

第55頁/共108頁專題—WAP問題WAP錯誤代碼含義—WSP層協(xié)議發(fā)生錯誤

第56頁/共108頁專題—WAP問題WAP錯誤代碼含義—HTTP協(xié)議發(fā)生錯誤

第57頁/共108頁專題—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配置檢查GPRS參數(shù)設置，合理設置DrxTimeMax、MFR、T3168第58頁/共108頁專題—MMS問題MMS故障案例一:MMS發(fā)送失敗問題：通過掛表發(fā)現(xiàn)手機首先PDP激活，APN為CMWAP，但是手機隨后沒有任何發(fā)起任何信令。這種情況是由于手機軟件進程吊死所致。解決方案：重裝手機操作系統(tǒng)。第59頁/共108頁專題—MMS問題MMS故障案例二:MMS接收失敗問題：通過掛表發(fā)現(xiàn)手機首先建立了WSP層的連接，然后發(fā)起GET請求接收彩信，隨后WAP網(wǎng)關(guān)將彩信在WTP分割后，向手機發(fā)送WTP層的分段，當傳送到第六個分段后該消息中的GTR和TTR都為0，說明該分段既不是整個消息中某組的最后一塊，也不是整個消息的最后一塊，但是手機卻回應了ACK，緊接著又發(fā)起一個Transaction(Invoke)。這種情況是由于手機軟件故障所致。解決方案：重裝手機操作系統(tǒng)。第60頁/共108頁專題—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)。第61頁/共108頁專題—MMS問題MMS故障案例四:MMS發(fā)送失敗問題：通過掛表我們發(fā)現(xiàn)手機首先上行發(fā)送WSP層的Connect信令，建WSP層的連接，但是WAP網(wǎng)關(guān)沒有回應ConnectReply，手機等待5秒后重Connect，但是始終沒有回應ConnectReply，達到最大重發(fā)次數(shù)5次后，WSP層的建鏈失敗，最終導致彩信發(fā)送失敗。導致此次MMS發(fā)送失敗的原因為WAP網(wǎng)關(guān)過于繁忙沒有回應ConnectReply。解決方案：請核心網(wǎng)工程師配合解決。第62頁/共108頁專題—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的比例檢查GPRS參數(shù)設置，合理設置DrxTimeMax、MFR、T3168、T3192打開CS3、CS4第63頁/共108頁專題—FTP問題FTP故障案例一:FTP下載失敗問題：MS重選到小區(qū)41921后，DLTBF一直沒被建立導致長時間下行無數(shù)據(jù)傳輸，最終導致了PDP掉線.經(jīng)檢查該小區(qū)在測試時間段內(nèi)的GPRSKPI：下行時隙分配擁塞率比較高，這是為什么沒能建立DLTBF的主要原因所在。解決方案：增加該小區(qū)靜態(tài)PS信道。第64頁/共108頁專題—FTP問題FTP故障案例二:FTP下載速率過低問題：第一次cellreselection（90→52）使數(shù)據(jù)傳輸恢復時間變長而導致長時間TBF掛起。之后重建時由于小區(qū)30553數(shù)據(jù)業(yè)務繁忙只申請到一條PS信道，在數(shù)據(jù)下傳過程中又發(fā)生了第二次cellreselection（52→80），然后因為數(shù)據(jù)傳輸恢復時間變長而導致長時間TBF掛起。在重建時小區(qū)30152數(shù)據(jù)業(yè)務繁忙導致一直申請不到下行的PS信道導致三次PING失敗，最終申請到了4條PS信道，下載成功。導致平均下載速率只有8.11kbit/s。解決方案：擴充30553、30152靜態(tài)PS信道；調(diào)整30553RXLEVACCESSMIN由10到12。第65頁/共108頁專題—FTP問題FTP故障案例三:FTP下載失敗問題：MS從43372重選到42093后，又從42093重選到1531后又頻繁重選回1531后，電平降到-94dBm，拖了一段時間后PDP掉線。解決方案：控制42093、1531覆蓋。第66頁/共108頁專題—FTP問題FTP故障案例四:FTP下載失敗問題：MS跨LAC從83重選到1483后，就頻繁的小區(qū)重選1483→18621→741，導致長時間的TBF掛起，最終PDP掉線。從地形看，該處是一座立交橋，橋下無主控區(qū)。解決方案：調(diào)整1483CRH由6到10，確定該地點的主控小區(qū)。第67頁/共108頁專題—FTP問題FTP故障案例五:FTP下載速率低問題：MS拿到的PDCH不穩(wěn)定，跳變頻繁，PS爭搶頻繁，導致了DLFTP速率低。解決方案：增加CI2631的靜態(tài)PS信道。第68頁/共108頁專題—FTP問題FTP故障案例六:FTP下載速率低案例說明：在**路和**橋路附近，手機從宏站小區(qū)重選至室外微蜂窩52484（八萬人體育館），BCCH＝109。由于室外微蜂窩主要是針對某個熱點地區(qū)，或者覆蓋比較差的區(qū)域采用的覆蓋方式。我們在GPRS測試時，車經(jīng)過室外微蜂窩的時間比較短，盡量不要讓手機重選至這樣的小區(qū)，這樣會增加小區(qū)重選的次數(shù)和減少吞吐量。在這個案例中，我們發(fā)現(xiàn)這個小區(qū)主要是覆蓋八萬人體育場的外場，所以我們鼓勵慢速移動的手機占用此小區(qū)，快速移動的手機不要重選進這樣的小區(qū)。52484參數(shù)設置為：PET=20s，TEO=0。為了保證手機在一段時間內(nèi)不重選進此小區(qū)，設置PET＝20s，TEO＝30db，即在52484的信號出現(xiàn)在MS的鄰區(qū)20s內(nèi)給C2一個人為的衰減值30db，使其他小區(qū)的C1，C2大過本小區(qū)5s，這樣手機即不會選進室外微蜂窩。第69頁/共108頁專題—FTP問題FTP故障案例六:FTP下載速率低第70頁/共108頁專題—FTP問題FTP故障案例六:FTP下載速率低問題：在復測時我們發(fā)現(xiàn)，在同一個地點，此時52484的C1=25，C2＝21，從15:40:33.764至15:53:586持續(xù)20s后，C2值升至53。由于復測時，車行駛的地方為一個交通燈口，車流量大、擁堵。我們原先設置的PET＝20s遠遠小于堵車的時間。解決方案：將這個小區(qū)的PET設置為200s，這樣小區(qū)重選發(fā)生的可能性就大大降低了。第71頁/共108頁專題—高BLERBLER概述BLER反應信道受干擾的情況，但在小數(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層速率，這些都是反應信道質(zhì)量的重要指標。第72頁/共108頁專題—高BLERBLER案例1—內(nèi)部干擾問題問題：是該站點覆蓋小區(qū)，但是高BLER。解決方案：更改GTRX或者更換頻點。第73頁/共108頁專題—高BLERBLER案例2—小區(qū)重選問題問題：已經(jīng)越過了該小區(qū)的主控范圍，但是不向鄰小區(qū)重選。解決方案：調(diào)高該鄰小區(qū)的CRH。第74頁/共108頁專題—小區(qū)重選問題小區(qū)重選的時候手機會暫時中斷數(shù)據(jù)傳輸，在這里數(shù)據(jù)中斷的時長主要包括：重選后數(shù)據(jù)暫停的時間、TCPSlowStart啟動的時間，這一過程大約需要4~10秒，直至TCP正常傳輸。路測過程中，要特別注意觀察，是否有頻繁小區(qū)重選或乒乓小區(qū)重選發(fā)生，小區(qū)信號覆蓋過小或不穩(wěn)定都會導致頻繁、乒乓小區(qū)重選，同時還要注意觀察，是否由于小區(qū)重選參數(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來檢驗就可以看到GPRS連接已經(jīng)恢復。在TCP的數(shù)據(jù)連接恢復過程中再次發(fā)生的小區(qū)重選會嚴重影響給TCP的數(shù)據(jù)連接恢復。小區(qū)重選與路由更新概述第75頁/共108頁專題—小區(qū)重選與路由更新問題小區(qū)重選與路由更新概述小區(qū)重選的時候手機會暫時中斷數(shù)據(jù)傳輸，在這里數(shù)據(jù)中斷的時長主要包括：重選后數(shù)據(jù)暫停的時間、TCPSlowStart啟動的時間，這一過程大約需要4~10秒，直至TCP正常傳輸。路測過程中，要特別注意觀察，是否有頻繁小區(qū)重選或乒乓小區(qū)重選發(fā)生，小區(qū)信號覆蓋過小或不穩(wěn)定都會導致頻繁、乒乓小區(qū)重選，同時還要注意觀察，是否由于小區(qū)重選參數(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來檢驗就可以看到GPRS連接已經(jīng)恢復。在TCP的數(shù)據(jù)連接恢復過程中再次發(fā)生的小區(qū)重選會嚴重影響TCP數(shù)據(jù)連接的恢復。第76頁/共108頁專題—小區(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ù)連接恢復帶來負作用，路測過程中應觀察重要路段或重要場所是否有不合理的RAU事件發(fā)生。在RAU之后可以使用PING來驗證GPRS承載已經(jīng)恢復。小區(qū)重選與路由更新概述第77頁/共108頁專題—小區(qū)重選與路由更新問題小區(qū)重選案例1—C2參數(shù)設置不合理問題問題：車輛沿機場高速從北向南行駛，紅圈處占用小區(qū)高教科研4（BCCH：560）。繼續(xù)南行，高教科研4的電平逐漸降低，低至－94dBm以下時，仍不發(fā)生小區(qū)重選。長時間電平小于－94dBm，造成無覆蓋。經(jīng)檢查發(fā)現(xiàn)此時該小區(qū)與相鄰小區(qū)的小區(qū)重選參數(shù)設置情況如下：第78頁/共108頁專題—小區(qū)重選與路由更新問題小區(qū)重選案例1—C2參數(shù)設置不合理問題

小區(qū)名Rexlev（dBm）RXLEVACCESSMINCRHCROTOC2高教科研4-103-100826023下墟3-80-10088028殷巷3-84-100810026解決方案：控制小區(qū)高教科研4（BCCH：560）的覆蓋，修改高教科研4小區(qū)CRO由26到20。第79頁/共108頁專題—小區(qū)重選與路由更新問題路由更新案例1—跨越SGSN路由區(qū)更新故障

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

(1)

每個MSC到SGSN的歸屬位置

(2)

每個BSC到MSC的歸屬位置

(3)

每個小區(qū)的歸屬的RAC區(qū)以上3個參數(shù)必須與現(xiàn)行網(wǎng)絡中硬件設備的連接一致才能保證GPRS手機路由更新的正常進行。第80頁/共108頁專題—NSEI規(guī)劃NSEI規(guī)劃概述GPRS協(xié)議棧BSSGP層中，為了便于管理，每個GPRS小區(qū)被賦予了一個BSSGP虛連接BVC（NSEI＋BVCI），一個BVC必須隸屬于一個NSE。其中NSE為網(wǎng)絡服務設備實體，是全網(wǎng)統(tǒng)一編碼的，以NSEI來標識。一般來說一個BSC被劃分為一個服務實體，為了可擴展性，ZXG10系統(tǒng)中也允許BSC下掛若干個NSE。BSSGP虛連接（BVC）為不同的BSSGP實體間通訊提供了一種途徑。對等的PTP（點對點）、PTM（點對多）和信令實體間傳送BSSGPPDU時是以BVC為基礎的。每條虛連接都有一個標識，為BVCI，它能使底層網(wǎng)絡服務層將BSSGPPDU高效地路由到對等實體上。在一個網(wǎng)絡服務實體（NSE）下，每個GPRS小區(qū)可由BVCI唯一標識，一個網(wǎng)絡服務實體有且僅有一條信令BVC（BVCI=0）。第81頁/共108頁專題—NSEI規(guī)劃NSEI規(guī)劃前在網(wǎng)絡優(yōu)化之前沒有優(yōu)化過NSEI，PCU的分配很是隨便，甚至一個站上的兩個小區(qū)都不在一個PCU下，這對GPRSperformance有很大影響。因此,我們需要重新分配NSEI。比如下圖就是沒有經(jīng)過合理配置的NSEI：第82頁/共108頁專題—NSEI規(guī)劃NSEI規(guī)劃后在優(yōu)化期間，PCU需要定期重新規(guī)劃，也即重新分配小區(qū)的NSEI，在物理位置上盡量靠近，這樣做的目的是為了在GPRSDT的過程中避免頻繁的RAU，從而提高GPRSDT的Performance。下圖就是經(jīng)過優(yōu)化過的NSEI分配：專題—NSEI規(guī)劃第83頁/共108頁專題—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值。第84頁/共108頁專題—PANDEC、PANINC參數(shù)實驗PANDEC、PANINC概述

在無線鏈路失敗控制中，PAN參數(shù)將與MS側(cè)的定時器N3102一起使用。當移動臺檢測到發(fā)送窗口停止轉(zhuǎn)動時（V(S)=V(A)+WS），移動臺應啟動定時器T3182；在收到PACKETUPLINKACK/NACK導致V(S)<V(A)+WS時，則停止T3182；當T3182超時后，移動臺將把計數(shù)器N3102減去PANDEC，并執(zhí)行該TBF的異常釋放并接入重試；當移動臺收到網(wǎng)絡發(fā)送的“分組上行證實/未證實”消息允許V(S)或V(A)增加時，移動臺將把計數(shù)器N3102增加PANINC，但是N3102值不能超過PANMAX所定義的值；當N3102≤0時，MS將執(zhí)行該TBF的異常釋放，并將觸發(fā)小區(qū)重選。如果PANDEC，PANINC和PANMAX置為0值時，計數(shù)器N3102就無效。

增加PANMAX和PANINC，減小PANDEC，可以減少MS在收不到PacketUplinkAck時TBF異常釋放并進行小區(qū)重選的可能，但也使MS在發(fā)送窗口停止，不能發(fā)送數(shù)據(jù)的情況下，較長時間占據(jù)無線資源，資源利用率不高。而減小PANMAX和PANINC，增加PANDEC，則容易使手機發(fā)生TBF異常釋放并進行小區(qū)重選，降低小區(qū)TBF正常釋放比例，影響數(shù)據(jù)傳輸速率。

第85頁/共108頁專題—PANDEC、PANINC參數(shù)實驗PANDEC、PANINC參數(shù)調(diào)整實驗參數(shù)名重要性參數(shù)類型原值修改值BSCMSCPAN_DEC

高CELL02BSC19MSC06PAN_INC

高CELL01BSC19MSC06試驗結(jié)果：總體而言，對公里無覆蓋比等GPRSDT測試指標有明顯改善。第86頁/共108頁專題—PANDEC、PANINC參數(shù)實驗PANDEC、PANINC參數(shù)調(diào)整實驗前后相關(guān)區(qū)域電平分布圖第87頁/共108頁專題—MFR、DRX參數(shù)實驗MFR、DRX概述MFR（BS_PA_MFRMS）在每個小區(qū)中每個尋呼組都對應于一個尋呼子信道，移動臺根據(jù)自身的IMSI計算出它所屬的尋呼組，進而計算出屬于該尋呼組的尋呼子信道位置，在實際網(wǎng)絡中，移動臺只“收聽”它所屬的尋呼子信道而忽略其它尋呼子信道的內(nèi)容，甚至在其它尋呼子信道期間關(guān)閉移動臺中某些硬件設備的電源以節(jié)約移動臺的功率開銷（即DRX的來源）。尋呼信道復幀數(shù)（MFR）是指以多少復幀數(shù)作為尋呼子信道的一個循環(huán)。第88頁/共108頁專題—MFR、DRX參數(shù)實驗MFR、DRX概述DRX（DRX_TIMER_MAX）在DRX模式中，MS僅收聽歸屬尋呼組的尋呼塊，而在非DRX模式下，MS將收聽所有的CCCH塊。非DRX模式持續(xù)的時間由兩個參數(shù)共同決定：NON_DRX_TIMER和DRX_TIMER_MAX，等于兩者的最小值。DRX_TIMER_MAX設定MS在從分組傳輸模式進入分組空閑模式時，執(zhí)行NON-DRX模式時長的最大值。NON_DRX_TIMER由MS在GPRS附著的過程中和SGSN協(xié)商。NON_DRX_TIMER的大小可以在ATTACHREQUEST中看到；DRX_TIMER_MAX的數(shù)值可從SystemInformationType13中看到。

DRX_TIMER_MAX的取值范圍為0～7，表達的取值遵循公式：2k-1（其中k=0時，表示參數(shù)值為0），即參數(shù)取值為：0，1s、2s、4s……64s。第89頁/共108頁專題—MFR、DRX參數(shù)實驗DRX模式與非DRX模式概述

當移動臺處在DRX模式的時候，移動臺只會監(jiān)聽和它尋呼組相關(guān)的尋呼子信道。若PCU判斷該MS正處于DRX模式時，它將計算MS屬于哪個尋呼組，并向BTS發(fā)出資源分配消息，當BTS收到該消息后將在MS所偵聽的CCCH信道上發(fā)出立即指配消息。BS_PA_MFRMS定義了尋呼信道的復幀數(shù)，目前現(xiàn)網(wǎng)的默認設置是5，也就是說MS在收聽了自己尋呼組所對應的CCCH塊后，將等待4個51復幀，繼續(xù)收聽的將是第6個51復幀的同樣位置的CCCH塊。MS如果錯過了自己所偵聽的尋呼子信道，它將不得不再等待，直到下一個尋呼子信道到來。如果MFR=5，那么在最壞的情況下，MS要收到立即指配的消息，就必須等待：5×235ms=1175ms。如果立即指配消息隨機出現(xiàn)，MFR=5，MS要等待的平均時間就是：

235ms×（5+4+3+2+1）/5=705ms

如果立即指配消息隨機出現(xiàn)，MFR=2，等待的平均時間就減少為：

235ms×（2+1）/2=352.5ms節(jié)約的時間為352.5ms?。。〉?0頁/共108頁專題—MFR、DRX參數(shù)實驗DRX模式與非DRX模式概述

當MS由分組傳輸模式返回分組空閑模式時（比如TBF釋放），在DRX_TIMER_MAX與NON_DRX_TIMER的共同作用下，如果MS進入非DRX傳輸?shù)臓顟B(tài)，將如下圖所示：

在非DRX模式期間內(nèi)，MS將收聽所有的CCCH塊，同時PCU保留MS相關(guān)的上下文。此時下行TBF建立的立即指配消息不需要再計算尋呼組，可以直接在AGCH上發(fā)送。所以設置了非DRX模式后會大大縮短下行TBF的建立時間，缺點是會加快手機電池的消耗。第91頁/共108頁專題—MFR、DRX參數(shù)實驗MFR、DRX參數(shù)實驗結(jié)果第92頁/共108頁專題—T3192參數(shù)實驗T3192概述

當MS向網(wǎng)絡發(fā)送“最后證實標志”（FAI）等于“1”的“分組下行證實/未證實”(PACKET

DOWNLINK

ACK/NACK)消息時啟動定時器T3192，或者在以非確認模式發(fā)送“分組控制證實”（PACKETCONTROLACK）作為最后一個數(shù)據(jù)塊的響應時，MS啟動定時器T3192。在T3192期間，滿足啟動條件時，將重新啟動T3192。當移動臺收到PCU發(fā)送的“分組下行指配”（PACKET

DOWNLINKASSIGNMENT）消息或“分組時隙重新配置”（PACKETTIMESLOTRECONFIGURE）時，停止定時器T3192。如果T3192超時，MS將釋放TBF相關(guān)資源并開始監(jiān)聽尋呼信道。此參數(shù)以500ms為單位進行配置。在TBF釋放階段，如果MS處于半雙工狀態(tài)并且收到上行指配，MS將立即響應該命令；如果在TBF釋放階段沒有收到上行指配，MS將進入分組空閑模式，在雙傳輸模式時將進入專用模式。在進入空閑模式或?qū)Ｓ媚Ｊ綍r，根據(jù)協(xié)議，仍舊需要執(zhí)行一段非DRX時間。第93頁/共108頁專題—T3192參數(shù)實驗T3192概述

該參數(shù)的設置越大，TBF相關(guān)資源保留（包括TFI和時隙）的時間就越長，相同TBF傳送占用的時間就越長，容易導致?lián)砣?。而該參?shù)設置越小，因為MS將很快將TBF資源釋放掉，若網(wǎng)絡有新的下行數(shù)據(jù)到來，網(wǎng)絡必須發(fā)起尋呼或立即指配流程（若MS處于就緒狀態(tài)），所以下行TBF建立的時間就越長。而如果網(wǎng)絡側(cè)新的下行數(shù)據(jù)到來時，T3192還未超時，則網(wǎng)絡可以直接發(fā)送“分組下行指配”消息，來建立一個新的下行TBF，縮短TBF的建立時間。該參數(shù)的設置，應充分考慮該小區(qū)的業(yè)務負荷、小區(qū)的業(yè)務模型，網(wǎng)絡資源較充足的情況下，應盡量設置T3192較大，減少新TBF建立時間，提高數(shù)據(jù)傳輸速率。網(wǎng)絡側(cè)有相對應的計數(shù)器T3193，要求T3193必須大于T3192。第94頁/共108頁專題—T3192參數(shù)實驗T3192參數(shù)實驗結(jié)果 T3192設置為0.5秒，T3192會影響TBF建立時間的長短，常規(guī)情況下，當一組數(shù)據(jù)RLC傳完之后，手機會啟動T3192，等待0.5秒(注意剛才在使用PDCH時隙)，如果沒有續(xù)傳的指令，T3192超時，釋放下行TBF而且開始監(jiān)視Paging信道。當再次有數(shù)據(jù)傳時，需要重新立即指配。這無形中延長了TBF建立時間。 T3192設置為1.5秒，容易導致GPRSterritoryugradereject(%)，而且增加了PDP激活時間，降