WCDMA常见问题的分析思路.doc

WCDMA常见问题的分析思路.doc

《WCDMA常见问题的分析思路.doc》由会员分享，可在线阅读，更多相关《WCDMA常见问题的分析思路.doc（19页珍藏版）》请在冰豆网上搜索。

1网络优化的基本流程

1、观察前一个星期的统计,看网络的运行是否稳定,

2、做NCS,把漏定的相邻关系补齐,特别是越局切换的相邻关系；

3、查看小区参数,把不合理的小区参数检查出来,如DIR,CS,MSRXSUFF等

4、路测

5、根据路测结果和统计的结果做出整改方案,

6、根据整改方案进行整改

7、观察指标的稳定性

8、写网络优化报告。

最差小区：

每线话务量>0.1Erlang为标准话音信道掉话率>3%或话音信道拥塞率>5%

1、掉话分析及处理

1.1切换的分析和解决

首先可通过DT测试进行较大范围的测试，因为切换是在小区及基站之间发生的，本小区的掉话有可能是因为其与相邻小区之间的切换设置不合理造成的。

对于一些与该小区有切换相邻关系而拥塞率又较高的小区进行删除，对造成孤岛效应的小区的天线下倾角进行调整，使其不能越区覆盖。

对那些由于话务量不均衡，造成忙时因目标基站无切换信道而产生的掉话，解决的办法是进行话务量的调整。

1.2干扰的分析和解决

干扰分为上行干扰和下行干扰，多数是由于频率规划不当，导致同频或邻频而引起的，通过DT测试发现如果信号较好但话音质量差或切换濒繁就有可能是由于同频或邻频干扰而引起的，可检查周围的小区是否有存在同频或邻频，如果有就要通过修改频点来解决。

1.3天馈线的分析和解决

对因天线方位角或俯仰角不正确而形成的掉话可通过天线调整来解决。

在话务报表中分析，我们可以看到掉话一般分为上行质差掉话、下行质差掉话、双向质差掉话、弱信号掉话、TA掉话、突然掉话八种，在话务报表中可以看到因各种原因引起的掉话情况，对于这些掉话我们应当如何处理呢？

1.41、质差掉话的处理方法:

质差掉话多数是因为频率的同邻干扰引起，当然也有可能是因为外界的干扰引起的，解决的方法都是换频点。

在质差掉话不是很严重的情况下，也可以调QLIMUL:

、QLIMDL用于切换的上行质量门限值这两个参数。

这个参数越大表示越质量越差,质量测量值高于此值,必须考虑紧急切换。

因此降低紧急切换的门限有可能减少因为质量太差而引起的掉话，在实践中我们也调过这两个参数，而且确实收到了一定的效果。

当然也可以适当调小一点QLENSD（质量滤波器的长度）的长度

1.52、弱信号掉话的处理方法

弱信号掉话分为上行弱信号掉话、下行弱信号、双向弱信号掉话三种，下行弱信号掉话暂时还没有什么解决的方法，对于上行弱信号掉话和双向弱信号掉话，可以通过

压天线下倾角，增大有效覆盖范围的信号密度，从而减少弱信号掉话；

把ACCMIN调大一点，可以减少弱信号掉话，但是对覆盖范围有影响；

调大RLINKUP、RLINKT调大一点，RLINKUP最大为63、RLINKT最大为64，调整这两个参数可以有效改善弱信号掉话，但是也可能引起用户投诉。

1.63、突然掉话的处理方法

突然掉话在全网掉话中占有很大的比例，有人认为，突然掉话占的比例越多表示网络的质量越好，其实这中说法是不科学的，我们可以从引起突然掉话的原因来说明，一般来说引起突然掉话的原因有三种：

传输质量差基站硬件存在故障手机掉电

要减少突然掉话只能从传输和基站本身找问题，并对次进行处理，对于一个网络来说，假如其基站硬件运行情况正常，传输质量比较好，那么可以说突然掉话占的比例越大，网络越好。

2WCDMA常见问题的分析思路和方法的总结

2.1接入问题

RRC连接建立失败问题

接入问题；它是指UE发出了RRC连接建立消息，但没有收到altering消息，出现RRC连接建立失败可能的原因有：

1、上行RACH的问题

2、下行FACH功率问题

3、小区重选参数设置问题

4、下行的初始发射功率低

5、网络拥塞、设备异常等

UE发出RRCConnectionRequest消息，RNC没有收到：

如果此时EC/IO较低可能是覆盖问题，需要解决覆盖；如果此时EC/Io不差，可能是由于Preamble的功率攀升不够、上行存在干扰、NodeB设备问题、存在驻波告警、小区半径设置参数不合理等需要做相关的参数和设备检查；

RNC收到UE发的RRC建立请求消息后，下发了RRCConnectionSetup消息而UE没有收到：

可能是覆盖差或者小区重选参数设置有问题；

RNC收到UE发的RRC建立请求消息后，下发了RRCConnectionReject消息：

一般会返回相应的拒绝原因值，比如说拥塞，这时就需要检查网络资源（码资源，功率资源，CE资源，传输资源等）

UE收到RRCConnectionSetup消息而没有发出SetupComplete消息：

如果这时覆盖较好可能是手机异常问题或下行同步出现了问题；

UE发出RRCSetupComplete消息而RNC没有收到：

如果前面的信令都正常，出现这种问题的概率很小，很少见，可能是突然出现外部干扰等因素影响；

鉴权失败问题

根据鉴权失败消息的原因来判断，可能的原因有：

非法用户，HLR中相关的鉴权参数设置有问题，这个需要让核心网工程师协助分析定位；

加密失败问题

可能的原因有：

手机不支持加密算法，在工程中遇到最多的是RNC和MSC之间的加密算法不一致导致，具体原因的定位需要核心网工师协助分析定位；

RB或RAB建立失败问题

当RB或RAB建立失败时，RNC会在RABAssignmentResponse信令中回RAB指配建立失败，通过相关信元中携带的失败原因值，比如说从RNC的信令中可以得到具体失败原因，一般产生的原因可能会有：

1、参数配置错误：

比如参数配置超出UE的能力等，需要看具体的信令来确定

2、准入拒绝：

比如功率、码资源、传输、CE等系统资源不足，从信令消息中可以查出具体原因

3、UE回应RB建立失败造成RAB建立失败：

比如被叫手机不支持VP，UE不支持VP＋H的并发业务等

4、RNC没有收到RB建立ACK消息导致RAB建立失败：

可能是弱覆盖，或上行RTWP过高等，需要查看当时的覆盖和上行干扰情况来确定。

2.2导频污染问题

导频污染产生的原因一般为：

天线过高、下倾角、方位角设置不合理、导频功率不正确、站址不合理等，解决的办法一般主要是调整天线工参，如果通过调整现有站点工参无法解决可以建议更换站址，如果短期无法更换，在不影响覆盖大局的情况下可以考虑暂时关闭个小区来临时规避，在青岛项目中由于工期紧，站址落地难，部分高站在规划时无法避免，开通后通过关闭高站的个别小区来暂时规避导频污染问题效果很好，总的原则是：

使导频污染点的区域调整出一个主导小区，信号“强的更强，弱的更弱”。

3.掉话问题

还是以CS为例，结合路测数据和RNC的信令来一起判定，常见的产生掉话的原因主要有以下几个方面：

1、覆盖差：

解决RSCP或Ec/Io问题（无主导小区或干扰）

2、邻区漏配：

通过邻区地理化显示或Scanner数据分析

3、干扰：

对于上行干扰导致网络收不到UE的消息，查看上行手机发射功率，然后检查RTWP，再结合RNC侧的信令来确定。

4、传输问题：

表现比较多的是传输闪断或误码过高

5、驻波问题：

检查告警

6、切换导致掉话：

在同频切换中主要体现为：

切换不及时、“针尖效应”和“拐角效应”，可以通过调整天馈参数和修改切换参数来解决；

在异系统切换中主要体现为：

切换不及时、漏配异系统邻区，异系统切换参数设置错误或不合理，根据路测数据和RNC信令消息来定位，解决办法为根据具体的原因调整相关的切换参数（切换导致的掉话也是比较常见的原因）

7、设备问题：

显性告警可以从集中网管查看，对应隐性的需要通过内部信令来分析确定

8、手机异常 ：

主要表现为不上报测量报告或事件报告，需要结合信令来确定，这种情况比较少见。

1.在同一测试区域，HSDPA速率正常，HSUPA速率不达标，可能有什么原因？

HSDPA速率正常,只能说明空中接口基本传输链路（HS-SCCH,HS-PDSCH,HS-DPCCH,associatedDPCH）正常,以及下行的backhaul不存在拥塞,UE在合理的无线覆盖范围内且UE接收参数合理.但这不能保证上行的各个节点/接口都是通畅的.

  HSUPA速率不达标,体现在各个节点上的可能原因包括:

  -UE:

发射功率受限（传输TBS比较大的时侯）.建议上Rel8的HSPA,采用E-DPCCHpowerboosting机制才好.在UE使用2msTTI时也容易导致功率受限的情况,但目前现网中的数据卡好象都还不能支持2msTTI.

  -airinterface:

本小区的RoT已经比较高（通常上限为6~7dB）因而E-AGCH上给出的功率偏移本身就限制了高速率;或者某个邻小区的上行干扰已经比较严重因而在E-RGCH上发送"down"指令从而限制了UE在servingcell的能力"发挥".

  -NodeB:

看各家vendor各自的处理机制了.比如是否能够根据traffic特性动态调整CE分配以避免多用户时CE资源受限;NodeB是否有advancedreceiver从而能够对高速上行数据做有效的信道估计和解调.

  -Iublink:

是承载在ATM上还是IP上.是否有上行的拥塞及丢包发生?

如果存在此类现象的话,恐怕会触发Iub上的流控措施以迫使空口uplink降速以免NodeBbufferoverflow

  -RNC:

也看各家vendor自身的处理机制了.通常RNC用户面的处理能力远远超过NodeB.但这里要保证RNC内部各关联的处理单元上没有受限的情况发生,以免在RNC上引起相关的降负荷措施而"连累"该UE的数据传输.

  -IuPS:

也要保证没有丢包和拥塞.现在有了OneTunnel,RNC可以直接和GGSN建GTPtunnel做数传了.现网中Iu接口带宽配置充分,通常不会在这里出问题.

  -核心网:

保证该用户在HLR设备上有合法的签约数据并且GGSN不要实施降速限流类的策略,GGSN上防火墙设置是否合理,等.

  最后还要看应用层的业务特性,如果是承载在TCP上的,那么应用层会要求receiver对接收到的TCP数据包有acknowledge,否则会认为传输路径中有拥塞发生从而自动减小发送窗口（导致sender的实际发送速率变小）.我猜,这个也就是出题者为什么给出HSDPA正常的原因吧.

2,"在同一测试区域，HSUPA速率正常，HSDPA速率不达标，可能有什么原因".

分析逻辑同上.HSUPA速率正常,只能说明上行方向各接口和节点工作正常.对HSDPA,要考虑以下:

  UE:

UE侧接收参数是否设置合理.现网的智能终端偶尔会出现因UE操作系统对多任务场景的处理能力不够强导致UE解析应用层数据的能力下降从而影响了接收效果.总之,UE本身也是容易出问题的地方.

  airinterface:

UE的无线环境（上报的CQI）是否合理;基站所使用的无线资源（码,功率）是否充分;比如采用动态的码分配和功率分配.

  NodeB:

类似于上例,要保证基站有足够的处理资源和灵活的资源调整机制.

  Iublink:

类似于问题1,是否有拥塞及丢包现象.要保证Iubdownlink带宽充分且顺畅,从而避免flowcontrol措施导致NodeBbuffer"starving".

 RNC:

类似于上例,要保证RNC的相关处理单元资源充足.RNC内部各处理单元没有高负荷,以避免激发RNC本身的"减压"措施从而影响用户数传

 IuPS:

典型情况下采用OneTunnel.现网IU带宽配置充分,往往不在这里出问题.

  核心网:

类似于上例,要保证该用