TD-SCDMA PS域问题定位分析

PS域问题定位分析,1.PS域接通率问题定位分析,首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方面来分析PS接通率。,产品问题从实际网络运营情况观察来看，目前未发现产品问题严重影响PS接通率。,TOP小区问题从话统数据来看，PS的RRC建立成功率较高；而PS的RAB建立成功率则较低。查看每天PSRAB建立失败的TOP15小区，其失败次数占总失败次数的55%，因此，可针对TOP小区进行问题处理，提升网络KPI。,终端问题通过PCHR数据分析来看，IMEI为86010300的终端，PSRAB建立失败率较高，且失败次数较多。,无线环境和干扰针对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/个，如下图所示：,PS无线接入坏小区趋势图,1.1.2DCCC算法目前该TD项目的时隙比为2：4配置，H载波的两个上行时隙中有一个需要配置HS-SICH信道；用户的PS开户速率通常为上行128kbps，下行2048kbps。因此，如果没有打开DCCC算法的，一个H载波只能接进一个上行128kbps的H用户，很容易造成H载波的拥塞。,PS域接通率趋势图,从话统数据来看，7月13日网络侧关闭整网的DCCC算法，PS接通率迅速由97%下跌到92%，7月28日网络侧打开DCCC算法后，PS接通率重新恢复到97%。,RRC的建立成功率指标始终维持在99%，PS接通率主要与PS域RAB建立成功率强相关；DCCC算法关闭后，PS域RAB建立失败是由于网络拥塞造成的，话统上可以看到“分组域RAB指配建立失败的RAB数目”大幅增加。,1.1.3载波扩容随着数据业务用户的增多，DCCC算法的打开已不能解决网络中小区PS拥塞的现象，针对8月17日至8月23日的话统数据来看，“分组域RAB指配建立失败的RAB数目”已经占PSRAB建立失败总次数的5%10%。以下是这段期间PS业务拥塞小区列表。,PS业务拥塞小区列表,从上表可以看出，周末小区拥塞较少，其中以下小区在一周内拥塞次数超过3天,连续拥塞多天的小区,为了减少由于小区拥塞导致的RAB建立失败，可在该小区增加一个H载波。因为，HS-PSSCH是没有功控的，所以新增的H载波可能对周边与其同频的小区造成同频干扰，导致CS/PS接入失败或掉话，因此在H载波扩容时，还需要关注扩容对周边小区的影响。随着H载波的扩容，小区拥塞造成的RAB建立失败已明显下降。,小区扩容对RAB建立成功率的影响,1.1.4H载波调整,从话统数据来看，由于最大速率不支持造成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发送RBSETUP信令后，始终收不到UE回的RBSETUPCMP，导致RB建立失败。,RBSETUP超时消息流程,从UE的接入电平来看，RB建立失败的主要电平分布在-89-85，信号质量一般，到小区的该信号质量区域进行测试，RB建立也没有什么问题。分析PS业务建立的流程，首先是RRC建立，然后RNC会在H载波分配好资源，并下发RBSETUP给UE，UE会尝试在H载波上进行信道建立。RRC建立成功了，为什么RB建立不起来，同样的小区为什么CS基本没问题？该城市H频点规划只有1个频点，推测与单频点干扰相关。,PSRB建立失败在各RSCP的分布,为了验证RB建立失败与H单频点干扰的相关性，在RNC1T选择TOP小区调整频点，并对这些小区进行簇跟踪。从话统数据来看，H频点更改后，该簇PS的RB建立成功率由96%提升到了99.5%，掉话率也有显著的改善。,H频点更改对PSRB建立成功率的影响,减少弱覆盖,H频点干扰较大，弱覆盖区域的PS用户容易RB建立失败而接入失败，也比较容易掉话，为了减少弱覆盖造成的PS接入失败和掉话，可调整小区覆盖，后修改最小接入电平和异系统启动门限，让用户尽量在2G网络使用业务。以下表用户为例，其接入电平平均在-97左右，如果可以调整H频点可考虑优先修改H频点，如果不行，可考虑将最小接入电平修改为-98或-95，同时注意修改异系统启动门限。,缩短“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永久在线定时器的时间该短后，PS的RAB建立尝试次数会增加，RAB建立成功次数也会正向增加，从而可以优化接通率和掉话率。从话统可以看出，23日修改7个RNC的“PS永久在线定时器”由之前的60S到45S后，PS的RAB建立成功率由之前的98.6%上升到98.8%。,PS域掉话率问题定位分析,从PCHR的数据分析来看，现网CS的平均呼叫时长为87S，PSR4业务平均呼叫时长为243S，PSH业务的平均呼叫时长为792S。根据华为CDMA/UMTS系统经验，在一个成熟的网络中，基于相同的无线环境，不同业务的中断概率与业务保持时间成比例增长。从下表来看，PS的掉话率仍有提升的空间,针对5T的掉话率分析，发现PS掉话绝大部分为H掉话，因此，工作重心应该放在H优化上面。首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方面来分析PS掉话率。,产品问题从实际网络运营情况观察来看，目前未发现产品问题严重影响PS掉话率。,TOP小区问题从话统数据来看，黎光T1等小区连续多天出现在TOP小区，因此，可针对TOP小区进行问题处理，提升网络KPI。,终端问题从统计看出，目前现网终端活跃度较高的终端，其掉线率较为平均，均处于较高水平,无线环境和干扰针对TOP小区，排查现网的无线环境，查看其是否是由于过覆盖、弱覆盖、信号泄露、干扰等无线环境原因造成的。该城市H频点采用单频点组网，因此，H频点干扰对于PS的掉话率影响较大。除以上分析方法外，PS掉话率指标还包括DCCC、调整H频点、减少弱覆盖、HS-PDSCH功率与PCCPCH功率对齐、调整永久在线定时器这几个主要措施。,2.1具体问题定位措施,2.1.1问题小区处理通过对PS域掉话率的TOP小区的处理，在网络业务量不断增加的情况下，PS掉话坏小区数目从6月末到9月末显著减少。,2.1.2DCCC算法优化现网在没有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算法时持平。,PS域掉线趋势图,2.1.3H频点调整从UE的接入电平来看，PS掉话对应的电平信号质量一般，跟弱电平没有强相关性，到小区的该信号质量区域进行测试，PS业务也正常。该城市H频点规划只有1个频点，推测与单频点干扰相关。,PS掉话在各RSCP的分布,为了验证PS掉话与H单频点干扰的相关性，在RNC1T选择TOP小区调整频点，并对这些小区进行簇跟踪。从话统数据来看，H频点更改后，该簇PS的掉话率由25%下降到了5%，掉话率改善明显。,2.1.4减少弱覆盖,H频点干扰较大，弱覆盖区域的PS用户比较容易掉话，为了减少弱覆盖造成的PS接入失败和掉话，可调整小区覆盖，后修改最小接入电平和异系统启动门限，让用户尽量在2G网络使用业务。以下表用户为例，其接入电平平均在-96左右，如果可以调整H频点可考虑优先修改H频点，如果不行，可考虑将最小接入电平修改为-98或-95，同时注意修改异系统启动门限。,2.1.5HS-PDSCH功率与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%。,PCCPCH与HS-PDSCH功率对齐对PS掉话的影响,2.1.6缩短“PS永久在线定时器”,当UE的PS业务没有流量时，尽快将其RB释放，一方面可以降低掉话的机率，另一方面UE当有业务需求时会再次发起RRC建立和业务请求，可再次进行RB建立，增加了RAB建立次数，从而降低PS掉话率。从话统可以看出，23日修改7个RNC的“PS永久在线定时器”由之前的60S到45S后，PS掉话率由之前的11%下降到7%。,PS永久在线定时器对PS掉话的影响,3PS异系统切换成功率问题定位分析首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方面来分析PS接通率。,产品问题通过话统数据发现,每天TOP小区通常为1个UE连续切换失败造成的。在RNC4.0.1SP100版本，依靠惩罚机制，减少的异常切换失败次数可以将PS的切换成功率提升10个百分点左右。TOP小区问题通过话统数据发现,每天TOP10的小区造成了超过总切换失败次数的一半以上，因此，可针对TOP小区进行问题处理，提升网络KPI。终端问题通过PCHR数据分析和问题验证，推测三星手机在DCCC流程与切换流程冲突时，容易造成异系统切换失败，所以可从DCCC策略入手，优化参数减少频繁升降速。无线环境和干扰针对TOP小区，排查现网的无线环境，查看其是否是由于过覆盖、弱覆盖、信号泄露、干扰等无线环境原因造成的。RNC上配置的2G邻区存在同频组网时，容易造成异系统切换失败，因此，应尽量避免。,3.1具体问题定位措施,3.1.1问题小区处理PS23G切换坏小区选取需同时满足条件1和条件2：条件1：PS域3G-2G切换尝试次数(小区)-PS域3G-2G切换成功次数(小区)=3条件2：PS域3G切换2G成功率(小区)=0.85;通过对PS23G切换TOP小区的处理，在网络业务量不断增加的情况下，CS23G切换坏小区数目从6月末的83个减少到9月末的22个，减少了73.49%，9月末的坏小区比8月末的坏小区略多主要是因为切换次数从2419次增加到5461次，整体基数上升导致。如下图所示：,PS异系统切换坏小区趋势图,3.1.2单用户频繁上报3A导致大量切换失败,网络优化调整前全网PS切换成功率维持在78%左右,PS切换失败统计的原因值90%以上为”物理信道失败”。通过话统数据发现,每天TOP10的小区造成了超过总切换失败次数的一半以上,而每个小区的大量切换失败,通常为1个UE连续切换失败造成的。下表为统计数据:,根据上述统计结果，理论分析，如果使用RNC4.0.1SP100，依靠惩罚机制，减少的异常切换失败次数可以将PS的切换成功率提升10个百分点左右RNC4.0.1SP100版本解决了单用户重复上报3A导致大量切换的问题，升级后PS切换成功率大幅提升到88左右，与我们的理论分析一致。,单用户造成连续切换失败统计,SP100版本前后指标对比,3.1.3话统切换请求总数不等于切换失败与切换成功次数的和,话统中统计的数据，从下表可以看出，占总切换次数的约4%的PS系统间切换既没有被统计为切换成功也没有被统计为切换失败。,2009-09-19话统数据（成功次数+失败次数不等于总切换次数）,那么这103次切换到底是成功还是失败呢？接下来我们对PCHR的统计数据进行了分析。,2009-09-19PCHR切换失败统计数据,对比PCHR和话统中的按切换失败原因分项进行的统计我们可以看到，PCHR统计到的切换失败次数为331次，则说明表2-3中既没有统计为切换成功也没有统计为切换失败的103次切换，基本上为切换失败。而分析信令可以看出如果在PS进行系统间切换失败时，如果UE通过Cellupdate返回3G，则RNC对于这个呼叫将漏统计，也就是既不统计为切换失败也不统计为切换成功。其典型信令流程如下：,Cellupdate导致切换不被统计的信令流程图,如果要真实体现PS的系统间切换成功率，应该在PS系统间切换流程中，考虑收到Cellupdate的影响，将这种流程统计为切换失败,3.1.4PS系统间切换超时释放,其典型信令流程如下,PS系统间切换超时信令流程,PCHR和话统中都统计到8次超时释放的切换失败，与话统数据一致。该问题集中于联芯系终端。,3.1.5pS系统间切换发生“不可知错误原因的失败”,对比发生该原因切换失败的分时话统和PCHR数据，我们得到以下的统计数据和PCHR信令。这18次不可知原因的切换失败都是由于三星系终端造成,三星报不可知错误的切换失败次数,发生这种切换失败的典型信令流程图如下：,PS切换失败原因值为“不可知错误,从信令流程上看到，DCCC触发了下行频繁升降速。“RBrecfgcmp”与PS异系统切换命令“cellchangeorderfromUTRAN”间隔10ms，随后UE上报“cellchangeorderfromUTRANfail”。此现象多次发生，信令流程及时间间隔基本一致。导致以上现象的原因是：由于下行DCCC策略没有经过优化，现网中采用的默认参数比较极端，相当于“快升快降”，如下行64k对应的4A门限为1024，触发时间为240ms，4B门限为256，触发时间为1280ms。这样的参数导致下行频繁升降速。RB重配流程与PS异系统切换流程间隔（10ms）太短，可能导致三星系UE的处理出现问题，目前发现三星系终端此现象比较突出，其他终端暂未发现该现象。从现象上看，由于怀疑是DCCC流程与切换流程冲突导致三星系手机切换失败，所以从DCCC策略入手，优化参数减少频繁升降速。通过信令分析，发现重配主要发生在16k、32k、64k三档速率之间。RAB指派业务类型为交互类，上下行对称128k。RB建立上行16k，下行64k，业务建立不久容易发生降速。经测试，UE发起wap浏览业务表现为以上现象。现网默认的下行DCCC策略见下表。,修改前的DCCC策略,将以上参数策略修改为下表所示。,修改后的DCCC策略,修改后的参数策略相当于“慢升慢降”。对于26号软参，根据资阳的经验，设置为32k降速需要5个4B报告（至少16s），64k降速需要2个4B报告（至少4s）。,分析参数修改后的话统，发现流程冲突的现象得到一定程度的缓解。26号软参对下行DCCC起作用，降速过程明显变慢。,我们对比了参数修改前后5日的话统指标：,这种不可知错误的切换失败从之前的30次左右下降到20次左右，有明显的改善，但没有完全消除。,DCCC算法优化对不可知错误PS切换失败的影响,3.1.6物理信道失败的原因,对于物理信道类的切换失败，网络侧并没有更多的办法可以进行优化，这种切换失败通常是由于终端和无线环境的原因造成的，只能通过调整参数改善无线环境以及要求终端改善无线性能进行提高。网络侧只能通过减少不必要的切换尝试来减少切换失败。在完成RNC4.0.1SP100升级后，从PCHR中可以看到，单用户造成的切换失败次数大幅度降低，指标也得到极大的改善，但仍然可以看到单用户超过3次以上的连续切换失败。这是因为在该版本中系统间切换最大允许次数默认为16，而由于单次呼叫中，第一次呼叫的切换成功率最高，依次递减，因此为了确定最佳的参数设定，限制后面不必要的切换尝试失败，我们进行了以下的数据分析。,我们选取了约一个礼拜的PS切换的统计分析，如下表，我们以每呼叫进行的切换次数做为纵坐标，进行了如下的统计。,PS切换统计,对于上表，我们以第一行为例，该行表示统计的是呼叫中只发生了一次切换的所有呼叫所产生的总的切换失败次数（1413），总的切换次数（13880）,总的切换成功次数(12744)，只发生过一次切换的所有呼叫共13880次,下表是如果我们将系统间切换次数从15减小到1或2，对各KPI造成的影响如下：例如减小到2，即只允许呼叫发起2次系统间切换尝试，那么超过2次的所有切换将被禁止，不再发生，从下表我们可以看出，将减少124次切换失败和21次切换成功。如果我们假设这21次本来能成功的切换由于被禁止而导致掉话（实际上也许会发生系统内切换而不会掉话），则我们将提高0.8%个百分点的切换成功率，对掉话率的影响将远小于0.14%(因为我们这里用发生过切换的PS切换次数作为分母，而实际的PS呼叫次数肯定是大于发生过切换的PS呼叫次数的)。,异系统最大切换次数配置分析,从上表我们可以得出结论，但系统间切换最大切换次数配置为2时，将提高切换成功率0.8个百分点，而几乎不会造成掉话等负面影响。因此全网按此参数进行了设置。,3.1.7切换过程中由于RNC异常释放导致的切换失败,我们统计分析发现，PS切换存在下列典型的异常信令流程：,UE收到Cellchangeorder命令后，进行切换RNC收到RANAP_SRNS_CONTEXT_REQ,说明UE已经成功完成了在2G的物理接入，2GSGSN收到UE的RAU更新请求。RNC也及时的回应了RANAP_SRNS_CONTEXT_RESP由于由以下参数配置：NOUTSYNCIND=20,TRLFAILURE=200表示NodeB将在无线链路失步后23.2秒上报RLFAILIND,然后按NodeB和维护部同事给出的解释，NodeB的RECCTT定时器将决定在上报RLFAILIND后，什么时候上报NBAP_RESET_REQ，而RNC收到该消息后，将发送IUreleaserequest给核心网，导致该次切换失败。但目前现网的RECCTT参数设置为60，按NODEB给出的解释，说明NODEB将在发送RLFAILIND6秒后，上报释放消息NBAP_RESET_REQ。但根据PCHR抓到的信令看，NodeB应该是在固定的17秒后（也即RNC发起切换后40秒）上报的NBAP_RESET_REQ，释放呼叫，与NodeB的解释不一致。目前NODEB没有给出进一步的解释。,目前RNC通常在40秒左右超时，发送IU_Release_Req对这个呼叫进行了释放，导致切换失败。,RNC异常释放导致的切换失败,为了提高切换成功率，我们进行了以下的2个方案的修改尝试。,发生此种切换的关键问题是由于PS系统间切换所需的流程较长，甚至长于1分钟。要减少