NETWORK TESTING

Kiểm thử Wi-Fi OFDMA, MU-MIMO và airtime fairness

6/8/2026 · 16 phút

Access point phục vụ nhiều Wi-Fi client với OFDMA resource units và MU-MIMO
Mục lục bài viết 9 phần

OFDMA và MU-MIMO có thể tăng hiệu quả vô tuyến, nhưng kết quả phụ thuộc capability client, scheduler, RSSI, channel utilization và traffic direction. Bài viết đo cả tổng capacity lẫn fairness và tail latency của từng nhóm client.

ĐỌC NHANH

Bài viết giúp bạn

  • OFDMA và MU-MIMO cần chứng minh gì?
  • Topology và môi trường RF
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

OFDMA và MU-MIMO cần chứng minh gì?

#

OFDMA chia channel thành resource unit để phục vụ nhiều station; MU-MIMO truyền nhiều spatial stream cho nhiều client khi điều kiện phù hợp. Việc AP/client quảng bá capability không chứng minh scheduler sử dụng hiệu quả trong workload thực.

Câu hỏi nghiệm thu gồm: tổng goodput tăng hay không; p99 latency của flow nhỏ có được bảo vệ; client RSSI thấp có chiếm quá nhiều airtime; uplink/downlink có công bằng; và feature có ổn định khi client mix thay đổi.

02

Topology và môi trường RF

#

Dùng AP under test, controller nếu có, client emulator hoặc client thật, wired server và RF chamber/attenuator khi có thể. Tách management path khỏi data path; đo wired reference trước. Ghi channel, bandwidth, power, antenna, khoảng cách/attenuation và nguồn nhiễu.

Nếu đo trong văn phòng, quét spectrum và ghi baseline trước mỗi lượt. Kết quả RF mở khó so sánh giữa ngày; cần chạy lặp, lưu channel utilization và đánh dấu interference event.

Topology Wi-Fi đa client với điều kiện RF và traffic profile khác nhau
Topology Wi-Fi đa client với điều kiện RF và traffic profile khác nhau
03

Biến số phải kiểm soát

#

Ghi AP/controller firmware, client chipset/driver, PHY standard, MCS, NSS, channel width, security, band, power-save, roaming và scheduler option. Khóa server capacity, TCP window/QUIC version và traffic mix.

  • Biến: Client count · Mức thử: 1, 8, 32, mục tiêu · Rủi ro: Scheduler/association scale
  • Biến: RSSI · Mức thử: gần, trung bình, edge · Rủi ro: Low-rate airtime cost
  • Biến: Direction · Mức thử: DL, UL, bidirectional · Rủi ro: Khác scheduler behavior
  • Biến: Payload · Mức thử: flow nhỏ, bulk, voice · Rủi ro: Tail latency bị che
  • Biến: Capability · Mức thử: legacy/mixed/new · Rủi ro: Feature fallback
  • Biến: Channel load · Mức thử: sạch/nhiễu có kiểm soát · Rủi ro: Retry và contention
04

KPI và bằng chứng

#

KPI gồm aggregate/per-client throughput, application goodput, p50/p95/p99 latency, jitter, packet loss, retry, MCS/NSS distribution, channel utilization, airtime per client và fairness index. Theo dõi association/authentication failure và disconnect.

Counter AP phải đối soát với generator và capture/monitor hợp lệ. Pass/fail nên có floor cho client yếu và SLO cho traffic nhạy latency, không chỉ tổng Mbps. Nếu dùng Jain’s fairness index, ghi input là throughput hay airtime.

05

Ma trận traffic/client

#
  • Profile: 1 client gần · Điều cần chứng minh: PHY/baseline sạch · KPI chính: goodput, retry
  • Profile: N client đồng capability · Điều cần chứng minh: Scheduler scale · KPI chính: aggregate + fairness
  • Profile: Mixed legacy/new · Điều cần chứng minh: Fallback không phá SLO · KPI chính: airtime, p99
  • Profile: Edge client + near client · Điều cần chứng minh: Low-rate impact · KPI chính: per-client floor
  • Profile: Voice + bulk · Điều cần chứng minh: Flow nhỏ được bảo vệ · KPI chính: jitter, p99, loss
  • Profile: UL burst + DL steady · Điều cần chứng minh: Direction fairness · KPI chính: queue, latency
06

Test plan theo từng pha

#
  • Quét RF, chọn channel và đo wired baseline.
  • ác nhận capability/association từng client.
  • Chạy một client theo từng direction.
  • Tăng client đồng capability theo bậc.
  • Thêm legacy/low-RSSI client từng nhóm.
  • Chạy voice/API flow nhỏ cùng bulk transfer.
  • Tạo UL burst và DL steady theo profile.
  • Bật/tắt OFDMA/MU-MIMO nếu nền tảng cho phép A/B.
  • Lặp mỗi case, lưu RF/counter/generator result.
  • Kiểm recovery sau AP restart/channel change.
Phân bố airtime, throughput và độ trễ giữa các nhóm Wi-Fi client
Phân bố airtime, throughput và độ trễ giữa các nhóm Wi-Fi client
07

Checklist nghiệm thu

#
  • Firmware/chipset/driver đã ghi.
  • RF baseline và interference được lưu.
  • Wired server không là bottleneck.
  • Đã thử UL, DL và bidirectional.
  • Mixed legacy/new và RSSI edge đã thử.
  • Có flow nhỏ nhạy latency cạnh bulk.
  • Báo per-client percentile/fairness.
  • Retry/MCS/airtime đối soát được.
  • Không suy capability thành feature usage.
  • Kết quả có ít nhất ba lượt lặp.
08

Giới hạn kết luận

#

Wi-Fi phụ thuộc mạnh vào RF, client implementation và scheduler proprietary. Một laptop không đại diện toàn bộ fleet; emulator không luôn tái tạo power-save/driver behavior. Kết quả chamber khác văn phòng thực.

Tổng throughput cao có thể che starvation. Ngược lại, fairness tuyệt đối có thể giảm capacity. Tiêu chí phải theo application/SLO và mật độ client, không lấy một chỉ số tối ưu duy nhất.

09

Khái niệm cần nhớ

#
  • OFDMA: Chia channel thành resource unit cho nhiều client.
  • MU-MIMO: Truyền spatial stream tới nhiều client.
  • Airtime fairness: Cách phân bổ thời gian sử dụng kênh.
  • MCS/NSS: Điều chế-mã hóa và số spatial stream.
  • Retry rate: Tỷ lệ frame phải truyền lại.
  • Jain’s index: Chỉ số định lượng mức công bằng.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

DUT / SUT
Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
Steady state
Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
Pass / fail
Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo3 nguồn

Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.

Nguyên tắc biên tập

NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật