简介一册聚焦5G NR PRACH接入信号规划的专业技术文档面向5G网络优化、无线接入网规划与运维工程师。文档系统讲解了PRACH随机接入的核心原理涵盖Preamble序列的Zadoff-Chu生成机制、long/short前导格式Format 0/1/2/3与A/B/C系列的适用场景以及CP循环前缀和GP保护间隔对小区覆盖半径的影响。同时结合实际部署介绍相邻小区根序列规划、ZC根分配索引与Ncs循环移位配置阐述PRACH参数精细化调整方法以降低随机接入冲突、提升UE接入性能。资源为单份PDF文档共1个文件压缩包大小2.22MB内容详实、结构完整便于系统学习与随时查阅。已有647人学习下载适合希望深入理解5G接入流程并提升网络优化技能的工程技术人员。1. 5G NR PRACH接入信号规划为什么说它是无线网络优化里最容易被低估的一环一张5G工参表里的PRACH参数随便填和认真规划指标差距能到几个百分点。我拆过一份某厂商系5G PRACH规划讨论材料里面反复强调一个观点随机接入是UE与基站建立物理连接的第一道门而5G NR PRACH的Preamble怎么生成、格式怎么选、根序列怎么分直接决定接入时延、覆盖半径和网络容量。曾有个站点RRC建立成功率一直掉在99%以下无线环境正常、干扰也不高最后定位到邻区PRACH的format、根序列和频域起点全撞在一起前导虚检把基站处理资源吃掉大半。这份资料把PRACH规划从ZC序列原理讲到了64个Preamble的完整生成、频时域配置和邻区协调适合做5G网络优化、接入参数核查和验收测试的人按步骤能把一套PRACH规划手推下来。2. Preamble结构与格式选型长码839和短码139把覆盖半径写进了CP和GP2.1 一个Preamble的三段式CP、ZC序列、GP分别扛什么PRACH的Preamble在时域上由三部分组成循环前缀CP、前导序列、保护间隔GP。很多人只看前导序列本身的长度忽略了CP和GP才是决定覆盖半径的关键。CP的作用是抵消多径传播造成的时延差防止符号间干扰GP的作用是防止相邻小区的PRACH信号在时间上重叠同时给UE切换收发留出余量。时延一大基站就可能把上一个符号的尾巴误认为下一个符号的头造成误识别。从数学角度看Preamble序列是长度为LRA的Zadoff-Chu序列LRA取839或139对应长码和短码。ZC序列的核心性质是恒包络和理想循环自相关这保证基站做相关检测时峰值尖锐抗干扰能力强。序列本身并不直接决定覆盖半径真正决定覆盖的是CP和GP的时间长度——CP和GP设置得越大符号越不容易混淆小区覆盖半径才能做得越大。这是整个PRACH规划里最基础的一条判断依据。2.2 长码四种Format对照常规、超远、弱覆盖、超高速长码用的是839长度的ZC序列子载波间隔低单个符号时间长适合做覆盖。协议定义了format 0到3四种格式每种格式的CP和GP长度都不同。资料里给了一张最大小区半径和适用场景的对照表下面是我整理后的精简版。格式子载波间隔(kHz)CP对应半径(km)GP对应半径(km)最大小区半径(km)适用场景format 01.2515.4714.5314.53常规覆盖format 11.25102.66107.34102.66超远覆盖format 21.2522.86142.7222.86弱覆盖format 3515.4714.5314.53超高速注意到一个规律最大小区半径取的是CP和GP折算半径里的较小值。format 0的CP折算半径15.47km比GP折算半径14.53km大所以最终覆盖半径被GP限制在14.53km。format 2正好反过来GP折算半径有142.72km但CP只有22.86km覆盖半径被CP卡住。选格式时不能只看SCS或序列长度得把CP和GP两个维度都查一遍。format 1的102.66km是长码里的极限覆盖格式适合海面、湖面、草原这类超远覆盖场景。format 3虽然最大半径只有14.53km但子载波间隔提高到5kHz抗多普勒频移能力强用在高铁这类超高速场景。实际部署中format 0用得最多常规宏站基本都从它开始选。2.3 短码A/B/C系列选型与设备支持边界短码用139长度的ZC序列子载波间隔更大符号时间短天然适合小覆盖和低时延场景。短码格式分成A1/A2/A3、B1/B2/B3/B4、C0/C2九种资料里也给了每种格式在30kHz子载波间隔下的覆盖半径。我把有代表性的几档列出来。格式最大小区半径(km)适用定位A10.47Small CellA21.05Normal CellA31.76Normal CellB10.18Small CellC02.70Normal CellC22.67Normal Cell短码选型有一条实际经验密集城区一般用B系列郊区用C系列。原因是B系列的CP和GP相对紧凑时域资源占用少单位时间内能塞进更多PRACH机会适合用户密集、接入频繁的城区C系列覆盖半径更大适合郊区这种对时延不敏感但对覆盖有要求的场景。A系列里的A1和B1主要面向Small Cell半径压到500米以内很多室分站、微站会选这两档。这里有一个重要的设备边界资料里明确提到某厂商5G RAN2.1版本只支持format 0和C2两种前导格式。也就是说软件版本不同协议允许的格式不一定在设备上都能配。做规划前先确认基站版本支持哪些格式否则方案做得再漂亮到工参配置那一步就卡住了。3. 根序列规划与Ncs计算从时延预算到64个Preamble生成3.1 ZC序列的两个自由度root sequence number和cyclic shift终端要根据配置参数生成64个Preamble也就是64个序列。产生不同序列有两种方法一种是用不同的root sequence number在ZC公式里换不同的u值另一种是基于同一个root sequence number做循环移位改变Cv值。两者可以组合使用协议3GPP TS 38.211对生成顺序有明确规定先在一个根序列上做循环移位如果不够64个再换下一个根序列直到凑满64个为止。ZC序列的公式长这样x_u(i) e^(-j·π·i·(i1)/LRA)i从0到LRA-1。加上循环移位后变成x_u,v(n) x_u((nCv) mod LRA)。Cv的步长由Ncs决定Ncs就是循环移位的最小间隔也叫零相关区配置。把时域序列做DFT后频域上得到LRA点的序列也就是PRACH占用LRA个子载波。理解两个自由度的意义在于规划时你其实是在分配两个资源——给小区分配哪些根序列以及Ncs取多大。Ncs取大了一个根能产生的Preamble就少Ncs取小了循环移位间隔不够小区半径就受限制。3.2 Ncs的工程计算公式时延预算大于往返、多径和下行同步误差之和Ncs的取值不是拍脑袋定的工程上要满足一个不等式Ncs × Ts TRTD TMD TAdsch其中Ts是ZC序列的抽样间隔单位微秒TRTD是小区信号往返时延等于2×小区半径/0.3半径单位km0.3是光速折算成km/μsTMD是最大多径时延扩展TAdsch是下行同步误差短码场景覆盖距离近一般直接取0。Ts的计算公式是Ts 1000 / (SCS(kHz) × LRA)单位微秒。资料里给了两个算例我复述其中一个。format C2RA-SCS15kHzLRA139Ts0.479624μs如果目标小区半径是29.2kmTRTD61.33μsTMD取2.345μsTAdsch取0那么需要的Ncs×Ts约等于63.68μs。折算成Ncs就是132.77再到Ncs表里找不小于这个值的那一档。另一个算例是format 0SCS1.25kHzLRA839Ts0.953525μs。小区半径25km时TRTD83.33μs加上多径和同步误差项后总预算约95.99μs。这个算例说明长码的时延预算主要由往返时延主导短码则由多径和同步误差占比重更高。计算流程我一般按四步走第一步根据目标覆盖半径算TRTD 第二步按场景估TMD和TAdsch短码TAdsch取0 第三步把三项加起来除以Ts得到Ncs下界 第四步到对应的Ncs表里取不小于该值的档位再用这个Ncs反推小区实际支持半径。3.3 长短码Ncs表怎么读复用度与半径的取舍长码和短码的Ncs表结构不同。长码Ncs定义了三种集合Unrestricted Set用于低速场景Restricted Set Type A用于高速场景Restricted Set Type B用于超高速场景。同样一个Ncs值三种集合对应的支持半径不一样。资料里给过format 0的对照Ncs32时Unrestricted Set对应2.15kmRestricted Type A对应2.15kmRestricted Type B对应1km级别的半径。也就是说同样循环移位间隔限制集为了抗多普勒会牺牲一部分覆盖能力。短码的Ncs表更复杂因为短码有15kHz、30kHz、60kHz、120kHz四档子载波间隔。资料里有一张Zero Correlation Zone表列出了每个Ncs档位在不同SCS下的Delay Spread和Cell Range。读这张表的要点是随着子载波间隔加大同样Ncs对应的半径逐步缩小120kHz子载波间隔下最大只支持1.15km的小区半径。这就是为什么短码格式做不了大覆盖——Ncs表直接把上限卡死了。Ncs的选择直接影响根序列复用度。循环移位间隔越大一个ZC根能生成的Preamble越少小区要凑齐64个Preamble就需要更多根序列。根序列数量有限每个小区占用的根越多可分配的根组就越少邻区复用距离就越近。所以Ncs不是越大越好取满足覆盖半径的最小档位才是正解。3.4 从RRC参数到64个Preamble439号根序列的完整推导资料里有一个完整的算例把三个RRC参数联动起来推导64个Preamble的生成过程我完整复述一遍。假设小区配置了prach-ConfigurationIndex2、zeroCorrelationZoneConfig6、prach-RootSequenceIndex439、restrictedSetConfigunrestrictedSet。从prach-ConfigurationIndex2能查到Preamble format是format 0子载波间隔1.25kHz对应长码839。从zeroCorrelationZoneConfig6在format 0的Ncs表里查到Ncs32。那么一个ZC根通过循环移位能产生的Preamble数量是floor(839/32)26个。然后是root sequence的映射。prach-RootSequenceIndex439就是logical root sequence index查长码映射表439对应u662。接下来算Cvunrestricted set下Cvv×Ncsv从0取到25Cv依次是0、32、64、96……一直到768、800。这样662号根生成了preamble_index 0到25共26个。26个不够64个换下一个logical root sequence index。440对应u196同样通过Ncs32循环移位生成preamble_index 26到51又是26个。此时已经有52个还差12个。换到441它对应u643用v0到11生成12个Cv从0到352。第64个Preamble的Cv正好是352。步骤logical indexu值生成的preamble序号Cv范围个数14396620-250~80026244019626-510~80026344164352-630~35212这个推导过程值得每个做PRACH规划的人手推一遍。实际配置里Ncs、根索引、格式三个参数是联动的改任何一个64个Preamble的分布就全变了。我见过有人只改根索引不重算覆盖半径结果Ncs没变、每根产出的Preamble数不变但第三根只用12个就满了第四根完全不被使用——这本身没问题问题是他没意识到根组复用距离因此变了。3.5 根组复用一个小区三个根邻区怎么错开由上面的算例可知format 0配Ncs32时每个小区至少需要3个ZC根才能凑齐64个Preamble。规划时把这3个根作为一个根组分配给小区邻区之间用不同的根组来降低随机接入冲突概率。根组数量的计算分两步第一步算出每个ZC根能产生的Preamble数长码是floor(839/Ncs)短码是floor(139/Ncs)Ncs0时一个根只能产生1个Preamble第二步用64除以每根Preamble数向上取整得到每个小区需要的根数再用总根数除以每小区根数得到可用根组数。可用根组数越少根组复用距离越近邻区之间越容易发生前导冲突。这是规划的核心矛盾Ncs为了覆盖半径取大每根产出就少根组就多占复用距离就近。覆盖半径和抗干扰之间永远在互相拉扯没有一组参数能同时赢两头。4. PRACH频域与时域位置msg1-FrequencyStart和Configuration Index 94怎么读4.1 频域起点msg1-FrequencyStart与BWP位置关系PRACH频域资源由两个参数决定msg1-FrequencyStart和msg1-FDM。msg1-FrequencyStart告诉你PRACH资源的起点距离initial BWP或当前active BWP起点的偏移量取值范围0到36步进1。注意它给出的是相对位置不是绝对频点。想知道PRACH在载波里的绝对位置还得加上BWP起点和carrier实际有效RB起点这两个起点分别由BWP配置和carrier配置里的RRC参数决定。这个嵌套关系是频域规划容易出错的地方。只调msg1-FrequencyStart不改BWPPRACH相对BWP的位置变了但绝对频点可能没变甚至跑出有效RB范围。我一般先把BWP起点算出来再反推msg1-FrequencyStart的合理区间最后才落到具体值。4.2 频域占用139/839序列在不同PUSCH SCS下占多少RBPRACH占用的带宽由序列长度和子载波间隔共同决定但折算成PRB数量还要看PUSCH的子载波间隔。同样一段带宽PUSCH SCS越大一个RB占的频域越宽PRACH折算下来的RB数就越少。PRACH配置占用带宽PUSCH 15kHzPUSCH 30kHzPUSCH 60kHzPUSCH 120kHz139序列 15kHz2.085MHz12 RB6 RB3 RB—139序列 30kHz4.17MHz24 RB12 RB6 RB—139序列 60kHz8.34MHz——12 RB6 RB139序列 120kHz16.68MHz——24 RB12 RB以139序列加15kHz为例PRACH占2.085MHz带宽。PUSCH用15kHz时每个RB是180kHz占12个RBPUSCH换成30kHz每个RB变成360kHz只占6个RB。带宽没变但RB数折半。长码839序列在1.25kHz间隔下占1.04875MHz带宽PUSCH 15kHz时折算6个RB30kHz时3个60kHz时2个。这块最烦的是改动PUSCH SCS后忘记重新核算PRACH占用的RB数。PRACH带宽固定RB数却跟着PUSCH SCS变你不动PRACH参数配置也可能已经被动失效。4.3 时域位置Configuration Index 94的排布逻辑PRACH时域位置由prach-ConfigurationIndex决定这个索引对应一套完整的时域符号规则。资料里详细列了FR1非成对频谱下Configuration Index 90到95的表格我拿94来拆解。Configuration Index 94配置的是format A2子载波间隔30kHz。它定义在奇数帧的第4和第9个时隙里出现PRACH机会每个子帧包含6次PRACH机会20ms周期内总共12个PRACH机会。再细一层每个PRACH机会占4个符号每个时隙内重复发3遍。这意味着一个时隙里PRACH资源在时域上是连续密集排布的适合短码格式在城区高频次接入。读这张表要看四个维度nSFN Mod xy决定周期帧号Slot number决定时隙位置Starting symbol决定符号起点Number of PRACH occasions within a PRACH slot决定重复次数。90到95这几个索引的区别就在时隙编号和起始符号排列上错一个数字PRACH机会就和PUSCH撞在同一个时隙。4.4 时频资源规划顺序先半径后时频把第2、3、4章串起来PRACH规划的合理顺序应该是先按覆盖半径定format和Ncs再根据Ncs算每根序列产出和根组分配最后用msg1-FrequencyStart和prach-ConfigurationIndex把时频资源落到具体位置。顺序反了会出大问题。先定格式和Ncs是因为它们决定时延预算和根组数量是规划里最硬的约束时频位置是最后一步留给它的自由度最大。如果先把时频资源占满回头发现Ncs需要调大每根Preamble产出变少根组需求增加频域上可能就分不出那么多根组了。5. PRACH规划避坑六个翻车现场与排查方法5.1 邻区PRACH配置全撞车前导虚检风暴现象某个区域多个站点的RRC建立成功率同时下滑基站告警里有大量PRACH虚检处理资源被无效检测占满。原因邻近小区的Preamble格式、频域起始位置、ZC根序列全部相同。基站收到邻区UE的PRACH信号后无法通过根序列和频域位置区分把邻区的接入请求当成自己小区的请求处理产生大量虚检。解决相邻小区至少错开一个维度。优先错开根组根组不够就错开频域起始位置再不行换Preamble格式。实际排查时先看邻区列表里有没有根序列相同的站再对比msg1-FrequencyStart最后看format是否一致。5.2 高速场景没开限制集循环移位被多普勒打混现象高铁沿线站点接入成功率低Preamble检测峰值扩散误检率上升。原因高速场景下多普勒频移破坏了ZC序列的循环移位特性。Unrestricted Set只在低速场景下有效高速场景必须用Restricted Set Type A或Type B。没开限制集时基站检测到的循环移位位置会偏移把正常Preamble误判成另一个Preamble。解决场景判断为高速移动时把restrictedSetConfig改成restrictedSetTypeA或restrictedSetTypeB同时按对应集合的Ncs表重新查覆盖半径。Type A和Type B支持的半径比Unrestricted Set小查表时不能混用。5.3 Ncs按理论值取整取小了多径一来就误检现象小区覆盖边缘UE接入时延抖动大偶发性接入失败但中心区域正常。原因Ncs只按TRTD算没留够TMD和TAdsch余量。不等式用等号取整多径时延扩展一上来就超预算循环移位窗口被相邻Preamble污染。解决Ncs计算时把TMD按场景估足城区多径大建议按资料里的典型值再加20%余量。取Ncs档位时向上取不小于预算值的档不是四舍五入。5.4 选了设备不支持的格式方案好看配不了现象PRACH规划方案里写了format 1做超远覆盖到了配置阶段基站报参数不支持。原因协议定义了十几种格式但具体设备版本可能只支持其中一部分。某厂商5G RAN2.1版本只支持format 0和C2规划时没核对版本选了别的格式。解决选型前先查设备支持的前导格式列表。长码优先选format 0短码优先选C2这两个是默认支持面最广的组合。特殊覆盖需求提前和厂商确认版本能力。5.5 PUSCH子载波间隔变了没重算RB占用现象PUSCH SCS从15kHz改成30kHz后PRACH资源与PUSCH资源碰撞时频资源调度冲突。原因PRACH占用带宽固定但折算成RB数随PUSCH SCS变化。139序列配15kHz时占12个RBPUSCH换成30kHz只占6个RB。只改PUSCH SCS不重算PRACH的RB占用PRACH可能落在PUSCH资源内部。解决每次调整PUSCH SCS后按PRACH占用带宽重新折算RB数再用msg1-FrequencyStart核对PRACH起点是否与PUSCH边界对齐。我习惯做一张参数联动表SCS、RB数、频域起点三列一起更新。5.6 根序列数量没按64个Preamble倒推小区接入冲突率高现象用户密集区域随机接入冲突概率高RACH成功率波动大但干扰和覆盖都正常。原因只给小区配了一两个根序列循环移位生成的Preamble数远不到64个。UE可用Preamble不足两个UE选到同一个Preamble的概率就大冲突后只能退避重试。解决用floor(LRA/Ncs)算每根产出再用ceil(64/每根产出)算每小区根数最后做根组分配。不要想当然觉得根序列给得越多越好根组占用和复用距离要一起权衡。6. 验证一次PRACH规划手工反推与现场指标自检6.1 手工反向推导验证参数表做完一套PRACH规划后我会强制自己用一个小区做反向推导。已知prach-ConfigurationIndex2查出format 0、SCS1.25kHz已知zeroCorrelationZoneConfig6查出Ncs32已知prach-RootSequenceIndex439查出u662然后手推Cv序列确认第64个Preamble落在第三个根的Cv352上。这条链路走通参数表才是自洽的。6.2 三个现场指标判断规划质量第一个指标是RRC建立成功率目标值通常在99%以上低于这个值优先查PRACH虚检和冲突。第二个是前导冲突概率通过RACH统计能拿到的Msg1重传比例正常应在1%以下高了说明Preamble数量或根组复用有问题。第三个是接入时延特别是边缘UE的时延分布时延抖动大说明Ncs余量不够或GP偏短。6.3 一个快速自检习惯从那以后我每次做PRACH规划都强制走一遍完整链路先定format和Ncs再算根组再排时频位置最后用一个小区手工反推64个Preamble的生成全过程。反推能通参数表才敢批量铺开。这套方法帮我挡掉了好几次邻区虚检和Ncs取值过小的翻车。希望帮到你。本文还有配套的精品资源点击获取