IMS PDN retry测试用例

 

[转载连接]:

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过程日志如下：