大概不少网优兄弟都有过这种经历后台指标里随机接入成功率只有百分之八十几但整个小区看下来既没有告警也没有明显拥塞前台上站用终端做拉网测试又一切正常。前阵子我就被这么一个站点磨了两天最后定位到问题出在PRACH的上行干扰上。整个排查过程让我又一次把随机接入协议翻了个底朝天。5G NR的随机接入占了非常底层的一环PRACH信道和Preamble序列的设计牵一发而动全身从覆盖、容量到干扰排查全都绕不开这些参数。这篇文章我就把PRACH和Preamble这块内容系统性地梳理一遍。从随机接入在协议栈里的位置讲起到ZC序列怎么生成64个前导再到时频资源的配置实操、覆盖半径的推算方法最后附上现场排障的实录和常用工具清单。适用人群是无线网优工程师、基站产品测试、通信专业学生只要你想把“随机接入成功率低”这类问题从根上搞清楚这篇内容应该都能给你省不少事。1. 随机接入流程与PRACH在5G NR中的角色1.1 随机接入到底在解决什么问题随机接入不是5G新发明LTE时代就有。它本质上是终端从“非同步”状态向网络发起请求的过程。终端刚开机不知道基站的定时基准上行时间还没对齐这时候连最起码的上行调度都无法进行因为基站根本不知道这个终端在哪、离自己多远、发上来的数据会落在哪个时隙。随机接入的第一层任务就是让基站通过Preamble完成对终端的定时估算然后通过RAR消息告诉终端一个TA值把上行时间对齐。在5G NR里随机接入的触发场景比LTE更多。除了最经典的初始接入还有无线链路失败后的RRC连接重建、上行失步后又有数据要发、切换过程中的目标小区接入、辅小区组添加、定位需求以及从RRC_INACTIVE态恢复连接。每一种场景对随机接入的要求不尽相同这直接决定了用竞争式还是非竞争式也影响到Preamble格式的选择。有一点很多人容易忽略随机接入使用的资源其实是上行物理信道里的“预留给碰撞”的资源。终端选一个Preamble发上来如果两个终端恰好用了同一个Preamble、同一块时频资源基站只能检测到一个有效的前导这就是竞争冲突。既然设计上允许碰撞那后面就必须配套竞争解决机制。所以随机接入天生就是一个“先抢物资再靠编号和解冲突消息来圆场”的过程。1.2 PRACH和Preamble是一对天生的搭档PRACHPhysical Random Access Channel是承载Preamble的物理信道。协议上Preamble序列映射到PRACH上发送终端发起随机接入的第一步Msg1本质就是在PRACH信道上发一串Preamble序列。很多做上层业务的人会把Msg1简单理解成“我来了”但这条消息的物理层内涵比表面复杂得多。基站从收到的信号里要同时完成几件事检测有没有Preamble、识别出用的是哪个Preamble索引、测量到达时刻来估计TA、估算信号强度。这四件事全部依赖PRACH的时频资源位置和Preamble序列自身的性质。所以PRACH资源的规划不是随便找个上行位置塞进去就行的它要跟帧结构、上行BWP、小区覆盖半径、干扰环境一起通盘考虑。从逻辑上看PRACH在随机接入链路里承担的是“入口”角色。终端还没拿到专属上行调度之前PRACH就是唯一能用的上行信道而且必须保证任何位置、任何方向的终端都能发上来。这跟PUSCH/PUCCH完全不一样后两者是在已经有调度和同步的基础上工作的而PRACH得在一团混沌中完成第一次握手。这就对Preamble的抗干扰能力、检测算法的灵敏度、序列之间的正交性提出了很高的要求。1.3 竞争式与非竞争式随机接入配置取向完全不同随机接入分成竞争式Contention-Based Random Access, CBRA和非竞争式Contention-Free Random Access, CFRA。这两种方式的配置思路和执行机制差别非常大。竞争式随机接入是终端自己从64个可用Preamble里随机选一个发给基站。如果两个终端选了同一个Preamble那就要靠后续Msg3和Msg4的竞争解决来判定谁胜出。典型场景是初始接入、无线链路失败后的重建、RRC_INACTIVE态恢复。这类场景的特点是小区里可能有大量终端同时发起所以Preamble的容量规划要看随机接入碰撞概率而不是简单算“够不够用”。非竞争式则完全不同。基站已经知道终端的存在通过RRC信令给终端下发专用的Preamble索引终端直接用这个专用Preamble发起接入。因为每个终端用的是不同的专用Preamble天然不存在碰撞也就省掉了竞争解决这个环节接入更快更可靠。典型场景是切换、辅小区组添加、基于下行信号的定位。这里要重点理解的是专用Preamble是从该小区公共的64个Preamble里预留出来的部分。所以非竞争前导的配置会压缩竞争前导的可用数量如果预留太多终端随机碰撞的概率就会上升。实际配置时切换频繁的小区要动态评估dedicated preamble的预留比例不能拍脑袋。2. Preamble序列的设计逻辑与关键参数2.1 为什么非要用ZC序列Preamble的序列类型是ZC序列Zadoff-Chu序列。这东西在通信系统里是块宝因为它是CAZAC序列恒定包络、零自相关。恒定包络意味着发射信号的峰均比很低对功放的线性度要求不高终端侧的功放效率能做得更好零自相关意味着同一个根序列产生的不同循环移位版本之间是严格正交的基站做相关检测时能把不同用户的Preamble干净地区分开。还有一个反直觉的性质值得多说一句ZC序列经过傅里叶变换之后在频域上依然是ZC序列。这意味着基站可以在频域直接做相关检测实现上非常友好不需要反复做时频域转换工程上能省不少DSP算力。实际工程中用的Preamble并不是直接发一个原始ZC序列而是由根序列做循环移位得到的。循环移位后的序列和原始序列在时域上只是“错开了一点时间”但相关特性保持不变。基站侧用本地根序列和接收信号做滑动相关相关峰出现的位置直接对应到循环移位量这个移位量就是TA估算的基础。正因为“根源”相同只是时间上有偏移所以一次相关运算就能同时检测出使用同一个根序列、不同循环移位的所有终端这个设计相当精妙。2.2 逻辑根序列1个根序列如何变出64个Preamble每个小区需要配置64个Preamble协议规定每个小区的可用Preamble总数就是64。但64个Preamble并不是64个完全不同的ZC根序列而是通过“根序列循环移位”组合出来的。我们以长序列格式为例一个ZC根序列的长度是839循环移位的步长由Ncs决定。如果我们配置Ncs119那一个根序列上能生成的循环移位个数就是floor(839/119)7也就是说一个根序列只能产生7个Preamble。为了凑够64个就必须在下一个物理根序列上继续生成循环移位。算下来需要ceil(64/7)≈10个根序列才能凑满64个Preamble。这就是为什么邻区规划时往往只规划根序列的起始索引而不是直接规划物理根序列号——因为一个起始索引会顺序使用一串物理根序列。这里有个很关键的工程权衡Ncs越大单个根序列能生成的Preamble数量越少支持的覆盖半径越大。反过来Ncs小覆盖半径小但一个根序列能生成的Preamble多需要用到的根序列就少。所以覆盖半径和Preamble容量本质上是矛盾的。海面超远覆盖站点和城区密集小区的PRACH规划思路肯定不一样基础原因就藏在这个Ncs的权衡里。逻辑根序列索引和物理根序列号之间有一个映射关系协议里是排好的一张表规划时直接把每个小区的逻辑根序列起始索引错开就行。邻区的根序列规划原则是“尽可能用不同的根序列组”这样就算邻区信号穿越过来基站做相关检测时也不会把邻区的Preamble误判成自己的。根序列复用距离不够或者规划冲突是随机接入干扰的常见隐性原因。2.3 长序列与短序列场景决定Format5G NR的PRACH Preamble格式分为长序列和短序列两大类。长序列长度839短序列长度139。这个设计延续了LTE长序列的思路同时为5G的高频大带宽场景增加了短序列选项。长序列格式包括Format 0、1、2、3子载波间隔是1.25kHz或5kHz一个Preamble最短1ms最长可以到4.5ms。长序列的好处是序列时间长能量积累多覆盖能力强。Format 0支持大约14公里左右的覆盖Format 1和2配合较大Ncs可以支持几十公里以上Format 3属于覆盖和容量的折中。海上覆盖、偏远农村这类大覆盖场景基本都靠长序列。短序列格式则有A1/A2/A3、B1/B2/B3/B4、C0/C2等等子载波间隔可以配15/30/60/120kHz。短序列占用OFDM符号数少正好匹配5G的帧结构和波束扫描机制。高频段覆盖距离本来就小不需要长序列那么强的积累增益短序列可以通过波束扫描在时分上轮流覆盖不同方向灵活性高很多。选择哪个Format核心看两件事一是实际覆盖需求二是帧结构里能不能放下。比如一个站点的小区半径只有3公里用Format 0就有点浪费因为Format 0占用1ms时隙如果帧结构里每个无线帧只有一个上行时隙那PRACH会挤占大量上行容量。这种场景可能用短序列更合适。反过来海面覆盖几十公里短序列连循环移位都撑不起那么大的时延差就必须上长序列。3. PRACH时频资源配置与覆盖规划实操3.1 prach-ConfigurationIndex和时域位置PRACH在时域的位置由prach-ConfigurationIndex决定。协议38.211里给了多张表格分别对应不同的频段、子载波间隔和双工模式索引范围是0到255。配置的时候你只需要指定一个索引值协议里就能查到这个PRACH在无线帧里的具体出现位置包括在第几号帧的哪个时隙、从第几个符号开始、占几个符号。实际规划时的第一原则是别和SSB、PDCCH、CSI-RS撞在一起。特别是TDD站点上下行时隙是分时复用的PRACH必须放在上行时隙或者特殊时隙的UpPTS区域里。我有一次排查一个小区随机接入异常最后发现是prach-ConfigurationIndex配到了一个被配置成下行的时隙上终端发了Msg1基站根本不会在那个位置收PRACH哪怕终端在信号极好的地方也接不进去。TDD场景下另一个常见问题是PRACH和SSB的关系。终端检测完SSB才能获取下行同步但发起随机接入还要知道上行时机。如果PRACH时隙离SSB太远终端在空闲态要额外等一个较长时间才能等到PRACH机会会显著拉长随机接入时延。室分站点、车联网这类对时延敏感的部署最好把PRACH配置在每几个无线帧内都出现一次的位置而不是为了省上行开销把PRACH机会压得很稀疏。3.2 频域偏移与BWP的配合时域位置定好之后频域位置由msg1-FrequencyStart和PRACH的频域占用来决定。msg1-FrequencyStart的单位是RB表示PRACH第一个RB相对上行BWP起始位置的偏移取值范围从0到274。PRACH在频域上占用的RB数取决于序列长度和子载波间隔比如短序列139在30kHz子载波间隔下一个PRACH机会大概占12个RB左右。这个配置的关键是PRACH必须在初始上行BWP的范围内。终端在空闲态和初始接入阶段用的是初始BWP如果PRACH的频域起点加上占用带宽已经超出BWP边界终端压根找不到合法的PRACH资源。很多自测环境里出现“能搜到小区但永远注册不上去”的怪问题查了一圈最后发现是PRACH频域配出了BWP边界这种问题用协议分析仪非常难抓通常得靠基站侧日志才能看到Msg1接收失败的记录。另外PRACH频域位置对干扰有直接影响。如果系统带宽边缘存在外部干扰源比如某些频段的广电信号或者工业无线设备把PRACH配到这些受干扰RB上会导致Msg1检测率大幅下降。排查随机接入问题时第一步就是看基站上报的PRACH频域RB的干扰统计例如每RB的底噪抬升量。如果某些RB的干扰底噪明显高于其他RB优先考虑移动PRACH的频域位置来避让干扰。3.3 用Ncs反推覆盖半径的计算实例Ncs是循环移位相关的核心参数它决定小区支持的最大覆盖半径。之前提到一个根序列长度839序列时长约0.8ms对应的时间是800微秒839个采样点每个点约0.954微秒。Ncs等于循环移位的采样点个数所以Ncs对应的循环移位时间约为Ncs乘以0.954微秒。这里子载波间隔取1.25kHz序列持续时间是1除以1.25kHz等于800微秒。无线电波是双向传播的信号从终端到基站再被基站检测往返距离才是覆盖半径的两倍。所以最大覆盖半径R等于光速乘以循环移位时间再除以2。以Ncs119为例单个采样点时间 800 us / 839 ≈ 0.954 usNcs119对应的循环移位时间 119 × 0.954 ≈ 113.5 us最大覆盖半径 3×10^8 × 113.5×10^-6 / 2 ≈ 17公里这个计算非常实用。当你想把小区覆盖半径从17公里扩大到30公里以上时先把需要的时延差算出来再反推Ncs最小值。比如覆盖30公里往返时延 30km×2 / 3×10^8 200微秒对应Ncs至少是200/0.954≈210。算清楚之后你还得考虑多径时延扩展Ncs需要留出额外余量不能恰好卡在边界上。实际配置时查38.211里的Ncs配置表选一个大于理论最小值且能满足Preamble数量要求的离散值即可。4. 现场实测随机接入问题的定位与排查实录4.1 失败率突然飙升时我怎么做随机接入成功率下降先别急着调参数。我习惯按“先干扰、再覆盖、后参数”的顺序排查。第一步看基站侧的上行干扰统计特别是PRACH所在时频资源上的底噪抬升。一个长序列PRACH如果底噪被抬高了10dB以上整条链路的信噪比就崩了终端发射功率再高也没用。确认干扰后排查干扰源方向常见手段是看干扰是7x24小时恒定的还是分时段出现的。恒定干扰大概率是外部系统或者硬件故障比如天线馈线问题、放大器自激分时段干扰可能是附近有雷达、工业设备或者 一些临时的无线设备在工作。定位到干扰方向后优先考虑在频域上移动PRACH位置来避让避不开再考虑加滤波器。如果干扰指标很干净那问题大概率在覆盖侧。看看随机接入分布是不是全部集中在远点TA分布是不是普遍偏大。如果远点终端占比异常高就需要优化下行覆盖或提高终端发射功率而不是去动PRACH配置。还有一点容易忽略上行覆盖和下行覆盖如果严重不平衡终端虽然能收到很强的SSB但它发上来的Preamble基站却很吃力这种场景在海面覆盖、隧道覆盖比较常见。4.2 干扰对PRACH检测的影响如何判断基站侧检测Preamble用的是相关检测本质上是在噪声里找相关峰。正常情况下相关峰应该很尖锐背景噪声均匀。如果PRACH所在的频带存在窄带干扰你会发现相关峰旁边的旁瓣被抬高甚至出现“假峰”。假峰会被检测成另一个循环移位导致TA估算错误这正是PRACH干扰最隐蔽的危害——它不一定让接入失败但会让终端的定时提前量算错接下来的Msg3大概率对不上时隙最后依然表现为随机接入失败。怎么快速判断有没有假峰呢基站日志里如果能看到“检测到Preamble但Msg3未收到”的记录同时Msg1的功率报告异常偏大那基本就是TA估算错误。这时候再回看PRACH频域干扰数据看是否存在某个RB特别“凸起”。我见过一个案例干扰源是附近另一个运营商基站的TDD下行信号泄漏到了我们的上行频段因为两边TDD帧结构不完全对齐导致周期性干扰。最后通过调整PRACH频域位置避开了那几段RB随机接入成功率立刻从85%回升到99%以上。4.3 参数配置错位导致Msg1石沉大海的案例参数配错的问题在自测和开站阶段最常见比外界干扰更容易踩坑。有一次我们一个新开的站点终端在楼下信号显示满格但一直驻留不上信令一直在搜网重试。拿到基站日志一看PRACH接收端一个Preamble都没抓到。查配置发现prach-ConfigurationIndex选择的时隙格式和该小区实际使用的TDD上下行配置不匹配PRACH机会正好落在了下行符号上基站自然收不到任何Msg1。另一种常见的配置错位是PRACH子载波间隔和BWP的子载波间隔不匹配。如果终端和基站对PRACH机会的理解不一致终端会在错误的符号位置上发Preamble基站完全检测不到。这类问题的排查要点是“所有关于PRACH的配置在基站侧和终端侧必须来源于同一个系统消息”。如果SIB1里下发的prach-ConfigurationIndex因为某些原因被覆盖配置或者参数同步失败终端和基站就“各说各话”了。遇到这种问题最直接的办法是在基站侧导出终端的Msg1接收记录对比终端实际发送的位置和基站期望接收的位置。5. 常用工具与排查手段清单5.1 网侧基站日志与统计指标网侧排查主要依赖基站OM和日志。PRACH相关的关键指标包括随机接入成功率、每Preamble索引的接收次数、Msg1接收功率、TA分布、PRACH频域RB的干扰底噪抬升量。这些统计能帮你在高层面判断是容量问题、覆盖问题还是干扰问题。深入到单用户追踪时需要看RRC建立流程的信令记录重点是Msg1到Msg4的往返过程。如果Msg1有记录但Msg2没下发问题在基站检测或调度侧如果Msg2下发了但Msg3没收到可能是上行覆盖不足、TA估算错误或PUSCH资源冲突如果Msg3收到但Msg4没成功多半是竞争冲突或UE异常。这类信令追踪日志在华为、中兴、爱立信的网管系统里都有关键是知道该看哪一层的数据。5.2 终端侧路测软件与信令分析终端侧排查最直观的手段是路测。用路测软件抓SSB和SIB1里的PRACH配置可以确认终端视角下的参数是否正确。UE日志里会记录Msg1发送时使用的Preamble索引、PRACH时机、发射功率以及Msg2是否收到。如果UE日志显示Msg1已经发出去了但始终收不到Msg2那问题基本就锁定在基站侧“听到了但没正确响应”或者“压根没听到”两种可能。在射频暗室里做终端一致性测试时通常用综测仪模拟基站直接查看UE发送的PRACH波形能精确分析Preamble的频域位置、发射功率、定时精度是否符合规范。如果你做的是芯片或模块开发这一步几乎是必测项。PRACH波形的时间误差和频率误差超标会直接导致基站检测失败这类问题在真实网络中很难复现但在暗室测试中非常容易暴露。5.3 仿真验证手段做协议算法研究或者基站性能调优时仿真工具比实网更高效。MATLAB的5G Toolbox里有一个完整的PRACH生成和检测流程可以自己设置根序列、循环移位、子载波间隔、信道模型实测不同干扰条件下的检测概率。开源的SRSRAN和OpenAirInterface也都有PRACH检测的实现可以直接跑在通用处理器上做原型验证。我自己的经验是在做“如果我把Ncs调大一档覆盖半径能提升多少”这类的方案对比时先跑一轮仿真远比直接去现网改参数要稳妥。仿真中可以精确控制干扰水平、时延扩展、多普勒频移把每种参数的极限性能摸清楚再上现网验证。这样既能规避现网改造风险也能积累起一套属于自己的参数性能基线数据。做随机接入相关的排障和规划说难也难说简单也简单。难在参数多、链路长、干扰因素杂一不留神就在某个不起眼的配置项上翻车简单在只要你把PRACH时频资源、Preamble序列生成、循环移位与覆盖半径的关系这几条主线吃透绝大多数问题都能顺着这条链一路找到根因。我自己踩过最多的坑反而是那些“我以为配置肯定没问题”的默认值越自信越容易翻车。所以现在的习惯是每次开站、每次改PRACH参数都会把终端视角的SIB1解析结果和基站侧的PRACH接收配置拉在一起逐项对比一遍虽然多花十几分钟但能省下后面好几天的排障时间。