第四章 空口资源分配：OFDMA资源单元分配、MU-MIMO用户配对、空间流分配
好，咱们进入第四章。这一章讲的是空口资源分配，说白了就是怎么把WiFi的“路”分给多个用户，让大家都能跑起来还不撞车。
我个人习惯把空口资源分配分成三个层面来看：频域、空域和空间流。对应到技术术语就是OFDMA资源单元分配、MU-MIMO用户配对、以及空间流分配。这三个东西是WiFi 6和WiFi 7多站点并发性能的核心。
4.1 OFDMA资源单元分配
OFDMA，全称是正交频分多址。你想想看，以前的WiFi一次只能服务一个用户，就像一条单车道。OFDMA相当于把这条车道分成多个小车道，每个用户走自己的道。
在WiFi芯片里，资源单元（RU）就是这些小车道。一个20MHz的信道，可以分成9个26-tone的RU，或者4个52-tone的RU，等等。具体怎么分，取决于AP的调度策略。
核心要点：RU分配的核心是“粒度”和“效率”的平衡。RU越小，能服务的用户越多，但每个用户的吞吐量也越小。RU越大，单个用户吞吐量高，但能服务的用户数少。
我在项目中遇到过一个问题：某个客户反馈，他们的AP在密集场景下，小包业务（比如IoT传感器上报）延迟特别高。我查了一下，发现RU分配策略太死板了，总是给每个用户分配固定的RU大小。后来我改成了动态RU分配，根据业务类型和信道质量来调整。
举个例子，对于小包业务，我倾向于用26-tone或52-tone的RU，这样一次可以服务更多用户。对于视频流这种大包业务，用106-tone或242-tone的RU更合适。
| RU类型 | 子载波数 | 典型应用场景 | 我建议的分配策略 |
|---|---|---|---|
| 26-tone RU | 26 | IoT小包、控制信令 | 优先分配给低速率、小包用户 |
| 52-tone RU | 52 | 语音、小文件传输 | 中等优先级，兼顾用户数和速率 |
| 106-tone RU | 106 | 视频流、网页浏览 | 分配给中高速率用户 |
| 242-tone RU | 242 | 大文件下载、高吞吐场景 | 保留给高优先级或高吞吐用户 |
避坑指南：我曾经在RU分配时忽略了“保护间隔”的影响。不同RU之间需要留出保护子载波，否则会互相干扰。特别是当RU大小不一致时，保护间隔的配置要格外小心。
4.2 MU-MIMO用户配对
MU-MIMO，多用户多输入多输出。这个技术允许AP同时向多个用户发送数据，利用空间维度来提升容量。
但MU-MIMO不是随便把用户凑一起就能用的。用户配对是关键。配对不好，不仅没有增益，反而会互相干扰，导致性能下降。
我总结了几条用户配对的原则：
- 信道正交性：两个用户的信道向量越正交，配对效果越好。说白了就是他们在空间上“分得开”。
- 信噪比均衡：配对用户的信噪比不能差太多。一个高信噪比用户配一个低信噪比用户，低信噪比用户会拖累整体性能。
- 业务类型匹配：尽量把相同或相似业务类型的用户配对在一起。比如两个视频流用户配对，比一个视频流配一个IoT用户效果好。
嗯，这里要注意。MU-MIMO的用户配对算法，在芯片实现上通常有两种：基于码本的配对和基于Sounding的配对。
基于码本的配对，简单粗暴，AP根据用户上报的码本信息直接配对。优点是计算量小，缺点是精度有限。基于Sounding的配对，AP先发送探测帧，测量每个用户的信道状态信息，然后根据这些信息做配对。精度高，但开销也大。
我个人习惯在芯片设计时，把这两种方式都支持。默认用基于Sounding的配对，当信道变化快或者用户数多时，切换到基于码本的配对来降低开销。
警告：MU-MIMO用户配对时，千万不要忽略“用户间干扰”的消除。在芯片的基带处理中，必须要有干扰消除模块，否则配对增益会被干扰吃掉。我曾经见过一个方案，配对算法做得很好，但干扰消除没做好，最终性能还不如单用户MIMO。
4.3 空间流分配
空间流分配，就是决定给每个用户分配多少个空间流。WiFi 6最多支持8个空间流，WiFi 7支持到16个。
空间流分配的核心问题：是给一个用户分配所有流，还是分给多个用户？
答案取决于场景。如果有一个用户离AP很近，信道条件极好，那把所有流都给它，单用户吞吐量最高。如果多个用户都在中等信道条件下，把流分给他们，系统总吞吐量更高。
我建议的分配策略是这样的：
- 先评估每个用户的信道质量：用Sounding结果或者历史数据来估算。
- 计算单用户和多用户的吞吐量：做一个简单的比较。
- 动态调整：每几个传输机会就重新评估一次，因为信道是变化的。
举个例子，假设AP有4个空间流。用户A信道很好，单用户能跑800Mbps。用户B和C信道一般，各能跑200Mbps。如果全给A，总吞吐量800Mbps。如果分给B和C各2个流，总吞吐量可能只有400Mbps。那当然全给A。
但如果用户A只能跑400Mbps，B和C各能跑300Mbps，那分给B和C各2个流，总吞吐量600Mbps，比全给A的400Mbps高。这时候就应该分。
核心公式：空间流分配的目标是最大化系统总吞吐量，或者满足特定用户的QoS要求。没有银弹，必须动态调整。
在芯片实现上，空间流分配通常和MU-MIMO用户配对是联动的。配对完成后，根据配对结果和信道条件，再决定每个用户分配几个流。我习惯把这两个模块放在一起设计，用一个统一的调度器来管理。
最后说一句，空间流分配还有一个容易被忽略的点：接收端的能力。有些老旧设备只支持1个或2个空间流，你给它分配4个流也没用。所以分配前一定要查一下用户的能力集。
小技巧：在芯片的固件中，可以维护一个“用户能力表”，记录每个用户支持的最大空间流数、支持的MCS等级等。这样调度器在做分配时，可以直接查表，不用每次都去解析能力元素。
好了，这一章的内容就这些。OFDMA、MU-MIMO、空间流分配，这三个东西是WiFi多站点并发性能的基石。理解透了，你就能设计出高效的调度算法。下一章我们会讲具体的调度器实现，到时候会结合代码来演示。