掉话类故障处理指导
掉话处理流程
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。
掉话处理方法
1.出现小区级掉话时，首先查看该小区有硬件故障告警，2.检查切出成功率是否正常，如果切换成功率较低，检查邻区关系以及是否存在同频同码的情况。
1》邻小区关系中是否存在同频同扰码的现象，这种情况在路测中也可以发现，一般是在邻区表中出现两条相同频点的邻小区关系，这里需要注意的是业务同频同扰的现象，它无法在路测中发现，一般需要对信令进行分析，此时虽然两个小区主载频异频，但measurement report却上报了1G事件，针对这种情况需要通过修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查）2》邻小区关系中是否存在同频同码组的现象，这种情况在路测中也可以发现，一般情况是它是影响到终端的测量结果，此时测量结果不准确，造成终端上报系统后系统判断错误，针对这种情况则需要修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查）3》是否存在单边邻小区关系，如果存在，添加单边邻区，单边小区的检查可以使用NOP-T工具进行也可以通过对性能统计指标中的小区对切换统计指标来检查。
4》是否存在异频邻小区个数过多的现象（异频邻区数超过8个），如果存在，删除不必要的邻区，这种情况可以使用NOP-T工具进行检查，也可以使用办公软件进行检查。
5》是否存在切换开关设置的问题（有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止），如果存在，打开切换开关。
6》切换相关的事件定义是否准确，不区引用是否正确，如果存在，修改引用。
7》PS切换失败是否存在完整性算法问题，如果存在，将之间的完整性开关设成一致。
8》是否存在邻区漏配的情况9》目标小区拥塞造成的掉话，由于目标小区的资源不足，而本小区的覆盖又越来越差，此时造成掉话，常见的错误代码为no_resource_available或RRM_Celloverload_Release3、检查时隙转换点配置是否正确，是否存在交叉时隙干扰，如果存在，修改时隙转换点4、检查UP时隙贺上行业务时隙的干扰电平，是否存在上行干扰导致掉话，若存在，进行干扰排查5、根据性能指标统计，如果PS域和CS域的BLER都比较高则可能存在干扰，然后再结合载频时隙干扰统计指标来判断是否确实存在干扰，另外通过对信令的分析如存在干扰则一般信令流程正常，未有切换或其他事件，但RNC进行了IURELEASE，原因一般为无线链路的原因（比如无线链路错误等），有时也会发生CELLUPDATE原因为RLCunrecoverable erro如果存在则需要现场排查，现场测试时如果存在干扰则有以下几方面的显示：1》C/I较差：系统内同频的干扰较为严重，发生掉话时会存在终端发射功率较高的现象，同时覆盖也相对较好，表现在RSCP值上，一般都在-90dB以上，另外一表现象就是起呼比较困难，而起呼成功后也容易掉话2》终端发射功率较高，基本上满功率发射，一般都在-20dB以上3》系统外的干扰造成的掉话同样具有终端发射功率较高的现象，也一般都在-20dB以上4》系统外的干扰造成的掉话也可以通过误块率指标进行判断，此时无论是进行CS业务还是PS业务BLER都比较高，且保持时间较长5》系统外的干扰语音业务判断，此时进行通话会出现断字，吞字等现象，比较难以进行通话6.通过对性能指标的统计主要是RRC连接成功率的统计，这其中包括业务相关和非业务相关的统计，如果两种统计都差则可能存在覆盖问题，此时检查CT数据中RRC CONNECTION REQUEST中的PCCPCH的值，则存在弱覆盖现象，需进行功率参数，天线方位角、下倾角的调整7.如果上述都检查不出原因，可能是载波的隐性故障，此时可以尝试闭解载波时隙，或者强行闭载波、时隙观察掉话率的变化8.终端问题，一般是通过对大量的性能数据统计，发现掉话高的小区，然后依据小区信令数据分析信令，可以看出掉话常发生的用户，而后进行处理。
VOLTE端到端掉话分析指导
VOLTE端到端掉话分析指导端到端掉话是指通话过程中，双方用户在语音通话过程中突然失去声音或嘈杂的背景声音，导致通话无法继续进行。
在进行VOLTE（Voiceover Long Term Evolution）时，如果出现端到端掉话问题，需要进行分析和解决。
1.确定掉话现象2.收集掉话问题的证据在用户报告掉话问题后，需要收集相关的证据以进行分析。
可以收集以下内容：-掉话的具体时间和地点-掉话前后的通话质量和信号强度-接入网关或基站的状态信息-网络负载和流量数据3.检查网络和设备接下来，需要检查网络和设备的问题。
可以执行以下操作：-检查网络连接是否正常，例如查看是否有网络故障或网络拥塞的现象。
-检查设备是否有软件更新或升级，确保设备处于最新的运行状态。
-检查设备的电池是否充足，如果电池电量不足可能会影响通话质量。
4.分析通话质量报告VOLTE通话质量报告会记录通话过程中的相关数据，如接收信号强度指示（RSSI）、信噪比（SNR）、块错误率（BLER）等。
分析这些报告可以帮助找到问题的原因。
如果在特定时间段内出现了信号强度下降、信号干扰或其他异常现象，可能会对通话质量产生影响。
5.进行网络路径分析网络路径分析可以帮助确定通话过程中数据传输的路径，并找出可能的问题。
可以通过以下方式进行网络路径分析：- 使用ping命令测试网络连通性，了解数据包在网络中的传输情况。
-分析数据包进出的路由情况，检查是否存在延迟或丢包的现象。
-检查语音流量是否经过负载均衡设备，负载均衡设备的故障可能会导致掉话问题。
6.调查核心网和IMS网络- 网络设备或服务器故障，如SBC（Session Border Controller）或BGCF（Breakout Gateway Control Function）的故障。
-网络节点配置错误，如路由配置错误或信道配置错误。
总结：。
10-掉话类故障分析与处理
M900/M1800 基站子系统故障处理手册目录目录第10章掉话类故障分析与处理...........................................................................................10-110.1 概述...............................................................................................................................10-110.1.1 掉话问题描述......................................................................................................10-110.1.2 掉话的计算公式..................................................................................................10-310.2 导致掉话的几种因素......................................................................................................10-410.2.1 覆盖引起的掉话..................................................................................................10-410.2.2 切换引起的掉话..................................................................................................10-610.2.3 干扰引起的掉话..................................................................................................10-810.2.4 天馈引起的掉话................................................................................................10-1010.2.5 传输引起的掉话................................................................................................10-1110.2.6 无线参数设置不合理.........................................................................................10-1110.2.7 其它原因引起的掉话.........................................................................................10-1210.3 典型案例......................................................................................................................10-1310.3.1 优化切换参数减少掉话.....................................................................................10-1310.3.2 直放站干扰引起掉话.........................................................................................10-1310.3.3 MAIO相同引起干扰掉话...................................................................................10-1510.3.4 上下行不平衡....................................................................................................10-1510.3.5 孤岛效应引起掉话.............................................................................................10-1610.3.6 与版本相关的参数设置.....................................................................................10-17第10章掉话类故障分析与处理10.1 概述在GSM网络中，掉话率是衡量无线网络质量的重要指标。
移动通信掉话故障分析及解决方案
移动通信掉话故障分析及解决方案掉话率是衡量移动通信无线网络质量的一项重要指标，解决减少掉话成为了提升网络质量和客户满意度的重要工作。
本文例举了移动通信中无线系统几种常见的掉话问题，如因直放站掉话、设备引起的掉话、切换掉话、干扰掉话等，并简要分析了这几类掉话的原因，提出了相应的解决方案。
标签掉话；切换；干扰；直放站1 前言我们在使用手机过程中经常会遇到掉话的问题，这也是许多移动用户申告的热点之一。
所谓掉话，就是指通话双方在通话期间由于某种原因非正常终止通话。
移动通信系统是有线与无线的综合体，它是移动网络在其覆盖范围内，通过空中接口将移动台与基站联系起来，并进而通过移动交换机交换连接，实现用户终端无线联络。
由于移动电话的移动性及无线传输的复杂性，因而一定程度的掉话显得不可避免的。
但随着无线技术的不断发展和网络质量的逐步提升，无线掉话正被逐渐克服和改善。
掉话率是考核无线网络的一项重要指标，它从一个侧面反映了网络运行的质量情况。
2 产生掉话的几种原因2.1 网络漏覆盖或盲区引起的掉话2.1.1 移动网络建设初期，由于资金问题和无线规划的缺陷，以及大众对移动通信需求的飞涨，无线基站在一些地区还存在着许多的盲点和漏点。
当移动台进入网络的漏覆盖区或信号盲区时，因信号太弱而发出切换请求，但切换不成功引起掉话。
2.1.2 初期网络建设为了解决无线覆盖问题，采用全向基站较多，一些基站在工程选址时又往往选到山坡或大楼楼顶等高处上，导致近距离覆盖不好，且覆盖范围又过大，在统计上体现上行信号弱掉话比例较高。
2.2 直放站引起的掉话为减少投资，扩大覆盖范围，一些小基站普遍采用直放站放大信号，但由于目前大量使用的直放站是900MHz宽带放大器，基站与直放站之间绝大多数又是射频连接方式，加之直放站的规划和选址上存在一些问题，特别是部分县局设置的直放站不是接收本局基站的信号，而是就近接收邻县(市)基站的信号，从而造成邻县(市)基站掉话率偏高。
掉话小分析
1、根据你平时的工作经验，分析一下现网可能产生掉话的原因及
相应的解决措施。
（14分）
1）由于系统故障导致的掉话
及时查找MSC、BSC告警，并检查系统是否有大规模的调整，软件升级、补丁
2）由基站设备硬件故障引起的掉话
查找相关硬件的告警，更换相关硬件
3）由于天线馈线的原因导致掉话
检查仰角，检查馈线是否接反，接头接触不良或馈线损坏现象，天线的方位角和俯消除天线后向信号的干扰
4)由于A接口、ABIS接口的故障引起。
5)由于传输故障，同步不好，传输质量差造成的掉话
定期进行基站的时钟校准，传输同步检查和传输质量的检查
6)由于干扰导致的掉话
上行干扰：若同频，修正同频频率，若外部干扰，通过频谱分析仪来分析解决，寻找干扰源
下行干扰：通过统计数据的分析，结合现场测试，对干扰的频率进行修改
7)由于覆盖原因导致的掉话
措施：查找覆盖不足的地方；增加基站的覆盖；消除漂移信号的影响，比如仰角的调整，基站的发射功率的调整，最小接入电平的调整
8)由于切换引起的掉话
检查邻小区表是否定义完整：切换参数是否定义正确；目标小区是否拥塞；是否有频率干扰。
掉话处理浅解
SDCCH掉话的处理步骤及判断方法一、对于上行干扰引起的TCH掉话小区：（1）首先可以查看TCH信道分配性能测量话统，看每块载频TCH信道受干扰情况，如果只有一块载频受干扰，可以把受干扰的，和没有受干扰的载频频点对换：（a）若对换后，上行干扰随频点转移到另外一块载频上，可能是由于频点干扰引起（一般频点干扰，上下行接收质量也比较差），建议修改频点；（b）若对换后，上行干扰并没有随频点转移，而仍然集中在原来那块载频，很有可能是载频有问题，或者跟这块载频级连的合路器出现故障，建议更换硬件设备观察。
（c）也有可能对换频点后，两块载频都没有出现上行干扰（这中情况比较少见），可能是由于载频隐形故障，或者该载频对某一频段的频点滤波性能比较差引起。
临夏县-3小区就属于这种情况，对换频点后，发现上行干扰都消除。
（2）如果这个小区载频数比较多，其中有两块或者两块以上载频出现上行干扰：（a）有可能是这几块载频的频点受到干扰，建议修改频点观察（康乐-1小区曾出现这个情况；（b）也有可能是硬件故障，建议到BTS机房查看这几块载频跟合路器的连接情况，如果这几块载频连接到同一合路器下，建议先更换合路器再观察；（3）如果是所有的载频都出现干扰：（a）一般是由于直放站工作不正常，或者干扰器问题引起（同时查看周围基站的是否有上行干扰），建议实地勘查扫频。
（b）也有可能是馈线接口松动或者是和馈线相连的CDU故障，建议到BTS机房查看。
二、对于下行问题引起的掉话小区：可以查看接收电平话统，接收质量话统，查看每块载频的上下接收电平，上下行质量情况：（a）如果某块载频的下行电平，下行质量都很差，而上行电平，上行质量正常，一般是由于载频隐性故障引起，可以重启载频，若还是不行，建议更换载频板；（b）如果某块载频的上下行电平都正常，而上下行质量差，很有可能是频点干扰引起，建议更换频点观察；（c）如所有载频的下行电平都比上行电平低，很可能是由于合路器故障或者天馈问题引起，建议进BTS机房查看馈线接口是否松动，以及更换合路器观察。
掉话处理流程
流程图掉话处理处理流程操作手册1、由小区性能监控模块发现小区掉话数多2、排查硬件故障如果掉话率突然上升，则需要检查本小区和相邻小区此时是否工作正常，通过OMC-R检查本小区和相邻小区告警，传输和天线是否出现异常，排除因为硬件原因产生的小区异常掉话。
解决措施:派单处理3、覆盖欠佳引起的掉话了解该小区的覆盖区域，是否存在一定的覆盖欠佳区域，覆盖欠佳是造成下行弱信号掉话的一大原因。
原因分析:服务小区由于各种原因（如无线环境好，功率过高，站点设置太高）产生越区覆盖，导致UE在移动到被越区覆盖的小区后，因无邻区关系配置，导致无邻区可切换造成的弱信号掉话。
越区覆盖导致的频率干扰和扰码相关性问题。
波导效应和湖面效应会使服务小区覆盖过远，引起干扰或切换判断混乱，产生掉话。
由于孤岛效应，处于孤岛的UE 无法切换出去，产生掉话。
由于一个地方没有一个足够强的主导频，出现导频污染，手机通话过程中，乒乓切换会比较严重，导致掉话率上升。
两个小区交接部分出现明显的无信号覆盖的漏洞，UE移动出覆盖范围，产生掉话。
由于高大建筑物遮挡产生的阴影效应。
解决措施:消除越区信号的影响：通过路测同事了解掉话小区及周围覆盖情况，查找覆盖不规范的基站，通过调整该站的下倾角，方位角，或降低它的最大发射功率等方法来优化覆盖区域，同时避免基站天线沿街道或湖面覆盖，避免街道效应和湖面效应等产生难以控制的信号，消除漂移信号对其它基站的影响.查找覆盖不足的地区：通过投诉组同事和路测同事的场测试来查明覆盖不足的地方，看是否可以通过调整下倾角，方位角，挂高，以及发射功率等方法增大覆盖范围（这需要综合考虑频率、扰码规划以及其它方位覆盖的情况）。
如果弱场区处于商场、隧道、地下停车场、地铁入口、高层建筑等特殊场合，则需要增加RRU，或室内分布来解决。
4、小区数参数配置不合理引起掉话检查小区各系统参数有无配置得很不合理，可以能过与正常小区之间的参数进行对比，找出是否出现个别参数调得很不合理面导致的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
掉话类故障处理指导
掉话分类定义
在华为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 +
L.E-RAB.NormRel.QCI.N）
其中：
分子上表征异常释放的Counter为L.E-RAB.AbnormRel.QCI.N= L.E-RAB.AbnormRel.QCI.1+L.E-RAB.AbnormRel.QCI.2+
L.E-RAB.AbnormRel.QCI.3+L.E-RAB.AbnormRel.QCI.4+ L.E-RAB.AbnormRel.QCI.5+ L.E-RAB.AbnormRel.QCI.6+ L.E-RAB.AbnormRel.QCI.7+ L.E-RAB.AbnormRel.QCI.8+ L.E-RAB.AbnormRel.QCI.9；
而分母上是正常释放与异常释放的总和，正常释放的Counter为L.E-RAB.NormRel.QCI.N= L.E-RAB.NormRel.QCI.1+L.E-RAB.NormRel.QCI.2+
L.E-RAB.NormRel.QCI.3+L.E-RAB.NormRel.QCI.4+ L.E-RAB.NormRel.QCI.5+ L.E-RAB.NormRel.QCI.6+ L.E-RAB.NormRel.QCI.7+ L.E-RAB.NormRel.QCI.8+ L.E-RAB.NormRel.QCI.9；
常见掉话原因
邻区错/漏配
通常，网络建设初期优化过程掉话占大多数是由于邻区错/漏配导致的。
对于LTE网络内同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：
方法一：如果掉话后UE马上重新接入，且UE重新接入的PCI与UE掉话时的PCI不一致，则可以怀疑是邻区错/漏配问题，可以通过测量控制进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。
方法二：在网络侧，观察eNodeB在收到UE上报的测量报告后如果没有处理，且同时X2口没有往目标小区发送HANDOVER_REQUEST，则可以怀疑是邻小区漏配。
（该方法只适用于异站切换，同站切换没有X2口交互）。
邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。
异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，UE没有测量或者上报异频邻区，而UE掉话后重新驻留到异频邻区上。
异系统邻区漏配表现为UE在LTE网络掉话，掉话后UE重新选网驻留到异系统网络，且从信号质量来看，异系统网络的质量很好。
定位邻小区错/漏配的方法可通过UE的Scanner功能进行扫频，观察是否有更强的的且不在邻小区列表中的小区。
邻小区错/漏配需要结合工参、电子地图等信息进行优化。
弱覆盖
这里所说的弱覆盖是超出了链路预算获得的最大路损得到的下行及上行的覆盖，由于上下行支持的最大路损不一致，通常在LTE中上行较之于下行先受限，故在这里提到的弱覆盖将分为上行弱覆盖及下行弱覆盖。
按照当前V100R005C00及以后版本的商用网典型配置来看，下行PDSCH导频配置的是15.2dBm（2T2R配置），上行UE最大发射功率为23dBm。
在链路预算过程中链路预算的结果和场景、链路预算的边缘吞吐率、接收机灵敏度等的配置强相关。
弱覆盖问题需要结合实际路测情况及工参进行调整优化。
切换导致的掉话
在LTE系统中，在时间轴上，可将切换分为如下3类：过早切换、过晚切换及乒乓切换。
由于重建的引入，通常过早切换能重建回原小区，故不会引发掉话，而过晚切换及乒乓切换易导致掉话。
从信号变化趋势上来看，过晚切换主要有以下现象：
拐角效应：源小区RSPR/SINR陡降，目标小区RSRP/SINR陡升（即突然出现在邻小区列表中就是很高的值）；
针尖效应：源小区RSPR/SINR快速下降后一段时间后上升，目标小区出现短时间的陡升后立即陡降。
因为切换过晚时容易发生目标小区没有UE的上下文，由于eRAN2.2SPC230之前的版本尚未实现无上下文的重建，故易造成重建失败，最终导致掉话。
之后的版本在多数场景下可以无上下文重建成功，如果该现象仍有发生，需要具体问题再具体分析。
从信令流程上看，一般在掉话前UE上报了邻区的A3测量报告，eNodeB也收到了测量报告，并下发了切换命令，但是UE侧收不到，此时如果目标小区能有UE的上下文且能重建成功，可以不掉话。
乒乓切换在信号变化趋势上有如下表现：
1）主服务小区变化快：2个或者多个小区交替成为主服务小区，主服务小区具有较好的RSRP 和SINR且每个小区成为主导小区的时间很短；
2）无最优小区：存在多个小区，RSRP正常而且相互之间差别不大，每个小区的SINR都很差。
从信令流程上看，一般可以看到UE刚刚完成一次切换后就有新的测量报告上报并发起另一次切换，由于切换后还有较多的重配置消息下发（CQI上报模式、sounding等），在乒乓区域易导致这些命令超时失败引起掉话。
解决切换过晚导致的掉话问题，可以通过调整天线位置，修改切换参数或者配置CIO使目标小区能够提前发生切换；解决乒乓切换带来的掉话问题，主要通过调整天线位置改善RF，使得该区域能有一个稳定的最优小区。
对于异频切换和异系统切换，在切换前需要通过启动GAP来进行异频或者异系统频点的测量，故需要对A2参数进行合理配置，保证及时的起GAP测量，从而避免起GAP过晚导致的终端来不及测量目标侧小区的信号导致掉话，并合理的配置目标小区的门限。
干扰引起的掉话
通常干扰分为上行干扰及下行干扰，系统内干扰及外来干扰。
不论哪种类型的干扰都会导致掉话。
通常，对于下行，当服务小区的RSRP高于-90，但是SINR低于-6，基本上可以认为是下行干扰的问题（当邻小区错/漏配或切换不及时的时候，也可能出现服务小区RSRP信号很好，但SINR很差的情况）；下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现频繁小区重选或者乒乓切换，可能会导致掉话。
通常在没有干扰的情况下，上下行是平衡的，而当下行存在干扰时，会体现在下行受限，上行不受限；而存在上行干扰时，则是上行受限但下行不受限。
流程交互失败
一些需要信令交互的流程，如CQI上报周期、MIMO模式、SRS、ANR流程等，这些流程往往常常会由于无线环境的原因，eNodeB与终端侧兼容方面的原因或者UE本身的问题导致流程失败，最后导致掉话。
这类问题需要针对特定的流程进行分析，特殊情况特殊处理，没有一般性的处理方法。