5G NR随机接入PRACH规划：前导序列、Ncs与根序列详解

简介这份PDF资料聚焦5G NR随机接入中PRACH信道的规划方法面向无线网络规划工程师、5G优化人员及通信专业学习者帮助解决小区覆盖半径、前导格式、Ncs参数与根序列索引等实际配置难题。资源包共1个PDF文件大小约532KB内容围绕PRACH规划展开涵盖随机接入过程目的、竞争与非竞争两类接入方式、频域前导生成公式、时域配置索引对应关系以及前导格式、Ncs、根序列和高速场景下的规划思路。文中结合现网参数示例如prachConfigIndex17对应Format 0、zeroCorrelationZoneConfig6对应Ncs32并给出小区半径3.3km时根序列数量的推算过程还涉及限制集B在350km/h以上高速场景的Cv计算与根序列分组方法。目前已有2267人学习下载适合需要系统掌握PRACH规划逻辑、对照协议参数完成小区配置与覆盖估算的读者参考。1. 5GNR随机接入PRACH的规划为什么手机开机第一件事是“喊一嗓子”你有没有想过手机开机后屏幕上那个小小的信号格是怎么冒出来的它其实经历了一场看不见的“点名”——手机要先向基站喊一嗓子基站听到了才会给它分配资源、建立连接。这一嗓子在5G NR里就叫随机接入而承载这声呼喊的物理通道就是PRACH物理随机接入信道。搞懂PRACH的规划本质上是在搞明白一件事基站怎么在成千上万台设备同时“喊话”的时候还能准确分辨出每一台这背后涉及前导序列怎么生成、循环移位怎么算、根序列怎么分配、高速场景下又该怎么调整。这些概念听起来像天书但拆开来看每一个都有它不得不存在的理由。这份资料把PRACH规划的完整逻辑链条梳理了一遍从随机接入的目的到前导格式的选择再到Ncs和根序列的规划方法最后落到高速场景下的特殊处理。看完你至少能明白为什么基站规划不是随便填几个参数就完事以及那些看起来枯燥的索引号背后到底在解决什么问题。2. 随机接入到底在接入什么从“敲门”到“对上暗号”2.1 随机接入的两个核心目的随机接入不是随便喊一声就完了它要完成两件正事。第一件是实现UE和gNB之间的上行同步。手机和基站之间如果没有对齐时间基站收到手机发来的数据就会像听一个节奏完全乱掉的人说话根本分不清哪里是开头哪里是结尾。随机接入就是让手机先发一个已知的信号基站根据收到的时间差告诉手机“你刚才发早了往后挪一点。”这样后续的上行数据才能被正确解析。第二件是获取Message3的资源。手机喊完那一嗓子之后基站得给它分配后续通信要用的资源这个分配信息就藏在Message3里。你可以把随机接入理解成去银行办业务先取号发前导柜台叫号基站响应然后你才能坐到窗口前提交材料Message3。没有这个取号环节后面的事都无从谈起。2.2 基于竞争和非竞争两种截然不同的“排队方式”随机接入分两种类型这个区分非常关键。基于竞争的方式是多个UE可能同时生成相同的PRACH Preamble一起到达基站。基站一开始分不清谁是谁只能先按这个前导回应后续再通过额外过程解决冲突。如果冲突解决了UE接入成功解决不了就得重来。这就像一群人同时喊“到”老师只能先记下有人答到了然后再一个个确认到底是谁。基于非竞争的方式则完全不同基站直接指定某个PRACH Preamble给某个UE用从源头上避免了冲突。最常见的场景是切换——手机从一个基站覆盖范围移动到另一个基站时目标基站提前给它分配好专属前导确保切换过程干净利落。这种方式效率高、时延低但需要基站提前知道有UE要接进来。提示基于竞争的随机接入是常态基于非竞争的随机接入是特例。规划PRACH时两种场景都要考虑但优先级和参数选择逻辑不同。3. PRACH前导序列是怎么造出来的ZC序列、循环移位和根序列的三角关系3.1 ZC序列前导的“原材料”PRACH前导的频域生成公式里最核心的是ZC序列Zadoff-Chu序列。这是一种特殊的数学序列它的特点是不管你怎么循环移位移位后的序列和原序列之间的相关性都几乎为零。这个特性太重要了——基站收到一堆前导时就是靠这种“互不干扰”的特性来区分不同UE的。公式里的u是ZC序列的根序列索引取值0到837或0到137。现网参数里给的是逻辑索引号它和u之间有一一对应的关系。LRA是ZC序列长度取值839或139对应配置参数prachRootSequenceIndexI839。你可以把u理解成“配方编号”不同的u生成出来的序列形状不同但都具备那种互不干扰的特性。3.2 循环移位Cv一个根序列怎么变出多个前导光有一个根序列u还不够因为一个小区需要64个有效的前导。怎么从一个根序列变出多个前导靠的就是循环移位Cv。Cv的取值取决于Ncs和限制集类型而Ncs又由小区半径、应用场景等因素决定。通俗地说Cv就是把ZC序列首尾相接成一个环然后从不同位置切开。切的位置不同得到的序列就不同但它们都来自同一个根序列。Cv的数量决定了根序列u能产生多少个前导。如果当前u产生的前导数量不足64个根序列索引号加一用下一个根序列继续产生直到凑够64个为止。配置参数里restrictedSetConfig非限制集zeroCorrelationZoneConfig6对应Ncs32。这个Ncs32意味着每次循环移位32个位置一个长度为839的序列能切出838/3226个不同的前导。3.3 时域位置前导什么时候发PRACH Preamble只能在高层参数prach-ConfigurationIndex给出的时域上传输具体取决于FR1还是FR2。配置参数prachConfigIndex17时查表可知Preamble format0允许UE在任何系统帧的子帧4上发送PRACH。这个“子帧4”不是随便选的。基站需要预留特定的时频资源给PRACH不能和别的信道冲突。规划时域位置时要考虑小区内其他信道的调度情况避免资源撞车。配置参数取值含义prachRootSequenceIndexI839ZC序列长度为839restrictedSetConfig非限制集不使用循环移位限制zeroCorrelationZoneConfig6对应Ncs32prachConfigIndex17Preamble format0子帧4发送注意这些参数不是孤立的改一个往往要连带调整其他几个。比如Ncs变了能产生的Cv数量就变了需要的根序列数量也跟着变。4. 前导格式和Ncs的规划覆盖半径是怎么算出来的4.1 前导格式长码短码各有各的用武之地PRACH前导格式的规划直接关系到小区能覆盖多远。格式0/1沿用LTE的格式0/3格式2/3、Ax、Bx、Cx是NR新引入的合计长码4种、短码9种。长码和短码的区别在于序列长度和子载波间隔长码覆盖远但时延大短码覆盖近但时延小。前导格式按照覆盖场景和最大覆盖半径来规划。小区覆盖半径的计算公式是*小区覆盖半径Tcp-最大多径时延扩展c/2。Tcp是循环前缀长度c是光速。这个公式的物理含义很直白循环前缀越长能容忍的多径时延扩展越大小区就能覆盖得越远。但循环前缀不是越长越好因为它会占用额外的时域资源降低频谱效率。4.2 Ncs规划在覆盖和复用之间找平衡Ncs的规划是PRACH规划里最需要拿捏的部分。标准协议定义了三张Ncs表分别对应子载波间隔1.25kHz、5kHz和15*2ukHz。在低速场景下先根据覆盖场景确定Format格式然后按照各场景内小区实际覆盖需求尽量选用复用度大的zeroCorrelationZoneConfig索引号。小区覆盖半径的计算公式变成*小区覆盖半径Ncs*Tseq/Lra-最大多径时延扩展-安全余量c/2。Tseq是序列时长。这个公式告诉你Ncs越大覆盖半径越大但每个根序列能产生的前导数量越少。这是一个典型的权衡——想要覆盖广就得接受根序列消耗快想要根序列用得省就得接受覆盖范围小。举个例子小区半径3.3kmFormat0Ncs32Lra839。每个逻辑根序列可生成838/3226个PRACH Preamble每个小区需要生成64个因此需要连续逻辑根序列64/263个。这意味着这个小区要占用3个连续的根序列索引号。4.3 根序列规划64个前导怎么凑齐一个小区需要产生64个有效的PRACH Preamble。首次通过根序列索引号按照所有有效的循环偏移Ncs得到如果本次根序列不能产生64个前导就用逻辑根序列索引号下一个来产生直到产生64个为止。Cv的计算过程决定了当前小区产生64个前导所需要的根序列数量也决定了根序列索引号如何规划。以不设置限制集为例当Ncs0时Cv0只产生1个Cv所以每次根序列u只能产生1个前导一个小区生成64个前导需要连续64个根序列索引号规划时不同小区的逻辑根序列索引号间隔至少为64个。当Ncs≠0时CvvNcs可以产生Lra-1/Ncs个Cv所以每次根序列u能产生Lra-1/Ncs个前导。之后可以规划出不同小区逻辑根序列索引号的最小间隔。这个间隔直接决定了网络规划时能支持多少个相邻小区间隔算错了相邻小区之间就会互相干扰。提示根序列规划不是算一次就完事。小区半径调整、前导格式变更、Ncs重新选择都会导致根序列需求数量变化需要重新核算。5. 高速场景下的特殊处理限制集A和B到底在限制什么5.1 高速为什么会让前导“串门”在高速场景下频偏会造成序列相关峰的能量泄露到其它循环移位窗内。你可以把每个循环移位窗想象成一个房间正常情况下每个房间里的信号只在自己的房间里被检测到。但高速移动带来的多普勒频偏会让信号“串门”跑到隔壁房间去。泄露的循环移位就不能用于产生前导了否则基站会把隔壁房间的信号误认为是本房间的。为了解决这个问题引入了循环移位限制集来限制某些循环位移的使用保证PRACH的接收性能。R15标准在限制集A的基础上引入新的限制集B被用于超高速场景即350km/h以上。限制集B比限制集A更严格牺牲了更多的循环移位可用性换来了更高的速度容忍度。5.2 限制集B的规划实例针对限制集B的Cv部分计算结果如下。当高铁小区半径为1-2km时Ncs26可选用连续根序列索引42-329。使用简易法规划以19个连续索引为一组可用于规划的根序列索引号共15个使用最大法规划可用于规划的根序列号共19个分别是42、55、71、86、102、116、132、147、166、183、200、214、227、240、254、268、283、297、311。这两个方法的区别在于简易法分组规整实现简单但可用根序列数量少最大法逐个挑选可用的根序列索引可用数量多但规划复杂度高。实际规划时选哪种取决于小区数量和干扰控制要求。如果周边小区不多简易法够用如果根序列资源紧张就得用最大法把每一个可用的索引都利用起来。高速场景的PRACH规划和低速场景最大的不同在于低速场景下你主要考虑覆盖和复用高速场景下你首先要保证的是速度带来的频偏不会让前导检测失效。限制集的选择直接决定了Ncs的可用范围进而决定了根序列的规划方式。6. 什么时候该翻出这份规划资料几个真实场景和一条血泪教训这份资料最直接的适用场景是新站开通前的参数规划。当你拿到一个小区的基本信息——覆盖半径要求、是否高铁沿线、FR1还是FR2——你需要确定前导格式、Ncs、根序列索引号、时域配置索引这一整套参数。这套参数不是拍脑袋填的每一个都有推导链条。比如覆盖半径3.3km、Format0、Ncs32推导出需要3个连续根序列如果周边还有相邻小区根序列索引号间隔至少留出3个否则两个小区的前导会撞车。另一个场景是网络优化阶段的参数调整。现网运行一段时间后如果发现随机接入成功率偏低或者切换时延偏大可能需要回头检查PRACH规划是否合理。比如高速场景下如果还在用限制集A350km/h以上的频偏就会导致前导检测性能下降这时候就得切换到限制集B重新规划。但切换限制集不是改一个参数就完事Ncs的可用范围变了根序列的规划方式也要跟着变整个小区的PRACH参数需要重新核算一遍。还有一种情况是容量扩容。一个小区原来规划了64个前导随着接入用户增多前导冲突概率上升。这时候需要评估是否增加根序列数量来提供更多的前导。但根序列不是想加就能加得看相邻小区的索引号占用情况如果周边小区已经把相邻的根序列用掉了你就得重新协调。什么时候别用这份资料如果你只是想知道“5G随机接入是什么”这种科普层面的问题这份资料偏深了它更适合已经了解随机接入基本流程、需要动手做规划的人。另外这份资料里的参数示例是基于特定配置的实际规划时不能直接照搬数值得根据自己小区的覆盖需求、场景类型重新推导。说一个我自己的教训。早些年参与一个高铁沿线的小区规划当时想当然地按低速场景选了Ncs觉得覆盖半径够用就行。结果开通后随机接入成功率一直上不去排查了很久才发现是高速频偏导致前导检测窗被污染。后来重新按限制集B规划把Ncs和根序列索引全部重算了一遍问题才解决。从那以后我每次做PRACH规划都强制走一遍完整流程先确认场景类型再选限制集然后算Ncs最后核根序列间隔一步都不跳过。希望这份资料能帮你少走一遍我当年走过的弯路。本文还有配套的精品资源点击获取