本文已参与「新人创作礼」活动，一起开启掘金创作之路。
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
///////////
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本地配置的策略本章节后面会具体介绍。
（A）方法有一个使用场景，在TS23.501中有明确说明：如果NSSF直接返回了候选AMF列表，则初始AMF只能通过Namf_Communication_N1MessageNotify消息转发注册请求。
我们面临的第一个问题是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）方法。
