简介这份文档面向5G网络优化与无线通信协议学习人员系统梳理NR网络中上行控制信息UCI的承载内容与比特结构帮助读者理解PUCCH与PUSCH在不同场景下如何承载UCI并掌握其对网络性能优化的实际影响。资源包为单一docx文档压缩包约15KB内容聚焦协议要点便于快速查阅与对照学习。文档围绕ACK/NACK、调度请求SR与信道状态信息CSI三类基本内容展开说明五种组合承载方式并结合TS38.212-6.3章节介绍HARQ反馈在CBG配置前后的比特差异、SR的1bit结构以及CSI依赖类型变化的复杂结构同时提及TDD网络配置的特殊性。已有335人学习适合需要深入理解UCI机制、提升资源调度与传输策略分析能力的优化人员参考。1. 5G(NR)上行控制信息UCI从PUCCH到PUSCH的承载逻辑做5G网络优化的人日常路测和信令跟踪里绕不开的一个词就是UCI。它不像DCI那样只走PDCCH一条路UCI的承载信道会根据场景动态切换——有时走PUCCH有时复用到PUSCH上跟用户数据一起发。这个切换逻辑如果搞不清楚看log的时候就会一头雾水明明终端有上行数据在传为什么PUCCH上的SR一直没发出来答案往往就藏在UCI的复用规则里。UCI承载三种基本内容HARQ ACK/NACK、SR、CSI。这三种内容不是每次全发而是根据调度状态和信道条件组合上报形成五种典型组合。理解这些组合的触发条件是排查上行覆盖、调度延迟、MCS选阶异常等问题的基本功。这份文档把UCI的承载内容和比特结构拆得很细尤其适合需要对着TS38.212做参数核对、或者要写解析脚本的优化工程师。下面从承载信道选择讲起再逐层拆到比特结构最后落到实际排查中怎么用。2. UCI承载信道选择与五种组合的触发条件2.1 PUCCH与PUSCH的承载分工UCI默认由PUCCH承载这是终端在没有上行数据发送时的专用控制信道。PUCCH的格式Format 0到Format 4决定了它能承载多少UCI比特、占用多少符号。但实际网络中终端经常同时有上行数据和UCI要发这时候如果还走PUCCH就会造成额外的资源开销和发射功率浪费。所以协议设计了一个复用机制当终端有PUSCH传输时UCI可以复用到PUSCH上跟上行共享信道的数据一起编码发送。这个复用不是随意的。触发条件取决于UCI的类型和PUSCH的调度参数。常见做法是如果终端在当前时隙有PUSCH调度且UCI比特数不超过PUSCH能承载的上限就优先复用。如果UCI比特数太大比如CSI报告配置了很多子带或者PUSCH的MCS太高导致没有足够资源放UCI那就还是走PUCCH。这个判断逻辑在TS38.213的9.2.5节有详细定义但实际优化中更值得关注的是复用后的功率分配和编码速率变化。注意复用场景下PUSCH的MCS可能会因为要容纳UCI而被迫降阶这是上行吞吐量掉坑的一个常见原因。2.2 五种UCI组合的触发场景UCI的五种组合不是随机出现的每种对应不同的调度状态和配置。下面这张表把触发条件和典型场景列清楚组合触发条件典型场景HARQ ACK/NACK only终端收到下行数据没有SR待发CSI报告未到周期下行连续调度上行无新数据HARQ ACK/NACK SR下行有数据反馈同时终端有上行数据待发但无资源上行缓冲区有数据等待调度CSI onlyCSI周期上报时刻到无下行数据反馈无SR周期性CSI测量上报HARQ ACK/NACK CSI下行数据反馈与CSI周期上报碰撞下行调度密集且CSI周期较短HARQ ACK/NACK SR CSI三者同时触发高负载场景上行待发下行反馈CSI上报实际优化中第三种和第五种组合最容易出问题。CSI only场景下如果PUCCH格式配置不当CSI比特数超过PUCCH容量终端会直接丢弃CSI导致基站侧信道状态信息过期调度器选阶偏保守吞吐量上不去。第五种组合则是比特数最多的情况编码和资源分配稍微不合理就会导致UCI解码失败表现为上行ACK漏检、SR丢失。2.3 复用判断的实操检查点在网优工具里看UCI复用是否正常我一般会盯这几个点第一看PUSCH调度时刻和UCI触发时刻是否对齐。如果终端有PUSCH但UCI还是走了PUCCH说明复用条件不满足可能是UCI比特数超限或者PUSCH资源不够。第二看复用后的PUSCH MCS是否被压低。如果发现某个终端在复用时刻MCS突然掉2到3阶基本可以确认是UCI挤占了数据资源。第三看PUCCH和PUSCH的功率配置。复用场景下终端会把UCI的功率需求叠加到PUSCH上如果功率控制参数没调好会导致PUSCH发射功率过高增加干扰。# 示例从信令log中提取UCI复用相关字段以常见解析工具为例 # 过滤PUSCH调度DCI检查UCI复用标志 grep DCI format 0_1 nr_log.txt | grep -E UCI|CSI request | \ awk {print $1, $2, $NF} uci_mux_check.txt # 统计复用时刻的MCS分布对比非复用时刻 grep PUSCH nr_log.txt | grep UCI multiplex | \ awk -FMCS {print $2} | cut -d -f1 | sort -n | uniq -c上面这段脚本的思路是从log里把UCI复用时刻的MCS值抽出来跟非复用时刻做对比。如果复用时刻的MCS明显偏低说明UCI挤占资源的情况比较严重需要检查CSI报告配置是否过于激进或者SR周期是否太短导致频繁触发复用。3. UCI比特结构从HARQ ACK/NACK到CSI的逐层拆解3.1 HARQ ACK/NACK的比特数计算HARQ ACK/NACK的比特结构看起来简单但CBG配置一开复杂度直接翻倍。没有CBG时每个载波的每个码字只需要1bit一个载波两个码字就是2bit。开了CBG之后每个码字内的每个CBG都需要1bit反馈比特数等于CBG数量乘以码字数。TDD网络更麻烦。TDD上下行配比导致下行子帧可能连续多个终端需要在某个上行子帧里反馈多个下行子帧的HARQ结果这就是所谓的HARQ捆绑或复用。捆绑是把多个子帧的ACK/NACK做逻辑与压缩成1bit复用则是按顺序排列每个子帧占1bit。协议里用DAIDownlink Assignment Index来指示实际调度的下行子帧数终端根据DAI值确定反馈比特数。# HARQ ACK/NACK比特数计算示例 def harq_bits(num_carriers, num_codewords, cbg_configNone, tdd_bundleFalse): num_carriers: 载波数 num_codewords: 每载波码字数通常1或2 cbg_config: 每码字的CBG数量None表示未配置CBG tdd_bundle: 是否TDD捆绑模式 if cbg_config is None: bits_per_carrier num_codewords # 每码字1bit else: bits_per_carrier num_codewords * cbg_config # 每CBG 1bit total_bits num_carriers * bits_per_carrier if tdd_bundle: # TDD捆绑模式下多个下行子帧压缩为1bit total_bits num_carriers * num_codewords return total_bits # 示例2载波每载波2码字CBG4非捆绑 print(harq_bits(2, 2, cbg_config4)) # 输出 16 # 示例1载波2码字TDD捆绑 print(harq_bits(1, 2, tdd_bundleTrue)) # 输出 2这个计算逻辑在写解析工具时很实用。参数cbg_config直接对应RRC配置里的maxCodeBlockGroupsPerTransportBlocktdd_bundle对应PUCCH-Config里的harq-ACK-SpatialBundlingPUCCH。实际优化中如果发现HARQ反馈比特数异常大先查CBG配置是不是被打开了再查TDD配比是不是导致反馈窗口过长。3.2 SR的1bit结构与调度请求时机SR的结构最简单就是1bit。终端有上行数据要发但没有PUCCH资源时就在配置的SR资源上发送这个1bit的正向请求。基站收到SR后在下一个调度时刻分配上行grant。SR的配置参数包括周期和偏移这两个值决定了终端多久能发一次SR。周期太短SR资源开销大PUCCH容量紧张周期太长终端上行数据等待延迟增加。常见做法是根据业务类型配eMBB业务配20ms到40msURLLC业务配5ms到10ms。注意SR周期和CSI周期如果配成相同值且偏移也相同会导致两者频繁碰撞触发第三种或第五种组合增加UCI比特数。3.3 CSI比特结构的类型依赖CSI是UCI里最复杂的部分比特数完全取决于CSI报告配置。协议里定义了多种CSI类型CRI/SSBRI/RSRP用于波束管理CRI指示选中的CSI-RS资源SSBRI指示选中的SSBRSRP是测量值RI/LI/CQI用于链路自适应RI指示rankLI指示层指示CQI指示信道质量PMI用于预编码比特数取决于码本配置每种类型的比特数在TS38.212的6.3.2节有详细表格。实际优化中CSI比特数过大是PUCCH容量不足的主要原因。比如配置了type II码本PMI比特数可能达到几十甚至上百比特PUCCH Format 2根本放不下只能走PUSCH或者丢弃部分CSI。# CSI比特数估算示例简化版实际需查表 def csi_bits(csi_type, config): csi_type: CRI_RSRP, RI_CQI, PMI config: 配置参数字典 if csi_type CRI_RSRP: # CRI: log2(CSI-RS资源数), RSRP: 7bit per resource cri_bits (config[num_csi_rs] - 1).bit_length() rsrp_bits 7 * config[num_csi_rs] return cri_bits rsrp_bits elif csi_type RI_CQI: # RI: 1-3bit取决于最大层数, CQI: 4bit per codeword ri_bits (config[max_rank] - 1).bit_length() cqi_bits 4 * config[num_codewords] return ri_bits cqi_bits elif csi_type PMI: # PMI比特数取决于码本类型和配置需查TS38.212表6.3.2.1.2-1 # 这里用简化估算 return config.get(pmi_bits, 0) return 0 # 示例4个CSI-RS资源的CRI/RSRP报告 print(csi_bits(CRI_RSRP, {num_csi_rs: 4})) # 输出 2 28 30这个估算函数在配置核查时很有用。如果算出来CSI比特数超过PUCCH格式容量就需要调整配置要么减少CSI-RS资源数要么改用type I码本要么把CSI报告触发方式改成非周期走PUSCH承载。4. UCI解析与优化中的避坑排查4.1 坑一PUCCH Format选错导致CSI丢弃现象基站侧收到的CSI报告不完整或者CSI更新周期明显变长调度器选阶偏保守下行吞吐量低于预期。原因PUCCH Format 2的容量上限是特定比特数如果CSI报告配置的比特数超过这个上限终端会按照优先级丢弃部分CSI。常见的是丢弃宽带CQI只留子带CQI或者直接丢弃整个CSI报告。解决先算CSI比特数再对照PUCCH Format容量表。如果超限调整CSI报告配置减少子带数、降低CQI精度、或者把CSI触发方式改为非周期。也可以换用容量更大的PUCCH Format 3或Format 4但要注意这两个格式占用更多符号可能影响上行覆盖。4.2 坑二SR周期与CSI周期碰撞导致UCI比特数激增现象某些时刻UCI解码失败率升高上行ACK漏检增加SR响应延迟变大。原因SR周期和CSI周期配成相同值且偏移对齐时两者会在同一时刻触发加上HARQ反馈形成第五种组合。UCI比特数达到最大编码速率被迫提高解码性能下降。解决错开SR和CSI的周期偏移。比如SR周期20ms偏移0CSI周期20ms偏移5这样两者不会在同一时隙碰撞。如果业务允许也可以把CSI周期改成非周期触发减少周期性碰撞。4.3 坑三CBG配置打开后HARQ反馈比特数暴增现象上行控制信道资源占用率突然升高PUCCH容量紧张部分终端的HARQ反馈出现漏检。原因CBG配置打开后每个CBG都需要1bit反馈比特数等于CBG数乘以码字数。如果CBG数配了4两个码字就是8bit比原来的2bit翻了4倍。解决评估CBG配置的实际收益。CBG重传能提高资源利用率但代价是HARQ反馈开销增加。如果上行控制信道容量本来就紧张建议关闭CBG或者减少CBG数量。另外可以检查PUCCH资源分配是否足够必要时增加PUCCH资源集。4.4 坑四TDD配比导致HARQ反馈窗口过长现象TDD网络下某些上行子帧的HARQ反馈比特数异常大PUCCH解码失败率升高。原因TDD上下行配比中下行子帧连续多个时终端需要在一个上行子帧里反馈多个下行子帧的HARQ结果。如果DAI指示的调度子帧数很多反馈比特数会线性增长。解决检查TDD配比和HARQ反馈时序配置。如果反馈窗口过长可以考虑启用HARQ捆绑把多个子帧的反馈压缩成1bit。代价是丢失了部分重传粒度但能显著降低上行控制开销。另外要确保DAI解析正确DAI值错误会导致反馈比特数计算错误终端和基站理解不一致HARQ进程混乱。4.5 坑五UCI复用PUSCH时MCS降阶过多现象终端有上行数据发送时PUSCH的MCS明显低于信道条件允许的值上行吞吐量上不去。原因UCI复用到PUSCH时需要占用一定的RE资源来承载UCI比特。如果UCI比特数较大PUSCH的可用数据RE减少为了保持相同的编码速率基站会降低MCS。如果UCI比特数超过PUSCH容量的某个比例MCS会降得更厉害。解决检查UCI比特数和PUSCH资源分配的匹配度。如果UCI比特数太大考虑把CSI报告改成非周期触发避免在PUSCH传输时刻复用。也可以调整PUSCH的频域资源分配给UCI留出更多空间。另外要确认基站的UCI复用参数配置是否合理有些设备厂商的实现里有一个UCI比特数上限超过就强制走PUCCH。5. 用TS38.212做UCI比特解析的进阶技巧前面讲的都是配置层面的排查真正要定位UCI解码问题还得回到TS38.212的6.3节把比特结构跟实际log里的比特流对上。我一般会按这个流程走第一步从RRC配置里提取UCI相关的参数PUCCH格式、CSI报告配置、SR周期、CBG配置、TDD配比。这些参数决定了UCI的理论比特数。第二步从DCI里提取调度信息DAI值、CSI请求字段、HARQ进程号。DAI值决定了HARQ反馈的实际比特数CSI请求字段决定了是否触发非周期CSI。第三步用TS38.212的公式计算UCI比特序列的排列顺序。HARQ ACK/NACK在前SR在中间CSI在后。如果有多载波按载波索引排列。CBG反馈按CBG索引排列。第四步把计算出的比特序列跟log里的UCI比特流做比对。如果对不上检查DAI解析是否正确、CSI报告配置是否跟RRC一致、CBG数量是否匹配。# UCI比特序列排列示例 def uci_bit_sequence(harq_bits, sr_bit, csi_bits): 按照TS38.212 6.3.1的顺序排列UCI比特 harq_bits: HARQ ACK/NACK比特列表 sr_bit: SR比特0或1None表示无SR csi_bits: CSI比特列表 sequence [] # HARQ ACK/NACK在前 sequence.extend(harq_bits) # SR在中间 if sr_bit is not None: sequence.append(sr_bit) # CSI在后 sequence.extend(csi_bits) return sequence # 示例2bit HARQ, 1bit SR, 4bit CSI harq [1, 0] # ACK, NACK sr 1 csi [0, 1, 1, 0] print(uci_bit_sequence(harq, sr, csi)) # [1, 0, 1, 0, 1, 1, 0]这个排列逻辑看起来简单但实际log里UCI比特流可能经过加扰、调制不能直接比对。常见做法是先解调、解扰还原出UCI比特再跟理论序列比对。如果比对失败重点查DAI和CSI请求字段的解析这两个字段最容易出错。还有一个技巧用CSI报告的比特数反推CSI类型。如果CSI比特数在10到20之间大概率是RICQI如果在30以上可能是CRIRSRP或者PMI。这个反推在不知道RRC配置的情况下很有用能快速判断CSI报告的类型。提示TS38.212的6.3节表格很多建议把常用的几个表打印出来贴在工位上比对的时候直接查表比翻电子版快得多。从那以后我每次做UCI相关排查都强制走一遍「配置提取→比特计算→log比对」的流程不跳过任何一步。看起来麻烦但能避免大部分误判。希望帮到你。本文还有配套的精品资源点击获取