Soluzioni WiFi per appartamenti: una guida completa per le aziende

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.

Estándares y seguridad

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

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.

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

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.