下载文档原格式
重定位-完成重定位后掉话问题案例分析版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。
未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。
目录1 问题现象描述 (2)2 分析推理过程 (5)3 问题结论、优化措施、优化前后效果对比 (10)4 总结该类问题一般分析优化思路 (10)1 问题现象描述10月24日下午，测试车辆沿桂平路向北行驶至宜山路后向西左转。
如下：被叫UE2占用RNC405漕桂_1小区。
随着服务小区漕桂_1覆盖质量的下降，被叫UE2发起2A的测量报告，目标小区显示为主频点为10104，CPI＝1的小区，没有得到网络响应。
过了大约30秒以后发送第二条测试报告，目标小区显示为主频点为10112，CPI＝96的小区。
随后收到Radio Bearer Reconfiguration消息，指示UE向主频点为10112，CPI＝96的小区切换，随后UE在主频点为10112，CPI＝96的小区上面发送Radio Bearer Reconfiguration Complete。
8秒以后进入空闲状态。
没有发生小区更新，然后掉话。
测试图以及各条信令具体内容如下：RB Reconfiguration 消息解码该次掉话中，出现的异常情况有两个：1) 第一条目标小区为主频点为10104，CPI ＝1小区的测量报告发送后，网络侧没有下发切换命令2)重定位完成以后UE掉话。
2 分析推理过程首先对第一个异常现象进行分析。
分析CDL数据（10月24日 RNC405，时间15点），对UE_ID=3630过滤，如下：对RNC收到第一条向测量报告使用ASNDecode软件进行解码，解码后观察其消息内容，显示目标小区为10104，CPI＝1的小区，RNC收到该条测量报告以后，内部生成原语MULTICCSS_SOURCE_TARGET_RL_SETUP_REQ，目标小区CELL_ID＝10018，核查基站数据库显示，目标小区为田州_2小区，主频点10104，CPI＝1。
高铁组合业务迁移失败分析1 问题现象IPHONE用户在高铁进行语音通话时，由于迁移发起迁移失败，导致掉话。
2 问题分析2.1 业务流程●用户发起注册业务●PS业务建立●随后建立CS业务●业务释放在用户掉话前，进行了多次的语音通话，但是由于在语音释放后，由于存在PS业务的连接，因此，RRC的连接始终未进行释放。
2.2 掉话原因分析●用户从RNC5起呼，软切换至RNC6，在切换至RNC7时，由于迁移失败，导致掉话。
迁移失败的原因为Iu链路连接失败。
●目前现网RNC之间的Iur接口的关系为●现网迁移策略及掉话分析目前现网RNC 5,6,7,8迁移策略为CS域进行静态迁移，PS域进行DSCR。
用户在掉话前进行了多次呼叫，但是由于PS域始终存在连接，因此RRC连接始终没有释放。
目前，在用户进行组合业务的情况下，跨RNC将不会进行静态迁移或者DSCR。
因此在RNC5切换至RNC6时，终端进行的是软切换流程，随着终端移动，RNC7下的小区增强。
手机发送1D事件，将RNC7下的小区26扰码变更为最好小区。
随后RNC5发起向RNC7的迁移（由于RNC5与RNC7之间没有Iur接口，而此时SRNC为RNC5，因此终端在迁移至RNC7时，采用UE涉及的硬切换伴随迁移。
但是由于SRNC在收到迁移命令后，又给核心网发送了迁移取消，导致迁移失败。
查看迁移取消的原因为iu-transport-connection-failed-to-establish。
考虑到由于RNC5与RNC7之间没有Iur接口，因此两个RNC之间的PS域的迁移会由于没有定义相应的路由导致两个RNC之间迁移无法成功。
3 解决建议增加RNC5与RNC7之间的IPRT 及IPPATH 信息。
【关键字】问题LTE的掉话原因分析及处理思路LTE“掉话”是指UE异常退出RRC_CONNECTED状态导致的连接中断。
统计节点为“RrcConnctionReconfigurationComplete”消息正确达到网络侧开始，之后进行的各类业务，未正常释放的均计为“掉话”。
正常释放流程如下：一、外场常见掉话原因分析目前LTE常见掉话原因包括弱覆盖、越区覆盖、切换失败、邻区漏配、系统设备异常、干扰、拥塞等。
掉话原因1：弱覆盖现象:由于弱覆盖导致的掉话，通常有以下表现：1.掉话前服务小区的RSRP持续变差（低于弱覆盖标准，如小于-105dBm），同时服务小区的SINR也一起持续变差（小于0dB，甚至小于-3dB）。
2.掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE无数据上报（类似于UE脱网）。
解决方案:要解决此类掉话，需要改善覆盖。
具体手段有：1.首先明确当前的弱覆盖区域由哪些扇区的信号覆盖。
2.根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区，并加强它的覆盖。
如常用的天馈调整、站点建设等。
具体案例：对呼和浩特市大昭寺前街DT过程中占用到大昭寺华隆小区-FL_3小区，覆盖较差存在掉线风险。
通过调整PA：3→0，RS参考功率：13.4dB→15.2dB，覆盖改善，掉线风险大大降低。
掉话原因2：越区覆盖现象:在支持切换的移动通信网络中，由于无法精确控制无线信号的传播，因此或多或少都会存在越区覆盖的情况，导致“孤岛覆盖”无法与周边站点进行正常切换掉话，通常有以下表现：1.越区覆盖导致的“导频污染”。
在覆盖区内，没有稳定的强信号作为主服务小区。
服务小区信号的频繁变化，是导致掉话的一个主要原因。
2.越区覆盖对主服务小区的干扰（包括邻区漏配、越区信号的迅速变化等）。
在某些区域，主服务小区收到越区信号的干扰，最终导致掉话。
解决方案：1.越区覆盖的一般优化原则是：在区域中已有合理的稳定信号覆盖的情况下，尽可能的控制越区覆盖的信号。
无线链路失败原理1) 下行无线链路失败在正常的业务保持阶段，如果检测到来自L1层的连续N313次“out of sync”指示，则认为下行失步。
UE 启动定时器T313。
如果在T313时间内，检测到连续N315次“in sync”则认为下行同步，则停止定时器T313。
否则将认为下行无线链路失败，UE 将进行小区搜索过程，在搜到小区后，UE 将在目标小区上进行cellupdate ，如果小区更新成功，则该次下行无线链路失败得到挽救。
3GPP 规范里约束的下行失步检测窗窗长为160ms ，且监测机制较为严格；而同步监测机制较为宽松，同步检测窗的大小为一个TTI 或者是160ms 。
需要指出的是监测窗的滑动步长是由各个终端厂家自行实现的，下面以某厂家终端为例：UE 侧采用滑窗方式，监测窗窗长为160ms ，滑动步长为10ms 。
由此，UE 收到第一个下行失步指示到UE 上发Cell Update 的时间为：160ms+（N313-1）*10ms+T313+小区搜索的时间（正常情况在2ｓ左右），如下图所示当N313配置为20，N315设为4，T313设为5s 时，整个时间的长度大约7350ms 。
图1 上行无线链路、下行无线链路失步时间计算2) 上行无线链路失败3GPP 协议规定，在业务保持阶段，Node B 高层收到物理层上报的连续N_OUTSYNC_IND个失步指示后，将启动T_RLFAILURE ，在此期间如果收到连续N_SYNC_IND 个同步状态指示，Node B 将停止并复位T_RLFAILURE ，如果T_RLFAILURE 超时，物理层向高层汇报失步。
在实际的运行过程中，基站对于上行失步也是如此操作的，Node B 对于物理层两个连续同步指示间的时间间隔为160ms ，那么上行方向，Node B 如果收到连续“同步信息_连续保密仅供中国移动学员内部使用失步指示”个outofsync ，则认为上行失步，并启动“同步信息_无线链路失败定时器”，在该定时器期间，如果未收到连续“同步信息_连续同步指示”个insync ，则Node B 认为上行无线链路失败，向RNC 上发“Radio link failure indication ”，并且停发下行数据，RNC 启动“收到RL 失败等待定时器”，在该定时器超时前，如果未收到“Radio link restore ”则RNC 释放链路，并记为无线链路失败的掉话。
5G终端接入NR后出现SCG失败掉话案例案例上报省份：贵州省案例上报人：李拔任➢一、关键词：NR接入、SCG失败、RateMatch开关➢二、案例分类问题分类：掉话类手段分类：基站参数配置调整➢三、优化背景目前NSA组网需要LTE锚点接入后5G持续驻留，因此优化过程中要确保LTE锚点接入、切换指标正常，确保5G站点接入、切换、驻留比、速率、覆盖等指标正常。
➢四、问题现象1BY-轩辕山庄NHHO站点周围DT测试时发现5G接入成功后出现SCG失败，NR异常释放导致5G掉话。
➢五、原因分析通过Probe信令观察，发现锚点与5G正常接入后出现信令SCGFailureInformationNR（SCG失败），对应事件为NRSCGFailureInformation FailureType：rlc-maxnumretx（失败原因为rlc最大重传次数）初步怀疑是小区干扰较大导致重传次数增加超过最大次数：观察小区的RSRP和SINR指标，发现小区RSRP正常，小区的SSB SINR和CSI SINR均不算差。
RSRP有-83dBm，SSB SINR为9.88.●排除空口质量问题，怀疑是小区的RLC重传次数配置过低。
通过后台小区参数配置核查，发现小区的RLC AM模式重传次数均为基准值，并未设置太低，问题未解决。
●对log继续分析并核查轩辕山庄站点前一天DT数据发现切换及接入均正常，核查在正常与问题出现期间修改过的参数发现，该期间仅修改RateMAtch开关，修改方法为：RateMatch4个开关之前为全部打开。
修改后为只打开了TRS RateMatch开关，其余均为关闭：LST NRDUCELLPDSCHMOD NRDUCELLPDSCH修改RateMatch开关后发现仍未生效，咨询设备厂家研发后确认该参数修改后需要重新复位基站才生效，基站复位后复测正常。
➢六、解决方案修改RateMatch开关配置为单开TRS RateMatch后，对站点进行复位。
LTE的掉话原因分析及处理思路LTE“掉话”是指UE异常退出RRC_CONNECTED状态导致的连接中断。
统计节点为“RrcConnctionReconfigurationComplete”消息正确达到网络侧开始，之后进行的各类业务，未正常释放的均计为“掉话”。
正常释放流程如下：一、外场常见掉话原因分析目前LTE常见掉话原因包括弱覆盖、越区覆盖、切换失败、邻区漏配、系统设备异常、干扰、拥塞等。
掉话原因1：弱覆盖现象:由于弱覆盖导致的掉话，通常有以下表现：1.掉话前服务小区的RSRP持续变差（低于弱覆盖标准，如小于-105dBm），同时服务小区的SINR也一起持续变差（小于0dB，甚至小于-3dB）。
2.掉话后可能会有一段时间（数秒至数分钟不等，取决于实际网络覆盖情况），UE无数据上报（类似于UE脱网）。
解决方案:要解决此类掉话，需要改善覆盖。
具体手段有：1.首先明确当前的弱覆盖区域由哪些扇区的信号覆盖。
2.根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区，并加强它的覆盖。
如常用的天馈调整、站点建设等。
具体案例：对呼和浩特市大昭寺前街DT过程中占用到大昭寺华隆小区-FL_3小区，覆盖较差存在掉线风险。
通过调整PA：3→0，RS参考功率：13.4dB→15.2dB，覆盖改善，掉线风险大大降低。
掉话原因2：越区覆盖现象:在支持切换的移动通信网络中，由于无法精确控制无线信号的传播，因此或多或少都会存在越区覆盖的情况，导致“孤岛覆盖”无法与周边站点进行正常切换掉话，通常有以下表现：1.越区覆盖导致的“导频污染”。
在覆盖区内，没有稳定的强信号作为主服务小区。
服务小区信号的频繁变化，是导致掉话的一个主要原因。
2.越区覆盖对主服务小区的干扰（包括邻区漏配、越区信号的迅速变化等）。
在某些区域，主服务小区收到越区信号的干扰，最终导致掉话。
解决方案：1.越区覆盖的一般优化原则是：在区域中已有合理的稳定信号覆盖的情况下，尽可能的控制越区覆盖的信号。
LTE掉话问题分析及RRC连接重建触发原因
一、掉话问题两类
1、异常RRC connection Release,网络设备异常。
2、RRC重建失败。
二、掉话问题具体原因：
1、弱覆盖
2、干扰
3、切换失败，邻区参数配置不正确，目标小区工作不正常（传输误码，负荷高接纳拒绝）
4、邻区漏配，无法切换
5、越区覆盖，导致参考信号污染或邻区漏配引起切换掉话。
6、拥塞，引起多项指标恶化。
7、设备异常，终端或网络设备异常。
三、RRC重建立触发的原因有如下几种情况：
（1）UE检测到无线链路失败，主要包括：上下行RLC达到最大重传次数；上/下行失步，随机接入失败等原因
（2）切换失败（包括同系统、异系统切换）
如果切换失败，UE会发起RRC重建立请求，并将重建立原因封装在RRC重建立请求消息中。
（3）底层指示完整性保护失败
由于信令的完整性保护失败发生RRC重建立，例如UE和基站的加密以及完整性保护算法不一致，这类原因不常见，通常为终端的问题。
（4）RRC重配失败
RRC重配置的目的是修改RRC连接，在如下场景会发生RRC重配置：建立、修改或者释放无线承载时；执行切换时；建立、修改或释放测量配置等。
无
原因分析
同时查看CDL过滤出该次呼叫，RNC已下发物理信道重配消息，但UE未收到，无线链路持续恶化定时器（10S）超时，UE上发物理信道重配失败，RRC收到UE超时失步，发起IU Release 指示，释放RRC连接，UE掉话。
信令跟踪如下：
故障总结
针对上行和下行，失步分为上行链路失步和下行链路失步两种。
在协议里面针对上行链路失步和下行链路失步分别定义了判断标准，上行链路失步会删除链路,，下行失步会cellupdate 而且现在的情况是一般出现了上行失步后基本上都恢复不了，造成UE最终掉话，而下行时刻有时可以通过cellupdate过程恢复。
引起上行和下行链路失步的原因又不能简单地认为是某一方面的问题，而是由于交互作用引起的。
下行失步：
由于终端物理层对物理信道数据进行CRC校验，如果误码率较高，物理层就会判断为失步（160ms）。
在RL同步状态下，当CC子系统检测到连续N313（20个）失步后，给LC上报一
附录无。
温州网络优化项目组| 技术文档1
RNC迁移失败导致掉话的分析报告
温州网络优化项目组
作者：孙瑜峰、涂小林
2010-01-06
目录
1现象 (2)
2测试及现象分析 (2)
2.1跨RNC迁移DT验证 (9)
2.1.1现象汇总和初步分析 (10)
2.2交换层面深入分析问题 (10)
2.2.1问题定位 (13)
3问题解决方案 (13)
4总结 (13)
温州网络优化项目组 | 技术文档 2
1 现象
在2009年12月24日和25日两天长呼测试过程中，现场网优发现，从机场往市区方向测试过程中，
路过汤家桥南路的时候在同一地点都产生了掉话。
2 测试及现象分析
车辆行驶方向如图所示，由瓯海大道（东南向西北行驶）右转至汤家桥路（南向北行驶），当行驶至RNC8地界时产成了掉话。
[途经RNC 4→RNC9→RNC8]
图表 1 此时刻UE 已经切至RNC9下的Nod e B,应于此刻开始SRNC 重定位
温州网络优化项目组 | 技术文档
3
SRNC 向CN 上发了Relocation Required ，迁移种类为静态迁移：RelocationType = ue-not-involved
Relocation Required 要求由RNC4（RNC 标识为2374）迁移至RNC9（RNC 标识为2384）
温州网络优化项目组| 技术文档4
CN向SRNC下发了Relocation Preparation Failure消息，迁移失败。
温州网络优化项目组| 技术文档
5 UE在RNC9内正常切换，由Iur口的配合，AMR语音长呼没有因此受到影响
车辆行驶至RNC9—RNC8交界处时，UE不停地通过measurementReport(UL_DCCH)上报1a事件，要求添
温州网络优化项目组 | 技术文档
6
加RNC8的小区温州质检大楼WZW01192扰码为（220）进入激活集。
SRNC 向CN 上发了Relocation Required ，迁移种类为硬切换伴随迁移：RelocationType = ue-involved 。
Relocation Required 要求由RNC4（RNC 标识为2374）迁移至RNC8（RNC 标识为2382）
温州网络优化项目组 | 技术文档
7
CN 向SRNC 下发Relocation Preparation Failure 消息，此状态一直循环下去，直至掉话。
掉话时Txpower=-128dBm BLER=100%，rrcConnectionRelease(DL_CCCH)的
Cause
为
温州网络优化项目组 | 技术文档
8
“directedsignallingconnectionre-establishment ”
Release 消息Cause 显示Recovery on timer expiry
掉话后UE 做了location Updating,完成了位臵更新。
温州网络优化项目组| 技术文档
9
可见，此次掉话是RNC迁移（伴随跨LAC）失败，以及RNC4-RNC8的Iur接口的问题导致。
2.1跨RNC迁移DT验证
针对以上跨RNC切换失败的问题，做了以下实验（AMR语音长呼）：
RN C8→RNC9成功切换流程
测试结果：
温州网络优化项目组| 技术文档10
①RNC8至RNC9迁移成功；RNC9至RNC8迁移成功；（反复试验屡试不爽）
②RNC9至RNC4迁移失败；
③RNC6至RNC4迁移失败；
④RNC4至RNC9迁移失败；
2.1.1现象汇总和初步分析
现象总结： RNC5、RNC8、RNC9为同LAC，都是55120；
RNC4的LAC为55110，RNC6的LAC为55114；
所以RNC8→RNC9和RNC9→RNC8迁移成功，RNC6→RNC4、RNC4→RNC9、RNC9→RNC4为跨LAC迁移，所以迁移失败。
2.2交换层面深入分析问题
在交换层面，切换参数是根据目标侧查表得到的，而不是根据源侧查表得到。
如果目标侧是2G，使用目的小区查表LAIGCI得到切换参数，如果目标侧是3G，使用目的RNC-ID查RNC和NRNC表得到切换参数。
要获取目标侧信息，当源侧为本局BSC，目标侧为3G，目的RNC-ID从HANDOVER REQUIRED获取；当源侧为本局RNC，目标侧为3G，目的RNC-ID从RELOCATION REQUIRED获取。
在华为软交换设备上，获取RNC-ID后，查RNC、NRNC表，得到切换参数，根据匹配的记录在RNC还是NRNC 表，还可以确定目标侧RNC是本局的还是它局的。
如果查表成功，使用该RNC的切换参数，如果查表失败，切换被拒绝。
（RNC和NRNC的记录不能重复，因此最多只会匹配到一条记录。
）
在此次路测RNC4-RNC9-RNC8的过程中，RNC4下挂在WZMG4，RNC8、RNC9下挂在WZMG5，所以切换过程属于跨局切换。
温州网络优化项目组 | 技术文档
11
根据路测失败的信令跟踪消息，可以看到第一次RELOCATION 失败消息是在8：05
，查看RELOCATION REQUIRED 消息，得到用户源RNC 标识为2374（即RNC4），目的RNC 标识为2384（即RNC9）。
而RELOCATION_PREPARATION_FAILURE 消息内可以看到原因为“查询不到这个目标RNC ”。
温州网络优化项目组 | 技术文档
12
此时虽然RELOCATION 失败，但RNC4和RNC9之间有Iur 接口相连，因此通话不会中断。
当路测继续前进，到达RNC8和RNC9交界处时，8：16
又发起一条RELOCATION REQUIRED ，用户源RNC 标识为2374（即RNC4），目的RNC 标识为2382
（即RNC8）。
通过RELOCATION_PREPARATION_FAILURE 消息内可以看到原因仍然为“查询不到这个目标RNC ”。
RNC4和RNC8之间没有Iur 接口相连，此时发生掉话。
温州网络优化项目组| 技术文档13
2.2.1问题定位
根据失败原因，检查WZMG4的切换参数设臵，发现WZMG4的NRNC表未配臵。
后续测试RNC8→RNC9和RNC9→RNC8迁移都是在WZMG5下，因此测试正常。
RNC6→RNC4、RNC4→RNC9、RNC9→RNC4均为跨端局迁移，所以测试失败。
查询各局的NRNC表均未有相关配臵。
3问题解决方案
解决方案：在各端局上新增相邻RNC数据后，测试通过。
4总结
针对跨RNC迁移失败的问题，首先确定目标RNC是本局的还是它局的，确定出问题主要是因为跨CN 的RNC迁移失败造成，最终确定是由于CN缺少邻RNC表的定义造成。
目前该问题在网络中普遍存在，建议在核心网侧进行普查。
---结束---。
