7.3.3.2.4 Msg5 — 初始接入完成确认

本节课程视频前面几节课我们陆续讨论了随机接入初始化接入过程中的Msg1PRACH随机接入信道、Msg2RAR、Msg3RRC连接请求与Msg4竞争解决。通过这四步正常情况下已经解决了竞争问题并且建立好了RRC连接——不管Msg4内部是采用一次调度还是两次调度的方式到这一步竞争已经解决RRC Connection已经建立。后续所有的通信过程都要基于这一步所建立起来的RRC连接SRB1也就是DCCH这一逻辑信道所对应的资源来进行。原则上讲到第四步结束、手机确认收到Msg4之后它会向基站再次发送一个确认消息——通过PUCCH反馈一个ACK告诉基站“我已经成功收到了”。看起来后面似乎就没有太多需要特别关注的内容了因为接下来的所有信令和数据交互都是在用户专用通道里进行的正常业务。但实际上从Msg4到Msg5之间跟其他业务阶段的普通信令交互相比仍然存在一些独特之处——这正是本节要展开讨论的内容。一、Msg4到Msg5从“匿名状态”到“正规军”的分水岭在随机接入过程中Msg4竞争解决成功是手机从“匿名状态”转为“正规军”的分水岭。由于竞争接入可能存在两个手机在前面几步完全撞车的极端情况系统在Msg4之后一直到Msg5建立了一套非常严密的双向确认与状态锁定机制。手机成功解调出用TC-RNTI加扰的PDCCH、下载了Msg4RRCSetup数据包之后会打开MAC PDU将其中的“冲突解决MAC CE”Contention Resolution Identity MAC CE与自己之前缓存在Msg3里的48位自身标识CCCH SDU进行逐比特比对——如果完全一致手机就判定“我赢了”。而基站这一侧只有在预期的USSUE专用搜索空间或特定上行资源上成功用该C-RNTI解调出了Msg5基站内部的数据链路上下文Context才会彻底把该C-RNTI标记为“Active激活/已连接”状态——至此基站才真正确信该UE已经成功常驻本小区双向竞争解决正式画上句号。一旦Msg4冲突解决手机和基站就正式告别了“随机接入”的无序阶段顺理成章地进入RRC连接态RRC_CONNECTED的全套标准业务流程。后续的过程会环环相扣地推进——例如会携带NAS层的Registration Request消息通过gNB一直传给核心网。消息生动比喻核心动作Msg4“领准考证”手机在公共信道CSS通过比对48位Identity确定自己被录取并将临时工牌TC-RNTI升级为专属工牌C-RNTIMsg5“凭证打卡并提交档案”手机移步到专用控制车道USS用C-RNTI加扰发送Msg5将高层的入网档案NAS消息托付给基站转发核心网从而全面激活基站与核心网侧的全套安全、鉴权及用户面数据承载DRB流程二、Msg5与普通PUSCH调度的本质区别本教材后续将有专门一节详细介绍PUSCH相关内容——我们会讲到PUSCH信道与PDSCH信道有相似之处都需要通过PDCCH来调度但也有明显不同对于下行PDSCH基站的调度器主要位于基站MAC层非常清楚每个手机在无线接口上的通道资源使用情况一旦有下行数据到来就可以直接在MAC层调度器中做出调度、通过DCI分配PDSCH资源这是一种非常直接的方式。但对于PUSCH而言情况有所不同——基站并不知道手机究竟有多少数据要发送因此正常的上行数据发送流程要复杂得多步骤名称作用第一步SRScheduling Request调度请求手机向基站申请“调度资源”这件事本身——此时基站还没有分配任何资源给手机手机只是先请求“给我一次被调度的机会”第二步基站反馈基站收到SR后回复手机“可以开始调度了”并等待手机进一步告知具体的数据量第三步BSRBuffer 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 SetupMsg4之后、UL_DCCH/RRCSetup CompleteMsg5图中高亮显示出现的时候前后并没有出现我们刚才分析的普通上行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开始二者在频域上完全不重叠但两次调度所分配的TBTransport 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-RNTIMsg5与普通PUSCH调度流程的本质区别——由于基站已经能够预判手机接下来必然要发送Msg5因此主动跳过了SR、BSR这两轮申请交互直接以最快速度下发UL Grant大幅压缩了接入时延并结合一组真实的信令跟踪截图具体展示了基站针对Msg5所采取的“双重PUSCH资源预分配”这一颇具工程智慧的调度策略以及其背后“宁可资源富余、也要确保一次调度成功”的设计考量。最后我们简要说明了Msg5的HARQ确认机制及其标志着整个初始化接入流程正式收尾这一结论。至此我们已经完整地讲解了随机接入初始化接入过程中Msg1至Msg5的全部五个步骤构建起了一套系统而完整的知识体系。下一部分“7.3.4 PUSCH及其DMRS”我们将正式转入对上行共享信道PUSCH本身的深入学习其中也会呼应本节提到的“初始接入过程中的PUSCH”这一话题进一步展开讨论。