GSMBSS網(wǎng)絡性能PSKPI(RTT時延)優(yōu)化手冊

GSMBSSGSMBSSPSKPI〔RTT時延〕優(yōu)化手冊內(nèi)部公開第1頁第1頁,共15頁2008-11-1版權全部，侵權必究產(chǎn)品名稱產(chǎn)品名稱GSMBSS產(chǎn)品版本Productversion密級內(nèi)部公開共15頁GSMBSSPSKPI〔RTT時延〕優(yōu)化手冊(僅供內(nèi)部使用〕擬制:擬制:GSM&UMTS網(wǎng)絡性能研究部日期：審核:日期：審核:日期：批準:日期：華為技術版權全部侵權必究修訂記錄日期2008-12-20本1.0初稿完成修改描述作者耿海建2008-12-251.0依評審意見修改耿海建2009-7-301.0增加涉及特性楊召青目錄總體介紹 ..1.1 RTT定義..Ping過程分析 E)GPRS中時延簡介 2 RTT時延分析和優(yōu)化..\l“_TOC_250003“TBF的建立釋放時延優(yōu)化 1.2\l“_TOC_250002“數(shù)據(jù)傳送時延分析 .3\l“_TOC_250001“系統(tǒng)處理時延 .42.4 網(wǎng)元間傳輸時延4\l“_TOC_250000“3 附錄：測試跟蹤文件 4圖名目圖1Ping命令執(zhí)行結(jié)果 8.圖2Ping業(yè)務抓包 8.圖3Ping流程TBF建立釋放未優(yōu)化〕 .圖4GB接口跟蹤圖形 9.圖5GB接口跟蹤〔左，對應于圖4行序號24〕和Ethereal跟蹤〔右〕比照 10圖6Um口接入流程第一個UplinkACK消息中帶上TLLI進展沖突解決 10圖7Um口跟蹤其次次Ping數(shù)據(jù) .1圖8TEMS口跟蹤其次次Ping時，上行發(fā)送BSN=4,5，網(wǎng)絡側(cè)未收到的塊 11圖9Ping包在各協(xié)議層的組包圖 .3表名目表1EGPRS各種編碼RLC數(shù)據(jù)塊承載的LLC層數(shù)據(jù)量的大小 13表2GPRS各種編碼RLC數(shù)據(jù)塊承載的LLC層數(shù)據(jù)量的大小 13表3CQTPing測試結(jié)果 .4文檔摘要和縮略語關鍵詞：Ping，RTT時延摘要：PingRTTRTTPing業(yè)務的根本過程，然后基于這些描述說明RTT時延的優(yōu)化方法?？s略語清單：GPRS縮略語英文全名GeneralPacketRadioService中文解釋通用分組無線業(yè)務EGPRSEnhancedGPRS慢速隨路掌握信道MSMobileStation移動臺CQTCallQualityTest呼叫質(zhì)量測試DTDriveTest驅(qū)車測試RTTRoundTripTime來回時間ICMPInternetControlMessageProtocolInternet掌握消息協(xié)議PCUPacketControlUnit分組掌握單元BSSBaseStationSystem基站系統(tǒng)BSCBaseStationControl基站掌握器BTSBaseTransceiverStation基站收發(fā)信臺TBFTemporaryBlockFlow臨時塊流RLCRadioLinkControl無線鏈路掌握MACMediaAccessControl媒體接入掌握MCSModulationandCodingScheme調(diào)制編碼方案參考資料《TCP/IP1：協(xié)議》，W.RichardStevens，2008-4《GPRS2005-6-1《GSMPS〔試驗室外場版〕》，GSM2008-9-3GSMBSSGSMBSSPSKPI〔RTT時延〕優(yōu)化手冊內(nèi)部公開GSMBSSPSKPI〔RTT時延〕優(yōu)化手冊總體介紹本文對RTTGPRS系統(tǒng)中引入RTT每個點如何優(yōu)化作了說明。本文說明定位問題的工具主要是TEMS，Ethereal/Wireshark，各網(wǎng)元的消息跟蹤和掃瞄工具。分析RTT時延問題，需要TEMS的跟蹤信令，Ethereal/Wireshark手機側(cè)抓包數(shù)據(jù)，BSSPSUm口跟蹤信令，BSSPSGBPTP跟蹤信令。本文基于下載上傳存在的問題都解決的根底上。即不存在信道故障，鏈路失步，接口丟包等問題。RTT定義RTT時延是指從數(shù)據(jù)包發(fā)送到接收到回應的時間RTT么要考核RTT時延這個指標？RTT時延越大，應用層的數(shù)據(jù)確認需要的時間較長，從而在慢啟動階段，窗口翻開慢，到達擁RTT時延較大時的帶寬利用率就較低。Ping過程分析2008-11-1共15頁一般承受Ping命令來測試RTT時延，Ping業(yè)務基于ICMPICMP回顯懇求包至效勞器，效勞器收到該懇求包后，將其中的數(shù)據(jù)段原封不動的封裝在ICMP回顯應答包中，發(fā)送給終端。2008-11-1共15頁GSMBSSGSMBSSPSKPI〔RTT時延〕優(yōu)化手冊內(nèi)部公開第10頁第10頁,共15頁2008-11-1版權全部，侵權必究圖1Ping命令執(zhí)行結(jié)果Ping命令中，-n表示Ping的次數(shù)，-l表示PingPingPing包的RTT時延，在Ping命令執(zhí)行完畢后，會顯示Ping的最小/最大/平均時延，在Windows操作1ms。1測試中，通過WireShark跟蹤的結(jié)果如以下圖所示：圖2Ping業(yè)務抓包在Windows操作系統(tǒng)缺省設置下，屢次Ping懇求發(fā)送的時間間隔為1S〔圖中顯示的時間為與上一個包的間隔時間〕，Ping回顯大于1s的狀況，一等到Ping回顯，則馬上發(fā)送下一個Ping5S沒有收到相應的回顯應答包Requesttimeout，說明對方不行達〔對方不肯定真的不行達，有可能是對方的網(wǎng)絡防火墻阻擋Ping入〕。E)GPRS中時延簡介E)GPRS系統(tǒng)中的時延TBF取決于系統(tǒng)的硬件處理力量；網(wǎng)元間傳送時延和接口傳輸模式相關；數(shù)據(jù)傳送時延和Ping包的大小以及使用的相應編碼有關系；TBF建立釋放時延則受承受的接入方法〔一步接入或兩步接入〕以及受網(wǎng)絡側(cè)相應的TBF建立或釋放的優(yōu)化手段的影響。RTT時延分析和優(yōu)化以下圖表示了任何功能都不翻開狀況下一個Ping包的傳遞過程：客戶端 MS

PCU

效勞器ICMP回顯懇求上行TBF建立懇求ICMP回顯懇求上行TBF建立懇求指配上行資源承載ICMP回顯懇求的RLC數(shù)據(jù)塊RTT時延ICMP回顯懇求ICMP回顯應答指配下行資源確定指配成功承載ICMP回顯懇求的RLC數(shù)據(jù)塊ICMP回顯應答

層

層

網(wǎng)絡層圖3Ping流程〔TBF建立釋放未優(yōu)化〕TBF戶端的組包等過程。對于Ping時延的分析，按以下思路分析：核心網(wǎng)是否引入時延〔GB跟蹤數(shù)據(jù)〕，假設有，聯(lián)系核心網(wǎng)工程師解決，否則，下一步。推斷首Ping時延長還是連續(xù)Ping時延長假設僅僅是首Ping時延長，考察TBF建立流程是否特別假設是連續(xù)Ping過程中時延都比較長，考察TBF建立/釋放優(yōu)化流程是否啟動，參數(shù)設置是否合理；考察是否由于數(shù)傳過程的問題導致延遲釋放時間超時。假設是連續(xù)Ping過程中局部Ping過程時延較長，考察數(shù)據(jù)傳送過程，如編碼、信道數(shù)、誤塊等狀況。圖4GB接口跟蹤圖形我們以圖1中所做的Ping圖4GB接口跟蹤圖形首Ping時延為767ms，較一般首Ping過程要長一些，從信令可以看到，沒有啟動下行提前建〔下行提前建立應在發(fā)送第一個UplinkACKUplinkACK時發(fā)送下行指配〕；上行一個信道以及上下行編碼都比較低〔這在對其次次Ping過程中分析〕。連續(xù)Ping過程有幾個Ping1其次次PingGB接口數(shù)據(jù)對應到該次Ping過程，可以從以下圖來確定這兩個數(shù)據(jù)塊對應于其次次Ping。圖5GB接口跟蹤〔424〕Ethereal圖5GB接口跟蹤〔424〕Ethereal跟蹤〔右〕比照圖6UmUplinkACKTLLI進展沖突解決TFI為10。然后找到下一個下行指配，可以看到以上行TFI10MSMSTFI13GB接口對應的時間找到相應的數(shù)據(jù)塊在Um〔GB接口整個LLCPDU內(nèi)容和UmRLC塊數(shù)據(jù)內(nèi)容可以準確確定〕。如以下圖所示：圖7UmPing數(shù)據(jù)/BSN號為4、5的第一次發(fā)送網(wǎng)絡側(cè)沒有收到。上行編碼較低是由于默認編碼是MCS2，后續(xù)沒有準時調(diào)整〔配置為依下行來調(diào)上行，明顯，沒有調(diào)整是下行沒有調(diào)整的緣由〕；下行編碼默認配置為MCS6編碼，卻使用MCS2編碼，明顯是由于副鏈路不能綁定的緣由；上行僅使用一個信道是由于一階段接入，未到觸發(fā)時機安排成上行兩時隙；上行數(shù)據(jù)塊BSC號為4、5網(wǎng)絡側(cè)沒有收到，查看空口質(zhì)量是比較好的，則很大的可能是Gabis口鏈路和信道的問題；即使丟兩個塊也不會導致這么長的時延，由于MS處于延遲釋放狀態(tài)，無其它復用應是持續(xù)調(diào)TEMS〔ModeReport－PHPDCHBlockHeaderDLReport〕：圖8TEMSPingBSN=4,5，網(wǎng)絡側(cè)未收到的塊覺察有大量的下行塊手機側(cè)沒有收到，則很可能是由于傳輸鏈路的緣由導致。全部的分析都指向鏈路質(zhì)量的問題，這時，查看有無鏈路失步的告警；BTS是否鎖定BSC的時鐘；查看Gabis口誤碼率話統(tǒng)。由于試驗室環(huán)境，我們僅確認BTS的時鐘處于自由振蕩狀態(tài)。附件是相應的Ping跟蹤文件和配置數(shù)據(jù)，可以依照這次分析結(jié)果試著分析第四次時延長的狀況。TBF的建立釋放時延優(yōu)化上行TBF建立時延優(yōu)化上行TBF或許是193ms；對于兩階段接入，從信道懇求到指配上行資源或許是452ms。接入方式是手機打算的，網(wǎng)絡側(cè)可以限定其必需承受兩階段接入，明顯，我們不應作這種限定。要查看該開關是否翻開〔進入超級用戶模式，查看“配置BSC屬性－內(nèi)部軟參－強制手機二階段接入功能開關”應設置為“不強制〕。兩階段接入中，消耗時間最多的地方是指配單塊－>手機在單塊上上兩步接入懇求的過程，通過修改“單塊指配下的延遲塊數(shù)”〔進入超級用戶模式，查看“配置BSC屬性－內(nèi)部軟參－單塊指配下的延遲塊數(shù)”〕9660ms左右。 說明單塊指配的延遲塊數(shù)主要是考慮馬上指配消息從PCU發(fā)送至MS的時延，包括傳輸時延以及指配消息在基站側(cè)可能要排隊帶來的時延。在試驗室驗證“單塊指配下的延遲塊數(shù)”為6時沒有問題，但在現(xiàn)網(wǎng)，假設尋呼量和接入懇求量很大，有可能造成手機收到指配消息時，所指配的塊的時間已經(jīng)過了，從而重發(fā)信道懇求的狀況。所以，建議僅用于RTT時延比拼。上行TBF釋放時延優(yōu)化上行數(shù)據(jù)塊發(fā)送完畢以后，就可以進入上行釋放流程。但上行釋放后，建立下行時間較長。同時，對于連續(xù)Ping時，每一次Ping業(yè)務都要重建立上行，會消耗過多的時長，所以，一般我們會延遲上行的釋放。一般翻開上行擴展功能，將“配置小區(qū)屬性－GPRS屬性－Ps域網(wǎng)絡優(yōu)化－上行擴展TBF非活動期時長〔毫秒〕”設置為一個合理的值，建議設置為2000ms。 說明上行擴展功能需要MS支持。由于Ping1S，所以“上行擴展TBF非活動期時長〔毫秒〕”需要設置大于1S。下行TBF建立時延優(yōu)化正常的流程是有下行數(shù)據(jù)到達PCUPS行，且正常也都會有下行數(shù)據(jù)。所以，產(chǎn)品實現(xiàn)了“下行提前建立”的功能〔進入超級用戶模式，“配置BSC屬性－內(nèi)部軟參－下行TBF提前建立開關”設置為“對全部TLLI翻開優(yōu)化”〕。即在上行TBF建立以后，即馬上觸發(fā)下行建立。下行TBF釋放時延優(yōu)化下行TBF也需要啟動延遲釋放來實現(xiàn)連續(xù)Ping過程不反復建立下行。在“配置小區(qū)屬性－GPRS屬性－Ps域網(wǎng)絡優(yōu)化－下行TBF延時釋放時長〔毫秒〕”設置為大于1000ms的值。建議2400ms。數(shù)據(jù)傳送時延分析每次Ping32字節(jié)包在各協(xié)議層的組包狀況如以下圖所示：Ping包數(shù)據(jù)32字節(jié)ICMP包頭8字節(jié)Ping包數(shù)據(jù)32字節(jié)Ping包數(shù)據(jù)32字節(jié)ICMP包頭8字節(jié)Ping包數(shù)據(jù)32字節(jié)包頭字節(jié)ICMP包頭8字節(jié)Ping包數(shù)據(jù)32字節(jié)SNDCP頭4字節(jié)包頭字節(jié)ICMP包頭8字節(jié)Ping包數(shù)據(jù)32字節(jié)SNDCP頭3字節(jié)LLC頭SNDCP頭IP包頭ICMP包頭Ping包數(shù)據(jù)SNDCP頭LLC頭3字節(jié)4字節(jié)20字節(jié)8字節(jié)32字節(jié)3字節(jié)3字節(jié)IPSNDCPLLC圖9Ping包在各協(xié)議層的組包圖Ping32字節(jié)包時，每個PingRLC73字節(jié)。各種編碼的RLC數(shù)據(jù)塊大小如下表所示：表1EGPRSRLCLLC層數(shù)據(jù)量的大小ChannelCodingSchemeEGPRSRLCdataunitsize(N2)(octets)FamilyMCS-122CMCS-228BMCS-337AMCS-444CMCS-556BMCS-674AMCS-72x56BMCS-82x68AMCS-92x74A表2GPRSRLCLLC層數(shù)據(jù)量的大小ChannelCodingSchemeRLCdatablocksizewithoutsparebits(N2)(octets)NumberofsparebitsRLCdatasize(octets)CS-122022CS-2327327/8CS-3383383/8CS-4527527/8從表中可以看出，對于上行單信道的狀況，需要MCS6編碼才可以在20ms內(nèi)將一個Ping數(shù)PingMCS6GPRS的狀況，則需要兩個信道，CS3/4的編碼才可以在20ms內(nèi)發(fā)送一個Ping包。所以，對于初始發(fā)起Ping10的MS，會安排3〔下行〕+2〔上行〕Ping〔進入超級用戶模式，“配置BSC屬性－內(nèi)部軟參－DSP掌握開關表2”共八位，第一位即為時隙快速調(diào)整開關〕。對于存在誤塊的狀況，可能會導致Ping時延突增，由于發(fā)送的數(shù)據(jù)塊假設對端沒有賜予確認，且不支持的未確認數(shù)據(jù)塊重發(fā)的狀況下，會等待對方確認再進展重傳而鋪張很長的時間。所以，網(wǎng)絡側(cè)也開發(fā)出了“PACK重傳”的功能，對于存在誤塊〔主要是DTPing測試中〕的狀況，要確認一下現(xiàn)有版本是否支持該功能。系統(tǒng)處理時延基站不同硬件版本的處理時延不同，對于BTS3012的老雙密度會有40ms的差異。另外，不同的終端，時延也會有所差異，N95下時延性能要比索愛K790好40ms左右。網(wǎng)元間傳輸時延網(wǎng)元間傳輸時延和網(wǎng)元間傳輸模式有關，主要是Gabis口的傳輸方式〔TDM/HDLC/IP〕，對于不同傳輸模式下，翻開上行擴展和下行延遲釋放功