高掉话小区处理流程
掉话处理流程
1 TCH掉话高处理TCH掉话的处理过程比较复杂，监控人员自身需要对日常监控中的掉话处理不断总结，以提高处理TCH高掉话的水平。
下面为各类掉话的参考处理方式。
1.1 TR掉话高TR掉话高可通过以下方式处理：可通过ZAHP查看相关载频进行复位如复位载频无效，可通过重建载频数据观察如复位载频和重建数据均无效，确定是否为载频故障或传输配置数据有误如果TR掉话在BSC内部分布比较均匀，可能为TC板或BSC级其它单元故障（如2992、2993告警），向网运中心反映。
1.2 LAPD掉话高LAPD掉话高可通过以下方式处理：查看告警确定是否为载频退服导致，并查看相关原因，如需要更换载频或做基站硬件处理，与网管中心沟通ZYMO查看是否存在传输误码导致传输闪断确定基站是否出现过断电原因造成的退服告警号如7705、1583等1.3 A口掉话高A口掉话可通过以下方式处理：如果A口掉话均匀分布在BSC内所有小区上，A口电路存在故障，向网优中心反映A口掉话一般都是由于跨MSC的切换引起，可检查相关切换指标和切换参数以及目标小区的工作是否正常。
1.4 BTS以及OTHER掉话高BTS掉话一般在基站告警上有所体现，基本由于基站硬件故障导致，需要与网管中心沟通USER掉话由于重启基站导致，不做处理1.5 ABIS掉话高ABIS掉话高可通过以下方式处理：1、查看告警是否相关载频存在7745告警，可通过复位载频观察。
如复位载频后，7745高告警仍然存在，仍然存在高掉话，可尝试锁住载频观察掉话情况，在确定由于某载频故障导致ABIS高掉话后，向RNP发送工单要求更换。
2、是否存在严重的同邻频干扰3、ZERO查看是否小区存在严重上行干扰，干扰处理参考如下：如由于突发的干扰器开通，监控人员需要跟踪干扰是否一直存在，如一直存在干扰，需要向相关RNP反馈确定该小区是否下挂有直放站，如下挂有直放站，并且干扰一直存在，向RNP发送工单进行直放站的相关硬件排查查看是否存在与天馈相关的告警，如7949告警等，如由于天馈原因，发单要求RNP进行天馈系统检查如产生干扰的原因不明，并且ABIS掉话很高，可向RNP发单要求进行现场扫频、基站硬件检查、天馈系统检查等备注：由于7745告警原因复位载频时，有时重启BTS和重启载频效果不一样，可能重启BTS不能恢复，但重启载频却恢复正常，建议在锁住BTS后，对问题载频进行一次解锁操作后，再解锁BTS。
GSM网络高掉话小区的治理方案
某市 的移 动通信 网络采 用爱立 信 ＧＳ ０ Ｍ９ ０设备 ，在话 务统计 中， 们发现 该市 的小 区掉 话原 因主要 有 以下几种 ： 我 弱信号掉话 、 质差掉 话、 Ａ超限 的掉 话 、 Ｔ 突然掉 话等 。 以上 是 Ｂ Ｃ（ ａｅＳ ｔ ｎＣ ｎ ｏｌ ） Ｓ Ｂ ｓ ｔ ｉ ｏ ｔ ｌ ｒ掉话计 数指令 统计 的掉话原 ａｏ ｒ ｅ 因【 实际上可 由基 站硬件 故障 、 ｌ 】 ， 外源信 号干扰 、 内部信 道 同 频、 邻频 干扰 、 切换 问题 、 覆盖 问题 等 多种 原 因引起 ， 面结 下
有 问题 的载 频 用 Ｔ ＭＳ进 行 测 试 来 发 现 故 障 点 。 Ｅ 天 馈 线 系 统 出 现 故 障会 引 起 驻 波 比 过 高 ， 是 产 生 掉 话 这
对 网络 质量影 响比较 大 ， 应尽快排 除 。 （） ２ 系统 内部干扰对掉 话的影响 系统 内部 干扰主要指 同频干扰 和邻 频干扰 。 好的无线环 境是 降低掉 话率 的主 要因素 。 频率规 划对于移动通 信系统来 说相 当重要 ， 建议采用 Ｂ Ｃ Ｃ Ｈ与 Ｔ Ｈ分段 的规划方法 。如： Ｃ １ ８频 点 用 于 微 蜂 窝 ， ｏ ． ４用 于 Ｔ Ｈ，６ ９ — １＿ ７ Ｃ ７ — ４用 于
络 对 移 动 Ｇ Ｍ 小 号 频 率 干 扰 不 容 忽 视 。一 般 来 说 外 部 干 扰 Ｓ
２ １ 硬件故 障引起 的掉 话 ．
硬件 故障产生 的掉 话往往集 中于一个小 区， 且掉 话次数
较 多， 同时其 他网络指标 也会 受到影 响。对硬 件原 因产 生的 掉话 ，可通 过终端 查看相 关硬 件告警 。如 果无硬 件告警 信 息， 则可能 是 Ｔ ＲＵ的 隐性 故障闭， 时可 以通 过 Ａ Ｉ 令 此 Ｂ Ｓ信 跟踪 发现故 障载频 ， 也可 以关 闭该小 区 的其他载 频 ， 对怀 疑
VoLTE高掉线差小区处理案例
VoLTE高掉线差小区处理案例发布时间：2022-04-24T12:58:16.730Z 来源：《中国建设信息化》2022年1期作者：蒋馥珍李磊李海娣[导读] LTE网络相对以前3G的使用感知有较大提升，其中采取了关键技术之一就是V oLTE技术蒋馥珍李磊李海娣中国联合网络通信有限公司潍坊市分公司一、摘要LTE网络相对以前3G的使用感知有较大提升，其中采取了关键技术之一就是V oLTE技术，目前5G语音解决方案VONR还不成熟，仍需VOLTE打底。
V oLTE语音相对之前语音方案具有接通快，通话音质更清晰，保持性好等优点，但V oLTE掉话对用户使用语音感知影响较大。
V oLTE掉话主要有：覆盖问题、干扰问题、切换问题、邻区问题、参数配置问题以及终端设备问题。
日常优化并减少掉话可以提高语音感知，提升用户使用感知。
二、关键词V oLTE、掉话、电联共享、冗余邻区外部三、案例正文（一）案例背景根据集团考核标准，例行周级统计质差发现昌乐宝城西崔区域9个小区突发高掉话，查询小区其他无线侧KPI正常，无干扰，无告警；查询周边站点传输侧业务也无异常，查询掉话原因值发现小区因传输层问题导致的语音业务异常释放占比较高，无线侧未发现异常，需进一步分析。
（二）案例描述1、无线侧指标查询：后台网管核查该站点无异常告警和干扰告警，用户数占用正常，小区无线侧指标，负荷情况均正常，小区WFCL0237-HW-F1HD02-(北局-宝城西崔)-B1 的最大用户数、同频切换成功率、RRC连接成功率、ERAB建立成功率、掉话率、无线接通率、系统每PRB接收的干扰噪声平均值、上行PRB平均利用率、下行PRB平均利用率、平均TA（米）分别为：64、99.96%、99.98%、99.97%、0.04%、99.96%、-112.14、9.67、13.37、1105.99。
2、掉话失败原因值定位：提取周边小区QCI1掉话原因值发现，小区因传输层问题导致的语音业务异常释放占比较高。
掉话原因及处理
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接口的误码率的影响。
OMCR组日常工作流程
OMCR系统组工作流程由近期NOSS指标来看，掉话坏小区、切换成功率等指标均处于良好的水平，OMCR组下阶段工作主要围绕集团公司巡检及拥塞坏小区、干扰小区及新建站3个重点来展开。
●总负责人：胡渊●OMCR组：刘畅、李元琛、张开奥、赵留栓、王峰、刑灵均、敖猛、赵磊一拥塞坏小区处理流程责任人：王峰、李元琛、刑灵均、敖猛、刘畅目标：意味每天的拥塞坏小区必须做到7个以下,按照目前的网络实际状况来看,有难度,且晚忙时往往不可控;现网能控制到拥塞小区处理方法:1空闲＆接入状态时的参数设置抬高RxLev_Access_Min来提高对小区接入的要求以平衡话务量。
一般建议在一些基站密度较高、无线覆盖较好的地区调整RXLEV_ACCESS_MIN来均衡小区的业务量.增加切入拥塞小区的HO Margin来提高切入要求，减少服务小区的话务流入.减小切出拥塞小区的HO Margin,以利于切出，让服务小区的话务分流到小区.RACH_TA_Filter一般都是64,可以适当限制,把那些过覆盖的试呼滤除,可以起到适当减少话务负荷的作用。
.建议值: 根据网络实际情况调整通过调整CRO、PT来改变小区重选，鼓励移动台尽量重选到话务量较低的小区。
建议值：超忙小区的PT设成inactivity,则C2=C1-CRO, CRO越大，则本小区C2越低,更易重选到话务负荷不大的邻区.也就是说用提高CRO的值来加强移动台对邻小区的倾向性，CRO越大，对邻小区倾向越大。
2 开启半速率信道采用半速率小区的无线资源分配方式与服务小区的话务负荷有关。
用来表示小区话务负荷的变量为LOAD_SV1，LOAD_SV1的值将决定是否把半速率话音信道分配给MS，调节半速率的门限值以使半速率小区优先占用半速率信道，尽量减少突发性的拥塞情况.OMCR缺省值为70%,90%,建议值THR_FR_LOAD_L_SV1 0%THR_FR_LOAD_D_SV1 0%,这样就能优先占用半速率信道.附半速率具体算法:LOAD_SV1的值为false，即小区话务负荷较低，小区将首先分配全速率信道；若LOAD_SV1的值为True,即小区负荷较高，小区将首先分配半速率信道;评估时候与LOAD_SV1的初始值也有关系.3开启Traffic HO (包括话务负荷设置)Traffic HO是针对当前的高话务小区和周围的低话务小区而言的，由相邻的低话务小区来分担当前高话务的服务小区的话务量,以期达到减小拥塞,话务均衡的目的,这是一种临时解决拥塞的措施. 从traffic HO发生的条件我们可以看出，只要当前小区处于HIGH_TRAFFIC_LOAD而邻小区处于LOW_TRAFFIC_LOAD，就可用发生traffic HO 的切换,建议值：将话务忙的服务小区High_traffic_load 设成60％，邻小区Low_traffic_load设成50％。
11513_SD掉话率高
11513 SD掉话率高
小区信息（CI、设备类型、载频数、跳频类型）：
CI=11513，设备类型FLEXI, 载频数8，跳频未开
现象描述：
1、关键字：SDCCH掉话、呼叫建立失败率、载频故障
2、描述。
13日晚该小区的SDCCH掉话率突然升高，导致呼叫建立失败率增高，从掉话的分类来看，SD掉话中RF的成分较高；
处理过程：
21日发现呼叫建立失败率较高，怀疑是TRX2频点干扰导致，修改TRX2频点从64->57，继续观察发现指标未改善，相关指标如下：
同时发现该小区13日有扩容：
这个小区自扩容后，SD掉话突然升高，话音质量统计良好，判断可能跟频点和硬件有关，21号修改有SD 的载频频点后指标仍未恢复，22号对载频进行功率测试，发现TRX2测试失败，FLEX站，TRX1/trx2为1个物理载频，倒换BCCH从TRX1->TRX3，同时暂时锁住TRX1/TRX2，随后观察该小区的SD掉话率及呼叫建立失败率明显下降,指标恢复正常；
SD掉话相关指标如下：
结论：从该小区的处理过程可以看出，小区扩容后，如果SD掉话率升高，其中SD掉话中RF的成分较高，同时呼叫建立失败率升高的情况，一般是由于小区载频故障或频点问题导致，在排除频点干扰原因外，可对载频进行功率测试判断载频故障（ZUBS 测试载频，ZUBP:TR:BTS= ,TRX= ;看载频的测试报
告），发现故障载频后应及时做出相关预处理操作，然后派单对故障载频进行更换；。
VoLTE高掉话小区处理流程
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 异常释放。
掉话处理流程
流程图掉话处理处理流程操作手册1、由小区性能监控模块发现小区掉话数多2、排查硬件故障如果掉话率突然上升，则需要检查本小区和相邻小区此时是否工作正常，通过OMC-R检查本小区和相邻小区告警，传输和天线是否出现异常，排除因为硬件原因产生的小区异常掉话。
解决措施:派单处理3、覆盖欠佳引起的掉话了解该小区的覆盖区域，是否存在一定的覆盖欠佳区域，覆盖欠佳是造成下行弱信号掉话的一大原因。
原因分析:服务小区由于各种原因（如无线环境好，功率过高，站点设置太高）产生越区覆盖，导致UE在移动到被越区覆盖的小区后，因无邻区关系配置，导致无邻区可切换造成的弱信号掉话。
越区覆盖导致的频率干扰和扰码相关性问题。
波导效应和湖面效应会使服务小区覆盖过远，引起干扰或切换判断混乱，产生掉话。
由于孤岛效应，处于孤岛的UE 无法切换出去，产生掉话。
由于一个地方没有一个足够强的主导频，出现导频污染，手机通话过程中，乒乓切换会比较严重，导致掉话率上升。
两个小区交接部分出现明显的无信号覆盖的漏洞，UE移动出覆盖范围，产生掉话。
由于高大建筑物遮挡产生的阴影效应。
解决措施:消除越区信号的影响：通过路测同事了解掉话小区及周围覆盖情况，查找覆盖不规范的基站，通过调整该站的下倾角，方位角，或降低它的最大发射功率等方法来优化覆盖区域，同时避免基站天线沿街道或湖面覆盖，避免街道效应和湖面效应等产生难以控制的信号，消除漂移信号对其它基站的影响.查找覆盖不足的地区：通过投诉组同事和路测同事的场测试来查明覆盖不足的地方，看是否可以通过调整下倾角，方位角，挂高，以及发射功率等方法增大覆盖范围（这需要综合考虑频率、扰码规划以及其它方位覆盖的情况）。
如果弱场区处于商场、隧道、地下停车场、地铁入口、高层建筑等特殊场合，则需要增加RRU，或室内分布来解决。
4、小区数参数配置不合理引起掉话检查小区各系统参数有无配置得很不合理，可以能过与正常小区之间的参数进行对比，找出是否出现个别参数调得很不合理面导致的。
华为TOP小区处理阶段流程经验总结
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开关；✓对于业务量持续较大的小区，可以考虑建议扩容。
掉话分析及处理流程
掉话分析及处理流程掉话分析流程：掉话处理流程：在上图中,如果不明原因掉话比较高,那么该小区存在硬件故障或其他外部影响的因素就比较大,然后才对这些不同类型的掉话进行分析;1）不明原因掉话①TRAU故障：用ALLIP查看是否有“RADIO TRANSMISSION TRANSCODER POOL MEAN HOLDTIME SUPERVISION”告警;如果出现告警,用RRMAP查看哪个设备出现告警,然后用RRTBI闭掉告警设备并报障;②传输故障：用DTQUP查看传输是否有滑码且不稳定,如果出现这种现象,报障处理;③时隙同步：用RXASP查看时隙是否同步,如果不同步,对载波或不同步的时隙重启,如果还不能解决问题,报障处理;④其他硬件故障：用RXMFP：MO=XXX,FAULTY,SUBORD;或用CTR分析、查看ERRORLOG,判断是否出现硬件故障;2）弱信号掉话处理流程①存在弱信号区域：通过周边的掉话类型和MRR数据可以初步判别是否存在弱信号区域；通过普查可确定弱信号区域;②2、硬件故障：用RXMFP：MO=XXX,FAULTY,SUBORD；或用CTR分析、查看ERRORLOG,判断是否出现硬件故障;③3、上下行信号不平衡：上下行信号相差15dBm时认为上下行信号不平衡;3）质差掉话处理流程①硬件故障：用RXMFP：MO=XXX,FAULTY,SUBORD；或用CTR分析、查看ERRORLOG,判断是否出现硬件故障;②频点干扰：通过配频、FAS和CTR分析可判断是否存在频点干扰;4）突然掉话处理流程①硬件故障：用RXMFP：MO=XXX,FAULTY,SUBORD；或用CTR分析、查看ERRORLOG,判断是否出现硬件故障;②存在弱信号区域：通过周边的掉话类型和MRR数据可以初步判别是否存在弱信号区域；通过普查可确定弱信号区域;。
高倒流小区分析优化思路详细案例
高倒流小区分析优化一．倒流定义5G分流比：5G流量占全网4/5总流量的比例；5G分流比为综合指标，关联终端、网络和市场。
倒流比=5G用户在4G网络产生的流量/4G网络的总流量。
话统5G倒流比指标：基于话统的5G倒流比计算方式，5G倒流比= (L.Thrp.bits.DL.NR.capable.plmn+ L.Thrp.bits.UL.NR.Capable.PLMN)/( L.Thrp.bits.UL.PLMN + L.Thrp.bits.DL.PLMN) * 100%。
1.1 分析过程1.1.1高倒流小区获取可通过SEQ平台/网管提取全网4G小区级流量。
（包含小区总流量及用户、5G用户4G 流量、以及5G用户4G流量占小区总流量的比例），具体模板如下：通常当4G小区内5G用户4G流量（日均）>10GB，且5G用户4G流量占小区总流量的比例大于20%时，认为该小区为SA用户高倒流小区，需针对高倒流小区进行分析处理，从网络侧提升分流比。
1.2.2高倒流小区分析思路针对上述提出的5G高倒流小区，按照如下思路进行原因分析，通过5大方面进行问题排查与分析。
（5大方面：覆盖、故障、参数、性能及其他；涉及的分析标准比如：距离、流量等可结合实际情况修改）1.2.2.1分析过程分析流程图：准备工作：基础信息准备（1）、核查高倒流小区的频点等基础信息，通过工参获得高倒流小区的站型(区分宏站/微站/室分/地铁/高铁)。
（2）、核查出每个高倒流小区500米内的5G站点及5G小区，并通过工参获得所有5G 小区的站型（宏站/微站/室分/地铁/高铁）。
排查是否有共站5G（1）、判断4G高倒流小区500米内所有5G站点的站间距与站型，若100米内存在同站型的5G站点时，一般可认为存在共站5G站点，进入第二步。
否则按无共站5G站点处理。
（2）、若非5G共站，判断4G高倒流小区是否为高铁/地铁，若为高铁/地铁，则定义为高铁/地铁无共站5G，需规划或新开高倒流共站5G。
室分VoLTE掉话问题处理总结
室分VoLTE掉话问题处理总结一、问题描述近日接到县局反馈在XX电信大楼通话过程中容易掉话，出现次数较多。
二、分析处理过程根据县局提供室分信息，查询了基站的告警情况，该小区为1t2r配置，底噪情况如下，实际底噪-85左右，（诺基亚基站小区正常底噪在-105左右；该小区ANT2实际未接馈线）：根据县局提供的手机号码及掉话时间，在智慧优化平台查看通话记录，发现其掉话原因为BEARER_RELEASED。
端到端语音质量对比情况，主被叫语音质量均优良，没有丢包问题和时延问题：分析被叫端语音质量，可以看出在最后的5秒内达到的达到包数相比减少了非常多：在“信令回溯”页面，可以看出eNobeB发送了UE Context Release Complete 消息给MME，具体原因未知：继续查询XDR话单，找到对应的使用记录，可以看出UE Context Release 的原因是Radio Connection With UE Lost:根据上述分析，在空口侧应该是UE失步了导致基站释放了它的上下文信息。
按照通话时间在基站侧进行了calltrace，从信令来看，掉线原因是Radio Connection With UE Lost，具体原因为上行BLER达到了100%，然后基站认为手机out of syn并释放了其手机上下文信息，导致掉话问题出现。
若干秒后三、处理方案根据上面的分析，是手机失步了然后基站释放上下文导致掉话问题出现。
查询小区参数，其N310，N311，T310均已达到最极限值，没有修改的空间了，而该小区的底噪问题由于涉及到较多的环节，暂时无法处理。
分析该小区周边站点情况，同站址内有L800小区在用，故暂时采用语数分析方案，临时解决掉话问题。
XX大楼室分小区_1修改了如下参数：数修改如下：因L800小区带宽较小，在承载了较多的语音业务后需控制其覆盖范围，我们将其rsboost调整为-3，电子倾角下压了3度。
PDCP高丢包小区处理
1高丢包定义VoLTE上行高丢包小区（语音）：>5%且小区QCI为1的DRB业务PDCP SDU上行期望收到的总包数>1000；VoLTE下行高丢包小区（语音）：>5%且小区QCI为1的DRB业务PDCP SDU下行发送的包数>1000；2丢包影响丢包对VoLTE语音质量的影响较大，当丢包率大于10%时，已不能接受，而在丢包率为5%时，基本可以接受。
因此，要求IP承载网的丢包率小于5%。
VoLTE丢包率是MOS值的一个重要影响因素，严重的丢包影响通话质量，甚至导致掉话，导致用户感知降低。
3影响丢包的因素影响Volte丢包的因素有故障告警、无线环境、大话务、传输、核心网、参数等多因素，详细如下：针对VoLTE丢包可进行关联分析的指标有：➢无线环境包括TA占比、MR弱覆盖、干扰、RRC重建、切换、邻区漏配等；➢容量包括：PRB利用率、单板利用率、CCE利用率、小区用户数等；1高丢包分析流程针对高丢包问题小区优化分析思路流程如下：2优化界定方案2.1故障告警核查问题小区及周边一圈层邻近小区是否存在影响业务的故障告警，若存在影响业务的故障告警，优先处理故障告警；影响业务的告警如下：处理建议：针对相应的故障进行故障处理。
2.2上行干扰小区级系统上行每个PRB上检测到的干扰噪声的平均值大于-110，即可判定该小区为上行干扰小区；干扰特征和干扰原因如下：干扰特征分类干扰原因整体抬升阻塞干扰其它其它干扰部分载波高谐波干扰滚降杂散干扰干扰器干扰器干扰MMDS MMDS干扰复合干扰（滚降+整体抬升）复合干扰（杂散+阻塞）复合干扰（MMDS+整体抬升）复合干扰（MMDS+阻塞）系统内干扰系统内干扰处理建议：结合现场进行干扰排查和处理。
2.3下行质差CQI 用以表示下行信道的质量，eNodeB 根据CQI 信息选择合适的调度算法和下行数据块大小，以保证UE 在不同无线环境下都能获取最优的下行性能。
精品案例_RRU频繁退服引起VoLTE掉话异常小区处理
RRU频繁退服引起VoLTE掉话异常小区处理案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (5)RRU频繁退服引起VOLTE掉话异常小区处理案例【摘要】4月份，小区GC-东至-东至尧城迎宾馆-电信-ZFTA-173755-182出现VOLTE掉话的异常小区。
查看4G专业网管，发现RRU存在频繁瞬断的告警，处理告警后，VOLTE掉话异常消失，问题得到解决。
【关键字】VOLTE 掉话 RRU瞬断【业务类别】VoLTE一、问题描述4月3-8日，小区GC-东至-东至尧城迎宾馆-电信-ZFTA-173755-182连续出现VoLTE语音掉话的异常。
如图所示。
二、分析过程VOLTE网络架构由图可以看出，VOLTE基于4G网络，由IMS（IP多媒体子系统）进行业务控制，4G网络负责信令和业务承载。
与VOTE业务有关的4G网络E-RAB承载有3种：一是QCI=5的承载，用于承载VOLTE业务建立、释放、变更的IMS信令；二是QCI=1的承载，用于承载VOLTE语音业务流；三是QCI=2的承载，用于承载VOLTE视频业务流。
根据《VOLTE无线网络优化指导书（第一册）》关于VOLTE掉话的定义，VOLTE掉话次数即QCI=1的E-RAB异常释放次数。
VOLTE掉话涉及终端、无线、EPC和IMS等诸多网元。
VOLTE掉话一般分为无线侧掉话和IMS侧的会话释放，掉话原因也要从无线和IMS两个方面来找，其中无线侧掉话原因包括设备故障、RRC重建失败等，需重点查看设备是否存在告警，RRC重建指标是否正常。
IMS涉及面较大，出现问题的可能性较小一旦出现问题，往往是全局性的。
VOLTE掉话分析，首先从无线侧入手。
通过中兴4G专业网管性能查询功能，查看GC-东至-东至尧城迎宾馆-电信-ZFTA-173755-182的VOLTE性能指标，如图。
由图看出，4月1-8日，小区RRC重建比例正常，但是QCI=1、QCI=5的E-RAB掉话率高，掉话次数较多。
五高一低一弱问题小区整治经验材料
五高一低优化总结—低话务小区
低话务小区现状： 优化前杭州有超低话务小区199个，通过话务均衡等手段有 134个小区已经恢复，现网低话务小区数目为65个： 超低话务小区比例从优化前6.03%下降到1.87%。
•通过调整小区层级、重选、边缘层间切换门限、功 250 200 150 6.03% 7.00% 6.00% 5.00% 4.00% 3.00% 1.87% 2.00% 1.00% 0.00%
责任到人
四结合：
参数优化和
硬件维护相
结合 图纸平台与 后台分析和 现场测试相
三点
闭环管理
实际优化相
结合
依据可实 施性，严 控处理周 期
四结合
网络指标与 规划建设相 结合
结合
五班组
室分组 主管：楼喆午 组长：郭嘉
优化分析组 靳少伟
现场测试组 金小鹏
维护组 蔡海燕
硬件排障组 王科炜
规划组 吴佳
目录
1 2
100
50 0
参数优化
率参数及邻区合理吸收小区覆盖区域的语音话务； •通过调整PS域参数，优化低话务小区数据业务，
优化前
超低话务小区数目
优化后
超低话务小区占比
提升等效数据业务。
• 建立低话务小区故障跟踪处理机制，及
故障排除
时发现和处理由于故障导致低话务的小 区。 • 建立常态化的话务跟踪机制， 对业务波动小区及时进行配置 调整。
27.56% 14.93% 14.67% 14.05% 12.47% 16.32%
有源器件故障 无源器件故障 邻区和参数设置不合 理 弱覆盖 PB值偏高或偏低
通过及时跟踪处理高掉话TOP
小区，室分高掉话小区改善明显， 指标由2011年高掉话专项开始时的 2.0%提升并稳定至当前的0.8%以 下。
TD星卡时钟输出异常告警导致周边大片站点高掉话处理案例
星卡时钟输出异常告警导致周边大片站点高掉话处理案例一、案例描述7月28日，在日常指标监控过程中，发现RNC14掉话率较高且掉话TOP小区均分布比较集中，分析数据发现中茵皇冠三个小区掉话率都较高，因此怀疑是中茵皇冠站点出现告警，经查询该站点在凌晨2点出现星卡时钟输出异常告警。
自从出现告警后，掉话率一直高居不下。
经统计，出现告警站点以及影响范围如下：本案例主要是阐述一下TD站点出现星卡时钟输出异常告警导致周边站点高掉话的处理流程。
二、问题处理1、告警说明（1) 告警级别：次要（2）告警影响：基站不能与星卡时钟同步，如果基站长时间获取不到参考时钟，会导致基站系统时钟不可用，此时基站业务处理会出现各种异常，如小区切换失败、掉话等，严重时基站不能提供业务。
（3）产生连带告警：出现该告警后长时间没有恢复，就会连带出现时钟参考源异常告警以及时间同步失败告警，如下图：2、处理流程在指标监控过程中，如发现大片站点掉话率高，及时定位问题站点，然后确定是否为星卡时钟输出异常告警，若是该告警首先闭掉该站点的所有小区，及时通知代维去现场，然后需要按照下面的流程进行处理：（1）后台人员远程处理流程：①确定星卡类型，如果是RGPS，通知现场代维，通过执行MML命令DSP GPS，输入GPS时钟编号，可以查询到星卡类型；②获取单板信息，执行MML命令DSP BRD，输入柜号、框号、槽号可查询单板类型及主备状态；③复位单板，执行MML命令RST BRD，输入柜号、框号、槽号复位单板；④倒换单板，执行MML命令SWP BRD，输入柜号、框号、槽号倒换单板主备；⑤下电复位单板，执行MML命令RST BRDPWROFF，输入柜号、框号、槽号复位单板；⑥查看告警是否恢复，若恢复问题处理完毕，若不能恢复，需代维现场处理。
具体流程图如下：(2)现场代维处理流程（需和后台配合）：①检查RGPS 与USCU 的连线，排除线缆破损，断裂，连接不牢等常见线缆故障，确认线缆完好联系远程人员，要求远程人员确认告警是否恢复； ②更换RGPS ，确定RGPS 安装完好，联系远程人员，要求远程人员确认告警是否恢复；③更换WMPT 单板，详细记录单板上的所有面板连线情况，然后联系后台闭塞WMPT 主控板，待板子换好以及数据做好后，通知远程人员现场处理完成，要求远程人员确认告警是否恢复，设备状态是否正常。
VoNR语音掉话实施方案
VONR语音掉话实施方案PCI优化（VoNR连片区域）1,5G-5G，5G-4GPCI冲突\混淆原因分析;PCI复用过近解决措施;为避免PCI混淆/冲突出现，在PCI规划时必须保证PCI的复用距离大于覆盖距离，并且建议间隔4层站点以；优化场景;对全网PCI重新规划原因分析;越区覆盖解决措施;越区覆盖是造成PCI混淆/冲突的重要原因，一般要求把小区的覆盖距离控制在1km以下，避免出现PCI混淆。
优化场景;调整越区覆盖小区小区功率原因分析;冗余邻区解决措施;①切换请求少的冗余邻区；②优化无效邻区。
优化场景;核查两两切换失败TOP邻区合理性2,MOD3/30压降，SRS干扰优化解决措施;相邻小区不应具有相同的Mod30值优化场景;对全网PCI重新规划5G-4G、5G-4G邻区优化，ANR验证选取区域进行ANR试点VoNR-VoLTE切换/重定向（VoNR边缘区域）1，VONR语音移动性及互操作策略优化措施;规划全网VoNR>EPSFB/VoLTE策略优化场景；系统规划全网5-4策略2，VoNR高掉话基础问题排查思路优化场景；排查小区状态是否正常、各单板状态正常、是否存在告警，排查无线环境是否存在覆盖问题，核查参数设置是否存在问题，是否是异常终端导致。
优化场景；分析TOP掉话小区3，VoNR向VoLTE切换成功率低切换成功率跟邻区息息相关，针对5-4的邻区进行全量核查（切换TOP场景）4，5G覆盖好VoNR向VoLTE切换丢包率指标统计存在问题需升级解决。
5，下行弱场门限设置不合理导致VoNR无法起呼全网核查弱场禁止VoNR起呼下行RSRP门限，其中宏站统一设置为-110与-105，室分站点统一设置为-105与-100。
通过合理设置弱场禁止起呼门限，提升用户感知。
（5G弱覆盖场景）EPS FB低接通基于语音质量的异频和异系统切换（特性功能）基于VoNR语音质量的异频切换基于VoNR语音质量的E-UTRAN切换。
话务掉话比(苏庆国)
话务掉话比分析:通过话务掉话比公式可以看出，在话务量为定量的前提下,无线掉话及切换掉话的减少,就意味着话务掉话比的提高。
大致的优化思路:找出高掉话小区，并分类处理：第一类是高掉话并高话务的小区,这些小区掉话次数较高，对全网的掉话率影响较大，应该首先处理，统计周边小区指标,检查是否有越区覆盖，天线设置是否合理并检查硬件是否有隐患故障；第二类是高掉话且一般话务小区,检查无线环境是否设置合理,是否有频率规划不合理处；第三类是切换掉话多的小区,检查小区切换参数及基站硬件，同时对于邻小区关系进行了重新规划；在各类小区中都重点检查了天馈部分，由于菏泽1800M基站较少，无线环境较差，所以关闭了基于信号质量的切换。
系统参数修改:修改部分系统参数可能让统计指标在短期内得到一定的提高甚至是脱离现实情况,但可能对用户实际使用没有多大帮助,所以系统参数修改应基于在硬件问题,无线问题及实际使用情况改善的基础上进行,所以将参数修改列为最后进行；针对无线掉话较高的情况我们适当修改了一下参数：Link_fail 由原来的12 改为 15；Radio_link_timeout 由原来的 12 改为 15；Link_about_to_fail 由原来的 9 改为 4通过这些工作的进行我们的掉话率由原来的1左右降低到0.6 左右，话务掉话比由原来的90多上升到现在的150 左右。
附：参数◆link_fail此参数设置RSS如果连续多少个复帧没有解出来，就认为上行链路fail。
可以将此参数看作一个计数器，如果能正确解出SACCH则计数器加二，否则计数器减一。
此计数器最大值为radio_link_timeout.取值：0 – 15（4 – 64个SACCH）◆link_about_to_fail由link_fail计数器计算，当link_fail-link_about_to_fail 个SACCH复帧没解出时，则使得MS和BTS都设置为满功率发射。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
高掉话小区处理流程建议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_trafficB = p_nbsc_serviceC = p_nbsc_ho上表就是NOKIA设备中，分为在各个接口的14类掉话。
3.掉话的优化建议当在分析某小区的高掉话时，应先看它掉话发生在哪个接口，然后在做具体的分析，详细分析过程如下：RF掉话定位及处理：（TCH_RADIO_FAIL）1、如上行话音质量较差同时OUT OF BAND 1比例很高，说明干扰等级较高，确认是否存在外部干扰、直放站故障等，并对干扰源进行查找和排除。
干扰带取自：Counters from tables:OMC_P_NBSC_RES_AVAILband 1:Sum(OMC_P_NBSC_RES_AVAIL!AVE_IDLE_F_TCH_1/OMC_P_NBSC_RES_AVAIL!RES_AV_DENOM4) band 2:Sum(OMC_P_NBSC_RES_AVAIL!AVE_IDLE_F_TCH_2/OMC_P_NBSC_RES_AVAIL!RES_AV_DENOM5) band 3:Sum(OMC_P_NBSC_RES_AVAIL!AVE_IDLE_F_TCH_3/OMC_P_NBSC_RES_AVAIL!RES_AV_DENOM6) band 4:Sum(OMC_P_NBSC_RES_AVAIL!AVE_IDLE_F_TCH_4/OMC_P_NBSC_RES_AVAIL!RES_AV_DENOM7) band 5:Sum(OMC_P_NBSC_RES_AVAIL!AVE_IDLE_F_TCH_5/OMC_P_NBSC_RES_AVAIL!RES_AV_DENOM8)2、如上行质差，确认是否为载频故障或频点干扰，一般建议先关闭跳频，然后通过倒换频点或载频的方式进一步确定。
通常有以下几种方式：载频之间频点互换，确定是否为频率干扰，如果掉话发生在同一个频点上，可以确定为频点干扰情况，可通过MAPINFO来进行核查,同、邻频点检查，选取干净的频点，排除频点干扰。
载频之间频点互换后，如果掉话依旧发生在同一块载频上，可以确定是否为载频故障，对故障载频进行更换处理。
载频之间槽位更换，该操作需要工程人员实施。
备注：倒换载频后，有时可能会马上出现7745告警，可以通过重启载频恢复。
要求监控人员在倒换载频操作后，需要跟踪小区是否出现由于倒换载频造成的高掉话。
在处理故障载频时，可以通过以下方式定位载频故障：载频频繁存在告警。
载频存在故障告警，如TRX_FAULTY、高温告警等。
载频7745告警占用比例高，重启后仍然存在。
载频级的统计显示某载频掉话很高。
载频级的统计显示某载频的KPI统计相对其它载频异常，如发射功率、上下行接收信号强度、上（下）行话音质量、PATHBALANCE等。
基站是否存在7604、7607告警，可派单给相关部门检查天馈和基站硬件。
如基站开有BB或是RF跳频，话音质量突降情况，可通过关闭跳频定位是否个别载频故障导致。
如切换失败率异常，请参考切换失败率处理流程。
4、确认小区空闲小区重新参数、接入参数(手机功率等级设置等)、小区切换参数、BMA等设置是否合理。
5、对于突发的高掉话，可查看周围是否有小区退服、参数是否存在变动、是否做过工程调整等，突发的高掉话需要持续跟踪。
6、结合上下行信号强度、MS和BTS的发射功率统计、覆盖距离统计确认小区是否存在弱覆盖，同时分析造成弱覆盖的成因。
7、在KPI指标正常情况下，可通过网优平台查看该小区是否存在直放站，直放站性能不好或者频点设置有误等，也会造成对掉话的影响。
8、确认是否BSC内部较多小区存在突发高掉话，这可能由于BCSU吊死、BSC级的参数设置不合理、BSC 内较多小区的参数设置有误等造成。
9、其它异常情况，如进程故障、SDCCH信道吊死(一般建议SDCCH信道设置在时隙0)等，可通过重启BCF、倒换SDCCH信道解决。
切换掉话定位及处理（TCH_RF_OLD_HO、TCH_ABIS_FAIL_OLD、TCH_A_IF_FAIL_OLD、TCH_TR_FAIL_OLD）切换掉话是发生在切换过程中，由于切换不成功后不能回到原来的信道而造成的掉话。
由此可见切换掉话的产生和TCH射频掉话有所不同，因此分析方法也有一定的差异，下面我们将给出具体的切换掉话分析处理流程图并详细说明如何分析、处理切换掉话。
具体分析流程图通过分析掉话比例后发现一个小区的掉话主要是切换掉话，则可根据下面的流程进行分析。
同无线掉话相比，切换掉话的分析和处理要复杂很多，而且不是很容易对问题进行定位，处理周期相对较长。
切换掉话的主要原因是由于切换不成功后，移动台不能回到原来的信道而造成的掉话。
1.该小区是否有硬件问题对于切换来说，是一个TCH信道分配的过程，如果信道存在问题，则有可能出现系统分配了TCH信道，但移动台不能正常占用所分配的信道，而出现分配失败，这时就可能会出现掉话。
硬件问题可以通过载频级掉话的分布，看掉话是否长期集中在同一块载频上，如果是，就更换改载频。
2.邻区的问题应主要从以下这些方面来进行分析。
邻区是否有硬件问题这里对硬件问题的分析和处理方法与无线口掉话的硬件问题分析处理方法相同，在此就不进行重复说明。
邻区数据是否正确通过统计发现和某个邻区切换不成功次数较多，这时应检查一下该邻区的BCCH、BSIC和LAC数据是否正确，如果有错误应该立即更正。
另外如果通过统计分析发现和某个邻区切换次数很多，但成功的极少，这时需要检查一下该小区周围是否存在和这个邻区同频、同BSIC的小区存在，如果有则应该对邻区进行优化。
通常这时切换掉话会明显减少。
邻区的BCCH频率是否有干扰切换掉话较高的小区和某个邻区切换不成功的次数较多时，也有可能是由于该邻区的BCCH频率有干扰，这时可以通过一些优化工具检查一下该邻区的BCCH的频率规划，如果有同、邻频可能造成干扰的情况，可以先进行改频或者使用测试频点，然后观察切换掉话情况，如果连续观察几天发现切换情况好转，切换掉话减少则可以确定是频率干扰造成，但如改频后掉话仍未好转，则可以认为不是频率问题，应考虑其他方面是否存在问题。
邻区是否有干扰同无线口掉话一样，干扰也会造成切换掉话较高的情况发生，因此可以对问题邻区的OUT_BAND1统计进行分析，检查一下该邻区是否有干扰，通常这时该邻区本身的掉话也会因为干扰而有所增多。
邻区是否拥塞邻区拥塞也有可能造成切换掉话增多，这时只有通过缓解该小区拥塞来减少掉话，或者可以通过补充邻区关系，是源小区在不能切换到拥塞的邻区时，可以选择其他的邻区进行切换，以此来减少切换掉话的次数。
LAPD掉话定位及处理（TCH_LAPD_FAIL）1、统计分析ET的可用率和误码率。
2、查看告警确定是否为载频退服导致，并查看相关原因，如需要更换载频或做基站硬件处理，与相关部门合作处理。
3、ZYMO指令查看是否存在传输误码导致传输闪断。
4、确定基站是否出现过断电原因造成的退服。
Abis口掉话定位及处理（TCH_ABIS_FAIL_CALL）1、查看告警是否相关载频存在7745告警，可通过复位载频观察。
如复位载频后，7745高告警仍然存在，仍然存在高掉话，可尝试锁住载频观察掉话情况，在确定由于某载频故障导致ABIS高掉话后，可先行闭锁TRX然后更换。
2、检查小区是否存在严重的同邻频干扰问题。
3、对Abis口的传输可用率和误码率进行统计。
A口掉话定位及处理（TCH_A_IF_FAIL_CALL）1、如果A口掉话均匀分布在BSC内所有小区上，A口电路存在故障，向相关部门反映解决。
A口掉话一般都是由于跨MSC的切换引起，可检查相关切换指标和切换参数以及目标小区的工作是否正常。
对A口的传输可用率和误码率进行统计。
TR掉话定位及处理（TCH_TR_FAIL）1、如果TR掉话在BSC内部分布比较均匀，可能为TC板或BSC级其它单元故障，需要更换排查硬件故障。
2、查看是否有2993告警，定位哪些些站或BSC TC出现这种问题。
如果单站出现TR掉话，为降低对用户的影响，可优先考虑以下方式处理：a)考虑重启该载频b)考虑关闭该载频c)考虑关闭该时隙3、出现2992告警时一般为BSC TC故障，现象是BSC多个BTS出现少量TR掉话，不像2993告警，单个BTS大量TR掉话。
当BSC反复出现此告警时，可以确定是BSC TC故障，需及时更换硬件单元。
4、检查TRX数据是否正确，如果因工程、割接等造成TRX数据时隙做错，重起是无效的。
判断BTS现场还是BSC TRX数据时隙做错,重做TRX数据纠正。
5、如复位载频和重建数据均无效，确定是否为载频故障或传输配置数据有误。
6、通过调节BSC参数ITCF，可以对TR掉话有所缓解，建议设为最大值5。