尧图网页设计 
简介这是一份深入讲解5G NR随机接入机制的PDF学习资料适合无线通信初学者、5G研发工程师及备考人员阅读。文档从“为什么要随机接入”出发系统梳理了RACH、UL Grant、C-RNTI、上行同步、TATiming Advance等核心概念并结合GSM/CDMA/LTE对比与师生课堂互动比喻帮助读者理解随机接入在初始接入和RRC_CONNECTED状态下的实际作用。资源为单个PDF文件大小约5.72MB内容紧凑、图文结合便于按自身节奏反复研读。目前已有1193人学习口碑良好。通过该文档读者可快速建立5G NR随机接入的整体知识框架理清PRACH到RAR的完整流程并对TA在维持上行正交性中的意义形成直观认识为进一步学习3GPP协议或从事网络优化工作打下扎实基础。1. 5GNR随机接入的PDF就在手边但真正的坑总在外场这份文档解决的不只是概念拉网测试做到第三轮RSRP显示-82dBmPDSCH的SINR也正常可是UE的ping就是不通。抓了空口日志才发现MSG1发了几十次基站侧一条PRACH检测都没报上来。这种问题翻协议能翻出答案但真正告诉你往哪查的是能把随机接入讲透的资料。手头这份5GNR随机接入的PDF文档把触发条件、两类接入机制、MSG1到MSG4的时序和参数配置串成了一条线适合做基站算法、协议栈开发和外场优化的工程师当作案头手册用。今天把它拆开按我实际配过参数、调过问题的顺序过一遍。2. 触发场景与机制选型先分清竞争、非竞争与两步随机接入随机接入不是只有“开机入网”才会发生。实际上只要UE和基站之间处于失步状态或者需要建立上行同步都会触发随机接入。机制的选型不只是一个“通不通”的问题它直接决定接入时延、PUSCH资源占用、失败后的重试路径。下面把触发场景、竞争机制、两步接入一层层说清楚。2.1 六个触发场景随机接入不是在“接入”时才出现用TS 38.300的视角看随机接入分布在RRC_IDLE、RRC_INACTIVE、RRC_CONNECTED三种状态下。我把实际工程里会遇到的六个触发场景整理成一个表触发场景UE原状态推荐接入类型时延敏感度RRC连接建立初始接入IDLECBRA中RRC连接重建CONNECTEDCBRA高切换HandoverCONNECTEDCFRA优先极高下行数据到达但上行失步CONNECTEDCBRA或CFRA高上行数据到达但上行失步CONNECTEDCBRA高波束失败恢复BFRCONNECTEDCFRA专用资源极高每个场景对参数配置的敏感点不一样。切换和波束失败恢复最怕时延抖动必须优先用CFRA专用preamble。上行失步数据到达的场景基站可能不清楚UE信道质量初始preamble功率不能按保守值配否则要多轮重发。一个经典错误是把所有场景都按“初始接入”配导致切换场景下共享preamble池被大量占用碰撞率抬升切换时延劣化。2.2 CBRA vs CFRA专用与非专用preamble的本质差异竞争随机接入CBRA的完整路径是MSG1到MSG4。UE从小区广播的公共preamble集合里随机选一个。如果多个UE同时选了同一个preamble并在同一时刻发送基站侧的检测窗口里只会看到一个信号峰竞争由此产生要靠MSG3和MSG4把身份区分开。非竞争随机接入CFRA则由基站专门给UE分配一个专用preambleUE在指定PRACH occasion上发不会撞车流程从MSG1到MSG2就结束时延少两跳。我配参数时的选择逻辑如下对比维度CBRACFRApreamble来源小区公共池RRC信令专用分配碰撞风险有无完成流程MSG1到MSG4MSG1加MSG2典型场景初始接入、失步恢复切换、波束失败恢复资源开销低高专用资源稀缺CFRA的实际配置在RRC里是rach-ConfigDedicated里面最关键的两个字段是ra-PreambleIndex和ra-ssb-OccasionMaskIndex。前者指定用哪个专用preamble后者限定UE在哪些SSB波束对应的PRACH occasion上发。现场容易翻车的地方是这两个字段没有跟上行波束状态同步基站按旧波束监听UE按新波束发送MSG2等不到。RRC重配下来后一定要做一次UE侧波束状态检查。2.3 两步随机接入R16的msgA到底省了什么R16的两步随机接入缩短时延的逻辑是MSG A把preamble和PUSCH合并到一次发送里MSG B把RAR和竞争解决合并。也就是说UE一次调度里同时完成“PRACH前导码传输”和“带业务数据的PUSCH传输”。省下来的是原先MSG1到MSG3之间的一次往返。但msgA不是白给的preamble格式要选带“A部分”的变体例如Format A1/A2/A3PUSCH部分要求有独立的时频资源块而且这块资源要和4步的PRACH资源天然分开。配置层面有个参数叫msgA-PUSCH-Config里面包含msgA-PUSCH时域资源分配、频域起始位置、DMRS端口数。如果这些参数和preamble关联的导频端口对不上UE会反复退避。我对2-step的评价是在覆盖好的室内小站和热点区域省时延效果明显在宏站远点msgA的PUSCH解调成功率不够协议允许UE回退到4步回退本身没问题但回退后会撞上4步流程的PRACH负载这时就要把msgA-PRACH和4步PRACH的occasion分开编排。这个细节在避坑章会再强调。3. PRACH配置实战从preamble format到完整RRC参数推导随机接入能不能成半数以上的决定因素在PRACH配置上。配置顺序别乱先定preamble format、再定时域、再定频域、定序列最后把功控参数接上。下面按这个顺序展开。3.1 先定preamble format长序列与短序列的覆盖差异5G NR的preamble分长序列和短序列两大阵营。长序列格式0到3序列长度839子载波间隔1.25kHz或5kHz单个preamble占用时间长能量积累密度高覆盖半径明显更大。短序列格式A/B/C系列序列长度139子载波间隔支持15kHz到60kHz甚至120kHzFR2传输时间短适合城区的短时隙调度和FR2高频段。我在宏站和室分站点里的选型逻辑场景推荐格式理由农村广覆盖宏站format 0 / 1长序列覆盖半径更大城区宏站format A1 / A2短序列调度灵活室分/热点format A1覆盖压力小时延更重要FR2毫米波format B1 / C0短序列支持波束扫描选择format之后要用prach-ConfigurationIndex把时域位置固定下来。同一个format可以对应多个config index不同index的周期和子帧/时隙偏移不同。例如format A1在30kHz SCS下prach-ConfigurationIndex2代表10ms周期、0号时隙起始如果选index3周期还是10ms但偏移到另一个时隙。改变周期会直接影响随机接入容量和时延容量不足时调MSG1-FDM比调周期更高效。3.2 时频位置与序列参数prach-ConfigurationIndex和rootSequenceIndex怎么配prach-ConfigurationIndex是最容易“配错但不报错”的参数。一个多发问题场景是TDD站点如果config index定义的时域位置恰好落在下行时隙或灵活符号上基站侧检测窗口找不到PRACHUE端却认为自己在合法资源上发送。这种问题靠编译期检查发现不了只能拿时隙格式图拉出来人工比对。频域位置由msg1-FrequencyStart和msg1-FDM联合决定。msg1-FrequencyStart表示PRACH在资源块网格上的起点msg1-FDM控制频分复用路数1/2/4/8两者相乘就是PRACH占用的总频带。配的时候要注意别和PUCCH、SRS资源重叠尤其是上行带宽紧张时我一般把PRACH放在带宽两端PUCCH放另一边中间留给PUSCH。序列参数里prach-RootSequenceIndex决定根序列zeroCorrelationZoneConfig决定循环移位间隔。根序列和循环移位共同决定可用preamble数量。L139时根序列0到137每个根序列配合循环移位能生成64个preamble。如果zeroCorrelationZoneConfig选得太大每个根序列的preamble数量减少需要配置多个根序列才够用选得太小序列间相关性上升误检率升高。高速场景必须用受限集合restricted set否则多普勒频移导致相关峰跨循环移位漂移接入成功率断崖式下跌。3.3 一份可落地的PRACH配置实例下面这份配置对应FR1 n78频段、子载波间隔30kHz的典型宏站用RRC的ASN.1片段表达prach-ConfigurationIndex 2, msg1-FDM 4, msg1-FrequencyStart 8, prach-RootSequenceIndex 32, zeroCorrelationZoneConfig 1, ssb-perRACH-Occasion 1, ra-ResponseWindow 8, preambleReceivedTargetPower -100, powerRampingStep 2逐项说prach-ConfigurationIndex2在30kHz SCS下对应format A1PRACH在时隙内占用2个符号周期10ms。msg1-FDM4配合msg1-FrequencyStart8把PRACH频域起点放在资源块8占用4个频域位置总带宽约在低端侧。ssb-perRACH-Occasion1让每个SSB波束拿到独立occasion覆盖多波束场景。preambleReceivedTargetPower-100dBm表示基站希望收到的preamble接收功率powerRampingStep2表示UE每轮重试抬2dB。还有一个关键点SSB和PRACH occasion的映射数量决定了容量。在同一个小区里如果ssb-perRACH-Occasion配置为1/4表示每个SSB对应4个occasion一个波束下的UE全挤在4个PRACH资源里竞争如果配置为4/1表示4个SSB对应1个occasion资源紧张时会有更多碰撞但时延可接受。具体调哪个看现场并发接入量而不是拍脑袋。4. 四步随机接入的逐段拆解MSG1到MSG4的时序与RA-RNTI计算4步随机接入的每一段都有对应的时间窗口和标识符排查的时候一处对不上后面全乱。这章把每一段的关键参数和算法写清楚。4.1 MSG1发送时机SSB与PRACH occasion的映射关系MSG1发送前要选定SSB和PRACH occasion的配对关系。配对由ssb-perRACH-Occasion控制取值1/2/4/8或1/4等分数形式。取值为1时一个SSB对应一个occasion取值为1/4时4个SSB共享一个occasion。这个比值的本质是“波束资源”和“PRACH容量”之间的权衡。ssb-perRACH-Occasion含义容量/覆盖表现1/44个SSB共用一个PRACH occasion容量高碰撞率高1/22个SSB共用一个occasion居中1一个SSB对应一个occasion覆盖好容量低1/8一个SSB对应8个occasion容量高时延低FR2毫米波部署通常希望“一个波束一个资源”因为波束对应的覆盖范围有限UE的波束选择已经做了精确定位PRACH occasion不够会导致接入延时。我调过的一个站点把1/4改成1之后平均接入时延直接降了20ms。4.2 MSG2和MSG3的调度约束rarWindow、TC-RNTI与功控MSG2由基站在RAR窗口内发送窗口从MSG1发送后的第一个下行时隙起长度由ra-ResponseWindow配置。如果基站没在窗口内成功解出preambleUE就会按powerRampingStep抬升功率重发MSG1。这个“抬升-等待-重发”的过程称为功率爬坡最大尝试次数受preambleTransMax限制。MSG3是在RAR上行授权里调度的PUSCH传输。UE这里拿到的临时标识是TC-RNTI后续MSG4竞争解决成功后才升级成C-RNTI。MSG3的调制编码方案MCS和传输块大小由上行的调度DCI控制有些实现里MSG3的MCS是固定低阶的保证解码可靠性。现实中能看到的现象是有些厂商终端在MSG3的PUSCH里携带额外信令如果基站端不支持就会出现“MSG3解到了但MSG4逻辑对不上”的怪现象需要基站侧协议栈放松对MSG3内容的校验。4.3 RA-RNTI计算一行代码算错就满盘皆输RA-RNTI是MSG2的寻址标识一个ROPRACH occasion对应一个RA-RNTI。协议TS 38.321给出的公式是RA-RNTI 1 s_id 14 × t_id 14 × 80 × f_id 14 × 80 × 8 × ul_carrier_ids_id是PRACH occasion的起始符号索引范围0到13t_id是帧内时隙索引以15kHz SCS为基准范围0到79f_id是频域索引范围0到7ul_carrier_id是上行载波标识0代表SUL1代表NUL。如果小区SCS不是15kHzt_id要按15kHz换算例如30kHz SCS下时隙数要乘2。看实际案例我用Python算一个30kHz小区的RA-RNTIdef compute_ra_rnti(s_id, t_id, f_id, ul_carrier_id): # s_id: 0~13, t_id: 基于15kHz的帧内时隙0~79 # f_id: 0~7, ul_carrier_id: 0SUL, 1NUL rnti 1 s_id 14 * t_id 14 * 80 * f_id 14 * 80 * 8 * ul_carrier_id return rnti # 场景1: 符号0, 30kHz下帧内时隙10 - 15kHz基准t_id20, f_id0, NUL print(compute_ra_rnti(0, 20, 0, 1)) # 1 0 14*20 0 8960 9241 # 场景2: 符号9, 时隙5, f_id2, NUL print(compute_ra_rnti(9, 5, 2, 1)) # 1 9 70 2240 8960 11280逻辑说明第二个print展示了符号9、时隙5、频域位置2、NUL下的RA-RNTI为11280第一个print展示了30kHz SCS下标称时隙10要映射到15kHz基准的时隙20。这一步如果不做换算RA-RNTI会差出几百导致UE监听MSG2的PDCCH压根解码不到。对数日志时我习惯先把s_id和t_id标注出来再算避免把时隙号当t_id直接代入。5. 随机接入失败排查五个高频问题的现象、原因与解法随机接入的排查本质是“时序对齐”和“参数一致性”两件事下面五条从现象出发给定位路径都是我在基站侧和外场遇到过的真实问题。5.1 现象MSG1发出去但基站检测不到现象UE侧日志显示preamble已发出发射功率也达到了基站期望值但基站侧PRACH检测记录为零。排查路径先查TDD时隙配置这是占比最高的原因。TDD站点里如果PRACH所在符号被固定成下行或灵活符号基站没法在对应位置做PRACH检测。把prach-ConfigurationIndex对应的时域位置和时隙结构图叠一起人工比对一下。第二常见的是SSB到PRACH occasion的映射错位FR2站点尤其明显UE在波束1上报但映射表让它在波束2的occasion发送。解决核对ssb-perRACH-Occasion映射关系必要时降低该参数让波束和occasion一一对应。5.2 现象MSG3反复重传但一直没等到MSG4现象RAR窗口正常收到MSG2MSG3的HARQ重传次数持续增长但始终没有竞争解决MSG4。排查路径先确认TC-RNTI是否一致MSG3的加扰初始化值必须用TC-RNTI如果实现里错用了C-RNTI基站解码身份一直错位。然后看MSG3的PUSCH资源位置是否和RAR grant一致资源位置冲突时基站解码失败。最后看DMRS端口和preamble的关联这两者不匹配时多UE的MSG3信号在DMRS上混叠谁也解不出来。最常见的还是功控问题上行功率不足直接把MSG3的target power调高3dB再测。5.3 现象波束切换时CFRA专用preamble超时现象波束失败恢复配置了CFRAUE在波束切换后发专用preamble但MSG2窗口超时。排查路径CFRA专用preamble是按波束粒度分配的。波束切换后UE按新波束对应的PRACH occasion发preamble但基站侧还在旧波束的监听窗口内等待二者错开。检查RRC重配里rach-ConfigDedicated是否随波束状态同步更新如果没有立刻重配。另外要看专用preamble索引是否落在小区广播preamble集合范围内如果专用索引和公共集合重复UE实际发送的还是竞争preambleCFRA白配了。5.4 现象2-step随机接入总是回退到4-step现象UE配置了msgA-PRACH和msgA-PUSCH但空口日志显示每次接入都退回4步流程。排查路径msgA的PUSCH时频资源如果被PRACH占用了重叠符号UE在重叠位置无法同时发出preamble和PUSCH自动回退。把msgA-PUSCH的时域起始符号往PRACH之后挪留出保护间隔。第二个原因是基站侧没有开启msgB接收窗口或者msgB窗口太短UE在窗口外收不到msgB也回退。第三个原因是msgA-PRACH的format没有选B系列A系列格式在协议里对msgA的PUSCH时间绑定不友好。逐项核对后回退率基本能压下来。5.5 现象高速场景接入成功率上不去现象高铁/高速场景下UE信号良好但RACH成功率掉到90%以下且失败样本集中在某些小区边缘。排查路径多普勒频移让preamble序列相关峰在循环移位窗口内漂移基站错检到相邻移位上。启用受限集合后前导码的循环移位专门按高速场景设计对频移免疫。配置上就是冻结zeroCorrelationZoneConfig的循环移位集合选择同时换用受限集合专用根序列。这个参数对普通场景影响是负面的不建议全站开启只针对覆盖高速路段的扇区单独下发。6. 验证随机接入是否真的通从空口日志到小区统计的一线习惯前面把配置和流程都过完最后说验证。随机接入是否成功不能只看“UE显示注册完成”要从空口日志和小区统计两条线各过一次。6.1 空口日志看什么RACH attempt到rar的五个字段我在基站侧抓日志时至少核对五个字段preambleId、RA-RNTI、PRACH occasion时隙和符号、RAR窗口内PDCCH的DCI格式、MSG3的TC-RNTI调度记录。先拿preambleId和RA-RNTI和UE侧日志比对再确认MSG2的RAR grant里的UL grant位置和MSG3实际发送位置一致。这个流程能过滤掉八成配置不一致问题。6.2 小区级统计怎么反推瓶颈如果单链路看不出来问题就把小区级RACH成功率按时间段切块。看这个指标总RACH attempt次数、MSG1检测成功数、MSG2发送数、MSG3解码成功数、MSG4完成数。哪一步和上一步之间掉数最大瓶颈就在哪。比如MSG1检测成功率低回头检查PRACH接收功率门限和prach-ConfigurationIndexMSG3解码成功率低重点查DMRS和功控。从那以后我每开一个新站点都会强制过这三步先核对时频参数和时隙结构图再算一次RA-RNTI对照空口日志最后看小区级统计里MSG1到MSG4的掉数差值。这套习惯救过我很多次尤其TDD站点配置容易出符号冲突的暗坑。希望这些经验对你也有用手边那份5GNR随机接入的PDF里时序图和参数表值得再对照一遍消化。本文还有配套的精品资源点击获取 5G NR随机接入实战：PRACH配置、RA-RNTI计算与故障排查
简介这是一份深入讲解5G NR随机接入机制的PDF学习资料适合无线通信初学者、5G研发工程师及备考人员阅读。文档从“为什么要随机接入”出发系统梳理了RACH、UL Grant、C-RNTI、上行同步、TATiming Advance等核心概念并结合GSM/CDMA/LTE对比与师生课堂互动比喻帮助读者理解随机接入在初始接入和RRC_CONNECTED状态下的实际作用。资源为单个PDF文件大小约5.72MB内容紧凑、图文结合便于按自身节奏反复研读。目前已有1193人学习口碑良好。通过该文档读者可快速建立5G NR随机接入的整体知识框架理清PRACH到RAR的完整流程并对TA在维持上行正交性中的意义形成直观认识为进一步学习3GPP协议或从事网络优化工作打下扎实基础。1. 5GNR随机接入的PDF就在手边但真正的坑总在外场这份文档解决的不只是概念拉网测试做到第三轮RSRP显示-82dBmPDSCH的SINR也正常可是UE的ping就是不通。抓了空口日志才发现MSG1发了几十次基站侧一条PRACH检测都没报上来。这种问题翻协议能翻出答案但真正告诉你往哪查的是能把随机接入讲透的资料。手头这份5GNR随机接入的PDF文档把触发条件、两类接入机制、MSG1到MSG4的时序和参数配置串成了一条线适合做基站算法、协议栈开发和外场优化的工程师当作案头手册用。今天把它拆开按我实际配过参数、调过问题的顺序过一遍。2. 触发场景与机制选型先分清竞争、非竞争与两步随机接入随机接入不是只有“开机入网”才会发生。实际上只要UE和基站之间处于失步状态或者需要建立上行同步都会触发随机接入。机制的选型不只是一个“通不通”的问题它直接决定接入时延、PUSCH资源占用、失败后的重试路径。下面把触发场景、竞争机制、两步接入一层层说清楚。2.1 六个触发场景随机接入不是在“接入”时才出现用TS 38.300的视角看随机接入分布在RRC_IDLE、RRC_INACTIVE、RRC_CONNECTED三种状态下。我把实际工程里会遇到的六个触发场景整理成一个表触发场景UE原状态推荐接入类型时延敏感度RRC连接建立初始接入IDLECBRA中RRC连接重建CONNECTEDCBRA高切换HandoverCONNECTEDCFRA优先极高下行数据到达但上行失步CONNECTEDCBRA或CFRA高上行数据到达但上行失步CONNECTEDCBRA高波束失败恢复BFRCONNECTEDCFRA专用资源极高每个场景对参数配置的敏感点不一样。切换和波束失败恢复最怕时延抖动必须优先用CFRA专用preamble。上行失步数据到达的场景基站可能不清楚UE信道质量初始preamble功率不能按保守值配否则要多轮重发。一个经典错误是把所有场景都按“初始接入”配导致切换场景下共享preamble池被大量占用碰撞率抬升切换时延劣化。2.2 CBRA vs CFRA专用与非专用preamble的本质差异竞争随机接入CBRA的完整路径是MSG1到MSG4。UE从小区广播的公共preamble集合里随机选一个。如果多个UE同时选了同一个preamble并在同一时刻发送基站侧的检测窗口里只会看到一个信号峰竞争由此产生要靠MSG3和MSG4把身份区分开。非竞争随机接入CFRA则由基站专门给UE分配一个专用preambleUE在指定PRACH occasion上发不会撞车流程从MSG1到MSG2就结束时延少两跳。我配参数时的选择逻辑如下对比维度CBRACFRApreamble来源小区公共池RRC信令专用分配碰撞风险有无完成流程MSG1到MSG4MSG1加MSG2典型场景初始接入、失步恢复切换、波束失败恢复资源开销低高专用资源稀缺CFRA的实际配置在RRC里是rach-ConfigDedicated里面最关键的两个字段是ra-PreambleIndex和ra-ssb-OccasionMaskIndex。前者指定用哪个专用preamble后者限定UE在哪些SSB波束对应的PRACH occasion上发。现场容易翻车的地方是这两个字段没有跟上行波束状态同步基站按旧波束监听UE按新波束发送MSG2等不到。RRC重配下来后一定要做一次UE侧波束状态检查。2.3 两步随机接入R16的msgA到底省了什么R16的两步随机接入缩短时延的逻辑是MSG A把preamble和PUSCH合并到一次发送里MSG B把RAR和竞争解决合并。也就是说UE一次调度里同时完成“PRACH前导码传输”和“带业务数据的PUSCH传输”。省下来的是原先MSG1到MSG3之间的一次往返。但msgA不是白给的preamble格式要选带“A部分”的变体例如Format A1/A2/A3PUSCH部分要求有独立的时频资源块而且这块资源要和4步的PRACH资源天然分开。配置层面有个参数叫msgA-PUSCH-Config里面包含msgA-PUSCH时域资源分配、频域起始位置、DMRS端口数。如果这些参数和preamble关联的导频端口对不上UE会反复退避。我对2-step的评价是在覆盖好的室内小站和热点区域省时延效果明显在宏站远点msgA的PUSCH解调成功率不够协议允许UE回退到4步回退本身没问题但回退后会撞上4步流程的PRACH负载这时就要把msgA-PRACH和4步PRACH的occasion分开编排。这个细节在避坑章会再强调。3. PRACH配置实战从preamble format到完整RRC参数推导随机接入能不能成半数以上的决定因素在PRACH配置上。配置顺序别乱先定preamble format、再定时域、再定频域、定序列最后把功控参数接上。下面按这个顺序展开。3.1 先定preamble format长序列与短序列的覆盖差异5G NR的preamble分长序列和短序列两大阵营。长序列格式0到3序列长度839子载波间隔1.25kHz或5kHz单个preamble占用时间长能量积累密度高覆盖半径明显更大。短序列格式A/B/C系列序列长度139子载波间隔支持15kHz到60kHz甚至120kHzFR2传输时间短适合城区的短时隙调度和FR2高频段。我在宏站和室分站点里的选型逻辑场景推荐格式理由农村广覆盖宏站format 0 / 1长序列覆盖半径更大城区宏站format A1 / A2短序列调度灵活室分/热点format A1覆盖压力小时延更重要FR2毫米波format B1 / C0短序列支持波束扫描选择format之后要用prach-ConfigurationIndex把时域位置固定下来。同一个format可以对应多个config index不同index的周期和子帧/时隙偏移不同。例如format A1在30kHz SCS下prach-ConfigurationIndex2代表10ms周期、0号时隙起始如果选index3周期还是10ms但偏移到另一个时隙。改变周期会直接影响随机接入容量和时延容量不足时调MSG1-FDM比调周期更高效。3.2 时频位置与序列参数prach-ConfigurationIndex和rootSequenceIndex怎么配prach-ConfigurationIndex是最容易“配错但不报错”的参数。一个多发问题场景是TDD站点如果config index定义的时域位置恰好落在下行时隙或灵活符号上基站侧检测窗口找不到PRACHUE端却认为自己在合法资源上发送。这种问题靠编译期检查发现不了只能拿时隙格式图拉出来人工比对。频域位置由msg1-FrequencyStart和msg1-FDM联合决定。msg1-FrequencyStart表示PRACH在资源块网格上的起点msg1-FDM控制频分复用路数1/2/4/8两者相乘就是PRACH占用的总频带。配的时候要注意别和PUCCH、SRS资源重叠尤其是上行带宽紧张时我一般把PRACH放在带宽两端PUCCH放另一边中间留给PUSCH。序列参数里prach-RootSequenceIndex决定根序列zeroCorrelationZoneConfig决定循环移位间隔。根序列和循环移位共同决定可用preamble数量。L139时根序列0到137每个根序列配合循环移位能生成64个preamble。如果zeroCorrelationZoneConfig选得太大每个根序列的preamble数量减少需要配置多个根序列才够用选得太小序列间相关性上升误检率升高。高速场景必须用受限集合restricted set否则多普勒频移导致相关峰跨循环移位漂移接入成功率断崖式下跌。3.3 一份可落地的PRACH配置实例下面这份配置对应FR1 n78频段、子载波间隔30kHz的典型宏站用RRC的ASN.1片段表达prach-ConfigurationIndex 2, msg1-FDM 4, msg1-FrequencyStart 8, prach-RootSequenceIndex 32, zeroCorrelationZoneConfig 1, ssb-perRACH-Occasion 1, ra-ResponseWindow 8, preambleReceivedTargetPower -100, powerRampingStep 2逐项说prach-ConfigurationIndex2在30kHz SCS下对应format A1PRACH在时隙内占用2个符号周期10ms。msg1-FDM4配合msg1-FrequencyStart8把PRACH频域起点放在资源块8占用4个频域位置总带宽约在低端侧。ssb-perRACH-Occasion1让每个SSB波束拿到独立occasion覆盖多波束场景。preambleReceivedTargetPower-100dBm表示基站希望收到的preamble接收功率powerRampingStep2表示UE每轮重试抬2dB。还有一个关键点SSB和PRACH occasion的映射数量决定了容量。在同一个小区里如果ssb-perRACH-Occasion配置为1/4表示每个SSB对应4个occasion一个波束下的UE全挤在4个PRACH资源里竞争如果配置为4/1表示4个SSB对应1个occasion资源紧张时会有更多碰撞但时延可接受。具体调哪个看现场并发接入量而不是拍脑袋。4. 四步随机接入的逐段拆解MSG1到MSG4的时序与RA-RNTI计算4步随机接入的每一段都有对应的时间窗口和标识符排查的时候一处对不上后面全乱。这章把每一段的关键参数和算法写清楚。4.1 MSG1发送时机SSB与PRACH occasion的映射关系MSG1发送前要选定SSB和PRACH occasion的配对关系。配对由ssb-perRACH-Occasion控制取值1/2/4/8或1/4等分数形式。取值为1时一个SSB对应一个occasion取值为1/4时4个SSB共享一个occasion。这个比值的本质是“波束资源”和“PRACH容量”之间的权衡。ssb-perRACH-Occasion含义容量/覆盖表现1/44个SSB共用一个PRACH occasion容量高碰撞率高1/22个SSB共用一个occasion居中1一个SSB对应一个occasion覆盖好容量低1/8一个SSB对应8个occasion容量高时延低FR2毫米波部署通常希望“一个波束一个资源”因为波束对应的覆盖范围有限UE的波束选择已经做了精确定位PRACH occasion不够会导致接入延时。我调过的一个站点把1/4改成1之后平均接入时延直接降了20ms。4.2 MSG2和MSG3的调度约束rarWindow、TC-RNTI与功控MSG2由基站在RAR窗口内发送窗口从MSG1发送后的第一个下行时隙起长度由ra-ResponseWindow配置。如果基站没在窗口内成功解出preambleUE就会按powerRampingStep抬升功率重发MSG1。这个“抬升-等待-重发”的过程称为功率爬坡最大尝试次数受preambleTransMax限制。MSG3是在RAR上行授权里调度的PUSCH传输。UE这里拿到的临时标识是TC-RNTI后续MSG4竞争解决成功后才升级成C-RNTI。MSG3的调制编码方案MCS和传输块大小由上行的调度DCI控制有些实现里MSG3的MCS是固定低阶的保证解码可靠性。现实中能看到的现象是有些厂商终端在MSG3的PUSCH里携带额外信令如果基站端不支持就会出现“MSG3解到了但MSG4逻辑对不上”的怪现象需要基站侧协议栈放松对MSG3内容的校验。4.3 RA-RNTI计算一行代码算错就满盘皆输RA-RNTI是MSG2的寻址标识一个ROPRACH occasion对应一个RA-RNTI。协议TS 38.321给出的公式是RA-RNTI 1 s_id 14 × t_id 14 × 80 × f_id 14 × 80 × 8 × ul_carrier_ids_id是PRACH occasion的起始符号索引范围0到13t_id是帧内时隙索引以15kHz SCS为基准范围0到79f_id是频域索引范围0到7ul_carrier_id是上行载波标识0代表SUL1代表NUL。如果小区SCS不是15kHzt_id要按15kHz换算例如30kHz SCS下时隙数要乘2。看实际案例我用Python算一个30kHz小区的RA-RNTIdef compute_ra_rnti(s_id, t_id, f_id, ul_carrier_id): # s_id: 0~13, t_id: 基于15kHz的帧内时隙0~79 # f_id: 0~7, ul_carrier_id: 0SUL, 1NUL rnti 1 s_id 14 * t_id 14 * 80 * f_id 14 * 80 * 8 * ul_carrier_id return rnti # 场景1: 符号0, 30kHz下帧内时隙10 - 15kHz基准t_id20, f_id0, NUL print(compute_ra_rnti(0, 20, 0, 1)) # 1 0 14*20 0 8960 9241 # 场景2: 符号9, 时隙5, f_id2, NUL print(compute_ra_rnti(9, 5, 2, 1)) # 1 9 70 2240 8960 11280逻辑说明第二个print展示了符号9、时隙5、频域位置2、NUL下的RA-RNTI为11280第一个print展示了30kHz SCS下标称时隙10要映射到15kHz基准的时隙20。这一步如果不做换算RA-RNTI会差出几百导致UE监听MSG2的PDCCH压根解码不到。对数日志时我习惯先把s_id和t_id标注出来再算避免把时隙号当t_id直接代入。5. 随机接入失败排查五个高频问题的现象、原因与解法随机接入的排查本质是“时序对齐”和“参数一致性”两件事下面五条从现象出发给定位路径都是我在基站侧和外场遇到过的真实问题。5.1 现象MSG1发出去但基站检测不到现象UE侧日志显示preamble已发出发射功率也达到了基站期望值但基站侧PRACH检测记录为零。排查路径先查TDD时隙配置这是占比最高的原因。TDD站点里如果PRACH所在符号被固定成下行或灵活符号基站没法在对应位置做PRACH检测。把prach-ConfigurationIndex对应的时域位置和时隙结构图叠一起人工比对一下。第二常见的是SSB到PRACH occasion的映射错位FR2站点尤其明显UE在波束1上报但映射表让它在波束2的occasion发送。解决核对ssb-perRACH-Occasion映射关系必要时降低该参数让波束和occasion一一对应。5.2 现象MSG3反复重传但一直没等到MSG4现象RAR窗口正常收到MSG2MSG3的HARQ重传次数持续增长但始终没有竞争解决MSG4。排查路径先确认TC-RNTI是否一致MSG3的加扰初始化值必须用TC-RNTI如果实现里错用了C-RNTI基站解码身份一直错位。然后看MSG3的PUSCH资源位置是否和RAR grant一致资源位置冲突时基站解码失败。最后看DMRS端口和preamble的关联这两者不匹配时多UE的MSG3信号在DMRS上混叠谁也解不出来。最常见的还是功控问题上行功率不足直接把MSG3的target power调高3dB再测。5.3 现象波束切换时CFRA专用preamble超时现象波束失败恢复配置了CFRAUE在波束切换后发专用preamble但MSG2窗口超时。排查路径CFRA专用preamble是按波束粒度分配的。波束切换后UE按新波束对应的PRACH occasion发preamble但基站侧还在旧波束的监听窗口内等待二者错开。检查RRC重配里rach-ConfigDedicated是否随波束状态同步更新如果没有立刻重配。另外要看专用preamble索引是否落在小区广播preamble集合范围内如果专用索引和公共集合重复UE实际发送的还是竞争preambleCFRA白配了。5.4 现象2-step随机接入总是回退到4-step现象UE配置了msgA-PRACH和msgA-PUSCH但空口日志显示每次接入都退回4步流程。排查路径msgA的PUSCH时频资源如果被PRACH占用了重叠符号UE在重叠位置无法同时发出preamble和PUSCH自动回退。把msgA-PUSCH的时域起始符号往PRACH之后挪留出保护间隔。第二个原因是基站侧没有开启msgB接收窗口或者msgB窗口太短UE在窗口外收不到msgB也回退。第三个原因是msgA-PRACH的format没有选B系列A系列格式在协议里对msgA的PUSCH时间绑定不友好。逐项核对后回退率基本能压下来。5.5 现象高速场景接入成功率上不去现象高铁/高速场景下UE信号良好但RACH成功率掉到90%以下且失败样本集中在某些小区边缘。排查路径多普勒频移让preamble序列相关峰在循环移位窗口内漂移基站错检到相邻移位上。启用受限集合后前导码的循环移位专门按高速场景设计对频移免疫。配置上就是冻结zeroCorrelationZoneConfig的循环移位集合选择同时换用受限集合专用根序列。这个参数对普通场景影响是负面的不建议全站开启只针对覆盖高速路段的扇区单独下发。6. 验证随机接入是否真的通从空口日志到小区统计的一线习惯前面把配置和流程都过完最后说验证。随机接入是否成功不能只看“UE显示注册完成”要从空口日志和小区统计两条线各过一次。6.1 空口日志看什么RACH attempt到rar的五个字段我在基站侧抓日志时至少核对五个字段preambleId、RA-RNTI、PRACH occasion时隙和符号、RAR窗口内PDCCH的DCI格式、MSG3的TC-RNTI调度记录。先拿preambleId和RA-RNTI和UE侧日志比对再确认MSG2的RAR grant里的UL grant位置和MSG3实际发送位置一致。这个流程能过滤掉八成配置不一致问题。6.2 小区级统计怎么反推瓶颈如果单链路看不出来问题就把小区级RACH成功率按时间段切块。看这个指标总RACH attempt次数、MSG1检测成功数、MSG2发送数、MSG3解码成功数、MSG4完成数。哪一步和上一步之间掉数最大瓶颈就在哪。比如MSG1检测成功率低回头检查PRACH接收功率门限和prach-ConfigurationIndexMSG3解码成功率低重点查DMRS和功控。从那以后我每开一个新站点都会强制过这三步先核对时频参数和时隙结构图再算一次RA-RNTI对照空口日志最后看小区级统计里MSG1到MSG4的掉数差值。这套习惯救过我很多次尤其TDD站点配置容易出符号冲突的暗坑。希望这些经验对你也有用手边那份5GNR随机接入的PDF里时序图和参数表值得再对照一遍消化。本文还有配套的精品资源点击获取