本文详细介绍了5G注册流程的最后四个步骤，包括Nsmf_PDUSession的更新与释放、与N3IWF/TNGF/W-AGF的UE上下文修改消息，以及N2接口和空口的关键消息，如INITIAL CONTEXT SETUP REQUEST、RRC层安全激活等。内容基于3GPP标准，旨在确保知识准确性，避免误导读者。后续将深入探讨5G专题内容，如切片、服务发现和QoS流映射等。
相关文章会在公众号同步更新（可看全文）。公众号：5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理，保证更新内容的准确性，避免通过二手，甚至多手的资料，以讹传讹误导网友。
在介绍完流程详解后，会整理专题内容，比如切片、服务发现、QoS流端到端的映射等内容，各位同学不仅可以纵向学习知识点，横向也会将知识关联起来，达到深入理解灵活运用的目的。
目录
17. Nsmf_PDUSession_UpdateSMContext/ Nsmf_PDUSession_ReleaseSMContext
18. 和N3IWF/TNGF/W-AGF间的UE Context Modification Request/Response
19. 和N3IWF/TNGF/W-AGF间的UE Context Modification Response等消息
（1）INITIAL CONTEXT SETUP REQUEST
（4）RRC层UECapabilityInformation
（5）N2接口消息：UE RADIO CAPABILITY INFO INDICATION
（8）INITIAL CONTEXT SETUP RESPONSE
17. Nsmf_PDUSession_UpdateSMContext/ Nsmf_PDUSession_ReleaseSMContext
该步骤可选，当AMF没有需要释放的PDU Session或者没有需要更新的PDU Session时该步骤不需要执行。这就面临触发条件的问题，什么时候会出现需要释放的PDU Session，什么时候有需要更新的PDU Session。下面分别介绍。
（1）释放PDU Session的场景
AMF发送Nsmf_PDUSession_ReleaseSMContext消息的场景：
- UE本地释放了PDU Session，需要通知网络释放相关的资源。
UE在发送Registration Request消息的PDU Session Status IE中携带了每个PDU Session的状态：0表示PDU Session处于INACTIVE状态，1表示PDU Session是ACTIVE状态。new AMF收到PDU Session内容后，会将置位的PDU Session相关的资源进行释放。
需要注意的是，第10步中Namf_Communication_ RegistrationStatusUpdate消息中也会携带需要释放的PDU Session ID，但是该消息中携带的是new AMF判断不能支持的PDU Session，需要old AMF释放，而本步骤中是UE自行决定释放的PDU Session。
注：
第10步中new AMF不支持的PDU Session由old AMF释放，这点是确定的。那么，本步骤中UE主动释放的PDU Session是由new AMF释放，还是old AMF释放呢？按照TS 23.502来看应该是new AMF释放，而old AMF只释放new AMF不支持的PDU Session。如果UE既有new AMF不支持的，又有UE自身释放的PDU Session，网络会如何处理呢？ 暂存疑，也许会合并到一起由old AMF释放，这样会减少一步。因为假如AMF不能直接访问SMF，还需要插入SMF时，如果只是为了释放一个PDU Session成本就太高了。具体等研究到PDU Session部分时再分析。
（2）更新PDU Session的场景
AMF发送Nsmf_PDUSession_UpdateSMContext消息的场景：
- UE在Registration Request消息中的Uplink data status IE中包含有需要激活的PDU Session；
- UE在执行进出NB-IOT的Inter-RAT移动性更新时，AMF会向SMF发送Nsmf_PDUSession_UpdateSMContext消息更新PDU Session信息；
- 跨AMF的注册更新，new AMF需要更新SMF中会话信息。
会话更新和释放的具体流程在这里不深入分析，等分析到会话流程时在一起分析。5G的会话流程非常复杂，远比我们平时看流程时介绍的复杂，因为涉及到和4G互操作、切换、及I-SMF/V-SMF、I-UPF等的插入和删除，消息参数特别多，5G真是太复杂了。有没有感觉到看不下去了，我都快感觉写不下去了。5G知识点太多了，每一点都够研究很长时间的。如果只是懂大概的知识，还是感觉比较简单，但是如果想细致分析，实在太复杂了。
18. 和N3IWF/TNGF/W-AGF间的UE Context Modification Request/Response
该步骤涉及到其它接入技术间的流程，国内不涉及。
19. 和N3IWF/TNGF/W-AGF间的UE Context Modification Response等消息
该步骤涉及到其它接入技术间的流程，国内不涉及。
20. N2接口及空口消息
该步骤3GPP中的流程为空。这里暂借用来介绍AMF和gNB之间的INITIAL CONTEXT SETUP REQUEST信令消息、空口消息RRCReconfiguration消息等，Registration Accept消息承载在这两条消息中。在第21步集中精力介绍NAS层Registration Accept消息。该步骤的内容对应TS 23.502中注册流程的9c、9d内容。之所以放在第20步才开始介绍原本在第9步中的内容，原因是我经过反复查找发现，实际上在第9步中AMF并没有和gNB的信令交互。既然没有信令交互，也就是说在初始注册的情况下，第11步并没有使用新的5G NAS security context来推导RRC层的密钥来对Identity Request/Response（请求PEI）进行加密和完整性保护，要么Identity Request/Response在RRC层没有加密和完整性保护，要么是使用old 5G NAS security context进行的加密和完整性保护。
3GPP只在RRC层说明了什么时候激活RRC层安全，至于和NAS层直接的对应关系没有明确说明。NAS层从哪条消息开始进行了RRC层的加密和完整性保护，需要我们自己分析。由于RRC层和NAS层都定义了Security Mode Command消息，NAS层中间有空格，RRC层中间没有空格，定义为SecurityModeCommand，对我们理解造成了很大的干扰。在TS 33.501中使用NAS Security Mode Command和AS Security Mode Command来区分。经过多次印证，RRC层的加密和完整性保护是在INITIAL CONTEXT SETUP REQUEST建立起来的。具体分析如下。
TS 38.331（RRC层信令规范）5.3.4 Initial AS security activation章节，明确说明UE是接收到网络下发的SecurityModeCommand消息后启动AS加密和完整性保护。这里的网络对于UE来讲就是gNB，该消息指的是RRC层的SecurityModeCommand消息。
接下来，我们重点关注gNB在什么时候下发该消息。查看TS38.413规范（NGAP）中，gNB在INITIAL CONTEXT SETUP REQUEST消息中获得安全密钥。TS38.413 章节8.3.1中 gNB收到该消息后的操作有：store the received Security Key in the UE context and, if the NG-RAN node is required to activate security for the UE, take this security key into use.
从这句话可以看出来，只有当UE收到INITIAL CONTEXT SETUP REQUEST时才会激活RRC层的安全流程。因为，gNB并不需要理解NAS层的信息，此处说的肯定不会是NAS层的安全。从密钥安全推导的图来看，也不存在N2接口使用的密钥，只有NAS层和RRC层。
另外，INITIAL CONTEXT SETUP REQUEST消息的定义中包含Mobility Restriction List IE（虽然是可选项）需要在第14步执行完成之后才能得到，也能够说明初始NGAP流程，应该是在14步之后执行，该不是在第9步中主鉴权流程执行完成之后，直接执行NGAP流程。
据此判断中国移动的5G路由规范在注册流程中第7步写了NGAP流程应该错误的，应该挪在Registration Accept之前。至于TS 23.502的第9步只是把安全相关的内容写到了一起，没有区分先后，这样的情况在3GPP中很多。
接下来我们分别看N2接口消息和空口消息。
（1）INITIAL CONTEXT SETUP REQUEST
该消息的目的是在gNB中创建UE Context，包括PDU session上下文、安全密钥、移动限制性列表、UE无线能力及UE的安全能力等信息。 该消息是由AMF触发的。在第1步介绍的INITIAL UE MESSAGE消息中有UE Context Request IE表示gNB请求UE Context。如果gNB没有携带该IE，AMF也会根据配置触发INITIAL CONTEXT SETUP REQUEST，否则UE的初始注册就失败了，因为gNB创建不了UE Context，也没有安全密钥等必须参数。
INITIAL CONTEXT SETUP REQUEST消息包含的内容很多，部分截图如下：
重点IE介绍：
- UE Security Capabilities
包含加密算法和完整性保护算法信息。
- Core Network Assistance Information for RRC INACTIVE
UE处于RRC_INACTIVE状态时需要的信息。
- Redirection for Voice EPS Fallback
指示AMF和UE对EPS Fallback的支持情况。gNB如果支持EPS Fallback功能，会保存该信息，用于后续的VoLTE回落判断。
- Mobility Restriction List
gNB根据该字段为UE分配处于RRC INACTIVE状态时的RNA。
- NAS-PDU IE
该字段包含Registration Accept消息，gNB透明转发给UE。
- UE Radio Capability
UE的无线能力信息，包括：power class、frequency bands等信息。如果AMF本地有，需要在该消息中发送给gNB。
- SRVCC Operation Possible
UE和AMF的SRVCC支持能力
（2）RRC层（AS层）加密和完整性保护的启用
gNG收到该消息后，除了保存相关字段信息外，还需要根据消息中的密钥参数执行RRC层的安全。和NAS层的加密和完整性保护启用步骤略有差异，具体步骤如下：
从上图可以看出来，RRC层的加密是在AS Security Mode Command和AS Security Mode Complete之后激活的。而NAS层在NAS Security Mode Complete消息中就启用了加密和完整性保护。
AS Security Mode Command消息承载在SRB1上，消息的详细定义如下
AS Security Mode Command消息的定义中，我们需要重点关注的是securityAlgorithmConfig，其中配置有RRC层的加密算法信息，nia0、nea0同样为空算法：如下：
RRC层使用的密钥是由UE和gNB根据KgNB推导出来的，不是由AMF推导出来发送给gNB的。在RRC层只是选择使用的算法。
AS Security Mode Complete消息的定义比较简单，没有什么需要关注的信息。
需要注意的是，如果UE验证AS Security Mode Command失败，会返回不经过任何保护的security mode failure消息。
（3）RRC层UECapabilityEnquiry
该步骤的执行前提是激活了AS安全保护，如果未激活是无法执行该流程的。
如果UE在CM-IDLE状态改变了UE Radio Capability信息，在发送移动性Registration Request消息中的5GS update type IE中设置“UE radio capability update needed”标记，AMF收到该消息后会删除AMF保存的UE无线能力信息。同样，在使用SUCI的初始注册或者从old AMF中没有得到UE无线能力信息，在AMF发送给gNB的INITIAL CONTEXT SETUP REQUEST消息中就不能包含UE Radio Capability IE。此时就会触发gNB执行UECapabilityEnquiry流程获取UE的无线能力。
另外，在第6步或者第11步中Identity Request消息的发送流程中，N2接口的Downlink NAS Tranport消息中包含UE Capability Info Request IE，如果设置为"requested"，在AS安全保护启动后，也会执行该步骤获取UE无线能力。
说到这里各位同学会不会觉得有点乱，到底什么时候执行？具体在什么时候执行要看情况，可选的信令流程就是这样，一定要明白触发条件。只要满足了触发条件就会执行。以注册过程为例，如果UE使用SUCI发起注册流程，则第6步不会执行获取SUCI，也就是gNB不会收到第一条Downlink NAS Tranport消息，那么接下来gNB收到第一条Downlink NAS Tranport消息的可能是第11步获取UE的PEI，此时就会携带UE Capability Info Request IE设置为：request。因为如果UE携带SUCI注册，AMF中肯定不会有UE Radio Capability信息。但是此时gNB还没有激活AS安全，无法发起UECapabilityEnquiry流程，只能挂起该操作，等到gNB收到INITIAL CONTEXT SETUP REQUEST激活了AS安全后，才会发起获取UE无线能力的流程。
（4）RRC层UECapabilityInformation
UE的无线能力信息比较大，如果超多了PDCP层的最大支持，会启用RRC层消息的分段传输功能。
（5）N2接口消息：UE RADIO CAPABILITY INFO INDICATION
gNB将获取到的最新的UE Capability Information通过UE RADIO CAPABILITY INFO INDICATION消息发送给AMF，AMF收到后会替换本地为该UE保存的无线能力信息。UE RADIO CAPABILITY INFO INDICATION消息的定义如下：
（6）RRCReconfiguration
该消息用于在空口上传递Registration Accept消息，用于UE处于RRC_CONNECTED状态时，更新RRC连接、刷新RRC连接使用的密钥参数等。该消息承载在SRB1或者SRB3上。RRCReconfiguration消息的部分定义如下：
其中：dedicatedNAS-MessageList用于传递UE和AMF之间的NAS信令；后面的sk-counter参数用于UE进行RRC层的密钥推导。
（7）RRCReconfigurationComplete
RRCReconfiguration消息的回复消息为RRCReconfigurationComplete。因为对Registration Accept消息的确认不是必须的，所以在RRCReconfigurationComplete消息中没有定义传递NAS消息的IE，这里不进行详细介绍。
（8）INITIAL CONTEXT SETUP RESPONSE
对INITIAL CONTEXT SETUP REQUEST消息的确认，如果没有PDU Session的建立和更新，只用来确认消息。
后续流程，下回分解
扫一扫
1368
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
