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