本帖最后由 wuyou125 于 2021-4-29 08:57 编辑
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
在先容完流程详解后，会整理专题内容，比如切片、服务发现、QoS流端到端的映射等内容，各位同学不仅可以纵向学习常识点，横向也会将常识关联起来，达到深入理解灵活运用的目的。
目录
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消息。 为什么直接转发可以避免注册失败呢？接着看后面的详解。 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）方法。
| 
9
发表于 2021-4-29 08:55:54
