Patent Application
20140269463
This disclosure generally relates to communication systems, and more particularly, to intelligent beaconing in wireless communication systems.
Currently, most user devices (e.g., mobile devices such as smart phones, tablets, cellular phones, laptops, etc.) support searching for and connecting to wireless communication systems such as Wi-Fi networks via hotspots, i.e., Wi-Fi network access points or areas. A Wi-Fi network access point, in general, may work as an Access Point (AP) for network connections.
In contrast, a set of user devices may establish an ad-hoc wireless network where a user device having a Software-enabled Access Point (SoftAP) may be used to provide a wireless client antenna that may act as both an Access Point and a client in the ad-hoc network. That is, SoftAP may act as “virtual” Wi-Fi such that software in a user device may enable the user device to create a hotspot or portable hotspot that other user devices in the vicinity may be able to use.
As such, SoftAP may enable a user device, for example, one having a wireless client antenna and network connection, as an Access Point (AP) to serve other user devices that may not otherwise have a network connection. When user devices, which may not have network (e.g., Internet) access directly, are in the vicinity or neighborhood of a SoftAP user device, those neighboring user devices may connect to a network through the user device having SoftAP functionality. It should be noted that in this disclosure, a SoftAP user device may be referred to as a Service Access Point or “SoftAP”. Also, a user device that may connect to a network through a SoftAP may be referred to as a station (STA).
SoftAP user devices generally have capabilities to use the IEEE defined 802.11 groups of protocols (e.g., 802.11a, b, c, g, n, ac, etc.), and may be any fixed, mobile, or portable user device (e.g., smart phones, tablets, cellular phones, laptops, etc.).
Most use cases of SoftAP are generally limited to a small number of stations (STAs), for example, one or two STAs. One particular aspect in which SoftAP differs from a commercial AP is that for SoftAP, there may not be a need to repeat beaconing continuously to advertise its capabilities. For a commercial access point (AP), for example, in a corporate network or a shopping mall, any user device can try to connect to a network via the commercial AP. As such, the commercial AP generally may need to continue beaconing even if there are no STAs connected.
Because user devices may be the source of a Wi-Fi hotspot, it is commonly desirable that power consumption be minimized as much as possible (especially in mobile devices, for example). However, IEEE standards may not specify power save processes for user devices working in AP mode. As such, in cases where a user device is acting as a hotspot or a SoftAP, the user device may not go into power save mode, which may result in quicker draining of the battery.
According to one or more embodiments of the present disclosure, systems and methods are provided for reducing power consumption of a SoftAP enabled user device in a wireless communications system.
According to an embodiment, a method comprises transmitting a first beacon from the SoftAP to a station connected to the SoftAP. The method also comprises determining a beacon interval between the first beacon and a second beacon. The method further comprises dynamically changing the beacon interval. And the method also comprises transmitting the second beacon upon the changed beacon interval passing since the transmitting of the first beacon.
Like element numbers in different figures represent the same or similar elements.
Systems and methods for intelligent beaconing by a SoftAP user device that results in power savings are provided according to one or more embodiments of the present disclosure. In embodiments herein, an intelligent connection-based beaconing that helps to reduce power consumption on SoftAP is provided such that unnecessary transmission of beacons may be avoided. For example, in cases where a user device turns on SoftAP and, for instance, the user device gets disconnected after some time or the user forgets to turn off the hotspot or SoftAP feature, the beaconing may be stopped, and the beaconing may be started dynamically based on a connection. Thus, the user device avoids continuing to beacon, saving the battery of the user device.
In a current example, beacons may be transmitted at a basic rate of 1 Mbps, which may use baseband modulations of differential binary phase shift keying (DBPSK). Therefore, reducing the number of beacons transmitted may save significant battery power for user devices, e.g., mobile devices.
According to one or more embodiments, transmission of beacons by a SoftAP may be dynamically enabled or disabled so that power consumption is reduced. For example,
Referring to
In block 102, when SoftAP features of a user device are enabled, the user device is prepared or ready for transmitting beacons or for probing responses for a directed probe request (in some embodiments, the user device may not transmit beacons at this point).
In block 104, an identifier, such as a Service Set Identifier (SSID), is configured at the SoftAP. In block 106, if a user device or station (STA) wants to connect to the SoftAP, it may send a probe request that includes an identifier (e.g., a unicast SSID). In an example, an STA that wants to connect to the SoftAP or hotspot may have previously asked for (or it may already know) the SSID configured at the SoftAP. In one or more embodiments, the SoftAP may provide its SSID to known STAs with which it may want to connect.
In block 108, continuing with the example of a unicast SSID, the received unicast SSID included in the probe request is compared with the SSID configured at the SoftAP. In block 110, if the probe request with the unicast SSID does not match the SSID configured at the SoftAP, there is no action (e.g., there is no beacon transmission). In block 112, if the probe request with the unicast SSID matches the SSID configured at the SoftAP, then the SoftAP may enable beaconing, after responding with a probe response, because there is a user device interested in connecting via the SoftAP. In block 114, after the SoftAP starts beaconing based on the unicast SSID probe request, it may wait for the STA to connect. In an embodiment, the SoftAP may start a timer at this point to measure or keep track of the waiting time for the STA to connect. In an embodiment where the timer runs out, the SoftAP may stop beacon transmission.
In block 116, if the STA connects (in one embodiment, within a specified period of time, e.g., within 5 seconds as measured by the timer), the SoftAP may continue beaconing. In block 118, if no user device or STA connects to the SoftAP, the SoftAP may stop, pause or disable transmitting (e.g., stop beaconing after a specified trigger such as after a specified period of time). The SoftAP may resume beaconing after it receives another probe request with a unicast SSID that matches the SSID configured at the SoftAP.
In an embodiment, for an idle scenario, a processor of the user device acting as a SoftAP (e.g., a mobile application processor (APPS processor)) may go into a suspended state if there is no need to respond to every probe request. In some embodiments, a connectivity processor of the user device acting as the SoftAP may wake up the APPS processor only when it receives a probe request including an identifier that matches the identifier configured at the SoftAP.
In various embodiments, the beacons generated by the SoftAP may contain the hidden SSID. In this manner, the power consumption is reduced because there is no beacon transmission in idle scenarios.
Referring now to
Referring now to
In block 202, in a system (e.g., in a Basic Service Set (BSS)) where one or more STAs are connected to a SoftAP, data activity may be determined in the system, for example, there may be high data activity such that connections are active between the SoftAP and the STAs. There may be low or no significant data activity, for example, when no connections are made between the SoftAP and the STAs within a specified period of time such as 10 seconds. It should be appreciated that various techniques may be used to identify and measure data activity (or inactivity) associated with a communications system, for example, data activity may be based on beacon transmissions in the communications system. In some implementations, for example, a user device may monitor whether it has transmitted successive beacons for a defined period of time (for example, one and a half minutes). Also, in some implementations, a user device may monitor the amount of time that has passed or the number of beacon intervals that have occurred since the user device last received a beacon from another user device.
In block 204, if there is no significant data activity in the system, it is determined if the connected STAs support a feature wherein the SoftAP may dynamically change a beacon interval. In block 208, where connected STAs do not support the feature wherein a SoftAP can dynamically change the beacon interval, there is no action. In this case, for example, transmission of beacons may continue. In block 206, where connected STAs may support the feature wherein the SoftAP may dynamically change a beacon interval, the SoftAP may do so, that is, dynamically change a beacon interval based on data activity in the Basic Service Set (BSS), which includes the SoftAP and associated STAs. For example, SoftAP may dynamically increase the beacon interval when there is no significant data activity in the BSS. In one or more embodiments, the beacon intervals may be changed, e.g., increased, by various appropriate ways including, for example, by determining a beacon transmission time period, a step size that changes (e.g., increases) over time statically or dynamically, or by any other appropriate way. In one instance, if a beacon interval is normally 1 beacon per 100 ms, the beacon interval may be changed to 1 beacon per 200 ms or 300 ms if there is no significant data activity in the system. In another instance, a time period between beacons or a step of a beacon interval may increase gradually over time. A step may increase statically or it may increase dynamically over time. For example, a step may increase dynamically, e.g., a step may increase from 1 ms to 3 ms, to 4 ms, etc., or the step may increase statically over time such that a step increase is the same over time (e.g., a step may increase by 1 ms each time such as from 1 ms to 2 ms to 3 ms, etc.). A step may increase exponentially, arithmetically, or in any appropriate manner based on data activity in the system.
In block 209, the SoftAP may decide to increase the beacon interval and also notify STAs about future beacon intervals as well as a changed beacon interval. In various embodiments, an information element (i.e., an IE) may be added for use by SoftAP in the beacons to notify its client or associated STAs about a future beacon interval it is going to use, for example after 5 beacons. That is, when a beacon includes an IE, the transmitting beacon that includes the IE may indicate that the beacon interval will change, for example, after 2 beacons, and indicate that the beacon interval will change from 1 beacon per 100 ms to 1 beacon per 300 ms instead. The increment may be in integral multiples of the current beacon interval so that all client STAs may receive the beacons that are sent at new intervals. As such, client STAs may be able to adapt to the new beacon interval without having to start reconnection procedures.
Advantageously, some embodiments of the present disclosure increase security because, for example, the user device acting as SoftAP may not be a commercial enterprise or the like, so it is not required to allow connections to unknown STAs. As such, beaconing on demand may provide security in a way that allows connections only to STAs that know the identifier, e.g., the SSID, configured at the SoftAP.
Furthermore, power consumption is minimized to a large extent when the user device acting as SoftAP is idle with no STAs connected to it because a processor such as an APPS processor may go into power suspend in this mode. Power consumption may also be minimized when the user device acting as SoftAP is idle with STA's connected to it.
In various embodiments, where a SoftAP is enabled and this is the only AP at a location, an STA may not be able to connect to the SoftAP if the SoftAP is not beaconing. In this case, the SoftAP may do periodic scanning to find potential APs for STAs in the location. If there are APs in the location, the SoftAP may move to the intelligent beaconing as described above according to one or more embodiments. Otherwise, the SoftAP may fall back to a legacy beaconing.
Referring now to
A communications system 301 may generally include, for example, a wireless communications system such as an ad-hoc Wi-Fi network. System 301 may comprise a plurality of user devices 302, 316 and 318. In this embodiment, user device 302 may communicate with user devices 316 and 318 (also referred to as stations or “STAs”). It should be appreciated that system 301 may comprise any combination and/or number of user devices according to one or more embodiments.
User device 302 may comprise several components including for example, a SoftAP component 304, a mode controller 306, a system activity monitor 308, a communications system controller 310 and a transceiver 312. Although components 304-312 are only illustrated for user device 302, it should be noted that user devices 316 and 318 may include similar components.
SoftAP component 304 may include features for establishing an access point that may be activated to act as a “virtual” network connection such that software in the user device may enable the user device to create a hotspot or portable hotspot that other user devices, e.g., user devices 316 and 318, in the vicinity may be able to use. As such, SoftAP component 304 may enable user device 302 as an Access Point (AP) to serve user devices 316 and 318, which may not otherwise have a network connection.
Mode controller 306 may control a mode of operation of user device 302. For example, mode controller 306 may control whether one or more components of user device 302 operate in an active state (e.g., a fully operational mode), or a power save state (e.g. power savings mode). For example, user device 302 may operate in a power save state in idle scenarios where no STAs are connected to user device 302, or in idle scenarios where STAs are connected to it as described above according to one or more embodiments.
System Activity Monitor 308 may monitor activity associated with the communications system 301. In one or more embodiments herein, activity may relate to data or operations of user device 302 and/or operations of user devices 316 and 318. In an embodiment, data activity in communications system 301 may be monitored such that a determination may be made for changing a beacon interval as described above, for example, in connection with
Communications System Controller 310 may provide appropriate functionality for establishing communications with one or more user devices via a network such as communications system 301. For example, controller 310 may provide functionality relating to enabling or disabling transmission of beacons, receiving probe requests including an identifier that is compared with an identifier configured at the user device, notifying of beacon interval changes or future interval changes, etc.
Transceiver 312 may provide appropriate functionality for establishing communications with one or more user devices via an appropriate medium, for example, a wireless medium. Transceiver 312 may comprise one or more transmitters and one or more receivers for communicating in communications system 301 and or other types of systems or networks.
It will be appreciated that the methods and systems disclosed herein may be implemented by or incorporated into a wide variety of electronic systems or devices. For example, a smart phone, a cell phone, a laptop, a tablet PC, etc. may include SoftAP features in accordance with one or more embodiments of the present disclosure. Other exemplary electronic systems such as a music player, a video player, a communication device, or a personal computer may also be configured with SoftAP features in accordance with one or more embodiments of the present disclosure.
Referring now to
In this regard, a system 1500 may be used to implement any type of device including wired or wireless devices such as a mobile device, a smart phone, a Personal Digital Assistant (PDA), a tablet, a laptop, a personal computer, a TV, a network server, or the like.
System 1500 may be suitable for implementing embodiments of the present disclosure, such as a part of a user device, including, for example, user devices 302, 316 and 318 illustrated in
In accordance with embodiments of the present disclosure, system 1500 performs specific operations by processing component 1504 executing one or more sequences of one or more instructions contained in system memory component 1506. Such instructions may be read into system memory component 1506 from another computer readable medium, such as static storage component 1508. These may include instructions for intelligent transmission of beacons by a SoftAP as well as, for example, configuring identifiers associated with a SoftAP, changing of beacon intervals, notifying of changed beacon intervals, etc. In other embodiments, hard-wired circuitry may be used in place of or in combination with software instructions for implementation of one or more embodiments of the disclosure.
Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processing component 1504 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various implementations, volatile media includes dynamic memory, such as system memory component 1506, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 1502. In an embodiment, transmission media may take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. Some common forms of computer readable media include, for example, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave, or any other medium from which a computer is adapted to read. The computer readable medium may be non-transitory.
In various embodiments of the disclosure, execution of instruction sequences to practice the disclosure may be performed by system 1500. In various other embodiments, a plurality of systems 1500 coupled by communication link 1520 (e.g., Wi-Fi antenna(s), or various other wired or wireless networks) may perform instruction sequences to practice the disclosure in coordination with one another. System 1500 may transmit and receive beacons, messages, data, information and instructions, including one or more programs (i.e., application code) through communication link 1520 and network interface component 1512. Received program code may be executed by processing component 1504 as received and/or stored in disk drive component 1510 or some other non-volatile storage component for execution.
As those of some skill in this art will by now appreciate and depending on the particular application at hand, many modifications, substitutions and variations can be made in and to the materials, apparatus, configurations and methods of use of the devices of the present disclosure without departing from the spirit and scope thereof. In light of this, the scope of the present disclosure should not be limited to that of the particular embodiments illustrated and described herein, as they are merely by way of some examples thereof, but rather, should be fully commensurate with that of the claims appended hereafter and their functional equivalents.
