-08eec4200864.webp&w=1920&q=75)
Size an iPSK guest network for your hotel
Enter your property and see the device load, key churn, isolation design and front-desk time a per-reservation passphrase saves.
High turnover of business travellers who need video calls, VPNs and a laptop that just connects.
Starting points only. Replace them with your own front-desk log for a figure you can defend.
One VLAN per room is workable (160 of the 4,094 usable 802.1Q IDs), though per-key group isolation avoids trunking them all to every AP.
- Occupied rooms = rooms × occupancy. Devices = occupied rooms × 2.8 per room for this property type.
- Keys a year = occupied rooms × 365 ÷ average stay, because each reservation gets one key.
- Requests = occupied room-nights × your rate per 100, then reduced by the share you expect iPSK to remove.
Every reservation gets its own WPA2 passphrase on a single SSID. The RADIUS server looks the key up at association and returns the room's VLAN or group, so phones, laptops and casting devices in one room share a private network and cannot see the room next door.
Oracle OPERA Cloud or OPERA V5 sends the check-in event (ohip business events for check-in, room move and check-out (opera cloud), or the fias interface on opera v5). A unique passphrase is generated and bound to the reservation.
The guest types the passphrase once on each device. The AP places every device using that key in the room’s VLAN or group, with mDNS kept inside it for casting.
The check-out event deletes the key, so departed guests and neighbours cannot keep using hotel bandwidth. A room move re-maps the same key.
# Access-Accept for MAC authentication on the iPSK SSID # (Cisco Meraki and Catalyst 9800 syntax) Tunnel-Type = VLAN (13) Tunnel-Medium-Type = IEEE-802 (6) Tunnel-Private-Group-ID = "room-304" Cisco-AVPair = "psk-mode=ascii" Cisco-AVPair = "psk=<unique per-reservation passphrase>" Session-Timeout = 86400 # re-check the key daily # Key valid for 1.8 nights + 2 h grace = 162,720 s, # revoked early on the PMS check-out event. # HPE Aruba uses the Aruba-MPSK-Passphrase VSA instead of psk=.
Purple's hospitality team can review your numbers, confirm iPSK support on your controller and show the PMS key flow live.
在酒店业中，宾客满意度取决于无形的设施。虽然舒适的床铺和干净的房间是基本要求，但快速、可靠的 WiFi 一直被评为对酒店评价和重复预订影响最大的单一因素。然而，传统的酒店 WiFi 架构给宾客带来了不便，也为酒店运营商带来了安全漏洞。
Identity Pre-Shared Keys (iPSK) 通过使用安全、个性化的无线网络取代传统的 Captive Portal，解决了这些挑战。通过为每位宾客或每个房间分配一个唯一的密码，iPSK 在提供企业级加密的同时，还带来了无缝的 “宾至如归” 连接体验。
核心要点：用于酒店访客 WiFi 的 iPSK
- 免除 Captive Portal：用一个 WPA2/WPA3 密钥取代繁琐的重复登录网页，使访客设备在抵达时即可自动连接。
- 专属局域网 (PAN)：隔离每个客房的无线流量，使访客可以投屏到房内电视，而无需向其他酒店访客暴露其设备。
- 无屏幕设备支持：顺畅连接没有网页浏览器的流媒体播放棒、游戏机和智能音箱。
- 自动化 PMS 集成：将 WiFi 凭证直接与物业管理系统 (PMS) 同步，实现办理入住时立即联网、退房时立即撤销。
- 企业级硬件兼容性：在现有的 Cisco Meraki、HPE Aruba 和 Ruckus 无线基础设施中无缝部署。
为什么传统酒店 Captive Portal 会让宾客和 IT 团队感到沮丧
二十多年来，酒店一直依赖 Captive Portal 进行 宾客 WiFi 认证。宾客连接到开放网络，等待弹出欢迎页面，然后输入他们的房号和姓氏。虽然这种系统提供了基本的身份识别，但现代宾客的期望已经超越了它。
标准的 Captive Portal 部署会带来一些持续存在的运营挑战：
- 频繁的断开连接超时：安全策略强制 Captive Portal 每24小时对访客进行一次重新身份验证。晚饭后回到房间的访客会发现他们的智能手机已断开连接，从而错过了重要通知。
- 与无浏览器设备不兼容：访客通常会携带流媒体棒（Chromecast、Roku、Fire TV）、智能手表和游戏机旅行。这些设备缺少内置的网页浏览器，因此无法通过 Captive Portal 网页表单。
- 缺乏客房隔离：在标准的开放式访客网络上，客户端隔离会阻止设备相互发现。虽然这阻止了恶意监听，但也导致访客无法将视频从他们的平板电脑投屏到客房电视上。
- 未加密的无线流量：没有预共享密钥的开放式 WiFi 网络会导致未加密的数据帧暴露在大堂和走廊的本地数据包监听中。
iPSK 在酒店宾客 WiFi 中如何工作
Identity Pre-Shared Key (iPSK) 技术弥补了简单家庭 WiFi 密码与企业级 802.1X 安全之间的差距。在标准的家庭网络上，每个家庭成员都共享完全相同的密码。在传统的企业网络上，每个用户都需要单独的证书凭证。
iPSK 允许单个酒店 SSID 接受数千个唯一的密码。当访客在其智能手机、笔记本电脑或流媒体棒上输入其专属密码时，无线接入点会将该密码传递给 RADIUS 身份验证服务器。服务器验证该密钥，将设备与访客的个人资料相关联，并应用特定于客房的 VLAN 策略。
要了解有关基于身份架构的更多信息，请阅读我们详细的 多租户 WiFi 指南。
对比酒店 WiFi 认证模式
下表对比了开放式宾客网络、传统 Captive Portal 以及与 PMS 集成的酒店 iPSK 部署在关键技术和运营要求方面的差异：
| 功能 / 需求 | 开放式访客 WiFi | Captive Portal | 酒店 iPSK (Purple) |
|---|---|---|---|
| 数据加密 | 无（未加密） | 仅限网页 SSL | 完整 WPA2/WPA3 Enterprise |
| 访客体验 | 即时连接，零隐私保护 | 频繁超时与重复登录表单 | 无缝“家一般”的自动连接 |
| 智能电视 / 设备投屏 | 失败（共享子网风险） | 失败（无网页浏览器） | 通过专用局域网支持 |
| PMS 自动化 | 无 | 房号与姓名核对 | 自动化的办理入住与退房同步 |
| 设备隔离 (PAN) | 否（点对点风险） | 客户端隔离阻断投屏 | 隔离的私人客房 VLAN / 气泡隔离 |
专用局域网 (PAN)：客房内投屏无安全风险
现代旅客期望将个人内容投屏到酒店房间的显示器上。然而，在传统的酒店子网上启用设备发现意味着 204 室的宾客 A 可能会不小心将个人手机屏幕投屏到 205 室宾客 B 的电视上。
iPSK 通过专用区域网络（PAN）解决了这个问题。当访客在多台个人设备（手机、笔记本电脑、Chromecast）上输入其特定于客房的 iPSK 密钥时，网络会将所有这些设备放入一个私有的、隔离的虚拟子网中。访客的设备彼此之间可以无缝通信，同时与物业中的所有其他客房完全隔离。
这提供了与家庭网络完全相同的便利性，同时兼顾了企业级安全合规。有关详细的网络隔离架构，请参阅我们的 企业级 WiFi 安全指南。
通过物业管理系统 (PMS) 集成自动管理宾客生命周期
为每日成百上千到达和离开的宾客管理个人 WiFi 凭证必须完全自动化。Purple 的 iPSK 平台与主流物业管理系统 (PMS) 直接集成，包括 Oracle Opera、Mews、Stayntouch、RMS 和 Protel。
1. 抵达前凭据凭据生成
当PMS（物业管理系统）确认预订或办理入住时，Purple 会自动生成一个唯一的 iPSK 密码。该密钥将通过数字化确认邮件、短信欢迎消息发送给宾客，或打印在其房卡套上。
2. 无缝的多设备引导入网
抵达后，宾客选择酒店的 WiFi 网络并输入一次密码。他们的智能手机、笔记本电脑和平板电脑即可立即连接，无需进行网页登录或电子邮件验证。
3. 退房时自动撤销权限
当前台在 PMS 中办理退房手续时，该宾客唯一的 iPSK 将在 RADIUS 基础设施中自动停用。这可以防止已退房的宾客在离开后从停车场或相邻设施访问网络。
硬件兼容性与多厂商支持
升级到 iPSK 不需要更换现有的酒店无线硬件。Purple 的云管理层独立于硬件，支持领先的企业级网络厂商：
- Cisco Meraki: 带有身份策略标签的原生 IPSK 认证。
- HPE Aruba Networks: 通过 Cloud Auth 和 ClearPass 实现 ePSK 集成。
- Ruckus Wireless: 动态 PSK (dPSK) 生命周期管理。
- Juniper Mist: 通过 Cloud API 生成多 PSK 密码。
要了解位置洞察和营销订阅如何提高宾客留存率，请访问我们的 WiFi 营销指南。
关于酒店 iPSK WiFi 的常见问题
针对酒店环境部署中身份预共享密钥 (iPSK) 技术问题的直接解答。
酒店 WiFi 中的 iPSK 是什么？
Identity Pre-Shared Key (iPSK) 是一种无线安全协议，可在单个 SSID 上为每个酒店宾客或房间分配唯一的 WPA2/WPA3 密码。它提供企业级数据加密和私有房间网络，而无需强迫宾客通过网页浏览器 Captive Portal 进行操作。
iPSK 如何提高宾客满意度评分？
iPSK 消除了智能设备上的登录超时、重新身份验证表单和连接失败。访客在办理入住时连接一次，即可在整个物业中保持连接，获得与在家中无异的 WiFi 体验。
宾客是否可以使用 iPSK 将 Chromecast 和 Netflix 内容投屏到客房电视？
是的。iPSK 可以创建专用局域网 (PAN)，允许宾客的智能手机或平板电脑安全地发现并推送到其客房内的智能电视或 Chromecast，而不会将设备暴露给其他房间。
Purple 如何自动管理 iPSK 凭证？
Purple 与 Oracle Opera 和 Mews 等酒店物业管理系统 (PMS) 直接集成。入住时会自动生成唯密钥，通过电子邮件、短信或房卡套发送，并在退房时自动撤销。
iPSK 是否需要更换现有的酒店接入点？
不需要。Purple 的 iPSK 解决方案与硬件无关，可与来自 Cisco Meraki、HPE Aruba、Ruckus Wireless 和 Juniper Mist 等厂商的现有企业级无线基础设施协同工作。
用零摩擦的 iPSK 变革您的酒店 WiFi
利用 Purple 的酒店业 WiFi 平台，消除 Captive Portal 投诉，自动完成 PMS 入住联网，并提供安全的房内流媒体体验。
