简介这份PDF面向5G无线网络规划与优化工程师、设备商及运营商技术人员聚焦NR随机接入中PRACH信道的参数配置与容量规划问题。全文从随机接入过程的目的和竞争、非竞争两类接入方式切入依次说明频域ZC根序列生成、循环移位Cv的取值、时域prach-ConfigurationIndex配置、前导格式选择、Ncs规划及逻辑根序列索引分配等关键环节并给出小区覆盖半径与所需根序列数量的推算方法针对高速及高铁场景还讨论了限制集A/B下Cv的演算过程与根序列索引的分组规划思路。资源为单个PDF文件压缩包约532KB篇幅紧凑便于日常查阅。目前已有2267人学习下载适合用于PRACH参数核查、覆盖半径估算和高速场景根序列规划的参考对照。1. 一份PRACH规划材料能省掉多少外场返工外场调过随机接入的人大概都遇到过这种局面小区开通后接入成功率卡在某个数值上不去信令翻了几遍看不出毛病最后发现是prachConfigIndex和zeroCorrelationZoneConfig这两个参数在某张表里对不上——格式选的是长码Ncs 却按短码表配了。5GNR随机接入PRACH的规划这份材料做的就是把散在协议表格里的约束串成一条能算、能验的链路从 ZC 序列的根索引一路推到 64 个前导怎么分给相邻小区中间每一步都落在一个可核对的参数上。它适合刚接手 NR 小区参数规划的新人照着走一遍也适合手里有一批高铁沿线站点、需要复核根序列分组的老手。前提是你手边有对应的协议表否则单看公式会算不出数。2. 从ZC序列到64个前导频域资源是怎么被一步步消耗掉的PRACH 的频域资源本质上不是一段带宽而是一批可以被不同小区重复使用、但彼此不能撞车的码。理解这一点后面所有参数选择才有判断依据。这一段把公式拆成三个可独立检查的环节根序列怎么选、循环移位怎么定、一个根序列到底能产出多少个前导。2.1 根序列u、ZC长度Lra与循环移位Cv三者的关系前导的生成公式是x_{u,v}(n) x_u((n C_v) mod L_RA)其中x_u(n) exp(-j·π·u·n·(n1)/L_RA)。这个式子读起来抽象落到规划上其实只有三个自由量根序列号 u、序列长度 Lra、循环移位量 Cv。u 决定这条序列的形状Lra 决定它的长度Cv 决定从哪个位置开始截取一段给某个 UE 用。u 的取值范围是 0~837对应 Lra839 的长码或 0~137对应 Lra139 的短码。这里有个很容易被忽略的坑现网参数下发的prachRootSequenceIndex是逻辑索引号不是物理的 u。逻辑索引到物理 u 之间隔着一张按 order 排布的表两者不是简单的相等关系。材料里专门标注了这一点因为一旦跳过映射直接拿逻辑号当 u 代入公式算出来的 Cv 数量和实际网元行为对不上后面的根序列数量规划全部作废。Cv 的取值不是随便挑的它由 Ncs 和限制集类型共同决定。非限制集下Cv v · Ncsv 从 0 取到(Lra-1)/Ncs的整数部分限制集 A 和 B 下 Cv 的计算分成好几段还要引入一个辅助量去处理高速场景下的窗口折叠。材料里给的现网配置是restrictedSetConfig非限制集、zeroCorrelationZoneConfig6、对应Ncs32这是一个典型的低速宏站配置先按这个把链路走通再去改高速场景。提示先把逻辑索引到物理 u 的映射做成一张固定表存下来后面无论算多少个小区都从这张表查不要每次现场翻协议。这是我在做批量规划时最省事的一个习惯。2.2 用zeroCorrelationZoneConfig把Ncs钉死Ncs 的物理含义是相邻两个前导之间留出的保护间隔单位是采样点。它越大能容忍的时延扩展越大、覆盖半径越大但同一根序列能切出来的前导数就越少。协议给了三张 Ncs 表分别对应子载波间隔 1.25 kHz、5 kHz 和 15·2^u kHz规划时必须先确认自己用的是哪张表再看索引号对应的数值。材料里给出的现网参数组合可以直接作为起点参数取值说明prachRootSequenceIndexI839逻辑根序列索引需映射到物理 uLra839长码 ZC 序列长度restrictedSetConfig非限制集决定用哪一张 Ncs 表zeroCorrelationZoneConfig6非限制集下对应 Ncs32prachConfigIndex17决定时域位置与前导格式同一张表里索引 6 在非限制集下是 32在限制集 A 和 B 下都是 46。这个差异非常关键同一个zeroCorrelationZoneConfig值换个限制集配置Ncs 就从 32 跳到 46覆盖半径和前导产出量都跟着变。很多规划表在复制粘贴时只改了restrictedSetConfig没同步重算 Ncs结果就是纸面覆盖半径和实际对不上。低速场景下的选择原则材料里的表述是依据覆盖场景确定格式后按照各场景内小区实际覆盖需求尽量选用复用度大的zeroCorrelationZoneConfig索引号。这句话要拆开理解复用度高意味着同一批根序列能被更多小区容纳而 Ncs 越小、单根序列产出的前导越多复用度就越高。但 Ncs 不能小到覆盖不住小区的时延扩展。所以真实操作顺序是先用覆盖半径公式算出 Ncs 的下限再在这个下限之上取能满足覆盖的最小索引而不是无脑取大或取小。如果反过来操作先按经验定 Ncs32再去算覆盖半径往往会发现半径算出来比站间距小一大截回头改 Ncs 又要重排整片区域的根序列分配返工量比一开始就按公式算大得多。2.3 手算一遍Ncs32时一个根序列能出多少个前导公式是每根序列前导数 (Lra - 1) / Ncs向下取整。代入 Lra839、Ncs32(839-1)/32 26.19取整得 26。一个小区需要 64 个前导64/26 2.46向上取整得 3。也就是说这个配置下每个小区要连续占用 3 个逻辑根序列索引。这个数字直接决定了相邻小区之间至少留多宽的索引间隔。如果按 3 个算完就往下排小区遇到 Ncs0 的场景就会翻车——Ncs0 时 Cv 只有 0 这一个取值每根序列只产出 1 个前导64 个前导意味着连续吃掉 64 个索引小区间隔必须拉到 64 以上。材料里明确写了这一条但很多规划模板默认按 Ncs≠0 的公式算Ncs0 的分支被漏掉。把这段逻辑写成脚本批量跑小区的时候比手算靠谱import math def roots_per_cell(Lra839, ncs32, target64): 返回(每根序列产出的前导数, 本小区需要的连续根序列数) if ncs 0: # Ncs0 时只有一个循环移位一根序列只出一个前导 return 1, target per_root (Lra - 1) // ncs # 向下取整不四舍五入 roots math.ceil(target / per_root) return per_root, roots for ncs in (0, 13, 26, 32, 46): per_root, roots roots_per_cell(ncsncs) print(fNcs{ncs:3} 每根序列前导数{per_root:3} 需连续根序列{roots:3})跑出来 Ncs32 那一行是 26 和 3和手算一致。注意(Lra-1)//ncs用的是整除不是math.floor之后再加一差一个前导在密集城区可能就是一个小区多占一个索引累积到几十个站点上就是一片区域的根序列提前耗尽。注意Lra 取 839 还是 139取决于用的是长码还是短码格式。短码 Lra139 时同样 Ncs32 只能产出 4 个前导一个小区的根序列消耗量直接翻了六倍多。格式选型没定之前不要算根序列。3. 时域配置与格式选型prachConfigIndex17到底查出了什么频域算完只是解决用哪些码时域要解决什么时候发。这两件事由不同的参数控制但互相牵连——格式决定了 CP 长度CP 长度决定了覆盖半径覆盖半径又反过来约束 Ncs 的下限。这一段把这条闭环走完。3.1 FR1与FR2的配置表分开查prach-ConfigurationIndex对应的是协议里的时域配置表FR1 和 FR2 用的是不同的表同一个索引号在两张表里查出来的格式、SFN 周期、子帧位置可能完全不同。材料给的例子是 FR1 下prachConfigIndex17查表得到 Preamble format0允许 UE 在任何系统帧的子帧 4 上发送 PRACH。拆开看这三个结论分别意味着什么。format0 是长码格式Lra839Tseq800 μs一个 PRACH 占用 1.25 kHz 子载波间隔下的 839 个子载波频域宽度约 1.05 MHz。任何系统帧意味着这个配置下 PRACH 的发送周期是每帧一次没有额外的 SFN 门限子帧 4 是固定的时域位置同一覆盖区域内所有小区如果都用索引 17PRACH 就会在同一时刻同时到达邻区干扰会集中在这一段。实际规划里同频邻区一般会错开prachConfigIndex让 PRACH 时刻散开。错开的粒度取决于表里的 SFN 周期和子帧号组合不是随便换个数就行——换完之后要重新确认 format 有没有变因为格式一变前面算好的 Ncs 和根序列数全部要重来。提示改prachConfigIndex之后第一件事是回查 format 字段不要假设格式不变。我在一个批量脚本里吃过这个亏十几个小区改了索引其中三个的格式从 0 变成了 B4根序列规划整个作废。3.2 长码4种、短码9种格式按覆盖场景排NR 的前导格式一共 13 种长码 4 种format 0/1/2/3短码 9 种A1/A2/A3、B1/B2/B3/B4、C0/C2。format 0 和 1 沿用 LTE 的 format 0 和 format 32 和 3 以及所有 A/B/C 系列是 NR 新引入的。这个划分的意义在于长码格式序列长、CP 长适合大覆盖和低速场景短码格式序列短、占用符号少适合密集城区和低时延场景但覆盖半径天然受限。选型的抓手是覆盖半径公式小区覆盖半径 (Tcp - 最大多径时延扩展) × c / 2。Tcp 是循环前缀的时长c 是光速除以 2 是因为要走一个往返。把协议表里的 Tcp 代进去扣除当地的多径时延扩展就能得到这个格式在这个场景下的半径上限。格式TcpTseq扣 5 μs 多径后的半径上限0103.13 μs800 μs约 14.7 km1684.38 μs800 μs约 102 km2203.13 μs6.4 ms约 29.7 km34.8 ms6.4 ms公式值极大实际受链路预算约束这张表里 format 3 那一行要特别注意公式算出来的数字上千公里明显超出任何真实组网需求说明这个格式的设计目的不是覆盖更远而是用超长 CP 去对抗极端多径和超大时延扩展。真正决定能不能用 format 3 的是 UE 发射功率和链路预算公式只是给个上限。材料里没展开这一层但规划时如果只盯着公式选格式很容易选出一个纸面覆盖够、实际解不出来的配置。多径时延扩展这个量在不同场景差别很大。密集城区常见的取值在 1~3 μs 量级郊区开阔地可能到 5 μs 以上山区或特殊地形要单独评估。材料里没有给具体的时延扩展建议值这个数只能靠当地路测或场景类比来定取保守值。取小了边缘用户的前导会拖到尾部的下一个窗口里表现为接入失败率随距离上升。3.3 两个半径公式别用混材料里出现了两个形式相近的覆盖半径公式用的场景完全不同混用是规划表出错的高频原因。第一个是格式选型用的(Tcp - 最大多径时延扩展) × c / 2它回答的是这个格式最多能覆盖多远。第二个是 Ncs 规划用的(Ncs × Tseq / Lra - 最大多径时延扩展 - 安全余量) × c / 2它回答的是在当前 Ncs 下循环移位窗口能容纳多大的时延而不产生窗口重叠。两个公式的差别在于Ncs × Tseq / Lra这一项。Tseq/Lra 是单个采样点对应的时长乘上 Ncs 就是保护间隔的实际时间长度。这个长度必须大于往返传播时延加多径扩展再留一段安全余量否则相邻两个循环移位窗会互相污染。安全余量这个参数材料里没有给固定值实际规划里一般按保护间隔的 10%~20% 取或者直接按经验留 1~2 μs。留得太紧高速移动或大气折射引起的时延抖动会把窗口顶穿留得太松等于白白牺牲覆盖半径。我一般会在边缘站点单独放宽中心站点按标准值走避免整片区域统一放宽导致 Ncs 全部上调。举个具体算例Ncs32、Tseq800 μs、Lra839保护间隔 32 × 800/839 ≈ 30.5 μs。扣掉 5 μs 多径和 2 μs 安全余量剩下 23.5 μs往返除以 2 得半径约 3.5 km。这个数字和 2.3 节按根序列数反推的 3.3 km 量级吻合说明这套参数组合是自洽的。如果算出来两个数差得远基本可以断定某一环节的表查错了。4. 根序列规划从64个前导倒推小区之间的索引间隔前面两步算的是单个小区需要什么这一步要解决多个小区怎么分。根序列是全网共享的稀缺资源长码只有 838 个可用索引0 号通常保留短码更少一个城市动辄几千个小区分配策略直接决定会不会出现跨区干扰。4.1 Cv的数量决定根序列消耗速度逻辑很直接一个小区要凑够 64 个前导靠的是当前根序列 u 按所有合法 Cv 切出来的前导集合。如果这个集合不够 64 个就把逻辑根序列索引加一用下一个 u 继续切直到凑满为止。所以 Cv 的个数就是单根序列的产能产能越低吃掉的连续索引越多。材料里给了两个典型分支。Ncs0 时 Cv 只有一个取值 0产能是 1一个小区连续吃掉 64 个索引规划时不同小区的逻辑根序列索引间隔至少 64。Ncs≠0 时Cv v × Ncsv 取 0 到(Lra-1)/Ncs产能就是前面算的 26小区间隔降到 3。这个 3 是理论最小值实际规划还要往上加。原因有两个一是相邻小区如果紧挨着用连续索引边界处一旦有时延扩展溢出两边的窗口容易撞上二是留出余量方便后续扩容和参数微调。工程上常见的做法是在理论值上乘 1.5 到 2 倍作为同频邻区的索引间隔异频或物理隔离足够的小区可以复用同一段。材料里的算例是小区半径 3.3 km、Format0、Ncs32、Lra839838/3226个前导64/26向上取整得 3 个连续逻辑根序列。这个算例的每一步都能复算是整份材料里最适合拿来验证自己理解是否有偏差的一段。4.2 低速场景先满足覆盖再压索引消耗低速场景的规划顺序不能反。正确顺序是定格式 → 算覆盖半径 → 反推 Ncs 下限 → 在满足下限的索引里选最小的那个 → 算单根序列产能 → 算小区索引间隔 → 全网分配。反过来先按经验拍一个 Ncs再算覆盖再发现覆盖不够再回头改——这条路走一遍前面分配好的索引全部作废。批量规划时这个返工成本非常高尤其是已经有几十个站点按旧参数开通的情况下。实际分配时还有个细节同一片区域内的所有小区应该尽量用同一套 Ncs 和格式参数。参数不一致会导致边界处的 PRACH 行为不可预测切换场景下尤其明显。材料里提到的非竞争前导主要用于切换如果源小区和目标小区的 Ncs 差异过大目标小区预留的专用前导可能在源小区的定时假设下对不上切换成功率会掉。对于边界小区我的习惯是先把整片区域的参数统一再针对个别超远覆盖站点单独开一组索引而不是让每个站点各自为政。这样索引池的碎片化程度最低后续加站时还有余量可用。4.3 高速场景限制集A/B与高铁沿线的分组规划高速场景的问题根源是频偏。UE 高速移动产生的多普勒频偏会让 ZC 序列的相关峰能量向相邻的循环移位窗泄露被污染的那些窗就不能再用来产生前导否则接收端会把一个 UE 的前导误判成另一个。解决办法是引入循环移位限制集主动禁用那些会被污染的位置。R15 在限制集 A 的基础上加了限制集 B用于 350 km/h 以上的超高速场景。限制集 B 下 Cv 的计算分成几段还要引入辅助量处理窗口折叠比非限制集复杂得多。材料里明确说了对限制集 B 做演算分析是为了后续高速场景规划并且给了部分计算结果——这也是这份材料和普通科普的差别所在它把最难手算的那部分做成了可查的表。材料里的高铁算例值得完整走一遍小区半径 1~2 kmNcs26可选用连续根序列索引 42~329。这个区间一共 288 个索引。用简易法规划以 19 个连续索引为一组可用的组数是288/19 ≈ 15也就是 15 个可用起点。用最大法规划逐个验证后得到 19 个可用索引42、55、71、86、102、116、132、147、166、183、200、214、227、240、254、268、283、297、311。这两种方法的差别在于粒度。简易法按固定步长切实现简单、可批量但会浪费一部分本来能用的索引最大法逐个试能把索引池榨到最满代价是计算量大、对表格精度要求高。实际工程里通常是简易法定框架、最大法做补充先用简易法把大片区域铺开剩下的边角站点再用最大法抠出可用索引。把最大法的逻辑写成脚本方便对着材料里的 19 个结果做校验def count_preambles(u, ncs, Lra839, restrictedFalse): 给定根序列和Ncs返回该序列能产出的前导数量。 restrictedTrue 时保守地按每两个Cv之间留双倍间隔估算 用于高速场景下的快速筛选精确值仍需查限制集表。 if ncs 0: return 1 step ncs * 2 if restricted else ncs # 高速场景留双倍窗规避泄露 return (Lra - 1) // step def scan_roots(start, end, ncs, target64, restrictedTrue): 从索引区间里挑出能独立凑满target个前导的起点 usable, idx [], start while idx end: total, cur 0, idx while total target and cur end: total count_preambles(cur, ncs, restrictedrestricted) cur 1 if total target: usable.append(idx) idx cur # 下一组从当前组结束的位置开始 return usable roots scan_roots(42, 329, ncs26, restrictedTrue) print(len(roots), roots)这段脚本里的step ncs * 2是一个保守近似真实的限制集 B 要按协议表逐段算 Cv脚本只用来快速圈定候选区间最终结果必须回表核对。跑出来的起点数量和材料给的 19 个不一定完全一致差几个属于正常因为近似模型没有覆盖限制集 B 的全部分段规则。它的价值在于把 288 个索引的遍历从手工变成秒级剩下的核对工作量就很小了。注意高速场景下不要用非限制集的公式去估算产能误差可能到一倍以上。材料里专门把限制集 B 单独拎出来演算就是因为这个分支不能靠类推。5. 避坑与排查PRACH规划里翻车最多的五个地方这一节按现象 → 原因 → 解决记五条都是规划表做完、参数下发之后才会暴露的问题提前对着检查能省掉一轮外场。第一条算出来的前导数和网元实际行为对不上。现象是规划表里按公式算出某小区需要 3 个根序列但实际开通后发现前导不够用或者相邻小区的专用前导出现冲突。原因基本都是把逻辑根序列索引直接当成了物理 u 代入公式跳过了那层映射表。逻辑索引按 order 排布和物理 u 不是一一顺排的关系。解决办法是把映射做成固定查表脚本里第一步就做转换转换后的 u 再进公式。这条在材料里是明确标注的属于看一眼就能避免、不看就必踩的坑。第二条Ncs0 的场景按 Ncs≠0 的公式排了索引。现象是密集城区某片小区根序列索引大面积重叠接入冲突率异常。原因是 Ncs0 时每根序列只产出 1 个前导一个小区的索引消耗量是 64 而不是 3规划表如果统一按(Lra-1)/Ncs算遇到 Ncs0 会直接除零或者走进错误分支。解决办法是在脚本里对 Ncs0 单独走一个分支返回 1 和 64并且在分配索引时强制检查小区间隔是否达到 64。第三条限制集配错高速场景用了非限制集。现象是高铁沿线小区在列车高速通过时接入成功率骤降低速测试一切正常。原因是高速下的多普勒频偏让相关峰能量泄露到相邻循环移位窗非限制集没有禁用这些被污染的窗接收端把泄露的能量当成了另一个 UE 的前导。解决办法是把restrictedSetConfig切到对应的限制集同时按新的 Ncs 表重算全部参数。注意切换限制集之后zeroCorrelationZoneConfig的同一个索引对应的 Ncs 会变索引 6 从 32 变成 46覆盖半径和产能都要重算。第四条prachConfigIndex 跨 FR 查错表。现象是参数下发后 UE 根本不在预期的子帧上发 PRACH或者格式对不上导致解调失败。原因是 FR1 和 FR2 用的是两张不同的时域配置表同一个索引号在两张表里指向完全不同的格式和子帧位置。解决办法是查表前先确认频段归属脚本里把 FR 作为入参显式传进去不靠默认值。第五条覆盖半径公式漏了安全余量。现象是小区边缘用户接入失败率明显高于中心路测显示边缘 RSRP 够但随机接入就是上不去。原因是 Ncs 规划时只扣了多径时延扩展没留安全余量保护间隔刚好卡在临界值上稍微有点时延抖动窗口就被顶穿。解决办法是在公式里显式加一项安全余量边缘站点单独放宽。这个余量材料里没给推荐值按保护间隔的 10%~20% 取是个稳妥起点。6. 验收一遍把规划表跑成可复核的检查单规划表做完不等于能下发中间还差一道验收。我的做法是把所有关键参数拉成一张纵向的检查单每一行都写清楚期望值、实际值、依据哪张表然后逐行过。这张单子不追求覆盖全部参数只放那些改一个就会连锁影响其他的强耦合项。检查项期望关系不满足时的后果格式 与 Lraformat 0/1/2/3 对应 839Ax/Bx/Cx 对应 139根序列产能算错一个量级restrictedSetConfig 与 Ncs同一索引在不同限制集下 Ncs 不同覆盖半径与产能同时偏差Ncs 与小区半径按含安全余量的公式反算半径不小于站间距边缘接入失败单根序列产能 与 64(Lra-1)/Ncs向上取整后乘以根序列数不小于 64前导不够接入失败邻区根序列间隔不小于理论值乘 1.5边界窗口重叠虚警上升prachConfigIndex 与 FR查表前确认 FR 归属时域位置或格式全错这张表里最容易漏的是第二行和第五行。第二行是因为zeroCorrelationZoneConfig和restrictedSetConfig是两个独立下发的参数规划表里经常分在两列改一个忘了改另一个第五行是因为理论间隔算出来是 3很容易就按 3 排下去忽略了边界溢出的余量。再往前一步可以把检查单做成脚本输入是一份参数清单输出是每条检查项的通过与否。这样每次参数调整之后重跑一遍比人工对表快得多也不会因为疲劳漏看。我一般会把这个脚本和根序列分配脚本放在同一个目录下参数文件共用一份避免两边不同步。最后一个技巧关于格式选型的验证。前面算覆盖半径用的是公式公式给的是上限但真实可用半径还受 UE 发射功率、天线高度、链路预算影响。验证方法是找一两个边缘站点做单站验证固定 Ncs 和格式让测试终端从小区中心往外走记录随机接入成功率随距离的变化曲线把成功率开始明显下降的位置和公式算出来的半径对比。如果实测半径明显小于公式值说明链路预算是瓶颈而不是 CP 长度这时候加大 Ncs 没有意义得从功率或天线下倾角上找。反过来如果实测半径接近或超过公式值说明这套参数还有余量可以考虑把 Ncs 往下调一档换回更多的根序列产能。这个方向在大规模组网时很值钱——Ncs 从 32 降到 26单根序列产能从 26 涨到 32小区间隔从 3 降到 2整片区域的索引池能多撑三分之一的小区。高速场景的验证要单独做一版。材料里给的简易法和最大法两套结果实际选哪套取决于沿线站点的密度和列车速度分布。我一般会先用简易法铺一遍把 15 个分组起点标在地图上看有没有连续两个站点落在同一组的边界上如果有就在那一段换用最大法抠出来的索引补位。这个方法不优雅但比全线都用最大法省很多计算时间。从那以后我每次做完 PRACH 规划都会强制走一遍格式—Ncs—产能—间隔这四行检查哪怕只改了一个参数。这套参数之间的耦合太紧靠记忆判断哪几个会连锁变化迟早会漏。希望帮到你。本文还有配套的精品资源点击获取