WCDMA日常优化中TOP小区处理指导.doc

WCDMA日常优化TOP小区处理指导目 录1 概述32 工作范围描述42.1 工作范围42.2 工具准备52.3 信息收集52.4 操作步骤62.4.1 关键/风险点62.4.2 Timelines62.4.3 Checklist73 问题小区筛选83.1 通过NASTAR生成每天各项指标的TOP 10小区。83.2 利用insightsharp进行问题小区预过滤93.2.1 日志类型介绍93.2.2 预过滤功能介绍93.2.3 各类指标预过滤方法93.2.4 指标过滤方法举例104 问题小区处理思路124.1 接入问题分析124.1.1 RRC建立失败124.1.2 RAB指配失败144.2 切换问题分析164.2.1 软切换失败164.2.2 硬切换失败174.2.3 系统间切换失败174.3 掉话问题分析194.4 干扰问题分析224.4.1 内部干扰定位224.4.2 外部干扰定位234.4.3 下行干扰定位251 概述问题小区处理是日常网络优化中每天必须进行的一项工作，其主要是对网络故障或性能下降小区进行分析和处理，同时对每日综合指标最差的TOP小区进行集中处理，解决网络问题，消除网络隐患，提升网络质量。问题小区处理主要涉及四类工作：问题小区分析、干扰排查、工单处理跟踪、测试验证。2 工作范围描述2.1 工作范围（1） 问题小区筛选1) 问题小区生成：每日对日常投诉、指标和告警监控和DT、CQT测试和MR数据分析等发现的网络问题进行详细分析和分类，形成问题小区列表。2) TOP小区生成：在每日的指标监控中发现某些小区或者基站存在隐性故障，导致该小区或者基站出现性能下降现象时，应从该小区或基站的接入性能、保持性能、资源性能、覆盖性能入手进行相关的分析，找出综合指标最差的前N个小区，形成每日TOP N小区列表。（2） 问题小区处理1) 制定解决方案。通过对日常投诉、指标和告警监控以及MR等数据信息进行汇总分析, 对问题小区与TOP小区制定解决方案，以工单形式提交相关人员实施调整。需要时可以进行现场测试。2) 跟踪问题小区的处理。跟踪调整工单的执行进程和结果反馈，对已处理完成的小区观察其指标、告警信息的变化情况，需要时进行现场测试验证，确认问题解决情况。对于连续出现5日以上的TOPN小区要重点关注及早优先解决。3) 对问题小区分析中发现的网络干扰问题进行分析、排查和处理。对于无法处理的干扰，需及时提交分析报告给局方，由局方协调处理。（3） 周期性总结：每周、月对问题小区处理情况进行汇总总结，对于现阶段暂无法解决的问题应形成说明。（4） 输出结果1) 问题小区分析处理记录；2) 每周、月问题小区分析和处理总结报告。2.2 工具准备l Probe路测数据采集软件及Assistant后处理软件；l Nastar性能统计分析工具；l Insightsharp性能定位分析工具；l UMAT工具；2.3 信息收集l 网络配置数据l RNC的话统数据l RNC的CHR数据l RNC的告警信息l 日常DT/CQT数据2.4 操作步骤图1 问题小区处理流程图根据日常的投诉，性能监控，告警以及DT/CQT等数据，发现需要处理的问题小区，制定相应的调整方案，按照计划实施调整内容，实施完成后，确认调整效果，输出问题小区分析总结报告。2.4.1 关键/风险点1. 对于网络出现的外部干扰源，应由局方为主导，由其协调相关的资源，进行处理。2. 对于因规划等原因无法解决的问题小区，比如覆盖问题，容量，license等问题，需要提出解决建议，提交给客户。2.4.2 Timelines下面列出了1个问题小区的时间安排： Process：问题小区处理Weekly Progress任务名称任务描述Duration1st2nd3rd4th5thT1/问题小区筛选对日常投诉、指标和告警监控和DT、CQT测试和MR数据分析等发现的网络问题进行详细分析和分类，形成问题小区列表（包括TOP N小区）每天T2/制定解决方案 针对问题小区，制定解决方案1 个工作日T3/问题小区的处理根据调整方案，对问题小区进行处理.1个工作日T4/调整效果反馈和确认根据性能统计或现场测试，验证调整方案的有效性1个工作日T5/输出周问题小区分析表输出周问题小区分析表1个工作日2.4.3 Checklist表1 问题小区处理checklistTopN小区分析报告Check Date:Name:任务名称任务描述ItemCheck byT1/问题小区筛选对日常投诉、指标和告警监控和DT、CQT测试和MR数据分析等发现的网络问题进行详细分析和分类，形成问题小区列表（包括TOP N小区）日常投诉问题处理建议DT/CQT问题处理建议性能数据的分析告警问题小区的处理建议T2/制定解决方案针对问题小区，制定解决方案输出问题小区处理建议T3/问题小区的处理根据调整方案，对问题小区进行处理.执行调整方案T4/调整效果反馈和确认审核调整效果，评估调整结果.确认调整效果T5/输出周问题小区分析表输出周问题小区分析表输出周问题小区分析表T6/输出月问题小区分析总结报告输出月问题小区分析总结报告输出月问题小区分析总结报告3 问题小区筛选3.1 通过NASTAR生成每天各项指标的TOP 10小区。利用NASTAR生成KPI日报时，将Include TOPN Page选项勾选上，生成的KPI日报将附带各项指标的TOP 10小区。如下所示：NASTAR自动生成TOP 10小区的指标共包括12项，如下所示：指标名称指标名称CS Call Drop CellsPS RAB FAILPS Drop CellsSHO FAILHSDPA FAILInterFreq HHO FailHSUPA FAILCS InterRAT HHO FAILRRC FailPS InterRAT HHO FAILCS RAB FAILHot Traffic Cell3.2 利用insightsharp进行问题小区预过滤3.2.1 日志类型介绍当前常用CHR日志分析工具insightsharp进行问题小区分析。在利用insightsharp进行CHR日志分析时，需要对CHR日志先进行预过滤。每项不同的指标有不同的过滤方法。RAN12版本主要包括三类CHR日志。每类日志记录内容与作用如下所示：日志类型记录内容用于分析指标类型CHR记录切换失败信息软切换失败、硬切换失败、异系统切换失败CALL FAULT记录接入失败信息RRC接入失败、RAB建立失败、掉话UPCHR记录所有呼叫信息所有类型指标（偏向于RF分析）其中CHR和CALL FAULT日志主要记录CHR打点信息，UPCHR日志主要记录RF信息。从各类日志类型的记录内容可看出，CHR日志类型只能用于切析切换问题，CALL FAULT只能用于分析接入和掉话问题。3.2.2 预过滤功能介绍利用insightsharp软件的预过滤功能对日志文件进行预过滤，可避免因导入过多的日志文件而导致耗时长或软件卡住的现象。通过预过滤可提高问题小区处理效率。预过滤功能设置界面如下所示：3.2.3 各类指标预过滤方法对CHR日志和CALL FAULT日志进行预过滤，在软件中自定义过滤器时都选择SPU_Single_User_Log日志类型，利用该日志结构树中的FAULT TYPE对不同的KPI问题进行过滤。CHR MSG TYPE CHOICE STRU下的8类FAULT TYPE分别对应不同问题指标的详细选项。 SPU_Single_User_Log日志类型日志结构树如下所示： FAULT TYPE内容代表的问题指标如下所示：FAULT TYPE内容问题指标RRC CONNECTION REQ FAULT RRC连接失败RAB ASSIGNMENT REQ FAULT RAB建立失败SOFT HANDOVER FAULT 软切换失败HARD HANDOVER FAULT 硬切换失败 INTERRAT HO 3G2G FAULT 3G2g切换失败 DROP CALL FAULT 掉话CHR MSG TYPE CHOICE STRU下8类FAULT TYPE对应的问题指标：FAULT TYPE序号问题指标FAULT TYPE 1RRC接入失败FAULT TYPE 2RAB建立失败FAULT TYPE 3SHO失败FAULT TYPE 4HHO失败FAULT TYPE 5interRAT切换失败FAULT TYPE 6未知FAULT TYPE 7掉话FAULT TYPE 8未知3.2.4 指标过滤方法举例1、 RRC接入失败预过滤小区36473的RRC接入失败日志方法如下：选择FAULT TYPE字段填写RRC CONNECTION REQ FAULT ，选择FAULT TYPE 1下的BEST CELLID字段填写36473，如下图所示：2、 RAB建立失败预过滤小区36473下的RAB建立失败方法如下：选择FAULT TYPE字段填写填写RAB ASSIGNMENT REQ FAULT ，选择FAULT TYPE 2下的BEST CELLID字段填写36473，选择FAILED CS字段填写包含”CS”3、 异系统切换失败过滤小区31041、31044和31246三个小区的异系统异系统切换失败方法如下：选择FAULT TYPE字段填写填写INTERRAT HO 3G2G FAULT ，选择FAULT TYPE 5下的BEST CELLID字段填写31041、31044和31246（选择三次该字段）。如下所示：4、 掉话过滤过滤小区36473下的掉话方法如下：选择FAULT TYPE字段填写填写DROP CALL FAULT ，选择FAULT TYPE 7下的BEST CELLID字段填写36473。如下图所示：4 问题小区处理思路4.1 接入问题分析4.1.1 RRC建立失败1.上行 RACH 的问题2.下行FACH 功率配比问题3.小区重选参数问题4.下行专用初始发射功率偏低5.上行初始功控问题6.拥塞问题7.设备异常问题等造成RAB成功率低的原因有：1无线环境原因，需RF调整，或者推动工程建设；2小区资源拥塞：包括功率资源、码资源、CE资源、Iub口带宽，用户设备设置导致；3.上行干扰RTWP值异常；4.排查基站或传输硬件故障。从 RNC 侧来看，RRC 连接建立失败包括两种情形：一种是当 RNC 收到 UE 发送的 RRC Connection Request 消息后，向 UE 发送了 RRC Connection Reject 消息。这种情况对应着“因 Iub 接口失败而拒绝 RRC 连接请求”和“因网络拥塞而拒绝 RRC 连接请求”这两类指标。具体计数器打点位置如下图 A 点所示：另外一种是 RNC 下发 RRC CONNECTION SETUP 消息后，始终没有收到UE 的响应（RRC CONNECTION SETUP COMPLETE 或者 RRC CONNECTION SETUP FAILED）。这种情况对应着“因无应答而导致 RRC 连接失败”这类指标。导致 RRC 连接建立失败的常见原因如下：1、 因 Iub 接口失败而拒绝 RRC 连接请求因 Iub 接口失败而拒绝 RRC 连接请求可以细分为以下几类原因：RL 建立失败导致 RRC 连接建立拒绝RL 建立失败一般情况下较少出现，可能原因包括：l NodeB 设备硬件问题，如功放过热（偶尔出现）l NodeB CE 数受限。当 NodeB credits 估计不准，不能真实反映 NodeB CE 数的使用状况时，有可能出现 RNC 认为 NodeB 的 CE 数足够，向NodeB 下发 RL 建立消息，NodeB 由于 CE 数受限返回 RL 建立失败。发现 RL 建立失败导致 RRC 连接拒绝的次数不为零后，需要检查小区的负载情况，排除 CE数受限的可能；检查有无设备告警，排除空调、功放等问题引起的失败；AAL2 建立失败导致 RRC 连接建立拒绝AAL2 建立失败问题很少发生，当 AAL2 资源受限，或者小区出现故障的时候，才有可能出现。2、 因网络拥塞而拒绝 RRC 连接请求对于网络拥塞而导致 RRC 连接失败，需要检查是哪种资源不足导致的。其中无线资源的拥塞通常有如下几类：功率资源申请失败出现功率资源申请失败的时候，应该检查准入参数设置是否与默认参数一致。如果参数设置合理，则需要通过话务量、等效用户数等计数器检查当前网络负荷。如果网络负荷以及阻塞率确实达到扩容要求，则需要启动扩容。上/下行 CE 资源申请失败说明 NodeB CE 资源不足，需要结合当前实际话务负荷，检查 NodeB CE 资源配置情况。码资源申请失败说明码资源不足，需要结合实际的话务负荷给出合理的扩容手段。3、 因无应答而导致 RRC 连接失败造成这种问题的主要原因包括以下两种：UE 没有收到 RNC 下发的 RRC CONNECTION SETUP 消息造成这种问题的原因可能是覆盖或者小区选择与重选参数配置不合理。UE 发出了 RRC CONNECTION SETUP COMPLETE 消息，但是 RNC 没有收到可能是因为上行专用信道初始发射功率设置偏低。4、 因重定向而拒绝 RRC 连接请求nUE 发起 RRC 链接建立请求，如果小区拥塞或资源分配（主要指准入、码资源分配）失败，且 RRC 直接重试算法全部失败，则触发重定向算法。如果 UE 发起接入的主小区存在异频邻近小区或者 GSM 小区，则通过 RRC connection reject 信令的 Redirection info 信元指示 UE 重定向到异频邻近小区的频点或者 GSM 小区。如果不存在异频或 GSM 小区，则不配置 RRC connection reject 信令的 Redirection info 信元。4.1.2 RAB指配失败在 RNC 话统中，RAB 指配失败计数器打点位置如下图所示：如上图中 B 点所示，当 RNC 向 CN 发送失败的 RAB 指配响应 RAB ASSIGNMENT RESPONSE 消息时，根据具体失败原因，对相关计数器进行计数。图中 RB 建立过程使用虚线标出，为可选流程。RAB 指配建立失败的原因如下：1、 无线网络原因由于迁移导致 RAB 建立失败因迁移导致 RAB 建立失败是指：当 RNC 正在执行迁移，如果再收到来自 CN 的 RAB ASSIGNMENT REQUEST 消息，RNC 不会处理此消息，直接向 CN 应答 RAB 指配失败 RAB ASSIGNMENT REPONSE 消息（失败原因为Relocation Triggered。该指标一般出现机会较少，无需处理。由于空口失败导致 RAB 建立失败由于空口失败导致 RAB 建立失败是指：当 RNC 收到 UE 回的 RB Setup Failure 消息后，会给 CN 回 RAB Assignment Response，携带的原因为“Failure in the Radio Interface Procedure”。分析由于空口失败导致 RAB 建立失败，需要对 RB 建立失败原因进行分析，具体分析方法参见Error! Reference source not found.中 RB 建立失败相关内容。由于能力不足导致 RAB 建立失败小区中因能力不支持导致的 RAB 指配建立失败具体原因包括：l Requested Traffic Class not Available (18)l Requested Maximum Bit Rate not Available (20)l Requested Maximum Bit Rate for DL not Available (33)l Requested Maximum Bit Rate for UL not Available (34)l Requested Guaranteed Bit Rate not Available (21)l Requested Guaranteed Bit Rate for DL not Available (35)l Requested Guaranteed Bit Rate for UL not Available (36)l Requested Transfer Delay not Achievable (22)该指标一般出现在小区拥塞时，如 Requested Maximum Bit Rate not Available 等。需要注意的是，这个指标的触发原因包含了下面的几种“无线资源拥塞导致失败”指标的原因；l 功率不足导致 CS RAB 拒绝l 上行 CE 资源不足导致 CS RAB 拒绝l 下行 CE 资源不足导致 CS RAB 拒绝l 码资源不足导致 CS RAB 拒绝l IUB 带宽不够导致 CS RAB 拒绝可以通过查询相关指标，确定具体是什么资源不足导致失败，并作相应扩容处理。其他无线网络原因导致 RAB 建立失败除了上述原因外还有一些其他原因导致 CS RAB 指配建立失败，如 RB 建立无响应等。其他无线网络原因造成的 RAB 建立失败，一般来说无法从话统上直接获得原因，通常需要通过 DT 或者其他测试方法及分析手段定位。2、 传输网络原因CS 域因传输承载建立失败导致的 RAB 指配建立失败的具体原因包括：l Signalling Transport Resource Failure(65)l Iu Transport Connection Failed to Establish(66)该指标出现一般表示传输出现问题，需要检查 Iu 口的传输是否异常。4.2 切换问题分析4.2.1 软切换失败从流程上看，软切换可以分为软切换准备过程和软切换空口过程，其中准备过程是从切换判决到RL建立完成，空口过程是激活集更新过程：1、首先查看忙时全网和小区的软切换成功率是否达标，如果没有达标，则需要找到主要的问题小区进行详细分析。2、对小区的（更）软切换失败次数进行TOP N排序，找出几个失败次数最高的小区，并列出具体的失败原因指标，如果不能直接从话统上找到具体的失败原因，还要分析对应的CHR。下表列出了（更）软切换失败的详细话统指标和分析思路：失败原因分析思路配置不支持UE认为RNC增加/删除链路的激活集更新的内容不支持。这种场景在商用网络中基本不会出现同步重配置不支持UE反馈RNC增加/删除链路的更软/软切换过程与其他并发过程不兼容。RNC在流程处理的时候已经保证了串行处理，出现这种情况主要是一些手机自身处理出现问题非法配置UE认为RNC增加/删除链路的激活集更新的内容非法。这种场景在商用网络中基本不会出现UE无响应RNC没有收到增加/删除链路的激活集更新命令响应。这个在网络中是更软/软切换失败的主要原因，主要是发生在覆盖比较差或者切换区比较小的区域，需要RF优化4、进行路测重现问题。由于话统给出了趋势，并给出了可能的问题，具体问题的定位和分析还需要结合路测或者针对小区的CHR分析来进行。对于问题小区，一般都需要安排针对小区进行路测，跟踪手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。4.2.2 硬切换失败整个硬切换阶段失败，重点关注以下指标，包括NODEB内、NODEB间和RNC间的指标，下表同时给出了具体的分析思路。失败原因分析思路硬切换准备失败无线链路建立失败为RL建立过程中的失败，具体见IUB接口RL建立过程分析其他原因需结合CHR日志进行进一步的分析NODEB内/NODEB间/RNC间 硬切换出失败配置不支持UE认为硬切换出小区的命令不支持，一般为手机兼容性问题物理信道失败可能为覆盖较差或者干扰较严重同步重配置不支持UE反馈硬切换过程与其他并发过程不兼容，可能为手机自身兼容性问题小区更新在硬切换出小区的过程中，发生了小区更新，这种流程嵌套导致了硬切换出小区失败非法配置UE认为硬切换出小区的命令非法，一般为手机兼容性问题其他原因需结合CHR日志进行进一步的分析4.2.3 系统间切换失败1.UMTS服务小区上行链路质量较差2.事件2D、3A门限设置不合理,参数设置不合理3.当前UMTS小区邻区配置漏配GSM小区4.当前UMTS小区的GSM邻区配置过多5.目标GSM小区无可用无线资源、目标GSM小区干扰严重。1、 CS系统间切换失败CS系统间切换出过程分为切换准备过程和执行过程。切换出准备过程如下所示：在CS域系统间切换出过程中，当RNC向CN发送RELOCATION REQUIRED消息时，如果当前CS的业务为AMR语音业务，则统计为一次系统间切换准备。当RNC收到CN返回的IU RELEASE COMMAND消息时，按UE当前使用的SRNC的小区统计为系统间切换出成功。如果发生CS系统间失败，需要查看以下失败统计指标：失败原因分析思路RNC级异系统切换出准备失败等待迁移命令超时核心网没有返回切换准备请求的相应命令。这种情况往往是核心网参数配置或者相关链路连接有问题，需要根据核心网与BSS的信令跟踪进行原因分析迁移取消RNC请求切换准备后，收到核心网的释放命令。这种情况往往是两种情况，一是位置更新等信令过程发生系统间切换请求，流程还没有完成前已经完成了位置更新流程，核心网发起释放；二是建立呼叫的用户在切换准备时就挂机，核心网发起释放。这两种情况虽然切换没有完成，但都是正常的流程嵌套迁移超时一般对应着核心网配置错误，需要根据核心网与BSS的信令跟踪进行原因分析在目标CN/RNC或系统中迁移失败一般对应着核心网配置错误或者BSS系统不支持，需要根据核心网与BSS的信令跟踪进行原因分析未知目标RNC这种情况往往是MSC参数配置错误，没有配置目标小区的LAC等信息，需要核心网检查参数配置。这种情况在2G网络进行了调整后很容易出现无可用资源往往是MSC参数配置错误或者BSC无资源可用，需要根据核心网与BSS的信令跟踪进行原因分析其他原因需结合核心网与BSS的信令跟踪进行原因分析Cell级异系统切换出准备失败迁移超时这种情况往往是核心网参数配置或者相关链路连接有问题，需要根据核心网与BSS的信令跟踪进行原因分析在目标CN/RNC或系统中迁移失败一般对应着核心网配置错误或者BSS系统不支持，需要根据核心网与BSS的信令跟踪进行原因分析在目标CN/RNC或系统中迁移不支持这种情况往往是BSC不支持系统间切换请求的某些参数，需要根据核心网与BSS的信令跟踪进行原因分析其他原因需结合核心网与BSS的信令跟踪进行原因分析RNC/CELL级异系统切换出失败配置不支持网络中的切换命令终端不支持，一般是手机兼容性问题物理信道失败主要是2G信号比较弱或者干扰比较严重导致UE接入失败其他原因需要根据CHR日志及核心网与BSS的信令跟踪进行进一步的分析2、 PS系统间切换失败RNC发送CELL CHANGE ORDER FROM UTRAN消息后，如收到CELL CHANGE ORDER FROM UTRAN FAILURE消息，表明本次PS域系统间切换出过程失败，需要重点查看以下话统指标：失败原因分析思路RNC/CELL级PS异系统切换出准备失败配置不支持网络中的切换命令终端不支持，一般是手机兼容性问题物理信道失败主要是2G信号比较弱或者干扰比较严重导致UE接入失败无线网络层原因可能为手机兼容性问题，已知可能为手机终端检测到AUTN消息中的SQN的序列号错误，引起失败，原因值为：同步失败传输层原因对应着传输链路异常其他原因需要根据RNC的日志及核心网与BSS的信令跟踪进行进一步的分析4.3 掉话问题分析邻区漏配导频污染越区覆盖覆盖差基站或传输硬件故障干扰（包括内网及外网干扰）小区半径受限，上行无法同步小区负荷过高资源拥塞RAB强拆扰码复用距离不够23G切换参数设置不合理在话统分析中需要分析引起掉话的主要原因，主要指标如下：失败原因分析思路OM干预操作维护工作导致的掉话RAB抢占导致的原因高优先级抢占引起的CS链路释放，这种掉话在负载和资源不足的时候发生，根据发生的次数确定是否扩容UTRAN产生的原因小区中UTRAN产生的原因导致链路异常释放。这种情况一般对应着处理异常，需要通过CHR进一步分析上行RLC复位上行SRB复位引起链路释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况）下行RLC复位下行SRB复位引起链路释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况）上行同步失败上行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致UE异常关闭发射机或者上行解调失步下行同步失败下行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致UE异常关闭发射机或者上行解调失步UU口无响应UE空口无响应系统发出的命令，覆盖不好导致其他RF原因射频原因，均属于覆盖质量不好AAL2链路异常RNC发现IU CS接口AAL2 Path异常，发起了异常释放，可能为传输设备异常，已知问题有RB建立过程中马上正常释放被话统统计为该原因异常释放GTPU异常RNC发现IU PS接口GTPU异常，发起了异常释放，可能是设备故障其他原因异常原因掉话，需结合RNC日志进行分析另外，掉话中很大一部分原因是切换掉话，应着重进行切换指标优化，下边介绍常见导致掉话的非切换原因：1、 覆盖差一般来说，对于Voice而言，当CPICH的EcIo大于-14dB，RSCP大于-100dBm时（采用Scanner车外的测量值），不可能是由于覆盖不行导致的掉话。通常所说的覆盖差，主要是指RSCP很差。下表是规划时要求的Outdoor EcIo和Ec要求（来自某运营商的网络规划结果，供参考）：SERVICEBIT RATE OF SERVICEDL EBNOECIO THRESHOLDSEC THRESHOLDSCS 12.212.28.7-13.3-103.1CS 64645.9-11.9-97.8PS 64645.1-12.7-98.1PS 1281284.5-13.3-95.3PS 3843844.6-10.4-90.6上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RL failure，基本可以认为上行覆盖差导致的掉话；如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖差导致的掉话。在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。如果上下行严重不平衡，则应该初步判定为受限方向存在干扰。确认覆盖的问题简单直接的方式是直接观察Scanner采集的数据，若最好小区的RSCP和EcIo都很低，就可以认为是覆盖问题。由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差。扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。2、 干扰导致的掉话下行和上行的干扰都会导致掉话。一般情况下，对于下行，当激活集CPICH RSCP大于-85dBm，而激活集综合EcIo小于-13dB产生了掉话，基本上可以认为是下行干扰的问题（当切换不及时的时候，也可能出现服务小区RSCP信号很好，但EcIo很差；但此时监视集小区RSCP和EcIo都很好）；对于上行RTWP比正常值（-107-105）超过10dB，干扰时间超过23s，就有可能造成掉话，需要重点解决。下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现激活集替换或者最优小区发生变化，通常当激活集综合质量不好（CPICH的EcIo都在-10dB左右波动），容易出现切换失败导致SRB复位，也可能出现TRB复位。上行的干扰增加了连接模式的手机上行发射功率，从而产生过高的BLER导致SRB或者TRB复位或者由于失步导致掉话。另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，造成切换失败而导致掉话。上行干扰可能来自系统内，也可能来自系统外，绝大部分场景上行干扰来自系统外。通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射功率都会接近最大值。当下行干扰存在，往往出现上行发射功率很小或者BLER收敛的情况，但下行发射功率达到最大值同时也伴随着下行BLER不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。3、 异常分析在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。比如：NodeB异常引起同步失败，导致的链路不停增加和删除比如：手机不上报1a测量报告导致掉话4.4 干扰问题分析4.4.1 内部干扰定位定位步骤如下：1、 初步排查1、对于观察不到分集信号的要检查分集接收的配置情况未配置分集接收的典型的RTWP图如下所示：图1 RTWP跟踪图-分集未配置2、对于未做过上行射频通道校正的应检查射频通道的增益设置（尤其是有塔放情况下）是否正确，最好能够做一下上行射频通道校正以便于避免此类问题影响干扰定位的思路。上行射频通道校正方法：在待校正端口安装匹配负载，为避免功率过载，可以关闭相应的功放（SET TXSW: TXSW = OFF;），观察该通道RTWP值，如果RTWP在-105-106dBm左右属于正常，否则，可以通过设置对应的通道衰减值(SET RXATTEN: ATTEN=*;)调整RTWP至合理范围。上行射频通道校正非常规操作，现场如果有用服人员，应该由用服工程师操作。3、如果有DCS1800M系统跟WCDMA合路的情况，需要跟运营商确认其频率配置，检查其合路的DCS的频率的3阶互调（2f1-f2、2f2-f1）有没有落入WCDMA接收带内（1920M1980M），如果有，则需要跟运营商沟通交流，建议运营商将这种不合理的频率配置改掉。如果经过上面三步的初步排查后未解决干扰问题，需要到现场进一步处理。2、 现场排查1、启动NodeB的LMT，实时测量待定位小区的RTWP，以便于在采取后续的定位手段后实时观察待定位小区的RTWP变化情况。2、如果有DCS合路到WCDMA的，需要将DCS的载波特性查清楚（每个通道上有那些载波，是什么频点，BCCH在哪个通道上），并将BCCH的通道标出。这里，通道可以理解为实现每组无线信号在设备和天线之间传输的所需的天馈设备系统。3、如果有DCS合路到WCDMA的，根据干扰发现的结果，建议运营商配合将BCCH修改到需要定位干扰问题的通道。如果BCCH不在问题通道（GSM在两个通道上都可能会有信号发射，而BCCH只在其中一条上发射），那些与DCS话务相关的干扰很可能无法重现。4、在通道上逐个轻敲每一个射频连接器（重点是跳线接头、负载以及跳线和天线的连接头），查看RTWP的反应情况，如RTWP有相应的变化，变大或变小，则表示该连接器有问题，需要运营商工程相关人员配合进行接头紧固、重做等工程质量改进工作，请注意在进行工程工作前关闭掉相应小区的功放，以免造成辐射损伤。5、在确认连接器无问题，但存在干扰的情况下，使用YBT250滤波器定向天线在WCDMA天线处查一下是否能收到干扰（滤波器和定向天线器件要求，参考电磁干扰测试指导书，特殊情况下滤波器需要根据当地WCDMA接收频段和其它无线系统发射频段进行定制），如YBT250观察不到空间有干扰，则更换基站天线，确认是否是天线内部问题引起的干扰，如果更换天线后问题依然存在，转至“Error! Reference source not found.”环节。6、如果使用YBT250滤波器定向天线在WCDMA天线处收到了干扰信号，转“外部干