厦门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、小区数参数配置不合理引起掉话检查小区各系统参数有无配置得很不合理，可以能过与正常小区之间的参数进行对比，找出是否出现个别参数调得很不合理面导致的。
同PN问题的解决方案
同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日常投诉处理优化典型问题和解决方案
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）导致的。
苹果iPad造成PS域掉话的分析
是 是
否 否
是 是
先 关 闭 Ｗｉｉ Ｆ，重新开 机 ，３ Ｇ这边有 Ｐ Ｐ激 活，做 了 Ｄ 业务请 求都是在访 问 Ａ ｐｅ的网站。（）再打开 Ｗｉｉ ｐｌ ２ Ｆ， ３ Ｇ这边过了 ５ ｎ才去激活 ， ｍｉ 之后就一直没有再激活 了。 （）再 关闭 Ｗｉｉ ３ Ｆ，用 ３ Ｇ登 陆新浪 ，３ Ｇ的 Ｐ Ｐ一直保 Ｄ 持激活状态 ，没有 去激活。（）再 打开 Ｗｉｉ ４ Ｆ，同时保 持３ Ｇ连接 ，无论是 浏览网 页还 是登 陆实 验室 的内网 ， 业务全走 Ｗｉｉ ５ Ｆ。（）将笔记本 Ａ 的拨号断开 ，但 ｉａ Ｐｄ 保持 Ｗｉｉ Ｆ 连接 ，再 浏览 网页过程 ，３ Ｇ这边依 然无 动 作 ，依 然保持 着第 ３ 中的 Ｐ Ｐ激 活状态 。（）ｉａ 步 Ｄ ６ Ｐｄ 断开 ＷＩＩ Ｆ ，继 续浏 览，数据 分组 从 ３ Ｇ上 来 ，之后不 做任何操作 ，Ｓ Ａ 内容 清掉后 ，ｉａ ＡＦ ＲＩ Ｐ ｄ没有去激活 。 （）再连接 Ｗｉｉ ７ Ｆ 后，运行很多软件 ，大部分业务都走
兴核心 网 Ｃ Ｓ Ｓ ， Ｎ（Ｇ Ｎ）但是某市使用 了中兴的 ＲＡ 无 Ｎ（ 线接入 网） Ｍ 使用 了华为 的 ＲＡ ，Ｘ Ｎ。为何 ｉａ Ｐ ｄ只在 某市出现这么大量异常掉话？
和 ３ 没 有 配 置 Ａ Ｎ，也 没 有 任 何 人 为 操 作。 在 Ｇ， Ｐ
１ ：３ ５ ：９ ，ｉａ ３ ｌ ：９０ ０ Ｐ ｄ收 到 Ｒ ＮＣ下 发 的 Ｒａ ｉ Ｂ ａ ｅ ｄｏ ｅｒｒ
验。 关键 词 Ａ Ｎ；ｉａ 版本 ；“ Ｐ Ｐｄ 通知”功能 ； Ｄ 去激活 ＰＰ
中图分类号
Ｔ ９９５ Ｎ ２．
文献标识码
Ａ
文章编号
１０— ５９（０ １ ７ ０６— ６ ０８ ５９ ２ １）０ ０２ ０
无线接入网常见问题处理思路-掉话
案例：
9
掉话问题分析
5、由于干扰和小区负荷过高引起的掉话
•
典型表征
1）前向链路干扰、反向链路干扰、直放站干扰等 2）小区话务量太高，系统自干扰严重
案例：
10
掉话问题分析
6、由于切换（软切换、硬切换）问题引起的掉话
•
典型表征
1）软切换问题 邻区漏配、优先级设置不当、One_way\Two_Way问题、 搜索窗设置、软切换分支Abis链路传输时延超大、由于 BTS时钟同步错误、GPS故障、BSC边界基站功率同步开关 打开、呼叫迁移失败 2）硬切换问题
1、了解问题发生的区域、时间范围、现象描述；掉话是个别手机 还是全部手机，如果是个别手机的掉话，可能与手机的版本和 手机本身质量有关； 2、用优化工具分析掉话原因； 3、确认掉话区域手机接收功率如何，能否满足手机良好通话的要 求，是否有导频污染； 4、邻区配置检查，确认无错配、漏配，优先级是否合理； 5、确认当前小区是否处于BSC或MSC边界；如果是边界基站，确认 和周围业务区的切换是否正常，是否打开了前向功率同步开关； 6、检查基站各小区以及周围相邻小区的反向接收信号强度指示 （RSSI）是否过高； 7、检查掉话率高的基站是否带了直放站及直放站工作是否正常； 8、检查PN规划是否有问题，是否存在PN复用距离不够，OneWay、 TwoWay问题； 9、确认无线参数设置是否正确；重点检查搜索窗大小、小区半径、 切换参数等内容；
无线接入网常见问题处理
国内无线网络规划部 王卫民 工号：148885
内容提要
1、掉话产生的机制 2、掉话产生的一般原因及典型表征 3、掉话问题处理流程 4、掉话问题处理思路
2
掉话产生的机制
1、移动台的掉话机制 • 移动台接收到坏帧： 当连续接收到12个坏帧之 后，移动台会关闭它的发 射机。在连续接收到2个 好帧帧之后会重新启动 发射机。 • 移动台的衰落计时器： 过高的FER意味着前向链路 很差。移动台设有衰落定时 器。定时器的期满值为T5m （5秒），该计时器一直在倒 计时一直到0；当接收到连续的2个好帧时，计时器重新开 始倒计时。如果移动台在回零之前没有接收到连续的两个 好帧，那么移动台将重新初始化。 。
W网规高培-掉话问题分析
10. UE发RRC_RB_REL_CMP消息给RNC，业务RB释放完成
11. RNC发RANAP_RAB_ASSIGNMENT_RESP消息给CN，RAB释放完成
第一章 掉话分类定义
第一节 正常释放流程
第二节 空中接口掉话定义
第三节 话统指标掉话定义－CS 第四节 掉话话统指标定义－PS
第一章 掉话分类定义
第一节 正常释放流程
第二节 掉话空中接口定义
第三节 掉话话统指标定义－CS 第四节 掉话话统指标定义－PS
话统指标定义
话统指标定义－CS掉话统计
通过统计RNC触发的 RAB 释放个数，统计 RAB 建立个数，进而得 到掉话率。根据测量对象的不同，掉话率可以分为面向 RNC 和面 向小区的掉话率，分别考察整个 RNC 和单个小区的掉话情况。 面向 RNC 的CS掉话率公式： (RNC_CS_RAB_REL_CONV_TRIG_BY_RNC+RNC_CS_RAB_REL_STR_TRIG_ BY_RNC)/(CS_RAB_SETUP_SUCC_CONV+CS_RAB_SETUP_SUCC_STR)*10 0% 测量点： CS会话类(流类）业务建立成功后，RNC向CN CS发送IU RELEASE REQUEST消息，其后CN发送释放原因"Release due to UTRAN Generated Reason"的IU RELEASE COMMAND。
正常释放流程
一个PS正常释放信令流程
正常释放流程
一个PS正常释放信令流程
1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nas message是0a46，表示是session management子层的deactivate PDP context request消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中nas pdu是0a46，表示是session management子层的deactivate PDP context request消息。 3. CN 发 RANAP_DIRECT_TRANSFER 消 息 给 RNC ， 消 息 中 nas pdu 是 8a47 ， 表 示 是 session management子层的deactivate PDP context accept消息。 4. CN发RANAP_RAB_ASSIGNMENT_REQ消息给RNC，消息中给出要释放的RAB list，其 中包含了要释放的RAB ID。 5. RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nas message是8a47，表示是
无线网络优化问题分析和主要解决方法
一、WCDMA掉话分析和解决办法：1、路测中掉话的定义：路测的掉话定义是：从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息满足以下3个条件的任何一个就视为路测掉话。
(1)收到任何的广播信道消息。
(2)收到无线资源释放的消息且释放的原因为非正常的。
(3)收到呼叫控制断连接、呼叫控制释放等消息，而且释放的原因为非正常的。
广义的掉话率应该包含C N和UTRA N的掉话率，但由于网络优化重点关注的是与UTRAN侧的掉话率指标，因此只要重点关注U TRA N侧的K P I指标即可。
2、掉话原因分析——涉及到具体的信令分析A、邻区漏配：一般来讲，掉话在初期优化过程中大多数是由于邻区漏配导致的。
对于同频邻区，通常可以用以下方法来确认是否为同频邻区漏配。
方法一：观察掉话前U E记录的活动集EcI o信息和记录的Bes tServ erEcI o信息。
如果UE记录的EcIo很差，而记录的Be stSer ver EcIo很好，同时检查记录BestServer EcIo扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中。
如果同频测量控制的邻区列表中没有扰码，那么可以确认是邻区漏配。
方法二：如果掉话后U E马上重新接入，UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制，进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。
方法三：有些UE会上报检测集（Detect edSet）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。
邻区漏配导致的掉话包括异频邻区漏配和异系统邻区漏配。
- 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的结果不一致。