项目

一般

简介

需求CR #1943

当基站存在旧的gnb_cu时，重启新的cu时优化提示信息或者流程

由 王 松 在 10 个月 之前添加. 更新于 6 个月 之前.

状态:
挂起
优先级:
普通
指派给:
李 玮璇
开始日期:
2024-07-11
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
CU
目标解决问题版本:
Rel_2.1.6
CPU类型:

描述

测试环境：
基站：分体式基站
版本：Rel_2.1.14P_Pre2T4

问题描述：
现场配置为手动启动三层，在操作过程中将起三层的笔记本网线拔掉了，在将网线插上之后重启三层，发现无法启动成功，在CU上打印如下信息：
STARTING GNB CONFIGURATION
---------------------------------------------------------
[INF]: Scheduled changes not applied because of other existing connections.
[INF]: Connection 38 created.
[INF]: Session 15989 (user "root", CID 38) created.

========== LISTENING FOR NOTIFICATIONS ==========

SCTP F1AP Init: IP=192.168.2.177 PORT=38472
[10/07/2024 11:12:38.961396][SCTP][ERR][ngp_sctp.cpp:271]SCTP Server Bind Failure for FD : 17

问题分析：
通过打印可以看出是F1口的连接建立失败，结合前面是手动起三层，网线拔掉之后，怀疑是否存在服务没有杀死的情况，因此在基站上输入ps -a 进行查看，存在两个gub_cu
root@yzrt:~# ps -a
PID TTY TIME CMD
20678 pts/14 00:00:00 ps
112071 pts/10 00:00:00 run.sh
112264 pts/10 00:02:43 gnb_cu
208849 pts/8 00:00:00 run.sh
208963 pts/12 00:00:00 run.sh
209063 pts/13 00:00:00 run.sh
209073 pts/13 00:28:44 gnb_du
209142 pts/12 00:01:12 gnb_cu
209164 pts/8 00:00:00 flock
209166 pts/8 00:00:00 dev_om.sh
209169 pts/8 00:00:00 dev_om
209263 pts/8 00:03:11 l1app

这样就导致了服务的冲突，三层无法启动，跟研发沟通之后，可以进行优化，建议如下：
1、存在就的cu服务时，重启cu增加提示信息
2、也可以考虑将旧的cu服务杀掉

具体见附件：

文件

CU无法启动优化需求.docx (191 KB) CU无法启动优化需求.docx 王 松, 2024-07-11 09:48

历史记录

#1

由 李 玮璇 更新于 10 个月 之前

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

根据探讨准备优化如下：
1、cu启动时，发现要是已有gnb_cu，退出，并给出界面日志打印
2、排查代码中关于影响正常功能的启动流程（比如绑端口失败、读取关键配置失败等），当失败的时候直接退出，而不是流程卡住

#2

由 李 玮璇 更新于 7 个月 之前

  • 状态 从 进行中 变更为 挂起

后续优化

#3

由 李 玮璇 更新于 6 个月 之前

第一点已修改，第二点后续排查修改

导出 Atom PDF