企业官网建设流程全解析

大概不少网优兄弟都有过这种经历：后台指标里随机接入成功率只有百分之八十几，但整个小区看下来既没有告警，也没有明显拥塞，前台上站用终端做拉网测试又一切正常。前阵子我就被这么一个站点磨了两天，最后定位到问题出在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是一对天生的搭档

PRACH（Physical 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决定。如果我们配置Ncs=119，那一个根序列上能生成的循环移位个数就是floor(839/119)=7，也就是说一个根序列只能产生7个Preamble。为了凑够64个，就必须在下一个物理根序列上继续生成循环移位。算下来需要ceil(64/7)≈10个根序列才能凑满64个Preamble。这就是为什么邻区规划时往往只规划根序列的起始索引，而不是直接规划物理根序列号——因为一个起始索引会顺序使用一串物理根序列。

这里有个很关键的工程权衡：Ncs越大，单个根序列能生成的Preamble数量越少，支持的覆盖半径越大。反过来Ncs小，覆盖半径小，但一个根序列能生成的Preamble多，需要用到的根序列就少。所以覆盖半径和Preamble容量本质上是矛盾的。海面超远覆盖站点和城区密集小区的PRACH规划思路肯定不一样，基础原因就藏在这个Ncs的权衡里。

逻辑根序列索引和物理根序列号之间有一个映射关系，协议里是排好的一张表，规划时直接把每个小区的逻辑根序列起始索引错开就行。邻区的根序列规划原则是“尽可能用不同的根序列组”，这样就算邻区信号穿越过来，基站做相关检测时也不会把邻区的Preamble误判成自己的。根序列复用距离不够或者规划冲突，是随机接入干扰的常见隐性原因。

2.3 长序列与短序列：场景决定Format

5G 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。以Ncs=119为例：

• 单个采样点时间 = 800 us / 839 ≈ 0.954 us
• Ncs=119对应的循环移位时间 = 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接收配置拉在一起逐项对比一遍，虽然多花十几分钟，但能省下后面好几天的排障时间。