简介《5GNR随机接入PRACH的规划》是一份面向5G无线网络规划优化人员、通信工程学习者及网络优化工程师的专题文档围绕随机接入中的前导规划展开涵盖竞争与非竞争接入、频域前导生成、时域资源配置、前导格式选择、循环移位与根序列规划等要点帮助读者把小区覆盖半径、前导数量、逻辑根序列索引间隔等参数串联起来。资源包共1个PDF文件约532KB内容集中便于按主题检索和批注。已有2267人学习下载在5G NR接入参数规划场景中具有一定参考价值。文档结合现网参数示例说明前导配置索引、零相关区配置、限制集类型等设置并延伸至高速场景限制集A/B与根序列复用规划适合从事PRACH参数核算、覆盖评估及高铁场景规划的一线读者查阅。1. 为什么PRACH规划总在“根序列不够用”上翻车做5GNR随机接入PRACH的规划最容易翻车的不是公式抄错而是根序列数量、Ncs和时域配置三者没有对齐。某地网络把小区半径从1.5km改到3.3kmprachConfigIndex没动zeroCorrelationZoneConfig还停在6现场接入成功率掉得莫名其妙。翻协议表才发现Ncs32时每个根序列只能产生26个前导64个前导要连续吃掉3个逻辑根序列邻区如果还按老间隔分配根序列就撞了。这份PDF把ZC序列、Cv、根序列索引、时域配置和高速限制集串成一条线还带了规划工具和协议附表适合做无线规划、参数核查、高速场景优化的从业者拿着直接复算。2. 拆开PRACH协议骨架ZC序列、Cv和64个前导的硬约束2.1 随机接入的两条路竞争与非竞争随机接入过程的目的很明确一是实现UE和gNB之间的上行同步二是获取Message3的资源。落到规划上这两个目的会直接决定前导资源怎么分。基于竞争的随机接入里多个UE可能生成相同的PRACH Preamble并同时到达gNBgNB要靠后续冲突解决过程判断谁接入成功基于非竞争的随机接入里gNB直接指定PRACH Preamble给UE常见场景是切换目的是避开冲突。这两种类型对PRACH规划的影响不一样。竞争场景下一个小区要凑齐64个有效前导根序列、Ncs、Cv都要围着这个目标算非竞争场景下gNB指定前导意味着要给专用前导留出余量不能把64个前导全部按竞争场景分干净。实际做规划时我一般先把小区按场景分类普通覆盖小区、切换密集小区、高速小区。普通小区可以按竞争为主来配切换密集小区要预留专用前导高速小区还要把限制集和频偏泄露算进去。随机接入类型触发场景前导来源规划影响基于竞争初始接入、重建、上行失步UE从可用前导中随机选每小区要凑够64个前导根序列数量要算足基于非竞争切换、部分特殊场景gNB指定前导要预留专用前导不能把64个全部分给竞争这张表不是让你背概念而是提醒一件事64个前导不是永远都能全部拿来给竞争用。资料里的规划工具会把前导总数、专用前导预留、根序列索引放在一张表里核对手算容易漏掉预留量。2.2 ZC序列、根序列u和Cv到底谁决定谁频域PRACH Preamble的生成公式是x_{u,v}(n) x_u((n C_v) mod L_RA)其中x_u(n)是ZC序列u是根序列L_RA是ZC序列长度C_v是循环移位。u的取值在长码下是0~837短码下是0~137。工程参数里填的是逻辑根序列索引号不是u本身逻辑索引和u的对应关系要查表资料里的协议附表就是干这个用的。L_RA取839或139对应长码和短码。C_v的取值取决于Ncs和限制集类型由小区半径、应用场景等因素决定。关键在C_v的数量。非限制集下C_v v*Ncsv从0开始取能产生的C_v数量是floor((L_RA-1)/Ncs)。每个C_v对应一个前导所以一个根序列u能产生多少个前导直接由Ncs决定。如果当前u产生的前导不够64个逻辑根序列索引号加1用下一个根序列u继续产生直到凑满64个。项目正文里的例子是restrictedSetConfig非限制集、zeroCorrelationZoneConfig6、Ncs32L_RA839每个根序列能出26个前导64/26向上取整等于3所以一个小区要连续占用3个逻辑根序列索引。import math def preamble_count_unrestricted(lra, ncs): 非限制集下单个根序列能产生的PRACH前导数量。 if ncs 0: return 1 # Ncs0时Cv只有0一个根序列只出1个前导 return (lra - 1) // ncs for lra, ncs in [(839, 32), (839, 0), (139, 32), (839, 46)]: per_root preamble_count_unrestricted(lra, ncs) need_roots math.ceil(64 / per_root) print(fLra{lra}, Ncs{ncs}, 每根序列前导数{per_root}, 凑64个需根序列{need_roots})这段代码只算非限制集。参数lra是ZC序列长度长码填839短码填139ncs是循环移位步长不是逻辑索引号。输出里Ncs32、Lra839时每根序列26个前导需要3个根序列Ncs0时每根序列只有1个前导需要64个根序列。短码Lra139、Ncs32时每根序列只有4个前导要16个根序列才够64个这就是短码场景根序列规划更紧的原因。限制集A/B不能直接套这个函数Cv的计算规则变了必须查表或用资料里的高速规划工具。注意同一zeroCorrelationZoneConfig索引在不同限制集下Ncs不同。项目正文表里索引6在非限制集是32在限制集A和B是46不能只记一个32就到处填。2.3 用一张表把Lra、Ncs、格式绑在一起PRACH前导格式分长码和短码。格式0/1沿用LTE的格式0/3格式2/3、Ax、Bx、Cx是NR新引入的合计长码4种、短码9种。长码用Lra839短码用Lra139。格式按覆盖场景、最大覆盖半径规划不是随便挑一个索引。Ncs表有三张分别对应子载波间隔1.25kHz、5kHz和15*2^u kHz选错表Ncs就全错。参数常见取值作用规划时看什么L_RA839长码、139短码ZC序列长度长码广覆盖短码亚毫秒级、适合密集小区Ncs0、32、46等循环移位步长由小区半径、多径时延扩展、安全余量反推zeroCorrelationZoneConfig6等查Ncs表的索引同一索引在不同限制集下Ncs不同restrictedSetConfig非限制集、限制集A、限制集B是否启用循环移位限制高速场景必须切限制集350km/h以上看B集prachRootSequenceIndex逻辑索引号根序列起点不是u本身要查逻辑索引与u的映射表prachConfigIndex17等时域PRACH配置决定前导格式、子帧位置、周期这张表建议贴在规划表旁边。很多人只盯prachRootSequenceIndex忘了zeroCorrelationZoneConfig和restrictedSetConfig是联动的。项目正文里给的配置组合是prachRootSequenceIndexI839、restrictedSetConfig非限制集、zeroCorrelationZoneConfig6、prachConfigIndex17对应Ncs32、Format0、子帧4。这是一组能跑通的基线但换小区半径、换高速场景就要重新算不能整组照抄。3. 频域规划落地Ncs反推半径与根序列数量的手算脚本3.1 覆盖半径反推Ncs公式、Tseq和安全余量小区覆盖半径的公式是小区覆盖半径 (Ncs*Tseq/Lra - 最大多径时延扩展 - 安全余量) * c / 2Tseq是前导序列持续时间跟着前导格式走长码Format0按协议表取800us量级短码按对应格式查。Lra是序列长度。最大多径时延扩展按场景估普通城区取几微秒复杂环境取更大。安全余量是给同步误差、设备时延、多径抖动留的我一般留3~5us高速或复杂多径场景会再放大。c是光速。C 3e8 # 光速m/s def radius_km(ncs, tseq_us, lra, delay_us, margin_us): 按Ncs反算小区覆盖半径单位km。 guard_us ncs * tseq_us / lra - delay_us - margin_us if guard_us 0: return 0.0 # 保护间隔被吃光配置不可用 return guard_us * 1e-6 * C / 2 / 1000 # Format0长码示例Ncs32Tseq800usLra839多径5us安全余量5us print(radius_km(32, 800, 839, 5, 5))这段代码算出来约3.08km。参数ncs32tseq_us800lra839delay_us5margin_us5。项目正文的例子是小区半径3.3km、Format0、Ncs32、Lra839量级对得上差异来自多径和安全余量的取值。实际规划时不要拿一个固定余量套所有站型密集城区多径重余量留小会把半径算大现场就会出现循环移位窗重叠。把公式反过来用已知小区半径先减多径和安全余量再反推Ncs最后去Ncs表里找不小于计算值的索引。提示Tseq不要手填一个固定值。长码和短码的Tseq不同同一格式族里不同格式也不同资料里的规划工具会按格式自动带出Tseq手算时至少回到协议表核对一遍。3.2 根序列够不够64个手算与脚本复算一个小区需要产生64个有效的PRACH Preamble。首次用根序列索引号按所有有效的循环偏移Ncs得到Cv如果本次根序列不能产生64个前导就用逻辑根序列索引号的下一个继续产生直到凑满64个。Cv的计算过程决定了当前小区产生64个前导需要多少个根序列也决定了根序列索引号怎么规划。import math def roots_needed(lra, ncs, target64): 返回每小区所需根序列数单根序列前导数。仅非限制集。 per_root 1 if ncs 0 else (lra - 1) // ncs return math.ceil(target / per_root), per_root for ncs in [0, 32, 46]: need, per_root roots_needed(839, ncs) print(fNcs{ncs}: 单根序列{per_root}个前导每小区需{need}个根序列)输出很直观Ncs0时单根序列1个前导每小区要64个根序列所以规划时不同小区的逻辑根序列索引号间隔至少64个Ncs32时单根序列26个前导每小区3个根序列Ncs46时单根序列18个前导每小区4个根序列。这里的“所需根序列数”是向上取整实际分配还要加隔离带。比如Ncs32、每小区3个根序列相邻小区起始索引至少隔3个留1个隔离就隔4个。项目正文里的例子是3.3km、Format0、Ncs32、Lra839每逻辑根序列26个前导64/262.46向上取整3和脚本一致。短码场景要单独算。Lra139、Ncs32时单根序列只有4个前导每小区要16个根序列逻辑索引消耗很快。短码小区密集时根序列规划表要留出更多余量不能按长码的3个根序列习惯去分。3.3 根序列索引分配连续索引还是留隔离带根序列索引分配有两种常见做法连续分配和留隔离带。连续分配是把一个小区需要的根序列索引连续占满比如小区A占0~2小区B从3开始占3~5。留隔离带是在小区之间空1~2个索引比如A占0~2B从4开始占4~6。隔离带的作用是降低相邻小区根序列重叠的概率也给后续扩容留余地。高速场景下限制集B的Cv不是连续等间隔某些索引不能用隔离带要按工具算出来的可用索引组来留。示例小区起始逻辑索引占用索引数隔离索引数备注小区A031Ncs32每小区3个根序列小区B431与A隔1个索引小区C831与B隔1个索引高速小区D42按限制集B工具结果按组留不能套非限制集连续分配def allocate_roots(start, roots_per_cell, cell_count, gap1, max_index837): 生成非限制集下的根序列分配示例gap是小区间隔离索引数。 plan [] idx start for cell in range(1, cell_count 1): if idx roots_per_cell - 1 max_index: raise ValueError(逻辑根序列索引越界需要回绕并避开已用索引) plan.append((fcell_{cell}, idx, idx roots_per_cell - 1)) idx roots_per_cell gap return plan for row in allocate_roots(0, 3, 5, gap1): print(row)这段代码生成5个示例小区的分配每小区3个根序列小区间留1个隔离。参数start是起始逻辑索引roots_per_cell是每小区所需根序列数cell_count是小区数gap是隔离数max_index是逻辑索引上限。实际工程里还要避开已经分配给邻区的索引资料里的规划工具可以直接导入邻区表做冲突检查。高速场景不要用这个函数限制集B的可用索引是成组的项目正文里高铁小区1~2km、Ncs26的例子用简易法以19个连续索引为一组可用根序列索引共15个用最大法可用19个具体索引是42、55、71、86、102、116、132、147、166、183、200、214、227、240、254、268、283、297、311。这个结果必须按限制集B的Cv演算来不能拿非限制集的连续分配去套。4. 时域规划落地prachConfigIndex17的子帧映射与格式选型4.1 prachConfigIndex17为什么落在子帧4PRACH Preamble只能在高层参数prach-ConfigurationIndex给出的时域上传输具体取决于FR1还是FR2。项目正文给的配置是prachConfigIndex17查表可知Preamble format0允许UE在任何系统帧的子帧4上发送PRACH。这里的“任何系统帧”不是每个子帧都能发而是每10ms周期里落在子帧4这一个机会上。时域密度直接决定PRACH容量子帧4被PRACH占用后这个子帧上的业务信道调度要避开。prach_config: prach_ConfigurationIndex: 17 # 高层参数查表得到格式和子帧 preamble_format: 0 # 由索引17反查不是单独随意配 subframe: 4 # 索引17对应的时域位置 period_ms: 10 # 任何系统帧的子帧4周期10ms restricted_set_config: unrestricted zero_correlation_zone_config: 6 prach_root_sequence_index: 0这段配置片段里prach_ConfigurationIndex是入口参数preamble_format、subframe、period_ms都是查表结果不是独立配置项。现场最容易犯的错是只抄prachConfigIndex17却没确认当前频段和FR类型对应的表是不是同一张。FR1和FR2的PRACH配置表不同同一个索引在不同表里可能对应不同格式或不同子帧。配置核查时先把索引号、格式、子帧、周期四个字段一起对再去看根序列和Ncs。时域密度还要和容量匹配。子帧4每10ms一次适合普通覆盖小区密集城区或高话务小区如果PRACH容量不够要换更密的配置索引但换了索引可能连格式一起变Ncs和根序列规划要跟着重算。资料里的协议附表把索引、格式、子帧号放在同一张表里规划时直接查表比背索引可靠。4.2 长码与短码格式的选型边界长码4种、短码9种选型边界主要看覆盖半径、多径环境、频段和时延扩展。长码Format0/1/2/3适合广覆盖Format0是项目正文里的基线Format1/2/3随着序列时长变化覆盖能力和资源占用不同。短码Ax/Bx/Cx是NR新引入的适合FR2、密集小区、亚毫秒级时延场景。格式选错后面Ncs和根序列算得再细也白搭。格式族L_RA覆盖特点典型场景规划注意长码Format0/1/2/3839覆盖半径大时域占用相对长FR1广覆盖、普通宏站先按半径选格式再反推Ncs短码Ax/Bx/Cx139亚毫秒级适合密集部署FR2、室内、密集城区根序列消耗快要算足64个前导限制集A按格式高速但非超高速中高速移动场景Cv计算查限制集A表限制集B按格式超高速350km/h以上高铁等高速场景用高速规划工具演算Cv不能手套选型步骤我一般按这个顺序走先确认FR1还是FR2再确认小区半径和多径环境然后查协议表选格式接着用覆盖半径公式反推Ncs最后算根序列数量。这个顺序不能反。先算根序列再选格式很容易出现格式覆盖不够、Ncs被迫改大、根序列数量又不够的连环翻车。项目正文说前导格式按照覆盖场景、最大覆盖半径规划这句话是规划顺序的总结不是一句空话。4.3 用表格核对FR1/FR2的时域配置FR1和FR2的PRACH时域配置差异大核查时用一张表把频段、子载波间隔、Ncs表、典型格式、Lra绑在一起能少踩很多坑。Ncs表有三张分别对应子载波间隔1.25kHz、5kHz和152^u kHz。152^u kHz里的u是子载波间隔索引u0对应15kHzu1对应30kHzu2对应60kHzu3对应120kHz。选Ncs时先确认当前PRACH子载波间隔落在哪张表再去查zeroCorrelationZoneConfig。频段类型典型PRACH子载波间隔Ncs表典型格式L_RA时域核查点FR1长码1.25kHz、5kHz1.25kHz表、5kHz表Format0/1/2/3839prachConfigIndex查出的子帧和周期FR1短码15kHz、30kHz15*2^u kHz表A/B/C系列139时域密度是否够根序列是否够64个FR2短码60kHz、120kHz15*2^u kHz表A/B/C系列139子载波间隔与格式匹配避免跨表抄索引核查时按四步走确认频段和PRACH子载波间隔确认prachConfigIndex查出的格式和子帧确认zeroCorrelationZoneConfig落在正确的Ncs表确认restrictedSetConfig和场景匹配。四步里任何一步跨表后面的根序列计算都会偏。项目正文里的prachConfigIndex17、Format0、子帧4是一组FR1长码基线换到FR2不能直接沿用。5. 避坑与复核PRACH规划落地前必须走的五条检查5.1 现象根序列数量算出来够现场却接不进现象是规划表上每小区3个根序列、64个前导算得满满当当现场接入成功率却上不去随机接入失败计数偏高。原因通常不是数量不够而是逻辑根序列索引和u的映射查错或者restrictedSetConfig填了非限制集但实际场景需要限制集导致Cv可用数量比预期少。还有一种情况是Ncs表选错1.25kHz的表套到了5kHz上算出来的每根序列前导数偏大实际可用前导不够。解决时先别急着加根序列回到三件事确认prachRootSequenceIndex是逻辑索引还是u查资料里的映射表确认restrictedSetConfig和场景一致确认zeroCorrelationZoneConfig查的是当前子载波间隔对应的Ncs表。三件事对完再用规划工具复算Cv数量。排查时看随机接入前导检测的虚警和漏检计数如果虚警高优先怀疑根序列复用太近如果漏检高优先怀疑Ncs和保护间隔。5.2 现象小区半径改大后Ncs没跟着改现象是小区半径从1.5km扩到3.3km工程参数只改了半径字段zeroCorrelationZoneConfig还停在原来的索引Ncs没变。现场表现为远点UE接入困难近点正常。原因是Ncs决定循环移位窗宽度半径变大后最大多径时延扩展和安全余量吃掉更多保护间隔原Ncs对应的窗不够用循环移位之间发生重叠。解决时按覆盖半径公式重算先用新半径加多径和安全余量反推需要的保护间隔再反推Ncs最后去Ncs表里选不小于计算值的索引。项目正文的例子是3.3km、Format0、Ncs32、Lra839这个组合是基线不是所有3.3km小区都必须用32多径重的场景安全余量要放大Ncs可能要大一级。改完Ncs后根序列数量会变每小区所需根序列数和邻区间隔要一起重算不能只改一个参数就交表。5.3 现象高速场景仍按非限制集配现象是高速小区、高铁沿线小区还在用restrictedSetConfig非限制集规划表上根序列数量够现场高速移动时接入成功率波动大。原因是高速频偏会让序列相关峰的能量泄露到其它循环移位窗内泄露的循环移位不能用于产生前导非限制集下这些窗没有被限制使用接收性能会下降。R15标准在限制集A的基础上引入限制集B用于超高速场景350km/h以上要按B集演算。解决时先把restrictedSetConfig切到限制集A或B再按对应Cv规则重新算可用前导。限制集B的Cv不是等间隔项目正文里高铁小区1~2km、Ncs26的例子用简易法以19个连续索引为一组可规划根序列索引共15个用最大法可规划19个具体索引是42、55、71、86、102、116、132、147、166、183、200、214、227、240、254、268、283、297、311。这个结果要用资料里的高速规划工具复算手算容易漏掉不可用循环移位。5.4 现象prachConfigIndex抄了邻区但格式不匹配现象是新建小区直接抄邻区的prachConfigIndex参数表上索引一样现场却出现PRACH时域位置和邻区冲突或者格式和覆盖需求不匹配。原因是prachConfigIndex不是孤立参数它绑定了Preamble format、子帧号、周期FR1和FR2的表还不同。邻区用Format0覆盖广新建小区是密集城区短码站型抄同一个索引就会把长码配置带到短码场景。解决时按当前频段和FR类型查表确认索引对应的格式、子帧、周期再和小区覆盖需求对一遍。项目正文的prachConfigIndex17对应Format0、子帧4、任何系统帧发送这是FR1长码基线。换到FR2或短码场景索引要重新选。核查时把prachConfigIndex、preamble format、subframe、period四个字段一起打印出来任何一项和规划意图不符就退回重选。5.5 现象根序列复用距离太近导致虚警现象是相邻小区根序列索引间隔太小规划表上每个小区的前导数量都够现场却出现前导虚警gNB把邻区前导误判成本区前导。原因是根序列复用距离小于每小区所需根序列数或者隔离带留得不够。Ncs32时每小区要3个根序列如果两个小区起始索引只隔1个实际占用的索引会重叠。高速场景限制集B的可用索引是成组的复用距离更不能按非限制集的连续索引去估。解决时按每小区所需根序列数加隔离带来分配普通场景至少留1个索引隔离高速场景按工具算出的可用索引组来留。项目正文里Ncs0时每小区要64个根序列不同小区逻辑根序列索引间隔至少64个Ncs≠0时按floor((Lra-1)/Ncs)算每根序列前导数再向上取整得到每小区所需根序列数。分配完用规划工具做一次邻区冲突检查重点看同频邻区、高速沿线小区、切换关系密集的小区。6. 把规划表变成可复核脚本三个断言和一条血泪习惯PRACH规划表交出去之前我习惯用三个断言做最后一道复核每根序列前导数够不够、每小区根序列数够不够64个前导、邻区间隔有没有小于每小区所需根序列数。这三个数任何一个不满足后面参数配得再漂亮都是纸面功夫。import math def check_prach_plan(lra, ncs, roots_per_cell, index_gap, target64): 交表前复核前导数、根序列数、邻区间隔。仅非限制集。 per_root 1 if ncs 0 else (lra - 1) // ncs need_roots math.ceil(target / per_root) assert roots_per_cell need_roots, f根序列不足: {roots_per_cell} {need_roots} assert index_gap roots_per_cell, f邻区间隔太小: {index_gap} {roots_per_cell} return per_root, need_roots # 示例Lra839Ncs32每小区3个根序列邻区间隔3 print(check_prach_plan(839, 32, 3, 3))参数lra和ncs决定单根序列前导数roots_per_cell是规划表里每小区实际占用的根序列数index_gap是相邻小区起始索引间隔。断言通过只代表非限制集下数量逻辑成立限制集A/B还要把Cv可用性加进去高速场景直接用资料里的规划工具跑一遍。从那以后我每次出PRACH规划表都先把Ncs、每根序列前导数、所需根序列数、邻区间隔这四个数跑一遍断言再拿协议附表核对prachConfigIndex和子帧最后才交给前台。希望帮到你。本文还有配套的精品资源点击获取
