协调传输排除故障。 5. 效果评估
速率恢复正常。 6. 注意事项及建议
针对下行吞吐率不达标的问题，按照相关指导书进行逐步核查；涉及到非空口原因导致的调度不足以及吞吐率较低问题，应通过基本手段初步判断问题原因，再求助相关模块进行进一步确认并及时处理；针对基站传输类告警，不容易发现，建议通过基站层显示出来，便于及时发现并及时处理。
1.5传输参数问题
1.5.1案例11： PTNQOS参数限制导致LTE下载速度低案例
1. 现象描述
某日在对某小区进行单站验证的过程中，对该小区进行定点的上传和下载业务，发现即使在覆盖“极好点”，该站的下载速度依旧只有8~10Mbps，达不到测试用例的要求。 2. 问题分析
使用jperf，对传输进行推送测试，发现主要问题应该在传输上，由于传输的限制导致下载速度最大只能达到10Mbps。最终核查发现华为在PTN上做了些QOS的配置，根据不同业务限制了最高带宽，对下载业务带宽为10M，这样导致了下载的限制。 3. 问题分类： 传输参数 4. 解决方案
改变了PTN上的QOS配置的参数限制 5. 效果评估
进行下载验证，结果显示恢复正常，达到30Mbps以上，符合用例需求。 6. 注意事项及建议
PTN上的QOS配置参数限制可能导致下载速率低。
1.5.2案例12： PTN侧MAC地址学习功能未配置导致LTE基站FTP下载速率低
1. 现象描述
某地TD-LTE实验网，部分基站进行迅雷下载时，速率能够稳定达到60Mbps，但采用FTP下载时最小速率仅几Mbps，并且出现频繁的速率波动。 2. 问题分析
本次实验网分析中迅雷下载速率较高，说明无线环境、容量、时隙配比、传输带宽和速率相关无线参数设置均没有问题。而迅雷下载采用的是UDP协议，FTP下载采用的TCP协议。UDP与TCP协议主要区别在超时重发机制上，根据这种区别初步怀疑PTN传输侧有丢包。采用wireshark软件进行S1抓包分析，发现大量的数据包重传。传输站点未发现告警，且LTE基站各个传输链路光功率收发均正常，未存在光路衰减情况。查询传输相关参数配置，发现速率异常的LTE站点对应的PTN设备MAC地址学习功能未配置。 3. 问题分类：传输参数 4. 解决方案
为速率异常站点配置PTN设备MAC地址学习功能。 5. 效果评估
FTP下载速率恢复正常。 6. 注意事项及建议
PTN上的MAC地址学习功能未配置可能导致下载速率低。
1.5.3案例13： 由交换机端口配置不正确导致LTE TDD下载速率波动问题
1. 现象描述
在某LTE TDD 100M峰值下载业务验证中，发现FTP下载业务速率严重波动，从10Mpbs到60Mbps波动，平均速率仅有25Mbps左右，用wireshark工具抓包，可以看到大量重传。由于所有设备搬迁过一次，而在之前的测试中，峰值可稳定在90Mbps左右。 2. 问题分析
检查交换机配置：登录到S9303交换机，查询配置后发现，到UGW和USN的端口都被配置成100M 不协商，这时候再登录到UGW，发现Gn物理口也都被配置成100M不协商的。由于UGW 物理端口既给LTE用，又作为GGSN的Gn口，在3G HSPA+测试时由于遇到下载速率问题，把1000M端口统一改成了100M后没有改回来，而LTE TDD 100M的DEMO下载业务所需理想的物理带宽为300M，导致LTE下载速率低且严重波动。 3. 问题分类： 传输参数 4. 解决方案
将两端端口改成自协商1000M
5. 效果评估
速率恢复到90Mbps，没有大波动。 6. 注意事项及建议
LTE TDD 峰值下载业务对带宽具有很高的要求，现网中如UGW同时应用于3G和LTE网络，必须要保证有足够的物理带宽，不能够简单累加，一定要留有足够的余量，否则很容易引起网络间的相互影响。
1.6核心网参数
1.6.1案例14：QCI设置错误导致演示厅LTE下行速率低问题
1. 现象描述
某LTE网络演示厅新建完成后，开展业务测试，发现下行速度只有7Mb左右，远未达到正常水平。 2. 问题分析
通过对S1口信令进行了跟踪，发现在S1AP-INITIAL-CONTEXT-SETUP-REQ中，虽然核心网侧指派的上下行带宽为150Mb， 但QCI值为5，下表是QCI所代表含义。
QCI 资源类型 优先级 GBR 2 4 分组数据分组数据业务举例 延时 丢包率 100ms 150ms 10-2 10-3 Conversational Voice Conversational (Live Streaming) Video 1 2 3 5 300ms 10-6 Non-Conversational Video (Buffered Streaming) Real Time Gaming IMS Signalling Voice, Video (Live Streaming) Interactive Gaming Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive 4 5 6 3 Non-GBR 1 6 50ms 100ms 100ms 10-3 10-6 10-3 7 8 9 7 8 9 300ms 10-6 QCI 资源类型 优先级 分组数据分组数据业务举例 延时 丢包率 video, etc.) 以上表可知QCI=5时，为IMS信令，而LTE一般用6-9作为缺省值，这时，6~9由于业务包含视频流业务，速率会达到较高值。 3. 问题分类：核心网参数 4. 解决方案
协调核心网侧工程师将开户信息中的QCI改为6。 5. 效果评估
下行速度恢复到70Mb，问题解决。 6. 注意事项及建议
QCI参数设置会影响下载速率。LTE对QoS进行了简化，使用QCI（QoS等级标识）代替了3G中的13种QoS参数，eNB可通过QCI推导出其对应的QoS参数，我们需要对LTE的QoS参数变化情况了解清楚，才能准确找到问题的根源。
1.7基站存在故障或告警
1.7.1案例15：室分场景多RRU合并后某一RRU驻波导致速率低
1. 现象描述
该室分采用4RRU合并为一个小区，编号为0，单流的组网形式，但在室内遍历测试过程中,发现某区域存在如下现象：当UE移动到某区域时发现速率下降明显，且无线环境良好(RSRP-80dBm左右，SINR39dB左右)，满调度，与测试速率好时为同一小区，但RB不足，下载速率一直较低（29Mbps左右）且稳定。 2. 问题分析
经后台查询，该小区存在射频单元驻波告警。 3. 问题分类： 故障 4. 解决方案 解决告警。 5. 效果评估
处理告警完毕后，对该小区进行定点下载测试，速率可达到55Mbps左右，下载速率恢复正常。
6. 注意事项及建议
小区合并后用户的调度将在独立调度和联合调度两者中自适应选择。当用户处于正常RRU下，且为独立调度时，对吞吐量是没有影响的；当UE处于两个RRU覆盖交叠区域时，为联合调度，且其中一个RRU有驻波，则会影响到另外一个RRU，影响整体测试结果；如果完全处理问题RRU下（驻波RRU），独立调度，测试速率也会受到影响。上述两种情况速率之所以会受到影响是由于为了保证数据传输的可靠性，系统降低了数据传输的RB数。
1.8其它类别
1.8.1案例16： LTE测试软件配置错误导致下载速率低
1. 现象描述
新建LTE基站进行单站优化，使用Filezilla进行FTP下载速率测试。在测试中，发现覆盖良好，RSRP在-90dBm左右，但下载速率极低，峰值下载速率6Mbps左右，平均下载速率低于5Mbps。 2. 问题分析
换测试电脑后，发现该站测试速率正常，由此推测是Filezilla软件设置问题；Filezilla软件设置里可以设置速度限制，如下图
3. 问题分类：软件参数 4. 解决方案
Filezilla软件速度限制部分设为不限速 5. 效果评估