WO2018164707A1

WO2018164707A1 - Internet-of-things (iot) station (sta), access point (ap) and methods for unassociated communication

Info

Publication number: WO2018164707A1
Application number: PCT/US2017/037730
Authority: WO
Inventors: Laurent Cariou; Bahareh Sadeghi; Daniel F. BRAVO; Robert J. Stacey
Original assignee: Intel IP Corporation
Priority date: 2017-03-07
Filing date: 2017-06-15
Publication date: 2018-09-13
Also published as: DE112017007196T5

Abstract

Embodiments of a station (STA), access point (AP) and method of communication in accordance with internet-of -things (IoT) techniques are generally described herein. The STA may determine, while in a power save mode, to transmit uplink data. The STA may iransiiion to an awake mode, and may broadcast an uplink physical layer convergence procedure protocol data, unit (PPDU) to APs of an extended service set (ESS) for relay to an ioT server. The STA may broadcast the uplink PPDU while imassociated with the APs. The STA may attempt to detect an acknowledgement · AC'k s for the uplink PPDU from at least one of the APs. If the ACK is detected, the STA may transition from the awake mode to the pow;er save mode.

Description

INTERNET-OF-THINGS (IOT) STATION (STA), ACCESS POINT (AP) AND METHODS FOR UNASSOCIATED COMMUNICATION

TECHNICAL FIELD [0001] Embodiments pertain to wireless communications. Some embodiments relate to wireless local area networks (WLANs) and Wi-Fi networks including networks operating in accordance with the IEEE 802.11 family of standards, including but not limited to IEEE 802.11ax. Some embodiments relate to internet-of-things (IoT) operation. Some embodiments relate to communication with a network, including communication while unassociated from the network.

BACKGROUND [0002] A device may communicate with a network to exchange voice, data, control messages and other types of signals. In some cases, the device may operate in accordance with reduced functionality, reduced power consumption and/or other criteria in comparison to other devices. For instance, an internet-of- things (IoT) device (and/or a device configured to operate in accordance with an IoT protocol) may communicate relatively small quantities of data at a relatively low frequency in comparison to a cellular phone. Some aspects of IoT operation, such as exchanging of control signaling with the network, may be challenging. Accordingly, there is a general need for devices and methods to address such challenges in these and other scenarios. BRIEF DESCRIPTION OF THE DRAWINGS [0003] FIG.1 illustrates a wireless network in accordance with some embodiments;

[0004] FIG.2 illustrates an example machine in accordance with some embodiments;

[0005] FIG.3 illustrates an internet-of-things (IoT) station (STA) in accordance with some embodiments and an access point (AP) in accordance with some embodiments;

[0006] FIG.4 is a block diagram of a radio architecture in accordance with some embodiments;

[0007] FIG.5 illustrates a front-end module circuitry for use in the radio architecture of FIG.4 in accordance with some embodiments;

[0008] FIG.6 illustrates a radio IC circuitry for use in the radio architecture of FIG.4 in accordance with some embodiments;

[0009] FIG.7 illustrates a baseband processing circuitry for use in the radio architecture of FIG.4 in accordance with some embodiments;

[0010] FIG.8 illustrates the operation of a method of communication in accordance with some embodiments;

[0011] FIG.9 illustrates example networks in accordance with some embodiments;

[0012] FIG.10 illustrates example operations and example messages in accordance with some embodiments;

[0013] FIG.11 illustrates example operations and example messages in accordance with some embodiments;

[0014] FIG.12 illustrates example generic advertisement service (GAS) frames in accordance with some embodiments; and

[0015] FIG.13 illustrates the operation of another method of communication in accordance with some embodiments. DETAILED DESCRIPTION [0016] The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.

[0017] FIG.1 illustrates a wireless network in accordance with some embodiments. In some embodiments, the network 100 may be a Wireless Local Area Network (WLAN) or a Wi-Fi network, although the scope of embodiments is not limited in this respect. It should be noted that embodiments are not limited to the number or type of components shown in the example network 100.

Embodiments are also not limited by the example network 100 in terms of the arrangement of the components or the connectivity between components as shown. In addition, some embodiments may include additional components.

[0018] The example network 100 may include one or more access points (APs) 102 and one or more internet-of-things (IoT) stations (STAs) 103. In some embodiments, the IoT STA 103 may be configured to operate in accordance with one or more Internet-of-Things (IoT) techniques and/or protocols, although the scope of embodiments is not limited in this respect. In some embodiments, the IoT STA 103 may be designed and/or implemented to operate in accordance with IoT techniques and/or protocols. Such an IoT STA 103 may operate exclusively as an IoT device, in some embodiments, although the scope of embodiments is not limited in this respect. It should be noted that references herein to an“IoT STA” are not limiting. Any suitable device, including devices which may not necessarily be configured to operate exclusively in accordance with IoT techniques and/or protocols, may perform one or more operations, techniques and/or methods described herein. For instance, an STA or other device may be configurable to operate in accordance with IoT techniques and/or protocols in addition to one or more other protocols (such as 802.11, 802.11ax, 802.11ay, 3GPP LTE and/or other). [0019] In some embodiments, the IoT STAs 103 may be arranged to operate in accordance with one or more IEEE 802.11 standards. These embodiments are not limiting, however, as other mobile devices, portable devices and/or other devices, which may or may not be arranged to operate in accordance with a standard, may be used in some embodiments. As an example, a User Equipment (UE) arranged to operate in accordance with one or more Third Generation Partnership Project (3GPP) standards, including but not limited to 3GPP LTE standards, may be used in some cases.

[0020] In some embodiments, the AP 102 may be arranged to operate in accordance with one or more IEEE 802.11 standards. These embodiments are not limiting, however, as other base station components, which may or may not be arranged to operate in accordance with a standard, may be used in some embodiments. As an example, an Evolved Node-B (eNB) arranged to operate in accordance with one or more Third Generation Partnership Project (3GPP) standards, including but not limited to 3GPP Long Term Evolution (LTE) standards, may be used in some cases.

[0021] In some embodiments, the IoT STAs 103 may be configured to communicate with the AP 102. In some embodiments, the IoT STAs 103 may be configurable to communicate with other IoT STAs 103. In some

embodiments, the IoT STAs 103 may be configurable to communicate with STAs, other mobile devices and/or other base stations. As shown in the example network 100 in FIG.1, IoT STA #1 may communicate with the AP 102 over the wireless link 105 and IoT STA #2 may communicate with the AP 102 over the wireless link 110. In some embodiments, direct communication between IoT STAs 103 may be possible, such as over the wireless link 115 between IoT STA #1 and IoT STA #2. These embodiments are not limiting, however, as the direction communication between IoT STAs 103 may not necessarily be possible in some embodiments.

[0022] In some embodiments, the communication between the AP 102 and the IoT STAs 103 may be performed in accordance with one or more IoT techniques and/or standards. In some embodiments, the communication between the AP 102 and the IoT STAs 103 and/or the communication between the IoT STAs 103 may be performed in accordance with one or more standards, such as an IoT standard, an 802.11 standard (including legacy 802.11 standards), a 3GPP standard (including 3GPP LTE standards) and/or other standards. These embodiments are not limiting, however, as other communication techniques and/or protocols, which may or may be included in a standard, may be used for the communication between the AP 102 and the IoT STAs 103 and/or the communication between the IoT STAs 103, in some embodiments.

[0023] Embodiments are not limited to communication as part of a network. In some embodiments, communication between two or more IoT STAs 103 may not necessarily involve a network. In some cases, at least a portion of the communication may include direct communication between the IoT STAs 103.

[0024] In some embodiments, some techniques, operations and/or methods may be described herein in terms of communication between an IoT STA 103 and an AP 102, but such descriptions are not limiting. Some or all of those techniques, operations and/or methods may be applicable to scenarios in which two or more IoT STAs 103 communicate.

[0025] In some embodiments, the IoT STAs 103, AP 102, other mobile devices, other base stations and/or other devices may be configured to perform operations related to contention based communication. As an example, the communication between the IoT STAs 103 and/or AP 102 and/or the communication between the IoT STAs 103 may be performed in accordance with contention based techniques. In such cases, the IoT STAs 103 and/or AP 102 may be arranged to contend for a wireless medium (e.g., during a contention period) to receive exclusive control of the medium for a transmission period. For instance, the transmission period may include a transmission opportunity (TXOP), which may be included in an 802.11 standard and/or other standard.

[0026] It should be noted that embodiments are not limited to usage of contention based techniques, however, as some communication (such as that between mobile devices and/or communication between a mobile device and a base station) may be performed in accordance with schedule based techniques. Some embodiments may include a combination of contention based techniques and schedule based techniques. [0027] In some embodiments, the communication between mobile devices and/or between a mobile device and a base station may be performed in accordance with single carrier techniques. As an example, a protocol data unit (PDU) and/or other frame(s) may be modulated on a single carrier frequency in accordance with a single carrier modulation (SCM) technique.

[0028] In some embodiments, the communication between mobile devices and/or between a mobile device and a base station may be performed in accordance with any suitable multiple-access techniques and/or multiplexing techniques. Accordingly, one or more of orthogonal frequency division multiple access (OFDMA), orthogonal frequency division multiplexing (OFDM), code- division multiple access (CDMA), time-division multiple access (TDMA), frequency division multiplexing (FDMA), space-division multiple access (SDMA), multiple-input multiple-output (MIMO), multi-user (MU) multiple- input multiple-output (MIMO) (MU-MIMO) and/or other techniques may be employed in some embodiments.

[0029] As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware. Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software.

[0030] FIG.2 illustrates a block diagram of an example machine in accordance with some embodiments. The machine 200 is an example machine upon which any one or more of the techniques and/or methodologies discussed herein may be performed. In alternative embodiments, the machine 200 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 200 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 200 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine 200 may be an AP 102, an STA (which may or may not support IoT techniques and/or protocols), an IoT STA 103, User Equipment (UE), Evolved Node-B (eNB), mobile device, base station, personal computer (PC), a tablet PC, a set- top box (STB), a personal digital assistant (PDA), a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term“machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.

[0031] Examples as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

[0032] Accordingly, the term“module” is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

[0033] The machine (e.g., computer system) 200 may include a hardware processor 202 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 204 and a static memory 206, some or all of which may communicate with each other via an interlink (e.g., bus) 208. The machine 200 may further include a display device 210, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In an example, the display device 210, input device 212 and UI navigation device 214 may be a touch screen display. The machine 200 may additionally include mass storage 216 (such as a storage device, drive unit and/or other), a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors 221, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine 200 may include an output controller 228, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

[0034] The mass storage 216 may include a machine readable medium 222 on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 224 may also reside, completely or at least partially, within the main memory 204, within static memory 206, or within the hardware processor 202 during execution thereof by the machine 200. In an example, one or any combination of the hardware processor 202, the main memory 204, the static memory 206, or the mass storage 216 may constitute machine readable media. In some embodiments, the machine readable medium may be or may include a non-transitory computer-readable storage medium. [0035] While the machine readable medium 222 is illustrated as a single medium, the term "machine readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224. The term“machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine 200 and that cause the machine 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable

Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, machine readable media may include non-transitory machine readable media. In some examples, machine readable media may include machine readable media that is not a transitory propagating signal.

[0036] The instructions 224 may further be transmitted or received over a communications network 226 using a transmission medium via the network interface device 220 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 226. In an example, the network interface device 220 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. In some examples, the network interface device 220 may wirelessly communicate using Multiple User MIMO techniques. The term“transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 200, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

[0037] FIG.3 illustrates an internet-of-things (IoT) station (STA) in accordance with some embodiments and an access point (AP) in accordance with some embodiments. It should be noted that in some embodiments, an IoT STA or other mobile device may include one or more components shown in any of FIG.2, FIG.3 (as in 300) or FIGs.4-7. In some embodiments, the IoT STA 300 may be suitable for use as an IoT STA 103 as depicted in FIG.1, although the scope of embodiments is not limited in this respect. It should also be noted that in some embodiments, an AP or other base station may include one or more components shown in any of FIG.2, FIG.3 (as in 350) or FIGs.4-7. In some embodiments, the AP 350 may be suitable for use as an AP 102 as depicted in FIG.1, although the scope of embodiments is not limited in this respect.

[0038] The IoT STA 300 may include physical layer circuitry 302 and a transceiver 305, one or both of which may enable transmission and reception of signals to and from components such as the AP 102 (FIG.1), other IoT STAs or other devices using one or more antennas 301. As an example, the physical layer circuitry 302 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals. As another example, the transceiver 305 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range. Accordingly, the physical layer circuitry 302 and the transceiver 305 may be separate components or may be part of a combined component. In addition, some of the described functionality related to transmission and reception of signals may be performed by a combination that may include one, any or all of the physical layer circuitry 302, the transceiver 305, and other components or layers. The IoT STA 300 may also include medium access control (MAC) layer circuitry 304 for controlling access to the wireless medium. The IoT STA 300 may also include processing circuitry 306 and memory 308 arranged to perform the operations described herein.

[0039] The AP 350 may include physical layer circuitry 352 and a transceiver 355, one or both of which may enable transmission and reception of signals to and from components such as the IoT STA 103 (FIG.1), other APs or other devices using one or more antennas 351. As an example, the physical layer circuitry 352 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals. As another example, the transceiver 355 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range. Accordingly, the physical layer circuitry 352 and the transceiver 355 may be separate components or may be part of a combined component. In addition, some of the described functionality related to transmission and reception of signals may be performed by a combination that may include one, any or all of the physical layer circuitry 352, the transceiver 355, and other components or layers. The AP 350 may also include medium access control (MAC) layer circuitry 354 for controlling access to the wireless medium. The AP 350 may also include processing circuitry 356 and memory 358 arranged to perform the operations described herein.

[0040] The antennas 301, 351, 230 may 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 301, 351, 230 may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.

[0041] In some embodiments, the IoT STA 300 may be configured to communicate using OFDM and/or OFDMA communication signals over a multicarrier communication channel. In some embodiments, the AP 350 may be configured to communicate using OFDM and/or OFDMA communication signals over a multicarrier communication channel. Accordingly, in some cases, the IoT STA 300 and/or AP 350 may be configured to receive signals in accordance with specific communication standards, such as the Institute of Electrical and Electronics Engineers (IEEE) standards including IEEE 802.11- 2012, 802.11n-2009, 802.11ac-2013 standards, 802.11ax standards (and/or proposed standards), 802.11ay standards (and/or proposed standards) and/or other, although the scope of the embodiments is not limited in this respect as they may also be suitable to transmit and/or receive communications in accordance with other techniques and standards. In some other embodiments, the AP 350 and/or the IoT STA 300 may be configured to receive signals that were 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.

[0042] In some embodiments, the IoT STA 300 and/or AP 350 may be a mobile device and may be a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a wearable device such as a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive and/or transmit information wirelessly. In some embodiments, the IoT STA 300 and/or AP 350 may be configured to operate in accordance with 802.11 standards, although the scope of the embodiments is not limited in this respect. Mobile devices or other devices in some embodiments may be configured to operate according to other protocols or standards, including other IEEE standards, Third Generation Partnership Project (3GPP) standards or other standards. In some embodiments, the IoT STA 300 and/or AP 350 may include one or more of a keyboard, a display, a non-volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other mobile device elements. The display may be an LCD screen including a touch screen.

[0043] Although the IoT STA 300 and the AP 350 are each 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.

[0044] Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include read- only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media. Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device.

[0045] It should be noted that in some embodiments, an apparatus of the IoT STA 300 may include various components of the IoT STA 300 as shown in FIG.3 and/or the example machine 200 as shown in FIG.2 and/or various components shown in FIGs.4-7. Accordingly, techniques and operations described herein that refer to the IoT STA 300 (or 103) may be applicable to an apparatus of an IoT STA, in some embodiments. It should also be noted that in some embodiments, an apparatus of the AP 350 may include various components of the AP 350 as shown in FIG.3 and/or the example machine 200 as shown in FIG.2 and/or various components shown in FIGs.4-7.

Accordingly, techniques and operations described herein that refer to the AP 350 (or 102) may be applicable to an apparatus of an AP, in some embodiments. In addition, an apparatus of a mobile device and/or base station may include one or more components shown in FIGs.2-7, in some embodiments. Accordingly, techniques and operations described herein that refer to a mobile device and/or base station may be applicable to an apparatus of a mobile device and/or base station, in some embodiments.

[0046] FIG.4 is a block diagram of a radio architecture 400 in accordance with some embodiments. Radio architecture 400 may include radio front-end module (FEM) circuitry 404, radio IC circuitry 406 and baseband processing circuitry 408. Radio architecture 400 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.

[0047] It should be noted that the radio architecture 400 and components shown in FIGs.5-7 support WLAN and BT, but embodiments are not limited to WLAN or BT. In some embodiments, two technologies supported by the radio architecture 400 may or may not include WLAN or BT. Other technologies may be supported. In some embodiments, WLAN and a second technology may be supported. In some embodiments, BT and a second technology may be supported. In some embodiments, two technologies other than WLAN and BT may be supported. In addition, the radio architecture 400 may be extended to support more than two protocols, technologies and/or standards, in some embodiments. Embodiments are also not limited to the frequencies illustrated in FIGs.4-7.

[0048] FEM circuitry 404 may include a WLAN or Wi-Fi FEM circuitry 404A and a Bluetooth (BT) FEM circuitry 404B. The WLAN FEM circuitry 404A may include a receive signal path comprising circuitry configured to operate on WLAN RF signals received from one or more antennas 401, to amplify the received signals and to provide the amplified versions of the received signals to the WLAN radio IC circuitry 406A for further processing. The BT FEM circuitry 404B may include a receive signal path which may include circuitry configured to operate on BT RF signals received from one or more antennas 401, to amplify the received signals and to provide the amplified versions of the received signals to the BT radio IC circuitry 406B for further processing. FEM circuitry 404A may also include a transmit signal path which may include circuitry configured to amplify WLAN signals provided by the radio IC circuitry 406A for wireless transmission by one or more of the antennas 401. In addition, FEM circuitry 404B may also include a transmit signal path which may include circuitry configured to amplify BT signals provided by the radio IC circuitry 406b for wireless transmission by the one or more antennas. In the embodiment of FIG.4, although FEM 404A and FEM 404B 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.

[0049] Radio IC circuitry 406 as shown may include WLAN radio IC circuitry 406A and BT radio IC circuitry 406B. The WLAN radio IC circuitry 406A may include a receive signal path which may include circuitry to down- convert WLAN RF signals received from the FEM circuitry 404A and provide baseband signals to WLAN baseband processing circuitry 408a. BT radio IC circuitry 406B may in turn include a receive signal path which may include circuitry to down-convert BT RF signals received from the FEM circuitry 404B and provide baseband signals to BT baseband processing circuitry 408B.

WLAN radio IC circuitry 406A may also include a transmit signal path which may include circuitry to up-convert WLAN baseband signals provided by the WLAN baseband processing circuitry 408A and provide WLAN RF output signals to the FEM circuitry 404A for subsequent wireless transmission by the one or more antennas 401. BT radio IC circuitry 406B may also include a transmit signal path which may include circuitry to up-convert BT baseband signals provided by the BT baseband processing circuitry 408B and provide BT RF output signals to the FEM circuitry 404B for subsequent wireless transmission by the one or more antennas 401. In the embodiment of FIG.4, although radio IC circuitries 406A and 406B 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.

[0050] Baseband processing circuity 408 may include a WLAN baseband processing circuitry 408A and a BT baseband processing circuitry 408B. The WLAN baseband processing circuitry 408A 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 408A. Each of the WLAN baseband circuitry 408A and the BT baseband circuitry 408B 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 406, and to also generate corresponding WLAN or BT baseband signals for the transmit signal path of the radio IC circuitry 406. Each of the baseband processing circuitries 408A and 408B may further include physical layer (PHY) and medium access control layer (MAC) circuitry, and may further interface with application processor 411 for generation and processing of the baseband signals and for controlling operations of the radio IC circuitry 406.

[0051] Referring still to FIG.4, according to the shown embodiment, WLAN-BT coexistence circuitry 413 may include logic providing an interface between the WLAN baseband circuitry 408A and the BT baseband circuitry 408B to enable use cases requiring WLAN and BT coexistence. In addition, a switch 403 may be provided between the WLAN FEM circuitry 404A and the BT FEM circuitry 404B to allow switching between the WLAN and BT radios according to application needs. In addition, although the antennas 401 are depicted as being respectively connected to the WLAN FEM circuitry 404A and the BT FEM circuitry 404B, 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 404A or 404B.

[0052] In some embodiments, the front-end module circuitry 404, the radio IC circuitry 406, and baseband processing circuitry 408 may be provided on a single radio card, such as wireless radio card 402. In some other embodiments, the one or more antennas 401, the FEM circuitry 404 and the radio IC circuitry 406 may be provided on a single radio card. In some other embodiments, the radio IC circuitry 406 and the baseband processing circuitry 408 may be provided on a single chip or integrated circuit (IC), such as IC 412.

[0053] In some embodiments, the wireless radio card 402 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 400 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.

[0054] In some of these multicarrier embodiments, radio architecture 400 may be part of an IoT STA, 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 400 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.11n-2009, IEEE 802.11- 2012, 802.11n-2009, 802.11ac, and/or 802.11ax standards and/or proposed specifications for WLANs, although the scope of embodiments is not limited in this respect. Radio architecture 400 may also be suitable to transmit and/or receive communications in accordance with other techniques and standards.

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

[0056] In some other embodiments, the radio architecture 400 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.

[0057] In some embodiments, as further shown in FIG.4, the BT baseband circuitry 408B may be compliant with a Bluetooth (BT) connectivity standard such as Bluetooth, Bluetooth 4.0 or Bluetooth 5.0, or any other iteration of the Bluetooth Standard. In embodiments that include BT functionality as shown for example in Fig.4, the radio architecture 400 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 400 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.4, 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 402, although embodiments are not so limited, and include within their scope discrete WLAN and BT radio cards.

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

[0059] In some IEEE 802.11 embodiments, the radio architecture 400 may be configured for communication over various channel bandwidths including bandwidths having center frequencies of about 900 MHz, 2.4 GHz, 5 GHz. In some embodiments, the bandwidths may be about 1 MHz, 2 MHz, 2.5 MHz, 4 MHz, 5MHz, 8 MHz, 10 MHz, 16 MHz, 20 MHz, 40MHz, 80MHz (with contiguous bandwidths) or 80+80MHz (160MHz) (with non-contiguous bandwidths). In some embodiments, a 320 MHz channel bandwidth may be used. In some embodiments, the bandwidths may be about 2.16 GHz, 4.32 GHz, 6.48 GHz, 8.72 GHz and/or other suitable value. The scope of the embodiments is not limited with respect to the above center frequencies or bandwidths, however.

[0060] FIG.5 illustrates FEM circuitry 500 in accordance with some embodiments. The FEM circuitry 500 is one example of circuitry that may be suitable for use as the WLAN and/or BT FEM circuitry 404A/404B (FIG.4), although other circuitry configurations may also be suitable.

[0061] In some embodiments, the FEM circuitry 500 may include a TX/RX switch 502 to switch between transmit mode and receive mode operation. The FEM circuitry 500 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 500 may include a low-noise amplifier (LNA) 506 to amplify received RF signals 503 and provide the amplified received RF signals 507 as an output (e.g., to the radio IC circuitry 406 (FIG.4)). The transmit signal path of the circuitry 500 may include a power amplifier (PA) 510 to amplify input RF signals 509 (e.g., provided by the radio IC circuitry 406), and one or more filters 512, such as band-pass filters (BPFs), low-pass filters (LPFs) or other types of filters, to generate RF signals 515 for subsequent transmission (e.g., by one or more of the antennas 401 (FIG. 4)).

[0062] In some dual-mode embodiments for Wi-Fi communication, the FEM circuitry 500 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 500 may include a receive signal path duplexer 504 to separate the signals from each spectrum as well as provide a separate LNA 506 for each spectrum as shown. In these embodiments, the transmit signal path of the FEM circuitry 500 may also include a power amplifier 510 and a filter 512, such as a BPF, a LPF or another type of filter for each frequency spectrum and a transmit signal path duplexer 514 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 401 (FIG.4). In some embodiments, BT communications may utilize the 2.4 GHZ signal paths and may utilize the same FEM circuitry 500 as the one used for WLAN communications.

[0063] FIG.6 illustrates radio IC circuitry 600 in accordance with some embodiments. The radio IC circuitry 600 is one example of circuitry that may be suitable for use as the WLAN or BT radio IC circuitry 406A/406B (FIG.4), although other circuitry configurations may also be suitable.

[0064] In some embodiments, the radio IC circuitry 600 may include a receive signal path and a transmit signal path. The receive signal path of the radio IC circuitry 600 may include at least mixer circuitry 602, such as, for example, down-conversion mixer circuitry, amplifier circuitry 606 and filter circuitry 608. The transmit signal path of the radio IC circuitry 600 may include at least filter circuitry 612 and mixer circuitry 614, such as, for example, up- conversion mixer circuitry. Radio IC circuitry 600 may also include synthesizer circuitry 604 for synthesizing a frequency 605 for use by the mixer circuitry 602 and the mixer circuitry 614. The mixer circuitry 602 and/or 614 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.6 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 602 and/or 614 may each include one or more mixers, and filter circuitries 608 and/or 612 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.

[0065] In some embodiments, mixer circuitry 602 may be configured to down-convert RF signals 507 received from the FEM circuitry 404 (FIG.4) based on the synthesized frequency 605 provided by synthesizer circuitry 604. The amplifier circuitry 606 may be configured to amplify the down-converted signals and the filter circuitry 608 may include a LPF configured to remove unwanted signals from the down-converted signals to generate output baseband signals 607. Output baseband signals 607 may be provided to the baseband processing circuitry 408 (FIG.4) for further processing. In some embodiments, the output baseband signals 607 may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 602 may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0066] In some embodiments, the mixer circuitry 614 may be configured to up-convert input baseband signals 611 based on the synthesized frequency 605 provided by the synthesizer circuitry 604 to generate RF output signals 509 for the FEM circuitry 404. The baseband signals 611 may be provided by the baseband processing circuitry 408 and may be filtered by filter circuitry 612. The filter circuitry 612 may include a LPF or a BPF, although the scope of the embodiments is not limited in this respect.

[0067] In some embodiments, the mixer circuitry 602 and the mixer circuitry 614 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 604. In some embodiments, the mixer circuitry 602 and the mixer circuitry 614 may each include two or more mixers each configured for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 602 and the mixer circuitry 614 may be arranged for direct down- conversion and/or direct up-conversion, respectively. In some embodiments, the mixer circuitry 602 and the mixer circuitry 614 may be configured for super- heterodyne operation, although this is not a requirement.

[0068] Mixer circuitry 602 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 507 from Fig.6 may be down- converted to provide I and Q baseband output signals to be sent to the baseband processor.

[0069] 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 605 of synthesizer 604 (FIG.6). 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.

[0070] 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 25% 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 25% duty cycle, which may result in a significant reduction is power consumption.

[0071] The RF input signal 507 (FIG.5) 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 606 (FIG.6) or to filter circuitry 608 (FIG.6).

[0072] In some embodiments, the output baseband signals 607 and the input baseband signals 611 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 607 and the input baseband signals 611 may be digital baseband signals. In these alternate embodiments, the radio IC circuitry may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry.

[0073] 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.

[0074] In some embodiments, the synthesizer circuitry 604 may be a fractional-N synthesizer or a fractional N/N+1 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 604 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 604 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 604 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 408 (FIG.4) or the application processor 411 (FIG.4) depending on the desired output frequency 605. 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 411.

[0075] In some embodiments, synthesizer circuitry 604 may be configured to generate a carrier frequency as the output frequency 605, while in other embodiments, the output frequency 605 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 605 may be a LO frequency (fLO).

[0076] FIG.7 illustrates a functional block diagram of baseband processing circuitry 700 in accordance with some embodiments. The baseband processing circuitry 700 is one example of circuitry that may be suitable for use as the baseband processing circuitry 408 (FIG.4), although other circuitry configurations may also be suitable. The baseband processing circuitry 700 may include a receive baseband processor (RX BBP) 702 for processing receive baseband signals 609 provided by the radio IC circuitry 406 (FIG.4) and a transmit baseband processor (TX BBP) 704 for generating transmit baseband signals 611 for the radio IC circuitry 406. The baseband processing circuitry 700 may also include control logic 706 for coordinating the operations of the baseband processing circuitry 700.

[0077] In some embodiments (e.g., when analog baseband signals are exchanged between the baseband processing circuitry 700 and the radio IC circuitry 406), the baseband processing circuitry 700 may include ADC 710 to convert analog baseband signals received from the radio IC circuitry 406 to digital baseband signals for processing by the RX BBP 702. In these

embodiments, the baseband processing circuitry 700 may also include DAC 712 to convert digital baseband signals from the TX BBP 704 to analog baseband signals. [0078] In some embodiments that communicate OFDM signals or OFDMA signals, such as through baseband processor 408A, the transmit baseband processor 704 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 702 may be configured to process received OFDM signals or OFDMA signals by performing an FFT. In some embodiments, the receive baseband processor 702 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.

[0079] Referring back to FIG.4, in some embodiments, the antennas 401 (FIG.4) 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 401 may each include a set of phased-array antennas, although embodiments are not so limited.

[0080] Although the radio-architecture 400 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.

[0081] Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include read- only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media. Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device.

[0082] In accordance with some embodiments, an IoT STA 103 may determine, while the IoT STA 103 is in a power save mode, that the IoT STA 103 is to transmit uplink data to an IoT server. The IoT STA 103 may transition the IoT STA 103 from the power save mode to an awake mode based on the determination that the IoT STA 103 is to transmit the uplink data. The IoT STA 103 may contend for access to channel resources and may encode the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission in the channel resources to access points (APs) 102 of an extended service set (ESS) for relay to the IoT server. The uplink PPDU may be transmitted while the IoT STA 103 is unassociated with the APs 102. The IoT STA 103 may attempt to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs 102. If the ACK is detected, the IoT STA 103 may transition from the awake mode to the power save mode. These embodiments are described in more detail below.

[0083] FIG.8 illustrates the operation of a method of communication in accordance with some embodiments. It is important to note that embodiments of the method 800 may include additional or even fewer operations or processes in comparison to what is illustrated in FIG.8. Some embodiments of the method 800 may not necessarily include all operations shown in FIG.8. In addition, embodiments of the method 800 are not necessarily limited to the chronological order that is shown in FIG.8. In describing the method 800, reference may be made to FIGs.1-7 and 9-13, although it is understood that the method 800 may be practiced with any other suitable systems, interfaces and components. [0084] In addition, the method 800 and other methods described herein may be applicable to IoT STAs 103, STAs or APs 102 operating in accordance with an 802.11 standard, protocol and/or specification and/or WLAN standard, protocol and/or specification, in some cases. In some embodiments, one or more of the operations of the method 800 may be practiced by an IoT STA 103, an STA and/or other mobile device, although the scope of embodiments is not limited in this respect. Embodiments are not limited to IoT STAs 103, STAs or APs 102, however, and may be applicable to other devices, such as a User Equipment (UE), an Evolved Node-B (eNB) and/or other device. In addition, the method 800 and other methods described herein may be practiced by wireless devices configured to operate in other suitable types of wireless communication systems, including systems configured to operate according to various Third Generation Partnership Protocol (3GPP) standards, including but not limited to Long Term Evolution (LTE). The method 800 may also be practiced by an apparatus of an IoT STA 103, an apparatus of an STA, an apparatus of a mobile device and/or an apparatus of another device, in some embodiments.

[0085] It should also be noted that embodiments are not limited by references herein (such as in descriptions of the methods 800, 1300 and/or other descriptions herein) to transmission, reception and/or exchanging of elements such as frames, messages, requests, indicators, signals or other elements. In some embodiments, such an element may be generated, encoded or otherwise processed by processing circuitry (such as by a baseband processor included in the processing circuitry) for transmission. The transmission may be performed by a transceiver or other component, in some cases. In some embodiments, such an element may be decoded, detected or otherwise processed by the processing circuitry (such as by the baseband processor). The element may be received by a transceiver or other component, in some cases. In some embodiments, the processing circuitry and the transceiver may be included in a same apparatus. The scope of embodiments is not limited in this respect, however, as the transceiver may be separate from the apparatus that comprises the processing circuitry, in some embodiments. [0086] It should be noted that references herein to an“IoT STA” are not limiting. In some embodiments, an STA or other mobile device may perform one or more operations of an IoT STA 103 described herein. In some embodiments, an STA (and/or other mobile device) may perform one or more operations described herein without explicit operation as an IoT STA 103. In some embodiments, the method 800 may be performed by an IoT STA 103 and/or an STA configured to operate in accordance with one or more IoT techniques and/or protocols. The scope of embodiments is not limited in this respect, however, as any suitable device (including an STA not necessarily configured to operate in accordance with IoT techniques and/or protocols) may perform the method 800, in some embodiments.

[0087] At operation 805, the IoT STA 103 may operate in a power save mode. Embodiments are not limited by references herein to the“power save mode.” Same or similar modes of operation, including but not limited to a power savings mode, a sleep mode, an idle mode and/or other mode may be used in some embodiments. One or more techniques, methods and/or operations described herein may refer to the power save mode (such as operation in the power save mode, transition to or from the power save mode and/or other operation,) but it is understood that some or all of those techniques, methods and/or operations may be applicable to other modes of operation that may be the same or similar to the power save mode.

[0088] In some embodiments, operation of the IoT STA 103 in the power save mode may include restriction of transmission and reception of signals by the IoT STA 103. In a non-limiting example, the IoT STA 103 may refrain from transmission of signals, reception of signals and/or other processing operations while in the power save mode. In another non-limiting example, the IoT STA 103 may restrict transmission of signals, reception of signals and/or other processing operations while in the power save mode. In another non-limiting example, a reduced amount of (and/or frequency of) transmission of signals, reception of signals and/or other processing operations may be performed during operation in the power save mode in comparison to operation in an awake mode, active mode, normal mode and/or other mode. [0089] At operation 810, the IoT STA 103 may determine whether the IoT STA 103 is to transmit uplink data. In some embodiments, the IoT STA 103 may determine that the IoT STA 103 is to transmit the uplink data while the IoT STA 103 operates in the power save mode, although the scope of embodiments is not limited in this respect. In some embodiments, the IoT STA 103 may determine that the IoT STA 103 is to transmit the uplink data to an IoT server of an extended service set (ESS), although the scope of embodiments is not limited in this respect. In some embodiments, the IoT server may not necessarily be part of the ESS, although the scope of embodiments is not limited in this respect. In some embodiments, the IoT server may be separate from the ESS, independent from the ESS and/or exclusive to the ESS. In some embodiments, the IoT server may be part of the ESS. In some embodiments, the IoT server may be at least partly controlled and/or managed by the ESS. In some embodiments, the ESS and/or APs 102 and/or other component(s) of the ESS may be coupled to the IoT server.

[0090] In a non-limiting example, the IoT STA 103 may determine whether the uplink data is available for transmission. For instance, the IoT STA 103 may periodically check whether the uplink data is available, such as in accordance with a schedule, periodicity, predetermined time and/or other. In another non-limiting example, the IoT STA 103 may use a schedule to determine whether the uplink data is available. In another non-limiting example, the uplink data may become available to the IoT STA 103 from a sensor or other component, and the sensor or other component may signal the IoT STA 103 that the uplink data is available.

[0091] At operation 815, the IoT STA 103 may remain in the power save mode. For instance, if it is determined that the IoT STA 103 is not to transmit uplink data (and/or that the uplink data is not available for transmission), the IoT STA 103 may remain in the power save mode. In some embodiments, the processing circuitry may maintain the IoT STA 103 in the power save mode.

[0092] At operation 820, the IoT STA 103 may transition from the power save mode to an awake mode. For instance, if it is determined that the IoT STA 103 is to transmit uplink data (and/or that the uplink data is available for transmission), the IoT STA 103 may transition to the awake mode. In some embodiments, the IoT STA 103 may transition from the power save mode to the awake mode based on a determination that the IoT STA 103 is to transmit the uplink data. In some embodiments, the IoT STA 103 may transition from the power save mode to the awake mode for transmission of the uplink data. In some embodiments, the processing circuitry may transition the IoT STA 103 from the power save mode to the awake mode.

[0093] At operation 825, the IoT STA 103 may refrain from association with access points (APs) 102 of the ESS. In some embodiments, the IoT STA 103 may refrain from association with the APs 102 for one or more operations of the method 800, including but not limited to operations 830-850. Accordingly, the IoT STA 103 may perform one or more of operations 830-850 while unassociated with the APs 102. In some embodiments, the IoT STA 103 may be unassociated with the APs 102 and may remain unassociated with the APs 102 while the IoT STA 103 performs one or more operations of the method 800. In some embodiments, the IoT STA 103 may perform the method 800 (and/or portions of it) while unassociated with the APs 102, although the scope of embodiments is not limited in this respect.

[0094] In some embodiments, the IoT STA 103 may perform one or more of operations 830-850 (and/or other operations) during an awake period in which the IoT STA 103 is in the awake mode. The IoT STA 103 may refrain from association with the APs 102 during the awake period.

[0095] At operation 830, the IoT STA 103 may contend for access to channel resources. In a non-limiting example, the IoT STA 103 may contend for access to the channel resources multiple times. For instance, a first contention may be performed before a first transmission and a second contention may be performed before a second transmission. Embodiments are not limited to contention based transmissions, however.

[0096] At operation 835, the IoT STA 103 may transmit the uplink data. In some embodiments, the uplink data may be included in an uplink physical layer convergence procedure protocol data unit (PPDU). In a non-limiting example, the uplink data and/or uplink PPDU may be included in a generic advertisement service (GAS) frame that includes: an address of the IoT STA 103, and an address of the IoT server and/or other information. Embodiments are not limited to the uplink PPDU, however, as multiple uplink PPDUs may be used, in some embodiments. In addition, embodiments are not limited to usage of uplink PPDUs, as any suitable blocks, frames, PDUs and/or other elements may include the uplink data, in some embodiments.

[0097] In some embodiments, the IoT STA 103 may transmit the uplink PPDU in a broadcast mode. In some embodiments, the transmission of the uplink PPDU may be a broadcast transmission. In some embodiments, the uplink PPDU may be a broadcast PPDU. In some embodiments, the IoT STA 103 may transmit the uplink data and/or uplink PPDU to the APs 102 for relay to the IoT server. In some embodiments, the IoT STA 103 may transmit the uplink data and/or uplink PPDU to the APs 102 to be forwarded, by at least one of the APs 102, to the IoT server. In some embodiments, the IoT STA 103 may transmit the uplink PPDU and/or uplink data while the IoT STA 103 is unassociated with the APs 102.

[0098] In some embodiments, the broadcast transmission may be performed as part of a preconfigured service in which the APs 102 of the ESS are to operate as relays for communication between the IoT server and one or more IoT STAs 103. It should be noted that the particular IoT STA(s) 103 for which the APs 102 are to operate as relays for the service may not necessarily be known, in some embodiments. For instance, the APs 102 may be configured to operate as relays for any IoT STA 103 that intends to communicate with the IoT server as part of the service. Embodiments are not limited as such, however, as one or more of the IoT STAs 103 may be known (such as through registration, configuration and/or other), in some embodiments.

[0099] In some embodiments, the uplink PPDU may include one or more of: uplink data, an identifier of the ESS, an identifier of the IoT server, an indicator that the uplink PPDU is encoded for the service, an indicator that the uplink PPDU is a broadcast PPDU, other indicator(s), other parameter(s) and/or other information.

[00100] In some embodiments, the uplink PPDU may be a generic advertisement service (GAS) frame that includes one or more of: an address of the IoT STA, an address of the ESS or a broadcast address, an advertisement protocol identifier field that indicates that the uplink PPDU is encoded for the service, other indicator(s), other parameter(s) and/or other information.

[00101] At operation 840, the IoT STA 103 may attempt to detect an acknowledgement (ACK) for the uplink PPDU. At operation 845, the IoT STA 103 may determine whether the IoT STA is to receive downlink data. In some embodiments, the determination of whether the IoT STA 103 is to receive the downlink data may be based at least partly on information included in the ACK, although the scope of embodiments is not limited in this respect. At operation 850, the IoT STA 103 may receive one or more downlink PPDUs (and/or other downlink data). At operation 855, the IoT STA 103 may transition from the awake mode to the power save mode. In some embodiments, the processing circuitry may transition the IoT STA 103 from the awake mode to the power save mode.

[00102] In some embodiments, the IoT STA 103 may attempt to detect the ACK for the uplink PPDU in the channel resources from at least one of the APs 102. In some embodiments, the ACK may be (and/or may be configurable to be) a simulcast ACK from multiple APs 102 during a predetermined time window subsequent to the transmission of the uplink PPDU. The IoT STA 103 may attempt to detect the ACK during the predetermined time window. For instance, the one or more APs 102 that receive the uplink PPDU may each transmit an ACK of a same format or similar format during the predetermined time window. A resulting signal at the IoT STA 103 may be a simulcast ACK, in some cases.

[00103] In some embodiments, if the ACK is detected, the IoT STA 103 may transition from the awake mode to the power save mode. In some embodiments, if the ACK is detected, the processing circuitry may transition the IoT STA 103 from the awake mode to the power save mode.

[00104] In some embodiments, if the ACK is detected, the IoT STA 103 may decode the ACK. The IoT STA 103 may determine, based at least partly on the decoded ACK, whether the IoT STA 103 is to receive a downlink PPDU (and/or other downlink data). If it is determined that the IoT STA 103 is to receive a downlink PPDU, the IoT STA 103 may attempt to detect the downlink PPDU from one or more of the APs 102 in the channel resources. The IoT STA 103 may monitor the channel resources for the downlink PPDU during a predetermined time window subsequent to the detection of the ACK.

[00105] In some embodiments, if the downlink PPDU is detected, the IoT STA 103 may transition from the awake mode to the power save mode. In some embodiments, if the downlink PPDU is detected, the processing circuitry may transition the IoT STA 103 from the awake mode to the power save mode.

[00106] In some embodiments, if the ACK is detected and if it is determined that the IoT STA 103 is not to receive the downlink PPDU (and/or downlink data), the IoT STA 103 may transition from the awake mode to the power save mode. In some embodiments, if the ACK is detected and if it is determined that the IoT STA 103 is not to receive the downlink PPDU (and/or downlink data), the processing circuitry may transition the IoT STA 103 from the awake mode to the power save mode

[00107] In some embodiments, if the ACK is not detected, the IoT STA 103 may retransmit the uplink PPDU (and/or transmit another uplink PPDU that includes the uplink data) and may attempt to receive an ACK in response to the retransmission. For instance, the IoT STA 103 may determine a backoff count for a retransmission of the uplink PPDU, and may attempt to detect a second ACK for the uplink PPDU in the channel resources from one or more of the APs 102.

[00108] Embodiments are not limited to the above operation(s) in cases in which the ACK is not detected. In some embodiments, if the ACK is not detected, the IoT STA 103 may transition from the awake mode to the sleep mode. In some embodiments, if the ACK is not detected, the processing circuitry may transition the IoT STA 103 from the awake mode to the power save mode. Other operation(s) and/or additional operation(s) may be performed, in some embodiments.

[00109] It should be noted that embodiments are not limited to usage of simulcast ACKs from multiple APs 102. For instance, the IoT STA 103 may receive an ACK that is unicast from a single AP 102, in some cases. It should be noted that the ACK may be transmitted by a single AP 102 even if the uplink PPDU is received by multiple APs 102, in some embodiments. [00110] It should be noted that all operations shown in FIG.8 may not necessarily be performed. For instance, at operation 845, if it is determined that the IoT STA 103 is not to receive the downlink data, operation 850 (reception of one or more downlink PPDUs) may not necessarily be performed.

[00111] In some embodiments, an apparatus of an STA 103 may comprise memory. The memory may be configurable to store the uplink PPDU. The memory may store one or more other elements and the apparatus may use them for performance of one or more operations. The apparatus may include processing circuitry, which may perform one or more operations (including but not limited to operation(s) of the method 800 and/or other methods described herein). The processing circuitry may include a baseband processor. The baseband circuitry and/or the processing circuitry may perform one or more operations described herein, including but not limited to determination of whether the IoT STA 103 is to transmit the uplink data and encoding of the uplink data in the uplink PPDU.

[00112] In some embodiments, the apparatus of the IoT STA 103 may include a transceiver to transmit the uplink PPDU and/or to attempt to detect the ACK. The transceiver may transmit and/or receive other frames, PPDUs, messages and/or other elements. In some embodiments, the transceiver may be configurable to be coupled to one or more antennas. Operation of the IoT STA 103 in the power save mode may include restriction of transmission and reception of signals by the transceiver, in some embodiments. The processing circuitry may be configured to, as part of the transition of the IoT STA 103 from the awake mode to the power save mode, instruct the transceiver to restrict the transmission and the reception of signals.

[00113] FIG.9 illustrates example networks in accordance with some embodiments. FIG.10 illustrates example operations and example messages in accordance with some embodiments. FIG.11 illustrates example operations and example messages in accordance with some embodiments. FIG.12 illustrates example generic advertisement service (GAS) frames in accordance with some embodiments. It should be noted that the examples shown in FIGs.9-12 may illustrate some or all of the concepts and techniques described herein in some cases, but embodiments are not limited by the examples. For instance, embodiments are not limited by the name, number, type, size, ordering, arrangement, values and/or other aspects of the components, devices, operations, messages, packets, frames, headers, data portions, fields, and other elements as shown in FIGs.9-12. Although some of the elements shown in the examples of FIGs.9-12 may be included in a standard, such as 802.11, 802.11ax, WLAN and/or other, embodiments are not limited to usage of such elements that are included in standards. Some embodiments may not necessarily include all components shown in any of FIGs.9-12. Some embodiments may include one or more additional components.

[00114] Referring to FIG.9, two example arrangements 900, 950 are shown. Although two APs are shown for each example arrangement 900, 950, these examples may be extended to arrangements in which more than two APs are included.

[00115] In the example arrangement 900, the IoT device 910 (which may be an STA 103, IoT STA 103 and/or other) may communicate over the wireless link 922 with AP 920 and may communicate over the wireless link 932 with the AP 930. The APs 920, 930 may be coupled to the IoT server 940 over the links 924 and 934, respectively. The links 924 and 934 may be wired links in some embodiments, although the scope of embodiments is not limited in this respect. In a non-limiting example, the IoT device 910 may transmit a broadcast frame that may be received by either or both of APs 920, 930. The broadcast frame may be transmitted while the IoT device 910 is unassociated from the APs 920, 930. If the AP 920 receives and/or decodes the broadcast frame, it may forward at least a portion of the broadcast frame (such as a data payload, request for downlink data and/or other) to the IoT server 940. In addition, if the AP 930 receives and/or decodes the broadcast frame, it may forward at least a portion of the broadcast frame (such as a data payload, request for downlink data and/or other) to the IoT server 940. One or both of APs 920, 930 may receive and/or decode the broadcast frame. If both of the APs 920, 930 receive and/or decode the broadcast frame, both of the APs 920, 930 may forward at least a portion of the broadcast frame to the IoT server 940, in some cases.

[00116] In the example arrangement 950, the IoT device 960 (which may be an STA 103, IoT STA 103 and/or other) may communicate over the wireless link 972 with AP 970 and may communicate over the wireless link 982 with the AP 980. The APs 970, 980 may be coupled to the local controller 990 over the links 974 and 984, respectively. The local controller 990 may be coupled to the IoT server 995 over the link 992. The links 974, 984, 992 may be wired links in some embodiments, although the scope of embodiments is not limited in this respect. In a non-limiting example, the IoT device 960 may transmit a broadcast frame that may be received by either or both of APs 970, 980. The broadcast frame may be transmitted while the IoT device 960 is unassociated from the APs 970, 980. If the AP 970 receives and/or decodes the broadcast frame, it may forward at least a portion of the broadcast frame (such as a data payload, request for downlink data and/or other) to the local controller 990. The local controller 990 may forward at least a portion of the broadcast frame (such as a data payload, request for downlink data and/or other) to the IoT server 995. In addition, if the AP 980 receives and/or decodes the broadcast frame, it may forward at least a portion of the broadcast frame (such as a data payload, request for downlink data and/or other) to the local controller 990. One or both of APs 970, 980 may receive and/or decode the broadcast frame. If both of the APs 970, 980 receive and/or decode the broadcast frame, both of the APs 970, 980 may forward at least a portion of the broadcast frame to the local controller 990, in some cases.

[00117] Referring to FIG.10, two example arrangements 1000 and 1050 are shown. Referring to FIG.11, an example arrangement 1100 is shown.

Embodiments are not limited to the number of APs and/or other components as shown in any of the arrangements 1000, 1050, 1100. It should be noted that one or more of the operations shown in FIGs.10 and 11 may be performed in accordance with an IoT Query Protocol (IoT QP), although the scope of embodiments is not limited in this respect. It should also be noted that one or more of the messages shown in FIGs.10 and 11 may be exchanged in accordance with an IoT Query Protocol (IoT QP), although the scope of embodiments is not limited in this respect.

[00118] In the example arrangement 1000, the IoT device 1010 may communicate with an AP 1012, which may communicate with an IoT server 1016. At operation 1020, the IoT device 1010 may broadcast a GAS initial frame that may carry one or more of a payload, user ID, IoT server address and/or other information. At operation 1021, the AP 1012 may send, to the IoT server 1016, a request to verify authentication (which may include user ID information, in some cases). At operation 1022, the AP 1012 may transmit, to the IoT device 1010, an ACK for the GAS initial frame. At operation 1023, the IoT server 1016 may send a response to the request to verify authentication from operation 1021. At operation 1024, the AP 1012 may transmit, to the IoT server 1010, a GAS response frame. The GAS response frame may be unicasted to the IoT device 1010, although the scope of embodiments is not limited in this respect. The GAS response frame may indicate a“come-back time” related to a later time at which downlink data may be transmitted to the IoT device 1010, although the scope of embodiments is not limited in this respect. At operation 1025, the AP 1012 may send a payload (such as an uplink payload from operation 1020 and/or other operation) with user ID to the IoT server 1016. At operation 1026, the IoT server 1016 may send an ACK (such as an

acknowledgement of good reception) of the payload sent by the AP 1012 at operation 1025. At operation 1027, the IoT device 1010 may transmit a unicast GAS initial frame that may include a request for an ACK from the IoT server 1016. At operation 1028, the AP 1012 may transmit a unicast GAS response frame to the IoT device 1010 that may include and/or indicate the ACK requested at operation 1027. The network address translation (NAT) component (indicated by 1014) may enable traffic to be sent from the IoT server 1016 to the AP 1012, in some embodiments. It should be noted that some embodiments may not necessarily include the NAT 1014.

[00119] In the example arrangement 1050, the IoT device 1060 may communicate with an AP 1062, which may communicate with an IoT server 1066. At operation 1070, the IoT device 1060 may broadcast a GAS initial frame that may carry one or more of a request for downlink data, user ID, IoT server address and/or other information. At operation 1071, the AP 1062 may send, to the IoT server 1066, a request to verify authentication (which may include user ID information, in some cases). At operation 1072, the AP 1062 may transmit, to the IoT device 1060, an ACK for the GAS initial frame. At operation 1073, the IoT server 1066 may send a response to the request to verify authentication from operation 1071. At operation 1074, the AP 1062 may transmit, to the IoT server 1060, a GAS response frame. The GAS response frame may be unicasted to the IoT device 1060, although the scope of embodiments is not limited in this respect. The GAS response frame may indicate a“come-back time” related to a later time at which downlink data may be transmitted to the IoT device 1060, although the scope of embodiments is not limited in this respect. At operation 1075, the AP 1062 may send a request to receive downlink data from the IoT server 1066. The request may include a user ID, although the scope of embodiments is not limited in this respect. At operation 1076, the IoT server 1016 may send downlink data to the AP 1062. In some embodiments, the downlink data may be sent to the AP 1062 for forwarding (over a wireless link) to the IoT device 1060. At operation 1077, the IoT device 1060 may transmit a unicast GAS initial frame that may include a request for downlink data from the IoT server 1066. At operation 1078, the AP 1062 may transmit a unicast GAS response frame to the IoT device 1010 that may include the downlink data requested at operation 1077. The network address translation (NAT) component (indicated by 1064) may enable traffic to be sent from the IoT server 1066 to the AP 1062, in some embodiments. It should be noted that some embodiments may not necessarily include the NAT 1064.

[00120] In the example arrangement 1100, one or more operations may be the same as or similar to one or more operations of the example arrangement 1050, although the scope of embodiments is not limited in this respect. The IoT device 1110 may communicate with either or both of APs 1112 and 1114. For instance, the IoT device 1110 may transmit a broadcast message that may be received by either or both of APs 1112 and 1114. The APs 1112 and 1114 may communicate with the IoT server 1116. For instance, either or both of the APs 1112 and 1114 may send at least a portion of a packet received from the IoT device 1110 to the IoT server 1116. The APs 1112 and 1114 may communicate with the IoT server 1116 over wired links, although the scope of embodiments is not limited in this respect.

[00121] At operation 1120, the IoT device 1110 may broadcast a GAS initial frame that may carry one or more of a request for downlink data, user ID, IoT server address and/or other information. The GAS initial frame may be received by either or both of APs 1112 and 1114.

[00122] At operation 1121(a), the AP 1112 may transmit an ACK for the GAS initial frame to the IoT device 1110. At operation 1121(b), the AP 1114 may transmit an ACK for the GAS initial frame to the IoT device 1110. The ACKs transmitted may be the same, although the scope of embodiments is not limited in this respect. It should be noted that the performance of operations 1121(a) and 1121(b) may depend on which of APs 1112 and 1114 receive the GAS initial frame. For instance, the AP 1112 may perform operation 1121(a) if it successfully receives the GAS initial frame and the AP 1114 may perform operation 1121(b) if it successfully receives the GAS initial frame. The APs 1112 and 1114 may perform the respective operations (1121(a) or 1121(b)) if both successfully receive the GAS initial frame.

[00123] At operation 1122(a), the AP 1112 may send, to the IoT server 1116, a request to verify authentication (which may include user ID information, in some cases). At operation 1122(b), the AP 1114 may send, to the IoT server 1116, a request to verify authentication (which may include user ID information, in some cases). The request of operation 1122(b) may be the same request or similar request sent by the AP 1112 at operation 1122(a), although the scope of embodiments is not limited in this respect. It should be noted that the performance of operations 1122(a) and 1122(b) may depend on which of APs 1112 and 1114 receive the GAS initial frame. For instance, the AP 1112 may perform operation 1122(a) if it successfully receives the GAS initial frame and the AP 1114 may perform operation 1122(b) if it successfully receives the GAS initial frame. The APs 1112 and 1114 may perform the respective operations (1122(a) or 1122(b)) if both successfully receive the GAS initial frame.

[00124] At operation 1123, the IoT server 1066 may send a response to the request to verify authentication from operation 1122. In some embodiments, the response may be sent to AP 1112 but not to AP 1114. At operation 1124, the AP 1112 may transmit, to the IoT server 1110, a GAS response frame. The GAS response frame may be unicasted to the IoT device 1110, although the scope of embodiments is not limited in this respect. The GAS response frame may indicate a“come-back time” related to a later time at which downlink data may be transmitted to the IoT device 1110, although the scope of embodiments is not limited in this respect. At operation 1125, the AP 1112 may send a request to receive downlink data from the IoT server 1116. The request may include a user ID, although the scope of embodiments is not limited in this respect. At operation 1126, the IoT server 1116 may send downlink data to the AP 1112. In some embodiments, the downlink data may be sent to the AP 1112 for forwarding (over a wireless link) to the IoT device 1110. At operation 1127, the IoT device 1110 may transmit a unicast GAS initial frame that may include a request for downlink data from the IoT server 1116. At operation 1128, the AP 1112 may transmit a unicast GAS response frame to the IoT device 1110 that may include the downlink data requested at operation 1127.

[00125] Referring to FIG.12, the example GAS Frame 1200 may include one or more of the following: an advertisement protocol ID 1205, a transmit antenna (TA) field 1210, an STA address 1215 (which may be an STA ID, in some cases), an ESS address 1220 (which may be an ESS ID, in some cases), a request for DL data (in 1225). The GAS Frame 1200 may include (as indicated by 1230) any number (including zero, one or other) of other fields and/or parameters and may include other information. The GAS Frame 1200 may be sent as an initial GAS Frame, in some embodiments, although the scope of embodiments is not limited in this respect.

[00126] FIG.13 illustrates the operation of another method of communication in accordance with some embodiments. As mentioned previously regarding the method 800, embodiments of the method 1300 may include additional or even fewer operations or processes in comparison to what is illustrated in FIG.13 and embodiments of the method 1300 are not necessarily limited to the chronological order that is shown in FIG.13. In describing the method 1300, reference may be made to any of FIGs.1-13, although it is understood that the method 1300 may be practiced with any other suitable systems, interfaces and components. In addition, embodiments of the method 1300 may be applicable to IoT STAs 103, APs 102, STAs, UEs, eNBs and/or other wireless or mobile devices. The method 1300 may also be applicable to an apparatus of an AP 102, IoT STA 103, STA and/or other device, in some embodiments. [00127] It should be noted that the method 1300 may be practiced by an AP 102 and may include exchanging of elements, such as frames, signals, messages and/or other elements with an IoT STA 103. The method 800 may be practiced by an IoT STA 103 and may include exchanging of elements, such as frames, signals, messages and/or other elements with an AP 102. In some cases, operations and techniques described as part of the method 800 may be relevant to the method 1300. In addition, embodiments of the method 1300 may include one or more operations that may be the same as, similar to or reciprocal to one or more operations of the method 800 (and/or other operation(s) described herein). For instance, an operation of the method 1300 may include reception of an element (such as a frame, block, message and/or other) by an AP 102 and the method 800 may include transmission of a same or similar element by the IoT STA 103. In addition, one or more operations included in the method 800 may be the same as, or similar to, one of more operations included in the method 1300.

[00128] In addition, previous discussion of various techniques, operations and/or concepts may be applicable to the method 1300, in some cases, including IoT, IoT STAs 103, IoT server, uplink PPDUs, downlink PPDUs, ACK for uplink PPDUs, association of IoT STAs 103 with APs 102, contention for channel resources and/or others.

[00129] It should be noted that references to the IoT STA 103 in descriptions of the method 1300 (and/or other descriptions herein) are not limiting. One or more operations of the method 1300 may include

communication, by the AP 102, with an STA that may not necessarily be an IoT STA 103, in some embodiments.

[00130] At operation 1305, the AP 102 may decode a header of an uplink PPDU broadcast from an IoT STA 103. At operation 1310, the AP 102 may determine whether the uplink PPDU is intended for an IoT server. At operation 1315, the AP 102 may forward (and/or relay) a payload portion of the uplink PPDU to the IoT server. At operation 1320, the AP 102 may contend for access to channel resources. At operation 1325, the AP 102 may transmit an ACK to the IoT STA 103 for the uplink PPDU. The transmission may be performed in the channel resources. The AP 102 may contend for the access to the channel resources to transmit the ACK, in some embodiments. At operation 1330, the AP 102 may refrain from association with the IoT STA 103. For instance, the AP 102 may perform one or more operations while unassociated with the IoT STA 103, including but not limited to operations 1335-1355 and/or others.

[00131] At operation 1335, the AP 102 may determine whether the IoT server intends to send downlink data to the IoT STA 103. For instance, a message from the IoT server may indicate this information. At operation 1340, the AP 102 may receive the downlink data from the IoT server. Operation 1340 may be performed if it is determined that the downlink data is to be transmitted to the IoT STA 103. At operation 1345, the AP 102 may transmit the downlink data to the IoT STA 103. In some embodiments, one or more downlink PPDUs may be transmitted. In a non-limiting example, the downlink data and/or downlink PPDU may be included in a GAS frame. At operation 1350, the AP 102 may receive an ACK from the IoT STA 103 for the downlink PPDU. At operation 1355, the AP 102 may send an ACK to the IoT server to indicate successful reception of the downlink PPDU at the IoT STA 103.

[00132] In some embodiments, the AP 102 may receive, from an IoT server on an interface, a configuration message for a service in which the AP 102 is to: receive broadcast transmissions from IoT STAs 103 unassociated with the AP 102; and forward data of the broadcast transmissions to the IoT server. Accordingly, the AP 102 may be configured to support the service. The AP 102 may decode a header of an uplink PPDU received in channel resources. The uplink PPDU may be a broadcast PPDU from an IoT STA 103, in some cases. The AP 102 may determine, based on the decoded header, whether the uplink PPDU was transmitted as part of the service. The AP 102 may, if it is determined that the uplink PPDU was transmitted as part of the service: forward the payload portion of the uplink PPDU to the IoT server over the interface; and encode, for transmission in the channel resources, an ACK for the uplink PPDU.

[00133] In some embodiments, the AP 102 may, if it is determined that the uplink PPDU was transmitted as part of the service: encode an authentication request message for the IoT server for authentication of a particular IoT STA 103 that transmitted the uplink PPDU; decode an authentication response from the IoT server; and forward the payload portion of the uplink PPDU to the IoT server over the interface if the authentication response message indicates that the particular IoT STA 103 is authenticated for the service at the IoT server. The AP 102 may refrain from forward of the payload portion, transmission of ACK messages to the particular IoT STA 103, transmission of data to the particular IoT STA 103 and/or other operations if the authentication response message indicates that the particular IoT STA 103 is not authenticated for the service at the IoT server, in some embodiments. The AP 102 may, if it is determined that the uplink PPDU was not transmitted as part of the service: refrain from forward of the payload portion of the uplink PPDU to the IoT server. The AP 102 may, if it is determined that the uplink PPDU was transmitted as part of the service: refrain from association, for the transmission of the ACK, with the particular IoT STA that transmitted the uplink PPDU. The AP 102 may, if it is determined that the uplink PPDU was transmitted as part of the service: encode the ACK for transmission during a predetermined time window subsequent to a reception of the uplink PPDU.

[00134] In some embodiments, the AP 102 may receive an uplink PPDU from an IoT STA 103 (and/or other STA) that is unassociated with the AP 102. The uplink PPDU may be received in channel resources. In some embodiments, the AP 102 may operate in an ESS, and the IoT STA 103 may be unassociated from APs 102 of the ESS. The AP 102 may decode a header of the uplink PPDU. The AP 102 may determine, based on the decoded header, whether the uplink PPDU is intended for an IoT server (which may or not be part of the ESS). If it is determined that the uplink PPDU is intended for the IoT server, the AP 102 may: store a payload portion of the uplink PPDU in the memory;

forward the payload portion of the uplink PPDU to the IoT server over an interface; and encode, for transmission to the IoT STA 103 in the channel resources, an ACK for the uplink PPDU. If it is determined that the uplink PPDU is not intended for the IoT server, the AP 102 may refrain from forwarding the payload portion of the uplink PPDU to the IoT server.

[00135] In some embodiments, if it is determined that the uplink PPDU is intended for the IoT server, the AP 102 may refrain from association with the IoT STA 103 for the transmission of the ACK. In some embodiments, if it is determined that the uplink PPDU is intended for the IoT server, the AP 102 may transmit the ACK to the IoT STA 103 during a predetermined time window subsequent to a reception of the uplink PPDU. If it is determined that the uplink PPDU is intended for the IoT server, the AP 102 may determine, based on a response message received from the IoT server over the interface, whether the IoT server intends to send downlink data to the IoT STA 103. If it is determined that the IoT server intends to send downlink data to the IoT STA 103, the AP 102 may decode the downlink data from the IoT server and may encode the downlink data in a downlink PPDU for transmission to the IoT STA while unassociated from the IoT STA 103.

[00136] In some embodiments, IoT STAs 103 may operate in accordance with IoT techniques and/or protocols, wherein (in comparison to cellular systems and some other systems) a relatively low power is used and relatively small amounts of data are exchanged. In addition, such exchanges may occur relatively infrequently in comparison to exchanges in protocols of cellular systems and other systems.

[00137] In some embodiments, IoT STAs 103 may be mobile within an ESS for instance. For example, an enterprise with an ESS deployment with blanket coverage over the entire site with multiple APs 102, sensors and/or other components. For IoT STAs 103 in mobility, and for the STAs associated to APs 102 which disassociate STAs in response to a long duration of inactivity, a cost of association may be relatively high. For instance, if an IoT STA 103 is not associated upon wake-up (for instance, it is either disassociated or not in a coverage of a previously serving AP 102), the IoT STA 103 may have to scan, identify a target AP 102, and perform full association before being able to send its payload. The time and energy consumed for this (re)association may become problematic, in some cases.

[00138] In some embodiments, an ESS may be deployed over an area, and some or all APs 102 deployed in the ESS may support operations described herein. It should be noted that embodiments described herein may be extended to a wider area in some cases. In a non-limiting example, all APs 102 supporting the operations described herein may not necessarily be deployed as part of the ESS. In another non-limiting example, multiple APs 102 may not be part of an ESS but may support one or more operations described herein. For instance, a deployed system could support operations described herein in home APs 102 (such as APs 102 in different households).

[00139] In some embodiments, an IoT STA 103 may not necessarily discover the APs 102 that support some operations/features related to IoT. The IoT STA 103 may broadcast PPDUs and/or other frames when it has something to transmit and may determine whether there are any supporting APs 102 if the IoT STA 103 receives a response (such as an ACK or other). If the IoT STA 103 does not hear a response/ACK back, it may adjust a window in which it may wake up and re-attempt transmission. Such operation may be a trade-off for power save and discovery of supporting APs 102, in some cases. The IoT STA 103 may wake up when it is in the area covered by the ESS, and may transmit a PPDU with an uplink data payload in a broadcast PPDU. The broadcast PPDU may also include information that may enable an AP 102 (and/or other receiving entity) to determine how to forward the packet to a relevant IoT server. In some embodiments, security and/or authentication may be performed between the IoT STA 103 and the IoT server in accordance with cloud technique(s). This may be a higher layer security mechanism, and may be pre-configured (such as before the IoT STA 103 is purchased by an end user). In some embodiments, in cases in which the IoT STA 103 is in an area in which no APs 102 support the IoT operation/feature, the IoT STA 103 may not receive any response from a broadcast PPDU.

[00140] In some embodiments, an AP 102 of the ESS that supports the IoT operation/functionality may receive the PPDU, may detect that it is a PPDU sent by the IoT STA 103 in accordance with techniques described herein (such as broadcast transmission while unassociated with APs 102), and may forward a payload portion and/or data portion to the IoT server. In an UL traffic case, the data payload may be the UL data that is to be sent to the IoT server. The AP 102 may also receive DL traffic from the IoT Server destined for the IoT STA 103. In that case, the data payload in the PPDU sent by the STA to the AP may include a request for the IoT server to send the DL traffic.

[00141] In some embodiments, a predetermined time for ACK transmission may be based on the following (or similar): the AP(s) 102 that receive uplink PPDUs from the IoT STA 103 while the IoT STA 103 is unassociated from the APs 102 may (and/or shall) transmit an ACK at a time that is a short inter-frame spacing (SIFS) after the end of an event (such as PPDU transmission, PPDU reception and/or other). Embodiments are not limited to the SIFS, as other suitable time periods and/or time intervals may be used. In cases in which multiple APs 102 receive the PPDU, the APs 102 for which the PPDU is correctly received may simultaneously transmit an ACK. The ACK may be the same, in some cases, which may enable the IoT STA 103 to receive it, although the scope of embodiments is not limited in this respect. In some embodiments, the ACK may not include a TA address, so the transmission of the same ACK by the different APs 102 may be possible. In some embodiments, the AP(s) may transmit the ACK as soon as possible, which may be performed in accordance with a rule, guideline of a protocol/standard, although the scope of embodiments is not limited in this respect.

[00142] In some embodiments, AP(s) 102 that receive the PPDU from the IoT STA 103 may transmit a unicast response/ACK to the IoT STA 103. The response/ACK may include one or more of: an ACK from the IoT server that the IoT server received the data payload for the UL case, the DL data payload from the IoT server and/or other. In cases in which a delay to receive a response from the IoT server is too long (such as longer than a predetermined threshold), the AP 102 may transmit a first response frame to the IoT STA 103 indicating a come-back time at which the DL data will be available and/or buffered in queues of the APs 102. At the come-back time, the AP 102 may transmit a response with the data from the IoT server or the STA 103 may send a request frame to request the data.

[00143] Referring to FIG.9, in the example 900, the IoT device 910 (such as an IoT STA or other) may transmit over-the-air. The transmission may be in accordance with a wireless local area network (WLAN) protocol, a Wi-Fi protocol, an 802.11 protocol and/or other protocol. The transmission may be performed without association to APs 920, 930, which may belong to an ESS. The APs 920, 930 may be connected through 924, 934 (the internet or any suitable technique for connectivity may be used to the IoT cloud server 940. In some embodiments, such as in the example 950, a local controller 990 may be connected to the APs 970, 980. The local controller 990 may perform one or more operations, such as removal of duplicates in cases in which multiple APs (such as both of APs 970, 980 in the example 950) received successfully the PPDU sent by the IoT device 960. To remove the duplicate(s), the local controller 990 may use feedback from the APs 970, 980, in some cases. If the local controller 990 intends to select the AP (of 970, 980) with the best signal received from the IoT device 960, the APs 970, 980 may send a received signal strength indicator (RSSI) and/or other signal quality measurement(s) for reception of the PPDU from the IoT device 960. Such feedback may be sent along with the data payload of the particular AP (of 970, 980) of the higher RSSI (or other measurement). In some embodiments, the local controller 990 may perform a selection of the AP (of 970, 980) without feedback from the APs 970, 980. For instance, the local controller 990 may select the first signal it receives (chronologically) and may discard other signals received subsequently. These examples are not limiting, however, as any suitable technique may be used by the local controller 990 for sending data received from one or more APs (such as 970, 980) on behalf of the IoT device 960. In addition, the examples 900, 950 and techniques described regarding FIG.9 may be extended to more than two APs.

[00144] In some embodiments, a service may be established between an IoT device (such as 910 in FIG.9) and an IoT cloud server (such as 940 in FIG. 9) using any suitable technique(s). For instance, the service may be pre- configured before, during or after purchase of the IoT device 910 by an end user. As part of the preconfiguration operation, the IoT device 910 and the IoT cloud server 940 may perform one or more of the following: negotiate security and/or authentication, exchange security and/or authentication keys, assign user IDs and/or other operation(s). The IoT device 910 may know and/or determine an address (such as an IP address and/or other) of the IoT server 940. Although the example 900 is used to describe one or more operations above, embodiments are not limited to the example 900.

[00145] In some embodiments, when the IoT STA 910 has data and/or information to send to the IoT cloud server 940 or wants to request DL traffic from the IoT cloud server, the IoT device 910 may wake up on one channel; perform a backoff; transmit, in an unassociated mode, a broadcast PPDU. A GAS container may be used, although the scope of embodiments is not limited in this respect. The GAS container may include the request, a user identification (such as an identification of the IoT STA 910), an address (IP address and/or other) of the IoT cloud server 940, MAC address and/or IP address of the IoT device 910, and the data payload (in cases in which UL traffic is sent). The choice of the channel on which to transmit may be pre-selected and/or predetermined, in some cases. Otherwise, the IoT device 910 may wait for a response before attempting to transmit on other channels or may transmit on other channel(s). Once an ACK of the uplink traffic (uplink PPDU and/or other) is received at the IoT device 910, the IoT device 910 may go back to sleep directly or may wait for a more detailed response from one or more APs 920, 930. The response may include an ACK from the IoT cloud server 940 or a DL data payload from the IoT cloud server 940. The response may indicate a come- back-time when the data payload and/or other information may be available. In cases in which a come-back time is used, the IoT device 910 may go back to sleep until the come-back time. Although the example 900 is used to describe one or more operations above, embodiments are not limited to the example 900.

[00146] In some embodiments, if the AP 920 receives a broadcast PPDU from an unassociated IoT device 910, the AP 920 may detect the PPDU and may identify the PPDU as an encapsulated data payload for the IoT cloud server 940. If the PPDU is received successfully at the AP 920, the AP 920 may send an ACK after a duration (such as SIFS and/or other) has elapsed with respect to the end of the PPDU reception in one mode of operation. Or the AP 920 may attempt to access the channel after having received the PPDU to transmit a frame that acts as an ACK under another mode of operation. The AP 920 may forward the data payload directly to the IoT cloud server 940. The AP 930 may perform the same operations, or similar operations, as the AP 920, in some embodiments.

[00147] In the example 950, the AP 970 may forward data payload from a PPDU (received from IoT device 960) to the local controller 990, which may remove duplicates if multiple APs (such as 970, 980 in the example 950) successfully received the same PPDU. In the example 950, the local controller 990 may forward the payload to the IoT cloud server 995. The APs 970, 980 may include additional information in its exchange with the local controller 990 (such as an RSSI, received power, information about the location of the IoT device 960 and/or other information). The APs 920, 930 in the example 900 may include similar information in exchanges with the IoT cloud server 940, in some embodiments. Although the examples 900, 950 are used to describe one or more operations above, embodiments are not limited to the examples 900, 950.

[00148] In some embodiments, the AP 970 or local controller 990 may perform filter operation(s) and may use security information contained in the PPDU from the IoT device 960 to verify the identity of the IoT device 960, to verify if the IoT device 960 is registered (such as for IoT service) in a AAA server or in the IoT cloud server 995. As the broadcast PPDU may include user identification credentials, the request, and the data for the IoT server, the AP 970 may first send to the IoT cloud server 995 the user identification credentials to check if the user is authenticated. If the response from the IoT cloud server 995 is positive, the AP 970 may forward the data payload. In cases in which a PPDU from the IoT device 960 is received by multiple APs (such as 970, 980), either the local controller 990 or the IoT cloud server 995 may decide which of the APs (such as 970 or 980) is to transmit DL data to the IoT device 960. This decision may be based on one or more factors, including but not limited to link quality/localization information that the AP(s) (such as 970 and/or 980) may share with the local controller 990 and/or IoT cloud server 995. Although the example 950 is used to describe one or more operations above, embodiments are not limited to the example 950.

[00149] In some embodiments, a Wi-Fi container may be used for PPDUs, wherein a BSSID field may be set to a wildcard BSSID value. In some embodiments, a MAC container may be defined to enable a transmission between the IoT STA 103 and the AP 102 of a self-contained pre-association PPDU.

[00150] In some embodiments, a GAS frame may be used and may enable pre-association exchanges of information. In some cases, the GAS frame may be used to enable devices (such as STAs) in pre-association mode to collect information from a server through a specific AP 102. The STA may send a GAS initial request to the AP 102, which may include information to enable forwarding of the request to a server. The AP may forward the request to the server and may receive a response from the server. The AP 102 may send a GAS initial response frame to the STA with the response from the server. If the response from the server comes late (such as after a predetermined threshold of time) or is larger than a predetermined size restriction (so that it may not be transmitted in a single PPDU), the STA may request again the AP 102 to provide the response from the server, which may be available at that time.

[00151] In some embodiments, techniques described herein may use the GAS frame. One or more of the following modifications may be used in some embodiments (although in some embodiments, the following modifications may not necessarily be performed). The IoT STA 103 may send a GAS frame with its address in a TA field. For instance, an ESS address, a predetermined broadcast address and/or other address may be used. The IoT STA 103 may transmit its frame to any AP 102 (which may or may not be in the ESS) that supports some or all of the techniques described herein. In an uplink scenario, instead of being a request for feedback from the server, the initial GAS frame from the IoT STA 103 may include a data payload for the IoT server (UL traffic instead of a request for DL traffic). The IoT server may respond with an ACK. In a downlink scenario, the IoT STA 103 may send a request to the server in the initial GAS frame. In response, the IoT server may send the DL data to the IoT STA 103 through the AP 102 that forwarded the GAS request. In some embodiments, an advertisement protocol ID may be defined so that the GAS frame may be identified as being for a service that supports techniques described herein (such as the communication between IoT STA 103 and an IoT server while unassociated with APs 102 of the ESS).

[00152] In some embodiments, frames such as probe requests and probe responses may be used in one or more operations, techniques and/or methods described herein.

[00153] In Example 1, an apparatus of an internet-of-things (IoT) station (STA) may comprise memory. The apparatus may further comprise processing circuitry. The processing circuitry may be configured to, while the IoT STA is in a power save mode, determine that the IoT STA is to transmit uplink data to an IoT server. The processing circuitry may be further configured to transition the IoT STA from the power save mode to an awake mode based on the determination that the IoT STA is to transmit the uplink data. The processing circuitry may be further configured to contend for access to channel resources. The processing circuitry may be further configured to encode the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission in the channel resources to access points (APs) of an extended service set (ESS) for relay to the IoT server, the uplink PPDU transmitted while the IoT STA is unassociated with the APs of the ESS. The broadcast transmission may be performed as part of a preconfigured service in which the APs are to operate as relays for communication between the IoT server and IoT STAs. The uplink PPDU may include the uplink data, an identifier of the ESS, and an indicator that the uplink PPDU is encoded for the service.

[00154] In Example 2, the subject matter of Example 1, wherein the processing circuitry may be further configured to encode the uplink PPDU as a generic advertisement service (GAS) frame that includes: an address of the IoT STA, an address of the ESS or a broadcast address, and an advertisement protocol identifier field that indicates that the uplink PPDU is encoded for the service.

[00155] In Example 3, the subject matter of one or any combination of Examples 1-2, wherein the processing circuitry may be further configured to refrain from association with the APs for the broadcast transmission.

[00156] In Example 4, the subject matter of one or any combination of Examples 1-3, wherein the processing circuitry may be further configured to attempt to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs. The processing circuitry may be further configured to, if the ACK is detected, transition the IoT STA from the awake mode to the power save mode.

[00157] In Example 5, the subject matter of one or any combination of Examples 1-4, wherein the processing circuitry may be further configured to, if the ACK is detected: decode the ACK; determine, based on the decoded ACK, whether the IoT STA is to receive a downlink PPDU; if it is determined that the IoT STA is to receive a downlink PPDU, attempt to detect the downlink PPDU from one or more of the APs in the channel resources, and if the downlink PPDU is detected, transition the IoT STA from the awake mode to the power save mode.

[00158] In Example 6, the subject matter of one or any combination of Examples 1-5, wherein the processing circuitry may be further configured to, if the ACK is detected and if it is determined that the IoT STA is not to receive the downlink PPDU: transition the IoT STA from the awake mode to the power save mode.

[00159] In Example 7, the subject matter of one or any combination of Examples 1-6 wherein the processing circuitry may be further configured to, if the ACK is detected and if it is determined that the IoT STA is to receive the downlink PPDU: monitor the channel resources for the downlink PPDU during a predetermined time window subsequent to the detection of the ACK.

[00160] In Example 8, the subject matter of one or any combination of Examples 1-7, wherein the ACK may be configurable as a simulcast ACK from multiple APs during a predetermined time window subsequent to the

transmission of the uplink PPDU. The processing circuitry may be further configured to attempt to detect the ACK during the predetermined time window.

[00161] In Example 9, the subject matter of one or any combination of Examples 1-8, wherein the ACK is a first ACK. The processing circuitry may be further configured to, if the ACK is not detected: determine a backoff count for a retransmission of the uplink PPDU; and attempt to detect a second ACK for the uplink PPDU in the channel resources from one or more of the APs.

[00162] In Example 10, the subject matter of one or any combination of Examples 1-9, wherein the processing circuitry may be further configured to contend for the access to the channel resources during an awake period in which the IoT STA is in the awake mode. The processing circuitry may be further configured to detect the ACK during the awake period. The broadcast transmission of the uplink PPDU may be performed during the awake period. The processing circuitry may be further configured to refrain from association with the APs during the awake period.

[00163] In Example 11, the subject matter of one or any combination of Examples 1-10, wherein the processing circuitry may be further configured to maintain the IoT STA in the power save mode when the IoT STA is not to transmit uplink data.

[00164] In Example 12, the subject matter of one or any combination of Examples 1-11, wherein the memory may be configurable to store the uplink PPDU.

[00165] In Example 13, the subject matter of one or any combination of Examples 1-12, wherein the apparatus may further include a transceiver to transmit the uplink PPDU.

[00166] In Example 14, the subject matter of one or any combination of Examples 1-13, wherein the transceiver may be configurable to be coupled to one or more antennas. Operation of the IoT STA in the power save mode may include restriction of transmission and reception of signals by the transceiver. The processing circuitry may be further configured to, as part of the transition of the IoT STA from the awake mode to the power save mode: instruct the transceiver to restrict the transmission and the reception of signals.

[00167] In Example 15, the subject matter of one or any combination of Examples 1-14, wherein the processing circuitry may include a baseband processor to determine that the IoT STA is to transmit the uplink data and to encode the uplink data in the uplink PPDU.

[00168] In Example 16, a computer-readable storage medium may store instructions for execution by one or more processors to perform operations for communication by a station (STA). The operations may configure the one or more processors to, while the STA is in a sleep mode, determine whether the STA is to transmit uplink data to an internet-of-things (IoT) server. The operations may configure the one or more processors to, if it is determined that the STA is not to transmit the uplink data, maintain the STA in the sleep mode. The operations may further configure the one or more processors to, if it is determined that the STA is to transmit the uplink data: transition the STA from the sleep mode to an awake mode; refrain from association with access points (APs) of an extended service set (ESS); contend for access to channel resources; and encode the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission to the APs for forwarding to the IoT server, the broadcast transmission in the channel resources while the STA is unassociated from the APs.

[00169] In Example 17, the subject matter of Example 16, wherein the operations may further configure the one or more processors to, if it is determined that the STA is to transmit the uplink data: attempt to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs; if the ACK is detected, transition the STA from the awake mode to the sleep mode; and if the ACK is not detected, determine a backoff count for a retransmission of the uplink PPDU.

[00170] In Example 18, the subject matter of one or any combination of Examples 16-17, wherein the operations may further configure the one or more processors to, if it is determined that the STA is to transmit the uplink data, encode the uplink data in an uplink PPDU of a generic advertisement service (GAS) frame that includes: an address of the STA, and an address of the IoT server.

[00171] In Example 19, a method of communication at a station (STA) may comprise, while the STA is in a sleep mode, determining that the STA is to transmit uplink data. The method may further comprise transitioning from the sleep mode to an awake mode based on the determination that the STA is to transmit the uplink data. The method may further comprise contending for access to channel resources. The method may further comprise encoding the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission to access points (APs) of an extended service set (ESS) while the STA is unassociated from the APs, the broadcast transmission in the channel resources. The method may further comprise attempting to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs. The method may further comprise, if the ACK is detected, transitioning from the awake mode to the sleep mode.

[00172] In Example 20, the subject matter of Example 19, wherein the method may further comprising refraining from association with the APs for the broadcast transmission and for the attempted detection of the ACK. [00173] In Example 21, an apparatus of an access point (AP) may comprise memory. The apparatus may further comprise an interface. The apparatus may further comprise processing circuitry. The processing circuitry may be configured to decode, from an internet-of-things (IoT) server on the interface, a configuration message for a service in which the AP is to: receive broadcast transmissions from IoT STAs unassociated with the AP; and forward data of the broadcast transmissions to the IoT server. The processing circuitry may be further configured to decode a header of an uplink physical layer convergence procedure protocol data unit (PPDU) received in channel resources. The processing circuitry may be further configured to determine, based on the decoded header, whether the uplink PPDU was transmitted as part of the service. The processing circuitry may be further configured to, if it is determined that the uplink PPDU was transmitted as part of the service: forward the payload portion of the uplink PPDU to the IoT server over the interface; and encode, for transmission in the channel resources, an ACK for the uplink PPDU.

[00174] In Example 22, the subject matter of Example 21, wherein the processing circuitry may be further configured to, if it is determined that the uplink PPDU was transmitted as part of the service: encode an authentication request message for the IoT server for authentication of a particular IoT STA that transmitted the uplink PPDU; decode an authentication response from the IoT server; and forward the payload portion of the uplink PPDU to the IoT server over the interface if the authentication response message indicates that the particular IoT STA is authenticated for the service at the IoT server.

[00175] In Example 23, the subject matter of one or any combination of Examples 21-22, wherein the processing circuitry may be further configured to, if it is determined that the uplink PPDU was not transmitted as part of the service: refrain from forward of the payload portion of the uplink PPDU to the IoT server.

[00176] In Example 24, the subject matter of one or any combination of Examples 21-23, wherein the processing circuitry may be further configured to, if it is determined that the uplink PPDU was transmitted as part of the service: refrain from association, for the transmission of the ACK, with the particular IoT STA that transmitted the uplink PPDU. [00177] In Example 25, the subject matter of one or any combination of Examples 21-24, wherein the processing circuitry further configured to, if it is determined that the uplink PPDU was transmitted as part of the service: encode the ACK for transmission during a predetermined time window subsequent to a reception of the uplink PPDU.

[00178] In Example 26, the subject matter of one or any combination of Examples 21-25, wherein the processing circuitry may be further configured to, if it is determined that the uplink PPDU was transmitted as part of the service: determine, based on a response message received from the IoT server over the interface, whether the IoT server intends to send downlink data to a particular IoT STA that transmitted the uplink PPDU. The processing circuitry may be further configured to, if it is determined that the uplink PPDU was transmitted as part of the service and if it is determined that the IoT server intends to send downlink data to the particular IoT STA: decode the downlink data from the IoT server; and encode the downlink data in a downlink PPDU for transmission to the particular IoT STA while unassociated from the particular IoT STA.

[00179] In Example 27, an apparatus of a station (STA) may comprise means for, while the STA is in a sleep mode, determining whether the STA is to transmit uplink data to an internet-of-things (IoT) server. The apparatus may further comprise means for, if it is determined that the STA is not to transmit the uplink data, maintaining the STA in the sleep mode. The apparatus may further comprise means for, if it is determined that the STA is to transmit the uplink data: transitioning the STA from the sleep mode to an awake mode; refraining from association with access points (APs) of an extended service set (ESS); contending for access to channel resources; encoding the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission to the APs for forwarding to the IoT server, the broadcast transmission in the channel resources while the STA is unassociated from the APs.

[00180] In Example 28, the subject matter of Example 27, the apparatus further comprising means for, if it is determined that the STA is to transmit the uplink data: attempting to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs; if the ACK is detected, transitioning the STA from the awake mode to the sleep mode; and if the ACK is not detected, determining a backoff count for a retransmission of the uplink PPDU.

[00181] In Example 29, the subject matter of one or any combination of Examples 27-28, wherein the apparatus may further comprising means for, if it is determined that the STA is to transmit the uplink data, encoding the uplink data in an uplink PPDU of a generic advertisement service (GAS) frame that includes: an address of the STA, and an address of the IoT server.

[00182] The Abstract is provided to comply with 37 C.F.R. Section 1.72(b) requiring an abstract that will allow the reader to ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to limit or interpret the scope or meaning of the claims. The following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims

What is claimed is: 1. An apparatus of an internet-of-things (IoT) station (STA), the apparatus comprising: memory; and processing circuitry, configured to:

while the IoT STA is in a power save mode, determine that the IoT STA is to transmit uplink data to an IoT server;

transition the IoT STA from the power save mode to an awake mode based on the determination that the IoT STA is to transmit the uplink data; contend for access to channel resources; and

encode the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission in the channel resources to access points (APs) of an extended service set (ESS) for relay to the IoT server, the uplink PPDU transmitted while the IoT STA is unassociated with the APs of the ESS,

wherein the broadcast transmission is performed as part of a

preconfigured service in which the APs are to operate as relays for

communication between the IoT server and IoT STAs,

wherein the uplink PPDU includes the uplink data, an identifier of the ESS, and an indicator that the uplink PPDU is encoded for the service.

2. The apparatus according to claim 1, the processing circuitry further configured to:

encode the uplink PPDU as a generic advertisement service (GAS) frame that includes:

an address of the IoT STA,

an address of the ESS or a broadcast address, and an advertisement protocol identifier field that indicates that the uplink PPDU is encoded for the service.

3. The apparatus according to claim 1, the processing circuitry further configured to refrain from association with the APs for the broadcast transmission.

4. The apparatus according to claim 1, the processing circuitry further configured to:

attempt to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs; and

if the ACK is detected, transition the IoT STA from the awake mode to the power save mode.

5. The apparatus according to any of claims 1-4, the processing circuitry further configured to, if the ACK is detected:

decode the ACK;

determine, based on the decoded ACK, whether the IoT STA is to receive a downlink PPDU;

if it is determined that the IoT STA is to receive a downlink PPDU: attempt to detect the downlink PPDU from one or more of the APs in the channel resources; and

if the downlink PPDU is detected, transition the IoT STA from the awake mode to the power save mode.

6. The apparatus according to claim 5, the processing circuitry further configured to, if the ACK is detected and if it is determined that the IoT STA is not to receive the downlink PPDU:

transition the IoT STA from the awake mode to the power save mode.

7. The apparatus according to claim 5, the processing circuitry further configured to, if the ACK is detected and if it is determined that the IoT STA is to receive the downlink PPDU:

monitor the channel resources for the downlink PPDU during a predetermined time window subsequent to the detection of the ACK.

8. The apparatus according to any of claims 1-4, wherein:

the ACK is configurable as a simulcast ACK from multiple APs during a predetermined time window subsequent to the transmission of the uplink PPDU, the processing circuitry is further configured to attempt to detect the ACK during the predetermined time window.

9. The apparatus according to any of claims 1-4, wherein:

the ACK is a first ACK,

the processing circuitry is further configured to, if the ACK is not detected:

determine a backoff count for a retransmission of the uplink PPDU; and

attempt to detect a second ACK for the uplink PPDU in the channel resources from one or more of the APs.

10. The apparatus according to any of claims 1-4, wherein:

the processing circuitry is further configured to contend for the access to the channel resources during an awake period in which the IoT STA is in the awake mode,

the processing circuitry is further configured to detect the ACK during the awake period,

the broadcast transmission of the uplink PPDU is to be performed during the awake period,

the processing circuitry is further configured to refrain from association with the APs during the awake period.

11. The apparatus according to claim 1, the processing circuitry further configured to maintain the IoT STA in the power save mode when the IoT STA is not to transmit uplink data.

12. The apparatus according to claim 1, wherein the memory is configurable to store the uplink PPDU.

13. The apparatus according to claim 1, wherein the apparatus further includes a transceiver to transmit the uplink PPDU.

14. The apparatus according to claim 13, wherein:

the transceiver is configurable to be coupled to one or more antennas, operation of the IoT STA in the power save mode includes restriction of transmission and reception of signals by the transceiver, and

the processing circuitry is further configured to, as part of the transition of the IoT STA from the awake mode to the power save mode:

instruct the transceiver to restrict the transmission and the reception of signals.

15. The apparatus according to any of claims 11-14, wherein the processing circuitry includes a baseband processor to determine that the IoT STA is to transmit the uplink data and to encode the uplink data in the uplink PPDU.

16. A computer-readable storage medium that stores instructions for execution by one or more processors to perform operations for communication by a station (STA), the operations to configure the one or more processors to: while the STA is in a sleep mode, determine whether the STA is to transmit uplink data to an internet-of-things (IoT) server;

if it is determined that the STA is not to transmit the uplink data, maintain the STA in the sleep mode;

if it is determined that the STA is to transmit the uplink data:

transition the STA from the sleep mode to an awake mode;

refrain from association with access points (APs) of an extended service set (ESS);

contend for access to channel resources;

encode the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission to the APs for forwarding to the IoT server, the broadcast transmission in the channel resources while the STA is unassociated from the APs.

17. The computer-readable storage medium according to claim 16, the operations to further configure the one or more processors to, if it is determined that the STA is to transmit the uplink data:

attempt to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs;

if the ACK is detected, transition the STA from the awake mode to the sleep mode; and

if the ACK is not detected, determine a backoff count for a

retransmission of the uplink PPDU.

18. The computer-readable storage medium according to claim 16, the operations to further configure the one or more processors to, if it is determined that the STA is to transmit the uplink data:

encode the uplink data in an uplink PPDU of a generic advertisement service (GAS) frame that includes:

an address of the STA, and

an address of the IoT server.

19. A method of communication at a station (STA), the method comprising:

while the STA is in a sleep mode, determining that the STA is to transmit uplink data;

transitioning from the sleep mode to an awake mode based on the determination that the STA is to transmit the uplink data;

contending for access to channel resources;

encoding the uplink data in an uplink physical layer convergence procedure protocol data unit (PPDU) for broadcast transmission to access points (APs) of an extended service set (ESS) while the STA is unassociated from the APs, the broadcast transmission in the channel resources;

attempting to detect an acknowledgement (ACK) for the uplink PPDU in the channel resources from at least one of the APs; and if the ACK is detected, transitioning from the awake mode to the sleep mode.

20. The method according to claim 19, further comprising refraining from association with the APs for the broadcast transmission and for the attempted detection of the ACK.

21. An apparatus of an access point (AP), the apparatus comprising: memory; an interface; and processing circuitry, configured to:

decode, from an internet-of-things (IoT) server on the interface, a configuration message for a service in which the AP is to:

receive broadcast transmissions from IoT STAs unassociated with the AP; and

forward data of the broadcast transmissions to the IoT server; decode a header of an uplink physical layer convergence procedure protocol data unit (PPDU) received in channel resources;

determine, based on the decoded header, whether the uplink PPDU was transmitted as part of the service;

if it is determined that the uplink PPDU was transmitted as part of the service:

forward the payload portion of the uplink PPDU to the IoT server over the interface; and

encode, for transmission in the channel resources, an ACK for the uplink PPDU.

22. The apparatus according to claim 21, the processing circuitry further configured to:

encode an authentication request message for the IoT server for authentication of a particular IoT STA that transmitted the uplink PPDU;

decode an authentication response from the IoT server; and forward the payload portion of the uplink PPDU to the IoT server over the interface if the authentication response message indicates that the particular IoT STA is authenticated for the service at the IoT server.

23. The apparatus according to claim 21, the processing circuitry further configured to, if it is determined that the uplink PPDU was not transmitted as part of the service:

refrain from forward of the payload portion of the uplink PPDU to the IoT server.

24. The apparatus according to claim 21, the processing circuitry further configured to, if it is determined that the uplink PPDU was transmitted as part of the service:

refrain from association, for the transmission of the ACK, with the particular IoT STA that transmitted the uplink PPDU.

25. The apparatus according to claim 21, the processing circuitry further configured to:

encode the ACK for transmission during a predetermined time window subsequent to a reception of the uplink PPDU.

26. The apparatus according to claim 21, the processing circuitry further configured to, if it is determined that the uplink PPDU was transmitted as part of the service:

determine, based on a response message received from the IoT server over the interface, whether the IoT server intends to send downlink data to a particular IoT STA that transmitted the uplink PPDU;

if it is determined that the IoT server intends to send downlink data to the particular IoT STA:

decode the downlink data from the IoT server; and encode the downlink data in a downlink PPDU for transmission to the particular IoT STA while unassociated from the particular IoT STA.