本文已参与「新人创作礼」活动，一起开启掘金创作之路。
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
///////////
1.1.2.24.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语音业务等。
1.1.2.24.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 IP地址是否保留
（4）HPLMN 5G到3G的SRVCC是否支持
（5）NG-RAN的覆盖情况
（6）gNB发送的Voice Support MatchIndicator
其中第（5）不涉及，（2）和（4）项基础数据，在UE的注册请求Registration Request中会携带给AMF，第（1）项是AMF本地配置的。也就是说，上面的第（1）（2）（4）项基础数据AMF在第14a步骤之前已经得到了。只剩下（3）、（6）项信息在执行第14a步时不能得到，我们分别看一下：
- 第（3）项“HPLMN IP地址是否保留”，应该是指SSC模式，即该模式能否保证用户的IP地址不变，对于IMS语音通话该项基本是必须的要求。
这两项内容在“Step 14b：AMF获取签约数据”中都会得到，那么还剩下最后一项“（6）gNB发给AMF的Voice Support Match Indicator”。该指示是通过AMF触发的UE Capability MatchRequest流程查询的。
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更新，也就是本步骤的作用[详见文后的注]。
1.1.2.24.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步的详述。
