1、LTE典型案例1.案例一：远见智能第1小区下载速率偏低问题【现象描述】在远见智能基站1小区下载速率偏低（20Mbps), RSRP很高，下行SINR很好，MCS偏低，16QAM比例很高、BLER很低。【问题分析】 关闭ATB/UL PC等问题依然存在。关闭远见智能第2、3小区问题依然存在；初步分析问题不是由于干扰问题，检查SCF文件发现DLTARGETBLER设置为1%，可能与此有关，由于BLER要求太高，OLLA会调低MCS以保证BLER目标，而对于FTP等业务不需要如此高的BLER要求，并且会导致不能够使用高阶MCS及64QAM，从而导致下载速率偏低。【解决方案】将第1小区恢复成DLTAR
2、GETBLER=10%。2.案例二：室分小区随机接入失败-误包率【问题分析】 1.怀疑定时器设置或者切换参数问题，但是核查参数发现336和337的定时器设置相同，切换参数也相同，故排除定时器设置和切换参数问题； 2.怀疑无线环境问题，336小区和337小区做的是同层的2个小区，在同层测试RSRP/RSRQ/SINR都比较好，排除无线环境问题； 3.怀疑随机接入参数设置有问题，由于336向337切换都正常而反向切换337向336会出现失败，因此对比这两个小区的PRACH参数，发现prachConfigIndex参数不同。将336小区的prachConfigIndex从51修改到3，多次测试切换成
3、功率和接入成功率明显提高。4.进一步定位发现海思终端在prachConfigIndex=51(preamble format 4)时随机接入的成功率较低。【解决方案】 prachConfigIndex与preamble format对应表如下： prachConfigIndex=51时，对应的preamble format为4，prachConfigIndex=3时，对应的preamble format为0。【解决方案】preamble format 规范定义的格式如下： preamble format 4时PRACH在UPPTS发送，这种格式的CP时域长度和Sequence的时域长度都比pr
4、eamble format 0小很多，被基站成功解调的几率也小很多，所以选择format 0会比选择format 4切换成功率高。因此修改参数prachConfigIndex从51修改到3。问题解决。3.案例三：初始接入MSG1多次发送未响应的处理案例 1 问题描述 在短呼测试中，出现UE发出attach req和RRC Connection Request后未收到RRC Connection Setup，造成呼叫未接通的情况，查看路测信令，如图1所示，在小区PCI11，8次msg1发送未收到MSG2。 图1 MSG1多次重发无响应 2 原因分析 首先检查后台告警此时无GPS失锁告警，排查上行
5、交叉时隙干扰导致的MSG1解调失败。在路测软件上查看起呼失败时的接收电平和信噪比，下行RSRP为-91 dBm，接收电平良好；SINR较差-9.8 dB，说明起呼点无线信道质量较差。如图2、图3所示。 精诚服务 TD-LTE 无线侧专刊 2013 年第 1 辑 17 图2 接入失败点RSRP 图3 接入失败点RS-INR 在无线信道质量较差的位置起呼，基站收到的PRACH信号过弱，导致基站侧将接收的PRACH信号当做无用信号不解调，造成MSG1无响应。通过降低“eNodeB对PRACH的绝对前缀检测门限”，提高PRACH信号的检测概率，在上行无线信道质量较差的情况下，提升MSG1正确解调的概率
6、。 3 处理过程 将“eNodeB对PRACH的绝对前缀检测门限”从2000改为50，修改后进行短呼测试，RRC Connection Success为100%。在小区PCI11，从MSG1发送的间隔上观察，再未出现MSG1重发无响应的现象。如表1所示。 参数：eNodeB对PRACH的绝对前缀检测门限 PRACH Absolute Preamble Threshold for Enode B Detecting Preamble 取值范围：1-65535 4.案例四：调度不满a)传输问题传输明显丢包；传输端口模式配置错误；由于传输侧反馈无其他明显异常，定位至此，有点山穷水尽了。回过头再次梳理
7、之前的定位过程，从中找些蛛丝马迹。根据1.抓包分析，从基站、终端侧抓包看，S1下行存在1/1000的丢包，因此再次安排上站抓包，站点：伊刘村。方法是在基站和PTN设备之间接入第3方交换机，在连接第三方交换机时发现，端口速率始终无法达到千兆，而第3方交换机直接和基站传输口相连，则可以达到千兆，怀疑传输侧配置为100M光口而非1000M，将该问题反馈传输核查，经传输改配后，重新连接PTN和基站，复测速率正常。这种情况有一个特点：在物理设备-机架-机框-板卡-以太网节点下，目前正在使用的端口，配置工作模式为自适应，实际工作模式为100M。传输链路不稳；b)参数设置问题：上行BO设置不合理；c)测试点
8、空口环境查，BLER高导致速率持续偏低；d)传输大时延使上行ACK晚点到达服务器，引发重传，最终导致下载速率低；e)终端问题终端性能问题导致业务长时间保持中收到数据处理不过来而丢弃，引发重传；终端反馈0窗口报文，导致速率偏低。5.案例五：TD内部干扰【问题描述】在对师大食堂站点进行SSV验证时，出现UE（HISI E5776）无法接入的情况，UE显示“无服务”，信令流程如下图所示。此时的参数配置如下：SubframeAssignment=2、SpecialSubframePattern=7、TimeOffset=700000，后台查询，该站点存在严重上行干扰。【问题分析】与GSM900一样，T
9、D-LTE的干扰也分外部干扰和内部干扰两大类，外部干扰包括TD-S同频阻塞干扰、DCS阻塞/杂散干扰、GSM谐波/互调干扰、天馈和器件故障导致干扰以及其他未知干扰；内部干扰包括TD-LTE同频干扰和TD-LTE主设备故障引起的干扰。对此，需逐一排查，同时也须验证如何设置时隙配比和TimeOffset才能规避TD-LTE与TD-S之间的互相干扰。【排查步骤】步骤1：验证是否由主设备故障导致干扰初始连接加入200W负载干扰截图干扰截图结论：TD-LTE设备正常，干扰可能来自合路器、1/2跳线、天线或外部。（注：干扰判决门限-116dBm。）步骤2：验证干扰是否由合路器引起初始连接RRU（F）直连基
10、站天线干扰截图干扰截图结论：合路器性能正常，并非干扰源。步骤3：验证干扰是否由基站天线引起RRU（F）直连基站天线RRU（F）直连吸顶天线干扰截图干扰截图结论：由后台干扰数据分析，RRU（F）直连吸顶天线后干扰减弱，但考虑到吸顶天线的增益为3dBi，小于基站天线增益17dBi，干扰减弱在情理之中，至此判定基站天线性能正常，并非干扰源。步骤4：验证同站点的DCS1800、TD-S是否干扰TD-L开启DCS1800; 开启TDS开启DCS1800; 关闭TDS连接方式关闭DCS1800; 关闭TDS结论：同站点DCS1800、TD-S并未对TD-L造成明显干扰。步骤5：验证同站点的GSM900是否
11、干扰TD-LGSM900开启连接示意图GSM900闭站结论：同站点GSM900并未对TD-L造成明显干扰。补充说明：1、排除TD-LTE同频干扰在整个排查过程中，除师大食堂_3开启之外，同站点师大食堂_1、师大食堂_2及其他TD-LTE（F）站点均处于关闭状态，故排除LTE同频干扰。2、外部扫频本次外部扫频使用的是安利MS2732B扫频仪，在开启均方根检波时，无论设置VBW/RBW为何值，其自然底噪均在-100dBm左右，该底噪电平甚至强于师大食堂_3后台统计的干扰电平，所以其扫频结果参考价值不大，建议采用底噪小于-120dBm、灵敏度更高的扫频仪进行扫频。3、ENodeB版本升级后问题得到解
12、决。6.案例六：速率不稳定问题分析a)问题描述某站-3小区覆盖的区域RSRP在-60,86之间、SINR在23,33之间，BLER及双流MCS正常，但是速率常常低至10Mbps以下或无速率。问题地点如下：b)2.问题分析问题区域由某站-3小区（PCI 329）覆盖，该区域信号较强，无线环境相对较好，RSRP平均值在-75dbm左右，SINR平均值在-25dB左右，BLER也正常，但是下行速率不稳定，有时候会降低至10Mbps，甚至完全没有速率。如上图所示，该时刻RSRP为-66dbm，RSRQ为-3dB，SINR为33dB，但是RB数只有16，下行速率为0.31Mbps。下图为问题路段速率图：
13、c)3.问题排查问题小区覆盖路段RSRP、SINR好，BLER及双流MCS均正常，但是速率上不去。对此做了以下排查工作：1、检查了后台无线参数（邻区配置、功率、带宽、时隙配比等）及告警，未发现异常；2、更换电脑及测试终端，问题依旧；3、怀疑BPL单板故障，复位BPL，问题依然存在；4、远程telnet登录基站CC单板，复位板件，问题依然存在；5、更换FTP服务器进行测试，问题依旧；FTP+迅雷多线程下载，问题依旧；6、上站检查RRU与天线之间馈线的线序，发现线序有误，RRU4口接到了天线的8口，RRU8口接到了天线的4口。如下图所示：怀疑是天线线序接错，使得数据流和BBU PORT口映射错误导
14、致下行速率不稳定，故联系工程人员将线序进行了调整，调整后速率恢复正常，没有再出现速率不稳定现象，如下图所示：d)4问题处理在上面的问题排查中，将可能影响TD-LTE下载速率的几个相关因素进行了排查，最终将问题原因定位在天线与RRU之间的线序。工程人员将线序调整正确后，复测发现速率不稳定的现象得到了解决。在以后出现速率不稳定问题时，建议可以检查RRU与天线之间线序，提高问题排查效率，提升TD-LTE的网络指标。e)5原理目前常规定向智能天线有8个天线阵元,提供8个通道，共8根馈线，第9根线为校准线，其通过内部的耦合网络与8个通道相连，进行基本的校准。8天线线阵双极化天线与RRU通道映射关系如下图
15、所示：其中天线1至4端口为-45极化，依次连接RRU TRX1至TRX4，映射数据流Data1至Data4，汇聚到BBU的PORT1；天线5至8端口为+45极化，依次连接RRU TRX5至TRX8，映射数据流Data5至Data8，汇聚到BBU的PORT2。硬件连接关系、软件数据流走向和端口之间的映射关系相对固定，不能随意配置。7.案例七：调度不满导致下载速率低问题问题描述：近期，在网格大会战过程中， LTE网格组发现多个站点在无线环境良好的情况下，下载速率无法达到峰值的情况，如下为金陵城二-1小区测试速率，速率始终只能在50M-60M上下。而该站点的配置在正常情况下应该在80M以上。 共发现
16、该问题的有：郭家山二搬迁、新生圩港、金陵村二、伊刘村、浦口二、柳塘村、浦江学院、燕江路、宝塔街T、大桥村、浦口审计学院试扩、林家凹试扩等12个站点。问题分析：针对该问题进行了长达1个月的反复抓包、测试定位，分析发现引发该问题的原因有多种情况，下面是详细分析。1.无线侧初步分析排除终端和笔记本、FTP服务器问题：对这几个站点，进行更换终端、笔记本等方法进行测试，现象一样，且同样的笔记本、终端在其他站点上速率正常，可达到峰值。排除这方面的问题排除无线环境因素:测试时对测试位置进行多次选点，在RSRP/SINR等都远大于极好点的位置进行测试，MCS等级可基本维持在27以上，但是速率表现一样。同样的位
17、置进行UDP灌包，速率可达到峰值。如下图，至此可基本排除无线环境问题。测试组对问题站点的小区PRB数限制为48/24，测试速率基本稳定在对应的峰值速率上。也说明问题不在空口上，怀疑进入基站的数据不足。在基站的S1口做镜像抓包，同时在FTP服务器上也做WIRESHARK抓包，发现S1口的下行数据存在乱序和丢包的现象，丢包率大约为千分之一，这个有可能导致速率的下降。金陵村二 伊刘村2.传输链路不稳及丢包问题根据以上分析，首先怀疑传输侧问题，将存在问题站点提交传输分析，传输侧反馈郭家山二搬迁、新生圩港链路不稳，并进行处理；燕江路传输侧存在明显丢包，并对异常进行处理；根据传输侧反馈，项目安排复测：新生
18、圩港和燕江路问题解决，郭家山二搬迁1、2小区速率恢复正常，3小区下载速率依然较低；由于同站所有小区共用传输，因此该站3小区问题非传输导致；站点中兴答复当前版本郭家山二链路不稳，已处理3.20.00.40.15.01新生圩港链路不稳，已处理3.20.00.40.15.01燕江路存在明显丢包,已处理3.20.00.40.15.013.参数设置问题 传输整改后郭家山二仅3小区仍存在问题，因此小区参数设置嫌疑较大，将3小区参数与1、2小区进行对比，发现上行BO参数设置不合理，参照1、2小区进行设置后，3小区下载速率恢复正常，并对其他未解决站点参数也进行核查，发现金陵村二存在同样问题，修改后也恢复正常。
19、4.传输侧带宽设置不合理由于传输侧反馈无其他明显异常，定位至此，有点山穷水尽了。回过头再次梳理之前的定位过程，从中找些蛛丝马迹。根据1.抓包分析，从基站、终端侧抓包看，S1下行存在1/1000的丢包，因此再次安排上站抓包，站点：伊刘村。方法是在基站和PTN设备之间接入第3方交换机，在连接第三方交换机时发现，端口速率始终无法达到千兆，而第3方交换机直接和基站传输口相连，则可以达到千兆，怀疑传输侧配置为100M光口而非1000M，将该问题反馈传输核查，经传输改配后，重新连接PTN和基站，复测速率正常。这种情况有一个特点：在物理设备-机架-机框-板卡-以太网节点下，目前正在使用的端口，配置工作模式为
20、自适应，实际工作模式为100M。对全网进行核查发现还有浦江学院、浦口审计学院试扩、林家凹试扩等站点存在同样问题。传输侧反馈如下，经处理几个站点均恢复正常：站点中兴答复伊刘村传输侧配置为强制100M浦江学院传输侧配置为强制100M浦口审计学院试扩传输侧配置为强制100M林家凹试扩基站上PTN设备安装为155M光模块以下是该种情况下，OMC上核查的节点：5.上行BLER导致速率持续偏低针对柳塘村速率持续偏低的问题，上站抓包：该站没有明显丢包，但是从基站可以看到空口有心电图状的BLER毛刺，峰值约10%，从拉网速率趋势看，曾有一小段时间空口无BLER，对应的速率可以稳定在80M左右，因此可以看出，下
21、载速率高低，与测试点空口BLER有直接关系，空口BLER会导致下载速率持续偏低。经过外场测试人员寻找，在柳塘村可以找到空口环境较好的测试点，这些测试点空口无明显BLER，测试速率可在90M，这一现象也能说明，下载速率与BLER的关系。6.上行反馈晚点到达服务器和终端丢包通过在柳塘村寻找无线环境好的测试点，测试速率可在90M以上，但也有偶尔掉坑现象，针对此种情况进行抓包和CDL业务日志分析，发现掉坑的时候有突发重传，重传的原因有2中：上行ACK到达服务器时间点晚导致服务器重传终端侧抓包分析：在500746行收到了SN为904789478的原始包紧接着在500748行对500746行和500747
22、行报文进行确认ACK（ipid : 30556），如图：在501077行，收到SN为904789478的重传包服务器侧：在939644行对SN：904789478包首次进行发送在939931对SN：904789478包进行重传，此时按照TCP协议，超时重传会导致速率陡降。然而，在服务器对SN： 904789478重传后的939936行收到了终端对原始包的确认，说明原始包的ACK（ipid: 30556）并没有丢，只是到服务器时晚了上行ACK晚点到达服务器的原因应该与下述发现的传输时延突发异常变大有关。在做业务过程中，基站对EPC进行长PING操作，会偶尔出现超大时延现象，如图：终端接收丢包在1
23、26424行，抓包看终端已收到SN为3564609387的原始包，然而终端后续却一再确认SN为3564609387的包丢失（红色部分）直到在126917行收到服务器的对SN为3564609387报文的快速重传才恢复正常总结上述抓包分析：1） 上行TCP ACK晚点到达服务器导致重传；2） 业务过程中PING EPC存在超大时延是导致ACK晚点的最重要原因；3） 重传为瞬时突发，绝大部分时间无重传，且重传发生时伴随速率下降；4） 怀疑终端或笔记本性能问题会导致在业务长时间保持中收到数据处理不过来而丢掉；上述四点解释了测试过程中出现的现象：业务较长时间能够保持锋速，偶尔出现掉坑，长时间持续业务时速
24、率波动幅度会变大。7.终端反馈0窗口报文导致速率低针对宝塔街站上站测试抓包，经过分析，该站点BLER相对较高，但导致业务速率低的更重要原因为终端会反馈0窗长报文，一旦出现该问题，当前下载线程则处于停滞状态直至终端上报窗长恢复，每次发生停滞时间120ms-900ms不等，停滞时间内速率为0。 5线程下载测试，57秒的抓包中，发生约20次0窗口事件，而且，0窗长发生时往往伴随着丢包，如此，必然会导致速率低，如图，在65419行发生0窗口事件，直到65466行恢复，停滞时长约800ms。解决措施及结果：综上多种情况分析：调度不满导致速率低问题，经过传输整改链路、改配端口模式均能有效解决该问题。问题结论;引起调度不满导致速率低问题有以下几种因素：f)传输问题传输明显丢包；传输端口模式配置错误；传输链路不稳；g)参数设置问题：上行BO设置不合理；h)测试点空口环境查，BLER高导致速率持续偏低；i)传输大时延使上行ACK晚点到达服务器，引发重传，最终导致下载速率低；j)终端问题终端性能问题导致业务长时间保持中收到数据处理不过来而丢弃，引发重传；终端反馈0窗口报文，导致速率偏低。
