在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。
比如：NodeB异常引起的切换失败；
比如：手机不上报1G/2A测量报告导致掉话；
这里需要重点注意的是测试手机异常死机引起的掉话问题，一般在拨测过程中容易出现这个问题，具体表现为路测记录的数据中有一段时间没有手机上报的信息。 3.2. 掉话问题分析思路 3.2.1. 掉话分析判决树
综合各种掉话原因，掉话分析的判决树如下图所示：
1 准备数据 2 获取掉话 位置和时间 3 分析Scanner主导小区信号主导小区信号稳稳4 Scanner最优小区RSCP 变化4.1 RSCP差 4.3 RSCP正常 4.2 RSCP正常 不UE和Scanner一确认漏配 确认N N UPPCY Y 覆盖问题 邻区漏配 切换不及时 UPPCH干扰问异常掉话 导频干扰问题 乒乓切换问题 5 重新路测 问题是否解决
? 准备数据
路测软件采集数据文件、RNC记录的单用户跟踪、RNC记录的CHR ? 获取掉话位置
采用路测数据处理软件获取掉话的时间和地点，掉话时的无线参数和信令流程，获取掉话前后Scanner采集的导频数据等。
? 分析Scanner主导小区变化情况
主要分析主导小区的变化情况，如果主导小区相对稳定，进一步分析RSCP和C/I情况； 如果主导小区变化频繁，需要区分主导小区变化快的情况，或者没有主导小区的情况，然后进一步进行乒乓切换掉话分析。
? 分析Scanner主导小区信号RSCP和C/I
观察Scanner最好小区RSCP，C/I，根据不同的情况分别处理 ? RSCP差，C/I差，可以确定为覆盖问题； ? RSCP正常，C/I差，可以确定为干扰问题；
? RSCP正常，C/I正常，如果UE的服务小区与Scanner最好小区不一致，可能为邻区
漏配或者切换来不及导致的掉话；如果UE的服务小区与Scanner最好小区一致,可能为UPPCH干扰或者异常掉话。 ? 路测重现问题
由于一次路测不一定能够采集到定位掉话问题需要的所有信息，此时需要通过进一步路测来收集数据。通过进一步的路测也能确认该掉话点是随机掉话的点或者固定掉话点，一般来说固定掉话点一定需要解决，而随机掉话点则需要根据掉话发生的概率来确定是否需要解决。
3.2.2. 话统分析流程
分析话统指标时，要先看RNC掉话指标，掌握了网络运行的整体情况。同时对关注的小区针对性地分析，按小区统计得到更详细的掉话指标。分析时可使用话统分析工具得到不同业务的掉话情况以及大致的掉话原因。
话统分析应获得指标明显异常的小区分析，如果小区以前KPI良好，此时很可能是版本、硬件、传输、天馈或者数据出了问题导致的异常，可以结合告警首先从这几个方面检查。如无明显异常，根据指标将各扇区载频进行统计分类，可整理出各重点指标较差小区列表，对于这些小区进一步细分话统指标（如分析更多相关指标，分析小时间间隔，分析可能引起掉话的指标，如切换指标等等），同时结合CHR看掉话的原因。实际分析解决问题时，在重点抓住某个指标分析的同时需要结合其他指标一起分析。需要说明的是话统只有话务量达到一定程度时，指标数值才具有指导意义。例如，出现掉话率为50%并不就代表网络差，只有在呼叫次数、呼叫成功次数、掉话总次数的绝对值都已具备统计意义时，这个数值才具有意义。
话统分析流程可以简述如下： （1）分析RNC掉话率
RNC掉话率统计RNC触发释放的各业务RAB个数，主要包括两个方面：（1）业务建立成功后，RNC向CN发送RAB RELEASE REQUEST消息。（2）业务建立成功后，RNC向CN发送IU RELEASE REQUEST消息，其后收到CN发送的IU RELEASE COMMAND。 （2）分析小区的掉话率指标
上述只是对整个网络分析，我们可分析小区掉话率指标，主要需要分析小区“AMR掉话率”、“VP掉话率”、“PS掉话率”。对所有小区分别用以上的指标进行排序，选择指标特别差的小区或者最差的一些小区，帅选出TOPN最差小区，进一步分析掉话原因。
AMR掉话率：RNC请求释放的话音(12.2)业务RAB 数目/ 话音(12.2)业务RAB建立成功的RAB 数目*100%
VP掉话率：RNC请求释放的视频电话业务RAB 数目/ 视频电话业务RAB建立
成功的RAB 数目*100%
为分析不同速率的PS掉话情况，可分析指标
RNC请求释放的PS64/64业务RAB 数目/ PS64/64业务RAB建立成功的RAB 数目*100%
RNC请求释放的PS128/64业务RAB 数目/ PS128/64业务RAB建立成功的RAB 数目*100%
RNC请求释放的PS384/64业务RAB 数目/ PS384/64业务RAB建立成功的RAB 数目*100%
通过上述这些掉话率的分析，我们可获得不同业务及其速率在网络中的性能，可获得切换掉话情况。重要的是通过这一步可获得指标较差的小区以及时间段。 （3）分析小区掉话原因
在话统分析中需要分析引起掉话的主要原因，主要指标如下：
失败原因
分析思路
OM干预 RAB抢占导致的原因
操作维护工作导致的掉话
高优先级抢占引起的CS链路释放，这种掉话在负载和资源不足的时候发生，根据发生的次数确定是否扩容
UTRAN产生的原因 小区中UTRAN产生的原因导致链路异常释放。这种情况一般对应着处理异常，需要通过CHR进一步分析
上行同步失败 上行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致UE异常关闭发射机或者上行解调失步
下行同步失败 下行链路失步引起的异常释放。这种情况主要是由于覆盖质量不好（包括邻区漏配、切换区小等情况），导致UE异常关闭发射机或者上行解调失步
UU口无响应 其他RF原因 AAL2链路异常
UE空口无响应系统发出的命令，覆盖不好导致 射频原因，均属于覆盖质量不好
RNC发现IU CS接口AAL2 Path异常，发起了异常释放，可能为传输设备异常，已知问题有RB建立过程中马上正常释放被话统统计为该原因异常释放
GTPU异常 其他原因
RNC发现IU PS接口GTPU异常，发起了异常释放，可能是设备故障 异常原因掉话，需结合RNC日志进行分析
可以将这些指标按照前面章节的分类，将其分为空口原因（RF、流程超时）、非空口原因（硬件故障、传输故障、用户干预等），从而对网络有个总体把握，得到影响网络的主要因素。
（4）检查小区是否异常
如果小区以前KPI正常，可检查小区的告警，排除小区异常方面的原因。 （5）通过路测重现问题
由于话统给出了趋势，并给出了可能的问题，具体问题的定位和分析还需要结合路测或者针对小区的CHR分析来进行。对于问题小区，一般都需要安排针对小区进行路测，跟踪手机侧和RNC的信令流程进行分析，详细分析方法请参见路测数据分析流程。 3.2.3. 跟踪数据优化流程
跟踪数据分析包括单用户跟踪消息分析和性能监测，通常情况下，单用户消息结合数据采集工具记录的UE侧数据，能够基本上定位一些掉话问题；对于更加复杂的问题，需要配合CHR和性能监测来综合分析。
也有一些商用手机的问题或者重点用户的问题，没有手机侧记录的消息，需要通过从单用户跟踪数据来分析和定位。单用户跟踪除了记录单用户的信令消息（Iu，Iur，Iub，Uu），