 |
善于提问，勤于回答，你也是专家
|
 |
问题已开启
(普通问题)
提问者:
• [请大佬帮忙看看这一题选择什么答案，谢谢]关于TDM eICIC .以下描述正确的是哪些项 2020-04-15
• TD-LTE仿真 2020-01-16
• 诺西 TDD室分开CA是否影响容量 2019-12-04
• 急急急，通宇4或6端口天线TDQ-182018DEH-65Fv04 和诺西FXEB RRU 怎么连接 2019-11-18
• 关于TDD与FDD重定向 2019-09-05
• TDLTE异频频点的从频带是什么？何时需要配置？ 2019-08-20
• 我国4G移动通信系统频谱TD-LTE在组网时主要使用的频段和5G频段是多少 2019-06-17
• TD-LTE在组网时主要使用的频段和5G频段是多少 2019-06-17
• TD-LTE仿真 2020-01-16
• 诺西 TDD室分开CA是否影响容量 2019-12-04
• 急急急，通宇4或6端口天线TDQ-182018DEH-65Fv04 和诺西FXEB RRU 怎么连接 2019-11-18
• 关于TDD与FDD重定向 2019-09-05
• TDLTE异频频点的从频带是什么？何时需要配置？ 2019-08-20
• 我国4G移动通信系统频谱TD-LTE在组网时主要使用的频段和5G频段是多少 2019-06-17
• TD-LTE在组网时主要使用的频段和5G频段是多少 2019-06-17
问题答案
( 6 )
RNC下发Iurelease这条信令就被定义为掉话/掉线，原因会有很多的，干扰、切换失败回滚掉话、弱覆盖掉话、等等有很多，有疑问可以发站内信，欢迎拍砖
回答者：
xinhaoqi
回答时间：2010-06-28 10:57
30
31
下面的是解决的办法，直接复制的
1 出现小区级掉话时，首先查看该小区是否有硬件故障告警，如果有，首先要求用服人员解决硬件故障问题。
2 检查切出成功率是否正常，如果切换成功率较低，检查邻区关系以及是否存在同频同码的情况。
² 邻小区关系中是否存在同频同扰码的现象，这种情况在路测中也可以发现，一般是在邻区表中出现两条相同的邻小区关系，这里需要注意的是业务同频同扰（能不能理解为辅载频相同的情况）的现象，它无法在路测中发现，一般需要对信令进行分析，此时虽然两个小区主载频异频，但measurement report却上报了1G 事件，针对这种情况需要通过修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查）
² 邻小区关系中是否存在同频同码组的现象，这种情况在路测中也可以发现，一般情况是它是影响到终端的测量结果，此时测量结果不准确，造成终端上报系统后系统判断错误，针对这种情况则需要修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查）
² 是否存在单边邻小区关系，如果存在，添加单边邻区，单边小区的检查可以使用NOP-T工具进行，也可以通过对性能统计指标中的小区对切换统计指标来检查。
² 是否存在异频邻小区个数过多的现象（异频邻区数超过8个），如果存在，删除不必要的邻区，这种情况可以使用NOP-T工具进行检查，也可以使用办公软件进行检查。
² 是否存在切换开关设置的问题（有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止）。如果存在，打开切换开关
² 切换相关的事件定义是否准确，不区引用是否正确，如果存在，修改引用
² PS切换失败是否存完整性算法问题，如果存在，将RNC、CN之间的完整性开关设成一致
² 是否存在邻区漏配的情况。需要用SCANNER路测发现是否存在漏配的情况。如果存在，添加邻区。
² 目标小区拥塞造成的掉话，由于目标小区的资源不足，而本小区的覆盖又越来越差，此时造成掉话。常见的错误代码为no_resource_available或RRM_CellOverload_Release
3 检查时隙转换点配置是否正确，是否存在交叉时隙干扰。如果存在，修改时隙转换点。
4 检查UP时隙和上行业务时隙的干扰电平，是否存在上行干扰导致掉话。如果存在，进行干扰排查
5 根据性能指标统计，如果PS域和CS域的BLER都比较高则有可能存在干扰，然后再结合载频时隙干扰统计指标来判断是否确实存在干扰，另外通过对信令的分析如存在干扰则一般信令流程正常，未有切换事件或其它事件，但RNC进行了IURELEASE，原因一般为无线链路的原因。（比如无线链路错误等），有时也会发生CELLUPDATE 原因为RLCunrecoverable error如果确实存在则需要现场排除，现场测试时如果存在干扰则有以下几个方面的显示
u C/I较差：系统内同频的干扰较为严重，发生掉话时会存在终端发射功率较高，的现象，同时覆盖也相对较好，表现在RSCP值上，一般都在-90dBm以上，另外一表现象就是起呼比较困难，而起呼成功后也很容易掉话
u 终端发射功率较高，基本上满功率发射，一般都在-20dBm以上
u 系统外的干扰造成的掉话同样具有终端发射功率较高的现象，也一般都都在-20dBm以上
u 系统外干扰造成掉话时也可以通过误块率指标进行判断，此时无论是进行CS业务还是进行PS业务，BLER都比较高，并且保持时间较长
u 系统外干扰语音业务判断，此时进行通话会出现断字、吞字、金属声等现象，比较难以进行通话。
6 通过对性能指标的统计，主要是对RRC连接成功率的统计，这其中的统计包括业务相关和非业务相关的统计，如果两种统计都较差，则有可能存在覆盖问题，此时可以检查CT数据中RRC CONNECTION REQUEST中的PCCPCH的值，则说明存在弱覆盖现象，需要进行功率参数、天线方向角、下倾角的调整。
7 如果上述都检查不出原因，可能是载波、时隙的隐性故障，此时可以尝试闭解载波时隙，或者强行闭载波、时隙观察掉话率的变化。
8 终端问题，一般是通过对大量的性能数据统计，发现掉话高的小区，然后依据小区性能数据分析信令，可以看出掉话常发生的用户，而后进行处理。目前常见的终端问题为UP同步存在问题，此时容易在切换时产生Ue_Operate_fail_physicalchannelfailure错误。
1 出现小区级掉话时，首先查看该小区是否有硬件故障告警，如果有，首先要求用服人员解决硬件故障问题。
2 检查切出成功率是否正常，如果切换成功率较低，检查邻区关系以及是否存在同频同码的情况。
² 邻小区关系中是否存在同频同扰码的现象，这种情况在路测中也可以发现，一般是在邻区表中出现两条相同的邻小区关系，这里需要注意的是业务同频同扰（能不能理解为辅载频相同的情况）的现象，它无法在路测中发现，一般需要对信令进行分析，此时虽然两个小区主载频异频，但measurement report却上报了
² 邻小区关系中是否存在同频同码组的现象，这种情况在路测中也可以发现，一般情况是它是影响到终端的测量结果，此时测量结果不准确，造成终端上报系统后系统判断错误，针对这种情况则需要修改频点和扰码解决（可以通过系统自带的全局参数合法性检查工具进行检查）
² 是否存在单边邻小区关系，如果存在，添加单边邻区，单边小区的检查可以使用NOP-T工具进行，也可以通过对性能统计指标中的小区对切换统计指标来检查。
² 是否存在异频邻小区个数过多的现象（异频邻区数超过8个），如果存在，删除不必要的邻区，这种情况可以使用NOP-T工具进行检查，也可以使用办公软件进行检查。
² 是否存在切换开关设置的问题（有部分HOM开关可能被关掉或在外部小区定义中的切入开关设为禁止）。如果存在，打开切换开关
² 切换相关的事件定义是否准确，不区引用是否正确，如果存在，修改引用
² PS切换失败是否存完整性算法问题，如果存在，将RNC、CN之间的完整性开关设成一致
² 是否存在邻区漏配的情况。需要用SCANNER路测发现是否存在漏配的情况。如果存在，添加邻区。
² 目标小区拥塞造成的掉话，由于目标小区的资源不足，而本小区的覆盖又越来越差，此时造成掉话。常见的错误代码为no_resource_available或RRM_CellOverload_Release
3 检查时隙转换点配置是否正确，是否存在交叉时隙干扰。如果存在，修改时隙转换点。
4 检查UP时隙和上行业务时隙的干扰电平，是否存在上行干扰导致掉话。如果存在，进行干扰排查
5 根据性能指标统计，如果PS域和CS域的BLER都比较高则有可能存在干扰，然后再结合载频时隙干扰统计指标来判断是否确实存在干扰，另外通过对信令的分析如存在干扰则一般信令流程正常，未有切换事件或其它事件，但RNC进行了IURELEASE，原因一般为无线链路的原因。（比如无线链路错误等），有时也会发生CELLUPDATE 原因为RLCunrecoverable error如果确实存在则需要现场排除，现场测试时如果存在干扰则有以下几个方面的显示
u C/I较差：系统内同频的干扰较为严重，发生掉话时会存在终端发射功率较高，的现象，同时覆盖也相对较好，表现在RSCP值上，一般都在-90dBm以上，另外一表现象就是起呼比较困难，而起呼成功后也很容易掉话
u 终端发射功率较高，基本上满功率发射，一般都在-20dBm以上
u 系统外的干扰造成的掉话同样具有终端发射功率较高的现象，也一般都都在-20dBm以上
u 系统外干扰造成掉话时也可以通过误块率指标进行判断，此时无论是进行CS业务还是进行PS业务，BLER都比较高，并且保持时间较长
u 系统外干扰语音业务判断，此时进行通话会出现断字、吞字、金属声等现象，比较难以进行通话。
6 通过对性能指标的统计，主要是对RRC连接成功率的统计，这其中的统计包括业务相关和非业务相关的统计，如果两种统计都较差，则有可能存在覆盖问题，此时可以检查CT数据中RRC CONNECTION REQUEST中的PCCPCH的值，则说明存在弱覆盖现象，需要进行功率参数、天线方向角、下倾角的调整。
7 如果上述都检查不出原因，可能是载波、时隙的隐性故障，此时可以尝试闭解载波时隙，或者强行闭载波、时隙观察掉话率的变化。
8 终端问题，一般是通过对大量的性能数据统计，发现掉话高的小区，然后依据小区性能数据分析信令，可以看出掉话常发生的用户，而后进行处理。目前常见的终端问题为UP同步存在问题，此时容易在切换时产生Ue_Operate_fail_physicalchannelfailure错误。
xinhaoqi 2010-06-28 13:10
不错！
佳佳1073 2012-12-19 12:44
掉话率(CS)=( RNC 触发释放的CS域业务RAB的数目/ CS 域成功建立业务的 RAB 指配响应消息的数目)× 100%
掉话率(PS)= (RNC 触发释放的PS域业务RAB的数目/ PS 域成功建立业务的 RAB 指配响应消息的数目)× 100%
掉话的原因如：弱覆盖、强干扰、切换失败引起的掉话(系统内&异系统)、手机或基站故障引起掉话...
具体来说：
1.1 覆盖差
TD网络覆盖指标主要是P-CCPCH的RSCP、C/I。通常所说的覆盖差，是指RSCP小于－100dBm。
对覆盖差问题进行分析是，通常要考虑上行覆盖和下行覆盖。上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：
如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RL failure，基本可以认为上行覆盖差导致的掉话。
如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。
在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。如果上下行严重不平衡，则应该初步判定为受限方向存在干扰。
确认覆盖的问题简单直接的方式是直接观察Scanner采集的数据，若最好小区的RSCP和C/I都很低，就可以认为是覆盖问题。
由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差，扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。
1.2 邻区漏配
一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：
方法一：观察掉话前UE记录的激活集C/I信息和Scanner记录的Best Server C/I信息，如果UE记录的C/I很差，而Scanner记录的Best Server C/I很好；同时检查Scanner记录Best Server扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中，如果测量控制的邻区列表中中没有扰码，那么可以确认是邻区漏配。
方法二：如果掉话后UE马上重新接入，如果UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。
方法三：有些UE会上报检测集（Detected Set ）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。
邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在3G掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。
1.3 切换掉话
切换导致掉话主要有两类原因：切换来不及或者乒乓切换。
从信令流程上CS业务表现为手机收不到激活集更新命令（物理信道重配置），PS业务也有可能收不到激活集更新命令，也有可能在切换之前先发生TRB复位。
从信号上看，切换来不及主要有以下现象：
1）拐角：源小区C/I陡降，目标小区C/I陡升（即突然出现就是很高的值）；
2）针尖：源小区C/I快速下降后一段时间后上升，目标小区出现短时间的陡升。
从信令流程上看，一般在掉话前手机上报了邻区的1g或者2a测量报告，RNC也收到了测量报告，并下发了激活集更新消息，但UE收不到激活集更新消息。
乒乓切换主要有以下两种现象：
1）主导小区变化快：2个或者多个小区交替成为主导小区，主导小区具有较好的RSCP和C/I每个小区成为主导小区的时间很短；
2）无主导小区：存在多个小区，RSCP正常而且相互之间差别不大，每个小区的C/I都很差。
从信令流程上看，一般可以看到1个小区刚刚删除，然后马上要求加入，此时收不到RNC下发的激活集更新命令导致失败。
解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1g事件的切换参数使切换更容易发生，或者配置Offset使目标小区能够提前发生切换；解决乒乓切换带来的掉话问题，可以调整天线使覆盖区域形成主导小区，也可以配置1g事件的切换参数减少乒乓的发生等方法来进行。
对于异频切换和系统间切换，在切换前需要进行异频或者异系统测量，测量启动太迟，可能导致手机来不及测量目标小区的信号，从而产生掉话，也可能手机完成了测量，但下发的异频或者异系统切换请求手机不能正常接收而导致掉话。
对于3G 2G系统间切换掉话的常见原因大概如下：
邻区漏配置，可以通过配置邻区解决；
信号变化太快导致掉话；
手机问题，比如UE回切换失败或者UE没有上报异系统测量报告导致掉话等；
物理信道重配置时发生最优小区发生变更导致掉话，需要产品算法进行优化；
异系统小区配置过多导致掉话，可以通过优化邻区数目解决；
LAC区配置错误导致的掉话，可以通过数据配置检查解决。
1.4 干扰掉话
下行和上行的干扰都会导致掉话。一般情况下，对于下行，当激活集P-CCPCH RSCP大于-85dB，而激活集综合C/I小于-9dB产生了掉话，基本上可以认为是下行干扰的问题（当切换不及时的时候，也可能出现服务小区RSCP信号很好，但C/I很差；但此时监测集小区RSCP和C/I都很好）；对于上行RTWP比正常值（-107～-105）超过10dB，干扰时间超过2～3s，就有可能造成掉话，需要重点解决。
下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现激活集替换或者最优小区发生变化，通常当激活集综合质量不好（P-CCPCH的C/I都在-3dB左右波动），容易出现切换失败导致SRB复位，也可能出现TRB复位。
上行的干扰增加了连接模式的手机上行发射功率，从而产生过高的BLER导致SRB或者TRB复位或者由于失步导致掉话。另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。
通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射功率都会接近最大值。但当干扰存在时，如果是下行的干扰，往往出现上行发射功率很小或者BLER收敛的情况，但下行发射功率达到最大值同时也伴随着下行BLER不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。
1.5 流程交互失败
一些需要信令交互的流程，如AMR控制、UE的状态迁移等，常常会由于信号的原因，手机支持方面的原因或者RAN设备和手机的配合问题，导致流程失败，最后导致掉话。还有一种特殊情况就是在流程的交互过程中，如RB建立，RB重配置等流程中，切换的测量报告不能及时处理，导致信号变差而掉话。
这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。
1.6 异常
在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。比如：NodeB异常引起同步失败，导致的链路不停增加和删除,手机不上报1g测量报告导致掉话.这里需要重点注意的是测试手机异常死机引起的掉话问题，一般在拨测过程中容易出现这个问题，具体表现为路测记录的数据中有一段时间没有手机上报的信息。
掉话率(PS)= (RNC 触发释放的PS域业务RAB的数目/ PS 域成功建立业务的 RAB 指配响应消息的数目)× 100%
掉话的原因如：弱覆盖、强干扰、切换失败引起的掉话(系统内&异系统)、手机或基站故障引起掉话...
具体来说：
1.1 覆盖差
TD网络覆盖指标主要是P-CCPCH的RSCP、C/I。通常所说的覆盖差，是指RSCP小于－100dBm。
对覆盖差问题进行分析是，通常要考虑上行覆盖和下行覆盖。上行覆盖差还是下行覆盖差的问题需要通过掉话前上行或者下行的专用信道功率来确认，需要采用以下的方法来确认：
如果掉话前的上行发射功率达到最大值，并且上行的BLER也很差或者从RNC记录的单用户跟踪上看到NodeB上报RL failure，基本可以认为上行覆盖差导致的掉话。
如果掉话前，下行发射功率达到最大值，并且下行的BLER很差，基本可以认为是下行覆盖不行导致的掉话。
在合理的链路平衡情况下，而且上下行没有干扰的情况下，上行和下行发射功率会同时受限，此时不一定要严格区分哪一方先出现受限。如果上下行严重不平衡，则应该初步判定为受限方向存在干扰。
确认覆盖的问题简单直接的方式是直接观察Scanner采集的数据，若最好小区的RSCP和C/I都很低，就可以认为是覆盖问题。
由于缺站、扇区接错、功放故障导致站关闭等原因都会导致覆盖差，在一些室内，由于过大的穿透损耗也会导致覆盖太差，扇区接错或者站点由于故障原因关闭等容易在优化过程中出现，表现为其他小区在掉话点的覆盖差，需要注意分析区别。
1.2 邻区漏配
一般来讲，初期优化过程掉话占大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下的办法来确认是否为同频邻区漏配：
方法一：观察掉话前UE记录的激活集C/I信息和Scanner记录的Best Server C/I信息，如果UE记录的C/I很差，而Scanner记录的Best Server C/I很好；同时检查Scanner记录Best Server扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中，如果测量控制的邻区列表中中没有扰码，那么可以确认是邻区漏配。
方法二：如果掉话后UE马上重新接入，如果UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。
方法三：有些UE会上报检测集（Detected Set ）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。
邻区漏配导致的掉话也包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在3G掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。
1.3 切换掉话
切换导致掉话主要有两类原因：切换来不及或者乒乓切换。
从信令流程上CS业务表现为手机收不到激活集更新命令（物理信道重配置），PS业务也有可能收不到激活集更新命令，也有可能在切换之前先发生TRB复位。
从信号上看，切换来不及主要有以下现象：
1）拐角：源小区C/I陡降，目标小区C/I陡升（即突然出现就是很高的值）；
2）针尖：源小区C/I快速下降后一段时间后上升，目标小区出现短时间的陡升。
从信令流程上看，一般在掉话前手机上报了邻区的1g或者2a测量报告，RNC也收到了测量报告，并下发了激活集更新消息，但UE收不到激活集更新消息。
乒乓切换主要有以下两种现象：
1）主导小区变化快：2个或者多个小区交替成为主导小区，主导小区具有较好的RSCP和C/I每个小区成为主导小区的时间很短；
2）无主导小区：存在多个小区，RSCP正常而且相互之间差别不大，每个小区的C/I都很差。
从信令流程上看，一般可以看到1个小区刚刚删除，然后马上要求加入，此时收不到RNC下发的激活集更新命令导致失败。
解决切换来不及导致的掉话，可以通过调整天线扩大切换区，也可以配置1g事件的切换参数使切换更容易发生，或者配置Offset使目标小区能够提前发生切换；解决乒乓切换带来的掉话问题，可以调整天线使覆盖区域形成主导小区，也可以配置1g事件的切换参数减少乒乓的发生等方法来进行。
对于异频切换和系统间切换，在切换前需要进行异频或者异系统测量，测量启动太迟，可能导致手机来不及测量目标小区的信号，从而产生掉话，也可能手机完成了测量，但下发的异频或者异系统切换请求手机不能正常接收而导致掉话。
对于3G 2G系统间切换掉话的常见原因大概如下：
邻区漏配置，可以通过配置邻区解决；
信号变化太快导致掉话；
手机问题，比如UE回切换失败或者UE没有上报异系统测量报告导致掉话等；
物理信道重配置时发生最优小区发生变更导致掉话，需要产品算法进行优化；
异系统小区配置过多导致掉话，可以通过优化邻区数目解决；
LAC区配置错误导致的掉话，可以通过数据配置检查解决。
1.4 干扰掉话
下行和上行的干扰都会导致掉话。一般情况下，对于下行，当激活集P-CCPCH RSCP大于-85dB，而激活集综合C/I小于-9dB产生了掉话，基本上可以认为是下行干扰的问题（当切换不及时的时候，也可能出现服务小区RSCP信号很好，但C/I很差；但此时监测集小区RSCP和C/I都很好）；对于上行RTWP比正常值（-107～-105）超过10dB，干扰时间超过2～3s，就有可能造成掉话，需要重点解决。
下行的干扰通常是指导频污染，指覆盖地区存在3个以上的小区满足切换条件，由于信号的波动常常出现激活集替换或者最优小区发生变化，通常当激活集综合质量不好（P-CCPCH的C/I都在-3dB左右波动），容易出现切换失败导致SRB复位，也可能出现TRB复位。
上行的干扰增加了连接模式的手机上行发射功率，从而产生过高的BLER导致SRB或者TRB复位或者由于失步导致掉话。另外，在切换的时候，新建链路由于上行干扰问题导致链路不能同步，从而造成该小区的切换成功率低，或者造成切换失败而导致掉话。
通常在没有干扰的情况下，上下行是平衡的，也就是说掉话前上下行的发射功率都会接近最大值。但当干扰存在时，如果是下行的干扰，往往出现上行发射功率很小或者BLER收敛的情况，但下行发射功率达到最大值同时也伴随着下行BLER不收敛；对于上行干扰，会存在同样的表现，在实际分析可以通过这个方法来区分。
1.5 流程交互失败
一些需要信令交互的流程，如AMR控制、UE的状态迁移等，常常会由于信号的原因，手机支持方面的原因或者RAN设备和手机的配合问题，导致流程失败，最后导致掉话。还有一种特殊情况就是在流程的交互过程中，如RB建立，RB重配置等流程中，切换的测量报告不能及时处理，导致信号变差而掉话。
这类问题需要针对特定的流程和手机进行分析，没有一般性的处理方法。
1.6 异常
在排除了以上的原因之后，其他的掉话一般需要怀疑设备的问题，需要通过查看设备的日志，告警等进一步来分析掉话原因。比如：NodeB异常引起同步失败，导致的链路不停增加和删除,手机不上报1g测量报告导致掉话.这里需要重点注意的是测试手机异常死机引起的掉话问题，一般在拨测过程中容易出现这个问题，具体表现为路测记录的数据中有一段时间没有手机上报的信息。
回答者：
tscinter
回答时间：2010-06-28 11:16
30
36
资料挺详细的，谢了
华山令狐冲 2010-06-28 13:22
资料很好，谢谢分享。。
kjq110 2010-10-19 10:14
很好 整理的很详细
81808836 2011-07-06 11:06
掉话有三种定义方式
1）收到任何的BCH消息（即系统消息）
2）收到RRC Release消息且释放的原因值为Not Normal
3）收到CC Disconnect，CC Release Complete，CC Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。
1）收到任何的BCH消息（即系统消息）
2）收到RRC Release消息且释放的原因值为Not Normal
3）收到CC Disconnect，CC Release Complete，CC Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。
回答者：
mao_mao
回答时间：2010-06-28 11:17
34
33
学习下
回答者：
guangdao
回答时间：2010-06-28 11:17
37
33
导致掉话有下面几种原因：
1、干扰
2、弱覆盖或者过覆盖
3、设备告警
4、参数设置
5、网络资源
等等
1、干扰
2、弱覆盖或者过覆盖
3、设备告警
4、参数设置
5、网络资源
等等
回答者：
mao_mao
回答时间：2010-06-28 11:17
30
34
掉话的定义：手机收到Disconnect/Release信令视为通话正常结束，在手机没有发Disconnect信令或没收到网络下发Disconnect/Release信令情况下，手机回到idle 状态，则视为一次掉话。（摘自最新的移动测试规范，绝对正确）
掌握掉话常见原因及处理方法，逐一排查，并最终定位解决（个人的总结，如有不当，欢迎指教）
掉话原因分析：
1设备异常导致的掉话（查看告警）；
2覆盖原因（弱覆盖、后瓣覆盖、越区覆盖及无主覆盖等）导致的掉话；
3干扰导致的掉话（同频干扰、上下行交叉时隙干扰等）；
4 切换失败导致掉话（邻区拥塞无法触发切换、漏配邻区导致的切换失败进而掉话、切换参数设置不合理导致切换过早或者过晚）；
5 呼叫重建不支持导致掉话（查看RNC侧信令文件跟踪里IU Release中携带的原因进行判断）；
6 同频同码导致掉话或同频同时隙导致的掉话；
7 同频同时隙导致的掉话等。
8 其他原因如手机终端出现死机等。
回答者：
TD夏夏
回答时间：2010-06-28 11:19
32
34
我可是一个字一个字的打上去的 辛苦啊
TD夏夏 2010-06-28 11:20
兄台辛苦了，大家共同进步么
华山令狐冲 2010-06-28 13:02
兄台辛苦了
王建生 2010-12-20 16:34
简单明了，谢谢兄弟！
| 联系我们 - 问通信专家 | Powered by MSCBSC 移动通信网 © 2006 - |