 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
LTE随机接入过程
下载积分：1000
内容提示：LTE随机接入过程
文档格式：DOC|
浏览次数：140|
上传日期： 16:59:56|
文档星级：
该用户还上传了这些文档
LTE随机接入过程
官方公共微信LTE中,那如果在DRX的静默期刚好有对UE的下行信息的话,会发生什么情况呢?DRX跟半静态调度的区别是什么?他们是同时发生,还是不同的发生部分?在DRX激活期中,UE会监听下行信道有否新信息.而在静默期就为了省电不监听下行链路.那如果在DRX的静默期刚好有对该UE的下行信息的话,会发生什么情况呢?
dbthbfn000DD
DRX,非连续接收.主要指的是UE的处理,当然需要基站处做出一定发送的配合.SPS,半静态调度.主要指的是基站处资源分配和指示的一种方法.通常用在VoIP等一次性调度数据量较小,并且需要持续一段时间的业务.这样可以节省PDCCH资源的需求,可以调度更多的VoIP用户.DRX静默期UE有下行数据时,基站会在该UE的DRX激活期于PDCCH中发送Paging信息,UE在接收到该Paging后,会发起随机接入过程,随机接入的理由通常为Service Request吧.随机接入的优先级肯定高于DRX,之后再怎么样就没有研究过了.
为您推荐：
其他类似问题
扫描下载二维码君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
LTE随机接入(很全)
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口lte+下行信号处理_壮志凌云
lte+下行信号处理
lte+下行信号处理&相关文章
1.LTE下载速率低原因及相关案例
现阶段排查LTE下载速率低影响的主要因素包括：
（1）无线环境
（3）无线参数配置
（4）传输问题
（5）传输相关参数配置
（7）传输相关参数配置
1.1无线环境
无线环境是影响下载速率低的一个重要原因。现网中由于多系统的存在，会对空口传输质量造成影响。
无线系统按照干扰产生的起因可以将干扰分为系统内干扰和系统间干扰。
系统内干扰：系统内干扰通常为同频干扰。TD-LTE系统中，系统内干扰常见原因有小区越区覆盖造成的同频干扰和GPS时钟不同步造成的下行信号对上行信号的干扰和模三干扰。
系统间干扰的产生：系统间干扰通常为异频干扰。主要有：杂散干扰、阻塞干扰、谐波干扰、互调干扰。通过LTE前期总结系统间干扰的干扰主要如下：
排查这种类型干扰，一般是通过系统监控手段对小区干扰进行预判断，然后根据小区的干扰特性进行实地扫频排查。通过闭站，看干扰是否消失排查。
1.1.1案例1：系统外干扰（DCS1800）导致LTE宏站单小区下载速率低
LTE基站1小区在测试过程中，发现下载速率低（1M左右），终端ping核心网侧丢包率高达50%。该基站配置为S111，频段是F频段MHz，带宽20M，参考信号功率12dBm，上下行时隙配比1:3，特殊子帧时隙配置DwPTS:GP:UpPTS=3:9:2
2.问题分析
使用底噪查询工具。各小区底噪情况如下：
将查询出的底噪值与各小区的业务速率对比，很容易看出业务速率低的小区恰好是后台查询底噪高的小区。由此判断为底噪高是导致空口质量差，引起终端业务速率低、ping包丢包率高的原因。
闭塞周边所有LTE小区,以及2、3小区全部闭塞，仅保留1小区，问题依然存在。对MHz扫频，发现移动DCS1800频段天线对该频段有干扰。由于该LTE基站与37854昌平都市芳园DCS共址，基本确认干扰来自该基站。接下来考虑为何2，3方向无明显干扰而1方向干扰明显，观察天线，发现2,3方向LTE天线与DCS天线水平隔离度1米左右，而1方向LTE与DCS天线水平隔离度仅0.4米左右。
4.解决方案
改变1方向LTE天线位置，将其与DCS天线水平隔离度增加到1米。
5.效果评估
１小区天线与DCS天线水平隔离度增加到1米后，底噪-109，下载速率50M，故障排查完成。
6.注意事项及建议
故障排查流程：
1.1.2案例2：服务小区与邻小区PCI存在mod3干扰造成下载速率过低
对某区域LTE网络进行评估测试时发现，当测试终端占用A小区后下载速率过慢，下载速率只有10Mbps左右。
2.问题分析
核查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值过低导致下载速率过慢。
4.解决方案
修改A小区PCI为11
5.效果评估
重新测试，A小区下载速率提升到55Mkbps以上。
6.注意事项及建议
下行参考信号在天线上发送的位置取决于小区PCI值，如果是单天线发送下行参考信号的位置为PCImod6，如果是两天线发送下行参考信号的位置为PCImod3。如果PCI规划不当就会造成不同小区间参考信号干扰。
1.1.3案例3：由GPS失锁引起的F频段LTE基站上行干扰
某基站通过话统查询上行底噪，发现此基站上行底噪很高，三个小区均在-77dB左右。测试工程师到现场测试发现该小区无法正常接入，无法进行上下载业务。
2.问题分析
经话统确认，此基站周围基站汇彩路、黄村大道、珠吉路底噪也较高，达到-100dBm以上.连片区域基站存在干扰问题原因可能为：GPS失锁或外部干扰。协调代维人员进入基站机房，发现机房内存在两个BBU。分别下挂东圃珠村和9860基站，均为TDDF频段基站，9860基站在工参表中未显示，此基站告警灯常闪，后台查询后，发现9860基站存在GPS失锁告警。
4.解决方案
闭塞9860基站，安排维护人员上站处理该基站的GPS失锁告警问题。
5.效果评估
基站底噪下降到-110dBm以下，速率恢复正常。
6.注意事项及建议
TDD-LTE上行干扰可能的问题原因：
(1)、移动DCS1800M小区频段为：M，M；所以此频段很容易对TDD-LTE频段M形成阻塞干扰、互调干扰和杂散干扰。
(2)、GSM900M基站对TDD-LTE频段M形成谐波干扰。
(3)、小灵通基站对TDD-LTE形成阻塞干扰、互调干扰和杂散干扰。
(4)、周围TDD-LTE基站GPS失锁形成干扰。
(5)、RRU硬件或天馈系统问题造成干扰。
(6)、外部干扰源干扰。
容量也会影响下载速率，现网由于LTE用户不多，暂不需考虑这方面的问题。
1.3无线参数配置
1.3.1案例4：爱立信小区上下行时隙配比错误导致上行高BLER速率低
某日在进行簇优化过程中，进行上传业务时发现某站点的3个扇区的上传速率均明显偏低，仅能达到约2~5Mbps，而在前期该站点的单站验证测试中，该站的上传速度正常，三个小区均达到了16Mbps左右；
2.问题分析
在占用站点第1小区测试过程中，显示第1小区BLER较正常情况偏高，导致MCS较低；检查周边邻区的无线参数配置，经过核查发现该站点第3小区的TDDframeconf=2，即时隙配比为3：1，而周边基站均为2：2；
4.解决方案
将第3小区参数TDDframeconf改为1，即时隙配比改2：2
5.效果评估
经测试三个小区SINR在24左右，上传速度均达到了15Mbps以上。
6.注意事项及建议
因LTE上行采用SC-FDMA，相对下行抗干扰能力较弱，在LTE建设过程中，需注意邻近小区上下行时隙配比准确一致，否则易对周边小区造成较强的上行干扰。后期网管搭建完毕后，需定期对小区做参数核查，确保参数配置无误。
1.3.2案例5：LTE的功率PA、PB参数设置不合理导致下载速率低的处理
LTE小区在覆盖较好路段（RSRP=-72dB,SINR=32dB，且传输模式为TM3）下载速率低（基本小于40Mbps）
2.问题分析
查询该小区功率参数设置，发现PA参数设置为-3，PB参数设置为3，根据功率利用率分配表可知此时功率利用率仅为67％。
4.解决方案
修改PB参数为1，使其利用率达到100%。
5.效果评估
将PB参数修改为１后，对该路段验证测试，该路段PHYDLThroughput由35Mbps提升至47Mbps，达到指标要求。
6.注意事项及建议
LTE下载速率低也需注意功率参数PA/PB的设定，其要求TypeA，TypeB两类符号上的功率保持相等，当和相等且等于最大发射功率时，功率利用率最高。LTE参数设置需考虑业务场景，根据不同的需求对参数进行合理化配置，已到达感知最优。
1.3.3案例6：爱立信LTE小区DLTARGETBLER参数配置有误导致下行速率低
某站在进行簇优化过程中，进行FTP下载业务时发现某小区的下载速率均明显偏低，仅能达到约20Mbps左右，而在前期簇优化的拉网测试中，该站的下载速度正常，三个小区均达到了40Mbps左右。
2.问题分析
在占用该小区测试过程中，观察发现下行调制方式中16QAM占比较高；初步怀疑该小区下行速率低为调制方式没有全部采用64QAM导致。核查该小区CV文件发现参DLTARGETBLER（下行目标ＢＬＥＲ）配置为1%；
当参数DLTARGETBLER(下行目标BLER)设置为1%时，由于对BLER要求过高，导致RBS会调低MCS以保证BLER达到目标值。而对于FTP、流媒体等并不需要很高的BLER要求的业务，过高的BLER要求会导致下行因没有使用64QAM的高阶调制方式，反而无法得到理想的下行速率，从而影响用户感知。
4.解决方案
将该小区参数DLTARGETBLER设置为10%
5.效果评估
修改该参数后，复测FTP下载速率达到40Mbps左右，下行速率正常。
6.注意事项及建议
下载速率低时可以查看MCS为64QAM的比例高不高，占用高阶调制比例低并且BLER较低则可能是DLTARGETBLER设置的过小。
1.3.4案例7：华为eNodeB升级8.0版本默认开启MR功能后导致速率低
1.现象描述
华为ENodeB升级BTSC00SPC130后在外场拨打时发现上传及下载速率慢，CAT4测试终端在好点的情况下进行定点CQT测试，下载最高速率仅在45Mbps左右，上传最高速率仅12Mbps左右。
2.问题分析
通过后台跟踪UU口信令，发现终端在进行业务过程中会周期性上报Meas_Report。在无线环境很好的情况下，不应发生异频/异系统测量。但测试结果表明：终端在不停上报异频测量，并且是周期性上报。对站点升级前后配置数据进行进一步核查，发现升级站点均默认开启了MR功能，在Nastar服务器上开启了同频/异频/异系统的订阅。
后台关闭同频/异频/异系统的订阅。
5.效果评估
后台关闭订阅后再次进行复测，测试结果恢复正常。
6.注意事项及建议
升级版本后需注意核查前后配置数据找原因。
1.3.5案例8：由于PDCCH信道误码率较高导致下载速率波动
1.现象描述
渝北水木青华HL测试有两个现象：
（1）业务过程中出现业务中断的现象；
（2）业务过程速率不稳定，有比较严重的毛刺现象。
业务过程中出现业务中断的现象：在正常业务过程中上行干扰不高，但是出现异常。速率掉坑时候，上行RSSI达到－15db左右，突发的上行干扰很大，此时UE掉线并且频繁尝试重建，过一段时间后，干扰消失，业务恢复正常。
2.问题分析
对测试数据进行分析，由于下行PDCCH偶尔出现误码率较高，上行也出现误码率较高的现象，导致下载速率出现波动。进行扫频测试，确实发现存在一定的外部干扰，但未发现周边有TD站点等干扰源，只能采取参数优化来对问题进行解决。
修改下行PDCCHCCE聚合级别、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等级调低导致。
将TA同步功能参数打开
5.效果评估
将TA同步功能找开后，下载速率正常，不再出现速率陡降情况。
6.注意事项及建议
速率陡降的情况，可以考虑查看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小区确实存在下载速率低问题。
2.问题分析
1、利用LTE核心网EPC内网服务器对辉煌公寓小区入网终端UE进行40mbps带宽的UDP灌包测试；在基站侧对传输PTN来包流量做实时统计，基站侧收包带宽为15mbps左右；在UE终端侧通过测试软件查看收包带宽也为15mbps左右。通过该步骤，确认速率低问题是在基站侧以上网元引入。
2、利用LTE核心网EPC内网服务器对火车站综合楼室分小区入网终端UE进行40mbps带宽的UDP灌包测试；在基站侧对传输PTN来包流量做实时统计，基站侧收包带宽为40mbps左右；在UE终端侧通过测试软件查看收包带宽也为40mbps左右。通过该步骤，进一步确认速率低问题为EPC至辉煌公寓基站间的PTN传输网元引入。
4.解决方案
协调传输排除故障。
5.效果评估
速率恢复正常。
6.注意事项及建议
针对下行吞吐率不达标的问题，按照相关指导书进行逐步核查；涉及到非空口原因导致的调度不足以及吞吐率较低问题，应通过基本手段初步判断问题原因，再求助相关模块进行进一步确认并及时处理；针对基站传输类告警，不容易发现，建议通过基站层显示出来，便于及时发现并及时处理。
1.5传输参数问题
1.5.1案例11：PTNQOS参数限制导致LTE下载速度低案例
1.现象描述
某日在对某小区进行单站验证的过程中，对该小区进行定点的上传和下载业务，发现即使在覆盖“极好点”，该站的下载速度依旧只有8~10Mbps，达不到测试用例的要求。
2.问题分析
使用jperf，对传输进行推送测试，发现主要问题应该在传输上，由于传输的限制导致下载速度最大只能达到10Mbps。最终核查发现华为在PTN上做了些QOS的配置，根据不同业务限制了最高带宽，对下载业务带宽为10M，这样导致了下载的限制。
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地址学习功能未配置。
4.解决方案
为速率异常站点配置PTN设备MAC地址学习功能。
5.效果评估
FTP下载速率恢复正常。
6.注意事项及建议
PTN上的MAC地址学习功能未配置可能导致下载速率低。
1.5.3案例13：由交换机端口配置不正确导致LTETDD下载速率波动问题
在某LTETDD100M峰值下载业务验证中，发现FTP下载业务速率严重波动，从10Mpbs到60Mbps波动，平均速率仅有25Mbps左右，用wireshark工具抓包，可以看到大量重传。由于所有设备搬迁过一次，而在之前的测试中，峰值可稳定在90Mbps左右。
2.问题分析
检查交换机配置：登录到S9303交换机，查询配置后发现，到UGW和USN的端口都被配置成100M不协商，这时候再登录到UGW，发现Gn物理口也都被配置成100M不协商的。由于UGW物理端口既给LTE用，又作为GGSN的Gn口，在3GHSPA+测试时由于遇到下载速率问题，把1000M端口统一改成了100M后没有改回来，而LTETDD100M的DEMO下载业务所需理想的物理带宽为300M，导致LTE下载速率低且严重波动。
将两端端口改成自协商1000M
5.效果评估
速率恢复到90Mbps，没有大波动。
6.注意事项及建议
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。
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.问题分析
经后台查询，该小区存在射频单元驻波告警。
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软件设置里可以设置速度限制，如下图
4.解决方案
Filezilla软件速度限制部分设为不限速
5.效果评估
Filezilla软件设置不限速后，下载速率恢复正常，平均下载速率大于50Mbps
6.注意事项及建议
换新电脑测试前，Filezilla软件设置需要注意。
1.8.2案例17：由于合路器接法不正确引起的下载速率低的问题
对上合村北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小区合路器前端馈线的接法是否正确，整改前合路器前端馈线的连接示意图如下：
整改后合路器前端馈线的连接示意图如下：
4.解决方案
调整合路器接线。
5.效果评估
复测2小区RANK指示为RANK2，下载速率提升至40Mbps以上。
6.注意事项及建议
通过本案例，可以看到天馈系统的问题对LTE网络性能影响比较明显。针对目前LTE很多都和原有系统进行合路的现状，要着重注意合路之后的影响，重点关注合路器接法是否正确，避免因小失大。
1.8.3案例18：LTE室分双路不平衡导致下载速率低
在某LTE站进行单站验证测试，测试发现上传速率只有9M，没达到目标值，下载速率波动较大平均速率为58M
2.问题分析
从测试中发现，接收的两个天线通道功率相差较大，导致下载速率波动较大。
该室分为双流模式，其中1号端口利用原来的室分系统，另外0号端口为新建室分系统，室分设计图如下：
根据如上室分设计图可以看出，利旧室分系统的通道多一个耦合器，另外旧的室分系统存在损耗，导致新建室分系统通道较利旧室分通道天线口功率强。
4.解决方案
现场在新建室分系统增加6db的衰减器
5.效果评估
在新建室分系统增加6db的衰减器后进行测试，上传速率和下载速率都达到目标值，其中上传速率为15.84M，下载速率较平稳为79.52M。
6.注意事项及建议
双流室分场景往往是在以前单流室分的基础上新增1路室分系统建设而成，这样先前的单流室分由于使用时间较长，存在老化或设计缺陷，与新建的1路室分达不到链路平衡，造成了双流场景只有单流的速率，双流站点两个通道的平衡性要求电平差值在5db以内，否则速率不达标可以判定为两条链路不平衡，需进行室分整改。
同时，双流场景下对两条链路的隔离度也有要求，建议室分天线点位间距不要太近或太远，距离约为1.5米性能最好。
2.LTE基站小区无法建立或建立异常问题及案例
2.1无线参数配置
2.1.1案例1：GPS数据配置错误导致LTETDD无法正常开通的案例
新建LTE基站开通时，发现小区总是无法激活，小区激活时，告警信息为“Clockresourceisnotusable”。
2.问题分析
从“Clockresourceisnotusable”告警信息来看，我们初步判断为时钟问题。查看当前GPS的时钟源状态，执行：DSPCLKSTAT，该基站的时钟模式设置为了FREQ频率同步，由于LTETDD系统是时分双工系统，对时钟精度要求很高，要求时间同步。
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个默认参数配置错误，如下图：
修改该宏站小区参考信号端口数为２
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框号配置错误导致。
OMC后台修改LTE小区关联的RRU框号
5.效果评估
修改TDL框号与TD-SCDMA一致后，对该站进行复测，问题解决。
6.注意事项及建议
(1)、参数配置时，LTE网络的RRU的框号配置应与TD-SCDMA一致；
(2)、涉及到TD-LTE与TD-SCDMA共址基站天馈接反的问题，首先应核查两个系统是否都存在该类问题，顺藤摸瓜，找到问题的根因并处理。
2.1.4案例4：LTE基站eNodeBID标识不唯一导致基站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信令，给出的释放的原因为：Aborttheanotherassoc,maybetheeNBGlobalID[:10016]isconflict
根据EPC返回的结果可以判断次故障是由于eNodeBID在EPC侧冲突引起，最终发现在EPC中有两个站eNodeBID相同。
修改该站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回复ErrorIndication消息，以指示E-NODEB删除用户上下文；这个周期在30分钟左右。
华为核心网侧SGW上关闭了GTP-U路径探测功能；
大唐E-NODEB将GTP-U功能设置为可控开关，这样在配合现网各个核心网厂商需求时，可以根据客户和友商的要求设置为打开或关闭。
5.效果评估
问题解决。
6.注意事项及建议
异厂家设备对接过程中，参数协商未统一会出现问题。
2.1.6案例6：由于TDS频点设置问题导致LTE基站无法开启的案例
1.现象描述
黄冈小池LTE基站开通时，总是出现上行频点生效失败提示，因此，LTE小区无法激活。
2.问题分析
查询共站TDS的频点信息，发现有9492这个频点，换算以后是1898.4M。该频点正是LTE所使用的F频段包含的频点。在增加TDS载波时未考虑双模改造LTE的站点。
原TDS侧配置频点为：1，，10093.
LTE频点设置为:38350.
TDS和TDL侧频段存在包含关系。
将9492频点的载波去激活。通过规划将9492改为10079。然后重新激活改TDS载波。
5.效果评估
将9492频点的载波去激活后，LTE小区能正常建立。
6.注意事项及建议
在做规划时，避免出现TDS和TDL侧频段存在包含关系，否则，很容易出现类似问题。
3.LTE切换问题及案例
3.1.1案例1：由于弱覆盖导致成都理工大学LTE小区1与音乐公园LTE小区2切换失败案例
1.现象描述
成都理工大学LTE站点小区1切换到站点成都音乐公园小区2过程中，未完成切换流程就出现重建，导致切换失败，业务中断几秒后，UE重建接入音乐公园小区2中，数传恢复。
2.问题分析
从覆盖角度考虑，如果在切换点上存在着覆盖问题，在某区域上某个方向上由于建筑物等的遮挡，导致UE在该区域内出现信号质量的大幅抖动，切换失败。
从现场来看，切换点区域是处于目标小区覆盖信号很弱的拐角点，天线到该位置的直线空间里有一座较高的楼房，一直怀疑该楼房的阻挡影响信号覆盖。从消息跟踪结果来看，在UE测量到目标小区的RSRP比服务小区的RSRP差值超过切换门限发出测量报告，但是源小区信号质量下降太快没有收到测量报告，从而使UE只能在目标小区发起随机接入过程。
4.解决方案
通过调整切换相关参数，提前进入切换流程，原小区默主认小区偏置为０dB，将邻区的小区偏置修改成1dB~2dB
5.效果评估
修改小区偏置后，切换正常
6.注意事项及建议
在现实场景下，往往会出现许多切换过晚现象，可以通过调整切换相关参数配置来提前切换达到解决切换失败的目的。
参数修改过程有一个注意的问题是，修改切换门限和切换迟滞时间固然也可以达到提前切换的目的，但是因为这两个参数都属于小区级参数，一旦修改，将会造成和所有邻区的切换点发生改变，因此修改后风险较大，大多数情况下都不应修改，因此一般可以通过修改CIO配置参数达到相同的目的，而其只对特定的小区有影响。
3.2无线参数配置
3.2.1案例2：爱立信LTE小区DCI配置错误导致切换失败
1.现象描述
在进行簇优化过程中，进行FTP下载业务时发现在路测过程中切向某小区时出现切换失败，更换源小区无改善，而在前期簇优化的拉网测试中，该小区切换正常。
2.问题分析
前期测试终端为海斯数据卡，本次测试使用创毅Warpdrive5000芯片，目前包含Warpdrive5000芯片在内的多种芯片尚不支持PDCCHDCIFormat1C，而爱立信基站PDCCHDCIFormat默认为1C
联系后台核查该小区PDCCHDCIFormat，经核查该小区前期基站复位后DCIFormat为1C，修改为目前全网设置的1A。
5.效果评估
修改该小区该小区PDCCHDCIFormat后，对该小区进行复测，多次复测切换均成功，无异常。
6.注意事项及建议
3GPP协议里在36.212的5.3.3.1里对PDCCH的DCIFormat定义为：
Format1A:用于下行传输，单码字PDSCH调度，下行数据触发随机接入过程；
Format1C:用于紧凑型单码字PDSCH调度
目前青岛LTE为试验网，网络整体出于空载状态，全网DCIFormat均采用1A。TD-LTE也处于发展初期，很多终端芯片尚不健全，对PDCCHDCIFormat支持不全面。如果后期试商用，需提前针对商用终端进行评估，避免部分终端对协议支持不完善影响用户感知。
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但无法切换，或切换过慢。
而实际的某些优化场景中，必须要发生乒乓切换才能保证业务连续性。针对类似场景从用户感知出发，可以考虑关闭防乒乓切换算法，或降低乒乓切换判断时间以允许乒乓切换。
5.效果评估
关闭防乒乓切换算法，或降低乒乓切换判断时间,切换成功。
6.注意事项及建议
乒乓切换对速率、掉线率和信令负荷都会有一定影响，应当尽量避免发生乒乓切换。抑制乒乓切换有效的方法有：
&控制好覆盖，合理设置切换带；
&适当调整A3参数（迟滞、偏移值、触发时延），以及CIO；
&合理应用防乒乓切换算法。
3.2.3案例4：由切换门限设置错误导致某LTE站无法进行异频切换
1.现象描述
在用Quanta1K3的设备进行测试蠡园移动全球通大楼过程中，室分小区的E频段为39150、PCI是189切换到室外宏站D频段为38050、PCI是104无法进行异频切换，在从室外宏站切换到室分小区E频段也无法进行异频切换，但可以进行站内同频切换和插拔后小区初搜。
2.问题分析
该站A1事件（停止异频测量）设置的门限是４，即相当于接收电平大于-136dBm时候停止测量异频；A２事件（开始异频测量）设置的门限是６０，即相当于接收电平大于-８０dBm时候停止测量异频；这两个参数设置的逻辑冲突，当服务小区电平低于-80dBm的时候UE触发A2开始异频测量，然后下一个时刻UE立即判断该触发A1停止测量了，所以才出现下面这种频繁A1A2上报的情况。
将A2对应的参数a2ThresholdRsrpPrim的值更改为-90，把A1对应参数a1ThresholdRsrpPrim更改为-80
5.效果评估
异频切换成功，不再频繁上报A1/A2事件。
6.注意事项及建议
有逻辑关系的门限需注意设定。
3.2.4案例5：TAU与X2切换冲突导致切换失败并掉线
1.现象描述
观察话统发现某小区掉线严重，并且都是由于切换失败导致的掉线。
2.问题分析
从无线侧分析看，所有切换失败导致的掉话都是因为X2切换PathSwitchTimeout，即等待MME的PATHSWITCHACK超时。
MME目前的实现方式是，当MME正处在处理终端的TAU流程的中间状态时收到了Enodeb发来的PATHSWITCHREQ消息，除了正在等待TAUComplete消息状态下会处理PATHSWITCH流程，其他状态下均直接返回PATHSWITCHFAILURE。
这样就使得处于TAL交接处的小区发生TAU概率较大，同时MME的配置发现许多IMSI号段的用户均开启了TAU鉴权。TAU流程中发起鉴权，增加了TAU流程的中间状态，也增加了TAU整个流程的时间，所以也增大了TAU与X2切换冲突的概率。
现场通过按照默认配置修改鉴权暂时规避掉线。
5.效果评估
修改后掉线率显著下降。
6.注意事项及建议
在TAL区，可能会出现由于TAU更新导致X2切换成功率增高的情况。
3.3核心网参数
3.3.1案例6：LTE核心网鉴权关闭导致切换失败
1.现象描述
在某TDD-LTE实验网，站间小区切完后直接RRCCONNECTIONRELEASE，切换失败率增加。
2.问题分析
通过后台信令跟踪发现UE上发切换完成信令“RRCConnectionReconfigurationComplete”后，核心网直接下发“RRCCONNECTIONRELEASE”给UE，导致UE重新建立RRC连接；
前后台的信令对比分析得出，由于核心网下发了RRC拆链的信令，导致切换不成功，故问题可以暂定为核心网存在问题。
后通过与核心网人员确认，核心网将鉴权功能关闭，导致在站间切换时，UE鉴权被拒，从而导致切换完成后直接RRC释放。
核心网打开鉴权功能。
5.效果评估
切换问题解决。
6.注意事项及建议
切换失败可能是核心网参数设置原因。
3.4传输参数
3.4.1案例7：LTE基站S1口少配导致切换成功率低处理案例
1.现象描述
在LTE网络KPI指标监控过程中发现某一区域的几个站点切换成功率极低，严重影响全网切换类指标，其中某站切换入失败次数每天达到4600多次。
2.问题分析
查询周边站点切换出失败原因全部为“目标小区回复切换准备失败消息”导致切换出准备失败。后台信令跟踪对吉州区人民广场标准X2口进行跟踪，发现切换准备失败的失败原因值为：传输不可用。
查询基站IPPATH是否设置合理，结果发现S1接口配置为1条，IPPATH资源有限，所以相邻站点切到该站的成功率很低。
增加到S1接口的IPPATH由1条到8条（现网标准为8条）
5.效果评估
将S1接口的IPPATH由1条到8条后，切换成功率恢复正常。
6.注意事项及建议
对LTE基站配置IPPATH链路时，需配置8条用于S1链路；如果S1链路配置少于8条将会出现S1链路传输资源不足的问题，导致基站E-RAB建立失败，系统内切换失败高；后期新开站点配置时需注意IPPATH链路是否正确配置，避免类似问题出现。
4.LTE终端接入问题
4.1无线参数配置
4.1.1案例1：TD-LTE帧同步参数配置错误导致上行干扰，造成终端有信号无法接入
1.现象描述
新建站LTE基站70530三个小区存在有信号无法接入现象。现场测试：场强正常，无硬件告警，终端无法接入。
2.问题分析
提取故障站底噪，发现该站三个小区底噪都偏高，关闭周边基站后，故障站底噪正常，由此可以判断是周边基站对故障站造成干扰导致故障站底噪高。用后台扫频工具以1RB（180KHz）带宽为单位，记录故障站底噪，发现RB47-RB52底噪高，对比LTE帧结构，RB47-RB53处是主、辅同步信号和广播信号，经过分析研究，判断是周边基站的第一个下行时隙落入故障站的上行时隙，从而造成周边基站的主同步信号、辅同步信号和广播信号对故障站的上行RB47-RB53产生干扰。排除GPS故障后，将问题定位在是否自动调整数据帧头开关上，周边基站该开关是关闭状态，故障站是打开。
关闭故障站是否自动调整数据帧头开关。
5.效果评估
关闭开关后，故障恢复。
6.注意事项及建议
是否自动调整数据帧头开关是基站自动计算和调整帧头位置，如果要打开该开关，必须全频段站点全部打开。如果部分基站打开，部分基站关闭，会造成打开的基站间与不打开的基站间的不同步。
4.1.2案例2：TDL完整性保护算法设置错误导致部分终端无法上网
1.现象描述
在T市TDD-LTE实验局项目中，新开通的一个站点终端A（MF91S）可以拨号上网，而终端B（MF820S2）无法拨号，点击拨号软件的连接，提示连接失败。
2.问题分析
为了定位问题，进行了小区信令跟踪，当问题终端拨号时，会伴随初始化上下文建立失败信令，查看信令发现原因为“加密或完整性保护算法不支持”。查看该站点的安全管理，发现该站点的完整性保护算法与其他站点设置不一样，该站设置为128-ElA2，而其他站点设置为128ElA1
修改该站点完整性保护算法与其他站点一致
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.211Table5.7.1-3PrachConfigIndex与PreambleFormat对应关系，可知该室分小区PreambleFormat为４。PreambleFormat4仅用于TDDLTE，它时域长度较其他PreambleFormat明显偏短，占用特殊子帧的ＵpPTS的两个符号。
将室分小区的PrachConfigIndex从51修改到3，采用PreambleFormat0
5.效果评估
修改后多次测试该小区切换成功率和接入成功率明显改善，与周边小区相比无异常。
6.注意事项及建议
PreambleFormat4在特殊时隙的最后部分（即UpPTS）进行发送，这样利用UpPTS的资源完成上行随机接入的操作，避免占用正常子帧的资源。这是针对半径较小的微型小区的一种优化，可以在不占用正常时隙资源的情况下，利用很小的资源承载PRACH信道，有助于提高系统上行吞吐量，也有助于提高上行业务信道的覆盖性能。
但在实际工作中采用PreambleFormat4提升小区上行吞吐量时，需注意由于其时域长度要远小于其它4种PreambleFormat，因此其链路预算相对明显较低，其链路预算所能够支持的覆盖半径相应的明显偏小，仅适用于覆盖半径较小的场景，特别是密集市区、室内覆盖或热点补充覆盖等场景。同时根据网络环境不同，采用PreambleFormat4时其实际覆盖半径不同，如采用PreambleFormat4则开通后需着重进行接入性测试，确保其覆盖范围内终端接入正常。
本文源自网络如有侵权联系我们删除
网优雇佣军微信订阅号：hr_opt
以下内容已过滤百度推广
日&-&如图,lte上行信号的处理流程和下行相比,为什么没有层映射和预编码两个环节呢???... 如图,lte上行信号的处理流程和下行相比,为什么没有层映射和预编码...&&普通
southwestjiaotonguniversitymasterdegreethesisonthetdd—-ltedownlinksignalgenerator...92.1tdd.lte 系统下行链路信号处理流程………92.1.1tdd.lte 无线帧结构……...&&在线文档&结构化
针对以上两个技术难点,本文研究了3gpp lte下行接收系统中dsp技术及其vlsi实现的关键技术,设计了低复杂度高性能的关键信号处理模块,并从系统级对性能-运算复杂度可...&&普通
日&-&b 774 lte同步信号用来确保小区内ue获得下行同步,在信道中的位置和长度都固定,...完成上下行数据系带处理功能 提供与rru通信的cpri接口 实现跨bbu系带...&&百度文库
lte上行信号的处理流程和下行相比,为什么没有层映射和预编码两个环节呢???... lte上行信号的处理流程和下行相比,为什么没有层映射和预编码两个环节呢???关闭...&&普通
日&-&优化难度要高 参考答案:b 当前作答:b 7、lte 同步信号用来确保小区内ue 获得下行同步,在信道中的位置和长度都固定,在频域 上占用系统带宽中心位置共()...&&普通
日&-&题填空客观题 lte的物理层上行采用 技术,下行采用 ...a.参考信号接收电平 b.接收信号强度指示 c.参考...设备管理、数据采集、数据呈现、数据处理每题2...&&普通
日&-&在空中接口上,lte系统定义了无线侦来进行信号的传输,1个无线帧的长度为10ms。lte...(5)具有上下行信道互惠...&&普通
日&-&(业务相关) e-rab建立阻塞率 e-rab建立成功率 1 enodeb侧处理s1接口控制面...则需要随机接入 3 下列对于lte系统中下行参考信号目的描述错误的是: 下行...&&普通