一个高难度的log分析：EPSFB通话结束后重定向回5G

但为了提升5G利用率，很多UE支持EPS FB结束后（也就是通话结束后），

重新返回5G的方式。这其中又以重定向方式返回5G最为常见。

本文就是讲的EPSFB通话结束后怎么重定向返回5G。

直接上log截图：

【可以把这个截图死记硬背背下来，

以后如果log长这样，那就是EPSFB结束重定向回5G，无疑！！！！】

这个图里有一些重要的步骤，分析一下。

1）EPS Fallback回落的过程：

- 是图上的#2381到#2394。其中#2381是AMF透传SMF的请求给gNB，要求gNB为音频Qos流建5G专

载，但在#2383被gNB拒绝，原因值ims-voice-eps-fallback-or-rat-fallback-triggered。如下图：

2）非常重要的时间戳观察：

- 第41秒完成了EPS FB。然后是62秒的#6196号包重定向回到了5G。中间间隔了21秒。

这21秒应该是用户讲电话的持续时间。如果抓SIP信令的话，应该有一个BYE的挂机消息能抓到。

3）EPSFB通话结束后重定向回5G的过程：

- 从62秒的#6196号包开始，到最后#6360，UE发注册完成结束。UE正式回到了5G。

4）最重要的一个包就是#6196号的注册请求。

- 这是一个俄罗斯套娃5连套！！！

无语了！！！

第1层：N2消息InitialUEMessage

第2层：套了个5G-NAS消息：Registration request

第3层：5G-NAS又套了个4G-NAS消息：TAU Request

第4层：4G-NAS又套了个5G-NAS消息：Registration request

第5层：5G-NAS又套了个4G-NAS消息：TAU Request

等等，如果您认为是这样套的，那就不对了。

上述套法是根据wireshark的消息汇总截图（上面那两张图）来推断的。

但其实不是，如果把消息展开看详细截图的话，实际上只有4层，4连套。

如图所示。

我其实也是第一次见到这样的实际log，

咱们星友一起开开眼界。汗。

先看个全局的截图#6196。

第3层的4G TAU请求如下：

第3层的5G注册请求如下：

- UE status可以看出UE侧的5G注册状态为求注册态，4G注册状态为注册态。

说明是从4G重定向过来的。如果是5到4切换过来的，没有UE status这个参数。

- 同时还包含了4G侧的TAU请求，放在EPS NAS message container。

第4层的4G-NAS消息TAU请求如下：