【正文】 10658000/TYPE=PLMN人民手機報綜合版%10658000/TYPE=PLMNhinaDaily晚報%10658000/TYPE=PLMN新華手機報%1065868866/TYPE=PLMN世界杯開始了%10658688734/TYPE=PLMN衡陽手機報晚報%由上表可以看出主要的手機報內容是手機報新聞早晚報。 PILTIMER調整建議：Packet Idle List Timer，當一個OnDemand PDCH處于空閑狀態(tài)（Idle）時，將被系統(tǒng)放置在PS域的空閑列表，同時PILTIMER啟動，當PILTIMER超時，Ondemand PDCH將返回CS域。由上面2個統(tǒng)計列表可以看出suspend次數(shù)為247947次，resume次數(shù)為226155，比suspend少21792次，這將會影響21792次數(shù)據(jù)業(yè)務的持續(xù)性。216。 “suspend” 過程一般不會對網(wǎng)絡性能產(chǎn)生影響，但是如果經(jīng)常做“suspend”過程，就會對網(wǎng)絡產(chǎn)生一定影響。雖然最終此條手機報成功下載，但是下載時間損耗過長，對網(wǎng)絡手機報下載速率有較大影響。在LAC，RAC，SGSN邊界發(fā)生SUSPEND NACK的情況，在當前的算法機制下似乎無解，因為做位置更新時肯定要SUSPEND，而SUSPEND的時候，因為手機還未做路由區(qū)更新，還未在新的SGSN下登記，所以新SGSN肯定不認識這個手機，似乎陷入了死循環(huán)。假設MS在跨LAC，RAC，SGSN發(fā)生重選時，先要進行位置更新，這時需要進行SUSPEND，但是如果新SGSN還沒有MS的登記信息，就會發(fā)生SUSPENDNACK，然后再進行路由區(qū)更新。Resume失敗跟suspend相同典型流程如下：RESUME失敗原因和SUSPEND NACK一樣，也是Unkown MS。此種情況下，MS往往發(fā)出多次“suspend”,SGSN因為忙或者負荷較高都未對其進行相應的處理。 對應流程截圖如下：基于上圖，分析如下：216。 在MS進入新的小區(qū)時，MS會發(fā)起“suspend”，但SGSN不能夠識別該MS，故發(fā)出“suspend nack”，其中包含原因“Unknown MS”，此時BSS一般會終止此次“suspend”過程。 在MS進入新的小區(qū)時，MS會發(fā)起“suspend”過程，但是由于手機上報的PTMSI與SGSN存儲的一樣，但是是兩個不同的用戶，SGSN可能不識別，會發(fā)出“suspend nack”信息。suspend與resume成功率統(tǒng)計如下：MessageCounterRateDelayBSSGP SUSPEND247947%BSSGP SUSPENDNACK8749%TimeOut26%　BSSGP SUSPENDACK239172%Suspend %。對于“RESUME”: BSC向SGSN發(fā)出請求，SGSN回復確認；“RESUME”過程結束。CS業(yè)務完成后，BSC發(fā)送 Resume消息到SGSN，恢復PS業(yè)務。下邊對SUSPEND/RESUME過程則具體分析該過程對手機報下載速率以及成功率的影響。對這種失敗發(fā)生的小區(qū)進行統(tǒng)計如下表：LACCI發(fā)生次數(shù)29643476432296751673229675527132296755624325835819633229643406212964323722129643244711296433251212964347642129643526611296435267212967516711296751672129675466212967512880129675246031296752600212967547512129675475131296755675212967556813158358126115835815221583583031158358461115835873031583581963115835824291158358242931 Suspend過程中伴隨LLC_discarded的超時失敗：典型流程部分截圖如下：由消息流程可以看出手機報提取的過程中發(fā)生了Spended過程，但是隨后伴隨的是小區(qū)更新以及路由區(qū)更新，路由區(qū)更新完成后，一直沒有resume消息恢復數(shù)據(jù)業(yè)務，最終導致超時失敗。其中400 Bad Request屬于彩信過期提取，由于早晚忙時數(shù)據(jù)中只出現(xiàn)一次，在此不在深入分析。這個時間差小于一秒鐘，隨后手機又重新發(fā)起get請求，結果又在不到一秒鐘的時間內，網(wǎng)絡側拒絕，發(fā)起response status code: 403 Forbidden。 403 Forbidden典型流程如下：由上圖可以看出，終端手機在18:05:54’156向彩信中心發(fā)起get請求后URI main:。從而可以認為這是終端原因造成的。 502 Bad Gateway分析：典型流程如下：由上圖可以看出用戶向彩信中心發(fā)起get請求，url:,在手機報提取過程中，終端往網(wǎng)絡側發(fā)送了一個上行包,由于彩信中心SP不接受終端發(fā)送的這種數(shù)據(jù)包所以對其進行拒絕，發(fā)送response status code:502 bad geteway 。統(tǒng)計結果如下：to_numberurl_mainerror_statuspost_urimobil_type次數(shù)8615200834633404 Not Found2 8615811113445404 Not FoundNokiaE6312 8613548767889404 Not Found　　1 這種原因屬于終端原因導致錯誤的GET請求中的URI不是標準的彩信中心地址，建議對這種終端進行關注。216。因此SGSN返回response消息中Status code :500 internal server error。 Response 非成功狀態(tài)碼失敗原因分析：216。早忙時非成功狀態(tài)碼分析：error_status 次數(shù)比例500 Internal Server Error32%404 Not Found5%403 Forbidden3%502 Bad Gateway3%405 Method Not Allowed2%附圖如下：比較早晚忙手機報提取返回非成功狀態(tài)碼發(fā)現(xiàn)主要的失敗原因都是500 Internal Server Error。216。早忙時各小區(qū)重傳率統(tǒng)計如下：按照重傳率排名前20：BVCI重傳包個數(shù)總的下行包個數(shù)重傳率106773313%10643522615%1049434636480%10548839881%10572103054%1038139221289%1050210135169%1063212738277%1031377969298%1040223041596%1051103924386%10114212102382%1015273972224%10533298912%1003276875532%10334017109926%1046270274330%1001210758443%1022136639547%1041224265502%詳細清單見附件如下： 晚忙時各小區(qū)重傳率統(tǒng)計如下：按照重傳率排名前20：BVCI重傳包次數(shù)下行包次數(shù)重傳率105310392914%10663551147%10691970%10324011740%106215087317%105217779350%1028400022066%1049501927851%1047317219060%1010506830871%1012179510983%1042381223654%1063312519493%1014272517458%1027551635641%1013389125207%1018482833407%1007589340925%1041477833339%1030197014028%：詳細清單如附件： 小結：216。發(fā)生flush的各小區(qū)統(tǒng)計如下：BVCILACCIflush次數(shù)10352964318931938110002964356071192891010296432447218690100929643244711764810332964318911733310272964388511409510422964325163136931002296435607312035100729643804211713102829643885211182100429643476428590104129643251628436100829643804383111017296434705376541046296435304176031015296434705175991006296438041755510242964332616968100529643476436893102329675462416066詳細清單見如下附件: 數(shù)據(jù)包重傳分析小區(qū)更新會觸發(fā)下行數(shù)據(jù)包的重傳，下邊則對重傳率進行統(tǒng)計。顯然由于網(wǎng)絡一直重傳下行數(shù)據(jù)包而沒有得到終端響應，最終導致超時失敗。典型流程如下：由上圖可以看出手機報下載過程中用戶17:42:34’084從小區(qū)LAC:29675；CI：26001更新到LAC:29675；CI:26002，并且FlushLLACK，action value:LLCSDU(S) deleted。原來的frame被deleted后,上層應用(TCP或WTP)會觸發(fā)重發(fā),如果重發(fā)成功的話,不會造成下載失敗. 但會造成時延較大。當SGSN收到FLUSHLLACK PDU時，該PDU指示了與老BVC相關聯(lián)的LLCPDU在NSE內轉發(fā)，SGSN不必執(zhí)行以上任何操作。如果SDU指示為轉發(fā)，應包含新BVCI。排隊的BSSGP信令，比如尋呼消息，將不受這個流程影響。在FLUSHLL PDU中，SGSN向BSSGP提供：l 用于識別MS的TLLI。SGSN檢測到MS由于小區(qū)重選或者路由更新使得小區(qū)變更時，將向老BVCI發(fā)送一個FLUSHLL PDU來啟動一下流程：l 一個NSE(如一個BSS即為一個NSE)和一個路由區(qū)內部的小區(qū)變更時，存儲在老BVCI(對應原小區(qū))中的由TLLI確定的LLCPDU要么被刪除，要么被傳送到與該TLLI相關聯(lián)的一個新BVCI（對應新的小區(qū)）。 在4個BSC的FLUSH流程中發(fā)現(xiàn)所有的參數(shù)Action value參數(shù)大部分都是LLCSDU(s) deleted，所以有一部分FLUSH消息不被PCU相應屬于正?，F(xiàn)象，不影響網(wǎng)絡的運行。在FLUSH流程中的FLUSHACK消息中BSSGP層中Action value參數(shù)有兩個可設定的值，一個為LLCSDU(s) transferred 另一個為LLCSDU(s) deleted。 FLUSH分析： Flush過程概況統(tǒng)計：統(tǒng)計結果如下：時段消息名稱次數(shù)占總FLUHS次數(shù)比例早忙時FlushLL234279%FlushLLack66755%晚忙時FlushLL337835%FlushLLack86171%由統(tǒng)計結果可以發(fā)現(xiàn)flush成功率比較低。：典型流程如下：可以看出數(shù)據(jù)包下發(fā)過程中，進行小區(qū)更新，從而導致網(wǎng)絡側無響應，消息流程失敗，這種原因可能跟早忙、晚忙時，上下班高峰，很多用戶都在路上或者車上移動，頻繁進行小區(qū)更新，導致網(wǎng)絡側無響應超時失敗。POST之前的PDP去激活請求屬于用戶行為，從局方角度無法干涉用戶主動放棄提取彩信行為，但是可以看出很大部分是由于下發(fā)過程太過漫長，以至于用戶主動放棄，這需要提高手機報下載速率來解決，post之后的PDP去激則在下一步分析中與GN口關聯(lián)分析，看是否是POST消息上發(fā)過程中網(wǎng)絡側丟包或者與手機終端有關導致網(wǎng)絡側沒有發(fā)送response。Post 消息之后的PDP去激活失敗流程分析典型流程部分截圖如下：第52個分包消息的消息參數(shù)如下： 由上圖可以看出手機報分割下發(fā)后，下發(fā)到第52個分包消息，通過該消息參數(shù)可以看到這個分包