5G注册流程分级详解(Step10-13)_identity request-CSDN博客

本文链接：https://blog.csdn.net/wuyou125/article/details/114906807

*** 欢迎转发，转发请注明出处。相关更新会在公众号同步更新，敬请关注。公众号：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消息存在响应消息。

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

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。