本文已参与「新人创作礼」活动，一起开启掘金创作之路。
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
///////////
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注册成功。
