1. 从一次现场测试异常说起：为什么随机接入值得单独拎出来讲
刚入行做网络优化那会儿，我对随机接入的理解长期停留在"手机开机要接入网络"这个层面，觉得它无非就是终端发个请求、基站回个响应，跟TCP三次握手差不多。直到有一次跟着前辈去处理一个现场问题：某片区域大量终端在特定时段接入成功率骤降，后台信令跟踪显示大量终端卡在随机接入的前几步反复重试，用户感知就是"信号满格但打不出去电话、上不了网"。那次排查前后折腾了将近一周，才把问题定位清楚。从那以后我才真正意识到，随机接入（Random Access，简称RA）绝不是"握手"两个字能概括的，它是终端和网络之间建立连接的第一道门槛，这道门槛的设计直接决定了接入时延、接入成功率和整个系统的容量表现。
这篇内容我想把NR随机接入的基础知识系统地梳理一遍。所谓"基础"，不是泛泛而谈的概念罗列，而是把随机接入到底解决什么问题、有哪几种触发场景、两种接入模式的区别、前导码是怎么设计和选择的、Msg1到Msg4这条消息链路每一步在干什么、以及实际优化中哪些参数最值得关注，这些内容讲透。适合刚接触NR协议栈的工程师、做网络优化和测试的从业者，以及想从LTE平滑过渡到NR的读者。我会尽量用从业者之间交流的口吻，把协议里那些看起来枯燥的流程还原成"终端和基站之间到底在商量什么"的实际场景。
需要先说明一点：随机接入的很多细节在3GPP协议里有明确定义，但不同设备厂商、不同运营商在参数配置和实现策略上会有差异。我下面讲的内容以通用原理和常见实践为主，涉及具体参数取值时，我会说明这是基于常见配置的合理推断，实际项目中还是要以设备文档和现场配置为准。
2. 随机接入到底在解决什么问题：四种触发场景拆解
2.1 随机接入不是"开机专属"，它的触发场景比想象中多
很多人第一次学随机接入，会默认它只发生在终端刚开机、需要注册到网络的时候。实际上在NR里，随机接入的触发场景至少有四大类，理解这些场景是理解整个流程设计意图的前提。
第一类是初始接入。终端刚开机，或者从覆盖盲区回到服务区，此时网络侧还没有这个终端的任何上下文信息，终端需要通过随机接入来请求建立连接。这是最典型的场景，也是协议设计时考虑最多的场景。
第二类是无线链路失败后的重建。终端原本已经和网络建立了连接，但因为信号突变、切换失败等原因导致链路中断，终端需要重新发起随机接入来恢复连接。这个场景的特点是终端可能还保留部分上下文，但网络侧的状态可能已经不一致了，所以流程上会有一些特殊处理。
第三类是切换过程中的接入。终端从一个小区移动到另一个小区，目标小区需要终端通过随机接入来确认"我来了，请给我分配资源"。这个场景对时延非常敏感，因为切换中断时间直接影响用户感知。
第四类是上行失步后的重新同步。终端长时间没有上行数据传输，网络侧认为终端的上行定时已经不准了，此时如果终端突然有数据要发，就需要先通过随机接入重新对齐上行定时。
把这四类场景放在一起看，你会发现随机接入的核心使命其实有两个：一是让网络知道有终端要接入，二是让网络和终端在上行定时上达成一致。第二个使命经常被忽略，但它恰恰是随机接入区别于普通"请求-响应"机制的关键所在。
2.2 为什么上行定时对齐这么重要
这里需要稍微展开讲一下上行定时对齐为什么是随机接入的核心任务之一。在蜂窝通信里，下行方向是基站发、终端收，所有终端共享同一个下行定时基准，终端只要按基站的下行信号对齐接收窗口就行。但上行方向是终端发、基站收，不同终端距离基站的远近不同，信号传播时延也不同。如果两个终端同时发送上行数据，一个离基站近、一个离基站远，它们到达基站的时间就会错开，基站接收时就会产生符号间干扰。
NR系统解决这个问题的办法是上行定时提前（Timing Advance，TA）：基站测量每个终端上行信号的到达时间，计算出一个提前量，告诉终端"你下次发送时提前这么多时间发"，这样所有终端的上行信号就能在基站侧对齐。而随机接入，正是终端第一次获得TA值的途径。终端在随机接入过程中发送前导码，基站通过检测前导码的到达时间来估算TA，然后在响应消息里把TA值告诉终端。这就是为什么随机接入不能简单地用"发个请求"来理解——它承载了物理层定时测量的功能。
理解了这一点，你就能明白为什么前导码的设计要特别考虑检测性能，为什么基站对前导码的检测精度要求那么高。TA估算的准确性直接决定了后续上行传输的质量。
3. 四步随机接入与两步随机接入：两种模式怎么选
3.1 四步随机接入：经典但不算快的方案
NR里最经典的随机接入流程是四步随机接入（4-step RACH），消息链路是Msg1、Msg2、Msg3、Msg4。我按顺序把每一步在干什么讲清楚。
Msg1（前导码传输）：终端从基站广播的配置里选一个前导码序列，在指定的时频资源上发送。这一步是"我来了"的信号，终端此时还没有任何专属资源，用的是竞争性的公共资源。基站收到前导码后，能检测到"有人要接入"，并通过前导码的到达时间估算TA。
Msg2（随机接入响应）：基站在下行发送随机接入响应（RAR），里面包含检测到的前导码标识、TA值、上行授权（告诉终端Msg3可以用哪些上行资源发）以及一个临时标识。注意，Msg2是发给所有发了前导码的终端的，如果多个终端选了同一个前导码，它们都会收到这个响应，这就是"竞争"的来源。
Msg3（连接请求）：终端用Msg2里分配的上行资源发送自己的身份信息，比如终端标识、连接建立原因等。这一步是终端第一次向网络表明"我是谁"。
Msg4（竞争解决）：基站回送竞争解决消息，把在Msg3里收到的终端标识回显出来。终端收到后对比自己的标识，如果一致，说明自己赢得了竞争，随机接入成功；如果不一致，说明前导码冲突了，需要退避后重试。
四步流程的优点是成熟、可靠、兼容性好，缺点是时延相对较大，因为要经历四次消息交互。对于URLLC这类对时延极度敏感的业务，四步流程的时延可能成为瓶颈。
3.2 两步随机接入：把前两步合并的思路
为了降低时延，NR引入了两步随机接入（2-step RACH）。它的思路很直接：把Msg1和Msg3合并成一个消息（称为MsgA），把Msg2和Msg4合并成一个消息（称为MsgB）。终端在MsgA里同时发送前导码和载荷（payload），基站收到后如果解码成功，直接在MsgB里回复竞争解决和后续调度信息。
两步流程把消息交互次数从四次降到两次，理论上能显著降低接入时延。但它也有代价：MsgA的载荷部分需要额外的上行资源，而且前导码和载荷之间的资源映射关系更复杂，基站检测的复杂度也更高。所以实际部署中，两步和四步往往是共存的，网络会根据业务类型、终端能力、负载情况来决定用哪种。
3.3 两种模式的对比与选择逻辑
| 对比维度 | 四步随机接入 | 两步随机接入 |
|---|---|---|
| 消息交互次数 | 4次 | 2次 |
| 接入时延 | 相对较高 | 相对较低 |
| 资源开销 | 前导码资源为主 | 前导码加载荷资源 |
| 竞争解决方式 | Msg4显式解决 | MsgB内解决 |
| 适用场景 | 通用场景、初始接入 | 低时延业务、小包传输 |
| 实现复杂度 | 较低 | 较高 |
选择逻辑上，我的经验是：如果是常规的移动性管理、初始接入，四步流程足够用，而且兼容性最好；如果业务对时延敏感，或者终端处于连接态需要快速恢复上行同步，可以优先考虑两步流程。但要注意，两步流程能否使用，取决于网络是否配置了对应的资源，以及终端是否支持。实际优化中，我见过不少现场问题是因为终端和网络对两步流程的支持能力不匹配导致的，这个后面会展开讲。
4. 前导码：随机接入里最讲究的一块设计
4.1 前导码序列是怎么来的
前导码（preamble）是随机接入里第一个在空中接口上传输的信号，它的设计直接决定了基站能不能可靠地检测到终端。NR的前导码基于Zadoff-Chu（ZC）序列生成，这是一种恒幅零自相关序列，优点是峰均比低、自相关特性好，非常适合用于定时估计。
NR定义了长序列和短序列两种前导码格式。长序列主要用于低频段、覆盖要求高的场景，序列长度839，子载波间隔1.25kHz或5kHz；短序列主要用于高频段和低时延场景，序列长度139，子载波间隔15kHz、30kHz、60kHz、120kHz等。不同格式对应不同的时域占用长度和频域占用带宽，网络会根据部署频段和覆盖需求来配置。
这里有个容易混淆的点：前导码格式的选择不是终端随便定的，而是网络在系统消息里广播的。终端只能从网络配置的格式集合里选。所以如果你在现场发现终端发的preamble格式不对，首先要查的是网络侧的配置，而不是终端。
4.2 前导码分组与选择逻辑
网络会把可用的前导码分成若干组，常见的是Group A和Group B。分组的依据通常是Msg3的大小和路径损耗。终端在选择前导码时，会根据自己的Msg3数据量和测量的路损，决定从哪个组里选。
为什么要分组？核心目的是让基站通过前导码就能大致判断终端的意图。比如Group B通常对应较大的Msg3，基站收到Group B的前导码，就知道这个终端后续要发比较多的数据，可以提前准备更大的上行授权。这种"用前导码携带隐式信息"的设计，能减少后续消息交互的协商成本。
实际优化中，前导码分组配置不合理是导致接入失败的常见原因之一。如果Group B的门限设得太高，很多本该用Group B的终端被迫用Group A，基站分配的授权不够，Msg3就发不出去；如果门限设得太低，又会导致Group B资源被滥用。这个门限的调整需要结合现场的路损分布和业务模型来定。
4.3 前导码冲突与竞争解决
前导码是竞争性资源，多个终端可能同时选中同一个前导码，这就是"冲突"。冲突本身不可怕，协议设计了竞争解决机制来处理。但冲突率过高会直接拉低接入成功率、增加接入时延。
影响冲突率的因素主要有几个：一是前导码资源总数，资源越多冲突概率越低；二是同时发起接入的终端数量，负载越高冲突越多；三是前导码选择策略，如果终端选择过于集中，也会加剧冲突。
我在实际优化中总结的经验是：当接入负载升高时，单纯增加前导码资源不一定能解决问题，还要看资源在时频上的分布是否合理。有时候把前导码资源在时间上分散开，比单纯增加序列数量更有效。另外，退避参数的配置也很关键，退避窗口设得太小，冲突的终端会很快重试，反而加剧冲突；设得太大，又会拉长接入时延。这个参数需要根据负载情况动态权衡。
5. Msg1到Msg4的完整链路：每一步的实操关注点
5.1 Msg1发送：终端侧的选码与发射
终端决定发起随机接入后，第一件事是选前导码。选码的逻辑大致是：先根据路损和Msg3大小确定用哪个组，然后从组内随机选一个序列，再根据网络配置的时频资源确定发送位置。
这里有个实操中容易忽略的点：前导码的发射功率。终端不能随便用最大功率发，而是要根据路损测量和网络配置的目标接收功率来计算。如果功率算低了，基站检测不到；算高了，会对邻区造成干扰。NR里有个参数叫preambleReceivedTargetPower，网络通过它告诉终端"我希望收到你的前导码时功率是多少"，终端再结合自己测量的路损反推发射功率。这个参数的调整直接影响接入成功率和上行干扰水平，是优化时的重点参数之一。
5.2 Msg2接收：RAR窗口与监听
终端发完Msg1后，会在一个叫RAR窗口（随机接入响应窗口）的时间范围内监听下行控制信道，等待Msg2。这个窗口的长度由网络配置，通常几个到几十个毫秒不等。
窗口长度的设置是个权衡：设得太短，基站可能还没来得及处理前导码并发送响应，终端就错过了；设得太长，终端在窗口内一直监听，增加功耗，而且如果没收到响应，要等窗口结束才能重试，拉长了接入时延。实际配置中，窗口长度要匹配基站的preamble检测处理时延和调度周期。
如果终端在窗口内没收到Msg2，会认为这次尝试失败，需要退避后重新发起。退避时间的计算涉及一个退避指示符（BI），网络可以通过它来调节终端的重试节奏。
5.3 Msg3发送：上行授权与竞争传输
Msg2里包含的上行授权告诉终端可以用哪些上行资源发Msg3。终端在这个资源上发送连接请求，内容包括终端标识和连接建立原因。
Msg3的传输用的是HARQ机制，如果基站没解对，会要求重传。这里有个细节：Msg3的重传和普通数据的HARQ重传不太一样，它是在竞争解决之前进行的，所以重传时用的还是临时标识。如果重传次数用完了还没成功，终端只能放弃这次随机接入，重新来过。
实操中Msg3发送失败的原因主要有几类：上行授权不够大，装不下要发的数据；上行定时不准，导致基站解调失败；上行干扰太大，信噪比不够。排查时要结合Msg2里的授权大小、TA值以及现场的上行干扰情况综合判断。
5.4 Msg4接收：竞争解决的最后一关
Msg4是竞争解决消息，基站把在Msg3里收到的终端标识回显出来。终端收到后对比，一致就说明自己赢了，随机接入成功；不一致就说明前导码冲突了，需要退避重试。
这里有个容易踩的坑：Msg4的监听和Msg2的监听用的是不同的标识。Msg2用的是随机接入临时标识（RA-RNTI），Msg4用的是临时小区标识（TC-RNTI）。如果终端在监听Msg4时用错了标识，就会一直收不到，表现为"Msg3发出去了但接入就是完不成"。这种问题在信令跟踪里看得很清楚，但如果不熟悉流程，很容易误判成基站没发Msg4。
6. 随机接入优化：参数、场景与常见问题
6.1 最值得关注的几个参数
随机接入相关的参数很多，但实际优化中真正高频调整的就那么几个。我整理了一个表，把参数、作用和调整方向列出来。
| 参数 | 作用 | 调整方向与注意事项 |
|---|---|---|
| preambleReceivedTargetPower | 目标接收功率 | 提高可提升检测成功率，但会增加干扰 |
| powerRampingStep | 功率爬升步长 | 步长大接入快但干扰大，步小反之 |
| preambleTransMax | 最大前导码传输次数 | 影响接入成功率和时延的平衡 |
| ra-ResponseWindow | RAR窗口长度 | 需匹配基站处理时延，过短会漏收 |
| backoffIndicator | 退避指示 | 负载高时适当增大，降低冲突 |
| msg3-DeltaPreamble | Msg3功率偏移 | 影响Msg3解调成功率 |
这些参数没有一组"万能最优值"，必须结合现场的路损分布、负载水平、干扰情况来调。我的经验是，先抓主要矛盾：如果接入成功率低但干扰正常，优先看功率相关参数；如果接入时延大但成功率还行，优先看窗口和退避参数。
6.2 不同场景下的优化侧重点
高负载场景：比如大型活动现场，大量终端同时接入。这时候冲突率是主要矛盾，优化重点是前导码资源的合理分配、退避参数的调整，以及考虑是否启用两步随机接入来降低信令开销。
远覆盖场景：终端离基站远，路损大。这时候检测成功率是主要矛盾，优化重点是功率参数的调整和前导码格式的选择。长序列前导码在远覆盖场景下更有优势。
高速移动场景：终端移动速度快，多普勒频移大。这时候前导码的检测性能会下降，需要选择对频偏不敏感的前导码格式，同时TA的更新频率也要考虑。
室内深度覆盖场景：信号弱且多径复杂。优化重点是功率爬升策略和重传次数的配置，必要时考虑增加室分系统来改善覆盖。
6.3 几个我踩过的坑
第一个坑是把接入失败简单归因于覆盖。有一次现场接入成功率低，第一反应是加功率、加站点，结果折腾半天没效果。后来仔细看信令，发现是Msg3一直解调失败，根因是上行干扰，跟覆盖没关系。这个教训让我养成了先看信令、再下结论的习惯。
第二个坑是忽略终端和网络的能力匹配。两步随机接入刚引入时，有些终端支持、有些网络配置没开，导致部分终端接入异常。排查这类问题，一定要先确认双方的能力和配置是否对齐。
第三个坑是退避参数一刀切。不同小区、不同时段的负载差异很大，用同一套退避参数往往顾此失彼。后来我们按小区和时段做了差异化配置，接入成功率明显改善。
7. 从信令跟踪看随机接入：排查问题的实用方法
7.1 信令跟踪要看哪些关键节点
做随机接入问题排查，信令跟踪是最直接的手段。我通常会关注这几个节点：终端是否发出了Msg1、基站是否检测到前导码、Msg2是否在窗口内发出并被终端收到、Msg3是否发送成功并被基站解调、Msg4是否完成竞争解决。
把这几个节点串起来看，问题出在哪一步一目了然。比如Msg1发了但基站没检测到，问题在覆盖或功率；Msg2发了但终端没收到，问题在窗口配置或下行质量；Msg3发了但基站没解对，问题在上行授权、定时或干扰；Msg4没完成，问题在竞争解决或标识配置。
7.2 几个典型问题的排查链路
问题一：接入成功率低但信号质量正常。排查链路：先看是不是冲突率高，如果是，查前导码资源和退避配置；如果不是，看Msg3解调成功率，如果低，查上行干扰和功率配置；如果Msg3正常，看Msg4，查标识配置和竞争解决逻辑。
问题二：接入时延大。排查链路：先看RAR窗口是否过长，如果是，适当缩短；再看退避参数是否过大，如果是，适当减小；最后看是否频繁重传，如果是，查功率爬升和检测成功率。
问题三：特定终端接入异常。排查链路：先确认终端能力是否支持当前配置，再看终端侧的选码逻辑是否正常，最后看是不是终端实现问题。这类问题往往需要终端侧日志配合分析。
7.3 一个实用的排查清单
我把日常排查随机接入问题的清单整理如下，供参考：
- 确认问题范围：是单终端、单小区还是全网
- 抓取信令跟踪：定位失败发生在哪一步
- 检查参数配置：功率、窗口、退避、前导码资源
- 检查干扰情况：上行底噪是否正常
- 检查终端能力：是否支持当前配置的特性
- 检查负载情况：是否高负载导致冲突
- 对比历史数据：是突发问题还是长期问题
- 小范围验证：调整参数后先在小范围验证效果
这个清单看起来简单，但实际排查中按顺序走一遍，能避免很多"拍脑袋"式的误判。
8. 写在最后：随机接入的学习路径建议
随机接入这块内容，我的体会是"入门容易精通难"。协议里的流程图看一遍就能懂个大概，但真正要吃透，需要在实践中反复对照信令、参数和现场表现。如果你刚接触这块，我的建议是先把手头的信令跟踪工具用熟，然后找一个真实的小区，把它的随机接入相关参数全部拉出来看一遍，再结合信令跟踪理解每个参数在流程里的作用。这样学一遍，比看十遍协议都管用。
另外，NR的随机接入还在演进，两步流程、免调度接入等新特性会逐步引入。保持对协议版本更新的关注，同时不要脱离现网实践，这两点结合起来，才能真正把随机接入这块知识变成自己的东西。
