TDSCDMA业务切换问题分析指导书.doc

《TDSCDMA业务切换问题分析指导书.doc》由会员分享，可在线阅读，更多相关《TDSCDMA业务切换问题分析指导书.doc（68页珍藏版）》请在三一办公上搜索。

1、业务切换问题分析指导书(仅供内部使用)项目名称RNC现网产品维护文档编号QRSN00015579版 本 号V1.0.0作 者马忱、陈国强版权所有大唐移动通信设备有限公司本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。文档更新记录日期更新人版本备注20090824马忱、陈国强V1.0.0初稿提交评审20090903马忱、陈国强V1.0.0根据评审意见修改20090908马忱、陈国强V1.0.0根据评审意

2、见修改完成目 录1概述42切换的分类42.1TD系统内RNC内切换42.2TD系统内SRNS重定位42.33G/2G互操作43TD系统内RNC内切换43.1原理和基本信令过程43.2常见问题概述43.2.1问题1- RNC不发1g/2a的测量控制消息问题43.2.2问题2- UE上报1g/2a报告后RNC不发切换命令53.2.3问题3-在小区边界频繁发生切换63.2.4问题4-切换过程中UE收不到PhysicalChannleRecfg消息63.2.5问题5-切换过程中RNC收不到UE回的PhysicalChannleRecfgComplete73.2.6问题6-切换过程中UE返回Physic

3、alChannleRecfgFailure（physical channel failure）83.2.7问题7-切换过程中UE返回PhysicalChannleRecfgFailure（configuration unsupported）83.2.8问题8-切向一个小区总是失败-惩罚机制93.3经典案例94TD系统内SRNS重定位94.1原理和基本信令过程94.2常见问题概述94.2.1问题1- UE上报1g/2a报告后RNC不触发重定位104.2.2问题2- SRNC发起Relo Require后CN返回Relo Require Failure114.2.3问题3- SRNC发起Relo

4、Require后CN不响应Relo Command124.2.4问题4- CN发给TRNC Relo Request后TRNC响应Relo Failure134.2.5问题5- CN发给TRNC Relo Request后TRNC不响应134.2.6问题6- TRNC返回Relo Request Ack后收不到RB Recfg Complete144.2.7问题7- SRNC发出RB RECFG 切换命令后SRNC等不到CN的IU RELEASE144.2.8问题8- SRNC发出RB RECFG后UE返回RB RECFG FAILURE154.2.9问题9-重定位成功后的其他问题-VP无图像

5、154.2.10问题10-重定位成功后的其他问题-PS无速率164.2.11问题11-重定位成功后的其他问题-RU失败164.3经典案例174.3.1案例1 核心网（CS）参数未配置导致跨MSC的RNC间重定位失败的案例分析1753G/2G互操作175.1原理和基本信令过程175.2常见问题概述175.2.1问题1-RNC不发3A测量控制消息175.2.2问题2- UE上报3A报告后RNC不触发系统间切换或重选185.2.3问题3- RNC下发系统间切换或重选消息后，UE返回失败，原因为物理信道失败195.2.4问题4- RNC下发系统间切换或重选消息后，UE返回失败，原因为配置不可接受215

6、.2.5问题5- UE已经成功重选到2G后SGSN没有释放IU连接问题215.2.6问题6- CS切往2G时CN不响应Relo Require或者响应Relo Require Failure225.2.7问题7- 2/3G互操作各种场景测试结果研究分析和优化策略225.3经典案例235.3.1案例1南京现网系统间切换优化流程_修改235.3.2案例2 3G到2G系统间切换235.3.3案例3 2-3G互操作CN不发IUReleaseCommand问题235.3.4案例4 2/3G互操作各种场景测试结果研究分析和优化策略236附录236.1附录1：2/3G互操作相关知识236.1.1CS TD-

7、GSM切换236.1.2PS TD-GSM重选256.1.3GSM-TD重选过程266.2附录2：handoverFromUTRANCommand-GSM306.3附录3：终端已知2/3G问题316.4附录4：SRNS重定位相关知识326.5附录5：TD系统内切换相关知识356.6附录6：测量报告的解读441 概述本文档用于指导定位TD网络中和切换相关网优类问题的定位和处理方法。2 切换的分类2.1 TD系统内RNC内切换指由于UE的1g/2a测量报告触发的RNC内小区间的接力切换或者硬切换相关问题的处理。对于RLS或者LCC算法触发的切换情况和1g/2a切换的定位思路相同。2.2 TD系统内

8、SRNS重定位指由于UE的1g/2a测量报告触发的RNC间的SRNS重定位换相关问题的处理。2.3 3G/2G互操作指UE由3G切换（或者重选）到2G的相关移动性问题的处理。3 TD系统内RNC内切换3.1 原理和基本信令过程见附录6.5 TD系统内RNC内切换相关知识。3.2 常见问题概述问题描述问题1RNC不发1g/2a的测量控制消息问题问题2UE上报1g/2a报告后RNC不发切换命令；问题3在小区边界频繁发生切换；问题4切换过程中UE收不到PhysicalChannleRecfg消息问题5切换过程中RNC收不到UE返回的PhysicalChannleRecfgComplete消息问题6切

9、换过程中UE返回PhysicalChannleRecfgFailure（PhyCH Fail）问题7切换过程中UE返回PhysicalChannleRecfgFailure（Config not Accept）问题8切向一个小区总是失败-惩罚机制3.2.1 问题1- RNC不发1g/2a的测量控制消息问题3.2.1.1 问题分析 思路：小区HC算法参数开关问题、邻区配置问题（如果是其他RNC邻区，还要检查其他RNC邻区结点下的邻区配置）。另外，如果是通过LDT的UE imsi跟踪，那么通常无法看到1g/2a的MC，因为该类型信令跟踪只能跟踪到COMMON ID消息之后的信令过程，通过UE小区跟

10、踪能够观察到1g/2a的MC。3.2.1.2 Log抓取 该问题需要抓取RNC侧log： RNC信令跟踪log 在LDT的RSPA模拟shell中敲： hsps_drm_show_arithstblpara CellID 3.2.1.3 处理建议检查小区HC算法的“HC算法开关”是否打开；检查邻区配置是否正常，可以通过观察系统信息更新的SIB11中邻区配置是否和数据配置的一致；3.2.1.4 问题check list检查项备注HC算法开关在小区算法HC算法下SIB11中的同频和异频邻区配置和数据中小区的邻区配置比较其他RNC邻区配置在其他RNC邻区结点下配置3.2.2 问题2- UE上报1g/

11、2a报告后RNC不发切换命令3.2.2.1 问题分析UE上报1g/2a MR的时机问题，因为RNC有HC算法定时器，在前一次切换或者其他算法过程完成后会启动该定时器，如果UE上报的1g/2a MR时机在算法定时器未超时前，RNC则收到该1g/2a MR不处理。这是设计如此，避免乒乓切换。UE上报1g/2a MR的服务小区绝对导频问题。这种情况仅限于切换的目标小区邻区类型为“非重叠全向相邻”的小区，此时UE上报1g/2a报告后，RNC会将上报的服务小区的导频值和HC算法中的“存在Cs/PS的信令连接服务小区绝对导频门限”进行比较，如果大于配置的绝对门限，RNC不会切换。对于“非重叠扇区相邻”小区

12、RNC不作此判断。所以出现UE上报MR不切时，可以检查目标小区的切换类型和服务小区测量结果。对于1g/2a触发的切换，RNC不会判断邻小区的绝对导频门限。对于其他算法（如：RLS）触发的切换RNC会判断邻小区的绝对门限。注意事项：目前同频1g、异频2a测量控制消息中的“相对门限-hysteresis”、“服务小区绝对门限-usedFreqThreshold”、“邻小区绝对门限-nonUsedFreqThreshold” 首先看小区算法参数中的“事件信息表”，如果小区下没有，则看RNC的UE测量中的事件信息表。不会看小区HC算法参数中的参数的。另外，目标小区资源分配失败也会造成该现象。这种情况C

13、DL中有专门的（资源分配失败的）CDL记录。定向切换功能打开着也是一种可能。切换之后不允许向前一次刚切换过来的小区切，但如果MR中仅包含了前一次刚切换过来的小区测量结果，那么就会找不到可切的目标小区。定向切换的具体参数配置是在HC算法中有“本小区是否支持定向切换”开关。同频同码问题也是原因之一（虽然omc上限制了同频同码邻小区的配置）。3.2.2.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC配置数据 CDL 在LDT的RSPA模拟shell中敲： hsps_drm_show_arithstblpara CellID 3.2.2.3 处理建议HC算法定时器

14、设置不合理，目前是10秒，可以适当减小；检查目标小区的邻区类型是否为非重叠全向相邻；检查MR中的服务小区测量结果是否小于HC算法下的服务小区绝对导频门限；检查“其他rnc小区表”配置对象下是否有目标小区的配置。3.2.2.4 问题check list检查项备注HC算法定时器在小区算法下目标小区邻区类型在邻小区节点下服务小区的绝对导频门限小区算法-HC算法下本小区是否支持定向切换小区算法-HC算法下3.2.3 问题3-在小区边界频繁发生切换3.2.3.1 问题分析出现这种情况的原因可能是在这两个小区的交接处，RSCP的变化幅度较大，也有UE测量不准的因素。3.2.3.2 Log抓取 该问题需要抓

15、取RNC侧和UE侧log： RNC信令跟踪log RNC配置数据 CDL 在LDT的RSPA模拟shell中敲： hsps_drm_show_arithstblpara CellID 3.2.3.3 处理建议尝试修改增大1g/2a的相对门限来解决，目前默认是3db，可以修改增大为6db。另外，适当加大RNC内部HC算法定时器的值也可以避免乒乓切换，目前默认是10秒。该算法定时器意味着在上一次切换成功后的10秒内再收到该UE上报的MR，RNC不会触发切换。10秒后，UE再上报MR，RNC会切换。惩罚机制，3.2.3.4 问题check list检查项备注相对门限在小区HC算法下HC算法定时器在小

16、区HC算法下3.2.4 问题4-切换过程中UE收不到PhysicalChannleRecfg消息3.2.4.1 问题分析有可能是硬切换过程，切换消息采用RLC的AM模式发送，那么在空口质量较差的情况下，有大量重传，以致在硬切换的激活时间点到达后，UE的高层还没有收全切换命令，此时网络侧已经删除了旧的RL，UE无法再在旧链路返回任何失败消息，切换失败。后续RL有可能会检测到RL FAIL，或者UE从旧小区或新小区上CU。另外，RNC侧“等待UE响应消息定时器”设置过短也有可能导致该问题，目前默认为10s。3.2.4.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log R

17、NC配置数据 OMC上小区的UL TS ISCP的统计结果，最大值和平均值。 CDL UE侧outum log 3.2.4.3 处理建议 检查空口干扰情况，是否有过覆盖的邻小区配置。3.2.4.4 问题check list检查项备注等待UE响应消息定时器接口协议-RRC协议-等待UE响应消息定时器3.2.5 问题5-切换过程中RNC收不到UE回的PhysicalChannleRecfgComplete3.2.5.1 问题分析这种情况是切换过程中的主要问题。出现该问题的原因可能主要是：UE收到RNC发送的切换命令后，UE返回PHYSICAL CHANNEL RECFG COMPLETE。但是由于

18、UL干扰或UE上行发射功率过小问题，目标小区基站无法检测到上行同步，致使UE的RB RECFG COMPLETE的消息无法转发到RNC，切换失败导致掉话。另外，需要观察RNC是否收到目标小区NB上报的RL RESTORE，如果没有RESTORE，很有可能就是上行太差导致。另外，RNC侧“等待UE响应消息定时器”设置过短也有可能导致该问题，目前默认为10s。3.2.5.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log3.2.5.3 处理建议出现该问题后需要抓取当时的UE侧log，观察干扰情况，

19、同时如果能够复现的话，可以抓取目标小区的小区公共过程跟踪，分析基站测量的UL TS ISCP是否有异常。3.2.5.4 问题check list检查项备注等待UE响应消息定时器接口协议-RRC协议-等待UE响应消息定时器3.2.6 问题6-切换过程中UE返回PhysicalChannleRecfgFailure（physical channel failure）3.2.6.1 问题分析这种情况是UE和目标小区无法同步导致，即UE检测不到NB的下行同步，UE最后在源小区DCH上给RNC返回失败，带这种原因。3.2.6.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log

20、RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log3.2.6.3 处理建议出现该问题后需要抓取当时的UE侧log，观察干扰情况，同时如果能够复现的话，可以抓取目标小区的小区公共过程跟踪，分析基站测量的UL TS ISCP是否有异常。3.2.6.4 问题check list检查项备注3.2.7 问题7-切换过程中UE返回PhysicalChannleRecfgFailure（configuration unsupported）3.2.7.1 问题分析这种情况是RNC给UE发送的切换命令UE不支持导致。原因可能有UE的上行物理信道能力不支持等。3.2.7.2 Log抓取 该

21、问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log3.2.7.3 处理建议具体可以比较一下该UE和别的能够成功切换的UE的RRC SETUP COMPLETE消息中的UE能力有什么区别。另外，也可以比较一下成功切换和切换失败的切换命令消息，看有什么不同，排除网络侧配置因素。另外，需要检查一下该小区CAC算法的UE能力开关，看和成功切换的小区的该配置是否有区别。3.2.7.4 问题check list检查项备注UE能力开关小区CAC算法下的PDCP、RLC、Phy等UE能力开关，如果没有打开需要打开。3.2.8

22、问题8-切向一个小区总是失败-惩罚机制3.2.8.1 问题分析如果通过KPI或者CDL发现从小区A切换到小区B总是失败。在这种情况下，如果无法定位出具体原因，可以使用惩罚机制减少向小区B的切换尝试。3.2.8.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log3.2.8.3 处理建议通过设置 算法过程参数表（rRrmTimer）中，TimeArithOther（中文名称：其它算法定时器（单位：10ms），借用了该参数（该参数目前没有人使用）完成切换惩罚策略。具体该参数含义为：允许邻小区切换失败

23、的次数，例如设置为3（推荐设置为3，外场也可以根据自己的情况设定）。也就是如果某个邻区切换失败次数（会针对每个失败邻区都计数，有一个计数器）大于等于3次，那么该邻区就不能再作为目标小区了。 如果用户成功切换一次之后，相应的计数器会清0。3.2.8.4 问题check list检查项备注其它算法定时器算法过程参数表（rRrmTimer）中。3.3 经典案例4 TD系统内SRNS重定位4.1 原理和基本信令过程见附录6.4。4.2 常见问题概述问题描述问题1UE上报1g/2a报告后RNC不触发重定位；问题2SRNC发起Relo Require后CN返回Relo Require Failure；问题

24、3SRNC发起Relo Require后CN不响应Relo Command；问题4CN发给TRNC Relo Request后TRNC响应Relo Failure问题5CN发给TRNC Relo Request后TRNC不响应问题6TRNC返回Relo Request Ack后收不到RB Recfg Complete问题7SRNC发出RB RECFG 切换命令后SRNC等不到CN的IU RELEASE问题8SRNC发出RB RECFG后UE返回RB RECFG FAILURE问题9重定位成功后的其他问题-VP无图像问题10重定位成功后的其他问题-PS无速率问题11重定位成功后的其他问题-RU失

25、败问题12。4.2.1 问题1- UE上报1g/2a报告后RNC不触发重定位4.2.1.1 问题分析UE上报1g/2a MR的时机问题，因为RNC有HC算法定时器，在前一次切换或者其他算法过程完成后会启动该定时器，如果UE上报的1g/2a MR时机在算法定时器未超时前，RNC则收到该1g/2a MR不处理。这是设计如此，避免乒乓切换。UE上报1g/2a MR的服务小区绝对导频问题。这种情况仅限于切换的目标小区邻区类型为“非重叠全向相邻”的小区，此时UE上报1g/2a报告后，RNC会将上报的服务小区的导频值和HC算法中的“存在Cs/PS的信令连接服务小区绝对导频门限”进行比较，如果大于配置的绝对

26、门限，RNC不会切换。对于“非重叠扇区相邻”小区RNC不作此判断。所以出现UE上报MR不切时，可以检查目标小区的切换类型和服务小区测量结果。对于1g/2a触发的切换，RNC不会判断邻小区的绝对导频门限。对于其他算法（如：RLS）触发的切换RNC会判断邻小区的绝对门限。注意事项：目前同频1g、异频2a测量控制消息中的“相对门限-hysteresis”、“服务小区绝对门限-usedFreqThreshold”、“邻小区绝对门限-nonUsedFreqThreshold” 首先看小区算法参数中的“事件信息表”，如果小区下没有，则看RNC的UE测量中的事件信息表。不会看小区HC算法参数中的参数的。另外

27、，目标小区资源分配失败也会造成该现象。这种情况CDL中有专门的（资源分配失败的）CDL记录。定向切换功能打开着也是一种可能。切换之后不允许向前一次刚切换过来的小区切，但如果MR中仅包含了前一次刚切换过来的小区测量结果，那么就会找不到可切的目标小区。定向切换的具体参数配置是在HC算法中有“本小区是否支持定向切换”开关。4.2.1.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC配置数据 CDL 在LDT的RSPA模拟shell中敲： hsps_drm_show_arithstblpara CellID 4.2.1.3 处理建议HC算法定时器设置不合理，目前是1

28、0秒，可以适当减小；检查目标小区的邻区类型是否为非重叠全向相邻；检查MR中的服务小区测量结果是否小于HC算法下的服务小区绝对导频门限；检查“其他rnc小区表”配置对象下是否有目标小区的配置。4.2.1.4 问题check list检查项备注HC算法定时器在小区算法下目标小区邻区类型在邻小区节点下服务小区的绝对导频门限小区算法-HC算法下4.2.2 问题2- SRNC发起Relo Require后CN返回Relo Require Failure4.2.2.1 问题分析参考附录6.4重定位流程图，如果SRNC发起Relo Require后，CN返回Relo Require Failure，归类整理

29、有以下几种情况： 第一种，失败原因为Unknow Target RNC（未知目标RNC）。对应CDL原因：Relocation rejected because the target RNC is not known to the CN.分析：MSC 没有配置TRNC的数据。以下是贵阳项目出现该问题的分析：关于MSC之间的重定位：当3G用户在通话的过程中发生MSC局间切换事件时，如果切换的方向为由本局MSC Server控制的RNC切换到由其它MSC（相邻MSC）控制的RNC（相邻RNC），在切换的过程中，本局MSC Server需要通过MAP信令向相邻MSC发送Relocation Requ

30、est消息。根据3GPP协议的规定，3G用户在切换时向网络发送的Relocation Required消息将仅携带相邻RNC的RNC标识参数，这样，为使本局MSC Server与相邻MSC之间建立起正常的MAP对话，本局MSC Server就需要根据相邻RNC的RNC标识通过检索本地配置数据库来获得相邻MSC的MSC号码。此时，操作员需要在MSC Server侧配置相邻RNC数据，以建立相邻RNC的RNC标识与相邻MSC的MSC号码之间的映射关系。 第二种，失败原因为The action failed because requested information is not available

31、（请求的信息不可用） 分析为CN不支持无RAB时的重定位，所以CN直接给SRNC返回失败，带这种原因。可以通过关闭“仅有信令是否允许重定位”开关来规避。华为MSC有该问题。 第三种，失败原因为relocation-not-supported-in-target-RNC-or-target-system或者0x08000000。分析：TRNC收到SGSN发的Relo Request后，TRNC判断Relo Request消息和RRC容器中的RAB信息是否一致，如果不一致，TRNC会给RNC返回这个原因的失败。这种情况在ASB的SGSN中较多。 第四种，失败原因为Relocation was ca

32、ncelled due to interaction with other procedure。分析：这种情况主要是CS和PS双域同时进行了重定位，当一个域由于某种原因重定位失败，那么此时CN会给另外一个域发Relo require Failure，带该原因。问题根本还是要查首先引起失败的原因。 第五种，失败原因为The action is due to O&M intervention。分析：这种情况较少见，分析为CN直接给SRNC回失败的问题，需要CN定位。 第六种：No requested resource is available分析：RNC修改RANAP协议过程表中目标侧等待Uu侧重

33、定位完成定时器800-1500ms得以解决。 第七种，失败原因为Unspecial cause分析：该原因较常见，主要是SRNC在分配用户资源时失败导致，需要结合具体目标侧RNC的CDL分析。如能复现抓取UE信令跟踪和UE打印跟踪，结合配置数据，可以有效定位。4.2.2.2 Log抓取 该问题需要抓取RNC侧： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 在LDT的RSPA模拟shell中敲： hsps_drm_show_arithstblpara CellID 4.2.2.3 处理建议分析中已详细说明。4.2.2.4 问题check list检查项备注

34、目标侧等待uu侧重定位完成定时器接口协议-RANAP协议下4.2.3 问题3- SRNC发起Relo Require后CN不响应Relo Command4.2.3.1 问题分析出现该问题主要是TRNC分配资源时过程异常处理时间过长，或者SRNC侧“SRNC重定位准备定时器”设置过短，导致SRNC侧“SRNC重定位准备定时器”超时，SRNC发起Relo Cancel，原因是“timer TReocPrepare expired”。4.2.3.2 Log抓取 该问题需要抓取RNC侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） RNC配置数据 4.2.3.3 处理建议定位方法

35、可以根据SRNC的CDL找到目标RNC ID和CELL ID，在对应TRNC的CDL中分析资源分配过程，结合配置数据中该定时器的值，综合分析是资源分配问题，还是定时器过短问题。4.2.3.4 问题check list检查项备注4.2.4 问题4- CN发给TRNC Relo Request后TRNC响应Relo Failure4.2.4.1 问题分析TRNC响应Relo Failure实际上是导致CN给SRNC侧返回relocation-not-supported-in-target-RNC-or-target-system的因。那么本节中的TRNC的失败分析，就和4.2.2节中的分析基本相同

36、，当然，除了CN没有发给TRNC的那几种情况。4.2.4.2 Log抓取 该问题需要抓取RNC侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 4.2.4.3 处理建议略。4.2.4.4 问题check list检查项备注4.2.5 问题5- CN发给TRNC Relo Request后TRNC不响应4.2.5.1 问题分析同4.2.3节分析。4.2.5.2 Log抓取 该问题需要抓取RNC侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 4.2.5.3 处理建议略。4.2.5.4 问题check li

37、st检查项备注4.2.6 问题6- TRNC返回Relo Request Ack后收不到RB Recfg Complete4.2.6.1 问题分析这种情况是重定位过程中的主要问题。出现该问题的原因可能主要是：UE收到SRNC发送的RB RECFG后，UE返回RB RECFG COMPLETE。但是由于UL干扰或UE上行发射功率过小问题，目标小区基站无法检测到上行同步，致使UE的RB RECFG COMPLETE的消息无法转发到TRNC，重定位失败导致掉话。另外，需要观察SRNC是否收到目标小区NB上报的RL RESTORE，如果没有RESTORE，很有可能就是上行太差导致。4.2.6.2 Lo

38、g抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log4.2.6.3 处理建议出现该问题后需要抓取当时的UE侧log，观察干扰情况，同时如果能够复现的话，可以抓取目标小区的小区公共过程跟踪，分析基站测量的UL TS ISCP是否有异常。4.2.6.4 问题check list检查项备注4.2.7 问题7- SRNC发出RB RECFG 切换命令后SRNC等不到CN的IU RELEASE4.2.7.1 问题分析该现象同4.2.6节，只是本节站在SRNC角度来表述问题现象。4.2.7.2 Log抓取 该问题需

39、要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log4.2.7.3 处理建议出现该问题后需要抓取当时的UE侧log，观察干扰情况，同时如果能够复现的话，可以抓取目标小区的小区公共过程跟踪，分析基站测量的UL TS ISCP是否有异常。4.2.7.4 问题check list检查项备注4.2.8 问题8- SRNC发出RB RECFG后UE返回RB RECFG FAILURE4.2.8.1 问题分析一般具体的原因是PhysicalChannelFailure，造成这种情况主要原因是UE和目标小区同步不上，干扰大，RSCP

40、正常。另外还有一种原因是ConfigurationNotAccept，这种原因就是说网络给UE配置的新链路，UE不支持导致，需要查看UE的RRC SETUP COMPLETE消息的UE能力，结合目标侧小区的DCA的UE能力开关综合分析。4.2.8.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log4.2.8.3 处理建议目标侧小区的DCA的UE能力开关，如果没有打开需要打开。4.2.8.4 问题check list检查项备注UE能力开关DCA算法下4.2.9 问题9-重定位成功后的其他问题-V

41、P无图像4.2.9.1 问题分析一般出现在跨RAN厂家的重定位区域。广州出现过类似问题，后定位为连接大唐RAN和爱立信RAN之间的两个MSC之间互联问题，后CN修改解决。4.2.9.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log4.2.9.3 处理建议CN定位解决。4.2.9.4 问题check list检查项备注4.2.10 问题10-重定位成功后的其他问题-PS无速率4.2.10.1 问题分析有可能是PS重定位过程中SRNC CONTEXT 过程有问题导致。也有可能是目标小区的DCA或

42、者HSDPA算法设置问题。4.2.10.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log 使用wireshark软件从UE侧进行抓包分析4.2.10.3 处理建议需要具体分析wireshark的log，确认应用层是否在切换前后发生异常。4.2.10.4 问题check list检查项备注4.2.11 问题11-重定位成功后的其他问题-RU失败4.2.11.1 问题分析现象就是重定位流程成功后，UE在新小区发出的RU更新消息，网络侧收不到问题，后续UE15秒后重新发起RU成功。这种情况确认为联

43、芯终端bug导致，具体为重定位前在源小区没有进行完整性保护过程，在终端发起重定位时，终端的高层和物理层出现问题，从outum来看UE高层发出了上行直传（RU更新），但是实际上UE物理层没有发出该消息。4.2.11.2 Log抓取 该问题需要抓取RNC侧和UE侧log： RNC信令跟踪log RNC UE打印跟踪（如果条件具备） CDL RNC配置数据 UE侧log4.2.11.3 处理建议更换终端测试，并确认是否重定位前没有发生SMC完整性保护过程。4.2.11.4 问题check list检查项备注4.3 经典案例4.3.1 案例1 核心网（CS）参数未配置导致跨MSC的RNC间重定位失败的

44、案例分析该案例结合贵阳实际的情况，主要介绍了4.2.2.1节的第一种重定位准备失败的问题分析。5 3G/2G互操作 5.1 原理和基本信令过程见附录6.1。5.2 常见问题概述问题描述问题1RNC不发3A测量控制消息；问题2UE上报3A报告后RNC不触发系统间切换或重选。问题3RNC下发系统间切换或重选消息后，UE返回失败，原因为物理信道失败问题4RNC下发系统间切换或重选消息后，UE返回失败，原因为不支持的配置问题5UE已经成功重选到2G后SGSN没有释放IU连接问题问题6CS切往2G时CN不响应Relo Require或者响应Relo Require Failure问题72/3G互操作各种场景测试结果研究分析和优化策略5.2.1 问题1-RNC不发3A测量控制消息5.2.1.1 问题分析 思路：小区HC算法参数开关问题、UE支持gsm能力问题、邻区配