5G物理层PUCCH深度解析：从格式、资源配置到6G演进

把5G的物理层拆开看，PUCCH（Physical Uplink Control Channel，物理上行控制信道）绝对是最容易被低估，却又最“见真章”的地方。UE再强的下行速率，如果上行控制信息传不回来，整个链路就是空转。而恰恰是这个看似低调的信道，从5G的R15一路演进到R18，再到面向6G的技术预研，几乎是观察“控制面未来走向”的最佳窗口。这篇解析不打算堆教科书，而是从实际工程出发，把NR PUCCH的格式、资源、波束、功控，以及它与6G愿景之间的关联，彻底捋清楚。

1. PUCCH到底是什么：不是“一个小信道”那么简单

1.1 上行控制信息（UCI）：UE到网络的“状态汇报”

PUCCH承载的是UCI（Uplink Control Information），但UCI不是一种东西，而是三种关键信息的总和。

第一是HARQ-ACK，也就是下行数据包到底收到没有。5G采用HARQ（混合自动重传请求），UE收到PDSCH数据后必须通过PUCCH反馈ACK/NACK，网络才能决定是继续发新数据还是重传旧数据。HARQ-ACK的时延直接影响下行吞吐率，尤其在URLLC场景下，反馈时延往往比数据本身的传输时延更致命。

第二是SR（Scheduling Request，调度请求）。UE没有上行数据要发，但突然来了新数据，总不能干等网络调度，需要主动举手说“我有数据了，给点资源”。SR在周期性的PUCCH资源上发送或复用其他UCI。SR的特点是“0/1信息”：要么有需求，要么没有，但它的检测可靠性和时延有严格要求，否则会让业务明显卡顿。

第三是CSI（Channel State Information，信道状态信息），包括CQI、PMI、RI，以及L1-RSRP等。CSI的作用是告诉网络下行信道现在怎么样，网络据此选择调制编码方式和预编码。这部分信息量最大，可能需要几十个比特，而且分Part 1和Part 2，Part 1必须先传，否则网络无法解出Part 2。PUCCH格式的复杂度，很大程度就是被CSI撑起来的。

1.2 为什么不直接塞进PUSCH？独立信道存在的逻辑

有人问：UE不是有PUSCH吗？为什么还要PUCCH？确实，规范里有一个叫“UCI on PUSCH”的机制，允许在没有PUCCH资源或者需要跟着数据一起传的时候，把UCI搭在PUSCH上。但这是“兜底方案”，不是“常态方案”。

PUCCH独立存在的核心原因是：控制信息和数据有完全不同的可靠性目标。数据误码了可以靠HARQ重传，但CSI/SR/HARQ-ACK本身是控制信息，如果传丢了，网络会做出错误的调度决策。PUCCH被设计成低阶调制、强序列相关、高冗余的传输方式，不需要像PUSCH那样追求高频谱效率，而是追求极低的漏检概率和误检率。更重要的是，PUCCH是周期性/半静态存在的，UE如果没有上行数据，就没有PUSCH，那么控制信息必须有一个常驻的、独占的通道。

从资源上看，PUCCH占据的RB数量往往很少，但位置是精心设计的——通常分布在带边（edge of band），避开PUSCH的中心区域，这样既不影响数据调度的连续性，也能利用频率分集。如果你把PUCCH去掉，单靠PUSCH抢占式传输，调度开销和冲突概率会急剧上升。所以，PUCCH不是为了占资源而存在，它是上行调度体系的“心跳”。

2. NR PUCCH格式体系：五种格式背后的设计宇宙

2.1 五个格式的定位：短与长的艺术

NR的PUCCH格式从0到4共五种，不像LTE那样单纯靠格式0/1/2划分。NR的划分逻辑是：先按持续时间分“短PUCCH”（1至2个符号）和“长PUCCH”（4至14个符号），再按容量分序列和变换域。

Format 0和1是“少比特但要足够稳”；Format 2/3/4是“多比特但也要稳”。为什么要搞这么多格式？因为直接用一个格式覆盖所有场景必然顾此失彼。短PUCCH支持低时延，长PUCCH支持深覆盖和更多复用用户。打个比方：短PUCCH像“外卖跑腿”，送快件但一次就一两封；长PUCCH像“物流货车”，跑得慢但能装很多货，还能几家共用一辆车。所有格式都有存在的必要，关键是网络侧怎么选。

2.2 Format 0和Format 1：序列里的“暗号”

Format 0是NR特有的，而且非常精巧。它不显式传比特，而是用“循环移位（CS）”和“序列索引”来编码信息，也就是“无数据调制”的序列选择。最多2比特的HARQ-ACK可以用不同的CS偏移来区分：例如CS=0表示NACK，CS=3表示ACK，CS=6表示SR+ACK等。接收端只需检测每个候选CS上的能量即可。这种设计的优点是极低的信噪比要求，缺点是如果信道的时间偏移估计不准，循环移位会相互干扰。所以Format 0对频偏和时偏校正要求很高，否则几个用户之间会“串台”。

Format 1则更传统一些：基序列调制BPSK/QPSK符号，然后乘以正交覆盖码（OCC），让多个UE在同一时频资源上用不同的OCC区分。特别注意，OCC的复用能力受限于信道是否平坦，在高速场景下多普勒效应会破坏OCC的正交性。所以Format 1虽然能复用，但并不是无限制地塞用户。实际配置时，我一般建议Format 1每块资源最多复用6个用户（长度为6的OCC），如果用户信道变化大，就把复用数降到3甚至2。

2.3 Format 2/3/4：大容量CSI的“三条路线”

Format 2用CP-OFDM，好处是可以灵活调度资源块和调制方式，但它对PAPR（峰均比）不友好，所以UE的发射功率回退（power backoff）较大。Format 2适合短时间突发的大CSI反馈，比如周期CSI、波束测量后的CSI上报。

Format 3和Format 4都采用DFT-s-OFDM，PAPR低，功放效率高。Format 3是纯粹的“大容量长路”，最多可以承载上百比特的CSI，对于高阶MIMO的低秩信道信息足够用。Format 4则另辟蹊径：在频域做梳状（comb）结构，每个UE只占用每隔几个子载波的频域资源，但时域上多个UE通过不同的OCC叠加在相同DFT-s-OFDM符号上。这种设计让Format 4既能低PAPR又能多用户复用，代价是实现复杂度高，因为需要处理频域开梳引起的频域频谱不连续和时域包络变化。

选择哪一格式，取决于你需要“多快”“多长”“多少用户”。没有银弹，只有匹配。

3. 从资源配置到波束管理：PUCCH的现场部署指南

3.1 PUCCH-Config：用RRC把“网”织好

在基站配置中，PUCCH所有参数都收拢在PUCCH-Config这个IE里。别小看这份配置，它决定了UE在哪个时隙、哪个符号、哪块资源上发送UCI。核心结构包括：

• pucch-ResourceSet：把多条PUCCH资源聚合在一起，类似“资源池”。每条资源内部要定义格式类型、起始PRB、符号起始点、符号数、序列相关参数。
• pucch-Resource：具体的资源ID，关联到一个格式（format 0/1/2/3/4）的实例。
• schedulingRequestResource：SR的专用资源，可以配置周期、偏移和PUCCH资源ID。
• pucch-PowerControl：包括p0-nominal、p0-UE、路径损耗参考RS、闭环索引等。

配置的误区往往出在“资源映射”上。很多刚入行的工程师以为PUCCH资源随便指定，结果造成同小区用户间的PUCCH资源碰撞，或者与PUSCH的DMRS位置冲突。我曾经排查过一个小区连续上报CSI错误的问题，最后发现是Format 2的符号落在了该时隙的最后一个符号，而该符号恰好被配置为PUSCH的第二个DMRS符号，UE在同一时刻无法同时发送，导致PUCCH被丢弃。后来我把PUCCH Format 2放到时隙中间，问题直接消失。

3.2 空间关系与功率控制：波束对了，一切才会对

NR高频段的最大特点就是波束。PUCCH在上行也必须有“空间关系”（SpatialRelationInfo），告诉UE用哪根上行波束发送。通常PUCCH会跟随一个下行参考信号（例如SSB或CSI-RS）的波束方向，或者使用独立的SRS资源作为空间参考。在初始接入阶段，PUCCH默认跟随SSB波束；但在波束管理过程中，如果网络发现SSB波束不够精细，就会通过MAC CE更新PUCCH的空间关系为某个更窄的CSI-RS或SRS波束。

更新空间关系后，必须一并重配路径损耗参考RS。如果只更新波束方向，不更新路损参考，UE会用错误的参考信号测量路损，进而算错发射功率。我在外场就见过这种“半调子”配置：波束更新后UE的新波束方向放大了，但路径损耗值变小，功控结果导致PUCCH发射功率不足，丢包率大增。这个问题用信令跟踪很难肉眼发现，因为RRC重配置本身就是成功的，为什么不看实际上报的PHR和PUCCH误码率呢？排查功控问题一定要先核对SpatialRelationInfo和pathlossReferenceRS必须在同一次更新里同步做。

功控公式本身不复杂：P_PUCCH = min(P_CMAX, P0_PUCCH + PL + Δ_format + Δ_F_PUCCH + 闭环)（换算成dBm格式）。其中PL就是基于参考RS的路损。发射功率不能无限大，P_CMAX是上限。配置P0的高低直接影响覆盖：P0定高了，代价是小区间干扰上升；定低了，边缘UE解调不了。对于深覆盖场景（比如地下车库、远海），我一般会通过pucch-CoverageEnhancement或重复次数（比如重复8次）来弥补，而不是无脑抬P0，这样能兼顾功率控制和干扰。

3.3 一份典型的高频PUCCH配置示例

为了让大家有可参照的“抄作业”模板，我给一份典型的基站侧PUCCH配置片段（注意这只是一个示意，具体参数以设备实现为准）：

c复制PUCCH-Config {
    pucch-ResourceSetToAddModList {
        pucch-ResourceSetId 1,
        pucch-ResourceIdList { 0, 1, 2, 3, 4, 5, 6, 7 }
    }
    pucch-ResourceToAddModList {
        // Format 0: 反馈HARQ-ACK + SR
        pucch-ResourceId 0,
        startingPRB 1,
        format {
            format0 {
                initialCyclicShift 0,
                nrofSymbols 2,
                startingSymbolIndex 10
            }
        },
        pucch-ResourceId 1,
        startingPRB 1,
        format {
            format0 {
                initialCyclicShift 3,
                nrofSymbols 2,
                startingSymbolIndex 10
            }
        }
        // Format 2: 大容量CSI，用CP-OFDM，短格式
        pucch-ResourceId 2,
        startingPRB 50,
        format {
            format2 {
                nrofSymbols 2,
                startingSymbolIndex 8,
                maxCodeRate 0.5,
                nrofPRBs 4,
                intraSlotFrequencyHopping enabled
            }
        }
        // Format 1: 长覆盖HARQ-ACK
        pucch-ResourceId 3,
        startingPRB 80,
        format {
            format1 {
                initialCyclicShift 0,
                nrofSymbols 14,
                startingSymbolIndex 0,
                frequencyHopping { secondHopStartPRB 90 },
                timeDomainOCC 0
            }
        }
    }
    schedulingRequestResourceToAddModList {
        schedulingRequestResourceId 1,
        periodicityAndOffset {
            periodicityAndOffset-sl10 0 // 周期10ms，偏移0
        },
        resource 1
    }
    format2 {
        dmrsInitialPosition 0,
        additionalDMRS 0,
        maxCodeRate 0.35,
        nrofSLots 1,
        subcarrierSpacing 30kHz
    }
}

有几个配置要点必须提醒：第一，Format 2的maxCodeRate决定了CSI能够压缩到什么程度，如果配置太高（比如0.7），CSI会被严重压缩，波束管理就会出现“噪声型测量”。第二，至少给Formats 0/1/2都预留不同区域，不要挤在同一个PRB附近，尤其是带内跳频（intraSlotFrequencyHopping）开了以后可以让UE在一个时隙内的两个符号跳频，但如果跳频目标PRB与PUCCH资源冲突就直接碰撞。第三，如果是高频段，一定要在所有PUCCH资源里额外配置SpatialRelationInfo，否则UE回退到默认SSB波束，波束增益可能不够，覆盖半径缩水。

4. 用PUCCH的视角看5G向6G演进

4.1 5G-Advanced的增强：PUCCH在追赶什么

到了5G-Advanced（R18/R19），PUCCH的主要增强方向是：第一，多TRP下的PUCCH分集。传统单TRP只有一个上行路径，多TRP场景下PUCCH可以在两个TRP上重复发送，本质上是“空间重复”，让检测成功率大幅提升。第二，降时延增强：支持一个时隙内更短PUCCH（比如1符号）和更密集的SR周期，把控制时延降到百微秒级。第三，覆盖增强：重复次数、功率合并，以及对有限能力的低复杂度UE做特别标定，让PUCCH在IoT/RedCap场景下也能发送。

这些增强不是平白无故出现的，它们都对应一个现实困境：下行速率已经很高了，但控制信令的可靠性和时延却成为瓶颈。比如工业互联网里一个机器臂的下行指令只有几十字节，但HARQ反馈如果出错，可能让机器臂停顿数百毫秒。所以5G-A做的不是给PUCCH“堆码率”，而是让它变得更灵活、更强健、更善于“接力”。

4.2 6G愿景：控制信令会消失吗？不，它会变形

6G愿景通常包括沉浸式通信、通感一体化、超大规模连接、AI与通信融合等。很多人问，6G还需要PUCCH吗？我的判断是，PUCCH作为一种“专用控制信道”的概念可能会被重塑，但控制信息本身不会消失。

在6G的超高带宽和太赫兹通信里，波束管理会更频繁，控制信令量和时延要求将大幅提升。这时候，固定分配式的PUCCH可能不够灵活，需要引入“即需即建”的控制通道，也就是“control-plane on demand”。比如通过预测式调度，在数据通道上叠加极短的控制头；或者在AI辅助下，让UE提前在资源池中抢占无冲突的控制资源。

另一个重要方向是通感一体化。基站不仅接收通信数据，还能感知周围环境（比如雷达探测），那么PUCCH上的上行控制信息也许会和感知信号融合。比如同一个符号既发送HARQ-ACK，又携带UE感知测量量的部分信息。这会让序列设计面临新的挑战：你既要在非常低的信噪比下检测出几个比特的ACK，又要从同一个资源里提取出多普勒速度或者散射体位置。目前已有不少学术研究在探索基于前导序列的联合通信感知编码，但距离标准化还早。

AI也会深度介入PUCCH。UE可以在本地利用AI信道预测，自动调整PUCCH传输方案（如选择格式、符号数、发射方向），而不再完全依赖网络配置。这会改变“RRC全量配置”的模式，变成“网络给一个控制资源池，UE用AI做瞬时选择”。这听起来很美好，但要解决信任和冲突问题——AI预测错了怎么办？冲突检测和回退机制必须跟上。

4.3 从“信道”到“服务”：控制面演进的底层逻辑

如果把5G的PUCCH看作是“物理层的邮局”，那么6G的控制面更像是“智能调度中心”。5G时代，我们努力把每一种UCI放到一个预先设计好的格式里，本质上是物理层静态定制。6G时代，因为空口极快、业务极多，需要把控制信息的发送权更多地下放给UE侧的智能决策，而网络侧用更宽泛的资源池来容纳不可预测的请求。听起来很虚，但PUCCH恰恰是这场演变的“最小化模型”——你已经能看到从Format 0的序列暗号，到Format 4的梳状复用，再到5G-A的多TRP分集，这是在把信道从“铁轨”变成“公交专用道”。6G则是把公交专用道变成“随叫随到的智能班车”。既然6G还在研究阶段，这部分的客观信息并不多，但趋势判断是有工程依据的：控制信息的表达方式将跟着物理波形和网络能力的升级一起变形，而PUCCH这个看似不起眼的物理信道，会是观察这一切的极佳窗口。

5. 常见问题与排查技巧实录

5.1 PUCCH检测不到或误码率高：先查时空再查功率

现场最常见的问题就是“UE显示RRC连接正常，但调度器就是拿不到HARQ反馈”，或者“CSI上报极少”。我总结的排查顺序是：第一，先查时域配置，看PUCCH符号是否和SSB或SIB1中的RB冲突，尤其是TDD配置里上行符号为1至2个的时候，PUCCH很容易被塞到下行符号里直接丢失。第二，查频域配置，确认PUCCH起始PRB没有超出上行可用带宽。第三，查空间关系，如果高频波束失配，PUCCH可能发到错误的波束方向，路损参考值偏大或偏小。第四，查功控P0，特别是在小区和边带场景，P0过低会让弱信号覆盖范围内无法解调。

用信令跟踪时，重点看上下行RRC重配置是否同步——我见过由于RRC重配UE的PUCCH格式从Format 1切到Format 2，但因为配置下发和生效的时隙有偏差，UE在旧资源上发送新格式，基站解出了乱码，最终触发RRC重建。这类问题往往在“动态切换资源集”时发生，建议在切换前后保留旧资源至少20ms。

5.2 资源冲突：隐藏得很深的“隐性碰撞”

资源冲突往往不是体现在峰值冲突，而是体现在“边缘用户互相踩踏”。Format 0用CS区分不同UE，如果两个UE的CS就近（比如CS=0和CS=1），且信道频偏较大，那么接收端的相关检测就可能混淆。所以，给同一PRB上的多个UE分配CS时，要尽量让CS间隔足够大，比如间隔至少3或4。Format 1的OCC复用也一样，OCC的长度和置零间隔需要在小区内统一规划，否则会出现“OCC污染”。

还有一类冲突来自SR和HARQ-ACK复用。如果一个UE的SR资源恰好和另一个UE的HARQ-ACK资源重叠，网络端只能用加倍的盲检去解，或者直接放弃其中一个。排查方法是：在网管里导出PUCCH资源占用图，把同小区在相同PRB/时隙上的不同资源ID拉出来做对比，凡是重叠就是隐患。

5.3 功控和波束失配：一个案例

某项目中，用户反映距离基站400米的地方，PUCCH解调成功率从99%掉到90%，但PUSCH数据几乎没有影响。检查发现，PUSCH用的是“UE-specific波束”并通过SRS校准，而PUCCH还停留在初始SSB波束，两个波束之间的偏角超过3度，在400米处路损差异接近4dB。而且PUCCH的pathlossReferenceRS仍是SSB，终端测量的路损比实际波束路损小3dB，最终发射功率偏低。解决办法是，在波束管理完成后，立刻用MAC CE更新PUCCH空间关系到CSI-RS波束，并把pathlossReferenceRS一起换掉。这种问题在FR2尤其常见，FR1也会发生在有大规模天线阵列的站点，只是不那么剧烈。

5.4 速查表：PUCCH常见问题快速定位

最后分享一个实际用起来很顺手的习惯：每配置完一轮PUCCH，我都会在基站侧导出一份“PUCCH资源冲突检查报表”，把同小区的所有PUCCH资源（包括Format 0/1/2/3/4）在时隙符号和PRB的角度做一次光栅扫描。只要同一条资源池里出现“同符号+同PRB+不同CS/OCC”以外的重复，就说明配置有问题。很多无线问题看起来是覆盖或干扰，其实根子出在“资源摆放”上。物理层的功夫，一半在计算，一半在细心。PUCCH这小东西，恰恰是检验细心程度的试金石。