您好,欢迎访问三七文档
DropcallAnalysisThisReportwaswritenbyNPIteamforYangzhou,JiangSuprovinceWCDMAnetwork,UnicomChina.Thecontentofthefileconsistsofsystemdropcallanalyzingmethodandcaselearning,handoverproblemetc..ThereportpresentsdailyworkaboutKPIofSTS.Thereportcanbeusedasreferenceforourinitialtuningwork.概述掉话的定义掉话的Counters说明正常的呼叫释放流程常见的掉话原因及简单的分析处理掉话的定义路测UE侧掉话定义路测时从UE的信令上看,在通话过程中,如果受到的空口的消息中,满足以下三个条件的任何一个:(1)收到任何的BCH消息(即系统消息)。(2)收到RRCConnectionRelease消息且释放的原因值为NotNormal。(3)收到CCDisconnect,而且释放的原因不是Normalcallclearing。掉话的定义UTRAN侧的KPI指标分析掉话定义UTRAN侧相关指标就是RNC触发释放的各业务RAB个数。主要包括两个方面:(1)业务建立成功后,RNC向CN发送RABRELEASEREQUEST消息。(2)业务建立成功后,RNC向CN发送IURELEASEREQUEST消息,其后收到CN发送的IURELEASECOMMAND。需要说明的是KPI话统掉话的定义只从Iu接口的角度进行统计,统计了RNC主动发起的RABrelease请求次数和Iurelease请求次数。而路测UE侧掉话定义主要从空口接口的消息和非接入层的消息结合原因值来进行定义的,两者不完全一致的。比如说,对于同时进行主被叫通话,TEMS记录主叫的空口消息,如果被叫异常掉话,那么分析主叫的流程也会是一次掉话,但从KPI上看,这次主叫是没有掉话指标记录的。所以两者的定义是不完全一致的,在分析时要注意区分。掉话的Counters说明Retainability(SystemRABReleaseCounters)SyetemRABreleaseshave‘releasecause’=anythingexcept‘NormalRelease‘(正常释放),’SuccessfulRelocation’(成功的位置更新),‘ResourceOptimisationRelocation’(资源最优化的重新定位),‘UserInactivity’or‘releaseduetoUEgeneratedsignallingconnectionrelease’(由于手机原因而导致的信号传输连接的释放).Thesecountersareincrementedinthebestcellintheactiveset.pmNoSystemRabReleaseSpeech(掉话次数)IncrementedbyoneinthebestcellintheactivesetforeachsystemRABreleaseofaSpeechRAB,duetoaRANAPIuReleaseCommandorRABAssignmentRequestmessage.计数的是RNC触发释放的各业务RAB个数:即根据在aRANAP(无线接入网络应用部分)IuReleaseCommandorRABAssignmentRequest(IU控制释放或者RAB分配的申请)信息。pmNoNormalRabReleaseSpeech(正常通话释放次数)DropCallRate(Speech)=100*(pmNoSystemRabReleaseSpeech/(pmNoNormalRabReleaseSpeech+pmNoSystemRabReleaseSpeech))SpeechDropCallCounterspmNoSysRelSpeechNeighbr(缺失邻区造成的掉话个数):duetounknownmeasuredcell(missingneighborrelation).IthastobenotedthatthecounteratnumeratorisonlypeggedifreleaseConnOffsetisexceeded,sotheKPIisnotincludingallthedropsrelatedtomissingneighbors.pmNoSysRelSpeechSoHo(软切换失败造成的掉话个数):duetoSoftHandoveraction,whicharenetworkinitiatedcallreleasesduetoinabilitytoincludeanon-validorvalidcellintheactiveset.ThismeansthatmissingneighbourdropsduetoreleaseConnOffsetexceedingareincluded.IngeneraleverycausethatdoesnotallowexecutingaSHOistriggeringthecounteratnumerator.pmNoSysRelSpeechUlSynch(上行同步失败造成的掉话):droppedSpeechcallduetoULSynchronizationLost.IthastobenotedthatthecounteratnumeratorisonlypeggedasaULsynchdropifdchRcLostT(default5s)expires.pmNoOfTermSpeechCong(小区拥塞造成的掉话):duetoCongestionUnknownreason(其他未知原因):duetotransmissionlost(传输断线),suddendrop(突发掉话),specificUEproblem(特定手机问题),etc正常的呼叫释放流程1)UE向SRNC发送上行直传消息UPLINKDRIECTTRANSFER。2)SRNC将UE发来的上行直传消息通过直传消息DIRECTTRANSFER透传给CN,内容指示为DISCONNECT,通知网络侧UE挂机。3)CN向SRNC发送直传消息DRIECTTRANSFER,内容指示为RELEASE,要求释放呼叫。4)SRNC将CN发来的直传消息内容通过下行直传消息DOWNLINKDIRECTTRANSFER透传给UE5)UE向SRNC发送上行直传消息UPLINKDRIECTTRANSFER。6)SRNC将UE发来的上行直传消息通过直传消息DIRECTTRANSFER透传给CN,内容指示为RELEASECOMPLETE。7)CN向SRNC发送Iu释放请求消息IURELEASECOMMAND,发起Iu接口的释放请求过程,消息表明请求Iu接口释放的原因。8)Iu接口的ALCAP协议发起Iu接口的数据传输承载释放过程。9)SRNC向CN返回Iu接口释放完成消息IURELEASECOMPLETE。常见的掉话原因及简单的分析处理1)丢邻区导致的掉话:其Counter为pmNoSysRelSpeechNeighbr。例:在BO提取的12月20日的DropCallReasons–Speech中可以看到:YZAWo1174B1于20点~21点有pmNoNormalRabReleaseSpeech(正常通话)3次,pmNoSystemRabReleaseSpeech(掉话)2次,其中2次均为pmNoSysRelSpeechNeighbr(邻区丢失掉话)、pmNoSysRelSpeechNeighbr(软切换失败掉话)。处理建议:对比MOCM基站位置,按照邻区添加原则添加所缺邻区;做GPEH或CTR跟踪该小区,查出所缺邻区后并添加;在该小区覆盖范围内现场测试后添加其所缺邻区。丢邻区导致的掉话UE测信令2)软切换失败导致的掉话:其Counter为pmNoSysRelSpeechSoHo。例:在BO提取的12月23日的DropCallReasons–Speech中可以看到:YZAWo1101B1于11点~12点有pmNoNormalRabReleaseSpeech、(正常通话)1次,pmNoSystemRabReleaseSpeech(掉话)1次,掉话为为pmNoSysRelSpeechNeighbr(软切换失败掉话)。而软切换导致掉话一般有两类原因:切换来不及(主要是拐角和针尖效应)以及乒乓切换,从信令流程上CS业务表现为手机收不到活动集更新命令。处理建议:可以通过调整天线扩大切换区,也可以配置1a事件的切换参数使切换更容易发生;解决乒乓切换带来的掉话问题,可以调整天线使覆盖区域形成主导小区,也可以配置1b事件的切换参数减少乒乓的发生等方法来进行。但该小区话务量较少,对比连续2周内该小区的掉话情况,该情况只出现一次,建议收集一定数据量,确定后再采取措施。3)上行干扰导致的掉话:其Counter为pmNoSysRelSpeechUlSynch例:在BO提取的12月22日的DropCallReasons–Speech中可以看到:YZAWo1155A1于10点~11点有pmNoNormalRabReleaseSpeech、(正常通话)196次,pmNoSystemRabReleaseSpeech(掉话)3次,掉话为为pmNoSysRelSpeechUlSynch(上行干扰掉话)。WCDMA上行干扰主要是根据跟踪的RTWP结果(可从BO里提取)结果进行判断,在发现某基站的某小区有干扰,应尽快对这小区进行一段时间的RTWP跟踪,进行定位干扰。某些情况下,该小区所在基站的其他小区以及周围基站的RTWP也需要同时跟踪根据RTWP结果判断这个小区的干扰处理。外部干扰定位通过专业测试仪器,定点、路测以及相关小区的RTWP关联分析,逐步确定外部干扰源,内部干扰定位通过对天馈不分检测和测试,最终确定干扰原因。上行干扰导致上下行覆盖不平衡,从而导致掉话,表现为:EC/NO和RSCP正常,但TxPower过高。UE侧信令查看若是上行干扰掉话,手机收到了RNC下发的CCconnect消息,同时也回了CCconnectAcknowledge消息,但RNC没有收到该消息,此时RNC就会发一个RRCConnectionRelease,进行异常通话释放。UE侧信令看干扰:可查看SystemInformationMessage(SIB7)中的ul-Interference,-106为正常值。比正常值超过10、干扰时间超过2~3秒就可能掉话。4)小区拥塞导致的掉话:其Counter为pmNoOfTermSpeechCong。建网初期网络中激活用户非常少,小区拥塞出现的可能性极低。如果有小区拥塞:1、如果是资源紧张造成的,就增加资源;2、如果是覆盖过广造成的,就减小覆盖,如:降低天线高度,增加下倾角,降低功率等;3、如果是参数设置不合理造成的,就修改参数;4、如果是突发事件造成的,可临时修改小区参数和切换参数等5)其他原因导致的掉话:DropduetoSpeechUeRejection:手机原因拒绝接入导致的掉话DropduetoIRATHandoverLost:异系统切换导致的掉话duetotransmissionlost:传输问题导致的掉话suddendrop:突发掉话
本文标题:掉话分析(英文版)
链接地址:https://www.777doc.com/doc-3156992 .html