Systems and methods for improved access point discovery with dynamic dwell time

Abstract

This disclosure describes systems and methods for improving access point discovery with dynamic dwell time. A station may transmit a probe request to be received by an access point. The probe request may identify a scan dwell time of the station. While waiting for the probe response during the scan dwell time, the station may determine that the probe response has not been received from the access point at a certain point in time during the scan dwell time. In response to the determination, the station may dynamically increase the scan dwell time while waiting for the probe response from the access point. The access point may receive the probe request and determine whether to respond within the scan dwell time. The access point may identify an associated time metric and generate the probe response. The access point may transmit the probe response to the station during the scan dwell time.

Description

[0001] Cross-referencing of related patent applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 682,247, filed August 12, 2024, and to U.S. Provisional Application No. 63 / 651,275, filed May 23, 2024, the entire contents of each of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to systems and methods for wireless communication between access points and wireless communication devices, including but not limited to improving access point discovery with dynamic dwell time. Background Technology

[0004] The market for wireless communication devices has been growing due to the increasing use of portable devices, increased connectivity, and data transfer between various devices. Digital switching technology has facilitated the large-scale deployment of affordable and easy-to-use wireless communication networks. Wireless communication can operate according to various standards, such as IEEE 802.11x (e.g., Wi-Fi technology), Bluetooth, Global System for Mobile Communications (GSM), and Code Division Multiple Access (CDMA). Using such technologies, wireless communication devices can connect to local area networks and the Internet without physical cables, enabling communication across various spaces and ranges via radio frequency. Summary of the Invention

[0005] This disclosure relates to a technical solution that improves access point discovery using dynamic dwell time. In a wireless local area network (WLAN), access points and client devices can communicate wirelessly within a localized area, such as a home, office, or campus. WLANs support a wide range of applications, from basic web browsing to real-time communication and entertainment services such as audio / video conferencing and online gaming. These applications require not only efficient data transmission but also timely delivery of data packets to ensure a seamless user experience. In dense WLAN environments, non-AP stations (STAs) often struggle to discover available access points (APs) within a limited scanning dwell time, resulting in inefficient network connectivity. This challenge may arise primarily from factors such as overlapping basic service sets (BSS), which can cause interference and congestion when multiple WLAN networks operate on a shared channel. High levels of channel congestion can make it difficult for STAs to receive beacon or probe responses within their allocated time. Furthermore, in some cases, access points may prioritize other tasks over responding to probe requests, resulting in delays in response time. Consequently, even in environments with low congestion, this can cause STAs to experience delays in receiving responses. Furthermore, limited scan dwell time restricts the amount of time a STA can spend scanning an AP. As a result, STAs may experience delayed connections, especially in areas with high AP density, leading to roaming issues and frequent AP handovers, which can cause disconnections and service interruptions. Similarly, network performance may degrade due to interference and congestion, thereby reducing data throughput.

[0006] The technical solutions disclosed herein overcome the challenges of inefficient access point discovery, limited scan dwell time, channel congestion, overlapping BSS, and degraded network performance in dense WLAN environments. The technical solutions may include changes on both the STA and AP sides. For example, on the STA side, special proprietary elements can be added, containing fields such as specifying the scan dwell time (SDT) on the channel and the priority of probe requests. Priorities can be categorized into different values: low priority for initial unassociated scans or discovery, normal priority for regular roaming scans or background associated scans, and high priority for final roaming scans. On the AP side, the access point can use information and priorities from the STA's SDT to determine how to manage probe requests. For example, the AP can prioritize probe responses and / or beacon frames to provide reliable delivery within the STA's SDT, or, if network congestion prevents timely scheduling of probe responses, the AP can indefinitely postpone responses to avoid wasting airtime. In some cases, the AP can use voice access class (AC-VO) to prioritize probe responses, beacon frames, or certain types of traffic.

[0007] Technical solutions can include additional enhancements to the AP's management of probe requests. For example, the AP can include the average response time of STA probe requests as part of a proprietary element in the beacon and probe response frames, called the Average Response Time of Probe Requests (ART-PReq). The AP can also include the ART-PReq value in the Simplified Neighbor Report (RnR) element for all co-located APs. The AP can also provide information about channel congestion (CC) or channel utilization (CU) for all co-located APs within the RnR element. Non-AP STAs can use the CC, CU, or ART-PReq values ​​from the AP via RnR or beacons to make informed decisions, such as adjusting dwell time when scanning for co-located APs on their channels, or discovering co-located APs via multi-link (ML) probes if the AP has multi-link operation (MLO) capabilities. When the response time or CU of a co-located AP is poor, configuration can be useful, allowing STAs to use the ART-PReq of the reporting AP to modify the dwell time during ML probes to improve network performance. The technical solutions described in this article are scalable to future standards, such as the 802.11bn (UHR / Wi-Fi 8) specification.

[0008] Similarly, the technical solution may include the AP providing an average response time metric for additional frames, such as authentication (ART-AuthReq) and (re)association (ART-AssocReq) frames. This metric can be used by the STA to fine-tune the channel dwell time during authentication and association. Furthermore, the configuration can be extended to action frames, such as adding block acknowledgment (ADDBA) requests / responses and ART-ActionReq, allowing the STA to further enhance its dwell time and improve overall network performance during these interactions.

[0009] Furthermore, the technical solution allows STAs to dynamically increase their scan dwell time based on localized interference. For example, if an STA does not receive a response from an AP after half of its scan dwell time and determines that channel congestion is high (e.g., attributed to Energy Detection (ED) or Overlapping Basic Service Set (OBSS) frames), the STA can dynamically increase its scan dwell time to account for delays in probe response delivery. Additionally, the AP can reduce unnecessary probe response deliveries by detecting and ignoring duplicate probe requests. If the AP has already queued responses to previous requests, it can avoid responding to new probe requests until previously generated responses have been processed. The technical solution disclosed herein enhances access point discovery and overall network efficiency.

[0010] At least one aspect of the technical solution relates to a system for improving access point discovery using dynamic dwell time. The system may include a station. The station may include one or more processors coupled to a memory. The one or more processors may generate probe requests for access point discovery. The probe requests may identify the station's scan dwell time and priority. The one or more processors may transmit the probe requests to be received by an access point. The one or more processors may receive probe responses from the access point. The probe responses may identify a metric including the time taken for the access point to respond to the probe requests. In response to the probe responses, the one or more processors may adjust the station's scan dwell time for subsequent probe requests.

[0011] In some embodiments, the access point may respond to the probe request at least based on the priority of the probe request within the identified scan dwell time. In some embodiments, the metric may include the average response time of the access point in responding to the probe request. In some embodiments, the probe request may include a field identifying the metric. In some embodiments, the field may include a custom field or a standard-defined field. The metric may include at least the scan dwell time or a priority value, wherein the priority value includes at least one of a low priority value, a normal priority value, or a high priority value. In some embodiments, the one or more processors may adjust the scan dwell time at least based on the metric. The metric may include at least one of channel congestion, channel utilization, or the average response time of the probe request. In some embodiments, the access point may be a co-located access point. In some embodiments, the one or more processors may receive the metric via a simplified neighbor report from the co-located access point.

[0012] In some embodiments, the one or more processors may scan the co-located access point based at least on the average response time of the probe requests from the co-located access point or the congestion metric obtained from the simplified neighbor report, or scan the co-located access point using multi-link probe. In some embodiments, the one or more processors may adjust the dwell time for at least one of authentication requests, association requests, reassociation requests, or Add Block Acknowledgment (ADDBA) requests based on the average response time provided by the access point for the corresponding request.

[0013] Another aspect of the technical solution relates to a system for improving access point discovery using dynamic dwell time. The system may include a station. The station may include one or more processors coupled to a memory. The one or more processors may issue probe requests to be received by an access point. The station may include a scan dwell time for waiting for a probe response. While waiting for the probe response during the scan dwell time, the one or more processors may determine that a probe response has not been received from the access point at a certain point during the scan dwell time. In response to this determination, the one or more processors may dynamically increase the scan dwell time while waiting for the probe response from the access point.

[0014] In some embodiments, the one or more processors may dynamically increase the scan dwell time based at least on metrics received from the access point. The metrics may include at least one of channel congestion, channel utilization, or the average response time to a probe request. In some embodiments, the one or more processors may dynamically increase the scan dwell time based at least on local interference. The local interference may include at least one of energy detection frames or overlapping basic service set frames.

[0015] Another aspect of the technical solution relates to a system for improving access point discovery using dynamic dwell time. The system may include an access point. The access point may include one or more processors coupled to a memory. The one or more processors may receive probe requests from a station. The probe request may identify the station's scan dwell time and priority. The one or more processors may determine, at least based on the priority, to respond to the probe request within the scan dwell time. The one or more processors may identify one or more time metrics for the access point's response to the probe request, wherein the time metrics may be determined at least based on channel congestion or channel utilization. The one or more processors may generate a probe response that includes one or more of the time metrics for the access point's response to the probe request. The one or more processors may transmit the probe response within the scan dwell time.

[0016] In some embodiments, the one or more processors may suspend the transmission of the probe response when it is determined that the probe response cannot be scheduled during the scan dwell time. In some embodiments, the one or more processors may transmit the probe response to the station via a second access point associated with the station, wherein the second access point may be identified based on a basic service set identifier included in the probe request. In some embodiments, the metric may further include the average response time of at least one of an authentication request, association request, reassociation request, or Add Block Acknowledgment (ADDBA) request from the station. In some embodiments, the one or more processors may transmit a simplified neighbor report to a co-located access point, wherein the simplified neighbor report includes at least one of channel congestion or channel utilization.

[0017] Another aspect of the technical solution relates to a system for improving access point discovery using dynamic dwell time. The system may include an access point. The access point may include one or more processors coupled to a memory. The one or more processors may receive probe requests from a station. The probe requests may identify the station's scan dwell time. The one or more processors may determine that the access point cannot transmit a probe response during the station's scan dwell time. The one or more processors may skip transmitting the probe response. The one or more processors may queue the probe requests until the resolution of the probe requests occurs. While queuing the probe requests, the one or more processors may ignore duplicate probe requests from the station. In some embodiments, the one or more processors may detect duplicate probe requests from the station. In some embodiments, the one or more processors may be further configured to prioritize the probe responses based on a priority value associated with the probe request, wherein the priority value may include at least one of low priority, normal priority, or high priority values. Attached Figure Description

[0018] The various objects, aspects, features, and advantages of this disclosure will become more apparent and better understood through a detailed description taken in conjunction with the accompanying drawings, wherein similar reference numerals identify corresponding elements throughout. In the drawings, similar reference numerals generally indicate identical, functionally similar, and / or structurally similar elements.

[0019] Figure 1A The illustration depicts a block diagram of a network environment comprising one or more access points communicating with one or more devices or stations, according to one or more embodiments.

[0020] Figure 1B and 1C The illustration depicts a block diagram of a computing device that can be used in conjunction with the methods and systems described herein, according to one or more embodiments.

[0021] Figure 2 A block diagram illustrating an instance system for improving access point discovery using dynamic dwell time, according to one or more embodiments.

[0022] Figure 3 Example flowchart illustrating a method for improving access point discovery using dynamic dwell time, according to one or more embodiments.

[0023] Figures 4 to 6 This describes an instance implementation scheme for access point discovery based on one or more embodiments.

[0024] Figure 7 A flowchart illustrating another example of a method for improving access point discovery using dynamic dwell time, according to one or more embodiments.

[0025] Figures 8 to 11 This describes another implementation of the access point discovery method based on one or more embodiments. Detailed Implementation

[0026] The following IEEE standards (including any draft versions of these standards) are hereby incorporated herein by reference in their entirety and are part of this disclosure for all these purposes: Wi-Fi Alliance standards and IEEE 802.11 standards, including but not limited to IEEE 802.11a. TM IEEE 802.11b TM IEEE 802.11g TM IEEE P802.11n TM IEEE P802.11ac TM ; and IEEE P802.11be TM To IEEE P802.11bn TM Standards. Although this disclosure may refer to aspects of these standards, it is in no way limited by them.

[0027] For the purpose of reading the descriptions of the various embodiments below, the following descriptions of the sections of the specification and their corresponding contents may be helpful:

[0028] Section A describes the network and computing environments that can be used to practice the embodiments described herein; and

[0029] Section B describes systems and methods for improving access point discovery using dynamic dwell time.

[0030] A. Computing and Networking Environment

[0031] Before discussing specific embodiments of this solution, it may be helpful to describe aspects of the operating environment and associated system components (e.g., hardware elements) in conjunction with the methods and systems described herein. References Figure 1A This describes an embodiment of a network environment. In brief, the network environment includes a wireless communication system comprising one or more access points (APs) or network devices 106, one or more stations or wireless communication devices 102, and network hardware components or network hardware 192. Wireless communication device 102 may, for example, include a laptop computer, tablet computer, personal computer, and / or cellular phone device. Reference Figure 1B and 1C More detailed descriptions are provided for embodiments of each station or wireless communication device 102 and AP or network device 106. In one embodiment, the network environment may be an ad hoc network environment, an infrastructure wireless network environment, a subnet environment, etc. Network device 106 or AP may be operatively coupled to network hardware 192 via a local area network (LAN) connection. In some embodiments, network device 106 is a 5G base station. Network hardware 192, which may include routers, gateways, switches, bridges, modems, system controllers, appliances, etc., may provide LAN connectivity for the communication system. Each of network device 106 or AP may have an associated antenna or antenna array to communicate with wireless communication devices in its area. Wireless communication device 102 may register with a specific network device 106 or AP to receive services from the communication system (e.g., via SU-MIMO or MU-MIMO configuration). For direct connections (e.g., point-to-point communication), some wireless communication devices may communicate directly via allocated channels and communication protocols. Some of the wireless communication devices 102 may be mobile or relatively stationary relative to network device 106 or AP.

[0032] In some embodiments, network device 106 or AP includes means or modules (comprising a combination of hardware and software) that allow wireless communication device 102 to connect to a wired network using Wi-Fi or other standards. Network device 106 or AP may sometimes be referred to as a wireless access point (WAP). Network device 106 or AP may be implemented (e.g., configured, designed, and / or built) for operation in a wireless local area network (WLAN). In some embodiments, network device 106 or AP may be connected as a standalone device to a router (e.g., via a wired network). In other embodiments, network device 106 or AP may be a component of a router. Network device 106 or AP may provide network access to multiple devices. Network device 106 or AP may, for example, connect to a wired Ethernet connection and use a radio frequency link to provide wireless connectivity for other communication devices 102 to utilize the wired connection. Network device 106 or AP may be implemented to support standards for transmitting and receiving data using one or more radio frequencies. Those standards and the frequencies they use may be defined by IEEE (e.g., the IEEE 802.11 standard). Network device 106 or AP may be configured and / or used to support public Internet hotspots and / or to extend the Wi-Fi signal range of a network.

[0033] In some embodiments, access point or network device 106 may be used for (e.g., in a home, vehicle, or building) wireless networks (e.g., IEEE 802.11, Bluetooth, ZigBee, any other type of radio frequency-based network protocol, and / or variations thereof). Each of the wireless communication devices 102 may include a built-in radio and / or be coupled to a radio. Such wireless communication devices 102 and / or access point or network device 106 may operate according to various aspects of the present disclosure presented herein to enhance performance, reduce cost and / or size, and / or enhance broadband applications. Each wireless communication device 102 may have the capability to act as a client node seeking access to resources (e.g., data and connections to networked nodes, such as servers) via one or more access point or network devices 106.

[0034] The network connection may include any type and / or form of network, and may include any of the following: point-to-point network, broadcast network, telecommunications network, data communication network, computer network. The network topology may be a bus, star, or ring network topology. The network may be any such network topology known to those skilled in the art capable of supporting the operations described herein. In some embodiments, different types of data may be transmitted via different protocols. In other embodiments, the same type of data may be transmitted via different protocols.

[0035] The communication device 102 and the access point or network device 106 may be deployed as any type and form of computing device and / or executed on any type and form of computing device, such as a computer, network device or appliance capable of communicating and performing the operations described herein on any type and form of network. Figure 1B and 1C A block diagram depicting a computing device 100 that can be used to implement embodiments of wireless communication device 102 or network device 106. (See diagram for reference.) Figure 1B and 1C As shown, each computing device 100 includes a processor 121 (e.g., a central processing unit) and a main memory unit 122. Figure 1B As shown, the computing device 100 may include a storage device 128, a mounting device 116, a network interface 118, an input / output (I / O) controller 123, display devices 124a to 124n, a keyboard 126, and a pointing device 127 (e.g., a mouse). The storage device 128 may include an operating system and / or software. Figure 1C As shown, each computing device 100 may also include additional optional elements that communicate with the central processing unit or processor 121, such as memory port 103, bridge 170, one or more I / O devices 130a to 130n, and cache memory 140.

[0036] The central processing unit or processor 121 is any logic circuit system that responds to and processes instructions fetched from main memory unit 122. In many embodiments, the central processing unit or processor 121 is provided by a microprocessor unit, such as a microprocessor unit manufactured by Intel Corporation of Santa Clara, California; a microprocessor unit manufactured by International Business Machines of White Plains, New York; or a microprocessor unit manufactured by Advanced Micro Devices of Sunnyvale, California. The computing device 100 may be based on any of these processors, or any other processor capable of operating as described herein.

[0037] Main memory unit 122 may be one or more memory chips capable of storing data and allowing direct access from any storage location by a microprocessor or processor 121, such as any type or variant of static random access memory (SRAM), dynamic random access memory (DRAM), ferroelectric RAM (FRAM), NAND flash memory, NOR flash memory, and solid-state drive (SSD). Main memory unit 122 may be based on any of the aforementioned memory chips, or any other available memory chip capable of operating as described herein. Figure 1B In the embodiment shown, the processor 121 communicates with the main memory unit 122 via the system bus 150 (described in more detail below). Figure 1C An embodiment of computing device 100 is depicted, wherein the processor communicates directly with main memory unit 122 via memory port 103. For example, in Figure 1C In this context, the main memory unit 122 can be DRDRAM.

[0038] Figure 1C An embodiment is depicted in which the main processor 121 communicates directly with the cache memory 140 via a secondary bus (sometimes referred to as the back-side bus). In other embodiments, the main processor 121 communicates with the cache memory 140 using a system bus 150. The cache memory 140 typically has a faster response time than the main memory unit 122 and is provided by, for example, SRAM, BSRAM, or EDRAM. Figure 1C In the embodiments shown, processor 121 communicates with various I / O devices 130 via local system bus 150. Various buses can be used to connect the central processing unit or processor 121 to any of the I / O devices 130, such as VESA VL bus, ISA bus, EISA bus, Micro Channel Architecture (MCA) bus, PCI bus, PCI-X bus, PCI-Express bus, or NuBus. In embodiments where the I / O device is a video display 124, processor 121 may use an Advanced Graphics Port (AGP) to communicate with the display 124. Figure 1C An embodiment of a computer or computer system 100 is depicted, wherein the main processor 121 may communicate directly with the I / O device 130b, for example, via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communication technologies. Figure 1C An embodiment in which a hybrid local bus and direct communication is also depicted: the processor 121 communicates with I / O device 130a using the local interconnect bus, while simultaneously communicating directly with I / O device 130b.

[0039] Various I / O devices 130a to 130n may be present in the computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, dial pads, touchpads, touch screens, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, projectors, and dye-sublimation printers. For example... Figure 1B As shown, the I / O devices can be controlled by I / O controller 123. The I / O controller can control one or more I / O devices, such as keyboard 126 and pointing device 127, such as a mouse or optical pen. Furthermore, the I / O devices can also provide storage and / or mounting media for the computing device 100. In yet another embodiment, the computing device 100 may provide a USB connection (not shown) to receive a handheld USB storage device, such as a USB flash drive series device manufactured by Twintech Industry, Inc., Los Alamitos, California.

[0040] Refer again Figure 1B The computing device 100 may support any suitable installation device 116, such as a disk drive, CD-ROM drive, CD-R / RW drive, DVD-ROM drive, flash drive, tape drive of various formats, USB device, hard disk drive, network interface, or any other device suitable for installing software and programs. The computing device 100 may further include storage devices for storing the operating system and other related software, and for storing application software programs (e.g., any program or software 120 for implementing (e.g., configured and / or designed for) the systems and methods described herein), such as one or more hard disk drives or redundant arrays of independent disks. Optionally, any of the installation devices 116 may also be used as storage devices. Furthermore, the operating system and software may run from bootable media.

[0041] Furthermore, the computing device 100 may include a network interface 118 to interface with a network via various connections, including but not limited to standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECNET), broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET), wireless connections, or any or all of the above connections. Connections can be established using various communication protocols (e.g., TCP / IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE 802.11, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac, IEEE 802.11ad, CDMA, GSM, WiMax, and Direct Asynchronous Connection). In one embodiment, computing device 100 communicates with other computing devices 100' via any type and / or form of gateway or tunneling protocol (e.g., Secure Sockets Layer (SSL) or Transport Layer Security (TLS)). Network interface 118 may include a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing computing device 100 to any type of network capable of communicating and performing the operations described herein.

[0042] In some embodiments, computing device 100 may include or be connected to one or more display devices 124a to 124n. Therefore, any of the I / O devices 130a to 130n and / or the I / O controller 123 may include any type and / or form of suitable hardware, software, or a combination of hardware and software to support, enable, or provide connectivity and use by computing device 100 to (a number of) display devices 124a to 124n. For example, computing device 100 may include any type and / or form of video adapter, video card, driver, and / or library to interface with, communicate with, connect to, or otherwise use (a number of) display devices 124a to 124n. In one embodiment, a video adapter may include multiple connectors to interface with (a number of) display devices 124a to 124n. In other embodiments, computing device 100 may include multiple video adapters, each of which is connected to (a number of) display devices 124a to 124n. In some embodiments, any portion of the operating system of the computing device 100 may be configured to use multiple display devices 124a to 124n. In another embodiment, the I / O device 130 may be a bridge between the system bus 150 and external communication buses (e.g., USB bus, Apple Desktop bus, RS-232 serial connection, SCSI bus, FireWire bus, FireWire 800 bus, Ethernet bus, AppleTalk bus, Gigabit Ethernet bus, Asynchronous Transfer Mode bus, Fibre Channel bus, Fibre bus, Serial Attached Small Computer System Interface bus, USB connection, or HDMI bus).

[0043] Figure 1B and 1CThe computing device 100 of the type described herein can operate under the control of an operating system that controls task scheduling and access to system resources. The computing device 100 can run any operating system, such as any version of Microsoft Windows, different versions of Unix and Linux, any version of macOS for Macintosh computers, any embedded operating system, any real-time operating system, any open-source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system capable of running on a computing device and performing the operations described herein. Typical operating systems include, but are not limited to: Android, produced by Google Inc.; Windows 7, 8, and 10, produced by Microsoft Corporation of Redmond, Washington; MAC OS, produced by Apple Computer of Cupertino, California; WebOS, produced by Research In Motion (RIM); OS / 2, produced by International Business Machines of Armonk, New York; and Linux, a free operating system released by Caldera of Salt Lake City, Utah, or any type and / or form of Unix operating system and other operating systems.

[0044] The computer system or computing device 100 may be any workstation, telephone, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone or other portable telecommunications device, media playback device, gaming system, mobile computing device, or any other type and / or form of computing, telecommunications, or media device capable of communication. In some embodiments, the computing device 100 may have a different processor, operating system, and input device consistent with the device. For example, in one embodiment, the computing device 100 is a smartphone, mobile device, tablet computer, or personal digital assistant. Furthermore, the computing device 100 may be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone, any other computer, or other form of computing or telecommunications device capable of communication and having sufficient processor power and memory capacity to perform the operations described herein.

[0045] The aspects of the operating environment and components described above will become apparent in the context of the systems and methods disclosed herein.

[0046] B. Used for Improving Access Point Discovery Systems and Methods with Dynamic Dwell Time

[0047] The following is a detailed description of various concepts and embodiments of the technologies, methods, devices, and systems related to improving access point discovery with dynamic dwell time. The various concepts introduced above and discussed in more detail below can be implemented in many ways, as the described concepts are not limited to any particular implementation. Specific embodiments and examples of applications are provided primarily for illustrative purposes.

[0048] The technical solutions disclosed herein address challenges such as inefficient access point (AP) discovery, limited scan dwell time, channel congestion, overlapping basic service sets (BSS), and degraded network performance in dense wireless local area network (WLAN) environments. On the non-AP (STA) side, custom or standard-defined fields can be added to probe requests to identify scan dwell time (SDT) and priority, with the classification ranging from low to high priority for different scan configurations. On the AP side, the access point can prioritize probe responses based on the STA's SDT and priority, thereby maintaining timely delivery or deferring responses if congestion prevents scheduling within the SDT. The AP can also use Voice Access Class (AC-VO) to prioritize traffic. Furthermore, the AP can include the Average Response Time metric (ART-PReq) along with channel congestion (CC) and channel utilization (CU) information for co-located APs in the beacon or probe response frame and in the Simplified Neighbor Report (RnR) element. For example, in situations of poor performance or high congestion, STAs can utilize ART-PReq, CC, and CU data from RnR or beacons to adjust their dwell time or perform multi-link (ML) probing while scanning co-located APs. The technical solution is scalable to future standards such as 802.11bn (UHR / Wi-Fi 8). Furthermore, APs can provide average response time metrics for authentication (ART-AuthReq) and (re)association (ART-AssocReq) frames, enabling STAs to fine-tune their dwell time during these processes and extend the adjustments to action frames such as ADDBA-request / response and ART-ActionReq. Additionally, STAs can dynamically increase their scanning dwell time based on localized interference (e.g., Energy Detection (ED) or Overlapping BSS (OBSS) frames), while APs can detect and ignore duplicate probing requests to reduce unnecessary response deliveries. Therefore, the technical solutions disclosed herein improve access point discovery and overall network efficiency.

[0049] Figure 2This describes an example system 200 for improving access point discovery using dynamic dwell time. Example system 200 may include one or more access points 205A to 205N (sometimes referred to herein as access point 205), which are communicatively coupled to one or more stations 215A to 215N (sometimes referred to herein as station 215) via one or more networks 210. Figures 1A to 1C Any of the components in the described system may be configured, constructed, or implemented to implement, operate, and / or use. Figure 2 Any of the options and technologies described herein.

[0050] Access point 205 may include means, systems, or modules (combining hardware and software) that allow wireless communication devices to connect to a wired network using Wi-Fi or other standards. Access point 205 may sometimes be referred to as a wireless access point (WAP). Access point 205 may include components such as antennas for transmitting and receiving wireless signals, radio devices for managing wireless communication, a CPU for processing data and control operations, and memory (DDR) for storing operational data and configurations. Access point 205 may be implemented (e.g., configured, designed, and / or constructed) to operate in a wireless local area network (WLAN). In some embodiments, access point 205 may be connected as a standalone device to a router (e.g., via a wired network). In some embodiments, access point 205 may be a component of a router. Access point 205 may provide network access to multiple devices. For example, access point 205 may connect to a wired Ethernet connection and use a radio frequency link to provide wireless connectivity for other devices to utilize the wired connection. Access point 205 may be implemented to support standards for transmitting and receiving data using one or more radio frequencies. These standards and the frequencies they use may be defined by IEEE (e.g., IEEE 802.11 standard). Access point 205 may be configured and / or used to support Internet hotspots and / or extend the Wi-Fi signal range of a network over the network.

[0051] Network 210 may include computer networks such as the Internet, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs) or other regional networks, intranets, satellite networks, other computer networks (e.g., voice or data mobile phone communication networks), and combinations thereof. Network 210 may be any form of computer network capable of relaying information between access point 205, station 215, and one or more information sources (e.g., web servers or external databases). Network 210 may include the Internet and / or other types of data networks, such as local area networks (LANs), wide area networks (WANs), cellular networks, satellite networks, or other types of data networks. Network 210 may include any number of computing devices (e.g., computers, servers, routers, network switches, etc.) configured to receive and / or transmit data within network 210. Network 210 may include any number of hardwired and / or wireless connections. Any or all computing devices described herein may wirelessly communicate (e.g., via Wi-Fi, cellular, radio, etc.) with transceivers of other computing devices in network 210 via hardwired connections (e.g., via fiber optic cables, CAT5 cables, etc.). Any or all computing devices described herein may communicate wirelessly with computing devices on network 210 via an agent device (e.g., a router, network switch, or gateway).

[0052] Station 215 may be a wireless communication device configured for wireless communication in a wireless communication network (e.g., LAN, WAN, or cellular network). Station 215 may be configured to wirelessly communicate with a network device (e.g., access point 205) using any of the IEEE standards (e.g., IEEE 802.11 standard). Station 215 may be combined with... Figure 1A To any of the user devices described in C. In some embodiments, station 215 may include one or more wireless communication devices 102 configured to receive services from a communication system, such as Figure 1A As described in the text.

[0053] In some embodiments, access point 205 may include network interface 220. Network interface 220 may be or include any script, file, program, application, instruction set, or computer-executable code configured to manage the transmission and reception of probe requests and responses over a wireless network. Network interface 220 may include a radio operating at a specific frequency (e.g., 2.4 GHz and 5 GHz) and supporting various Wi-Fi standards, which manages the transmission and reception of wireless signals. In some embodiments, network interface 220 may include an Ethernet port, which provides a primary wired connection point, allowing access point 205 to connect to a router or switch within a wired network. Network interface 220 may further include an antenna, which enhances wireless signal strength and coverage area. Network interface 220 may include an onboard processor and memory, which manages data flow between wired and wireless networks, facilitates encryption and decryption, and runs firmware that controls the access point's functionality. Network interface 220 may include firmware and software interfaces that provide operating system and configuration settings that allow administrators to manage access point 205, set security protocols, and improve performance.

[0054] In some embodiments, network interface 220 of access point 205 can receive probe requests. Network interface 220 can receive probe requests from station 215. The probe request can identify the scan dwell time of station 215 and its associated priority value. Scan dwell time refers to the duration spent by station 215 or access point 205 scanning a specific channel. The priority value can indicate the urgency of the request. In some embodiments, the priority value can include low priority values ​​(e.g., for initial unassociated scans or discoveries), normal priority values ​​(e.g., for normal roaming scans or background associated scans), or high priority values ​​(e.g., for final roaming scans where connections are more urgent). Network interface 220 can listen for incoming signals. Network interface 220 can continuously monitor the radio frequency (RF) spectrum of signals that match the characteristics of the probe request. When a signal is detected, network interface 220 can demodulate the signal to extract data. The received data can be parsed to verify whether it is a valid probe request by checking specific fields and values. If the probe request is valid, network interface 220 can extract information such as the MAC address, the desired SSID, the scan dwell time, and other relevant parameters. In some embodiments, network interface 220 of access point 205 can prioritize probe responses based on priority values.

[0055] In some embodiments, the network interface 220 of access point 205 may generate a probe response. The probe response may include information such as the access point's Basic Service Set Identifier (BSSID), SSID, channel number, supported data rates, security details, and other relevant network parameters. The network interface 220 may incorporate one or more metrics, such as the average response time to a probe request. In some embodiments, the metric may be determined at least based on channel congestion levels (e.g., multiple devices attempting to use the same channel simultaneously) or channel utilization data (e.g., how much of the capacity of a wireless communication channel is being used at any given time). The metric may refer to a specific measurement or indicator used to evaluate the performance or quality of the wireless connection during the probe process. The probe process in a wireless network may be used by station 215 to discover available access points 205 and networks, and may include both active and passive probes. In active probes, station 215 may transmit probe requests on different channels. Access points 205 receiving these requests may respond with probe responses, providing information about the network, such as the SSID, supported data rates, and security settings, thereby allowing station 215 to quickly discover nearby networks. In passive probe, station 215 can listen for beacon frames periodically broadcast by access point 205. After collecting and organizing the data, network interface 220 can generate a probe response as needed, which includes any custom or standard-defined fields. Network interface 220 can modulate the probe response data onto a carrier for transmission to the station.

[0056] In some embodiments, the network interface 220 of access point 205 may determine whether a probe response can be transmitted during the scan dwell time. Network interface 220 may determine whether a probe response can be transmitted during the scan dwell time by evaluating various factors. For example, network interface 220 may prioritize probe requests based on supported data rates, giving higher priority to stations with data rates compatible with the access point's capabilities. Network interface 220 may use a Received Signal Strength Indicator (RSSI) to assess signal strength, prioritizing requests with stronger signals that generally indicate closer proximity. If a probe request contains a specific SSID that matches the access point's network, then network interface 220 may prioritize that request over generic or wildcard requests. In some embodiments, network interface 220 may prioritize based on station capabilities (e.g., support for specific Wi-Fi standards or security protocols (e.g., WPA3)). In some embodiments, network interface 220 may assess the current network load, prioritizing requests from station 215 that is more likely to maintain a stable and efficient connection during heavy load periods. In some embodiments, network interface 220 may take into account any Quality of Service (QoS) requirements indicated in the probe request and prioritize requests that expect low latency or real-time performance.

[0057] In some embodiments, the network interface 220 of access point 205 may identify metrics to assess current network conditions and determine whether access point 205 can respond to probe requests within a specified time frame. Metrics may include factors such as channel congestion, interference, and overall network load, which can be used to assess network performance and availability. In some embodiments, network interface 220 may evaluate specific metrics, such as the average response time to probe requests, the level of channel utilization, and the severity of congestion, to identify its ability to process incoming requests and respond in a timely manner based on network conditions.

[0058] In some embodiments, the network interface 220 of access point 205 may transmit a probe response when it is determined that a probe response can be scheduled during the scan dwell time. The probe response or beacon frame may contain a field identifying a metric, such as the average response time of a probe request. In some embodiments, the metric may be included in the probe response or beacon frame. A field may refer to a specific data element within a communication frame used to communicate information or a metric between devices. This field may be a standard-defined field or a custom field. A standard-defined field may be a data element that follows a predetermined format or structure according to an industry standard or protocol. For example, a standard-defined field may be communicated using an existing beacon, Simplified Neighbor Report (RnR), or probe response. A custom field may be a data element within a communication frame configured for a specific application or use case and is not defined by any industry standard. A custom field may be a proprietary element. In some embodiments, the field may be a custom specification defined in a UHR (Ultra-High Rate) standard or similar protocol. Metrics provide data about the access point's response efficiency, allowing the station to more accurately assess network conditions. Proprietary elements may contain additional performance metrics, such as channel congestion or utilization, to provide a detailed view of the network environment. Proprietary elements may contain data fields that are not part of a standard protocol. Proprietary elements may be defined according to a proprietary protocol used by station 215 and access point 205. Unlike standard protocols (e.g., IEEE 802.11 for Wi-Fi), proprietary protocols may contain custom features not available in standard protocols. Proprietary elements may contain a Unique Identifier (OUI), a 24-digit number assigned by the Institute of Electrical and Electronics Engineers (IEEE) registry. The OUI can be used in various contexts, such as in the first 24 bits of a MAC address to identify the manufacturer of a network device, in a protocol identifier to determine the source or destination organization, and in vendor-specific information to globally distinguish the device.

[0059] In some embodiments, a metric may refer to a measurable data point or indicator used to evaluate the performance of access point 205. A time metric may specify the average time required for access point 205 to receive or respond to a probe request. In this regard, average time may refer to the duration between station 215 transmitting a probe request and access point 205 receiving and responding to the probe request. In some embodiments, the terms "metric" and "time metric" may be used interchangeably. In some embodiments, a metric may include the average response time of authentication requests (e.g., ART-AuthReq), association requests (ART-AssocReq), or reassoc requests (ART-ReassocReq) from station 215. For example, the response time of an authentication request may measure how quickly access point 205 can authenticate the identity of station 215, and the response time of an association request may measure how quickly access point 205 can establish a connection with station 215. The response time of a reassoc request may measure how quickly access point 205 can re-establish a connection with station 215. In some embodiments, these metrics may extend to action frames, such as Add Block Acknowledgment (ADDBA) - request / response and ART-ActionReq. In some embodiments, the access point may transmit simplified neighbor reports (RnRs) to co-located access points, which include channel congestion or channel utilization. These metrics can be used to provide information about network conditions to station 215 and other devices.

[0060] In some implementations, the network interface 220 of access point 205 may ignore duplicate probe requests when it is determined that a response cannot be scheduled within the scan dwell time. In some embodiments, network interface 220 may skip transmitting probe responses. In some embodiments, network interface 220 may detect and ignore duplicate probe requests from the same station. For example, network interface 220 may compare timestamps, match MAC addresses, or process the content of an incoming request to identify duplicates. In some embodiments, access point 205 may transmit probe responses to station 215 via an auxiliary (or second) access point 205 associated with station 215. The second access point 205 may be identified based on a Basic Service Set Identifier (BSSID) included in the probe request. In some embodiments, the second access point 205 and station 215 may be within each other's communication range such that the signal strength between them is sufficient for reliable data transmission. For example, when station 215 and second access point 205 are allegedly within communication range, the configuration indicates that the communication link can support effective data transmission.

[0061] In some embodiments, access point 205 may include a scan dwell time monitor 225. The scan dwell time monitor 225 may be or include any script, file, program, application, instruction set, or computer-executable code configured to measure the time spent by access point 205 on each channel during a scan. The scan dwell time monitor 225 may monitor channel scans and may include periodically scanning different channels to detect probe requests, interference, and unauthorized devices. The dwell time monitored by the scan dwell time monitor 225 may vary depending on the operating mode, including modes such as access point mode (short dwell time), airborne monitor mode (longer dwell time for security missions), and spectrum monitor mode (adaptive dwell time for analyzing the radio frequency environment).

[0062] In some embodiments, the scan dwell time monitor 225 of access point 205 can determine whether it is possible to schedule a probe response during the scan dwell time. The scan dwell time monitor 225 can assess resource availability, such as processing power and channel bandwidth, to determine whether access point 205 can manage the probe response. In some embodiments, the scan dwell time monitor 225 can assess current network conditions, such as channel congestion and network load, to determine whether the network can handle the response. In some embodiments, the scan dwell time monitor 225 can determine the time required to process and transmit the probe response by comparing the estimated response time with the remaining time in the scan dwell period.

[0063] In some embodiments, access point 205 may include a scan dwell time adjuster 230. The scan dwell time adjuster 230 may be or include any script, file, program, application, instruction set, or computer-executable code configured to dynamically adjust the amount of time spent by access point 205 scanning each channel. The scan dwell time adjuster 230 may modify the scan dwell time based on network conditions and specific requirements. For example, in an environment with high interference or many malicious devices, access point 205 may increase the dwell time on certain channels to collect detailed information. In some embodiments, the scan dwell time adjuster 230 may minimize the dwell time to reduce interruptions to client connections. In some embodiments, the scan dwell time adjuster 230 may increase the dwell time to facilitate comprehensive monitoring. In some embodiments, the scan dwell time adjuster 230 may dynamically adjust the scan dwell time based on specific scanning needs of the environment. The scan dwell time adjuster 230 may implement adaptive scanning to prioritize channels with higher activity, causing access point 205 to spend more time on channels more likely to cause problems.

[0064] In some embodiments, the scan dwell time adjuster 230 of access point 205 can dynamically adjust the scan dwell time of probe requests. The scan dwell time adjuster 230 can continuously monitor network conditions, such as channel congestion, channel utilization, and interference levels, to determine whether adjustment is needed. For example, the scan dwell time adjuster 230 can reduce the scan dwell time in high-traffic environments to minimize outages, or increase the scan dwell time in low-traffic environments for a more thorough scan. In some embodiments, access point 205 can evaluate its performance, including the average response time of probe requests, to determine via the scan dwell time adjuster 230 whether adjustment is needed. Based on the collected data, the scan dwell time adjuster 230 can determine an adjustment to the scan dwell time. Access point 205 can update its internal parameters to apply the adjusted scan dwell time.

[0065] In some embodiments, access point 205 may include queue manager 235. Queue manager 235 may be or include any script, file, program, application, instruction set, or computer-executable code configured to manage data packet streams via queues for transmission or reception. A queue may refer to a buffer used to manage data packets as they travel through the network. Queue manager 235 may include an input queue for temporarily storing incoming data packets before processing and an output queue for holding data packets ready for transmission. Queue manager 235 may determine the order of packet processing and transmission. Queue manager 235 may prioritize packet processing and transmission based on QoS requirements and network conditions. In some embodiments, queue manager 235 may regulate data flow, delaying or dropping packets to avoid network congestion. In some embodiments, queue manager 235 may examine incoming packets based on packet type, source, destination, or QoS requirements and assign them to one or more queues. In some embodiments, queue manager 235 may manage buffers and dynamically allocate buffer space to prevent overflow. Queue manager 235 may adjust transmission rate and buffer size based on network conditions. In some embodiments, queue manager 235 may implement strategies to maintain a consistent data flow.

[0066] In some embodiments, the queue manager 235 of access point 205 may queue or ignore duplicate probe requests. Access point 205 may detect and ignore duplicate probe requests from the same station 215. For example, access point 205 may compare timestamps, match MAC addresses, or process the content of incoming requests to identify duplicates. In some embodiments, if queue manager 235 has already queued responses to previous requests, access point 205 may avoid responding to new probe requests until a previously generated response has been processed.

[0067] Station 215 may include network interface 220, scan dwell time monitor 225, and scan dwell time adjuster 230. The network interface 220, scan dwell time monitor 225, and scan dwell time adjuster 230 of station 215 may be similar to and include any of the structures and functions of their corresponding parts, such as the interface 220, scan dwell time monitor 225, and scan dwell time adjuster 230 of access point 205.

[0068] Network interface 220 of station 215 manages the transmission and reception of probe requests and responses. Network interface 220 may include a wireless network adapter, which allows station 215 to connect to a wireless network by incorporating the physical layer (PHY) and media access control (MAC) layers. Network interface 220 may include an antenna for transmitting and receiving wireless signals. Network interface 220 may include driver software that interfaces with the operating system and the wireless network adapter. The driver software can be used to scan for available networks, connect to access points, and manage data transmission. Network interface 220 may support various network protocols, such as IEEE 802.11. Network interface 220 provides security features, including support for encryption protocols such as WPA2 or WPA3. Network interface 220 may include a graphical user interface (GUI) or command-line interface (CLI), which allows users to configure network settings, select networks, enter security keys, and manage network profiles.

[0069] In some embodiments, the network interface 220 of station 215 may generate a probe request. The network interface 220 may generate a probe request for access point discovery. The probe request may contain information such as the station's scanning dwell time or its corresponding priority level. Priority may indicate the urgency of the request, allowing access point 205 to prioritize its responses. For example, based on SDT or priority, access point 205 may determine whether it can respond within an allocated time or prioritize responses accordingly. In some embodiments, priorities may be categorized into different values, such as low priority for initial unassociated scans or discoveries, normal priority for regular roaming scans or background associated scans, and high priority for final roaming scans. The network interface 220 may determine the access points that are expected to be scanned, which may be triggered by user actions (e.g., connecting to a Wi-Fi network) or automatically based on predefined intervals or network conditions. The probe request may contain a MAC address, a random identifier (timestamp), a Service Set Identifier (SSID) (e.g., specific or wildcard), and capability information (e.g., supported data rates and security protocols), etc. In some embodiments, network interface 220 may include scan dwell time (e.g., the amount of time a station waits for a response) as a custom field or a standard-defined field in the probe request.

[0070] In some embodiments, the network interface 220 of station 215 may transmit probe requests to be received by access point 205. Network interface 220 may broadcast probe requests containing custom fields or standard-defined fields to all access points 205 within a certain range. Network interface 220 may modulate the probe request data onto a carrier and transmit the modulated signal. Network interface 220 may select a specific channel, such as 2.4 GHz or 5 GHz, based on configuration or available channels in the area.

[0071] In some embodiments, the network interface 220 of station 215 can listen for probe responses. Network interface 220 can activate a receiver to listen for incoming probe responses. The receiver can be tuned to the same channel used to transmit probe requests. Network interface 220 can continuously monitor the incoming radio frequency (RF) spectrum of a signal that matches the expected characteristics of a probe response, and if a signal is detected, network interface 220 can demodulate the signal. Network interface 220 can parse the received data to determine whether it is a valid probe response frame, for example, by checking specific fields and values. Network interface 220 can compare the received probe response with a previously sent probe request to verify whether it is a response to the station's own query.

[0072] In some embodiments, if no response timeout occurs, the network interface 220 of station 215 may receive a probe response. If a probe response is received before the timer expires, the network interface 220 may extract relevant metrics from the probe response. In some embodiments, the network interface 220 may receive a probe response containing custom fields or standard-defined fields. Custom fields (e.g., proprietary elements) or standard-defined fields may identify the metrics associated with the probe response.

[0073] In some embodiments, when access point 205 is a co-located access point, network interface 220 of station 215 may receive metrics from the co-located access point via Simplified Neighbor Report (RnR). For example, network interface 220 may extract metrics from the RnR, such as the average response time to probe requests (ART-PReq), channel congestion, or channel utilization. Based on the reported metrics, such as if the co-located access point's ART-PReq, channel congestion, or channel utilization is unfavorable, network interface 220 may initiate multi-link (ML) probes. For example, network interface 220 may transmit probe request frames across multiple channels (e.g., 2.4 GHz, 5 GHz, 6 GHz) to discover available access points 205. The co-located access point may respond with probe response frames containing information about the co-located access point's capabilities, such as supported channels, SSID, and security parameters. Network interface 220 may evaluate the signal strength, signal-to-noise ratio (SNR), and other metrics from the received responses to determine optimal connection quality.

[0074] The scan dwell time monitor 225 of station 215 can actively monitor the behavior of station 215 when it switches between different channels. The scan dwell time monitor 225 can monitor the timing of probe requests. The scan dwell time monitor 225 can be used to record the time spent on each channel. The scan dwell time monitor 225 can monitor incoming responses from access point 205. The scan dwell time monitor 225 can collect data on the timing and frequency of responses received during the scan dwell period.

[0075] In some embodiments, the scan dwell time monitor 225 of station 215 may be initialized to track the time elapsed since a probe request was transmitted. In some embodiments, the scan dwell time monitor 225 may be set to count from zero, where the maximum value corresponds to a specified scan dwell time. The scan dwell time monitor 225 may measure the amount of time elapsed since station 215 transmitted a probe request. The scan dwell time monitor 225 may be used to determine whether a response has been received from access point 205 within a specified time limit. In some embodiments, the scan dwell time monitor 225 of station 215 may determine whether a response timeout has been reached. In some embodiments, when station 215 transmits a probe request, the scan dwell time monitor 225 may start a timer. If the timer reaches a specified time limit before any probe response is received, then the scan dwell time monitor 225 may determine that a response timeout has been reached. In some embodiments, the scan dwell time monitor 225 may implement an event listener for probe responses and may be configured to trigger a timeout event after a predefined time period. If a probe response is received before the timeout event is triggered, then the scan dwell time monitor 225 may process the response and cancel the timeout event. If a timeout event is triggered first, the scan dwell time monitor 225 can determine that a response timeout has been reached. In some implementations, the scan dwell time monitor 225 may implement a hybrid approach, where the timer is set together with an interrupt for receiving a probe response. If a probe response is received, an interrupt can be triggered, and station 215 can process the response while resetting the timer. If the timer reaches a specified time limit without any interrupt, the scan dwell time monitor 225 can determine that a response timeout has been reached.

[0076] The scan dwell time adjuster 230 of station 215 can dynamically modify the dwell time based on network conditions. The scan dwell time adjuster 230 can adjust the time spent on each channel based on scan results and network feedback. The scan dwell time adjuster 230 can evaluate signal strength and the quality of the response from access point 205 to determine whether the scan dwell time should be extended or reduced. In some embodiments, the scan dwell time adjuster 230 can store information about the detected access point 205 and its corresponding signal strength.

[0077] In some embodiments, if a response timeout occurs, the scan dwell time adjuster 230 of station 215 may dynamically increase the scan dwell time. The scan dwell time adjuster 230 may adjust the scan dwell time based on local interference. For example, if station 215 does not receive a response from access point 205 after a portion (e.g., half) of the scan dwell time has elapsed, or if station 215 determines that surrounding channel conditions indicate high congestion (e.g., due to Energy Detection (ED) or Overlapping Basic Service Set (OBSS) frames), the scan dwell time adjuster 230 may dynamically increase the scan dwell time to account for any delay in probe response delivery caused by congestion. ED frames can be used to determine whether a particular frequency band is signal-occupied or idle (i.e., contains only noise). OBSS frames may refer to data frames transmitted by access point 205 and station 215 within overlapping coverage areas of different Basic Service Sets (BSS). In a wireless network, a BSS may be a set of devices communicating with each other through a common access point 205.

[0078] In some embodiments, the scan dwell time adjuster 230 of station 215 can dynamically adjust the scan dwell time in response to subsequent probe requests. For example, the scan dwell time adjuster 230 can adjust the scan dwell time based on metrics such as channel congestion, channel utilization, or the average response time of probe requests. Station 215 can continuously monitor network conditions and collect data on various factors. Based on the collected data, station 215 can assess the need to adjust the scan dwell time. If adjustment is required, the scan dwell time adjuster 230 can determine appropriate changes, for example, based on the severity of congestion, the average response time, and the desired response level. In some embodiments, station 215 can update its internal parameters to implement updated scan dwell times. For example, if station 215 detects high channel congestion or utilization, station 215 can increase the scan dwell time via the scan dwell time adjuster 230 to allow more time for responses from access point 205. In some embodiments, if station 215 detects slow response times, the scan dwell time adjuster 230 can extend the dwell time to give access point 205 more time to respond. In some embodiments, if the network operates efficiently with low congestion and fast response time, the scan dwell time adjuster 230 can reduce the scan dwell time to minimize overhead.

[0079] In some embodiments, when access point 205 is a co-located access point, station 215 may use the average response time (ART-PReq) of probe requests provided in the RnR or beacon, channel congestion, or channel utilization to adjust scanning behavior via scan dwell time adjuster 230. Scan dwell time adjuster 230 may dynamically adjust the scan dwell time when scanning co-located access points on its channel based on reported metrics. For example, if the ART-PReq, channel congestion, or channel utilization of the co-located access point is unfavorable, then scan dwell time adjuster 230 may dynamically adjust the scan dwell time.

[0080] In some embodiments, while station 215 is awaiting a response to an authentication request, association request, reassociation request, or Add Block Acknowledgment (ADDBA) request, the scan dwell time adjuster 230 of station 215 may dynamically adjust the dwell time. For example, the scan dwell time adjuster 230 may adjust the dwell time based on the average response time for the corresponding request provided by access point 205. In some embodiments, station 215 may update its internal parameters to implement the updated dwell time. For example, if station 215 detects a slow response time for authentication, association, reassociation, or ADDBA requests, the scan dwell time adjuster 230 may extend or adjust the dwell time.

[0081] Figure 3 This describes an example method 300 for improving access point discovery using dynamic dwell time. Method 300 can be implemented using systems 100, 200, or any other features discussed in Figures 1 and 2. Method 300 may include actions 302 through 318. At 302, a station may be initialized. At 304, the station may generate a probe request. At 306, the station may transmit a probe request. At 308, the station may activate a scan dwell time monitor. At 310, the station may listen for probe responses. At 312, the station may check if a response timeout has occurred. At 314, if a response timeout occurs, the station may dynamically increase the scan dwell time. At 316, if no response timeout occurs, the station may receive a probe response. At 318, the station may dynamically adjust the scan dwell time for subsequent probe requests.

[0082] At point 302, the station can be initialized by powering on and activating its wireless network interface. The station can scan for available networks by switching channels and listening for beacon frames from the access point. The station can select a network based on factors such as signal strength and security settings. After selecting a network, the station can initiate the authentication process and send an association request. Once authenticated and associated, the station obtains an IP address and configures its network settings.

[0083] At position 304, a station can generate a probe request. The station can generate a probe request for access point discovery. The probe request may contain information such as the station's scan dwell time or corresponding priority level. Priority indicates the urgency of the request, allowing the access point to prioritize its responses. For example, based on SDT or priority levels, the access point can determine whether it can respond within the allocated time or prioritize responses accordingly. In some embodiments, priorities can be categorized into different values, such as low priority for initial unassociated scans or discovery, normal priority for regular roaming scans or background associated scans, and high priority for final roaming scans.

[0084] A station can determine which access points it wishes to scan, which may be triggered by user actions (such as connecting to a Wi-Fi network) or automatically based on predefined intervals or network conditions. The probe request may include a MAC address, a random identifier (timestamp), a Service Set Identifier (SSID) (e.g., specific or wildcard), and capability information (e.g., supported data rates and security protocols). In some embodiments, the station may include the scan dwell time (e.g., the amount of time the station waits for a response) as a custom field or a standard-defined field in the probe request. Custom fields (e.g., proprietary elements) may contain data fields that are not part of a standard protocol. For example, proprietary elements may be defined according to a proprietary protocol used by the station and the access points. Unlike standard protocols (e.g., IEEE 802.11 for Wi-Fi), proprietary protocols may contain custom features not available in standard protocols.

[0085] At point 306, the station can transmit a probe request. The station can transmit a probe request that will be received by access points. The station can broadcast a probe request containing custom fields or standard-defined fields to all access points within range. The station can modulate the probe request data onto a carrier and transmit the modulated signal. The station can select a specific channel based on configuration or available channels in the area, such as 2.4 GHz or 5 GHz.

[0086] At 308, the station can activate a scan dwell time monitor. The station can track the time elapsed since transmitting a probe request via the scan dwell time monitor. In some embodiments, the station's scan dwell time monitor can be set to count from zero, where the maximum value corresponds to a specified scan dwell time. The scan dwell time monitor can measure the amount of time elapsed since the station transmitted a probe request. The scan dwell time monitor can be used to determine whether a response has been received from the access point within a specified time limit.

[0087] At 310, the station can listen for probe responses. The station can activate its receiver to listen for incoming probe responses. The receiver can be tuned to the same channel used to transmit probe requests. The station can continuously monitor the incoming radio frequency (RF) spectrum of signals that match the expected characteristics of probe responses, and if a signal is detected, the station can demodulate the signal. The station can parse the received data to determine if it is a valid probe response frame, for example, by checking specific fields and values. The station can compare the received probe response with previously sent probe requests to verify whether it is a response to the station's own query.

[0088] At 312, the station can check if a response timeout has been reached. In some embodiments, the station can start a timer when it transmits a probe request. If the timer reaches a specified time limit before any probe response is received, the station can determine that a response timeout has been reached. In some embodiments, the station can implement an event listener for probe responses and can be configured to trigger a timeout event after a predefined time period. If a probe response is received before the timeout event triggers, the station can process the response and cancel the timeout event. If the timeout event triggers first, the station can determine that a response timeout has been reached. In some embodiments, the station can implement a hybrid approach where the timer is set together with an interrupt for incoming probe responses. If a probe response is received, the interrupt can be triggered, and the station can process the response while resetting the timer. If the timer reaches a specified time limit without any interrupt, the station can determine that a response timeout has been reached.

[0089] At point 314, if a response timeout occurs, the station can dynamically increase the scan dwell time. The station can adjust the scan dwell time based on local interference. For example, if the station does not receive a response from the access point after a portion (e.g., half) of the scan dwell time has elapsed, or if the station determines that the surrounding channel conditions indicate high congestion (e.g., due to Energy Detection (ED) or Overlapping Basic Service Set (OBSS) frames), the station can dynamically increase the scan dwell time to account for any delay in probe response delivery caused by congestion.

[0090] At point 316, if no response timeout occurs, the station may receive a probe response. If a probe response is received before the timer expires, the station may extract relevant metrics from the probe response. In some embodiments, the station may receive a probe response containing custom fields or standard-defined fields. Custom fields (e.g., proprietary elements) or standard-defined fields may identify the metrics associated with the probe response. The metrics may specify the average time required for the access point to receive or respond to a probe request.

[0091] At point 318, the station can dynamically adjust the scan dwell time in response to subsequent probe requests. For example, the station can adjust the scan dwell time based on metrics such as channel congestion, channel utilization, or the average response time of probe requests. The station can continuously monitor network conditions and collect data on various factors. Based on the collected data, the station can assess the need to adjust the scan dwell time. If adjustment is required, the station can determine appropriate changes, for example, based on the severity of congestion, the average response time, and the desired response level. The station can update its internal parameters to implement the updated scan dwell time. For example, if the station detects high channel congestion or utilization, it can increase the scan dwell time to allow more time for responses from access points. In some embodiments, if the station detects slow response times, it can extend the dwell time to give access points more time to respond. In some embodiments, if the network operates efficiently with low congestion and fast response times, the station can reduce the scan dwell time to minimize overhead.

[0092] In some embodiments, a station may dynamically adjust its dwell time while awaiting a response to an authentication request, association request, reassociation request, or Add Block Acknowledgment (ADDBA) request. For example, the station may adjust the dwell time based on the average response time provided by the access point for the corresponding request. In some embodiments, the station may update its internal parameters to implement the updated dwell time. For example, if the station detects a slow response time for authentication, association, reassociation, or ADDBA requests, it may extend or adjust the dwell time.

[0093] In some embodiments, when the access point is a co-located access point, the station can receive metrics from the co-located access point via Simplified Neighbor Report (RnR). The station can use the average response time (ART-PReq), channel congestion, or channel utilization provided in the RnR or beacon to adjust its scanning behavior. The station can dynamically adjust its dwell time when scanning for co-located access points on its channels based on the reported metrics. For example, if the ART-PReq, channel congestion, or channel utilization of the co-located access point is unfavorable, the station can initiate multi-link (ML) probing. For example, during ML probing, the station can transmit probe request frames across multiple channels (e.g., 2.4 GHz, 5 GHz, 6 GHz) to discover available access points. The co-located access point can respond with probe response frames containing information about the access point's capabilities, such as supported channels, SSID, and security parameters. The station can evaluate the signal strength, signal-to-noise ratio (SNR), and other metrics from the received responses to determine optimal connection quality. In some embodiments, a station may use the ART-PReq value reported by the colocation access point to fine-tune the scan dwell time during ML probing.

[0094] Now for reference Figure 4This describes an example implementation of successful access point discovery achieved by increasing scanning dwell time based on local interference assessment of the site, such as combining... Figure 3 As described. A station can send a probe request to an access point. The probe request identifies the station's scan dwell time. The station can initiate a scan dwell time monitor. The scan dwell time monitor can monitor probe responses for a specified dwell time. If no response is received within this time, for example due to local interference, the station can determine that a response timeout has occurred. In response, the station can dynamically increase the scan dwell time to allow additional time to receive a response. The station can continue listening for responses during the newly extended scan dwell time.

[0095] Now for reference Figure 5 The description describes an instance implementation where a station uses the average response time or channel utilization (CU) of probe requests (ART-PReq) from simplified neighbor reports (RnR) to discover co-located access points on its channel, such as combining... Figure 3 As described, a station can transmit a probe request on its channel, and multiple access points (e.g., AP1 and AP2) can respond with their probe responses. The station can receive a probe request (RnR) from AP1, which contains information about AP2, such as the corresponding ART-PReq and CU. Based on the data in the RnR, the station can dynamically adjust its scan dwell time on AP2's channel, for example, based on the ART-PReq and CU values ​​reported by AP1. In this configuration, the station successfully discovers AP2 by adjusting its scan dwell time.

[0096] Now for reference Figure 6 The description describes an implementation scheme where a station uses multi-link (ML) probing to discover co-located access points, such as combining... Figure 3 As described. A station can transmit probe requests on its channel, and access points (e.g., AP1 and AP2) can respond with their respective beacons or probe responses. The station can receive a Simplified Neighbor Report (RnR) from AP1, which contains information about AP2, such as the average response time (ART-PReq) or channel utilization (CU) of the probe request. If AP2's ART-PReq or CU is unfavorable, the station can initiate ML probes by transmitting an ML probe request to AP1. The ML probe request has a specific link identifier (e.g., link ID = AP2) instructing the station to establish a connection targeting AP2. AP1 can respond with an ML probe response containing additional information related to the ML probe request for AP2. The station can use the ART-PReq value from the RnR and the additional information from the ML probe response to dynamically adjust its scan dwell time on AP2's channel to improve the discovery process.

[0097] Figure 7This describes another example method 700 for improving access point discovery using dynamic dwell time. Method 700 can be implemented using systems 100, 200, or any other features discussed in Figures 1-2. Method 700 may include actions 702 to 720. At 702, the access point can be initialized. At 704, the access point can receive probe requests. At 706, the access point can determine whether a probe response can be emitted during the scan dwell time. At 708, the access point can identify a metric. At 710, the access point can generate a probe response. At 712, the access point can check whether it is possible to schedule a probe response during the scan dwell time. At 714, the access point can emit a probe response if it is determined that a response can be scheduled during the scan dwell time. At 716, the access point can update the average response time metric.

[0098] At point 702, the access point can be initialized by powering it on, thus initiating its startup sequence. The access point's hardware components, such as the processor, memory, network interface, and radio module, can be initialized and configured. The access point can load its operating system and software components into memory. The access point can load its configuration settings, such as network parameters, security settings, and operating modes. The access point can perform self-tests to verify the functionality of its hardware and software. The access point can initiate a network discovery process to identify other devices on the network. The radio can be configured by selecting a channel and setting the transmit power. The access point can begin broadcasting beacon frames to signal its presence and provide network information, including the SSID, channel, and security. Once the initialization process is complete, the access point is ready to receive and process connections.

[0099] At position 704, the access point can receive probe requests. The access point can receive probe requests from stations. Probe requests can identify the station's scan dwell time and associated priority. Priority refers to the relative importance or urgency assigned to the probe request by the station. The access point can listen for incoming signals via the network interface. The access point can continuously monitor the radio frequency (RF) spectrum of signals matching the characteristics of probe requests. When a signal is detected, the access point can demodulate the signal to extract data. The received data can be parsed to verify whether it is a valid probe request by checking specific fields and values. If the probe request is valid, the access point can extract information such as the MAC address, the desired SSID, the scan dwell time, and other relevant parameters.

[0100] At 706, the access point can determine whether a probe response can be transmitted during the scan dwell time by evaluating various factors. For example, the access point can prioritize probe requests based on supported data rates, giving higher priority to stations with data rates compatible with the access point's capabilities. The access point can use Received Signal Strength Indicator (RSSI) to evaluate signal strength, prioritizing stronger signals that generally indicate closer proximity. If the probe request contains a specific SSID that matches the access point's network, the access point can prioritize that request over generic or wildcard requests. In some embodiments, the access point can prioritize based on station capabilities, such as support for specific Wi-Fi standards or security protocols (e.g., WPA3). In some embodiments, the access point can assess the current network load, prioritizing requests from stations more likely to maintain stable and efficient connections during periods of heavy load. In some embodiments, the access point can consider any Quality of Service (QoS) requirements indicated in the probe request, prioritizing requests that expect low latency or real-time performance. In some embodiments, the access point can use Voice Access Class (AC-VO) to prioritize probe responses, beacon frames, or other high-priority traffic, such as voice or video communications.

[0101] At 708, the access point can identify metrics. These metrics assess the current network condition and determine whether the access point can respond to probe requests within a specified time frame. Metrics may include several factors, such as channel congestion, interference, and overall network load, which can be used to evaluate network performance and availability. In some embodiments, the access point can assess specific metrics, such as the average response time to probe requests, channel utilization level, and congestion severity, to identify its ability to process incoming requests and respond in a timely manner based on network conditions.

[0102] At point 710, the access point can generate a probe response. The probe response may include information such as the access point's BSSID, SSID, channel number, supported data rates, security details, and other relevant network parameters. The access point may incorporate one or more metrics, such as the average response time to probe requests, channel congestion level, and channel utilization data. After collecting and organizing the data, the access point can generate a probe response as needed, containing any custom or standard-defined fields. The access point can then modulate the probe response data onto a carrier for transmission to the station.

[0103] In some embodiments, an access point may queue probe requests, which may mean temporarily saving probe requests for later processing and ignoring duplicate probe requests. The access point may detect and ignore duplicate probe requests from the same station. For example, the access point may compare timestamps, match MAC addresses, or process the content of incoming requests to identify duplicates. In some embodiments, if the access point has already queued responses to previous or earlier requests, the access point may avoid responding to new probe requests until a previously generated response has been processed or transmitted.

[0104] At point 712, the access point can check whether it is possible to schedule a probe response during the scan dwell time. The access point can assess resource availability, such as processing power and channel bandwidth, to determine whether the access point can manage the probe response. In some embodiments, the access point can assess current network conditions, such as channel congestion and network load, to determine whether the network can handle the response. In some embodiments, the access point can determine the time required to process and transmit the probe response by comparing the estimated response time with the remaining time in the scan dwell period.

[0105] At point 714, the access point may transmit a probe response when it determines that the probe response can be scheduled within the scan dwell time. The probe response may include a custom field or a standard-defined field that identifies a metric (e.g., the average response time from probe requests from a station). The metric provides data on the access point's response efficiency, allowing the station to more accurately assess network conditions. Custom fields (e.g., proprietary elements) or standard-defined fields may include additional performance metrics, such as channel congestion or utilization, to provide a detailed view of the network environment. In some embodiments, the access point may provide average response time metrics for additional frames, such as authentication (ART-AuthReq) and (re)association (ART-AssocReq) frames.

[0106] At point 716, the access point can update the Average Response Time (ART-PReq) metric. After the access point has transmitted a probe response to the station, it can update the ART-PReq, which specifies the average time spent responding to a probe request. In some embodiments, the access point can average the response times of all requests over a specific time period to update the ART-PReq metric. The ART-PReq can be updated in real time or at periodic intervals (e.g., every minute, hour, or day). The updated ART-PReq metric can be included in beacon frames, probe responses, or simplified neighbor reports (RNRs).

[0107] Now for reference Figure 8 This describes an example implementation of successful access point discovery, where the access point responds during the scan dwell time, such as combining... Figure 3 and 7As described. A station can transmit a probe request specifying a scan dwell time. An access point can receive the probe request and process it by determining whether the access point can respond within the specified scan dwell time. The access point can generate a probe response within the allocated time and transmit it to the station. In this configuration, the station receives the probe response before the scan dwell time expires.

[0108] Now for reference Figure 9 This describes an implementation plan for an instance of unsuccessful access point discovery, where the access point fails to respond within the scan dwell time, such as combining... Figure 3 and 7 As described. A station may transmit a probe request, specifying a scan dwell time. An access point may receive and process the request. After generating a probe response, the access point may transmit the response to the station. In some embodiments, if the station fails to transmit an acknowledgment (ACK) within a reasonable time frame, the access point may attempt to retransmit the probe response. If the station still does not respond, or if the access point fails to transmit a response within the scan dwell time, the discovery process may be considered unsuccessful.

[0109] Now for reference Figure 10 This describes an example implementation of successful access point discovery for high-priority probe requests, achieved by utilizing scan dwell time values ​​and prioritizing probe responses within a specified time, such as combining... Figure 3 and 7 As described. A station can transmit a probe request that specifies a scan dwell time value and a priority level (e.g., high priority) as part of a proprietary element or a standard-defined field in the probe request. An access point can receive probe requests containing scan dwell time values ​​and process the requests based on the priority level. The access point can prioritize probe responses and transmit probe responses within the station's specified scan dwell time. For example, in this configuration, the station receives a probe response before the scan dwell time expires.

[0110] Now for reference Figure 11 Describe an example implementation of unsuccessful access point discovery for low or normal priority probe requests, such as combining... Figure 3 and 7 As described, a station can transmit a probe request, which includes a scan dwell time value and a priority level (e.g., low, normal, or high priority) as proprietary elements within the probe request. An access point can receive and process the request. The access point can evaluate whether it can schedule a response based on the priority level within the specified scan dwell time. If the access point determines that it cannot schedule a response within the scan dwell time, then the access point can cancel the transmission. The station can continue to wait for a response until the scan dwell time expires. In this configuration, the discovery process is considered unsuccessful because no response was received within the scan dwell time.

[0111] It should be noted that, for the purpose of identifying or distinguishing one another or others, certain paragraphs of this disclosure may refer to terms such as “first” and “second” that are associated with apparatus, mode of operation, transmission chain, role, etc. These terms are not intended to relate entities (e.g., first apparatus and second apparatus) solely in time or according to sequence, although in some cases such a relationship may exist. These terms also do not limit the number of possible entities (e.g., apparatuses) that may operate in the system or environment. The term coupling or connection (which may refer to electronic or communication coupling or connection, e.g., for data transmission purposes) includes both indirect and direct coupling and connection.

[0112] While this disclosure has described specific embodiments, those skilled in the art will recognize that many modifications are possible. For example, although specific examples of rules (including triggering conditions and / or resulting actions) and processes for generating recommended rules are described, other rules and processes may be implemented. Embodiments of this disclosure may be implemented using various computer systems and communication technologies, including, but not limited to, the specific examples described herein.

[0113] Embodiments of this disclosure may be implemented using any combination of components and / or programmable processors and / or other programmable devices. The various processes described herein may be implemented on the same processor or different processors in any combination. Where a component is described as being configured to perform certain operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, by programming programmable electronic circuitry (e.g., a microprocessor) to perform the operations, or any combination thereof. Furthermore, while the embodiments described above may refer to specific hardware and software components, those skilled in the art will understand that different combinations of hardware and / or software components may also be used, and specific operations described as being implemented in hardware may also be implemented in software, or vice versa.

[0114] Computer programs incorporating the various features of this disclosure can be encoded and stored on a variety of computer-readable storage media; suitable media include magnetic disks or magnetic tapes, optical storage media such as optical discs (CDs) or DVDs (Digital Versatile Optical Discs), flash memory, and other non-transitory media. Computer-readable media encoding program code can be packaged together with a compatible electronic device, or the program code can be provided separately from the electronic device (e.g., via Internet download or as a separately packaged computer-readable storage media).

[0115] Therefore, although this disclosure has been described with respect to specific embodiments, it should be understood that this disclosure is intended to cover all modifications and equivalents within the scope of the appended claims.

[0116] It should be understood that the disclosed embodiments do not represent all claimed innovations. Therefore, certain aspects of this disclosure have not yet been discussed herein. Alternative embodiments may not have been proposed for specific parts of the innovation, or alternative embodiments not further described may be available for part of the claims that should not be considered a waiver of those alternative embodiments. Therefore, it should be understood that other embodiments may be utilized, and functional, logical, operational, organizational, structural, and / or topological modifications may be made without departing from the scope of this disclosure. Thus, throughout this disclosure, all instances and / or embodiments are considered non-limiting.

[0117] Some embodiments described herein relate to methods. It should be understood that such methods can be computer-implemented methods (e.g., instructions stored in memory and executed on a processor). The order of certain events can be modified when the methods described above instruct certain events to occur in a certain order. Furthermore, certain events can be performed repeatedly, concurrently in parallel processes where possible, and sequentially as described above. Additionally, some embodiments may omit one or more of the described events.

[0118] Some embodiments described herein relate to computer storage products having non-transitory computer-readable media (also referred to as non-transitory processor-readable media) having instructions or computer code thereon for performing various computer-implemented operations. Computer-readable media (or processor-readable media) are non-transitory and, in a sense, do not inherently contain transient propagation signals (e.g., propagating electromagnetic waves carrying information on a transmission medium (e.g., space or cable)). The media and computer code (also referred to as code) may be those designed and constructed for a particular purpose or several purposes. Examples of non-transitory computer-readable media include, but are not limited to, magnetic storage media such as hard disks, floppy disks, and magnetic tapes; optical storage media such as optical discs / digital video discs (CD / DVD), optical disc read-only memories (CD-ROMs), and holographic devices; magneto-optical storage media such as optical discs; carrier signal processing modules; and hardware devices specifically configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), read-only memories (ROMs), and random access memories (RAMs). Other embodiments described herein relate to computer program products that may include, for example, instructions and / or computer code discussed herein.

[0119] Some of the embodiments and / or methods described herein can be implemented by software (executing on hardware), hardware, or a combination thereof. Hardware modules may include, for example, general-purpose processors, field-programmable gate arrays (FPGAs), and / or application-specific integrated circuits (ASICs). Software modules (executing on hardware) can be expressed in various software languages ​​(e.g., computer code), including C, C++, Java, etc.TM Ruby, Visual Basic TM and / or other object-oriented, procedural, or other programming languages ​​and development tools. Examples of computer code include, but are not limited to, microcode or microinstructions, machine instructions (e.g., instructions generated by a compiler), code for generating web page services, and files containing higher-level instructions that a computer executes using an interpreter. For example, embodiments may be implemented using Python, Java, JavaScript, C++, and / or other programming languages ​​and software development tools. For example, embodiments may be implemented using imperative programming languages ​​(e.g., C, Fortran, etc.), functional programming languages ​​(Haskell, Erlang, etc.), logic programming languages ​​(e.g., Prolog), object-oriented programming languages ​​(e.g., Java, C++, etc.), or other suitable programming languages ​​and / or development tools. Additional examples of computer code include, but are not limited to, control signals, encryption code, and compression code.

[0120] The accompanying drawings are primarily for illustrative purposes and are not intended to limit the scope of the subject matter described herein. The drawings are not necessarily drawn to scale; in some instances, aspects of the subject matter disclosed herein may be exaggerated or enlarged in the drawings to facilitate understanding of different features. In the drawings, similar reference characters generally refer to similar features (e.g., functionally similar and / or structurally similar elements).

[0121] Actions performed as part of the disclosed method can be ordered in any suitable manner. Therefore, embodiments can be constructed in which processes or steps are performed in a different order than described, which may include performing some steps or processes simultaneously, even if shown as sequential actions in the illustrative embodiments. In other words, it should be understood that such features may not be limited to a particular order of execution, but can be performed serially, asynchronously, concurrently, in parallel, simultaneously, synchronously, and / or similarly in a manner consistent with this disclosure. Consequently, some of these features may contradict each other, as they cannot coexist in a single embodiment. Similarly, some features may be applicable to one aspect of the innovation but not to others.

[0122] Where value ranges are provided, it should be understood that, unless the context explicitly indicates otherwise, every intermediate value (to one-tenth of the lower limit unit) between the upper and lower limits of the range, and any other stated or intermediate value within the stated range, is included in this disclosure. The upper and lower limits of these smaller ranges may be independently included within the smaller ranges and also within this disclosure, subject to any expressly excluded limitations of the stated ranges. Where a stated range includes one or both of the limitations, the range excluding any or both of those included limitations is also included in this disclosure.

[0123] As used in this specification and embodiments, the phrase “and / or” should be understood as “any one or both” of the elements so combined, that is, elements that exist in combination in some cases and separately in others. Multiple elements listed with “and / or” should be interpreted in the same way, that is, “one or more” of the elements so combined. In addition to the elements explicitly identified in the “and / or” clause, other elements may optionally exist, whether related to or unrelated to the explicitly identified elements. Therefore, as a non-limiting example, when used in conjunction with open-ended language such as “including,” a reference to “A and / or B” may in one embodiment refer only to A (optionally including elements other than B); in another embodiment, only to B (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); and so on.

[0124] As used herein in the specification and embodiments, “or” should be understood to have the same meaning as “and / or” as defined above. For example, when items are listed separately, “or” or “and / or” should be interpreted as inclusive, that is, including multiple elements or at least one of the elements in the list, but also including more than one, and optionally including additional unlisted items. Terms that explicitly indicate the opposite uniqueness, such as “only one of” or “exact one of”, or, when used in embodiments, “consisting of”, will refer to including multiple elements or exactly one of the elements in the list. Generally, the term “or” as used herein should only be interpreted as indicating an exclusive alternative (i.e., “one or the other, but not both”) when preceded by an exclusive term (e.g., “either one or the other”, “only one of”, or “exact one of”). When used in embodiments, “consisting substantially of” should have its ordinary meaning as used in the field of patent law.

[0125] As used herein in the specification and embodiments, the phrase "at least one" referring to a list of one or more elements should be understood to mean at least one element selected from any one or more of the elements in the list, but not necessarily including at least one of every element expressly listed in the list, and does not exclude any combination of elements in the list. This definition also allows for the optional presence of elements other than those expressly identified in the list referred to by the phrase "at least one," whether or not these elements are related to those expressly identified elements. Therefore, as a non-limiting example, "at least one of A and B" (or equivalently, "at least one of A or B", or equivalently "at least one of A and / or B") may in one embodiment refer to at least one (optionally including more than one) A, without B (and optionally including elements other than B); in another embodiment, refer to at least one (optionally including more than one) B, without A (and optionally including elements other than A); in yet another embodiment, refer to at least one (optionally including more than one) A and refer to at least one (optionally including more than one) B (and optionally including other elements); etc.

[0126] In the embodiments and in the foregoing description, all transitional phrases (e.g., “including,” “comprising,” “carrying,” “having,” “containing,” “involving,” “holding,” “consisting of,” etc.) should be understood as open-ended, that is, meaning including but not limited to. As set forth in Section 2111.03 of the U.S. Patent Examination Process Manual, only the transitional phrases “consisting of” and “substantially consisting of” should be closed or semi-closed transitional phrases, respectively.

Claims

1. A station comprising: One or more processors coupled to memory, said one or more processors being configured to: Generate a probe request for access point discovery, the probe request identifying the scanning dwell time and priority of the station; The probe request will be transmitted and received by the access point; Receive a probe response from the access point, the probe response identification including a measure of the time it takes for the access point to respond to the probe request; and In response to the detection response, the scanning dwell time of the station is adjusted for subsequent detection requests.

2. The station of claim 1, wherein the access point is further configured to respond to the probe request at least based on the priority of the probe request during the identified scan dwell time.

3. The station according to claim 1, wherein the metric includes the average response time of the access point in response to the probe request.

4. The station according to claim 1, wherein the probe request includes a field for identifying the metric, the field including a custom field or a standard-defined field, wherein the metric includes at least the scan dwell time or a priority value, the priority value including at least one of a low priority value, a normal priority value, or a high priority value.

5. The station of claim 1, wherein the one or more processors are further configured to adjust the scan dwell time based at least on the metric, the metric including at least one of channel congestion, channel utilization, or the average response time of the probe request.

6. The station according to claim 5, wherein the access point is a co-located access point.

7. The station of claim 6, wherein the one or more processors are further configured to receive the metric via a simplified neighbor report from the co-located access point.

8. The station according to claim 7, wherein the one or more processors are further configured to: Scan the co-located access point at least based on the average response time of the probe request from the co-located access point or the congestion metric obtained from the simplified neighbor report, or The co-located access point is scanned using multi-link detection.

9. The station of claim 1, wherein the one or more processors are further configured to adjust the dwell time for at least one of an authentication request, an association request, a re-association request, or an add block acknowledgment (ADDBA) request based on the average response time provided by the access point for the corresponding request.

10. A station comprising: One or more processors coupled to memory, said one or more processors being configured to: The station transmits a probe request to be received by the access point, and the station has a scan dwell time to wait for a probe response; While waiting for the probe response during the scan dwell time, it is determined that at some point during the scan dwell time, the probe response has not yet been received from the access point; and In response to the determination, the scan dwell time is dynamically increased while waiting for the probe response from the access point.

11. The station of claim 10, wherein the one or more processors are further configured to dynamically increase the scan dwell time based at least on metrics received from the access point, the metrics including at least one of channel congestion, channel utilization, or average response time to probe requests.

12. The station of claim 10, wherein the one or more processors are further configured to dynamically increase the scan dwell time at least based on local interference, the local interference including at least one of energy detection frames or overlapping basic service set frames.

13. An access point comprising: One or more processors coupled to memory, said one or more processors being configured to: The slave station receives a detection request, which identifies the scanning dwell time and priority of the slave station; The response to the detection request shall be determined at least based on the priority during the scan dwell time; Identify one or more of the time metrics for the access point's response to the probe request, wherein the time metrics are determined based at least on channel congestion or channel utilization; Generate a probe response, which includes one or more of the time metrics of the access point's response to the probe request; and The detection response is emitted during the scan dwell time.

14. The access point of claim 13, wherein the one or more processors are further configured to suspend the transmission of the probe response when it is determined that the probe response cannot be scheduled during the scan dwell time.

15. The access point of claim 13, wherein the one or more processors are further configured to transmit the probe response to the station via a second access point associated with the station, wherein the second access point is identified based on a basic service set identifier included in the probe request.

16. The access point of claim 13, wherein the time metric further comprises the average response time of at least one of an authentication request, an association request, a reassociation request, or an add block acknowledgment (ADDBA) request from the station.

17. The access point of claim 13, wherein the one or more processors are further configured to transmit simplified neighbor reports to the co-located access point, the simplified neighbor reports including at least one of channel congestion or channel utilization.

18. An access point comprising: One or more processors coupled to memory, said one or more processors being configured to: The slave station receives a detection request, the detection request identifying the scanning dwell time of the slave station; It was determined that the access point was unable to transmit a probe response during the scanning dwell time at the station; Skip the launch of the probe response; The probe requests are queued until they are parsed. and While queuing the probe requests, duplicate probe requests from the station are ignored.

19. The access point of claim 18, wherein the one or more processors are further configured to detect repeated probe requests from the station.

20. The access point of claim 18, wherein the one or more processors are further configured to prioritize the probe responses based on a priority value associated with the probe request, wherein the priority value includes at least one of a low priority value, a normal priority value, or a high priority value.

Images