卡特TD-LTE-D频-华为TDS升级F频段站点切换失败案例 - 图文

D频段-华为TDS升级站点切换失败

【问题描述】

为快速增强道路覆盖，补充覆盖盲区，在原有华为TDS站点基础上升级站点到F。

站点开通后，对其覆盖进行评估测试，测试中，卡特-》华为可以切换，但华为-》卡特无法切换。经过多次测试，并在其他F站点下进行验证，均不能正常切换。

TDS升级站点-沙洲社区中心覆盖评估.doc

切换情况如下图所示：

卡特D频段站点可成功切换至华为F

第1页 共6页

F频段→D频段切换不成功

检查卡特站点相关邻区及参数设置，均无问题。

【问题分析及处理】

为详细分析问题原因，开启相关站点calltrace再次进行测试跟踪。

对比华为和卡特后台信令，无论F沙洲社区中心六期向MME发送HandoverRequired的目标小区是哪一个D频段小区，都会收到HandoverFailure（value Cause : misc : unspecified），并且发送多条MR未收

到RRCConnectionReconfiguration。此为现象，如下图：

第2页 共6页

沙洲中心切换问题初步分析_刘晓航.docx

现场和朱明辉老师沟通，就此问题提交AR，升级研发分析处理相关问题。 11月2日核心网侧对路测IMSI进行了跟踪，结果如下：

1. 华为ENB向MME发送了handover Required，其中target macro ENB ID=0x502eb=328427，对应ENB IP=100.68.3.21，在MME中可看到该ENB为正常。

2. MME向目标ENB发送handover request, ENB返回了handover failure,cause=unspecified. 从上面的跟踪，核心网侧得到以下结论：

MME

能够正确处理源

ENB

发送的切换请求，将其中切换具体参数

id-Source-ToTarget-TransparentContainer透传给目标ENB，至于目标ENB为何返回失败，核心网侧无法判断。这个解析和空口现象一样。

经总部GPS专家分析，HO出错的原因是在对HO required这条消息中的字段SourceeNB-ToTargeteNB-TransparentContainer里的rrc-container进行ASN1解码时失败，该字段对核心网是透明的，和核心网无关。后详细分析，出错点是在解physicalConfigDedicated 这个ie的扩展块时发生，其中有三个扩展块（value=2），而目前R9的协议里只定义了一个扩展块（value应该=0），R8的协议里没有规定带扩展块。

现场咨询HW网优技术人员， HW目前enodeB版本开发平台基于R10协议，当前软件版本是R9的。由此

第3页 共6页

初步判断问题原因是双方协议不匹配。经和客户协商后，现场将一个邻区站点升级到LR13.3，再进行验证测试（LR13.3能够正确解码，需验证）。

【优化效果】

现场选取雨润路试扩L这个站点，版本升至LR13.3。验证和F沙洲社区中心六期之间的切换问题。 经复测，华为-》卡特能够成功切入。如下图所示：

升级后F→D切换成功

在其他F频段站点下面做验证测试，如下面关注F定淮门西拉远站(W)_1与晚宴试扩L_3的切换关系，

在晚宴试扩L升级至LR13.3后做切换验证测试，站间能够切换成功。

测试情况如下：

第4页 共6页

（D→F切换成功）

（F→D切换成功）

12月2日对华为升级站主要分布的江宁区域（VoLTE实验区域）F-D之间的切换做重点评估。

测试结果显示，FD之间切换正常，成功率为100%。详细统计如下：

D频段环境 FD混合环境 D频段时长占比 F频段时长占比 切换成功率 100% 85.51% 0% 14.49% 100% 100% 主服小区占用频点统计图【下图红色部分为F频段，时长占比14.49%】：

第5页 共6页

【结论】

1、对于异厂家站点之间的切换问题，由于双方协议不匹配，造成对对华为发过来的码流rrc container（HandoverPreparationInformation）的解码出错，从而导致F→D切换不成功；

2、根据总部专家研究反馈，从解码的结果来看，华为即使是按照R10的协议来发的码流，但是physicalConfigDedicated这个ie信息带的信息也过于冗余，从码流来看指示该ie带了三个扩展块（前导bit为1），但实际上后面又没有带扩展块（虽然协议没有明确禁止这种行为），总之不是完全符合协议规范，此为问题的具体出错点；

3、结合客户的要求，根据南京现场的实际情况，考虑时间的紧迫性，解决方案是我们升到LR13.3，以能够正确解码从华为发过来的码流，经过验证，在LR13.3下，F-D可以正常切换；

4、此次问题的处理，沟通是关键，特别是和客户的沟通，以及不同厂家之间的沟通协调也是关键。此次问题发生时间处于集团巡检即将到来的关键时期，而LR13.3 又无法在短时间内大范围部署（涉及与华为有切换的宏站有200个）。因此时间非常紧迫，压力非常大，基本全部集中在我们一边。因此此类的问题需和客户负责人协商，组织双方人员交流会，当面沟通分析问题，找出最优、最有效的解决手段，为实现互联互通扫清障碍。

第6页 共6页

【结论】

1、对于异厂家站点之间的切换问题，由于双方协议不匹配，造成对对华为发过来的码流rrc container（HandoverPreparationInformation）的解码出错，从而导致F→D切换不成功；

2、根据总部专家研究反馈，从解码的结果来看，华为即使是按照R10的协议来发的码流，但是physicalConfigDedicated这个ie信息带的信息也过于冗余，从码流来看指示该ie带了三个扩展块（前导bit为1），但实际上后面又没有带扩展块（虽然协议没有明确禁止这种行为），总之不是完全符合协议规范，此为问题的具体出错点；

3、结合客户的要求，根据南京现场的实际情况，考虑时间的紧迫性，解决方案是我们升到LR13.3，以能够正确解码从华为发过来的码流，经过验证，在LR13.3下，F-D可以正常切换；

4、此次问题的处理，沟通是关键，特别是和客户的沟通，以及不同厂家之间的沟通协调也是关键。此次问题发生时间处于集团巡检即将到来的关键时期，而LR13.3 又无法在短时间内大范围部署（涉及与华为有切换的宏站有200个）。因此时间非常紧迫，压力非常大，基本全部集中在我们一边。因此此类的问题需和客户负责人协商，组织双方人员交流会，当面沟通分析问题，找出最优、最有效的解决手段，为实现互联互通扫清障碍。

第6页 共6页

本文来源：https://www.bwwdw.com/article/3a5x.html