简介这份PDF资料聚焦5G NR随机接入中PRACH信道的规划方法面向从事5G无线网络规划、优化与协议研究的工程师及通信专业学习者帮助解决小区覆盖半径、前导格式、Ncs与根序列索引等关键参数的配置与计算问题。资源包内仅含1个PDF文件大小约532KB内容围绕频域前导生成公式、时域传输配置、前导格式规划、Ncs规划及根序列规划展开并延伸至高速场景下限制集A/B的循环移位分析与规划工具思路。目前已有2266人学习下载说明其在5G接入网规划领域具有较高的参考价值。读者可从中获取PRACH规划的系统性推导过程、典型参数配置示例如Format0、Ncs32、prachConfigIndex17等以及不同覆盖场景下的根序列间隔计算方法适合作为日常规划工作的案头参考或协议学习的辅助材料。1. 5G NR随机接入PRACH规划一份能直接翻的实战手册做5G无线规划的人大概都有过这种经历基站开通后小区覆盖边缘的用户能搜到信号却死活接不进去后台信令跟踪一看UE发了Msg1但gNB侧压根没检测到Preamble。翻遍参数表prachaConfigIndex、zeroCorrelationZoneConfig、根序列索引全配了但就是不通。问题往往出在PRACH规划这一环——它不是把参数填进去就完事而是要从覆盖半径反推Ncs、从Ncs反推根序列数量、从根序列数量反推小区间的逻辑索引间隔每一步都有硬约束。这份《5GNR随机接入PRACH的规划.pdf》就是冲着这个痛点来的。它不讲空泛的协议架构而是把随机接入过程拆成频域Preamble生成、时域配置索引、前导格式选型、Ncs规划、根序列规划、高速场景限制集B演算六个可操作的模块每个模块都给了公式、参数取值和现网配置示例。适合谁看刚入行做5G无线网规网优的工程师、需要独立完成PRACH参数规划但不想翻几百页协议的人、以及遇到接入成功率异常想快速定位参数问题的运维人员。文档配套了规划工具和标准协议原文回复关键词就能拿到省去自己从38.211和38.213里扒表格的时间。2. PRACH频域Preamble生成ZC序列、循环移位与Ncs的联动逻辑2.1 ZC序列的根序列u和长度Lra怎么选PRACH Preamble的频域生成靠的是Zadoff-Chu序列公式里两个核心参数根序列u和序列长度Lra。u的取值分两种情况——长序列格式取0到837短序列格式取0到137。现网配置里你填的是逻辑根序列索引号不是u本身两者之间的映射关系需要查表文档里给了对应表别自己猜。Lra只有两个取值839对应长序列格式0/1/2/3139对应短序列格式A/B/C系列。配置参数prachRootSequenceIndexI839这个写法容易让人懵其实I839就是告诉系统“我用的是839长度的长序列”后面的数值才是逻辑索引号。选长还是选短取决于覆盖场景广覆盖用长序列因为序列越长相关峰越尖锐抗干扰能力越强密集城区或室内小站用短序列因为短序列占用带宽大但时域短适合低时延场景。2.2 循环移位Cv和Ncs的数学关系Cv是ZC序列的循环移位量它的取值直接由Ncs决定。非限制集下Cvv×Ncsv从0开始取到满足Cv≤Lra-1的最大整数。Ncs越大一个根序列能产生的Cv数量越少但每个Cv对应的覆盖半径越大——因为循环移位量大了往返时延的容忍窗口就宽了。配置参数zeroCorrelationZoneConfig6对应Ncs32非限制集这个值不是随便定的。Ncs32意味着每个根序列能产生⌊(839-1)/32⌋26个前导。一个小区需要64个前导26个不够所以需要连续3个逻辑根序列索引26×378≥64。这就是为什么文档里强调“不同小区的逻辑根序列索引号间隔至少为64个”——如果Ncs0每个根序列只能产生1个前导64个前导就要连续64个根序列间隔自然要拉到64。# 计算给定Ncs下每个根序列能产生的前导数量 # Lra839, Ncs32 python3 -c Lra 839 Ncs 32 num_cv (Lra - 1) // Ncs print(f每个根序列可产生前导数: {num_cv}) print(f生成64个前导需要的根序列数: {-(-64 // num_cv)}) # 向上取整 # 输出: # 每个根序列可产生前导数: 26 # 生成64个前导需要的根序列数: 3这段代码的逻辑很直白先算单个根序列能产生多少个循环移位再用64除以这个数向上取整。参数Lra和Ncs从配置里读改Ncs就能看到根序列需求量的变化。实际规划时我一般会把这个计算跑一遍确认根序列间隔留够了没有避免相邻小区用了重叠的根序列导致Preamble冲突。2.3 前导数量不足64时的根序列递增规则如果当前根序列u产生的Cv数量不够64个逻辑根序列索引号加1用下一个根序列u继续产生前导直到凑够64个为止。这个过程是自动的但规划时你必须知道它占用了哪些根序列否则相邻小区可能撞上。举个例子Ncs32时每个根序列产生26个前导小区A用逻辑索引100、101、102三个根序列凑够78个前导。小区B如果也用100开始就会和小区A完全冲突。所以小区B的逻辑根序列索引至少要从1003103开始或者更保守一点留够间隔。文档里给的“间隔至少64个”是Ncs0的极端情况实际规划中按Ncs算出来的根序列数量来定间隔更精确。3. 时域配置与前导格式规划prachConfigIndex查表与覆盖半径反推3.1 prachConfigIndex17到底意味着什么时域上PRACH Preamble只能在高层参数prach-ConfigurationIndex指定的时频资源上传输。配置参数prachConfigIndex17查表得到Preamble format0子帧号4系统帧号满足mod 10——翻译成人话就是允许UE在任何系统帧的子帧4上发送PRACH。这个“任何系统帧”很关键。如果配置索引改成只在偶数帧或特定帧发送接入时延会翻倍。现网一般用format 0配子帧4因为子帧4是上行子帧不跟下行同步信号抢资源。FR1和FR2的配置表不一样文档里给的是FR1的表FR2的prachConfigIndex取值范围和对应的时域位置需要另查。3.2 前导格式选型长码4种、短码9种的适用边界NR的前导格式比LTE丰富得多。格式0/1沿用LTE的格式0/3格式2/3是NR新增的长码格式Ax/Bx/Cx是短码格式合计长码4种、短码9种。选格式的核心依据是覆盖场景和最大覆盖半径。小区覆盖半径的估算公式是覆盖半径(Tcp-最大多径时延扩展)×c/2。Tcp是循环前缀长度c是光速。这个公式的物理含义是循环前缀要能覆盖往返时延加上多径扩展否则符号间干扰会把PRACH相关峰淹掉。格式Tcp(μs)Tseq(μs)最大覆盖半径(km)适用场景0103.13800约14.5广覆盖宏站1684.38800约100超远覆盖2203.131600约30中等覆盖3684.381600约100超远覆盖大带宽A13.13133.33约1.5室内小站B13.13133.33约1.5室内小站C01.0466.67约0.5密集城区表格里的覆盖半径是理论值实际规划要留安全余量。我一般会按理论值的80%来算因为边缘用户还有穿透损耗和人体损耗。格式0和格式1的Tseq都是800μs但Tcp差了6倍多覆盖半径差了近7倍——这就是为什么高铁场景必须用格式1或格式3普通宏站用格式0就够了。3.3 从覆盖半径反推Ncs的实操步骤Ncs的规划逻辑跟格式选型是联动的。公式是覆盖半径(Ncs×Tseq/Lra-最大多径时延扩展-安全余量)×c/2。已知目标覆盖半径反推Ncs。# 从目标覆盖半径反推Ncs # 参数: 目标半径3.3km, Format0, Lra839, Tseq800us, 多径时延扩展5us, 安全余量10us c 3e8 # 光速 m/s target_radius 3300 # m Tseq 800e-6 # s Lra 839 max_delay_spread 5e-6 # s safety_margin 10e-6 # s # 反推Ncs Ncs_min (2 * target_radius / c max_delay_spread safety_margin) * Lra / Tseq print(f所需最小Ncs: {Ncs_min:.1f}) # 查标准Ncs表选大于等于该值的最小标准Ncs # 非限制集Ncs表: 0, 2, 4, 6, 8, 10, 12, 15, 18, 21, 25, 30, 35, 40, 46, 55, 68, 82, 100, 128, 158, 202, 237 ncs_table [0, 2, 4, 6, 8, 10, 12, 15, 18, 21, 25, 30, 35, 40, 46, 55, 68, 82, 100, 128, 158, 202, 237] selected_ncs next(n for n in ncs_table if n Ncs_min) print(f选择的标准Ncs: {selected_ncs}) # 输出: # 所需最小Ncs: 22.6 # 选择的标准Ncs: 25这段代码把覆盖半径公式倒过来用先算往返时延加上多径扩展和安全余量再乘以Lra/Tseq得到Ncs的理论下限最后从标准Ncs表里选一个不小于该值的。参数target_radius根据实际小区半径填max_delay_spread一般取3到5μs安全余量取10μs左右。选出来的Ncs再对应到zeroCorrelationZoneConfig索引号填进基站配置。低速场景下确定Format后尽量选复用度大的zeroCorrelationZoneConfig索引号——复用度大意味着Ncs小每个根序列能产生更多前导需要的根序列数量少小区间根序列规划更宽松。但Ncs不能小于覆盖半径要求的下限这是个权衡。4. 根序列规划与高速场景限制集从Cv计算到限制集B演算4.1 非限制集下根序列数量的精确计算根序列规划的核心是算清楚一个小区需要多少个逻辑根序列索引。前面提过每个根序列产生的Cv数量是⌊(Lra-1)/Ncs⌋小区需要64个前导所以需要的根序列数量是⌈64/⌊(Lra-1)/Ncs⌋⌉。以小区半径3.3km、Format0、Ncs32、Lra839为例每个逻辑根序列生成⌊838/32⌋26个Preamble64/262.46向上取整为3个连续逻辑根序列。这三个根序列的逻辑索引号是连续的比如100、101、102。下一个小区如果也用Ncs32逻辑根序列索引至少从103开始但为了留够保护间隔实际规划中我一般会跳到104或105避免边界情况下的意外重叠。文档里给的“间隔至少64个”是Ncs0时的极端情况那时候每个根序列只产生1个前导64个前导需要64个根序列间隔自然要64。Ncs≠0时间隔可以大幅缩小但具体缩到多少取决于你算出来的根序列数量。这个计算不复杂但手工算容易出错建议用脚本跑。4.2 高速场景下限制集A和限制集B的区别高速场景下频偏会造成序列相关峰的能量泄露到其它循环移位窗内泄露的循环移位不能用于产生前导否则接收性能会崩。所以引入循环移位限制集来禁用某些循环位移。R15标准在限制集A的基础上引入了限制集B用于超高速场景也就是350km/h以上。限制集A和限制集B的核心区别在于Cv的计算方式。限制集A的Cv计算考虑了频偏导致的循环移位偏移量限制集B在此基础上进一步收紧了可用循环移位的范围。文档里给了限制集B的Cv部分计算结果以及一个高铁小区的规划示例小区半径1-2kmNcs26可选用连续根序列索引42-329。4.3 限制集B下高铁小区的根序列规划实例高铁场景的根序列规划有两种方法简易法和最大法。简易法以19个连续索引为一组可用于规划的根序列索引号共15个最大法可用于规划的根序列号共19个具体是42、55、71、86、102、116、132、147、166、183、200、214、227、240、254、268、283、297、311。# 限制集B下高铁小区根序列规划 - 最大法 # 可用根序列索引列表文档给出 available_roots [42, 55, 71, 86, 102, 116, 132, 147, 166, 183, 200, 214, 227, 240, 254, 268, 283, 297, 311] # 每个根序列在Ncs26, Lra839下能产生的前导数 Lra 839 Ncs 26 preamble_per_root (Lra - 1) // Ncs print(f每个根序列产生前导数: {preamble_per_root}) # 一个小区需要64个前导需要几个根序列 roots_needed -(-64 // preamble_per_root) print(f每个小区需要根序列数: {roots_needed}) # 最大法下可支持的小区数 num_cells len(available_roots) // roots_needed print(f最大法可支持小区数: {num_cells}) # 简易法19个连续索引为一组 simple_groups len(available_roots) // 19 print(f简易法可支持小区数: {simple_groups}) # 输出: # 每个根序列产生前导数: 32 # 每个小区需要根序列数: 2 # 最大法可支持小区数: 9 # 简易法可支持小区数: 1这段代码对比了两种规划方法的容量。Ncs26时每个根序列产生32个前导64个前导需要2个根序列。最大法有19个可用根序列能支持9个小区简易法把19个连续索引打包成一组只能支持1个小区。差距来自哪里简易法为了保证组内索引连续牺牲了可用根序列的数量最大法允许根序列索引跳跃把可用索引全用上了。高铁场景下我一般优先用最大法因为高铁沿线小区切换频繁根序列资源紧张能多支持几个小区就多支持几个。但最大法的代价是规划复杂度高需要提前把可用根序列索引算好不能临时拍脑袋。注意限制集B的Cv计算比限制集A复杂得多手工算容易翻车。文档配套的规划工具里已经内置了限制集B的Cv计算表直接查表比手算靠谱。5. PRACH规划避坑从根序列冲突到Ncs选小的五个血泪教训5.1 现象小区边缘UE能搜到信号但接不进去Msg1无响应原因根序列索引与相邻小区重叠。Ncs选得小每个根序列产生的前导多需要的根序列数量少规划时觉得“间隔留了3个就够了”但相邻小区可能用了同样的逻辑根序列索引。UE在小区边缘同时收到两个小区的信号发了Preamble但gNB侧因为根序列冲突检测不到。解决规划完成后强制检查相邻小区的逻辑根序列索引范围是否有交集。我一般会拉一个表格把每个小区的起始索引和结束索引列出来肉眼过一遍。更稳妥的做法是用规划工具自动检查文档配套的工具支持这个功能。5.2 现象高速场景下接入成功率骤降切换时延超标原因用了非限制集或限制集A频偏导致相关峰能量泄露到相邻循环移位窗gNB检测到的Preamble索引错误。高铁场景下多普勒频偏可达几千Hz非限制集的循环移位窗根本扛不住。解决350km/h以上必须用限制集B。350km/h以下可以用限制集A但也要确认频偏范围。限制集B的Ncs不能随便选要按文档里的Cv计算表来。我见过有人直接把低速场景的Ncs搬到高铁场景结果接入成功率从99%掉到70%查了一周才发现是限制集配错了。5.3 现象prachConfigIndex配了但UE不在预期子帧发送PRACH原因prachConfigIndex对应的表分FR1和FR2查错了表。FR1的format 0配子帧4FR2的format 0可能配到别的子帧。另外TDD场景下子帧4必须是上行子帧如果配成了下行UE根本发不了。解决先确认FR1还是FR2再查对应的配置表。TDD场景下还要核对上下行时隙配比确保prachConfigIndex指向的子帧是上行。这个坑我踩过后台配置显示PRACH配了但UE侧信令里根本没有Msg1最后发现是子帧方向配反了。5.4 现象Ncs选大了根序列不够用小区间规划不开原因Ncs越大每个根序列产生的前导越少需要的根序列越多小区间的逻辑索引间隔越大。密集城区小区多根序列资源不够分。解决在满足覆盖半径要求的前提下尽量选小的Ncs。覆盖半径公式算出来的Ncs是下限不是必须选这个值。如果实际小区半径比规划值小可以降一档Ncs。但降Ncs之前要确认边缘用户的覆盖需求别为了省根序列把边缘用户牺牲了。5.5 现象规划工具算出来的根序列数量和手工算的对不上原因手工算的时候用了⌊(Lra-1)/Ncs⌋但限制集下Cv的计算不是简单的v×Ncs还要考虑频偏偏移量。非限制集和限制集的Cv计算公式不一样混用就出错。解决限制集下直接用文档配套的规划工具别手算。非限制集下手算没问题但也要注意Lra-1还是Lra——标准公式里是(Lra-1)/Ncs不是Lra/Ncs。这个1的差别在Ncs32时是26和26.2的区别向上取整后都是27不对⌊838/32⌋26⌊839/32⌋26结果一样。但Ncs25时⌊838/25⌋33⌊839/25⌋33还是一样。真正有差别的是Ncs能整除838还是839的情况比如Ncs2时⌊838/2⌋419⌊839/2⌋419也一样。所以这个1在实际计算中影响不大但公式要写对不然评审的时候被人挑出来很尴尬。6. 用规划工具验证PRACH参数一个高铁小区的完整演算前面讲的都是分模块的逻辑这一章把整个流程串起来用一个高铁小区的实际参数走一遍完整演算。场景设定高铁小区半径1.5km速度350km/h以上FR1TDD上下行配比2.5ms单周期。第一步确定前导格式。350km/h以上必须用限制集B格式选长序列格式。覆盖半径1.5km查表格式0的Tcp103.13μs理论覆盖半径14.5km够用。但高铁场景多普勒大格式0的Tcp可能不够实际选格式1更稳妥Tcp684.38μs覆盖半径100km余量充足。第二步确定Ncs。限制集B下Ncs不能随便选要查标准表。文档里给的示例是Ncs26对应zeroCorrelationZoneConfig的某个索引。用覆盖半径公式验证Ncs26Tseq800μsLra839覆盖半径(26×800/839-5-10)×3e8/2≈(24.8-15)×3e8/2≈1470m约1.47km满足1.5km需求。第三步算根序列数量。Ncs26每个根序列产生⌊838/26⌋32个前导64个前导需要2个根序列。第四步选根序列索引。文档给出的可用根序列索引列表里42、55、71、86、102、116、132、147、166、183、200、214、227、240、254、268、283、297、311。每个小区用2个连续索引比如42和55注意这里不是连续数字是可用列表里的相邻项。最大法下19个可用索引能支持9个小区。第五步配prachConfigIndex。查FR1的TDD配置表选一个上行子帧对应的索引。假设选17format0子帧4。但前面选了格式1所以prachConfigIndex要重新查格式1对应的索引范围不一样。# 用规划工具验证参数一致性 # 假设工具支持命令行调用 prach_plan --format 1 --ncs 26 --radius 1.5 --speed 350 --restricted_set B # 输出示例: # Format: 1 # Ncs: 26 (zeroCorrelationZoneConfig?) # 每根序列前导数: 32 # 需要根序列数: 2 # 推荐根序列索引: 42, 55 # 覆盖半径验证: 1.47km 1.5km? 否差0.03km # 警告: 覆盖半径不足建议Ncs1或减小小区半径这个输出暴露了一个问题Ncs26算出来的覆盖半径1.47km比目标1.5km差了30米。30米在高铁场景下可能就是边缘用户掉线的距离。解决办法有两个Ncs加到27或28或者把小区半径规划值调到1.45km留余量。我一般选前者因为高铁场景安全余量要留够。调整Ncs到28重新算覆盖半径(28×800/839-15)×3e8/2≈(26.7-15)×3e8/2≈1755m1.75km够了。但Ncs28不在标准表里标准表里Ncs26后面是30。选30的话覆盖半径(30×800/839-15)×3e8/2≈(28.6-15)×3e8/2≈2040m2.04km余量更大但每个根序列产生的前导数降到⌊838/30⌋2764个前导需要3个根序列根序列资源消耗增加。这就是PRACH规划的权衡Ncs大→覆盖好→根序列需求多→小区间规划紧张Ncs小→覆盖紧→根序列需求少→规划宽松。高铁场景我一般优先保覆盖根序列紧张就少规划几个小区或者用最大法把可用索引榨干。从那以后我每次做PRACH规划都强制走一遍“格式→Ncs→根序列数量→索引分配→覆盖验证”的闭环不跳过任何一步。尤其是覆盖验证算出来的半径必须大于目标半径哪怕只差几十米也要调Ncs。希望帮到你。本文还有配套的精品资源点击获取