System and method for improving access point detection using dynamic dwell time

Abstract

To provide a system and a method for improving access point detection using a dynamic dwell time.SOLUTION: In a method for improving access point detection, a station generates a probe request identifying a scan dwell time and priority of the station for access point detection, transmits a probe request to be received by an access point, receives a probe response from the access point identifying an indicator including an amount of time until the access point responds to the probe request, and adjusts the station's scan dwell time for subsequent probe requests in response to the probe response.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Provisional Application No. 63 / 682,247, filed August 12, 2024, and also claims the benefit of priority to U.S. Provisional Application No. 63 / 651,275, filed May 23, 2024, the entireties of which are incorporated herein by reference.

[0002] Field of Disclosure The present disclosure relates generally to systems and methods for wireless communication between access points and wireless communication devices, including, but not limited to, improved access point detection using dynamic dwell times. [Background technology]

[0003] background The market for wireless communication devices continues to grow due to the increasing use of mobile devices, improved connectivity, and data transfer between all types of devices. Digital switching technologies have 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). These technologies enable wireless communication devices to connect to local area networks and the Internet without physical cables and to communicate over radio frequencies across various spaces and ranges.

[0004] overview The technical solution of the present disclosure is directed to improving access point detection using a dynamic dwell time. In a wireless local area network (WLAN), access points and client devices can communicate wirelessly within a local area, such as a home, office, or campus. WLANs can support a variety 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 data packet delivery to ensure a seamless user experience. In dense WLAN environments, non-AP stations (STAs) often have difficulty discovering available access points (APs) within the limited scan dwell time, resulting in reduced network connection efficiency. This problem is primarily caused by factors such as basic service set (BSS) overlap, which can cause interference and congestion when multiple WLAN networks operate on a shared channel. High channel congestion can make it difficult for STAs to receive beacons or probe responses within the allotted time. Furthermore, in some cases, access points may prioritize other tasks over responding to probe requests, leading to delayed response times. As a result, even in lightly congested environments, STAs may experience delays in receiving responses. Furthermore, the limited scan dwell time may limit the amount of time STAs spend scanning for APs. As a result, STAs may experience connection delays, especially in areas with high AP density. Roaming issues and frequent switching between APs may occur, leading to connection loss and service interruptions. Similarly, interference and congestion may degrade network performance and reduce data throughput.

[0005] The technical solution disclosed herein overcomes challenges such as inefficient access point detection, scan dwell time limitations, channel congestion, BSS overlap, and degraded network performance in dense WLAN environments. This technical solution includes modifications on both the STA side and the AP side. For example, the STA side can add special proprietary elements, including fields such as the scan dwell time (SDT) for a designated channel and the priority of a probe request. Priority can be categorized into different values. For example, priority may be categorized as low priority for initial unconnected scans or discovery, normal priority for regular roaming scans or background connected scans, and high priority for final roaming scans. On the AP side, the access point can use the STA's SDT and priority information 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. Additionally, if probe responses cannot be scheduled in a timely manner due to network congestion, the AP can postpone the response indefinitely to avoid wasting airtime. In some cases, an AP can use the Access Category for Voice (AC-VO) to prioritize probe responses, beacon frames, or certain types of traffic.

[0006] Technical solutions may include additional enhancements to AP probe request management. For example, an AP can include the average response time to STA probe requests as part of a unique element in its beacon and probe-response frames. This average response time is called the average response time to probe requests (ART-PReq). The AP can also include the ART-PReq value in the Reduced Neighbor Report (RnR) element of all co-located APs. The AP can also provide information about the channel congestion (CC) or channel utilization (CU) of all co-located APs in the RnR element. Non-AP STAs can use the CC, CU, or ART-PReq values ​​obtained from the AP via RnR or beacons to make informed decisions. For example, they can adjust the dwell time when scanning for co-located APs on their own channel or, if the AP supports multi-link operation (MLO), discover co-located APs through multi-link probing. This setting is useful when the response time or CU of the co-located AP is not good, and the STA can improve network performance by changing the dwell time during ML probing using the ART-PReq of the AP that provides the report.The technical solution described in this specification can also be extended to future standards such as the 802.11bn (UHR / Wi-Fi8) specification.

[0007] Similarly, technical solutions may include APs providing an average response time metric for additional frames, such as authentication request (ART-AuthReq) and (re)association request (ART-AssocReq) frames. STAs can use this metric to fine-tune their channel dwell time during authentication and association. Furthermore, this setting can be extended to action frames, such as additional block ACK (ADDBA) requests / responses and ART-ActionReq, allowing STAs to further extend their dwell time during these interactions and improve overall network performance.

[0008] Furthermore, according to the present technical solution, a STA can dynamically increase its scan dwell time based on local interference. For example, if a STA does not receive a response from an AP after half of the scan dwell time has elapsed and determines that channel congestion is high (e.g., due to energy detection (ED) or overlapping basic service set (OBSS) frames), the STA can dynamically increase the scan dwell time, taking into account the probe response delivery delay. Furthermore, an AP can reduce the delivery of unnecessary probe responses by detecting and ignoring duplicate probe requests. If an AP has already queued a response to a previous request, the AP can avoid responding to a new probe request until it has completed processing the previously generated response. The technical solution disclosed in this specification can improve access point detection and the overall network efficiency.

[0009] At least one aspect of the technical solution is directed to a system for improving access point detection using a 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 a probe request for access point detection. The probe request may identify a scan dwell time and a priority of the station. The one or more processors may transmit the probe request to an access point for reception. The one or more processors may receive a probe response from the access point. The probe response may identify an indicator including an amount of time until the access point responds to the probe request. In response to the probe response, the one or more processors may adjust the scan dwell time of the station for subsequent probe requests.

[0010] In some embodiments, the access point may respond to the probe request within the identified scan dwell time based on at least the priority of the probe request. In some embodiments, the indicator may include an average response time for the access point to respond to the probe request. In some embodiments, the probe request may include a field identifying the indicator. In some embodiments, the field may include a custom field or a standard-defined field. The indicator may include 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. In some embodiments, the one or more processors may adjust the scan dwell time based at least on the indicator. The indicator may include at least one of a channel congestion level, a channel utilization rate, or an average response time to 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 indicator via a simplified neighbor report of the co-located access point.

[0011] In some embodiments, the one or more processors may scan the co-located access point based on the average response time to a probe request of the co-located access point or the congestion metric obtained from the simplified neighbor report, or may scan the co-located access point using multi-link probing. In some embodiments, the one or more processors may adjust a dwell time for at least one of an authentication request, an association request, a reassociation request, or an add block ACK (ADDBA) request based on an average response time to a corresponding request provided by the access point.

[0012] Another aspect of the technical solution is directed to a system for improving access point detection using a 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 transmit a probe request to be received by an access point. The station may have 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, at a point during the scan dwell time, that the probe response has not yet been received from the access point. In response to the determination, the one or more processors may dynamically increase the scan dwell time while waiting for the probe response from the access point.

[0013] In some embodiments, the one or more processors can dynamically increase the scan dwell time based on at least an indicator received from the access point. The indicator may include at least one of channel congestion, channel utilization, or average response time to a probe request. In some embodiments, the one or more processors can 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.

[0014] Another aspect of the technical solution is directed to a system for improving access point detection using a 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 a probe request from a station. The probe request may identify a scan dwell time and a priority of the station. The one or more processors may determine to respond to the probe request within the scan dwell time based at least on the priority. The one or more processors may identify one or more of the time indicators until the access point responds to the probe request, and the time indicators may be determined based at least on channel congestion or channel utilization. The one or more processors may generate a probe response including one or more of the time indicators until the access point responds to the probe request. The one or more processors may transmit the probe response within the scan dwell time.

[0015] In some embodiments, the one or more processors may pause transmission of the probe response if they determine that the probe response cannot be scheduled within 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. The second access point may be identified based on a basic service set identifier included in the probe request. In some embodiments, the time indicator may further include an average response time to at least one of an authentication request, an association request, a reassociation request, or an add block ACK (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 may include at least one of a channel congestion degree or a channel utilization rate.

[0016] Yet another aspect of the technical solution is directed to a system for improving access point detection using a 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 a probe request from a station. The probe request may identify a scan dwell time of the station. The one or more processors may determine that the access point cannot transmit a probe response within the scan dwell time of the station. The one or more processors may skip transmitting the probe response. The one or more processors may queue the probe request until the probe response is resolved. While the probe request is queued, the one or more processors may ignore duplicate probe requests from the station. In some embodiments, the one or more processors may detect the 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 a low priority value, a normal priority value, or a high priority value. [Brief explanation of the drawings]

[0017] Various objects, aspects, features, and advantages of the present disclosure will become more apparent and will be better understood by reference to the detailed description in conjunction with the accompanying drawings, in which like reference numerals designate corresponding elements throughout and generally indicate identical, functionally similar, and / or structurally similar elements.

[0018] [Figure 1A]1 is a block diagram illustrating a network environment including one or more access points that communicate with one or more devices or stations, according to one or more embodiments.

[0019] [Figure 1B] FIG. 1 is a block diagram illustrating a computing device useful in connection with the methods and systems described herein, in accordance with one or more embodiments. [Figure 1C] FIG. 1 is a block diagram illustrating a computing device useful in connection with the methods and systems described herein, in accordance with one or more embodiments.

[0020] [Figure 2] FIG. 1 is a block diagram of an example system for improving access point detection using dynamic dwell times, according to one or more embodiments.

[0021] [Figure 3] FIG. 1 is an exemplary flow diagram illustrating a method for improving access point detection through dynamic dwell times, according to one or more embodiments.

[0022] [Figure 4] FIG. 1 illustrates an exemplary embodiment of access point detection, according to one or more embodiments. [Figure 5] FIG. 1 illustrates an exemplary embodiment of access point detection, according to one or more embodiments. [Figure 6] FIG. 1 illustrates an exemplary embodiment of access point detection, according to one or more embodiments.

[0023] [Figure 7] FIG. 10 is another example flow diagram of a method for improving access point detection using dynamic dwell times, according to one or more embodiments.

[0024] [Figure 8]FIG. 1 illustrates another exemplary embodiment of access point detection, according to one or more embodiments. [Figure 9] FIG. 1 illustrates another exemplary embodiment of access point detection, according to one or more embodiments. [Figure 10] FIG. 1 illustrates another exemplary embodiment of access point detection, according to one or more embodiments. [Figure 11] FIG. 1 illustrates another exemplary embodiment of access point detection, according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0025] Detailed Description The following IEEE standards (including draft versions of such standards) are incorporated herein by reference in their entirety and made a part of this disclosure for all purposes: WiFi Appliance Standards and IEEE 802.11 Standards (including but not limited to IEEE 802.11a™, IEEE 802.11b™, IEEE 802.11g™, IEEE P802.11n™; IEEE P802.11ac™; and IEEE P802.11be™ through IEEE P802.11bn™ standards). While this disclosure may reference aspects of these standards, this disclosure is in no way limited by these standards.

[0026] In reading the following description of the various embodiments, the following explanations of each section of this specification and its respective content may be helpful. Section A describes network and computing environments useful for practicing the embodiments described herein. Section B describes a system and method for improving access point detection using dynamic dwell times.

[0027] A. Computing and Network Environment Before describing specific embodiments of the present solution, it may be helpful to describe aspects of an operating environment relevant to the methods and systems described herein, as well as associated system components (e.g., hardware elements, etc.). Referring to FIG. 1A, one embodiment of a network environment is illustrated. Briefly, the network environment includes a wireless communication system including 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. The wireless communication devices 102 may include, for example, laptop computers, tablets, personal computers, and / or mobile phone devices. Details of embodiments of each station or wireless communication device 102 and AP or network device 106 are described in further detail with reference to FIGS. 1B and 1C. In one embodiment, the network environment may be an ad-hoc network environment, an infrastructure wireless network environment, a subnet environment, etc. The network device 106 or AP may be operably coupled to the network hardware 192 via a local area network connection. In some embodiments, the network device 106 may be a 5G base station. The network hardware 192 may include a router, a gateway, a switch, a bridge, a modem, a system controller, an appliance, etc. The network hardware 192 may provide a local area network connection to the communication system. Each of the network devices 106 or APs may have an associated antenna or antenna array for communicating with wireless communication devices within its area. The wireless communication device 102 may register with a particular network device 106 or AP to receive service from the communication system (e.g., via a SU-MIMO or MU-MIMO configuration). In the case of a direct connection (e.g., point-to-point communication), some wireless communication devices may communicate directly via an assigned channel and communication protocol.Some of the wireless communication devices 102 may be mobile or relatively static relative to the network devices 106 or APs.

[0028] In some embodiments, the network device 106 or AP may include a device or module (including a combination of hardware and software) that enables the wireless communication device 102 to connect to a wired network using Wi-Fi or other standards. The network device 106 or AP may also be referred to as a wireless access point (WAP). The network device 106 or AP may be implemented (e.g., configured, designed, and / or built) to operate in a wireless local area network (WLAN). In some embodiments, the network device 106 or AP may be connected to a router (e.g., via a wired network) as a standalone device. In other embodiments, the network device 106 or AP may be a component of a router. The network device 106 or AP may provide access to a network for multiple devices. For example, the network device 106 or AP may connect to a wired Ethernet connection and provide wireless connectivity using a radio frequency link so that other communication devices 102 can utilize the wired connection. The network device 106 or AP 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 the IEEE (e.g., the IEEE 802.11 standard, etc.) The network device 106 or AP may be configured and / or used to support public internet hotspots and / or may be configured and / or used on a network to extend the Wi-Fi signal range of the network.

[0029] In some embodiments, the access points or network devices 106 may be used in a wireless network (e.g., in a home, car, or building) (e.g., IEEE 802.11, Bluetooth, ZigBee, any other radio frequency-based network protocol and / or variations thereof). Each wireless communication device 102 may include and / or be coupled to a built-in radio. Such wireless communication devices 102 and / or access points or network devices 106 may operate in accordance with various aspects of the disclosure presented herein to improve performance, reduce cost and / or size, and / or enhance broadband applications. Each wireless communication device 102 may be capable of functioning as a client node seeking access to resources (e.g., data, connections to network nodes such as servers, etc.) via one or more access points or network devices 106.

[0030] The network connection may include any type and / or format of network. For example, it may include any of a point-to-point network, a broadcast network, a telecommunications network, a data communication network, and a computer network. The topology of the network may be bus, star, or ring. The network may be any such network topology known to those skilled in the art that can support the operations described herein. In some embodiments, different types of data may be transmitted using different protocols. In other embodiments, the same type of data may be transmitted using different protocols.

[0031] The communication device 102 and the access point or network device 106 may be arranged and / or implemented as any type and form of computing device, such as a computer, network device, or appliance, capable of communicating over any type and form of network and performing the operations described herein. FIGS. 1B and 1C are block diagrams illustrating computing devices 100 useful for implementing an embodiment of the wireless communication device 102 or the network device 106. As shown in FIGS. 1B and 1C, each computing device 100 includes a processor 121 (e.g., a central processing unit) and a main memory unit 122. As shown in FIG. 1B, the computing device 100 may include a storage device 128, an installation device 116, a network interface 118, an input / output (I / O) controller 123, display devices 124a-124n, a keyboard 126, and a pointing device 127, such as a mouse. The storage device 128 may include an operating system and / or software. As shown in FIG. 1C, each computing device 100 may further include additional optional elements. Optional components may include, for example, memory port 103, bridge 170, one or more I / O devices 130a-130n, and cache memory 140 in communication with central processing unit or processor 121.

[0032] Central processing unit or processor 121 is any logic circuitry that responds to and processes instructions fetched from main memory unit 122. In many embodiments, central processing unit or processor 121 is provided by a microprocessor unit, which may include, for example, those manufactured by Intel® Corporation of Santa Clara, California, IBM® (International Business Machines) of White Plains, New York, or AMD® (Advanced Micro Devices) of Sunnyvale, California. Computing device 100 may be based on any of these processors or any other processor capable of operating as described herein.

[0033] Main memory unit 122 is one or more memory chips that store data and allow the microprocessor or processor 121 to directly access any storage location. Main memory unit 122 can be any type or variety of static random access memory (SRAM), dynamic random access memory (DRAM), ferroelectric RAM (FRAM), NAND flash, NOR flash, solid-state drive (SSD), etc. Main memory unit 122 can be based on any of the above memory chips or any other available memory chip capable of operating as described herein. In the embodiment shown in FIG. 1B, processor 121 communicates with main memory unit 122 via system bus 150 (described in more detail below). FIG. 1C shows an embodiment of computing device 100 in which the processor communicates directly with main memory unit 122 via memory port 103. For example, in FIG. 1C, main memory unit 122 can be DRAM.

[0034] FIG. 1C illustrates an embodiment in which main processor 121 communicates directly with cache memory 140 through a secondary bus, sometimes referred to as a backside bus. In other embodiments, main processor 121 communicates with cache memory 140 using system bus 150. Cache memory 140 typically has a faster response time than main memory unit 122 and is provided, for example, by SRAM, BSRAM, or EDRAM. In the embodiment illustrated in FIG. 1C, processor 121 communicates with various I / O devices 130 through local system bus 150. Various buses can be used to connect central processing unit or processor 121 to any of I / O devices 130. Examples of buses that can be used include a VESAVL bus, an ISA bus, an EISA bus, a Micro Channel Architecture (MCA) bus, a PCI bus, a PCI-X bus, a PCI-Express bus, or a NuBus. In an embodiment in which the I / O device is a video display 124, processor 121 can communicate with display 124 using an Advanced Graphics Port (AGP). 1C illustrates an embodiment of computer or computer system 100 in which main processor 121 can communicate directly with I / O device 130b using communications technologies such as HYPER TRANSPORT, RAPID IO, or INFINI BAND. FIG. 1C also illustrates an embodiment in which local bus and direct communication are mixed: processor 121 communicates with I / O device 130a using a local interconnect bus, but communicates directly with I / O device 130b.

[0035] A wide variety of I / O devices 130a-130n may be present on computing device 100. Input devices include keyboards, mice, trackpads, trackballs, microphones, dials, touchpads, touchscreens, and drawing tablets. Output devices include video displays, speakers, inkjet printers, laser printers, projectors, and dye-sublimation printers. As shown in FIG. 1B, the I / O devices may be controlled by I / O controller 123. The I / O controller may control one or more I / O devices, such as keyboard 126 and pointing device 127, such as a mouse or optical pen. Additionally, the I / O devices may provide storage or installation media for computing device 100. In yet another embodiment, computing device 100 may include a USB connection (not shown) for accepting handheld USB storage devices, such as devices from the USB flash drive line manufactured by TwinTec Industries, Inc. of Los Alamitos, California.

[0036] Referring again to FIG. 1B , 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 memory drive, various types of tape drives, USB devices, hard drives, network interfaces, or other devices suitable for installing software or programs. Computing device 100 may also include a storage device, such as one or more hard disk drives or a redundant array of independent disks, for storing an operating system and other related software, as well as application software programs, such as any programs and software 120 for implementing (e.g., configured and / or designed for) the systems and methods described herein. Optionally, any of installation devices 116 may be used as a storage device. Additionally, the operating system and software may be executed from bootable media.

[0037] Additionally, computing device 100 may include a network interface 118 that connects to a network via a variety of connections, including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25, SNA, DECNET), broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET), wireless connections, or any or all combinations thereof. Connections can be established using a variety of 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 connections). In one embodiment, computing device 100 communicates with other computing devices 100' via any type and / or form of gateway or tunneling protocol, such as Secure Socket Layer (SSL) or Transport Layer Security (TLS). Network interface 118 may include an internal network adapter, a network interface card, a PCMCIA network card, a card bus network adapter, a wireless network adapter, a USB network adapter, or a modem, or any other device suitable for connecting computing device 100 to any type of network with the capabilities to communicate and perform the various operations described herein.

[0038] In some embodiments, computing device 100 may include or be connected to one or more display devices 124a-124n. Accordingly, any of I / O devices 130a-130n and / or I / O controller 123 may include any type and / or form of suitable hardware, software, or combination of hardware and software to support, enable, or provide for the connection and use of display devices 124a-124n by computing device 100. For example, computing device 100 may include any type and / or form of video adapter, video card, driver, and / or library for coupling with, communicating with, connecting to, or otherwise using display devices 124a-124n. In one embodiment, a video adapter may include multiple connectors for connecting with display devices 124a-124n. In other embodiments, computing device 100 may include multiple video adapters, each connected to display device(s) 124a-124n. In some embodiments, any portion of the operating system of computing device 100 may be configured to use multiple display devices 124a-124n. In yet another embodiment, I / O device 130 may be a bridge between system bus 150 and an external communications bus, such as a USB bus, an Apple Desktop Bus, an RS-232 serial connection, a SCSI bus, a FireWire® bus, a FireWire 800 bus, an Ethernet bus, an AppleTalk® bus, a Gigabit Ethernet bus, an Asynchronous Transfer Mode bus, a Fibre Channel bus, a Fiber Optic bus, a serially connected Small Computer System Interface bus, a USB connection, or an HDMI bus.

[0039] 1B and 1C may operate under the control of an operating system that controls task scheduling and access to system resources. Any operating system may be executed on the computing device 100, such as any version of the MICROSOFT® WINDOWS® operating system, various releases of the Unix® and Linux® operating systems, 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 various operations described herein. Common operating systems include, but are not limited to, Android®, manufactured by Google®, Inc.; WINDOWS 7, 8, and 10, manufactured by Microsoft Corporation of Redmond, Washington; MACOS, manufactured by Apple Computer, Inc. of Cupertino, California; WebOS®, manufactured by Research In Motion (RIM), Inc.; OS / 2, manufactured by IBM (International Business Machines), Inc. of Armonk, New York; and Linux, a freely available operating system distributed by Caldera Corp. of Salt Lake City, Utah; or any type and / or form of Unix operating system.

[0040] Computer system or computing device 100 may be any workstation, telephone, desktop computer, laptop or notebook computer, server, handheld computer, or mobile phone, or other portable telecommunications device, media playback device, gaming system, or mobile computing device, or any other type and / or form of computing device, telecommunications device, or media device capable of communications. In some embodiments, computing device 100 may have a variety of processors, operating systems, and input devices appropriate for the device. For example, in one embodiment, computing device 100 is a smartphone, mobile device, tablet, or personal digital assistant (PDA). Furthermore, computing device 100 may be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, or mobile phone, or other form of computing or telecommunications device with communications capabilities and sufficient processor power and memory capacity to perform the various operations described herein.

[0041] Aspects of the above operating environment and components will become apparent in the context of the systems and methods disclosed herein.

[0042] B. SYSTEMS AND METHODS FOR IMPROVING ACCESS POINT DETECTION USING DYNAMIC DWELL TIMES

[0013] Various concepts related to techniques, approaches, methods, apparatus, and systems for improving access point detection using dynamic dwell times, as well as embodiments thereof, are described in detail below. The various concepts introduced above and described in more detail below are not limited to any particular implementation method and may be implemented in numerous ways. Specific embodiments and application examples are provided primarily for illustrative purposes.

[0043] The technical solution disclosed herein can address challenges such as inefficient access point (AP) detection, limited scan dwell time, channel congestion, basic service set (BSS) overlap, and degraded network performance in high-density wireless local area network (WLAN) environments. On the non-AP station (STA) side, custom or standard-defined fields identifying the scan dwell time (SDT) and priority can be added to probe requests, allowing for classification from low to high priority according to different scan configurations. On the AP side, the access point can prioritize probe responses based on the STA's SDT and priority to maintain timely delivery or delay responses when congestion prevents them from being scheduled within the SDT. APs can also prioritize traffic using the access category for voice (AC-VO). Furthermore, APs can include an average response time indicator (ART-PReq) and an abbreviated neighbor report (RnR) element in beacon frames or probe response frames, as well as co-located AP channel congestion (CC) and channel utilization (CU) information. In the event of poor performance or heavy congestion, STAs can utilize the ART-PReq, CC, and CU data obtained from RnR or beacons to adjust their dwell time when scanning for co-located APs or perform multi-link (ML) probing. This technical solution can be extended to future standards such as 802.11bn (UHR / Wi-Fi8). Furthermore, APs can provide average response time indicators for authentication request (ART-AuthReq) and (re)association request (ART-AssocReq) frames, allowing STAs to fine-tune their dwell time during these processes. This adjustment can also be extended to action frames such as Add Block ACK (ADDBA) requests / responses and ART-ActionReq.Furthermore, STAs can dynamically increase their scan dwell time based on local interference (e.g., energy detection (ED) frames and duplicate BSS (OBSS) frames), and APs can detect and ignore duplicate probe requests, thereby reducing the delivery of unnecessary responses. Therefore, the technical solution disclosed in this specification can improve access point detection and overall network efficiency.

[0044] 2 illustrates an example system 200 for improving access point detection using dynamic dwell times. The example system 200 may include one or more access points 205A-205N (hereinafter sometimes referred to as access points 205) communicatively coupled to one or more stations 215A-215N (hereinafter sometimes referred to as stations 215) via one or more networks 210. Any of the systems described in connection with FIGS. 1A-1C may be configured, constructed, or implemented to implement, operate, and / or use any of the options and techniques described in FIG. 2.

[0045] The access point 205 may include a device, system, or module (including a combination of hardware and software) that enables a wireless communication device to connect to a wired network using Wi-Fi or other standards. The access point 205 is sometimes referred to as a wireless access point (WAP). The access point 205 may include components such as an antenna for transmitting and receiving wireless signals, a radio device for managing wireless communications, a CPU for data processing and control operations, and memory (DDR) for storing operational data and settings. The access point 205 may be implemented (e.g., configured, designed, and / or built) to operate in a wireless local area network (WLAN). In some embodiments, the access point 205 may be capable of connecting to a router (e.g., via a wired network) as a standalone device. In some embodiments, the access point 205 may be a component of a router. The access point 205 may provide access to a network for multiple devices. For example, the access point 205 may connect to a wired Ethernet connection and provide wireless connectivity using a radio frequency link so that other devices can utilize the wired connection. The 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 the IEEE (e.g., the IEEE 802.11 standard, etc.) Access points 205 may be configured and / or used to support Internet hotspots or to extend the Wi-Fi signal range of a network on a network.

[0046] Network 210 may include a computer network such as the Internet, a local area network, a wide area network, a metro area network, other area network, an intranet, a satellite network, or another computer network such as a voice or data cellular communication network, and combinations thereof. Network 210 may be any form of computer network capable of relaying information between access points 205, stations 215, and one or more information sources such as web servers or external databases. Network 210 may include the Internet and / or other types of data networks (e.g., local area networks (LANs), wide area networks (WANs), cellular networks, satellite networks, 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 wired and / or wireless connections. Any or all of the computing devices described herein may communicate wirelessly (e.g., via Wi-Fi, cellular, radio, etc.) with transceivers that are wired (e.g., via fiber optic cable, CAT5 cable, etc.) to other computing devices in network 210. Any or all of the computing devices described herein may communicate wirelessly with computing devices in network 210 through a proxy device (e.g., router, network switch, gateway).

[0047] The station 215 may be a wireless communication device configured for wireless communication in a wireless communication network, such as a LAN, a WAN, a cellular network, etc. The station 215 may be configured to wirelessly communicate with network devices, such as an access point 205, using any of the IEEE standards (e.g., the IEEE 802.11 standard). The station 215 may be any of the user devices described in connection with Figures 1A-C. In some embodiments, the station 215 may include one or more wireless communication devices 102 configured to receive service from a communication system, as shown in Figure 1A.

[0048] In some embodiments, the access point 205 may include a network interface 220. The 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 probe responses over a wireless network. The network interface 220 may include a wireless communication device capable of managing the transmission and reception of wireless signals operating at specific frequencies (e.g., 2.4 GHz and 5 GHz) and supporting various Wi-Fi standards. In some embodiments, the network interface 220 may include an Ethernet port capable of providing a primary wired connection point, allowing the access point 205 to connect to a router or switch in a wired network. The network interface 220 may further include an antenna to extend the strength and coverage area of ​​the wireless signal. The network interface 220 may include an onboard processor and memory capable of executing firmware that manages data flow between the wired and wireless networks, facilitates encryption and decryption, and controls the functionality of the access point. The network interface 220 may include firmware and software interfaces that may provide an operating system and configuration settings, allowing an administrator to manage the access point 205, set security protocols, and improve performance.

[0049] In some embodiments, the network interface 220 of the access point 205 can receive a probe request. The network interface 220 can receive the probe request from the station 215. The probe request can identify the station 215's scan dwell time and an associated priority value. The scan dwell time refers to the amount of time the station 215 or access point 205 spends scanning a particular channel. The priority value can indicate the urgency of the request. In some embodiments, the priority value can include a low priority value (e.g., for an initial unconnected scan or discovery), a normal priority value (e.g., for a normal roaming scan or background connected scan), or a high priority value (e.g., for a final roaming scan where connectivity is more urgent). The network interface 220 can listen for incoming signals. The network interface 220 can continuously monitor the radio frequency (RF) spectrum for signals matching the characteristics of a probe request. When the network interface 220 detects a signal, it can demodulate the signal and extract the data. The received data can be analyzed and certain fields and values ​​checked to determine whether it is a valid probe request. If the probe request is valid, the 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, the network interface 220 of the access point 205 can prioritize the probe responses based on a priority value.

[0050] In some embodiments, the network interface 220 of the access point 205 can generate a probe response. The probe response can 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 can incorporate one or more metrics, such as the average response time for a probe request. In some embodiments, the metrics can be determined based on at least a channel congestion level (e.g., multiple devices attempting to use the same channel simultaneously) or channel utilization data (e.g., how much capacity of a wireless communication channel is being used at any given time). The metrics may refer to specific measurements or indicators used to evaluate the performance or quality of a wireless connection during the probing process. The probing process in a wireless network can be used by a station 215 to discover available access points 205 and networks and can include active probing and passive probing. In active probing, the station 215 can send probe requests on different channels. Upon receiving these requests, the access point 205 returns a probe response that provides information about the network, such as the SSID, supported data rates, and security settings, allowing the station 215 to quickly discover nearby networks. In passive probing, the station 215 can listen for beacon frames that are periodically broadcast by the access point 205. After collecting and organizing the data, the network interface 220 can generate a probe response that includes custom or standard-defined fields as needed. The network interface 220 can modulate the probe response data onto a carrier wave and transmit it to the station.

[0051] In some embodiments, the network interface 220 of the access point 205 can determine whether a probe response can be transmitted within the scan dwell time. The network interface 220 can determine whether a probe response can be transmitted within the scan dwell time by evaluating various factors. For example, the network interface 220 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 network interface 220 can evaluate signal strength using a received signal strength indicator (RSSI), giving higher priority to requests with stronger signals, which generally indicate closer distances. If a probe request contains a specific SSID that matches the access point's network, the network interface 220 can prioritize the probe request over generic or wildcard requests. In some embodiments, the network interface 220 can determine priority based on the station's capabilities (e.g., support for a particular Wi-Fi standard or security protocol (e.g., WPA3)). In some embodiments, the network interface 220 can evaluate the current network load and prioritize requests from stations 215 that are more likely to maintain stable and efficient connections even under heavy load. In some embodiments, the network interface 220 may take into account quality of service (QoS) requirements specified in the probe requests and prioritize requests that require low latency or real-time performance.

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

[0053] In some embodiments, the network interface 220 of the access point 205 may transmit a probe response if it determines that a probe response can be scheduled within the scan dwell time. The probe response or beacon frame may include a field identifying a metric, such as the average response time for probe requests. In some embodiments, the metric may be included in the probe response or beacon frame. A field may refer to a specific data element in a communication frame used to convey information or metrics between devices. The 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 transmitted using an existing beacon, simplified neighbor report (RnR), or probe response. A custom field may be a data element in a communication frame configured for a specific application or use case and is not defined by an industry standard. A custom field may be a proprietary element. In some embodiments, the field may be a custom specification defined within the UHR (Ultra High Rate) standard or a similar protocol. The metric may provide data regarding the response efficiency of the access point, allowing stations to more accurately assess network conditions. The proprietary elements may include additional performance metrics such as channel congestion and utilization, providing a detailed view of the network environment. The proprietary elements may include data fields that are not part of a standard protocol. The proprietary elements may be defined according to a proprietary protocol used by the station 215 and the access point 205. Unlike a standard protocol (e.g., IEEE 802.11 for Wi-Fi), the proprietary protocol may include custom features not available in the standard protocol. The proprietary elements may include an Organizationally Unique Identifier (OUI), which is a 24-bit number assigned by the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority.OUIs may be used in a variety of contexts, such as the first 24 bits of a MAC address to identify the manufacturer of a network device, protocol identifiers to determine the source or destination organization, and vendor-specific information to globally distinguish devices.

[0054] In some embodiments, a metric may refer to a measurable data point or indicator used to evaluate the performance of an access point 205. A time metric may specify the average time it takes for the access point 205 to receive or respond to a probe request. In this regard, average time may refer to the time between a station 215 sending a probe request and the access point 205 receiving and responding to the probe request. In some embodiments, the terms “metric” or “time metric” are used interchangeably. In some embodiments, a metric may include an average response time to an authentication request from a station 215 (e.g., ART-AuthReq), an average response time to an association request (ART-AssocReq), or an average response time to a reassociation request (ART-ReassocReq). For example, the response time to an authentication request may evaluate how quickly the access point 205 can verify the identity of a station 215, and the response time to an association request may evaluate how quickly the access point 205 can establish a connection with a station 215. The response time to the reassociation request can be used to assess how quickly the access point 205 can re-establish a connection with the station 215. In some embodiments, these metrics can be extended to action frames such as Add Block ACK (ADDBA) Request / Response and ART-ActionReq. In some embodiments, the access point can send a simplified neighbor report (RnR) to its co-located access points, including channel congestion and channel utilization. These metrics can be used to provide information about the network condition to the station 215 and other devices.

[0055] In some embodiments, the network interface 220 of the access point 205 can ignore duplicate probe requests if it determines that a response cannot be scheduled within the scan dwell time. In some embodiments, the network interface 220 can skip sending probe responses. In some embodiments, the network interface 220 can detect and ignore duplicate probe requests sent from the same station. For example, the network interface 220 can identify duplicates by comparing timestamps, matching MAC addresses, or processing the content of the incoming requests. In some embodiments, the access point 205 can send a probe response to the station 215 through a secondary (or second) access point 205 associated with the 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 the station 215 may be within communication range of each other, allowing the signal strength between them to be sufficient for reliable data transmission. For example, when station 215 and second access point 205 are said to be within communication range, it means that the configuration allows the communication link to support effective data transfer.

[0056] In some embodiments, the 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 the access point 205 spends on each channel during a scan. The scan dwell time monitor 225 may monitor channel scans. Channel scans include periodically scanning different channels to detect probe requests, interference, and rogue devices. The dwell time monitored by the scan dwell time monitor 225 may vary depending on the operating mode. Examples of operating modes include access point mode (short dwell time), air monitor mode (longer dwell time for security tasks), and spectrum monitor mode (context-dependent dwell time for analyzing the radio frequency environment).

[0057] In some embodiments, the scan dwell time monitor 225 of the access point 205 can determine whether a probe response can be scheduled within the scan dwell time. The scan dwell time monitor 225 can evaluate resource availability, such as processing power and channel bandwidth, to determine whether the access point 205 can manage the probe response. In some embodiments, the scan dwell time monitor 225 can evaluate 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 an estimated response time to the time remaining in the scan dwell period.

[0058] In some embodiments, the 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 the access point 205 spends scanning each channel. The scan dwell time adjuster 230 may vary the scan dwell time based on network conditions and specific requirements. For example, in an environment with high interference or many rogue devices, the access point 205 may dwell longer on certain channels to gather more detailed information. In some embodiments, the scan dwell time adjuster 230 may shorten the dwell time to reduce client connection interruptions. In some embodiments, the scan dwell time adjuster 230 may lengthen 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 the specific scanning needs of the environment. The scan dwell time adjuster 230 can perform adaptive scanning that prioritizes channels with more activity, allowing the access point 205 to spend more time on channels that are more likely to experience problems.

[0059] In some embodiments, the scan dwell time adjuster 230 of the 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 an adjustment is necessary. For example, the scan dwell time adjuster 230 can shorten the scan dwell time in a high-traffic environment to minimize interruptions, or lengthen the scan dwell time in a low-traffic environment to perform a more thorough scan. In some embodiments, the access point 205 can evaluate its own performance, such as average response time to probe requests, to determine whether an adjustment by the scan dwell time adjuster 230 is necessary. The scan dwell time adjuster 230 can determine an adjustment to the scan dwell time based on collected data. The access point 205 can update its internal parameters to apply the adjusted scan dwell time.

[0060] In some embodiments, the access point 205 may include a queue manager 235. The queue manager 235 may be or include any script, file, program, application, instruction set, or computer-executable code configured to manage the ordering of data packets through a queue for transmission or reception. A queue may refer to a buffer used to manage data packets passing through a network. The queue manager 235 may include input queues that temporarily store incoming data packets before processing and output queues that hold data packets ready for transmission. The queue manager 235 may determine the order in which packets are processed and transmitted. The queue manager 235 may prioritize packet processing and transmission based on QoS requirements and network conditions. In some embodiments, the queue manager 235 may regulate data flow, delay, or drop packets to avoid network congestion. In some embodiments, the queue manager 235 may inspect incoming packets and assign them to one or more queues based on packet type, source, destination, or QoS requirements. In some embodiments, the queue manager 235 can dynamically allocate buffer space to manage buffering and prevent overflow. The queue manager 235 can adjust sending rates and buffer sizes based on network conditions. In some embodiments, the queue manager 235 can implement policies to maintain a consistent data flow.

[0061] In some embodiments, the queue manager 235 of the access point 205 can queue probe requests or ignore duplicate probe requests. The access point 205 can detect and ignore duplicate probe requests sent from the same station 215. For example, the access point 205 can identify duplicates by comparing timestamps, matching MAC addresses, or processing the content of the incoming requests. In some embodiments, if the queue manager 235 has already queued a response to a previous request, the access point 205 can refrain from responding to a new probe request until the previously generated response has been processed.

[0062] Station 215 may include a network interface 220, a scan dwell time monitor 225, and a 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 the interface 220, scan dwell time monitor 225, and scan dwell time adjuster 230 of access point 205 and may include any of the structure and functionality of the corresponding elements.

[0063] The network interface 220 of the station 215 can manage the sending and receiving of probe requests and probe responses. The network interface 220 can include a wireless network adapter that incorporates a physical layer (PHY) and a media access control (MAC) layer to enable the station 215 to connect to a wireless network. The network interface 220 can include an antenna for sending and receiving wireless signals. The network interface 220 can include driver software that interfaces with an operating system and a wireless network adapter. The driver software may be used to scan for available networks, connect to access points, and manage data transmissions. The network interface 220 can support various network protocols, such as IEEE 802.11. The network interface 220 can provide security features, including support for encryption protocols such as WPA2 and WPA3. The network interface 220 can include a graphical user interface (GUI) or a command line interface (CLI) for users to configure network configuration information, select networks, enter security keys, and manage network profiles.

[0064] In some embodiments, the network interface 220 of the station 215 can generate a probe request. The network interface 220 can generate a probe request for access point discovery. The probe request can include information such as the station's scan dwell time and a corresponding priority level. The priority can indicate the urgency of the request, allowing the access point 205 to prioritize its response. For example, the access point 205 can determine whether it can respond within the allotted time based on the SDT or priority and prioritize the response accordingly. In some embodiments, the priority can be categorized into different values. For example, the priority can be categorized as low priority for an initial disconnected scan or discovery, normal priority for a normal roaming scan or background connected scan, and high priority for a final roaming scan. The network interface 220 can determine that a scan for available access points is necessary. This scan can be initiated by a user action, such as connecting to a Wi-Fi network, or automatically based on a predetermined time interval or network conditions. The probe request may include a MAC address, a random identifier (timestamp), a service set identifier (SSID) (e.g., a specific SSID or a wildcard), and capability information (e.g., supported data rates, security protocols, etc.) In some embodiments, the network interface 220 may include a scan dwell time (e.g., the amount of time a station waits for a response) as a custom or standard-defined field in the probe request.

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

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

[0067] In some embodiments, the network interface 220 of the station 215 can receive a probe response if a response timeout has not occurred. If the probe response is received before the timer expires, the network interface 220 can extract an associated indicator from the probe response. In some embodiments, the network interface 220 can receive a probe response that includes custom or standard-defined fields. The custom fields, such as proprietary elements, or standard-defined fields can identify an indicator associated with the probe response.

[0068] In some embodiments, if the access point 205 is a co-located access point, the network interface 220 of the station 215 can receive indicators from the co-located access point via an abbreviated neighbor report (RnR). For example, the network interface 220 can extract indicators such as the average response time to a probe request (ART-PReq), channel congestion, or channel utilization from the RnR. Based on the reported indicators (e.g., if the ART-PReq, channel congestion, or channel utilization of the co-located access point is unfavorable), the network interface 220 can initiate multilink (ML) probing. For example, the network interface 220 can detect available access points 205 by transmitting probe request frames over multiple channels (e.g., 2.4 GHz, 5 GHz, 6 GHz). The co-located access point can respond with a probe response frame containing information about its capabilities (e.g., supported channels, SSID, security parameters, etc.). From the received responses, the network interface 220 can determine the optimal connection quality by evaluating signal strength, signal-to-noise ratio (SNR), and other metrics.

[0069] The scan dwell time monitor 225 of the station 215 can actively monitor the station's operation as the station 215 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 log the elapsed time spent on each channel. The scan dwell time monitor 225 can monitor incoming responses from the access point 205. The scan dwell time monitor 225 can collect data regarding the timing and frequency of responses received during the scan dwell period.

[0070] In some embodiments, the scan dwell time monitor 225 of the station 215 may be initialized to track the amount of time that has elapsed since the probe request was sent. In some embodiments, the scan dwell time monitor 225 may be configured to count up from zero, with the maximum value corresponding to a specified scan dwell time. The scan dwell time monitor 225 may measure the amount of time that has elapsed since the station 215 sent the probe request. The scan dwell time monitor 225 may be used to determine whether a response from the access point 205 is received within a specified time limit. In some embodiments, the scan dwell time monitor 225 of the station 215 may determine whether a response timeout has been reached. In some embodiments, the scan dwell time monitor 225 may start a timer when the station 215 sends a probe request. If the timer reaches a specified time limit before a probe response is received, 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 execute an event listener to listen for a probe response and may configure a timeout event that is fired at a predetermined time. If a probe response is received before the timeout event is fired, the scan dwell time monitor 225 may process the response and cancel the timeout event. If the timeout event is fired first, the scan dwell time monitor 225 may determine that the response timeout has been reached. In some embodiments, the scan dwell time monitor 225 may implement a hybrid approach that sets a timer along with an interrupt for incoming probe responses. Upon receiving a probe response, an interrupt is fired, and the station 215 may process the response while resetting the timer. If the timer reaches a specified time limit without an interrupt being fired, the scan dwell time monitor 225 may determine that the response timeout has been reached.

[0071] The scan dwell time adjuster 230 of the station 215 can dynamically change the dwell time based on network conditions. The scan dwell time adjuster 230 can adjust the time spent on each channel based on the scan results and network feedback. The scan dwell time adjuster 230 can evaluate the signal strength and response quality from the access points 205 to determine whether to increase or decrease the scan dwell time. In some embodiments, the scan dwell time adjuster 230 can store information about detected access points 205 and corresponding signal strengths.

[0072] In some embodiments, the scan dwell time adjuster 230 of the station 215 can dynamically increase the scan dwell time if a response timeout occurs. The scan dwell time adjuster 230 can adjust the scan dwell time based on local interference. For example, if the station 215 does not receive a response from the access point 205 after a portion (e.g., half) of the scan dwell time has elapsed, or if the station 215 determines that the surrounding channel conditions are highly congested (e.g., due to energy detect (ED) frames or overlapping basic service set (OBSS) frames), the scan dwell time adjuster 230 can dynamically increase the scan dwell time to account for the delay in probe response delivery caused by the congestion. ED frames can be used to determine whether a particular frequency band is occupied by a signal or is clear (i.e., contains only noise). OBSS frames can refer to data frames transmitted by the access point 205 and the station 215 within the overlapping coverage areas of different basic service sets (BSSs). In a wireless network, a BSS may be a group of devices that communicate with each other through a common access point 205 .

[0073] In some embodiments, the scan dwell time adjuster 230 of the station 215 can dynamically adjust the scan dwell time for 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 average response time to probe requests. The station 215 can continuously monitor network conditions and collect data on various factors. Based on the collected data, the station 215 can assess the need to adjust the scan dwell time. If an adjustment is necessary, the scan dwell time adjuster 230 can determine the appropriate change based on, for example, the severity of the congestion, the average response time, and the desired response level. In some embodiments, the station 215 can update its internal parameters to implement the updated scan dwell time. For example, if the station 215 detects high channel congestion or utilization, the station 215 can increase the scan dwell time using the scan dwell time adjuster 230 to allow more time for a response from the access point 205. In some embodiments, if station 215 detects a slow response time, scan dwell time adjuster 230 can increase the dwell time to give access point 205 more time to respond. In some embodiments, if the network is operating efficiently with low congestion and fast response times, scan dwell time adjuster 230 can decrease the scan dwell time to minimize overhead.

[0074] In some embodiments, if the access point 205 is a co-located access point, the station 215 can use the average response time to probe request (ART-PReq), channel congestion, or channel utilization provided in the RnR or beacon to adjust its scanning behavior via the scan dwell time adjuster 230. The scan dwell time adjuster 230 can dynamically adjust the scan dwell time when scanning for co-located access points on the channel of the station 215 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 scan dwell time adjuster 230 can dynamically adjust the scan dwell time.

[0075] In some embodiments, when station 215 is waiting for a response to an authentication request, association request, reassociation request, or add block ACK (ADDBA) request, scan dwell time adjuster 230 of station 215 can dynamically adjust the dwell time. For example, scan dwell time adjuster 230 can adjust the dwell time based on an average response time to corresponding requests provided by access point 205. In some embodiments, station 215 can update its internal parameters to perform the dwell time update. For example, if station 215 detects a slow response time to an authentication request, association request, reassociation request, or add block ACK (ADDBA) request, scan dwell time adjuster 230 can extend or adjust the dwell time.

[0076] FIG. 3 illustrates an example method 300 for improving access point detection using a dynamic dwell time. Method 300 may be implemented using systems 100, 200, or any other functionality described in FIGS. 1-2. Method 300 may include operations 302-318. At 302, a station may initialize. 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 a probe response. At 312, the station may check whether a response timeout has been reached. At 314, if a response timeout has occurred, the station may dynamically increase the scan dwell time. At 316, if a response timeout has not occurred, the station may receive a probe response. At 318, the station may dynamically adjust the scan dwell time for subsequent probe requests.

[0077] At 302, the station may initialize by powering on the station and enabling its wireless network interface. The station may scan for available networks by switching channels and listening for beacon frames from access points. The station may select a network based on factors such as signal strength and security settings. After selecting a network, the station may begin the authentication process and send an association request. Once authentication and association are complete, the station may obtain an IP address and configure its network configuration information.

[0078] At 304, the station may generate a probe request. The station may generate a probe request for access point discovery. The probe request may include information such as the station's scan dwell time and a corresponding priority level. The priority may indicate the urgency of the request, thereby allowing the access point to prioritize its response. For example, the access point may determine whether it can respond within the allotted time based on the SDT or priority level and prioritize the response accordingly. In some embodiments, the priority may be categorized into different values. For example, the priority may be categorized as low priority for an initial disconnected scan or discovery, normal priority for a normal roaming scan or background connected scan, and high priority for a final roaming scan.

[0079] A station may determine that a scan for available access points is necessary. This scan may be initiated by a user action, such as connecting to a Wi-Fi network, or automatically based on a predetermined time interval or network conditions. A probe request may include information such as a MAC address, a random identifier (timestamp), a service set identifier (SSID) (e.g., a specific SSID or a wildcard), and capability information (e.g., supported data rates and security protocols). In some embodiments, a station may include a scan dwell time (e.g., the amount of time the station waits for a response) as a custom or standard-defined field in a probe request. Custom fields, such as proprietary elements, may include 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 access point. Unlike standard protocols (e.g., IEEE 802.11 for Wi-Fi), proprietary protocols may include custom features not available in the standard protocol.

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

[0081] At 308, the station may activate a scan dwell time monitor. The scan dwell time monitor enables the station to track the time elapsed since transmitting a probe request. In some embodiments, the station's scan dwell time monitor may be configured to count up from zero, with the maximum value corresponding to a specified scan dwell time. The scan dwell time monitor may measure the time that has elapsed since the station transmitted the probe request. The scan dwell time monitor may be used to determine whether a response from an access point is received within a specified time limit.

[0082] At 310, the station can listen for a probe response. The station can activate its receiver to listen for an incoming probe response. The receiver may be tuned to the same channel used to transmit the probe request. The station can continuously monitor the incoming radio frequency (RF) spectrum and detect a signal that matches the expected characteristics of a probe response. If a signal is detected, the station can demodulate the signal. The station can analyze the received data and determine whether it is a valid probe response frame, for example, by checking specific fields or values. The station can compare the received probe response to a previously transmitted probe request to verify that it is a response to the station's own query.

[0083] At 312, the station may check whether the response timeout has been reached. In some embodiments, the station may start a timer when sending the probe request. If the timer reaches a specified time limit before receiving a probe response, the station may determine that the response timeout has been reached. In some embodiments, the station may execute an event listener to listen for a probe response and set a timeout event that is fired after a predetermined time. If a probe response is received before the timeout event is fired, the station may process the response and cancel the timeout event. If the timeout event is fired first, the station may determine that the response timeout has been reached. In some embodiments, the station may implement a hybrid approach that sets a timer along with an interrupt for an incoming probe response. Upon receiving a probe response, an interrupt is fired and the station may process the response while resetting the timer. If the timer reaches a specified time limit without the interrupt being fired, the station may determine that the response timeout has been reached.

[0084] At 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 detect (ED) frames or overlapping basic service set (OBSS) frames), the station can dynamically increase the scan dwell time to account for the congestion-induced probe response delivery delay.

[0085] At 316, if a response timeout did not occur, the station may receive a probe response. If the probe response is received before the timer expires, the station may extract an associated metric from the probe response. In some embodiments, the station may receive a probe response that includes custom or standard-defined fields. The custom or standard-defined fields, such as proprietary elements, may identify an metric associated with the probe response. The metric may specify the average time it takes an access point to receive or respond to a probe request.

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

[0087] In some embodiments, when a station is waiting for a response to an authentication request, association request, reassociation request, or block ACK add (ADDBA) request, the station can dynamically adjust the dwell time. For example, the station can adjust the dwell time based on an average response time to the corresponding request provided by the access point. In some embodiments, the station can update its internal parameters to implement the updated dwell time. For example, if the station detects slow response times to the authentication request, association request, reassociation request, or block ACK add (ADDBA) request, the station can extend or adjust the dwell time.

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

[0089] Referring to FIG. 4, an example embodiment is shown in which a station's scan dwell time is increased based on an assessment of local interference, as described in connection with FIG. 3, to successfully detect an access point. The station may send a probe request to an access point. The probe request may identify the station's scan dwell time. The station may initiate a scan dwell time monitor. The scan dwell time monitor may monitor for a probe response within a specified dwell time. For example, if a response is not received within that time due to local interference, the station may determine that a response timeout has occurred. In response, the station may dynamically increase the scan dwell time to allow additional time to receive a response. The station may continue to listen for a response within the newly extended scan dwell time.

[0090] Referring to FIG. 5, an example is shown in which a station detects a co-located access point on its own channel using the average response time of a probe request (ART-PReq) or channel utilization (CU) obtained from an abbreviated neighbor report (RnR), as described in connection with FIG. 3. The station can transmit a probe request on its own channel, and multiple access points (e.g., AP1 and AP2) may return probe responses. The station can receive an RnR from AP1 that includes information about AP2 (such as its corresponding ART-PReq and CU). Based on the RnR data, for example, based on the values ​​of ART-PReq and CU reported by AP1, the station can dynamically adjust its scan dwell time on AP2's channel. In this configuration, the station successfully detects AP2 by adjusting its scan dwell time.

[0091] Referring to FIG. 6, an example embodiment of a station using multilink (ML) probing to discover co-located access points is shown, as described in connection with FIG. 3. The station can transmit a probe request on its own channel, and the access points (e.g., AP1 and AP2) may return beacon or probe responses, respectively. The station can receive an abbreviated neighbor report (RnR) from AP1, which includes information about AP2, such as the average response time to a probe request (ART-PReq) and channel utilization (CU). If AP2's ART-PReq or CU is unfavorable, the station can initiate ML probing by sending an ML probe request to AP1 with a specific link identifier (e.g., link ID=AP2) indicating that it is attempting to establish a connection with AP2. AP1 can return an ML probe response with additional information related to the ML probe request to AP2. Using the ART-PReq value obtained from the RnR and the additional information obtained from the ML probe response, the station can dynamically adjust its scan dwell time on AP2's channel to improve the discovery process.

[0092] FIG. 7 illustrates another method 700 for improving access point detection using a dynamic dwell time. Method 700 may be implemented using systems 100, 200, or any other functionality described in FIGS. 1-2. Method 700 may include operations 702-720. At operation 702, an access point may be initialized. At operation 704, the access point may receive a probe request. At operation 706, the access point may determine whether it can transmit a probe response within the scan dwell time. At operation 708, the access point may identify an indicator. At operation 710, the access point may generate a probe response. At operation 712, the access point may check whether it can schedule a probe response within the scan dwell time. At operation 714, if the access point determines it can schedule a probe response within the scan dwell time, it may transmit the probe response. At operation 716, the access point may update an average response time indicator.

[0093] At 702, the access point may be initialized by powering on the access point and initiating a boot sequence. The access point's hardware components, such as the processor, memory, network interface, and wireless module, may be initialized and configured. The access point may load its operating system and software components into memory. The access point may load its configuration information, such as network parameters, security settings, and operating mode. The access point may perform a self-test to verify the functionality of its hardware and software. The access point may begin a network discovery process to identify other devices on the network. The radio may be configured by selecting a channel and setting transmit power. The access point may begin broadcasting beacon frames to announce its presence and provide network information, such as SSID, channel, and security. Once the initialization process is complete, the access point is ready to accept and process connections.

[0094] At 704, the access point may receive a probe request. The access point may receive a probe request from a station. The probe request may identify the station's scan dwell time and its associated priority. Priority may refer to the relative importance or urgency the station assigns to the probe request. The access point may listen for incoming signals via a network interface. The access point may continuously monitor the radio frequency (RF) spectrum for signals matching the characteristics of the probe request. When the access point detects a signal, it may demodulate the signal and extract data. The received data may be analyzed and checked for specific fields and values ​​to determine whether it is a valid probe request. If the probe request is valid, the access point may extract information such as the MAC address, desired SSID, scan dwell time, and other relevant parameters.

[0095] At 706, the access point may determine whether it can transmit a probe response within the scan dwell time by evaluating various factors. For example, the access point may prioritize probe requests based on supported data rates and give higher priority to stations with data rates compatible with the access point's capabilities. The access point may evaluate signal strength using a received signal strength indicator (RSSI) and may prioritize requests with stronger signals, which generally indicate closer range. If a probe request contains a specific SSID that matches the access point's network, the access point may prioritize the probe request over generic or wildcard requests. In some embodiments, the access point may determine priority based on the station's capabilities (e.g., support for a particular Wi-Fi standard or security protocol (e.g., WPA3)). In some embodiments, the access point may evaluate the current network load and prioritize requests from stations that are more likely to maintain a stable and efficient connection even under heavy load. In some embodiments, the access point may consider quality of service (QoS) requirements specified in the probe request and prioritize requests requiring low latency or real-time performance. In some embodiments, an access point may use an access category for voice (AC-VO) to prioritize probe responses, beacon frames, or other high priority traffic (e.g., voice or video communications).

[0096] At 708, the access point may identify metrics. The access point may identify metrics for evaluating current network conditions and determine whether the access point can respond to probe requests within a specified time frame. These metrics may include multiple factors, such as channel congestion, interference, and overall network load, and may be used to evaluate network performance and availability. In some embodiments, the access point may evaluate certain metrics, such as average probe request response time, channel utilization, and congestion severity, to thereby identify its own ability to process incoming requests based on network conditions and respond in a timely manner.

[0097] At 710, the access point may 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 average response time to a probe request, channel congestion level, and channel utilization data. After collecting and organizing the data, the access point may generate a probe response that includes custom or standard-defined fields as needed. The access point may modulate the probe response data onto a carrier and transmit it to the station.

[0098] In some embodiments, an access point may queue probe requests, which may refer to temporarily holding a probe request for later processing. An access point may also ignore duplicate probe requests. An access point may detect and ignore duplicate probe requests sent from the same station. For example, an access point may identify duplicates by comparing timestamps, matching MAC addresses, or processing the content of the incoming request. In some embodiments, if an access point already has a response to a previous request queued, the access point may refrain from responding to a new probe request until the previously generated response has been processed or transmitted.

[0099] At 712, the access point may determine whether a probe response can be scheduled within the scan dwell time. The access point may evaluate 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 may evaluate 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 may determine the time required to process and transmit the probe response by comparing the estimated response time with the time remaining in the scan dwell period.

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

[0101] At 716, the access point may update the average response time (ART-PReq) indicator. The access point may update the ART-PReq after sending a probe response to the station. The ART-PReq may specify the average time it takes to respond to a probe request. In some embodiments, the access point may update the ART-PReq indicator by averaging the response times of all requests over a certain period of time. The ART-PReq may be updated in real time or periodically (e.g., every minute, hour, or day). The updated ART-PReq indicator may be included in a beacon frame, a probe response, or an abbreviated neighbor report (RNR).

[0102] Referring now to FIG. 8, an example is shown in which an access point responds within the scan dwell time, i.e., successful access point detection, as described in connection with FIGS. 3 and 7. A station can transmit a probe request specifying a scan dwell time. When an access point receives a probe request, it can process the request by determining whether it can respond within the specified scan dwell time. The access point can generate and transmit a probe response to the station within the allotted time. In this configuration, the station receives the probe response before the scan dwell time expires.

[0103] Referring now to FIG. 9, an example is shown of an access point discovery failure, i.e., an example of a case where the access point is unable to respond within the scan dwell time, as described in connection with FIGS. 3 and 7. The station may send a probe request specifying the scan dwell time. The 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 does not send an acknowledgement (ACK) within a reasonable timeframe, the access point may attempt to retransmit the probe response. If the station still does not respond or if the access point is unable to send a response within the scan dwell time, the discovery process is considered a failure.

[0104] Referring now to FIG. 10, an example of successful access point detection with a high priority probe request is shown by utilizing a scan dwell time value and prioritizing probe responses to fit within a specified time, as described in connection with FIGS. 3 and 7. A station may transmit a probe request specifying a scan dwell time value and a priority level (e.g., high priority) as part of a proprietary or standard-defined field in the probe request. When an access point receives a probe request that includes a scan dwell time value, it may process the request based on the priority level. The access point may prioritize the probe responses and transmit the probe responses within the station-specified scan dwell time. For example, in this configuration, the station may receive a probe response before the scan dwell time expires.

[0105] Referring now to FIG. 11, an example of access point discovery failure due to a low-priority or normal-priority probe request, as described in connection with FIGS. 3 and 7, is shown. A station may transmit a probe request that includes a scan dwell time value and a priority level (e.g., low priority, normal priority, high priority) as part of a unique element in the probe request. An access point may receive and process the request. Based on the priority level, the access point may evaluate whether a response can be scheduled within the specified scan dwell time. If the access point determines that a response cannot be scheduled within the scan dwell time, the access point may cancel the transmission. The station may continue to wait for a response until the scan dwell time expires. In this configuration, the discovery process is considered unsuccessful because a response is not received within the scan dwell time.

[0106] It should be noted that in certain places in this disclosure, terms such as "first" and "second" may be used in connection with devices, modes of operation, transmission chains, roles, etc., to identify or distinguish one device from another. These terms are not intended to merely associate entities (e.g., a first device and a second device) in time or sequence, although in some cases these entities may include such a relationship. Nor do these terms limit the number of entities (e.g., devices) that may operate within a system or environment. The terms "coupled" or "connected" (which may refer to an electronic or communicative coupling or connection for purposes such as data transmission) include indirect and direct couplings and connections.

[0107] While the present disclosure has been described with respect to specific embodiments, those skilled in the art will recognize that numerous variations are possible. For example, specific examples of rules (including trigger conditions and / or resulting actions) and processes for generating suggested rules are described, but other rules and processes can be implemented. Embodiments of the present disclosure can be implemented using a variety of computer systems and communication technologies, including but not limited to the specific examples described herein.

[0108] Embodiments of the present 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 any combination of different processors. When a component is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or by any combination thereof. Furthermore, while the above embodiments 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 be used, and that certain operations described as being performed in hardware may also be performed in software, or vice versa.

[0109] A computer program incorporating various features of the present disclosure may be encoded on and stored on a variety of computer-readable storage media. Suitable media include magnetic disks or tapes, optical storage media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, and other non-transitory media. The computer-readable medium on which the program code is encoded may be packaged with a compatible electronic device, or the program code may be provided separately from the electronic device (e.g., via internet download or as a separately packaged computer-readable storage medium).

[0110] Therefore, although the disclosure has been described in terms of specific embodiments, it will be understood that the disclosure is intended to cover all modifications and equivalents that fall within the scope of the following claims.

[0111] It is understood that the disclosed embodiments do not represent all claimed inventions. Accordingly, certain aspects of the present disclosure have not been described herein. The fact that alternative embodiments not shown or described for certain portions of the invention may be available is not to be considered a disclaimer of those alternative embodiments. Accordingly, it is to be understood that other embodiments may be available and that functional, logical, operational, organizational, structural, and / or topological changes may be made without departing from the scope of the present disclosure. Accordingly, throughout this disclosure, all examples and / or embodiments should be considered non-limiting.

[0112] Some embodiments described herein relate to methods. It should be understood that these methods may be computer-implemented methods (e.g., instructions stored in a memory and executed on a processor). Where certain events are shown to occur in a particular order in the methods described above, the order of the certain events may be changed. Furthermore, certain events may be performed repeatedly, simultaneously in a parallel process if possible, or sequentially as described above. Furthermore, in certain embodiments, one or more of the described events may be omitted.

[0113] Some embodiments described herein relate to computer storage products with a non-transitory computer-readable medium (also referred to as a non-transitory processor-readable medium) having instructions or computer code for performing various computer-implemented operations. The computer-readable medium (or processor-readable medium) is non-transitory in the sense that it does not include a transitory propagating signal itself (e.g., a propagating electromagnetic wave carrying information over a transmission medium such as space or a cable). The medium and computer code (also referred to as code) may be designed and constructed for a specific purpose(s). Examples of non-transitory computer-readable media may include, but are not limited to, magnetic storage media such as hard disks, floppy disks, and magnetic tape; optical storage media such as compact disks / digital video disks (CDs / DVDs), compact disk read-only memories (CD-ROMs), holographic devices; magneto-optical storage media such as optical disks; carrier wave signal processing modules; and hardware devices specially configured to store and execute program code (e.g., application-specific integrated circuits (ASICs), programmable logic devices (PLDs), read-only memories (ROMs), random access memory (RAM) devices, etc.). Other embodiments described herein relate to computer program products that may include, for example, the instructions and / or computer code described herein.

[0114] Some embodiments and / or methods described herein may be implemented by software (executed 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 (executed on hardware) may be expressed in various software languages ​​(e.g., computer code), including C, C++, Java, Ruby, Visual Basic, 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 generated by a compiler, code used to generate web services, and files containing high-level instructions executed by a computer 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.

[0115] The 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 to scale, and in some cases, various aspects of the subject matter disclosed herein may be shown exaggerated or enlarged in the drawings to facilitate a comprehension of various features. In the drawings, like reference characters generally refer to like features (e.g., functionally similar and / or structurally similar elements).

[0116] Operations performed as part of the disclosed methods may be reordered in any suitable manner. Thus, embodiments may be constructed in which processes or steps are performed in an order different from that shown, and example embodiments may include some steps or processes being performed simultaneously, even when shown as sequential operations. In other words, it is understood that such features are not necessarily limited to a particular order of execution, but rather, any number of threads, processes, services, servers, etc. may be performed sequentially, asynchronously, simultaneously, in parallel, simultaneously, synchronously, etc., in a manner consistent with this disclosure. Thus, some of these features may be mutually inconsistent in that they cannot exist simultaneously in a single embodiment. Similarly, some features may be applicable to one aspect of the invention and not to other aspects.

[0117] Where a range of values ​​is presented, it is understood that all intervening values ​​(to the nearest tenth of the unit of the lower limit unless the context clearly dictates otherwise) between the upper and lower limits of that range, as well as other explicitly stated or intermediate values ​​within that range, are included in the disclosure. Within these smaller ranges, the upper and lower limits may each be independently included, and are also included in the disclosure, except where expressly excluded limits exist. Where one or both limits are included in a stated range, ranges excluding either or both limits are also included in the disclosure.

[0118] The phrase "and / or" as used in the present specification and embodiments should be understood to mean "either or both" of the conjoined elements, i.e., elements that are sometimes conjunctively present and sometimes disjunctively present. Multiple elements listed with "and / or" should be interpreted similarly, i.e., "one or more" of the conjoined elements. Elements other than the elements specifically identified by "and / or" may optionally be present, whether related to those specifically identified elements or not. Thus, as a non-limiting example, when the phrase "A and / or B" is used in combination with open-ended language such as "comprising," in one embodiment it can refer to only A (optionally including elements other than B), in another embodiment it can refer to only B (optionally including elements other than A), and in yet another embodiment it can refer to both A and B (optionally including other elements).

[0119] As used herein and in the embodiments, "or" should be understood to have the same meaning as "and / or" as defined above. For example, when separating items in a list, "or" or "and / or" is to be interpreted as inclusive, i.e., including at least one element, but also including two or more elements of a plurality or list of elements, and optionally additional unlisted items. Only terms clearly indicated to the contrary, such as "only one" or "exactly one," or "consisting of" as used in the embodiments, mean including exactly one element of a plurality or list. In general, the term "or" as used herein should be interpreted as indicating exclusive alternatives (i.e., "either / or," "one," "only one," or "exactly one") only when preceded by terms indicating exclusivity, such as "either / or," "one," "only one," or "exactly one." As used in the embodiments, "consisting essentially of" has its ordinary meaning as used in the field of patent law.

[0120] In this specification and in embodiments, the phrase "at least one" when used in reference to a list of one or more elements should be understood to mean at least one element selected from any one or more elements in the list of elements, but not necessarily including at least one of each element specifically listed in the list of elements, and not excluding any combination of elements in the list of elements. This definition also allows for the optional presence of elements other than those specifically identified in the list of elements to which the phrase "at least one" refers, whether related to those specifically identified elements or not. Thus, as a non-limiting example, "at least one of A and B" (or, synonymously, "at least one of A or B" or, synonymously, "at least one of A and / or B") may, in one embodiment, refer to at least one (optionally more than one) A and no B (but optionally including elements other than B). In another embodiment, they may refer to at least one (optionally more than one) B and no A (but optionally including elements other than A). In yet another embodiment, they may refer to containing at least one (optionally two or more) A and containing at least one (optionally two or more) B (and optionally containing other elements).

[0121] In the above embodiments and in the specification, all transitional phrases such as "comprises," "includes," "carries," "has," "contains," "involves," "holds," "consists of," etc. are understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases "consisting of" and "consisting essentially of" are closed-ended or semi-closed-ended transitional phrases, respectively.

Claims

1. a station, one or more processors coupled to a memory, the one or more processors: generating a probe request identifying a scan dwell time and priority of the station for access point detection; transmitting the probe request to be received by an access point; receiving a probe response from the access point that identifies an indicator including an amount of time until the access point responds to the probe request; adjusting the scan dwell time of the station for subsequent probe requests in response to the probe response; The station is configured as follows:

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

3. The station of claim 1 , wherein the indicator comprises an average response time for the access point to respond to the probe request.

4. 2. The station of claim 1, wherein the probe request includes a field identifying the indicator, the field including a custom field or a standard-defined field, the indicator including 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. 2. The station of claim 1, wherein the one or more processors are further configured to adjust the scan dwell time based on at least the indicator, the indicator including at least one of channel congestion, channel utilization, or average response time to the probe request.

6. The station of 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 indication via a simplified neighbor report of the co-located access point.

8. The one or more processors: scanning the co-located access points based on the average response time to probe requests of the co-located access points or the congestion indicator obtained from the simplified neighbor report; or Scanning for Co-located Access Points Using Multilink Probing 8. The station of claim 7, further configured to:

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

10. a station having a scan dwell time for waiting for a probe response; one or more processors coupled to a memory, the one or more processors: Sending a probe request to be received by an access point; While waiting for the probe response during the scan dwell time, determining at some point during the scan dwell time that the probe response has not yet been received from the access point; In response to the determination, dynamically increasing the scan dwell time while waiting for the probe response from the access point. The station is configured as follows:

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

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

13. an access point, one or more processors coupled to a memory, the one or more processors: receiving a probe request from a station identifying a scan dwell time and priority of said station; determining, based at least on the priority, to respond to the probe request within the scan dwell time; identifying one or more time indicators for the access point to respond to the probe request, the time indicators being determined based on at least a channel congestion or channel utilization; generating a probe response that includes one or more of the time indicators until the access point responds to the probe request; Transmitting the probe response within the scan dwell time The access point is configured as follows:

14. 14. The access point of claim 13, wherein the one or more processors are further configured to suspend transmission of the probe response if they determine that the probe response cannot be scheduled within the scan dwell time.

15. 14. 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, the second access point being identified based on a basic service set identifier included in the probe request.

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

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

18. an access point, one or more processors coupled to a memory, the one or more processors: receiving a probe request from a station identifying a scan dwell time for said station; determining that the access point is unable to transmit a probe response within the scan dwell time of the station; skipping the transmission of the probe response; queuing the probe request until resolution of the probe response; Ignore duplicate probe requests from the station while the probe request is queued. The access point is configured as follows:

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

20. 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, the priority value comprising at least one of a low priority value, a normal priority value, or a high priority value.

Images