WO2019006170A2

WO2019006170A2 - Methods and apparatus for facilitating communications using a wake-up radio frame

Info

Publication number: WO2019006170A2
Application number: PCT/US2018/040094
Authority: WO
Inventors: Po-Kai Huang; Daniel F. BRAVO; Robert Stacey
Original assignee: Intel Corporation
Priority date: 2017-06-30
Filing date: 2018-06-28
Publication date: 2019-01-03
Also published as: WO2019006170A3

Abstract

Methods and apparatus to facilitate communications using a wake-up radio frame are disclosed. An example apparatus includes a frame generator to generate a wake-up radio frame including a frame type identification corresponding to a vendor specific frame; and an interface to cause an antenna to transmit the wake-up radio frame to a low power receiver of a station while a high power receiver of the station is in a low power mode.

Description

METHODS AND APPARATUS FOR FACILITATING COMMUNICATIONS USING A

WAKE-UP RADIO FRAME

RELATED APPLICATION

This patent arises from an application claiming the benefit of U.S. Provisional Patent Application Serial No. 62/527,602, which was filed on June 30, 2017. U. S. Provisional Patent Application Serial No. 62/527,602 is hereby incorporated herein by reference in its entirety. Priority to U.S. Provisional Patent Application Serial No. 62/527,602 is hereby claimed.

FIELD OF THE DISCLOSURE

This disclosure relates generally to wireless fidelity connectivity (Wi-Fi) and, more particularly, to methods and apparatus for facilitating communications using a wake-up radio frame.

BACKGROUND

Many locations provide Wi-Fi to connect Wi-Fi enabled devices to networks such as the Internet. Wi-Fi enabled devices include personal computers, video-game consoles, mobile phones and devices, digital cameras, tablets, smart televisions, digital audio players, etc. Wi-Fi allows the Wi-Fi enabled devices to wirelessly access the Internet via a wireless local area network (WLAN). To provide Wi-Fi connectivity to a device, a Wi-Fi access point transmits a radio frequency Wi-Fi signal to the Wi-Fi enabled device within the access point (e.g., a hotspot) signal range. Wi-Fi is implemented using a set of media access control (MAC) and physical layer (PHY) specifications (e.g., such as the Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 protocol).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of the transmission of a wake-up radio frame in a local area network between example access point and an example station.

FIG. 2 is a block diagram of an example station wake-up handler and an example hibernation handler of FIG. 1. FIGS. 3A and 3B illustrates an example structures of a frame that may be transmitted by the example wake-up handler to the example hibernation handler of FIG. 2.

FIG. 4 is a flowchart representative of example machine readable instructions that may be executed to implement the example station wake-up handler of FIGS. 1 and 2.

FIG. 5 is a flowchart representative of example machine readable instructions that may be executed to implement the example hibernation handler of FIGS. 1 and 2.

FIG. 6 is a block diagram of a radio architecture in accordance with some examples.

FIG. 7 illustrates an example front-end module circuitry for use in the radio architecture of FIG. 6 in accordance with some examples.

FIG. 8 illustrates an example radio IC circuitry for use in the radio architecture of FIG. 6 in accordance with some examples.

FIG. 9 illustrates an example baseband processing circuitry for use in the radio architecture of FIG. 6 in accordance with some examples.

FIG. 10 is a block diagram of a processor platform structured to execute the example machine readable instructions of FIG. 4 to implement the example station wake-up handler of FIGS. 1 and 2.

FIG. 11 is a block diagram of a processor platform structured to execute the example machine readable instructions of FIG. 5 to implement the example hibernation handler of FIGS. 1 and 2.

The figures are not to scale. Wherever possible, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts.

DETAILED DESCRIPTION

Various locations (e.g., homes, offices, coffee shops, restaurants, parks, airports, etc.) may provide Wi-Fi to the Wi-Fi enabled devices (e.g., stations (STA)) to connect the Wi-Fi enabled devices to the Internet, or any other network, with minimal hassle. The locations may provide one or more Wi-Fi access points (APs) to output Wi-Fi signals to the Wi-Fi enabled device within a range of the Wi-Fi signals (e.g., a hotspot). A Wi-Fi AP is structured to wirelessly connect a Wi-Fi enabled device to the Internet through a wireless local area network (WLAN) using Wi-Fi protocols (e.g., such as IEEE 802.11). The Wi-Fi protocol is the protocol for how the AP communicates with the devices to provide access to the Internet by transmitting uplink (UL) transmissions and receiving downlink (DL) transmissions to/from the Internet

In some examples, a STA may include a low-power (LP) receiver to enable low-power operation of the STA. The LP receiver allows the STA to turn off a full power receiver or allow the receiver to enter into a hibernation (e.g., sleep or low-power) mode to conserve power. The LP receiver is able to receive wake-up receiver/radio (WUR) frames (e.g., packets) from an AP when full transmission of data is to be initiated. In this manner, once the LP receiver receives a WUR frame from another device (e.g., a AP or another STA), the LP receiver executes instructions corresponding to the WUR frame. For example, the LP receiver may wake-up the full power receiver to initiate full transmission capabilities. Such a WUR frame requires a 62.5 Kilobytes per second (Kbps) data rate, as opposed to a 6 Megabytes per second (Mbps) data rate of a data packet communicated with a full receiver. To maintain such a low data rate, example disclosed herein include a frame format of a WUR frame that avoids high overhead and waste of medium usage. Additionally, example disclosed herein generate a WUR frame that corresponds to vender specific data. Such a WUR frame disclosed herein may be extensible for adding additional data to allow for future development and innovation. Examples disclosed herein further include receiving the WUR frame and executing instructions based on the received WUR frame. Using examples disclosed herein, future extension of WUR data frames by Wi-Fi device designers is achievable with minimum overhead by enabling additional content within the frame for future purposes.

FIG. 1 illustrates the transmission of a WUR packet-based frame using Wi-Fi protocols between an example access point 100 and an example station 102. The example of FIG. 1 includes the example AP 100, the example STA 102, an example station wake-up handler 104, example radio architecture 105 A, 105B, an example hibernation handler 106, and an example network 108.

The example AP 100 of FIG. 1 is a device that allows the example STA 102 to wirelessly access the example network 108. The example AP 100 may be a router, a modem-router, and/or any other device that provides a wireless connection to the example network 108. A router provides a wireless communication link to a STA The router accesses the network 108 through a wire connection via a modem. A modem-router combines the functionalities of the modem and the router. The example AP 100 includes the example station wake-up handler 104 to transmit WUR based frames/packets to the example STA 102, as further described below. The example AP 100 includes the example radio architecture 105 A to transmit data to the example STA 102, as further described below in conjunction with FIG. 6.

The example STA 102 of FIG. 1 is a Wi-Fi enabled computing device. The example STA 102 may be, for example, a computing device, a portable device, a mobile device, a mobile telephone, a smart phone, a tablet, a gaming system, a digital camera, a digital video recorder, a television, a set top box, an e-book reader, and/or any other Wi-Fi enabled device. The example STA 102 includes the example hibernation handler 106 and the example radio architecture 105B to receive packets/frames from the example AP 100, as further explained below.

The example station wake-up handler 104 of the example AP 100 of FIG. 1 generates data packets (e.g., frames) to be transmitted to the example STA 102 using the example radio architecture 105A. In some examples, the station wake-up handler 104 generates a WUR data frame to be transmitted to the example hibernation handler 106 via the radio architecture 105 A using one or more channels. Additionally, the transmitter transmits other data packets to the example radio architecture 105B using one or more channels. In some examples, the example station wake-up handler 104 may instruct the radio architecture 105A to transmit the WUR data frame on a frequency channel dedicated to WUR data frame communications. When the example station wake-up handler 104 receives instructions to transmit (e.g., via the example application processor 610 of FIG. 6) to transmit a WUR frame (e.g., a wirelessly transmitted frame or a wireless frame) to the example hibernation handler 106, the example station wake-up handler 104 generates the WUR frame such that the example hibernation handler 106 can identify what type of WUR frame is being transmitted. For example, a WUR frame may be a WUR beacon, a unicast wake-up radio frame, a multicast wake-up radio frame, or a vendor specific or Wi-Fi alliance (WFA) WUR frame. A WUR beacon is a periodic or aperiodic transmission sent to maintain synchronization with the example STA 102 whose example hibernation handler 106 is ON and whose radio architecture 105B is OFF or in

sleep/hibernation/low-power mode. A unicast wake-up radio frame is a packet/frame designed to enable the example hibernation handler 106 to wake-up (e.g., turn ON or disable sleep mode) the example radio architecture 105B in response to receiving the wake-up radio frame. A multicast wake-up radio frame is a packet/frame designed to enable LP receivers of one or more STAs within a range of the example AP 100 (e.g., within the hotspot corresponding to the AP 100) to wake-up the receiver(s) of the one or more STAs in response to receiving the wake-up radio frame(s). A vendor specific and/or WFA WU frame is a frame that includes vendor and/or WFA specific content that may be used by the hibernation handler 106 to execute vendor and/or WFA specific instructions while the example radio architecture 105B is OFF or in sleep mode. Vendor specific WUR frames can add additional functionality along with the general WUR functionalities. For example, WFA can add features, which utilize the design of vender specific elements in PCR. In this manner, the vendor specific frame is a counterpart contain for WUR, thereby allowing other forums (e.g., car communication) to use the vendor specific design. Although the illustrated example of FIG. 1 includes the example station wake-up handler 104 in the example AP 100, the station wake-up handler 104 may transmit WUR frames from any device (e.g., including a second STA). The example station wake-up handler 104 is further described below in conjunction with FIG. 2.

The example hibernation handler 106 of the STA 102 of FIG. 1 receives WUR frames including WUR frames from the example station wake-up handler 104. When, the example hibernation handler 106 receives a WUR frame, the hibernation handler 106 analyzes the WUR frame to determine the WUR type. The example hibernation handler 106 executes instructions based on the frame type. For example, if the frame type corresponds to a wake-up packet, the example hibernation handler 106 executes instructions to wake-up the example radio architecture 105B. If the example hibernation handler 106 determines that the WUR frame corresponds to a vendor specific frame/packet, the hibernation handler 106 executes instructions to analyze the frame accordingly. Such instructions may include, determining the length of the frame, verifying the frame, and determining the vendor specific data of the frame. In this manner, the example hibernation handler 106 may execute instructions according to the vendor specific data. The example hibernation handler 106 is further described below in conjunction with FIG. 2.

The example radio architecture 105B of the example STA 102 of FIG. 2 is a full power radio architecture 105B that receives data packets from the example AP 100 to access data from the example network 108. The example radio architecture 105B enters into a sleep mode (e g , low-power mode and/or hibernation mode) and/or otherwise turns OFF when there is no communication between the AP 100 and the radio architecture 105B. In some examples, the radio architecture 105B enters sleep mode after a duration of inactivity and/or based on instructions transmitted by the example AP 100. When the example radio architecture 105B is in sleep mode, the example radio architecture 105B can be woken-up or otherwise turned ON by the example hibernation handler 106 in response to the example hibernation handler 106 receiving a WUR frame from the AP 100. The example radio architecture 105B is further described below in conjunction with FIG. 6.

The example network 108 of FIG. 1 is a system of interconnected systems exchanging data. The example network 108 may be implemented using any type of public or private network such as, but not limited to, the Internet, a telephone network, a local area network (LAN), a cable network, and/or a wireless network. To enable communication via the network 108, the example Wi-Fi AP 100 includes a communication interface that enables a connection to an Ethernet, a digital subscriber line (DSL), a telephone line, a coaxial cable, or any wireless connection, etc.

FIG. 2 is a block diagram of the example station wake-up handler 104 and the example hibernation handler 106 of FIG. 1, disclosed herein, to facilitate communication using a WUR frame/packet (e.g., the example frame 204). The example station wake-up handler 104 includes an example frame generator 200 and an example component interface 202. The example hibernation handler 106 includes an example low-power receiver 210 to receive the example frame 204, an example frame analyzer 212, and an example component interface 214.

The example frame generator 200 of FIG. 2 generates the example frame 204 (e.g., a WUR frame). The example frame generator 200 receives instructions from another circuit and/or processor (e.g., the example application processor 610 of FIG. 6) of the example AP 100 to generate and transmit the example frame 204 to the example hibernation handler 106 using one or more channels. In response to the instructions, the example frame generator 200 generates the example frame 204 including a frame type to identify the WUR type (e.g., a WUR beacon, a unicast wake-up radio frame, a multicast wake-up radio frame, or a vendor specific frame). Additionally, the frame generator 200 may include additional data within the example frame 204, as further described below in conjunction with FIGS. 3A and 3B. The example component interface 202 of FIG. 2 instructs the radio architecture 105 A to transmit the example frame 204 via one or more frequency channels. In some examples, the component interface 202 instructs the radio architecture 105 A to transmit the example frame 204 via a dedicated WUR channel. The example low-power receiver 210 of FIG. 2 receives the example frame 204 from the example AP 100. Once received, the example frame analyzer 212 analyzes the received frame to determine the frame type corresponding to the example frame 204. The example frame analyzer 212 of FIG. 2 processes the frame to identify the frame type included in the example frame 204. Once the example frame analyzer 212 determines the frame type corresponding to the example frame 204, the frame analyzer 212 determines how to proceed with analyzing the example frame 204. For example, if the frame analyzer 212 determines that the example frame 204 is a vendor specific frame, the frame analyzer 212 processes the frame 204 to determine the frame length, verify that the frame 204 is authentic (e.g., not corrupt, not from an attacker, not from an unauthorized or unintended source, no transmission errors, etc.), and determine the vendor specific data of the frame 204. For example, the frame analyzer 212 may, for a protected WU frame, verify that the frame check sequence (FCS) field is equal to MIC for authentication. The frame analyzer 212 may, for an unprotected WUR frame, verify that the FCS field is equal to CRC to check that there are no transmission errors of the frame. The example component interface 214 of FIG. 2 interfaces with other components of the example STA 102 based on the determined vendor specific data. For example, if the vendor specific data corresponds with executing instructions using a processor of the example STA 102, the example component interface 214 transmits the instructions to the processor (e.g., the example application processor 610 of FIG. 6) of the STA 102. The instructions may correspond to waking up the full power radio architecture 105B, protocols for maintaining synchronization with the AP 100 (e.g., time stamp functions, partial time stamps, etc.), etc.

FIG. 3A illustrates the example frame 204, in a general form, that may be generated and transmitted by the example station wake-up handler 104 of FIGS. 1 and/or 2. The example frame 204 includes an example frame control entry/field 300, an example address entry/field 302, an example TD control entry/field 304, an example frame body entry 306, and an example FCS entry /field 308. The example frame control entry/field 300 includes an example type entry/field 3 10, an example length present entry/field 312, an example length/misc. entry/field 314, and an example protected entry /field 316. Although the example frame 204 of FIG. 3B includes the example entries/fields 300-308 in a particular order, the example frame 204 may include any number and/or any order of entries. Likewise, the example station wake-up handler 104 may generate the frame 204 to combine and/or remove any of the example entries 300-308. The example frame 204 of FIG. 3B is a general MAC frame format for WUR frames.

The example frame control entry 300 of FIG. 3A is a field that is optionally present in certain WUR frame types, as further described below. The example address entry 302 of FIG. 3 A is a field that includes an identifier for the WUR frame. The identifier is selected from a group of identifiers (e.g., including a transmit ID identifying a transmitting AP, a group ID identifying a group of receiving WUR STAs, a WUR ID identifying an individual receiving WUR STA, or an organizationally unique identifier). The identifier depends on the type of WUR frame. The example TD control entry 304 of FIG. 3A is a field corresponding to a type dependent control field including control information that depends on the WUR frame type. The example frame body entry 306 of FIG. 3 A is a field including information specific to individual WUR frame types. The frame body entry 306 may not be present when the length present subfield 312 of the frame control 300 is zero (e.g., within ML WUR frames) and is present when the length control present entry 312 is one. The length of the frame body entry 306 is in units of octets and is equal to 2 x (L +1), where L is the value of the length subframe 312 in the frame control entry 300 (e.g., between 2 and 16 octets). The example FCS entry 308 is a field corresponding to a frame check sequence field used to verify the WUR frame 204. The example FSC entry 308 is further described below in conjunction with FIG. 3B.

The example frame control entry 300 of FIG. 3 A includes the type entry 310, the length present entry 312, the length/misc. entry 314, and the protected entry 316. The example type entry 10 is a field indicating the type of WUR frame. For example, the type entry 310 may includes one or more values corresponding to a WUR Beacon, a WUR wake-up, a WUR vendor specific, a WUR discovery, and one or more reserved values for future implementations. The length present entry 312 is a field including a value corresponding to whether length/misc. entry 314 is included in the frame control entry 300. The length/misc. entry 3 14 is a field including a value corresponding to the length of the frame body entry 306 and one or more reserved values. The protected entry 316 is a field indicating whether the information carried in the WUR frame 204 has been processed by a message integrity check algorithm. For example, the protected entry 3 16 may be set to 1 if the WUR frame is protected utilizing the MIC algorithm, otherwise it may be set to 0. FIG. 3B illustrates the example frame 204 that may be generated and transmitted by the example station wake-up handler 104 of FIGS. 1 and/or 2. The example frame 204 includes an example frame type entry 320, an example vendor identifier (ID) entry 322, an example length entry/field 324, an example vendor specific data entry/field 326, and an example FCS entry/field 328. Although the example frame 204 of FIG. 3B includes the example entries/fields 320-328 in a particular order, the example frame 204 may include any number and/or any order of entries. Likewise, the example station wake-up handler 104 may generate the frame 204 to combine and/or remove any of the example entries 320-328. The example frame 204 of FIG. 3B is a vender specific MAC frame format for WUR frame.

The example frame type entry 320 of FIG. 3B is a field that identifies that the frame 204 is a new frame and identifies the frame type. For example, the frame type may include one or more bits or bytes corresponding to different frame types (e.g., a first bit/byte corresponding to a WUR beacon, a second bit/byte corresponding to a unicast wake-up radio frame, a third bit/byte corresponding to a multicast wake-up radio frame, a fourth bit/byte corresponding to a vendor specific data frame, etc.). The example frame type 320 may be utilized in a public action frame in certain Wi-Fi protocols (e.g., 802.1 1).

The example vendor ID entry 322 of FIG. 3B is a field including values that identifies a source of the frame 204 (e.g., the vendor and/or the example AP 100) using some number of bits. In some examples, the vendor ID entry 322 entry includes a 24-bit organizationally unique identifier (OUI). In some examples, the vendor ID entry 322 may be an ID chosen by the example AP 100 and announced through the example station wake-up handler 104 using a main radio (e.g., used to communicate with the example radio architecture 105B of FIG. 1). In some examples, the vendor ID entry 322 includes a partial number of bits of a known value to both the example AP 100 and the example STA 102 (e.g., similar to an OUI). In some examples, the vendor ID entry may include a hashed value of a known value to both the example AP 100 and the example STA 102 (e.g., similar to an OUI).

The example length entry 324 of FIG. 3B is a field that identifies the length of the example frame 204. In some examples, the length entry 324 includes some number of bits indicating the length of the carried data of the frame 204 with some unit (e.g., bits or bytes). For example, a bit value of 1 may correspond to a frame length of 1 byte, a bit value of 2 may correspond to a frame length of 2 bytes, etc. In some examples, the length entry 324 includes some number of bits that corresponds to a predefined length (e.g., known by both the example AP 100 and the example STA 102 during negotiations, for example) For example, a bit value of 0 bits may correspond to a frame length of 2 bytes, a bit value of 1 bit may correspond to a frame length of 5 bytes, etc. In either of the above examples, the units may be in bits, bytes, or a combination of bits and bytes.

The example vendor specific data entry 326 of FIG. 3B is a field including data corresponding to some instructions to be executed by the example STA 102 when the example frame 204 is to be received. The example vendor specific data entry 326 may correspond to a preset length or may correspond to a variable length. Such a variable length effects the length of the example frame 204. However, the variable length is identified by the example length entry 324 so that the example STA 102 identifies the end of the example frame 204. In some examples, the length of the vendor specific data entry 326 depends on the maximum allowable frame size. The example vendor specific data entry 326 may be used by the example STA 102 to exchange management information prior to communicating full data packets to the example radio architecture 105B of FIG. 1. Additionally or alternatively, the example vendor specific data entry 326 may be used to carry information not currently designed in the 802.11 standard within a single defined format. Additionally or alternatively, the example vendor specific data entry 326 includes data to communicate any information or instructions that fits within the example vendor specific data entry 326. For example, the vender specific data entry 326 may include values corresponding to synchronization, instructions to wake-up the radio architecture 105B, vendor specific communication information (e.g., information related to car

communications), information not identified in a Wi-Fi standard, WFA subprogram information (e.g., multi-AP, device to device communication, multi-band operation, etc.), and/or any information that a vendor may want to include.

The example FCS entry 328 of FIG. 3B is a verification field that includes data that may be used to verify the example frame 204. For example, the example frame 204 may (A) have corrupt or otherwise invalid information, (B) be otherwise valid but not intended for the example STA 102, (C) be a fake frame sent by an attacker, etc. The example FCS entry 328 is used by the example STA 102 to verify the validity of the example frame 204. For example, the FCS entry 328 may include a predetermined value agreed upon by the example AP 100 and the example STA 102. In this manner, if the example STA 102 determines that the value of the example FCS entry 328 does not match the predetermined agreed upon value, the example STA 102 identifies that the example frame 204 is not valid and the example STA 102 disregards the frame. Additionally or alternatively, the example FCS entry 328 may be a frame check sequence (FCS), authentication field, or message integrity check/code (MIC) depending on what kinds of computation is to be used. For example, if the example FCS entry 328 is a FCS, the example AP 100 calculates a value based on the data in the example frame 204, which is included in the FCS. When the example frame 204 is received by the STA 102, the STA 102 recalculates the value calculated by the AP 100 and if the recalculated value does not match the FCS of the frame 204, the STA 102 determines that the frame 204 is invalid. In another example, if the FCS entry 328 is a MIC, the example AP 100 generates a sequence included in the example FCS entry 328. When the frame 204 is received by the STA 102, the STA 102 determines if the frame 204 is invalid based on the sequence (e.g., the sequence is invalid if out of order). If the example FCS entry 328 includes a predetermined sequence corresponding to the example AP 100, the example vendor ID entry 322 may not be necessary in the example frame 204 and may be omitted (e.g., to allow more space for one of the other entries or an additional entry).

While an example manner of implementing the example station wake-up handler 104 and example the hibernation handler 106 of FIG. 1 is illustrated in FIG. 2, one or more of the elements, processes and/or devices illustrated in FIG. 2 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example frame generator 200, the example component interface 202, and/or, more generally, the station wake-up handler 104 of FIG. 2 and the example low-power receiver 210, the example frame analyzer 212, the example component interface 214, and/or more generally the hibernation handler 106 of FIG. 2 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example frame generator 200, the example component interface 202, and/or, more generally, the station wake-up handler 104 of FIG. 2 and the example low-power receiver 210, the example frame analyzer 212, the example component interface 214, and/or more generally the hibernation handler 106 of FIG. 2 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example frame generator 200, the example component interface 202, and/or, more generally, the station wake-up handler 104 of FIG. 2 and the example low-power receiver 210, the example frame analyzer 212, the example component interface 214, and/or more generally the hibernation handler 106 of FIG. 2 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the hibernation handler 106 of FIG. 2 and/or the example station wake-up handler 104 of FIG. 2 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in FIG. 2, and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase "in

communication," including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

Flowcharts representative of example machine readable instructions for implementing the example station wake-up handler 104 of FIG. 2 is shown in FIG. 4 and a flowchart representative of example machine readable instructions for implementing the example hibernation handler 106 of FIG. 2 is shown in FIG. 5. In this example, the machine readable instructions comprise a program for execution by a processor such as the processor 1012, 1112 shown in the example processor platform 1000, 1100 discussed below in connection with FIGS. 10 and 11. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu- ray disk, or a memory associated with the processor 1012, 1112, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 1012, 1 1 12 and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowchart illustrated in FIGS. 4-5, many other methods of implementing the example station wake-up handler 104 and/or the example hibernation handler 106 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, a Field Programmable Gate Array (FPGA), an Application Specific Integrated circuit (ASIC), a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

As mentioned above, the example processes of FIGS. 4-5 may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non- transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information) As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

"Including" and "comprising" (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim employs any form of "include" or "comprise" (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, when the phrase "at least" is used as the transition term in, for example, a preamble of a claim, it is open-ended in the same manner as the term "comprising" and "including" are open ended. The term "and/or" when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C.

FIG. 4 is an example flowchart 400 representative of example machine readable instructions that may be executed by the example station wake-up handler 104 of FIG. 2 to generate and transmit the example frame 204 of FIG. 2. Although the flowchart 400 of FIG. 4 is described in conjunction with the example station wake-up handler 104 of FIG. 2, the instructions may be executed by any type of transmitter in any type of device.

At block 401, the example component interface 202 determines if instructions were received to send out WUR-based frame (e.g., the example frame 204 of FIG. 2). As described above in conjunction with FIG. 2, the instructions may come from a circuit or other device of the example AP 100 (e.g., the example application processor 610 of FIG. 6). If the example component interface 202 determines that instructions have not been received (block 401 : NO), the component interface 202 waits until instructions are received. If the example component interface 202 determines that instruction have been received (block 401 : YES), the example frame generator 200 determines a frame type based on received instructions to generate the frame 204 (block 402). For example, if the instructions correspond to a WUR beacon, the frame generator 200 determines that the frame 204 will correspond to a WUR beacon. At block 404, the example frame generator 200 identifies a frame structure based on the frame type. For example, each frame type may correspond to a different, or a similar, frame structure. Example WUR frames are described above in conjunction with FIG. 3A and 3B.

At block 406, the example frame generator 200 generates the example frame 204 within the identified frame structure. Such generation includes generating the example frame type entry 320 and/or any other entry corresponding to the example frame 204 of FIGS. 3 A and/or 3B . The structure and entries included in the example frame 204 may be based on user and/or manufacture preferences. At block 408, the example component interface 202 instructs the radio architecture 105A to transmit the generated frame (e.g., the example frame 204) to the hibernation handler 106 of the example STA 102.

FIG. 5 is an example flowchart 500 representative of example machine readable instructions that may be executed by the example hibernation handler 106 of FIG. 2 to receive and process the example frame 204 of FIG. 2. Although the flowchart 500 of FIG. 5 is described in conjunction with the example hibernation handler 106 of FIG. 2, the instructions may be executed by any type of LP receiver in any type of device.

At block 502, the example low-power receiver 210 receives the example frame 204. At block 504, the example frame analyzer 212 determines the frame type based on the received frame. For example, the frame analyzer 212 may process the example frame 204 to determine (e.g., extract) the frame type based on the value in the example frame type entry 320, 320 of FIGS 3A and 3B. At block 506, the example frame analyzer 212 determines if the frame type corresponds to a vendor specific WUR frame.

If the example frame analyzer 212 determines that the frame type does not correspond to a vendor specific WUR frame (block 506: NO), the example component interface 214 executes instruction according to the frame type (block 508). For example, if the frame type is a unicast wake-up frame, the example component interface 214 interfaces with the example radio architecture 105B of FIG. 1 to turn ON the example radio architecture 105B (e.g., by waking up the example radio architecture 105B). If the example frame analyzer 212 determines that the frame type corresponds to a vendor specific WUR frame (block 506: YES), the example frame analyzer 212 determines the frame length based on the received frame 204 (block 510). For example, the frame analyzer 212 may process the example length entry 324, 314 to determine the frame length, as further described above in conjunction with FIG. 3.

At block 512, the example frame analyzer 212 determines the end of the frame based on the frame length to process the example FCS entry 328. At block 514, the example frame analyzer 212 verifies the received frame 204 based on the example FCS entry 328. For example, the example frame analyzer 212 is able to verify the example frame 204 based on the FCS field 328/FCS entry 328 of FIGS. 3A-3B. In such an example, the frame analyzer 212 may look for a predefined value agreed upon by the AP 100 and the STA 102, an FCS, authentication number, MIC, etc. to determine if the value of the frame corresponds to is authentic (e.g., to verify the frame), as further described in conjunction with FIGS. 3A-3B. At block 516, the example frame analyzer 212 determines if the received frame 204 is authentic (e.g., based on verifying the frame 204 corresponding to the example FCS entry 328).

If the example frame analyzer 212 determines that the received frame 204 is not authentic (block 516: NO), the example frame analyzer 212 discards the received frame 204 (block 518). If the example frame analyzer 212 determines that the received frame 204 is authentic (block 516: YES), the example frame analyzer 212 determines the vendor specific data of the received frame 204 (block 520). The vendor specific data is included in the example vendor specific data entry 326 of FIG. 3A. At block 522, the example component interface 214 executes instructions according to the vendor specific data in the example vendor specific data entry 326 of the received frame 204. For example, if the instructions correspond to car communication protocols, the component interface 214 instructions a processor in communication with the component interface 214 to execute the car communication protocols

FIG. 6 is a block diagram of a radio architecture 105 A, 105B in accordance with some embodiments that may be implemented in any one of the example AP 100 and/or the example STA 102 of FIG 1 Radio architecture 105A, 105B may include radio front-end module (FEM) circuitry 604a-b, radio IC circuitry 606a-b and baseband processing circuitry 608a-b. Radio architecture 105 A, 105B as shown includes both Wireless Local Area Network (WLAN) functionality and Bluetooth (BT) functionality although embodiments are not so limited. In this disclosure, "WLAN" and "Wi-Fi" are used interchangeably.

FEM circuitry 604a-b may include a WLAN or Wi-Fi FEM circuitry 604a and a Bluetooth (BT) FEM circuitry 604b. The WLAN FEM circuitry 604a may include a receive signal path comprising circuitry configured to operate on WLAN RF signals received from one or more antennas 601, to amplify the received signals and to provide the amplified versions of the received signals to the WLAN radio IC circuitry 606a for further processing. The BT FEM circuitry 604b may include a receive signal path which may include circuitry configured to operate on BT RF signals received from one or more antennas 601, to amplify the received signals and to provide the amplified versions of the received signals to the BT radio IC circuitry 606b for further processing. FEM circuitry 604a may also include a transmit signal path which may include circuitry configured to amplify WLAN signals provided by the radio IC circuitry 606a for wireless transmission by one or more of the antennas 601. In addition, FEM circuitry 604b may also include a transmit signal path which may include circuitry configured to amplify BT signals provided by the radio IC circuitry 606b for wireless transmission by the one or more antennas. In the embodiment of FIG. 6, although FEM 604a and FEM 604b are shown as being distinct from one another, embodiments are not so limited, and include within their scope the use of an FEM (not shown) that includes a transmit path and/or a receive path for both WLAN and BT signals, or the use of one or more FEM circuitries where at least some of the FEM circuitries share transmit and/or receive signal paths for both WLAN and BT signals.

Radio IC circuitry 606a-b as shown may include WLAN radio IC circuitry 606a and BT radio IC circuitry 606b. The WLAN radio IC circuitry 606a may include a receive signal path which may include circuitry to down-convert WLAN RF signals received from the FEM circuitry 604a and provide baseband signals to WLAN baseband processing circuitry 608a. BT radio IC circuitry 606b may in turn include a receive signal path which may include circuitry to down-convert BT RF signals received from the FEM circuitry 604b and provide baseband signals to BT baseband processing circuitry 608b. WLAN radio IC circuitry 606a may also include a transmit signal path which may include circuitry to up-convert WLAN baseband signals provided by the WLAN baseband processing circuitry 608a and provide WLAN RF output signals to the FEM circuitry 604a for subsequent wireless transmission by the one or more antennas 601. BT radio IC circuitry 606b may also include a transmit signal path which may include circuitry to up-convert BT baseband signals provided by the BT baseband processing circuitry 608b and provide BT RF output signals to the FEM circuitry 604b for subsequent wireless transmission by the one or more antennas 601. In the embodiment of FIG. 6, although radio IC circuitries 606a and 606b are shown as being distinct from one another, embodiments are not so limited, and include within their scope the use of a radio IC circuitry (not shown) that includes a transmit signal path and/or a receive signal path for both WLAN and BT signals, or the use of one or more radio IC circuitries where at least some of the radio IC circuitries share transmit and/or receive signal paths for both WLAN and BT signals.

Baseband processing circuity 608a-b may include a WLAN baseband processing circuitry 608a and a BT baseband processing circuitry 608b The WLAN baseband processing circuitry 608a may include a memory, such as, for example, a set of RAM arrays in a Fast Fourier Transform or Inverse Fast Fourier Transform block (not shown) of the WLAN baseband processing circuitry 608a. Each of the WLAN baseband circuitry 608a and the BT baseband circuitry 608b may further include one or more processors and control logic to process the signals received from the corresponding WLAN or BT receive signal path of the radio IC circuitry 606a-b, and to also generate corresponding WLAN or BT baseband signals for the transmit signal path of the radio IC circuitry 606a-b. Each of the baseband processing circuitries 608a and 608b may further include physical layer (PHY) and medium access control layer (MAC) circuitry, and may further interface with the link aggregator 64 for generation and processing of the baseband signals and for controlling operations of the radio IC circuitry 606a- b.

Referring still to FIG. 6, according to the shown embodiment, WLAN-BT coexistence circuitry 613 may include logic providing an interface between the WLAN baseband circuitry 608a and the BT baseband circuitry 608b to enable use cases requiring WLAN and BT coexistence. In addition, a switch 603 may be provided between the WLAN FEM circuitry 604a and the BT FEM circuitry 604b to allow switching between the WLAN and BT radios according to application needs. In addition, although the antennas 601 are depicted as being respectively connected to the WLAN FEM circuitry 604a and the BT FEM circuitry 604b, embodiments include within their scope the sharing of one or more antennas as between the WLAN and BT FEMs, or the provision of more than one antenna connected to each of FEM 604a or 604b. In some embodiments, the front-end module circuitry 604a-b, the radio IC circuitry 606a- b, and baseband processing circuitry 608a-b may be provided on a single radio card, such as wireless radio card 602. In some other embodiments, the one or more antennas 601 , the FEM circuitry 604a-b and the radio IC circuitry 606a-b may be provided on a single radio card. In some other embodiments, the radio IC circuitry 606a-b and the baseband processing circuitry 608a-b may be provided on a single chip or integrated circuit (IC), such as IC 612.

In some embodiments, the wireless radio card 602 may include a WLAN radio card and may be configured for Wi-Fi communications, although the scope of the embodiments is not limited in this respect. In some of these embodiments, the radio architecture 105 A, 105B may be configured to receive and transmit orthogonal frequency division multiplexed (OFDM) or orthogonal frequency division multiple access (OFDMA) communication signals over a multicarrier communication channel. The OFDM or OFDMA signals may comprise a plurality of orthogonal subcarriers.

In some of these multicarrier embodiments, radio architecture 105 A, 105B may be part of a Wi-Fi communication station (STA) such as a wireless access point (AP), a base station or a mobile device including a Wi-Fi device. In some of these embodiments, radio architecture 105 A, 105B may be configured to transmit and receive signals in accordance with specific

communication standards and/or protocols, such as any of the Institute of Electrical and

Electronics Engineers (IEEE) standards including, 802. 1 ln-2009, IEEE 802.1 1 -2012, IEEE 802.11-2016, 802.1 1n-2009, 802.1 lac, 802.1 1 ah, 802. Had, 802.1 l ay and/or 802.1 l ax standards and/or proposed specifications for WLANs, although the scope of embodiments is not limited in this respect. Radio architecture 105 A, 105B may also be suitable to transmit and/or receive communications in accordance with other techniques and standards.

In some embodiments, the radio architecture 105A, 105B may be configured for high- efficiency Wi-Fi (FtEW) communications in accordance with the IEEE 802.1 lax standard. In these embodiments, the radio architecture 105 A, 105B may be configured to communicate in accordance with an OFDMA technique, although the scope of the embodiments is not limited in this respect.

In some other embodiments, the radio architecture 105 A, 105B may be configured to transmit and receive signals transmitted using one or more other modulation techniques such as spread spectrum modulation (e.g., direct sequence code division multiple access (DS-CDMA) and/or frequency hopping code division multiple access (FH-CDMA)), time-division multiplexing (TDM) modulation, and/or frequency-division multiplexing (FDM) modulation, although the scope of the embodiments is not limited in this respect.

In some embodiments, as further shown in FIG. 6, the BT baseband circuitry 608b may be compliant with a Bluetooth (BT) connectivity standard such as Bluetooth, Bluetooth 8.0 or Bluetooth 6.0, or any other iteration of the Bluetooth Standard. In embodiments that include BT functionality as shown for example in FIG. 6, the radio architecture 105A, 105B may be configured to establish a BT synchronous connection oriented (SCO) link and or a BT low energy (BT LE) link. In some of the embodiments that include functionality, the radio architecture 105 A, 105B may be configured to establish an extended SCO (eSCO) link for BT communications, although the scope of the embodiments is not limited in this respect. In some of these embodiments that include a BT functionality, the radio architecture may be configured to engage in a BT Asynchronous Connection-Less (ACL) communications, although the scope of the embodiments is not limited in this respect. In some embodiments, as shown in FIG. 6, the functions of a BT radio card and WLAN radio card may be combined on a single wireless radio card, such as single wireless radio card 602, although embodiments are not so limited, and include within their scope discrete WLAN and BT radio cards

In some embodiments, the radio-architecture 105 A, 105B may include other radio cards, such as a cellular radio card configured for cellular (e.g., 5GPP such as LTE, LTE- Advanced or 7G communications)

In some IEEE 802.11 embodiments, the radio architecture 105 A, 105B may be configured for communication over various channel bandwidths including bandwidths having center frequencies of about 900 MHz, 2.4 GHz, 5 GHz, and bandwidths of about 2 MHz, 4 MHz, 5 MHz, 5 5 MHz, 6 MHz, 8 MHz, 10 MHz, 20 MHz, 40 MHz, 80 MHz (with contiguous bandwidths) or 80+80 MHz (160MHz) (with non-contiguous bandwidths). In some

embodiments, a 920 MHz channel bandwidth may be used. The scope of the embodiments is not limited with respect to the above center frequencies however.

FIG. 7 illustrates WLAN FEM circuitry 604a in accordance with some embodiments. Although the example of FIG. 7 is described in conjunction with the WLAN FEM circuitry 604a, the example of FIG. 7 may be described in conjunction with the example BT FEM circuitry 604b (FIG. 6), although other circuitry configurations may also be suitable. In some embodiments, the FEM circuitry 604a may include a TX RX switch 702 to switch between transmit mode and receive mode operation. The FEM circuitry 604a may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 604a may include a low-noise amplifier (LNA) 706 to amplify received RF signals 703 and provide the amplified received RF signals 707 as an output (e.g., to the radio IC circuitry 606a-b (FIG. 6)). The transmit signal path of the circuitry 604a may include a power amplifier (PA) to amplify input RF signals 709 (e.g., provided by the radio IC circuitry 606a-b), and one or more filters 712, such as band-pass filters (BPFs), low-pass filters (LPFs) or other types of filters, to generate RF signals 715 for subsequent transmission (e.g., by one or more of the antennas 601 (FIG. 6)) via an example duplexer 714.

In some dual-mode embodiments for Wi-Fi communication, the FEM circuitry 604a may be configured to operate in either the 2.4 GHz frequency spectrum or the 5 GHz frequency spectrum. In these embodiments, the receive signal path of the FEM circuitry 604a may include a receive signal path duplexer 704 to separate the signals from each spectrum as well as provide a separate LNA 706 for each spectrum as shown. In these embodiments, the transmit signal path of the FEM circuitry 604a may also include a power amplifier 710 and a filter 712, such as a BPF, an LPF or another type of filter for each frequency spectrum and a transmit signal path duplexer 704 to provide the signals of one of the different spectrums onto a single transmit path for subsequent transmission by the one or more of the antennas 601 (FIG. 6). In some embodiments, BT communications may utilize the 2.4 GHz signal paths and may utilize the same FEM circuitry 604a as the one used for WLAN communications.

FIG. 8 illustrates radio IC circuitry 606a in accordance with some embodiments. The radio IC circuitry 606a is one example of circuitry that may be suitable for use as the WLAN or BT radio IC circuitry 606a/606b (FIG. 6), although other circuitry configurations may also be suitable. Alternatively, the example of FIG. 8 may be described in conjunction with the example BT radio IC circuitry 606b.

In some embodiments, the radio IC circuitry 606a may include a receive signal path and a transmit signal path. The receive signal path of the radio IC circuitry 606a may include at least mixer circuitry 802, such as, for example, down-conversion mixer circuitry, amplifier circuitry 806 and filter circuitry 808. The transmit signal path of the radio IC circuitry 606a may include at least filter circuitry 812 and mixer circuitry 814, such as, for example, up-conversion mixer circuitry. Radio IC circuitry 606a may also include synthesizer circuitry 804 for synthesizing a frequency 805 for use by the mixer circuitry 802 and the mixer circuitry 814 The mixer circuitry 802 and/or 814 may each, according to some embodiments, be configured to provide direct conversion functionality. The latter type of circuitry presents a much simpler architecture as compared with standard super-heterodyne mixer circuitries, and any flicker noise brought about by the same may be alleviated for example through the use of OFDM modulation. FIG. 8 illustrates only a simplified version of a radio IC circuitry, and may include, although not shown, embodiments where each of the depicted circuitries may include more than one component. For instance, mixer circuitry 814 may each include one or more mixers, and filter circuitries 808 and/or 812 may each include one or more filters, such as one or more BPFs and/or LPFs according to application needs. For example, when mixer circuitries are of the direct-conversion type, they may each include two or more mixers.

In some embodiments, mixer circuitry 802 may be configured to down-convert RF signals 707 received from the FEM circuitry 604a-b (FIG. 6) based on the synthesized frequency 805 provided by synthesizer circuitry 804. The amplifier circuitry 806 may be configured to amplify the down-converted signals and the filter circuitry 808 may include an LPF configured to remove unwanted signals from the down-converted signals to generate output baseband signals 807. Output baseband signals 807 may be provided to the baseband processing circuitry 608a-b (FIG. 6) for further processing. In some embodiments, the output baseband signals 807 may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 802 may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 814 may be configured to up-convert input baseband signals 81 1 based on the synthesized frequency 805 provided by the synthesizer circuitry 804 to generate RF output signals 709 for the FEM circuitry 604a-b. The baseband signals 81 1 may be provided by the baseband processing circuitry 608a-b and may be filtered by filter circuitry 812. The filter circuitry 812 may include an LPF or a BPF, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 802 and the mixer circuitry 814 may each include two or more mixers and may be arranged for quadrature down-conversion and/or up- conversion respectively with the help of synthesizer 804. In some embodiments, the mixer circuitry 802 and the mixer circuitry 814 may each include two or more mixers each configured for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 802 and the mixer circuitry 814 may be arranged for direct down-conversion and/or direct up- conversion, respectively. In some embodiments, the mixer circuitry 802 and the mixer circuitry 814 may be configured for super-heterodyne operation, although this is not a requirement.

Mixer circuitry 802 may comprise, according to one embodiment: quadrature passive mixers (e.g., for the in-phase (I) and quadrature phase (Q) paths). In such an embodiment, RF input signal 707 from FIG. 8 may be down-converted to provide I and Q baseband output signals to be sent to the baseband processor

Quadrature passive mixers may be driven by zero and ninety-degree time-varying LO switching signals provided by a quadrature circuitry which may be configured to receive a LO frequency (fLO) from a local oscillator or a synthesizer, such as LO frequency 805 of synthesizer 804 (FIG. 8). In some embodiments, the LO frequency may be the carrier frequency, while in other embodiments, the LO frequency may be a fraction of the carrier frequency (e.g., one-half the carrier frequency, one-third the carrier frequency). In some embodiments, the zero and ninety-degree time-varying switching signals may be generated by the synthesizer, although the scope of the embodiments is not limited in this respect.

In some embodiments, the LO signals may differ in duty cycle (the percentage of one period in which the LO signal is high) and/or offset (the difference between start points of the period). In some embodiments, the LO signals may have an 85% duty cycle and an 80% offset. In some embodiments, each branch of the mixer circuitry (e.g., the in-phase (I) and quadrature phase (Q) path) may operate at an 80% duty cycle, which may result in a significant reduction is power consumption.

The RF input signal 707 (FIG. 7) may comprise a balanced signal, although the scope of the embodiments is not limited in this respect. The I and Q baseband output signals may be provided to low-noise amplifier, such as amplifier circuitry 806 (FIG. 8) or to filter circuitry 808 (FIG. 8).

In some embodiments, the output baseband signals 807 and the input baseband signals 811 may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals 807 and the input baseband signals 81 1 may be digital baseband signals. In these alternate embodiments, the radio IC circuitry may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, or for other spectrums not mentioned here, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 804 may be a fractional-N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 804 may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider. According to some embodiments, the synthesizer circuitry 804 may include digital synthesizer circuitry. An advantage of using a digital synthesizer circuitry is that, although it may still include some analog components, its footprint may be scaled down much more than the footprint of an analog synthesizer circuitry. In some embodiments, frequency input into synthesizer circuity 804 may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. A divider control input may further be provided by either the baseband processing circuitry 608a-b (FIG. 6) depending on the desired output frequency 805. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table (e.g., within a Wi-Fi card) based on a channel number and a channel center frequency as determined or indicated by the example application processor 610. The application processor 610 may include, or otherwise be connected to, one of the example station wake-up handler 104 or the example hibernation handler 106 (e.g., depending on which device the example radio architecture is implemented in).

In some embodiments, synthesizer circuitry 804 may be configured to generate a carrier frequency as the output frequency 805, while in other embodiments, the output frequency 805 may be a fraction of the carrier frequency (e.g., one-half the carrier frequency, one-third the carrier frequency). In some embodiments, the output frequency 805 may be a LO frequency (fLO).

FIG. 9 illustrates a functional block diagram of baseband processing circuitry 608a in accordance with some embodiments. The baseband processing circuitry 608a is one example of circuitry that may be suitable for use as the baseband processing circuitry 608a (FIG. 6), although other circuitry configurations may also be suitable. Alternatively, the example of FIG. 83 may be used to implement the example BT baseband processing circuitry 608b of FIG 6.

The baseband processing circuitry 608a may include a receive baseband processor (RX BBP) 902 for processing receive baseband signals 809 provided by the radio IC circuitry 606a-b (FIG. 6) and a transmit baseband processor (TX BBP) 904 for generating transmit baseband signals 81 1 for the radio IC circuitry 606a-b. The baseband processing circuitry 608a may also include control logic 906 for coordinating the operations of the baseband processing circuitry 608a.

In some embodiments (e.g., when analog baseband signals are exchanged between the baseband processing circuitry 608a-b and the radio IC circuitry 606a-b), the baseband processing circuitry 608a may include ADC 910 to convert analog baseband signals 909 received from the radio IC circuitry 606a-b to digital baseband signals for processing by the RX BBP 902. In these embodiments, the baseband processing circuitry 608a may also include DAC 912 to convert digital baseband signals from the TX BBP 904 to analog baseband signals 91 1.

In some embodiments that communicate OFDM signals or OFDMA signals, such as through baseband processor 608a, the transmit baseband processor 904 may be configured to generate OFDM or OFDMA signals as appropriate for transmission by performing an inverse fast Fourier transform (IFFT). The receive baseband processor 902 may be configured to process received OFDM signals or OFDMA signals by performing an FFT. In some embodiments, the receive baseband processor 902 may be configured to detect the presence of an OFDM signal or OFDMA signal by performing an autocorrelation, to detect a preamble, such as a short preamble, and by performing a cross-correlation, to detect a long preamble. The preambles may be part of a predetermined frame structure for Wi-Fi communication.

Referring back to FIG. 6, in some embodiments, the antennas 601 (FIG. 6) may each comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some multiple-input multiple-output (MIMO) embodiments, the antennas may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result. Antennas 601 may each include a set of phased-array antennas, although embodiments are not so limited. Although the radio-architecture 105A, 105B is illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements.

FIG. 10 is a block diagram of an example processor platform 1000 capable of executing the instructions of FIG. 4 to implement the example station wake-up handler 104 of FIGS. 1 and/or 2. The processor platform 1000 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, or any other type of computing device.

The processor platform 1000 of the illustrated example includes a processor 1012. The processor 1012 of the illustrated example is hardware. For example, the processor 1012 can be implemented by integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.

The processor 1012 of the illustrated example includes a local memory 1013 (e.g., a cache). The example processor 1012 of FIG. 10 executes the instructions of FIG. 4 to implement the example frame generator 200 and the example component interface 202 of FIG. 2.

The processor 1012 of the illustrated example is in communication with a main memory including a volatile memory 1014 and a non-volatile memory 1016 via a bus 1018. The volatile memory 1014 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 1016 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1014, 1016 is controlled by a clock controller.

The processor platform 1000 of the illustrated example also includes an interface circuit 1020. The interface circuit 1020 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface. In the illustrated example, one or more input devices 1022 are connected to the interface circuit 1020. The input device(s) 1022 permit(s) a user to enter data and commands into the processor 1012. The input device(s) can be implemented by, for example, a sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 1024 are also connected to the interface circuit 1020 of the illustrated example. The output devices 1024 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, and/or speakers). The interface circuit 1020 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The interface circuit 1020 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1026 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 1000 of the illustrated example also includes one or more mass storage devices 1028 for storing software and/or data. Examples of such mass storage devices 1028 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The coded instructions 1032 of FIG. 4 may be stored in the mass storage device 1028, in the volatile memory 1014, in the non-volatile memory 1016, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

FIG. 11 is a block diagram of an example processor platform 1 100 capable of executing the instructions of FIG. 5 to implement the example hibernation handler 106 of FIGS 1 and/or 2. The processor platform 1 100 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, or any other type of computing device.

The processor platform 1100 of the illustrated example includes a processor 1112. The processor 1112 of the illustrated example is hardware. For example, the processor 1112 can be implemented by integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer.

The processor 1112 of the illustrated example includes a local memory 1 113 (e.g., a cache). The example processor 1 1 12 of FIG. 1 1 executes the instructions of FIG. 5 to implement the example low-power receiver 210, the example frame analyzer 212, and the example component interface 214 of FIG. 2.

The processor 1112 of the illustrated example is in communication with a main memory including a volatile memory 1 1 14 and a non-volatile memory 1 116 via a bus 1 1 18. The volatile memory 1 1 14 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 1 1 16 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1 1 14, 1 1 16 is controlled by a clock controller.

The processor platform 1100 of the illustrated example also includes an interface circuit 1 120. The interface circuit 1 120 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 1 122 are connected to the interface circuit 1 120. The input device(s) 1 122 permit(s) a user to enter data and commands into the processor 1 112. The input device(s) can be implemented by, for example, a sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 1 124 are also connected to the interface circuit 1120 of the illustrated example. The output devices 1 124 can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, and/or speakers). The interface circuit 1120 of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The interface circuit 1120 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e g., computing devices of any kind) via a network 1126 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 1100 of the illustrated example also includes one or more mass storage devices 1128 for storing software and/or data. Examples of such mass storage devices 1128 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The coded instructions 1132 of FIG. 5 may be stored in the mass storage device 1 128, in the volatile memory 1114, in the non-volatile memory 1116, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

Example 1 includes an apparatus to facilitate communications using a wake-up radio frame, the apparatus comprising a frame generator to generate a wake-up radio frame including a frame type identification corresponding to a vendor specific frame, and an interface to cause an antenna to transmit the wake-up radio frame to a low power receiver of a station while a high power receiver of the station is in a low power mode.

Example 2 includes the apparatus of example 1, wherein transmitting the wake-up radio frame to the low power receiver causes the station to wake-up the high power receiver.

Example 3 includes the apparatus of example 1, wherein the frame generate is to generate a vendor identifier field to identify a vendor specific design of the wake-up radio frame, the vender identifier being included in the wake-up radio frame.

Example 4 includes the apparatus of example 3, wherein the vendor identifier is a vendor organizationally unique identifier (oui).

Example 5 includes the apparatus of example 4, the vendor oui has a length of twenty four bits.

Example 6 includes the apparatus of example 3, wherein the vendor specific design includes vendor specific content in a frame body field of the wake-up radio frame.

Example 7 includes the apparatus of example 1, wherein the frame generate is to generate a length field identifying the length of a frame body field of the wake-up radio frame, the length field being included in the wake-up radio frame.

Example 8 includes the apparatus of example 1, wherein the frame generate is to generate a frame check sequence field including information used to verify the authenticity of the wake- up radio frame, the verification field being included in the wake-up radio frame. Example 9 includes the apparatus of example 1, wherein the wireless frame is a vendor specific wake-up receiver (wur) frame.

Example 10 includes the apparatus of example 1, wherein the frame generator is to generate the wake-up radio frame according a structure corresponding to the frame type example 11 includes an apparatus to facilitate communications using a wake-up radio frame, the apparatus comprising a low power receiver to receive a wake-up radio frame transmitted by an access point, a frame analyzer to process fields of the wake-up radio frame to determine a frame type, and an interface to, when the frame type corresponds to a vendor specific wireless frame, execute instructions according to vendor specific data in the received wake-up radio frame.

Example 12 includes the apparatus of example 11, wherein the instructions corresponding to at least one of synchronization protocols or waking up high power radio architecture.

Example 13 includes the apparatus of example 11, wherein the frame analyzer is to, when the frame type does not correspond to the vendor specific wireless frame, execute instructions corresponding to the frame type.

Example 14 includes the apparatus of example 11, wherein the frame analyzer is to process the fields of the wake-up radio frame to determine a frame length, and determine an end of the wake-up radio frame based on the frame length.

Example 15 includes the apparatus of example 11, wherein the frame analyzer is to process the fields of the wake-up radio frame to verify the authenticity of the wake-up radio frame.

Example 16 includes the apparatus of example 15, wherein the frame analyzer is to, when the wake-up radio frame is not authentic, discard the wake-up radio frame.

Example 17 includes the apparatus of example 15, wherein the frame analyzer is to process the frame of the pack-up packet to verify the authenticity based on at least one of a predefined value, a frame check sequence, an authentication field, or a message integrity code.

Example 18 includes a tangible computer readable storage medium comprising instructions which, when executed cause a machine to at least generate a wake-up radio frame including a frame type identification corresponding to a vendor specific frame, and cause an antenna to transmit the wake-up radio frame to a low power receiver of a station while a high power receiver of the station is in a low power mode Example 19 includes the computer readable storage medium of example 1, wherein transmitting the wake-up radio frame to the low power receiver causes the station to wake-up the high power receiver.

Example 20 includes the computer readable storage medium of example 1, wherein the instructions cause the machine to generate a vendor identifier field to identify a vendor specific design of the wake-up radio frame, the vender identifier being included in the wake-up radio frame.

Example 21 includes the computer readable storage medium of example 3, wherein the vendor identifier is a vendor organizationally unique identifier (oui).

Example 22 includes the computer readable storage medium of example 4, the vendor oui has a length of twenty four bits.

Example 23 includes the computer readable storage medium of example 3, wherein the vendor specific design includes vendor specific content in a frame body field of the wake-up radio frame.

Example 24 includes the computer readable storage medium of example 1, wherein the instructions cause the machine to generate a length field identifying the length of a frame body field of the wake-up radio frame, the length field being included in the wake-up radio frame.

Example 25 includes the computer readable storage medium of example 1, wherein the instructions cause the machine to generate a frame check sequence field including information used to verify the authenticity of the wake-up radio frame, the verification field being included in the wake-up radio frame.

Example 26 includes the computer readable storage medium of example 1, wherein the wireless frame is a vendor specific wake-up receiver (wur) frame.

Example 27 includes the computer readable storage medium of example 1, wherein the instructions cause the machine to generate the wake-up radio frame according a structure corresponding to the frame type example 28 includes a tangible computer readable storage medium comprising instructions which, when executed cause a machine to at least receive a wake-up radio frame transmitted by an access point, process fields of the wake-up radio frame to determine a frame type, and when the frame type corresponds to a vendor specific wireless frame, execute instructions according to vendor specific data in the received wake-up radio frame. Example 29 includes the computer readable storage medium of example 11, wherein the instructions corresponding to at least one of synchronization protocols or waking up high power radio architecture.

Example 30 includes the computer readable storage medium of example 11, wherein the instructions cause the machine to, when the frame type does not correspond to the vendor specific wireless frame, execute instructions corresponding to the frame type.

Example 31 includes the computer readable storage medium of example 11, wherein the instructions cause the machine to process the fields of the wake-up radio frame to determine a frame length, and determine an end of the wake-up radio frame based on the frame length.

Example 32 includes the computer readable storage medium of example 11, wherein the instructions cause the machine to process the fields of the wake-up radio frame to verify the authenticity of the wake-up radio frame.

Example 33 includes the computer readable storage medium of example 15, wherein the instructions cause the machine to, when the wake-up radio frame is not authentic, discard the wake-up radio frame.

Example 34 includes the computer readable storage medium of example 15, wherein the instructions cause the machine to process the frame of the pack-up packet to verify the authenticity based on at least one of a predefined value, a frame check sequence, an

authentication field, or a message integrity code.

Example 3 includes a method to facilitate communications using a wake-up radio frame, the method comprising generating a wake-up radio frame including a frame type identification corresponding to a vendor specific frame, and instructing an antenna to transmit the wake-up radio frame to a low power receiver of a station while a high power receiver of the station is in a low power mode.

Example 36 includes a method to facilitate communications using a wake-up radio frame, the method comprising receiving a wake-up radio frame transmitted by an access point, processing fields of the wake-up radio frame to determine a frame type, and when the frame type corresponds to a vendor specific wireless frame, executing instructions according to vendor specific data in the received wake-up radio frame.

Although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.

Claims

CLAIMS What Is Claimed Is:

1. An apparatus to facilitate communications using a wake-up radio frame, the apparatus comprising:

a frame generator to generate a wake-up radio frame including a frame type identification corresponding to a vendor specific frame; and

an interface to cause an antenna to transmit the wake-up radio frame to a low power receiver of a station while a high power receiver of the station is in a low power mode.

2. The apparatus of claim 1, wherein transmitting the wake-up radio frame to the low power receiver causes the station to wake-up the high power receiver.

3. The apparatus of claim 1, wherein the frame generate is to generate a vendor identifier field to identify a vendor specific design of the wake-up radio frame, the vender identifier being included in the wake-up radio frame.

4. The apparatus of claim 3, wherein the vendor identifier is a vendor

organizationally unique identifier (OUI).

5. The apparatus of claim 4, the vendor OUI has a length of twenty four bits.

6. The apparatus of claim 3, wherein the vendor specific design includes vendor specific content in a frame body field of the wake-up radio frame.

7. The apparatus of claim 1, wherein the frame generate is to generate a length field identifying the length of a frame body field of the wake-up radio frame, the length field being included in the wake-up radio frame.

8. The apparatus of claim 1, wherein the frame generate is to generate a frame check sequence field including information used to verify the authenticity of the wake-up radio frame, the verification field being included in the wake-up radio frame.

9. The apparatus of claim 1, wherein the wireless frame is a vendor specific wake-up receiver (WUR) frame.

10. The apparatus of claim 1, wherein the frame generator is to generate the wake-up radio frame according a structure corresponding to the frame type

11. An apparatus to facilitate communications using a wake-up radio frame, the apparatus comprising:

a low power receiver to receive a wake-up radio frame transmitted by an access point; a frame analyzer to process fields of the wake-up radio frame to determine a frame type; and

an interface to, when the frame type corresponds to a vendor specific wireless frame, execute instructions according to vendor specific data in the received wake-up radio frame.

12. The apparatus of claim 1 1 , wherein the instructions corresponding to at least one of synchronization protocols or waking up high power radio architecture.

13. The apparatus of claim 1 1 , wherein the frame analyzer is to, when the frame type does not correspond to the vendor specific wireless frame, execute instructions corresponding to the frame type.

14. The apparatus of claim 1 1 , wherein the frame analyzer is to:

process the fields of the wake-up radio frame to determine a frame length; and determine an end of the wake-up radio frame based on the frame length.

15. The apparatus of claim 1 1 , wherein the frame analyzer is to process the fields of the wake-up radio frame to verify the authenticity of the wake-up radio frame.

16. The apparatus of claim 15, wherein the frame analyzer is to, when the wake-up radio frame is not authentic, discard the wake-up radio frame.

17. The apparatus of claim 15, wherein the frame analyzer is to process the frame of the pack-up packet to verify the authenticity based on at least one of a predefined value, a frame check sequence, an authentication field, or a message integrity code.

18. A tangible computer readable storage medium comprising instructions which, when executed cause a machine to at least:

generate a wake-up radio frame including a frame type identification corresponding to a vendor specific frame; and

cause an antenna to transmit the wake-up radio frame to a low power receiver of a station while a high power receiver of the station is in a low power mode.

19. The computer readable storage medium of claim 1, wherein transmitting the wake-up radio frame to the low power receiver causes the station to wake-up the high power receiver.

20. The computer readable storage medium of claim 1, wherein the instructions cause the machine to generate a vendor identifier field to identify a vendor specific design of the wake- up radio frame, the vender identifier being included in the wake-up radio frame.

21. The computer readable storage medium of claim 3, wherein the vendor identifier is a vendor organizationally unique identifier (OUI).

22. The computer readable storage medium of claim 4, the vendor OUI has a length of twenty four bits.

23. The computer readable storage medium of claim 3, wherein the vendor specific design includes vendor specific content in a frame body field of the wake-up radio frame.

24. The computer readable storage medium of claim 1, wherein the instructions cause the machine to generate a length field identifying the length of a frame body field of the wake-up radio frame, the length field being included in the wake-up radio frame.

25. The computer readable storage medium of claim 1, wherein the instructions cause the machine to generate a frame check sequence field including information used to verify the authenticity of the wake-up radio frame, the verification field being included in the wake-up radio frame.

26. The computer readable storage medium of claim 1, wherein the wireless frame is a vendor specific wake-up receiver (WUR) frame.

27. The computer readable storage medium of claim 1, wherein the instructions cause the machine to generate the wake-up radio frame according a structure corresponding to the frame type

28. A tangible computer readable storage medium comprising instructions which, when executed cause a machine to at least:

receive a wake-up radio frame transmitted by an access point;

process fields of the wake-up radio frame to determine a frame type; and

when the frame type corresponds to a vendor specific wireless frame, execute instructions according to vendor specific data in the received wake-up radio frame.

29. The computer readable storage medium of claim 11, wherein the instructions corresponding to at least one of synchronization protocols or waking up high power radio architecture.

30. The computer readable storage medium of claim 11, wherein the instructions cause the machine to, when the frame type does not correspond to the vendor specific wireless frame, execute instructions corresponding to the frame type.

31. The computer readable storage medium of claim 11, wherein the instructions cause the machine to:

32. The computer readable storage medium of claim 11, wherein the instructions cause the machine to process the fields of the wake-up radio frame to verify the authenticity of the wake-up radio frame.

33. The computer readable storage medium of claim 15, wherein the instructions cause the machine to, when the wake-up radio frame is not authentic, discard the wake-up radio frame.

34. The computer readable storage medium of claim 15, wherein the instructions cause the machine to process the frame of the pack-up packet to verify the authenticity based on at least one of a predefined value, a frame check sequence, an authentication field, or a message integrity code.

35. A method to facilitate communications using a wake-up radio frame, the method comprising:

generating a wake-up radio frame including a frame type identification corresponding to a vendor specific frame; and

instructing an antenna to transmit the wake-up radio frame to a low power receiver of a station while a high power receiver of the station is in a low power mode.

36. A method to facilitate communications using a wake-up radio frame, the method comprising:

receiving a wake-up radio frame transmitted by an access point;

processing fields of the wake-up radio frame to determine a frame type; and when the frame type corresponds to a vendor specific wireless frame, executing instructions according to vendor specific data in the received wake-up radio frame.