ImageVerifierCode 换一换
格式:DOCX , 页数:28 ,大小:449.38KB ,
资源ID:4419050      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/4419050.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(掉话分析v2.docx)为本站会员(b****3)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

掉话分析v2.docx

1、掉话分析v2掉话分析(r8)一、概述深圳移动分公司本地网规划与优化服务的掉话研究的主要内容是掉话计数器跳转的原因及话务统计掉话率的真实性,并分析各种类型掉话的原因。主要结论如下: BSC掉话计数器跳转非常明确,只有实际掉话时才会跳转。话务统计的掉话率也是真实的,数量与BSC内部实际掉话相符。 突然掉话(SUDLOS)是超TA、弱信号与质量差三个条件都不符合的掉话,而掉话原因是太多测量报告丢失,或T200定时器超时等。 切换掉话只计源BSC的一次掉话。研究结果也确认各种原因与实际情况关系,其中原因主要是MS LOST。 网络中其它原因(Other Reason)的掉话原因主要是MSC与BSC之间

2、的切换掉话及由于交换硬件所引起的掉话。 BSC的4个阀值:LOWSSDL、LOWSSUL、BADQDL与BADQUL,对掉话计数器的跳转起了决定性的作用,而阀值需根据BSC信号强度分布设置。 半速率TCH在比较差的无线环境下有可能出现比全速率TCH更高的掉话率。二、BSC掉话分析研究掉话是指通话的非正常终止,掉话率是指掉话次数在接通总次数中的比例,它是衡量网络可用性的一个重要指标。无线网络的掉话可分为两种:一种是在SDCCH信道上的掉话,另一种是在TCH信道上的掉话。SDCCH掉话是指在BSC给MS分配了SDCCH信道,而TCH信道还没有分配成功期间发生的掉话。TCH掉话是指在BSC给MS成功

3、分配了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

4、 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就认为该信道资源

5、已空闲并可用于再分配了。此时BSC将向MSC发出“CLEAR COMPLETE”消息,表明无线链路已清除完毕。MSC就会完成对SCCP连接的释放,到此为止该信令流程完毕。图1 正常的呼叫连接释放流程非正常呼叫连接释放过程与正常呼叫连接释放过程的区别是:由BSC首先发出“CLEAR REQUEST”的消息。这是因为当无线接口消息失败、无线链路失败或因设备故障等原因而导致呼叫进程非正常性的释放,则由BSC向MSC发出“CLEAR REQUEST”消息。如果掉话不是由无线侧引起,则BSC不会向MSC发送“CLEAR REQUEST”消息,而是MSC向BSC发送“CLEAR COMMAND”消息,消息

6、中的呼叫清除原因不再是“Call control”或者“Handover successful”,而是其它原因。2.2 关于掉话计数器的分析根据中国移动集团公司对掉话的定义:掉话率指标定义:无线系统掉话率包括所有原因(用户线侧的原因和网络侧的原因)引起的掉话,该指标表示了网络的可保持性能。在用户所要求通话的持续时间内,网络应有连续为用户提供服务的能力。掉话率为忙时掉话次数与忙时系统应答次数之比,即:掉话率 (忙时话音信道掉话总次数/忙时系统应答总次数)100%其中,掉话次数的定义为无线侧统计“CLEAR REQUEST”消息,忙时话音信道掉话总次数是指在指配话音信道完成(即Assignment

7、 Complete)后由于各种原因导致的掉话。忙时系统应答次数的定义为交换侧统计“ANM”消息。该项指标要求在无线侧统计爱立信交换机对掉话总次数(TFNDROP)的统计定义是: 当BSC向MSC发“CLEAR REQUEST”时,会使TFNDROP加一; 或者是BSC未向MSC发“CLEAR REQUEST”,却收到MSC送来的“CLEAR COMMAND”信息,其中附带的原因不是“Call control”或者“Handover successful”,也会使TFNDROP加一。在爱立信交换机里,当掉话产生即CLEAR REQUEST发送到MSC时,交换机将会以下面的优先顺序去检查紧急状态(

8、Urgency state),从而判断应该增加哪一个掉话计数器: 超TA值(Excessive TA) 上下行弱信号(Low signal strength in downlink and/or uplink) 上下行质量差(Bad quality in downlink and/or uplink) 突然掉话(Sudden loss of connection)图2 掉话计数器跳转流程超TA 值(Excessive TA):当掉话发生时,TA 值大于或等于小区定义的参数TALIM、TFDISTA或THDISTA,这个掉话计数器就会加一,同时TFNDROP加一。上下行弱信号(Low signa

9、l 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,THDI

10、SSSBLSUB上下行质量差(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

11、,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通过信号RMFAU

12、LTIND告诉RMCC关于“RELEASE CHANNEL”的请求,然后RMCC会通过信号RMCONRELINIT2通知RMCR开始“RELEASE A CONNECTION”。RMCR会返回信号RMMSGCLEARREQ(即CLEAR REQUEST)去MSC。其中RMCONRELINIT2这个信号会带有拆除连接的原因。所以我们通过追踪信号RMCONRELINIT2可以得到关于掉话在系统内的原因。2.3.1 使用TEST SYSTEM对掉话原因进行分析由于信号RMCONRELINIT2 所带有的掉话原因比较多,我们需要缩小范围。通过TEST SYSTEM追踪(具体追踪指令见爱立信的报告),分

13、析采样数据可以看到深圳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 MEASURE

14、MENT 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局的掉话原因主要有三种: 手机丢失(MS LOST); T200 超时(N200+1)次,

15、不正常释放(T200 expired (N200+1)times, abnormal release); 太多测量报告丢失(TOO MANY MEASUREMENT GENERATIONS MISSING)。2.3.2分析掉话原因与掉话计数器的关系我们一直关心系统是如何触发掉话计数器的,所以我们通过测试系统追踪不同的掉话原因与系统掉话计数器之间的关系。我们观察到的结果是:当RMCONRELINIT2带有的“RELEASE CAUSE”是DR2=H0004,DR3=H0001(TOO MANY MEASUREMENT GENERATIONS MISSING)时,系统可能会触发突然掉话计数器(TF

16、SUDLOS)、上行质差掉话计数器(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

17、)或者触发双向弱信号掉话计数器(TFDISSBL)或者触发双向质差掉话计数器(TFDISQABL)。为什么会出现由RMCONRELINIT2带有的同一个“RELEASE CONNECTION”的原因会触发不同的掉话计数器的加一呢?从追踪到的掉话过程看,RP(TRH)向RQRCQS发出“DISCONNECT REQUEST”,RMHBI通过信号RMFAULTIND告诉RMCC关于“RELEASE CHANNEL”的请求,然后RMCC会通过信号RMCONRELINIT2通知RMCR开始“RELEASE A CONNECTION”。由于在RMCR发出了“CLEAR REQUEST”后,会再发一个信号

18、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所

19、携带的原因去进行掉话计数器的累加。三、BSC中交换方面的掉话分析从前面的分析中可以基本了解到一个BSC里出现的掉话的主要原因,这些原因大多数属于无线方面的原因。但交换方面的原因造成的掉话也是存在的,不过是占的比例较小。3.1交换硬件故障掉话交换方面造成掉话的原因包括了硬件问题。每个通话都需要使用到交换硬件资源,而硬件故障会直接导致掉话的产生。BSC硬件方面比较可能出现故障而造成掉话的主要是Group Switch与Transcoder(TRA)。3.1.1分析GS与TRANSCODER是否造成掉话如果GS或TRANSCODER设备有问题是可能导致掉话的。使用TEST SYSTEM可以追踪到BS

20、C掉话时占用的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

21、 !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接口上的设备问题。此时信号RMMSGCL

22、EARREQ(Clear Request)所带的原因会标注成“Terrestrial Resource Unavailable”。因此如果出现此原因的掉话,应该检查A接口上的设备状态。3.2其它原因(OTHER REASON)的掉话交换方面的原因造成的掉话多数都是只会跳转TFNDROP计数器,不会跳转特别的掉话计数器,所以属于其它原因(Other Reason)掉话。在爱立信的BSC里,把不属于超TA、上行/下行弱信号、上行/下行质量差与突然掉话(SUDLOS)的掉话归结到其它原因(OTHER REASON)的掉话里。 这些通常是因为硬件问题、传输的问题、对系统的维护工作或者手机的问题引起的。

23、我们需要检查交换与基站硬件的状态和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里有一个越局切换参数HOCLRC

24、ODE的设置决定了在目标小区无线资源分配失败时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(Equipme

25、nt 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)时所需要的参数及测量数据。手机测量本身所在小区及

26、相邻的小区的下行信号的信号强度(RXLEV_DL)及下行的信号质量(RXQUAL_DL)。而基站的载波模块(TRX)测量在目前信道上所接收到的上行信号强度(RXLEV_UL)及信号质量(RXQUAL_UL)。基站载波模块TRX使用MEASurement RESult消息发送所有的测量报告给BSC。而发送此信息是与收取由SACCH Block发来的手机测量报告是完全同步的。当某个SACCH Block不包含任何的手机测量报告时,基站的TRX只会把上行(Uplink)的测量报告发送出去到BSC,而同时信息里也包含了手机报告丢失的提示。下图说明了此流程:图6 测量报告丢失当出现这样一个手机测量报告丢

27、失时将会被BSC记录为一次测量报告丢失。而这测量报告丢失主要体现在RLINKUP参数值里。MISSNM参数是无线小区参数。MISSNM设定所允许的服务小区或相邻小区的缺少测量值次数,默认值为3。在缺少测量值次数超过MISSNM值之前收到新的测量值,缺少的测量值将引用之前与之后的测量值自动加以填补。当缺少测量值次数超过MISSNM值时,所有已经测量到的相关小区的测量值将作废。当缺少某个相邻小区的测量值时,相关相邻小区就不能作为评估对象。在紧急情况下如果所有相邻小区缺少的测量值都超MISSNM值,手机将无法做切换,可能导致掉话。测量报告因素是BSC用于决定无线掉话的主要原因,绝大多数的掉话都是由测

28、量报告的丢失触发。TRH通过Abis接口由基站收到测量报告,而测量报告是除了TA以外在发起“Disconnect Request”,CPCDISCREQ信号所带的故障原因。测量报告是决定跳转掉话计数器的主要因素。BSC需要根据最后所收到的测量报告的值来判断当时是否出现弱信号或质量差的情况。此判断需要根据BSC的LOWSSDL、LOWSSUL、BADQDL与BADQUL参数值。出现弱信号而形成的测量报告丢失导致最终掉话将跳转弱信号掉话计数器,而质量差造成的测量报告丢失掉话将跳转质差掉话计数器。其它不符合质量差及弱信号的测量报告丢失掉话都会归为突然掉话(SUDLOS)。4.2 T200定时器与N2

29、00计数器T200定时器超时(N200+1)次:执行非正常释放,也是深圳G1局掉话的主要原因之一。研究中发现此掉话原因占了掉话总数的20左右。T200定时器与N200计数器用于Abis接口与空中(Um)接口,主要是在两个接口上第二层的LAPD与LAPDm协议层上。T200同时也是Um接口第二层LAPDm协议层上的一个重要定时器。在LAPDm上T200主要用于SAPI0与SAPI3的数据链路,而T200值的选择需要根据以下一些法则: 在LAPDm协议层上出现帧丢失的情况必须及时发现; 帧的重发应该尽在可能早的时间内进行; T200不应该在对方的下一帧未接收到并加以处理完成之前超时; 在不同的逻辑

30、信道上的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通话建立过程中的

31、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

32、”,基站在收到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通话过程中的

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1