Wi-Fi 6/7特性：MU-MIMO与OFDMA技术在路由器固件中的调度算法实现与吞吐量测试

在智能家居与高密度办公场景下，Wi-Fi 6/7的MU-MIMO（多用户多输入多输出）与OFDMA（正交频分多址）技术是提升并发性能的核心。它们将传统的“竞争信道”模式转变为“AP集中调度”模式，而调度算法的优劣直接决定了路由器的实际吞吐量与延迟表现。本文将深入解析这两项技术在路由器固件中的实现逻辑，并提供实测对比方案。

一、技术原理：空间与频率的二维切割

MU-MIMO与OFDMA并非替代关系，而是互补的二维资源切割技术：

- MU-MIMO（空间维）：利用多根天线（如4×4）的空间分集，在同一频率、同一时间服务多个用户。Wi-Fi 6支持下行8用户，Wi-Fi 7扩展至16用户。

- OFDMA（频率维）：将整个信道带宽（如20MHz）划分为多个资源单元（RU）（如26-tone、52-tone），允许多个用户在同一时间占用不同的频率子载波并行传输。

在实际传输中，AP可以同时使用MU-MIMO和OFDMA：先按RU分配频率资源，再在同一个RU内利用空间流服务多个用户。

二、固件调度算法：从标准到代码

路由器固件（如基于Linux的OpenWrt或厂商SDK）中的调度器，核心任务是决定“在哪个时刻、将哪个RU/空间流分配给哪个用户”。

2.1 OFDMA RU分配算法（伪代码示例）

RU分配是一个典型的组合优化问题。固件需要根据STA（站点）的缓冲区状态（Buffer Status）、信道质量（CQI）和QoS优先级进行动态决策。

# 简化的OFDMA调度器核心逻辑（Python伪代码）

class OFDMAScheduler:

   def __init__(self, total_tones=234):  # 20MHz有效子载波约234个

       self.total_tones = total_tones

       self.ru_sizes = [26, 52, 106, 242]  # 标准RU尺寸

   def schedule_ru(self, sta_list):

       """根据STA需求分配RU"""

       allocation_plan = []

       remaining_tones = self.total_tones

       # 按业务优先级排序（如VOICE > VIDEO > BEST_EFFORT）

       sorted_stas = sorted(sta_list, key=lambda x: x.priority, reverse=True)

       for sta in sorted_stas:

           if remaining_tones <= 0:

               break

           # 根据STA的流量大小和信道质量选择最合适的RU尺寸

           req_ru_size = self._calculate_required_ru(sta.traffic_load, sta.snr)

           for size in self.ru_sizes:

               if size <= remaining_tones and size >= req_ru_size:

                   allocation_plan.append({'sta': sta.mac, 'ru_size': size})

                   remaining_tones -= size

                   break

       return allocation_plan

   def _calculate_required_ru(self, traffic_load, snr):

       """根据业务量和信噪比估算所需RU大小"""

       if traffic_load < 100:  # 小包（如IoT心跳）

           return 26

       elif traffic_load < 500:

           return 52

       else:

           return 106

注：实际商用固件会采用更复杂的启发式算法或强化学习来优化RU分配。

2.2 MU-MIMO用户分组策略

MU-MIMO的关键是用户分组。固件需要筛选出信道空间特性正交（即方向差异大）的用户组，避免波束成形（Beamforming）时的相互干扰。

在Linux的mac80211子系统或厂商驱动中，通常包含以下判断逻辑：

// 简化的MU-MIMO分组检查逻辑（基于Linux无线驱动概念）

bool check_mu_mimo_group(struct sta_info *sta1, struct sta_info *sta2) {

   // 检查设备能力：必须支持VHT/HE并具备波束成形能力

   if (!(sta1->vht_cap.flags & VHT_CAP_MU_BEAMFORMEE_CAPABLE) ||

       !(sta2->vht_cap.flags & VHT_CAP_MU_BEAMFORMEE_CAPABLE))

       return false;

   // 检查空间流是否足够（如4x4 AP可同时服务两个2SS用户）

   if (sta1->max_spatial_streams + sta2->max_spatial_streams > ap_total_streams)

       return false;

   // 检查信道矩阵的互相关性（伪代码），相关性越低越好

   if (calculate_spatial_correlation(sta1->csi, sta2->csi) > CORR_THRESHOLD)

       return false;

   return true;

}

注：实际分组算法会综合考虑SNR、空间流数量及缓冲区状态。

三、吞吐量测试：多用户并发实战

验证MU-MIMO和OFDMA性能，必须在多用户并发场景下进行。单用户测速无法体现技术优势。

3.1 测试环境搭建

角色 设备要求 软件工具

AP (DUT) Wi-Fi 6/7路由器（4×4天线），开启MU-MIMO和OFDMA 固件版本需支持相关特性

STA 1/2/3 至少3台支持Wi-Fi 6的终端（手机/PC） iPerf3, iperf -c server -t 60 -P 4

Server 有线端性能服务器 iPerf3 Server

3.2 测试场景与预期结果

1.  SU-MIMO基准测试：仅1台STA进行iPerf TCP下行测速，记录吞吐量（如600 Mbps）。

2.  MU-MIMO并发测试：3台STA同时启动iPerf下行。若MU-MIMO生效，总吞吐量应接近SU-MIMO的2-3倍（如1.4 Gbps），且单用户速率不应剧烈下跌。

3.  OFDMA小包测试：使用ping -f或UDP小包（如64字节）测试多设备并发时的延迟。开启OFDMA后，平均延迟应显著低于关闭状态（理想情况下降低60%以上）。

3.3 关键指标监控

在Linux路由器上，可通过iw命令监控OFDMA和MU-MIMO状态：

# 查看当前连接的MU-MIMO和OFDMA能力

iw dev wlan0 station dump | grep -E "(rx.*mu-mimo|ofdma)"

# 监控空口时间利用率和RU分配统计（依赖驱动支持）

cat /sys/kernel/debug/ieee80211/phy0/ath10k/ru_alloc_stats

四、性能优化与排错

• MU-MIMO失效排查：若并发总吞吐量未提升，需检查终端是否支持MU-MIMO（部分手机仅支持SU），以及AP驱动中的分组算法是否过于保守。

- OFDMA动态调整：在高密度IoT场景，固件应倾向于分配更多26-tone RU；在下载场景，则合并为106/242-tone RU给单用户。

五、结语

MU-MIMO与OFDMA是Wi-Fi 6/7提升容量的“左右手”。在路由器固件中，OFDMA调度器负责精细的频率资源切割，而MU-MIMO分组器负责空间维度的复用。开发者需在驱动层实现高效的用户选择与RU分配算法，并通过多用户并发测试（而非单用户跑分）来验证真实性能。只有软硬件协同优化，才能在高密度场景下实现“低延迟、高吞吐”的承诺。