GPRS測試中案例分析.ppt

1、GPRS業(yè)務測試案例分析,目錄,Internet,GPRS業(yè)務測試工具介紹 GPRS專題優(yōu)化介紹及案例分析,GPRS測試軟件CDS的使用方法,CDS用戶界面,測試中常見問題總結,CDS 4.0版本現在還不穩(wěn)定，在信令解碼（比如C/I、RxQual、Ms-TxPower等）中存在一些BUG 在采集參數選項中CDS默認只采集GSM C/I Trace和RLC/MAC Control MSG,其實LLC MSG等參數選項對事件的分析也能起到一定作用，最好將信令采集完整 注意測試用筆記本電腦在安裝測試軟件前必須重裝操作系統(tǒng)，不能安裝與測試無關的其它軟件;將托盤中的任何與網絡通訊相關的程序關閉,如MSN

2、等;關閉Windows的自動更新功能，否則會影響Ping、FTP等所有與數據上傳、下載有關的測試項目 測試手機各參數一定要設置正確，測試手機必須為K或以上軟件版本,測試中常見問題總結,WAP刷新不是刷新首頁，而是深度為3的隨機刷新 準確設置測試項目時間間隔以及超時時間，這些測試項目屬性的設置對測試結果有很大影響 每個測試點測試前需要重啟一下測試手機，這樣不僅可以清除緩存空間，也可以使測試手機選擇到最好小區(qū) WAP圖鈴下載的URL不同，下載速率的差別也很大 WAP測試應以所有文字信息全部顯示為準，所以應在WAP測試時去掉設置中的“下載頁面中的圖標”選項 當FTP測試中出現長時間無流量時，可讓司機

3、適當降低車速 MMS測試中最好選擇NOKIA智能手機做為測試終端（不同手機測試測試結果差別很大）,GPRS業(yè)務測試工具介紹 GPRS專題優(yōu)化介紹及案例分析,Internet,目錄,專題ATTACH問題,Attach優(yōu)化方法 關閉SGSN鑒權 檢查覆蓋 防止頻繁的小區(qū)重選 排查干擾，提高C/I 檢查RACH或AGCH信道配置 檢查靜態(tài)PS信道、動態(tài)PS信道配置 檢查GPRS ENABLED參數設置 檢查Gb links load，調整NSEI配置,專題ATTACH問題,Attach故障案例一: 手機無法登陸GPRS網絡,問題描述 某區(qū)域用戶反應不能登陸GPRS網絡，檢查網絡配置無異常，實地測試的

4、確無法登陸GPRS網絡。 故障分析 進行了GPRS配置數據檢查，開通GPRS功能小區(qū)的NSEI、NSVI、RAC等各項GPRS參數配置均正確 檢查BSC BRP板配置，發(fā)現有一塊BRP板已經配置了21個靜態(tài)GPRS信道和41個GPRS動態(tài)信道，總數超過了每塊BRP板上PS信道的配置要求 解決方法 調整該BRP板上配置的GPRS信道數，保存配置數據后業(yè)務恢復正常。,專題ATTACH問題,Attach故障案例二: 手機無法登陸GPRS網絡,問題描述： 有用戶反映手機GPRS Attach 不能成功。現象為手機發(fā)送Attach request，SGSN 返回attach accept 消息，而后面B

5、SC上發(fā)信令為LLC unkown information。 故障分析： 根據信令流程，BSS側負責TBF流的建立，后面應為手機和SGSN的透傳信令，正常流程應為手機向SGSN發(fā)送Attach complete。檢查BSC相關數據沒有發(fā)現問題。從全局測試來看，與SGSN對接的所有BSC下所帶基站都有相同問題情況，初步判斷為SGSN側的問題。經SGSN的工程師檢查，有數據改動，即P-TMSI 由原來的enable 改為disable。導致P-TMSI無法分配，用戶無法上GPRS。 解決方法： 將P-TMSI由disable調整為enable，故障解決。,專題ATTACH問題,Attach故障案例

6、三: ATTACH失敗,問題：頻繁的小區(qū)重選（600216033260021）導致ATTACH時延過長（14.55s）。 解決方案：提高60021CRH由8dB到10dB,調整60332RXLEVACCESSMIN由10dB到12dB,專題ATTACH問題,Attach故障案例四: ATTACH失敗,問題：網絡向手機發(fā)送Packet Access Reject消息作為對Packet Resource Request消息的應答，此消息中包含“Wait_Indication”域，其值賦予T3172，當手機收到Packet Access Reject消息后，啟動T3172，在T3172運行期間，網絡

7、不允許手機在同一小區(qū)內再次發(fā)起分組接入嘗試。該事件由無線資源緊張所致。 解決方案：擴充靜態(tài)PS信道。,專題PDP激活問題,PDP激活優(yōu)化方法 關閉SGSN鑒權 檢查核心網各網元處理能力（DNS解析APN錯誤或者過慢、GGSN關于APN的配置數據不完整、DHCP或RADIUS服務器故障、HLR和SGSN對通配符APN格式的兼容性問題、SGSN和GGSN的GTP信令的兼容性問題、SGSN構造APN的配置問題、GGSN處理過慢、DNS和GGSN的主備用狀態(tài) ） 防止頻繁的小區(qū)重選 排查干擾，提高C/I 檢查RACH或AGCH信道配置，提高接入和立即指配成功率 檢查靜態(tài)PS信道、動態(tài)PS信道配置 檢查

8、Gb links load，調整NSEI配置 檢查GPRS參數設置，合理設置DrxTimeMax、MFR、T3168,專題PDP激活問題,PDP故障案例一: PDP激活失敗,問題：在20022重選到20281后，由于20281AGCH緊張導致。 解決方案：控制20281覆蓋范圍，適當增加20281AGCH配置。,專題PDP激活問題,PDP故障案例二: PDP激活失敗,問題：由于連續(xù)發(fā)生兩次小區(qū)重選（CELLID: 10071 Channel:2CELLID: 111 Channel:90CELLID: 114 Channel:512）長時間無時隙分配引起PDP激活失敗。 解決方案：提高6002

9、1CRH由6dB到10dB。,專題PDP激活問題,PDP故障案例三: PDP激活失敗,問題：由于沒有申請到PS信道導致PDP激活失敗。 解決方案：增加8540站點的靜態(tài)PS信道，將MFR由5調整到2。,專題PDP激活問題,PDP故障案例四: PDP激活失敗,問題：在CQT測試時經常出現偶爾PDP激活時延過長的現象。 經過對10個點100次的PDP激活測試,發(fā)現7次時延異常的現象，具體掛表結果如下：,專題PDP激活問題,PDP故障案例四: PDP激活失敗,正常情況下幾個接口上的耗時情況如下：,專題PDP激活問題,PDP故障案例四: PDP激活失敗,從幾次異常測試結果可以看出，主要耗時是在Gb口以

10、下和Radius與WAP網關間，其中第六次GGSN與Radius間的耗時比較長，是因為GGSN第一次發(fā)送的Accounting request消息沒有被WAP網關接收到，也就是說，我們在WAP網關側沒有看到GGSN第一次發(fā)送的Accounting request消息，只看到了GGSN第二次重新發(fā)送的Accounting request消息，而且WAP網關收到后及時給予了響應。導致這種現象的原因可能是Accounting request消息在傳輸中丟失或者Radius的處理異常。 另外六次則是因為Gb口以下和Radius與WAP網關間的耗時過長。GGSN向Radius發(fā)送Accounting R

11、equest消息，等待Radius的響應，并啟動相應的等待定時器，在相應的WAP網關側，我們發(fā)現WAP網關在收到Accounting Request消息后沒有給予響應，由于GGSN沒有收到Accounting Request消息的響應消息，導致等待定時器超時，然后GGSN重新發(fā)送Accounting Request消息，在相應的WAP網關側，我們發(fā)現WAP網關此次給予了響應，GGSN收到Radius轉發(fā)的Accounting Response消息，這時GGSN才對手機的PDP激活請求進行響應。,專題PDP激活問題,PDP故障案例四: PDP激活失敗,正是由于Gi口的耗時過長，使得無線側的定時器

12、超時而釋放了TBF資源，所以手機在接收PDP激活接受消息時，重新進行了TBF的建立，這又進一步增加了在無線口上的延時。因此，WAP網關的響應過慢，是導致PDP激活時延過長根本原因。,專題PDP激活問題,PDP故障案例五: PDP激活失敗,在中國移動集團公司第三方測試的準備工作中，發(fā)現GPRS CQT的火車站測試點有PDP激活失敗的現象，并且多次測試問題始終存在。 從信令來看，當下行的立即指配信息里出現了右圖中ARFCN為809的時候，PDP激活會不成功。,專題PDP激活問題,PDP故障案例五: PDP激活失敗,809這個頻點是不正常的，但這是根據手機收到基站發(fā)出的層三消息解出來的。這個立即支配

13、消息是為了分配下行的TBF，也就是意味著網絡已收到PDP激活申請且給手機回復了PDP activate accept消息，但此消息未能通過空中接口。當時懷疑是否因測試軟件導致，詢問CDS軟件研發(fā)工程師，回復軟件應該沒有問題，也不像測試手機問題，所以網絡下發(fā)的消息編碼存在問題的可能性比較大。對同個BSC下的三晉國際飯店測試沒有發(fā)現同樣的問題。 調整頻點和無線參數等也沒有解決問題，于是懷疑是否為基站的問題。重啟基站，重做基站數據，仍然沒有效果。將天線直接接到BTS機柜上測試看是否是因為分布系統(tǒng)的問題，但在測試中還是存在PDP激活失敗，所以也排除分布系統(tǒng)的問題。對GB口進行掛表測試，出現三次PDP激

14、活失敗。這三次失敗在GB口信令中體現為：MS發(fā)給SGSN APCR,然后SGSN都立即回復一個APAC給MS。 但是在SGSN回復APAC給MS 7s8s后,在GB數據里發(fā)現了RSTA，在該信令中發(fā)現“Radio contact lost with MS”的信息，同時還有一個LLCD(=LLC-DISCARDED)的信令。見下圖：,專題PDP激活問題,PDP故障案例五: PDP激活失敗,專題PDP激活問題,PDP故障案例五: PDP激活失敗,總之, 雖然在CDS的LOG里存在PDP失敗,但是從GB數據里反應出的流程卻是完整的,而且SGSN都是在收到MS的APCR后就立即回復了APAC。因此分析

15、結果表明這幾次的PDP激活失敗并非由核心網引起，可能是由無線側導致了手機未能收到SGSN發(fā)的APAC而產生TIMEOUT。 由于無線質量、GPRS統(tǒng)計和參數、核心網、分布系統(tǒng)等都沒有問題，這時我們把重點放在基站硬件這一側。 因為8593也會出現閃斷，懷疑是否因傳輸誤碼率過高而導致，所以要求更換傳輸，換完傳輸后進行測試，還是沒有效果。 由于在8591測試時PDP激活成功率為100，把8591的BTS和8593的BTS進行調換再測試。在調換完后的200次PDP激活測試中，8593沒有出現一次失敗，而原來好的小區(qū)8591出現了5次PDP激活失敗。 最終更換了8593BTS，問題得到解決。,專題Pin

16、g問題,Ping優(yōu)化方法 優(yōu)化Ping Server,將Ping Server搬到FW內 檢查覆蓋 防止頻繁的小區(qū)重選 排查干擾，提高C/I 檢查靜態(tài)PS信道、動態(tài)PS信道配置 檢查Gb links load，調整NSEI配置 檢查GPRS參數設置，合理設置DrxTimeMax、MFR、T3168 優(yōu)化測試測試電腦，關閉所有系統(tǒng)軟件以及應用軟件的自動更新功能,專題Ping問題,Ping故障案例一: 不同時間間隔造成PING時延不同,問題：Ping測試中時間間隔設置為4s-12s測試結果有很大差別。經過核心網掛表測試發(fā)現Ping時延不穩(wěn)定是因為測試過程中出現其他一些數據包，這些垃圾數據包是由殺毒

17、軟件和一些應用軟件自動更新造成的。 解決方案：重新安裝操作系統(tǒng)，不能安裝與測試無關的軟件，將托盤中的任何與網絡通訊相關的程序關閉，關閉Windows的自動更新功能。,專題Ping問題,Ping故障案例二: Ping失敗,問題：PING失敗時誤碼率很高，查看網管指標發(fā)現此時干擾比較嚴重，但是其他時段幾乎沒有干擾，基本可以確定該干擾是外部干擾。 解決方案：查找外部干擾。,專題Ping問題,Ping故障案例三:Ping失敗,問題：由于小區(qū)的C/I低導致較高的BLER（小區(qū)BCCH CI5.9）。查看規(guī)劃數據，微蜂窩8800、7660、8750是同BCCH 。 解決方案：控制8800、7660、875

18、0覆蓋，調整8800、7660、8750頻點。,專題WAP問題,WAP優(yōu)化方法 優(yōu)化WAP網關、移動夢網服務器、Gi口 檢查覆蓋 防止頻繁的小區(qū)重選 排查干擾，提高C/I 檢查靜態(tài)PS信道、動態(tài)PS信道配置 檢查Gb links load，調整NSEI配置 檢查GPRS參數設置，合理設置DrxTimeMax、MFR、T3168 優(yōu)化測試測試電腦，關閉所有系統(tǒng)軟件以及應用軟件的自動更新功能,專題WAP問題,WAP故障案例一:WAP刷新失敗,問題：出現WAP reply失敗的時候GPRS的質量為6級，從服務小區(qū)和鄰區(qū)的測量來看，存在著鄰頻的干擾。 解決方案：更改頻點。,專題WAP問題,WAP故障案

19、例一:WAP圖鈴下載速率低,問題：通過分析看出RLC數據重傳率高，從OMC統(tǒng)計數據看Gb link的負荷在測試時段已高達64%，從而導致下載速率低。 解決方案：重新調整NSEI以減低Gb link load，從而提高GPRS CQT的下載速率。,專題WAP問題,WAP故障案例三:WAP登陸失敗,問題：在*賓館WAP登陸測試中，通過跟蹤Gb口發(fā)現，手機上行發(fā)送Get(URL=)，網絡側回復了一個PDU，具體內容為：Your request for a service could not be fulfilled,please try again or contact your operator

20、if the problem persists。這種現象是因為移動夢網服務器出現問題。 解決方案：與核心網工程師溝通解決。,專題WAP問題,WAP故障案例四:WAP登陸和刷新時延過長,GB口WAP測試流程,專題WAP問題,WAP故障案例四:WAP登陸和刷新時延過長,WAP測試信令流程,問題：信令分析發(fā)現，網關在CONNECT到CONNECT REPLY和GET到REPLY間存在響應時延長，需重復發(fā)送GET請求,甚至會出現沒有響應的情況，尤其是GET與REPLY間經常出現較大的信令時延，有的甚至達到幾十秒,對手機訪問WAP速度有較大影響。我們初步認為打開WAP網頁時超過20秒以上的大時延基本都是

21、由網關時延引起的。 解決方案：核心網工程師針對WAP網關進行優(yōu)化。,專題WAP問題,WAP錯誤代碼含義WTP層協(xié)議發(fā)生錯誤,專題WAP問題,WAP錯誤代碼含義WSP層協(xié)議發(fā)生錯誤,專題WAP問題,WAP錯誤代碼含義HTTP協(xié)議發(fā)生錯誤,專題WAP問題,WAP錯誤代碼含義HTTP協(xié)議發(fā)生錯誤,專題MMS問題,MMS優(yōu)化方法 優(yōu)化相關核心網網關及接口、移動Radius到省內 檢查覆蓋 防止頻繁的小區(qū)重選 排查干擾，提高C/I 檢查靜態(tài)PS信道、動態(tài)PS信道配置 檢查Gb links load，調整NSEI配置 檢查GPRS參數設置，合理設置DrxTimeMax、MFR、T3168,專題MMS問題,

22、MMS故障案例一:MMS發(fā)送失敗,問題：通過掛表發(fā)現手機首先PDP激活，APN為CMWAP，但是手機隨后沒有任何發(fā)起任何信令。這種情況是由于手機軟件進程吊死所致。 解決方案：重裝手機操作系統(tǒng)。,專題MMS問題,MMS故障案例二:MMS接收失敗,問題：通過掛表發(fā)現手機首先建立了WSP層的連接，然后發(fā)起GET請求接收彩信，隨后WAP網關將彩信在WTP分割后，向手機發(fā)送WTP層的分段，當傳送到第六個分段后該消息中的GTR和TTR都為0，說明該分段既不是整個消息中某組的最后一塊，也不是整個消息的最后一塊，但是手機卻回應了ACK，緊接著又發(fā)起一個Transaction(Invoke)。這種情況是由于手機

23、軟件故障所致。 解決方案：重裝手機操作系統(tǒng)。,專題MMS問題,MMS故障案例三:MMS接收失敗,問題：通過Gi口掛表發(fā)現手機在發(fā)起Get請求后，在10ms左右的時間連續(xù)多次重發(fā)Get請求（Get請求重發(fā)定時器為10s），導致WAP網關來不得處理手機的Session，從重發(fā)時間間隔來看，不可能是手機連續(xù)接收彩信。這種情況是由于手機軟件故障所致。 解決方案：重裝手機操作系統(tǒng)。,專題MMS問題,MMS故障案例四:MMS發(fā)送失敗,問題：通過掛表我們發(fā)現手機首先上行發(fā)送WSP 層的Connect 信令，建WSP 層的連接，但是WAP 網關沒有回應Connect Reply，手機等待5 秒后重Connec

24、t，但是始終沒有回應Connect Reply，達到最大重發(fā)次數5 次后，WSP 層的建鏈失敗，最終導致彩信發(fā)送失敗。導致此次MMS發(fā)送失敗的原因為WAP網關過于繁忙沒有回應Connect Reply。 解決方案：請核心網工程師配合解決。,FTP優(yōu)化方法 優(yōu)化FTP Server，將FTP Server搬到FW內 檢查覆蓋 防止頻繁的小區(qū)重選 排查干擾，提高C/I 檢查靜態(tài)PS信道、動態(tài)PS信道配置 檢查Gb links load，調整NSEI配置 調整DLB、ULB、DLBH、ULBH參數，動態(tài)調整CS的比例 檢查GPRS參數設置，合理設置DrxTimeMax、MFR、T3168、T3192

25、 打開CS3、CS4,專題FTP問題,專題FTP問題,FTP故障案例一:FTP下載失敗,問題：MS 重選到小區(qū)41921后，DL TBF一直沒被建立導致長時間下行無數據傳輸，最終導致了PDP掉線. 經檢查該小區(qū)在測試時間段內的GPRS KPI：下行時隙分配擁塞率比較高，這是為什么沒能建立DL TBF的主要原因所在。 解決方案：增加該小區(qū)靜態(tài)PS信道。,專題FTP問題,FTP故障案例二:FTP下載速率過低,問題：第一次cell reselection（9052）使數據傳輸恢復時間變長而導致長時間TBF掛起。之后重建時由于小區(qū)30553數據業(yè)務繁忙只申請到一條PS信道，在數據下傳過程中又發(fā)生了第二

26、次cell reselection（5280），然后因為數據傳輸恢復時間變長而導致長時間TBF掛起。在重建時小區(qū)30152數據業(yè)務繁忙導致一直申請不到下行的PS信道導致三次PING失敗，最終申請到了4條PS信道，下載成功。導致平均下載速率只有8.11kbit/s。 解決方案：擴充30553、30152靜態(tài)PS信道；調整30553RXLEVACCESSMIN由10到12。,專題FTP問題,FTP故障案例三:FTP下載失敗,問題：MS從43372重選到42093后，又從42093重選到1531后又頻繁重選回1531后，電平降到-94dBm，拖了一段時間后PDP掉線。 解決方案：控制42093、15

27、31覆蓋。,專題FTP問題,FTP故障案例四:FTP下載失敗,問題：MS跨LAC從83重選到1483后，就頻繁的小區(qū)重選148318621741，導致長時間的TBF掛起，最終PDP掉線。從地形看，該處是一座立交橋，橋下無主控區(qū)。 解決方案：調整1483 CRH由6到10，確定該地點的主控小區(qū)。,專題FTP問題,FTP故障案例五:FTP下載速率低,問題：MS拿到的PDCH不穩(wěn)定，跳變頻繁，PS爭搶頻繁，導致了DL FTP速率低。 解決方案：增加CI2631的靜態(tài)PS信道。,專題FTP問題,FTP故障案例六:FTP下載速率低,案例說明： 在*路和*橋路附近，手機從宏站小區(qū)重選至室外微蜂窩52484

28、（八萬人體育館），BCCH109。由于室外微蜂窩主要是針對某個熱點地區(qū)，或者覆蓋比較差的區(qū)域采用的覆蓋方式。我們在GPRS測試時，車經過室外微蜂窩的時間比較短，盡量不要讓手機重選至這樣的小區(qū)，這樣會增加小區(qū)重選的次數和減少吞吐量。在這個案例中，我們發(fā)現這個小區(qū)主要是覆蓋八萬人體育場的外場，所以我們鼓勵慢速移動的手機占用此小區(qū)，快速移動的手機不要重選進這樣的小區(qū)。 52484參數設置為：PET=20s，TEO=0。為了保證手機在一段時間內不重選進此小區(qū)，設置PET20s，TEO30db，即在52484的信號出現在MS的鄰區(qū)20s內給C2一個人為的衰減值30db，使其他小區(qū)的C1，C2大過本小區(qū)5

29、s，這樣手機即不會選進室外微蜂窩。,專題FTP問題,FTP故障案例六:FTP下載速率低,專題FTP問題,FTP故障案例六:FTP下載速率低,問題：在復測時我們發(fā)現，在同一個地點，此時52484的C1=25，C221，從15:40:33.764至15:53:586持續(xù)20s后，C2值升至53。由于復測時，車行駛的地方為一個交通燈口，車流量大、擁堵。我們原先設置的PET20s遠遠小于堵車的時間。 解決方案：將這個小區(qū)的PET設置為200s，這樣小區(qū)重選發(fā)生的可能性就大大降低了。,專題高BLER,BLER概述,BLER反應信道受干擾的情況，但在小數據傳輸中可以看到下行BLER總是比較高，重傳的BLO

30、CK中很大的一部分是由于PCU的無線傳輸特性決定的，PCU在下行傳輸時，判斷數據是否快要發(fā)送完了，在數據快要結束前N個BLOCK(N由PCU參數決定)的時候確定TBF快要結束，在下行TBF的結尾處最后的一個BLOCK發(fā)送之后而在對它的確認包回來之前，PCU重復發(fā)送這些未確認的BLOCK直到收到確認包。此時如果發(fā)生該BLOCK的接收錯誤，手機可以馬上從后面的BLOCK中獲得而不必要求重傳，手機在計算BLER的時候把這部分BLOCK也計算在內，從而導致 BLER的計算值比較高，因此小數據傳輸下行BLER并不代表系統(tǒng)真正的無線 性能，在大數據量傳輸時的BLER可以真實的反映出系統(tǒng)的無線性能。測試中同

31、時觀察C/I、質量、手機發(fā)射功率、重傳率以及信道的RLC層速率，這些都是反應信道質量的重要指標。,專題高BLER,BLER案例1內部干擾問題,問題：是該站點覆蓋小區(qū)，但是高BLER。 解決方案：更改GTRX或者更換頻點。,專題高BLER,BLER案例2小區(qū)重選問題,問題：已經越過了該小區(qū)的主控范圍，但是不向鄰小區(qū)重選。 解決方案：調高該鄰小區(qū)的CRH。,專題小區(qū)重選問題,小區(qū)重選的時候手機會暫時中斷數據傳輸，在這里數據中斷的時長主要包括：重 選后數據暫停的時間、TCP Slow Start啟動的時間，這一過程大約需要410秒，直至TCP正常傳輸。路測過程中，要特別注意觀察，是否有頻繁小區(qū)重選或

32、乒乓小區(qū)重選發(fā)生，小區(qū)信號覆蓋過小或不穩(wěn)定都會導致頻繁、乒乓小區(qū)重選，同時還要注意觀察，是否由于小區(qū)重選參數設置不合理導致過覆蓋，這里注意對CRO、CRH等相關參數的調整。TCP Slow Start過程，在小區(qū)重選后數據暫停的時長約410秒，手機在新小區(qū)駐留后需要0.55秒的時間獲得資源分配，如果有資源可以分配的話，此時手機已經有少量數據的發(fā)送和接收（通過IP分析軟件觀察），此時使用PING來檢驗就可以看到GPRS連接已經恢復。在TCP的數據連接恢復過程中再次發(fā)生的小區(qū)重選會嚴重影響給TCP的數據連接恢復。,小區(qū)重選與路由更新概述,專題小區(qū)重選與路由更新問題,DT測試中會發(fā)生小區(qū)重選，在重選

33、后的數據中斷和恢復期間數據量非常小，TCP慢啟動之后，數據傳輸恢復。恢復時間長度不一，這和重選時TCP數據傳輸當時的具體情況有關，一般410秒，極端惡劣情況下達12分鐘，但此時如果停止行駛，數據傳輸會在短時間內恢復。 FTP的數據傳輸在經歷RAU的時候同時也進行了小區(qū)重選，此時的數據中斷情況 同小區(qū)重選一樣，在RAU之后繼續(xù)的小區(qū)重選也會給TCP的數據連接恢復帶來負作用，路測過程中應觀察重要路段或重要場所是否有不合理的RAU事件發(fā)生。在RAU之后可以使用PING來驗證GPRS承載已經恢復 。,小區(qū)重選與路由更新概述,專題小區(qū)重選與路由更新問題,小區(qū)重選案例1C2參數設置不合理問題,問題：車輛沿

34、機場高速從北向南行駛，紅圈處占用小區(qū)高教科研4（BCCH：560）。繼續(xù)南行，高教科研4的電平逐漸降低，低至94dBm以下時，仍不發(fā)生小區(qū)重選。長時間電平小于94dBm，造成無覆蓋。經檢查發(fā)現此時該小區(qū)與相鄰小區(qū)的小區(qū)重選參數設置情況如下：,專題小區(qū)重選與路由更新問題,小區(qū)重選案例1C2參數設置不合理問題,解決方案：控制小區(qū)高教科研4（BCCH：560）的覆蓋，修改高教科研4小區(qū)CRO由26到20。,專題小區(qū)重選與路由更新問題,路由更新案例1跨越SGSN路由區(qū)更新故障,每次穿越RAC區(qū)時，都發(fā)生掉線，且都伴隨著RAU Failure。通過仔細分析， SGSN內的數據錯誤是導致這種路由更新失敗的

35、原因。 關系GPRS路由更新的參數主要有3部分，即： (1) 每個MSC到SGSN的歸屬位置 (2) 每個BSC到MSC的歸屬位置 (3) 每個小區(qū)的歸屬的RAC區(qū) 以上3個參數必須與現行網絡中硬件設備的連接一致才能保證GPRS手機路由更新的正常進行 。,專題NSEI規(guī)劃,NSEI規(guī)劃概述,GPRS協(xié)議棧BSSGP層中，為了便于管理，每個GPRS小區(qū)被賦予了一個BSSGP虛連接BVC（NSEIBVCI），一個BVC必須隸屬于一個NSE。其中NSE為網絡服務設備實體，是全網統(tǒng)一編碼的，以NSEI來標識。一般來說一個BSC被劃分為一個服務實體，為了可擴展性，ZXG10系統(tǒng)中也允許BSC下掛若干個N

36、SE。 BSSGP虛連接（BVC）為不同的BSSGP實體間通訊提供了一種途徑。對等的PTP（點對點）、PTM（點對多）和信令實體間傳送BSSGP PDU時是以BVC為基礎的。每條虛連接都有一個標識，為BVCI，它能使底層網絡服務層將BSSGP PDU高效地路由到對等實體上。在一個網絡服務實體（NSE）下，每個GPRS小區(qū)可由BVCI唯一標識，一個網絡服務實體有且僅有一條信令BVC（BVCI=0）。,專題NSEI規(guī)劃,NSEI規(guī)劃前,在網絡優(yōu)化之前沒有優(yōu)化過NSEI，PCU的分配很是隨便，甚至一個站上的兩個小區(qū)都不在一個PCU下，這對GPRS performance有很大影響。因此,我們需要重新

37、分配NSEI。比如下圖就是沒有經過合理配置的NSEI：,專題NSEI規(guī)劃,NSEI規(guī)劃后,在優(yōu)化期間，PCU需要定期重新規(guī)劃，也即重新分配小區(qū)的NSEI，在物理位置上盡量靠近，這樣做的目的是為了在GPRS DT的過程中避免頻繁的RAU，從而提高GPRS DT的Performance。下圖就是經過優(yōu)化過的NSEI分配：,專題NSEI規(guī)劃,專題NSEI規(guī)劃,NSEI規(guī)劃案例2FTP下載失敗,問題：MS從CI1892重選到CI到481的同時跨了PCU，屬于Inter-PCU的Cell Reselection,導致了數據傳輸長時間的停頓，最終發(fā)生了PDP掉線。經檢查發(fā)現CI1892的NSEI值與周圍站

38、點不統(tǒng)一。 解決方案：調整CI1892的NSEI值。,專題PANDEC、PANINC參數實驗,PANDEC、PANINC概述,在無線鏈路失敗控制中，PAN參數將與MS側的定時器N3102一起使用。當移動臺檢測到發(fā)送窗口停止轉動時（V(S) = V(A) + WS），移動臺應啟動定時器T3182；在收到PACKET UPLINK ACK/NACK導致V(S) V(A) + WS時，則停止T3182；當T3182超時后，移動臺將把計數器N3102減去PANDEC，并執(zhí)行該TBF的異常釋放并接入重試；當移動臺收到網絡發(fā)送的“分組上行證實/未證實”消息允許V(S)或V(A)增加時，移動臺將把計數器N3

39、102增加PANINC，但是N3102值不能超過PANMAX所定義的值；當N31020時，MS將執(zhí)行該TBF的異常釋放，并將觸發(fā)小區(qū)重選。如果PANDEC，PANINC和PANMAX置為0值時，計數器N3102就無效。 增加PANMAX和PANINC，減小PANDEC，可以減少MS在收不到Packet Uplink Ack時TBF異常釋放并進行小區(qū)重選的可能，但也使MS在發(fā)送窗口停止，不能發(fā)送數據的情況下，較長時間占據無線資源，資源利用率不高。而減小PANMAX和PANINC，增加PANDEC，則容易使手機發(fā)生TBF異常釋放并進行小區(qū)重選，降低小區(qū)TBF正常釋放比例，影響數據傳輸速率。,專題P

40、ANDEC、PANINC參數實驗,PANDEC、PANINC參數調整實驗,試驗結果： 總體而言，對公里無覆蓋比等GPRS DT測試指標有明顯改善。,專題PANDEC、PANINC參數實驗,PANDEC、PANINC參數調整實驗前后相關區(qū)域電平分布圖,專題MFR、DRX參數實驗,MFR、DRX概述,MFR（BS_PA_MFRMS） 在每個小區(qū)中每個尋呼組都對應于一個尋呼子信道，移動臺根據自身的IMSI計算出它所屬的尋呼組，進而計算出屬于該尋呼組的尋呼子信道位置，在實際網絡中，移動臺只“收聽”它所屬的尋呼子信道而忽略其它尋呼子信道的內容，甚至在其它尋呼子信道期間關閉移動臺中某些硬件設備的電源以節(jié)約

41、移動臺的功率開銷（即DRX的來源）。尋呼信道復幀數（MFR）是指以多少復幀數作為尋呼子信道的一個循環(huán)。,專題MFR、DRX參數實驗,MFR、DRX概述,DRX（DRX_TIMER_MAX） 在DRX模式中，MS僅收聽歸屬尋呼組的尋呼塊，而在非DRX模式下，MS將收聽所有的CCCH塊。非DRX模式持續(xù)的時間由兩個參數共同決定：NON_DRX_TIMER和DRX_TIMER_MAX，等于兩者的最小值。DRX_TIMER_MAX設定MS在從分組傳輸模式進入分組空閑模式時，執(zhí)行NON-DRX模式時長的最大值。 NON_DRX_TIMER由MS在GPRS附著的過程中和SGSN協(xié)商。 NON_DRX_TI

42、MER的大小可以在ATTACH REQUEST中看到；DRX_TIMER_MAX的數值可從System Information Type 13中看到。 DRX_TIMER_MAX的取值范圍為07，表達的取值遵循公式：2k-1（其中k=0時，表示參數值為0），即參數取值為：0，1s、2s、4s64s。,專題MFR、DRX參數實驗,DRX模式與非DRX模式概述,當移動臺處在DRX模式的時候，移動臺只會監(jiān)聽和它尋呼組相關的尋呼子信道。若PCU判斷該MS正處于DRX模式時，它將計算MS屬于哪個尋呼組，并向BTS發(fā)出資源分配消息，當BTS收到該消息后將在MS所偵聽的CCCH信道上發(fā)出立即指配消息。BS_

43、PA_MFRMS定義了尋呼信道的復幀數，目前現網的默認設置是5，也就是說MS在收聽了自己尋呼組所對應的CCCH塊后，將等待4個51復幀，繼續(xù)收聽的將是第6個51復幀的同樣位置的CCCH塊。MS如果錯過了自己所偵聽的尋呼子信道，它將不得不再等待，直到下一個尋呼子信道到來。 如果MFR=5，那么在最壞的情況下，MS要收到立即指配的消息，就必須等待：5235ms=1175ms。 如果立即指配消息隨機出現，MFR=5，MS要等待的平均時間就是： 235ms（5+4+3+2+1）/5=705ms 如果立即指配消息隨機出現，MFR=2，等待的平均時間就減少為： 235ms（2+1）/2=352.5ms 節(jié)

44、約的時間為352.5ms！,專題MFR、DRX參數實驗,DRX模式與非DRX模式概述,當MS由分組傳輸模式返回分組空閑模式時（比如TBF釋放），在DRX_TIMER_MAX與NON_DRX_TIMER的共同作用下，如果MS進入非DRX傳輸的狀態(tài)，將如下圖所示：,在非DRX模式期間內，MS將收聽所有的CCCH塊，同時PCU保留MS相關的上下文。此時下行TBF建立的立即指配消息不需要再計算尋呼組，可以直接在AGCH上發(fā)送。所以設置了非DRX模式后會大大縮短下行TBF的建立時間，缺點是會加快手機電池的消耗。,專題MFR、DRX參數實驗,MFR、DRX參數實驗結果,專題T3192參數實驗,T3192概

45、述,當MS向網絡發(fā)送“最后證實標志”（FAI）等于“1”的“分組下行證實/未證實”(PACKETDOWNLINKACK/NACK)消息時啟動定時器T3192，或者在以非確認模式發(fā)送“分組控制證實”（PACKET CONTROL ACK）作為最后一個數據塊的響應時，MS啟動定時器T3192。在T3192期間，滿足啟動條件時，將重新啟動T3192。當移動臺收到PCU發(fā)送的“分組下行指配”（PACKETDOWNLINK ASSIGNMENT）消息或“分組時隙重新配置”（PACKET TIMESLOT RECONFIGURE）時，停止定時器T3192。如果T3192超時，MS將釋放TBF相關資源并開始

46、監(jiān)聽尋呼信道。 此參數以500ms為單位進行配置。在TBF釋放階段，如果MS處于半雙工狀態(tài)并且收到上行指配，MS將立即響應該命令；如果在TBF釋放階段沒有收到上行指配，MS將進入分組空閑模式，在雙傳輸模式時將進入專用模式。在進入空閑模式或專用模式時，根據協(xié)議，仍舊需要執(zhí)行一段非DRX時間。,專題T3192參數實驗,T3192概述,該參數的設置越大，TBF相關資源保留（包括TFI和時隙）的時間就越長，相同TBF傳送占用的時間就越長，容易導致擁塞。 而該參數設置越小，因為MS將很快將TBF資源釋放掉，若網絡有新的下行數據到來，網絡必須發(fā)起尋呼或立即指配流程（若MS處于就緒狀態(tài)），所以下行TBF建立

47、的時間就越長。而如果網絡側新的下行數據到來時，T3192還未超時，則網絡可以直接發(fā)送“分組下行指配”消息，來建立一個新的下行TBF，縮短TBF的建立時間。 該參數的設置，應充分考慮該小區(qū)的業(yè)務負荷、小區(qū)的業(yè)務模型，網絡資源較充足的情況下，應盡量設置T3192較大，減少新TBF建立時間，提高數據傳輸速率。 網絡側有相對應的計數器T3193，要求T3193必須大于T3192。,專題T3192參數實驗,T3192參數實驗結果,T3192設置為0.5 秒，T3192會影響TBF 建立時間的長短，常規(guī)情況下，當一組數據RLC 傳完之后，手機會啟動T3192，等待0.5 秒(注意剛才在使用PDCH 時隙)

48、，如果沒有續(xù)傳的指令，T3192 超時，釋放下行TBF 而且開始監(jiān)視Paging 信道。當再次有數據傳時，需要重新立即指配。這無形中延長了TBF 建立時間。 T3192 設置為1.5 秒，容易導致GPRS territory ugrade reject (%) ，而且增加了PDP 激活時間，降低了PDP激活成功率。 T3192 設置為1 秒，對小數據交互多的GPRS 業(yè)務或小區(qū)重選等TBF 變更頻繁的地方的數據傳輸速度上有改善,而對于定點的穩(wěn)定大數據量的FTP 下載沒有正面或負面影響。,專題BCCH TRX、TCH TRX（HF/NHF）下GPRS性能比較,BCCH TRX、TCH TRX（H

49、F/NHF）下GPRS性能比較,為明確了解BCCH載頻、TCH載頻在跳頻、非跳頻及不同編碼方式下FTP下載速率的變化情況，尋找特定小區(qū)進行了詳盡的測試 ，具體情況如下：,無線環(huán)境好、接收電平強 測試地點設在一寫字樓內，由于樓內主要由微蜂窩覆蓋，周邊的無線環(huán)境較好，主控小區(qū)的電平遠遠高于相鄰小區(qū)，接收電平在55dBm左右，在這種情況下通過測試發(fā)現，占用BCCH或TCH、跳頻或非跳頻之間的下載速率差異值不是很大。,專題BCCH TRX、TCH TRX（HF/NHF）下GPRS性能比較,無線環(huán)境好、接收電平低 測試地點為一寫字樓內，用手機鎖頻到室外大站，接收電平在-85dBm左右，由于樓體的屏蔽雖然使服務小區(qū)電平很低，但周圍的干擾電平也很低無線環(huán)境較干凈。在這種情況下通過測試發(fā)現，占用BCCH或TCH、跳頻或非跳頻之間的下載速率差異值不是很大。,BCCH TRX、TCH TRX（HF/NHF）下GPRS性能比較,專題BCCH TRX、TCH TRX（HF/NHF）下GPRS性能比較,無線環(huán)境差、接收電平低 測試地點為一16層建筑物頂層，用手機鎖頻的室外大站接收電平為80dBm左右，由于樓頂的無線環(huán)境較差，周圍較多大站飄來的信號對當前小區(qū)帶來干擾。在這種