NR随机接入之MSG3

在这里插入图片描述

1.MSG3的作用

  1)向基站提供UE的合法身份标识以完成接入,获取相应的注册服务
  2)携带发起竞争随机接入(CBRA)的原因,如EstablishmentCause、ResumeCause等

2.MSG3类型

  MSG3可以分为两种类型:CCCH SDU、C-RNTI MAC CE + [other],如表1所示。图中未标明C-RNTI MAC CE的,均为CCCH SDU。CCCH SDU承载在SRB0上,使用RLC TM模式,在实现时,可在RRC与MAC之间直接交互。这两种类型除系统消息请求外均需要携带UE的身份标识,这是因为系统消息是广播发送的,小区内所有UE均可接收,且UE也不需要进入RRC连接态。Note:竞争同步重配和其他连接态的的CBRA的MSG3类型一致,这里为了强调切换这种场景,故单独进行了描述。

表1 NR MSG3内容

在这里插入图片描述
(1)RRCSetupRequest(48bits)
  该信元用于处于RRC Idle态的UE建立RRC连接,使用5G-S-TMSI(5G S-Temporary Mobile Subscription Identifier)的高39bits或者39bits随机值作为UE的身份标识。5G-S-TMSI由AMF Set ID、AMF Pointer 以及5G-TMSI组成,具体结构如下所示,从其结构组成中可以看出,5G-S-TMSI在AMF内是唯一的。

[5G-S-TMSI] = [AMF Set ID][AMF Pointer][5G-TMSI]

在这里插入图片描述

图1 RRCSetupRequest信元
(2)RRCResumeRequest和RRCResumeRequest1

  该信元用于处于RRC Inactive态的UE恢复RRC连接。RRC Inactive是LTE的基础上新增的一种RRC状态,此状态的UE仅断开AS连接,NAS层连接依然保持,同时基站也会保存UE的上下文信息。因此UE建连时,与Idle态相比,基站不需要再次获取UE能力,不需要重配安全等流程,缩短了接入过程的时延;与connected态相比,不需要测量上报、切换等流程,利于终端节能。UE的Inactive态是由基站控制的,基站可以根据UE当前承载的业务属性、支持的最大用户容量等信息进行判决是否通知connected态UE进入RRC Inactive态。基站通过携带参数suspendConfig的RRCRelease消息通知UE进入Inactive态。UE收到该消息后,会存储C-RNTI、RB等信息,并挂起除SRB0外的所有RB。当下列事件发生时,UE发起连接恢复流程:
✓ 存在需要发送的NAS信令或其他上行数据
✓ 收到NG-RAN paging(如果收到的是核心网paging,UE进入Idle态建连)
✓ RNA更新
  UE可以通过RRCResumeRequest或RRCResumeRequest1向基站请求恢复连接。这两个信元的区别体现在参数resumeIdentity,RRCResumeRequest1使用的是40bits的fullI-RNTI,RRCResumeRequest使用的是24bits的shortI-RNTI,基站在suspendConfig会将这两种RNTI全部通知给UE。UE则根据SIB1中的参数useFullResumeID置是/否为TRUE,来选择RRCResumeRequest1或RRCResumeRequest。fullI-RNTI由gNB ID和UE ID两部分组成,可以根据系统部署情况,灵活设置这两者各自占用的Bit数;shortI-RNT是由full-RNTI截断形成;一般运营商仅使用其中一种。
在这里插入图片描述

图2 RRCResumeRequest信元

在这里插入图片描述

图3 RRCResumeRequest1信元
(3)RRCReestablishmentRequest   该信元用于RRC Connected态、已激活AS侧安全、且建立了SRB2和至少一个DRB的UE继续保持RRC连接态。当下列事件发生时,UE发起连接重建流程:

✓ MCG无线链路失败(MAC随机接入失败属于该分支)
✓ MCG同步重配失败,如切换失败
✓ 从NR小区移动到其他小区失败
✓ SRB1或SRB2完整性校验失败(RRCReestablishment消息除外,因为这会产生死循环)
✓ RRC重配失败
  重建请求通过参数ReestabUE-Identity标识UE的身份,该参数包含(原)小区的PCI、UE C-RNTI等信息,如图4所示。
在这里插入图片描述

图4 RRCReestablishmentRequest信元
(4)RRCSystemInfoRequest

  该信元用于非RRC Connected的UE请求OSI(除MIB和SIB1外的其他系统消息)。基站可以根据自身策略(如节能考虑)、部署场景(不同UE对OSI的需求可能不同)等来选择是按需发送OSI还是周期发送OSI。如果选择按需发送OSI,且未配置专用RACH资源,则UE需要某个系统消息时,就需要发起MSG3为RRCSystemInfoRequest的竞争随机接入。RRCSystemInfoRequest-IEs->requested-SI-List中系统消息的顺序与SIB1->SchedulingInfo->schedulingInfoList的顺序一致。当下列事件发生时,UE发起系统消息请求流程:

✓ 小区选择
✓ 小区重选
✓ 进入小区覆盖范围
✓ 同步重配完成后
✓ 从其他RAT进入NR小区
✓ 收到系统消息更新指示
✓ 收到PWS(公众预警系统)通知,如ETWS 、CMAS
✓ UE没有收到有效OSI
在这里插入图片描述

图5 RRCSystemInfoRequest信元
(5)C-RNTI MAC CE

  对于RRC Connected态UE发起的竞争随机接入,MSG3均为C-RNTI MAC CE,该C-RNTI可能是原小区分配,也可能为目标小区分配的,即切换场景。
在这里插入图片描述

图6 C-RNTI MAC CE

3.MSG3资源

  MSG3的资源分配在MSG2中介绍了部分,这里从MSG3与其他PUSCH调度区别的角度,再补充下。
1)时域资源分配
✓ MSG3不支持slot aggregation
✓ MSG3对应的PUSCH调度需要在K2的基础上,额外添加Δ的处理时延
✓ RAR UL grant可以使用Default A PUSCH时域资源分配表格,也可以使用pusch-ConfigCommon中配置的时域资源分配表格
2)频域资源分配
✓ 当前激活上行BWP如果包含初始上行BWP(CP以及SCS相同),则使用初始上行BWP调度(Note:这里并不涉及BWP切换);否则使用当前激活上行BWP调度,但是使用的RB数量不能大于初始上行BWP大小
✓ DCI中频域资源字段的截断补长相关操作在DCI中描述
✓ MSG3的调度仅能使用type1频域资源分配方式
3)HARQ
✓ RAR授权默认采用RV=0,HARQ ID=0(包括CFRA)
✓ 对于RAR授权的PUSCH,CFRA是用C-RNTI加扰,CBRA则使用TC-RNTI加扰
✓ MSG3重传的DCI使用TC-RNTI加扰,基站可以单独设计MSG3的重传次数,UE在ra-SearchSpace检索
4)其他
  如果MSG3包含CCCH SDU,则MSG3授权不能小于56bits(如果MSG3是RRCResumeRequest1,则不能小于72bits)

Reference:

[1]3GPP TS 23.003: “Numbering, Addressing and Identification”.
[2]3GPP TS 38.213: “NR; Physical Layer Procedures for control”.
[3]3GPP TS 38.214: “NR; Physical Layer Procedures for data”.
[4]3GPP TS 38.321: “NR; Medium Access Control (MAC); Protocol specification”.
[5]3GPP TS 38.331: “NR; Radio Resource Control (RRC); Protocol specification”.

更多内容,请关注微信公众号—沧海Radio
在这里插入图片描述

  • 5
    点赞
  • 69
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值