本节课程视频7.3.2.3.1.1 先回答一个最关键的问题谁在UE内部“决定”发起随机接入在无线系统中“UE发送PRACH”是一个物理层可观察到的结果但真正的触发原因通常来自更高层的连接需求或RAN内部状态事件。因此不能简单地说“应用层直接触发PRACH”也不能说“PHY自己决定发送PRACH”。更准确的理解是上层产生接入/连接需求RRC根据UE状态决定是否需要建立RRC连接并形成相应控制消息随后下层在没有可用上行传输条件时通过MAC的随机接入机制获得上行发送机会最终由PHY执行PRACH发送。图7.3.2.3.1-1 UE内部初始化随机接入的典型触发链这条链路可以浓缩为一条主线上层需求→ RRC连接建立触发→ RRCSetupRequest准备→ MAC需要获得UL传输机会→ Random Access → PHY发送PRACH/Preamble7.3.2.3.1.2 为什么要从“上层需求”开始看5G终端并不是一块只会发送无线信号的PHY芯片而是一个完整的计算与通信系统。用户开机、发起业务、系统服务需要联网等事件首先表现为终端内部的软件状态和协议状态变化。对于初始接入场景上层的连接需求最终需要转化为RRC连接建立而RRC连接建立又必须借助底层无线资源才能真正通过空口发送出去。因此在分析“随机接入从哪里开始”时最有价值的不是直接寻找第一条PRACH波形而是沿着控制面的因果链向上追为什么RRC要建立连接RRC为什么产生RRCSetupRequest为什么这个消息又需要MAC提供UL-SCH传输机会如果当前没有已建立的上行资源MAC为什么需要启动Random Access应用/系统服务层产生联网需求或连接需求具体触发来源取决于终端软件实现。NAS在需要与核心网进行注册等控制交互时形成NAS消息例如Registration Request。RRC负责无线连接控制在RRC_IDLE等相应状态下按照规范建立RRC连接并准备RRCSetupRequest。MAC负责无线接入和共享信道资源相关的过程当RRC的上行CCCH消息没有现成UL资源可用时可以通过Random Access获得初始上行传输条件。PHY按照高层提供的RACH/PRACH参数执行物理层随机接入包括Preamble发送。7.3.2.3.1.3 AP、BP与RF协议层如何落到手机硬件从工程实现角度手机常被粗略划分为APApplication Processor、BP/Modem/Baseband基带处理部分和RFRadio Frequency部分。这种划分非常适合解释QXDM等Modem日志但必须注意AP/BP/RF不是3GPP规定的协议层名称具体芯片可能采用不同的集成方式有的SoC会把应用处理、Modem以及其他功能高度集成。图7.3.2.3.1-2典型手机AP、BP与RF硬件/软件功能关系示意AP运行操作系统和应用/系统服务是终端计算与业务呈现的重要部分。BP/Modem通常承载蜂窝通信协议栈和基带处理功能包括NAS、RRC、PDCP、RLC、MAC以及PHY相关处理具体划分依芯片实现而定。RF负责射频信号的收发及模拟/射频链路处理与基带数字处理形成完整的无线收发链。AP与Modem之间通常存在厂商定义的接口机制在Android生态中常见RIL相关软件接口但不能把RIL理解为3GPP空口协议层。教学边界后续分析QXDM时可以把“LOG出现在哪个模块”作为定位线索但不要据此推断3GPP协议职责。例如某条LOG名称包含RACH Trigger并不意味着3GPP定义了一条名为“RACH Trigger”的空口消息它很可能只是芯片内部MAC事件。7.3.2.3.1.4 NAS Registration Request究竟怎样参与随机接入触发初始入网时一个常见的逻辑场景是UE需要完成5GS注册因此NAS层产生Registration Request。这个NAS消息最终需要经由RAN承载到AMF等核心网实体。但是此时UE可能还处于RRC_IDLE并没有用于承载该NAS消息的已建立专用无线承载。于是必须先建立RRC连接。图7.3.2.3.1-3从上层NAS需求到RRC/MAC/PHY的层间关系这里需要把两个概念严格分开第一Registration Request是NAS消息第二RRCSetupRequest是RRC消息。前者表达的是UE向核心网发起注册相关请求后者是UE向无线接入网请求建立RRC连接的控制消息。两者可能在同一次初始接入链路中前后出现但它们属于不同协议层目的也不同。在典型初始接入中UE的RRC层根据上层请求启动RRC连接建立过程并按照RRC规范准备RRCSetupRequest。由于RRCSetupRequest需要通过CCCH在上行无线链路上传输而UE在RRC_IDLE初始接入时并没有可直接使用的专用UL-SCH资源因此下层需要解决“第一次上行怎么发”的问题这就是Random Access发挥作用的地方。纠正一个常见说法不应简单表述为“NAS直接命令MAC发随机接入”或“应用层直接命令PHY发PRACH”。更准确的协议关系是上层连接需求触发RRC连接建立RRC准备RRCSetupRequest并请求下层传输MAC在需要建立上行传输机会时启动Random AccessPHY再执行PRACH。7.3.2.3.1.5 RRCSetupRequest为什么不能“直接发”这是理解本节最重要的逻辑之一。RRCSetupRequest虽然属于RRC层但RRC层的消息并不是脱离MAC和PHY独立存在的。最终它必须被映射到无线物理资源上通过空口传给gNB。RRC生成RRCSetupRequest消息内容由RRC过程决定并使用CCCH逻辑信道。消息交给下层RRC请求下层为该上行控制消息提供传输。MAC检查可用上行条件如果UE已经存在可以直接使用的UL-SCH资源则可以走相应的普通上行传输在典型初始接入场景中UE通常没有这样的专用UL资源。启动Random AccessMAC通过RA过程建立初始的上行发送机会并获得后续所需的控制参数。PHY执行PRACHMAC/高层提供的参数最终落实到物理层UE在合法PRACH Occasion发送随机接入前导码。RA成功后的后续UL获得初始上行授权和时序调整等条件后UE才能发送后续的上行控制/数据例如承载RRCSetupRequest的Msg3在典型四步RA场景下。这里“RA为RRCSetupRequest开路”是一个很好的教学比喻但它不是说RRCSetupRequest被封装进PRACH。PRACH只承载随机接入前导码在典型四步RA中RRCSetupRequest是在后续获得UL Grant后通过PUSCH对应的上行传输发送。7.3.2.3.1.6 QXDM日志如何从时间戳证明触发链图7.3.2.3.1-4典型QXDM日志中的初始接入触发时序原始日志中可以看到几个非常有价值的相邻事件NAS Plain Message Container中的Registration Request、UL_CCCH / RRC Setup Req以及随后出现的NR5G MAC RACH Trigger。对于教学和测试而言这组日志非常适合用来建立“上层需求已经产生 → RRC连接建立过程启动 → MAC进入随机接入准备”的时间关联。图7.3.2.3.1-5将QXDM时间戳转换为UE内部触发因果链但是日志分析必须保持一个原则**LOG事件名称不是空口协议消息名称。** 例如“NR5G MAC RACH Trigger”更像是Modem内部MAC状态机/事件记录真正的空口随机接入信号是PRACH上的Random Access Preamble。先确认事件发生时间建立严格的时间顺序。再确认事件所属层NAS、RRC、MAC、PHY还是RF。然后寻找对应的空口结果是否出现PRACH发送、是否有RAR相关PDCCH/PDSCH等。最后把UE侧与gNB侧日志对齐UE说“trigger”不等于gNB已经“detect”。7.3.2.3.1.7 “触发”与“执行”必须分开阶段谁负责/主要位置典型事件或信息本阶段回答的问题需求产生上层/NAS/RRC业务需求、Registration Request、RRC connection establishment request为什么需要连接RRC消息准备RRCRRCSetupRequest要通过无线发送什么RA触发MAC/RRC相关下层过程Random Access trigger没有UL资源时怎样获得首次上行机会RA物理执行PHY/RFPRACH/Preamble transmission怎样把接入尝试真正发到空口后续上行MAC/PHYRAR UL Grant对应的PUSCH等怎样发送后续连接建立消息7.3.2.3.1.8 触发机制中的“状态”比“开机按钮”更重要教材中常把“手机开机”作为初始接入的起点但从协议实现角度“开机”只是导致状态变化的一种外部事件。真正决定RRC是否启动连接建立过程的是UE当前RRC状态、系统信息是否有效、接入控制是否允许以及上层是否存在连接需求等协议条件。例如在RRC_IDLE状态下上层请求建立RRC连接时RRC会执行相应的接入控制和连接建立动作而在其他RRC状态或其他无线过程场景中Random Access也可能被不同的事件触发。因此分析“RA trigger”时最好问的是**UE当时处于什么状态是什么事件改变了这个状态RRC为什么需要UL传输MAC为什么没有现成UL资源**UE状态RRC_IDLE、RRC_INACTIVE、RRC_CONNECTED等。系统信息是否已经获得并保持有效的必要系统信息。接入控制是否满足当前接入类别/接入身份等限制。无线资源是否存在可以直接用于所需上行传输的资源。RAN内部事件例如某些连接恢复、切换、波束恢复等场景也可能触发RA具体场景应按对应规范过程判断。7.3.2.3.1.9 为什么“上层触发”与“MAC触发”不能混为一谈从规范视角Random Access procedure的初始化可以由PDCCH order、MAC实体自身或者RRC触发具体触发条件由NR整体过程定义。对于本节关注的初始接入场景最典型的教学链路是“上层需要建立RRC连接 → RRC连接建立过程启动 → 下层需要上行资源 → MAC进入Random Access”。因此如果在QXDM中看到MAC RACH Trigger应该理解为“MAC实体已经进入随机接入过程的实现事件”而不是说MAC第一次知道UE要联网。前面的需求和RRC连接建立状态变化通常已经提供了更高层背景。规范层面的精确表述3GPP TS 38.321定义Random Access procedure的初始化可以由PDCCH order、MAC entity本身或RRC触发UE的RRC连接建立过程则在RRC规范中定义并要求UE准备RRCSetupRequest。这样可以同时解释“RA由谁触发”和“为什么初始接入中会出现RA”。7.3.2.3.1.10 一个完整的初始接入触发案例假设UE开机后已经完成小区选择并获得了必要的系统信息。用户此时没有打开任何具体业务但终端需要执行5GS注册。下面用一个抽象案例把内部触发链完整串起来。UE完成小区选择并进入适合进行后续接入的状态。上层/移动性管理相关软件产生注册需求NAS准备Registration Request。UE需要建立RRC连接才能把后续NAS消息通过无线接入网传送到核心网。RRC层启动RRC连接建立过程并准备RRCSetupRequest。RRCSetupRequest需要通过CCCH进行上行传输UE此时没有可以直接使用的专用上行资源。下层因此启动Random AccessMAC根据RACH公共配置准备随机接入。PHY在相应PRACH Occasion执行Preamble发送。gNB检测到PRACH后继续执行随机接入响应过程UE获得后续上行发送所需的条件。UE随后可以通过获得的上行资源发送RRCSetupRequest等后续消息RRC连接建立继续向前推进。RRC连接建立后NAS消息才有了可依托的无线承载/连接路径继续完成与核心网相关的注册过程。这个案例最值得记住的是**Registration Request是业务/核心网注册需求的表现RRCSetupRequest是无线连接建立需求的表现PRACH是建立首次上行接触的物理入口。** 三者处于不同层次但在初始接入时间线上存在紧密的因果关系。7.3.2.3.1.11 实际测试中的故障定位方法现象首先检查进一步检查不要直接下结论没有RACH Trigger上层/NAS/RRC状态是否存在RRC连接建立请求、接入是否被禁止不是先怀疑RF有RACH Trigger但无PRACHMAC→PHY接口、RACH配置PRACH Occasion、PHY调度、RF TX链路Trigger不等于实际发射有PRACH但gNB未检测UE/gNB时间、频率、功率、PRACH配置SCS、format、RO、preamble、RF链路不能只看UE“TX OK”gNB检测PRACH但无RARgNB PRACH detector、RAR调度RA-RNTI、PDCCH/PDSCH、RAR window不是一定说明UE PRACH有问题RAR后Msg3失败TA、UL Grant、PUSCHPUSCH解调、功控、UL timing、RRC消息不能把问题归结为PRACH7.3.2.3.1.12 本节容易出现的概念错误容易形成的错误认识准确理解“NAS直接触发PRACH”更准确上层需求可触发RRC连接建立Random Access由RRC/MAC相关机制启动PHY执行PRACH。“RRCSetupRequest就在PRACH里发送”不准确。在典型四步RA中PRACH承载的是PreambleRRCSetupRequest属于后续上行传输。“MAC产生RRCSetupRequest”不准确。RRC消息由RRC层产生/准备MAC负责其下层传输所需的资源与过程。“MAC RACH Trigger就是空口消息”不准确。它通常是终端内部日志/事件空口上的随机接入前导码才是实际无线传输。“应用层直接控制基带发射”过度简化。真实商用UE存在多层软件接口、状态机和厂商实现应用通常不能直接控制PHY。“看到Registration Request就一定马上PRACH”过度绝对化。实际实现还受到RRC状态、系统信息有效性、接入控制以及当前无线资源等条件影响。“随机接入只发生在开机时”不准确。NR的RA还用于多种其他无线过程本节只聚焦初始化/初始接入触发。