5G NR物理层深度解析：从协议栈架构到SSB与波束管理实践

1. 项目概述：为什么先讲总体架构与物理层

做5G NR协议栈开发或者测试的同行应该都有体会，很多人一上来就扎进RRC信令、NAS流程里，结果遇到物理层相关的问题就抓瞎。比如邻区添加失败、切换异常、随机接入反复失败，兜兜转转排查半天，最后发现根因在物理层——SSB频点配错了，或者PUSCH功率没算对。这个系列文章我打算从总体架构开始，逐步往下拆协议栈的每一层，第一期先把框架和物理层讲透。

这篇内容覆盖三块：第一，5G NR协议栈的整体分层结构，包括控制面和用户面各有哪些层、层间怎么交互；第二，物理层在整个协议栈里的位置和它承担的核心职责；第三，物理层最关键的功能模块——小区搜索、SSB解析、上下行信道、参数集、波束管理，以及这些模块在实际工程里怎么配合。适合三类人看：刚转5G的协议栈开发工程师、做基站或终端物理层测试的同行、以及想从信令往物理层深入理解空口行为的网优工程师。

先说一个基本判断：5G NR和4G LTE的物理层差异，比大多数人想象的大得多。LTE物理层基本是固定参数集——15kHz子载波间隔、固定帧结构，而NR引入了灵活参数集，子载波间隔可以是15/30/60/120/240kHz可配。这一改动直接影响了后续所有物理层功能的实现逻辑，从时频资源映射到波束管理再到调度时序，全部围绕这个核心变化重新设计。理解不了参数集，就理解不了NR物理层的半边天。

2. 5G NR协议栈总体架构拆解

2.1 控制面与用户面的分层设计

5G NR协议栈继承了LTE的分层思想，但针对5G的业务场景做了大量调整。整体上分为控制面（C-Plane）和用户面（U-Plane）两条栈。控制面负责信令的生成、传输和解析，包括RRC连接管理、移动性管理、安全激活等；用户面负责实际业务数据的传输，核心是IP数据包的封装、调度和空口发送。

从协议栈各层的归属看，从上到下分别是：

• NAS层（非接入层）：终端和核心网之间的信令，主要处理注册、鉴权、会话管理。对空口协议栈来说NAS层是透明传输的，RRC把它当作透传数据块封装进消息里。
• RRC层（无线资源控制）：控制面的核心大脑，负责系统消息调度、连接管理、测量配置、切换控制。NR的RRC引入了大量的灵活配置能力，比如BWP配置、波束配置、CA/DC配置都集中在RRC消息里下发。
• PDCP层（分组数据汇聚协议）：头压缩、加密、完整性保护。5G NR对PDCP的要求比LTE更高，因为要支持双连接场景下的数据分流和重排序。
• RLC层（无线链路控制）：分段、重传、按序递交。NR的RLC有三种模式——TM透明模式、UM非确认模式、AM确认模式，实际组网中最常用的是AM模式。
• MAC层（媒体接入控制）：调度、优先级处理、HARQ重传、逻辑信道复用。MAC层是物理层和上层之间的中转站，调度器就住在MAC层。
• PHY层（物理层）：把MAC层下来的传输块做编码、调制、资源映射，最终通过天线发射出去。

用户面和控制面在PDCP层以下基本复用同一套协议栈，区别在PDCP之上的承载类型。控制面的SRB（信令无线承载）走RRC，用户面的DRB（数据无线承载）直接对接SDAP层，SDAP负责QoS流到DRB的映射，这是5G新增的一层，主要服务于核心网的QoS流模型。

2.2 NR协议栈相比LTE的关键变化

NR协议栈不是LTE的小修小补，有几个结构性变化必须在理解总体架构时建立起来。

第一个变化是RLC分段的职责重新分配。LTE里RLC负责分段，MAC负责复用；NR里MAC层也能做分段，这叫“逻辑信道优先级处理时的MAC分段”。这个改动看似不起眼，实际影响不小——动态调度时MAC可以根据当前可用的物理资源量，精确控制从每个逻辑信道取多少数据，低时延业务不用等RLC层的重分段，调度粒度细了很多。

第二个变化是PDCP层引入了重排序功能。LTE的PDCP只做头压缩和加密，按序递交是RLC的活。NR因为要支持多路径（双连接、CA下的跨小区调度），RLC的数据可能从不同路径到达终端，顺序会乱，所以把重排序上移到PDCP统一管理。这也是为什么NR的PDCP缓冲区和定时器参数和LTE差异很大——它要管的不只是单个链路的重传，还有多链路间的排序。

第三个变化是把波束管理直接做进了协议栈。LTE没有波束的概念，天线发出去是全向或扇区级的覆盖。NR高低频段并用，高频段路径损耗大，单靠全向发射覆盖能力太差，必须用波束成形把能量集中在特定方向。这就导致物理层新增了波束测量、波束上报、波束失败恢复这套机制，RRC、MAC、PHY三个层都得配合处理波束，这在LTE协议栈里完全没有对应物。

2.3 逻辑信道、传输信道与物理信道映射关系

理解协议栈不能只看层，还要看“信道”这个概念。数据从上往下走，依次经过逻辑信道、传输信道、物理信道这三层映射，每一层都有自己的“打包方式”。

逻辑信道定义的是“传什么内容”——控制信令还是业务数据。常见的有PCCH（寻呼）、CCCH（公共控制）、DCCH（专用控制）、DTCH（专用业务）等。MAC层把逻辑信道的数据按优先级和QoS要求，复用到传输信道上。

传输信道定义的是“怎么传”——数据在空中接口上以什么方式传输。NR的传输信道比LTE少，去掉了BCH广播信道（广播内容移到物理层直接承载），只保留了DL-SCH（下行共享信道）、UL-SCH（上行共享信道）、RACH（随机接入信道）、PCH（寻呼信道）。5G的广播消息（MIB）直接在物理层的PBCH上发送，不再经过传输信道的适配。

物理信道定义的是“用什么资源传”——具体的时频资源、调制方式、天线端口。NR下行物理信道主要有：

• PBCH：承载MIB，和PSS/SSS一起组成SSB块
• PDCCH：承载DCI调度信令，相当于物理层的“命令通道”
• PDSCH：承载实际的下行业务数据和部分信令，相当于“数据通道”

上行物理信道主要有：

• PRACH：随机接入信道，终端第一次发起上行传输用的
• PUCCH：承载UCI上行控制信息，包括HARQ反馈、CQI/PMI/RI等
• PUSCH：承载上行业务数据和上行控制信息复用传输

物理信号则分为上行参考信号（DMRS、SRS、PTRS）和下行参考信号（PSS/SSS、DMRS、CSI-RS、PTRS）。这些信号不承载业务内容，但负责解调参考、信道测量、同步、波束管理等关键功能。

3. 5G NR物理层核心功能深入解析

3.1 参数集Numerology：整个NR物理层的地基

参数集是NR物理层最基础、也最能体现设计思路的概念。LTE用固定的15kHz子载波间隔，好处是简单，坏处是灵活性差——低频段追求大覆盖，15kHz没问题；但高频段要对抗大频偏和相位噪声，需要更大的子载波间隔来缩短符号时间，固定参数就吃不消了。

NR把子载波间隔定义为：

[ \Delta f = 15 \times 2^{\mu} \quad \text{kHz} ]

其中μ取0到4，对应15/30/60/120/240kHz。μ的每个取值对应一套完整的时域结构——循环前缀长度、每时隙OFDM符号数、每无线帧的时隙数都不一样。常用的是μ=1（30kHz）和μ=3（120kHz），前者用于中低频段的广覆盖，后者用于高频段的宽带传输。

参数集为什么重要？因为它决定了时频资源的最小粒度。NR的资源网格以“资源块RB”为单位，一个RB频域占12个子载波，时域占一个时隙。子载波间隔变大，单个OFDM符号的时间变短，同样的时隙时长内能塞更多符号，但符号变短意味着保护间隔变短，抗多径能力下降。所以选参数集本质上是在“时延、覆盖、抗干扰、峰值速率”之间做权衡。

实际工程里，一个小区可以同时配置多个BWP（带宽部分），每个BWP可以有不同的参数集。比如FR1频段（450MHz-6GHz）常用30kHz做初始BWP，再配置一个15kHz的BWP给某些对覆盖更敏感的UE。终端通过RRC重配消息在BWP之间切换，这比LTE的整个载波带宽一把抓灵活太多。

3.2 帧结构、时隙配置与HARQ时序

NR的帧长度固定10ms，一帧分成10个子帧，每子帧1ms。每个子帧包含的时隙数由参数集决定——μ=0时一子帧1个时隙，μ=1时一子帧2个时隙，μ=2时一子帧4个时隙。公式是：

[ \text{每子帧时隙数} = 2^{\mu} ]

在30kHz子载波间隔下，一个10ms帧内共有20个时隙，每个时隙0.5ms，包含14个OFDM符号（常规CP时）。

NR一个大的变化是灵活的上下行时隙配比。LTE的TDD配比是固定的7种模式，NR引入了“DL-UL-TransmissionPeriodicity”和slot格式组合配置，可以按需把时隙配成纯下行、纯上行或混合时隙。5G的时隙格式由一个叫“SlotFormat”的表控制，RRC配置+动态DCI指示相结合，理论上可以做到每几个时隙就重新配置一次上下行比例。

这带来的一个连锁影响是物理层时序的变化。LTE的HARQ时序基本固定——下行数据后4ms反馈ACK/NACK，上行传输前4ms收到调度命令。NR因为参数集和上下行时隙配比可变，HARQ时序变成了配置项。下行HARQ反馈通过PUCCH发送，具体在哪个时隙反馈由“PDSCH-to-HARQ-feedback timing indicator”字段控制，可以是同一个时隙、隔几个时隙，甚至跨子帧。上行调度的K2值（PDCCH到PUSCH的间隔）也是RRC里配好的候选值，DCI动态选择。

这个设计对理解5G空口时延很重要。如果你在排查“为什么这个UE的HARQ反馈那么慢”，不要直接怀疑设备出了问题，先查一下时隙配置和时序参数是不是合理。很多低时延业务的时延瓶颈不在空口速率，而在HARQ往返时间被时隙结构拉长了。

3.3 SSB与小区搜索：终端开机后干的第一件事

终端开机后没有任何先验信息，它要做的事是“找小区”。这个过程的物理层实现，是围绕SSB（SS/PBCH Block）展开的。

SSB是PSS（主同步信号）、SSS（辅同步信号）、PBCH、PBCH的DMRS四样东西打包在一起的时间-频率资源块，时域占4个OFDM符号，频域占20个RB（240个子载波）。PSS/SSS是已知序列，终端不知道小区ID的情况下，通过相关检测就能识别出来；PBCH承载MIB，包括系统帧号、子载波间隔、SSB子载波偏移、PDCCH配置信息等，这些是终端读取后续SIB1必需的信息。

SSB在时域上的发送位置不是固定的。NR把SSB在时隙内的几种可能位置定义成“Case A到Case E”，具体用哪个取决于频段和子载波间隔。比如30kHz时隙下，Case B定义SSB的起始符号为{4,8,16,20}，一个时隙内可能发送多个SSB。这些SSB在频域上也可能分布在不同的RB位置，终端需要盲检。

盲检的实际过程是这样的：终端先假设一个子载波间隔和频段，在中心频点附近搜PSS。搜到PSS后得到粗略的时频同步和小区ID的前一半信息，再用SSS确认完整的PCI。然后解调PBCH的DMRS，根据DMRS的位置和序列确认SSB的索引，接下来解调PBCH拿到MIB。整个过程在终端侧要求极低信噪比下也能工作——PSS/SSS序列相关增益高，PBCH用极化码编码，纠错能力强。实测下行同步在这个过程通常在几十毫秒内完成，但如果SSB频点配置和终端盲检范围不匹配，终端会一直在那转圈找不到小区。

还有个关键概念叫SCS（同步栅格）。NR的SSB频域位置不是随便放的，规范定义了同步栅格上的GSCN（全局同步信道号），基站只能把SSB放在GSCN对应的频点上。终端盲检时也是按GSCN逐个搜索。这就是为什么很多“小区搜不到”的问题——基站侧SSB频点设置不在标准GSCN栅格上，或者和终端能力支持的频点范围不匹配。

3.4 物理下行控制信道PDCCH与DCI

PDCCH是所有下行调度的“司令塔”。终端在哪个时隙的哪些资源上收PDSCH数据、用什么MCS调制编码、HARQ进程号是几，全部由PDCCH上携带的DCI（下行控制信息）决定。

PDCCH在频域上占用CORESET（控制资源集）配置的RB集合，时域上占用1到3个OFDM符号。终端需要盲检CORESET内的候选PDCCH，用RNTI（无线网络临时标识）去解扰DCI的CRC，匹配上了才说明这条DCI是发给自己的。主要有几类RNTI：

• C-RNTI：单用户调度，每个连接态UE独有
• RA-RNTI：随机接入响应使用
• P-RNTI：寻呼
• SI-RNTI：系统消息调度
• TC-RNTI：随机接入过程中的临时标识

盲检次数是有上限的——终端能力决定了一个时隙内最多盲检多少次PDCCH候选和多少个DCI。实际运维中如果在系统里看到“PDCCH盲检漏检率偏高”，先看是不是CORESET配置的聚合等级分布不合理，导致终端在有限盲检次数内没覆盖到实际使用的聚合等级；再看是不是干扰导致信噪比差、解调失败率高。

DCI的格式分好几类：DCI format 1_0和1_1用于下行调度，0_0和0_1用于上行调度，2_0到2_4用于时隙格式通知、PDCCH抢占指示等特殊场景。1_1和0_1是常规调度使用的，字段很多，包括频域资源分配、时域资源分配、MCS、HARQ信息、天线端口、SRS请求等等。做物理层测试时，DCI内容的解析准确率是检验实现正确性的核心指标之一。

3.5 物理上行共享信道PUSCH与功率控制

PUSCH承载用户上行数据，同时也能复用传输上行控制信息。PUSCH的调度有两种方式——动态调度和配置授权（Configured Grant）。动态调度走PDCCH上的DCI 0_0/0_1，每次传输都要一个调度命令；配置授权则是一次性配置好周期性传输资源，UE按周期直接发数据。后者是URLLC低时延场景的关键技术——终端不用等调度，省去了调度请求和授权一来一回的时间。

PUSCH的功率控制是物理层一个容易出问题的环节。NR的上行功率控制公式比LTE复杂，涉及开环功率、路损补偿、闭环功率调整、MCS相关的功率偏置等多个分量：

[ P_{\text{PUSCH}} = \min\left{P_{\text{CMAX}},\ 10\log_{10}(M) + P_{\text{O_PUSCH}} + \alpha \cdot PL + \Delta_{\text{TF}} + f(i)\right} ]

其中M是分配的RB数，P_O_PUSCH是目标接收功率，α是路损补偿系数（0到1之间取），PL是终端估计的下行路损，Δ_TF是传输格式相关的偏置，f(i)是闭环功率调整量。调试时最常遇到的问题就是路损估计不准——如果基站侧给终端的参考信号功率配置不对，终端算出来的PL偏大，发出来的功率过高造成干扰；偏小则解调失败，终端反复升高功率，形成干扰的恶性循环。

做测试时我见过不少“UE在小区边缘怎么都上不了行”的案例，排查到最后发现是P0_PUSCH和α配得不合理——α取大一点让终端在边缘时功率补偿更激进，或者把P0调高一点提升整体目标功率，问题就解决了。

3.6 参考信号：DMRS、CSI-RS、SRS的角色分工

参考信号是物理层最容易被轻视的模块。很多人觉得参考信号就是“导频”，随便配配就行。实际上NR的三种主要参考信号各有分工，配置错了直接影响性能。

DMRS（解调参考信号）：和解调数据绑定在一起，作用是让接收机估计信道冲激响应。下行PDSCH的DMRS配置有type1和type2两种映射方式，type1一个RE上放6个端口，type2放12个，根据MIMO层数选择。DMRS分前置DMRS和附加DMRS，前置DMRS放在数据开始的位置，让接收机尽快开始解调；附加DMRS放在时隙后面的符号上，用于高速移动场景的信道跟踪。高铁、高速等高速场景如果没有配足够多的附加DMRS，解调性能会急剧恶化。

CSI-RS（信道状态信息参考信号）：用于信道测量。终端基于CSI-RS做信道估计，算出CQI（信道质量指示）、PMI（预编码矩阵指示）、RI（秩指示）通过PUCCH/PUSCH上报给基站，基站再据此确定调度策略。CSI-RS还承担波束管理的测量功能——多个CSI-RS资源对应不同的波束方向，终端测量后上报参考信号接收功率，基站选出最优波束。做波束管理测试时，CSI-RS资源的数量、时频位置、周期都要精心设计，资源之间不能冲突。

SRS（探测参考信号）：上行信道测量的工具。终端发SRS，基站侧接收后反推上行信道状态，用于上行调度和波束选择。SRS和DMRS的一个重要区别是SRS可以宽带发送（覆盖整个BWP），做全带信道探测，帮助基站做频选调度；而DMRS只存在于实际调度的资源块上。SRS还支持天线切换——终端有多根天线但只有一个发射通道时，通过SRS天线切换可以让基站分别估计所有天线对应的信道。

个人经验：排查“下行速率差”问题时，先看CSI-RS配置是否合理，再看终端上报的CQI是否和现场覆盖情况匹配；排查“上行速率差”问题时，先看SRS发送周期和带宽是否足够，再看基站侧上行DMRS解调是否稳定。这两套检查做完，大多数物理层性能问题都能定位到方向。

4. 5G NR物理层核心流程实操解析

4.1 从开机到驻留：物理层完整流程串联

把物理层的各个功能模块串联起来看一遍，才能体会到它们之间是怎么协同的。下面以终端从开机到完成初始接入的全过程为例，梳理物理层每一步做了什么。

• 步骤1：频点扫描和PSS检测。终端根据自身频段能力和设置的搜索范围，逐个GSCN频点做能量检测。发现候选频点后，尝试在该频点附近检测PSS。PSS相关峰值超过阈值，就认为找到了潜在小区。

• 步骤2：SSS检测和PCI确认。利用PSS的时频同步结果，在同一SSB时隙里检测SSS，得到完整的物理小区ID（PCI = 3×N_ID1 + N_ID2）。

• 步骤3：PBCH DMRS和PBCH解调。在SSB的第三个OFDM符号上解调DMRS，确定SSB索引；进而解调PBCH，拿到MIB。MIB里有系统帧号高6位、子载波间隔、SSB子载波偏移k_SSB、PDCCH SIB1配置信息等。

• 步骤4：CORESET0和SIB1获取。根据MIB里的PDCCH配置，终端在对应的CORESET0（初始控制资源集）上盲检PDCCH，查找调度SIB1的DCI。收到DCI后解调PDSCH，拿到SIB1。SIB1包含小区接入参数、上下行载波带宽、PRACH配置等，终端有了这些信息才能发起随机接入。

• 步骤5：PRACH前导码发送。SIB1里有PRACH资源的时频位置和前导序列格式。终端随机选择前导码，在配置的PRACH时机上发送。基站收到后检测前导码，得到RA-RNTI和前导码标识，并通过随机接入响应（RAR）回复，携带临时C-RNTI、时间提前量、上行授权。

• 步骤6：MSG3发送和竞争解决。终端收到RAR后，在上行授权上发MSG3（RRC连接请求）。基站通过竞争解决消息确认哪个终端接入成功，同时把临时C-RNTI升级为正式C-RNTI。初始接入物理层流程到此完成。

整个流程里，任何一个环节失败都会导致接入失败。区别在于失败的表现方式不同——PSS/SSS没检测到，终端会一直驻留在“找小区”阶段，不会有任何上行信号；PRACH发了但基站没响应，终端会重试并升高前导功率；MSG3发了没收到竞争解决消息，终端重新发起随机接入。通过信令跟踪工具看这些失败发生在哪个节点，就能快速反推物理层哪个模块出了问题。

4.2 SSB频点规划与GSCN计算实例

SSB频点规划是物理层实际落地的第一步，也是最容易出错的一步。NR的SSB位置由GSCN定义，不能随意设置。我以一个实际场景说明计算过程。

假设现网使用n78频段（3300MHz-3800MHz），计划将SSB放置在3500MHz附近。根据GSCN的计算规则，n78属于0到3000GHz范围的频段，GSCN计算公式为：

[ \text{GSCN} = 6001 + \frac{F_{\text{SSB}} - 3000\text{MHz}}{5\text{kHz}} ]

如果选F_SSB = 3500MHz，那么：

[ \text{GSCN} = 6001 + \frac{3500 - 3000}{0.005} = 6001 + 100000 = 106001 ]

这个计算结果要转成实际配置里的ARFCN（NR绝对射频信道号），中间还涉及SSB子载波间隔、offsetToPointA等因素。实际配置时，我习惯先用软件工具（如NR规划工具或现网配置查询工具）把GSCN算出来，再反查SSB落点是否在该频段的同步栅格范围内。很多现场问题是因为工程师图省事，把SSB随意放在一个非GSCN的频点上，导致终端扫不到。

还要注意SSB和BWP的关系。初始BWP必须包含SSB的频域位置，否则终端在初始接入阶段读不到系统消息。常见错误是SSB频点设了，但初始BWP的起始RB和RB数没有覆盖到SSB，导致终端能检测到SSB但解不到SIB1——这个问题的排查要同时看SSB频点和BWP配置是否对齐。

4.3 波束管理与波束失败恢复实操

波束管理是NR物理层区别于LTE的典型功能，尤其在FR2毫米波频段，波束管理直接决定了连接能否建立和保持。波束管理分几个阶段：

• 初始波束建立：基站通过发送同步信号块在不同方向上的波束扫描，终端测量发现最强波束，上报波束索引。
• 波束调整：基站通过配置CSI-RS资源并让终端测量上报波束参考信号接收功率，持续跟踪波束变化。
• 波束失败检测与恢复：当终端检测到当前波束质量恶化（比如波束参考信号接收功率低于阈值），触发波束失败恢复流程——终端在专用的PRACH资源上发送波束失败恢复请求，基站通过专用PDCCH响应新的波束配置。

实际组网中，波束失败恢复是高频段掉线问题的主要原因之一。排查这类问题，重点看三个配置：

第一，波束失败检测的参考信号配置是否合理。如果检测参考信号周期太长（比如80ms以上），终端发现波束失败的时间延迟太大，恢复也会慢。第二，候选波束列表是否覆盖了所有可能的切换方向。很多掉线是因为候选波束列表配置不全，最优波束退化后终端找不到备用波束。第三，波束失败恢复的PRACH资源是否和普通随机接入资源有冲突。如果冲突，恢复请求会被普通接入请求淹没，基站检测成功率下降。

低频段（FR1）虽然波束宽度大，但也有波束管理和波束失败恢复的应用场景——大规模天线的波束成形不仅用在高频段，在FDD中低频段的容量提升项目里也很常见。所以别觉得波束管理是毫米波独占的技术，5G-A时代的低频段也会更依赖它。

5. 5G NR物理层常见问题与排查技巧实录

5.1 小区搜索失败：从频点到配置的四步排查法

我参与过的项目中，“终端搜不到小区”是最常被拉去救火的物理层问题。这种问题排查有个固定的套路，按顺序做四步检查，基本能覆盖90%以上的原因。

第一步，检查SSB频点是否在标准GSCN栅格上。用终端log的盲检过程看不出来，直接用路测软件或频谱仪看对应频点有没有SSB信号。没有信号，先查基站侧SSB配置和射频通道是否正常。有信号但终端搜不到，大概率是频点不在终端支持的搜索范围内。

第二步，检查PSS/SSS的功率配置。如果SSB功率设太低，终端在远点或者遮挡严重的场景下检测不到。SSB功率一般要单独配置，不要把下行业务参考信号功率直接当成SSB功率。有的基站设备默认把两者设成一样的，实际组网时建议SSB功率略高于业务信道，保证小区边缘和初始接入的覆盖。

第三步，检查终端侧频段能力。不同终端支持的频段范围不一样，特别是某些定制终端或旧款终端，n78频段范围可能只支持部分子集。SSB频点对不上终端的支持频段找得再多也没用。

第四步，检查外部干扰。用频谱仪扫SSB频点附近有没有强干扰信号。5G干扰排查里，SSB所在频点如果和DAS系统、私装信号放大器等杂散信号有重叠，很多弱场接入失败都是被这种外部干扰打掉的。

5.2 随机接入失败的物理层根因定位

随机接入失败分两类：PRACH没发出去、PRACH发出去了但基站没检测到。

PRACH没发出去，先看终端是否完成了下行同步和系统消息读取。很多随机接入失败的根因不是随机接入本身，而是之前的小区搜索或SIB1解码就没成功，终端压根不知道PRACH资源在哪。通过终端log查看“PRACH目的”字段能区分是初始接入、切换接入还是波束失败恢复——三者用的PRACH资源不同，失败原因也可能分别对应不同问题。

PRACH发出去了但基站没检测到，排查重点转向三个方面：前导码格式配置是否合理、PRACH时机是否有干扰、上行同步是否准确。前导格式配置方面，大覆盖半径的小区需要长前导序列（比如format 0适合小站，format 2适合远覆盖），如果覆盖半径很大却用了短前导，基站的检测窗口覆盖不到，自然检测失败。

干扰方面，PRACH资源如果和邻居小区的PUSCH调度资源重叠，互相干扰会导致检测性能下降。这类问题在log上很难直接看出来，需要用频谱仪做时频域的底噪测量。上行同步方面，如果终端的TA（时间提前量）估计不对，PRACH到达基站的时间偏移超出循环前缀容忍范围，检测也会失败——这种情况常见于高速移动场景，多普勒频偏导致定时漂移。

5.3 下行速率不达标的物理层排查清单

下行速率问题是物理层优化的重头戏。建立一个完整的问题排查思维框架比记住每一个具体问题更管用。我自己的排查顺序是：先看无线环境，再看参数配置，最后对照终端能力。

无线环境部分，下载速率首先要看CQI。CQI低（比如低于8）说明信道质量差，速率上不去是正常的物理限制，这时候要解决覆盖或干扰问题，而不是调协议栈参数。CQI高但速率还是上不去，才轮到参数配置排查。

参数配置部分，重点检查PDCCH聚合等级和MCS表选择。聚合等级选低了，终端收不到调度命令，调度机会空转；MCS表选保守了，最高只能到64QAM，速率天花板被卡死。还有HARQ最大重传次数、CQI上报周期、CSI-RS密度这些，每一个都有可能在特定场景下成为瓶颈。

终端能力部分，注意UE的DL Category支持的最大MIMO层数和最大调制阶数。有的终端标称支持5G，实际下行只支持2层MIMO和64QAM，那么理论峰值速率自然只有4层加256QAM方案的一半。排查时如果只看基站侧配置会觉得一切正常，把终端能力一比对才发现能力和预期不匹配。

5.4 上行功率异常的现场处理经验

上行功率问题在现网中常见表象包括：上行速率波动大、邻区上行干扰高、UE掉话前过度升功率。物理层层面，我分享三个实际经验。

第一个经验，先查路损补偿基准。很多上行功率异常问题的根因是基站下发的参考信号功率配置和实际发射功率不一致。比如SSB或CSI-RS的参考信号功率设了30dBm，实际射频口只有27dBm，终端据此计算出的路损就低了3dB，上行发射功率整体偏高3dB，造成无谓干扰。基站侧功率校准是上行功率问题排查的第一步。

第二个经验，闭环功率调整的步长和范围要设置合理。NR的TPC命令可以调整累积功率，但如果步长最大（2dB或更大），增益调整范围太宽，遇到信道快速波动时终端功率会震荡，反而导致解调质量恶化。把TPC步长调小一些，让功率调整更平滑，能有效减少上行调度的不稳定情况。

第三个经验，PUSCH的开环功控目标功率P0和全补偿/部分补偿的选择要配合。城区高干扰场景适合调低P0、降低补偿系数α，让终端别总是满功率发射；郊区弱覆盖场景则反过来，P0调高一些、α取1，保证远点终端能发够功率。这个参数的调优没有统一答案，要结合现场路损分布和干扰水平来做。

5.5 物理层测试与log分析要点

做5G物理层测试和调试，工具链的熟练程度直接决定工作效率。我整理几个自己常用的工具和操作习惯。

信道模拟器方面，Keysight Propsim、Spirent、Rohde & Schwarz的设备都常用，做多径衰落场景时注意时延扩展和多普勒频移参数的设置要和真实场景匹配。频谱仪方面，测SSB信号时用零频宽模式看频谱包络，检查频点位置和带宽是否和配置一致；测干扰时用余辉模式或者长时间最大值保持，能把间歇性干扰抓出来。

终端log分析方面，主流终端芯片厂商（高通的QXDM、MTK的CatTool等）都能输出物理层级别的log。重点看几个关键参数的变化趋势：RSRP、RS-SINR、CQI、MCS、RB数、HARQ重传率、PDCCH盲检次数。这些参数组合起来基本能还原物理层的每一次调度过程，判断问题是在覆盖、干扰、调度还是终端侧。

基站侧log分析方面，看CQI分布和调度结果，和终端侧log做对比，能发现是信道估计的偏差问题，还是调度器的策略问题。我实测中最常见的对不上是PDSCH的DMRS端口配置和终端上报的RI不匹配——基站以为终端能收4层，终端实际只能收2层，速率自然减半。这种问题从指标上不容易看出来，因为调度是“成功”的，只是用的层数和能力不匹配。

6. 其他高频咨询问题速查

我把过去几年被问得比较多、但不算单独成篇的问题整理成一个速查表，方便同行快速定位。

这张表没办法覆盖所有场景，但它代表了一个思路：物理层问题十有八九能归到“配置不对、资源冲突、能力不匹配、干扰”这四类中的一个。按照这个框架排查，比零散地东查西查效率高得多。

7. 实操心得与后续系列预告

写到这里，第一期的主要内容基本覆盖完了。最后分享几个个人经验，希望对刚开始做5G物理层的同行有帮助。

第一个体会：学好NR物理层，先学会从协议里找“为什么”。3GPP协议38.211（物理信道调制）、38.212（复用和编码）、38.213（物理层过程）这三本规范是核心，但别指望一上来就看懂。我的建议是先看38.331（RRC）里的物理层配置参数结构，再回到物理层规范里找参数的取值范围和含义，这样能快速建立“配置项-物理层行为”的映射关系。

第二个体会：工具只能帮你定位问题，不能帮你理解问题。无论用终端log还是基站后台，最后都要落到物理层的基本原理上——子载波间隔、时频资源、参考信号的序列行为、功率控制的计算链路。原理扎实了，任何新问题都能快速归因；原理不扎实，手上工具再多也只是瞎试。

第三个体会：做物理层测试，一定要会看波形和频谱。很多配置类问题在log上看起来模棱两可，但频谱仪一扫、信号解调一比对，问题立刻一目了然。我带了几个新人，发现他们普遍不重视频谱仪的操作能力，一到现场就只知道看软件log，效率很低。建议每个做物理层的同行都把“会用频谱仪做基础信号分析”当作基本功来练。

第四个体会：别忽视参数集之外的时间同步细节。5G物理层很多“疑难杂症”最后查出来都是时间对齐的问题——TA没估算准、时隙边界偏移、符号定时偏差累积。NR支持多种参数集共存后，时间同步的边界条件比LTE复杂，排查时多留个心眼。

第五个体会：多积累“现场感觉”。比如一个小区覆盖距离大概多远、SSB功率应该配多少、P0和α大概在什么范围才能兼顾覆盖和干扰，这些数值在书本上没有标准答案，但是做多了心里会有谱。数值一报出来就知道高不高低不低，排查效率完全不一样。

这个系列后续安排：第二期准备讲MAC层和调度器——逻辑信道优先级处理、HARQ重传管理、调度请求和BSR（缓冲状态上报）、DRX配置对调度的影响；第三期讲RLC和PDCP——分段与重传机制、头压缩、双连接下的数据分流与重排序；第四期讲RRC连接管理和移动性——包括测量配置、切换流程、条件切换、NR和LTE互操作时的RRC信令差异。每一期仍然保持同样的风格：先讲透为什么，再讲怎么做，最后是现场经验。

如果你在阅读过程中遇到具体问题，或者有想让我优先写的内容方向，欢迎随时反馈。我做这行的时间越长越觉得，物理层这东西，看似门槛高，但只要你把基本原理踏踏实实搞明白，再复杂的协议流程都能拆解成一步步可定位、可验证的环节。希望这个系列能帮你把这个“拆解”的能力建立起来。