Service set identifier obfuscation

Abstract

The present disclosure provides techniques for SSID obfuscation. A network device broadcasts a generic SSID to enable a station (STA) to associate with the network device. The network device receives a setup request from the first STA, the setup request comprising one or more configuration parameters for a private SSID. The network device generates the private SSID and an SSID obfuscation algorithm for transforming between the private SSID and a pseudo-random SSID. The network device transmits the SSID obfuscation algorithm to the first STA for use in a future association.

Description

SERVICE SET IDENTIFIER OBFUSCATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of co-pending United States provisional patent application Serial No. 63 / 690,959 filed September 5, 2024. The aforementioned related patent application is herein incorporated by reference in its entirety.TECHNICAL FIELD

[0002] Embodiments presented in this disclosure generally relate to wireless communication. More specifically, embodiments disclosed herein relate to service set identifier (SSID) obfuscation in wireless networks.BACKGROUND

[0003] IEEE 802.11 bi amendment introduces enhancements to the privacy of management and control frame exchanges in Wi-Fi networks. To achieve this goal, the standard addresses the protection of sensitive identifying parameters that are exposed during wireless network discovery and association procedures. One important class of such parameters includes access point (AP) identifiers, such as the service set identifier (SSID) and basic service set identifier (BSSID). These identifiers are typically broadcast in cleartext in beacon and probe response frames, allowing devices to discover and join networks. However, their visibility also introduces privacy risks for both personal networks and enterprise or public networks.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] So that the manner in which the above-recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, may be had by reference to embodiments, some of whichare illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate typical embodiments and are therefore not to be considered limiting; other equally effective embodiments are contemplated.

[0005] Figure 1 depicts an example wireless environment that supports SSID obfuscation, according to some embodiments of the present disclosure.

[0006] Figure 2 depicts an example workflow for SSID obfuscation and discovery in a private network, according to some embodiments of the present disclosure.

[0007] Figure 3 depicts an example workflow for SSID obfuscation and discovery in a private network with out-of-band SSID profile provisioning, according to some embodiments of the present disclosure.

[0008] Figure 4 depicts an example workflow for SSID obfuscation and discovery via ANQP queries in a public network, according to some embodiments of the present disclosure.

[0009] Figure 5 depicts an example workflow for SSID obfuscation and discovery using neighbor reports in a public network, according to some embodiments of the present disclosure.

[0010] Figure 6 depicts an example workflow for SSID obfuscation and discovery using a shared SSID obfuscation algorithm in a public network, according to some embodiments of the present disclosure.

[0011] Figure 7 depicts an example method performed by a network device for SSID obfuscation and discovery support, according to some embodiments of the present disclosure.

[0012] Figure 8 depicts an example method performed by a network device for SSID obfuscation with out-of-band provisioning, according to some embodiments of the present disclosure.

[0013] Figure 9 depicts an example method performed by a network device for SSID obfuscation and ANQP-based network discovery, according to some embodiments of the present disclosure.

[0014] Figure 10 depicts an example method performed by a network device for SSID obfuscation and roaming support using neighbor reports, according to some embodiments of the present disclosure.

[0015] Figure 11 depicts an example method performed by a network device for SSID obfuscation and roaming support using a shared SSID obfuscation algorithm, according to some embodiments of the present disclosure.

[0016] Figure 12 is a block diagram depicting a method for SSID obfuscation and discovery in a private network, according to some embodiments of the present disclosure.

[0017] Figure 13 is a block diagram depicting a method for SSID obfuscation and discovery in a private network with out-of-band SSID profile provisioning, according to some embodiments of the present disclosure.

[0018] Figure 14 is a block diagram depicting a method for SSID obfuscation and discovery in a public network, according to some embodiments of the present disclosure.

[0019] Figure 15 depicts an example network device configured to perform various aspects of the present disclosure, according to some embodiments of the present disclosure.

[0020] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially used in other embodiments without specific recitation.DESCRIPTION OF EXAMPLE EMBODIMENTSOVERVIEW

[0021] One embodiment presented in this disclosure provides a method, including broadcasting, by a first network device, a generic service set identifier (SSID) to enable a first station (STA) to associate with the network device, receiving, by the first networkdevice, a setup request from the first STA, the setup request comprising one or more configuration parameters for a private SSID, generating, by the first network device, the private SSID and an SSID obfuscation algorithm for transforming between the private SSID and a pseudo-random SSID, and transmitting, by the first network device, the SSID obfuscation algorithm to the first STA for use in a future association.

[0022] One embodiment presented in this disclosure provides a method, including generating, by a network device, an enterprise service set identifier (SSID) and an SSID obfuscation algorithm for transforming between the enterprise SSID and a pseudo-random SSID, transmitting, by the network device, a profile to a station (STA) via an out-of-band communication channel, the profile comprising the enterprise SSID and the SSID obfuscation algorithm, and broadcasting, by the network device and to the STA, the pseudo-random SSID derived from the enterprise SSID using the SSID obfuscation algorithm.

[0023] One embodiment presented in this disclosure provides a method, including broadcasting, by a first network device that is part of a public wireless system, a common service set identifier (SSID) to a station (STA), where the common SSID is shared by a plurality of network devices within the public wireless system, broadcasting, by the first network device, a temporal identifier to the STA, where the temporal identifier is shared between the first network device and a second network device within the plurality of network devices, and the first network device and the second network device belong to a first extended service set (ESS) or mobility domain (MD), and updating, by the first network device, the temporal identifier based on a defined time schedule.EXAMPLE EMBODIMENTS

[0024] One focus of the IEEE 802.11 bi amendment is on the privacy protection of management and control frame exchanges. One aspect of that protection includes reducing the exposure of sensitive identifying parameters that are transmitted in the cleartext during the network discovery and association phase. Among these, access point (AP) parameters, such as the service set identifier (SSID) and basic service set identifier (BSSID), are representative elements subject to privacy risks.

[0025] In existing deployments, the SSID is commonly broadcast in cleartext within beacon or probe response frames to enable station (STA) devices to discover and associate with available networks. However, the transparency also presents vulnerabilities. As used herein, the SSID refers to the network name that is advertised by an access point (AP) and displayed in the network discovery list on user devices (e.g., in the Wi-Fi menu on a smartphone or laptop). For example, a typical SSID may appear as “HomeNetwork_123” or “Airport_Wi-Fi”. Exposure of the SSID allows observers to catalog network names and locations. These risks impact both personal networks (e.g., home Wi-Fi systems or smartphone-based virtual APs) and enterprise or public networks (e.g., campuses, retail environments, event venues, cruise ships, and other mobile or temporary deployments). In such contexts, operators may wish to avoid third-party monitoring and mapping their network infrastructure.

[0026] The SSID is sensitive because it is directly linked to privacy attacks. For example, in one known attack scenario, a malicious actor installs an AP in a public location (e.g., an airport) and configures it with the SSID of a well-known person’s home network (e.g., a celebrity’s home Wi-Fi name). Many devices are configured to automatically reconnect to previously joined networks. If a device belonging to the target (or someone in his or her household) comes within range, the device may automatically attempt to associate with the spoofed AP. Such an attempt can be detected by the attacker and reveals the target’s presence at that location. The type of attack demonstrates how SSID value can inadvertently serve as passive tracking or detection signals. Therefore, SSID obfuscation can help to improve user and network privacy.

[0027] However, once the SSID is obfuscated to prevent such abuses, conventional discovery mechanisms may no longer function as expected. Without a broadcast SSID, STAs are unable to identify or locate APs within range.

[0028] Embodiments of the present disclosure provide methods, systems, and apparatuses for SSID obfuscation that improves privacy protection but also preserves discovery capabilities. In the disclosed embodiments, wireless STAs are able to discover and connect to networks even when the SSIDs are not broadcasted in plaintext, using configured algorithms provided by the AP or obtained during provisioning.

[0029] In one embodiment, a private network scenario is supported where a client device connects to an AP that initially advertises a generic SSID (e.g., “HomeWiFi_Setup”) and performs setup operations. During this session, the STA provides one or more parameters (e.g., preferred SSID, transformation seed, or algorithm identifier), and the AP configures a private SSID and a corresponding transformation algorithm. The AP then shares the algorithmic profile back to the STA, so that the STA can derive future obfuscated SSID strings and recognize the correct network during subsequent discovery. In some embodiments, the STA may further share the received SSID profile with other trusted devices, allowing them to also identify the obfuscated SSID using the same decoding logic. In embodiments where a new device lacks the profile, a legitimate user may manually provide the current SSID and corresponding network credentials to facilitate onboarding. In larger or managed private systems (e.g., enterprise environments), the SSID profile may also be provisioned to devices via secure out-of-band (OOB) channels (e.g., web portals, configuration tools, or authenticated messaging systems).

[0030] In one embodiment, such as when the AP is deployed in a public venue or as part of a public network, additional discovery mechanisms are used to support privacy-enhancement operations. In this configuration, the SSID may be obfuscated or omitted from beacon and probe response frames, and the AP supports discovery through in-band signaling protocols, such as the access network query protocol (ANQP). Unassociated STAs may issue ANQP queries to nearby APs to retrieve network-related metadata, including information indicating Internet availability or network type, and decide whether to connect accordingly.

[0031] In another embodiment for public networks, APs may advertise a common SSID (e.g., “Public Wi-Fi”) for easy discovery. To enable privacy protection, APs belonging to the same extended service set (ESS) or mobility domain (MD) also broadcast a temporal identifier, which changes periodically (e.g., every 10 minutes). The shared temporal identifier allows STA to recognize which APs belong to the same network domain and support seamless roaming. When roaming occurs, the current AP provides the STA with a list of neighboring APs within the same ESS (identified by the shared temporal identifier). In this configuration, SSID obfuscation does not interfere with roaming, as the STA relies on the neighbor report to identify appropriateroaming targets, even when SSIDs are not plainly broadcast. When neighbor reporting is not supported, the AP shares an SSID obfuscation algorithm with the AP during association. The SSID obfuscation algorithm enables the STA to locally derive the expected obfuscation SSID values of other APs within the same ESS. As the STA scans for available networks, the STA applies the transformation logic to determine which nearby APs are part of the same roaming domain and then performs seamless roaming.

[0032] Figure 1 depicts an example wireless environment 100 that supports SSID obfuscation, according to some embodiments of the present disclosure. As depicted, the environment 100 includes a STA 105 and at least two APs 110-1 and 110-2. As used herein, the STA 105 may refer to any wireless client device capable of communicating over a wireless local area network (WLAN), including but not limited to a single-link STA, a multi-link device (MLD) STA, or any other wireless transceiver that performs network discovery and association. As used herein, the AP 110 may refer to any wireless infrastructure device that provides connectivity to STAs, including a single-link AP or a MLD AP.

[0033] As depicted, the STA 105 is located within the overlapping wireless coverage areas of both AP 110-1 and AP 110-2, and therefore is capable of receiving wireless management frames from each AP. During network discovery, the STA 105 receives a management frame 150 (e.g., a beacon frame or a probe response frame) from each AP.

[0034] As depicted, the management frame 150 (e.g., a beacon frame or a probe response frame) includes a service set identifier (SSID) element 155, which is part of the frame body of the 802.11 management frame. Within the SSID element 155, the SSID is encoded as a variable-length information field. As used herein, the SSID refers to a textual identifier defined for a WLAN. The SSID serves as the network name that the AP advertises to allow STAs to discover and distinguish available networks during active or passive scanning.

[0035] When the SSID is transmitted in cleartext, as depicted, the STA’s Wi-Fi user interface 115 (e.g., connection menu) displays the human-readable SSID values received from the APs 110. For example, AP 110-1 may advertise an SSID of “Ahome-G07” 120-1 , and AP 110-2 may advertise “CoffeeStore” 120-2. These cleartext SSIDs 120 may expose sensitive information or compromise user privacy. For example, a home SSID may reveal the identity or location of the household, and a retail SSID may enable tracking of a user’s movement across venues.

[0036] Moreover, such identifiers may be exploited in SSID spoofing attacks, particularly in public venues like airports or shopping malls. An attacker may configure a spoofed AP to advertise the same SSID (e.g., “Ahome-G07”) to impersonate a legitimate network. Since many client devices retain previously connected SSIDs in their network profiles and are configured to auto-join known networks, the STA may proactively initiate an association attempt to the spoofed AP upon detecting the SSID. Even if the association fails (e.g., due to mismatched credentials or other authentication errors), the STA still transmits probe requests, association requests, or authentication frames identifying the target SSID. These frames may be captured and analyzed to reveal the user’s past affiliations, device identifiers, and potential movement patterns. As a result, even failed connection attempts may leak sensitive information and enable device tracking or user profiling in public areas.

[0037] To address these concerns, the APs 110 may use SSID obfuscation for network discovery, where the advertised SSID element 155 includes a pseudo-random or obfuscated identifier instead of the real SSID. For example, AP 110-1 may broadcast “x9f4B3_q” 130-1 instead of “Ahome-G07” 120-1 , and AP 110-2 may use “net_7ac1 d2” 130-2 instead of “CoffeeStore” 120-2.

[0038] A network profile is saved within the STA 105, which maintains a set of entries that map obfuscated SSIDs to their corresponding real SSIDs along with associated credentials. Each profile entry 135 may include: the obfuscated SSID 140- 1 (e.g., “x9f4B3_q”) as received in the management frame 150; the real SSID 140-2 (e.g., “Ahome-G07”) used for user display or recognition; the security credentials, such as a password 140-3, a pre-shared key (PSK), or other certificate required for authentication; and an indication 140-4 of whether the STA would automatically join the network when it is detected. The mapping enables the STA 105 to resolve obfuscated SSIDs back to their true SSIDs for purposes such as network selection, display in the Wi-Fi menu, or initiating authentication, without requiring the AP to broadcast any directly identifying information in its management frames. More detailsabout the SSID obfuscation mechanisms are discussed below with reference to Figures 2-6.

[0039] Figure 2 depicts an example workflow 200 for SSID obfuscation and discovery in a private network, according to some embodiments of the present disclosure. The example workflow 200 addresses the process 260 by which a STA initially connects to a wireless network that uses SSID obfuscation, as well as the process 270 of how future discoveries and associations are handled using stored profile data.

[0040] As depicted, during the initial association process 260 (the first time the STA 205 connects to the network), the AP 210 advertises a generic SSID within its beacon or probe response frames (as depicted by step 215). The STA 205 may correspond to the STA 105 as depicted in Figure 1 , and the AP 210 may correspond to the AP 110- 1 or AP 110-2 as depicted in Figure 1 . The generic SSID may be a default value such as “Setup” or “Linksys AP,” which does not uniquely identify the network. The generic SSID may be included within the SSID element (e.g., 155 of Figure 1 ) in the frame body, and encoded as a variable-length string. The STA 205 detects the broadcast during passive scanning or initiates a directed probe request, and upon receiving the beacon or probe response, the STA identifies the generic SSID as a candidate network.

[0041] As depicted by step 220, the STA 205 establishes an initial association with AP 210, by sending an association request frame to AP 210 and receiving an association response frame from AP 210. The association may involve open or WPA2 / WPA3-based authentication.

[0042] Once connected, the STA 205 transmits a setup request message to the AP 210 (as depicted by step 225). The setup request message may include one or more parameters to guide the configuration of the private network, such as a preferred SSID string, SSID length constraints, user-defined transformation seeds or keys for SSID obfuscation, and an SSID rotation interval or profile expiration policy. The request may be transmitted via a vendor-specific protocol, an upper-layer application, or as part of a secure setup handshake (e.g., the 4-way handshake).

[0043] Upon receiving the setup request, the AP 210 defines a private SSID for the WLAN based on the received setup parameters or system defaults (when no user- defined parameters are provided). The private SSID serves as the actual network identifier recognized internally by the STA 205 and AP 210 but is not broadcast over the air in its original form. To improve privacy, the private SSID may be a non- descriptive string, such as a random alphanumeric sequence (e.g., “h7dcd2se”), a numeric identifier (e.g., “402563”), a truncated hash value (e.g., “3f8ac1 de9b7e4c20”), or any other format that avoids revealing semantic or location-based information.

[0044] The AP 210 additionally configures an SSID obfuscation algorithm that transforms the private SSID into a pseudo-random broadcast SSID. The algorithm may use cryptographic hash functions or other one-to-one encoding mechanisms. The algorithm may further incorporate time-varying or device-specific inputs. In some embodiments, the SSID obfuscation algorithm is configured to support reverse computation by authorized STAs (e.g., XOR with a rotating key or seed). More specifically, given an obfuscated SSID received in a beacon or probe response, the STA 205 can apply the corresponding decoding process to recover the original private SSID. In some embodiments, the algorithm supports forward computation and comparison, in which the STA 205 locally computes the expected obfuscation SSID(s) from its stored private SSID and associated parameters (e.g., seed, time) and performs a match against the received SSID.

[0045] As depicted by step 235, the AP 210 transmits a SSID profile to the STA 205. The profile may include the selected obfuscation algorithm, any required seed or initialization vector (IV), the defined private SSID, and additional metadata (e.g., profile validity duration, refresh intervals, or access control flags). The profile may be transmitted over a secure management channel. The profile is stored locally on the STA for future use.

[0046] In a subsequent discovery or reassociation process 270, such as when the STA returns to the AP’s 210 coverage after roaming to another AP or following a temporary disconnection, the AP 210 no longer advertises the generic SSID. Instead, the AP broadcasts an obfuscated SSID generated by the obfuscation algorithm (as depicted by step 240). The obfuscated SSID appears as a random string in the SSID element of the beacon or probe response frames.

[0047] Upon receiving the obfuscated SSID, the STA 205 uses the previously stored SSID profile to map the obfuscated value back to the corresponding private SSID (as depicted by step 245). The STA 205 may perform reverse computation by applying a decoding function (e.g., XOR with a shared key) to recover the private SSID directly, or it may use forward computation, generating one or more expected obfuscated SSIDs from the private SSID and profile parameters (e.g., seed, time) and comparing them to the received SSID. If one of the expected SSIDs matches the received SSID, the STA initiates the connection procedure.

[0048] Upon determining that the received SSID corresponds to a known private network, the STA proceeds to initiate a reassociation process with the AP (as depicted by step 250). The connection is performed without exposing the real SSID in any over- the-air (OTA) transmission. Therefore, the disclosed approach preserves user and network privacy and maintains seamless roaming for the authorized STA 205.

[0049] In some embodiments, the STA 205 that has completed the initial association 260 and received the SSID profile may share the profile with other trusted devices. The profile sharing may occur through peer-to-peer transfer mechanisms, such as Bluetooth or Wi-Fi Direct, through synchronization associated with a user account, or via application-based or operating system-level sharing features. In some embodiments, OOB provisioning methods, such as email, text message, QR code, or cloud-based device management systems, may also be used to deliver the SSID profile to other devices. The shared profile enables recipient STAs to resolve the obfuscated SSID using the same algorithm and seed, so that the recipient STAs can recognize and connect to the network even though the broadcast SSID remains masked. The profile-sharing method supports scalable onboarding of trusted devices to a private network. In some embodiments, the sharing STA may additionally send a notification to the AP, indicating that the profile has been shared with another STA. This allows the AP to recognize the newly added STA and authorize its associated request, even if the new STA has not undergone the original setup procedure.

[0050] In embodiments where a new STA lacks the ability to receive a profile through digital sharing, the network owner or a trusted user may manually provide the current obfuscated SSID along with the connection credentials. Although this methodmay require human intervention, it still enables secure access and maintains the privacy benefits of SSID obfuscation.

[0051] The example method 200 may be particularly useful for private networks that are open to receiving new guest or trusted devices, where an initial setup operation using a generic SSID is implemented to facilitate profile provisioning. The disclosed example method 200 provides flexibility for environments such as home networks or small enterprises, where authorized users may wish to add devices on demand.

[0052] In embodiments where the private network is not intended to support guest devices, the setup process using a generic SSID may be omitted. Instead, the AP may advertise an SSID that changes periodically or is generated pseudo-random ly based on an internal obfuscation algorithm. The STA 205 and other trusted devices are preprovisioned with a profile that includes the private SSID and a mapping function or obfuscation algorithm (delivered via secure provisioning channels during device deployment or enrollment). The closed network setting is suitable for environments with a fixed and static membership.

[0053] Figure 3 depicts an example workflow 300 for SSID obfuscation and discovery in a private network with out-of-band SSID profile provisioning, according to some embodiments of the present disclosure. The STA 305 may correspond to the STA 105 as depicted in Figure 1 , and the AP 310 may correspond to the AP 110-1 or AP 110-2 as depicted in Figure 1. The example workflow 300 may be particularly useful in enterprise environments where device onboarding is controlled and guest access is restricted or tightly managed. In such scenarios, profile delivery and network access credentials are distributed securely through IT-managed channels, such as mobile device management (MDM) systems, enterprise email, secure web portals, or QR-based onboarding tools.

[0054] As depicted, the AP 310 first defines an enterprise SSID to serve as the initial network identifier (as depicted by step 315). The SSID may follow the organization’s naming convention or may be randomized for privacy. The AP 310 also configures an SSID obfuscation algorithm that transforms the enterprise SSID into a pseudo-random value for OTA broadcast. The algorithm is designed to support eitherreverse computation, where the STA can decode the received SSID to retrieve the enterprise SSID, or forward computation, where the STA derives the expected obfuscated SSID(s) based on the stored enterprise SSID and associated algorithm parameters (e.g., seed, timestamps, or nonce) and compares them to the broadcast SSID.

[0055] As depicted by step 320, the STA 305 receives the SSID profile via an OOB delivery mechanism. The SSID profile may include the enterprise SSID, the configured obfuscated algorithm, any transformation keys or seed values, and additional metadata (e.g., validity duration or refresh intervals). The step 320 occurs to any OTA interaction and ensures that the STA is fully provisioned to recognize and connect to the enterprise network securely.

[0056] Following provisioning, the AP begins to broadcast an obfuscated SSID (e.g., a pseudo-random string) in its beacon or probe response frames (as depicted by step 325).

[0057] Upon receiving the obfuscated SSID, the STA 305 uses its stored profile to resolve the broadcast SSID to the known enterprise SSID (as depicted by step 330). The process may involve decoding the received value or generating expected obfuscated values for comparison.

[0058] Once determining that the received SSID corresponds to a known enterprise network, the STA 305 initiates association with the AP 310. The connection is completed without revealing the enterprise SSID in any cleartext management frame.

[0059] Figure 4 depicts an example workflow 400 for SSID obfuscation and discovery via ANQP queries in a public network, according to some embodiments of the present disclosure. The example workflow 400 may be particularly useful in public network deployments. In public deployments, such as those in airports, cafes, or transportation hubs, the STA typically does not have prior knowledge of the network. In conventional public Wi-Fi deployments, the real SSID is broadcast in cleartext, allowing STAs to recognize familiar or user-selected network names (e.g., “Airport WiFi,” “CoffeeShopNet”) and initiate connection based on those identifiers. However, when SSID obfuscation is introduced into public networks for privacy or anti-tracking purposes, it creates a challenge: STAs can no longer rely on the SSID string alone toidentify or evaluate the network, since the broadcast SSID is non-descriptive or randomized.

[0060] To address these concerns, the example workflow 400 introduces a mechanism for discovery and connection that is not dependent on the SSID name. Instead of relying on a human-readable SSID to determine whether to connect, the STA 405 performs active network discovery using access network query protocol (ANQP). More specifically, the STA’s association decision is based on network metadata provided in response to ANQP queries (e.g., network type, Internet availability, authentication methods, or service provider information), rather than on matching or recognizing an SSID. The STA 405 may correspond to the STA 105 as depicted in Figure 1 , and the AP 410 may correspond to the AP 110 as depicted in Figure 1.

[0061] As depicted, the AP 410 first configures an obfuscated SSID derived from its real SSID using a masking algorithm or random generator (as depicted by step 415). The obfuscated SSID may be a pseudo-random string, a truncated hash, or another identifier that does not reveal any human-readable information about the network. The obfuscation may be static or may change periodically (e.g., per a defined period of time) to further reduce tracking risk. The real SSID remains hidden from the OTA broadcast.

[0062] The AP 410 then broadcasts the obfuscated SSID as part of its beacon and probe response frames (as depicted by step 420). The SSID serves as a passive signal to nearby STAs that a network exists but conveys no recognizable semantic content. The STA 405, upon scanning, receives the beacon or probe response and identifies the presence of a nearby network, even though the SSID string cannot be interpreted directly.

[0063] Upon detecting the obfuscated SSID, the STA 405 transmits an ANQP query to the AP 410 (as depicted by step 425). The query may request various types of network metadata defined in relevant 802.11 standards and specifications, such as the network type (e.g., free / public), Internet connectivity status, venue name, domain name, IP address availability, or supported authentication and credential types. TheSTA does not need to know the SSID content to send the ANQP query. The ANQP query is directed to the AP’s 410 BSSID or MAC address.

[0064] Upon receiving the ANQP query, the AP 410 responds with an ANQP response that includes the requested network information (as depicted by step 430). The metadata provides the STA 405 with sufficient context to evaluate the network, for example, whether it is open to the public, part of a trusted seamless mobility domain (SMD), or supports a compatible authentication method (e.g., Open, EAP-based). The information may also indicate whether the network offers unrestricted Internet access, internal services only, or tiered access models.

[0065] Based on the metadata received, the STA 405 determines whether to proceed with the connection. If the STA 405 concludes that the network matches its policies or preferences (e.g., open access or trusted operator), the STA 405 initiates the association process with the AP 410 (as depicted by step 435). The connection is established without the STA relying on or referencing a cleartext SSID. The example workflow 400 therefore preserves user privacy when connecting to public infrastructure.

[0066] Figure 5 depicts an example workflow 500 for SSID obfuscation and discovery using neighbor reports in a public network, according to some embodiments of the present disclosure. The example workflow 500 may be particularly useful in public wireless networks where neighbor reporting is supported. The approach builds upon SSID obfuscation techniques by preserving privacy during both initial association 560 and roaming phases 570. The STA 505 may correspond to the STA 105 as depicted in Figure 1 , the AP 510-1 may correspond to the AP 110-1 as depicted in Figure 1 , and the AP 510-2 may correspond to the AP 110-2 as depicted in Figure 1 .

[0067] In public network deployments, STAs typically lack prior knowledge of network-specific SSIDs. When neighbor reporting is enabled (e.g., as defined in IEEE 802.11 k), the serving AP provides the STA with a structured list of nearby APs, along with associated metadata (e.g., channel, BSSID, mobility domain). This allows the STA to evaluate and roam to neighboring APs without requiring SSID broadcast visibility from each candidate AP.

[0068] As depicted, the example workflow includes two phases: the initial association phase 560, where the STA 505 discovers and connects to the AP 510-1 , and the roaming phase 570, where the STA 505 roams to another AP in the same ESS or MD based on neighboring information.

[0069] The AP 110-1 defines a common SSID (e.g., “Public Wi-Fi”) that is used across all APs within a venue (e.g., airport), even if the APs belong to different ESSs or MDs (as depicted by step 515). The common SSID allows all APs in the venue, such as those operated by different stores or service providers, to advertise a consistent SSID. To support roaming privacy, AP 510-1 also generates a temporal identifier that is unique to the AP’s ESS or MD (as depicted by step 515). The identifier may be updated periodically (e.g., every 10 minutes) and is broadcast along with the common SSID. The temporal identifier enables the STA 505 to distinguish between different ESSs or MDs using the same SSID.

[0070] Once defined, the AP 510-1 broadcasts the common SSID (e.g., “Public Wi¬Fi”) and the temporal identifier in beacon or probe response frames (as depicted by step 520). The SSID indicates the presence of a public access service, and the temporal identifier provides contextual information about which ESS or MD the AP 510-1 belongs to. The temporal identifier may be included as a vendor-specific information element or as part of a modified mobility domain information element (MDIE).

[0071] Upon receiving the beacon or probe response from AP 510-1 , the STA 505 initiates an initial association with AP 510-1 (as depicted by step 525). During normal operation or upon detecting degrading signal quality, the STA 505 prepares to roam to another AP. As depicted, the STA 505 sends a neighbor report request to AP 510- 1 (as depicted by step 530). The neighbor report request may be transmitted using a neighbor report request frame, a reassociation request, or other suitable management frames.

[0072] AP 510-1 then responds with a neighbor report, which includes a list of recommended APs within the same ESS or MD (as depicted by step 535). The list may include each AP’s BSSID, channel number, and supported capabilities or metrics.

[0073] Based on the received information, the STA 505 selects one of the candidate APs, such as AP 510-2, and initiates an association process with the selected AP (as depicted by step 540). Because the STA already knows the common SSID and current temporal identifier from AP 510-1 , AP 510-2 is not required to rebroadcast its own SSID or identifier in advance of the association. The example workflow 500 allows for seamless roaming in environments where SSID obfuscation is used to reduce broadcast exposure.

[0074] Figure 6 depicts an example workflow 600 for SSID obfuscation and discovery using a shared SSID obfuscation algorithm in a public network, according to some embodiments of the present disclosure. The example workflow 600 may be particularly useful in a public network that supports SSID obfuscation but does not enable neighbor reporting. The STA 605 may correspond to the STA 105 as depicted in Figure 1 , the AP 610-1 may correspond to the AP 110-1 as depicted in Figure 1 , and the AP 610-2 may correspond to the AP 110-2 as depicted in Figure 1 .

[0075] In public network deployments lacking neighbor report capability, STAs cannot rely on direct AP-provided lists of roaming candidates. As a result, when obfuscated SSIDs are used, preventing recognition of the next AP by SSID string alone, the example workflow 600 enables seamless roaming by introducing a shared SSID obfuscation algorithm across APs within the same ESS or MD.

[0076] As depicted, the example workflow 600 includes two phases: the initial association phase 680, where the STA 605 discovers and connects to the AP 610-1 , and the roaming phase 690, where the STA 505 roams to another AP in the same ESS or MD using a shared SSID algorithm.

[0077] AP 610-1 defines a common SSID (e.g., “Public Wi-Fi”) that is used across all public APs in the same venue (as depicted by step 615). The common SSID may span multiple ESSs or MDs. To distinguish each ESS or MD, AP 610-1 also defines a temporal identifier that changes periodically (e.g., every 10 minutes) (as depicted by step 615).

[0078] The AP 610-1 then broadcasts the common SSID and the current temporal identifier in beacon or probe response frames (as depicted by step 620). The information provides the STA with initial visibility of the network and its mobility context.

[0079] Upon receiving the beacon or probe response, the STA 605 begins an initial association with AP 610-1 (as depicted by step 625). Once the association is established, the STA 605 sends a setup request to the associated AP (as depicted by step 630), including parameters that the STA indicates for setting up a private or base SSID specific to the ESS or MD to which the AP belongs. These parameters may include SSID naming preferences, roaming policies, or security limits.

[0080] Based on the received information or system defaults (when no user-defined parameters are provided), the AP 610-1 defines a base SSID specific for the ESS or MD to which it belongs (as depicted by step 635). The base SSID may be used internally as the true network identifier. AP 610-1 also configures an SSID obfuscation algorithm to transform the base SSID into pseudo-random broadcast SSIDs (e.g., using a shared seed value or the temporal identifier). The algorithm may support reverse computation (e.g., XOR-based decoding with a shared seed) or forward computation, where the STA 605 generates candidate obfuscated SSIDs and matches them against the received SSID.

[0081] Once the base SSID and obfuscation algorithm are configured, AP 610-1 sends an SSID profile to the STA 605 (as depicted by step 640). The profile may include the base SSID, the obfuscation algorithm, any transformation seeds or keys, and additional parameters (e.g., update intervals, temporal offsets). In addition, AP 610-1 may also share the SSID profile with other APs, such as AP 610-2, that belong to the same ESS or MD. The profile enables other participating APs to generate consistent obfuscated SSIDs, allowing the STA to recognize and roam between them using the shared algorithm and configuration data.

[0082] As depicted by step 640, the AP 610-1 may periodically update the STA 605 with the new temporal identifier, especially when the identifier is designed to rotate at fixed intervals (e.g., every 10 minutes). In another embodiment, the STA 605 may proactively request the current temporal identifier from AP 610-1 (as depicted by step 655), for example, immediately before initiating a roaming procedure or when preparing to scan for candidate APs. The AP 610-1 may then respond with the updated temporal identifier (as depicted by step 660), allowing the STA 605 to correctly interpret the obfuscated SSID broadcasts from other APs in the same ESS or MD.

[0083] As depicted by step 665, a neighbor AP 610-2 (which belongs to the same ESS or MD as AP 610-1 ) broadcasts its obfuscated SSID along with the same temporal identifier via beacon or probe response frames. The SSID is generated using the shared obfuscation algorithm, and the base SSID or temporal identifier for the ESS or MD.

[0084] Upon receiving the beacon or probe response frames, the STA 605 uses the stored SSID profile and the updated temporal identifier to resolve the received obfuscated SSID (as depicted by step 670). The operation may involve applying the reverse algorithm (e.g., XOR-based algorithm) to decode the base SSID, or generating forward-computed SSID candidates and comparing them against the broadcast value.

[0085] If the resolved SSID matches the base SSID associated with AP 610-1 (e.g., the STA determines that AP 610-2 belongs to the same ESS or MD), the STA 605 initiates an association with AP 610-2 (as depicted by step 675). The example workflow 600 allows the STA 605 to complete a seamless roaming transition without requiring the APs 610 to broadcast their real SSIDs.

[0086] Figure 7 depicts an example method 700 performed by a network device for SSID obfuscation and discovery support, according to some embodiments of the present disclosure. The network device supports wireless LAN functions and manages SSID configuration and association. The network device may correspond to a physical AP (e.g., AP 110-1 or 110-2 as depicted in Figure 1 , AP 210 as depicted in Figure 2), or any other type of wireless infrastructure device capable of performing AP-related functionality (e.g., a residential or enterprise router, a mesh network node, a gateway device, or a virtualized AP within a software-defined networking (SDN) environment or cloud-managed infrastructure). The disclosed method 700 corresponds to the initial setup and obfuscation configuration process, where the AP cooperates with a STA to establish a private SSID and enable future privacy-improved connections using SSID obfuscation.

[0087] At block 705, an AP broadcasts a generic SSID (e.g., “Setup”) in its beacon or probe response frames (as depicted by step 215 of Figure 2). The SSID is publicly visible and intended to support initial discovery and onboarding by an authorized STA.

[0088] At block 710, the AP establishes an initial association (as depicted by step 220 of Figure 2) with a STA (e.g., STA 105 as depicted in Figure 1 , STA 205 as depicted in Figure 2). The process involves the AP receiving an association request from the STA, which may include authentication credentials or capability indicators, and the AP responding with an association response to complete the link establishment.

[0089] At block 715, the AP receives a setup request from the STA (as depicted by step 225 of Figure 2). The setup request may include one or more configuration parameters, such as a preferred SSID string, SSID length constraints, user-defined transformation seeds or keys for SSID obfuscation, and an SSID rotation interval or profile expiration policy.

[0090] At block 720, based on the setup parameters, the AP defines a private SSID for the WLAN and configures an SSID obfuscation function or algorithm (as depicted by step 230 of Figure 2). The private SSID serves as the actual network identifier known internally to the STA and AP, but it is not broadcast in cleartext during normal operation. The private SSID may be user-defined and is non-descriptive to minimize the risk of identification or profiling. The obfuscation algorithm (or function) may support either forward generation (e.g., hashing, keyed transformation, or time-based coding) or reverse decoding (e.g., XOR-based schemes, where the obfuscated SSID can be decoded back to the private SSID using a shared key or profile). The obfuscation algorithm allows the AP to generate dynamic pseudo-random SSIDs from the private SSID for future broadcast.

[0091] At block 725, the AP sends an SSID profile to the STA (as depicted by step 235 of Figure 2). The profile may include the private SSID, the selected obfuscation algorithm or function, and relevant parameters such as seed values or refresh intervals. The shared profile enables the STA to resolve future obfuscated SSIDs during discovery or roaming.

[0092] At block 730, the AP broadcasts obfuscated SSIDs in subsequent beacon or probe response frames (as depicted by step 240 of Figure 2). In future reassociation scenarios — such as when the STA roams to another AP and later returns, or when the connection is interrupted and reestablished — the STA receives the broadcastedpseudo-random SSID, uses the stored profile to recognize the network, and proceeds to connect using standard association procedures, all without requiring the real SSID to be broadcast over the air.

[0093] The example method 700 may be particularly useful in private networks that are open to guest or trusted device onboarding, such as home or small enterprise environments. In such cases, the use of a generic SSID for initial setup enables new STAs to discover the network and establish trust through the exchange of a setup request and profile provisioning. In a private network where guest access is not supported, the initial setup process involving a generic SSID may be omitted. Instead, the AP may begin advertising an SSID that changes periodically or is generated pseudo-random ly using an internal SSID obfuscation algorithm. In such configurations, the trusted devices may be pre-provisioned with a network profile prior to association. The profile includes the private SSID, the obfuscation algorithm, any required seed or keys, and relevant parameters that allow the STA to identify and join the network based on the obfuscated SSID.

[0094] Figure 8 depicts an example method 800 performed by a network device for SSID obfuscation with out-of-band provisioning, according to some embodiments of the present disclosure. The network device supports wireless LAN functions and manages SSID configuration and association. The network device may correspond to a physical AP (e.g., AP 110-1 or 110-2 as depicted in Figure 1 , AP 310 as depicted in Figure 3), or any other type of wireless infrastructure device capable of performing AP- related functionality (e.g., a residential or enterprise router, a mesh network node, a gateway device, or a virtualized AP within a software-defined networking (SDN) environment or cloud-managed infrastructure). The disclosed method 800 may be particularly useful in an enterprise wireless network where devices are provisioned using an OOB channel.

[0095] At block 805, an AP (e.g., AP 110-1 or 110-2 of Figure 1 , AP 310 of Figure 3) defines an enterprise SSID and configures an SSID obfuscation algorithm (as depicted by step 315 of Figure 3). The enterprise SSID serves as the internal identifier for the wireless network. The obfuscation algorithm (or function) supports forward or reverse computation to generate obfuscated broadcast SSIDs from the defined enterprise SSID.

[0096] At block 810, the AP sends the SSID profile to a STA (e.g., STA 105 of Figure 1 , STA 305 of Figure 3) via an OOB provisioning channel algorithm (as depicted by step 320 of Figure 3). The profile may include the enterprise SSID, the obfuscation algorithm or function, any required keys or seeds, and the validity or refresh intervals. The profile may be delivered through a secure management interface such as MDM, email attachment, configuration portal, QR code, or onboarding tool prior to the STA’s network discovery.

[0097] At block 815, the AP generates the obfuscated SSID and broadcasts the identifier in its beacon or probe response frames during the network discovery phase (as depicted by step 325 of Figure 3). When the STA scans for networks, the STA uses the stored SSID profile to resolve the received obfuscated SSID and recognize the network as trusted. The STA then proceeds to initiate an association with the AP using standard authentication and association procedures.

[0098] Figure 9 depicts an example method 900 performed by a network device for SSID obfuscation and ANQP-based network discovery, according to some embodiments of the present disclosure. The network device supports wireless LAN functions and manages SSID configuration and association. The network device may correspond to a physical AP (e.g., AP 110-1 or 110-2 as depicted in Figure 1 , AP 410 as depicted in Figure 4), or any other type of wireless infrastructure device capable of performing AP-related functionality (e.g., a residential or enterprise router, a mesh network node, a gateway device, or a virtualized AP within a software-defined networking (SDN) environment or cloud-managed infrastructure). The disclosed method 900 may be particularly useful in a public network environment where ANQP is supported. In this configuration, the STA’s decision to connect does not rely on the SSID name, which is obfuscated, but instead depends on network metadata received through ANQP responses.

[0099] At block 905, an AP (e.g. , AP 110-1 or 110-2 of Figure 1 , or AP 410 of Figure 4) generates an obfuscated SSID for broadcasting OTA (as depicted by step 415 of Figure 4). The SSID may be a pseudo-random or non-descriptive string that does not reveal any privacy-sensitive information about the network.

[0100] At block 910, the AP broadcasts the obfuscated SSID in its beacon or probe response frames to nearby STAs (e.g., STA 105 of Figure 1 or STA 405 of Figure 4) (as depicted by step 420 of Figure 4). Upon detecting the broadcast SSID, a STA sends an ANQP query to the AP (as depicted by step 425 of Figure 4).

[0101] At block 915, the AP receives the ANQP query from the STA (as depicted by step 425 of Figure 4). The query may request structured network metadata, such as Internet availability, venue name, domain name, or supported authentication and credential types. The metadata enables the STA to determine whether the network is suitable for connection.

[0102] At block 920, the AP sends an ANQP response to the STA, providing the requested metadata (as depicted by step 430 of Figure 4). If the metadata satisfies the STA’s selection policy, the AP may then receive an association request from the STA to establish a connection for network access.

[0103] Figure 10 depicts an example method 1000 performed by a network device for SSID obfuscation and roaming support using neighbor reports, according to some embodiments of the present disclosure. The network device supports wireless LAN functions and manages SSID configuration and association. The network device may correspond to a physical AP (e.g., AP 110-1 or 110-2 as depicted in Figure 1 , or AP 510-1 as depicted in Figure 5), or any other type of wireless infrastructure device capable of performing AP-related functionality (e.g., a residential or enterprise router, a mesh network node, a gateway device, or a virtualized AP within a software-defined networking (SDN) environment or cloud-managed infrastructure). The disclosed method 1000 may be particularly useful in a public network environment that supports neighbor reporting. In this configuration, the STA relies on the neighbor reports to identify and roam between nearby APs.

[0104] At block 1005, an AP (e.g., AP 110-1 or 110-2 of Figure 1 , or AP 510-1 of Figure 5) configures a common SSID (e.g., “Public Wi-Fi”) that is shared across multiple APs within the same venue (as depicted by step 515 of Figure 5). The AP further defines a temporal identifier associated with its ESS or MD. The temporal identifier is periodically updated (e.g., every 10 minutes) and is used to distinguish between overlapping ESSs or MDs that use the same SSID.

[0105] At block 1010, the AP broadcasts the common SSID and the current temporal identifier in its beacon or probe response frames (as depicted by step 520 of Figure 5).

[0106] At block 1015, the AP establishes an initial association with a STA (e.g., STA 105 of Figure 1 , STA 505 of Figure 5) (as depicted by step 525 of Figure 5).

[0107] At block 1020, the AP receives a neighbor reporting request from the associated STA (as depicted by step 530 of Figure 5). The request may be triggered by degrading link quality or proactive roaming behavior.

[0108] At block 1025, the AP generates a neighbor report. The report may include information about other nearby APs within the same ESS or MD, such as each neighbor’s BSSID, operating channel, PHY type, and other supported capabilities or metrics.

[0109] At block 1030, the AP sends the neighbor report to the STA (as depicted by step 535 of Figure 5). Based on the report, the STA may select a roaming target (e.g., AP 510-2 of Figure 5), and initiate an association process with the selected AP.

[0110] Figure 11 depicts an example method 1100 performed by a network device for SSID obfuscation and roaming support using a shared SSID obfuscation algorithm, according to some embodiments of the present disclosure. The network device supports wireless LAN functions and manages SSID configuration and association. The network device may correspond to a physical AP (e.g., AP 110-1 or 110-2 as depicted in Figure 1 , AP 610-1 as depicted in Figure 6), or any other type of wireless infrastructure device capable of performing AP-related functionality (e.g., a residential or enterprise router, a mesh network node, a gateway device, or a virtualized AP within a software-defined networking (SDN) environment or cloud-managed infrastructure). The disclosed method 1100 may be particularly useful in a public network environment where the infrastructure or platform does not support neighbor reporting for seamless roaming. To facilitate roaming with obfuscated SSIDs, the method 1100 relies on shared obfuscation algorithms and temporal identifiers to enable STAs to identify and transition between APs within the same ESS or MD.

[0111] At block 1105, an AP (e.g., AP 110-1 or 110-2 of Figure 1 , AP 610-1 of Figure 6) configures a common SSID (e.g., “Public Wi-Fi”) to be used by all participating APs across the venue (e.g., an airport), and defines a temporal identifier specific to the ESS or MD to which the AP belongs (as depicted by step 615 of Figure 6). The temporal identifier is used to distinguish between different ESSs that share the same SSID and is periodically updated to reduce tracking.

[0112] At block 1110, the AP broadcasts the common SSID and temporal identifier in its beacon or probe response frames (as depicted by step 620 of Figure 6). The broadcasting allows a STA (e.g., STA 605 of Figure 6) to discover the network and evaluate its temporal context before initial association.

[0113] At block 1115, the AP and STA establish an initial association (as depicted by step 625 of Figure 6).

[0114] At block 1120, the AP receives a setup request from the STA (as depicted by step 630 of Figure 6), which may include parameters that the STA indicates for setting up a private or base SSID specific to the ESS or MD to which the AP belongs. These parameters may reflect the STA’s roaming preferences, network naming policies, compatibility limits, or any seeds or keys used for SSID obfuscation.

[0115] At block 1125, based on the received parameters, the AP defines a base SSID for the ESS or MD, and configures a corresponding obfuscation algorithm (as depicted by step 635 of Figure 6). The algorithm enables deterministic transformation between the base SSID and obfuscated SSIDs. The algorithm may support either forward computation (e.g., hash or keyed generation) or reverse computation (e.g., XOR-based decoding).

[0116] At block 1130, the AP sends an SSID profile to the STA (as depicted by step 640 of Figure 6), which includes the base SSID, obfuscation algorithm, refresh interval or validity duration, and other parameters needed to resolve future obfuscated SSIDs. Additionally, in some embodiments, the AP may share the SSID profile with other APs within the same ESS or MD, so that the other APs can use the same obfuscation scheme to generate broadcast SSIDs.

[0117] At block 1135, the AP provides the updated temporal identifier to the STA. The updated temporal identifier may be sent proactively (e.g., via periodic update messages) (as depicted by step 650 of Figure 6), in response to a request from the STA, sent when the STA is preparing to roam (as depicted by step 655 of Figure 6), or through both mechanisms. The updating mechanism ensures that the STA remains synchronized with the ESS’s current identifier state. When the STA subsequently detects a decrease in link quality (such as due to signal attenuation or increased interference), the STA may begin listening for SSID broadcasts from other APs in the surrounding environment. Upon receiving such a broadcast, the STA may apply the shared obfuscation algorithm and the current temporal identifier to resolve the obfuscated SSIDs. If the resolved SSID matches the base SSID of the current ESS or MD, the STA may decide to roam to the corresponding AP and initiate a new association. The example method 1100 maintains the seamless connectivity without requiring explicit neighbor report support.

[0118] Figure 12 is a block diagram depicting a method 1200 for SSID obfuscation and discovery in a private network, according to some embodiments of the present disclosure.

[0119] At block 1205, a first network device (e.g., AP 210 of Figure 2) broadcasts a generic service set identifier (SSID) to enable a first station (STA) (e.g., STA 205 of Figure 2) to associate with the network device.

[0120] At block 1210, the first network device receives a setup request from the first STA, the setup request comprising one or more configuration parameters for a private SSID.

[0121] At block 1215, the first network device generates the private SSID and an SSID obfuscation algorithm for transforming between the private SSID and a pseudorandom SSID.

[0122] At block 1220, the first network device transmits the SSID obfuscation algorithm to the first STA for use in a future association.

[0123] In some embodiments, the first STA may be configured to discover the pseudo-random SSID broadcasted by the first network device, apply the SSIDobfuscation algorithm to transform the pseudo-random SSID into the private SSID, identify the private SSID as a known network based on the private SSID, and transmit an association request to the first network device.

[0124] In some embodiments, the first STA may share a profile with a second STA, the profile comprising at least one of the private SSID and the SSID obfuscation algorithm.

[0125] In some embodiments, the second STA, upon receiving the profile, may associate with the first network device without requiring user reconfiguration.

[0126] In some embodiments, the profile may be transferred to the second STA via at least one of a peer-to-peer sharing mechanism, synchronization through a user account, or an application-based or operating system-level sharing feature.

[0127] In some embodiments, the first network device may receive, from a second STA, an association request comprising the pseudo-random SSID and a security credential, where the second STA receives the pseudo-random SSID and the security credential from the first STA.

[0128] In some embodiments, prior to receiving the association request from the second STA, the first network device may receive a notification from the first STA, indicating that the pseudo-random SSID and the security credential are to be shared with the second STA, where the first network device accepts the association request from the second STA in response to the notification.

[0129] In some embodiments, the first network device may comprise at least one of an access point (AP), a wireless controller, a gateway device, or a cloud-based server.

[0130] In some embodiments, the first network device and a second network device may belong to a same extended service set (ESS) or mobility domain (MD) and share the private SSID, and the second network device may broadcast a second pseudorandom SSID derived from the private SSID using the SSID obfuscation algorithm.

[0131] In some embodiments, in response to determining to initiate roaming, the first STA may be configured to discover the second pseudo-random SSID by thesecond network device, apply the SSID obfuscation algorithm to transform the second pseudo-random SSID into the private SSID, identify the private SSID as a known network, and that the second network device belongs to the same ESS or MD as the first network device, and initiate a seamless roaming procedure to associate with the second network device.

[0132] In some embodiments, the STA may receive a neighbor report indicating the first network device and a second network device belong to a same extended service set (ESS) or mobility domain (MD), and the first STA may initiate a seamless roaming procedure to associate with the second network device based on the neighbor report.

[0133] Figure 13 is a block diagram depicting a method 1300 for SSID obfuscation and discovery in a private network with out-of-band SSID profile provisioning, according to some embodiments of the present disclosure.

[0134] At block 1305, a network device (e.g., AP 310 of Figure 3) generates an enterprise service set identifier (SSID) and an SSID obfuscation algorithm for transforming between the enterprise SSID and a pseudo-random SSID.

[0135] At block 1310, the network device transmits a profile to a station (STA) (e.g., STA 305 of Figure 3) via an out-of-band communication channel, the profile comprising the enterprise SSID and the SSID obfuscation algorithm.

[0136] At block 1315, the network device broadcasts, to the STA, the pseudorandom SSID derived from the enterprise SSID using the SSID obfuscation algorithm.

[0137] In some embodiments, the network device may receive an association request from the STA, where the STA identifies the pseudo-random SSID based on the SSID obfuscation algorithm and initiates the association request using the enterprise SSID.

[0138] In some embodiments, the out-of-band communication channel may comprise at least one of an email address, a web portal, a mobile device management (MDM) system, or an enterprise onboarding application.

[0139] In some embodiments, the network device may comprise at least one of an access point (AP), a wireless controller, a gateway device, or a cloud-based server.

[0140] Figure 14 is a block diagram depicting a method 1400 for SSID obfuscation and discovery in a public network, according to some embodiments of the present disclosure.

[0141] At block 1405, a first network device (e.g., AP 510-1 of Figure 5, AP 610-1 of Figure 6) that is part of a public wireless system broadcasts a common service set identifier (SSID) to a station (STA) (e.g., STA 505 of Figure 5, STA 605 of Figure 6), where the common SSID is shared by a plurality of network devices within the public wireless system.

[0142] At block 1410, the first network device broadcasts a temporal identifier to the STA, where the temporal identifier is shared between the first network device and a second network device (e.g., AP 510-2 of Figure 5, AP 610-2 of Figure 6) within the plurality of network devices, and the first network device and the second network device belong to a first extended service set (ESS) or mobility domain (MD).

[0143] At block 1415, the first network device updates the temporal identifier based on a defined time schedule.

[0144] In some embodiments, the STA may receive a neighbor report from the first network device, where the neighbor report identifies a plurality of neighboring network devices that belong to the first ESS or MD based on the temporal identifier.

[0145] In some embodiments, based on the temporal identifier, the STA may distinguish the first network device from one or more other network devices that broadcast the common SSID but belong to a second extended service set (ESS) or mobility domain (MD).

[0146] In some embodiments, the first network device may generate a base SSID for the first ESS or MD and an SSID obfuscation algorithm for transforming between the base SSID and a pseudo-random SSID, and transmit the SSID obfuscation algorithm to the STA.

[0147] In some embodiments, the STA is configured to discover the pseudorandom SSID and the temporal identifier broadcasted by the second network device, apply the SSID obfuscation algorithm to transform the pseudo-random SSID into the base SSID, identify the second network device as belonging to the first ESS or MD based on the base SSID and the temporal identifier, and transmit an association request to the second network device.

[0148] Figure 15 depicts an example network device 1500 configured to perform various aspects of the present disclosure, according to some embodiments of the present disclosure. The example network device 1500 may correspond to the AP 110- 1 or AP 110-2 as depicted in Figure 1 , AP 210 as depicted in Figure 2, AP 310 as depicted in Figure 3, AP 410 as depicted in Figure 4, AP 510 as depicted in Figure 5, AP 610 as depicted in Figure 6, or any other network device capable of managing SSID obfuscation mappings (e.g., an AP of a MLD, a wireless controller, a router, a gateway device, a logical radio within a virtualized AP platform, a cloud-based server).

[0149] As illustrated, the network device 1500 includes a processor 1505, memory 1510, storage 1515, one or more transceivers 1520, one or more I / O interfaces 1580, and one or more network interfaces 1525. In some embodiments, I / O devices 1570 are connected via the I / O interface(s) 1580. Further, via the network interface 1525, the network device 1500 can be communicatively coupled with one or more other devices and components (e.g., via a network, which may include the Internet, local network(s), and the like). Each of the components is communicatively coupled by one or more buses 1530. In some embodiments, one or more antennas 1535 may be coupled to the transceivers 1520 for transmitting and receiving wireless signals.

[0150] The processor 1505 is generally representative of a single central processing unit (CPU) and / or graphic processing unit (GPU), multiple CPUs and / or GPUs, a microcontroller, an application-specific integrated circuit (ASIC), or a programmable logic device (PLD), among others. The processor 1505 processes information received through the transceiver 1520, I / O interfaces 1580, and the network interfaces 1525. The processor 1505 retrieves and executes programming instructions stored in memory 1510, as well as stores and retrieves application data residing in storage 1515.

[0151] The storage 1515 may be any combination of disk drives, flash-based storage devices, and the like, and may include fixed and / or removable storage devices, such as fixed disk drives, removable memory cards, caches, optical storage, network attached storage (NAS), or storage area networks (SAN). The storage 1515 may store a variety of data for the efficient functioning of the system.

[0152] The memory 1510 may include random access memory (RAM) and readonly memory (ROM). The memory 1510 may store processor-executable software code containing instructions that, when executed by the processor 1505, enable the network device 1500 to perform various functions described herein for wireless communication. The memory 1510 includes a SSID broadcast component 1245, a SSID obfuscation engine 1250, a profile management component 1255, a temporal identifier generator 1260, and an OOB provisioning component 1265.

[0153] In one embodiment, the SSID broadcast component 1245 is configured to generate and transmit SSIDs via beacon or probe response frames. The SSID broadcast component 1245 handles both generic (initial setup) and obfuscated SSID advertisements.

[0154] In one embodiment, the SSID obfuscation engine 1250 implements the logic for transforming private or base SSIDs into pseudo-random obfuscated SSIDs using configured algorithms. It may support forward computation (e.g., hash-based or timebased transformation) or reverse encoding (e.g., XOR-based mapping). The SSID obfuscation engine 1250 also manages rotation logic tied to time intervals or policy triggers.

[0155] In one embodiment, the profile management component 1255 manages generation, storage, and distribution of SSID profiles that include obfuscation parameters, private SSID, temporal identifiers, and validity data. The profile management component 1255 handles delivery of profiles to STAs (e.g., during initial setup or provisioning) and to peer APs within the same ESS or MD.

[0156] In one embodiment, the temporal identifier generator 1260 creates and periodically updates temporal identifiers used to distinguish ESSs or MDs sharing the same common SSID.

[0157] In one embodiment, the OOB provisioning component 1265 supports secure delivery of SSID profiles and configuration parameters to STAs via OOB methods (e.g., through an MDM system, QR code, or secure web portal).

[0158] Although depicted as a discrete component for conceptual clarity, in some embodiments, the operations of the depicted components (and others not illustrated) may be combined or distributed across any number of components. Further, although depicted as software residing in memory 1510, in some aspects, the operations of the depicted components (and others not illustrated) may be implemented using hardware, software, or a combination of hardware and software.

[0159] In the current disclosure, reference is made to various embodiments. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Additionally, when elements of the embodiments are described in the form of “at least one of A and B,” or “at least one of A or B,” it will be understood that embodiments including element A exclusively, including element B exclusively, and including elements A and B are each contemplated. Furthermore, although some embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the aspects, features, embodiments and advantages disclosed herein are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

[0160] As will be appreciated by one skilled in the art, the embodiments disclosed herein may be embodied as a system, method or computer program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, embodimentsmay take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

[0161] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0162] Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0163] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments presented in this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the block(s) of the flowchart illustrations and / or block diagrams.

[0164] These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processingapparatus, or other device to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function / act specified in the block(s) of the flowchart illustrations and / or block diagrams.

[0165] The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device provide processes for implementing the functions / acts specified in the block(s) of the flowchart illustrations and / or block diagrams.

[0166] As one example, there is provided a computer readable medium carrying instructions which, when executed by one or more processors, causes any of the methods described herein to be carried out.

[0167] As one example, there is provided apparatus for performing any of the methods described herein. The apparatus may be a single device or a system of one or more devices.

[0168] The flowchart illustrations and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart illustrations or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware and computer instructions.

[0169] In view of the foregoing, the scope of the present disclosure is determined by the claims that follow.

Claims

Claims1 . A method, comprising: broadcasting, by a first network device, a generic service set identifier (SSID) to enable a first station (STA) to associate with the first network device; receiving, by the first network device, a setup request from the first STA, the setup request comprising one or more configuration parameters for a private SSID; generating, by the first network device, the private SSID and an SSID obfuscation algorithm for transforming between the private SSID and a pseudorandom SSID; and transmitting, by the first network device, the SSID obfuscation algorithm to the first STA for use in a future association.

2. The method of claim 1 , wherein, during the future association, the first STA is configured to: discover the pseudo-random SSID broadcasted by the first network device, apply the SSID obfuscation algorithm to transform the pseudo-random SSID into the private SSID, identify the private SSID as a known network based on the private SSID, and transmit an association request to the first network device.

3. The method of claim 1 or 2, wherein the first STA shares a profile with a second STA, the profile comprising at least one of the private SSID and the SSID obfuscation algorithm.

4. The method of claim 3, wherein the second STA, upon receiving the profile, associates with the first network device without requiring user reconfiguration.

5. The method of claim 3 or 4, wherein the profile is transferred to the second STA via at least one of: a peer-to-peer sharing mechanism, synchronization through a user account, or an application-based or operating system-level sharing feature.

6. The method of any preceding claim, further comprising: receiving, by the first network device and from a second STA, an association request comprising the pseudo-random SSID and a security credential, wherein the second STA receives the pseudo-random SSID and the security credential from the first STA.

7. The method of claim 6, wherein, prior to receiving the association request from the second STA, the method further comprises: receiving, by the first network device and from the first STA, a notification indicating that the pseudo-random SSID and the security credential are to be shared with the second STA, wherein the first network device accepts the association request from the second STA in response to the notification.

8. The method of any preceding claim, wherein the first network device comprises at least one of an access point (AP), a wireless controller, a gateway device, or a cloud-based server.

9. The method of any preceding claim, wherein the first network device and a second network device belong to a same extended service set (ESS) or mobility domain (MD) and share the private SSID, and the second network device broadcasts a second pseudo-random SSID derived from the private SSID using the SSID obfuscation algorithm.

10. The method of claim 9, wherein, in response to determining to initiate roaming, the first STA is configured to: discover the second pseudo-random SSID by the second network device; apply the SSID obfuscation algorithm to transform the second pseudo-random SSID into the private SSID; identify the private SSID as a known network, and that the second network device belongs to the same ESS or MD as the first network device; and initiate a seamless roaming procedure to associate with the second network device.11 . The method of any preceding claim, wherein the STA receives a neighbor report indicating the first network device and a second network device belong to a same extended service set (ESS) or mobility domain (MD), and the first STA initiates a seamless roaming procedure to associate with the second network device based on the neighbor report.

12. A method, comprising: generating, by a network device, an enterprise service set identifier (SSID) and an SSID obfuscation algorithm for transforming between the enterprise SSID and a pseudo-random SSID; transmitting, by the network device, a profile to a station (STA) via an out-of- band communication channel, the profile comprising the enterprise SSID and the SSID obfuscation algorithm; and broadcasting, by the network device and to the STA, the pseudo-random SSID derived from the enterprise SSID using the SSID obfuscation algorithm.

13. The method of claim 12, further comprising: receiving, by the network device, an association request from the STA, wherein the STA identifies the pseudo-random SSID based on the SSID obfuscation algorithm and initiates the association request using the enterprise SSID.

14. The method of claim 12 or 13, wherein the out-of-band communication channel comprises at least one of: an email address, a web portal, a mobile device management (MDM) system, or an enterprise onboarding application.

15. The method of any of claims 12 to 14, wherein the network device comprises at least one of an access point (AP), a wireless controller, a gateway device, or a cloud-based server.

16. A method, comprising: broadcasting, by a first network device that is part of a public wireless system, a common service set identifier (SSID) to a station (STA), wherein the common SSID is shared by a plurality of network devices within the public wireless system; broadcasting, by the first network device, a temporal identifier to the STA, wherein the temporal identifier is shared between the first network device and a second network device within the plurality of network devices, and the first network device and the second network device belong to a first extended service set (ESS) or mobility domain (MD); and updating, by the first network device, the temporal identifier based on a defined time schedule.

17. The method of claim 16, wherein the STA receives a neighbor report from the first network device, wherein the neighbor report identifies a plurality of neighboring network devices that belong to the first ESS or MD based on the temporal identifier.

18. The method of claim 16 or 17, wherein, based on the temporal identifier, the STA distinguishes the first network device from one or more other network devices that broadcast the common SSID but belong to a second extended service set (ESS) or mobility domain (MD).

19. The method of any of claims 16 to 18, further comprising: generating, by the first network device, a base SSID for the first ESS or MD and an SSID obfuscation algorithm for transforming between the base SSID and a pseudo-random SSID; and transmitting, by the first network device, the SSID obfuscation algorithm to the STA.

20. The method of claim 19, wherein the STA is configured to: discover the pseudo-random SSID and the temporal identifier broadcasted by the second network device; apply the SSID obfuscation algorithm to transform the pseudo-random SSID into the base SSID; identify the second network device as belonging to the first ESS or MD based on the base SSID and the temporal identifier; and transmit an association request to the second network device.21 . Apparatus arranged to perform the method of any preceding claim.

22. A computer readable medium carrying instructions which, when executed by one or more processors cause the method of any of claims 1 to 20 to be carried out.

Images