5G NR UCI全面解析：PUCCH/PUSCH承载、格式选型与参数调优

简介：面向5G网络优化与物理层协议学习者的专题文档，聚焦5G(NR)系统中上行控制信息(UCI)的承载原理，系统讲解PUCCH在调度请求、HARQ确认/否定应答及CSI反馈中的核心作用，并对比4G网络中由PUSCH承载UCI的方式，帮助读者快速理解两代系统在控制信道设计上的差异。文档重点解读PUCCH的五种格式，逐一说明各格式的符号长度、可承载比特数、是否支持同一PRB内的用户设备复用，以及UCI与解调参考信号的复用策略；例如短格式支持短UCI且可在同一PRB内复用，中等格式采用频率分集处理，长格式承载大UCI负载，另一种中等长度格式则通过预编码OCC支持最多四个用户复用。同时依据3GPP TS 38.300逐项对比各格式的详细参数，包括起始PRB与偏移、PRB数量、频率与子帧间跳频、起始符号索引、OCC长度与索引、时隙数量、最大码率、附加解调参考信号等，便于建立PUCCH选型与配置的整体认知。压缩包内包含一份DOCX文档，体积仅18KB，内容高度浓缩、结论直接，适合作为日常参数查询或5G网络优化入门的便携手册。目前已有三百六十九人学习下载，文档同时结合UCI负载与PUCCH格式的选择关系，给出优化上行资源利用率、改善系统吞吐量与时延性能的参考思路，对有上行调度优化、UCI资源配置及网络性能调优需求的工程人员具有直接参考价值。

1. 5G(NR) 里的 UCI：上行控制信息不是“一个字段”，而是一套调度语言

第一次在网管侧看到“UCI 误码率”指标飙升时，很多人会下意识把它当成某个测量字段，实际上 UCI（Uplink Control Information）是 5G(NR) 物理层里一整套上行控制机制的总称。它承载着 HARQ 反馈、调度请求和信道状态信息三类关键内容，直接决定了下行重传率、上行调度效率和链路自适应能不能正常工作。在 SA 组网、小区类型为 NR 的现网环境里，UCI 的配置质量会直观反映到用户速率和覆盖上。这篇文章把 UCI 从内容构成、PUCCH 格式选型、PUSCH 复用规则到常见参数坑完整过一遍，适合刚上手 5G 物理层的工程师，也适合做上行容量优化的老手对照排查。

2. UCI 的四类内容和两条上行通路：先从 PUCCH 与 PUSCH 的职责边界说起

2.1 先分清四类内容：HARQ-ACK、SR、CSI，以及容易混淆的 CG-UCI

很多人会把 UCI 等同于“HARQ 反馈”，这不完整。UCI 在 NR 里实际承担了多类信息的上行传递，按用途可以分成三个传统大类，外加一个在配置授权传输中出现的特殊角色。

第一类是下行数据接收的确认信息，即 HARQ-ACK。UE 收到 PDSCH 后，需要告诉基站“收到了”还是“没收到”，通常用 ACK/NACK 区分，多码字场景下每个 PDSCH 对应最多 2 bit 反馈。第二类是调度请求（SR），UE 有上行数据要发但没有上行授权时，通过 SR 向基站要资源。第三类是信道状态信息（CSI），包含 CQI、PMI、RI 等，用于给下行调度提供链路质量参考。第四类是 CG-UCI，它在 configured grant（配置授权）的 PUSCH 上携带 HARQ 进程号、NDI 和冗余版本信息。严格说，CG-UCI 和传统三大类在协议里的归属不同，但它同样是在上行控制平面上传递的信息，做免授权调度优化时绕不开。

理解这四类的关键是优先级：HARQ-ACK 的实时性要求最高，误检代价也最大；SR 只在有上行需求时才需要发；CSI 对实时性要求相对低，但负载通常比前两类大得多。后面的 PUCCH 格式选择和 PUSCH 复用规则，本质上都是在按这个优先级分配资源。

2.2 两条通路：PUCCH 上单独发，还是挤进 PUSCH 一起走

NR 给了 UCI 两条上行通路，选择哪条不是随意定的，而是由“是否有 PUSCH 传输”和“UCI 负载大小”共同决定。

第一条是专用控制信道 PUCCH。当 UE 没有上行数据要发，或者基站特意为控制信息分配了独立资源时，UCI 就单独在 PUCCH 上发送。PUCCH 的优点是专用、可预测，调度器知道每个 PUCCH 资源上可能来什么；缺点是占用上行资源，而且 PUCCH 的容量有限，塞不下大块 CSI。

第二条是复用进 PUSCH。当同一时隙里 UE 同时有 PUSCH 数据要发，又有 UCI 要报时，UE 不一定会同时开两个信道。NR 更常见的做法是把 UCI 搭着 PUSCH 一起发，避免双信道同时发送带来峰均比问题和功率抬升。这时 HARQ-ACK、CSI 会按照规定的位置和优先级塞进 PUSCH 资源里，数据 RE 要给控制信息让位。

这里有个常见误用：有人类比 LTE 的做法，认为“UCI 和 PUSCH 冲突就二选一”。NR 里不是二选一，而是同比重地复用。至于 SR，它基本固定走 PUCCH，不会搭 PUSCH（R16 之前的标准里，SR 不参与 PUSCH 复用），所以同一时隙里 positive SR 和 PUSCH 同时存在时，需要靠 PUCCH 资源上的设计来避免冲突。

2.3 承载位置与资源分配原则：先看负载，再看时序

UCI 具体落在哪个 RE 上，由格式、符号数和资源映射规则确定，但设计原则上有一条主线：控制信息要优先保证可靠性，其次是容量。

以 HARQ-ACK 为例，它在 PUCCH 上的资源位置通常由 PDCCH 的调度信息动态推导出来，而不是完全靠 RRC 静态指定。这就是“隐式资源映射”：基站通过 PUCCH resource indicator（PRI）配合 PDCCH 起始 CCE 序号，让不同 UE 落到不同的 PUCCH 资源上。这样做的好处是省信令，坏处是如果 PUCCH 资源集配少了，多个 UE 会撞到同一个资源，这就是后面要专门讲的一个大坑。

CSI 的资源分配则偏重周期配置。在 PUCCH 上，CSI 通常按周期上报，负载受限于 PUCCH 格式的容量；在 PUSCH 上，CSI 随数据一起发送，可以塞得更大，但需要用 CSI part 1 和 part 2 分段来控制可靠性和时延。理解了这两条通路和三类信息的优先级，下一步才能看懂 PUCCH 五个格式为什么这样设计。

3. PUCCH 格式 0 到 4：一张表看清选型逻辑、容量上限与复用方式

3.1 五种格式的参数对照表：先把符号数、调制方式和容量上限对齐

NR 把 PUCCH 分成了从 0 到 4 共五种格式，它们不是按版本迭代，而是按 UCI 负载大小和覆盖需求并行设计的。选型时最需要对齐的四个维度是：符号长度、能承载的 UCI 比特数、调制方式、多用户复用能力。

Format 0 和 1 的容量上限都是 2 bit，区别在符号数。Format 0 只占 1~2 个符号，靠序列的循环移位组合来表达 ACK/NACK 和 positive/negative SR，不携带 DMRS；Format 1 占 4~14 个符号，有专门的 DMRS 符号，适合覆盖受限的用户，因为符号多可以攒能量。

Format 2、3、4 都采用 QPSK 调制，真正拉开差距的是负载和复用能力。Format 2 只有 1~2 个符号，但带宽可以拉大，适合几十 bit 以内的 CSI 加 HARQ 组合；Format 3 符号数多、不依赖正交扩频，容量最大；Format 4 在时域符号多的基础上又加频域 OCC，多个用户可以占同一份时频资源。选型的基本逻辑是：先看 UCI 负载大小，再看覆盖和复用需求，最后看时域位置能否避开下行符号。

3.2 格式 0 与格式 1：轻量反馈场景怎么选，别在覆盖上翻车

做上行覆盖优化时，Format 0 和 Format 1 是最容易被拿来做“容量换覆盖”的地方，也是最容易选错的地方。

我在现场最常见的配置是：边缘用户、或 TDD 上行符号紧张的时隙，用 Format 0 做 HARQ 反馈，因为它只占 1~2 个符号，对时隙结构影响最小。但 Format 0 的容量只有 2 bit，而且它没有 DMRS，靠序列相关性做检测，信噪比差时误检率会陡增。白天做拉网测试时可能一切正常，一到晚高峰上行干扰起来，HARQ 误检率就会抬上来，这个现象我遇到过不止一次。

Format 1 的优势在于 4~14 个符号可以做时间上的能量积累，等效信噪比更高。如果用户处于小区边缘、或者 PUCCH 覆盖半径明显不够，把 HARQ-ACK 从 Format 0 挪到 Format 1 往往比加大 PUCCH 功率更有效。代价是占用更多时域符号，挤压 PUSCH 资源。我的习惯是：边缘用户无脑给 Format 1，中心用户用 Format 0 省资源，中间地带用 Format 2 兼顾 HARQ 与 CSI。

3.3 格式 2、3、4：CSI 负载与多用户复用怎么平衡

当 UCI 负载超过 2 bit 时，就只能从 Format 2、3、4 里选。这里的判断顺序是：先看负载，再看复用，最后看时隙符号预算。

Format 2 只有 1~2 个符号，它的容量靠带宽堆出来。如果 CSI 配置了宽带 CQI 加少量 PMI，负载通常在十几到几十 bit，Format 2 就够了，而且可以放在上行符号比较少的时隙里。但要注意，Format 2 的复用能力较弱，多个用户同时上报 CSI 时容易撞资源，所以它更适合负载小、调度器可以分散放置资源的场景。

Format 3 是容量最大的格式，适合周期 CSI 负载较大的场景，比如上报 subband CQI、多天线 PMI 时，负载可以到上百 bit。但 Format 3 的时域占用是 4~14 个符号，对时隙资源消耗明显。Format 4 则是 Format 3 的复用改进版，它引入频域 OCC，让多个用户共享同一份时频资源，适合用户密集、但每个用户 CSI 负载中等的场景。

选型时最容易踩的坑是把“格式支持多用户”误理解为“容量会变大”。Format 4 加了 OCC 之后，单用户的容量比 Format 3 低，但它能让更多用户同时发。如果只追求单用户 CSI 量，Format 4 反而不如 Format 3。正确的想法是：容量不够就升格式长度，用户数太多才考虑加复用，两者不能混为一谈。

4. UCI on PUSCH 的复用规则：CSI 分段、beta offset 与速率匹配如何取舍

4.1 UCI 何时必须搭 PUSCH 的“便车”：冲突触发与双信道同时发送的代价

在 NR 里，同一时隙如果同时存在 PUSCH 调度和 PUCCH 上的 UCI 发送，UE 会优先把 UCI 复用进 PUSCH，而不是开两个信道。这样做的原因很实际：双信道同时发送会让上行发射功率分散，可能超过 UE 的最大功率，而且 PUCCH 和 PUSCH 同时发会抬高峰均比，降低功放效率。

触发复用的条件也很直接：HARQ-ACK 的反馈定时与 PUSCH 所在时隙重合，或者 CSI 的上报周期与 PUSCH 调度时隙重合。基站侧在调度时会通过 DCI 格式和时隙配置尽量避免让 UE 临时改道，但一旦重合，UE 侧没有太多选择余地，只能按协议规定的优先级把 UCI 塞进 PUSCH。

这里的优先级顺序是：HARQ-ACK 最高，CSI part 1 其次，CSI part 2 最后。当 PUSCH 的可用 RE 不够时，先牺牲的是数据，而不是控制信息。换句话说，控制信息占用的 RE 是“硬性支出”，PUSCH 数据只能围着它做速率匹配。理解了这个优先级，后面调 beta offset 和看误码率时才有据可依。

4.2 CSI part 1 与 part 2 的分段：为什么要把 CSI 拆成两段，丢弃时先丢谁

CSI 在 PUSCH 上复用时不作为一个整体传输，而是被拆成 part 1 和 part 2。这个设计刚看时会觉得繁琐，实际上它是一套保护机制。

CSI part 1 包含 RI 和宽带 CQI 等基础信息，这些是后续 PMI 解释的前提；CSI part 2 携带 PMI 和其他相对次要的信息。把 CSI 拆开的原因是：如果上行 RE 非常紧张，系统可以只保留 part 1，丢弃 part 2，这样调度器仍然知道秩和信道质量的大致水平，只是没有精细的预编码信息。如果一开始就把 CSI 捆成一个大块，丢弃时要么全丢，要么全保，调度的弹性就没了。

复用时，part 1 和 part 2 在 PUSCH 上的映射位置不同。UCI 优先从 DMRS 之后的第一个符号开始映射，然后按照 HARQ-ACK、CSI part 1、CSI part 2 的顺序占用 RE。映射顺序直接决定了干扰程度：最靠近 DMRS 的 RE 信道估计质量最好，所以最重要的 HARQ-ACK 被放在最前面，part 2 靠后，宁可被数据挤压也不能挤到 HARQ 前面。

4.3 beta offset 的取值：一个数同时控制编码功率与速率匹配行为

UCI 在 PUSCH 上占多少 RE，不是由 UCI 比特数单方面决定的，而是通过 beta offset 参数来平衡。beta offset 控制的是 UCI 编码速率：beta offset 越大，每个 UCI bit 占用的 RE 越多，编码冗余越大，抗干扰能力越强，但 PUSCH 数据能用的 RE 就越少。

NR 里通过高层配置的 betaOffsetACK-Index、betaOffsetCSI-Part1-Index、betaOffsetCSI-Part2-Index 分别控制三类信息的资源占用，DCI 里也可以动态指示。现场调优时，我会先看边缘用户的上行误块率：如果数据误码高但 UCI 还能解出来，说明 beta offset 偏保守，抢了太多数据 RE；反过来，如果 UCI 检测失败但数据正常，那就是 beta offset 太小，UCI 编码冗余不够。

复用时的速率匹配行为也要区分。如果复用是通过速率匹配做的，PUSCH 数据会绕过被 UCI 占用的 RE，解码时双方互不干扰；如果是打孔处理，数据 RE 被 UCI 覆盖后数据直接受损，严重时整块 CRC 都会失败。NR 里两种方式都可能出现，配置和调度版本不同，行为就不一样。排查上行误码时，先确定当前是哪种模式，再谈调参数，不然会走弯路。

5. UCI 参数配置中的 5 个坑：从 PUCCH 资源冲突到 CSI 超时的排查思路

5.1 现象：某小区 HARQ 误码率突升，下行重传率跟着涨，查了半天发现是两个用户抢了同一个 PUCCH 资源

这个坑我踩过一次，现象非常迷惑：误码率不高，但 HARQ 反馈总是时好时坏，重传率居高不下。

原因在于 NR 的 HARQ-ACK PUCCH 资源不是纯静态分配的，它由 PDCCH 的起始 CCE 序号和 PRI 共同推导。如果 PUCCH resource set 里只配了少数几个资源，不同用户按 CCE 规则算出来后落到同一个资源 ID 上，两个用户的 ACK/NACK 就在同一个时频位置互相干扰。信噪比看着不差，但解出来的内容经常是错的。

解决方法是先查出 PUCCH resource set 里的资源数量和 CCE 聚合等级的匹配关系，扩大资源池或者调整搜索空间的聚合等级分布，让 UE 分散到不同 PUCCH 资源上。这类问题从统计数据上看是“随机误码”，但从 RRC 配置上看却是确定性冲突，排查时必须把两个用户的 PUCCH 资源 ID 拉出来对比。

5.2 现象：CSI 上报超时，调度器一直等不到 PMI，下行 MCS 被压得很保守

现场表现是用户下行速率突然掉档，但 RSRP 和 SINR 都正常。去基站侧看 UCI 检测结果，发现 CSI 经常解不出来。

原因多半是 CSI 上报负载与 PUCCH 格式不匹配。比如把 subband CSI 配置得很大，但 PUCCH 还在用 Format 2，只有 1~2 个符号，容量装不下这么多 bit，编码率被撑到极致，稍微有点干扰就解调失败。这个配置在实验室里可能没问题，因为实验室环境干净，一到外场小干扰环境就翻车。

解决思路是二选一：要么减小 CSI 负载，关掉 subband 只保留 wideband，要么把 PUCCH 格式升到 Format 3/4，给 CSI 更多符号。不要两个都改，先只改一个变量，对比 24 小时统计，再动第二个。

5.3 现象：边缘用户 HARQ 反馈总丢，拉网测试时发现 PUCCH 覆盖半径比 PUSCH 小一大截

PUCCH 和 PUSCH 的覆盖半径不一致很正常，但如果差太多，问题基本出在格式选择上。

边缘用户如果配的是 Format 0，只有 1~2 个符号，没有 DMRS，靠序列相关性检测，覆盖能力天然弱于带 DMRS 和长符号的 Format 1。基站侧看 UE 距离并不远，但 PUCCH 的接收 SINR 已经跌到检测门限以下，反馈就丢了。

这里有个血泪经验：边缘用户的 HARQ 反馈优先考虑 Format 1（4~14 符号），哪怕它占用的时域资源多一点。上行资源紧张时，可以用 Format 1 搭配跳频来兼顾可靠性和频率分集，而不是死守 Format 0 省那一个符号。

5.4 现象：开了 UCI on PUSCH 复用后，上行误块率上升，但数据功率和 MCS 都没动

复用本身不会平白增加误码，真正出问题的是 beta offset 和速率匹配方式。

我们常见做法是先检查 betaOffsetACK-Index 的配置值。如果它偏小，HARQ-ACK 编码冗余不够，UCI 检测失败后基站会误解去重传，误块率就被抬起来了。如果 beta offset 正常，再看复用方式：打孔模式下，UCI 覆盖掉的 PUSCH RE 直接报废，数据解码相当于少了一块，CRC 失败的概率更高；速率匹配模式下，数据和 UCI 各占各的 RE，解码互不干扰。优先选速率匹配，代价是数据有效码率可能被推高，这两者需要看具体场景权衡。

5.5 现象：SR 配置周期太短，上行干扰被抬高，基站频繁给 UE 临时授权

SR 周期配得越短，UE 响应越快，但代价是 PUCCH 上的 SR 机会大量增加。在 VoIP 或周期性小包业务中，这会让 SR 几乎每个时隙都出现，调度器被迫频繁分配临时授权，上行资源碎片化，干扰电平也跟着涨。

解决方向不是盲目拉长 SR 周期，因为那会影响小包业务的时延，而是给 SR 配上合理的 sr-ProhibitTimer，让 SR 不会在短时间内反复发送。同时检查 sr-TransMax 的上限，避免 UE 在收不到授权时无限重发，把上行干扰拖到无法收拾。

6. 一线调 UCI 的入手习惯：先核三张表，再动参数

每次遇到 UCI 相关的问题，我第一件事不是看功率，也不是改周期，而是先拉出三张表核对。

第一张是 PUCCH 资源表，重点看 resource set 数量、资源 ID 总数、每个资源用的格式和符号起始位置。第二步把两个同频用户放到一起对比，大部分 HARQ 反馈丢失都能在这里找到原因。第二张是 UCI 负载表，看每个 UE 的 CSI 配置：宽带还是子带、periodicity 是多少、在 PUCCH 上还是在 PUSCH 上复用的，超过格式容量就立刻能看出来。第三张是 beta offset 表，主要核对三类 UCI 在 PUSCH 上的资源占用比例，以及复用方式是打孔还是速率匹配。

这三张表核对完之后，我才会去动参数，而且一次只动一个。改完配置不是马上看瞬时指标，而是拉 24 小时统计，重点对比 HARQ 误码率、上行 BLER 和平均 MCS 三个值。恢复问题靠数据，不靠感觉。这个习惯帮我少走了很多弯路，尤其在多站多频段混叠的场景里，靠记忆和猜测去调参基本就是在原地打圈。希望帮到你。

本文还有配套的精品资源，点击获取