
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.
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
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.
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.

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
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.
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
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.

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.
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.
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.
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.
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.
