Patent Application
20250150935
Generally described, computing devices or electronic devices can be configured for wireless connectivity, such as the ability to host or connect to a wireless network. While hosting a wireless network, such devices may be referred to as wireless access points (APs) or hotspots. Examples of such electronic devices include, but are not limited to, mobile phones, tablets, base stations, network access points, customer-premises equipment (CPE), notebook or desktop computers, cameras, and wearable electronics.
A host electronic device acting as a wireless access point (AP), also referred to as a hotspot device, can suffer poor network performance when a large number of client electronic devices are connected to the host simultaneously, particularly devices with poor network connectivity. Examples of client devices with poor network connectivity can include devices which are distant from the host, devices with an obstructed view of the host (e.g., walls, furniture, people, or other obstructions present between the host device and client device), and devices in a noisy (i.e., congested) radio frequency (RF) environment. Scenarios resulting in poor network performance are particularly common in settings with a large number of client devices and congested RF channels, like a school or office.
Examples described herein provide a method of modifying a wireless network topology to improve network performance. The host device can identify a client device with poor network connectivity based on several indications of connection quality. The host can determine a wireless signal strength, a peer-to-peer (P2P) packet drop rate, and/or a P2P ping response time for each client device to identify a target unit with the poorest network performance among the plurality of client devices. (The target unit is targeted for offloading by the host to relieve network load caused by latency, dropped packets, or other effects of a weak connection.) The host device can instruct the target unit to enable a software-enabled access point (SoftAP) which enables the target unit to become a wireless access point of the network, and for each one of the remaining client devices scan the SoftAP and transmit results to the host for the host to identify a candidate client device to serve as a new host device (i.e., sub-host) for the target unit. The candidate client device can then receive instructions from the host device to enable its own SoftAP and to relay communication to the host device from the target unit via the wireless connection, thereby reducing the number of client devices connected directly to the host device and improving network performance for the client devices, including the target unit.
While a Wireless Access Point (WAP) is specifically made only to work as an Access Point, SoftAP is used to make a wireless client antenna work as either the Access Point, or the client. The advantage of SoftAP is the use of a regular electronic device, for example, with a client antenna and data connection as an Access Point to serve other wireless devices that do not have a data connection otherwise. The wireless devices in the vicinity of the SoftAP-enabled device, which may not have the Internet access directly, can use the Internet through the device whose SoftAP is enabled. This is called tethering.
Referring initially to
The wireless module 130 acts as a network interface to enable wireless network access (e.g., WLAN or WWAN connectivity) for the electronic device. In general, the wireless module 130 comprises at least a transmitter 130a, a receiver 130b, and an antenna 130d, although various implementations are possible. (For example, the transmitter 130a and the receiver 130b may be combined into a transceiver having both TX and RX capabilities.) The wireless module 130 may include additional transmitters, receivers, transceivers, antennas, and/or filters or signal conditioning stages to enable techniques such as spread spectrum or multiple input, multiple output (MIMO) communications. The wireless module can support various wireless technologies including Wi-Fi, Bluetooth, long-term evolution (LTE), 5G New Radio (5G NR), or any other wireless technology known to those skilled in the art.
It will be appreciated that the capability of the wireless module 130 to transmit and receive enables the electronic device 100 to host a wireless network as well as to connect to one. As will be discussed herein, when certain instructions stored in the non-volatile memory 150 are executed by the processor 140, the processor 140 can cause the wireless module 130 to enable a software-enabled access point (SoftAP) functionality for hosting a wireless network. Subsequently, additional electronic devices (not necessarily the same kind of device as the electronic device 100) can connect to the SoftAP-based wireless network to share a network connection. In this scenario, the electronic device 100 may be referred to as a host device and the additional electronic devices may each be referred to as a client device.
An example of a wireless network 200 formed by a host device 100a and a plurality of client devices 100b, 100c, and 100d is schematically illustrated by
While the star network topology can be effective for several client devices to obtain network access, the network 200 places a large load on the host device 100a and can become slow and increasingly unstable as more client devices are added. In particular, overall network performance may suffer when the connection between the host device 100a and one of the client devices 100b-d is compromised by long distances, obstructions, RF interference, or other factors. A poorly connected client can have a weak signal strength, increased latency, and a high rate of dropped data packets, requiring additional network resources from the host device 100a which negatively affects network performance for each one of the client devices 110b-d. Accordingly, a method of modifying the network topology can be used to improve network performance when the host device 100a detects one of the client devices 100b-d with poor connectivity.
Those skilled in the art will appreciate that the network 300 has fewer direct connections to the host device 100a as compared to the star network 200 of the previous example while retaining the same total number of client devices 100b-d. This can improve overall network performance and connectivity between devices by updating the network topology based on a connectivity quality of each client device. In the example of
Referring now to
At block 405, the host device 100a establishes an initial network (e.g., the star network 200) as client devices 100b-d connect to the host. The host device 100a operates as a first SoftAP to communicate with the client devices 100b-d. Establishing the network can occur over an extended period of time as additional client devices are added or dropped from the initial network. The host device 100a can monitor several indications of connectivity quality and overall network performance to determine when to proceed with modifying the network topology. For example, the host device 100a can monitor a received signal strength indicator (RSSI), a peer-to-peer ping response time (i.e. a time-of-flight delay), and/or a peer-to-peer packet drop rate of each client device 100b-d to determine when modifying the network topology is necessary (e.g., when a client device has a network performance score below a threshold or otherwise qualify as target units). In other examples, the host device 100a can trigger modifying the network topology when it detects a rapid increase in the number of client devices, or when the number of client devices exceeds a threshold likely to impact the network performance.
At block 410, the host device 100a transmits a request to each one of the client devices 100b-d indicating its intent to offload hosting to a sub-host 320. Because only certain client devices of the plurality of client devices 100b-d may be compatible with the offloading, the host device 100a may identify a pool of eligible client devices (e.g., by MAC address, manufacturer code, serial number, or other means) to which the host will transmit the request. In other cases, the host device 100a can transmit the request for offloading to each one of the connected client devices 100b-d.
At block 415, each one of the eligible client devices (e.g., the plurality of client devices 100b-d) determines if permission is granted by a respective user of the device to participate in the offloading. The client devices 100b-d can, for example, prompt the user via a graphical user interface to accept or decline the request by the host device 100a. The prompt may include information about current network performance or network connectivity quality for that device. Alternatively, each client device 100b-d may refer to a preconfigured flag stored in the non-volatile memory 150 to determine if user permission is granted. The client devices 100b-d may be preconfigured to accept requests for offloading unless the user has changed the flag to automatically decline, or if offloading is disabled by administrative group policy. In some cases, the user may also be warned of poor network connectivity before attempting intensive operations such as transferring large files. Each one of the eligible client devices reports feedback to the host device 100a based on the user permission.
At block 420, the host device 100a receives the feedback from each one of the eligible client devices 100b-d to identify a pool of approved client devices for hosting offloading.
At block 425, the host device 100a evaluates network performance for each one of the approved client devices based on two or more of the aforementioned indications of connectivity quality. Evaluating network performance may be performed passively by the host device 100a (e.g., monitoring a received signal strength of each client device), or the host may also transmit an instruction to each of the approved client devices to participate in a network test (e.g., measuring a ping response time from the client device).
At block 430, the host device 100a can identify one of the approved client devices with the poorest network performance as the target unit 310 based on the results of the previous step. The host device 100a can calculate a weighted connectivity score based on each one of the indications of connectivity quality to identify the target unit 310. For example, the weighted connectivity score can be calculated from normalized results of the received signal strength (weighted 40%), the ping response time (weighted 30%), and the packet drop rate (weighted 30%) for each client device. In other examples, each one of the two or more indications of connectivity quality may be weighted equally to calculate the connectivity score. In yet other examples, other combinations of percentages or weights may be used to determine whether a client device qualifies as a target unit and/or to rank the client devices. The host device 100a may form an ordered list of the approved client devices based on their weighted connectivity scores, with the target unit 310 being identified as the client device with the lowest connectivity score. In some examples, a specific number (e.g., 1, 2, or more) or percentage (5%, 10%, or some other percentage) of worst performing client device(s) may be identified as the target unit 310 (for being connected to a new host).
At block 435, the host device 100a transmits a request to the target unit 310 to perform a channel scan.
At block 440, the target unit 310 performs a channel scan to identify, among a plurality of RF channels or bands, an RF channel or band having the least amount of congestion for communicating with the host device 100a. The channel scan may be performed passively or in cooperation with the host device 100a. For example, when the wireless network is a Wi-Fi network, the target unit 310 can monitor ambient RF noise levels in Wi-Fi channels 1-14 to identify a preferred channel having the least amount of RF noise and network traffic. In some cases, the host device 100a can also transmit a test signal to the target unit 310 over two or more RF channels or bands to assist in identifying the preferred channel. Upon identifying the preferred channel, the target unit 310 transmits the result to the host device 100a for future use.
At block 445, the host device 100a transmits a request to the target unit 310 to temporarily enable a second SoftAP. The target unit 310 subsequently enables SoftAP functionality of its wireless module 130 to allow other client devices to sense the wireless signal from the second SoftAP.
At block 450, the host device 100a transmits a request to each one of the approved client devices (aside from the target unit 310) instructing the approved client devices to scan the second SoftAP. The request can include information such as a MAC address or SSID of the second SoftAP, and the preferred channel of the target unit 310.
At block 455, each one of the approved client devices performs the scan, evaluates its own network performance with respect to the second SoftAP of the target unit 310, and transmits the scan result (an indication of connection quality) to the host device 100a. For example, the scan result may indicate the connection strengths of the approved client devices relative to the target unit 310. While the client devices passively monitor the second SoftAP, they remain connected to the first SoftAP of the host device 100a. In some cases, the wireless modules 130 of the client devices can be connected to the first SoftAP and the second SoftAP simultaneously. Evaluating network performance may be performed passively by the client devices (e.g., monitoring a received signal strength of the second SoftAP), or the host device 100a may transmit an instruction to the target unit 310 to participate in a network test (e.g., measuring a ping from the second SoftAP by each one of the approved client devices).
At block 460, the host device 100a identifies a candidate sub-host device 320 from the client devices having the best network performance with respect to the target unit 310. Upon receiving the indications of connectivity quality from each of the approved client devices, the host device 100a will generate an ordered list of candidate devices including a second weighted connectivity score for each one of the approved client devices. Once the list of candidate devices is obtained, the host device 100a can instruct the target unit 310 to disable the second SoftAP.
The sub-host device 320 can be selected from the list of candidate devices as the device having the highest second weighted connectivity score, indicating the strongest connection between the sub-host and the target unit 310. However, the host device 100a can also refer to the entire list of candidate devices in the event that the device having the highest second weighted connectivity score is not available as a sub-host 320.
At block 465, the host device 100a transmits a request to the device having the highest second weighted connectivity score to offload the network connection for the target unit 310 (i.e., a request to become a sub-host 320).
At block 470, the device having the highest second weighted connectivity score determines if permission is granted by the device user to participate in the offloading. The device can prompt the user via a graphical user interface to accept or decline the request by the host device 100a. The prompt may include information about current network performance or network connectivity quality for that device and/or information about the target unit 310. Alternatively, the device may refer to a second preconfigured flag stored in the non-volatile memory 150, or an administrative group policy to determine if permission is granted. If the user declines to participate in the offloading, the method 400 returns to block 460 and the next best candidate device is selected from the list of candidate devices as the new sub-host device 320.
Once a sub-host device 320 is selected and approved, at block 475 the sub-host device 320 enables a third SoftAP to enable the target unit 310 to connect. The host device 100a transmits a request to the target unit 310 to disconnect from the first SoftAP and to connect to the third SoftAP of the sub-host device 320. The sub-host device 320 is configured to provide access to the network for the target unit 310 such that a communication between the target unit 310 and the network of the host device 100a is routed via the first SoftAP and the third SoftAP.
Accordingly,
The principles of the examples described herein can be used for any other system or apparatus including mobile phones, tablets, base stations, network access points, customer-premises equipment (CPE), laptops, cameras, and wearable electronics.
All of the methods and tasks described herein may be performed and fully automated by a computer system. The computer system may, in some cases, include multiple distinct computers or computing devices (e.g., laptops, physical servers, workstations, storage arrays, etc.) that communicate and interoperate over a network to perform the described functions. Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium or device (e.g., solid state storage devices, disk drives, etc.). The various functions disclosed herein may be embodied in such program instructions, or may be implemented in application-specific circuitry (e.g., ASICs or FPGAs) of the computer system. Where the computer system includes multiple computing devices, these devices may, but need not, be co-located. The results of the disclosed methods and tasks may be persistently stored by transforming physical storage devices, such as solid-state memory chips or magnetic disks, into a different state.
The processes described herein or illustrated in the figures of the present disclosure may begin in response to an event, such as on a predetermined or dynamically determined schedule, on demand when initiated by a user or system administrator, or in response to some other event. When such processes are initiated, a set of executable program instructions stored on one or more non-transitory computer-readable media (e.g., hard drive, flash memory, removable media, etc.) may be loaded into memory (e.g., RAM) of a server or other computing device. The executable instructions may then be executed by a hardware-based computer processor of the computing device. In some embodiments, such processes or portions thereof may be implemented on multiple computing devices and/or multiple processors, serially or in parallel.
Depending on the embodiment, certain acts, events, or functions of any of the processes or algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described operations or events are necessary for the practice of the algorithm). Moreover, in certain embodiments, operations or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.
The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device.
Conditional language used herein, such as, among others, “can,” “could,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements or steps. Thus, such conditional language is not generally intended to imply that features, elements or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without other input or prompting, whether these features, elements or steps are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.
Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present.
Any process descriptions, elements or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.
Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B, and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.
While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As can be recognized, certain embodiments described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
