[轉載連接]:
https://mp.weixin.qq.com/s?__biz=MzU5NjA0OTUzNg==&mid=2247484833&idx=1&sn=2217fbcae8be983ab66efae4c7b74f33&scene=19
UT主動觸發未期望的detach來破壞測試用例。下面就是整個事件的回放示意圖，可以看見Modem組其實是被動躺槍的，問題出現在Network Tool組負責的加密DNS查詢長期沒有得到響應，觸發了安卓原生的AOSP數據恢復機制，導致ATel發送tear down Internet APN給Modem，從而detach請求到測試儀表側。
知識點1：AOSP Data Stall and Recovery機制；
知識點2：DNS with TLS；
知識點3：PDN retry過程；
1. AOSP Data Stall and Recovery機制
為了抵御網絡故障引起的數據業務不可用，Google在安卓Telephony Framework層加了一套檢測數據Stall和應對恢復機制。
用於檢測數據是否Stall的關鍵就是mSentSinceLastRecv，代表上次成功接收到響應后的TCP發包數。( 注：如果為私有APN，會統計UDP+TCP發包數 ）
由下面邏輯可以看出只要當RX>0時（收到對端響應）,mSentSinceLastRecv都會被重置為0. 只有當RX=0時，mSentSinceLastRecv會累加發包數。
僅當mSentSinceLastRecv累加的發包數已經超過NUMBER_SENT_PACKETS_OF_HANG常量規定的門限閾值，判定DUT數據業務已掛，啟動恢復機制。
默認這個門限為10個TCP包未得到響應（TCP ACK or NAK or RST），可根據具體需求具體定制，如下：
數據恢復機制采用了幾步走策略，每一步均比前一步殺傷力更大，對用戶感知影響也更為明顯，但同時保證數據業務也可以更大可能性地恢復。先開始會去激活再重新激活Internet APN，若數據業務仍不可用，則采用turn off radio再turn on radio方式，類似開關了飛行模式一次。
更多細節，請閱讀https://android.googlesource.com/的源文件
/frameworks/opt/telephony/src/java/com/android/internal/telephony/dataconnection/DcTracker.java or DcTrackerBase.java.
此過程對應ADB Radio日志如下：
D/QtiDCT ( 2221): [0]Data stall alarm
D/QtiDCT ( 2221): [0]updateDataStallInfo: OUT sent=5 mSentSinceLastRecv=10
//直接采用最終大招， reset radio
D/QtiDCT ( 2221): [0]onDataStallAlarm: tag=18025 do recovery action=3
D/QtiDCT ( 2221): [0]restarting radio
D/QtiDCT ( 2221): [0]restartRadio: *******TURN OFF RADIO**************
//因為要reset radio，所以ROM發了tear down internet APN
D/RILJ ( 2221): [0295]> DEACTIVATE_DATA_CALL cid = 0 reason = 2 [SUB0]
D/QtiDCT ( 2221): [0]cleanUpAllConnections: tearDown=true reason=radioTurnedOff
D/SST ( 2221): [0] Wait upto 30s for data to disconnect, then turn off radio.
2. DNS over TLS
從Modem日志提取出Modem TCP/IP棧的IP包可以發現出現問題時，DUT有大量發送到TCP端口853的TCP握手SYN請求，均未收到對端ACK。因此觸發了上面講過的AOSP Data Stall and Recovery機制.
查詢IANA的well-known service name and port表，如下：
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=15
可知TCP公用端口853用於RFC7858引入的采用TLS加密的DNS查詢
如果DNS服務器不支持DNS over TLS功能，會選擇通過TCP RST來拒絕TCP連接,或者干脆置之不理，等待TCP連接超時客戶端重新發送TCP SYN等。
需要強調地是DNS over TLS功能是從安卓9.0（Android Pie)開始支持。
如果你手中已有Anroid Pie系統的手機，請進入Settings → Network & internet → Advanced → Private DNS，如下圖所示：
如果選為Off, 相當於還是選擇DNS查詢采用明文的方式，依舊會往53端口的DNS服務器發送DNS查詢。
如果選為Automatic，會同時往DNS服務器的53 UDP端口發送DNS查詢請求和853 TCP端口發送TLS握手SYN包。只有當TLS握手完成，再繼續發送加密的DNS查詢請求。
3. PDN retry
從3GPP官方spec上，PDN是否retry需要綜合考慮以下多種因素
1）.是standalone PDN連接請求還是piggyback到EMM信令Attach request上的PDN連接請求？
2）.網絡回復的PDN CONNECTIVITY REJECT的ESM cause是什么?
3). 網絡回復的PDN CONNECTIVITY REJECT信令里包含代表T3396的Back-off timer IE和re_attemp_ind IE了么？如果帶了，值為多少？
詳情請查閱3GPP TS24.301
6.5.1.4.2 Handling of network rejection due to ESM cause #26
6.5.1.4.3 Handling of network rejection due to ESM cause other than ESM cause #26
DUT發送standalone PDN連接請求后，儀表側模擬網拒絕且回復的是ESM cause = 31( request rejected, unspecified ),不帶T3396 back-off timer。
這種Scenario下，協議上只是留有一句話，說白了就是白說，完全真空地帶。the UE behaviour regarding the start of a back-off timer is unspecified. 因此各運營商自行定奪是否在這種情形下retry，例如本例中軟銀要求PDN retry，並且重試間隔時長依次增加，從5分鍾、10分鍾到30分鍾.
Q司針對這種運營商特殊的IMS PDN retry定制需求，並沒有在NAS ESM協議層或者Modem Data層而是放到了IMS模塊實現。例如第一次retry過程日志如下：
