前面的内容，我们主要讨论了在初始化随机接入过程中，随机接入信道所携带的前导码在时域、频域、码域上的各项特性，以及随机接入过程中竞争性接入（CBRA）与非竞争性接入（CFRA）这两种不同场景的应用方式。本节将在此基础上继续深入：在整个初始化接入过程当中，手机使用随机接入信道、随机接入前导码发起接入之后，究竟是如何一步步最终实现“建立RRC连接”这一目标的？

有时候我们容易简单地认为，随机接入信道或随机接入前导码只是MAC层所触发的一个孤立的信道或信号，加上Msg2（RAR）这一响应，就是随机接入的全部内容。但实际上，在这个基础之上，还需要继续讨论如何解决竞争的问题，并最终完成整个RRC连接建立（RRCSetup）的过程——这正是本节“总体流程”与下一节“具体流程分解”所要共同覆盖的内容。

我们在上一小节已经讲到，竞争性随机接入通过最多四到五步即可解决潜在的接入冲突；即便没有冲突，也同样需要通过这四到五步，来确认整个随机接入过程中，手机与其他手机之间不存在冲突、且这次接入是成功的。本节就来具体看看，在两步随机接入（Msg1前导码与Msg2响应）已经明确的基础上，后续的两到三步是如何最终解决竞争、结束整个RRCSetup过程的——也就是申请RRC连接这一完整过程。RRC连接的建立，本质上是建立起用户与网络、与小区之间的专用信令通道；如果流程继续推进下去，后续还将建立起专用的用户数据通道（DRB），供用户实际收发数据使用。

一、从上层需求到随机接入：跨层触发的完整链条

手机发起初始化接入的时机，通常是开机、重启等场景——当手机内部系统准备完备之后，上层应用会产生连接5G网络的需求。这一需求首先会触发手机5G协议栈中最上层的NAS（非接入层）生成一条Registration Request（注册请求）消息。这是一条标准的OTA（Over The Air，空口）消息，但它本身又是以透传（Transparent）的方式，打包在无线接口的RRC消息内部进行传递的。

由于NAS层处于协议栈的最上层，它无法直接将消息发送给基站或核心网，只能在手机内部逐层向下递交，最终依靠物理层发出信号，才能将信息真正传递给基站，再由基站以透传方式将NAS消息转发给核心网。因此，手机内部先由NAS层生成Registration Request（这是发起注册流程Attach的起点），随后这一请求被递交给RRC层。RRC层接到这一“需要向核心网传递NAS消息”的需求后，会触发自身的消息生成机制，形成RRCSetupRequest这条消息——这是一条真正意义上的RRC层三（L3）消息。

RRCSetupRequest生成后，同样需要向下递交——这一次递交的对象是层二（L2），其中最直接相关的是MAC层，因为MAC层正是最终的调度器所在的层级。RRC消息要想真正通过空口发送给基站，必须依靠MAC层触发物理层的信道行为。MAC层在接到这一递交请求后，首先要做的是检查物理层当前是否已经存在可用的RRC连接——由于这是初始化接入场景，显然尚不存在这样的连接，因此MAC层（或者说底层调度层）便会自主触发一次随机接入过程。

至此，我们此前用大量篇幅讨论过的随机接入信道时频域资源特性、竞争性/非竞争性等一系列属性，正是MAC层在这一步所需要综合考虑的内容——而这些考虑因素的触发依据，正是来自上层（RRC乃至NAS）逐层传递下来的这一需求。

图7.3.3.1-1 从上层需求到物理层随机接入的逐层触发链条（自制补充图）

二、RRCSetup总体流程的五步图景

手机完成上述触发之后，便会按照标准的随机接入与RRC连接建立流程，依次经历以下步骤：

图7.3.3.1-2 RRCSetup总体流程示意：Msg1~Msg4完整信令交互（原讲义配图）

需要特别指出一个时序上的细节：RRCSetupRequest这条消息，实际上是在Msg1、Msg2完成之前，就已经在手机内部的RRC层生成、并暂存于手机存储器当中的——它只是在“时间点”上先于Msg1/Msg2出现，但真正通过空口发送出去（作为Msg3），是在两步随机接入完成、拿到UL Grant资源之后才发生的。这也解释了此前小节中提到的一个关键细节：Msg3之所以不需要独立的PDCCH来调度，正是因为它复用了Msg2（RAR）中已经给出的上行授权。