重定位-完成重定位后掉话问题案例分析

重定位-完成重定位后掉话问题案例分析
版权所有
大唐移动通信设备有限公司
本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。

未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。

目录
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。

随后RNC内部生成响应原语MULTICCS_TARGET _SOURCE _RL_SETUP_RSP，从该原语交互过程可以推断该次切换进行的RNC内的板间切换。

随后RNC内部生成原语HSPS _RRM _INTERCCSS_HO_RSP，以描述RRM资源分配的状态，据此可以看出RNC内部切换判决已经成功。

但是随后RNC 内部HSPS从CPSS侧收到RRM_ALLOCATE_RESOURCES_FAILURE，原因为
RRM_ErrorCellStatus，显示目标小区RRM资源分配失败的原因为小区状态错误。

如下：
随后观察田州_2小区在该时间段的CDL信令，核查显示Iub以及Uu口都无任何信令，显示该时段田州_2小区和RNC之间没有信令交互。

如下：
同时核查了田州基站其余两个小区的CDL数据，情况相同，和RNC都没有信令交互。

随后核查测试当日也就是10月24日的性能统计报表中的上行业务时隙的ISCP报表，发现上报ISCP统计值的小区中不包含RNC＝405.CELLID＝10018即田州_2小区。

造成该现象最可能的原因有两个:
1)由于割接，田州基站已经从RNC405下面割接到了其他RNC下，但在原RNC405
中的数据没有删除。

2)田州基站传输出现故障
目前田州_2基站的传输已经中断，割接记录中没有田州基站的相关记录，因此该现象的具体起因无法核查。

然后分析第二个异常现象，即重定位完成以后UE掉话：
分析CDL数据（10月24日 RNC405，时间15点），对UE_ID=3630过滤，如下：
UE发出的第二条目标小区为10112，CPI＝96小区的测量报告触发了重定位，RNC405向CN发出了Relocation Required，CN向RNC405回复了Relocation Command，表示源RNC 侧和目标RNC侧的重定位准备流程正常结束。

随后出现异常，源RNC发出Iu Release Request 拆链，原因值显示为IUSP_REL_REQ_LOCAL_CAUSE_TRELOCOVERALL_EXPIRE。

从该次掉话中重定位的流程来看，源RNC405收到Relocation Command以后，应该在
“SRNC重定位定时器”内收到CN下发IU RELEASE CMD。

源RNC405上发Iu Release Request消息的时间和源RNC收到Relocation Command的时间相隔10秒左右，为源RNC405“SRNC重定位定时器”的设置值。

因此判定，“SRNC重定位定时器”超时导致了源RNC405释放链路。

“SRNC重定位定时器内”设置界面如下：
同时看到RNC405向UE发送RB Reconfiguration消息，空口显示UE收到了该条消息，且UE在目标小区钦唐_3小区上面向网路侧发送了Radio Bearer Reconfiguration Complete。

表示源RNC侧的重定位流程都完成，可以判定问题出在目标侧。

随后观察目标RNC侧的信令流程，分析Call Trace数据（10月24日 RNC390，时间15点），UEID＝16334（Radio Bearer Reconfiguration消息中可找到），结果如下:
从信令流程来看，目标RNC390向CN发送RELOCATION DETECT消息，显示目标RNC390已经收到重定位执行的触发（relocation execution trigger），但是目标RNC390始终没有收到UE发出Radio Bearer Reconfiguration Complete，随后目标RNC390上发Iu Release Request拆链。

原因值显示为
IUSP_REL_REQ_LOCAL_CAUSE_SINGLE_DOMAIN_TRNC_TFINISH_TIMER_EXPIRE，
即定时器超时导致的链路释放。

根据正常重定位的流程，目标侧RNC在发出RELOCATION REQUEST ACKNOWLEDGE后，应该在“目标侧等待Uu侧重定位完成定时器”超时之前收到Uu侧的Radio Bearer Reconfiguration Complete 消息。

该定时器目前设置的值为8秒，而从Call Trace内显示的时间戳来看，目标侧RNC390发出RELOCATION REQUEST ACKNOWLEDGE的时间和RNC释放链路的时间之间间隔为8秒，因此判定，目标RNC
收不到Radio Bearer Reconfiguration Complete导致“目标侧等待Uu侧重定位完成定时器”定时器超时从而引起目标RNC390释放链路，“目标侧等待Uu侧重定位完成定时器”设置界面如下：
因此，造成这次掉话的主要原因即是UE上发的Radio Bearer Reconfiguration Complete 消息目标RNC390侧没有收到。

造成该问题有两个可能性：
1)钦唐基站故障，信令无法通过
2)信令在空口丢失
首先考虑钦唐基站故障的可能性，核查测试当日10月24日的故障类告警原始报表，没有发现钦唐基站存在故障类告警。

随后核查测试当日的事件类告警原始报表，发生Radio Bearer Reconfiguration Complete消息丢失的时间大约是2008-10-24 15:56左右，在该时间点发现如下两类告警：
原因描述 上报时间 告警类型 网元类型告警级别网元对象
与无线链路占用的RU冲突2008-10-24 15:57处理错误告警宏基站 警告告警RAN=390 钦唐-560 BBU (1-1-8)与无线链路占用的RU冲突2008-10-24 15:57处理错误告警宏基站 警告告警RAN=390 钦唐-560 BBU (1-1-8) APB响应超时 2008-10-24 15:56处理错误告警宏基站 警告告警RAN=390 钦唐-560 SCM (1-0-2) APB响应超时 2008-10-24 15:56处理错误告警宏基站 警告告警RAN=390 钦唐-560 SCM (1-0-2)上述两类告警代表接入时RRC Connection Setup消息的下发有可能出问题，和上行方向信令的发送无关。

因此钦唐基站故障造成信令丢失的可能可以排除。

随后考虑信令在Uu口丢失的可能性，观察发送Radio Bearer Reconfiguration Complete 时UE的发射功率的情况，如下：
从上图中可以看到，UE 切换到钦唐_3小区以后，初始上行功率较低。

因此在发射Radio Bearer Reconfiguration Complete 时发射功率较低，导致信令在空口的丢失。

为分析造成UE 切换到目标小区以后初始上行发射功率较低的原因，首先解释UE 的初始上行DPCH 功率的计算方式，计算公式如下：
◆ 上行初始功率＝上行期望接收功率（Uu 消息配置值）＋PCCPCHTx – PCCPCH RSCP
其中，“PCCPCHTx – PCCPCH RSCP ”为下行PCCPCH 信号的路损值，是由无线环境决定的，而上行期望接收功率根据钦唐_3小区的配置文件设置是“根据干扰计算得到”，即根据“分配给Node B 的上行目标信噪比”，根据
计
算得到。

其中ISCP 来自于基站的周期测量报告。

当ISCP 不可得时，将使用操作维护配置的“上行期望接收功率”。

钦唐_3小区PC 算法参数的各项配置如下：
可以看到，钦唐_3小区的“分配给Node B 的上行目标信噪比”设置为3dB
，而参标中
dB
dBm dBm
SF SIR ISCP PRX ,1PDPCHdes
+
=
该参数的默认值设置为12dB。

该值设置偏低将导致Node B侧计算得到上行期望接收功率偏小，引起UE切换到钦唐_3小区以后初始上行DPCH功率较低，从而引起Radio Bearer Reconfiguration Complete信令丢失。

3 问题结论、优化措施、优化前后效果对比
总结第一个异常现象，源RNC405收到被叫UE发出的向田州_2小区切换的测量报告后，发出原因值为RRM_ErrorCellStatus的RRM_ALLOCATE_RESOURCES_FAILURE表示RRM资源分配失败无法切换。

造成该问题的原因推测是田州_2小区在源RNC405中的数据配置存在问题，导致RRM模块找不到相应的小区无法分配资源。

目前田州基站的传输处于中断状态，各个小区的原始邻小区关系也都删除完毕，田州基站对网络的不良影响已经消除。

第二个异常现象，即UE和目标小区钦唐_3在空口完成了上下行的同步后上发Radio Bearer Reconfiguration Complete消息网路侧无响应，导致"目标侧等待Uu侧重定位完成定时器"超时引起掉话。

该问题的起因是钦唐_3小区的“分配给Node B的上行目标信噪比”设置较低为3dB，导致初始的DPCH上行功率较低引起Radio Bearer Reconfiguration Complete 消息丢失。

考虑到初始的DPCH上行功率较低容易引起信令的丢失，目前，全网小区的“分配给Node B的上行目标信噪比”都已经设置为12dB。

4 总结该类问题一般分析优化思路
该次掉话实际包含了两类问题。

第一类问题是RNC收到了测量报告没有触发切换流程。

解决该类问题需要分析RNC
内部原语，如看到RNC内部这时出现原因值为“RRM_ErrorCellStatus”的
RRM_ALLOCATE_RESOURCES_FAILURE，则可以初步推测测量报告中目标小区的数据配置存在问题。

随后观察目标小区和RNC之间的通信过程以及ISCP值的上报情况，如果发现目标小区和RNC之间的Iub无任何数据，同时上行业务时隙的ISCP值统计报表中无此小区，则可以确定上面的推测，起因很可能是该小区割接以后在原来RNC中的数据没有完全删除导致的。

第二类问题是UE在空口上发了Radio Bearer Reconfiguration Complete消息后掉话。

出现该类问题，首先观察RNC是否收到，随后通过观察网络侧RNC释放链路的时间，确定是哪个定时器超时，以此确定掉话的原因是否是由于Radio Bearer Reconfiguration Complete 消息RNC没有收到。

如果确定，则观察Radio Bearer Reconfiguration Complete消息丢失的原因，是空口质量差还是基站故障导致的丢失。