湖南長沙移動手機報數(shù)據(jù)業(yè)務組階段報告

1、長沙移動手機報優(yōu)化項目數(shù)據(jù)業(yè)務組階段報告目 錄1概 述42.GB口業(yè)務性能統(tǒng)計：63.GB口業(yè)務性能分析：103.1失敗原因分析103.1.1用戶側發(fā)起PDP去激活分析：123.1.2小區(qū)更新過程分析：183.1.3FLUSH分析：193.1.4 Response非成功狀態(tài)碼整體統(tǒng)計：263.1.5 Response 非成功狀態(tài)碼失敗原因分析：283.1.6 Radio_cause分析353.1.7 Suspend過程中伴隨LLC_discarded的超時失?。?73.1.8“SUSPEND”與“RESUME” 的失敗原因分析：383.2 SP站點排名：453.3手機報內容大小分析：473.4

2、終端端口設置及操作流程484.GB口下載速率分析：504.1各小區(qū)手機報下載速率統(tǒng)計：504.2手機報下載速率整體分析：526.GB口介入性時延分析：566.1 Attach時延分布統(tǒng)計：566.2 PDP激活時延分析：576.3 TCP連接時延分析：587 MMS測試分析：618EGPRS分析：689GN口統(tǒng)計分析709.1 GN口業(yè)務性能評估：709.2GN與GB關聯(lián)分析729.3小結：7610.1 MM1接口TCP連接分析7710.1.1 TCP連接建立過程描述7710.1.2 TCP連接建立時延分析7810.1.3 syn至ack消息時延分析：7910.1.4 TCP連接建立成功率統(tǒng)計

3、7910.1.5異常的TCP連接統(tǒng)計:8010.2 MM1口手機報接收分析8110.2.1 MM1口手機報接收過程描述8110.2.2 Get至M-retrieve.conf時延和成功率8511PUSH接口信令分析8911.1 PUSH口統(tǒng)計分析8911.2 PUSH口與MM1口關聯(lián)分析9012總 結：93引言：項目管理區(qū)域范圍： 本次長沙移動GPRS手機報端到端性能優(yōu)化服務涉及長沙市區(qū)的4個BSC和3個CQT點以及相關的SGSN，GGSN, 1個和1套MMSC服務器。4個BSC如下：BSC404: BSC719: BSC728: BSC785: 1概 述湖南長沙移動手機報數(shù)據(jù)采集結構示意圖如

4、下所示：本次手機報業(yè)務數(shù)據(jù)采集主要包括4個采集點，數(shù)據(jù)業(yè)務小組分別采集長沙移動現(xiàn)網(wǎng)的GB、Gn、MM1及PUSH等接口的數(shù)據(jù)用以專題分析。2.成果綜述本次項目通過GB,GN,MM1,PUSH多接口關聯(lián)分析發(fā)現(xiàn)的主要問題有如下4類：1） 用戶自身問題：比如彩信中心地址設置錯誤，以及流程沒有結束用戶主動釋放等?？梢愿嬷脩粽_設置來解決。2） 終端問題：終端協(xié)議有問題，多為山寨機。建議廠家修補bug。3） 無線環(huán)境問題：小區(qū)無線環(huán)境差。對小區(qū)進行無線環(huán)境優(yōu)化。4） 網(wǎng)絡問題：超時、網(wǎng)絡無響應。由于GGSN/SGSN忙時丟棄掉的消息。長沙移動手機報優(yōu)化成果如下：u GB口分析主要結果與發(fā)現(xiàn)：1) 網(wǎng)

5、絡側超時無響應，主要是用戶頻繁小區(qū)更新過程中網(wǎng)絡超時無響 應。2) 用戶行為：用戶主動去激活以及彩信中心地址錯誤。3) 位置更新或者語音業(yè)務搶占數(shù)據(jù)業(yè)務過程中超時無響應。4) 終端原因：終端協(xié)議問題，上報不符合規(guī)范的消息參數(shù)5) 網(wǎng)絡連接中斷6) Flush成功率過低。7) 小區(qū)更新(FLUSH)過程以及位置更新（SUSPEND）過程嚴重影響手機報下載速率。8) 部分小區(qū)重傳率過高。9) 手機滲透率相對較高u 手機報集中下發(fā)高峰期的下載速率明顯低于其他時段的手機報下載 速率，網(wǎng)絡的負荷過重時，對手機報的下載速率有著較大影響。u GN口手機報成功率以及下載速率過低，GGSN繁忙無響應超時造成的手

6、機報下載失敗占比較高。u Push口消息到GET消息之間平均時延為23.817S對手機報下過程中時間損耗貢獻較大。u SGSN響應BSC發(fā)送的GET請求時間損耗較長為5S左右。u 通過無線配合測試發(fā)現(xiàn)，定點測試過程（非移動狀態(tài)）中手機報下載成功率較高，并且下載速率比較穩(wěn)定。u 彩信中心多次給部分手機下發(fā)PUSH消息用戶沒有手機報提取行為發(fā)生。u 主要性能指標：接口成功率下載速率 GB 89.81%17.35(kps)GN 80.16%11.58(kbps)MM1 99.81%5394(kbps)PUSH 97.56%17.32(kbps) 備注： 其中GB,GN接口下載速率為get reque

7、st 到response消息時間差作為下載速率時間計算值。MM1接口下載速率為get request到m-retrieve-conf消息之間時間差作為下載速率時間計算值。push接口下載速率以push消息下發(fā)到MM1口收到get request消息過程時間作為計算下載速率時間差。 手機報大小均以各接口統(tǒng)計手機報總大小比總次數(shù)得到平均值計算得到。 接口TCP連接平均時延(MS) GB810GN998MM18接口PDP激活時延(MS) GB 174GN145由上表可以看出GN口TCP連接時間損耗最長是998ms，其次是GB口TCP連接時間損耗為810MS。MM1口TCP連接時間損耗為8ms對整個手

8、機報下載過程來說可以忽略不計。Gb口與GN口PDP激活時延相差不大。u 基于上述分析結果建議如下：· 針對用戶以及終端建議如下：針對用戶彩信中心地址設置錯誤，建議客服聯(lián)系不同廠家總結彩信中心地址設置匯總，對客戶進行正確的彩信中心地址設置指導。· 針對無線建議如下：1. 針對語音搶占數(shù)據(jù)業(yè)務導致超時無響應，建議修改無線參數(shù)降低小區(qū)CS/PS業(yè)務量。2. 針對網(wǎng)絡斷連的小區(qū)建議檢查這些小區(qū)無線環(huán)境。3. 對網(wǎng)絡負荷過重建議擴容。4 對數(shù)據(jù)流量大且移動性能不太好的小區(qū)，即導致TBF中斷的小區(qū)重選 間隔較短的小區(qū)，通過調整一些空閑模式參數(shù)，盡量減少小區(qū)重選，以提高其移動性能。5 針

9、對重傳率較高的小區(qū)LA參數(shù)調整建議：建議LA設置為ON，在C/I 好的情況下盡可能使用高編碼方式，在C/I低的情況下使用低編碼方式，降低重傳。6 PILTIMER調整建議：Packet Idle List Timer，當一個On-Demand PDCH處于空閑狀態(tài)（Idle）時，將被系統(tǒng)放置在PS域的空閑列表，同時PILTIMER啟動，當PILTIMER超時，On-demand PDCH將返回CS域。建議設置5秒，可提早釋放GSL設備，降低GSL負荷。GSL是PCU與BSS之間的信令鏈路，所采用的協(xié)議為LAPD協(xié)議，故GSL鏈路又叫GDS LAPD。在BSC側GSL定義于GPROC下，每個PC

10、U可支持6個主用的GSL 64kbps時隙和6個冗余備份時隙，每個64kbps時隙是一個LAPD信道，兩條GSL工作于負荷分擔模式。網(wǎng)絡運行維護過程中定期分析現(xiàn)網(wǎng)GSL負荷，對負荷已經達到預警門限的GSL及時采取容量調整措施可有效保障GSL始終工作于最佳狀態(tài)。7 建議EGPRS網(wǎng)絡開通網(wǎng)絡輔助小區(qū)重選和GB over IP從而減少小區(qū) 重選對手機報下載速率的影響以及幀中繼模式下Gb帶寬不足問題。 8 SUSPEND、RESUME失敗主要是在跨LAC，RAC，SGSN發(fā)生重選時造成 的。想要解決這一問題需要添加Gs接口。· 針對核心網(wǎng)建議如下：1 建議修改GGSN qos_policy

11、map 里的參數(shù)Traffic Handling Priority可以大大提高PS業(yè)務的速率。2 建議調整SGSN尋呼響應計時器T3313值的設置，以減少尋呼響應時 間。 3 建議調整SM等待GGSN響應定時器的設置，以減少等待GGSN響應create PDP context response時間。4 建議SGSN開啟對GGSN進行負荷分擔功能，減少GGSN繁忙時負荷過重現(xiàn)象。 5 為了防止個別用戶激活PDP上下文后，長時間不適用PS業(yè)務而占用系統(tǒng)資源，GGSN應當配置最大空閑時間，在這個時間內如果用戶沒有流量，則可以主動去激活此PDP上下文。建議設置為15分鐘。同時設置PDP上下文最大存活時

12、間為15分鐘。6 建議調整GGSN未收到SGSN響應報文時的重發(fā)時間間隔值，從而減少重傳率。7 建議PUSH消息按時間分散下發(fā)，避免下發(fā)集中度過高。 8 由于晚忙時下載速率以及接入性各項指標均比早忙時要差，建議手機 報 晚忙時播報時間提前一個小時播報，同時用戶避開晚忙時下班路途中下載手機報，從而減少多次進行小區(qū)重選對手機報下載速率的影響。· 針對無線建議的提出，通過無線優(yōu)化人員配合無線參數(shù)調整優(yōu)化前后指標對比：優(yōu)化前優(yōu)化后日期長沙手機報下載速率日期長沙手機報下載速率指標同比提升6月7日11.84 7月7日12.283.73%6月8日10.28 7月8日12.1518.19%6月9日1

13、1.13 7月9日12.3310.76%6月10日11.14 7月10日12.169.20%6月11日11.04 7月11日12.2711.23%由上表可以看出優(yōu)化后手機報下載速率得到明顯提高。3. GB口業(yè)務性能分析：數(shù)據(jù)采集時間點：6月25日從17：00至下午20：00和6月26日從7:30到9:30。依據(jù)上述時間段內GB接口數(shù)據(jù)針對現(xiàn)網(wǎng)手機報業(yè)務的提取性能進行分析晚忙時25日（17:00-19:00）4個BSC總體手機報業(yè)務性能統(tǒng)計概況：晚忙時手機報接收概況類別次數(shù)比例手機報提取總次數(shù)6450100.00%提取成功次數(shù)579389.81%deactivate_pdp2043.16%flu

14、sh_timeout1842.85%timeout841.30%Response非2xx761.18%Radio_cause(radio contact lost with MS)340.53%suspend_timeout330.51%Reset90.14%llc_discarded_timeout330.51%從統(tǒng)計結果可以看出長沙移動現(xiàn)網(wǎng)中4個BSC晚忙時手機報下發(fā)總次數(shù)為6450次，成功提取次數(shù)為5793次，成功率為89.81%，主要的失敗原因是timeout（超時無響應），其次是deactivate_pdp(用戶去激活)以及response返回的非成功狀態(tài)碼，最后是radio_cau

15、se（無線原因）引起的失敗。另外值得關注的是timeout（超時無響應）失敗中伴隨flush（小區(qū)更新）的有184次占總提取次數(shù)的2.85%，伴隨有suspend（語音業(yè)務搶占數(shù)據(jù)業(yè)務）的次數(shù)為33次占總提取次數(shù)的0.51%，是否由于小區(qū)更新過程中以及suspend過程中出現(xiàn)異常導致手機報的提取超時失敗下面將進行深入分析。除此之外還有33次超時無響應是伴隨有LLC-DISCARDED，雖然這種消息不一定造成手機報提取失敗，但是這種消息的發(fā)生一般是因為小區(qū)無線環(huán)境差造成的。早忙時（7:30-9:30） 4個BSC總體手機報業(yè)務性能統(tǒng)計概況：早忙時手機報接收概況類別次數(shù)比例手機報提取總次數(shù)4739

16、100.00%提取成功次數(shù)439292.68%deactivate_pdp1042.19%flush_timeout831.75%timeout591.24%Response非2xx450.95%Radio_cause(radio contact lost with MS)150.32%suspend_timeout170.36%Reset60.13%llc_discarded_timeout180.38%比較早忙與晚忙統(tǒng)計概況，發(fā)現(xiàn)早忙的成功率92.68%要高于晚忙成功率89.81%。各種失敗原因的所占比例排名相同，依然都是用戶主動去激活以及小區(qū)更新過程中的網(wǎng)絡超時無響應。4個BSC晚忙時（

17、17:00-19:00）手機報提取成功率統(tǒng)計如下：BSC總提取次數(shù)提取成功次數(shù)成功率BSC4041639149991.46%BSC7191251108586.73%BSC7282061186390.39%BSC7851617145690.04%總體6568590389.88% 由上表可以看出BSC404手機報提取成功率最高2個小時內下發(fā)1639條成功提取1499條，手機報提取成功率為91.46%，BSC719手機報提取成功率最低2個小時忙時內總的下發(fā)1251條成功提取1085條，手機報提取成功率為86.73%，BSC728在2個小時忙時內總的下發(fā)次數(shù)為2061下發(fā)次數(shù)最多，成功提取1863條，

18、提取成功率為90.39%，BSC785在2個小時內總的下發(fā)1617條手機報，成功提取1456條，手機報提取成功率為90.04%。 早忙時段（7:30-9:30） 4個BSC手機報提取成功率統(tǒng)計如下：BSC總提取次數(shù)成功提取次數(shù)成功率BSC40499693393.67%BSC71976771292.83%BSC7281547141791.60%BSC7851429133093.07%總體4739439292.68%同晚忙時段統(tǒng)計結果對比BSC404手機報提取成功率依然最高2個小時內下發(fā)996條成功提取933條，手機報提取成功率為93.67%， BSC728在2個小時忙時內總的下發(fā)次數(shù)為1547下

19、發(fā)次數(shù)依然最多，成功提取1417條，提取成功率為91.60%，總體 提取成功率為92.68%高于晚忙時89.88%。 4個BSC晚忙時（17:00-19:00）各小區(qū)手機報提取成功率統(tǒng)計如下：各小區(qū)按照提取次數(shù)前20名列表如下：BSClac_ci總提取次數(shù)成功次數(shù)比例M40429675_4751116415292.68%M72858358_152313012293.85%M72858358_126111510490.43%M72858358_473011099587.16%M40429675_46621069892.45%M71929675_246031017473.27%M78529643_

20、8043968992.71%M71929675_1673957174.74%M72858358_1263948590.43%M71929675_24601937782.80%M40429675_4661897685.39%M40429675_26002857891.76%M40429675_23561847488.10%M71929675_4281847690.48%M72858358_7303837286.75%M40429675_47512826781.71%M72858358_1522797392.41%M72858358_24231787393.59%M71929675_1672776

21、280.52%M71929675_55800767497.37%上表中黃色部分標出的是成功率相對較低的小區(qū)。詳細列表見附件：4個BSC早忙時（7:30-9:30）各小區(qū)手機報提取成功率統(tǒng)計如下：各小區(qū)按照提取次數(shù)前20名：BSCLAC_CI總提取次數(shù)成功提取次數(shù)成功率M72858358_152313812792.03%M78529643_804311310895.58%M72858358_47301807695.00%M40429675_47511777698.70%M71929675_46242817390.12%M40429675_47512807290.00%M40429675_2356

22、1716794.37%M72858358_24293736690.41%M71929675_56243686494.12%M40429675_47523605998.33%M78529643_1891605693.33%M72858358_24231575698.25%M78529643_47051595593.22%M72858358_24292565496.43%M72858358_19631605185.00%M78529643_32614949100.00%M72858358_11891514996.08%M71929675_1673524994.23%M72858358_126160

23、4880.00%M72858358_47303524790.38%上表中黃色部分標出的是成功率相對較低的小區(qū)。詳細請見附件：3.1失敗原因分析首先看下正常接收手機報的流程，下圖為WAP手機報提取過程：手機接收彩信時，首先要和WAP網(wǎng)關建立連接，連接的過程與WAP上網(wǎng)前的連接過程相同。連接完成后，手機向WAP網(wǎng)關發(fā)送GET消息，里面含有彩信中心的地址及彩信的 Transaction ID。WAP網(wǎng)關將該消息轉換為HTTP消息，轉發(fā)至彩信中心。正常情況下，彩信中心向WAP網(wǎng)關發(fā)送該條彩信(m-retrieve-conf)。WAP網(wǎng)關收到該彩信后，轉化為WSP向手機轉發(fā)該彩信。手機收到該彩

24、信后，向WAP網(wǎng)關發(fā)送m-acknowledge-ind消息，確認彩信已經接收完畢，WAP網(wǎng)關轉發(fā)至彩信中心，彩信中心回復200 OK，WAP網(wǎng)關向手機回復WSP Reply，狀態(tài)碼為200 OK。手機向WAP網(wǎng)關發(fā)送WTP acknowledge消息，接收彩信過程完成。3.1.1用戶側發(fā)起PDP去激活分析：1. POST消息之前用戶側發(fā)起PDP去激活典型流程部分截圖如下圖：13秒第36個分包消息詳細解碼如下： 由于流程太長上面流程截圖中忽略掉中間部分下發(fā)分包消息，從上面流程可以看出該用戶在17：37:56227的時候發(fā)起PDP請求隨后經過tcp連接三握手后于17:38:00729發(fā)起get請

25、求開始下載手機報內容，隨后手機報內容被分割下發(fā)，一直下發(fā)到17:38:10197時的第36個分包，我們看到第36個分包消息的詳細解碼，發(fā)現(xiàn)TCP中Finish :more data from sender,說明這不是最后一個分包消息，還有沒有下發(fā)的分包消息，用戶13秒鐘后仍然沒有收到最后一個分包消息，開始發(fā)起deactivate PDP context request ，流程失敗。至于為何網(wǎng)絡側沒有下發(fā)最后一個分包后續(xù)將關聯(lián)其他接口做深入分析。2、Post 消息之后的PDP去激活失敗流程分析典型流程部分截圖如下：第52個分包消息的消息參數(shù)如下： 由上圖可以看出手機報分割下發(fā)后，下發(fā)到第52個分

26、包消息，通過該消息參數(shù)可以看到這個分包消息IP：total length :823比以上所有分包消息都小，手機終端認為這個分包就是最后一個分包消息，隨后向網(wǎng)絡側發(fā)起接收完成回應消息POST，手機接收彩信完成，post消息參數(shù)如下： 由消息參數(shù)可以看出該消息request_URI:設置正確，可能是由于網(wǎng)路側一直沒有收到終端上發(fā)的POST消息，最終網(wǎng)絡側沒有下發(fā)response 200 ok，最后用戶等待14秒鐘后仍然沒有收到網(wǎng)絡側的response，所以用戶發(fā)起deactivate pdp context request. 這種情況屬于用戶接收彩信完成，從用戶側角度來看屬于提取成功，但是如果網(wǎng)絡

27、側收不到post消息，不返回response 200 ok的話，彩信中心認為手機報沒有提取成功，將繼續(xù)保留該彩信直到過期，這樣勢必對彩信中心SP有影響，彩信日志中會出現(xiàn)手機報過期沒有提取的錯誤日志記錄。對以上2種用戶側發(fā)起PDP去激活情況進行統(tǒng)計發(fā)現(xiàn)Post之前的pdp去激活147次，post之后的PDP去激活71次。POST之前的PDP去激活請求屬于用戶行為，從局方角度無法干涉用戶主動放棄提取彩信行為，但是可以看出很大部分是由于下發(fā)過程太過漫長，以至于用戶主動放棄，這需要提高手機報下載速率來解決，post之后的PDP去激則在下一步分析中與GN口關聯(lián)分析，看是否是POST消息上發(fā)過程中網(wǎng)絡側丟

28、包或者與手機終端有關導致網(wǎng)絡側沒有發(fā)送response。Post之后的PDP去激活手機終端型號：手機終端型號次數(shù)SAMSUNG-GT-S5230C10SAMSUNG-GT-S3650C8MAUI MMS User Agent7SonyEricssonK700c7Nokia26103Nokia26263SAMSUNG-GT-S3930C_CMCC3SAMSUNG-S8300C3SAMSUNG-SGH-L878E2SHARP2SonyEricssonW302c2Android-Mms1Bird.M111Java1LENOVO I5161LENOVO-TD9001LG-KU3111PHOENIX1P

29、RIZM1SAMSUNG-GT-C5510U1SAMSUNG-GT-M8800C1SAMSUNG-GT-S56001SAMSUNG-GT-S6700C1SAMSUNG-GT-S7070C1SAMSUNG-SGH-E8481SHARP SH6220C1SonyEricssonF305c1SonyEricssonS500i1YuLong1YuLong-Coolpad73601YuLong-CoolpadN681不難看出主要是三星手機終端出現(xiàn)這種情況失敗，建議這些終端型號升級軟件。3.1.2小區(qū)更新過程分析：典型流程如下：可以看出數(shù)據(jù)包下發(fā)過程中，進行小區(qū)更新，從而導致網(wǎng)絡側無響應，消息流程失敗，這

30、種原因可能跟早忙、晚忙時，上下班高峰，很多用戶都在路上或者車上移動，頻繁進行小區(qū)更新，導致網(wǎng)絡側無響應超時失敗。下邊分析FLUSH過程對下手機報下載成功率以及下載速率的影響。3.1.3 FLUSH分析： Flush過程概況統(tǒng)計：統(tǒng)計結果如下：時段消息名稱次數(shù)占總FLUHS次數(shù)比例早忙時Flush-LL234279100.00%Flush-LL-ack6675528.49%晚忙時Flush-LL337835100.00%Flush-LL-ack8617125.51%由統(tǒng)計結果可以發(fā)現(xiàn)flush成功率比較低。時段Action 參數(shù)值次數(shù)占總FLUSH次數(shù)比例早忙時LLC-SDU(s)

31、 deleted6216726.54%LLC-SDU(s) transferred45881.96%晚忙時LLC-SDU(s) deleted7539722.32%LLC-SDU(s) transferred107743.19%通過對SGSN回復flush消息參數(shù)action的統(tǒng)計發(fā)現(xiàn)，LLC-SDU大多數(shù)被deleted,只有一小部分被轉發(fā)。在FLUSH流程中的FLUSH-ACK消息中BSSGP層中Action value參數(shù)有兩個可設定的值，一個為LLC-SDU(s) transferred 另一個為LLC-SDU(s) deleted。當設置成完全是LLC-SDU(s) deleted的

32、時候可以不返回FLUSH-ACK消息，在老的LLC-PDU也會被刪除掉。 在4個BSC的FLUSH流程中發(fā)現(xiàn)所有的參數(shù)Action value參數(shù)大部分都是LLC-SDU(s) deleted，所以有一部分FLUSH消息不被PCU相應屬于正常現(xiàn)象，不影響網(wǎng)絡的運行。 Flush過程描述下面為3GGP里面對FLUSH流程的描述。SGSN檢測到MS由于小區(qū)重選或者路由更新使得小區(qū)變更時，將向老BVCI發(fā)送一個FLUSH-LL PDU來啟動一下流程：l 一個NSE(如一個BSS即為一個NSE)和一個路由區(qū)內部的小區(qū)變更時，存儲在老BVCI(對應原小區(qū))中的由TLLI確定的LLC-PDU

33、要么被刪除，要么被傳送到與該TLLI相關聯(lián)的一個新BVCI（對應新的小區(qū)）。l 兩個NSE或兩個路由區(qū)之間的小區(qū)變更時，存儲在老的BVCI中的由TLLI確定的LLC-PDU被刪除。在FLUSH-LL PDU中，SGSN向BSSGP提供：l 用于識別MS的TLLI;l 用于識別小區(qū)的老BVCI，該小區(qū)可找到針對某個MS的緩存LLC-PDU；l 用于識別與MS當前相關聯(lián)的小區(qū)新的BVCI（僅在同一NSE和同一路由區(qū)時）FLUSH-LL PDU中如果沒有提供新BVCI，則視為刪除老的BVC排隊的LLC-PDU。排隊的BSSGP信令，比如尋呼消息，將不受這個流程影響。作為對FLUSH-LL PDU的回

34、應，BSS將SGSN發(fā)送一個FLUSH-LL-ACK PDU，該PDU包括：l FLUSH-LL PDU中收到的TLLI；l 是否轉發(fā)（在同一NSE內）或刪除LLC-PDU的指示。如果SDU指示為轉發(fā)，應包含新BVCI。當SGSN收到FLUSH-LL-ACK PDU時，如果該PDU指示了與老PDU指示了與老BVC相關聯(lián)的LLC-PDU已被刪除，SGSN將選擇如下操作之一：l 立即在新BVC（即新小區(qū)）上向MS重傳所有未確認的LLC-PDU（在LLC確認刷新下）；l 按照LLC重傳機制來發(fā)送未確認的LLC-PDU。當SGSN收到FLUSH-LL-ACK PDU時，該PDU指示了與老BVC相關聯(lián)的

35、LLC-PDU在NSE內轉發(fā)，SGSN不必執(zhí)行以上任何操作。在FLUSH-LL流程中，如果BSS能夠轉發(fā)緩存的LLC PDU給新BVCI，BSS上下文將被保存；否則BSS上下文將被刪除。原來的frame被deleted后,上層應用(TCP或WTP)會觸發(fā)重發(fā),如果重發(fā)成功的話,不會造成下載失敗. 但會造成時延較大。 Flush過程對手機報下載影響分析針對上文統(tǒng)計中手機報下載過程中，伴隨flush過程的timeout失敗流程進行分析。典型流程如下：由上圖可以看出手機報下載過程中用戶17:42:34084從小區(qū)LAC:29675；CI：26001更新到LAC:29675；CI:260

36、02，并且Flush-LL-ACK，action value:LLC-SDU(S) deleted。由上圖可以看出sequence number：317D09AE(830278062)以及 sequence number：317D0F4E(830279498)，sequence number：317D0412(830276626)均被觸發(fā)重傳。顯然由于網(wǎng)絡一直重傳下行數(shù)據(jù)包而沒有得到終端響應，最終導致超時失敗。就算最終下載成功，小區(qū)更新觸發(fā)重傳也會對下載速率產生很大影響。發(fā)生flush的各小區(qū)統(tǒng)計如下：BVCILACCIflush次數(shù)103529643189319381100029643560

37、711928910102964324472186901009296432447117648103329643189117333102729643885114095104229643251631369310022964356073120351007296438042117131028296438852111821004296434764285901041296432516284361008296438043831110172964347053765410462964353041760310152964347051759910062964380417555102429643326169681005

38、29643476436893102329675462416066詳細清單見如下附件: 數(shù)據(jù)包重傳分析小區(qū)更新會觸發(fā)下行數(shù)據(jù)包的重傳，下邊則對重傳率進行統(tǒng)計。早晚忙時段下行包重傳率如下：時段下行傳送包數(shù)下行重傳包數(shù)重傳率早忙時9269631760082.92%晚忙時179422719438010.83%早忙時下行數(shù)據(jù)包重傳率為2.92%，晚忙時下行數(shù)據(jù)包重傳率10.83%，明顯高于早忙時。早忙時各小區(qū)重傳率統(tǒng)計如下：按照重傳率排名前20：BVCI重傳包個數(shù)總的下行包個數(shù)重傳率10677331323.32%1064352261513.46%104943463648011.91%105

39、488398818.94%105721030546.88%10381392212896.54%10502101351695.97%10632127382775.56%10313779692985.45%10402230415965.36%10511039243864.26%101142121023824.11%10152739722243.79%105332989123.69%10032768755323.66%103340171099263.65%10462702743303.64%10012107584433.61%10221366395473.45%10412242655023.42%詳

40、細清單見附件如下： 晚忙時各小區(qū)重傳率統(tǒng)計如下：按照重傳率排名前20：BVCI重傳包次數(shù)下行包次數(shù)重傳率10531039291435.66%1066355114730.95%1069197027.14%1032401174023.05%10621508731720.61%10521777935019.01%102840002206618.13%104950192785118.02%104731721906016.64%101050683087116.42%101217951098316.34%104238122365416.12%106331251949316.03%1014272517458

41、15.61%102755163564115.48%101338912520715.44%101848283340714.45%100758934092514.40%104147783333914.33%103019701402814.04%：詳細清單如附件： 小結：Ø 針對重傳率較高的小區(qū)LA參數(shù)調整建議：建議LA設置為ON，在C/I好的情況下盡可能使用高編碼方式，在C/I低的情況下使用低編碼方式，降低重傳。Ø 對數(shù)據(jù)流量大且移動性能不太好的小區(qū)，即導致TBF中斷的小區(qū)重選間隔較短的小區(qū)，通過調整一些空閑模式參數(shù)，盡量減少小區(qū)重選，以提高其移動性能，建議進行參

42、數(shù)調整的小區(qū)如下；BSCLAC_CI手機報總提取次數(shù)手機報提取成功次數(shù)手機報提取成功率該小區(qū)FLUSH發(fā)生次數(shù)M78529643_8043968992.71%2709M72858358_1522797392.41%1814M78529643_1891756181.33%11077M78529643_8042746587.84%4349M78529643_53041716185.92%2081M78529643_47051625385.48%3949M78529643_47641605896.67%2806M78529643_47642595389.83%2996M71929675_462414

43、94489.80%3972M78529643_47643464393.48%2584M78529643_47052434093.02%2644M78529643_193134040100.00%1251M78529643_3261403587.50%2567M78529643_56071383592.11%11773M78529643_24471383386.84%8964M78529643_244733636100.00%1794M7192967514%2825M78529643_23721343397.06%1295M78529643_24472333193.94

44、%7115M78529643_1893333090.91%9715M78529643_28801292586.21%1069M78529643_1894292793.10%1492M78529643_56072262492.31%1280M78529643_8041262284.62%3773M78529643_19312242291.67%1886M78529643_47053222090.91%3995M78529643_56073212095.24%5338M78529643_23723212095.24%16423.1.4 Response非成功狀態(tài)碼整體統(tǒng)計： 晚忙時各非成功狀態(tài)碼統(tǒng)

45、計如下：error_status次數(shù)比例500 Internal Server Error6484.21%502 Bad Gateway67.89%403 Forbidden22.63%405 Method not allowed22.63%400 Bad Request11.32%504 Gateway Timeout11.32%附圖如下：通過統(tǒng)計發(fā)現(xiàn)主要的非成功狀態(tài)碼為：500 Internal Server Error占84.21%。早忙時非成功狀態(tài)碼分析：error_status 次數(shù)比例500 Internal Server Error3271.11%404 Not Found511

46、.11%403 Forbidden36.67%502 Bad Gateway36.67%405 Method Not Allowed24.44%附圖如下：比較早晚忙手機報提取返回非成功狀態(tài)碼發(fā)現(xiàn)主要的失敗原因都是500 Internal Server Error。下邊對這些非成功狀態(tài)碼進行深入分析。3.1.5 Response 非成功狀態(tài)碼失敗原因分析：Ø 500 Internal Server Error分析： 典型流程截圖如下：Post消息參數(shù)如下： 由上圖可以看出用戶發(fā)起的POST消息中彩信中心地址設置錯誤：host；mmsc.vnet.mobi正確的彩信中心地址應該為：。因此

47、SGSN返回response消息中Status code :500 internal server error。另外我們發(fā)現(xiàn)有些彩信中心地址設置正確的消息流程也出現(xiàn)同樣的500 internal server error,這主要是由于SP不穩(wěn)定，統(tǒng)計如下：Url_mainFrom_NumberError_Statuspost_uri211.138.236TYPE=PLMN500 Internal Server Error211.138.236TYPE=PLMN500 Internal Server Error3210

48、658000/TYPE=PLMN500 Internal Server Error211.138.236TYPE=PLMN500 Internal Server Error211.138.236TYPE=PLMN500 Internal Server Error211.138.236TYPE=PLMN500 Internal Server Error211.138.236TYPE=PLMN500 Internal Server Error發(fā)現(xiàn)SP均是10658000，通過分析發(fā)現(xiàn)106580

49、00主要的發(fā)送內容為新聞早晚報以及三湘晨晚報，該SP下發(fā)手機報占所有下發(fā)手機報比例89.71%，所以建議提高該SP穩(wěn)定性。Ø 404 Not Found分析：典型流程截圖如下：Get消息參數(shù)截圖如下：由上圖可以看出用戶發(fā)起的提取手機報的Get消息Uri main： ，不是標準的手機報地址，因此這種失敗是由于用戶終端請求地址上報錯誤，同時彩信中心地址設置也錯誤。統(tǒng)計結果如下：to_numberurl_mainerror_statuspost_urimobil_type次數(shù)8615200834633404 Not FoundMyWebClient1.02 8615811113445221

50、.179.185.231404 Not FoundNokiaE63-12 8613548767889404 Not Found1 這種原因屬于終端原因導致錯誤的GET請求中的URI不是標準的彩信中心地址，建議對這種終端進行關注。Ø 502 Bad Gateway分析：典型流程如下：由上圖可以看出用戶向彩信中心發(fā)起get請求，url:67,在手機報提取過程中，終端往網(wǎng)絡側發(fā)送了一個上行包,由于彩信中心SP不接受終端發(fā)送的這種數(shù)據(jù)包所以對其進行拒絕，發(fā)送response status code:502 bad geteway 。我們對這種失敗進行統(tǒng)計，結果如下：由統(tǒng)計結果可以看出終端類型是MOZILLA和coolpadf800 并且彩信中心地址都是32正確的彩信中心地址應該為：。從而可以認為這是終端原因造成的。Ø 403 Forbidden典型流程如下：由上圖可以看出，終端手機在18:05:54156向彩