【威尼斯人】5G注册流程分级详解Step1-3

wuyou125

前段时间学习5G积攒了一些学习笔记，整理一下发出来，也算蹭个热点，撞撞风口，走走流量。原计划分为四级整理笔记，适应从肉食者到搬砖者不同的人群分级学习，尽量节省阅读和学习时间：

• 尊享篇
  

  5G普及篇。本篇中，尽量不出现专业词汇，比如：UDM/UDR——均用存放用户数据那玩意儿；AUSF——审批你是不是公司内部员工那台设备；AMF——你想做什么，先联系我，我帮你对缝儿的那家伙儿；SMF……写到一半感觉我写不下去了。可能即使写出来，连搞5G的专业人士也不知所云，后来尊享篇就中途趴窝，下马了。

• 专享篇
  

  5G大概篇，适于不需要太深入了解的人群。本篇中，专业词汇、专有名词的英文缩写都会出现，但仅介绍基本知识。速看一遍，走马观花，管中窥豹也能窥个差不多。

• 优享篇
  

  适用于威尼斯人官方网站专业的技术同仁。本篇对技术细节、关键知识点进行梳理，详细介绍，以期读完之后既知其一，又知其二，又能知其它。什么时候忘了，回来一查，还有《新华字典》的效果，那就更给力了。

• 畅享篇
  

  适用于狂热于技术，对技术有剥皮剔骨专执信念的人群，计划对消息比特0-1的设置、二进制的分析、ASN.1、TLV等知识详细说明，能折腾到这种程度，对于一个维护人员来讲，已经无异于自掘坟墓，驾鹤西去，神游太虚了，于是美其名曰“畅享”篇。不过，我实在不想过早仙游，所以本篇只能任凭发挥，随意“畅想”了。

  经过衡量，最后只剩下了专享篇和优享篇两级。具体内容均根据3GPP R16（2020年12月）版本做了更新，也有可能个别地方更新不及时或者干脆理解错了，只能随时发现随时更新了。涉及到的流程图、消息定义等直接采用3GPP文档原图，不做任何更改，以方便有阅读疑问时，根据本篇回查对应的3GPP，不至于张冠李戴，郢书燕说。先进行第一篇5G注册流程介绍。

注：

（1）3GPP流程图中的虚线表示该步骤可选；

（2）消息参数用方括号括住的为可选字段。

5G注册流程图

一、专享篇

1. UE发送Registration Request到(R)AN，消息中包含注册类型、用户标识、UE能力及请求的切片等参数。

2. (R)AN接收到消息，根据用户临时标识或切片选择合适的AMF，如果(R)AN找不到合适的AMF，则将RegistrationRequest发送给缺省AMF，由缺省AMF进行AMF重新选择流程。

3. (R)AN将Registration Request消息转发给AMF。

4. 如果Registration Request中携带的是5G-GUTI，AMF发现不是自己分配的，则会向调用Old AMF请求用户的上下文。

5. Old AMF响应New AMF，返回用户上下文信息。

6. 如果UE没有提供SUPI，也没有从Old AMF处获取到SUPI，AMF向UE发送Identity Request消息请求获取SUPI。

7. UE向AMF返回IdentityResponse消息，消息中包含SUPI。

8. AMF根据SUPI或者SUCI选择一个AUSF，进行用户鉴权。

9. AUSF执行对UE的鉴权过程。

10.用户新注册AMF发生改变，则New AMF发送Namf_Communication_RegistrationStatusUpdate消息给Old AMF。

11．AMF向UE发送Identity Request消息，请求获取PEI。UE向AMF返回IdentityResponse消息。

12．AMF向EIR发起PEI检查过程，EIR向AMF返回检查结果响应。

13. 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。

16．New AMF和PCF进行接入策略交互。

17．如果AMF改变或UE的PDU Session Status与AMF保存的不一致，AMF更新SMF中会话上下文。

18、19. 国内部署不涉及。

21．New AMF向UE发送Registration Accept消息，接受UE发起的注册请求。如果New AMF为UE分配了新的5G-GUTI，一起下发。

21b. 如果UE请求了UE策略，则AMF需要和PCF执行UE策略交互。

21．如果AMF为UE分配了新的5G-GUTI，则UE向New AMF发送Registration Complete消息。

二、优享篇

1. UE发送Registration Request到(R)AN

该步骤涉及UE和gNB之间Uu接口信令交互。gNB在UE和AMF之间充当NAS信令网关的作用，NAS信令在gNB中透明转发，gNB不需要理解NAS信令的内容。Uu接口的信令协议栈（从上往下）：RRC/PDCP/RLC/MAC/PHY。

• RRC层介绍
  

   UE在发送Registration Request消息之前需要和gNB先建立RRC连接。UE和gNB之间在发送Registration Request消息过程中共涉及到三条RRC信令交互。具体流程如下：

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）。

         -EstablishmentCause字段

   该字段的取值为mo-SMS、mo-Signalling等值，可用的取值详见上图。

2）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。在RRCSetup中只允许对SRB1进行配置。

3）RRCSetupComplete

  该消息用于UE确认已经成功完成RRC连接的建立，其承载在SRB1上。UE收到RRCSetup消息后根据其中的radioBearerConfig进行无线承载配置。

其中：

    -  ng-5G-S-TMSI-Part2

设置为5G-S-TMSI 最左面9bit。如果gNB在RRCSetupComplete消息中的ng-5G-S-TMSI-Value字段得到的不是完整的NG-5G-S-TMSI，则利用RRCSetupRequest消息中提供右侧39bit和RRCSetupComplete消息中提供最左面9bit，合并成一个完整的NG-5G-S-TMSI。

    -  guami-Type

    用于指示GUAMI是从原生5G-GUTI导出的（native取值），还是从EPS GUTI导出的（mapped取值）。

    -  registeredAMF

    UE注册的GUAMI信息。

    UE的NAS层提供给RRC层5G-S-TMSI或者GUAMI的规则如下：

• 如果UE使用了SUCI标识进行注册，则不应该再包含任何GUAMI信息；
  

• 如果是CONFIGURATION     UPDATE COMMAND消息要求的注册流程，则不应该提供5G-S-TMSI或者GUAMI；
• 如果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既没有5G-GUTI也没有4G-GUTI，则都不提供。
  

-   selectedPLMN-Identity

该值包含的并不是完整的PLMN ID信息，而是SIB1广播的PLMN ID列表的索引。

-   DedicatedNAS-Message

该消息中的DedicatedNAS-Message只用于传输initial NAS message。在3GPP中，初始NAS消息共定义了4种，分别是：RegistrationRequest、Deregistration Request、Service Request及Control Plane Service Request。注册流程中的第一条Registration Request消息就包含在该字段中发送给gNB。

   注：在RRC规范的定义中，还有一条ULInformationTransfer消息用户上行NAS信令的传输，该消息需要在SRB2建立之后，用于上行NAS消息传递。ULInformationTransfer消息在SRB2没有建立的时候也可以承载在SRB1上。

   从网上搜到的UE侧的信令截图可以看出Registration Request并没有使用ULInformationTransfer进行传述：

（该图片来源https://blog.csdn.net/weixin_33218985/article/details/112141324）

-  s-NSSAI-List

如果UE的NAS层提供提供了一个或者多个S-NSSAI，则设置该值。该值的设置与Access StratumConnection Establishment NSSAI Inclusion Mode参数相关，而该参数包含在REGISTRATION ACCEPT消息中。

如果新买的手机，UE中没有保存Access Stratum ConnectionEstablishment NSSAI Inclusion Mode参数时，UE可以不提供S-NSSAI。

如果UE中保存有AccessStratum Connection Establishment NSSAI Inclusion Mode参数，UE可以提供requested NSSAI或者allowed NSSAI。具体提供的是requested NSSAI还是allowed NSSAI，与Access Stratum ConnectionEstablishment NSSAI Inclusion Mode参数采用的是哪个模式相关。这里仅以中国移动的路由组织规范推荐的mode B说明。

Mode B定义的两个场景：（1）由业务请求（Service Request）引起的连接建立，允许UE包含触发连接家里的各个S-NSSAI；（2）在周期性注册更新（PeriodicRegistration Update）、更新UE能力的注册流程的连接建立，允许UE包含Allowed NSSAI。

UE的NAS层提供给RRC层NSSAI的准则相对比较容易理解，如果UE有Allowed NSSAI，则优先提供Allowed NSSAI。如果UE的AllowedNSSAI在后续流程中可能引起改变时，则提供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。
• NAS层介绍
  

NAS层包含RegistrationRequest消息。3GPP R16中共定义了29个IE，这里仅介绍重点的IE。

-5GS Registration type

5G中，共有四种注册类型：

1）  初始注册（Initial Registration）

UE开机时，处于RM-DEREGISTERED状态发起的注册流程。2）  移动性注册（Mobility Registration Update）发起移动性注册的场景：（1）进入到不在TA List的新TA（2）更新UE能力及协议参数（和TA是否改变无关）；（3）请求改变NSSAI信息；（4）（R16新增）UE的PreferredNetwork Behaviour改变，和AMF当前支持的SupportedNetwork Behaviour参数不兼容。（5） 请求改变允许使用的NSSAI。3）  周期性注册（Periodic Registration Update）T3512超时发起的注册流程。4）  紧急注册（Emergency Registration）紧急注册国内未开启。在该IE中还有一个重要的指示，UE如果不包含需要激活的PDU Session或者UE要进行紧急注册，但UE还有上行信令需要发送时包含该参数，需要在该5GS Registration typeIE中设置"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网络分配的native5G-GUTI；4）  其它PLMN分配的5G-GUTI；5）  其它情况，UE提供SUCI进行注册。如果UE既有有效的EPSGUTI又有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）  DefaultConfigurated NSSAI：UE既没有Configured NSSAI，又没有Allowed NSSAI时使用。Default Configurated NSSAI作为用户的签约数据，保存到UDR中，只有一个。2）  Configured NSSAI或者下述3）、4）情况的子集3）  Allowed NSSAI或者它的子集4）  Allowed NSSAI或者它的子集，加上一个或者多个不包含在Allowed NSSAI中的Configured NSSAI。在确定下来这些计划注册的NSSAI后，UE还需要根据URSP中的NSSP和本地配置来最终确定Requested NSSAI。

-[Network slicing indication]

如果UE使用DefaultConfigurated NSSAI进行注册，则需要包含该字段，在其中指示“Requested NSSAIcreated from default configured NSSAI”。

-[5GMM capability]

该IE中常用的能力信息有：1）  UE是否支持EPC NAS即UE是否支持在EPC网络功能（S1 mode supported）；2）  NG-RAN到UTRAN的5G-SRVCC能力信息；R16版本的3GPP已经对从5G到2G的SRVCC功能进行了明确。如果UE支持该功能，则指示 "5G-SRVCC from NG-RAN to UTRAN supported"，并且还需包含Mobile station classmark 2 IE和Supportedcodecs IE。3）  Radio capability signalling optimisation (RACS)能力支持信息该功能的使用，需要在网络中增加部署UCMF网元实例；4）  网络切片的认证和授权（NetworkSlice-Specific Authentication and Authorization）能力信息。

-[5GS update type]

该IE中常用的能力信息有：1）  UE的SMS over NAS支持情况；2）  UE radio capability更新指示UE Radio Capability包含包含RAT相关的信息，如UE支持的powerclass, frequency bands等。AMF保存该参数内容，如果该参数可用，AMF会通过N2消息发送给RAN保存。如果UE的状态变为RM-DEREGISTERED，则需要删除该参数。如果发送给RAN的N2请求不包含该参数，RAN自身也没有该参数信息，则会触发RAN向UE索取该参数信息并通过N2UE 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-15，0保留不用。该IE适用于移动性注册或者周期性注册。

-[Uplink data status]

该IE适用于移动性注册或周期性注册流程。如果有需要发送的上行数据，需要包含该字段。如果UE有always-on PDU Session，即使没有数据发送，也需要包含在该参数中。但是建立为always-on PDU Session是在5G SM流程中，PDU SESSION ESTABLISHMENT REQUEST消息中包含Always-onPDU session requested IE

-[Payload container]、[Payload container type]

如果UE有保存的UEpolicy sections（UE策略可以使用一个或者多个UEpolicy section），UE需要设置Payloadcontainer type IE为"UE policy container" ，并在Payload container IE中包含UE STATE INDICATION消息。网络收到该消息后，会执行UE Configuration Update流程下发新的UE策略。

-[NAS message container]

该字段存在的先决条件如下，这三条需要同时满足才能包含该字段：1）  RegistrationRequest作为初始NAS消息；2）  UE存在有效的5G NAS安全上下文；3）  UE有需要密文发送的内容。在没有NAS安全上下文的情况下，UE可以明文发送的内容有：1）  Extended protocol discriminator;2）  Securityheader type;3）  Spare half octet;4）  Registrationrequest message identity;5）  5GS registration type;6）  ngKSI;7）  5GSmobile identity;8）  UE security capability;9）  AdditionalGUTI;10） UE status11）  EPS NAS message container.

注：

Registration Request本身就是一条NAS层的消息，但在该条消息中又包含一个[NAS message container] IE，规范对该IE的解释为：The purpose of the NAS message container IE is to encapsulate aplain 5GS NAS REGISTRATION REQUEST or SERVICE REQUEST message, or toencapsulate non-cleartext IEs of a CONTROL PLANE SERVICE REQUEST message. 不知道这个NAS message container和UE构建的Registration Request消息有什么区别？从其它介绍来看应该是不允许明文发送的部分内容，打包在了[NAS message container] IE中。

TS 24.501中定义：ThisIE includes a complete plain 5GS NAS message as specified insubclauses 8.2 and 8.3. The SECURITY PROTECTED 5GS NAS MESSAGE message(see subclause 8.2.28) is not plain 5GS NAS messages and shall not beincluded in this IE.

经过查看现网实际的信令内容[NAS message container]中既包含可以明文传递的部分，又包含不允许明文传递的部分，即[NAS message container]中包含完整的注册消息的全部字段。而RegistrationRequest这条NAS消息中，只包含可以明文传递的部分，部分内容是重复的。

2.AMF选择

gNB收到RRCSetupComplete消息，根据RRC层包含5G-S-TMSI或GUAMI来对NAS消息进行路由。AMF选择的具体的规则如下：

1） 如果UE既没有提供GUAMI或5G-S-TMSI，又没有提供NSSAI信息（如：UE使用SUCI进行注册），则gNB根据RAT类型将RegistrationRequest消息路由到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路由到defaultAMF。

注：

3GPP TS 23.501和中国移动的5G路由组织规范，在AMF选择部分都使用了Requested NSSAI作为AMF选择的参数。从上面介绍的RRC信令交互的部分和Uu接口协议栈可以知道，在这里使用Requested NSSAI的概念，个人感觉并不准确。因为RequestedNSSAI是NAS消息层的概念，gNB并不理解NAS消息的内容，根本无法使用NAS消息中包含的内容。gNB能够利用的只有UE的NAS层传递给RRC层的NSSAI信息，而RRC层的NSSAI信息可以是Requested NSSAI也可以是Allowed NSSAI。

3.gNB将Registration Request消息通过N2接口发送给AMF

gNB选择完AMF后，向AMF发送INITIAL UE MESSAGE（初始N2消息）。为该UE分配一个唯一的RANUE NGAP ID，也包含在INITIAL UE MESSAGE消息中。从选择的AMF可用的TNL associations中，选择一个可以用于发送初始消息的TNL associations（TNL Association的权重因子为0的，不用用于初始N2消息的发送），为该UE创建NGAP UE-TNLA-binding，并通过选定的TNL association转发该UE的消息到AMF。

TNL Association应该就是SCTP的Association，第一个TNLAssociation在gNB上电后，根据配置的IP地址和端口号与AMF建立Association，后续如果需要增加TNL Association时，AMF需要给5G-AN发送AMF CONFIGURATION UPDATE消息，该消息中包含增加TNL Association的IP地址和端口号。TNL Association最多可以创建32个。

INITIAL UE MESSAGE只用于发送上行的第一条NAS消息。后续的NAS消息使用UPLINKNAS 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消息的DOWNLINKNAS TRANSPORT不存在这样的问题，因为gNB发送完第一条INITIAL UE MESSAGE消息后已经将本侧的RAN UE NGAP ID带给了AMF。

注：

       在INITIAL UE MESSAGE消息中，还包含AllowedNSSAI IE，规范的解释：If the Allowed NSSAIIE is included in the INITIAL UE MESSAGE message the AMF shall use the IE asdefined in TS 23.502 [10]. 但是在TS 23.502中并没有看到该IE的使用场景。在此处包含AllowedNSSAI感觉很奇怪。该IE不可能是UE发送给gNB的，因为3GPP定义的四种初始NAS消息中都没有发现Allowed NSSAI IE。Allowed NSSAI是在Registration Accept消息中下发给UE的，正常gNB并不会得到NAS层UE的Allowed NSSAI。即使是gNB在哪条消息中获得了UE的Allowed NSSAI，似乎在INITIAL UE MESSAGE消息中发送给AMF，并没有什么作用，感觉真是很奇怪。如果哪位同仁知道该IE的作用，多多指教。

补充：

       经过仔细查找，发现在注册过程中如果AMF出现重选的场景下，如果需要RAN转发初始注册请求可能会在INITIAL UE MESSAGE中出现Allowed NSSAI。初始AMF和UDM、NSSF已经交互完成得到了切片相关的信息，此时如果初始AMF不能为UE服务，而目标AMF和初始AMF不在同一个AMF Set，此时可能就需要RAN转发注册请求。AMF发送Reroute NAS Request消息给gNB，gNB发现在该消息中存在Allowed NSSAI时，会在发送给目标AMF的InitialUE Message消息中包含Allowed NSSAI IE和Sourceto Target AMF Information Reroute IE。

后续流程，留待下回分解  ......

发帖需要单独上传图片编辑，很花时间，相关分析在公众号上，也会同步更新，各位同仁如果想继续了解可以关注一下：5G威尼斯人官方网站大家学

参考资料：

TS 23.501

TS 23.502

TS 38.331

TS 38.413

wuyou125

威尼斯人官方网站技术你问我答 (积分兑奖)

***   网页编辑器不能直接粘贴图片，平时工作比较忙，逐个图片上传比较耗精力，大家可以下载附件查看。或者关注公众号：5G威尼斯人官方网站大家学    ***

4.  AMF调用old AMF的Namf_Communication_UEContextTransfer服务获取UE上下文。

如果UE的Registration Request消息携带5G-GUTI进行注册，并且AMF发生了变化，此时新的AMF（newAMF）会向UE原来注册的AMF（old AMF）请求UE上下文信息，包含SUPI、GPSI、5GMM Capability等参数（UE上下文的内容详见TS 23.502）。

new AMF采用POST方法调用old AMF的Namf_Communication_UEContextTransfer服务。具体使用的URI格式为：

{apiRoot}/namf-comm/<apiVersion>/ue-contexts/{ueContextId}/transfer

调用该服务携带的请求消息内容为：UeContextTransferReqData。

注：

（1）通用的URI结构为：

{apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>

（2）对于SBI接口采用POST方法还是PUT方法的区别

服务的生产者选择资源的标识符和URI，则采用POST方法；服务的消费者选择资源的标识符和URI，则采用PUT方法。

l URI请求的命令行参数

-         {apiRoot}

该字段和我们日常上网，在IE地址栏中输入的内容一样，以http或者https开头的地址，后面是IP地址和端口号等信息；

-         namf-comm

AMF上用于信息传递的API名称。其它API名字为："namf-mt"、"namf-loc"、"namf-evts"

-         <apiVersion>

目前在R16版本中全部为“v1”，后续如果有大的功能变更，可能会有更新的版本。

-         ue-contexts

请求UE Context的固定值。

-         {ueContextId}

请求的UE Context的标识，可以为5G-GUTI、SUPI或者PEI，使用的格式如下：

（1）5G-GUTI：5g-guti-[0-9]{5,6}[0-9a-fA-F]{14}

（2）SUPI：(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。

l  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]

特性支持相关的字符串。

l  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根据newAMF的PLMN ID判断，不能将N2接口重定位到new AMF，则只返回supi；

B． 如果注册类型"MOBI_REG"并且old AMF执行完整性检查成功，返回200 OK消息，包含完整的UE Context（含有PDU Session信息）。

（2）  如果第一次old AMF完整性检查失败（返回给new AMF的响应为：403 Forbidden，携带原因值：“INTEGRITY_CHECK_FAIL”），UE和AUSF鉴权成功后，再次向oldAMF请求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相关的信息）。

5.  old AMF向new AMF回复Namf_Communication_UEContextTransferResponse消息

l  成功响应

如果old AMF处理成功，在Namf_Communication_UEContextTransferResponse

消息中返回200 OK 响应，并携带UE Context。响应的消息内容如下UeContextTransferRspData：

l  响应失败

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重新获取了，即在注册流程中的第4，5，10步骤都不需要执行。

l  如果old AMF有不同于当前accessType的PDU Session，AMF判断该PDUSession无法重定位到新的AMF，则AMF只返回SUPI，并指示消息已经经过完整性验证，不包含UE Context的其他部分（SUPI包含在UeContext数据类型中）。

l  跨PLMN移动的时候，UEContext中的信息包含的是HPLMN S-NSSAI的信息（可以对应到Allowed NSSAI的S-NSSAI），而不是old PLMN的Allowed S-NSSAI。

l  UE注册到新的AMF后，不需要重新订阅事件，因为UEContext中包含事件订阅的信息。如下：

6.  Identity Request消息向UE获取SUCI

如果在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 AMFthe Identity Request procedure is initiated by AMF sending an Identity Requestmessage 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.2：TheSEAF shall include the SUPI in the Nausf_UEAuthentication_Authenticate Request messagein case the SEAF has a valid 5G-GUTI and re-authenticates the UE. Otherwise theSUCI is included in Nausf_UEAuthentication_Authenticate Request. 可以知道，主鉴权流程使用的参数要么是SUCI，要么是SUPI。个人判断，TS23.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 TRANSPORT（N2接口消息）消息中发送给gNB，之后gNB将NAS消息承载在RRC层的DLInformationTransfer消息中发送给UE。

DLInformationTransfer消息承载在SRB2（在SRB2未建立时也可以使用SRB1）中（逻辑信道DCCH）。

7.  UE向AMF发送Identity Response消息

该NAS消息中的重点字段为：Mobileidentity。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 Transport（N2接口消息）消息中发送给AMF。

RRC层消息DLInformationTransfer和ULInformationTransfer用于在UE处于RRC-CONNECTED状态时传递NAS消息。

8.  AUSF选择

在AMF从UE得到SUCI或者old AMF得到SUPI后，选择AUSF执行鉴权流程。

后续流程，留待下回分解  ......

ghr123

下载学习

wuyou125

9. Authentication/Security流程。
0）准备知识
该步骤为UE的5G的鉴权流程，本文以目前使用的5G AKA鉴权方式为例介绍。5G AKA相比4G增加了归属网络的鉴权功能。4G的鉴权由MME完成，而5G的鉴权由AMF和AUSF共同完成，且5G的鉴权向量不支持预取，也不支持一次获取多组鉴权向量。
归属网络的AUSF提供鉴权过程的锚点密钥（anchor key）KSEAF，它是由加密保存在AUSF中的中间密钥Kausf计算得到的。5G中，锚点密钥和和服务网络（Serving Network）进行绑定，向UE提供隐式的服务网络认证。绑定的方式是将5G SN名称作为密钥推导的输入参数。
（1）5G SNN（Serving 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和小区广播的PLMN信息可以很容易推导出SNN，进而用于安全密钥的推导；而AMF侧根据配置信息也可以构造出SNN，用于鉴权和认证。
（2）鉴权流程的触发条件
通常，与UE建立信令连接的流程都可以触发鉴权流程。我们常见到的能够触发鉴权流程的场景为：
•        UE使用SUCI发起注册流程；
•        AMF没有UE的有效上下文；
•        Registration Request消息没有被完整性保护；
•        UE携带5G-GUTI注册，但是old AMF对注册请求消息执行完整性检查失败；
1） 鉴权流程
本部分的鉴权流程分成三个部分：
A． 鉴权流程（请求阶段）
B． 鉴权流程（响应阶段）
C． 鉴权流程（鉴权确认和注册绑定部分）
A. 鉴权流程（请求阶段）：

（1）消息方向：AMF/SEAF -> AUSF
HTTP方法：POST
消息名称：Nausf_UEAuthentication_Authenticate Request
在整体注册流程的第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）消息方向：AUSF -> UDM
HTTP方法：POST
消息名称：Nudm_UEAuthentication_Get Request
该请求的资源URI为：
{apiRoot}/nudm-ueau/v1/{supiOrSuci}/security-information/ generate-auth-data
该消息用于AUSF请求UDM为UE选择一种鉴权方法，并计算新的鉴权向量（如果该鉴权需要鉴权向量的话）。如果请求中包含的是SUCI，UDM收到该请求后，首先，SIDF将SUCI解密为SUPI，之后根据SUPI为UE选择鉴权方式。目前，5G使用的鉴权方式有两种：EAP-AKA’ 和5G AKA。
请求消息AuthenticationInfoRequest的内容如下图：

- ResynchronizationInfo
  该字段包含两项内容：rand和auts。在鉴权重同步过程中，AUTS由UE计算得到。
B. 鉴权流程（响应阶段）：

（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.102，6.4.3章节及附录F）。对于鉴权向量来讲，如果设置为1，AKS鉴权过程中产生的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）消息方向：UDM -> AUSF
消息名称：Nudm_UEAuthentication_Get Response
•        成功响应
返回200 OK响应。UDM计算出5G HE AV（RAND、AUTN、XRES*、KAUSF），并在响应消息中返回给AUSF。携带AuthenticationInfoResult内容。
该响应消息包含AuthenticationInfoResult，具体内容如下：

- supi
如果请求消息中是SUCI，UDM会使用SIDF解密出SUPI并在该字段中返回给AUSF。
- authType
AUSF根据该字段为UE开启"5G_AKA"鉴权流程或者"EAP_AKA_PRIME"鉴权流程。
选择的鉴权类型共有三个取值："EAP_AKA_PRIME"、"5G_AKA"和"EAP_TLS"，其中，"EAP_TLS"标准并不强制要求支持。
- AuthenticationVector
鉴权向量包含的内容如下：

其中：
- avType
取值两种："5G_HE_AKA"和"EAP_AKA_PRIME"。
- rand
共128比特，16字节。
- autn
共128比特，16字节。AUTN的构成(SQN xor AK)||AMF||MAC，共48+16+64 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 AV（RAND、AUTN、XRES*、KAUSF）来计算5G AV（RAND、AUTN、HXRES*、KSEAF）；根据XRES*计算出HXRES*；根据KAUSF计算出KSEAF（计算KSEAF仍然需要serving network name作为输入参数）。锚点密钥Kseaf此时诞生。
（5）消息方向：AUSF -> AMF/SEAF
消息名称：Nausf_UEAuthentication_Authenticate Response
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 ... 5g-aka-confirmation。如果是EAP鉴权，该字段的值为："eap-session"及执行EAP Session的URI。
- 5gAuthData
包含上一步骤的5G SE AV (RAND, AUTN, HXRES*)。
（6）消息方向：AMF/SEAF -> UE
消息名称：Authentication Request（NAS消息）
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-6（3bit）（7保留）。如果UE发送给网络的ngKSI=7，表示没有密钥可用。ngKSI用于在UE和AMF中识别Kamf。在后续鉴权成功后，用于识别5G安全上下文。如果在初始NAS消息（Registration Request消息）中包含了ngKSI，AMF需要在Authentication Request中分配一个不同的ngKSI。
- ABBA
ABBA参数为保持前向兼容，其长度可变，在R16版本中，长度为2个字节，值规定为：0x0000，用于推导Kamf作为输入参数。该参数用于防止降维攻击。
- Authentication parameter RAND/ Authentication parameter AUTN
均为从AUSF收到的数据。
- EAP message
对于5G AKA鉴权，不包含该IE。
（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）消息方向： UE -> AMF/SEAF
消息名称：Authentication Response（NAS消息）
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）消息方向： AMF/SEAF -> AUSF
HTTP方法：PUT（注意：EAP鉴权方式时本步骤为POST方法）
消息名称：Nausf_UEAuthentication_Authenticate Request
该请求消息调用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鉴权结果，之后开启鉴权确认和注册绑定流程。
（12）消息方向： AUSF -> AMF/SEAF
消息名称：Nausf_UEAuthentication_Authenticate Response
如果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。
C. 鉴权流程（鉴权确认和注册绑定部分）

该步骤主要用于防止AMF的虚假注册，如UE所处拜访网络没有的AMF，确发起了Nudm_UECM_Registration_Request，导致UE注册在了一个不存在的AMF上。
（1）消息方向：AUSF -> UDM
HTTP方法：POST
消息名称：Nudm_UEAuthentication_ResultConfirmation Request
该请求消息的资源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）消息方向：UDM -> AUSF
消息名称：Nudm_UEAuthentication_ResultConfirmation Response
•        成功响应
返回201 Created，消息体可以为空。如果不为空，则返回AuthEvent内容。HTTP消息头的Location字段包含创建的资源，URI如下：
{apiRoot}/nudm-ueau/v1/{supi}/auth-events/{authEventId}
•        失败响应
404 Not Found，原因值：USER_NOT_FOUND。
（3）UDM对后续流程的鉴权
如果UDM收到了UE的后续流程，如：AMF发送的Nudm_UECM_Registration_Request消息，UDM会根据运营商策略执行相关检测和保护操作（详见TS 33.501，3GPP仅提供了建议操作）。
2）5G密钥相关推导图
（1）5GS密钥推导图（TS 33.501）

（2）5GS密钥分布及生成模式图（TS 33.501）

（3）UDM鉴权向量推导图（TS 33.102）

（4）UE鉴权推导图（TS 33.102）


后续流程，留待下回分解  ......

qazokm321

学习学习~

zny165

学习了

xiyouli2006

学习了 太牛了

c_kelly

感谢LZ分享。

wuyou125

9. 鉴权流程（续）
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推导出Kamf（Kamf保存在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）NAS消息完整性保护要点说明
我们先来看一下5G在NAS消息的完整性保护相关的要点：
        如果UE本地没有5G NAS security context的情况，UE执行注册流程时，发送的Registration Request消息可以不进行加密和完整性保护。只要UE本地存在有效的5G NAS security context，3GPP规范强制要求UE对NAS消息进行完整性保护。
        当发送的NAS消息既需要加密又需要执行完整性保护时，NAS消息首先进行加密，之后加密后的NAS消息和NAS序列号一起进行完整性保护，计算MAC；
        NAS消息可以只进行完整性保护而不加密。未加密的NAS消息和NAS序列号一起进行完整性保护，计算MAC；
        当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消息交互。
        如果选择5G-IA0（空算法，即："null integrity protection algorithm"，相当于没有进行完整性保护）作为完整性保护的算法，在NAS消息的安全头（Security header type）指示为完整性保护消息，则NAS消息的接收方仍然认为该消息是完整性保护的消息。如果NAS消息使用5G-EA0（即："null ciphering algorithm" ）算法加密，在NAS消息的安全头部指示为加密保护消息，则仍然认为NAS消息是加密的。
（2）NAS消息的加密要点说明
下面再看一下UE发送Registration Request消息时，是否有5G NAS security context在消息加密方面的要点。在3GPP文档中，该部分内容有两个名词：cleartext和non-cleartext，经过前后对比，cleartext理解为“允许明码发送”，non-cleartext理解为“需要加密发送”比较合适。
        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内容。
        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 REQUEST，SERVICE REQUEST，CONTROL 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消息。
（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本地和之前注册的AMF（old 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消息。
Step4：UE发送NAS Security Mode Complete消息给AMF，该消息是加密并完整性保护的消息。
Step 5：AMF发送初始NAS消息的回复，该消息是加密及完整性保护的。
（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 IE，AMF会原封带回。如果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
降级攻击保护参数。
注：
百度百科上的降级保护内容，供参阅：降级攻击（Downgrade attack）是一种对计算机系统或通讯协议的攻击。在降级攻击中，攻击者故意使系统放弃新式、安全性高的工作方式（如加密连接），反而使用为向下兼容而准备的老式、安全性差的工作方式（如明文通讯）。例如，在OpenSSL中曾经存在一个缺陷，从而使攻击者能够让SSL/TLS服务器与客户端创建老版本TLS连接，尽管双方事实上支持新版本。这样的攻击是最常见的降级攻击。
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。如果重新推导了Kamf，AMF会设置NAS COUNT为0。

如果UE验证NAS Security Mode Command消息不成功，会回复Security Mode Reject 消息。Security Mode Reject消息及后续的NAS消息仍然会使用之前的5G NAS security context进行加密和完整性保护。如果之前不存在5G NAS security context，NAS 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注册过程的鉴权和安全性保护方面到这就介绍完了。在切换过程中也会涉及到安全方面的内容，在详解切换流程时在进行分析。
我在写详解流程的过程中，也在逐渐的深入。之前学习的时候觉得已经学明白了，但是在整理成该文档的时候，仍然会发现很多疑问。如有疑问和错误，请大家随时回复，共同学习5G。

后续流程，留待下回分解  ......

整理文档需要查询大量3GPP文档，整理不易，敬请关注。

wuyou125

***   相关更新会在公众号同步更新，敬请关注。公众号：5G威尼斯人官方网站大家学    ***
我持续更新的相关5G内容都是直接根据3GPP整理，避免通过二手，甚至多手的资料，错误的地方以讹传讹误导网友，保证更新内容的准确性，后续网友遇到问题时可以斩钉截铁的校准，消除疑虑。
在介绍完主要流程的详解后，会计划整理专题相关的内容，比如切片、服务发现等主题内容，让网友不仅纵向学习到知识，横向也会将知识关联起来，以达到深入理解的目的。
------
10. 消息名称：Namf_Communication_RegistrationStatusUpdate
消息方向：new AMF -> old AMF
HTTP方法：POST
该消息用于正在进行UE注册的new AMF向old AMF更新相应的注册状态,及通知需要释放的PDU Session等信息。
如果第9步UE鉴权失败，new AMF需要使用该消息通知old AMF：UE在new AMF注册失败，old AMF需要继续保存该UE的上下文信息。
对于移动性注册流程，如果UE在old AMF的RA（注册区）中可以使用的S-NSSAI，在new AMF的RA中无法支持，则new AMF需要确定该S-NSSAI关联有哪些PDU Session需要释放，之后使用该消息将拒绝的PDU Session ID信息通知old AMF，old 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 AMF：new AMF重新选择了新PCF，old 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注册没有成功，需要重新选择新的AMF，old 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的值为"TRANSFERRED"，old 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 IE，old AMF会删除I-SMF 或者V-SMF中smfChangeInfoList指示的所有PDU Session的SM Context（会话上下文）信息。
如果RegistrationStatusUpdate消息的transferStatus值为"NOT_TRANSFERRED"，old 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版本中，已经全部改正了这些矛盾。目前在网上及个别厂家文档、培训教材中，该消息名称还没有改正，大家阅读到该步骤时需要注意。
11. 消息名称：Identity Request/Response
消息方向：new AMF -> UE
该消息和注册流程的第6步相同，不同点是第6步获取UE的SUCI，本步骤获取UE的PEI。另外需要注意的一点是第6步中的消息可能是未执行加密和完整性保护的，而本步骤的请求消息和回复消息都应该是加密和完整性保护的消息。
该步骤执行的前提是UE在注册消息（紧急注册场景是会提供UE的PEI）及old AMF的UE Context中没有得到UE的PEI，此时需要执行该步骤获取UE的PEI。需要注意的是Identity Request消息中的Identity Type IE，应该设置为011或者101，表示获取UE的IMEI/IMEISV，详见下图：

注：
在Registration Request消息中不直接包含PEI字段，也就是说在注册流程中，除了紧急注册，AMF都不会从注册消息中直接获得PEI。只要从old AMF没有得到PEI，都需要执行该步骤。
初始注册流程中，AMF执行该步骤获取UE的PEI，在后续流程中，AMF会将其其发送给UDM（Nudm_UECM_Registration）、SMF和PCF。
如果UE在注册消息的5GMM capability IE中指示UE支持RACS功能，AMF会使用PEI获取IMEI/TAC，用于网络执行RACS操作。
12. 消息名称：N5g-eir_EquipmentIdentityCheck_Get
消息方向：AMF -> EIR
HTTP方法：POST
该步骤国内未使用，不进行介绍。
13. UDM选择
在该步骤中，AMF会使用SUPI通过NRF选择UDM。
需要注意的是在第8步中，AMF选择AUSF时可以使用SUCI和SUPI。在本步骤中，不管何种情况，AMF和AUSF已经完成了UE的鉴权流程，AMF一定会获取到UE的SUPI，所以在UDM的选择中，只有一个输入参数就是SUPI。

后续流程，留待下回分解  ......

maolingzx

wuyou125 发表于 2021-3-16 23:33
***   相关更新会在公众号同步更新，敬请关注。公众号：5G威尼斯人官方网站大家学    ***
我持续更新的相关5G内容都是直 ...

找不到这个公众号啊

wuyou125

maolingzx 发表于 2021-04-04 22:20:27 找不到这个公众号啊

微信里搜一下: 5G威尼斯人官方网站大家学，就能找到。再不然就搜一下: laozhouhulielie

wuyou125

注册流程陆续已经更新差不多了，下面上传一份pdf文档，查看方便。


核心网信令分析手册v1-注册.part2.rar (6.26 MB, 下载次数: 40)

2021-4-8 13:04 上传

下载次数: 40

核心网信令分析手册v1-注册.part1.rar (9 MB, 下载次数: 36)

2021-4-8 13:04 上传

下载次数: 36

的数据分类

下载学习

877352462

太感谢楼主总结啦，哭了

sto2543

学习学习

skywang3210

需要学习5G知识

昌维cw

请问这些流程的原始出处在哪可以看到啊？是3GPP的文档吗？

yeshu1996

刚入职的威尼斯人官方网站小白，感谢大佬分享！

ceozhang

wuyou125 发表于 2021-4-7 12:29
注册流程陆续已经更新差不多了，下面上传一份pdf文档，查看方便。

谢谢！