MLO en Wi-Fi 7: qué negocia cada cliente y qué pasa cuando cae un enlace

Medición en campo sobre un hAP be³ Media de MikroTik

Tu red Wi-Fi 7 funciona. Y aun así hay algo que no puedes comprobar.

Tienes un equipo Wi-Fi 7 funcionando. Los clientes tienen internet. Nadie llama a soporte. Y sin embargo algo no cuadra: la ficha habla de MLO, de enlaces múltiples, de continuidad. Pero no tienes forma de saber si eso está ocurriendo de verdad en tu red.

Esa sensación tiene nombre. Y tiene método.

Luis Aguilar, de Ekoinos, compró un hAP be³ Media de MikroTik para preparar un curso. Pasó un día entero creyendo que había configurado algo mal. Revisando. Descartando. Hasta llegar a la conclusión que nadie quiere tener: no era la configuración.

Lo que siguió fue una sesión de medición sobre la función que define a Wi-Fi 7 — y sobre lo que ocurre cuando se la pone a prueba.

Por qué esto importa ahora

La Wi-Fi Alliance proyecta 1.100 millones de dispositivos Wi-Fi 7 para 2026. Los envíos de puntos de acceso crecieron más del 210 % en un año, según IDC.

Pero en febrero de 2026, RTINGS auditó 25 routers vendidos como Wi-Fi 7 y encontró que solo 3 tenían certificación Wi-Fi CERTIFIED 7. Ninguno entregaba MLO simultáneo real.

La adopción va muy por delante de la verificación. Y MLO es justo la función más difícil de verificar de todas.

Qué es MLO, y qué no es

MLO —Multi-Link Operation— es la función definitoria de 802.11be. Y arrastra una confusión que conviene desmontar desde el principio.

MLO no suma velocidad. MLO suma continuidad.

En Wi-Fi 6E y anteriores, cada banda es una asociación independiente con su propia dirección MAC. Cambiar de 5 a 6 GHz significa reasociarse: reautenticación, nuevo DHCP, corte perceptible.

Con MLO el cliente se asocia una sola vez a una entidad lógica —el MLD, Multi-Link Device— que agrupa varios radios. La capa MAC se parte en dos: la U-MAC gestiona la asociación, las claves y el cifrado, y es común a todos los enlaces; la L-MAC gestiona el acceso al canal y los beacons de cada banda por separado.

De ahí salen dos consecuencias que explican todo lo demás:

• Cambiar de enlace no reautentica, porque la seguridad vive arriba.
• Todos los enlaces deben anunciar la misma configuración de seguridad, por la misma razón.

No todos los enlaces son iguales

Este es el matiz que casi nadie explica, y que resultó ser la clave de todo lo que medimos después.

Dentro de un MLD existe un enlace de asociación —aquel por el que se produjo el intercambio de Association Request y Response— y uno o más enlaces de no-asociación, descritos en la misma trama mediante los Per-STA Profiles.

No son intercambiables. El enlace de asociación sostiene la sesión; los demás son alternativas de transporte.

Guarda esa distinción. Vuelve al final del artículo con consecuencias muy concretas.

Los tres modos, y cuál es el que vas a encontrar

Esa asimetría lo explica casi todo: el punto de acceso está obligado a implementar los tres; el cliente solo el primero. El mismo AP entrega experiencias distintas según qué haya decidido implementar el fabricante del dispositivo.

Cómo funciona EMLSR en realidad

Es el modo que soporta la mayoría de la flota actual, y suele explicarse mal.

El cliente no tiene dos radios. Tiene una radio de dos cadenas que reparte o concentra:

1. Escuchando: dedica 1×1 a cada banda. Ambos enlaces vivos, ambos monitoreando.
2. El AP inicia: envía una trama de control MU-RTS por el enlace que elige.
3. El cliente concentra: dedica sus dos cadenas a ese enlace. Pasa a NSS 2 en esa banda y a NSS 0 en la otra.
4. Al terminar el TXOP: vuelve a repartir 1×1 por banda.

Ese NSS 0 en el enlace inactivo es la razón técnica —no metafórica— por la que EMLSR no puede agregar caudal. No hay cadenas disponibles para transmitir en dos sitios a la vez.

El modo que sí suma es STR. Cisco lo midió con una estación Qualcomm FastConnect 7800: 747 Mbps frente a 506 Mbps en 802.11ax, un 47 % más. Existe, pero la adopción en clientes es todavía escasa.

La configuración completa

Cuatro condiciones deben cumplirse simultáneamente para que el MLD se forme. La ausencia silenciosa de cualquiera de ellas es el error de campo más común:

• SSID unificado en todas las bandas afiliadas
• WPA3 en todos los enlaces del MLD
• PMF (Protected Management Frames) en modo required
• Un cliente que soporte MLD

Esta es la configuración operativa del laboratorio:

Consola del RouterOS:

/interface wifi
add configuration.mode=ap disabled=no mac-address=D2:EA:11:3E:DD:C2 \
    mld-name=mld-d0ea113eddc2 name=mld

set [ find default-name=wifi1 ] channel.band=2ghz-be .width=20/40mhz-eC \
    configuration.mode=ap .ssid=wardenclyffe name=wifi1-2GHz-wardenclyffe \
    security.authentication-types=wpa3-psk .management-protection=required

set [ find default-name=wifi2 ] channel.band=5ghz-be .skip-dfs-channels=all \
    .width=20/40/80mhz configuration.mode=ap .ssid=wardenclyffe disabled=no \
    mld-interface=mld name=wifi2-5GHz-wardenclyffe \
    security.authentication-types=wpa3-psk .management-protection=required

set [ find default-name=wifi3 ] channel.band=6ghz-be .frequency=6135 \
    .width=20/40/80/160/320mhz configuration.mode=ap .ssid=wardenclyffe \
    disabled=no mld-interface=mld name=wifi3-6GHz-wardenclyffe \
    security.authentication-types=wpa3-psk .management-protection=required

Cuatro decisiones de esa configuración merecen explicación.

El MLD agrupa 5 y 6 GHz, no las tres bandas. wifi1 mantiene el SSID pero no lleva mld-interface. Hay dos razones: en EMLSR el cliente solo negocia dos enlaces, y no quieres que gaste uno en la banda lenta; y si necesitas compatibilidad WPA2 para dispositivos IoT, 2.4 GHz puede tener un perfil distinto sin romper el MLD.

WPA3 y PMF required en las tres interfaces. No es opcional. Un enlace en modo mixto WPA2/WPA3 no puede convivir en el mismo MLD con otro en WPA3-only, porque la seguridad vive en la U-MAC y debe ser idéntica.

6135 MHz es el canal 37, un PSC (Preferred Scanning Channel). Fuera de los PSC el descubrimiento de la red es más lento o directamente falla.

Falta el country, y es deliberado en laboratorio. En producción es obligatorio configurarlo: sin dominio regulatorio explícito, RouterOS aplica el perfil por defecto y puedes no ver 6 GHz en absoluto. Es el primer punto a revisar si copias esta configuración y la banda no aparece.

Verificación rápida: si /interface wifi registration-table print detail muestra la interfaz mld con dos o más bandas en el campo band, el MLD está formado.

El día de depuración: tres capas, no una

El problema original tenía tres causas encadenadas, y cada una escondía a la siguiente.

Capa 1 — El perfil de seguridad heredado. La configuración inicial tenía wpa2-psk,wpa3-psk con management-protection=allowed. Ambos valores son inválidos en 6 GHz: WPA2 está prohibido en esa banda y PMF debe ser required. El radio acepta la configuración sin protestar, pero nunca emite beacons. Sin mensaje de error. Sin alerta.

Capa 2 — La regla de uniformidad del MLD. Corregido lo anterior, apareció el conflicto estructural: los tres radios estaban afiliados al mismo MLD, con 2.4 y 5 GHz en modo mixto y 6 GHz obligada a WPA3-only. Son mutuamente excluyentes. La tabla de registro lo mostraba con precisión: el cliente se asociaba con mld-interfaces=wifi2-5GHz, wifi1-2GHz — el enlace de 6 GHz simplemente ausente.

Capa 3 — El cliente decidiendo por su cuenta. Con el AP ya emitiendo correctamente en 6135 MHz, el iPhone seguía sin ver la red. La causa no estaba en el AP: Apple determina si puede usar 6 GHz según la ubicación que el propio dispositivo calcula, no según el Country IE del beacon. Donde el regulador no ha liberado la banda, el dispositivo la apaga entera: ni escanea, ni muestra el SSID.

Confirmado después en macOS: la restricción es transversal al ecosistema, no específica de iOS.

Ninguna configuración del AP corrige la tercera capa. Es política de cliente sobre jurisdicción, y está por encima de lo que anuncia tu red.

El banco de pruebas: dos clientes, tres instrumentos

Una vez resuelta la configuración, el entorno se redujo deliberadamente a dos dispositivos que representan dos generaciones:

Dos entradas en la misma tabla, contra el mismo punto de acceso, con comportamientos radicalmente distintos. La columna Band es lo que los separa: BE frente a AX distingue 802.11be de 802.11ax dentro de la misma banda de 6 GHz.

El techo lo pone la flota, no el equipo que instalaste.

El equipo por dentro

El hAP be³ Media tiene tres radios 2×2 con capacidad agregada de 7.538 Mbps en el aire, frente a 5 Gbps de Ethernet hacia la CPU. El aire puede pedir más de lo que entra por cobre.

Y hay un detalle del diagrama de bloques que no aparece en ninguna ficha: las radios de 5 y 6 GHz comparten el mismo chip, conectado a la CPU por un único enlace PCIe 3.0 ×2. La de 2.4 GHz va integrada en el SoC.

Es decir: el MLO de dos enlaces no cruza silicio. Comparte die y bus.

(Nota de nomenclatura: la ficha de MikroTik declara IPQ-5322 y QCM-8083; el diagrama de bloques nombra IPQ5332 y QCN6274; RouterOS reporta ipq5332 hw1.0 y qcn9274 hw2.0, identificadores que coinciden con los del driver ath12k de Qualcomm. Tres fuentes, tres nombres. La única verificable por ti es la del equipo.)

Tres instrumentos, tres límites

Elegir bien qué afirmación sostiene cada instrumento vale más que tener el instrumento caro.

Medición 1: quién negocia qué

La validación cruzada entre AP, cliente y aritmética del estándar confirmó las lecturas con precisión decimal:

• iPhone 16 Pro: 1.921,5 Mbps medidos. Tabla teórica para 160 MHz, NSS 2, MCS 9, GI 800 ns: 1.921,6 Mbps.
• MacBook Air M4: 2.161,0 Mbps medidos. Tabla para MCS 10 en las mismas condiciones: 2.161,8 Mbps. Y wdutil reportó MCS 10 por sí mismo.

Tres fuentes independientes convergiendo en el mismo número. Ese es el protocolo mínimo: la tasa no se cree, se comprueba contra sus propios parámetros.

También aparece aquí un criterio operativo útil: el máximo absoluto a 160 MHz con NSS 2 es 2.882,4 Mbps (MCS 13). Cualquier cliente que supere esa cifra está necesariamente en 320 MHz. Como RouterOS no expone el ancho negociado por cliente, la aritmética es la única vía indirecta para deducirlo.

Medición 2: el espectro como testigo independiente

Las condiciones de RF en 6 GHz eran casi ideales: ocupación de canal del 1 %, piso de ruido en −93 dBm, SNR de 58 dB.

Ese 1 % es el argumento real de la banda de 6 GHz. Sin hornos, sin vecinos, sin cámaras, sin radares. Toda la conversación sobre jitter y calidad de experiencia cambia cuando el medio no está en disputa.

La forma de la ocupación también resultó reveladora: en 6 GHz, energía densa y continua; en 5 GHz, picos aislados sin continuidad. Es la firma que predice EMLSR — un enlace transporta datos, el otro solo gestión y beacons.

Y aquí está el punto que justifica el tercer instrumento. El AP anunciaba un canal de 320 MHz: la cadena 6135/be/eCeeeeeeeeeeeeee/I tiene 16 caracteres tras la banda, uno por subcanal de 20 MHz. El analizador mostró energía únicamente en los 8 primeros — 160 MHz. La mitad superior del bloque, vacía, verificada con barrido ampliado.

La explicación es precisa: el beacon anuncia capacidad, no transmisión. Cada PPDU se emite al ancho que negoció el cliente que la recibe. Ninguno de los clientes podía pedir más de 160 MHz.

El cliente no solo desaprovecha la capacidad: impide que exista.

Sin el analizador, habrías dado por bueno que el enlace corría a 320 MHz porque el AP lo decía.

Medición 3: qué pasa cuando cae un enlace del MLD

Aquí está el hallazgo principal, y no es el que esperábamos.

La pregunta era simple: si MLO promete continuidad, ¿sobrevive la sesión cuando un enlace desaparece? Se montó una transferencia activa con el iPhone 16 Pro asociado en MLO de dos enlaces, y se fue deshabilitando cada radio desde el AP.

El resultado fue radicalmente asimétrico.

Apagando 5 GHz: ~1 ms

Interrupción imperceptible. La transferencia continuó sin corte apreciable, sin reasociación y sin nueva IP. La aplicación no se enteró de que había perdido una banda.

Esto es exactamente lo que promete el estándar. MLO cumple.

Apagando 6 GHz: desconexión

No hubo conmutación. La sesión se cayó.

El cliente no migró al enlace de 5 GHz, que seguía perfectamente operativo. Perdió la asociación por completo y tuvo que reconectarse desde cero.

Por qué la diferencia

La asimetría apunta directamente a la distinción entre enlace de asociación y enlace de no-asociación que veíamos al principio.

Si la asociación se estableció sobre 6 GHz, ese enlace no es un camino más: es el que sostiene la sesión.

• Apagar un enlace secundario deja intacta la asociación, y la conmutación funciona como está diseñada: un milisegundo.
• Apagar el enlace de asociación derriba la entidad completa. No hay nada a lo que conmutar, porque lo que se perdió no fue una banda: fue la sesión.

(La verificación definitiva de cuál era el enlace de asociación requiere captura de tramas sobre el aire. Lo reproducible es el comportamiento; esta es la explicación que mejor encaja con la arquitectura documentada.)

El hallazgo secundario

Al volver a encender el radio apagado, el enlace no se reincorpora al MLD. El cliente sigue operando con menos enlaces de los que tenía hasta que se fuerza una reasociación.

Y hay mecanismo documentado detrás. En el análisis de tramas de Cisco, el controlador identifica la capacidad del cliente leyendo el campo Maximum Number of Simultaneous Links del elemento ML en la Association Request. El conjunto de enlaces se declara una sola vez, al asociarse.

Existe una trama QoS Null que activa el uso de un enlace secundario ya establecido — pero eso no es lo mismo que reincorporar uno que desapareció.

El resultado es un estado silencioso: el cliente tiene internet, la sesión sigue viva, nadie llama a soporte. Y la flota opera degradada sin que ninguna alarma se dispare.

En producción esto ocurre cada vez que reinicias un radio, cambias un canal o actualizas firmware.

La lectura operativa

Las dos conclusiones son accionables y van juntas:

1. MLO entrega continuidad real — pero solo ante la caída de un enlace secundario.
2. La caída del enlace de asociación no está cubierta. Es un corte completo, igual que en Wi-Fi 6E.

Antes de tocar un radio en producción conviene saber cuál de tus bandas sostiene las asociaciones. Y después de tocarlo, forzar la desasociación de la flota para que el MLD se reconstruya completo.

Qué prometer y qué no

Hay cosas que Wi-Fi 7 entrega hoy, medibles y defendibles. Y hay cosas que están en el menú pero que la cocina no sirve todavía.

Lo que puedes prometer:

• Espectro limpio en 6 GHz. 59 canales de 20 MHz y 1.200 MHz totales, frente a 25 canales en 5 GHz y 3 en 2.4 GHz. Solo en 6 GHz caben canales de 320 MHz.
• Continuidad ante la caída de un enlace secundario. Medido: del orden del milisegundo, imperceptible para la aplicación.
• Menor latencia de acceso al medio. Con dos canales bajo observación, el cliente transmite por el que esté libre.
• Una plataforma que mejora por firmware, no un producto terminado.

Lo que no deberías prometer:

• Suma de caudal con EMLSR. No agrega, por diseño.
• Cifras de 320 MHz sin auditar la flota del cliente.
• 6 GHz sin verificar la atribución regulatoria del país y el comportamiento de los dispositivos.
• Inmunidad ante la caída de cualquier radio. La del enlace de asociación desconecta.

Una promesa que el cliente puede verificar y que se cumple vale más que una cifra de folleto que nunca va a ver.

Tres decisiones que separan al que instala del que entiende

1. Sabe cuál es tu enlace de asociación. No todas las bandas del MLD pesan lo mismo. Tocar la equivocada desconecta a la flota entera; tocar la otra es transparente. Esa diferencia no está en ninguna ficha técnica, y solo aparece si la pruebas.

2. Cruza tres instrumentos. La tabla del AP dice lo que se negoció. El cliente dice lo que vio. El espectro dice lo que ocurrió. Ninguno basta solo — y el tercero fue el único que reveló los 160 MHz reales.

3. Vende continuidad, no megabits. EMLSR suma resiliencia, no velocidad. Si esa es tu propuesta de valor tienes evidencia para sostenerla, con el matiz de que la resiliencia tiene un límite y ahora sabes dónde está.

El método, en cuatro comandos

Reproducible hoy sobre cualquier despliegue Wi-Fi 7 activo:

Consola del RouterOS

# 1 · qué canal y ancho está operando el AP
/interface wifi print
#    → columna Current Channel: cuenta las letras × 20 MHz = ancho anunciado

# 2 · qué negoció cada cliente
/interface wifi registration-table print detail
#    → campos band y mld-interfaces

Consola de la MAC

# 3 · qué dice el otro extremo (macOS)
sudo wdutil info
#    → Channel, PHY Mode, MCS Index, NSS, GI, Country

# 4 · qué ocurre al perder cada enlace
ping -i 1 <gateway>
#    + deshabilitar un radio del MLD desde RouterOS
#    → repítelo banda por banda: los resultados no son simétricos

Los tres primeros no requieren equipamiento especializado. El cuarto es el que casi nadie hace, y es el que te dice cuál de tus radios puedes tocar sin desconectar a nadie.

La brecha no se cierra sola

Cada generación de Wi-Fi ha sido más difícil de verificar que la anterior.

Wi-Fi 6E prometía espectro: se comprobaba con cualquier escáner de canal. Wi-Fi 7 promete continuidad con MLO: ningún fabricante la expone completa, y hace falta cruzar tres instrumentos. Wi-Fi 8 —cuyo ecosistema completo lanzó Broadcom en octubre de 2025— mantiene la misma tasa máxima teórica y apunta a fiabilidad y latencia: justo las métricas que hoy menos se saben medir.

Wi-Fi 8 no va a cerrar la brecha: va a ensancharla. Quien tenga hoy el método para medir estará años por delante de quien siga leyendo fichas técnicas.

El hAP be³ Media entregó exactamente lo que el estándar permite entregar con la flota actual. Ni más, ni menos.

El problema nunca fue la configuración.

Mediciones realizadas en el laboratorio de Ekoinos sobre RouterOS 7.24rc3. La grabación completa de la masterclass está disponible en el canal de YouTube de Ekoinos.