CN111615850B

CN111615850B - Enabling wake-up radio (WUR) device communications

Info

Publication number: CN111615850B
Application number: CN201980007364.3A
Authority: CN
Inventors: A·阿斯特加迪; G·切瑞安; B·田; S·J·谢尔汉姆
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2018-01-04
Filing date: 2019-01-04
Publication date: 2024-02-09
Anticipated expiration: 2039-01-04
Also published as: CN111615850A; WO2019136212A1; TW201931903A; US11026172B2; EP3735789A1; TWI769362B; US20190208470A1

Abstract

The present disclosure provides systems, methods, and apparatus, including computer programs encoded on a computer storage medium, for establishing communication with one or more devices. In one aspect, a first device generates a wake-up radio (WUR) frame that includes a Medium Access Control (MAC) header and a Frame Check Sequence (FCS) with a Cyclic Redundancy Check (CRC) or a Message Integrity Check (MIC). The first device may determine the FCS based at least in part on the MAC header and Basic Service Set Identifier (BSSID) information associated with the first device. The first device may output WUR frames for transmission to one or more devices. The second device may receive the WUR frame from the first device and determine whether the WUR frame is directed to the second device based at least in part on comparing an FCS of the WUR frame with the calculated FCS.

Description

Enabling wake-up radio (WUR) device communications

Cross Reference to Related Applications

This patent application claims priority from U.S. provisional patent application No.62/613,737 filed on 1 month 4 of 2018, U.S. provisional patent application No.62/635,307 filed on 2 month 26 of 2018, and U.S. patent application No.16/239,479 filed on 1 month 3 of 2019.

Technical Field

The present application relates generally to wireless communications, and more particularly, to systems, methods, and devices for enabling communications with wake-up radio (WUR) devices.

Description of related Art

In many telecommunication systems, a communication network is used to exchange messages between several spatially separated interacting devices. The network may be classified according to geographic scope, which may be, for example, a metropolitan area, a local area, or a personal area. Such networks will be designated as Wide Area Networks (WANs), metropolitan Area Networks (MANs), local Area Networks (LANs), wireless Local Area Networks (WLANs), or Personal Area Networks (PANs), respectively. Networks also vary according to the switching/routing techniques used to interconnect the various network nodes and devices (such as circuit switched versus packet switched), the type of physical medium used for transmission (such as wire versus wireless), and the set of communication protocols used (such as the internet protocol suite, SONET (synchronous optical networking), ethernet, etc.).

Wireless networks are often preferred when network elements are mobile and thus have dynamic connectivity requirements, or where the network architecture is formed in an ad hoc (ad hoc) topology rather than a fixed topology. Wireless networks employ intangible physical media in an unguided propagation mode using electromagnetic waves in the radio, microwave, infrared, optical, etc. frequency bands. Wireless networks advantageously facilitate user mobility and rapid field deployment when compared to fixed wired networks.

However, as the use of wireless networks increases, the power constraints of the wireless devices may become increasingly critical. Some devices may include multiple radios: one or more "primary" radios for general communication and data transfer over a wireless network, and a secondary radio or "wake-up radio (WUR)" for wake-up communication. In some cases, the WUR radio may be the only radio of the device. In particular, WUR may provide communications when the primary radio is in a power save mode because periodically waking up WUR to monitor communications on the wireless network may be more energy efficient than waking up the primary radio.

SUMMARY

The systems, methods, and apparatus of the present disclosure each have several inventive aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

One innovative aspect of the subject matter described in this disclosure can be implemented by a first device for establishing communication with one or more devices. The first device may generate a wake-up radio (WUR) frame. WUR frames may include a Medium Access Control (MAC) header, and a Frame Check Sequence (FCS) with a Cyclic Redundancy Check (CRC) or Message Integrity Check (MIC). The FCS may be determined based at least in part on the MAC header and Basic Service Set Identifier (BSSID) information associated with the first device. The first device may output WUR frames for transmission to the one or more devices.

In some implementations, the FCS may include a CRC when the WUR frame is an unprotected frame.

In some implementations, the FCS may include a MIC when the WUR frame is a protected frame.

In some implementations, a first device may determine an FCS based at least in part on a MAC header and BSSID information associated with the first device. BSSID information used to determine the value of FCS may not be included in WUR frames that are output for transmission. The first device may output WUR frames for transmission to the one or more devices. WUR frames may include a MAC header and an FCS.

In some implementations, a first device may generate a bit sequence for a WUR frame that includes at least a first plurality of bits for a MAC header and a second plurality of bits for BSSID information associated with the first device. The first device may determine an FCS based at least in part on the first plurality of bits for the MAC header and the second plurality of bits for the BSSID information, wherein the FCS includes a third plurality of bits. The first device may append the third plurality of bits for the FCS to the bit sequence for the WUR frame. The first device may output a WUR frame for transmission to the one or more devices, the WUR frame including the first plurality of bits for a MAC header and the third plurality of bits for an FCS.

In some implementations, the first device may determine a CRC or MIC based at least in part on the MAC header. The first device may determine the FCS based at least in part on the CRC or MIC and BSSID information associated with the first device. The first device may output WUR frames for transmission to the one or more devices. WUR frames may include a MAC header and an FCS.

Another innovative aspect of the subject matter described in this disclosure can be implemented by a first device for establishing communications having WUR. The first device may receive WUR frames from the second device via the WUR. WUR frames may include a MAC header, and FCS with a CRC or MIC. The FCS may be determined by the second device based at least in part on the MAC header and BSSID information associated with the second device. The first device may determine whether the WUR frame is directed to the first device based at least in part on comparing an FCS of the WUR frame with the calculated FCS.

In some implementations, the first device may determine the calculated FCS based at least in part on a MAC header of the WUR frame and stored BSSID information stored at the first device.

In some implementations, the first device may determine whether the FCS of the WUR frame matches the calculated FCS by comparing the FCS of the WUR frame with the calculated FCS. The first device may determine that the WUR frame is directed to the first device in response to determining that the FCS of the WUR frame matches the calculated FCS. The first device may determine that the WUR frame is not directed to the first device in response to determining that the FCS of the WUR frame does not match the calculated FCS.

In some implementations, the first device may determine a CRC or MIC based at least in part on the MAC header of the WUR frame. The first device may generate the calculated FCS based at least in part on the CRC or MIC and the stored BSSID information. The first device may determine whether the FCS of the WUR frame matches the calculated FCS by comparing the FCS of the WUR frame with the calculated FCS. The first device may determine that the WUR frame is directed to the first device in response to determining that the FCS of the WUR frame matches the calculated FCS. The first device may determine that the WUR frame is not directed to the first device in response to determining that the FCS of the WUR frame does not match the calculated FCS.

Another innovative aspect of the subject matter described in this disclosure can be implemented by a first device including a processor and an interface. The processor may be configured to generate WUR frames. WUR frames may include a MAC header, and FCS with a CRC or MIC. The FCS may be determined based at least in part on the MAC header and BSSID information associated with the first device. The interface may be coupled to the processor. The interface may be configured to output WUR frames for transmission to one or more devices.

Another innovative aspect of the subject matter described in this disclosure can be implemented by a first device including WUR and a processor. The WUR may be configured to receive WUR frames from the second device. WUR frames may include a MAC header, and FCS with a CRC or MIC. The FCS may be determined by the second device based at least in part on the MAC header and BSSID information associated with the second device. The processor may be coupled with WUR. The processor may be configured to determine whether the WUR frame is directed to the first device based at least in part on a comparison of an FCS of the WUR frame with the calculated FCS.

The details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims. It should be noted that the relative dimensions of the following figures may not be drawn to scale.

Brief Description of Drawings

Fig. 1 illustrates an example of a wireless communication system in which aspects of the present disclosure may be employed.

Fig. 2 illustrates various components that may be utilized in a wireless device employed within the wireless communication system of fig. 1.

Fig. 3 illustrates an example structure of a Physical Layer Convergence Procedure (PLCP) protocol data unit (PPDU) for communicating with a wake-up radio (WUR) device.

Fig. 4 illustrates further details of an example structure of the PPDU of fig. 3 for communication with WUR devices.

Fig. 5 illustrates further details of an example structure of the PPDU of fig. 3 for communication with WUR devices.

Fig. 6 illustrates another example structure of a PPDU for communicating with WUR devices.

Fig. 7 illustrates further details of an example structure of the PPDU of fig. 6 for communication with WUR devices.

Fig. 8 illustrates a flow chart of an example method of wireless communication.

Fig. 9 illustrates further details of an example structure of the PPDU of fig. 3 for communication with WUR devices.

Fig. 10 illustrates further details of an example structure of the MPDU of fig. 9.

Fig. 11 illustrates further details of an example structure of the MPDU of fig. 9.

Fig. 12 illustrates details of an example WUR frame indicating an embedded BSSID field and details of an example WUR frame not indicating an embedded BSSID field.

Fig. 13 illustrates a flowchart of an example method performed by a first device for generating WUR frames for transmission to one or more devices.

Fig. 14 illustrates an example WUR frame initially generated with BSSID information for determining FCS, and an example WUR frame output for transmission.

Fig. 15 illustrates an example WUR frame initially generated for determining FCS, and an example WUR frame output for transmission.

Fig. 16 illustrates a flow chart of an example method performed by a first device having WUR for receiving and processing WUR frames.

Fig. 17 illustrates details of an example process flow for calculating FCS of WUR frames.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

The following description is directed to certain implementations to aim at describing innovative aspects of the present disclosure. However, one of ordinary skill in the art will readily recognize that the teachings herein could be applied in a multitude of different ways. The described implementations may be in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard or Any of the standards is implemented in any device, system, or network that transmits and receives Radio Frequency (RF) signals. The described implementations may also be implemented in any device, system, or network capable of transmitting and receiving RF signals in accordance with any one of the following techniques or technologies: code Division Multiple Access (CDMA), frequency Division Multiple Access (FDMA), orthogonal Frequency Division Multiple Access (OFDMA), time Division Multiple Access (TDMA), global system for mobile communications (GSM), GSM/General Packet Radio Service (GPRS), enhanced Data GSM Environment (EDGE), terrestrial trunked radio (TETRA), wideband CDMA (W-CDMA), evolution data optimized (EV-DO), 1xEV-DO, EV-DO revision A, EV-DO revision B, high Speed Packet Access (HSPA), high Speed Downlink Packet Access (HSDPA), high Speed Uplink Packet Access (HSUPA), evolved high speed packet access (hspa+), long Term Evolution (LTE), AMPS, or other known signals for communication within a wireless network, cellular network, or internet of things (IOT) network (such as systems utilizing 3G, 4G, or 5G or further implemented technologies thereof).

Wireless network technologies may include various types of Wireless Local Area Networks (WLANs). WLANs may be used to interconnect nearby devices together using widely used networking protocols. The various aspects described herein are applicable to any communication standard, such as WiFi, or more generally any member of the IEEE 802.11 family of wireless protocols, such as the IEEE 802.11ba protocol.

In some implementations, the WLAN includes various devices as components to access the wireless network. For example, there may be two types of devices: an access point ("AP") and a client (also referred to as a station, or "STA"). In general, an AP acts as a hub or base station of a WLAN, while STAs act as users of the WLAN. For example, the STA may be a laptop computer, a Personal Digital Assistant (PDA), a mobile phone, a watch, or the like. In an example, a STA connects to an AP via a wireless link that is compliant with WiFi (such as IEEE 802.11 protocol) to obtain general connectivity to the internet or to other wide area networks. In some implementations, the STA may also be used as an AP.

The teachings herein may be incorporated into (such as implemented within or performed by) various wired or wireless devices (such as nodes). In some aspects, a wireless node implemented according to the teachings herein may include an access point or an access terminal.

An AP may include, be implemented as, or referred to as a node B, radio network controller ("RNC"), evolved node B, base station controller ("BSC"), base transceiver station ("BTS"), base station ("BS"), transceiver function ("TF"), radio router, radio transceiver, basic service set ("BSs"), extended service set ("ESS"), radio base station ("RBS"), or some other terminology.

A STA may also include, be implemented as, or referred to as an access terminal ("AT"), a subscriber station, a subscriber unit, a mobile station, a remote terminal, a user agent, a user device, a user equipment, or some other terminology. In some implementations, an access terminal may comprise a cellular telephone, a cordless telephone, a session initiation protocol ("SIP") phone, a wireless local loop ("WLL") station, a personal digital assistant ("PDA"), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (such as a cellular phone or smart phone), a computer (such as a laptop device), a portable communication device, a headset, a portable computing device (such as a personal data assistant), an entertainment device (such as a music or video device, or a satellite radio), a gaming device or system, a global positioning system device, or any other suitable device that is configured to communicate via a wireless medium.

Each AP and each STA of a network may generate a wake-up radio (WUR) communication and transmit the WUR communication to another device in the network, such as another AP or STA. For example, the AP may generate a WUR communication and transmit the WUR communication to the STA. WUR communications may be WUR frames directed to a WUR of a STA to avoid waking up the STA's primary radio. In some implementations, an AP may conceal, hash, scramble, or mask BSSID information associated with the AP in generating a value for a Frame Check Sequence (FCS) of a WUR frame in the FCS. In some implementations, an AP may generate an FCS for a WUR frame based at least in part on a Medium Access Control (MAC) header and BSSID information associated with the AP. After generating the WUR frame, the AP may transmit the WUR frame to one or more devices in the network. The transmitted WUR frame may include at least a MAC header and an FCS. BSSID information for determining the value of the FCS may not be included in the transmitted WUR frame. The STA may receive the WUR frame from the AP and determine whether the WUR frame is directed to the STA or to another device in the network. The STA may use the stored BSSID information previously received from the AP to determine whether the WUR is directed to the STA.

Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. The various types of frames exchanged between APs and STAs of a network typically include Basic Service Set Identifier (BSSID) information in separate fields or subfields within the frame. Generating and transmitting WUR frames that do not include BSSID information in separate fields or subfields within the WUR frames may reduce the size of the frames, reduce transmission overhead, and increase transmission speed. In addition, hiding, hashing, scrambling or masking WUR frames of BSSID information in FCS of WUR frames may improve privacy and security.

Fig. 1 is an illustration of an example wireless communication system 100 in which aspects of the disclosure may be employed. The wireless communication system 100 may operate in accordance with a wireless standard, such as a High Efficiency (HE) 802.11 standard, a High Throughput (HT) 802.11 standard, a Very High Throughput (VHT) standard, an Extremely High Throughput (EHT) standard, or any other wireless communication standard. The wireless communication system 100 may include an AP 104 in communication with various STAs 106 (generally referred to as STAs 106A-106C).

Various procedures and methods may be used for transmissions between the AP 104 and the STAs 106 in the wireless communication system 100. For example, signals may be transmitted and received between the AP 104 and the STAs 106 in accordance with OFDM/OFDMA techniques. If this is the case, the wireless communication system 100 may be referred to as an OFDM/OFDMA system. Alternatively, signals may be transmitted and received between the AP 104 and the STAs 106 in accordance with Code Division Multiple Access (CDMA) techniques. If this is the case, the wireless communication system 100 may be referred to as a CDMA system.

The communication link that facilitates transmission from the AP 104 to the one or more STAs 106 may be referred to as a Downlink (DL) 108, while the communication link that facilitates transmission from the one or more STAs 106 to the AP 104 may be referred to as an Uplink (UL) 110. Alternatively, the downlink 108 may be referred to as a forward link or forward channel, while the uplink 110 may be referred to as a reverse link or reverse channel. The communication link may be established via a Single Input Single Output (SISO), multiple Input Single Output (MISO), single Input Multiple Output (SIMO), or Multiple Input Multiple Output (MIMO) system.

The AP 104 may act as a base station and provide wireless communication coverage in a Basic Service Area (BSA) 102. The AP 104 along with the STAs 106 associated with the AP 104 and communicating using the AP 104 may be referred to as a Basic Service Set (BSS). It should be noted that the wireless communication system 100 may not have a central AP 104, but rather may be used as a peer-to-peer network (such as TDLS, wiFi direct) between STAs 106. Accordingly, the functions of the AP 104 described herein may alternatively be performed by one or more STAs 106.

In some aspects, the STA 106 may associate with the AP 104 to send communications to the AP 104 or to receive communications from the AP 104. In one aspect, the information for association is included in a broadcast by the AP 104. To receive such broadcasts, for example, the STA 106 may perform a wide coverage search over a coverage area. The search may also be performed by the STA 106 by sweeping the coverage area in a lighthouse fashion, for example. After receiving the information for association, the STA 106 may transmit a reference signal, such as an association probe or request, to the AP 104. In some aspects, the AP 104 may use backhaul services to communicate with, for example, a larger network, such as the internet or a Public Switched Telephone Network (PSTN). In some aspects, a STA 106 may already be associated with an AP 104 and may periodically monitor communications from the AP 104 for communications directed to the STA 106.

In some implementations, one or more STAs 106 in the BSA 102 may include multiple radios. For example, the STAs may include a "primary" radio for performing communications within the wireless communication system 100, and a low power radio or "wake-up radio (WUR)" for monitoring "wake-up" or similar low power communications from the AP 104 when the STA 106 is in a low power or power saving mode. In some implementations, the STA 106 may include only WUR radios. In some implementations, a STA may include more than one primary radio, where each primary radio may operate in a different frequency band (such as 2.4, 5, 6, 18, and 60 GHz) or with different wireless technologies (such as LTE, bluetooth, and 802.11). The STA 106 including WUR radio may be designated as WUR STA. WUR may be a transmitter and receiver circuit with minimal capability to communicate over communication system 100, such as minimal compatibility with communication frequency and speed. In some implementations, WUR may include fewer features than the primary radio, such as lack of advanced encoder/decoder capabilities, and so forth. Accordingly, WUR may be lower in cost than the primary radio and may also consume less power than the primary radio when operating. Thus, WUR can be used to more efficiently monitor communications to a STA than a primary radio using the STA. In some cases, WUR radios may operate in different channels/bands than the one or more primary radios. WUR may be configured to receive instructions from AP 104 (or other devices broadcasting on wireless communication system 100). These instructions may include instructions to "wake up" the primary radio or perform other actions that do not activate the primary radio.

In some implementations, the AP 104 and STAs 106 may be configured to generate various WUR communications for WUR devices. For example, the AP 104 and STAs 106 may be configured to synchronize devices based on WUR beacon transmissions. Additionally or alternatively, the AP 104 and STAs 106 may transmit unicast WUR messages to wake up a single WUR STA, or multicast/broadcast WUR messages to wake up multiple or all WUR STAs. The AP 104 and STA 106 may be configured to generate and transmit WUR beacon frames/messages, WUR control frames/messages, and the like. Similarly, WUR STAs may be configured to perform various operations based on received WUR communications. For example, WUR STAs may synchronize based on WUR beacon reception including timing information, wake up based on individual or multicast/broadcast wake up messages, activate lights or perform actions, and so forth.

WUR communications may generally be based on conventional IEEE 802.11 communication structures. For example, the communication frame may include a preamble, addressing information, control information, and frame check information. However, IEEE 802.11 communication structures, such as WUR Physical Layer Convergence Procedure (PLCP) protocol data unit (PPDU), may be customized for WUR communications to reduce or minimize overhead and maintain signaling of necessary information to enable various operations. In some implementations, WUR PPDUs may provide flexibility for a wide range of use cases and scenarios.

Fig. 2 illustrates various components available in a wireless device 202 that may be employed within the wireless communication system 100 of fig. 1. Wireless device 202 is an example of a device that may be configured to implement the various methods described herein and may conform to the IEEE 802.11ba standard. The wireless device 202 may implement a WUR AP or WUR STA. In some implementations, the wireless device 202 may implement the AP 104 or the STA 106.

The wireless device 202 may include a processor 204 that controls the operation of the wireless device 202. The processor 204 may also be referred to as a Central Processing Unit (CPU). Memory 206, which may include both Read Only Memory (ROM) and Random Access Memory (RAM), provides instructions and data to processor 204. A portion of the memory 206 may also include non-volatile random access memory (NVRAM). The processor 204 may perform logical and arithmetic operations based on program instructions stored within the memory 206. The instructions in memory 206 may be executable to implement the methods described herein.

The processor 204 may include or be a component of a processing system implemented with one or more processors. The one or more processors may be implemented with any combination of general purpose microprocessors, microcontrollers, digital Signal Processors (DSPs), field Programmable Gate Arrays (FPGAs), programmable Logic Devices (PLDs), controllers, state machines, gating logic, discrete hardware components, dedicated hardware finite state machines, or any other suitable entity capable of performing algorithms or other manipulations of information.

The processing system may also include a machine-readable medium for storing the software. Software should be construed broadly to mean any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The instructions may include code (such as in a source code format, a binary code format, an executable code format, or any other suitable code format). The instructions, when executed by the one or more processors, cause the processing system to perform the various functions described herein.

The wireless device 202 may also include a housing 208, which housing 208 may include a transmitter 210 and a receiver 212 to allow transmission and reception of data between the wireless device 202 and a remote location or device. The transmitter 210 and the receiver 212 may be combined into a transceiver 214. A single or multiple transceiver antennas 216 may be attached to the housing 208 and electrically coupled to the transceiver 214. The wireless device 202 may also include a plurality of transmitters (such as WUR transmitter 224), a plurality of receivers (such as WUR receiver 226), and a plurality of transceivers (such as WUR transceiver 228). The transceiver 214 and WUR transceiver 228 may also operate as interfaces (also referred to as network interfaces) to communicate with other devices in the network.

The wireless device 202 may also include a signal detector 218 that may be used to attempt to detect and quantify the level of signals received by the transceiver 214 or the transceiver 228. The signal detector 218 may detect signals such as total energy, energy per subcarrier per symbol, power spectral density, and other signals. The wireless device 202 may also include a Digital Signal Processor (DSP) 220 for use in processing signals. In some aspects, the wireless device may also include a user interface component (not shown) and a Wireless LAN (WLAN) modem (not shown). The WLAN modem may provide for communication using one or more WiFi technologies, such as any of the IEEE 802.11 protocol standards.

The various components of the wireless device 202 may be coupled together by a bus system 222, which bus system 222 may include a power bus, a control signal bus, and a status signal bus in addition to a data bus.

Certain aspects of the present disclosure support the transmission of Uplink (UL) signals or Downlink (DL) signals between one or more STAs, WUR STAs, APs, and WUR APs. In some implementations, these signals may be transmitted in a multi-user MIMO (MU-MIMO) system. Alternatively, the signals may be transmitted in a multi-user FDMA (MU-FDMA) or similar FDMA system. In some aspects, these signals may be transmitted using one or more of the transmitter 210 and WUR transmitter 224.

In some implementations, WUR transmitter 224, WUR receiver 226, and WUR transceiver 228 may be configured to communicate with limited or minimal power consumption. Accordingly, WUR transmitter 224, WUR receiver 226, and WUR transceiver 228 may be limited to operating at a particular frequency or bandwidth. For example, WUR transmitter 224, WUR receiver 226, and WUR transceiver 228 may be configured to operate at one of the 900MHz, 2.4GHz, 5.0GHz, 6GHz, 18GHz, or 60GHz bands, at speeds of 62.5Kbps or 250Kbps, but are not limited to these frequencies or speeds. In some implementations, WUR devices may be limited to operating in the frequently utilized industrial, scientific, and medical (ISM) radio bands. Based on such speeds and limitations, transferring even a limited number of bytes can take a significant amount of time. As an example, assuming a speed of 62.5kbps, transmitting seven (7) bytes of information may utilize approximately 1ms transmission time.

Further, WUR devices (such as WUR APs and WUR STAs) may be configured such that the corresponding radio system operates in one of four states at any given time. For example, in the first state, both WUR transceiver 228 and transceiver 214 are off. In the second state, WUR transceiver 228 is on and transceiver 214 is off. In the third state, WUR transceiver 228 is off and transceiver 214 is on. In the fourth state, both are on. And the number of states may increase in proportion to the number of primary radios (which may be greater than one). WUR transmitters 224, WUR receivers 226, WUR transceivers 228, transmitters 210, receivers 212, and transceivers 214 may share the same antenna or antennas 216 and may operate in the same frequency band or may operate in separate frequency bands. Accordingly, the corresponding WUR component and the "primary radio" component may be configured to operate only one component at a time such that only WUR communications or primary radio communications are being transmitted/received at any given time. In some implementations, when the device 202 includes multiple antennas 216 coupled to the WUR transmitter 224, WUR receiver 226, WUR transceiver 228, transmitter 210, receiver 212, and transceiver 214, the processor 204 may be configured to dedicate one or more antennas 216 to the WUR transmitter 224, WUR receiver 226, and WUR transceiver 228, and one or more remaining 216 antennas to the transmitter 210, receiver 212, and transceiver 214 to allow simultaneous WUR and primary channel communications. The STA may also turn off WUR radios and assign all antennas to the primary radio.

Although several separate components are illustrated in fig. 2, one skilled in the art will recognize that one or more of these components may be combined or implemented together. For example, the processor 204 may be used to implement not only the functionality described above with respect to the processor 204, but also the functionality described above with respect to the signal detector 218 or DSP 220. Furthermore, each component illustrated in fig. 2 may be implemented using a plurality of separate elements. Additionally, additional components not illustrated in fig. 2 may be included in any of the devices 202.

The wireless device 202 may include an AP 104 or STA 106 and may be used to transmit or receive communications. That is, the AP 104 or STA 106 may act as a transmitting or receiving device. Certain aspects contemplate that the signal detector 218 is used by software running on the memory 206 and the processor 204 to detect the presence of a transmitter or receiver.

Fig. 3 illustrates an example structure of a PPDU 300 for communicating with WUR device 202 (fig. 2). The four portions of the illustrated PPDU 300 are a PHY preamble 310 portion, a Medium Access Control (MAC) header 320 portion, a payload or frame body portion 330 (payload or frame body portion 330 may be used interchangeably), and a Frame Check Sequence (FCS) 340 portion. PHY preamble 310 is a portion of a PPDU 300 preamble, and the PHY preamble 310 contains information for decoding the one or more PLCP Service Data Units (PSDUs) or MAC Protocol Data Units (MPDUs) 302 contained in the PPDU 300. More than one PDSU or MPDU may be included in a PPDU transmitted in MU mode (such as using OFDMA multiplexing techniques). MPDU 302 of PPDU 300 may include one or more of the following: a MAC header 320, a payload or frame body portion 330, and an FCS 340. The MAC header 320 may include one or more common fields present in all WUR frames or PPDUs 300. The payload or frame body portion 330 may include one or more frame type specific fields that may be present in the selected PPDU 300 (such as based on the type of PPDU 300). In some implementations, the payload or frame body portion 330 may be optional in the PPDU 300, e.g., based on the type of WUR frame or based on an indication contained in the WUR frame. In some implementations, FCS 340 may be used to detect whether MPDU 302 contains any errors or whether MPDU 302 is generated from an access point of an overlapping BSS. FCS 340 may include a Cyclic Redundancy Check (CRC) or message integrity check (such as a CRC may be present if the frame is unsafe and a MIC may be present if the frame is safe) depending on the type of PPDU 300 received. FCS 340 may be 8 bits, 16 bits, or any other number of bits in length and may contain one or more bits of CRC-8, CRC-16, or CRC-32. For example, FCS 340 may carry a CRC having a length of 8 bits, 16 bits, 24 bits, or 32 bits when communicated without a protected frame. In some implementations, FCS 340 may have a variable length. For example, the size of FCS 340 may depend on whether the WUR frame is protected (such as whether the WUR frame contains a CRC or a MIC). In some implementations, the size of FCS 340 may depend on the type of WUR frame. In some implementations, the MAC header 320 and FCS 340 constitute a minimum WUR frame format and are present in all WUR frames (including reservation type frames). In some implementations, FCS 340 may include a Message Integrity Check (MIC), which may be calculated in a similar manner as the CRC described herein. Accordingly, CRCs as described herein may be replaced with MICs.

The size of FCS 340 may directly affect the false alarm probability generated by the corresponding MPDU 302. For example, a smaller FCS size may cause or result in a STA 106 receiving a frame containing the FCS 340 and MPDU 302 to erroneously interpret the MPDU 302 as being directed to the STA 106 even if the MPDU 302 contains errors or is generated by an AP 104 from an overlapping BSS. However, FCS 340 having a smaller size (such as a smaller number of bits) than larger FCS 340 may cause or result in a smaller (or reduced or smaller) overhead than the larger FCS 340 (such as a larger number of bits). This smaller or reduced overhead may be beneficial for short frames (such as constant length frames). For example, the smallest possible MPDU 302 may have a length of 32 bits (4 bytes), such as a constant length WUR frame, as will be discussed in further detail below. In some implementations, MPDU 302 may be up to 12 or 30 bytes in length (such as variable length WUR frames), as will be discussed in further detail below. FCS 340 length may be appended to MPDU 302 length. For example, when the WUR frame includes the FCS 340 having a length of 8 bits and the MPDU having a length of 32 bits, the FCS 340 may constitute 20% overhead. In contrast, for a WUR frame that includes MPDUs 302 having a length of 12 bytes and FCS 340 having a length of 8 bits, FCS 340 constitutes only 8.3% of the overhead of the WUR frame. Accordingly, in some implementations, a shorter FCS 340 may be implemented when overhead is more of a concern than potential false alarms. Longer FCS 340 may be implemented with less overhead concerns than potential false alarms.

In some implementations, a CRC may use a polynomial generator that generates one or more polynomials for the CRC. For example, the polynomial generator may generate a 32-bit polynomial. In some implementations, the 32-bit polynomial is used for CRC to provide baseline MPDU protection. In such implementations, the generator polynomial may be identified by equation 1 below:

formula 1: g (x) =x ³² +x ²⁶ +x ²³ +x ²² +x ¹⁶ +x ¹² +x ¹¹ +x ¹⁰ +x ⁸ +x ⁷ +x ⁵ +x ⁴ +x ² +x+1

In some implementations, the polynomial generator may generate a 16-bit polynomial. In some implementations, the 16-bit polynomial is used for the CRC of the SIG field of the DSSS PHY. In such implementations, the generator polynomial may be identified by equation 2 below:

formula 2: g (x) =x ¹⁶ +x ¹² +x ⁵ +1

In some implementations, the polynomial generator may generate an 8-bit polynomial. In some implementations, the 8-bit polynomial is used for CRC of MPDU delimiters. In such an implementation, the generator polynomial may be identified by equation 3 below:

formula 3: g (x) =x ⁸ +x ² +x+1

Since the WUR radio may be a secondary radio for waking up or activating a primary or primary radio, in some implementations, the polynomial used by the WUR radio may be the same as the polynomial used by the primary or primary radio. By using the same polynomial between WUR radio and primary or main radio, overall cost and design complexity can be reduced. Any of the 8, 16, or 32 bit polynomials may be implemented, wherein higher order polynomials may give better protection against false positives caused by a CRC. Higher order polynomials may also result in the use of longer FCS 340 (such as causing increased overhead and utilizing increased memory).

Various options may provide reduced overhead while achieving higher order polynomial protection. For example, in some implementations, only a portion of the calculated CRC may be transmitted or included in FCS 340, allowing higher order CRC polynomials to be used without a corresponding high overhead. In some implementations, FCS 340 may have an 8-bit length and include only 8 bits of the calculated CRC-16, such as including only the 8 Most Significant Bits (MSBs) or the 8 Least Significant Bits (LSBs), and exclude the remaining 8 bits of CRC-16. Similarly, in some implementations, FCS 340 may have an 8-bit length and include only 8 bits of calculated CRC-32, may have a 16-bit length and include only 16 bits of calculated CRC-16, may have an 8-bit length and include only 8 bits of calculated CRC-8, and so on. Accordingly, the STA 106 that receives the WUR frame may perform a frame check based on CRC bits (which may be less than the calculated bits) transmitted in the FCS 340.

In a first example, a constant length WUR frame may include an 8-bit length FCS 340, while a variable length WUR frame may include an 8-bit length FCS 340 and additional 8 bits of CRC-16 (such as the last 8 bits of frame body 330) contained in frame body 330. WUR frames may be shorter and susceptible to overhead for constant length frames than variable length frames, where WUR frames are longer and less susceptible or less susceptible to increased overhead. Although CRC-16 is described for a WUR frame, any CRC polynomial described herein may be used. However, if the polynomial order is smaller than the FCS 340 length (such as 16 bits for CRC-8 for FCS 340 length), a supplement (repetition) or padding may be applied to the CRC included in FCS 340. With this supplementation, the calculated bits of the CRC may be repeated in an FCS having a length greater than the calculated bits of the CRC.

For constant length WUR frames, 8 bits of FCS 340 may carry 8 MSBs of CRC-16, while 8 LSBs of CRC-16 may be freed from transmission. Accordingly, a receiver that receives a constant length WUR frame may perform frame check on only the received 8 bits. For variable length WUR frames, 8 LSBs omitted from FCS 340 may instead be included or carried in frame body 330. Accordingly, a receiver that receives the variable length WUR frame may perform frame check on the received 16 bits. Thus, longer frames (such as variable length WUR frames) may be provided with more protection.

Note that in this example, the calculated fields (such as the fields that the CRC is protecting) include all fields of the WUR frame up to the FCS 340 but not the FCS 340 itself.

In a second example, the 8-bit FCS 340 of the variable length WUR frame may protect the same portions of the MPDU 302 (such as all portions except the frame body 330) as the FCS 340 protects in the constant length WUR frame. The 8 bits of the CRC included in frame body 330 may protect the contents of frame body 330 except for the portion of frame body 330 that includes the remainder of CRC-16 (such as the frame body 330 length minus 8 bits for the remainder of CRC-16).

As depicted in fig. 3, the MAC header 320 may include one or more of the following three separate fields: a frame control field 321, a partial Basic Service Set Identifier (BSSID) field 322, and a timestamp field 322. Each of the frame control field 321, the partial BSSID field 322, and the timestamp field 322 may have a length of one (1) byte or octet. In some implementations, some portion of the content of the frame control field may be carried in the PHY preamble of the WUR PPDU.

The 1-byte frame control field 321 may provide information identifying details of the type and length of MPDU 302. In some implementations, the frame control field 321 may include a type subfield (not shown) and a length/subtype field (not shown). The type subfield may be configured to identify the frame type of PPDU 300. In some implementations, the type subfield may indicate that PPDU 300 is a WUR beacon frame, a WUR control frame, a WUR sync frame, and so forth. In some implementations, frame control may indicate whether the frame is a secure/protected frame or an unsecure/unprotected frame (MIC present or CRC present). For example, a first value in the type subfield may indicate a WUR beacon frame, while a second value in the type subfield may indicate a WUR control frame. In some implementations, the frame type indicated by the type subfield may help distinguish between a constant length PPDU 300 and a variable length PPDU 300. The length/subtype field may provide information indicating one or both of the following: different frame sub-types of PPDU 300, or different payload or frame body sizes of its payload or frame body portion 330. In some implementations, as will be described in more detail below, the payload or frame body portion 330 may be integrated with the MAC header portion 320, and the length of the payload or frame body portion 330 may not be indicated in the length/subtype subfield of the frame control field 321, but rather the length of the MAC header, MPDU, or variable portion of the MPDU may be indicated by the length specified in the frame control field. When included, the length may provide the length of the variable length frame. Alternatively or additionally, the subtype field may provide additional details of the subtype of the constant length frame. In some implementations, the frame control field 321 may be moved to the PHY preamble 310 and may be part of the SIG field of the PHY preamble or encoded in the PHY preamble itself.

In some implementations, the constant length frames may not include a payload or frame body portion 330. WUR frames that include a payload or frame body portion 330 may be referred to as Variable Length (VL) WUR frames. In some implementations, constant length WUR frames may be transmitted to any WUR STA, while variable length WUR frames may be transmitted to WUR STAs that have been declared to support reception of variable length WUR frames.

A partial BSSID field 322 (which may optionally be present and may be 1 byte) may provide an identification of the identity (such as an ID) of the transmitting BSS. The transmitting BSS may correspond to a BSS from which WUR communications are transmitted. For example, the partial BSSID field 322 may include a partial address or identifier of the AP 104 or STA 106 transmitting the PPDU 300. In some implementations, the recipient WUR STA may use the partial BSSID field (and the information contained therein) to determine whether the WUR STA is a potential intended recipient of the PPDU 300. For example, during association with the AP 104 or the wireless communication system 100, a WUR STA may be assigned or provided with a BSSID of a BSS (such as the BSS in BSA 102) to which the WUR STA belongs. Accordingly, WUR STAs may store the BSSID of their BSSs in their memory (such as memory 206 of fig. 2). When the WUR STA compares the partial BSSID 322 with the stored BSSID, if the values match, the WUR STA may determine that the received acknowledgement of the PPDU 300 is applied to the WUR STA and perform additional checks as described below. However, if the partial BSSID 322 does not match the stored BSSID of the WUR STA, the WUR STA may determine that the received PPDU 300 is not applied to the WUR STA and may ignore the remaining portion of the PPDU 300. Accordingly, the partial BSSID field 322 may be used to reduce the computation, processing, and reception of the PPDU 300 by WUR STAs that do not need to be concerned with the PPDU 300. In some implementations, the partial BSSID may be a value known by both the AP and the STA that may vary over time according to a function known by both the AP and the STA, such as a random generator with a seed known at both devices.

In some implementations, the partial BSSID 322 field may include only one octet of the BSSID of the transmitting device. In some implementations, a single octet of the BSSID (such as a partial BSSID) is sufficient to provide adequate intra-PPDU power savings and discard PPDUs transmitted by other BSSs (APs) as compared to the increased cost (such as time, bandwidth, etc.) of transmitting and processing the full BSSID. Accordingly, the partial BSSID field 322 may provide reduced accuracy in identifying whether WUR STAs belong to the same or different BSS as the transmitting AP 104 or STA 106 while providing reduced communication costs (such as time, bandwidth, etc.). Additionally, the partial BSSID field 322 may be used in some implementations to minimize false alarms in FCS, as discussed in further detail below.

The timestamp field 323 (which may be 1 byte or 2 bytes in length if present) may contain a partial Timing Synchronization Function (TSF). The partial TSF may allow WUR STAs to synchronize their clocks to match the clocks of the transmitting AP 104. The partial TSF may also allow WUR STAs to prevent and avoid replay attacks, as will be described in further detail below.

Fig. 4 illustrates further details of an example structure of the PPDU 300 of fig. 3 for communication with WUR device 202 of fig. 2. As depicted in fig. 4, the payload or frame body portion 330 may include two separate fields: a paged ID field 331 and a control/miscellaneous instruction field 332. The paged ID field 331 may have a variable byte or octet length, while the control/miscellaneous instruction field 332 may have a length of 1 byte or octet. In some implementations, at least one of the paged ID field(s) 331 and the control/miscellaneous instruction field 332 may be part of the MAC header 320.

The paged ID field 331 (which may have one or more paged IDs, each of which may be 1 byte in length) may provide a payload or frame body or a list of intended recipient WUR STAs of the PPDU 300. In some implementations, the paged ID field 331 may include identifiers, where each identifier may identify one STA, or be assigned to a group of WUR STAs, or all WUR STAs associated with the device transmitting the PPDU 300. The paged ID field 331 may be used in conjunction with the partial BSSID field 322 of fig. 3. For example, when a WUR STA determines that the partial BSSID field 322 matches the BSSID of the WUR STA, the WUR STA may proceed to confirm that the ID of the WUR STA is included in the paged ID field 331. When the WUR STA's ID is not included in the paged ID field 331, the WUR STA may stop receiving the PPDU 300 and may ignore any received information. On the other hand, if the ID of the WUR STA is included in the paged ID field 331, the WUR STA proceeds to receive the remaining portion of the PPDU 300 and follows any instructions included in the PPDU 300. In some implementations, each paged ID in paged ID field 331 may be mixed with a known portion of the identifier of the BSS, such as exclusive or (XOR) with a particular 8 bits of the BSSID, such that the paged ID values are not concentrated in a particular portion of range (such as a higher likelihood that multiple APs assign low values, such as 1, 2, etc., if all APs 104 begin to assign IDs in ascending order). If the AP 104 applies this rule, the paged ID value may extend evenly across the range of 1-255. In some implementations, the APs 104 may use a random generator to select the paged IDs that these APs 104 assign to their STAs, and the selected paged IDs may be known by all APs within range such that the paged IDs assigned by the APs 104 in the same area do not coincide.

In some implementations, the paged ID field 331 may have a length of one byte. In the case of one byte length, the paged ID field 331 may indicate or identify a single WUR STA to which or associated with the PPDU 300 is applied. The paged ID field 331 may have a size of up to 16 bytes, allowing the PPDU 300 to be applied to or associated with up to 16 different WUR STAs. In some implementations, the length subfield of the frame control field 321 may indicate the number of WUR STAs identified by the paged ID field 331 and, accordingly, the number of bytes of the paged ID field 331. In some implementations, when the length subfield is zero (0), it may be expected that PPDU 300 is a broadcast or multicast PPDU that is applied to all WUR STAs or to all WUR STAs that share the BSSID of the partial BBSID field 322. In such implementations, the paged ID field 331 may have a length of zero and may not include any WUR STA identifiers. In some implementations, when the length subfield is 0 for the broadcast PPDU, the paged ID field 331 may have a length of one (1) byte without including any WUR STA identifier (e.g., may have a value of zero, indicating that the frame is broadcast).

The 1-byte length paged ID subfield 331 may be used to identify up to 256 unique STA identifiers (or up to 255 unique STA identifiers if a value of 0 is used for broadcast) (up to 1024 unique STA identifiers if the paged ID is 11 bits, and so on). However, if the AP 104 serves more than 256 STAs, the AP 104 may be configured to schedule STAs sharing the same paged ID orthogonally. If the paged ID is obtained from an Association Identifier (AID) (such as 8 LSBs of the AID providing the paged ID), the AP may use one or more of the remaining MSBs of the AID to make such a schedule. For example, STAs with associated identifiers "1" and "257" may share the LSB as 0000 0001. Accordingly, if paged ID field 331 identifies an STA with an identifier 0000 0001, both STA "1" and STA "257" will determine that PPDU 300 is intended for that STA based on both partial BSSID field 321 and paged ID field 331. Accordingly, STA "1" and STA "257" may be considered "clones". During association of STA "1" and STA "257", AP 104 may schedule each clone to have orthogonal awake times or be allocated in an orthogonal group. For example, STA "1" may be provided with scheduled wake times and wake time durations (SPs) during association such that they do not coincide with the scheduled wake times and wake time durations of STA 257 (such as STA1 may be scheduled for the first 10ms of a 20ms wake time duration and STA 257 may be scheduled for the second 20ms of the wake time duration). Accordingly, cloned STAs (such as WUR STAs having the same LSB identifier or i.e., paged ID) will not wake up at the same time, and unintended WUR STAs will not wake up only because they share the same LSB identifier or i.e., paged ID as intended WUR STAs.

Alternatively or additionally, the Most Significant Bit (MSB) of the identifier for the paged ID may be masked in one or more other fields of the PPDU 300 or MPDU 302. For example, the paged ID in the paged ID field 331 may be associated with one group MSB to four groups MSB. For example, for STA "1" and STA "257", STAs will be associated with both groups of MSBs. STA "1" will be associated with MSB "0" and STA "257" will be associated with MSB "1". Accordingly, the MSB identifier may be communicated to the WUR STA to allow the WUR STA to determine whether the PPDU is intended for the WUR STA or for another WUR STA having the same LSB identifier in the paged ID field 331.

In some implementations, the AP 104 may desire to send instructions or pages to more than 16 WUR STAs. In such implementations, the AP 104 may transmit a multicast or broadcast PPDU 300 (e.g., having a length of 0, as described herein). Alternatively or additionally, the AP 104 may transmit a proximate (continuous) WUR PPDU 300. When multiple PPDUs 300 are transmitted in close proximity, the AP 104 may include STA identifiers in the paged ID field 331 in ascending order only, which may allow STAs to know when they will not be paged later in the PPDU 300. For example, when a previous PPDU 300 of the two or more immediate PPDUs 300 includes a paged ID for WUR STAs 1, 3, and 8, WUR STA 5 may know that a subsequent PPDU 300 of the two or more immediate PPDUs 300 will not page STA 5 because the lowest WUR STA that can be paged by the subsequent PPDU 300 is 9 (e.g., STA identifier only rises between PPDUs). This ascending order may allow WUR STAs to optimize their sleep mode by determining when they will not be paged without having to wait to receive and consult all of the immediate PPDUs 300. In some implementations, one or more bits may be included in MPDU 302 to indicate that a sequence of one or more other PPDUs 300 is following the current PPDU 300.

The control/miscellaneous instruction field 332 may include one or more instructions for one or more paged IDs identified in the paged ID field 331. In some implementations, the control/miscellaneous instruction field 332 may provide special instructions for WUR STA(s) to execute once they are awake. In some implementations, the control/miscellaneous instruction field 332 may include a special command if the PPDU 300 is used to control an external state. In some implementations, a special command may instruct which primary radio to turn on (such as by identifying a radio number, technology, or frequency band). In some implementations, a special command may indicate which wideband to use or may specify one or more reception or transmission parameters.

In some implementations, the one or more control/miscellaneous instruction fields 332 may be common to all identified WUR STAs in the paged ID field 331. In some implementations, one or more identified WUR STAs in the paged ID field 331 may have instructions that are unique compared to other identified WUR STAs in the paged ID field 331. Association of WUR STAs with particular control instructions may be identified in a frame control field 321 (e.g., length subfield). For example, the length subfield may indicate that each identified WUR STA has a corresponding control instruction field. In this implementation, the length subfield may provide the length of both the paged ID and the control ID (such as the unit of the length subfield may be 2 bytes, since one paged ID may be one byte and one control ID one byte), and the length may have a range between 2 and 14 bytes. Other lengths of the length subfield in the frame control field 321 may be used (such as 3 or 4 or more).

In some implementations, the two-byte paged ID and control field may include a combination of AID identifier bits and control/miscellaneous instruction bits. For example, the two-byte paged ID and control field may include 12 AID identifier bits and 4 control/miscellaneous instruction bits. In some implementations, the combination may be 8 AID identifier bits and 8 control/miscellaneous instruction bits. In some implementations, various combinations of AID identifier bits and control/miscellaneous instruction bits are negotiated in advance between the AP 104 and WUR STAs. In some implementations, the combination of AID identifier bits and control/miscellaneous instruction bits may be vendor specific (such as different vendors may have different numbers of AID identifier bits and different numbers of control/miscellaneous instruction bits, etc.).

In some implementations, commands or instructions associated with the control/miscellaneous instruction bits may be negotiated in advance between the AP 104 and WUR STAs. For example, these bits and corresponding instructions may be negotiated during association of the WUR STA with the AP 104. For example, control/miscellaneous instruction bits may be stored in a table type format, where each bit corresponds to a particular action, command, or instruction.

Fig. 5 illustrates further details of an example structure of the PPDU 300 of fig. 3 for communication with WUR device 202 of fig. 2. As depicted in fig. 5, FCS 340 may be a two byte portion that includes a Cyclic Redundancy Check (CRC) or a Message Integrity Check (MIC). The CRC may be used to detect errors in the unsafe PPDU 300. The MIC may be used to detect errors and replay attacks in the secure PPDU 300.

In some implementations, AP 104 may logically combine FCS 340 with portions or known sequences of the BSSID of AP 104 prior to transmitting PPDU 300. For example, AP 104 may exclusive-or the FCS with two LSBs of the 3 MSBs of the BSSID of AP 104. Since the BSSID of the AP 104 is known to the associated STA from the initial association procedure, a successful decoding may mean that the WUR STA is receiving the PPDU 300 generated by the AP 104 of the WUR STA when the FCS is decoded by the receiving WUR STA. For WUR STAs that belong to a different BSSID than the transmitting AP 104, the PPDU 300 may be decrypted as corrupted. In some implementations, the AP 104 may calculate the CRC and MIC assuming that the BSSID is present in the PPDU 300 (such as immediately after the FCS or before the FCS), and may refrain from transmitting (e.g., calculate but not transmit) the BSSID. The receiver, upon receiving the PPDU 300, may check the FCS or the MIC assuming the presence of the BSSID, such as the MAC address of the AP transmitting the PPDU 300.

In some implementations, the CRC/MIC field of FCS 340 may be used to ensure that WUR STAs are not awakened by PPDUs from aggressors or unfriendly APs 104. For example, a security protocol with low overhead may be used to avoid CCMP type signaling, where the MIC has 8 or 16 bytes and the CCMP header has 8 bytes. Accordingly, PPDU 300 or MPDU 302 may be unsafe when FCS 340 contains a CRC, and PPDU 300 or MPDU 302 may be safe when FCS 340 contains a MIC. In some implementations, the frame control field 321 may be used to signal whether to use a CRC or MIC for a particular PPDU 300 or MPDU 302.

In some implementations, MIC computation may be based on the entire MPDU 302. For example, MPDU 302 may be intended for a single WUR STA or multiple WUR STAs. In some implementations, the MIC is generated by the AP 104 based on a group key known to both the AP and the one or more WUR STAs. The group key may be known by all STAs associated with the AP 104 that are intended recipients of the PPDU 300. In some implementations, the timestamp field 323 may provide a portion of a monotonically increasing counter. For example, the absolute TSF timer at WUR STA may be updated based on the partial TSF of timestamp field 323. The absolute TSF timer may be used as an input parameter for MIC computation, which may be further used to protect WUR STAs from replay attacks.

In some implementations, MPDUs 302 may have a minimum length and a maximum length. The length may be signaled or determined based on the frame type of PPDU 300 (such as in frame control field 321, as described herein). For example, MPDU 302 may have a minimum length of six (6) bytes. MPDU 302 may include one or more of the following fields: a 1 byte frame control field 321, a 1 byte partial BSSID field 322, a 1 byte timestamp field 323, a control/miscellaneous instruction field 322, and a 2 byte CRC/MIC field 341. In some implementations, as described above, MPDU 302 may have a minimum length of seven (7) bytes when frame control field 321 indicates no length (such as no paged ID) but includes a paged ID field 331 therein having a length of 1 byte but a zero value. In some implementations, the constant length PPDU 300 may have a minimum MPDU 302 size of 6 or 7 bytes. The smallest size MPDU 302 may be transmitted at 62.5Kbps with a time of about 1 ms.

MPDU 302 may have a maximum length of twenty-two (22) bytes. For example, MPDU 302 may include the minimum 6 bytes described above, and then also 16 bytes for the 16 identifiers in paged ID field 331. Thus, the maximum length of MPDU 302 may be 6 bytes of the non-paged ID field plus a maximum of 16 bytes of the paged ID field 331. In some implementations, the variable length PPDU 300 may be signaled or determined based on the frame type and length in the frame control field 321. A maximum MPDU 302 length of 22 bytes may use a transmission time of about 3ms at 62.5 Kbps. In some implementations, MPDU 302 may have a length of any byte between 6 bytes and 22 bytes.

Fig. 6 illustrates another example structure of a PPDU 600 for communicating with WUR device 202 (fig. 2). The three parts of the illustrated PPDU 600 are a PHY preamble 610 part, a Medium Access Control (MAC) header 620 part, and an FCS 630 part. The PHY preamble 610 is a part of a preamble of the PPDU 600, and the PHY preamble 610 contains information for decoding one or more PSDUs or MPDUs 602 contained in the PPDU 600. More than one MPDU 602 may be included in a PPDU 600 transmitted in MU mode (such as using OFDMA multiplexing techniques). MPDU 602 included in PPDU 600 may include one or more of MAC header 620 and FCS 630. The MAC header 620 may include one or more common fields that are present in all PPDUs 600, as compared to the MAC header 320, or it may include one or more type-specific fields that may not be present in each WUR PPDU 600. Accordingly, in some implementations, the content of the MAC header 620 may depend on the type of WUR PPDU frame in which the MAC header 620 is included. FCS 630 may include a Cyclic Redundancy Check (CRC) or a Message Integrity Check (MIC) depending on the type of WUR PPDU frame received (such as a CRC may be present if PPDU 600 is not secure and a MIC may be present if PPDU 600 is secure). No payload or frame body portion is present in PPDU 600 because PPDU frames do not carry any payload and type-specific fields may not be included in the MAC header 620 portion. Other aspects of communicating PPDU 600 (such as speed, frequency band, etc.) may be similar to those described above with respect to fig. 3 and PPDU 300.

As depicted in fig. 6, the MAC header 620 may include one or more of the following four separate fields: a frame control field 621, a paged ID (RA) field 622, a partial BSSID (TA) field 623, and a timestamp field 624. The frame control field 321 may have a length of one (1) byte or octet. The paged ID (RA) field 622, partial BSSID (TA) field 623, and timestamp field 624 may have lengths that are not fully established but rather estimated, as described below. In some implementations, some portion of the content of the frame control field 621 may be carried in the PHY preamble of the PPDU 600.

The 1-byte frame control field 621 may provide information identifying details of at least one of the MPDU 602 type and length. In some implementations, the frame control field 621 may include a one-bit protocol version field (not shown) in which zero (0) is currently used and one (1) is saved for future development. The frame control field 621 also includes a type subfield of two-bit length. The type subfield (not shown) may identify the type of PPDU 600 frame. In some implementations, the type subfield may indicate that PPDU 600 is a WUR beacon frame, a WUR control frame, a WUR sync frame, and so forth. In some implementations, the frame control field 621 may indicate whether the PPDU 600 is a secure/protected PPDU 600 or an unsecure/unprotected PPDU 600 (such as the presence of a MIC or the presence of a CRC). For example, a first value in the type subfield may indicate a WUR beacon frame, while a second value in the type subfield may indicate a WUR control frame. In some implementations, the frame type indicated by the type subfield may help or may implicitly distinguish between the constant length PPDU 600 and the variable length PPDU 600. For example, WUR broadcast frames may be of constant length, while beacon frames or control frames may be of variable length. The length/subtype field (not shown) may be a 3-bit field that may provide information indicating one or both of the following: different frame subtypes of PPDU 600 and MPDU 602, or payload or frame body sizes thereof. In some implementations, as will be described in more detail below, the payload or frame body may be integrated with the MAC header portion 620. In some implementations, the length/subtype field may have a length of four bits. In some implementations, the length of the MAC header 620, or MPDU 602, or a variable portion of the MPDU may be indicated by a length specified in the frame control field 621. When included, the length may provide the length of the variable length frame. Alternatively or additionally, the subtype field may provide additional details of the subtype of the constant length frame. The frame control field 621 may further include two bits for future use (one or both of the two bits may be used for security purposes, as described in further detail below). In some implementations, the frame control field 621 may be moved to the PHY preamble 610 and may be part of the SIG field of the PHY preamble or encoded in the PHY preamble itself. The above possible decomposition of the frame control field 621 may also be applied to the frame control field 321 of fig. 3.

The partial BSSID field 623 (which may optionally have a pending (TBD) length)) may provide an identification of the identity, such as an ID, of the transmitting BSS. The transmitting BSS may correspond to a BSS from which WUR communications are transmitted. For example, the partial BSSID field 623 may include a partial address or identifier of the AP 104 or STA 106 transmitting the PPDU 600. In some implementations, the recipient WUR STA may use the partial BSSID field (and the information contained therein) to determine whether the WUR STA is a potential intended recipient of the PPDU 600. For example, during association with the AP 104 or the wireless communication system 100, a WUR STA may be assigned or provided with a BSSID of a BSS (such as the BSS in BSA 102) to which the WUR STA belongs. Accordingly, WUR STAs may store the BSSID of their BSSs in their memory (such as memory 206 of fig. 2). When a WUR STA compares the partial BSSID 623 with the stored BSSID, if the values match, the WUR STA may determine that the received PPDU 600 is indeed applied to the WUR STA and perform additional checks as described below. However, if the partial BSSID 623 does not match the stored BSSID of the WUR STA, the WUR STA may determine that the received PPDU 600 is not applied to the WUR STA and may ignore the remaining portion of the PPDU 600. Accordingly, the partial BSSID field 623 may be used to reduce the computation, processing, and reception of the PPDU 600 by WUR STAs that do not need to be concerned with the PPDU 600. In some implementations, the partial BSSID 623 may be a value known by both the AP 104 and WUR STA that varies over time according to a function known by both the AP 104 and WUR STA (such as a random generator with a seed known at both devices).

In some implementations, the partial BSSID 623 field may include only one octet of the BSSID of the transmitting device. In some implementations, a single octet of the BSSID (such as a partial BSSID) is sufficient to provide adequate intra-PPDU power savings and discard PPDUs 600 transmitted by other BSSs (APs) as compared to the increased cost (such as time, bandwidth, etc.) of transmitting and processing the full BSSID. Accordingly, the partial BSSID field 623 may provide reduced accuracy in identifying whether the WUR STA belongs to the same or a different BSS as the transmitting AP 104 or STA 106 while providing reduced communication costs (such as time, bandwidth, etc.). Additionally, in some implementations, the partial BSSID field 623 may be used in some implementations to minimize false alarms in FCS, as discussed in further detail below. Additionally or alternatively, a portion of the BSSID may be masked or hidden in another field of MPDU 602 (e.g., FCS 630). Additionally or alternatively, the paged ID may be scrambled or masked with a partial BSSID, as will be discussed in further detail below.

The timestamp field 624 (optionally having a pending length) may include a partial Timing Synchronization Function (TSF). The partial TSF may allow WUR STAs to synchronize their clocks to match the clocks of the transmitting AP 104. The partial TSF may also allow WUR STAs to prevent and avoid replay attacks, as will be described in further detail below. The timestamp field 624 may have a length of 1 byte. Alternatively or additionally, the timestamp field 624 may include a sequence number (such as the timestamp field 624 may be a timestamp/sequence number field 624). The sequence number may provide an alternative to the counter of the security frame and provide other purposes such as BSS parameter updates, etc. In some implementations, the timestamp field 624 may include change sequence information or control information. For example, the control information may be carried in the timestamp field 624 in the timestamp information (such as scrambled or masked) or before or after the timestamp information. In some implementations, if control information is desired for each paged ID, the paged ID field 622 may be followed by a control field (not shown). Thus, each paged ID may have a dedicated or shared control field. The control field may have a variable length based on at least one of the control information and the number of paged IDs. In some implementations, the control field may provide special signaling to one or more WUR STAs. For example, the control information may include an application layer command. Alternatively or additionally, the control information may include an indication of which WUR STAs to turn on their primary radio or which of the dual/tri-band radios to turn on or which antennas of the multi-antenna STA to activate. In some implementations, the control field application may depend on the type of PPDU 600. In some implementations, a special command may instruct which primary radio to turn on (such as by identifying a radio number, technology, or frequency band). In some implementations, a special command may indicate which bandwidth to use or may specify one or more reception or transmission parameters.

In some implementations, the control information may be common to all identified WUR STAs in the paged ID field 621. In some implementations, one or more identified WUR STAs in the paged ID field 621 may have instructions that are unique compared to other identified WUR STAs in the paged ID field 621. Association of WUR STAs with specific control instructions may be identified in a frame control field 621, such as a length subfield. For example, the length subfield may indicate that each identified WUR STA has a corresponding control instruction field. In some implementations, the length field may provide a length of both the paged ID and the control ID (in units of 2 bytes, as an example, because one paged ID may be one byte and the control ID may be another byte), and the length may have a range between 2 and 14 bytes.

In some implementations, commands or instructions associated with the control/miscellaneous instruction bits may be negotiated in advance between the AP 104 and WUR STAs. For example, the bits and corresponding instructions may be negotiated during association of the WUR STA with the AP 104. For example, control/miscellaneous instruction bits may be stored in a table type format, where each bit corresponds to a particular action, command, or instruction.

The paged ID field 622 (which may include one or more paged IDs, each of which may be 1 byte in length) may provide a list of the intended recipient WUR STAs of the payload or frame body of the WUR PPDU 600. In some implementations, the paged ID field 624 may include identifiers, where each identifier may identify one WUR STA, or be assigned to a group of WUR STAs, or all WUR STAs associated with the device transmitting the PPDU 600. The paged ID field 622 may be used in conjunction with the partial BSSID field 623 of fig. 6. For example, when a WUR STA determines that a partial BSSID field 622 (or a stored or retrieved BSSID from elsewhere, e.g., masked with FCS 630 or paging ID) matches the BSSID of the WUR STA, the WUR STA may proceed to confirm that the WUR STA's ID is included in the paging ID field 622. If the WUR STA's ID is not included in the paged ID field 331, the WUR STA may stop receiving the PPDU 600 and may ignore any received information. On the other hand, if the WUR STA's ID is included in the paged ID field 622, the WUR STA proceeds to receive the remainder of the PPDU 600 and follows any instructions included in the PPDU 600. In some implementations, each paged ID in the paged ID field 622 may be mixed, scrambled, encoded, or masked with a known portion of the identifier of the BSS of the AP 104 (such as exclusive or with a particular 8 bits of the BSSIDs of the AP 104 and WUR STAs) such that the paged ID values are not concentrated in a particular portion of the available ID range. For example, if all APs 104 begin to assign IDs in ascending order, the likelihood that multiple APs 104 assign low values (such as 1, 2, etc.) is high. If the AP 104 applies this rule, the paged ID value may extend evenly across the range of 1-255. In some implementations, the AP 104 may use a random generator to select the paged ID assigned to the associated STA. The random generator and the selected/assigned paged IDs may be known by all APs 104 within range such that the paged IDs assigned by the APs in the same area do not overlap or overlap.

In some implementations, the paged ID field 622 may have a length of one byte. In the case of one byte length, the paged ID field 622 may indicate or identify a single WUR STA to which or associated with the PPDU 600 applies. The paged ID field 622 may have a size of up to 8 bytes, allowing the PPDU 600 to be applied to or associated with up to 8 different WUR STAs. For example, when the length subfield in the frame control field 621 is 3 bits, only 8 paged IDs may be included. Thus, the length subfield of the frame control field 621 may indicate the number of WUR STAs identified by the paged ID field 622, and accordingly, the number of bytes of the length of the paged ID field 622 (maximum of 8). In some implementations, when the length subfield is zero (0), it is contemplated that PPDU 600 may be a broadcast or multicast PPDU that is applied to all WUR STAs or to all WUR STAs that share the BSSID of the partial BSSID field 622. In such implementations, the paged ID field 622 may have a length of zero and may not include any WUR STA identifiers. In some implementations, when the length subfield is 0 for a broadcast PPDU, the paged ID field 622 may have a length of one (1) byte without including any WUR STA identifiers (such as may have a value of zero, indicating that the PPDU is a broadcast PPDU). In some implementations, the paged ID field 622 is included in the multicast or broadcast PPDU 600. In some implementations, only a single paged ID may be present in the paged ID field 622 (1 byte in length) of the unicast PPDU 600.

The paged ID subfield 622 of 1 byte length may be used to identify up to 256 unique STA identifiers (or up to 255 unique STA identifiers if a value of 0 is used for broadcast). The number of STAs that can be identified depends on the size of the paged ID. For example, if the paged ID is 11 bits in length, the paged ID may be used to identify up to 1024 STAs (assuming value 0 is used for broadcast), and so on. However, if the AP 104 serves more than 256 STAs, the AP 104 may be configured to schedule STAs sharing the same paged ID orthogonally. If the paged ID is obtained from an Association Identifier (AID) (such as the 8 LSBs of the AID that provide the paged ID), the AP 104 may use one or more of the remaining MSBs of the AID to make such scheduling. For example, STAs with associated identifiers "1" and "257" may share the LSB as 0000 0001. Accordingly, if paged ID field 622 identifies a STA with an identifier 0000 0001, both STA "1" and STA "257" will determine that PPDU 600 is intended for that STA based on both partial BSSID field 623 and paged ID field 622. Accordingly, STA "1" and STA "257" may be considered "clones". During association of STA "1" with STA "257", AP 104 may schedule each clone to have orthogonal awake times or be allocated in an orthogonal group. For example, STA "1" may be provided with scheduled wake times and wake time durations (SPs) during association such that they do not coincide with the wake times and wake time durations of STA 257 (such as the first 10ms of a 20ms wake time duration may schedule STA1 and the second 10ms of a 20ms wake time duration may schedule STA 257). Accordingly, cloned STAs (such as WUR STAs having the same LSB identifier or paged ID) will not wake up at the same time, and unexpected WUR STAs will not wake up merely because they share the LSB identifier or paged ID with the intended WUR STAs.

Alternatively or additionally, the Most Significant Bit (MSB) of the identifier of the paged ID may be masked in one or more other fields of PPDU 600 or MPSU 602. For example, the paged ID in the paged ID field 622 may be associated with one group MSB to four groups MSB. For example, for STA "1" and STA "257", STAs will be associated with both groups of MSBs. STA "1" will be associated with MSB "0" and STA "257" will be associated with MSB "1". Accordingly, the MSB identifier may be communicated to the WUR STA to allow the WUR STA to determine whether the PPDU 600 is intended for the WUR STA or another WUR STA having the same LSB identifier in the paged ID field 622.

In some implementations, the AP 104 may desire to send instructions or pages to more than 8 WUR STAs. In such an implementation, the AP 104 may transmit a multicast or broadcast PPDU 600 (such as having a length of 0, as described herein). Alternatively or additionally, the AP 104 may transmit a proximate (such as continuous) PPDU 600. When multiple PPDUs 600 are transmitted in close proximity, the AP 104 may include STA identifiers in the paged ID field 622 in ascending order only, which may allow STAs to know when they will not be paged later in the PPDU 600. For example, when a previous PPDU 600 of the two or more immediate PPDUs 300 includes paged IDs for WUR STAs 1, 3, and 8, WUR STA 5 may know that a subsequent PPDU 600 of the two or more immediate PPDUs 600 will not page STA 5 because the lowest WUR STA that can be paged by the subsequent PPDU 600 is 9 (e.g., STA identifier only rises between PPDUs). This ascending order may allow WUR STAs to optimize their sleep mode by determining when they will not be paged without having to wait to receive and consult all of the immediate PPDUs 600. In some implementations, one or more bits may be included in MPDU 602 to indicate that a sequence of one or more other PPDUs 600 is following the current PPDU 600.

In some implementations, the paged ID field 622 is not included in the broadcast PPDU 600, as mentioned above. In such an implementation, each receiving WUR STA will decode PPDU 600 independent of the BSS of that WUR STA. Thus, in some implementations, the partial BSSID field 623 and the paged ID field 622 may be eliminated from the MAC header 620 (thereby further reducing the minimum MPDU 602 size to 3 bytes). In some implementations, one paged ID may be included in the paged ID field 622 of the broadcast frame. Accordingly, the AP 104 may assign a single WUR STA ID for inclusion in the paged ID field 622. In some implementations, the WUR STA may discard other BSSIDs. Additionally or alternatively, the AP 104 may scramble or mask a portion of the BSS identifier of the AP 104 with the paged ID included in the paged ID field 622. For example, the AP 104 may mask its BSSID (or a portion thereof, such as BSSID [40:47 ]) with a target paged ID as stored in the paged ID field 622. The receiving WUR STA may descramble the paged ID in the paged ID field 622 and determine if any of the obtained paged IDs match the identifier of the WUR STA or if the paged ID is a broadcast value (such as a paged ID value of 0). If the WUR STA determines that one of the descrambled paged IDs matches the WUR STA identifier or determines that a broadcast value is included, the WUR STA receives the remainder of the packet and performs additional actions. If the WUR STA determines that the descrambled paged ID does not match the WUR STA identifier and determines that the broadcast value is not included, the WUR STA may discard the PPDU 600.

Fig. 7 illustrates further details of an example structure of the PPDU 600 of fig. 6 for communicating with WUR device 202 (fig. 2). As depicted in fig. 7, FCS 630 (length pending) may include a Cyclic Redundancy Check (CRC) or a Message Integrity Check (MIC). The CRC may be used to detect errors in the unsafe PPDU 600. The MIC may be used to detect errors and replay attacks in the secure PPDU 600. In some implementations, no explicit CRC may be required for PPDU 600.

In some implementations, the AP 104 may conceal, scramble, or mask a portion of its BSSID in the FCS 630. Such scrambling or concealment may be performed using various methods. For example, the AP 104 may exclusive-or its portion of the BSSID (such as BSSID [23:38 ]) with the FCS 630. Accordingly, WUR STAs will only successfully decode the received PPDU 600 generated by their AP 104, since only those WUR STAs will have the proper BSSID value to successfully decode the FCS 630. PPDUs generated by other APs 104 will be decoded as corrupted because incorrect BSSID decoder values will result in incorrect FCS 630. By using such scrambling or encoding methods, portions of the BSSID may not need to be included as separate fields, thereby saving communication time, power, and bandwidth. In some implementations, FCS field 630 may have a length of 2 bytes, which may provide better security and protection, fewer false alarms, and better protection against replay attacks. In some implementations, AP 104 may calculate a CRC and MIC assuming that the BSSID of AP 104 is present in PPDU 600 (such as immediately after or before the FCS), and refrain from transmitting (such as calculating but not transmitting) the BSSID. WUR STAs, when they receive PPDU 600, may check FCS or MIC assuming the presence of a BSSID, such as the MAC address of the AP 104 transmitting PPDU 600.

Accordingly, in some implementations, calculating the CRC may be based at least in part on assuming that at least a portion of the BSSID is present in the WUR frame. For example, the transmitting party may append one or more bits of the BSSID in the WUR frame without transmitting the one or more bits of the BSSID (an address 2 field, such as 16 bits, may exist after the ID field, but may not transmit the address 2 field).

Alternatively, the CRC may be calculated as described herein and may then be scrambled or embedded with some information of the BSSID associated with the transmitting device (such as AP 104). In some implementations, the exclusive OR can extend to other fields of the WUR frame. For example, if the WUR frame is 6 bytes in length, the WUR frame may be scrambled with 6 bytes of the BSSID. Scrambling of the CRC may occur before the CRC is included in FCS 630. The CRC may be scrambled with 16 bits of the BSSID. Scrambling may include exclusive-or of the CRC, as described herein. The receiver device (such as STA 106) may descramble the CRC based on the known information of the receiver BSSID, and then check or compare the descrambled CRC to confirm that the check or comparison passed. In some implementations, the MIC may be calculated and scrambled or embedded instead of the CRC.

In some implementations, the CRC/MIC/BSS field of FCS 630 may be used to ensure that WUR STAs are not awakened by PPDUs from aggressors or unfriendly APs 104. For example, a security protocol with low overhead may be used to avoid CCMP type signaling, where the MIC has 8 or 16 bytes and the CCMP header has 8 bytes. Accordingly, PPDU 300 or MPDU 302 may be unsafe when FCS 340 contains a CRC, and PPDU 300 or MPDU 302 may be safe when FCS 340 contains a MIC. In some implementations, the frame control field 321 may be used to signal whether to use a CRC or MIC for a particular PPDU 300 or MPDU 302. In some implementations, the MIC is a truncated output of the selected cipher suite (such as the baseline), and the timestamp field 624TSF timer may serve as the packet number. Accordingly, PPDU 600 may be an unsafe PPDU when FCS 630 includes a CRC and a scrambled/encoded/masked/camouflaged BSSID of AP 104, etc., and PPDU 600 may be a safe PPDU when FCS 630 includes a MIC and a scrambled/encoded/masked/camouflaged BSSID of AP 104, etc. In some implementations, the frame control field 621 may signal the distinction between a secure PPDU 600 and an unsecure PPDU 600.

In some implementations, MIC computation may be based on the entire MPDU 602. For example, MPDU 602 may be intended for a single WUR STA or multiple WUR STAs. In some implementations, the MIC is generated by the AP 104 based on a group key known to both the AP 104 and the one or more WUR STAs. For example, the group key may be a PCR group key, IGTK, or the like. The group key may be known by all STAs associated with the AP 104 that are intended recipients of the PPDU 600. In some implementations, the timestamp field 624 may provide a portion of a monotonically increasing counter. For example, the timestamp field 624 may contain the MSBs of 2 LSBs of the TSF timer, which may provide a time step of 256us and a timestamp wrap-around every 65536 ms. In some implementations, the entire TSF timer at the WUR STA is updated with the partial TSF included in the timestamp field 624. In some implementations, an absolute TSF timer may be used as an input parameter for MIC computation, which may be further used to protect WUR STAs from replay attacks.

In some implementations, the MPDU 602 may have a minimum length and a maximum length. The length may be signaled or determined based on the frame type of PPDU 600, such as in frame control field 621, as described herein. For example, MPDU 602 may have a minimum length of five (5) bytes. MPDUs may include one or more of the following: a 1 byte frame control field 621, a paged ID (RA) field 622 (pending), a partial BSSID (TA) field 623 (pending), a timestamp field 624 (pending), and a CRC/MIC/BSS field 631 (pending), assuming that the paged ID (RA) field 622 has a length of zero bytes (such as for a broadcast or multicast PPDU 600) and each remaining pending field has a minimum length of 1 byte. In some implementations, as described above, MPDU 602 may have a minimum length of six (6) bytes when frame master control field 621 indicates no length (such as no paged ID) but includes a paged ID field 622 therein that has a length of 1 byte but is zero. In some implementations, the constant length PPDU 600 may have a minimum MPDU 602 size of 5 or 6 bytes. For example, the smallest size MPDU 602 may be transmitted at 62.5Kbps with a time of about 0.77 ms.

MPDU 602 may have a maximum length of twelve (12) bytes. For example, MPDU 602 may include a minimum of 5 bytes as described above, and then also 7 bytes for the 16 identifiers in paged ID field 622. Thus, the maximum length of MPDU 602 may be 5 bytes of the non-paged ID field plus the maximum 8 bytes of the paged ID field 622. In some implementations, the variable length PPDU 600 may be signaled or determined based on the frame type and length in the frame control field 621. A maximum MPDU 602 length of 12 bytes may use a transmission time of about 1.66ms at 62.5 Kbps. In some implementations, MPDU 602 may have a length of any byte between 5 bytes and 12 bytes.

Fig. 8 is a flow chart of an example method 800 of wireless communication. Although the method 800 is described herein with reference to communication between the AP 104 and the STA 106 as discussed above with reference to fig. 1, one of ordinary skill in the art will appreciate that the method 800 may be implemented by other suitable devices and systems. For example, the method 800 may be performed by the STA 106 or the plurality of APs 104. Although the method 800 is described herein with reference to a particular order, in various implementations, the blocks herein may be performed in a different order, or omitted, and additional blocks may be added.

At block 802, the method may include generating a message for transmission, the message including a preamble and a data unit. The preamble may include information for decoding the data unit. The data unit may include control information for the data unit that identifies information for the one or more devices intended to receive the data unit, information identifying the transmitting device, and synchronization and security information. At block 804, the method may further include transmitting the message from the transmitting device to one or more devices. The one or more devices may be configured to receive the message via a power saving receiver circuit.

In some implementations, an apparatus for wireless communication may perform some implementations described herein. In some implementations, the apparatus can include means for generating a message transmission, the message including a preamble and a data unit. The preamble may include information for decoding the data unit. The data unit may include control information for the data unit that identifies information for the one or more devices intended to receive the data unit, information identifying the transmitting device, and synchronization and security information. The apparatus may further include means for transmitting the message from the transmitting device to the one or more devices. The one or more devices may be configured to receive the message via a power saving receiver circuit.

Fig. 9 illustrates further details of an example structure of the PPDU 300 of fig. 3 for communication with WUR device 202 (fig. 2). Fig. 9 illustrates only three portions of the one or more MPDUs 902 contained in the PPDU 300. More than one MPDU may be included in a PPDU transmitted in MU mode (such as using OFDMA multiplexing techniques). MPDU 902 may include one or more of the following: a MAC header 320, a payload or frame body portion 330, and an FCS 340. The MAC header 320 may include one or more common fields present in all WUR frames or PPDUs. For example, the MAC header 320 may include one or more of the following: a frame control field 910, an Identifier (ID) field 912 (which may also be referred to as an address field), and a TSD (type subtype related)/TD (type related) control 914. Either TSD or TD may be present in WUR frames. In some implementations, TSD and TD may be used interchangeably. The payload or frame body portion 330 may contain miscellaneous information and may have a length of zero ("0") or more bits. In some implementations, the length may be a multiple of one octet, or two octets, etc., and the length may be indicated in the frame control field. Depending on the type of PPDU 300 received, FCS 340 may include a cyclic redundancy check ("CRC") or a message integrity check ("MIC"). For example, if the frame is not secure, there may be a CRC, and if the frame is secure, there may be a MIC. The FCS field 340 may be a 16-bit field. FCS 340 may be additionally calculated with the BSSID address taken into account if the frame is transmitted to one or more STAs associated with the BSS. If a frame is sent to one or more STAs not associated with the BSS, FCS 340 may not be calculated with the BSSID address taken into account.

As depicted in fig. 9, the MAC header 320 may include one or more of the following three separate fields: a frame control field 910, an ID field 912, and a TSD/TD control field 914. The frame control field 910 may be an 8-bit field, the ID field 912 may be a 12-bit field, and the TSD/TD control frame 914 may be a 12-bit field. In some implementations, some portion of the content of the frame control field may be carried in the PHY preamble of the WUR PPDU. Additionally, the payload or frame body portion 330 may have a variable length, and the FCS may have lengths of 8, 16, 24, and 32 bits. For example, the maximum length of the payload or frame body portion 330 may be 8, 16, 32, or 64 bytes. In some implementations, the length of the payload or frame body portion 330 is indicated in the frame control field 910 and is in units of 1 octet, 2 octets, and so on.

The 1-byte frame control field 910 may provide information identifying at least one of a type and a length of the MPDU 902, as well as additional information that may be used to decode the MPDU. In some implementations, the frame control field 910 may include a one-bit protocol version field (not shown) in which zero (0) is currently used and one (1) is saved for future development. In some implementations, the frame control field 910 may include a type subfield (not shown) and a length/subtype field (not shown). The type subfield may be configured to identify the frame type of MPDU 902. In some implementations, the type subfield can indicate that MPDU 902 is a WUR beacon frame, a WUR control frame, a WUR synchronization frame, a WUR paging frame, and so forth. In some implementations, a type subfield can be used to distinguish between constant or variable length frames. For example, a first value in the type subfield may indicate WUR beacon frames having a constant length, while a second value in the type subfield may indicate WUR control frames having a varying length. The length/subtype field may provide information indicating one or both of the following: different frame subtypes of MPDU 902, or different payload or frame body sizes of its payload or frame body portion 330 portions. Alternatively or additionally, the length/subtype field may provide parity bits, which may indicate validity or lack thereof of the frame. Alternatively or additionally, a bit (such as the first bit or the last bit of the frame control field 910) may be a parity bit indicating the validity or corruption of one or more subfields of the MPDU 902. In some implementations, parity bits may be calculated to cover only the frame control field 910, or the frame control field 910 and the ID field 912. Alternatively or additionally, the length/subtype field may indicate a frame subtype of a constant length frame or a length of a variable length frame. In some implementations, the parity bits may be any bits in the frame control field 910. For example, the parity bit may be bit 1 of the frame control field 910 or the last bit of the frame control field 910. Alternatively or additionally, the parity bit may also be one of the bits of the ID field 912 (such as the last bit).

The ID field 912 may optionally be present and may be 8 or 12 bits in length and may provide an identification of the identity (such as an ID) of the transmitting device. The transmitting device may be identified by a transmitting BSS, which may correspond to a BSS from which WUR communications are transmitted. For example, the ID field 912 may contain a partial BSSID field 322 or it may include a partial address or identifier of the AP 104 or STA 106 transmitting the PPDU 300. Alternatively, the ID field 912 may include a portion of a BSSID or a portion of a Service Set Identifier (SSID). In some implementations, the receiving WUR STA may use the ID field 912 (and information contained therein) to determine whether the WUR STA is a potential intended recipient of the PPDU 300. For example, during association with the AP 104 or the wireless communication system 100, a WUR STA may be assigned or provided with a BSSID of a BSS (such as the BSS in BSA 102) to which the SUR STA belongs. Accordingly, WUR STAs may store the BSSID of their BSSs in their memory (such as memory 206 of fig. 2). When a WUR STA compares the partial BSSID 322 with at least a portion of the stored BSSIDs (or may store a portion to be compared instead of the full BSSID), if the values match, the WUR STA may determine that the received acknowledgement of the PPDU 300 applies to the WUR STA and perform additional checks as described below. However, if the partial BSSID 322 does not match the stored BSSID or SSID of the WUR STA, the WUR STA may determine that the received PPDU 300 is not applied to the WUR STA and may ignore the remaining portion of the PPDU 300. Accordingly, the partial BSSID field 322 may be used to reduce the computation, processing, and reception of the PPDU 300 by WUR STAs that do not need to be concerned with the PPDU 300. In some implementations, the partial BSSID may be a value known by both the AP and the STA that may vary over time according to a function known by both the AP and the STA, such as a random generator with a seed known at both devices, or in accordance with a common time reference at the AP and the STA. In some implementations, the ID field 912 may contain an identifier of the WUR frame, which may be selected from table 1 below. The identifier included in the ID field 912 may depend on the type of WUR frame (identified below with respect to table 2).

Table 1-identifier of WUR frame

In some implementations, when a WUR frame (such as a wakeup frame) is addressed individually, the WUR frame's ID field 912 contains a WUR ID, when the WUR frame is group addressed, the WUR frame's ID field 912 contains a group ID, and when the WUR frame is broadcast, the WUR frame's ID field 912 contains a transport ID. In the following description, other implementations of identifiers contained in the ID field and in other fields of WUR frames are provided.

In some implementations, the partial BSSID 322 field may include only one octet of the BSSID of the transmitting device or 12 bits of the BSSID (or SSID). In some implementations, a single octet or 12 bits of a BSSID, such as a partial BSSID, is sufficient to provide sufficient intra-PPDU power savings and discard PPDUs transmitted by other BSSs (APs) as compared to the increased cost of transmitting and processing the complete BSSID. Accordingly, the partial BSSID field 322 may provide reduced accuracy in identifying whether WUR STAs belong to the same or different BSS as the transmitting AP 104 or STA 106 while providing reduced communication costs (such as time, bandwidth, etc.). Additionally, in some implementations, the partial BSSID field 322 may be used in some implementations to minimize false alarms in FCS, as discussed in further detail below. In some implementations, if a SIG field is present in the PHY preamble, the frame control field 910 may be moved to the PHY preamble.

The TSD/TD control field 914 contains control information that depends on the type or subtype of MPDU 902, as discussed in further detail below. For example, if MPDU 902 is a beacon, TSD/TD control field 914 may contain a partial TSF, if MPDU 902 is paging one or more STAs to wake up and the frame is protected, TSD/TD control field 914 may contain a packet number, in which case other control information may be carried, such as a partial TSF, etc. In another example, TSD/TD control field 914 may contain an additional portion of the transmitter identifier. This may be useful for frames sent prior to association (such as for positioning, discovery, and ranging purposes) because these frames may require lower false alarm probabilities. In some implementations, the ID field and TSD/TD control field 914 may be such that a portion of the transmitter identifier is stored in the ID field and another portion of the transmitter identifier is stored in the TSD/TD control field 914. Alternatively, when the ID field contains a portion of the sender identifier, TSD/TD control field 914 may contain a portion of the receiver identifier, and vice versa. When referring to a portion of an identifier in some implementations, these values may be identifiers that are assigned or negotiated between peer STAs using the primary radio.

The payload or frame body portion 330 may be of variable length and its content may depend on the type/subtype of MPDU or other settings of the fields in the MPDU 902 preceding that portion. The payload or frame body portion 330 may contain information that varies with the particular individual WUR frame type. Additionally, the payload or frame body portion 330 may not be present in constant length WUR frames and may be present in variable length WUR frames. In some implementations, the length of the payload or frame body portion 330 may be equal to X (l+1), where L is the value of the length subfield in the frame control field 910, and X is the unit of octets (such as if the unit is 1 octet and the length field is 3 bits, or if the unit is 2 octets and the length field is 2 bits), 16 octets (considering similar considerations of possible X, L values), 24 octets, or 32 octets. Examples of possible miscellaneous fields are provided below with respect to FIG. 10.

Fig. 10 illustrates further details of an example structure of the MPDU 902 of fig. 9. Fig. 10 illustrates four specific MPDU formats of a generic MPDU format 902: beacon format 1010, paging format 1020, pre-association format 1030, and example vendor specific format 1040. As shown, each of these formats may be associated with a particular "type" value (or subtype value), which may correspond to a value to be used in the type subfield of the frame control field 910 described herein. Accordingly, the beacon format 1010 may be identified by a type field value of "0", the paging format 1010 may be identified by a type field value of "1", the pre-association format 1030 may be identified by a type field value of "2", and the vendor specific format 1040 may be identified by a type field value of "3".

As shown, the beacon format 1010 includes an 8-bit frame control field 910 as described above with respect to fig. 9. The 12-bit ID field 912 referenced with respect to fig. 9 is a Partial BSSID (PBSSID) 1011 of the transmitting device, as described herein. For the beacon format 1010, the 12 bit TSD/TD control field 914 is a partial timestamp function (TSF) field 1011 and contains 12 bits of the timing synchronization function of the AP (such as the 12 LSBs of the timestamp field, or a specific window of the size 12 bits of the timestamp field that the AP will include in the transmitted beacon). The PTSF field helps the receiver synchronize its internal clock to the internal clock of the AP (such as a peer STA) with which the receiver interacts. For the beacon format 1010, the payload or frame body portion 330 may not be included, and the FCS 340 is the CRC/MIC/BSS field described herein. Thus, the beacon format 1010 may have a length of 6 bytes.

In some implementations, the beacon format 1010 may be a constant or variable length. The constant length may be most commonly used and may be required for use by all WUR devices. The enhanced or extended length beacon format may be optional. In some implementations, the beacon format 1010 may have a subtype identifier of 0 (such as in a length/subtype field), indicating a constant length. If a length bit is not used to indicate the length of the payload or frame body portion 330, this field (such as the remaining bits of the length/subtype field) may not be used and may be diverted. For example, these bits may be used as extended control bits, such as a change sequence number, which if increased, may indicate to the receiving STA that a BSS system update has occurred.

As shown, paging format 1020 includes an 8-bit frame control field 910, as described above with respect to fig. 9. The 12-bit ID field 912 referenced with respect to fig. 9 is the paged ID field 1021 of the recipient device, as described herein, and may contain 11 LSBs of the recipient device's association identifier. For paging format 1020, 12-bit TSD/TD control field 914 may be any of the following: a packet number field that is an increased number that identifies the packet and that can be used to identify replay attacks against the protected frame or that can be used to identify frames that need to be acknowledged; a PTSF field containing part of the timing synchronization function, which is useful for synchronizing the internal clock of the receiver to the internal clock of the transmitter, and can additionally be used as a counter to detect replay attacks for secure frames. For paging format 1020, a variable length frame body field 1023 may be included, and the presence of this frame body field 1023 may be indicated by a non-zero length field in frame control field 910, and FCS 340 is a CRC/MIC/BSS field described herein. Thus, paging format 1020 may have a minimum length of 6 bytes and a maximum length of 13 bytes, depending on the presence and length of frame body field 1023.

Paging format 1020 may be basic or advanced. When paging format 1020 is advanced, it may have a variable length based on the presence and length of frame body field 1023 itself. Accordingly, the length/subtype field of the frame control field 910 may be used to indicate the length of the frame body field 1023 in units of 1 byte, in units of 2 bytes, 3 bytes, 4 bytes, etc. (the units are known at both the sender and receiver, and may be default values). For example, when the length/subtype field indicates "2", the frame body field 1023 may have a length of 2 bytes. In some implementations, the 2-byte frame body field 1023 may indicate two addresses for the paged ID in the paged ID field 1021. For example, the frame body field 1023 may include an address range for the paged ID in the paged ID field 1021. For example, when the frame body field 1023 is 2 bytes, it may contain a list of STAs of the additional 2 paged ID fields, thereby identifying the second and third STAs, with the first STA being identified by the ID field itself of the WUR paging frame. In this example, the first STA is identified by an AID contained in the ID field, the second STA is identified by an AID (identifier) obtained from 3 MSBs of the ID field and the first 8 bits of the STA list, and the third STA is identified by an AID (identifier) obtained from 3 MSBs of the ID field and the second 8 bits of the STA list. As shown, the pre-association format 1030 includes an 8-bit frame control field 910, as described above with respect to fig. 9. The 12-bit ID field 912 referenced with respect to fig. 9 is a partial BSSID field 1031 or a partial identifier of the transmitting device, such as a PBSSID (TA). For pre-association format 1030, the 12-bit TSD/TD control field 914 is a second partial BSSID field 1032, such as PBSSID2 (TA 2), as described herein. The presence of two identifiers in the frame significantly reduces the false alarm probability. For pre-association format 1030, the payload or frame body portion 330 may be specific to the pre-associated frame (such as pre-association specific field 1033) and may be of variable length. FCS 340 is the CRC field described herein. Thus, the pre-association format 1030 may have a minimum length of 6 bytes and a maximum length of 13 bytes, depending on the length of the pre-association specific field 1033. In some implementations, vendor specific field 1043 may include a recipient address (such as an address of a recipient device of vendor specific format 1040 frames).

In some implementations, the pre-association format 1030 may not be encrypted because the communication device may not know the encryption method used by another device until associated with the other device. Further, the pre-association format 1030 may be transmitted by a transmitting device for positioning by a receiving device to communicate timing information or to communicate discovery information. In some cases, the CRC of FCS 340 may be replaced with another PBSSID field, such as PBSSID3 (TA 3), to further reduce the false alarm probability (now changing from 24 bits to a 32-bit identifier of the transmitter). In some implementations, the pre-association specific field 1033 may have a length identified by the length/subtype field of the frame control field 910. For example, when the length field indicates a length of 2, then the pre-association specific field 1033 may have a length of 2 bytes and may be used to provide fine timing synchronization, positioning, and the like. In some implementations, the PBBSID field 1031 and the PBBSID2 field 1032 may include hashes of the SSID of the transmitting device (and the receiving device). For example, a 6-byte MAC address of an associated AP may be hashed down to 3 bytes and included in PBSSID field 1031 and PBSSID2 field 1032, respectively.

As shown, vendor specific format 1040 includes an 8-bit frame control field 910, as described above with respect to fig. 9. The 12-bit ID field 912 referenced with respect to fig. 9 is the vendor ID 1041 of the transmitting device, which may identify a particular vendor, etc. For vendor specific format 1040, the 12-bit TSD/TD control field 914 is a second vendor ID field 1024 that may identify the second transmitting device. In some implementations, the vendor specific format contains two partial identifiers, one in the ID field (such as vendor ID field 1041) and one in the TSD/TD control field 914 (such as second vendor ID field 1024). The vendor ID field 1041 may contain the 12 Least Significant Bits (LSBs) of the Organization Unique Identifier (OUI), and the second vendor ID field 1042 contains the other 12 bits of the OUI. Vendor ID fields 1041 and 1042 may identify the vendor of the device generating the frame. For vendor specific format 1040, the payload or frame body portion 330 may include a vendor specific field 1043 of miscellaneous length, and the FCS 340 is a CRC field as described herein. Thus, vendor specific format 1040 may have a minimum length of 6 bytes and a maximum length of 13 bytes, depending on the length of vendor specific field 1043. In some implementations, vendor specific field 1043 may include a recipient address (such as an address of a recipient device) of the vendor specific format 1040 frame.

Fig. 11 illustrates further details of an example structure of the MPDU 902 of fig. 9, including details of the frame control field 910 of the MPDU 902. As shown, the frame control field 910 may include a type (subtype) field 1102, a length present field 1103, a length or miscellaneous field 1104, and a protected field 1106. In some implementations, the type field 1102 may be 3 bits in length and the length/miscellaneous field 1104 may be 3 bits in length. The length present field 1103 may be 1 bit in length and the protected field 1106 may be 1 bit in length. The type field 1102 may indicate the type of MPDU 902. Example types of MPDUs 902 are provided below in table 2.

TABLE 2 WUR frame types

For example, when the type field 1102 includes a value of "0," the MPDU 902 may be a WUR beacon frame. When the type field 1102 includes a value of "1," the MPDU 902 may be a WUR wake-up frame. When the type field 1102 includes a value of "2," the MPDU 902 may be a WUR vendor specific frame. When the type field 1102 includes a value of "3," the MPDU 902 may be a WUR discovery frame. When the type field 1102 includes a value of "4" or greater, the MPDU 902 may be another particular type(s) of frame.

The length/miscellaneous field 1104 may include or function as a length field for the MPDU 902 when the length is variable and may function as an miscellaneous field for the MPDU 902 when the length is constant. In some implementations, whether the MPDU 902 is of variable length or constant length may be indicated by one bit (such as a variable length or constant length bit). When the bit is set to "1," the MPDU 902 may be of variable length. When the bit is set to "0," the MPDU 902 may be of a constant length. The bit may be indicated in various locations. As an example, the bit may be the most significant bit or the least significant bit of the type field or the length/miscellaneous field. In some implementations, in addition to (or instead of) indicating whether the MPDU 902 is of variable length or constant length, the bit may indicate whether the MPDU includes a length value. For example, the bit may be the length present field 1103 shown in fig. 11, which may indicate whether the length/miscellaneous field 1104 includes the length of the MPDU 902. In some implementations, when the length present field 1103 is set to "1," the length/miscellaneous field 1104 may include the length of the MPDU 902, or may include a length subfield indicating the length of the MPDU 902. When the length present field 1103 is set to "0", the length/miscellaneous field 1104 may be a miscellaneous field as a reserved field, or may be a miscellaneous field including a reserved subfield. It should be noted that the bit lengths described herein are examples, and that the bit lengths may have other values. For example, the type field 1102 may be 2 bits in length and the length/miscellaneous field 1104 may be 4 bits in length.

When the length/miscellaneous field 1104 operates as a length field of the variable length MPDU 902, the length field 1104 may contain the length of the frame body field 330. When length/miscellaneous field 1104 operates as a miscellaneous field, miscellaneous field 1104 may contain, for example, bits that are expected to be used to indicate or convey various other information, as discussed above.

In some implementations, the protected field 1106 (which may also be referred to as a protected subfield) may indicate whether information carried in WUR frames is protected. For example, when the information carried in WUR frames has been processed by the MIC algorithm, the information is protected. If the WUR frame is protected with a MIC, the protected field 1106 may be set to "1". For example, when FCS 340 includes a MIC (rather than a CRC), protected field 1106 may be set to "1". The protected field 1106 may be set to "0" when the information carried in the WUR frame is not protected or the information has not been processed by the MIC algorithm. For example, when FCS 340 includes a CRC (rather than a MIC), protected field 1106 may be set to "0".

As described herein, each WUR frame including MPDU 902 may be composed of the following components: a MAC header 320 (which includes a frame control 910, an ID field 912, and a TSD/TD control field 914), a frame body portion 330 (which may be of variable length and contain frame type specific information in the case of variable length), and an FCS 340 (which contains, for example, 8, 16 or other bit CRCs). In some implementations, the FCS may include a different CRC. For example, FCS 340 may include a CRC-16FCS (which may include a 16 th order polynomial sum(s) corresponding calculation) or a CRC-8FCS (which may include an 8 th order polynomial sum(s) corresponding calculation). In some implementations, another CRC polynomial or calculation may be used or provided.

Fig. 12 illustrates details of an example WUR frame 1200a indicating an embedded BSSID field 1210 and an example WUR frame 1200b not indicating an embedded BSSID field 1210. WUR frame 1200a includes a frame control field 910, an ID field 912, a TSD/TD control field 914, a payload or frame body portion 330, an embedded BSSID field 1210, and an FCS field 340.WUR frame 1200b includes a frame control field 910, an ID field 912, a TSD/TD control field 914, a payload or frame body portion 330, and an FCS field 340, while an embedded BSSID field 1210 is not explicitly included in WUR frame 1200 b.

In some implementations, the FCS field 340 may include a 16-bit CRC, and the FCS may be calculated over the frame control field 910, the ID field 912, the TSD/TD control field 914, the payload or frame body portion 330, and the embedded BSSID field 1210 shown in WUR frame 1200 a. In some implementations, the frame control field 910, the ID field 912, the TSD/TD control field 914, the payload or frame body portion 330, and the embedded BSSID field 1210 may be referred to as calculation fields. In some implementations, the payload or frame body portion 330 may be optional (e.g., may be included in WUR frame 1200a only when WUR frame 1200a is of variable length, as discussed herein. In other implementations, the payload or frame body portion 330 may not be included in the WUR frame 1200 a. Similarly, for WUR frames that are not WUR discovery frames, the embedded BSSID field 1210 may be included only in WUR frames 1200a (e.g., may only be present in post-association WUR frames). For WUR discovery frames, the embedded BSSID field 1210 may not be included in WUR frame 1200 a. In some implementations, the embedded BSSID field 1210 may be the last field in sequence of the calculation fields.

In some implementations, when the embedded BSSID field 1210 is not included in the WUR frame 1200b, the embedded BSSID may be obtained from a last WUR pattern element or a last WUR operation element transmitted by the AP 104 to the STA 106. In some implementations, the embedded BSSID field 1210 may be obtained from a hash of the BSSID field contained in the WUR pattern element or WUR operation element. The AP 104 may include WUR operation elements in individually addressed management frames sent to the STA 106 (if the AP 104 wishes that these frames are decodable only by the STA 106, such as by using embedded BSSID or BSSID fields known only by the STA 106 and providing this information to the STA 106 in encrypted management frames), or in broadcasted management frames (such as beacons, broadcast probe responses, etc.), so that all STAs 106 associated to the AP 104 or intended to be associated with the AP 104 are aware of the embedded BSSID or from which they may derive the BSSID. The embedded BSSID may include, for example, 16 bits that are randomly selected by the AP 104 from the BSSIDs identifying BSSs with which the recipient STA 106 is associated, or from the BSSIDs identifying BSSs that are not transmitting when the BSSs with which the STA 106 is associated belong to a multiple BSSID set and the BSSID is not a transmitted BSSID. In some implementations, the AP 104 may select any value of 16 bits for the BSSID, as long as the selected value is different from all other BSSs in the neighborhood. The AP 104 may request that each STA 106 provide a report or list of BSSIDs they observe in the respective neighbor. Alternatively, the STA 106 may report the observed BSSID without prompting by the AP 104. In some implementations, the reporting or listing of BSSIDs may utilize a mechanism similar to BSS color conflict reporting.

In some implementations, when the embedded BSSID field 1210 is not included in the WUR frame 1200b, the embedded BSSID may be obtained from the Least Significant Bits (LSBs) of the BSSID. For example, the embedded BSSID may be 16 LSBs of a BSSID (such as BSSID [32:47 ]) that identifies the BSS with which the STA 106 is associated. Alternatively, the 16 LSB BSSIDs [32:47] may come from a BSSID identifying the transmitting BSS when the STA 106 belongs to a multi-BSSID set with its associated BSS.

In some implementations, when the embedded BSSID field 1210 is not included in the WUR frame 1200b, the embedded BSSID may be a 16-bit field obtained by xoring the BSSIDs by default. For example, the embedded BSSID may be 16 bits equal to the result of BSSID [0:15] exclusive-or BSSID [16:31] exclusive-or BSSID [32:47] identifying the BSSID of the BSS with which STA 106 is associated. Alternatively, when the STA 106 belongs to a set of multiple BSSIDs with its associated BSS, the embedded BSSID may be from the BSSID identifying the transmitting BSS, which is xored as described above.

In some implementations, the embedded BSSID may be obtained from a 48-bit BSSID when the embedded BSSID field 1210 is not included in the WUR frame 1200 b. For example, a 48-bit BSSID may identify a BSS with which STA 106 is associated. Alternatively, a 48-bit BSSID may be from a BSSID identifying a transmitting BSS when the STA 106 belongs to a set of multiple BSSIDs with its associated BSS.

In some implementations, the computation fields are processed according to the order in which they are transmitted. In some implementations, the embedded BSSID may not exist as a separate field in the transmitted WUR frame. For example, the embedded BSSID may be embedded in one or more other fields of the WUR frame that is actually transmitted. Thus, while WUR frame 1200a shows the embedded BSSID as an explicit field 1210, the embedded BSSID may actually be included in the calculation field as part of, or embedded in, one or more fields that make up the calculation field, such as frame control field 910, ID field 912, TSD/TD control field 914, payload, or frame body portion 330.

Fig. 13 illustrates a flow chart of an example method 1300 performed by a first device for generating WUR frames for transmission to one or more devices. In some implementations, the first device may be an AP (such as AP 104), or may be a WLAN chip of the AP. The first device may communicate with one or more devices, such as one or more STAs 106. The method may be implemented in whole or in part by a device described herein, such as wireless device 202. Although the illustrated methods are described herein with reference to a particular order, in some implementations, the blocks herein may be performed in a different order, or omitted, and additional blocks may be added.

In block 1302 of fig. 13, in some implementations, the first device may generate a WUR frame including a MAC header and an FCS with a CRC or MIC. The FCS may be determined based at least in part on the MAC header and BSSID information associated with the first device.

In some implementations, the first device may conceal, hash, scramble, or mask BSSID information associated with the first device in the FCS when generating the value of the FCS. For example, the first device may determine the FCS based at least in part on the MAC header and the BSSID information.

Fig. 14 illustrates an example WUR frame 1400a that may be initially generated with BSSID information for determining FCS 340, and an example WUR frame 1400b that is output for transmission. WUR frame 1400a may initially include a MAC header 320 and an embedded BSSID field 1210. As depicted in fig. 9-12, MAC header 320 may include a frame control field 910, an ID field 912, and a TSD/TD control field 914. In some implementations, the embedded BSSID field 1210 may include BSSID information, which may be part of a BSSID associated with the first device (such as 16 LSBs or MSB bits of the BSSID), or a complete BSSID associated with the first device. In some implementations, the BSSID information included in the embedded BSSID field 1210 may be obtained from a hash of the BSSID associated with the first device. For example, the value of the BSSID information included in the embedded BSSID field 1210 may be obtained from the output of a hash function having the BSSID as input. In some implementations, the first device may determine the FCS 340 based on the MAC header 320 and the embedded BSSID field 1210 using a polynomial (such as one of the various polynomials described in this disclosure). As depicted in fig. 11, when WUR frame 1400a is a protected frame, the first device may generate a MIC for FCS 340. When the WUR frame is an unprotected frame, the first device may generate a CRC for FCS 340. In some implementations, FCS 340 may be a fixed length, such as a 16-bit FCS. In some implementations, WUR frame 1400a may optionally include a payload or frame body field 330 (as shown by the dashed line in fig. 14). When WUR frame 1400a includes a payload or frame body field 330, the first device may determine FCS 340 based on MAC header 320, payload or frame body field 330, and embedded BSSID field 1210 using a polynomial.

In some implementations, the first device may assume that BSSID information is included in WUR frames for calculating the value of FCS. In some implementations, a first device may retrieve BSSID information stored in the first device and may conceal, hash, scramble, or mask BSSID information associated with the first device in the FCS when generating the value of the FCS. In some implementations, when BSSID information is initially included in embedded BSSID field 1210 for calculating FCS (such as FCS 340), the first device may remove BSSID information from WUR frames before outputting WUR frames for transmission. For example, after generating FCS 340 and appending it to WUR frame 1400a, the first device may remove embedded BSSID field 1210 from WUR frame 1400a, which results in WUR frame 1400b to be output for transmission. WUR frame 1400b may include a MAC header 320 and an FCS 340. Similar to WUR frame 1400a, MAC header 320 of WUR frame 1400b may include frame control field 910, ID field 912, and TSD/TD control field 914. As described herein, in some implementations WUR frame 1400b may optionally include a payload or frame body field 330 (as shown by the dashed line in fig. 14).

In some implementations, the first device may generate a bit sequence to generate WUR frame 1400a. For example, the first device may generate a bit sequence including at least a first set of bits for the MAC header 320 and a second set of bits for the embedded BSSID field 1210. The second set of bits may correspond to BSSID information that may be included in the embedded BSSID field 1210. In some implementations, the first device may determine the FCS 3340 based at least in part on the first set of bits for the MAC header 320 and the second set of bits for the embedded BSSID field 1210. The FCS may include a third set of bits. The first device may append the third set of bits for FCS 340 to the bit sequence for WUR frame 1400a. The first device may also remove the second set of bits for the embedded BSSID field 1210 from the bit sequence to generate a WUE frame 1400b before outputting the WUR frame for transmission. In some implementations, WUR frame 1400a may optionally include a fourth set of bits for payload or frame body field 330. When WUR frame 1400a includes a payload or frame body field 330, the first device may determine FCS 340 based on a first set of bits for MAC header 320, a fourth set of bits for payload or frame body field 330, and a second set of bits for embedded BSSID field 1210. In some implementations, the first device may use the second set of bits associated with the BSSID information to determine the FCS 340 without adding the second set of bits to the WUR frame (and thus without removing the second set of bits prior to transmission). For example, the first device may retrieve a second set of bits associated with BSSID information stored in the first device, and may use the second set of bits (and the first set of bits of MAC header 320) in generating FCS 340. The first device may conceal, hash, scramble, or mask the second set of bits associated with the BSSID information in the FCS when generating the value of the FCS.

In some implementations, the first device may initially determine a CRC or MIC of the WUR frame and then perform an operation on the CRC or MIC using the BSSID information to generate an FCS of the WUR frame.

Fig. 15 illustrates an example WUR frame 1500a that is initially generated for determining FCS 340, and an example WUR frame 1500b that is output for transmission. WUR frame 1500a may initially include a MAC header 320. As depicted in fig. 9-12, MAC header 320 may include a frame control field 910, an ID field 912, and a TSD/TD control field 914. In some implementations, the first device may determine a CRC or MIC (shown as CRC/MIC 1540) for WUR frame 1500a based at least in part on MAC header 320. The first device may then determine BSSID information 1510 (which may also be referred to as embedded BSSID field information) associated with the first device. The BSSID information 1510 may include a portion of the BSSID associated with the first device (such as 16 LSBs or MSB bits of the BSSID), or a complete BSSID associated with the first device. In some implementations, the BSSID information 1510 may be obtained from a hash of the BSSID associated with the first device. For example, the value of the BSSID information may be obtained from the output of a hash function having the BSSID as input. The first device may determine FCS 340 based at least in part on CRC/MIC 1540 and BSSID information 1510, which may result in WUR frame 1500b to be output for transmission. For example, the first device may generate FCS 340 by hashing or scrambling CRC/MIC 1540 with BSSID information 1510. The first device may generate FCS 340 by xoring CRC/MIC 1540 with BSSID information 1510. In some implementations, WUR frame 1500a may optionally include a payload or frame body field 330 (as shown by the dashed line in fig. 15). When WUR frame 1500a includes a payload or frame body field 330, the first device may determine a CRC/MIC 1540 based on the MAC header 320 and the payload or frame body field 330.

In some implementations, the first device may determine a frame type associated with the WUR frame prior to initiating the operation to generate the FCS. When the WUR frame is one of a set of frame types, the first device may use the BSSID information to generate an FCS. For example, the set of frame types that may use BSSID information to generate FCS may include WUR beacon frames and WUR wake frames. If the first device determines that the frame type associated with the WUR frame is one of the group of frame types (such as a WUR beacon frame or WUR wake frame), the first device may use at least the BSSID information to determine the FCS. For example, as described herein, a first device may determine an FCS based at least in part on a MAC header and BSSID information associated with the first device. When the frame type associated with the WUR frame is a WUR discovery frame, the first device may not use BSSID information to determine the FCS. In some implementations, depending on vendor specifications, another frame type, referred to as WUR vendor specific frame, may also be part of the set of frame types that use BSSID information to generate FCS.

At block 1304 of fig. 13, the first device may output WUR frames for transmission to the one or more devices. For example, WUR frames may be sent to the PHY layer to be embedded in a PPDU for transmission to one or more devices. WUR frames (such as WUR frame 1400b or WUR frame 1500 b) that are output for transmission to the one or more devices may include a MAC header 320 and an FCS 340. As described herein, in some implementations WUR may optionally include a payload or frame body field 330.

In some implementations, the BSSID information associated with the first device includes a BSSID associated with the first device, or a portion of a BSSID associated with the first device. In some implementations, the first device may operate in a multiple BSSID mode, wherein the first device implements a transmitted BSSID and one or more untransmitted BSSIDs. When a first device operates in a multiple BSSID mode and a BSSID associated with the first device is part of a multiple BSSID set of the first device, the BSSID is a transmitted BSSID in the multiple BSSID set. In some implementations, the BSSID information is a function of a BSSID associated with the first device. For example, the BSSID information may be obtained from a hash of a BSSID associated with the first device. In some implementations, the first device may provide BSSID information to the one or more devices prior to generating the WUR frame. For example, the primary radio of the first device may transmit BSSID information to the one or more devices during an association operation or during negotiation of WUR operation modes. As described in fig. 16, the receiving device may use the BSSID information to confirm whether the received WUR frame is directed to the receiving device.

Fig. 16 illustrates a flowchart of an example method 1600 performed by a first device having WUR for receiving and processing WUR frames. In some implementations, the first device may be a STA (such as one of STAs 106), or may be a WLAN chip of the STA. The first device may communicate with a second device, such as AP 104. The method may be implemented in whole or in part by a device described herein, such as wireless device 202. Although the illustrated methods are described herein with reference to a particular order, in some implementations, the blocks herein may be performed in a different order, or omitted, and additional blocks may be added.

In block 1602 of fig. 16, in some implementations, a first device may receive WUR frames from a second device via WUR. For example, the first device may receive a WUR frame embedded in the PPDU from the second device. In some implementations, the first device may receive WUR frame 1400b (shown in fig. 14) or WUR frame 1500b (shown in fig. 15). WUR frames may include a MAC header and FCS with a CRC or MIC. The FCS may be determined by the second device based at least in part on the MAC header and BSSID information associated with the second device. As described in fig. 11, the FCS may include a MIC when the WUR frame is a protected frame, and may include a CRC when the WUR frame is an unprotected frame.

At block 1604, the first device may determine whether the received WUR frame is directed to the first device based at least in part on comparing the FCS of the WUR frame with the calculated FCS. The first device may determine the calculated FCS using information from the received WUR frame and the stored BSSID information. The stored BSSID information may be BSSID information associated with the second device that is received from the second device and stored at the first device. For example, the stored BSSID information may be received from a primary radio of a second device (such as AP 104) during an association procedure or during negotiation of WUR modes of operation.

In some implementations, the first device may determine the calculated FCS based at least in part on the MAC header of the received WUR frame and the stored BSSID information. The first device may determine whether the FCS of the WUR frame matches the calculated FCS by comparing the FCS of the WUR frame with the calculated FCS. The first device may determine that the WUR frame is directed to the first device in response to determining that the FCS of the WUR frame matches the calculated FCS. The first device may determine that the WUR frame is not directed to the first device in response to determining that the FCS of the WUR frame does not match the calculated FCS. If a received WUR frame (transmitted by the second device) is directed to the first device, and if the first device previously received the stored BSSID from the second device, the first device will determine the calculated FCS using the same BSSID information as the second device uses to determine the FCS of the received WUR frame. In this case, the calculated FCS will match the FCS of the received WUR frame.

In some implementations, WUR frames may optionally include a payload or frame body field. When the WUR frame includes a payload or frame body field, the first device may determine the calculated FCS based on the MAC header, the payload or frame body field, and the stored BSSID information.

In some implementations, the first device may generate a bit sequence for comparing the FCS of the WUR frame with the calculated FCS. The bit sequence may include at least a first set of bits for a MAC header of the WUR frame and a second set of bits for the stored BSSID information. The first device may generate the calculated FCS based at least in part on the first set of bits of the MAC header for the WUR frame and the second set of bits for the stored BSSID information. When a WUR frame includes an optional payload or frame body field, the first device may generate a bit sequence that may include the first set of bits for a MAC header of the WUR frame, the second set of bits for the stored BSSID information, and the third set of bits for the payload or frame body field of the WUR frame. The first device may generate the calculated FCS based at least in part on the first set of bits for a MAC header of the WUR frame, the second set of bits for the stored BSSID information, and the third set of bits for a payload or frame body field of the WUR frame. The first device may compare the FCS of the WUR frame with the calculated FCS, as described herein.

In some implementations, the first device may determine a CRC or MIC based at least in part on the MAC header of the WUR frame. The first device may generate the calculated FCS based at least in part on the CRC or MIC and the stored BSSID information. For example, the first device may generate the calculated FCS by hashing or scrambling the CRC or MIC with the stored BSSID information. The first device may generate the calculated FCS by xoring the CRC or MIC with the stored BSSID information. In some implementations, WUR frames may optionally include a payload or frame body field. When the WUR frame includes a payload or frame body field, the first device may determine a CRC or MIC based at least in part on the MAC header of the WUR frame or the payload or frame body field of the WUR frame.

In some implementations, the stored BSSID information may include a BSSID associated with the second device or a portion of a BSSID associated with the second device. In some implementations, if the second device operates in a multiple BSSID mode and implements a transmitted BSSID and one or more untransmitted BSSIDs, the BSSID information (and stored BSSID information) associated with the second device may be the transmitted BSSID. When a first device operates in a multiple BSSID mode and a BSSID associated with the first device is part of a multiple BSSID set of the first device, the BSSID is a transmitted BSSID in the multiple BSSID set. In some implementations, a first device (such as a STA) may be associated with an untransmitted BSSID, and a second device (such as an AP) may have data associated with the untransmitted BSSID to send to the STA. In this case, to avoid waking up other STAs associated with different BSSIDs, the second device may transmit WUR frames to STAs targeted to the untransmitted BSSID, and thus the BSSID information (and stored BSSID information) associated with the second device may be the untransmitted BSSID.

Fig. 17 illustrates details of an example process flow for calculating FCS of WUR frames. In some implementations, when a 16-bit polynomial is used, FCS 340 may include a polynomial x by dividing the calculated field modulo 2 ¹⁶ +x ¹² +x ⁵ +1, wherein the shift register state is preset to full1. In some implementations, FCS 340 may include an inverse of the remainder generated by dividing the calculated field modulo 2 by the corresponding 8, 24, or 32 bit polynomial.

As shown, the CRC-16 implementation includes a serial data input. In some implementations, the serial data input may include a calculation field (B _L ,B _L-1 …,B ₁ ,B ₀ ) Wherein B is _L Is the most significant bit of the computation field. In some implementations, the CRC-16 implementation may be replaced with one of the CRC-8, CRC-24, CRC-32, and CRC-64 implementations.

As used herein, a phrase referring to "at least one" or "one or more" of a list of items refers to any combination of these items, including a single member. For example, "at least one of a, b, or c" is intended to cover the following possibilities: a alone, b alone, c alone, a and b in combination, a and c in combination, b and c in combination, and a and b and c in combination.

The various illustrative components, logic, blocks, modules, circuits, operations, and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware, or software, including the structures disclosed in this specification and their structural equivalents. This interchangeability of hardware, firmware, and software has been described generally in terms of its functionality, and is illustrated in the various illustrative components, blocks, modules, circuits, and processes described herein. Whether such functionality is implemented in hardware, firmware, or software depends upon the particular application and design constraints imposed on the overall system.

The hardware and data processing apparatus used to implement the various illustrative components, logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose single or multi-chip processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable Logic Device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular processes, operations, and methods may be performed by circuitry dedicated to a given function.

In one or more aspects, the functions described may be implemented in hardware, digital electronic circuitry, computer software, firmware (including the structures disclosed in this specification and their structural equivalents), or in any combination thereof. Implementations of the subject matter described in this specification can also be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a computer storage medium for execution by, or to control the operation of, data processing apparatus.

If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The processes of the methods or algorithms disclosed herein may be implemented in processor-executable software modules that may reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that can be implemented to transfer a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Any connection is properly termed a computer-readable medium. Disk (disc) and disc (disc), as used herein, includes Compact Disc (CD), laser disc, optical disc, digital Versatile Disc (DVD), floppy disk and blu-ray disc ^TM A disc, in which data is usually reproduced magnetically, and a disc (disc) optically reproduces data with a laser. Combinations may also be included within the scope of computer-readable media. In addition, the manipulation of methods or algorithms As one of code and instructions, or any combination or set of code and instructions, resides on machine-readable media and computer-readable media that may be incorporated into a computer program product.

Various modifications to the implementations described in this disclosure may be apparent to those skilled in the art, and the generic principles defined herein may be applied to other implementations without departing from the spirit or scope of the disclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded the widest scope consistent with the disclosure, principles and novel features disclosed herein.

In addition, those of ordinary skill in the art will readily appreciate that the terms "upper" and "lower" are sometimes used for convenience in describing the drawings and indicate relative positions corresponding to the orientation of the drawings on a properly oriented page, and may not reflect the true orientation of any device as implemented.

Certain features that are described in this specification in the context of separate implementations may also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Furthermore, although features may be described as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination, or variation of a subcombination.

Similarly, although operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Furthermore, the figures may schematically depict one or more example processes in the form of a flowchart or flowsheet. However, other operations not depicted may be incorporated into the example process schematically illustrated. For example, one or more additional operations may be performed before, after, concurrently with, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results.

Claims

1. A method performed by a first device for wireless communication with one or more devices, comprising:

generating a wake-up radio (WUR) frame, the WUR frame comprising a Medium Access Control (MAC) header and a Frame Check Sequence (FCS), wherein generating the WUR frame comprises:

determining BSSID information associated with the first device from a Basic Service Set Identifier (BSSID) information field of the WUR frame,

determining the FCS based at least in part on the MAC header and the BSSID information associated with the first device, an

Removing the BSSID information field having the BSSID information from the WUR frame prior to outputting the WUR frame for transmission; and

outputting the WUR frame for transmission to the one or more devices, the WUR frame output for transmission including the MAC header and the FCS without including the BSSID information field having the BSSID information used to determine the FCS.

2. The method of claim 1, wherein the FCS comprises a Cyclic Redundancy Check (CRC) when the WUR frame is an unprotected frame.

3. The method of claim 1, wherein the FCS comprises a Message Integrity Check (MIC) when the WUR frame is a protected frame.

4. The method of claim 1, wherein generating and outputting the WUR frame further comprises:

generating a bit sequence for the WUR frame, the bit sequence comprising at least a first plurality of bits for the MAC header and a second plurality of bits for the BSSID information associated with the first device,

determining the FCS based at least in part on the first plurality of bits for the MAC header and the second plurality of bits for the BSSID information, the FCS comprising a third plurality of bits,

appending the third plurality of bits for the FCS to the bit sequence for the WUR frame, an

Outputting the WUR frame for transmission to the one or more devices, the WUR frame including the first plurality of bits for the MAC header and the third plurality of bits for the FCS and not including the second plurality of bits for the BSSID information.

5. The method of claim 1, wherein generating the WUR frame further comprises:

determining a CRC or MIC based at least in part on the MAC header, an

The FCS is determined based at least in part on the CRC or the MIC and the BSSID information associated with the first device.

6. The method of claim 5, wherein determining the FCS based at least in part on the CRC or the MIC and the BSSID information associated with the first device comprises:

the FCS is generated by hashing at least a portion of the BSSID information or the CRC or the MIC.

7. The method of claim 5, wherein determining the FCS based at least in part on the CRC or the MIC and the BSSID information associated with the first device comprises:

the FCS is generated by xoring the CRC or the MIC with at least a portion of the BSSID information.

8. The method of claim 1, wherein the WUR frame comprises:

a data unit including the MAC header and the FCS, the MAC header including frame type information, address information, and control information; and

a preamble comprising information for decoding said data unit,

wherein the FCS is determined based at least in part on the frame type information, the address information, the control information, and the BSSID information associated with the first device.

9. The method of claim 8, wherein,

The data unit further includes a frame body

The FCS is determined based at least in part on the frame type information, the address information, the control information, the frame body, and the BSSID information associated with the first device.

10. The method as recited in claim 1, further comprising:

determining that the WUR frame is one of a plurality of frame types; and

responsive to the WUR frame being of the frame type of a plurality of frame types:

Outputting the WUR frame for transmission to the one or more devices, the WUR frame output for transmission not including the BSSID information for determining the FCS.

11. The method of claim 1, wherein the BSSID information associated with the first device comprises a BSSID associated with the first device or a portion of the BSSID associated with the first device.

12. The method of claim 11, wherein when the BSSID associated with the first device is part of a set of multiple BSSIDs for the first device, the BSSID is a transmitted BSSID in the set of multiple BSSIDs for the first device.

13. The method of claim 1, wherein the BSSID information is a function of the BSSID associated with the first device.

14. A method for wireless communication performed by a first device, the first device comprising a wake-up radio (WUR), the method comprising:

receiving, via the WUR, a WUR frame from a second device, the WUR frame including a Medium Access Control (MAC) header and a Frame Check Sequence (FCS), the WUR frame generated by the second device by:

determining BSSID information associated with the second device from a Basic Service Set Identifier (BSSID) information field of the WUR frame,

determining the FCS based at least in part on the MAC header and the BSSID information associated with the second device, an

Removing the BSSID information field having the BSSID information from the WUR frame prior to outputting the WUR frame for transmission, the WUR frame not including the BSSID information field having the BSSID information used by the second device to determine the FCS; and

determining whether the WUR frame is directed to the first device based at least in part on comparing the FCS of the WUR frame with the calculated FCS.

15. The method of claim 14, wherein,

when the WUR frame is an unprotected frame, the FCS includes a Cyclic Redundancy Check (CRC), an

When the WUR frame is a protected frame, the FCS includes a Message Integrity Check (MIC).

16. The method as recited in claim 14, further comprising:

the calculated FCS is determined based at least in part on the MAC header of the WUR frame and stored BSSID information stored at the first device.

17. The method of claim 15, wherein determining whether the WUR frame is directed to the first device based at least in part on comparing the FCS of the WUR frame with the calculated FCS comprises:

determining whether the FCS of the WUR frame matches the calculated FCS by comparing the FCS of the WUR frame with the calculated FCS,

determining that the WUR frame is directed to the first device in response to determining that the FCS of the WUR frame matches the calculated FCS, an

Determining that the WUR frame is not directed to the first device in response to determining that the FCS of the WUR frame does not match the calculated FCS.

18. The method of claim 16, wherein determining the calculated FCS based at least in part on the MAC header of the WUR frame and stored BSSID information comprises:

Generating a bit sequence for comparing the FCS of the WUR frame with the calculated FCS, the bit sequence comprising at least a first plurality of bits for the MAC header of the WUR frame and a second plurality of bits for the stored BSSID information,

generating a calculated FCS based at least in part on the first plurality of bits of the MAC header for the WUR frame and the second plurality of bits for the stored BSSID information, an

The FCS of the WUR frame is compared to the calculated FCS.

19. The method of claim 16, wherein the stored BSSID information is received by the first device from a primary radio of the second device, the stored BSSID information comprising a BSSID associated with the second device or a portion of the BSSID associated with the second device.

20. The method of claim 19, wherein when the BSSID associated with the second device is part of a set of multiple BSSIDs for the second device, the BSSID is a transmitted BSSID in the set of multiple BSSIDs for the second device.

21. The method of claim 16, wherein the stored BSSID information is a function of the BSSID associated with the second device.

22. The method of claim 14, wherein determining whether the WUR frame is directed to the first device based at least in part on comparing the FCS of the WUR frame with the calculated FCS comprises:

determining a CRC or MIC based at least in part on the MAC header of the WUR frame,

generating a calculated FCS based at least in part on the CRC or the MIC and stored BSSID information,

23. The method of claim 22, wherein generating the calculated FCS based at least in part on the CRC or the MIC and the stored BSSID information comprises: the calculated FCS is generated by hashing the CRC or the MIC with the stored BSSID information.

24. A first device, comprising:

a processor configured to generate a wake-up radio (WUR) frame comprising a Medium Access Control (MAC) header and a Frame Check Sequence (FCS), wherein generating the WUR frame comprises:

an interface coupled with the processor, the interface configured to output the WUR frame for transmission to one or more devices, the WUR frame output for transmission including the MAC header and the FCS without including the BSSID information field having the BSSID information for determining the FCS.

25. The first device of claim 24,

the processor is further configured to:

determining a CRC or MIC based at least in part on the MAC header, an

26. A first device, comprising:

a wake-up radio (WUR) configured to receive a WUR frame from a second device, the WUR frame comprising a Medium Access Control (MAC) header and a Frame Check Sequence (FCS), wherein generating the WUR frame by the second device comprises:

determining the FCS based at least in part on the MAC header and the BSSID information associated with the second device,

a processor coupled with the WUR, the processor configured to:

determining whether the WUR frame is directed to the first device based at least in part on a comparison of the FCS of the WUR frame with the calculated FCS.

27. The first device of claim 26, wherein the processor configured to determine whether the WUR frame is directed to the first device based at least in part on the comparison of the FCS of the WUR frame with the calculated FCS further comprises the processor configured to:

determining a calculated FCS based at least in part on the MAC header of the WUR frame and stored BSSID information stored at the first device,

Determining whether the FCS of the WUR frame matches the calculated FCS based on a comparison of the FCS of the WUR frame and the calculated FCS,

28. The first device of claim 26, wherein the processor configured to determine whether the WUR frame is directed to the first device based at least in part on the comparison of the FCS of the WUR frame with the calculated FCS further comprises the processor configured to: