5G NR PUCCH深度解析：从五种格式到6G演进的关键设计

1. 从一个容易被忽略的关键信道说起

说起5G，大多数人第一反应是"快"。下载速率、时延、带宽这些指标确实抓眼球，但真正撑起5G体验的，往往是那些藏在协议栈深处、平时不显山不露水的控制面设计。PUCCH（Physical Uplink Control Channel，物理上行控制信道）就是典型代表。它不传用户数据，却在每一次调度、每一次反馈、每一次波束调整中都扮演着关键角色。

一句话概括PUCCH的职责：终端通过它向基站上报控制信息，包括HARQ-ACK应答、调度请求SR、信道状态信息CSI，以及更灵活的PUCCH资源配置下的波束相关反馈。表面上看这只是一个"传几比特控制信息的小管道"，但深入之后你会发现，它牵涉到序列设计、频域资源配置、时隙格式、功控闭环、多天线端口映射、跨时隙调度等一系列硬核问题。甚至在3GPP关于6G的早期讨论中，PUCCH的演进方向也已经被反复提及——因为任何一代新空口，都绕不开"控制信道怎么做得更稳、更省、更灵活"这个基本问题。

这篇文章就围绕PUCCH展开，先把NR里的设计逻辑和实操要点讲透，再往6G的方向推演。适合刚接触5G物理层的人，也适合已经做过一段时间LTE或NR对接、想系统梳理PUCCH细节的工程师。毕竟"会用"只是第一步，真正在实网里碰到问题、定位问题、优化问题，靠的是对设计动机的深度理解。

2. 5G NR PUCCH的核心设计思路

2.1 为什么不像LTE那样只做一种PUCCH格式

LTE时代，PUCCH格式就那么几种，承载能力也不高，结构相对固定。NR面对的场景要复杂得多：从eMBB的大流量到URLLC的低时延，从FDD到TDD的各种帧结构，从低频到毫米波的各种波束场景，再加上不同的终端能力和不同的覆盖需求。如果沿用LTE那种"一种格式打天下"的思路，要么资源浪费，要么灵活性不足。

所以NR定义了五种PUCCH格式，按长短分为两大类：

一眼看过去，Format 0和Format 1都只能传极少的比特数，但一个短一个长，区别在哪？关键在于覆盖和容错。短格式占用符号少、开销低，但也意味着每个符号上要承载的信息密度高，信道估计和干扰抑制的压力大。长格式用更多符号换鲁棒性，适合小区边缘这种信噪比不高的场景。

Format 2、Format 3、Format 4则可以承载更多UCI比特，区别主要在于结构形式：Format 2是短格式，适合快速反馈；Format 3和Format 4是长格式，Format 4还能让多个UE在同一个PRB内复用，这在用户密集的场景下特别有用。

注意：格式选择不是越高越好。很多刚入手NR的人容易陷入"能传更多比特的格式一定更先进"的误区。实际上，格式选择要综合覆盖、时延、资源开销、终端能力等多方面因素。比如一个只需要反馈1比特HARQ-ACK的场景，硬要用Format 3，既浪费符号和PRB，还可能因为调制阶数提升而降低解调可靠性。这就是"杀鸡用牛刀"的典型反面教材。

2.2 PUCCH资源集和资源分配背后的逻辑

PUCCH资源不是简单地配一个频点、一个符号就完事，而是通过"资源集 + 资源 + 跳频 + 波束"多层组合来定义。NR引入PUCCH-Config这个IE，里面配置了一个或多个PUCCH资源集，每个资源集里又包含若干PUCCH资源。终端在需要发送UCI时，首先根据UCI比特数选择对应的资源集，再根据动态信令（比如DCI里的PUCCH resource indicator字段）或隐式规则确定具体资源。

这个分层设计有什么好处？打个比方，就像打车软件里的"车型选择"：你要送的文件大小不同、路程不同、预算不同，系统会帮你匹配不同的车型和计价规则。PUCCH的资源集就是车型分类，资源就是具体派单，动态信令则是实时调度。这种设计让网络可以在同一个小区内灵活适配不同用户的反馈需求，而不是给所有UE配一套固定的资源。

实际配置时，有几个操作要点值得留意：

• 第一个资源集通常用于HARQ-ACK小于等于2比特的场景，往往配置在小区边缘或者公共搜索空间附近，保证接入初期的反馈可靠；
• 资源集中的资源要避免与其他UE的PUCCH资源冲突，特别是同一BWP内多个UE共享资源集时，需要靠PRB偏移、循环移位或OCC区分；
• 跳频配置要结合时隙格式和实际干扰情况，不能盲目开跳频。跳频能带来频率分集增益，但也会让信道估计和功控更复杂，有时反而影响性能。

我最开始接触这套资源体系时，最大的感受是：配置项多得让人头皮发麻。但真正上手之后会发现，只要理解了"UCI大小选择资源集、DCI指示资源、PRB和序列区分用户"这条主线，再多的参数也能串起来。

2.3 UCI编码、CRC和速率匹配：小信息也有大学问

PUCCH传的UCI虽然比特数不大，但编码过程一点都不能马虎。HARQ-ACK这种信令错了，可能直接导致不必要的数据重传；CSI错了，可能让调度器基于错误信道质量做决策，进而影响整个小区的吞吐量。

如果UCI比特数小于等于2，NR直接用调制符号映射的方式，不做复杂的信道编码，但会精心选择序列和循环移位，让不同UE的符号在相关检测时能区分开。如果UCI比特数超过2，就要走真正的编码链路了：

• 首先对UCI比特做CRC附加，校验长度根据比特数决定，一般是6比特或11比特；
• 然后根据UCI类型和比特数选择编码方式，常见的是Reed-Muller码和Polar码；
• 编码后的比特流需要进行速率匹配，适配到实际分配的RE个数上；
• 最后做调制映射到对应符号上发送。

其中可以说Polar码是NR的一大亮点。在LTE时代，控制信道大量使用卷积码和咬尾卷积码，到了NR，Polar码承担了小包控制信息的编码任务，纠错性能明显更好，特别是在低信噪比环境下。PUCCH Format 3和Format 4在承载较多UCI比特时，就会用到Polar编码。

有一个坑要特别提醒：速率匹配的目标RE数，并不等于PRB数乘以每个PRB的RE数这么简单。PUCCH的RE数量要扣除解调参考信号DMRS占用的RE，还要考虑跳频时每跳的PRB数和符号数是否一致。如果两边算出来的容量对不上，轻则编码性能下降，重则直接导致解码失败。我自己就被这种"看起来很小"的RE数量差异坑过一次，定位问题时才发现是跳频两跳的符号数分配不均导致的。

3. 五种PUCCH格式的实操对比与选型要点

3.1 Format 0：序列选择里的门道

Format 0是短格式，只占1~2个符号，最多承载2比特UCI。它的核心是ZC序列的不同循环移位：发送端通过选择不同的循环移位索引来隐含表示不同的UCI比特组合，接收端通过相关检测来判别。

因为不需要显式调制比特，Format 0在资源开销上做到了极致。一个PRB里的多个循环移位可以被多个UE共用，甚至还能和CSI-RS、SRS等信号在频域上错开。这种设计在用户量大、反馈量小的场景下非常有效。

实操过程中要注意循环移位间隔。NR的循环移位配置和LTE类似，但PRB数量、梳齿结构以及干扰环境会影响实际效果。如果两个UE的循环移位太近，检测端很容易误判，严重时就是HARQ-ACK误报和漏报。建议在实际网络规划时，给小区边缘用户和信道环境差的用户预留更大的循环移位间隔，或者在资源允许时直接给他们分配Format 1的长格式。

3.2 Format 1：覆盖优先的长格式代表

Format 1是长格式，占用4~14个符号，仍然只能承载不超过2比特的UCI。和Format 0的区别在于：Format 1有显式的DMRS，用BPSK/QPSK调制承载UCI比特，而不是靠循环移位隐含信息。

这么说吧，Format 0像"手势暗号"，懂的人一看就明白，但距离远了看不清；Format 1像"面对面说话"，加上DMRS就相当于一个稳定的参考基准，信号哪怕弱一点也能猜出你在说什么。所以它在小区边缘、高速移动、深衰场景下非常有用。

Format 1的DMRS位置和符号数关系到信道估计质量。长格式本身允许跨多个符号，但DMRS密度要足够，否则信噪比再高也白搭。很多商用参数里Format 1的DMRS位置是每个时隙的第3个和第7个符号等固定位置，但不是所有情况都最优。遇到干扰较强或者信道快速变化的场景，适当增加DMRS密度会带来明显增益。

3.3 Format 2：短格式里的大载荷担当

Format 2同样只占1~2个符号，但能承载超过2比特的UCI。它通过QPSK调制和更密的RE映射来实现，这使它适合做周期性的CSI反馈，特别是那些对时延敏感、又不想占太多符号的场景。

Format 2的DMRS密度比Format 1低很多，这是为了给UCI腾出更多RE。但随之而来的问题是信道估计精度受限。如果UE的SRS和PUCCH之间没有很好的相关性，基站侧的信道估计可能不准确，解码性能就会打折扣。

所以我建议，在配置Format 2时，一定要结合SRS资源配置一起看。本质上，Format 2依赖的是"基站先通过SRS或DMRS估计信道，再在PUCCH上做相干解调"这套逻辑，SRS如果周期太长或者带宽不匹配，PUCCH性能就会受影响。

3.4 Format 3 与 Format 4：大载荷、长时长、多用户复用

Format 3支持超过2比特的UCI，占用4~14个符号，适合承载周期性和半静态CSI、多小区测量结果等数据量较大的控制信息。Format 4则在这基础上引入了UE复用能力：多个UE可以共享同一个PRB，通过不同的正交扩展码OCC来区分。

Format 3和Format 4的选择，本质上是在"资源占用"和"复用效率"之间做权衡。Format 3对单个UE来说更简单直接，解调性能也更容易保证；Format 4则更省PRB，但需要精确的功率控制和同步保证，否则OCC的正交性被破坏，复用就名存实亡了。

在实际操作中，Format 4的复用组大小要结合UE分布和功率控制精度来定。一般来说，小区中心用户之间的复用更可靠，边缘用户尽量不要强行复用。曾经有人图省事，把所有UE都塞进同一个Format 4资源组，结果边缘用户反馈的CSI频繁出错，反而拖累了整个调度效率。这种"省资源反而费性能"的案例，在实网优化中非常典型。

4. BWP、跳频、功控与多天线：那些决定PUCCH性能的底层参数

4.1 BWP内的PUCCH资源配置策略

BWP（Bandwidth Part）是NR引入的重要概念，它把系统带宽切成若干份，每个UE可以工作在特定的BWP上。PUCCH的配置也严格绑定BWP：不同BWP下，PUCCH资源集、起始PRB、跳频方式都可能完全不同。

这意味着什么呢？举个例子，一个UE在初始BWP接入时，PUCCH配置比较简单，主要保证基本反馈。后续切换到专用BWP后，可以为它配置更丰富的PUCCH资源，比如更多的资源集、更灵活的跳频配置、甚至预备多个上行波束。这种"先保证可用，再追求最优"的思路，是NR能兼顾接入效率和用户体验的关键。

配置BWP内PUCCH时，有两个容易被忽略的地方：

• 起始PRB的位置选择会影响PUCCH和其他上行信道（PUSCH、SRS、PRACH）的频域复用关系。需要仔细核对资源格栅，避免无意中重叠；
• BWP切换时，PUCCH配置要提前通过RRC信令备好，不能依赖动态DCI去临时配置控制信道。因为PUCCH是UE接入后最先要用到的上行控制通道，临时配置既慢又容易出错。

4.2 跳频：什么时候开、怎么跳、怎么算容量

跳频这个词听起来很高级，实际作用很简单：让同一份PUCCH数据在两个不同的频域位置发送，利用频率分集对抗深衰和窄带干扰。NR支持时隙内跳频和时隙间跳频两种方式。

时隙内跳频是指在一个时隙内，PUCCH从第一个频率位置跳到第二个频率位置，两跳各占一部分符号。时隙间跳频则是不同时隙使用不同的频率位置。对长格式来说，时隙内跳频更为常见。

跳频配置要明确两个参数：跳频的PRB间隔或起始PRB，以及两跳之间的符号分割点。分割点不一定是时隙正中间，具体要看DMRS位置、UCI类型和网络策略。

这里提醒一下：跳频不是免费的午餐。跳频增益在高频段、大带宽场景下明显，但在低频覆盖受限场景，频率分集收益有限，反而增加了实现复杂度。还有一种情况要警惕：如果PUCCH跳频的第二跳和PUSCH或SRS在频域上靠得太近，可能引入新的带内干扰，那就得不偿失了。所以配置跳频之前，先认真看看整个上行频域资源的使用情况，再做决定。

4.3 上行功控：PUCCH的功率怎么算、怎么调

PUCCH的发射功率不是固定的，而是由一整套功控公式决定。NR里PUCCH功控遵循3GPP 38.213的定义，基本公式包含：

• 目标接收功率P0_PUCCH；
• 路损补偿系数，由高层参数配置；
• 基于TPC命令的闭环调整量；
• MPR和功率余量等其他修正项。

功控的目标是让基站接收到的PUCCH信噪比稳定在目标水平，既不能太大造成干扰，也不能太小导致解调失败。P0_PUCCH和路损补偿系数的组合，直接决定了PUCCH覆盖范围和干扰水平。

经验上，P0_PUCCH调高，边缘用户的PUCCH接收质量会明显改善，但会抬高小区整体干扰底噪，影响其他用户。如果P0_PUCCH调低，则可能看到边缘用户HARQ-ACK漏检率上升。功控参数没有"最优默认值"，必须结合实际路损分布、干扰水平、业务模型来调。

另外要注意，功控是闭环动态调整的过程。TPC命令会在DCI里携带，UE每收到一次TPC命令，就会在累积值上加一个调整量。这种累积式功控对突发干扰的响应较慢，但胜在稳定。如果网络里有大量短时突发干扰，可以考虑配置绝对式TPC，让UE直接跳到目标值。

4.4 多天线端口和空间关系：PUCCH的波束怎么管理

NR里PUCCH可以配置多个天线端口，支持Spatial Relation Information（空间关系信息）。简单说，这个信息告诉UE用哪个上行参考信号作为波束参考——比如用某个SRS资源、某个CSI-RS资源，或者某个SSB作为参考。

这在波束管理非常成熟的毫米波场景里尤其重要。基站可以指示UE在PUCCH上使用和SSB相同的上行波束方向，保证覆盖；也可以根据信道变化更新空间关系信息，让PUCCH波束跟着用户位置走。如果空间关系配置不对，哪怕PUCCH频域资源再充足，信号可能根本到不了基站。

实操提醒：空间关系信息和TCI状态（下行波束指示）是两个维度的配置，很多人容易搞混。下行数据信道用TCI状态指示接收波束，上行控制信道用Spatial Relation信息指示发送波束。两者可以联动，但不是同一份配置。在测试环境里验证PUCCH波束切换时，我建议先把下行链路调通，再单独验证上行空间关系，避免两边同时出问题时难以定位。

5. PUCCH与其他信道的协同工作

5.1 PUCCH和PUSCH的复用关系

实际系统里，一个UE可能同时有数据要发（PUSCH）和控制信息要反馈（PUCCH）。如果两者在同一个时隙里同时发送，最常见的选择是把UCI直接复用进PUSCH传输，而不是同时开两个信道。这么做的好处是节省上行单载波特性，不让发射功率被多个信道分掉，也减少对峰均比的影响。

复用时机和具体UCI类型有关：HARQ-ACK、CSI、SR都可以被复用进PUSCH，但位置和资源配置方式不同。HARQ-ACK通常放在PUSCH的解调参考信号附近，确保信道估计质量好的区域；CSI则可能分布在整个PUSCH的RE集合上。

实际操作中需要注意PUSCH的UCI速率匹配。PUSCH中UCI占用的RE数会挤占数据RE，导致有效编码码率上升。如果UCI非常大而PUSCH资源又有限，就可能出现数据码率过高导致的误块率升高。这种事情在实网里并不少见——UCI反馈增多直接拖累了用户下行速率，表面上却看不出来。

5.2 PUCCH和SR、CSI的联动调度

SR（Scheduling Request）的作用是告诉基站"我有上行数据要发，请你给我分配资源"。CSI（Channel State Information）则是周期或非周期反馈信道质量。它们都会占用PUCCH资源，但节拍完全不同。

SR通常是周期性的，周期短则资源开销大，周期长则上行调度时延变大。CSI反馈可以是周期性、半静态或触发式，不同方式对PUCCH资源的需求差异很大。在一个真实小区里，几十个UE都在上报各自的SR和CSI，PUCCH资源规划稍不留神就会形成瓶颈。

一个比较实用的思路是按业务类型分组配置PUCCH资源。比如把低时延业务UE的SR配置在短周期资源上，把大包业务UE的CSI配置在长周期或非周期触发式资源上。这样既能满足不同业务的实时性需求，又不会让PUCCH资源全部挤在一起。

5.3 PUCCH和波束失败恢复的联系

5G NR里有一个机制叫波束失败恢复（Beam Failure Recovery, BFR）。当UE检测到当前波束质量严重下降，它会通过PUCCH发送一个专用的调度请求，指示波束失败事件并请求基站重新配置波束。这个PUCCH上的BFR请求通常使用专门配置的资源，和普通SR区分开。

这个场景对PUCCH的可靠性要求极高，因为波束都已经失败了，信道质量本身就是最差的状态。如果PUCCH资源配置在同一个失效波束方向上，那这个求救信号可能根本发不出去。所以BFR的PUCCH资源往往会配置在更鲁棒的方向或更低的调制方式上，确保万不得已的时候还能喊一嗓子。

我在测试毫米波终端时遇到过这样的情况：下行波束指向已经偏了，但PUCCH的Spatial Relation信息还指着旧方向，导致BFR请求反复发送失败。后来把PUCCH的空间关系改为基于SSB的宽波束参考，BFR才恢复正常。这说明，BFR的PUCCH配置不能和普通PUCCH完全混为一谈，它的设计原则是"宁稳勿快"。

6. 从5G到6G：PUCCH会走向哪里

6.1 6G候选频段和信道特点对PUCCH的挑战

6G的讨论已经非常热，其中一个共识是：6G会向更高频段扩展，同时覆盖更多样的场景，包括通感一体化、超大规模连接、极低功耗终端等。这些新场景对上行控制信道提出了完全不同的要求。

高频段带来的首要问题是信道衰减大、波束窄。PUCCH如果仍然采用"UE主动上报"的固定格式，在覆盖和功耗上都会很吃力。所以行业里对6G PUCCH的讨论，往往集中在"如何让控制信道更省功耗、更抗干扰、更适应分布式节点架构"。

另一个关键变化是：6G不再只是基站和终端之间的单链路，而是可能包含大量中继节点、可重构智能表面，甚至终端直通。控制信息的产生主体和接收主体都变得更加多元，PUCCH的设计就不能再局限于"终端发给基站"这一种模式了。

6.2 可能的技术演进方向

基于现有研究文献和标准化讨论，PUCCH在6G时代可能朝以下几个方向演进：

• 更灵活和更短的格式：为了适配极低时延场景，PUCCH格式可能需要进一步缩短到单符号甚至亚符号级别，同时保持足够强的纠错能力；
• 更强的干扰抑制与免授权传输：在超大规模连接场景，海量终端同时上报控制信息的概率大增，免授权传输和更智能的干扰消除技术会变得更关键；
• 更精细的波束和空间维度利用：PUCCH的发送波束可能会由AI辅助预测，而不是单纯依赖基站配置的空间关系；
• 更智能的资源分配：引入AI/ML技术对PUCCH资源需求进行预测和动态编排，减少资源碎片，提升频谱效率；
• 通感一体化场景下的复用：PUCCH可能与感知信号在某些频段上复用，同时实现通信和感知功能，这对序列设计和信号结构又提出了新要求。

这些方向里，我个人最关注的是"AI辅助PUCCH资源编排"。因为从5G的经验来看，PUCCH的问题很多时候不是单一链路质量问题，而是系统级的资源分配、干扰管理和调度策略问题。AI在这方面的潜力很大，值得持续关注。

6.3 对物理层工程师意味着什么

从5G到6G，PUCCH的演进不会是一张白纸重画，而是基于现有NR框架的持续迭代。对做物理层、协议栈、算法或者网络优化的工程师来说，现在扎实掌握PUCCH的NR设计，就是在为6G打底。

举例来说，如果你能深入理解PUCCH Format 0的序列检测原理，那未来6G里再出现新的短序列设计，你也能很快上手；如果你能熟练排查PUCCH功控和波束配置问题，那6G引入AI调度器时，你也能清楚地知道该用哪些数据训练模型、该验证哪些指标。

说到底，无线通信的底层物理规律没变，变的只是组合方式和优化维度。控制信道永远要做的一件事，就是用尽量少的资源、尽量稳的质量，把关键信息送达对端。

7. 常见问题排查与经验速查

7.1 PUCCH解码失败的排查路径

PUCCH解码失败的原因五花八门，但排查思路是有规律的。下面这套路径我用了很久，值得参考：

1. 先确认UE是否真的在期望的时频资源上发送了PUCCH。可以通过基站侧日志或协议分析仪查看，判断是不是调度和实际发送不一致；
2. 再查PUCCH功控。接收功率是否在预期范围内，边缘UE是否长期处于功率受限状态；
3. 然后看信道估计质量。DMRS位置、跳频结构、SRS关联这些都可能影响信道估计；
4. 接着查干扰底噪。PUCCH频段附近是否存在PUSCH、SRS或其他PUCCH的干扰；
5. 最后看UCI载荷和编码配置。如果UCI大小和资源容量不匹配，解码性能再好的算法也救不回来。

7.2 PUCCH配置中的常见问题速查表

7.3 容易被忽略的配置细节

再分享几个实际踩过坑的细节：

• PUCCH资源集开关和BWP切换之间要联动核对。资源集配置在BWP1里，但UE已经切到BWP2，此时PUCCH会直接失联；
• UCI复用进PUSCH时，别忘了检查PUSCH的RE容量。UCI挤占数据RE后，码率变化可能比想象的大；
• 不同子载波间隔下，PUCCH的符号长度和跳频粒度都不同。换SCS时不能只改数值，要看整体资源配置是否匹配；
• 做实验室测试时，尽量模拟真实的干扰环境，不要只在干净信道下测PUCCH。很多问题只在有干扰时才会暴露。

8. 写在最后的一点体会

做无线物理层的时间越长，我越觉得控制信道才是整个系统的"隐形骨架"。数据信道出了问题，影响直观、定位迅速；控制信道出了问题，往往表现为一些间接症状——时延变大、吞吐量波动、切换成功率下降，但就是找不到具体原因。而PUCCH因为承载的都是"小信息"，更容易被忽略。

我个人在调PUCCH功控和资源配置时最大的感受是：宁可在配置阶段多花一小时核对资源格栅和干扰分布，也不要等到实网出问题时再回头翻日志。控制信道的容错空间远小于数据信道，一次配置偏差就可能引发连锁反应。

5G NR的PUCCH设计已经是相当成熟的体系，但从6G的角度回头看，它还远不是终点。更高频段、更大连接密度、更低功耗，这些趋势都会持续推动上行控制信道的演进。对每一位和无线物理层打交道的工程师来说，把NR PUCCH的每一个细节吃透，既是对当前工作的负责，也是为下一代系统积累判断力。控制信道不显眼，但它永远值得认真对待。