TD PS接通率分析.docx
《TD PS接通率分析.docx》由会员分享,可在线阅读,更多相关《TD PS接通率分析.docx(13页珍藏版)》请在冰豆网上搜索。
TDPS接通率分析
PS域无线接通率提升报告
1评估1.1PS域无线接通率概述
PS域无线接通率是集团考核的重要指标之一。
指标优劣间接反映了用户的感知。
ZZ的整体排名指标排名相对较靠后,低于全国平均水平。
XX在ZZ的指标较差,以XX为例进行评估分析。
1.2指标评估
XX各个RNC的PS域接通率指标-PS域RRC指标-PS域RAB指标如下:
定义:
PS域无线接通率=RRC无线接通率*PS域RAB建立成功率
XX
PS域RRC建立成功率指标
PS域RAB建立成功率指标
PS域接通率指标
RNC02
99.65%
99.43%
99.08%
RNC07
99.59%
99.63%
99.22%
RNC08
99.69%
99.60%
99.29%
RNC09
99.63%
99.59%
99.22%
RNC10
99.77%
99.62%
99.39%
RNC11
99.74%
99.67%
99.41%
RNC12
99.54%
99.61%
99.15%
RNC13
99.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.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
[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.AAL2SetupFail[/url]
原因为的连接失败次数
为用户建立Iub口的用户面时,需先建立AAL2链路。
如果AAL2链路建立失败,则后续的FP、MACD等都无法建立。
如果出现AAL2建立失败,同样需要检查Iub接口的通道是否正常,例如:
PATH是否配置合理。
3
[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.Cong[/url]
原因为<网络拥塞拒绝>的连接失败次数
当UE发RRCconnectionreq,收不到RRCconnectionsetup消息,当达到N300次数,还没有收到RRCconnectionsetup,则RRC建立失败,原因值是“拥塞”。
在网络建设初期,基本上不会发生拥塞,如果出现该原因,应该检查一下NodeB是否正常。
4
[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.FPSynFail[/url]
原因为的连接失败次数
在为用户建立Iub口用户面时,RNC建立好DCH的FP之后,会发起FP同步过程,如果该过程失败,则认为RRC建立失败。
如果出现FP同步失败,则需检查Iub口的用户面是否有问题。
同时可以跟踪NodeB那边,是否收到了FP同步帧来确认上下行同步在哪一步出现了问题。
5
[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.NoReply[/url]
原因为<无应答>的连接失败次数
当网络侧下发“RRC connectionsetup”消息后,网络侧收不到“RRCconnectioncomplete”消息,则会导致RRC建立失败。
一般需要排查空口上下行无线环境,例如:
干扰、弱场等,
6
RRC.FailConnEstab.RlSetupFail
原因为的连接失败次数
当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小区失败次数较多,以RNC12为例,具体分布如下:
通过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无线接口进程