做LTE物理层协议分析和无线网络优化的人，肯定绕不开MIMO，而聊MIMO又绕不开预编码。很多同事拿着路测软件盯RI、PMI、CQI，能报数却说不清这三个值是怎么算出来的，也不清楚基站拿到PMI之后到底怎么把数据符号送到天线上去。这篇把预编码的前前后后掰开讲一遍，重点放在“协议为什么这么设计”和“实现时要注意什么”上，适合物理层开发、协议测试、网络优化的朋友，也适合那些刚入行、想系统理解LTE多天线原理的同学。我尽量用大白话，把天线权值、码本、反馈、接收机那一套串成一个完整故事。
1. 预编码在解决什么问题：MIMO里的“发端先手”
1.1 没有预编码时，多天线其实很“拧巴”
LTE多天线可以用一个线性系统来描述：发送端有Nt根天线，接收端有Nr根天线，收到的信号模型是 y = H·W·x + n。其中H是信道矩阵，W是预编码矩阵，x是待发送的数据符号向量，n是噪声。如果W是单位阵，等价于“什么额外处理都不做”，基站直接发射多路独立数据流，接收端看到的是多路信号在空间里的线性混合。此时接收端必须靠信道均衡把数据分出来，比如直接对等效信道求逆。
问题在于，当两根天线对应的信道高度相关时，H矩阵会变得病态。我举个例子，在室内或者终端紧贴人体、金属物体遮挡的场景下，基站两端口到终端两根接收天线的信道往往高度相似，2×2信道特征值一个很大、一个极小。接收端如果直接做解相关运算，小特征值方向会被当作分母放大，噪声被抬升十几dB不止。结果就是两流数据抢同一块空间资源，总吞吐还不如老老实实发单流。这个现象在强相关信道下非常典型，也是多天线系统必须引入发射端处理的原因。
1.2 预编码的核心逻辑：把“解混线”的动作前置到发射端
如果发射端能预知H的形状，就可以在数据发送之前先做一次线性变换W，让H·W变成一个“条件数良好”的等效信道。更进一步，对H做奇异值分解（SVD），可以得到 H = U·Σ·V^H。若取W等于V的前v列，则有 H·W = U·Σ_v。接收端只需要做U^H匹配滤波，多天线信道就被打散成v个互不干扰的并行子信道，每个子信道的增益正好是Σ里对应的奇异值。这就是线性预编码的理论最优解。
打个生活比方：两个人在两个房间里各用一个话筒说话，你知道每个话筒和音箱之间的房间回声路径，就可以在“说话之前”调整音量分配，让对面两个音箱收到的声音彼此分离得足够干净。接收端只要简单滤波，不需要做复杂破译。预编码的本质，就是把接收端从“混线堆里硬拆”的复杂度，搬一部分到发射端去做“事先整理”。这个思路贯穿LTE所有MIMO模式。
1.3 测量在接收端、处理在发射端，就必然产生反馈
为什么LTE不能直接用SVD算出来的V矩阵做预编码？因为FDD系统里下行信道是由UE测量得到的，基站并不知道精确的H矩阵。即使TDD可以利用上、下行信道互易性，工程上天线校准、干扰环境也会带来偏差。所以LTE的协议设计必须回答两个问题：UE怎么把信道信息告诉基站，以及基站拿到信息后怎么把它变成实际发射的权值。
码本方案就是答案：UE把所有可能的预编码矩阵事先列成一本“字典”，在里面挑一个最合适的，只回报编号PMI。这样上行反馈开销极小，两端口只要2bit，四端口也不过4bit。但代价是量化误差：实际信道方向不可能每次都精确落在某个码本矩阵上，只能在离散集合里选择最近的点。反馈精度、开销、复杂度这三者之间的取舍，是LTE预编码设计的主线。
2. LTE码本为什么这么设计：从量化到恒模约束
2.1 码本不是随便凑的，工程约束比数学最优更关键
如果只追求量化误差最小，把码本矩阵都设计成单位阵附近的高精度向量就行，但工程上行不通。码本设计有几个硬约束，缺一个都会在功放、调度、实现上出问题。
第一个是恒模（Constant Modulus）约束。码本里每个元素的幅度要接近相等，确保不同预编码方向下，每根物理天线的发射功率基本一致。如果某个矩阵里出现幅度很大的元素，对应天线方向的平均功率就会抬高，超出功放线性区，信号被限幅，邻道泄漏跟着恶化。这个约束是“可以不用，但用了就一定会牵连射频设计”的典型。
第二个是嵌套（Nested）属性。低Rank的预编码向量必须是高Rank矩阵的前几列。这样调度器从单流切到双流，或者从双流回退到单流时，不需要UE重新上报一套完全不同的矩阵，只需要在原有PMI基础上调整列选择，调度和反馈的灵活性会高很多。
第三个是空间分辨率。码本里的矩阵在格拉斯曼流形上要尽量分布均匀，避免某些方向量化误差特别大、某些方向又冗余。四端口16个矩阵，就是按这个思路用Householder变换构造出来的，集合内矩阵之间的最小距离比较大，整体量化误差更平滑。
2.2 2端口与4端口码本的实际差异
LTE Rel-8的2端口码本很小：Rank1有4个预编码向量，Rank2有3个矩阵。终端遍历起来压力极小，但量化精度有限。四端口码本则用16个Householder反射矩阵生成，每个矩阵形如 W_n = I - 2·u_n·u_n^H / (u_n^H·u_n)，再由规范把列向量选出来。具体表项都列在标准文档TS 36.211里，做实现时不需要背，直接把表抄进工程代码，再写个遍历就够。
这里有个关键点：4端口码本虽然容量大，但终端接收天线数限制了实际层数。常见配置是4T4R基站配2R终端，最大Rank只有2，所以Rank2时只用到码本矩阵的前两列。你在路测里看到Rank经常为2、很少上到4，不是基站不支持，而是终端能力就卡在那里。理解这一点，对看RI统计分布很有帮助。
2.3 从单码本到双码本，演进逻辑是反馈精度
到8端口之后，如果继续用单码本，8端口全Paul矩阵集合的遍历复杂度、反馈位宽都会激增。于是LTE-A引入双码本结构：一个宽带、长期、慢变的W1负责覆盖大方向，一个频选、短期、快变的W2负责细化选择。反馈被拆成“粗”和“细”两级，上行开销可控，预编码精度也提高了。
我建议做预编码理解时，先吃透4端口单码本的思路，再去对比双码本，会发现协议演进非常有延续性。单码本解决的是“能不能做预编码”，双码本解决的是“反馈得更精细、刷新得更快”，射频和基带的折衷逻辑一直是同一套。
3. PMI/RI/CQI反馈链路和闭环预编码的完整流程
3.1 UE侧选PMI：遍历码本，挑让系统容量最大的那个
UE拿到信道估计H之后，要做的事并不复杂，但计算节奏很紧。对每个候选预编码矩阵W_i，先形成等效信道 H_eff = H·W_i，然后估计接收端均衡后的层间SINR，再映射到互信息或者吞吐，最后选总和最大的那组矩阵和层数。我习惯把流程写成五步：
- 基于参考信号估计下行信道矩阵H；
- 遍历当前Rank下所有候选预编码矩阵W_i；
- 计算等效信道 H_eff = H·W_i，以及对应的接收端均衡矩阵；
- 由均衡后的模型算出每一层的SINR，映射到互信息或吞吐量；
- 选择互信息总和最大的W_i及其Rank，反馈PMI和RI。
第4步是最关键的实现分水岭。用MMSE接收机模型时，第k层的SINR可以近似为：
γ_k = 1 / [ ( I + σ⁻² · H_effᴴ · H_eff )⁻¹ ]_{k,k} - 1其中σ²是噪声功率，H_effᴴ表示H_eff的共轭转置。这个公式把“预编码矩阵选择”直接和“层间干扰水平”绑定在一起，比单纯看信道增益可靠得多。实际终端里，有的厂家用互信息准则，有的用简化SVD或信道范数准则，所以同一信道条件下不同终端反馈的PMI可能不一样，这一点在对比测试时很容易踩坑。
3.2 RI、PMI、CQI不是三个独立参数，是同一件事的三张脸
RI本质是“用几层”的决策，它决定预编码矩阵取几列；PMI是“具体哪个矩阵”的决策，它决定层间干扰特征；CQI则是在选定RI和PMI的前提下，把每层SINR压缩成有效SINR，再映射到信道质量等级。三者必须联动看。测试时经常说“CQI掉了先看RI是不是也降了”，就是因为Rank下降会直接改变每层SINR的计算基础，CQI数值会跟着变。
调度器还可以覆盖UE反馈。即使UE上报RI=2，基站基于小区负载、邻区干扰、终端位置等信息，也可能实际调度Rank1，并通过DCI里的传输格式告诉UE。协议栈实现时要特别注意：传输块大小、调制阶数、码率都是跟着实际调度Rank走的，如果按UE反馈的RI去解析DCI，大概率解错。
3.3 eNodeB拿到PMI后怎么用：从PMI到TPMI再到DCI
基站收到PMI后，不一定原样使用。调度器会结合资源分配、多用户配对、干扰协调等因素，把UE反馈的PMI转化成实际发射用的TPMI，在下行DCI里通知UE。对TM4这种基于CRS解调的闭环模式，这个通知必不可少，因为CRS里没有预编码信息，UE必须用“CRS估计出的信道矩阵”乘以“基站实际用的预编码矩阵”，才能合成等效信道去做解调。如果基站实际用的预编码和DCI里告诉UE的不一致，解调基本全废。
TM3开环模式就不需要这套PMI流程。它的预编码矩阵是按固定规则轮转的，再叠加循环延迟分集，本质是故意制造频率选择性，让信道随子载波变化更充分，靠信道编码和频率分集来扛。它不追求“对当前信道最优”，而追求“在任何信道下都不崩”。这就解释了为什么高速移动场景下开环反而更好：PMI反馈时延在那里摆着，过期的PMI比不用PMI伤害更大。
| 对比项 | TM4闭环空间复用 | TM3开环空间复用 |
|---|---|---|
| PMI依赖 | 依赖UE反馈，时延敏感 | 不依赖反馈，码本固定轮转 |
| 主要增益来源 | 空间复用+波束匹配 | 循环延迟分集+频率分集 |
| 典型场景 | 市区低速、信道变化慢 | 高铁、高速公路、高多普勒 |
| 风险 | 反馈过期、PMI失配 | 峰值速率上限较低 |
这里有一张我在工作里经常用来给新同事解释的对比表，它们不是完全互斥，但调度策略和反馈配置差异很大。
3.4 反馈时延这笔账，算清楚才能理解高速场景
以1.8GHz、终端移动速度60km/h为例，最高多普勒频率大约100Hz，信道相干时间约5ms量级。假设PUCCH上PMI/CQI每5ms上报一次，RI每20ms一次，再加上UE处理时延、基站调度等待，反馈链路整体延迟很容易到10ms以上。10ms对100Hz的信道变化来说，预编码方向已经明显落后于真实信道了。
所以外场优化时，遇到高速场景，第一反应不是把TM4的反馈周期调到最短，而是考虑切换TM3或者用更鲁棒的接收机。反馈周期调短确实有用，但上行开销会增大，而且处理时延的底子在，最终收益有限。这个判断要在现场结合RI、PMI更新速率和BLER一起下。
4. 接收端算法配合和预编码的边界：ZF、MMSE与波束赋形
4.1 接收端不能只做“求逆”：ZF和MMSE的取舍
预编码是发射端的线性变换，等效信道 H_eff = H·W。因为W是量化过的矩阵，H_eff一般不会完全对角，层间残留干扰仍然存在。接收端用线性均衡去打散残留，最常见的是迫零ZF和最小均方误差MMSE。
ZF接收机直接对H_eff求逆，理论上把层间干扰全部抵消，但代价是噪声被放大。假设两层等效信道奇异值为λ1=1、λ2=0.2，噪声功率0.1，ZF会把λ2方向放大1/0.2=5倍，该方向SNR损失约14dB。MMSE则会在“消除干扰”和“抑制噪声”之间取折衷，不强求干扰为零，但总均方误差最小。低SNR场景和高条件数信道下，MMSE优势很明显，这也是LTE终端接收机主流选择MMSE的原因。
做链路仿真时尤其要留意：不同均衡器模型下，预编码增益的结论可能完全不同。如果报告里不写接收机假设，对比结果基本没有参考价值。
4.2 层SINR到CQI映射，为什么经常出现“对了天，错了地”的情况
UE上报CQI时，通常会把每层SINR经过EESM或MI-ESM压缩成一个有效SINR，再映射到CQI等级。这个链条上的误差来源很多：均衡器模型不匹配、信道估计误差、干扰非白化、层间正交性估计偏乐观等，都会让上报CQI和实际情况脱节。
我排查外场问题时的经验是：凡是怀疑预编码性能的，先同时抓RI、PMI、CQI、BLER四个量，不要只看吞吐。如果CQI很高但BLER一直不收敛，放大看链路，大概率是高Rank下层间正交性不足，SINR计算过于乐观。这种情况下，节省的反馈开销和复杂度不会体现在吞吐里，只会体现在误码率报表上。
4.3 码本预编码和波束赋形的边界，在DMRS那里断开了
波束赋形本质也是一种预编码：把数据加权到多根天线上，让能量对准目标方向。但LTE TM7的单流波束赋形，不依赖UE反馈PMI，而是基站根据上行探测或信道互易性自己计算权值，解调用专用参考信号DRS/DMRS，UE不需要知道权值矩阵长什么样。这是因为参考信号和数据经历了同一个预编码，UE直接估计出的是等效信道。
这条边界在LTE往LTE-A演进时变得尤其重要。TM8以后，DMRS-based解调模式下，预编码权值可以不受码本约束，自由度更高；而CRS-based闭环模式必须严格依赖码本和TPMI通知。理解这个差别，才能解释为什么TM7/TM8在复杂传播环境里经常比TM4更灵活，也为什么它们对天线校准更敏感。
5. 外场和仿真里常见的几个预编码坑
5.1 坑一：PMI跳来跳去，不代表预编码失效
如果PMI在相邻两个索引之间反复跳变，但CQI很稳、吞吐波动不大，通常是两个候选矩阵的互信息几乎相等，而UE实现里选准则不同造成的。不要一看到PMI跳变就怀疑基站预编码没生效。建议统计一段时间的PMI分布，而不是看瞬时值。PMI分布非常集中，说明信道方向很稳定；如果PMI长期只在某两个索引间跳，再检查天线端口的相位校准，那个问题通常更隐蔽。
5.2 坑二：RI=2但CQI看起来像单流水平
可能信道秩够但两层之间正交性差，比如天线相关性高、多径不够丰富；也可能是调度器实际只用了Rank1。先看DCI里实际调度的层数和MCS，再看RI反馈周期是否过长导致RI过期。基站如果通过上行探测或历史链路判断出天线相关性高，哪怕UE报RI=2，调度器也会保守地用Rank1，这属于正常的链路自适应，不是故障。
5.3 坑三：高速移动下闭环预编码拖后腿
车速超过60km/h甚至更高时，反馈PMI的时延会导致预编码方向“过期”。外场测试里如果发现TM4在高速段吞吐断崖式下降，先检查PMI更新周期，再检查RI是否频繁降秩。有些工程师为了“保RI”去调低切换门限，短期看着Rank稳定了，实际平均吞吐可能更差。遇到这类场景，TM3加合理的MCS回退，往往比硬扛闭环更靠谱。
5.4 坑四：天线相关性和码本量化误差叠加
码本是固定集合，当实际信道落在一个码本矩阵的量化边界附近时，量化误差会很大。天线相关性越高，信道方向越“窄”，码本里能有效匹配的方向越少，性能损失越明显。与其换码本，不如考虑降低Rank、改用发射分集、或者切换波束赋形TM7/8。物理层调优的空间不止在软件参数，天线间距、终端姿态这些物理条件也直接影响预编码增益。
5.5 坑五：MU-MIMO配对只看PMI正交性不够
Rel-8 MU-MIMO在同一个PRB上最多配两个单流用户，很多人选用户时只强调PMI正交性。但配对效果还受两个用户SINR差异、RB分配、功率分配和调度公平性影响。强用户和弱用户配在一起，弱用户很容易被强用户功率盖住，系统总吞吐反而下降。我自己调试时习惯先按SINR把用户分组，再在组内挑PMI正交性最好的配对，同时控制强用户的功率余量。下面这张速查表可以贴在工位上参考。
| 问题现象 | 可能原因 | 排查动作 |
|---|---|---|
| PMI频繁跳变但吞吐稳定 | 候选矩阵互信息相近、UE准则差异 | 统计PMI分布，不盯瞬时值 |
| RI高但CQI低 | 信道秩不足或调度Rank回退 | 核对DCI实际层数、天线相关性 |
| 高速场景闭环掉吞吐 | PMI反馈时延过长 | 对比TM3、调整反馈周期 |
| 强相关信道增益小 | 码本量化误差叠加 | 降Rank、切波束赋形 |
| MU配对后弱用户崩溃 | 只按PMI正交没看SINR差异 | 按SINR分组再配PMI |
最后聊点我个人的体会。做预编码相关的学习和调试，光看协议文本容易晕。我建议拿到一个信道矩阵就先用SVD拆一遍，看看奇异值长什么样，再拿一个简单的MMSE链路把“UE选PMI、基站用PMI、接收端解调”的闭环跑起来。你会发现预编码的核心没那么神秘，无非是在发射端用一层线性变换，把信道掰成接收端更好处理的样子。它在LTE里经历了从2端口到4端口再到8端口双码本的演进，这条思路在5G里也延续着。希望这篇能帮你把RI、PMI、CQI和天线端口之间的那根线彻底捋顺。
