跳至主要內容

Managed WiFi 服務:企業必備的完整指南

本完整指南詳細介紹物業開發商和 BTR(租賃專用住宅)營運商如何利用雲端疊加(cloud overlay)架構佈署託管式 WiFi 服務。內容涵蓋透過 iPSK 實現每戶居民隔離的技術實作、網路分段最佳實踐,以及將 WiFi 視為託管便利設施的商業投資報酬率(ROI)。

📖 5 分鐘閱讀📝 1,145 字數🔧 2 範例3 練習題📚 8 關鍵定義

收聽此指南

查看播客逐字稿
歡迎來到 Purple 技術簡報。在接下來的十分鐘裡,我將為您清晰、實用地說明何謂託管 WiFi 服務 - 它們是什麼、如何運作,以及您今天所做的架構決策如何決定您的網路會成為營運資產還是揮之不去的頭痛問題。 [medium pause] 我們首先從背景資訊談起。「託管 WiFi 服務」這個詞經常被寬鬆地使用。在最基本的層面上,它意味著將無線網路的設計、部署、監控和日常管理委外給第三方。但這個定義忽略了過去五年中所發生的更重要轉變。真正的改變在於架構。託管 WiFi 已從硬體與支援合約模式,轉變為雲端重疊(cloud overlay)模型 - 在這個模型中,智慧功能、驗證、分析和合規層全都在軟體中運行,並架構在您已擁有的任何存取點(AP)之上。 [short pause] 對於管理多住戶單元(MDU)的開發商、共同租賃(BTR)營運商和房東而言,這種轉變極為重要。您不再只是購買一個網路。您購買的是在您網路上運行的服務。而這種區別徹底改變了您的採購方式、向住戶收費的方式,以及您長期從中榨取價值的方式。 [medium pause] 好的。我們來深入探討技術架構,因為這正是大多數採購對話出錯的地方。 [short pause] 託管 WiFi 服務有四個不同的層級。第一,存取層 - 安裝在走廊、公共區域和個人單元中的實體存取點(AP)。第二,交換和佈線基礎設施 - 為這些 AP 提供電力並進行連接的 PoE 交換機和結構化佈線。第三,控制器或雲端管理平台 - 從單一介面配置、監控和更新每個 AP 的軟體。第四,服務層 - 驗證、訪客存取、住戶引導系統、分析和合規。這才是價值真正存在的地方。 [short pause] 關鍵的洞察在於,第一層和第二層在很大程度上已商品化。Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium - 他們都製造了極其優秀的存取點。硬體決策固然重要,但這並非決定勝負的關鍵。決定勝負的是第三層和第四層。 [medium pause] 現在,對於 BTR 或 MDU 部署,服務層有一個標準企業 WiFi 無法解決的特定需求:單一住戶隔離。這是最根本的挑戰。您擁有一個共享的實體網路,為數百個不同的家庭提供服務。每位住戶都希望他們的裝置表現得就像在家庭網路中一樣 - 他們的手機可以找到他們的 Chromecast、智慧喇叭可以與其燈泡配對、遊戲主機可以獲得乾淨的 NAT 類型以進行線上多人遊戲。但住戶 A 的裝置必須對住戶 B 完全隱形。 [short pause] 為了解決這個問題,所採用的技術是 iPSK - Identity Pre-Shared Key。Aruba 有時稱之為 PPSK,而 Cisco Meraki 則稱之為個人專私網路。不論各家廠商的術語為何,其概念都是相同的。每位住戶在參加上線引導時都會獲得一組專屬的 WiFi 認證資訊,其所有裝置皆使用該認證資訊。網路透過此認證資訊來識別裝置屬於哪位住戶,並將其歸入專屬該住戶的私有區段 - 也就是我們所說的 WiFi 氣泡。使用相同認證資訊的裝置可以互相偵測,而使用不同認證資訊的裝置彼此之間是看不見的。當住戶遷出時,您只需撤銷其認證資訊即可,其他住戶完全不受影響。 [medium pause] 這就是核心所在。但在合規性維度上同樣重要,特別是在英國與歐盟。在 GDPR 規範下,您有義務確保某個住戶無法存取另一位住戶的資料或裝置。iPSK 就是在網路層滿足該義務的技術機制。再加上 WPA3 加密 - 這是目前用來取代 WPA2 的標準 - 從資料保護的角度來看,您就擁有了一個具備防禦力的架構。 [short pause] 在驗證方面,以 RADIUS 作為後端的 IEEE 802.1X 是員工網路的標準。它在裝置獲准接入前提供基於憑證或憑證資訊的驗證,並與 Microsoft Entra ID、Okta 或 Google Workspace 整合以進行策略執行。對於使用 iPSK 的住戶網路,RADIUS 伺服器會自動處理每組憑證資訊的查詢與 VLAN 分配。 [medium pause] 接下來談談網路分段,因為這是您必須做對的另一個架構支柱。在租賃專用住宅(BTR)開發項目中,您至少在運行三種不同的網路群體:住戶、員工,以及公共區域的訪客。每種群體都需要擁有自己的 VLAN - 也就是 IEEE 802.1Q 標準中所定義的虛擬區域網路 - 並配備專屬的防火牆原則。住戶在 VLAN 30、員工在 VLAN 20、大廳與健身房的訪客 WiFi 在 VLAN 10、IoT 和大樓管理系統則在 VLAN 40。 [short pause] 這些 VLAN 之間的防火牆原則與 VLAN 架構本身一樣重要。應採取預設拒絕、明確允許。您的訪客 VLAN 應該只具有連外網際網路存取權限,而無其他權限。沒有路由可通往住戶網路、沒有路由可通往員工網路,也沒有路由可通往大樓管理系統。如果您重視安全性與合規性,這絕非選配項目。 好的,接著談導入。讓我為您說明託管 WiFi 部署的五個階段,因為這正是專案通常會停滯或失敗的地方。 [short pause] 第一階段是 RF 場地勘測。在指定任何無線基地台(AP)之前,您需要進行預測性的射頻設計。像 Ekahau 這樣的工具可以模擬信號在建築物特定材質(混凝土、玻璃、石膏板)中的傳播,並精確告訴您在何處安裝 AP 以及採用何種功率級別以達到覆蓋目標。跳過此步驟並僅憑每平方公尺的粗略 AP 估算,是部署後效能不佳最常見的單一原因。 [short pause] 第二階段是流量分類與 VLAN 設計。記錄環境中的每種設備類型和使用者群體。住戶、員工、訪客、IoT 設備、CCTV、大樓管理系統。在接觸控制器之前,每個群體都需要分配一個 VLAN、子網和防火牆原則。 [short pause] 第三階段是控制器設定與 SSID 對應。保持您的 SSID 數量處於低水平 - 每個無線頻段不超過四個。三個是最理想的:住戶、員工、訪客。您廣播的每個額外 SSID 都會消耗信框信號(beacon frames)的空頻時間,即使沒有用戶端連接也是如此。在擁有數百個 AP 的密集建築中,SSID 激增會顯著降低吞吐量。 [short pause] 第四階段是服務層整合。這就是像 Purple 的 Multi-Tenant WiFi 平台透過 RADIUS 和 API 連接到您的控制器、處理住戶引導、管理每個住戶的 iPSK 認證,並提供分析與合規層的地方。Purple 可在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 上運作 - 因此您不會被鎖定在特定的硬體廠商。 [short pause] 第五階段是驗證與監控。執行部署後的 RF 驗證走測。從訪客設備測試您的 VLAN 隔離 - 確認您無法存取住戶或員工子網。設定您的監控儀表板並定義您的 SLA 閾值。Purple 的平台為您提供 99.999% 的上線時間 SLA,以及整個資產的即時網路健康狀態可視性。 [medium pause] 現在讓我指出我最常看到的的三個陷阱。 [short pause] 第一:低估場地勘測的重要性。我見過有些部署中,開發商因跳過預測性 RF 設計而省了錢,結果在他們試圖以 WiFi 品質做出市場區隔的單位中出現了訊號死角。勘測成本僅是補救成本的一小部分。 [short pause] 第二:將住戶 WiFi 視為次要考慮。在 BTR(長租公寓)中,WiFi 品質是預訂調查中排名前五的設施因素。在 WiFi 品質上領先的營運商,其住戶滿意度得分一貫高於行業平均水準。網路是一項商業資產,而不僅僅是基礎設施。 [short pause] 第三:將 WiFi 與第三方寬頻合約進行綑綁。軟體疊加模式 - 即您擁有硬體並在其上運行託管服務 - 持續提供比綑綁式 ISP 合約更好的經濟效益。由 WiFi-as-amenity(WiFi 作為便利設施)產生的每戶每月 20 到 40 英鎊的租金溢價,應該流向營運商,而不是第三方 ISP。 [medium pause] 快速問答。三個我最常聽到的問題。 [short pause] 「我需要更換現有的無線基地台嗎?」在大多數情況下,不需要。如果您已經安裝了 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist 或 Ubiquiti UniFi,Purple 的雲端疊加層可以透過標準的 RADIUS 和 VLAN 整合,在您現有的硬體上運行。您是在添加服務層,而不是更換實體基礎設施。 [short pause] 「住戶在入住當天如何上網?」透過 iPSK,住戶會在入住過程中收到其專屬的 WiFi 憑證 - 透過 Purple 應用程式或歡迎電子郵件。他們連接第一台裝置後,後續添加的每台裝置都會使用相同的憑證。無需等待寬頻工程師,也無需簽署獨立的 ISP 合約。入住第一天即可上網。 [short pause] 「智慧家庭裝置和 IoT 呢?」這是讓許多營運商措手不及的問題。標準的訪客 WiFi 會將每個裝置彼此隔離 - 這意味著 Chromecast 無法運作,智慧喇叭無法配對,您會收到大量的支援工單。iPSK 解決了這個問題,它將住戶的所有裝置保持在同一個邏輯網路區段中,同時與其他住戶進行隔離。對於現代 BTR(出租專用住宅)單位來說,每戶 15 到 25 台裝置是較切合實際的數字。您的網路架構需要從第一天起就能處理這樣的密度。 [medium pause] 總結來說。針對 BTR 和 MDU(多住戶單元)的託管 WiFi 服務不僅僅是一項連線方案。它是一個住戶體驗平台、一個合規機制,也是一項商業資產。這些架構決策 - 用於單一住戶隔離的 iPSK、用於加密的 WPA3、用於安全的 VLAN 區段,以及用於管理的雲端疊加層 - 都是非常成熟且不綁定特定廠商的。硬體已經商品化。價值在於服務層。 [short pause] 自 2012 年以來,Purple 已在 80,000 個場所運行託管 WiFi。我們已通過 ISO 27001 認證、符合 GDPR 和 CCPA,並獲得 B Corp 認證。我們的 Multi-Tenant WiFi 平台可處理完整的住戶生命週期 - 包括註冊引導、憑證管理、IoT 支援、分析和合規性 - 作為您已擁有或目前正在規劃的硬體上的雲端疊加層。 [short pause] 如果您正處於 BTR 開發的設計階段,或者正在評估運作不佳的現有網路,那麼正確的下一步是與我們的網路架構師進行對話。我們將審查您的平面圖、裝置密度假設和商業模式,並為您清晰呈現架構應有的樣貌及其成本。 [short pause] 您可以在 purple.ai 找到完整的書面指南、架構圖以及 ROI 計算器。感謝您的收聽。

header_image.png

執行摘要

託管 WiFi 服務已從基本的硬體支援合約演變為複雜的雲端覆蓋架構。對於房地產開發商、房東和 BTR 營運商而言,網路不再只是基礎設施,而是一項關鍵的便利設施和商業資產。本指南提供了一個全面的技術框架,用於在多租戶環境中設計、部署和管理企業級 WiFi。

藉由遷移到雲端管理控制器架構並透過 iPSK 部署每個住戶的隔離,營運商可以提供宛如在家中的連線體驗,同時保持嚴格的安全性和合規性。我們探討了將 WiFi 作為託管服務的實施策略、部署架構和業務優勢,並輔以來自 Purple 超過 80,000 個真實場域的數據支持。

技術深度剖析:雲端覆蓋架構

現代託管 WiFi 服務運行於四個不同的層級。物理接入層和交換機基礎設施構成了基石,但真正的價值在於雲端管理平台和服務層。

接入層依賴企業級硬體。Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 提供物理基地台。然而,單靠硬體無法解決多租戶環境的根本挑戰:在單一共享的物理網路上隔離數百個家庭。

這正是服務層變得至關重要的原因。標準的訪客 WiFi 會將每台設備與其他所有設備隔離。這種方法在住宅情境中行不通,因為住戶希望他們的手機可以找到他們的智慧電視,並用他們的語音助理控制燈光。

其技術解決方案是 iPSK (Identity Pre-Shared Key)。每位住戶都會獲得一個與其租約綁定的唯一 WiFi 憑證。網路會使用此憑證將該住戶的所有設備放入一個私有的隔離網路區段中。使用相同憑證的設備可以互相識別;使用不同憑證的設備則保持完全隱形。這種架構可支援現代 BTR 家庭典型的 15 到 25 台設備,而不會損害鄰近住戶的安全。

architecture_overview.png

從安全角度來看,這種隔離是強制性的。在 GDPR 規範下,營運商必須確保住戶無法存取另一位住戶的資料或裝置。iPSK 在網路層提供了這種隔離。當結合 WPA3 加密以及針對員工網路的 IEEE 802.1X 驗證時,此架構可提供強大且具防禦力的安全防護。

實作指南:部署多租戶 WiFi

部署託管 WiFi 服務需要結構化、分階段的方法。跳過這些階段不可避免地會導致效能不佳和住戶不滿。

此過程始於預測性無線電頻率場地勘測。使用工具模擬訊號穿透特定建築材料的傳播情況,可確保存取點的精確放置。純粹根據平方英尺來估算 AP 密度,保證會導致訊號死角和同頻道干擾。

流量分類和 VLAN 設計緊隨物理規劃之後。BTR 環境通常需要至少三個不同的網路客群:住戶、員工和訪客。每個客群都需要一個專用的 VLAN 和嚴格的防火牆政策。

例如,大廳的 Guest WiFi 應置於 VLAN 10 上,且僅具備對外網際網路存取權限。員工營運置於 VLAN 20,並由 WPA3-Enterprise 保護。住戶則置於 VLAN 30,並由 iPSK 處理每戶隔離。防火牆必須在這些區段之間強制執行預設拒絕政策。如果您需要設定這些規則的指引,請參閱我們的指南: 如何安全地隔離員工與訪客 WiFi 網路

控制器設定涉及將這些 VLAN 對應到 SSID。最佳實作做法是每個無線電頻段廣播不超過三個或四個 SSID,以儘量減少管理開銷並保留無線空中傳輸時間。如需深入瞭解 SSID 策略,請參閱 三個稱霸群雄的 SSID:訪客、Passpoint 和 IoT WiFi

最後階段是整合服務層。Purple 的雲端重疊透過標準 RADIUS 和 API 整合連線到無線控制器。此層處理自動化的住戶啟用、憑證管理以及 WiFi Analytics ,將實體網路轉化為託管服務。

deployment_comparison.png

BTR 和 MDU 營運商的最佳實作做法

將 WiFi 視為託管便利設施需要營運思維的轉變。網路的設計必須考慮到密度、自助服務和持續監控。

自動化住戶啟用。 住戶期望在入住那一刻就能上網。將 WiFi 佈署與您的物業管理系統整合,以便在租約開始前,透過電子郵件或住戶應用程式自動產生並發送憑證。

針對 IoT 密度進行設計。 現代 BTR(建屋出租)住宅內含 15 到 25 台聯網裝置。網路架構必須支援此等密度,且上線程序必須容納無螢幕裝置,例如智慧插座和感測器。

保留商業價值。 避免將 WiFi 服務與第三方寬頻合約綑綁銷售。藉由擁有硬體並執行軟體疊加層,營運商可保留與優質 WiFi 相關的租金溢價。

實施嚴格的網路分割。 絕不要在與住戶或訪客流量相同的邏輯網路上執行建築管理系統、CCTV 或付款終端機。請使用具有明確防火牆規則的專用 VLAN。

疑難排解與風險緩釋

即使是設計良好的網路也會遇到問題。瞭解常見的故障模式,可讓營運商在影響住戶體驗之前降低風險。

多租戶環境中最常見的支援工單與裝置探索有關 - 通常是住戶無法投放至其智慧電視。如果網路使用標準訪客隔離而非 iPSK,裝置探索將會失敗。請確保正確配置 iPSK,並允許在住戶各自的 VLAN 區段內進行多播流量傳輸,但必須嚴格限制在該區段內。

配置錯誤的 Trunk 埠代表重大安全性風險。如果將承載多個 VLAN 的交換器連接埠意外配置為 Access 埠,分割將會崩潰,進而將所有流量暴露在單一廣播網域中。請定期稽核交換器配置。

最後,監控有線基礎設施。如果訪客可以將筆記型電腦插入公共區域中暴露的網路埠,並存取公司 VLAN,那麼安全的無線架構就毫無用處。請使用 MAC 驗證或 802.1X 保護所有實體連接埠的安全。

ROI 與業務影響

受管理 WiFi 服務能為 BTR 營運商和房東帶來可衡量的商業回報。其影響涵蓋營收創造、營運效率和資產估值。

優質 WiFi 是潛在租戶前五大考量的便利設施因素。提供無縫、如家般連線體驗的營運商,每套住宅每月可獲得 20 至 40 英鎊的租金溢價。此外,擁有即裝即用 WiFi 的物業空置期較短,因為即時可用的連線消除了新住戶的一大痛點。

在營運方面,雲端管理的疊加層可減少 IT 支援開銷。自動化上線和自助式裝置管理消除了手動重設密碼和疑難排解的需求。集中式儀表板提供整個物業的即時可見性,使支援團隊能夠在住戶回報問題之前發現並解決問題。

Purple 的平台已部署於超過 80,000 個場所,並在 2024 年處理了 4.4 億次登入,提供了將成本中心轉化為營收資產所需的分析與合規性架構。透過擷取第一方數據並了解網路使用率,營運商可以優化其空間並提供卓越的住戶體驗。

關鍵定義

iPSK (Identity Pre-Shared Key)

一種安全機制,允許在單一 SSID 上使用多個唯一的 WiFi 密碼,每個密碼會將使用者分配到特定的 VLAN 或原則。

對於 BTR 和 MDU(多住戶單元)環境至關重要,可讓營運商在共享基礎架構上為每位居民提供私有網路的體驗。

VLAN (Virtual Local Area Network)

一個邏輯子網路,可將來自不同實體 LAN 區段的裝置群組,集合到單一廣播網域中。

用於安全地進行流量分段,例如將訪客裝置與員工筆記型電腦和付款終端機完全隔開。

Cloud Overlay

在實體網路硬體之上運作的軟體管理與服務層,提供集中式控制、驗證和分析。

允許營運商在不更換現有存取點(Access Points)的情況下,佈署進階功能,例如 Purple 的多租戶引導上網。

IEEE 802.1X

一項針對連接埠網路存取控制的 IEEE 標準,為希望連接到 LAN 或 WLAN 的裝置提供驗證機制。

保護員工和企業網路的黃金標準,要求使用者使用個人憑證而非共享密碼進行驗證。

Captive Portal

公共存取網路的使用者在獲得存取權限之前,必須查看並與之互動的網頁。

用於訪客網路以收集第一方數據、呈現服務條款並管理 GDPR 行銷同意書。

WPA3

最新一代的 WiFi 安全技術,提供增強的加密強度和更好的防範離線字典攻擊保護。

應作為所有新企業和住宅網路部署的預設加密標準。

RADIUS

一種網路協定,為連接和使用網路服務的使用者提供集中式的驗證、授權和計費管理。

後端引擎,用於驗證 802.1X 員工網路的憑證,並驗證住宅網路的 iPSK 密碼。

SSID (Service Set Identifier)

裝置可看見並連接的無線網路公開名稱。

營運商應限制廣播的 SSID 數量,以節省無線空中時間並維持網路效能。

範例

一個擁有 250 個單元的 BTR 開發項目正收到大量居民的支援工單,反映其無法將智慧喇叭和投影裝置連接到大樓的共享 WiFi 網路。目前的設定是使用單一 SSID,搭配 Captive Portal 和標準用戶端隔離。

將網路遷移至 iPSK (Identity Pre-Shared Key) 架構。設定無線網路控制器,在居民入住時發給每戶唯一的 WiFi 憑證。透過 RADIUS 伺服器對應這些憑證,動態將每位居民的裝置分配到私有的 VLAN 區段或微細分(micro-segmented)的「WiFi 氣泡」中。在這些獨立的區段內停用標準用戶端隔離,但維持嚴格的防火牆規則,防止不同居民的區段之間進行路由。

考官評語: 原先的 Captive Portal 方法是專為臨時訪客設計,而非永久居民。標準用戶端隔離會阻斷物聯網裝置所需的裝置偵測協定(如 mDNS 或 Bonjour)。實作 iPSK 可以在公寓之間提供必要的安全性和隔離,同時允許同一公寓內的裝置自由通訊,運作方式與傳統家用寬頻完全相同。

一家擁有多個據點的共享空間營運商需要佈署一個安全網路,以支援臨時的每日訪客、需要 VPN 連線的長期企業會員,以及內部員工日常營運,且所有服務皆需運行在現有的 Cisco Meraki 硬體上。

在現有硬體上實施嚴格的 VLAN 分段策略。佈署三個不同的 SSID。SSID 1(訪客):對應至 VLAN 10,使用開放網路並搭配 Purple Captive Portal 進行符合 GDPR 規範的資料收集,且僅限外網連線。SSID 2(會員):對應至 VLAN 20,使用 WPA3-Enterprise802.1X 向營運商的識別身分提供者進行驗證,並允許 VPN 穿透。SSID 3(員工):對應至 VLAN 30,使用 WPA3-Enterprise,並允許存取內部管理系統。

考官評語: 此方法在解決每個使用者群組的不同安全需求之餘,還能充分利用既有的硬體投資。針對會員和員工使用 802.1X 可確保強效的驗證,而搭配嚴格防火牆規則的專用訪客 VLAN 則能防止橫向移動,保護企業網路免受可能已受入侵的訪客裝置威脅。

練習題

Q1. 您正在一個擁有 400 個單元的新學生宿舍大樓部署 WiFi。開發商建議使用單一的開放式 SSID 搭配 Captive Portal,以簡化學生的登入流程。這種方法的主要技術風險是什麼?您應該推薦什麼樣的架構來替代?

提示:考量學生如何在房間內使用遊戲機、智慧電視和無線印表機等裝置。

查看標準答案

主要風險在於,採用標準用戶隔離的 Captive Portal 會中斷裝置對裝置的通訊,這意味著智慧電視、無線印表機和投放裝置將無法運作。此外,遊戲機通常很難透過 Captive Portal 進行驗證。建議的架構是部署 iPSK 解決方案,為每位學生核發唯一的憑證,將他們的裝置置於私有、隔離的 VLAN 區段中,允許他們的裝置彼此通訊,同時確保不受其他學生的干擾與安全威脅。

Q2. 在對一家零售連鎖店進行網路稽核期間,您發現銷售點(POS)終端機和公共訪客 WiFi 在相同的實體存取點上運作,並在相同的子網路中進行廣播。目前違反了哪項合規標準?您該如何補救此問題?

提示:思考處理付款卡資料的相關要求。

查看標準答案

此設定違反了 PCI-DSS(付款卡產業資料安全標準),該標準要求對持卡人資料環境進行嚴格隔離。若要補救此問題,您必須實作 VLAN 分割。POS 終端機必須移至專用且高度受限的 VLAN。訪客 WiFi 則必須在獨立的 VLAN 上運作,並配置防火牆原則,明確拒絕訪客子網路與 POS 子網路之間的任何路由。

Q3. 一家 BTR 營運商希望將其整個產品組合中的存取點硬體從 Cisco Meraki 更換為 HPE Aruba,但他們擔心會失去現有的 Purple Captive Portal 和分析數據。這種擔憂是否有必要?

提示:考量智慧功能在雲端重疊架構(cloud overlay architecture)中位於何處。

查看標準答案

這種擔憂是沒有必要的。Purple 是一個與硬體無關的雲端重疊服務。它透過標準的 RADIUS 和 API 協定與 Cisco Meraki 及 HPE Aruba 進行整合。營運商可以更換實體存取層硬體,而不會失去其 Captive Portal 設計、行銷自動化流程或歷史分析數據,因為這些服務是存在於 Purple 雲端平台,而非本機存取點上。