Multi-Link Operation (MLO) em Wi-Fi 7: Como Funciona e Porque é Importante

PODCAST SCRIPT: Multi-Link Operation in Wi-Fi 7 — How It Works and Why It Matters Approximate runtime: 10 minutes | Voice: UK English, senior consultant tone --- SEGMENT 1: INTRODUCTION & CONTEXT (approx. 1 minute) Welcome back. I'm going to cut straight to it today, because if you're designing or procuring wireless infrastructure in 2025 or 2026, there is one Wi-Fi 7 feature that genuinely changes the engineering calculus — and that's Multi-Link Operation, or MLO. We've had band steering since Wi-Fi 5. We've had MU-MIMO, OFDMA, target wake time. All useful. But MLO is architecturally different. It's not a refinement — it's a fundamental change in how a client device and an access point negotiate and maintain a wireless connection. In this session, I want to give you a clear-eyed view of what MLO actually is under the hood, how the three operating modes — STR, NSTR, and EMLSR — differ in practice, which client devices support it today, and where it genuinely delivers measurable latency improvements. I'll also flag the deployment pitfalls that are already catching teams out in early Wi-Fi 7 rollouts. Let's get into it. --- SEGMENT 2: TECHNICAL DEEP-DIVE (approx. 5 minutes) So, what is Multi-Link Operation? At its core, MLO is defined in the IEEE 802.11be amendment — that's the formal standard underpinning Wi-Fi 7. It allows a single logical connection between a client device and an access point to operate simultaneously across multiple frequency bands and channels. Not sequentially. Simultaneously. To understand why that matters, think about what band steering actually does. With band steering, your controller looks at a client device and decides: this device should be on 5 GHz rather than 2.4 GHz, and it nudges it across. The device has one active radio link at a time. It's on one band. If that band gets congested, you steer it again. It's reactive, it's disruptive, and there's always a brief disconnection event — even if it's sub-second. MLO is fundamentally different. The client device and the AP establish what the standard calls a Multi-Link Device, or MLD, relationship. Within that relationship, they negotiate multiple simultaneous links — say, 5 GHz and 6 GHz at the same time. The MAC layer aggregates these links. Traffic can be split across them, load-balanced across them, or one link can serve as a hot standby while the other carries the primary load. No steering event. No disconnection. The link adaptation happens below the application layer. Now, there are three modes of MLO operation, and this is where it gets nuanced. The first is STR — Simultaneous Transmit and Receive. This is the gold standard. The client device has sufficient radio isolation between its antennas that it can transmit on one link while simultaneously receiving on another, without self-interference. The result is true parallel operation: you get aggregated throughput and, critically, the lowest achievable latency, because the scheduler can always find a clear path on at least one link. For XR workloads — extended reality, spatial computing — this is the mode you want. Sub-5 millisecond round-trip latency becomes achievable in a well-designed STR deployment. The second mode is NSTR — Non-Simultaneous Transmit and Receive. Here, the device doesn't have enough antenna isolation to transmit and receive at the same time across its links. So the MAC layer has to coordinate — it can't overlap transmit and receive windows. You still get multi-link benefits: better reliability, some latency improvement, and the ability to load-balance. But you lose the full parallelism of STR. Most of the first-generation Wi-Fi 7 client chipsets that shipped in 2024 — including several laptop and smartphone implementations — operate in NSTR mode, not STR. That's an important caveat when you're setting expectations with stakeholders. The third mode is EMLSR — Enhanced Multi-Link Single Radio. This is the power-efficiency play. The device has a single radio that can switch between links very rapidly — we're talking microsecond-level switching times. It listens on multiple links simultaneously using a low-power monitor mode, and when it detects an incoming frame, it switches its active radio to that link to receive it. EMLSR is designed for IoT devices, wearables, and battery-constrained endpoints where you want the multi-link resilience benefits without the power draw of running multiple radios continuously. The latency profile is better than single-link Wi-Fi 6, but not as good as full STR. Now, a critical architectural point: MLO requires both the AP and the client to support it. The AP side is largely sorted — all the major enterprise AP vendors shipping Wi-Fi 7 hardware in 2025 support MLO. The client side is where you need to do your homework. As of early 2025, confirmed MLO-capable client devices include the Qualcomm Snapdragon 8 Gen 3 platform — which powers a number of Android flagships — the MediaTek Filogic 380 and 680 chipsets, and Intel's BE200 Wi-Fi 7 module, which is appearing in premium laptops. Apple's Wi-Fi 7 implementation in the iPhone 15 Pro and later devices supports MLO, though Apple's specific mode implementation has some nuances around EMLSR behaviour. The honest picture is that full STR support in client devices is still maturing. You'll see it in purpose-built XR headsets and high-end laptops before you see it broadly in commodity smartphones. One more thing on the infrastructure side: MLO requires your AP to present what's called a Multi-Link Element in its beacon frames, and the BSS — the Basic Service Set — needs to be configured as a Multi-Link BSS. This is not automatic when you upgrade firmware. Check your vendor's configuration guide explicitly for MLD setup, because some vendors ship with MLO disabled by default pending further interoperability testing. --- SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS & PITFALLS (approx. 2 minutes) Let me give you the practical deployment guidance. First: audit your client estate before you commit to an MLO-first design. If 80% of your devices are NSTR-capable rather than STR-capable, your latency gains will be meaningful but not transformative. Set expectations accordingly. Second: the 6 GHz band is essential for MLO to deliver its best results. The 6 GHz band — introduced with Wi-Fi 6E — provides clean, uncongested spectrum with 320 MHz channels. Pairing a 5 GHz link with a 6 GHz link in an STR configuration is where you get the headline latency numbers. If your venue hasn't deployed 6 GHz-capable APs, MLO will still work on 2.4 and 5 GHz, but you're leaving performance on the table. Third: backhaul matters more than ever. An AP delivering sub-5 millisecond wireless latency is pointless if it's sitting behind a 100 Mbps uplink with 15 milliseconds of jitter. MLO shifts the bottleneck downstream. Make sure your switching infrastructure and WAN connectivity are sized appropriately. Fourth: watch for the hidden NSTR coordination overhead. In dense deployments — think a conference centre with 50 APs in a single hall — NSTR devices generate additional management frame overhead because of the link coordination signalling. This is manageable with proper channel planning and EDCA parameter tuning, but it's a real consideration in high-density environments. Fifth: for hospitality and venue deployments specifically, MLO's reliability benefits are arguably more valuable than the raw latency gains. A hotel guest's video call staying connected seamlessly as they move between the lobby and their room — without a steering event causing a one-second freeze — is a tangible guest experience improvement. That's a story you can tell to a general manager, not just a network architect. --- SEGMENT 4: RAPID-FIRE Q&A (approx. 1 minute) Let me run through a few questions I get asked regularly. "Does MLO replace band steering?" No — band steering still applies to legacy clients that don't support MLO. You'll run both simultaneously for years. MLO is additive. "Can I enable MLO on existing Wi-Fi 6E hardware?" No. MLO is an 802.11be feature. It requires Wi-Fi 7 hardware on both ends. "Does MLO help with congestion, or just latency?" Both. The ability to spread traffic across multiple links reduces per-link congestion, which in turn reduces queuing latency. It's not a magic fix for a fundamentally under-provisioned network, but it makes better use of available spectrum. "What about security?" MLO operates above the PHY layer. WPA3 applies normally. Each link within an MLD is independently authenticated and encrypted. There's no regression in security posture. --- SEGMENT 5: SUMMARY & NEXT STEPS (approx. 1 minute) To wrap up: Multi-Link Operation is the most architecturally significant advancement in Wi-Fi since OFDMA. It moves wireless networking from a single-link, band-steered model to a true multi-path, always-on aggregated link model. The three modes — STR for maximum performance, NSTR for broader device compatibility, and EMLSR for power-constrained endpoints — give you a framework for understanding what your specific client estate will actually experience. The immediate action items: first, check your AP vendor's roadmap for MLD configuration support and ensure your firmware is current. Second, audit your client device estate for Wi-Fi 7 chipset support — specifically whether they're STR or NSTR capable. Third, if you're designing a new venue deployment or a refresh, prioritise 6 GHz coverage as the foundation for MLO to deliver its best results. If you're working on a deployment and want to understand how guest WiFi analytics and network intelligence layer on top of a Wi-Fi 7 infrastructure, that's exactly the kind of architecture conversation worth having. The network data that MLO generates — per-link utilisation, roaming events, latency telemetry — is rich input for a properly instrumented WiFi analytics platform. Thanks for listening. I'll see you in the next one.