整理LTE网络优化.docx

整理LTE网络优化.docx

《整理LTE网络优化.docx》由会员分享，可在线阅读，更多相关《整理LTE网络优化.docx（23页珍藏版）》请在冰豆网上搜索。

整理LTE网络优化

1LTE优化案例分析

1.1覆盖优化案例

1.1.1弱覆盖

问题描述：

测试车辆延长安街由东向西行驶，终端发起业务占用京西大厦1小区（PCI=132）进行业务，测试车辆继续向东行驶，行驶至柳林路口RSRP值降至-90dBm以下，出现弱覆盖区域。

问题分析：

观察该路段RSRP值分布发现，柳林路口路段RSRP值分布较差，均值在-90dBm以下，主要由京西大厦1小区（PCI=132）覆盖。

观察京西大厦距离该路段约200米，理论上可以对柳林路口进行有效覆盖。

通过实地观察京西大厦站点天馈系统发现，京西大厦1小区天线方位角为120度，主要覆盖长安街柳林路口向南路段。

建议调整其天线朝向以对柳林路口路段加强覆盖。

调整建议：

京西大厦1小区天线方位角由原120度调整为20度，机械下倾角由原6度调整为5度。

调整结果：

调整完成后，柳林路口RSRP值有所改善。

具体情况如下图所示。

1.1.2越区覆盖

问题描述：

测试车辆延月坛南街由东向西行驶，发起业务后首先占用西城月新大厦3小区（PCI=122），车辆继续向西行驶，终端切换到西城三里河一区2小区（PCI=115），切换后速率由原30M降低到5M。

问题分析：

观察该路段无线环境，速率降低到5M时，占用西城三里河一区2小区（PCI=115）RSRP为-64dBm覆盖良好，SINR值为2.7导致速率下降。

观察邻区列表中次服务小区为西城月新大厦3小区（PCI=122）RSRP为-78dBm，同样对该路段有良好覆盖。

介于速率下降地点为西城三里河一区站下，西城月新大厦3小区在其站下应具有相对较好的覆盖效果，形成越区覆盖导致SINR环境恶劣，速率下降。

调整建议：

为避免西城月新大厦3小区越区覆盖，建议将西城月新大厦3小区方位角由原270度调整至250度，下倾角由原6度调整为10度。

调整后

调整结果：

西城三里河一区站下仅有该站内小区信号，并且SINR提升到15以上，无线环境有明显提升。

1.2切换优化案例

1.2.1邻区漏配

问题描述：

测试车辆延长安街由东向西行驶，终端占用中华人民共和国科技部2（PCI=211）小区进行业务，车辆继续向西行驶，终端开始频繁上发测量报告，并没有网络侧下发的切换命令，导致UE掉话，终端掉话后重选至新兴宾馆1小区（PCI=201）。

问题分析：

终端由中华人民共和国科技部2小区（PCI=211）开始正常业务，随后频繁上发测量报告，测量目标小区为海淀新兴宾馆1小区（PCI=201），但始终没有收到网络侧下发的切换命令，最终导致UE拖死掉话。

观察当时无线环境，掉话地点中华人民共和国科技部2小区（PCI=211）RSRP为-99dBm，测量目标小区为海淀新兴宾馆1小区（PCI=201）RSRP为-90dBm，两小区RSRP相差9dBm，以满足切换判决条件，但未发生切换关系。

怀疑导致该现象发生的原因为中华人民共和国科技部2小区（PCI=211）并未添加海淀新兴宾馆1小区（PCI=201）的邻区关系。

检查基站小区配置文件后，中华人民共和国科技部2小区（PCI=211）与海淀新兴宾馆1小区（PCI=201）并没有相互邻区关系，使终端无法切换导致掉话。

调整建议：

添加中华人民共和国科技部2小区（PCI=211）与海淀新兴宾馆1小区（PCI=201）双向邻区关系。

调整结果：

调整后，中华人民共和国科技部2小区（PCI=211）与海淀新兴宾馆1小区（PCI=201）顺利进行切换。

1.2.2乒乓切换

问题描述：

测试车辆延复兴门外大街由西向东行驶，发起业务后首先占用恩菲大厦3小区（PCI=128），车辆继续向东行驶，终端切换到梅地亚宾馆2小区（PCI=130），随后又在恩菲大厦3小区（PCI=128）与梅地亚宾馆2小区（PCI=130）乒乓切换一次，导致终端异常。

问题分析：

观察该路段周围站点分布，正常站点间切换顺序应为恩菲大厦3小区（PCI128）——梅地亚宾馆2小区（PCI130）——北京铁路局3小区（PCI113）。

在测试过程中出现恩菲大厦3小区（PCI128）与梅地亚宾馆2小区（PCI130）回切情况。

由于恩菲大厦正北方向有高层建筑无遮挡，在建筑间缝隙会泄漏出较强的信号覆盖到长安街，形成尖峰覆盖，导致乒乓切换。

调整建议：

恩菲大厦站点天馈系统被高层建筑遮挡，若调整其天馈系统就会影响长安街覆盖，所以考虑调整恩菲大厦3小区向梅地亚宾馆2小区切换相关参数值，避免乒乓切换情况。

具体调整参数如下：

参数名称

参数位置

原始值

目标值

事件触发滞后因子（dB）

小区->小区测量->A3事件配置

2

3

事件触发持续时间（ms）

小区->小区测量->A3事件配置

512

1024

邻小区个性化偏移（dB）

小区->邻小区关系

0

-4

调整结果：

乒乓切换现象消失。

1.2.3切换不及时

问题描述：

测试车辆延长安街由东向西行驶，终端发起业务占用北京银行燕京支行2小区（PCI=211），车辆继续向西行驶，RSRP从-90dBm降至-100dBm以下，出现掉话。

问题分析：

观察该路段RSRP值分布发现，北京银行燕京支行2小区（PCI=221）覆盖方向向西约200米后，出现黄色覆盖区域，RSRP为-100dBm以下，邻区列表中测量到最强邻小区北京铁路局1小区（PCI=111）RSRP也是-100dBm以下，且两小区RSRP值相近，一直无法满足切换判决条件，当测试车辆继续向西行驶时，无线环境继续恶劣导致掉话。

北京银行燕京支行2小区（PCI=211）天线向西方向有高层建筑遮挡天馈系统无法调整，另北京铁路局1小区（PCI=111）距离掉话区域650米左右，调整其天馈系统不会产生太大的改善。

所以建议调整北京银行燕京支行2小区（PCI=211）向铁路局1小区（PCI=111）切换的迟滞量，使其更容易向铁路局1小区（PCI=111）切换以避免掉话。

调整建议：

具体调整参数如下。

参数名称

参数位置

原始值

目标值

邻小区个性化偏移（dB）

小区->邻小区关系

0

3

调整结果：

调整完成后，使终端提早切换至北京铁路局1小区（PCI=111），避免了终端掉话的风险。

1.2.4UE未启动同频测量

问题描述：

UE从江宁T的446小区向旭海宾馆的449移动过程中，切换失败：

UE没有上报测量报告，直接失步回到Idle态。

问题分析：

UE的邻区测量列表中没有任何邻区的测量信息，因此应该是未测量到邻区；结合基站分布和扫频信息，该区域应该可以测量到邻区。

查看重配置消息的邻区参数配置，正确；查看重配置消息中的s-Measure配置为20（实际值为协议值-141）,UE需要在RSRP小于-121dBm以下才会启动测量；参数取值不合理。

解决措施：

将小区446的s-Measure改为97（最大值）。

处理效果：

参数修改后，重新验证，问题解决。

1.3干扰优化

1.3.1PCI干扰

问题描述：

测试车辆延长安街由西向东行驶，终端占用北京银行燕京支行2小区（PCI=214）进行业务，随后切换至西城燕京饭店2小区（PCI=118），SINR值较差。

问题分析：

北京银行燕京支行与西城燕京饭店两站点之间距离较近，发现北京银行燕京支行2小区（PCI=214），西城燕京饭店2小区（PCI=118），PCI造成模三干扰，导致两小区切换带SINR值较差。

调整建议：

将北京银行燕京支行2小区原PCI214调整为221，以解决两小区之间模三干扰问题。

调整结果：

修改后SINR有明显改善。

1.3.2重叠覆盖干扰

问题描述：

测试车辆延长安街由东向西行驶，终端占用海淀新兴宾馆2小区（PCI=202、RSRP-78dBm）进行业务，速率在30M左右，车辆继续向西行驶，速率陡降至5M左右。

问题分析：

通过回放测试数据观察，在海淀新兴宾馆2小区（PCI=202）进行DL业务时，该小区的RSRP正常为-78dBm，但是SINR为-4.8较差。

观察邻区列表中次服务小区为公主坟桥南3小区（PCI=197），当前RSRP值为-77dBm，与当前主服务小区新兴宾馆2小区RSRP相差1dBm。

以此判断该路段存在海淀新兴宾馆2小区与公主坟桥南3小区重叠覆盖情况，导致SINR值恶化，速率陡降。

调整建议：

为避免在该路段产生一个上RSRP较强小区，建议调整公主坟桥南3小区天馈系统，由原310度调整为270度，避免覆盖到长安街。

调整结果：

调整后，海淀新兴宾馆2小区（PCI=202）成为该路段最强服务小区，SINR值良好。

1.4参数优化

1.4.1DSR上报周期

问题描述：

在北京演示网项目移动集团A座的优化过程发现该站在信号强度和信号质量都比较好的情况下，下载速率只有30mbps左右。

而且MSC也在正常范围内。

如下图：

可以看出来信号的传输模式主要在双流，影响速率的主要问题是MSC调度次数不够。

使用UDP灌包的模式进行对比,速率基本可以达到50多mbps，结果如下图：

问题分析：

通过灌包对比，可以判断速率低的主要问题不是由于无线信号质量不好引起。

观察一段时间下载情况，发现下载速率不稳定，调度次数在200-600间跳动，速率同时在30m至50m之间不断变化。

可能是由于基站调度算法引起的速率不稳。

核查基站参数发现DSR上报周期为80ms，时间过长。

改回20ms后，调度次数稳定在500多，下载速率也正常稳定。

调整建议：

核查基站参数发现DSR上报周期为80ms，时间过长。

改回20ms后，调度次数稳定在500多，下载速率也正常稳定。

调整结果：

调度次数稳定在500多，下载速率也正常稳定。

1.4.2小区驻留困难

问题描述：

室内分布小区在窗口或电梯口开机无法campon，并且idle态时在这些位置经常脱网。

问题分析：

在中心进行业务保持并移动到这些地点，业务可以保持，且速率仍比较高，且进出电梯可正常切换；查看脱网地点的RSRP仍然比较高，在-90dBm左右，怀疑网络侧参数配置错误。

查看Sib参数（Sib1），q-RxLevMin配置为-80dbm（终端Log中值为-40）。

解决措施：

将网络侧的q-RxLevMin改为-120dBm。

处理效果：

修改参数后，重新验证，没有再复现问题，问题解决。

1.4.3同频小区重选失败

问题描述：

UE在Idle态向邻区移动时没有发生小区重选，而是直接进行了小区选择。

问题分析：

从路测软件看，UE在向邻区移动过程中，始终未测量到邻区；怀疑小区选择的参数配置错误，查询Sib3消息，发现s-IntraSearch配置过小，导致UE未启动同频邻区测量。

Srxlev>SIntraSearch时不启动同频测量。

其中，Srxlev=Qrxlevmeas–（Qrxlevmin+Qrxlevminoffset）–Pcompensation

解决措施：

将网络侧的s-IntraSearch改为62dB。

处理效果：

修改参数后，重新验证，小区间可以正常重选成功，问题解决。

1.4.4切换后TAU导致掉话

问题描述：

UE在东城家园小区438向大学城2小区33切换成功后，发生TAU过程，TAU完成后RRC连接被释放。

问题分析：

从TAU更新的消息类型看，是正常的TAU更新过程，怀疑是小区33的TA配置错误导致。

无线分组一的TA应该为511，但查看该小区的TA配置为515

解决措施：

将小区33的TA修改为511。

处理效果：

修改参数后，重新验证切换，没有再发生TAU过程，问题解决。

2TD-LTE网络优化经验总结

2.1网络部署与优化思路

LTE与3G关系紧密，体现在以下几个方面：

●同为同频组网，网络性能主要受限于系统内干扰，无线规划和优化的思路和手段比较接近；

●覆盖能力接近：

TD-LTE和TD-SCDMA频段接近，都是2GHz左右的频段，覆盖能力接近。

在建设选址时巨大多数可以采用方式；同时3G的现有覆盖状况可作为LTE覆盖预测的参考。

●业务接近，PS业务、视频业务等3G业务为LTE的业务开展进行了培育，同时3G对用户业务性能的分析和优化手段可以借鉴；如一些KPI指标的目标确定；

●关键技术接近：

3GHSPA技术引入了AMC、HARQ、多天线/智能天线等技术，这些技术在LTE中得以延续；

共站建设：

根据测试经验，2.6GTD-LTE的覆盖能力（满足一定能够边缘速率要求）比TD-SCDMA稍弱，在共站建设情况下，TD-LTE可以获得良好的室外连续覆盖；但作为高速业务主要产生区域的室内，部分区域难以满足高速输出传输的覆盖需求，需要有进一步的热点及室内解决方案；

2.2同频干扰减轻与小区边界性能提升

TD-LTE同频组网的可行性和小区边缘用户性能的提升，是影响后续TD-LTE未来应用的关键问题，也是本次规模实验网关注的问题之一。

从目前测试结果看同频组网可行性是毋庸置疑的。

目前系统指只引入了一些初步的已经采用的同频干扰减轻措施，如：

●波束赋形；

●IRC

●上行功控

●PDCCH自适应

●ICIC（未深入验证）

在当前情况技术状况下，系统负荷50%可以作为一个同频组网的目标点。

通过大规模组网性能测试，50%负荷情况下网络指标达到商用要求是可以实现的。

随着增强技术的引入，系统效率可进一步提升。

后续一些增强功能会逐步引入，结合优化能够进一步提升性能，如：

●COMP（CS、CBF等）

●下行功率控制等

2.3天线性能

8天线作为TD-SCDMA关键技术和产品形态得的延续，组网性能得到初步验证。

相对于2天线有明显增益。

针对8天线优化考虑以下几点：

●广播波束3dB宽度的合理设置：

高速可以采用更窄的波束以增强覆盖能力；

●关注天线校准结果，一旦校准出现偏差，整个智能天线工作失效；

●建议IRC功能打开，试验证明IRC对邻区干扰有明显抑制作用；

●FAD天线与单D频段天线性能接近，均可满足组网需求；

针对8天线的成熟应用以及性能提升，后续测试和优化工作需要考虑：

●中高速情况下的赋形性能需要充分测试；

●8天线双流波束赋形；

●上下行MU-MIMO的应用及性能优化

31．WLAN网管的原理

3.11.1系统概述

WLAN网管系统采用三层结构：

前端接口代理层、中心信息模型层、应用接口层，支持大型数据库和多种操作系统，以面向对象技术和软总线技术为核心，采用B/S方式，实现针对各个AP的故障管理、性能预警、告警统计、KPI指标统计、配置管理等功能，为及时发现故障和分析优化提供可靠实用的手段。

本系统严格遵守TCP/IP的标准，以SNMPMIBII为信息采集基本手段，基于LINUX操作系统平台，采用基本C语言、以及高度安全、可靠、支持多平台移植的、面向对象化的JAVA编程技术，整套系统基于LINUX内核技术进行开发，融合了多种接口技术，力求系统高效、可靠。

在可行性研究时应进行安全预评价的建设项目有：

本系统是依据中国电信WLAN热点接入设备管理系统技术规范，系统架构遵循集团APMS规范，如图1.1.1所示。

图1.1.1APMS结构图

（2）环境的非使用价值。

环境的非使用价值（NUV）又称内在价值，相当于生态学家所认为的某种物品的内在属性，它与人们是否使用它没有关系。

北向接口模块：

用于处理与外部系统的接口及向外部用户（非此系统用户）提供接口，向BOSS系统提供采集到的拓扑数据、故障数据、性能等数据。

北向接口可采用FTP、WebService、Socket等协议进行数据的交互。

南向接口模块：

通过南向接口对WLAN热点接入设备进行设备认证、状态监视、参数配置、软件升级、故障检测及告警、性能数据采集等功能，必须支持分布式采集。

南向接口采用SNMP（SNMPv2或v3）协议进行数据的交互。

业务逻辑模块：

用于集中处理数据的流转，实现系统的核心业务。

（2）辨识和分析评价对象可能存在的各种危险、有害因素，分析危险、有害因素发生作用的途径及其变化规律。

数据库访问模块：

用于实现数据存储、读取和备份等相关的操作，提供内存数据和数据库数据映射缓存，提供数据库访问优化，实现系统和数据库系统的隔离。

3.21.2技术实现基础

●SNMPMIBⅡ

SNMP（SimpleNetworkManagementProtocol，简单网络管理协议）首先是由IETF的研究小组为了解决Internet上的路由器管理问题而提出的。

SNMP的设计原则是简单性和扩展性。

SNMP的网络管理模型包括以下关键元素：

管理站、代理者、管理信息库（MIB）、网络管理协议。

如图1.2.1所示。

图1.2.1SNMP模型

管理站和代理者之间通过网络管理协议通信，SNMP通信协议主要包括以下能力：

　　Get：

管理站读取代理者处对象的值。

　　Set：

管理站设置代理者处对象的值。

　　Trap：

代理者向管理站通报重要事件。

MIB（ManagementInformationBase）管理信息库，用来定义SNMPMessage中交换的信息。

RFC1213[2]定义了MIB-II,互联网协议套件管理对象的核心集。

MIB有一定的组织结构，即管理信息结构（SMI），SMI用分层的树形结构组织，从树根开始，按照分支来分类组织被管理对象。

本WLAN网管系统通过集合多个AP厂家（包括思科、华三、摩托罗拉、华硕、D_LINK友讯、先创、网件、阿尔卡特、中天创、东方世纪等）的MIB库信息，运用SNMP原语操作，对AP设备的各项性能数据进行收集和管理。

●MRTG

Mrtg（MultiRouterTrafficGrapher,MRTG）是一个监控网络链路流量负载的工具软件，它通过snmp协议从设备得到设备的流量信息，并将流量负载以包含PNG格式的图形的HTML文档方式显示给用户，以非常直观的形式显示流量负载

本WLAN网管系统的性能曲线部分就是通过本软件实现的。

●RRDTools

RRDTool是由TobiasOetiker开发的自由软件，它使用RRD（RoundRobinDatabase）作为存储格式，Roundrobin是一种处理定量数据、以及当前元素指针的技术，其数据库采用环形队列方式，采用独特的数据合并算法，维持数据库文件大小不变。

RRDTool主要用来跟踪对象的变化情况，生成这些变化的走势图。

本WLAN网管系统通过MRTG与RRDTools的结合，快速生成各个AP的相关性能曲线。

●JAVA、C语言

C语言系列的编程语言是当今非常流行的程序设计语言，它融汇了高效，灵活等设计思想，具有较高的可移植性。

Java是一种简单、动态、面向对象、分布式、解释执行、健壮、安全、结构中立、可移植、高效能、具有多线程能力的新一代语言。

系统采用基本C语言、以及高度安全、可靠、支持多平台移植的、面向对象化的JAVA编程技术，相对于其他很多高级语言开发的程序，系统的执行效率非常高。

●PHP

PHP可以跨平台，性能优越，跟Linux/Unix结合比跟Windows结合性能强45%，并且和很多免费的平台结合非常省钱，支持N种数据库。

（N>=10）；语法简单；目前主流技术都支持，比如WebService、Ajax、XML等等，足够应用；有很多成熟的框架，比如支持MVC的框架：

phpMVC，支持类似ASP.net的事件驱动的框架：

Prado，支持类似RubyOnRails的快速开发的框架：

Cake等等，足够满足你的应用需求；PHP5已经有成熟的面向对象体系，能够适应基本的面向对象要求，适合开发大型项目。

本WLAN网管系统使用PHP实现WEB呈现，界面友好，操作简便。

●LINUX

Linux的本质有三点，一是开源，二是免费，三是和Unix是一个体系。

用Linux作为服务器的操作系统，安全又高效，且可扩展性好，可维护性强。

本WLAN网管系统采用Linux作为各个本地网的采集机和WEB服务器的操作系统，版本为FedroCore6，可以很好地满足系统应用需求。

●数据库

本WLAN网管系统的全省统一数据库平台是基于sybase的大型关系型数据库，它是美国Sybase公司研制的一种关系型数据库系统，是一种典型的UNIX或WindowsNT平台上客户机/服务器环境下的大型数据库系统。

Sybase提供了一套应用程序编程接口和库，可以与非Sybase数据源及服务器集成，允许在多个数据库之间复制数据，适于创建多层应用。

系统具有完备的触发器、存储过程、规则以及完整性定义，支持优化查询，具有较好的数据安全性。

在全省已有广泛的应用。

本地网级数据库则采用SQLServer2000SP4作为各个本地网的数据库服务器。

Microsoft®SQLServer™2000由一系列产品组成，不仅能够满足最大的数据处理系统和商业Web站点存储数据的需要，还能为个人或小企业提供易于使用的数据存储服务。

SQLServer2000数据库引擎提供完整的XML支持。

它还具有构成最大的Web站点的数据存储组件所需的可伸缩性、可用性和安全功能。

SQLServer2000程序设计模型与WindowsDNA构架集成，用以开发Web应用程序，并且SQLServer2000支持EnglishQuery和Microsoft搜索服务等功能，在Web应用程序中包含了用户友好的查询和强大的搜索功能，用以实现大容量的AP数据的存储，并通过数据库优化及查询优化，实现网管数据的快速高效统计。