Wi-Fi 7 Multi-Link Operation (MLO) Simulator

A Wi-Fi 7 access point and client can use 2.4, 5 and 6 GHz as one connection. How much that helps depends on what the client's radios can do. Compare MLSR, eMLSR, MLMR-STR and MLMR-NSTR on the same busy channels.

One connection, several links

With Multi-Link Operation, a Wi-Fi 7 access point (an AP MLD, multi-link device) runs one AP on each band, and a Wi-Fi 7 client (a non-AP MLD) associates once to all of them. Data can then go over whichever link is free. What the client can actually do depends on its hardware:

MLSR: one radio, one link at a time. eMLSR: listens on several links, then moves all its antennas to whichever link the AP grabs first. MLMR-STR: one radio per link, sending and receiving on all of them at once. MLMR-NSTR: several radios, but links too close in frequency can't send on one while receiving on the other.

Client mode

Traffic for our client

Other traffic on each channel

2.4 GHz: other traffic wins 5 GHz: other traffic wins 6 GHz: other traffic wins

Timeline

Window start

Other traffic: channel busy, our AP must wait Downlink: AP → our client Uplink: our client → AP Block Ack MU-RTS from the AP (+ padding), or RTS from the client CTS

Client strip under each link: listening receiving transmitting blind: transmitting on the partner link switching antennas not on this link

What triggers the switch

All four modes on the same channels

The same congestion settings, run for 1 second in each mode. Throughput is this one client's data, downlink plus uplink. A gap is a time when nothing moved in a direction, which is what a video call or game feels; 99% of gaps are shorter than the value shown. Small differences between modes change from run to run; try “New random run”.

Side by side

	MLSR	eMLSR	MLMR-STR	MLMR-NSTR
Client radios	1	1 main radio; its antenna chains can listen on different links	1 per link	1 per link
Links listening at once	1	All links in its eMLSR set (1 chain each)	All	All
Links carrying data at once	1	1 (with all chains)	All, fully independent	All, but frames on close links must end together
When the client transmits	Contends on its one link	Wins any link it's listening on, then moves its chains there; the AP can't reach it on the others meanwhile	On any link, any time, even while receiving on another	Blind on the partner link while transmitting; starts on both together when it can
Latency benefit	Little: stuck when its link is busy	Large: uses whichever link frees up first	Largest	About the same as STR
Throughput benefit	None over a single link	Small: one link at a time, plus switching overhead	Adds up the links	Adds up the links, minus alignment losses
Typical devices	Low-cost and IoT devices	Most Wi-Fi 7 phones	APs, some laptops and routers	Clients whose links sit close together, such as upper 5 GHz and 6 GHz

Inside an MLD: upper and lower MAC

MLO needs each multi-link device to be one device and several links at the same time. 802.11be does this by splitting the MAC in two: one upper MAC for the whole MLD, and one lower MAC per link. The standard (IEEE 802.11be-2024, 5.1.5.1a) says the split models the functions; it doesn't say where a product must implement each one. Here one video flow's frames 1–4 go down over three links, arrive out of order, and are put back in order.

Upper MAC: one per MLD

One identity: a single MLD MAC address towards the network and apps. To the switch and DHCP it's one device.
One authentication, association and security setup for all links. Individually addressed frames are encrypted and decrypted here, with one pairwise key (PTK) for all links, and get their sequence and packet numbers here too, so a frame can go out on any link. Group keys (GTK, IGTK, BIGTK) are distributed here but kept per link.
One Block Ack session per traffic ID across all links, with one sequence-number space, so frames of one flow can use different links.
Reordering: frames that arrive out of order over different links are put back in sequence before being passed up.
Link selection: decides which link each frame uses, within the TID-to-link mapping (which traffic may use which links).
Power save buffering on the AP MLD: frames for a client that is dozing wait here, whichever link will deliver them.

On the AP, each link's affiliated AP also keeps its own small upper MAC for that link only: its Beacon frames, group-addressed frames and group keys, and any legacy (non-MLD) clients.

Lower MAC: one per link

Channel access on its own channel: carrier sense, NAV and EDCA backoff, with that link's own EDCA parameters. Each link contends independently.
Link addressing: its own link MAC address (on the AP, the link's BSSID), used to filter which frames it accepts.
Link-level control exchanges: RTS/CTS, ACKs and Block Acks, NDPs. The Block Ack scoreboard is kept together with the upper MAC.
Power save state and mode of that link: each link can be awake or dozing separately.
Hands frames up to the upper MAC, which does the reordering.

Without the shared upper MAC, a tri-band client would be three separate stations with three associations, three sets of keys and three sequence spaces, unable to spread one flow over links or move it seamlessly: roughly what multi-band devices did before Wi-Fi 7. Without separate lower MACs, links couldn't contend independently. The modes above don't change this split; they only change how many lower MACs can be active at once (all of them for STR, in step for NSTR, one at a time for eMLSR and MLSR). A legacy client just associates with one of the AP's per-link APs as a normal BSS and never sees the upper MAC.

Notes and simplifications

Links: 2.4 GHz at 20 MHz (286.8 Mbps), 5 GHz at 80 MHz (1,201 Mbps) and 6 GHz at 160 MHz (2,402 Mbps): 802.11be MCS 11, 2 spatial streams, 0.8 µs guard interval, as if the client were close to the AP.
Client hardware: "2×2" or "3×3" describes antenna chains, and so streams on one link; it doesn't say how many bands a client can use at once. MLSR follows one link with all its chains; eMLSR splits its chains to listen on several links, then puts them all on one to exchange data; MLMR needs chains working on every link at the same moment. To keep the modes comparable, this simulator gives the client 2 streams on every link, so its MLMR-STR and MLMR-NSTR client would need 6 receive chains running at once, more than a typical phone or laptop has. Real MLMR clients often have 1 stream on some links (for example 2 on 6 GHz and 1 on 2.4 GHz), so their throughput is lower than shown; the timing rules (who can transmit when, and what must line up) are unaffected.
Traffic: depending on the setting, the AP always has downlink data for this client, the client always has uplink data, or both. When both want the same link, each has an even chance of winning it. Each data frame is 1 ms on air (about 40 µs of it preamble), followed by SIFS (16 µs) and a Block Ack (32 µs).
Contention: before every attempt a link waits AIFS (43 µs) plus a random backoff of 0–15 slots of 9 µs. Other traffic (grey) is anything our AP has to wait for: neighbouring networks on the same channel and the AP's other clients, since only one client is followed here. Each slider sets the chance that other traffic wins a contention round; its transmission then lasts 0.3–2.5 ms, so the time the channel is actually busy (shown under the sliders) is higher than the slider value. When the AP has nothing to send on a link, the link stays idle for 100 µs and tries again. Real contention, retries and rate changes are left out.
eMLSR: the AP opens each exchange with an initial control frame (MU-RTS, 64 µs at 6 Mbps) followed by padding as long as the client's padding delay: time for the client to move its antenna chains to that link. The client answers with CTS (44 µs). After the exchange it needs a transition delay before it listens on all links again. 802.11be allows 0–256 µs for both; the client advertises its values.
Uplink in eMLSR: the client contends on every link it's listening on. When it wins one, it opens with RTS using the chain already there, and moves its other chain over during the RTS/CTS exchange (it waits longer if its switching time, the padding delay here, is longer). The standard allows this: any of the client's links in its eMLSR set may start a frame exchange with the AP MLD, using normal EDCA channel access and without an initial Control frame (IEEE 802.11be-2024, 35.3.17). How the client covers the time to move its chains is left to implementations; opening with RTS/CTS is a common way.
Uplink in MLMR-NSTR: while the client transmits on 5 or 6 GHz, its own signal blinds its receiver on the other. The AP can't send to it there, and when both links are idle the client starts its uplink on both at once (the standard's optional start-time-sync channel access, 35.3.16.6). After being blind, a client may have missed reservations on that link; 802.11be's medium synchronization delay makes it cautious there for a while. That is not simulated.
eMLSR links: Wi-Fi 7 phones typically run eMLSR on 5 and 6 GHz, which is the default here. Choose “All three” to see why adding 2.4 GHz can hurt: the client takes whichever link is free first, even when it's the slowest.
Terminology: IEEE 802.11be-2024 defines a single-radio non-AP MLD (transmits or receives on one link at a time), a multi-radio non-AP MLD, EMLSR and EMLMR operation, and STR or NSTR link pairs. "MLSR", "MLMR-STR" and "MLMR-NSTR" as used here are the common industry shorthand for a single-radio MLD and a multi-radio MLD whose links are STR or NSTR pairs. EMLMR (a multi-radio client moving its spatial streams between links) is in the standard but not modelled here. The eMLSR padding delay (0, 32, 64, 128 or 256 µs) and transition delay (0, 16, 32, 64, 128 or 256 µs) choices are the values the standard allows.
MLSR stays on one link. It could move to another, but it can't hear the other links while it's away, so switching is slow and rare in practice.
MLMR-NSTR: here 5 GHz and 6 GHz form the non-STR pair, and 2.4 GHz is STR with both. When the AP sends to the client on both links of the pair at once and the frames ask for an immediate response, it must make them end within 8 µs of each other (35.3.16.5), so the client never transmits a Block Ack on one link while it is still receiving on the other. Only the end times have to line up, not the start times. In this simulation the AP also only joins a frame already on the other link if the remaining time is at least 300 µs, a simplification.
Throughput counts only this client's data, without MAC overhead or retries. Only downlink is shown.