***   欢迎转发，转发请注明出处。相关更新会在公众号同步更新，敬请关注。公众号：5G通信大家学    ***

我持续更新的相关5G内容都是直接根据3GPP整理，避免通过二手，甚至多手的资料，错误的地方以讹传讹误导网友，保证更新内容的准确性，后续网友遇到问题时可以斩钉截铁的校准，消除疑虑。

在介绍完主要流程的详解后，会计划整理专题相关的内容，比如切片、服务发现等主题内容，让网友不仅纵向学习到知识，横向也会将知识关联起来，以达到深入理解的目的。

-----------------------------------

目录

10. 消息名称：Namf_Communication_RegistrationStatusUpdate

11. 消息名称：Identity Request/Response

1.1.2.11.1紧急注册扩展知识

12. 消息名称：N5g-eir_EquipmentIdentityCheck_Get

13. UDM选择

 

---

10. 消息名称：Namf_Communication_RegistrationStatusUpdate

消息方向：new AMF -> old AMF

HTTP方法：POST

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

如果第9步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消息存在响应消息。

1. 成功相应（200 OK）

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

1. 失败相应

-  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版本中，已经全部改正了这些矛盾。目前在网上及个别厂家文档、培训教材中，该消息名称还没有改正，大家阅读到该步骤时需要注意。

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

 

12. 消息名称：N5g-eir_EquipmentIdentityCheck_Get

消息方向：AMF -> EIR

HTTP方法：POST

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

13. UDM选择

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

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

 

后续流程，留待下回分解  ......