LTE下载速率低原因及相关案例Word格式.docx
《LTE下载速率低原因及相关案例Word格式.docx》由会员分享，可在线阅读，更多相关《LTE下载速率低原因及相关案例Word格式.docx（24页珍藏版）》请在冰豆网上搜索。
通过闭站，看干扰是否消失排查。
1.1.1案例1：
系统外干扰（DCS1800）导致LTE宏站单小区下载速率低
1.现象描述
LTE基站1小区在测试过程中，发现下载速率低（1M左右），终端ping核心网侧丢包率高达50%。
该基站配置为S111，频段是F频段1880-1900MHz，带宽20M，参考信号功率12dBm，上下行时隙配比1:
3，特殊子帧时隙配置DwPTS:
GP:
UpPTS=3:
9:
2
2.问题分析
使用底噪查询工具。
各小区底噪情况如下：
将查询出的底噪值与各小区的业务速率对比，很容易看出业务速率低的小区恰好
是后台查询底噪高的小区。
由此判断为底噪高是导致空口质量差，引起终端业务速率低、ping包丢包率高的原因。
闭塞周边所有LTE小区,以及2、3小区全部闭塞，仅保留1小区，问题依然存在。
对1880-1900MHz扫频，发现移动DCS1800频段天线对该频段有干扰。
由于该LTE基站与37854昌平都市芳园DCS共址，基本确认干扰来自该基站。
接下来考虑为何2，3方向无明显干扰而1方向干扰明显，观察天线，发现2,3方向LTE天线与DCS天线水平隔离度1米左右，而1方向LTE与DCS天线水平隔离度仅0.4米左右。
3.问题分类：
干扰－DCS1800干扰
4.解决方案
改变1方向LTE天线位置，将其与DCS天线水平隔离度增加到1米。
5.效果评估
１小区天线与DCS天线水平隔离度增加到1米后，底噪-109，下载速率50M，故障排查完成。
6.注意事项及建议
故障排查流程：
1.1.2案例2：
服务小区与邻小区PCI存在mod3干扰造成下载速率过低
对某区域LTE网络进行评估测试时发现，当测试终端占用A小区后下载速率过
慢，下载速率只有10Mbps左右。
核查A小区PCI发现，该小区PCI与邻区B小区PCImod3值相等，A小区PCI
为15，B小区PCI为36，A、B小区之间存在mod3干扰。
在LTE中，PCI用来区分每一个小区，类似于WCDMA中的扰码和CDMA2000
中的PN。
LTE协议规定，PCI一共有504个，其组成分为两部分：
PhysicalLayerCellIdentity=（3×
NID1）+NID2
NID1:
物理层小区标识组，范围从0到167共168组（决定了辅同步序列）
NID2:
组内ID，范围从0到2（决定了主同步序列）然而，PCI也不是504个可以随意分配，它必须避免同一个小区覆盖范围内PCImod3不相等，其原因是因为不同的PCI决定了小区特定参考信号（CRS）的位置。
CRS用于终端辅助信道估计，其在子帧中的时频位置如下图所示：
当小区使用单天线端口传输模式，RS参考信号的位置为PICmod6。
当手机天线端口数为2信道Rank=2时,小区使用2天线传输模式，RS参考信号的位置为PICmod3。
在小区使用2天线传输模式且2个小区PCImod3数值相等，参考信号的位置重叠就会造成相互干扰，SINR值过低导致下载速率过慢。
干扰－模3干扰
修改A小区PCI为11
重新测试，A小区下载速率提升到55Mkbps以上。
下行参考信号在天线上发送的位置取决于小区PCI值，如果是单天线发送下行参考信号的位置为PCImod6，如果是两天线发送下行参考信号的位置为PCImod3。
如果PCI规划不当就会造成不同小区间参考信号干扰。
1.1.3案例3：
由GPS失锁引起的F频段LTE基站上行干扰
某基站通过话统查询上行底噪，发现此基站上行底噪很高，三个小区均在-77dB左右。
测试工程师到现场测试发现该小区无法正常接入，无法进行上下载业务。
经话统确认，此基站周围基站汇彩路、黄村大道、珠吉路底噪也较高，达到
-100dBm以上.连片区域基站存在干扰问题原因可能为：
GPS失锁或外部干扰。
协调代维人员进入基站机房，发现机房内存在两个BBU。
分别下挂东圃珠村和9860基站，均为TDDF频段基站，9860基站在工参表中未显示，此基站告警灯常闪，后台查询后，发现9860基站存在GPS失锁告警。
干扰—GPS失锁
闭塞9860基站，安排维护人员上站处理该基站的GPS失锁告警问题。
基站底噪下降到-110dBm以下，速率恢复正常
6.注意事项及建议
TDD-LTE上行干扰可能的问题原因：
（1）、移动DCS1800M小区频段为：
1805-1830M，1850-1872M；
所以此频段很容易对TDD-LTE频段1880-1900M形成阻塞干扰、互调干扰和杂散干扰。
（2）、GSM900M基站对TDD-LTE频段1880-1900M形成谐波干扰。
（3）、小灵通基站对TDD-LTE形成阻塞干扰、互调干扰和杂散干扰。
（4）、周围TDD-LTE基站GPS失锁形成干扰。
（5）、RRU硬件或天馈系统问题造成干扰。
（6）、外部干扰源干扰。
1.2容量
容量也会影响下载速率，现网由于LTE用户不多，暂不需考虑这方面的问题。
1.3无线参数配置
1.3.1案例4：
爱立信小区上下行时隙配比错误导致上行高BLER速率低
某日在进行簇优化过程中，进行上传业务时发现某站点的3个扇区的上传速率均
明显偏低，仅能达到约2~5Mbps，而在前期该站点的单站验证测试中，该站的上传速度正常，三个小区均达到了16Mbps左右；
在占用站点第1小区测试过程中，显示第1小区BLER较正常情况偏高，导致
MCS较低；
检查周边邻区的无线参数配置，经过核查发现该站点第3小区的
TDDframeconf=2，即时隙配比为3：
1，而周边基站均为2：
2；
无线参数配置
将第3小区参数TDDframeconf改为1，即时隙配比改2：
2
经测试三个小区SINR在24左右，上传速度均达到了15Mbps以上。
因LTE上行采用SC-FDMA，相对下行抗干扰能力较弱，在LTE建设过程中，需注意邻近小区上下行时隙配比准确一致，否则易对周边小区造成较强的上行干
扰。
后期网管搭建完毕后，需定期对小区做参数核查，确保参数配置无误
1.3.2案例5：
LTE的功率PA、PB参数设置不合理导致下载速率低的处理
LTE小区在覆盖较好路段（RSRP=-72dB,SINR=32dB，且传输模式为TM3）下载速率低（基本小于40Mbps）
查询该小区功率参数设置，发现PA参数设置为-3，PB参数设置为3，根据功率利用率分配表可知此时功率利用率仅为67％。
无线参数配置－功率参数
修改PB参数为1，使其利用率达到100%。
将PB参数修改为１后，对该路段验证测试，该路段PHYDLThroughput由
35Mbps提升至47Mbps，达到指标要求。
LTE下载速率低也需注意功率参数PA/PB的设定，其要求TypeA，TypeB两
类符号上的功率保持相等，当和相等且等于最大发射功率时，功率利用率最高。
LTE参数设置需考虑业务场景，根据不同的需求对参数进行合理化配置，已到达感知最优。
1.3.3案例6：
爱立信LTE小区DLTARGETBLER参数配置有误导致下行速率低
某站在进行簇优化过程中，进行FTP下载业务时发现某小区的下载速率均明显偏低，仅能达到约20Mbps左右，而在前期簇优化的拉网测试中，该站的下载速度正常，三个小区均达到了40Mbps左右。
在占用该小区测试过程中，观察发现下行调制方式中16QAM占比较高；
初步怀疑该小区下行速率低为调制方式没有全部采用64QAM导致。
核查该小区CV文件发现参DLTARGETBLER（下行目标ＢＬＥＲ）配置为1%；
当参数DLTARGETBLER（下行目标BLER）设置为1%时，由于对BLER要求过高，
导致RBS会调低MCS以保证BLER达到目标值。
而对于FTP、流媒体等并不需
要很高的BLER要求的业务，过高的BLER要求会导致下行因没有使用64QAM
的高阶调制方式，反而无法得到理想的下行速率，从而影响用户感知。
无线参数配置
将该小区参数DLTARGETBLER设置为10%
修改该参数后，复测FTP下载速率达到40Mbps左右，下行速率正常。
下载速率低时可以查看MCS为64QAM的比例高不高，占用高阶调制比例低并且BLER较低则可能是DLTARGETBLER设置的过小。
1.3.4案例7：
华为eNodeB升级8.0版本默认开启MR功能后导致速率低
华为ENodeB升级BTS3900V100R008C00SPC130后在外场拨打时发现上传及下载速率慢，CAT4测试终端在好点的情况下进行定点CQT测试，下载最高
速率仅在45Mbps左右，上传最高速率仅12Mbps左右。
通过后台跟踪UU口信令，发现终端在进行业务过程中会周期性上报
Meas_Report。
在无线环境很好的情况下，不应发生异频/异系统测量。
但测试结果表明：
终端在不停上报异频测量，并且是周期性上报。
对站点升级前后配置数据进行进一步核查，发现升级站点均默认开启了MR功能，在Nastar服务器上开启了同频/异频/异系统的订阅。
后台关闭同频/异频/异系统的订阅。
5.效果评估后台关闭订阅后再次进行复测，测试结果恢复正常。
升级版本后需注意核查前后配置数据找原因。
1.3.5案例8：
由于PDCCH信道误码率较高导致下载速率波动
渝北水木青华HL测试有两个现象：
（1）业务过程中出现业务中断的现象；
（2）业务过程速率不稳定，有比较严重的毛刺现象。
业务过程中出现业务中断的现象：
在正常业务过程中上行干扰不高，但是出现异常。
速率掉坑时候，上行RSSI达到－15db左右，突发的上行干扰很大，此时UE掉线并且频繁尝试重建，过一段时间后，干扰消失，业务恢复正常。
对测试数据进行分析，由于下行PDCCH偶尔出现误码率较高，上行也出现误码率较高的现象，导致下载速率出现波动。
进行扫频测试，确实发现存在一定的外部干扰，但未发现周边有TD站点等干扰源，只能采取参数优化来对问题进行解决。
修改下行PDCCHCCE聚合级别、PDCCH功率值，增强PDCCH下行信道抗干扰能力，上行Bler目标值收敛到5％。
5.效果评估通过参数用户增强信道的抗干扰能力，然后测试观察，速率已经稳定在70M以上，毛刺现象基本消失；
测试近1小时没有再出现掉坑的现象。
下载速率出现波动时出现下行PDCCH误码率较高，则需修改参数增强PDCCH信道的抗干扰能力。
1.3.6案例9：
TA同步功能未打开导致LTE下载速率抖降问题案例
在进行“TM3和TM8的小区吞吐量对比”的测试中，发现无论TM3还是TM8模式，在测试路线上某一固定点附近，都出现下载速率陡降的现象，在CDS对吞吐量的记录中，在该点出现深坑。
在RSRP及SINR均无明显变化的情况下，路测软件统计的PDCP吞吐量由22312.2Kbps，突降到666.1Kbps，下降幅度达97%，2-3秒钟后恢复正常。
通过核查后台参数，发现测试中关闭了TA同步功能（通过配置开关控制）。
此参数被关闭的话会导致终端无法调整上行同步位置，使基站接收到的上行
PUCCH数据（ack/Nack）超出接收窗，接收数据错误，造成下行速率陡降。
下行吞吐量陡降是由于PUCCH上携带的反馈ACK被译错为NACK，基站认为下行bler高，会将MCS等级调低导致。
将TA同步功能参数打开
将TA同步功能找开后，下载速率正常，不再出现速率陡降情况。
速率陡降的情况，可以考虑查看TA同步功能是否打开。
1.4传输问题
1.4.1案例10：
LTE传输问题导致小区下载速率低
收到某公寓下LTE下载速率慢的投诉，安排人员现场测试验证：
投诉点位于宏站辉煌公寓-HLH-1小区覆盖范围，在无线环境较好的条件下（RSRP=-90dBm，SINR=25），利用省公司120.202.251.18服务器做FTP下载，下行速率约10-15mbps，低于该空口环境下的正常预期（SINR>
25，DLTHR>
45mbps），
确认辉煌公寓-HLH-1小区确实存在下载速率低问题
1、利用LTE核心网EPC内网服务器对辉煌公寓小区入网终端UE进行40mbps带宽的UDP灌包测试；
在基站侧对传输PTN来包流量做实时统计，基站侧收包带宽为15mbps左右；
在UE终端侧通过测试软件查看收包带宽也为15mbps左右。
通过该步骤，确认速率低问题是在基站侧以上网元引入。
2、利用LTE核心网EPC内网服务器对火车站综合楼室分小区入网终端UE进行40mbps带宽的UDP灌包测试；
在基站侧对传输PTN来包流量做实时统计，基站侧收包带宽为40mbps左右；
在UE终端侧通过测试软件查看收包带宽也为40mbps左右。
通过该步骤，进一步确认速率低问题为EPC至辉煌公寓基站间的PTN传输网元引入。
传输
协调传输排除故障。
速率恢复正常。
针对下行吞吐率不达标的问题，按照相关指导书进行逐步核查；
涉及到非空口原因导致的调度不足以及吞吐率较低问题，应通过基本手段初步判断问题原因，再求助相关模块进行进一步确认并及时处理；
针对基站传输类告警，不容易发现，建议通过基站层显示出来，便于及时发现并及时处理。
1.5传输参数问题
1.5.1案例11：
PTNQOS参数限制导致LTE下载速度低案例
1.现象描述某日在对某小区进行单站验证的过程中，对该小区进行定点的上传和下载业务，发现即使在覆盖“极好点”，该站的下载速度依旧只有8~10Mbps，达不到测试用例的要求。
使用jperf，对传输进行推送测试，发现主要问题应该在传输上，由于传输的限制导致下载速度最大只能达到10Mbps。
最终核查发现华为在PTN上做了些QOS的配置，根据不同业务限制了最高带宽，对下载业务带宽为10M，这样导致了下载的限制。
传输参数
改变了PTN上的QOS配置的参数限制
进行下载验证，结果显示恢复正常，达到30Mbps以上，符合用例需求。
PTN上的QOS配置参数限制可能导致下载速率低。
1.5.2案例12：
PTN侧MAC地址学习功能未配置导致LTE基站FTP下载速率低
某地TD-LTE实验网，部分基站进行迅雷下载时，速率能够稳定达到60Mbps，但采用FTP下载时最小速率仅几Mbps，并且出现频繁的速率波动。
2.问题分析本次实验网分析中迅雷下载速率较高，说明无线环境、容量、时隙配比、传输带宽和速率相关无线参数设置均没有问题。
而迅雷下载采用的是UDP协议，FTP
下载采用的TCP协议。
UDP与TCP协议主要区别在超时重发机制上，根据这种区别初步怀疑PTN传输侧有丢包。
采用wireshark软件进行S1抓包分析，发现大量的数据包重传。
传输站点未发现告警，且LTE基站各个传输链路光功率
收发均正常，未存在光路衰减情况。
查询传输相关参数配置，发现速率异常的
LTE站点对应的PTN设备MAC地址学习功能未配置。
传输参数
为速率异常站点配置PTN设备MAC地址学习功能。
FTP下载速率恢复正常。
PTN上的MAC地址学习功能未配置可能导致下载速率低。
1.5.3案例13：
由交换机端口配置不正确导致LTETDD下载速率波动问题
在某LTETDD100M峰值下载业务验证中，发现FTP下载业务速率严重波动，从10Mpbs到60Mbps波动，平均速率仅有25Mbps左右，用wireshark工具抓包，可以看到大量重传。
由于所有设备搬迁过一次，而在之前的测试中，峰
检查交换机配置：
登录到S9303交换机，查询配置后发现，到UGW和USN的端口都被配置成100M不协商，这时候再登录到UGW，发现Gn物理口也都被配置成100M不协商的。
由于UGW物理端口既给LTE用，又作为GGSN的Gn口，在3GHSPA+测试时由于遇到下载速率问题，把1000M端口统一改成了100M后没有改回来，而LTETDD100M的DEMO下载业务所需理想的物理带宽为300M，导致LTE下载速率低且严重波动。
将两端端口改成自协商1000M
速率恢复到90Mbps，没有大波动。
LTETDD峰值下载业务对带宽具有很高的要求，现网中如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=5时，为IMS信令，而LTE一般用6-9作为缺省值，这时，6~9由于业务包含视频流业务，速率会达到较高值。
核心网参数
4.解决方案协调核心网侧工程师将开户信息中的QCI改为6。
下行速度恢复到70Mb，问题解决
QCI参数设置会影响下载速率。
LTE对QoS进行了简化，使用QCI（QoS等级标识）代替了3G中的13种QoS参数，eNB可通过QCI推导出其对应的QoS参数，我们需要对LTE的QoS参数变化情况了解清楚，才能准确找到问题的根源。
1.7基站存在故障或告警
1.7.1案例15：
室分场景多RRU合并后某一RRU驻波导致速率低
该室分采用4RRU合并为一个小区，编号为0，单流的组网形式，但在室内遍历测试过程中,发现某区域存在如下现象：
当UE移动到某区域时发现速率下降明显，且无线环境良好（RSRP-80dBm左右，SINR39dB左右），满调度，与测试速率好时为同一小区，但RB不足，下载速率一直较低（29Mbps左右）且稳定。
2.问题分析经后台查询，该小区存在射频单元驻波告警。
4.解决方案
解决告警。
5.效果评估处理告警完毕后，对该小区进行定点下载测试，速率可达到55Mbps左右，下载速率恢复正常。
6.注意事项及建议小区合并后用户的调度将在独立调度和联合调度两者中自适应选择。
当用户处于正常RRU下，且为独立调度时，对吞吐量是没有影响的；
当UE处于两个RRU覆盖交叠区域时，为联合调度，且其中一个RRU有驻波，则会影响到另外一个RRU，影响整体测试结果；
如果完全处理问题RRU下（驻波RRU），独立调度，测试速率也会受到影响。
上述两种情况速率之所以会受到影响是由于为了保证数据传输的可靠性，系统降低了数据传输的RB数。
1.8其它类别
1.8.1案例16：
LTE测试软件配置错误导致下载速率低
新建LTE基站进行单站优化，使用Filezilla进行FTP下载速率测试。
在测试中，
发现覆盖良好，RSRP在-90dBm左右，但下载速率极低，峰值下载速率6Mbps左右，平均下载速率低于5Mbps。
换测试电脑后，发现该站测试速率正常，由此推测是Filezilla软件设置问题；
Filezilla软件设置里可以设置速度限制，如下图
软件参数
Filezilla软件速度限制部分设为不限速
Filezilla软件设置不限速后，下载速率恢复正常，平均下载速
升级会员 