7.3.3.2.3 Msg4-竞争解决

课程视频上一节课我们讨论了5G网络手机在初始化接入过程中随机接入的前两步Msg1、Msg2即PRACH前导码与随机接入响应RAR以及Msg3——它主要的作用从字面上看是向基站发起RRC连接建立请求但实际上还隐含着继续解决潜在竞争的作用万一有多个手机同时在相同的时频资源上选择了同样的前导码就需要有相应的机制来解决这一冲突问题。基站在收到Msg3之后如果能够正常接收不需要重传或即便需要重传、最终也成功接收就会进入下一步——也就是本节要讨论的Msg4。通常我们说随机接入是一个“四步接入”的过程再加上确认消息Msg5可以认为共同构成一个完整的接入过程。但实际上正常情况下前面四步就已经完成了竞争的解决第五步则是对“RRC连接已经建立”这一结果的确认消息。本节将聚焦于Msg4讨论它是如何最终解决竞争、确定RRC连接建立成功的。一、Msg4的两大核心作用Msg4有两个重要作用和明确的目标一是标识竞争已经解决二是给RRC连接或者说SRB1专用信令通道分配UE专用的资源。组成部分承载内容所属层级UE Contention Resolution Identity竞争解决标识用于确认接入成功的具体是哪一个UEMAC层控制单元MAC CERRCSetup为该UE分配专用信令通道DCCH/SRB1所需的完整配置信息RRC层层三消息如果确实有多个UE发生了冲突实际概率很低到这一步就需要解决多个UE因选择同一前导码而产生的资源冲突——通过基站的唯一“点名”机制确保仅有一个UE成功接入其余UE则需要重新发起接入尝试。二、两步调度机制为什么要把Msg4拆成两次发送由于UE Contention Resolution Identity与RRCSetup这两部分内容一个体量很小仅仅是一个ID号一个体量很大涉及物理层、MAC层、RLC层、PDCP层等多方面的详细配置参数因此在实际网络中往往会采用“两步指派”的调度方式调度顺序承载内容使用的RNTI特点第一次调度仅下发Contention Resolution的MAC CETC-RNTI内容很小能够以最快速度完成竞争解决的确认第二次调度承载来自RRC层的专用DCCH消息——RRCSetupC-RNTI实际上与TC-RNTI号码相同内容较大涉及大量详细配置参数需要说明的是这只是通用方式之一另一种方式是一次调度就完成完整Msg4的全部功能即MAC CE与RRCSetup合并在同一个PDSCH的TB中一起下发。无论是采用两次调度还是一次调度承载完整Msg4内容的PDSCH其重传机制都与普通的PDSCH重传方式相同。2.1为什么要优先确认竞争解决之所以要把竞争解决这一块单独、优先地做第一次调度核心考量在于Contention Resolution这一块ID号相对来说比较小可以很快地完成传输与确认而只有当竞争真正解决之后也就是确认了没有其他UE在争抢同一份资源手机才算是比较稳定可靠地接入了这个网络。与此相对RRCSetup涉及的内容很多——包括对用户专用信令通道在物理层、MAC层等各个层次的详细参数配置如果把这么大量的内容和竞争解决的确认捆绑在一起发送一旦竞争尚未解决例如另一个UE也在等待这份内容就会造成不必要的资源浪费。因此将“体量小、需尽快确认”的竞争解决标识与“体量大、可稍后配置”的RRCSetup分开发送正是许多网络采用两步调度方式的重要原因。三、UE Contention Resolution Identity MAC CE详解3GPP规范对UE Contention Resolution Identity MAC CE有明确的定义这一MAC CE由MAC PDU子头部中的LCID字段所标识具有固定的48比特大小由单一字段构成——该字段包含了UE在Msg3中所发送的UL CCCH SDU如果这个UL CCCH SDU的长度超过了48比特则该字段只包含UL CCCH SDU的前48比特。图7.3.3.2.3-13GPP规范中UE Contention Resolution Identity MAC CE的定义与格式原讲义配图从图中可以看到这48比特6个字节Oct 1至Oct 6的内容主体部分正是UE在Msg3中所发送的、代表其身份的那个字段——可能是随机数Random Value也可能是S-TMSI具体取决于该UE此前是否已经接入过网络。手机在收到这一MAC CE后会将其与自己此前缓存在本地、发送Msg3时所用的那48比特内容逐比特进行比对如果完全一致就说明这次竞争解决的结果确实是自己手机据此可以判定“我赢了”接入成功如果比对不一致则说明本次接入尝试没有成功可能是另一个UE的接入请求被基站确认手机需要重新发起随机接入。四、真实信令案例两次调度的完整呈现下面结合一组真实的信令跟踪截图具体展示两次调度方式在实际网络中的呈现。图7.3.3.2.3-2真实信令跟踪截图从RRC Setup Req到RRCSetup Complete的完整消息序列原讲义配图从这份消息列表中可以清晰看到完整的时序UL_CCCH/RRC Setup ReqMsg3→一系列MAC层调度与状态记录→ DL_CCCH/RRC SetupMsg4图中高亮显示→更多MAC层记录→ UL_DCCH/RRCSetup CompleteMsg5。值得注意的是DL_CCCH/RRC Setup这一条OTA消息记录实际上是两次PDSCH调度共同呈现出的最终结果——要看清楚具体是如何分两次调度的需要结合更底层的MAC层调度记录来分析。4.1第一次调度Contention Resolution MAC CE图7.3.3.2.3-3第一次调度对应的PDSCH Status记录TB Size7字节RNTI TypeTC_RNTI原讲义配图从这条PDSCH Status记录可以看到两个关键信息其一RNTI Type字段显示为TC_RNTI——这印证了第一次调度必须使用临时RNTI来加扰PDCCH因为此时竞争尚未解决基站还不能使用正式的C-RNTI其二TB Size字段仅为7个字节——6个字节48比特正是Contention Resolution Identity MAC CE本身的大小再加上1个字节的MAC子头部恰好合计7个字节与我们前面所讲的理论内容完全吻合这也是判断“这是第一次调度”的关键依据。4.2第二次调度RRCSetup完整配置图7.3.3.2.3-4第二次调度对应的PDSCH Status记录TB Size437字节RNTI TypeC_RNTI原讲义配图紧随第一次调度之后的第二条PDSCH Status记录显示RNTI Type已经变为C_RNTITB Size也大幅增加到437个字节——远大于第一次调度的7个字节。这一巨大的差异正好对应着RRCSetup这条包含大量物理层、MAC层、RLC层、PDCP层配置参数的层三消息。这里需要特别澄清一个容易混淆的地方截图中所显示的C-RNTI与第一次调度时使用的TC-RNTI实际上是完全相同的号码——只不过由于此时竞争已经通过第一次调度得到解决这个RNTI的“名分”正式从“临时”转正为“正式”但其数值本身并未发生变化。4.3两次调度各自独立的HARQ确认两次调度都各自拥有独立的HARQ反馈机制手机在成功接收并解调每一次调度的PDSCH内容后都需要通过PUCCH向基站反馈对应的ACK/NACK确认信息。由于此时用户专用的PUSCH等信道尚未建立手机只能通过公共的PUCCH资源来完成这一反馈。图7.3.3.2.3-5第一次调度对应的PUCCH HARQ反馈记录PUCCH Format F1UCI Request BMaskACK_NACK_RPT原讲义配图图7.3.3.2.3-6第二次调度对应的PUCCH HARQ反馈记录原讲义配图从这两组截图可以看到两次调度各自都有对应的PUCCH上行物理信道调度报告UCI Request BMask字段均标记为ACK_NACK_RPT表明这正是HARQ确认信息的反馈记录。在这个真实案例中两次曝光反馈的结果都是没有问题的——也就是说无论是第一次调度竞争解决确认还是第二次调度RRCSetup配置下发手机都成功接收并正确反馈了确认信息标志着整个Msg4流程顺利完成。知识拓展PUCCH在初始接入阶段的特殊角色读者可能会好奇手机此时还没有建立起任何专用的上行信道是如何发送PUCCH的答案在于小区会配置一份公共的PUCCH资源供尚处于竞争解决阶段、还未获得专用资源配置的UE使用用来反馈针对Msg4两次调度的HARQ确认信息。PUCCH在初始化接入过程中具体是如何工作的涉及格式选择、资源分配等更细致的内容教材后续章节将专门展开介绍这里读者只需了解即便在专用信道尚未建立的阶段公共PUCCH资源依然能够支撑起必要的HARQ反馈机制这是保障随机接入可靠性的重要一环。五、本节小结本节围绕随机接入过程中的Msg4展开系统讲解了以下内容Msg4承载着竞争解决标识UE Contention Resolution Identity MAC CE与RRC连接专用资源配置RRCSetup这两大核心内容由于二者体量悬殊实际网络中普遍采用两步调度的方式——先以TC-RNTI快速下发体量很小的MAC CE完成竞争确认再以转正后的C-RNTI下发体量较大的RRCSetup完成详细配置并结合3GPP规范原文与一组完整的真实信令跟踪截图具体验证了两次调度各自的TB Size7字节与437字节、RNTI类型TC-RNTI与C-RNTI差异以及各自独立的PUCCH HARQ确认反馈机制。至此Msg1到Msg4的完整机制我们都已经系统讲解完毕。下一小节“7.3.3.2.4Msg5 —初始接入完成确认”我们将讨论手机在完成竞争解决之后如何通过Msg5这最后一步向基站正式确认RRC连接建立完成并触发后续NAS层注册流程的完整衔接。