北京联通FDD-LTE正常案例分析报告--Normal Release
无线网络规划-掉话LTE释放过程
感谢您的聆听与观看
Lorem ipsum dolor sit amet, consectetur adipisicing elit.Lorem ipsum dolor sit amet, consectetur
2．RRC连接释放
RRC连接释放流程如下图：
RRC连接释放流程
通常情况下，以下情形会触发EUTRAN下发RRC Connection Release消息。
（1）RRC激活检测定时器超时。 （2）UE发起Detach之后。 （3）TAU之后。 （4）核心网触发load Balancing TAU Required之后
任务6 掉话分析
LTE释放过程
LTE释放过程
LTE释放分为E-RAB释放和RRC释放。它们是两个不同的过程，RRC释 放是在E-RAB释放之后。
1．E-RAB释放
E-RAB释放分为eNB发起和MME发起两种情况，由eNB发起的释放比MEE发起 的释放多一条S1_UE_CONTEXT_RELEASE_REQUEST消息。
对于异常释放，原因n”、 “unspecified”等。一般触发异常释放的机制有以下几类：
（1）空口RRC/NAS AM模式信令交互失败。 （2）空口重同步失败。 （3）空口RLC 达到最大重传次数；（包括上行/下行，SRB/DRB）。 （4）eNB/MME侧资源拥塞。 （5）传输故障。 （6）eNB/MME内部异常。
（2）如果RRC Connection Release消息中的releaseCause为load Balancing TAU Required，UE将在离开RRC_CONNECTED时执行操作，并带上 releaseCause为load Balancing TAUR equired；如果releaseCause为other， 则在离开RRC_CONNECTED时执行操作，并带上releaseCause为other。
7#LTE室分设计及案例分析
模测结论： 在天线口导频功率为0dBm，在货架较低的超市，可以覆 盖的半径为20米左右，边缘场强为－85dBm若货架较高， 覆盖半径缩小。 建议覆盖半径10～15米。
2、LTE室分模测
3G模拟测试案例
写字楼模拟测试
1 2 12m 20m 10m 3 4 5 8m 12m
LTE室分系统模拟测试
专业市场模拟测试
(一) LTE室内覆盖系统工程的建设应综合考虑网络性能、改造难度、资源情况、 投资成本等选择最佳建设模式，应尽量展示LTE的性能特点并保证网络质量，
并不影响现网系统的安全性和稳定性。
(二) LTE室内覆盖系统建设应综合考虑2G、3G和LTE共用的需求，并按照相关 要求，促进室内覆盖系统的共建共享。多系统共存时系统间隔离度应满足 要求，避免系统间的相互干扰。 (三) 建设室内覆盖系统的物业点应能保证优质的室内覆盖，同时要控制好室内 信号，避免对室外构成强干扰。 (四) LTE室内覆盖系统建设应保证扩容的便利性，尽量做到在不改变分布系统
京信LTE技术培训系列—室分工程
LTE室分设计及案例分析
京信通信系统（中国）有限公司
网络技术研究部/应用技术部 2013年5月
课程目标及培训对象
本课程学习目标
熟悉LTE室分设计原则 掌握LTE室分勘测知识 掌握LTE室分设计知识
了解LTE室分试点案例
本课程培训对象
BD全体、 工程技术人员 -- 设计/督导/测试/优化工程师
3）对该室内分布话务、用户投诉情况、室分信源和有源设备告警信息进
行查询，确保原室内分布系统覆盖效果良好、设备运行良好无告警、没有 用户投诉，若存在弱覆盖、用户投诉未解决、设备有故障等问题，则需进 行室分优化整改后，再进行LTE室分双通道改造。
FDD-LTE干扰分析排查_v1.0讲诉
盖。 5. 如为外部干扰，使用排除法和扫频定位法结合来确定。
内部干扰—GPS时钟故障
如果FDD LTE使用GPS时钟，基站GPS时钟存在故障时，则本基站 就会和周边基站时钟不一致，也就是时间帧不一致，这样就会 影响切换，给别的站点带来严重干扰。
处理方法—外部干扰排除
2. 经过实地扫频，通过八木天线进行扫频定位，对2扇区干扰信号主要来源于京 开高速以东居民区内。
处理方法—外部干扰排除
3. 在居民区域内扫频发现该区域内移动、联通信号覆盖差，当地居民安装了比 较多的手机信号放大器，在信号放大器天线附近能够扫到有LTE上行频段内的 宽带干扰信号，与天面扫频的干扰信号波形类似。
OMC 指标
接通率 掉线率 切换成功率
干扰排查目的
明确是系统内干扰还是系统外干扰
对于系统外的干扰，要提供相关分析材料推动局 方找当地无线电管理部门去定位消除干扰 对于系统内的干扰，尽量消除，消除不了的，采 用相关算法或措施合理规避
目录
• 概述 • 干扰原理 • 排查手段及方法 • 异系统干扰分析 • 案例
1. 目前上行受干扰频 带主要在前15M内， 受影响RB数75个左 右。
2. 目前后台取出RSSI 指标为-60dbm
处理方法—内部干扰排除
1. 站点无告警，且参数配置正确。说明基本不是站点故障或者参数配置 导致干扰。
2. 将基站小区关断，RRU功放关断，小区的RRU无输出功率，后台查询 RSSI值几乎无变化，说明排除站点施工工艺不好抬高了RSSI。
频段 中国联通
FDD-LTE下行PRB平均利用率及负荷高优化案例
LTE下行PRB平均利用率及流量高优化案例1、问题描述全网指标统计发现临海吉利学院周边负荷较高，LF_Z_临海吉利学院专家楼流量平均每天在200G以上，下行PRB平均利用率在37.87%左右，用户数在140人左右，12月1-30日指标统计情况如下：LF_Z_临海吉利学院专家楼_49问题小区指标情况统计LF_Z_临海吉利学院专家楼_4问题小区指标情况统计2、分析处理过程1）查询基站状态该站无告警，小区状态正常；2）查询基站信息，该小区为双载波载三扇区，日均流量200G，RRC连接最大用户数日均169个，为高话务双载波基站，基站信息如下：表2 LF_Z_临海吉利专家学院楼基站信息3）由于增加基站难度较大，观察地形发现，LF_Z_临海吉利集团_51小区有重叠覆盖区域，但是该小区话务基本正常，因此可平衡覆盖来调整问题小区负荷；表3 LF_Z_临海吉利集团_51指标情况问题基站位置及覆盖方向基站分布图如下：、图1 问题基站位置及覆盖方向基站分布图4）尝试降高话务小区功率，提升周边低话务小区功率，前期对LF_Z_临海吉利专家学院楼_49降功率后，查看小时参数有所改善，其后校园内有学生投诉，故又满功率发射。
调整LF_Z_临海吉利集团_51扇区方位角及下倾角增强对周边区域的覆盖，电子下倾角8°调整到2°。
调整后查看话务发现指标只改善一点，LF_Z_临海吉利集团_51话务有所增强。
2、效果由于是覆盖学校站点，校园内集团用户众多，经与县局沟通后再调整的基础上再实行载波扩容，2月份LF_Z_临海吉利集团_4开通后，提取LF_Z_临海吉利专家学院楼_49和4调整前后指标对比，调整后指标明显改善，下行PRB平均利用率由日均37.87下降至30.93%，上行PRB平均利用率、流量和RRC连接建立最大用户数也均有明显下降；LF_Z_临海吉利集团_51和LF_Z_临海吉利集团_4下行PRB平均利用率、上行PRB平均利用率、流量和RRC连接建立最大用户数均明显上升，基本达到平衡负荷的目的。
FDD-LTE单验以及报告流程
FDD站单验测试步骤一、室外单站验证测试前准备事项：1、出发前，联系后台查询一下站点是否有告警。
2、到达站后，联系后台。
3、寻找好点RSRP为-80以内，SINR为25以上；在找不到好点的情况下，可以用中点代替。
中点RSRP为-90以内，SINR为15以上（中点达标：上传25M，下载45M)4、测试必备设备(车辆、测试电脑、终端、硬（软）狗、GPS)二、室外单站验证测试步骤：1、打开probe测试软件→连接设备，如下图导入工参表点击图标（crtl+E）→在弹出的对话框system中选LTE，选LTE工参表单击→,单击→选LTE→分别单击，三个图标显示如下图：导入Mapinfo Tab地图。
测试可以开始了2、PING在开始→运行输入cmd→cd\→回车，如下图：输入命令“ping 127.1.1.1 -n 100 >M_XXXXX(站名)-S1-PCI50-PING-1.txt”其中“数字50为该扇区PCI，“M_XXXXX”为站名，测试时根据所测站点进行修改“，然后回车出现如下图（范例）开始PING后记录LOG，PING结束后停止记录LOG（LOG命名方式：Probe_20130516171626-M_XXXXX-S1-PCI50-PING-1），每个扇区PING做2次，第二次PING 命名为：“M_XXXXXXX-S1-PCI50-PING-2.txt”。
3、上传（UL）灌包在命令中输入“iperf -c -u -b 50m -i 1 -t 9999 -P 2 -l 1000”。
→ENTER如下图所示待速率达到40M左右时开始记录开始后记录LOG3分钟3分钟后停止记录LOG，截图同样记录两次再停止灌包Ctrl+C停止上行灌包命名为Probe_20130516171626-M_XXXXXXX-S1-PCI50-UL-1 截图命名：M_XXXXXX-S1-PCI50-UL(截图采用HooNetMeter软件来截图范例UL4、FTP下载FTP下载采用FileZilla软件来下载，将FileZilla中下载线程设置为10，打开FileZilla 单击“编辑‘→设置如下图：拉满10个下载任务后待速率达到100M左右开始记录LOG同样3分钟之后停止记录，截图DL同样记录两次删除FTP下载任务FTP下载命名为“Probe_20130516171626-M_XXXXXX-S1-PCI50-DL-1“截图命名：“M_XXXXXX-S1-PCI50-DL“5、ATTACH测试导入Attach_Probe脚本→,运行如下图:6、0度和8度测试‘空载记录2分钟即可，不做任何业务，但需注意0度和8度的RSRP、PUCCH需相差5以上。
北京联通LTE接入专题分析报告
LTE接入专题分析报告1.1项目背景随着LTE网络大力建设与业务推广，LTE网络呈直线上升趋势，但随之带来的问题也日益明显，北京联通无线环境的多样化、复杂化，主要呈现在LTE网络用户下载速率，拥塞扇区增加，用户感知下降等问题。
北京联通本着为用户着想，网络为用户更好服务的中心原则，让LTE网络为用户带来更好的体验感受，开启LTE接入专项和其他专项切实保障LTE 网络质量，提高LTE网络用户使用感受，提升LTE网络用户感知。
1.2优化容对北京联通以网络结构分析、KPI指标性能分析、接入事件分析、MR（TA）分析四个维度为切入点，OMStar和mapinfo其它工具进行辅助组合分析如下：1.2.1网络架构分析网络架构在对整网中的一定规划，合理的网络架构规划可以解决在网络中由于网络规划不够合理导致的接入，切换，掉线和速率低的问题，这些问题都是由于不合理的网络架构导致的交叉干扰。
LTE网络结构和全网中SINR（CQI）、接入带来决定性影响，分析方法如下：第一步：LTE设备告警导致对网络接入有影响的进行处理;网络中主要的告警名称和告警ID。
通过对设备中的告警名称进行分析，特别是告警对网络中用户感知和KPI有影响的进行提取和处理。
特别是设备的能力下降，时频不同步，射频单元驻波告警等。
处理集中和对指标影响较大的告警及时高效的处理。
第二步：站点的开通率，站点的完好率，方位角和下倾角受限等问题；（1）：站点的开通率对全网中特别是在覆盖较差，影响网络指标影响，用户感知特别差区域，在对要尽快开通站点在时间跟踪上要及时，设备的正常运行。
以四区为例：规划站点和开通率跟踪表：四区新规划站点和开通率.xls规划站点图：（2）完好率对网络中进行站点由于一定原因导致站点关闭，看站点是否还可以开通，站点是否要做RF进行调整，邻区关系是否要进行修改等问题。
（3）扇区方位角不小于65，会可能引起干扰；重叠覆盖，浪费资源等问题，处理该扇区问题，特殊站点进行特殊处理。
CSFB正常信令流程及问题分析
CSFB业务正常信令流程及问题分析一、正常CSFB信令流程按照北京联通FDD-LTE新站入网验收测试规范V8进行CSFB测试，正常信令流程如下：1、CSFB业务发起图1图2UE向eNodeB发起ExtendServiceRequest，此时说明开始发起CSFB业务。
双击ExtendServiceRequest信令也可以看到此时服务类型是service-type:mobile-originating-cs-fallback即手机主叫CSFB（如图2红框所示）。
2、LTE重定向图3如果CSFB业务可以正常进行，那么eNodeB会向UE发从RRCConnectionRelese信令，此时将进行LTE向WCDMA的重定向。
双击此条信令，在msg中给定要重定向的频点，进行测量，如果符合重定向的条件，上报测量报告，实行重定向。
图4图5如图4与图5所示，UE已从LTE重定向至WCDMA，频点为10713。
3、重定向WCDMA后正常语音业务UE重定向至WCDMA后能够按正常语音呼叫流程进行，而ExtendServiceRequest至Alerting信令之间的间隔即为此次CSFB业务时延。
图64、通话结束后返回LTE网络占用WCDMA通话结束后，应直接返回LTE网络。
由于此时正处于LTE建站初期，WCDMA如没有向LTE开启Fast Return开关，手机不会自动返回至LTE网络。
二、 CSFB问题排查通过这几天对新开站进行CSFB业务测试，发现部分基站CSFB业务存在问题，主要出现两种问题：1、LTE基站TAC配置与WCDMA邻区的LAC不一致如果LTE基站TAC配置与WCDMA邻区的LAC不一致，容易导致UE无法找到对应的WCDMA服务小区，导致CSFB无法做业务。
图7图8如图7所示，由于LTE基站TAC配置与WCDMA邻区的LAC不一致，UE无法进行CSFB业务，一直在重复做附着与分离。
双击Attach Request信令消息，会看到图8红框中的消息，此消息说明MSC未能接入，LTE不能重定向至WCDMA进行CSFB业务。
北京联通FDD-LTE案例分析报告--安全模式失败导致E-RAB建立失败案例--security Mode Failure
北京联通FDD-LTE案例分析报告--安全模式失败导致E-RAB建立失败案例security Mode Failure事件:故障描述:在后台在进行信令跟踪中对UU，X2，S1进行提取，在该站点FBJ900111系统信令跟踪过程中出现初始建立失败，eNodeB向MME发送原因值。
RRC_SECUR_MODE_FAIL的信令条件，UE在向eNodeB的信令里面出现radio Network –security Mode Failure-r8,导致S1_INITIAL_CONTEXT_SETUP_FAIL失败。
故障分析:MME向eNB发送initial Context Setup Request消息，请求建立初始的UE上下文，包含E-RAB上下文、安全密钥、切换限制列表、UE无线性能以及UE安全性能等等。
初始建立的正常流程：请求建立初始正常流程图1本事件案例事件流程图2对网络中的问题分析，手机在接入以后，基站向MME发送了初始的消息上去，等待近6S的时间，MME收到以后进行了鉴权和加密的请求，在进行鉴权请求的同时，也在NAS上进行安全模式的建立，手机回应时失败（RRC），导致在RRC_SECUR_MODE_FAIL，UE直接失败，eNodeB直接进行了释放，S1AP_INITIAL_CONTEXT_SETUP_FAIL导致的接入失败。
以下几种原因易导致这种情况：1）初始消息未被基站正确接收：基站对在接入时收到的信息，针对这个信息进行发送UE的安全模式出错而有异常，因此安全模式出错上的问题。
2）RRC安全模式配置错误：安全模式关系配置错误会导致接入请求“RRC_SECUR_MODE_FAIL”无法发送，可能导致本案例里面无该现象。
3）设备故障：由于基站内部状态机设计存在缺陷，本案例里面的无该现象。
这种情况，一般可以采用重新启动基站的方法暂时消除。
具体排查过程如下：1：RRC上安全模式配置，看网络是否安全模式无问题情况；2：怀疑设备问题，重启设备，复测问题依旧；3：怀疑UE问题或者配置错误导致。
LTE路测案例分析报告
LTE路测案例分析报告LTE （Long Term Evolution）是第四代移动通信技术的标准之一，其提供了更高的数据传输速率和更低的时延，以满足用户对高速移动宽带数据服务的需求。
LTE的引入和部署对移动网络的覆盖和性能产生了重大影响，因此进行LTE路测案例分析是非常重要的。
本文将以一次LTE路测案例为基础，对路测数据进行分析和解读，以评估LTE网络的覆盖范围、速率和性能。
本次LTE路测案例是在一些城市进行的，目的是评估LTE网络在城市中各个区域的覆盖情况和性能表现。
路测使用了专业的测试仪器和软件，收集了大量的数据，包括信号强度、信噪比、RSRP（Reference Signal Received Power）、RSRQ（Reference Signal Received Quality）等。
以下是对数据的分析和解读：首先，我们关注LTE网络的覆盖情况。
通过分析信号强度和RSRP数据，我们可以确定网络覆盖的强弱程度。
我们发现，在城市中心区域，信号强度较高，RSRP值在-60dBm到-80dBm之间；而在城市边缘区域，信号强度较低，RSRP值在-85dBm到-100dBm之间。
这表明LTE网络在城市中心区域的覆盖较好，在城市边缘区域的覆盖相对较弱。
其次，我们需要分析LTE网络的速率和性能。
通过分析信号质量和RSRQ数据，我们可以评估网络的速率和性能。
我们发现，在城市中心区域，信号质量较好，RSRQ值在-6dB到-9dB之间；而在城市边缘区域，信号质量较差，RSRQ值在-12dB到-15dB之间。
这表明LTE网络在城市中心区域的速率和性能较好，在城市边缘区域的速率和性能相对较差。
最后，我们可以基于路测数据，提出一些改进建议。
首先，对于城市中心区域的覆盖，可以进一步优化网络资源分配和功率控制，以提高覆盖范围、速率和性能。
其次，对于城市边缘区域的覆盖，可以考虑增加基站密度，以增强信号强度和质量，提高网络覆盖和速率。
LTE 路测案例分析报告
1覆盖类1.1概述覆盖类问题只要涉及弱覆盖、越区覆盖、过覆盖、无主导小区、上下行不平衡及导频污染等.在TD-LTE中一般认为RSRP<-110dBm,认为是弱覆盖.越区覆盖：由于基站天线挂高过高或下倾角过小引起的该小区覆盖距离过远,从而越区覆盖到其他站点覆盖的区域,并且在该区域终端接收到的信号电平较好.过覆盖：指网络中存在过度的覆盖重叠,容易引起干扰和乒乓切换；无主导小区：指某一片区域内服务小区和邻区的接收电平相差不大,不同小区之间的下行信号在小区重选门限附近的区域,并且无主导覆盖的区域接收电平一般或者较差,在这种情况下由于网络频率复用的原因,导致服务小区的SINR不稳定,可能发生空闲态主导小区频繁重选、连接态频繁切换,无主导覆盖也可认为是若覆盖的一种.导频污染：指在某一点存在过多<一般认为大于等于3个>的强导频,但却没有一个足够强的主导频；1.2弱覆盖1.2.1弱覆盖分析造成弱覆盖的原因有：1、规划的站点由于种种原因如物业等没有开起来；2、天线方位角、下倾角不合理,如下倾角过低；3、在站建起来后,由于新建楼宇的遮挡,导致部分区域RSRP很差；4、站点过高,如四十多米或更高,会造成塔下黑5、下倾角、方位角由于条件所限,无法调整,如：美化邓杆站点不方便调整天线的方位角<3个天线方位要一起转,因为外面有罩子盖住下倾角无法调整,如科技园四、海德三路等；深大校园里站点天线都是放在美化罩子<长方体的箱子>里面,对天线的下倾角和方位角调整范围也有影响<如：深大、深大南校等>>.针对以上原因建议的方案有：1、推动客户将规划站点尽快开起来；2、调整天线方位角、下倾角到合理位置；1.2.2天线方位角不合理导致弱覆盖现象：科技园三的102和104小区由于天线被住宅楼遮挡,导致覆盖区域内部分道路信号较弱,存在弱覆盖,科技园三站点周围的地物如图：图表 1科技园三周围地物调整前道路的电平值如下图：图表 2优化前科技园三覆盖措施：将104小区的方位角由20度调整为40度；将102的方位角由150度调整到100度；调整后弱覆盖得到改善,如下图：图表 3优化后科技园三覆盖1.2.3天线方位角下倾角不合理导致的弱覆盖现象：东都花园附近有小段路RSRP低于-110dBm,该路段属于东都花园和龙中站点主覆盖区,需要调整东都花园和龙中站的天馈方向角和下倾角加强覆盖.调整方案见下表,表格 1东都花园天馈调整方案调整后弱覆盖得到解决,调整前后的图见下：图表 4东都花园调整前覆盖调整后的图见下：图表 5东都花园优化后覆盖1.3越区覆盖1.3.1越区覆盖分析越区覆盖经常因为一些超过周围建筑物的站点,发射信号沿丘陵地形或道路可以传播很远,在其他基站的覆盖区域形成了主导覆盖,产生"岛"的现象,因此,当呼叫接入到远离某基站而仍由该基站服务的"岛"形区域上,并在小区切换参数设置时,"岛"周围的小区没有设置为该小区的邻区,当终端离开该"岛"时,就会立即发生掉话.且即便配置了邻区,由于"岛"的区域过小,也会容易造成切换不及时而掉话.解决建议：1、避免扇区天线的主瓣方向正对道路传播,可调整扇区的天线方位角,使天线主瓣方向与街道方向稍微形成斜角,利用建筑物的遮挡减少电波因街道两边的建筑反射而覆盖过远的情况.2、调整扇区天线的下倾角,如果条件允许优先调整电子下倾角,其次调整机械下倾角；3、降低天线高度4、在不影响小区与业务性能前提下,降低发射功率；1.3.2越区覆盖案例214小区的电子下倾6度,机械下倾5度,由于美化罩缘故,下倾角无法再往下压；但小区在1.26km还有信号且电平为-103dBm,在700多米时信号强度达到-93dBm,故在不影响覆盖的前提下需要适当降功率,将功率降低2dB后,信号消失,如下图图表 6科技北调整前越区覆盖图图表 7科技北调整后覆盖图表 8科技北覆盖路段基站分布注：该路段由于高新公寓站没开起来,有小段弱覆盖,当电平为-103时会切向214小区.2干扰类2.1PCI模3相等干扰科技园E,58小区上报了114的MR,181和服务小区58模3相等,下发了切换命令,UE没收到,由UE侧可看到此时SINR很差为-6.83;图表 9科技园58基站侧LOG图表 10科技园58信道状况图表 11科技园58终端侧LOG措施：将科技园四1小区的PCI由181调整为182,0小区的PCI由180调整为181,2小区的PCI182调整为180,干扰得到规避.注：在调整PCI时也要将配置该小区为外部邻区的基站的外部邻区中的PCI修改过来.2.2GPS失锁干扰现象：高科E站点小区1覆盖区域近点接入困难,拉网在此小区覆盖区域下必然掉话且长时间无法接入.在M2000信令跟踪下的干扰检测中跟踪高科E的1小区.发现每个RB的功率都比正常-110dBm高了30dB左右.RSSI同时也高了20dB左右,如下图：在故障小区覆盖区域,实测,信号强度大于-70dBm的时候才偶尔能接入.Probe和基站侧信令分析看到,eNodeB未发切换命令或者切换重配消息UE没收到,导致每次经过此处必然掉话.后发现M2000中,中兴通讯站点有GPS告警"GPS线路短路故障",在MML中将中兴通讯站点去激活,高科站点的干扰马上消失.由此确定是中兴站点GPS失步,导致周边区域同频干扰严重,更换中兴站点GPS后,故障消失.3切换类3.1基站不下发切换命令该问题的前提是UE上报了切换的MR,基站侧也收到了MR,但没有收到切换命令,可能的原因有邻区漏配或邻区配错、下发重配置没收到重配置完成和同频邻区中有PCI相等的邻区.下面以案例形势一一展开.3.1.1邻区漏配&邻区配错一、邻区漏配从基站跟踪看到基站收到了大量的MR,没有下发切换命令,导致掉话,如下图.从probe 上看信道质量不差没到解调门限以下,因为没有下发切换命令而掉话,可以查看是否为邻区漏配.中兴通讯179向科技园四182发起切换,上报了切换的MR,基站侧也收到了MR,没有下发切换命令,之后读系统消息,发起重建,重新接入到MR中小区,即科技园四182,可以确认为邻区漏配.Probe和基站侧log如下：图表 12邻区漏配UE侧无线环境图表 13邻区漏配UE侧LOG图表 14邻区漏配基站侧log邻区漏配有2种情况: 1、同频邻区和外部小区都没有配置;2、配置了外部邻区,但没配置同频邻区；建议：添加邻区注：也可通过对比SIB4中的邻区信息与MR中的邻区PCI发现是否为邻区漏配,如下图；图表 15SIB4消息内容二、邻区配错下面为外部小区和同频邻区均已配置,且同频邻区也配置正确,但外部小区的PCI添加有错,导致的掉话.如下图,102<科技园三1小区>上报181<科技园四的1小区>的MR,但没下发切换命令,查询同频邻区已配置eNBID为28即科技园四的1小区为邻区,但1小区的PCI被配成了182,且配置了同站的两个PCI相等的外部邻区.图表 16邻区错配终端侧LOG图表 17科技园三1小区的同频邻区图表 18科技园三的外部邻区建议：修正外部小区的PCI,在添加邻区时务必保证外部小区的PCI及同频邻区的eNBID正确,减少优化工作量.3.1.2PCI相等导致不发切换命令现象：基站标识117,67<本地小区1>、68<本地小区0>为同站邻区,68往67切换正常,67往68切则切不过去,表现为上报了MR,不发切换命令,LOG如下：图表 19PCI相等终端侧LOG图表 20PCI相等基站侧LOG经查询67<本地小区标识为1>的外部邻区中有PCI为68和同站邻区的PCI相等,如下,在ANR关闭情况下,会不发切换命令；图表 2167小区的外部邻区图表 2267小区的同频邻区措施：首先核查是外部邻区中的PCI配置错误<即该站不存在,或基站存在但PCI配置有错>；核查都无误时需要调整PCI；建议：1、调整完PCI后或新加站后用M2000上的PCI冲突核查工具进行核查邻区中是否存在PCI相等情况.2、使用excel原型工具进行对比,该工具相对麻烦一点,需要将邻区信息倒出来.如下,在M2000的配置中选择LTE 自优化,在优化菜单中双击PCI优化任务,如下图：图表 23M2000 PCI自优化界面图表 24PCI冲突信息在PCI冲突信息中点击任何一条在旁边会显示与其冲突的邻区的具体信息,如下表：图表 25PCI冲突详细信息点击下面优化任务中的绿色按钮,会弹出如下对话框,图表 26优化任务启动界面点击确认后,会显示如下进度条图表 27优化进度条看见完成后会显示已成功,进度条显示100%,建议的优化值会显示如下：图表 28优化结果3.1.3基站下发的RRC连接重配置没收到RRC连接重配置完成科技园三102切向科技园三104后,基站侧下发了RRC连接重配置,为重配置CQI,UE侧没收到,一直山上报MR,基站侧不处理,掉话；UE侧LOG如下：图表 29OMT侧LOG基站侧LOG如下：图表 30基站侧LOG在切换到104后,104小区的信道质量很差,导致没有解出RRC连接重配置而不下切换命令继而掉话,如下：图表 31Probe侧信道状况措施：测量到邻区中182与服务小区104模3相等,由于此路段为弱覆盖路段,建议调整182的PCI,将182调整为180,180调整为181,181调整为182,但由于高新公寓站开不起来,弱覆盖无法解决.3.2乒乓切换在高科E内114和115间乒乓切换,如下图,将时间迟滞由320ms调整480ms,调整后有所缓解,如下：图表 32调整前114和115乒乓情况图表 33优化后114和115切换情况注：根据实际情况也可调整IntraFreqHoA3Hyst和IntraFreqHoA3Offset,但该参数会影响到所有和该小区进行切换的邻区.4重建类协议规定的重建原因有3类：切换失败、重配置失败和其他,重建成功的前提是小区必须有ue的上下文.下面依案例进行分析.4.1重配置失败引起的重建现象：服务小区为102,102切换到180后,基站下发了RRC连接重配置,但在发送重配置完成时,无线链路失败,从无线环境来看,此时服务小区的180的信号为-106左右,随后信号消失,且邻区中也测不到180信号,之后开始搜小区,搜完小区就报RRC连接重建了,重建原因为重配置失败,重建不成功导致掉话,该点为弱覆盖点,各小区在该点的信号都在-110左右且持续时间较短.图表 34Histudio侧信令无线环境如下：图表 35HiStudio侧无线环境措施：可以调整天线的下倾角和方位角,使其有一个主导小区覆盖,但该段由于高新公寓站没有开起来,属于弱覆盖,214为距离1km左右的信号,182为旁瓣覆盖,除了加站,此处无法优化.改掉话点的位置如下<102小区距离该掉话点610米左右,182距离约780米左右>：。
TDD_LTE网络RF优化案例-北京移动(可编辑)
TDD_LTE网络RF优化案例-北京移动（可编辑）(文档可以直接使用，也可根据实际需要修改使用,可编辑推荐下载）网格三ATU测试分析报告ATU指标：RSRP覆盖图：SINR:下载速率：问题点及解决方案：一RSRP覆盖问题：问题点一：清华西路及北段弱覆盖问题描述：车辆行驶至清华西路,RSRP在-110左右，弱覆盖严重。
问题分析：由于该路段附近阻挡严重，周围站址都较低，导致弱覆盖严重。
处理建议：催开规划站点1, TDL12110595 2,TDL14080449 3,TDL12110678 4,TDL14080450问题点二：双清路中段弱覆盖问题描述：车辆行驶至双清路中段，RSRP在-100左右，弱覆盖。
问题分析：由于70224海淀三和概念酒店ZL为一个20米杆塔站点，并周围酒店阻挡，无法覆盖该路段，导致弱覆盖。
处理建议：建议搬迁站址至三和概念酒店楼上或双清路旁，覆盖该路段解决弱覆盖。
问题点三：王庄路弱覆盖问题描述：车辆行驶至王庄路，RSRP在-100左右，弱覆盖。
问题分析：由于王庄路东西两端均有阻挡，导致周围站点无法覆盖该路段。
导致弱覆盖。
处理建议：1，建议催开规划站，催开号：TDL141113752催开站未建前，暂时调整海淀东王庄ZL-2，海淀东王庄ZL-3频点为2605问题点四：清华南路弱覆盖问题描述：车辆行驶至学院南路，RSRP在-100左右，弱覆盖。
问题分析：由于海淀清华南路ZL网元断链，导致弱覆盖处理建议：处理海淀清华南路ZL故障。
二SINR问题:问题点一：成府路清华大学南门SINR差问题描述：车辆由东向西行驶该路段,SINR在5左右，下载速率低。
问题分析：由于70001海淀清华大学南侧ZL-1（PCI=102）越区覆盖与71000海淀华清嘉园ZL-1(PCI=225) MOD3，导致该路段SINR差。
处理建议：下压70001海淀清华大学南侧ZL-1下倾角为8度，控制覆盖。
问题点二：荷清路与双清路交叉口SINR差问题描述：车辆由南向北行驶至荷清路与双清路交叉口处，SINR差，下载速率低问题分析：此路段覆盖不合理，主导频不突出，导致SINR差。
LTE无线网络优化项目教程06LTE网络路测事件分析
【复测结果】
复测时切换正常，但此区域受周边山体阻挡，信号较弱，需要针对性解决覆盖 问题。
任务3 LTE无线网络掉线分析 【知识链接1】 LTE释放过程
1．E-RAB释放 E-RAB释放分为eNB发起和MME发起两种情况， 由eNB发起的释放比MEE发起的释放多一条 S1_UE_CONTEXT_RELEASE_REQUEST消息。
3．UE能力查询和上报 终端能力上报过程：
终端能力上报过程
LTE UE能力询问和上报
在Attach时，核心网下
发的初始上下文建立 请求不携带UE能力， 由eNodeB向UE发起查 询，UE上报给eNodeB， 同时eNodeB通过S1口 的UE能力指示过程上
报给核心网保存；如 果UE能力查询过程失 败，会导致eRAB建立 失败。在Idle to active
正常
随机接入
正常
RRC接入
正常
NAS、鉴权
正常
E-RAB建立
失败
1、覆盖差 2、终端不支持 3、SIM未开LTE功能
……
失败 失败 失败 失败
1、基站异常（RRU、板件故障等） 2、功率参数、功控参数不合理 3、终端问题（设置、系统软件异常）
……
1、覆盖差 2、用户过多、拥塞 3、功率参数、功控参数不合理 4、干扰
（4）参数检查。
功率参数、切换和重选参数对于接入也有影响，特别是在功率参数方面。对于初 始接入影响较大，如上下行功率不平衡造成终端Prea参数设置不合理造成重选时终端占用小区不合理导致接入失败。
FDD LTE_中国联通XX项目_XX Cluster优化报告_YYYYMMDD
FDD LTE_中国联通XX项目_XX Cluster优化报告华为技术有限公司目录目录 (2)1测试总体介绍 (4)1.1测试指标说明 (4)1.2测试基本情况 (5)1.3测试方法 (6)1.4测试路线 (6)1.5优化工作量 (6)2测试结果 (7)2.1质量分析——SINR (7)2.2覆盖情况——RSRP (8)2.3传输模式分析——TM分布 (9)2.4服务小区分析——PCI分布 (10)2.5重叠覆盖分析——导频污染 (12)2.6吞吐率——下行吞吐量 (13)2.7吞吐率——上行吞吐量 (15)2.8异常事件 (16)2.8.1接入失败 (16)2.8.2掉话 (17)2.8.3切换失败 (18)2.9业务测试（每轮做了哪项测试下面就下哪项） (18)2.9.1FTP下载 (18)2.9.2FTP上传 (19)3问题分析和调整建议 (21)3.1问题汇总 (21)3.2问题点分析 (21)3.2.1问题区域1——新凯饭店东北拐角处 (21)3.2.2问题区域1——XXX（共W天馈）可选 (25)4需重点推动处理的遗留问题 (30)5测试总结： (30)6附录： (30)1 测试总体介绍1.1 测试指标说明表1指标优化总结列表注：没有达到目标的要用红色标注出来1.2 测试基本情况1、 簇内基站Mapinfo 图，用红色标注未开通的基站，开通基站用绿色。
2、 简单的语言描述，簇的地理信息，簇内共多少基站，多少未开通，未开通基站名、3、 告警情况。
1.3 测试方法参照《中国联通LTE无线网络工程优化指导书》中“全网优化测试方法”进行测试。
1.4 测试路线根据要求拟定优化测试路线。
测试路线说明：簇优化测试针对整个簇，在簇内LTE无线网络覆盖的全部区域内进行。
路测时，测试路线应尽可能遍历测试区域内的主干道、次主干道、支路等道路，并遍历选定测试区域内所有小区；1.5 优化工作量说明本次RF优化工作前后的各种工作量情况，包括但不限于累计优化轮数、累计测试次数、累计测试公里数、累计上站次数、累计调整天线数等，按表格列出来即可。
FDD-LTE--LTE基站出现RRH瞬断故障案例分析
LTE基站出现RRH瞬断故障案例分析上海贝尔股份有限公司FTM团队摘要：10月22日17:05至17:12左右，某地LTE基站出现部分RRH瞬断故障，RRH发生退服后自行恢复服务，平均持续时间约1分钟左右。
因故障持续时间较短，且临近下班，导致该故障未能及时发现.关键词：FDD LTE; RRH瞬断1 故障现象/功能介绍10月22日17:05至17:12左右，某地FDD LTE基站出现部分RRH瞬断故障，RRH发生退服后自行恢复服务，平均持续时间约1分钟左右。
因故障持续时间较短，且临近下班，导致该故障未能及时发现。
直至第二天，接到现场反馈故障信息后，上海贝尔现场技术人员立即向公司的二线支持部门申请技术支持，同时安排人员开始故障信息的收集工作。
在问题分析的过程中，从分公司到总部领导都十分重视，组织了无线技术支援中心召开电话会议，分析故障可能原因，并派研发专家赶赴现场。
根据统计分析，本次小区退服涉及基站102个，退服后的RRH中断约1分钟左右后继续正常工作，经统计涉及到退服的基站分散在15个BBU池内，且BBU池中，并不是所有的BBU下面下挂的RRH都出现退服现象，没有明显的规律，退服小区的统计较为分散.2 原因分析/原理介绍本次批量基站发生的故障，告警信息为IK4006006 – RFM COMM FAIL，该告警表示基站控制板eCCM在连续30秒的时间内没有收到RRH的心跳信号，就会认为RRH已经退出了服务，并产生IK4006006告警。
根据告警信息和现场工程师收集了相关log信息，研发部门进行了分析，我们认为外部因素也可能引发故障的发生，故需要寻找并检查网络拓扑中的相关节点，是否能够发现一些线索，如传输光路出现误码、瞬断等都可能引起心跳丢失。
同时，我们也不排除产品自身问题的可能性。
因此我们从产品自身和外部环境两个方面同时着手进行了深入仔细的排查。
2.1产品自身原因在接到故障信息后，上海贝尔现场技术人员在第一时间收集了日志文件，并提交上级技术支持和研发人员分析。
北京联通FDD-LTE案例分析报告--安全模式失败导致E-RAB建立失败案例--security Mode Failure
北京联通FDD-LTE案例分析报告--安全模式失败导致E-RAB建立失败案例security Mode Failure事件:故障描述:在后台在进行信令跟踪中对UU，X2，S1进行提取，在该站点FBJ900111系统信令跟踪过程中出现初始建立失败，eNodeB向MME发送原因值。
RRC_SECUR_MODE_FAIL的信令条件，UE在向eNodeB的信令里面出现radio Network –security Mode Failure-r8,导致S1_INITIAL_CONTEXT_SETUP_FAIL失败。
故障分析:MME向eNB发送initial Context Setup Request消息，请求建立初始的UE上下文，包含E-RAB上下文、安全密钥、切换限制列表、UE无线性能以及UE安全性能等等。
初始建立的正常流程：请求建立初始正常流程图1本事件案例事件流程图2对网络中的问题分析，手机在接入以后，基站向MME发送了初始的消息上去，等待近6S的时间，MME收到以后进行了鉴权和加密的请求，在进行鉴权请求的同时，也在NAS上进行安全模式的建立，手机回应时失败（RRC），导致在RRC_SECUR_MODE_FAIL，UE直接失败，eNodeB直接进行了释放，S1AP_INITIAL_CONTEXT_SETUP_FAIL导致的接入失败。
以下几种原因易导致这种情况：1）初始消息未被基站正确接收：基站对在接入时收到的信息，针对这个信息进行发送UE的安全模式出错而有异常，因此安全模式出错上的问题。
2）RRC安全模式配置错误：安全模式关系配置错误会导致接入请求“RRC_SECUR_MODE_FAIL”无法发送，可能导致本案例里面无该现象。
3）设备故障：由于基站内部状态机设计存在缺陷，本案例里面的无该现象。
这种情况，一般可以采用重新启动基站的方法暂时消除。
具体排查过程如下：1：RRC上安全模式配置，看网络是否安全模式无问题情况；2：怀疑设备问题，重启设备，复测问题依旧；3：怀疑UE问题或者配置错误导致。
LTE切换优化总结案例
XX市LTE切换优化总结报告目录一、LTE切换概述 (4)1.1 切换流程图 (4)1.2 切换分类介绍 (6)1.2.1 站内切换 (6)1.2.2 X2口切换 (6)1.2.3 S1口切换 (7)二、LTE切换日常优化 (8)2.1 LTE切换原理 (8)2.2 切换问题优化流程 (9)三、LTE切换自动优化（MRO） (10)3.1 MRO优化场景 (10)3.1.1 切换过早 (11)3.1.2 切换过晚 (12)3.1.3 乒乓切换 (13)3.1.4 切换到错误小区 (14)3.2 MRO优化模式 (15)3.3 MRO优化原理及动作 (15)3.4 网络影响 (16)3.4.1 系统容量影响 (16)3.4.2 网络性能影响 (17)3.5 MRO优化部署建议 (17)3.5.1 部署要求 (17)3.5.2 数据准备 (17)3.5.3 特性激活 (18)3.5.4 开通观测 (19)四、MRO优化试点 (20)4.1 试点区域 (20)4.2 同频MRO优化 (20)4.2.1 试点分析 (20)4.2.2 优化效果 (22)4.3异频MRO优化 (24)4.3.1 试点分析 (24)4.3.2 优化效果 (26)五、日常切换差处理案例 (27)5.1 切换准备失败类优化案例 (27)5.2 模三干扰严重优化案例 (27)5.3 参数配置错误导致切换差优化案例 (28)5.4 T/F切换参数调整提升切换成功率案例 (29)六、总结 (30)一、LTE切换概述1.1 切换流程图切换流程图Measurement Control：测量控制，一般在初始接入或上一次切换命令中的重配消息里携带Measurement Report：测量报告，终端根据当前小区的测量控制信息，将符合切换门限的小区进行上报HO Request：源小区在收到测量报告后向目标小区申请资源及配置信息（站内切换的话为站内交互，站间切换会使用X2口或者S1口，优先使用X2口）HO Request Ack：目标小区将终端的接纳信息以及其它配置信息反馈给源小区RRC Connection Reconfiguration：将目标小区的接纳信息及配置信息发给终端，告知终端目标小区已准备好终端接入，重配消息里包含目标小区的测量控制SN Status Transfer：源小区将终端业务的缓存数据移至目标小区Random Access Preamble：终端收到第5步重配消息（切换命令）后使用重配消息里的接入信息进行接入Random Access Response：目标小区接入响应，收到此命令后可认为接入完成了，然后终端在RRC层上发重配完成消息（第9步）RRC Connect Reconfiguration complete（HO Confirm）：上报重配完成消息，切换完成Release Resource：当终端成功接入后，目标小区通知源小区删除终端的上下文信息1.2 切换分类介绍按照我们实际情况，切换可分为eNb站内切换，X2口切换以及S1口切换，下边分别进行介绍（下边介绍的所有切换都是基于已经接入且获取到了测量配置后）。
LTE案例分析
一定要像爱护自己的眼睛一样爱护我们的网络
5
案例6：切换类
• 故障现象：邻区漏配 从基站跟踪看到基站收到了大量的MR，没有下发切换命令，导致掉话，如下图 。从probe上看信道质量不差没到解调门限以下，因为没有下发切换命令而掉话 ，可以查看是否为邻区漏配。 基站179向科技园四182发起切换，上报了切换的MR，基站侧也收到了MR， 没有下发切换命令，之后读系统消息，发起重建，重新接入到MR中小区，即科 技园四182，可以确认为邻区漏配。Probe和基站侧log如下：
• 解决方案：
• 让测试人员在页面修改为ctlte建立连接，这样，就和附着时的默认承载一致，单PDN 链接，终端重启后，可以接入LTE上网。定论为测试人员所在的基站（爱立信TDD基 站）不支持多PDN连接导致。
• 后期建议：
• 为了避免用户在网络连接时，输入的APN与终端底层送的、或用户签约的默认APN不 一致，附着成功后，发起第二个PDN连接时无线拒绝，导致无法上网。建议需要进一 步梳理无线基站的多PDN连接功能。
邻区漏配有2种情况: 1、同频邻区和外部小区都没有配置; 2、配置了外部邻区,但没配置同频邻区 ； 建议：添加邻区
一定要像爱护自己的眼睛一样爱护我们的网络
6
图表邻区漏配基站侧log
谢谢！
一定要像爱护自己的眼睛一样爱护我们的网络
7
优化建议：
增大A2事件切换门限，将A2门限设置高于终端在掉话前显示的RSRP值，这样终端在掉话前即可触 发激活态切换
一定要像爱护自己的眼睛一样爱护我们的网络
3
案例4：MOD3干扰类
• 故障现象
✓ 科技园E，58小区上报了114的MR，181和服务小区58模3相等，下发了切换命令，UE没收到，由 UE侧可看到此时SINR很差为-6.83;
FDD-LTE调测及排障小结(工作小结)
FDD-LTE调测及排障小结郑重声明：以下所写内容，纯属个人工作总结（部分拾人牙慧），如有错误及不到之处，敬请批评指正。
一、FDD-LTE调测（一）检查硬件无论开站还是排障，检查硬件状态都是第一步也是必须的、基础的一步。
未导入数据之前，上电后的各硬件状态是：eCCM-U（以下简称C板）指示灯为两盏绿灯（如图1-1）；bCEM-U（以下简称B板）指示灯为三盏绿灯（如图1-2）；RRH指示灯为绿灯慢闪。
（开站之前的硬件检查有一步很重要：检查电源线。
包括电源柜和设备电源线是否正确连接，即黑色在电源柜中是否接在正极排上，在设备是否接在+极上）图1-1图1-2检查完硬件状态之后，还要注意一下告警线的连接及RRH上尾纤光口连接是否正确。
告警线上标有RUC/ALARM的一端应与电源模块相连（如图1-3），而另一端应与C板相连即标有iCCM-U/ALARM的一端。
图1-3RRH的尾纤一定要连接到CPRI PRI光口(如图1-4)。
（二）、导入数据以上基本工作完成后，接下来开始进行站点调测，导入数据。
用网线连接本地电脑和eCCM-U板卡的prot 1口（本地电脑ip v4设置为192.168.10.100，子网掩码设为255.255.255.0），打开与基站版本相对应NEM（如图1-5）。
首先获取权限，导入对应版本，版本下载（Download）大概需要20分钟左右（极少情况会很快），开始进度条会走的很慢，下载到40%后会稍微快一些。
版本下载完毕，依次进行激活版本（Activate）和接受版本（Accept）两步操作，后两个步骤建议手动执行，因为在实际工作中遇到过自动激活版本失败的情况，而改为手动激活则会成功。
注意在激活版本的操作执行后，正常情况C板会自动重启，此时可将插在C板上的网线一端拔掉，待C板重启成功后再插回。
版本成功导入后，由于没有导入workorde（WO文件）GPS指示灯即SYNC会是四盏橘黄色灯闪亮，说明eNodeB没有有效同步。
FDD-TE案例解析-常见问题
电信L TE案例解析集1、服务器使用人数多无法满调度下载【产品族】LTE FDD【现象描述】LTE-FDD新建站项目单验阶段，在FDD-LTE单站验证过程中，出现RSRP约为-70dBm左右，SINR为25-30dB，下行速率只有88—89Mbps，且稳定在该数值范围,无法达到下行90Mbps以上,影响单站验证的进度和效率.【告警信息】无【原因分析】由于每天新开站均比较多,每天都会有多组人员同时进行单站验证工作，同时由于每个地市服务器资源有限，且电信、移动开站进度类似，单验和簇优化同时进行，导致服务器使用时间集中。
由于LTE网络下行上行速率均比较大，导致在多组人员同时测试情况下，服务器不稳定.【处理过程】1、检查发现，测试电脑可以满足测试要求,下载上传均正常，不存在电脑故障.2、测试终端能力为CAT3，满足测试要求，测试终端未连续使用过长时间，可以达到88—89Mbps下载速度，不存在吊死情况。
3、服务使用客户提供的服务器，下载地址和端口均正常，且是十线程下载。
4、测试地点位于站点下近点好点,RSRP在-70dBm左右,SINR在25左右,且换至其他好点,下载速度仍然不能超过90Mbps。
5、下载测试速率软件DU Meter经过和Probe自带速度统计对比显示,DU Meter速率显示正常。
6、开启2组FileZilla Client下载软件，选择2组相同下载路径，在指定服务器内下载，发现下载速度改善不明显，不能达到验收要求，于是选择2组不同路径下载,即一组服务器在下载路径进行下载，另一组再上传路径里进行下载，如下图，发现速率由88-89Mbps提升至96-100Mbps，问题得以解决。
【建议与总结】在新建网络单验和簇优化阶段,由于很多人同时集中同时使用服务器进行下载，导致服务器下载目录,造成用户无法从服务器下载目录里获得满RB的调度,导致形成非网络原因的速率无法达到峰值，造成单验时找点困难，速率达标困难等,通过同时开启2组FileZilla Client下载软件进行下载，一组在下载目录里进行下载，以获取绝大部分的RB调度，同时由于使用下载目录的人比较多，基本上下载目录调度不满.另一组FileZilla Client下载软件在上传目录里选择文件进行下载,由于使用上传目录下载的人很少,基本上可以和第一组FileZilla Client下载软件形成互补，从而保证整个下载过程基本上都是950以上的调度次数，从而可以达到下载速率提升且稳定的目的。