《5GC实践篇》之SMF篇（2）对移动性管理的支持

2.2.3 对网络侧发起的业务请求流程的支持 230

2.2.4 对Xn切换流程的支持 234

2.2.5 对N2切换流程的支持（不插入I-UPF场景） 237

正文开始

2.2 对移动性管理的支持

虽然SMF不负责移动性管理，但在很多移动性管理流程中，有很多会话管理的任务，这是需要SMF所支持的。

2.2.1 对去注册流程的支持

一 概述

完整的去注册流程在规范23502的4.2.2.3.2节介绍，在《原理篇》的UE发起的去注册流程节也有详细介绍。

这里不再赘述。

二 检查点

主要检查在去注册流程中，当SMF收到AMF发过来的Nsmf_PDUSession_ReleaseSMContext请求后，需要检查对应

的PDU会话是否存在，并释放相关的资源。具体来说，SMF需要做以下几步：

1）向UPF发起N4会话释放流程；

2）向UDM发起去订阅；

3）向UDM发起去注册登记；

4）【如果存在的话】，向PCF发起SM上下文的释放。

也就是检查下图规范流程中标红色的几个步骤（3a/3b、5a、5b、5c），SMF是否发起和执行。

三 消息举例

检查点1：检查SMF是否向UPF发送了N4会话释放请求消息。

检查点2：检查SMF是否向UDM发起了去订阅请求，不再订阅该UE的sm-data。去订阅采用DELETE方法，requesturi=/nudm-sdm/v1/imsi-460660000066666/sdm-subscriptions/imsi-460660000066666。

UDM收到后取消关于该UE的sm-data订阅，并返回204 no content。

检查点3：检查SMF是否向UDM发起了去注册请求，将自己再UDM中为该UE的注册登记信息删除。去注册采用DELTE

方法，request-uri=/nudm-uecm/v1/imsi-460660000066666/registrations/smf-registrations/666。其中，imsi460660000066666为UE的IMSI，最后那个666是订阅ID（subscription ID）。

UDM收到后删除该UE的服务SMF注册登记信息，并返回204响应。

2.2.2 对UE发起的业务请求流程的支持

一 概述

完整的UE发起的业务请求流程在规范23502的4.2.3.2节介绍，在《原理篇》的3.3.2 UE 发起的业务请求流程一节也有

详细介绍。这里不再赘述。

二 检查点

主要检查SMF是否支持“UE发起的业务请求流程”中的相应工作，也就是下图中标红色的步骤。

主要检查项：

第5a步：如果部署了PCC，SMF应向PCF发起策略更新流程，PCF提供更新后的策略。（例如AMF告诉SMF，UE的

位置发生了改变，从闲小区到了忙小区，PCF可提供更新后的忙小区策略。）

第5b步：是SMF内部步骤。SMF应根据从AMF收到的UE的位置信息，决定是否继续使用现有的UPF，还是需要重新选

择一个新的I-UPF插入。（例如跨省场景，当前UPF已经无法为UE服务，则需要插入一个新的I-UPF。）

第6a/6b步：如果不需要插入新I-UPF，SMF通知UPF（PSA）进行N4会话更新，要求UPF（PSA）激活N9隧道。

第6c/6d步：如果需要插入I-UPF，则SMF与I-UPF建立N4会话，并下发规则，同样也是要求I-UPF建立N3和N9的隧

道，并分配相关资源。

第7a/7b步：如果插入了I-UPF，SMF还需要向UPF（PSA）发送N4会话更新，将I-UPF的用户面信息告诉原UPF。这

样下行数据将从PSA发现新的I-UPF。

第8a/8b步：如果SMF需要移除Old I-UPF，则给Old I-UPF发送N4会话更新，引导Old I-UPF将缓存的下行数据发送。

第9和10步二选一：如果有新的I-UPF插入，则Old I-UPF将缓存的下行数据发给新的I-UPF，但如果没有新的I-UPF而

只是将Old I-UPF移除了，则Old-UPF将缓存的下行数据发给PSA。

第11步：SMF给AMF回Nsmf_PDUSession_UpdateSMContext响应，包含给gNB的N2 SM消息（PDU会话ID、QFI、

Qos配置、N3隧道信息、S-NSSAI等。）

第17a/17b和18a/18b步二选一：如果有新的I-UPF，则将新的I-UPF发送N4会话更新，如果没有新的I-UPF，则向PSA

发送N4会话更新，更新的内容都是gNB侧的N3隧道信息。这样接下来的下行数据就可以发给gNB了。用户面就基本打

通了。

第20a/20b步（条件）：如果已经为新的I-UPF建立了隧道，且步骤8a的用于转发隧道的计时器超时，则SMF向作为N3

终结点的新I-UPF发N4会话更新，释放该转发隧道。

第21a/21b步（条件）：如果已经为UPF（PSA）建立了隧道，且步骤7b的用于转发隧道的计时器超时，则SMF向向作

为N3终结点的UPF（PSA）发N4会话更新，释放该转发隧道。

第22a/22b步（条件）：如果SMF在步骤5决定继续沿用old I-UPF，则向old I-UPF发送N4会话更新请求或者N4会话释

放请求。其中N4更新请求里提供了gNB侧的隧道信息，但如果SMF在5b选择了新的I-UPF，则SMF会给old I-UPF发N4

会话释放请求，并说明原因，为什么不要你了。

三 消息举例

看起来规范里的业务请求流程非常复杂，但规范是把所有的场景都放在一个图里说，并没有拆开，自然就复杂了。但

实际生活场景，上图中的很多网元是不参与的。例如如果UE就只是在某个城市内移动（比如从北京朝阳区去海淀区上

班），没有出这个AMF的服务区（这种场景更常见，毕竟一个用户一个月都不见得坐两次高铁），那上图中的New IUPF是不需要的，Old I-UPF也是不需要的（通常I-UPF只用于省间移动或MEC场景）。而且即便有，I-UPF和PSA在

初期应该也是合设的。那图中涉及New和Old I-UPF的步骤都没有了。这样用户面的路径就是UE--gNB--UPF（PSA）-DN就可以了。

来看一个实际报文，是没有I-UPF的场景。这样的话SMF其实只需要将gNB侧的N3用户面信息发给PSA就可以了，然

后PSA将下行数据发给gNB。

这个实际的报文对应上面规范图中的第18a步，SMF发给PSA的N4会话更新请求消息。

Packet Forwarding Control Protocol

Flags: 0x21, SEID (S)

Message Type: PFCP Session Modification Request

Length: 62

SEID: 0x7ca0000000000000

Sequence Number: 15666999

Spare: 0

Update FAR :

IE Type: Update FAR

IE Length: 46

FAR ID : Dynamic by CP 2

Apply Action :

IE Type: Apply Action

IE Length: 1

Flags: 0x02, FORW (Forward)

Update Forwarding Parameters :

IE Type: Update Forwarding Parameters

IE Length: 29

Network Instance : n3-vpn

IE Type: Network Instance

IE Length: 6

Network Instance: n3-vpn

Destination Interface : Access

IE Type: Destination Interface

IE Length: 1

0000 .... = Spare: 0

.... 0000 = Interface: Access

Outer Header Creation :

IE Type: Outer Header Creation

IE Length: 10

Outer Header Creation Description: GTP-U/UDP/IPv4

TEID: 0x5000ee66

IPv4 Address: 100.1.1.1

该N4更新请求消息主要更新了一个FAR，将gNB的用户面信息发给了PSA。主要参数解读：

- Message Type: 消息类型。本例为PFCP Session Modification Request；

-Update FAR：下发的规则。这里是更新了一个FAR，即包转发规则。

- Apply Action：告诉UPF需采取的行动，这里FORW位置1，即告诉UPF可以转发用户面数据。

- Destination Interface：取值为Access。即告诉UPF往下行的gNB方向转发。

- Network Instance：取值为n3-vpn。即告诉UPF，如果在UPF的下行方向有多个网络实例的话，则往n3-vpn这个网络

实例转发。UPF接下来查找n3-vpn网络实例的路由表，找到到gNB的下一跳（如一个PTN网关或路由器设备）转发下

行数据。

- Outer Header Creation：告诉UPF在转发下行数据时要加上一个外层包头。添加的外层包头是GTP-U/UDP/IPv4，并

且GTP-U的目的地址是100.1.1.1（gNB侧N3口用户面地址），并打上TEID=0x5000ee66（gNB分配的N3口的

TEID）。

2.2.3 对网络侧发起的业务请求流程的支持

一 概述

完整的去注册流程在规范23502的4.2.3.2节介绍，在《原理篇》的网络侧发起的业务请求流程一节也有详细介绍。这里

不再赘述。

二 检查点

主要检查SMF是否支持“网络侧发起的业务请求流程”中的相应工作，也就是下图中标红色的步骤。也就是步骤3a：当

SMF收到UPF过来的下行数据通知（步骤2a）时，需要给调用AMF的服务，请求AMF发起对UE的寻呼流程，从而重新

激活用户面的连接来接收下行数据。

【注：本流程由UPF收到了下行数据而触发，这里的下行数据包括下行的NAS信令消息、下行的用户面数据、NAS短

消息。其中以下行用户面数据（如微信消息）触发最为常见，则UPF需要给SMF发送Data Notification，即2a步骤。】

三 消息举例

本来想找一个实际报文，就是上图中的步骤3a的消息，SMF发给AMF的

Namf_Communication_N1N2MessageTransfer来看的。但怎么都没找到一个完整成功解码的报文。只找到一个半完整

的（就是ngapData部分没有解出来）。该消息调用的是AMF的Namf_Communication服务，采用POST方法，requesturi=/namf-comm/v1/ue-contexts/imsi-460660000006666/n1-n2-messages。

JSON数据部分如下：

如图所示，可以看到这个消息中包含了关联的PDU Session ID=5、S-NSSAI信息，但还有关键的smInfo->n2InfoContent（ngap消息类型=PDU_RES_SETUP_REQ），这个是没有解出来，里边还有东西的。

PDU_RES_SETUP_REQ的全称是PDU Session Resource Setup Request Transfer，在38413里定义。那这个没解出

来的消息里还有哪些参数呢？

让我们回到23502，看看规范里的步骤3a是怎么说的？规范原文是：“3a. [Conditional] SMF to AMF:

Namf_Communication_N1N2MessageTransfer (SUPI, PDU Session ID, N1 SM container (SM message), N2 SM

information (QFI(s), QoS profile(s), CN N3 Tunnel Info, S-NSSAI), Area of validity for N2 SM information, ARP,

Paging Policy Indicator, 5QI, N1N2TransferFailure Notification Target Address, Extended Buffering support), or NF to

AMF: Namf_Communication_N1N2MessageTransfer (SUPI,N1 message).”。可以看出，该消息中应该还有UPF侧N3

口的用户面隧道信息（GTP-U IP+TEID）、QFI、Qos Profile（5QI等Qos参数）。这些信息实际上就是包含在SMF通

过AMF透传给gNB的PDU Session Resource Setup Request Transfer消息里了。

那依据呢？不能想当然啊。那自然要查AMF的服务规范29518，在它的6.1.6.2.26节提到了对N2InfoContent参数内容的

定义，让我们去找TS38413的9.3.4节。

然后顺藤摸瓜，跳转到38413的9.3.4节：9.3.4 SMF Related IEs。这一节专门介绍SMF通过AMF透传给gNB的相关消

息及参数。其中9.3.4.1 PDU Session Resource Setup Request Transfer节就正好是我们上面实际报文截图中的NGAP

消息。所以答案就在这一节里了，只要看看 PDU Session Resource Setup Request Transfer里带哪些参数，那就是本

流程步骤3a里给AMF要带哪些参数了。

摘录该消息的部分参数如下：

可以看到和23502描述一致，有Qos、PDU会话类型、QFI以及UPF侧的用户面信息（图中的UL NG-U UP TNL

Information参数）。

2.2.4 对Xn切换流程的支持

一 概述

完整的Xn切换流程在规范23502的4.9.1.2.2节介绍，在《原理篇》的3.4.1 Xn切换流程一节也有详细介绍。这里不再赘

述。

二 检查点

主要检查SMF是否支持“Xn切换流程”中的相应工作，也就是下图中标红色的步骤。

也就是步骤3a：当SMF收到AMF的Nsmf_PDUSession_UpdateSMContext Request消息时，应给UPF发送N4会话修

改请求，里边包含了目标gNB的N3口用户面信息（GTP-U IP+TEID），引导UPF将下行数据发给目标gNB。当收到

UPF的响应后，能在第6步给AMF回正确的响应。

三 消息举例

来看一个实际报文，也就是上图的步骤3a：SMF发给UPF的N4会话修改请求消息。

该N4更新请求消息主要更新了一个FAR，将目标gNB的用户面信息发给PSA。主要参数：

- Message Type: 消息类型。本例为PFCP Session Modification Request；

-Update FAR：下发的规则。这里是更新了一个FAR，即包转发规则。FAR ID=2。

- Apply Action：告诉UPF需采取的行动，这里FORW位置1，即告诉UPF可以转发用户面数据。

- Destination Interface：取值为Access。即告诉UPF往下行的gNB方向转发。

- Network Instance：取值为n3-vpn。即告诉UPF，如果在UPF的下行方向有多个网络实例的话，则往n3-vpn这个网络

实例转发。UPF接下来查找n3-vpn网络实例的路由表，找到去gNB的下一跳（如一个PTN网关或路由器设备）转发下

行数据。

- Outer Header Creation：告诉UPF在转发下行数据时要加上一个外层包头。添加的外层包头是GTP-U/UDP/IPv4，并

且GTP-U的目的地址是100.1.1.1（gNB侧N3口用户面地址），并打上TEID=0x50000025（目标gNB分配的N3口的

TEID）。

2.2.5 对N2切换流程的支持（不插入I-UPF场景）

一 概述

完整的N2切换流程在规范23502的4.9.1.3节介绍，在《原理篇》的3.4.2 N2切换流程一节也有详细介绍。这里不再赘

述。

二 检查点

主要检查SMF是否支持“N2切换流程”中的相应工作，N2切换在规范里包括准备阶段和执行（完成）阶段两张图，SMF

都需要支持其中的相关步骤，也就是下图中标红色的步骤。

【注意：本场景中，在规范里是把所有的场景画在一张图里，实际上不同场景是不可能同时出现的。需要拆分来看。

本例的场景是UPF不变（也就是SMF决定不插入I-UPF的场景，生活中大多数场景都是这种。），而且S-UPF和PSA合

设的场景。也和现阶段商用网络基本一致。这样就没有第5步UPF的选择，也没有第6a/6b/6c/6d、11b/11c/11d/11e

步，因为这些步骤都和I-UPF的插入有关。

但还需要注意，如果源gNB和目标gNB不支持用户面GTP-U数据的直接转发，则还需要11d和11e步，SMF要求UPF分

配非直接转发的用户面隧道信息。这样后续执行阶段的下行数据非直接转发路径为：UPF（PSA）-->源gNB->UPF(PSA)-->目标gNB，然后目标gNB进行缓存和报文重组排序等工作，然后等待UE接入目标小区后，将缓存中的下

行数据发给UE。】

2.1）准备阶段中SMF的支持

主要检查项：

第7步：SMF给AMF回Nsmf_PDUSession_UpdateSMContext响应消息，里边包含了UPF(PSA)侧N3口的用户面信息

（GTP-U IP+TEID），这一步的参数在规范里叫UL CN Tunnel ID of the UPF。然后通过AMF透传给目标gNB，用于上

行数据的发送。

第11f：SMF给AMF回Nsmf_PDUSession_UpdateSMContext响应消息，里边包含了的是用于下行数据转发的用户面信

息，这一步的参数在规范里叫DL CN Tunnel ID。具体带什么取决于gNB之间是否支持直接转发：

- 如果支持直接转发：则这个参数里携带的是目标gNB的用户面隧道信息；

- 如果不支持直接转发：则这个参数里携带的是UPF（PSA）侧的用户面隧道信息；

最后，这个DL CN Tunnel ID参数通过AMF透传给源gNB，用于执行阶段下行数据的发送。

直接转发的路径为：源gNB-->目标gNB

非直接转发路径为：源gNB-->UPF(PSA)-->目标gNB

最后由目标gNB进行缓存和报文重组排序等工作，然后等待UE接入目标小区后，将缓存中的下行数据发给UE。

2.2）执行阶段中SMF的支持

主要检查项：

第10a步：SMF给UPF（PSA）发N4会话更新请求，主要参数是目标gNB侧N3口隧道信息（规范原文叫N3 AN Tunnel

Info of T-RAN）。【注：如果有I-UPF插入的话，这里提供的是I-UPF也就是图中T-UPF的隧道信息。】这样，接下来

的下行数据由PSA直接发给目标gNB（如果有I-UPF插入的话，就发给I-UPF。）

第11步：SMF给AMF回Nsmf_PDUSession_UpdateSMContext响应消息，里边包含了PDU Session ID。这也是SMF

侧对切换完成的确认。

三 消息举例

来看几个实际报文，和前面的流程图步骤是对应的。

3.1）准备阶段的第7步，SMF给AMF回的第一个Nsmf_PDUSession_UpdateSMContext响应消息，这是一个HTTP

200 OK消息。JSON数据部分如下：

可以看到，hoState=PREPARING，代表是在准备中。并携带了一个给gNB的NGAP消息：PDU Resource Setup

Request。将这个NGAP消息点开，得到下图：

可以看到，该参数携带了UPF侧用于接收上行数据的GTP隧道信息（注意看图，写的是UL代表上行），本例为

10.1.1.1和TEID（0a00004），PDU会话类型是ipv4，以及需要建立的Qos流列表（QFI=5）以及所需的Qos

（5QI=5，ARP）。

3.2）准备阶段的第11f步，SMF给AMF回的第二个Nsmf_PDUSession_UpdateSMContext响应消息，这是一个HTTP

200 OK消息。JSON数据部分如下：

可以看到，hoState=PREPARED，代表是过去时态，准备完成了。并携带了一个给gNB的NGAP消息：

HANDOVER_CMD（全名是Handover Command Transfer）。

将这个NGAP消息点开，得到下图：

可以看到，该参数携带了非直接转发场景下UPF侧用于接收下行数据的GTP隧道信息（注意看图，写的是DL代表下

行），本例为10.1.1.2和TEID（50006666），以及需要转发的Qos流列表（QFI=5）。这样源gNB收到下行数据后，

一看如果是QFI=5的Qos流的数据，就会又转给UPF。

3.3）执行阶段的第11步，SMF给AMF回的第三个Nsmf_PDUSession_UpdateSMContext响应消息，这还一个HTTP

200 OK消息。JSON数据部分如下：

可以看到，hoState=COMPLETED，代表SMF侧认为切换已经完成了。没有N2消息和别的参数了。这就够了。