[精华]AMF的磨叽引发的血案（Step24）

wuyou125

相关文章会在公众号同步更新。公众号：5G通信大家学

持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。

在先容完流程详解后，会整理专题内容，比如切片、服务发现、QoS流端到端的映射等内容，各位同学不仅可以纵向学习常识点，横向也会将常识关联起来，达到深入理解灵活运用的目的。


目录



24. Nudm_UECM_Update

1）案发现场回顾

2）AMF的判决数据

3）UE Capability Match Request流程

4）终审判决
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）案发现场回顾

大家先来回顾一下案发现场，看看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语音业务等。
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

（4）IP地址是否保留

（5）5G到3G的SRVCC是否支撑以及NG-RAN的覆盖情况

（6）gNB发送的Voice Support Match Indicator

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

- 第（3）项“HPMN”，应该是指UE是否签约了IMS语音业务，即HPLMN是否允许使用IMS语音。

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

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

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更新，也就是本步骤的作用[详见文后的注]。
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步的详述。
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才好，否则还真有麻烦。