掉话分析v2.docx

掉话分析v2.docx

《掉话分析v2.docx》由会员分享，可在线阅读，更多相关《掉话分析v2.docx（28页珍藏版）》请在冰豆网上搜索。

掉话分析v2

掉话分析（r8）

一、概述

深圳移动分公司本地网规划与优化服务的掉话研究的主要内容是掉话计数器跳转的原因及话务统计掉话率的真实性，并分析各种类型掉话的原因。

主要结论如下：

●BSC掉话计数器跳转非常明确，只有实际掉话时才会跳转。

话务统计的掉话率也是真实的，数量与BSC内部实际掉话相符。

●突然掉话（SUDLOS）是超TA、弱信号与质量差三个条件都不符合的掉话，而掉话原因是太多测量报告丢失，或T200定时器超时等。

●切换掉话只计源BSC的一次掉话。

研究结果也确认各种原因与实际情况关系，其中原因主要是MSLOST。

●网络中其它原因（OtherReason）的掉话原因主要是MSC与BSC之间的切换掉话及由于交换硬件所引起的掉话。

●BSC的4个阀值：

LOWSSDL、LOWSSUL、BADQDL与BADQUL，对掉话计数器的跳转起了决定性的作用，而阀值需根据BSC信号强度分布设置。

●半速率TCH在比较差的无线环境下有可能出现比全速率TCH更高的掉话率。

二、BSC掉话分析研究

掉话是指通话的非正常终止，掉话率是指掉话次数在接通总次数中的比例，它是衡量网络可用性的一个重要指标。

无线网络的掉话可分为两种：

一种是在SDCCH信道上的掉话，另一种是在TCH信道上的掉话。

SDCCH掉话是指在BSC给MS分配了SDCCH信道，而TCH信道还没有分配成功期间发生的掉话。

TCH掉话是指在BSC给MS成功分配了TCH信道后，发生的不正常TCH释放。

BSC掉话研究主要研究发生掉话的原因和掉话统计真实性。

2.1呼叫连接释放过程的分析

正常情况下，若主叫先挂机，则MS利用FACCH信道向MSC发出“DISCONNECT”消息。

MSC收到该信息后，随即清除业务信道在网络中的连接，并向MS发出“RELEASE”消息，释放CC层的连接。

MS收到该信息后将停止所有CC连接定时器，释放MM连接，并向MSC发出“RELEASECOMPLETE”信息。

MSC就会释放MM层连接，然后向BSC发出“CLEARCOMMAND”的消息来要求释放SCCP信令链路。

在该信息中携带着此次呼叫清除的原因。

例如是因为“Callcontrol”而清除还是因为“Handoversuccessful”而清除等等。

BSC收到后，将释放RR连接。

为了保证上下行链路都能及时地拆除，BSC在向MS发出“CHANNELRELEASE”信息要求拆除上行链路的同时，还要向BTS发出“DEACTIVESACCH”的消息，要求释放下行的随路信令。

BTS停止发送SACCH下行链路的系统信息后，即向BSC发出“DEACTIVESACCHACK”的消息。

BSC收到后，随即向BTS发出“RFCHANNELRELEASE”要求释放TCH。

当收到BTS返回的“RFCHANNELRELEASEACK”消息后，BSC就认为该信道资源已空闲并可用于再分配了。

此时BSC将向MSC发出“CLEARCOMPLETE”消息，表明无线链路已清除完毕。

MSC就会完成对SCCP连接的释放，到此为止该信令流程完毕。

图1正常的呼叫连接释放流程

非正常呼叫连接释放过程与正常呼叫连接释放过程的区别是：

由BSC首先发出“CLEARREQUEST”的消息。

这是因为当无线接口消息失败、无线链路失败或因设备故障等原因而导致呼叫进程非正常性的释放，则由BSC向MSC发出“CLEARREQUEST”消息。

如果掉话不是由无线侧引起，则BSC不会向MSC发送“CLEARREQUEST”消息，而是MSC向BSC发送“CLEARCOMMAND”消息，消息中的呼叫清除原因不再是“Callcontrol”或者“Handoversuccessful”，而是其它原因。

2.2关于掉话计数器的分析

根据中国移动集团公司对掉话的定义：

掉话率指标定义：

无线系统掉话率包括所有原因（用户线侧的原因和网络侧的原因）引起的掉话，该指标表示了网络的可保持性能。

在用户所要求通话的持续时间内，网络应有连续为用户提供服务的能力。

掉话率为忙时掉话次数与忙时系统应答次数之比，即：

掉话率＝（忙时话音信道掉话总次数/忙时系统应答总次数）×100%

其中，掉话次数的定义为无线侧统计“CLEARREQUEST”消息，忙时话音信道掉话总次数是指在指配话音信道完成（即AssignmentComplete）后由于各种原因导致的掉话。

忙时系统应答次数的定义为交换侧统计“ANM”消息。

该项指标要求在无线侧统计爱立信交换机对掉话总次数（TFNDROP）的统计定义是：

●当BSC向MSC发“CLEARREQUEST”时，会使TFNDROP加一；

●或者是BSC未向MSC发“CLEARREQUEST”，却收到MSC送来的“CLEARCOMMAND”信息，其中附带的原因不是“Callcontrol”或者“Handoversuccessful”，也会使TFNDROP加一。

在爱立信交换机里，当掉话产生即CLEARREQUEST发送到MSC时，交换机将会以下面的优先顺序去检查紧急状态（Urgencystate），从而判断应该增加哪一个掉话计数器：

●超TA值（ExcessiveTA）

●上下行弱信号（Lowsignalstrengthindownlinkand/oruplink）

●上下行质量差（Badqualityindownlinkand/oruplink）

●突然掉话（Suddenlossofconnection）

图2掉话计数器跳转流程

超TA值（ExcessiveTA）：

当掉话发生时，TA值大于或等于小区定义的参数TALIM、TFDISTA或THDISTA，这个掉话计数器就会加一，同时TFNDROP加一。

上下行弱信号（Lowsignalstrengthindownlinkand/oruplink）：

当掉话发生时的上行信号的弱信号强度（lowsignalstrength）小于BSC定义的参数LOWSSUL或下行信号的弱信号强度小于BSC定义的参数LOWSSDL，以下的弱信号计数器之一就会加一：

Underlaid：

TFDISSUL，TFDISSSDL，TFDISSSBL

Overlaid：

TFDISSULSUB，TFDISSSDLSUB，TFDISSSBLSUB

Underlaid：

THDISSSUL，THDISSSDL，THDISSSBL

Overlaid：

THDISSSULSUB，THDISSSDLSUB，THDISSSBLSUB

上下行质量差（Badqualityindownlinkand/oruplink）：

当这个掉话发生时的上行信号的质差（Badquality）小于BSC定义的参数BADQUL或下行信号的质差小于BSC定义的参数BADQDL，以下的其中一个质差计数器就会加一：

Underlaid：

TFDISQAUL，TFDISQADL，TFDISQABL

Overlaid：

TFDISQAULSUB，TFDISQADLSUB，TFDISQABLSUB

Underlaid：

THDISQAUL，THDISQADL，THDISQABL

Overlaid：

THDISQAULSUB，THDISQADLSUB，THDISQABLSUB

突然丢失掉话（Suddenlossofconnection）：

当MS因为测量结果丢失，但又不符合以上三种情况时的掉话，则会使以下的其中一个质差计数器加一：

Underlaid：

TFSUDLOS，THSUDLOS

Overlaid：

TFSUDLOSSUB，THSUDLOSSUB

2.3使用BSC信号RMCONRELINIT2追踪掉话原因

图3BSC内部掉话信号流程图

上图是爱立信BSC内部关于掉话的的信号流程图。

从图中可以看出当发生掉话时RP（TRH）向CP发出“DISCONNECTREQUEST”，经过RQRCQS处理后传到RMHBI，RMHBI通过信号RMFAULTIND告诉RMCC关于“RELEASECHANNEL”的请求，然后RMCC会通过信号RMCONRELINIT2通知RMCR开始“RELEASEACONNECTION”。

RMCR会返回信号RMMSGCLEARREQ（即CLEARREQUEST）去MSC。

其中RMCONRELINIT2这个信号会带有拆除连接的原因。

所以我们通过追踪信号RMCONRELINIT2可以得到关于掉话在系统内的原因。

2.3.1使用TESTSYSTEM对掉话原因进行分析

由于信号RMCONRELINIT2所带有的掉话原因比较多，我们需要缩小范围。

通过TESTSYSTEM追踪（具体追踪指令见爱立信的报告），分析采样数据可以看到深圳G1局的掉话集中在：

DR2=4“FAULTINDICATION”

DR2=6“MSLOST”

DR2=3“ClearCommand”

DR2=2“SCCPFAULT”

所以我们将DR2=4“FAULTINDICATION”下面的原因进行细分，然后用TESTSYSTEM在2003年8月12日10-11点进行信号追踪（此信号追踪只限定在TCH的掉话上）：

我们得到的结果是：

总的追踪到的掉话次数为1076，其中：

DR2=6“MSLOST”为103次；

DR2=2“SCCPFault”为2次；

DR2=4，DR3=1“TOOMANYMEASUREMENTGENERATIONSMISSING”为745次；

DR2=4，DR3=8，DR4=1“T200expired（N200+1）times,abnormalrelease”为222次。

图4掉话原因与次数

另外我们从STS统计方式用OBJECTTYPECELTCHF统计掉话次数，用OBJECTTYPECLTCHDRF统计掉话原因。

其结果如下：

图5统计报告掉话原因比例

从上面的统计分析结果来看，考虑到误差的原因，两种方法得到的掉话数基本上能对应得上。

由追踪的结果可以知道，深圳G1局的掉话原因主要有三种：

●手机丢失（MSLOST）；

●T200超时（N200+1）次，不正常释放（T200expired（N200+1）times,abnormalrelease）；

●太多测量报告丢失（TOOMANYMEASUREMENTGENERATIONSMISSING）。

2.3.2分析掉话原因与掉话计数器的关系

我们一直关心系统是如何触发掉话计数器的，所以我们通过测试系统追踪不同的掉话原因与系统掉话计数器之间的关系。

我们观察到的结果是：

当RMCONRELINIT2带有的“RELEASECAUSE”是DR2=H'0004，DR3=H'0001（TOOMANYMEASUREMENTGENERATIONSMISSING）时，系统可能会触发突然掉话计数器（TFSUDLOS）、上行质差掉话计数器（TFDISQAUL）或者下行质差掉话计数器（TFDISQADL）。

当RMCONRELINIT2带有的“RELEASECAUSE”是DR2=H'0004，DR3=H'0008，DR4=1（T200expired（N200+1）times,abnormalrelease）时，系统可能会触发突然掉话计数器（TFSUDLOS）、上行弱信号掉话计数器（TFDISSUL）或者双向质差掉话计数器（TFDISQABL）。

当RMCONRELINIT2带有的“RELEASECAUSE”是DR2=H'0006（MSLOST）时，系统可能会触发突然掉话计数器（TFSUDLOS）或者触发双向弱信号掉话计数器（TFDISSBL）或者触发双向质差掉话计数器（TFDISQABL）。

为什么会出现由RMCONRELINIT2带有的同一个“RELEASECONNECTION”的原因会触发不同的掉话计数器的加一呢？

从追踪到的掉话过程看，RP（TRH）向RQRCQS发出“DISCONNECTREQUEST”，RMHBI通过信号RMFAULTIND告诉RMCC关于“RELEASECHANNEL”的请求，然后RMCC会通过信号RMCONRELINIT2通知RMCR开始“RELEASEACONNECTION”。

由于在RMCR发出了“CLEARREQUEST”后，会再发一个信号RMURGCOND1到RMHBI提出检查紧急条件（URGENCYCONDITION）的请求，然后通过RMHBI和RQRCQS向RP（TRH）询问。

RP（TRH）会根据此时从MS收到的MEASUREMENTREPORT的信息，通过和BSC设定的四个阀值参数LOWSSUL、LOWSSDL、BADQUL和BADQDL进行比较，把不同的掉话归类，将结果通过信号RPCURCONDR送到RQRCQS，对不同的掉话计数器进行加一。

所以系统最终是根据RP（TRH）对最后收到的MEASUREMENTREPORT的信息进行运算后得出的结果，然后进行掉话计数器的累加。

而不是直接根据RMCONRELINIT2所携带的原因去进行掉话计数器的累加。

三、BSC中交换方面的掉话分析

从前面的分析中可以基本了解到一个BSC里出现的掉话的主要原因，这些原因大多数属于无线方面的原因。

但交换方面的原因造成的掉话也是存在的，不过是占的比例较小。

3.1交换硬件故障掉话

交换方面造成掉话的原因包括了硬件问题。

每个通话都需要使用到交换硬件资源，而硬件故障会直接导致掉话的产生。

BSC硬件方面比较可能出现故障而造成掉话的主要是GroupSwitch与Transcoder（TRA）。

3.1.1分析GS与TRANSCODER是否造成掉话

如果GS或TRANSCODER设备有问题是可能导致掉话的。

使用TESTSYSTEM可以追踪到BSC掉话时占用的GroupSwitch的MUP，而由此MUP可以知道其它连接的设备，包括TRA及传输设备。

如果产生掉话时所占用的TRA设备在BSC内较分散，可以认为在BSC上没有因GroupSwitch与TRANSCODER产生的掉话。

3.1.2检查TRAPOOL的情况

RRTPP:

TRAPOOL=ALL;

PRINTVARRTTPH0-:

103;!

CHECKFORTRAPOOLCONGESTION!

如果打印出来的值在不断增加，表示TRA设备有拥塞。

3.1.3检查GROUPSWITCH的情况

GSSTP;

PRINTVARSRSTRAF83;!

CCOUNTGSFAULTOUT!

PRINTVARSRSTRAF82;!

CCOUNTGSFAULTIN!

PRINTVARSRSTRAF80;!

CCOUNTGSCONGIN!

PRINTVARSRSTRAF81;!

CCOUNTGSCONGOUT!

PRINTVARSRSTRAF88;!

CCOUNTSRSFAULT!

如果打印出来的值在不断增加，表示SRS设备有故障或拥塞。

3.1.4A接口传输问题

A接口上的传输设备问题也会造成掉话。

其中有种情况是在MS改变ChannelMode时，发出“ModifyTransmissionRequest”失败，主要是A接口上的设备问题。

此时信号RMMSGCLEARREQ（ClearRequest）所带的原因会标注成“TerrestrialResourceUnavailable”。

因此如果出现此原因的掉话，应该检查A接口上的设备状态。

3.2其它原因（OTHERREASON）的掉话

交换方面的原因造成的掉话多数都是只会跳转TFNDROP计数器，不会跳转特别的掉话计数器，所以属于其它原因（OtherReason）掉话。

在爱立信的BSC里，把不属于超TA、上行/下行弱信号、上行/下行质量差与突然掉话（SUDLOS）的掉话归结到其它原因（OTHERREASON）的掉话里。

这些通常是因为硬件问题、传输的问题、对系统的维护工作或者手机的问题引起的。

我们需要检查交换与基站硬件的状态和TCH、SDCCH的完好率。

同时我们也观察到，当BSC间切换的时候，如果由于目标BSC的资源分配失败，MSC向BSC发出CLEARCOMMAND，其中如果所带的原因是“Equipmentfailure”，则BSC只会增加掉话计数器TFNDROP，而不增加其它的掉话计数器，因此这种情况发生时，系统认为属于“OTHERREASON”的掉话。

从上述的信号RMCONRELINIT2分析中发现E1局中因CLEARCOMMAND产生的释放信道时的BSSMAPCAUSE有近30%是H’20即Equipmentfailure。

在MSC里有一个越局切换参数HOCLRCODE的设置决定了在目标小区无线资源分配失败时CLEARCOMMAND中的BSSMAPCAUSECODE，不同的设置造成不正确的释放信道原因。

如果把HOCLRCODE设为1，则由于目标BSC的资源分配失败时，MSC向BSC发出CLEARCOMMAND所带的原因就会是BSSMAPcausecode10（Radiointerfacefailure,reversiontooldchannel）。

如果把HOCLRCODE设为0，则由于目标BSC的资源分配失败时，MSC向BSC发出CLEARCOMMAND所带的原因就会是BSSMAPcausecode32（Equipmentfailure）。

四、无线掉话

无线方面的掉话是最主要的掉话。

由BSC的TestSystem追踪及CellTrafficRecording（CTR）得到的无线掉话原因主要是太多测量报告丢失（TooManyMeasurementReportGenerationMissing），T200超时（N200+1）次，执行非正常释放（T200Expired（N200+1）Times,PerformAbnormalRelease），MSLost与其它原因掉话。

4.1测量报告丢失

测量报告主要是提供BSC在决定切换（Handover）时所需要的参数及测量数据。

手机测量本身所在小区及相邻的小区的下行信号的信号强度（RXLEV_DL）及下行的信号质量（RXQUAL_DL）。

而基站的载波模块（TRX）测量在目前信道上所接收到的上行信号强度（RXLEV_UL）及信号质量（RXQUAL_UL）。

基站载波模块TRX使用MEASurementRESult消息发送所有的测量报告给BSC。

而发送此信息是与收取由SACCHBlock发来的手机测量报告是完全同步的。

当某个SACCHBlock不包含任何的手机测量报告时，基站的TRX只会把上行（Uplink）的测量报告发送出去到BSC，而同时信息里也包含了手机报告丢失的提示。

下图说明了此流程：

图6测量报告丢失

当出现这样一个手机测量报告丢失时将会被BSC记录为一次测量报告丢失。

而这测量报告丢失主要体现在RLINKUP参数值里。

MISSNM参数是无线小区参数。

MISSNM设定所允许的服务小区或相邻小区的缺少测量值次数，默认值为3。

在缺少测量值次数超过MISSNM值之前收到新的测量值，缺少的测量值将引用之前与之后的测量值自动加以填补。

当缺少测量值次数超过MISSNM值时，所有已经测量到的相关小区的测量值将作废。

当缺少某个相邻小区的测量值时，相关相邻小区就不能作为评估对象。

在紧急情况下如果所有相邻小区缺少的测量值都超MISSNM值，手机将无法做切换，可能导致掉话。

测量报告因素是BSC用于决定无线掉话的主要原因，绝大多数的掉话都是由测量报告的丢失触发。

TRH通过Abis接口由基站收到测量报告，而测量报告是除了TA以外在发起“DisconnectRequest”，CPCDISCREQ信号所带的故障原因。

测量报告是决定跳转掉话计数器的主要因素。

BSC需要根据最后所收到的测量报告的值来判断当时是否出现弱信号或质量差的情况。

此判断需要根据BSC的LOWSSDL、LOWSSUL、BADQDL与BADQUL参数值。

出现弱信号而形成的测量报告丢失导致最终掉话将跳转弱信号掉话计数器，而质量差造成的测量报告丢失掉话将跳转质差掉话计数器。

其它不符合质量差及弱信号的测量报告丢失掉话都会归为突然掉话（SUDLOS）。

4.2T200定时器与N200计数器

T200定时器超时（N200+1）次：

执行非正常释放，也是深圳G1局掉话的主要原因之一。

研究中发现此掉话原因占了掉话总数的20％左右。

T200定时器与N200计数器用于Abis接口与空中（Um）接口，主要是在两个接口上第二层的LAPD与LAPDm协议层上。

T200同时也是Um接口第二层LAPDm协议层上的一个重要定时器。

在LAPDm上T200主要用于SAPI＝0与SAPI＝3的数据链路，而T200值的选择需要根据以下一些法则：

●在LAPDm协议层上出现帧丢失的情况必须及时发现；

●帧的重发应该尽在可能早的时间内进行；

●T200不应该在对方的下一帧未接收到并加以处理完成之前超时；

●在不同的逻辑信道上的T200值应该是不同的。

T200在个别逻辑信道上的默认值如下：

SACCH/T－416frames

SDCCH（SAPI-0&3）－51frames

FACCH（RBS2000）（SAPI-0）－30frames

FACCH（RBS200）（SAPI-0）－39frames

N200是帧重发时的最大次数。

N200值与T200值同样是根据不同的逻辑信道而设，这主要是为了确保判断第二层（LAPDm）链路故障的共同时间。

以下是主要逻辑信道上的N200值：

SACCH/T－5次

SDCCH－23次

FACCH/F－34次

Um接口上的T200与N200值同样是无法更改的。

4.2.1通话建立过程中的T200超时

在Assignment的过程当中，MSC将发起“AssignmentRequest”要求相关BSC分配TCH给所需要的手机。

BSC会发出“ChannelActivation”的要求到相关基站的有关TRX去激活一个空闲的TCH。

在TRX激活了有关TCH之后，TRX会回“ChannelActivationAcknowledge”给BSC。

这之后BSC才会发起“AssignmentCommand”给相关手机。

而此“AssignmentCommand”通过原来的TRX上的SDCCH信道发到手机之后，手机需要回应给基站一个SABM来建立“Multi-FrameOperation”，基站在收到SABM之后会回个UA（UnnumberedAcknowledgement）给手机及同时发出“AssignmentComplete”给BSC。

但当基站无法收到手机发出的SABM信号时，基站会根据T200定时器时间来做等待。

在第一次出现等待时间达到T200时，N200次数将被设为零。

接下来每次等待时间达到T200值时，N200次数将被加一。

等待时间将一直延续到T200超时次数达到N200+1，这时BSC会发起“ClearRequest”来释放之前所分配到的TCH及目前使用的SDCCH。

这情况会被计为不正常的信道释放，即一次掉话，而原因为“T200expired（N200+1）times:

performabnormalrelease”。

图7通话建立中的T200超时

4.2.2通话过程中的