帮人做微信是哪个网站,深圳市宝安区邮编,wordpress字体在哪,如何进行网站设计1.1 注册流程
1.1.1 专享篇 UE发送Registration Request到(R)AN#xff0c;消息中包含注册类型、用户标识、UE能力及请求的切片等参数。 (R)AN接收到消息#xff0c;根据用户临时标识或切片选择合适的AMF#xff0c;如果(R)AN找不到合适的AMF#xff0c;则将Registration…
1.1 注册流程
1.1.1 专享篇 UE发送Registration Request到(R)AN消息中包含注册类型、用户标识、UE能力及请求的切片等参数。 (R)AN接收到消息根据用户临时标识或切片选择合适的AMF如果(R)AN找不到合适的AMF则将Registration Request发送给缺省AMF由缺省AMF进行AMF重新选择流程。 (R)AN将Registration Request消息转发给AMF。 如果Registration Request中携带的是5G-GUTIAMF发现不是自己分配的则会向调用Old AMF请求用户的上下文。 Old AMF响应New AMF返回用户上下文信息。 如果UE没有提供SUPI也没有从Old AMF处获取到SUPIAMF向UE发送Identity Request消息请求获取SUCI。 UE向AMF返回Identity Response消息消息中包含SUCI。 AMF根据SUPI或者SUCI选择一个AUSF进行用户鉴权。 AUSF执行对UE的鉴权过程。 用户新注册AMF发生改变则New AMF发送Namf_Communication_RegistrationStatusUpdate消息给Old AMF。
11AMF向UE发送Identity Request消息请求获取PEI。UE向AMF返回Identity Response消息。
12AMF向EIR发起PEI检查过程EIR向AMF返回检查结果响应。
New AMF根据SUPI选择UDM。
14a-c. AMF需要向UDM注册并获取签约数据并订阅签约数据变更通知。
14d.New AMF向UDM注册成功后UDM向Old AMF发送Nudm_UECM_DeregistrationNotify通知携带通知原因值。
14e.Old AMF向UDM取消签约数据订阅。
15如果AMF需要执行接入策略则选择一个PCF。
16New AMF和PCF进行接入策略交互。
17如果AMF改变或UE的PDU Session Status与AMF保存的不一致AMF更新SMF中会话上下文。
18、19. 国内部署不涉及。
21New AMF向UE发送Registration Accept消息接受UE发起的注册请求。如果New AMF为UE分配了新的5G-GUTI一起下发。
21b. 如果UE请求了UE策略则AMF需要和PCF执行UE策略交互。
22如果AMF为UE分配了新的5G-GUTI则UE向New AMF发送Registration Complete消息。
1.1.2 优享篇
1.1.2.1 UE发送Registration Request到(R)AN
该步骤涉及UE和gNB之间Uu接口信令交互。gNB在UE和AMF之间充当NAS信令网关的作用NAS信令在gNB中透明转发gNB不需要理解NAS信令的内容。Uu接口的信令协议栈从上往下RRC/PDCP/RLC/MAC/PHY。
1.1.2.1.1 RRC层介绍
UE在发送Registration Request消息之前需要和gNB先建立RRC连接。
UE和gNB之间在发送Registration Request消息过程中共涉及到三条RRC信令交互。具体流程如下 1.1.2.1.1.1 RRCSetupRequest
该消息用于建立RRC连接包括SRB1的建立。处于RRC-IDLE状态下的UE需要转变为RRC-CONNECTED状态时发起该过程如呼叫、响应寻呼等。UE发送完该消息后仍然可以继续进行小区重选测量及小区重选评估如果条件满足执行小区重选流程。
该消息承载在SRB0上。RRCSetupRequest消息的定义如下 其中 - InitialUE-Identity字段
UE的NAS层提供给RRC层的信息。如果上层提供了5G-S-TMSI共48bit则设置ng-5G-S-TMSI-Part1为5G-S-TMSI的最右侧39bit否则设置为39bit的随机数值注网络上有些文档写的是40bit经查询最新的TS 38.331-g20版本应该为39bit。
5G-S-TMSI也在寻呼和Service Request流程中使用可以提高效率。 - EstablishmentCause字段
该字段的取值为mo-SMS、mo-Signalling等值可用的取值详见上图。
1.1.3.1.1.1 RRCSetup
该消息用于建立SRB1其承载在SRB0上。gNB收到RRCSetupRequest消息则为UE创建UE Context并执行SRB1的准入和资源分配。如果允许建立SRB1则在RRCSetup消息中携带SRB1的完整配置信息发送给UE。UE收到该消息后进入RRC_CONNECTED状态并停止小区重选。
RRCSetup消息的定义如下 其中 - RRC-TransactionIdentifier字段
该消息相比RRCSetupRequest增加了RRC-TransactionIdentifier标识其与消息类型一起用于识别一个RRC流程transaction取值范围0-3
- RadioBearerConfig字段
携带建立SRB1的配置信息其中srb-Identity的取值为1表示建立SRB1。在RRC Setup中只允许对SRB1进行配置。
1.1.3.1.1.1 RRCSetupComplete
该消息用于UE确认已经成功完成RRC连接的建立其承载在SRB1上。UE收到RRCSetup消息后根据其中的radioBearerConfig进行无线承载配置。 其中
- ng-5G-S-TMSI-Part2
复制代码
设置为5G-S-TMSI 最左面9 bit。如果gNB在RRCSetupComplete消息中的ng-5G-S-TMSI-Value字段得到的不是完整的NG-5G-S-TMSI则利用RRCSetupRequest消息中提供右侧39bit和RRCSetupComplete消息中提供最左面9bit合并成一个完整的NG-5G-S-TMSI。
从RRCSetupComplete消息的定义中可以看到ng-5G-S-TMSI-Part2字段有两个选项既可以是ng-5G-S-TMSI也可以是ng-5G-S-TMSI-Part2。如果上层提供了5G-S-TMSI且UE收到了RRCSetup消息则设置ng-5G-S-TMSI-Value为ng-5G-S-TMSI-Part2否则设置ng-5G-S-TMSI;
- guami-Type用于指示GUAMI是从原生5G-GUTI导出的native取值还是从EPS GUTI导出的mapped取值。- registeredAMF
复制代码
UE注册的GUAMI信息用于gNB路由Registration Request消息。
UE的NAS层提供给RRC层5G-S-TMSI或者GUAMI的规则如下
· 如果UE使用了SUCI标识进行注册则不应该再包含任何GUAMI信息
· 如果是CONFIGURATION UPDATE COMMAND消息要求的注册流程则不应该提供5G-S-TMSI或者GUAMI
注
CONFIGURATION UPDATE COMMAND消息可能会改变UE的切片如果切片变化了原来的AMF可能已经无法为UE服务了。如果RRC消息又包含了5G-S-TMSI或者GUAMIgNB把注册消息路由回了原来的AMF相当于白忙活了所以此地不能再提供5G-S-TMSI或者GUAMI。NAS层提供GUAMI的使用场景是Non-3GPP场景用于N3IWF、 TNGF、W-AGF选择AMF。
· 如果UE没有5G-GUTI但是有EPS的4G-GUTI且注册原因是由于RAT改变引起的则将4G-GUTI映射成5G-GUTI之后根据映射的5G-GUTI提供GUAMI并指示该GUAMI是从EPS映射过来的。
如果当前小区在RA中则提供5G-S-TMSI不提供GUAMI如果当前的小区不在RA中则提供GUAMI不提供5G-S-TMSI
注
UE不在RA即TA List中了说明UE可能已经不在当前的AMF POOL了提供5G-S-TMSI已经没有任何意义。因为5G-S-TMSI有一部分可以用于计算寻呼。为了避免gNB实现时出错所以干脆直接就不提供5G-S-TMSI。 如果UE既没有5G-GUTI也没有4G-GUTI则都不提供。 selectedPLMN-Identity
该值包含的并不是完整的PLMN ID信息而是SIB1广播的PLMN ID列表的索引。
DedicatedNAS-Message
该消息中的DedicatedNAS-Message只用于传输initial NAS message。在3GPP中初始NAS消息共定义了4种分别是Registration Request、Deregistration Request、 Service Request及Control Plane Service Request。注册流程中的第一条Registration Request消息就包含在该字段中发送给gNB。
注
在RRC规范的定义中还有一条ULInformationTransfer消息用于上行NAS信令的传输该消息一般需要在SRB2建立之后才能用于上行NAS消息传递。如果SRB2还没有建立也可以承载在SRB1上。
从网上搜到的UE侧的信令截图可以看出Registration Request并没有使用ULInformationTransfer进行传述 s-NSSAI-List
如果UE的NAS层提供提供了一个或者多个S-NSSAI则设置该值。该值的设置与Access Stratum Connection Establishment NSSAI Inclusion Mode参数相关而该参数包含在REGISTRATION ACCEPT消息中。
如果新买的手机UE中没有保存Access Stratum Connection Establishment NSSAI Inclusion Mode参数时UE可以不提供S-NSSAI。
如果UE中保存有Access Stratum Connection Establishment NSSAI Inclusion Mode参数UE可以提供requested NSSAI或者allowed NSSAI。具体提供的是requested NSSAI还是allowed NSSAI与Access Stratum Connection Establishment NSSAI Inclusion Mode参数采用的是哪个模式相关。这里仅以中国移动的路由组织规范推荐的mode B说明。
Mode B 定义的两个场景****
1由业务请求Service Request引起的连接建立允许UE包含触发连接的各个S-NSSAI
2在周期性注册更新Periodic Registration Update、更新UE能力的注册流程中的连接建立允许UE包含Allowed NSSAI。
UE的NAS层提供给RRC层NSSAI的准则相对比较容易理解如果UE有Allowed NSSAI则优先提供Allowed NSSAI。如果UE的Allowed NSSAI在后续流程中可能引起改变时则提供Request NSSAI。具体规则如下
· 初始注册时提供的是Requested NSSAI
注册请求为移动性注册且不是由改变5GMM能力、或者改变S1 UE网络能力或者UE在5GMM-IDLE空闲模式下更新无线能力触发的注册请求时如TA改变、切片改变、请求LADN信息等提供Requested NSSAI注册请求为移动性注册且是由改变5GMM能力、或者改变S1 UE网络能力或者UE在5GMM-IDLE空闲模式下更新无线能力触发的注册请求时提供Allowed NSSAI周期性注册时提供的是Allowed NSSAI
业务请求Service Request时如果PDU Session已经有了用户面资源只是进行重建则使用重建PDU Session连接的所有NSSAI。或者触发业务请求需要进行控制面交互的NSSAI。
1.1.2.1.1 NAS层介绍
NAS层包含Registration Request消息。3GPP R16中共定义了29个IE我们先来看Registration Request消息的定义包含的内容非常多这里仅截图部分信息 重点IE介绍
5GS Registration type
5G中共有四种注册类型
1 初始注册 Initial Registration
UE开机时处于RM-DEREGISTERED状态发起的注册流程。
2 移动性注册 Mobility Registration Update
UE发起移动性注册的场景
1进入到不在TA List的新TA
2更新UE能力及协议参数和TA是否改变无关
3请求改变NSSAI信息
4R16新增UE的Preferred Network Behaviour改变和AMF当前支持的Supported Network Behaviour参数不兼容。
3 周期性注册 Periodic Registration Update
UE的T3512超时发起的注册流程。
4 紧急注册 Emergency Registration
紧急注册国内未开启。
在该IE中还有一个重要的指示当UE没有需要激活的PDU Session或者UE进行紧急注册而此时UE还有上行信令需要发送时需要设置该值即需要在该5GS Registration type IE中设置Follow-on request pending。
- 5GS mobile identity
该IE中包含SUCI或5G-GUTI或PEI。注册中UE携带的用户标识按下列优先级逐次降低提供相应的标识
1从EPS GUTI映射来的5G-GUTI
2当前UE正在注册的PLMN分配的native 5G-GUTI
3对等PLMN网络分配的native 5G-GUTI
4其它PLMN分配的5G-GUTI
5其它情况UE提供SUCI进行注册。
如果UE既有有效的EPS GUTI又有5G-GUTI则原来的5G-GUTI会放在Additional GUTI字段中。如果有多个native 5G-GUTI按照上面UE标识的选择顺序选择最高优先级的标识。
紧急注册时可以使用PEI进行注册这里不进行介绍。
- [Requested NSSAI]
该参数为可选参数Registration Request中不包含该参数的场景有
1如果UE没有allowed NSSAI 、configured NSSAI、default configured NSSAI则UE不包含requested NSSAI
2如果UE想要注册的所有S-NSSAI(s) 都在pending NSSAI中则UE不包含requested NSSAI。
Registration Request中该参数的来源有
1 Default Configurated NSSAIUE既没有Configured NSSAI又没有Allowed NSSAI时使用。Default Configurated NSSAI作为用户的签约数据保存到UDR中只有一个
2Configured NSSAI或者下述3、4情况的子集
3Allowed NSSAI或者它的子集
4Allowed NSSAI或者它的子集加上一个或者多个不包含在Allowed NSSAI中的Configured NSSAI。在确定下来这些计划注册的NSSAI后UE还需要根据URSP中的NSSP和本地配置来最终确定Requested NSSAI具体细则详见后续详解部分。
[Last visited registered TAI]
UE之前本地保存的TAI。UE发送该IE的作用是如果AMF注册成功在下发Registration Accept消息时如果TAI和原来的相同则不必在Registration Accept消息中包含TAI。
UE的初始注册、移动性注册和周期性注册Registration Accept消息都可能包含有UE注册的TAI。
- [Network slicing indication]
如果UE使用Default Configurated NSSAI进行注册则需要包含该字段在其中指示“Requested NSSAI created from default configured NSSAI”。
- [5GMM capability]
该IE中常用的能力信息有
1UE是否支持EPC NAS即UE是否支持EPC网络功能S1 mode supported
2NG-RAN到UTRAN的5G-SRVCC能力信息
R16版本的3GPP已经对从5G到3G的SRVCC功能进行了明确。如果UE支持该功能则指示 5G-SRVCC from NG-RAN to UTRAN supported并且还需包含Mobile station classmark 2 IE和Supported codecs IE。
3Radio capability signalling optimisation (RACS)能力支持信息。该功能的使用需要在网络中增加部署UCMF网元实例
4 网络切片的认证和授权Network Slice-Specific Authentication and Authorization能力信息即NSSAA。
- [5GS update type]
该IE中常用的能力信息有
1UE的SMS over NAS支持情况
2UE radio capability更新指示
UE Radio Capability包含包含RAT相关的信息如UE支持的power class, frequency bands等。AMF会保存该参数内容。如果该参数在AMF中可用AMF会通过N2消息发送给RAN保存。如果UE的状态变为RM-DEREGISTERED则AMF需要删除该参数。如果发送给RAN的N2请求不包含该参数RAN自身也没有该参数信息则会触发RAN向UE索取该参数信息并通过N2 UE RADIO CAPABILITY INFO INDICATION消息上传给AMF。如果UE在CM-IDLE状态时该参数改变了需要执行Mobility Registration Update。如果UE在CM-CONNECTED状态该参数改变UE需要先变为CM-IDLE状态之后再执行移动性注册。这部分的流程在后续会进行介绍。
- [ 5GS及EPS Preferred CIoT network behaviour信息]
该参数会影响物联网设备Registration Request请求消息从一个AMF到另一个AMF的重路由。
- [PDU session status]
指示UE在当前PLMN以前建立的PDU Session。PDU Session ID由UE进行分配取值范围为1-150保留不用。该IE适用于移动性注册或者周期性注册。
[Allowed PDU session status]
如果UE从非3GPP接入类型收到寻呼消息UE应该在注册请求中包含该IE用于指示网络UE允许通过3GPP接入类型重新建立用户面资源。
- [Uplink data status]
该IE适用于移动性注册或周期性注册流程。如果UE需要发送上行数据则需要包含该字段。如果UE有always-on PDU Session即使没有数据发送也需要包含在该参数中。但是建立always-on PDU Session的场景是在5G SM流程中PDU SESSION ESTABLISHMENT REQUEST消息中包含Always-on PDU session requested IE
该IE指示网络哪一个保留的PDU Session有挂起的数据需要发送对应的比特位设置为1。如果没有数据需要发送、或者PDU Session处于INACTIVE状态、或者PDU Session处于激活状态但是用户面资源已经建立起来了则相应的比特位设置为0。PDU session status指示出哪些PDU Session是非ACTIVE或者INACTIVE。
- [Payload container]、[Payload container type]
如果UE有保存的UE policy sectionsUE策略可以使用一个或者多个UE policy sectionUE需要设置Payload container type IE为UE policy container 并在Payload container IE中包含UE STATE INDICATION消息。网络收到该消息后会执行UE Configuration Update流程下发新的UE策略。
下面看一下UE STATE INDICATION消息的内容 其它可以包含在的负荷类型有 当负荷类型为SMS时payload container IE的内容为SMS的内容包括CP-DATA, CP-ACK or CP-ERROR详见3GPP TS 24.011
- [NAS message container]
该字段存在的先决条件如下这三条需要同时满足才能包含该字段
1 Registration Request作为初始NAS消息
2 UE存在有效的5G NAS安全上下文
3 UE有需要密文发送的内容。
在没有NAS安全上下文的情况下UE可以明文发送的内容有
1 Extended protocol discriminator;
2 Security header type;
3 Spare half octet;
4 Registration request message identity;
5 5GS registration type;
6 ngKSI;
7 5GS mobile identity;
8 UE security capability;
9 Additional GUTI;
10 UE status
11 EPS NAS message container.
注****
Registration Request本身就是一条NAS层的消息但在该条消息中又包含一个[NAS message container] IE规范对该IE的解释为The purpose of the NAS message container IE is to encapsulate a plain 5GS NAS REGISTRATION REQUEST or SERVICE REQUEST message, or to encapsulate non-cleartext IEs of a CONTROL PLANE SERVICE REQUEST message. 那么这个NAS message container和UE构建的Registration Request消息有什么区别
经过仔细查询答案是该IE用来封装不允许明文发送的部分内容将其打包在了[NAS message container] IE中。
在TS 24.501中解释plain 5GS NAS message为非加密的明文消息加密的5GS NAS MESSAGE SECURITY PROTECTED 5GS NAS MESSAGE不是plain 5GS NAS messages。
5G之所以在NAS层的Registration request消息中又包含了一个[NAS Container]是因为5G系统支持初始NAS消息的保护初始NAS消息包含REGISTRATION REQUEST, SERVICE REQUEST and CONTROL PLANE SERVICE REQUEST。如果AMF收到了包含NAS Container的信息AMF优先处理container中的REGISTRATION REQUEST消息。
经过查看现网信令[NAS message container]中既包含可以明文传递的部分又包含不允许明文传递的部分即[NAS message container]中包含完整的注册消息的全部字段。而Registration Request这条NAS消息的[NAS message container]外部只包含可以明文传递的部分两者部分内容是重复的。
1.1.2.2 AMF选择
gNB收到RRCSetupComplete消息根据RRC层包含5G-S-TMSI或GUAMI来对NAS消息进行路由。AMF选择的具体的规则如下
1如果UE既没有提供GUAMI或5G-S-TMSI又没有提供NSSAI信息如UE使用SUCI进行注册则gNB根据RAT类型将Registration Request消息路由到default AMF
2如果UE提供了GUAMI或5G-S-TMSI也提供NSSAI信息如果gNB根据GUAMI或5G-S-TMSI能匹配到合适的AMF则将Registration Request消息路由到该AMF如果根据GUAMI或5G-S-TMSI没有匹配到合适的AMF根据NSSAI信息选择一个AMF将注册消息路由到该AMF
3如果消息中UE只提供了NSSAI信息则根据NSSAI信息选择AMF并将注册消息路由到该AMF。
4其它匹配不到合适AMF的情况根据RAT路由到default AMF。
注****
3GPP TS 23.501和中国移动的5G路由组织规范在AMF选择部分都使用了Requested NSSAI作为AMF选择的参数。从上面介绍的RRC信令交互部分的内容和Uu接口协议栈可以知道在这里使用Requested NSSAI个人感觉并不准确。因为Requested NSSAI是NAS消息层的概念gNB并不理解NAS消息的内容根本无法使用NAS消息中包含的内容。gNB能够利用的只有UE的NAS层传递给RRC层的NSSAI信息而RRC层的NSSAI信息可以是Requested NSSAI也可以是Allowed NSSAI。
1.1.2.3 gNB转发Registration Request消息给AMF
gNB选择完AMF后向AMF发送INITIAL UE MESSAGE初始N2消息。为该UE分配一个唯一的RAN UE NGAP ID也包含在INITIAL UE MESSAGE消息中。gNB从选择的AMF且该AMF可用的TNL associations中选择一个可以用于发送初始消息的TNL associationsTNL Association的权重因子为0的不能用于初始N2消息的发送为该UE创建NGAP UE-TNLA-binding并通过选定的TNL association转发该UE的消息到AMF。
TNL Association应该就是SCTP层的Association第一个TNL Association在gNB上电后根据配置的IP地址和端口号与AMF建立Association后续如果需要增加TNL Association时AMF需要向5G-AN发送AMF CONFIGURATION UPDATE消息该消息中包含增加TNL Association的IP地址和端口号。TNL Association最多可以创建32个。
INITIAL UE MESSAGE只用于发送上行的第一条NAS消息。后续的NAS消息使用UPLINK NAS TRANSPORT。既然两条消息都用于传输上行NAS消息为什么会有这个区别我们先来看这两条消息的定义。
INITIAL UE MESSAGE消息的定义
UPLINK NAS TRANSPORT消息的定义
从上面两条消息的定义可以看出来INITIAL UE MESSAGE只需要包含gNB本侧的RAN UE NGAP ID而UPLINK NAS TRANSPORT需要知道gNB和AMF两侧的UE NGAP ID才能进行通信这个两个字段又都是必选字段。所以3GPP定义了两条消息。在gNB和AMF之间第一回合的交互中互相知道了对方的UE NGAP ID后才能使用UPLINK NAS TRANSPORT消息传递NAS消息。对于传输下行NAS消息的DOWNLINK NAS TRANSPORT不存在这样的问题因为gNB发送完第一条INITIAL UE MESSAGE消息后已经将本侧的RAN UE NGAP ID带给了AMF。
注**** * 在INITIAL UE MESSAGE消息中还包含Allowed NSSAI IE规范的解释If the Allowed NSSAI IE is included in the INITIAL UE MESSAGE message the AMF shall use the IE as defined in TS 23.502 [10].但是在TS 23.502中并没有明确指出该IE的使用场景。那么什么情况下会在INITIAL UE MESSAGE消息中包含Allowed NSSAI呢按正常的逻辑Allowed NSSAI是在注册请求完成后AMF下发给UE的Registration Accept才会有Allowed NSSAI而这里在初始N2消息中就包含Allowed NSSAI相当奇怪了。*
经过仔细查找发现在注册过程中如果AMF出现重选的场景下如果需要RAN转发初始注册请求可能会在INITIAL UE MESSAGE中出现Allowed NSSAI。初始AMF和UDM、NSSF已经交互完成得到了切片相关的信息此时如果初始AMF不能为UE服务而目标AMF和初始AMF不在同一个AMF Set此时可能就需要RANgNB转发注册请求。AMF发送Reroute NAS Request消息给gNBgNB发现在该消息中存在Allowed NSSAI会在发送给目标AMF的Initial UE Message消息中包含Allowed NSSAI IE和Source to Target AMF Information Reroute IE。
1.1.2.3 gNB转发Registration Request消息给AMF
gNB选择完AMF后向AMF发送INITIAL UE MESSAGE初始N2消息。为该UE分配一个唯一的RAN UE NGAP ID也包含在INITIAL UE MESSAGE消息中。gNB从选择的AMF且该AMF可用的TNL associations中选择一个可以用于发送初始消息的TNL associationsTNL Association的权重因子为0的不能用于初始N2消息的发送为该UE创建NGAP UE-TNLA-binding并通过选定的TNL association转发该UE的消息到AMF。
TNL Association应该就是SCTP层的Association第一个TNL Association在gNB上电后根据配置的IP地址和端口号与AMF建立Association后续如果需要增加TNL Association时AMF需要向5G-AN发送AMF CONFIGURATION UPDATE消息该消息中包含增加TNL Association的IP地址和端口号。TNL Association最多可以创建32个。
INITIAL UE MESSAGE只用于发送上行的第一条NAS消息。后续的NAS消息使用UPLINK NAS TRANSPORT。既然两条消息都用于传输上行NAS消息为什么会有这个区别我们先来看这两条消息的定义。
INITIAL UE MESSAGE消息的定义 UPLINK NAS TRANSPORT消息的定义 从上面两条消息的定义可以看出来INITIAL UE MESSAGE只需要包含gNB本侧的RAN UE NGAP ID而UPLINK NAS TRANSPORT需要知道gNB和AMF两侧的UE NGAP ID才能进行通信这个两个字段又都是必选字段。所以3GPP定义了两条消息。在gNB和AMF之间第一回合的交互中互相知道了对方的UE NGAP ID后才能使用UPLINK NAS TRANSPORT消息传递NAS消息。对于传输下行NAS消息的DOWNLINK NAS TRANSPORT不存在这样的问题因为gNB发送完第一条INITIAL UE MESSAGE消息后已经将本侧的RAN UE NGAP ID带给了AMF。
注****
*在INITIAL UE MESSAGE消息中还包含Allowed NSSAI IE规范的解释If the Allowed NSSAI IE is included in the INITIAL UE MESSAGE message the AMF shall use the IE as defined in TS 23.502 [10].但是在TS 23.502中并没有明确指出该IE的使用场景。那么什么情况下会在INITIAL UE MESSAGE消息中包含Allowed NSSAI呢按正常的逻辑Allowed NSSAI是在注册请求完成后AMF下发给UE的Registration Accept才会有Allowed NSSAI而这里在初始N2消息中就包含Allowed NSSAI相当奇怪了。
经过仔细查找发现在注册过程中如果AMF出现重选的场景下如果需要RAN转发初始注册请求可能会在INITIAL UE MESSAGE中出现Allowed NSSAI。初始AMF和UDM、NSSF已经交互完成得到了切片相关的信息此时如果初始AMF不能为UE服务而目标AMF和初始AMF不在同一个AMF Set此时可能就需要RANgNB转发注册请求。AMF发送Reroute NAS Request消息给gNBgNB发现在该消息中存在Allowed NSSAI会在发送给目标AMF的Initial UE Message消息中包含Allowed NSSAI IE和Source to Target AMF Information Reroute IE。*
1.1.2.4 Namf_Communication_UEContextTransfer
new AMF调用old AMF的服务获取UE上下文信息。
如果UE的Registration Request消息携带5G-GUTI进行注册并且AMF发生了变化此时新的AMFnew AMF会向UE原来注册的AMFold AMF请求UE上下文信息包含SUPI、GPSI、5GMM Capability等参数UE上下文的内容详见TS 23.502。
new AMF采用POST方法调用old AMF的Namf_Communication_UEContextTransfer服务。具体使用的URI格式为
{apiRoot}/namf-comm//ue-contexts/{ueContextId}/transfer
调用该服务携带的请求消息内容为UeContextTransferReqData。
注
*1通用的URI结构为
*{*apiRoot}///
**2对于SBI接口采用POST方法还是PUT方法的区别
服务的生产者选择资源的标识符和URI则采用POST方法服务的消费者选择资源的标识符和URI则采用PUT方法。*
下面看一下该POST请求的URI参数
{apiRoot}
该字段和我们日常上网在IE地址栏中输入的内容一样以http或者https开头的地址后面是IP地址和端口号等信息
namf-comm
AMF上用于信息传递的API名称。其它API名字为namf-mt、namf-loc、namf-evts 目前在R16版本中全部为“v1”后续如果有大的功能变更可能会有更新的版本。
ue-contexts
请求UE Context的固定值。
{ueContextId}
请求的UE Context的标识可以为5G-GUTI、SUPI或者PEI使用的格式如下
15G-GUTI5g-guti-[0-9]{5,6}[0-9a-fA-F]{14}
2SUPI(imsi-[0-9]{5,15}|nai-.|.)
3(imei-[0-9]{15}|imeisv-[0-9]{16}|.)
3GPP使用正则表达式进行描述我们只需要知道对应的标记5g-guti、imsi、nai、imei、imeisv加上短横线再加上具体的值即可。IMEI和IMEISV用于紧急注册目前在国内不会遇到。我们能够遇到的基本都是5g-guti或者imsi。
transfer
传递已经存在的UE Context释放的方法。其它的可能方法有transfer-update后续流程中Namf_Communication_RegistrationStatusUpdate消息使用的就是该方法、release、assign-ebi。
该URI请求的内容UeContextTransferReqData
SBI接口的消息内容采用JSON编码。Namf_Communication_UEContextTransfer消息的请求内容定义如下 reason
可选的取值为INIT_REG、MOBI_REG、MOBI_REG_UE_VALIDATED。
当UE执行初始注册时取值为INIT_REG
当UE执行移动性注册时取值为MOBI_REG
当首次获取UE Context失败AMF和AUSF执行UE鉴权成功后再次获取UE Context时使用MOBI_REG_UE_VALIDATED。
accessType
可选的取值为3GPP_ACCESS或者NON_3GPP_ACCESS。
[plmnId]
即MCC和MNC。
[regRequest]
注册流程的完整Registration Request消息包含在该参数中。
[supportedFeatures]
特性支持相关的字符串。
我们先来看一下new AMF调用该操作的处理过程
1对于初始注册和移动性注册如果有5G-GUTI第一次向old AMF请求获取UE上下文的输入参数为5G-GUTI、Access Type、Reason和完整的Registration Request。AMF返回的信息如下
A 如果注册原因为INIT_REG并且old AMF执行完整性检查成功则返回不包含PDU Session信息的UE上下文。如果old AMF根据new AMF的PLMN ID判断不能将N2接口重定位到new AMF则只返回supi跨PLMN的情况
B 如果注册类型为MOBI_REG并且old AMF执行完整性检查成功返回200 OK消息包含完整的UE Context含有PDU Session信息。
2如果第一次old AMF完整性检查失败返回给new AMF的响应为403 Forbidden携带原因值“INTEGRITY_CHECK_FAIL”UE和AUSF鉴权成功后再次向old AMF请求UE Context的消息和第一次请求的消息略有不同三个不同点如下
A 第二次{ueContextId}的取值为SUPI。因为在UE和AUSF的鉴权流程中new AMF已经得到了SUPI所以第二次直接携带SUPI请求UE Context
B 第二次“reason”的取值为MOBI_REG_UE_VALIDATED
C 第二次消息中不包含Registration Request消息也就是不包含[regRequest]参数。
old AMF在处理该请求时会跳过完整性检查直接回复“200 OK 并携带完整的UE上下文包含PDU Session相关的信息。
1.1.2.5 Namf_Communication_UEContextTransfer Response
1成功响应
如果old AMF处理成功在Namf_Communication_UEContextTransfer Response消息中返回200 OK 响应并携带UE Context。响应消息的消息体包含的内容为UeContextTransferRspData该数据类型定义如下 2响应失败
A 403 Forbidden
如果old AMF对请求消息中的Registration Request消息完整性检查失败则设置原因值“INTEGRITY_CHECK_FAIL”。
B 404 Not Found
如果old AMF没有找到对应的UE Context则返回该响应并设置原因值为“CONTEXT_NOT_FOUND”
获取 UE Context 流程中的注意点****
l 如果在切换流程中new AMF已经从old AMF中获取到了UE则在注册流程中就不需要向old AMF重新获取了即在注册流程中的第4510步骤都不需要执行。
l 如果old AMF有不同于当前accessType的PDU SessionAMF判断该PDU Session无法重定位到新的AMF则AMF只返回SUPI并指示消息已经经过完整性验证不包含UE Context的其他部分SUPI包含在UeContext数据类型中。
l 跨PLMN移动的时候UE Context中的信息包含的是HPLMN S-NSSAI的信息可以对应到Allowed NSSAI的S-NSSAI而不是old PLMN的Allowed S-NSSAI。
l UE注册到新的AMF后不需要重新订阅事件因为UEContext中包含事件订阅的信息。如下 1.1.2.6 Identity Request
如果在Registration Request中UE没有提供SUCI则AMF向UE发送Identity Request消息请求获取UE的SUCI。
注
*在TS 23.502规范中注册流程该步骤的解释为If the SUCI is not provided by the UE nor retrieved from the old AMF the Identity Request procedure is initiated by AMF sending an Identity Request message to the UE requesting the SUCI.
“UE从old AMF没有获取到SUCI”也是发送Identity Request消息的前提。但是我们在UE Context的定义中并没有发现SUCI字段也就是UE Context并不保存UE的SUCI。另外从Namf_Communication_UEContextTransfer Request的响应中可以知道要么成功响应返回SUPI要么获取失败返回403 Forbidden或者404 Not Found此时new AMF什么都不会得到。
根据TS 33.501章节6.1.2The SEAF shall include the SUPI in the Nausf_UEAuthentication_Authenticate Request message in case the SEAF has a valid 5G-GUTI and re-authenticates the UE. Otherwise the SUCI is included in Nausf_UEAuthentication_Authenticate Request.* *可以知道主鉴权流程使用的参数要么是SUCI要么是SUPI。
个人判断TS 23.502此处编写有误new AMF从old AMF得到SUCI的场景是不存在的只能得到SUPI。SUCI是SIM或者ME计算得到的每次计算的值都不一样AMF也没有必要保存SUCI。*
NAS消息Identity Request消息的定义如下 该消息中重点关注的字段为Identity Type该字段指明了AMF请求的是哪一个5GS标识。可以请求的5GS标识如下图最后一句话很重要所有不能识别的标识都认为是SUCI。 该NAS消息承载在AMF和gNB之间的DOWNLINK NAS TRANSPORTN2接口消息消息中发送给gNB之后gNB将NAS消息承载在RRC层的DLInformationTransfer消息中发送给UE。
DLInformationTransfer消息承载在SRB2在SRB2未建立时也可以使用SRB1中逻辑信道DCCH。 1.1.2.7 Identity Response
UE向AMF回复Identity Response消息。
该NAS消息中的重点字段为Mobile identity。UE可以发送SUCI、5G-GUTI、IMEI、IMEISV、5G-S-TMSI、MAC地址或者EUI-64作为5GS mobile identity。 该NAS消息在UE和gNB间承载在RRC层的ULInformationTransfer消息中。
ULInformationTransfer消息承载在SRB2在SRB2未建立时也可以使用SRB1中逻辑信道DCCH。 gNB收到Identity Response消息后封装在Uplink NAS TransportN2接口消息消息中发送给AMF。
RRC层消息DLInformationTransfer和ULInformationTransfer用于在UE处于RRC-CONNECTED状态时传递NAS消息。 1.1.2.8 AUSF选择
在AMF从UE得到SUCI或者从old AMF得到SUPI后通过NRF执行服务发现选择AUSF执行鉴权流程。
1.1.2.9 Authentication/Security流程。
1.1.2.9.0 准备知识
该步骤为UE的5G鉴权流程本文以目前使用的5G AKA鉴权方式为例介绍。5G AKA相比4G增加了归属网络的鉴权功能。4G的鉴权由MME完成而5G的鉴权由AMF和AUSF共同完成并且5G的鉴权向量不支持预取也不支持一次获取多组鉴权向量。
归属网络的AUSF提供鉴权过程的锚点密钥anchor keyKSEAF它是由加密保存在AUSF中的中间密钥Kausf计算得到的。5G中锚点密钥和和服务网络Serving Network进行绑定向UE提供隐式的服务网络认证。绑定的方式是将5G SN名称作为密钥推导的输入参数。
1.1.2.9.0.1 5G SNNServing Network Name
5G SNN 的作用
· 用于推导锚点密钥作为AUSF推导Kseaf的输入参数及作为UE推导RES和XRES的输入参数
· 将锚点密钥和服务网络绑定
· 通过将服务码Service code设置为“5G”来保证锚点密钥用于5G核心网和UE之间的鉴权认证。
5G SNN 的构成
SNN最长1020个字节由两部分构成SNN-service-code和SNN-network-identifier中间用冒号“:”进行连接。
由于在认证和鉴权过程中安全密钥需要在UE和SEAF位于AMF中中分别推导因此SNN作为密钥推导的输入参数需要在UE和SEAF分别进行构造。
· SNN-service-code固定为“5G”。在通过non-3GPP接入时也用于区分接入网络作为Access Network Identity使用
· SNN-network-identifier用于识别当前的移动网络。根据TS 24.501章节9.12.1规定对于PLMN网络该值为mncXXX.mccXXX.3gppnetwork.org都为小写字母。对应中国移动的5G网络SNN-network-identifier为mnc000.mcc460.3gppnetwork.org。
UE侧根据RAT、USIM卡中的信息及小区广播的PLMN等信息可以很容易推导出SNN进而用于安全密钥的推导而AMF侧根据配置信息也可以构造出SNN用于鉴权和认证。
1.1.2.9.0.2 鉴权流程的触发条件
通常与UE建立信令连接的流程都可以触发鉴权流程。我们常见到的场景为
· UE使用SUCI发起注册流程
· AMF没有UE的有效上下文
· Registration Request消息没有被完整性保护
· UE携带5G-GUTI注册但是old AMF对注册请求消息执行完整性检查失败
1.1.2.9.1 鉴权流程
本部分的鉴权流程分成三个部分
A 鉴权流程请求阶段
B 鉴权流程响应阶段
C 鉴权流程鉴权确认和注册绑定部分
1.1.2.9.1.1 鉴权流程请求阶段 1 Nausf_UEAuthentication_Authenticate Request****
消息方向AMF/SEAF - AUSF
HTTP方法POST
在整体注册流程的第8步中AMF根据从UE得到的SUCI或者从old AMF得到的SUPI选择对该UE进行鉴权的AUSF构造Nausf_UEAuthentication_Authenticate Request消息并发送给该AUSF。
该请求的资源URI为
{apiRoot}/nausf-auth/v1/ue-authentications
携带的参数类型为AuthenticationInfo具体的字段信息如下图我们常见到的IE为SUPI或者SUCI及SNN 只要AMF得到了UE的SUPI在Nausf_UEAuthentication_Authenticate Request消息中包括的都是SUPI除非AMF不知道UE的SUPI才会在该消息中包含SUCI。
AUSF收到请求消息后会检查消息中的Serving Network Name是否得到了授权。如果检查失败则返回403 Forbidden携带的原因值为SERVING_NETWORK_NOT_AUTHORIZED。
2 Nudm_UEAuthentication_Get Request
HTTP方法POST
消息方向AUSF - UDM
该请求的资源URI为
{apiRoot}/nudm-ueau/v1/{supiOrSuci}/security-information/ generate-auth-data
该消息用于AUSF请求UDM为UE选择一种鉴权方法并且如果本次鉴权需要鉴权向量还会请求UDM计算新的鉴权向量。如果请求中包含的是SUCIUDM收到该请求后首先SIDF将SUCI解密为SUPI之后根据SUPI为UE选择鉴权方式。目前5G使用的鉴权方式有两种EAP-AKA’ 和5G AKA。
请求消息AuthenticationInfoRequest的内容如下图 重点信息介绍
ResynchronizationInfo 该字段包含两项内容rand和auts。在鉴权重同步过程中AUTS由UE计算得到。
1.1.2.9.1.2 鉴权流程响应阶段 1 UDM生成鉴权向量****
UDM/ARPF在生成鉴权向量时需要将Authentication Management Field (AMF)的separation bit设置为1。separation bit为AUTN中AMF字段的第0比特该值为1表示生成的鉴权向量用于EPS/5G AKA鉴权如果设置为0标识该鉴权向量用于GSM、UMTS等非EPS/5G AKA鉴权具体原理详见TS33.1026.4.3章节及附录F。对于鉴权向量来讲如果设置为1AKA鉴权过程中产生的CK和IK鉴权密钥不会离开HSS。
UDM/ARPF推导出 KAUSF并计算XRES*在推导Kausf和XRES时都会将serving network name作为输入参数使用。最后UDM/ARPF生成的5G HE AV包含RAND、AUTN、XRES、KAUSF四个参数。其中鉴权令牌AUTN SQN Å AK || AMF || MAC。
2 Nudm_UEAuthentication_Get Response****
消息方向UDM - AUSF
· 成功响应
返回200 OK响应。UDM计算出5G HE AVRAND、AUTN、XRES*、KAUSF并在响应消息中返回给AUSF。携带AuthenticationInfoResult内容。
该响应消息包含AuthenticationInfoResult具体内容如下 supi
如果请求消息中是SUCIUDM会使用SIDF解密出SUPI并在该字段中返回给AUSF。
authType
AUSF根据该字段为UE开启5G_AKA鉴权流程或者EAP_AKA_PRIME鉴权流程。
选择的鉴权类型共有三个取值EAP_AKA_PRIME、5G_AKA和EAP_TLS其中EAP_TLS 3GPP标准并不强制要求支持。
AuthenticationVector
鉴权向量包含的内容如下 其中
avType
取值两种5G_HE_AKA和EAP_AKA_PRIME。
rand
共128比特16字节。
autn
共128比特16字节。AUTN的构成(SQN xor AK)||AMF||MAC共481664 bits。
· 失败响应
403 Forbidden
可能的原因值为AUTHENTICATION_REJECTED、INVALID_HN_PUBLIC_KEY_IDENTIFIER、INVALID_SCHEME_OUTPUT
404 Not Found
如果用户没有开户则携带原因值USER_NOT_FOUND
501 Not Implemented
原因值UNSUPPORTED_PROTECTION_SCHEME。
3 AUSF 保存XRES*
AUSF临时保存响应消息中的XRES*和SUPI用于归属地的鉴权比较。
注
在TS33.501中该步骤的解释为“The AUSF shall store the XRES temporarily together with the received SUCI or SUPI.”。也就是说本步骤AUSF也可能保存SUCI。不知道在什么场景下会出现AUSF临时保存SUCI从上述Nudm_UEAuthentication_Get Response成功的200 OK响应AuthenticationInfoResult内容来看并没有定义SUCI字段。在失败响应中只有403 Forbidden原因值INVALID_SCHEME_OUTPUT表示无法解密SUCI也没有带回SUCI。怀疑3GPP该步骤的解释应该为编写错误。*
4 AUSF 计算XRES*****
AUSF根据接收到的5G HE AVRAND、AUTN、XRES*、KAUSF来计算5G AVRAND、AUTN、HXRES*、KSEAF根据XRES计算出HXRES根据KAUSF计算出KSEAF计算KSEAF仍然需要serving network name作为输入参数。锚点密钥Kseaf此时诞生。
5 Nausf_UEAuthentication_Authenticate Response****
消息方向AUSF - AMF/SEAF
AUSF 删除KSEAF并在Nausf_UEAuthentication_Authenticate Response消息中向AMF返回5G SE AV (RAND, AUTN, HXRES*) 。
从上述可见AUSF产生的5G AV并没有直接发送给AMF而是分两步发送第一步发送5G SE AV用于拜访地鉴权第二步如果拜访地鉴权成功返回RES*归属地鉴权成功后将锚点密钥Kseaf发送给AMF此时才将完整的5G AV发送给了AMF。
该Response的内容如下 消息IE介绍
authType
指示UE本次鉴权网络选择的鉴权方法共有三个取值EAP_AKA_PRIME、5G_AKA和EAP_TLS。
_links
该字段包含本次鉴权UE返回RES后AMF向归属地返回RES时需要调用的AUSF的资源URI。如果是5G AKA该字段的值为“5g-aka”和执行鉴权确认的超链接URI如http://172.16.141.122:8080/nausf-auth/v1/ue-authentications/06120902071/5g-aka-confirmation。如果是EAP鉴权该字段的值为eap-session及执行EAP Session的URI。
5gAuthData
包含上一步骤的5G SE AV (RAND, AUTN, HXRES*)。 6 Authentication Request NAS 消息****
消息方向AMF/SEAF - UE
AMF/SEAF保存接收到的HXRES*并向UE发送Authentication Request消息启动T3560计时器消息中包含RAND、AUTN、ngKSI、ABBA等参数。ME转发接收到的Authentication Request消息中的RAND和AUTN 给USIM。
5G AKA流程都是由网络发起的UE可以拒绝网络发起的鉴权请求。
Authentication Request消息包含在N2接口的Downlink NAS Transport和Uu接口的RRC层DLInformationTransfer消息中发送给UE。
Authentication Request消息定义 消息IE介绍
ngKSI
ngKSI是由SEAF生成的取值范围0-63bit7保留。如果UE发送给网络的ngKSI7表示没有密钥可用。ngKSI用于在UE和AMF中识别Kamf。在后续鉴权成功后用于识别5G安全上下文。如果在初始NAS消息Registration Request消息中包含了ngKSIAMF需要在Authentication Request中分配一个不同的ngKSI。
ABBA
ABBA参数为保持前向兼容其长度可变在R16版本中长度为2个字节值规定为0x0000用于推导Kamf作为输入参数。该参数用于防止降级攻击。
Authentication parameter RAND/ Authentication parameter AUTN
均为从AUSF收到的数据。
EAP message
对于5G AKA鉴权不包含该IE。
注****
百度百科上的降级保护内容供参阅降级攻击Downgrade attack是一种对计算机系统或通讯协议的攻击。在降级攻击中攻击者故意使系统放弃新式、安全性高的工作方式如加密连接反而使用为向下兼容而准备的老式、安全性差的工作方式如明文通讯。例如在OpenSSL中曾经存在一个缺陷从而使攻击者能够让SSL/TLS服务器与客户端创建老版本TLS连接尽管双方事实上支持新版本。这样的攻击是最常见的降级攻击。
7 UE 计算RES*****
USIM收到RAND和AUTN需要先检查AUTN中的MAC区域验证接收的AUTN新鲜度。验证通过后USIM计算RES并和CK、IK一起返回给ME。如果USIM 根据CK和IK计算出了Kc (如GPRS Kc) 也发给了ME则ME忽略该值在USIM和ME上都不保存该值。之后ME根据收到的RES计算RES*serving network name、RAND等作为输入参数。ME根据CK||IK 、serving network name 及AUTN中的SQN Å AK 计算出KAUSF进而计算出 KSEAF serving network name作为输入参数。最后ME检查AUTN的AMF域的separation bit是否为1。
8 Authentication Response NAS 消息****
消息方向 UE - AMF/SEAF
UE构造Authentication Response消息发送给AMF/SEAF。AMF/SEAF收到Authentication Response消息后停止T3560计时器。
Authentication Response消息包含在Uu接口RRC层的ULInformationTransfer消息和N2接口的Uplink NAS Transport消息中发送给AMF/SEAF。
Authentication Response消息定义 消息IE介绍
Authentication response parameter
该参数为UE计算的RES*。在5G AKA中RES*由ME计算得到16字节长度在4G中RES由USIM计算得到最短4字节最长16字节。
9 AMF/SEAF 计算HRES*****
AMF/SEAF根据UE发送的RES计算出HRES 输入参数有RES*、RAND等SEAF比较HRES和HXRES如果二者一致则认为UE在当前的拜访网络鉴权成功。之后执行第10步通过Nausf_UEAuthentication_Authenticate Request消息将RES*发送给AUSF进行归属地鉴权。
如果HRES和HXRES不一致则认为UE在拜访网络鉴权失败仍然会继续执行第10步只是此时不携带RES*而是携带空值以通知AUSF在拜访地鉴权失败。
如果此时UE不可达SEAF不会收到RES* 则SEAF认为本次鉴权失败并通知AUSF。
注
网络上及个别厂家文档写到如果拜访网络鉴权失败流程结束。该说法并不准确即使拜访网络鉴权失败仍然会通知归属地AUSF。
如果在后面第12步中AUSF返回给SEAF鉴权结果Nausf_UEAuthentication_Authenticate Response消息中指示RES在归属地鉴权失败或者RES在拜访网络的SEAF中鉴权失败则认为UE本次鉴权失败。如果UE使用SUCI发起的注册请求则SEAF向UE发送UE Authentication Reject消息如果UE使用的5G-GUTI发起的注册请求AMF会尝试向UE请求SUCI再次进行鉴权尝试。如果最终UE鉴权失败会收到Authentication Reject消息。
在UE侧如果UE对Authentication Reject消息完整性检查通过UE会设置update status为5U3 ROAMING NOT ALLOWED并删除保存的5G-GUTI、TAI list、last visited registered TAI和ngKSI。在UE关机或者USIM卡更换之前不会再进行重新注册。如果Authentication Reject完整性检查失败在30分钟到60分钟之间会再次发起注册。
10 Nausf_UEAuthentication_Authenticate Request****
消息方向 AMF/SEAF - AUSF
HTTP方法PUT注意EAP鉴权方式时本步骤为POST方法
该请求消息调用AUSF的资源URI:
{apiRoot}/nausf-auth/v1/ue-authentications/{authCtxId}/5g-aka-confirmation
该URI在第5步的响应消息_links字段携带也可以由AMF自行构造。如果构造的不准确则会返回响应消息404 Not Found携带原因值CONTEXT_NOT_FOUND表示AUSF没有找到对应的资源URI。
该消息携带的确认数据只有ConfirmationData包含RES*。但是该值也有为空的情况表示通知AUSF拜访地鉴权失败。具体场景如下 UE不可达的情况AMF不会收到RES* 拜访地鉴权失败AMF比较HRES和HXRES不一致 AMF收到UE的authentication failure消息如synchronization failure或者MAC failure。
11 AUSF 验证RES*
AUSF收到RES后首先验证5G AV是否过期。如果5G AV过期了则认为归属网络鉴权失败。如果5G AV验证不超期AUSF加密保存Kausf。之后AUSF比较接收到的 RES和保存的XRES*是否一致如果一致AUSF认为归属网络鉴权成功并通知UDM鉴权结果之后开启C. 鉴权确认和注册绑定流程。
12 Nausf_UEAuthentication_Authenticate Response****
消息方向 AUSF - AMF/SEAF
如果AUSF鉴权成功则向AMF/SEAF返回200 OK响应携带ConfirmationDataResponse信息具体内容如下 消息IE介绍
authResult
该IE共有三个可选值 AUTHENTICATION_SUCCESS归属地鉴权成功 AUTHENTICATION_FAILURE归属地鉴权失败 AUTHENTICATION_ONGOING表示EAP Session鉴权正在进行目前不涉及。 supi/kseaf
从整个流程中可以看到只有当归属地鉴权成功后AMF才能得到解密后的SUPI和锚点Kseaf。拜访网络在得到SUPI之前不能使用任何网络服务。之后SEAF根据Kseaf、ABBA参数和SUPI推导出Kamf并和ngKSI一起发送给AMF。
1.1.2.9.2.3 鉴权流程鉴权确认和注册绑定部分 该步骤主要用于防止AMF的虚假注册如UE所处拜访网络没有的AMF却发起了Nudm_UECM_Registration_Request导致UE注册在了一个不存在的AMF上。
1 Nudm_UEAuthentication_ResultConfirmation Request****
消息方向AUSF - UDM
HTTP方法POST
该请求消息的资源URI如下
{apiRoot}/nudm-ueau/v1/{supi}/auth-events
资源URI中包含SUPI消息体仅包含AuthEvent参数内容如下 消息IE介绍
nfInstanceId
执行鉴权的NF instance 如AUSF。
success
该值为布尔类型true表示AUSF鉴权成功false 表示鉴权不成功。false值也用于AUSF请求UDM删除鉴权结果。
authRemovalInd
可选项用于指示UDM中的鉴权结果是否删除true表示删除。默认值为false。
2 UDM 保存AuthEvent 相关信息
UDM保存UE的鉴权状态如SUPI、鉴权结果、时间戳、serving network name等。
3 Nudm_UEAuthentication_ResultConfirmation Response****
消息方向UDM - AUSF
· 成功响应
返回201 Created消息体可以为空。如果不为空则返回AuthEvent内容。HTTP消息头的Location字段包含创建的资源URI如下
{apiRoot}/nudm-ueau/v1/{supi}/auth-events/{authEventId}
· 失败响应
404 Not Found原因值USER_NOT_FOUND。 4 UDM对后续流程的鉴权****
如果UDM收到了UE的后续流程如AMF发送的Nudm_UECM_Registration_Request消息UDM会根据运营商策略执行相关检测和保护操作详见TS 33.5013GPP仅提供了建议操作。
1.1.2.9.2 重新执行获取UE Context
如果在new AMF对UE成功鉴权如果在第5步中由于完整性检查失败获取UE context不成功导致发起的鉴权。鉴权完成后此时需要重新执行第4步重新获取ue context。具体内容详见1.1.2.4章节的叙述。
1.1.2.9.3 5G密钥相关推导图
1.1.2.9.3.1 5GS密钥推导图TS 33.501 1.1.2.9.3.2 5GS密钥分布及生成模式图TS 33.501 1.1.2.9.3.3 UDM鉴权向量推导图TS 33.102 1.1.2.9.3.4 UE鉴权推导图TS 33.102 1.1.2.9.4 5G NAS安全模式的启用
new AMF对UE成功鉴权后如果第5步中由于完整性检查失败导致获取UE context不成功此时需要重新执行第4步Namf_Communication_UEContextTransfer从old AMF获取UE context此时请求消息携带的原因值为MOBI_REG_UE_VALIDATED。old AMF收到消息后发现是该原因值则不进行完整性检查直接返回完整UE Context包括PDU Session信息。
在本步骤上半部分的叙述中AUSF和AMF均鉴权成功后AMF才会收到锚点密钥Kseaf和SUPI。从上面的密钥推导图可以看出来AMF会从Kseaf推导出KamfKamf保存在5G NAS security context中之后再推导出NAS层、RRC层及UP用户面的加密和完整性保护密钥。
我们先来看NAS层加密和完整性功能的开启过程。RRC层加密和完整性功能的开启我们在核心网信令交互完成后发送给UE注册结果时再进行讨论。
在UE鉴权流程完成之后AMF拿到了密钥完成了AMF中5G NAS security context 的创建下一步需要完成UE中5G NAS security context 的创建两侧安全上下文全部创建完成后之后UE和AMF之间的加密和完整性保护才能激活。5G NAS security context参数保存在USIM卡中如果USIM中没有对应的保存文件则要保存在ME的非易失性的存储器中。
注
UE的鉴权流程场景可以创建5G NAS security context在N1间切换、N1和S1间的切换场景也可以完成5G NAS security context的创建。5G NAS security context包括KAMF及相关的密钥标识、UE security capabilities、上下行NAS COUNT值。
1.1.2.9.4.1 NAS消息完整性保护要点说明
我们先来看一下5G NAS消息的完整性保护相关的要点
l 如果UE本地没有5G NAS security context的情况UE执行注册流程时发送的Registration Request消息可以不进行加密和完整性保护。只要UE本地存在有效的5G NAS security context3GPP规范强制要求UE对NAS消息进行完整性保护。
l 当发送的NAS消息既需要加密又需要执行完整性保护时NAS消息首先进行加密之后加密的NAS消息和NAS序列号一起进行完整性保护计算MAC
l NAS消息可以只进行完整性保护而不加密。未加密的NAS消息和NAS序列号一起进行完整性保护计算MAC
l 当UE处于5GMM-IDLE模式要建立NAS信令连接时如果本地有有效的5G NAS security context时发送初始NAS消息时会包含NAS key set identifier IE 其中含有ngKSI值用于指示当前使用的用于进行NAS完整性保护的5G NAS security context。AMF收到初始NAS消息时会检查其中包含的ngKSI值指向的AMF本地的5G NAS security context是否可用并验证NAS消息的MAC。如果验证成功则AMF和UE之间可以进行安全的NAS消息交互。
l 如果选择5G-IA0空算法即null integrity protection algorithm相当于没有进行完整性保护作为完整性保护的算法在NAS消息的安全头Security header type指示为完整性保护消息则NAS消息的接收方仍然认为该消息是完整性保护的消息。如果NAS消息使用5G-EA0即null ciphering algorithm 算法加密在NAS消息的安全头部指示为加密保护消息则仍然认为NAS消息是加密的。
1.1.2.9.4.2 NAS消息的加密要点说明
下面再看一下UE发送Registration Request消息时是否有5G NAS security context在消息加密方面的要点。在3GPP文档中该部分内容有两个名词cleartext和non-cleartext经过前后对比cleartext理解为“允许明码发送”non-cleartext理解为“需要加密发送”比较合适。
l UE没有有效的5G NAS security context
则只能发送包含cleartext IE初始NAS消息即只包含在第1步中介绍的允许明文发送的字段。也就是说发送的Registration Request消息不包含NAS message container IE。在本步中完成UE鉴权流程后会将完整的Registration Request消息包含cleartext和non-cleartext的内容包含在NAS SECURITY MODE COMPLETE消息中的NAS message container IE中重新发送。如果UE没有non-cleartext发送的内容则NAS SECURITY MODE COMPLETE消息的NAS message container IE中只包含cleartext内容。
l UE有有效的5G NAS security context
A. 如果UE有需要non-cleartext发送的信息则需要将cleartext和non-cleartext的内容完整包含在Registration Request的NAS message container IE中并将该NAS message container IE进行加密。之后发送Registration Request消息该消息包含cleartext和non-cleartext内容的NAS message container IE即包含完整的注册请求消息。
注
本步涉及的初始NAS消息有三种REGISTRATION REQUESTSERVICE REQUESTCONTROL PLANE SERVICE REQUEST。每种消息类型包含的可以cleartext发送的IE都不一样具体参见TS 24.501。物联网应用场景中CONTROL PLANE SERVICE REQUEST发送会涉及CIoT small data container IE的处理需要注意。
B. 如果UE没有non-cleartext发送的信息则不包含NAS message container IE。
需要注意的是上面的规则适用于UE发起的第一条初始NAS消息如果是UE收到NAS Security Mode Command后包含在NAS Security Mode Complete消息里的NAS message container IE中完整的Registration Request消息是不需要加密的。详见TS 24.501 Clause 5.4.2.3
注****
如果UE具有5G NAS security context但是其中包含的加密算法为5G-EA0。此时当UE在5GMM-IDLE状态选择了一个不同于以前注册的PLMN时UE会放弃该5G NAS security context不使用。
AMF在收到这些包含[NAS message container] IE的初始NAS消息会优先处理NAS message container IE中的内容。由于NAS message container IE是加密保护的如果AMF本地没有UE的有效上下文或者从old AMF得到的UE上下文中的安全参数无法解密或者old AMF完整性检查失败等等只要任何一步出现问题都会触发AMF和AUSF之间的UE鉴权流程。
注**** * 在第1步流程中我们的疑问在本步骤的学习中得到了解答。以前觉得学明白了在细致整理的时候仍然会发现一些未知的问题。5G系统之所以在NAS消息Registration Request中又包含了一个[NAS message container]主要是因为5G系统支持初始消息的保护。*
从现网跟踪到的信令来看信令内容[NAS message container]中既包含cleartext的部分又包含non-cleartext部分即[NAS message container]中包含完整的注册消息的全部字段。而Registration Request这条NAS消息[NAS message container]外部只包含cleartext部分与[NAS message container]中部分内容是重复的。
网络是否开启加密由AMF配置决定如果不开启加密功能AMF会在所有UE的5G NAS security context 指示采用null ciphering algorithm 5G-EA0算法。
当建立起N1 NAS安全交互的信令连接后UE会开启NAS消息的加密和解密功能。之后除非明确定义在N1 NAS信令连接释放或者执行S1切换之前UE会将所有发送的NAS消息加密。AMF除了NAS SECURITY MODE COMMAND消息也会在N1 NAS信令连接释放或者执行S1切换之前开启加密和解密功能。
一旦在AMF和UE间开启了NAS消息加密NAS消息的接收方会丢弃所有未加密的NAS消息。 1.1.2.9.4.3 5G初始NAS消息保护机制 对于UE发送的Registration Request如果没有进行完整性保护UE本地没有5G NAS security context场景AMF会继续处理该NAS消息。如果Registration Request消息进行了保护但是使用AMF本地5G NAS security context执行MAC完整性校验失败或者无法校验时AMF仍然会处理Registration Request消息。这样就保证了不论UE移动到何处发送的注册请求是否有保护或者保护的密钥参数不对AMF都会处理Registration Request消息尽可能为UE提供网络服务。
Step 1如果UE发送初始NAS消息给AMF。如果UE没有NAS Security context初始NAS消息值包含cleartext IE如SUCI或者GUTI、UE security capabilities、ngKSI等。如果UE有NAS Security context初始NAS消息会包含cleartext和non-cleartext信息加密部分的信息在NAS container中。因为UE有NAS安全上下文所以发送的消息是经过加密和完整性保护的。如果NAS消息被保护了且AMF具有相同的安全上下文如UE在同一AMF再次注册的场景Step 2到4可以忽略此时AMF可以解密使用NAS container中完整的初始NAS消息。
Step 2如果AMF本地和之前注册的AMFold AMF中没有找到安全上下文或者完整性检查失败AMF会触发UE鉴权流程Step 2b。如果从old AMF获取到UE context其中的安全参数可以解密NAS container中的内容则Step2b到4可以忽略。
Step 3如果UE鉴权成功AMF会发送NAS Security Mode Command消息给UE。如果UE之前发送的初始NAS消息无法使用如NAS container无法解密或者完整性校验不通过等。AMF会设置标记要求在UE发送的NAS Security Mode Complete消息中包含完整的初始NAS消息。
Step4UE发送NAS Security Mode Complete消息给AMF该消息是加密并完整性保护的消息。
Step 5AMF发送初始NAS消息的回复该消息是加密及完整性保护的。
1.1.2.9.4.4 5G NAS安全模式的开启 1a. AMF在发送NAS Security Mode Command 消息之前首先激活NAS完整性保护功能。
1b. AMF通过发送NAS Security Mode Command消息启动NAS安全模式控制流程NAS security mode control procedure并开启定时器T3560。AMF重置下行NAS COUNT计数器用于推导密钥及完整性保护的输入参数并使用它进行NAS SECURITY MODE COMMAND消息的完整性保护。AMF发送NAS Security Mode Command 消息不进行加密但是需要使用该消息中的ngKSI指示的Kamf进行完整性保护并设置security header type为integrity protected with new 5G NAS security context。
如果之前的Registration Request消息由于AMF中完整性校验失败或者解密NAS message container IE不成功AMF会在NAS Security Mode Command消息中包含Additional 5G security information IE并设置RINMR比特位为Retransmission of the initial NAS message requested请求UE在发送NAS Security Mode Complete消息时包含完整的Registration Request消息。Security Mode Command消息的定义如下图 重点IE介绍
Security header type
NAS消息保护性说明。其中0011用于NAS Security Mode Command消息。0100用于NAS Security Mode Complete消息。 Selected NAS security algorithms
指示网络选择的加密和完整性保护算法。UE发送的Registration Request消息中UE security capability IE包含UE支持的算法AMF根据UE和自身的支持情况选择合适的加密算法。
ngKSI
用于识别5G NAS Security Context中的Kamf。
Replayed UE security capabilities/ Replayed S1 UE security capabilities
UE发送的Registration Request消息中的UE security capability IEAMF会原封带回。如果UE发现与自己发送的不一致则会发送SECURITY MODE REJECT消息携带原因值#23 UE security capabilities mismatch。
IMEISV request
AMF请求获取UE的IMEISV。 Selected EPS NAS security algorithms
如果网络支持N26接口并且UE在Registration Request消息中5GMM capability IE设置了S1 mode比特为S1 mode supported则AMF会选择EPS使用的NAS安全算法用于UE移动到EPS时使用。AMF会将该参数保存在UE Security context中N2接口的切换或者空闲模式下的移动更新该参数会被传递到目标AMF。
Additional 5G security information
该参数包含RINMR是否需要重传初始NAS消息。和HDP是否需要推导Kamf两个重要选项。在移动性注册、周期性注册或者同一PLMN的多注册3GPP access或non-3GPP access场景下需要包含Kamf推导标识。 ABBA
降级攻击保护参数。
1c. AMF在发送完NAS Security Mode Command消息后激活上行NAS解密功能。
2a. UE验证NAS Security Mode Command消息包括验证UE发送的UE security capabilities是否遭到修改及使用NAS Security Mode Command消息中ngKSI指示的Kamf推导密钥及选择的算法进行完整性校验。
如果HDP设置了K_AMF_change_flag UE需要推导新的KAMF并设置NAS COUNTs为0。 如果UE验证NAS Security Mode Command消息成功UE使用ngKSI指示的安全上下文启动NAS消息的加密和完整性保护功能。
2b. UE发送经过加密和完整性保护的NAS NAS Security Mode Complete消息给AMF。消息中可能携带PEI、IMEISV及重传的完整初始NAS消息Registration Request。如果重新推导了KamfAMF会设置NAS COUNT为0。
如果UE验证NAS Security Mode Command消息不成功会回复Security Mode Reject 消息。Security Mode Reject消息及后续的NAS消息仍然会使用之前的5G NAS security context进行加密和完整性保护。如果之前不存在5G NAS security contextNAS Security Mode Reject消息不进行保护。
如果UE发送Security Mode Reject消息后NAS COUNT溢出则UE会直接释放NAS连接而不发送Security Mode Reject。
1d. AMF使用在NAS Security Mode Command消息中选择的加密和完整性保护算法和密钥解密以及校验 NAS Security Mode Complete 消息。AMF收到NAS Security Mode Complete 消息后开启NAS消息的下行加密并停止计时器T3560。
至此UE和AMF完成了NAS消息加密和完整性保护功能激活。
一旦UE和AMF之间完成了加密和完整性保护功能激活所有没有通过完整性检查的NAS消息都会被丢弃不进行处理。
5G注册过程的鉴权和安全性保护方面到这就介绍完了。在切换过程中也会涉及到安全方面的内容在详解切换流程时在进行分析。
UE鉴权成功之后此时还要重新执行第4步和第5步即章节1.1.2.4和1.1.2.5重新获取UE的Context。如果new AMF获取到了UE Context此时new AMF会判断自己能否为UE提供服务如果不能则需要进行AMF重选流程。如果new AMF没有获取到UE Context则需要根据SUPI选择UDM下载切片选择数据判断自己能否为UE提供服务如果不能为UE提供服务则执行AMF重选流程。
1.1.2.10 Namf_Communication_RegistrationStatusUpdate
消息方向new AMF - old AMF
HTTP方法POST
该消息用于正在进行UE注册的new AMF向old AMF更新相应的注册状态,及通知需要释放的PDU Session等信息。
如果第9步UE鉴权失败或者new AMF根据下载的切片选择信息发现自己不能为UE请求的切片提供服务new AMF需要使用该消息通知old AMFUE在new AMF注册失败old AMF需要继续保存该UE的上下文信息。
对于移动性注册流程如果UE在old AMF的RA注册区中可以使用的S-NSSAI在new AMF的RA中无法支持则new AMF需要确定该S-NSSAI关联有哪些PDU Session需要释放之后使用该消息将拒绝的PDU Session ID信息通知old AMFold AMF调用相应SMF的Nsmf_PDUSession_ReleaseSMContext将拒绝的PDU Session资源释放。New AMF也会修改该UE的PDU Session Status信息。在整体注册流程完成之后new AMF使用Registration Accept消息通知UE更新后的PDU Session Status信息。如果UE发现有PDU Session被网络拒绝就将相应资源释放。
如果new AMF不使用原来UE Policy和AM Policy关联的PCF也会通知old AMFnew AMF重新选择了新PCFold AMF需要释放相应的资源。
该请求的资源URI为
{apiRoot}/namf-comm/v1//ue-contexts/{ueContextId}/transfer-update
携带的参数类型为UeRegStatusUpdateReqData具体的字段信息如下图。其中只有tranfserStatus为必选IE其它均为可选IE。在该消息中需要注意的是{ueContextId}是old AMF分配的5G-GUTI而不是SUPI也不是new AMF分配的5G-GUTI。因为在old AMF中UE Context是使用原来的5G-GUTI来识别的。 重点IE介绍
transferStatus
该IE取值TRANSFERRED或NOT_TRANSFERRED。如果取值为NOT_TRANSFERRED标识在new AMF注册没有成功需要重新选择新的AMFold AMF需要继续保存该UE的UE Context不要删除。
toReleaseSessionList
某些S-NSSAI在new AMF不能支持其关联的PDU Session ID在该IE中通知old AMF。
pcfReselectedInd
指示new AMF是否重新选择了PCF该类型为布尔型取值true或者false。需要注意的是不论在非漫游场景或者漫游场景AMF的AM策略和UE策略都是选择同一个PCF或者V-PCF。SM策略选择的PCF则可能与AM、UE策略不是同一个PCF。
smfChangeInfoList
AMF间注册场景时如果有I-SMF/V-SMF变化或者删除时需要通过该IE通知。包含PDU Session ID的列表及对应的I-SMF/V-SMF改变取值CHANGED或者删除取值REMOVED。
old AMF收到RegistrationStatusUpdate消息后如果transferStatus的值为TRANSFERREDold AMF执行的操作如下
1释放toReleaseSessionList IE中的PDU Session
2对UE Context启动预删除计时器。如果在计时器超时前收到了UDM发送的Nudm_UECM_DeregistrationNotify消息则等待该计时器超时删除UE Context如果已经超时则立即删除
3如果pcfReselectedInd取值为TRUE则old AMF释放和old PCF间的AM和UE策略偶联
4如果消息中包含smfChangeInfoList IEold AMF会删除I-SMF 或者V-SMF中smfChangeInfoList指示的所有PDU Session的SM Context会话上下文信息。
如果RegistrationStatusUpdate消息的transferStatus值为NOT_TRANSFERREDold AMF继续保留UE Context。
消息名称Namf_Communication_RegistrationStatusUpdate Reponse
消息方向old AMF - new AMF
消息属性响应消息
在3GPP的注册流程图中没有明确画出该消息实际上Namf_Communication_RegistrationStatusUpdate消息存在响应消息。
· 成功相应200 OK
成功相应携带数据类型为UeRegStatusUpdateRspData数据类型为布尔型TRUE表示更新成功默认为TURE。
· 失败相应
- 307 Temporary Redirect
- 308 Permanent Redirect
- 403 Forbidden
表示old AMF可以正常解析消息但是由于错误无法执行状态更新操作。
- 404 Not Found
如果old AMF没有找到指定的UE Context则返回该错误原因值为CONTEXT_NOT_FOUND。
注
该步骤在3GPP R15的TS 23.502的最后一个版本fb0中消息名称为Namf_Communication_RegistrationCompleteNotify在注册流程图、相应步骤的解释及最后AMF服务化接口操作描述都是该名称。但是在TS 29.518的最后一个版本f40中找不到Namf_Communication_RegistrationCompleteNotify消息该消息已经使用RegistrationStatusUpdate进行了更新。在3GPP R16版本中已经全部改正了这些矛盾。目前在网上及个别厂家文档等资料中该消息名称还没有改正大家阅读到该步骤时需要注意。
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 REQUESTTS 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操作涉及UCMFUE 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的PEIIdentity Request消息中的Identity Type IE应该设置为011或者101表示获取UE的IMEI/IMEISV详见下图 初始注册流程中AMF如果获取了UE的PEI在后续流程中AMF会将其发送给UDMNudm_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.502UE在紧急注册中使用的UE标识的优先级5G-GUTI、SUCISUPI、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卡本身就不支持加密SUPIIMSI
2归属网络为UE配置使用null-scheme。比如开户时在USIM卡中烧录的就是null-scheme
3UE没有有效的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
1IMEI
2IMEISV
448bit的MAC地址
5EUI-64IEEE Extended Unique Identifier。
1.1.2.12 N5g-eir_EquipmentIdentityCheck_Get
消息方向AMF - EIR
HTTP方法POST
该步骤国内未使用不进行介绍。
1.1.2.13 UDM选择
在该步骤中AMF会使用SUPI通过NRF选择UDM。
需要注意的是在第8步中AMF选择AUSF时可以使用SUCI和SUPI。在本步骤中不管何种情况AMF和AUSF已经完成了UE的鉴权流程AMF一定会获取到UE的SUPI所以在UDM的选择中只有一个输入参数就是SUPI。
1.1.2.14 AMF与UDM交互
第14步共有514a-e部分涉及到new AMF/old AMF和UDM之间的信令交互。下面具体介绍。
1.1.2.14a Nudm_UECM_Registration
消息方向new AMF - UDM
HTTP方法PUT
该Nudm_UECM_Registration操作用于在UDM中保存UE Context Managemen信息。该消息的触发条件有再次注册时AMF发生改变、UE在AMF的UE上下文无效、UE在同一个AMF注册但是RAT不同。从触发条件也可以看出来在周期性注册中是不需要执行Nudm_UECM_Registration操作的。
不仅AMF可以调用该Nudm_UECM_Registration操作SMF、SMSF、IP-SM-GW均可以进行调用用于保存各自相关的信息。
注
在TS23.502中该步骤的解释有If the AMF has changed since the last Registration procedure, or if the UE provides a SUPI which doesnt refer to a valid context in the AMF……其中“UE提供的SUPI不能指向有效的上下文”应该是不对的。5G中不会出现UE给AMF提供SUPI的场景。在Identity Request消息中也没有可以获取SUPI的定义。
资源URI如下
{apiRoot}/nudm-uecm/v1/{ueId}/registrations/amf-3gpp-access
其中/{ueId}为用户的SUPI。该消息包含的消息体为Amf3GppAccessRegistration其内容非常丰富下面仅截图部分内容对于其它在IE部分具体介绍。内容如下 重点IE介绍
amfInstanceId
AMF在NRF中注册的ID。
deregCallbackUri
UDM向AMF发送UE去注册事件订阅消息的URI该事件为隐式订阅的。
ratType
AMF向UDM提供接入类型对于3GPP接入类型该值为3GPP access
-guami
正在执行UE注册的AMF的GUAMI。
imsVoPs
指示AMF下的所有TA对IMS over PS是否是匀质支持的。共有三个取值HOMOGENEOUS_SUPPORT、HOMOGENEOUS_NON_SUPPORT、NON_HOMOGENEOUS_OR_UNKNOWN。
AMF只有在评估完自身对Homogenous Support of IMS Voice over PS Sessions支持情况后才可以包含该IE否则不能包含该IE。后期当AMF收集到足够的信息可以判断是否支持该功能时可以使用PATCH方法更新该属性。
initialRegistrationInd
是否是初始注册如果是初始注册该IE需要设置为True否则应设置为False或者不包含该IE。UDM根据该字段来决定是否向之前UE注册的网元发送取消注册信息Nudm_UECM_DeregistrationNotification。
epsInterworkingInfo
如果网络支持N26接口的EPS互操作AMF需要将为DNN选择的PGW-C的FQDN和SMF的标识包含在该IE中发送给UDM。
ueSrvccCapability
该IE标识UE是否支持5G SRVCC。如果设置为True标识UE和AMF都支持5G SRVCC。如果设置为False或者不包含该IE标识表示不支持5G SRVCC。当UE的SRVCC能力改变的时候需要包含该IE。需要注意的是在R16版本的3GPP中已经支持5G SRVCC功能这一点和R15有不同详见TS23.216。
在本步骤中需要注意的是整体更新或者创建AMF的注册信息时使用的是PUT方法修改AMF注册信息使用PATCHPATCH方法可以更新的信息比较有限相比PUT方法少很多获取AMF注册信息使用GET方法。虽然消息名称、资源URI都相同但是不同的HTTP方法效果是不一样的。在UDM侧的处理方法也不一样。另外需要注意的一点是PUT/PATCH方法创建或者修改UE签约数据时在URI中的{ueId}需要使用SUPI而GET方法可以使用SUPI或者GPSI。
PATCH可以更新的信息共有6个具体包含purgeFlag、pei、imsVoPs、backupAmfInfo、epsInterworkingInfo、ueSrvccCapability。
消息名称Nudm_UECM_Registration Reponse
消息方向UDM - new AMF
消息属性响应消息
UDM收到Nudm_UECM_Registration消息后如果UDM中有该UE的注册信息则使用新接收到的Amf3GppAccessRegistration替换之前的注册信息并返回200 OK消息体包含创建的Amf3GppAccessRegistration内容或者204 No Context响应。之后UDM调用Nudm_UECM_DeregistrationNotify通知old AMF删除UE Context。UDM调用该服务使用的URI就是前面介绍的deregCallbackUri包含的内容。
如果UDM中之前没有该UE的注册信息会保存接收到的信息并返回201 created响应。返回的内容可能包含UDM自身支持的额外特性信息及创建的Amf3GppAccessRegistration内容。详细信息如下 注
在介绍鉴权流程第9步C. 鉴权流程鉴权确认和注册绑定部分中步骤2保存了UE鉴权状态。在本步骤中UDM收到了Nudm_UECM_Registration请求消息此时UDM需要对该请求进行内部验证确保不是欺骗性注册具体的验证内容和设备厂商实现相关验证通过后才表示UE注册成功。
1.1.2.14b Nudm_SDM_Get
消息方向new AMF - UDM
HTTP方法GET
该消息的触发条件是AMF中没有该UE的签约数据或者签约数据不完整或者签约数据需要更新时会调用该消息SoR等参数可以设置为要求更新。
AMF使用Nudm_SDM_Get操作下载UE的签约数据。UE的签约数据有很多比较重点的有切片选择签约数据、接入和移动性管理签约数据、SMF选择签约数据、会话管理签约数据、SMS签约数据及SMS管理签约数据。除签约数据外关于SMF、SMSF的UE Context也可以下载其它还有很多签约数据详见TS 29.503经常翻一下这些签约数据对理解信令原理有很大的好处会减少很多疑惑的地方。
该消息调用的URI格式如下后续以下载切片签约数据为例
{apiRoot}/nudm-sdm/v2/{supi}/****
其中{supi}为UE的SUPI最后的URI变量可以为nssai、am-data、smf-select-data、sm-data、sms-data、sms-mng-data、ue-context-in-smf-data等。其支持的查询参数有plmn-id和supported-features查询参数是可选的。如果没有提供plmn-id默认为归属PLMN值返回UE的HPLMN的Subscribed S-NSSAI如果提供了plmn-id则返回该PLMN下的Subscribed S-NSSAI。另一个需要注意的地方是在获取UE签约数据的URI中API版本号为v2。 Nudm_SDM_Get的请求消息不包含消息体。其返回的数据为NSSAI类型的数据具体内容如下 nssai类型的数据包含defaultSingleNssais、singleNssais、additionalSnssaiData等信息其中defaultSingleNssais包含缺省的Subscribed S-NSSAIsingleNssais包含非缺省的Subscribed S-NSSAIadditionalSnssaiData是键值对类型用于说明每个S-NSSAI是否需要执行Network Slice-Specific Authentication and Authorization流程默认为false不需要执行网络切片的鉴权和授权流程。
在众多签约数据中比较特殊的就是网络切片NSSAI签约数据它是在AMF注册前查询用于辅助网络选择的签约数据。4G EPC中PDN连接建立过程中PGW-CSMF也需要查询NSSAI签约数据为UE提供一个S-NSSAI。
下面仅介绍几个重点的签约数据内容
- 接入和移动性签约数据 包含gpsis、subscribedUeAmbr、nssai、ratRestrictions、forbiddenAreas 、serviceAreaRestriction、coreNetworkTypeRestrictions 、rfspIndex 、subsRegTimer周期性注册定时器、ueUsageTypeEPS互操作时用于选择EPC专用核心网、subscribedDnnList、stnSr、cMsisdn、nssaiInclusionAllowed等
- SMF 选择签约数据 包含每个S-NSSAI和DNN信息的关联DNN信息有缺省的DNN、EPS互操作信息及使用静态IP地址的SMF列表等信息。
- 会话管理签约数据 包括切片和DNN配置信息如PDU Session的类型、sscModes、iwkEpsInd、5gQosProfile、sessionAmbr、staticIpAddress等
- SMS 签约数据 包括是否允许NAS短信等
- SMS 管理签约数据 正常的短信业务非IMS短信PS网络自身也支持短信业务数据
- ue-context-in-smf-data 签约数据 包括PDU Session信息DNN、切片等信息和pgwInfo与EPS互操作是的APN和PGW-CSMF FQDN等信息。
注册过程中下载切片数据用于判断当前的AMF是否可以为UE提供服务如果不能服务会涉及到AMF重选流程在后面的详解文章中再具体分析。
注册过程中AMF可以从UDM中可以一次下载多组签约数据如AM签约数据、SMF选择签约数据、SMF中UE Context数据、SMS签约数据等这时候需要使用DataSet的概念。 对应的资源URI相比前面介绍的只是没有具体签约数据名字的信息如下
{apiRoot}/nudm-sdm//{supi}
此时需要下载的多个签约数据是包含在GET方法的查询参数中如下
{apiRoot}/nudm-sdm/v1/imsi-460000000000000?dataset-namesAM,SMF_SEL,UEC_SMSF,SMS_SUBplmn-id***
这些数据集的名字规范定义如下 响应消息 200 OK包括需要获取的签约数据 404 Not Found携带可能的原因值USER_NOT_FOUND、DATA_NOT_FOUND。
1.1.2.14c Nudm_SDM_Subscribe
消息方向new AMF - UDM
HTTP方法POST 该消息可以订阅UE的签约数据变化包括UE自己的签约数据和可以多个UE公用的共享签约数据部分。
该消息的资源URI如下
{apiRoot}/nudm-sdm//{ueId}/sdm-subscriptions
其中{ueId}变量的取值可以为SUPI或者GPSI。
该请求的消息体SdmSubscription包含callbackReference、monitoredResourceUris、subscriptionId等信息。 重点参数介绍
callbackReference
由AMF提供给UDM当签约数据有变化时UDM调用该URI通知AMF。
monitoredResourceUris
AMF请求监控的UDM资源即UE签约数据的资源URI。和AMF下载签约数据的资源URI系统如{apiRoot}/nudm-sdm/v1/{ueId}/am-data。
subscriptionId
用于UDM删除订阅时使用。
注
R16版本中Nudm_SDM_Subscribe进行了优化可以在订阅签约数据的同时携带Immediate Report指示表示同时请求签约数据下载。这样就在一个流程中既订阅了数据又下载了签约数据。但是该功能需要AMF和UDM都支持才行。 Nudm_SDM_Subscribe消息的SdmSubscription数据类型中包含immediateReport参数布尔型如果该参数设置为true则会在report参数中包含需要下载的签约数据具体内容详见下图 响应消息**** 201 Created如果全部成功消息体包括创建的签约数据订阅信息。如果部分成功返回成功订阅数据监视的资源URI。 404 Not Found 501 Not Implemented携带原因值UNSUPPORTED_RESOURCE_URI
1.1.2.14d Nudm_UECM_DeregistrationNotification
消息方向UDM - old AMF
HTTP方法POST 该消息的触发条件是UE移动到了同一个AMF Set内的其它AMF上注册成功同时在Step 14a的Nudm_UECM_Registration消息中initialRegistrationInd参数应该设置为TrueUDM会向old AMF发送该消息。
调用的URI就是在Nudm_UECM_Registration消息中的deregCallbackUri参数包含的地址。 重点参数介绍
deregReason
目前版本的标准共定义了7中原因如下
· UE_INITIAL_REGISTRATION
· UE_REGISTRATION_AREA_CHANGE
· SUBSCRIPTION_WITHDRAWN
· 5GS_TO_EPS_MOBILITY
· 5GS_TO_EPS_MOBILITY_UE_INITIAL_REGISTRATION
· REREGISTRATION_REQUIRED
· SMF_CONTEXT_TRANSFERRED
pduSessionId
SMF去注册时与其关联的PDU Session ID取值范围1-150备用
newSmfInstanceId
新使用的SMF。
响应消息****
old AMF收到该消息后会删除本地保存的UE Context。
如果是初始注册old AMF会调用SMF的Nsmf_PDUSession_ReleaseSMContext服务删除需要释放的PDU Session资源。
如果old AMF之前建立了AM Policy和UE Policy偶联相应的PCF ID没有发送给new AMF如new AMF和old AMF不是同一个PLMN或者new AMF选择了新的PCFold AMF在收到该消息后会结束与相应PCF的策略偶联。
如果AMF有N2接口的连接如UE在RRC in active状态移动到了4G或者其它AMFAMF会通知释放N2连接。
old AMF成功接受并处理返回
204 No Content。
其它错误信息307 Temporary Redirect、308 Permanent Redirect、404 Not Found。
1.1.2.14e Nudm_SDM_Unsubscribe
消息方向old AMF - UDM
HTTP方法DLETE 该消息的资源URI如下
{apiRoot}/nudm-sdm//{ueId}/sdm-subscriptions/{subscriptionId}
其中{ueId}变量可以为SUPI或者GPSI。{subscriptionId}为Step 14c中创建订阅时返回的subscription ID。
消息体为空。
响应消息 204 No Content 404 Not Found
1.1.2.15 PCF选择
该步骤是可选的具体要不要执行AM策略完全是由运营商定义的。为了提供更多的服务一般运营商都会开启请求AM策略的流程。
从上面叙述的各步骤解释中我们可以想到对于周期性注册该步骤不需要执行对于移动性注册或者初始注册该步骤都需要执行。另外紧急注册也是一个例外虽然在国内不涉及但考试时需要注意避免入坑。
在AMF选择PCF获取AM策略和UE策略的选择因子方面TS 23.501定义了4个具体有 SUPI S-NSSAI在漫游场景下可能会用到切片选择PCF的情况。 PCF Set ID PCF Group ID
还有一个情况是如果old AMF已经选择了一个PCF并且将PCF ID包含在UE Context传递给了new AMF如果new AMF决定使用原来的PCF可以直接使用PCF ID访问NRF获得原来PCF的信息。
在该步骤中需要注意的是不论在漫游场景还是非漫游场景负责AM策略的PCF和UE策略的PCF都是同一个PCF。这点3GPP规范明确进行了说明。****
注
在中国移动的路由组织规范上选择PCF的两个因子为GPSI和PCF IDPCF的nfInstanceId。GPSI作为选择因子和3GPP规范上略有不同需要注意。
下面先介绍AMF执行AM策略的过程AMF和PCF之间的接口为N15在后面21b步骤中再进行UE策略的介绍。
1.1.2.16 AM Policy Association Establishment/Modification
对于本步骤来说如果new AMF重新选择了一个PCF则执行AM Policy Association Establishment流程如果是使用old AMF选择的PCF则执行AM Policy Association Modification流程。我们先来看创建AM Policy Associations的流程。
1.1.2.16.1 AM Policy Association Establishment 请求AM策略的资源URI如下
{apiRoot}/npcf-am-policy-control/v1/policies
HTTP方法为POST。消息名Npcf_AMPolicyControl_Create Request消息体为PolicyAssociationRequest该数据类型的内容很多一部分数据来源于AMF从UDM获取的AM签约数据一部分来自于UE的注册消息携带的信息。截图仅粘贴部分IE 重点IE介绍
notificationUri
必选项。PCF发送策略执行通知的URI对于AMF来讲就是AMF接收PCF通知的URI。后面的altNotifIpv4Addrs、altNotifIpv6Addrs、altNotifFqdns都是为了保证消息可靠发送定义的冗余信息。
userLoc
可选项。该信息包含UE当前的位置信息包括TAC、nCGI、Global RAN Node ID等信息。
allowedSnssais/ mappingSnssais
可选项。经过前面的消息交互已经可以推导出UE的Allowed NSSAI所以这里可以包含UE在当前PLMN下可以使用的NSSAI。包含该IE的前提是AMF支持切片功能或者AMF支持DNNReplacementControl特性R16中新增的特性
serviceName
AMF中用于处理PCF发送的策略数据的服务名。
guami
如果PCF收到了GUAMIPCF还需要向AMF订阅AMF状态改变通知。
其它信息包括pei、servingPlmn、ratType、servAreaRes、rfsp、ueAmbr等。
PCF收到Npcf_AMPolicyControl_Create Request请求后会分配Policy Association ID并对消息中收到的服务区限制、UE-AMBR等进行策略处理
响应消息
201 Created
响应消息体中包含的内容为PolicyAssociation具体定义如下 重点信息介绍
request
包含AMF请求时发送的数据PCF可以再返回一次。
triggers
UE在PCF中签约的触发器RequestTrigger 数据类型共定义了8中触发器在AM策略执行中只有 LOC_CH、ALLOWED_NSSAI_CH、SMF_SELECT_CH、PRA_CH、ACCESS_TYPE_CH 可以使用。
smfSelInfo
如果UE请求了不支持的DNN或者在smfSelInfo包含的DNN时AMF需要执行AM策略。
servAreaRes/ rfsp/ ueAmbr
这些AMF发送的数据经过PCF处理后会返回。
从上面的叙述中发现虽然PCF分配了Association ID但是在响应消息体中没有该偶联的标识等信息。实际上这部分信息包含在了HTTP消息的头部“Location”中具体的资源URI为{apiRoot}/npcf-am-policy-control/v1/policies/{polAssoId}后续AMF如果需要查询信息时GET方法就是使用的该URI。
由于该步骤发生在AMF从UDM获取签约数据之后所以AMF从PCF收到的服务区限制等信息可能是经过修改的和UDM中保存的数据不一样。
1.1.2.16.2 AM Policy Association Modification 该流程不仅适用于new AMF选择了原来的PCF时更新通知接收的URI、GUAMI和备用IP地址等信息另外前面介绍的AM Policy Association Establishment流程中PCF发给AMF的触发器triggers被触发时AMF也会发起该流程。
该流程的请求方法为POST调用的服务为Npcf_AMPolicyControl_Update Request请求的资源URI
{apiRoot}/npcf-am-policy-control/v1/policies/{polAssoId}/update
消息体包含的内容为PolicyAssociationUpdateRequest内容和PolicyAssociationRequest差不多但不包含supi、gpsi、pei等信息。 重点信息介绍
notificationUri
new AMF的通知接收URI。
triggers
满足触发条件的事件如服务区限制变化、UE位置变化、RFSP索引变化等。
当PCF收到该请求后首先更新相关的策略数据其次当triggers中对应的事件发生时执行的相应的策略操作。如果是AMF变化引起的策略更新GUAMI发生变化PCF还需要向AMF重新订阅AMF状态改变通知。
注
在TS 29.507中有一段说明If the AMF received the request of removal of Service Area Restrictions and/or RFSP and/or UE-AMBR from the UDM, the AMF shall remove the authorized Service Area Restrictions and/or RFSP and/or UE-AMBR provisioned by the PCF and apply the configured Service Area Restrictions and/or RFSP and/or UE-AMBR at the AMF without interacting with the PCF.
这里的UDM删除数据的请求操作应为UDM的通知操作调用的是Nudm_SDM_Subscribe操作中包含的{callbackReference} URI。携带的消息体内容包括ModificationNotification其中包含的通知项目对应的改变类型为“REMOVE”其它的改变类型为ADD、MOVE、REPLACE。但是后面的“apply the configured Service Area Restrictions and/or RFSP and/or UE-AMBR at the AMF”一句没有理解是什么意思既然前面的是请求删除后面接着说使用“配置的数据”对于服务区限制数据、RFSP和UE-AMBR的配置都是在UDM中的。如果UDM的签约数据变化了通知给AMF。按照TS 29.507后面的介绍当UE的签约数据变化时如服务区限制信息、RFSP信息、UE-AMBR改变时UDM都会通知AMF。这就满足了AM的策略触发条件之后AMF会发起AM Policy Association Modification流程请求PCF执行策略。 * 感觉内部逻辑有点矛盾暂存疑。如果哪位同学get到了原因多多指教。*
响应消息
Npcf_AMPolicyControl_Update Response消息的消息体包含PolicyUpdate类型包含的具体内容之前均进行了介绍不再重复。消息的部分截图如下 1.1.2.17 Nsmf_PDUSession_UpdateSMContext
/Nsmf_PDUSession_ReleaseSMContext
该步骤可选适用于移动性注册更新或者周期性注册更新。当AMF没有需要释放的PDU Session或者没有需要更新的PDU Session时该步骤不需要执行。这就面临触发条件的问题什么时候会出现需要释放的PDU Session什么时候又需要更新PDU Session。下面分别介绍。
1.1.2.17.1 释放PDU Session的场景
AMF发送Nsmf_PDUSession_ReleaseSMContext消息的场景
UE本地释放了PDU Session需要通知网络释放相关的资源。
UE本地释放了某个PDU Session如何通知网络呢在第一步中UE发送的Registration Request消息的PDU Session Status IE中携带了每个PDU Session的状态0表示PDU Session处于INACTIVE状态1表示PDU Session是非INACTIVE状态。new AMF收到该注册请求消息后会将PDU Session Status IE中的标记为非INACTIVE状态的PDU Session对应的会话资源释放。
注****
这里之所以不说是ACTIVE状态是因为非INACTIVE状态除了包括ACTIVE状态可能还包含吊死、挂起等等状态。这里PDU Session Status IE用于通知AMF释放资源如果表述为ACTIVE状态会引起理解上的困惑。****
需要注意的是第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部分时再分析。
1.1.2.17.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知识点太多了每一点都够研究很长时间。如果只是懂大概的知识还是比较简单但是如果细致分析感觉就实在太复杂了。
1.1.2.18 UE Context Modification Request/Response
和N3IWF/TNGF/W-AGF间的交互该步骤涉及到其它接入技术间的流程国内不涉及。
1.1.2.19 UE Context Modification Response
和N3IWF/TNGF/W-AGF间的交互该步骤涉及到其它接入技术间的流程国内不涉及。
1.1.2.20 创建UE Context的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.331RRC层信令规范5.3.4 Initial AS security activation章节明确说明UE是接收到网络下发的SecurityModeCommand消息后启动AS加密和完整性保护。这里的网络对于UE来讲就是gNB该消息指的是RRC层的SecurityModeCommand消息。
接下来我们重点关注gNB在什么时候下发该消息。查看TS 38.413规范NGAP中gNB在INITIAL CONTEXT SETUP REQUEST消息中获得安全密钥。TS 38.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中很多。因为3GPP知识点都是分散在好多文档一般是把一类的知识放在一起将。
接下来我们分别看N2接口消息和空口消息。
1.1.2.20.1 INITIAL CONTEXT SETUP REQUEST
该消息的目的是在gNB中初始化UE ContextgNB在收到Registration消息时已经创建了UE Context此时只是修改增加相关数据包括PDU session上下文、安全密钥、移动限制性列表、UE无线能力及UE的安全能力等信息。该消息是由AMF触发的。在第1步介绍的INITIAL UE MESSAGE消息中有UE Context Request IE表示gNB请求UE Context。如果gNB没有携带该IEAMF也会根据配置触发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支持能力
1.1.2.20.2 RRC层AS层加密和完整性保护的启用
gNG收到该消息后除了保存相关字段信息外还需要根据消息中的密钥参数执行RRC层的安全。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消息。
1.1.2.20.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无线能力的流程。
1.1.2.20.4 RRC层UECapabilityInformation
UE的无线能力信息比较大如果超过了PDCP层的最大支持会启用RRC层消息的分段传输功能。
1.1.2.20.5 N2消息UE RADIO CAPABILITY INFO INDICATION gNB将获取到的最新的UE Capability Information通过UE RADIO CAPABILITY INFO INDICATION消息发送给AMFAMF收到后会替换本地为该UE保存的无线能力信息。UE RADIO CAPABILITY INFO INDICATION消息的定义如下 1.1.2.20.6 RRCReconfiguration 该消息用于在空口上传递Registration Accept消息用于UE处于RRC_CONNECTED状态时更新RRC连接、刷新RRC连接使用的密钥参数等。该消息承载在SRB1或者SRB3上。RRCReconfiguration消息的部分定义如下 其中dedicatedNAS-MessageList用于传递UE和AMF之间的NAS信令后面的sk-counter参数用于UE进行RRC层的密钥推导。
注
在本步骤中为什么使用了RRCReconfiguration而不是DLInformationTransfer来传递Registration Accept消息呢
这两条消息都是UE在RRC_CONNECTED状态使用的消息NAS层消息都可以承载在这两条消息中传递。之所以在初始注册时使用了RRCReconfiguration是因为要修改RRC连接的配置启用AS层的保护功能。如果本步骤RRC不需要修改RRC的配置只是传递NAS消息则使用DLInformationTransfer来传递Registration Accept消息。
*从第一步Registration Request步骤中介绍的DLInformationTransfer定义可以看到该消息专门就是用于传递NAS消息的没有别的功能。gNB在发送下行NAS消息时首先根据当前情况看是否RRC层有需要修改的参数如果有则构造RRCReconfiguration消息此时NAS层的消息只是顺带发送给UE的这样就节省了一条空口消息gNB不用单独再构造一条DLInformationTransfer消息下发NAS消息。 *
1.1.2.20.6 RRCReconfigurationComplete
RRCReconfiguration消息的回复消息为RRCReconfigurationComplete。因为对Registration Accept消息的确认不是必须的所以在RRCReconfigurationComplete消息中没有定义传递NAS消息的IE这里不进行详细介绍。
1.1.2.20.7 INITIAL CONTEXT SETUP RESPONSE
对INITIAL CONTEXT SETUP REQUEST消息的确认如果没有PDU Session的建立和更新只用来确认消息。 1.1.2.21 Registration Accept
1.1.2.21.1 Registration Accept消息注解
Registration Accept消息承载在20步中的INITIAL CONTEXT SETUP REQUESTN2接口消息和RRCReconfiguration消息RRC层消息中发送给UE。本步骤专门介绍NAS层Registration Accept消息。该消息内容非常丰富UE的很多行为参数都是在该消息中下发给UE的。
Registration Accept为必选消息不论是什么注册类型该消息都存在只是不同的注册类型携带的参数不一样。如果网络接受了用户的注册请求AMF会发送Registration Accept消息给UE。AMF保存注册请求中的5GMM capability、S1 UE network capability、UE security capability等信息。在AMF间切换或者4/5G切换时old AMF会将这些信息发送给new AMF或者MME。
我们先看Registration Accept消息的定义**** 该消息的IE很多有些参数的网络行为也很复杂比如切片、MICO、LADN等。这些内容在后续专题里进行详细介绍这里仅扼要介绍重点内容。
5GS registration result
该IE中包含的信息很重要具体信息如下
1注册成功的RAT类型3GPP access还是non-3GPP access或者二者都有。
2网络对SMS over NAS是否支持allowed或者not allowed。
3是否需要执行NSSAANetwork slice-specific authentication and authorization也就是对切片的鉴权和授权是否需要执行。该标识位很重要会衍生出很多的网络行为。
在第一步的介绍中我们知道UE是否支持SMS over NAS是在注册消息的5GS update type IE中设置的。如果完成SMSF选择并激活SMSF服务成功AMF会在REGISTRATION ACCEPT消息中将5GS registration result IE对应的比特位置位表示SMS over NAS allowed。SMSF的地址信息会保存在AMF的UE Context中。
我们再来看一下5GS registration result IE 中设置为SMS over NAS not allowed的场景有哪些
1AMF进行SMSF选择失败目前中国移动使用nf-type来查询NRF执行SMSF发现操作
2SMSF中UE的SMS功能激活失败
3AMF不允许使用SMS over NAS功能
4UE在REGISTRATION REQUEST 消息中设置为SMS over NAS not supported
5REGISTRATION REQUEST消息不包含5GS update type IE。
5G-GUTI
这个术语很著名只要学5G的同学都知道它的结构。这里我们主要讲一个大家容易忽视的问题网络什么时候会为UE重新分配5G-GUTI5G-GUTI并不是初始注册完成后就一成不变的而是会经常变化这样才能保证信息安全。我们看一下网络为UE重新分配5G-GUTI的场景
1根据3GPP规范初始注册、移动性注册、周期性注册网络都会为UE重新分配5G-GUTI
2UE响应寻呼AMF收到UE发送的Service Request消息也会为UE分配新的5G-GUTI在当前的NAS信令连接释放前发送给UE
3除上述场景5G-GUTI重新分配的可以更频繁这依赖于厂家实现。任何时候网络都可以通过CONFIGURATION UPDATE COMMAND对UE的5G-GUTI重新分配。
需要注意的是UE收到5G-GUTI发送确认Registration Complete后会删除本地所有的SUCI。
如果USIM中有对应的文件则将5G-GUTI保存在USIM中如果USIM没有对应的文件则将其保存在ME的非易失性存储器中。
如果UE没有收到5G-GUTI则认为UE之前保存的5G-GUTI仍然有效比如UE已经通过non-3GPP完成了注册本次在3GPP场景注册。
Equivalent PLMNs
AMF会为UE分配一个equivalent PLMN列表MCCMNC。UE会保存该列表但是在保存前会把禁止接入的PLMN从该列表中删除。当然UE也会保存当前注册的PLMN。UE每次收到Registration Accept都会保存equivalent PLMN列表如果消息中不包含该列表那么UE也会删除本地保存的列表。
equivalent PLMN列表是什么东西呢举个例子对中国移动来讲网络正常注册的是46000但是46002、46004等也是中国移动使用的PLMN ID这些同一个运营商使用的其它PLMN号码就相当于equivalent PLMN。
注意该字段在gNB同时连接ToB和ToC核心网时会有用。
TAI list
AMF会为UE分配一个注册的TA List具体使用场景和4G一样。UE在收到新的TA List后会替换掉UE原来保存的TA List。
如果UE没有收到新的TA List则认为原来的TA List仍然有效。
如果UE从5G去注册了UE中的TAI List就无效了。
Allowed NSSAI
Allowed NSSAI中包含的是不需要NSSAA的切片或者NSSAA验证成功的切片根据UE Context判断old AMF已经对这些切片进行了NSSAA验证最多包含8个S-NSSAI保存在UE的非易失性的存储器中。
在3GPP网络接入下网络允许使用的切片信息包含在该IE中该值为Requested NSSAI和subscribed NSSAI的交集且在UE的当前TA中允许使用的NSSAI。
如果UE在注册请求中没有包含Requested NSSAI或者Requested NSSAI中的切片网络都不允许使用那么Allowed NSSAI IE中包含的S-NSSAI是subscribed S-NSSAI中设置为缺省的切片前提是这些缺省的subscribed S-NSSAI不需要NSSAA如果缺省的切片需要NSSAA则不能包含在Allowed NSSAI中。
UE会将接收到的allowed NSSAI和当前的PLMN、TA关联起来进行保存。
UE注册中Registration Accept中出现Allowed NSSAI为空的场景有哪些呢
1Requested NSSAI中的所有S-NSSAI(s)都需要进行Network Slice-Specific Authentication and Authorization
2UE没有提供Requested NSSAI或者Requested NSSAI中的S-NSSAI都没有匹配上Subscribed S-NSSAIs并且所有Subscribed S-NSSAIs中所有的缺省S-NSSAI都需要Network Slice-Specific Authentication and Authorization。
Rejected NSSAI
UE请求的Requested NSSAI中被网络拒绝的S-NSSAI都会放在该IE中每个切片都会有对应的拒绝原因值。
UE收到Rejected NSSAI会将其添加在拒绝列表中下次注册时不会使用这些NSSAI。Rejected NSSAI也会和PLMN网络、TAI等关联用于实现不同级别的限制。
UE从网络去注册的时候需要删除Rejected NSSAI信息。
Configured NSSAI
Configured NSSAI在AMF或者NSSF上进行配置。一般AMF或者NSSF配置的NSSAI需要和用户签约的Subscribed NSSAI取交集其结果包含在Configured NSSAI IE中。Configured NSSAI最多包含16个S-NSSAI保存在UE的非易失性的存储器中。
网络下发Configured NSSAI的场景如下
1Registration Request不包含Requested NSSAI
2Registration Request消息中Requested NSSAI里包含的S-NSSAI当前网络无法使用。
3Registration Request消息中Requested NSSAI使用是Default Configured NSSAI。
4Registration Request消息中Requested NSSAI对应的mapped S-NSSAI不正确mapped S-NSSAI在R15版本的3GPP中介绍的非常模糊在R16版本中很清晰在漫游场景时使用一般用于非标准的S-NSSAI
UE收到消息后替换当前的Configured NSSAI并删除所有之前保存的Allowed NSSAI、Rejected NSSAI、Pending NSSAI发送REGISTRATION COMPLETE消息。
此处有一个关键点当终端支持4/5G功能如果用户从4G接入时网络此时网络一般会给UE下发一个NSSAI用于4/5G互操作这个NSSAI就是保存在UE的Configured NSSAI中。
5GS network feature support
如果UE在Registration Request消息的5GMM capability IE中指示支持S1模式4G模式那么该IE包含AMF支持N26接口指示interworking without N26 interface not supported 。
该IE中还包含IMS voice over PS session、 location services (5G-LCS)、紧急服务等指示信息。
AMF在设置IMS voice over PS session标记时可能会使用UE Capability Match Request流程来查询UE和NG-RAN的无线能力用于判断是否支持IMS over PS Session。相关具体信息详见第24步骤的分析。
PDU session status
该IE适用于移动性注册或者周期性注册。
UE的Registration Request消息中如果包含PDU session status IE AMF会将没有处在PDU SESSION INACTIVE状态的PDU Session资源释放也就是说会将在注册请求消息中PDU session status IE对应的比特位置位的PDU Session占用的资源释放并在Registration Accept消息中包含PDU session status IE。
AMF需要和UE进行PDU Session的状态同步时也会下发该IE置位方法和注册请求消息一样。UE收到该IE时UE会在本地释放PDU session status IE置位的PDU SessionUE中的PDU Session状态可能处于非PDU SESSION INACTIVE或者PDU SESSION ACTIVE PENDING等。但是UE收到该IE的处理方式有几个例外情况。例外情况时UE会忽略该Registration Accept中的PDU session status IE具体的例外情况如下
1Registration Request消息中已经发送了PDU session status IE
2UE处于单注册模式
3UE在5GMM-IDLE模式下执行S1到N1模式的系统间切换4G到5G
4UE收到的IWK N26比特位设置为interworking without N26 interface supported。
PDU session reactivation result
该IE适用于移动性注册或者周期性注册。
UE的Registration Request消息中如果包含Uplink data status IEAMF会请求SMF重新激活对应PDU Session的用户面资源并在Registration Accept消息中包含PDU session reactivation result IE。
-PDU session reactivation result error cause
该IE适用于移动性注册或者周期性注册.
如果UE不在允许的区域allowed area用户面重新激活失败时该IE中包含的错误原因为#28 Restricted service area。
如果UE不在LADN服务区激活重新用户面失败错误原因#43 LADN not available。
如果UPF资源不可用导致的重新激活失败错误原因#92 insufficient user-plane resources for the PDU session。
其他情况导致的PDU Session重新激活失败时会下发相应的原因值。
Network slicing indication
如果用户UDM中的签约切片数据发生了变化AMF会使用该IE向UE指示Network slicing subscription changed。
UE收到该IE后会删除当前PLMN外的其它所有PLMN的切片信息并发送REGISTRATION COMPLETE消息通知AMF切片信息更新成功。
LADN information/ MICO indication
LADN和区域专网相关MICO和超低功耗相关都是物联网相关的IE目前应用比较少这里不具体进行分析后续专题分析时会进行详细介绍。
UE如果收到的Registration Accept消息中包含新的LADN information会把本地保存的信息及时替换更新。如果Registration Accept消息中没有LADN信息UE要把本地的LADN information删除表示UE当前所处的TA没有LADN可用。这点和5G-GUTI、TA List不一样5G-GUTI、TA List如果没有收到新的会认为之前的仍然有效。
Service area list
如果UE没有收到Service area list IE则默认当前注册的PLMN和equivalent PLMN的所有TA都是允许区域。
T3512 value
UE的周期性注册更新定时器。
NSSAI inclusion mode
UE如果收到该IE则按照其指示在接入层包含NSSAI。如果UE本地存有该网络的NSSAI inclusion mode则按照该模式执行。如果UE本地没有该NSSAI inclusion mode数据对于3GPP接入来讲默认按照模式D执行。该参数具体的设置在Registration Request步骤中已经说明过本步骤不再说明。
EPS bearer context status
如果由S1模式到N1模式执行系统间切换4/5G切换AMF会为UE生成EPS承载上下文信息AMF会在Registration Accept消息中包含EPS bearer context status IE指示UE使用了哪一个EPS上下文。
UE收到该IE后会释放其中标记为不活动的EPS承载关联的资源如QoS flow descriptions及所有关联的QoS规则。
Pending NSSAI
如果UE支持NSSAA即Registration Request请求消息的5GMM capability IE中NSSAA置位时会下发该IE。之后在第25步中进行Network Slice-Specific Authentication and Authorization流程。
如果网络有切片需要进行NSSAA验证或者正在进行NSSAA验证其相应的S-NSSAI包含在该IE中下发给UE同时5GS registration result IE中需要设置NSSAA to be performed指示。
Pending NSSAI最多包含16个S-NSSAI。
后续如果切片验证成功了但是网络已经下发了Registration Accept消息如何把这些切片信息发送给UE呢
答案是后续如果切片验证成功AMF会使用CONFIGURATION UPDATE COMMAND消息将结果通知UE。
Truncated 5G-S-TMSI configuration
该IE与物联网相关。
UE工作在NB-N1模式使用了control plane CIoT 5GS optimization特性而且网络也支持该特性时才会为UE发送Truncated 5G-S-TMSI configuration信息。其中包含Truncated AMF Set ID value 和Truncated AMF Pointer value。该IE需要UE发送确认消息。
上面切片部分叙述看起来很复杂总的来说只有两条
1如果Registration Request消息中包含Requested NSSAI IE且Requested NSSAI和subscribed S-NSSAI签约切片有交集此时的焦点是交集NSSAI处理方法为 不需要执行NSSAA的或者NSSAA已经成功的放在Allowed NSSAI IE中 需要执行NSSAA的NSSAI放在Pending NSSAI IE中。
2如果Registration Request消息不包含Requested NSSAI IE且Requested NSSAI和Subscribed S-NSSAI签约切片没有交集此时的焦点是Subscribed S-NSSAI标记为缺省的NSSAI处理方法如下 缺省Subscribed S-NSSAI中不需要执行NSSAA的或者NSSAA成功的NSSAI放到Allowed NSSAI IE中 缺省Subscribed S-NSSAI中需要执行NSSAA的NSSAI放到Pending NSSAI IE中。
1.1.2.21.2 注册流程要点说明
1 如果UE收到了切片信息要删除本地保存的所有切片数据Default Configured NSSAI除外之后使用接收到的切片数据更新。
2 如果在Registration Request消息的5GS Registration type IE中指示Follow-on request pending或者网络有下行数据要发送AMF完成注册流程后不会立刻释放NAS连接。
3UE收到Registration Accept消息后会重置注册尝试的定时器并切换自身状态到5GMM-REGISTERED设置自己的5GS更新状态为5U1 UPDATED。
4 虽然UE收到了REGISTRATION ACCEPT消息但是如果5GS registration result IE指示NSSAA to be performed且包含pending NSSAIallowed NSSAI又为空的情况下此时UE是无法享受任何网络服务的紧急服务及高优先级接入除外。
5根据上面的叙述我们总结UE收到Registration Accept包含哪些信息时需要发送Registraton Complete消息 5G-GUTI TA List SOR transparent container IE Operator-defined access category definitions IE Extended emergency number list IE CAG information list IE UE radio capability ID IE UE radio capability ID deletion indication IE 收到任何和切片相关的信息。
6AMF收到Registraton Complete消息后会停止T3550修改UE状态为5GMM-REGISTERED5G-GUTI、UE radio capability ID开始生效。
1.1.2.21.3 注册被拒绝的情况
1.1.2.21.3.1 初始注册被拒绝
如果网络拒绝UE的Registration Request消息会下发Registration Reject消息给用户。拒绝的情况很多我们常见的拒绝场景就是切片不可用此时网络下发的原因值为#62 No network slices available具体场景如下 UE不支持NSSAA请求消息的5GMM capability IE中设置情况Requested NSSAI中的所有的S-NASSAI都被拒绝了并且没有缺省的Subscribed S-NSSAIs或者缺省的Subscribed S-NSSAIs都不允许使用。 UE支持NSSAA情况Requested NSSAI中的所有的S-NASSAI都被拒绝了并且没有缺省的Subscribed S-NSSAIs或者缺省的Subscribed S-NSSAIs都不允许使用而且需要鉴权的缺省Subscribed S-NSSAIs全都鉴权失败。
网络拒绝UE的注册后会把拒绝的S-NSSAI放在Registration Reject消息的Rejected NSSAI IE中发送给UE。UE收到后会保存Rejected S-NSSAI。
UE由于切片被注册拒绝后仍然会有后续操作具体是什么呢 如果UE有allowed NSSAI或者configured NSSAIUE发起注册前保存的旧的数据其中包含有不在Rejected S-NSSAI列表中的S-NSSAI此处暂自定义为后续S-NSSAI此时UE还会驻留在当前小区使用正常的小区重选流程启动初始注册流程将“后续S-NSSAI”作为Requested NSSAI发起注册。如果“后续S-NSSAI”为空UE会执行PLMN选择。如果allowed NSSAI或者configured NSSAI中所有的S-NSSAI都被拒绝了UE会关闭当前PLMN的N1模式。 如果UE在当前网络没有allowed NSSAI或者configured NSSAI但是有default configured NSSAI会把default configured NSSAI作为Requested NSSAI之后按照上面的流程再执行一遍。
最后一点需要注意的是在很多场景下UE如果注册被拒绝UE会删除本地之前保存的5G-GUTI、之前注册的TAI、TAI list和ngKSI。因为这些参数是保存USIM中或者UE的非易失性存储中。再说的深一点也就是说如果UE注册是由于下面的原因被网络决绝了UE下次发起的注册请求一定还是初始注册。具体的原因有
#3 (Illegal UE)
#6 (Illegal ME)
#7 (5GS services not allowed)
#11 (PLMN not allowed)
#12 (Tracking area not allowed)
#13 (Roaming not allowed in this tracking area)
#15 (No suitable cells in tracking area)
#27 (N1 mode not allowed)
#73 (Serving network not authorized)
#31 (Redirection to EPC required)
1.1.2.21.3.2移动性或者周期性注册被拒绝 基本和初始注册时一样个别场景有区别。下面重点列两个主要区别
#62 (No network slices available)
此时的区别是不使用default configured NSSAI尝试进行再次注册其它都一样。
删除本地保存的参数
对于移动性注册和周期性注册UE删除5G-GUTI、之前注册的TAI、TAI list和ngKSI的场景有不同。也就是说一旦注册失败下次注册的注册类型发生了改变变为初始注册而不是移动性注册或者周期性注册。具体如下
#3 (Illegal UE)
#6 (Illegal ME)
#7 (5GS services not allowed)
#9 (UE identity cannot be derived by the network)
#11 (PLMN not allowed)
#12 (Tracking area not allowed)
#13 (Roaming not allowed in this tracking area)
#73 (Serving network not authorized)
#75 (Permanently not authorized for this SNPN)
你从这篇文章中能学到什么 我们在手机上运行一个应用程序UE是如何把应用程序的数据映射到PDU session上的 UE新建立PDU Session时是如何选择切片的。如果注册时UE的Allowed NSSAI有多个必然面临切片的选择问题。 Registration Accept消息已经下发了UE策略是如何得到的 UE策略和网络之间如何更新的
……
还有很多细节问题都会从这篇文章中学到。后续会介绍QoS flow的映射QoS Flow和DRB的映射及UPF下行数据的映射都会在后续详解中不断呈现直到把5G扒的只剩一条内裤。
内容目录
21b. UE Policy Association Establishment
1触发场景和条件
2UEPolicy为何物
3UE中如何使用URSP路由数据
4UE 策略的发送流程
5UEPolicy Association的建立
6UE策略的下发
1UE策略管理流程
2UE策略的下发
可以使用电脑点击下面链接
mp.weixin.qq.com/s/o9fCb76rP…
该篇文章为收费文章全文8000多字。目前互联网独一份看完本篇UE策略你就可以完全掌握了。
昨天发完《一文彻底弄懂UE策略5G注册流程分级详解Step21b》后针对其中UE策略的更新流程部分前文虽然进行了“标注”感觉论据并不充分多是主观理解今天又深入想了想补充一下避免介绍错了误导各位同学。
先上流程图便于后面解说 UE策略更新目前看到有两种场景
1初始注册过程中的UE策略更新和注册流程一起执行。触发条件是RegistrationRequest消息中携带UE Policy Container。AMF如果发现携带了该IE就会执行UE策略
2AMF执行Npcf_UEPolicyControl_CreateRequest后会下发触发器Triggers后续UE如果满足触发器定义的条件时进行UE策略的更新。
第二种情况比较好理解这种场景肯定是PCF触发更新TS23.502中明确有定义没有任何疑问。但是第一种场景就有歧义了歧义的起源在哪呢根源是PCF发送给AMF的Npcf_UEPolicyControl_Create Request的响应消息201 Created中消息体PolicyAssociation数据类型携带了UePolicy字段该字段可选该字段中包含的就是PCF处理过的UE策略。如果响应消息中PCF包含该字段发送给AMF那么AMF就得到了注册UE的UE策略完全可以直接提取出该字段下发给UE这样就省了PCF再次发送Namf_Communication_N1N2MessageTransfer消息传送UE策略了相当于省了一个HTTP Request/Response回合。但是AMF提取响应消息的UePolicy发送给UE的操作3GPP规范中没有写。我查遍了所有UE策略相关的规范都没有写没有写我们就不能认为这个捷径可行。
那么PCF什么时候会下发UePolicy字段给AMFAMF要来何用呢暂时还没有找到只能暂存疑。
现把昨天的“注”部分再补充说明如下
注
从上面5小节Npcf_UEPolicyControl_Create Request的响应消息201 Created中可以看到其中包含UePolicy字段该字段的内容和MANAGE UE POLICY COMMAND消息一样就是要UE策略。是否AMF收到201消息后直接使用该UePolicy字段下发给UE呢最开始时我也有此疑问。AMF收到201响应直接将其中的UePolicy使用DL NAS TRANSPORT发送给UE岂不是更好省了PCF再触发更新UE策略的流程也省了PCF和AMF之间的一条信令。结果查遍3GPP规范并没有该骚操作。
至于原因我想可能是如果AMF直接下发UePolicy字段流程会显的比较乱不闭环网元功能也有混淆。从“UE策略管理流程”可以看出来AMF在其中只是一个透明转发的作用。UE策略的更新本来是PCF的事情涉及UE和PCF两个网元。如果AMF收到了一个正常的请求响应反倒担负起来更新UE策略的责任那么AMF在其中就不能扮演一个透明转发的角色了而是AMF在其中要处理UePolicy字段提取出来再转发。这样的话这个更新并不是PCF触发的而是AMF自己臆断收到UePolicy就更新UE侧的UE策略至于是否真的需要更新UE策略AMF并没有足够的信息可以做决策。况且UePolicy字段还是可选字段PCF是可以选择不下发的。
另外从上一节的叙述中可以知道UE更新完网络下发的UE策略后要发送MANAGE UE POLICY COMPLETE确认消息给PCF该消息是必须要执行的不是可选消息。那么AMF收到UL NAS TRANSPORT消息后该怎么发送给PCF呢只能通过Namf_Communication_N1MessageNotify发送MANAGE UEPOLICY COMPLETE消息给PCF。因为TS 29.518中明确说明了N1MessageNotify用于UE策略的传递见下图。 如果AMF直接使用了201响应中UePolicy字段又何来N1MessageNotify呢因为之前PCF根本就没有给UE发送N1消息呢PCF发给AMF的一个201Created响应消息不论从什么角度来讲也不能认为有N1消息的嫌疑。。
最后不使用Namf_Communication_N1MessageNotify使用PCF订阅AMF的事件消息PCF也能收到AMF发来的通知。我们再看一下PCF订阅AMF事件的说明。订阅事件是在AM策略建立之后执行的也就是说订阅的是AM相关的变化。 综上所述不论是注册过程中UE策略的更新还是后续场景中UE策略的更新只能使用UE Configuration Update流程完成UE策略的投递。由PCF触发使用Namf_Communication_N1N2MessageTransfer消息的N1MessageContainer字段来实现AMF对UE策略的透明转发。
至于响应消息中的UePolicy信息有什么作用只能存疑了。
1.1.2.22 Registration Complete
在第21步中我们总结了UE发送Registration Complete消息的触发条件现在回顾一下。
当UE收到的Registration Accept包含下列信息时UE需要发送Registraton Complete消息 5G-GUTI TA List SOR transparent container IE Operator-defined access category definitions IE Extended emergency number list IE CAG information list IE UE radio capability ID IE UE radio capability ID deletion indication IE 收到任何和切片相关的信息如Allowed NSSAI、Configured NSSAI、Network Slicing Subscription Change Indication等等。
UE成功发送完Registration Complete消息后还需要把5G-GUTI传递给UE的RM层目的是NG-RAN使用RRC Inactive State功能时需要使用5G-GUTI的一部分来计算寻呼帧Paging Frame方法是5G-S-TMSI mod 1024取模1024。
如果在Registration Request消息的5GS Registration type IE中指示Follow-on request pending或者网络有下行数据要发送AMF完成发送完Registration Accept后不会立刻释放信令连接。
如果没有上面的信息则会立即释放NG-AP信令连接、AN接入网信令连接以及N3用户面连接。什么时候会在注册流程中出现N3信令面连接呢比如UE有需要always-on PDU Session如果没有数据要发送就会释放N3连接。
下面看Registration Complete消息的定义 Registration Complete消息比较简单基本只是用来向AMF确认已经收到了关键信息。虽然有SOR transparent container IE貌似包含一些信息实际上此处的SOR transparent container IE也只是用于向网络确认UE已经正常收到Registration Accept消息中的SOR transparent container并没有其它的作用。
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指示呢具体场景如下
1UE和网络在当前注册区相当于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”信息那么在步骤14b23中又发生了什么居然在24步时让AMF摇身一变可以如此自信的向UDM发送Homogeneous Support of IMS Voice over PS Sessions更新注册信息了呢
1.1.2.24.1案发现场回顾
我们先来回顾一下案发现场看看14a步骤之后又发生了什么事情
1Step 14bAMF获取签约数据
2Step 14cAMF订阅签约数据变化
3Step 14dold AMF去注册
4Step 14eold AMF取消订阅UDM签约数据变化
5Step 15如果new AMF不适用old PCF则选择新的PCF
6Step 16new AMF新建立UE的接入策略
7Step 17释放UE请求的PDU Session资源
8Step 18、193GPP接入不涉及
9Step 20AMF请求gNB初始化UE Context
10Step 21AMF回复UE注册接受消息Registration Accept
11Step 22UE发送注册确认Registrationg Complete消息
12Step 23AMF下发或修改gNB中RRC INACTIVE信息
下面我们用排除法排除案发后的12个步骤中AMF无法获得信息的步骤。显然28、101112项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 14bAMF获取签约数据”该步骤对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
这些判断基础数据虽然只是举例但是已经够全面了翻译过来是
1AMF本地策略
2UE能力
3HPLMN IP地址是否保留
4HPLMN 5G到3G的SRVCC是否支持
5NG-RAN的覆盖情况
6gNB发送的Voice Support MatchIndicator
其中第5不涉及2和4项基础数据在UE的注册请求Registration Request中会携带给AMF第1项是AMF本地配置的。也就是说上面的第124项基础数据AMF在第14a步骤之前已经得到了。只剩下3、6项信息在执行第14a步时不能得到我们分别看一下
第3项“HPLMN IP地址是否保留”应该是指SSC模式即该模式能否保证用户的IP地址不变对于IMS语音通话该项基本是必须的要求。
这两项内容在“Step 14bAMF获取签约数据”中都会得到那么还剩下最后一项“6gNB发给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是可选IEAMF可以在该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 CapabilitygNB本地又没有此时就会触发第2步。
UE RADIO CAPABILITY CHECK REQUEST消息的定义 -2 UE Capabiltiy Enquiry
-3 UE Capability Information
第-2-3步在注册流程的第21步中已经介绍过了这里就不再重述了。这两步都是可选项如果第20步中已经获取过了gNB会将UE Radio Capability保存在本地的UE Context中并通知给AMFAMF也会保存不需要理解其内容。那么这两步都不会执行。
对于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步的详述。
1.1.2.24.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 hasnt 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才好否则还真有麻烦。
25. Network Slice-Specific Authentication and Authorization
UE的Allowed NSSAI中有需要NSSAA的切片时需要触发该流程。切片的鉴权使用EAP鉴权框架并且需要使用GPSI。该步骤也非常复杂部分内容在第21步骤中已经进行了部分介绍。NSSAA的详细流程这里就不进行详解了。目前在网络中暂时还没有用到后续使用后再进行详解。
最后对于移动性注册更新因为new AMF从old AMF得到了UE事件的全部订阅。所以在new AMF执行完注册后需要通知所有订阅UE可达性事件的NF。
1.1.3 移动性注册更新流程图
虽然前面的详解流程把每一步骤的触发条件都说明了但是对于初学者判定这一步是否执行时可能仍有困难下面把移动性注册流程图和周期性注册流程图贴一下方便初学者学习。
在学习注册流程中第一个需要知道在什么场景下UE触发的是什么类型的注册流程。这部分内容在注册流程详解的第一步中有明确的说明。后面的步骤重点关注触发条件及携带的参数。这样整个注册流程学完之后会知道其中的原理什么特性是手机发送给网络的什么特性是网络下发给UE的。
虽然感觉详解系列已经说明的很细致了可能仍有一些疏漏各位同学如果平时学习遇到疑惑可以公众号后台随时发消息。
流程图中的步骤序号相比初始注册都没有变化初学者可以根据流程的序号对照之前的详解步骤就可以直接学习 1.1.4 周期性注册更新流程图 1.2 带AMF重选的注册流程
到这5G SA注册流程详解完成下一篇开始详解的内容是带重选的5G注册这个步骤基本是5G注册的标配。
在国内5G建网初期行业切片的场景比较少出现切片不支持导致的AMF重选可能比较少。目前最有可能出现重选的场景是基站连接多个核心网比如同一个基站连接两个ToB、ToC两种核心网或者同一个基站连接两个不同厂家的AMF POOL的场景这样就会面临ToC的AMF不支持物联网的切片或者网络要引导UE注册到指定的核心网导致AMF重选流程的发生。
对于同一个厂家基站连接两个核心网POOL的情况4G的时候华为还有相关网络资源的分配专利。5G时连接两个POOL的场景单从技术来讲也没有问题但是不能指定哪个POOL。因为在同一个基站同一个TAC下基站根据已有的信息没法选择指定的核心网POOL。在5G的时候还有C-RAN类型的基站即一个BBU下可以连接多个RRU。这种RRU形式的基站如果配置不同的TAC核心网可以通过AMF重选的流程将UE重定向到另外一个核心网AMF POOL。
也许有人会想为什么C-RAN类型的BBU不能根据UE所处的TAC直接把UE的消息路由到指定的AMF POOL呢这样就省了由于选择错误导致的核心网重选流程。我们看一下原因。
1.2.1 同一个基站连接两个核心网AMF POOL的场景分析
gNB上电后会根据配置的AMF地址发起SCTP偶联的建立AMF的IP地址目前是基站配置好的另一种方法也可以通过DNS获取但这种方法目前还没有使用的。
SCTP偶联建立完成后也相当于建立了第一条TNL Association但是后续如果想新增加TNL Association则需要AMF向gNB发送AMF CONFIGURATION UPDATE消息携带其它的IP地址建立新的TNL Association。当TNL Association建立成功后gNB在这条TNL Association上发送第一条RAN CONFIGURATION UPDATE消息AMF收到消息后会通过Global RAN node ID将这条TNL Association和NG-C接口实例关联。从这段叙述中可以看出来gNB在开局的时候只需要配置一个AMF的IP地址就可以了其它的IP地址可以通过AMF下发给gNB。
注
SCTP偶联和TNL association虽然类似但不是完全相同的东西。比如多归属SCTP偶联可以有多个但同时只有一条起作用但是TNL Association的多条可以同时有效。
接下来我们看一下TNL Association可用后gNB和AMF间交换信息的流程这些信息就关系到“为什么基站没法为UE选择指定AMF POOL”的原因。流程图如下 gNB通过NG SETUP REQUEST消息将自己的信息发送给AMF。NG SETUP REQUEST消息的定义如下 消息内容很直观从消息定义中我们可以看到gNB将自己支持的Global RAN Node ID、TAC List、TAC切片支持列表、广播的PLMN等信息发送给了AMF。
再看一下AMF发送的NG SETUP RESPONSE消息的定义 从AMF的回复消息中可以看到AMF把自己的GUAMI、容量因子、AMF支持的切片、支持的PLMN信息发送给了gNB。这些信息就可以供gNB在注册流程中选择AMF使用。
这条NG SETUP RESPONSE消息中并没有把AMF支持的TAC发送给gNB所以对于C-RAN类型的基站如果TAC相同的话基站从上面的信息中根本无法将UE的注册请求消息路由到指定的核心网。当然切片可以gNB可以根据切片选择不同的AMF POOL。
最后在C-RAN类型的基站连接两个核心网AMF POOL场景下比如不同厂家的AMF POOL如果要实现UE在指定AMF POOL中登记注册只能通过C-RAN下的RRU配置不同的TAC之后核心网使用NSSF重选AMF的功能来实现UE在指定的AMF POOL中注册的目的。
下面就开始详解带AMF重选的注册流程。
1.2.2 流程图
带AMF重选的注册流程大部分的内容和初始注册流程基本一致只是把不同于1.1 注册流程的步骤详解一下即可。
这里的初始AMF是指第一次收到Registration Request消息的AMF。 1.2.3 专享篇 gNB转发将承载有Registration Request消息的Initial UE MessageN2发送给初始AMF。gNB选择AMF的方法详见1.1.2.2 AMF选择。 AMF收到Registration Request消息后向old AMF获取UE Context、触发AUSF的鉴权流程等步骤和1.1章节相同这几步都是可选的步骤。
这一步需要执行的原因是初始AMF需要用户的SUPI和签约数据用于判断当前的初始AMF是否能够为UE服务如果不能够服务当前的UE初始AMF需要重新路由Registration Request消息。
3a. 如果初始AMF从old AMF没有得到UE Context此时这一部分数据就需要从UDM中获取。本步骤初始AMF使用SUPI向NRF执行UDM服务发现进行UDM选择。
3b. 初始AMF从UDM下载用户的切片选择签约数据。
3c. UDM返回UE的切片选择签约数据。
4a. 如果AMF根据签约数据判断不能服务于注册请求Requested NSSAI中所有已签约的S-NSSAI切片初始AMF需要查询NSSF来获得可以为UE提供服务的AMF信息。
4b. NSSF返回AMF Set或者AMF候选AMF地址、Allowed NSSAI等信息。NSSF也可能返回用于选择AMF的NRF。
初始AMF向old AMF发送Namf_Communication_RegistrationStatusUpdate消息通知old AMF当前UE在初始AMF注册没有成功完成。
6a. 初始AMF向NRF执行服务发现发送Nnrf_NFDiscovery_Request请求。
6b. NRF返回给初始AMF目标AMF的地址等信息。
7(A). 初始AMF根据具体情况选择7A或者7B进行AMF重选的消息传递。如果初始AMF和目标AMF可以直接通信则通过Namf_Communication_N1MessageNotify转发注册消息到目标AMF。
7(B). 如果初始AMF不能和目标AMF直接通信初始AMF会将重新路由的注册消息发送给gNB由gNB再将注册消息发送给目标AMF。
8. 目标AMF收到注册消息继续执行后续注册。步骤和我们在1.1节叙述的第422步注册流程一样。
带AMF重选的注册流程相比1.1节叙述的注册流程只是多了重选的步骤其它完全一样。
1.2.4 优享篇
1.2.4.1 Initail UE Message
消息方向gNB - AMF
TS 23.502中带AMF重选流程的第1步相当于初始注册流程的第13步直接从AMF收到Initial UE Message开始。该消息是N2接口消息详见1.1.2.3章节。
1.2.4.2 初始注册流程的steps 4-9b
Steps 4-9b的步骤也是可选的我们先简单回顾一下是哪些步骤 Step 4、5new AMF向old AMF获取UE Context。这里的new AMF和本步骤说的初始AMF是一个意思 Step 6、7如果没有从old AMF获取到UE Context或者5G-GUTI没找到对应的AMF就需要向UE索取SUCI用于注册 Step 8AMF进行AUSF选择。通过SUCI或者SUPI查询NRF为UE选择鉴权的AUSF。 Step 9aAUSF对UE进行鉴权详见1.1.2.9章节。 Step 9b执行NAS安全也就是开启NAS消息安全流程详见1.1.2.9.4章节。
之后初始AMF判断是否需要重新路由初始NAS消息即Registration Request消息。
为什么要在鉴权成功后初始AMF才执行重选而不是收到注册消息就执行重选AMF呢
原因相对比较容易想到我想到的一些原因如下
1网络首先要确认UE是否是非法用户否则后续的任何流程都没有意义只能白白占用网络资源。从old AMF获取UE Context或者执行AUSF鉴权都是这个目的
2后面要介绍的步骤3aUDM的选择只有SUPI一个选择因子如果UE没有被网络认可得不到SUPI
3从UDM获取签约数据一定要是网络鉴权通过的用户否则任何AMF岂不是都可以到UDM中获取数据。另外到UDM中获取签约数据的URI也需要SUPI作为参数。
1.2.4.3a UDM选择
详见1.1.2.13章节。UDM的选择需要利用NRF。
1.2.4.3b Nudm_SDM_Get(Slice Selection Subscription data)
消息方向初始AMF - UDM
切片选择签约数据就是1.1.2.14b章节介绍的切片签约数据。
需要注意的是网络切片NSSAI签约数据是在AMF注册前查询用于辅助网络选择的签约数据。其它的签约数据都是在注册后查询才有意义如果考试这可能就是一个考点。
1.2.4.3c Nudm_SDM_Get response
消息方向UDM - 初始AMF
详见1.1.2.14b章节介绍的切片数据。
1.2.4.4a Nnssf_NSSelection_Get
AMF和NSSF之间的接口为N22。
该步骤用于NSSF向AMF提供Allowed NSSAI和Configured NSSAI等信息。需要注意的是AMF向NSSF发消息是根据本地的配置找到的NSSF而不是像SMF、UDM等是通过查询NRF发现的。 获取切片信息的资源URI
{apiRoot}/nnssf-nsselection/{apiVersion}/network-slice-information
该请求消息没有消息体只有HTTP请求的查询参数。
我们先看一下GET请求能够得到哪些信息后面会详细介绍相关各个信息
1切片选择信息
包括allowed NSSAI、Configured NSSAI、目标AMF Set或者候选AMF列表及其它可选的信息如下 Allowed NSSAI和Configured NSSAI的映射 Allowed NSSAI的网络切片实例Network Slice instancesIDNSI ID 用于执行网络切片实例NSI选择的NRF及用于确定AMF Set中的目标候选AMF列表NRF 注册请求Requested NSSAI中被NSSF拒绝的S-NSSAI。
2PDU Session Establishment流程中用于执行会话切片关联的NFs/services服务发现的NRF。
3HPLMN和VPLMN之间的切片映射信息。
下面介绍HTTP请求的查询参数即上图问号后面的具体信息详见下图 重点IE介绍
nf-type
消费者的NF类型。在本流程中即初始AMF的NF类型。NF类型基本就是网元类型。常见的比如AMF、SMF、UDM等后续陆续会有UCMFUE无线能力管理的网元、MME、HSS、PCSCF、ICSCF、SCSCF、NSSAAF等
nf-id
AMF的NF ID即AMF的UUIDUniversally Unique Identifier。5GC中采用的是UUID version 4。
slice-info-request-for-registration
注册流程或者4G到5G基于N26接口的切换流程中需要包含该IE。其中包含的具体信息如下图一部分信息是从UE的注册请求中获取的一部分是UE的签约数据。其中 subscribedNssai除了包含Subscribed NSSAI列表还包含default S-NSSAI指示 sNssaiForMapping在下面的requestMapping设置为True的情况下会包含该IE其中包含的S-NSSAI是HPLMN即归属网络的切片。 mappingOfNssaiVPLMN到HPLMN的映射。
其它的IE比较好理解就不具体介绍了。 slice-info-request-for-pdu-session
PDU Session建立过程中包含的切片请求信息内容相对简单。只包含
S-NSSAI必选IE会话请求建立的S-NSSAI具体的设置方法我们在UE Policy中已经介绍过详见章节1.1.2.21b。
当UE在漫游场景时对于归属地漫游的PDU Session建立请求vNSSF查询hNSSF时包含的应该是归属地的S-NSSAI。原因比较好理解假如UE处在漫游地发了一个只在漫游地使用S-NSSAI归属地根本不识别。此时就会用到下面的homeSnssai IE。 roamingIndication必选IE漫游指示。指示UE的漫游状态NON_ROAMING、LOCAL_BREAKOUT、HOME_ROUTED_ROAMING。 homeSnssai可选IE归属地漫游时PDU Session建立场景使用。 slice-info-request-for-ue-cu
UE Configuration Update流程中使用的信息和slice-info-request-for-registration包含的内容差不多只是不包含sNssaiForMapping和requestMapping。
该IE的适用场景比较好理解当用户UDM中签约的切片发生改变时比如用户在营业厅变更了签约切片导致的UE重新注册就会涉及到这部分信息的获取。
home-plmn-id和tai比较好理解就不介绍了。
1.2.4.4b Nnssf_NSSelection_Get response
NSSF可能的响应消息如下 如果NSSF查询成功返回200 OK消息。消息体中包含的就是AuthorizedNetworkSliceInformation具体内容如下 从上面的返回信息可以看到allowedNssaiList、configuredNssai、nsiInformation、supportedFeatures、nrfAmfSetNfMgtUri是条件可选IE其它都是可选IE。
重点IE介绍
allowedNssaiList
NSSF收到Requested NSSAI和subscribed S-NSSAI(s)或者请求消息中requestMapping IE设置为true时返回消息中包含该IE。
configuredNssai
NSSF没有收到Requested NSSAI、或者Requested NSSAI包含的个别S-NSSAI无效、或者defaultConfiguredSnssaiInd 设置为true时返回消息包含该IE。如果requestMapping设置为true时不能包含该IE也就是和上面的allowedNssaiList是互斥的关系。
targetAmfSet
请求消息中包含Requested NSSAI和Subscribed S-NSSAI时可能包含该IE。之后AMF使用目标AMF Set查询NRF进行目标AMF的发现。
如果请求消息中包含requestMapping则不能包含该IE。
candidateAmfList
该IE是NfInstanceId的形式即UUID的格式ID而不是AMF的名字。请求消息中包含Requested NSSAI和Subscribed S-NSSAI时可能包含该IE。同样如果请求消息中包含requestMapping则不能包含该IE。
nsiInformation
PDU Session建立过程中如果NSSF收到了S-NSSAI返回消息需要包含该IE。
同样如果请求消息中包含requestMapping则不能包含该IE。
supportedFeatures
当网络支持额外的网络特性即NSSF返回307或者308响应需要重定向请求时会包含该IE。
目前基本不会用到除非将来5G应用场景非常多很多定制化需求时可能会用到。
nrfAmfSet
当包含targetAmfSet IE时就可能要包含该IE代表NRF NFDiscovery Service的URI。这样初始AMF使用该URI就可以直接发现候选AMF。
注
在这我们不禁会想到一个问题目前网络中AMF本地都会定义NRF的地址信息如果NSSF在响应中也返回了NRF的地址那么这两个NRF地址哪个优先级更高呢按照规范中优先级相关的定义章节来看一般在信令携带的信息和网元本地配置的信息都存在时信令携带的信息优先级要更高一些。这样在gNB多家运营商共享甚至个别专用网络共享基站场景下NSSF利用该IE可能还会将UE引导到指定专网上进行注册非常适合垂直行业的专网应用。
nrfAmfSetNfMgtUri
如果上面nrfAmfSet IE存在时就需要包含该IE内容是NRF NFManagement Service的URI。
targetAmfServiceSet
目标AMF Service的集合也需要像AMF Set一样需要执行NRF发现才能获得目标AMF信息。
如果NSSF没有找到可用的切片NSSF可能就会返回403 Forbidden包含SNSSAI_NOT_SUPPORTED 错误原因。
1.2.4.5 Namf_Communication_RegistrationStatusUpdate
此时初始AMF发送给old AMF携带的原因值NOT_TRANSFERRED表示UE还没有注册成功需要old AMF继续保留UE Context。详见章节1.1.2.10。
1.2.4.6a Nnrf_NFDiscovery_Request
我们先看该步骤的触发条件。从第4b步骤中初始AMF通过查询NSSF已经可以得到候选目标AMF列表candidateAmfList或者目标AMFSettargetAmfSet。
如果初始AMF得到的是目标AMF的列表AMF根据本地配置选择一个目标AMF如果本地保存有目标AMF的信息如IP地址就不需要查询NRF了。如果没有目标AMF的信息或者NSSF返回的是AMF Set就需要查询NRF获得目标AMF的NF Profile其中包含目标AMF的信息。
初始AMF查询NRF的服务发现流程如下图 请求消息的HTTP方法为GET
请求的资源URI{apiRoot}/nnrf-disc/v1/nf-instances
GET请求的消息体为空但是GET的查询参数非常丰富3GPP中一共有8页之多基本所有的网络名词都可以作为查询参数具体详见TS29.510这里就不细说了。
在AMF重选的注册流程中可以使用NFInstanceID及AMF Set ID、NF类型AMF作为查询参数查询目标AMF。
1.2.4.6b Nnrf_NFDiscovery_Request Response
服务发现的查询结果如下图 如果查询正常匹配到了查询参数中的内容则返回200 OK响应响应消息体为SearchResult。如果没有找到会携带相应的错误原因。
SearchResult的内容就是NF在NRF中注册时的NF Profile、查询结果有效期等。详见下图 重点信息介绍
validityPeriod
查询结果的有效期。比如初始AMF查询完NRF后查询结果在多长时间内有效计时单位为秒。需要注意的是该值和HTTP响应消息头部“Cache-Control”中的“max-age”的值相同。
nfInstances
查询结果的NF实例即NF的NF Profile里面包含NF的基本信息比如IP地址、提供的服务等信息。初始AMF据此就可以找到目标AMF的IP地址。
需要注意的是该字段信息也可以为空表示没有NF实例匹配上查询参数。在本例中就是没有找到合适的目标AMF。此时根据设备的实现方式初始AMF可能会直接拒绝UE的注册也可能就会用第7步的B方法将注册消息转发给基站由基站根据Allowed NSSAI等信息决定将注册消息路由到哪个AMF。如果再次收到消息的AMF发现是重路由的UE注册消息本AMF还是不能支持一定是要拒绝掉UE的注册请求的不可能让注册消息在gNB和AMF之间踢皮球。这属于设备实现方面的问题。3GPP规范里目前还没有读到相关的处理规则。但是基站一定不会直接拆掉RRC连接放弃UE注册。因为即使拆掉了RRC连接按照规范UE还是要重新建立RRC连接进行注册会继续浪费网络资源。
searchId
如果返回消息中包含searchId在查询结果的有效期内AMF可以使用该searchId查询。完整的查询即{apiRoot}/nnrf-disc/v1/searches/{searchId}。
除正常的200 OK成功相应其它错误响应有307 Temporary Redirect、400 Bad Request、403 Forbidden、404 Not Found、500 Internal Server Error。
需要注意的是404 Not Found的意义并不是没有找到匹配的NF实例而是代表查询的URI找不到或者在分层部署NRF时本地NRF缺少信息将请求转发或重定向到其它NRF时返回该错误码。
初始AMF收到NRF的返回信息根据收到的候选AMF的能力信息、本地策略等选择一个合适的目标AMF。
如果初始AMF和UE之间已经建立的安全连接也就是说网络对UE进行了鉴权启动了NAS安全。根据1.1.2.9.4章节的叙述此时UE和AMF之间的ngKSI指向的NAS Security Context是一致的这样才能保证UE和AMF之间的NAS消息互相能够加密和完整性校验通过那么这种场景下为了避免注册失败初始AMF会将注册NAS消息直接转发到目标AMF也就是通过1.2.4.7a步骤的Namf_Communication_N1MessageNotify消息。
为什么直接转发可以避免注册失败呢接着看后面的详解。
1.2.4.7aA Namf_Communication_N1MessageNotify 这条消息我们在1.1.2.21.6.2章节介绍UE策略时介绍了一部分内容。这里介绍该消息AMF间消息传递的功能。
7aA和7aB两个步骤是转发NAS消息的两种方法不会同时出现。在实际应用中具体使用方法A还是方法B取决于AMF本地配置的策略和签约信息。签约信息怎么理解呢比如多个运营商基站共建但是核心网独自建设此时初始AMF就要根据用户的签约把消息转发到UE归属运营商的网络。至于AMF本地配置的策略本章节后面会具体介绍。
A方法有一个使用场景在TS23.501中有明确说明如果NSSF直接返回了候选AMF列表则初始AMF只能通过Namf_Communication_N1MessageNotify消息转发注册请求。
我们面临的第一个问题是n1NotifyCallbackUri从哪里来UE策略下发时使用的Callback Uri是PCF订阅AMF事件时生成的而这里new AMF和初始AMF素未谋面根本谈不到订阅关系那么这个URI从哪里得到呢
在重选AMF流程中n1NotifyCallbackUri是从NRF返回给初始AMF的NF Profile中得到的。NF Profile中包含defaultNotificationSubscriptions字段该字段类型为DefaultNotificationSubscription从其数据类型定义中可以看到callbackUri。Registration Request的传递就是通过调用该URI进行的。详见下图 其中
notificationType
该值为N1_MESSAGES取值时用于N1消息的传递。
callbackUri
初始AMF通知目标AMF时使用的Call URI地址。
n1MessageClass
当notificationType取值为N1_MESSAGES时需要包含该IE并且该消息的取值为5GMM。 上面Callback Uri的问题解决了下面看一下消息体N1MessageNotification的内容。详见下图 从上图可以看出来消息体数据类型中的n1MessageContainer就包含有初始NAS消息。n1MessageContainer中n1MessageClass的取值为“5GMM”表示n1MessageContent的内容就是5GMM NAS消息Registration Request。
Namf_Communication_N1MessageNotify Request消息除了把Registration Request消息带过去了还带有其它信息
1RAN NGAP ID和初始AMF的名字。 AMF的名字是字符串类型用于在gNB中识别AMF。在这里用于让gNB识别N2终结点
2RAN标识如RAN Node Id、RAN N2 IPv4/v6地址
3gNB之前发送给初始AMF的信息如UE的位置信息、RRC Establishment Cause、UE Context Request等这些信息从Initial UE Message消息中都可以得到详见1.1.2.3章节介绍。UE Context Request用于在注册请求被AMF接受后向gNB发送Initial Context Setup Request消息初始化gNB中的UE Context
4UE的SUPI及UE的MM Context移动性管理相关的数据。这部分数据通过鉴权流程可以得到
5UE的Allowed NSSAI及其对应的NSI ID。初始AMF已经和UDM、NSSF交互过Allowed NSSAI已经可以确定了。
上述的五条信息都包含在N1MessageNotification数据类型中的registrationCtxtContainer字段中该字段完整的数据类型定义如下图 在上面这张registrationCtxtContainer数据定义图中需要重点关注的就是ueContext它里面包含的内容很多其中MmContext作用很大其中包含有初始AMF和UE协商好的加密和完整性保护算法、上行和下行的NasCount等信息用于执行消息的安全保护。 响应消息
Namf_Communication_N1MessageNotify Request的响应消息比较简单如果目标AMF成功接受请求消息直接返回204 No Content。其它响应消息信息如下图 从上面的叙述能够看出来初始AMF使用N1MessageNotify消息把UE当前的安全上下文信息传递给了目标AMF。根据TS 23.502的规定如果UE和初始AMF之间已经建立了安全上下文为了避免用户注册失败初始AMF需要通过7aA步骤直接转发NAS消息即Registration Request消息给目标AMF。
这句话怎么理解呢如果初始AMF收到Registration Request消息找到了old AMF并且old AMF成功对注册消息进行了完整性校验此时初始AMF得到了注册UE的UE Context。初始AMF根据UE Context就可以判断不能为UE服务就需要访问NSSF寻找目标AMF。这样就不能算是UE和初始AMF建立了安全上下文。因为对注册请求的解密和完整性验证都在old AMF中执行的初始AMF只是起了消息传递的作用而且如果初始AMF不能为UE服务还需要通知old AMF继续保持UE Context等待该UE的真主出现。初始AMF也不会保存UE Context。
UE和初始AMF建立安全上下文的意思就是说初始AMF执行了AUSF参与的鉴权流程详见1.1.2.9.1章节介绍。此时UE和AMF协商了加密和完整性保护算法UE和初始AMF间启动了NAS消息的安全保护功能。
当然这中间还会面临一个能不能直接转发的问题。比如北京和河北的AMF可能根本都不允许直接互访。不过目前国内某运营商的网络互访貌似还没有问题。这都是根据具体的网络部署情况决定的也属于本地策略的范畴。像刚才这个例子同一个基站现实中也不可能同时连接北京和河北的AMF。现网应用的场景远比我们技术探讨时遇见的场景简单基本不会出模糊或者罕见的场景。3GPP规范里一般的原则就是是否是同一个AMF Set同一个AMF Set内要允许互访。实际应用中一般用AMF Set来区分是否是同一个AMF POOL也就是AMF POOL内的各个AMF要允许互访。
如果初始AMF不能为UE服务通过gNB将注册消息转发给目标AMF就是NAS消息重路由的B方法。
1.2.4.7aB Reroute NAS message
3GPP TS 23.502中对该步骤的使用场景进行了介绍总结如下
1初始AMF和目标AMF不属于同一个AMF Set
2初始AMF通过AMF Set查询NRF没有得到候选AMF列表
3初始AMF根据自身配置判断自己无权为UE提供服务。
4如果初始AMF查询NSSF没有返回候选AMF列表也就是NSSF不知道哪些AMF满足UE的请求。比如多个运营商共享基站收到注册消息的AMF也不会知道另一个运营商的AMF情况但是基站共享基站一定会知道这种情况初始AMF就会把注册消息发送给gNB由基站选择合适的目标AMF。
上面虽然列举了四个条件在实际应用时需要综合考虑来决定选择哪个方法转发注册请求消息。
需要注意的一点是如果初始AMF不能为UE服务通过gNB将注册消息转发给目标AMF无法携带UE的安全上下文信息。
注
为什么经过gNB对NAS消息重路由不携带安全上下文原因是消息里没有定义相关的字段。至于不定义的原因也许是保证核心网的安全相关安全数据不暴露给基站RAN。按照通信核心网的思路核心网内自己的东西认为是安全可信的安全数据不要流出自己的可信范围。
AMF将注册消息发回给gNB使用的消息是REROUTE NAS REQUEST该消息用于将INITIAL UE MESSAGE消息重新路由到其它AMF。我们先看消息的定义 重点IE介绍
RAN UE NGAP ID
基站侧用于区别UE的ID为必选项。
AMF UE NGAP ID
AMF侧用于区别UE的ID该IE为可选项因为本来该UE就需要在别的AMF上注册初始AMF为该UE分配AMF UE NGAP ID并没有什么意义。
NGAP Message
其中包含有基站发送给初始AMF的INITIAL UE MESSAGE。初始AMF相当于把收到的初始N2消息又转发回了基站。
AMF Set ID
从NSSF中得到的AMF Set ID。基站可以根据其选择目标AMF转发INITIAL UE MESSAGE。
Allowed NSSAI
初始AMF从NSSF中获得的Allowed NSSAI包含在这可以辅助基站选择目标AMF并且目标AMF根据该字段也可以知道UE的Allowed NSSAI。
Source to Target AMF Information Reroute
该IE用于初始AMF向目的AMF透明传递NSSF提供的信息具体信息如下 从上面IE可以看出来并没有给传递安全信息留有位置所以通过gNB转发的注册消息不包含初始AMF的安全数据。
1.2.4.7bB Initial UE message
基站从根据收到的REROUTE NAS REQUEST提取出相关信息重新组合成新的INITIAL UE MESSAGE发给目标AMF消息名和第一次基站发送注册消息给初始AMF的消息名称一样只是携带的字段不同。我们再复习一下INITIAL UE MESSAGE消息的定义如下图。 我们现在再看这条消息定义的很多字段就非常清晰了比如其中的AMF Set ID、Allowed NSSAI等IE的来源就很容易理解分析到这我们在1.1.2.3章节的疑惑就烟消云散了。在之前详细分析时Initial UE Message中的Allowed NSSAI困惑了我很长时间。TS 38.413中根本没有对该IE的来源进行介绍只是让参看TS 23.502而TS 23.502是一个600多页的规范找Allowed NSSAI的使用场景相当麻烦了。规范虽然介绍的很详细考虑的也很周全但是用它来学习5G还是很花时间的对于初学者也并不适合。 最后这一步大部分只剩下技术探讨了规范里介绍的很简单注册流程全图的Steps 4-22重新再来一遍。下面针对其中的重复步骤分析一下是不是必须的只做一家之言仅供日常参考分析问题随时欢迎各位同学一起讨论。
1.2.4.8.1 初始AMF从old AMF得到UE Context
此种情况下UE可以不需要执行鉴权流程直接利用原来的安全上下文。此时初始AMF根据UE Context中的Allowed NSSAI来判断是否能够支持UE请求的所有切片。如果不能够为UE提供服务则执行AMF重选。之后选择B方法通过RAN将注册消息转发到目标AMF之后目标AMF重新从第4步骤old AMF获取UE Context开始执行后续流程。是否执行鉴权流程和之前介绍的一样主要看old AMF中的UE Context是否可用。
为什么是比较Allowed NSSAI呢因为从UE Context中包含的mmContex的定义来看其中只包含Allowed NSSAI及其映射。详见下图 我们根据TS 24.501的说明UE在移动性注册中Registration Request消息中携带的Requested NSSAI来源只有Allowed NSSAI和Configured NSSAI。UE在之前的注册中收到Registration Accept消息内容的时候会将获得的NSSAI和PLMN关联起来保存在UE的非易失存储器中。后续进行注册时携带的Requested NSSAI应该是同一个PLMN的可以理解为同一个运营商即使不是同一个PLMN也需要包含相关切片的映射所以对于移动性注册由于AMF不支持请求的切片导致AMF重选的情况应该不会出现国内同一个运营商各个省部署的切片基本是一致的。出现重选AMF的场景基本就是同一区域下可能有两个厂家的AMF POOL覆盖我们又要指定区域下的UE注册在指定的AMF上比如CRAN基站的覆盖可能就会出现AMF重选但是此时AMF需要通过TAC来区分不同的区域否则核心网无法引导UE在指定的AMF POOL注册。
对于初始注册也一样如果UE在同一个PLMN下注册过本地保存有Allowed NSSAI和Configured NSSAI再次发起初始注册时会携带Requested NSSAI基站根据NSSAI选择AMF出现AMF重选情况可能也比较少。初始注册出现AMF重选比较多的情况可能是不同PLMN下的初始注册或者重新插拔USIM卡后的注册此时UE发送的注册消息不携带Requested NSSAI基站会将注册消息发送到默认AMF出现AMF重选。
1.2.4.8.2 初始AMF没有从old AMF得到UE Context
没有得到UE Context原因可能是UE使用SUCI注册、或者初始AMF找不到old AMF或者不同PLMN间的注册N2接口无法重定向old AMF只返回了SUPI等等。
上面这些情况就需要初始AMF和AUSF进行UE鉴权之后下载UDM中的切片选择数据判断是否需要执行AMF重选。
TS 23.502有一段备注如果AMF重建了UE安全上下文初始AMF需要直接转发注册消息到目标AMF这样可以避免注册失败。失败的原因是UE和AMF的安全上下文不同步。为什么会这么说呢这里简单分析一下。
从1.1.2.9章节我们知道AMF和AUSF之间如果发生了鉴权AMF会获得新的密钥之后根据新密钥启动NAS的安全保护。此时UE和AMF之间的安全上下文是同步的。如果此时的AMF初始AMF下载完切片数据后发现自己不能为UE服务重选了一个AMF即目标AMF。我们需要从下面两种方法选择一个转发注册消息
1如果此时采用A方法也就是初始AMF直接转发注册消息和UE Context包含安全上下文部分给目标AMF。那么根据上下文理解此时应该从注册流程全图的第13步“选择UDM”开始执行后续流程。因为这样就跳过了目标AMF和AUSF重新执行鉴权的步骤也就是跳过了目标AMF使用新的安全上下文的步骤此时目标AMF使用的仍然是初始AMF的安全上下文信息。从1.2.4.7aA步骤的介绍能看到Namf_Communication_N1MessageNotify消息除了发送了注册消息还把注册上下文其中包含安全上下文信息一起也发送了。这样就能保证目标AMF在向UE发送Registration Accept时使用的安全上下文和UE同步UE能够正常执行解密和完整性保护验证注册成功执行。也就是TS 23.502说的避免了UE注册失败。
我们从现网设备抓取到的一个AMF重选信令信令流程如下 从上图可以看到目标AMF收到了Namf_Communication_N1MessageNotify消息之后又和UE重新进行了一次完整鉴权也就是目标AMF和UE又协商了一个新的安全上下文。我们抓取信令的业务场景是UE使用SUCI注册显然初始AMF已经执行完了一次鉴权流程从N1MessageNotify消息的内容RegistratonCtxContainer也能看到携带了安全上下文如下图。 从现网信令来看该厂家的设备目标AMF完整执行了注册流程全图的Step 4-22目标AMF没有跳过鉴权相当于带AMF重选的注册流程需要执行两次鉴权注册时延会增加但注册成功率应当会由一定程度的提高。这种处理方式最保险不容易出现bug而且程序的判决逻辑比较简单。
如果目标AMF重新执行一次鉴权就不涉及TS 23.502中说的安全上下文同步和不同步的事情了UE和目标AMF安全上下文一定是同步的。
TS 23.502中还有一个备注如果初始AMF和目标AMF发生了直接消息传递的情况就不能保证切片之间的隔离了。这点比较好理解比如初始AMF是切片1目标AMF是切片2如果他们之间发生了通信相当于切片1和切片2的独立逻辑网络之间发生了通信。原本切片之间的隔离性就破坏了。
2如果此时采用B方法通过基站转发注册消息从上面的叙述中知道目标AMF得不到新建立的安全上下文但是目标AMF仍然能继续处理Registration Request消息。因为TS 24.501规定不管有没有安全保护AMF都需要能处理注册请求消息。之后注册请求会在目标AMF中继续Step422步完成UE的注册流程。UE和目标AMF之间的安全上下文一直是同步的注册流程正常也会成功。
1.2.4.8.3 结论
综合上面的分析可以得到下面几点
1不管初始AMF能不能从old AMF得到UE Context如果重选AMF后执行一次鉴权注册都会成功。这里不含意外情况只针对安全上下文来说。
2如果通过gNB转发注册消息目标AMF如果能够找到old AMF则获取UE Context不需要AUSF鉴权。如果得不到old AMF中的UE Context目标AMF一定会执行鉴权。这个场景和不发生AMF重选的场景基本一样也比较容易理解。
3如果目标AMF从初始AMF得到了安全上下文在old AMF中也有该UE的安全上下文则初始AMF中的安全上下文会替代old AMF中的安全上下文。这个场景貌似不会发生呢
