本文已参与「新人创作礼」活动，一起开启掘金创作之路。
相关文章会在公众号同步更新。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
///////////
1.1.2.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。
翻译过来，UE使用"null-scheme"的具体场景如下：
（1）归属网络没有提供公钥用于UE生成SUCI。比如现在4G使用的USIM卡，本身就不支持加密SUPI（IMSI）；
（2）归属网络为UE配置使用"null-scheme"。比如开户时，在USIM卡中烧录的就是"null-scheme"；
（3）UE没有有效的5G-GUTI，执行了紧急注册或者在紧急注册流程成功执行完之前又触发了去注册流程；
（4）紧急注册流程中UE收到了identity request消息，网络请求获取UE的SUCI，或者UE处于紧急注册流程成功执行完成之前的去注册流程中（后半部分意思和第（3）条其实一样）。
从上面叙述中可以看出来，虽然TS 23.502中介绍在紧急注册中获取UE的SUPI，实际上是未加密的SUCI。
上面的叙述也能证明第14a步骤（章节1.1.2.14a Nudm_UECM_Registration）的“注”中对14a步骤的触发条件做的说明，应该确定为规范编写错误。从14a步骤的上下文中也看不出来是说明的紧急注册场景。
作为扩展再介绍一下5G的R16版本中支持的PEI：
（1）IMEI
（2）IMEISV
（4）48bit的MAC地址
（5）EUI-64（IEEE Extended Unique Identifier）。
