本文已参与「新人创作礼」活动，一起开启掘金创作之路。
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
///////////
1.2.4.6a Nnrf_NFDiscovery_Request
我们先看该步骤的触发条件。从第4b步骤中，初始AMF通过查询NSSF已经可以得到候选目标AMF列表（candidateAmfList）或者目标AMFSet（targetAmfSet）。
如果初始AMF得到的是目标AMF的列表，AMF根据本地配置选择一个目标AMF，如果本地保存有目标AMF的信息，如IP地址，就不需要查询NRF了。如果没有目标AMF的信息或者NSSF返回的是AMF Set就需要查询NRF，获得目标AMF的NF Profile，其中包含目标AMF的信息。
初始AMF查询NRF的服务发现流程如下图：
请求消息的HTTP方法为：GET
请求的资源URI：{apiRoot}/nnrf-disc/v1/nf-instances
GET请求的消息体为空，但是GET的查询参数非常丰富，3GPP中一共有8页之多，基本所有的网络名词都可以作为查询参数，具体详见TS29.510，这里就不细说了。
在AMF重选的注册流程中，可以使用NFInstanceID，及AMF Set ID、NF类型（AMF）作为查询参数，查询目标AMF。
1.2.4.6b Nnrf_NFDiscovery_Request Response
服务发现的查询结果如下图：
如果查询正常，匹配到了查询参数中的内容，则返回200 OK响应，响应消息体为：SearchResult。如果没有找到，会携带相应的错误原因。
SearchResult的内容就是NF在NRF中注册时的NF Profile、查询结果有效期等。详见下图：
重点信息介绍：
- validityPeriod
查询结果的有效期。比如初始AMF查询完NRF后，查询结果在多长时间内有效，计时单位为：秒。需要注意的是，该值和HTTP响应消息头部“Cache-Control”中的“max-age”的值相同。
- nfInstances
查询结果的NF实例，即：NF的NF Profile，里面包含NF的基本信息，比如IP地址、提供的服务等信息。初始AMF据此就可以找到目标AMF的IP地址。
需要注意的是该字段信息也可以为空，表示没有NF实例匹配上查询参数。在本例中就是没有找到合适的目标AMF。此时根据设备的实现方式，初始AMF可能会直接拒绝UE的注册，也可能就会用第7步的（B）方法，将注册消息转发给基站，由基站根据Allowed NSSAI等信息决定将注册消息路由到哪个AMF。如果再次收到消息的AMF发现是重路由的UE注册消息，本AMF还是不能支持，一定是要拒绝掉UE的注册请求的，不可能让注册消息在gNB和AMF之间踢皮球。这属于设备实现方面的问题。3GPP规范里，目前还没有读到相关的处理规则。但是基站一定不会直接拆掉RRC连接，放弃UE注册。因为即使拆掉了RRC连接，按照规范UE还是要重新建立RRC连接进行注册，会继续浪费网络资源。
- searchId
如果返回消息中，包含searchId，在查询结果的有效期内，AMF可以使用该searchId查询。完整的查询即：{apiRoot}/nnrf-disc/v1/searches/{searchId}。
除正常的200 OK成功相应，其它错误响应有：307 Temporary Redirect、400 Bad Request、403 Forbidden、404 Not Found、500 Internal Server Error。
需要注意的是404 Not Found的意义并不是没有找到匹配的NF实例，而是代表查询的URI找不到，或者在分层部署NRF时，本地NRF缺少信息将请求转发或重定向到其它NRF时返回该错误码。
初始AMF收到NRF的返回信息，根据收到的候选AMF的能力信息、本地策略等选择一个合适的目标AMF。
如果初始AMF和UE之间已经建立的安全连接，也就是说网络对UE进行了鉴权，启动了NAS安全。根据1.1.2.9.4章节的叙述，此时UE和AMF之间的ngKSI指向的NAS Security Context是一致的，这样才能保证UE和AMF之间的NAS消息互相能够加密和完整性校验通过，那么，这种场景下为了避免注册失败，初始AMF会将注册NAS消息直接转发到目标AMF，也就是通过1.2.4.7a步骤的Namf_Communication_N1MessageNotify消息。
为什么直接转发可以避免注册失败呢？接着看后面的详解。
