【文章內容簡介】 。request消息在傳輸中丟失或者 Radius的處理異常。 另外六次則是因為 Gb口以下和 Radius與 WAP網關間的耗時過長。 GGSN向 Radius發(fā)送 AccountingRequest消息，等待 Radius的響應，并啟動相應的等待定時器，在相應的 WAP網關側，我們發(fā)現(xiàn) WAP網關在收到 AccountingRequest消息后沒有給予響應，由于 GGSN沒有收到 AccountingRequest消息的響應消息，導致等待定時器超時，然后 GGSN重新發(fā)送 AccountingRequest消息，在相應的 WAP網關側，我們發(fā)現(xiàn) WAP網關此次給予了響應， GGSN收到 Radius轉發(fā)的 AccountingResponse消息，這時 GGSN才對手機的 PDP激活請求進行響應。專題 —PDP 激活問題PDP故障案例四 : PDP激活失敗正是由于 Gi口的耗時過長，使得無線側的定時器超時而釋放了 TBF資源，所以手機在接收 PDP激活接受消息時，重新進行了 TBF的建立，這又進一步增加了在無線口上的延時。因此， WAP網關的響應過慢，是導致 PDP激活時延過長根本原因。專題 —PDP 激活問題PDP故障案例五 : PDP激活失敗在中國移動集團公司第三方測試的準備工作中，發(fā)現(xiàn) GPRSCQT的火車站測試點有 PDP激活失敗的現(xiàn)象，并且多次測試問題始終存在。從信令來看，當下行的立即指配信息里出現(xiàn)了右圖中 ARFCN為 809的時候， PDP激活會不成功。專題 —PDP 激活問題PDP故障案例五 : PDP激活失敗809這個頻點是不正常的，但這是根據(jù)手機收到基站發(fā)出的層三消息解出來的。這個立即支配消息是為了分配下行的 TBF，也就是意味著網絡已收到 PDP激活申請且給手機回復了 PDPactivateaccept消息，但此消息未能通過空中接口。當時懷疑是否因測試軟件導致，詢問 CDS軟件研發(fā)工程師，回復軟件應該沒有問題，也不像測試手機問題，所以網絡下發(fā)的消息編碼存在問題的可能性比較大。對同個 BSC下的三晉國際飯店測試沒有發(fā)現(xiàn)同樣的問題。調整頻點和無線參數(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(=LLCDISCARDED)的信令。見下圖：專題 —PDP 激活問題PDP故障案例五 : PDP激活失敗專題 —PDP 激活問題PDP故障案例五 : PDP激活失敗總之 ,雖然在 CDS的 LOG里存在 PDP失敗 ,但是從 GB數(shù)據(jù)里反應出的流程卻是完整的 ,而且 SGSN都是在收到 MS的 APCR后就立即回復了 APAC。因此分析結果表明這幾次的 PDP激活失敗并非由核心網引起，可能是由無線側導致了手機未能收到 SGSN發(fā)的 APAC而產生 TIMEOUT。由于無線質量、 GPRS統(tǒng)計和參數(shù)、核心網、分布系統(tǒng)等都沒有問題，這時我們把重點放在基站硬件這一側。 因為 8593也會出現(xiàn)閃斷，懷疑是否因傳輸誤碼率過高而導致，所以要求更換傳輸，換完傳輸后進行測試，還是沒有效果。 由于在 8591測試時 PDP激活成功率為 100％，把 8591的 BTS和 8593的 BTS進行調換再測試。在調換完后的 200次 PDP激活測試中， 8593沒有出現(xiàn)一次失敗，而原來好的小區(qū) 8591出現(xiàn)了 5次 PDP激活失敗。最終更換了 8593BTS，問題得到解決。專題 —Ping 問題qPing優(yōu)化方法216。優(yōu)化 PingServer,將 PingServer搬到 FW內216。檢查覆蓋216。防止頻繁的小區(qū)重選216。排查干擾，提高 C/I216。檢查靜態(tài) PS信道、動態(tài) PS信道配置216。檢查 Gblinksload，調整 NSEI配置216。檢查 GPRS參數(shù)設置，合理設置 DrxTimeMax、 MFR、 T3168216。優(yōu)化測試測試電腦，關閉所有系統(tǒng)軟件以及應用軟件的自動更新功能專題 —Ping 問題Ping故障案例一 : 不同時間間隔造成 PING時延不同問題： Ping測試中時間間隔設置為 4s12s測試結果有很大差別。經過核心網掛表測試發(fā)現(xiàn) Ping時延不穩(wěn)定是因為測試過程中出現(xiàn)其他一些數(shù)據(jù)包，這些垃圾數(shù)據(jù)包是由殺毒軟件和一些應用軟件自動更新造成的。解決方案： 重新安裝操作系統(tǒng)，不能安裝與測試無關的軟件，將托盤中的任何與網絡通訊相關的程序關閉，關閉 Windows的自動更新功能。專題 —Ping 問題Ping故障案例二 : Ping失敗問題： PING失敗時誤碼率很高，查看網管指標發(fā)現(xiàn)此時干擾比較嚴重，但是其他時段幾乎沒有干擾，基本可以確定該干擾是外部干擾。 解決方案： 查找外部干擾。專題 —Ping 問題Ping故障案例三 :Ping失敗問題： 由于小區(qū)的 C/I低導致較高的 BLER（小區(qū) BCCHC／ I＝ ）。查看規(guī)劃數(shù)據(jù)，微蜂窩 8800、 7660、 8750是同 BCCH解決方案： 控制 8800、 7660、 8750覆蓋，調整 8800、 7660、 8750頻點。專題 —WAP 問題qWAP優(yōu)化方法216。優(yōu)化 WAP網關、移動夢網服務器、 Gi口216。檢查覆蓋216。防止頻繁的小區(qū)重選216。排查干擾，提高 C/I216。檢查靜態(tài) PS信道、動態(tài) PS信道配置216。檢查 Gblinksload，調整 NSEI配置216。檢查 GPRS參數(shù)設置，合理設置 DrxTimeMax、 MFR、 T3168216。優(yōu)化測試測試電腦，關閉所有系統(tǒng)軟件以及應用軟件的自動更新功能專題 —WAP 問題WAP故障案例一 :WAP刷新失敗問題： 出現(xiàn) WAPreply失敗的時候 GPRS的質量為 6級，從服務小區(qū)和鄰區(qū)的測量來看，存在著鄰頻的干擾。解決方案： 更改頻點。專題 —WAP 問題WAP故障案例一 :WAP圖鈴下載速率低問題： 通過分析看出 RLC數(shù)據(jù)重傳率高，從 OMC統(tǒng)計數(shù)據(jù)看 Gblink的負荷在測試時段已高達 64%，從而導致下載速率低。解決方案： 重新調整 NSEI以減低 Gblinkload，從而提高 GPRSCQT的下載速率。專題 —WAP 問題WAP故障案例三 :WAP登陸失敗問題： 在 **賓館 WAP登陸測試中，通過跟蹤 Gb口發(fā)現(xiàn)，手機上行發(fā)送Get(URL= PDU，具體內容為：Yourrequestforaservicecouldnotbefulfilled,pleasetryagainorcontactyouroperatoriftheproblempersists。這種現(xiàn)象是因為移動夢網服務器出現(xiàn)問題。解決方案： 與核心網工程師溝通解決。專題 —WAP 問題WAP故障案例四 :WAP登陸和刷新時延過長GB口WAP測試流程專題 —WAP 問題WAP故障案例四 :WAP登陸和刷新時延過長WAP測試信令流程問題： 信令分析發(fā)現(xiàn)，網關在CONNECT到 CONNECTREPLY和 GET到 REPLY間存在響應時延長，需重復發(fā)送 GET請求 ,甚至會出現(xiàn)沒有響應的情況，尤其是 GET與 REPLY間經常出現(xiàn)較大的信令時延，有的甚至達到幾十秒 ,對手機訪問WAP速度有較大影響。我們初步認為打開 WAP網頁時超過 20秒以上的大時延基本都是由網關時延引起的。解決方案： 核心網工程師針對WAP網關進行優(yōu)化。專題 —WAP 問題WAP錯誤代碼含義 —WTP 層協(xié)議發(fā)生錯誤 專題 —WAP 問題WAP錯誤代碼含義 — WSP層協(xié)議發(fā)生錯誤 專題 —WAP 問題WAP錯誤代碼含義 —HTTP 協(xié)議發(fā)生錯誤 專題 —MMS 問題qMMS優(yōu)化方法216。優(yōu)化相關核心網網關及接口、移動 Radius到省內216。檢查覆蓋216。防止頻繁的小區(qū)重選216。排查干擾，提高 C/I216。檢查靜態(tài) PS信道、動態(tài) PS信道配置216。檢查 Gblinksload，調整 NSEI配置216。檢查 GPRS參數(shù)設置，合理設置 DrxTimeMax、 MFR、 T3168專題 —MMS 問題MMS故障案例一 :MMS發(fā)送失敗問題：通過掛表發(fā)現(xiàn)手機首先 PDP激活， APN為 CMWAP，但是手機隨后沒有任何發(fā)起任何信令。這種情況是由于手機軟件進程吊死所致。解決方案：重裝手機操作系統(tǒng)。專題 —MMS 問題MMS故障案例二 :MMS接收失敗問題：通過掛表發(fā)現(xiàn)手機首先建立了 WSP層的連接，然后發(fā)起 GET請求接收彩信，隨后 WAP網關將彩信在 WTP分割后，向手機發(fā)送 WTP層的分段，當傳送到第六個分段后該消息中的 GTR和 TTR都為 0，說明該分段既不是整個消息中某組的最后一塊，也不是整個消息的最后一塊，但是手機卻回應了 ACK，緊接著又發(fā)起一個 Transaction(Invoke)。這種情況是由于手機軟件故障所致。解決方案：重裝手機操作系統(tǒng)。專題 —MMS 問題MMS故障案例三 :MMS接收失敗問題：通過 Gi口掛表發(fā)現(xiàn)手機在發(fā)起 Get請求后，在 10ms左右的時間連續(xù)多次重發(fā) Get請求（ Get請求重發(fā)定時器為 10s），導致 WAP網關來不得處理手機的Session，從重發(fā)時間間隔來看，不可能是手機連續(xù)接收彩信。這種情況是由于手機軟件故障所致。解決方案：重裝手機操作系統(tǒng)。專題 —MMS 問題MMS故障案例四 :MMS發(fā)送失敗問題：通過掛表我們發(fā)現(xiàn)手機首先上行發(fā)送 WSP層的 Connect信令，建 WSP層的連接，但是 WAP網關沒有回應 ConnectReply，手機等待 5秒后重 Connect，但是始終沒有回應 ConnectReply，達到最大重發(fā)次數(shù) 5次后， WSP層的建鏈失敗，最終導致彩信發(fā)送失敗。導致此次 MMS發(fā)送失敗的原因為 WAP網關過于繁忙沒有回應 ConnectReply。解決方案：請核心網工程師配合解決。專題 —FTP 問題qFTP優(yōu)化方法216。優(yōu)化 FTPServer，將 FTPServer搬到 FW內 216。檢查覆蓋216。防止頻繁的小區(qū)重選216。排查干擾，提高 C/I216。檢查靜態(tài) PS信道、動態(tài) PS信道配置216。檢查 Gblinksload，調整 NSEI配置216。調整 DLB、 ULB、 DLBH、 ULBH參數(shù)，動態(tài)調整 CS的比例 216。檢查 GPRS參數(shù)設置，合理設置 DrxTimeMax、 MFR、 T316 T3192216。打開 CS CS4專題 —FTP 問題FTP故障案例一 :FTP下載失敗問題： MS重選到小區(qū) 41921后， DLTBF一直沒被建立導致長時間下行無數(shù)據(jù)傳輸，最終導致了 PDP掉線 .經檢查該小區(qū)在測試時間段內的 GPRSKPI：下行時隙分配擁塞率比較高，這是為什么沒能建立 DLTBF的主要原因所在。解決方案： 增加該小區(qū)靜態(tài) PS信道。專題 —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信道，下載成功。導致平均下載速率只有 。解決方案： 擴充 3055 30152靜態(tài) PS信道；調整 30553RXLEVACCESSMIN由 10到 12。專題 —FTP