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網絡。