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