RECEIVER

RELATED APPLICATION

[0001] This patent claims priority from United States Provisional Patent Application Serial Number 62/529,435, which was entitled

"METHODS AND APPARATUS TO WAKE A RECEIVER," and was filed on July 6, 2017, and also claims priority from United States Provisional Patent Application Serial Number 62/575,352, which was entitled "METHODS AND ARRANGEMENTS FOR WAKE-UP RADIO FRAME

AUTHENTICATION," and was filed on October 20, 2017. U.S. Provisional Patent Application Serial No. 62/529,435 and U.S. Provisional Patent Application Serial No. 62/575,352 are hereby incorporated by reference in their entireties. Priority to U.S. Provisional Patent Application Serial No. 62/529,435 and U.S. Provisional Patent Application Serial No. 62/575,352 is hereby claimed.

FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communication, and, more particularly, to methods and apparatus to wake a receiver.

BACKGROUND

[0003] Wireless device designers seek to use as low of power as possible to conserve battery usage. Some devices use a Low Power Wake- up Receiver/Radio (LP-WUR) to enable ultra-low power operation for a Wi-Fi device. In such an approach, the device uses a low-power receiver that can receive a wake-up packet from another device, and leave the low power mode. Thus, the device can stay in a low power mode until receiving the wake-up packet from the other device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is a block diagram of an example environment in which a transmitter transmits a wake-up message to wake a receiver. [0005] FIG. 2 is a block diagram of an example implementation of the example transmitter of FIG. 1.

[0006] FIG. 3 is a block diagram of an example implementation of the example receiver of FIG. 1.

[0007] FIG. 4 is a communication diagram illustrating example communications between the example receiver of FIG. 1, the example transmitter of FIG. 1, and an attacker.

[0008] FIG. 5 is a message protocol diagram illustrating message frames being omitted from the example wake-up message of FIG. 1.

[0009] FIG. 6 is a message protocol diagram illustrating example extended message content.

[0010] FIG. 7 is a message protocol diagram illustrating alternative example extended message content.

[0011] FIG. 8 is a block diagram of an example wake-up packet prepended by an IEEE 802.11 physical layer preamble.

[0012] FIG. 9 is a message protocol diagram illustrating reconstruction is an example message using information provided in a wake-up message and extended message content.

[0013] FIG. 10 is a flowchart illustrating an example process that may be implemented by machine readable instructions to implement the receiver of FIGS. 1 and/or 3 to enter a low power mode.

[0014] FIG. 11 is a flowchart illustrating an example process that may be implemented by machine readable instructions to implement the receiver of FIGS. 1 and/or 3 to exit a low power mode.

[0015] FIG. 12 is a block diagram illustrating an example approach for computation of a message integrity check (MIC).

[0016] FIG. 13 is a block diagram illustrating an example approach for computation of a message integrity check (MIC).

[0017] FIG. 14 is a block diagram of a radio architecture in accordance with some embodiments.

[0018] FIG. 15 illustrates a front-end module circuitry for use in the radio architecture of FIG. 14 in accordance with some embodiments. [0019] FIG. 16 illustrates a radio IC circuitry for use in the radio architecture of FIG. 14 in accordance with some embodiments;

[0020] FIG. 17 illustrates a baseband processing circuitry for use in the radio architecture of FIG. 14 in accordance with some embodiments.

[0021] FIG. 18 is a block diagram of an example processing device that may execute the instructions of FIGS. 10 and/or 11 to wake a receiver.

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

DETAILED DESCRIPTION

[0023] Low Power Wake-up Receiver/Radio (LP-WUR) is a technique used to enable ultra-low power operation for Wi-Fi devices. In some example systems, a low-power receiver device receives a wake-up packet from another device and determines whether to exit the low power mode. For example, a mobile station may receive a wake-up message from an access point.

[0024] A key element of such a system is waking the appropriate receiver(s). For example, receivers should only be woken (e.g., leave the low power mode) when directed to do so, and should not be able to be woken by devices other than those that have pre-negotiated and/or otherwise established authorization for the ability to wake the receiver. That is, the device should not be able to be woken by an attacker.

[0025] Prior to entering the low power mode, the receiver negotiates with the transmitter to identify pre-shared data fields and/or a pre-shared key. The receiver saves the pre-shared data fields and/or the pre-shared key. To wake the receiver, the transmitter transmits a wake-up message. The receiving device computes an authentication code based on the received message, the pre-shared data fields, and/or the pre-shared key, and compares the computed authentication code to a provided authentication code included in the wake-up message. If the computed authentication code matches the provided authentication code, a wake instruction is sent to the wireless radio to wake the radio from the low power mode. [0026] Existing approaches for the formatting of the wake-up receiver message include fields such as, for example, a transmitter identifier (TXID), a receiver identifier (RXID), and a frame check sum (FCS). However, in some examples, such fields are not necessary. In some examples, the frame check sum field (FCS) includes the authentication code (e.g., a message integrity check (MIC)). In such an example (e.g., where the FCS field includes the authentication code), the FCS field is not omitted. However, if the FCS field does not include the authentication code (e.g., the FCS field includes some other data, such as a cyclical redundancy check (CRC) field) the FCS field may be omitted from the wake-up message.

[0027] Wake-up messages are typically transmitted using low- bandwidth and/or low data rate transmissions. As such, transmission of non- necessary fields should be avoided. In examples disclosed herein, one or more of the transmitter identifier (TXID), the receiver identifier (RXID), and the frame check sum (FCS) fields (when possible) are omitted from the wake-up message. In examples disclosed herein, the wake-up message includes a type field, an authentication field, and one or more other fields.

[0028] Although using a message format with substantially only an authentication field has some benefits, it also leaves the receiver with very little information for processing the wake-up message and/or determining whether to leave the low power state. For example, whereas the wake-up message originally carried the TXID field and RXID field that were used as part of the authentication mechanism, in examples disclosed herein, those fields are not present in the received wake-up message.

[0029] In examples disclosed herein, the receiver supplements the one or more of the transmitter identifier (TXID), the receiver identifier (RXID), and the frame check sum (FCS) fields to re-construct a complete wake-up message (e.g., a message that does not omit fields). In some examples, the transmitter identifier (TXID), the receiver identifier (RXID), and/or the frame check sum (FCS) fields are stored in a memory of the receiver and/or are pre- negotiated when entering the low power mode. In some examples, other information (e.g., extended message content) is also appended to the re- constructed message, to enlarge a potential attack space. The re-constructed message can then be used to calculate the authentication code and determine whether to exit the low power mode.

[0030] Omitting the one or more of the transmitter identifier (TXID), the receiver identifier (RXID), and the frame check sum (FCS) fields enables a longer authentication field to be used in the wake-up message. Using a longer authentication field enhances protection of the authentication field. In examples where the FCS field is used to transmit the authentication code (e.g., the MIC), a longer FCS field may be used. Moreover, using additional information appended to the re-constructed message further ensures that devices are not inadvertently and/or maliciously woken up.

[0031] FIG. 1 is a block diagram of an example environment 100 in which an example transmitter 1 10 wirelessly communicates with a receiver 120. In the illustrated example of FIG. 1, data packets 122 and/or wake-up packets 125 are transmitted between the transmitter 1 10 and the receiver 120.

[0032] The example transmitter 110 of the illustrated example of FIG. 1 is implemented by a wireless access point. However, the example transmitter 1 10 may be implemented by any other type of device that communicates wirelessly. In the illustrated example of FIG. 1 , the example transmitter communicates using an 802.11+ radio 113 using Wi-Fi (e.g., 802.1 1 based technology). However, any other past, present, and/or future wireless communication technologies may additionally or alternatively be used such as, for example, Bluetooth, cellular communications, etc.

[0033] The example receiver 120 of the illustrated example of FIG. 1 is implemented as a mobile device such as, for example, a smart phone.

However, any other device that may enter a low power mode may additionally or alternatively be used such as, for example, a tablet, a laptop, a desktop, an Internet of Things (IoT) device, etc. In examples disclosed herein, the example receiver 120 receives communications from example transmitter 110 using an 802.11+ radio 123 using Wi-Fi (e.g., 802.11 based technology). However, any other past, present, and/or future wireless communication technologies may additionally or alternatively be used such as, for example, Bluetooth, cellular communications, etc. The example receiver 120 of FIG. 1 includes a low- power wake-up radio (LP-WUR) 124 that monitors for wake-up packets (e.g., the wake-up packets 125) and determines whether to wake the 802.1 1+ radio 123.

[0034] FIG. 2 is a block diagram of an example implementation of the example transmitter 1 10 of FIG. 1. In the illustrated example of FIG. 2, the example transmitter 1 10 includes native transmitter functionality 230, one or more antennas 240, a wake-up negotiator 250, and an authentication memory 260.

[0035] The example native transmitter functionality 230 of the illustrated example of FIG. 2 implements intended operations of the example transmitter 1 10. For example, the native transmitter 230 may implement a packet routing system, an operating system, etc. In examples disclosed herein, while the native transmitter functionality 230 is not directly involved in the negotiation or wake-up messages transmitted to the receiver 120, the example native transmitter functionality 230 benefits from the receiver device being promptly woken up.

[0036] The example one or more antennas 240 of the illustrated example of FIG. 2 enable the transmitter 1 10 to wirelessly transmit data (e.g., data packets/messages, wake-up packets/messages) to the receiver 120.

[0037] The example wake-up negotiator 250 of the illustrated example of FIG. 2 negotiates with the receiver 120 to determine field values that will be used when attempting to instruct the receiver 120 to exit the low power mode. In some examples, a transmitter identifier field, a receiver identifier field, an authentication field, a frame check sum field, etc. are pre-negotiated such that the transmitter 1 10 has a record of what information must be transmitted to cause the receiver 120 to exit the low power mode. In some examples, a pre-shared key is additionally negotiated. In some examples, extended message content is negotiated.

[0038] The example authentication memory 260 of the illustrated example of FIG. 2 is implemented by any memory, storage device and/or storage disc for storing data such as, for example, flash memory, magnetic media, optical media, etc. Furthermore, the data stored in the example authentication memory 260 may be in any data format such as, for example, binary data, comma delimited data, tab delimited data, structured query language (SQL) structures, etc. While in the illustrated example the authentication memory 260 is illustrated as a single element, the example authentication memory 260 and/or any other data storage elements described herein may be implemented by any number and/or type(s) of memories. In the illustrated example of FIG. 2, the example authentication memory 260 stores the transmitter identifier field, the receiver identifier field, the authentication field, the frame check sum field, the extended message content, and/or the example pre-shared key that are to be used to instruct the receiver to exit the low power mode.

[0039] FIG. 3 is a block diagram of an example implementation of the example receiver 120 of FIG. 1. The example receiver 120 of the illustrated example of FIG. 3 includes one or more antennas 310, a wireless

communicator 315, a wake-up processor 320, a code generator 321, a receiver memory 322, and native receiver functionality 350.

[0040] The example one or more antennas 310 of the illustrated example of FIG. 3 are antennas that enable the wake-up processor 320 and the wireless communicator 315 to receive data from the transmitter 1 10. In examples disclosed herein, the wake-up processor 320 and the wireless communicator 315 are directly connected to the one or more antennas 310. However, the wake-up processor 320 and/or the wireless communicator 315 may be connected to the one or more antennas 310 in any other fashion.

[0041] The example wireless communicator 315 of the illustrated example of FIG. 3 enables the receiver to communicate with the transmitter 1 10. In examples disclosed herein, the wireless communicator 315 communicates using a WiFi protocol. However, any other past, present, and/or future protocol(s) and/or communication system(s) may additionally or alternatively be used. To conserve power, the example wireless communicator 315 may enter a low power mode. However, when an external device is to communicate with the receiver (e.g., an access point has data that is to be transmitted to the receiver), the wireless communicator 315 can be woken by the example wake-up processor 320.

[0042] The example wake-up processor 320 of the illustrated example of FIG. 3 negotiates an authentication code and a pre-shared key with the transmitter that can be used to identify when the receiver 120 is to exit the low power mode. In examples disclosed herein, the wake-up processor 320 stores the authentication code and the pre-shared key in the receiver memory 322. Upon receipt of a wake-up message, the example wake-up processor 320 extracts data from the received wake-up message (e.g., a message that omits one or more fields), and re-constructs a wake-up message for use in the generation of an authentication code. In some examples, the example wake-up processor 320 appends (and/or prepends) extended message content to the reconstructed message. The example wake-up processor 320 causes the code generator 321 to generate an authentication code based on the re-constructed message and a pre-shared key. The example wake-up processor 320 compares the generated authentication code with the stored authentication code to determine whether to wake the receiver from the low power mode.

[0043] The example code generator 321 of the illustrated example of FIG. 3 generates the authentication code based on the reconstructed wake-up message and the pre-shared key. In examples disclosed herein, the code generator 321 uses an Advanced Encryption Standard (AES) 128 Cooperative Medium Access Control (CMAC) algorithm to generate the authentication code. However, any other code generation approach may additionally or alternatively be used such as, for example, a hash of the wake-up message and the pre-shared key. An example approach for generating the authentication code using the CMAC algorithm based on a re-constructed message and a pre- shared key is shown below in connection with FIGS. 12 and/or 13.

[0044] The example receiver memory 322 of the illustrated example of FIG. 3 is implemented by any memory, storage device and/or storage disc for storing data such as, for example, flash memory, magnetic media, optical media, etc. Furthermore, the data stored in the example receiver memory 322 may be in any data format such as, for example, binary data, comma delimited data, tab delimited data, structured query language (SQL) structures, etc. While in the illustrated example the receiver memory 322 is illustrated as a single element, the example receiver memory 322 and/or any other data storage elements described herein may be implemented by any number and/or type(s) of memories. In the illustrated example of FIG. 3, the example receiver memory 322 stores the pre-shared key and an authentication code that is used to validate the received wake-up message(s). In some examples, the example receiver memory 322 stores one or more of the TXID field, the RXID field, the FCS field, and/or the example extended message content that are used to supplement the authentication field to re-construct a wake-up message.

[0045] The example native receiver functionality 350 of the illustrated example of FIG. 3 implements intended operations of the example receiver 120. For example, the native receiver functionality 350 may implement an operating system, an app, a program, etc. In examples disclosed herein, while the native receiver functionality 350 is not directly involved in the receipt of wake-up messages and/or exiting the low power state, the example native receiver functionality 350 benefits from the ability to be woken up by the transmitter 1 10 as a result of the use of the example approaches disclosed herein.

[0046] FIG. 4 is a communication diagram 400 illustrating example communications between the example receiver 120 of FIG. 1, the example transmitter 1 10 of FIG. 1 , and an attacker 401. In the illustrated example of FIG. 4, the attacker 401 is a third party that can communicate with the receiver 120. In some examples, the attacker 401 may wish to wake a receiver 120 from a low power mode to exploit a vulnerability in the receiver 120.

[0047] The example diagram 400 of FIG. 4 begins when the example receiver 120 determines that it is to enter a low power mode. The example receiver 120 transmits a message to the transmitter 1 10 requesting entry into the low power mode. (Block 405). In some examples, multiple messages are transmitted from the example receiver 120 to the transmitter 1 10 to enable entry into the low power mode. For example, those message(s) may include an indication of a capability of the receiver 120 to receive protected wake-up messages while in the low power mode. The example transmitter provides extended message content and/or other information that will be used to trigger an exit from the low power mode. (Block 412). In some examples, the extended message content and/or other information is received at the receiver 120 via the wireless communicator 315 (e.g., the primary communication radio (PCR)). Moreover, in the illustrated example of FIG. 4, the extended message content and/or other information is provided in response to a request from the receiver to enter the low power mode. However, in some examples, such information may be provided prior to such a request (e.g., may be pre- negotiated). The example receiver 120 stores the extended message content and/or other information, and enters the low power mode. (Block 415). The example receiver 120 exits the low power mode when a valid wake-up message is received. In examples disclosed herein, such validation may be based on the extended message content and/or other information.

[0048] While the example receiver 120 is in the low power mode, the attacker 401 may transmit a wake-up message to the receiver. (Block 420). The receiver 120 then validates the received wake-up message. (Block 423). As noted below in connection with FIGS. 5, 8, and/or 9, the wake-up message includes a message integrity check (MIC) field. The MIC field, in combination with other fields included in the message and/or other pre-shared fields (e.g., the extended message content, the other information, a pre-shared key, etc.), is used to determine whether the wake-up message is valid.

Because the attacker 401 is not aware of the extended message content and/or the other information, the determination of a correct MIC field is

computationally difficult (e.g., time-consuming). Thus, the wake-up message from the attacker 401 is not valid, and the example receiver 120 does not exit the low power mode. (Block 425).

[0049] In the illustrated example of FIG. 4, the example transmitter 1 10 receives data for transmission to the receiver 120. (Block 440). To enable such information to be transmitted to the receiver 120, a wake-up message including authentication information (e.g., the MIC field) is transmitted to the receiver 120. (Block 445). The example wake-up message is then validated by the receiver 120. (Block 448). Because the wake-up message includes the appropriate authentication information, the wake-up message is considered valid by the receiver 120, which then exits the low power mode. (Block 450). The example receiver 120 establishes a primary connection to the transmitter 110 (and/or a network that enables

communication with the transmitter 110). (Block 455). The example transmitter 110 then transmits the data to the receiver 120. (Block 460).

[0050] FIG. 5 is a message protocol diagram illustrating message frames being omitted from the example wake-up message 125 of FIG. 1. The example diagram 500 of the illustrated example of FIG. 5 includes a first wake-up message 510 and a second wake-up message 550. The first wake-up message 510 represents an existing format for a wake-up message transmitted to a receiver 120. The second wake-up message 550 represents a format modified in accordance with teachings of this disclosure that omits one or more of the example TXID field, the RXID field, and/or the FCS field (e.g., when the FCS field does not include the MIC) to reduce message size.

[0051] The first example message 510 includes a type field 512, a transmitter identifier (TXID) field 514, a receiver identifier (RXID) field 516, an authentication field 518, one or more other fields 520, and a frame checksum (FCS) field 522. The example type field 512 is a two-bit field that is used to identify the type of the message (e.g., to identify the message as a wake-up message). The example TXID field 514 identifies the transmitter transmitting the message (e.g., the transmitter 110). The example RXID field 516 identifies the receiver to which the message is directed (e.g., the receiver 120). The authentication field 518 includes data that, when used as part of an input to the example code generator 321 (e.g., along with a pre-shared key and/or other stored data), results in computation of an authentication code. The example other fields 520 represent one or more other fields that may be used to extend the functionality of the wake-up message 510.

[0052] The example FCS field 522 represents data that is used to validate a frame containing the FCS field. In some examples, the FCS field 522 includes a cyclical redundancy check (CRC) that enables the receiver to perform validation on the message to determine whether the message was corrupted during transmission. In some other examples, the FCS field 522 includes a message integrity check (MIC) that enables validation of whether to wake a receiver from a low power mode. In some examples, whether the FCS field includes the CRC or the MIC is identified by the type field 512 and/or a portion thereof.

[0053] In accordance with teachings of this disclosure, messages formatted like the first example message 510 include fields that do not necessarily need to be transmitted for determining whether to exit the low power mode. For example, when negotiating entry into the low power mode, the receiver 120 identifies the transmitter (e.g., the TXID field) that is allowed to transmit a message that brings the receiver out of the low power mode. Likewise, the receiver 120 knows and/or has access to its own identifier (e.g., the RXID field). In some examples, the authentication field 518 can be pre- negotiated and/or set to a default value, as the error protection provided by the authentication field 518 ensures that devices to which the message was not intended do not mistakenly wake-up. Moreover, in some examples, additional extended message content can be combined with the other message components to increase the length of the re-constructed message. Thus, the second example message 550 of the illustrated example of FIG. 5 includes the type field 512, the authentication field 518, the one or more other fields 520, and the FCS field 522 (e.g., formatted to include the MIC data).

[0054] FIG. 6 is a message protocol diagram illustrating example extended message content 600. In the illustrated example of FIG. 6, the example extended message content 600 includes a defined portion 605 and a WUR transmitter indicated portion 650. In examples disclosed herein, the specification defined portion 605 includes information such as, for example, part of or all of a MAC address for the wireless communicator 315 (e.g., the primary connectivity radio (PCR)) of the receiver 120, part of or all of the MAC address for the transmitter 110, part or all of the MAC address for the wake-up processor 320 of the receiver 120, other information, a combination of one or more of these, a hash of the combination, a hash of one or more of these, etc.

[0055] In some examples, the extended message content 600 may include a basic service set identifier (BSSID). In some examples, the BSSID may be provided in an embedded format. That is, while a BSSID may include 48 bits, the embedded BSSID may be derived from the BSSID but only include 16 bits. In some examples, the embedded BSSID is derived by generating a hash of the BSSID (e.g., a cyclical redundancy check (CRC) hash), and then selecting a number of bits (e.g., the sixteen least significant bits (LSBs), the sixteen most significant bits (MSBs), etc.) as the embedded BSSID.

[0056] In examples disclosed herein, the example WUR transmitter indicated portion 650 includes any data that the transmitter 110 determines to use for the extended message content 600. For example, the transmitter 110 may generate a pseudorandom number, identify field values, indicate a calculation based on different field values and/or other data to include as the extended message content 600. In some examples, the transmitter 110 transmits the WUR transmitter indicated portion 650 in a WUR packet such as a WUR beacon or a WUR action frame such as, for example, a WUR response. In some other examples, the extended message content may be transmitted

[0057] FIG. 7 is a message protocol diagram illustrating alternative example extended message content 700. In contrast, the example extended message content 600 of FIG. 6, in some examples, the extended message content (e.g., the extended message content 700 of FIG. 7) may omit the specification defined portion 605. Thus, the example extended message content 700 may include only a portion determined by the example transmitter 110.

[0058] FIG. 8 is a block diagram illustrating an example structure of an example wake-up packet 800. The example wake-up packet 800 of FIG. 8 includes an IEEE 802.11 preamble 810 (e.g., an IEEE 802.11ah preamble). In the illustrated example of FIG. 8, the preamble 810 includes an STF field 812, an LTF field 814, and a SIG field 816. In some examples, the preamble 810 includes a legacy IEEE 802.11 preamble followed by a high efficiency (HE) preamble. After the 802.11 preamble(s) 810 (which may be transmitted across the entire bandwidth of the channel), the example WUR packet 800 includes a wake-up preamble 820, a MAC header 830, a payload 840, and a frame check sequence (FCS) field 850.

[0059] The example MAC header 830 of FIG. 8 includes a receiver address. In some examples, the MAC header 830 includes additional information. In some other examples, the MAC header 830 includes a partial MAC address.

[0060] The example payload 840 of FIG. 8 includes an action identifier (ID) 842 and an action payload 844. The example action ID 842 identifies a structure and/or format of the action payload 844. The example action payload 844 includes an instruction to wake a main radio such as an IEEE 802.1 lax radio. In some examples, the instruction causes the radio to wake immediately. In some other examples, the instruction causes the radio to wake after a period of time. In some examples, the period of time may identify a target time for the main radio to be ready to receive a packet.

[0061] Transmission of a WUR packet (e.g., WUR packet 800 of FIG. 8) from a transmitter (e.g., the transmitter 110) may involve utilization of one or more of transmission rates of the WUR packet. In some examples, reception of a WUR packet at WUR devices may involve a WUR device that is unaware of whether the packet is a multi-user transmission (e.g., multiplexed with 802.11ax) or a single user transmission.

[0062] FIG. 9 is a message protocol diagram illustrating reconstruction of an example message using information provided in a wake-up message and extended message content 650. The example diagram 900 of FIG. 9 includes a wake-up packet 901, and a reconstructed message 950. The example wake-up packet 901 corresponds to the wake-up packet 800 of FIG. 8 and/or the wake-up packets 510, 550 of FIG. 5. In the illustrated example of FIG. 9, the example wake-up packet 901 includes included fields 905 and an FCS field 518 that, in this example, represents a MIC. In the illustrated example of FIG. 9, the included fields 905 may represent any field included in the wake-up packet 901 such as, for example, a MAC header (e.g., the MAC header 830 of FIG. 8), a payload (e.g., the payload 840 of FIG. 8), a preamble (e.g., the 802.11 preamble 810 and/or the example wake-up preamble 820 of FIG. 8), a TXID (e.g., the TXID 514 of FIG. 5), a RXID (e.g., the RXID 516 of FIG. 5), an authentication field (e.g., the authentication field 518 of FIG. 5), and/or any other field.

[0063] The example message M 950 of the illustrated example of FIG. 9 is constructed using the included fields 905 from the wake-up message, one or more other non-included fields 910, and, in some examples, extended message content (e.g., the extended message content 600 of FIG. 6). The example message M 950 is constructed by concatenating the included fields 905 with the non-included fields 910. However, any other approach to generating and/or structuring a message may additionally or alternatively be used. Moreover, any ordering of the fields from the included fields 905 and/or the non-included fields 910 may additionally or alternatively be used.

[0064] In some examples, the included fields 905 may omit one or more of the fields transmitted in the wake-up packet. That is, one or more of the fields transmitted in the wake-up packet may not be used for construction of the message M.

[0065] The non-included fields 910 of the illustrated example of FIG. 9 represent fields that are not provided as part of the wake-up message. The non-included fields 910 include, for example, a TXID (e.g., the TXID 514 of FIG. 5), an RXID (e.g., the RXID 516 of FIG. 5). In the illustrated example of FIG. 9, the non-included fields 910 includes extended message content (e.g., the extended message content 600 of FIG. 6). By inclusion of the extended message content 600, the length of the message M can be increased, thereby avoiding the need to apply padding to the message prior to computing a MIC based on the message.

[0066] While an example manner of implementing the example receiver 120 of FIG. 1 is illustrated in FIG. 3, one or more of the elements, processes and/or devices illustrated in FIGS. 1 and/or 3 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. While an example manner of implementing the example transmitter 110 of FIG. 1 is illustrated in FIG. 2, one or more of the elements, processes and/or devices illustrated in FIGS. 1 and/or 2 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example native transmitter functionality 230, the example antennas 240, the example wake-up negotiator 250, the example authentication memory 260, and/or, more generally, the example transmitter 110 of FIGS. 1 and/or 2, the example one or more antennas 310, the example wireless communicator 315, the example wake-up processor 320, the example code generator 321, the example receiver memory 322, the example native receiver functionality 350, and/or more generally, the example receiver 120 of FIGS. 1 and/or 3 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example native transmitter functionality 230, the example antennas 240, the example wake-up negotiator 250, the example authentication memory 260, and/or, more generally, the example transmitter 110 of FIGS. 1 and/or 2, the example one or more antennas 310, the example wireless communicator 315, the example wake-up processor 320, the example code generator 321, the example receiver memory 322, the example native receiver functionality 350, and/or more generally, the example receiver 120 of FIGS. 1 and/or 3 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s)

(ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware

implementation, at least one of the example native transmitter functionality 230, the example antennas 240, the example wake-up negotiator 250, the example authentication memory 260, and/or, more generally, the example transmitter 110 of FIGS. 1 and/or 2, the example one or more antennas 310, the example wireless communicator 315, the example wake-up processor 320, the example code generator 321, the example receiver memory 322, the example native receiver functionality 350, and/or more generally, the example receiver 120 of FIGS. 1 and/or 3 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the example access transmitter 110 and/or the example receiver 120 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in FIGS. 1, 2, and/or 3, and/or may include more than one of any or all of the illustrated elements, processes and devices.

[0067] Flowcharts representative of example machine readable instructions for implementing the example receiver 120 FIGS. 1 and/or 3 are shown in FIGS. 10 and/or 11. In these example(s), the machine-readable instructions comprise a program(s) for execution by a processor such as the processor 1812 shown in the example processor platform 1800 discussed below in connection with FIG. 18. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD- ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 1812, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 1812 and/or embodied in firmware or dedicated hardware. Further, although the example program(s) is/are described with reference to the flowcharts illustrated in FIGS. 10 and/or 11, many other methods of implementing the example receiver 120 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, a Field Programmable Gate Array (FPGA), an Application Specific Integrated circuit (ASIC), a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware. [0068] As mentioned above, the example processes of FIGS. 10 and/or 11 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a readonly memory, a compact disk, a digital versatile disk, a cache, a random- access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

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

[0070] FIG. 10 is a flowchart illustrating an example process that may be implemented by machine readable instructions to implement the receiver 120 of FIGS. 1 and/or 3 to enter a low power mode. The example process 1000 of the illustrated example of FIG. 10 begins when the example receiver 120 identifies that it is to enter the low power mode. In some examples, the receiver 120 identifies that the receiver 120 is to enter the low power mode in response to a user command (e.g., a user command indicating that the receiver 120 is to enter a sleep mode). In some examples, the receiver 120 identifies that the receiver 120 is to enter the low power mode in response to expiration of an inactivity timer.

[0071] The example wake-up processor 320 of the example receiver 120 negotiates an authentication code and/or a pre-shared key that can be used to identify when to exit the low power mode. (Block 1010). The example wake-up processor 320 stores the authentication code in the receiver memory 322. (Block 1015). The example wake-up processor 320 stores the pre-shared key in the receiver memory 322. (Block 1020). The example wake-up processor 320 accesses an extended message content provided by the transmitter 110, and stores the extended message content in the receiver memory 322. (Block 1025). In some examples, one or more of the authentication code, the pre-shared key, and/or the extended message content may be pre-negotiated. That is the one or more of the authentication code, the pre-shared key, and/or the extended message content may be provided to the receiver 120 prior to a time when the example receiver 120 determines that the receiver is to enter the low power mode. The example wake-up processor 320 then directs the example wireless communicator 315 to enter the low power mode. (Block 1030). While in the low power mode, the example wake-up processor 320 monitors for incoming wake-up messages and, upon receipt of a wake-up message, determines whether to exit the low power mode.

[0072] FIG. 11 is a flowchart illustrating an example process that may be implemented by machine readable instructions to implement the receiver 120 of FIGS. 1 and/or 3 to exit a low power mode. The example process 1100 of the illustrated example of FIG. 11 begins when the example wake-up processor 320 receives a message. The example wake-up processor 320 determines whether the received message is a wake-up message. (Block 1110). In some examples, the message is identified as a wake-up message based on information included in a type field (e.g., the type field 512 of FIG. 5) such as, for example, a frame control tag. If the message is not a wake-up message (Block 1110 returns a result of NO), the example process of FIG. 11 terminates. If the message is a wake-up message (Block 1110 returns a result of YES), the example wake-up processor 320 extracts an authentication field (e.g., the authentication field 518 of FIG. 5) from the received message.

(Block 1120).

[0073] The example wake-up processor 320 determines one or more of the TXID field, the RXID field, the extended message content, and/or the FCS field (e.g., fields omitted from the received wake-up message). (Block 1125). In some examples, one or more of the TXID field, the RXID field, the extended message content, and/or the FCS field may be retrieved from the receiver memory 322.

[0074] In examples disclosed herein, the TXID field may be, for example, a media access control (MAC) address of the transmitter, a portion of the MAC address of the transmitter, etc. However, any other type of identifier may additionally or alternatively be used. In some examples, the TXID is provided by the transmitter 110 as part of the initial negotiation of the authentication code. In some examples, the TXID is stored in the receiver memory 322.

[0075] Likewise, the RXID may be, for example, a MAC address of the receiver, a portion of the MAC address of the receiver, etc. However, any other type of identifier may additionally or alternatively be used. In some examples, the RXID is an association identifier (AID) allocated in the main radio (e.g., the wireless communicator 315) that is associated with the basic service set (BSS). In some examples, an embedded BSSID (e.g., a 16-bit value) is used instead of a BSSID (e.g., a 48-bit value). In some examples, the RXID is provided by the transmitter as part of the initial negotiation of the authentication code. In some examples, the RXID is stored in the receiver memory 322.

[0076] The example FCS field may be determined based on, for example, a stored value (e.g., a pre-negotiated value stored in the receiver memory 322). In some examples, the FCS field is set to a default value (e.g., all 0's).

[0077] Using one or more of the example TXID, the example RXID, the example extended message content, the example FCS field, and/or the example extracted authentication field, the example wake-up processor 320 reconstructs a message that includes the one or more fields that were omitted from the received message (e.g., constructs a message that is formatted similarly to the example message 950 of FIG. 9). (Block 1130).

[0078] Using the reconstructed message and the pre-shared key (stored in the receiver memory 322 at block 1025 of FIG. 10), the example code generator 321 generates an authentication code using a function "P. In examples disclosed herein, the example code 321 generator implements a function "P that produces an output based on the input message and pre- shared key. In some examples, the function "P provides an output with a length based on the length of the inputs (e.g., the pre-shared key and/or the message) that are used. Because transmission times and/or bandwidth for wake-up messages are limited, it is advantageous to transmit a shorter authentication field. For example, typical lengths for authentication fields may include 8 bytes or 16 bytes. This then results in an overhead of approximately one millisecond or two milliseconds, respectively, when a transmission rate of 62.5 kilobits per second is used, which is the expected lowest data rate for wake-up message transmission.

[0079] In examples disclosed herein, the message is constructed based on the extracted authentication field (and one or more of the example TXID field, the example RXID field, the example extended message content, and/or the example FCS field) and has a length of "Y". When, for example, long extended message content (e.g., message content having 128 bits), the message length of "Y" will be longer than a length of the pre-shared key "X".

[0080] However, in some other examples, the pre-shared key will have a length "X" that is greater than Y. In some such examples, the example wake- up processor 320 truncates the pre-shared key to have a length of "Y" (e.g., such that the length of the message is equal to the length of the truncated pre- shared key). (Block 1135). In some examples, the "Y" most significant bits of the pre-shared key are selected. However, in some other examples, the "Y" least significant bits of the pre-shared key are selected. Of course, any other approach to truncating the pre-shared key may additionally or alternatively be used. [0081] While in the illustrated example of FIG. 11, the truncation of the pre-shared key occurs during processing of the received wake-up message, such truncation may instead be performed during negotiation of the pre-shared key in connection with the illustrated example of FIG. 10.

[0082] Moreover, in some examples, truncation of the pre-shared key may be omitted. In some examples, the authentication code may be generated using the reconstructed message and the (non-truncated) pre-shared key, and the resulting authentication code may then be truncated to be a same length as a provided authentication code (e.g., the MIC field 518 of FIG. 9).

[0083] Using the reconstructed message and the pre-shared key, the example code generator 321 generates an authentication code. (Block 1140). The example wake-up processor 320 determines whether the generated authentication code matches the provided authentication code (e.g., the MIC field 518 of FIG. 9). (Block 1150). If the generated authentication code matches the provided authentication code (Block 1150 returns a result of YES), the example wake-up processor 320 transmits a wake-up instruction to the wireless communicator 315 (e.g., the primary and/or main radio) to wake the receiver from the low power mode. (Block 1160). The receiver 120 then exits the low power mode. If the generated authentication code does not match the provided authentication code (Block 1150 returns a result of NO), the example process of FIG. 11 terminates. The example process of FIG. 11 may then be repeated upon receipt of a subsequent message.

[0084] FIG. 12 is a block diagram illustrating an example 1200 approach for computation of a message integrity check (MIC). The example approach of FIG. 12 is used when, for example, the re-constructed message can be split into an integer number of message blocks. In the illustrated example of FIG. 12, the message M can be split into three 128-bit message blocks 1210, 1212, 1214. However, any number of message blocks having any other block size may additionally or alternatively be used.

[0085] FIG. 13 is a block diagram illustrating an example approach for computation of a message integrity check (MIC). In some examples, the message M is of a length that is not evenly divisible by the block length. In such a case, the last message block (e.g., message block 1314 of FIG. 13) is padded with additional data (e.g., consecutive values 10...0) (block 1316) to meet the block size b. In the illustrated example of FIG. 13, a key (e.g., key 1332) that is different from the key of FIG. 12 is used (e.g., key 1230).

[0086] In the illustrated examples of FIGS. 12 and/or 13, first, the message (M) (e.g., the reconstructed message 950 of FIG. 9) is split into blocks Mi with block size b (e.g., message blocks 1210, 1212, 1214 of FIGS. 12 and/or 13). Next, a block cipher (e.g., block cipher 1220) applied to the first block, and an output of the block cipher is XOR'ed with the next block (e.g., block 1212). The block cipher (e.g., block cipher 1221) is then applied to the output of the XOR, and the resultant output is XOR'ed with the next subsequent block (e.g., message block 3 1214 of FIG. 12 or message block 3 1214 of FIG. 13 with message padding 1316 applied). This ciphering and XOR'ing process is repeated until all message blocks have been accounted for (e.g., until a final block cipher 1222 is applied). Lastly, the output of the final cipher (e.g., block cipher 1222) is truncated to T bits (block 1240). In examples disclosed herein, the most significant bits (MSB) are selected. However, truncation may be performed in any other fashion. For example, the least significant bits (LSB) may be selected.

[0087] In the illustrated examples of FIGS. 12 and/or 13, the block cipher (e.g., block ciphers 1220, 1221, 1222) is an AES block cipher operation with key K. However, any other type of cipher and/or hashing function may additionally or alternatively be used.

[0088] FIG. 14 is a block diagram of a radio architecture 1400 in accordance with some embodiments. Radio architecture 1400 may include radio front-end module (FEM) circuitry 1404, radio IC circuitry 1406 and baseband processing circuitry 1408. Radio architecture 1400 as shown includes both Wireless Local Area Network (WLAN) functionality and Bluetooth (BT) functionality although embodiments are not so limited. In this disclosure, "WLAN" and "Wi-Fi" are used interchangeably.

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

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

[0091] Baseband processing circuity 1408 may include a WLAN baseband processing circuitry 1408a and a BT baseband processing circuitry 1408b. The WLAN baseband processing circuitry 1408a may include a memory, such as, for example, a set of RAM arrays in a Fast Fourier

Transform or Inverse Fast Fourier Transform block (not shown) of the WLAN baseband processing circuitry 1408a. Each of the WLAN baseband circuitry 1408a and the BT baseband circuitry 1408b may further include one or more processors and control logic to process the signals received from the corresponding WLAN or BT receive signal path of the radio IC circuitry 1406, and to also generate corresponding WLAN or BT baseband signals for the transmit signal path of the radio IC circuitry 1406. Each of the baseband processing circuitries 1408a and 1408b may further include physical layer (PHY) and medium access control layer (MAC) circuitry, and may further interface with application processor 1410 for generation and processing of the baseband signals and for controlling operations of the radio IC circuitry 1406.

[0092] Referring still to FIG. 14, according to the shown embodiment, WLAN-BT coexistence circuitry 1413 may include logic providing an interface between the WLAN baseband circuitry 1408a and the BT baseband circuitry 1408b to enable use cases requiring WLAN and BT coexistence. In addition, a switch 1403 may be provided between the WLAN FEM circuitry 1404a and the BT FEM circuitry 1404b to allow switching between the WLAN and BT radios according to application needs. In addition, although the antennas 1401 are depicted as being respectively connected to the WLAN FEM circuitry 1404a and the BT FEM circuitry 1404b, embodiments include within their scope the sharing of one or more antennas as between the WLAN and BT FEMs, or the provision of more than one antenna connected to each of FEM 1404a or 1404b.

[0093] In some embodiments, the front-end module circuitry 1404, the radio IC circuitry 1406, and baseband processing circuitry 1408 may be provided on a single radio card, such as wireless radio card 1402. In some other embodiments, the one or more antennas 1401, the FEM circuitry 1404 and the radio IC circuitry 1406 may be provided on a single radio card. In some other embodiments, the radio IC circuitry 1406 and the baseband processing circuitry 1408 may be provided on a single chip or integrated circuit (IC), such as IC 1412.

[0094] In some embodiments, the wireless radio card 1402 may include a WLAN radio card and may be configured for Wi-Fi

communications, although the scope of the embodiments is not limited in this respect. In some of these embodiments, the radio architecture 1400 may be configured to receive and transmit orthogonal frequency division multiplexed (OFDM) or orthogonal frequency division multiple access (OFDMA) communication signals over a multicarrier communication channel. The OFDM or OFDMA signals may comprise a plurality of orthogonal subcarriers.

[0095] In some of these multicarrier embodiments, radio architecture 1400 may be part of a Wi-Fi communication station (STA) such as a wireless access point (AP), a base station or a mobile device including a Wi-Fi device. In some of these embodiments, radio architecture 1400 may be configured to transmit and receive signals in accordance with specific communication standards and/or protocols, such as any of the Institute of Electrical and Electronics Engineers (IEEE) standards including, 802.1 ln-2009, IEEE 802.11-2012, IEEE 802.11-2016, 802.11n-2009, 802.1 lac, 802.11ah, 802.11 ad, 802.11 ay, and/or 802.11 ax standards and/or proposed specifications for WLANs, although the scope of embodiments is not limited in this respect. Radio architecture 1400 may also be suitable to transmit and/or receive communications in accordance with other techniques and standards.

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

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

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

[0099] In some embodiments, the radio-architecture 1400 may include other radio cards, such as a cellular radio card configured for cellular (e.g., 6GPP such as LTE, LTE-Advanced or 5G communications).

[00100] In some IEEE 802.1 1 embodiments, the radio architecture 1400 may be configured for communication over various channel bandwidths including bandwidths having center frequencies of about 900 MHz, 2.4 GHz, 5 GHz, and bandwidths of about 2MHz, 4 MHz, 5 MHz, 5.5 MHz, 7 MHz, 8 MHz, 10 MHz, 40 MHz, 46 MHz, 50 MHz, 70MHz, 80MHz (with contiguous bandwidths) or 80+80MHz (160MHz) (with non-contiguous bandwidths). In some embodiments, a 620 MHz channel bandwidth may be used. The scope of the embodiments is not limited with respect to the above center frequencies however.

[00101] FIG. 15 illustrates FEM circuitry 1500 in accordance with some embodiments. The FEM circuitry 1500 is one example of circuitry that may be suitable for use as the WLAN and/or BT FEM circuitry

1404a/1404b (FIG. 14), although other circuitry configurations may also be suitable.

[00102] In some embodiments, the FEM circuitry 1500 may include a TX/RX switch 1502 to switch between transmit mode and receive mode operation. The FEM circuitry 1500 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 1500 may include a low-noise amplifier (LNA) 1506 to amplify received RF signals 1503 and provide the amplified received RF signals 1507 as an output (e.g., to the radio IC circuitry 1406 (FIG. 14)). The transmit signal path of the circuitry 1500 may include a power amplifier (PA) to amplify input RF signals 1509 (e.g., provided by the radio IC circuitry 1406), and one or more filters 1512, such as band-pass filters (BPFs), low-pass filters (LPFs) or other types of filters, to generate RF signals 1515 for subsequent transmission (e.g., by one or more of the antennas 1401 (FIG. 14)).

[00103] In some dual-mode embodiments for Wi-Fi

communication, the FEM circuitry 1500 may be configured to operate in either the 2.4 GHz frequency spectrum or the 5 GHz frequency spectrum. In these embodiments, the receive signal path of the FEM circuitry 1500 may include a receive signal path duplexer 1504 to separate the signals from each spectrum as well as provide a separate LNA 1506 for each spectrum as shown. In these embodiments, the transmit signal path of the FEM circuitry 1500 may also include a power amplifier 1510 and a filter 1512, such as a BPF, a LPF or another type of filter for each frequency spectrum and a transmit signal path duplexer 1514 to provide the signals of one of the different spectrums onto a single transmit path for subsequent transmission by the one or more of the antennas 1401 (FIG. 14). In some embodiments, BT communications may utilize the 2.4 GHZ signal paths and may utilize the same FEM circuitry 1500 as the one used for WLAN communications.

[00104] FIG. 16 illustrates radio IC circuitry 1600 in accordance with some embodiments. The radio IC circuitry 1600 is one example of circuitry that may be suitable for use as the WLAN or BT radio IC circuitry 1406a/1406b (FIG. 14), although other circuitry configurations may also be suitable.

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

[00106] In some embodiments, mixer circuitry 1602 may be configured to down-convert RF signals 1507 received from the FEM circuitry 1404 (FIG. 14) based on the synthesized frequency 1605 provided by synthesizer circuitry 1604. The amplifier circuitry 1606 may be configured to amplify the down-converted signals and the filter circuitry 1608 may include a LPF configured to remove unwanted signals from the down-converted signals to generate output baseband signals 1607. Output baseband signals 1607 may be provided to the baseband processing circuitry 1408 (FIG. 14) for further processing. In some embodiments, the output baseband signals 1607 may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1602 may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[00107] In some embodiments, the mixer circuitry 1614 may be configured to up-convert input baseband signals 161 1 based on the synthesized frequency 1605 provided by the synthesizer circuitry 1604 to generate RF output signals 1509 for the FEM circuitry 1404. The baseband signals 161 1 may be provided by the baseband processing circuitry 1408 and may be filtered by filter circuitry 1612. The filter circuitry 1612 may include a LPF or a BPF, although the scope of the embodiments is not limited in this respect. [00108] In some embodiments, the mixer circuitry 1602 and the mixer circuitry 1614 may each include two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion respectively with the help of synthesizer 1604. In some embodiments, the mixer circuitry 1602 and the mixer circuitry 1614 may each include two or more mixers each configured for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1602 and the mixer circuitry 1614 may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, the mixer circuitry 1602 and the mixer circuitry 1614 may be configured for super-heterodyne operation, although this is not a requirement.

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

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

[00111] In some embodiments, the LO signals may differ in duty cycle (the percentage of one period in which the LO signal is high) and/or offset (the difference between start points of the period). In some

embodiments, the LO signals may have a 55% duty cycle and a 50% offset. In some embodiments, each branch of the mixer circuitry (e.g., the in-phase (I) and quadrature phase (Q) path) may operate at a 55% duty cycle, which may result in a significant reduction is power consumption.

[00112] The RF input signal 1507 (FIG. 15) may comprise a balanced signal, although the scope of the embodiments is not limited in this respect. The I and Q baseband output signals may be provided to low-nose amplifier, such as amplifier circuitry 1606 (FIG. 16) or to filter circuitry 1608 (FIG. 16).

[00113] In some embodiments, the output baseband signals 1607 and the input baseband signals 1611 may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals 1607 and the input baseband signals 1611 may be digital baseband signals. In these altemate embodiments, the radio IC circuitry may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry.

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

[00115] In some embodiments, the synthesizer circuitry 1604 may be a fractional -N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1604 may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

According to some embodiments, the synthesizer circuitry 1604 may include digital synthesizer circuitry. An advantage of using a digital synthesizer circuitry is that, although it may still include some analog components, its footprint may be scaled down much more than the footprint of an analog synthesizer circuitry. In some embodiments, frequency input into synthesizer circuity 1604 may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. A divider control input may further be provided by either the baseband processing circuitry 1408 (FIG. 14) or the application processor 1410 (FIG. 14) depending on the desired output frequency 1605. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table (e.g., within a Wi-Fi card) based on a channel number and a channel center frequency as determined or indicated by the application processor 1410.

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

[00117] FIG. 17 illustrates a functional block diagram of baseband processing circuitry 1700 in accordance with some embodiments. The baseband processing circuitry 1700 is one example of circuitry that may be suitable for use as the baseband processing circuitry 1408 (FIG. 14), although other circuitry configurations may also be suitable. The baseband processing circuitry 1700 may include a receive baseband processor (RX BBP) 1702 for processing receive baseband signals 1609 provided by the radio IC circuitry 1406 (FIG. 14) and a transmit baseband processor (TX BBP) 1704 for generating transmit baseband signals 161 1 for the radio IC circuitry 1406. The baseband processing circuitry 1700 may also include control logic 1706 for coordinating the operations of the baseband processing circuitry 1700.

[00118] In some embodiments (e.g., when analog baseband signals are exchanged between the baseband processing circuitry 1700 and the radio IC circuitry 1406), the baseband processing circuitry 1700 may include ADC 1710 to convert analog baseband signals 1709 received from the radio IC circuitry 1406 to digital baseband signals for processing by the RX BBP 1702. In these embodiments, the baseband processing circuitry 1700 may also include DAC 1712 to convert digital baseband signals from the TX BBP 1704 to analog baseband signals 1711. [00119] In some embodiments that communicate OFDM signals or OFDMA signals, such as through baseband processor 1408a, the transmit baseband processor 1704 may be configured to generate OFDM or OFDMA signals as appropriate for transmission by performing an inverse fast Fourier transform (IFFT). The receive baseband processor 1702 may be configured to process received OFDM signals or OFDMA signals by performing an FFT. In some embodiments, the receive baseband processor 1702 may be configured to detect the presence of an OFDM signal or OFDMA signal by performing an autocorrelation, to detect a preamble, such as a short preamble, and by performing a cross-correlation, to detect a long preamble. The preambles may be part of a predetermined frame structure for Wi-Fi communication.

[00120] Referring back to FIG. 14, in some embodiments, the antennas 1401 (FIG. 14) may each comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some multiple-input multiple-output (MIMO) embodiments, the antennas may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result. Antennas 1401 may each include a set of phased-array antennas, although embodiments are not so limited.

[00121] Although the radio-architecture 1400 is illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements. [00122] FIG. 18 is a block diagram of an example processor platform 1800 capable of executing the instructions of FIGS. 10 and/or 11 to implement the example receiver 120 of FIGS. 1 and/or 3. The processor platform 1800 can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, or any other type of computing device.

[00123] The processor platform 1800 of the illustrated example includes a processor 1812. The processor 1812 of the illustrated example is hardware. For example, the processor 1812 can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. The example processor 1812 includes the wake-up processor 320, the example code generator 321, and the example native receiver functionality 350.

[00124] The processor 1812 of the illustrated example includes a local memory 1813 (e.g., a cache). The processor 1812 of the illustrated example is in communication with a main memory including a volatile memory 1814 and a non-volatile memory 1816 via a bus 1818. The volatile memory 1814 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 1816 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 1814, 1816 is controlled by a memory controller.

[00125] The processor platform 1800 of the illustrated example also includes an interface circuit 1820. The interface circuit 1820 may be implemented by any type of interface standard, such as an Ethemet interface, a universal serial bus (USB), and/or a PCI express interface. [00126] In the illustrated example, one or more input devices

1822 are connected to the interface circuit 1820. The input device(s) 1822 permit(s) a user to enter data and/or commands into the processor 1812. The input device(s) can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.

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

[00128] The interface circuit 1820 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 1826 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.). In the illustrated example of FIG. 18, the example interface circuit 1820 implements the example wireless communicator 315 and/or the example antennas 310.

[00129] The processor platform 1800 of the illustrated example also includes one or more mass storage devices 1828 for storing software and/or data. Examples of such mass storage devices 1828 include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives. In some examples, the one or more mass storage devices 1828 implements the example receiver memory 322.

[00130] The coded instructions 1832 of FIGS. 10 and/or 11 may be stored in the mass storage device 1828, in the volatile memory 1814, in the non-volatile memory 1816, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

[00131] From the foregoing, it will be appreciated that the methods and apparatus disclosed herein facilitate the better use of available wireless spectrum by omitting and/or otherwise removing one or more fields from wake-up messages transmitted from a transmitter to a receiver.

Moreover, example approaches disclosed herein utilize extended message content to supplement a message used to authenticate whether to wake a receiver, thereby reducing a potential attack space that may be used to wake the receiver.

[00132] It is noted that this patent claims priority from United

States Provisional Patent Application Serial Number 62/529,435, which was entitled "METHODS AND APPARATUS TO WAKE A RECEIVER," and was filed on July 6, 2017, and also claims priority from United States Provisional Patent Application Serial Number 62/575,352, which was entitled "METHODS AND ARRANGEMENTS FOR WAKE-UP RADIO FRAME AUTHENTICATION," and was filed on October 20, 2017. U.S. Provisional Patent Application Serial No. 62/529,435 and U.S. Provisional Patent Application Serial No. 62/575,352 are hereby incorporated by reference in their entireties.

[00133] Example 1 includes an apparatus to wake a receiver, the apparatus comprising a receiver memory to store a pre-shared key and one or more pre-shared fields, a wake-up processor to extract an authentication field from a received wake-up message, the received wake-up message including a message integrity check field, and generate a re-constructed wake-up message based on the authentication field and at least one of the one or more pre-shared fields, and a code generator to generate an authentication code using the reconstructed wake-up message and the pre-shared key, the wake-up processor to, in response to determining that the authentication code matches the message integrity check field, cause a wireless communicator of the receiver to exit a low power mode. [00134] Example 2 includes the apparatus of example 1, wherein the wireless communicator is a primary communication radio.

[00135] Example 3 includes the apparatus of example 1, wherein the one or more pre-shared fields includes an extended message content field.

[00136] Example 4 includes the apparatus of example 1, wherein the code generator is to generate the authentication code by splitting the re-constructed wake-up message into message blocks, applying a block cipher to the message blocks, and truncating a result of the block cipher.

[00137] Example 5 includes the apparatus of example 4, wherein the truncation of the result of the block cipher results in creation of the authentication code having a same length as the message integrity check field.

[00138] Example 6 includes the apparatus of example 1, wherein the one or more pre-shared fields includes a transmitter identifier.

[00139] Example 7 includes the apparatus of example 1, wherein the one or more pre-shared fields includes a receiver identifier.

[00140] Example 8 includes the apparatus of any one of examples 1 through 7, wherein the one or more pre-shared fields are not included in the received wake-up message.

[00141] Example 9 includes the apparatus of example 1, wherein the pre-shared key and the one or more pre-shared fields are provided to the apparatus prior to the apparatus entering the low power mode.

[00142] Example 10 includes the apparatus of example 1, wherein the wake-up processor is to identify that the apparatus is to enter the low power mode, and the pre-shared key and the one or more pre-shared fields are provided to the apparatus prior to the wake-up processor identifying that the apparatus is to enter the low power mode.

[00143] Example 11 includes the apparatus of example 1, wherein the code generator is to truncate the pre-shared key.

[00144] Example 12 includes at least one non-transitory computer readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to at least store a pre- shared key and one or more pre-shared fields, extract an authentication field from a received wake-up message, the received wake-up message including a message integrity check field, generate a re-constructed wake-up message based on the authentication field and at least one of the one or more pre-shared fields, generate an authentication code using the re-constructed wake-up message and the pre-shared key, and in response to the authentication code matching the message integrity check field, cause a wireless communicator to exit a low power mode.

[00145] Example 13 includes the at least one non-transitory computer-readable medium of example 12, wherein the one or more pre- shared fields includes an extended message content field.

[00146] Example 14 includes the at least one non-transitory computer-readable medium of example 12, wherein instructions, when executed by the at least one processor, cause the at least one processor to generate the authentication code by splitting the re-constructed wake-up message into message blocks, applying a block cipher to the message blocks, and truncating a result of the block cipher to produce the authentication code.

[00147] Example 15 includes the at least one non-transitory computer-readable medium of example 14, wherein the truncation of the result of the block cipher results in the authentication code having a same length as the message integrity check field.

[00148] Example 16 includes the at least one non-transitory computer-readable medium of example 12, wherein the one or more pre- shared fields includes a transmitter identifier.

[00149] Example 17 includes the at least one non-transitory computer-readable medium of example 12, wherein the one or more pre- shared fields includes a receiver identifier.

[00150] Example 18 includes the at least one non-transitory computer-readable medium of any one of examples 12 through 17, wherein the one or more pre-shared fields are not included in the received wake-up message. [00151] Example 19 includes the at least one non-transitory computer-readable medium of example 12, wherein the pre-shared key and the one or more pre-shared fields are provided prior to entry into the low power mode.

[00152] Example 20 includes the at least one non-transitory computer-readable medium of example 12, wherein the instructions, when executed by the at least one processor, further cause the at least one processor to identify that the low power mode is to be entered, wherein the pre-shared key and the one or more pre-shared fields are provided to the at least one processor identifying that the low power mode is to be entered.

[00153] Example 21 includes the at least one non-transitory computer-readable medium of example 12, wherein the instructions, when executed by the at least one processor, further cause the at least one processor to truncate the pre-shared key.

[00154] Example 22 includes a method to wake a receiver, the method comprising storing a pre-shared key and one or more pre-shared fields, extracting an authentication field from a received wake-up message, the received wake-up message including a message integrity check field, generating, by executing an instruction with at least one processor, a reconstructed wake-up message based on the authentication field and at least one of the one or more pre-shared fields, generating, by executing an instruction with at least one processor, an authentication code using the reconstructed wake-up message and the pre-shared key, and in response to the authentication code matching the message integrity check field, causing a wireless communicator to exit a low power mode.

[00155] Example 23 includes the method of example 22, wherein the generating of the authentication code further includes splitting the re-constructed wake-up message into message blocks, applying a block cipher to the message blocks, and truncating a result of the block cipher to produce the authentication code. [00156] Example 24 includes the method of example 23, wherein the truncation of the result of the block cipher results in the authentication code having a same length as the message integrity check field.

[00157] Example 25 includes the method of example 22, wherein the one or more pre-shared fields includes a transmitter identifier.

[00158] Example 26 includes the method of example 22, wherein the one or more pre-shared fields includes a receiver identifier.

[00159] Example 27 includes the method of any one of examples 22 through 26, wherein the one or more pre-shared fields are not included in the received wake-up message.

[00160] Example 28 includes the method of example 22, wherein the pre-shared key and the one or more pre-shared fields are provided prior to entry into the low power mode.

[00161] Example 29 includes the method of example 22, further including identifying that the low power mode is to be entered, wherein the pre-shared key and the one or more pre-shared fields are provided to the at least one processor identifying that the low power mode is to be entered.

[00162] Example 30 includes the method of example 22, further including truncating the pre-shared key.

[00163] Example 31 includes an apparatus to wake a receiver, the apparatus comprising means for storing a pre-shared key and one or more pre-shared fields, means for processing to extract an authentication field from a received wake-up message, the received wake-up message including a message integrity check field, the means for processing to generate a reconstructed wake-up message based on the authentication field and at least one of the one or more pre-shared fields, and means for generating an authentication code using the re-constructed wake-up message and the pre- shared key, the means for processing to, in response to determining that the authentication code matches the message integrity check field, cause a wireless communicator of the receiver to exit a low power mode.

[00164] Example 32 includes the apparatus of example 31, wherein the wireless communicator is a primary communication radio. [00165] Example 33 includes the apparatus of example 31, wherein the one or more pre-shared fields includes an extended message content field.

[00166] Example 34 includes the apparatus of example 31, wherein the means for generating is to split the re-constructed wake-up message into message blocks, apply a block cipher to the message blocks, and truncate a result of the block cipher.

[00167] Example 35 includes the apparatus of example 34, wherein the truncation of the result of the block cipher creates the

authentication code having a same length as the message integrity check field.

[00168] Example 36 includes the apparatus of example 31, wherein the one or more pre-shared fields includes a transmitter identifier.

[00169] Example 37 includes the apparatus of example 31, wherein the one or more pre-shared fields includes a receiver identifier.

[00170] Example 38 includes the apparatus of any one of example 31 through 37, wherein the one or more pre-shared fields are not included in the received wake-up message.

[00171] Example 39 includes the apparatus of example 31, wherein the pre-shared key and the one or more pre-shared fields are provided to the apparatus prior to the apparatus entering the low power mode.

[00172] Example 40 includes the apparatus of example 31, wherein the means for processing is to identify that the apparatus is to enter the low power mode, and the pre-shared key and the one or more pre-shared fields are provided to the apparatus prior to the means for processing identifying that the apparatus is to enter the low power mode.

[00173] Example 41 includes the apparatus of example 31, wherein the means for generating is to truncate the pre-shared key.

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