企业官网建设流程全解析

简介：这是一份聚焦5G(NR)网络上行控制信息(UCI)的图文资料，面向5G网络优化工程师、通信协议开发及学习NR物理层的人员。资料以3GPP 38.300/38.211为依据，系统梳理UCI在物理上行控制信道(PUCCH)与物理上行共享信道(PUSCH)之间的承载机制，并与4G网络中主要通过PUSCH承载的做法进行对比。核心内容围绕PUCCH的Format 0～4展开，逐一说明各自适用的符号长度、可携带比特数、是否支持同一PRB内的用户设备复用，以及UCI与解调参考信号(DMRS)的复用方式；其中Format 0与1适用于短UCI，Format 2、3、4用于较大负载，且复用能力各有差异。同时逐项对比起始PRB、频内跳频、第二跳PRB、起始符号索引、符号数、初始循环移位、时域OCC、OCC长度与索引、子帧间跳频、附加DMRS、最大码率、nrofSlots、π/2-BPSK等参数，便于根据网络负载与用户需求选择最合适的承载格式。资源为单一docx文档，大小仅18KB，下载后可在手机或电脑上随时查阅，当前已有369人学习下载。文档从实际优化角度说明了UCI承载方式对资源利用率和时延性能的影响，可为配网、调度及功率调整提供参考依据。

1. 5G(NR) 网络中的 UCI：从 DCI 之外的另一半控制面说起

做 5G 优化的人，天天盯下行调度，盯着 DCI 里的 CQI、MCS、RB 分配，却很容易忽略一个事实：下行调度做得再漂亮，UE 得把 HARQ ACK/NACK、CSI、SR 这些反馈传回来，闭环才转得起来。在 4G 时代，这些上行控制信息主要靠 PUSCH 捎带，信道紧张时反馈时延和可靠性都没保障；到了 5G NR，协议引入了 UCI（Uplink Control Information）这个明确的上行控制指示概念，并专门设计了 PUCCH 来承载它。这篇笔记基于一份实战拆解资料，先把 PUCCH 五种格式的差别讲透，再把每个配置参数落到 3GPP 38.331 的实际字段上，最后聊网络优化时最容易因为 UCI 配置翻车的几个场景。适合刚接触 5G 网优的工程师，也适合被 PUCCH 参数表搞得头大的协议阅读者——这份资料的价值，就是把协议里分散的表格和参数定义，收敛成一张可以直接查着配置的对照表。

2. UCI 承载场景与 PUCCH 格式选型：先搞清什么时候走 PUCCH、什么时候走 PUSCH

2.1 承载 DCI 的场景判定：为什么不是所有 UCI 都走 PUCCH

资料正文里有一句关键的话：UCI 是由 PUCCH 还是 PUSCH 承载，是根据承载 DCI 的场景决定的。这句话看着简单，实际理解时要拆成两层。第一层是调度的产物——当 UE 没有上行数据要发，gNB 只给它分配了 PUCCH 资源，那 HARQ ACK/NACK、SR、周期 CSI 就全部通过 PUCCH 反馈；当 UE 有 PUSCH 调度时，gNB 通过 DCI format 0_0/0_1 调度了上行数据，UCI 可以选择跟着 PUSCH 一起走，这叫 piggyback，目的是省掉单独的 PUCCH 资源。第二层是参数配置的产物——PUCCH 资源配置在 PUCCH-Config 里，PUSCH 调制方式、RB 数、时域位置由 DCI 决定，两者的时频位置、跳频图样如果配置得不好，UCI 在 PUCCH 上被干扰或在 PUSCH 上被打孔，都会直接表现为误块率上升和下行重传增加。

2.2 五种格式的本质差异：符号长度与比特数的乘积决定了你的策略

38.211 里对 PUCCH 格式的定义，最核心的两个维度是符号长度和 UCI 比特数。Format 0 和 Format 1 的 UCI 载荷都是小于等于 2 bit，区别在于 Format 0 只有 1~2 个符号，典型用于 HARQ-ACK 的快速反馈，靠序列选择（sequence selection）和循环移位（CS）来区分不同 UE；Format 1 拉到 4~14 个符号，UCI 和 DMRS 在时域上时分复用，同样支持同一 PRB 内多 UE 复用，只是复用维度从 CS 扩展到 CS + 时域 OCC。我的理解是：Format 0 是给「越快越好」的场景，Format 1 是给「反馈少但覆盖弱」的场景——符号多了，时间分集增益就有了，小区边缘的用户会明显受益。

Format 2 开始进入另一个世界。它的符号数虽然还是 1~2 个，但 UCI 比特数大于 2 bit，典型承载 CSI 或 HARQ-ACK + CSI 的联合反馈。因为比特数多了，不能再靠序列选择，必须用 QPSK 显式调制，UCI 和 DMRS 在频域上复用（FDMed），同一 PRB 内不支持多 UE 复用，只能靠不同 PRB 分开发。Format 3 和 Format 4 都是长 PUCCH，4~14 个符号，区别在复用能力：Format 3 不支持同一 PRB 内复用，适合大载荷 CSI；Format 4 支持最多 4 个 UE 在同一 PRB 内复用，靠 Pre-DFT OCC 区分，occ-Length 取 2 或 4，occ-Index 取 0~3。一句话总结选型逻辑：比特数小于等于 2，看时延要求选 Format 0 还是 Format 1；比特数大于 2，看是否需要复用和多 UE 容量，在 Format 2/3/4 之间取舍。

2.3 一个实操判断方法：从 UCI 载荷倒推 PUCCH 格式

有个快速判断的技巧。先数 UE 要反馈的内容有多少 bit。只有 HARQ-ACK 且没有 SR 时，1 bit 或 2 bit 的反馈用 Format 0 最省资源；带着 SR 一起反馈，SR 和 ACK/NACK 概率上可能同时在，建议 Format 1 或 Format 0 配合 SR 专用资源，这里有个常见误区——SR 本身不占 UCI bit 数，它是靠「有没有发送」来区分的，所以 Format 0/1 完全可以承载 SR + ACK 的组合。如果 CSI 周期反馈参与进来，part 1 通常就得 Format 2 起步，而宽带的 CSI 加 HARQ-ACK 联合反馈，载荷可能到十几 bit，Format 2 在 1~2 符号内受限于码率和 PRB 个数，往往得 Format 3 才能兜住。碰到这种场景，我会直接翻 38.331 里 PUCCH-Config 下的 pucch-Format0、pucch-Format1 这些子节点，看里面配置的 maxPayloadMinus1 和 maxCodeRate，再对照资料里的参数表做一次交叉验证。

3. 五种格式的承载内容与参数对照：把协议表翻译成可配置的字段

3.1 UCI 比特长度与 DMRS 复用方式：Format 0/1 与 Format 2/3/4 的分水岭

资料里那张来自 3GPP TS 38.300 - 5.3.3 的参数对照表，是整个文档的骨架。UCI Bit Length 一栏，Format 0 和 Format 1 都是 <= 2，Format 2/3/4 都是 > 2，这个「2 bit 分水岭」直接决定了后续所有参数有没有意义。比如 initialCyclicShift 只出现在 Format 0/1 里，因为序列选择需要 CS 区分；timeDomainOCC 只出现在 Format 1 里，因为它要支持时域 OCC 复用；而 occ-Length 和 occ-Index 只出现在 Format 4，因为 Pre-DFT OCC 只在 DFT 预编码的 PUCCH 上才有意义。UCI/DMRS Multiplexing Method 这一列更直白：Format 0 是 N/A，压根没有 DMRS，靠序列本身传信息；Format 1 和 3/4 是 TDM，DMRS 和 UCI 分时发送；Format 2 是 FDM，DMRS 和 UCI 占用不同频域子载波。这个差异在配置时要注意：Format 2 在 1~2 个符号内既要放 UCI 又要放 DMRS，频域上就得交替打孔，PRB 给少了，DMRS 密度不够，信道估计直接崩。

3.2 跳频与 PRB 参数：intraSlotFrequencyHopping 和 secondHopPRB 的配置逻辑

五种格式全部支持 intraSlotFrequencyHopping，这是 5G 相对 4G 的一个明显增强。时隙内跳频的作用是获得频率分集——UCI 反馈对时延敏感，不能像 PUSCH 那样靠重传兜底，只能靠频率分集提高单次传输成功率。配置时有个细节：secondHopPRB 的取值是 RRC 配的绝对 PRB 号，跳频起始位置和第一跳的位置都在 PUCCH-Config 里显式配置。但跳频不是无代价的，Format 0 只有 1~2 个符号，跳频只发生在符号间，实际等于没有跳频，配置了也只是理论上有效；Format 1/3/4 符号数多，跳频发生在符号组之间，收益才明显。我在外场看到过一种翻车情况：把第二跳 PRB 配到了和控制信道重叠的区域，跳频增益没拿到，反而把邻区的 PUCCH 干扰抬高了。所以跳频配置要结合小区间 PUCCH 资源规划来看，不能只看单用户链路。

3.3 其他带不同参数的字段说明：maxCodeRate、nrofSlots、pi2BPSK、additionalDMRS

资料表里还有一批参数值得逐个说明。maxCodeRate 在 Format 2/3/4 里是决定编码率上限的，取 0.08 到 0.76 不等，它和 PRB 数、比特数一起决定了 Format 2 能不能在 1~2 个符号内放下 UCI——如果 UCI 比特数超过 maxCodeRate 约束下的容量，MAC 层就得丢 CSI 部分信息，这在优化里叫 CSI 截断。nrofSlots 可取 2/4/8，表示 PUCCH 跨多个时隙重复发送，本质是时间分集换覆盖，代价是反馈时延成倍增加——配置前要想清楚时延预算。pi2BPSK 只出现在 Format 1/2/3/4，用 pi/2-BPSK 调制降低 PAPR 以支持功率提升，对小区边缘用户有用。additionalDMRS 在 Format 1/2/3/4 里可配 true/false，额外 DMRS 改善高速场景下的信道估计。这些参数全部来自 RRC 侧的 PUCCH-FormatConfig，体现的是 gNB 对覆盖、容量、时延三者的权衡，没有绝对的对错，只有贴合场景的取舍。

3.4 从 38.331 看这组参数的实际配置位置

协议读到这里，建议直接打开 38.331 的 PUCCH-Config 结构对照。PUCCH-format 0/1/2/3/4 分别对应 PUCCH-format0/1/2/3/4 节点，各自有 startingSymbolIndex、nrofSymbols、附加的 intraSlotFrequencyHopping 和 secondHopPRB。PUCCH-format1 专门有时域 OCC 配置 timeDomainOCC；PUCCH-format2 有 maxPayloadMinus1 和 maxCodeRate；PUCCH-format4 有 occ-Length、occ-Index 和 maxPayloadMinus1。实际的调度资源分配还要通过 PUCCH-ResourceId 指向 PUCCH-Resource 集合，里面包含 pucch-ResourceId、起始 PRB、格式类型和格式具体配置。资料这份表相当于把 38.300 和 38.211 的参数翻译成了可以逐字段配置的清单，省掉了来回翻协议的时间。

4. PUCCH 配置实操：从小区级资源到 UE 级分配的完整路径

4.1 PUCCH 资源集与格式绑定的配置流程

在 gNB 侧配置 PUCCH，第一步是在 PUCCH-Config 里建立资源集。RRC 里 pucch-ResourceSet 可以配多个集合，每个集合绑定一组 pucch-ResourceId，并且有一个 pucch-ResourceSetId 关联到 DCI 里的 PUCCH resource indicator 字段。这里的规则是：UCI 比特数不同，走的资源集就不同——小于等于 2 bit 的 HARQ-ACK 走 Format 0/1 的资源集，大于 2 bit 的走 Format 2/3/4 的资源集。第二步是给每个 pucch-Resource 指定格式和时频位置。常见的做法是给小区配 4 个资源集：一个给 Format 0，一个给 Format 1，一个给 Format 2，一个给 Format 3/4，每个资源集里再按 UE 或 UE 组分配具体的 PRB 起始位置和符号位置。第三步是处理复用——Format 0 复用靠 CS，Format 1 复用靠 CS + OCC，Format 4 复用靠 Pre-DFT OCC，这些复用维度要在资源规划时统一分配，不然两两 UE 的 CS 或 OCC 撞一起，接收端解调就分不出来了。

4.2 典型配置参数速查表与一个实际配置片段

举一个常见的配置场景：小区边缘用户反馈 HARQ-ACK，希望提高可靠性，我一般会配 Format 1，4 个符号，nrofSlots 取 2，打开 intraSlotFrequencyHopping，第二跳放低频段，initialCyclicShift 分配一个相对空闲的 CS 索引。RRC 配置片段示意如下：

PUCCH-Config ::= { pucch-ResourceSetToAddModList { pucch-ResourceSetId 0, pucch-ResourceIdList { 0, 1, 2, 3 }, maxPayloadMinus1 1 }, pucch-ResourceToAddModList { pucch-ResourceId 0, startingPRB 10, intraSlotFrequencyHopping enabled, secondHopPRB 40, format { pucch-Format1 { startingSymbolIndex 4, nrofSymbols 4, timeDomainOCC 0, additionalDMRS false, pi2BPSK false, nrofSlots 2 } } } }

这段配置的逻辑：pucch-ResourceSetId 0 负责承载 <= 2 bit 的 HARQ-ACK，pucch-ResourceId 0 指定了一个起始 PRB 为 10、第二跳 PRB 为 40 的 Format 1 资源，从符号 4 开始占 4 个符号，时域 OCC 取 0，重复 2 个时隙。注意 secondHopPRB 是绝对 PRB，规划时要避开 PUCCH 资源集间的重叠，nrofSlots 2 意味着时延翻倍，对时延敏感的业务要谨慎开启。这里还缺了一个关键项——每个 UE 通过 RRC 的 PUCCH-Config 下发时，会绑定一个 pucch-ResourceId，这个绑定关系在调度侧由 DCI 里的 PUCCH resource indicator 字段动态选择，所以同一个 UE 可以有多个候选资源，用于负载均衡和干扰规避。

4.3 配置后信令验证：从 RRC Setup 到 SR 与 CSI 的上行反馈

配置完成后，验证链路是否打通，我习惯分三步。第一步看 RRC 重配置是否完成，UE 是否返回 RRC Reconfiguration Complete，如果这条消息迟迟不来，大概率是 PUCCH 资源配置非法——比如 startingSymbolIndex + nrofSymbols 超过 14 个符号的时隙边界，或者 secondHopPRB 越界。第二步看 HARQ-ACK 反馈是否正常，通过 gNB 侧统计 PUCCH 上的 ACK/NACK 接收情况，如果大量 DTX（不连续传输）出现，说明 UE 根本没找到 PUCCH 资源，这时要看 PUCCH resource indicator 对应的资源集是不是和 RRC 配的一致。第三步看 CSI 反馈是否周期性到达，周期性 CSI 走 PUCCH，如果 CSI 丢失率偏高，优先怀疑 Format 2/3/4 的 maxPayloadMinus1 配小了，UCI 被截断。

5. PUCCH 配置避坑指南：格式误配、复用碰撞与功率受限的排障记录

5.1 现象：PUCCH Format 0 复用后 ACK 大量误判

外场遇到过一种情况：4 个 UE 共用同一 PRB 的 Format 0 资源，都靠 initialCyclicShift 区分，结果 ACK 误判率飙到 30%。排查后发现，4 个 UE 的 CS 分别是 0、3、6、9，间隔看着均匀，但其中两个 UE 处于小区边缘，频偏较大，序列的相关性被破坏了，接收端把 CS 6 的 UE 误判成 CS 3。原因是 Format 0 的序列选择本质上是非相干检测，CS 间隔在频偏面前不够大，边缘用户的频偏把序列间的正交性吃掉了。解决方法是给边缘用户改用 Format 1 或 Format 2，用 DMRS 做信道估计后再解调，或者把边缘用户的 PUCCH 资源单独规划到不同的 PRB，不做 CS 复用。

5.2 现象：PUCCH Format 2 配了 1 个 PRB，CSI 反馈永远不完整

另一个案例是 Format 2 只配了 1 个 PRB，UE 反馈的 CSI part 1 截断严重，gNB 拿到的宽带 CQI 和 RI 经常缺失。原因是 Format 2 在 1~2 个符号内既要放 DMRS 又要放 UCI，1 个 PRB 能承载的 UCI bit 数有限，加上最大码率限制，UCI 载荷超过容量后被 MAC 层截断。解决的思路有两个：一是把 nrofPRBs 从 1 提到 2 或 4，容量立马上来；二是查看 maxPayloadMinus1 的实际配置，如果配的是 0 而实际 CSI 载荷需要 5 bit 以上，就得调高这个字段，或者把 CSI 改成部分上报，砍掉一些非关键字段。从那以后，我每次配 Format 2 都先按「目标比特数 / maxCodeRate / PRB 数」反推一次容量，确认有余量才下发。

5.3 现象：Format 4 的 OCC 复用导致 DMRS 估计恶化

Format 4 支持最多 4 个 UE 在同一 PRB 复用，靠 Pre-DFT OCC 区分，但 OCC 的有效性依赖 DMRS 的信道估计质量。遇到过一个案例：两个 UE 用 occ-Length 4、occ-Index 0 和 1，DMRS 都用额外的 additionalDMRS，结果一个 UE 的 BLER 明显偏高。原因是对端信道在时域上变化太快，OCC 的正交性被时间选择性破坏，尤其是高速移动场景，Pre-DFT OCC 的解扩增益会明显下降。解决方法是高速场景避免 Format 4 复用，直接给每个 UE 独立 PRB，或者降低 occ-Length 到 2 以减少时域跨度，牺牲复用容量换解调稳健性。

5.4 现象：nrofSlots 配成 8 后 HARQ 时延超标，下行重传率不降反升

小区边缘覆盖差，想着用 nrofSlots 8 的重复传输兜底 ACK/NACK，结果下行 TCP 吞吐掉了 20%。原因是重复传输把 HARQ RTT 从 8 个时隙拉长到 16 个甚至更长，TCP 发送窗口因为 ACK 迟迟不来而收缩，吞吐率反而下降。解决方法是区分场景：时延敏感业务用 Format 0 快速反馈，覆盖不足靠功控和频率分集解决；只有真正的深度覆盖场景，比如地下车库、远点用户，才值得用 nrofSlots 2 起步去试探，而不是直接上 8。另外要注意，nrofSlots 重复传输时跨时隙跳频要同步打开，否则重复传输只是时间分集，频率分集没吃到。

6. 用 38.211 参数表反推 UCI 资源规划：一个验证配置冲突的实用技巧

拿到资料里那张五种格式的参数对照表，除了照着配，还可以反过来用——当网络指标异常时,用它来反推 PUCCH 配置里哪里出了问题。我常用的技巧是画一张「格式 - 符号数 - 比特数 - 复用能力」的四象限图，把现场每个小区的 PUCCH 配置点进去，看有没有落在互相矛盾的象限里。比如某小区配了 Format 2 但 nrofSymbols 给了 4，这本身就是矛盾的，因为 38.211 定义 Format 2 的符号数只能是 1~2；再比如 Format 0 配了 additionalDMRS true，这个字段根本不存在于 Format 0 的参数集里，UE 侧收到这种配置会直接判定为协议错误，RRC 重配置都起不来。

另一种用法是做小区间的 PUCCH 干扰排查。PUCCH 资源不像 PUSCH 那样有调度器动态避让，它的时频位置是 RRC 半静态配下去的，干扰是长期的。要是某个小区上行干扰底噪抬升，先别急着查 PUSCH，翻一下邻区的 PUCCH 第二跳 PRB 是否和本小区 PUCCH 起始 PRB 重叠。因为 secondHopPRB 是绝对 PRB，跨小区规划时很容易撞车。我处理过一个真实案例：两个相邻小区，A 小区的 PUCCH Format 1 第二跳配在 PRB 20，B 小区的 PUCCH Format 2 起始 PRB 也配在 PRB 20，B 小区干扰抬升 6 dB，UE 反馈的 CQI 从 13 掉到 8。查出来后把 B 小区的 Format 2 起始 PRB 挪到 PRB 30，干扰立刻回落。这就是那张参数表在规划层面的价值——它不会替你选配置，但它把每个格式允许的参数空间标得清清楚楚，超出边界的配置错误，都能通过表格反查定位到具体字段。从那以后，我每做一次 PUCCH 资源规划，都强制走一遍「格式选型 → 参数空间校验 → PRB 碰撞检查」这三步，从源头上把配置冲突挡在开局之前。这套方法配合资料里的 38.211 参数表来用，基本能覆盖现网 90% 以上的 PUCCH 配置问题，希望帮到你。

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