0
0

5G UE附着过程 学习心得

UE附着过程

前言

NAS(非接入层)想要进行操作/交互，必须通过AS(接入层)做载体才能进行。即UE想进行附着，要先进行RRC连接；UE想要去附着，也要先进行RRC连接。

attach(附着)是NAS协议过程，而RRC连接/释放是AS层的RRC协议。

相关协议

  • 24.301 NAS协议

  • 36.331 RRC协议

流程框图

Q:这个流程图，相对另一种常见的，少了一对信令的交互，少的是哪对信令？什么情况下会少？

少了UE能力获取的信令交互——UECapabilityEnquiry和UECapabilityInformation。根据目前新版协议要求，UE能力在安全建立之后才能发送UE能力，gNB会根据接收到的UE能力，发送RRC重配信息。

UE能力获取的信令涉及到RRC重配，故不能缺少

当核心网下发消息时携带了之前保存的该UE的能力信息，且能够保证本次附着过程的最小集需求时，gNB不会在此过程中询问UE能力。但在附着完成后，gNB还会根据需要发送询问UE能力的信令。

(下图为修正后的流程图)

1. RRC连接 RRC connection establishment

  • 该过程是RRC连接过程

  • 该过程包含SRB1的建立

  • 该过程在处于RRC_IDLE的UE获取了有效的基本系统信息(MIB,SIB1)后启动

Q:发起RRC建立，这些广播都需要读取到吗？需要的最小集合是什么？

不需要全部读到。初始接入流程只需要读到MIB和SIB1即可

MIB的前4个参数是随机接入过程所必须的；根据MIB的信息可以解码SIB1，小区选择参数、接入控制参数和初始接入相关的信道配置信息是随机接入过程所必须的

-- ASN1START
-- TAG-MIB-STARTRelease 16 256 3GPP TS 38.331 V16.2.0 (2020-09)
MIB ::= SEQUENCE {
systemFrameNumber BIT STRING (SIZE (6)),
subCarrierSpacingCommon ENUMERATED {scs15or60, scs30or120},
ssb-SubcarrierOffset INTEGER (0..15),
dmrs-TypeA-Position ENUMERATED {pos2, pos3},
pdcch-ConfigSIB1 PDCCH-ConfigSIB1,
cellBarred ENUMERATED {barred, notBarred},
intraFreqReselection ENUMERATED {allowed, notAllowed},
spare BIT STRING (SIZE (1))
}
-- TAG-MIB-STOP
-- ASN1STOP

-- ASN1START
-- TAG-SIB1-START
SIB1 ::= SEQUENCE {
cellSelectionInfo SEQUENCE {
q-RxLevMin Q-RxLevMin,
q-RxLevMinOffset INTEGER (1..8) OPTIONAL, -- Need S
q-RxLevMinSUL Q-RxLevMin OPTIONAL, -- Need R
q-QualMin Q-QualMin OPTIONAL, -- Need S
q-QualMinOffset INTEGER (1..8) OPTIONAL -- Need S
} OPTIONAL, -- Cond Standalone
cellAccessRelatedInfo CellAccessRelatedInfo,
connEstFailureControl ConnEstFailureControl OPTIONAL, -- Need R
si-SchedulingInfo SI-SchedulingInfo OPTIONAL, -- Need R
servingCellConfigCommon ServingCellConfigCommonSIB OPTIONAL, -- Need R
ims-EmergencySupport ENUMERATED {true} OPTIONAL, -- Need R
eCallOverIMS-Support ENUMERATED {true} OPTIONAL, -- Need R
ue-TimersAndConstants UE-TimersAndConstants OPTIONAL, -- Need R
uac-BarringInfo SEQUENCE {
uac-BarringForCommon UAC-BarringPerCatList OPTIONAL, -- Need S
uac-BarringPerPLMN-List UAC-BarringPerPLMN-List OPTIONAL, -- Need S
uac-BarringInfoSetList UAC-BarringInfoSetList,
uac-AccessCategory1-SelectionAssistanceInfo CHOICE {
plmnCommon UAC-AccessCategory1-SelectionAssistanceInfo,
individualPLMNList SEQUENCE (SIZE (2..maxPLMN)) OF UAC-AccessCategory1-SelectionAssistanceInfo
} OPTIONAL -- Need S
} OPTIONAL, -- Need R
useFullResumeID ENUMERATED {true} OPTIONAL, -- Need R
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension SIB1-v1610-IEs OPTIONAL
}
SIB1-v1610-IEs ::= SEQUENCE {
idleModeMeasurementsEUTRA-r16 ENUMERATED{true} OPTIONAL, -- Need R
idleModeMeasurementsNR-r16 ENUMERATED{true} OPTIONAL, -- Need R
posSI-SchedulingInfo-r16 PosSI-SchedulingInfo-r16 OPTIONAL, -- Need R
nonCriticalExtension SEQUENCE {} OPTIONAL
}
UAC-AccessCategory1-SelectionAssistanceInfo ::= ENUMERATED {a, b, c}
-- TAG-SIB1-STOP
-- ASN1STOP

RRCSetupRequest

  • 相关IE：

  • ue-Identity 用于促进低层竞争解决

  • 高层提供5G-S-TMSI(UE在当前小区所在TA进行了注册则有)，设置为ng-5G-S-TMSI-Part1

5G-S-TMSI是临时移动用户标识，包含分配该标识和AMF信息和唯一ID信息。在AMF内唯一标识一个UE，由核心网配置。此处高层应该指的AMF，Paging信息中包含了"ng-5G-S-TMSI"IE可选

如果AMF提供了5G-S-TMSI，而在INITIAL_UE_MESSAGE中没有收到预期的5G-S-TMSI，则AMF认为该过程失败

Q:part2在哪？一定会是part1+part2两部分吗？

ng-5G-S-TMSI-Part2包含在RRCSetupComplete中，part1和part2都是CHOICE可选的，可能没有part1、part2。某些情况下，如Paging寻呼时会用到，但在初始接入时没有该IE

  • 高层不提供，则设置为0～2^39^之间的随机数

  • informationCuase 根据高层收到的信息设置

  • establishmentCause RRC建立原因

  • 动作：

  • UE继续小区重选相关测量以及小区重选评估

RRCSetup

  • 相关IE：

  • masterCellGroup IE 主小区组

  • 根据内容执行小区配置过程 (38331-5.3.5.5)

  • radioBearerConfig IE 无线承载配置

  • 根据内容执行无线承载配置过程

  • 配置了SRB1的RLC承载

  • 动作：

  • UE 进入RRC_Connected状态

  • 停止小区重选

  • 将当前小区设置为主小区(PCell) ( 完成小区选择 )

RRCSetupComplete

  • 使用SRB1承载信令

  • 设置RRCSetupComplete消息内容：

  • 5G-S-TMSI

  • 高层提供，则将ng-5G-S-TMSI-Value设置为ng-5G-S-TMSI-Part2

  • seletedPLMN-Identity

  • 设置为plmn-IdentityList包含的PLMN中选择PLMN

  • registeredAMF，高层提供，则SRB1中包含，并设置如下：

  • 如果Registered AMF的PLMN Identity与高层所选的PLMN不同，则将plmnIdentity包含进registered AMF中，并将其设置为从高层收到的PLMN identity值

  • guami-Type

  • 表明guami是本地的还是映射的

  • s-nssai-List

  • 高层提供一个/多个S-NSSAI，则包含此IE，并设为高层提供的值

  • dedicatedNAS-Message

  • 基站不处理，透传给核心网

  • 实际上，在接收到RRCSetup信令之后，UE即开始配置如上IE，在RRCSetupComplete中通过SRB1发送给gNB

  • 该消息中包含Registration Request注册请求

2. NAS消息

Initial UE Message

  • 当基站在RRC连接中从空口收到了第一条NAS消息，会发送此消息给AMF

  • 相关IE：

  • gNB收到Msg.5后开始给UE分配对应的RAN UE NGAP ID

Q:这个ID是哪层分配的？基站和核心网在AP有个索引的映射，核心网的那个索引IE叫什么？基站什么时候拿到？

此ID是gNB分配给UE的。UE和核心网之间映射的ID叫AMF_UE_NGAP_ID，是AMF用于区分UE的ID。AMF通过DOWNLINK_NAS_TRANSPORT发送给基站[注:不确定问题是否指的此IE?]

  • gNB收到Msg.5后开始给UE分配对应的RAN UE NGAP ID

  • 唯一识别码，取值为0~2^32^-1的整数

  • 此IE会触发DL NAS TRANSPORT

Q:这个什么意思？如何理解，这是触发了一个什么过程？

此处描述错误，删掉

  • NAS-PDU

  • Msg.5中收到的Registration Requst

  • UE发给核心网的NAS消息，基站透传

  • User Location Information

  • UE所在位置信息

  • Msg.3中收到的 RRC Establishment Cause、5G-S-TMSI 和 AMF Set ID

  • UE Context Request

  • 包含此IE，基站需要建立包含安全信息的UE上下文，核心网会** 触发初始上下文建立流程 **

  • Allowed NSSAI

  • 切片信息

DL information transfer

Q:初始上下文后的几条nas里面的ie不需要了解，但需要掌握：这几条nas交互，是为了完成一个什么过程或是功能？

这几条NAS交互，主要完成了两个过程，即鉴权(AuthenticationRequest/Response)和NAS加密(SecurityModeCommand/Complete)。交互双方是UE和AMF，基站负责转发

  • DL Information Transfer是将NAS专用信息从NG-RAN(网络)传输到UE的过程

  • 相关IE：

  • dedicatedNAS-Message 专用NAS消息

  • 包含此IE，将dedicatedNAS-Message转发到高层

  • referenceTimeInfo 参考时间信息

  • 基于 timereferenceSFN 和 timeInfoType 计算时间

  • 基于 uncertainty 计算时间不确定性

  • 通知高层 时间 和 uncertainty

UL information transfer

  • 是将NAS专用消息从UE传输到gNB(网络)的过程

  • 相关IE：

  • dedicatedNAS-Message

  • 如果高层提供了NAS PDU，设置dedicatedNAS-Message包含从高层接收到的消息

  • 动作：

  • 将ULInformationTransfer消息传递给低层发送

DOWNLINK NAS TRANSPORT

  • 目的是在UE和AMF之间提供有效载荷传输

  • 相关IE：

  • AMF UE NGAP ID

  • Old AMF

  • 包含此IE，则说明UE相关的NG连接是从另一个此IE识别的AMF重定向到此AMF

  • RAN Paging Priority

  • 服务优先级，用于基站寻呼处于RRC_INACTIVE状态的UE的优先级

  • Mobility Restriction List

  • Index to RAT/Frequency Selection Priority

  • UE Aggregate Maximum Bit Rate

UPLINK NAS TRANSPORT

  • 当与UE相关的逻辑NG连接存在时，基站从空口收到了需要转发给AMF的NAS消息时，会触发此过程

  • 相关IE：

  • 包含UE的位置信息

3. 初始上下文建立 Initial Context Setup

INITIAL CONTEXT SETUP REQUEST

  • 在基站建立UE上下文

  • 包括PDU session上下文

Q:这5个方面，初始上下文建立中一定都携带吗？如果有不一定携带的，哪个是不一定的？

不一定全部携带

PDUSession上下文不一定携带，有业务需求时才需要建立PDUSession；UE无线能力也不一定携带，当核心网提供的信息不满足当前过程，或核心网未提供时才会有此IE

  • 安全密钥

  • 移动性限制列表

  • UE无线能力

  • UE安全能力

  • 相关信息：

  • Core Network Assistance Information for RRC INACTIVE

  • 提供RRC_INACTIVE配置的辅助信息，无此信息UE无法进入INACTIVE态

  • GUAMI

  • 识别AMF ID

  • PDU session建立请求列表

  • UE Security Capabilities

  • Security Key

  • 在基站中为不同的场景应用安全性

INITIAL CONTEXT SETUP RESPONSE

  • 基站通过此消息将建立成功/失败的PDU session上报给AMF

4. 初始AS安全激活 Initial AS security activation

SecurityModeCommand

  • 包含完整性保护算法和加密算法，用来激活AS安全

  • 发送时机是在SRB1建立之后，SRB2和DRBs建立之前

  • UE收到消息后动作：

  • 推演KgNB密钥和KRRCint密钥验证此信息的完整性保护

  • 利用完整性保护算法和KRRCint密钥验证此消息的完整性保护

  • 通过完整性保护检查后

  • 对SRB通过算法** 进行完整性保护 ，对后续UE接收和发送的消息， 包括SecurityModeComplete **，进行完整性保护应用

  • 对SRB进行** 加密 ，对后续UE接收和发送的消息， 除了SecurityModeComplete **，进行加密

  • 向基站 ** 发送SecurityModeComplete **消息

SecurityModeComplete

  • 表明;初始安全激活成功

5. RRC重配置

RRCReconfiguration

  • 用来修改RRC连接，包括：

  • 测量配置

  • 移动性控制

  • 无线资源配置(包括RB、MAC主配置和物理信道配置)

  • AS安全配置

  • 若消息中包含除SRB1之外的RB建立(SRB2和DRBx)，此信息发送后，UE即刻可使用这些RB

Q:SRB2和DRB一定有吗？基站是否建立SRB和DRB的依据是什么？如果本次的过程没有，那SRB2和DRB是哪个过程建立的？

DRB不一定有。跟PDUSession上下文一样，建立依据是是否有用户数据/业务需求。有业务需求才会建立PDUSession和相应的DRB(s)

SRB2不一定有。SRB2用于承载NAS消息和测量信息相关的RRC消息，SRB1用于承载RRC消息和SRB2建立之前的NAS消息。据上述两条定义，推论为SRB2的建立是可选的、非必须的。当需要传输NAS消息或测量信息相关的RRC消息时，建立SRB2[注:此为推理，未找到协议中具体描述信息]

RRCReconfigurationComplete

  • 表明RRC重配完成

  • 从此信息开始，使用SRB2承载

Q:从此开始，使用SRB2承载，是所有信令都开始使用srb2承载吗？不是所有的话，具体是哪些开始使用SRB2承载？

此处描述应该修改为:从此信息开始(即SRB2建立之后)，"所有的NAS消息和包含测量信息的RRC信息"，用SRB2承载。其他的RRC信令，由SRB1(或SRB3)承载

DLInformationTransfer/ULInformationTransfer中有明确描述，如果SRB2已经建立，则不能用SRB1发送，如果SRB2没有resume，也不能发送

拓展

随机竞争介入过程

  • 包括Msg.1~Msg.5

  • Msg.1是UE发起竞争介入

  • Msg.2是gNB返回给UE的RAR

  • 从Msg.3开始算是“附着”过程，Msg.3~Msg.5是完整的RRC连接建立流程

  • 拓展问题：

Msg.3只用来发送RRCSetupRequest吗？(请跳转至下方问题思考的第一个问题处)

SRB, Signalling Radio Bearers 信令无线承载

  • SRB0

  • 使用CCCH(Common Control CHannel)

  • 用于传输RRC和NAS消息

  • 一直存在

  • SRB1

  • 使用DCCH(Dedicated Control CHannel)

  • 用于传输RRC消息和SRB2建立之前的NAS消息

  • 在RRC_CONNECTED态后建立，即从RRCSetupComplete开始使用SRB1承载

  • SRB2

  • 使用DCCH

  • 用于传输NAS消息和包含测量信息的RRC消息

  • 在UE接收到RRCReconfiguration之后建立

Note：

  • 测量消息可以通过SRB1发送，但要等AS安全激活完成后，才会通过SRB2返回测量报告
DRB, (user)Data Radio Bearers (用户)数据无线承载
  • 传输用户数据
关于UE能力的注意点

  • gNB在AS安全激活之后获取UE能力，不应在AS激活前将获取的UE能力发送给核心网

  • 对于未经验证的紧急呼叫，gNB可以在AS安全激活之前查询UE能力，但不用储存；gNB在AS安全激活之后重新查询UE能力

  • gNB的下行加密在发送SMC后便启动

  • 上行加密在UE侧从发送完AS SMC Complete消息后启动；下行解密在UE侧从收到并成功完保校验SMC消息后开始

UE能力的分类

  • UE specific的UE Capability：每个UE可以有不同的能力，这种UE能力适用于UE支持的所有载波和载波组合。

  • 载波组合(Band Combination)级别的UE Capability：每个载波组合可以用不同的能力。

  • 载波(Band)级别的UE Capability：Band可以有不同的能力。

  • 另一种UE能力分类的方法是按照协议栈来分类，UE Capability实际上报的时候也是按照协议栈分层来上报的。UE Capability上报分为：

  • PDCP-Parameters：PDCP层对应的UE Capability

  • RLC-Parameters：RLC层对应的UE Capability

  • MAC-Parameters：MAC层对应的UE Capability

  • Phy-Parameters：PHY层对应的UE Capability

  • RF-Parameters：RF（射频）相关的UE Capability

问题思考

Msg.3只用来发送RRCSetupRequest吗？

  • 不是，有如下几种情景：

  • RRC_IDLE状态下的初始接入，通过RRCSetupRequest

  • RRC_INACTIVE状态下的恢复接入，通过RRCResumeRequest

  • RRC连接重建，通过RRCReestablishmentRequest

  • Msg.3中包含的一个重要信息

  • UE唯一标识，用于Msg.4的冲突解决

RRCReconfiguration重配的重要IE和作用

  • radioBearerConfig 用于重配置无线承载、数据无线承载、传输信道及物理信道

  • srb-ToAddModList 用于SRB2的建立

  • drb-ToAddModList 用于DRB的建立

  • measConfig 用于测量配置的修改

  • measObjectToAddModList 用于添加测量对象

  • reportConfigToAddModList 用于报告配置

  • measIdToAddModList 用于测量ID

  • s-MeasureConfig 用于阈值的配置

  • quantityConfig 用于质量配置

  • masterCellGroup

  • rlc-BearerToAddModList 用于无线承载相关的MAC逻辑信道和RLC实体的配置

  • spCellConfig 包括下行BWP、上行BWP、CSI测量配置

NAS状态的说明

  • NAS信令连接用于实现UE与核心网之前的NAS信令交换

  • UE与AMF之间的连接状态有两种：

  • CM_IDLE

  • CM_CONNECTED

  • 状态转换：

  • CM_IDLE -> CM_CONNECTED

  • AMF接收到初始N2消息(INITIAL UE MESSAGE)，将开始从CM_IDLE转换到CM_CONNECTED状态

  • CM_CONNECTED -> CM_IDLE

  • 发生RRC Relase时

  • 与RRC_INACTIVE状态的联系：

  • 处于CM_CONNECTED状态的UE可以处于RRC_INACTIVE状态

  • 可以理解为AMF感知不到RRC_INACTIVE状态(RRC_INACTIVE指的是UE和gNB之间的状态)

标签： 5G 信息与通信 网络安全
本文转载自: https://blog.csdn.net/msjlhx/article/details/129121543
版权归原作者 Loop Liu 所有， 如有侵权，请联系我们删除。
登录后发布评论

“5G UE附着过程 学习心得”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

249_基于springboot的安全生产培训管理系统（共享资源、学习课件、用户管理、公告管理等功能）

Ubuntu 24.04-自动安装-Nvidia驱动

动态网页爬取 —— ajax 与 selenium

Error:不支持发行版本 5 解决方法--Idea一次性解决所有idea项目（包括新项目）的maven配置问题

Atom：开源世界的代码编辑利器

Hadoop学习 第二章 HDFS

最全Kafka知识宝典之消费端深度剖析

文章导航