《5GC实践篇》之SMF篇（1）对服务管理的支持

2.1.1.1 SMF到NRF中的注册 211

2.1.1.2 SMF到NRF中的注册更新

2.1.1.3 SMF发起到NRF中的去注册

213

214

2.1.2 SMF支持向NRF订阅其他网元状态事件 215

2.1.3 支持NRF的主备倒换 218

2.1.4 支持到NRF的心跳检测 220

2.1.5 支持对服务的授权 221

正文开始

2.1 对服务管理的支持

2.1.1 SMF到NRF中的注册/更新/去注册

和大多数SBI的5GC网元一样，SMF需要在NRF中注册自己的信息。当SMF被MANO系统创建完成后，SMF需要根据

本地配置的NRF地址，主动向NRF发起注册流程。将自己的NFProfile（自己的寻址信息以及能力信息）在NRF中进行

注册登记。【这个步骤是无需用户触发，在SMF割接入网之前就需要完成的。】

一 流程概述

SMF通过调用NRF暴露的NFManagement服务完成在NRF中的注册登记。采用PUT方法，在NRF中注册登记自己的

NFProfile具体流程在TS29510的5.2.2.2.2定义。注册成功，则NRF返回201 Created，这样在后续的5G注册流程中，

SMF就可以被自己的消费者网元如AMF选择。

二 SMF的NF Profile

所有支持SBI的5GC网元都要将自己的NFProfile注册登记到NRF中。NFProfile包含了网元需要注册登记在NRF中的信

息，如NFType、Instance ID、支持的PLMN、支持的切片、优先级、静态容量FQDN、IP地址、支持的服务等。根据

网元的功不同，NF Profile也会有所差别。NF Profile有些属于公共参数，有些属于该网元特有的参数。网元特有参数

大多通过xxinfo来定义。SMF特有的参数则通过smfinfo来定义，在29510的6.1.6.2.12定义。如下图：

三 消息举例

下面来看一个实际的SMF注册消息请求消息中，都带了哪些参数。请求消息包括Headers头部和JSON数据参数两个部

分。其中，Headers包括method=PUT、uri=/nnrf-nfm/v1/nf-instances/aaa-bbb-ccc-ddd（SMF的Instance ID）。

JSON数据部分包括：

从输出中可以看出，SMF注册到NRF中的NFProfile包括了公共参数如SMF支持的服务、NF类型、PLMN列表外，还包

含了SMF的特有参数smfinfo，下面包括了SMF/PGW-C合设的PGW-C的FQDN，SMF支持的TAI列表，SMF支持的切

片列表（DNN+切片的组合）。

2.1.1.2 SMF到NRF中的注册更新

一 流程概述

当SMF将自己的NFProfile注册到NRF之后，如果此后SMF的NFProfile中的参数发生变化，SMF需要立即发起到NRF的

注册更新流程（保证其他网元能实时选择到能力更新后的SMF。）例如当以下参数发生变化，SMF要立即发起注册更

新流程：

- SMFF的FQDN和SBI的Service IP因为割接调整，发生变化；

SMF通过调用NRF暴露的NFManagement服务下的NFUpdate服务操作（Service Operation）完成在NRF中的注册更

新。具体流程在TS29510的5.2.2.3中定义。

更新的话有两种，一种是完全更新（也就是整个替换NFProfile，这种不太多见）；还有一种是部分更新（即只更新部

分参数，更为常见。）。完全更新采用PUT方法，正常响应为200 OK（表示NRF侧更新成功）。部分更新采用PATCH

方法，正常响应为200 OK（表示NRF侧更新成功）。

二 消息举例

下面来看一个实际的SMF注册更新的请求消息（部分注册更新）。在本例中，我们将SMF支持的切片信息进行修改，

将SMF支持的切片替换为（op操作符为replace）sst1+sd1，触发了到NRF的注册更新流程。其中请求消息包括

Headers头部和JSON数据参数两个部分。其中，Headers包括method=PUT、uri=/nnrf-nfm/v1/nf-instances/aaa-bbbccc-ddd（SMF的Instance ID）。

JSON数据部分为：

[{"path":"/sNssais","value":[{"sst":1,"sd":"000001"}],"op":"replace"},

{"path":"/smfInfo/sNssaiSmfInfoList/0/sNssai","value":{"sst":1,"sd":"000001"},"op":"replace"}]

从结果中可以看到，SMF将在NRF中注册登记的支持的切片信息替换为了sst1+sd1，NRF修改成功后返回200 OK。

2.1.1.3 SMF发起到NRF中的去注册

一 流程概述

当SMF停止服务时，需要先发起到NRF的去注册，这样可以避免被其他消费者网元选中后为UE服务。SMF停止服务的

典型场景，比如：

- SMF版本升级或割接（如业务地址调整）；

- SMF发生故障，需要隔离业务，将业务迁移到其他SMF上去；

SMF通过调用NRF暴露的NFManagement服务下的NFDeregister服务操作（Service Operation）完成在NRF中的去注

册。具体流程在TS29510的5.2.2.4中定义。去注册采用DELETE方法，正常响应为204 No content（表示NRF侧已成功

删除）。

二 消息举例

实际消息的举例其实没什么可看的，因为非常的简单。请求消息只有HEADER部分，在Request-URI中提供SMF的

instanceID即可，没有JSON数据。响应消息也只有一个204状态码，同样也没有JSON数据。

可以看到，请求消息的Headers包括method=DELETE、uri=/nnrf-nfm/v1/nf-instances/aaa-bbb-ccc-ddd（SMF的

Instance ID）。没有数据部分。

2.1.2 SMF支持向NRF订阅其他网元状态事件

一 概述

SMF应支持向NRF发起事件订阅，订阅其他感兴趣网元的状态。该功能调用的是NRF的Nnrf_NFManagement服务的

NFStatusSubscribe 服务操作，在29510的5.2.2.5节定义。采用POST方法，订阅成功回201 Created。例如SMF可以

通过NRF订阅UDM、PCF等感兴趣网元的状态，从而了解其他网元的可用性状态信息，为业务倒换或者网元间的负荷

分担提供依据。

在订阅请求消息中的关键参数是subscrCond，在29510的6.1.6.2.5节定义。用于向NRF声明希望订阅的网元和具体的

匹配条件（Condition to determine the set of NFs to monitor under a certain subscription in NRF.）。例如

NfTypeCond子参数描述的就是希望订阅的网元类型是什么。如下表所示：

当订阅的网元状态改变（如从注册状态变更为去注册状态，NRF需要给SMF发送通知。）

二 消息和场景举例：

首先来看一个SMF通过NRF订阅UDM状态的例子。请求消息采用POST方法，request-uri等于/nnrfnfm/v1/subscriptions，JSON数据部分携带了具体希望订阅的内容，如下：

从输出中可以看到有3个主要参数。ReqNfType=SMF是说发起订阅请求的网元是SMF、subscrCond的子参数

nfType=UDM表示我希望订阅UDM的状态，最后是SMF用于接收状态通知的uri。

当NRF收到后，会创建订阅关系，并返回一个订阅号来标识这个订阅关系。

接下来，当某个UDM状态变化（如某个UDM刚刚上线，刚刚注册到NRF上来，变为Registered状态）。NRF发现如果

订阅关系还在，就应该给SMF发送通知。接下来就是NRF发给SMF的通知消息举例。通知消息分为请求和响应，请求

采用POST方法，request-uri=/notifications/nrf/nf-status/v1/referenceid/111-222-333（111-222-333是举例，表示订阅

ID）。具体的通知内容在JSON数据中。

如上图所示，NRF给SMF发送了通知，通知SMF有一个新的UDM上线了。它的状态在NRF侧已经变更为

REGISTERD，意味着SMF可以尝试使用这个UDM的服务了。该UDM的能力信息在udmInfo里也告诉SMF了。包括该

UDM支持的SUPI范围和Routing Indicator等。

2.1.3 支持NRF的主备倒换

一 概述

5GC信令流程（如PDU会话建立流程）中，SMF需要查询NRF得到其他感兴趣网元（如UDM）的信息。通常，SMF需

要在本地配置两个NRF，并设置不同优先级，形成主备NRF。默认情况下，所有的网元选择请求都指向主用NRF。但

是当主用NRF出现故障时，SMF需要能够在无需人工干预的情况下，能自动切换到备用NRF发起网元的查询，从而继

续PDU会话建立流程（UE无感知）。

大致的倒换流程如下图所示：

二 消息举例

在本例中，可以看到。SMF首先向主用NRF1发起了查询，但到NRF1的TCP连接建立失败，NRF1无响应。SMF选择

备用NRF2发起网元选择。主要步骤和信令消息截图如下：

1）#8709号包是SMF向主用NRF1发起的TCP Syn三次握手的重传消息，但NRF1一直没响应。

2）#8710~8714号包是SMF重新选择备用NRF2发起TCP Syn三次握手建立成功。

3）#8719号包是三次握手成功之后，SMF调用备用NRF2的nnrf-disc服务发起UDM的查询。

2.1.4 支持到NRF的心跳检测

一 概述

按规范约定，SMF需支持到NRF的心跳检测。NRF心跳检测的详细原理介绍请参考原理篇的《NF状态心跳检测流程》

节。这里不再赘述。这里结合SMF回顾下大致的流程：

1）SMF周期性向NRF发heartbeat（心跳）消息；

2）如果指定时间内NRF收不到心跳消息，将该SMF状态置为suspend状态，该状态下SMF不会被其他NF（也就是

SMF服务的消费者网元如AMF）选择。

3）同时，由于SMF的状态变更，NRF需要发送通知给感兴趣的其他NF（如AMF）。

4）其他NF做出failover（倒换）的决定，选择其他的SMF为UE服务。

这里SMF发给NRF的心跳请求消息是HTTP消息，采用PATCH方法，NRF收到后回200 OK或204 No Content。

二 消息举例

看一个实际的SMF发给NRF的心跳消息，包括HTTP请求（Patch方法+JSON数据），request-uri=/nnrf-nfm/v1/nfinstances/xxx-yyy-zzz【xxx-yyy-zzz是SMF此前注册登记在NRF中的instance ID。 用于告诉NRF，是我是我，我是

SMF。】JSON数据部分包括：

[{"path":"/nfStatus","value":"REGISTERED","op":"replace"}]

【op代表操作符，取值为replace代表替换操作，替换什么呢？将自己的nfStatus设置为REGISTERED。请注册，这就

是一个HTTP的heartbeat消息。并不像其他协议（如GTP的Echo消息）一样，看名字就知道这是个心跳消息。其实UE

发送的周期性注册更新请求消息表面上也是个5G-NAS的Register消息，但其主要的作用也是维持UE和网络侧的心跳、

保活。】

2.1.5 支持对服务的授权

一 概述

SMF需要支持对自己提供的服务的授权，限制非授权的消费者网元进行访问。大致的流程是：

1）SMF先将自己的NF Profile在NRF中注册登记。该Profile中包含了SMF允许访问的消费者网元类型、允许的消费者

网元所属的PLMN-ID、允许的消费者网元所属的domain、允许请求的切片等授权信息。

2）SMF的消费者网元（如AMF）发起到NRF的SMF选择流程，NRF检查消费者网元的信息，如果满足SMF此前注册

登记的授权要求，则返回200 OK和SMF的NF Profile。如果不满足，则回403 forbidden。拒绝为该消费者网元提供

SMF的查询服务。

SMF服务授权的流程图大致如下：

二 消息举例

来看一个SMF服务授权的实例。

1）第1个消息：SMF发给NRF的注册请求（上图第1步），携带了SMF登记的服务授权信息。其中request-uri=/nnrfnfm/v1/nf-instances/xxx-yyy-zzz。JSON数据部分如下：

JavaScript Object Notation: application/json

Object

Member Key: ipv4Addresses

Member Key: nfType

Member Key: nfStatus

Member Key: smfInfo

Member Key: nfInstanceId

Member Key: plmnList

Member Key: sNssais

Member Key: nfServices

Array

Object

Member Key: nfServiceStatus

String value: REGISTERED

Key: nfServiceStatus

Member Key: ipEndPoints

Member Key: allowedNssais

Array

Object

Member Key: sst

Number value: 1

Key: sst

Member Key: sd

String value: 000001

Key: sd

Key: allowedNssais

Member Key: serviceInstanceId

Member Key: allowedPlmns

Array

Object

Member Key: mnc

String value: 66

Key: mnc

Member Key: mcc

String value: 460

Key: mcc

Object

Key: allowedPlmns

Member Key: allowedNfTypes

Array

String value: AMF

Key: allowedNfTypes

Member Key: allowedNfDomains

Array

String value: domain0

Key: allowedNfDomains

Member Key: versions

Member Key: serviceName

Member Key: scheme

String value: http

Key: scheme

Key: nfServices

这其中和授权相关的关键参数有：

- allowedPlmns：授权的PLMN-ID，本例取值为46066。

- allowedNfTypes：授权的消费者网元类型，本例取值为AMF。代表我这个pdusession服务只给AMF服务。其他网元

不能访问该服务。

- allowedNssais：授权的切片。本例取值为SST1+SD1。

- allowedNfDomains：授权的domain。本例取值为domain0。

2）第2个消息：某非授权网元请求NRF查询SMF，发给NRF的查询请求，采用GET方法，数据部分直接在request-uri

中携带。Request-uri=/nnrf-disc/v1/nf-instances?service-names=nsmf-pdusession&target-nf-type=SMF&requester-nf-

type=AMF&requester-nf-instance-fqdn=domain888&snssais=sst1,sd000001。这里和授权相关的主要参数有：

requester-nf-type=AMF和requester-nf-instance-fqdn=domain888。

第3个消息：NRF进行比对，发现请求的网元类型是AMF，这个没问题，过关。但接下来看它的FQDN属于

domain888。不属于SMF注册的授权domain。因此NRF直接返回403 forbidden。