HC_UE向同一目标小区多次重定位失败案例分析讲课教案

1、Good is good, but better carries it.精益求精，善益求善。HC_UE向同一目标小区多次重定位失败案例分析HC_UE向同一目标小区多次重定位失败案例分析版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。目录TOCo1-3hzuHYPERLINKl_Toc2160089191问题现象描述PAGEREF_Toc216008919h3HYPERL

2、INKl_Toc2160089222数据呈现及数据附件PAGEREF_Toc216008922h5HYPERLINKl_Toc2160089233分析推理过程PAGEREF_Toc216008923h5HYPERLINKl_Toc2160089244问题结论、优化措施、优化前后效果对比PAGEREF_Toc216008924h10HYPERLINKl_Toc2160089255总结该类问题一般分析优化思路PAGEREF_Toc216008925h11问题现象描述上海TD网络性能统计的重定位失败率比较高，导致的掉话问题也比较多，为此我们组织了一次上海全网16个RNC的重定位准备失败统计，取的是2

3、008-10-27上午9点至晚上9点的CDL数据，统计各RNC重定位准备失败的原因，次数及各种原因所占的比例。我们从CDL中将数据导成excel表（方便统计）：将表格中的“事件名称”为“RelocationPreparationFailure”的信息数据过滤出来；将由于“重定位准备定时器超时”导致的重定位准备失败的相关事件滤出：采用滤出“事件名称”为“RelocationRequired”和“RelocationCancel”，观察同一个UEID的这两个事件，记录下两者之间的时间间隔为8S的事件（目前各RNC设置的重定位准备时间为8S，见下图1）。图1重定位准备定时器设置将上述两种原因导致的重

4、定位准备失败的事件记录下来并做了相关的统计，具体结果见下图2：图2重定位准备失败原因统计这次的统计结果中的“RelocationPreparationFailure”原因值为：“HSPS_RELOCATION_NOT_SUPPORTED_IN_TARGET_RNC_OR_TARGET_SYSTEM”引起了我们的注意，其次数达到2097次，所占比重高达近40%，对网络的影响很大，为此我们决定对其做重点分析。图3重定位准备失败在RNC405上午11点的统计结果中，发现在14分钟内，因为该原因，同一UEID（15821）下RNC405的8243（CELLID）向RNC406的8322（CELLID）

5、重定位准备失败了391次。图4重定位目标小区信息数据呈现及数据附件ftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/HC-UE向同一目标小区多次重定位失败/CDL数据/上午11点CDL（RNC405；RNC406）.rar；ftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/HC-UE向同一目标小区多次重定位失败/重定位结果统计/RNC重定位统计.rarftp：/39/个人文件夹/0-网络优化上海项目集中培训/整理后的案例/HC-UE向同一目标小区多次重定位失败/cfgdata/cfgdata406.rar；ftp：/39/个人文件夹/0-网络优化上海

6、项目集中培训/整理后的案例/HC-UE向同一目标小区多次重定位失败/cfgdata/RNC405割接前.rar；分析推理过程一次完整的重定位准备定义为源RNC向CN发送“RelocationRequired”至收到CN回复的“RelocationCommand”。常见重定位准备失败有如下几种原因：目标RNC不支持重定位，直接给源RNC回拒绝消息；目标RNC侧无线资源无法满足；目标RNC侧无线链路建立失败；目标RNC侧Iub接口AAL2建立失败；目标RNC无法找到目标小区（如：数据配置错误，基站割接等）；由于本次重定位准备没有涉及到目标侧小区的无线资源建立，所以第3和第4种原因未做分析。下图5为

7、一个正常的重定位流程：图5重定位流程图现对上述原因进行分析：1）目标RNC不支持重定位，直接给源RNC回拒绝消息；目标RNC406的重定位大部分是成功的，所以可以排除该RNC不支持重定位，下图6为一次向RNC406成功的重定位准备。图6向目标RNC406重定位准备成功2）目标RNC侧无线资源无法满足；我们需要到目标RNC406去查找小区8322当时的资源占用情况，通过IMSI在目标RNC406的CDL中找到此UE的相关信令，而IMSI我们可以在源RNC405的“UE列表”设置过滤条件，选择“按UEID检索”，从而快速得到UE的IMSI。随后根据IMSI在目标RNC406的CDL中查找，也是在“

8、UE列表”中，设置过滤条件，选择“按接入标识检索”，输入“IMSI=”+IMSI，此次查找输入“IMSI=460077101020786”，需要注意“=”前后均有空格，相应的我们会得到对应UEID（可能会得到不止一个UEID，需要根据时段取相应的UEID）,此次查找取UEID57701。MSC向目标RNC发送RelocationRequest请求目标RNC为重定位分配相应的资源，但返回RRM_ALLOCATE_RESOURCES_FAILURE。检查RelocationRequest消息中携带的RAB信息发现申请的是12.2k的语音业务（上下行各需要两个码道），见图7。通过小区8322该时段的

9、“USERdistributing”核查小区的资源占用情况，但通过CELLID过滤后发现此小区没有该消息，只有消息“RRM_ALLOCATE_RESOURCES_FAILURE”，见图8。图7申请业务类型图8小区8322信令查看“RRM_ALLOCATE_RESOURCES_FAILURE”，消息中携带的本地原因为“RRM-ErrorCellStatus”（见图9），如果是资源拥塞，一般失败原因为“RRM-DLCodeJudFail”，所以可以排除是由于小区资源不足导致的重定位准备失败。图9资源分配失败3）目标RNC无法找到目标小区（如：数据配置错误，基站割接等）消息“RRM_ALLOCATE

10、_RESOURCES_FAILURE”中携带的本地原因为“RRM-ErrorCellStatus”，字面理解应该是小区状态异常，比较容易怀疑的是该小区有故障。于是查看提取的相关告警，但没有发现该小区有告警和异常现象。既然小区没有告警，那么该小区上其他用户的信令流程是否正常？于是在CDL中查看该小区，但是却没有Iub口的信令，有可能该小区没有用户接入，但是现在全网UpPCHshifting都打开了，我们应该能够在lub口看到NODEB向RNC周期性上报“UpPCH干扰测量”,但是没有该消息。下图10为正常的“UpPCH干扰测量”上报。图10UpPCH干扰测量小区既然没有故障告警，那么该小区Iub

11、口上不应该没有任何信令，所以现在怀疑小区是否存在？取了RNC406最新的配置文件查找，没有发现小区8322，为进一步核实，请机房帮我们查找该小区，机房回复为小区8322已经由RNC406割接到RNC396。我们查了RNC406割接前的配置数据，确定小区8322为“万宜”站的第二小区。现在问题清楚了，失败原因为目标小区“万宜-8322”已经由RNC406割接到RNC396图11割接前小区地理信息基站“万宜”都已经割接到RNC396了，当手机要求切换到“万宜”的第二小区时，为什么源RNC405会要求向RNC406重定位呢？UE根据RNC下发的测量控制进行邻区测量，手机通过测量控制中的频点和扰码进行

12、测量，测量报告中上报的也是频点和扰码，RNC将频点和扰码与邻区中的CELLID对应起来，并在该CELLID的小区上进行无线资源建立。源RNC405内小区“欧华-8243”中的邻区“万宜-8322”的信息没有更新，所以UE收到的测量控制中仍然是“万宜-8322”的频点和扰码，由于割接没有改变该频点和扰码，UE能顺利搜索到其信号，当信号强度满足条件时就上报要求重定位到“万宜-8322”，源RNC会将该频点和扰码与RNC406的“万宜-8322”对应起来，通过CN要求目标RNC406的“万宜-8322”建立无线链路，目标RNC406内小区“万宜-8322”已经割接到RNC396上，但是其在源RNC4

13、05内的跨RNC邻区和邻小区信息没有更新(也可删除后重新添加)，导致目标RNC406找不到（RNC406内暂时没有小区ID为8322的小区），最后分配资源失败，并上报原因“RRM-ErrorCellStatus”，正确的应该是向RNC396的“万宜”第二小区做重定位。问题结论、优化措施、优化前后效果对比问题结论：目标小区“万宜-8322”已经割接到RNC396上，而源RNC405的跨RNC邻区列表和小区邻区列表中该小区“万宜-8322”信息仍然是原来在RNC406中的信息，导致重定位指向一个错误的RNC406。优化措施：更新RNC405内跨RNC邻区列表（下图12）和“欧华-8243”邻区列表

14、（下图13）.图12跨RNC邻区列表图13小区邻区列表总结该类问题一般分析优化思路在网络建设优化期，我们已经习惯了通过路测发现问题，并搜集相关数据进行分析，对信令分析的较为详细，也容易定位问题，但是随着工程建设的结束，后期的网络维护阶段不可能再进行大量的路测，所以日常发现定位问题需要依赖网络侧的性能统计，而且随着网络用户的增加，报表更具有统计意义，通过统计性能发现的问题比较具有典型性，并且很多问题是路测无法发现的。做好性能统计的分析工作，可以使我们较易发现问题，从而快速定位和解决问题。例如本次的重定位准备失败统计，我们从中就发现了不少问题，而且比较全面。这次重定位准备失败的性能统计，得出了一些

15、失败原因，有设备问题，也有网络数据配置错误导致，这点需要我们重视，尤其是涉及割接的数据未删除比较严重，在设备不是很成熟的情况下，不要因为这种人为操作上的失误影响指标，混淆对设备问题的定位。这种数据错误，如果通过测试去分析，比较困难而且只能发现小部分的问题，这时的性能统计就能突显它的作用，我们可以根据需要统计各个网元的数据，结合统计结果分析问题，往往比较容易找到原因，而且比较全面。但是我们还是希望基站人员在涉及基站割接和数据制作时，一定做好割接记录，并及时删除垃圾数据，更新割接后的数据。对于重定位问题，我们常分为准备阶段和执行阶段，对于重定位准备失败的情况，CDL中会在“RelocationPr

16、eparationFailure”或“RelocationCancel”中注明相关的原因，通过各种失败原因虽然不一定能准确定位问题，但是其还是有一定的参考价值，我们对其中几种主要原因做了相关的总结,见下表1：失败原因原因解析HSPS_RELOCATION_NOT_SUPPORTED_IN_TARGET_RNC_OR_TARGET_SYSTEM目标小区信息在目标RNC内不存在，可能该小区已经割接HSPS_RELOCATION_FAILURE_IN_TARGET_CN_RNC_OR_TARGET_SYSTEM1目标RNC分配资源失败(小区RRM资源不足,带宽资源不足,本地资源不足,小区状态异常(如

17、：UE上报的测量报告中的最优小区实际上是一个disable的小区,但是基站没有关断射频)2目标小区在目标RNC不存在,建立无线承载UU口失败或者IUB口失败3接收到的relocationrequest消息参数错误4CN侧常见失败可能的一个原因是网络规划参数和源RNC,目标RNC不一致,比如relocationrequired消息中携带的RAC号(或者LAC号)和CN规划的不一致等HSPS_INTERACTION_WITH_OTHER_PROCEDURE重定位过程和别的过程并发失败，如小区更新。后续版本已经支持并发HSPS_TRANSPORT_CONNECTION_FAILED_TO_ESTABLISH目标侧RNC为cs用户建立lu口aal2建链失败HSPS_UNKNOWN_TARGET_RNCcn发的relocationrequest消息中的targetcellid中的rncid错误HSPS_FAILURE_IN_THE_RADIO_INTERFACE_PROCEDURE空口失败，应该是RadioBear