RLFAILURE优化.doc_第1页
RLFAILURE优化.doc_第2页
RLFAILURE优化.doc_第3页
RLFAILURE优化.doc_第4页
RLFAILURE优化.doc_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

RLFAILURE课题研究报告1 概述目前在TD-SCDMA网络中,无线掉话的主要原因是RL FAIL,话务统计比例占到50%以上,在路测中也发现掉话的主要原因是RL FAIL。RLFAIL主要是无线环境变差或终端问题引起的,是影响KPI提升和用户感知的重要因素,一方面由于厂家均采用了CU的挽救机制,在一定程度上提升掉话率指标,但对用户的感知并没有明显的改善;另一方面由于这种原因分析起来较为困难,难以查找到发生RL FAIL的真正原因。2 问题分析现网的相关RL 参数设置如下表:序号参数配置值备注1N3133(10)2N3159(4)3T31324INSYNC4个别小区配置为15OUTSYNC10个别小区配置为256,206RLFAIL2.4个别小区配置为25.5,17tRlFailWaitCU100008tRlRestore20009AMMAXDAT1510AMMAX_RST3个别5,711AMTMRPL012SRVTYPE默认13N302314T3027(1400)15tUeCommonOper500016tRbSetup500017MCP_HOWAITUPDATEORDEL_DURATION1000018TmpInfo15019tRbSetup5000以上参数设置符合集团公司的规定,是目前情况下指标与用户感知度均衡较好的一套参数。但个别小区的参数不符合要求,为此对不符合的小区进行了更改。更改后指标稳定,无明显变化。后续针对CS和PS业务分别进行RL FAIL现象的分析:2.1 CS rl failure分析2.1.1 失败原因分类统计序号现象描述次数比例1信令挂死5418.69%2正常保持过程中出现rl failure18664.36%3切换成功后不久上报rl failure175.88%4切换失败后上报rl failure72.42%5业务建立成功后不久立即上报rl failure62.08%6其它196.57%7汇总289100.00%2.1.2 信令挂死的详细分析2.1.2.1 现象(RNC侧观察)表现为用户切到2G后再次回到TD-SCDMA网络时有一个域的信令没有释放,如下图所示:2.1.2.2 问题分析RNC挂接的核心网是华为的设备,针对PS域信令不释放问题,联系华为核心网工程师协助分析。根据华为工程师的解释:根据协议规定,如果是带PDP进行的RAU,核心网不下发IU_RELEASE,而是由RNC决定是否进行IU_RELEASE。这里有几种场景: 用户在切换前没有激活任何PDP,从old-sgsn切换到new-sgsn后,在new-sgsn侧进行RAU,在RAU完成后sgsn立即下发iu_release消息释放iu连接; 用户在切换前激活pdp,并且在切换过程中一直在上网,在new-sgsn侧完成RAU后,用户也一直在进行上网业务,那么这种情况下iu连接肯定是不释放的; 用户在切换前激活了PDP,在切换过程中没有进行上网,但是在切换过程中PDP一直没有被去激活,在这种情况下PDP是一直从old-sgsn带到new-sgsn的,这种情况属于协议规定的带PDP进行的RAU,这种情况是由RNC决定是否进行iu-release;HW产品手册上描述如下:场景:根据29060协议,当MS发送的附着或RAU消息中带的Follow On Request标志为True时,或MS有激活PDP时,SGSN不负责IU连接的释放,由RNC进行决策是否释放IU连接。中兴通讯的工程师认为:RNC无法知道终端是否激活了PDP,因此无法由RNC发起释放。根据以上华为核心网和中兴RNC侧的策略分析,在第三种场景下,由于核心网与无线侧对这种情况没有进行处理,导致PS域的信令一直不释放,直至出现rl failure。根据现场测试发现,确实存在PS域的信令不释放的问题。为了解决该问题,9月24日打开RNC的信令挂死优化策略:对于纯信令,如果没有任何直传,在保持一段时间(通过定时器控制)后,会请求CN发起释放。具体操作如下:在网管私有参数表中对参数进行修改,对应的表为TRNC_RRMTMPINFO_SPEC:预留参数47 修改为 36000ms;预留参数48 修改为 1;其中预留参数48指的是这个策略的开关,1表示打开,预留参数47指的是信令挂死多少时间后就发起释放。2.1.3 RNC侧信令挂死优化策略打开后的效果2.1.3.1 接入分析(CDT数据)失败原因信令挂死优化策略开启前信令挂死优化策略开启后失败次数失败比例失败次数失败比例RNLC_Ue_RRCSetup_TimeOut47520.36%39890.31%RNLC_RlFail_Report8060.06%2420.02%RNLC_Ue_WaitInitUeMsgAckTimeOut4290.03%2750.02%RNLC_Ue_RabOper_TimeOut3650.03%2860.02% RNLC_Ue_Operate_fail_invalidconfiguration1720.01%1320.01%RNLC_Ue_RRCReject1240.01%980.01%RNLC_SecurityModeRsp_TimeOut1170.01%930.01%RNLC_Ue_CellUpdate_TimeOut580.00%280.00%RNLC_Ue_IntraRNCHo_TimeOut160.00%10.00%由上表可见,信令挂死优化策略打开后,效果非常明显,rl failure大幅减少。2.1.3.2 掉话分析(CDT数据)失败原因总次数语音普通PSHSDPA打开前打开后打开前打开后打开前打开后打开前打开后RNLC_RlFail_Report1636122345127075491042892RNLU_UCIU_error2092454196192235RNLC_Ue_CellUpdate_TimeOut204232261294166213RNLC_Ue_RabOper_TimeOut2821102215RNLC_Ue_CCO_TimeOut202500241821可见,信令挂死优化策略打开后,由于rl failure导致的掉话次数明显减少。2.2 PS rl failure分析2.2.1 失败原因分类统计现象描述次数比例业务建立后几秒内上报4b,并最终出现rl failure8282.00%正常保持过程中rl failure1010.00%其它88.00%汇总100100%2.2.22.2.3 TOP N终端统计2.2.3.1 按8位IMEI统计8位IMEI掉话次数话单总次数掉话率在失败话单中的占比终端型号备注860062007250114.37%4.58%中兴MU350数据卡IMSI为460020812526037的这一个终端占了56个86008600436546.57%2.74%宏基ZG5上网本IMSI为460079440330876的这一个终端占了40次860122004110323.97%2.61%上海贝尔ASB TF618无线座机IMSI为460021777525293的这一个终端占了37次352284046175550.81%3.88%三星 i9008860219003886020.44%2.42%ZTE-T U2308603760053122140.43%3.37%未知860457003894500.40%2.42%ZTE U880860457001430610占了10次35257504159477190.33%10.12%中兴 U2328629130044133950.33%2.80%联想 TD30t2.2.3.2 按15位IMEI统计15位imeiIMSI失败次数总次数掉话率860062001600700 460020812526037 567871.79%860086008361880 460079440330876 4021718.43%860122002271810 460021777525293 379240.22%860073001162710 460079771211504 218225.61%860155002656040 460079771201242 175530.91%860156001295440 460007680140046 143441.18%860457001430610 460007282344467 102441.67%860156001334170 460028077230464 101855.56%860199002131640 460007721649516 101662.50%从终端类型上来分析,无明显的终端类型产生较多的rl failure问题。3 指标跟踪

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论