SMF支持专载的延迟释放

本例为10秒钟。

当专载建立后，如果收到了基站过来的N2释放请求，

正常情况下，专载对应的用户面连接会被去激活。

当启动了这个计时器之后，有两种情况：

- 如果10秒内，UE发起了业务请求流程，则停止计时。专载也不会删。

- 如果10秒内没有任何动静，则专载释放，也就是所谓的延迟删除。

测试步骤：

1）UE发起PDU会话建立流程，并且建立成功。

2）网络侧发起一个GBR的Qos流建立，并且建立成功。如下图：

其中，#5319到5499是PDU会话建立过程。

#5580到#5583是GBR的Qos流建立过程。建立成功。

在PDUSessionResourceModifyResponse消息里，基站回复了建立成功的Qos流的信息。

3）在基站侧通过机关触发一个N2释放流程，cause值是#21 radio-connection-with-ue-lost。

4）AMF调用SMF的pdu会话服务，服务操作是modify，即对一个已经建立的pdu会话进行参数修改。

改什么呢？就是要求SMF把用户面资源释放。也就是第#6380号包。ngapcause的取值与#6369相同，为

21。

5）此时SMF侧的专载延迟释放计时器10秒开始启动。

6）SMF找UPF做N4会话修改，更新FAR（update FAR参数）。

- 如果没有这个延迟释放计时器，则SMF应发起N4会话修改流程，要求UPF去激活该专载的用户面资源。

- 如果有这个计时器且启动，SMF也会发起N4会话修改流程，但改为要求UPF缓存该专载的下行数据。

即BUFF和NOCP标记位置1。

7）因此专载被暂时保持住了。

后面的流程也说一下：

- 如果10秒内，UE发起了业务请求流程，则停止计时。专载也不会删。

- 如果10秒内没有任何动静，则专载释放，也就是所谓的延迟删除。