PS域问题定位手册.doc

PS域问题定位手册 目 录1PS域接通率问题定位分析71.1具体问题定位措施81.1.1问题小区处理81.1.2DCCC算法91.1.3载波扩容101.1.4H载波调整121.1.5减少弱覆盖131.1.6缩短“PS永久在线定时器”142PS域掉话率问题定位分析152.1具体问题定位措施162.1.1问题小区处理172.1.2DCCC算法优化172.1.3H频点调整172.1.4减少弱覆盖182.1.5HS-PDSCH功率与PCCPCH功率对齐192.1.6缩短“PS永久在线定时器”203PS异系统切换成功率问题定位分析203.1具体问题定位措施213.1.1问题小区处理213.1.2单用户频繁上报3A导致大量切换失败213.1.3话统切换请求总数不等于切换失败与切换成功次数的和223.1.4PS系统间切换超时释放243.1.5PS系统间切换发生“不可知错误原因的失败”243.1.6物理信道失败的原因263.1.7切换过程中由于RNC异常释放导致的切换失败27表目录表1PS接通失败率TOP15小区7表2PS接通失败率IMEI分布7表3最大速率不支持导致的RAB建立失败分布10表4PS业务拥塞小区列表10表5连续拥塞多天的小区11表6小区扩容对RAB建立成功率的影响11表7H频点更改对PS RB建立成功率的影响13表8弱覆盖造成PS RB建立失败14表9PS永久在线定时器对PS RB建立的影响14表10现网业务模型15表11终端掉话率分布16表12H频点修改对PS掉话率的影响18表13弱覆盖造成PS掉话19表14PCCPCH与HS-PDSCH功率对齐对PS掉话的影响19表15PS永久在线定时器对PS掉话的影响20表16单用户造成连续切换失败统计21表17SP100版本前后指标对比22表182009-09-19话统数据（成功次数+失败次数不等于总切换次数）23表192009-09-19PCHR切换失败统计数据23表20三星报不可知错误的切换失败次数24表21修改前的DCCC策略25表22修改后的DCCC策略26表23DCCC算法优化对不可知错误PS切换失败的影响26表24PS切换统计27表25异系统最大切换次数配置分析27图目录图 1PS无线接入坏小区趋势图9图 2PS域接通率趋势图9图 3RB SETUP超时消息流程12图 4PS RB建立失败在各RSCP的分布13图 5PS掉话TOP小区16图 6PS域掉线趋势图17图 7PS掉话在各RSCP的分布18图 8PS异系统切换坏小区趋势图21图 9Cell update导致切换不被统计的信令流程图24图 10PS系统间切换超时信令流程24图 11PS切换失败原因值为“不可知错误”25图 12RNC异常释放导致的切换失败28图 13RECCTT=250时 CS释放时间29图 14RECCTT=60时 CS释放时间29PS域问题定位分析关键词：TD、PS、异系统、接通率、掉话率、切换、定位、分析摘要： 本文结合某城市TD SCDMA项目的性能提升经验，对PS域问题的定位给出分析总结方法。1 PS域接通率问题定位分析首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方面来分析PS接通率。l 产品问题从实际网络运营情况观察来看，目前未发现产品问题严重影响PS接通率。l TOP小区问题从话统数据来看，PS的RRC建立成功率较高；而PS的RAB建立成功率则较低。查看每天PS RAB建立失败的TOP15小区，其失败次数占总失败次数的55%，因此，可针对TOP小区进行问题处理，提升网络KPI。表1 PS接通失败率TOP15小区日期20090823200908222009082120090820200908192009081820090817TOP15小区贝东T2沿河南T1木头龙T2木头龙T2木头龙T3新秀T1金川T1黄贝中村T1海富高层T2湖贝T3邮政T1东方皇宫InT新园T1向西T2沿河南T1黄贝下村T1东门T2眼科T3南国T1盛华T3文锦T2黄贝T3海富高层T1文锦T1东方T2木头龙T2新园T2木头龙T3田贝龙屋T1贝东T2文锦T2海富高层T1向西T1文锦T3盛华高层T3京广中心F1南湖T2凤凰T3新园T2新秀T1盛华高层T3黄贝中村T3罗湖东门T1罗湖T2凤凰T1盛华高层T1海富高层T2海富高层T2文检T2木头龙T2金光华F1盛华高层T3湖贝T2文锦T2竹园T1竹园T1黄贝中村T3银通T1火车站二T2新园T3向西T2城市天地F3眼科T1北斗T2渔景T2东门T3友谊T1盛华高层T3眼科T1塘尾T2塘尾T2木头龙T2湖贝T2眼科T1黄贝下村T3木头龙T2湖贝T2南方T1黄贝中村T1眼科T1新园T1黄贝下村T1湖贝T1向西T1儿童公园T3新秀T1金川T2黄贝中村T3东方T1文锦T2罗湖T3中盛一期F1儿童公园T2文锦商检F1华丽T2新园T1罗湖T3罗湖T2黄贝T2老街T2海富高层T2东门T2向西T3沿河南T3华丽T2RB失败次数占总次数的比例69.80%53.30%62.90%56.80%55.30%61.00%53.20%l 终端问题通过PCHR数据分析来看，IMEI为86010300的终端，PS RAB建立失败率较高，且失败次数较多。表2 PS接通失败率IMEI分布IMEI_TACRAB分配尝试次数RAB分配失败次数RAB分配失败率终端型号8601340011872.73%#N/A860167003133.33%#N/A121212121317.69%#N/A860103001002676.69%#N/A111111116434.69%#N/A86007100916394.26%数据卡-熊猫-PT2086900700385164.16%数据卡-大唐-DD1.1针对该款终端的用户进行分析。460077107822XXX尝试接入157次，失败21次，接入失败率为21/157=13.3%，接入时电平基本上在-95以下。在21911小区尝试接入109次，接入电平在-95左右，失败13次，接入失败率为13/109=11.9%。尝试接入失败的小区有21911（下沙二T1）、55741（下沙三T1）、20833、20802，21911接入失败较多。460077107604XXX在22163-竹子林T3，20791-地铁总站T1，20131-滨海东T1尝试接入71次，失败18次，接入失败率为18/71=25.3%，平均接入电平在-85，其中22163-竹子林T3的接入电平基本上小区-85。扣除这两个IMSI，其它IMSI的接入失败率为3.6%。结论：86010300的接通失败率较高主要是由于个别用户与个别小区造成的。对应小区下其它性能较好的UE也会出现接通率较差，所以86010300的接通失败率较高与小区、用户强相关。l 无线环境和干扰针对TOP小区，排查现网的无线环境，查看其是否是由于过覆盖、弱覆盖、信号泄露、干扰等无线环境原因造成的。该项目H频点采用单频点组网，因此，H频点干扰对于PS的接通率影响较大。除以上分析方法外，PS接通率指标提升还包括DCCC、载波扩容、调整H频点、减少弱覆盖、永久在线定时器这几个主要措施。1.1 具体问题定位措施1.1.1 问题小区处理通过对PS域RRC建立失败的TOP小区和PS域RAB建立失败的TOP小区的处理，在网络业务量不断增加的情况下，PS接入坏小区数目从6月末的62个减少到9月末的9个，减少了85.48%，如果考虑业务量增加这一原因（从6月末的423GByte增加到了9月末的462GByte），业务量坏小区比例从6.8GB/个提升到51.3GB/个，如下图所示：图 1 PS无线接入坏小区趋势图1.1.2 DCCC算法目前该TD项目的时隙比为2：4配置，H载波的两个上行时隙中有一个需要配置HS-SICH信道；用户的PS开户速率通常为上行128kbps，下行2048kbps。因此，如果没有打开DCCC算法的，一个H载波只能接进一个上行128kbps的H用户，很容易造成H载波的拥塞。图 2 PS域接通率趋势图从话统数据来看，7月13日网络侧关闭整网的DCCC算法，PS接通率迅速由97%下跌到92%，7月28日网络侧打开DCCC算法后，PS接通率重新恢复到97%。RRC的建立成功率指标始终维持在99%，PS接通率主要与PS域RAB建立成功率强相关；DCCC算法关闭后，PS域RAB建立失败是由于网络拥塞造成的，话统上可以看到“分组域RAB 指配建立失败的RAB 数目”大幅增加。表3 最大速率不支持导致的RAB建立失败分布时间PS域RAB指派建立成功RAB数目PS域RAB建立请求的RAB数目分组域RAB 指配建立失败的RAB 数目 导致的RAB建立失败占RAB总失败次数比例PS域RAB建立成功率7月11日100488 103180 70.26%97.39 7月12日97840 100595 70.25%97.26 7月13日113740 121652 250431.65%93.50 7月14日123861 135558 426336.45%91.37 7月15日116958 127653 375535.11%91.62 7月16日120599 131627 393635.69%91.62 1.1.3 载波扩容随着数据业务用户的增多，DCCC算法的打开已不能解决网络中小区PS拥塞的现象，针对8月17日至8月23日的话统数据来看，“分组域RAB 指配建立失败的RAB 数目”已经占PS RAB建立失败总次数的5%10%。以下是这段期间PS业务拥塞小区列表。表4 PS业务拥塞小区列表20090823200908222009082120090820200908192009081820090817求水山T2石厦文化T3香径T1香径T1邮电枢纽T3市民西T3市民西T3石厦文化T3石厦文化T2石厦文化T3滨中T3新世界广场F3香径T1香径T1沙尾二T2书城高层T3皇岗公园T2新世界广场F3香径T1邮电枢纽T3邮电枢纽T3食品行T2华泰T2邮电枢纽T3地王大厦F1深大村T3石厦文化T3华强北T3投资T2横岭T1滨中T3地王大厦F2石厦文化T3新世界广场F3地王大厦F1管理大厦F2福田T3安华T2市民西T3滨中T3艺丰T2新世界广场F3大梅沙二T2儿童公园T2石厦文化T1皇岗公园T3梅林东T1华泰T2二办T2龙府F1山姆T1龙溪村T3发展大厦F1华强北T3求水山T2地王大厦F2华强北T3市民西T3地王大厦F1艺丰T3石厦文化T2石厦文化T3华强北T3万佳T1下沙二T1电器T1水库新村T1下沙二T1地铁总站T1人民银行F1龙城鹏飞T1邮电枢纽T3建艺T1中级法院T1石厦南T3新世界广场F3上李朗T2百仕达T1四季花城T2上沙T1墩埔T1龙岗创业T2书城T1名士酒店T2福运T1华泰T2福田T2世贸广场F1福运T1地王大厦F2龙城T1李通T3皇岗公园T2地铁世界之窗站F1赤尾T1供电局T3华强北T2水库新村T1银河T3建艺T1地税局F1东座酒店T2香蜜湖T1百仕达T1地铁总站T1文华T1市民西T3民治T3田面T1墩埔T3艺丰T3深铁T1梅观库坑T3从上表可以看出，周末小区拥塞较少，其中以下小区在一周内拥塞次数超过3天。表5 连续拥塞多天的小区小区名拥塞天数石厦文化T36市民西T35香径T15新世界广场F35邮电枢纽T35华强北T34滨中T33地王大厦F13地王大厦F23华泰T23为了减少由于小区拥塞导致的RAB建立失败，可在该小区增加一个H载波。因为，HS-PSSCH是没有功控的，所以新增的H载波可能对周边与其同频的小区造成同频干扰，导致CS/PS接入失败或掉话，因此在H载波扩容时，还需要关注扩容对周边小区的影响。随着H载波的扩容，小区拥塞造成的RAB建立失败已明显下降。表6 小区扩容对RAB建立成功率的影响时间PS域RAB指派建立成功RAB数目PS域RAB建立请求的RAB数目分组域RAB 指配建立失败的RAB 数目 导致的RAB建立失败占RAB总失败次数比例PS域RAB建立成功率8月18日124470 127291 31711.24%97.78 8月19日128296 131101 2809.98%97.86 8月20日124766 127664 1766.07%97.73 9月16日121658 123633 180.91%98.40 9月17日127311 129092 160.90%98.62 9月18日122020 123614 372.32%98.71 1.1.4 H载波调整从话统数据来看，由于最大速率不支持造成RAB建立失败只占RAB建立失败总次数的5%10%，其它原因未知。CS的RB建立成功率基本上都在99.9%，而为什么PS的RB建立成功率只有98%左右，两者的应用场景有什么区别？从PCHR的分析来看，PS的RB建立失败除了网络拥塞，最大速率不支持之外，其它的建立失败的原因值基本上都是“RR_ERR_RNCAP_RB_WAIT_UE_RB_CFG_TIMEOUT(185468904)”，请求的下行速率绝大部分为2048kbps，从信令上来看表现为RNC给UE发送RB SETUP信令后，始终收不到UE回的RB SETUP CMP，导致RB建立失败。图 3 RB SETUP超时消息流程从UE的接入电平来看，RB建立失败的主要电平分布在-89-85，信号质量一般，到小区的该信号质量区域进行测试，RB建立也没有什么问题。分析PS业务建立的流程，首先是RRC建立，然后RNC会在H载波分配好资源，并下发RB SETUP给UE，UE会尝试在H载波上进行信道建立。RRC建立成功了，为什么RB建立不起来，同样的小区为什么CS基本没问题？该城市H频点规划只有1个频点，推测与单频点干扰相关。图 4 PS RB建立失败在各RSCP的分布为了验证RB建立失败与H单频点干扰的相关性，在RNC 1T选择TOP小区调整频点，并对这些小区进行簇跟踪。从话统数据来看，H频点更改后，该簇PS的RB建立成功率由96%提升到了99.5%，掉话率也有显著的改善。表7 H频点更改对PS RB建立成功率的影响日期HSDPA RAB分配成功次数HSDPA RAB分配请求次数HSDPA 掉话次数PS RAB 分配成功次数PS RAB 分配请求次数PS 掉话次数（含HSDPA）HSDPA掉话率PS RAB分配成功率PS掉话率(含HSDPA)备注21/08/2009 108911473641459152337633.43%95.80%25.77%26号凌晨0点修改，数据都是只统计修改的10个小区；22/08/2009 130213363611606164237227.73%97.81%23.16%23/08/2009 198620734682315240548423.56%96.26%20.91%24/08/2009 143215225222047213854436.45%95.74%26.58%25/08/2009 157316773492071217635722.19%95.17%17.24%26/08/2009 9659686212031207626.42%99.67%5.15%27/08/2009 119712036814591465735.68%99.59%5.00%28/08/2009 75977390990100511111.86%98.51%11.21%29/08/2009 13921395107156115641567.69%99.81%9.99%30/08/2009 144514463816361638432.63%99.88%2.63%1.1.5 减少弱覆盖H频点干扰较大，弱覆盖区域的PS用户容易RB建立失败而接入失败，也比较容易掉话，为了减少弱覆盖造成的PS接入失败和掉话，可调整小区覆盖，后修改最小接入电平和异系统启动门限，让用户尽量在2G网络使用业务。以下表用户为例，其接入电平平均在-97左右，如果可以调整H频点可考虑优先修改H频点，如果不行，可考虑将最小接入电平修改为-98或-95，同时注意修改异系统启动门限。表8 弱覆盖造成PS RB建立失败接入时间IMSI接入小区RACH测量报告接入小区PCCPCH RSCP22:30:46460077119551XXX晨晖花园T2-99(17)22:29:43460077119551XXX晨晖花园T2-98(18)22:30:14460077119551XXX晨晖花园T2-98(18)22:25:59460077119551XXX晨晖花园T2-97(19)23:51:35460077119551XXX晨晖花园T2-97(19)18:39:07460077119551XXX晨晖花园T2-94(22)18:39:33460077119551XXX晨晖花园T2-94(22)1.1.6 缩短“PS永久在线定时器”PS永久在线定时器的含义为：当PS业务的用户在超过该定时器时长的一段时间内无数据传输，则RNC会发起RRC释放请求释放该业务。 将PS永久在线定时器的时间改短后，RNC会更快在用户空闲没有业务流量的情况下将用户的资源释放，也可以减少用户在空闲状态保持连接导致的掉话。以定时器长为1小时和1分钟为例。假设测试场景周期为2小时，期间有6次是用户的空闲时间超过1分钟（但是没有空闲时间超过1小时）的，45分钟时会有一次网外的强干扰（会导致用户掉话和1次RAB建立失败）。如果定时器时长为1小时，那么用户在测试开始时有一次RAB建立，45分钟掉话后再有2次RAB建立（假设一次失败，一次成功），总共有3次RAB建立；45分钟时有1次掉话，所以该用户的接通率为2/3=66.6%，掉话率为1/3=33.3%。如果定时器时长为1分钟，那么用户在测试开始时有一次RAB建立，45分钟掉话后再有2次RAB建立（假设一次失败，一次成功），加上6次定时器超时导致的RAB释放和建立，总共有9次RAB建立；45分钟时有1次掉话，所以该用户的接通率为8/9=88.9%，掉话率为1/9=11.1%。所以，将PS永久在线定时器（SET TPSINACTTIMER）的时间该短后，PS的RAB建立尝试次数会增加，RAB建立成功次数也会正向增加，从而可以优化接通率和掉话率。从话统可以看出，23日修改7个RNC的“PS永久在线定时器”由之前的60S到45S后，PS的RAB建立成功率由之前的98.6%上升到98.8%。表9 PS永久在线定时器对PS RB建立的影响时间PS域RAB指派建立成功RAB数目PS域RAB建立请求的RAB数目PS域RAB建立成功率PS域RRC连接建立成功次数PS域RRC连接建立尝试次数PS域RRC连接建立成功率（呼叫相关）PS域无线接通率RNC请求释放的分组域RAB数目分组域RAB指派建立成功的RAB数目PS域无线掉线率9月21日114344 115944 98.62 94546 95152 99.36 97.99 12611 114344 11.03 9月22日120430 122236 98.52 99331 99868 99.46 97.99 12265 120430 10.18 9月23日127016 128664 98.72 105585 106176 99.44 98.17 12003 127016 9.45 9月24日149242 151063 98.79 127969 128678 99.45 98.25 10787 149242 7.23 2 PS域掉话率问题定位分析从PCHR的数据分析来看，现网CS的平均呼叫时长为87S，PS R4业务平均呼叫时长为243S，PS H业务的平均呼叫时长为792S。根据华为CDMA/UMTS系统经验，在一个成熟的网络中，基于相同的无线环境，不同业务的中断概率与业务保持时间成比例增长。从下表来看，PS的掉话率仍有提升的空间。表10 现网业务模型业务类型CSPS R4PS H平均呼叫时长87.08s243.22s792.84s当前掉线率0.85%6.12%20.83%PS经验推算掉线率2.37%7.7%针对5T的掉话率分析，发现PS掉话绝大部分为H掉话，因此，工作重心应该放在H优化上面。首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方面来分析PS掉话率。l 产品问题从实际网络运营情况观察来看，目前未发现产品问题严重影响PS掉话率。l TOP小区问题从话统数据来看，黎光T1等小区连续多天出现在TOP小区，因此，可针对TOP小区进行问题处理，提升网络KPI。图 5 PS掉话TOP小区l 终端问题从统计看出，目前现网终端活跃度较高的终端，其掉线率较为平均，均处于较高水平。表11 终端掉话率分布IMEI_TAC业务次数终端活跃度掉线次数掉线率终端型号86006200179116.31%50528.20%中兴MU35086003900131912.01%40630.78%华为ET1288600790010819.84%32830.34%#N/A353036027666.98%21728.33%#N/A860016005274.80%11221.25%中兴U980860073005585.08%10418.64%大唐AirCard901860086007496.82%10113.48%#N/Al 无线环境和干扰针对TOP小区，排查现网的无线环境，查看其是否是由于过覆盖、弱覆盖、信号泄露、干扰等无线环境原因造成的。该城市H频点采用单频点组网，因此，H频点干扰对于PS的掉话率影响较大。除以上分析方法外，PS掉话率指标还包括DCCC、调整H频点、减少弱覆盖、HS-PDSCH功率与PCCPCH功率对齐、调整永久在线定时器这几个主要措施。2.1 具体问题定位措施2.1.1 问题小区处理通过对PS域掉话率的TOP小区的处理，在网络业务量不断增加的情况下，PS掉话坏小区数目从6月末到9月末显著减少。2.1.2 DCCC算法优化现网在没有DCCC算法的情况下，1个H载波只能接进一个H用户，随着PS业务的不断增长，需打开DCCC算法以满足用户需求。从全网的PS掉话趋势图来看，7月13日关闭DCCC时，整网的PS掉话率在14%16%波动。7月28日打开DCCC后，整网的PS掉话率上升到17%。默认的DCCC算法参数容易造成用户信道的频繁重配，从而加大了掉话的可能性。8月5日，通过DCCC算法调整，解决频繁信道重配导致的掉话，PS掉话率下降到14%15%，与关闭DCCC算法时持平。8月5日DCCC算法调整，解决频繁信道重配导致的掉话7月28日打开DCCC7月13日关闭DCCC图 6 PS域掉线趋势图2.1.3 H频点调整从UE的接入电平来看，PS掉话对应的电平信号质量一般，跟弱电平没有强相关性，到小区的该信号质量区域进行测试，PS业务也正常。该城市H频点规划只有1个频点，推测与单频点干扰相关。图 7 PS掉话在各RSCP的分布为了验证PS掉话与H单频点干扰的相关性，在RNC 1T选择TOP小区调整频点，并对这些小区进行簇跟踪。从话统数据来看，H频点更改后，该簇PS的掉话率由25%下降到了5%，掉话率改善明显。表12 H频点修改对PS掉话率的影响日期HSDPA RAB分配成功次数HSDPA RAB分配请求次数HSDPA 掉话次数PS RAB 分配成功次数PS RAB 分配请求次数PS 掉话次数（含HSDPA）HSDPA掉话率PS RAB分配成功率PS掉话率(含HSDPA)备注21/08/2009 108911473641459152337633.43%95.80%25.77%26号凌晨0点修改，数据都是只统计修改的10个小区；22/08/2009 130213363611606164237227.73%97.81%23.16%23/08/2009 198620734682315240548423.56%96.26%20.91%24/08/2009 143215225222047213854436.45%95.74%26.58%25/08/2009 157316773492071217635722.19%95.17%17.24%26/08/2009 9659686212031207626.42%99.67%5.15%27/08/2009 119712036814591465735.68%99.59%5.00%28/08/2009 75977390990100511111.86%98.51%11.21%29/08/2009 13921395107156115641567.69%99.81%9.99%30/08/2009 144514463816361638432.63%99.88%2.63%2.1.4 减少弱覆盖H频点干扰较大，弱覆盖区域的PS用户比较容易掉话，为了减少弱覆盖造成的PS接入失败和掉话，可调整小区覆盖，后修改最小接入电平和异系统启动门限，让用户尽量在2G网络使用业务。以下表用户为例，其接入电平平均在-96左右，如果可以调整H频点可考虑优先修改H频点，如果不行，可考虑将最小接入电平修改为-98或-95，同时注意修改异系统启动门限。表13 弱覆盖造成PS掉话接入时间IMSI接入小区RACH测量报告接入小区PCCPCH RSCP10:26:3446007711954XXXX东方半岛T2-91(25)10:27:1546007711954XXXX东方半岛T2-94(22)10:53:4546007711954XXXX东方半岛T2-96(20)10:54:0846007711954XXXX东方半岛T2-99(17)10:54:4046007711954XXXX东方半岛T2-95(21)10:56:1646007711954XXXX东方半岛T2-94(22)20:58:2146007711954XXXX东方半岛T2-98(18)2.1.5 HS-PDSCH功率（MOD THSPDSCH）与PCCPCH功率对齐对于弱覆盖、过覆盖、信号泄露的区域，通常需要通过修改PCCPCH的功率来调整小区覆盖。之前的PCCPCH功率调整，没有考虑HS-PDSCH功率的响应调整，HS-PDSCH功率与PCCPCH功率相差较大，从而造成HS-PDSCH相对于PCCPCH过覆盖、弱覆盖。9月25日对1T、2T、4T、5T、6T下PCCPCH与HS-PDSCH功率相差较大的小区进行功率对齐，PS掉话率由之前的8%下降到6.5%。表14 PCCPCH与HS-PDSCH功率对齐对PS掉话的影响日期RNC请求释放的分组域RAB数目分组域RAB指派建立成功的RAB数目PS域无线掉线率9月25日16点,修改全网DSCH功率，原则PCCPCH-DSCH不在0-30范围进行修改，保持和PCCPCH一致；2009-9-184408466669.45%2009-9-192977423657.03%2009-9-203423428557.99%2009-9-214656466179.99%2009-9-224317492958.76%2009-9-234298484968.86%2009-9-243928501427.83%2009-9-253716503597.38%2009-9-262605435605.98%2009-9-272848448076.36%2009-9-283470506766.85% 2009-9-293493492957.09%2.1.6 缩短“PS永久在线定时器” （SET TPSINACTTIMER）当UE的PS业务没有流量时，尽快将其RB释放，一方面可以降低掉话的机率，另一方面UE当有业务需求时会再次发起RRC建立和业务请求，可再次进行RB建立，增加了RAB建立次数，从而降低PS掉话率。从话统可以看出，23日修改7个RNC的“PS永久在线定时器”由之前的60S到45S后，PS掉话率由之前的11%下降到7%。表15 PS永久在线定时器对PS掉话的影响时间PS域RAB指派建立成功RAB数目PS域RAB建立请求的RAB数目PS域RAB建立成功率PS域RRC连接建立成功次数PS域RRC连接建立尝试次数PS域RRC连接建立成功率（呼叫相关）PS域无线接通率RNC请求释放的分组域RAB数目分组域RAB指派建立成功的RAB数目PS域无线掉线率9月21日114344 115944 98.62 94546 95152 99.36 97.99 12611 114344 11.03 9月22日120430 122236 98.52 99331 99868 99.46 97.99 12265 120430 10.18 9月23日127016 128664 98.72 105585 106176 99.44 98.17 12003 127016 9.45 9月24日149242 151063 98.79 127969 128678 99.45 98.25 10787 149242 7.23 3 PS异系统切换成功率问题定位分析首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方面来分析PS切换成功率。l 产品问题通过话统数据发现,每天TOP小区通常为1个UE连续切换失败造成的。在RNC4.0.1 SP100版本，依靠惩罚机制，减少的异常切换失败次数可以将PS的切换成功率提升10个百分点左右。l TOP小区问题通过话统数据发现,每天TOP 10的小区造成了超过总切换失败次数的一半以上，因此，可针对TOP小区进行问题处理，提升网络KPI。l 终端问题通过PCHR数据分析和问题验证，推测三星手机在DCCC流程与切换流程冲突时，容易造成异系统切换失败，所以可从DCCC策略入手，优化参数减少频繁升降速。l 无线环境和干扰针对TOP小区，排查现网的无线环境，查看其是否是由于过覆盖、弱覆盖、信号泄露、干扰等无线环境原因造成的。RNC上配置的2G邻区存在同频组网时，容易造成异系统切换失败，因此，应尽量避免。3.1 具体问题定位措施3.1.1 问题小区处理PS23G切换坏小区选取需同时满足条件1和条件2：条件1： PS域3G-2G切换尝试次数(小区)- PS域3G-2G切换成功次数(小区)=3 条件2： PS域3G切换2G成功率(小区)2G切换请求次数全网3G-2G切换成功次数全网3G-2G切换失败次数TOP10小区单用户造成的切换失败次数7.22日27352040695 349 7.23日29032295608 179 7.24日29742269705 344 7.25129 7.26日19371601336 129 7.27日28792065814 434 7.28日27381922816 453 根据上述统计结果，理论分析，如果使用RNC4.0.1 SP100，依靠惩罚机制，减少的异常切换失败次数可以将PS的切换成功率提升10个百分点左右RNC4.0.1 SP100版本解决了单用户重复上报3A导致大量切换的问题，升级后PS切换成功率大幅提升到88左右，与我们的理论分析一致。表17 SP100版本前后指标对比时间PS域3Gto2G 切换请求次数PS域3Gto2G 切换成功次数PS域3Gto2G 切换成功率7月17日(升级前)2115185187.52 7月18日(升级前)2219168475.89 7月19日(升级前)2268175377.29 7月20日(升级前)2616210880.58 7月21日(升级前)2585208180.50 7月22日(升级前)2735204074.59 7月23日(升级前)2903229579.06 7月24日(升级前)2974226976.29 8月5日(升级后)2212191686.62 8月6日(升级后)2357207387.95 8月7日(升级后)1907169488.83 8月8日(升级后)1640145888.90 8月9日(升级后)1334120089.96 8月10日(升级后)1550138989.61 8月11日(升级后)1638145188.58 3.1.3 话统切换请求总数不等于切换失败与切换成功次数的和话统中统计的数据，从下表可以看出，占总切换次数的约4%的PS系统间切换既没有被统计为切换成功也没有被统计为切换失败。表18 2009-09-19话统数据（成功次数+失败次数不等于总切换次数）起始时间PS 域系统间切换出请求次数（3G-GPRS）PS 域系统间切换出成功次数（3G-GPRS）分组域系统间切换出失败次数 (3G-GPRS)既没有统计为切换成功也没有统计为切换失败的次数19/09/200949904645242103那么这103次切换到底是成功还是失败呢？接下来我们对PCHR的统计数据进行了分析。表19 2009-09-19PCHR切换失败统计数据UE_LOST(46)信道配置超时(185468901)切换超时（无响应）分组域系统间切换出失败次数 (3G-GPRS)物理信道失败RNC异常释放导致的切换失败总计922781817511331对比PCHR和话统中的按切换失败原因分项进行的统计我们可以看到，PCHR统计到的切换失败次数为331次，则说明表2-3中既没有统计为切换成功也没有统计为切换失败的103次切换，基本上为切换失败。 而分析信令可以看出如果在PS进行系统间切换失败时，如果UE通过Cell update返回3G，则RNC对于这个呼叫将漏统计，也就是既不统计为切换失败也不统计为切换成功。 其典型信令流程如下：图 9 Cell update导致切换不被统计的信令流程图如果要真实体现PS的系统间切换成功率，应该在PS系统间切换流程中，考虑收到Cell update的影响，将这种流程统计为切换失败。3.1.4 PS系统间切换超时释放其典型信令流程如下:图 10 PS系统间切换超时信令流程PCHR和话统中都统计到8次超时释放的切换失败，与话统数据一致。该问题集中于联芯系终端。3.1.5 PS系统间切换发生“不可知错误原因的失败”对比发生该原因切换失败的分时话统和PCHR数据，我们得到以下的统计数据和PCHR信令。这18次不可知原因的切换失败都是由于三星系终端造成表20 三星报不可知错误的切换失败次数终端类型 发生不可知错误的切换失败次数三星i68815三星L2883发生这种切换失败的典型信令流程图如下：图 11 PS切换失败原因值为“不可知错误”从信令流程上看到，DCCC触发了下行频繁升降速。“RB recfg cmp”与PS异系统切换命令“cell change order from UTRAN”间隔10ms，随后UE上报“cell change order from UTRAN fail”。此现象多次发生，信令流程及时间间隔基本一致。导致以上现象的原因是：由于下行DCCC策略没有经过优化，现网中采用的默认参数比较极端，相当于“快升快降”，如下行64k对应的4A门限为1024，触发时间为240ms，4B门限为256，触发时间为1280ms。这样的参数导致下行频繁升降速。RB重配流程与PS异系统切换流程间隔（10ms）太短，可能导致三星系UE的处理出现问题，目前发现三星系终端此现象比较突出，其他终端暂未发现该现象。从现象上看，由于怀疑是DCCC流程与切换流程冲突导致三星系手机切换失败，所以从DCCC策略入手，优化参数减少频繁升降速。通过信令分析，发现重配主要发生在16k、32k、64k三档速率之间。RAB指派业务类型为交互类，上下行对称128