Methods, apparatus and media for guiding in a mesh network by service equipment

Abstract

This document describes methods, systems, and apparatus for bootstrapping by a serving device in a mesh network. The method may include: determining that a client device within the scope of the serving device is eligible for bootstrapping, wherein the client device is outside a set of one or more triggering client devices; based on the determination, requesting a radio resource management report from at least one triggering client device in the set of one or more triggering client devices; receiving the radio resource management report from at least one triggering client device in the set of one or more triggering client devices; and performing a boot operation from the serving device to a target device based on the radio resource management report from the at least one triggering client device.

Description

Background Technology

[0001] This patent application claims the benefit of U.S. Patent Application No. 17 / 109,755, filed December 2, 2020, entitled “TRIGGER-CLIENTBASED CLIENT STEERING IN MESH NETWORKS”, which has been assigned to its assignee and is expressly incorporated herein by reference. Background Technology

[0003] The following relates to steer performed by service devices in a mesh network, including client-side steer based on trigger-client in a mesh network.

[0004] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, broadcasting, etc. These systems can be multiple access systems capable of supporting communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Wireless networks (such as WLANs, or Wi-Fi networks (i.e., IEEE 802.11 networks) can include access points (APs) that can communicate with one or more stations (STAs) or mobile devices. APs can be coupled to a network, such as the Internet, and can enable mobile devices to communicate via the network (or with other devices coupled to the access point). Wireless devices can communicate bidirectionally with network devices. For example, in a WLAN, a STA can communicate with its associated AP via a DL (or forward link) and a UL (or reverse link). The DL (or forward link) can refer to the communication link from the AP to the station, while the UL (or reverse link) can refer to the communication link from the station to the AP.

[0005] Some bootstrapping algorithms assign the same priority to all clients, resulting in equal bootstrapping opportunities for all clients in the network. However, assigning the same priority to all clients can lead to latency in bootstrapping responsive or compliant clients (e.g., clients that follow a wireless protocol), because non-responsive and non-compliant clients are given the same priority as responsive and compliant clients. Wireless systems and devices can benefit from improved techniques in bootstrapping algorithms. Summary of the Invention

[0006] The described technology relates to improved methods, systems, devices, and apparatuses for supporting client booting based on trigger-based clients in mesh networks. Generally, the described technology provides a serving device that determines client devices within its range are eligible for booting, and based on this determination, requests a radio resource measurement report from at least one of one or more trigger-based client devices. In some cases, the described technology provides a serving device that receives a radio resource management report from at least one of the one or more trigger-based client devices and performs booting operations from the serving device to a target device based on the radio resource management report from the at least one trigger-based client device. In some cases, the client device may not be part of a set of one or more trigger-based client devices. In some cases, the client device may be a non-responsive client device. In some cases, the client device may be one of the one or more trigger-based client devices.

[0007] This document describes a method for bootstrapping in a mesh network by a serving device. The method may include: determining that a client device within the range of the serving device is eligible for bootstrapping, wherein the client device is outside a set of one or more triggering client devices; based on the determination, requesting a radio resource management report from at least one triggering client device in the set of one or more triggering client devices; receiving the radio resource management report from at least one triggering client device in the set of one or more triggering client devices; and performing a boot operation from the serving device to a target device based on the radio resource management report from the at least one triggering client device.

[0008] This document describes an apparatus for bootstrapping by a service device in a mesh network. The apparatus may include a processor, memory coupled to the processor, and instructions stored in the memory. These instructions are executable by the processor to cause the apparatus to: determine that client devices within the service device's range are eligible for bootstrapping, wherein the client devices are outside a set of one or more triggering client devices; based on the determination, request a radio resource management report from at least one triggering client device in the set of one or more triggering client devices; receive the radio resource management report from at least one triggering client device in the set of one or more triggering client devices; and, based on the radio resource management report from the at least one triggering client device, perform a boot operation from the service device to a target device for the client device.

[0009] This document describes another apparatus for bootstrapping by a service device in a mesh network. The apparatus may include components for performing the following operations: determining that a client device within the service device's range is eligible for bootstrapping, wherein the client device is outside a set of one or more triggering client devices; based on the determination, requesting a radio resource management report from at least one triggering client device in the set of one or more triggering client devices; receiving the radio resource management report from at least one triggering client device in the set of one or more triggering client devices; and performing a boot operation from the service device to the target device for the client device based on the radio resource management report from the at least one triggering client device.

[0010] This document describes a non-transitory computer-readable medium storing code for booting by a service device in a mesh network. The code may include instructions that can be executed by a processor: determining that a client device within the service device's scope is eligible for booting, wherein the client device is outside a set of one or more triggering client devices; based on the determination, requesting a radio resource management report from at least one triggering client device in the set of one or more triggering client devices; receiving the radio resource management report from at least one triggering client device in the set of one or more triggering client devices; and performing a booting operation from the service device to a target device by the client device based on the radio resource management report from the at least one triggering client device.

[0011] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, performing a boot operation may include operations, features, components, or instructions for: comparing a channel power indicator received by a serving device as indicated in a radio resource management report with a channel power indicator received by a target device as indicated in the radio resource management report; and determining that the channel power indicator received by the target device exceeds the channel power indicator received by the serving device.

[0012] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, components, or instructions for: determining that a client device complies with a radio protocol, and, based on the determination that the client device complies with the radio protocol, requesting a second radio resource management report from the client device.

[0013] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for: receiving a radio resource management report from the client device; and directing the client device from the network of the serving device to the network of the target device based on the radio resource management report received from the client device.

[0014] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for assigning a higher boot priority to the client device than to one or more other client devices in the network of the serving device, based on receiving a radio resource management report from the client device.

[0015] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for: determining that a radio resource management report may not have been received from the client device, and estimating the channel power indicator received by the client device based on the channel power indicator received by the serving device or the channel power indicator received by the target device, or both, indicated in the radio resource management report of the at least one triggering client device.

[0016] In some examples of the methods, apparatuses and non-transitory computer-readable media described herein, the wireless protocol includes the 802.11k wireless protocol.

[0017] In some examples of the methods, apparatuses and non-transitory computer-readable media described herein, at least one aspect of a radio resource management report may be based on the 802.11k wireless protocol.

[0018] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, determining that a client device is eligible for booting may include operations, features, components, or instructions for determining that a received signal strength indicator of the client device meets a signal strength threshold.

[0019] Some examples of the methods, apparatuses, and nontransitory computer-readable media described herein may further include operations, features, devices, or instructions for: determining that a second client device may not be eligible for booting, monitoring the boot eligibility of a second client device, and identifying a triggering client device based on monitoring results and user requests or historical boot success rates, or both.

[0020] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, devices, or instructions for passing one or more parameters of a serving device’s network or one or more parameters of a target device’s network, or both, through a decision tree model, and a triggering client device for identifying the serving device’s network or the target device’s network based on the output of the decision tree model.

[0021] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, the serving device may be a serving access point, and the target device may be a target access point. Attached Figure Description

[0022] Figure 1 The illustration shows an example of a system that supports client booting in a mesh network based on a trigger-based client, according to various aspects of this disclosure, by a service device.

[0023] Figure 2 The diagram illustrates a block diagram of an example of a client-booting environment based on trigger-based clients in a mesh network, according to various aspects of this disclosure.

[0024] Figure 3 An example flowchart illustrating an exemplary method for client bootstrapping based on trigger-based clients in a mesh network, according to various aspects of this disclosure, is shown.

[0025] Figure 4 The diagram illustrates an example of a block diagram of an environment supporting a trigger-based client bootstrapping system in a mesh network, according to various aspects of this disclosure.

[0026] Figure 5 and Figure 6 A block diagram is shown that supports a client-booting device based on a trigger-based client in a mesh network, according to various aspects of this disclosure.

[0027] Figure 7 A block diagram is shown of a network manager that supports client-booting based on trigger-based clients in a mesh network, according to various aspects of this disclosure.

[0028] Figure 8 A diagram is shown illustrating a system for supporting client-booting devices based on trigger-based clients in a mesh network, according to various aspects of this disclosure.

[0029] Figures 9 to 11 A flowchart illustrating a method for client bootstrapping based on trigger-based clients in a mesh network, according to various aspects of this disclosure, is shown. Detailed Implementation

[0030] This technology includes client steering in mesh networks. It provides improvements to operations associated with client steering based on trigger-based client devices in mesh networks. Steering is a method that allows clients connected to a mesh node to seamlessly switch to other nodes in the mesh network without altering Layer 7 connectivity. Steering provides a balance between network load and carrier and user demands, data offloading, interference management, and energy-saving strategies.

[0031] Some bootstrapping algorithms may be based on wireless protocols (e.g., IEEE 802.11, 802.11k, etc.). In some cases, bootstrapping algorithms may be based on Radio Resource Management (RRM) measurement reports used to perform bootstrapping on client devices. In some cases, RRM measurement reports may be based on wireless protocols (e.g., based on the 802.11k wireless protocol). However, mesh networks can include both responsive and non-responsive client devices. In some cases, responsive client devices may be identified as conforming to a wireless protocol (e.g., the 802.11k wireless protocol) or as responding to a request for an RRM measurement report, or both. In some cases, non-responsive client devices may be identified as non-compliant with a wireless protocol or as not responding to a request for an RRM measurement report, or both. Therefore, some RRM measurement report-based bootstrapping methods may not be scalable to all devices on the network (e.g., non-compliant client devices, non-responsive client devices, compliant client devices that do not respond during allocated time periods, etc.). Because some client devices may not respond to requests for RRM measurement reports when requested (e.g., due to request timeout, non-compliance, etc.), the current bootstrapping method may result in some client devices not being adequately served, leading to an imbalance between network load and carrier and user needs, data offloading, interference management, and energy-saving strategies.

[0032] This technology provides an improvement over current bootstrapping mechanisms by enabling at least one client device in a mesh network to be configured as a triggering client device for non-responsive client devices. The triggering client device can be configured to provide measurement reports to one or more non-responsive client devices, enabling the associated non-responsive client devices to participate in bootstrapping based on the RRM measurement reports. In some cases, the triggering client device may be a client device identified (e.g., by an access point or other user client device) as conforming to a wireless protocol (e.g., 802.11k wireless protocol) and responding to a reporting request (e.g., an RRM measurement report request) based on that wireless protocol. In some cases, the triggering client device may include a client device identified (e.g., by an access point or other client device) as stationary or relatively stationary within a given network.

[0033] The various aspects of this disclosure are first described in the context of a wireless communication system. These aspects are further illustrated and described with reference to block diagrams and flowcharts relating to client booting based on trigger-based clients in a mesh network. The various aspects of this disclosure are further illustrated and described with reference to apparatus diagrams, system diagrams, and flowcharts relating to client booting based on trigger-based clients in a mesh network.

[0034] Figure 1 The illustration depicts a wireless local area network (WLAN) 100 (also referred to as a Wi-Fi network) configured according to various aspects of this disclosure. The WLAN 100 may include an access point (AP) 105 and multiple associated stations (STAs) 115, which may represent devices such as mobile stations, personal digital assistants (PDAs), other handheld devices, netbooks, laptops, tablets, desktop computers, display devices (e.g., TVs, computer monitors, etc.), printers, etc. The AP 105 and associated stations 115 may represent a BSS or ESS. The individual STAs 115 in the network are able to communicate with each other via the AP 105. A coverage area 110 of the AP 105 is also shown, which may represent a BSA of the WLAN 100. Extended sites (not shown) associated with the WLAN 100 may connect to a wired or wireless distribution system that allows multiple APs 105 to be connected in an ESS.

[0035] Although not in Figure 1As shown, STA 115 may be located at the intersection of more than one coverage area 110 and may be associated with more than one AP 105. A single AP 105 and the associated set of STA 115 may be referred to as a BSS. An ESS is a set of connected BSSs. A distribution system (not shown) may be used to connect AP 105s in an ESS. In some cases, the coverage area 110 of AP 105 may be divided into sectors (also not shown). WLAN 100 may include AP 105s of different types (e.g., urban areas, home networks, etc.) with different and overlapping coverage areas 110. Two STA 115s may also communicate directly via a direct wireless link 125, regardless of whether the two STA 115s are in the same coverage area 110. Examples of direct wireless links 120 may include Wi-Fi direct connection, Wi-Fi Tunneled Direct Link Establishment (TDLS) link, and other group connections. The STA115 and AP 105 can communicate using WLAN radio and baseband protocols for the physical and MAC layers from IEEE 802.11 and its various versions (including but not limited to 802.11b, 802.11g, 802.11a, 802.11n, 802.11ac, 802.11ad, 802.11ah, 802.11ax, 802.11k, etc.). In other implementations, peer-to-peer or ad hoc networks can be implemented within the WLAN 100.

[0036] In some cases, STA 115 (or AP 105) may be detected by the central AP 105, but may not be detected by other STA 115s within the coverage area 110 of the central AP 105. For example, one STA 115 may be located at one end of the coverage area 110 of the central AP 105, while another STA 115 may be located at the other end. Thus, these two STA 115s can communicate with AP 105, but may not be able to receive each other's transmissions. This can lead to transmission conflicts for the two STA 115s in a contention-based environment (e.g., CSMA / CA), as these STA 115s may not suppress transmissions over each other. STA 115s whose transmissions cannot be identified but are located within the same coverage area 110 may be referred to as hidden nodes. CSMA / CA can be supplemented by the exchange of RTS packets sent by the sending STA 115 (or AP 105) and CTS packets sent by the receiving STA 115 (or AP 105). This serves as a warning to other devices within range of the transmitter and receiver not to transmit during the duration of the main transmission. Therefore, RTS / CTS can help mitigate the hidden node problem.

[0037] The aspects of the subject matter described herein can be implemented to achieve one or more advantages. The described techniques can support improvements in system efficiency such that wireless devices (e.g., STAs, wireless devices stationary or relatively stationary within the network, etc.) can be defined as triggered client devices. In some cases, triggered client devices can conform to a wireless protocol (e.g., the 802.11k wireless protocol). In other cases, some wireless devices in the network may not conform to this wireless protocol.

[0038] In some examples, multiple wireless devices can be defined as a set of triggered client devices. In some cases, this set of triggered client devices can be updated periodically. In some cases, the access point can use this set of triggered client devices (e.g., information from this set) to make guidance decisions for other wireless devices (e.g., client devices other than those in the set). In some cases, this technology can enable an access point (e.g., AP 105) to guide some wireless devices (e.g., non-responsive client devices, poorly responsive client devices, non-compliant client devices) as effectively as responsive and compliant wireless devices. Accordingly, this technology improves the distribution of workload and bandwidth across multiple networks (e.g., multiple APs), resulting in an improved user experience.

[0039] Figure 2 The illustration shows an example of an environment 200 supporting client booting based on trigger-based clients in a mesh network, according to various aspects of this disclosure. In some examples, environment 200 may implement various aspects of WLAN 100.

[0040] In the illustrated example, environment 200 may include premises 205. Examples of premises 205 may include residences, offices, business premises, schools, or any other type of building. As depicted, premises 205 may include one or more rooms. For example, premises 205 may include rooms 210-1, 210-2, 210-3, and 210-4, and a central area 215 (e.g., a corridor, entrance, reception area, etc.). As shown, room 210-1 may include access point (AP) 105-a, and room 210-4 may include AP 105-b.

[0041] As depicted, location 205 may include one or more stations (STAs) or wireless communication devices. In some cases, the depicted one or more STAs may include one or more responsive STAs that follow a wireless protocol (e.g., the 802.11k wireless protocol) or respond to a reporting request based on that wireless protocol, or both. In the illustrated example, responsive STAs may include STA 115-a1, STA 115-a2, STA 115-a3, STA 115-a4, etc. In some cases, responsive STAs may include one or more triggering client devices, wherein the triggering client devices are determined (e.g., by AP 105-a or AP 105-b) to follow the wireless protocol and respond to a reporting request based on that wireless protocol. In some cases, triggering client devices may include client devices determined by AP 105-a or AP 105-b to be stationary or relatively stationary.

[0042] In some cases, the depicted one or more STAs may include one or more non-responsive STAs that do not comply with the wireless protocol, or do not respond to reporting requests based on the wireless protocol, or respond inconsistently to reporting requests based on the wireless protocol, or temporarily do not respond to reporting requests based on the wireless protocol, or any combination thereof. In the illustrated example, non-responsive STAs may include STA 115-b1 and STA 115-b2, etc. In some cases, one or more non-responsive STAs may comply with the wireless protocol, but may be identified as non-responsive STAs because they do not respond to reporting requests based on the wireless protocol.

[0043] In some cases, AP 105-a or AP 105-b can determine whether a non-responsive STA is eligible for bootstrapping based on whether the received signal strength indicator of the non-responsive STA meets a signal strength threshold. When AP 105-a or AP 105-b determines that a client device is a responsive STA (e.g., the STA follows a radio protocol), but the responsive STA is not a triggering client device, AP 105-a or AP 105-b can initiate a report request (e.g., a radio resource management measurement report) and send the request to the responsive STA. In some cases, AP 105-a or AP 105-b can send the request to the responsive STA and each triggering client device in the corresponding network (e.g., the network of AP 105-a or AP 105-b). When the responsive STA responds by sending a report to AP 105-a or AP 105-b, AP 105-a or AP 105-b can give the responsive STA higher priority than one or more non-responsive STAs. In some cases, when AP 105-a or AP 105-b receives a report from the responsive STA, AP 105-a or AP 105-b can continue the guidance operation for the responsive STA based on the information in the report (e.g., the received Channel Power Indicator (RCPI) information for AP 105-a and the RCPI information for AP 105-b).

[0044] In some cases, when AP 105-a or AP 105-b does not receive a report from the responsive STA (e.g., when the request times out, the responsive STA becomes a non-responsive STA, or when AP 105-a or AP 105-b does not receive the report within a given time period), AP 105-a or AP 105-b may estimate the approximate RCPI value of the responsive STA (e.g., a previously responsive STA, a STA still following the radio protocol, etc.) based on reports received by AP 105-a or AP 105-b from one or more triggering client devices that received and responded to the sent request.

[0045] In some cases, a non-responsive STA may not respond to a report request because it does not conform to a given radio protocol (e.g., the 802.11k radio protocol). When AP 105-a or AP 105-b determines that a non-responsive STA is not a compliant STA, AP 105-a or AP 105-b may initiate a report request (e.g., generate a Radio Resource Management Measurement Report Request) and send the request to each triggering client device in the corresponding network. In some cases, AP 105-a or AP 105-b may estimate an approximate RCPI value for the non-compliant STA with respect to AP 105-a or AP 105-b based on reports received by AP 105-a or AP 105-b from one or more triggering client devices that receive and respond to the sent request. In some cases, the more triggering client devices respond to the sent request by sending reports to AP 105-a or AP 105-b, the more accurate the estimated RCPI value for the non-compliant STA will be. In some examples, AP 105-a can guide non-compliant STAs to AP 105-b (or from AP 105-b to AP 105-a) based on the estimated RCPI value for the non-compliant STA.

[0046] In some examples, AP 105-a can be the serving AP for STA 115-a2, STA 115-b1, and STA 115-a3. In some cases, AP 105-a can determine that STA 115-a2 and STA 115-a3 are responsive STAs, and STA 115-b1 is a non-responsive STA. In some cases, AP 105-a can determine that STA 115-a2 or STA 115-a3, or both, are within a set of one or more triggering client devices, and STA 115-b1 is outside the set of one or more triggering client devices.

[0047] In some examples, AP 105-a can determine that STA 115-b1 is eligible for booting. In some examples, STA 115-b1 can be moved away from AP 105-a and closer to AP 105-b, and AP 105-a can determine that STA 115-b1 is eligible for booting based on this. In some cases, AP 105-a can determine that STA 115-b1 is eligible for booting based on the received signal strength indicator of STA 115-b1 meeting a signal strength threshold.

[0048] In some cases, AP 105-a can determine that STA 115-b1 is a non-responsive STA (e.g., STA 115-b1 is outside the set of one or more triggering client devices). In some examples, based on the determination that STA 115-b1 is a non-responsive STA, AP 105-a can request a radio resource management report from at least STA 115-a2 or STA 115-a3, or at least both (e.g., to at least one triggering client device in the set of one or more triggering client devices). In some examples, AP 105-a can request a radio resource management report from at least STA 115-a1 or STA 115-a4, or at least both.

[0049] In some examples, AP 105-a may receive radio resource management reports from at least STA 115-a2 or STA 115-a3, or at least both. Additionally or alternatively, AP 105-a may receive radio resource management reports from at least STA 115-a1 or STA 115-a4, or at least both. In some examples, AP 105-a may perform a bootstrapping operation from AP 105-a to AP 105-b for STA 115-b1 based at least in part on radio resource management reports from at least STA 115-a2 or STA 115-a3, or at least both (e.g., from at least one triggered client device).

[0050] In some examples, AP 105-b can be the serving AP for STA 115-a1, STA 115-b2, and STA 115-a4. In some cases, AP 105-a can determine that STA 115-a1 and STA 115-a4 are responsive STAs, and STA 115-b2 is a non-responsive STA. In some cases, AP 105-b can determine that STA 115-a1 or STA 115-a4, or both, are within a set of one or more triggering client devices, and STA 115-b2 is outside the set of one or more triggering client devices.

[0051] In some examples, AP 105-b can determine that STA 115-b2 is eligible for booting. In some examples, STA 115-b2 can be moved away from AP 105-b and closer to AP 105-a, and based on this, AP 105-b can determine that STA 115-b2 is eligible for booting. In some cases, AP 105-b can determine that STA 115-b2 is eligible for booting based on the received signal strength indicator of STA 115-b2 meeting a signal strength threshold.

[0052] In some cases, AP 105-b can determine that STA 115-b2 is a non-responsive STA (e.g., STA 115-b2 is outside the set of one or more triggering client devices). In some examples, based on the determination that STA 115-b2 is a non-responsive STA, AP 105-b can request a radio resource management report from at least STA 115-a1 or STA 115-a4, or at least both (e.g., from at least one triggering client device in the set of one or more triggering client devices). In some examples, AP 105-b can request the radio resource management report from at least STA 115-a2 or STA 115-a3, or at least both.

[0053] In some examples, AP 105-b can receive radio resource management reports from at least STA 115-a1 or STA 115-a4, or at least both. In some examples, AP 105-b can perform the bootstrap operation from AP 105-b to AP 105-a based at least in part on radio resource management reports from at least STA 115-a1 or STA 115-a4, or at least both (e.g., from at least one triggered client device).

[0054] In some examples, AP 105-b may receive radio resource management reports from at least STA 115-a2 or STA 115-a3, or at least both. In some examples, AP 105-b may perform a bootstrapping operation from AP 105-b to AP 105-a based at least in part on radio resource management reports from at least STA 115-a2 or STA 115-a3, or at least both (e.g., from at least one triggered client device).

[0055] When the network of AP 105-a or AP 105-b includes non-responsive STAs (e.g., STA 115-b1 or STA 115-b2), AP 105-a or AP 105-b may not receive RCPI from those non-responsive STAs. In some cases, AP 105-a or AP 105-b can determine (e.g., estimate or predict) the RCPI information of a non-responsive STA based on RCPI information from one or more responsive STAs. Therefore, AP 105-a or AP 105-b can receive RCPI information from one or more responsive STAs (e.g., STA 115-a1, STA 115-a2, STA 115-a3, or STA 115-a4) and estimate the RCPI value of a non-responsive STA (e.g., STA 115-b1 or STA 115-b2) based on the RCPI information from those one or more responsive STAs. The higher the number of responsive STAs (e.g., trigger-based client devices) that provide their RCPI information to AP 105-a or AP 105-b, the more accurate the predicted or estimated RCPI values ​​will be for non-responsive STAs.

[0056] In some examples, AP 105-a or AP 105-b can establish a point-to-point connection (e.g., a Wi-Fi Direct connection) between a non-responsive STA (e.g., STA 115-b1 or STA 115-b2) and a responsive STA (e.g., STA 115-a1, STA 115-a2, STA 115-a3, or STA 115-a4). In some cases, AP 105-a or AP 105-b can establish a point-to-point connection to obtain RCPI information from a poorly responsive or non-compliant client device (e.g., a non-11k compliant client device). In some cases, AP 105-a or AP 105-b can establish a point-to-point connection when a non-responsive STA becomes eligible for booting. In some cases, this point-to-point connection allows a responsive STA to receive RCPI values ​​from a non-responsive STA (e.g., when a non-responsive STA becomes eligible for booting).

[0057] Some bootstrapping algorithms treat all client devices (e.g., responsive STAs and non-responsive STAs, compliant STAs and non-compliant STAs) in the same way, giving all client devices in the network an equal bootstrapping opportunity. However, giving all client devices an equal bootstrapping opportunity can lead to latency in booting compliant and responsive STAs (e.g., trigger-based client devices). Furthermore, when giving non-responsive STAs an equal opportunity, that opportunity is often wasted because non-responsive STAs may not respond to requests for information (e.g., requests for RCPI information), resulting in boot failure.

[0058] In some examples, AP 105-a or AP 105-b may identify a responsive STA (e.g., a triggered client device following a wireless protocol such as 802.11k) and characterize the responsive STA as a "preferred" client device. In some cases, AP 105-a or AP 105-b may assign higher priority to the preferred client device (e.g., higher priority for booting operations than non-responsive STAs). In some cases, characterizing a responsive STA as a preferred client device may improve booting success rate (e.g., the number of successful booting operations / the total number of booting operations initiated). In some cases, characterizing a responsive STA as a preferred client device may provide a higher booting opportunity for the responsive client device, resulting in an improved user experience (e.g., when the client device is roaming). In some cases, AP 105-a or AP 105-b may ignore non-responsive STAs (e.g., non-preferred client devices) while performing booting operations on responsive STAs (e.g., preferred client devices).

[0059] The aspects of the subject matter described herein can be implemented to achieve one or more advantages. The described techniques support improvements in system efficiency such that delays in waiting for reports (e.g., requested radio resource management reports) requested by non-responsive STAs (e.g., determined by AP 105-a or AP 105-b to be unresponsive to such requests) are reduced. Additionally, the described techniques result in improved bootstrapping efficiency, thereby improving the user experience. Any triggering client device in the network can be configured to assist in bootstrapping non-responsive STAs in the network (e.g., based on a mesh network forming interdependence between triggering client devices and non-responsive STAs).

[0060] Figure 3 The illustration shows an example flowchart of a sample method 300 supporting trigger-based client bootstrapping in a mesh network, according to various aspects of this disclosure. In some examples, method 300 may implement various aspects of WLAN 100.

[0061] The operation of method 300 can be implemented by an access point (e.g., AP 105) or its components as described herein. The operation of method 300 can be implemented by a station (e.g., STA 115) or its components as described herein. The operation of method 300 can be implemented by a wireless device (e.g., AP 105 or STA 115, or both). For example, the operation of method 300 can be implemented by a device as described in the reference... Figures 5 to 8 The network manager described herein performs these functions. In some examples, the AP or STA, or both, can execute a set of instructions to control the functional elements of the AP or STA, or both, to perform the functions described herein. Additionally or alternatively, the AP or STA, or both, may use dedicated hardware to perform aspects of the functions described herein.

[0062] At 305, the wireless device can determine whether a client device (e.g., STA 115) is eligible for booting. When the wireless device determines that a client device is not eligible for booting, at 310, the wireless device can monitor (e.g., continue monitoring) the boot eligibility among client devices (e.g., one or more STA 115s).

[0063] At point 315, the wireless device may identify a client device based on a user request or a statistical rate (e.g., identifying the client device as eligible for booting). Statistical rates may include a boot success rate (e.g., the number of successful boots exceeds the total number of boots initiated), or a reporting success rate (e.g., the number of received reports exceeds the total number of requests initiated), or a request rejection rate (e.g., the number of rejected requests exceeds the total number of requests initiated), a timeout rate (e.g., the number of timeout reports exceeds the total number of requests initiated), an invalid reporting rate (e.g., the number of received invalid reports exceeds the total number of received reports), a response time (e.g., the time spent by the client device responding to a request), or any combination thereof. When the wireless device identifies a client device as eligible for booting at point 305, the wireless device may verify that booting eligibility.

[0064] At 320, when the wireless device determines at 305 that the client device is eligible for booting, the wireless device may determine whether the client device is tagged or characterized as a triggered client device. In some cases (e.g., prior to the determination at 320), the wireless device may characterize the client device as a triggered client device based on one or more parameters of the client device. In some cases, the user (e.g., prior to the determination at 320) may configure or characterize the client device as a triggered client device.

[0065] At point 325, when the wireless device determines at point 320 that the client device is not a triggered client device, the wireless device may request a Radio Resource Measurement (RRM) report from each triggered client device. In some cases, the wireless device may identify each triggered client device in the network (e.g., the wireless device's network) and request an RRM report from each identified triggered client device.

[0066] At 330, the wireless device can estimate the RCPI value of the client device based on the RRM report received by the wireless device from the triggered client device.

[0067] At 345, the wireless device can determine whether a signal strength threshold is met based on the estimated RCPI value of the client device. In some cases, the signal strength threshold can be based on the Received Signal Strength Indicator (RSSI) threshold. When the wireless device determines that the signal strength threshold is not met, it can continue monitoring eligibility between client devices at 310.

[0068] At point 350, when the wireless device determines that a signal strength threshold is met, the wireless device can redirect the client device from the serving frequency band to the target frequency band, or from the serving access point to the target access point. In some cases, the serving frequency band and the target frequency band can be provided by the same access point. In other cases, the serving frequency band can be provided by the serving access point, and the target frequency band can be provided by the target access point.

[0069] At point 335, when the wireless device determines at point 320 that a client device is a triggered client device, the wireless device can request an RRM report from that client device. In some cases, the wireless device can request RRM reports from each triggered client device regarding both the serving access point (e.g., AP 105-a or AP 105-b) and the target access point (e.g., AP 105-b or AP105-a). In some examples, the wireless device can be either the serving access point or the target access point.

[0070] At point 340, the wireless device can determine whether it has received a report from at least one triggering client device regarding the serving access point or the target access point, or both. If the wireless device determines that it has not received a report from at least one triggering client device regarding the serving access point or the target access point, or both, the wireless device can again request RRM reports regarding the serving access point and the target access point from each triggering client device at point 335.

[0071] At point 345, when the wireless device determines at point 340 that it has received a report from at least one triggered client device regarding the serving access point or the target access point, or both, the wireless device can determine whether a signal strength threshold is met. If the wireless device determines that the signal strength threshold is not met, the wireless device can continue monitoring eligibility among client devices at point 310.

[0072] At 350, when the wireless device determines that the signal strength threshold is met, the wireless device can redirect the client device from the serving frequency band to the target frequency band, or from the serving access point to the target access point.

[0073] Figure 4 The illustration shows an example of an environment 400 supporting client booting based on trigger-based clients in a mesh network, according to various aspects of this disclosure. In some examples, environment 400 may implement various aspects of WLAN 100.

[0074] In some examples, the various operations of environment 400 can be implemented by the AP 105 or its components described herein. In some examples, the various operations of environment 400 can be implemented by the STA 115 or its components described herein. The various operations of environment 400 can be implemented by a wireless device (e.g., AP 105 or STA 115, or both). For example, the various operations of environment 400 can be implemented by, as referenced... Figures 5 to 8 The network manager described herein performs these functions. In some examples, the AP or STA, or both, can execute a set of instructions to control the functional elements of the AP or STA, or both, to perform the various operations described herein. Additionally or alternatively, the AP or STA, or both, may use dedicated hardware to perform aspects of the functions described herein. In some examples, various operations of environment 400 may include identifying potential trigger client devices and selecting trigger client devices from among the identified potential trigger client devices.

[0075] In the illustrated example, environment 400 may include a network set 405 containing n networks, where n is a positive integer. In some cases, the maximum number of networks in network set 405 may be configured by the user. In some cases, network set 405 may include one or more network sets, wherein at least a first network set includes a first number of networks up to the specified maximum number of networks, and at least one second network set includes a second number of networks up to the specified maximum number of networks, wherein the second number of networks is less than, greater than, or equal to the first number of networks.

[0076] In the illustrated example, environment 400 may include machine learning model 410. In some cases, machine learning model 410 may include or may be based on decision tree learning model, supervised learning model, cluster model, artificial neural network model, or reinforcement learning model.

[0077] In some examples, a wireless device (e.g., AP 105 or STA 115, or both) may implement a machine learning model 410 to identify potential triggered client devices to assist the network in network set 405 in selecting triggered client devices. In some cases, the wireless device may collect one or more parameters from the network in network set 405. Table 1 provides examples of such parameters that may be collected and used to determine potential triggered client devices.

[0078]

[0079]

[0080] Table 1

[0081] Table 1 provides examples of one or more parameters related to the 802.11k wireless protocol. In some cases, these one or more parameters may be based on one or more wireless protocols, which may include the 802.11k wireless protocol. In some cases, the wireless device may characterize the client device as a triggered client device based on one or more parameters of the client device (e.g., based on at least one parameter in Table 1 provided by the network in network set 405). In some cases, the user may configure or characterize the client device as a triggered client device (e.g., user-defined parameters).

[0082] In some examples, the one or more parameters may be categorized into one of two different parameter sets. These two parameter sets may include cloud parameters and network parameters. In some cases, cloud parameters may include successful 11k reports, bootstrapping success rates, rejected requests, timeout reports, response times, invalid reports, or any combination thereof. In some cases, network parameters may include one or more constant parameters that do not depend on additional sampled data. In some cases, network parameters may include user-defined parameters (e.g., user-defined triggered client devices), wireless protocol capabilities, radio capabilities (e.g., the radio type configured on the client device), service data rates, or any combination thereof.

[0083] In the illustrated example, the machine learning model 410 can perform machine learning analysis on one or more parameters provided to the machine learning model 410 by the network set 405. In some cases, the machine learning model 410 can identify potential triggering client devices 415. In some cases, the machine learning model 410 can provide the identified potential triggering client devices 415 to the network in the network set 405.

[0084] Based on machine learning model 410, this technique improves client bootstrapping in a mesh network by improving the selection of triggering client devices. This technique increases the accuracy of triggering client device selection. For example, the analysis provided by machine learning model 410 improves the selection of client devices determined by machine learning module 410 to be the most suitable triggering client device for operation. This technique significantly reduces the time and overhead of selecting client devices as suitable triggering client devices for a given network of network set 405. This technique eliminates unnecessary delays from waiting for client reports, to which clients are very sluggish in response. This technique improves bootstrapping efficiency, and thus leads to an improved user experience. Based on this technique, any client device in a given network of network set 405 can assist (e.g., assist an access point (such as AP105)) in bootstrapping any other client device in the corresponding network, thereby forming an interdependent mesh network. This technology identifies client devices with specified capabilities (e.g., wireless protocol compliant client devices, 802.11k compliant client devices, etc.) and selects them as triggering client devices. Using these identified client devices as triggering client devices not only improves the efficiency of guidance decisions at access points (e.g., AP 105) but also enhances the overall efficiency of the corresponding network. This technology leverages these specified capabilities in the identified client devices to assist in guiding other clients in the network that may not possess the same specified capabilities, thereby providing a better distributed and more equitable network.

[0085] Figure 5 A block diagram 500 shows a device 505 supporting client booting based on trigger-based clients in a mesh network, according to various aspects of this disclosure. The device 505 may be an example of various aspects of the device described herein. The device 505 may include a receiver 510, a network manager 515, and a transmitter 520. The device 505 may also include a processor. Each of these components may communicate with each other, for example, via one or more buses.

[0086] The receiver 510 can receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to client booting in a mesh network based on trigger-based clients). The information can be transmitted to other components of the device 505. The receiver 510 can be a reference. Figure 8 Examples of various aspects of the transceiver 820 described. The receiver 510 may utilize a single antenna or an array of antennas.

[0087] The network manager 515 can determine that a client device within the range of the serving device is eligible for booting, wherein the client device is outside the set of one or more triggering client devices; based on this determination, it requests a radio resource management report from at least one triggering client device in the set of one or more triggering client devices; receives the radio resource management report from at least one triggering client device in the set of one or more triggering client devices; and, based on the radio resource management report from the at least one triggering client device, performs a booting operation for the client device from the serving device to the target device. The network manager 515 may be an example of aspects of the network manager 810 described herein.

[0088] The network manager 515 or its sub-components may be implemented in hardware, processor-executable code (e.g., software or firmware), or any combination thereof. If implemented as processor-executable code, the functionality of the network manager 515 or its sub-components may be performed by a general-purpose processor, DSP, application-specific integrated circuit (ASIC), FPGA or other programmable logic device designed to perform the functions described in this disclosure, discrete gate or transistor logic, discrete hardware components, or any combination thereof.

[0089] The network manager 515 or its subcomponents may be physically located in various locations, including distributed so that the various parts of the functionality are implemented by one or more physical components at different physical locations. In some examples, according to aspects of this disclosure, the network manager 515 or its subcomponents may be separate and distinct components. In some examples, according to aspects of this disclosure, the network manager 515 or its subcomponents may be combined with one or more other hardware components, including but not limited to input / output (I / O) components, transceivers, network servers, another computing device, one or more other components described in this disclosure, or combinations thereof.

[0090] The transmitter 520 can transmit signals generated by other components of the device 505. In some examples, the transmitter 520 can be co-located with the receiver 510 in a transceiver module. For example, the transmitter 520 can be a reference... Figure 8 Examples of various aspects of the transceiver 820 are described. The transmitter 520 can utilize a single antenna or an array of antennas.

[0091] Figure 6A block diagram 600 shows a device 605 supporting client booting based on trigger-based clients in a mesh network, according to various aspects of this disclosure. The device 605 may be an example of various aspects of device 505 or STA 115 as described herein. The device 605 may include a receiver 610, a network manager 615, and a transmitter 640. The device 605 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses).

[0092] The receiver 610 can receive information such as packets, user data, or control information associated with various information channels (e.g., control channels, data channels, and information related to client booting in a mesh network based on trigger-based clients). The information can be passed to other components of the device 605. The receiver 610 can be a reference. Figure 8 Examples of various aspects of the transceiver 820 described. The receiver 610 may utilize a single antenna or an array of antennas.

[0093] The network manager 615 may be an example of aspects of the network manager 515 as described herein. The network manager 615 may include a range manager 620, a report manager 625, a measurement manager 630, and a boot manager 635. The network manager 615 may be an example of aspects of the network manager 810 as described herein.

[0094] The range manager 620 can determine which client devices within the range of the serving device are eligible for bootstrapping, wherein the client device is outside the set of one or more triggering client devices. Based on this determination, the report manager 625 can request a radio resource management report from at least one triggering client device in the set of one or more triggering client devices.

[0095] The measurement manager 630 can receive radio resource management reports from at least one triggering client device in a set of one or more triggering client devices. The boot manager 635 can perform a boot operation from the service device to the target device based on the radio resource management report obtained from the at least one triggering client device.

[0096] The transmitter 640 can transmit signals generated by other components of the device 605. In some examples, the transmitter 640 can be co-located with the receiver 610 in a transceiver module. For example, the transmitter 640 can be a reference... Figure 8 Examples of various aspects of the transceiver 820 are described. The transmitter 640 can utilize a single antenna or an array of antennas.

[0097] Figure 7A block diagram 700 shows a network manager 705 supporting client booting based on trigger-based clients in a mesh network, according to various aspects of this disclosure. The network manager 705 may be an example of aspects of the network manager 515, network manager 615, or network manager 810 described herein. The network manager 705 may include a range manager 710, a reporting manager 715, a measurement manager 720, a boot manager 725, a control manager 730, a protocol manager 735, a signal manager 740, a monitoring manager 745, and a data manager 750. Each of these modules can communicate with each other directly or indirectly (e.g., via one or more buses).

[0098] The range manager 710 can determine which client devices within the range of the serving device are eligible for bootstrapping, wherein the client device is outside the set of one or more triggering client devices. The report manager 715 can, based on this determination, request a radio resource management report to at least one triggering client device in the set of one or more triggering client devices. In some cases, the serving device is a serving access point, and the target device is a target access point. In some cases, the radio protocol includes the 802.11k radio protocol. In some cases, at least one aspect of the radio resource management report is based on the 802.11k radio protocol.

[0099] The measurement manager 720 can receive radio resource management reports from at least one triggering client device in a set of one or more triggering client devices. The boot manager 725 can perform a boot operation from the service device to the target device based on the radio resource management report obtained from the at least one triggering client device.

[0100] The control manager 730 can compare the received channel power indicator of the serving device indicated in the radio resource management report with the received channel power indicator of the target device indicated in the same report. In some examples, the control manager 730 can determine that the received channel power indicator of the target device exceeds that of the serving device.

[0101] The protocol manager 735 can determine whether a client device conforms to a wireless protocol. In some examples, the protocol manager 735 can request a second radio resource management report from the client device based on the determination that the client device conforms to the wireless protocol.

[0102] In some examples, the protocol manager 735 can receive radio resource management reports from the client device. In some examples, the protocol manager 735 can redirect the client device from the service device's network to the target device's network based on the radio resource management reports received from the client device.

[0103] In some examples, the protocol manager 735 can assign a higher boot priority to a client device than to one or more other client devices in the serving device's network, based on receiving a radio resource management report from the client device. In some examples, the protocol manager 735 can determine that a requested radio resource management report has not been received from the client device.

[0104] In some examples, the protocol manager 735 can estimate the channel power indicator received by the client device based on the channel power indicator received by the serving device or the channel power indicator received by the target device, or both, as indicated in the radio resource management report of the at least one triggered client device. The signal manager 740 can determine that the signal strength indicator received by the client device meets a signal strength threshold.

[0105] The monitoring manager 745 can determine that a second client device is not eligible for booting. In some examples, the monitoring manager 745 can monitor the boot eligibility of a second client device. In some examples, the monitoring manager 745 can identify a triggering client device based on the monitoring results and user requests or historical boot success rates, or both.

[0106] The data manager 750 can traverse one or more parameters of the service device's network or one or more parameters of the target device's network, or both, through a decision tree model. In some examples, the data manager 750 can identify triggering client devices of the service device's network or the target device's network based on the output of the decision tree model.

[0107] Figure 8 A diagram of a system 800 according to various aspects of this disclosure is shown, the system including a device 805 supporting client booting based on trigger-based clients in a mesh network. The device 805 may be an example of a device 505, device 605, or device as described herein, or a component including device 505, device 605, or a device. The device 805 may include components for bidirectional voice and data communication, including components for transmitting and receiving communications, including a network manager 810, an I / O controller 815, a transceiver 820, an antenna 825, a memory 830, a processor 840, and a decoder manager 850. These components may communicate electronically via one or more buses (e.g., bus 845).

[0108] The network manager 810 can determine that a client device within the range of the serving device is eligible for booting, wherein the client device is outside the set of one or more triggering client devices; based on this determination, it requests a radio resource management report from at least one triggering client device in the set of one or more triggering client devices; receives the radio resource management report from at least one triggering client device in the set of one or more triggering client devices; and based on the radio resource management report from the at least one triggering client device, performs a booting operation of the client device from the serving device to the target device.

[0109] The I / O controller 815 manages the input and output signals of the device 805. The I / O controller 815 can also manage peripheral devices not integrated into the device 805. In some cases, the I / O controller 815 may represent a physical connection or port to an external peripheral device. In some cases, the I / O controller 815 may utilize an operating system such as iOS®, Android®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or another well-known operating system. In other cases, the I / O controller 815 may represent or interact with a modem, keyboard, mouse, touchscreen, or similar device. In some cases, the I / O controller 815 may be implemented as part of a processor. In some cases, a user may interact with the device 805 via the I / O controller 815 or via hardware components controlled by the I / O controller 815.

[0110] As described herein, the transceiver 820 can communicate bidirectionally via one or more antennas, wired links, or wireless links. For example, the transceiver 820 can represent a wireless transceiver and can communicate bidirectionally with another wireless transceiver. The transceiver 820 may also include a modem for modulating packets, providing modulated packets to the antennas for transmission, and demodulating packets received from the antennas.

[0111] In some cases, the wireless device may include a single antenna 825. However, in other cases, the device may have more than one antenna 825, which are capable of transmitting or receiving multiple wireless transmissions simultaneously.

[0112] The memory 830 may include RAM and ROM. The memory 830 may store computer-readable, computer-executable code 835, including instructions that, when executed, cause the processor to perform the various functions described herein. In some cases, the memory 830 may contain a BIOS, which controls basic hardware or software operations, such as interaction with peripheral components or devices.

[0113] The processor 840 may include intelligent hardware devices (e.g., general-purpose processors, DSPs, CPUs, microcontrollers, ASICs, FPGAs, programmable logic devices, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, the processor 840 may be configured to use a memory controller to operate a memory array. In other cases, the memory controller may be integrated into the processor 840. The processor 840 may be configured to execute computer-readable instructions stored in memory (e.g., memory 830) to cause the device 805 to perform various functions (e.g., supporting client-booting functions or tasks based on trigger-based clients in a mesh network).

[0114] The code 835 may include instructions for implementing various aspects of this disclosure, including instructions for supporting bootstrapping by a service device in a mesh network. The code 835 may be stored in a non-transitory computer-readable medium, such as system memory or other types of memory. In some cases, the code 835 may not be directly executed by the processor 840, but may instead enable a computer (e.g., at compile and execution time) to perform the functions described herein.

[0115] Figure 9 A flowchart is shown illustrating a method 900 for supporting trigger-based client bootstrapping in a mesh network, according to various aspects of this disclosure. Operation of method 900 can be implemented by a device or component thereof as described herein. For example, operation of method 900 can be performed by [reference to...] Figures 5 to 8 The network manager described herein is used to execute this. In some examples, the device may execute a set of instructions to control the functional elements of the device to perform the functions described herein. Additionally or alternatively, the device may use dedicated hardware to perform aspects of the functions described herein.

[0116] At point 905, the device can determine which client devices within the service device's scope are eligible for bootstrapping, wherein the client device is outside a set of one or more triggering client devices. Operation of point 905 can be performed according to the methods described herein. In some examples, aspects of operation of point 905 can be derived from, as referenced... Figures 5 to 8 The scope manager described is used to execute.

[0117] At point 910, the device can, based on this determination, request a radio resource management report from at least one of a set of one or more triggered client devices. The operation of point 910 can be performed according to the methods described herein. In some examples, aspects of the operation of point 910 can be derived from, as referenced... Figures 5 to 8 The report manager described is used to perform this.

[0118] At point 915, the device can receive radio resource management reports from at least one triggering client device from a set of one or more triggering client devices. Operation of point 915 can be performed according to the methods described herein. In some examples, aspects of operation of point 915 can be derived from, as referenced... Figures 5 to 8 The described measurement manager is used to perform this.

[0119] At point 920, the device can perform a bootstrapping operation from the serving device to the target device based on a radio resource management report obtained from the at least one triggered client device. The operation of point 920 can be performed according to the methods described herein. In some examples, aspects of the operation of point 920 can be derived from, as referenced... Figures 5 to 8 The boot manager described is used for execution.

[0120] Figure 10 A flowchart is shown of a method 1000 for supporting client bootstrapping based on trigger-based clients in a mesh network, according to various aspects of this disclosure. Operation of method 1000 can be implemented by a device or component thereof as described herein. For example, operation of method 1000 can be implemented by, as referred to... Figures 5 to 8 The network manager described herein is used to execute this. In some examples, the device may execute a set of instructions to control the functional elements of the device to perform the functions described herein. Additionally or alternatively, the device may use dedicated hardware to perform aspects of the functions described herein.

[0121] At point 1005, the device can determine which client devices within the service device's scope are eligible for bootstrapping, wherein the client device is outside the set of one or more triggering client devices. The operation of point 1005 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1005 can be derived from, as referenced... Figures 5 to 8 The scope manager described is used to execute.

[0122] At point 1010, the device can, based on this determination, request a radio resource management report from at least one of a set of one or more triggered client devices. The operation of point 1010 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1010 can be derived from, as referenced... Figures 5 to 8 The report manager described is used to perform this.

[0123] At point 1015, the device can receive radio resource management reports from at least one triggering client device from a set of one or more triggering client devices. The operation of point 1015 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1015 can be derived from, as referenced... Figures 5 to 8 The described measurement manager is used to perform this.

[0124] At point 1020, the device can compare the received channel power indicator of the serving device indicated in the radio resource management report with the received channel power indicator of the target device indicated in the same report. The operation of point 1020 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1020 can be derived from, as referenced... Figures 5 to 8 The control manager described is used to execute this.

[0125] At point 1025, the device can determine that the channel power indicator received by the target device exceeds the channel power indicator received by the serving device. The operation of point 1025 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1025 can be derived from, as referenced... Figures 5 to 8 The control manager described is used to execute this.

[0126] At 1030, the device can perform a bootstrapping operation from the serving device to the target device based on a radio resource management report obtained from the at least one triggered client device. The operation of 1030 can be performed according to the methods described herein. In some examples, aspects of the operation of 1030 can be derived from, as referenced... Figures 5 to 8 The boot manager described is used for execution.

[0127] Figure 11 A flowchart is shown of a method 1100 for supporting client bootstrapping based on trigger-based clients in a mesh network, according to various aspects of this disclosure. Operation of method 1100 can be implemented by a device or component thereof as described herein. For example, operation of method 1100 can be performed by, as described in reference... Figures 5 to 8 The network manager described herein is used to execute this. In some examples, the device may execute a set of instructions to control the functional elements of the device to perform the functions described herein. Additionally or alternatively, the device may use dedicated hardware to perform aspects of the functions described herein.

[0128] At 1105, the device can determine which client devices within the service device's scope are eligible for bootstrapping, wherein the client device is outside the set of one or more triggering client devices. The operation of 1105 can be performed according to the methods described herein. In some examples, aspects of the operation of 1105 can be derived from, as referenced... Figures 5 to 8 The scope manager described is used to execute.

[0129] At point 1110, the device can, based on this determination, request a radio resource management report from at least one of a set of one or more triggered client devices. The operation of point 1110 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1110 can be derived from, as referenced... Figures 5 to 8 The report manager described is used to perform this.

[0130] At 1115, the device can receive radio resource management reports from at least one triggering client device from a set of one or more triggering client devices. The operation of 1115 can be performed according to the methods described herein. In some examples, aspects of the operation of 1115 can be derived from, as referenced... Figures 5 to 8 The described measurement manager is used to perform this.

[0131] At 1120, the device can determine that the client device conforms to the wireless protocol. The operation of 1120 can be performed according to the methods described herein. In some examples, aspects of the operation of 1120 can be determined by reference to [reference needed]. Figures 5 to 8 The described protocol manager is used for execution.

[0132] At point 1125, the device can request a second radio resource management report from the client device based on the determination that the client device conforms to the radio protocol. The operation of point 1125 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1125 can be derived from, as referenced... Figures 5 to 8 The described protocol manager is used for execution.

[0133] At point 1130, the device can receive radio resource management reports from the client device. The operation of point 1130 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1130 can be derived from, as referenced... Figures 5 to 8 The described protocol manager is used for execution.

[0134] At point 1135, the device can redirect the client device from the service device's network to the target device's network based on a radio resource management report obtained from the client device. The operation of point 1135 can be performed according to the methods described herein. In some examples, aspects of the operation of point 1135 can be derived from, as referenced... Figures 5 to 8 The described protocol manager is used for execution.

[0135] It should be noted that the methods described herein describe possible implementations, and the operations and steps can be rearranged or otherwise modified, and other implementations are possible. Furthermore, aspects from two or more methods can be combined.

[0136] The techniques described in this article can be used in various wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), and other systems. The terms "system" and "network" are often used interchangeably. Code Division Multiple Access (CDMA) systems can implement radio technologies such as CDMA2000, Universal Terrestrial Radio Access (UTRA), etc. CDMA2000 encompasses the IS-2000, IS-95, and IS-856 standards. IS-2000 Releases are often referred to as CDMA2000 1X, 1X, etc. IS-856 (TIA-856) is often referred to as CDMA2000 1xEV-DO, High Rate Packet Data (HRPD), etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. Time Division Multiple Access (TDMA) systems can implement radio technologies such as Global System for Mobile Communications (GSM). Orthogonal Frequency Division Multiple Access (OFDMA) systems can implement radio technologies such as Ultra Mobile Broadband (UMB), Evolved UTRA (E-UTRA), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, and Flash-OFDM.

[0137] The wireless communication systems or multiple wireless communication systems described herein can support synchronous or asynchronous operation. For synchronous operation, stations can have similar frame timing, and transmissions from different stations can be approximately aligned in time. For asynchronous operation, stations can have different frame timing, and transmissions from different stations can be misaligned in time. The techniques described herein can be used for both synchronous and asynchronous operation.

[0138] The downlink transmission described in this article can also be referred to as forward link transmission, while the uplink transmission can also be referred to as reverse link transmission. Each communication link described in this article—including, for example, WLAN 100 and... Figure 1 and 2 The environment 200 may include one or more carriers, where each carrier may be a signal composed of multiple subcarriers (e.g., waveform signals of different frequencies).

[0139] The specification described herein, taken in conjunction with the accompanying drawings, describes exemplary configurations and does not represent all examples that can be implemented or that are within the scope of the claims. As used herein, the term "exemplary" means "serving as an example, instance, or illustration," and not "preferred" or "superior to other examples." To provide an understanding of the described techniques, the detailed specification includes specific details. However, these techniques can be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described examples.

[0140] In the accompanying drawings, similar components or features may have the same reference numerals. Furthermore, various components of the same type can be distinguished by adding a dash after the reference numeral and a second numeral for differentiation among other similar components. If only the first reference numerals are used in the specification, the description applies to any similar components having the same first reference numerals, regardless of the second reference numerals.

[0141] The information and signals described herein can be represented using any of a variety of different technologies and processes. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout this specification can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0142] The various illustrative blocks and modules described herein can be implemented or executed using a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration).

[0143] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, these functions can be stored on or transmitted via a computer-readable medium as one or more instructions or code. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described herein can be implemented using software executed by a processor, hardware, firmware, hardwiring, or any combination thereof. Features implementing the functions can also be physically located in various locations, including distributed such that portions of the functions are implemented at different physical locations. Furthermore, as used herein, including in claims, the word "or" as used in a list of items (e.g., a list of items beginning with phrases such as "at least one" or "one or more of") indicates a list of inclusion, such that, for example, a list of "at least one of A, B, or C" means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Moreover, as used herein, the phrase "based on" should not be construed as a reference to a closed set of conditions. For example, an exemplary step described as "based on condition A" can be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used in this article, the phrase “based on” should be interpreted in the same way as the phrase “at least partially based on”.

[0144] Computer-readable media includes non-transitory computer storage media and communication media, with communication media including any media that facilitates the transfer of a computer program from one place to another. Non-transitory storage media can be any available medium accessible by a general-purpose or special-purpose computer. By way of example, and not limitation, non-transitory computer-readable media can include RAM, ROM, electrically erasable programmable read-only memory (EEPROM), optical disc (CD) ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store required program code in the form of instructions or data structures and is accessible by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. Furthermore, any connection is appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the definition of media includes coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave. The disks and optical discs used in this article include CDs, laser discs, optical discs, digital multifunction discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of these are also included within the scope of computer-readable media.

[0145] The description provided herein is intended to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but is given the broadest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for guiding operations in a mesh network by a service device, the method comprising: Determine which client devices within the scope of the service device are eligible for booting, wherein the client devices are outside a set of one or more trigger-based client devices; Based at least in part on the determination that the client device is a non-responsive client device, a radio resource management report is requested from at least one of the set of one or more triggering client devices, wherein the non-responsive client device does not comply with the radio protocol or does not respond to the request for the radio resource management report, or both; each of the one or more triggering client devices complies with the radio protocol and responds to the request based on the radio protocol; Receive the radio resource management report from at least one of the one or more triggering client devices in the set of triggering client devices; as well as The client device performs a bootstrapping operation from the service device to the target device based at least in part on the radio resource management report from the at least one triggering client device, wherein the channel power indicator received by the target device indicated in the radio resource management report exceeds the channel power indicator received by the service device.

2. The method according to claim 1, comprising: Based at least in part on the determination and the fact that the client device complies with the wireless protocol, a second radio resource management report is requested from the client device.

3. The method according to claim 2, comprising: Receive the second radio resource management report from the client device; as well as The client device is directed from the service device's network to the target device's network, at least in part, based on a second radio resource management report from the client device.

4. The method according to claim 3, comprising: At least in part, based on receiving the second radio resource management report from the client device, the client device is assigned a higher boot priority than one or more other client devices in the network of the serving device.

5. The method according to claim 2, comprising: It was determined that the requested second radio resource management report was not received from the client device; as well as The channel power indicator received by the client device is estimated at least in part based on the channel power indicator received by the serving device or the channel power indicator received by the target device, or both, as indicated in the radio resource management report of the at least one triggering client device.

6. The method according to claim 2, wherein, The wireless protocol includes the 802.11k wireless protocol.

7. The method according to claim 6, wherein, At least one aspect of the radio resource management report, at least one aspect of the second radio resource management report, or both, are at least partially based on the 802.11k radio protocol.

8. The method according to claim 1, wherein, Determining that the client device is eligible for booting includes: Determine that the signal strength indicator received by the client device meets the signal strength threshold.

9. The method according to claim 1, comprising: It was determined that the second client device was not qualified for booting; Monitor the boot eligibility of the second client device; as well as Triggered client devices are identified at least in part based on the monitoring results and user request or historical boot success rates, or both.

10. The method according to claim 1, comprising: One or more parameters of the network of the service device or one or more parameters of the network of the target device, or both, are passed through a decision tree model; and Triggered client devices of the network of the service device or the network of the target device are identified at least in part based on the output of the decision tree model.

11. The method according to claim 1, wherein, The service device is a service access point, and the target device is a target access point.

12. An apparatus for guiding operations in a mesh network by a service device, the apparatus comprising: At least one memory including instructions; and At least one processor, the at least one processor being configured to execute the instructions to cause the device to: Determine which client devices within the scope of the service device are eligible for booting, wherein the client devices are outside a set of one or more trigger-based client devices; Based at least in part on the determination that the client device is a non-responsive client device, a radio resource management report is requested from at least one of the set of one or more triggering client devices, wherein the non-responsive client device does not comply with the radio protocol or does not respond to the request for the radio resource management report, or both; each of the one or more triggering client devices complies with the radio protocol and responds to the request based on the radio protocol; Receive the radio resource management report from at least one of the one or more triggering client devices in the set of triggering client devices; as well as The client device performs a bootstrapping operation from the service device to the target device based at least in part on the radio resource management report from the at least one triggering client device, wherein the channel power indicator received by the target device indicated in the radio resource management report exceeds the channel power indicator received by the service device.

13. The apparatus according to claim 12, wherein, The at least one processor is further configured to execute the instructions to cause the device to: Based at least in part on the determination and the fact that the client device complies with the wireless protocol, a second radio resource management report is requested from the client device.

14. The apparatus according to claim 13, wherein, The at least one processor is further configured to execute the instructions to cause the device to: Receive the second radio resource management report from the client device; as well as The client device is directed from the service device's network to the target device's network, at least in part, based on a second radio resource management report from the client device.

15. The apparatus according to claim 14, wherein, The at least one processor is further configured to execute the instructions to cause the device to: At least in part, based on receiving the second radio resource management report from the client device, the client device is assigned a higher boot priority than one or more other client devices in the network of the serving device.

16. The apparatus according to claim 13, wherein, The at least one processor is further configured to execute the instructions to cause the device to: It was determined that the requested second radio resource management report was not received from the client device; as well as The channel power indicator received by the client device is estimated at least in part based on the channel power indicator received by the serving device or the channel power indicator received by the target device, or both, as indicated in the radio resource management report of the at least one triggering client device.

17. The apparatus according to claim 13, wherein, The wireless protocol includes the 802.11k wireless protocol.

18. An apparatus for guiding operations in a mesh network by a service device, the apparatus comprising: Components for determining which client devices within the scope of the service device are eligible for booting, wherein the client devices are outside a set of one or more trigger-based client devices; Components for requesting a radio resource management report from at least one of the set of one or more triggering client devices, based at least in part on the determination that the client device is a non-responsive client device, wherein the non-responsive client device does not comply with the radio protocol or does not respond to the request for a radio resource management report, or both; each of the one or more triggering client devices complies with the radio protocol and responds to the request based on the radio protocol; Components for receiving the radio resource management report from at least one of the one or more triggering client devices in the set of triggering client devices; as well as Components for performing a bootstrapping operation from the service device to a target device by the client device based at least in part on the radio resource management report from the at least one triggered client device, wherein the channel power indicator received by the target device exceeds the channel power indicator received by the service device.

19. A computer-readable medium having code recorded thereon, wherein the code is executable by a processor to cause the processor to perform the method of any one of claims 1-11.

Images