CDL掉话分析方法.doc

CDL掉话分析方法CDL中虽然提供了RNC掉话分析功能,但由于掉话原因过于复杂,只能大体上对掉话原因进行了分类,只是保证了大部分掉话分析的原因是正确的,如果要具体分析某个过程中掉话的具体原因,则需要结合码流和RNC内部定时器进行仔细分析。掉话分析规则如下:1>如果IuReIeaseRequest的前一个消息是RABAssignmentFaiIure,如果该消息之前是RLReconfigFailure,则显示为RL重配失败引起的掉话;否则显示结果改为RB建立UE无响应2、如果IuReIeaseRequest的前一个消息是RBSetup,如果该消息之前是RLReconfigFaiIure,则显示为RL重配失败引起的掉话;否则显示结果改为RB建立UE无响应3>如果luReIeaseRequest的前一个消息是RadioLinkFaiIureIndication,如果该消息之前是CellupdateConfirm,进一步判断RLFaiIure和IuReleaseRequest消息的8K时钟差值如果小于3秒,则显示为CelIUpdateConfirm超时,否则显示为RLFailure引起的掉话;4、 如果IuReIeaseRequest的前一个消息是PhysicaIChanneIReconfig,如果该消息之前是CelIupdateConfirm,进一步判断RLFaiIure和IuReIeaseRequest消息时钟差值如果小于6秒,则显示为切换过程中发生RL失败引起的掉话。5、 如果IuReIeaseRequest的前一个消息是RadioIinkDeIetionRequest,判断RLFaiIure和IuReIeaseRequest消息的8K时钟差值,如果小于等于6秒,显示RLFailure引起的掉话(长时间发生RLFailure),否则为未知掉话原因上面5种,除此之外则显示为RLFailure引起的掉话6、 monID,ess则显示结果为RNC内部原因引起的掉话7、 如果IuReIeaseRequest的前一个消息是CeIIupdateConfirm,则显示结果为则显示为CelIUpdateConfirm超时。8、如果IuReIeaseRequest的前一个消息是PhysicalChanneIReconfig,、 如果IuReIeaseRequest的前一个消息是GTP-UErrorIndication,则显示为业务面GTP-U错误引起的掉话10、 onnectReIease0、mand、pIete,则不算作掉话,归类为网络优化。常用系统定时器:无线链路失败定时器 6s移动性管理定时器 3s系统切换定时器 10s重定位切换定时器 8s目前常见掉话原因:1、并发流程引起的掉话:RB建立过程中发生小区更新不支持,V2目前的设计就是进行释放RRC。切换过程并发小区更新不支持,V2目前的设计就是进行释放RRC。安全模式控制并发小区更新不支持,V2目前的设计就是进行释放RRC。2、 无线链路失败引起的掉话:RadioIinkFailureindication和luReIeaseRequest之间没有该无线链路的恢复,且RadioIinkFaiIureindication和IuReIeaseRequest之间的时间差大于等于6s|目前,|,则为无线链路失败引起的掉话。(这种情况在目前比较普遍,问题是上刑事步后NodeB关闭发射,使UE下行失步,但是UE没有CellUpdateo)3、 小区更新引起的掉话:下行无线链路失败,CELLUpdate携带的Event_PARA=5,|RadiolinkfaiIure|.(^0侧下发。。11UpdataConfirm后时刻与IuReIeaseRequest时刻时间差大于等于3m,IuReIeaseRequest中携带内部原因为26,则为Ce11UpdateConfirm超时。(现在的小区更新最多发3次)4、 RB建立无响应:终端上报RBSetupFailure,且和RBSetup之间时间差大于等于10s,则为RB建立过程UE无响应,定时器超时释放。(也是很常见的现象,可能是UE同步失败造成的。)内部掉话分析依据:CDL掉话分析是基于RNC发起的luReleaseRequest而来,即认为所有由RNC发起的用户释放过程都是异常释放过程。当然该异常的直接发生有可能是终端问题、也可能是基站问题以及也可能是RNC问题。CDLX具为了减少消息量,减少对系统的冲击,尽量缩减码流长度,目前,系统上报的CDL码流基本为15字节左右;为了解码的统一,解码结构也大致相同。结构如下:第一部分占用一个字节:CDL定义的接口类型第二部分占用4个字节:EVENT