------从"反馈什么"理解 NR 上行控制信息
在上一小节从 Msg4 切入 PUCCH 后，我们已经建立了一个最基本的认识：UE 不仅需要接收 gNB 发来的下行数据，也需要在适当的时间把"接收结果、资源需求以及信道状态"等控制信息返回给 gNB。这里真正值得进一步追问的问题不是"UCI 在哪个物理信道上发送"，而是：
UCI 到底在向 gNB 传递什么信息？这些信息分别解决什么问题？为什么它们的产生条件、时效性和信息量会有如此大的差异？
|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
| 本节学习边界： 本节只聚焦 UCI 的三类核心内容------HARQ-ACK、SR 与 CSI，重点建立"信息来源---触发原因---比特含义---网络侧用途---三者之间关系"的知识体系。关于不同承载方式、具体 PUCCH 资源选择、格式结构、资源映射和功率控制等内容，在后续小节中再分别深入。 |
图7.3.5.2-1 UCI 承载内容的三大分类
从功能角度看，这三类 UCI 可以分别概括为三个问题：HARQ-ACK 回答"刚才的数据传输结果怎样"；SR 回答"我有没有新的上行传输需求"；CSI 回答"按照当前无线信道条件，gNB 下一次怎样传输更合适"。虽然三者都属于 UE→gNB 的控制信息，但它们并不是同一种反馈。
7.3.5.2.1 UCI 的本质：不是业务数据，而是"关于传输的控制信息"
理解 UCI 最好的方法，是先把它与我们已经学习过的用户数据区分开。用户面数据描述的是"用户真正要传递的内容"，例如网页、视频、文件或语音数据；UCI 则描述"无线传输本身的状态或需求"。因此，UCI 的价值通常不在于信息量大，而在于它能让 gNB 知道当前这条无线链路发生了什么，以及下一步应该如何处理。
HARQ-ACK：针对已经发生的下行数据传输，告诉 gNB UE 的接收判决结果。
SR：在 UE 需要上行资源、但当前没有合适的上行传输机会时，向 gNB 发出资源需求信号。
CSI：UE 根据下行参考信号等测量结果形成的信道状态报告，为 gNB 的下行传输策略提供输入。
这三个类别的共同点是：它们最终都服务于无线资源控制和可靠传输闭环。不同点则非常鲜明------HARQ-ACK 是"事件发生后立即给出结果"，SR 是"需求出现后请求机会"，CSI 则是"测量信道后提供决策依据"。
| UCI 类型 | 它回答的问题 | 直接针对的对象 | 信息来源/产生条件 | 网络侧主要用途 |
|---|---|---|---|---|
| HARQ-ACK | 这次下行传输我收得怎样？ | 某次下行传输/TB | UE 完成相应下行接收与判决后 | 决定 HARQ 后续动作 |
| SR | 我现在需要上行资源吗？ | UE 的上行传输需求 | UE 有待发数据且缺少可用 UL 传输机会等 | 为后续 UL Grant 提供触发 |
| CSI | 当前信道适合怎样传？ | 下行无线信道与空间传输条件 | UE 对配置的参考信号进行测量和计算后 | 辅助调度、MCS、空间传输等决策 |
7.3.5.2.2 HARQ-ACK：对下行传输结果的最快反馈
（1）从"收到 TB"到"形成 HARQ-ACK"
当 gNB 通过 PDSCH 向 UE 发送一个 Transport Block（TB）时，UE 的物理层需要完成同步、信道估计、解调、解扰、译码以及相应的错误检测。这里最终得到的并不是一句文字意义上的"成功/失败"，而是 UE 对该次传输所形成的 HARQ-ACK 信息。
在最简单的单 TB 场景中，可以把它抽象为 1 个 HARQ-ACK 信息比特：ACK 表示该次传输被 UE 正确接收并通过相应的错误检测；NACK 表示该次传输没有被 UE 正确恢复。实际 NR HARQ 反馈体系比"1 个 TB=1 个 bit"更复杂，因为多个下行传输、多个服务小区、不同 HARQ 过程以及不同 PDSCH 调度事件都可能共同决定一个反馈时刻需要报告多少 HARQ-ACK 信息。
图7.3.5.2-2 HARQ-ACK 从下行 PDSCH 接收到反馈的基本闭环
|--------------------------------------------------------------------------------------------------------------|
| 关键区分： HARQ-ACK 不是把 PDSCH 的 CRC 字段原封不动地"传回去"。UE 在本地完成接收判决后，把这个判决结果编码成规范定义的 HARQ-ACK 信息，再通过上行控制反馈链路传给 gNB。 |
（2）为什么 HARQ-ACK 的时效性特别高？
HARQ 的核心思想是把前向纠错与重传机制结合起来：第一次传输主要依靠信道编码纠正错误；如果 UE 判断本次传输没有被正确恢复，则通过反馈让 gNB 在后续机会中重新传输。于是，HARQ-ACK 处在一个非常短的闭环中：
gNB 发送 PDSCH。
UE 接收并完成译码与错误检测。
UE 形成 ACK/NACK 判决。
UE 在规定的反馈时机发送 HARQ-ACK。
gNB 根据反馈决定是否进行后续 HARQ 处理。
因此，HARQ-ACK 的价值并不仅仅是"告诉基站有没有错"，而是直接参与无线链路的可靠传输闭环。反馈过晚，会增加 HARQ 往返时间；反馈丢失或误判，则可能造成不必要的重传、吞吐下降，甚至在极端情况下造成错误的数据处理。
（3）多个 HARQ-ACK 为什么会出现？
在简单的单载波、单 TB 直观模型中，一个下行 TB 对应一个 HARQ-ACK 判决。但 NR 支持载波聚合、多个服务小区以及不同调度关系，因此一个反馈时刻可能对应多个需要报告的 HARQ 状态。此时，物理层需要按照既定顺序形成 HARQ-ACK bit sequence，而不是简单地发送一个"总 ACK"。
| 场景 | 可能的反馈规模 | 理解方式 |
|---|---|---|
| 单次 PDSCH、单 TB | 通常可抽象为 1 bit | ACK 或 NACK |
| 多个下行传输事件 | 多个 bit | 每个反馈位置对应一个确定的 HARQ 状态 |
| 载波聚合/多服务小区 | 可能包含多个反馈项 | 需要按照规定顺序组成反馈序列 |
| 更复杂的 HARQ 反馈场景 | 反馈规模进一步增加 | 由规范定义的 HARQ-ACK codebook 组织 |
7.3.5.2.3 SR：UE 向 gNB 打开的"上行资源请求窗口"
SR（Scheduling Request，调度请求）与 HARQ-ACK 有一个根本区别：HARQ-ACK 是对"已经发生的下行传输"做反馈，而 SR 是 UE 对"未来上行传输机会"的需求表达。它解决的是资源获取问题，而不是错误恢复问题。
可以把 SR 理解为 UE 向 gNB 发出的一个非常简短的"破冰信号"：我现在有上行数据或上行传输需求，但当前没有足够的上行传输机会，请你给我安排资源。SR 本身通常不承担具体的 Buffer 字节数报告；gNB 真正需要知道"到底有多少数据"时，还要依靠后续的 BSR 等 MAC 层机制。
图7.3.5.2-3 SR 与上行资源获取之间的基本关系
|------------------------------------------------------------------------|
| 工程上的一句话记忆： SR 解决"有没有资源"的问题；BSR 解决"需要多少资源"的问题。不要把 SR 和 BSR 当成同一个机制。 |
（1）SR 为什么常常只有很少的信息量？
因为 gNB 在 SR 阶段真正需要知道的第一件事情并不是"UE 有 2376 字节还是 8241 字节"，而是"这个 UE 是否出现了需要上行资源处理的新需求"。如果 UE 直接拥有足够的 PUSCH 资源，那么它可以利用已有资源发送数据及相关 MAC 信息；只有在缺少合适上行机会时，SR 才体现出特别重要的作用。
因此，SR 的信息量很小并不意味着它不重要。恰恰相反，它属于典型的"少量比特、关键控制作用"的设计。一个极小的控制信息可以触发后续更大规模的资源分配和数据传输。
（2）SR 与 Msg4 后流程的衔接
初始接入阶段与稳定业务阶段在"是否需要 UE 主动申请上行资源"这一点上存在明显差别。随机接入后的若干消息具有较强的流程确定性，某些上行消息的资源已经由前一步过程确定，因此不能简单地把所有上行消息都理解为"先发 SR 再等 Grant"。进入正常连接态之后，当 UE 出现新的上行数据需求且缺少合适的 PUSCH 机会时，SR 才成为典型的资源请求入口。
因此，从业务流程的角度看，可以形成一个非常重要的认知：SR 并不是"所有上行数据发送前都必须发送"的固定前置步骤，而是一种在特定资源状态下才需要触发的请求机制。
（3）Positive SR 与"没有 SR"
SR 的表达方式与普通数据字段很不同。它不是 UE 每个时隙都发送一个 0/1 状态报告。只有在满足触发条件时，UE 才会在配置的 SR occasion 上发送相应的 SR；没有待发送的请求，并不意味着 UE 必须再发送一个"Negative SR=0"的独立消息。
| 状态 | UE 行为 | gNB 看到的意义 |
|---|---|---|
| 无 SR 触发 | 不产生该次 SR 发送 | 不能据此理解为"UE 永远没有数据" |
| Positive SR | 在相应 SR occasion 发送请求 | UE 有需要获取上行资源的需求 |
| SR 已触发并获得 UL Grant | 后续进入正式上行传输过程 | SR 所承担的"破冰"任务完成 |
| 已有 PUSCH 资源 | 通常无需用 SR 重新申请当前已有资源 | 直接利用已授权机会进行上行传输 |
7.3.5.2.4 CSI：让 gNB"知道无线信道现在适合怎样传"
CSI（Channel State Information，信道状态信息）是三类 UCI 中最容易被初学者误解的一类。它不是一个单独的"信号强度值"，也不是把 UE 估计出来的完整无线信道矩阵直接上传，而是 UE 根据网络配置的测量资源和报告规则，对当前无线信道及空间传输条件进行测量、计算、量化后形成的标准化报告。
图7.3.5.2-6 CSI 报告中常见的内容维度
原课程中重点介绍了 CQI、RI 和 PMI。实际 NR 的 CSI 体系还可以根据配置包含其他报告量，例如 CRI、SSBRI、L1-RSRP、Layer Indicator 等。因此，在工程日志中看到"CSI report"时，不能默认它永远只有 CQI/PMI/RI 三项；具体包含哪些字段，取决于网络侧的 CSI 报告配置。
（1）CQI：告诉 gNB"信道质量大致允许多激进的调制编码"
CQI（Channel Quality Indicator）可以理解为 UE 对下行链路质量进行量化后的等级化反馈。经典的 CQI 表达采用有限数量的索引值，而不是直接把"实时 SINR=13.7 dB"作为 UCI 字段发送。gNB 获得 CQI 后，可以将其与自身的调度策略、目标 BLER、资源状况等结合，选择合适的调制与编码方案。
|-------------------------------------------------------------------------------------------------------------------------------|
| 不要把 CQI 等同于 SINR： CQI 是一种标准化的链路质量反馈/索引，并不是物理层测量量 SINR 的简单别名。UE 可以基于参考信号测量、假设的接收条件和规定的 CQI 映射规则得到 CQI；gNB 则将其作为链路自适应的输入之一。 |
（2）RI：告诉 gNB"空间上可以利用多少独立层"
RI（Rank Indicator）主要用于描述 UE 根据当前下行信道条件所认为的合适传输秩。这里必须把"天线数量"和"Rank"严格分开：UE 有多少根物理天线，是硬件和能力问题；RI 表示当前信道条件下建议使用的空间层数，是一次传输策略问题。
例如，一个 UE 具有多天线能力，并不意味着 gNB 每次都应该使用最高层数。若空间信道高度相关，增加层数可能并不能带来有效吞吐增益；因此 RI 的意义在于向 gNB 提供空间维度上的信道信息，使调度器可以在吞吐量、可靠性和资源利用率之间进行折中。
（3）PMI：告诉 gNB"码本中的哪一个预编码方向更合适"
PMI（Precoding Matrix Indicator）最容易被错误地理解为"UE 把预编码矩阵发送给 gNB"。更准确的理解是：在采用码本的 CSI 反馈体系中，UE 根据测量结果在预定义的码本候选中选择更适合当前信道的预编码矩阵，并反馈相应的索引。gNB 与 UE 共享同一套码本定义，因此通常不需要把一个大型复数矩阵的全部元素逐项上传。
这一点在大规模 MIMO 中尤其重要。假设系统拥有很多天线端口，直接传递完整预编码矩阵会带来巨大的控制开销；通过标准化码本与索引反馈，可以把复杂的空间信道信息压缩为有限长度的控制信息。
（4）CSI 中的其他报告量：为什么不能只记住 CQI/PMI/RI
随着 NR 的多波束、多 CSI-RS 资源以及更复杂的 MIMO 场景发展，CSI 报告可以进一步描述"哪个参考资源/波束更好""参考信号接收功率如何""建议使用哪一个层"等信息。课程中列出的 CRI、SSBRI、L1-RSRP 和 Layer Indicator 可以帮助我们从更完整的角度理解 CSI：
| 报告量 | 核心含义 | 直观理解 | 主要服务的决策 |
|---|---|---|---|
| CQI | 信道质量等级 | "当前链路适合多高的 MCS" | 链路自适应/调度 |
| RI | 建议传输秩 | "当前适合几层空间传输" | MIMO 层数 |
| PMI | 预编码矩阵指示 | "码本里哪个预编码更合适" | 空间预编码 |
| CRI | CSI-RS 资源指示 | "哪个 CSI-RS 资源更值得采用" | 资源/波束选择 |
| SSBRI | SSB 资源指示 | "哪个 SSB/波束更合适" | 波束/测量相关决策 |
| L1-RSRP | 物理层参考信号接收功率 | "这个参考信号有多强" | 快速链路/波束相关判断 |
| Layer Indicator | 层相关指示 | "哪个层具有更好的特性"等 | 空间传输相关决策 |
（5）CSI 的真正价值：形成"测量---反馈---决策"闭环
图7.3.5.2-7 CSI 从测量到网络侧传输决策的闭环
CSI 的意义必须放在闭环中理解。UE 通过参考信号获得对下行信道的观测；随后按照配置计算 CSI；gNB 接收到 CSI 后，把它与自身的调度器状态、业务需求和其他无线测量结合起来，决定下一次或后续下行传输采用怎样的资源、调制编码和空间传输策略。
因此，CSI 不是一次性的"网络状态报告"，而是一种持续更新的反馈接口。UE 移动速度越快、遮挡和散射变化越明显，信道状态变化就越快，过时的 CSI 就越可能降低链路自适应的准确性。反过来，如果 CSI 上报过于频繁，也会增加控制开销。因此，CSI 报告周期本质上是"信道变化速度、控制开销和调度收益"之间的工程折中。
（6）周期性、半持续性与非周期性：这里只建立概念，不展开流程
CSI 报告并不只有一种触发方式。网络可以通过高层配置让 UE 按固定周期报告，也可以使用半持续方式维持一定的报告状态，还可以在需要时通过下行控制信令触发非周期性报告。这里最重要的是理解"谁决定报告发生"与"什么时候报告"这两个概念，而不是在本节提前进入具体的资源和时序算法。
| 报告方式 | 触发思想 | 典型特点 | 适合的理解方式 |
|---|---|---|---|
| 周期性 CSI | 按配置的周期重复出现 | 规则、可预测 | "定时汇报" |
| 半持续 CSI | 先配置，再按一定规则维持报告 | 介于周期与动态之间 | "预先建立的持续汇报" |
| 非周期性 CSI | 由需要时的控制信令触发 | 按需、灵活 | "临时要求 UE 汇报一次" |
7.3.5.2.5 三类 UCI 的横向比较：三个不同层面的"反馈问题"
图7.3.5.2-5 HARQ-ACK、SR 与 CSI 所回答的三个不同问题
把三类 UCI 放在同一张图上，最容易建立稳定的认知：它们虽然都属于上行控制信息，但"反馈对象"完全不同。
| 维度 | HARQ-ACK | SR | CSI |
|---|---|---|---|
| 反馈对象 | 已经发生的下行传输 | 未来的上行资源需求 | 当前/近期的下行信道状态 |
| 核心目的 | 保证可靠传输闭环 | 打开上行资源获取通道 | 改善后续传输参数选择 |
| 典型内容 | ACK / NACK 等 | Positive SR | CQI、PMI、RI 等 |
| 产生方式 | 由对应下行传输事件驱动 | 由 UE 的上行资源需求触发 | 由测量与报告配置触发 |
| 时间敏感性 | 通常最高 | 通常取决于业务资源需求 | 取决于信道变化速度与报告配置 |
| 信息量 | 从极少量到多个反馈 bit | 通常很少 | 通常明显更多，取决于报告配置 |
| 网络侧用途 | HARQ 处理 | UL Grant 触发 | 调度/链路自适应/MIMO 等 |
| 典型错误理解 | 把 ACK 当成 CRC 字段本身 | 把 SR 当成 BSR | 把 PMI 当成完整矩阵 |
（1）HARQ-ACK 与 SR 可以同时出现吗？
可以。在某一个反馈时刻，UE 可能既存在需要反馈的下行 HARQ 状态，又存在一个需要发起的 SR。此时并不是简单地"二选一"，而是由规范定义的 UCI 组合与优先级规则来处理。对于教学上的第一层理解，可以把它看成两个独立事件在同一时间窗口内发生：一个事件来自"下行数据已经收到"，另一个事件来自"UE 产生了新的上行资源需求"。
因此，在分析日志时，如果看到同一 UE 在某个时间点既出现 HARQ feedback，又出现 SR，不应该认为它们互相矛盾；相反，这往往是正常的业务状态叠加。
（2）HARQ-ACK 与 CSI 为什么也可能同时出现？
二者的触发来源不同。HARQ-ACK 通常由某次下行传输事件产生，而 CSI 可以依据周期性或按需报告机制产生。因此，二者的时间轴可能相交。当同一时刻需要发送多个 UCI 内容时，物理层必须按照预先定义的规则把这些内容组织起来。
这一点特别重要：不要把"一次 PUCCH 传输"与"一个 UCI 类型"画等号。一次控制传输可以对应一个 UCI，也可能包含多个类型的 UCI；反过来，在某些情况下不同内容也可能由于调度和资源条件而处于不同的传输机会中。
7.3.5.2.6 典型业务案例：把三类 UCI 放回真实空口过程
案例一：Msg4 后第一次 HARQ-ACK
随机接入完成到 Msg4 时，gNB 通过 PDSCH 向 UE 下发 Msg4。UE 成功接收并完成相应判决后，需要在规定的上行反馈时机形成 HARQ-ACK。这个案例是理解 HARQ-ACK 最直观的入口，因为它把"下行数据---接收判决---上行反馈"三个环节第一次完整串起来。
UE 已经通过随机接入过程获得发送 Msg3 所需的上下文。
gNB 发送 Msg4 PDSCH。
UE 对 Msg4 PDSCH 进行接收、解调和译码。
UE 根据接收结果形成相应 HARQ-ACK。
该 HARQ-ACK 进入 UCI 发送流程，最终由上行控制传输反馈给 gNB。
与此同时，Msg4 本身还涉及竞争解决判断；因此不能把"HARQ-ACK=ACK"和"RACH contention resolution 成功"机械地视为完全相同的概念。
|-----------------------------------------------------------------------------------------------------------------------|
| 工程抓包提示： 分析 Msg4 时建议至少同时观察：Msg4 对应的下行调度、PDSCH 接收结果、HARQ process/feedback 关联以及后续上行控制反馈。这样可以把 PHY、MAC 与 RRC 的事件链串起来。 |
案例二：UE 有上行数据，但当前没有合适的 PUSCH 机会
假设 UE 已经处于正常连接态，应用层产生新的上行数据，数据逐渐进入 UE 的协议栈缓存。但此时 UE 没有可用的上行传输机会。UE 需要让 gNB 知道"我现在有事情要发"，于是 SR 成为一个非常小但关键的控制入口。
上层产生新的上行数据。
数据进入 UE 的缓存，形成上行资源需求。
当前没有足够的上行传输机会，触发 SR。
UE 在配置的 SR occasion 上发送 Positive SR。
gNB 收到 SR 后，调度器获得 UE 的上行需求信息，并可进一步安排 UL Grant。
UE 获得上行资源后，才进入后续的正式上行数据传输和 Buffer 状态汇报过程。
这个案例能够很好地区分 SR 与 BSR：SR 是"请求进入调度流程"的短消息；BSR 则进一步告诉 gNB"我的缓冲区大约有多少待发数据"。二者位于不同的协议职责层次。
案例三：UE 根据 CSI 反馈影响后续 MIMO 与链路自适应
假设 UE 正在高速移动，经过一个遮挡区域后，下行无线信道的空间特性发生变化。UE 对网络配置的 CSI 测量资源进行测量，发现原来较适合的空间传输条件已经发生变化。UE 按照当前 CSI 报告配置形成新的 CSI 报告并发送给 gNB。
gNB 提供用于 CSI 测量的参考信号资源。
UE 接收并测量参考信号。
UE 根据测量结果计算相应 CSI。
UE 形成 CQI、RI、PMI 或其他配置的 CSI 字段。
gNB 收到 CSI 后，把它与调度器的其他输入结合。
后续下行传输可以据此调整 MCS、空间层数、预编码/波束等参数。
这就是课程中强调的"UE 测量---CSI 反馈---gNB 决策---下一次传输"的闭环。需要注意，CSI 是决策输入，不是"UE 告诉 gNB 下一次必须采用某个参数"的命令。最终调度决策仍由 gNB 根据整个系统状态完成。
7.3.5.2.7 从工程日志识别 UCI：不要只盯着 PUCCH
在实际测试、QXDM、PHY log、MAC log 或空口分析工具中，判断一个 UCI 事件时，最可靠的方法不是看到"PUCCH"三个字就结束，而是沿着"触发源---UCI 内容---反馈时刻---承载结果"四个层次进行关联。
| 观察到的事件 | 首先应该问什么？ | 进一步关联什么？ | 容易犯的错误 |
|---|---|---|---|
| PDSCH Rx + HARQ | 这是哪一次 PDSCH 的反馈？ | HARQ process、PDSCH 时间、反馈时间 | 把任何 ACK 都归给最近的 PDSCH |
| SR indication | 为什么此时产生 SR？ | UE buffer、SR trigger、SR occasion | 把 SR 当成 BSR |
| CSI report | 本次报告包含哪些字段？ | CSI report config、测量资源、报告时间 | 默认所有 CSI 都只有 CQI/PMI/RI |
| UCI transmitted | 里面到底有哪些 UCI 类型？ | HARQ/SR/CSI 的 bit 数及关联事件 | 把一次 UCI 传输等同于一种 UCI |
| UCI decode fail | 失败的是哪个 UCI 内容？ | 对应 UCI payload、CRC/检测结果、时序 | 只看"PUCCH decode fail"而不追触发源 |
|----------------------------------------------------------------------------------------------------------------------------|
| 推荐的日志分析思路： 先建立时间轴，再从下行事件寻找 HARQ-ACK，从 UE Buffer/资源状态寻找 SR，从 CSI 测量与配置寻找 CSI。最后再把这些事件与同一上行反馈时刻关联。这样比单独搜索"PUCCH"更容易定位问题。 |
一个实用的关联模板
时间：记录 PDSCH、SR、CSI 和 UCI transmission 的系统时间。
事件源：标记是谁触发了本次 UCI------PDSCH 接收、资源需求还是 CSI 报告时机。
内容：确定 UCI 是 HARQ-ACK、SR、CSI，还是多个内容共同存在。
长度：记录各类信息的有效 bit 数，尤其注意 CSI 可能显著大于 HARQ-ACK/SR。
结果：区分"UE 产生了 UCI"和"gNB 成功解码了 UCI"两个事件。
闭环：继续观察 gNB 后续行为，例如 HARQ 处理、UL Grant 或后续调度变化。
7.3.5.2.8 几个必须建立的概念边界
① UCI ≠ PUCCH
UCI 是信息内容的统称；PUCCH 是物理承载实体。讨论 UCI 时首先问"传递什么"，讨论 PUCCH 时才进一步问"如何在空口上传"。
② HARQ-ACK ≠ CRC
CRC 是接收端进行错误检测的重要工具；HARQ-ACK 是 UE 根据整个接收处理结果形成并反馈给 gNB 的控制信息。二者存在因果关系，但不是同一个字段。
③ SR ≠ BSR
SR 主要表达上行资源需求；BSR 由 MAC 层报告缓存状态。一个解决"请求机会"，另一个解决"说明需求规模"。
④ CSI ≠ SINR
CSI 是一个报告体系，可以包含多个标准化报告量；SINR 是物理层测量/估计意义上的信号与干扰噪声关系指标。二者不能直接画等号。
⑤ PMI ≠ 原始预编码矩阵
PMI 是预编码相关的标准化指示/索引概念。在码本反馈中，gNB 和 UE 根据相同的码本定义理解该索引所对应的候选矩阵。
⑥ UCI 类型 ≠ 一次传输次数
一次上行控制传输可能包含一种或多种 UCI 内容；不能看到一个上行控制传输就假设只有一个控制信息类型。