Jupiter198343
初級會員
 發(fā)短消息
關(guān)注Ta
積分 86
帖子 16
威望 10048 個
禮品券 8 個
專家指數(shù) 6
注冊 2012-7-1 專業(yè)方向
通信，計算機(jī)
回答問題數(shù) 0
回答被采納數(shù) 0
回答采納率 0%
|
大
中
小
發(fā)表于 2012-10-30 13:29:37
只看樓主
|
|
上海網(wǎng)絡(luò)HSDPA業(yè)務(wù)無速率問題分析報告 1.
問題描述聯(lián)芯投訴:從5月18日起,陸續(xù)出現(xiàn)用戶投訴用聯(lián)芯數(shù)據(jù)卡上網(wǎng)無流量的問題,終端撥號連接正常,但網(wǎng)頁打不開,網(wǎng)址也ping不通;5月25日以后,此現(xiàn)象開始大量出現(xiàn),聯(lián)芯測試人員用華為ET128數(shù)據(jù)卡在大唐無線網(wǎng)絡(luò)下發(fā)現(xiàn)有同樣問題.
2.
定位過程6月9日,產(chǎn)品線支持人員到聯(lián)芯公司實驗室協(xié)助定位,用2臺8130終端嘗試數(shù)次,問題未能復(fù)現(xiàn);用5731E數(shù)據(jù)卡,問題2次復(fù)現(xiàn);同時這些終端都能正常進(jìn)行FTP下載.測試地點為聯(lián)芯公司實驗室,信號為室外小區(qū)覆蓋,P-CCPCH RSCP較高,在-60dBm左右.另外經(jīng)了解,西安研發(fā)部梁劍曾在上個月來上海定位過網(wǎng)頁打不開問題,最終定位為上海移動的防火墻負(fù)荷過重導(dǎo)致大量丟包.結(jié)合以上信息,做出初步分析,問題有如下可能原因
１）從2款終端的表現(xiàn)看,聯(lián)芯5731數(shù)據(jù)卡和8130手機(jī)的處理可能存在差異.需要通過進(jìn)一步的測試來判斷
２）網(wǎng)絡(luò)傳輸某個環(huán)節(jié)仍然存在丟包問題.經(jīng)過向梁劍了解,上次定位后,防火墻進(jìn)行了調(diào)整,性能有所提升,由防火墻導(dǎo)致的丟包大大降低,但并不能保證防火墻,或是由核心網(wǎng)到RAN的有線連接某個環(huán)節(jié)存在傳輸丟包,這應(yīng)該是后續(xù)關(guān)注的主要方向.
３）空口信號質(zhì)量差導(dǎo)致丟包,在聯(lián)芯測試時使用的小區(qū),其基站HSDPA算法中,CQI算法的”初始Bler”按室外環(huán)境標(biāo)定為10%,這個參數(shù)設(shè)置如果超過實際Bler太高,會導(dǎo)致Mac-hs向空口發(fā)包的速率超過此空口環(huán)境下終端的正確解調(diào)能力,導(dǎo)致誤塊率迅速上升.但經(jīng)過觀察和驗證,此環(huán)境下實際Bler應(yīng)該大于5%,在8%~10%左右,也就是說此時基站參數(shù)的設(shè)置基本合理,不會導(dǎo)致空口性能的惡化;另外,在終端不能打開網(wǎng)頁的過程中,伴隨的是始終正常的FTP下載過程,如果是空口質(zhì)量不好導(dǎo)致網(wǎng)頁基本不能打開,FTP的丟包率應(yīng)該相當(dāng)高,但此時FTP的重傳率在10%左右,因此這個原因的可能性較小,作為后續(xù)關(guān)注的次要方向.
6月10日,大唐人員和聯(lián)芯測試人員,在大唐分公司會議室進(jìn)行了多款商用終端的對比測試,共驗證了聯(lián)芯8130手機(jī),以及聯(lián)芯5731E,中興MU350華為ET128,三星等幾款數(shù)據(jù)卡,測試地點為中打-1小區(qū)(RNC390,TDR2000+TDB09A.P-CCPCH RSCP大于-60dBm).測試方法為用4款終端對4個門戶網(wǎng)站進(jìn)行ping操作,結(jié)果為:
Ping次數(shù)/響應(yīng)次數(shù)
| 搜狐
| 新浪
| 百度
| 網(wǎng)易
| 聯(lián)芯8130
| 4/4
| 4/4
| 4/0
| 4/0
| 聯(lián)芯5731E
| 4/4
| 4/4
| 4/0
| 4/0
| 三星
| 4/4
| 4/4
| 4/0
| 4/0
| 華為ET128
| 4/0
| 4/0
| 未找到主機(jī)
| 4/3
|
Ping不通的網(wǎng)址，網(wǎng)頁也打不開，但同時FTP下載正常。
當(dāng)天的測試過程中，同時跟蹤了如下信息：終端測wireshark抓包，Iub口TDPA跟蹤Iub口用戶面，基站內(nèi)部跟蹤FP消息，RNC內(nèi)部進(jìn)行QoS級UE跟蹤，CN內(nèi)部進(jìn)行Gi接口跟蹤。其中對8130訪問網(wǎng)站時的終端側(cè)和CN側(cè)Log結(jié)合分析如下：
<8130終端第一次跟蹤>:
(1)連接crl.microsoft.com,服務(wù)器回復(fù)2個主機(jī)地址(745行)
終端向第1個主機(jī)地址發(fā)送3次TCP握手請求,該主機(jī)無響應(yīng)
(2)連接www.163.com,服務(wù)器返回10個主機(jī)地址(1005行)
主機(jī)響應(yīng)終端的域名解析請求88秒后,終端才開始向該主機(jī)發(fā)TCP握手請求,發(fā)送3次,終端無響應(yīng)
(3)連接www.baidu.com,服務(wù)器返回2個主機(jī)地址(2356行)
作了數(shù)次ping操作,主機(jī)均有響應(yīng),但終端未收到
(4)連接www.sohu.com,服務(wù)器返回2個主機(jī)地址(3830行)
作了數(shù)次ping操作,主機(jī)均有響應(yīng),但終端未收到
(5)連接c.baidu.com,服務(wù)器返回1個主機(jī)地址(4342行)
終端向第1個主機(jī)地址發(fā)送3次TCP握手請求,主機(jī)均有響應(yīng),但終端未收到
(6)連接www.sina.com.cn,服務(wù)器返回1個主機(jī)地址(5250行)
終端和主機(jī)成功進(jìn)行TCP的3次握手,并成功下載該主機(jī)的HTTP協(xié)議數(shù)據(jù)包后續(xù)該網(wǎng)址下的鏈接都成功打開
(7)連接cn.msn.com,服務(wù)器返回1個主機(jī)地址(11398行)
作了數(shù)次ping操作并能ping通
(8)整個Log跟蹤過程中,終端一直成功進(jìn)行FTP下載(連接移動內(nèi)部FTP服務(wù)器)
<8130終端第二次跟蹤>
(1)連接www.163.com,服務(wù)器返回10個主機(jī)地址(747行)
作了數(shù)次ping操作,主機(jī)均有響應(yīng),但終端未收到
(2)連接www.baidu.com,服務(wù)器返回2個主機(jī)地址(2335行)
作了數(shù)次ping操作,主機(jī)均有響應(yīng),但終端未收到
(3)連接www.sohu.com,服務(wù)器返回2個主機(jī)地址(3483行)
作了數(shù)次ping操作并能ping通
(4)連接www.qq.com,服務(wù)器返回2個主機(jī)地址(4383行)
作了數(shù)次ping操作,主機(jī)無響應(yīng)
(5)連接cn.msn.com,服務(wù)器返回1個主機(jī)地址(5322行)
作了數(shù)次ping操作并能ping通
(6)整個Log跟蹤過程中,終端一直成功進(jìn)行FTP下載(連接移動內(nèi)部FTP服務(wù)器)
通過以上Log,基本可排除空口質(zhì)量的影響,因為雖然FTP過程能看到一定比例的丟包,但打開網(wǎng)頁操作中,每次的DNS域名解析交互過程都是完整的,未打開網(wǎng)頁的,都是TCP握手過程不完整;或者ping不通網(wǎng)址的,都是主機(jī)的ICMP響應(yīng)終端側(cè)沒有跟蹤到.若是空口丟包,不太可能每次都剛好在TCP協(xié)商過程中丟包
另外鑒于Log的全過程中都有持續(xù)的FTP協(xié)議數(shù)據(jù)包,RAN丟包的可能性也不大,因為所有IP包是統(tǒng)一在RLC對等層封裝為PDU的,RAN設(shè)備無法區(qū)分該IP包來自哪種應(yīng)用協(xié)議,也不會做有區(qū)別的處理
網(wǎng)絡(luò)結(jié)構(gòu)中各節(jié)點連接關(guān)系為：
UE－空口－Node B－（Iub）－RNC－（Iu）－SGSN－（Gn）－GGSN－（Gi）－防火墻－移動服務(wù)器（APN）－Internet
從Gi口跟蹤可以看到服務(wù)器對終端的請求都進(jìn)行了響應(yīng)，且Gi口跟蹤位置在GGSN和防火墻之間，可以排除防火墻丟包的可能性
另外經(jīng)對比Iub口用戶面的TDPA跟蹤，以及基站內(nèi)部跟蹤，未發(fā)現(xiàn)Iub口存在丟包。
這樣問題可縮小為：在RNC－SGSN－GGSN的下行傳輸過程中存在丟包，鑒于丟包現(xiàn)象出現(xiàn)的規(guī)律性，且RNC內(nèi)部對來自不同應(yīng)用協(xié)議的IP包不作區(qū)分，重點嫌疑在核心網(wǎng)側(cè)，即SGSN或GGSN可能存在丟包。
6月11日，鑒于浦西的RNC連接的核心網(wǎng)設(shè)備無法跟蹤Gn口，在浦東的RNC下進(jìn)一步進(jìn)行定位，同時在RNC內(nèi)部進(jìn)行QoS級的UE跟蹤，用TDPA跟蹤Iu口用戶面消息，CN內(nèi)部同時跟蹤Gn和Gi口。當(dāng)晚測試結(jié)果如下：
<21:00~22:00>
| 終端IP地址
| 網(wǎng)易
| 百度
| 新浪
| 騰訊
| 搜狐
| FTP
| 華為ET128
| 10.80.49.96
| 失敗
| 失敗
| OK
| OK
| OK
| OK
| 中興MU350
| 10.80.54.75
| 失敗
| 失敗
| OK
| 失敗
| OK
| OK
| 聯(lián)芯8130
| 10.80.57.198
| 失敗
| 失敗
| OK
| OK
| OK
| OK
| 聯(lián)芯5731E
| 10.80.59.222
| 失敗
| 失敗
| OK
| OK
| OK
| OK
|
<22:00~23:00>（Iu口掛上TDPA）
| 終端IP地址
| 網(wǎng)址
| FTP
| 華為ET128
| 10.80.184.185
| 連接所有網(wǎng)址成功
| OK
| 聯(lián)芯8130
| 10.80.3.90
| 連接所有網(wǎng)址失敗
| 失敗
| 聯(lián)芯8130（第二次撥號）
| 10.80.3.207
| 連接所有網(wǎng)址失敗
| 失敗
| 聯(lián)芯8130（第三次撥號）
| 10.80.185.156
| 連接所有網(wǎng)址成功
| OK
|
經(jīng)分析Gn口和Gi口Log，所有連接網(wǎng)頁失敗，都是終端發(fā)出的DNS域名解析請求，或TCP連接請求，在Gi口看到了服務(wù)器的響應(yīng)，但在Gn口沒有看到。所有連接FTP失敗，也是終端發(fā)出的FTP連接請求，在Gi口可以看到響應(yīng)，而在Gn口沒有看到。
也就是說，失敗的情況，都是由于服務(wù)器發(fā)給GGSN的響應(yīng)數(shù)據(jù)包，GGSN沒有發(fā)給SGSN導(dǎo)致。因此定位為ASB核心網(wǎng)GGSN設(shè)備的處理存在問題。
6月12日，和西安研發(fā)部遠(yuǎn)程支持同事就此結(jié)論做了確認(rèn)并知會ASB方面
6月13日，ASB方面反饋其更換了GGSN中的某個設(shè)備板卡，但尚未提供更詳細(xì)的信息。經(jīng)6月13日和6月14日2天在外場和室內(nèi)的驗證，全網(wǎng)大規(guī)模的上網(wǎng)后業(yè)務(wù)無流量問題已得到控制，6月14日的外場驗證結(jié)果如下：
浦東
RNC
| NodeB
| 384網(wǎng)頁打開情況
| 384 ftp下載情況
| H網(wǎng)頁打開情況
| H ftp下載情況
| 411（TDR3000）
| 陳行、江龍
| 打開速率較慢（10s）
| 240kbps左右
| 打開網(wǎng)頁快
| 平均速率1Mbps
| 406（TDR2000）
| 歸涇、西林村
| 打開網(wǎng)頁比較快
| 240kbps左右
| 打開網(wǎng)頁快
| 平均速率700～800kbps
|
注：H和R4測試2次，保持10分鐘，未出現(xiàn)打不開網(wǎng)頁，速率為0后回不來的現(xiàn)象
浦西
RNC
| NodeB
| 384網(wǎng)頁打開情況
| 384 ftp下載情況
| H網(wǎng)頁打開情況
| H ftp下載情況
| 397（TDR3000）
| 漕欽2
| 打開速率較慢
| ftp沒速率，能ping通，迅雷能下載，120kbps左右
| 打開速率較慢
| ftp沒速率，能ping通，迅雷能下載，960kbps
| 397（TDR3000）
| 二污2
| 打開速率較慢
| 40kbps左右
| 打開速率較慢
| ftp沒速率，能ping通，迅雷能下載，400kbps;多次嘗試后，ftp可以下載,400kpbs左右
| 390（TDR2000）
| 長世貿(mào)2
| 打開網(wǎng)頁比較快
| 700kbps左右
| 打開網(wǎng)頁比較快
| 700kbps左右
|
注：每個小區(qū)測試2次～5次，未出現(xiàn)打不開網(wǎng)頁，速率為0后回不來的現(xiàn)象
3.
問題跟進(jìn)（1）后續(xù)需要ASB進(jìn)一步提供定位和排障的更詳細(xì)信息，以便其他城市網(wǎng)絡(luò)參考和預(yù)防。
（2）6月14日4:00~18:00，在桂平路王安賓館室內(nèi)保持一個業(yè)務(wù)（RNC390下的室外小區(qū)信號）,中間沒有出現(xiàn)速率為0后不能恢復(fù)的問題，但發(fā)生過多次網(wǎng)頁打不開（同時FTP連接失敗）的情況,在1~2分鐘后都能恢復(fù)正常。 出現(xiàn)如上問題時,仍是DNS域名解析請求和FTP連接請求消息在終端側(cè)看不到響應(yīng)消息.，因此對核心網(wǎng)問題解決的效果需要持續(xù)觀察 （3）6月13日在室內(nèi)保持驗證過程中，還發(fā)現(xiàn)如下幾個其他問題，也建議持續(xù)關(guān)注： 業(yè)務(wù)保持1h左右時,可以正常打開網(wǎng)頁,但連接FTP服務(wù)器失敗,多次重新連接均失敗,從終端側(cè)wireshark抓包看是終端發(fā)出的FTP連接請求TCP消息沒有收到響應(yīng).但2min后FTP連接突然恢復(fù)正常.此現(xiàn)象的原因未知 曾發(fā)現(xiàn)中興數(shù)據(jù)卡MU350在業(yè)務(wù)保持過程中切換到2G網(wǎng)絡(luò)但未彈出提示窗口，此時PS業(yè)務(wù)會釋放，因此用戶投訴也有可能因為網(wǎng)絡(luò)覆蓋不足而切換至2G網(wǎng)絡(luò)導(dǎo)致 （4）前期驗證過程中，曾數(shù)次出現(xiàn)中興MU350數(shù)據(jù)卡HSDPA業(yè)務(wù)保持過程中，突然發(fā)生上行無線鏈路失敗導(dǎo)致速率降為0，重新?lián)芴�，或拔出終端重新連接PC并撥號后，網(wǎng)頁和FTP仍然連接不上；只有重起PC，再連接終端和撥號，業(yè)務(wù)才能恢復(fù)正常。這個現(xiàn)象在后期的定位過程中沒有復(fù)現(xiàn)，目前初步分析主要與終端有關(guān)。 （5）從6月4日聯(lián)芯在顧戴路測試的Log可以看出，切換到2G網(wǎng)絡(luò)時，CN去激活了PDP但沒有釋放RAB，此后終端再次切回TD網(wǎng)絡(luò)并再次請求激活PDP，CN下發(fā)的RAB指派消息中，RAB ID與之前未釋放的RAB相同，參數(shù)中除了GTP-TEI與之前不同外，其余參數(shù)不變，RNC對此指派消息返回失敗，原因為“非法的參數(shù)值”，導(dǎo)致終端重新發(fā)起的多次PDP激活請求均失敗，業(yè)務(wù)無法恢復(fù)。經(jīng)過和ASB討論，認(rèn)為CN的處理有問題，不應(yīng)該出現(xiàn)只釋放PDP上下文而不釋放RAB的異常情況。ASB表示要進(jìn)一步分析，此問題需要繼續(xù)關(guān)注。對于RNC來說，雖然CN的處理過程不正常，但這條RAB指派消息并不違反協(xié)議，RNC是可以返回成功，從而規(guī)避這種異常情況的，此問題需要RNC研發(fā)后續(xù)改進(jìn)。 4.
方法介紹此問題主要是通過析wireshark抓包數(shù)據(jù)，并結(jié)合網(wǎng)元的跟蹤信息進(jìn)行定位的，wireshark抓包的分析方法可參考西安研發(fā)部梁劍之前提供的《網(wǎng)頁刷新慢及下載速率低問題業(yè)務(wù)面定位方法總結(jié)》。在這里針對本次問題，對wireshark抓包數(shù)據(jù)的分析方法再做一點簡單的補充： 用wireshark抓包的界面如下圖所示（以打開網(wǎng)頁的正常過程為例，圖中終端PDP激活后分配的IP為192.168.1.111，服務(wù)器的IP為
218.206.176.4）： 首先終端側(cè)回向服務(wù)器發(fā)送欲打開網(wǎng)址的域名申請解析，服務(wù)器解析域名并返回若干個主機(jī)地址；此后瀏覽器一般會向其中第一個主機(jī)地址發(fā)起TCP請求消息，并交互3次，TCP消息中的標(biāo)志位分別為[SYN]，[SYN,ACK]和[ACK]，這個過程即常說的TCP三次握手。此后終端側(cè)發(fā)HTTP協(xié)議消息（GET）表示獲取到主機(jī)地址，此后就是通過TCP協(xié)議數(shù)據(jù)包下載網(wǎng)頁內(nèi)容，即圖中的[TCP Segment of a reassembled PDU]數(shù)據(jù)包。 同樣的，如果是連接FTP服務(wù)器，可以看到封裝FTP連接請求和響應(yīng)消息的TCP數(shù)據(jù)包，其中可以看到請求連接的FTP服務(wù)器地址，用戶名和密碼等信息；如果是對某個地址進(jìn)行ping操作，可以看到ICMP協(xié)議數(shù)據(jù)包（ping包）。 通過各檢測位置（比如終端側(cè)、CN內(nèi)各接口）檢查以上過程的完整性，可以初步判斷是否某個環(huán)節(jié)存在傳輸丟包問題。 本次問題是由聯(lián)芯投訴引發(fā)的，開始幾天處理時，因聯(lián)芯人員沒有提供詳細(xì)的問題描述，定位一直沒有找到準(zhǔn)確的方向，在后續(xù)去聯(lián)芯公司定位，以及聯(lián)芯測試人員來公司定位的過程中，通過進(jìn)一步交流，才了解了聯(lián)芯反饋問題的詳細(xì)信息。后續(xù)對此類問題的處理，開始時多花一些時間了解問題的詳情是很有必要的。 對于某一時間突然發(fā)生的，全網(wǎng)普遍出現(xiàn)的問題，一般都和網(wǎng)絡(luò)匯聚節(jié)點的網(wǎng)元如RNC、CN、業(yè)務(wù)平臺等有關(guān)�，F(xiàn)在此類網(wǎng)絡(luò)問題一般會從RNC日常操作和升版的影響性開始定位，但我們和ASB的溝通尚不夠暢通，核心網(wǎng)是否進(jìn)行過什么操作或版本升級我們一般無法得知，也無法就已解決的核心網(wǎng)問題形成有效的案例總結(jié)，也建議后續(xù)進(jìn)一步增強和ASB的信息溝通，比如核心網(wǎng)進(jìn)行某項操作或修改前，能將此活動的影響性事先知會我們。
掃碼關(guān)注5G通信官方公眾號,免費領(lǐng)取以下5G精品資料
1、回復(fù)“YD5GAI”免費領(lǐng)取《中國移動：5G網(wǎng)絡(luò)AI應(yīng)用典型場景技術(shù)解決方案白皮書》
2、回復(fù)“5G6G”免費領(lǐng)取《5G_6G毫米波測試技術(shù)白皮書-2022_03-21》
3、回復(fù)“YD6G”免費領(lǐng)取《中國移動：6G至簡無線接入網(wǎng)白皮書》
4、回復(fù)“LTBPS”免費領(lǐng)取《《中國聯(lián)通5G終端白皮書》》
5、回復(fù)“ZGDX”免費領(lǐng)取《中國電信5G NTN技術(shù)白皮書》
6、回復(fù)“TXSB”免費領(lǐng)取《通信設(shè)備安裝工程施工工藝圖解》
7、回復(fù)“YDSL”免費領(lǐng)取《中國移動算力并網(wǎng)白皮書》
8、回復(fù)“5GX3”免費領(lǐng)取《 R16 23501-g60 5G的系統(tǒng)架構(gòu)1》
| |
關(guān)注樓主