本节课程视频
前面几节课，我们陆续讨论了随机接入（初始化接入）过程中的Msg1（PRACH随机接入信道）、Msg2（RAR）、Msg3（RRC连接请求）与Msg4（竞争解决）。通过这四步，正常情况下已经解决了竞争问题，并且建立好了RRC连接——不管Msg4内部是采用一次调度还是两次调度的方式，到这一步，竞争已经解决，RRC Connection已经建立。
后续所有的通信过程，都要基于这一步所建立起来的RRC连接（SRB1，也就是DCCH这一逻辑信道所对应的资源）来进行。原则上讲，到第四步结束、手机确认收到Msg4之后，它会向基站再次发送一个确认消息——通过PUCCH反馈一个ACK，告诉基站“我已经成功收到了”。看起来，后面似乎就没有太多需要特别关注的内容了，因为接下来的所有信令和数据交互，都是在用户专用通道里进行的正常业务。但实际上，从Msg4到Msg5之间，跟其他业务阶段的普通信令交互相比，仍然存在一些独特之处——这正是本节要展开讨论的内容。
一、Msg4到Msg5：从“匿名状态”到“正规军”的分水岭
在随机接入过程中，Msg4竞争解决成功，是手机从“匿名状态”转为“正规军”的分水岭。由于竞争接入可能存在两个手机在前面几步完全撞车的极端情况，系统在Msg4之后一直到Msg5，建立了一套非常严密的双向确认与状态锁定机制。
手机成功解调出用TC-RNTI加扰的PDCCH、下载了Msg4（RRCSetup数据包）之后，会打开MAC PDU，将其中的“冲突解决MAC CE”（Contention Resolution Identity MAC CE）与自己之前缓存在Msg3里的48位自身标识（CCCH SDU）进行逐比特比对——如果完全一致，手机就判定“我赢了”。而基站这一侧，只有在预期的USS（UE专用搜索空间）或特定上行资源上，成功用该C-RNTI解调出了Msg5，基站内部的数据链路上下文（Context）才会彻底把该C-RNTI标记为“Active（激活/已连接）”状态——至此，基站才真正确信该UE已经成功常驻本小区，双向竞争解决正式画上句号。
一旦Msg4冲突解决，手机和基站就正式告别了“随机接入”的无序阶段，顺理成章地进入RRC连接态（RRC_CONNECTED）的全套标准业务流程。后续的过程会环环相扣地推进——例如会携带NAS层的Registration Request消息，通过gNB一直传给核心网。
消息 | 生动比喻 | 核心动作 |
Msg4 | “领准考证” | 手机在公共信道（CSS）通过比对48位Identity确定自己被录取，并将临时工牌（TC-RNTI）升级为专属工牌（C-RNTI） |
Msg5 | “凭证打卡并提交档案” | 手机移步到专用控制车道（USS），用C-RNTI加扰发送Msg5，将高层的入网档案（NAS消息）托付给基站转发核心网，从而全面激活基站与核心网侧的全套安全、鉴权及用户面数据承载（DRB）流程 |
二、Msg5与普通PUSCH调度的本质区别
本教材后续将有专门一节详细介绍PUSCH相关内容——我们会讲到，PUSCH信道与PDSCH信道有相似之处（都需要通过PDCCH来调度），但也有明显不同：对于下行PDSCH，基站的调度器（主要位于基站MAC层）非常清楚每个手机在无线接口上的通道资源使用情况，一旦有下行数据到来，就可以直接在MAC层调度器中做出调度、通过DCI分配PDSCH资源，这是一种非常直接的方式。
但对于PUSCH而言，情况有所不同——基站并不知道手机究竟有多少数据要发送，因此正常的上行数据发送流程要复杂得多：
步骤 | 名称 | 作用 |
第一步 | SR（Scheduling Request，调度请求） | 手机向基站申请“调度资源”这件事本身——此时基站还没有分配任何资源给手机，手机只是先请求“给我一次被调度的机会” |
第二步 | 基站反馈 | 基站收到SR后，回复手机“可以开始调度了”，并等待手机进一步告知具体的数据量 |
第三步 | BSR（Buffer Status Report，缓冲区状态报告） | 手机告诉基站自己大概有多少字节的数据需要发送 |
第四步 | 正式UL Grant | 基站根据BSR的内容，才正式向手机分配用于承载数据的上行资源 |
这样一套完整的流程走下来，交互次数多达两三次，每一次交互都要占用好几个时隙、好几个调度周期，整体时间开销是相当可观的。正因为普通上行调度存在这样的效率问题，随机接入本身又已经因为其“随机性”（不同格式的选择、基站在一定时频域范围内的捕获、潜在的冲突等）而占用了不少时间，所以在Msg5这一步，我们自然会考虑：能否尽量减少不必要的时延开销，比如省去SR、BSR这两轮交互？
三、Msg5的调度捷径：跳过SR与BSR
答案正是本节的核心内容：基站在收到手机对Msg4第二次调度（若采用两次调度方式）的确认报告之后，就已经非常明确地知道，接下来手机肯定要发送Msg5——因为这是流程中必然要走的下一步。既然如此，基站就没有必要再让手机走一遍完整的SR/BSR申请流程，而是直接以最快的速度，在收到确认报告的这个时间点上，主动给手机分配上行资源（即UL Grant），让手机可以直接发送Msg5。
而且，Msg5本身虽然也可能包含一些变化的内容（比如可能携带手机向核心网发起的注册请求NAS消息，内容可能不算少），但总体而言，它所承载内容的数据量、字节数是相对可以预估的。正因如此，基站在收到上行确认之后，可以立即以最快速度向手机分配一个大致够用的上行资源，直接跳过SR、BSR这两轮交互，这正是Msg5调度过程与其他普通PUSCH发送流程最不同的地方。
四、真实信令案例：从截图看Msg5的调度全貌
下面结合一组真实的信令跟踪截图，具体展示Msg5在实际网络中的调度过程。
图7.3.3.2.4-1 真实信令跟踪截图：从RRC Setup Req到RRCSetup Complete之后的Msg5调度记录（原讲义配图）
从截图中可以看到，在DL_CCCH/RRC Setup（Msg4）之后、UL_DCCH/RRCSetup Complete（Msg5，图中高亮显示）出现的时候，前后并没有出现我们刚才分析的普通上行PUSCH所需要的SR、BSR这些消息——基站直接给手机下发了一个DCI（体现为“NR5G MAC UL Physical Channel Schedule Report”），其中直接包含了对Msg5所需PUSCH资源的调度指令。这清楚地印证了前文所述：Msg5的调度完全跳过了SR/BSR这两轮请求，由基站主动、直接完成。
4.1一个有趣的现象：同一时刻的“双重调度”
从截图中的UL Physical Channel Schedule Report可以看到一个非常有意思的细节：基站在同一个无线帧、同一个子帧、同一个载波内，同时分配了两个PUSCH资源——二者唯一的区别在于频域上的起始RB不同：一个从RB 173开始，另一个从RB 149开始，二者在频域上完全不重叠；但两次调度所分配的TB（Transport Block）大小是完全相同的（截图中TBS均为201字节），HARQ ID分别为0和1。
图7.3.3.2.4-2 两次PUSCH调度的详细参数：TB Size均为201字节，RB Start分别为173与149（原讲义配图）
为什么基站要在同一时刻，分配两份大小相同、频域位置不同的PUSCH资源给同一个手机？这背后的原因在于：基站对Msg5的调度，本质上是一种基于“猜测”的资源预分配——基站并不能100%确定手机接下来到底要发送多少字节的内容，因此往往会倾向于尽量给到一个较为充裕、甚至偏大的资源量，以确保手机有足够的空间把Msg5中所有需要携带的字段（包括可能的NAS注册请求消息）都放进去，避免资源不够用导致这次调度直接失败——一旦失败，手机就不得不重新发起SR、BSR流程，反而更加拖慢整体的接入效率。
至于同时给两份完全相同大小的资源，则可能是基站为手机提供更灵活的选择余地，或者是一种“双保险”式的冗余调度策略。如果手机实际需要发送的内容用第一份资源就已经足够，那么第二份资源分配到的位置，手机就只能填入空数据（即所谓的Padding），充当占位内容。这也是我们在实际网络测试中，能够观察到的一个颇具趣味性的现象——基站在面对内容量难以精确预知的Msg5调度时，其内部调度逻辑所考虑的因素可能比想象中更为复杂，既要考虑手机使用的灵活性，也要在“分配是否足够”和“是否造成资源浪费”之间做出权衡。
知识拓展｜为什么基站宁可“多给”也不愿“少给” 如果基站为Msg5分配的资源量不足，手机将无法把完整的内容装进这个TB中，这次调度就会直接宣告失败。失败之后，手机不得不重新走一遍SR、BSR的完整申请流程，这不仅会显著增加接入时延，还会进一步占用宝贵的公共控制信道资源。相比之下，即便基站分配的资源略有富余（用不完，剩余部分填充Padding），所付出的代价也只是这一次调度中PUSCH资源的轻微浪费，远小于“调度失败后重新申请”所带来的时延和资源开销。因此，在Msg5这种内容量难以精确预知、但又对接入效率要求很高的场景下，基站的调度策略往往会倾向于“宁可多给、不可少给”，这是一种以局部资源效率换取整体接入速度的工程权衡。 |
五、Msg5之后：HARQ确认与整个初始接入流程的收尾
按照正常的逻辑，无论Msg5是通过一次调度还是两次调度完成的资源分配，手机把Msg5发送给基站之后，基站方面会有相应的反馈——也就是HARQ的ACK/NACK消息需要反馈给手机。由于5G网络中并没有像4G那样专门的PHICH信道，如果Msg5的接收出现问题，基站会通过重新调度一次PUSCH（重传）来处理，其判断方式与我们此前分析Msg3重传时所讲的原理是一致的——依据NDI（新数据指示）等相应字段，来确定这次调度给手机的是旧数据的重传，还是新的调度内容。
一旦Msg5被基站完整、正确地接收，且不需要再向手机发起任何重传调度，那么整个随机接入、也就是初始化接入的过程，就宣告正式结束了。
六、本节小结
本节围绕随机接入流程的最后一步——Msg5展开，系统讲解了以下内容：Msg4到Msg5之间建立起的严密双向确认与状态锁定机制，标志着手机从“匿名竞争”正式转为“已连接”状态，TC-RNTI也随之升级为正式的C-RNTI；Msg5与普通PUSCH调度流程的本质区别——由于基站已经能够预判手机接下来必然要发送Msg5，因此主动跳过了SR、BSR这两轮申请交互，直接以最快速度下发UL Grant，大幅压缩了接入时延；并结合一组真实的信令跟踪截图，具体展示了基站针对Msg5所采取的“双重PUSCH资源预分配”这一颇具工程智慧的调度策略，以及其背后“宁可资源富余、也要确保一次调度成功”的设计考量。最后，我们简要说明了Msg5的HARQ确认机制及其标志着整个初始化接入流程正式收尾这一结论。
至此，我们已经完整地讲解了随机接入（初始化接入）过程中Msg1至Msg5的全部五个步骤，构建起了一套系统而完整的知识体系。下一部分“7.3.4 PUSCH及其DMRS”，我们将正式转入对上行共享信道PUSCH本身的深入学习，其中也会呼应本节提到的“初始接入过程中的PUSCH”这一话题，进一步展开讨论。
