简介一份面向5G网络优化工程师、基站研发与网络规划人员的专业文档聚焦5G(NR)中上行控制信息(UCI)的承载内容与比特结构帮助读者系统掌握UCI在物理层协议中的组织方式。文档以3GPP TS38.212第6.3章节为依据完整梳理HARQ ACK/NACK、调度请求(SR)与信道状态信息(CSI)三类核心控制信息的定义作用、上报场景以及HARQ ACK/NACK only、HARQ ACK/NACKSR、CSI only、HARQ ACK/NACKCSI、HARQ ACK/NACKSRCSI五种组合承载方式。同时详解了不同传输场景下UCI的比特分配逻辑包括CBG配置前后HARQ反馈比特数的变化、TDD网络的特殊处理以及PMI、RI、CQI、CRI、SSBRI等CSI反馈类型的结构差异。资源为单个docx文档压缩包大小约15KB内容精炼且条理清晰既适合5G网络优化初学者建立UCI整体认知也可作为工程排障与协议分析时的速查手册。目前已有335人学习下载对于深入理解上行控制信令、优化网络吞吐与时延表现具有直接参考价值。1. 5G(NR)里的UCI不是“参数”而是“信号”先搞清它在协议栈里干什么当你翻看5G基站日志看到“PUCCH解码失败”或者“UCI承载异常”时第一反应是先搞清楚UCI是什么。NR里的UCI全称是Uplink Control Information指终端通过PUCCH或PUSCH回传的上行控制信令比特里面装着HARQ-ACK、调度请求SR和信道状态CSI三类内容。它不参与用户面数据传输却直接决定下行调度闭环、误块率和波束管理方向能不能转起来。如果你是从Kaggle那个UCI二分类数据集转到这个话题的先把头脑里的“UCI数据集”清空这里的UCI是一段物理层信号不是一份数据表。这篇文章就围绕“UCI里到底装了什么比特、在PUCCH和PUSCH上按什么结构摆放”展开适合做5G协议栈、射频测试和OAI/srsRAN仿真的人顺着步骤落地一套UCI承载方案。2. UCI承载哪些内容从HARQ-ACK到CSI Part1/Part2的完整清单2.1 三类UCI信息定义、触发条件与典型比特量HARQ-ACK是对PDSCH传输块的确认或否认反馈由DCI调度的PDSCH触发反馈时序由k1参数决定。一个传输块对应1比特如果配置了CBGcode block group传输一个传输块可以对应4比特或8比特的反馈。码本类型分半静态Type1和动态Type2两种Type1按候选PDSCH时机集合生成固定长度的反馈窗Type2依赖DCI里的下行分配指示DAI来动态决定实际反馈比特有哪些。外场测试中最常见的问题是基站按自己的调度预期去解ACK/NACK终端却按DAI得到了不同长度的反馈窗两边对不上UCI比特序全部错位。SR是调度请求用来告诉基站“我上行缓存里有数据需要调度”。SR资源由RRC独立配置本质上就1比特positive SR表示有数据请求negative SR表示不请求。触发条件是终端有可用的上行数据同时当前没有可用的UL grant。SR的周期从1个符号到80ms不等周期越短调度时延越低代价是PUCCH资源被占用的密度越高。这个参数在时延敏感业务里容易被调错。CSI是信道状态信息在NR里被拆成Part1和Part2两部分。Part1固定占用一段预设比特数包含RI、CQI和宽带PMIPart2包含子带PMI和子带CQI比特数随带宽配置变化而浮动。拆成两部分的原因很直接Part1小且重要必须在解码UCI时优先保住Part2大且相对次要资源不足时可以丢弃。CSI上报由一个ReportConfig触发分周期、半持续和非周期三种分别走不同的物理层流程和处理优先级。2.2 承载选择逻辑PUCCH和PUSCH怎么分工先明确一个边界UCI本身不是物理信道它是一组比特。承载它的物理资源有两种独立PUCCH传输或者复用进PUSCH一起传输。二者在NR里同时存在终端根据“当前有没有PUSCH要发”以及“UCI类型是什么”来选承载路径。如果终端当前没有PUSCH发送就用PUCCH独立承载。如果终端当前恰好有PUSCH要发HARQ-ACK和CSI会优先考虑复用进PUSCH这样省掉一个PUCCH资源也避免PUCCH和PUSCH同时发射导致功率压缩。但复用有一个前提PUSCH的资源要足够容纳UCI比特并且调度器要通过DCI或RRC配置把BetaOffset等复用参数正确传给终端。还有一种常见做法是用PRIPUCCH resource indicator从PUCCH资源集里选一个资源同时PUSCH复用作为备选两者由MAC调度器统一决策。记住UCI承载优先级高于用户面数据。2.3 优先级与丢弃规则NR默认行为里的两个固定顺序NR里UCI的优先级顺序是HARQ-ACK以及紧急SR最高一般SR次之然后是CSI Part1最后是CSI Part2。这个顺序体现在两个场景。第一个场景是同一时隙PUCCH和PUSCH冲突时优先保证承载最高优先级UCI的信道正常发射另一路做功率压缩或时域延后。第二个场景是UCI复用进PUSCH后资源不足时丢弃顺序为先丢CSI Part2再丢CSI Part1HARQ-ACK无论如何保留。这个顺序在TS 38.212和38.213的速率匹配规则里有明确推导不需要开发者自行决策。反过来说如果预留的UCI资源已经固定而业务数据量变大PUSCH速率匹配会自动压缩数据为UCI腾出位置。有一种常见的实现错误是把UCI当“附加项”先放数据再塞UCI结果UCI覆盖了数据RE。NR是先给UCI算好资源区域数据在剩余RE里做速率匹配。这句话记牢后面调试能省一半时间。3. PUCCH的5种格式与UCI结构Format 0到Format 4怎么选3.1 短PUCCH和长PUCCH先选长度类再选格式PUCCH在时域上先分两类。短PUCCH占1到2个OFDM符号适合低时延场景和URLLC业务占资源少但覆盖能力弱。长PUCCH占4到14个OFDM符号适合覆盖受限场景因为符号多时间分集和功率累积效果更好。5种格式的归属很清晰Format 0和Format 2是短PUCCHFormat 1、Format 3和Format 4是长PUCCH。格式选择不是终端自己决定的。基站通过RRC配置PUCCH资源集每个资源集里包含多个资源每个资源配置了PUCCH格式和起始PRB偏移。终端从DCI里拿到PRI之后在资源集里选对应配置项。如果你在资源集里把格式类型配错让一个需要长格式的UCI落在短格式资源上终端不会自己纠正结果是完全打不出来或者基站解码全乱。做NR物理层配置时先按符号数长短分大类再细看具体格式这个顺序不能跳。3.2 Format 0和Format 11到2比特的序列承载与多用户复用Format 0是一个很省资源的设计。它不用DMRS也不做传统调制而是直接在ZC序列上选一个循环移位来表示UCI比特。具体是1到2比特信息在12个循环移位中挑选组合基站做相关检测就能解出UCI。它占用一个PRB、1到2个符号是NR里开销最小的UCI承载方式。缺点同样明显只能承载1到2比特所以只在单个HARQ-ACK反馈且没有CSI时适用。Format 1虽然频域也是1个PRB但时域扩展到4到14个符号。UCI经过BPSK或QPSK调制后乘一个正交覆盖码OCC扩频到整段符号上。多用户复用能力来自时域OCC不同终端的UCI在同一个PRB上彼此正交可复用的用户数取决于OCC长度和符号数。Format 1的DMRS位置由配置决定通常放在长PUCCH的第一个符号。覆盖比Format 0好但前提仍然是UCI不超过2比特。做小区边缘覆盖优化时它能拉远覆盖代价是占用更多时域符号可能挤占同一时隙内的数据调度空间。3.3 Format 2/3/4超过2比特的三种路径Format 2是短PUCCH承载大比特UCI的方案。它用QPSK调制DMRS和UCI在频域交错放置本质是频分复用。支持扩展到多个PRB理论上能承载几百比特的UCI。周期性CSI上报大部分场景都走Format 2因为短符号不占PUSCH时隙调度灵活。做URLLC和eMBB混跑时短PUCCH的Format 2往往是默认选择。Format 3是长PUCCH里支持多PRB的方案调制还是QPSK但加了一级DFT扩展即DFT-S-OFDM好处是峰均比低终端功放效率高。它适合覆盖受限但UCI比特多的场景。Format 4则把频域限制死只能占1个PRB通过OCC在时域做扩频复用最多4个终端。它适合小区边缘需要长格式又不想让单个UE独占太多资源的场景。这三者之间的选择大方向看时域预算时隙里有空位就用长格式提升覆盖时隙很紧优先用Format 2把UCI快速发完。再结合复用需求需要多用户复用用Format 4需要多PRB聚合用Format 3。注意Format 2的频域交织结构跟数据不同UCI和DMRS按RE级交替放置做资源配置时不要试图修改它的内部顺序只要告诉基站起始PRB和PRB数量即可。3.4 依据UCI总比特数选择格式一张决策表UCI承载内容及结构的最直观落点就是这张格式选择表UCI总比特数建议格式时域长度频域占用典型用途1-2比特Format 0 或 Format 11-2符号 / 4-14符号1 PRB单HARQ-ACK、SR或小组合反馈大于2比特Format 21-2符号1-N PRB周期CSI、多TB反馈、URLLC快速上报大于2比特Format 34-14符号1-N PRB覆盖受限下的大UCI上报大于2比特Format 44-14符号1 PRB多用户复用的大UCI上报这里有个容易踩的边界UCI总比特数必须把HARQ-ACK比特、SR比特、CSI Part1和CSI Part2全部加起来判断。很多翻车现场的根因是只算了CSI的比特数忽略了HARQ-ACK码本从2比特扩到8比特比如配置了CBG反馈之后总比特数已经超过2但基站侧还按Format 1配置了PUCCH资源。实际编码时超过2比特的UCI走的是Polar或RM编码而Format 0和Format 1的序列选择通道根本不支持这种编码方式。所以做资源集配置前先算出真实总比特数再对照这张表。4. UCI搭上PUSCH这趟车复用映射、BetaOffset与打孔细节4.1 为什么NR要把UCI放进PUSCH省资源也省时隙冲突概率PUCCH和PUSCH如果同时存在于一个时隙终端要么需要同时发射两个信道要么就得错开。在小区边缘终端功率受限同时发射两个信道会导致功率压缩甚至两个信道都不达标。把UCI复用进PUSCH可以从根上减少一个信道的功率开销只保留一个发射链路。同时省掉单独的PUCCH资源后调度器可以把更多PRB留给数据。对于同时有业务要发、又有ACK和CSI要回的终端这是最经济的选择。这个方案的代价是PUSCH上的数据速率会下降。UCI占掉一部分RE之后数据要做速率匹配避开这些位置等效于PUSCH的有效码率变高。如果传输块大小不变可能因为码率超过门限而失败。调度器在做MCS选择时通常会留出一部分余量给UCI开销但这个余量不是自动生效的需要在调度器代码里显式预留否则大数据包场景很容易触发传输块CRC失败。4.2 UCI在PUSCH上的摆放顺序从DMRS开始低频优先映射映射规则不是随意定的。HARQ-ACK优先放置在PUSCH第一个DMRS之后的可用符号里从低频到高频逐个RE填充。CSI Part1排在HARQ-ACK之后CSI Part2排在Part1之后。这样安排的考虑是HARQ-ACK离DMRS最近信道估计最准确解码成功率最高。NR里还有一个细节HARQ-ACK可以跨越多个PUSCH符号而CSI根据剩余空间逐个映射并不要求整块对齐。映射方式跟PUSCH波形有关。DFT-S-OFDM波形下UCI和数据在同一个DFT块内通过打孔的方式把数据RE切掉CP-OFDM波形下UCI直接替换数据RE等效为打孔。不要试图在高层配置里密集指定UCI区域因为速率匹配逻辑是按虚拟资源块计算的如果你手动指定太多UCI区域调度的传输块大小会失真最终表现为PUSCH吞吐和配置预期不一致。4.3 BetaOffset参数直接影响UCI占用资源的工程化开关BetaOffset是一个比例因子由RRC参数UCI-OnPUSCH里的betaOffsetACK-Ind1、betaOffsetACK-Ind2、betaOffsetCSI-P1和betaOffsetCSI-P2提供也可以由DCI里的上行链路指示字段动态更新。它的作用是为UCI计算目标资源时把UCI比特数乘上一个配置的缩放因子结合调制阶数和偏移量折算成占用的RE数。因子取大UCI占用更多RE解码可靠性更高数据被压缩更多因子取小UCI资源变少数据吞吐提升但ACK或CSI解码余量变小。常见的做法是给HARQ-ACK的BetaOffset取大给CSI Part2取小。原因还是优先级ACK出错直接触发重传CSI出错最多导致一次调度不精准。我一般会先按信道质量分档覆盖差的UE把betaOffsetACK提高1到2档覆盖好的UE按默认值。不要所有UE用同一套BetaOffset这是外场优化最值得花时间的地方。还有一个容易踩的细节当PUSCH无法容纳全部UCI时终端会自动丢弃CSI Part2再丢CSI Part1但HARQ-ACK永远不会丢。如果基站解调器和终端实现的丢弃逻辑没对齐终端这边解出的数据位置和基站那边预期的UCI分布不一致PUSCH整体解码必然失败。所以配置检查时不光看BetaOffset数值还要确认基站调度器是否把丢弃优先级逻辑做进了速率匹配模块。5. UCI承载的避坑记录从设置、翻车到恢复的5条血泪经验5.1 现象PUCCH解调失败RSRP很强但误块率一直高外场测试时终端RSRP在-85dBm左右信号很好但基站侧PUCCH解码误块率始终降不下来。先别怀疑硬件先查功率控制参数。PUCCH发射功率由P0_NOMINAL_PUCCH和P0_UE_PUCCH配合给出前者是小区级基准后者是UE级偏移。如果P0_NOMINAL_PUCCH设得比链路预算目标低很多基站收到的PUCCH信号长期不足误块率就必然高。解决方法是先关掉闭环功控用开环固定功率把PUCCH抬高5到10dB确认解码恢复正常后再逐步配回闭环参数。这一步能快速把问题锁定在功控还是UCI结构本身。另外注意PUCCH-PathlossReferenceRS不能指向错误的下行参考信号路径损耗算错是PUCCH功控玄学问题的常见源头。5.2 现象HARQ-ACK和SR同时上报时基站解出的比特序全乱终端在一个时隙既需要反馈HARQ-ACK又需要发送positive SR两边都用PUCCH时规则是复用而不是分开发射。复用规则里有一个关键分支当HARQ-ACK比特数不大于2时把SR状态合并到HARQ-ACK消息里通过联合状态表达当HARQ-ACK大于2比特时把SR比特追加在HARQ-ACK比特序列末尾。很多实现把SR当作独立的1比特直接追加没有理会“不超过2比特时需要联合编码”的规则结果基站按另一种顺序解码比特序全错。解决方法是严格按TS 38.213的复用表生成联合编码状态并且在外场测试里专门构造“ACK加SR同发”的用例不要只在实验室里做单一UCI类型验证。5.3 现象PUSCH上的UCI打孔后整个传输块CRC校验失败配置了UCI on PUSCH之后PUSCH的传输块CRC总是失败即使同样的MCS等级在无UCI时没问题。这个现象往往不是UCI解码失败而是数据侧的速率匹配没有把UCI资源避开。一种错误实现是先做数据速率匹配再放UCI结果有两个问题一是UCI覆盖了已经映射的数据RE二是数据和UCI共用DMRS的相对偏移错乱。正确顺序是先按BetaOffset算出UCI占用的RE数和位置把UCI写入后再对数据做速率匹配。如果调度器对PUSCH的码率限制比较严格还要考虑给UCI留余量。常见解决方案是在链路级仿真里对比有UCI复用和无UCI复用两个场景的BLER曲线把MCS回退1到2档或者增加PRB数让数据码率回到余量内。不要只调BetaOffset那样往往牺牲的是UCI可靠性。5.4 现象CSI Part2被丢弃后波束管理上报的PMI连续缺失NR里CSI Part2包含了子带PMI是波束相关的重要信息。当UCI总资源不足时协议规定丢弃CSI Part2优先于CSI Part1。如果配置的PUSCH资源很小而CSI Part1又很大CSI Part2很可能被完全丢弃终端上报的RI和CQI显示信道很好但波束方向长期不更新。外场表现为下行吞吐忽高忽低但CQI普遍很高。解决路径不是违反丢弃顺序而是增大承载空间把PUSCH的PRB数量或符号数提升或者把周期CSI的周期调长减少单次上报的比特量。调试时要同时观察CSI Part1和CSI Part2两个字段是否都到达基站协议栈日志里通常会有CSI Part2缺失的告警不要忽略。5.5 现象UCI超过2比特却配置了Format 1的资源RRC配置错误是另一个翻车点。终端上报的UCI比特总数因为CBG反馈或CSI叠加变大之后如果PUCCH资源集仍配置Format 1终端要么拒绝发射要么按错位的方式编码基站解码时会出现“CRC通过但内容不合理”的情况。检查手段很简单在终端侧打开物理层日志查看实际生成的UCI比特数和用来发射的PUCCH格式是否匹配不匹配就按第3章的决策表修正PUCCH资源集。这里有个善后经验每次改PUCCH资源集配置后建议跑一组固定比特数的UCI测试向量确认终端在Format 0/1/2/3/4的每一种资源上都能正常解调再进外场省得后续问题说不清。6. 平时怎么验证UCI承载配置从决策脚本到链路仿真的落地6.1 用一个小脚本把UCI比特数到承载格式的映射固化下来我现在的习惯是在任何5G协议栈或测试平台里改PUCCH配置前先跑一个判断逻辑避免人工估算UCI总比特数翻车。下面是一个纯逻辑的参考脚本片段def choose_pucch_format(harq_ack_bits, sr_bits, csi_part1_bits, csi_part2_bits): total_uci_bits harq_ack_bits sr_bits csi_part1_bits csi_part2_bits if total_uci_bits 2: return Format0/Format1 # 超过2比特后短时域优先用Format2长时域用Format3/4 if total_uci_bits 256: return Format2 # 需要基站配置对应PRB数量 return Format3 # 更大的UCI建议走多PRB长格式 # 示例8比特HARQ-ACK 1比特SR 16比特CSI Part1 32比特CSI Part2 print(choose_pucch_format(8, 1, 16, 32)) # 输出Format2或Format3这个脚本把“总比特数决定格式”的约束固化成代码而不是靠人肉记忆。2比特是Format0/1和应用格式之间的分界256比特附近是Format2在短符号下的实际承载上限超过就转Format3或减少CSI Part2比特。关键是脚本里的阈值要和当前版本的3GPP协议对齐协议版本更新后要回查。6.2 UCI链路级验证的仿真参数与验收标准我一般用一条链路仿真做验收带宽20MHz、子载波间隔30kHz、PUCCH Format2、2个符号、2个PRB发射UCI比特数设为16比特信道用TDL-C延迟扩展300ns。验收标准是解调后的BLER曲线在SNR等于5dB时低于1%同时HARQ-ACK错误率低于0.1%。如果达不到优先调整BetaOffset而不是加PRB因为加PRB会挤占数据资源而BetaOffset只影响UCI的信噪比余量。如果涉及PUSCH复用UCI就再跑一版PUSCH采用QPSK、码率0.5UCI复用后数据BLER比无UCI场景的差不超过1dB。差值超过1dB就要回头查速率匹配是否避开了UCI资源。这套验证方法花半天时间能从根上避免外场返工。我现在的习惯是先把这种仿真脚本固化到测试流程里每次改完UCI相关配置都跑一遍等外场再出问题时至少能排除物理层结构这部分。希望帮到你。本文还有配套的精品资源点击获取