lesson7td-hsupa组网、测试及案例分析

HSUPA组网、测试

及案例分析目录HSUPA 基本原理介绍HSUPA组网方案HSUPA测试及分析指导HSUPA案例分析HSUPA的数传流程UE通过ERUCCH/SI发送“调度请求”，携带上行缓存数据量和信道质量关键信息，连续调度“调度信息”在上行数据包中携带；不连续调度，“调度信息”通过ERUCCH随机接入过程上报。网络侧根据“调度请求”中的关键信息，选择调度的用户，通过EAGCH信道授权；UE通过EPUCH信道发送上行数据；网络侧通过EHICH信道发送ACK/NACK信息；另外，UE新建业务、触发小区间切换后，以及出现不连续调度，都要通过ERUCCH的随机接入过程上报“调度信息”，随机接入具体流程如下：UE通过SYNCUL进行上行同步；网络侧通过FPACH反馈响应信息；UE通过通过ERUCCH进行随机接入，如果UE发送了ERUCCH，且网络侧进行了EAGCH授权，则进入正常的调度流程；HSUPAUTRAN侧协议栈介绍对于每个使用E-DCH的UE，每个NodeB配置一个MAC-e实体，每个SRNC配置一个MAC-es实体。NodeB中的MAC-e控制E-DCH接入并连接到位于SRNC的MAC-es，并进一步连接到MAC-d。UTRAN侧的MAC层结构HSUPAUTRAN侧协议栈介绍NodeB中针对每个UE配置一个MAC-e实体，并且配置一个E-DCH调度器。MAC-e实体和E-DCH调度器处理NodeB中与HSUPA相关的功能。MAC-e实体和E-DCH调度器包含以下实体：UTRAN侧MAC-e实体E-DCH调度模块管理UE之间的E-DCH小区资源。基于调度请求NodeB决定并发送调度授权。如何调度用户取决于网络侧的调度策略；E-DCH控制实体负责接收调度请求并发送调度授权；MAC-ePDU解复用实体，负责解复用MAC-ePDU，并将其转发给相关的MAC-dflow；HARQ实体支持多个HARQprocess的停等HARQ协议。每个HARQprocess负责产生指示E-DCH传输递交状态的ACK或NACK。该实体负责处理HARQ协议要求的所有任务。HSUPA新增信道介绍HSUPA新增信道主要包括以下几种类型：1条传输信道E-DCHE-DCH（EnhancedDedicatedChannel）是新增的传输信道，该信道用于承载上行业务，映射到物理信道E-PUCH。2条下行物理信道：E-HICH、E-AGCHE-HICH（E-DCHHybridARQAcknowledgementIndicatorChannel）用来承载一个或者多个用户的ACK/NACK，是下行信道。调度和非调度的ACK/NACK比特需要在不同的E-HICH上发送。E-AGCH（E-DCHAbsoluteGrantChannels）是共享下行信道，用于承载授权AG（AbsoluteGrant）信息。3条上行物理信道：E-PUCH、ERUCCH/E-UCCHE-PUCH（E-DCHPhysicalUplinkChannel）是用于承载E-DCH类型物理信道，用于传输上行业务数据，是上行信道，包括调度资源和非调度资源。E-RUCCH（E-DCHRandomAccessUplinkControlChannel）是用于HSUPA的随机接入信道，是上行信道，该信道要映射到PRACH上。当UE从空闲态进入业务态或者进行重配置后，如果有数据要发送，通过该信道向UE发送调度信息。E-UCCH（E-DCHUplinkControlChannel）载有与E-DCH相关的上行控制信息，是上行控制信道，映射在E-PUCH上。目录HSUPA 基本原理介绍HSUPA组网方案HSUPA测试及分析指导HSUPA案例分析现有网络引入HSPA后的组网策略(1)在2011及未来几年内，TDS网络将出现既有仅支持A频段的网络，也有支持A+F频段的网络，还有仅支持A频段和支持A+F频段混合存在的网络。从频段分配的角度，对于支持A+F频段的网络，建议不论室外还是室内小区新增的HSPA载波都由F频段承载，而对于仅支持A频段的网络，建议根据话务统计，则需要根据实际网络状况，选择话务负荷低的R4或者HSDPA载波，配置成HSPA载波，尽量降低对原有网络的影响。总体网络现状：网络中的载波类型：R4、HSDPA、HSPAHSPA载波推荐配置：现有网络引入HSPA后的组网策略(2)一期网络：多为S333站型，每小区2个R4、1个HSDPA载波，HSDPA载波全同频组网。仅支持A频段网络引入HSPA的组网策略：二期网络：多为S333站型，每小区1个R4、2个HSDPA载波，HSDPA载波采用全同频或者2*3频率复用方式组网。首选首选现有网络引入HSPA后的组网策略(3)三期网络：多为S444站型，每小区2个R4、2个HSDPA载波，HSDPA载波采用全同频或者2*3频率复用方式组网。首选现有网络引入HSPA后的组网策略(4)支持A+F频段网络引入HSUPA的组网策略不论是单A频段组网，还是A+F频段组网，或是既有单A又有A+F频段的网络，都不可避免的出现HSPA全同频组网或是HSPA与HSDPA混合同频组网的网络形态！目录HSUPA 基本原理介绍HSUPA组网方案HSUPA测试及分析指导HSUPA案例分析HSUPA功能测试及指导测试终端设置(LC8142)建议硬件版本：8142V软件版本：高于8142V1.20.00协议版本号设置为R7，只有在设置为R7版本下才能保证支持HSUPA功能。注意事项：联芯测试终端已发布8142V1.20.00版本，但是该版本整体的稳定性较差，移动时极易出现cellupdatte，不建议测试使用。（目前有联芯的内部版本LC83_T4_US_T50620，该版本解决了SNPL上报问题、低码率功率不受控等问题，或者测试前去联芯网站下载最新8142软件版本。）HSUPA载波资源配置建议增加纯HSUPA载波在小区中增加载波，在该载波上行配置HSUPA资源，下行为R4DCH，载波仅被激活为HSUPA，ACTHSUPATCARRIER，实际现网中不会存在“纯HSUPA载波”。HSDPA载波升级为HSPA载波/增加HSPA载波将HSDPA载波升级为HSPA，或者增加HSPA载波，即上行配置HSUPA，下行为HSDPA，载波被激活为HSPA如下：ACTHSUPATCARRIER，ACTHSDPATCARRIER。此称之为HSPA载波。HSUPA功能测试及指导RNC侧速率门限说明RNC侧速率门限UE设置建议小区中的HSUPA资源配置方式为”HSPA载波”，设置AT命令字采用如下方式：AT+CGDCONT=1,"IP","CMNET",,,;+CGEQREQ=1,2,2048,2048,,,0,,,,,(申请上行速率大于等于ULBETRAFFTHSONHSUPA)&(申请下行速率大于等于DLBETRAFFTHSONHSDPA)，此时用户才会承载在”HSPA载波”上。注：HSPA载波设置AT命令，必须上下行都设置，若不设下行，可能导致下行为默认值，低于DLBETRAFFTHSONHSDPA门限，用户无法接入HSPA载波，也无法接入HSDPA载波。HSUPA功能测试及指导测试结果参考

1、通过RBsetup消息中的E-RNTI来判断用户是否承载在HSUPA上2、HSPA载波上进行CQT单下载测试，下行速率可以接近1.5Mbps3、HSPA载波上进行CQT单上传测试，上行速率约为0.5Mbps4、HSPA载波CQT同时上传下载测试，上/下行速率在0.5/1.5Mbps左右TPCWinLOG能够更好更细致的分析HSUPA问题，补充普通跟踪手段的不足。HSUPA常用LMT-BTPCWinLOG跟踪指导TPC消息是NodeB网元内部的即时消息，从LCR5.0版本开始，TPC消息的跟踪功能由LMT-B来完成。具体跟踪设置方式如下：1、配置服务器地址，使用MML命令SETTPCSERVER重新设置，如下图

所示：“FTP服务器地址”就是RNC映射的BAM虚拟地址，设置好服务器地址后可以通过LSTTPCSERVER进行查询，确认上传服务器的正确。HSUPA常用LMT-BTPCWinLOG跟踪指导2、基带板TPCWinLOG跟踪通过命令CLRTPC清理以前抓取过的TPCWin消息，将之前设置的标志位等遗留信息全部清除；设置抓取消息的Testlevel(一般该步骤可略去，根据实际情况调整)“场景”参数需要根据问题现象或是研发人员的要求来选择；LMT-B中给出的默认场景，选择该场景跟踪的TpcWinlog会默认记录一些消息。如果需要单独跟踪一些消息，选择“其它场景”时需要设置一些消息的Testlevel，TestLevel”参数值，这个可以从研发人员处获取跟踪TPC消息(STRTPCTRACE，)，跟踪成功后有提示消息给出;!HSUPA跟踪TPCWinLOG分析指导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说明：只需要选择和当前NB版本匹配的*.dll文件即可，不需要重新安装TPCWIN工具。2、5.0/6.0版本TpcWin采集的是“base_*.trx”文件，在导入HSTool之前需要进行解压，解压过程如下图：解压完后的LOG方可用TOOL工具进行解析HSUPA跟踪TPCWinLOG分析指导3、打开“LogToPlugin.exe”工具，导入解压好的LOG，然后在“LogFile”中导入采集解压后的log；在“LoadOpCode”中导入版本配套的xssopo_n_x_bic.h；在“LoadPlug-in”中输入相同版本的.dll文件，该文件一般放置在TPCwin的安装目录:TD-TECH\tpcwin\PlugIn\，4、查阅HSUPA关键统计信息例如，在该界面上点击HSUPA菜单栏查阅HSUPA关键统计信息HSTOOL和BERTOOL功能分析简介HSUPATool主要是为验证HSUPA功能、以及解决HSUPA应用过程中出现的问题，HSUPATool中主要有以下几个部分：ScheduledInformationTable统计表格，该表格主要用来分析和定位HSUPA业务空口质量相关问题，该统计表格中的统计字段主要有UE的授权功率，NACK值，ACK值，Pebase、snpl等信息；SchdulingFlagTable统计表格，该表格主要用来查阅各种原因下的UE调度次数；HSUPAScheduledUserDataRateTable统计表格，该表格用来统计一些速率信息；HSUPAcarrierdatarateTable用于定位单个载波下资源使用以及环境相关情况；注：其中前3项是分析和定位HSUPA问题经常要关注的一些统计信息。HSTOOL和BERTOOL功能分析简介SchduledInformationTable统计表格介绍Reportsfn:本条记录的子帧号，范围0－8191,每200子帧(1s)统计一次；ACKNum:1s内NodeB成功解码的Mac-epdu总数；NACKNum:1s内NodeB解码失败的Mac-ePDU总数，此项越大表明空口的质量越差，速率越低；DiscardNum:1s内NodeB达到最大重传次数后仍未成功解码，丢弃的mac-epdu的总数。此项越大表明空口的质量越差，此时可以检查功率配置和功控相关参数是否合理；AverUPH:1s内统计UE上报的功率余量的平均值，在上行数据量充足的情况下，该值越大，上行能够得到的吞吐量就越高，UPH最大值为48；AverSNPL:1s内服务小区与邻区的路损的平均值，SNPL反映了UE在小区内距离各基站的位置情况；SNPL最大值为26；AverEUCCHNum:1s内使用占用E-UCCH信道的个数的平均值，该值一般为10，不需关注；Avergrantpower:1秒内授权功率的平均值；注：上述测量量中，UPH、SNPL和AverGrantPower是要重点关注的统计量。HSTOOL和BERTOOL功能分析简介SchduledFlagTable统计表格介绍NormalScheduling:

1s内正常调度的次数；DataInsufficient:

1s内UE侧buffer数据不足的次数，这种情况下UE依旧会被调度，但会降低给UE分配调度资源；BadJDPerformance:每秒内授权的功率不足以支持联检的次数。由于HSUPA上行不进行码分复用，该统计不需关注；TooBadC/I:每秒内分配的授权功率不足以支持UCCH发送的次数，此情况下UE不被调度；TooSmallGrant:每秒内分配的授权功率不足以发送一个mac-epdu的次数，这种情况下UE不被调度；RetransmitFailed:每秒内不支持重传的次数，但这种情况下UE依旧会被调度，只是不能支持重传。上述统计量中NormalScheduling、DataInsufficient和RetransmitFailed可以重点关注。HSTOOL和BERTOOL功能分析简介HSUPASchduledUserDataRateTable统计表格介绍air_data_rate:1s内统计的实际空口速率，是收到的ACK的mac-epdu的速率；req_data_rate:

1s内统计的UE请求速率；grant_data_rate:1s内统计的NB授权的速率，该值是NodeB根据UE上报的UPH值和缓存区数据量的多少来确定的；grant_tb_size:1秒内授权给UE发送的tb_size平均值，即在1秒内授权给UE发送的总的bit数；air_tb_size:1秒内UE实际发送的TBsize的平均值；aver_tebs:1秒内UE上报的上行缓存Buffer的平均值，可表明上行数据量的多少；conges_ind_num:

1秒内RNC指示拥塞的次数；aver_retrans_num:1秒内平均重传的次数；HSTOOL和BERTOOL功能分析简介BERTOOL主要用作进行HSUPA问题深入分析做辅助应用，根据其测量量信息进行问题辅助分析，如下图：目录HSUPA 基本原理介绍HSUPA组网方案HSUPA测试及分析指导HSUPA案例分析HSUPA案例分析-终端类UE不支持Upshifting问题背景：

部分HSUPA终端不支持辅载波Upshiting功能，如8142v1.11.04版本，导致该类终端一接入Uppch起始位置不为0的小区，会出现无速率的现象。问题分析：对于HSUPA终端，在业务发起过程中会做2次随机接入，第一次随机接入，采用的是主载波配置的用于一般随机接入的SYNC_UL。第二次当HSUPA终端申请调度资源的随机接入时，首先还是需要通过SYNC_UL发起上行同步。当主载波配置HSUPA资源时，就使用用于HSUPA的那组SYNC_UL；当辅载波配置HSUPA资源时，UE需要使用辅载波上配置的SYNC_UL发起上行同步。目前有的HSUPA终端将用于HSUPA调度资源申请的SYNC_UL的起始位置固定了，网络侧自然检测不到UE发起的上行同步，导致UE无法申请到调度资源。表现为HSUPA终端能拨号激活，但是就是没速率。规避措施若网络侧开启的是静态UpShifting功能，将HSPA载波的UpPCH起始位置配置的和主载波一致。但是如果终端不支持主载波配置静态Upshifting那只能靠终端解决。HSUPA案例分析-终端类动态UpShifting与HSPA功能兼容性问题问题背景：当HSPA配置在辅载波，辅载波配置的UpPCHPosition不同于主载波当前的UpPCHPoaition的时候就会出现SYNC_UL接入失败，最终发起Cellupdate。问题分析：该问题为终端问题，HSPA终端只读取主载波的UpPCH位置变更信息，辅载波与主载波的UpPCHPositon配置不一致，或者主载波开启动态UpShifting后，UpPCH位置不同就会导致问题产生。规避措施网络侧在开启HSPA载波时关闭动态UpShifting功能，同时将HSPA载波UpPCHPosition位置与主载波配置一致。(说明，如果终端存在上述问题，那么关闭动态也没用)。值得注意的是：该问题主要是终端不读取HSPA载波的UpPCH位置信息，导致SYNC_UL接入失败。关闭动态UpShifting功能对先现场UpPCH干扰的抑制会带来一定的风险，需要现场在UpPCHISCP高的小区手动调整静态UpPCHPosition，并将HSPA载波进行统一配置。HSUPA案例分析-终端类UE不发送ERUCCH问题如果终端不发送ERUCCH，网络侧无法对用户进行调度，UE会一直没有速率。只要存在不连续调度场景或者频繁触发切换，UE上行速率掉零现象严重，都有可能是UE没有发送ERUCCH导致；通过NodeB侧TPCWinLog显示ERUCCH解码错误现象，通过“O_XXCH_TEST_MESSAGE”来看是否为ERUCCH没有发送导致：消息中第一个word“CC000008”是ERUCCH的opcode，说明是ERUCCH的打印；消息中第四个word如果是“00000001”代表ERUCCH消息解错；如果是“00000000”代表ERUCCH消息能够正确解调；如果是终端不发送ERUCCH，那么“O_XXCH_TEST_MESSAGE”消息会显示ERUCCH解错，UE会隔7帧后会重复发起SYNC1，直到ERUCCH能够发送成功，网络侧收到“O_CCTS_ERUCCH_REC”进入调度流程，如下：HSUPA案例分析-终端类联芯芯片SNPL计算问题（1）联芯芯片早期版本进行同频小区筛选计算SNPL时，会将异频小区选入而将同频小区滤除，这样导致SNPL就不准确，而且会经常上报SNPL=-10的最小值。若采用默认ROT=22，提升ROT=32还会出现ROT判决受限，使得用户出现授权降低或者不连续授权，上行速率不稳定或者无速率。下图为进行FTP200kbps限速（PCCPCHRSCP=-68）的上行吞吐率。针对该问题，分析NodeB的统计log，发现用户的空口速率波动非常大，而且联芯8142snpl=-10的情况存在，但此时UE上报的UPH并不是很差。在此情况下如果按照默认参数进行ROT判决，即满足：Pebase+PRRI-SNPL<=ROT根据8142的测量值：（-120）+25-（-10）>(22-120)，则降低授权使得PRRI=12，只能传一个小包。导致速率会很小。同样行业终端也存在这样的问题，如ZTEA-355数据卡。HSUPA案例分析-终端类联芯芯片SNPL计算问题（2）针对联芯芯片存在的SNPL计算问题，抓取NodeB侧的TPCWinlog进行分析如下：HSUPA案例分析-终端类终端不上报最大能力导致切换后占不上UPA资源问题现象在测试过程中，联芯8142终端按照接入时所处的小区能力来上报UE能力，如果接入时的小区是R5小区，业务持续保持，则此终端在此后(例如小区间切换，RNC间切换)再也不会被分配R7资源。在现网中，没有配置HSPA资源的小区，对于某些终端，比如老版本的8142v1.11.04，就可能出现在R5小区起呼后，切换到支持HSPA的小区，而无法接入HSPA载波的现象。RNC的产品实现是，对于支持有激活HSDPA/HSUPA载波的小区，在SIB5中会携带HSDPAcellIndicator/E-DCHcellIndicator。协议中规定：这个两个IE只是用来表明此区域属于HSDPA或HSUPA的覆盖范围，只给UE指示，不做其它用途。而联芯的终端根据这两个指示来决定上报的能力，是不合适的。问题结论已推动所有芯片上报最大能力。已向CCSA提交CR澄清，并通过。UE在RRC连接建立请求中，需要携带“Accessstratumreleaseindicator”和“UEcapabilityindication”，这两个能力的上报值不需要参考小区的能力，按照UE实际能力上报。HSUPA案例分析-网络侧RNC间切换协议版本号不一致问题外场多个RNC的小区都开启了HSUPA，但是测试时发现RNC间存在问题：从一个非UPA小区迁移至UPA小区，并没有直接建立在PA载波上，直到用户释放再重新建立业务后，可以正常承载在该RNC下的HSUPA小区上。从一个RNC的HSUPA小区切换至另一个RNC的非HSUPA小区，会不触发切换。分析主要原因是：RNC侧参数配置导致，修改参数RNCPROTCLVER=R7（ADDTNRNC）配置可解决该问题。为了支持RNC间HSUPA小区间的正常切换，需要将该协议版本参数配置为R7。修改配置后跨RNC两个HSUPA小区可以正常触发切换。该问题已经修改入版本基线。HSUPA案例分析-网络侧HSPA载波上单下载速率低问题测试时发现，用户占用HSPA载波做下载时速率只有1.3M左右，速率没有在DPA载波上速率高。分析该问题主要有三方面原因：5.0版本E-HICH没有功控，导致下行时隙多个码道间功率差过大，对UE的解调能力影响大，使同时隙的SCCH解调失败；终端实现时，E-RUCCH没有听FPACH上带的TimingAdvance，而是参考同时隙的DPCH，导致偶尔丢失，使SI上报不及时；E-PUCH的开环功率偏低，上行非连续调度时的NACK率高。改进、解决措施由于EHICH的解调性能很好，原先的功率设置值较大，所以5.0版本将EHICH最大功率由-3dB改为-9dB。同时，6.0版本将EHICH发射功率与时隙内伴随DPCH功率绑定，有效降低时隙内码道间功率差。将HSUPASIR目标初始值由8dB改为10dB，降低NACK率。另外，室外5.0EPUCH开环功率余量为3dB。对于室内单天线，由3dB改为9dB。HSUPA案例分析-网络侧MAC-hsreset信元缺失导致切换后速率无法恢复（1）HSPA拉网在做上传业务时，发现有几次RNC内的小区间切换后速率掉零持续几秒，还有几次速率一直无法恢复。分析金鸡湖外场路测时发现2次的TEBS为0，而且调度率很低的，导致upa速率掉0的问题。Ue侧分析，UE的RLCReset了，主要原因是：这一段数据MAC没有上报给RLC是因为网络在物理信道重配后，对TSN进行了清零，MAC检查TSN不在窗口范围之内，丢掉下行包并报错。从L2数据统计来看，之后就没收到过有效的下行包，最终重传达到最大次数后终端发起reset。如下图，切换后持续7秒钟上行没有调度。HSUPA案例分析-网络侧MAC-hsreset信元缺失导致切换后速率无法恢复（2）网络侧在载波间切换或小区间切换后，MAC-hs实体会在新载波上重新建，相当于做了一次reset，但没有通知UE做reset，可能会导致TSN号非法。主要是RNC在切换后没有指示UE进行MAC-es/eReset，在某些情况下(TSN在接收窗内，但TSN小于next_expected_TSN或这个TSN已经被成功收到)收到的MAC-hsPDU会被UE丢弃，导致下行数据包连续丢失。

问题最终解决办法，在发生载波间切换或者小区间切换时，在物理信道重配置消息中携带“MAC-hsReset”信元，指示UE进行一次Reset。

网络侧版本6.0解决。问题举例：

切换后NodeB发的MAC-hsPDU从TSN=0开始发，如果恰好UE侧的接收窗是[60,27]，而且next_expected_TSN=22，那么切换后NodeB发的从TSN=0到TSN=22的连续23个MAC-hsPDU都会被UE丢弃，导致UE的上行RLCPDU一直不能得到下行反馈，UE会发生RLC重传，如果重传很多次会发生TRBReset或长期没速率被网络侧释放。HSUPA案例分析-网络侧多RAB并发时信元填写不合理导致并发业务失败问题描述：展讯终端发起HSPA两个PSRAB并发，第二个RAB接入时，终端回复RBsetup失败。问题分析：在做两个PSRAB并发时，第二个RAB接入后，我们发起的RBsetup消息中，两个“E-DCHMAC-dflow”的信息是分别放在两个“UL-AddReconfTransChInformation-r7”下的。协议规定多个E-DCHMAC-dflow时，“AddedorReconfiguredULTrCHinformation”信元在消息中只能出现一次。如果有多个“AddedorReconfiguredULTrCHinformation”信元时，展讯对于这种配置就会认为非法，协议对终端的行为没有做规定。问题解决：RNC修改信元填写方式，在多个RAB接入后，把多个E-DCHMAC-dflow并列放到RB消息中的“AddedorReconfiguredULTrCHinformation”下面。该问题在6.0版本已修正。HSUPA案例分析-网络侧HSPA用户从大唐RNC切入华为RNC无法接入PA载波该问题的主要原因是大唐切华为时，在relocationreq中只携带了支持A频段，而华为当前小区的HSPA载波是F频段的，所以切换过来时进行了回落，不能上HSPA载波。大唐切华为时，relocationreq消息只携带了A频段能力指示华为切大唐时，在relocationreq中携带了支持F频段的能力指示在华为小区进行HSUPA业务时，UE也上报了支持F频段。HSUPA案例分析-网络侧新版本8142(T4_US_T0610)的SNPL上报异常问题现象:采用83_T4_US_T0610版本，当前小区配置3个同频邻区，依然出现SNPL上报为0的问题。原因分析:CellUpdate之前的SNPL是正常的，前后MeasurementControl的MSN序号正常累加，但是发CellUpdate之后，前后MeasurementControl出现重复的MSN，此时8142认为测试控制消息非法，因此就认为没有同频邻区了，因此SNPL报0（index9）。HSUPA案例分析-网络侧单小区HSPA载波一个上传，一个下载测试分析（1）测试场景同一个HSPA载波上两个用户，一个做上传，一个做下载。一个用户上传的同时，另外一个用户做下载：上行速率从500kbps下降到369kbps左右。一个用户下载的同时，另外一个用户做上传：下行速率从1.5Mbps下降到1.4Mbps左右。HSUPA案例分析-网络侧单小区HSPA载波一个上传，一个下载测试分析（2）UE侧log分析UE侧log