错误 #935
历史记录
- 状态 从 新建 变更为 进行中
- 指派给 从 林 万江 变更为 杨 杨乐
四信定位了一次，但采用的DU版本没有打开reestablish流程，所以msg4 就没有下发给UE。
需要DU提供新版本打开reestablish流程，然后再分析终端为什么没有响应msg4
由 匿名用户 更新于 超过 2 年 之前
DU打开re-establishment的版本已经用手机验证，手机上的信令查看软件能够收到re-establishment 消息，但是事件中仍然显示re-establish fail。
版本已经发给西安同事，需要找四信帮忙看看具体的问题是啥。
由 匿名用户 更新于 超过 2 年 之前
- 指派给 从 杨 杨乐 变更为 匿名用户
- 问题归属 DU 已添加
根据四信的反馈和实测的结果，目前触发re-establishment的方式可能存在问题，衰减加得太多，RSRP降到比较低的情况，可能会导致当时的上下行接收本身就是错误的。
考虑从DU侧增加测试参数，触发Re-establishment。
按照产品例会讨论的结论执行：CU版本触发reestablish发生，复现终端没有响应的现象，找四信进一步定位分析。
DU触发reestablish，当前有msg4的反馈有问题
由 匿名用户 更新于 超过 2 年 之前
目前状态：
手机每次都能够收到reestablishment消息，并回复UCI ACK，但是手机侧会经过几百毫秒后，分析应该是timer T301超时重建立失败。
可能的原因：
1.msg5的调度PDCCH解不对；2.reestablishment消息内容有问题，完保或是加密校验无法通过；
调测：
1.针对原因1，修改了不同的msg5调度，（USS，CSS type0，CSS type1等），但手机的信令还是和上一条一致；
2.针对原因2，仔细阅读了331协议和咨询CU同事，确认手机会采用之前配置的完保和加密参数进行校验。
用公网sim卡查看了移动的完保和加密配置，和我们的配置稍有差别，移动的配置是 NEA2，NIA2；我们配置是NEA0, NIA2。
因为对加密协议不熟悉，不太清楚这个区别是否影响重建立消息的校验。
由 匿名用户 更新于 超过 2 年 之前
huang xiwen 写到：
正在进行抓数，请终端厂商四信帮忙分析。
因为之前的流程处理有问题，UE在msg3(CRNTI MAC CE)之后无法进行下一步的流程，并且从重建立的过程来看，
UE在发起重建立之前会优先发送CRNTI MAC CE尝试重新进行上行同步，所以在四信帮忙分析重建立响应的同时，
DU同步进行CRNTI MAC CE相关的流程开发和debug。
由 匿名用户 更新于 超过 2 年 之前
目前状态：
1.四信回复是 re-establishment消息，完整性保护失败，导致终端没有回复re-establishment complete消息；
2.CU/DU已经修改了UE CONTEXT MODIFICATION REQUIRED消息流程，待测试。
由 匿名用户 更新于 超过 2 年 之前
huang xiwen 写到：
目前状态：
1.四信回复是 re-establishment消息，完整性保护失败，导致终端没有回复re-establishment complete消息；
2.CU/DU已经修改了UE CONTEXT MODIFICATION REQUIRED消息流程，待测试。
CU/DU已经完成CRNTI MAC CE相关的流程，从打桩触发的方式测试看，UE能够通过发送CRNTI MAC CE，重新接入，并继续下行灌包。
重建立任务遗留：
1.重建立消息完保失败，仍在定位问题。
由 匿名用户 更新于 大约一年 之前
- 关联到 错误 #1452: 重建立测试，终端组包了reestablishment complete，未发送 已添加
导出 Atom
PDF