TD PS接通率分析Word格式文档下载.docx
《TD PS接通率分析Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《TD PS接通率分析Word格式文档下载.docx（13页珍藏版）》请在冰豆网上搜索。
RNC08
99.69%
99.60%
99.29%
RNC09
RNC10
99.77%
99.62%
99.39%
RNC11
99.74%
99.67%
99.41%
RNC12
99.54%
99.61%
99.15%
RNC13
99.72%
99.46%
XX全网
99.25%
数据提取时间：
2011/12/25-2011/12/31七天，目前XXPS无线接通率为99.25%,其中RNC02为99.08%最差。
PS接通率指标亟待提高。
1.3.失败原因评估
由RNC在话统的相关统计点，对RRC和RAB建立失败的原因进行统计，对统计点的名称和相应的统计占比进行如下分析。
1.4PSRRC失败原因分析
以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失败次数及失败主要原因为RRC.FailConnEstab.NoReply与RRC.FailConnEstab.Cong的分布情况。
全网RNC失败原因值占比统计分析，可以看出RRC.FailConnEstab.NoReply占比最大。
需要排查空口上下行无线环境，干扰、弱场、拥塞及设备异常等
RRC建立失败不区分业务，话统中常见的RRC建立失败原因具体含义如下：
序号
RRC失败counter
含义
原因
1
[url=mk
MSITStore
:
\%E5%90%88%E8%82%A5%E5%87%BA%E5%B7%AE\%E6%8A%80%E6%9C%AF%E6%96%87%E6%A1%A3\LCR4.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.html]RRC.FailConnEstab.1[/url]
原因为<
拥塞>
的连接失败次数
当UE发RRCconnectionreq，收不到RRCconnectionsetup消息，当达到N300次数，还没有收到RRCconnectionsetup，则RRC建立失败，原因值是“拥塞”。
在网络建设初期，基本上不会发生拥塞，如果出现该原因，应该检查一下NodeB是否正常。
2
/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.html]RRC.FailConnEstab.AAL2SetupFail[/url]
AAL2建立失败>
为用户建立Iub口的用户面时，需先建立AAL2链路。
如果AAL2链路建立失败，则后续的FP、MACD等都无法建立。
如果出现AAL2建立失败，同样需要检查Iub接口的通道是否正常，例如：
PATH是否配置合理。
3
/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.html]RRC.FailConnEstab.Cong[/url]
网络拥塞拒绝>
4
/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.html]RRC.FailConnEstab.FPSynFail[/url]
FP同步失败>
在为用户建立Iub口用户面时，RNC建立好DCH的FP之后，会发起FP同步过程，如果该过程失败，则认为RRC建立失败。
如果出现FP同步失败，则需检查Iub口的用户面是否有问题。
同时可以跟踪NodeB那边，是否收到了FP同步帧来确认上下行同步在哪一步出现了问题。
5
/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.html]RRC.FailConnEstab.NoReply[/url]
无应答>
当网络侧下发“RRC
connectionsetup”消息后，网络侧收不到“RRCconnectioncomplete”消息，则会导致RRC建立失败。
一般需要排查空口上下行无线环境，例如：
干扰、弱场等，
6
RRC.FailConnEstab.RlSetupFail
RL建立失败>
当Iub口出现问题，或NodeB直接回复RL建立失败，就会导致RL建立失败，从而导致RRC建立失败，原因值是“RL建立失败”。
如果出现该问题，需检查一下NodeB是否正常。
1.5PSRAB失败原因分析
话统对于PS域RAB建立失败次数进行统计，以XX全网2011/12/25到2011/12/31七天数据进行统计分析如下：
对XXHW区8个RNC的7天数据进行汇总，得出原因值为PS域RAB建立失败次数无资源可用RAB.FailRabAssnEstabCs.114与无线接口进程失败RAB.FailRabAssnEstabCs.14这两个原因值失败较多，其余失败原因值中占比稍大的为PS域RAB建立失败次数（最大速率不支持RAB.FailRabAssnEstabCs.20）,具体统计分析如下：
通过上图，RNC02PS域RAB建立失败次数较多，RNC08中，最大速率不支持导致PS域RAB建立过程中失败次数较多。
全网RNC-PS域RAB建立失败原因值占比统计分析，可以看出PS域RAB建立失败（无线接口进程失败占比50%，无资源可用占比44%），其次为最大速率不支持导致失败占比为6%。
各项RAB建立失败原因值分析：
RAB建立失败
Count
分析
RAB.FailEstabPsPerCell.14
原因为14（FailureintheRadioInterface
Procedure）的指配失败的分组域RAB数
指配失败的分组域RAB数（小区级）,为接口进程失败，指的就是我们通常意义上的空口问题，多数跟信号强度、质量等相关、天馈覆盖不合理，干扰、功率配置过小，C/I质量较差、载频有隐性故障，出来的信号可能不好、地物地貌影响，信号较杂乱。
处理方向：
干扰排查、覆盖调整、载频故障排查
RAB.FailEstabPsPerCell.19
原因为19（InvalidRABParametersValue）的指配失败的分组域
CN发给RNC的RAB指派消息中，RAB参数不符合协议。
这种原因基本不会出现。
如果出现需要进行参数核查。
RAB.FailEstabPsPerCell.20
原因为20（RequestedMaximumBitRatenot
Available）的指配失败的分组域RAB数
最大速率不支持失败的原因是，在建立了完成RRC后，在进行RL重配置时出现的问题，一般都不是AMR业务出现的问题，PS业务出现该问题较多，无线资源拥塞造成。
载波故障排查、话务均衡、申请速率配置、扩容。
RAB.FailEstabPsPerCell.5
原因为5（TqueingExpiry）的指配失败的分组域RAB数
排队定时器超时,这种原因基本不会出现。
RAB.FailEstabPsPerCell.66
原因为66（IuTransportConnectionFailedto
Establish）的指配失败的分组域RAB数
在为用户建立IU接口的用户面时，出现了某种错误，导致IU接口的连接建立失败。
出现了这种情况时，需要检查IU口的通道是否正常。
RAB.FailEstabPsPerCell.114
原因为114（NoResourceAvailable）的指配失败的分组域RAB数
在小区拥塞、或者某种资源（比如HS）不足时，又不支持排队抢占，则会回复这种原因。
建议：
[url=]扩容[/url][U1]
RAB.FailEstabPsPerCell.115
原因为115（UnspecifiedFailure）的指配失败的分组域RAB数
位置错误，故障排查、复位。
1.6TOP小区评估：
图层1.61RRC接入失败TOP小区评估
TOP小区分布图如下：
下面是对TOP小区解决前后的RRC建立成功率的评估
附：
RRCTOP100小区.xlsx
1.62RAB接入失败TOP小区评估
TOP小区分布如下
上图是对TOP小区解决前后的RAB建立成功率的评估
RABTOP100小区.xlsx
3.优化思路-（RNC12为例）3.1接入失败分析流程
3.3RRC建立成功率分析3.2.1TOP小区分布规律
通过多天数据汇总，以上TOP小区失败次数较多，以RNC12为例，具体分布如下：
通过分析，除去布瑞克大厦和中原区委_T6是由拥塞导致，其它小区失败原因值均为RRC.FailConnEstab.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用户分析主要作用在于看是否有高度集中的失败用户，通过联系用户处理的方式，实现精确点对点的问题解决。
TOP用户分析的关键在于是否可找到突出的用户，视具体情况可选择3~5个用户进行回访处理。
3.2.3弱覆盖-接入电平分析
查看UE呼叫信令中，RACH测量报告接入小区PCCPCHRSCP，如果小于-95dbm,则说明该小区主要是由于弱覆盖导致的接入失败；
通过对PCHR数据起呼电平进行统计，对RNC12-TOP小区进行分析，得出TOP小区的弱场起呼比例如下
通过统计分析，根据GT分流标准，RNC12内TOP小区中属于弱覆盖站点比例占33.33%，因此可以对弱覆盖小区进行天馈调整及功控参数调整，加强覆盖，提高起呼电平强度。
3.2.4干扰-接入下行干扰分析
统计上行TS1;
TS2的时隙干扰值，若失败集中在ISCP大于-90dbm，则说明该小区主要是由于干扰导致的接入失败。
通过统计分析，在接入时ISCP值大于-90dbm的占比仅为1.55%,并且小区分布较为分散，因此接入上行干扰不是导致RRC建立成功率差的主要因素。
虽然通过统计没有发现ISCP干扰，但是针对ISCP干扰类问题导致的接入失败，首先最为重要的工作就是需要找出主要干扰源，内部干扰进行频点和扰码的优化，外部干扰需要排查干扰源进而消除干扰，提升RRC建立成功率。
3.2.5接入载频分析
通过PCHR工具，查看UE呼叫信令中，信令接入小区主要集中在那块载频上，
目的在于统计出异常的频点，以及业务在小区内各频点是否平均，指导参数设置。
通过PCHR统计，小区（CI:
42395）失败原因均为NOReply，该小区没有TOP用户，需对该小区载波等参数进行核查进一步发现问题。
排查载频是否有干扰，频率规划是否合理。
3.3RAB建立成功率分析3.3.1TOP小区分布规律
通过TOP小区的地理化显示，差小区主要分布在覆盖的边缘，需要结合测试情况对小区的覆盖进行控制调整。
3.3.2TOP用户分析
通过PCHR对12月30当天RNC12的TOP用户进行分析，其中RAB失败次数较多的IMSI为460078380383212,终端类型为三星GT-I9008L手机；
IMSI为460027382080744，终端类型为中兴ZTE-TA356数据卡；
失败占比相对较高。
通过对该用户进行分析，主要由于无效参数配置导致其RAB建立失败次数较多。
需要对该用户进行详细信令跟踪，联系用户结合用户的无线环境问题复现定位。
3.3.2TOP终端分析
根据3.3.2中TOP用户分析，可以得到TOP终端为三星GT-I9008L手机，针对该终端在RB建立过程中频繁建立失败问题进行分析。
该终端失败错误编码为：
INVALIDCFGERRORBEGIN，通过PCHR数据分析可以看出，在PDP激活请求后NODEB向RNC发送NBAPRL_RECFG_CANCEL,并在之后的RB建立过程中一直出现RB_SETUP_FAIL失败，这样，由于RNC向核心网发送RABASSIGNMENTRESPONSE，并携带错误原因，所以在接入统计中记为一次接入失败。
分析发现此类问题不仅发生在三星GT-I9008L一款终端上，三星GT-I9008，三星GT-S5820等多款高端智能终端均同样出现类似问题，由于LCR5.0RNC的规格设计不支持PS域3RAB，现网存在部分智能终端，智能终端能够发起3PS，会导致该问题的出现。
此类问题需要RNC升级到LCR6.0版本，支持3PS。
4优化方法4.1RRC建立失败处理4.1.1拥塞
在RRC建立出现拥塞时，可以进行下面的操作：
ü
提高拥塞小区的最小接入电平，限制部分低电平用户的接入：
修改命令：
MODCELLSELRESEL:
QRXLEVMIN=-96；
打开LDC开关；
对于业务量持续较大的小区，可以考虑建议扩容。
（也可以观察周围站点，可以通过控制本站点及周围站点的覆盖，达到低话务小区对高话务小区的分流，缓解拥塞）
4.1.2RL建立失败
针对RL建立失败比较多，可采取下面的措施进行处理：
首先确认NodeB小区运行是否正常，小区载波的运行状态，检查告警信息，检查是否存在小区退服、GPS失步或者公共传输信道不可用等告警，如果存在首先进行处理。
现场复测，分析Radio
Link
SetupFailure消息，定位失败原因，针对失败原因进行相应的处理；
4.1.3无应答
针对无应答问题，可以进行以下的处理：
查看上下行ISCP值，确定和处理干扰问题；
增大上行干扰余量ULINTERFERESV，该值用来调整和计算上行期望接受功率的大小，间接提高SRB/RB建立时上行期望接收功率；
对于由于系统间重选导致的大量RRC失败，可以提高最小接入电平QRXLEVMIN或者降低空闲异系统重选门限IDLESEARCHRAT，使用户尽量驻留在T网。
4.1.4FP同步失败
FP同步失败可能的原因：
可能是Iub接口传输层配置错误；
或者Iub接口的接线存在问题，导致FP同步失败；
或者Iub带宽配置错误，在Iub接口出现拥塞；
在出现FP同步失败问题时，提交产品维护人员处理。
4.1.5AAL2建立失败
出现NodeB和RNC两个网元的传输层参数配置不一致的情况，导致出现RRC建立失败TOP小区。
首先确认AAL2的参数配置是否正确；
检查RNC和NodeB侧的PATHID配置是否一致；
检查RNC和NodeB侧的PATHID配置是否一致。
4.1.6其它
干扰因素
对于干扰需要进行监控，做到及时发现，及时处理。
环境因素
PS业务主要是在室内使用，如果没有配置室分分布系统，光靠室外基站覆盖室内，其PCCPCHRSCP的接受点评相对较低（可能低于-90dbm）。
在这种条件下，对于PS业务的RRC建立成功率影响很大。
在相同PCCPCH发射功率下，PS业务的RRC建立成功率比CS业务的RRC建立成功率要低一些事正常的。
因此，如果PS业务的RRC接通率一直不高，可以查看覆盖区域的信号强度是否足够强，如果不够，可适当调高PCCPCH功率，或者是收缩覆盖范围（调高小区的驻留电平，把信号不够好的用户剔除出去）。
4.2PS域RAB建立失败处理4.2.1最大速率不支持
在出现因为最大速率不支持导致PS域RAB建立失败时，占用的比例过大，可采用下面的措施进行优化：
调整下行的最大初始接入速率，使接入的时候避免RAB拥塞；
调整金/银/铜用户的保证速率，使大速率的PS用户如384K用户不至于由于超过满码道而导致接入失败和掉话的其它问题，将其最大初始接入速率调整为128K；
针对不支持H业务的数据卡，不能配置为大速率的上行数据业务。
4.2.2无可用资源/拥塞
无可用资源，先要确定，是否存在码资源拥塞情况，或是通过查询IUB口传输资源配置情况，分别进行处理。
码资源拥塞处理：
针对TOP小区，查看载频和相对应的DSP使用情况,确定载频状态正常；
对比小区业务量,如果发现是因为业务量过高导致，可以适度提高“最小接收电平/QRXLEVMIN”，减少部分用户接入；
调整上下行最大初始接入速率，“ULBETRAFFINITBITRATE”和“DLBETRAFFINITBITRATE”，如果H业务上行码资源受限，可以将上行初始接入速率降到16K；
根据拥塞用户的下行传输信道类型确定拥塞用户中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无线接口进程
升级会员 