研发产品测试 » 2.0基站产品化测试

1、流程中以ue_conn_pdu_session中有几个qos_flow来决定创建几个drb，视频电话时，需要根据qfi=1,qfi=2创建两个drb，分别将qfi1和2映射在这两个drb上，但当qfi=1所映射的drb的相关资源创建完成后，开始创建qfi=2要映射的drb的相关资源时，因为代码框架之前没有对qos_flow的状态标识，所以此时再一次针对qos flow 1创建了一个drb来映射，也就是说与正常业务相比，现在会多创建一个drb，将qfi=1的flow，在两个drb上都映射了一次，这是根本原因；
2、而当映射了qos flow为2的drb继续创建后续资源时，因为创建pdcp实体的消息中的上行线程实例id不对导致流程中断，所以从报文来看通知du和ue的消息中所包含的只有qos_flow为1的相关内容，而没有qos_flow为2的内容，导致ue不断的发nas消息通知核心网下发PDUSessionResourceModifyRequest消息；

打一次电话有声音和图像，视频通话正常，但第二次不行，测试了两次，有一次导致du和phy挂死，需要分析是那一层的问题

不下发重配置是cu侧idx映射错误的一个bug,已经可以下发重配置；
但因为时序性问题，下发的重配置中的drb的信息和LogicalChannelIdentity并不匹配，导致释放流程后续还是有问题，目前和林总讨论之后，确定了修改方案，正在写代码

已经可以多次打视频电话，自测打了三次视频电话后，du和phy挂掉，cu做初步分析的话，从报文和日志来看一切都是正常的，需要du帮忙看一下原因

提供了环境，配合du做了gdb调试，习文哥分析原因应该是一次有两个GBR的逻辑信道，建立释放导致LCG的管理出了问题

du已经提供新的版本，目前自测不存在挂死问题

视频通话，DRB承载的创建或者释放流程中，内部驱动流程trans_id和协议中的混用，协议中规定，trans上限为4个，但对于目前的内部流程来说因为时序性原因，trans4个是不够用的，在需要超过4个时，会释放掉所有，重新分配，此时，有些内部流程还没走完，导致流程中断，错误退出，从而触发超时，释放上下文

之前是trans有泄露，修改完问题后，mate30给vivo打了5次没有问题，但vivo给mate30打了一次，出现终端掉线，需要分析，不过能确认不是trans的问题

现在以mate30做主叫可以多次打，但以vivo做主叫的话可以接通，但接通之后时间大概有个1s就会卡死，原因还得分析

和核心网侧的人沟通过，从核心网侧也无法看出在通话过程中终端再次发sip信令invite的原因，所以我这边继续从cu侧分析一下

之前从cu日志看，与vonr相关的用户面下行数据都是由qfi=5来承载的，所以我怀疑是数据处理不过来导致卡了，后来沟通了核心网，将语音用qfi=1,视频用qfi=2来承载，但依然没有解决问题还是一样的现象，问题需要重新分析

通过对比mate30和mate30pro两个手机的对打情况来看，比vivo做主叫的情况要好，但还是有视频卡死的情况出现，vivo做主叫是第一次就视频卡死，但mate30pro做主叫不会在第一次有这种情况，但mate30pro的卡死随机，没有在第一次卡死过，而且mate30pro做主叫，正常或者卡死，上个描述中update信令中与视频编解码的相关字段都支持了，所以通过自测来看，视频接通后卡死的情况应该和上述字段没有关系，是其他原因导致还需要分析

在自测过程中发现一个问题：对于视频通话的流程，在结束通话时cu侧在接收到来自核心网的两条PDUSessionResourceModifyRequest后，cu侧分别释放qfi=1和qfi=2所映射的drb,cu侧收到此信令就会create一个trans,同时此trans的类型为UE_TRANS_PDU_SESSION_RESOURCE_MODIFY_EST，但有时候会因为时序性的问题在通过trans类型来得到trans_id时，两个流程会取到同一个trans_id，造成的结果就是，有一个流程在前，走完后就释放了trans,导致第二个流程走到此处时因找不到trans_id而触发了超时，释放了上下文，对于这个问题，已完成了代码的修改，但此问题和视频接通后卡死的问题无关

对于视频通话接通后卡死的问题，结合报文和现象来看可能和时序性有关，正在确认相关报文中，正常和不正常的时延，看是否是这个原因

复现了视频通话卡顿的情况，抓了基站和核心网的同步包，和红超哥进行了沟通分析，目前视频通话的问题归结为两个场景：
现在是两个场景：
1、有画面有声音，但是卡，这种情况能正常挂断，不影响下次打电话，cu先复现对比一下lo口和cu与核心网侧的速率，看是否一致,先看是不是cu侧用户面上行数据处理有问题
2、ims再一次触发了PDUSessionResourceModifyRequest,这种情况，会影响挂断，影响下次通话，原因不明确，有关于通道的怀疑，cu排查通道的建立,核心网侧也会帮忙分析

有一个怀疑的点，sdap实体中对于缺省drb每次打电话都会更新，导致每次的 end maker信令处理失败，目前在打电话时不再更新缺省drb代码已经修改完成，未自测

上次的修改有问题会影响打电话，后续确认了一个问题，通过日志来看额外用到缺省drb的地方只有处理核心网下发的 end maker消息，是在快速恢复后会有end maker消息的下发，目前来看cu侧一直是处理失败的，所以其实这样来看，缺省drb被替换不是视频卡顿的根本原因；
另一处修改是对于上行的用户面数据，之前cu给核心网发每一帧数据都不带头，核心网侧收到这帧数据会按照缺省流来处理，即打视频通话时，语音数据、视频数据都通过qfi=5来处理，怀疑视频卡顿是这个导致的，后来在cu侧给它加了头，语音数据用qfi=1处理，视频数据用qfi=2来处理，但这样也没有解决卡顿的问题

对于视频卡顿的问题，通过报文分析用户面数据，有如下结论：
视频卡顿的一次，一个终端通过qfi=1和qfi=2将语音数据和视频传输到核心网，但核心网下发语音和视频数据给另一个终端的时候却是通过qfi=5，我这边为了方便对比，将平时的语音和视频都抓了any包，通过分析来看：
1、语音处理核心网收到和下发是同一个qos_flow；
2、不卡顿的一次视频通话，核心网收发也是用一个qos_flow；
3、卡顿的一次核心网收发就不一致了
和红超哥也沟通了已经确认是核心网的bug,等核心网修改完bug再测试看看

核心网侧的bug已经修改完成，但卡顿的问题依然存在

卡顿的问题在新单跟踪

卡顿问题在1367跟踪