《5GC实践篇》之SMF篇（3）对会话管理的支持

2.3.3 对PDU会话释放流程的支持 256

2.3.4 支持去激活用户面资源 258

正文开始

2.3 对会话管理的支持

2.3.1 对PDU会话建立流程的支持

一 概述

完整的PDU会话建立流程在规范23502的4.3.2.2节介绍，在《原理篇》的3.2.1节PDU会话建立流程一节也有详细介

绍。这里不再赘述。

二 检查点

主要检查SMF是否支持“PDU会话建立流程”中的相应工作，而在该流程中，SMF需支持以下主要功能。（按信令流程

的步骤排序）

1）查NRF完成UDM的选择。然后SMF需要支持从UDM获取UE的会话管理签约数据（sm-data），并且SMF还需要向

UDM订阅该签约数据。

2）如果部署了PCC，需要完成PCF的选择，并发起到PCF的会话建立。并接受PCF下发的规则（含Qos），来完成

PDU会话的建立。

3）完成UPF的选择，并和UPF建立N4会话，并下发相应的管控规则。

4）给UE发送PDU会话接受NAS消息，并通过调用AMF的服务，将NAS消息透传给UE。

5）SMF需要在UDM中注册登记，登记UE的SMF的ID，也就是告诉UDM，这个UE现在是由我在为它提供会话管理服

务。如果有人要找做会话管理相关的事件，你就让它来找我。

三 消息举例

来看几个实际报文，和前面的主要步骤是对应的。

1）UDM的选择：

- 包括Get请求和200 OK。其中，Get请求的request-uri部分为：

/nnrf-disc/v1/nf-instances?service-names=nudm-uecm&target-nf-type=UDM&requester-nf-type=SMF&requester-nfinstance-fqdn=smf666.51xuetongxin.com&requester-plmn={"mcc":"460", "mnc":"66"}&snssais={"sst":1,

"sd":"000001"}。可以看出找NRF查询的是UDM网元，并且该UDM需要支持nudm-uecm服务。然后还有请求的网元是

SMF，plmn-id、切片等信息。

- NRF返回的200 OK包含了UDM的详细信息。如下图：

2）SMF在UDM中注册登记：

- 请求采用PUT方法，PUT请求的request-uri部分为：/nudm-uecm/v1/imsi-460660000000666/registrations/smfregistrations/5。【5是PDU Session ID。】，JSON数据部分包括smfId、dnn等信息。如下图：

- UDM返回201 Created。表示登记创建成功。

3）从UDM获取sm-data：

- 包括Get请求和200 OK。其中，Get请求的request-uri部分为：/nudm-sdm/v1/imsi-460660000000666/sm-data?

dnn=xxnet&singleNssai={"sst":1, "sd":"000001"} 。从uri部分可以看出请求的是sm-data，并且携带的DNN和切片等信

息。

- UDM返回200 OK，在JSON数据中包含了UE的sm-data。如下图：

4）向UDM订阅该UE的sm-data：

- 包括POST请求和201响应。其中，Post请求的request-uri部分为：/nudm-sdm/v1/imsi-460660000000666/sdmsubscriptions。JSON数据部分包含了订阅的对象（monitored Resource uri=sm-data）和接收订阅通知的uri地址。如

下图：

- UDM返回201 created，表示订阅成功。

5）PCF的选择：

- 包括Get请求和200 OK。其中，Get请求的request-uri部分为：/nnrf-disc/v1/nf-instances?service-names=npcfsmpolicycontrol&target-nf-type=PCF&requester-nf-type=SMF&requester-nf-instancefqdn=smf666.51xuetongxin.com&requester-plmn={"mcc":"460","mnc":"66"}&snssais={"sst":1, "sd":"0]。可以看出请求

的是PCF网元，并且需要支持smpolicycontrol这个服务。

- NRF返回的200 OK包含了PCF的详细信息。如下图：

6）从PCF获取sm-policy：

- 包括Post请求和201响应。其中，Post请求的request-uri部分为：/npcf-smpolicycontrol/v1/sm-policies。可以看出请

求的是sm-policy，即会话管理策略。

- PCF返回201响应，里边包含了sm-policy（Session Rule。包括授权的Session-AMBR、授权的缺省Qos如5QI和ARP

等参数）。如下图：

7）选择UPF并和该UPF建立N4会话，并下发管控规则：

- UPF的选择是SMF在本地完成的，没有信令。选定后，SMF发起N4会话的建立，里边包含了PDR、QER、URR等规

则用于管控。如下图【Grouped IE是wireshark加上去的解说词，说明点开还有子参数，这里就没有展开了。关于N4的

规则单独再开文单独讨论。】：

- UPF回复PFCP Session Establishment Response，该消息中UPF侧分配了N3口的GTP-U地址和TEID。如下图所

示：

8）调用AMF的服务，请求AMF将N2消息透传给gNB（请求gNB分配用户面资源），将N1消息（PDU会话建立接受）

透传给UE。调用采用Post请求，AMF透传后返回200 OK。

- Post请求的request-uri部分是/namf-comm/v1/ue-contexts/imsi-460660000000666/n1-n2-messages。JSON数据部分

携带了需要透传的N1和N2消息，但没有完全解析出来，就不展开了。但从输出中，可以看到包含了一个N2消息和一个

N1消息。如下图：

9）发起N4会话修改，将gNB的N3口用户面信息发给UPF（用于下行数据发送）：

- SMF发给UPF的是PFCP Session Modification Request，该消息修改了FAR，里边包含了gNB侧的N3口用户面地址

和TEID。如下图所示：

输出中的10.1.1.4就是gNB侧的N3口地址。

2.3.2 对PDU会话修改流程的支持

一 概述

PDU会话修改流程在规范23502的4.3.3节介绍，可以是UE发起，也可以是网络侧（PCF、UDM等）发起。本例以较为

常见的PCF发起的PDU会话修改流程为例进行介绍，详细的信令流程在《原理篇》的3.2.2.4 节PDU会话修改流程一节

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

PCF发起的PDU会话修改流程其实也是VoNR呼叫流程中的一部分，由IMS的AF向PCF提需求，请求5GC网络为语音业

务提供保证。AF会告诉PCF所需要的带宽和需要保证的对象（如音频流）及对象的特征（如源目的IP、端口号等）。

PCF发起PDU会话修改流程到SMF，请求SMF建立相应的5G专载（Qos流）。这需要SMF的支持。

二 检查点

主要检查SMF是否支持“PDU会话修改流程”中的相应工作，而在该流程中，SMF需支持以下标红的主要步骤：

主要检查项：

第1b步：SMF能正确处理PCF发过来的请求，从请求消息中能提取出PCF下发的各种管控规则（如Qos参数）。

第2a和2b步：SMF能将PCF发送来的规则转换成N4规则，并下发给UPF。例如5G专载所需的Qos放在QER里下发给

UPF，5G专载业务描述信息放在PDR里下发给UPF。

第3b步：SMF能调用AMF的1Namf_Communication_N1N2MessageTransfer 服务操作，请求AMF透传N2消息给gNB

（请求gNB为5G专载分配资源）、透传N1的NAS消息给UE。

第8a/8a,12a/12b步：SMF能根据AMF发过来的请求，提取相应参数，转换成需要更新的N4口规则，发起N4会话修改

流程，要求UPF更新。例如要求UPF对新增加的Qos流执行开门（Gating）操作，即允许UPF在新的Qos流的上下行用

户面资源建立后转发该Qos流的流量。

第13步：无论5G专载建立与否，SMF应发起到PCF会话修改流程，将结果告知PCF侧。并且将一些实时的动态信息

（如UE的位置）告诉PCF，来辅助PCF制定后续的策略。

三 消息举例

关于本节的报文，没找着完整的。因此，只能请大家看其中一个报文，不好意思。但也是非常重要的一个，就是图中

的第3b步：SMF调用AMF的Namf_comm服务，请求AMF透传N2和N1消息。该请求消息采用Post方法，requesturi=/namf-comm/v1/ue-contexts/imsi-460660000000666/n1-n2-messages。需要透传的N1和N2消息放在JSON数据

里。如下图：

从图中可以看出，本图一共包含了1个N1的NAS消息和1个N2的NGAP消息。这可以从Content-Type的取值

（vnd.3gpp.5gnas和vnd.3gpp.ngap）看出来，具体的消息可以从Content-ID的取值看出来（PDU Session

Modification Command这个是发给UE的NAS消息、PDU Session Resource Modify Request是发给gNB的N2消息）。

将这两个消息点开，得到详细的参数。先点开NAS部分的，如下图：

可以看到有PDU Session ID、S-NSSAI等参数。另外，还有一些参数因为解码的原因，没有在图中显示出来，比如

QFI和授权的Qos等也会发给UE进行确认，并以此约束终端的行为。

再点开NGAP部分的，但很遗憾，可能是装的wireshark的版本不对，没有解出来，如下图：

只能通过查询23502的信令流程（提到了该步骤的主要参数）和29502的SMF服务规范和38413的NGAP规范，最终确

定这个N2消息里的主要参数包括：PDU Session ID、QFI、需要修改的Qos（如MFBR、GFBR等）。

2.3.3 对PDU会话释放流程的支持

一 概述

PDU会话释放流程在规范23502的4.3.4节介绍，可以是UE发起，也可以是网络侧（PCF、UDM等）发起。本例以较为

常见的UE发起的PDU会话释放流程为例进行介绍，详细的信令流程在《原理篇》的3.2.3.3 节PDU会话释放流程一节

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

二 检查点

主要检查SMF在收到了AMF发过来的Nsmf_PDUSession_UpdateSMContext后，SMF能给UPF发N4的PFCP Session

Deletion Request，要求UPF删除N4会话并释放资源，并能给AMF回正确的响应。

如果该会话是UE的最后一个PDU会话，SMF应支持向UDM发送去订阅（Nudm_SDM_Unsubscribe）和去注册登记

（Nudm_UECM_Deregistration）消息。

三 消息举例

来看几个实际报文，和前面的检查点是对应的。

1）AMF发给SMF的Nsmf_PDUSession_UpdateSMContext请求：

- 采用Post方法，Post请求的request-uri部分为：

/nsmf-pdusession/v1/sm-contexts/55555555/modify。可以看出找SMF的PDUSession服务，请求对UE的SM上下文进

行modify的服务操作，其中55555555是PDU会话建立阶段由SMF分配的smcontext referenceId（smContextRef）。

JSON数据部分包含了透传给SMF的NAS消息PDU Session Release Request（放在N1SmMsg参数里）、UE位置、服

务网元的实例Id等信息。如下：

JavaScript Object Notation: application/json

Object

Member Key: servingNfId

String value: 11111111-2222-3333-4444-66666666

Key: servingNfId

Member Key: ueLocation

Object

Member Key: nrLocation

Object

Member Key: tai

Member Key: ncgi

Key: nrLocation

Key: ueLocation

Member Key: n1SmMsg

Object

Member Key: contentId

String value: n1SmMsg

Key: contentId

Key: n1SmMsg

Member Key: smContextStatusUri

2）SMF给UPF发N4会话释放请求，主要参数只有一个Session Endpoint ID。如下：

Packet Forwarding Control Protocol

Flags: 0x21, SEID (S)

Message Type: PFCP Session Deletion Request (54)

Length: 12

SEID: 0x6660000000000000

Sequence Number: 66688777

Spare: 0

3）SMF给AMF回200 OK。消息中应包含需要透传给UE和gNB的N1消息：PDU Session Release Command和N2消

息：PDU Session Resource Release Command。如下图：

4）SMF检查发现这是UE的最后一个PDU会话，给UDM发去注册登记消息。采用DELETE方法，request-uri

是：/nudm-uecm/v1/imsi-460xx0000000666/registrations/smf-registrations/5 。该消息没有JSON数据部分，uri中最后

那个5是PDU Session ID。然后UDM回204 no content。表示注册登记信息已经清除了。

5）SMF检查发现这是UE的最后一个PDU会话，给UDM发去订阅消息。采用DELETE方法，request-uri是：/nudmsdm/v1/imsi-460xx0000000666/sdm-subscriptions/referenceid-55555555-sm-data。可以看到，该消息调用了NudmSDM服务，并包括UE的IMSI，uri最后那一长串是在创建订阅关系时由UDM分配的订阅号（SubscriptionID）。UDM删

除订阅关系后回204 no content。

2.3.4 支持去激活用户面资源

一 概述

当某些场景下，SMF需支持去激活用户面资源（DRB和N3隧道资源），也就是向UPF发送请求，要求释放N3隧道和用

户面资源。在规范23502的4.3.7 CN-initiated selective deactivation of UP connection of an existing PDU Session节介

绍。

规范中提到的场景主要包括：

- UE离开了LADN区域；

- UPF检测并上报PDU会话没有数据传输等；

- AMF通知SMF，UE已经离开了Allowed Area。

- 切换流程中，目标gNB拒绝了所有的Qos流的建立、或收到AMF指示说PDU会话建立失败。

二 检查点

主要检查SMF能支持规范中提到的主要步骤，如下图所示：

1）SMF根据前面提到的4种场景，在本地做出用户面资源释放的决定。

【注意：规范图里有两个UPF，其中一个UPF写的是UPF（N3 terminating）代表这个UPF是终结N3接口的，也叫IUPF，右边还有一个UPF（to buffer）则是终结N9接口或者PSA角色的UPF。但实际环境中，可能不一定有I-UPF，或

者两个UPF是合设的。因此，相应的步骤也会合并。】

如果SMF决定释放终结N3口的UPF（The SMF may decide to release the UPF of N3 terminating point.），则执行步

骤2和步骤3。

如果SMF决定保持终结N3口的UPF（Otherwise, if the SMF decides to keep the UPF of N3 terminating points），则

执行步骤4。（跳过步骤2和3。）

2）如果SMF决定释放终结N3口的UPF，SMF需要给终结N3口的UPF发会话释放请求，将N4会话释放掉。

3）同时，SMF还需要给UPF（PSA）发送PFCP会话更新请求，下发缓存规则或转发规则，指示UPF缓存或丢弃下行

数据。

4）如果SMF决定保持终结N3口的UPF，SMF需要给终结N3口的UPF发会话更新请求，消息中包含需要移除的gNB侧

的N3隧道信息，并下发缓存和报文转发规则，告诉UPF是缓存还是丢弃下行数据报文。

5）SMF调用AMF的Namf_Communication_N1N2MessageTransfer，请求AMF透传N2消息：Resource Release

Command给gNB，请求gNB释放相关的资源。

三 消息举例

来看几个实际报文，和前面的检查点是对应的。

1）如果SMF决定释放掉I-UPF的N4会话，则发送PFCP Session Release Request给UPF，该消息除了SEID外，没有

其他本流程相关参数。具体可参考2.3.3.节中的消息举例。

2）当SMF释放了和N3终结点UPF的N4会话后，还要给UPF（PSA）发PFCP Session Modification Request，下发更

新的缓存规则或转发规则。告诉PSA是缓存还是丢弃下行报文。（反正就是不能转发，因为下行的N3用户面已经被拆

掉了，不通。而且一旦转发，就会被计费，多收用户钱了。）如下图所示：（本例中，SMF下发了一个更新的FAR规

则，要求PSA丢弃下行数据。）

3）而无论I-UPF的N4会话释放释放，N3的用户面资源都是需要释放的。因此无论是哪种场景，SMF都要调用AMF的

Namf_Communication_N1N2MessageTransfer，请求AMF透传N2消息：PDU Session Resource Release Command

给gNB来释放N3资源。该消息采用Post方法，其中request-uri为/namf-comm/v1/ue-contexts/imsi460xx0000066666/n1-n2-messages。JSON数据部分如下图所示：

最后还要检查AMF确实把N2消息发给了gNB。如下图：