【原创连载】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