企业官网建设流程全解析

简介：《5G NR PRACH接入信号规划方法详解.pdf》是一份面向5G网络优化工程师与无线接入网规划人员的专业文档，聚焦物理随机接入信道的规划与设计。内容从随机接入的作用出发，系统讲解Preamble的ZC序列生成、64个前导序列的组合方式，以及CP与GP对覆盖半径和干扰抑制的影响，并对比long/short preamble共13种format的适用场景，帮助读者掌握不同覆盖需求下的参数选择逻辑。资源共1个PDF文件，压缩包大小2.22MB，内容精炼，可在电脑端或移动端随时查阅。目前已有647人学习下载，是一份颇具参考价值的接入网技术资料。除了理论分析，文档还结合华为5G RAN2.1版本说明了前导格式选择、ZC根分配、循环移位间隔Ncs的取值方法，并给出邻区规划中Preamble虚检的成因与规避思路，对实际网络优化、参数精细化调整和覆盖性能提升具有很强的指导意义。

1. 基站刚开通，用户却喊“有信号打不了电话”：先查PRACH

一个站开通后RRC连接建立成功率掉到60%以下，网管上看SSB覆盖指标全部正常，用户投诉却集中在“有信号、一打电话就断”，这种场景我遇到过不止一次。问题往往不在下行覆盖，而在上行的第一跳：5G NR里终端进网要先在PRACH（物理随机接入信道）上发前导码，基站解析出是哪部手机、测出时间提前量，随机接入才算成立。PRACH规划看起来只是配几个参数，实际牵涉时域位置、频域宽度、根序列和覆盖半径四条线，任何一条配错都会让接入链路半残。这篇就按我日常做NR开局和扩容的顺序，把PRACH规划从查表到避坑完整过一遍。适合做4G/5G无线优化、开站调测的工程师，也适合刚接触5G SA接入网想快速上手PRACH的读者。

2. 先读懂PRACH的时频面孔：prach-ConfigurationIndex与msg1-FDM怎么定

PRACH规划的起点不是根序列，而是先把“前导码在哪发”定下来。NR里这个位置由prach-ConfigurationIndex决定时域，由frequencyStart和msg1-FDM决定频域。顺序不对，后面全是空中楼阁。

2.1 prach-ConfigurationIndex：一张表决定前导码“何时发”

prach-ConfigurationIndex取值范围0到255，映射到38.211的6.3.3.2节里的配置表。这个表按format和双工方式分成好几张，FR1 FDD、FR1 TDD、FR2各自对应不同的子表。查表时先确认format再查配置号，顺序不能反。常见的长格式有format0到format3，短格式有A1/B1/C0等，开局最常用的是format0。

以FR1 FDD的format0为例，prach-ConfigurationIndex=0表示前导码在偶数系统帧的子帧1发送，配置索引每增加一个档位，发送位置就往后挪一个子帧或跳一个周期。这个位置的本质是：既要落在上行时隙里，又要给上行调度留出空间。TDD帧结构下更麻烦，前导码不能和SSB、下行时隙撞车，所以很多厂商开局模板里TDD站用prach-ConfigurationIndex=15或16，配合上下行时隙配比去躲冲突。

我一般建议开局时不要直接抄模板值，而是打开配置表对着帧结构核对一遍。帧结构里下行时隙、灵活时隙、上行时隙的分布决定了PRACH能落在哪，落错位置最常见的结果是前导检测窗口里什么都收不到。记住一个原则：时域配置宁可多翻两页表，也不要靠猜。

2.2 msg1-FDM与frequencyStart：频域上把容量摊开

时域定了之后，频域由两个参数控制：msg1-FDM和frequencyStart。msg1-FDM表示同一个PRACH时隙上频分复用几路PRACH，取值1、2、4、8；frequencyStart给出PRACH频域起始位置，单位是PRB。

频域宽度取决于前导码格式：长格式（format0到format3，839个子载波）占用6个PRB，短格式（139个子载波）在15kHz子载波间隔下占用12个PRB。frequencyStart要在SSB和PUSCH的频域资源之外找一块干净的位置，否则会压到BWP里已有的调度资源。msg1-FDM开得越大，同一时刻能容纳的接入尝试越多，但代价是上行频域资源被吃掉，而且基站侧要并行处理的PRACH接收机会变多。

这里有个常见误解：以为msg1-FDM只跟容量有关，跟覆盖无关。实际上FDM开大后每个PRACH occasion占用的RB总数变大，功率谱密度会被摊薄，如果基站侧没有相应的功率补偿，边缘覆盖反而会变差。所以FDM不是越大越好，我一般根据“同时接入用户数”估算，普通宏站开局用2或4足够，高话务热点才考虑8。

2.3 SSB与PRACH occasion的映射：波束级接入怎么对齐

5G NR的随机接入还有一个4G时代没有的维度：SSB波束与PRACH occasion的对应关系。这个关系由ssb-perRACH-OccasionAndCB-PreamblesPerSSB这个参数控制，常见写法是“SSB数量/前导码数量”，比如1/4表示一个PRACH occasion对应一个SSB，每个SSB分到4个前导码。

配这个参数的逻辑是：终端在小区里听到哪个SSB波束，就用那个波束对应的PRACH occasion发前导码。基站收到前导码后，能反推出终端大概在哪个波束方向，后续波束管理可以直接沿用这条链路。如果SSB有8个波束，但PRACH occasion只有4个，就得让两个SSB共享一个occasion，规则是按照SSB-to-RO映射表循环映射。

这个映射如果配错，常见现象是特定波束方向上的终端反复接入失败，但网管统计前导检测成功率又很高。因为别的波束都正常，只有某个波束对应的occasion没建起来。排查时要先看SSB波束数量，再看PRACH occasion数量，最后核对映射偏移，三步缺一不可。

3. 根序列规划：从ZC序列到Ncs的分配算法与脚本

时频位置定完后，下一个核心问题是：每个小区用哪一组前导码。这就要动根序列和循环移位了。NR的前导码由ZC序列循环移位生成，规划根序列就是给每个小区分配“不会跟邻区撞车”的码字集合。

3.1 Nzc与物理根序列：839和139两条路线

ZC序列长度Nzc决定了一条链路上能切出多少种码字。NR里两套标准：长格式用Nzc=839，短格式用Nzc=139。Nzc=839时每个物理根序列能生成的可用前导码更多，覆盖性能也更好；Nzc=139资源占用小，适合高频大带宽场景。

物理根序列号u由逻辑根序列索引映射而来，映射关系在38.211的6.3.3.1节里查表。逻辑根序列索引是高层配置参数prach-RootSequenceIndex，规划时我们直接操作逻辑索引，但心里要知道背后对应的是哪一个物理根序列。相邻逻辑索引对应的物理根序列在时域上往往相邻，互相关性略高，所以邻区之间要刻意拉开索引间隔。

实操里常见做法是：先按“每小区64个前导码”的需求量，算出一共需要多少根序列，然后在逻辑根序列表里每隔一段取一个分配给相邻小区。最简单的分配策略是同站点三个扇区用连续但间隔的索引，距离更远的复用同一段根序列。

3.2 zeroCorrelationZoneConfig与循环移位：先定Ncs再谈覆盖

一个物理根序列能切出几个前导码，取决于循环移位步长Ncs。高层参数是zeroCorrelationZoneConfig，它映射到一组Ncs值。Ncs越大，每个前导码之间的时间间隔越大，能容忍的传输时延差越大，覆盖越远；但每个根序列能切出的前导码数量越少，需要的根序列就越多。

Ncs选择的第一约束是覆盖半径。前导码循环移位的物理意义是：不同终端发送的前导码到达基站后，如果时延差落在同一个循环移位窗口内，就会被基站识别成同一个前导码，造成冲突。所以Ncs必须大于“小区边缘时延差”对应的采样点数。工程上有一个粗略估算：长格式format0下，Ncs每增加1，可支持的覆盖半径大约增加140到150米。所以1.2公里左右的小区，Ncs取13左右；三公里以上的广覆盖站，Ncs要取到30以上，具体还要看format。

Ncs还有一个隐藏约束：一个物理根序列产生的可用前导码数量是floor(Nzc/Ncs)。Ncs取太大会导致单个根序列凑不满64个前导码，每个小区要占多条根序列，根序列需求量成倍上涨。这对小区数量多的城区是不小的压力，所以城区站Ncs宁可选小一点，靠根序列规划去解决干扰，也不要把覆盖余量全压在Ncs上。

3.3 用Python算根序列需求与覆盖半径

下面这段脚本用来做两件事：估算单个根序列能出多少前导码，以及估算Ncs对应的大致覆盖半径。写规划和扩容方案时我一般先跑一遍，拿到数量级再填表。

# PRACH根序列规划快速估算脚本 # 覆盖半径估算基于: 循环移位时间差 = Ncs / Nzc * 前导码周期 # 长格式format0前导码周期约0.8ms, 光速往返时间折半 import math def calc_preamble_per_root(nzc, ncs): """每个物理根序列可用的前导码数量""" if ncs == 0: return 1 return math.floor(nzc / ncs) def calc_roots_needed(nzc, ncs, preamble_total=64): """一个小区需要多少条根序列才能凑满preamble_total个前导码""" per_root = calc_preamble_per_root(nzc, ncs) return math.ceil(preamble_total / per_root) def estimate_coverage_km(ncs, nzc=839, preamble_duration_us=800): """估算Ncs对应的最大覆盖半径, 单位km""" # 循环移位时延 = ncs / nzc * 前导码周期 delay_us = ncs / nzc * preamble_duration_us # 距离 = 光速 * 时延 / 2 (往返) distance_km = 3e8 * delay_us * 1e-6 / 2 / 1000 return distance_km # 以format0, Nzc=839为例 for ncs in [0, 13, 15, 19, 23, 30]: roots = calc_roots_needed(839, ncs) cov = estimate_coverage_km(ncs) print(f"Ncs={ncs:3d}, 每根序列前导码={calc_preamble_per_root(839, ncs):3d}, " f"每小区需根序列={roots:2d}, 估算覆盖={cov:6.2f}km")

这段脚本里最关键的是calc_preamble_per_root和calc_roots_needed两个函数。calc_preamble_per_root返回的是单个物理根序列能切出的前导码数量，calc_roots_needed乘以小区实际需要的前导码总数（默认64）后向上取整，得到根序列需求量。estimate_coverage_km只是数量级估算，真实覆盖还要叠加链路预算和GT（保护间隔）的约束，不能直接拿这个数字去做网络承诺。

跑出来的结果很有参考性：Ncs=13时，单根序列能出64个前导码，一个小区正好占一条根序列，估算覆盖约1.86公里；当Ncs涨到30时，单根序列只能出27个前导码，每个小区要占3条根序列，覆盖估算约4.28公里。这就是为什么广覆盖站的根序列规划难度远大于城区小站：覆盖半径上去之后，根序列资源消耗是成倍增加的。

4. 把覆盖与容量换算成参数：PRACH规划的四步落地法

前面三章把PRACH的参数逻辑拆开了，这一章把它们串成一条可执行的规划流程。我每次做站点的PRACH规划都按四步走，中间不允许跳步。

4.1 四步法总览：从覆盖半径到参数表

第一步，定覆盖半径。用链路预算或者直接拿SSB的覆盖范围做参考，算出小区边缘目标距离。注意边缘要以“可解调PRACH的最小电平”为准，不能拿SSB的覆盖范围硬套，两者差了可能不止3dB。

第二步，选format和Ncs。覆盖半径小于1.5公里，format0优先；1.5到3公里，format1或format2；再往上才考虑format3。format每升一级，前导码时长变长、覆盖变大，但时域开销也变大，TDD帧结构下还要确认塞得下。Ncs按覆盖半径结合第3章脚本算，取整后落到zeroCorrelationZoneConfig对应档位。

第三步，算根序列需求量并分配。每小区要64个前导码，用calc_roots_needed算出本小区占几条根序列。同站邻区和周边邻区之间，把根序列索引隔开，原则是物理根序列号不相邻。

第四步，定频域位置和功率。frequencyStart避开SSB和PUSCH的有效资源，msg1-FDM按容量估算取1/2/4/8，最后给PRACH配置独立的功率偏置，通常比PUSCH高3到6dB。

4.2 一张可抄的规划参数模板

下面这张表是我做宏站PRACH规划时的常用起点，适合普通城市宏站、TDD帧结构、三扇区场景。注意这不是万能值，只是起步模板，配完要按现场验证结果回改。

根序列分配模板我一般这样写：站点三个扇区分别用逻辑根序列索引0、4、8这类间隔4的取值，向外一圈的邻区再用16、20、24，形成两圈错开的布局。根序列规划有个口袋规则：同站间间隔至少4到6，邻区之间间隔至少2到3，覆盖交叠越重，间隔越大。

4.3 SA组网与TDD帧结构下的调整

5G SA组网里PRACH规划还要额外注意TDD帧结构带来的干扰问题。TDD站点上下行同频，远端下行信号可能落入本地上行接收窗口，PRACH作为最脆弱的上行信道首当其冲。所以TDD帧结构里的灵活时隙要谨慎使用，PRACH尽量放在纯上行时隙，不要在灵活时隙里赌网络行为。

另外在多频段组网场景下，不同小区类型的NR站（宏站、微站、室内分布）覆盖半径差异极大，PRACH参数不能共用一套。宏站和微站交叠区域，微站的Ncs如果照抄宏站会浪费根序列，而且前导码窗口太长反而放大干扰。我一般会按小区类型单独建参数集，在网管上给不同小区分批下发。

这里也提一句与网管操作相关的事：华为网管上查小区对应框号时，PRACH参数是跟着RRU框号走的，改参数前先确认框号和小区归属，避免把参数配到别的硬件链路上。很多5G组网与运维大赛的实操题里，PRACH参数配错导致的接入失败都是必考排障项，考的就是现场工程师会不会先核对网管上的硬件归属再动手。

5. PRACH规划避坑指南：我踩过的5个典型坑

PRACH规划里翻车往往不是原理不懂，而是参数之间的联动关系没看全。下面这5个坑是我在实际开站和排障中遇到的，每条按现象、原因、解决三步写清楚。

5.1 RAR总超时，前导检测计数却正常

现象：终端显示已接入但一直收不到RAR（随机接入响应），基站侧统计前导检测成功次数不少，可RAR发送成功率低到离谱。原因：format选小了一档。小区实际覆盖半径接近3公里，但PRACH用了format0，Ncs又只够1.5公里。远端终端的前导码虽然被基站检测到了，但时延超出了Ncs容限，基站算出的定时提前量是错乱的，RAR发下去终端对不上相位，反复重传。解决：换format1或format2，同时把Ncs按覆盖半径重新计算。这类问题最坑的地方在于网管统计“有信号”，指标并不全红，只有RAR成功率这一个指标在报警。

5.2 相邻小区前导互扰，Ncs与根序列背锅

现象：两个相邻小区交叠区域，终端随机接入时偶发失败，前导检测统计里出现大量不是本小区根序列的“杂散峰”。原因：根序列分配距离太近。两个相邻小区用了相邻的物理根序列号，互相关性偏高，在交叠区域多径环境下会把邻区的前导码误检成自己的。解决：把邻区间的逻辑根序列索引间隔拉到4以上，并检查两圈以外的复用距离。这里有个经验：Ncs调大确实能减少码间干扰，但代价是根序列消耗量上涨，先动根序列间隔，再动Ncs，这个顺序不要反过来。

5.3 msg1-FDM开大后上行被挤压

现象：高话务区域把msg1-FDM从2改到8后，接入成功率反而下降，同时PUSCH的调度RB明显变少，上行吞吐掉了一截。原因：FDM开大方虽然增加了PRACH occasion数量，但占用的频域资源线性增长，把PUSCH的可用RB挤掉了；而且PRACH功率分散后，边缘前导码的接收信噪比下降。解决：先估算同时接入峰值，FDM够用就行。大部分宏站msg1-FDM=2或4足够，FDM=8一般是超大话务量场景且需要配套提升PRACH功率。改完FDM要回看上行RB利用率和边缘接入成功率，两个指标一起看，只看一个都会被误导。

5.4 SSB波束与PRACH occasion没对齐

现象：某个扇区方向上的终端接入成功率特别低，但其他方向正常。基站前导检测次数也有，就是感觉“差一点”。原因：SSB波束数量和PRACH occasion数量映射关系不对。最常见的是8波束站点只配了3或4个occasion，映射表里一部分SSB找不到自己的occasion，走那个波束的终端发前导码时撞到别的波束的窗口里。解决：把ssb-perRACH-OccasionAndCB-PreamblesPerSSB调成波束数量整除的格式，8波束就是1/8，如果occasion数量实在不够，用SSB-to-RO映射表的循环规则让多个SSB均匀共享occasion，同时确保共享SSB的前导码集合不重叠。

5.5 前导检测正常但Msg3重传高

现象：前导检测成功率和RAR成功率都正常，但Msg3重传率高，随机接入时延拖长。原因：竞争型随机接入的碰撞窗口没有配够。同一个PRACH occasion上分配的CB前导码数量太少，大量终端挤在同一组前导码里，碰撞概率被放大。解决：调大ssb-perRACH-OccasionAndCB-PreamblesPerSSB里前导码的部分，或者增加msg1-FDM。同时检查是否误把某些前导码划给了非竞争接入（比如切换），非竞争前导码占比过高会压缩竞争窗口，这种情况更隐蔽——查网管里前导码分组配置才能看出来。

6. 验证PRACH规划：三个指标加一套排查命令

参数配完不是结束，验证才是闭环。我验证PRACH规划时只盯三个指标：前导检测成功率、RAR成功率、Msg3重传率。前导检测成功率要大于99%，RAR成功率大于98%，Msg3重传率低于5%。任何一个指标不达标，按第5章的坑逐个对照。

基站侧的排查命令没有统一格式，各家厂商网管不同，但日志关键字是通用的。以常见Linux风格的网管后台为例，抓PRACH相关日志的套路是过滤前导码和随机接入关键字：

# 查看PRACH接收统计和根序列配置(以常见网管后台为例) mgmt_cli -c "show l1 measured prach-preamble-info" # 检查RAR发送失败的具体原因 grep -i "RAR.*fail" /var/log/net/phy/*.log # 按小区和根序列维度统计前导码冲突 grep -i "preamble.*collision" /var/log/net/phy/*.log | grep "cell=120"

最后我会拿着测试终端到这站的小区边缘走一遍路测，连续发起随机接入，观察从发前导码到收到RAR的时延。正常情况在几十毫秒以内，如果时延抖动明显，大概率是Ncs余量不够或者干扰没清干净。这个习惯改掉过我好几回“参数表看着都对但现场就是不顺”的玄学时刻，PRACH规划这东西，参数表只是纸面功夫，现场验证过了才算数。希望帮到你。

本文还有配套的精品资源，点击获取