MCPTT（Mission Critical Push-to-Talk）客户端的日志，和界面在待机状态下（即没有做通话等业务操作），会频繁提示“离线”。

主要先看有没有丢网，UL BLER有没有问题。确认没有问题。看到业务信道释放后也可以成功重新建链。所以以为这个只是终端业务进入dormant态的提示问题而已。

但是radio log的data_call状态可以看到异常，可以看到有多次SETUP_DATA_CALL出现，每次建立DATA_CALL后，终端都会从ACTIVE进入DORMANT，然后进入INACITVE，然后DATA_CALL_LIST为空。


QMI LOG中，通过data_call_status,call_end_reason,connection_status来确认状态。都是SERVICE_WDS QMI服务上报的。

终端RRC释放后，重建链路，发现网络已释放PDU

终端发送Service request：

当终端从idle态重新建链路时，发送的Service request消息中携带如下字段：
Uplink_data_status:
PSI[1]为1，代表终端UE在PSI[1]上有数据待传输，并且对应的PDU状态为ACITVIE.

pdu_session_status：
PSI[1]为1，代表终端UE在PSI[1]上对应的PDU状态是ACTIVE。

虽然高通代码办公开，但是查找开源软件UERANSIM的代码：
service.cpp中，
NasMm::sendServiceRequest：
service_type=data:

uplink_data_status的PSI字段对应bit位，在EPSstatue的状态位ACTIVE并且有数据上行数据待传输时置为1.

从上面可以看出 UE发送的pduSessionStatus对应PSI位置1，即代表在UE侧的PDU状态，即EPSstate状态为ACTIVE

网络回复的Service accept消息

网络回复的Service accept消息中：
pdu_session_status:
PSI[1]为0，代表网络侧PSI[1]对应的PDU状态为INACTIVE.
pdu_session_react_result:
PSI[1]为1，代表Uplink_data_status中请求的PSI[1]对应的PDU状态在网络侧没有建立

这是时掉线问题出现的原因。终端已经存在PSI【1】的pdu，但是网络回复的对应PDU状态为INACTIVE. 所以终端只好删除本机保存的PDU上下稳。进而后面重新申请建立PDU.

终端因为网络释放PDU而重新发送PDU请求

如下图红框部分，网络发送的service accept触发终端重发pdu请求。

参考文档3GPP TS34.501：

解决方案

终端侧行为符合标准。
核心网侧行为异常，核心网修改配置后解决。

开飞行时，网络拒绝释放PDU

The EPS bearer identity is used to identify a message flow. 所以pdu_session_id2并不是 5G中一般意义的pdu_session。

用中国移动卡测试：
建立IMS时，pdu_session_id2 = 1

网络回复pdu session establishment accept后：pdu_session_id2 = 1 也是1.

紧接着cmnet建立pdu，pdu_session_id2 =2

其他

如何确认一直没有丢网

modemlog确认

如果一直没有丢网NAS层服务状态没有变化，所以不会打印ON SERVICE或NO SERVICE变化。
可以通过sd的log，看sd的event， 如果event没有丢网event，基本终端没有掉网。
1101才是丢网，从这里看终端没有丢网。

AP radiolog确认

用< DATA_REGISTRATION_STATE.*PHONE0过滤：
过滤出来日志都是驻网状态

背景知识

MCPTT（Mission Critical Push-to-Talk）标准由3GPP（第三代合作伙伴计划）制定，旨在提供关键任务的一键通话服务，主要面向公共安全和应急响应领域。使用基于IMS域的实现方案。
MCPTT服务器通过N5 N6口连接5GS核心网。MCC客户端通过接入网专用DNN接入MCPTT网络。