企业官网建设流程全解析

简介：第五代移动通信新空口（5G NR）网络中的物理随机接入信道（PRACH）格式与映射是网络优化与故障排查的关键环节。文档系统讲解PRACH如何承载用户设备（UE）的随机接入前导、辅助基站（gNB）校准上行时钟及其他参数，并围绕Zadoff-Chu序列生成、两种格式差异、不同场景下的配置参数展开，明确序列长度839用于FR1广覆盖（支持1.25或5KHz子载波间隔），序列长度139适用于小范围覆盖（FR1支持15或30KHz，FR2支持60或120KHz）。物理层部分阐述PRACH与数据共享FFT资源、OFDM基带信号遵循3GPP TS38.211第5.3.2节规范，并给出未收到随机接入响应时的分层排查思路。资源为单个docx文档，压缩包仅158KB，内容高度浓缩，文档结构清晰，按功能、格式、配置、物理层处理四个模块逐层递进，便于快速导读与反复查阅。目前已有550人浏览学习，适合5G网络优化工程师、通信专业学生及一线运维人员系统掌握PRACH设计与排障方法，提升对随机接入过程的理解和实际优化能力。通过这份文档可快速掌握PRACH从序列设计到参数配置再到物理层实现的完整链路，是应对5G网络优化中随机接入类问题的实用参考。

1. 5G NR网络里，PRACH格式和映射为什么值得单独拿出来讲

5G基站和5G网络架构的日常规划与运维里，PRACH（物理随机接入信道）格式和映射配置是最容易被低估的一环。很多工程人员拿到一张“能跑通”的配置模板就直接搬，直到接入性能翻车，才回头翻PRACH参数——这时候再排查，投入产出比已经极低。实际上，PRACH格式决定了小区能覆盖多远、能容忍多高的终端移动速度，映射则决定前导码在时频资源上的具体位置、以及它和SSB之间的关联关系。这篇笔记沿着“格式选择→时域映射→频域映射→排错→验证”这条主线，把PRACH格式和映射讲透，适合正在做5G NR小区规划、基站开通前参数配置或接入性能优化的工程人员对照使用。

2. PRACH格式怎么选——长前导码与短前导码两条路线

2.1 长前导码格式0/1/2/3：把覆盖做上去

5G NR的PRACH前导码序列有两种长度：L=839的长码和L=139的短码。长码的子载波间隔只有1.25 kHz或5 kHz，ZC序列长度839，是典型的用较长的时域占用换取接收检测能力的设计。4种长码格式（0、1、2、3）的CP（循环前缀）长度和序列重复次数都不一样。CP越长，能容忍的往返时延越大，小区覆盖半径就越大；序列重复次数越多，检测增益越高，但时域开销也成倍增加。

格式0的CP约103μs，理论覆盖半径约15km，是长码里的“家用款”。绝大多数城区宏站、郊区普通覆盖场景都够用，也是很多默认配置模板的首选。格式1的CP拉到约684μs，覆盖半径能到100km以上，典型用在海面、戈壁、草原这类超远覆盖场景。但它的代价很直接：每个前导码占用接近1ms的时域资源，同样一个子帧里能容纳的随机接入尝试次数极少，接入容量非常有限。在用户密度稍高的远郊站点配格式1，高话务时段基本一定会看到随机接入拥塞。

格式2的CP约152μs，序列重复两次，覆盖约23km，对抗干扰有优势，适合岛屿、近海这类中远距离覆盖。格式3比较特殊，它把子载波间隔提升到5kHz，序列时域更短，多普勒鲁棒性更好，覆盖约9km，常配在高铁沿线。这里有个易被忽略的点：同是a1.25kHz SCS的长码，格式2因为序列重复两次，它的实际时域长度是格式0的两倍，TDD帧结构里如果上行可用符号本来就不多，配格式2很容易把整个上行子帧占满，导致PUSCH没有调度空间。

2.2 短前导码A/B/C系列：把容量和调度灵活性做上去

短前导码L=139，子载波间隔可选15kHz、30kHz或60kHz，前导码时域占用非常短，是5G NR里接入容量优化的主力。A系列、B系列、C系列的核心差异同样是CP长度。A1~A3的CP从约9μs逐步增加到约28μs，对应覆盖半径从约2.5km到约7km，其中A2和A3带有序列重复，检测增益更好。B1~B4的CP从约7μs到约40μs，覆盖半径从约1km到约9km。C0~C2则在B系列的基础上把CP做得更长，C2的CP超过130μs，在短码体系里覆盖半径最远，能达到十几公里级别。

短前导码因为可以在一个时隙内放入多次PRACH尝试，单位时间能容纳的接入用户数远高于长码，是密集城区、室内、微站的标配。但使用短码时要注意：它能用哪种格式，依赖系统当前的SCS和帧结构。比如15kHz SCS下可用A1/B1/C0组合，而30kHz SCS时对应的是另一组表条目。最终具体能配哪种格式，要回到prach-ConfigurationIndex对应的协议表里去查，不是想配哪个配哪个。实际组网里经常有人拿着长码场景的配置模板改短码，结果在30kHz SCS下对应不到合法格式，基站侧直接报配置错误。

2.3 格式选择是一场覆盖、容量、移动性的三方权衡

格式选择本质是三边权衡：覆盖半径、接入容量、多普勒容忍度，三者不可能同时拉满。我一般按这个顺序决策：先算覆盖需求，站点间距和边缘目标覆盖率决定需要的CP长度。覆盖超过30km只有格式1可选；15km~30km之间可以选长码格式2或短码C2；5~15km之间优先格式0或短码C系列；低于5km直接用A/B系列。

再看移动速度。接入终端如果常处高速移动，比如高铁线路覆盖，优先格式3或短码配合限制集配置，否则多普勒频移会让检测概率显著下降。最后算接入容量：估算高峰时段的RRC连接请求次数，反推需要的RO数量。必要时把覆盖目标略微压低，换取更多RO。这套逻辑在5G组网与运维的方案评审里常被拿出来考察。很多工程师在这里犯的错，是只盯着覆盖半径选格式，忽略了单位时间RO数量的上限。长码格式1一个子帧里只有少数几个RO位置，一个满载小区在高话务时段很容易出现接入拥塞；而用短码A系列，同样时间窗口内能塞入的接入机会明显更多。

3. 时域映射——从prach-ConfigurationIndex反推RO位置

3.1 一个整数索引背后的完整查表逻辑

prach-ConfigurationIndex是一个0~255的整数，在RRC配置里它只是一个数字，但在协议里它对应一张维度很宽的查找表（3GPP TS 38.211的6.3.3.2-2至6.3.3.2-9系列表格）。表格的快照信息包括：PRACH出现在哪些帧、哪些子帧、配置周期、起始符号、每个时隙内PRACH次数等。这些信息组合起来，决定了前导码在时域上占哪几个符号位置。

这里最容易犯的错是“拿来主义”——上一个项目用配置索引2能跑通，新项目换了个SCS或换了个帧结构（比如从15kHz FDD换到30kHz TDD），还继续用索引2。实际上表格是按SCS、帧结构拆开的，同一个索引号在不同SCS下对应的时域位置完全可能不同。以格式0、15kHz SCS、FDD场景为例，配置索引为0通常对应PRACH被安排在偶数帧的子帧0发送；配置索引为1则变成每个帧的子帧0都有PRACH。两者之间的选择，直接影响每秒钟有多少个RO可供接入。如果你配的索引对应PRACH在子帧7发送，而这个TDD帧结构里子帧7是下行，结果就会变成传输冲突，接入必然失败。

3.2 一小时域位置的推算步骤

我一般会这样推算PRACH时域位置，拿短码格式A1、30kHz SCS、TDD帧结构举例：拿到prach-ConfigurationIndex的值，假设当前配置为某个索引值。从30kHz SCS对应的协议表中查到该条目，假设内容包括：PRACH配置周期是10ms（即每10个帧为一个周期），在周期内的某指定子帧的第几个符号起，连续占用2个符号。接下来把配置周期、子帧编号、起始符号三个信息放到TDD的上下行时隙配比里核对，确认该子帧是上行而不是下行，同时确认起始符号之后连续几个符号没有被SSB或PUCCH占用。如果该子帧被配为下行，则该索引用不了，必须重选一个。

这个过程没有太多玄学，核心就是查表加核对帧结构。真正麻烦的是：协议表有将近300行，手动查容易看走眼。我通常写一个小脚本把表结构导出来直接搜索，或者用MATLAB 5G工具箱的PRACH配置导出函数来交叉校验。查询时还要注意版本差异——某些运营商基站软件版本使用的prach-ConfigurationIndex表格来自3GPP不同release，条目的内容可能有细微差别。同一份配置在R16和R17基站上查询的结果不同，这种事我在现网见过不止一次。所以配置下发前，最好先在目标基站版本的协议文档里拉出对应表格核对一遍，别直接拿旧表格套新版本。

3.3 restrictedSetConfig和循环移位的连带关系

时域映射确定之后，还要处理一个容易忽略的限制集参数restrictedSetConfig。对于高速场景，如果保持普通循环移位（非限制集），多普勒频移会造成相邻循环移位之间相关峰混叠，前导检测概率显著下降。此时需要将限制集配置为1或2，并重新规划根序列索引prach-RootSequenceIndex。这两个参数必须一起调整，否则新的限制集配置可能没有足够的可用循环移位数量来支撑目标覆盖半径。

实际配置里，很多默认模板的restrictedSetConfig都是0（非限制集）。如果你负责的是高铁或高速5G基站覆盖，务必把它改成1，同时从协议表中选择适合的根序列。做这一步时还要注意：限制集配置为1和2对应的根序列可用循环移位数量又不一样，分别适合不同的覆盖等级。改完之后用基站日志里的前导检测统计对比一下，多普勒频移场景下的检测成功率一般能有明显回升。这一步不做，后面路测发现问题时，往往会把排查方向错误地带到天线或RRU硬件上，白白浪费一到两个晚上。

4. 频域映射与SSB-RO关联——PRACH落在哪个RB上

4.1 msg1-FrequencyStart和msg1-FDM参数

时域位置定下来后，频域映射由两个参数直接控制。msg1-FrequencyStart是PRACH频域起始位置，单位是RB，相对当前BWP的起始点偏移。默认值0表示从BWP最低RB开始。如果BWP的子载波间隔与PRACH不同，比如BWP是15kHz而PRACH用的是30kHz，要注意单位换算：偏移量需要按PRACH对应的SCS折算成RB数量，而不是直接拿两个不同SCS的RB编号对齐。

msg1-FDM是PRACH在频域上的复用次数，取值为1、2、4或8。它的含义是在同一个时域RO上，频域间隔地安排多个PRACH机会。FDM=4时，同一个时隙里可以有4个并行RO服务于不同频段的终端，接入容量直接乘4。但FDM不是越大越好：频域上多个PRACH占用的总带宽变宽，如果系统带宽本身不大，很容易挤占PUCCH或PUSCH的资源。同时，相邻小区的PRACH如果FDM配置不同，频率错位后可能形成干扰，影响前导检测。

实操里我通常先在OMC的频谱资源视图里看看PUCCH和PUSCH的占用情况，再回头定msg1-FrequencyStart，避免把PRACH栽到PUCCH的RB里。用公式核对时，PRACH占用的RB范围大致等于起始偏移加上PRACH实际占用的物理资源块宽度。不同PRACH格式在频域占用的RB数量不同，长码格式占6个RB，短码格式占12个RB。把占用范围拉出来和PUCCH配置区间做一次交集计算，有重叠就调整起始位置，这是最基础也最有效的频域避让手段。

4.2 SSB到RO的关联映射

“PRACH格式和映射”里的“映射”还有个更常被忽略的部分——SSB到RO的关联。终端在发起随机接入之前，先做小区搜索和波束测量，选定一个最合适的SSB波束。随后它需要在这个SSB对应的RO上发送前导码，基站才能知道它选了哪个波束。这个对应关系由ssb-perRACH-OccasionAndCB-PreamblesPerSSB参数控制。它同时定义了两件事：每个RO关联多少个SSB，以及每个SSB分配多少个基于竞争的（CB）前导码。

具体的关系是：一个RO上的总可用前导码数是64。如果每个RO关联1个SSB，则64个前导码全归这个SSB；如果关联4个SSB，则理论每个SSB分到16个前导码；如果关联8个SSB，每个SSB只剩8个前导码。前导码变少，多个终端撞同一个前导码的概率就增大，接入碰撞概率随之上升。这里还需要注意，CB前导码数量通常不会配到理论上限，因为还要为切换、波束失败恢复等基于非竞争的随机接入预留前导码。比如关联4个SSB时每个SSB配12个CB前导码，总占用48个，剩余16个留给非竞争场景。

实际组网里常见的错误是把SSB关联数配得过大。在SSB波束数量已经确定的场景，如果每个RO关联的SSB过多，反而会让单波束可用前导码变少。正确做法不是把关联数调大，而是增加RO的频域密度（msg1-FDM）或提高RO时域周期，把接入负载拆散到更多RO上。

4.3 一个完整的PRACH配置参数示例

实际站点上prach-Config大概长这样，以常见的5G SA宏站、覆盖约10km、30kHz SCS TDD场景为例：

prach-Config { prach-ConfigurationIndex 2, msg1-FDM 4, msg1-FrequencyStart 16, prach-RootSequenceIndex 22, restrictedSetConfig 0, ssb-perRACH-OccasionAndCB-PreamblesPerSSB ssb-perRACH-Occasion four, cb-PreamblesPerSSB 12 }

这里prach-ConfigurationIndex=2在30kHz SCS对应的表里通常意味着PRACH在周期内指定的子帧发送；msg1-FDM=4提供频域4路复用；msg1-FrequencyStart=16让PRACH从RB16开始，绕开了PUCCH常用的低RB区域；ssb-perRACH-Occasion为four表示每个RO关联4个SSB，每个SSB分配12个CB前导码，预留16个给非竞争场景。这样的配置在覆盖、容量和资源隔离之间做到了基本平衡。

5. PRACH配置避坑指南——5条踩坑记录

5.1 prach-ConfigurationIndex查表错位

现象：站点开通后，路测发现终端在近点接入没问题，远点完全无法完成随机接入，但下行RSRP正常，SIB1也能正常解码。

原因：当前prach-ConfigurationIndex与SCS组合下，查表得到的PRACH时域位置落在了下行时隙里。这类配置在OMC侧不一定报错，因为参数本身合法，只是与帧结构不兼容。

解决：第一步把OMC配置里的SCS、帧结构、prach-ConfigurationIndex三项拉出来，对照TS 38.211表格逐项核对。第二步根据帧结构重选索引，随后在LMT上重新下发prach-Config，并观察远点接入是否恢复。重点是排查前先确认版本对应的表格，别拿旧的release表来套新基站版本。

5.2 SSB-per-RO配置过大引发前导碰撞

现象：接入成功率只有70%左右，但RRC资源、RB资源都没到顶，后台指标显示随机接入冲突率高。

原因：每个RO关联了8个SSB，每个SSB只有8个CB前导码。多波束配置下用户一多，多个终端选择同一个前导码的概率飙升，碰撞后终端只能退避重试。

解决：把ssb-perRACH-Occasion从eight改成four，同时把msg1-FDM从1提升到2，用频域密度补偿单RO关联数减少带来的接入机会下降。注意邻区干扰严重时不要无限提高FDM，否则本小区与邻区PRACH在频域上错开不足，反而造成前导互相干扰。

5.3 频域重叠导致上行功控异常

现象：基站侧检测到PRACH信号有能量但解码不出来，或者检测时延明显波动，前导检测成功率时高时低。

原因：msg1-FrequencyStart把PRACH频域起点放在了PUCCH占用的RB上，两个上行信道在频域发生重叠。PRACH接收功率和PUCCH功控互相影响，导致前导序列相关检测被干扰。

解决：通过后台的频域资源占用视图查看RB占用，重新设置msg1-FrequencyStart，在PRACH与PUCCH之间留出至少4~6个RB的保护间隔。如果系统带宽紧张，优先压缩PUCCH的RB分配，而不是压缩PRACH的保护带。

5.4 高速场景未启用限制集

现象：高铁沿线站点，终端接入时反复前导冲突，或接入时延超过2秒，路测中多次出现RRC建立失败重试。

原因：restrictedSetConfig=0，多普勒频移使循环移位相关峰发生偏移甚至重叠，基站侧检测时把不同循环移位混淆。

解决：配置restrictedSetConfig=1，同步更换prach-RootSequenceIndex到适合限制集的根序列。改完后用基站日志里的前导检测统计对比，重点看高速区段的前导检测成功率是否回升。若仍不理想，再检查是否同时用了合适的前导格式，比如短码A系列在30kHz SCS下的多普勒性能要好于长码。

5.5 RO数量不足导致高话务时段拥塞

现象：话务高峰期接通率下降，基站侧随机接入请求量触顶，但CPU、PRB利用率看起来都不高，呼损告警集中在随机接入拥塞。

原因：PRACH时域周期过长，或FDM频域复用次数过低，导致单位时间内可用RO数量远小于终端接入请求量。高峰期所有RO被占满，后续终端只能等待下一个周期。

解决：估算高峰期并发接入次数，按每个RO大约承载一次成功接入的经验值反推所需RO数量。必要时把prach-ConfigurationIndex换成更密集的周期，同时提升msg1-FDM至4或8。改完配置后要在高话务时段复查接入成功率，确认瓶颈转移而不是消失。

6. 验证PRACH配置的实操技巧——从参数反推覆盖能力

6.1 用Python脚本从CP时长估算覆盖

拿到格式参数后，我习惯先用一小段脚本快速算一遍理论覆盖。代码很简单，但能避免很多低级错误：

# 根据CP时长估算PRACH理论覆盖半径 def max_distance(cp_us, gt_us=None): c = 3e8 # 光速，单位 m/s if gt_us is None: # 假设保护时段至少等于CP，实际配置中GT会限制最终覆盖 gt_us = cp_us total_delay_us = cp_us + gt_us # 往返时延预算是CP+GT的总和 distance_m = total_delay_us * 1e-6 * c / 2 return distance_m / 1000 # 转成 km # 格式0长码：CP约103.1μs，理论覆盖约15.5km print(f"格式0 => {max_distance(103.1):.1f} km") # 短码A2在30kHz SCS下CP约18.7μs print(f"A2(30kHz) => {max_distance(18.7):.1f} km") # 短码C2 CP约132μs print(f"C2 => {max_distance(132):.1f} km")

运行后三个print会分别给出理论覆盖半径。注意这个估算忽略了对GT的精确建模，实际覆盖可能小于CP理论值，所以工程上我会留10%~20%的余量。比如理论15km的格式0，站点覆盖目标定在13km以内才稳妥。

6.2 用OMC日志反推TA值

最直接的验证不是看配置，而是看结果。在OMC或RRU侧导出PRACH检测记录，观察成功接入终端的TA分布。如果TA最大值接近配置格式的理论覆盖上限，说明覆盖边界正卡在配置临界点上，需要把格式放宽或站点间距缩小。如果TA分布普遍小于理论值的50%，说明当前格式偏保守，可以尝试增大容量相关配置，比如换用占用时域更短的格式来提高接入容量。

6.3 路测场景验证

最后一步一定是路测。选远点、中远点、近点三个点位，分别记录从随机接入发起到RRC连接建立完成的时延。理想情况下，三个点位的接入时延差异应在几十毫秒以内；如果远点接入时延明显拉长，多半是PRACH重传次数增多，回头检查格式CP和SSB-RO关联是否过紧。我自己在做5G NR基站配置评审时，最后的习惯动作是翻出PRACH的配置索引查一遍表、用脚本重算一次覆盖、对比路测TA值。这套流程虽然机械，但每次都能在验收前发现一两处低级错误，省下的返工时间远超做这件事的投入。希望帮到你。

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