LTE-TDD问题定位指导书-吞吐量篇
文档密级：内部公开
E-RAB Maximum Bit Rate Downlink M Bit Rate 9.2.1.19 Desc.: This IE indicates the maximum downlink E-RAB Bit Rate (i.e. from the EPC to E-UTRAN) for this bearer. E-RAB Maximum Bit Rate Uplink M Bit Rate 9.2.1.19 Desc.: This IE indicates the maximum uplink E-RAB Bit Rate (i.e. from the E-UTRAN to the EPC) for this bearer.
? 从L1 TTI跟踪中统计观察是否存在大量DTX情况，判断方法：观察上行DMRS
RSRP，如果发现RSRP值在调度的TTI处于底噪（－120dbm）附近，或者与前后的RSRP值相差较大，则认为是上行PUSCH的DTX。对比eNB侧DCI0次数，如果相差较大，则认为存在大量的DTX，需要判断PDCCH质量问题，是否是下行PDCCH IBLER较高，导致UL Grant解错。
说明：PDCCH允许一定的误检率，允许1%以内；而且上行HARQ时，调度器不需要下发ULGrant。
? 观察是否数据源不足（上报BSR 对应的值），如果数据源不足，需要排查是
否上层数据源异常，可能包括如下原因（详细参考应用层问题优化指导书）： （1）如果是UDP业务，检查上行灌包（出口速率）是否超过峰值速率。 （2）如果是TCP单线程业务，尝试多个线程，如果吞吐量可以提升到峰值速率，则可以认定是PC机的TCP窗口没有符合要求。
说明：如果ULGrant个数偏小，一般是由于上述两个原因导致。
数据源是否充足在eNB侧的TTI跟踪观测BSR上报记录及调度缓冲区大小。如果为BSR上报问题，可以将BSR周期从32ms修改为5ms。
2016-6-9
华为机密，未经许可不得扩散
第46页, 共59页
LTE-TDD问题定位指导书-吞吐量篇
文档密级：内部公开
? 在性能检测中观察在线用户数，看是否存在多用户并行业务（2个以上）的情
况，如果存在多用户，则主要观察RB利用率是否达到了100％，公平性是否得到满足。如果RB利用率低，则需要判断ICIC和频选是否开关打开，是否存在问题；如果公平性得不到满足，则可能为功控和ICIC的问题。这里的公平性指RB数公平，与算法的目标一致。 ? RB利用率观测方法
观察小区级RB利用率是否达到100％，在测试时可看M2000－>小区性能监测->RB利用率。 ? ICIC问题定位
上行ICIC算法的主要目标是改善边缘UE的上行吞吐率，同时使小区吞吐率受到的影响尽量小。目前上行ICIC算法采用了动态软频率复用的思想，把相邻小区的边缘UE分配到相互不重叠的频率资源上，使远点UE的上行接收只受到邻区中心UE（近点或中点）的干扰，以改善远点UE的上行吞吐率。
静态ICIC中，算法决定了边缘用户可调度的频带；根据A3测量报告定义出用户属性，在进行上行调度时，边缘用户只能使用边缘频带。
对于静态ICIC下的问题分析，主要关注用户属性判断是否准确，以及边缘频带是否分布合理： （1）ICIC算法是否识别出边缘UE
在UE OMT上跟踪RRC层信令消息，如果观测到MeasurementReport消息，并且消息中的MeasurementID与ICIC A3测量ID相同；并从TTI跟踪中查看用户属性，则可确定eNodeB已将UE判定为边缘UE。
确定ICIC A3测量ID的方法：搜索包含MeasurementConfig的RRCConnectionReconfiguration消息，如果消息中的reportOnLeave字段取值为TRUE则表明该消息中的MeasurementID为ICIC A3测量的ID。 （2）边缘频带分布是否合理
观察对应时刻用户邻区列表中最强的几个邻区其边缘频带分布及频带占用情况。目前性能监测中可以对ICIC的关注项进行监测，但需要可进一步批量对小区进行布控；在小区级CHR中需要能周期性记录边缘频带，可
2016-6-9
华为机密，未经许可不得扩散
第47页, 共59页
LTE-TDD问题定位指导书-吞吐量篇
文档密级：内部公开
辅助问题定位。
动态ICIC算法中，增加了对HII的考虑，邻区的干扰情况将会影响到本小区有效边缘频带分配，有效频带会随着邻区的干扰和负载情况发生变化。动态ICIC的性能时需重点关注下列事项：
X2口消息交互是否正常，是否存在只收不发或者跟踪不到消息交互的情况；只收不发可能是该小区没有打开动态ICIC开关造成的；而跟踪不到消息则可能是X2接口链路配置不正确造成的。
重载小区的边缘频带是否进行了扩张；如果未进行扩展，则原因可能是：重载小区的边缘RB需求并未超过基础边缘频带；轻载小区的边缘RB需求超过了基础边缘频带；所有小区的边缘频带需求超过了PUSCH最大带宽。这都属于测试条件设置不合理，不能体现动态ICIC相对静态ICIC的增益。
层3给出的频带划分是否符合预期，层2调度是否遵守了层3的频带划分。
在问题分析时，需要关注用户的属性以及边缘频带大小，直接影响了用户的吞吐率；而边缘频带又受到邻区的HII影响，这些因素都应该关注。 ? 上行功控问题定位
PUSCH功率控制采用部分补偿功率控制，其主要思路为：通过初始值设置保证小区边缘用户速率，各用户差异等；通过部分补偿降低小区边缘用户对相邻小区干扰，同时提高中心用户吞吐量。通过TPC命令字调整用户发射功率，跟踪信道状况变化。UE根据上行功控计算得到的UE功率余量上报给调度算法，调度器依据功率余量计算UE分配的RB数目。
功控测试中，如果存在近点用户，RB要基本占满；近点MCS阶数基本要达到24。目前碰到的问题一般为RB利用率低。
在调度算法中，RB数的确定过程如下： （1）期望的RB个数确定流程：
根据UE的缓冲区状态、token bucket状态、功率余量(power headroom)状态，产品硬件约束以及单载波允许的RB个数确定本TTI资源所需RB个数M2016-6-9
(u)
华为机密，未经许可不得扩散
第48页, 共59页
LTE-TDD问题定位指导书-吞吐量篇
文档密级：内部公开
i) 确定用户当前TTI允许传送的数据量d(u) ；
ii) 由用户全带宽的平均SINR值加上SINR的调整量SINR?_filter ，进行
(u)MCS初选，确定MCS级别，获得对应的频谱效率，记为Eavg ，计算RB
个数M(u)0??d(u)??(u)? ； E?12?12???avg?iii) 根据power headroom确定用户能够支持的RB个数，记为M1(u)； 调度计算上行RB数目流程如下： 1）维护P 值 c Pc?PHR?10logM(j)?Pmax?P0??PL P物理含义表示当前功率谱密度下所能支持的RB数目扩展能力。 c2）计算RB数据
M(i)?10?10?10Pc10Pmax?P0??PL10PHR?10logM(j)10
从上式可以看出，调度以以前分配的RB为基础判断如何调整RB数目。例如 大于0，可以扩展RB，如果 等于0，维持RB不变；如果 小于0，则缩小RB。
iv) 设产品硬件规格允许的单用户最大分配RB个数为Mhd-limit ； v）则当前
TTI
i分配给用户u的RB个数为
(u)M(u)?miMn0{,M1(u),Mhd-l}mit，如果 不满足单载波RB个数要求，则取离
M(u)最近的满足单载波约束的RB个数为新的M(u)值。其中，单载波RB个
312数约束为：上行所分配RB数目须满足M?235 ，其中k1k2k3为整数，
kkk2、3、5为协议规定的DFT基。
（2）实际调度分配的RB数确定
根据期望的RB数，在上行频带中查找可分配的资源。频带查找使用滑
2016-6-9
华为机密，未经许可不得扩散
第49页, 共59页
LTE-TDD问题定位指导书-吞吐量篇
文档密级：内部公开
窗机制，查找SINR均值最大，满足窗口的资源。
功控算法输出的PHR主要影响了RB数，根据上述的RB数确定过程，如果RB数较少，需要查看UE功率是否已经达到了上限，即PHR为0. 如果PHR值为0，而RB数没有达到最大，可能与路损过大、P0值设置不合理有关，需要观察Pc值，根据Pc值可计算出分配的RB数。 ? 上行频选问题定位
上行频选RB分配，在确定期望RB数后，在全频带进行滑窗搜索，查找符合窗口大小，且SINR均值最高的连续RB进行分配。多用户情况下，频选容易造成碎片，由于上行必须使用连续的RB，因此，碎片较多会导致RB少，吞吐率下降。
频选需要关注碎片情况以及是否分配了了SINR最优的连续RB。因此，需要可观察当前TTI的可分配RB的分布情况，以及各RB的SINR分布情况。
? 检查PRACH的资源配置。上行预留PRACH的时候，会对上行分配RB产生
影响，对上行峰值速率产生影响，10M系统更明显。可以将PRACH设置到PUSCH最低端，且将PRACH默认周期从5ms扩大为20ms。
? 检查PUCCH配置，当前默认配置占用8RB，在单用户峰值测试时，可以手动
改为2个RB，提高上行峰值吞吐率，再测极限峰值。
5.2.2.2 低阶MCS定位方法
MCS由几方面决定：PUSCH SINR、IBLER、UE CAT能力、是否扩展CP。在SRS、周期随路信令发送时，MCS也会强制降阶。
在较高的上行SINR时，如果下行PDCCH质量太差，导致UL grant丢失，会导致IBLER
2016-6-9
华为机密，未经许可不得扩散
第50页, 共59页