同一个基站连接两个核心网AMF POOL的场景分析及带AMF重选的注册流程

wuyou125

持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。敬请关注公众号：5G通信大家学
在先容完流程详解后，会整理专题内容，比如切片、服务发现、QoS流端到端的映射等内容，各位同学不仅可以纵向学习常识点，横向也会将常识关联起来，达到深入理解灵活运用的目的。

目录

1.2 带AMF重选的注册流程

1.2.1 同一个基站连接两个核心网AMF POOL的场景分析

1.2.2 流程图

1.2.3 专项篇

---

[url=]1.2[/url]带AMF重选的注册流程

到这5G SA注册流程详解完成，下一篇开始详解的内容是带重选的5G注册，这个步骤基本是5G注册的标配。

在国内5G建网初期，行业切片的场景比较少，出现切片不支撑导致的AMF重选可能比较少。目前最有可能出现重选的场景是基站连接多个核心网，比如同一个基站连接两个ToB、ToC两种核心网，或者同一个基站连接两个不同厂家的AMF POOL的场景，这样就会面临ToC的AMF不支撑物联网的切片，或者网络要引导UE注册到指定的核心网导致AMF重选流程的发生。

对于同一个厂家基站连接两个核心网POOL的情况，4G的时候HUAWEI还有相关网络资源的分配专利。5G时连接两个POOL的场景，单从技术来讲也没有问题，但是不能指定哪个POOL。因为在同一个基站同一个TAC下，基站根据已有的信息没法选择指定的核心网POOL。在5G的时候还有C-RAN类型的基站，即：一个BBU下可以连接多个RRU。这种RRU形式的基站如果配置不同的TAC，核心网可以通过AMF重选的流程将UE重定向到另外一个核心网AMF POOL。

也许有人会想，为什么C-RAN类型的BBU不能根据UE所处的TAC直接把UE的消息路由到指定的AMF POOL呢？这样就省了由于选择错误导致的核心网重选流程。大家看一下原因。

1.2.1 同一个基站连接两个核心网AMF POOL的场景分析

gNB上电后，会根据配置的AMF地址发起SCTP偶联的建立（AMF的IP地址目前是基站配置好的，另一种方法也可以通过DNS获取，但这种方法目前还没有使用的）。

SCTP偶联建立完成后，也相当于建立了第一条TNL Association，但是后续如果想新增加TNL Association，则需要AMF向gNB发送AMF CONFIGURATION UPDATE消息，携带其它的IP地址建立新的TNL Association。当TNL Association建立成功后，gNB在这条TNL Association上发送第一条RAN CONFIGURATION UPDATE消息，AMF收到消息后会通过Global RAN node ID将这条TNL Association和NG-C接口实例关联。从这段叙述中可以看出来，gNB在开局的时候只需要配置一个AMF的IP地址就可以了，其它的IP地址可以通过AMF下发给gNB。

注：

SCTP偶联和TNL association虽然类似，但不是完全相同的东西。比如多归属SCTP偶联可以有多个，但同时只有一条起作用，但是TNL Association的多条可以同时有效。

接下来大家看一下TNL Association可用后，gNB和AMF间交换信息的流程，这些信息就关系到“为什么基站没法为UE选择指定AMF POOL”的原因。流程图如下：

​

gNB通过NG SETUP REQUEST消息将自己的信息发送给AMF。NG SETUP REQUEST消息的定义如下：

​

消息内容很直观，从消息定义中，大家可以看到gNB将自己支撑的Global RAN Node ID、TAC List、TAC切片支撑列表、广播的PLMN等信息发送给了AMF。

再看一下AMF发送的NG SETUP RESPONSE消息的定义：

​

从AMF的回复消息中可以看到，AMF把自己的GUAMI、容量因子、AMF支撑的切片、支撑的PLMN信息发送给了gNB。这些信息就可以供gNB在注册流程中选择AMF使用。

这条NG SETUP RESPONSE消息中并没有把AMF支撑的TAC发送给gNB，所以对于C-RAN类型的基站，如果TAC相同的话，基站从上面的信息中根本无法将UE的注册请求消息路由到指定的核心网。当然切片可以，gNB可以根据切片选择不同的AMF POOL。

最后，在C-RAN类型的基站连接两个核心网AMF POOL场景下（比如：不同厂家的AMF POOL），如果要实现UE在指定AMF POOL中登记注册，只能通过C-RAN下的RRU配置不同的TAC，之后核心网使用NSSF重选AMF的功能来实现​UE在指定的AMF ​OOL中注册的目的。

下面就开始详解带AMF重选的注册流程。

[url=]1.2.[/url]2 流程图

带AMF重选的注册流程，大部分的内容和初始注册流程基本一致，只是把不同于1.1 注册流程的步骤详解一下即可。

这里的初始AMF是指第一次收到Registration Request消息的AMF。

​

[url=]1.2.[/url]3 专项篇

1. gNB转发将承载有Registration Request消息的Initial UE Message（N2）发送给初始AMF。gNB选择AMF的方法详见：1.1.2.2 AMF选择。

2. AMF收到Registration Request消息后，向old AMF获取UE Context、触发AUSF的鉴权流程等步骤和1.1章节相同，这几步都是可选的步骤。

这一步需要实行的原因是初始AMF需要用户的SUPI和签约数据用于判断当前的初始AMF是否能够为UE服务，如果不能够服务当前的UE，初始AMF需要重新路由Registration Request消息。

3a. 如果初始AMF从old AMF没有得到UE Context，此时这一部分数据就需要从UDM中获取。本步骤初始AMF使用SUPI向NRF实行UDM服务发现，进行UDM选择。

3b. 初始AMF从UDM下载用户的切片选择签约数据。

3c. UDM返回UE的切片选择签约数据。

4a. 如果AMF根据签约数据，判断不能服务于注册请求Requested NSSAI中所有已签约的S-NSSAI切片，初始AMF需要查询NSSF，来获得可以为UE提供服务的AMF信息。

4b. NSSF返回AMF Set或者AMF候选AMF地址、Allowed NSSAI等信息。NSSF也可能返回用于选择AMF的NRF。

5. 初始AMF向old AMF发送Namf_Communication_RegistrationStatusUpdate消息，通知old AMF当前UE在初始AMF注册没有成功完成。

6a. 初始AMF向NRF实行服务发现，发送Nnrf_NFDiscovery_Request请求。

6b.  NRF返回给初始AMF目标AMF的地址等信息。

7(A). 初始AMF根据具体情况选择7A或者7B进行AMF重选的消息传递。如果初始AMF和目标AMF可以直接通信，则通过Namf_Communication_N1MessageNotify转发注册消息到目标AMF。

7(B). 如果初始AMF不能和目标AMF直接通信，初始AMF会将重新路由的注册消息发送给gNB，由gNB再将注册消息发送给目标AMF。

8.    目标AMF收到注册消息，继续实行后续注册。步骤和大家在1.1节叙述的第4～22步注册流程一样。

带AMF重选的注册流程，相比1.1节叙述的注册流程只是多了重选的步骤，其它完全一样。