1. 预编码到底在解决什么问题1.1 不加预编码多天线只会“各自为战”4G LTE协议分析写到现在终于轮到预编码这个重头戏了。我在前面几篇聊MIMO和传输模式时好几次提到预编码但一直没展开讲因为这个词牵涉的东西实在不少码本、PMI、RI、TM、天线端口映射随便哪个拉出来都能单独写一篇。很多刚开始接触LTE物理层的人看到“预编码”三个字以为只是在发送端做一次复数矩阵乘法但实际上你如果理解不到位后面看调度日志、看反馈报告、分析吞吐率异常都会觉得隔着一层。预编码要解决的第一件事听起来很简单几根天线同时发信号到底怎么让信号在接收端“叠加”而不是“抵消”没有预编码的时候各天线发射的信号到达接收端时相位和幅度是随信道状态随机变化的可能增益叠加也可能直接对消。你可以把多根发射天线想象成几个拿着手电筒的人往同一扇窗户照如果没有提前商量好光线的相位几个人照出来的光可能互相抵消还不如一个人照得亮。这里的数学模型也很直接。接收信号可以写成y H·W·s n其中s是发送符号W是预编码矩阵H是信道矩阵n是噪声。预编码干的事就是根据对信道的认识找到一个合适的W让H·W这个等效信道朝着接收端最容易接收的方向去。换句话说发射端不能只知道“我要发多大功率”还要知道“信号应该从哪个空间方向送出去”。这个思路放到实际系统中就引出了两种完全不同的实现路线一种是用终端反馈的量化索引来选预编码矩阵这叫码本预编码另一种是靠上下行信道互易性、直接用探测信号反推预编码矩阵这叫非码本预编码。两种路线在LTE里都有应用后面我会逐个拆开讲。1.2 预编码、波束赋形、空间复用三者的关系很多资料喜欢把预编码和波束赋形混着说其实它们的关系更像“包含”而非“等同”。预编码是一个大类波束赋形只是预编码在层数为1时的特殊情况。当传输层数只有一层预编码矩阵就退化成一个列向量这时的作用就是把单流信号的能量集中到某个方向这就是传统的波束赋形。当层数大于1时预编码矩阵变成多列每一列对应一路数据流这时候预编码不仅要让每路信号对准接收端还要让不同流之间的信号尽量互不干扰。这也是多流空间复用能提升峰值速率的原因四根发射天线同时发两层数据如果预编码设计得好系统容量几乎可以翻倍。所以预编码在LTE协议里的作用其实是双重的既要完成空间方向的调整又要完成多流之间的“消耦”。这也是为什么预编码矩阵不能随便填矩阵的列之间必须保持正交至少要做到低相关性否则两路流在接收端相互干扰反馈再准也白搭。我个人的理解方式是预编码矩阵承担的是“最后一公里”的物理层整形工作它决定了后面那些数据符号在真正的射频通道上应该以什么样的幅度比例和相位差发射出去。1.3 FDD用码本TDD用互易预编码的两条路线预编码依赖对下行信道的认识。这里有个关键区别FDD系统上下行工作在不同频段信道衰落特性不直接互通所以FDD里基站很难直接通过上行信号准确推断下行信道只能靠终端下发测量报告。终端反馈的东西不可能把信道矩阵整个报上来那开销太大了。LTE的做法是定义一套有限大小的矩阵集合通信双方都事先存好这份“参考词典”终端从词典里挑出当前信道下性能最优的一个矩阵然后只上报这个矩阵的编号。这个编号就是PMI这套词典就是码本。TDD系统则不一样上下行工作在同一个频段、不同时隙电磁波传播路径在毫秒级内基本一致所以基站可以借助上行探测信号SRS来估计上行信道再利用信道互易性推断下行信道直接从估计出的信道里算出预编码权值不需要终端反馈。这个路线下预编码矩阵不再受固定的码本限制可以做得更精细也是8天线以上高增益波束赋形的主要实现方式。我在实际项目中见过不少对这两种路线理解不深的同事经常在FDD网络里问“为什么不能直接用SRS做波束赋形”其实就是没考虑到频段不同导致信道互易性不成立这一层。2. 码本就是预编码的“参考词典”2.1 预编码矩阵的维度天线端口数和层数在聊码本之前先搞清楚预编码矩阵的维度问题。LTE里有几个概念比较容易混淆天线端口、物理天线、层。天线端口不是物理天线根数而是一个逻辑概念对应着一个参考信号端口。比如最常用的两天线端口是端口0和端口1四天线端口则是0、1、2、3。预编码矩阵的行数等于天线端口数列数等于当前传输用的层数。所以两天线端口下如果传一层数据预编码矩阵就是2×1的列向量如果传两层数据就是一个2×2的方阵。四天线端口下可能出现的维度是4×1、4×2、4×3、4×4分别对应层数为1到4的情况。这里有一个很关键的约束层数不能超过天线端口数而且在大多数实际场景里层数也不会超过接收天线数。终端只有两根接收天线时即便基站侧有四根发射天线传输层数最多也只能到2因为接收端的空间分辨能力有限。所以层数到底是多少要靠终端测量后上报秩指示RI来判断RI的值就是当前信道条件下建议使用的传输层数。2.2 真正看懂两天线码本表LTE Release 8里两天线码本比较小巧总共包含4个秩1预编码向量和3个秩2预编码矩阵。它们的权重向量长这样秩1归一化向量[1,1]、[1,-1]、[1,j]、[1,-j]秩2单位矩阵以及由[1,±1]、[1,±j]扩展出的正交矩阵光看这些数字会觉得很抽象我一般习惯从空间方向上去理解。两根天线发送同一个信号时如果两天线的发射权值都是1那么两路信号同相合成波束在正前方最强如果第二根天线的权值是-1两个信号反相合成波束就偏到一侧去。权值里有虚数j时相当于在两天线之间引入了90度的相位差波束方向也随之发生旋转。秩2矩阵则多了一重意义矩阵的两列要同时服务于两路独立的数据流每一列相当于给对应的一路流“指了一个方向”而两列之间尽量正交好让接收端能把两路流区分开。有一次我做室外拉远覆盖测试天线阵列安装在一个楼顶终端在正下方偏转方向移动我对比了终端上行的RI报告和实测的下行吞吐能明显看出当RI从1变成2时如果PMI保持不变每天线之间信号能产生区分速率会有明显一跃。当然这个跳跃能否兑现还取决于多径环境是否足够丰富否则RI2看着好看实际速率反而可能不如单流。这也是一个重要的实操经验RI值高不代表吞吐率一定高。信道条件差的时候高层数带来的反而是串行干扰所以很多厂家的调度器会对RI做“偏保守”的门限处理宁可选择秩低一点也要保证每层流的质量稳定。2.3 四天线与八天线的码本如何演进四天线码本的设计比两天线复杂得多。早期的四天线码本大量使用了基于Householder变换的结构这种结构的好处是生成的预编码矩阵本身是酉矩阵天然具备能量归一化和列间正交性对多流传输很友好。你在题里看到那一大串16个矩阵索引的码本表格不用去背核心理解是这个码本集合覆盖了不同方向组合、不同极化相位关系终端从中选最匹配的一组方向上报PMI。八天线码本则是从Release 10开始引入的设计思路变成了双码本结构用公式表示就是W W1 × W2W1负责描述宽带的、长期稳定的信道特征通常是一个块对角矩阵反映了天线阵列的方向相关性W2负责描述窄带的、短期快速变化的部分比如细波束选择和极化相位调整。这种拆分的最大好处是反馈开销大幅下降因为终端不需要频繁上报W1只需要在信道长期变化时更新一次W2才需要跟着频率选择性快速更新。我之所以在4G协议分析里专门提双码本是因为这个结构太重要了——5G NR里的预编码码本基本就是沿着这个思路继续走的只是把矩阵集合做得更大、分层更细。你如果能把LTE里的双码本结构吃透后面去看NR的Type Ⅰ和Type Ⅱ码本会轻松很多。3. 终端反馈与基站调度RI、PMI、CQI的完整循环3.1 UE侧先算谁后算谁预编码不只是一次性发生在基站侧的操作它更像一个闭环控制系统终端测量信道反馈控制信息基站依据反馈决定预编码矩阵再给终端发数据。这个闭环里最关键的三个反馈值就是RI、PMI和CQI。很多初学者搞不清这三者的先后顺序。 UE内实现时通常先根据信道矩阵的秩来定RI。信道矩阵的秩决定了空间上能支持几路并行流比如信道多径不够丰富时矩阵秩可能只有1反馈RI1其他都免谈。定好RI之后终端会去码本里搜索当前RI条件下的最优预编码矩阵也就是PMI。搜索准则在各厂家实现里不完全一样但目标都一样在给定候选矩阵下让等效SINR尽可能高或者让误块率尽可能低。最后终端基于选定的RI和PMI去估计等效信道再反推CQI上报一个在该预编码条件下能可靠支持的调制编码等级。这个顺序很重要。如果先报CQI再看PMI数据会完全对不上因为不同的预编码矩阵会带来完全不同的等效信道质量。我见过一些用设备厂商私有日志做后处理的人看到RI和PMI对应不上就开始怀疑基站配置错误但其实那只是终端内部搜索时的排序不同造成的需要结合上报周期内的实际调度情况一起看。3.2 宽带PMI与子带PMI该怎么理解LTE的CQI和PMI上报有两种最基本的粒度一种是宽带一种是子带。宽带PMI是对整个传输带宽用一个统一的预编码矩阵适合信道频率选择性不强的场景比如室内低速、视距传输明显的地方。子带PMI则把带宽切成若干个资源块组每个子带单独选预编码矩阵能贴合频率选择性信道。我在优化一个小区吞吐率时遇到过这样一个案例一个FDD两发两收的小区用户固定在一个位置但下行吞吐老是波动看RI和宽带CQI都很正常只有子带CQI在部分子带上明显偏低。后来打开子带PMI上报模式发现高频子带上的PMI和低频子带差了好几个索引。原因就是该用户所在位置正好处于两个不同多径反射簇的交界处频率不同方向不同宽带PMI只能“迁就”整体子带PMI才能细调。最终把上报模式切到子带粒度对应调度资源分配也改成子带匹配吞吐波动明显收窄。不过子带PMI不是没有代价它的上行开销更大而且对移动性敏感。用户一移动子带PMI变化非常快反馈还没到基站信道又变了。所以实际网络里通常是低速用户用子带反馈高速用户切到宽带反馈或干脆用开环模式。3.3 eNodeB拿到PMI后不一定照单全收基站收到UE上报的PMI后并不会完全按这个PMI来发射。原因有很多。第一基站要兼顾多个用户不能只为一个用户最优让整个小区性能受损。第二PMI测量的是瞬时信道和干扰情况基站有可能会综合考虑历史反馈对PMI做平滑或迟滞处理。第三在多用户MIMO配对调度里基站往往需要把两个用户的预编码向量调整成互相正交的方向这时候单个用户“自己最喜欢的方向”就得让路。举例来说用户A上报PMI指向某一组波束方向用户B上报的PMI与其最接近如果让A和B共享同一套时频资源就需要将其中一人的预编码方向稍稍偏移牺牲一点单用户峰值换取两个用户同时传输。这种调度好比两个人要同时过一个窄门各自最优路线可能是同一条但为了不撞车总得有一个人侧身让一步。在看协议时你可能看到基站配置了“PMI自适应”或“预编码去旋转”之类的高级功能本质上就是基站不盲从反馈而是对PMI做了一些修正。如果你在路测中发现DCI中调度的预编码矩阵和UE上报的PMI不完全一致先别急着判定为异常要看基站是否开启了这类修正算法。4. 不同传输模式下的预编码形态4.1 TM3开环没有反馈的“盲发”说到预编码很多人习惯性只想到闭环MIMO其实LTE里还有开环MIMO的做法对应的传输模式是TM3。开环模式下终端不反馈PMI基站也不依赖实时信道状态做预编码而是利用一种叫“循环延时分集”的技术来获得空间分集增益。原理上同一组符号在多根天线上发送时人为地在不同天线上施加不同的循环延迟让同样的信号在频域上形成一种类似频率分集的效果。即使接收端不知道哪根天线的方向最强也能通过频域交织获得增益。这对高速移动场景很有价值因为车速一快闭环反馈往往跟不上信道变化搞不好反而不如开环稳定。所以假如你发现某个用户明明在高速上移动但网络把传输模式配置成了TM4反而是值得警惕的。从工程经验上说高速场景下TM3往往能提供更平稳的体验因为用“分集”兜底永远比用一个过时反馈“硬撑”要靠谱。4.2 TM4闭环PMI驱动下的空间复用TM4是闭环空间复用也是咱们聊预编码的主战场。TM4模式下UE反馈RI和PMI基站基于这些反馈给PDSCH做预编码再把预编码后的数据从对应天线端口发射出去。用户下行数据通过TM4时RI2加上PMI匹配得好就能看到两层空间复用同时工作吞吐峰值几乎翻倍。在实际测试中判断TM4是否真正在高效工作我会看两个层面第一RI是否长期稳定且大于等于2第二物理下行共享信道的预编码矩阵指示是否有周期性切换但又不是无规则乱跳。如果RI一直为1说明信道秩不够或者终端接收能力受限如果RI能到2但实际吞吐没有上升就要去查SINR是否足够支撑双流解调。另外TM4虽然吃PMI反馈但不是所有的TM4都一定是双流。TM4可以同时支持单层和双层传输具体要看DCI里的传输块个数和天线端口信息。所以你在看报告时看到“传输模式4”不等于“一定双流”这也是新手容易踩的坑。4.3 TM5 MU-MIMO多个用户的预编码要“错开”TM5属于多用户MIMO也叫MU-MIMO。在这种模式下两个或多个用户共享同一时频资源每个用户使用不同的预编码向量。因为要同时服务多个用户基站的选择逻辑从“让单个用户方向最匹配”变成了“让多个用户方向尽量正交”。这里有一个很关键的工程问题多用户配对时要看预编码向量的正交性。如果两个用户的PMI指向几乎相同他们在空间上就“挤”在一起相互干扰会把共享增益完全吞掉。我见过一个站点配置了TM5但由于用户分布集中在一个角落配对的PMI相关性很高结果共享资源之后两个用户的速率都在掉后来限制配对条件、提高正交性门槛后才好转。另外还要注意MU-MIMO场景下的CQI。用户上报的CQI通常是基于单用户传输假设算出来的多用户共享资源后干扰水平更高这会导致实际BLER比预期高。所以很多基站会对MU-MIMO场景下的CQI做一定偏移补偿调增益时如果你发现这个偏移不合理用户速率就会被“白白扣掉”。4.4 从CRS到DMRS8天线让预编码变得更灵活从LTE Release 9开始引入了基于专有参考信号DMRS的传输到了Release 10的8天线TM9/TM10预编码的方式发生了革命性变化。之前的TM4是基于CRS的预编码矩阵和CRS是解耦的终端必须用CRS估计出原始信道再去遍历候选PMI最后自己算一遍等效信道复杂度很高。而基于DMRS的时候基站对数据符号做预编码的同时也对DMRS做了相同的预编码。这样终端拿到DMRS后估计出来的本身就是“信道乘预编码矩阵”之后的等效信道终端根本不需要知道基站具体用了哪个矩阵。这种预编码方式对终端是透明的基站侧反而可以更自由地选择任意预编码权值不一定受限于码本集合。这也是为什么TDD系统里用8天线做大范围波束赋形时普遍采用基于DMRS的传输模式的原因。基站用SRS算出信道矩阵后可以对连续波束方向做权值优化不受码本粒度限制。再加上DMRS在接收端天然完成了“去预编码”的过程整个链路闭环下来既灵活又干净。5. 预编码相关的现场调试与问题排查5.1 从测量日志里确认预编码在正常工作这里分享一些我在现场排障时的常规操作主要借助终端或路测软件的物理层日志。第一步确认当前服务的传输模式。不像TM3这类开环可以不看PMITM4、TM6、TM9、TM10这类闭环模式预编码正常工作的前提是反馈链路完整。我会先在日志里筛RI、PMI、CQI三个字段看它们有没有按配置的上报周期稳定出现。第二步看RI的变化趋势。RI长期是1说明空间维度的“潜力”没被发掘出来要么是多径不足要么是终端天线相关性太高。如果RI频繁在1和2之间跳就要考虑是不是信道交替变化太快反馈来不及收敛。第三步把PMI变化节奏和CQI关联起来。如果PMI频繁变化但CQI也跟着涨落这种“联动”属于正常反馈如果PMI剧烈变化但CQI纹丝不动或者反过来PMI稳定但CQI忽高忽低那多半有问题可能是多用户调度干扰、邻区干扰或者功率分配异常。另外还有一个项目化操作在确认PDSCH采用相关模式后可以观察基站配置的“下行DMRS端口数”。如果端口数是单端口但RI长期报2说明基站没有实际采纳终端上报的高秩信息这时候看下行调度选阶和CQI回落有没有做配对心里就有数了。5.2 常见问题排查参考表我把这几年与预编码相关的问题做了个速查表基本覆盖了大部分排查场景写在这里方便查阅。现象可能原因排查方向PMI在两个索引间高频跳变信道呈快速时变反馈滞后于信道变化检查子带PMI是否过于激进考虑改用宽带PMI或TM3RI长期为1吞吐上不去多径环境不佳或终端双流接收能力受限后台看信道相关性调整天线与干扰协调参数高层数RI2但BLER偏高信道秩被高估实际等效SINR不足以支撑双流对RI门限做偏保守调整降低RI后观察BLERTM5配对后单用户速率下降配对用户的PMI方向正交性不足提高配对正交性门槛必要时关闭TM5回退TM4基于DMRS的模式下PDSCH解调失败DMRS端口配置与DCI指示不一致或端口功率分配异常核对DCI中天线端口字段和后台DMRS配置这张表不一定能覆盖所有怪现象但大多数预编码异常归根到底都可以往两个方向上归因一个是反馈是否准确及时另一个是基站侧是否合理使用了反馈。顺着这两条线查基本不会跑偏。5.3 我踩过的几个坑和绕坑技巧第一颗“地雷”把PMI上报间隔当成越小越好。有一次处理下行吞吐异常我把UE的CQI/PMI上报周期配置调得很短想让反馈更实时结果发现吞吐反而下降了。原因是上报频率增加后物理上行控制信道的开销增大同时基站调度器对高频反馈过度敏感PMI频繁切换导致预编码方向不稳定等效信道波动变大。后来把上报周期退回一个合理的折中值加上基站侧开启PMI平滑问题才缓解。第二颗“地雷”在FDD系统里用TDD思维做波束赋形。又一次在某FDD站点优化覆盖有同事希望通过SRS估计信道直接算预编码结果运行一段时间发现效果不稳定甚至比基于码本反馈更差。原因就是FDD频段差异让信道互易性不成立SRS估计出的信道不能直接用于下行。后来改成依赖终端反馈PMI并配合CRS测量来校准空间方向覆盖才算稳住。这里也提醒大家预编码方案选型一定要先看系统是FDD还是TDD再决定采用码本反馈还是互易性预编码。第三颗“地雷”看日志只盯PMI忽略RI和CQI的联动。预编码不是独立变量RI决定PMI搜索的空间维度CQI又依赖预编码后的等效信道。只看PMI不看其他两个往往会对告警和统计表做出错误判断。所以我现在看任何预编码相关的问题习惯把RI/PMI/CQI三个值一起画时间轴观察联动关系而不是单独看某个指标。第四颗“地雷”忽略DMRS端口的功率补偿。在基于DMRS的传输里如果多个DMRS端口被同时使用时发射总功率是固定的单个端口功率会被均分这时候高层“每端口功率”参数配置如果还按单端口满功率来算会给终端一个偏乐观的信道质量预期导致BLER走高。这类问题不好直接看到只能通过比对DSCH端口数和参考信号功率配置来查。5.4 最后再分享一个排查技巧在实际排查预编码异常时我最后几乎都会做一步验证人为切换到开环模式做对照测试。如果同一用户同一位置换到TM3之后吞吐率反而稳定且更高那就说明闭环预编码的反馈链路确实存在问题要么是PMI抖动太厉害要么是基站侧的调度匹配不及时。如果开环模式还不如闭环那就得回到信道本身去找原因比如SINR太低、多径时延太大。这个方法不需要高端工具一台支持手动配模的测试终端和一个能改传输模式的测试脚本就够了尤其在区分“预编码算法问题”和“无线环境问题”时特别管用。我这次在写整个4G LTE协议分析系列时也一直把“可验证性”放在很重要的位置因为协议本身再漂亮最终都要过现场实测这一关。预编码这个主题看起来数学味道重但真正落地时考验的还是对整个反馈链路、调度机制和无线信道的综合理解。 ## 1. 预编码到底在解决什么问题1.1 不加预编码多天线只会“各自为战”4G LTE协议分析写到现在终于轮到预编码这个重头戏了。我在前面几篇聊MIMO和传输模式时好几次提到预编码但一直没展开讲因为这个词牵涉的东西实在不少码本、PMI、RI、TM、天线端口映射随便哪个拉出来都能单独写一篇。很多刚开始接触LTE物理层的人看到“预编码”三个字以为只是在发送端做一次复数矩阵乘法但实际上如果不把整个机制理解透后面看调度日志、看反馈报告、分析吞吐率异常都会觉得隔着一层。预编码要解决的第一件事听起来很简单几根天线同时发信号到底怎么让信号在接收端“叠加”而不是“抵消”。没有预编码的时候各天线发射的信号到达接收端时相位和幅度随信道状态随机变化可能增益叠加也可能直接对消。你可以把多根发射天线想象成几个人拿着手电筒往同一扇窗户照如果没有提前商量好光线的相位几个人照出来的光可能互相抵消还不如一个人照得亮。这里的数学模型也很直接接收信号可以写成y H·W·s n其中s是发送符号W是预编码矩阵H是信道矩阵n是噪声。预编码要做的事就是根据对信道的认识找到一个合适的W让H·W这个等效信道朝着接收端最容易接收的方向去。换句话说发射端不能只知道“我要发多大功率”还要知道“信号应该从哪个空间方向送出去”。这个思路放到实际系统中就引出了两种完全不同的实现路线一种是用终端反馈的量化索引来选预编码矩阵这叫码本预编码另一种是靠上下行信道互易性、直接用探测信号反推预编码矩阵这叫非码本预编码。两种路线在LTE里都有应用后面我会逐个拆开讲。1.2 预编码、波束赋形、空间复用三者的关系很多资料喜欢把预编码和波束赋形混着说其实它们的关系更像“包含”而非“等同”。预编码是一个大类波束赋形只是预编码在层数为1时的特殊情况。当传输层数只有一层预编码矩阵就退化成一个列向量这时的作用就是把单流信号的能量集中到某个方向这就是传统的波束赋形。当层数大于1时预编码矩阵变成多列每一列对应一路数据流这时候预编码不仅要让每路信号对准接收端还要让不同流之间的信号尽量互不干扰。这也是多流空间复用能提升峰值速率的原因四根发射天线同时发两层数据如果预编码设计得好系统容量几乎可以翻倍。所以预编码在LTE协议里的作用其实是双重的既要完成空间方向的调整又要完成多流之间的“消耦”。这也是为什么预编码矩阵不能随便填矩阵的列之间必须保持正交至少要做到低相关性否则两路流在接收端相互干扰反馈再准也白搭。我个人的理解方式是预编码矩阵承担的是“最后一公里”的物理层整形工作它决定了后面那些数据符号在真正的射频通道上应该以什么样的幅度比例和相位差发射出去。1.3 FDD用码本TDD用互易预编码的两条路线预编码依赖对下行信道的认识。这里有个关键区别FDD系统上下行工作在不同频段信道衰落特性不直接互通所以FDD里基站很难直接通过上行信号准确推断下行信道只能靠终端下发的测量反馈。终端反馈的东西不可能把信道矩阵整个报上来那开销太大了。LTE的做法是定义一套有限大小的矩阵集合通信双方都事先存好这份“参考词典”终端从词典里挑出当前信道下性能最优的一个矩阵然后只上报这个矩阵的编号。这个编号就是PMI这套词典就是码本。TDD系统则不一样上下行工作在同一个频段、不同时隙电磁波传播路径在毫秒级内基本一致所以基站可以借助上行探测信号SRS来估计上行信道再利用信道互易性推断下行信道直接从估计出的信道里算出预编码权值不需要终端反馈。这个路线下预编码矩阵不再受固定码本限制可以做得更精细也是8天线以上高增益波束赋形的主要实现方式。我在实际项目中见过不少对这两种路线理解不深的同行经常在FDD网络里问“为什么不能直接用SRS做波束赋形”其实就是没考虑到频段不同导致信道互易性不成立这一层。2. 码本就是预编码的“参考词典”2.1 预编码矩阵的维度天线端口数和层数在聊码本之前先搞清楚预编码矩阵的维度问题。LTE里有几个概念比较容易混淆天线端口、物理天线、层。天线端口不是物理天线根数而是一个逻辑概念对应着一个参考信号端口。比如最常用的两天线端口是端口0和端口1四天线端口则是0、1、2、3。预编码矩阵的行数等于天线端口数列数等于当前传输用的层数。所以两天线端口下如果传一层数据预编码矩阵就是2×1的列向量如果传两层数据就是一个2×2的方阵。四天线端口下可能出现的维度是4×1、4×2、4×3、4×4分别对应层数为1到4的情况。这里有一个很关键的约束层数不能超过天线端口数而且在大多数实际场景里层数也不会超过接收天线数。终端只有两根接收天线时即便基站侧有四根发射天线传输层数最多也只能到2因为接收端的空间分辨能力有限。所以层数到底是多少要靠终端测量后上报秩指示RI来判断RI的值就是当前信道条件下建议使用的传输层数。2.2 真正看懂两天线码本表LTE Release 8里两天线码本比较小巧总共包含4个秩1预编码向量和3个秩2预编码矩阵。它们的权重向量长这样秩1归一化向量[1,1]、[1,-1]、[1,j]、[1,-j]秩2单位矩阵以及由[1,±1]、[1,±j]扩展出的正交矩阵光看这些数字会觉得很抽象我一般习惯从空间方向上去理解。两根天线发送同一个信号时如果两天线的发射权值都是1那么两路信号同相合成波束在正前方最强如果第二根天线的权值是-1两个信号反相合成波束就偏到一侧去。权值里有虚数j时相当于在两天线之间引入了90度的相位差波束方向也随之发生旋转。秩2矩阵则多了一重意义矩阵的两列要同时服务于两路独立的数据流每一列相当于给对应的一路流“指了一个方向”而两列之间尽量正交好让接收端能把两路流区分开。有一次我做室外拉远覆盖测试天线阵列安装在一个楼顶终端在正下方偏转方向移动我对比了终端上行的RI报告和实测的下行吞吐能明显看出当RI从1变成2、同时PMI指向正确时两路流之间产生了足够的区分度速率会有明显一跃。当然这个跳跃能否兑现还取决于多径环境是否足够丰富否则RI2看着好看实际速率反而可能不如单流。这也是一个重要的实操经验RI值高不代表吞吐率一定高。信道条件差的时候高层数带来的反而是流间干扰所以很多厂家的调度器会对RI做“偏保守”的门限处理宁可选择秩低一点也要保证每层流的质量稳定。2.3 四天线与八天线的码本如何演进四天线码本的设计比两天线复杂得多。早期的四天线码本大量使用了基于Householder变换的结构这种结构的好处是生成的预编码矩阵本身是酉矩阵天然具备能量归一化和列间正交性对多流传输很友好。你在协议附件的码本表格里看到那一大串矩阵索引不用去背核心理解是这个码本集合覆盖了不同方向组合、不同极化相位关系终端从中选最匹配的一组方向上报PMI。八天线码本则是从Release 10开始引入的设计思路变成了双码本结构用公式表示就是W W1 × W2W1负责描述宽带的、长期稳定的信道特征通常是一个块对角矩阵反映了天线阵列的方向相关性W2负责描述窄带的、短期快速变化的部分比如细波束选择和极化相位调整。这种拆分的最大好处是反馈开销大幅下降因为终端不需要频繁上报W1只需要在信道长期变化时更新一次W2才需要跟着频率选择性快速更新。我之所以在4G协议分析里专门提双码本是因为这个结构太重要了。5G NR里的预编码码本基本就是沿着这个思路继续走的只是把矩阵集合做得更大、分层更细。你如果能把LTE里的双码本结构吃透后面去看NR的Type Ⅰ和Type Ⅱ码本会轻松很多。3. 终端反馈与基站调度RI、PMI、CQI的完整循环3.1 UE侧先算谁后算谁预编码不只是一次性发生在基站侧的操作它更像一个闭环控制系统终端测量信道反馈控制信息基站依据反馈决定预编码矩阵再给终端发数据。这个闭环里最关键的三个反馈值就是RI、PMI和CQI。很多初学者搞不清这三者的先后顺序。UE内部实现时通常先根据信道矩阵的秩来定RI。信道矩阵的秩决定了空间上能支持几路并行流比如信道多径不够丰富时矩阵秩可能只有1反馈RI1其他都免谈。定好RI之后终端会去码本里搜索当前RI条件下的最优预编码矩阵也就是PMI。搜索准则在各厂家实现里不完全一样但目标都一样在给定候选矩阵下让等效SINR尽可能高或者让误块率尽可能低。最后终端基于选定的RI和PMI去估计等效信道再反推CQI上报一个在该预编码条件下能可靠支持的调制编码等级。这个顺序很重要。如果先报CQI再看PMI数据会完全对不上因为不同的预编码矩阵会带来完全不同的等效信道质量。我见过一些用厂商私有日志做后处理的人看到RI和PMI对应不上就开始怀疑基站配置错误但其实那只是终端内部搜索时的排序不同造成的需要结合上报周期内的实际调度情况一起看。3.2 宽带PMI与子带PMI该怎么理解LTE的CQI和PMI上报有两种最基本的粒度一种是宽带一种是子带。宽带PMI是对整个传输带宽统一用一个预编码矩阵适合信道频率选择性不强的场景比如室内低速、视距传输明显的地方。子带PMI则把带宽切成若干个资源块组每个子带单独选预编码矩阵能贴合频率选择性信道。我在优化一个小区的吞吐率时遇到过这样一个案例一个FDD两发两收的小区用户固定在一个位置但下行吞吐老是波动看RI和宽带CQI都很正常只有子带CQI在部分子带上明显偏低。后来打开子带PMI上报模式发现高频子带上的PMI和低频子带差了好几个索引。原因就是该用户所在位置正好处于两个不同多径反射簇的交界处频率不同方向不同宽带PMI只能“迁就”整体子带PMI才能细调。最终把上报模式切到子带粒度对应调度资源分配也改成子带匹配吞吐波动明显收窄。不过子带PMI不是没有代价它的上行开销更大而且对移动性敏感。用户一移动子带PMI变化非常快反馈还没到基站信道又变了。所以实际网络里通常是低速用户用子带反馈高速用户切到宽带反馈或干脆用开环模式。3.3 eNodeB拿到PMI后不一定照单全收基站收到UE上报的PMI后并不会完全按这个PMI来发射。原因有很多。第一基站要兼顾多个用户不能只为一个用户最优让整个小区性能受损。第二PMI测量的是瞬时信道和干扰情况基站有可能会综合考虑历史反馈对PMI做平滑或迟滞处理。第三在多用户MIMO配对调度里基站往往需要把两个用户的预编码向量调整成互相正交的方向这时候单个用户“自己最喜欢的方向”就得让路。举例来说用户A上报PMI指向某一组波束方向用户B上报的PMI与其最接近如果让A和B共享同一套时频资源就需要将其中一人的预编码方向稍稍偏移牺牲一点单用户峰值换取两个用户同时传输。这种调度好比两个人要同时过一个窄门各自最优路线可能是同一条但为了不撞车总得有一个人侧身让一步。在看协议时你可能看到基站配置了“PMI自适应”或“预编码去旋转”之类的高级参数本质上就是基站不盲从反馈而是对PMI做了一些修正。如果你在路测中发现DCI中调度的预编码矩阵和UE上报的PMI不完全一致先别急着判定为异常要看基站是否开启了这类修正算法。4. 不同传输模式下的预编码形态4.1 TM3开环没有反馈的“盲发”说到预编码很多人习惯性只想到闭环MIMO其实LTE里还有开环MIMO的做法对应的传输模式是TM3。开环模式下终端不反馈PMI基站也不依赖实时信道状态做预编码而是利用一种叫“循环延时分集”的技术来获得空间分集增益。原理上同一组符号在多根天线上发送时人为地在不同天线上施加不同的循环延迟让同样的信号在频域上形成一种类似频率分集的效果。即使接收端不知道哪根天线的方向最强也能通过频域交织获得增益。这对高速移动场景很有价值因为车速一快闭环反馈往往跟不上信道变化搞不好反而不如开环稳定。所以假如你发现某个用户明明在高速上移动但网络把传输模式配置成了TM4反而是值得警惕的。从工程经验上说高速场景下TM3往往能提供更平稳的体验因为用“分集”兜底永远比用一个过时的反馈“硬撑”要靠谱。4.2 TM4闭环PMI驱动下的空间复用TM4是闭环空间复用也是聊预编码的主战场。TM4模式下UE反馈RI和PMI基站基于这些反馈给PDSCH做预编码再把预编码后的数据从对应天线端口发射出去。用户下行数据通过TM4时RI2加上PMI匹配得好就能看到两层空间复用同时工作吞吐峰值几乎翻倍。在实际测试中判断TM4是否真正在高效工作我会看两个层面第一RI是否长期稳定且大于等于2第二PDSCH的预编码矩阵指示是否有周期性切换但又不是无规则乱跳。如果RI一直为1说明信道秩不够或者终端接收能力受限如果RI能到2但实际吞吐没有上升就要去查SINR是否足够支撑双流解调。另外TM4虽然吃PMI反馈但不是所有的TM4都一定是双流。TM4可以同时支持单层和双层传输具体要看DCI里的传输块个数和天线端口信息。所以你在看报告时看到“传输模式4”不等于“一定双流”这也是新手容易踩的坑。4.3 TM5 MU-MIMO多个用户的预编码要“错开”TM5属于多用户MIMO也叫MU-MIMO。在这种模式下两个或多个用户共享同一时频资源每个用户使用不同的预编码向量。因为要同时服务多个用户基站的选择逻辑从“让单个用户方向最匹配”变成了“让多个用户方向尽量正交”。这里有一个很关键的工程问题多用户配对时要看预编码向量的正交性。如果两个用户的PMI指向几乎相同他们在空间上就“挤”在一起相互干扰会把共享增益完全吞掉。我见过一个站点配置了TM5但由于用户分布集中在一个角落配对的PMI相关性很高结果共享资源之后两个用户的速率都在掉后来限制配对条件、提高正交性门槛后才好转。另外还要注意MU-MIMO场景下的CQI。用户上报的CQI通常是基于单用户传输假设算出来的多用户共享资源后干扰水平更高这会导致实际BLER比预期高。所以很多基站会对MU-MIMO场景下的CQI做一定偏移补偿调增益时如果你发现这个偏移不合理用户速率就会被“白白扣掉”。4.4 从CRS到DMRS8天线让预编码变得更灵活从LTE Release 9开始引入了基于专有参考信号DMRS的传输到了Release 10的8天线TM9/TM10预编码的方式发生了革命性变化。之前的TM4是基于CRS的预编码矩阵和CRS是解耦的终端必须用CRS估计出原始信道再去遍历候选PMI最后自己算一遍等效信道复杂度很高。而基于DMRS的时候基站对数据符号做预编码的同时也对DMRS做了相同的预编码。这样终端拿到DMRS后估计出来的本身就是“信道乘预编码矩阵”之后的等效信道终端根本不需要知道基站具体用了哪个矩阵。这种预编码方式对终端是透明的基站侧反而可以更自由地选择任意预编码权值不一定受限于码本集合。这也是为什么TDD系统里用8天线做大范围波束赋形时普遍采用基于DMRS的传输模式的原因。基站用SRS算出信道矩阵后可以对连续波束方向做权值优化不受码本粒度限制。再加上DMRS在接收端天然完成了“去预编码”的过程整个链路闭环下来既灵活又干净。5. 预编码相关的现场调试与问题排查5.1 从测量日志里确认预编码在正常工作这里分享一些我在现场排障时的常规操作主要借助终端或路测软件的物理层日志。第一步确认当前服务的传输模式。不像TM3这类开环可以不看PMITM4、TM6、TM9、TM10这类闭环模式预编码正常工作的前提是反馈链路完整。我会先在日志里筛RI、PMI、CQI三个字段看它们有没有按配置的上报周期稳定出现。第二步看RI的变化趋势。RI长期是1说明空间维度的“潜力”没被发掘出来要么是多径不足要么是终端天线相关性太高。如果RI频繁在1和2之间跳就要考虑是不是信道交替变化太快反馈来不及收敛。第三步把PMI变化节奏和CQI关联起来。如果PMI频繁变化但CQI也跟着涨落这种“联动”属于正常反馈如果PMI剧烈变化但CQI纹丝不动或者反过来PMI稳定但CQI忽高忽低那多半有问题可能是多用户调度干扰、邻区干扰或者功率分配异常。另外还有一个项目化操作在确认PDSCH采用相关模式后可以观察基站配置的“下行DMRS端口数”。如果端口数是单端口但RI长期报2说明基站没有实际采纳终端上报的高秩信息这时候看下行调度选阶和CQI回落有没有做配对心里就有数了。5.2 常见问题排查参考表我把这几年与预编码相关的问题做了个速查表基本覆盖了大部分排查场景写在这里方便查阅。现象可能原因排查方向PMI在两个索引间高频跳变信道呈快速时变反馈滞后于信道变化检查子带PMI是否过于激进考虑改用宽带PMI或TM3RI长期为1吞吐上不去多径环境不佳或终端双流接收能力受限后台看信道相关性调整天线与干扰协调参数高层数RI2但BLER偏高信道秩被高估实际等效SINR不足以支撑双流对RI门限做偏保守调整降低RI后观察BLERTM5配对后单用户速率下降配对用户的PMI方向正交性不足提高配对正交性门槛必要时关闭TM5回退TM4基于DMRS的模式下PDSCH解调失败DMRS端口配置与DCI指示不一致或端口功率分配异常核对DCI中天线端口字段和后台DMRS配置这张表不一定能覆盖所有怪现象但大多数预编码异常归根到底都可以往两个方向上归因一个是反馈是否准确及时另一个是基站侧是否合理使用了反馈。顺着这两条线查基本不会跑偏。5.3 我踩过的几个坑和绕坑技巧第一颗“地雷”把PMI上报间隔当成越小越好。有一次处理下行吞吐异常我把UE的CQI/PMI上报周期配置调得很短想让反馈更实时结果发现吞吐反而下降了。原因是上报频率增加后物理上行控制信道的开销增大同时基站调度器对高频反馈过度敏感PMI频繁切换导致预编码方向不稳定等效信道波动变大。后来把上报周期退回一个合理的折中值加上基站侧开启PMI平滑问题才缓解。第二颗“地雷”在FDD系统里用TDD思维做波束赋形。又一次在某FDD站点优化覆盖有同事希望通过SRS估计信道直接算预编码结果运行一段时间发现效果不稳定甚至比基于码本反馈更差。原因就是FDD频段差异让信道互易性不成立SRS估计出的信道不能直接用于下行。后来改成依赖终端反馈PMI并配合CRS测量来校准空间方向覆盖才算稳住。这里也提醒大家预编码方案选型一定要先看系统是FDD还是TDD再决定采用码本反馈还是互易性预编码。第三颗“地雷”看日志只盯PMI忽略RI和CQI的联动。预编码不是独立变量RI决定PMI搜索的空间维度CQI又依赖预编码后的等效信道。只看PMI不看其他两个往往会对告警和统计表做出错误判断。所以我现在看任何预编码相关的问题习惯把RI/PMI/CQI三个值一起画时间轴观察联动关系而不是单独看某个指标。第四颗“地雷”忽略DMRS端口的功率补偿。在基于DMRS的传输里如果多个DMRS端口被同时使用发射总功率是固定的单个端口功率会被均分这时候高层“每端口功率”参数配置如果还按单端口满功率来算会给终端一个偏乐观的信道质量预期导致BLER走高。这类问题不好直接看到只能通过比对PDSCH端口数和参考信号功率配置来查。5.4 最后再分享一个排查技巧在实际排查预编码异常时我最后几乎都会做一步验证人为切换到开环模式做对照测试。如果同一用户同一位置换到TM3之后吞吐率反而稳定且更高那就说明闭环预编码的反馈链路确实存在问题要么是PMI抖动太厉害要么是基站侧的调度匹配不及时。如果开环模式还不如闭环那就得回到信道本身去找原因比如SINR太低、多径时延太大。这个方法不需要高端工具一台支持手动配模的测试终端和一个能改传输模式的测试脚本就够了尤其在区分“预编码算法问题”和“无线环境问题”时特别管用。我这次在写整个4G LTE协议分析系列时也一直把“可验证性”放在很重要的位置因为协议本身再漂亮最终都要过现场实测这一关。预编码这个主题看起来数学味道重但真正落地时考验的还是对整个反馈链路、调度机制和无线信道的综合理解。