GSM掉话浅析
1、前言
掉话是移动网络最常见的故障之一。本文讨论了GSM移动网络的掉话产生的原因、机制以及和掉话密切相关的无线参数。本文只是抛砖引玉，如内容有不适之处，还请大家指正。
2、掉话产生的原因
所谓掉话就是通话的异常中断,要分析掉话产生的根本原因，首先回顾一下2G移动网络的结构模型，见下图：
参见上图，在GSM移动网络中，语音流的流程是MS—BTS—BSC—MSC—MSC—BSC—BTS—MS。以上流程中任何一个接口、任何一个网元发生问题均会导致掉话。从网元的可靠性来看，MSC＞BSC＞BTS（由于MS不在网络优化工程师的控制范围之内，在此就将其忽略，但实际当中，有些问题就是由故障MS导致的）。对于接口来说，可靠性是E接口＞A接口＞Abis接口＞Um接口。根据以上分析和实际的情况，可以说由于用户终端的移动性和无线传播的不确定性，大部分掉话发生在空中接口。另外常见的是由于基站和Abis口的故障导致的大量掉话。
3、掉话机制
3.1空口
根据GSM协议04.18、05.08、04.06，空口掉话（通话异常中断）的机制是:
1) 基于层1（物理层）的接收情况。对于MS就是基于解调下行SACCH消息的成功率。
对于BSS基于上行SACCH出错率，或基于RXLEV/RXQUAL测量值。大部分厂家使用SACCH出错率
2）主信令链路上的层2（数据链路层）的故障。对于TCH，主信令链路只指FACCH。
因此SACCH信道上数据链路层故障不导致掉话。数据链路层故障具体有以下14种情况：
- timer T200 expired (N200 +1) times: perform abnormal release;
- re-establishment request;
- unsolicited UA response;
- unsolicited DM response;
- unsolicited DM response, multiple frame established state: perform abnormal release;
- unsolicited supervisory response;
- sequence error: perform abnormal release;
- U frame with incorrect parameters;
- S frame with incorrect parameters;
- I frame with incorrect use of M bit;
- I frame with incorrect length;
- frame not implemented;
- SABM command, multiple frame established state;
- SABM command with information field not allowed in this state
其实04.60定义的数据链路层故障还有以下两种：
- short L2 header type 1 not supported;
- short L2 header type 1 not applicable;
不过这两种故障发生在数据链路层的非确认模式，根据协议，这两种故障不导致掉话。
3）切换失败重建也失败
对于终端用户来说，切换失败重建也失败就意味着掉话，但对于运营商OMC的话务统计来说，并不一定全统计为掉话。在某些情况下的“出BSC切换失败重建也失败”就不统计为掉话。如等待切换完成时收到MSC发出的CLEAR COMMAND消息，且清除原因不是切
换成功，此时BSC统计为“出BSC切换失败重建也失败”，但由于话统中的掉话次数是由BSC给MSC发“清除请求”（Clear Request）的消息来统计的，因此这种“出BSC切换失败重建也失败”不统计为掉话，但用户感知为掉话。相关案例可以参见之后的案例“MSC参数配置问题导致大量出BSC切换失败重建也失败”。
3.2 Abis接口
Abis接口的故障也会导致掉话，根据《网络规划GSM技术支持问题答复汇编(第1-40期分类汇总)》，对于华为GSM设备，Abis接口在LAPD断链后会启动1个6秒的定时器，定时器到时后，如LAPD仍未恢复，则清除该RSL对应载频上的所有通话。
3.3 A接口
A接口的故障也会导致通话异常释放。华为GSM BSC话统中的“TCH占用时A接口失败次数”反应了A接口的故障情况。其中一些类型的故障如SCCP断链会导致通话异常释放，但由于话统中的掉话次数是由BSC给MSC发“清除请求”（Clear Request）的消息来统计的，所以在话统中这种掉话并没有被统计。
3.4 设备故障
BTS和BSC的故障也会导致掉话。如BTS的功放突然关断，BSC的产品BUG都会导致大量掉话。
4、话统里的掉话统计
联通：
掉话次数定义:本地区无线子系统所有原因引起的业务信道掉话，包括正常信道丢失及各种切换等原因引起的话音掉话(含半速率)。
触发点:统计ASSIGNMENT COMPLETE消息之后的CLEAR REQUEST消息，以及HANDOVER COMPLETE消息之后的CLEAR REQUEST消息。统计点为BSC。
移动：
忙时话音信道掉话总次数=在指配话音信道完成（即Assignment Complete）后由于各种原因导致的掉话，统计无线侧的“Clear Request”消息。
可见移动、联通KPI中的掉话次数统计都是由手机成功占用TCH信道后的“Clear Request”触发的。因此话统中的掉话次数是小于实际网络的掉话次数的。
5、掉话后手机和BSS的操作
手机侧。当手机根据空口的掉话机制检测到掉话后将发起本地释放，由于是本地释放，手机掉话后，释放无线信道时并不通知网络侧。因此当时网络侧并不能马上知晓手机已掉话。但由于手机本地释放后不再发射上行信号，网络侧根据自己的掉话机制不久也会检测到掉话。
BSS。BSS检测到无线链路故障后将去激活SACCH信道（停止在SACCH信道上的发射），同时启动定时器T3109，等T3109超时后，BSS就可以把相关的无线资源分配给其它的用户。至于BSS检测到掉话后是否会通知手机释放信道，协议并未明确规定这点。公司GSM较老版本的做法是BSS检测到掉话后会给手机发channel release消息指示手机释放无线信道。而较新的版本在BSS检测到掉话后不给手机发channel release消息，因为此时认为无线环境恶化，手机无法收到基站的消息，或者手机早已掉话
6、和掉话相关的无线参数
RADIO_LINK_TIMEOUT（无线链路失效定时器）
移动台在BCCH的系统消息3以及SACCH信道的系统消息6中获知当前小区的RADIO_LINK_TIMEOUT（无线链路失效定时器）。在信道建立之初，移动台将radio link counter初始化为RADIO_LINK_TIMEOUT。每当移动台切往一个新小区，在获知新小区的RADIO_LINK_TIMEOUT后radio link counter就初始化为该值。因此切换可以迟滞和减少掉话。
SACCH复帧数
SACCH复帧数是华为GSM采用的上行掉话机制。当BTS开始收到SACCH发来的测量报告时，将判断无线链路故障的计数器置为该参数。
T200
对于数据链路层的”timer T200 expired (N200 +1) times”导致的掉话，可以增大FACCH 信道的T200来减少这种掉话。由于SACCH信道上数据链路层故障不导致掉话，因此增大SACCH信道的T200不能减少掉话。
T3103和T8
在切换流程中，协议规定当源小区发出切换命令后和在新信道上收到手机的SABM帧前，BSS会忽略层1和层2的无线链路故障。此时BSS的掉话机制就是T3103超时和T8超时（对于BSC间切换）。因此增大T3103和T8可以减少掉话。
T305和T308
减小T305和T308这两个MSC定时器可以减少话统中的掉话次数。尤其在SACCH复帧数和T3103、T8设置较大时。其原理就是在无线链路异常时，由于对端无法忍受通话质量而挂机时，使MSC尽快给本方发清除命令（clear command），这样本方BSC由于没有发送clear request，所以就不统计掉话。
T3109
T3109的设置对掉话次数没有影响，但设置过小会导致空口的串话。其道理如下：如用户A在通话过程中由于上行链路质量差触发了BSS侧的掉话，BSS去激活SACCH信道，同时启动定时器T3109，等T3109超时后，将用户A占用的无线资源（频点、时隙）分配
给了B用户，B用户呼叫建立成功后和C用户进行通话。而此时A用户由于下行的无线链路计时器还没有到零，还在监听原属于自己的无线资源。因此A用户就可以听到C用户讲话，甚至这两个用户还可以通话，从而导致串话。
对于这种串话，目前的解决措施有：
1）设置T3109大于RADIO_LINK_TIMEOUT。保证T3109超时前，手机A可以检测到无线链路故障而自己释放信道。
2）MSC开启加密功能。开启加密功能后，语音码流在交织后会和加密块进行模2加。由于加密块和用户的Ki相关，因此A用户就无法听到针对B用户的下行语音。
3）如果BSS检测到上行掉话后给手机发channel release消息通知手机释放无线信道，在一定程度上也可以避免空口串话。
7、案例
以下3个掉话案例是在日常的工作中遇到的比较特殊的掉话，其最终的掉话原因都非无线网优原因。但做为网优工程师将掉话原因准确隔离定位到网元或设备故障上，并及时推动解决就可以说基本完成了本职任务。
7.1 MSC参数配置问题导致大量出BSC切换失败且重建也失败
问题描述
陕西汉中移动与安康移动采用公司G9软交换，组网结构为大本地网下的两个小本地网。即汉中移动与安康移动各自有MGW，而MSC SERVER在咸阳。由于两个MGW之间没有直达承载电路，因此汉中移动与安康移动的切换等效为MSC间的切换。自从汉中移动与安康移动做了边界切换后。话统显示汉中至安康的出BSC切换全部失败且重建也失败，即全部掉话。用户也强烈投诉在问题区域频繁掉话。
问题分析
出BSC切换全部失败一般是外部小区数据有误。仔细核对BSC外部小区和交换切换数据配置，未发现问题。并且很奇怪的是出BSC切换失败后，为什么重建也全部失败？为定位此问题，分别在汉中和安康进行了A接口跟踪。汉中至安康切换时，安康BSC的A接口信令如下：
可见BSC间切换时，手机实际已成功接入安康基站，并且在A接口发送了handover complete消息，但6秒后就被MSC发来的clear command释放掉，释放原因为Equipment failure。而汉中BSC的A接口切换流程如下：
可见汉中至安康BSC间切换时，汉中BSC在收到MSC的切换命令7秒后也收到交换的清除命令clear command，原因值为Radio interface failure。
至此汉中至安康的出BSC切换全部失败且重建也失败的原因大致就清楚了：BSC间切换时手机其实已成功切换至安康，但由于某种原因在每次切换成功6秒后，MSC就给安康BSC发出clear command,原因值为equipment failure，导致BSC释放信道，用户感受为掉话。同时MSC也给汉中BSC发clear command, 原因值为 radio interface fail，导致汉中BSC统计为出BSC切换失败（BSC间切换时，源BSC收到原因值为handover success的clear command时，统计为出BSC切换成功），并且由于手机是被MSC释放掉的，因此也不会在原小区重建。导致汉中BSC又统计为重建失败。
由于是MSC主动发起的清除，因此怀疑是MSC的问题。请办事处交换工程师排查MSC 的问题。经排查，发现交换侧没有加切换号码处理命令ADD HDOVPROC。由于MSC为区分漫游号码和切换号码，在内部处理时给切换号码加了个前缀D。而在MSC间切换时，要建立MSC间的承载电路，此时要进行切换号码分析。由于没有加切换号码处理命令ADD HDOVPROC，导致局间建立承载的消息IAM中携带的切换号码的前缀D没有去掉。对端局不能识别此号码导致承载电路建立失败，这样就造成切换流程可以走通，但由于无局间话音承载电路，切换成功后数秒就被交换释放掉了。
解决措施
交换侧加切换号码处理命令ADD HDOVPROC后，问题解决。
7.2 异常功控导致掉话
问题描述
吴忠联通红寺堡1800M-1小区掉话率高。话统显示掉话类型均为“连接失败”。
问题分析
对该小区进行ABIS口信令跟踪，并用信令分析软件筛选出所有的“连接失败”，对每次“连接失败”进行“呼叫跟踪”。掉话前的测量报告显示掉话前上行电平和质量均很差，并且奇怪的是从层1的信息可看到，手机当时的MS POWER是3，也就是手机在该小区的发射功率比最大功率低6db。具体情况见下图：
一般1800M手机的最大发射功率为30dbm，对应MS Power level应为0。在开启上行功控的情况下，当上行电平或质量恶化时，BSS会指示手机不断的提升发射功率直至手机最大发射功率。在没有开启上行功控的情况，手机起呼接入小区后应一直以参数MS-TXPWR-MAX-CCH指示的功率发射。在切换接入目标小区时，手机应以切换命令指示的Power level发射，如“切换后功率预测算法”设置为否，则切换命令中的Power level为手机最大发射功率。
检查问题小区的参数设置，该小区开启上行功控，上行功控相关参数均采用系统默认配置、MS-TXPWR-MAX-CCH设置为0，“切换后功率预测算法”设置为否。可以确认问题小区参数设置没有问题。再仔细查看信令，注意到掉话多发生在手机切换入该小区后，并且预测量配置（PREPROC CONFIG）后的MS_POWER_CONTROL中的MS power的Power control 设置为3。具体情况见下图：
根据ABIS口协议，在MS_POWER_CONTROL消息里出现MS power parameters参数，则说明功控下移到BTS进行（公司GSM在打开测量报告预处理后功控下移到BTS进行），此时MS_POWER_CONTROL消息里的MS power指示MS可以使用的最大功率。至此可知手机用Power level 3发射是因为BSC的限制。并且因为该1800M小区切换层级设置的比900M低，手机在该小区覆盖较差的情况下也会切换至该小区，在上行发射功率不足的情况下就很容易导致上行质量差而掉话。
为验证是否是BSC产品问题导致测量报告预处理功能打开后MS发射功率受到限制。对该BSC（该BSC是BSC32，软件版本为C01）的其它小区进行了ABIS口信令跟踪。信令跟踪显示，1800M小区在切换占用后的MS_POWER_CONTROL消息里将MS power level 设置为3，而呼叫占用时正常。900M小区无论呼叫占用和切换占用均正常。1800M小区在关闭测量报告预处理功能后功控也正常。
问题解决
将此问题通过问题单反馈给研发后，研发初步分析后确认BSC有些问题，并要求现场做一些信息收集。但当时正好进行了一次BSC割接，问题小区割接到另一个BSC后不再出现此问题，而原来的BSC又搬迁至其它地市使用，因此该问题最终未确切定位。
7.3 产品问题导致掉话
问题描述
汉中移动正在将北电基站替换为华为基站。替换时频率和邻区均继承原网，其他参数采用公司建议值。
搬迁后掉话率异常偏高。话统数据显示“通话后的掉话次数”较少。即很多掉话发生在“
对掉话高的几个小区进行了ABIS信令跟踪，信令显示手机占用TCH不久后，上行质量就恶化至7，导致掉话。且掉话流程异常，BTS连续给BSC发送13个“连接失败”消息。如以下这次掉话：
从上图可见3：55：26手机发起呼叫。此时TA为1，手机距基站很近。
3：55：29秒TCH被激活。3：55：39秒的测量报告显示，上行电平为-76dbm，上行质量为0，如下图：
但3：55：42秒以后的测量报告就显示上行电平为-106dbm，质量为7。如下图
随后到3：56：6，BTS就连续给BSC发“连接失败”原因值为“无线链路失败”，见下图：
此时呼叫流程才走到“connect”。之后BSC发起本地释放，通话结束。
从下图可以清楚地看到上行电平、质量突然恶化的情况：
问题解决
由于大部分掉话都恰好发生在信令流程走到connect时，因此技术支持2线和3线很快也认定此问题属产品问题。问题转至研发后，研发迟迟未能定位，后来BSC和BTS经多次升级后，此种掉话明显减少。直至搬迁结束，此问题也未明确定位。