Saltar al contenido principal

Soluciones de WiFi para apartamentos: una guía completa para empresas

Esta guía cubre la arquitectura, el despliegue y el caso de negocio de las soluciones de WiFi para apartamentos en propiedades de Build to Rent y de múltiples viviendas. Explica cómo la tecnología Identity Pre-Shared Key (iPSK) crea burbujas de red seguras y aisladas para cada residente, a la vez que admite dispositivos inteligentes e IoT. Los promotores inmobiliarios, propietarios y operadores de BTR encontrarán orientación práctica de despliegue, datos de ROI y escenarios de implementación resueltos.

📖 9 min de lectura📝 2,033 palabras🔧 2 ejemplos prácticos4 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast
Usted es un consultor sénior de tecnología con un acento británico claro y autoritario, que informa a un cliente con un tono seguro y conversacional. Hable como si se dirigiera a una junta directiva de promotores inmobiliarios y directores de TI. Ritmo pausado, dicción clara, sin palabras de relleno. Pronunciación en inglés británico en todo momento: Hola y bienvenidos a esta sesión informativa para ejecutivos. Hoy nos adentraremos en un tema de infraestructura crítico para el sector inmobiliario: las soluciones de WiFi para apartamentos. Si es usted un director de TI, un arquitecto de redes o un director de operaciones inmobiliarias en el espacio de promociones para alquiler (Build to Rent) o de edificios multifamiliares, esta sesión es para usted. Analizaremos cómo desplegar un sistema WiFi multiinquilino de calidad empresarial que realmente funcione para los residentes y, lo que es más importante, cómo impulsa el Ingreso Operativo Neto. Empecemos con el contexto. La expectativa de conectividad en las propiedades residenciales ha cambiado radicalmente. Los residentes no solo quieren internet. Esperan una experiencia como en casa desde el mismo momento en que cruzan la puerta. Tienen televisiones inteligentes, consolas de videojuegos, altavoces inteligentes y un sinfín de dispositivos IoT. Y esperan que todos esos dispositivos funcionen juntos, a la perfección, desde el primer día. El problema es que las arquitecturas de red tradicionales fallan en estos entornos. Si despliega un sistema WiFi de invitados estándar, como haría en el vestíbulo de un hotel, aislará cada dispositivo de todos los demás. Eso es excelente para la seguridad en un entorno de paso, pero significa que el teléfono de un residente no puede comunicarse con su Chromecast. El servicio se interrumpe de inmediato desde la perspectiva del usuario. Por otro lado, si simplemente configura un SSID compartido con una única contraseña y desactiva el aislamiento, se enfrentará a un problema importante de seguridad y privacidad. Todo el mundo podrá ver los dispositivos de todos los demás. Esto no es aceptable en un entorno residencial donde las personas tienen una relación continua con la propiedad y una expectativa de privacidad. Entonces, ¿cuál es la solución técnica? Se trata de las Redes Basadas en la Identidad, utilizando Clave Precompartida de Identidad, o iPSK. iPSK es el motor del WiFi multiinquilino moderno. Así es como funciona. Se emite un único SSID en toda la propiedad. Pero en lugar de una contraseña para todo el mundo, la red admite miles de claves únicas, una para cada residente. Cuando un residente firma su contrato de alquiler, el sistema genera una frase de contraseña única solo para él. Cuando conectan un dispositivo utilizando esa clave, el punto de acceso se comunica con el servidor RADIUS en la nube. El servidor RADIUS valida la clave y responde con una asignación dinámica de VLAN. Dice, en efecto: este es el Residente A del apartamento 101. Colóquelo en la VLAN 101. La red asigna dinámicamente ese dispositivo a un microsegmento dedicado exclusivamente a ese residente. A esto lo llamamos la burbuja WiFi. Dentro de esa burbuja, los dispositivos del residente se comunican entre sí a la perfección. Pueden transmitir contenidos a su televisor, controlar sus luces inteligentes y jugar en línea sin problemas, pero están completamente aislados del Residente B del apartamento 102. El Residente B es invisible para ellos. Esta arquitectura es compatible con cualquier tipo de hardware. Purple funciona como una capa en la nube sobre el hardware empresarial que probablemente ya tenga desplegado. Esto incluye Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. No es necesario reemplazar su infraestructura existente. Solo tiene que apuntar sus puntos de acceso a la nube RADIUS de Purple y listo. Los estándares subyacentes son robustos. WPA3-Personal proporciona cifrado individualizado para el tráfico de cada residente. IEEE 802.1X constituye el marco para la asignación dinámica de VLAN. Y la arquitectura cumple plenamente con los requisitos de GDPR y CCPA, ya que el tráfico de los inquilinos está separado de forma lógica y las analíticas individuales dentro de las unidades privadas están restringidas. Ahora, hablemos de la implementación. Hay varios errores que debe evitar. En primer lugar, el diseño de RF. No confíe únicamente en el modelado predictivo. Los entornos Build to Rent tienen paredes densas y fuertes interferencias. Necesita un estudio activo de cobertura de RF sobre el terreno. Diseñe para una cobertura principal de 5GHz y 6GHz, y coloque los puntos de acceso cerca o dentro de las viviendas. Asegure una cobertura superpuesta para una itinerancia sin interrupciones cuando los residentes se trasladen a zonas comunes como gimnasios, vestíbulos y espacios de coworking. En segundo lugar, la automatización de la incorporación. La carga operativa de gestionar el WiFi para cientos de residentes puede ser considerable si no se automatiza. Debe integrar su plataforma de gestión de WiFi con su sistema de gestión inmobiliaria (Property Management System). Cuando se firma un contrato de alquiler, el sistema genera automáticamente la iPSK y se la entrega al residente. Cuando se mudan, Purple revoca el acceso automáticamente. Intervención cero de su equipo de TI. Sin rotaciones de contraseñas compartidas, sin llamadas de soporte. En tercer lugar, la compatibilidad con dispositivos IoT. Los dispositivos inteligentes de consumo son muy difíciles de gestionar en redes empresariales. No son compatibles de forma nativa con la autenticación 802.1X. iPSK soluciona esto de forma elegante porque, para el dispositivo, parece una red personal estándar WPA2 o WPA3. Se conectan sin problemas y se ubican en la VLAN correcta de forma automática. Pasemos a las preguntas rápidas. Pregunta uno: ¿Cómo gestionamos a los residentes que quieren instalar sus propios rúteres? No es necesario que lo hagan. Al proporcionar una red WiFi gestionada y de cobertura total con VLAN privadas, elimina la necesidad de puntos de acceso no autorizados, que solo causan interferencias de canales y empeoran la experiencia de todos en el edificio. Pregunta dos: ¿Cumple esto con las normativas de privacidad de datos como GDPR? Sí, y de hecho refuerza el cumplimiento normativo. La asignación dinámica de VLAN garantiza una separación lógica absoluta del tráfico entre inquilinos, cumpliendo con el deber de diligencia del operador para proteger los datos de los residentes. Pregunta tres: ¿Qué ocurre con la escalabilidad? Estamos planificando una cartera de veinte edificios. La infraestructura cloud RADIUS de Purple funciona en 80 000 ubicaciones en vivo en todo el mundo, con un tiempo de actividad del 99,999 %. No hay servidores locales que mantener. La gestión centralizada significa que puede gestionar el acceso y las políticas de todos los edificios desde un único panel de control. Por último, analicemos el impacto empresarial. ¿Por qué tomarse la molestia de implantar un servicio de WiFi gestionado en lugar de dejar que los residentes contraten su propia banda ancha? La respuesta es el Ingreso Operativo Neto (NOI). Tratar el WiFi como un servicio gestionado es sistemáticamente positivo para el NOI. Según Parks Associates, el 70 % de los propietarios de MDU afirman que el WiFi ayuda a atraer residentes, y casi el 80 % coincide en que aumenta el valor de la propiedad. Una investigación de ASK4 reveló que el 77 % de los inquilinos tienen más probabilidades de mudarse a una vivienda si el WiFi está incluido en el alquiler, y el 84 % afirma que un WiFi deficiente afectaría a su decisión de renovar el contrato. En la práctica, un WiFi gestionado de alto rendimiento puede justificar incrementos en el alquiler de 15 a 30 libras por vivienda al mes. Las propiedades con WiFi instantáneo y listo para usar desde el primer día registran periodos de desocupación más cortos, lo que suele reducir la vacancia entre 5 y 10 días. Al ser propietario de la infraestructura y utilizar una capa de software, usted captura esos ingresos en lugar de cederlos a un proveedor de banda ancha externo. En resumen: el WiFi multi-inquilino requiere una arquitectura iPSK para crear burbujas de VLAN seguras por residente. Debe admitir dispositivos IoT sin pantalla de forma fluida. Debe integrarse con sus sistemas de gestión de propiedades para automatizar las altas y bajas de usuarios. Y cuando se implementa correctamente como una capa de software sobre el hardware propio, transforma el coste de un edificio en un motor de ingresos medible. Gracias por escuchar esta sesión informativa técnica. Para obtener guías de implementación detalladas, diagramas de arquitectura y una herramienta gratuita de diseño de subredes iPSK, visite el centro de recursos de Purple en purple dot ai. Si desea hablar con uno de nuestros arquitectos de redes sobre su cartera de propiedades específica, reserve una demostración técnica a través del mismo sitio.

header_image.png

Resumen ejecutivo

El WiFi multiinquilino no es WiFi para invitados. En entornos de Build to Rent (BTR) y unidades multifamiliares (MDU), los residentes esperan una experiencia de red doméstica desde el primer día. Necesitan que sus televisiones inteligentes, videoconsolas y dispositivos IoT se detecten entre sí sin problemas, al tiempo que permanecen completamente aislados del apartamento de al lado. Los portales cautivos estándar y las contraseñas compartidas fallan en ambos aspectos.

La respuesta técnica son las redes basadas en la identidad mediante iPSK (Identity Pre-Shared Key). Esta arquitectura asigna a cada residente una clave WiFi única, que el servidor RADIUS en la nube utiliza para ubicar dinámicamente cada dispositivo en una VLAN privada. El resultado es una burbuja de red segura y persistente que acompaña al residente por toda la propiedad.

Para los promotores inmobiliarios y operadores de BTR, desplegar un WiFi gestionado como una capa de software sobre hardware empresarial convierte un centro de costes en un servicio que genera ingresos. Según Parks Associates (2025), el 70% de los propietarios de MDU afirman que el WiFi ayuda a atraer residentes y casi el 80% indica que aumenta el valor de la propiedad. En el mercado de BTR del Reino Unido se pueden alcanzar primas de alquiler de entre 15 y 30 libras al mes por unidad, según los propios datos de despliegue de Purple.

Esta guía abarca la arquitectura técnica, un proceso de despliegue en cinco fases, escenarios del mundo real y los requisitos de cumplimiento sobre los que le consultará su equipo legal.

Análisis técnico profundo

El problema del aislamiento de dispositivos

En un despliegue estándar de WiFi para invitados , el aislamiento de clientes es absoluto. Cada dispositivo se separa de todos los demás para evitar el movimiento lateral a través de la red. Este es el comportamiento correcto para el vestíbulo de un hotel o un entorno de Retail , donde los usuarios son transitorios y no se conocen entre sí.

En un entorno residencial, esto interrumpe el servicio. El smartphone de un residente no puede comunicarse con su Chromecast en la red local. Su altavoz inteligente no puede detectar sus bombillas inteligentes. Su videoconsola no puede encontrar la televisión. La red es técnicamente funcional, pero prácticamente inútil para la vida residencial moderna.

La alternativa - desactivar el aislamiento de clientes en un SSID compartido - crea un problema mucho peor. Los dispositivos de cada residente se vuelven visibles para todos los demás residentes del edificio. Un dispositivo de la unidad 101 puede explorar los archivos compartidos de un dispositivo de la unidad 405. Esto es inaceptable en un entorno residencial donde los residentes tienen una relación continua con la propiedad y una expectativa razonable de privacidad.

La arquitectura iPSK

iPSK (Identity Pre-Shared Key) - llamado PPSK por HPE Aruba y Personal Private Network por Cisco Meraki - soluciona esto desacoplando el SSID de la clave de cifrado. En lugar de una única contraseña para todo el edificio, la red admite miles de frases de contraseña únicas en un único SSID.

Cuando un dispositivo se asocia con un punto de acceso, el AP reenvía la frase de contraseña al servidor RADIUS en la nube. El servidor RADIUS autentica la clave específica, busca el perfil del residente y devuelve una asignación de VLAN dinámica a través de un mensaje RADIUS Access-Accept. El AP asigna inmediatamente el dispositivo a esa VLAN.

El resultado es una burbuja de WiFi por residente:

  • Cada dispositivo que utiliza la clave del Residente A detecta todos los demás dispositivos asociados a esa clave. Su teléfono encuentra su Chromecast. Su altavoz inteligente se empareja con sus bombillas inteligentes. Su consola se conecta a su televisor.
  • Ningún dispositivo con la clave del Residente A puede ver ningún dispositivo con una clave diferente. Los dispositivos del Residente B son invisibles, aunque ambos residentes compartan el mismo punto de acceso físico.
  • Cuando el Residente A se muda, Purple revoca su clave. Ningún otro residente se ve afectado. No se requiere la rotación de contraseñas de todo el edificio.

architecture_overview.png

Estándares y seguridad

Esta arquitectura se basa en estándares del sector firmemente establecidos:

Estándar Función en la arquitectura
IEEE 802.1X Marco para la asignación dinámica de VLAN a través de RADIUS
WPA3-Personal Cifrado individualizado por residente, mitigando ataques de diccionario fuera de línea
RADIUS (RFC 2865) Autenticación, autorización y contabilidad a través de RADIUS en la nube
VLAN (IEEE 802.1Q) Aislamiento lógico del tráfico entre segmentos de residentes
mDNS (RFC 6762) Descubrimiento de dispositivos dentro de la burbuja de VLAN del residente

La arquitectura se alinea con los requisitos de GDPR y CCPA. El tráfico de los inquilinos está separado lógicamente y el análisis del comportamiento de los residentes individuales dentro de las unidades privadas está restringido por diseño. Los datos agregados de utilización de áreas comunes - ocupación por piso, horas de uso pico - son generalmente admisibles y operacionalmente útiles.

Compatibilidad de hardware

Purple funciona como un software de superposición en la nube agnóstico respecto al hardware. El RADIUS en la nube se integra con puntos de acceso de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. No es necesario reemplazar la infraestructura existente. Solo debe apuntar sus puntos de acceso al endpoint de RADIUS en la nube de Purple y configurar el SSID para usar autenticación WPA2/WPA3-Enterprise.

Guía de implementación

Un despliegue de WiFi multi-inquilino sigue cinco fases. Saltarse cualquier fase - particularmente el estudio de RF y la integración del proveedor de identidad - es la causa más común de problemas de soporte post-despliegue.

deployment_checklist.png

Phase 1: RF site survey

Do not rely solely on predictive modelling. BTR and MDU environments contain dense concrete and masonry walls that attenuate 5GHz and 6GHz signals heavily. Conduct an active RF site survey using a spectrum analyser to identify interference sources, coverage gaps, and co-channel interference from neighbouring buildings.

Access point placement decisions:

  • In-unit placement (ceiling or wall) provides the strongest signal but requires cable runs into each apartment.
  • Corridor placement with directional antennas reduces cabling cost but requires careful RF design to avoid inter-unit interference.
  • Target -65 dBm or better at the furthest point in each unit.

Phase 2: Network design

Design the switching infrastructure to support dynamic VLAN pooling. A 200-unit building with 15-25 devices per household requires a DHCP scope of at least 5,000 addresses. Use /22 or /21 subnets per VLAN pool. Ensure your core and distribution switches support the required number of VLANs - most enterprise switches support 4,094 VLANs per IEEE 802.1Q.

Configure DHCP snooping and ARP inspection on all access-layer switches to prevent rogue DHCP servers and ARP spoofing. Implement rate limiting per VLAN to prevent a single resident from saturating the uplink.

For a detailed comparison of PPSK deployment models, see our guide on PPSK: comparing features and deployment models .

Phase 3: Hardware installation

Install PoE switches at each distribution point. Use Cat6A cabling to all access point locations to support WiFi 6E and WiFi 7 speeds. Label all ports and document the physical topology - this is essential for remote troubleshooting.

For common areas (lobbies, gyms, coworking spaces), deploy access points on a separate SSID for Guest WiFi to handle visitor traffic. This keeps visitor traffic off the resident network entirely. For more on this three-SSID design pattern, see Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi .

Phase 4: iPSK provisioning and identity integration

Integrate Purple with your Property Management System (PMS) or identity provider - Microsoft Entra ID, Okta, or Google Workspace. When a lease is signed, the integration automatically generates an iPSK and delivers it to the resident via email or the resident portal. When the lease terminates, Purple revokes the key automatically.

This zero-touch provisioning eliminates manual IT intervention for onboarding and offboarding. In a 200-unit building with 30% annual turnover, that is approximately 60 move-in and move-out events per year - each one handled without a support ticket.

Phase 5: Go-live and monitoring

Before go-live, test the following scenarios on each access point model in the deployment:

  • A phone and a Chromecast on the same iPSK can discover each other.
  • A phone and a Chromecast on different iPSKs cannot discover each other.
  • Un dispositivo IoT sin pantalla (enchufe inteligente) se conecta utilizando la iPSK sin necesidad de un navegador.
  • Los dispositivos de un residente realizan un roaming fluido entre puntos de acceso sin necesidad de volver a autenticarse.

Tras el lanzamiento, supervise el panel de control de Purple para detectar fallos de autenticación, advertencias de agotamiento de DHCP y el estado de los puntos de acceso. Configure alertas para cualquier punto de acceso con más de 50 clientes asociados, lo que indica una brecha de cobertura en otra zona.

Buenas prácticas

Nunca utilice una PSK compartida en varias unidades sin aislamiento por cliente y limitación de ancho de banda. En el momento en que los residentes puedan ver los dispositivos de los demás, el servicio se ve comprometido y el operador se enfrenta a una responsabilidad bajo el GDPR.

Automatice el ciclo de vida de las credenciales. Vincule el acceso a la red directamente al contrato de alquiler. Purple revoca el acceso al finalizar el contrato sin ninguna intervención manual, lo que elimina el riesgo de seguridad de que los antiguos residentes conserven el acceso a la red.

Priorice las bandas de 5GHz y 6GHz. Diseñe la red para una cobertura principal en 5GHz y 6GHz. Reserve la de 2.4GHz únicamente para dispositivos IoT heredados. En entornos MDU densos, la interferencia de canal compartido en 2.4GHz procedente de edificios vecinos es grave.

Planifique para una alta densidad de IoT. Asuma una base de 15 a 25 dispositivos por vivienda. Un edificio de 200 unidades tiene entre 3,000 y 5,000 dispositivos en la red en cualquier momento. Dimensione sus pools de DHCP, la capacidad de conmutación y el ancho de banda de subida de manera acorde.

Pruebe la reflexión mDNS antes del lanzamiento. Este es el error de configuración más común en despliegues multi-inquilino. Verifique que el mDNS se refleje dentro de la VLAN de cada residente pero no entre diferentes VLAN.

Para obtener una perspectiva de primera mano sobre la experiencia de incorporación de los residentes, consulte Cómo causar una excelente primera impresión con su WiFi para invitados .

Resolución de problemas y mitigación de riesgos

Fallos de emparejamiento con Chromecast y dispositivos de hogar inteligente

Síntoma: Los residentes informan de que su teléfono no puede encontrar su altavoz inteligente o su dispositivo de transmisión.

Causa principal: La reflexión mDNS está desactivada o configurada para transmitirse a toda la subred en lugar de estar restringida a las VLAN individuales.

Solución: Active la reflexión mDNS dentro de la VLAN de cada residente. Verifique que el punto de acceso no esté aplicando un aislamiento de cliente absoluto dentro de la VLAN dinámica. Realice pruebas con un Apple TV, un altavoz Sonos y un Chromecast - estos tres cubren los principales protocolos de descubrimiento en uso.

Errores de tipo de NAT en videoconsolas

Síntoma: Los jugadores informan de NAT estricta (PlayStation) o NAT tipo 3 (Nintendo Switch), lo que impide el modo multijugador online.

Causa principal: La NAT simétrica en la puerta de enlace impide el redireccionamiento de puertos UDP peer-to-peer requerido por las plataformas de juego.

Solución: Implemente CGNAT por residente con UPnP activado. Evite la NAT simétrica en toda la red. Realice pruebas con una PlayStation 5 y una Xbox Series X antes de la puesta en marcha.

Agotamiento de direcciones IP

Síntoma: Los dispositivos no consiguen obtener una dirección IP, especialmente durante las horas punta de la tarde.

Causa principal: El pool de DHCP se ha dimensionado para el número de dispositivos en un único momento, no para la rotación de concesiones de corta duración de los dispositivos IoT.

Solución: Utilice el iPSK Subnet Designer gratuito de Purple para calcular el tamaño adecuado de las subredes. Implemente tiempos de concesión de DHCP agresivos de cuatro a ocho horas para los dispositivos IoT. Supervise la utilización del pool DHCP en el panel de control de Purple.

Puntos de acceso no autorizados

Síntoma: Los residentes instalan sus propios routers domésticos, lo que provoca interferencias de canales y degrada la red gestionada.

Solución: Active la detección de AP no autorizados en los puntos de acceso gestionados. Comunique claramente a los residentes al mudarse que la red gestionada ofrece la misma experiencia en el hogar que obtendrían de un router doméstico, incluido el soporte completo para IoT y hogares inteligentes. La red gestionada es la mejor opción - exponga este argumento en el paquete de bienvenida para residentes.

ROI e impacto empresarial

Tratar el WiFi como un servicio gestionado transforma el modelo financiero de la propiedad. Los datos que se muestran a continuación proceden de Parks Associates (2025) y del estudio Building a True Home de ASK4 (2025).

Métrica Punto de datos Fuente
Propietarios de MDU que afirman que el WiFi atrae a los residentes 70% Parks Associates, 2025
Propietarios de MDU que afirman que el WiFi aumenta el valor de la propiedad 80% Parks Associates, 2025
Inquilinos con mayor probabilidad de mudarse si se incluye el WiFi 77% ASK4, 2025
Inquilinos que afirman que un WiFi deficiente afecta a la renovación del alquiler 84% ASK4, 2025
Inquilinos que esperan tener el WiFi listo a los pocos días de mudarse 93% ASK4, 2025
Incremento del alquiler BTR por unidad y mes £15-30 Datos de despliegue de Purple
Reducción de los periodos de desocupación 5-10 días Datos de despliegue de Purple

Cuando se despliega como una capa de software sobre hardware propio, el WiFi gestionado es sistemáticamente positivo para el NOI. El modelo se deteriora cuando el WiFi se empaqueta con un contrato de banda ancha de terceros que se queda con el aumento de los ingresos. Ser propietario de la infraestructura y utilizar Purple como capa de gestión mantiene el valor en manos del operador.

Más allá del rendimiento financiero directo, las analíticas de WiFi proporcionan datos de utilización del edificio (ocupación por ala, horas de mayor uso, tiempo de permanencia en zonas comunes) que se integran directamente en la gestión de las instalaciones y la programación del mantenimiento. La plataforma de WiFi Analytics de Purple exporta estos datos a los paneles de control existentes a través de una API.

Para los operadores de Hospitality que gestionan desarrollos BTR de uso mixto con servicios de tipo hotelero, la misma plataforma de Purple gestiona tanto el WiFi multiinquilino para residentes como el WiFi para invitados desde una única consola de gestión.

Definiciones clave

iPSK (Identity Pre-Shared Key)

Una arquitectura de seguridad que permite múltiples contraseñas únicas en un único SSID. La contraseña específica presentada por un dispositivo es utilizada por el servidor RADIUS para asignar dicho dispositivo a una VLAN y una política de red específicas.

La tecnología principal que permite el aislamiento de la red por residente en entornos WiFi multiinquilino. También se denomina PPSK (HPE Aruba) o red privada personal (Cisco Meraki).

VLAN (Red de Área Local Virtual)

Una subred lógica que agrupa dispositivos e aísla su tráfico de otros dispositivos en la misma infraestructura física, definida por IEEE 802.1Q.

El mecanismo que evita que un residente del apartamento 101 vea los dispositivos del apartamento 102, incluso cuando ambos se conectan al mismo punto de acceso físico.

mDNS (DNS Multidifusión)

Un protocolo definido en RFC 6762 que permite a los dispositivos descubrir servicios en una red local sin un servidor DNS central, utilizando UDP multidifusión en el puerto 5353.

Necesario para que funcionen Chromecast, Apple TV, Sonos y los hubs de hogar inteligente. Debe reflejarse dentro de la VLAN de cada residente pero bloquearse entre diferentes VLAN.

Asignación dinámica de VLAN

El proceso mediante el cual un servidor RADIUS indica a un switch de red o punto de acceso que coloque un dispositivo en una VLAN específica según sus credenciales de autenticación, devueltas en el mensaje RADIUS Access-Accept.

El mecanismo que encamina el dispositivo de un residente hacia su burbuja de red personal al conectarse.

BTR (Build to Rent)

Desarrollos residenciales construidos específicamente para el alquiler a largo plazo en lugar de la venta, que normalmente ofrecen gestión profesional y paquetes de servicios.

El mercado principal para el WiFi multiinquilino en el Reino Unido. El sector BTR creció un 16% en los 12 meses anteriores al primer trimestre de 2025, según la British Property Federation.

NOI (Ingreso Operativo Neto)

Una métrica financiera inmobiliaria calculada como los ingresos totales de la propiedad menos todos los gastos operativos, excluyendo el servicio de la deuda y los gastos de capital.

El WiFi gestionado incrementa el NOI al generar primas de alquiler, reducir los periodos de desocupación y disminuir los costes de soporte de TI.

Dispositivo sin pantalla (headless)

Un dispositivo conectado a la red que carece de pantalla o navegador web, como un enchufe inteligente, una consola de videojuegos, un altavoz inteligente o una cámara IP.

Estos dispositivos no pueden autenticarse a través de portales cautivos. Requieren iPSK o autenticación MAC para conectarse a redes empresariales. Representan la mayoría de los dispositivos IoT en los apartamentos modernos.

CGNAT (NAT de calidad de operador)

Un método para compartir una única dirección IP pública entre múltiples direcciones IP privadas, utilizado habitualmente por los ISP y operadores de MDU para conservar el espacio de direcciones IPv4.

Debe configurarse correctamente en entornos MDU. El CGNAT simétrico interrumpe el funcionamiento de las consolas de videojuegos en línea que requieren NAT abierta o de tipo 2 para conexiones de par a par.

RADIUS (Servicio de Usuario de Acceso Telefónico de Autenticación Remota)

Un protocolo de red definido en RFC 2865 que proporciona autenticación, autorización y contabilidad centralizadas para el acceso a la red.

El motor de autenticación detrás de iPSK. Purple opera un servicio RADIUS en la nube con un tiempo de actividad del 99.999%, lo que elimina la necesidad de servidores RADIUS locales.

Ejemplos prácticos

Un desarrollo de Build to Rent de 250 unidades necesita proporcionar WiFi sin interrupciones para los residentes desde el día de su mudanza. El promotor quiere que los residentes conecten televisores inteligentes y consolas de videojuegos fácilmente, pero al equipo de TI le preocupa que el tráfico de difusión sature la red si las 250 unidades comparten una única subred. El sistema de gestión de la propiedad se basa en Microsoft Entra ID.

Despliegue un único SSID para toda la propiedad utilizando las redes basadas en identidad de Purple con iPSK. Integre el RADIUS en la nube de Purple con Microsoft Entra ID a través de aprovisionamiento SCIM. Cuando se firma un contrato de alquiler en el PMS, la integración crea una cuenta de residente en Entra ID y activa Purple para generar una iPSK única. Purple envía la clave por correo electrónico al residente antes del día de la mudanza. Al llegar, el residente introduce la clave en su teléfono. Todos los dispositivos posteriores (televisor inteligente, consola, ordenador portátil, altavoz inteligente) utilizan la misma clave. El servidor RADIUS coloca cada dispositivo en una VLAN dedicada (por ejemplo, VLAN 101 para la unidad 101). La reflexión mDNS dentro de la VLAN 101 permite que el teléfono descubra el Chromecast. La consola recibe un tipo de NAT Abierto a través de UPnP por VLAN. Al finalizar el contrato de alquiler, la cuenta de Entra ID se desactiva, Purple revoca la iPSK y la VLAN se devuelve al grupo de recursos. No se requiere intervención de TI.

Comentario del examinador: Este escenario demuestra la automatización completa del ciclo de vida de las credenciales que hace que el funcionamiento del WiFi multiinquilino sea viable operativamente a escala. La decisión de diseño clave es utilizar el proveedor de identidad como la única fuente de información sobre el estado de los residentes, en lugar de gestionar las credenciales en un sistema de WiFi independiente. Esto elimina el riesgo de que los antiguos residentes mantengan el acceso una vez finalizado el contrato de alquiler. El diseño de una VLAN por unidad evita las tormentas de difusión y aísla el tráfico DHCP, algo esencial a una escala de 250 unidades.

Un proveedor de alojamiento para estudiantes (PBSA) experimenta una grave congestión de red durante la semana de mudanza en septiembre. Los estudiantes llegan con entre cinco y siete dispositivos cada uno, el servicio de soporte está saturado con fallos del Captive Portal y los estudiantes no pueden conectar sus consolas de videojuegos ni sus televisores inteligentes. La red existente utiliza un único SSID compartido con un Captive Portal.

Sustituya el Captive Portal por una arquitectura iPSK desplegada en los puntos de acceso Ruckus existentes. Dos semanas antes de la mudanza, el portal del estudiante genera una iPSK única para cada estudiante y la muestra en el panel de su cuenta. Los estudiantes llegan, introducen su clave en su teléfono y se conectan de inmediato. Los dispositivos posteriores (ordenador portátil, consola, televisor inteligente) utilizan la misma clave sin necesidad de interactuar con el navegador. El controlador en la nube de Ruckus recibe la asignación de VLAN del servidor RADIUS de Purple y coloca a cada estudiante en su propio microsegmento. La carga de trabajo del servicio de soporte se reduce a casi cero porque no hay sesión del Captive Portal que expire ni contraseña compartida que restablecer.

Comentario del examinador: Los Captive Portals son fundamentalmente inadecuados para entornos residenciales. Requieren la interacción del navegador, de la que carecen los dispositivos sin pantalla. Interrumpen las sesiones, lo que requiere una reautenticación frecuente. Y no pueden proporcionar la red persistente y compatible con dispositivos que los residentes esperan. La transición a iPSK en el hardware existente demuestra que la solución no requiere nuevos puntos de acceso; se trata de un cambio de software y configuración, no de un proyecto de sustitución de hardware.

Preguntas de práctica

Q1. Está actualizando la red de un complejo de apartamentos de lujo de 300 unidades. El administrador de la propiedad desea ofrecer un nivel de WiFi premium. Los residentes se quejan de que no pueden conectar sus nuevos hubs de hogar inteligente a la red 802.1X existente. El equipo de TI se muestra reacio a reducir los estándares de seguridad. ¿Cómo resolvería esto?

Sugerencia: Considere las capacidades de autenticación de los dispositivos IoT de consumo y si 802.1X es el protocolo adecuado para dispositivos sin pantalla.

Ver respuesta modelo

Migre la red de un 802.1X estándar a una arquitectura iPSK. Los dispositivos IoT de consumo y los hubs de hogar inteligente no admiten suplicantes 802.1X, lo que imposibilita su conexión segura en una red empresarial tradicional sin omitir la autenticación MAC (lo cual es más débil que iPSK). Con iPSK, los residentes conectan los dispositivos sin pantalla utilizando una contraseña personal estándar WPA2/WPA3. El servidor RADIUS los asigna dinámicamente a su VLAN segura y aislada. Se mantiene la seguridad - cada residente tiene una clave única y las VLAN evitan el acceso entre inquilinos - mientras que la experiencia de usuario coincide con la de una red doméstica.

Q2. Durante un despliegue piloto de una solución WiFi multi-tenant en 20 unidades, un residente informa que puede ver la Apple TV de su vecino en el menú de AirPlay de su iPhone. La red utiliza iPSK con asignación dinámica de VLAN. ¿Cuál es el error de configuración más probable y cómo se soluciona?

Sugerencia: Revise cómo funciona mDNS y cómo debe delimitarse su alcance en un despliegue multiinquilino.

Ver respuesta modelo

La causa más probable es que la reflexión mDNS esté configurada para transmitir en toda la subred en lugar de limitarse a las VLAN individuales. Verifique que el RADIUS en la nube esté devolviendo un VLAN ID único para el iPSK de cada residente y que el punto de acceso esté etiquetando correctamente el tráfico a esas VLAN. A continuación, compruebe la configuración del proxy o reflector mDNS: debe reflejar las consultas mDNS solo dentro de la VLAN de origen, no entre todas las VLAN. Realice una prueba conectando un teléfono y una Apple TV a dos iPSK diferentes y confirme que el descubrimiento de AirPlay falla entre ellos.

Q3. Un operador de BTR desea incluir WiFi gestionado en el alquiler de una cartera de 15 edificios. Les preocupan los costes de soporte de TI continuos, especialmente para las altas y bajas de residentes. La cartera tiene una rotación anual de residentes de aproximadamente el 40%. ¿Cómo se minimizan los costes operativos?

Sugerencia: Considere los puntos de integración entre la plataforma WiFi y el sistema de gestión de propiedades existente.

Ver respuesta modelo

Integre Purple directamente con el sistema de gestión de propiedades a través de API o aprovisionamiento SCIM. Cuando se firma un contrato de arrendamiento, el PMS activa a Purple para generar un iPSK y entregarlo al residente automáticamente. Cuando finaliza el contrato, el PMS activa a Purple para revocar la clave. Con una rotación anual del 40% en 15 edificios, esta automatización gestiona cientos de eventos de aprovisionamiento al año sin ninguna intervención de TI. El único paso manual es la configuración inicial de la integración. Tras la integración, la función del equipo de TI consiste en supervisar el panel de Purple para detectar anomalías, no en gestionar las credenciales individuales.

Q4. Un arquitecto de redes está diseñando la infraestructura de conmutación para un nuevo desarrollo de BTR de 400 unidades. Se espera que cada unidad tenga una media de 20 dispositivos. El arquitecto está considerando si utilizar una VLAN por unidad o una VLAN por planta. ¿Qué enfoque es el correcto y por qué?

Sugerencia: Considere los requisitos de privacidad y las implicaciones del dominio de difusión de cada enfoque.

Ver respuesta modelo

Utilice una VLAN por unidad. Una VLAN por planta sitúa a todos los residentes de la misma planta en el mismo dominio de difusión, lo que significa que sus dispositivos son visibles entre sí. Esto infringe el requisito de privacidad de que los residentes no puedan ver los dispositivos vecinos. También crea un dominio de difusión más grande, lo que aumenta el riesgo de tormentas de difusión y saturación ARP. Una VLAN por unidad, asignada dinámicamente mediante iPSK y RADIUS, proporciona un aislamiento completo entre los residentes al tiempo que mantiene pequeños los dominios de difusión. Un edificio de 400 unidades requiere 400 VLAN, muy por debajo del límite de 4.094 VLAN de IEEE 802.1Q. Dimensione el pool de DHCP para cada VLAN para dar cabida a 20 - 25 dispositivos con una subred /27 o /26.