问题处理思路树V1.2.doc

内部公开无线性能优化思路树关于本书文件编号版本号拟制人/修改人拟制/修改日期更改理由主要更改内容V1.0顾健/1295242008/11/11完成初稿无V1.1原学军/1528562009/01/08添加增加PS掉线原因分析注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 -I第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.1 RNC级掉话1、 出现RNC级掉话后，首先需确定该RNC级的掉话是由多个小区引起的，还是由个别高掉话的小区所导致。如果是由个别小区引起的，应进行小区级的掉话处理步骤，否则进入网元级的掉话处理过程。2、 检查RNC的系统告警，检查是否存在相关硬件的告警信息，如果存在单板的告警，则需要进行排除。3、 检查RNC的系统日志，对其中不正常部分进行检查。4、 检查CT数据中掉话部分的信令，分析其错误代码，常见的RNC级参数设置错误引起的掉话主要有以下几种：错误代码事件编号CN_TRANAP_unknown_target_rnc 9CN_TRANAP_release_due_to_utran_generated_reason 15CN_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、 检查切出成功率是否正常，如果切换成功率较低，检查邻区关系以及是否存在同频同码的情况。 邻小区关系中是否存在同频同扰码的现象，这种情况在路测中也可以发现，一般是在邻区表中出现两条相同的邻小区关系，这里需要注意的是业务同频同扰的现象，它无法在路测中发现，一般需要对信令进行分析，此时虽然两个小区主载频异频，但measurement report却上报了1G事件，针对这种情况需要通过修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查） 邻小区关系中是否存在同频同码组的现象，这种情况在路测中也可以发现，一般情况是它是影响到终端的测量结果，此时测量结果不准确，造成终端上报系统后系统判断错误，针对这种情况则需要修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查） 是否存在单边邻小区关系，如果存在，添加单边邻区，单边小区的检查可以使用NOP-T工具进行，也可以通过对性能统计指标中的小区对切换统计指标来检查。 是否存在异频邻小区个数过多的现象（异频邻区数超过8个），如果存在，删除不必要的邻区，这种情况可以使用NOP-T工具进行检查，也可以使用办公软件进行检查。 是否存在切换开关设置的问题（有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止）。如果存在，打开切换开关 切换相关的事件定义是否准确，不区引用是否正确，如果存在，修改引用 PS切换失败是否存完整性算法问题，如果存在，将RNC、CN之间的完整性开关设成一致 是否存在邻区漏配的情况。需要用SCANNER路测发现是否存在漏配的情况。如果存在，添加邻区。 目标小区拥塞造成的掉话，由于目标小区的资源不足，而本小区的覆盖又越来越差，此时造成掉话。常见的错误代码为no_resource_available或RRM_CellOverload_Release3、 检查时隙转换点配置是否正确，是否存在交叉时隙干扰。如果存在，修改时隙转换点。4、 检查UP时隙和上行业务时隙的干扰电平，是否存在上行干扰导致掉话。如果存在，进行干扰排查5、 根据性能指标统计，如果PS域和CS域的BLER都比较高则有可能存在干扰，然后再结合载频时隙干扰统计指标来判断是否确实存在干扰，另外通过对信令的分析如存在干扰则一般信令流程正常，未有切换事件或其它事件，但RNC进行了IURELEASE，原因一般为无线链路的原因。（比如无线链路错误等），有时也会发生CELLUPDATE 原因为RLCunrecoverable error如果确实存在则需要现场排除，现场测试时如果存在干扰则有以下几个方面的显示l C/I较差：系统内同频的干扰较为严重，发生掉话时会存在终端发射功率较高，的现象，同时覆盖也相对较好，表现在RSCP值上，一般都在-90dBm以上，另外一表现象就是起呼比较困难，而起呼成功率后也很容易掉话l 终端发射功率较高，基本上满功率发射，一般都在-20dBm以上l 系统外的干扰造成的掉话同样具有终端发射功率较高的现象，也一般都都在-20dBm以上l 系统外干扰造成掉话时也可以通过误块率指标进行判断，此时无论是进行CS业务还是进行PS业务，BLER都比较高，并且保持时间较长l 系统外干扰语音业务判断，此时进行通话会出现断字、吞字、金属声等现象，比较难以进行通话。6、 通过对性能指标的统计，主要是对RRC连接成功率的统计，这其中的统计包括业务相关和非业务相关的统计，如果两种统计都较差，则有可能存在覆盖问题，此时可以检查CT数据中RRC CONNECTION REQUEST中的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.1 PS掉话的主要处理过程：2.1.1 RNC级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后，可以规避一些掉话的发生。下面是对物理信道或是RB重配置超时以及CELLUPDATE的原因分析： 物理信道重配置超时或RB重配置超时（Ue_Operate_TimeOut）对于物理信道重配置超时或RB重配置超时，常见的有以下几种可能性： 存在UPPCH的干扰，如果是硬切换的情况下会造成随机接入过程的失败，从而造成物理信道重配置失败，Cause值为2。 HS业务与R4业务之间的切换失败，包括从R4到R5的切换和从R5到R4的切换，这种原因主要表现为RB重配置超时。 虚假的邻小区关系造成物理信道重配置超时 RB重配置参数设置不合理造成RB重配置超时 功率参数配置不合理造成RB或物理信道重配置超时目前外场常见的原因主要是终端问题和R5与R4业务之间的切换问题。 UeReportCellUpdate产生CellUpdate的直接原因是UE判断下行失败造成，当UE在一定的时间内没有收到系统下发的消息，会认为下行无线质量恶化导，进一步判断下行失步后，此时UE会上报小区更新（CellUpdate），网络侧根据小区更新的目标小区分配无线资源，因此小区更新（CellUpdate）有两种可能性： 第一种可能性，小区更新（CellUpdate）发生在本小区，如果来自在当前归属小区，出于规避下行干扰的考虑将为终端分配新的物理资源，如果此时该小区剩余资源不足时，会出现小区更新资源不足而导致掉话。并且在本小区上报小区更新（CellUpdate）从另一方面也可以认为部分RLC层参数（N315、T313等）配置不合理造成。 第二种可能性，小区更新（CellUpdate）发生在其它小区，此种情况发果系统侧同时报了RLFail基本上可以认定是无线覆盖的原因或是C/I较差造成。5、 在OMM上对PS掉话的原因进行统计，重点分析是哪种原因突然增多。如果是“用户未激活（user inactivity）”所占比重较大，则是系统问题。目前外场配置为15分钟没有流量后从DCH迁到IDLE，后续支持PCH态后，从DCH迁到PCH后，该部分掉话就不会计入了。 V1.30.112版本根据市场要求规划了PCH态功能。6、 在OMM上对PS掉话的原因进行统计，重点分析是哪种原因突然增多。如果突然出现大量的UCIU Error 、RL Fail、RNLC Unknow则很大的可能性是由于终端问题造成。下面详细对RLFail_Report和UCIU Error两种原因进行分析： RlFail_Report产生RLFail的直接原因是RNC判断上行失败造成，从目前的优化经验来看，主要有三个方面造成了这种原因1）终端侧出现异常当终端发生异常，没有上发信号，导致基站侧检测不到上行信号而报无线链路失败，终端侧的异常包括： 终端本身出现异常，比如死机。 终端与电脑的连接出现异常，比如连接线、USB插口、插槽因为松动而断线，或终端在电脑上的驱动程序出现异常。 终端在电脑上的应用程序出现异常。 电脑出现异常导致终端方面异常。如果终端侧出现异常，要重新作起业务，一般要对终端进行重启，终端重启后将会进行一次Location Update过程，这从系统侧后台信令上可以观察到，并且从上次RL Failure导致掉话到下次重新作起业务来也将会有较大的时延，通常要超过30秒。2）无线信道环境出现深衰落或者强干扰无线信道环境出现深衰落或强干扰时，会导致基站没有解对终端发出的上行信号而报RL Failure，如果是出现深衰落，下行链路的无线信道环境跟上行链路一样，信道质量变差，下行功率会抬升得比较高，并且UE会上报Cell Update。3）基站侧出现异常基站解错上行信号或接收不到上行信号而报无线链路失败。此时基站应该会出现告警，且基本上不能接入和保持住包括PS在内的任何业务或终端了。 UCIU Error产生UCIU Error的直接原因是用户出错误，RLC达到最大复位重发次数后产生的错误，产生此种错误的原因主要以下几种原因： RLC层发生了不恢复的错误 参数配置错误，曾经在天津外场做过偿试，关闭掉RBC算法后UCIU Error错误上升了300%左右。 无线覆盖原因，其主要还是造成了RLC层的错误 基站故障 部分终端原因也会造成此这种原因的出现。对于此种原因，暂时没有找到相应的解决方案7、 通过CT分析，定位到一些掉话频发的号码（用户），通过用户回访了解到用户的数据卡类型，借用相同类型的数据卡后，进行专项测试，测试的同时作信令跟踪、LMT跟踪等。在厦门PS攻关中用这个方法定位了新邮通HSDPA卡，在DCH上难以保持业务，会出现多种现象的掉话以及多普达终端去激活过程没有发送正确信令，全部被RNC当异常流程作释放处理导致网络指标恶化。8、 检查CT数据中掉话部分的信令，分析其错误代码，常见的RNC级参数设置错误引起的掉话主要有以下几种：错误代码事件编号CN_TRANAP_unknown_target_rnc 9CN_TRANAP_release_due_to_utran_generated_reason 15CN_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点左右取数据）、UpPCH POS015上的干扰统计（15分钟粒度、并在晚上4点左右取数据），通过此项判断是否存在干扰（注：如果存在干扰，则小区的CS掉话也较高）。3、 检查PS切换成功率是否正常，如切换成功率较低，则： 邻小区关系中是否存在同频同扰码的现象，这种情况在路测中也可以发现，一般是在邻区表中出现两条相同的邻小区关系，这里需要注意的是业务同频同扰的现象，它无法在路测中发现，一般需要对信令进行分析，此时虽然两个小区主载频异频，但measurement report却上报了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、 掉线发生时的大致场强：主要是判断当时是否存在弱场覆盖，此项指标可以在Measurement Report或RRC Connection Request中得出PCCPCH-RSCP的协议值（绝对值=协议值+（-116）。5、 检查掉线时的是否发生并发业务类型：目前的并发业务主要有以下几种 PS+PS业务并发，主要是进行PS业务时可能有彩信等背景类PS业务发生 PS+CS业务并发，在进行PS业务时有电话接入或是在进行电话时有彩信等背景类PS业务发生。 CS+CS并发，主要是进行CS业务时有短信业务发生如果存在则有可能是终端多业务性能较差造成，也有可能是由于并发业务相关参数设置存在问题（比如没有打开2个PS业务并）等造成。6、 掉线发生时的时隙和码道位置，主要是时隙位置：可以判断是否由于某一个时隙上的原因造成的，有可能是由于交叉时隙干扰或室内分布系统中干放时隙转换点与Node B上设置不同造成的，或是否发生了同频同时隙的切换。- 23 -第3章 接入问题原因及解决办法3.1 接入问题分析触发点及获取信令方式 用户投诉语音或视频无法接通，首先判断投诉所在的RNC及小区，根据用户投诉的IMSI号和时间获取CT文件，对信令进行分析；无法获取IMSI号或无法确定小区时，要联系用户现场复测，使用后台信令跟踪工具和路测软件获取信令过程。 话统数据显示某段时间CS或PS接通率明显下降，获取该时段的CT文件进行分析，如果仅凭CT的信令无法定位问题，回访用户获取问题地点/UE类型/用户的行为。3.2 接入失败问题定位接入失败的定义及可能的问题原因包括以下几类：1、拨号后，RRC Connection Request消息没有发送；是否手机异常2、在主叫UE发送了RRC Connection Request后，定时器超时，没有收到RRC Connection Setup消息；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在发出RRC Connection Request后，收到RRC Connection Reject消息。并且没有重发RRC Connection Request进行尝试；根据拒绝原因定位问题。4、主叫UE在收到RRC Connection Setup消息后，没有发出RRC Connection Complete消息；通过在RNC侧看似否有RadioLinkRestoreIndication消息，判断是上行开环还是下行开环有问题，若RNC侧收到了RadioLinkRestoreIndication，则说明上行开环已完成，则首先需要判断下行业务时隙是否有干扰，若有干扰，优先排除干扰，其次核查设备的天线类型，下行开环功控参数是否正常，最好才考虑调整下行初始发射功率；若RNC没有收到RadioLinkRestoreIndication，则首先需要判断上行业务时隙是否有干扰，若有干扰，优先排除干扰，其次核查设备的天线类型，上行开环功控参数是否正常，最好才考虑调整上行开环功控参数；5、主叫UE在收到RRC Connection Setup消息后收到或是发出了RRC Connection Release消息；根据Release原因值判断原因6、主叫UE在发送了RRC Connection Complete消息后，没有收到Measurement Control消息；首先判断RNC侧是否收到了RRC Connection Complete，若没有，需要核查上行业务时隙是否存在干扰，若没有干扰，需要根据RRCConnectionRequest消息中携带的本小区的RSCP值判断起呼点是否是弱场（小于-95dBm），若不是弱场，可能终端异常，需要现场换终端进行验证。若RNC收到并下发了Measurement Control，则首先需要排查下行时隙是否存在干扰，没有干扰，需要判断终端所在位置是否为弱场。 7、主叫UE收到了Service Request Reject消息；参数配置错误可能性最大8、主叫UE在发送了CM Service Request消息后，鉴权和安全模式控制失败；-终端的鉴权算法可能有问题，更换终端进行尝试定位。 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性能指标检测，发现部分小区或是RNC或是全网存在切换问题，主要表现为切换成功率低等现象（系统内、切入、切出、系统间、接力、硬切）。4.2 切换问题主要原因在切换过程中，常常会出现以下几种异常信令情况：（1）终端上报测量报告，但是由于上行信道质量不好或失步，导致RNC收不到测量报告，使得服务小区一直发测量报告，且服务小区信号已经很差了，却不能发起切换；（2）RNC接收到测量报告，但由于下行失步，导致随后下发的测量控制UE不能收到，同样UE不停发测量报告，却不能发起切换；（3）UE由于和原小区失步，收不到原小区DCH数据，即收不到物理信道重配置信令，导致无法切换；（4）UE收到物理信道重配置消息，却无法在新小区建立上行同步，导致帧定时跟踪出现问题，这样UE无法在目标小区正确收发，正常情况下此时会回到原小区发物理信道重配置失败，若此时原小区失步的话，则无法回滚，导致物理信道重配置超时；（5）UE收到物理信道重配置消息，由于原小区或周围邻小区对目标小区的下行信号有干扰，导致UE无法正确解析目标小区的下行信号，导致不能与目标小区建立同步，而引发物理信道重配置超时；（6）UE已向目标Node B发送物理信道重配置完成信令，但是由于目标小区Node B底噪过高，或此时多部UE位于小区边缘，且上行发射功率都被抬升的比较高，导致产生较大的上行时隙干扰，使得目标小区Node B无法正确解析重配置完成的信令，而引发物理信道重配置超时。（7）系统侧切换参数配置不合理，造成UE在系统下只测量不切换，或是无法切换等原因，从而造成掉话。4.3 切换问题解决思路切换问题的解决思路，一般来说做如下判断：1） 判断是全网的现象或是个别RNC的现象2） 判断是个别小区的现象还是整个Node B的现象3） 判断是否是偶然的切换失败现象4.3.1 RNC或全网切换失败问题由于全网的切换问题直接包括了Node B、RNC、CN等所有网元在内的因素，所以对于全网（RNC）性的切换问题很少发生，一旦发生则是整个系统存在问题，如果是路测时发现此类问题，请检查是否是测试终端存在问题，如不是，请系统工程师检查问题。4.3.2 RNC内切换失败问题RNC内切换问题，处理思路如下：1）切换成功率指标分析：分析切换成功率的种类，从OMM服务器或是MINOS服务器上对切换成功率进行简要分析，分析是何种切换较差造成了整体切换成功率较差，是同频硬切换还是异频硬切换，是同频硬切换切出失败高还是切入失败高。2）分析关连指标：根据第一步的结果，提取更详细的相关信息，以及相关的记数器值进行统计，将之具体到各个小区、相关用户、相关的记数器值；常见的分析指标（切换失败原因指标）如下：（1）RNC内切出准备次数 与 切换出尝试次数正常情况下，RNC内切换出尝试次数基本等同RNC内切出准备次数。如果RNC内切换出尝试次数明显小于RNC内切出准备次数，说明失败情况较多。可能原因： 在目标小区建立新链路失败，通过对应计数器“RNC内切换出准备失败次数，在目标小区建立新链路失败”可以查看，也可以找到对应的小区，通过calltrace信令看看是否有NODEB 返回的RL链接建立失败相关信令。如果确认，进行进一步排查Iub口传输是否正常，以及获取NODEB的log进行分析。 其它原因： 查看计数器“RNC内切换出准备失败次数，其他原因”,原因为RRM 内部处理失败，如果为资源分配失败，需要确认目标小区资源情况，可能原因目标小区拥塞。如果为测量报告内小区与邻区信息不匹配，可能为其它同频同扰码小区虚假信号导致。（2）RNC内异频（同频）硬切换出失败次数，physical channel failure意为UE收到RNC下发的Physical Channel Reconfig消息后，向目标小区同步，由于同步失败，UE在原小区上报切换失败（原因为physical channel failure）。产生的原因有以下几种可能性： 其它同频同扰码小区虚假信号导致 FACH功率不足，在UE与目标小区同步时失步 覆盖问题，目标小区RSCP和C/I较差，UE与之无法取得同步 同频干扰，造成在切换时C/I较差，UE与目标小区无法取得同步（3）检查基站小区的故障：检查相关的小区是否存在硬件故障告警，特别GPS等硬件故障，这会严重影响切换的成功率（一旦GPS失步），如存在相关的硬件故障，请相关团队协助解决。（4）检查切换参数配置：这其中主要包括以下几项： 邻小区关系中是否存在同频同扰码的现象，包括业务同频同扰的现象 邻小区关系中是否存在同频同码组的现象 是否存在单边邻小区关系 是否存在异频邻小区个数过多的现象（多为手误而超过了9个） 是否存在邻区漏配的情况 是否存在切换开关设置的问题（有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止） 切换相关的事件定义是否准确，不区引用是否正确 PS切换失败是否存完整性算法问题。（5）对前几步的数据进行汇总，进行切换失败原因的分类（具体到小区）：造成切换的原因相对较多，从指标的相关性来看，可能存在以下几种原因： 如果相关小区的RRC连接成功率比较低，则有可能存在覆盖问题，建议进行现场的测试。 如果相关小区的RAB建立成功率比较低，则有可能是存在参数设置问题，建议进行相关参数的检查。 如果是小区的RL失败次数较多，则有可能存在小区的干扰或小区的上行导频时隙的干扰，建议进行干扰指标的分析或UPPCH干扰的检查 如果小区的的CELL UPDATE较多，则有可能是相关的功率配置不足或是小区同步指标相关参数设置问题，建议进行查检 如果小区的物理信道重配置失败，则有可能是存在一个同频同扰码的小区（此小区不在邻区表中，但邻区表中有一个相同扰码的邻小区关系，并且这两个小区相隔不远）或是目标小区的C/I较差，即覆盖问题或是同频干扰问题。 如果存在大理的UCIUerror（此意为用户面的错，则有可能是存在覆盖问题），无线链路存在问题。 如果存在2G或3G切换开关打开，可以关闭进行验证，是否是其影响，造成切换成功率较差（UE测量能力有限） 如果存在大量的Ue_Operat_Timeout，则有可能是存在RBC算法或是物理信道的同步存在问题，其会影响到掉话率。第5章 干扰问题解决办法干扰是无线通信中常见的影响到系统性能和用户感受的一个重要问题，它的产生是多种多样的，某些专用无线电系统占用没有明确划分的频率资源、不同运营商网络配置不当、收发滤波器的性能、小区重叠、环境、电磁兼容（EMC）以及有意干扰，都是移动通信网络射频干扰产生的原因。