无线性能优化思路.docx
- 文档编号:23881962
- 上传时间:2023-05-21
- 格式:DOCX
- 页数:21
- 大小:89.63KB
无线性能优化思路.docx
《无线性能优化思路.docx》由会员分享,可在线阅读,更多相关《无线性能优化思路.docx(21页珍藏版)》请在冰豆网上搜索。
无线性能优化思路
无线性能优化思路树
<本文中的所有信息均为中兴通讯股份有限公司信息,务请妥善保管,未经公司明确作出的书面许可,不得为任何目的、以任何形式或手段(包括电子、机械、复印、录音或其它形式)对本文档的任何部分进行复制、存储、引入检索系统或者传播。
>
关于本书
文件编号
版本号
拟制人/修改人
拟制/修改日期
更改理由
主要更改内容
V1.0
顾健/129524
2008/11/11
完成初稿
无
注1:
每次更改归档文件(指归档到事业部或公司档案室的文件)时,需填写此表。
注2:
文件第一次归档时,“更改理由”、“主要更改内容”栏写“无”。
目录
第1章掉话问题原因及解决办法-1-
1.1掉话的主要处理过程-2-
1.1.1RNC级掉话-2-
1.1.2小区级掉话-2-
第2章PS掉话问题原因及解决方法-6-
2.1PS掉话的主要处理过程:
-7-
2.1.1RNC级PS掉话-7-
2.1.2小区级PS掉话-8-
第3章接入问题原因及解决办法-11-
3.1接入问题分析触发点及获取信令方式-11-
3.2接入失败问题定位-11-
第4章切换问题原因及解决办法-13-
4.1切换问题的发现-13-
4.1.1路测中发现切换问题-13-
4.1.2系统侧KPI统计中发现切换问题-13-
4.2切换问题主要原因-13-
4.3切换问题解决思路-14-
4.3.1RNC或全网切换失败问题-14-
4.3.2RNC内切换失败问题-15-
第5章干扰问题解决办法-18-
第6章寻呼拥塞问题解决办法-20-
第1章掉话问题原因及解决办法
现网的掉话监测分成RNC级的掉话与小区级的掉话两个方面,若出现网元大面积掉话,可能由RNC硬件故障引起。
但还有一种情况是全网所有的RNC掉话率都较高,此时可以考虑可能是由于CN的故障或是由其它系统原因造成,比如系统升级。
造成RNC掉话升级的原因可以有以下几种:
1)参数配置错误:
这有两个方面参数配置存在问题,一是RNC中的全局参数配置存在问题,另一方面是由CN中对RNC的参数配置存在问题。
2)RNC硬件故障问题:
需要通过对RNC告警的检查以及对RNC日志的检查来确定是否是由硬件故障引起。
小区级掉话率较高,造成小区掉话的原因较多,主要有以下几种:
3)干扰造成的掉话:
(同频干扰、相关性较强的扰码引起的干扰、导频污染、上下行交叉时隙干扰、上下行导频间干扰、系统间干扰、其它无线设置的干扰)
4)切换造成的掉话:
(硬件故障导致切换异常、同频同扰码小区越区覆盖导致切换异常、越区孤岛切换问题、目标小区上行同步失败导致切换失败、无线参数设置不合理导致切换不及时)
5)基站硬件故障造成的掉话
6)终端问题造成的掉话
7)链路失衡造成的掉话
8)参数配置错误造成的掉话
9)覆盖问题造成的掉话(覆盖空洞造成的掉话、越区覆盖造成的掉话、孤岛效应导致的掉话、导频杂乱导致的掉话、阴影衰落导致的掉话)
1.1掉话的主要处理过程
1.1.1RNC级掉话
1、出现RNC级掉话后,首先需确定该RNC级的掉话是由多个小区引起的,还是由个别高掉话的小区所导致。
如果是由个别小区引起的,应进行小区级的掉话处理步骤,否则进入网元级的掉话处理过程。
2、检查RNC的系统告警,检查是否存在相关硬件的告警信息,如果存在单板的告警,则需要进行排除。
3、检查RNC的系统日志,对其中不正常部分进行检查。
4、检查CT数据中掉话部分的信令,分析其错误代码,常见的RNC级参数设置错误引起的掉话主要有以下几种:
错误代码
事件编号
CN_TRANAP_unknown_target_rnc
9
CN_TRANAP_release_due_to_utran_generated_reason
15
CN_TRANAP_user_plane_versions_not_supported
27
其中:
unknown_target_rnc则表明CN中对RNC的SGSN解析地址定义错误,此时容易造成PS业务RNC间切换失败,从而引起掉话的产生。
而user_plane_versions_not_supported则主要是由于版本问题造成的失败;如果产生release_due_to_utran_generated_reason原因则主要是由于硬件故障造成。
1.1.2小区级掉话
1、出现小区级掉话时,首先查看该小区是否有硬件故障告警,如果有,首先要求用服人员解决硬件故障问题。
2、检查切出成功率是否正常,如果切换成功率较低,检查邻区关系以及是否存在同频同码的情况。
✓邻小区关系中是否存在同频同扰码的现象,这种情况在路测中也可以发现,一般是在邻区表中出现两条相同的邻小区关系,这里需要注意的是业务同频同扰的现象,它无法在路测中发现,一般需要对信令进行分析,此时虽然两个小区主载频异频,但measurementreport却上报了1G事件,针对这种情况需要通过修改频点和扰码解决(可以通过系统自带的全局参数合法性检查工具进行检查)
✓邻小区关系中是否存在同频同码组的现象,这种情况在路测中也可以发现,一般情况是它是影响到终端的测量结果,此时测量结果不准确,造成终端上报系统后系统判断错误,针对这种情况则需要修改频点和扰码解决(可以通过系统自带的全局参数合法性检查工具进行检查)
✓是否存在单边邻小区关系,如果存在,添加单边邻区,单边小区的检查可以使用NOP-T工具进行,也可以通过对性能统计指标中的小区对切换统计指标来检查。
✓是否存在异频邻小区个数过多的现象(异频邻区数超过8个),如果存在,删除不必要的邻区,这种情况可以使用NOP-T工具进行检查,也可以使用办公软件进行检查。
✓是否存在切换开关设置的问题(有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止)。
如果存在,打开切换开关
✓切换相关的事件定义是否准确,不区引用是否正确,如果存在,修改引用
✓PS切换失败是否存完整性算法问题,如果存在,将RNC、CN之间的完整性开关设成一致
✓是否存在邻区漏配的情况。
需要用SCANNER路测发现是否存在漏配的情况。
如果存在,添加邻区。
✓目标小区拥塞造成的掉话,由于目标小区的资源不足,而本小区的覆盖又越来越差,此时造成掉话。
常见的错误代码为no_resource_available或RRM_CellOverload_Release
3、检查时隙转换点配置是否正确,是否存在交叉时隙干扰。
如果存在,修改时隙转换点。
4、检查UP时隙和上行业务时隙的干扰电平,是否存在上行干扰导致掉话。
如果存在,进行干扰排查
5、根据性能指标统计,如果PS域和CS域的BLER都比较高则有可能存在干扰,然后再结合载频时隙干扰统计指标来判断是否确实存在干扰,另外通过对信令的分析如存在干扰则一般信令流程正常,未有切换事件或其它事件,但RNC进行了IURELEASE,原因一般为无线链路的原因。
(比如无线链路错误等),有时也会发生CELLUPDATE原因为RLCunrecoverableerror如果确实存在则需要现场排除,现场测试时如果存在干扰则有以下几个方面的显示
●C/I较差:
系统内同频的干扰较为严重,发生掉话时会存在终端发射功率较高,的现象,同时覆盖也相对较好,表现在RSCP值上,一般都在-90dBm以上,另外一表现象就是起呼比较困难,而起呼成功率后也很容易掉话
●终端发射功率较高,基本上满功率发射,一般都在-20dBm以上
●系统外的干扰造成的掉话同样具有终端发射功率较高的现象,也一般都都在-20dBm以上
●系统外干扰造成掉话时也可以通过误块率指标进行判断,此时无论是进行CS业务还是进行PS业务,BLER都比较高,并且保持时间较长
●系统外干扰语音业务判断,此时进行通话会出现断字、吞字、金属声等现象,比较难以进行通话。
6、通过对性能指标的统计,主要是对RRC连接成功率的统计,这其中的统计包括业务相关和非业务相关的统计,如果两种统计都较差,则有可能存在覆盖问题,此时可以检查CT数据中RRCCONNECTIONREQUEST中的PCCPCH的值,则说明存在弱覆盖现象,需要进行功率参数、天线方向角、下倾角的调整。
7、如果上述都检查不出原因,可能是载波、时隙的隐性故障,此时可以尝试闭解载波时隙,或者强行闭载波、时隙观察掉话率的变化。
8、终端问题,一般是通过对大量的性能数据统计,发现掉话高的小区,然后依据小区性能数据分析信令,可以看出掉话常发生的用户,而后进行处理。
目前常见的终端问题为UP同步存在问题,此时容易在切换时产生Ue_Operate_fail_physicalchannelfailure错误。
第2章PS掉话问题原因及解决方法
现网的PS掉话监测分成RNC级的掉话与小区级的掉话两个方面,若出现网元大面积掉话,可能由RNC硬件故障引起。
但还有一种情况是全网所有的RNC掉话率都较高,此时可以考虑可能是由于CN的故障或是由其它系统原因造成,比如系统升级。
造成RNC掉话升级的原因可以有以下几种:
1)参数配置错误:
这有两个方面参数配置存在问题,一是RNC中的全局参数配置存在问题,另一方面是由CN中对RNC的参数配置存在问题。
2)RNC硬件故障问题:
需要通过对RNC告警的检查以及对RNC日志的检查来确定是否是由硬件故障引起。
3)终端问题。
目前外场的终端不是很成熟,特别是HS终端。
这些不成熟的终端对性能指标的影响很大。
4)R5和R4小区的切换走RB重定位流程,目前我们系统的实现不是很成熟,R5和R4小区之间的切换失败会造成大量的掉话。
小区级掉话率较高,造成小区掉话的原因较多,主要有以下几种:
1)干扰造成的掉话:
(同频干扰、相关性较强的扰码引起的干扰、导频污染、上下行交叉时隙干扰、上下行导频间干扰、系统间干扰、其它无线设置的干扰)
2)切换造成的掉话:
(硬件故障导致切换异常、同频同扰码小区越区覆盖导致切换异常、越区孤岛切换问题、目标小区上行同步失败导致切换失败、无线参数设置不合理导致切换不及时)
3)基站硬件故障造成的掉话
4)终端问题造成的掉话
5)链路失衡造成的掉话
6)参数配置错误造成的掉话
7)覆盖问题造成的掉话(覆盖空洞造成的掉话、越区覆盖造成的掉话、孤岛效应导致的掉话、导频杂乱导致的掉话、阴影衰落导致的掉话)
2.1PS掉话的主要处理过程:
2.1.1RNC级PS掉话
1、出现RNC级掉话后,首先需确定该RNC级的掉话是由多个小区引起的,还是由个别高掉话的小区所导致。
如果是由个别小区引起的,应进行小区级的掉话处理步骤,否则进入网元级的掉话处理过程。
2、检查RNC的系统告警,检查是否存在相关硬件的告警信息,如果存在单板的告警,则需要进行排除。
3、从流量、HS的RAB增加数量、HS的掉话数量几个方面看,整体PS掉话率是否和HSDPA用户增加,HS高掉话率有关。
此次厦门PS掉话率急剧抬升就是由于HS用户/HS业务量增加有关。
4、在OMM上对PS掉话的原因进行统计,重点分析是哪种原因突然增多。
如果是operate_timeout原因的掉话数量很大,则通过CT查看是否是HSDPA与DCH信道之间切换超时掉话。
这类关键小区大多处在HSDPA小区的边缘,如果存在大量1、2载频的小区(都没有开通HSDPA),HSDPA数据卡在切换过程中容易发生operate_timeout,通过开通HSDPA后,可以规避一些掉话的发生。
5、在OMM上对PS掉话的原因进行统计,重点分析是哪种原因突然增多。
如果是“用户未激活(userinactivity)”所占比重较大,则是系统问题。
目前外场配置为15分钟没有流量后从DCH迁到IDLE,后续支持PCH态后,从DCH迁到PCH后,该部分掉话就不会计入了。
V1.30.112版本根据市场要求规划了PCH态功能。
6、在OMM上对PS掉话的原因进行统计,重点分析是哪种原因突然增多。
如果突然出现大量的UCIUError、RLFail、RNLCUnknow则很大的可能性是由于终端问题造成。
7、通过CT分析,定位到一些掉话频发的号码(用户),通过用户回访了解到用户的数据卡类型,借用相同类型的数据卡后,进行专项测试,测试的同时作信令跟踪、LMT跟踪等。
在厦门PS攻关中用这个方法定位了新邮通HSDPA卡,在DCH上难以保持业务,会出现多种现象的掉话以及多普达终端去激活过程没有发送正确信令,全部被RNC当异常流程作释放处理导致网络指标恶化。
8、检查CT数据中掉话部分的信令,分析其错误代码,常见的RNC级参数设置错误引起的掉话主要有以下几种:
错误代码
事件编号
CN_TRANAP_unknown_target_rnc
9
CN_TRANAP_release_due_to_utran_generated_reason
15
CN_TRANAP_user_plane_versions_not_supported
27
其中:
unknown_target_rnc则表明CN中对RNC的SGSN解析地址定义错误,此时容易造成PS业务RNC间切换失败,从而引起掉话的产生。
而user_plane_versions_not_supported则主要是由于版本问题造成的失败;如果产生release_due_to_utran_generated_reason原因则主要是由于硬件故障造成。
2.1.2小区级PS掉话
1、基站小区的告警日志检查
本着先硬后软的原则,如果是某个小区存在掉线率较高的情况,则需要先检查一下此小区是否存在硬件故障,同时请注意此时小区的CS业务同样存在问题。
2、基站小区干扰统计
小区的干扰统计主要包括两个方面的干扰统计,目前此类指标已经可以在后台进行统计,也可以算做是PI指标统计的一部分,通过判断小区时隙上的平均时隙干扰功率(15分钟粒度、并在晚上4点左右取数据)、最大时隙干扰功率(15分钟粒度、并在晚上4点左右取数据)、UpPCHPOS0~15上的干扰统计(15分钟粒度、并在晚上4点左右取数据),通过此项判断是否存在干扰(注:
如果存在干扰,则小区的CS掉话也较高)。
3、检查PS切换成功率是否正常,如切换成功率较低,则:
Ø邻小区关系中是否存在同频同扰码的现象,这种情况在路测中也可以发现,一般是在邻区表中出现两条相同的邻小区关系,这里需要注意的是业务同频同扰的现象,它无法在路测中发现,一般需要对信令进行分析,此时虽然两个小区主载频异频,但measurementreport却上报了1G事件,针对这种情况需要通过修改频点和扰码解决(可以通过系统自带的全局参数合法性检查工具进行检查)
Ø邻小区关系中是否存在同频同码组的现象,这种情况在路测中也可以发现,一般情况是它是影响到终端的测量结果,此时测量结果不准确,造成终端上报系统后系统判断错误,针对这种情况则需要修改频点和扰码解决(可以通过系统自带的全局参数合法性检查工具进行检查)
Ø是否存在单边邻小区关系,如果存在,添加单边邻区,单边小区的检查可以使用NOP-T工具进行,也可以通过对性能统计指标中的小区对切换统计指标来检查。
Ø是否存在异频邻小区个数过多的现象(异频邻区数超过8个),如果存在,删除不必要的邻区,这种情况可以使用NOP-T工具进行检查,也可以使用办公软件进行检查。
Ø是否存在切换开关设置的问题(有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止)。
如果存在,打开切换开关
Ø切换相关的事件定义是否准确,不区引用是否正确,如果存在,修改引用
ØPS切换失败是否存完整性算法问题,如果存在,将RNC、CN之间的完整性开关设成一致
Ø是否存在邻区漏配的情况。
需要用SCANNER路测发现是否存在漏配的情况。
如果存在,添加邻区。
Ø切换目标小区拥塞造成的掉话,由于目标小区的资源不足,而本小区的覆盖又越来越差,此时造成掉话。
常见的错误代码为no_resource_available或RRM_CellOverload_Release。
,对于容量原因造成的掉话,如果是拥塞业务较小,可以通过对负荷算法进行调整来,但如果拥塞率较高的情况,建议对小区进行扩容,增加业务载频的个数或是进行小区分裂(增加基站、增加小区)。
Ø切换时的业务种类,比如切换时的PS384业务、HSDPA业务,对于PS384业务很容易由于目标小区的资源问题造成切换失败后掉话,而HADPA业务则有可能由于R5业务的不连续覆盖造成掉话(注意HSPA业务为硬切换)。
对于R5业务不连续的情况,一般的建议为增加R5的覆盖区域,将之进行连续覆盖。
4、掉线发生时的大致场强:
主要是判断当时是否存在弱场覆盖,此项指标可以在MeasurementReport或RRCConnectionRequest中得出PCCPCH-RSCP的协议值(绝对值=协议值+(-116))。
5、检查掉线时的是否发生并发业务类型:
目前的并发业务主要有以下几种
ØPS+PS业务并发,主要是进行PS业务时可能有彩信等背景类PS业务发生
ØPS+CS业务并发,在进行PS业务时有电话接入或是在进行电话时有彩信等背景类PS业务发生。
ØCS+CS并发,主要是进行CS业务时有短信业务发生
如果存在则有可能是终端多业务性能较差造成,也有可能是由于并发业务相关参数设置存在问题(比如没有打开2个PS业务并)等造成。
6、掉线发生时的时隙和码道位置,主要是时隙位置:
可以判断是否由于某一个时隙上的原因造成的,有可能是由于交叉时隙干扰或室内分布系统中干放时隙转换点与NodeB上设置不同造成的,或是否发生了同频同时隙的切换
第3章接入问题原因及解决办法
3.1接入问题分析触发点及获取信令方式
✓用户投诉语音或视频无法接通,首先判断投诉所在的RNC及小区,根据用户投诉的IMSI号和时间获取CT文件,对信令进行分析;无法获取IMSI号或无法确定小区时,要联系用户现场复测,使用后台信令跟踪工具和路测软件获取信令过程。
✓话统数据显示某段时间CS或PS接通率明显下降,获取该时段的CT文件进行分析,如果仅凭CT的信令无法定位问题,回访用户获取问题地点/UE类型/用户的行为。
3.2接入失败问题定位
接入失败的定义及可能的问题原因包括以下几类:
1、拨号后,RRCConnectionRequest消息没有发送;——是否手机异常
2、在主叫UE发送了RRCConnectionRequest后,定时器超时,没有收到RRCConnectionSetup消息;——RNC没有收到请求,优先确认是否是弱场区域(RSCP值小于-95dBm),其次判断UPPTS时隙是否存在干扰,判断方法为从OMC上提取凌晨12点~3点的16个POS的功率值,若从第6个POS位置开始,功率大于-90dBm,即可判断为UP干扰,进行upshifting之后,再进行呼叫尝试。
若RNC还是没有收到请求,则需要通过现场路测的或从该UE的切换测量报告中判断该终端所处位置的C/I是否大于-3,若小于-3,需要通过调整工程参数或频点改善C/I,调整后再进行呼叫尝试。
若RNC还是没有收到请求,则需要调整PRACH信道功率。
若RNC发了建立消息,但UE没有收到,是否是手机发生重选,则优化重选参数;若没有发生重选,则首先需要判断是否为弱场区域,其次看失败点的C/I是否满足大于-3dB的要求,最好才考虑调整FPACH功率。
3、主叫UE在发出RRCConnectionRequest后,收到RRCConnectionReject消息。
并且没有重发RRCConnectionRequest进行尝试;——根据拒绝原因定位问题。
4、主叫UE在收到RRCConnectionSetup消息后,没有发出RRCConnectionComplete消息;——通过在RNC侧看似否有RadioLinkRestoreIndication消息,判断是上行开环还是下行开环有问题,若RNC侧收到了RadioLinkRestoreIndication,则说明上行开环已完成,则首先需要判断下行业务时隙是否有干扰,若有干扰,优先排除干扰,其次核查设备的天线类型,下行开环功控参数是否正常,最好才考虑调整下行初始发射功率;若RNC没有收到RadioLinkRestoreIndication,则首先需要判断上行业务时隙是否有干扰,若有干扰,优先排除干扰,其次核查设备的天线类型,上行开环功控参数是否正常,最好才考虑调整上行开环功控参数;
5、主叫UE在收到RRCConnectionSetup消息后收到或是发出了RRCConnectionRelease消息;――根据Release原因值判断原因
6、主叫UE在发送了RRCConnectionComplete消息后,没有收到MeasurementControl消息;――首先判断RNC侧是否收到了RRCConnectionComplete,若没有,需要核查上行业务时隙是否存在干扰,若没有干扰,需要根据RRCConnectionRequest消息中携带的本小区的RSCP值判断起呼点是否是弱场(小于-95dBm),若不是弱场,可能终端异常,需要现场换终端进行验证。
若RNC收到并下发了MeasurementControl,则首先需要排查下行时隙是否存在干扰,没有干扰,需要判断终端所在位置是否为弱场。
7、主叫UE收到了ServiceRequestReject消息;――参数配置错误可能性最大
8、主叫UE在发送了CMServiceRequest消息后,鉴权和安全模式控制失败;--终端的鉴权算法可能有问题,更换终端进行尝试定位。
9、UE完成鉴权和安全模式控制后,RNC返回RABassignmentFail;――根据fail的原因值进行定位。
目前已经发现的原因值为”TRANAP_invalid_rab_parameters_value”,在信令上,表现为UE去激活后,在不到1s的时间内终端发起了第二次激活,第二次激活的RAB指配失败,主要是由于核心网没有优先处理去激活请求导致。
第4章切换问题原因及解决办法
TD-SCDMA系统中的切换问题相对于2G网络(CDMA、GSM)的切换问题其重要性有所降低,这主要是TD-SCDMA系统采用了切换的回滚机制,如果切换不成功UE会返回到原来的小区进行,从而使得业务继续保持,但切换仍然会造成掉话率抬升、通话质量较量等现象,并且TD-SCDMA系统考查的切换指标更加复杂,主要有硬切换成功率、接力切换成功率、RNC内同频硬切换成功率、RNC内异频硬切换成功率、RNC内同频接力切换成功率、RNC内异频接力切换成功率、RNC间同频硬切换成功率、RNC间异频硬切换成功率、切出成功率、切入成功率、系统间CS业务切换成功率、系统间PS业务切换成功率等指标,切换问题也是日常优化即常见又重要的一个问题。
4.1切换问题的发现
4.1.1路测中发现切换问题
在日常的优化工作中,通过室外的测试(DT)发现UE在个别小区或是个别RNC或是全网存在不切换或是切换掉话等现象。
4.1.2系统侧KPI统计中发现切换问题
通过日常的KPI性能指标检测,发现部分小区或是
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 无线 性能 优化 思路