TD-LTE切换案例分析.ppt

TD LTE切换案例分析 交流目标 通过LTE切换案例的交流学习 了解LTE现网中常见的切换问题以及解决思路 Page2 1 漏配同频邻区导致切换失败2 A2门限太低导致下载速率低问题 含切换 3 C国H地区局点LTE入切换成功率为0 分析4 CIO配置不合理导致切换失败5 LTE重复覆盖导致切换失败和频繁 乒乓 切换6 LTE外部小区配置错误导致同频切换失败7 LTEDT测试中终端发起原因值为otherfailureRRC重建8 P国G项目MR不处理因素导致低吞吐率问题9 W市两个基站之间TAC配置错误导致切换失败10 ENODEBID设置重复导致无法切换11 LTE一个小区添加俩PCI相同邻区导致的切换问题 Page3 1 漏配同频邻区导致切换失败 现象描述 切换测试时 在UE移动过程中 发现有比当前服务小区质量好的小区 触发切换A3测量报告 并不停周期上报 但一直收不到网络侧的切换命令 随着UE移动服务小区RSRP越来越差 服务小区SINR越来越差 吞吐率越来越低 而邻区RSRP越来越好 Page4 Page5 最终在UE下行失步后在邻区发起RRC重建 重建被拒绝后 重新发起RRC接入邻区并建立业务 此时邻区的无线质量较好 业务恢复正常 Page6 原因分析 告警信息 无 原因分析 分析切换失败期间的相关信息 发现在UE第一次上报A3测量报告时 RSRP为 106dBm SINR约5dB 在这样的信号质量条件下 应该完全可以完成切换信令交互而成功切换 说明这里切换失败存在问题 再从网络侧记录的信令跟踪 可以看到eNB的UU口能收到UE上报的测量报告 Page7 Page8 从这里可以看到eNB收到测量报告后并没有下发切换命令 怀疑是不是X2接口向目标小区切换时失败导致 再查看X2接口 发现X2接口没有消息交互 也即eNB没有向目标小区发起切换请求 说明eNB判决切换测量报告的结果为不切换 再分析eNB不切换的可能原因有 Page9 切换惩罚 eNB对于非资源准入切换失败的小区要其经历一定的切换惩罚次数Intra freqHORetryPenaltyNumber 该值默认为10 后才能再次允许该小区进行切换 切换失败且重建到本小区的UE会受到切换惩罚 目标小区在核心网切换限制列表中 邻区漏配 目标小区禁止切换 对于以上四种原因 需要进一步在处理过程中进行排查和确认 Page10 如果是切换惩罚的原因 在IFTS跟踪内可以看到UEMTEXTPRINT显示eNB在收到测量报告后 判断目标小区为RetryPenaltyCell 查看IFTS跟踪文件并没有发现RetryPenaltyCell 而且该小区之前并没有出现非资源准入失败 流程失败 所以排除切换惩罚的原因 经核心网确认并没有将服务小区和目的小区配置进切换限制列表 目标小区禁止切换开关在同频邻区关系中配置和显示的 需要进行同频邻区配置的检查再从LMT上查看ANR开关为关闭 X2口 S1口配置均正常 再查看这两个小区的邻区关系配置 发现两个小区的同频邻区关系没有配置 至此 基本可以确认问题在于邻区漏配 Page11 解决过程 解决方法1 打开ANR算法开关实现自动邻区增加 命令为 MODENODEBALGOSWITCH SONAnrAlgoSwitch IntraRatEventAnrSwitch 1UE在上报A3测量报告后 eNB会下发控制CGI读取的重配置命令 UE测量目标小区 读取CGI后上报给eNB eNB再发切换命令给UE 从而完成切换流程 成功切换 解决方法2 手工增加邻区配置 用 ADDEUTRANINTRAFREQNCELL 命令给两个小区的邻区关系并打开允许切换开关后也可以使UE正常切换 Page12 Page13 建议与总结 切换的问题先从信令入手 再分析信令流程失败点所有可能的原因 采用逐一排除 逐一确认的方法来找问题原因 Page14 2 A2门限太低导致下载速率低问题 含切换 现象描述 TDDLTE校园网 西城中州大学 D频段小区 附近有一路段 UE一直占用师专新校2小区 F频段小区 覆盖比较差 速率低 如下 Page15 优化前RSRP Page16 优化前PDCP层下载速率分布图 Page17 原因分析 车辆在西城中州大学校园自北向南行驶中 UE一直占用F频段师专新校2小区 PCI71 RSRP恶化到 111dbm的时候 eNodeB才向UE下发异频测量控制信息 异频测量切换信令流程如下 Page18 异频测量控制下发 Page19 UE上报异频测量结果 Page20 eNodeB下发切换判决结果 目标小区西城中州大学1小区 PCI75 Page21 在后台查询师专新校F2小区 PCI71 的A2RSRP触发门限为 109 A2触发门限太低 主服务器小区信号恶化到 111dbm的时候才发起异频测量 导致该路段RSRP很差 下载速率偏低 Page22 解决方案 将师专新校F2小区 PCI71 的A2门限提高到 95 A1RSRP触发门限由 105改为 91 参数修改之后问题路段指标提升明显 测试情况如下 Page23 建议与总结 1 A1和A2是门限用于控制异频和异系统测试量的 A1用于停止测量 A2用于启动测量 A1的值要比A2的值高 因此A2参数修改的时候 A1参数也要同步修改 2 异频测量门限不能设置太高也不能设置太低 设置过低导致源小区信号强度很小 吞吐率已经严重下降的情况下 才发起异频邻区的测量 此时目标小区信号强度已经很强的情况 但是没有及时切换 使得吞吐率迅速下降 A2门限设置过高 导致触发UE过早地进行了异频测量 由于异频测量需要专门分配一定时频资源进行 减少了UE可用的时频资源 导致调度次数不足 影响吞吐率 Page24 异频测量参数的设置可参考如下经验值 Page25 3 C国H地区局点LTE入切换成功率为0 分析 现象描述C国H地区进行每日KPI指标统计的时候发现小区出现入切换失败次数为100 KPI指标如下图所示 Page26 查看小时级指标从13号凌晨出现问题 查看对应问题时间点的操作日志 发现在13号凌晨没有任何操作 Page27 原因分析 怀疑是否是由于站点无资源导致的入切换全部失败 但是查看用户数统计发现没有用户在这个站点下面做业务 查询一个月的平均用户数 发现周末应该是有用户使用LTE网络的 Page28 对小区的其他指标进行分析 发现如下情况 问题时段RRC请求次数为0问题时间段随机接入次数不为0 Page29 RRC建立之前的随机接入过程是有用户请求 也就是说在下 图5 A点 B点有统计说明随机接入网络侧都是有响应的 但是在进入到了RRC接入过程后 图6 网络L3没有收到终端RRC请求 原因是RRC请求次数为0 Page30 Page31 而睡眠小区一般表现为eNodeB的L3收不到UE的RRC建立请求消息 也出问题在图7红色标注部分 与此问题站点的现象非常一致 没有告警 没有操作日志 DSP小区状态也正常 没有用户接入和流量 但是有随机接入过程 Page32 处理过程 确认疑似睡眠小区的情况后 我们在16日凌晨3 00进行了重启基站的操作 观察指标如下 重启 站点业务恢复正常 Page33 建议及总结 在商用网中 睡眠小区很有可能会存在在网络中 这种小区查询状态时完全正常 DSPCELL 也没有任何异常告警上报 但用户实际上不能接入 非常影响用户感知 并且很多情况下是客户投诉才发现此类问题 所以在现网维护项目中 尤其在LTE建网初期 一个好的例行指标监控流程及工作必不可少 通过监控可以更早的发现网络中出现的问题 变 救火 为 防火 睡眠小区的监控可以通过随机接入请求 RRC请求 入切换指标及最大用户数等相关指标来判断 另外 现在处理睡眠小区的途径还只是重启基站这一条路 Page34 4 CIO配置不合理导致切换失败 现象描述 K国Z局点的站点1213中小区7切换到站点1252的小区9过程中 未完成切换流程就出现重建 导致切换失败 业务中断几秒后 UE重建接入小区9中 数传恢复 Page35 原因分析 对于切换失败问题 可以通过以下几个方面进行定位 从覆盖角度考虑 如果在切换点上存在着覆盖问题 在某区域上某个方向上由于建筑物等的遮挡 导致UE在该区域内出现信号质量的大幅抖动 切换失败 从配置角度考虑 如果出现影响切换的相关参数配置不合理可能导致切换失败 如切换门限设置 切换时间迟滞设置 切换CIO设置 这些参数设置不合理都有可能造成错过最佳切换时机导致切换失败 从传输角度考虑 可能因为存在传输问题导致切换失败 如eNB到核心网的传输 两个站间的传输 这些数传问题都可能导致出现切换失败 Page36 处理过程 首先考虑覆盖的问题 因为切换点K区域是处于目标小区覆盖信号很弱的拐角点 天线到该位置的直线空间里有一座较高的楼房 一直怀疑该楼房的阻挡影响信号覆盖 现场情况如下 Page37 其中A B C为组成三角关系的三个站点 在K区域发生切换失败 在B站点前面有一个三角形的建筑物 挡住目标站点发到K区域的信号 调整了基站B的目标小区的天线角度以后 K区域的信号也没有提高 可见 现场由于环境限制 无法通过调整覆盖来解决切换问题 接着要尝试能否通过调整参数来解决 Page38 从消息跟踪结果来看 在UE测量到目标小区的RSRP比服务小区的RSRP差值超过切换门限发出测量报告 但是源小区信号质量下降太快没有收到测量报告 从而使UE只能在目标小区发起随机接入过程 根据实际情况 基站安装位置难以更改 天线调整也起不到作用 这时可以考虑通过调整切换相关参数 提前进入切换流程 应该可以解决问题 Page39 查看切换相关参数 因为切换门限和迟滞时间都涉及到多个小区 且在和其他小区的切换中不存在这种需要提前切换的问题 所以这几个参数不需要修改 使用查看CIO配置 该配置默认值都为0 因此要修改这个参数让切换提前 经过数次测试 将邻区的小区偏置修改成1dB 2dB以后 切换正常 Page40 Page41 使用LSTEUTRANINTRAFREQNCELL 查看CIO如下 建议与总结 在现实场景下 往往会出现许多切换过晚现象 可以通过调整切换相关参数配置来提前切换达到解决切换失败的目的 参数修改过程有一个注意的问题是 修改切换门限和切换迟滞时间固然也可以达到提前切换的目的 但是因为这两个参数都属于小区级参数 一旦修改 将会造成和所有邻区的切换点发生改变 因此修改后风险较大 大多数情况下都不应修改 因此一般可以通过修改CIO配置参数达到相同的目的 而其只对特定的小区有影响 Page42 5 LTE重复覆盖导致切换失败和频繁 乒乓 切换 现象描述 Z省H项目Cluster优化过程中 对Cluster21进行优化发现某拐角区域出现切换失败现象 并且该区域切换频繁 存在两小区间的乒乓切换现象 Page43 原因分析 从某路段的路测数据中可以发现切换失败导致掉线的事件点 Page44 我们首先要定位原因 可以看出 在切换前的服务小区为PCI 54小区 查看MeasurementReport测量报告 查看切换的目标小区 明确切换方向 Page45 MR显示 切换的目标小区PCI 56 实际上切换是发生在站内的54小区向56小区的同频切换 进一步分析所在区域收到的导频信号可以发现 在该切换点上 同时收到了四个小区的导频信号 分别是PCI 54 PCI 7 PCI 56 PCI 6 属于四个小区重复覆盖的区域 且导频信号的参考功率RSRP的值都相当 属于同等覆盖 如下图所示事件点收到的导频信号情况 Page46 Page47 可以看出 由于切换时由54小区向56小区发生的 且8小区与56小区Mod3的结果同为2 结果相同 因此导致干扰 该区域的SINR 信干燥比 的值下降 造成了最终的切换失败掉线现象 下图为该区域的SINR变化情况 Page48 通过分析可以看出 切换发生在54 56小区的基站内部 失败主要是由于相邻基站的小区重复覆盖造成的Mod3干扰所致 并且由于地理位置特殊 处于两处转角的区域 无线环境复杂 干扰较大 在一定的路段出还现了乒乓切换的现象 如下图A点到B点的路段 共发生了6次同频切换过程 且在B点处SINR值很低 干扰严重 因此 对于该区域的优化方案需要综合考虑两基站间和地理环境等因素来解决 Page49 Page50 处理过程 将上方基站的8小区与6小区PCI的值进行对调 避免Mod3干扰现象 并且为减少频繁切换 将56小区向原8小区 对调后的6小区 切换的CellIndividualOffset 对应同频切换A3事件进入公式Mn Ofn Ocn Hys Ms Ofs Ocs Off中的Ocn 的值适当减小 增加切换难度 同时 将56小区向原8小区切换的时间迟滞IntraFreqHoA3TimeToTrig由320ms调整为640ms 防止频繁切换 Page51 建议与总结 由于该区域处于多拐角的区域 需要两个或以上小区的覆盖 无法避免重复覆盖现象 因此在优化中以调整同频切换的参数优先 如果效果不理想 可适当降低干扰小区的天线发射功率 如果还是无法达到理想效果 可考虑压更改干扰小区的天馈系统 减小其对问题区域的覆盖 达到降低干扰的目的 对参数进行调整后复测 切换次数明显减少 未出现切换失败现象 建议在类似的问题及事件处理过程中 结合不同区域的地理及无线环境分析进行有针对性的Cluster优化 Page52 6 LTE外部小区配置错误导致同频切换失败 现象描述某LTE项目 在使用移动终端CPEB593s进行测试过程中 某区域总是切换失败 未成功一次 如下图所示 Page53 问题分析 回放测试LOG 对问题进行深入分析 发现该区域主要存在华立大厦 1 华立大厦 2 怡和大厦 1三个小区的信号 UE在由北向南行进 应该由华立大厦 2小区切向怡和大厦 1小区 从图切换失败问题呈现中可以看出 但是 仔细分析发现 UE占用华立大厦 2 PCI 104 切向目标小区怡和大厦 1 PCI 85 而切换请求中目标小区PCI却为84 如下图所示 Page54 Page55 Page56 从上面的分析发现 怀疑邻区相关数据配置存在异常 检查以往的参数修改记录 发现怡和大厦 1和怡和大厦 3小区的PCI由于怡和大厦 1和华立大厦 1的PCI同为MOD0 存在MOD3干扰而进行过PCI互换 如下图所示 Page57 核查与怡和大厦存在邻区关系的站点的外部小区数据 发现怡和大厦相邻站点的外部小区数据中的PCI数据均未进行相应的调整 这三个站点的外部小区中怡和大厦 1和怡和大厦 3的配置如下表所示 Page58 Page59 解决方法及验证 根据上面的分析 由于外部小区数据配置错误 导致同频切换失败 将上述错误修改如下 修改该数据的MML命令如下 MODEUTRANEXTERNALCELL ENODEBID 524505 CELLID 31 PHYCELLID 85 MODEUTRANEXTERNALCELL ENODEBID 524505 CELLID 33 PHYCELLID 84 Page60 调整后切换失败事件消失 问题闭环 如下图所示 Page61 Page62 总结与建议 这个问题是典型的优化调整缺乏系统性的一个表现 在GSM网络中 系统以主B频点和BSIC来确定邻区 在LTE中 系统以频点和PCI来确定邻区 跟GSM网络类似 在修改小区的主B频点或者BSIC之后 都要查看是否涉及有外部相邻小区需要更新 在LTE中由于没有了BSC级的网元 每个基站都存在所谓的外部邻区 只要是修改了频点或者PCI 通常情况下都是需要更新外部邻区描述的 这需要作为一个规定动作去落实 Page63 7 LTEDT测试中终端发起原因值为otherfailureRRC重建 现象描述 H省C局项目 进行TD LTE网络DT测试过程中 车辆行至某两个小区边缘区域时 终端发起原因值为otherfailure的RRC重建 之前无RRC异常释放 RRC重建失败 切换失败等事件 Page64 原因分析 使用Assistant对测试Log进行分析 信令RRCReestablishAttempt原因值为otherfailure Page65 上图所示为RRC重建事件点 可看出重建发生在两小区边缘地带 不存在掉线等异常事件 但此时主服务小区RSRP值为 69 而邻区RSRP值为 53 电平差值较大 Page66 Page67 根据Serving nighboringCell图中显示 虽然服务小RSRP值还处于正常水平 但此时邻区电平值已高于服务小区16dBm 服务小区RSRQ已降低到 20 信令上显示 终端一直上报MR测量报告 但未执行同频切换 因此判断终端发起RRC重建原因为 测量邻区RSRP高于服务小区 终端上报MR但未执行切换导致服务小区服务质量快速下降 UE检测到 radiolinkfailure 发起原因值为 otherfailure 的RRC重建 进行切换参数确认 分析未及时切换原因 发现该事件中 服务小区向邻小区切换的同频邻小区偏置CIO为 10 属于不合理设置 因此判断为参数设置不当 导致切换不及时 Page68 处理过程 考虑到该区域为基站密集区域 之前调整CIO为 10以减少频繁切换现象 但由于参数值修改过大 导致切换不及时 终端发起RRC重建 通过对切换参数的修改 将CIO调整为0 并将服务小区的切换时间迟滞TimeToTrig由320ms调整为640ms 同频切换幅度迟滞Hys修改为3 以减少频繁切换 参数修改后复测多次 未出现RRC重建事件 Page69 建议与总结 在对于同频切换的优化中 CIO的值修改不宜过大 一般在 3到3dB之间 对于存在频繁切换现象的小区 可考虑对小区级切换参数 时间迟滞及幅度迟滞Hys进行适当调整以减少频繁切换现象 Page70 8 P国G项目MR不处理因素导致低吞吐率问题 问题描述 P国G项目LTE工程为公司A级项目工程在P国支持G项目LTE工程时 接到客户邮件投诉 作为本国本地区较为重要的商业中心 客户较为关心其信号质量问题 客户择期在连接商业L区与G5区的人行天桥上进行了单独测试 吞吐量结果是 DL在7Mbps左右 UL在500kbps左右 更有甚者 在测试的其中一个地点 DL仅是557kbps UL仅是154kbps 客户发邮件投诉质疑 为什么在本地区没有LTE其他用户的情况下 吞吐率如此差 要求给出问题原因及解决方案 Page71 问题分析 此问题属于TOP小区问题 为室内分布基站特定地区低吞吐率问题 需实地路测得到测试log 分析后得出问题解决方法 在此案例中 计划用三步骤来分析定位问题 Page72 Page73 首先检查此地区信号覆盖情况 RSRP与SINR DL 由上图可以看出 此段天桥上的覆盖非常弱 RSRP在 90dBm以下占到47 SINR在5dB以下的达到80 Page74 由于下行的RSRP和SINR很差导致下行的吞吐率很低 大部分在10Mbps以下 但是上行的吞吐率没有受到影响 原因在于LTE的上行采用的是SC FDMA技术 每个用户所分配使用的频带是不一样的 因此上行的干扰主要是来自不同用户之间的干扰 测试时在此地区只有一个测试终端 用户 因此上行吞吐率正常 而下行的干扰主要来自邻区的同频干扰 Page75 二 检查周边小区情况核查参数ServingRSRP 1stNeighboreRSRP 在此基础上 选择此参数值在 3dBm以下的区域 重点考察这区域的ServingPCI和1stPCIinNeighboreCells 可以初步判断此区域应该是由ServingPCI所对应小区向1stPCIinNeighboreCells所对应小区切换 之所以没有顺利切换 是因为邻区漏配导致 再对相应信令进行核查 做进一步确认 通过核查ServingRSRP 1stNeighboreRSRP 可以看出在此天桥上大部分地区主服务小区的信号都比第一邻区的信号要低很多 两者差值在 3dBm以下的达到86 这说明存在严重的邻区漏配现象 Page76 Page77 进一步看这区域的ServingPCI和1stPCIinNeighboreCells Page78 由上图可以很清晰地看出 ServingRSRP 1stNeighboreRSRP筛选出小于 3dBm的区域 对应的应该会有两个切换顺利进行才对 由主服务小区PCI12对应的小区理应向PCI82对应的小区切换 主服务小区PCI72对应的小区理应向PCI82对应的小区切换 Page79 三 从信令流程上确认邻区问题从L3Message上可以看到 终端主服务小区是PCI12对应的小区时 终端每隔240ms上报一次A3事件的MeasurementReport ENODEB对上报的MR不处理 这些MR上报的邻区PCI均包括82 偶尔会有PCI83 平均来看 PCI为82的小区RSRP比PCI12的小区RSRP要高10dBm左右 如下图 Page80 Page81 ENODEB侧由于没有检测到配置PCI82作为其邻区 因此一直没有给UE下发切换执行的 RRCConnectionReconfiguration 最后一次MR中包含了PCI为78的邻区 比主服务小区高6dBm 因为在配置中有此小区作为邻区 因此ENODEB侧给UE下发了向PCI78的目标小区切换执行命令 信号从PCI12的小区切换到PCI78的小区 Page82 Page83 对主服务小区是PCI78的小区 进行L3Message跟踪 可以同样发现 PCI78的小区一直上报含有邻区PCI82的MR 因为两者没有配备邻区关系 ENODEB侧一直不下发切换指令 Page84 四 总结问题原因综上因素 可以判定出现天桥地区低吞吐率问题的原因有以下两点 下行信号覆盖很差 RSRP在 90dBm以下占到47 此区域段出现邻区漏配现象 作为当前主服务小区的PCI12 PCI78都没有配置PCI82作为邻区 因此导致信号不那切换到最强小区 一直停留在较弱小区 Page85 处理过程 一 在客户M2000上 检查PCI12与PCI78对应的邻区配置 检查同频邻区关系 在对应小区MML执行LSTEUTRANINTRAFREQNCELL 检查是否有PCI82对应的小区作为邻区 经过检查同频邻区 可以看到有这样的邻区关系 PCI12 GREENBELT4F 1 PCI82 RIZALDRVF 3 PCI78 GBELTRDEV2F 1 PCI82 RIZALDRVF 3 由此可见 同频邻区是已经成功配置的了 但是只配置了同频邻区的情况下 还不能确定一定会顺利发生切换 还要额外检查一下外部小区情况 ENODEB侧在处理UE上发上来的MR时 过程是提取MR中所携带的小区的PCI 根据此PCI值在外部小区中检查是否存在此PCI所对应的小区 如果唯一存在 再根据小区名检查是否已经将此小区配置成目标小区的邻区 如果上述两步都唯一存在 ENODEB侧就下发切换指示 Page86 二 运行MML命令LSTEUTRANEXTERNALCELL 看到 1 PCI12 GREENBELT4F 1 配置有两个PCI为82的外部小区 一个是正确的对应小区RIZALDRVF 3 另外一个是配置出现错误的小区 显示名字是NULL 但是PCI是82 其他配置都同RIZALDRVF 3一样 分析原因可能是无线侧在下发配置邻区脚本时出现手工错误 这一小区导入了两次 导致出现了PCI相同的外部小区 2 PCI78 GBELTRDEV2F 1 配置的外部小区中没有找到PCI82对应的小区RIZALDRVF 3 因为配置LTE同频邻区的步骤是首选配置外部小区 然后再配置邻区 邻区是包括在外部小区里的 既然没有配置外部小区 那么单纯的配置邻区是没有作用的 找到上述问题后 对于PCI12 GREENBELT4F 1 小区的操作是 删除多余的外部小区 保证PCI82唯一存在 对于PCI78 GBELTRDEV2F 1 小区的操作是 增加RIZALDRVF 3为外部小区 Page87 总结与建议 配置邻区时 外部小区和邻区是对应的 不能只顾配置了邻区关系而忽略了外部小区 如果外部小区没有配置正确 单纯看邻区关系是没有意义的 同样ENODEB侧也不会处理MR Page88 9 W市两个基站之间TAC配置错误导致切换失败 问题现象 从A基站2小区到B基站2小区过程中 发现一段道路主服务小区的RSRP一直处于 128dbm以上 而辅服务小区的信号都在 80DBM左右 在此种情况下没有发生站间切换 Page89 问题分析 首先判断是否由于邻区漏配导致 通过后台查询发现A基站2小区与B基站3个小区都已经配置了邻区 故此问题不是由于临区漏配导致的 观察切换信令流程是否正确 站间切换流程从ASSISTANT分析如下 目前X2接口还没有配置 发生S1接口切换 1 首先有MeasurementReport上报 Page90 Page91 从中可以看到A基站3个临小区的RSRP都在 75dbm左右 都属于信号强点 而此时A基站二小区RSRP为 123dbm 根据此A3报告应该要发生切换的动作 3 其次看到了TrackingAreaUpdateRequest W市的TAC和G网的LAC配置的完全一致 一个基站目前就是一个TAL 所以目前从基站到基站侧的肯定会有TAU更新的操作 Page92 Page93 从LOG可以看到目标小区TAC为39198 通过后台查询 目标小区的TAC为39188 Page94 发现配置的TAC和实际后台配置的TAC不同 可见后台对于TAC配置错误 4 紧接出现TrackingAreaUpdateReject Page95 从LOG中可以看到ATU拒绝的原因是由于Implicitlydetached 隐式分离 导致的 再次之后 他会重新发起ATTACH流程 驻网成功 以下是协议对隐式分离的解释 10 Implicitlydetached TheUEshalldeletethelistofequivalentPLMNsandshallenterthestateEMM DEREGISTERED NORMAL SERVICE TheUEshalldeleteanymappedEPSsecuritycontextorpartialnativeEPSsecuritycontext TheUEshallthenperformanewattachprocedure IfA GbmodeorIumodeissupportedbytheUE theUEshallhandletheGMMstateasspecifiedin3GPPTS24 008 13 forthecasewhenthenormalroutingareaupdatingprocedureisrejectedwiththeGMMcausewiththesamevalue Page96 总结建议 由以上分析可知 是由于目标小区TAC配置错误 导致ATU流程失败导致 从基站A切换到基站B失败 通过修改为正确TAC问题已经解决 Page97 10 ENODEBID设置重复导致无法切换 现象描述14号大街 华虹光电附近 UE占用华虹光电1 RSRP为 93dBm SINR为1 0dB 一直未切换到得力纺织2 导致下载速率为1Mbps左右 Page98 Page99 Page100 原因分析 设备是否存在故障 功率设置是否合理 切换参数设置是否合理 邻区配置是否遗漏 邻区PCI是否混淆或者冲突 Page101 处理过程 1 查询基站运行情况 小区状态正常 无告警 2 功率设置该小区CRSPW 8 2dBm 在正常范围之内 3 查看切换参数 邻区得力纺织2RSRP 84dBm 满足切换门限邻区比服务小区高3dB 持续时间640ms切换条件 4 查看邻区配置完整性 周围两层邻区均正确配置 5 查看外部邻区的PCI设置 没有PCI混淆和冲突情况 6 分析前台测试log 发现终端持续上报MR 在UE多次上报测量报告无法正常切换情况下 后台虚用户跟踪信令出现MME回复S1AP HANDOVER PREPARATION FAIL消息 详细原因为MME无法识别目标基站 710499 提示unknown targetid 未知目标标识 Page102 Page103 根据经验 unknown targetid存在两种可能 一 上报的目标eNodeB不存在 二 在同一核心网EPC下如果上报的目标eNodeBID存在重复现象 核心网在无法辨别的情况下 也是发送unknown targetid消息的 所以华为EPC下面下挂两个相同eNodeB标识的基核心网EPC与eNodeB的映射是通过S1AP链路连接 所以 一条S1AP链路对应一个eNodeB 且链路号必须核心网和eNodeB侧必须一致 但是从核心网侧查询到eNodeBid为710499站点对应两个基站 IP地址分别为172 29 60 81和172 27 60 18站 其中IP地址172 29 60 81为得力纺织站点 而172 27 60 18在华为OMC网管并未查询到该站点 Page104 Page105 后发现在EPC上诺西有相同有一站点eNodeB标识710499 修改后 外场验证测试时 得力纺织仍然存在无法入切换问题 复位S1接口后再次复测 华新电缆3能够正常切入得力纺织1小区了 下载速率由1Mbps提升到30Mbps以上 Page106 Page107 Page108 持续观察得力纺织基站入切换话统指标 eNodeB间入切换指标已恢复正常 Page109 建议总结 在建网初期 NODEBID的规划需要按照规则进行 保证全网站点NODEBID规划合理并且唯一涉及到切换问题 首先应核查切换参数合理性 PCI是否混淆或者冲突 涉及到其他网元问题 应顺藤摸瓜 找到问题的根因并处理 Page110 11 LTE一个小区添加俩PCI相同邻区导致的切换问题 Page111 问题描述M国FDDLTE局点 添