掉话分析(r8).doc

此文档收集于网络，如有侵权，请联系网站删除掉话分析(r8)一、概述深圳移动分公司本地网规划与优化服务的掉话研究的主要内容是掉话计数器跳转的原因及话务统计掉话率的真实性，并分析各种类型掉话的原因。主要结论如下：l BSC掉话计数器跳转非常明确，只有实际掉话时才会跳转。话务统计的掉话率也是真实的，数量与BSC内部实际掉话相符。l 突然掉话（SUDLOS）是超TA、弱信号与质量差三个条件都不符合的掉话，而掉话原因是太多测量报告丢失，或T200定时器超时等。l 切换掉话只计源BSC的一次掉话。研究结果也确认各种原因与实际情况关系，其中原因主要是MS LOST。l 网络中其它原因（Other Reason）的掉话原因主要是MSC与BSC之间的切换掉话及由于交换硬件所引起的掉话。l BSC的4个阀值：LOWSSDL、LOWSSUL、BADQDL与BADQUL，对掉话计数器的跳转起了决定性的作用，而阀值需根据BSC信号强度分布设置。l 半速率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发出“RELEASE COMPLETE”信息。MSC就会释放MM层连接，然后向BSC发出“CLEAR COMMAND”的消息来要求释放SCCP信令链路。在该信息中携带着此次呼叫清除的原因。例如是因为“Call control”而清除还是因为“Handover successful”而清除等等。BSC收到后，将释放RR连接。为了保证上下行链路都能及时地拆除，BSC在向MS发出“CHANNEL RELEASE”信息要求拆除上行链路的同时，还要向BTS发出“DEACTIVE SACCH”的消息，要求释放下行的随路信令。BTS停止发送SACCH下行链路的系统信息后，即向BSC发出“DEACTIVE SACCH ACK”的消息。BSC收到后，随即向BTS发出“RF CHANNEL RELEASE”要求释放TCH。当收到BTS返回的“RF CHANNEL RELEASE ACK”消息后，BSC就认为该信道资源已空闲并可用于再分配了。此时BSC将向MSC发出“CLEAR COMPLETE”消息，表明无线链路已清除完毕。MSC就会完成对SCCP连接的释放，到此为止该信令流程完毕。图1 正常的呼叫连接释放流程非正常呼叫连接释放过程与正常呼叫连接释放过程的区别是：由BSC首先发出“CLEAR REQUEST”的消息。这是因为当无线接口消息失败、无线链路失败或因设备故障等原因而导致呼叫进程非正常性的释放，则由BSC向MSC发出“CLEAR REQUEST”消息。如果掉话不是由无线侧引起，则BSC不会向MSC发送“CLEAR REQUEST”消息，而是MSC向BSC发送“CLEAR COMMAND”消息，消息中的呼叫清除原因不再是“Call control”或者“Handover successful”，而是其它原因。2.2 关于掉话计数器的分析根据中国移动集团公司对掉话的定义：掉话率指标定义：无线系统掉话率包括所有原因（用户线侧的原因和网络侧的原因）引起的掉话，该指标表示了网络的可保持性能。在用户所要求通话的持续时间内，网络应有连续为用户提供服务的能力。掉话率为忙时掉话次数与忙时系统应答次数之比，即：掉话率 （忙时话音信道掉话总次数/忙时系统应答总次数）100%其中，掉话次数的定义为无线侧统计“CLEAR REQUEST”消息，忙时话音信道掉话总次数是指在指配话音信道完成（即Assignment Complete）后由于各种原因导致的掉话。忙时系统应答次数的定义为交换侧统计“ANM”消息。该项指标要求在无线侧统计爱立信交换机对掉话总次数（TFNDROP）的统计定义是：l 当BSC向MSC发“CLEAR REQUEST”时，会使TFNDROP加一；l 或者是BSC未向MSC发“CLEAR REQUEST”，却收到MSC送来的“CLEAR COMMAND”信息，其中附带的原因不是“Call control”或者“Handover successful”，也会使TFNDROP加一。在爱立信交换机里，当掉话产生即CLEAR REQUEST发送到MSC时，交换机将会以下面的优先顺序去检查紧急状态（Urgency state），从而判断应该增加哪一个掉话计数器：l 超TA值（Excessive TA）l 上下行弱信号（Low signal strength in downlink and/or uplink）l 上下行质量差（Bad quality in downlink and/or uplink）l 突然掉话（Sudden loss of connection）图2 掉话计数器跳转流程超TA 值（Excessive TA）：当掉话发生时，TA 值大于或等于小区定义的参数TALIM、TFDISTA或THDISTA，这个掉话计数器就会加一，同时TFNDROP加一。上下行弱信号（Low signal strength in downlink and/or uplink）：当掉话发生时的上行信号的弱信号强度（low signal strength）小于BSC定义的参数LOWSSUL或下行信号的弱信号强度小于BSC定义的参数LOWSSDL，以下的弱信号计数器之一就会加一：Underlaid：TFDISSUL，TFDISSSDL，TFDISSSBLOverlaid：TFDISSULSUB，TFDISSSDLSUB，TFDISSSBLSUBUnderlaid：THDISSSUL，THDISSSDL，THDISSSBLOverlaid：THDISSSULSUB，THDISSSDLSUB，THDISSSBLSUB上下行质量差（Bad quality in downlink and/or uplink）：当这个掉话发生时的上行信号的质差（Bad quality）小于BSC定义的参数BADQUL或下行信号的质差小于BSC定义的参数BADQDL，以下的其中一个质差计数器就会加一：Underlaid：TFDISQAUL，TFDISQADL，TFDISQABLOverlaid：TFDISQAULSUB，TFDISQADLSUB，TFDISQABLSUBUnderlaid：THDISQAUL，THDISQADL，THDISQABLOverlaid：THDISQAULSUB，THDISQADLSUB，THDISQABLSUB突然丢失掉话（Sudden loss of connection）：当MS因为测量结果丢失，但又不符合以上三种情况时的掉话，则会使以下的其中一个质差计数器加一：Underlaid：TFSUDLOS，THSUDLOSOverlaid：TFSUDLOSSUB，THSUDLOSSUB2.3 使用BSC信号RMCONRELINIT2追踪掉话原因图3 BSC内部掉话信号流程图上图是爱立信BSC 内部关于掉话的的信号流程图。从图中可以看出当发生掉话时RP（TRH）向CP发出“DISCONNECT REQUEST”，经过RQRCQS处理后传到RMHBI，RMHBI通过信号RMFAULTIND告诉RMCC关于“RELEASE CHANNEL”的请求，然后RMCC会通过信号RMCONRELINIT2通知RMCR开始“RELEASE A CONNECTION”。RMCR会返回信号RMMSGCLEARREQ（即CLEAR REQUEST）去MSC。其中RMCONRELINIT2这个信号会带有拆除连接的原因。所以我们通过追踪信号RMCONRELINIT2可以得到关于掉话在系统内的原因。2.3.1 使用TEST SYSTEM对掉话原因进行分析由于信号RMCONRELINIT2 所带有的掉话原因比较多，我们需要缩小范围。通过TEST SYSTEM追踪（具体追踪指令见爱立信的报告），分析采样数据可以看到深圳G1 局的掉话集中在：DR2=4 “FAULT INDICATION”DR2=6 “MS LOST”DR2=3 “Clear Command”DR2=2 “SCCP FAULT”所以我们将DR2=4 “FAULT INDICATION”下面的原因进行细分，然后用TEST SYSTEM在2003年8月12日10-11点进行信号追踪（此信号追踪只限定在TCH 的掉话上）：我们得到的结果是：总的追踪到的掉话次数为1076，其中：DR2=6 “MS LOST ”为103 次；DR2=2 “SCCP Fault ”为2 次；DR2=4，DR3=1 “TOO MANY MEASUREMENT GENERATIONS MISSING”为745 次；DR2=4，DR3=8，DR4=1 “T200 expired （N200+1）times, abnormal release”为222 次。图4 掉话原因与次数另外我们从STS统计方式用OBJECT TYPE CELTCHF统计掉话次数，用OBJECT TYPE CLTCHDRF统计掉话原因。其结果如下：图5 统计报告掉话原因比例从上面的统计分析结果来看，考虑到误差的原因，两种方法得到的掉话数基本上能对应得上。由追踪的结果可以知道，深圳G1局的掉话原因主要有三种：l 手机丢失（MS LOST）；l T200 超时（N200+1）次，不正常释放（T200 expired （N200+1）times, abnormal release）；l 太多测量报告丢失（TOO MANY MEASUREMENT GENERATIONS MISSING）。2.3.2分析掉话原因与掉话计数器的关系我们一直关心系统是如何触发掉话计数器的，所以我们通过测试系统追踪不同的掉话原因与系统掉话计数器之间的关系。我们观察到的结果是：当RMCONRELINIT2带有的“RELEASE CAUSE”是DR2=H0004，DR3=H0001（TOO MANY MEASUREMENT GENERATIONS MISSING）时，系统可能会触发突然掉话计数器（TFSUDLOS）、上行质差掉话计数器（TFDISQAUL）或者下行质差掉话计数器（TFDISQADL）。当RMCONRELINIT2带有的“RELEASE CAUSE”是DR2=H0004，DR3=H0008，DR4=1（T200 expired（N200+1）times, abnormal release）时，系统可能会触发突然掉话计数器（TFSUDLOS）、上行弱信号掉话计数器（TFDISSUL）或者双向质差掉话计数器（TFDISQABL）。当RMCONRELINIT2带有的“RELEASE CAUSE”是DR2=H0006（MS LOST）时，系统可能会触发突然掉话计数器（TFSUDLOS）或者触发双向弱信号掉话计数器（TFDISSBL）或者触发双向质差掉话计数器（TFDISQABL）。为什么会出现由RMCONRELINIT2带有的同一个“RELEASE CONNECTION”的原因会触发不同的掉话计数器的加一呢？从追踪到的掉话过程看，RP（TRH）向RQRCQS发出“DISCONNECT REQUEST”，RMHBI通过信号RMFAULTIND告诉RMCC关于“RELEASE CHANNEL”的请求，然后RMCC会通过信号RMCONRELINIT2通知RMCR开始“RELEASE A CONNECTION”。由于在RMCR发出了“CLEAR REQUEST”后，会再发一个信号RMURGCOND1到RMHBI提出检查紧急条件（URGENCY CONDITION）的请求，然后通过RMHBI和RQRCQS向RP（TRH）询问。RP（TRH）会根据此时从MS收到的MEASUREMENT REPORT的信息，通过和BSC设定的四个阀值参数LOWSSUL、LOWSSDL、BADQUL和BADQDL进行比较，把不同的掉话归类，将结果通过信号RPCURCONDR送到RQRCQS，对不同的掉话计数器进行加一。所以系统最终是根据RP（TRH）对最后收到的MEASUREMENT REPORT的信息进行运算后得出的结果，然后进行掉话计数器的累加。而不是直接根据RMCONRELINIT2所携带的原因去进行掉话计数器的累加。三、BSC中交换方面的掉话分析从前面的分析中可以基本了解到一个BSC里出现的掉话的主要原因，这些原因大多数属于无线方面的原因。但交换方面的原因造成的掉话也是存在的，不过是占的比例较小。3.1交换硬件故障掉话交换方面造成掉话的原因包括了硬件问题。每个通话都需要使用到交换硬件资源，而硬件故障会直接导致掉话的产生。BSC硬件方面比较可能出现故障而造成掉话的主要是Group Switch与Transcoder（TRA）。3.1.1分析GS与TRANSCODER是否造成掉话如果GS或TRANSCODER设备有问题是可能导致掉话的。使用TEST SYSTEM可以追踪到BSC掉话时占用的Group Switch的MUP，而由此MUP可以知道其它连接的设备，包括TRA及传输设备。如果产生掉话时所占用的TRA设备在BSC内较分散，可以认为在BSC上没有因Group Switch与TRANSCODER产生的掉话。3.1.2检查TRA POOL的情况RRTPP:TRAPOOL=ALL;PRINT VAR RTTPH 0-:103;!CHECK FOR TRA POOL CONGESTION!如果打印出来的值在不断增加，表示TRA设备有拥塞。3.1.3检查GROUP SWITCH的情况GSSTP;PRINT VAR SRSTRAF 83;!CCOUNTGSFAULTOUT !PRINT VAR SRSTRAF 82;!CCOUNTGSFAULTIN !PRINT VAR SRSTRAF 80;!CCOUNTGSCONGIN !PRINT VAR SRSTRAF 81;!CCOUNTGSCONGOUT !PRINT VAR SRSTRAF 88;!CCOUNTSRSFAULT !如果打印出来的值在不断增加，表示SRS 设备有故障或拥塞。3.1.4 A接口传输问题A接口上的传输设备问题也会造成掉话。其中有种情况是在MS改变Channel Mode时，发出“Modify Transmission Request”失败，主要是A接口上的设备问题。此时信号RMMSGCLEARREQ（Clear Request）所带的原因会标注成“Terrestrial Resource Unavailable”。因此如果出现此原因的掉话，应该检查A接口上的设备状态。3.2其它原因（OTHER REASON）的掉话交换方面的原因造成的掉话多数都是只会跳转TFNDROP计数器，不会跳转特别的掉话计数器，所以属于其它原因（Other Reason）掉话。在爱立信的BSC里，把不属于超TA、上行/下行弱信号、上行/下行质量差与突然掉话（SUDLOS）的掉话归结到其它原因（OTHER REASON）的掉话里。 这些通常是因为硬件问题、传输的问题、对系统的维护工作或者手机的问题引起的。我们需要检查交换与基站硬件的状态和TCH、SDCCH的完好率。同时我们也观察到，当BSC间切换的时候，如果由于目标BSC的资源分配失败，MSC向BSC发出CLEAR COMMAND，其中如果所带的原因是“Equipment failure”，则BSC只会增加掉话计数器TFNDROP，而不增加其它的掉话计数器，因此这种情况发生时，系统认为属于“OTHER REASON”的掉话。从上述的信号RMCONRELINIT2分析中发现E1局中因CLEAR COMMAND产生的释放信道时的BSSMAP CAUSE有近30%是H20即Equipment failure。在MSC里有一个越局切换参数HOCLRCODE的设置决定了在目标小区无线资源分配失败时CLEAR COMMAND中的BSSMAP CAUSE CODE，不同的设置造成不正确的释放信道原因。如果把HOCLRCODE设为1，则由于目标BSC的资源分配失败时，MSC向BSC发出CLEAR COMMAND所带的原因就会是BSSMAP cause code 10（Radio interface failure, reversion to old channel）。如果把HOCLRCODE设为0，则由于目标BSC的资源分配失败时，MSC向BSC发出CLEAR COMMAND所带的原因就会是BSSMAP cause code 32（Equipment failure）。四、无线掉话无线方面的掉话是最主要的掉话。由BSC的Test System追踪及Cell Traffic Recording（CTR）得到的无线掉话原因主要是太多测量报告丢失（Too Many Measurement Report Generation Missing），T200超时（N200+1）次，执行非正常释放（T200 Expired（N200+1）Times, Perform Abnormal Release），MS Lost与其它原因掉话。4.1测量报告丢失测量报告主要是提供BSC在决定切换（Handover）时所需要的参数及测量数据。手机测量本身所在小区及相邻的小区的下行信号的信号强度（RXLEV_DL）及下行的信号质量（RXQUAL_DL）。而基站的载波模块（TRX）测量在目前信道上所接收到的上行信号强度（RXLEV_UL）及信号质量（RXQUAL_UL）。基站载波模块TRX使用MEASurement RESult消息发送所有的测量报告给BSC。而发送此信息是与收取由SACCH Block发来的手机测量报告是完全同步的。当某个SACCH Block不包含任何的手机测量报告时，基站的TRX只会把上行（Uplink）的测量报告发送出去到BSC，而同时信息里也包含了手机报告丢失的提示。下图说明了此流程：图6 测量报告丢失当出现这样一个手机测量报告丢失时将会被BSC记录为一次测量报告丢失。而这测量报告丢失主要体现在RLINKUP参数值里。MISSNM参数是无线小区参数。MISSNM设定所允许的服务小区或相邻小区的缺少测量值次数，默认值为3。在缺少测量值次数超过MISSNM值之前收到新的测量值，缺少的测量值将引用之前与之后的测量值自动加以填补。当缺少测量值次数超过MISSNM值时，所有已经测量到的相关小区的测量值将作废。当缺少某个相邻小区的测量值时，相关相邻小区就不能作为评估对象。在紧急情况下如果所有相邻小区缺少的测量值都超MISSNM值，手机将无法做切换，可能导致掉话。测量报告因素是BSC用于决定无线掉话的主要原因，绝大多数的掉话都是由测量报告的丢失触发。TRH通过Abis接口由基站收到测量报告，而测量报告是除了TA以外在发起“Disconnect Request”，CPCDISCREQ信号所带的故障原因。测量报告是决定跳转掉话计数器的主要因素。BSC需要根据最后所收到的测量报告的值来判断当时是否出现弱信号或质量差的情况。此判断需要根据BSC的LOWSSDL、LOWSSUL、BADQDL与BADQUL参数值。出现弱信号而形成的测量报告丢失导致最终掉话将跳转弱信号掉话计数器，而质量差造成的测量报告丢失掉话将跳转质差掉话计数器。其它不符合质量差及弱信号的测量报告丢失掉话都会归为突然掉话（SUDLOS）。4.2 T200定时器与N200计数器T200定时器超时（N200+1）次：执行非正常释放，也是深圳G1局掉话的主要原因之一。研究中发现此掉话原因占了掉话总数的20左右。T200定时器与N200计数器用于Abis接口与空中（Um）接口，主要是在两个接口上第二层的LAPD与LAPDm协议层上。T200同时也是Um接口第二层LAPDm协议层上的一个重要定时器。在LAPDm上T200主要用于SAPI0与SAPI3的数据链路，而T200值的选择需要根据以下一些法则：l 在LAPDm协议层上出现帧丢失的情况必须及时发现；l 帧的重发应该尽在可能早的时间内进行；l T200不应该在对方的下一帧未接收到并加以处理完成之前超时；l 在不同的逻辑信道上的T200值应该是不同的。T200在个别逻辑信道上的默认值如下：SACCH/T 416 framesSDCCH （SAPI-0&3）51 framesFACCH （RBS2000）（SAPI-0）30 framesFACCH （RBS200）（SAPI-0）39 framesN200是帧重发时的最大次数。N200值与T200值同样是根据不同的逻辑信道而设，这主要是为了确保判断第二层（LAPDm）链路故障的共同时间。以下是主要逻辑信道上的N200值：SACCH/T 5 次SDCCH 23 次FACCH/F 34 次Um接口上的T200与N200值同样是无法更改的。4.2.1通话建立过程中的T200超时在Assignment的过程当中，MSC将发起“Assignment Request”要求相关BSC分配TCH给所需要的手机。BSC会发出“Channel Activation”的要求到相关基站的有关TRX去激活一个空闲的TCH。在TRX激活了有关TCH之后，TRX会回“Channel Activation Acknowledge”给BSC。这之后BSC才会发起“Assignment Command”给相关手机。而此“Assignment Command”通过原来的TRX上的SDCCH信道发到手机之后，手机需要回应给基站一个SABM来建立“Multi-Frame Operation”，基站在收到SABM之后会回个UA（Unnumbered Acknowledgement）给手机及同时发出“Assignment Complete”给BSC。但当基站无法收到手机发出的SABM信号时，基站会根据T200定时器时间来做等待。在第一次出现等待时间达到T200时，N200次数将被设为零。接下来每次等待时间达到T200值时，N200次数将被加一。等待时间将一直延续到T200超时次数达到N200+1，这时BSC会发起“Clear Request”来释放之前所分配到的TCH及目前使用的SDCCH。这情况会被计为不正常的信道释放，即一次掉话，而原因为“T200 expired （N200+1）times: perform abnormal release”。图7 通话建立中的T200超时4.2.2通话过程中的T200超时在正常的通话过程当中，基站与手机之间不断的在发送第二层LAPDm的帧。LAPDm帧是由物理层的TCH信道收到。在LAPDm协议上，主要的信息帧内部带有发出帧的顺序号N（S）与接收帧的顺序号N（R）。由这两个值发方可得知接收方有没有收到已经发出的信息帧（I-frame）。如果接收方没有收到，发方需要重发有关帧。当不断出现帧重发失败的情况时，LAPDm层上的数据链路将被认为是有故障的。出现此情况时，发方会使用SABM来重新建立有关链路，发出SABM方会等待接收方回应UA来确认链路的建立成功与否。在发出SABM时T200计时也会开始。当T200超时的时候还未收到UA，发方需重发SABM，而重发次数将加一。当重发次数达到N2001时还未收到UA，Um接口上的连接将判为彻底失败。BSC 将由基站发出的Abis信息中得到有关情况与原因及发起信道的释放流程。这将会是个非正常信道释放，原因是“T200 expired （N200+1）times”。图8 通话过程中的T200超时4.2.3 信道释放过程中的T200超时如果释放过程是由MSC发起，MSC发送“Clear Request”到BSC。BSC发出“Channel Release”与“Deactivate SACCH”到基站。基站收到BSC发出的指令后发出“Channel Release”给手机。手机要释放在Um接口LAPDm上的数据链路时需要发起Disconnect（DISC）指令。T200需要在收到物理层的PH_READY-TO-SEND时及发出帧时启动。重发计数N200也需设为零。基站或手机在收到DISC之后需使用UA或DM回应，而收到UA后，将发出RELEASE-INDICATION给第三层，T200计时清除，手机进入空闲状态。但如果T200定时器在UA未接收到前超时，发起DISC的一方需要：l 重发DISC；l 将T200设回到准备发帧时的值；l 重发计数器N200加值。图9 信道释放中的T200超时当重发次数达到N2001时还未收到UA，ERROR-IND将被发到第三层，故障原因为“T200 expired（N200+1）times:perform abnormal release”。此情况也将会被计为不正常信道释放，也就是掉话。4.2.4 BSC端的T200与N200分析在出现不正常情况需要释放信道时，RP（TRH）向CP发出“Disconnect Request”。在Block RQRCOS收到“Disconnect Request”时，信号里未带有关T200的原因。因此由Block RQRCQS向Block RMHBI转发的“Disconnect Request”信号里也不带有T200超时原因。T200超时的不正常释放原因主要是由第三层的“Abis Messages”带给Block RMHBI。而Block RMHBI在发出“RMFAULTIND”提示出现不正常情况需要释放信道时，使用此信号将T200超时的故障原因带给Block RMCC。RMCC在得到此原因后把原因加在“RMCONRELINIT2”信号里发给Block RMCR。图10 BSC中获取T200超时掉话原因的流程Block RMCR除了向MSC发出“Clear Request”外，还会发出信号请求检查当时的紧急情况（Urgency State）来判断该跳转那一个计数器。但是此T200 超时原因不会直接的对掉话计数器的跳转起到决定性作用。掉话计数器里也没有属于T200超时的计数器。4.3测量报告丢失与T200超时在无线掉话当中，太多测量报告丢失（Too Many Measurement Generations Missing）与T200超时N2001次：执行不正常释放（Timer T200 expired （N200+1）times: perform abnormal release）是最主要原因。而这两种掉话原因也存在着一些关系。4.3.1 上行RLINKUP参数与T200超时RLINKUP是BSC用来计算无法解读的上行SACCH 信息的计数器。每次解到上行SACCH信息时，RLINKUP值将加二，最大值为所设定值（163 SACCH时间）。而每次上行SACCH信息无法解时，RLINKUP的值将被减去一。当RLINKUP的值是0时，将会产生掉话。SACCH是手机发送测量报告的逻辑信道，RLINKUP值的减少基本上代表着上行的测量报告丢失。但在上行SACCH可以解的时候也有可能出现没有测量报告的情况，也就是当SACCH里没有任何的手机测量报告。这也会造成太多测量报告丢失而引起掉话。在正常的通话过程中，基站与手机之间不断的发送第二层LAPDm的帧。在LAPDm协议上，主要的Information帧内部带有N（S）（发出帧的顺序号（Send Sequence Number）与N（R）（接收帧的顺序号（Receive Sequence Number）。由这两个值发方可得知接收方有没有收到已经发出的信息帧（I-frame）。如果接收方没有收到，发方需要重发有关帧。重发帧的时间间隔是T200时长，而能重发的次数最高为N2001次。给SACCH/T的T200是1.9198s，而SACCH/T的N200值是5。LAPDm层上的数据链路在T200超时N200+1次时将被认为是有故障的。SACCH上的时间大约为12秒。T200属于LAPDm层的定时器，T200超时代表着在LAPDm层的帧发送失败，也因此无法带第三层的信息。所以同样的基站将无法在SACCH信道上收到手机发出的测量报告。测量报告的丢失不一定是因为LAPDm层的故障，但LAPDm层故障将会造成测量报告丢失。太多测量报告的丢失与T200超时N200+1次都会造成掉话。而到底最终的掉话原因会是太多测量报告的丢失还是T200超时，就得看到底是那个原因先出现。很多的时候掉话或非正常TCH释放未出现前，可能同时出现测量报告丢失与T200超时的情况。4.3.2下行RLINKT参数与掉话RLINKT是属于无线下行的参数。RLINKT参数值决定手机在无法解读SACCH信号下断开连接的时间。允许参数值为8-64 SACCH（480ms）。当手机分配到TCH时，RLINKT计数器将启动。每当下行SACCH信息无法解读，RLINKT值将减一，而每次成功解下行SACCH时，RLINKT将加二。当RLINKT值减为0时，手机端将自动断开无线数据链路，手机端出现掉话。出现此情况时，基站将收不到手机通过SACCH发出的上行测量报告，同时间LAPDm层也将出现基站发出的I-Frame没有回应。这时候同时可能出现太多测量报告丢失与T200超时的情况，而最终BSC端出现的掉话原因将决定于那个条件先符合。但这两种情况将不会直接决定BSC哪个掉话计数器的跳转。4.4 无线参数调整建议由于在以上所分析的各种掉话原因中，由BSC发起的Clear Request掉话大多数都是属于无线方面的问题，无线参数方面的调整有可能降低一些小区的掉话率。而对于不同的掉话原因，应当根据相关情况分析可以调整的参数。要知道某个小区掉话的主要原因可以使用Cell Traffic Recording（CTR）。以下是一些无线参数调整的建议。4.4.1 针对太多测量报告丢失与T200超时的调整测量报告的丢失与T200超时出现掉话的实际原因可能性比较多，其中包括了手机进入非常弱信号的范围，通话当中的无线质量太差导致SACCH帧丢失，无线环境出现严重频率干扰，手机突然进入无覆盖范围如电梯或手机掉电等。从CTR中可以得知是否有很多由于太多测量报告丢失而产生的掉话。在取得相关信息后，需要分析相关小区的掉话话务统计，确定是否出现很多的弱信号与质量差的掉话。如果有这些情况建议调整BSRXMIN上行最低接收功率与MSRXMIN下行最低接收功率，确保手机不会在弱信号时继续留在相关小区。也可考虑调整QLIMUL与QLIMDL参数，确保手机不是在非常紧急情况下才切换到更好的小区。同时如果路测当中发现有小范围的弱信号情况，可以调整RLINKUP与RLINKT小区参数，延长手机在出现SACCH无法解时不掉话时间。然而如手机掉电与实际无覆盖等原因的掉话次数是无法改进的。五、切换与掉话一部移动中的手机需要靠切换来保持良好的上下行信号强度与质量。GSM网络中出现的切换情况包括小区内部切换（Intra Cell Handover）、BSC内小区之间切换（Intra BSC, Inter Cell Handover）、MSC内BSC之间小区切换（Intra MSC，Inter BSC Handover）与MSC之间小区切换（Inter MSC handover）。任何的一种切换情况都有可能会出现TCH上的掉话。以下是各种切换方式与可能出现的掉话情况，掉话与掉话计数器跳转关系及BSC所提供的掉话原因的研究。由于深圳多数小区的小区内部切换参数IHO都是关闭的，因此没有对小区内部切换进行研究。5.1 BSC内部小区间切换与掉话BSC内部两个小区之间的切换是最多的切换情况。以下是这种切换方式下可能出现的各类情况。5.1.1 成功的BSC内部小区间切换当BSC由测量报告中发现手机所在的服务小区的某个相邻小区是比服务小区来得更好时，BSC将发出要求（CH_ACT）到该相邻小区的基站要求分配一个空闲的TCH信道给这部手机。基站收到要求后激活TCH信道，同时回应（CH_ACT_ACK）给BSC。基站发出（RTH_TRAF_IND）然后BSC回应（RTC-TRAF-IND）来分配TRA及监控TS与TRA的同步。BSC跟着发出“Handover Command”通过服务小区到手机。在发出HO_CMD后定时器T3103b1将启动。手机在收到“Handover Command”后在新小区发起“Handover Access”，目标基站收到后发Handover Detect到BSC（T3103b1结束），同时发出Physical Info给手机提供帧号。手机发起SABM激活复帧操作，基站回个UA进行确认，也同时发出Establish Indication到BSC。手机收到UA后发出Handover Complete表示切换完成。BSC收到HO_COM后发出“Handover Perform”给MSC及发出RF_CH_REL要求源基站释放原来的TCH。这是一个正常的信道释放，所以在Release信号里收到的原因是Call Control。图11 BSC内部正常切换流程5.1.2 BSC内部小区间切换失败例子BSC在分配好切换目标基站上的TCH后发出“Handover Command”给手机。手机在收到后需要在新基站上发起“Handover Access”（T3124启动），而新基站收到HO_ACC后发出“Handover Detect”到BSC及发出Physical Info给手机提供帧号信息。手机收到后必须发出SABM激活复帧操作。如果新基站没收到SABM，会继续发出PHYS_INFO直到定时器T3105（BSC参数TIMER3105，8=80ms）超时NY1（BSC 参数NOOFPHYSINFOMSG，18）次。手机端的T3124超时后，手机会回到原来的TCH上发起SABM重新建立复帧操作，基站会回应UA及发起Establish Indication到BSC。跟着手机发出Handover Failure表示切换失败回到原来的TCH。BSC在收到Handover Failure之后会发出RF_CH_REL要求释放新分配的TCH，在BSC里将会见到目标小区原因为MS Lost的释放信号但不会跳转计数器。图12 切换失败回到原TCH的例子5.1.3 BSC内部小区间切换T3103b1超时掉话在BSC内部两个小区切换当中，BSC要求目标小区激活一个空闲TCH以供切换。目标基站激活TCH后发出CH_ACT_ACK告知BSC，而BSC接着通过目前基站发出Handover Command给手机，而同时启动T3103b1（爱立信值为6 秒）定时器。手机在正常情况下应当在收到Handover Command后在目标小区发起Handover Access。只有在收到HO_ACC后目标基站才会发出Handover Detect给BSC，而T3103b1会结束。当目标基站没收到手机的HO_ACC，而同时在源基站上也收不到相关手机发起的SABM重建复帧试图回到原来TCH的信号，BSC也收不到源基站发出的Establish Indication。在定时器T3103b1超时时，BSC将发出Clear Request到MSC。此Clear Request信号是用来同时释放源小区上的TCH及目标小区的TCH信道。当这种情况出现时，在BSC里将见到两个Release信号，一个给源小区而另一个给目标小区。在给目标小区的信号中所带的原因是正常的Clear Command（Call Control），目标小区的掉话计数器是不跳转的。而给源小区发出的Release信号中的原因是MS Lost，源小区将跳转总掉话计数器TFNDROP。另外也会跳转其中一个掉话计数器例如SUDLOS或TFDISSUL，而这要根据源小区上相关手机的最后测量报告与BSC的4个阀值的比较而定。图13 BSC内部小区间切换T3103b1超时掉话例子5.1.4 BSC内部小区间切换T3103b2超时掉话图14中可见到手机在BSC内部两个小区进行切换。BSC由目标基站收到Handover Detect并启动T3103b2，目标基站发Physical Info给手机失败后，手机回到源小区的TCH上。BSC收到手机回到源小区上的Establish Indication，T3103b2定时器重新启动，等待手机通过源基站发来的Handover Failure。如果在T3103b2定时器结束之时还没收到切换失败信号，BSC将发起Clear Request释放源小区及目标小区的TCH。在这情况下，Release信号所带的原因与T3103b1是一样的。源小区将出现以MS Lost为原因的掉话，掉话计数器将跳转，而目标小区出现正常TCH释放，不跳转掉话计数器。图14 BSC内部小区间切换T3103b2超时掉话例子T3103b2超时也可以是出现在目标小区。BSC在收到Handover Detect后启动T3103b2定时器，等待目标基站发来的Establish Indication。在收到“建立指示”时，T3103b2定时器将重新开始计时，等待Handover Complete。当T3103b2超时而未收到Handover complete，BSC将发出Clear Request来释放源小区与目标小区的TCH。这时同样的是会出现MS Lost为由的源小区掉话。目标小区上只会出现正常TCH释放，不算掉话。以上的情况可见到BSC内部两个小区之间的切换都是归类为MS LOST掉话原因。而且在BSC未由目标小区收到Handover Complete之前所出现的掉话，都是属于源小区的掉话，只有源小区跳转掉话计数器，目标小区不计掉话。5.2 MSC内部BSC之间切换掉话MSC内部两个BSC之间的切换信令需由MSC处理。5.2.1 BSC 之间切换的成功例子源BSC向MSC发出Handover Required而MSC向目标BSC发出Handover Request。目标BSC在要求目标基站分配TCH后回应Handover Request Acknowledge给MSC。MSC接着通过源BSC与基站发出Handover Command给手机。MSC启动HOCMDTIM（HNDTCMDINTRA参数）定时器，BSC也启动T8（25s）定时器。手机在目标小区发起Handover Access，目标基站发出Handover Detect到BSC及MSC。目标BSC启动T3103b2定时器。同时发出Physical Info给手机提供帧号。手机发起SABM，目标基站回个UA进行确认，也同时发出Establish Indication到目标BSC，目标BSC重启T3103b2。手机收到UA后发出Handover Complete到目标BSC及MSC表示切换完成。MSC发出Clear Command（HOCMDTIM结束）要求源BSC发出RF Channel Release（T8结束），源基站释放原来的TCH。这是一个正常的信道释放，所以在源BSC的Release信号里的原因是Call Control。图15 成功的MSC内BSC间切换5.2.2 MSC内部BSC之间切换失败回到源TCH源BSC发起Handover Required到MSC并启动T75定时器。MSC收到后向目标BSC发出Handover Request，当目标BSC发现有信道资源则将通过与目标小区的Channel Activate和Channel Aactive Acknowlegde消息分配新的TCH。然后目标BSC向MSC发送Handover Request Acknowledge，并启动定时器T_BSCHORRSUP直到收到目标小区发送的Handover Detect。MSC在收到目标BSC的Handover Request Acknowlegde后向源BSC发送Handover Command。源BSC收到后停止T75，然后发送HO_CMD给源小区，并同时启动T8直至最后MS成功切换到目标小区后MSC送回的旧信道Clear Command。手机收到HO_CMD后将试图用Handover Access接入目标BSC的目标小区。同时目标小区会以Handover Detect通知目标BSC已经与手机建立起了数据链路。此时目标BSC启动T3103b2，直至收到目标小区的Establish Indication，目标BSC停止并重新启动T3103b2。由于新信道发生故障，手机放弃新信道并重新激活原有TCH。在源BSC收到源小区的Establish Indication时启动T3103b2，直到收到Handover Failure。当MSC收到源BSC的HO_FAIL，会向目标BSC发出Clear Command。在目标BSC里的Release信号所带的原因是Call Control正常释放。图16 MSC内部BSC间切换失败回到源TCH5.2.3 MSC内部BSC间切换超时掉话信令流程与之前的成功和失败切换是一样的。目标BSC在回应Handover Request Acknowledge给MSC时，启动T_BSC_HORRSUP（默认15s）。接着MSC发出Handover Command给源BSC并启动HOCMDTIM（HNDTCMDINTRA参数），T102定时器。源BSC也发出HO_CMD（启动T8，默认25s）。当目标BSC在T_BSC_H