lesson7td-hsupa組網(wǎng)、測(cè)試及案例分析

HSUPA組網(wǎng)、測(cè)試

及案例分析目錄HSUPA 基本原理介紹HSUPA組網(wǎng)方案HSUPA測(cè)試及分析指導(dǎo)HSUPA案例分析HSUPA的數(shù)傳流程UE通過ERUCCH/SI發(fā)送“調(diào)度請(qǐng)求”，攜帶上行緩存數(shù)據(jù)量和信道質(zhì)量關(guān)鍵信息，連續(xù)調(diào)度“調(diào)度信息”在上行數(shù)據(jù)包中攜帶；不連續(xù)調(diào)度，“調(diào)度信息”通過ERUCCH隨機(jī)接入過程上報(bào)。網(wǎng)絡(luò)側(cè)根據(jù)“調(diào)度請(qǐng)求”中的關(guān)鍵信息，選擇調(diào)度的用戶，通過EAGCH信道授權(quán)；UE通過EPUCH信道發(fā)送上行數(shù)據(jù)；網(wǎng)絡(luò)側(cè)通過EHICH信道發(fā)送ACK/NACK信息；另外，UE新建業(yè)務(wù)、觸發(fā)小區(qū)間切換后，以及出現(xiàn)不連續(xù)調(diào)度，都要通過ERUCCH的隨機(jī)接入過程上報(bào)“調(diào)度信息”，隨機(jī)接入具體流程如下：UE通過SYNCUL進(jìn)行上行同步；網(wǎng)絡(luò)側(cè)通過FPACH反饋響應(yīng)信息；UE通過通過ERUCCH進(jìn)行隨機(jī)接入，如果UE發(fā)送了ERUCCH，且網(wǎng)絡(luò)側(cè)進(jìn)行了EAGCH授權(quán)，則進(jìn)入正常的調(diào)度流程；HSUPAUTRAN側(cè)協(xié)議棧介紹對(duì)于每個(gè)使用E-DCH的UE，每個(gè)NodeB配置一個(gè)MAC-e實(shí)體，每個(gè)SRNC配置一個(gè)MAC-es實(shí)體。NodeB中的MAC-e控制E-DCH接入并連接到位于SRNC的MAC-es，并進(jìn)一步連接到MAC-d。UTRAN側(cè)的MAC層結(jié)構(gòu)HSUPAUTRAN側(cè)協(xié)議棧介紹NodeB中針對(duì)每個(gè)UE配置一個(gè)MAC-e實(shí)體，并且配置一個(gè)E-DCH調(diào)度器。MAC-e實(shí)體和E-DCH調(diào)度器處理NodeB中與HSUPA相關(guān)的功能。MAC-e實(shí)體和E-DCH調(diào)度器包含以下實(shí)體：UTRAN側(cè)MAC-e實(shí)體E-DCH調(diào)度模塊管理UE之間的E-DCH小區(qū)資源?；谡{(diào)度請(qǐng)求NodeB決定并發(fā)送調(diào)度授權(quán)。如何調(diào)度用戶取決于網(wǎng)絡(luò)側(cè)的調(diào)度策略；E-DCH控制實(shí)體負(fù)責(zé)接收調(diào)度請(qǐng)求并發(fā)送調(diào)度授權(quán)；MAC-ePDU解復(fù)用實(shí)體，負(fù)責(zé)解復(fù)用MAC-ePDU，并將其轉(zhuǎn)發(fā)給相關(guān)的MAC-dflow；HARQ實(shí)體支持多個(gè)HARQprocess的停等HARQ協(xié)議。每個(gè)HARQprocess負(fù)責(zé)產(chǎn)生指示E-DCH傳輸遞交狀態(tài)的ACK或NACK。該實(shí)體負(fù)責(zé)處理HARQ協(xié)議要求的所有任務(wù)。HSUPA新增信道介紹HSUPA新增信道主要包括以下幾種類型：1條傳輸信道E-DCHE-DCH（EnhancedDedicatedChannel）是新增的傳輸信道，該信道用于承載上行業(yè)務(wù)，映射到物理信道E-PUCH。2條下行物理信道：E-HICH、E-AGCHE-HICH（E-DCHHybridARQAcknowledgementIndicatorChannel）用來承載一個(gè)或者多個(gè)用戶的ACK/NACK，是下行信道。調(diào)度和非調(diào)度的ACK/NACK比特需要在不同的E-HICH上發(fā)送。E-AGCH（E-DCHAbsoluteGrantChannels）是共享下行信道，用于承載授權(quán)AG（AbsoluteGrant）信息。3條上行物理信道：E-PUCH、ERUCCH/E-UCCHE-PUCH（E-DCHPhysicalUplinkChannel）是用于承載E-DCH類型物理信道，用于傳輸上行業(yè)務(wù)數(shù)據(jù)，是上行信道，包括調(diào)度資源和非調(diào)度資源。E-RUCCH（E-DCHRandomAccessUplinkControlChannel）是用于HSUPA的隨機(jī)接入信道，是上行信道，該信道要映射到PRACH上。當(dāng)UE從空閑態(tài)進(jìn)入業(yè)務(wù)態(tài)或者進(jìn)行重配置后，如果有數(shù)據(jù)要發(fā)送，通過該信道向UE發(fā)送調(diào)度信息。E-UCCH（E-DCHUplinkControlChannel）載有與E-DCH相關(guān)的上行控制信息，是上行控制信道，映射在E-PUCH上。目錄HSUPA 基本原理介紹HSUPA組網(wǎng)方案HSUPA測(cè)試及分析指導(dǎo)HSUPA案例分析現(xiàn)有網(wǎng)絡(luò)引入HSPA后的組網(wǎng)策略(1)在2011及未來幾年內(nèi)，TDS網(wǎng)絡(luò)將出現(xiàn)既有僅支持A頻段的網(wǎng)絡(luò)，也有支持A+F頻段的網(wǎng)絡(luò)，還有僅支持A頻段和支持A+F頻段混合存在的網(wǎng)絡(luò)。從頻段分配的角度，對(duì)于支持A+F頻段的網(wǎng)絡(luò)，建議不論室外還是室內(nèi)小區(qū)新增的HSPA載波都由F頻段承載，而對(duì)于僅支持A頻段的網(wǎng)絡(luò)，建議根據(jù)話務(wù)統(tǒng)計(jì)，則需要根據(jù)實(shí)際網(wǎng)絡(luò)狀況，選擇話務(wù)負(fù)荷低的R4或者HSDPA載波，配置成HSPA載波，盡量降低對(duì)原有網(wǎng)絡(luò)的影響?？傮w網(wǎng)絡(luò)現(xiàn)狀：網(wǎng)絡(luò)中的載波類型：R4、HSDPA、HSPAHSPA載波推薦配置：現(xiàn)有網(wǎng)絡(luò)引入HSPA后的組網(wǎng)策略(2)一期網(wǎng)絡(luò)：多為S333站型，每小區(qū)2個(gè)R4、1個(gè)HSDPA載波，HSDPA載波全同頻組網(wǎng)。僅支持A頻段網(wǎng)絡(luò)引入HSPA的組網(wǎng)策略：二期網(wǎng)絡(luò)：多為S333站型，每小區(qū)1個(gè)R4、2個(gè)HSDPA載波，HSDPA載波采用全同頻或者2*3頻率復(fù)用方式組網(wǎng)。首選首選現(xiàn)有網(wǎng)絡(luò)引入HSPA后的組網(wǎng)策略(3)三期網(wǎng)絡(luò)：多為S444站型，每小區(qū)2個(gè)R4、2個(gè)HSDPA載波，HSDPA載波采用全同頻或者2*3頻率復(fù)用方式組網(wǎng)。首選現(xiàn)有網(wǎng)絡(luò)引入HSPA后的組網(wǎng)策略(4)支持A+F頻段網(wǎng)絡(luò)引入HSUPA的組網(wǎng)策略不論是單A頻段組網(wǎng)，還是A+F頻段組網(wǎng)，或是既有單A又有A+F頻段的網(wǎng)絡(luò)，都不可避免的出現(xiàn)HSPA全同頻組網(wǎng)或是HSPA與HSDPA混合同頻組網(wǎng)的網(wǎng)絡(luò)形態(tài)！目錄HSUPA 基本原理介紹HSUPA組網(wǎng)方案HSUPA測(cè)試及分析指導(dǎo)HSUPA案例分析HSUPA功能測(cè)試及指導(dǎo)測(cè)試終端設(shè)置(LC8142)建議硬件版本：8142V軟件版本：高于8142V1.20.00協(xié)議版本號(hào)設(shè)置為R7，只有在設(shè)置為R7版本下才能保證支持HSUPA功能。注意事項(xiàng)：聯(lián)芯測(cè)試終端已發(fā)布8142V1.20.00版本，但是該版本整體的穩(wěn)定性較差，移動(dòng)時(shí)極易出現(xiàn)cellupdatte，不建議測(cè)試使用。（目前有聯(lián)芯的內(nèi)部版本LC83_T4_US_T50620，該版本解決了SNPL上報(bào)問題、低碼率功率不受控等問題，或者測(cè)試前去聯(lián)芯網(wǎng)站下載最新8142軟件版本。）HSUPA載波資源配置建議增加純HSUPA載波在小區(qū)中增加載波，在該載波上行配置HSUPA資源，下行為R4DCH，載波僅被激活為HSUPA，ACTHSUPATCARRIER，實(shí)際現(xiàn)網(wǎng)中不會(huì)存在“純HSUPA載波”。HSDPA載波升級(jí)為HSPA載波/增加HSPA載波將HSDPA載波升級(jí)為HSPA，或者增加HSPA載波，即上行配置HSUPA，下行為HSDPA，載波被激活為HSPA如下：ACTHSUPATCARRIER，ACTHSDPATCARRIER。此稱之為HSPA載波。HSUPA功能測(cè)試及指導(dǎo)RNC側(cè)速率門限說明RNC側(cè)速率門限UE設(shè)置建議小區(qū)中的HSUPA資源配置方式為”HSPA載波”，設(shè)置AT命令字采用如下方式：AT+CGDCONT=1,"IP","CMNET",,,;+CGEQREQ=1,2,2048,2048,,,0,,,,,(申請(qǐng)上行速率大于等于ULBETRAFFTHSONHSUPA)&(申請(qǐng)下行速率大于等于DLBETRAFFTHSONHSDPA)，此時(shí)用戶才會(huì)承載在”HSPA載波”上。注：HSPA載波設(shè)置AT命令，必須上下行都設(shè)置，若不設(shè)下行，可能導(dǎo)致下行為默認(rèn)值，低于DLBETRAFFTHSONHSDPA門限，用戶無法接入HSPA載波，也無法接入HSDPA載波。HSUPA功能測(cè)試及指導(dǎo)測(cè)試結(jié)果參考

1、通過RBsetup消息中的E-RNTI來判斷用戶是否承載在HSUPA上2、HSPA載波上進(jìn)行CQT單下載測(cè)試，下行速率可以接近1.5Mbps3、HSPA載波上進(jìn)行CQT單上傳測(cè)試，上行速率約為0.5Mbps4、HSPA載波CQT同時(shí)上傳下載測(cè)試，上/下行速率在0.5/1.5Mbps左右TPCWinLOG能夠更好更細(xì)致的分析HSUPA問題，補(bǔ)充普通跟蹤手段的不足。HSUPA常用LMT-BTPCWinLOG跟蹤指導(dǎo)TPC消息是NodeB網(wǎng)元內(nèi)部的即時(shí)消息，從LCR5.0版本開始，TPC消息的跟蹤功能由LMT-B來完成。具體跟蹤設(shè)置方式如下：1、配置服務(wù)器地址，使用MML命令SETTPCSERVER重新設(shè)置，如下圖

所示：“FTP服務(wù)器地址”就是RNC映射的BAM虛擬地址，設(shè)置好服務(wù)器地址后可以通過LSTTPCSERVER進(jìn)行查詢，確認(rèn)上傳服務(wù)器的正確。HSUPA常用LMT-BTPCWinLOG跟蹤指導(dǎo)2、基帶板TPCWinLOG跟蹤通過命令CLRTPC清理以前抓取過的TPCWin消息，將之前設(shè)置的標(biāo)志位等遺留信息全部清除；設(shè)置抓取消息的Testlevel(一般該步驟可略去，根據(jù)實(shí)際情況調(diào)整)“場(chǎng)景”參數(shù)需要根據(jù)問題現(xiàn)象或是研發(fā)人員的要求來選擇；LMT-B中給出的默認(rèn)場(chǎng)景，選擇該場(chǎng)景跟蹤的TpcWinlog會(huì)默認(rèn)記錄一些消息。如果需要單獨(dú)跟蹤一些消息，選擇“其它場(chǎng)景”時(shí)需要設(shè)置一些消息的Testlevel，TestLevel”參數(shù)值，這個(gè)可以從研發(fā)人員處獲取跟蹤TPC消息(STRTPCTRACE，)，跟蹤成功后有提示消息給出;!HSUPA跟蹤TPCWinLOG分析指導(dǎo)1、TPCWin的LOG需要TPCWin中的TOOL工具分析，LCR5.0/6.0上常用的TOOL主要有HS_Tool_LCR5.0/BerTool_LCR6.02.dllBer_Tools_LCR5.0_For_9C(2010-5-25)/BerTool_LCR6.0.dll說明：只需要選擇和當(dāng)前NB版本匹配的*.dll文件即可，不需要重新安裝TPCWIN工具。2、5.0/6.0版本TpcWin采集的是“base_*.trx”文件，在導(dǎo)入HSTool之前需要進(jìn)行解壓，解壓過程如下圖：解壓完后的LOG方可用TOOL工具進(jìn)行解析HSUPA跟蹤TPCWinLOG分析指導(dǎo)3、打開“LogToPlugin.exe”工具，導(dǎo)入解壓好的LOG，然后在“LogFile”中導(dǎo)入采集解壓后的log；在“LoadOpCode”中導(dǎo)入版本配套的xssopo_n_x_bic.h；在“LoadPlug-in”中輸入相同版本的.dll文件，該文件一般放置在TPCwin的安裝目錄:TD-TECH\tpcwin\PlugIn\，4、查閱HSUPA關(guān)鍵統(tǒng)計(jì)信息例如，在該界面上點(diǎn)擊HSUPA菜單欄查閱HSUPA關(guān)鍵統(tǒng)計(jì)信息HSTOOL和BERTOOL功能分析簡介HSUPATool主要是為驗(yàn)證HSUPA功能、以及解決HSUPA應(yīng)用過程中出現(xiàn)的問題，HSUPATool中主要有以下幾個(gè)部分：ScheduledInformationTable統(tǒng)計(jì)表格，該表格主要用來分析和定位HSUPA業(yè)務(wù)空口質(zhì)量相關(guān)問題，該統(tǒng)計(jì)表格中的統(tǒng)計(jì)字段主要有UE的授權(quán)功率，NACK值，ACK值，Pebase、snpl等信息；SchdulingFlagTable統(tǒng)計(jì)表格，該表格主要用來查閱各種原因下的UE調(diào)度次數(shù)；HSUPAScheduledUserDataRateTable統(tǒng)計(jì)表格，該表格用來統(tǒng)計(jì)一些速率信息；HSUPAcarrierdatarateTable用于定位單個(gè)載波下資源使用以及環(huán)境相關(guān)情況；注：其中前3項(xiàng)是分析和定位HSUPA問題經(jīng)常要關(guān)注的一些統(tǒng)計(jì)信息。HSTOOL和BERTOOL功能分析簡介SchduledInformationTable統(tǒng)計(jì)表格介紹Reportsfn:本條記錄的子幀號(hào)，范圍0－8191,每200子幀(1s)統(tǒng)計(jì)一次；ACKNum:1s內(nèi)NodeB成功解碼的Mac-epdu總數(shù)；NACKNum:1s內(nèi)NodeB解碼失敗的Mac-ePDU總數(shù)，此項(xiàng)越大表明空口的質(zhì)量越差，速率越低；DiscardNum:1s內(nèi)NodeB達(dá)到最大重傳次數(shù)后仍未成功解碼，丟棄的mac-epdu的總數(shù)。此項(xiàng)越大表明空口的質(zhì)量越差，此時(shí)可以檢查功率配置和功控相關(guān)參數(shù)是否合理；AverUPH:1s內(nèi)統(tǒng)計(jì)UE上報(bào)的功率余量的平均值，在上行數(shù)據(jù)量充足的情況下，該值越大，上行能夠得到的吞吐量就越高，UPH最大值為48；AverSNPL:1s內(nèi)服務(wù)小區(qū)與鄰區(qū)的路損的平均值，SNPL反映了UE在小區(qū)內(nèi)距離各基站的位置情況；SNPL最大值為26；AverEUCCHNum:1s內(nèi)使用占用E-UCCH信道的個(gè)數(shù)的平均值，該值一般為10，不需關(guān)注；Avergrantpower:1秒內(nèi)授權(quán)功率的平均值；注：上述測(cè)量量中，UPH、SNPL和AverGrantPower是要重點(diǎn)關(guān)注的統(tǒng)計(jì)量。HSTOOL和BERTOOL功能分析簡介SchduledFlagTable統(tǒng)計(jì)表格介紹NormalScheduling:

1s內(nèi)正常調(diào)度的次數(shù)；DataInsufficient:

1s內(nèi)UE側(cè)buffer數(shù)據(jù)不足的次數(shù)，這種情況下UE依舊會(huì)被調(diào)度，但會(huì)降低給UE分配調(diào)度資源；BadJDPerformance:每秒內(nèi)授權(quán)的功率不足以支持聯(lián)檢的次數(shù)。由于HSUPA上行不進(jìn)行碼分復(fù)用，該統(tǒng)計(jì)不需關(guān)注；TooBadC/I:每秒內(nèi)分配的授權(quán)功率不足以支持UCCH發(fā)送的次數(shù)，此情況下UE不被調(diào)度；TooSmallGrant:每秒內(nèi)分配的授權(quán)功率不足以發(fā)送一個(gè)mac-epdu的次數(shù)，這種情況下UE不被調(diào)度；RetransmitFailed:每秒內(nèi)不支持重傳的次數(shù)，但這種情況下UE依舊會(huì)被調(diào)度，只是不能支持重傳。上述統(tǒng)計(jì)量中NormalScheduling、DataInsufficient和RetransmitFailed可以重點(diǎn)關(guān)注。HSTOOL和BERTOOL功能分析簡介HSUPASchduledUserDataRateTable統(tǒng)計(jì)表格介紹air_data_rate:1s內(nèi)統(tǒng)計(jì)的實(shí)際空口速率，是收到的ACK的mac-epdu的速率；req_data_rate:

1s內(nèi)統(tǒng)計(jì)的UE請(qǐng)求速率；grant_data_rate:1s內(nèi)統(tǒng)計(jì)的NB授權(quán)的速率，該值是NodeB根據(jù)UE上報(bào)的UPH值和緩存區(qū)數(shù)據(jù)量的多少來確定的；grant_tb_size:1秒內(nèi)授權(quán)給UE發(fā)送的tb_size平均值，即在1秒內(nèi)授權(quán)給UE發(fā)送的總的bit數(shù)；air_tb_size:1秒內(nèi)UE實(shí)際發(fā)送的TBsize的平均值；aver_tebs:1秒內(nèi)UE上報(bào)的上行緩存Buffer的平均值，可表明上行數(shù)據(jù)量的多少；conges_ind_num:

1秒內(nèi)RNC指示擁塞的次數(shù)；aver_retrans_num:1秒內(nèi)平均重傳的次數(shù)；HSTOOL和BERTOOL功能分析簡介BERTOOL主要用作進(jìn)行HSUPA問題深入分析做輔助應(yīng)用，根據(jù)其測(cè)量量信息進(jìn)行問題輔助分析，如下圖：目錄HSUPA 基本原理介紹HSUPA組網(wǎng)方案HSUPA測(cè)試及分析指導(dǎo)HSUPA案例分析HSUPA案例分析-終端類UE不支持Upshifting問題背景：

部分HSUPA終端不支持輔載波Upshiting功能，如8142v1.11.04版本，導(dǎo)致該類終端一接入U(xiǎn)ppch起始位置不為0的小區(qū)，會(huì)出現(xiàn)無速率的現(xiàn)象。問題分析：對(duì)于HSUPA終端，在業(yè)務(wù)發(fā)起過程中會(huì)做2次隨機(jī)接入，第一次隨機(jī)接入，采用的是主載波配置的用于一般隨機(jī)接入的SYNC_UL。第二次當(dāng)HSUPA終端申請(qǐng)調(diào)度資源的隨機(jī)接入時(shí)，首先還是需要通過SYNC_UL發(fā)起上行同步。當(dāng)主載波配置HSUPA資源時(shí)，就使用用于HSUPA的那組SYNC_UL；當(dāng)輔載波配置HSUPA資源時(shí)，UE需要使用輔載波上配置的SYNC_UL發(fā)起上行同步。目前有的HSUPA終端將用于HSUPA調(diào)度資源申請(qǐng)的SYNC_UL的起始位置固定了，網(wǎng)絡(luò)側(cè)自然檢測(cè)不到UE發(fā)起的上行同步，導(dǎo)致UE無法申請(qǐng)到調(diào)度資源。表現(xiàn)為HSUPA終端能撥號(hào)激活，但是就是沒速率。規(guī)避措施若網(wǎng)絡(luò)側(cè)開啟的是靜態(tài)UpShifting功能，將HSPA載波的UpPCH起始位置配置的和主載波一致。但是如果終端不支持主載波配置靜態(tài)Upshifting那只能靠終端解決。HSUPA案例分析-終端類動(dòng)態(tài)UpShifting與HSPA功能兼容性問題問題背景：當(dāng)HSPA配置在輔載波，輔載波配置的UpPCHPosition不同于主載波當(dāng)前的UpPCHPoaition的時(shí)候就會(huì)出現(xiàn)SYNC_UL接入失敗，最終發(fā)起Cellupdate。問題分析：該問題為終端問題，HSPA終端只讀取主載波的UpPCH位置變更信息，輔載波與主載波的UpPCHPositon配置不一致，或者主載波開啟動(dòng)態(tài)UpShifting后，UpPCH位置不同就會(huì)導(dǎo)致問題產(chǎn)生。規(guī)避措施網(wǎng)絡(luò)側(cè)在開啟HSPA載波時(shí)關(guān)閉動(dòng)態(tài)UpShifting功能，同時(shí)將HSPA載波UpPCHPosition位置與主載波配置一致。(說明，如果終端存在上述問題，那么關(guān)閉動(dòng)態(tài)也沒用)。值得注意的是：該問題主要是終端不讀取HSPA載波的UpPCH位置信息，導(dǎo)致SYNC_UL接入失敗。關(guān)閉動(dòng)態(tài)UpShifting功能對(duì)先現(xiàn)場(chǎng)UpPCH干擾的抑制會(huì)帶來一定的風(fēng)險(xiǎn)，需要現(xiàn)場(chǎng)在UpPCHISCP高的小區(qū)手動(dòng)調(diào)整靜態(tài)UpPCHPosition，并將HSPA載波進(jìn)行統(tǒng)一配置。HSUPA案例分析-終端類UE不發(fā)送ERUCCH問題如果終端不發(fā)送ERUCCH，網(wǎng)絡(luò)側(cè)無法對(duì)用戶進(jìn)行調(diào)度，UE會(huì)一直沒有速率。只要存在不連續(xù)調(diào)度場(chǎng)景或者頻繁觸發(fā)切換，UE上行速率掉零現(xiàn)象嚴(yán)重，都有可能是UE沒有發(fā)送ERUCCH導(dǎo)致；通過NodeB側(cè)TPCWinLog顯示ERUCCH解碼錯(cuò)誤現(xiàn)象，通過“O_XXCH_TEST_MESSAGE”來看是否為ERUCCH沒有發(fā)送導(dǎo)致：消息中第一個(gè)word“CC000008”是ERUCCH的opcode，說明是ERUCCH的打?。幌⒅械谒膫€(gè)word如果是“00000001”代表ERUCCH消息解錯(cuò)；如果是“00000000”代表ERUCCH消息能夠正確解調(diào)；如果是終端不發(fā)送ERUCCH，那么“O_XXCH_TEST_MESSAGE”消息會(huì)顯示ERUCCH解錯(cuò)，UE會(huì)隔7幀后會(huì)重復(fù)發(fā)起SYNC1，直到ERUCCH能夠發(fā)送成功，網(wǎng)絡(luò)側(cè)收到“O_CCTS_ERUCCH_REC”進(jìn)入調(diào)度流程，如下：HSUPA案例分析-終端類聯(lián)芯芯片SNPL計(jì)算問題（1）聯(lián)芯芯片早期版本進(jìn)行同頻小區(qū)篩選計(jì)算SNPL時(shí)，會(huì)將異頻小區(qū)選入而將同頻小區(qū)濾除，這樣導(dǎo)致SNPL就不準(zhǔn)確，而且會(huì)經(jīng)常上報(bào)SNPL=-10的最小值。若采用默認(rèn)ROT=22，提升ROT=32還會(huì)出現(xiàn)ROT判決受限，使得用戶出現(xiàn)授權(quán)降低或者不連續(xù)授權(quán)，上行速率不穩(wěn)定或者無速率。下圖為進(jìn)行FTP200kbps限速（PCCPCHRSCP=-68）的上行吞吐率。針對(duì)該問題，分析NodeB的統(tǒng)計(jì)log，發(fā)現(xiàn)用戶的空口速率波動(dòng)非常大，而且聯(lián)芯8142snpl=-10的情況存在，但此時(shí)UE上報(bào)的UPH并不是很差。在此情況下如果按照默認(rèn)參數(shù)進(jìn)行ROT判決，即滿足：Pebase+PRRI-SNPL<=ROT根據(jù)8142的測(cè)量值：（-120）+25-（-10）>(22-120)，則降低授權(quán)使得PRRI=12，只能傳一個(gè)小包。導(dǎo)致速率會(huì)很小。同樣行業(yè)終端也存在這樣的問題，如ZTEA-355數(shù)據(jù)卡。HSUPA案例分析-終端類聯(lián)芯芯片SNPL計(jì)算問題（2）針對(duì)聯(lián)芯芯片存在的SNPL計(jì)算問題，抓取NodeB側(cè)的TPCWinlog進(jìn)行分析如下：HSUPA案例分析-終端類終端不上報(bào)最大能力導(dǎo)致切換后占不上UPA資源問題現(xiàn)象在測(cè)試過程中，聯(lián)芯8142終端按照接入時(shí)所處的小區(qū)能力來上報(bào)UE能力，如果接入時(shí)的小區(qū)是R5小區(qū)，業(yè)務(wù)持續(xù)保持，則此終端在此后(例如小區(qū)間切換，RNC間切換)再也不會(huì)被分配R7資源。在現(xiàn)網(wǎng)中，沒有配置HSPA資源的小區(qū)，對(duì)于某些終端，比如老版本的8142v1.11.04，就可能出現(xiàn)在R5小區(qū)起呼后，切換到支持HSPA的小區(qū)，而無法接入HSPA載波的現(xiàn)象。RNC的產(chǎn)品實(shí)現(xiàn)是，對(duì)于支持有激活HSDPA/HSUPA載波的小區(qū)，在SIB5中會(huì)攜帶HSDPAcellIndicator/E-DCHcellIndicator。協(xié)議中規(guī)定：這個(gè)兩個(gè)IE只是用來表明此區(qū)域?qū)儆贖SDPA或HSUPA的覆蓋范圍，只給UE指示，不做其它用途。而聯(lián)芯的終端根據(jù)這兩個(gè)指示來決定上報(bào)的能力，是不合適的。問題結(jié)論已推動(dòng)所有芯片上報(bào)最大能力。已向CCSA提交CR澄清，并通過。UE在RRC連接建立請(qǐng)求中，需要攜帶“Accessstratumreleaseindicator”和“UEcapabilityindication”，這兩個(gè)能力的上報(bào)值不需要參考小區(qū)的能力，按照UE實(shí)際能力上報(bào)。HSUPA案例分析-網(wǎng)絡(luò)側(cè)RNC間切換協(xié)議版本號(hào)不一致問題外場(chǎng)多個(gè)RNC的小區(qū)都開啟了HSUPA，但是測(cè)試時(shí)發(fā)現(xiàn)RNC間存在問題：從一個(gè)非UPA小區(qū)遷移至UPA小區(qū)，并沒有直接建立在PA載波上，直到用戶釋放再重新建立業(yè)務(wù)后，可以正常承載在該RNC下的HSUPA小區(qū)上。從一個(gè)RNC的HSUPA小區(qū)切換至另一個(gè)RNC的非HSUPA小區(qū)，會(huì)不觸發(fā)切換。分析主要原因是：RNC側(cè)參數(shù)配置導(dǎo)致，修改參數(shù)RNCPROTCLVER=R7（ADDTNRNC）配置可解決該問題。為了支持RNC間HSUPA小區(qū)間的正常切換，需要將該協(xié)議版本參數(shù)配置為R7。修改配置后跨RNC兩個(gè)HSUPA小區(qū)可以正常觸發(fā)切換。該問題已經(jīng)修改入版本基線。HSUPA案例分析-網(wǎng)絡(luò)側(cè)HSPA載波上單下載速率低問題測(cè)試時(shí)發(fā)現(xiàn)，用戶占用HSPA載波做下載時(shí)速率只有1.3M左右，速率沒有在DPA載波上速率高。分析該問題主要有三方面原因：5.0版本E-HICH沒有功控，導(dǎo)致下行時(shí)隙多個(gè)碼道間功率差過大，對(duì)UE的解調(diào)能力影響大，使同時(shí)隙的SCCH解調(diào)失?。唤K端實(shí)現(xiàn)時(shí)，E-RUCCH沒有聽FPACH上帶的TimingAdvance，而是參考同時(shí)隙的DPCH，導(dǎo)致偶爾丟失，使SI上報(bào)不及時(shí)；E-PUCH的開環(huán)功率偏低，上行非連續(xù)調(diào)度時(shí)的NACK率高。改進(jìn)、解決措施由于EHICH的解調(diào)性能很好，原先的功率設(shè)置值較大，所以5.0版本將EHICH最大功率由-3dB改為-9dB。同時(shí)，6.0版本將EHICH發(fā)射功率與時(shí)隙內(nèi)伴隨DPCH功率綁定，有效降低時(shí)隙內(nèi)碼道間功率差。將HSUPASIR目標(biāo)初始值由8dB改為10dB，降低NACK率。另外，室外5.0EPUCH開環(huán)功率余量為3dB。對(duì)于室內(nèi)單天線，由3dB改為9dB。HSUPA案例分析-網(wǎng)絡(luò)側(cè)MAC-hsreset信元缺失導(dǎo)致切換后速率無法恢復(fù)（1）HSPA拉網(wǎng)在做上傳業(yè)務(wù)時(shí)，發(fā)現(xiàn)有幾次RNC內(nèi)的小區(qū)間切換后速率掉零持續(xù)幾秒，還有幾次速率一直無法恢復(fù)。分析金雞湖外場(chǎng)路測(cè)時(shí)發(fā)現(xiàn)2次的TEBS為0，而且調(diào)度率很低的，導(dǎo)致upa速率掉0的問題。Ue側(cè)分析，UE的RLCReset了，主要原因是：這一段數(shù)據(jù)MAC沒有上報(bào)給RLC是因?yàn)榫W(wǎng)絡(luò)在物理信道重配后，對(duì)TSN進(jìn)行了清零，MAC檢查TSN不在窗口范圍之內(nèi)，丟掉下行包并報(bào)錯(cuò)。從L2數(shù)據(jù)統(tǒng)計(jì)來看，之后就沒收到過有效的下行包，最終重傳達(dá)到最大次數(shù)后終端發(fā)起reset。如下圖，切換后持續(xù)7秒鐘上行沒有調(diào)度。HSUPA案例分析-網(wǎng)絡(luò)側(cè)MAC-hsreset信元缺失導(dǎo)致切換后速率無法恢復(fù)（2）網(wǎng)絡(luò)側(cè)在載波間切換或小區(qū)間切換后，MAC-hs實(shí)體會(huì)在新載波上重新建，相當(dāng)于做了一次reset，但沒有通知UE做reset，可能會(huì)導(dǎo)致TSN號(hào)非法。主要是RNC在切換后沒有指示UE進(jìn)行MAC-es/eReset，在某些情況下(TSN在接收窗內(nèi)，但TSN小于next_expected_TSN或這個(gè)TSN已經(jīng)被成功收到)收到的MAC-hsPDU會(huì)被UE丟棄，導(dǎo)致下行數(shù)據(jù)包連續(xù)丟失。

問題最終解決辦法，在發(fā)生載波間切換或者小區(qū)間切換時(shí)，在物理信道重配置消息中攜帶“MAC-hsReset”信元，指示UE進(jìn)行一次Reset。

網(wǎng)絡(luò)側(cè)版本6.0解決。問題舉例：

切換后NodeB發(fā)的MAC-hsPDU從TSN=0開始發(fā)，如果恰好UE側(cè)的接收窗是[60,27]，而且next_expected_TSN=22，那么切換后NodeB發(fā)的從TSN=0到TSN=22的連續(xù)23個(gè)MAC-hsPDU都會(huì)被UE丟棄，導(dǎo)致UE的上行RLCPDU一直不能得到下行反饋，UE會(huì)發(fā)生RLC重傳，如果重傳很多次會(huì)發(fā)生TRBReset或長期沒速率被網(wǎng)絡(luò)側(cè)釋放。HSUPA案例分析-網(wǎng)絡(luò)側(cè)多RAB并發(fā)時(shí)信元填寫不合理導(dǎo)致并發(fā)業(yè)務(wù)失敗問題描述：展訊終端發(fā)起HSPA兩個(gè)PSRAB并發(fā)，第二個(gè)RAB接入時(shí)，終端回復(fù)RBsetup失敗。問題分析：在做兩個(gè)PSRAB并發(fā)時(shí)，第二個(gè)RAB接入后，我們發(fā)起的RBsetup消息中，兩個(gè)“E-DCHMAC-dflow”的信息是分別放在兩個(gè)“UL-AddReconfTransChInformation-r7”下的。協(xié)議規(guī)定多個(gè)E-DCHMAC-dflow時(shí)，“AddedorReconfiguredULTrCHinformation”信元在消息中只能出現(xiàn)一次。如果有多個(gè)“AddedorReconfiguredULTrCHinformation”信元時(shí)，展訊對(duì)于這種配置就會(huì)認(rèn)為非法，協(xié)議對(duì)終端的行為沒有做規(guī)定。問題解決：RNC修改信元填寫方式，在多個(gè)RAB接入后，把多個(gè)E-DCHMAC-dflow并列放到RB消息中的“AddedorReconfiguredULTrCHinformation”下面。該問題在6.0版本已修正。HSUPA案例分析-網(wǎng)絡(luò)側(cè)HSPA用戶從大唐RNC切入華為RNC無法接入PA載波該問題的主要原因是大唐切華為時(shí)，在relocationreq中只攜帶了支持A頻段，而華為當(dāng)前小區(qū)的HSPA載波是F頻段的，所以切換過來時(shí)進(jìn)行了回落，不能上HSPA載波。大唐切華為時(shí)，relocationreq消息只攜帶了A頻段能力指示華為切大唐時(shí)，在relocationreq中攜帶了支持F頻段的能力指示在華為小區(qū)進(jìn)行HSUPA業(yè)務(wù)時(shí)，UE也上報(bào)了支持F頻段。HSUPA案例分析-網(wǎng)絡(luò)側(cè)新版本8142(T4_US_T0610)的SNPL上報(bào)異常問題現(xiàn)象:采用83_T4_US_T0610版本，當(dāng)前小區(qū)配置3個(gè)同頻鄰區(qū)，依然出現(xiàn)SNPL上報(bào)為0的問題。原因分析:CellUpdate之前的SNPL是正常的，前后MeasurementControl的MSN序號(hào)正常累加，但是發(fā)CellUpdate之后，前后MeasurementControl出現(xiàn)重復(fù)的MSN，此時(shí)8142認(rèn)為測(cè)試控制消息非法，因此就認(rèn)為沒有同頻鄰區(qū)了，因此SNPL報(bào)0（index9）。HSUPA案例分析-網(wǎng)絡(luò)側(cè)單小區(qū)HSPA載波一個(gè)上傳，一個(gè)下載測(cè)試分析（1）測(cè)試場(chǎng)景同一個(gè)HSPA載波上兩個(gè)用戶，一個(gè)做上傳，一個(gè)做下載。一個(gè)用戶上傳的同時(shí)，另外一個(gè)用戶做下載：上行速率從500kbps下降到369kbps左右。一個(gè)用戶下載的同時(shí)，另外一個(gè)用戶做上傳：下行速率從1.5Mbps下降到1.4Mbps左右。HSUPA案例分析-網(wǎng)絡(luò)側(cè)單小區(qū)HSPA載波一個(gè)上傳，一個(gè)下載測(cè)試分析（2）UE側(cè)log分析UE側(cè)log