1.LTE下载速率低原因及相关案例

现阶段排查LTE下载速率低影响的主要因素包括：

（1）无线环境

（2）容量

（3）无线参数配置

（4）传输问题

（5）传输相关参数配置

（6）故障

（7）传输相关参数配置

1.1无线环境

无线环境是影响下载速率低的一个重要原因。现网中由于多系统的存在，会对空口传输质量造成影响。

无线系统按照干扰产生的起因可以将干扰分为系统内干扰和系统间干扰。 

系统内干扰：系统内干扰通常为同频干扰。TD-LTE 系统中，系统内干扰常见原因有小区越区覆盖造成的同频干扰和GPS时钟不同步造成的下行信号对上行信号的干扰和模三干扰。 

系统间干扰的产生：系统间干扰通常为异频干扰。主要有：杂散干扰、阻塞干扰、谐波干扰、互调干扰。通过LTE前期总结系统间干扰的干扰主要如下：

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.问题分析

使用底噪查询工具。各小区底噪情况如下：

闭塞周边所有 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 干扰造成下载速率过低

1.现象描述

对某区域LTE网络进行评估测试时发现，当测试终端占用A小区后下载速率过慢，下载速率只有10Mbps左右。

2.问题分析

核查A小区PCI发现，该小区PCI与邻区B小区PCI mod3值相等，A小区PCI为15，B小区PCI为36，A、B小区之间存在mod3 干扰。

在LTE中，PCI用来区分每一个小区，类似于WCDMA中的扰码和CDMA2000中的PN。LTE协议规定，PCI一共有504个，其组成分为两部分：

Physical Layer Cell Identity = (3 × NID1) + NID2

NID1: 物理层小区标识组， 范围从0 到167共168组（决定了辅同步序列）

NID2: 组内ID， 范围从 0 到 2（决定了主同步序列）

 然而，PCI也不是504个可以随意分配，它必须避免同一个小区覆盖范围内PCI mod3不相等，其原因是因为不同的PCI决定了小区特定参考信号（CRS）的位置。

CRS用于终端辅助信道估计，其在子帧中的时频位置如下图所示：

当小区使用单天线端口传输模式，RS参考信号的位置为PIC mod 6。当手机天线端口数为2信道Rank=2时,小区使用2天线传输模式，RS参考信号的位置为PIC mod 3。在小区使用2天线传输模式且2个小区PCI mod3 数值相等，参考信号的位置重叠就会造成相互干扰，SINR值过低导致下载速率过慢。

3.问题分类： 干扰－模3干扰

4.解决方案

修改A小区PCI为11

5.效果评估

重新测试，A小区下载速率提升到55Mkbps以上。

6.注意事项及建议

下行参考信号在天线上发送的位置取决于小区PCI值，如果是单天线发送下行参考信号的位置为PCI mod 6，如果是两天线发送下行参考信号的位置为PCI mod3。如果PCI规划不当就会造成不同小区间参考信号干扰。

1.1.3案例3： 由GPS失锁引起的F频段LTE基站上行干扰

1.现象描述

某基站通过话统查询上行底噪，发现此基站上行底噪很高，三个小区均在-77dB左右。测试工程师到现场测试发现该小区无法正常接入，无法进行上下载业务。

2.问题分析

经话统确认，此基站周围基站汇彩路、黄村大道、珠吉路底噪也较高，达到-100dBm以上.连片区域基站存在干扰问题原因可能为：GPS失锁或外部干扰。协调代维人员进入基站机房，发现机房内存在两个BBU。分别下挂东圃珠村和9860基站，均为TDD  F频段基站，9860基站在工参表中未显示，此基站告警灯常闪，后台查询后，发现9860基站存在GPS失锁告警。

3.问题分类： 干扰—GPS失锁

4.解决方案

闭塞9860基站，安排维护人员上站处理该基站的GPS失锁告警问题。

5.效果评估

基站底噪下降到-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速率低

1.现象描述

某日在进行簇优化过程中，进行上传业务时发现某站点的3个扇区的上传速率均明显偏低，仅能达到约2~5Mbps，而在前期该站点的单站验证测试中，该站的上传速度正常，三个小区均达到了16Mbps左右；

2.问题分析

在占用站点第1小区测试过程中，显示第1小区BLER较正常情况偏高，导致MCS较低；检查周边邻区的无线参数配置，经过核查发现该站点第3小区的TDDframeconf=2，即时隙配比为3：1，而周边基站均为2：2；

3.问题分类： 无线参数配置

4.解决方案

将第3小区参数TDDframeconf改为1，即时隙配比改2：2

5.效果评估

经测试三个小区SINR在24左右，上传速度均达到了15Mbps以上。

6.注意事项及建议

因LTE上行采用SC-FDMA，相对下行抗干扰能力较弱，在LTE建设过程中，需注意邻近小区上下行时隙配比准确一致，否则易对周边小区造成较强的上行干扰。后期网管搭建完毕后，需定期对小区做参数核查，确保参数配置无误。

1.3.2案例5：LTE的功率PA、PB参数设置不合理导致下载速率低的处理

1.现象描述

LTE小区在覆盖较好路段（RSRP=-72dB,SINR=32 dB，且传输模式为TM3）下载速率低（基本小于40Mbps）

2.问题分析

查询该小区功率参数设置，发现PA参数设置为-3，PB参数设置为3，根据功率利用率分配表可知此时功率利用率仅为67％。

4.解决方案

修改PB参数为1，使其利用率达到100%。

5.效果评估

将PB参数修改为１后，对该路段验证测试，该路段PHY DL Throughput 由35Mbps提升至47Mbps，达到指标要求。

6.注意事项及建议

LTE下载速率低也需注意功率参数PA/PB的设定，其要求Type A，Type B两类符号上的功率保持相等，当和相等且等于最大发射功率时，功率利用率最高。LTE参数设置需考虑业务场景，根据不同的需求对参数进行合理化配置，已到达感知最优。

1.3.3案例6：爱立信LTE小区DLTARGETBLER参数配置有误导致下行速率低

1.现象描述

某站在进行簇优化过程中，进行FTP下载业务时发现某小区的下载速率均明显偏低，仅能达到约20Mbps左右，而在前期簇优化的拉网测试中，该站的下载速度正常，三个小区均达到了40Mbps左右。

2.问题分析

在占用该小区测试过程中，观察发现下行调制方式中16QAM占比较高；初步怀疑该小区下行速率低为调制方式没有全部采用QAM导致。核查该小区CV文件发现参DLTARGETBLER（下行目标ＢＬＥＲ）配置为1%；

当参数DLTARGETBLER(下行目标BLER) 设置为1%时，由于对BLER要求过高，导致RBS会调低MCS以保证BLER达到目标值。而对于FTP、流媒体等并不需要很高的BLER要求的业务，过高的BLER要求会导致下行因没有使用QAM的高阶调制方式，反而无法得到理想的下行速率，从而影响用户感知。

3.问题分类：无线参数配置

4.解决方案

将该小区参数DLTARGETBLER设置为10%

5.效果评估

修改该参数后，复测FTP下载速率达到40Mbps左右，下行速率正常。

6.注意事项及建议

下载速率低时可以查看MCS为QAM的比例高不高，占用高阶调制比例低并且BLER较低则可能是DLTARGETBLER设置的过小。

1.3.4案例7：华为eNodeB升级8.0版本默认开启MR功能后导致速率低

1.现象描述

华为ENodeB升级BTS3900 V100R008C00SPC130后在外场拨打时发现上传及下载速率慢，CAT4测试终端在好点的情况下进行定点CQT测试，下载最高速率仅在45Mbps左右，上传最高速率仅12Mbps左右。

2.问题分析

通过后台跟踪UU口信令，发现终端在进行业务过程中会周期性上报Meas_Report。在无线环境很好的情况下，不应发生异频/异系统测量。但测试结果表明：终端在不停上报异频测量，并且是周期性上报。对站点升级前后配置数据进行进一步核查，发现升级站点均默认开启了MR功能，在Nastar服务器上开启了同频/异频/异系统的订阅。

3.问题分类：无线参数配置

4.解决方案

后台关闭同频/异频/异系统的订阅。

5.效果评估

后台关闭订阅后再次进行复测，测试结果恢复正常。

6.注意事项及建议

升级版本后需注意核查前后配置数据找原因。 

1.3.5案例8：由于PDCCH信道误码率较高导致下载速率波动

1.现象描述

渝北水木青华HL测试有两个现象：

（1）业务过程中出现业务中断的现象；

（2）业务过程速率不稳定，有比较严重的毛刺现象。

业务过程中出现业务中断的现象：在正常业务过程中上行干扰不高，但是出现异常。速率掉坑时候，上行RSSI达到－15db左右，突发的上行干扰很大，此时UE掉线并且频繁尝试重建，过一段时间后，干扰消失，业务恢复正常。

2.问题分析

对测试数据进行分析，由于下行PDCCH偶尔出现误码率较高，上行也出现误码率较高的现象，导致下载速率出现波动。进行扫频测试，确实发现存在一定的外部干扰，但未发现周边有TD站点等干扰源，只能采取参数优化来对问题进行解决。

3.问题分类：无线参数配置

4.解决方案

修改下行PDCCH CCE聚合级别、PDCCH功率值，增强PDCCH下行信道抗干扰能力，上行Bler目标值收敛到5％。

5.效果评估

通过参数用户增强信道的抗干扰能力，然后测试观察，速率已经稳定在70M以上，毛刺现象基本消失；测试近1小时没有再出现掉坑的现象。

6.注意事项及建议

下载速率出现波动时出现下行PDCCH误码率较高，则需修改参数增强PDCCH信道的抗干扰能力。

1.3.6案例9：TA同步功能未打开导致LTE下载速率抖降问题案例

1.现象描述

在进行“TM3和TM8的小区吞吐量对比”的测试中，发现无论TM3还是TM8模式，在测试路线上某一固定点附近，都出现下载速率陡降的现象，在CDS对吞吐量的记录中，在该点出现深坑。在RSRP及SINR均无明显变化的情况下，路测软件统计的PDCP吞吐量由22312.2Kbps，突降到666.1Kbps，下降幅度达97%，2-3秒钟后恢复正常。

2.问题分析

通过核查后台参数，发现测试中关闭了TA同步功能（通过配置开关控制）。此参数被关闭的话会导致终端无法调整上行同步位置，使基站接收到的上行PUCCH数据（ack/Nack）超出接收窗，接收数据错误，造成下行速率陡降。

下行吞吐量陡降是由于PUCCH上携带的反馈ACK被译错为NACK，基站认为下行bler高，会将MCS等级调低导致。

3.问题分类：无线参数配置

4.解决方案

将TA同步功能参数打开

5.效果评估

将TA同步功能找开后，下载速率正常，不再出现速率陡降情况。

6.注意事项及建议

速率陡降的情况，可以考虑查看TA同步功能是否打开。

1.4传输问题

1.4.1案例10： LTE 传输问题导致小区下载速率低

1.现象描述

收到某公寓下LTE下载速率慢的投诉，安排人员现场测试验证：投诉点位于宏站辉煌公寓-HLH-1小区覆盖范围，在无线环境较好的条件下（RSRP=-90dBm，SINR=25），利用省公司120.202.251.18服务器做FTP下载，下行速率约10-15mbps，低于该空口环境下的正常预期（SINR>25，DL THR>45mbps），确认辉煌公寓-HLH-1小区确实存在下载速率低问题。

2.问题分析

1、利用LTE核心网EPC内网服务器对辉煌公寓小区入网终端UE进行40mbps带宽的UDP灌包测试；在基站侧对传输PTN来包流量做实时统计，基站侧收包带宽为15mbps左右；在UE终端侧通过测试软件查看收包带宽也为15mbps左右。通过该步骤，确认速率低问题是在基站侧以上网元引入。

2、利用LTE核心网EPC内网服务器对火车站综合楼室分小区入网终端UE进行40mbps带宽的UDP灌包测试；在基站侧对传输PTN来包流量做实时统计，基站侧收包带宽为40mbps左右；在UE终端侧通过测试软件查看收包带宽也为40mbps左右。通过该步骤，进一步确认速率低问题为EPC至辉煌公寓基站间的PTN传输网元引入。

3.问题分类：传输 

4.解决方案

协调传输排除故障。

5.效果评估

速率恢复正常。

6.注意事项及建议

针对下行吞吐率不达标的问题，按照相关指导书进行逐步核查；涉及到非空口原因导致的调度不足以及吞吐率较低问题，应通过基本手段初步判断问题原因，再求助相关模块进行进一步确认并及时处理；针对基站传输类告警，不容易发现，建议通过基站层显示出来，便于及时发现并及时处理。

1.5传输参数问题

1.5.1案例11： PTN QOS参数导致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所代表含义。 

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.效果评估

Filezilla软件设置不限速后，下载速率恢复正常，平均下载速率大于50Mbps

6.注意事项及建议

换新电脑测试前，Filezilla软件设置需要注意。

1.8.2案例17： 由于合路器接法不正确引起的下载速率低的问题

1.现象描述

对上合村北FE站点进行单验，在进行单站验收时，单用户下行吞吐率最大值只有39mbps左右，MCS正常，终端信号质量较好，速率稳定，从probe上看到终端一直上报RANK1,没有RANK2上报。该站点使用2T2R与GSM合路共天馈，该问题定位涉及硬件排查，最终将问题锁定在合路器上。

2.问题分析

分别对2通道单独测试，单通道测试结果都可以达到峰值吞吐量，说明2通道都正常。由于终端上报RANK2要求接收到的两天线信号的相关性要求越低越好，而从几次测试结果都发现RxChCorFactor系数基本大于0.5，由此推测两天线的2通道相关性太强导致终端始终上报RANK1，需上站进行天馈系统的排查。

该站点与GSM合路，GSM两个天线口和LTE两个天线口接入一个4路合路器，合路后接到2天线口的天线，天线型号支持+/-45°双极化。现场直接使用测试小天线接到LTE的RRU射频口，进行测试，终端可以进入RANK2，且峰值吞吐量可以达到60Mbps，由此基本可以确认合路之后导致终端无法进入双流RANK2。

先单独取一个小区进行排查，确认问题根源是否在合路器上面。首先，从合路器前端馈线的接法着手，单独排查2小区合路器前端馈线的接法是否正确，整改前合路器前端馈线的连接示意图如下：

整改后合路器前端馈线的连接示意图如下：

3.问题分类： 硬接连接

4.解决方案

调整合路器接线。

5.效果评估

复测2小区RANK指示为RANK2，下载速率提升至40Mbps以上。

6.注意事项及建议

通过本案例，可以看到天馈系统的问题对LTE网络性能影响比较明显。针对目前LTE很多都和原有系统进行合路的现状，要着重注意合路之后的影响，重点关注合路器接法是否正确，避免因小失大。

1.8.3案例18： LTE室分双路不平衡导致下载速率低

1.现象描述

在某LTE站进行单站验证测试，测试发现上传速率只有9M，没达到目标值，下载速率波动较大平均速率为58M

2.问题分析

从测试中发现，接收的两个天线通道功率相差较大，导致下载速率波动较大。

该室分为双流模式，其中1号端口利用原来的室分系统，另外0号端口为新建室分系统，室分设计图如下：

根据如上室分设计图可以看出，利旧室分系统的通道多一个耦合器，另外旧的室分系统存在损耗，导致新建室分系统通道较利旧室分通道天线口功率强。

3.问题分类： 硬件

4.解决方案

现场在新建室分系统增加6db的衰减器

5.效果评估

在新建室分系统增加6db的衰减器后进行测试，上传速率和下载速率都达到目标值，其中上传速率为15.84M，下载速率较平稳为79.52M。

6.注意事项及建议

双流室分场景往往是在以前单流室分的基础上新增1路室分系统建设而成，这样先前的单流室分由于使用时间较长，存在老化或设计缺陷，与新建的1路室分达不到链路平衡，造成了双流场景只有单流的速率，双流站点两个通道的平衡性要求电平差值在5db以内，否则速率不达标可以判定为两条链路不平衡，需进行室分整改。

同时，双流场景下对两条链路的隔离度也有要求，建议室分天线点位间距不要太近或太远，距离约为1.5米性能最好。

2.LTE基站小区无法建立或建立异常问题及案例

2.1无线参数配置

2.1.1案例1：GPS数据配置错误导致LTE TDD无法正常开通的案例

1.现象描述

新建LTE基站开通时，发现小区总是无法激活，小区激活时，告警信息为“Clock resource is not usable”。

2.问题分析

从“Clock resource is not usable”告警信息来看，我们初步判断为时钟问题。查看当前GPS的时钟源状态，执行：DSP CLKSTAT，该基站的时钟模式设置为了FREQ频率同步，由于LTE TDD系统是时分双工系统，对时钟精度要求很高，要求时间同步。

3.问题分类： 无线参数配置－GPS数据配置

4.解决方案

将时钟源的同步模式修改为时间同步

5.效果评估

修改时钟源模式后，基站能正常开通。

6.注意事项及建议

在出现时钟源告警时，需核查：

(1)时钟源是否可用

(2)时钟源工作模式是否正确以及跟踪的GPS卫星数目，GPS时钟源工作模式是否为GPS，跟踪的GPS卫星数目是否大于４；

(3)GPS时钟的底层配置参数；时钟编号，柜框槽号及馈线类型都配置正确。

(4)GPS的时钟源状态是否为锁定以及同步模式是否正确；

2.1.2案例2：LTE宏站小区CRS端口配置错误导致小区无法建立

1.现象描述

通过巡检网管，发现TDL侧第三小区上报“小区不可用告警”，而在TDS侧，却没有发现任何异常告警。

2.问题分析

在TDL侧了除小区不可用告警外无其它告警，且TDS侧的小区和载波也都正常建立，无任何告警，并且功率不存在不足问题，通过网管查询发现小区建立失败原因是 配置BBI模块失败。怀疑可能是基带板运行异常，重新复位和更换基带板后小区仍建立失败，故障依旧，也排除基带板硬件故障。仔细检查数据后发现，问题小区有1个默认参数配置错误，如下图：

3.问题分类： 无线参数配置

4.解决方案

修改该宏站小区参考信号端口数为２

5.效果评估

修改后激活小区，小区成功建立

6.注意事项及建议

根据协议约束，小区参考信号端口数支持1、2、4三种配置：取值为1表示配置CRS端口数为1，即逻辑天线Port0；取值为2表示配置CRS端口数为2，即逻辑天线Port0/1；取值为4表示配置CRS端口数为4，即逻辑天线Port0/1/2/3。一般而言，室分1T1R小区模板默认的CRS接口是配置为1；而室外宏站的CRS接口配置为2。做数据或修改参数时，要注意这点。

2.1.3案例3： LTE小区与RRU关联错误导致覆盖接反

1.现象描述

TDS与TDL分别对某LTE站点作单站验证，TDL判断1、3小区存在接反，同比TDS环测数据发现并无此问题。

2.问题分析

TDS侧无天馈接反问题，故怀疑是TDL小区数据配置错误，OMC后台查询该站TD-LTE和TD-SCDMA网络射频单元RRU的框号，发现TD-LTE小区关联的RRU与TD-SCDMA不一致。初步判定LTE天馈接反的问题由小区关联的RRU框号配置错误导致。

3.问题分类：无线参数配置

4.解决方案

OMC后台修改LTE小区关联的RRU框号

5.效果评估

修改TDL框号与TD-SCDMA一致后，对该站进行复测，问题解决。

6.注意事项及建议

(1)、参数配置时，LTE网络的RRU的框号配置应与TD-SCDMA一致；

(2)、涉及到TD-LTE与TD-SCDMA共址基站天馈接反的问题，首先应核查两个系统是否都存在该类问题，顺藤摸瓜，找到问题的根因并处理。

2.1.4案例4：LTE基站eNodeB ID标识不唯一导致基站S1偶联链路频繁规律闪断 

1.现象描述

LTE新建站S1链路不能正常建链，频繁规律闪断。具体现象为：S1链路建立成功，几秒钟后断链，然后间隔4、5秒恢复，约7、8秒后，再次断链，如此反复。

2.问题分析

通过基站抓包分析，S1建立成功后，基站与EPC之间还有心跳通讯，但EPC突然发出ABORT，打开ABORT查看，可以看出源地址是EPC的SCTP地址，所以释放请求时是由EPC发出，ABORT的原因为6，“停止报文的处理”，由此判断，是EPC侧主动发起的异常终止。

由于EPC突然释放偶联，协调EPC的工程师进行跟踪并解析原因。EPC工程师经过跟踪EPC信令，给出的释放的原因为：Abort the another assoc, may be the eNBGlobalID[61540 :65280 :10016 ] is conflict

根据EPC返回的结果可以判断次故障是由于eNodeBID在EPC侧冲突引起，最终发现在EPC中有两个站eNodeBID相同。

3.问题分类：无线参数配置

4.解决方案

修改该站eNodeBID为规划唯一ID;

5.效果评估

修改该站eNodeBID后恢复正常。

6.注意事项及建议

制作eNodeBID时需谨慎；

2.1.5案例5：大唐和华为GTP-U检测功能参数协商不一致导致LTE站点业务频繁中断

1.现象描述

武汉LTE站点下测试业务时候发现，在终端成功附着成功30分钟左右后，就出现无法ping通内外服务器和连接的情况，多用户附着成功后，也会在间隔30分钟左右的时间同时出现上述现象；武汉LTE示范站点对接的为华为公司的核心网，咨询华为公司核心网人员，其他厂家未出现该问题，初步断定是大唐E-NODEB和华为核心网之间协商参数存在不一致情况导致检测异常。

2.问题分析

大唐E-NODEB关闭了GTP-U检测功能，而华为核心网侧打开了GTP-U路径探测功能。SGW在用户激活后，会检测GTP-U路径是否中断，发出路径检测的ECHO消息，如果没有收到E-NODEB的回复，重发5次后产生数据路径断的告警，路径中断后，核心网会继续探测用户的GTP-U路径，每隔60秒发送一个ECHO消息，重复20次后（定时器超时），如果路径仍未恢复，就去激活上下文，将用户PDP上下文删除，并对用户后续的上行报文给E-NODEB回复Error Indication消息，以指示E-NODEB删除用户上下文；这个周期在30分钟左右。 

3.问题分类：无线参数配置

4.解决方案

华为核心网侧SGW上关闭了GTP-U路径探测功能；

大唐E-NODEB将GTP-U功能设置为可控开关，这样在配合现网各个核心网厂商需求时，可以根据客户和友商的要求设置为打开或关闭。

5.效果评估

问题解决。

6.注意事项及建议

异厂家设备对接过程中，参数协商未统一会出现问题。

2.1.6案例6：由于TDS频点设置问题导致LTE基站无法开启的案例

1.现象描述

黄冈小池LTE基站开通时，总是出现上行频点生效失败提示，因此，LTE小区无法激活。

2.问题分析

查询共站TDS的频点信息，发现有9492这个频点，换算以后是18.4M。该频点正是LTE所使用的F频段包含的频点。在增加TDS载波时未考虑双模改造LTE的站点。

原TDS侧配置频点为：10121，9492，9543，10086，10093.

LTE频点设置为:38350.

TDS和TDL侧频段存在包含关系。

3.问题分类：无线参数配置

4.解决方案

将9492频点的载波去激活。通过规划将9492改为10079。然后重新激活改TDS载波。

5.效果评估

将9492频点的载波去激活后，LTE小区能正常建立。

6.注意事项及建议

在做规划时，避免出现TDS和TDL侧频段存在包含关系，否则，很容易出现类似问题。

3.LTE切换问题及案例

3.1覆盖

3.1.1案例1： 由于弱覆盖导致成都理工大学LTE小区1与音乐公园LTE小区2切换失败案例

1.现象描述

成都理工大学LTE站点小区1切换到站点成都音乐公园小区2过程中，未完成切换流程就出现重建，导致切换失败，业务中断几秒后，UE重建接入音乐公园小区2中，数传恢复。

2.问题分析

从覆盖角度考虑，如果在切换点上存在着覆盖问题，在某区域上某个方向上由于建筑物等的遮挡，导致UE在该区域内出现信号质量的大幅抖动，切换失败。

从现场来看，切换点区域是处于目标小区覆盖信号很弱的拐角点，天线到该位置的直线空间里有一座较高的楼房，一直怀疑该楼房的阻挡影响信号覆盖。从消息跟踪结果来看，在UE测量到目标小区的RSRP比服务小区的RSRP差值超过切换门限发出测量报告，但是源小区信号质量下降太快没有收到测量报告，从而使UE只能在目标小区发起随机接入过程。

3.问题分类： 无线

4.解决方案

通过调整切换相关参数，提前进入切换流程，原小区默主认小区偏置为０dB，将邻区的小区偏置修改成1dB~2dB 

5.效果评估

修改小区偏置后，切换正常

6.注意事项及建议

在现实场景下，往往会出现许多切换过晚现象，可以通过调整切换相关参数配置来提前切换达到解决切换失败的目的。

参数修改过程有一个注意的问题是，修改切换门限和切换迟滞时间固然也可以达到提前切换的目的，但是因为这两个参数都属于小区级参数，一旦修改，将会造成和所有邻区的切换点发生改变，因此修改后风险较大，大多数情况下都不应修改，因此一般可以通过修改CIO配置参数达到相同的目的，而其只对特定的小区有影响。

3.2无线参数配置

3.2.1案例2：爱立信LTE小区DCI配置错误导致切换失败

1.现象描述

在进行簇优化过程中，进行FTP下载业务时发现在路测过程中切向某小区时出现切换失败，更换源小区无改善，而在前期簇优化的拉网测试中，该小区切换正常。

2.问题分析

前期测试终端为海斯数据卡，本次测试使用创毅Warpdrive5000芯片，目前包含Warpdrive5000芯片在内的多种芯片尚不支持PDCCH DCI Format 1C，而爱立信基站PDCCH DCI  Format默认为1C

3.问题分类：无线参数配置

4.解决方案

联系后台核查该小区PDCCH DCI Format，经核查该小区前期基站复位后DCI  Format为 1C，修改为目前全网设置的1A。

5.效果评估

修改该小区该小区PDCCH DCI Format后，对该小区进行复测，多次复测切换均成功，无异常。

6.注意事项及建议

3GPP协议里在36.212的5.3.3.1里对PDCCH的DCI Format定义为：

 Format 1A:用于下行传输，单码字PDSCH调度，下行数据触发随机接入过程；

Format 1C:用于紧凑型单码字PDSCH调度

目前青岛LTE为试验网，网络整体出于空载状态，全网DCI Format均采用1A。TD-LTE也处于发展初期，很多终端芯片尚不健全，对PDCCH DCI Format 支持不全面。如果后期试商用，需提前针对商用终端进行评估，避免部分终端对协议支持不完善影响用户感知。

3.2.2案例3：开启防乒乓切换开关导致不切换

1.现象描述

从Ａ小区向Ｂ小区切换的过程中，在目标小区Ｂ驻留约2秒后，由于拐角RSRP波动，满足A3事件触发条件，UE上报A3事件的MR后，未收到ENB下发的带有MobilityControlInfo信息的RRCConnectionReconfiguration消息，无法完成切换最终导致UE发起小区重选，业务中断。

2.问题分析

检查小区B的切换算法配置(小区>小区算法>切换)如下，防用户乒乓切换开关为打开，用于判断乒乓切换的目标小区停留时间门限为5秒，即如果由A小区切后B小区后，5秒内如果UE上报MR中为A小区，基站判断此次切换为乒乓切换，而导致切换判决不通过，空口直观表现为上报MR但无法切换，或切换过慢。

3.问题分类：无线参数配置

4.解决方案

而实际的某些优化场景中，必须要发生乒乓切换才能保证业务连续性。针对类似场景从用户感知出发，可以考虑关闭防乒乓切换算法，或降低乒乓切换判断时间以允许乒乓切换。

5.效果评估

关闭防乒乓切换算法，或降低乒乓切换判断时间,切换成功。

6.注意事项及建议

乒乓切换对速率、掉线率和信令负荷都会有一定影响，应当尽量避免发生乒乓切换。抑制乒乓切换有效的方法有：

       >控制好覆盖，合理设置切换带；

       >适当调整A3参数（迟滞、偏移值、触发时延），以及CIO；

       >合理应用防乒乓切换算法。

3.2.3案例4： 由切换门限设置错误导致某LTE站无法进行异频切换

1.现象描述

在用Quanta 1K3的设备进行测试蠡园移动全球通大楼过程中，室分小区的E频段为39150、PCI是1切换到室外宏站D频段为38050、PCI是104无法进行异频切换，在从室外宏站切换到室分小区E频段也无法进行异频切换，但可以进行站内同频切换和插拔后小区初搜。

2.问题分析

该站A1事件（停止异频测量）设置的门限是４，即相当于接收电平大于-136dBm时候停止测量异频；A２事件（开始异频测量）设置的门限是６０，即相当于接收电平大于-８０dBm时候停止测量异频；这两个参数设置的逻辑冲突，当服务小区电平低于-80dBm的时候UE触发A2开始异频测量，然后下一个时刻UE立即判断该触发A1停止测量了，所以才出现下面这种频繁A1A2上报的情况。

3.问题分类：无线参数配置

4.解决方案

将A2对应的参数a2ThresholdRsrpPrim的值更改为-90，把A1对应参数a1ThresholdRsrpPrim更改为-80

5.效果评估

异频切换成功，不再频繁上报A1/A2事件。

6.注意事项及建议

有逻辑关系的门限需注意设定。

3.2.4案例5： TAU与X2切换冲突导致切换失败并掉线

1.现象描述

观察话统发现某小区掉线严重，并且都是由于切换失败导致的掉线。

2.问题分析

从无线侧分析看，所有切换失败导致的掉话都是因为X2切换PathSwitchTimeout，即等待MME的PATH SWITCH ACK超时。

MME目前的实现方式是，当MME正处在处理终端的TAU流程的中间状态时收到了Enodeb发来的PATH SWITCH REQ消息，除了正在等待TAU Complete消息状态下会处理PATH SWITCH流程，其他状态下均直接返回PATH SWITCH FAILURE。

这样就使得处于TAL交接处的小区发生TAU概率较大，同时MME的配置发现许多IMSI号段的用户均开启了TAU鉴权。TAU流程中发起鉴权，增加了TAU流程的中间状态，也增加了TAU整个流程的时间，所以也增大了TAU与X2切换冲突的概率。

3.问题分类：无线参数配置

4.解决方案

现场通过按照默认配置修改鉴权暂时规避掉线。

5.效果评估

修改后掉线率显著下降。

6.注意事项及建议

在TAL区，可能会出现由于TAU更新导致X2切换成功率增高的情况。

3.3核心网参数

3.3.1案例6：LTE核心网鉴权关闭导致切换失败

1.现象描述

在某TDD-LTE实验网，站间小区切完后直接RRC CONNECTION RELEASE，切换失败率增加。 

2.问题分析

通过后台信令跟踪发现 UE 上发切换完成信令“ RRC Connection Reconfiguration Complete ”后，核心网直接下发“ RRC CONNECTION RELEASE ”给 UE ，导致 UE 重新建立 RRC 连接； 

前后台的信令对比分析得出，由于核心网下发了 RRC 拆链的信令，导致切换不成功，故问题可以暂定为核心网存在问题。

后通过与核心网人员确认，核心网将鉴权功能关闭，导致在站间切换时， UE 鉴权被拒，从而导致切换完成后直接 RRC 释放。

3.问题分类：核心网参数

4.解决方案

核心网打开鉴权功能。

5.效果评估

切换问题解决。

6.注意事项及建议

切换失败可能是核心网参数设置原因。

3.4传输参数

3.4.1案例7： LTE基站S1口少配导致切换成功率低处理案例

1.现象描述

在LTE网络KPI指标监控过程中发现某一区域的几个站点切换成功率极低，严重影响全网切换类指标，其中某站切换入失败次数每天达到4600多次。

2.问题分析

查询周边站点切换出失败原因全部为“目标小区回复切换准备失败消息”导致切换出准备失败。后台信令跟踪对吉州区人民广场标准X2口进行跟踪，发现切换准备失败的失败原因值为：传输不可用。

查询基站 IPPATH是否设置合理，结果发现S1接口配置为1条，IPPATH资源有限，所以相邻站点切到该站的成功率很低。

3.问题分类：传输参数

4.解决方案

增加到S1接口的IPPATH由1条到（现网标准为）

5.效果评估

将S1接口的IPPATH由1条到后，切换成功率恢复正常。

6.注意事项及建议

对LTE基站配置IPPATH链路时，需配置用于S1链路；如果S1链路配置少于将会出现S1链路传输资源不足的问题，导致基站E-RAB建立失败，系统内切换失败高；后期新开站点配置时需注意IPPATH链路是否正确配置，避免类似问题出现。

3.5异厂家参数配置

3.5.1案例8：爱立信与中兴LTE邻小区RLC传输模式配置不一致导致切换失败

1.现象描述

UE在中兴区域基站接入，往爱立信区域移动时不能切换，直至掉线

UE在爱立信区域接入或者在爱立信区域重建，这时UE能在中兴和爱立信基站间正常切换。

2.问题分析

在中兴后台侧跟踪信令发现，eNodeB收到UE上报的测量报告后，向CN发送了Handover Required消息，但是很快就收到CN回的Handover Preparation Failure，失败原因为12（No radio resources available in target cell）。经过异厂家参数一致性核查：通过对比成功和失败切换消息，发现两厂家RLC传输模式不一样，中兴是UM模式、爱立信是AM模式。

3.问题分类： 无线参数配置

4.解决方案

将中兴RLC无线传输模式配置为AM模式

5.效果评估

修改RLC无线传输模式配置后，异厂家邻区切换失败的问题解决。

6.注意事项及建议

由于同一个地市LTE网络由不同厂家建设，各自厂家传输模式设置不一致。建议 统一异厂家切换带小区传输模式，避免类似问题发生。

3.5.2案例9：大唐与诺西Local Cell Resource ID配置不一致导致切换失败的案例

1.现象描述

在优化测试过程中，UE占用信用联社1小区（PCI=79）的信号，在上发MR中可以看到，UE准备切换到工商学院3小区（PCI=113）上，但随后eNB下发的重配置消息中要求UE切换到工商学院2小区（PCI=112）上，而此处工商学院2小区（PCI=112）信号较差，最终导致切换后掉线。 

另外，信用联社为大唐基站，而工商学院是NSN基站，刚完成割接。

2.问题分析

经过分析发现割接后诺西的ECI与割接前大唐的ECI不统一所导致。

其中cell ID也就是我们常说的Local Cell Resource ID，eNB通过UE上报的PCI来判别是哪个小区的信号，并关联到相应的ECI，后续eNB下发的重配消息中target的PCI就是该ECI的PCI。 

大唐侧邻区配置中的Local Cell Resource ID是0、1、2，而诺西侧的Local Cell Resource ID是1、2、3，这样会生成不同ECI，导致PCI关联错误，致使eNB下发的PCI和UE上报的PCI不同导致切换失败。 

3.问题分类：无线参数配置

4.解决方案

大唐侧将割接后的该站邻区的Local Cell Resource ID由0、1、2修改为1、2、3

5.效果评估

修改后复测正常

6.注意事项及建议

异厂家间需注意Local Cell Resource ID参数不一致的情况。

3.5.3案例10：由于DRB-ID分配策略华为中兴LTE异厂家切换失败案例 

1.现象描述

在对华为中兴边界的LTE网络进行异厂家eNB切换测试时，发现失败率较高。经过分析，失败现象与起呼的小区有关：从华为站点入网开始做切换动作，无法完成切换。UE改为在中兴站点进行RRC建立之后，往华为小区切换就成功了。

2.问题分析

当测试终端从华为站点入网，当初始上下文建立后，基站向终端重配置，建立DRB承载的时候，会建立一个drb-identity为1的承载，而此时，如果这个时候测试终端从华为站点往中兴站点切换的话，切换命令里面会有DRB的删除信息，删除drb-identity（1），添加了一个drb-identity（3），但没有对应新建eps-BearerIdentity，导致终端切换失败。

而从中兴站点往华为站点切换的时候，在切换命令中的drb-identity为3，并且携带eps-BearerIdentity信息，不存在修改drb-identity的情况，所以切换成功。

3.问题分类：无线参数配置

4.解决方案

已经将该问题交与中兴研发，确认由于DRB-ID分配策略问题导致切换失败。需要在下一基站版本升级后解决。

5.效果评估

案例中暂未解决

6.注意事项及建议

目前LTE组网情况很多，由于不同厂家的算法策略有差异，需要特别关注异厂家之间的配合问题，以免影响用户使用。

4.LTE终端接入问题

4.1无线参数配置

4.1.1案例1： TD-LTE帧同步参数配置错误导致上行干扰，造成终端有信号无法接入

1.现象描述

新建站LTE基站70530三个小区存在有信号无法接入现象。现场测试：场强正常，无硬件告警，终端无法接入。

2.问题分析

提取故障站底噪，发现该站三个小区底噪都偏高，关闭周边基站后，故障站底噪正常，由此可以判断是周边基站对故障站造成干扰导致故障站底噪高。用后台扫频工具以1RB（180KHz）带宽为单位，记录故障站底噪，发现RB47-RB52底噪高，对比LTE帧结构，RB47-RB53处是主同步信号、辅同步信号和广播信号，经过分析研究，判断是周边基站的第一个下行时隙落入故障站的上行时隙，从而造成周边基站的主同步信号、辅同步信号和广播信号对故障站的上行RB47-RB53产生干扰。排除GPS故障后，将问题定位在是否自动调整数据帧头开关上，周边基站该开关是关闭状态，故障站是打开。

3.问题分类：无线参数配置

4.解决方案

关闭故障站是否自动调整数据帧头开关。

5.效果评估

关闭开关后，故障恢复。

6.注意事项及建议

是否自动调整数据帧头开关是基站自动计算和调整帧头位置，如果要打开该开关，必须全频段站点全部打开。如果部分基站打开，部分基站关闭，会造成打开的基站间与不打开的基站间的不同步。

4.1.2案例2： TDL完整性保护算法设置错误导致部分终端无法上网

1.现象描述

在T市TDD-LTE实验局项目中，新开通的一个站点终端A（MF91S）可以拨号上网，而终端B（MF820S2）无法拨号，点击拨号软件的连接，提示连接失败。

2.问题分析

为了定位问题，进行了小区信令跟踪，当问题终端拨号时，会伴随初始化上下文建立失败信令，查看信令发现原因为“加密或完整性保护算法不支持”。 查看该站点的安全管理，发现该站点的完整性保护算法与其他站点设置不一样，该站设置为128-ElA2，而其他站点设置为128ElA1

3.问题分类：无线参数配置

4.解决方案

修改该站点完整性保护算法与其他站点一致

5.效果评估

将该站点的完整性保护算法设置为128-ElA1后，上网正常。

6.注意事项及建议

LTE支持的完整性保护算法较多，但并不是所有的终端能支持所有的算法，需要根据实际情况设置，避免出现设置的加密或完整性算法终端不支持的情况。

4.1.3案例3：爱立信室分小区PrachConfigIndex配置错误导致接入性差

1.现象描述

在进行室分小区测试过程中，测试初始接入或小区切换时，经常遇到attch失败或切换失败现象。具体症状为：

1、PRACH上行同步次数较多，且PRACH的功率会逐渐攀升到满功率23dbm，CDS软件会提示定时器T304或T300超时。

2、反切失败。室分主测小区向同层同频的邻小区切换正常，但是经过在测试发现邻小区向室分小区切回时失败率偏高，测试症状同为 PRACH上行同步次数较多。

2.问题分析

查询该小区PRACH参数由于室分向邻小区切换都正常而反向切换邻小区向室分小区切换则会出现失败，因此对比这两个小区的PRACH参数，发现PrachConfigIndex参数不同，室分小区为51，邻小区为3。通过查询协议3GPP协议36.211 Table 5.7.1-3PrachConfigIndex与Preamble Format对应关系，可知该室分小区Preamble Format为４。Preamble Format 4仅用于TDD LTE，它时域长度较其他Preamble Format明显偏短，占用特殊子帧的ＵpPTS的两个符号。

Random access preamble parameters.

4.解决方案

将室分小区的PrachConfigIndex从51修改到3，采用Preamble Format 0

5.效果评估

修改后多次测试该小区切换成功率和接入成功率明显改善，与周边小区相比无异常。

6.注意事项及建议

Preamble Format 4在特殊时隙的最后部分（即UpPTS）进行发送，这样利用UpPTS的资源完成上行随机接入的操作，避免占用正常子帧的资源。这是针对半径较小的微型小区的一种优化，可以在不占用正常时隙资源的情况下，利用很小的资源承载PRACH信道，有助于提高系统上行吞吐量，也有助于提高上行业务信道的覆盖性能。

但在实际工作中采用 Preamble Format 4提升小区上行吞吐量时，需注意由于其时域长度要远小于其它4种Preamble Format，因此其链路预算相对明显较低，其链路预算所能够支持的覆盖半径相应的明显偏小，仅适用于覆盖半径较小的场景，特别是密集市区、室内覆盖或热点补充覆盖等场景。同时根据网络环境不同，采用Preamble Format 4时其实际覆盖半径不同，如采用Preamble Format4则开通后需着重进行接入性测试，确保其覆盖范围内终端接入正常。

4.2核心网配置

4.2.1案例4： LTE的S1口IP配置错误导致终端无法正常接入

1.现象描述

TD-LTE基站站完成数据配置且检查无告警后，网优进行CQT、DT测试，CPE多次拨打，均无法接入，离开该站覆盖范围后，CPE可正常接入。

2.问题分析

在M2000上通过IMSI进行信令跟踪，通过信令跟踪，核心网返回的原因为传输资源不可用。检查IP Path配置信息，发现至UGW9811的IP路由设置错误。

3.问题分类：核心网配置

4.解决方案

修改IP Path配置信息。

5.效果评估

修改后，重新接入正常。

6.注意事项及建议

本案例由于在数据配置时，修改了SCTP 链路的目的信令点，但没有同步修改IP Path链路的信令点，导致传输链路不可用；由于IP Path与SCTP 链路强相关，建议修改SCTP链路后，提示需要修改IP Path链路，或者在告警台提示IP Path链路与SCTP 链路数据配置不符等告警信息。

4.2.2案例5： 在MME中未绑定IMSI和HSS对应关系导致LTE新号段无法附着到网络

1.现象描述

深圳TD-LTE二阶段扩大规模试验网，有一批新开户的测试号码，初次使用时发现所有用户终端均显示无信号，无法发起业务。用户直接感受就是不能接入网络，接入性能的体验上就大打折扣了，更享受不到高速上网的体验。

2.问题分析

选定其中一个用户在MME上对其进行用户跟踪，发现用户Attach流程异常，定位为网元配置异常。经检查在MME侧中绑定IMSIHSS数据配置出错，导致Attach过程中MME并未向HSS发送ULR(Update Location Request)消息，从而终止了Attach流程，详细如下： 

从信令跟踪来看，用户初次Attach采用IMSI附着，MME正常收到了用户上报的附着请求，但是MME没有向HSS上报update location RQ来获取用户信息和签约数据，直接就被终止，查看USN内部模块消息，发现在UDM查询SDB表项时，SDB返回查询失败。

SDB表项存储有IMSI和HSS的绑定信息，USN通过查询SDB表项得知该IMSI注册的HSS主机信息，进而向该HSS获取用户信息和签约数据，这里显示查询SDB表项失败，说明USN侧未添加IMSI和HSS的绑定关系或定义出错，导致未查询到相应结果。

3.问题分类：核心网配置

4.解决方案

在MME中添加新开户的IMSI号码和HSS的绑定关系。

5.效果评估

问题解决。

6.注意事项及建议

用户现象来看，用户终端显示无信号，实际为无法完成Attach流程，可能有以下原因：

（1）、基站断站，导致用户无信号。

（2）、用户未注册到网络中，主要原因有以下几点：

 　HSS侧未开户或开户数据错误。

   EPC设备或链路故障，导致信令流程异常，致使用户无法正常注册到网络中。

EPC网元的数据配置问题。

4.3传输参数配置

4.3.1案例6：未设置用户面路由导致LTE基站无业务速率

1.现象描述

在对某地市 LTE 基站进行业务测试时，发现终端显示 USIM 卡可以注册到 LTE 网络，但是进行数据业务时，所有网站都打不开， ftp 下载也无法连接到服务器。

2.问题分析

LTE 业务分为业务和网管两部分，因此，在 PTN 网络需要配置两条业务通道分别进行传输，经过数据核查，发现业务层信令面路由已经配置，但用户面路由未进行配置。

3.问题分类： 传输参数配置

4.解决方案

PTN 侧对业务层用户面路由进行配置。

5.效果评估

配置后，在 NodeB 侧对 MME 地址及 SGW IP 地址进行 ping 包，均可以 ping 通，数据业务测试正常。

6.注意事项及建议

如LTE基站无业务速率，需核查用户面路由是否已配。

5.2/3/4G互操作问题

5.1.1案例1： 由于3G/4G的PLMN不同且未配置EHPLMN导致TD-S重选TD-L失败

1.现象描述

在进行4G到3G的互操作测试时，经过参数配置，能实现D频段LTE A小区 向  TD-SCDMA基站的B小区重选，但是不能实现TDSCDMA基站B小区向D频段LTE A小区的重选，即无法完成3G到4G的重选

2.问题分析

TDD-LTE的PLMN配置为46008，TD-SCDMA的PLMN配置为46000。终端进行小区选择或者异系统重选时，将根据USIM卡内的ePLMN_list信息选择合适的网络，而UE的ePLMN_list是通过网络侧获取（一般通过LAU过程），并保存在USIM/SIM卡的ePLMN_list列表中。而终端在３GLAU流程中，在location-update-accept信元中，只下发了一个plmn_list只下发了46000,未下发LTE的PLMN46008,导致从3G到4G重选失败。

3.问题分类： 核心网参数配置

4.解决方案

在3G核心网配置对等PLMN46008

5.效果评估

3G和4G配置对等PLMN46008后，3G向4G重选测试成功

6.注意事项及建议

3G-4G重选失败问题原因：

(1)、目标4G小区的频间绝对优先级设置低于3G服务小区，如3G小区的重选到高优先级小区的高门限ThreshX, High配置太大等。

(2)、3G服务小区的4G邻区频点或PCI等配置错误导致无法重选; 3G小区的SIB19未下发。

(3)、核心网未配置对等PLMN。

(4)、外部干扰源干扰。 

5.1.2案例2： 华为和中兴MME选路策略不同导致CSFB被叫接通率较低

1.现象描述

中兴公司在静海区域现场优化测试时发现CSFB被叫异常，同时也接到其他方面反映此情况。于是现场测试跟踪并更换多个基站测试，发现静海区域整体被叫接通率较低。UE重新ATTACH后没有选择原来的MME而是选择POOL内另外一个MME，EnodeB侧没有按照POOL方式正确分发。

2.问题分析

静海区域组网情况如下：中兴ENODEB站点和华为的EPC对接，华为的EPC采用两套SGSN升级起来的MME组成MME-POOL，ENODEB侧因此配置两条偶联同时和两MME对接。网络结构图如下：

中兴无线侧ENODEB对MME处理方式如下：一个GUMMEI中只能携带一个MME code，即再处理过程也做了截断处理；当携带多个MME code的情况下，也会仅仅保存一个。

静海区域华为MME下每个GUMMEI中都携带了两个MME Code，分别是2和3,4和5。按照以上处理机制，中兴ENODEB在处理多个MME Code时，每个MME下只保留了一个MME code，即保存了MME Code为3和5。而当S-TMSI中MME Code为4的情况下，ENODEB无法匹配信息中携带的MME code信息，则进行Load balance选择MME的过程，所以UE接入两个MME/SGSN几乎是均等的。

3.问题分类： 核心网参数配置

4.解决方案

规避方案是将MME只配置一个MME Code。

解决方案是在S1 Setup过程中，保存所有的MME Code信息，用于选路过程。

5.效果评估

待厂家升级解决

6.注意事项及建议

UE重新ATTACH后没有选择原来的MME而是选择POOL内另外一个MME，主要原因为中兴在MME协议理解与华为方不一致，导致ENODEB侧对MME处理方式异常。

6.掉话问题

6.1.1案例1：TD-LTE SRS带宽重配置导致掉话率高案例

1.现象描述

某LTE站点在用华为E398进行测试时，掉话率过高，达不到验站要求。

2.问题分析

查看话统数据及CHR日志，发现异常释放原因为RB重配失败导致了掉话。通在eNB侧的Uu口跟踪中展开eNB下发的“RRC_CONN_RECFG”消息，发现涉及到的重配置内容包括MIMO传输模式、SRS配置。所以可能的原因集中在这些参数的配置上。在关闭MIMO传输模式后，在eNB侧的L3空口信令中看到RRC释放前有srs-Bandwidth重配置。Sounding参考信号SRS带宽重配置主要是其自适应的结果。SRS带宽自适应为了使RB资源分配随着信道质量变化而变化，但是在网络弱覆盖的场合，可能会造成TA解调性能受限而产生异常释放。

3.问题分类： 无线参数配置

4.解决方案

关闭SRS自适应开关

5.效果评估

现场修改参数后，成功降低了掉线率。

6.注意事项及建议

掉话问题一般要分析最频繁的异常释放原因，这样才能有效降低掉话率。根据掉话前信令中出现的可疑点进行分析，尝试修改配置，结合实验得到解决方案。下载本文