1 网优类1.1 掉话类掉话排查总体思路流程图1.1.1 CS掉话类问题处理流程现网的掉话监测分成RNC级的掉话与小区级的掉话两个方面，若出现网元大面积掉话，可能由RNC硬件故障引起。

但还有一种情况是全网所有的RNC掉话率都较高，此时可以考虑可能是由于CN的故障或是由其它系统原因造成，比如系统升级。

造成RNC掉话升级的原因可以有以下几种：1. 参数配置错误：这有两个方面参数配置存在问题，一是RNC中的全局参数配置存在问题，另一方面是由CN中对RNC的参数配置存在问题。

2. RNC硬件故障问题：需要通过对RNC告警的检查以及对RNC日志的检查来确定是否是由硬件故障引起。

小区级掉话率较高，造成小区掉话的原因较多，主要有以下几种：1. 干扰造成的掉话：（同频干扰、相关性较强的扰码引起的干扰、导频污染、上下行交叉时隙干扰、上下行导频间干扰、系统间干扰、其它无线设置的干扰）2. 切换造成的掉话：（硬件故障导致切换异常、同频同扰码小区越区覆盖导致切换异常、越区孤岛切换问题、目标小区上行同步失败导致切换失败、无线参数设置不合理导致切换不及时）3. 基站硬件故障造成的掉话4. 终端问题造成的掉话5. 链路失衡造成的掉话6. 参数配置错误造成的掉话覆盖问题造成的掉话（覆盖空洞造成的掉话、越区覆盖造成的掉话、孤岛效应导致的掉话、导频杂乱导致的掉话、阴影衰落导致的掉话）1.1.1.1 RNC级问题处理思路1. 确定问题小区的分布情况（比如是否集中在同一框的某一单板上）。

2. 出现RNC级掉话后，首先需确定该RNC级的掉话是由多个小区引起的，还是由个别高掉话的小区所导致。

如果是由个别小区引起的，应进行小区级的掉话处理步骤，否则进入网元级的掉话处理过程。

3. 检查RNC的系统告警，检查是否存在相关硬件的告警信息，如果存在单板的告警，则需要进行排除。

4. 检查RNC的系统日志，对其中不正常部分进行检查。

5. 检查CT数据中掉话部分的信令，分析其错误代码，常见的RNC级参数设置错误引起的掉话主要有以下几种：其中：unknown_target_rnc则表明CN中对RNC的SGSN解析地址定义错误，此时容易造成PS业务RNC间切换失败，从而引起掉话的产生。

而user_plane_versions_not_supported则主要是由于版本问题造成的失败；如果产生release_due_to_utran_generated_reason原因则主要是由于硬件故障造成。

1.1.1.2 小区级问题处理思路1. 确定问题小区的分布情况（比如是否集中在同一框的某一单板上）。

2. 出现小区级掉话时，首先查看该小区是否有硬件故障告警，如果有，首先要求用服人员解决硬件故障问题。

3. 检查切出成功率是否正常，如果切换成功率较低，检查邻区关系以及是否存在同频同码的情况。

-邻小区关系中是否存在同频同扰码的现象，这种情况在路测中也可以发现，一般是在邻区表中出现两条相同的邻小区关系，这里需要注意的是业务同频同扰的现象，它无法在路测中发现，一般需要对信令进行分析，此时虽然两个小区主载频异频，但measurementreport却上报了1G事件，针对这种情况需要通过修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查）-邻小区关系中是否存在同频同码组的现象，这种情况在路测中也可以发现，一般情况是它是影响到终端的测量结果，此时测量结果不准确，造成终端上报系统后系统判断错误，针对这种情况则需要修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查）-是否存在单边邻小区关系，如果存在，添加单边邻区，单边小区的检查可以使用NOP-T工具进行，也可以通过对性能统计指标中的小区对切换统计指标来检查。

-是否存在异频邻小区个数过多的现象（异频邻区数超过8个），如果存在，删除不必要的邻区，这种情况可以使用NOP-T工具进行检查，也可以使用办公软件进行检查。

-是否存在切换开关设置的问题（有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止）。

如果存在，打开切换开关-切换相关的事件定义是否准确，不区引用是否正确，如果存在，修改引用-PS切换失败是否存完整性算法问题，如果存在，将RNC、CN之间的完整性开关设成一致-是否存在邻区漏配的情况。

需要用SCANNER路测发现是否存在漏配的情况。

如果存在，添加邻区。

-目标小区拥塞造成的掉话，由于目标小区的资源不足，而本小区的覆盖又越来越差，此时造成掉话。

常见的错误代码为no_resource_available或RRM_CellOverload_Release4. 检查时隙转换点配置是否正确，是否存在交叉时隙干扰。

如果存在，修改时隙转换点。

5. 检查UP时隙和上行业务时隙的干扰电平，是否存在上行干扰导致掉话。

如果存在，进行干扰排查6. 根据性能指标统计，如果PS域和CS域的BLER都比较高则有可能存在干扰，然后再结合载频时隙干扰统计指标来判断是否确实存在干扰，另外通过对信令的分析如存在干扰则一般信令流程正常，未有切换事件或其它事件，但RNC进行了IURELEASE，原因一般为无线链路的原因。

（比如无线链路错误等），有时也会发生CELLUPDATE 原因为RLCunrecoverable error如果确实存在则需要现场排除，现场测试时如果存在干扰则有以下几个方面的显示-C/I较差：系统内同频的干扰较为严重，发生掉话时会存在终端发射功率较高，的现象，同时覆盖也相对较好，表现在RSCP值上，一般都在-90dBm以上，另外一表现象就是起呼比较困难，而起呼成功率后也很容易掉话-终端发射功率较高，基本上满功率发射，一般都在20以上-系统外的干扰造成的掉话同样具有终端发射功率较高的现象，也一般都都在20以上-系统外干扰造成掉话时也可以通过误块率指标进行判断，此时无论是进行CS业务还是进行PS业务，BLER都比较高，并且保持时间较长-系统外干扰语音业务判断，此时进行通话会出现断字、吞字、金属声等现象，比较难以进行通话。

7. 通过对性能指标的统计，主要是对RRC连接成功率的统计，这其中的统计包括业务相关和非业务相关的统计，如果两种统计都较差，则有可能存在覆盖问题，此时可以检查CT数据中RRC CONNECTIONREQUEST中的PCCPCH的值，则说明存在弱覆盖现象，需要进行功率参数、天线方向角、下倾角的调整。

8. 如果上述都检查不出原因，可能是载波、时隙的隐性故障，此时可以尝试闭解载波时隙，或者强行闭载波、时隙观察掉话率的变化。

9. 终端问题，一般是通过对大量的性能数据统计，发现掉话高的小区，然后依据小区性能数据分析信令，可以看出掉话常发生的用户，而后进行处理。

目前常见的终端问题为UP同步存在问题，此时容易在切换时产生Ue_Operate_fail_physicalchannelfailure错误。

1.1.1.3 按问题原因错误码处理思路上表为目前TD外场CS域掉话原因最多的4种原因（错误码），占全部掉话总量的92%左右。

下面我们针对每个原因的掉话情况进行排查分析说明，排查大概思路是从无线到设备，从外部到内部，从软（空口环境、参数设置）到硬（硬件故障）。

本节中涉及到的覆盖排查、干扰排查在前面的1.1节中都有详细描述，故本节中对此类排查不予详细描述。

UCIU_error错误原因机制：UCIU error表示RLC（无线链路控制层）不可恢复性错误。

从结构模型看，RLC层是比物理层高。

发生UCIU error故障（掉话），说明链路的物理层是正常的，RLC层出现故障。

当RLC层发生传递失败后，会首先进行重传尝试，如果重传成功，链路的RLC 层恢复；当重传达到最大次数后RLC层仍没有传递成功，发送端可发起RLC层的复位，恢复RLC的全部初始参数，如果复位能够成功，那么RLC重新开始向接收端作重传尝试；当复位达到最大次数后，复位仍不成功，发送端认为RLC发生了不可恢复性错误。

（UCIU error）。

RNC作UCIU error释放，意味着下行链路的RLC发生了不可恢复性错误。

排查思路：-确定问题小区的分布情况（比如是否集中在同一框的某一单板上）。

-检查这些小区的状态和告警信息，包括RRU的驻波比等，看是否由于设备原因导致UCIU_error。

Iub口传输质量不好导致的严重丢包。

一般来讲，由于设备侧异常会导致整个NodeB的小区掉话率非常高，比较易于从后台KPI指标发现并且处理优先级高，现网中这种情况应该较少。

-无线参数核查，利用网管自带小区参数模板核查功能进行参数核查（重点关注问题小区与正常小区有出入的参数配置，同时要甄别一些日常网优调整的常规参数如小区个性偏移、迟滞值等）。

-确定事件发生时间点上当时的场强情况，可能由于弱场导致下行RLC发生不可恢复性错误。

-对系统内、外的上、下行干扰情况进行排查。

跟踪后台这些小区的LMT载波测量，同时跟踪这些小区的信令，或者采集后台的CT数据，将信令时间和LMT时间对齐（计算出差值)，对于后台CT中由于UCIU_error掉话的业务对照LMT数据进行分析，主要关注业务所在载波的上行的ISCP值和下行的TCP值，上行ISCP过高或者是有突变，说明是上行干扰过大导致ACK不能反馈上来，下行TCP过大，说明UE需要的功率过大，表明有弱覆盖或者是下行强干扰。

-更换终端进行测试，排除特定问题终端因素。

RNLC_Ue_IntraRNCHo_TimeOut错误原因机制：该原因的掉话从信令流程上看是由于RNC下发RNC内切换的物理信道重配置或者RB重配消息后，启动一个定时器，在定时器超时前没有收到物理信道重配置完成或者RB重配完成消息，则RNC发起IU释放请求。

排查思路：-确定问题小区的分布情况（比如是否集中在同一框的某一单板上）。

-查看告警，排查告警问题。

-无线参数核查，利用网管自带小区参数模板核查功能进行参数核查。

-NodeB、传输等数据配置核查。

-RNC下发的物理信道重配置或者RB重配消息，终端没有正常接收到。

排查覆盖情况、下行干扰情况。

用LMT跟踪小区TCP，若TCP过大说明终端需要的下行发射功率很大，可判断下行弱覆盖或者有干扰。

-终端收到了RNC下发的物理信道重配置或者RB重配消息，上报了物理信道重配置完成或者RB重配完成消息，RNC没有收到，首先排查上行干扰情况。

用LMT跟踪小区上行ISCP，如果上行ISCP过高或者有突变则可判定存在上行干扰。

-更换终端进行测试，排除特定问题终端因素。

-排查NodeB硬件故障。

RNLC_Ue_Cellupdate_TimeOut错误原因机制：UE发送cellupdate，RNC响应后下发cellupdate confirm并设置等待定时器，定时器默认长度为5s，定时器超前如果未收到终端的物理信道重配完成消息，则发起Iu Release Request。