简介面向5G网络优化与规划工程师详解5G NR PRACH接入信号规划方法。内容覆盖Preamble序列生成ZC序列839/139两种长度、循环前缀CP与保护间隔GP的设计逻辑以及long preambleformat 0/1/2/3与short preambleA/B/C系列各格式的适用场景包括常规覆盖、超远覆盖、弱覆盖、高速移动等典型环境。同时说明相邻小区Preamble格式、频域起始位置、时间偏移协调以及ZC根序列规划与Ncs取值对小区覆盖半径和接入性能的影响。资源为1个PDF文档大小2.22MB便于随时查阅。已有647人学习浏览。文档结合Preamble结构、小区覆盖半径计算和华为5G RAN 2.1版本配置限制给出从基础原理到实际参数规划的操作指引适合从事5G无线网络规划优化、需要深入理解随机接入信道配置的读者。1. 5G NR PRACH接入信号规划基站开通前最容易“看不见”的一步新开一个5G基站gNB配置下发完成终端在小区里搜得到SSB却始终不发起注册后台一查gNB侧PRACH检测次数为0或者检测到了preamble但TA值和站间距完全对不上RRC建立成功率直接掉到谷底。这种问题在网络开通调测和全网排障里非常常见而定位到最后多半都出在PRACH接入信号规划上。PRACH是终端开机、切换、失步恢复或波束失败后第一次主动向基站“喊话”的物理信道终端选一条preamble发出去基站根据检测到的preamble估算TA并分配C-RNTI整个5G信令流程才算真正跑起来。规划PRACH并不是“配个索引号”那么简单它同时决定覆盖半径、干扰隔离、容量上限和高速场景下的检测可靠性。这篇把PRACH规划从理论到落地拆开讲适合做5G网络规划、基站开通调测和性能优化的工程师新手能照着步骤做完一套熟手也能在参数边界和干扰处理上找到可用的经验。2. 先定PRACH preamble格式长短格式的覆盖与容量取舍2.1 5G preamble长格式和短格式共有多少种各自能扛多大覆盖5G NR的preamble序列分两大体系长格式和短格式。长格式基于ZC序列长度839短格式基于ZC序列长度139。不少人问“5G preamble序列格式中长格式有多少种”答案并不复杂3GPP TS 38.211里定义了4种长格式Format 0/1/2/3和9种短格式A1、A2、A3、B1、B2、B3、B4、C0、C2合计13种。长格式和短格式不能混用一个小区在一个PRACH配置里只能选其中一种。格式选择的第一决定因素是覆盖半径。长格式的序列时长长接收端能累积的能量多同样的发射功率下可以覆盖更远短格式序列短适合小站和毫米波场景配合mu1或mu2的子载波间隔时频开销小。下面是常用格式的典型参数和覆盖能力格式ZC长度序列时长SCS最大覆盖半径参考典型场景Format 0839571.3us1.25kHz约14km普通城区宏站最常用Format 18392857us1.25kHz100km以上海面、沙漠、超远覆盖Format 28392x876.5us1.25kHz约77km大功率广覆盖站、高容量远覆盖Format 38391757us5kHz约29km大站且需要较短GT、兼顾容量A1/A2/A3139133/267/400us15/30/60kHz1~5km城区分层、室内、微站B1~B4139133~571us15/30/60kHz2~8km普通宏站短格式部署C0/C2139571/1144us15/30kHz5~12km需要更大覆盖的短格式覆盖半径的计算核心不是序列本身而是GTGuard Time保护时间。PRACH前导在子帧末尾发送GT要能吞下“最远终端发过来的信号到达基站所需的时间”减去“TA预估时间”的余量。GT不够远端终端的preamble尾部会撞进下一个子帧的PUSCH区域产生干扰GT太宽时间资源闲置容量白白浪费。所以规划的第一步不是查表选格式而是先算清楚这个站要覆盖多远。2.2 用站间距和GT估算选择PRACH格式落到gNB配置常见做法是先根据站型定目标覆盖半径再反推需要的GT和preamble时隙结构。小区半径R对应的最大往返时延约为R / 150000秒电波传播速度近似3e8m/s往返除以2后按6.7us/km计算更直观。我一般会用下面这段Python脚本做初选输入目标覆盖半径输出推荐的PRACH格式候选和配置要点# prach_format_select.py # 输入目标覆盖半径km # 输出推荐的PRACH格式候选及GT余量检查 def gt_for_radius(radius_km): # 光速 3e8 m/s往返时延 2 * R / c # 转换为 us1km 往返约 6.67us return radius_km * 2 * 1000 / 299792458 * 1e6 def check_format(cfg, radius_km): gt gt_for_radius(radius_km) ok OK if cfg[gt_us] gt else GT不足 return f{cfg[name]:10} GT{cfg[gt_us]:8.2f}us 需要GT{gt:8.2f}us - {ok} formats [ {name: Format0, gt_us: 428.7}, # 1ms时隙序列571.3us余下为GT {name: Format1, gt_us: 2143.0}, # 3ms时隙序列2857us {name: Format2, gt_us: 2287.5}, # 2个序列总序列1753us {name: Format3, gt_us: 1243.0}, # 2ms时隙序列1757us {name: A2/mu1, gt_us: 533.0}, # 2符号序列 尾随GT {name: B4/mu1, gt_us: 1133.0}, ] radius float(input(目标覆盖半径(km): )) for f in formats: print(check_format(f, radius))这段脚本的输出逻辑很清楚GT是格式里“没有承载序列的那一段时隙余量”。Format 1之所以能覆盖100km以上是因为它的GT高达约2143us远远超过百公里往返时延的666us留了巨大的安全余量Format 0只有约428us的GT折合覆盖半径约30km但实际网络里要考虑干扰余量和TA不确定性做14km以内的城区站更稳妥。选好格式后基站侧的RRC配置体现在SIB1里的prach-ConfigurationIndex、msg1-FrequencyStart、rootSequenceIndex和msg1-SubcarrierSpacing这些参数上。例如一个典型的宏站配置prach-Config: prach-ConfigurationIndex: 0 # Format 0每帧子帧1发送 msg1-FrequencyStart: 4 # 频域偏移4个RB msg1-FDM: 1 # 频分复用份数 msg1-SubcarrierSpacing: kHz1_25 # 长格式对应1.25kHz rootSequenceIndex: 117 # 逻辑根序列 restrictedSetConfig: UNRESTRICTED # 低速场景这里prach-ConfigurationIndex: 0对应的就是Format 0占1ms在偶数帧的子帧1发送。参数里的数字不是随便写的每个索引都在38.211 Table 6.3.3.2-2/3/4里对应一组明确的时域规则后面第4章会展开算。3. 根序列与循环移位PRACH干扰规划的“第一道栅栏”3.1 逻辑根序列、物理根序列和Ncs如何决定小区容量PRACH的preamble是由ZC序列循环移位生成的。一个小区能同时使用多少条正交的preamble取决于“根序列数量 × 每个根序列能生成的循环移位个数”。逻辑根序列索引从配置里下发rootSequenceIndex终端和基站根据它映射到物理根序列u逻辑根到物理根的映射表在38.211 Table 6.3.3.1-1/2/3里然后基于u生成ZC基序列再按循环移位Ncs生成多条preamble。循环移位Ncs的取值不是连续的38.211规定了若干离散档位。长格式下Ncs可以是0、1、2、6、7、8、9、10、11、12、13、15、17、19、23、27、31、38、46、59、76、93、119、167、279、419等短格式另有对应表。Ncs越大每条preamble之间的最小间隔越大抗时延扩展和多普勒能力越强但一个根序列能分出的preamble数量就越少。具体的可用preamble数计算公式为零相关区长度 Ncs 对应的一个根序列可生成 ⌊839 / Ncs⌋ 条长格式或 ⌊139 / Ncs⌋ 条短格式Ncs0时只有1条基序列可用于无循环移位场景。每个小区固定需要64条preamble。如果一条根序列不够就顺延到下一个逻辑根序列。相邻小区如果用了相同的根序列且Ncs覆盖范围重叠检测时会出现preamble互踩。规划根序列的原则很简单相邻小区错开逻辑根序列的起始点让“相同根序列的小区之间”距离大于Ncs能覆盖的时延范围。另一个容易忽略的点是Ncs不仅影响容量还直接影响可支持的最大小区半径。因为循环移位的间隔必须大于传播时延带来的相位差加多径扩展否则基站会把相邻移位间的preamble误检成另一个用户。3.2 高速移动场景必须用Restricted Set高铁和高速公路场景下多普勒频移破坏了ZC序列的循环移位正交性会产生一个“多普勒频移导致的伪峰”。如果配置的是UNRESTRICTED这个伪峰可能落在另一个循环移位的检测窗里造成两个终端同时发preamble时互相误检。5G NR为此引入了受限集restricted set。受限集A和受限集B在高速场景下重新定义了允许使用的循环移位把容易受多普勒影响的移位剔除只保留抗频偏的移位。代价是容量下降1249号Ncs档位下受限集的可用移位数量明显少于非受限集。5G网络开通调测里如果涉及高铁专网这个参数必须检查不能拿宏站的UNRESTRICTED配置直接复用。配置层面只需要改一个字段restrictedSetConfig: RESTRICTED_SET_A # 高铁/高速场景对应38.211表里的A类注意RESTRICTED_SET_A不是所有Ncs档都支持选Ncs时要对应查38.211里restricted集合合法的Ncs值。选错会让gNB直接拒绝配置。3.3 用python给一组连续小区分配根序列起始点和Ncs针对一批连续扇区常见的规划方式是给每个小区指定一个起始逻辑根序列然后按容量需求顺序占位。下面这段脚本可根据每个小区的覆盖半径计算合法Ncs并自动分配不重叠的根序列区间# pnach_root_plan.py # 输入小区列表名称、目标覆盖半径(km) # 输出每个小区的起始根序列、Ncs、占用根序列个数 ZC_LEN 839 # 长格式 def valid_ncs_long(): return [0, 1, 2, 6, 7, 8, 9, 10, 11, 12, 13, 15, 17, 19, 23, 27, 31, 38, 46, 59, 76, 93, 119, 167, 279, 419] def pick_ncs(radius_km): # 覆盖半径R对应往返时延约6.67us/km取Ncs中大于2*R*6.67的最小值 need_us radius_km * 2 * 6.67 for n in valid_ncs_long(): if n 0: continue if n need_us: return n return max(valid_ncs_long()) def preambles_per_root(ncs): if ncs 0: return 1 return ZC_LEN // ncs def plan(cells): next_root 0 for name, radius in cells: ncs pick_ncs(radius) per_root preambles_per_root(ncs) roots_needed (64 per_root - 1) // per_root print(f{name:12} radius{radius:5.1f}km Ncs{ncs:3d} f每根序列{per_root:3d}条 需要根序列{roots_needed:2d} f起始根序列{next_root:3d}) next_root roots_needed if next_root 838: print(根序列不足需降低Ncs或调整小区半径) break cells [ (Cell_A, 6.0), (Cell_B, 5.0), (Cell_C, 12.0), (Cell_D, 7.5), ] plan(cells)这个脚本里的核心逻辑是把“覆盖半径”先转成“所需Ncs”再算“每个根序列能提供多少条preamble”最后从0号逻辑根序列开始顺序分配。实际工程里往往还要留根序列余量而不是恰好分配完。比如上面示例Cell_C半径12km需要的Ncs比较大占用的根序列会明显增多这和第2章格式选择的覆盖能力是联动的覆盖太远要么用长格式大Ncs换检测可靠性要么牺牲小区内可接入用户数同时竞争的preamble数。4. PRACH时频资源规划配置索引、频域偏移和FDM的设置4.1 prach-ConfigurationIndex查表与子帧计算PRACH的时域位置由prach-ConfigurationIndex查表确定这个索引决定了PRACH“在哪些无线帧、哪些子帧、从哪个符号开始”。很多调测工程师看到配置里写prach-ConfigurationIndex: 16以为这只是个编号其实它背后是一整套时域规则。下面列出几个典型配置便于理解索引格式每帧发送次数发送无线帧子帧号起始符号0Format 01偶数帧1015Format 01每帧1016Format 01每帧1, 6032Format 11偶数帧1096Format A22每帧0, 80107Format B41每帧00配置索引的计算逻辑在38.211里是用表格直接查的不涉及复杂公式但落地时可以用脚本验证当前索引是否满足某个子帧偏移需求。比如需要“每帧都在子帧5发一次”就在表里找每帧发送次数1且子帧号5的行找到对应索引填到配置里。4.2 msg1频域位置和guard band设计时域定好之后频域位置由msg1-FrequencyStart和msg1-FDM共同决定。msg1-FrequencyStart表示PRACH的起始RB相对公共资源块0的偏移而msg1-FDM表示同一时刻在频域上放几份PRACH资源取值1/2/4/8用于提升容量。多个FDM副本之间要留guard band避免不同根序列的PRACH在频域边缘相互泄漏干扰。频域规划的一个重要约束是PRACH不能占用已经配置给PUCCH/PUSCH的核心资源块更不能和SSB的频域位置冲突。工程上通常把PRACH放在上行带宽边缘靠近PUCCH的一侧但不要紧贴留出至少几个RB的保护间隔。做5G网络测试与优化的时候最容易遇到的问题是PRACH频域和PUCCH重叠或者两个FDM副本间隔太小导致检测侧出现“某种根序列下的preamble在邻区干扰下误检率升高”。4.3 用python生成可查的PRACH时频位置表把配置索引、频域偏移和FDM一起放进脚本可以直接输出一份时频位置表方便和后台日志、路测数据对照# prach_time_freq_table.py def prach_sfn_subframes(cfg_index): # 简化示例实际应从38.211表中取配置 table { 0: {format: 0, sfn_mod: 2, sfn_rest: 0, subframes: [1]}, 16: {format: 0, sfn_mod: 1, sfn_rest: 0, subframes: [1, 6]}, 96: {format: A2, sfn_mod: 1, sfn_rest: 0, subframes: [0, 8]}, } return table.get(cfg_index, table[0]) def freq_start_rb(freq_start, fdm_index, fdm_num, prach_rb_width): # fdm_index 从0开始 gap 1 # 每个FDM副本之间的保护RB工程上可调 return freq_start fdm_index * (prach_rb_width gap) cfg 16 fdm 4 fs 4 info prach_sfn_subframes(cfg) print(fprach-ConfigurationIndex{cfg} 格式{info[format]}) print(f每{info[sfn_mod]}帧发送子帧{info[subframes]}) for i in range(fdm): rb freq_start_rb(fs, i, fdm, 6) # 长格式PRACH占6个RB print(fFDM副本{i1}: 起始RB{rb}, 占用RB{rb}~{rb5})脚本输出的频域结果可以直接和基站后台的physicalResourceBlock占用图比对。注意prach_rb_width在不同格式下不一样长格式Format 0~3在15kHz子载波间隔参照下占6个RB72个子载波×15kHz对应到1.25kHz序列占6个RB短格式A/B/C类在30kHz SCS下通常占12个RB。计算时如果SCS参照选错频域位置会差一整倍这是常见的坑。5. 规划完怎么验收PRACH排障的三个见效技巧5.1 直接看prach检测日志不要只看RRC建立成功率PRACH规划合不合理第一现场是gNB物理层检测日志。后台统计里preambleDetected次数远小于终端发起的随机接入尝试基本可以断定是配置问题而不是射频问题。抓日志时过滤prach关键词重点看每条记录里的preambleIndex、timingAdvance和rsrp如果RSRP正常但TA超出预期范围优先怀疑Ncs不够或格式覆盖不足。5.2 TA值突变先查根序列和Restricted Set某扇区用户上报的TA从几个us突然跳到几十us且集中在同一时段往往是相同根序列的邻区PRACH串扰而不是终端移动造成的。处理办法是查相邻站的rootSequenceIndex是否相同再看是否误配了UNRESTRICTED。高铁沿线站点按第3.2节方式直接切到RESTRICTED_SET_A并重算Ncs能消除大部分误检。5.3 把PRACH频域图和数据面PUSCH放在一张图里查重叠最后一个技巧是把PRACH占用的RB范围可视化叠加PUCCH/PUSCH的调度边界。下面这段脚本从基站导出的RB配置文档里统计PRACH的RB占位并标出与PUSCH重叠的部分# 从gNB配置导出的txt里抽取msg1-FrequencyStart和FDM grep msg1-FrequencyStart\|msg1-FDM gNB_config.txt先确认这两个字段的值再带入第4.3节的脚本得到起始RB列表然后把列表和上行PUSCH资源分配表对比。实测里重叠通常发生在FDM2时第三个副本越过了规划保护带。发现重叠后优先调整msg1-FrequencyStart让整个PRACH带整体上移或下移而不是单独调某个FDM副本因为协议规定FDM副本之间等间隔分布。做完这几项检查PRACH规划是否合理基本可以量化确认检测次数对得上、TA值符合站间距、频域无重叠、高速场景无误检。遇到5G全网排障和5G网络开通调测时这套流程能帮你把随机接入问题收敛到物理层参数上而不是反复重启基站碰运气。本文还有配套的精品资源点击获取