5G详解：带AMF重选的注册流程（Step1～5）

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

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

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

1.2.4 优享篇

1.2.4.1 Initail UE Message

1.2.4.2初始注册流程的steps 4-9b

1.2.4.3a UDM选择

1.2.4.3b Nudm_SDM_Get(Slice Selection Subscription data)

1.2.4.3c Nudm_SDM_Get response

1.2.4.4a Nnssf_NSSelection_Get

1.2.4.4b Nnssf_NSSelection_Get response

1.2.4.5 Namf_Communication_RegistrationStatusUpdate

1.2.4 优享篇

1.2.4.1 Initail UE Message

消息方向：gNB - > AMF

TS 23.502中带AMF重选流程的第1步，相当于初始注册流程的第1～3步，直接从AMF收到Initial UE Message开始。该消息是N2接口消息，详见1.1.2.3章节。

1.2.4.2初始注册流程的steps 4-9b

Steps 4-9b的步骤也是可选的，我们先简单回顾一下是哪些步骤：

- Step 4、5：new AMF向old AMF获取UE Context。这里的new AMF和本步骤说的初始AMF是一个意思；

- Step 6、7：如果没有从old AMF获取到UE Context，或者5G-GUTI没找到对应的AMF就需要向UE索取SUCI用于注册；

- Step 8：AMF进行AUSF选择。通过SUCI或者SUPI查询NRF为UE选择鉴权的AUSF。

- Step 9a：AUSF对UE进行鉴权，详见1.1.2.9章节。

- Step 9b：执行NAS安全，也就是开启NAS消息安全流程，详见1.1.2.9.4章节。

之后，初始AMF判断是否需要重新路由初始NAS消息，即：Registration Request消息。

为什么要在鉴权成功后初始AMF才执行重选，而不是收到注册消息就执行重选AMF呢？

原因相对比较容易想到，我想到的一些原因如下：

（1）网络首先要确认UE是否是非法用户，否则后续的任何流程都没有意义，只能白白占用网络资源。从old AMF获取UE Context或者执行AUSF鉴权都是这个目的；

（2）后面要介绍的步骤3a，UDM的选择只有SUPI一个选择因子，如果UE没有被网络认可得不到SUPI；

（3）从UDM获取签约数据，一定要是网络鉴权通过的用户，否则任何AMF岂不是都可以到UDM中获取数据。另外，到UDM中获取签约数据的URI也需要SUPI作为参数。

1.2.4.3a UDM选择

详见1.1.2.13章节。UDM的选择需要利用NRF。

1.2.4.3b Nudm_SDM_Get(Slice Selection Subscription data)

消息方向：初始AMF - >UDM

切片选择签约数据就是1.1.2.14b章节介绍的切片签约数据。

需要注意的是网络切片NSSAI签约数据，是在AMF注册前查询，用于辅助网络选择的签约数据。其它的签约数据都是在注册后查询才有意义，如果考试，这可能就是一个考点。

1.2.4.3c Nudm_SDM_Get response

消息方向：UDM - >初始AMF

详见1.1.2.14b章节介绍的切片数据。

1.2.4.4a Nnssf_NSSelection_Get

AMF和NSSF之间的接口为N22。

该步骤用于NSSF向AMF提供Allowed NSSAI和Configured NSSAI等信息。需要注意的是AMF向NSSF发消息是根据本地的配置找到的NSSF，而不是像SMF、UDM等是通过查询NRF发现的。

获取切片信息的资源URI：

{apiRoot}/nnssf-nsselection/{apiVersion}/network-slice-information

该请求消息没有消息体，只有HTTP请求的查询参数。

我们先看一下GET请求能够得到哪些信息，后面会详细介绍相关各个信息：

（1）切片选择信息

包括allowedNSSAI、ConfiguredNSSAI、目标AMFSet或者候选AMF列表，及其它可选的信息，如下：

- Allowed NSSAI和Configured NSSAI的映射；

- Allowed NSSAI的网络切片实例（Network Slice instances）ID（NSI ID）；

- 用于执行网络切片实例（NSI）选择的NRF及用于确定AMFSet中的目标候选AMF列表NRF；

- 注册请求RequestedNSSAI中被NSSF拒绝的S-NSSAI。

（2）PDU Session Establishment流程中，用于执行会话切片关联的NFs/services服务发现的NRF。

（3）HPLMN和VPLMN之间的切片映射信息。

下面介绍HTTP请求的查询参数，即上图问号后面的<query parameters>，具体信息详见下图：

重点IE介绍：

- nf-type

消费者的NF类型。在本流程中即初始AMF的NF类型。NF类型基本就是网元类型。常见的比如AMF、SMF、UDM等，后续陆续会有UCMF（UE无线能力管理的网元）、MME、HSS、PCSCF、ICSCF、SCSCF、NSSAAF等

- nf-id

AMF的NF ID，即：AMF的UUID（UniversallyUnique Identifier）。5GC中采用的是UUIDversion 4。

- slice-info-request-for-registration

注册流程或者4G到5G基于N26接口的切换流程中需要包含该IE。其中包含的具体信息如下图，一部分信息是从UE的注册请求中获取的，一部分是UE的签约数据。其中：

- subscribedNssai：除了包含SubscribedNSSAI列表，还包含default S-NSSAI指示；

- sNssaiForMapping：在下面的requestMapping设置为True的情况下会包含该IE，其中包含的S-NSSAI是HPLMN，即归属网络的切片。

- mappingOfNssai：VPLMN到HPLMN的映射。

其它的IE比较好理解，就不具体介绍了。

- slice-info-request-for-pdu-session

PDU Session建立过程中包含的切片请求信息，内容相对简单。只包含：

- S-NSSAI（必选IE）：会话请求建立的S-NSSAI，具体的设置方法，我们在UE Policy中已经介绍过，详见章节1.1.2.21b。

当UE在漫游场景时，对于归属地漫游的PDUSession建立请求，vNSSF查询hNSSF时，包含的应该是归属地的S-NSSAI。原因比较好理解，假如UE处在漫游地，发了一个只在漫游地使用S-NSSAI，归属地根本不识别。此时就会用到下面的homeSnssai IE。

- roamingIndication（必选IE）：漫游指示。指示UE的漫游状态：NON_ROAMING、LOCAL_BREAKOUT、HOME_ROUTED_ROAMING。

- homeSnssai（可选IE）：归属地漫游时，PDUSession建立场景使用。

- slice-info-request-for-ue-cu

UE Configuration Update流程中使用的信息，和slice-info-request-for-registration包含的内容差不多，只是不包含：sNssaiForMapping和requestMapping。

该IE的适用场景比较好理解，当用户UDM中签约的切片发生改变时（比如用户在营业厅变更了签约切片）导致的UE重新注册，就会涉及到这部分信息的获取。

home-plmn-id和tai比较好理解，就不介绍了。

1.2.4.4b Nnssf_NSSelection_Get response

NSSF可能的响应消息如下：

如果NSSF查询成功，返回：200 OK消息。消息体中包含的就是AuthorizedNetworkSliceInformation，具体内容如下：

从上面的返回信息，可以看到allowedNssaiList、configuredNssai、nsiInformation、supportedFeatures、nrfAmfSetNfMgtUri是条件可选IE，其它都是可选IE。

重点IE介绍：

- allowedNssaiList

NSSF收到Requested NSSAI和subscribed S-NSSAI(s)，或者请求消息中"requestMapping" IE设置为true时，返回消息中包含该IE。

- configuredNssai

NSSF没有收到Requested NSSAI、或者Requested NSSAI包含的个别S-NSSAI无效、或者"defaultConfiguredSnssaiInd"设置为"true"时，返回消息包含该IE。如果"requestMapping"设置为true时不能包含该IE，也就是和上面的allowedNssaiList是互斥的关系。

- targetAmfSet

请求消息中包含RequestedNSSAI和Subscribed S-NSSAI时可能包含该IE。之后，AMF使用目标AMF Set查询NRF进行目标AMF的发现。

如果请求消息中包含"requestMapping"，则不能包含该IE。

- candidateAmfList

该IE是NfInstanceId的形式，即：UUID的格式ID，而不是AMF的名字。请求消息中包含Requested NSSAI和SubscribedS-NSSAI时可能包含该IE。同样，如果请求消息中包含"requestMapping"，则不能包含该IE。

- nsiInformation

PDU Session建立过程中，如果NSSF收到了S-NSSAI，返回消息需要包含该IE。

同样，如果请求消息中包含"requestMapping"，则不能包含该IE。

- supportedFeatures

当网络支持额外的网络特性，即NSSF返回307或者308响应，需要重定向请求时会包含该IE。

目前基本不会用到，除非将来5G应用场景非常多，很多定制化需求时可能会用到。

- nrfAmfSet

当包含targetAmfSet IE时，就可能要包含该IE，代表NRF NFDiscovery Service的URI。这样初始AMF使用该URI就可以直接发现候选AMF。

注：

在这我们不禁会想到一个问题，目前网络中AMF本地都会定义NRF的地址信息，如果NSSF在响应中也返回了NRF的地址，那么，这两个NRF地址哪个优先级更高呢？按照规范中优先级相关的定义章节来看，一般在信令携带的信息和网元本地配置的信息都存在时，信令携带的信息优先级要更高一些。这样，在gNB多家运营商共享，真挚个别专用网络共享基站场景下，NSSF利用该IE可能还会将UE引导到指定专网上进行注册，非常适合垂直行业的专网应用。

- nrfAmfSetNfMgtUri

如果上面nrfAmfSet IE存在时，就需要包含该IE，内容是NRF NFManagement Service的URI。

- targetAmfServiceSet

目标AMF Service的集合，也需要像AMF Set一样，需要执行NRF发现才能获得目标AMF信息。

如果NSSF没有找到可用的切片，NSSF可能就会返回403 Forbidden，包含"SNSSAI_NOT_SUPPORTED"错误原因。

1.2.4.5 Namf_Communication_RegistrationStatusUpdate

此时初始AMF发送给old AMF携带的原因值："NOT_TRANSFERRED"，表示UE还没有注册成功，需要old AMF继续保留UE Context。详见章节1.1.2.10。