项目

一般

简介

错误 #2467

15Ppre1_T5版本，3.3G同频切换，因时序问题导致的切换流程异常。

由 孙 泽林 在 10 个月 之前添加. 更新于 7 个月 之前.

状态:
已解决
优先级:
普通
指派给:
孙 泽林
类别:
-
开始日期:
2024-11-27
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
CU
发现问题版本:
Rel_2.1.15P
目标解决问题版本:
Rel_2.1.15P
FPGA板卡类型:
CPU类型:

描述

15Ppre1_T5版本，3.3G同频切换。切换流程异常
和目标侧收到reconfiguration complete和DownlinkRANStatusTransfer的时序性相关
若重配完成在前就会导致基站不向核心网发HandoverNotify，切换流程异常，终端切换后掉线。
同步基站和核心网侧时间后，因系统暂不稳定，待验证。

文件

ng切换偶现无notify.rar (2.56 MB) ng切换偶现无notify.rar 孙 泽林, 2024-11-27 09:56

历史记录

#1

由 席 振斌 更新于 10 个月 之前

问题原因：通过目前基站侧的报文分析，直接原因是目标侧DownlinkRANStatusTransfer在重配置完成信令后收到，导致目标侧资源块的状态机更新错误，根据源侧和目标侧的信令流程的时间间隔推测根本原因为核心网处理UplinkRANStatusTransfer到发出DownlinkRANStatusTransfer的间隔太长了，导致目标侧在重配置完成才收到DownlinkRANStatusTransfer，DownlinkRANStatusTransfer必须要在重配置完成之前收到，目标侧才能更新hfn和sn,这样切换后目标侧的上下行数据才不会有问题；

需要再复现一次，根据基站和核心网的报文在时间点对齐后再分析，证明根本原因的推测

#2

由 席 振斌 更新于 10 个月 之前

  • 状态 从 新建 变更为 进行中
#3

由 席 振斌 更新于 9 个月 之前

因为协议对这两条信令的先后顺序没有明确的要求，所以目前cu侧做了一步防护，就是如果重配置完成信令走在了DownlinkRANStatusTransfer之前，通过修改状态机让它的流程走下去，这样可能会丢失这一秒内的部分上行数据，但对整体来讲应该不会有太大的影响，这个之所以只在cu做了防护，是考虑对接的核心网和源基站如果不是咱们厂家的不可能要求人家整改，所以这个防护是必须的

#4

由 刘 抒放 更新于 9 个月 之前

友商功能的做法是将这些异口先后到达的信令进行缓存处理。比如重配完成先上来后缓存在基站内，可以是RRM也可以是RRC。之后等待DLSNtransfer的到来。这样也不会丢包也不会丢失业务

#5

由 席 振斌 更新于 9 个月 之前

  • 状态 从 进行中 变更为 转测试
  • 指派给 从 席 振斌 变更为 孙 泽林
#6

由 席 振斌 更新于 9 个月 之前

缓存只是延迟了信令的处理时间，终端发送了重配置完成就可以发送上行数据了，上行的部分丢包没法规避，只是mac和rlc的重传功能会让包丢的少一点

#7

由 孙 泽林 更新于 7 个月 之前

  • 状态 从 转测试 变更为 已解决

截止16PT2测试，未再出现时序问题导致的切换失败

导出 Atom PDF