厦门PS掉话问题初步分析
- 格式:doc
- 大小:578.00 KB
- 文档页数:20
Counter分析和处理异常事件原因分析1.CS掉话原因分析vs.iureleasereqcs.oamintervention原因解释和建议:OAM干扰。
当网络资源或接口被锁定,导致掉话时,建议检查OAM资源和接口是否被锁定。
vs.iureleasereqcs.unspecifiedfailure原因解释和建议:未定义的故障、无线承载重新配置期间的故障(RBR重新配置等),或产品内部问题导致的错误。
建议检查信令流程、Rb配置和UE端配置问题的正确性,或跟踪产品内部跟踪进行进一步分析。
vs.iureleasereqcs.repeatedintegritycheckfailure原因解释和建议:完整性保护检查错误:当安全模式下的完整性保护被激活时,出现完整性检查错误,导致后续RRC报文解码失败;建议检查RNC和CN的数据参数配置,并在问题区域进行拨号验证测试,以正确配置参数。
vs.iureleasereqcs.uegeneratedsignallingconnectionrelease原因解释和建议:在建立认证的过程中设置RNC和RNC的认证参数的原因是CSC RRC发送到网络的认证消息失败。
vs.iureleasereqcs.radioconnectionwithuelost原因解释和建议:UE的无线链路丢失。
在UE和RNC之间建立无线链路。
由于上行链路失步,NodeB向RNC发送上行链路无线链路故障指示。
建议检查无线环境,尤其是上行索引。
vs.iureleasereqcs.abnormalconditiontimerrelocexpiry原因解释和建议:对于原因值为trelocoveralexpiry的异常,由于硬切换期间MSc计时器超时,硬切换失败。
建议调整MSc定时器的持续时间。
vs.iureleasereqcs.othercause原因解释和建议:由于其他未定义的原因,建议跟踪过程分析。
vs.iureleasereqcs.dlrlcerrsrb原因解释和建议:SRB上的下行链路RLC错误。
子帧配比不同导致掉话分析和问题处理1 现象描述室分系统,电梯门口天花板上有一个天线,主要覆盖电梯门口的信号(PCI=500,图中圆圈即为天线位置,PCI为500的小区覆盖电梯门口和1F-10F),测试时所在楼层为14楼,楼层内的信号由另外一个小区覆盖(PCI=501)。
除电梯口前通道外,整层楼的信号都比较强RSRP在-60~-75之间,SINR>24,室分打点测试时,一旦路过电梯口,特别是在电梯口天线下,RSRP会降低到-141,SINR也会降到-10,出现掉线的情况。
测试的时候两部终端同时测试,一部上行,一部下行。
2 告警信息无3 原因分析1、初步分析认为可能是RS功率设置过大导致干扰。
因为整层楼的室内区域比较小(在30平米左右),两个小区存在交叠覆盖,产生相互干扰。
所以首先将PCI为500的小区的RS功率降低3dB,发现掉话的情况同样存在,证明和RS功率关系不大;2、继续分析是否两个小区之间的相互邻区漏配了,导致掉话。
后经查看信令发现终端并不存在MR上报不处理的情况,并且后台核查邻区配置后确定两个小区的双向邻区均已经配置,则排除邻区漏配问题。
3、由于初步简单分析并没有查到原因,所以后面进行更详细的分析。
4 处理过程1、首先确定掉话问题,根据测试的结果显示,在电梯厅门口RSRP会突然陡降,然后掉话;2、排除邻区漏配的原因。
邻区已配置且参数配置正确,可排除邻区漏配导致掉话的情况。
因为刚开站,参数都是按照规划参数进行配置的,没有仔细的核查所有的参数配置;3、排除设备告警方面的原因。
核查操作日志,设备故障,告警和外部事件进行核查,没有设备故障,之前的告警也已经消除,没有发现问题;4、排除上行干扰原因。
由于之前的步骤都没有查出问题,所以接着就怀疑是不是因为存在干扰,所以进行了NI跟踪,结果是环境很干净,干扰问题排除;5、核查网规网优参数。
在核查的时候,就发现了一个问题,PCI为500的小区配置的子帧配比为SA1(2:2),而PCI为501小区配置的子帧配比为SA2(3:1),由于PCI为500的小区不光覆盖电梯门口,同时也覆盖1楼至10楼,而7楼为提高上行速率,修改了子帧配比。
1.1.1RNC级PS掉话1、出现RNC级掉话后,首先需确定该RNC级的掉话是由多个小区引起的,还是由个别高掉话的小区所导致。
如果是由个别小区引起的,应进行小区级的掉话处理步骤,否则进入网元级的掉话处理过程。
2、检查RNC的系统告警,检查是否存在相关硬件的告警信息,如果存在单板的告警,则需要进行排除。
3、从流量、HS的RAB增加数量、HS的掉话数量几个方面看,整体PS掉话率是否和HSDPA用户增加,HS高掉话率有关。
此次厦门PS掉话率急剧抬升就是由于HS用户/HS业务量增加有关。
4、在OMM上对PS掉话的原因进行统计,重点分析是哪种原因突然增多。
如果是operate_timeout原因的掉话数量很大,则通过CT查看是否是HSDPA与DCH信道之间切换超时掉话。
这类关键小区大多处在HSDPA小区的边缘,如果存在大量1、2载频的小区(都没有开通HSDPA),HSDPA数据卡在切换过程中容易发生operate_timeout,通过开通HSDPA后,可以规避一些掉话的发生。
下面是对物理信道或是RB重配置超时以及CELLUPDA TE的原因分析:物理信道重配置超时或RB重配置超时(Ue_Operate_TimeOut)对于物理信道重配置超时或RB重配置超时,常见的有以下几种可能性:✓存在UPPCH的干扰,如果是硬切换的情况下会造成随机接入过程的失败,从而造成物理信道重配置失败,Cause值为2。
✓HS业务与R4业务之间的切换失败,包括从R4到R5的切换和从R5到R4的切换,这种原因主要表现为RB重配置超时。
✓虚假的邻小区关系造成物理信道重配置超时✓RB重配置参数设置不合理造成RB重配置超时✓功率参数配置不合理造成RB或物理信道重配置超时目前外场常见的原因主要是终端问题和R5与R4业务之间的切换问题。
UeReportCellUpdate产生CellUpdate的直接原因是UE判断下行失败造成,当UE在一定的时间内没有收到系统下发的消息,会认为下行无线质量恶化导,进一步判断下行失步后,此时UE会上报小区更新(CellUpdate),网络侧根据小区更新的目标小区分配无线资源,因此小区更新(CellUpdate)有两种可能性:✓第一种可能性,小区更新(CellUpdate)发生在本小区,如果来自在当前归属小区,出于规避下行干扰的考虑将为终端分配新的物理资源,如果此时该小区剩余资源不足时,会出现小区更新资源不足而导致掉话。
VoLTE 百日会战KPI 优化-W17重点巡检项目第一批巡检的城市7项集团关注的重点指标大体能达到或超过集团要求。
DT KPI 依照目前集团的要求临时没有太大压力,各项目如有省内评比的压力,请踊跃反馈省内竞争对手的指标情形。
请严格依照各省客户要求的线路进行测试。
F-ASB 区域下周开始将不在上报上海项目情形,缘故为上海f-ASB 区域为三方负责一体化优化工作。
指标问题掉话率福州 2.03% 厦门 4.73% 上海 1.87%福州、厦门初步判定与本次测试采纳的大唐 ATU 设备问题有关。
另外厦门网络进行MME POOL 扩容工程,新站入网也较多,没来得及优化,致使掉话率也比较高。
上海初步判定测试终端问题,终端不到时刻主动发送Bye ,致使掉线>3.0 MOS 占比(%) 福州 % 厦门 83.03%福州、厦门初步判定与本次测试采纳的大唐 ATU 设备问题有关。
厂家指标来源是否为客户指定测试路线当前测试终端类型当前测试终端版本平均RSR P平均SIN RMoS平均值>3.5 MOS占比>3.0 MOS占比(%)VoLTE呼叫建立时延(s)RTP丢包率RTP抖动接通率(%)掉话率(%)IMS注册成功率(%) eSRVCC 切换次数eSRVCC 成功率(%)eSRVCC 切换时延-用户面(ms)8549719897350NOKIA DT N HTC M8T 3.59.1403.2-89.80 12.79 3.8786.30 97.29 3.37 1.3016.52100.000.00100.001100.00 125.00NOKIA DT Y HTC M8T 3.51.1403.2-86.7716.91 3.6770.5481.96 3.040.3816.4299.77 2.03100.0013100.00 300.50NOKIA DT Y HTC M8T 3.51.1403.2-80.3715.48 3.6471.2883.03 3.110.147.7999.37 4.7398.159100.00 404.00NOKIA DT Y HTC M8T 3.51.1403.2-85.26 14.86 3.7581.87 91.73 2.780.7415.4698.310.62100.006100.00 NOKIA DT Y ATU+N11_01.6900RPD_CN -80.2514.59 3.8484.7095.34 2.91 1.8417.12100.000.42100.000 no Esrvc HO No updateNOKIA DT Y HTC M8T 3.59.1403.2-82.33 15.69 3.96 91.69 97.16 2.14 0.22 7.74 99.68 0.27 100.00 0 no Esrvc HOHW DT N ATU-89.7914.15 3.8396.6891.56 4.00 1.01 5.5699.26 1.87100.001994.74260.00fASB DT Y HTC M8T 3.59.1403.2-80.66 20.01 3.94 91.92 97.95 2.70 0.32 4.59 100.00 0.00 100.00 0 no Esrvc HO fASB DT Y HTC M8T 3.59.1403.2-85.0014.00--- 3.600.85-100.000.85100.005100.00235.19fASB DT Y HTC M8T 3.59.1403.1-84.0816.28 3.8473.9489.60 1.930.72-100.000.00100.000 no Esrvc HO HWDTY ATU-83.4513.32 3.6275.4588.93 2.89 1.6814.68100.000.42100.004100.00172.00NOKIA DT Y HTC M8T 3.59.1403.2-78.5617.34 3.9085.24 93.10 2.800.8317.54100.000.00100.000 no Esrvc HO NOKIA DT Y HTC M8T 3.59.1403.2-81.2216.42 3.49-91.29 3.58--100.000.8396.002100.00NOKIA DT Y HTC M8T 3.59.1403.2-88.8617.14 3.770.840.92 2.380.9412.0199.360.48100.0054100.00171.00NOKIA DT Y HTC M8T 3.59.1403.2-80.0217.14 3.910.9096.58 3.150.9814.6499.140.00100.000 no Esrvc HO 0.00NOKIA DT Y HTC M8T 3.59.1403.2-69.35 16.77 4.0192.93 96.88 2.340.708.8998.610.74100.000 no Esrvc HO NOKIA DT Y HTC M8T 3.59.1403.2-85.93 17.91 3.68 88.57 94.28 2.51 0.95 5.89 98.76 0.71 100.00 0 no Esrvc HO NOKIA DT Y HTC M8T 3.59.1403.1-80.41 16.03 3.90 89.54 97.27 2.25 0.60 9.30 100.00 0.97 100.00 0 no Esrvc HONOKIA DT --------------NOKIA DT YHTC M8T 3.59.1403.282.2514.87 3.8886.4795.74 2.110.8478.00100.000.00100.000 no Esrvc HO-NOKIA DT ---0.910.96 6.370.008.07 1.000.00100.00---NOKIA DT--------------低于集团要求Top3第一批测试城市第二批测试城市暂无合同或客户无要求福州ATU通道异样,网格3/6/7/8/9/16低于90%,其余网格均高于90%厦门2套大唐ATU设备中一套测试的只有40%左右,致使全网的MOS值较低eSRVCC成功率(%)上海 94.74%上海初步判定测试终端问题Sharing江西网管VoLTE掉线高问题江西RLF延迟按时器屏蔽盒验证有成效,修改SWconfig文件内参数,可延长到15s左右释放,指标评估还在进行中,由于VoLTE呼唤数量少,临时成效不明显。
几种典型的掉话场景分析场景1:邻区漏配,终端无法切换到最强小区终端测量的,最强小区为PCI为241的河西大沽南路麦田-1。
切换的目的小区,为PCI为264的小区。
由于PCI=264的小区信号质量偏弱,导致终端搜索不到,因此,切换失败。
随之,终端发起RRC连接重建,重建小区为PCI为241的河西大沽南路麦田-1。
RRC重建失败,终端掉话。
图2-1 终端切换到非最优小区,导致切换失败场景2:邻区漏配,终端无法发起切换终端一直上报测量报告给基站,但是基站没有响应。
终端掉话,随之发起RRC连接重建,重建立小区为测量报告中的上报小区。
图2-2 最优小区不在邻区关系列表,导致掉话场景3:外部邻区关系中PCI标识配置错误,终端切换到次强小区终端上报,PCI为240和168小区信号质量给基站。
切换的目的小区,为次强小区,PCI=168由于PCI=168小区,干扰严重,随着终端的挪动,终端无法搜索到该小区,因此,导致终端切换失败。
终端切换失败后,发起RRC连接重建,RRC连接重建的小区,为河西大沽南路麦田-0小区。
但是,由于河西大沽南路麦田-0小区,并不是终端切换的目的小区,导致重建立失败,因此,终端发生掉话。
终端之所以,发起到次强小区168的切换原因在于,基站根据,PCI=240,查询外部邻区关系列表时,发现并不存在这样的外部小区。
因此,终端就发起到PCI 168的小区的切换。
归根结底的原因在于,下瓦房的外部邻区关系列表中,河西大沽南路麦田-0的PCI值配置错了,需要修改为240。
场景4:外部邻区关系中,基站标识配置错误,导致切换失败终端一直,上报测量报告给基站,指示PCI为6的河西洞庭路小区满足,切换条件。
可是,基站并无反响。
终端上报,测量报告给基站,其中包含PCI为0的河西小海地还迁居住区-0。
基站发起,到河西小海地还迁居住区-0的切换。
切换失败,在PCI为6的河西洞庭路小区发起RRC连接重建,但是,RRC连接重建立失败。
流程图掉话处理处理流程操作手册1、由小区性能监控模块发现小区掉话数多2、排查硬件故障如果掉话率突然上升,则需要检查本小区和相邻小区此时是否工作正常,通过OMC-R检查本小区和相邻小区告警,传输和天线是否出现异常,排除因为硬件原因产生的小区异常掉话。
解决措施:派单处理3、覆盖欠佳引起的掉话了解该小区的覆盖区域,是否存在一定的覆盖欠佳区域,覆盖欠佳是造成下行弱信号掉话的一大原因。
原因分析:服务小区由于各种原因(如无线环境好,功率过高,站点设置太高)产生越区覆盖,导致UE在移动到被越区覆盖的小区后,因无邻区关系配置,导致无邻区可切换造成的弱信号掉话。
越区覆盖导致的频率干扰和扰码相关性问题。
波导效应和湖面效应会使服务小区覆盖过远,引起干扰或切换判断混乱,产生掉话。
由于孤岛效应,处于孤岛的UE 无法切换出去,产生掉话。
由于一个地方没有一个足够强的主导频,出现导频污染,手机通话过程中,乒乓切换会比较严重,导致掉话率上升。
两个小区交接部分出现明显的无信号覆盖的漏洞,UE移动出覆盖范围,产生掉话。
由于高大建筑物遮挡产生的阴影效应。
解决措施:消除越区信号的影响:通过路测同事了解掉话小区及周围覆盖情况,查找覆盖不规范的基站,通过调整该站的下倾角,方位角,或降低它的最大发射功率等方法来优化覆盖区域,同时避免基站天线沿街道或湖面覆盖,避免街道效应和湖面效应等产生难以控制的信号,消除漂移信号对其它基站的影响.查找覆盖不足的地区:通过投诉组同事和路测同事的场测试来查明覆盖不足的地方,看是否可以通过调整下倾角,方位角,挂高,以及发射功率等方法增大覆盖范围(这需要综合考虑频率、扰码规划以及其它方位覆盖的情况)。
如果弱场区处于商场、隧道、地下停车场、地铁入口、高层建筑等特殊场合,则需要增加RRU,或室内分布来解决。
4、小区数参数配置不合理引起掉话检查小区各系统参数有无配置得很不合理,可以能过与正常小区之间的参数进行对比,找出是否出现个别参数调得很不合理面导致的。
同PN问题的解决方案摘要自从接手CDMA网络以来,中国电信在全国开展了大规模的网络建设,使得城区覆盖率大幅度提升。
但是在大城市,尤其是密集城区,由于特殊的地理场景造成PN复用掉话问题也越来越突出。
由于掉话问题严重影响用户感知,因此如何定位和解决不同场景下解决同PN问题显得迫在眉睫。
关键词:CDMA 特殊场景同PN问题掉话1概述在CDMA系统中,PN又称伪随机码,是长度为215-1的M序列,用于对前向链路进行正交调制,不同的小区使用不同相位的M序列进行调制,其相位差至少为64个比特,这样,最多有512个不同的相位可用。
1.1PN规划原则PN码用于区分小区,因此需要给每个小区分配一个PN码。
同PN类似于GSM的BCCH,同PN两个小区之间的复用距离应该足够大,以避免同PN混淆问题;同时由于PN短码在传播路径中会带来时延,相邻PN可能会出现混淆,因此在PN规划中应避免同PN或邻PN混淆。
PILOT_INC决定了可用PN个数,在可用PN数量有限的情况下,一个网络中需要对PN 进行最大可能的复用,在复用同时又要避免同PN或邻PN混淆,如下图:◆同PN混淆理论上相同PN小区之间的复用距离应至少间隔4层站点以上,大于5倍小区半径;◆邻PN混淆邻PN小区在终端侧的相对距离差必须小于PNINC/2所对应的光传播距离,如下图所示:图1Δd图示如终端接收到来自A和B小区的信号距离差Δd大于PNINC/2*64*0.245km,且A和B使用邻PN,则产生邻PN混淆问题,造成终端在本PN和邻PN之间产生误判。
表1邻PN混淆距离差对应表1.2PN规划不合理可能导致的问题CDMA协议规定BSC下发的邻区列表中的PN不能存在重复,且不能与激活集PN重复。
One way/two way问题可能会造成终端切换失败、掉话等。
PN资源紧张会增加one way/two way出现的可能性。
对于处于单分支状态下。
若同PN复用距离过近引起的异常邻区配置,定为1-way邻区。
WCDMA日常投诉处理优化典型问题和解决方案1、用户反映果超市信号不好现场对W果超市站点1楼电器和首饰卖场以及楼层覆盖信号测试,由于针对室覆盖信号进行测试分析,分析数据发现果超市一楼,信号覆盖很差,经过检查基站硬件和配置,发现基站运行正常,而1楼电器和首饰商场没有安装室天线,测试1楼如下:优化前【问题分析】针对室覆盖信号进行测试分析,分析数据发现果超市一楼,信号覆盖很差,经过检查基站硬件和配置,发现基站运行正常,而1楼电器和首饰商场没有安装室天线,因而导致一楼卖场信号强度差,出现投诉问题。
【优化方案】增加果超市一楼卖场的室覆盖天线。
经过增加天线后,再次测试,信号有了明显改善,同时对该路段造成的导频污染也有了明显改善,具体如下:果超市一楼室覆盖改善情况:优化后由此可以看出优化效果明显,针对信号覆盖比较差,没有安装室天线,切换频繁进行增加天线。
2、用户反映在马鞍方明珠小区四村7栋202室无信号,手机不能使用。
【问题描述】马鞍方明珠小区四村7栋202室无信号,手机不能使用。
【问题分析】11月5号下午前往现场处理,由于用户不在家无法进行室测试,经室外测试发现所处区域(明珠小区四村7栋)的3G信号覆盖较差,发现该区域3G信号RSCP均在-105dbm左右,如下图:图一 明珠四村道路RSCP 覆盖图图二 明珠四村地理位置图结合明珠四村的地理位置图可以看到,7栋处于小区的中央地带,四周均被其它建筑所阻挡,导致7栋室3G 信号覆盖较弱。
【优化方案】东方明珠四村7栋小区道路东方明珠四村7栋建议加站。
3、W_新桥宁西-3 RRC建立失败原因分析问题描述:11月1日W_新桥宁西-3 RRC建立失败次数较多,具体如下:W_新桥宁西-3 RRC建立失败原因表3问题分析:由上图可以看出,RRC建立失败的主要原因是小区中因无应答而导致的,而小区中因无应答而导致RRC连接失败的原因一般为覆盖较弱导致。
分析CHR,发现W_新桥宁西-3 RRC 建立失败全部为一个用户导致的,如下图:可以看出,W_新桥宁西-3 RRC建立失败全部为一个用户(UE ID: 460017002731026)导致的。
厦门PS掉话初步分析背景 (2)测试环境 (2)测试情况 (2)测试过程记录 (3)<测试1> 短呼测试(short call) (3)<测试2> 长呼测试(long call) (5)<测试3> 长呼测试(long call) (9)<测试4> UserA,UserC短呼测试,UserB 长呼测试 (11)<测试5> UserA,UserB,UserC长呼测试 (13)<测试6> UserA,UserB,UserC异常(人为故意模拟)测试 (15)附测试基站当天的OMC统计 (17)小结 (19)背景由于现场OMC统计鼎桥区域PS drop rate非常高,60%,从之前RNC的Iu trace看,主要原因都是RABrelease和IuRelease,而信令里面带的原因都是”Unspecific error”。
此外与研发的电话会议中,研发多次强调干扰的可能性,为此,外场在2009/2/29号进行外场测试:目的想探查Iu口发起rabrelease和Iu release真正原因,同时验证PS相关计数器OMC统计是否正确。
测试环境无线环境:为了屏蔽无线环境的影响和周围其它基站的干扰,我们挑了一个室内孤站(O3),其附近没有其它室外站,且测试地点就在室内分布天线的正下方,此外通过OMC统计,该站一个月几乎没有任何话务量,因此除了测试人员外,也不存在其它R4或者H业务影响,因此该基站无线环境已经接近或等同绝对理想化情况。
测试情况时间:2009/2/19 10:00~15:00,为了和OMC上同步,每次测试按整点进行分组,为了控制临街时间段,测试的起点是每小时07分左右,终点是每小时的55分钟;终端(HSDPA卡):UserA(尾号99700):大唐永胜UserB(尾号28876):新邮通UserC(尾号28875):大唐DT5731测试过程记录<测试1> 短呼测试(short call)建立PS业务后保持5~15秒不等,断掉连接后,间隔10秒左右重新接入;时间段:2009/1/19 (10:40~10:55 AM)测试1--外场人员手动测试记录UserB 从10:40:49~10:55:42进行17次成功RAB建立,但在第7次时在RAB释放时发生错误没有拨打RNC统计:RAB Request:34次RAB Response(succ):34次(Fail)0次RAB Release(异常): 1次:在RAB成功建立42秒后异常RAB releaseIu Release(异常共4次):都在用户“断掉连接”时产生疑问:按照RNC trace的分析,应该是17+17=34次RAB Attempt,17+17=34次RAB 成功建立;而因为UserA(由于disconnect时,导致发起的Iu release 4次)和UseB(RAB 刚成功建立后RNC发起的RAB release 1次),如果按照理解RNC主动发起的rabrelease和Iurelease就算掉话的话,应该是总共5次掉话,和OMC统计的7次相差2次。
然后从OMC 原因分类看,UseB的那次RAB relase(原因应为misc: 0x73 (115): unspecified failure)被算成RAB.RelReqPS.RbReset。
UserA导致的4次Iu Release(原因应为radioNetwork: 0xe(14):failure in the radio interface procedure)在子原因中没有,总和上有,但不知为什么在总数上OMC统计多两次。
注:确认除了测试用户外无其它用户。
<测试2> 长呼测试(long call)建立PS业务后保持45分钟不变,过程中3用户进行IE网页浏览,ftp下载等,如果连接断掉后,手动重新连接。
主要是模拟普通用户长时间上网过程:时间段:2009/1/19 (11:07~11:50 AM)测试2--外场人员手动测试记录测试2--后台人员RNC trace分析UserA大唐永胜分析:与在现场测试用户感觉不同(接入成功后,一直就没有断,能正常上网),但RNC上看发生多次失败:第一次:RAB release 原因“misc: 0x73 (115): unspecified failure“RAB建立19分钟后,RAB异常释放第二次:IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为鉴权Reject而发起异常Iu release??第三次:IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure Cell update完成后马上rnc发起 Iu release???UserB新邮通分析:与在现场测试用户感觉不同(接入成功后,一直就没有断,能正常上网),但RNC上看发生多次失败:第一次:IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure Cell update完成后马上rnc发起 Iu release???第二次:IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure Cell update完成后马上rnc发起 Iu release???UserC大唐5731分析:与在现场测试用户感觉不同(接入成功后,一直就没有断,能正常上网),但RNC上看发生多次失败:第一次:RAB release 原因“misc: 0x73 (115): unspecified failure“第二次:RAB release 原因“misc: 0x73 (115): unspecified failure“RAB建立5分钟后,RAB异常释放第三次:IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为鉴权Reject而发起异常Iu release??第四次:IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为RL Fail,异常Iu release??第五次:IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为RAB建立失败(失败原因也是failure in the radio interface procedure)导致IuRelease按照trace统计在11:00-12:00这个小时中,共发起12次RAB Request,其中2次失败,10次成功;3次异常RAB Release,7次异常Iu Release。
注:确认除了测试用户外无其它用户。
结论:这一次测试结果显示OMC统计结果和RNC trace统计相差很大,几乎觉得OMC 统计完全错误!!!<测试3> 长呼测试(long call)建立PS业务后保持45分钟不变,过程中3用户不进行任何操作,如果连接断掉后,手动重新连接。
主要是模拟普通用户长时间不上网但一直挂着(保持连接建立)的情况:时间段:2009/1/19 (13:07~13:50 AM)测试3--外场人员手动测试记录测试3--后台人员RNC trace分析UserA:大唐永胜异常分析异常Iu Release失败3次,情况一样,都是cell update流程结束后RNC发起Iu ReleaseUserB:新邮通异常分析异常Iu Release失败1次,和UserA一样也是cell update流程结束后RNC发起Iu ReleaseUserC:大唐5731异常分析(无)测试3-长呼测试事件记录(根据RNC Trace)建立成功;4次异常Iu Release掉话。
按照RNC Trace,共6次RAB建立请求,6次RAB结论:考虑到UserA大唐永胜在13:02不小心拨了一次,因此OMC统计比RNC多一次正常,此次RAB建立次数和成功次数和RNC一致。
但掉话OMC统计为0次,RNC trace上看应该为4次,OMC在本次测试中掉话相关计数器仍然不准!!!<测试4> UserA,UserC短呼测试,UserB 长呼测试目的:a:通过短呼测试继续比较OMC统计b:在测试3中,UserB异常掉死,因此UserB依旧进行长呼(不作任何操作,保持无数据流量)RNC统计:RAB Request:88次RAB Response(succ):86次(Fail)2次RAB Release(异常): 2次Iu Release(异常共12次):鉴权过程(无RAB过程)中3次RAB建立后,隔几秒就IuRelease 6次CN几乎在同时又RAB请求又RAB释放,有2次IuReleaseRAB请求后,RAB建立失败(Fail),但同时也出现1次IuRelease 测试4--OMC后台统计结论:尝试次数仍然统计偏高;RAB release这次争取;IuRelease依旧不对,同时也疑惑OMC统计的SRBReset 3次到底是对应RNC信令哪3次?<测试5> UserA,UserB,UserC长呼测试目的:a:通过短呼测试继续比较OMC统计b:3个UE不作任何操作,保持无数据流量RNC统计:RAB Request:6次RAB Response(succ):6次(Fail)0次RAB Release(异常): 0次Iu Release(异常共3次):都在cell update流程中失败结论:OMC统计中RAB建立次数和成功次数和UE trace一致,但只统计一次掉线;由于只有UserA发生3次Iu release,如果一定要比较3个不同,就是UE trace上看到的3次Iu_release中,第1次IU_release,面前的信令流程中出现了PDP 激活并成功,但在第2、3次IU_release,面前的信令流程中并没有出现PDP 激活请求,只有RABAssignmentReq。
那么:1、业务建立成功是否以PDP激活成功为准?2、OMC统计PS掉线时,是否只统计在PDP激活成功后,出现IU_release或RAB_release次数?3、假如UE trace中的3次IU release都应该计算为PS掉线,OMC统计与UE trace的结果不一致。