TD PS接通率分析.docx

1、TD PS接通率分析PS域无线接通率提升报告1评估1.1PS域无线接通率概述 PS域无线接通率是集团考核的重要指标之一。指标优劣间接反映了用户的感知。ZZ的整体排名指标排名相对较靠后，低于全国平均水平。XX在ZZ的指标较差，以XX为例进行评估分析。 1.2指标评估 XX各个RNC的PS域接通率指标-PS域RRC指标-PS域RAB指标如下：定义：PS域无线接通率=RRC无线接通率*PS域RAB建立成功率 XXPS域RRC建立成功率指标PS域RAB建立成功率指标PS域接通率指标RNC0299.65%99.43%99.08%RNC0799.59%99.63%99.22%RNC0899.69%99.6

2、0%99.29%RNC0999.63%99.59%99.22%RNC1099.77%99.62%99.39%RNC1199.74%99.67%99.41%RNC1299.54%99.61%99.15%RNC1399.74%99.72%99.46%XX全网99.65%99.60%99.25%数据提取时间：2011/12/25-2011/12/31七天，目前XXPS无线接通率为99.25%,其中RNC02为99.08%最差。PS接通率指标亟待提高。1.3.失败原因评估 由RNC在话统的相关统计点，对RRC和RAB建立失败的原因进行统计，对统计点的名称和相应的统计占比进行如下分析。1.4 PS RR

3、C失败原因分析 以XX全网2011/12/25-2011/12/31七天数据进行RRC建立失败统计分析如下： 上图是XXHW区8个RNC的7天数据汇总，对上图我们分别对各项失败原因值进行汇总统计，原因值为RRC.FailConnEstab.NoReply的失败次数最多，各个RNC该失败原因占比在88%左右，其余失败原因值占比较大的为RRC.FailConnEstab.Cong,具体统计分析如下： 通过上图，RNC12，RNC09，RNC02，RNC07四个RNC，RRC建立失败原因值为RRC.FailConnEstab.NoReply的失败次数较多。通过上图，各RNC的RRC失败次数及失败主要

4、原因为RRC.FailConnEstab.NoReply与RRC.FailConnEstab.Cong的分布情况。 全网RNC失败原因值占比统计分析，可以看出RRC.FailConnEstab.NoReply占比最大。需要排查空口上下行无线环境，干扰、弱场、拥塞及设备异常等RRC建立失败不区分业务，话统中常见的RRC建立失败原因具体含义如下： 序号RRC失败counter含义原因1url=mkMSITStore:%E5%90%88%E8%82%A5%E5%87%BA%E5%B7%AE%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3LCR4.1%20DRNC820%20P

5、erformance%20Counter%20Reference.chm:/help/percounter/4.3.4.1.3%E6%8C%89%E5%8E%9F%E5%9B%A0%E5%88%86RRC%E8%BF%9E%E6%8E%A5%E5%A4%B1%E8%B4%A5%E6%AC%A1%E6%95%B0.htmlRRC.FailConnEstab.1/url原因为的连接失败次数当UE发RRC connection req，收不到RRC connection setup消息，当达到N300次数，还没有收到RRC connection setup，则RRC建立失败，原因值是“拥塞”。在网络

6、建设初期，基本上不会发生拥塞，如果出现该原因，应该检查一下NodeB是否正常。2url=mkMSITStore:%E5%90%88%E8%82%A5%E5%87%BA%E5%B7%AE%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3LCR4.1%20DRNC820%20Performance%20Counter%20Reference.chm:/help/percounter/4.3.4.1.3%E6%8C%89%E5%8E%9F%E5%9B%A0%E5%88%86RRC%E8%BF%9E%E6%8E%A5%E5%A4%B1%E8%B4%A5%E6%AC%A1%E6%9

7、5%B0.htmlRRC.FailConnEstab.AAL2SetupFail/url原因为的连接失败次数为用户建立Iub口的用户面时，需先建立AAL2链路。如果AAL2链路建立失败，则后续的FP、MACD等都无法建立。如果出现AAL2建立失败，同样需要检查Iub接口的通道是否正常，例如：PATH是否配置合理。3url=mkMSITStore:%E5%90%88%E8%82%A5%E5%87%BA%E5%B7%AE%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3LCR4.1%20DRNC820%20Performance%20Counter%20Reference.c

8、hm:/help/percounter/4.3.4.1.3%E6%8C%89%E5%8E%9F%E5%9B%A0%E5%88%86RRC%E8%BF%9E%E6%8E%A5%E5%A4%B1%E8%B4%A5%E6%AC%A1%E6%95%B0.htmlRRC.FailConnEstab.Cong/url原因为的连接失败次数当UE发RRC connection req，收不到RRC connection setup消息，当达到N300次数，还没有收到RRC connection setup，则RRC建立失败，原因值是“拥塞”。在网络建设初期，基本上不会发生拥塞，如果出现该原因，应该检查一下No

9、deB是否正常。4url=mkMSITStore:%E5%90%88%E8%82%A5%E5%87%BA%E5%B7%AE%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3LCR4.1%20DRNC820%20Performance%20Counter%20Reference.chm:/help/percounter/4.3.4.1.3%E6%8C%89%E5%8E%9F%E5%9B%A0%E5%88%86RRC%E8%BF%9E%E6%8E%A5%E5%A4%B1%E8%B4%A5%E6%AC%A1%E6%95%B0.htmlRRC.FailConnEstab.FPSy

10、nFail/url原因为的连接失败次数在为用户建立Iub口用户面时，RNC建立好DCH的FP之后，会发起FP同步过程，如果该过程失败，则认为RRC建立失败。如果出现FP同步失败，则需检查Iub口的用户面是否有问题。同时可以跟踪NodeB那边，是否收到了FP同步帧来确认上下行同步在哪一步出现了问题。5url=mkMSITStore:%E5%90%88%E8%82%A5%E5%87%BA%E5%B7%AE%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3LCR4.1%20DRNC820%20Performance%20Counter%20Reference.chm:/help

11、/percounter/4.3.4.1.3%E6%8C%89%E5%8E%9F%E5%9B%A0%E5%88%86RRC%E8%BF%9E%E6%8E%A5%E5%A4%B1%E8%B4%A5%E6%AC%A1%E6%95%B0.htmlRRC.FailConnEstab.NoReply/url原因为的连接失败次数当网络侧下发“RRCconnection setup”消息后，网络侧收不到“RRC connection complete”消息，则会导致RRC建立失败。一般需要排查空口上下行无线环境，例如：干扰、弱场等，6RRC.FailConnEstab.RlSetupFail原因为的连接失败次

12、数当Iub口出现问题，或NodeB直接回复RL建立失败，就会导致RL建立失败，从而导致RRC建立失败，原因值是“RL建立失败”。如果出现该问题，需检查一下NodeB是否正常。1.5PS RAB失败原因分析 话统对于PS域RAB建立失败次数进行统计，以XX全网2011/12/25到2011/12/31七天数据进行统计分析如下：对XXHW区8个RNC的7天数据进行汇总，得出原因值为PS域RAB建立失败次数无资源可用RAB.FailRabAssnEstabCs.114与无线接口进程失败RAB.FailRabAssnEstabCs.14这两个原因值失败较多，其余失败原因值中占比稍大的为PS域RAB建立

13、失败次数(最大速率不支持RAB.FailRabAssnEstabCs.20),具体统计分析如下： 通过上图，RNC02PS域RAB建立失败次数较多，RNC08中，最大速率不支持导致PS域RAB建立过程中失败次数较多。 全网RNC-PS域RAB建立失败原因值占比统计分析，可以看出PS域RAB建立失败（无线接口进程失败占比50%，无资源可用占比44%），其次为最大速率不支持导致失败占比为6%。各项RAB建立失败原因值分析： RAB建立失败 Count含义分析RAB.FailEstabPsPerCell.14原因为14(Failure in the Radio InterfaceProcedure)

14、的指配失败的分组域RAB数指配失败的分组域RAB数(小区级),为接口进程失败，指的就是我们通常意义上的空口问题，多数跟信号强度、质量等相关、天馈覆盖不合理，干扰、功率配置过小，C/I质量较差、载频有隐性故障，出来的信号可能不好、地物地貌影响，信号较杂乱。 处理方向：干扰排查、覆盖调整、载频故障排查RAB.FailEstabPsPerCell.19原因为19(Invalid RAB Parameters Value)的指配失败的分组域CN发给RNC的RAB指派消息中，RAB参数不符合协议。这种原因基本不会出现。如果出现需要进行参数核查。RAB.FailEstabPsPerCell.20原因为20

15、(Requested Maximum Bit Rate notAvailable)的指配失败的分组域RAB数最大速率不支持失败的原因是，在建立了完成RRC后，在进行RL重配置时出现的问题，一般都不是AMR业务出现的问题，PS业务出现该问题较多，无线资源拥塞造成。 处理方向：载波故障排查、话务均衡、申请速率配置、扩容。RAB.FailEstabPsPerCell.5原因为5(Tqueing Expiry)的指配失败的分组域RAB数排队定时器超时, 这种原因基本不会出现。如果出现需要进行参数核查。RAB.FailEstabPsPerCell.66原因为66(Iu Transport Connect

16、ion Failed toEstablish)的指配失败的分组域RAB数在为用户建立IU接口的用户面时，出现了某种错误，导致IU接口的连接建立失败。出现了这种情况时，需要检查IU口的通道是否正常。RAB.FailEstabPsPerCell.114原因为114(No Resource Available)的指配失败的分组域RAB数在小区拥塞、或者某种资源（比如HS）不足时，又不支持排队抢占，则会回复这种原因。 建议：url=扩容/urlU1 RAB.FailEstabPsPerCell.115原因为115(Unspecified Failure)的指配失败的分组域RAB数位置错误，故障排查、复

17、位。1.6TOP小区评估：图层1.61RRC接入失败TOP小区评估 TOP小区分布图如下： 下面是对TOP小区解决前后的RRC建立成功率的评估附：RRCTOP100小区.xlsx1.62RAB接入失败TOP小区评估 TOP小区分布如下 上图是对TOP小区解决前后的RAB建立成功率的评估附：RABTOP100小区.xlsx3.优化思路-（RNC12为例）3.1接入失败分析流程 3.3RRC建立成功率分析3.2.1TOP小区分布规律 通过多天数据汇总，以上TOP小区失败次数较多，以RNC12为例，具体分布如下： 通过分析，除去布瑞克大厦和中原区委_T6是由拥塞导致，其它小区失败原因值均为RRC.F

18、ailConnEstab.NoReply。重点排查：无线接口环境。3.2.2TOP用户分析 通过PCHR对12月30当天的TOP用户进行分析，当天能统计出IMSI的用户共有74个，相应RRC失败次数是193次，其中IMSI:460077294497440占40次，IMSI: 460077138378821占39次，属于TOP用户，其中信令，并且全部是在51中_T6（CI：42396）小区，且发生的接入原因值均为：UU_REGISTER。且失败原因值均为RRC.FailConnEstab.NoReply。 TOP用户分析主要作用在于看是否有高度集中的失败用户，通过联系用户处理的方式，实现精确点对

19、点的问题解决。TOP用户分析的关键在于是否可找到突出的用户，视具体情况可选择35个用户进行回访处理。3.2.3弱覆盖-接入电平分析 查看UE呼叫信令中，RACH测量报告接入小区PCCPCHRSCP，如果小于-95dbm,则说明该小区主要是由于弱覆盖导致的接入失败；通过对PCHR数据起呼电平进行统计，对RNC12-TOP小区进行分析，得出TOP小区的弱场起呼比例如下 通过统计分析，根据GT分流标准，RNC12内TOP小区中属于弱覆盖站点比例占33.33%，因此可以对弱覆盖小区进行天馈调整及功控参数调整，加强覆盖，提高起呼电平强度。3.2.4干扰-接入下行干扰分析 统计上行TS1;TS2的时隙干扰

20、值，若失败集中在ISCP大于-90dbm，则说明该小区主要是由于干扰导致的接入失败。 通过统计分析，在接入时ISCP值大于-90dbm的占比仅为1.55%,并且小区分布较为分散，因此接入上行干扰不是导致RRC建立成功率差的主要因素。虽然通过统计没有发现ISCP干扰，但是针对ISCP干扰类问题导致的接入失败，首先最为重要的工作就是需要找出主要干扰源，内部干扰进行频点和扰码的优化，外部干扰需要排查干扰源进而消除干扰，提升RRC建立成功率。3.2.5接入载频分析 通过PCHR工具，查看UE呼叫信令中，信令接入小区主要集中在那块载频上，目的在于统计出异常的频点，以及业务在小区内各频点是否平均，指导参数

21、设置。通过PCHR统计，小区(CI:42395)失败原因均为NOReply，该小区没有TOP用户，需对该小区载波等参数进行核查进一步发现问题。排查载频是否有干扰，频率规划是否合理。3.3RAB建立成功率分析3.3.1TOP小区分布规律 通过多天数据汇总，以上TOP小区失败次数较多，以RNC12为例，具体分布如下： 通过TOP小区的地理化显示，差小区主要分布在覆盖的边缘，需要结合测试情况对小区的覆盖进行控制调整。3.3.2TOP用户分析 通过PCHR对12月30当天RNC12的TOP用户进行分析，其中RAB失败次数较多的IMSI为460078380383212,终端类型为三星GT-I9008L手

22、机；IMSI为460027382080744，终端类型为中兴ZTE-T A356数据卡；失败占比相对较高。 通过对该用户进行分析，主要由于无效参数配置导致其RAB建立失败次数较多。需要对该用户进行详细信令跟踪，联系用户结合用户的无线环境问题复现定位。3.3.2TOP终端分析 根据3.3.2中TOP用户分析，可以得到TOP终端为三星GT-I9008L手机，针对该终端在RB建立过程中频繁建立失败问题进行分析。 该终端失败错误编码为：INVALID CFG ERROR BEGIN，通过PCHR数据分析可以看出，在PDP激活请求后NODEB向RNC发送NBAP RL_RECFG_CANCEL,并在之后

23、的RB建立过程中一直出现RB_SETUP_FAIL失败，这样，由于RNC向核心网发送RAB ASSIGNMENT RESPONSE，并携带错误原因，所以在接入统计中记为一次接入失败。分析发现此类问题不仅发生在三星GT-I9008L一款终端上，三星GT-I9008，三星GT-S5820等多款高端智能终端均同样出现类似问题，由于LCR5.0 RNC的规格设计不支持PS域3RAB，现网存在部分智能终端，智能终端能够发起3PS，会导致该问题的出现。此类问题需要RNC升级到LCR6.0版本，支持3PS。4 优化方法4.1RRC建立失败处理4.1.1拥塞 在RRC建立出现拥塞时，可以进行下面的操作：提高拥

24、塞小区的最小接入电平，限制部分低电平用户的接入：修改命令：MOD CELLSELRESEL: QRXLEVMIN=-96；打开LDC开关；对于业务量持续较大的小区，可以考虑建议扩容。(也可以观察周围站点，可以通过控制本站点及周围站点的覆盖，达到低话务小区对高话务小区的分流，缓解拥塞)4.1.2RL建立失败 针对RL建立失败比较多，可采取下面的措施进行处理：首先确认Node B小区运行是否正常，小区载波的运行状态，检查告警信息，检查是否存在小区退服、GPS失步或者公共传输信道不可用等告警，如果存在首先进行处理。现场复测，分析RadioLinkSetup Failure消息，定位失败原因，针对失败

25、原因进行相应的处理；4.1.3无应答 针对无应答问题，可以进行以下的处理：查看上下行ISCP值，确定和处理干扰问题；增大上行干扰余量ULINTERFERESV，该值用来调整和计算上行期望接受功率的大小，间接提高SRB/RB建立时上行期望接收功率；对于由于系统间重选导致的大量RRC失败，可以提高最小接入电平QRXLEVMIN或者降低空闲异系统重选门限IDLESEARCHRAT，使用户尽量驻留在T网。4.1.4FP同步失败 FP同步失败可能的原因：可能是Iub接口传输层配置错误；或者Iub接口的接线存在问题，导致FP同步失败；或者Iub带宽配置错误，在Iub接口出现拥塞；在出现FP同步失败问题时，

26、提交产品维护人员处理。4.1.5AAL2建立失败 出现Node B和RNC两个网元的传输层参数配置不一致的情况，导致出现RRC建立失败TOP小区。首先确认AAL2的参数配置是否正确；检查RNC和NodeB侧的PATH ID配置是否一致；检查RNC和NodeB侧的PATH ID配置是否一致。4.1.6其它 干扰因素 对于干扰需要进行监控，做到及时发现，及时处理。 环境因素 PS业务主要是在室内使用，如果没有配置室分分布系统，光靠室外基站覆盖室内，其PCCPCHRSCP的接受点评相对较低（可能低于-90dbm）。在这种条件下，对于PS业务的RRC建立成功率影响很大。在相同PCCPCH发射功率下，P

27、S业务的RRC建立成功率比CS业务的RRC建立成功率要低一些事正常的。 因此，如果PS业务的RRC接通率一直不高，可以查看覆盖区域的信号强度是否足够强，如果不够，可适当调高PCCPCH功率，或者是收缩覆盖范围（调高小区的驻留电平，把信号不够好的用户剔除出去）。4.2PS域RAB建立失败处理4.2.1最大速率不支持 在出现因为最大速率不支持导致PS域RAB建立失败时，占用的比例过大，可采用下面的措施进行优化：调整下行的最大初始接入速率，使接入的时候避免RAB拥塞；调整金/银/铜用户的保证速率，使大速率的PS用户如384K用户不至于由于超过满码道而导致接入失败和掉话的其它问题，将其最大初始接入速率

28、调整为128K；针对不支持H业务的数据卡，不能配置为大速率的上行数据业务。4.2.2无可用资源/拥塞 无可用资源，先要确定，是否存在码资源拥塞情况，或是通过查询IUB口传输资源配置情况，分别进行处理。码资源拥塞处理：针对TOP小区，查看载频和相对应的DSP使用情况,确定载频状态正常；对比小区业务量,如果发现是因为业务量过高导致，可以适度提高“最小接收电平/QRXLEVMIN”，减少部分用户接入；调整上下行最大初始接入速率，“ULBETRAFFINITBITRATE”和“DLBETRAFFINITBITRATE”，如果H业务上行码资源受限，可以将上行初始接入速率降到16K；根据拥塞用户的下行传输

29、信道类型确定拥塞用户中H和D的用户比例，如果是D用户拥塞较多，可以限定金银铜用户的最大速率；如果是H用户较多，可以针对个别小区扩容一个H频点，但要注意扩容H频点对周围小区的干扰；如果是H用户，建议将H频点的最大接入用户数设置为频点码资源最大能力，不建议设置超过最大能力的值。现网绝大大多数的H载频设置的最大用户数仍为8，可以将该值设置为7、或者6；RRC信令连接建立建立在FACH上面，减少由于随机接入如注册、附着、短信等占有DPCH信道的专用码道资源。IUB口带宽拥塞处理：（大部分站点已经IP化，还有个别站点为ATM站点）查询IUB口传输资源配置情况，是否存在资源配置不足情况；另外通过查询告警信息，确定是否存在E1/T1告警，导致可用E1/T1减少；确定E1/T1资源不足或者E1/T1告警，需推动E1/T1扩容或者告警处理。4.2.3UE无响应 跟踪用户CDT定位问题，确认RNC是否收到UE上报的RB配置完成消息；观测TOP小区的上下行干扰水平，避免由于个别小区干扰较大导致UE无相应；如果存在弱覆盖，优化重选参数，使UE尽快选到信号更好的小区；提高上行干扰余量“ULINTERFERERSV”，以增大开环功率；确定是否由于问题终端导致。4.2.4无线接口进程