厦门PS掉话问题初步分析
Counter分析和处理
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楼为提高上行速率，修改了子帧配比。
PS掉线处理思路树(中兴)
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）发生在本小区，如果来自在当前归属小区，出于规避下行干扰的考虑将为终端分配新的物理资源，如果此时该小区剩余资源不足时，会出现小区更新资源不足而导致掉话。
掉话的一些原因
合理优化邻区
调整切换参数
4）由于干扰而导致的掉话
原因分析：
同频、邻频
直放站带来的干扰
外来干扰
硬件故障带来的干扰
解决措施：
同频、邻频干扰是GSM系统主要干扰，需要通过良好的频率规划、天线调整、功率控制综合解决
对直放站带来的干扰，需协调直放站厂家严格控制好直放站的覆盖范围。
2）、由于覆盖原因导致的掉话
原因分析：
基站较少，覆盖面积过大，造成覆盖问题
两小区交界的地方出现覆盖漏洞
硬件故障导致覆盖过小
高大建筑物阻挡造成覆盖问题
邻区定义不全造成无法切换到更好小区
越区覆盖造成无法切换到更好小区
查找覆盖不足的地方，根据实际情况增加基站、直放站、室内分布系统
调整现网基站覆盖方位角和下倾角，调整网络参数（基站发射功率、手机最小接入电平、小区相邻关系等），改善覆盖不好的地方
6）、参数设置不当引起掉话
可通过参数检查工具来检查参数设置是否合理，如频率的规划是否合理；跳频的频点是否存在干扰；关键计数器的设置；无线链路失效计时器、邻区定义是否错误、是否有同频同BSIC。检查出参数错误或者不当后，需尽快处理解决。
）、由于上下行不平衡引起的掉话（塔放、功放、天线方向）
无线信号根据传播方向分为上行和下行两个方向，在理想情况下上下行链路是平衡的，即在任何区域基站侧和手机侧均可以同时收到对方的信号，或者同时无法收到对方的信号。由于无线信号传播路径的不确定性以及实际环境的差异，在整网范围内完全实现无线链路上下行平衡是不可能的。因此网络中必然存在下行信号可以覆盖而上行信号无法覆盖到的区域，在这些区域内，用户可以收到网络侧的消息而网络侧无法收到用户手机上报的消息。
VoLTE百日会战KPI优化周报W17(002)
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连接重建立失败。
组合业务(PS+CS)掉话分析
无数据 业务传输 ， Ｐ Ｓ域 用 户 空 闲 ， Ｒ ＮＣ 会 将 ＵＥ 状 态 由
Ｉ ｕ 承 载 完成 的 。Ｒ Ａ Ｂ、 Ｒ Ｂ 、 Ｉ ｕ的 异 常释 放 都会 导 致 终端 掉 话 。 分析 Ｖ Ｉ Ｐ用 户 的 日常使 用 业 务 数 据 ，发 现 掉 话 类 型 中最 多 的是 组 合 业 务 ， 占比 ７ ８ ． ７ ９ ％； 其 次 为单 Ｃ Ｓ业 务 ， 共 ７次 ， 占
— ＿
根据签约用户数据 、 Ｃ Ｎ业务能力和 Ｕ Ｅ业 务 请 求 的 Ｑ ｏ Ｓ的 不 同使 用不 同的 Ｒ Ａ Ｂ 所以 Ｕ Ｅ与 Ｃ Ｎ之 间有 多 少业 务组 合 就 有
多少 条 ＲＡＢ ＲＡＢ在 ＵＥ 和 ＲＮＣ之 间 的传 输 是 通 过 ＲＢ来 实
且 后 面 做 了 位 置 区更 新 和 鉴 权 流 程
广应 用价 值
（ １ ） 产生掉话 ， Ｒ Ｎ Ｃ发 起 无线 资源 释放 ； （ ２ ） 如果 Ｕ Ｅ 处 于软 切 换 或更 软 切 换 。 Ｒ Ｎ Ｃ删 除 一条 链 路 ．
２ 组合业 务案例 分析及效 果
２ ． １ Ｖ Ｉ Ｐ数据 分析
ＲＡ Ｂ 建 立在 Ｕ Ｅ和 Ｃ Ｎ 之 间 ，承我 用 户面 的数 据 业务 ， ＵＥ
将会进行激活集更新（ 无１ Ｂ ／ １ Ｃ 事件 ） ， 不 计 一 次掉 话 ：
（ ３ ） 如 果 网络 开 启 呼叫 重 建功 能 ， 按 照呼 叫 重建 流程 进 行 。 终 端掉话 以后 再 次在 网络侧 发起 Ｒ Ｒ Ｃ接入 ，再 次接 入语 音
的时候ＲＲＣ－ ￣ 带的原 因是注册类原因（ ＲＲＣ ＣＯＮＮＥＣＴ ＲＥ Ｏ） 。而
掉话处理流程
流程图掉话处理处理流程操作手册1、由小区性能监控模块发现小区掉话数多2、排查硬件故障如果掉话率突然上升，则需要检查本小区和相邻小区此时是否工作正常，通过OMC-R检查本小区和相邻小区告警，传输和天线是否出现异常，排除因为硬件原因产生的小区异常掉话。
解决措施:派单处理3、覆盖欠佳引起的掉话了解该小区的覆盖区域，是否存在一定的覆盖欠佳区域，覆盖欠佳是造成下行弱信号掉话的一大原因。
原因分析:服务小区由于各种原因（如无线环境好，功率过高，站点设置太高）产生越区覆盖，导致UE在移动到被越区覆盖的小区后，因无邻区关系配置，导致无邻区可切换造成的弱信号掉话。
越区覆盖导致的频率干扰和扰码相关性问题。
波导效应和湖面效应会使服务小区覆盖过远，引起干扰或切换判断混乱，产生掉话。
由于孤岛效应，处于孤岛的UE 无法切换出去，产生掉话。
由于一个地方没有一个足够强的主导频，出现导频污染，手机通话过程中，乒乓切换会比较严重，导致掉话率上升。
两个小区交接部分出现明显的无信号覆盖的漏洞，UE移动出覆盖范围，产生掉话。
由于高大建筑物遮挡产生的阴影效应。
解决措施:消除越区信号的影响：通过路测同事了解掉话小区及周围覆盖情况，查找覆盖不规范的基站，通过调整该站的下倾角，方位角，或降低它的最大发射功率等方法来优化覆盖区域，同时避免基站天线沿街道或湖面覆盖，避免街道效应和湖面效应等产生难以控制的信号，消除漂移信号对其它基站的影响.查找覆盖不足的地区：通过投诉组同事和路测同事的场测试来查明覆盖不足的地方，看是否可以通过调整下倾角，方位角，挂高，以及发射功率等方法增大覆盖范围（这需要综合考虑频率、扰码规划以及其它方位覆盖的情况）。
如果弱场区处于商场、隧道、地下停车场、地铁入口、高层建筑等特殊场合，则需要增加RRU，或室内分布来解决。
4、小区数参数配置不合理引起掉话检查小区各系统参数有无配置得很不合理，可以能过与正常小区之间的参数进行对比，找出是否出现个别参数调得很不合理面导致的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
厦门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的结果不一致。