WCDMA RNP 专题指导书掉话问题分析
(仅供内部使用）
For internal use only
拟制: Prepared by URNP-SANA
日期：
Date
2004-10-25
审核: Reviewed by 日期：Date
审核: Reviewed by 日期：Date
批准: Granted by
日期：
Date
华为技术有限公司Huawei Technologies Co., Ltd.
版权所有侵权必究
All rights reserved
修订记录Revision record
目录
1概述 (8)
2掉话分类定义 (8)
2.1路测掉话定义 (8)
2.2话统指标 (8)
2.3工具中的定义 (11)
3掉话分析流程及方法 (11)
3.1常见掉话原因 (11)
3.1.1邻区漏配 (11)
3.1.2覆盖差 (12)
3.1.3切换导致的掉话 (12)
3.1.4干扰导致的掉话 (13)
3.1.5流程交互失败 (14)
3.1.6异常分析 (14)
3.2路测数据分析流程 (14)
3.3话统数据分析流程 (17)
3.4跟踪数据分析流程 (20)
3.5告警数据分析流程 (22)
3.6用户投诉分析流程 (22)
3.7调整措施 (24)
3.7.1工程参数 (24)
3.7.2小区参数 (24)
4典型掉话分析 (30)
4.1邻区漏配 (30)
4.1.1现象和分析 (30)
4.1.2解决方法 (31)
4.2覆盖太差 (31)
4.2.1现象和分析 (31)
4.2.2解决办法 (32)
4.3干扰过强 (32)
4.3.1导频污染 (32)
4.3.2上行干扰导致的掉话 (39)
4.4软切换掉话 (41)
4.4.1拐角效应 (41)
4.4.2针尖效应 (44)
4.4.3主导小区变化过快 (45)
4.5硬切换掉话 (46)
4.5.1压缩模式启动太迟 (46)
4.6系统间切换掉话 (46)
4.6.1邻区漏配导致掉话 (46)
4.6.2异系统邻区配置过多导致掉话 (47)
4.6.3LAC配置错误导致的掉话 (47)
4.6.4UE不报测量报告导致掉话 (48)
4.6.5切换不及时导致掉话 (49)
4.6.6物理信道重配置时发生最优小区变更导致掉话 (51)
4.6.7UE回切换失败导致掉话 (52)
4.6.8压缩模式启动太迟 (53)
4.7设备异常掉话 (53)
4.7.1NodeB上行同步导致的掉话 (53)
4.7.2手机问题 (54)
5网优各阶段关注点 (55)
5.1单站测试阶段 (55)
5.2优化前评估阶段 (55)
5.3RF优化阶段 (55)
5.4参数优化阶段 (55)
5.5网优项目验收阶段 (55)
6总结 (55)
7参考文档列表 (56)
表1 EcIo和Ec门限要求 (12)
表2 UU接口掉话相关定时器和计数器 (27)
表3 Iub接口掉话相关定时器和计数器 (29)
图目录List of Figures
图1 掉话分析流程图 (15)
图2 掉话分析判决树 (16)
图3 呼叫跟踪分析流程 (21)
图4 用户投诉处理流程 (23)
图5 掉话前的手机记录的活动集EcIo变化情况 (30)
图6 掉话前Scanner记录的活动集EcIo变化情况 (31)
图7 覆盖差信号分析 (32)
图8 育兴路附近导频污染 (33)
图9 育兴路附近best server (33)
图10 育兴路附近2th best server (34)
图11 育兴路附近3th best server (34)
图12 育兴路附近4th best server (35)
图13 育兴路导频污染构成 (35)
图14 育兴路附近的RSSI (36)
图15 育兴路附近BestServer小区的RSCP (36)
图16 育兴路附近270号小区的RSCP (37)
图17 优化后育兴路附近的导频污染 (37)
图18 优化后育兴路附近的best server (38)
图19 优化后育兴路附近的的best server小区的RSCP (38)
图20 优化后育兴路附近270号小区的RSCP (39)
图21 掉话前后Scanner测量的Ec/I0 ................................................................ 错误！未定义书签。图22 下行码发射功率...................................................................................... 错误！未定义书签。图23 掉话前的上行发射功率........................................................................... 错误！未定义书签。图24 拐角效应-信号变化情况. (42)
图25 拐角效应-手机记录的信号变化 (42)
图26 拐角效应-RNC记录的信令跟踪 (43)
图27 针尖效应-信号变化情况 (44)
图28 PS384K同频硬切换掉话分布 (45)
图29 cell52 vs cell88信号分布（切换区信号波动） (46)
WCDMA RNP 专题指导书掉话问题分析
关键词：掉话话统路测用户投诉
摘要：本文首先描述了常见的掉话，然后从路测数据、话统数据、RNC跟踪数据以及用户投诉等方面来描述掉话处理流程，最后结合实际掉话案例进行分析。
缩略语清单：
1 概述
本指导书综合了香港SUNDAY网络和UAE网络优化的经验。对CS掉话的定义、常见的分析方法和流程、解决办法进行了描述，在第四章结合实际的掉话例子给出了典型的掉话分析，最后描述了网优各阶段需要掉话内容。
第二章从空口消息、话统以及工具等方面给出了掉话的常见定义。
第三章首先分析了常见的掉话原因，然后结合路测、话统、跟踪、告警以及用户投诉等方面描述掉话流程，最后从工程参数和小区参数两方面给出了调整措施。
第四章是从邻区漏配、覆盖太差、干扰过强、软切换、硬切换、系统间切换以及设备异常等方面，结合消息、覆盖等方面给出实际的掉话例子分析和解决方法。
第五章结合网规的流程出发，描述各阶段掉话的关注点。
第六章对总结了不足和改进之处，以及将来需要进一步完善的地方。
PS掉话的内容将在PS掉话指导书中给出。
2 掉话分类定义
2.1 路测掉话定义
从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息，满足以下三个条件的任何一个：
1）收到任何的BCH消息（即系统消息）
2）收到RRC Release消息且释放的原因值为Not Normal
3）收到CC Disconnect，CC Release Complete，CC Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。
2.2 话统指标
1. 网元告警分析
参看相关小区的告警，检查这些告警是否会产生相应的掉话，如果存在这类告警，
试着消除和解决告警。
2. 突发事件关联
对大量站点出现的问题就需要考虑是否是由于突发事件造成；比如大型集会、恶
劣天气、误操作等都会对网络指标造成影响，根据各自的程度深浅，影响的范围
也有所区别。
3. 参数配置比较
检查问题小区无线参数的配置，与其它正常小区的无线参数配置是否一致，如果不一致则可改为一致，因为该小区可能是由于无线参数被误改而造成指标下降。
4. 指标关联
以上操作未有发现，可提取与之相关联的指标情况，往往从这些关联的指标中能发现问题原因。
5. 综合定位
排除了以上几个原因后，运用DT 数据、KPI 数据、RNC 信令分析等数据，综合分析指标问题，可以定位出绝大部分掉话小区的问题。
6. 后方专家支撑
在运用以上手段未定位掉话问题后，准备可获得的各方面掉话数据发回后方专家进行分析定位。
2.2.1 2.2.2
广义的掉话率应该包含CN 和UTRAN 的掉话率，由于网优重点关注与UTRAN 侧的掉话率指标，本文掉话率描述也重点关注UTRAN 侧的KPI 指标分析。
UTRAN 侧相关指标就是RNC 触发释放的各业务RAB 个数。主要包括两个方面：（1）业务建立成功后，RNC 向CN 发送RAB RELEASE REQUEST 消息。（2）业务建立成功后，RNC 向CN 发送IU RELEASE REQUEST 消息，其后收到CN 发送的IU RELEASE COMMAND 。目前这两种情况用一个指标统计：RNC_RAB_REL_TRIG_BY_RNC ，统计时可按具体业务分类统计。
同时话统还统计了RNC 触发释放各业务RAB 的原因。
掉话率计算：
从大的方面来讲，掉话分为两大类，信令面掉话和用户面掉话；从流程上看，信令面掉话是RNC 发起了Iu release request ，用户面掉话是RNC 主动发起RAB release request 。这两项指标是针对
%
*Success CSRABSetup iggedByRNC CSRabrelTr CDR CS 100_∑
∑=%
*Success PSRABSetup
iggedByRNC PSRabrelTr CDR PS 100_∑∑=
CS 和PS 分别统计的，根据IU 接口的话统统计项，定义信令面掉话如下：
用户面掉话可以直接通过RNC 掉话率和信令面掉话率相关指标运算得到。信令面和用户面掉话仅从信令角度区分。建议话统分析时重点关注整个掉话率，重点分析掉话的原因，目前有以下掉话原因统计项：
RNC_PS_RAB_REL_TRIG_BY_RNC_TRB_RESET RAB_CS_REL_RF_LOSS RAB_PS_REL_RF_LOSS
RNC_CS_RAB_REL_TRIG_BY_RNC_SRB_RESET RNC_PS_RAB_REL_TRIG_BY_RNC_SRB_RESET RNC_CS_RAB_REL_TRIG_BY_RNC_AAL2_LOSS RNC_PS_RAB_REL_TRIG_BY_RNC_GTPU_LOSS RAB_CS_REL_ABNORM_LOSS RAB_PS_REL_ABNORM_LOSS
其中出现最多的为SRB 、TRB 复位。 上述这些指标可以按照表格分类：
从上述分类看出，话统指标目前没有完全按照通常网络优化的掉话原因分类进行统计。
%
*ngSetup
CSSignalli active
lduetoUEin Signalling lbyUE Signalling l ng CSSignalli 100Re Re Re CDR Plane Signalling CS --=＝%*ngSetup PSSignalli nactive
elduetoUEi Signalling elbyUE Signalling el ng PSSignalli 100R R R CDR Plane Signalling PS --=
需要说明的是RAN话统掉话的定义只从Iu接口的角度进行统计，统计了RNC主动发起的RAB release请求次数和Iu release请求次数。而路测掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致的。比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上看，这次主叫是没有掉话指标记录的。所以两者的定义是不完全一致的，在分析时要注意区分。
2.3 工具中的定义
工具主要采集空口的消息，目前使用Actix的Analyzer和我司自己开发的Assistant都采用2.1节中空口的定义部分。
3 掉话分析流程及方法
3.1 常见掉话原因
3.1.1 邻区漏配
一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：
方法一：观察掉话前UE记录的活动集EcIo信息和Scanner记录的Best Server EcIo信息，如果UE记录的EcIo很差，而Scanner记录的Best Server EcIo很好；同时检查Scanner记录Best Server 扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中，如果测量控制的邻区列表中中没有扰码，那么可以确认是邻区漏配。
方法二：如果掉话后UE马上重新接入，如果UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。
方法三：有些UE会上报检测集（Detected Set ）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。
邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在3G掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。
3.1.2 覆盖差
一般来说，对于Voice而言，当CPICH的EcIo大于-14dB，RSCP大于-100dBm时（采用Scanner 的测量值），不可能是由于覆盖不行导致的掉话。通常所说的覆盖差，主要是指RSCP很差。下表是规划时要求的Outdoor EcIo和Ec要求（来自香港SUNDAY 网络规划）：
表1EcIo和Ec门限要求
上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：
如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RL failure，基本可以认为上行覆盖差导致的掉话；如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。如果上下行严重不平衡，则应该初步判定为受限方向存在干扰。
确认覆盖的问题简单直接的方式是直接观察Scanner采集的数据，若最好小区的RSCP和EcIo 都很低，就可以认为是覆盖问题。
由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差，扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。
3.1.3 切换导致的掉话
软切换/同频导致掉话主要有两类原因：切换来不及或者乒乓切换。
从信令流程上CS业务表现为手机收不到活动集更新命令（同频硬切换时为物理信道重配置），PS 业务也有可能收不到活动既更新命令，也有可能在切换之前先发生TRB复位。
从信号上看，切换来不及主要有以下现象：
1）拐角：源小区EcIo陡降，目标小区EcIo陡升（即突然出现就是很高的值）；
2）针尖：源小区EcIo快速下降后一段时间后上升，目标小区出现短时间的陡升。
从信令流程上看，一般在掉话前手机上报了邻区的1a或者1c测量报告，RNC也收到了测量报告，
并下发了活动集更新消息，但UE收不到活动集更新消息。
乒乓切换主要有以下两种现象：
1）主导小区变化快：2个或者多个小区交替成为主导小区，主导小区具有较好的RSCP和EcIo 每个小区成为主导小区的时间很短；
2）无主导小区：存在多个小区，RSCP正常而且相互之间差别不大，每个小区的EcIo都很差。
从信令流程上看，一般可以看到1个小区刚刚删除，然后马上要求加入，此时收不到RNC下发的活动集更新命令导致失败。
解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1a事件的切换参数使切换更容易发生，或者配置CIO使目标小区能够提前发生切换；解决乒乓切换带来的掉话问题，可以调整天线使覆盖区域形成主导小区，也可以配置1b事件的切换参数减少乒乓的发生等方法来进行。
对于异频切换和系统间切换，在切换前需要通过启动压缩模式来进行异频或者异系统测量，压缩模式启动太迟，可能导致手机来不及测量目标小区的信号，从而产生掉话，也可能手机完成了测量，但下发的异频或者异系统切换请求手机不能正常接收而导致掉话。
对于3G 2G系统间切换掉话的常见原因大概如下：
1. 邻区漏配置，可以通过配置邻区解决；
2. 信号变化太快导致掉话；
3. 手机问题，比如UE回切换失败或者UE没有上报异系统测量报告导致掉话等；
4. 物理信道重配置时发生最优小区发生变更导致掉话，需要产品算法进行优化；
5. 异系统小区配置过多导致掉话，可以通过优化邻区数目解决；
6. LAC区配置错误导致的掉话，可以通过数据配置检查解决。
3.1.4 干扰导致的掉话
下行和上行的干扰都会导致掉话。一般情况下，对于下行，当激活集CPICH RSCP大于-85dB，而激活集综合EcIo小于-13dB产生了掉话，基本上可以认为是下行干扰的问题（当切换不及时的时候，也可能出现服务小区RSCP信号很好，但EcIo很差；但此时监视集小区RSCP和EcIo都很好）；对于上行RTWP比正常值（-107~-105）超过10dB，干扰时间超过2~3s，就有可能造成掉话，需要重点解决。
下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现活动集替换或者最优小区发生变化，通常当活动集综合质量不好（CPICH的EcIo都在-10dB左右波动），容易出现切换失败导致SRB复位，也可能出现TRB复位。
上行的干扰增加了连接模式的手机上行发射功率，从而产生过高的BLER导致SRB或者TRB复
位或者由于失步导致掉话。另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。
通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射功率都会接近最大值。但当干扰存在时，如果是下行的干扰，往往出现上行发射功率很小或者BLER收敛的情况，但下行发射功率达到最大值同时也伴随着下行BLER不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。
3.1.5 流程交互失败
一些需要信令交互的流程，如AMR控制、DCCC以及压缩模式的启停、UE的状态迁移等，常常会由于信号的原因，手机支持方面的原因或者RAN设备和手机的配合问题，导致流程失败，最后导致掉话。还有一种特殊情况就是在流程的交互过程中，如RB建立，RB重配置等流程中，切换的测量报告不能及时处理，导致信号变差而掉话。
这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。
3.1.6 异常分析
在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。
比如：NodeB异常引起同步失败，导致的链路不停增加和删除
比如：手机不上报1a测量报告导致掉话
这里需要重点注意的是测试手机异常死机引起的掉话问题，一般在拨测过程中容易出现这个问题，具体表现为路测记录的数据中有一段时间没有手机上报的信息。
1 一些手机如MOTO A835会丢失掉话前的一些消息，可能导致后处理软件判断错误，发生这种情况的时候需要对比RNC记录的单用户跟踪来排除问题。
路测数据分析流程
掉话数据分析流程如下：
图1掉话分析流程图
图2掉话分析判决树
1. 准备数据
路测软件采集数据文件
RNC记录的单用户跟踪
RNC记录的CDL
2. 获取掉话位置
采用路测数据处理软件，比如Analyzer和获取掉话的时间和地点，获取掉话前后Scanner采集的导频数据，手机采集的活动集和监视集信息，信令流程等。
3. 分析Scanner主导小区变化情况
主要分析主导小区的变坏情况，如果主导小区相对稳定，进一步分析RSCP和EcIo情况；
如果主导小区变化频繁，需要区分主导小区变化快的情况，或者没有主导小区的情况，然后进一步进行乒乓切换掉话分析。
4. 分析Scanner主导小区信号RSCP和EcIo
观察Scanner最好小区RSCP，EcIo，根据不同的情况分别处理
4.1 RSCP差，EcIo差，可以确定为覆盖问题；
4.2 RSCP正常，EcIo差（排除切换来不及导致的，同频邻区干扰），可以确定为导频干扰问题；
4.3 RSCP正常，EcIo正常，如果UE活动集中小区与Scanner最好小区不一致，可能为邻区漏配或者切换来不及导致的掉话；如果UE活动集中小区与Scanner最好小区一致,可能为上行干扰或者异常掉话。
5. 路测重现问题
由于一次路测不一定能够采集到定位掉话问题需要的所有信息，此时需要通过进一步路测来收集数据。通过进一步的路测也能确认该掉话点是随机掉话的点或者固定掉话点，一般来说固定掉话点一定需要解决，而随机掉话点则需要根据掉话发生的概率来确定是否需要解决。
3.2 话统数据分析流程
分析话统指标时，要先看RNC掉话率指标和信令面掉话率指标，掌握了网络运行的整体情况。同时对关注的小区（小区集合）针对性地分析，按小区（小区集合）得到更详细的掉话指标。分析时可使用话统分析工具得到不同业务的掉话情况以及大致的掉话原因。
话统分析应获得指标明显异常的小区分析，如果小区以前KPI良好，此时很可能是版本、硬件、传输、天馈或者数据出了问题导致的异常，可以结合告警首先从这几个方面检查。如无明显异常，根据指标将各扇区载频进行统计分类，可整理出各重点指标较差小区列表，对于这些小区进一步细分话统指标（如分析更多相关指标，分析小时间间隔，分析可能引起掉话的指标，如切换指标等等），同时结合CDL看掉话的原因。实际分析解决问题时，在重点抓住某个指标分析的同时需要结合其他指标一起分析。需要说明的是话统只有在统计量较大时，指标数值才具有指导意义。例如，出现掉
话率为50%并不就代表网络差，只有在呼叫次数、呼叫成功次数、掉话总次数的绝对值都已具备统计意义时，这个数值才具有意义
话统分析流程可以简述如下：
1. 分析RNC掉话率和信令面掉话率
RNC掉话率统计RNC触发释放的各业务RAB个数，主要包括两个方面：（1）业务建立成功后，RNC向CN发送RAB RELEASE REQUEST消息。（2）业务建立成功后，RNC向CN发送IU RELEASE REQUEST消息，其后收到CN发送的IU RELEASE COMMAND。目前这两种情况用一个指标统计：RNC_RAB_REL_TRIG_BY_RNC。信令面掉话主要是RNC发起了Iu Release Request。分析IU口连接释放情况得到信令面掉话率。
2. 分析掉话原因
在话统分析中还分析引起掉话的主要原因，可分析以下主要指标：
RNC_PS_RAB_REL_TRIG_BY_RNC_TRB_RESET
RAB_CS_REL_RF_LOSS
RAB_PS_REL_RF_LOSS
RNC_CS_RAB_REL_TRIG_BY_RNC_SRB_RESET
RNC_PS_RAB_REL_TRIG_BY_RNC_SRB_RESET
RNC_CS_RAB_REL_TRIG_BY_RNC_AAL2_LOSS
RNC_PS_RAB_REL_TRIG_BY_RNC_GTPU_LOSS
RAB_CS_REL_ABNORM_LOSS
RAB_PS_REL_ABNORM_LOSS
可以将这些指标按照2.2节分类，将其分为空口原因（RF、流程超时）、非空口原因（硬件故障、传输故障、用户干预等），从而对网络有个总体把握，得到影响网络的主要因素。
3. 分析小区（小区集合）的掉话率指标
上述只是对整个网络分析，我们可分析小区掉话率指标，主要需要分析小区“AMR掉话率”、“VP掉话率”、“PS掉话率”、“硬切换掉话率”。对所有小区分别用以上的指标进行排序，选择指标特别差的小区或者最差的一些小区，进一步按照分析掉话原因。
AMR掉话率:
RNC_AMR_RAB_REL_CELL_TRIG_BY_RNC/
CS_RAB_SETUP__SUCC_AMR_CELL
VP掉话率：
RNC_CS_CONV_64K_RAB_REL_CELL_TRIG_BY_RNC/
CS_RAB_SETUP_SUCC_CONV_64K_CELL
PS掉话率：
RNC_PS_RAB_REL_CELL_TRIG_BY_RNC/
PS_RAB_SETUP_SUCC_CONV_64K_CELL
为分析不同速率的PS掉话情况，可分析指标
RNC_PS_384K_RAB_REL_CELL_TRIG_BY_RNC
RNC_PS_128K_RAB_REL_CELL_TRIG_BY_RNC
RNC_PS_64K_RAB_REL_CELL_TRIG_BY_RNC
切换掉话率情况：
HHO_INTERFEQ_DROP_OUT_CELL / HHO_INTERFEQ_OUT_CELL
HHO_INTERFEQ_DROP_IN_CELL / HHO_INTERFEQ_IN_CELL
HHO_INTRAFEQ_DROP_OUT_CELL/ HHO_INTRAFEQ_OUT_CELL
HHO_INTRAFEQ_DROP_IN_CELL/ HHO_INTRAFEQ_IN_CELL
通过上述这些掉话率的分析，我们可获得不同业务及其速率在网络中的性能，可获得软/硬切换掉话情况。重要的是通过这一步可获得指标较差的小区以及时间段。
分析掉话原因时，可分析下面的指标。按照2.2节分类，将其分为空口原因（RF、流程超时）、非空口原因（硬件故障、传输故障、用户干预等），从而对小区有个总体把握，得到影响网络的主要因素:
释放原因指标：
RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_OM
RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_UTRAN
RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_RAB_PREM
RNC_CS_RAB_REL_CELL_TRIG_BY_RNC_SRBRESET
RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_SRBRESET
RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_TRBRESET
RNC_CS_RAB_REL_CELL_TRIG_BY_RNC_AAL2LOSS
RNC_PS_RAB_REL_CELL_TRIG_BY_RNC_GTPULOSS
RNC_CS_RAB_REL_REQ_OM_CELL
RNC_CS_RAB_REL_REQ_UTRAN_CELL
RNC_CS_RAB_REL_REQ_RAB_PREM
RNC_PS_RAB_REL_REQ_OM_CELL
RNC_PS_RAB_REL_REQ_UTRAN_CELL
RNC_PS_RAB_REL_REQ_RAB_PREM
流程定时器超时指标：
流程定时器超时可重点分析以下流程(主要分析请求与CMP次数，已经相应超时次数统计指标)：RB_SETUP
RB_RECFG
ACTIVE_SET_UPDATE
PHY_CFG
RL Failure指标：
CELL_UPDT_RL_FAIL_CELL（下行失步）
IUB_RL_FAIL（上行失步）
RTWP，TCP指标：
RTWP均值、最大值
TCP均值、最大值
至于这些指标的具体含义可以参见RNC LMT联机帮助。
4. 检查小区是否异常
如果小区以前KPI正常，可检查小区的告警，排除小区异常方面的原因。具体参见告警分析指导书。
5. 分析掉话原因
设备问题：按照2、3如果分析结果是传输、设备原因，则可归类为设备问题。
覆盖差：按照2、3如果分析结果是空口原因，则可归类为覆盖差，无线环境变化块等原因。如果高速率的PS业务掉话率很高，而低速率与AMR较好，可知高速率覆盖不好。
切换导致的掉话：3中SHO、HHO相关指标导致的掉话。
干扰导致的掉话：分析RL Failure、RTWP，TCP相关指标，由于话统粒度粗，主要看整体情况，无法精确分析。
从话统详细分析掉话时，需按照掉话原因分类分析相关指标，必要时结合CDL分析。
6. 通过路测重现问题
由于话统给出了趋势，并给出了可能的问题，具体问题的定位和分析还需要结合路测或者针对小区的CDL分析来进行。对于问题小区，一般都需要安排针对小区进行路测，跟踪手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。
3.3 跟踪数据分析流程
跟踪数据分析包括单用户跟踪消息分析，通常情况下，单用户消息结合数据采集工具记录的UE 侧数据，能够基本上定位一些掉话问题；对于更加复杂的问题，需要配合CDL和实时状态监控来综合分析。
也有一些商用手机的问题或者重点用户的问题，没有手机侧记录的消息，需要通过从单用户跟踪数据来分析和定位。单用户跟踪除了记录单用户的信令消息（Iu，Iur，Iub，Uu），同时需要记
WCDMA掉话问题分析及处理方法 作者：南京格安 在国外，W CDMA已经在多个国家投入商用；在国内，WCDMA产品正逐步走向成熟，网络商用化的脚步正在加快。在网络建设及运营中，掉话率（calldroprate）是反映网络质量的重要指标之一；掉话问题也是日常网络优化面临的一个常见问题。本文从掉话的定义、掉话处理的基本流程、各种掉话数据分析方法、掉话问题的解决方法等方面加以研究，并结合实际掉话案例进行分析。 一、掉话的定义 1.路测的掉话定义 路测的掉话定义是：从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息满足以下3个条件的任何一个就视为路测掉话。 (1)收到任何的广播信道消息。 (2)收到无线资源释放的消息且释放的原因为非正常的。 (3)收到呼叫控制断连接、呼叫控制释放等消息，而且释放的原因为非正常的。 2.话统指标中的掉话定义 广义的掉话率应该包含CN和UTRAN的掉话率，由于网优重点关注与UTRAN侧的掉话率指标，本文掉话率描述也重点关注UTRAN侧的KPI指标。 从大的方面讲，掉话分为两大类，信令面掉话和用户面掉话。 需要说明的是：无线接入网话统掉话的定义只从Iu接口的角度进行统计，统计了RNC 主动发起的非正常资源释放的请求次数；路测的掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致。比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上
看，这次主叫是没有掉话指标记录的。所以两者的定义是不完全一致的，在分析时需加以区分。 二、掉话原因分析 由于掉话分析将涉及到具体的信令分析，因此本文参考华为设备的参数设置进行分析，而不同设备的参数定义并不一定相同，但是分析方法是相通的。 1.邻区漏配 一般来讲，掉话在初期优化过程中大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下方法来确认是否为同频邻区漏配。 方法一：观察掉话前UE记录的活动集EcIo信息和记录的BestServerEcIo信息。如果UE记录的EcIo很差，而记录的BestServer EcIo很好，同时检查记录Best Server EcIo 扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中。如果同频测量控制的邻区列表中没有扰码，那么可以确认是邻区漏配。 方法二：如果掉话后UE马上重新接入，UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制，进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。 方法三：有些UE会上报检测集（DetectedSet）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。 邻区漏配导致的掉话包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在3G网络掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。 2.覆盖差
TOP小区处理流程总结 1TOP小区处理流程及整体处理情况 1.1 TOP小区分解 TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等，针对这些KPI指标，可以通过分析、处理和解决影响这些指标的问题小区，提升和改善KPI指标。 1. 2 问题处理流程 TOP小区问题处理流程中，原因分析是流程中的关键点和重点。
2无线接通率TOP小区分析处理 无线接通率＝RRC建立成功率*RAB建立成功率，接通率需要从RRC建立成功率和RAB建立成功率两块进行分析。RRC建立成功率与业务类型没有关系，RAB建立成功率则与业务类相关，需要分PS业务/CS业务进行分析。每次RRC和RAB建立失败，话统都会输出一个失败原因统计。 2.1RRC建立失败处理
2.1.1RRC建立失败原因 RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。表3是RRC建立失败的对应原因打点。表4为RRC失败对应的原因分析。 表3：RRC失败原因打点 表4：RRC失败对应的原因分析
2.1.2RRC建立失败处理 1)拥塞 在RRC建立出现拥塞时，可以进行下面的操作： ?将主要业务的RRC建立在公共信道上，修改命令行为： ?主叫流媒类体RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGSTREAMCALLEST, SIGCHTYPE=FACH； ?主叫交互类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGINTERCALLEST, SIGCHTYPE=FACH； ?主叫背景类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGBKGCALLEST, SIGCHTYPE=FACH； ?终止流媒体类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=TERMSTREAMCALLEST, SIGCHTYPE=FACH； ?终止交互类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=TERMINTERCALLEST, SIGCHTYPE=FACH； ?终止流媒体类RRC建立在FACH上 RCESTCAUSE: RRCCAUSE=TERMBKGCALLEST, SIGCHTYPE=FACH； ?去附着信令承载建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=DETACHEST, SIGCHTYPE=FACH； ?注册登记承载在FACH上 SET RRCESTCAUSE: RRCCAUSE=REGISTEST, SIGCHTYPE=FACH； ?提高拥塞小区的最小接入电平，限制部分低电平用户的接入： 修改命令：MOD CELLSELRESEL: QRXLEVMIN=-96； ?打开LDC开关； ?对于业务量持续较大的小区，可以考虑建议扩容。 2)RL建立失败
M900/M1800 基站子系统故障处理手册目录 目录 第10章掉话类故障分析与处理...........................................................................................10-1 10.1 概述...............................................................................................................................10-1 10.1.1 掉话问题描述......................................................................................................10-1 10.1.2 掉话的计算公式..................................................................................................10-3 10.2 导致掉话的几种因素......................................................................................................10-4 10.2.1 覆盖引起的掉话..................................................................................................10-4 10.2.2 切换引起的掉话..................................................................................................10-6 10.2.3 干扰引起的掉话..................................................................................................10-8 10.2.4 天馈引起的掉话................................................................................................10-10 10.2.5 传输引起的掉话................................................................................................10-11 10.2.6 无线参数设置不合理.........................................................................................10-11 10.2.7 其它原因引起的掉话.........................................................................................10-12 10.3 典型案例......................................................................................................................10-13 10.3.1 优化切换参数减少掉话.....................................................................................10-13 10.3.2 直放站干扰引起掉话.........................................................................................10-13 10.3.3 MAIO相同引起干扰掉话...................................................................................10-15 10.3.4 上下行不平衡....................................................................................................10-15 10.3.5 孤岛效应引起掉话.............................................................................................10-16 10.3.6 与版本相关的参数设置.....................................................................................10-17
GSM网络优化中掉话、拥塞的原因及解决办法 1．掉话 在移动通信中，掉话是指在分配了话音信道（TCH）后，由于某种原因，使呼叫丢失或中断，正常通话无法进行的现象。掉话不仅影响网络指标，而且会给用户造成许多不便，是用户投诉的热点。 1.1掉话产生的原因 1、由干扰引起的掉话： 干扰主要包括同频、邻频及交调干扰。当手机在服务小区中收到很强的同频或邻频干扰信号时，会引起误码率恶化，使手机无法准确解调邻近小区的BSIC码或不能正确接收移动台测量报告。基站在通过SDCCH为手机分配好应使用的话音信道后,由于没有临近小区BSIC码而无法判断该使用哪个小区的话音信道，从而产生掉话。交调干扰主要来自于外部干扰，如CDMA站会对我基站上行频率产生干扰。 2、由于切换引起的掉话： （1） MS在通话中，手机列表中计算6个最好的相邻小区为切换做准备，但当网络覆盖不好时，会产生频繁切换，造成无主控小区，产生掉话。 （2）一些小区由于话务忙，会把话务推给相邻小区，但当相邻小区信号不好或无空闲信道时就会产生掉话。 （3）孤岛效应。如果服务小区A由于地形的原因产生的场强覆盖小岛C，而在小岛C周围又为小区B的覆盖范围，如在A的相邻小区列表中未添加小区B，那么当用户在C 中建立呼叫后一走出小岛C，由于无处可切换将产生掉话。 3、参数设置不合理引起的掉话： 影响掉话的参数主要有切换参数和相邻小区参数。如：PMRG设置过高或相邻小区参数做错都会导致掉话。 4、基站硬件引起的掉话： BTS的硬件故障也会引起掉话，NOKIA设备中的7745（CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD） 、7949 （DIFFERENCE IN RX LEVELS OF MAIN AND DIVERSITY ANTENNA / TRX）是特别要引起注意的，因为这些告警同时伴随着掉话。 5、Abis接口失败产生的掉话 Abis接口的，包括BSC未收到来自BTS的测量报告，超过TA极限，切换过程的一些信令失败以及一些内部原因，此外还有Abis接口的误码率的影响。 6、覆盖不好引起的掉话： 有些小区由于覆盖范围过大造成在小区覆盖的边缘地带信号不好，电平值很低，手机列表中测量的相邻小区的电平值又达不到接入的要求（如RXLEV ACCESS MIN＝－95dBm）而引起掉话，在边远地区、网络覆盖不好的情况下经常会出现这种掉话。 1.2 掉话的解决办法 如果一个小区掉话很高，可以先通过查掉话报告（如163报告），先确定是由于哪方面引起的掉话。 （1）对于由于切换引起的掉话的解决，可先进行大范围的路测，通过路测可以确定是和哪个相邻小区切换不正常。对于一些与该小区有切换关系而拥塞率又较高的小区应作为测试的重点，并需要检查小区周围是否有盲区存在，如果是这种原因应及时修改相关频率并
WCDMA 掉话问题分析 第一章掉话分类定义 第一节正常释放流程 一个CS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是0325，表示是call control 子层的disconnect消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是0325，表示是call control 子层的disconnect消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC，消息中naspdu是832d，表示是call control 子层的release消息。 4.RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nasmessage是832d，表示是call control子层的release消息。 5.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是032a，表示是call control 子层的release complete消息。 6. RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是032a，表示是call control 子层的release complete消息。
https://www.doczj.com/doc/ad16468714.html,发RANAP_IU_RELEASE_COMMAND消息给RNC，开始释放Iu口资源，包括RANAP 层和ALCAP层资源。 8. RNC发RANAP_IU_RELEASE_COMPLETE消息给RNC。 9.RNC发RRC_RRC_CONN_REL消息给UE，开始释放RRC连接。 10. UE发RRC_RRC_CONN_REL_CMP消息给RNC。 11.RNC发NBAP_RL_DEL_REQ消息给NODEB，开始释放Iub口资源，包括NBAP层和ALCAP 层，PHY层资源。 12. NODEB发NBAP_RL_DEL_RSP消息给RNC，整个释放过程结束。 一个PS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是0a46，表示是session management子层的deactivate PDP context request消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是0a46，表示是session management子层的deactivate PDP context request消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC，消息中naspdu是8a47，表示是session management子层的deactivate PDP context accept消息。 4. CN发RANAP_RAB_ASSIGNMENT_REQ消息给RNC，消息中给出要释放的RAB list，其中包含了要释放的RAB ID。 5. RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nasmessage是8a47，表示是session management子层的deactivate PDP context accept消息。 6. RNC发NBAP_RL_RECFG_PREP消息给NODEB。 7. NODEB发NBAP_RL_RECFG_READY消息给RNC， 8. RNC发RRC_RB_REL消息给UE，释放业务RB。 9. NODEB发NBAP_RL_RECFG_COMMIT消息给RNC，
高掉话小区处理流程建议 1. 背景 掉话率反映了系统话音业务的通讯保持能力，反映了系统的稳定性和可靠性，反映统计时间话音信道占用后因各种原因导致掉话严重程度，是无线通讯系统的重要性能指标，当系统的掉话率高时，会严重影响用户的感知，从而导致用户投诉或不满。此次我们主要针对TCH掉话的分析过程进行说明。 在NOKIA设备中，掉话次数count主要统计的是掉话出现在哪个接口，如：无线口、A_BIS口，A 口等等，并没有按掉话原因类型进行分类，如：信号质量差掉话或TA掉话等等，因此，在NOKIA设备中，应该按照掉话出现的接口进行分析。 2. 3J掉话率公式 (sum(a.tch_radio_fail+a.tch_rf_old_ho+a.tch_abis_fail_call+a.tch_abis_fail_old +a.tch_a_if_fail_call+a.tch_a_if_fail_old+a.tch_tr_fail+a.tch_tr_fail_old +a.tch_lapd_fail+a.tch_bts_fail+a.tch_user_act+a.tch_bcsu_reset +a.tch_netw_act+a.tch_act_fail_call)-sum(b.tch_re_est_assign))/ (sum(a.tch_norm_seiz)+sum(c.msc_i_sdcch_tch+c.bsc_i_sdcch_tch+c.cell_sdcch_tch)-sum(a.tc h_succ_seiz_for_dir_acc)+sum(a.tch_seiz_due_sdcch_con) -sum(b.tch_re_est_assign))*100% Counters from tables: A = p_nbsc_traffic B = p_nbsc_service C = p_nbsc_ho 上表就是NOKIA设备中，分为在各个接口的14类掉话。
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级参数 设置错误引起的掉话主要有以下几种：
VOLTE高掉话处理流程 1. 基站告警-主要指小区存在明显的站点告警，主要影响业务告警，包含硬件、停电、断站，射频单元驻波，IPPATH，S1故障等告警； 2. 隐形故障-主要指对问题点进行后台排查后，未发现明显故障，需上站检查相关硬件，计为隐性故障； 3. 传输故障-主要指小区存在传输链路断链，误码率过高,传输数据配置异常等问题； 4. 参数问题-主要指小区存在参数设置不合理、设置错误，参数漏配等； 5. 覆盖问题-主要指小区存在弱覆盖、覆盖过远或覆盖不合理等因素； 6. 内部干扰-主要指小区存在时隙配比不一致（要求同频点站点时隙配比一致）、GPS失锁、模三干扰、超远干扰； 7. 外部干扰-主要指小区存在阻塞干扰、杂散干扰、互调干扰、及其他外部干扰； 8. 邻区问题-新开站点邻区关系不全，不合理或未加任何邻区，影响UE小区选择或重选至不合理小区，从而影响掉线率。 9. 拥塞问题-主要指小区存在明显的资源不足，用户过多导致。 10. 核心网问题-主要指核心网数据定义不全、定义错误或网元合理化调整、功能验证等，导致指标恶化，计为核心网问题； 11. 终端问题-主要指对问题点通过后台排查和现场测试，排除为所有可能无线侧因素，结
合相关信令，确认为个别用户终端问题； 12. 突发异常-主要指某项指标在1-2个时段突然出现恶化，然后自行恢复正常，再排查完各种可能性原因后，未发现任何异常，计为突发异常。 2、E-RAB 掉线率(QCI=1/2)-高掉话TOP 小区分析流程 2、E-RAB掉线率(QCI=1/2)-高掉话TOP小区分析流程 1.查询掉线类定时器设置是否正确；（T310、N311、N310、T311、T301） 2.如掉线率突增，查询操作日志，确认是否有修改，导致小区异常； 1. 检查小区时隙配比是否设置准确（DE:SA2\SSP7;F:SA2\SSP5）； 2.如每PRB 上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型 1.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差； 2. 通过后台QCI=1/2误码率跟踪，如BLER>1%，确定小区存在高误码； 1.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖； 2.对比64QAM 和QPSK 占比，如后者比例远大于前者,可确定小区覆盖异常； 1.安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因； 2.如果确认问题后，转发相关人员处理，做好跟踪工作，直至问题闭环； 1.确定目标小区运行情况，是否基站故障或异常告警； 2. 检查邻区间参数设置是否正确； 3.通过Mapinfo 检查小区邻区配置是否合理，进行邻区合理性优化； 4.检查基站是否周边站点缺少，如为孤站，可视为正常； 1.通过LST ALMAF 查询站点实时告警,参考历史告警； 2.通过DSP BRD 查询单板运行情况； 是否存在弱覆盖 E-RAB 掉线率(QCI=1/2)高 掉话TOP 小区 服务小区是否存在异常告警或传输闪断，周边300米站点是否存在断站及告 警SRB 达到最大重传次数导致的激活的语音业务E-RAB 异常释放次数 切换流程失败导致的激活的语音业务E-RAB 异常释放 eNodeB 发起的原因为无线层问题的UE Context 释放次数 上行弱覆盖导致的激活的语音业务E-RAB 异常释放通过提取两两小区切换，确定目标小区 参数是否设置合理 是否存在高干扰 是否存在高质差 现场测试及后台跟踪 UE Reply 超时导致的激活的语音业务E-RAB 异常释放
山西煤炭运销集团 蒲县昊锦塬煤业有限公司异常情况处理制度为认真贯彻落实国家、省、市关于集中开展安全生产大检查的工作安排要求，加强我矿信息监控系统管理水平，做好矿井生产过程中井下环境参数的有效监控，保障矿井安全生产，加强煤矿安全生产管理水平及抗灾能力，特制定本矿异常情况处理制度如下： 一、值班人员按《中心岗位责任制》规定，浏览查询煤矿安全信息，发现异常情况及时处理，并认真填写《异常情况报告处理表》，传真至县监控中心。 二、监控室值班人员发现系统发出异常报警后，值班人员必须立即通知监控室主任、分管领导，同时立即通知矿井调度部门，由监控室主任或分管领导组织相关人员对本次异常报警进行原因分析，并按规定程序及时报上一级网络中心。处理结果应记录备案。调度值班人员接到报警、断电信息后，应立即向矿值班领导汇报，矿值班领导按规定指挥现场人员停止工作，断电时撤出人员。处理过程应记录备案。当系统显示井下某一区域瓦斯超限并有可能波及其他区域时，矿井有关人员应按瓦斯事故应急预案手动遥控切断瓦斯可能波及区域的电源。值班人员接到网络中心发出的报警处理指令后，要立即处理落实，并将处理结果向网络中心反馈。 当工作面瓦斯浓度达到报警浓度时，值班人员应立即通知矿值班领导及监控室主任，并填写异常情况处理报告表传真上报至
县监控中心
；由分管领导或监控室主任安排相关人员进行原因分析，按照瓦斯超限分析原则：①按人工检测值与甲烷传感器对比分析； ②按报警地点的历史曲线对比分析；③按报警地点上风侧检测值对比分析。根据分析结果立即将处理措施下达至矿调度中心按处理措施严格执行。报警期间要采取安全措施，报警消除后将报警的起止时间、分析报告、采取措施和处理结果上报县监控室并存档备案。 三、当煤矿通讯中断、无数据显示时，值班人员要通过传真（或电话）向县监控中心报告，并查明原因，恢复通讯。情况紧急的，由值班人员立即向矿领导汇报，对因故造成通讯中断未及时上报的，要通过电话联系移动公司或长途线务局进行抢修。
亳州GSM坏小区处理流程 1. 指标问题区分优先级别排查 1.1 指标监控一般分类 由于正常指标监控时间有限，需要利用有限的时间解决对网络质量影响程度更严重的、范围更广泛的指标问题，因此要将指标问题区分优先级别排查。 1）观察Net Indicator指标： 按指标重要性排序，分别为TCH、SD话务量增长情况、话务掉话比、TCH掉话率、TCH信道可用总数、TCH拥塞率（不含切换）、TCH分配失败率、SD拥塞率、切换成功率、TCH拥塞率（含切换）等指标，与近期相同时段相比，把握网络级指标变化情况。监控的宗旨是： 网络级容量指标稳中有升； 网络级质量相对稳定指标稳定； 2）观察BSC Indicator指标： 观察指标及观察方法具体如Net Indicator。监控的宗旨是，在Net Indicator指标变化的前提下，将指标变化范围定位到BSC级别。 网络容量指标如果发现为大多数BSC都增加的情况，那么多数都为节假日等公众行为所致，这类情况一般都能事前预测；如为部分BSC增加的情况，需要再进行Cell级别定位。 网络质量指标如果发现为大多数BSC都有恶化情况，多数情况为凌晨有网络级工程所致，例如核心网升版、核心网割接等工程，需要立即联系该工程所涉及硬件工程师；如为部分BSC恶化的情况，可以通过工程数据核查是否问题BSC属于某个或者某些特定的MSC，并了解交换侧工程情况，给予定位；如为个别BSC恶化的情况，需要再进行Cell级别定位。 3）观察Cell Indicator指标： 观察指标及观察方法具体如Net Indicator，监控的宗旨是，在BSC Indicator指标变化的前提下，将指标变化范围定位到Cell级别。但还需重点观察各小区TCH话务量、MC01/MC02比值及切换请求总次数等，这些指标可以发现是否有基站退服、吊死等故障情况。 网络容量指标通过涉及小区的数量及具体地理分布可以将变化情况定位到具体区域，多数原因可能是由于组织区域性活动等所致，这类问题需要局方尽量提前了解活动信息，优化工程师就活动信息提前调整网络配置或采用应急措施（例如：降低半速率占用门限、开启DR功能等）。 网络质量指标通过问题BSC下涉及小区数量可以将问题定位至BSC级问题还是
TOP小区处理流程 1TOP小区处理流程及整体处理情况 1.1 TOP小区分解 TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等，针对这些KPI指标，可以通过分析、处理和解决影响这些指标的问题小区，提升和改善KPI指标。 随着项目优化的深入开展，实行优化大区制，话统TOP小区也相应的落入大区进行分析和处理。TOP小区按问题类型进行分类处理，目前按23G互操作问题、产品性能问题、掉话类、接通率类、切换类等5大类进行分类，其中23G互操作问题由2G/3G团队处理，产品性能问题由产品性能研发处理，其余掉话类、接通类、切换类等落入大区进行处理。 1. 2 问题处理流程 TOP小区问题处理流程中，原因分析是流程中的关键点和重点，下面的章节中按问题类型进行分析和说明。
流程说明： 1)TOP小区输出，现阶段由机房在每天的KPI监控日报中一起输出，TOP小区处理团 队进行跟踪和处理； 2)每天跟踪TOP小区的KPI变化，刷新TOP小区问题跟踪表，更新处理情况和处理 内容； 3)完成调整的持续观察3－4天，如果话统恢复正常，关闭问题；仍未恢复的，转回 原因分析阶段，继续分析和处理；
4)每个问题建立案例，按照问题描述、原因分析和处理、指标变化、案例总结； 5)每天输出问题处理计划，外场测试必须输出测试报告； 6)每周输出TOP小区处理周报。 2无线接通率TOP小区分析处理 无线接通率＝RRC建立成功率*RAB建立成功率，接通率需要从RRC建立成功率和RAB 建立成功率两块进行分析。RRC建立成功率与业务类型没有关系，RAB建立成功率则与业务类相关，需要分PS业务/CS业务进行分析。每次RRC和RAB建立失败，话统都会输出一个失败原因统计。 2.1RRC建立失败处理 2.1.1RRC建立失败原因 RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。表3是RRC建立失败的对应原因打点。表4为RRC失败对应的原因分析。 表3：RRC失败原因打点 表4：RRC失败对应的原因分析
掉话类故障处理指导 掉话分类定义 在华为Probe侧对于掉话（ERAB Abnormal Release）的定义：UE没有收到Deactivate Eps Bearer Context Request消息，但收到RRC Release或RRC Connection Reconfiguration消息，则表示ERAB异常释放。 标口信令 在eNodeB跟踪到的标准接口信令中，如果存在eNodeB发起的释放，即在S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ消息内携带的原因值不为“User-inactivity (20)”时，则判断为掉话。 掉话预检查方式 异常掉话通常都是由eNB发起的释放，通知MME释放上下文，因此只要查看S1口发送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下图所示。 S1AP_UE_CONTEXT_REL_REQ 点击“标准接口消息类型”按消息类型进行排序，这样所有的S1AP_UE_CONTEXT_REL_REQ 都会排列在一起，如下图所示。 按消息类型排序 依次点击下一条，查看中的原因值，找出最后的原因为非02 80 的原因值。
找到异常掉话消息 根据对应的时间点，打开标准UU口的跟踪，找到对应时间点的RRC_CONN_REL消息，如下图所示。 找到对应的UU口消息 掉话率指标话统公式 在话统侧异常掉话指标的公式定义如下： Call Drop Rate = L.E-RAB.AbnormRel / (L.E-RAB.AbnormRel + L.E-RAB.NormRel) 等同于： Call Drop Rate = L.E-RAB.AbnormRel.QCI.N / （L.E-RAB.AbnormRel.QCI.N +
TCH掉话处理流程 TCH掉话是影响用户感知度的重要指标之一。我们按其原因将其归为以下几类，对每种类型的掉话做了简要说明并给出了优化建议： 1系统原因掉话（MC14C） 因为系统的一些操作或者故障引起的掉话，如修改频率、RESET 载频和BTS、载频和基站闪断的等，判断的根据就是观察小区的告警和操作记录。 这类掉话处理建议： ●操作时，建议使用Shut Down来Lock小区； ●对于闪断故障需及时LOCK，并进行更换、处理； ●频率修改尽量选在非忙时进行。 传输闪断引起系统掉话的案例： 察看XAD140_1的话务报告，在某一时段出现大量的系统掉话，同时不可用信道数为3，我们怀疑载频闪断引起大量的系统原因掉话。 在OMC-R察看该小区的告警，在出现系统掉话的时段，一直反复出现LOSS OF TCH和LOSS OF SDCCH的告警，并且二路传输存在告警。所以我们判断，二路传输闪断，引起在RSL闪断，进而引起信道丢失的告警，产生系统原因掉话。 这种系统掉话就是由于传输闪断引起的，应尽快处理传输问题。 2传输掉话（MC739） 导致传输掉话的原因有以下几种情况：
●A口故障，可结合018报告，来判断具体为哪一路出现故障，及时LOCK 有问题的时隙或者PCM链路，并处理故障； ●ABIS故障，可以通过ABIS告警来发现，需及时处理故障，控制传输掉 话； ●TC故障，可以通过TC告警来发现，需及时处理故障； ●载频故障，可以先 reset相关载频，无效后更换载频。 传输误码引起的传输掉话案例： 从话务报告来看，XAM794_0存在多载频的传输掉话，我们怀疑ABIS口或者A口出现问题。 查看ABIS告警：我们发现在传输掉话所处时段，ABIS口存在BER-10E-3的告警，所以断定此告警导致小区的传输掉话。 当对传输链路进行故障处理之后，告警清除，传输掉话消失。 3无线掉话（MC736） 当RADIO LINK TIMEOUT（无线链路超时计时器）减为0 时，信道被释放从而引起的掉话记为无线掉话，在网络运行中此类型掉话最为常见，其产生原因有以下几种：
分析检验及异常处理快速反应流程 为使化工产品质检一室分析检验过程运行畅通，明确生产管理人员职责，确保原料、中控（馏出口）、半成品（中间产品）、产品质量受控和检验过程受控，及时传输生产过程信息，积极、主动、有效、快速为生产服务，特制定本快速反应流程。 一、生产管理网络 二、职责划分 1、生产组组长：负责生产组的日常全面工作。对生产、质量各种报表进行审核。 2、生产管理技术员：负责LIMS系统数据维护等管理工作；协助做好一室生产、质量管理系统体系建设工作；参与组织编制质量检验技术方案；负责协调与其它专业部门之间的质量业务工作关系；根据质量
统计法规和上级制定产品统计标准及各项制度与规定，并拟定具体实施细则和管理规定；负责编制质量信息管理制度及质量信息报告、报表，工作程序并组织实施；负责产品质量计划完成情况考核；收集对比同行业产品质量数据，建立台帐；负责LIMS系统数据的录入审核工作。 3、化验质量管理技术员（1）：负责本岗位的各项日常工作；负责原材料、中间产品、成品质量统计工作，并对质量统计进行分析；编制印发质量日报、周报、月报、季报、与年报；负责收集、整理、汇总全厂产品质量信息，建立质量信息网络。 4、化验质量管理技术员（2）：负责本单位盲标样的管理；负责各班组原始记录差错率的统计和汇总工作；负责原材料进货的质量验收把关工作；负责标准溶液管理工作；负责仪器管理维护、计量器具检验校准等的协调工作；负责QC工作。 5、化验质量管理技术员（3）：负责质量分析检验、样品保存，组织编制质量检验技术方案；负责协调与其它专业部门之间的质量业务工作关系；负责监督分析检验过程中各种标准的执行情况；负责分析检验过程的质量把关、审核工作。 6、专区技术员：负责本专区生产装置与质检工作有关日常工作的协调，负责本专区的分析计划和检验规程的执行情况，及时解决分析过程中的各种问题以及分析仪器的日常维护和校验，负责本专区体系建设工作、安全环保工作的督促、检查。负责专区班组分析计划执行率、分析数据差错率和准确率、LIMS数据输入准确率的统计工作。
产线异常处理流程及技巧 一．品管人员问题处理之流程(步骤) 发现问题分析问题解决问题预防问题 备注: 品管人员之所以不同于工程人员处理问题之关键在于品管人员用品管技能, 品管统计手法,逻辑推理等方法来进行问题的分析与处理、 A.发现问题 ●不良现象(必须了解清楚及正确之数据) 发生日期,不良数﹑投产数﹑不良率﹑不良发生点﹑不良状况(不良状况就是怎样产生的), 亦即何种测试条件下之测试不良,具体详细之不良情形、相关的信息,在我们处理问题前, 必须清楚无误地掌握到、 Case1: 1.4/27,产线发现PUH不良,不良率5%、 2.产线Loader test站,发现较多托盘进出过缓,分析为托盘不良、 3.贵司4/7来料之3374365191之碟盖,批量1000pcs,在我司检验时发现表面有严重刮伤 之不良现象,不良率2、5%、 4.贵司4/22来料之1232001520陶瓷(1500Pf +/-10%) 450k,在我司检验时发现本体上 上有两种文字印刷,见图、 B.分析问题 此项来讲﹐为SQE处理问题之关键﹕怎样判定此部分之不良就是原材料造成还就是产线制程造成﹖基本上我们应能通过种种的品管手法及逻辑推理手段中作出进一步的判定, 当然, 从某种程度来瞧, 其效果有时并不一定如理想中的那么直接, 但从另一方面讲﹐对我们来处理产线问题绝对就是有益的﹐现例﹕当产线发生不良,并初步怀疑为组件不良所致, SQE该如何处治? 通过何种方式去剖析并解决问题、 ●不良现象与组件之关联, 其相关关系如何? 找出组件不良之相关与机台不良之相关联系参数、如其中的某个参数, 规格, 外观等不良, 就是否对产品(机台)有直接的影响?以往历史中就是否有类似之不良? 在分析问题前,我们必须展开相关的联想并设问、 ●不良之确认 分析前, 我们应该对所产生的现象作进一步的确认, 确认所产生的现象, 确实为不良, 否则, 以下相关之工作将只能就是徒劳、 *不良之现象,就是否确实为不良(超出规格之要求)、 *就是否确实为组件fail、
掉话处理案例总结 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】
路测掉话的原因分析及解决 1. 关于掉话的描述 在 GSM 系统中掉话从统计角度讲分为两大类：RF_LOSS 和 HO_LOSS 即射频掉话和切换掉话。考虑到2层信令的接续等问题，我们把掉话作如下描述。 1) 射频掉话 ●下行原因：Radio_link_timeout 计数器减至 0 ●上行原因：BSS 在 link_fail 的设定时间内未能接收到 UL SACCH 消息，使link_fail 计数器减至 0。BSS 下行功率停止发射 ●在 Layer 2 上： BSS/MS 每 T200 时间发送 N200＋1 次 SABM/DISC 消息，但未从接收端收到回应 2) 切换掉话 ●MS 未能成功切换至目标小区, 但未能回到源小区 ●MS 发送 HO FAILURE 和 UL-SABM 消息给源小区，但未得到回应 2. 在路测时发现的掉话问题时,我们应从哪些方面进行考虑 在路测中，如果我们发现了掉话，我们应该如何入手建议根据不同的现象作出一些初步的判断，可以尽量减少不必要的周折，提高工作效率。归纳起来初步判断有以下几点： ●带内、外干扰 ●无可切换的小区（拥塞、无邻区）
●覆盖问题（overshooting/poor coverage） ●有线口的信道释放 ●基站硬件故障（时钟、CTU 低功、信道盘的收发功率不平） ●天线错误（下倾角、方位角等错误） ●由于切换失败造成的掉话 ●参数设置不当 ●其它特殊原因（手机问题、交换机参数设置问题） 3. 对掉话现象进行分析以及可能的原因 在这一节中我们对每种造成掉话的可能原因进行具体的研究。在每一种原因中，我们尽可能的举出实际例子来进行说明。 1) 频率干扰 干扰会导致误码率升高，通信质量下降，是造成掉话的一个重要的原因。干扰可以分为带内干扰和带外干扰，也可以叫做系统内部干扰和系统外部干扰。 带外干扰：随着科技的进步，空中的无线电波越来越多，有些系统如 TCS 系统与 GSM 系统工作在同一频段，如果频率设置不当，会造成严重的频率干扰。在发射设备的非线性单元由于载波与通过天线进入的干扰信号产生互调干扰，会引起通话质量下降，产生掉话。另外一种情况就是人为的加建 GSM 频段的直放站，对功率以及天线方向不进行控制，对系统会造成上下行的干扰。一般有这
质差小区处理方案 一.影响质量差的因素 (1) 二.收集数据 (2) 2.1.小区级统计 (2) 2.2.TRX级统计 (2) 2.3.当前/历史告警信息和小区跳频情况 (2) 三.硬件排查 (3) 四.干扰排查 (3) 五.参数排查 (3) 六.频率排查 (3) 七.工程排查 (4) 一. 影响质量差的因素 根据以往的优化经验，对质量差问题进行了相应的总结，影响质量差的主要因素有： 硬件故障 传输问题 参数设置问题 网内外干扰 覆盖问题 天馈问题 上下行不平衡 直放站问题 根据对质差小区性能数据的分析，可按照质差小区原因分为以下几类：强干扰、负荷相关干扰、硬件故障、弱覆盖。 质差小区分类标准如下：
二. 收集数据 2.1.小区级统计 通过OMC统计收集小区级统计信息，重点查看： ◆TCH掉话率（3j）：是否有突然变化。 ◆TCH/SD可用信道数：是否有突然变化。 ◆TCH/SD话务量：是否有突然变化。 ◆TCH切入/切出成功率：是否有突然变化。 若有突然变化，记录发生突变的时间点和变化幅度。 2.2.TRX级统计 通过OMC统计收集TRX级统计信息，再结合上述小区级KPI突然变前后时间点收集其它几天的TRX级统计信息，重点查看： ◆各个TRX的上行质量0-5级比率：若低于95%,则表明此TRX的上行质量较差， 作好标记。 ◆各个TRX的下行质量0-5级比率：若低于95%,则表明此TRX的下行质量较差， 作好标记。 ◆各个TRX的上下行取测量报告数：若低于100次，此TRX统计暂时不做参考。 ◆各个TRX的上行平均电平：若城区基站低于-94dBm（郊区基站低于-98dBm）我 们认为TRX的上行电平较差，作好标记。 ◆各个TRX的下行平均电平：若城区基站低于-90dBm（郊区基站低于-96dBm）我 们认为TRX的下行电平较差，作好标记。 ◆各个TRX的上下行路径损耗：若高于15或者低于-10,我们认为TRX的上下行 路径损耗不平衡，作好标记。 检查上述TRX级KPI，记录下性能异常的TRX，判断为单TRX故障还是多TRX性能异常。 2.3.当前/历史告警信息和小区跳频情况 用ZEOL命令查看当前告警，同时用ZEOH命令检查前三天的历史告警，重点看如下信息： ◆7745告警：有无单TRX和或者多个TRX的告警。 ◆7607告警：有无单TRX和或者多个TRX的告警。 ◆7744告警：有无单TRX和或者多个TRX的告警。