5G详解：带AMF重选的注册流程（Step 7a～结束）

相关文章会在公众号同步更新。公众号：5G通信大家学

持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。

在介绍完流程详解后，会整理专题内容，比如切片、服务发现、QoS流端到端的映射等内容，各位同学不仅可以纵向学习知识点，横向也会将知识关联起来，达到深入理解灵活运用的目的。

终于赶在五一前把涉及AMF重选的注册流程分析完了，查了很多规范，思考了很多才算理清思路。请诸位御览

目录

1.2.4.7a（B） Reroute NAS message

1.2.4.7b（B） Initial UE message

1.2.4.8 Steps 4-22 of figure 4.2.2.2.2-1

1.2.4.8.1 初始AMF从old AMF得到UE Context

1.2.4.8.2 初始AMF没有从old AMF得到UE Context

1.2.4.8.3 结论

---

1.2.4.7a（B） Reroute NAS message

3GPP TS 23.502中对该步骤的使用场景进行了介绍，总结如下：

（1）初始AMF和目标AMF不属于同一个AMF Set；

（2）初始AMF通过AMF Set查询NRF没有得到候选AMF列表；

（3）初始AMF根据自身配置判断自己无权为UE提供服务。

（4）如果初始AMF查询NSSF，没有返回候选AMF列表，也就是NSSF不知道哪些AMF满足UE的请求。比如多个运营商共享基站，收到注册消息的AMF也不会知道另一个运营商的AMF情况，但是基站共享，基站一定会知道，这种情况初始AMF就会把注册消息发送给gNB，由基站选择合适的目标AMF。

上面虽然列举了四个条件，在实际应用时需要综合考虑来决定选择哪个方法转发注册请求消息。

需要注意的一点是，如果初始AMF不能为UE服务，通过gNB将注册消息转发给目标AMF，无法携带UE的安全上下文信息。

注：

为什么经过gNB对NAS消息重路由不携带安全上下文？原因是消息里没有定义相关的字段。至于不定义的原因也许是保证核心网的安全相关安全数据不暴露给基站（RAN）。按照通信核心网的思路：核心网内自己的东西认为是安全可信的，安全数据不要流出自己的可信范围。

AMF将注册消息发回给gNB使用的消息是REROUTE NAS REQUEST，该消息用于将INITIAL UE MESSAGE消息重新路由到其它AMF。我们先看消息的定义：

重点IE介绍：

- RAN UE NGAP ID

基站侧用于区别UE的ID，为必选项。

- AMF UE NGAP ID

AMF侧用于区别UE的ID，该IE为可选项，因为本来该UE就需要在别的AMF上注册，初始AMF为该UE分配AMF UE NGAP ID并没有什么意义。

- NGAP Message

其中包含有基站发送给初始AMF的INITIAL UE MESSAGE。初始AMF相当于把收到的初始N2消息又转发回了基站。

- AMF Set ID

从NSSF中得到的AMF Set ID。基站可以根据其选择目标AMF，转发INITIAL UE MESSAGE。

- Allowed NSSAI

初始AMF从NSSF中获得的Allowed NSSAI，包含在这可以辅助基站选择目标AMF，并且目标AMF根据该字段也可以知道UE的Allowed NSSAI。

- Source to Target AMF Information Reroute

该IE用于初始AMF向目的AMF透明传递NSSF提供的信息，具体信息如下：

从上面IE可以看出来并没有给传递安全信息留有位置，所以通过gNB转发的注册消息不包含初始AMF的安全数据。

1.2.4.7b（B） Initial UE message

基站从根据收到的REROUTE NAS REQUEST提取出相关信息，重新组合成新的INITIAL UE MESSAGE发给目标AMF，消息名和第一次基站发送注册消息给初始AMF的消息名称一样，只是携带的字段不同。我们再复习一下INITIAL UE MESSAGE消息的定义，如下图。

我们现在再看这条消息定义的很多字段就非常清晰了，比如其中的AMF Set ID、Allowed NSSAI等IE的来源就很容易理解，分析到这我们在1.1.2.3章节的疑惑就烟消云散了。在之前详细分析时，Initial UE Message中的Allowed NSSAI困惑了我很长时间。TS 38.413中根本没有对该IE的来源进行介绍，只是让参看TS 23.502，而TS 23.502是一个600多页的规范，找Allowed NSSAI的使用场景相当麻烦了。规范虽然介绍的很详细，考虑的也很周全，但是用它来学习5G还是很花时间的，对于初学者也并不适合。

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中的安全上下文。这个场景貌似不会发生呢？