麦峰强1

5G注册流程详解

1.1 注册流程

1.1.1 专享篇

UE发送Registration Request到(R)AN，消息中包含注册类型、用户标识、UE能力及请求的切片等参数。
(R)AN接收到消息，根据用户临时标识或切片选择合适的AMF，如果(R)AN找不到合适的AMF，则将Registration Request发送给缺省AMF，由缺省AMF进行AMF重新选择流程。
(R)AN将Registration Request消息转发给AMF。
如果Registration Request中携带的是5G-GUTI，AMF发现不是自己分配的，则会向调用Old AMF，请求用户的上下文。
Old AMF响应New AMF，返回用户上下文信息。
如果UE没有提供SUPI，也没有从Old AMF处获取到SUPI，AMF向UE发送Identity Request消息请求获取SUCI。
UE向AMF返回Identity Response消息，消息中包含SUCI。
AMF根据SUPI或者SUCI选择一个AUSF，进行用户鉴权。
AUSF执行对UE的鉴权过程。
用户新注册AMF发生改变，则New AMF发送Namf_Communication_RegistrationStatusUpdate消息给Old AMF。

11．AMF向UE发送Identity Request消息，请求获取PEI。UE向AMF返回Identity Response消息。

12．AMF向EIR发起PEI检查过程，EIR向AMF返回检查结果响应。

New AMF根据SUPI选择UDM。

14a-c. AMF需要向UDM注册并获取签约数据，并订阅签约数据变更通知。

14d.New AMF向UDM注册成功后，UDM向Old AMF发送Nudm_UECM_DeregistrationNotify通知，携带通知原因值。

14e.Old AMF向UDM取消签约数据订阅。

15．如果AMF需要执行接入策略，则选择一个PCF。

16．New AMF和PCF进行接入策略交互。

17．如果AMF改变或UE的PDU Session Status与AMF保存的不一致，AMF更新SMF中会话上下文。

18、19. 国内部署不涉及。

21．New AMF向UE发送Registration Accept消息，接受UE发起的注册请求。如果New AMF为UE分配了新的5G-GUTI，一起下发。

21b. 如果UE请求了UE策略，则AMF需要和PCF执行UE策略交互。

22．如果AMF为UE分配了新的5G-GUTI，则UE向New AMF发送Registration Complete消息。

1.1.2 优享篇

1.1.2.1 UE发送Registration Request到(R)AN

该步骤涉及UE和gNB之间Uu接口信令交互。gNB在UE和AMF之间充当NAS信令网关的作用，NAS信令在gNB中透明转发，gNB不需要理解NAS信令的内容。Uu接口的信令协议栈（从上往下）：RRC/PDCP/RLC/MAC/PHY。

1.1.2.1.1 RRC层介绍

UE在发送Registration Request消息之前需要和gNB先建立RRC连接。

UE和gNB之间在发送Registration Request消息过程中共涉及到三条RRC信令交互。具体流程如下：

1.1.2.1.1.1 RRCSetupRequest

该消息用于建立RRC连接，包括SRB1的建立。处于RRC-IDLE状态下的UE需要转变为RRC-CONNECTED状态时发起该过程，如：呼叫、响应寻呼等。UE发送完该消息后，仍然可以继续进行小区重选测量及小区重选评估，如果条件满足，执行小区重选流程。

该消息承载在SRB0上。RRCSetupRequest消息的定义如下：

其中：

` - InitialUE-Identity字段

UE的NAS层提供给RRC层的信息。如果上层提供了5G-S-TMSI（共48bit），则设置ng-5G-S-TMSI-Part1为5G-S-TMSI的最右侧39bit，否则设置为39bit的随机数值（注：网络上有些文档写的是40bit，经查询最新的TS 38.331-g20版本应该为39bit）。

5G-S-TMSI也在寻呼和Service Request流程中使用，可以提高效率。

` - EstablishmentCause字段

该字段的取值为mo-SMS、mo-Signalling等值，可用的取值详见上图。

1.1.3.1.1.1 RRCSetup

该消息用于建立SRB1，其承载在SRB0上。gNB收到RRCSetupRequest消息，则为UE创建UE Context，并执行SRB1的准入和资源分配。如果允许建立SRB1，则在RRCSetup消息中携带SRB1的完整配置信息发送给UE。UE收到该消息后进入RRC_CONNECTED状态，并停止小区重选。

RRCSetup消息的定义如下：

其中：

` - RRC-TransactionIdentifier字段

该消息相比RRCSetupRequest增加了RRC-TransactionIdentifier标识，其与消息类型一起用于识别一个RRC流程（transaction）（取值范围0-3）

`- RadioBearerConfig字段

携带建立SRB1的配置信息，其中srb-Identity的取值为1，表示建立SRB1。在RRC Setup中只允许对SRB1进行配置。

1.1.3.1.1.1 RRCSetupComplete

该消息用于UE确认已经成功完成RRC连接的建立，其承载在SRB1上。UE收到RRCSetup消息后根据其中的radioBearerConfig进行无线承载配置。

其中：

-  ng-5G-S-TMSI-Part2
复制代码

`设置为5G-S-TMSI 最左面9 bit。如果gNB在RRCSetupComplete消息中的ng-5G-S-TMSI-Value字段得到的不是完整的NG-5G-S-TMSI，则利用RRCSetupRequest消息中提供右侧39bit和RRCSetupComplete消息中提供最左面9bit，合并成一个完整的NG-5G-S-TMSI。

从RRCSetupComplete消息的定义中可以看到，ng-5G-S-TMSI-Part2字段有两个选项，既可以是ng-5G-S-TMSI也可以是ng-5G-S-TMSI-Part2。如果上层提供了5G-S-TMSI，且UE收到了RRCSetup消息，则设置ng-5G-S-TMSI-Value为ng-5G-S-TMSI-Part2，否则设置ng-5G-S-TMSI;`

-  guami-Type

用于指示GUAMI是从原生5G-GUTI导出的（native取值），还是从EPS GUTI导出的（mapped取值）。

-  registeredAMF
复制代码

UE注册的GUAMI信息，用于gNB路由Registration Request消息。

UE的NAS层提供给RRC层5G-S-TMSI或者GUAMI的规则如下：

· 如果UE使用了SUCI标识进行注册，则不应该再包含任何GUAMI信息；

· 如果是CONFIGURATION UPDATE COMMAND消息要求的注册流程，则不应该提供5G-S-TMSI或者GUAMI

注：

CONFIGURATION UPDATE COMMAND消息可能会改变UE的切片，如果切片变化了，原来的AMF可能已经无法为UE服务了。如果RRC消息又包含了5G-S-TMSI或者GUAMI，gNB把注册消息路由回了原来的AMF，相当于白忙活了，所以此地不能再提供5G-S-TMSI或者GUAMI）。NAS层提供GUAMI的使用场景是Non-3GPP场景，用于N3IWF、 TNGF、W-AGF选择AMF。

· 如果UE没有5G-GUTI，但是有EPS的4G-GUTI，且注册原因是由于RAT改变引起的，则将4G-GUTI映射成5G-GUTI，之后根据映射的5G-GUTI提供GUAMI，并指示该GUAMI是从EPS映射过来的。

如果当前小区在RA中，则提供5G-S-TMSI，不提供GUAMI；
如果当前的小区不在RA中，则提供GUAMI，不提供5G-S-TMSI；

注：

UE不在RA（即：TA List）中了，说明UE可能已经不在当前的AMF POOL了，提供5G-S-TMSI已经没有任何意义。因为5G-S-TMSI有一部分可以用于计算寻呼。为了避免gNB实现时出错，所以干脆直接就不提供5G-S-TMSI。

如果UE既没有5G-GUTI也没有4G-GUTI，则都不提供。
selectedPLMN-Identity

该值包含的并不是完整的PLMN ID信息，而是SIB1广播的PLMN ID列表的索引。

DedicatedNAS-Message

该消息中的DedicatedNAS-Message只用于传输initial NAS message。在3GPP中，初始NAS消息共定义了4种，分别是：Registration Request、Deregistration Request、 Service Request及Control Plane Service Request。注册流程中的第一条Registration Request消息就包含在该字段中发送给gNB。

注：

在RRC规范的定义中，还有一条ULInformationTransfer消息用于上行NAS信令的传输，该消息一般需要在SRB2建立之后才能用于上行NAS消息传递。如果SRB2还没有建立也可以承载在SRB1上。

从网上搜到的UE侧的信令截图可以看出Registration Request并没有使用ULInformationTransfer进行传述：

s-NSSAI-List

如果UE的NAS层提供提供了一个或者多个S-NSSAI，则设置该值。该值的设置与Access Stratum Connection Establishment NSSAI Inclusion Mode参数相关，而该参数包含在REGISTRATION ACCEPT消息中。

如果新买的手机，UE中没有保存Access Stratum Connection Establishment NSSAI Inclusion Mode参数时，UE可以不提供S-NSSAI。

如果UE中保存有Access Stratum Connection Establishment NSSAI Inclusion Mode参数，UE可以提供requested NSSAI或者allowed NSSAI。具体提供的是requested NSSAI还是allowed NSSAI，与Access Stratum Connection Establishment NSSAI Inclusion Mode参数采用的是哪个模式相关。这里仅以中国移动的路由组织规范推荐的mode B说明。

Mode B 定义的两个场景：****

（1）由业务请求（Service Request）引起的连接建立，允许UE包含触发连接的各个S-NSSAI；

（2）在周期性注册更新（Periodic Registration Update）、更新UE能力的注册流程中的连接建立，允许UE包含Allowed NSSAI。

UE的NAS层提供给RRC层NSSAI的准则相对比较容易理解，如果UE有Allowed NSSAI，则优先提供Allowed NSSAI。如果UE的Allowed NSSAI在后续流程中可能引起改变时，则提供Request NSSAI。具体规则如下：

· 初始注册时，提供的是Requested NSSAI；

注册请求为移动性注册，且不是由改变5GMM能力、或者改变S1 UE网络能力，或者UE在5GMM-IDLE空闲模式下更新无线能力触发的注册请求时（如TA改变、切片改变、请求LADN信息等），提供Requested NSSAI；
注册请求为移动性注册，且是由改变5GMM能力、或者改变S1 UE网络能力，或者UE在5GMM-IDLE空闲模式下更新无线能力触发的注册请求时，提供Allowed NSSAI；
周期性注册时，提供的是Allowed NSSAI；

业务请求（Service Request）时，如果PDU Session已经有了用户面资源，只是进行重建，则使用重建PDU Session连接的所有NSSAI。或者触发业务请求，需要进行控制面交互的NSSAI。

1.1.2.1.1 NAS层介绍

NAS层包含Registration Request消息。3GPP R16中共定义了29个IE，我们先来看Registration Request消息的定义，包含的内容非常多，这里仅截图部分信息：

重点IE介绍：

5GS Registration type

5G中，共有四种注册类型：

1 ） 初始注册（ Initial Registration ）

UE开机时，处于RM-DEREGISTERED状态发起的注册流程。

2 ） 移动性注册（ Mobility Registration Update ）

UE发起移动性注册的场景：

（1）进入到不在TA List的新TA

（2）更新UE能力及协议参数（和TA是否改变无关）；

（3）请求改变NSSAI信息；

（4）（R16新增）UE的Preferred Network Behaviour改变，和AMF当前支持的Supported Network Behaviour参数不兼容。

3 ） 周期性注册（ Periodic Registration Update ）

UE的T3512超时发起的注册流程。

4 ） 紧急注册（ Emergency Registration ）

紧急注册国内未开启。

在该IE中还有一个重要的指示，当UE没有需要激活的PDU Session或者UE进行紧急注册，而此时，UE还有上行信令需要发送时需要设置该值，即：需要在该5GS Registration type IE中设置"Follow-on request pending"。

- 5GS mobile identity

该IE中包含SUCI或5G-GUTI或PEI。注册中UE携带的用户标识，按下列优先级逐次降低提供相应的标识：

1）从EPS GUTI映射来的5G-GUTI；

2）当前UE正在注册的PLMN分配的native 5G-GUTI；

3）对等PLMN网络分配的native 5G-GUTI；

4）其它PLMN分配的5G-GUTI；

5）其它情况，UE提供SUCI进行注册。

如果UE既有有效的EPS GUTI又有5G-GUTI，则原来的5G-GUTI会放在Additional GUTI字段中。如果有多个native 5G-GUTI，按照上面UE标识的选择顺序，选择最高优先级的标识。

紧急注册时，可以使用PEI进行注册，这里不进行介绍。

- [Requested NSSAI]

该参数为可选参数，Registration Request中不包含该参数的场景有：

1）如果UE没有allowed NSSAI 、configured NSSAI、default configured NSSAI，则UE不包含requested NSSAI；

2）如果UE想要注册的所有S-NSSAI(s) 都在pending NSSAI中，则UE不包含requested NSSAI。

Registration Request中，该参数的来源有：

1） Default Configurated NSSAI：UE既没有Configured NSSAI，又没有Allowed NSSAI时使用。Default Configurated NSSAI作为用户的签约数据，保存到UDR中，只有一个；

2）Configured NSSAI或者下述3）、4）情况的子集；

3）Allowed NSSAI或者它的子集；

4）Allowed NSSAI或者它的子集，加上一个或者多个不包含在Allowed NSSAI中的Configured NSSAI。在确定下来这些计划注册的NSSAI后，UE还需要根据URSP中的NSSP和本地配置来最终确定Requested NSSAI，具体细则详见后续详解部分。

[Last visited registered TAI]

UE之前本地保存的TAI。UE发送该IE的作用是：如果AMF注册成功，在下发Registration Accept消息时，如果TAI和原来的相同，则不必在Registration Accept消息中包含TAI。

UE的初始注册、移动性注册和周期性注册，Registration Accept消息都可能包含有UE注册的TAI。

- [Network slicing indication]

如果UE使用Default Configurated NSSAI进行注册，则需要包含该字段，在其中指示“Requested NSSAI created from default configured NSSAI”。

- [5GMM capability]

该IE中常用的能力信息有：

1）UE是否支持EPC NAS，即UE是否支持EPC网络功能（S1 mode supported）；

2）NG-RAN到UTRAN的5G-SRVCC能力信息；

R16版本的3GPP已经对从5G到3G的SRVCC功能进行了明确。如果UE支持该功能，则指示 "5G-SRVCC from NG-RAN to UTRAN supported"，并且还需包含Mobile station classmark 2 IE和Supported codecs IE。

3）Radio capability signalling optimisation (RACS)能力支持信息。该功能的使用需要在网络中增加部署UCMF网元实例；

4）网络切片的认证和授权（Network Slice-Specific Authentication and Authorization）能力信息，即NSSAA。

- [5GS update type]

该IE中常用的能力信息有：

1）UE的SMS over NAS支持情况；

2）UE radio capability更新指示；

UE Radio Capability包含包含RAT相关的信息，如UE支持的power class, frequency bands等。AMF会保存该参数内容。如果该参数在AMF中可用，AMF会通过N2消息发送给RAN保存。如果UE的状态变为RM-DEREGISTERED，则AMF需要删除该参数。如果发送给RAN的N2请求不包含该参数，RAN自身也没有该参数信息，则会触发RAN向UE索取该参数信息并通过N2 UE RADIO CAPABILITY INFO INDICATION消息上传给AMF。如果UE在CM-IDLE状态时，该参数改变了，需要执行Mobility Registration Update。如果UE在CM-CONNECTED状态，该参数改变，UE需要先变为CM-IDLE状态，之后再执行移动性注册。这部分的流程，在后续会进行介绍。

- [ 5GS及EPS Preferred CIoT network behaviour信息]

该参数会影响物联网设备Registration Request请求消息从一个AMF到另一个AMF的重路由。

- [PDU session status]

指示UE在当前PLMN以前建立的PDU Session。PDU Session ID由UE进行分配，取值范围为1-15，0保留不用。该IE适用于移动性注册或者周期性注册。

[Allowed PDU session status]

如果UE从非3GPP接入类型收到寻呼消息，UE应该在注册请求中包含该IE，用于指示网络UE允许通过3GPP接入类型重新建立用户面资源。

- [Uplink data status]

该IE适用于移动性注册或周期性注册流程。如果UE需要发送上行数据，则需要包含该字段。如果UE有always-on PDU Session，即使没有数据发送，也需要包含在该参数中。但是建立always-on PDU Session的场景是在5G SM流程中，PDU SESSION ESTABLISHMENT REQUEST消息中包含Always-on PDU session requested IE

该IE指示网络哪一个保留的PDU Session有挂起的数据需要发送，对应的比特位设置为1。如果没有数据需要发送、或者PDU Session处于INACTIVE状态、或者PDU Session处于激活状态但是用户面资源已经建立起来了，则相应的比特位设置为0。PDU session status指示出哪些PDU Session是非ACTIVE或者INACTIVE。

- [Payload container]、[Payload container type]

如果UE有保存的UE policy sections（UE策略可以使用一个或者多个UE policy section），UE需要设置Payload container type IE为"UE policy container" ，并在Payload container IE中包含UE STATE INDICATION消息。网络收到该消息后，会执行UE Configuration Update流程下发新的UE策略。

下面看一下UE STATE INDICATION消息的内容：

其它可以包含在的负荷类型有：

当负荷类型为SMS时，payload container IE的内容为SMS的内容，包括：CP-DATA, CP-ACK or CP-ERROR（详见3GPP TS 24.011）

- [NAS message container]

该字段存在的先决条件如下，这三条需要同时满足才能包含该字段：

1） Registration Request作为初始NAS消息；

2） UE存在有效的5G NAS安全上下文；

3） UE有需要密文发送的内容。

在没有NAS安全上下文的情况下，UE可以明文发送的内容有：

1） Extended protocol discriminator;

2） Security header type;

3） Spare half octet;

4） Registration request message identity;

5） 5GS registration type;

6） ngKSI;

7） 5GS mobile identity;

8） UE security capability;

9） Additional GUTI;

10） UE status

11） EPS NAS message container.

注：****

Registration Request本身就是一条NAS层的消息，但在该条消息中又包含一个[NAS message container] IE，规范对该IE的解释为：The purpose of the NAS message container IE is to encapsulate a plain 5GS NAS REGISTRATION REQUEST or SERVICE REQUEST message, or to encapsulate non-cleartext IEs of a CONTROL PLANE SERVICE REQUEST message. 那么这个NAS message container和UE构建的Registration Request消息有什么区别？

经过仔细查询，答案是：该IE用来封装不允许明文发送的部分内容，将其打包在了[NAS message container] IE中。

在TS 24.501中，解释plain 5GS NAS message为非加密的明文消息，加密的5GS NAS MESSAGE （SECURITY PROTECTED 5GS NAS MESSAGE）不是plain 5GS NAS messages。

5G之所以在NAS层的Registration request消息中又包含了一个[NAS Container]，是因为5G系统支持初始NAS消息的保护（初始NAS消息包含REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST）。如果AMF收到了包含NAS Container的信息，AMF优先处理container中的REGISTRATION REQUEST消息。

经过查看现网信令[NAS message container]中既包含可以明文传递的部分，又包含不允许明文传递的部分，即[NAS message container]中包含完整的注册消息的全部字段。而Registration Request这条NAS消息的[NAS message container]外部只包含可以明文传递的部分，两者部分内容是重复的。

1.1.2.2 AMF选择

gNB收到RRCSetupComplete消息，根据RRC层包含5G-S-TMSI或GUAMI来对NAS消息进行路由。AMF选择的具体的规则如下：

1）如果UE既没有提供GUAMI或5G-S-TMSI，又没有提供NSSAI信息（如：UE使用SUCI进行注册），则gNB根据RAT类型将Registration Request消息路由到default AMF；

2）如果UE提供了GUAMI或5G-S-TMSI，也提供NSSAI信息，如果gNB根据GUAMI或5G-S-TMSI能匹配到合适的AMF，则将Registration Request消息路由到该AMF；如果根据GUAMI或5G-S-TMSI没有匹配到合适的AMF，根据NSSAI信息选择一个AMF，将注册消息路由到该AMF；

3）如果消息中UE只提供了NSSAI信息，则根据NSSAI信息选择AMF，并将注册消息路由到该AMF。

4）其它匹配不到合适AMF的情况，根据RAT路由到default AMF。

注：****

3GPP TS 23.501和中国移动的5G路由组织规范，在AMF选择部分都使用了Requested NSSAI作为AMF选择的参数。从上面介绍的RRC信令交互部分的内容和Uu接口协议栈可以知道，在这里使用Requested NSSAI，个人感觉并不准确。因为Requested NSSAI是NAS消息层的概念，gNB并不理解NAS消息的内容，根本无法使用NAS消息中包含的内容。gNB能够利用的只有UE的NAS层传递给RRC层的NSSAI信息，而RRC层的NSSAI信息可以是Requested NSSAI也可以是Allowed NSSAI。

1.1.2.3 gNB转发Registration Request消息给AMF

gNB选择完AMF后，向AMF发送INITIAL UE MESSAGE（初始N2消息）。为该UE分配一个唯一的RAN UE NGAP ID，也包含在INITIAL UE MESSAGE消息中。gNB从选择的AMF，且该AMF可用的TNL associations中，选择一个可以用于发送初始消息的TNL associations（TNL Association的权重因子为0的，不能用于初始N2消息的发送），为该UE创建NGAP UE-TNLA-binding，并通过选定的TNL association转发该UE的消息到AMF。

TNL Association应该就是SCTP层的Association，第一个TNL Association在gNB上电后，根据配置的IP地址和端口号与AMF建立Association，后续如果需要增加TNL Association时，AMF需要向5G-AN发送AMF CONFIGURATION UPDATE消息，该消息中包含增加TNL Association的IP地址和端口号。TNL Association最多可以创建32个。

INITIAL UE MESSAGE只用于发送上行的第一条NAS消息。后续的NAS消息使用UPLINK NAS TRANSPORT。既然两条消息都用于传输上行NAS消息，为什么会有这个区别？我们先来看这两条消息的定义。

INITIAL UE MESSAGE消息的定义：

UPLINK NAS TRANSPORT消息的定义：

从上面两条消息的定义可以看出来INITIAL UE MESSAGE只需要包含gNB本侧的RAN UE NGAP ID，而UPLINK NAS TRANSPORT需要知道gNB和AMF两侧的UE NGAP ID才能进行通信，这个两个字段又都是必选字段。所以3GPP定义了两条消息。在gNB和AMF之间第一回合的交互中，互相知道了对方的UE NGAP ID后才能使用UPLINK NAS TRANSPORT消息传递NAS消息。对于传输下行NAS消息的DOWNLINK NAS TRANSPORT不存在这样的问题，因为gNB发送完第一条INITIAL UE MESSAGE消息后已经将本侧的RAN UE NGAP ID带给了AMF。

注：**** * 在INITIAL UE MESSAGE消息中还包含Allowed NSSAI IE，规范的解释：If the Allowed NSSAI IE is included in the INITIAL UE MESSAGE message the AMF shall use the IE as defined in TS 23.502 [10].，但是在TS 23.502中并没有明确指出该IE的使用场景。那么什么情况下会在INITIAL UE MESSAGE消息中包含Allowed NSSAI呢？按正常的逻辑，Allowed NSSAI是在注册请求完成后，AMF下发给UE的Registration Accept才会有Allowed NSSAI，而这里在初始N2消息中就包含Allowed NSSAI，相当奇怪了。*

经过仔细查找，发现在注册过程中如果AMF出现重选的场景下，如果需要RAN转发初始注册请求可能会在INITIAL UE MESSAGE中出现Allowed NSSAI。初始AMF和UDM、NSSF已经交互完成得到了切片相关的信息，此时如果初始AMF不能为UE服务，而目标AMF和初始AMF不在同一个AMF Set，此时可能就需要RAN（gNB）转发注册请求。AMF发送Reroute NAS Request消息给gNB，gNB发现在该消息中存在Allowed NSSAI，会在发送给目标AMF的Initial UE Message消息中包含Allowed NSSAI IE和Source to Target AMF Information Reroute IE。

1.1.2.3 gNB转发Registration Request消息给AMF

INITIAL UE MESSAGE消息的定义：

UPLINK NAS TRANSPORT消息的定义：

注：****

*在INITIAL UE MESSAGE消息中还包含Allowed NSSAI IE，规范的解释：If the Allowed NSSAI IE is included in the INITIAL UE MESSAGE message the AMF shall use the IE as defined in TS 23.502 [10].，但是在TS 23.502中并没有明确指出该IE的使用场景。那么什么情况下会在INITIAL UE MESSAGE消息中包含Allowed NSSAI呢？按正常的逻辑，Allowed NSSAI是在注册请求完成后，AMF下发给UE的Registration Accept才会有Allowed NSSAI，而这里在初始N2消息中就包含Allowed NSSAI，相当奇怪了。

1.1.2.4 Namf_Communication_UEContextTransfer

new AMF调用old AMF的服务获取UE上下文信息。

如果UE的Registration Request消息携带5G-GUTI进行注册，并且AMF发生了变化，此时新的AMF（new AMF）会向UE原来注册的AMF（old AMF）请求UE上下文信息，包含SUPI、GPSI、5GMM Capability等参数（UE上下文的内容详见TS 23.502）。

new AMF采用POST方法调用old AMF的Namf_Communication_UEContextTransfer服务。具体使用的URI格式为：

{apiRoot}/namf-comm//ue-contexts/{ueContextId}/transfer

调用该服务携带的请求消息内容为：UeContextTransferReqData。

注：

*（1）通用的URI结构为：

*{*apiRoot}///

*（*2）对于SBI接口采用POST方法还是PUT方法的区别

服务的生产者选择资源的标识符和URI，则采用POST方法；服务的消费者选择资源的标识符和URI，则采用PUT方法。*

下面看一下该POST请求的URI参数

{apiRoot}

该字段和我们日常上网，在IE地址栏中输入的内容一样，以http或者https开头的地址，后面是IP地址和端口号等信息；

namf-comm

AMF上用于信息传递的API名称。其它API名字为："namf-mt"、"namf-loc"、"namf-evts"

目前在R16版本中全部为“v1”，后续如果有大的功能变更，可能会有更新的版本。

ue-contexts

请求UE Context的固定值。

{ueContextId}

请求的UE Context的标识，可以为5G-GUTI、SUPI或者PEI，使用的格式如下：

（1）5G-GUTI：5g-guti-[0-9]{5,6}[0-9a-fA-F]{14}

（2）SUPI：(imsi-[0-9]{5,15}|nai-.+|.+)

（3）(imei-[0-9]{15}|imeisv-[0-9]{16}|.+)

3GPP使用正则表达式进行描述，我们只需要知道对应的标记（5g-guti、imsi、nai、imei、imeisv）加上短横线，再加上具体的值即可。IMEI和IMEISV用于紧急注册，目前在国内不会遇到。我们能够遇到的基本都是5g-guti或者imsi。

transfer

传递已经存在的UE Context释放的方法。其它的可能方法有：transfer-update（后续流程中Namf_Communication_RegistrationStatusUpdate消息使用的就是该方法）、release、assign-ebi。

该URI请求的内容（UeContextTransferReqData）

SBI接口的消息内容采用JSON编码。Namf_Communication_UEContextTransfer消息的请求内容定义如下：

reason

可选的取值为："INIT_REG"、"MOBI_REG"、"MOBI_REG_UE_VALIDATED"。

当UE执行初始注册时取值为："INIT_REG"；

当UE执行移动性注册时取值为："MOBI_REG"；

当首次获取UE Context失败，AMF和AUSF执行UE鉴权成功后，再次获取UE Context时，使用"MOBI_REG_UE_VALIDATED"。

accessType

可选的取值为："3GPP_ACCESS"或者"NON_3GPP_ACCESS"。

[plmnId]

即：MCC和MNC。

[regRequest]

注册流程的完整Registration Request消息，包含在该参数中。

[supportedFeatures]

特性支持相关的字符串。

我们先来看一下new AMF调用该操作的处理过程

（1）对于初始注册和移动性注册，如果有5G-GUTI，第一次向old AMF请求获取UE上下文的输入参数为：5G-GUTI、Access Type、Reason和完整的Registration Request。AMF返回的信息如下：

A．如果注册原因为"INIT_REG"并且old AMF执行完整性检查成功，则返回不包含PDU Session信息的UE上下文。如果old AMF根据new AMF的PLMN ID判断，不能将N2接口重定位到new AMF，则只返回supi（跨PLMN的情况）；

B．如果注册类型为"MOBI_REG"并且old AMF执行完整性检查成功，返回200 OK消息，包含完整的UE Context（含有PDU Session信息）。

（2）如果第一次old AMF完整性检查失败（返回给new AMF的响应为：403 Forbidden，携带原因值：“INTEGRITY_CHECK_FAIL”），UE和AUSF鉴权成功后，再次向old AMF请求UE Context的消息和第一次请求的消息略有不同，三个不同点如下：

A．第二次{ueContextId}的取值为SUPI。因为在UE和AUSF的鉴权流程中，new AMF已经得到了SUPI，所以第二次直接携带SUPI请求UE Context；

B．第二次“reason”的取值为"MOBI_REG_UE_VALIDATED"；

C．第二次消息中不包含Registration Request消息，也就是不包含[regRequest]参数。

old AMF在处理该请求时会跳过完整性检查，直接回复“200 OK "，并携带完整的UE上下文（包含PDU Session相关的信息）。

1.1.2.5 Namf_Communication_UEContextTransfer Response

（1）成功响应

如果old AMF处理成功，在Namf_Communication_UEContextTransfer Response消息中返回200 OK 响应，并携带UE Context。响应消息的消息体包含的内容为UeContextTransferRspData，该数据类型定义如下：

（2）响应失败

A． 403 Forbidden

如果old AMF对请求消息中的Registration Request消息完整性检查失败，则设置原因值：“INTEGRITY_CHECK_FAIL”。

B． 404 Not Found

如果old AMF没有找到对应的UE Context则返回该响应，并设置原因值为“CONTEXT_NOT_FOUND”

获取 UE Context 流程中的注意点：****

l 如果在切换流程中，new AMF已经从old AMF中获取到了UE，则在注册流程中就不需要向old AMF重新获取了，即在注册流程中的第4，5，10步骤都不需要执行。

l 如果old AMF有不同于当前accessType的PDU Session，AMF判断该PDU Session无法重定位到新的AMF，则AMF只返回SUPI，并指示消息已经经过完整性验证，不包含UE Context的其他部分（SUPI包含在UeContext数据类型中）。

l 跨PLMN移动的时候，UE Context中的信息包含的是HPLMN S-NSSAI的信息（可以对应到Allowed NSSAI的S-NSSAI），而不是old PLMN的Allowed S-NSSAI。

l UE注册到新的AMF后，不需要重新订阅事件，因为UEContext中包含事件订阅的信息。如下：

1.1.2.6 Identity Request

如果在Registration Request中UE没有提供SUCI，则AMF向UE发送Identity Request消息，请求获取UE的SUCI。

注：

*在TS 23.502规范中，注册流程该步骤的解释为：If the SUCI is not provided by the UE nor retrieved from the old AMF the Identity Request procedure is initiated by AMF sending an Identity Request message to the UE requesting the SUCI.

“UE从old AMF没有获取到SUCI”，也是发送Identity Request消息的前提。但是我们在UE Context的定义中并没有发现SUCI字段，也就是UE Context并不保存UE的SUCI。另外，从Namf_Communication_UEContextTransfer Request的响应中可以知道，要么成功响应返回SUPI，要么获取失败返回403 Forbidden或者404 Not Found，此时，new AMF什么都不会得到。

根据TS 33.501章节6.1.2：The SEAF shall include the SUPI in the Nausf_UEAuthentication_Authenticate Request message in case the SEAF has a valid 5G-GUTI and re-authenticates the UE. Otherwise the SUCI is included in Nausf_UEAuthentication_Authenticate Request.* *可以知道，主鉴权流程使用的参数要么是SUCI，要么是SUPI。

个人判断，TS 23.502此处编写有误，new AMF从old AMF得到SUCI的场景是不存在的，只能得到SUPI。SUCI是SIM或者ME计算得到的，每次计算的值都不一样，AMF也没有必要保存SUCI。*

NAS消息Identity Request消息的定义如下：

该消息中重点关注的字段为Identity Type，该字段指明了AMF请求的是哪一个5GS标识。可以请求的5GS标识如下图，最后一句话很重要：所有不能识别的标识都认为是SUCI。

该NAS消息承载在AMF和gNB之间的DOWNLINK NAS TRANSPORT（N2接口消息）消息中发送给gNB，之后gNB将NAS消息承载在RRC层的DLInformationTransfer消息中发送给UE。

DLInformationTransfer消息承载在SRB2（在SRB2未建立时也可以使用SRB1）中（逻辑信道DCCH）。

1.1.2.7 Identity Response

UE向AMF回复Identity Response消息。

该NAS消息中的重点字段为：Mobile identity。UE可以发送SUCI、5G-GUTI、IMEI、IMEISV、5G-S-TMSI、MAC地址或者EUI-64作为5GS mobile identity。

该NAS消息在UE和gNB间承载在RRC层的ULInformationTransfer消息中。

ULInformationTransfer消息承载在SRB2（在SRB2未建立时也可以使用SRB1）中（逻辑信道DCCH）。

gNB收到Identity Response消息后，封装在Uplink NAS Transport（N2接口消息）消息中发送给AMF。

RRC层消息DLInformationTransfer和ULInformationTransfer用于在UE处于RRC-CONNECTED状态时传递NAS消息。

1.1.2.8 AUSF选择

在AMF从UE得到SUCI或者从old AMF得到SUPI后，通过NRF执行服务发现，选择AUSF执行鉴权流程。

1.1.2.9 Authentication/Security流程。

1.1.2.9.0 准备知识

该步骤为UE的5G鉴权流程，本文以目前使用的5G AKA鉴权方式为例介绍。5G AKA相比4G增加了归属网络的鉴权功能。4G的鉴权由MME完成，而5G的鉴权由AMF和AUSF共同完成，并且5G的鉴权向量不支持预取，也不支持一次获取多组鉴权向量。

归属网络的AUSF提供鉴权过程的锚点密钥（anchor key）KSEAF，它是由加密保存在AUSF中的中间密钥Kausf计算得到的。5G中，锚点密钥和和服务网络（Serving Network）进行绑定，向UE提供隐式的服务网络认证。绑定的方式是将5G SN名称作为密钥推导的输入参数。

1.1.2.9.0.1 5G SNN（Serving Network Name）

5G SNN 的作用：

· 用于推导锚点密钥，作为AUSF推导Kseaf的输入参数，及作为UE推导RES和XRES的输入参数；

· 将锚点密钥和服务网络绑定；

· 通过将服务码（Service code）设置为“5G”来保证锚点密钥用于5G核心网和UE之间的鉴权认证。

5G SNN 的构成：

SNN最长1020个字节，由两部分构成：SNN-service-code和SNN-network-identifier，中间用冒号“:”进行连接。

由于在认证和鉴权过程中，安全密钥需要在UE和SEAF（位于AMF中）中分别推导，因此，SNN作为密钥推导的输入参数，需要在UE和SEAF分别进行构造。

· SNN-service-code：固定为“5G”。在通过non-3GPP接入时，也用于区分接入网络，作为Access Network Identity使用；

· SNN-network-identifier：用于识别当前的移动网络。根据TS 24.501章节9.12.1规定，对于PLMN网络，该值为：mncXXX.mccXXX.3gppnetwork.org（都为小写字母）。对应中国移动的5G网络SNN-network-identifier为：mnc000.mcc460.3gppnetwork.org。

UE侧根据RAT、USIM卡中的信息及小区广播的PLMN等信息可以很容易推导出SNN，进而用于安全密钥的推导；而AMF侧根据配置信息也可以构造出SNN，用于鉴权和认证。

1.1.2.9.0.2 鉴权流程的触发条件

通常，与UE建立信令连接的流程都可以触发鉴权流程。我们常见到的场景为：

· UE使用SUCI发起注册流程；

· AMF没有UE的有效上下文；

· Registration Request消息没有被完整性保护；

· UE携带5G-GUTI注册，但是old AMF对注册请求消息执行完整性检查失败；

1.1.2.9.1 鉴权流程

本部分的鉴权流程分成三个部分：

A．鉴权流程（请求阶段）

B．鉴权流程（响应阶段）

C．鉴权流程（鉴权确认和注册绑定部分）

1.1.2.9.1.1 鉴权流程（请求阶段）

（1 ）Nausf_UEAuthentication_Authenticate Request****

消息方向：AMF/SEAF -> AUSF

HTTP方法：POST

在整体注册流程的第8步中，AMF根据从UE得到的SUCI或者从old AMF得到的SUPI，选择对该UE进行鉴权的AUSF，构造Nausf_UEAuthentication_Authenticate Request消息并发送给该AUSF。

该请求的资源URI为：

{apiRoot}/nausf-auth/v1/ue-authentications

携带的参数类型为：AuthenticationInfo，具体的字段信息如下图，我们常见到的IE为SUPI或者SUCI，及SNN：

只要AMF得到了UE的SUPI，在Nausf_UEAuthentication_Authenticate Request消息中包括的都是SUPI，除非AMF不知道UE的SUPI，才会在该消息中包含SUCI。

AUSF收到请求消息后，会检查消息中的Serving Network Name是否得到了授权。如果检查失败，则返回：403 Forbidden，携带的原因值为：SERVING_NETWORK_NOT_AUTHORIZED。

（2 ）Nudm_UEAuthentication_Get Request

HTTP方法：POST

消息方向：AUSF -> UDM

该请求的资源URI为：

{apiRoot}/nudm-ueau/v1/{supiOrSuci}/security-information/ generate-auth-data

该消息用于AUSF请求UDM为UE选择一种鉴权方法，并且，如果本次鉴权需要鉴权向量，还会请求UDM计算新的鉴权向量。如果请求中包含的是SUCI，UDM收到该请求后，首先，SIDF将SUCI解密为SUPI，之后根据SUPI为UE选择鉴权方式。目前，5G使用的鉴权方式有两种：EAP-AKA’ 和5G AKA。

请求消息AuthenticationInfoRequest的内容如下图：

重点信息介绍：

ResynchronizationInfo

该字段包含两项内容：rand和auts。在鉴权重同步过程中，AUTS由UE计算得到。

1.1.2.9.1.2 鉴权流程（响应阶段）

（ 1） UDM生成鉴权向量****

UDM/ARPF在生成鉴权向量时，需要将Authentication Management Field (AMF)的separation bit设置为"1"。separation bit为AUTN中AMF字段的第0比特，该值为1表示生成的鉴权向量用于EPS/5G AKA鉴权；如果设置为0，标识该鉴权向量用于GSM、UMTS等非EPS/5G AKA鉴权（具体原理详见TS33.102，6.4.3章节及附录F）。对于鉴权向量来讲，如果设置为1，AKA鉴权过程中产生的CK和IK鉴权密钥不会离开HSS。

UDM/ARPF推导出 KAUSF并计算XRES*（在推导Kausf和XRES时都会将serving network name作为输入参数使用）。最后UDM/ARPF生成的5G HE AV包含RAND、AUTN、XRES、KAUSF四个参数。（其中鉴权令牌AUTN = SQN Å AK || AMF || MAC）。

（2 ）Nudm_UEAuthentication_Get Response****

消息方向：UDM -> AUSF

· 成功响应

返回200 OK响应。UDM计算出5G HE AV（RAND、AUTN、XRES*、KAUSF），并在响应消息中返回给AUSF。携带AuthenticationInfoResult内容。

该响应消息包含AuthenticationInfoResult，具体内容如下：

supi

如果请求消息中是SUCI，UDM会使用SIDF解密出SUPI并在该字段中返回给AUSF。

authType

AUSF根据该字段为UE开启"5G_AKA"鉴权流程或者"EAP_AKA_PRIME"鉴权流程。

选择的鉴权类型共有三个取值："EAP_AKA_PRIME"、"5G_AKA"和"EAP_TLS"，其中，"EAP_TLS" 3GPP标准并不强制要求支持。

AuthenticationVector

鉴权向量包含的内容如下：

其中：

avType

取值两种："5G_HE_AKA"和"EAP_AKA_PRIME"。

rand

共128比特，16字节。

autn

共128比特，16字节。AUTN的构成(SQN xor AK)||AMF||MAC，共48+16+64 bits。

· 失败响应

403 Forbidden

可能的原因值为：AUTHENTICATION_REJECTED、INVALID_HN_PUBLIC_KEY_IDENTIFIER、INVALID_SCHEME_OUTPUT

404 Not Found

如果用户没有开户，则携带原因值：USER_NOT_FOUND

501 Not Implemented

原因值：UNSUPPORTED_PROTECTION_SCHEME。

（3 ）AUSF 保存XRES*

AUSF临时保存响应消息中的XRES*和SUPI，用于归属地的鉴权比较。

注：

在TS33.501中，该步骤的解释为：“The AUSF shall store the XRES temporarily together with the received SUCI or SUPI.”。也就是说本步骤，AUSF也可能保存SUCI。不知道在什么场景下会出现AUSF临时保存SUCI？从上述Nudm_UEAuthentication_Get Response成功的200 OK响应AuthenticationInfoResult内容来看，并没有定义SUCI字段。在失败响应中，只有403 Forbidden，原因值：INVALID_SCHEME_OUTPUT，表示无法解密SUCI，也没有带回SUCI。怀疑3GPP该步骤的解释应该为编写错误。*

（4 ）AUSF 计算XRES*****

AUSF根据接收到的5G HE AV（RAND、AUTN、XRES*、KAUSF）来计算5G AV（RAND、AUTN、HXRES*、KSEAF）；根据XRES计算出HXRES；根据KAUSF计算出KSEAF（计算KSEAF仍然需要serving network name作为输入参数）。锚点密钥Kseaf此时诞生。

（5 ）Nausf_UEAuthentication_Authenticate Response****

消息方向：AUSF -> AMF/SEAF

AUSF 删除KSEAF，并在Nausf_UEAuthentication_Authenticate Response消息中向AMF返回5G SE AV (RAND, AUTN, HXRES*) 。

从上述可见，AUSF产生的5G AV并没有直接发送给AMF，而是分两步发送：第一步，发送5G SE AV用于拜访地鉴权；第二步，如果拜访地鉴权成功，返回RES*，归属地鉴权成功后，将锚点密钥Kseaf发送给AMF，此时才将完整的5G AV发送给了AMF。

该Response的内容如下：

消息IE介绍：

authType

指示UE本次鉴权网络选择的鉴权方法，共有三个取值："EAP_AKA_PRIME"、"5G_AKA"和"EAP_TLS"。

_links

该字段包含本次鉴权UE返回RES后，AMF向归属地返回RES时需要调用的AUSF的资源URI。如果是5G AKA，该字段的值为“5g-aka”和执行鉴权确认的超链接URI，如http://172.16.141.122:8080/nausf-auth/v1/ue-authentications/06120902071/5g-aka-confirmation。如果是EAP鉴权，该字段的值为："eap-session"及执行EAP Session的URI。

5gAuthData

包含上一步骤的5G SE AV (RAND, AUTN, HXRES*)。

（6 ）Authentication Request （NAS 消息）****

消息方向：AMF/SEAF -> UE

AMF/SEAF保存接收到的HXRES*，并向UE发送Authentication Request消息，启动T3560计时器，消息中包含RAND、AUTN、ngKSI、ABBA等参数。ME转发接收到的Authentication Request消息中的RAND和AUTN 给USIM。

5G AKA流程都是由网络发起的，UE可以拒绝网络发起的鉴权请求。

Authentication Request消息包含在N2接口的Downlink NAS Transport和Uu接口的RRC层DLInformationTransfer消息中发送给UE。

Authentication Request消息定义：

消息IE介绍：

ngKSI

ngKSI是由SEAF生成的，取值范围0-6（3bit）（7保留）。如果UE发送给网络的ngKSI=7，表示没有密钥可用。ngKSI用于在UE和AMF中识别Kamf。在后续鉴权成功后，用于识别5G安全上下文。如果在初始NAS消息（Registration Request消息）中包含了ngKSI，AMF需要在Authentication Request中分配一个不同的ngKSI。

ABBA

ABBA参数为保持前向兼容，其长度可变，在R16版本中，长度为2个字节，值规定为：0x0000，用于推导Kamf作为输入参数。该参数用于防止降级攻击。

Authentication parameter RAND/ Authentication parameter AUTN

均为从AUSF收到的数据。

EAP message

对于5G AKA鉴权，不包含该IE。

注：****

百度百科上的降级保护内容，供参阅：降级攻击（Downgrade attack）是一种对计算机系统或通讯协议的攻击。在降级攻击中，攻击者故意使系统放弃新式、安全性高的工作方式（如加密连接），反而使用为向下兼容而准备的老式、安全性差的工作方式（如明文通讯）。例如，在OpenSSL中曾经存在一个缺陷，从而使攻击者能够让SSL/TLS服务器与客户端创建老版本TLS连接，尽管双方事实上支持新版本。这样的攻击是最常见的降级攻击。

（7 ）UE 计算RES*****

USIM收到RAND和AUTN，需要先检查AUTN中的MAC区域，验证接收的AUTN新鲜度。验证通过后，USIM计算RES，并和CK、IK一起返回给ME。如果USIM 根据CK和IK计算出了Kc (如GPRS Kc) 也发给了ME，则ME忽略该值，在USIM和ME上都不保存该值。之后，ME根据收到的RES计算RES*（serving network name、RAND等作为输入参数）。ME根据CK||IK 、serving network name 及AUTN中的SQN Å AK 计算出KAUSF，进而计算出 KSEAF （serving network name作为输入参数）。最后，ME检查AUTN的AMF域的"separation bit"是否为1。

（8 ）Authentication Response （NAS 消息）****

消息方向： UE -> AMF/SEAF

UE构造Authentication Response消息发送给AMF/SEAF。AMF/SEAF收到Authentication Response消息后停止T3560计时器。

Authentication Response消息包含在Uu接口RRC层的ULInformationTransfer消息和N2接口的Uplink NAS Transport消息中发送给AMF/SEAF。

Authentication Response消息定义：

消息IE介绍：

Authentication response parameter

该参数为UE计算的RES*。（在5G AKA中，RES*由ME计算得到，16字节长度，在4G中，RES由USIM计算得到，最短4字节，最长16字节。）

（9 ）AMF/SEAF 计算HRES*****

AMF/SEAF根据UE发送的RES计算出HRES （输入参数有RES*、RAND等），SEAF比较HRES和HXRES，如果二者一致，则认为UE在当前的拜访网络鉴权成功。之后，执行第10步，通过Nausf_UEAuthentication_Authenticate Request消息将RES*发送给AUSF进行归属地鉴权。

如果HRES和HXRES不一致，则认为UE在拜访网络鉴权失败，仍然会继续执行第10步，只是此时不携带RES*，而是携带空值，以通知AUSF在拜访地鉴权失败。

如果此时UE不可达，SEAF不会收到RES* ，则SEAF认为本次鉴权失败，并通知AUSF。

注：

网络上及个别厂家文档写到：如果拜访网络鉴权失败，流程结束。该说法并不准确，即使拜访网络鉴权失败，仍然会通知归属地AUSF。

如果在后面第12步中AUSF返回给SEAF鉴权结果Nausf_UEAuthentication_Authenticate Response消息中，指示RES在归属地鉴权失败，或者RES在拜访网络的SEAF中鉴权失败，则认为UE本次鉴权失败。如果UE使用SUCI发起的注册请求，则SEAF向UE发送UE Authentication Reject消息；如果UE使用的5G-GUTI发起的注册请求，AMF会尝试向UE请求SUCI再次进行鉴权尝试。如果最终UE鉴权失败，会收到Authentication Reject消息。

在UE侧，如果UE对Authentication Reject消息完整性检查通过，UE会设置update status为5U3 ROAMING NOT ALLOWED，并删除保存的5G-GUTI、TAI list、last visited registered TAI和ngKSI。在UE关机或者USIM卡更换之前不会再进行重新注册。如果Authentication Reject完整性检查失败，在30分钟到60分钟之间，会再次发起注册。

（10 ）Nausf_UEAuthentication_Authenticate Request****

消息方向： AMF/SEAF -> AUSF

HTTP方法：PUT（注意：EAP鉴权方式时本步骤为POST方法）

该请求消息调用AUSF的资源URI:

{apiRoot}/nausf-auth/v1/ue-authentications/{authCtxId}/5g-aka-confirmation

该URI在第5步的响应消息_links字段携带，也可以由AMF自行构造。如果构造的不准确，则会返回响应消息：404 Not Found，携带原因值：CONTEXT_NOT_FOUND，表示AUSF没有找到对应的资源URI。

该消息携带的确认数据只有ConfirmationData，包含：RES*。但是该值也有为空的情况，表示通知AUSF拜访地鉴权失败。具体场景如下：

UE不可达的情况，AMF不会收到RES*；
拜访地鉴权失败AMF比较HRES和HXRES不一致；
AMF收到UE的authentication failure消息，如：synchronization failure或者MAC failure。

（11 ）AUSF 验证RES*

AUSF收到RES后，首先验证5G AV是否过期。如果5G AV过期了，则认为归属网络鉴权失败。如果5G AV验证不超期，AUSF加密保存Kausf。之后，AUSF比较接收到的 RES和保存的XRES*是否一致，如果一致，AUSF认为归属网络鉴权成功，并通知UDM鉴权结果，之后开启C. 鉴权确认和注册绑定流程。

（12 ）Nausf_UEAuthentication_Authenticate Response****

消息方向： AUSF -> AMF/SEAF

如果AUSF鉴权成功，则向AMF/SEAF返回200 OK响应，携带ConfirmationDataResponse信息，具体内容如下：

消息IE介绍：

authResult

该IE共有三个可选值：

AUTHENTICATION_SUCCESS：归属地鉴权成功
AUTHENTICATION_FAILURE：归属地鉴权失败
AUTHENTICATION_ONGOING：表示EAP Session鉴权正在进行，目前不涉及。
supi/kseaf

从整个流程中可以看到，只有当归属地鉴权成功后，AMF才能得到解密后的SUPI和锚点Kseaf。拜访网络在得到SUPI之前，不能使用任何网络服务。之后SEAF根据Kseaf、ABBA参数和SUPI推导出Kamf，并和ngKSI一起发送给AMF。

1.1.2.9.2.3 鉴权流程（鉴权确认和注册绑定部分）

该步骤主要用于防止AMF的虚假注册，如UE所处拜访网络没有的AMF，却发起了Nudm_UECM_Registration_Request，导致UE注册在了一个不存在的AMF上。

（1 ）Nudm_UEAuthentication_ResultConfirmation Request****

消息方向：AUSF -> UDM

HTTP方法：POST

该请求消息的资源URI如下：

{apiRoot}/nudm-ueau/v1/{supi}/auth-events

资源URI中包含SUPI，消息体仅包含AuthEvent参数，内容如下：

消息IE介绍：

nfInstanceId

执行鉴权的NF instance （如AUSF）。

success

该值为布尔类型，true表示AUSF鉴权成功，false 表示鉴权不成功。false值也用于AUSF请求UDM删除鉴权结果。

authRemovalInd

可选项，用于指示UDM中的鉴权结果是否删除，true表示删除。默认值为false。

（2 ）UDM 保存AuthEvent 相关信息

UDM保存UE的鉴权状态，如SUPI、鉴权结果、时间戳、serving network name等。

（3 ）Nudm_UEAuthentication_ResultConfirmation Response****

消息方向：UDM -> AUSF

· 成功响应

返回201 Created，消息体可以为空。如果不为空，则返回AuthEvent内容。HTTP消息头的Location字段包含创建的资源，URI如下：

{apiRoot}/nudm-ueau/v1/{supi}/auth-events/{authEventId}

· 失败响应

404 Not Found，原因值：USER_NOT_FOUND。

（ 4） UDM对后续流程的鉴权****

如果UDM收到了UE的后续流程，如：AMF发送的Nudm_UECM_Registration_Request消息，UDM会根据运营商策略执行相关检测和保护操作（详见TS 33.501，3GPP仅提供了建议操作）。

1.1.2.9.2 重新执行获取UE Context

如果在new AMF对UE成功鉴权，如果在第5步中由于完整性检查失败，获取UE context不成功导致发起的鉴权。鉴权完成后，此时需要重新执行第4步，重新获取ue context。具体内容详见1.1.2.4章节的叙述。

1.1.2.9.3 5G密钥相关推导图

1.1.2.9.3.1 5GS密钥推导图（TS 33.501）

1.1.2.9.3.2 5GS密钥分布及生成模式图（TS 33.501）

1.1.2.9.3.3 UDM鉴权向量推导图（TS 33.102）

1.1.2.9.3.4 UE鉴权推导图（TS 33.102）

1.1.2.9.4 5G NAS安全模式的启用

new AMF对UE成功鉴权后，如果第5步中由于完整性检查失败导致获取UE context不成功，此时需要重新执行第4步（Namf_Communication_UEContextTransfer），从old AMF获取UE context，此时请求消息携带的原因值为："MOBI_REG_UE_VALIDATED"。old AMF收到消息后，发现是该原因值，则不进行完整性检查直接返回完整UE Context（包括PDU Session信息）。

在本步骤上半部分的叙述中，AUSF和AMF均鉴权成功后，AMF才会收到锚点密钥Kseaf和SUPI。从上面的密钥推导图可以看出来，AMF会从Kseaf推导出Kamf（Kamf保存在5G NAS security context中），之后再推导出NAS层、RRC层及UP（用户面）的加密和完整性保护密钥。

我们先来看NAS层加密和完整性功能的开启过程。RRC层加密和完整性功能的开启我们在核心网信令交互完成后发送给UE注册结果时再进行讨论。

在UE鉴权流程完成之后，AMF拿到了密钥，完成了AMF中5G NAS security context 的创建，下一步需要完成UE中5G NAS security context 的创建，两侧安全上下文全部创建完成后之后，UE和AMF之间的加密和完整性保护才能激活。5G NAS security context参数保存在USIM卡中，如果USIM中没有对应的保存文件，则要保存在ME的非易失性的存储器中。

注：

UE的鉴权流程场景可以创建5G NAS security context，在N1间切换、N1和S1间的切换场景也可以完成5G NAS security context的创建。5G NAS security context包括KAMF及相关的密钥标识、UE security capabilities、上下行NAS COUNT值。

1.1.2.9.4.1 NAS消息完整性保护要点说明

我们先来看一下5G NAS消息的完整性保护相关的要点：

l 如果UE本地没有5G NAS security context的情况，UE执行注册流程时，发送的Registration Request消息可以不进行加密和完整性保护。只要UE本地存在有效的5G NAS security context，3GPP规范强制要求UE对NAS消息进行完整性保护。

l 当发送的NAS消息既需要加密又需要执行完整性保护时，NAS消息首先进行加密，之后加密的NAS消息和NAS序列号一起进行完整性保护，计算MAC；

l NAS消息可以只进行完整性保护而不加密。未加密的NAS消息和NAS序列号一起进行完整性保护，计算MAC；

l 当UE处于5GMM-IDLE模式要建立NAS信令连接时，如果本地有有效的5G NAS security context时，发送初始NAS消息时，会包含NAS key set identifier IE （其中含有ngKSI值），用于指示当前使用的用于进行NAS完整性保护的5G NAS security context。AMF收到初始NAS消息时会检查其中包含的ngKSI值指向的AMF本地的5G NAS security context是否可用，并验证NAS消息的MAC。如果验证成功，则AMF和UE之间可以进行安全的NAS消息交互。

l 如果选择5G-IA0（空算法，即："null integrity protection algorithm"，相当于没有进行完整性保护）作为完整性保护的算法，在NAS消息的安全头（Security header type）指示为完整性保护消息，则NAS消息的接收方仍然认为该消息是完整性保护的消息。如果NAS消息使用5G-EA0（即："null ciphering algorithm" ）算法加密，在NAS消息的安全头部指示为加密保护消息，则仍然认为NAS消息是加密的。

1.1.2.9.4.2 NAS消息的加密要点说明

下面再看一下UE发送Registration Request消息时，是否有5G NAS security context在消息加密方面的要点。在3GPP文档中，该部分内容有两个名词：cleartext和non-cleartext，经过前后对比，cleartext理解为“允许明码发送”，non-cleartext理解为“需要加密发送”比较合适。

l UE没有有效的5G NAS security context

则只能发送包含cleartext IE初始NAS消息（即：只包含在第1步中介绍的允许明文发送的字段）。也就是说发送的Registration Request消息不包含NAS message container IE。在本步中，完成UE鉴权流程后，会将完整的Registration Request消息（包含cleartext和non-cleartext的内容）包含在NAS SECURITY MODE COMPLETE消息中的NAS message container IE中重新发送。如果UE没有non-cleartext发送的内容，则NAS SECURITY MODE COMPLETE消息的NAS message container IE中只包含cleartext内容。

l UE有有效的5G NAS security context

A. 如果UE有需要non-cleartext发送的信息，则需要将cleartext和non-cleartext的内容完整包含在Registration Request的NAS message container IE中，并将该NAS message container IE进行加密。之后发送Registration Request消息，该消息包含cleartext和non-cleartext内容的NAS message container IE（即：包含完整的注册请求消息）。

注：

本步涉及的初始NAS消息有三种：REGISTRATION REQUEST，SERVICE REQUEST，CONTROL PLANE SERVICE REQUEST。每种消息类型包含的可以cleartext发送的IE都不一样，具体参见：TS 24.501。物联网应用场景中，CONTROL PLANE SERVICE REQUEST发送会涉及CIoT small data container IE的处理，需要注意。

B. 如果UE没有non-cleartext发送的信息，则不包含NAS message container IE。

需要注意的是上面的规则适用于UE发起的第一条初始NAS消息，如果是UE收到NAS Security Mode Command后，包含在NAS Security Mode Complete消息里的NAS message container IE中完整的Registration Request消息是不需要加密的。（详见TS 24.501 Clause 5.4.2.3）

注：****

如果UE具有5G NAS security context，但是其中包含的加密算法为：5G-EA0。此时，当UE在5GMM-IDLE状态选择了一个不同于以前注册的PLMN时，UE会放弃该5G NAS security context不使用。

AMF在收到这些包含[NAS message container] IE的初始NAS消息，会优先处理NAS message container IE中的内容。由于NAS message container IE是加密保护的，如果AMF本地没有UE的有效上下文，或者从old AMF得到的UE上下文中的安全参数无法解密，或者old AMF完整性检查失败等等，只要任何一步出现问题都会触发AMF和AUSF之间的UE鉴权流程。

注：**** * 在第1步流程中我们的疑问，在本步骤的学习中得到了解答。以前觉得学明白了，在细致整理的时候仍然会发现一些未知的问题。5G系统之所以在NAS消息Registration Request中又包含了一个[NAS message container]，主要是因为5G系统支持初始消息的保护。*

从现网跟踪到的信令来看，信令内容[NAS message container]中既包含cleartext的部分，又包含non-cleartext部分，即[NAS message container]中包含完整的注册消息的全部字段。而Registration Request这条NAS消息[NAS message container]外部只包含cleartext部分，与[NAS message container]中部分内容是重复的。

网络是否开启加密由AMF配置决定，如果不开启加密功能，AMF会在所有UE的5G NAS security context 指示采用"null ciphering algorithm" 5G-EA0算法。

当建立起N1 NAS安全交互的信令连接后，UE会开启NAS消息的加密和解密功能。之后除非明确定义，在N1 NAS信令连接释放或者执行S1切换之前，UE会将所有发送的NAS消息加密。AMF除了NAS SECURITY MODE COMMAND消息，也会在N1 NAS信令连接释放或者执行S1切换之前开启加密和解密功能。

一旦在AMF和UE间开启了NAS消息加密，NAS消息的接收方会丢弃所有未加密的NAS消息。

1.1.2.9.4.3 5G初始NAS消息保护机制

对于UE发送的Registration Request，如果没有进行完整性保护（UE本地没有5G NAS security context场景），AMF会继续处理该NAS消息。如果Registration Request消息进行了保护，但是使用AMF本地5G NAS security context执行MAC完整性校验失败或者无法校验时，AMF仍然会处理Registration Request消息。这样就保证了不论UE移动到何处，发送的注册请求是否有保护或者保护的密钥参数不对，AMF都会处理Registration Request消息，尽可能为UE提供网络服务。

Step 1：如果UE发送初始NAS消息给AMF。如果UE没有NAS Security context，初始NAS消息值包含cleartext IE，如：SUCI或者GUTI、UE security capabilities、ngKSI等。如果UE有NAS Security context，初始NAS消息会包含cleartext和non-cleartext信息，加密部分的信息在NAS container中。因为UE有NAS安全上下文，所以发送的消息是经过加密和完整性保护的。如果NAS消息被保护了，且AMF具有相同的安全上下文（如：UE在同一AMF再次注册的场景），Step 2到4可以忽略，此时AMF可以解密使用NAS container中完整的初始NAS消息。

Step 2：如果AMF本地和之前注册的AMF（old AMF）中没有找到安全上下文或者完整性检查失败，AMF会触发UE鉴权流程Step 2b。如果从old AMF获取到UE context，其中的安全参数可以解密NAS container中的内容，则Step2b到4可以忽略。

Step 3：如果UE鉴权成功，AMF会发送NAS Security Mode Command消息给UE。如果UE之前发送的初始NAS消息无法使用（如：NAS container无法解密或者完整性校验不通过等）。AMF会设置标记，要求在UE发送的NAS Security Mode Complete消息中包含完整的初始NAS消息。

Step4：UE发送NAS Security Mode Complete消息给AMF，该消息是加密并完整性保护的消息。

Step 5：AMF发送初始NAS消息的回复，该消息是加密及完整性保护的。

1.1.2.9.4.4 5G NAS安全模式的开启

1a. AMF在发送NAS Security Mode Command 消息之前，首先激活NAS完整性保护功能。

1b. AMF通过发送NAS Security Mode Command消息启动NAS安全模式控制流程（NAS security mode control procedure），并开启定时器T3560。AMF重置下行NAS COUNT计数器（用于推导密钥及完整性保护的输入参数），并使用它进行NAS SECURITY MODE COMMAND消息的完整性保护。AMF发送NAS Security Mode Command 消息不进行加密，但是需要使用该消息中的ngKSI指示的Kamf进行完整性保护，并设置security header type为"integrity protected with new 5G NAS security context"。

如果之前的Registration Request消息由于AMF中完整性校验失败或者解密NAS message container IE不成功，AMF会在NAS Security Mode Command消息中包含Additional 5G security information IE，并设置RINMR比特位为："Retransmission of the initial NAS message requested"，请求UE在发送NAS Security Mode Complete消息时包含完整的Registration Request消息。Security Mode Command消息的定义如下图：

重点IE介绍：

Security header type

NAS消息保护性说明。其中：0011用于NAS Security Mode Command消息。0100用于NAS Security Mode Complete消息。

Selected NAS security algorithms

指示网络选择的加密和完整性保护算法。UE发送的Registration Request消息中UE security capability IE包含UE支持的算法，AMF根据UE和自身的支持情况选择合适的加密算法。

ngKSI

用于识别5G NAS Security Context中的Kamf。

Replayed UE security capabilities/ Replayed S1 UE security capabilities

UE发送的Registration Request消息中的UE security capability IE，AMF会原封带回。如果UE发现与自己发送的不一致，则会发送SECURITY MODE REJECT消息，携带原因值：#23 UE security capabilities mismatch。

IMEISV request

AMF请求获取UE的IMEISV。

Selected EPS NAS security algorithms

如果网络支持N26接口，并且UE在Registration Request消息中5GMM capability IE设置了S1 mode比特为"S1 mode supported"，则AMF会选择EPS使用的NAS安全算法，用于UE移动到EPS时使用。AMF会将该参数保存在UE Security context中，N2接口的切换或者空闲模式下的移动更新，该参数会被传递到目标AMF。

Additional 5G security information

该参数包含RINMR（是否需要重传初始NAS消息。）和HDP（是否需要推导Kamf）两个重要选项。在移动性注册、周期性注册或者同一PLMN的多注册（3GPP access或non-3GPP access）场景下，需要包含Kamf推导标识。

ABBA

降级攻击保护参数。

1c. AMF在发送完NAS Security Mode Command消息后，激活上行NAS解密功能。

2a. UE验证NAS Security Mode Command消息，包括验证UE发送的UE security capabilities是否遭到修改及使用NAS Security Mode Command消息中ngKSI指示的Kamf，推导密钥及选择的算法进行完整性校验。

如果HDP设置了K_AMF_change_flag ，UE需要推导新的KAMF并设置NAS COUNTs为0。

如果UE验证NAS Security Mode Command消息成功，UE使用ngKSI指示的安全上下文启动NAS消息的加密和完整性保护功能。

2b. UE发送经过加密和完整性保护的NAS NAS Security Mode Complete消息给AMF。消息中可能携带PEI、IMEISV及重传的完整初始NAS消息Registration Request。如果重新推导了Kamf，AMF会设置NAS COUNT为0。

如果UE验证NAS Security Mode Command消息不成功，会回复Security Mode Reject 消息。Security Mode Reject消息及后续的NAS消息仍然会使用之前的5G NAS security context进行加密和完整性保护。如果之前不存在5G NAS security context，NAS Security Mode Reject消息不进行保护。

如果UE发送Security Mode Reject消息后NAS COUNT溢出，则UE会直接释放NAS连接，而不发送Security Mode Reject。

1d. AMF使用在NAS Security Mode Command消息中选择的加密和完整性保护算法和密钥解密，以及校验 NAS Security Mode Complete 消息。AMF收到NAS Security Mode Complete 消息后开启NAS消息的下行加密，并停止计时器T3560。

至此，UE和AMF完成了NAS消息加密和完整性保护功能激活。

一旦UE和AMF之间完成了加密和完整性保护功能激活，所有没有通过完整性检查的NAS消息都会被丢弃，不进行处理。

5G注册过程的鉴权和安全性保护方面到这就介绍完了。在切换过程中也会涉及到安全方面的内容，在详解切换流程时在进行分析。

UE鉴权成功之后，此时还要重新执行第4步和第5步，即章节1.1.2.4和1.1.2.5，重新获取UE的Context。如果new AMF获取到了UE Context，此时new AMF会判断自己能否为UE提供服务，如果不能则需要进行AMF重选流程。如果new AMF没有获取到UE Context，则需要根据SUPI选择UDM，下载切片选择数据，判断自己能否为UE提供服务，如果不能为UE提供服务，则执行AMF重选流程。

1.1.2.10 Namf_Communication_RegistrationStatusUpdate

消息方向：new AMF -> old AMF

HTTP方法：POST

该消息用于正在进行UE注册的new AMF向old AMF更新相应的注册状态,及通知需要释放的PDU Session等信息。

如果第9步UE鉴权失败或者new AMF根据下载的切片选择信息发现自己不能为UE请求的切片提供服务，new AMF需要使用该消息通知old AMF：UE在new AMF注册失败，old AMF需要继续保存该UE的上下文信息。

对于移动性注册流程，如果UE在old AMF的RA（注册区）中可以使用的S-NSSAI，在new AMF的RA中无法支持，则new AMF需要确定该S-NSSAI关联有哪些PDU Session需要释放，之后使用该消息将拒绝的PDU Session ID信息通知old AMF，old AMF调用相应SMF的Nsmf_PDUSession_ReleaseSMContext，将拒绝的PDU Session资源释放。New AMF也会修改该UE的PDU Session Status信息。在整体注册流程完成之后，new AMF使用Registration Accept消息通知UE更新后的PDU Session Status信息。如果UE发现有PDU Session被网络拒绝，就将相应资源释放。

如果new AMF不使用原来UE Policy和AM Policy关联的PCF，也会通知old AMF：new AMF重新选择了新PCF，old AMF需要释放相应的资源。

该请求的资源URI为：

{apiRoot}/namf-comm/v1//ue-contexts/{ueContextId}/transfer-update

携带的参数类型为：UeRegStatusUpdateReqData，具体的字段信息如下图。其中只有tranfserStatus为必选IE，其它均为可选IE。在该消息中需要注意的是{ueContextId}是old AMF分配的5G-GUTI，而不是SUPI，也不是new AMF分配的5G-GUTI。因为在old AMF中，UE Context是使用原来的5G-GUTI来识别的。

重点IE介绍：

transferStatus

该IE取值："TRANSFERRED"或"NOT_TRANSFERRED"。如果取值为："NOT_TRANSFERRED"，标识在new AMF注册没有成功，需要重新选择新的AMF，old AMF需要继续保存该UE的UE Context不要删除。

toReleaseSessionList

某些S-NSSAI在new AMF不能支持，其关联的PDU Session ID在该IE中通知old AMF。

pcfReselectedInd

指示new AMF是否重新选择了PCF，该类型为布尔型，取值true或者false。需要注意的是，不论在非漫游场景或者漫游场景，AMF的AM策略和UE策略都是选择同一个PCF或者V-PCF。SM策略选择的PCF则可能与AM、UE策略不是同一个PCF。

smfChangeInfoList

AMF间注册场景时，如果有I-SMF/V-SMF变化或者删除时，需要通过该IE通知。包含PDU Session ID的列表及对应的I-SMF/V-SMF改变（取值："CHANGED"）或者删除（取值："REMOVED"）。

old AMF收到RegistrationStatusUpdate消息后，如果transferStatus的值为"TRANSFERRED"，old AMF执行的操作如下：

（1）释放toReleaseSessionList IE中的PDU Session；

（2）对UE Context启动预删除计时器。如果在计时器超时前收到了UDM发送的Nudm_UECM_DeregistrationNotify消息，则等待该计时器超时删除UE Context，如果已经超时，则立即删除；

（3）如果pcfReselectedInd取值为TRUE，则old AMF释放和old PCF间的AM和UE策略偶联；

（4）如果消息中包含smfChangeInfoList IE，old AMF会删除I-SMF 或者V-SMF中smfChangeInfoList指示的所有PDU Session的SM Context（会话上下文）信息。

如果RegistrationStatusUpdate消息的transferStatus值为"NOT_TRANSFERRED"，old AMF继续保留UE Context。

消息名称：Namf_Communication_RegistrationStatusUpdate Reponse

消息方向：old AMF -> new AMF

消息属性：响应消息

在3GPP的注册流程图中没有明确画出该消息，实际上Namf_Communication_RegistrationStatusUpdate消息存在响应消息。

· 成功相应（200 OK）

成功相应携带数据类型为：UeRegStatusUpdateRspData，数据类型为布尔型，TRUE表示更新成功，默认为TURE。

· 失败相应

- 307 Temporary Redirect

- 308 Permanent Redirect

- 403 Forbidden

表示old AMF可以正常解析消息，但是由于错误无法执行状态更新操作。

- 404 Not Found

如果old AMF没有找到指定的UE Context，则返回该错误，原因值为：CONTEXT_NOT_FOUND。

注：

该步骤，在3GPP R15的TS 23.502的最后一个版本fb0中，消息名称为：Namf_Communication_RegistrationCompleteNotify，在注册流程图、相应步骤的解释及最后AMF服务化接口操作描述都是该名称。但是在TS 29.518的最后一个版本f40中找不到Namf_Communication_RegistrationCompleteNotify消息，该消息已经使用RegistrationStatusUpdate进行了更新。在3GPP R16版本中，已经全部改正了这些矛盾。目前在网上及个别厂家文档等资料中，该消息名称还没有改正，大家阅读到该步骤时需要注意。

1.1.2.11 Identity Request/Response

消息方向：new AMF < -> UE

该消息和注册流程的第6步相同，不同点是第6步获取UE的SUCI，本步骤获取UE的PEI。另外需要注意的一点是第6步中的消息可能是未执行加密和完整性保护的，而本步骤的请求消息和回复消息都是加密和完整性保护的消息。TS 24.501规定UE的PEI需要加密发送，这样，注册流程中只有在AMF和UE启动完加密流程后才能发送。

注：

RRC层的加密和完整性保护是在INITIAL CONTEXT SETUP REQUEST投入使用的。其它两条可以设置UE安全能力的N2接口消息是：UE CONTEXT MODIFICATION REQUEST和HANDOVER REQUEST（TS 33.501）。

该步骤的执行前提是new AMF从old AMF的UE Context中没有得到UE的PEI，以及UE在注册消息（紧急注册场景会提供UE的PEI）没有发送PEI并且在第9步1.1.2.9章节中Security Mode Complete 消息中也没有携带IMEISV，上面两种情况外，如果网络需要获取UE的PEI就需要执行该步骤。

网络获取UE的PEI的作用有两条：

（1）网络使用EIR对用户的PEI进行校验；

（2）如果UE在注册消息的5GMM capability IE中指示UE支持RACS功能，并且网络开启了RACS 特性，AMF会使用PEI获取IMEI/TAC，用于网络执行RACS操作（涉及UCMF（UE radio Capability Management Function）网络实体）。

从14a步骤中（章节1.1.2.14a）中可以看到Nudm_UECM_Registration Request中PEI是可选字段，也就是说AMF发送给UDM保存PEI是可选的。目前国内也没有部署EIR，理论上获取UE的PEI可选，但运营商一般都会获取UE的PEI用于辅助故障处理，判断是不是某型号的手机缺陷导致的问题。获取的方法通常就是在Security Mode Complete 消息中携带IMEISV，具体介绍详见1.1.2.9.4.4章节“5G NAS安全模式的开启”。对于不需要安全特性开启的场景，比如移动性注册，new AMF从old AMF获取到的安全上下文全部有效，AMF可能会单独使用该流程获取UE的PEI。

如果网络需要使用该步骤获取UE的PEI，Identity Request消息中的Identity Type IE，应该设置为011或者101，表示获取UE的IMEI/IMEISV，详见下图：

初始注册流程中，AMF如果获取了UE的PEI，在后续流程中，AMF会将其发送给UDM（Nudm_UECM_Registration）、SMF和PCF。如果AMF在Nudm_UECM_Registration消息中没有携带PEI，表示AMF没有得到UE最新的PEI，此时UDM需要把本地保存的PEI删掉。

1.1.2.11.1紧急注册扩展知识

在Registration Request消息中不直接包含PEI字段，也就是说在注册流程中，除了紧急注册，AMF都不会从注册消息中直接获得PEI。

紧急注册中，由于在注册消息中已经包含了PEI，不需要使用该步骤再获取UE的PEI。根据TS 23.502，UE在紧急注册中，使用的UE标识的优先级：5G-GUTI、SUCI（SUPI）、PEI。（TS 23.502的原文是：For an Emergency Registration, the SUCI shall be included if the UE does not have a valid 5G-GUTI available; the PEI shall be included when the UE has no SUPI and no valid 5G-GUTI. In other cases, the 5G-GUTI is included and it indicates the last serving AMF. 相应的内容在TS 24.501中也有说明）

如果UE携带5G-GUTI进行紧急注册，AMF不能识别该5G-GUTI的话，也就是该5G-GUTI不是自己分配的，是其它AMF分配的。此时AMF不会向old AMF获取UE Context，而是直接向UE获取SUCI（取值和SUPI相同）。如果UE直接使用PEI发起紧急注册，就不需要获取SUCI了。对于紧急注册，该SUCI要不要鉴权取决于运营商配置，大多情况可能不会鉴权直接进行注册。

在TS 23.502中，该步骤的原文：For an Emergency Registration, if the UE identifies itself with a 5G-GUTI that is not known to the AMF, steps 4 and 5 are skipped and the AMF immediately requests the SUPI from the UE. If the UE identifies itself with PEI, the SUPI request shall be skipped. Allowing Emergency Registration without a user identity is dependent on local regulations. 原文是请求UE的SUPI，经过查询实际上此时并不是真正的SUPI，而是SUCI，只是这个SUCI是使用空加密算法加密（“null-scheme”）的SUPI，取值和SUPI一样。原因详见下面分解。

在TS 24.501中，规范说明了什么情况下，UE会生成不加密的SUCI，即："null-scheme"。此时，SUCI的内容就是SUPI。

翻译过来，UE使用"null-scheme"的具体场景如下：

（1）归属网络没有提供公钥用于UE生成SUCI。比如现在4G使用的USIM卡，本身就不支持加密SUPI（IMSI）；

（2）归属网络为UE配置使用"null-scheme"。比如开户时，在USIM卡中烧录的就是"null-scheme"；

（3）UE没有有效的5G-GUTI，执行了紧急注册或者在紧急注册流程成功执行完之前又触发了去注册流程；

（4）紧急注册流程中UE收到了identity request消息，网络请求获取UE的SUCI，或者UE处于紧急注册流程成功执行完成之前的去注册流程中（后半部分意思和第（3）条其实一样）。

从上面叙述中可以看出来，虽然TS 23.502中介绍在紧急注册中获取UE的SUPI，实际上是未加密的SUCI。

上面的叙述也能证明第14a步骤（章节1.1.2.14a Nudm_UECM_Registration）的“注”中对14a步骤的触发条件做的说明，应该确定为规范编写错误。从14a步骤的上下文中也看不出来是说明的紧急注册场景。

作为扩展再介绍一下5G的R16版本中支持的PEI：

（1）IMEI

（2）IMEISV

（4）48bit的MAC地址

（5）EUI-64（IEEE Extended Unique Identifier）。

1.1.2.12 N5g-eir_EquipmentIdentityCheck_Get

消息方向：AMF -> EIR

HTTP方法：POST

该步骤国内未使用，不进行介绍。

1.1.2.13 UDM选择

在该步骤中，AMF会使用SUPI通过NRF选择UDM。

需要注意的是在第8步中，AMF选择AUSF时可以使用SUCI和SUPI。在本步骤中，不管何种情况，AMF和AUSF已经完成了UE的鉴权流程，AMF一定会获取到UE的SUPI，所以在UDM的选择中，只有一个输入参数就是SUPI。

1.1.2.14 AMF与UDM交互

第14步共有5（14a-e）部分，涉及到new AMF/old AMF和UDM之间的信令交互。下面具体介绍。

1.1.2.14a Nudm_UECM_Registration

消息方向：new AMF -> UDM

HTTP方法：PUT

该Nudm_UECM_Registration操作用于在UDM中保存UE Context Managemen信息。该消息的触发条件有：再次注册时AMF发生改变、UE在AMF的UE上下文无效、UE在同一个AMF注册，但是RAT不同。从触发条件也可以看出来，在周期性注册中是不需要执行Nudm_UECM_Registration操作的。

不仅AMF可以调用该Nudm_UECM_Registration操作，SMF、SMSF、IP-SM-GW均可以进行调用，用于保存各自相关的信息。

注：

在TS23.502中，该步骤的解释有：If the AMF has changed since the last Registration procedure, or if the UE provides a SUPI which doesn't refer to a valid context in the AMF……其中“UE提供的SUPI不能指向有效的上下文”应该是不对的。5G中，不会出现UE给AMF提供SUPI的场景。在Identity Request消息中也没有可以获取SUPI的定义。

资源URI如下：

{apiRoot}/nudm-uecm/v1/{ueId}/registrations/amf-3gpp-access

其中：/{ueId}为用户的SUPI。该消息包含的消息体为Amf3GppAccessRegistration，其内容非常丰富，下面仅截图部分内容，对于其它在IE部分具体介绍。内容如下：

重点IE介绍：

amfInstanceId

AMF在NRF中注册的ID。

deregCallbackUri

UDM向AMF发送UE去注册事件订阅消息的URI，该事件为隐式订阅的。

ratType

AMF向UDM提供接入类型，对于3GPP接入类型，该值为："3GPP access"

-guami

正在执行UE注册的AMF的GUAMI。

imsVoPs

指示AMF下的所有TA对IMS over PS是否是匀质支持的。共有三个取值："HOMOGENEOUS_SUPPORT"、"HOMOGENEOUS_NON_SUPPORT"、"NON_HOMOGENEOUS_OR_UNKNOWN"。

AMF只有在评估完自身对"Homogenous Support of IMS Voice over PS Sessions"支持情况后才可以包含该IE，否则不能包含该IE。后期，当AMF收集到足够的信息可以判断是否支持该功能时，可以使用PATCH方法更新该属性。

initialRegistrationInd

是否是初始注册，如果是初始注册，该IE需要设置为True，否则应设置为False或者不包含该IE。UDM根据该字段来决定是否向之前UE注册的网元发送取消注册信息（Nudm_UECM_DeregistrationNotification）。

epsInterworkingInfo

如果网络支持N26接口的EPS互操作，AMF需要将为DNN选择的PGW-C的FQDN和SMF的标识包含在该IE中发送给UDM。

ueSrvccCapability

该IE标识UE是否支持5G SRVCC。如果设置为True，标识UE和AMF都支持5G SRVCC。如果设置为False或者不包含该IE标识，表示不支持5G SRVCC。当UE的SRVCC能力改变的时候需要包含该IE。需要注意的是在R16版本的3GPP中已经支持5G SRVCC功能，这一点和R15有不同，详见TS23.216。

在本步骤中需要注意的是：整体更新或者创建AMF的注册信息时使用的是PUT方法；修改AMF注册信息使用PATCH（PATCH方法可以更新的信息比较有限，相比PUT方法少很多）；获取AMF注册信息使用GET方法。虽然消息名称、资源URI都相同，但是不同的HTTP方法效果是不一样的。在UDM侧的处理方法也不一样。另外需要注意的一点是，PUT/PATCH方法创建或者修改UE签约数据时，在URI中的{ueId}需要使用SUPI，而GET方法可以使用SUPI或者GPSI。

PATCH可以更新的信息共有6个，具体包含：purgeFlag、pei、imsVoPs、backupAmfInfo、epsInterworkingInfo、ueSrvccCapability。

消息名称：Nudm_UECM_Registration Reponse

消息方向：UDM -> new AMF

消息属性：响应消息

UDM收到Nudm_UECM_Registration消息后，如果UDM中有该UE的注册信息，则使用新接收到的Amf3GppAccessRegistration替换之前的注册信息，并返回：200 OK（消息体包含创建的Amf3GppAccessRegistration内容）或者204 No Context响应。之后UDM调用Nudm_UECM_DeregistrationNotify通知old AMF删除UE Context。UDM调用该服务使用的URI就是前面介绍的deregCallbackUri包含的内容。

如果UDM中之前没有该UE的注册信息，会保存接收到的信息，并返回：201 created响应。返回的内容可能包含UDM自身支持的额外特性信息及创建的Amf3GppAccessRegistration内容。详细信息如下：

注：

在介绍鉴权流程（第9步）C. 鉴权流程（鉴权确认和注册绑定部分）中步骤2：保存了UE鉴权状态。在本步骤中，UDM收到了Nudm_UECM_Registration请求消息，此时UDM需要对该请求进行内部验证，确保不是欺骗性注册，具体的验证内容和设备厂商实现相关，验证通过后才表示UE注册成功。

1.1.2.14b Nudm_SDM_Get

消息方向：new AMF -> UDM

HTTP方法：GET

该消息的触发条件是：AMF中没有该UE的签约数据，或者签约数据不完整，或者签约数据需要更新时会调用该消息（SoR等参数可以设置为要求更新）。

AMF使用Nudm_SDM_Get操作下载UE的签约数据。UE的签约数据有很多，比较重点的有切片选择签约数据、接入和移动性管理签约数据、SMF选择签约数据、会话管理签约数据、SMS签约数据及SMS管理签约数据。除签约数据外，关于SMF、SMSF的UE Context也可以下载，其它还有很多签约数据，详见：TS 29.503，经常翻一下这些签约数据，对理解信令原理有很大的好处，会减少很多疑惑的地方。

该消息调用的URI格式如下，后续以下载切片签约数据为例：

{apiRoot}/nudm-sdm/v2/{supi}/****

其中：{supi}为UE的SUPI，最后的URI变量可以为：nssai、am-data、smf-select-data、sm-data、sms-data、sms-mng-data、ue-context-in-smf-data等。其支持的查询参数有plmn-id和supported-features，查询参数是可选的。如果没有提供plmn-id默认为归属PLMN值，返回UE的HPLMN的Subscribed S-NSSAI；如果提供了plmn-id，则返回该PLMN下的Subscribed S-NSSAI。另一个需要注意的地方是，在获取UE签约数据的URI中，API版本号为v2。

Nudm_SDM_Get的请求消息不包含消息体。其返回的数据为NSSAI类型的数据，具体内容如下：

nssai类型的数据包含defaultSingleNssais、singleNssais、additionalSnssaiData等信息，其中：defaultSingleNssais包含缺省的Subscribed S-NSSAI；singleNssais包含非缺省的Subscribed S-NSSAI；additionalSnssaiData是键值对类型，用于说明每个S-NSSAI是否需要执行Network Slice-Specific Authentication and Authorization流程，默认为false，不需要执行网络切片的鉴权和授权流程。

在众多签约数据中，比较特殊的就是网络切片NSSAI签约数据，它是在AMF注册前查询，用于辅助网络选择的签约数据。4G EPC中，PDN连接建立过程中PGW-C+SMF也需要查询NSSAI签约数据，为UE提供一个S-NSSAI。

下面仅介绍几个重点的签约数据内容：

- 接入和移动性签约数据： 包含gpsis、subscribedUeAmbr、nssai、ratRestrictions、forbiddenAreas 、serviceAreaRestriction、coreNetworkTypeRestrictions 、rfspIndex 、subsRegTimer（周期性注册定时器）、ueUsageType（EPS互操作时用于选择EPC专用核心网）、subscribedDnnList、stnSr、cMsisdn、nssaiInclusionAllowed等；

- SMF 选择签约数据： 包含每个S-NSSAI和DNN信息的关联，DNN信息有缺省的DNN、EPS互操作信息及使用静态IP地址的SMF列表等信息。

- 会话管理签约数据： 包括切片和DNN配置信息（如PDU Session的类型、sscModes、iwkEpsInd、5gQosProfile、sessionAmbr、staticIpAddress等）

- SMS 签约数据： 包括是否允许NAS短信等

- SMS 管理签约数据： 正常的短信业务（非IMS短信，PS网络自身也支持短信业务）数据

- ue-context-in-smf-data 签约数据： 包括PDU Session信息（DNN、切片等信息）和pgwInfo（与EPS互操作是的APN和PGW-C+SMF FQDN等信息）。

注册过程中下载切片数据用于判断当前的AMF是否可以为UE提供服务，如果不能服务会涉及到AMF重选流程，在后面的详解文章中再具体分析。

注册过程中，AMF可以从UDM中可以一次下载多组签约数据，如：AM签约数据、SMF选择签约数据、SMF中UE Context数据、SMS签约数据等，这时候需要使用DataSet的概念。

对应的资源URI（相比前面介绍的，只是没有具体签约数据名字的信息）如下：

{apiRoot}/nudm-sdm//{supi}

此时，需要下载的多个签约数据是包含在GET方法的查询参数中，如下：

{apiRoot}/nudm-sdm/v1/imsi-460000000000000?dataset-names=AM,SMF_SEL,UEC_SMSF,SMS_SUB&plmn-id=***

这些数据集的名字，规范定义如下：

响应消息：

200 OK：包括需要获取的签约数据
404 Not Found：携带可能的原因值：USER_NOT_FOUND、DATA_NOT_FOUND。

1.1.2.14c Nudm_SDM_Subscribe

消息方向：new AMF -> UDM

HTTP方法：POST

该消息可以订阅UE的签约数据变化，包括UE自己的签约数据和可以多个UE公用的共享签约数据部分。

该消息的资源URI如下：

{apiRoot}/nudm-sdm//{ueId}/sdm-subscriptions

其中：{ueId}变量的取值可以为SUPI或者GPSI。

该请求的消息体SdmSubscription，包含callbackReference、monitoredResourceUris、subscriptionId等信息。

重点参数介绍：

callbackReference

由AMF提供给UDM，当签约数据有变化时，UDM调用该URI通知AMF。

monitoredResourceUris

AMF请求监控的UDM资源，即：UE签约数据的资源URI。和AMF下载签约数据的资源URI系统，如：{apiRoot}/nudm-sdm/v1/{ueId}/am-data。

subscriptionId

用于UDM删除订阅时使用。

注：

R16版本中，Nudm_SDM_Subscribe进行了优化，可以在订阅签约数据的同时携带Immediate Report指示，表示同时请求签约数据下载。这样就在一个流程中既订阅了数据，又下载了签约数据。但是该功能需要AMF和UDM都支持才行。

Nudm_SDM_Subscribe消息的SdmSubscription数据类型中包含immediateReport参数（布尔型），如果该参数设置为true，则会在report参数中包含需要下载的签约数据，具体内容详见下图：

响应消息：****

201 Created：如果全部成功，消息体包括创建的签约数据订阅信息。如果部分成功，返回成功订阅数据监视的资源URI。
404 Not Found
501 Not Implemented：携带原因值：UNSUPPORTED_RESOURCE_URI

1.1.2.14d Nudm_UECM_DeregistrationNotification

消息方向：UDM -> old AMF

HTTP方法：POST

该消息的触发条件是：UE移动到了同一个AMF Set内的其它AMF上注册成功，同时，在Step 14a的Nudm_UECM_Registration消息中initialRegistrationInd参数应该设置为True，UDM会向old AMF发送该消息。

调用的URI就是在Nudm_UECM_Registration消息中的deregCallbackUri参数包含的地址。

重点参数介绍：

deregReason

目前版本的标准共定义了7中原因，如下：

· "UE_INITIAL_REGISTRATION"

· "UE_REGISTRATION_AREA_CHANGE"

· "SUBSCRIPTION_WITHDRAWN"

· "5GS_TO_EPS_MOBILITY"

· "5GS_TO_EPS_MOBILITY_UE_INITIAL_REGISTRATION"

· "REREGISTRATION_REQUIRED"

· "SMF_CONTEXT_TRANSFERRED"

pduSessionId

SMF去注册时，与其关联的PDU Session ID（取值范围1-15，0备用）

newSmfInstanceId

新使用的SMF。

响应消息：****

old AMF收到该消息后，会删除本地保存的UE Context。

如果是初始注册，old AMF会调用SMF的Nsmf_PDUSession_ReleaseSMContext服务删除需要释放的PDU Session资源。

如果old AMF之前建立了AM Policy和UE Policy偶联，相应的PCF ID没有发送给new AMF（如new AMF和old AMF不是同一个PLMN）或者new AMF选择了新的PCF，old AMF在收到该消息后，会结束与相应PCF的策略偶联。

如果AMF有N2接口的连接（如UE在RRC in active状态移动到了4G或者其它AMF），AMF会通知释放N2连接。

old AMF成功接受并处理返回：

204 No Content。

其它错误信息：307 Temporary Redirect、308 Permanent Redirect、404 Not Found。

1.1.2.14e Nudm_SDM_Unsubscribe

消息方向：old AMF -> UDM

HTTP方法：DLETE

该消息的资源URI如下：

{apiRoot}/nudm-sdm//{ueId}/sdm-subscriptions/{subscriptionId}

其中：{ueId}变量可以为SUPI或者GPSI。{subscriptionId}为Step 14c中创建订阅时返回的subscription ID。

消息体为空。

响应消息：

204 No Content
404 Not Found

1.1.2.15 PCF选择

该步骤是可选的，具体要不要执行AM策略完全是由运营商定义的。为了提供更多的服务，一般运营商都会开启请求AM策略的流程。

从上面叙述的各步骤解释中我们可以想到：对于周期性注册，该步骤不需要执行，对于移动性注册或者初始注册，该步骤都需要执行。另外紧急注册也是一个例外，虽然在国内不涉及，但考试时需要注意，避免入坑。

在AMF选择PCF（获取AM策略和UE策略）的选择因子方面，TS 23.501定义了4个，具体有：

SUPI
S-NSSAI（在漫游场景下，可能会用到切片选择PCF的情况。）
PCF Set ID
PCF Group ID

还有一个情况是，如果old AMF已经选择了一个PCF，并且将PCF ID包含在UE Context传递给了new AMF，如果new AMF决定使用原来的PCF，可以直接使用PCF ID访问NRF获得原来PCF的信息。

在该步骤中需要注意的是，不论在漫游场景还是非漫游场景负责AM策略的PCF和UE策略的PCF都是同一个PCF。这点3GPP规范明确进行了说明。****

注：

在中国移动的路由组织规范上，选择PCF的两个因子为：GPSI和PCF ID（PCF的nfInstanceId）。GPSI作为选择因子和3GPP规范上略有不同，需要注意。

下面先介绍AMF执行AM策略的过程（AMF和PCF之间的接口为N15），在后面21b步骤中，再进行UE策略的介绍。

1.1.2.16 AM Policy Association Establishment/Modification

对于本步骤来说，如果new AMF重新选择了一个PCF，则执行AM Policy Association Establishment流程；如果是使用old AMF选择的PCF，则执行AM Policy Association Modification流程。我们先来看创建AM Policy Associations的流程。

1.1.2.16.1 AM Policy Association Establishment

请求AM策略的资源URI如下：

"{apiRoot}/npcf-am-policy-control/v1/policies"

HTTP方法为POST。消息名：Npcf_AMPolicyControl_Create Request，消息体为：PolicyAssociationRequest，该数据类型的内容很多，一部分数据来源于AMF从UDM获取的AM签约数据，一部分来自于UE的注册消息携带的信息。截图仅粘贴部分IE：

重点IE介绍：

notificationUri

必选项。PCF发送策略执行通知的URI，对于AMF来讲，就是AMF接收PCF通知的URI。后面的altNotifIpv4Addrs、altNotifIpv6Addrs、altNotifFqdns都是为了保证消息可靠发送定义的冗余信息。

userLoc

可选项。该信息包含UE当前的位置信息，包括：TAC、nCGI、Global RAN Node ID等信息。

allowedSnssais/ mappingSnssais

可选项。经过前面的消息交互已经可以推导出UE的Allowed NSSAI，所以这里可以包含UE在当前PLMN下可以使用的NSSAI。包含该IE的前提是AMF支持切片功能，或者AMF支持"DNNReplacementControl"特性（R16中新增的特性）

serviceName

AMF中用于处理PCF发送的策略数据的服务名。

guami

如果PCF收到了GUAMI，PCF还需要向AMF订阅AMF状态改变通知。

其它信息包括：pei、servingPlmn、ratType、servAreaRes、rfsp、ueAmbr等。

PCF收到Npcf_AMPolicyControl_Create Request请求后，会分配Policy Association ID，并对消息中收到的服务区限制、UE-AMBR等进行策略处理

响应消息：

201 Created

响应消息体中包含的内容为PolicyAssociation，具体定义如下：

重点信息介绍：

request

包含AMF请求时发送的数据，PCF可以再返回一次。

triggers

UE在PCF中签约的触发器，RequestTrigger 数据类型共定义了8中触发器，在AM策略执行中只有 "LOC_CH"、"ALLOWED_NSSAI_CH"、"SMF_SELECT_CH"、"PRA_CH"、"ACCESS_TYPE_CH" 可以使用。

smfSelInfo

如果UE请求了不支持的DNN或者在smfSelInfo包含的DNN时，AMF需要执行AM策略。

servAreaRes/ rfsp/ ueAmbr

这些AMF发送的数据经过PCF处理后会返回。

从上面的叙述中发现，虽然PCF分配了Association ID，但是在响应消息体中没有该偶联的标识等信息。实际上，这部分信息包含在了HTTP消息的头部“Location”中，具体的资源URI为：{apiRoot}/npcf-am-policy-control/v1/policies/{polAssoId}，后续AMF如果需要查询信息时（GET方法），就是使用的该URI。

由于该步骤发生在AMF从UDM获取签约数据之后，所以AMF从PCF收到的服务区限制等信息，可能是经过修改的，和UDM中保存的数据不一样。

1.1.2.16.2 AM Policy Association Modification

该流程不仅适用于new AMF选择了原来的PCF时，更新通知接收的URI、GUAMI和备用IP地址等信息，另外，前面介绍的AM Policy Association Establishment流程中PCF发给AMF的触发器（triggers）被触发时，AMF也会发起该流程。

该流程的请求方法为：POST，调用的服务为Npcf_AMPolicyControl_Update Request，请求的资源URI：

{apiRoot}/npcf-am-policy-control/v1/policies/{polAssoId}/update

消息体包含的内容为：PolicyAssociationUpdateRequest，内容和PolicyAssociationRequest差不多，但不包含supi、gpsi、pei等信息。

重点信息介绍：

notificationUri

new AMF的通知接收URI。

triggers

满足触发条件的事件，如服务区限制变化、UE位置变化、RFSP索引变化等。

当PCF收到该请求后，首先更新相关的策略数据，其次，当triggers中对应的事件发生时，执行的相应的策略操作。如果是AMF变化引起的策略更新，GUAMI发生变化，PCF还需要向AMF重新订阅AMF状态改变通知。

注：

在TS 29.507中有一段说明：If the AMF received the request of removal of Service Area Restrictions and/or RFSP and/or UE-AMBR from the UDM, the AMF shall remove the authorized Service Area Restrictions and/or RFSP and/or UE-AMBR provisioned by the PCF and apply the configured Service Area Restrictions and/or RFSP and/or UE-AMBR at the AMF without interacting with the PCF.

这里的UDM删除数据的请求操作应为UDM的通知操作，调用的是Nudm_SDM_Subscribe操作中包含的{callbackReference} URI。携带的消息体内容包括：ModificationNotification，其中包含的通知项目对应的改变类型为“REMOVE”，其它的改变类型为："ADD"、"MOVE"、"REPLACE"。但是后面的“apply the configured Service Area Restrictions and/or RFSP and/or UE-AMBR at the AMF”一句没有理解是什么意思，既然前面的是请求删除，后面接着说使用“配置的数据”，对于服务区限制数据、RFSP和UE-AMBR的配置都是在UDM中的。如果UDM的签约数据变化了，通知给AMF。按照TS 29.507后面的介绍当UE的签约数据变化时，如服务区限制信息、RFSP信息、UE-AMBR改变时，UDM都会通知AMF。这就满足了AM的策略触发条件，之后AMF会发起AM Policy Association Modification流程请求PCF执行策略。 * 感觉内部逻辑有点矛盾，暂存疑。如果哪位同学get到了原因，多多指教。*

响应消息：

Npcf_AMPolicyControl_Update Response消息的消息体包含PolicyUpdate类型，包含的具体内容之前均进行了介绍，不再重复。消息的部分截图如下：

1.1.2.17 Nsmf_PDUSession_UpdateSMContext

/Nsmf_PDUSession_ReleaseSMContext

该步骤可选，适用于移动性注册更新或者周期性注册更新。当AMF没有需要释放的PDU Session或者没有需要更新的PDU　Session时该步骤不需要执行。这就面临触发条件的问题，什么时候会出现需要释放的PDU　Session，什么时候又需要更新PDU Session。下面分别介绍。

1.1.2.17.1 释放PDU Session的场景

AMF发送Nsmf_PDUSession_ReleaseSMContext消息的场景：

UE本地释放了PDU Session，需要通知网络释放相关的资源。

UE本地释放了某个PDU Session如何通知网络呢？在第一步中UE发送的Registration Request消息的PDU Session Status IE中携带了每个PDU Session的状态：0表示PDU Session处于INACTIVE状态，1表示PDU Session是非INACTIVE状态。new AMF收到该注册请求消息后，会将PDU Session Status IE中的标记为非INACTIVE状态的PDU Session对应的会话资源释放。

注：****

这里之所以不说是ACTIVE状态，是因为非INACTIVE状态除了包括ACTIVE状态可能还包含吊死、挂起等等状态。这里PDU Session Status IE用于通知AMF释放资源，如果表述为ACTIVE状态会引起理解上的困惑。****

需要注意的是，第10步中Namf_Communication_ RegistrationStatusUpdate消息中也会携带需要释放的PDU Session ID，但是其中携带的是new AMF判断不能支持的PDU Session，需要old AMF释放，而本步骤中是UE自行决定释放的PDU Session。

注：

第10步中new AMF不支持的PDU Session由old AMF释放，这点是确定的。那么，本步骤中UE主动释放的PDU Session是由new AMF释放，还是old AMF释放呢？按照TS 23.502来看应该是new AMF释放，而old AMF只释放new AMF不支持的PDU Session。如果UE既有new AMF不支持的，又有UE自身释放的PDU Session，网络会如何处理呢？暂存疑，也许会合并到一起由old AMF释放，这样会减少一步。因为假如AMF不能直接访问SMF，还需要插入SMF时，如果只是为了释放一个PDU Session成本就太高了。具体等研究到PDU Session部分时再分析。

1.1.2.17.2 更新PDU Session的场景

AMF发送Nsmf_PDUSession_UpdateSMContext消息的场景：

UE在Registration Request消息中的Uplink data status IE中包含有需要激活的PDU Session；
UE在执行进出NB-IOT的Inter-RAT移动性更新时，AMF会向SMF发送Nsmf_PDUSession_UpdateSMContext消息更新PDU Session信息；
跨AMF的注册更新，new AMF需要更新SMF中会话信息。

会话更新和释放的具体流程在这里不深入分析，等分析到会话流程时再一起分析。5G的会话流程非常复杂，远比我们平时看流程时介绍的复杂，因为涉及到和4G互操作、切换、及I-SMF/V-SMF、I-UPF等的插入和删除，消息参数特别多，5G真是太复杂了。5G知识点太多了，每一点都够研究很长时间。如果只是懂大概的知识，还是比较简单，但是如果细致分析，感觉就实在太复杂了。

1.1.2.18 UE Context Modification Request/Response

和N3IWF/TNGF/W-AGF间的交互，该步骤涉及到其它接入技术间的流程，国内不涉及。

1.1.2.19 UE Context Modification Response

和N3IWF/TNGF/W-AGF间的交互，该步骤涉及到其它接入技术间的流程，国内不涉及。

1.1.2.20 创建UE Context的N2接口流程

该步骤3GPP中的流程为空。这里暂借用来介绍AMF和gNB之间的INITIAL CONTEXT SETUP REQUEST信令消息、空口消息RRCReconfiguration消息等，Registration Accept消息承载在这两条消息中。在第21步集中精力介绍NAS层Registration Accept消息。

该步骤的内容对应TS 23.502中注册流程的9c、9d内容。之所以放在第20步才开始介绍原本在第9步中的内容，原因是我经过反复查找发现，实际上在第9步中AMF并没有和gNB的信令交互。既然没有信令交互，也就是说在初始注册的场景下，第11步并没有使用新的5G NAS security context来推导RRC层的密钥来对Identity Request/Response（请求PEI）进行加密和完整性保护，要么Identity Request/Response在RRC层没有加密和完整性保护，要么是使用old 5G NAS security context进行的加密和完整性保护。

3GPP只在RRC层说明了什么时候激活RRC层安全，至于和NAS层直接的对应关系没有明确说明。NAS层从哪条消息开始进行了RRC层的加密和完整性保护，需要我们自己分析。由于RRC层和NAS层都定义了Security Mode Command消息，NAS层中间有空格，RRC层中间没有空格，定义为SecurityModeCommand，对我们理解造成了很大的干扰。在TS 33.501中使用NAS Security Mode Command和AS Security Mode Command来区分。经过多次印证，RRC层的加密和完整性保护是在INITIAL CONTEXT SETUP REQUEST建立起来的。具体分析如下。

TS 38.331（RRC层信令规范）5.3.4 Initial AS security activation章节，明确说明UE是接收到网络下发的SecurityModeCommand消息后启动AS加密和完整性保护。这里的网络对于UE来讲就是gNB，该消息指的是RRC层的SecurityModeCommand消息。

接下来，我们重点关注gNB在什么时候下发该消息。查看TS 38.413规范（NGAP）中，gNB在INITIAL CONTEXT SETUP REQUEST消息中获得安全密钥。TS 38.413 章节8.3.1中 gNB收到该消息后的操作有：store the received Security Key in the UE context and, if the NG-RAN node is required to activate security for the UE, take this security key into use.

从这句话可以看出来，只有当UE收到INITIAL CONTEXT SETUP REQUEST时才会激活RRC层的安全流程。因为，gNB并不需要理解NAS层的信息，此处说的肯定不会是NAS层的安全。从密钥安全推导的图来看，也不存在N2接口使用的密钥，只有NAS层和RRC层。

另外，INITIAL CONTEXT SETUP REQUEST消息的定义中包含Mobility Restriction List IE（虽然是可选项）需要在第14步执行完成之后才能得到，也能够说明初始NGAP流程，应该是在14步之后执行，该不是在第9步中主鉴权流程执行完成之后，直接执行NGAP流程。

据此判断中国移动的5G路由规范在注册流程中第7步写了NGAP流程应该错误的，应该挪在Registration Accept之前。至于TS 23.502的第9步只是把安全相关的内容写到了一起，没有区分先后，这样的情况在3GPP中很多。因为3GPP知识点都是分散在好多文档，一般是把一类的知识放在一起将。

接下来我们分别看N2接口消息和空口消息。

1.1.2.20.1 INITIAL CONTEXT SETUP REQUEST

该消息的目的是在gNB中初始化UE Context（gNB在收到Registration消息时已经创建了UE Context，此时只是修改增加相关数据），包括PDU session上下文、安全密钥、移动限制性列表、UE无线能力及UE的安全能力等信息。该消息是由AMF触发的。在第1步介绍的INITIAL UE MESSAGE消息中有UE Context Request IE表示gNB请求UE Context。如果gNB没有携带该IE，AMF也会根据配置触发INITIAL CONTEXT SETUP REQUEST，否则UE的初始注册就失败了，因为gNB无法初始化UE Context，也没有安全密钥等必须参数。

INITIAL CONTEXT SETUP REQUEST消息包含的内容很多，部分截图如下：**

重点IE介绍：

UE Security Capabilities

包含加密算法和完整性保护算法信息。

Core Network Assistance Information for RRC INACTIVE

UE处于RRC_INACTIVE状态时需要的信息。

Redirection for Voice EPS Fallback

指示AMF和UE对EPS Fallback的支持情况。gNB如果支持EPS Fallback功能，会保存该信息，用于后续的VoLTE回落判断。

Mobility Restriction List

gNB根据该字段为UE分配处于RRC INACTIVE状态时的RNA。

NAS-PDU IE

该字段包含Registration Accept消息，gNB透明转发给UE。

UE Radio Capability

UE的无线能力信息，包括：power class、frequency bands等信息。如果AMF本地有，需要在该消息中发送给gNB。

SRVCC Operation Possible

UE和AMF的SRVCC支持能力

1.1.2.20.2 RRC层（AS层）加密和完整性保护的启用

gNG收到该消息后，除了保存相关字段信息外，还需要根据消息中的密钥参数执行RRC层的安全。RRC层的安全启用和NAS层的加密和完整性保护启用步骤略有差异。具体步骤详解如下：

从上图可以看出来，RRC层的加密是在AS Security Mode Command和AS Security Mode Complete之后激活的。而NAS层在NAS Security Mode Complete消息中就启用了加密和完整性保护。

AS Security Mode Command消息承载在SRB1上，消息的详细定义如下

AS Security Mode Command消息的定义中，我们需要重点关注的是securityAlgorithmConfig，其中配置有RRC层的安全算法信息，nia0、nea0同样为空算法：如下：

RRC层使用的密钥是由UE和gNB根据KgNB推导出来的，不是由AMF推导出来发送给gNB的。在RRC层只是选择使用的算法。

AS Security Mode Complete消息的定义比较简单，没有什么需要关注的信息。

需要注意的是，如果UE验证AS Security Mode Command失败，会返回不经过任何保护的security mode failure消息。

1.1.2.20.3 RRC层UECapabilityEnquiry

该步骤的执行前提是激活了AS安全保护，如果未激活是无法执行该流程的。

如果UE在CM-IDLE状态改变了UE Radio Capability信息，在发送移动性Registration Request消息中的5GS update type IE中设置“UE radio capability update needed”标记，AMF收到该消息后会删除AMF保存的UE无线能力信息。同样，在使用SUCI的初始注册或者从old AMF中没有得到UE无线能力信息，在AMF发送给gNB的INITIAL CONTEXT SETUP REQUEST消息中就不能包含UE Radio Capability IE。此时就会触发gNB执行UECapabilityEnquiry流程获取UE的无线能力。

另外，在第6步或者第11步中Identity Request消息的发送流程中，N2接口的Downlink NAS Tranport消息中包含UE Capability Info Request IE，如果设置为"requested"，在AS安全保护启动后，也会执行该步骤获取UE无线能力。

说到这里各位同学会不会觉得有点乱，到底什么时候执行？具体在什么时候执行要看情况，可选的信令流程就是这样，一定要明白触发条件。只要满足了触发条件就会执行。以注册过程为例，如果UE使用SUCI发起注册流程，则第6步不会执行获取SUCI，也就是gNB不会收到第一条Downlink NAS Tranport消息，那么接下来gNB收到第一条Downlink NAS Tranport消息的可能是第11步获取UE的PEI，此时就会携带UE Capability Info Request IE设置为：request。因为如果UE携带SUCI注册，AMF中肯定不会有UE Radio Capability信息。但是此时gNB还没有激活AS安全，无法发起UECapabilityEnquiry流程，只能挂起该操作，等到gNB收到INITIAL CONTEXT SETUP REQUEST激活了AS安全后，才会发起获取UE无线能力的流程。

1.1.2.20.4 RRC层UECapabilityInformation

UE的无线能力信息比较大，如果超过了PDCP层的最大支持，会启用RRC层消息的分段传输功能。

1.1.2.20.5 N2消息：UE RADIO CAPABILITY INFO INDICATION

gNB将获取到的最新的UE Capability Information通过UE RADIO CAPABILITY INFO INDICATION消息发送给AMF，AMF收到后会替换本地为该UE保存的无线能力信息。UE RADIO CAPABILITY INFO INDICATION消息的定义如下：

1.1.2.20.6 RRCReconfiguration

该消息用于在空口上传递Registration Accept消息，用于UE处于RRC_CONNECTED状态时，更新RRC连接、刷新RRC连接使用的密钥参数等。该消息承载在SRB1或者SRB3上。RRCReconfiguration消息的部分定义如下：

其中：dedicatedNAS-MessageList用于传递UE和AMF之间的NAS信令；后面的sk-counter参数用于UE进行RRC层的密钥推导。

注：

在本步骤中为什么使用了RRCReconfiguration而不是DLInformationTransfer来传递Registration Accept消息呢？

这两条消息都是UE在RRC_CONNECTED状态使用的消息，NAS层消息都可以承载在这两条消息中传递。之所以在初始注册时使用了RRCReconfiguration是因为要修改RRC连接的配置，启用AS层的保护功能。如果本步骤RRC不需要修改RRC的配置，只是传递NAS消息，则使用DLInformationTransfer来传递Registration Accept消息。

*从第一步Registration Request步骤中介绍的DLInformationTransfer定义可以看到该消息专门就是用于传递NAS消息的，没有别的功能。gNB在发送下行NAS消息时首先根据当前情况，看是否RRC层有需要修改的参数，如果有则构造RRCReconfiguration消息，此时NAS层的消息只是顺带发送给UE的，这样就节省了一条空口消息，gNB不用单独再构造一条DLInformationTransfer消息下发NAS消息。 *

1.1.2.20.6 RRCReconfigurationComplete

RRCReconfiguration消息的回复消息为RRCReconfigurationComplete。因为对Registration Accept消息的确认不是必须的，所以在RRCReconfigurationComplete消息中没有定义传递NAS消息的IE，这里不进行详细介绍。

1.1.2.20.7 INITIAL CONTEXT SETUP RESPONSE

对INITIAL CONTEXT SETUP REQUEST消息的确认，如果没有PDU Session的建立和更新，只用来确认消息。

1.1.2.21 Registration Accept

1.1.2.21.1 Registration Accept消息注解

Registration Accept消息承载在20步中的INITIAL CONTEXT SETUP REQUEST（N2接口消息）和RRCReconfiguration消息（RRC层消息）中发送给UE。本步骤专门介绍NAS层Registration Accept消息。该消息内容非常丰富，UE的很多行为参数都是在该消息中下发给UE的。

Registration Accept为必选消息，不论是什么注册类型，该消息都存在，只是不同的注册类型携带的参数不一样。如果网络接受了用户的注册请求，AMF会发送Registration Accept消息给UE。AMF保存注册请求中的5GMM capability、S1 UE network capability、UE security capability等信息。在AMF间切换或者4/5G切换时，old AMF会将这些信息发送给new AMF或者MME。

我们先看Registration Accept消息的定义：****

该消息的IE很多，有些参数的网络行为也很复杂，比如切片、MICO、LADN等。这些内容在后续专题里进行详细介绍，这里仅扼要介绍重点内容。

5GS registration result

该IE中包含的信息很重要，具体信息如下：

（1）注册成功的RAT类型：3GPP access还是non-3GPP access，或者二者都有。

（2）网络对SMS over NAS是否支持，allowed或者not allowed。

（3）是否需要执行NSSAA（Network slice-specific authentication and authorization），也就是对切片的鉴权和授权是否需要执行。该标识位很重要，会衍生出很多的网络行为。

在第一步的介绍中，我们知道UE是否支持SMS over NAS是在注册消息的5GS update type IE中设置的。如果完成SMSF选择并激活SMSF服务成功，AMF会在REGISTRATION ACCEPT消息中将5GS registration result IE对应的比特位置位，表示"SMS over NAS allowed"。SMSF的地址信息会保存在AMF的UE Context中。

我们再来看一下5GS registration result IE 中设置为"SMS over NAS not allowed"的场景有哪些：

（1）AMF进行SMSF选择失败（目前中国移动使用nf-type来查询NRF，执行SMSF发现操作）；

（2）SMSF中UE的SMS功能激活失败；

（3）AMF不允许使用SMS over NAS功能；

（4）UE在REGISTRATION REQUEST 消息中设置为"SMS over NAS not supported"；

（5）REGISTRATION REQUEST消息不包含5GS update type IE。

5G-GUTI

这个术语很著名，只要学5G的同学都知道它的结构。这里我们主要讲一个大家容易忽视的问题：网络什么时候会为UE重新分配5G-GUTI？5G-GUTI并不是初始注册完成后就一成不变的，而是会经常变化，这样才能保证信息安全。我们看一下，网络为UE重新分配5G-GUTI的场景：

（1）根据3GPP规范，初始注册、移动性注册、周期性注册，网络都会为UE重新分配5G-GUTI；

（2）UE响应寻呼，AMF收到UE发送的Service Request消息，也会为UE分配新的5G-GUTI，在当前的NAS信令连接释放前发送给UE；

（3）除上述场景，5G-GUTI重新分配的可以更频繁，这依赖于厂家实现。任何时候网络都可以通过CONFIGURATION UPDATE COMMAND对UE的5G-GUTI重新分配。

需要注意的是UE收到5G-GUTI，发送确认Registration Complete后，会删除本地所有的SUCI。

如果USIM中有对应的文件，则将5G-GUTI保存在USIM中；如果USIM没有对应的文件，则将其保存在ME的非易失性存储器中。

如果UE没有收到5G-GUTI，则认为UE之前保存的5G-GUTI仍然有效（比如：UE已经通过non-3GPP完成了注册，本次在3GPP场景注册）。

Equivalent PLMNs

AMF会为UE分配一个equivalent PLMN列表（MCC+MNC）。UE会保存该列表，但是在保存前会把禁止接入的PLMN从该列表中删除。当然UE也会保存当前注册的PLMN。UE每次收到Registration Accept都会保存equivalent PLMN列表，如果消息中不包含该列表，那么UE也会删除本地保存的列表。

equivalent PLMN列表是什么东西呢？举个例子，对中国移动来讲，网络正常注册的是46000，但是46002、46004等也是中国移动使用的PLMN ID，这些同一个运营商使用的其它PLMN号码就相当于equivalent PLMN。

注意该字段在gNB同时连接ToB和ToC核心网时会有用。

TAI list

AMF会为UE分配一个注册的TA List，具体使用场景和4G一样。UE在收到新的TA List后，会替换掉UE原来保存的TA List。

如果UE没有收到新的TA List，则认为原来的TA List仍然有效。

如果UE从5G去注册了，UE中的TAI List就无效了。

Allowed NSSAI

Allowed NSSAI中包含的是不需要NSSAA的切片或者NSSAA验证成功的切片（根据UE Context判断old AMF已经对这些切片进行了NSSAA验证），最多包含8个S-NSSAI，保存在UE的非易失性的存储器中。

在3GPP网络接入下，网络允许使用的切片信息包含在该IE中，该值为Requested NSSAI和subscribed NSSAI的交集，且在UE的当前TA中允许使用的NSSAI。

如果UE在注册请求中没有包含Requested NSSAI或者Requested NSSAI中的切片网络都不允许使用，那么Allowed NSSAI IE中包含的S-NSSAI是subscribed S-NSSAI中设置为缺省的切片（前提是这些缺省的subscribed S-NSSAI不需要NSSAA，如果缺省的切片需要NSSAA，则不能包含在Allowed NSSAI中）。

UE会将接收到的allowed NSSAI和当前的PLMN、TA关联起来进行保存。

UE注册中，Registration Accept中出现Allowed NSSAI为空的场景有哪些呢？

（1）Requested NSSAI中的所有S-NSSAI(s)都需要进行Network Slice-Specific Authentication and Authorization

（2）UE没有提供Requested NSSAI或者Requested NSSAI中的S-NSSAI都没有匹配上Subscribed S-NSSAIs，并且所有Subscribed S-NSSAIs中所有的缺省S-NSSAI都需要Network Slice-Specific Authentication and Authorization。

Rejected NSSAI

UE请求的Requested NSSAI中被网络拒绝的S-NSSAI都会放在该IE中，每个切片都会有对应的拒绝原因值。

UE收到Rejected NSSAI会将其添加在拒绝列表中，下次注册时不会使用这些NSSAI。Rejected NSSAI也会和PLMN网络、TAI等关联，用于实现不同级别的限制。

UE从网络去注册的时候，需要删除Rejected NSSAI信息。

Configured NSSAI

Configured NSSAI在AMF或者NSSF上进行配置。一般AMF或者NSSF配置的NSSAI需要和用户签约的Subscribed NSSAI取交集，其结果包含在Configured NSSAI IE中。Configured NSSAI最多包含16个S-NSSAI，保存在UE的非易失性的存储器中。

网络下发Configured NSSAI的场景如下：

（1）Registration Request不包含Requested NSSAI；

（2）Registration Request消息中Requested NSSAI里包含的S-NSSAI当前网络无法使用。

（3）Registration Request消息中Requested NSSAI使用是Default Configured NSSAI。

（4）Registration Request消息中Requested NSSAI对应的mapped S-NSSAI不正确（mapped S-NSSAI在R15版本的3GPP中介绍的非常模糊，在R16版本中很清晰，在漫游场景时使用，一般用于非标准的S-NSSAI）

UE收到消息后，替换当前的Configured NSSAI，并删除所有之前保存的Allowed NSSAI、Rejected NSSAI、Pending NSSAI，发送REGISTRATION COMPLETE消息。

此处有一个关键点，当终端支持4/5G功能，如果用户从4G接入时网络，此时网络一般会给UE下发一个NSSAI，用于4/5G互操作，这个NSSAI就是保存在UE的Configured NSSAI中。

5GS network feature support

如果UE在Registration Request消息的5GMM capability IE中指示支持S1模式（4G模式），那么该IE包含AMF支持N26接口指示；"interworking without N26 interface not supported" 。

该IE中还包含IMS voice over PS session、 location services (5G-LCS)、紧急服务等指示信息。

AMF在设置IMS voice over PS session标记时，可能会使用UE Capability Match Request流程来查询UE和NG-RAN的无线能力，用于判断是否支持IMS over PS Session。相关具体信息，详见第24步骤的分析。

PDU session status

该IE适用于移动性注册或者周期性注册。

UE的Registration Request消息中如果包含PDU session status IE， AMF会将没有处在PDU SESSION INACTIVE状态的PDU Session资源释放（也就是说：会将在注册请求消息中PDU session status IE对应的比特位置位的PDU Session占用的资源释放），并在Registration Accept消息中包含PDU session status IE。

AMF需要和UE进行PDU Session的状态同步时，也会下发该IE，置位方法和注册请求消息一样。UE收到该IE时，UE会在本地释放PDU session status IE置位的PDU Session（UE中的PDU Session状态可能处于非PDU SESSION INACTIVE或者PDU SESSION ACTIVE PENDING等）。但是UE收到该IE的处理方式有几个例外情况。例外情况时，UE会忽略该Registration Accept中的PDU session status IE，具体的例外情况如下：

（1）Registration Request消息中已经发送了PDU session status IE；

（2）UE处于单注册模式；

（3）UE在5GMM-IDLE模式下执行S1到N1模式的系统间切换（4G到5G）；

（4）UE收到的IWK N26比特位设置为："interworking without N26 interface supported"。

PDU session reactivation result

该IE适用于移动性注册或者周期性注册。

UE的Registration Request消息中如果包含Uplink data status IE，AMF会请求SMF重新激活对应PDU Session的用户面资源，并在Registration Accept消息中包含PDU session reactivation result IE。

-PDU session reactivation result error cause

该IE适用于移动性注册或者周期性注册.

如果UE不在允许的区域（allowed area），用户面重新激活失败时，该IE中包含的错误原因为：#28 "Restricted service area"。

如果UE不在LADN服务区，激活重新用户面失败，错误原因：#43 "LADN not available"。

如果UPF资源不可用导致的重新激活失败，错误原因：#92 "insufficient user-plane resources for the PDU session"。

其他情况导致的PDU Session重新激活失败时会下发相应的原因值。

Network slicing indication

如果用户UDM中的签约切片数据发生了变化，AMF会使用该IE向UE指示："Network slicing subscription changed"。

UE收到该IE后会删除当前PLMN外的其它所有PLMN的切片信息，并发送REGISTRATION COMPLETE消息，通知AMF切片信息更新成功。

LADN information/ MICO indication

LADN和区域专网相关，MICO和超低功耗相关，都是物联网相关的IE，目前应用比较少，这里不具体进行分析，后续专题分析时会进行详细介绍。

UE如果收到的Registration Accept消息中包含新的LADN information，会把本地保存的信息及时替换更新。如果Registration Accept消息中没有LADN信息，UE要把本地的LADN information删除，表示UE当前所处的TA没有LADN可用。这点和5G-GUTI、TA List不一样，5G-GUTI、TA List如果没有收到新的，会认为之前的仍然有效。

Service area list

如果UE没有收到Service area list IE，则默认当前注册的PLMN和equivalent PLMN的所有TA都是允许区域。

T3512 value

UE的周期性注册更新定时器。

NSSAI inclusion mode

UE如果收到该IE，则按照其指示在接入层包含NSSAI。如果UE本地存有该网络的NSSAI inclusion mode，则按照该模式执行。如果UE本地没有该NSSAI inclusion mode数据，对于3GPP接入来讲，默认按照模式D执行。该参数具体的设置在Registration Request步骤中已经说明过，本步骤不再说明。

EPS bearer context status

如果由S1模式到N1模式执行系统间切换（4/5G切换），AMF会为UE生成EPS承载上下文信息，AMF会在Registration Accept消息中包含EPS bearer context status IE，指示UE使用了哪一个EPS上下文。

UE收到该IE后会释放其中标记为不活动的EPS承载关联的资源，如QoS flow descriptions及所有关联的QoS规则。

Pending NSSAI

如果UE支持NSSAA，即：Registration Request请求消息的5GMM capability IE中NSSAA置位时，会下发该IE。之后在第25步中进行Network Slice-Specific Authentication and Authorization流程。

如果网络有切片需要进行NSSAA验证或者正在进行NSSAA验证，其相应的S-NSSAI包含在该IE中下发给UE，同时5GS registration result IE中需要设置"NSSAA to be performed"指示。

Pending NSSAI最多包含16个S-NSSAI。

后续如果切片验证成功了，但是网络已经下发了Registration Accept消息，如何把这些切片信息发送给UE呢？

答案是后续如果切片验证成功，AMF会使用CONFIGURATION UPDATE COMMAND消息将结果通知UE。

Truncated 5G-S-TMSI configuration

该IE与物联网相关。

UE工作在NB-N1模式使用了control plane CIoT 5GS optimization特性，而且网络也支持该特性时，才会为UE发送Truncated 5G-S-TMSI configuration信息。其中包含"Truncated AMF Set ID value" 和"Truncated AMF Pointer value"。该IE需要UE发送确认消息。

上面切片部分叙述看起来很复杂，总的来说只有两条：

（1）如果Registration Request消息中包含Requested NSSAI IE，且Requested NSSAI和subscribed S-NSSAI（签约切片）有交集，此时的焦点是交集NSSAI，处理方法为：

不需要执行NSSAA的或者NSSAA已经成功的，放在Allowed NSSAI IE中；
需要执行NSSAA的NSSAI，放在Pending NSSAI IE中。

（2）如果Registration Request消息不包含Requested NSSAI IE，且Requested NSSAI和Subscribed S-NSSAI（签约切片）没有交集，此时的焦点是Subscribed S-NSSAI标记为缺省的NSSAI，处理方法如下：

缺省Subscribed S-NSSAI中不需要执行NSSAA的或者NSSAA成功的NSSAI，放到Allowed NSSAI IE中；
缺省Subscribed S-NSSAI中需要执行NSSAA的NSSAI，放到Pending NSSAI IE中。

1.1.2.21.2 注册流程要点说明

（1）如果UE收到了切片信息，要删除本地保存的所有切片数据（Default Configured NSSAI除外），之后使用接收到的切片数据更新。

（2）如果在Registration Request消息的5GS Registration type IE中指示"Follow-on request pending"或者网络有下行数据要发送，AMF完成注册流程后，不会立刻释放NAS连接。

（3）UE收到Registration Accept消息后会重置注册尝试的定时器，并切换自身状态到5GMM-REGISTERED，设置自己的5GS更新状态为5U1 UPDATED。

（4）虽然UE收到了REGISTRATION ACCEPT消息，但是如果5GS registration result IE指示"NSSAA to be performed"且包含pending NSSAI，allowed NSSAI又为空的情况下，此时UE是无法享受任何网络服务的（紧急服务及高优先级接入除外）。

（5）根据上面的叙述，我们总结UE收到Registration Accept包含哪些信息时需要发送Registraton Complete消息：

5G-GUTI
TA List
SOR transparent container IE
Operator-defined access category definitions IE
Extended emergency number list IE
CAG information list IE
UE radio capability ID IE
UE radio capability ID deletion indication IE
收到任何和切片相关的信息。

（6）AMF收到Registraton Complete消息后会停止T3550，修改UE状态为5GMM-REGISTERED，5G-GUTI、UE radio capability ID开始生效。

1.1.2.21.3 注册被拒绝的情况

1.1.2.21.3.1 初始注册被拒绝

如果网络拒绝UE的Registration Request消息会下发Registration Reject消息给用户。拒绝的情况很多，我们常见的拒绝场景就是切片不可用，此时网络下发的原因值为#62 "No network slices available"，具体场景如下：

UE不支持NSSAA（请求消息的5GMM capability IE中设置）情况：Requested NSSAI中的所有的S-NASSAI都被拒绝了，并且没有缺省的Subscribed S-NSSAIs或者缺省的Subscribed S-NSSAIs都不允许使用。
UE支持NSSAA情况：Requested NSSAI中的所有的S-NASSAI都被拒绝了，并且没有缺省的Subscribed S-NSSAIs或者缺省的Subscribed S-NSSAIs都不允许使用，而且需要鉴权的缺省Subscribed S-NSSAIs全都鉴权失败。

网络拒绝UE的注册后，会把拒绝的S-NSSAI放在Registration Reject消息的Rejected NSSAI IE中发送给UE。UE收到后会保存Rejected S-NSSAI。

UE由于切片被注册拒绝后，仍然会有后续操作，具体是什么呢？

如果UE有allowed NSSAI或者configured NSSAI（UE发起注册前保存的旧的数据），其中包含有不在Rejected S-NSSAI列表中的S-NSSAI（此处暂自定义为：后续S-NSSAI），此时UE还会驻留在当前小区，使用正常的小区重选流程启动初始注册流程，将“后续S-NSSAI”作为Requested NSSAI发起注册。如果“后续S-NSSAI”为空，UE会执行PLMN选择。如果allowed NSSAI或者configured NSSAI中所有的S-NSSAI都被拒绝了，UE会关闭当前PLMN的N1模式。
如果UE在当前网络没有allowed NSSAI或者configured NSSAI，但是有default configured NSSAI，会把default configured NSSAI作为Requested NSSAI，之后按照上面的流程再执行一遍。

最后一点需要注意的是，在很多场景下UE如果注册被拒绝，UE会删除本地之前保存的5G-GUTI、之前注册的TAI、TAI list和ngKSI。因为这些参数是保存USIM中或者UE的非易失性存储中。再说的深一点，也就是说如果UE注册是由于下面的原因被网络决绝了，UE下次发起的注册请求一定还是初始注册。具体的原因有：

#3 (Illegal UE)

#6 (Illegal ME)

#7 (5GS services not allowed)

#11 (PLMN not allowed)

#12 (Tracking area not allowed)

#13 (Roaming not allowed in this tracking area)

#15 (No suitable cells in tracking area)

#27 (N1 mode not allowed)

#73 (Serving network not authorized)

#31 (Redirection to EPC required)

1.1.2.21.3.2移动性或者周期性注册被拒绝

基本和初始注册时一样，个别场景有区别。下面重点列两个主要区别

#62 (No network slices available)

此时的区别是不使用default configured NSSAI尝试进行再次注册，其它都一样。

删除本地保存的参数

对于移动性注册和周期性注册，UE删除5G-GUTI、之前注册的TAI、TAI list和ngKSI的场景有不同。也就是说，一旦注册失败，下次注册的注册类型发生了改变，变为初始注册，而不是移动性注册或者周期性注册。具体如下：

#3 (Illegal UE)

#6 (Illegal ME)

#7 (5GS services not allowed)

#9 (UE identity cannot be derived by the network)

#11 (PLMN not allowed)

#12 (Tracking area not allowed)

#13 (Roaming not allowed in this tracking area)

#73 (Serving network not authorized)

#75 (Permanently not authorized for this SNPN)

你从这篇文章中能学到什么？

我们在手机上运行一个应用程序，UE是如何把应用程序的数据映射到PDU session上的？
UE新建立PDU Session时，是如何选择切片的。如果注册时UE的Allowed NSSAI有多个，必然面临切片的选择问题。
Registration Accept消息已经下发了，UE策略是如何得到的？
UE策略和网络之间如何更新的？

……

还有很多细节问题，都会从这篇文章中学到。后续会介绍QoS flow的映射，QoS Flow和DRB的映射及UPF下行数据的映射，都会在后续详解中不断呈现，直到把5G扒的只剩一条内裤。

内容目录：

21b. UE Policy Association Establishment

1）触发场景和条件

2）UEPolicy为何物

3）UE中如何使用URSP路由数据

4）UE 策略的发送流程

5）UEPolicy Association的建立

6）UE策略的下发

（1）UE策略管理流程

（2）UE策略的下发

可以使用电脑点击下面链接

mp.weixin.qq.com/s/o9fCb76rP…

该篇文章为收费文章，全文8000多字。目前互联网独一份，看完本篇UE策略你就可以完全掌握了。

昨天发完《一文彻底弄懂UE策略（5G注册流程分级详解Step21b）》后，针对其中UE策略的更新流程部分前文虽然进行了“标注”，感觉论据并不充分，多是主观理解，今天又深入想了想，补充一下，避免介绍错了，误导各位同学。

先上流程图，便于后面解说：

UE策略更新目前看到有两种场景：

（1）初始注册过程中的UE策略更新，和注册流程一起执行。触发条件是RegistrationRequest消息中携带UE Policy Container。AMF如果发现携带了该IE就会执行UE策略；

（2）AMF执行Npcf_UEPolicyControl_CreateRequest后会下发触发器（Triggers），后续UE如果满足触发器定义的条件时，进行UE策略的更新。

第二种情况比较好理解，这种场景，肯定是PCF触发更新，TS23.502中明确有定义，没有任何疑问。但是第一种场景就有歧义了，歧义的起源在哪呢？根源是PCF发送给AMF的Npcf_UEPolicyControl_Create Request的响应消息201 Created中，消息体PolicyAssociation数据类型携带了UePolicy字段（该字段可选），该字段中包含的就是PCF处理过的UE策略。如果响应消息中PCF包含该字段发送给AMF，那么AMF就得到了注册UE的UE策略，完全可以直接提取出该字段下发给UE，这样就省了PCF再次发送Namf_Communication_N1N2MessageTransfer消息传送UE策略了，相当于省了一个HTTP Request/Response回合。但是，AMF提取响应消息的UePolicy发送给UE的操作3GPP规范中没有写。我查遍了所有UE策略相关的规范都没有写，没有写我们就不能认为这个捷径可行。

那么，PCF什么时候会下发UePolicy字段给AMF，AMF要来何用呢？暂时还没有找到，只能暂存疑。

现把昨天的“注”部分，再补充说明如下：

注：

从上面5）小节Npcf_UEPolicyControl_Create Request的响应消息201 Created中可以看到，其中包含UePolicy字段，该字段的内容和MANAGE UE POLICY COMMAND消息一样，就是要UE策略。是否AMF收到201消息后直接使用该UePolicy字段下发给UE呢？最开始时，我也有此疑问。AMF收到201响应直接将其中的UePolicy使用DL NAS TRANSPORT发送给UE岂不是更好，省了PCF再触发更新UE策略的流程，也省了PCF和AMF之间的一条信令。结果查遍3GPP规范，并没有该骚操作。

至于原因，我想可能是如果AMF直接下发UePolicy字段流程会显的比较乱，不闭环，网元功能也有混淆。从“UE策略管理流程”可以看出来，AMF在其中只是一个透明转发的作用。UE策略的更新本来是PCF的事情，涉及UE和PCF两个网元。如果AMF收到了一个正常的请求响应，反倒担负起来更新UE策略的责任，那么AMF在其中就不能扮演一个透明转发的角色了，而是AMF在其中要处理UePolicy字段提取出来再转发。这样的话，这个更新并不是PCF触发的，而是AMF自己臆断：收到UePolicy就更新UE侧的UE策略，至于是否真的需要更新UE策略，AMF并没有足够的信息可以做决策。况且UePolicy字段还是可选字段，PCF是可以选择不下发的。

另外，从上一节的叙述中可以知道，UE更新完网络下发的UE策略后要发送MANAGE UE POLICY COMPLETE确认消息给PCF，该消息是必须要执行的，不是可选消息。那么，AMF收到UL NAS TRANSPORT消息后，该怎么发送给PCF呢？只能通过Namf_Communication_N1MessageNotify发送MANAGE UEPOLICY COMPLETE消息给PCF。因为TS 29.518中明确说明了N1MessageNotify用于UE策略的传递，见下图。

如果AMF直接使用了201响应中UePolicy字段，又何来N1MessageNotify呢？因为之前PCF根本就没有给UE发送N1消息呢，PCF发给AMF的一个201Created响应消息，不论从什么角度来讲，也不能认为有N1消息的嫌疑。。

最后，不使用Namf_Communication_N1MessageNotify，使用PCF订阅AMF的事件消息，PCF也能收到AMF发来的通知。我们再看一下PCF订阅AMF事件的说明。订阅事件是在AM策略建立之后执行的，也就是说订阅的是AM相关的变化。

综上所述，不论是注册过程中UE策略的更新，还是后续场景中UE策略的更新，只能使用UE Configuration Update流程完成UE策略的投递。由PCF触发，使用Namf_Communication_N1N2MessageTransfer消息的N1MessageContainer字段来实现AMF对UE策略的透明转发。

至于响应消息中的，UePolicy信息有什么作用只能存疑了。

1.1.2.22 Registration Complete

在第21步中，我们总结了UE发送Registration Complete消息的触发条件，现在回顾一下。

当UE收到的Registration Accept包含下列信息时UE需要发送Registraton Complete消息：

5G-GUTI
TA List
SOR transparent container IE
Operator-defined access category definitions IE
Extended emergency number list IE
CAG information list IE
UE radio capability ID IE
UE radio capability ID deletion indication IE
收到任何和切片相关的信息，如Allowed NSSAI、Configured NSSAI、Network Slicing Subscription Change Indication等等。

UE成功发送完Registration Complete消息后，还需要把5G-GUTI传递给UE的RM层，目的是NG-RAN使用RRC Inactive State功能时，需要使用5G-GUTI的一部分来计算寻呼帧（Paging Frame），方法是：5G-S-TMSI mod 1024（取模1024）。

如果在Registration Request消息的5GS Registration type IE中指示"Follow-on request pending"，或者网络有下行数据要发送，AMF完成发送完Registration Accept后，不会立刻释放信令连接。

如果没有上面的信息，则会立即释放NG-AP信令连接、AN接入网信令连接以及N3用户面连接。什么时候会在注册流程中出现N3信令面连接呢？比如UE有需要always-on PDU Session，如果没有数据要发送就会释放N3连接。

下面看Registration Complete消息的定义：

Registration Complete消息比较简单基本只是用来向AMF确认已经收到了关键信息。虽然有SOR transparent container IE，貌似包含一些信息，实际上此处的SOR transparent container IE也只是用于向网络确认UE已经正常收到Registration Accept消息中的SOR transparent container，并没有其它的作用。

1.1.2.23 Nudm_SDM_Info

如果在第14b步骤中AMF获取的接入和移动性签约数据包含有SOR信息（Steering of Roaming）需要确认的指示，AMF会使用该步骤向UDM确认。SOR是涉及PLMN选择相关的知识，这里暂不介绍，后续进行专题讲解。

AMF也会使用Nudm_SDM_Info向UDM确认UE正常接收了CAG、Network Slicing Subscription Change Indication等信息。

1.1.2.23a. N2 message

如果AMF没有释放信令连接，AMF会向g-NB发送RRC Inactive Assistance Information，但TS 23.502中并没有详细说明在注册流程末尾，什么情况会触发该消息，也没有说明AMF使用了哪条N2消息？

在第20步：AMF使用INITIAL CONTEXT SETUP REQUEST消息在gNB中创建UE Context步骤中。我们知道，AMF可以将RRC Inactive Assistance Information通过INITIAL CONTEXT SETUP REQUEST消息中的Core Network Assistance Information for RRC INACTIVE IE将RRC Inactive状态的辅助信息发送给gNB，并保存在UE的Context中，该IE是可选字段。

在注册流程的结尾，如果AMF第20步没有发送RRC Inactive辅助信息或者相关信息需要更新，会在本步骤中发送，但是此时的N2接口消息为：UE CONTEXT MODIFICATION REQUEST，该消息的定义如下图：

需要注意的是在INITIAL CONTEXT SETUP REQUEST和UE CONTEXT MODIFICATION REQUEST消息中都包含有RRC Inactive Transition Report Request IE。该字段的作用是当UE进入或者退出RRC_INACTIVE状态时，gNB需要向AMF发送RRC INACTIVE TRANSITION REPORT消息，其中携带RRC的状态：inactive或者connected。

另外两个比较重要的IE是New AMF UE NGAP ID和New GUAMI，也是我们需要关注的重点，在后续详解系列中会介绍到。

下面我们看一下RRC Inactive Assistance Information包含的具体内容：

其中：

UE Identity Index Value

该IE用于gNB计算寻呼帧，其值一般为5G-S-TMSI mod 1024（取模）。

UE Specific DRX

寻呼DRX参数。

Expected UE Behaviour

UE的活动行为信息，比如UE是静止状态或者是处于移动状态、UE的切换周期等等信息。用于辅助NG-RAN决定RRC连接的时间、帮助确定RRC_INACTIVE 状态的迁移及帮助进行RNA配置等功能。

注：

3GPP R15版本中，TS 23.502的注册流程图中没有23a这一步，但是在后面的叙述中已经有相应的内容了，只是流程图没有更新。阅读时需要注意。从前面的步骤中，也能看出来R15版本还是有很多疏漏的地方，阅读时需要多多注意。

最后一个知识点是，RRC INACTIVE核心网辅助信息在HANDOVER REQUEST、PATH SWITCH REQUEST ACKNOWLEDGE消息中也会包含，在切换场景中使用。

1.1.2.24 Nudm_UECM_Update

AMF使用Nudm_UECM_Update消息通知UDM IMS语音的支持情况"Homogeneous Support of IMS Voice over PS Sessions"。

先看该步骤的流程：

Nudm_UECM_Update消息使用的HTTP方法为：POST，

资源URI：{apiRoot}/nudm-uecm/v1/{ueId}/registrations/amf-3gpp-access

其中：{ueId}为SUPI。

消息体内容就是需要修改的参数，数据类型为：Amf3GppAccessRegistrationModification，具体定义如下图：

该步骤的响应消息比较简单，成功就是：204 No Content。

该步骤是可选的。回顾我们在第14a步骤的叙述，如果AMF根据当时收集到的信息无法确定IMS语音的支持，在14a中就不需要发送“imsVoPs”信息，通知当前的"Homogeneous Support of IMS Voice over PS Sessions"支持情况。AMF确定后，在本步骤中进行UDM的数据更新。

那么什么场景下，AMF需要给UDM发送support（即："HOMOGENEOUS_SUPPORT"）指示呢？具体场景如下：

（1）UE和网络在当前注册区（相当于TA List）中都支持IMS语音；

（2）虽然网络或者UE不支持VoNR，但是支持EPS Fallback（切换或者重定向方式），或者支持eNodeB连接5GC情况下的IMS语音，或者支持以切换或重定向方式回落到在eNodeB连接5GC网络下的IMS语音；

（3）如果网络不支持eNodeB连接5GC情况下的IMS语音，但是支持EPS Fallback（切换或者重定向方式）。

接下来我们就面临一个大疑问，如果在14a中，AMF不确定IMS语音支持情况，向UDM注册时“犹抱琵琶”,不携带“imsVoPs”信息，那么在步骤14b～23中又发生了什么，居然在24步时让AMF摇身一变，可以如此自信的向UDM发送"Homogeneous Support of IMS Voice over PS Sessions"，更新注册信息了呢？

1.1.2.24.1案发现场回顾

我们先来回顾一下案发现场，看看14a步骤之后又发生了什么事情：

（1）Step 14b：AMF获取签约数据；

（2）Step 14c：AMF订阅签约数据变化；

（3）Step 14d：old AMF去注册；

（4）Step 14e：old AMF取消订阅UDM签约数据变化；

（5）Step 15：如果new AMF不适用old PCF，则选择新的PCF；

（6）Step 16：new AMF新建立UE的接入策略；

（7）Step 17：释放UE请求的PDU Session资源；

（8）Step 18、19：3GPP接入不涉及；

（9）Step 20：AMF请求gNB初始化UE Context；

（10）Step 21：AMF回复UE注册接受消息Registration Accept；

（11）Step 22：UE发送注册确认Registrationg Complete消息；

（12）Step 23：AMF下发或修改gNB中RRC INACTIVE信息；

下面我们用排除法，排除案发后的12个步骤中AMF无法获得信息的步骤。显然，（2）～（8）、（10）（11）（12）项，AMF不可能获得额外的信息。只有第（1）、（9）项AMF可能获得额外的信息。我们先看第9项的两条上行消息：INITIAL CONTEXT SETUP RESPONSE和UE RADIO CAPABILITY INFO INDICATION。INITIAL CONTEXT SETUP RESPONSE包含的是PDU Session相关的信息，这些信息对AMF判断是否支持IMS语音没有作用。而UE RADIO CAPABILITY INFO INDICATION包含RAT相关的信息，如UE支持的power class, frequency bands等，貌似有用。再看“Step 14b：AMF获取签约数据”，该步骤对AMF做决策很有帮助，比如用户是否签约了IMS语音业务等。

1.1.2.24.2 AMF的判决数据

接下来我们再看一下，AMF判断是否支持IMS语音的基础数据有哪些：The serving PLMN provides this indication based e.g. on local policy, UE capabilities, HPLMN, whether IP address preservation is possible, whether NG-RAN to UTRAN SRVCC is supported and how extended NG-RAN coverage is, and the Voice Support Match Indicator from the NG-RAN.（TS 23.501）

这些判断基础数据虽然只是举例，但是已经够全面了，翻译过来是：

（1）AMF本地策略

（2）UE能力

（3）HPLMN IP地址是否保留

（4）HPLMN 5G到3G的SRVCC是否支持

（5）NG-RAN的覆盖情况

（6）gNB发送的Voice Support MatchIndicator

其中第（5）不涉及，（2）和（4）项基础数据，在UE的注册请求Registration Request中会携带给AMF，第（1）项是AMF本地配置的。也就是说，上面的第（1）（2）（4）项基础数据AMF在第14a步骤之前已经得到了。只剩下（3）、（6）项信息在执行第14a步时不能得到，我们分别看一下：

第（3）项“HPLMN IP地址是否保留”，应该是指SSC模式，即该模式能否保证用户的IP地址不变，对于IMS语音通话该项基本是必须的要求。

这两项内容在“Step 14b：AMF获取签约数据”中都会得到，那么还剩下最后一项“（6）gNB发给AMF的Voice Support Match Indicator”。该指示是通过AMF触发的UE Capability MatchRequest流程查询的。

TS 23.502中有一句话：“After step 14a, and in parallel to any of the preceding steps”，意思是第14a之后的步骤可以并行执行。那么这时候AMF触发的UE Capability Match Request流程可以在14a之后同步执行，而且该步骤的执行要尽量在AMF向UE发送Registration Accept之前执行完，因为Registration Accept消息的5GS network feature support IE还要用到它的执行结果。UE Capability Match Request流程用于检查UE和NG-RAN（无线接入网）对IMS语音方面的无线能力是否兼容。如果AMF没有及时收到“Voice Support Match Indicator”，AMF可能就会默认在5GS network feature support IE中下发IMS语音指示（取决于网络设备的实现），后续如果有变化再向UDM更新，也就是本步骤的作用[详见文后的注]。

1.1.2.24.3 UE Capability Match Request流程

我们看一下UE Capability Match Request的流程图：

该流程的应用场景就是UE的注册流程或者new AMF从old AMF获取的UE Context中没有包含“Voice Support Match Indicator”。下图是UE Context中包含的信息，包含有“Voice Support Match Indicator”指示：

-1 AMF 发送UE Capability Match Request

虽然该步骤在TS 23.502中的消息是UE Capability Match Request，但只是意义上的请求，实际上真正的消息名定义为：UE RADIO CAPABILITY CHECK REQUEST。

如果AMF本地不能确定UE的无线能力和NG-RAN的无线能力对IMS语音是否兼容就需要发送该消息，从下面的定义图中可以看出来，其中的UE Radio Capability是可选IE，AMF可以在该IE中包含本地保存的UE Radio Capability。gNB收到后会根据该IE来判断IMS语音的兼容性，并设置IMS Voice Support Indicator。如果该消息中不包含UE Radio Capability，则gNB会使用在第20步中INITIAL CONTEXT SETUP REQUEST发来的，保存在gNB本地的UE Radio Capability信息检查。如果AMF没有发送UE Radio Capability，gNB本地又没有，此时就会触发第2步。

UE RADIO CAPABILITY CHECK REQUEST消息的定义：

-2 UE Capabiltiy Enquiry

-3 UE Capability Information

第-2，-3步，在注册流程的第21步中已经介绍过了，这里就不再重述了。这两步都是可选项，如果第20步中已经获取过了，gNB会将UE Radio Capability保存在本地的UE Context中，并通知给AMF，AMF也会保存，不需要理解其内容。那么这两步都不会执行。

对于UE Radio Capability信息内容的详细定义，这里不介绍了。如果无线专业同学想深入学习，可以参考TS 38.331。

-4 gNB 发送UE Capability Match Response

同样，该步骤真正的消息名为：UE RADIO CAPABILITY CHECK RESPONSE，消息中包含IMS Voice Support Indicator IE，取值为：Supported或者 Not Supported。消息定义如下：

gNB可以根据运营商的配置，检查UE的某些能力是否支持IMS语音业务。

-5 gNB 将UE Radio Capability 发送给AMF

如果gNB是从UE取得的UE Radio Capability，会将其发送给AMF保存，详见第20步的详述。

1.1.2.24.4终审判决

经过2）和3）步，AMF已经收集到了所有的基础数据，这时候AMF就可以做出最终判决了。如果签约数据和兼容性都满足，AMF就会认为网络支持IMS语音，并使用Nudm_UECM_Update消息更新UDM IMS语音的支持情况"Homogeneous Support of IMS Voice over PS Sessions"。

"Homogeneous Support of IMS Voice over PS Sessions"信息的设置原则如下：

（1）如果AMF下的所有TA均支持"IMS Voice over PS Sessions"，则"Homogeneous Support of IMS Voice over PS Sessions"指示设置为：Supported；

（2）如果AMF下的所有TA都不支持"IMS Voice over PS Sessions"，则"Homogeneous Support of IMS Voice over PS Sessions"指示设置为：Not Supported；

（3）如果AMF对"IMS Voice over PS Sessions"的支持是不均质的（即：不是所有的TA都支持）或者不能断定，则不需要包含"Homogeneous Support of IMS Voice over PS Sessions"指示。

UDM做被叫域选（T-ADS）的时候会使用到这些信息。

从上面的叙述和第20步的叙述中，看起来好像比较乱套。比如初始注册（使用SUCI），第20步的Initial Context Setup Request步骤中，肯定是需要gNB向UE查询UE Radio Capability，之后上传AMF。那么第24步中AMF要不要在UE RADIO CAPABILITY CHECK REQUEST消息中携带UE Radio Capability IE就看各厂家设备的实现了。总之，这些步骤哪些要执行哪些不需要执行都是根据具体情况，唯一的原则就是：缺少信息就执行，不缺少就不执行。PLMN网络的最终准则就是尽最大的可能为用户服务。

经过上面的分析，我们可以想到在注册流程末尾更新UE的注册信息，初始注册和移动性注册场景中可能会发生。如果new AMF没有从old AMF获取到UE Context或者获取到的UE Context没有包含签约数据或者UE Radio Capability信息，AMF不能立即做终审判决时，可能就会触发第24步。

注：****

最后仍然有一个疏漏，不知道大家注意到了没有。在第2）小节：“如果AMF没有及时收到“Voice Support Match Indicator”，AMF可能就会默认在5GS network feature support IE中下发IMS语音指示（取决于网络设备的实现），后续如果有变化再向UDM更新，也就是本步骤的作用。”

这一段来自TS 23.502中的Step 21，原文：If the AMF hasn't received Voice Support Match Indicator from the NG-RAN on time then, based on implementation, AMF may set IMS Voice over PS session supported Indication and update it at a later stage.

这里，我仍然有疑问。如果AMF没有准时收到NG-RAN的返回结果，AMF该怎么在Registration Accept中设置IMS语音支持指示。如果设置为不支持，即使后来收到了NG-RAN的结果是网络支持IMS语音。这时候Registration Accept消息已经下发给UE了，UE收到后，认为网络不支持，可能就不发起IMS语音呼叫了。如果设置为支持，后来AMF的判决是不支持，这时候UE如果发起IMS语音呼叫，会直接被网络拒绝，之后再回落吗？

所以这句话虽然说的是“可以”，但实际情况还是要尽早收到UE Capability Match Response才好，否则还真有麻烦。

25. Network Slice-Specific Authentication and Authorization

UE的Allowed NSSAI中有需要NSSAA的切片时，需要触发该流程。切片的鉴权使用EAP鉴权框架，并且需要使用GPSI。该步骤也非常复杂，部分内容在第21步骤中，已经进行了部分介绍。NSSAA的详细流程，这里就不进行详解了。目前在网络中暂时还没有用到，后续使用后再进行详解。

最后对于移动性注册更新，因为new AMF从old AMF得到了UE事件的全部订阅。所以在new AMF执行完注册后，需要通知所有订阅UE可达性事件的NF。

1.1.3 移动性注册更新流程图

虽然前面的详解流程把每一步骤的触发条件都说明了，但是对于初学者判定这一步是否执行时可能仍有困难，下面把移动性注册流程图和周期性注册流程图贴一下，方便初学者学习。

在学习注册流程中，第一个需要知道在什么场景下，UE触发的是什么类型的注册流程。这部分内容在注册流程详解的第一步中有明确的说明。后面的步骤重点关注触发条件及携带的参数。这样整个注册流程学完之后，会知道其中的原理，什么特性是手机发送给网络的，什么特性是网络下发给UE的。

虽然感觉详解系列已经说明的很细致了，可能仍有一些疏漏，各位同学如果平时学习遇到疑惑可以公众号后台随时发消息。

流程图中的步骤序号相比初始注册都没有变化，初学者可以根据流程的序号对照之前的详解步骤就可以直接学习

1.1.4 周期性注册更新流程图

1.2 带AMF重选的注册流程

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

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

对于同一个厂家基站连接两个核心网POOL的情况，4G的时候华为还有相关网络资源的分配专利。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 POOL中注册的目的。

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

1.2.2 流程图

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

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

1.2.3 专享篇

gNB转发将承载有Registration Request消息的Initial UE Message（N2）发送给初始AMF。gNB选择AMF的方法详见：1.1.2.2 AMF选择。
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。

初始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节叙述的注册流程只是多了重选的步骤，其它完全一样。

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）切片选择信息

包括allowed NSSAI、Configured NSSAI、目标AMF Set或者候选AMF列表，及其它可选的信息，如下：

Allowed NSSAI和Configured NSSAI的映射；
Allowed NSSAI的网络切片实例（Network Slice instances）ID（NSI ID）；
用于执行网络切片实例（NSI）选择的NRF及用于确定AMF Set中的目标候选AMF列表NRF；
注册请求Requested NSSAI中被NSSF拒绝的S-NSSAI。

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

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

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

重点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（Universally Unique Identifier）。5GC中采用的是UUID version 4。

slice-info-request-for-registration

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

subscribedNssai：除了包含Subscribed NSSAI列表，还包含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在漫游场景时，对于归属地漫游的PDU Session建立请求，vNSSF查询hNSSF时，包含的应该是归属地的S-NSSAI。原因比较好理解，假如UE处在漫游地，发了一个只在漫游地使用S-NSSAI，归属地根本不识别。此时就会用到下面的homeSnssai IE。

roamingIndication（必选IE）：漫游指示。指示UE的漫游状态：NON_ROAMING、LOCAL_BREAKOUT、HOME_ROUTED_ROAMING。
homeSnssai（可选IE）：归属地漫游时，PDU Session建立场景使用。
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

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

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

candidateAmfList

该IE是NfInstanceId的形式，即：UUID的格式ID，而不是AMF的名字。请求消息中包含Requested NSSAI和Subscribed S-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。

1.2.4.6a Nnrf_NFDiscovery_Request

我们先看该步骤的触发条件。从第4b步骤中，初始AMF通过查询NSSF已经可以得到候选目标AMF列表（candidateAmfList）或者目标AMFSet（targetAmfSet）。

如果初始AMF得到的是目标AMF的列表，AMF根据本地配置选择一个目标AMF，如果本地保存有目标AMF的信息，如IP地址，就不需要查询NRF了。如果没有目标AMF的信息或者NSSF返回的是AMF Set就需要查询NRF，获得目标AMF的NF Profile，其中包含目标AMF的信息。

初始AMF查询NRF的服务发现流程如下图：

请求消息的HTTP方法为：GET

请求的资源URI：{apiRoot}/nnrf-disc/v1/nf-instances

GET请求的消息体为空，但是GET的查询参数非常丰富，3GPP中一共有8页之多，基本所有的网络名词都可以作为查询参数，具体详见TS29.510，这里就不细说了。

在AMF重选的注册流程中，可以使用NFInstanceID，及AMF Set ID、NF类型（AMF）作为查询参数，查询目标AMF。

1.2.4.6b Nnrf_NFDiscovery_Request Response

服务发现的查询结果如下图：

如果查询正常，匹配到了查询参数中的内容，则返回200 OK响应，响应消息体为：SearchResult。如果没有找到，会携带相应的错误原因。

SearchResult的内容就是NF在NRF中注册时的NF Profile、查询结果有效期等。详见下图：

重点信息介绍：

validityPeriod

查询结果的有效期。比如初始AMF查询完NRF后，查询结果在多长时间内有效，计时单位为：秒。需要注意的是，该值和HTTP响应消息头部“Cache-Control”中的“max-age”的值相同。

nfInstances

查询结果的NF实例，即：NF的NF Profile，里面包含NF的基本信息，比如IP地址、提供的服务等信息。初始AMF据此就可以找到目标AMF的IP地址。

需要注意的是该字段信息也可以为空，表示没有NF实例匹配上查询参数。在本例中就是没有找到合适的目标AMF。此时根据设备的实现方式，初始AMF可能会直接拒绝UE的注册，也可能就会用第7步的（B）方法，将注册消息转发给基站，由基站根据Allowed NSSAI等信息决定将注册消息路由到哪个AMF。如果再次收到消息的AMF发现是重路由的UE注册消息，本AMF还是不能支持，一定是要拒绝掉UE的注册请求的，不可能让注册消息在gNB和AMF之间踢皮球。这属于设备实现方面的问题。3GPP规范里，目前还没有读到相关的处理规则。但是基站一定不会直接拆掉RRC连接，放弃UE注册。因为即使拆掉了RRC连接，按照规范UE还是要重新建立RRC连接进行注册，会继续浪费网络资源。

searchId

如果返回消息中，包含searchId，在查询结果的有效期内，AMF可以使用该searchId查询。完整的查询即：{apiRoot}/nnrf-disc/v1/searches/{searchId}。

除正常的200 OK成功相应，其它错误响应有：307 Temporary Redirect、400 Bad Request、403 Forbidden、404 Not Found、500 Internal Server Error。

需要注意的是404 Not Found的意义并不是没有找到匹配的NF实例，而是代表查询的URI找不到，或者在分层部署NRF时，本地NRF缺少信息将请求转发或重定向到其它NRF时返回该错误码。

初始AMF收到NRF的返回信息，根据收到的候选AMF的能力信息、本地策略等选择一个合适的目标AMF。

如果初始AMF和UE之间已经建立的安全连接，也就是说网络对UE进行了鉴权，启动了NAS安全。根据1.1.2.9.4章节的叙述，此时UE和AMF之间的ngKSI指向的NAS Security Context是一致的，这样才能保证UE和AMF之间的NAS消息互相能够加密和完整性校验通过，那么，这种场景下为了避免注册失败，初始AMF会将注册NAS消息直接转发到目标AMF，也就是通过1.2.4.7a步骤的Namf_Communication_N1MessageNotify消息。

为什么直接转发可以避免注册失败呢？接着看后面的详解。

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）方法。

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还是很花时间的，对于初学者也并不适合。

最后这一步大部分只剩下技术探讨了，规范里介绍的很简单，注册流程全图的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中的安全上下文。这个场景貌似不会发生呢？

5G注册流程详解

1.1 注册流程

1.1.1 专享篇

1.1.2 优享篇

1.1.3 移动性注册更新流程图

1.1.4 周期性注册更新流程图

1.2 带AMF重选的注册流程

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

1.2.2 流程图

1.2.3 专享篇

1.2.4 优享篇

你可能感兴趣的:(通信,5g)