楊宇晨

福建省廈門市思明區(qū)筼筜街道蓮岳社區(qū)，福建廈門，361001

0 引言

隨著智能終端的普及化、功能的完善化，移動(dòng)互聯(lián)網(wǎng)迅猛發(fā)展，用戶對(duì)于移動(dòng)業(yè)務(wù)體驗(yàn)的要求越來(lái)越高。與此同時(shí)，移動(dòng)網(wǎng)絡(luò)結(jié)構(gòu)日趨復(fù)雜，網(wǎng)絡(luò)場(chǎng)景多樣化，影響用戶體驗(yàn)的因素越來(lái)越難以判斷。傳統(tǒng)的KPI指標(biāo)已經(jīng)不能反映出用戶業(yè)務(wù)過(guò)程的感知體驗(yàn)，如何快速定位網(wǎng)絡(luò)問題、提升用戶業(yè)務(wù)感知是當(dāng)前網(wǎng)絡(luò)優(yōu)化中面臨的一個(gè)難題。本文結(jié)合現(xiàn)網(wǎng)用戶感知問題，介紹了如何利用wicap、qxdm及基站TTI抓包等多種分析手段，快速定位LTE基站的不正常調(diào)度問題的根因，最后通過(guò)對(duì)無(wú)線側(cè)調(diào)度參數(shù)的優(yōu)化，使得用戶的業(yè)務(wù)感知得到大幅改善。

1 問題現(xiàn)象

某地市運(yùn)營(yíng)商自3月底開始，出現(xiàn)較多用戶投訴，內(nèi)容為“4G信號(hào)正常，但用戶打開網(wǎng)頁(yè)慢，加載圖片慢”，截至4月底共收到100多單相關(guān)的投訴單。

投訴終端中蘋果、安卓手機(jī)都有。投訴點(diǎn)所占用的基站狀態(tài)、KPI指標(biāo)正常，現(xiàn)場(chǎng)測(cè)試RSRP良好、SINR良好、FTP上傳下載速率正常，ping時(shí)延正常。但在打開淘寶網(wǎng)頁(yè)、刷微信朋友圈的時(shí)候，會(huì)頻繁出現(xiàn)加載等待時(shí)延過(guò)長(zhǎng)現(xiàn)象，尤其是微信語(yǔ)音上傳出現(xiàn)較為明顯的延遲和超時(shí)情況，嚴(yán)重影響用戶感知[1]。

2 問題分析

2.1 投訴小區(qū)KPI、KQI分析

選取投訴較為集中的JK中心-1進(jìn)行KPI，KQI分析發(fā)現(xiàn)，小區(qū)KPI及KQI均較為正常，三次握手及頁(yè)面響應(yīng)時(shí)延也在正常范圍內(nèi)。

2.2 投訴小區(qū)現(xiàn)場(chǎng)測(cè)試

現(xiàn)場(chǎng)優(yōu)化人員到投訴站點(diǎn)測(cè)試，現(xiàn)場(chǎng)覆蓋良好，RSRP為-65dbm、SINR在20以上，下載峰值速率111M，上傳峰值速率65M，但是終端發(fā)微信語(yǔ)音、連接淘寶APP等均有很大概率出現(xiàn)延遲現(xiàn)象，與用戶投訴現(xiàn)象一致。

2.3 手機(jī)抓包分析

通過(guò)手機(jī)用wicap以及高通工具qxdm同時(shí)進(jìn)行抓包分析。從wicap抓包看到手機(jī)TCP層從11∶26∶21.897開始到11∶26∶25.283這段時(shí)間里，手機(jī)應(yīng)用層連續(xù)發(fā)了8個(gè)1300byte的IP包以及一個(gè)932byte的IP包。

我們?cè)購(gòu)母咄üぞ遯xdm抓包打開PDCP層的消息看到從583-7號(hào)子楨到922-6號(hào)子楨這3.389秒（時(shí)間與圖1用wicap抓包的時(shí)間吻合）內(nèi)，PDCP層共發(fā)出了4個(gè)1300byte大小的IP包，以及一個(gè)932byte大小的IP包（見圖2）。

圖1 wicap 抓包

圖2 PDCP 層消息

也就是說(shuō)，從系統(tǒng)幀583-7到922-6這段時(shí)間內(nèi)，應(yīng)用層一共發(fā)了8個(gè)1300byte大小的IP包，而PDCP層只發(fā)出了4個(gè)，被PDCP層丟棄了4個(gè)。且PDCP層從發(fā)出第一個(gè)到發(fā)出第二個(gè)間隔了3.289秒。是什么原因造成了PDCP層發(fā)送這個(gè)IP包用了這么長(zhǎng)時(shí)間？我們繼續(xù)打開RLC層消息進(jìn)行分析（圖3）。

圖3 RLC 層消息

從圖3RLC層上行消息包看到來(lái)自PDCP層的字節(jié)，RLC層將其一共分成26個(gè)SDU進(jìn)行分段傳輸，直至904-7號(hào)子幀才將這個(gè)IP包傳完，歷時(shí)3.210秒，且每個(gè)pdu字節(jié)數(shù)都比較小，最大僅118個(gè)字節(jié)[2]。我們繼續(xù)打開MAC層消息查看eNodeB是怎么調(diào)度的（圖4）。

圖4 MAC 層消息

從圖4MAC層上行消息看到手機(jī)在583-7的BSR消息中請(qǐng)求調(diào)度字節(jié)數(shù)為2915字節(jié)，而enodeb給的授權(quán)字節(jié)數(shù)一直未能滿足手機(jī)需要發(fā)送的IP包的大小，因此RLC層不得不將消息包分成26個(gè)SDU進(jìn)行傳輸。且期間存在較長(zhǎng)時(shí)間不調(diào)度，導(dǎo)致第一個(gè)1300byte的IP包就發(fā)送了3.210秒，手機(jī)上看到的現(xiàn)象就是轉(zhuǎn)圈轉(zhuǎn)了3～4秒后才將消息發(fā)出。

3 手機(jī)抓包分析結(jié)論

從以上分析可以初步判斷，eNodeB的上行調(diào)度存在問題，即終端首次發(fā)送SR請(qǐng)求后，eNodeB對(duì)BSR調(diào)度字節(jié)數(shù)小，且存在較長(zhǎng)時(shí)間不連續(xù)調(diào)度，導(dǎo)致時(shí)延較大。而同時(shí)基站也存在較多無(wú)效調(diào)度，浪費(fèi)了大量的空口資源。

UE通過(guò)SR告訴eNodeB是否需要上行資源以便用于UL-SCH傳輸，但并不會(huì)告訴eNodeB有多少上行數(shù)據(jù)需要發(fā)送（而是通過(guò)BSR上報(bào)的），UE要求被調(diào)度的緩沖區(qū)狀態(tài)報(bào)告（BSR）置于控制信息單元，一個(gè)MAC PDU最多只能包含一個(gè)MAC BSR控制信息單元，并在共享信道上發(fā)送。

eNodeB收到SR后，給UE分配多少上行資源取決于eNodeB的實(shí)現(xiàn)，通常的做法是至少分配足夠大于UE發(fā)送BSR的資源，如果用不滿則用空的padding字節(jié)填充。上行數(shù)據(jù)的傳輸需要的資源是通過(guò)BSR來(lái)獲得[3]。

BSR攜帶的是個(gè)索引值，它與實(shí)際字節(jié)大小的對(duì)應(yīng)關(guān)系為：index=0表示某個(gè)邏輯信道組沒有數(shù)據(jù)需要發(fā)送，index=63表示某個(gè)邏輯信道組有超過(guò)150K字節(jié)的數(shù)據(jù)需要發(fā)送。當(dāng)UE有30個(gè)字節(jié)的數(shù)據(jù)需要發(fā)送時(shí)，只需要將BSR控制單元的值填為8。網(wǎng)絡(luò)側(cè)在解碼BSR信息后，發(fā)現(xiàn)BSR的值等于8，就知道UE側(cè)需要發(fā)送的數(shù)據(jù)量在26～31字節(jié)之間，為eNB給UE分配合適大小的資源提供了參考依據(jù)。

需要注意的是，這里并不意味著網(wǎng)側(cè)就會(huì)給UE分配26個(gè)字節(jié)或31個(gè)字節(jié)對(duì)應(yīng)的資源，UE也不能做類似的假定。因?yàn)榫W(wǎng)側(cè)在收到BSR后，有可能只會(huì)分配極少數(shù)量的資源，比如這個(gè)例子中，網(wǎng)側(cè)可能只會(huì)分配10個(gè)字節(jié)的資源給UE，而不是26個(gè)字節(jié)也不是31個(gè)字節(jié)，甚至很多時(shí)候，網(wǎng)側(cè)在收到BSR后，并不會(huì)給該UE分配任何的上行資源。網(wǎng)側(cè)如何給某個(gè)UE分配資源，是由設(shè)備廠家的算法決定的，UE不會(huì)也不應(yīng)該對(duì)資源申請(qǐng)的結(jié)果做特定大小的假設(shè)[4]。

4 問題解決

4.1 基站側(cè)TTI抓包分析

我們?cè)贏irscale站型收取問題小區(qū)的TTI trace，可以發(fā)現(xiàn)和手機(jī)側(cè)抓包相印證，調(diào)度不連續(xù)，且初始的調(diào)度MCS偏小，所以TBS小，調(diào)度的數(shù)據(jù)量也少。部分時(shí)段，基站存在不連續(xù)調(diào)度。

4.2 調(diào)度參數(shù)調(diào)整測(cè)試

至此，時(shí)延問題基本確認(rèn)為上行調(diào)度問題，我們對(duì)airscale基站的幾個(gè)調(diào)度參數(shù)進(jìn)行各種組合測(cè)試（圖5）。

圖5 優(yōu)化參數(shù)

（1）默認(rèn)參數(shù)下修改 iniMcsDl / iniMcsUl和iniPrbsUl 3個(gè)到優(yōu)化值，測(cè)試微信語(yǔ)音秒發(fā)，結(jié)果ok。

（2）默認(rèn)參數(shù)下只修改參數(shù) iniUlMcs到優(yōu)化值，測(cè)試故障現(xiàn)象依舊，結(jié)果nok。

（3）默認(rèn)參數(shù)下只修改 iniUlMcs和iniPrbsUl到優(yōu)化值，測(cè)試微信語(yǔ)音秒發(fā)，結(jié)果ok。

（4）默認(rèn)參數(shù)下只修改 iniPrbsUl到優(yōu)化值，測(cè)試微信語(yǔ)音秒發(fā)，結(jié)果ok。也驗(yàn)證了初始grant較小的問題。

（5）默認(rèn)參數(shù)下只將ulsFdPrbAssignAl修改成mixeFD，測(cè)試故障現(xiàn)象依舊，結(jié)果nok。

4.3 優(yōu)化實(shí)施

基于以上測(cè)試結(jié)論，與現(xiàn)網(wǎng)FSMF站型進(jìn)行參數(shù)對(duì)齊，從優(yōu)化的角度出發(fā)，建議將上述幾個(gè)參數(shù)優(yōu)化同時(shí)實(shí)施。對(duì)問題小區(qū)進(jìn)行參數(shù)優(yōu)化后，觀察修改后的Airscale小區(qū)，KPI、KQI正常，尤其是上行流量相當(dāng)?shù)那闆r下，上行PRB利用率下降、系統(tǒng)負(fù)荷降低，經(jīng)分析驗(yàn)證是因?yàn)樯闲姓{(diào)度正常后TCP重傳減少了。同時(shí)，優(yōu)化小區(qū)的三次握手時(shí)延下降顯著。

4.4 結(jié)論

該廠商airscale站型iniPrbUl（初始的上行最大PRB）設(shè)置為1時(shí)，會(huì)導(dǎo)致初始調(diào)度有上行調(diào)度不響應(yīng)的情況，因?yàn)樯闲谐跏蓟腜RB太小了，不滿足UE的BSR請(qǐng)求的數(shù)據(jù)包的大小，按照通常的調(diào)度機(jī)制應(yīng)該是eNodeB至少分配足夠大于UE發(fā)送BSR的資源。預(yù)調(diào)度的開啟有利于降低LTE系統(tǒng)時(shí)延，同時(shí)也會(huì)引起額外的RB資源消耗，建議在上行PRB利用率不高的情況下適度開啟。

5 結(jié)語(yǔ)

本文從用戶感知問題出發(fā)，創(chuàng)新應(yīng)用wicap、qxdm及基站TTI抓包分析，快速定位LTE基站調(diào)度存在的問題。通過(guò)對(duì)上行調(diào)度機(jī)制的研究，提出對(duì)上行調(diào)度參數(shù)優(yōu)化的方案。這種抽絲剝繭、分層分析的方法，在移動(dòng)通信用戶感知問題優(yōu)化中具有普適性和參考意義。