本文已参与「新人创作礼」活动，一起开启掘金创作之路。
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
///////////
1.2.4.8 Steps 4-22 of figure 4.2.2.2.2-1
最后这一步大部分只剩下技术探讨了，规范里介绍的很简单，注册流程全图的Steps 4-22重新再来一遍。下面针对其中的重复步骤分析一下是不是必须的，只做一家之言，仅供日常参考分析问题，随时欢迎各位同学一起讨论。
1.2.4.8.1 初始AMF从old AMF得到UE Context
此种情况下，UE可以不需要执行鉴权流程，直接利用原来的安全上下文。此时初始AMF根据UE Context中的Allowed NSSAI来判断是否能够支持UE请求的所有切片。如果不能够为UE提供服务，则执行AMF重选。之后，选择（B）方法通过RAN将注册消息转发到目标AMF，之后目标AMF重新从第4步骤old AMF获取UE Context开始执行后续流程。是否执行鉴权流程和之前介绍的一样，主要看old AMF中的UE Context是否可用。
为什么是比较Allowed NSSAI呢？因为从UE Context中包含的mmContex的定义来看，其中只包含Allowed NSSAI及其映射。详见下图：
我们根据TS 24.501的说明，UE在移动性注册中，Registration Request消息中携带的Requested NSSAI来源只有Allowed NSSAI和Configured NSSAI。UE在之前的注册中，收到Registration Accept消息内容的时候会将获得的NSSAI和PLMN关联起来保存在UE的非易失存储器中。后续进行注册时，携带的Requested NSSAI应该是同一个PLMN的（可以理解为同一个运营商，即使不是同一个PLMN也需要包含相关切片的映射），所以，对于移动性注册，由于AMF不支持请求的切片导致AMF重选的情况应该不会出现，国内同一个运营商各个省部署的切片基本是一致的。出现重选AMF的场景基本就是同一区域下可能有两个厂家的AMF POOL覆盖，我们又要指定区域下的UE注册在指定的AMF上，比如CRAN基站的覆盖，可能就会出现AMF重选，但是此时AMF需要通过TAC来区分不同的区域，否则核心网无法引导UE在指定的AMF POOL注册。
对于初始注册也一样，如果UE在同一个PLMN下注册过，本地保存有Allowed NSSAI和Configured NSSAI，再次发起初始注册时会携带Requested NSSAI，基站根据NSSAI选择AMF，出现AMF重选情况可能也比较少。初始注册，出现AMF重选比较多的情况可能是不同PLMN下的初始注册或者重新插拔USIM卡后的注册，此时UE发送的注册消息不携带Requested NSSAI，基站会将注册消息发送到默认AMF，出现AMF重选。
1.2.4.8.2 初始AMF没有从old AMF得到UE Context
没有得到UE Context原因可能是UE使用SUCI注册、或者初始AMF找不到old AMF，或者不同PLMN间的注册N2接口无法重定向，old AMF只返回了SUPI等等。
上面这些情况就需要初始AMF和AUSF进行UE鉴权，之后下载UDM中的切片选择数据，判断是否需要执行AMF重选。
TS 23.502有一段备注：如果AMF重建了UE安全上下文，初始AMF需要直接转发注册消息到目标AMF，这样可以避免注册失败。失败的原因是UE和AMF的安全上下文不同步。为什么会这么说呢？这里简单分析一下。
从1.1.2.9章节我们知道，AMF和AUSF之间如果发生了鉴权，AMF会获得新的密钥，之后根据新密钥启动NAS的安全保护。此时，UE和AMF之间的安全上下文是同步的。如果此时的AMF（初始AMF）下载完切片数据后，发现自己不能为UE服务，重选了一个AMF，即：目标AMF。我们需要从下面两种方法选择一个转发注册消息：
（1）如果此时采用（A）方法，也就是初始AMF直接转发注册消息和UE Context（包含安全上下文部分）给目标AMF。那么根据上下文理解，此时应该从注册流程全图的第13步：“选择UDM”开始执行后续流程。因为这样就跳过了目标AMF和AUSF重新执行鉴权的步骤，也就是跳过了目标AMF使用新的安全上下文的步骤，此时目标AMF使用的仍然是初始AMF的安全上下文信息。从1.2.4.7a（A）步骤的介绍能看到Namf_Communication_N1MessageNotify消息除了发送了注册消息，还把注册上下文（其中包含安全上下文信息）一起也发送了。这样就能保证目标AMF在向UE发送Registration Accept时使用的安全上下文和UE同步，UE能够正常执行解密和完整性保护验证，注册成功执行。也就是TS 23.502说的避免了UE注册失败。
我们从现网设备抓取到的一个AMF重选信令，信令流程如下：
从上图可以看到目标AMF收到了Namf_Communication_N1MessageNotify消息之后又和UE重新进行了一次完整鉴权，也就是目标AMF和UE又协商了一个新的安全上下文。我们抓取信令的业务场景是UE使用SUCI注册，显然初始AMF已经执行完了一次鉴权流程，从N1MessageNotify消息的内容RegistratonCtxContainer也能看到携带了安全上下文，如下图。
从现网信令来看，该厂家的设备目标AMF完整执行了注册流程全图的Step 4-22，目标AMF没有跳过鉴权，相当于带AMF重选的注册流程需要执行两次鉴权，注册时延会增加，但注册成功率应当会由一定程度的提高。这种处理方式最保险，不容易出现bug，而且程序的判决逻辑比较简单。
如果目标AMF重新执行一次鉴权就不涉及TS 23.502中说的安全上下文同步和不同步的事情了，UE和目标AMF安全上下文一定是同步的。
TS 23.502中还有一个备注，如果初始AMF和目标AMF发生了直接消息传递的情况，就不能保证切片之间的隔离了。这点比较好理解，比如初始AMF是切片1，目标AMF是切片2，如果他们之间发生了通信，相当于切片1和切片2的独立逻辑网络之间发生了通信。原本切片之间的隔离性就破坏了。
（2）如果此时采用（B）方法，通过基站转发注册消息，从上面的叙述中知道，目标AMF得不到新建立的安全上下文，但是目标AMF仍然能继续处理Registration Request消息。因为TS 24.501规定，不管有没有安全保护，AMF都需要能处理注册请求消息。之后，注册请求会在目标AMF中继续Step4～22步，完成UE的注册流程。UE和目标AMF之间的安全上下文一直是同步的，注册流程正常也会成功。
1.2.4.8.3 结论
综合上面的分析，可以得到下面几点：
（1）不管初始AMF能不能从old AMF得到UE Context，如果重选AMF后执行一次鉴权，注册都会成功。这里不含意外情况，只针对安全上下文来说。
（2）如果通过gNB转发注册消息，目标AMF如果能够找到old AMF，则获取UE Context，不需要AUSF鉴权。如果得不到old AMF中的UE Context，目标AMF一定会执行鉴权。这个场景和不发生AMF重选的场景基本一样，也比较容易理解。
（3）如果目标AMF从初始AMF得到了安全上下文，在old AMF中也有该UE的安全上下文，则初始AMF中的安全上下文会替代old AMF中的安全上下文。这个场景貌似不会发生呢？
