AMF功能实战篇(37) NRF返回网元服务的FQDN，AMF支持根据FQDN查DNS

根据规范，AMF需要完成AUSF/UDM/SMF的选择，这在前面几节已经介绍过了。

但需要重点强调的是，5G的网元选择是基于网元服务（NF Service）作为最小颗粒度进行查询，而不是基于网元来查询的。

一个5G NF可以有多个服务，每个服务（NFServices参数）可以对外暴露不同的FQDN、业务IP和端口号（IPEndpoints参数）。

举一个例子如下，本例中UDM对外暴露了3个3GPP定义的标准服务，但可以采用3个不同的FQDN和IP端点给自己的消费者网元（如

AMF）来调用。

1.6.7.2 NFServices参数中的FQDN和IPEndpoints子参数

这里还得提一下NFService参数，也就是网元所支持的服务的详细信息，这个参数是是NFInstances参数的一部分。

每个SBI的5GC网元都要把该参数（自己支持的服务）在NRF中注册登记，用于后续的网元发现与选择流程。

该参数就包含了上节提到的该服务对外暴露的FQDN和IP端点。

该参数在TS29510的6.2.6.2.4节定义，如下（仅给出FQDN和IPEndpoints部分）：

从上图可以看到，NFService的fqdn和ipEndPoints都是O标，即Optional可选的。

也就是说AMF查NRF选择SMF的时候，NRF可能没有给AMF返回SMF的业务IP，而只给了FQDN（也许是SMF根本就没注册IP，只注

册了FQDN即域名）。

那在这种情况下，AMF应该支持构建SMF的FQDN，并向自己配置的DNSServer发起查询，最终得到SMF的该服务的SBI业务地址。

1.6.7.3 消息举例之NRF返回的结果只有业务的FQDN

下面来看一个实际的AMF在PDU会话建立流程中查询NRF选择SMF的例子（AMF选SMF详见1.6.4节），AMF选择的是一个支持nsmfpdusession服务的SMF，此时NRF返回的是SMF该服务的FQDN。

则AMF应构建SMF该服务的FQDN，向DNS发起查询，得到SMF的nsmf-pdusession服务的SBI业务地址，从而继续后面的PDU会话建

立流程。

1）AMF发给NRF的查询请求与1.6.4.2节相同。其中：

Request-uri=/nnrf-disc/v1/nf-instances?service-names=nsmf-pdusession&target-nf-type=SMF&requester-nf-type=AMF&snssais=

[{"sst":1,"sd":"000001"}]&dnn=xxnet

2）NRF返回给AMF的响应消息如下：

可以看到，NRF返回的查询结果包含了目标SMF的信息。包括：

- ipv4Addresses = 10.1.1.1（需要注意，这个是NF的IP，不是NF的pdusession这个服务的IP）。

- NFType = SMF。代表返回的结果是SMF这个网元的信息。

- nfServices下的子参数有：（注意看缩进，表示嵌套关系。）

1）serviceName=nsmf-pdusession（SMF支持的服务，和AMF请求中的完全一致）；

2）FQDN：取值是smf99.mnc099.mcc460.gprs。是SMF该服务的FQDN，不是SMF这个网元的FQDN。

3）ipEndPoints：端口号80，也是SMF该服务对外暴露的端口。并且该参数只有端口号，没有IP地址。也就是NRF并没有返回nsmfpdusession这个服务对外的IP地址。

1.6.7.4 消息举例之AMF构建服务的FQDN发起DNS查询

接下来，AMF根据SMF服务的FQDN构建A记录，向DNS发起查询，如下：

接下来，DNS返回对应的IP地址。如下：

最终，AMF得到了SMF的nsmf-pdusession服务的IP地址（10.1.1.1）和端口号80。

至此，AMF得到了SMF的完整寻址信息。接下来AMF将调用该服务，继续后面的PDU会话建立流程。