相关文章将以公众号同步更新。 公众号： 5G通讯大家一起学习
持续更新的相关5G内容均直接基于3GPP进行整理，保证更新内容的准确性，避免二手甚至多手资料的虚假宣传误导网民。
详细介绍流程后，组织主题内容，如切片、服务发现、QoS流端到端映射等。 每个学生不仅可以纵向学习知识点，还可以横向关联知识，深入理解和运用。
目录
1.2.4.6 annrf _ nf discovery _ request
1.2.4.6 bnn RF _ nf discovery _ request response
1.2.4.7a(a ) namf _ communication _ n1消息通告
1.2.4.6 annrf _ nf discovery _ request看看此步骤的触发条件。 从步骤4b开始，初始AMF可以通过查询NSSF来获得目标AMF候选列表(candidateAmfList )或目标AMF集(targetamfset )。
如果初始AMF获得目标AMF列表，则AMF将根据本地配置选择目标AMF。 如果目标AMF的信息(如IP地址)存储在本地，则不需要联系NRF。 如果没有目标AMF的信息，或者NSSF返回AMF Set，则必须联系NRF以获取包含目标AMF信息的目标AMF的nf配置文件。
初始AMF查询NRF的服务发现过程如下图所示。
请求消息的HTTP方法是GET
请求的资源uri:{ API root }/nnrf-disc/v1/nf-instances
GET请求的消息主体为空，但GET的查询参数非常丰富，3GPP共有8页，基本上所有网络名词都可以用作查询参数。 详情请参照TS29.510。 这里不详细说明。
在AMF重新选择注册过程中，可以使用NFInstanceID和AMF Set ID、NF类型(AMF )作为查询参数来查询目标AMF。
1.2.4.6 bnn RF _ nf discovery _ request response服务发现的查询结果如下图所示：
如果查询正常，并且与查询参数的内容相匹配，则响应消息主体在" SearchResult "中返回200 OK响应。 如果找不到，携带适当的错误原因。
搜索结果的内容包括在NRF中注册NF时的NF配置文件、查询结果的有效期等。 详细内容请参照下图。
重要信息介绍：
- validityPeriod
查询结果的有效期。 例如，在第一个AMF查询完成NRF之后，查询结果在多长时间内有效，时间单元为秒。 请注意，该值与HTTP响应消息标头" Cache-Control "中的" max-age "的值相同。
- nfInstances
查询结果的NF实例(即NF的NF配置文件)包含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消息。
为什么直接转发可以避免注册失败呢？接着看后面的详解。
1.2.4.7a（A） Namf_Communication_N1MessageNotify这条消息我们在1.1.2.21.6.2章节介绍UE策略时介绍了一部分内容。这里介绍该消息AMF间消息传递的功能。
7a（A）和7a（B）两个步骤是转发NAS消息的两种方法，不会同时出现。在实际应用中具体使用方法A还是方法B，取决于AMF本地配置的策略和签约信息。签约信息怎么理解呢？比如多个运营商基站共建，但是核心网独自建设，此时初始AMF就要根据用户的签约把消息转发到UE归属运营商的网络。至于AMF本地配置的策略本章节后面会具体介绍。
我们面临的第一个问题是n1NotifyCallbackUri从哪里来？UE策略下发时使用的Callback Uri是PCF订阅AMF事件时生成的，而这里new AMF和初始AMF素未谋面，根本谈不到订阅关系，那么这个URI从哪里得到呢？
在重选AMF流程中，n1NotifyCallbackUri是从NRF返回给初始AMF的NF Profile中得到的。NF Profile中包含defaultNotificationSubscriptions字段，该字段类型为DefaultNotificationSubscription，从其数据类型定义中可以看到callbackUri。Registration Request的传递就是通过调用该URI进行的。详见下图：
其中：
- notificationType
该值为"N1_MESSAGES"取值时，用于N1消息的传递。
- callbackUri
初始AMF通知目标AMF时使用的Call URI地址。
- n1MessageClass
当notificationType取值为"N1_MESSAGES"时需要包含该IE，并且该消息的取值为5GMM。
上面Callback Uri的问题解决了，下面看一下消息体N1MessageNotification的内容。详见下图：
从上图可以看出来，消息体数据类型中的n1MessageContainer就包含有初始NAS消息。n1MessageContainer中n1MessageClass的取值为“5GMM”，表示n1MessageContent的内容就是5GMM NAS消息Registration Request。
Namf_Communication_N1MessageNotify Request消息除了把Registration Request消息带过去了，还带有其它信息：
（1）RAN NGAP ID和初始AMF的名字。 AMF的名字是字符串类型，用于在gNB中识别AMF。在这里用于让gNB识别N2终结点；
（2）RAN标识，如：RAN Node Id、RAN N2 IPv4/v6地址；
（3）gNB之前发送给初始AMF的信息，如：UE的位置信息、RRC Establishment Cause、UE Context Request等，这些信息从Initial UE Message消息中都可以得到，详见1.1.2.3章节介绍。UE Context Request用于在注册请求被AMF接受后，向gNB发送Initial Context Setup Request消息，初始化gNB中的UE Context；
（4）UE的SUPI及UE的MM Context（移动性管理相关的数据）。这部分数据通过鉴权流程可以得到；
（5）UE的Allowed NSSAI及其对应的NSI ID。初始AMF已经和UDM、NSSF交互过，Allowed NSSAI已经可以确定了。
上述的五条信息都包含在N1MessageNotification数据类型中的registrationCtxtContainer字段中，该字段完整的数据类型定义如下图：
在上面这张registrationCtxtContainer数据定义图中，需要重点关注的就是ueContext，它里面包含的内容很多，其中MmContext作用很大，其中包含有初始AMF和UE协商好的加密和完整性保护算法、上行和下行的NasCount等信息，用于执行消息的安全保护。
响应消息：
Namf_Communication_N1MessageNotify Request的响应消息比较简单，如果目标AMF成功接受请求消息，直接返回：204 No Content。其它响应消息信息如下图：
从上面的叙述能够看出来，初始AMF使用N1MessageNotify消息把UE当前的安全上下文信息传递给了目标AMF。根据TS 23.502的规定：如果UE和初始AMF之间已经建立了安全上下文，为了避免用户注册失败，初始AMF需要通过7a（A）步骤直接转发NAS消息（即：Registration Request消息）给目标AMF。
这句话怎么理解呢？如果初始AMF收到Registration Request消息，找到了old AMF，并且old AMF成功对注册消息进行了完整性校验，此时，初始AMF得到了注册UE的UE Context。初始AMF根据UE Context就可以判断不能为UE服务，就需要访问NSSF寻找目标AMF。这样就不能算是UE和初始AMF建立了安全上下文。因为对注册请求的解密和完整性验证都在old AMF中执行的，初始AMF只是起了消息传递的作用，而且如果初始AMF不能为UE服务，还需要通知old AMF继续保持UE Context，等待该UE的真主出现。初始AMF也不会保存UE Context。
UE和初始AMF建立安全上下文的意思就是说，初始AMF执行了AUSF参与的鉴权流程，详见1.1.2.9.1章节介绍。此时UE和AMF协商了加密和完整性保护算法，UE和初始AMF间启动了NAS消息的安全保护功能。
当然，这中间还会面临一个能不能直接转发的问题。比如北京和河北的AMF可能根本都不允许直接互访。不过目前国内某运营商的网络互访貌似还没有问题。这都是根据具体的网络部署情况决定的，也属于本地策略的范畴。像刚才这个例子，同一个基站现实中也不可能同时连接北京和河北的AMF。现网应用的场景远比我们技术探讨时遇见的场景简单，基本不会出模糊或者罕见的场景。3GPP规范里一般的原则就是：是否是同一个AMF Set，同一个AMF Set内要允许互访。实际应用中一般用AMF Set来区分是否是同一个AMF POOL，也就是AMF POOL内的各个AMF要允许互访。
如果初始AMF不能为UE服务，通过gNB将注册消息转发给目标AMF，就是NAS消息重路由的（B）方法。