RU2782452C1 - Methods and wtru for wur scanning - Google Patents

Abstract

FIELD: communication technology.

SUBSTANCE: invention relates to the field of communication with application in a wireless transmission/reception module (WTRU). The method provides for: generation by the station control object (SME) of a request primitive that provides the process of scanning wake-up radio devices (WUR) for WUR detection frames transmitted by one or more access points (AP), and the request primitive contains a set of the first parameters; performing the WUR scanning process using WUR based on a set of first parameters; generating at least one confirmation primitive at the MAC level based on the result of the WUR scanning process and at least part of the set of first parameters; and transmitting at least one confirmation primitive from the MAC level to SME.

EFFECT: achieving the ability for WTRU to determine when to start scanning wake-up radio devices (WUR).

20 cl, 23 dwg, 1 tbl

Description

Cross-reference to related applications

This application claims benefit from U.S. Provisional Application No. 62/811,967, filed Feb. 28, 2019, the contents of which are incorporated herein by reference in their entirety.

Prerequisites for the creation of the invention

Fixed or low mobility wireless for local area networks (LANs) uses technologies such as IEEE (Institute of Electrical and Electronics Engineers) 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ax, 802.11be, or 802.11 in general x, also commonly referred to as WiFi. These technologies refer to media access control (MAC) and physical layer (PHY) specifications for creating wireless local area networks (WLANs) between at least two points. With the growth of WLAN, it may be desirable to transmit signals in one transmission for several types of WLAN interfaces in order to achieve the desired performance and spectral efficiency.

Statement of the Invention

A method for use in a wireless transmit/receive unit (WTRU) is described. The method includes: generating, by a station management entity (SME), a request primitive providing a wake-up radio (WUR) scanning process for WUR discovery frames transmitted by one or more access points (APs), the request primitive comprising a plurality of first parameters; performing a WUR scanning process based on the plurality of first parameters; and generating at the MAC level at least one confirmation primitive based on the result of the WUR scanning process and at least a portion of the plurality of first parameters; and transmitting at least one acknowledge primitive from the MAC layer to the SME.

A wireless transmit/receive unit (WTRU) has been described. The WTRU comprises: a processor configured to generate a request primitive providing a WRU scanning process for WUR discovery frames transmitted by one or more access points (APs), the request primitive comprising a plurality of first parameters; performing a WUR scanning process based on the plurality of first parameters; generating at the MAC level at least one confirmation primitive based on the result of the WUR scanning process and at least a portion of the plurality of first parameters; and transmitting from the MAC layer to the station control entity (SME) at least one acknowledge primitive.

Brief description of graphic materials

A more detailed explanation is contained in the description below, given by way of example, in conjunction with the accompanying drawings, in which like reference numbers in the figures denote like elements:

in fig. 1A is a system diagram illustrating an example of a communications system in which one or more of the described embodiments may be implemented;

in fig. 1B is a system diagram illustrating an example of a wireless transmit/receive unit (WTRU) that may be used in the communication system illustrated in FIG. 1A, according to an embodiment;

in fig. 1C is a system diagram illustrating an example of a radio access network (RAN) and an example of a core network (CN) that may be used in the communication system illustrated in FIG. 1A, according to an embodiment;

in fig. 1D is a system diagram illustrating a further example of a RAN and a further example of a CN that may be used in the communication system illustrated in FIG. 1A, according to an embodiment;

in fig. 2A is a flow chart illustrating a method in accordance with an embodiment of the present application;

in fig. 2B is a flow chart illustrating a method in accordance with another embodiment of the present application;

in fig. 3 shows an example construction of a downlink (DL) broadcast element;

in fig. 4 shows an example structure of an uplink broadcast (UL) element;

in fig. 5 shows an example of interframe low density parity check (LDPC) coding with incrementally increasing increments;

in fig. 6 shows an example of non-sequential incremental LDPC coding;

in fig. 7 shows an example of binary convolutional code (BCC) interframe coding;

in fig. 8 shows an example of interframe coding/partial hybrid automatic repeat request (HARQ) with fixed indices;

in fig. 9 shows an example of interframe coding/partial HARQ with a sliding window;

in fig. 10 shows an example of interframe coding/partial HARQ with feedback and dynamic incremental subframe selection;

in fig. 11 shows an example of a frame spaced power saving (xIFS) procedure between broadcast service (BCS) repetitions;

in fig. 12 shows an example of a power save procedure with specific time differences between repetitions;

in fig. 13 shows an example of a closed loop transmission repetition;

in fig. 14 shows an example of a multi-AP broadcast with CSD cyclic shift diversity;

in fig. 15 shows an example of a multi-AP time division broadcast;

in fig. 16 shows an example of a multi-AP broadcast transmission with a transmission spatial diversity scheme;

in fig. 17 shows an example of a network architecture in which a UL WTRU (eg, a station (STA)) has no receiver status information;

in fig. 18 shows an example procedure for an AP to provide downlink (DL) feedback; and

in fig. 19 shows an example procedure for an AP to provide downlink (DL) feedback identifying a piece of lost data.

Detailed description

In FIG. 1A is a diagram illustrating an example of a communications system 100 in which one or more of the described embodiments may be implemented. Communication system 100 may be a multiple access system from which multiple wireless users receive content such as voice, data, video, messaging, broadcast, and the like. Communication system 100 may be configured to provide multiple wireless users with access to such content by sharing system resources, including wireless connection bandwidth. For example, communication systems 100 may use one or more channel access techniques such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), Orthogonal Frequency Division Multiplexing (OFDMA), Single Carrier FDMA (SC-FDMA), Extended OFDM with Non-Redundant Discrete Fourier Transform Extension with Sync Burst (ZT-UW-DFT-S-OFDM), Sync Burst OFDM (UW-OFDM), OFDM resource block filtering, multi-carrier filter block (FBMC), and the like.

As shown in FIG. 1A, communication system 100 may include wireless transmit/receive (WTRU) modules 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, a network 110 the Internet and other networks 112, although it should be understood that the described embodiments involve any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device capable of operating and/or interoperating in a wireless communication environment. For example, WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive radio signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber module, subscriber unit, pager, cell phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, Mi-Fi hotspot or device, Internet of Things (IoT) device, watch, or other wearable device head-mounted display (HMD), vehicle, radio controlled unmanned aerial vehicle, medical device and applications (e.g. those used in remote surgery), industrial device and applications (e.g. robotic and/or other wireless devices operating in industrial and / or automated process chain), device related to consumer electronics, set a device operating in a commercial and/or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE. It should be noted that in this application, the terms "WTRU" and "STA" can be used interchangeably, unless otherwise indicated.

Communication systems 100 may also include base station 114a and/or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly communicate with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110 and/or other networks 112. As an example, base stations 114a, 114b may be a base transceiver station (BTS), NodeB, eNode B (eNB), Home Node B, Home eNode B, next generation NodeB such as gNode B (gNB), a new radio network (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. Although each of the base stations 114a, 114b is shown as a separate element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service in a particular geographic area, which may be relatively fixed or which may change over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i. one for each sector of the cell. In an embodiment, base station 114a may use multiple input multiple output (MIMO) technology and may employ multiple transceivers for each cell sector. For example, beamforming can be used to transmit and/or receive signals in the desired spatial directions.

Base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication system (e.g., for signaling in the radio frequency (RF), microwave spectrum, spectrum centimeter wave, micrometer wave spectrum, infrared (IR), ultraviolet (UV) spectrum, visible light spectrum, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

More specifically, as noted above, communication system 100 may be a multiple access system and may use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a in RAN 104 and WTRUs 102a, 102b, 102c may implement a radio technology such as a terrestrial radio access (UTRA) network for a universal mobile communications system (UMTS) in which a radio interface 116 using wideband CDMA may be established. (WCDMA). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Enhanced HSPA (HSPA+). The HSPA protocol may include High Speed Downlink (DL) Packet Access (HSDPA) and/or High Speed Uplink (UL) Packet Access (HSUPA).

In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as UMTS Evolved Terrestrial Radio Access (E-UTRA), which may establish a radio interface 116 using a Long Term Evolution (LTE) standard, and /or LTE-Advanced (LTE-A), and/or LTE-Advanced Pro (LTE-A Pro).

In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as new radio access technology (NR) that may establish air interface 116 using NR.

In an embodiment, multiple radio access technologies may be implemented in base station 114a and WTRUs 102a, 102b, 102c. For example, base station 114a and WTRUs 102a, 102b, 102c can both implement LTE and NR radio access technologies, for example, using dual connectivity (DC) principles. Thus, the air interface used by WTRUs 102a, 102b, 102c may be characterized by the use of multiple types of radio access technologies and/or transmissions sent to/from base stations of multiple types (eg, eNBs and gNBs).

In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., broadband microwave access (WiMAX)) technology. , CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim 2000 (IS-2000), Interim 95 (IS-95), Interim 856 (IS-856), Global System for Mobile Communications (GSM), GSM evolution with increased data rate (EDGE), GSM EDGE (GERAN), etc.

Base station 114b shown in FIG. 1A may be, for example, a wireless router, Home Node B, Home eNode B, or access point, and any suitable RAT may be used to facilitate wireless communication in a localized area such as a business, residential, vehicle, educational institution, industrial facility, air corridor (for example, for use by RC unmanned aerial vehicles), roadway, etc. In one embodiment, a radio technology such as IEEE 802.11 may be implemented in base station 114b and WTRU 102c, 102d to create a wireless local area network (WLAN). In an embodiment, a radio technology such as IEEE 802.15 may be implemented in base station 114b and WTRU 102c, 102d to create a wireless personal area network (WPAN). In yet another embodiment, cell-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) can be used in base station 114b and WTRUs 102c, 102d to create a pico cell. or femtocells. As shown in FIG. 1A, base station 114b may have a direct connection to Internet 110. Thus, base station 114b may not need to access Internet 110 via CN 106.

RAN 104 may communicate with CN 106, which may be any type of network configured to provide voice, data, applications, and/or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different performance requirements, latency requirements, fault tolerance requirements, reliability requirements, data rate requirements, mobility requirements, and the like. In the CN 106, call control, billing services, location-based mobile communication services, prepaid calls, Internet connectivity, video distribution, and the like can be provided. and/or implemented high-level security features such as user authentication. Although in FIG. 1A is not shown, it should be understood that RAN 104 and/or CN 106 may directly or indirectly communicate with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to communicating with RAN 104, which may use NR radio technology, CN 106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. .

CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, 102d to provide access to PSTN 108, Internet 110, and/or other networks 112. PSTN 108 may include circuit switched telephone networks that provide traditional telephone service (POTS). Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/Internet protocol suite. IP. Networks 112 may include wired and/or wireless communications networks that are owned and/or operated by other service providers. For example, networks 112 may include another CN connected to one or more RANs that may use the same RAT as RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links ). For example, WTRU 102c shown in FIG. 1A may be configured to communicate with base station 114a, which may use cell-based radio technology, as well as with base station 114b, which may use IEEE 802 radio technology.

In FIG. 1B is a system diagram illustrating an example of WTRU 102. As shown in FIG. 1B, WTRU 102 may include, but is not limited to, processor 118, transceiver 120, transmitter/receiver 122, speaker/microphone 124, keyboard 126, display/touchpad 128, non-removable storage 130, removable storage 132, source 134 power supply, global positioning system (GPS) chipset 136, and/or other peripheral devices 138. It should be understood that WTRU 102 may include any subcombination of the above elements and still conform to the embodiment.

Processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, application specific integrated circuits (ASICs), gate programmable matrix (FPGA), integrated circuit (IC) of any other type, state machine, etc. Processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality required by WTRU 102 to operate in a wireless communications environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitter/receiver element 122. Although FIG. 1B, processor 118 and transceiver 120 are shown as separate components, it should be understood that processor 118 and transceiver 120 may be integrated into an electronic unit or chip.

Transmitting/receiving element 122 may be configured to transmit signals to or receive signals from a base station (eg, base station 114a) over air interface 116. For example, in one embodiment, transmitting/receiving element 122 may be an antenna configured to transmitting and/or receiving RF signals. In an embodiment, transmitter/receiver element 122 may be an emitter/detector capable of transmitting and/or receiving signals in the IR, UV, or visible light spectrum, for example. In yet another embodiment, transmitter/receiver element 122 may be configured to transmit and/or receive signals in both the RF spectrum and the visible light spectrum. It should be understood that the transmitting/receiving element 122 may be configured to transmit and/or receive any combination of radio signals.

Although in FIG. 1B, transmitter/receiver element 122 is shown as a single element, WTRU 102 may include any number of transmitter/receiver elements 122. More specifically, MIMO technology may be used in WTRU 102. Thus, in one embodiment, WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals over air interface 116.

Transceiver 120 may be configured to modulate signals transmitted by transmitter/receiver element 122 as well as demodulate signals received via transmitter/receiver element 122. As noted above, WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include a plurality of transceivers by which the WTRU 102 is enabled to interact via a plurality of RATs, such as NR and IEEE 802.11, for example.

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keyboard 126, and/or a display/touch panel 128 (eg, a liquid crystal display (LCD) or an organic light emitting diode (OLED) display) and may receive user input from them. Processor 118 may also output user data to speaker/microphone 124, keyboard 126, and/or display/touchpad 128. In addition, processor 118 may access information from any type of suitable storage device, such as non-removable storage device 130 and/or removable storage device 132 and store data thereon. The non-removable storage device 130 may include random access memory (RAM), read only memory (ROM), a hard drive, or any other type of storage device. The removable storage device 132 may include a subscriber identity module (SIM) card, a memory card, a secure digital memory (SD) card, and the like. In other embodiments, the processor 118 may access and store information from a storage device that is not physically located in the WTRU 102 but, for example, on a server or home computer (not shown).

Processor 118 may receive power from power supply 134 and may be configured to manage power and/or distribute power to other components in WTRU 102. Power supply 134 may be any suitable device for supplying power to WTRU 102. For example, power supply 134 may include one or more dry batteries (e.g. nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (eg, longitude and latitude) relative to the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive information position over the air interface 116 from a base station (eg, from base stations 114a, 114b) and/or determine its location based on the timing of signals received from two or more adjacent base stations. It should be understood that the WTRU 102 may acquire location information by any suitable location method and still comply with the embodiment.

Processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless communication capabilities. For example, peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a wireless headset, a Bluetooth® module, frequency modulation (FM) radio, digital music player, multimedia player, video game player, Internet browser, virtual reality and/or augmented reality (VR/AR) device, activity tracker, etc. Peripheral devices 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a Hall sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; geolocation sensor, altimeter, ambient light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

The WTRU 102 may include a full duplex radio in which transmission and reception of some or all of the signals (eg, associated with specific subframes for both UL (eg, transmit) and DL (eg, receive)) can be co-located and /or at the same time. A full duplex radio may include an interference control unit to reduce and/or substantially eliminate its own interference using either hardware (e.g., a choke) or signal processing by a processor (e.g., a separate processor (not shown) or processor 118) . In an embodiment, the WTRU 102 may include a half-duplex radio for transmitting and receiving some or all of the signals (eg, associated with specific subframes for both UL (eg, transmit) and DL (eg, receive)).

In FIG. 1C is a system diagram illustrating RAN 104 and CN 106 in accordance with an embodiment. As noted above, RAN 104 may use E-UTRA radio technology to communicate with WTRUs 102a, 102b, 102c over air interface 116. RAN 104 may also communicate with CN 106.

RAN 104 may include eNode-Bs 160a, 160b, 160c, although it should be understood that RAN 104 may include any number of eNode-Bs and still conform to the embodiment. Each eNode-B 160a, 160b, 160c may include one or more transceivers for communicating with WTRU 102a, 102b, 102c over air interface 116. In one embodiment, MIMO technology may be implemented in eNode B 160a, 160b, 160c. Thus, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and/or receive radio signals from WTRU 102a.

Each eNode-B 160a, 160b, 160c may be associated with a specific cell (not shown) and may be configured to make radio resource management decisions, handover decisions, UL and/or DL user scheduling, and the like. As shown in FIG. 1C, eNode-Bs 160a, 160b, 160c can communicate with each other via the X2 interface.

CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway 166 (PGW). While the above elements are shown as part of CN 106, it should be understood that any of these elements may be owned by and/or controlled by an entity other than the CN operator.

The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via the S1 interface and may act as a control node. For example, MME 162 may be responsible for user authentication of WTRUs 102a, 102b, 102c, channel activation/deactivation, selection of a specific serving gateway during initial connection of WTRUs 102a, 102b, 102c, and the like. MME 162 may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies such as GSM and/or WCDMA.

SGW 164 may be connected to each eNode B 160a, 160b, 160c in RAN 104 over an S1 interface. SGW 164 may essentially direct and forward user data packets to and from WTRUs 102a, 102b, 102c. SGW 164 may perform other functions such as user plane binding during handover between eNode Bs, starting paging when DL data is available to WTRUs 102a, 102b, 102c, managing and storing the context of WTRUs 102a, 102b, 102c, etc. .

SGW 164 may be connected to PGW 166, which may provide WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communication between WTRUs 102a, 102b, 102c and IP enabled devices.

CN 106 may facilitate data exchange with other networks. For example, CN 106 may provide WTRUs 102a, 102b, 102c access to circuit switched networks such as PSTN 108 to facilitate data exchange between WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 may include an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108 or may communicate with it. In addition, CN 106 may provide WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

Although the WTRU is described in FIG. 1A-1D as a wireless terminal, it is contemplated that, in certain exemplary embodiments, a (eg, temporarily or permanently) wired interface to a communications network may be used with such a terminal.

In exemplary embodiments, the other network 112 may be a WLAN.

A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may access or interface with a Distribution System (DS) or communicate over another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic at the STA originating from outside the BSS may arrive via the AP and may be delivered to the STAs. Traffic originating from STAs to recipients outside the BSS may be sent to the AP for delivery to the appropriate recipients. Traffic between STAs within a BSS can be sent via an AP, for example, if a source STA can send traffic to an AP and an AP can deliver traffic to a destination STA. Traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transferred between (eg, directly between) a source STA and a sink STA in a forward link (DLS) setup. In certain exemplary embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs (eg, each STA) within or using IBSS may communicate directly with each other. In this document, the IBSS mode may sometimes be referred to as the "dynamic" communication mode.

When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may have a fixed width (eg, 20 MHz bandwidth) or a dynamically set width. The primary channel may be a working channel of the BSS and may be used by multiple STAs to establish a connection with the AP. In certain exemplary embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, such as in 802.11 systems. STAs (eg, each STA), including the AP, can discover the primary channel for CSMA/CA. Upon recognizing/detecting and/or determining whether a particular STA's primary channel is busy, that particular STA may turn off. One STA (eg, only one station) can transmit at any given time in a given BSS.

For high throughput (HT) STA communications, a 40 MHz channel can be used, for example by combining a 20 MHz primary channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz channel.

Very High Throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and/or 160 MHz channels. The 40 MHz and/or 80 MHz channels may be formed by combining continuous 20 MHz channels. A 160 MHz channel can be formed by combining 8 continuous 20 MHz channels, or by combining two non-continuous 80 MHz channels, which may be referred to as an 80+80 configuration. two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operation for the 80 + 80 configuration may be inverted, and the combined data may be sent to a media access control (MAC) device.

The 802.11af and 802.11ah protocols support operating modes up to 1 GHz. In 802.11af and 802.11ah, the channel bandwidths and carriers are reduced from those used in 802.11n and 802.11ac. The 802.11af protocol supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the unused portion of the television frequency spectrum (TVWS), while the 802.11ah protocol supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths with using spectrum other than TVWS. According to an exemplary embodiment, 802.11ah can support metered control/machine-to-machine communications (MTC), such as machine-to-machine communications (MTC) devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including support (eg, support only) certain and/or limited bandwidths. The MTC devices may include a battery having a battery life exceeding a threshold value (eg, to provide a very long battery life).

WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the largest total operating bandwidth supported by all STAs in the BSS. The primary channel bandwidth may be set and/or limited by the STA of all STAs operating in the BSS that supports the lowest bandwidth mode of operation. In the 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) 1 MHz mode, even if the APs and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz , 16 MHz and/or modes of operation with other channel bandwidths. The carrier detection and/or network allocation vector (NAV) parameters may depend on the state of the primary link. If the primary channel is busy, for example, due to a STA (which only supports a 1 MHz mode of operation) transmitting to an AP, all available bands may be considered busy even if most of the available bands remain unoccupied.

In the United States of America, the available frequency bands that can be used by 802.11ah range from 902 MHz to 928 MHz. The available frequency bands in Korea are from 917.5 MHz to 923.5 MHz. The available frequency bands in Japan are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is between 6 MHz and 26 MHz depending on the country code.

In FIG. 1D is a system diagram illustrating RAN 104 and CN 106 in accordance with an embodiment. As noted above, RAN 104 may use NR radio technology to communicate with WTRUs 102a, 102b, 102c over air interface 116. RAN 104 may also communicate with CN 106.

RAN 104 may include gNBs 180a, 180b, 180c, although it should be understood that RAN 104 may include any number of gNBs and still comply with the embodiment. Each gNB 180a, 180b, 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c over air interface 116. In one embodiment, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may use beamforming to transmit signals to and/or receive signals from gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, can use multiple antennas to transmit radio signals to and/or receive radio signals from WTRU 102a. In an embodiment, carrier aggregation technology may be implemented on gNBs 180a, 180b, 180c. For example, gNB 180a may transmit multiple carrier components (not shown) to WTRU 102a. A subset of these carriers may be in unlicensed spectrum, while the remaining carriers may be in licensed spectrum. In an embodiment, coordinated multipoint (CoMP) technology may be implemented on gNBs 180a, 180b, 180c. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using scaled-value transmissions. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may differ for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable duration (eg, containing varying numbers of OFDM symbols and/or having constant different absolute time durations).

gNBs 180a, 180b, 180c may be configured to communicate with WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In a standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without concurrent access to other RANs (eg, such as eNode-Bs 160a, 160b, 160c). In a standalone configuration, WTRUs 102a, 102b, 102c may use one or more gNBs 180a, 180b, 180c as a mobility anchor. In a standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using unlicensed band signals. In a non-autonomous configuration, WTRUs 102a, 102b, 102c can communicate/connect with gNBs 180a, 180b, 180c and simultaneously communicate/connect with another RAN such as eNode-B 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement dual connection (DC) principles for substantially simultaneous communication with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, 160c may act as a mobility anchor point for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c may provide additional coverage and/or capacity to serve WTRUs 102a, 102b, 102c .

Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to make radio resource control decisions, handover decisions, user scheduling in the UL and/or DL, network segmentation support, DCs, interaction between NR and E-UTRA, routing user plane data to a user plane functional block (UPF) 184a, 184b, routing control plane information to an access and mobility management function (AMF) 182a, 182b, and the like. As shown in FIG. 1D, gNB 180a, 180b, 180c can communicate with each other over the Xn interface.

CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly a data communication network (DN ). While the above elements are shown as part of CN 106, it should be understood that any of these elements may be owned by and/or controlled by an entity other than the CN operator.

AMFs 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in RAN 104 over the N2 interface and may act as a control node. For example, AMFs 182a, 182b may be responsible for authenticating users of WTRUs 102a, 102b, 102c, maintaining network segmentation (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration area, terminating Non-Access Layer (NAS) signaling, mobility management, and the like. Network segmentation may be used in AMFs 182a, 182b to configure CN support for WTRUs 102a, 102b, 102c based on the types of services used by WTRUs 102a, 102b, 102c. For example, different network segments may be set up for different use cases, such as services based on access to high reliability low latency communications (URLLC), services based on access to advanced mobile broadband (eMBB), services to access MTC etc. AMF 182a, 182b may provide a control plane function for switching between RAN 104 and other RANs (not shown) that use other radio technologies such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies. such as WiFi.

SMF 183a, 183b can be connected to AMF 182a, 182b in CN 106 via N11 interface. SMF 183a, 183b can also be connected to UPF 184a, 184b in CN 106 via N4 interface. SMFs 183a, 183b can select and manage UPFs 184a, 184b, and configure traffic routing with UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as UE IP address management and allocation, PDU session management, policy enforcement and QoS management, provision of DL data notifications, and the like. The session type of the PDU may be IP based, non-IP based, Ethernet based, and so on.

UPFs 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in RAN 104 over an N3 interface, which may provide WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate data exchange. between WTRUs 102a, 102b, 102c and IP devices. The UPFs 184, 184b may perform other functions such as packet routing and forwarding, user plane policing, support for multilink PDU sessions, user plane QoS processing, DL packet buffering, mobility binding, and the like.

CN 106 may facilitate data exchange with other networks. For example, CN 106 may include an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108 or may communicate with it. In addition, CN 106 may provide WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, WTRUs 102a, 102b, 102c can be connected to local DN 185a, 185b by UPF 184a, 184b over N3 interface to UPF 184a, 184b and N6 interface between UPF 184a, 184b and DN 185a, 185b.

Taking into account FIG. 1A-1D and the corresponding descriptions of FIG. 1A-1D, one or more or all of the functions described herein in connection with one or more of: WTRU 102a-d, base stations 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a–c, AMF 182a–b, UPF 184a–b, SMF 183a–b, DN 185a–b and/or any other device(s) described herein , may be implemented by one or more emulation devices (not shown). Emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and/or to simulate network and/or WTRU functions.

Emulation devices may be configured to implement one or more tests of other devices in a lab environment and/or in an operator's network environment. For example, one or more emulation devices may perform one or more functions, or all of the functions, while they are fully or partially implemented and / or deployed as part of a wired and / or wireless communication network, to test other devices in the communication network. One or more emulation devices may perform one or more functions, or all functions, while they are temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly connected to another device for testing purposes and/or performing tests using wireless radio.

One or more emulation devices may perform one or more functions, including all functions, and yet not be implemented/deployed as part of a wired and/or wireless communication network. For example, emulation devices can be used in a test lab scenario and/or in a non-deployed (eg, test) wired and/or wireless communications network to test one or more components. One or more emulation devices may be test equipment. The emulation devices may use a direct RF connection and/or wireless communications via an RF circuit (which may, for example, include one or more antennas) to transmit and/or receive data.

The IEEE 802.11 High Performance WLAN (HEW) Study Group (SG) was formed to study the scope and purpose of a possible future change to improve the quality of service of all users for a wide range of wireless network users in many use cases, including high-density scenarios in Band 2 .4 GHz, 5 GHz and 6 GHz. The HEW SG is currently considering new use cases that support AP and STA dense deployment modes and related Radio Resource Management (RRM) technologies. Potential applications of HEW include new use cases such as data delivery for stadium events, high-density scenarios such as train stations, corporate/retail environments, and evidence of increased reliance on video delivery and wireless communications in medical institutions. The IEEE Standards Council approved the IEEE 802.11ax Working Group (TG) based on the findings of the HEW SG.

In some presentations at the TGax standard meetings, it was reported that the measured traffic for various applications is more possible in short packets and that there are network applications that can also generate short packets. These applications include: virtual office; TPC confirmation; confirmation of video stream transmission; devices/controllers (eg mice, keyboards, gamepads, etc.); access (eg trial request/response); network selection (eg, probe requests, Network Access Request Protocol (ANQP)); and/or network management/control frames. Many reports on 802.11ax have proposed the implementation of multi-user features (MUs), including uplink (UL) and downlink (DL) OFDMA, as well as UL and DL MU-MIMO. In 802.11ax and other protocols, the design and definition of a UL random access multiplexing mechanism may be used for various purposes.

TGax's proposals for 6 GHz media access issues include using initiated or scheduled media access in the 6 GHz band only and/or limiting Enhanced Distributed Channel Access (EDCA) active scanning and scheduling as media access data in the 6 GHz band.

The IEEE 802.11ba TG was created to define changes to the physical layer (PHY) and media access control (MAC) aimed at improving the low power performance of 802.11 devices. MAC and PHY changes may encourage the use of wake-up radios (WURs). Expected WUR operating bands include 2.4 GHz, 5 GHz and may be extended to the 1 GHz subband. The WUR can function as a primary radio accessory (PCR) used to transmit normal 802.11 packets. The PCR may also be referred to as the main radio. The WUR may transmit packets containing (only) control information and the active receiver power consumption may be less than one milliwatt. Receiving a WUR wake-up packet may cause the Master Radio (PCR) to wake up from sleep mode. In one example, the WUR may have a range at least equal to that of a primary radio device operating in a payload range of at least 20 MHz.

STAs with and without APs may contain a WUR as an optional radio. Examples of WUR use cases include: Internet of Physical Object (IoT) devices; low power consumption for smartphones; quick message/incoming call notification script; quick status query/report, configuration change script; and/or an accident/critical event quick report script.

The IEEE 802.11bc TG was created to define MAC changes for the Evolved Broadcast Service (eBCS) for 802.11 devices. The IEEE 802.11bc change shall not affect the IEEE 802.11 PHY specifications. An eBCS service may exist in the DL direction from an AP to a STA without an AP, or may exist in a UL direction from a sensor STA without an AP. eBCS may be provided to STAs that are associated or not associated with a particular AP. An AP can be expected to support up to 3000 STAs without an AP with eBCS service. In addition, there may be a class of low-cost STAs without APs that receive eBCS service and may not be able to transmit data directly to the AP. Examples of eBCS use cases may include: video feed from the stadium; car broadcasting; broadcasting data from uplink sensors; museum information and multilingual broadcasting; and/or broadcasting information and content from event sources.

In intra-frame coding for broadcast or other channels, the content of a transmitted frame can be derived from a single set of encoded bits. In interframe coding, the content of a transmitted frame may be derived from a plurality of sets of encoded bits that are normally transmitted in separate frames but generated (eg, using incremental linear coding) to form new subframes that may be transmitted to assist decoding. This allows the broadcast signal to be transmitted to all received WTRUs (STAs) with enhanced reliability with a progressive form of rate matching to allow smooth code rate change. The encoder used is typically a rate compatible code such that for any two code rates R > R', with the frame rate R' being the concatenation of the frame rate R and additional redundancy bits.

For 802.11ba devices, WUR scanning is negotiated. When scanning a WUR, an AP may send WUR discovery frames containing information about itself and its BSS. WTRUs that support WURs can scan WUR discovery frames to discover suitable APs and BSSs for communication. However, MAC Layer Management Entity (MLME) primitives may need to be defined for the WTRU to initiate WUR scanning and/or pass the collected information about received WUR discovery frames to higher layers. Appropriate MLME primitives can be defined so that WTRUs can manage the WUR scanning process, as well as pass information about received WUR discovery frames collected during the WUR scanning process to a higher layer. It should be noted that the terms WUR scanning and WUR scanning process may be used interchangeably unless otherwise noted.

In order to solve the above problem, methods and WTRUs according to the present application will be described below.

A method 200 according to an embodiment of the present application will be described with reference to FIG. 2A below. In FIG. 2A shows a flow diagram of a method 200. As shown in FIG. 2A, method 200 may include: in step 201, generation by the station management entity (SME) of a request primitive providing a wake-up radio (WUR) scanning process for WUR discovery frames transmitted by one or more access points (APs), wherein the request primitive contains a plurality of first parameters ; at 202, performing a WUR scanning process based on a plurality of first parameters; at step 203, generating at least one confirmation primitive at the MAC layer based on the result of the WUR scanning process and at least a portion of the plurality of first parameters; and at 204, transmitting at least one acknowledge primitive from the MAC layer to the SME.

Accordingly, a WTRU according to an embodiment of the present application may comprise: a processor configured to generate a request primitive providing a wake-up radio unit (WRU) scanning process for WUR discovery frames transmitted by one or more access points (APs), wherein the request primitive comprises a set of first parameters; performing a WUR scanning process based on the plurality of first parameters; generating at the MAC level at least one confirmation primitive based on the result of the WUR scanning process and at least a portion of the plurality of first parameters; and transmitting at least one acknowledge primitive from the MAC layer to the SME.

The description below will describe the method in step 201 in detail.

The request primitive can be an MLME primitive that can be defined and used for WUR scanning. In one embodiment, the request primitive may be an MLME-WURSCAN.Request primitive. For example, a WUR scan may be initiated by an MLME primitive such as the MLME-WURSCAN.Request primitive. This MLME primitive may request polling of potential BSSs via WUR discovery frames that the WTRU may later choose to attempt a connection with. It should be noted that in this application, the terms "MLME-WURSCAN.Request primitive", "MLME-WURSCAN.Request" and "request primitive" may be used interchangeably unless otherwise indicated. These parameters in the request primitive (eg, the MLME-WURSCAN.Request primitive) will be described below with reference to detailed descriptions of the embodiments.

In another embodiment, the request primitive may be an MLME-SCAN.Request primitive or part of an MLME-SCAN.Request primitive. The parameters in the MLME-SCAN.Request primitive may be similar to the parameters in the MLME-WURSCAN.Request primitive, and the parameters in the MLME-SCAN.Request primitive will be further described below. In this application, the terms "MLME-SCAN.Request primitive", "MLME-SCAN.Request" and "request primitive" may be used interchangeably unless otherwise indicated. These parameters in the request primitive (eg, the MLME-WURSCAN.Request primitive) will be described below with reference to detailed descriptions of the embodiments.

In one embodiment, the request primitive may be generated by a station control entity (SME). For example, an MLME-WURSCAN.request primitive may be generated by the SME for the WTRU to determine, using its WUR or low power WUR mode, to scan WUR discovery frames to determine if there are other BSSs to join. In one embodiment, the request primitive may be generated by the processor.

The wake-up radio (WUR) scanning process for WUR discovery frames transmitted by one or more APs is a WTRU scanning process aimed at scanning and thus discovering suitable APs and BSSs for communication. WTRUs will scan and detect WUR discovery frames transmitted from the AP. The WUR discovery frame may contain various fields such as SSID, compressed SSID, compressed BSSID, channel information, and so on.

The request primitive can contain many first parameters. The set of first parameters may contain at least one of a Basic Service Set Identifier (BSSID), BSSIDList, a Service Set Identifier (SSID), SSIDList, CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MinDiscoveryChannelTime, MaxDiscoveryChannelTime, ReceivedPowerThreshod, MaxScanningTime, WURScanningReportingPeriodning (or WURScanningReportingTime), WURScanningMode, WURScanningReportingOption, or RequestWURresult. The following section will describe the above parameters in turn.

The BSSID may indicate the BSSID of the desired AP or the desired BSS. In one embodiment, the BSSID may identify basic service sets, which are 48-bit labels and conform to MAC-48 conventions. The BSSID may be a wildcard BSSID (eg, ff:ff:ff:ff:ff:ff). In one embodiment, there can be only one BSSID in a request primitive. In another embodiment, there may be a plurality of BSSIDs in the request primitive. One or more BSSIDs may be included in the BSSIDList. In other words, the BSSIDList may contain information about one or more BSSIDs. For example, BSSIDList may be a list containing a plurality of BSSIDs, each of which may indicate a desired BSS or AP. Although some examples of BSSID and BSSIDList have been described above, they are not meant to be exclusive or limiting to the present application. Any variant of the above embodiments of the BSSID and BSSIDList can also be applied in this method and WTRU according to the present application if they can help realize the principle of the present application.

The SSID may be the service set identifier of the desired AP, BSS, or SS. That is, the SSID may indicate a set of services to which the WTRU may need to connect. The SSID can be a wildcard SSID. In one embodiment, there can be only one SSID in a request primitive. In another embodiment, there may be a plurality of SSIDs in the request primitive. One or more SSIDs may be included in the SSIDList. In other words, the SSIDList may contain information about one or more SSIDs of the desired AP or BSS. For example, SSIDList may be a list containing a plurality of SSIDs, each of which may indicate a desired set of APs or BSSs. Although some examples of SSID and SSIDList have been described above, they are not meant to be exclusive or limiting to the present application. Any variant of the above embodiments of SSID and SSIDList can also be applied in this method and WTRU in accordance with the present application if they can help realize the principle of the present application.

The compressedBSSID may indicate the compressed BSSID of the desired AP or desired BSS with which the WTRU may wish to communicate. In one embodiment, the CompressedBSSID may be a partial BSSID. CompressedBSSID may be associated with a wildcard BSSID. The associated CompressedBSSID may be calculated based on the provided BSSIDs. In one embodiment, there can be only one CompressedBSSID in a request primitive. In another embodiment, there may be a plurality of CompressedBSSIDs in the request primitive. One or more CompressedBSSIDs may be included in the CompressedBSSIDList. In other words, the CompressedBSSIDList may contain one or more compressed BSSIDs of the desired AP or BSS. For example, CompressedBSSIDList may be a list containing a plurality of compressed BSSIDs, each of which may indicate a desired BSS or AP. Although some examples of CompressedBSSID and CompressedBSSIDList have been described above, they are not meant to be exclusive or limiting to the present application. Any variant of the above CompressedBSSID and CompressedBSSIDList embodiments can also be applied in this method and WTRU according to the present application if they can help realize the principle of the present application.

DiscoveryChannel may indicate a WUR channel or channel on which discovery frames (eg, WUR discovery frames) may be scanned during a WRU scan. In one embodiment, there can be only one DiscoveryChannel in a request primitive. That is, discovery frames may be scanned on the particular channel indicated by this DiscoveryChannel. In another embodiment, there may be a plurality of DiscoveryChannels in a request primitive. That is, discovery frames may be scanned on a plurality of channels indicated by these DiscoveryChannels. One or more DiscoveryChannels may be included in a DiscoveryChannelList. In other words, the DiscoveryChannelList may contain information about one or more DiscoveryChannels. For example, DiscoveryChannelList may be a list containing a plurality of DiscoveryChannels, each of which may indicate a WUR channel or channel on which discovery frames (eg, WUR discovery frames) may be scanned to discover desired APs or BSSs. If the MLME-WURSCAN.request primitive includes one or more WURDiscoveryChannel or WURDiscoveryChannelList, then the WTRU may tune only to those WUR discovery channels to scan WUR discovery frames. Although some examples of DiscoveryChannel and DiscoveryChannelList have been described above, they are not meant to be exclusive or limiting to the present application. Any variant of the aforementioned DiscoveryChannel and DiscoveryChannelList embodiments can also be applied in this method and WTRU according to the present application if they can help realize the principle of the present application. It should be noted that the terms "channel", "WUR channel", and "discovery channel" may be used interchangeably unless otherwise indicated.

MinDiscoveryChannelTime may indicate the minimum time, in units of time (TU) or other units, for the WTRU to perform a WUR scan on each of the channels indicated by one or more DiscoveryChannels in the DiscoveryChannelList. MinDiscoveryChannelTime may be determined based on the WUR discovery periods of the desired AP, BSS, or SS. The WUR detection periods may be predetermined or received over the air from one or more APs. Although MinDiscoveryChannelTime and its preferred embodiment have been described above, they are not meant to be exclusive or limiting to the present application. Any available value of MinDiscoveryChannelTime can also be applied in this method and WTRU in accordance with the present application, if it can help realize the principle of the present application.

MaxDiscoveryChannelTime may indicate the maximum time, in TUs or other units, for the WTRU to perform a WUR scan by the WTRU on each of the channels indicated by one or more DiscoveryChannels in the DiscoveryChannelList. MaxDiscoveryChannelTime may be determined based on the WUR discovery periods of the desired AP, BSS, or SS. The WUR detection periods may be predetermined or received over the air from one or more APs. Although MaxDiscoveryChannelTime and its preferred embodiments have been described above, they are not meant to be exclusive or limiting to the present application. Any available value of MaxDiscoveryChannelTime can also be applied in this method and WTRU in accordance with the present application, if it can help realize the principle of the present application.

ReceivedPowerThreshold may indicate a received power threshold above which discovery frame(s) (eg, WUR discovery frames) are processed. Thus, during a WUR scan, only discovery frame(s) whose received power(s) exceeds the ReceivedPowerThreshold value can be processed. Discovery frame(s) whose received power(s) is lower than the ReceivedPowerThreshold may be ignored during the WUR scan. In one embodiment, the ReceivedPowerThreshold may be determined by a receive channel power indicator (RCPI), received signal strength indicator (RSSI), signal to noise ratio (SNR), and/or signal to interference + noise ratio (SINR). Although ReceivedPowerThreshold and its preferred embodiments have been described above, they are not intended to be exclusive or limiting to the present application. Any available value of ReceivedPowerThreshold can also be applied in this method and WTRU in accordance with the present application, if it can help realize the principle of the present application.

MaxWURScanningTime may indicate the maximum time in TU or other units for the WTRU to perform the WUR scanning process. Although MaxWURScanningTime and its preferred embodiments have been described above, they are not meant to be exclusive or limiting to the present application. Any available value of MaxWURScanningTime can also be applied in this method and WTRU in accordance with the present application, if it can help realize the principle of the present application.

WURScanningReportingPeriod (or WURScanningReportingTime) may indicate the time or period in which the results of the WUR scanning process may be provided (eg, using the MLME-WURScanning.confirm primitive). Although the WURScanningReportingPeriod and its preferred embodiments have been described above, they are not intended to be exclusive or limiting to the present application. Any available value of WURScanningReportingPeriod can also be applied in this method and WTRU in accordance with this application, if it can help realize the principle of this application.

WURScanningMode can specify the WUR scanning mode. For example, WURScanningMode values can be: "background", "simultaneous with normal scanning", "only WUR scanning", etc. In other words, the WUR scanning mode denoted by WURScanningMode can be "background", "simultaneous with normal scanning", "WUR scanning only", etc. The above WUR scanning mode will be further described below with reference to detailed embodiments. Although WURScanningMode and examples of its values have been described above, they are not meant to be exclusive or limiting to the present application. Any available value of WURScanningMode can also be applied in this method and WTRU in accordance with the present application, if it can help realize the principle of the present application.

The WURScanningReportingOption may indicate how the results of the WUR scanning process may be reported. That is, the ability to provide the results of the WUR scanning process can be specified by the WURScanningReportingOption. WURScanningReportingOption values can be: Immediate (immediately), Periodic (periodically), At Pre-determined Time (at a pre-determined time), Channel Specific (depending on the channel), At_Request (on request), At_End (at the end), etc. d. For example, if the WURScanningReportingOption is set to Periodic or "at At_Specified_Time, WURScanningReportingPeriod or WURScanningReportingTime as described above can be included in the same primitive (i.e. request primitive) to specify the time or frequency at which results can be transmitted or provided WUR scanning process. The above options for providing results of the WUR scanning process will be further described below with reference to detailed embodiments. While WURScanningReportingOption and examples of its values have been described above, they are not intended to be exclusive or limiting to this application. Any available value of WURScanningReportingOption can also be applied in this method and WTRU in accordance with this application, if it can help realize the principle of this application.

RequestResults may indicate that the current results of the WUR scan process are requested and should be provided by issuing a confirmation primitive (eg, an MLME-WURSCAN.confirm primitive).

So far, various first parameters have been described that can be included in a request primitive. It should be noted that the above first parameters are given by way of example only and are not intended to be exclusive or limiting to the present application. Any available parameters may be included in the request primitive if they can help implement the principle of the present application.

The following section will detail the method at 202. As described above, the method 200 may include: at 202, performing a WUR scanning process using the WUR based on a plurality of first parameters.

In one embodiment, as described above, after the SME or the processor generates a request primitive (eg, an MLME-WURSCAN.request primitive), the processor may direct the WTRU to initiate the WUR scanning process either immediately or after completion of the ongoing frame exchange sequence. The WTRU may then perform the WUR scanning process based on a plurality of first parameters in the request primitive.

Depending on the WURScanningMode parameter, for example if its value is "background", the WUR scanning process in accordance with the present application can be started as a background scan. In this case, the WTRU may perform other types of operations.

If the value of the WURScanningMode parameter is "WUR scan only", then the WUR scan process can only be initiated as a WUR scan. In this case, for example, the WTRU may turn off its primary radio and/or only perform a WUR scan in the low power WUR mode, during which time the WTRU may not perform any other operations.

If the value of the WURScanningMode parameter is "simultaneous with normal scanning", "simultaneous with passive scanning/active scanning", then the WUR scanning process can be executed as a parallel discovery process along with normal scanning, active scanning/passive scanning, which can be specified by the WURScanningMode parameter. For example, the WTRU may use its WUR to scan WUR acquisition frames in a low power WUR mode and perform passive or active scanning, such as using a PCR or a master radio.

As described above, various WUR scanning modes can be selected based on the WURScanningMode parameter. It should be noted that the WUR scan process may not be the only scan process performed by the WTRU in a given time period. That is, both a non-WUR scanning process (eg, an active scanning process, a passive scanning process, etc.) and a WUR scanning process can be performed by the WTRU at the same time.

In another embodiment, the request primitive may be an MLME-SCAN.Request primitive or part of an MLME-SCAN.Request primitive. In one example, the WUR scanning process may be initiated by an MLME-SCAN.request primitive, which may contain one or more WUR scan parameters. For example, any of the following parameters can be added to the MLME-SCAN.request primitive: BSSIDList, SSIDList, CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MinDiscoveryChannelTime, MaxDiscoveryChannelTime, MaxScanningTime, ReceivedPowerThreshold, WURScanningMode, WURScanningReportingOption, RequestWReportingOption These parameters may be as described herein, and the procedures for initiating a WUR scan may be similar to those described herein. The detailed description of these parameters may be similar to the description above with reference to the MLME-WURSCAN.request primitive. Therefore, a detailed description of these parameters will be omitted. The terms MLME-WURSCAN and MLME-SCAN may be used interchangeably (eg, in primitive names such as MLME-SCAN.request, MLME-SCAN.confirm, MLME-WURSCANSTOP.request, and/or MLME-WURSCANSTOP.confirm).

The following section of the description will describe the method in step 203. As described above, the method 200 may include: in step 203 generating at least one confirmation primitive based on the result of the WUR scanning process and at least part of the set of first parameters.

At least one confirmation primitive may comprise one or more MLME-WURSCAN.confirm primitives, one or more MLME-SCAN.confirm primitives, or a combination of MLME-WURSCAN.confirm primitive(s) and MLME-SCAN.confirm primitive(s). . For example, at least one confirmation primitive may contain one MLME-WURSCAN.confirm primitive and one MLME-SCAN.confirm primitive. In another example, at least one confirmation primitive may contain a plurality of MLME-WURSCAN.confirm primitives and no MLME-SCAN.confirm primitives. While some examples of at least one confirmation primitive have been described above, they are not intended to be exclusive or limiting to the present application. In some embodiments, the terms "MLME-SCAN.confirm primitive", "MLME-WURSCAN.confirm primitive", "confirmation primitive" may be used interchangeably.

At least one confirmation primitive may be generated based on both (1) the result of the process at step 202 and (2) part of the set of first parameters. That is, on the one hand, at least one confirmation primitive may be generated based on the result of the process at step 202, ie the result of the WUR scanning process. Alternatively, at least one confirmation primitive may be generated based on a portion of the set of first parameters. Part of the set of first parameters may contain at least one of WURScanningReportingOption, ReceivedPowerThreshold, CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, or a combination thereof. In the following part of the description, part of the set of first parameters used to define the confirmation primitive will be described in detail. In the following description, the confirmation primitive and the MLME-WURSCAN.confirm primitive may be used interchangeably unless otherwise noted.

In one embodiment, a portion of the set of first parameters may comprise a WURScanningReportingOption. That is, an MLME-WURSCAN.confirm primitive can be generated based on WURScanningReportingOption values. The WURScanningReportingOption can be used to determine when to generate the MLME-WURSCAN.confirm primitive. The following description will focus on the relationship between the MLME-WURSCAN.confirm primitive and the WURScanningReportingOption, that is, the order in which the MLME-WURSCAN.confirm primitive is generated based on the value of the WURScanningReportingOption parameter.

For example, if the value of WURScanningReportingOption is "immediately", then an MLME-WURSCAN.confirm primitive may be generated each time a WUR discovery frame is received or detected correctly.

If the value of WURScanningReportionOption is Channel_Specific, then an MLME-WURSCAN.confirm primitive may be generated after a particular WUR discovery channel has been scanned for WUR discovery frames, and may or may not have a matching Compressed SSID or Compressed BSSID, as specified in MLME_WURSCAN .request. In this case, the WUR discovery channel may be one or more of the WUR discovery channels specified in the MLME_WURSCAN.request.

If the value of WURScanningReportingOption is "on request", then an MLME-WURSCAN.confirm primitive may be generated if an MLME-WURSCAN.request was generated with a RequestResults parameter or with a RequestResults parameter set to 1 to provide the results of the current scan procedure WUR.

If the value of WURScanningReportingOption is "at the end", then the MLME-WURSCAN.confirm primitive may be issued at the end of the current WUR scan procedure after the WUR scan has been completed on one or more WUR discovery channels, which may be indicated in the MLME-WURSCAN primitive .request.

If the value of WURScanningReportionOption is "periodically" or "at a specified time", then the MLME-WURSCAN.confirm primitive may be generated in every period or at a specific time, which may be specified in the MLME-WURSCAN.request primitive.

In one embodiment, a portion of the set of first parameters may comprise at least one of SSID, SSIDList, BSSID, BSSIDList, CompressedSSID, CompressedSSDList, CompressedBSSID, or CompressedBSSIDList. That is, the MLME-WURSCAN.confirm primitive may be generated based on the values of at least one SSID, SSIDList, BSSID, BSSIDList, CompressedSSID, CompressedSSDList, CompressedBSSID, or CompressedBSSIDList parameter. The following description will focus on the relationship between the MLME-WURSCAN.confirm primitive and the aforementioned parameter(s), i.e., the order in which the MLME-WURSCAN.confirm primitive is generated based on the value(s) of the aforementioned at least one parameter.

For example, an MLME-WURSCAN.confirm primitive may be generated if a WUR discovery frame with a matching SSID, BSSID, compressed SSID, or compressed BSSID has been received. In another example, if one or more CompressedBSSID or CompressedSSID were provided in a request primitive (e.g., an MLME-WURSCAN.request primitive), then an MLME-WURSCAN.confirm primitive may be generated if a WUR discovery frame was received with a matching compressed SSID or a matching compressed BSSID. For example, if in a received WUR discovery frame, the transmitter ID contained in the ID field matches the 12 least significant bits (LSB) of the desired compressed BSSID, and the type-specific field contains the 12 MSBs of the desired compressed BSSID, then there may be a matching compressed BSSID. and an MLME-WURSCAN.confirm primitive may be generated. If the MLME-WURSCAN.request contains one or more of CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, then only BSSs with matching CompressedBSSID or CompressedSSID (or part of them) may be sent.

In one embodiment, a portion of the set of first parameters may comprise a ReceivedPowerThreshold parameter. That is, an MLME-WURSCAN.confirm primitive can be generated based on the ReceivedPowerThreshold value. For example, if an MLME-WURSCAN.request primitive contains a ReceivedPowerThreshold, then an MLME-WURSCAN.confirm primitive can only be generated for one or more BSSs whose WUR discovery frames were received by the WTRU with a received power greater than the specified ReceivedPowerThreshold. That is, if the received power of WUR discovery frames is greater than the specified ReceivedPowerThreshold value, then the MLME-WURSCAN.confirm primitive may transmit one or more BSSs transmitting WUR discovery frames.

The following description will focus on the contents of the confirmation primitive in accordance with the present application. A confirmation primitive (eg, the MLME-WURSCAN.confirm primitive) may be used to return the BSS descriptions discovered by the WUR scanning process (eg, by receiving one or more WUR discovery frames). In one embodiment, a plurality of MLME-WURSCAN.confirm primitives may be generated if the WURReportingOption value is Channel_Specific, At_Request, Periodic, or At_Specified_Time. In another embodiment, a single MLME-WURSCAN.confirm primitive may be generated.

In one embodiment, at least one confirmation primitive may be generated, and each of the at least one confirmation primitive may contain a plurality of second parameters. The set of second parameters may contain at least one of BSSDescriptionFromWURDFSet, ResultCode, ScannedWURDiscoveryChannelList, and VendorSpecificInfo. The BSSDescriptionFromWURDFSet parameter may be present if dot11WUROptionImplemented or dot11WURActivated is true. The following description will detail the aforementioned second parameters in the confirmation primitive.

In one embodiment, there may be one or more BSSDescriptionFromWURDFSet in the confirmation primitive. Each BSSDescriptionFromWURDFSet may consist of one or more parameters, such as the example parameters shown in Table 1.

Table 1. BSSDescriptionFromWURDFSet parameters

Name Type of Description Transmitter ID 12 bit identifier The transmitter ID is included in the WUR discovery frame ID field and may be the 12 LSB bits of the compressed BSSID. Partial compressed BSSID 24-bit partial compressed BSSID The partial compressed BSSID may consist of 12 LSBs of the compressed BSSID (may be included in the ID field of the received WUR discovery frame) and 12 MSBs of the compressed BSSID (may be included in the type-specific field of the received WUR discovery frame). 12 bits LSB compressed BSSID 12 bits LSB compressed BSSID The 12 LSBs of the compressed BSSID may consist of the 12 LSBs of the compressed BSSID (may be included in the ID field of the received WUR discovery frame) 12 MSB bits of the compressed BSSID 12 bits LSB compressed BSSID The 12 MSB bits of the compressed BSSID (may be included in a type-specific field of the received WUR discovery frame). Compressed SSID Full or partial compressed SSID Full or partial compressed SSID. For example, the 16 bits LSB or MSB of the compressed SSID, which may be obtained from the compressed SSID field of the received WUR discovery frame. Operating class Operation class field The operational class of the primary link of the AP transmitting the WUR discovery frame. Channel Channel field The working channel of an AP transmitting a WUR discovery frame and operating in normal (non-WUR) mode. Received power The received power of the WUR discovery frame. The received power of the WUR discovery frame, such as RCPI or RSSI.

ResultCode can be at least one of the following exemplary values: SUCCESS (success), INTERMEDIATE_SCAN_RESULT (intermediate scan result), NOT_SUPPORTED (not supported), PARTIAL_WURSCAN (partial WUR scan), PERIODIC_SCAN_RESULT (periodic scan result), REQUESTED_SCAN_RESULTS (results requested scan). In all of these example values, SCAN can be replaced with WURSCAN to clarify that the results are WUR scan results. The value of the ResultCode may depend on the reasons why the MLME-WURSCAN.confirm primitive was issued. The following description will detail the above ResultCode values given as an example.

SUCCESS can be used if the WUR scan process was successful. INTERMEDIATE_SCAN_RESULT may be used if the WURReportingOption parameter in the MLME-WURSCAN.request primitive is set to Channel_Specific or Immediate. The ResultCode value may be set to PARTIAL_SCAN if not all WUR discovery channels are being scanned. The ResultCode may be set to PERIODIC_SCAN_RESULT if the WURReportingOption parameter in the MLME-WURSCAN.request primitive is set to Periodic or At_Requested_Time. The ResultCode may be set to REQUESTED_SCAN_RESULTS if the WURReportingOption parameter on the MLME-WURSCAN.request primitive is set to At_Request and the MLME-WURSCAN.request primitive was received with a RequestWURResult.

It should be noted that the aforementioned exemplary ResultCode values are provided by way of example only and are not intended to be exclusive or limiting to the present application. Any available ResultCode values may be applied to the method and WTRU according to the present application if they can help implement the principles of the present application.

ScannedWURDiscoveryChannelList may contain a list of scanned WUR discovery channels.

In one embodiment, WUR SCAN results may be transmitted using an MLME-SCAN.confirm primitive or as part of an MLME-SCAN.confirm primitive. That is, the MLME-SCAN.confirm primitive can be used to return the BSS or AP set descriptions discovered by the WUR scanning process (eg, by receiving one or more WUR discovery frames). A plurality of MLME-SCAN.confirm primitives may be returned if the value of WURReportingOption is Channel_Specific, At_Request, Periodic, or At_Specified_Time. Otherwise, a single MLME-SCAN.confirm primitive may be issued. The MLME-SCAN.confirm primitive may include any of the following exemplary parameters: BSSDescriptionFromWURDFSet, ResultCode, ScannedWURDiscoveryChannelList, or VendorSpecificInfo. The exemplary parameters may be the same or similar to those described with reference to the MLME-WURSCAN.confirm primitive. Therefore, the detailed description of the exemplary parameters in the MLME-SCAN.confirm primitive will be omitted. In this application, the terms MLME-WURSCAN and MLME-SCAN can be used interchangeably unless otherwise indicated. Accordingly, unless otherwise noted, the terms MLME-SCAN.request and MLME-WURSCAN.request may be used interchangeably; the terms MLME-SCAN.confirm and MLME-WURSCAN.confirm may be used interchangeably; the terms "MLME-WURSCAN-STOP.Request", "MLME-WURSCAN-STOP.Request primitive", "MLME-SCAN-STOP.Request", "MLME-SCAN-STOP.Request primitive", and "stop request primitive" may be used interchangeably; and the terms "MLME-WURSCAN-STOP.confirm", "MLME-WURSCAN-STOP.confirm primitive", "MLME-SCAN-STOP.confirm", "MLME-SCAN-STOP.confirm primitive", and "Stop confirmation primitive" may be used interchangeably.

After the process at step 203, the method 200 will proceed to the process at step 204, i. e. transmission from the MAC layer to the SME of at least one acknowledgment primitive.

Methods and WTRUs according to the second embodiment of the present application will be described below with reference to FIG. 2b. As shown in FIG. 2B, the processes of steps 201 to 204 are similar to those described above with reference to FIG. 2b. The difference between the first embodiment and the second embodiment is that the method 200 shown in FIG. 2B includes the processes of steps 205 to 207. More specifically, method 200 further includes: at step 205, detecting whether a stop request primitive has been generated to stop the WUR scanning process, provided that a stop request primitive has been generated, method 200 further includes: at step 206 stopping the WUR scanning process; and at step 207 generating a stop confirmation primitive. The stop primitive may be generated before the first acknowledge primitive is generated.

The following description will focus on the processes at steps 205 and 207. In one embodiment, the stop request primitive may be an MLME-WURSCAN-STOP.request primitive, which may terminate any ongoing WUR scan process. For example, regardless of which scan mode the WTRU performs the WUR scanning process based on the WURScanningMode parameter, the MLME-WURSCAN-STOP.request primitive can end such a WUR scanning process. The SME may issue an MLME-WURSCAN-STOP.request primitive to stop all ongoing WUR scans performed by the WTRU.

In another embodiment, the stop request primitive may be a WUR-SCAN-STOP.request primitive or part of a WUR-SCAN-STOP.request primitive. The WUR-SCAN-STOP.request primitive can be used to terminate any ongoing WUR scan process. The WUR-SCAN-STOP.request primitive may include one or more parameters such as ScanType. As described above, multiple scan processes (eg, both a WUR scan process and a non-WUR scan process) may be performed by the WTRU at the same time. The ScanType parameter may indicate the type(s) of scan(s) the primitive may complete. The ScanType parameter can be any of the following values: WUR_Scan (WUR scan), Non-WUR_Scan (non-WUR scan), and All_Scan (all scans). If ScanType is set to WUR_Scan, all ongoing WUR scans can be terminated. If ScanType is set to Non_WUR_Scan, then non-WUR scan processes can be completed, including the passive scan process and the active scan process. If ScanType is set to All_Scan, all ongoing scans, including WUR and non-WUR scans (such as active scans and passive scans), can be completed.

If a stop request primitive has been generated, then at step 206 the corresponding scan process(es) may be completed based on the stop request primitive. That is, if the WTRU or its processor receives a stop request primitive, then the corresponding scan process(es) identified by the stop request primitive(s) may(s) be completed.

The description below will detail the method at 207. As described above, the method 200 may include: at 207, generating a stop confirmation primitive.

In a first embodiment, the stop confirmation primitive may be an MLME-WURSCAN-STOP.confirm primitive, which may be used to indicate the successful completion of the scan process(es), such as the WUR scan process(es) and/or the (s) non-WUR scans. In a second embodiment, the stop confirmation primitive may be an MLME-Scan-Stop.confirm primitive or part of an MLME-Scan-Stop.confirm primitive. The MLME-Scan-Stop.confirm primitive can be used similarly to MLME-WURSCAN-STOP.Confirm. In a third embodiment, the stop confirmation primitive may be the MLME-WURSCAN.confirm primitive or the MLME-SCAN.confirm primitive described above. That is, the MLME-WURSCAN.confirm primitive or the MLME-SCAN.confirm primitive can be used for the same purpose as MLME-WURSCAN-STOP.confirm.

The following description will be devoted to the support of the eBCS service in accordance with the present application.

There is a need to support a broadcast service for non-associated WTRUs. In addition, in the current WLAN standards, there is a need for a broadcast service for the uplink. For non-associated WTRUs, or for WTRUs that are receive-only and cannot transmit, designs are needed to support the downlink broadcast service. In addition, schemes are needed for uplink broadcast by the WTRU to one or more APs. In order to support the WTRU regardless of the association status of the WTRU and to support the uplink broadcast service by the WTRU without APs, broadcast and signaling service protocols may be developed for one or more APs.

This document describes the mechanisms for supporting the broadcast service in accordance with the present application. A WTRU (eg, an AP or STA without an AP) that has dot11eBCSImplemented and/or dot11eBCSActivized may include an eBCS element in its beacon or in the probe request/response frames and association request/response (re)frames that the WTRU transmits. In one example, an eBCS element may be included in uplink (UL) and/or downlink (DL) broadcast information. In another example, the UL eBCS element may be included in the UL broadcast information and/or the DL eBCS element may be included in the DL broadcast information. It should be noted that in this application, unless otherwise indicated, the terms "DL Broadcast Element", "DL eBCS Element", and "DL Broadcast Capability Element" may be used interchangeably.

An exemplary construction of a DL broadcast element or a DL eBCS element is shown in FIG. 3. The DL broadcast element may contain one or more of the following exemplary fields: element identifier; length; element identifier extension; and/or DL broadcast capabilities, including the N fields of the eBCS. The combination of the element identifier and the element identifier extension may identify the current element as a DL broadcast element or a DL eBCS element. The length field may indicate the length of the DL broadcast element.

DL broadcast capabilities may include N fields (ie, eBCS 1 to eBCS N), so that each field may be used to indicate a particular broadcast service that is provided by the transmitting WTRU (eg, transmitting AP). Each eBCS field may contain one or more of the following exemplary subfields: Broadcast Service Identifier, eBCS Type, Required Association, Required UL Transmission, Broadcast Rate, Broadcast Frequency, Broadcast Coding, Broadcast Control, Broadcast Parameters and/or broadcast status. The above subfields will be further described below.

The Broadcast Service Identifier subfield may indicate a broadcast service identifier. The "eBCS type" subfield may include the type of broadcast service (eg, whether the eBCS is UL or DL, or whether the broadcast service is categorized as automotive, directional, emergency, ancillary, informational, and/or event support). In one example, a bitmap may be included in the DL broadcast element to indicate what types of broadcast services are provided by the transmitting WTRU(s). The type may also be multi-AP broadcast. In another example, the type of broadcast may be identified by an organizationally unique identifier (OUI). The Association Required subfield may indicate whether an association is required to use one or more broadcast services (eg, the broadcast service identified by the broadcast service identifier).

The "UL transmission required" subfield may indicate whether a UL transmission is required to use one or more broadcast services (eg, the broadcast service identified by the broadcast service ID). The Broadcast Rate subfield may indicate the data rate associated with the broadcast service. The "broadcast frequency" subfield may indicate the frequency at which the broadcast data is transmitted. The "broadcast coding" subfield may indicate the coding of the broadcast data packets (e.g., BCC interframe binary convolutional code (BCC), low density interframe parity check (LDPC), hybrid automatic repeat request (HARQ), convolution code (CC) , incremental redundancy (IR) HARQ).

The Broadcast Control subfield may indicate how to control the broadcast service. For example, the "broadcast control" subfield may indicate that if the WTRU requires a certain broadcast service, the WTRU needs to directly negotiate this with the transmitting WTRU (eg, the transmitting AP) using, for example, a broadcast request frame. In another example, the "broadcast control" subfield may indicate a server address (eg, server IP address) or controller AP address (eg, another AP's MAC address or BSSID). Such a controller AP may be the master AP of a multi-AP set. The WTRU may also communicate with a controller AP or server to provide feedback about the broadcast service, negotiated rates, or coding. Examples of control methods may be WLAN control methods, Transmission Control Protocol/Internet Protocol (TCP/IP), Broadcast Request Negotiation, ANQP, and/or Generic Advertisement Service (GAS) frame exchanges.

The Broadcast Parameters subfield may include one or more broadcast parameters, including offset, channel, and so on. For example, the offset may indicate an offset to the beginning of the next broadcast burst or broadcast sequences, which may be from the end of the current transmission, from the target beacon transmission time (TBTT), or from other breakpoints. A channel may indicate a channel, OFDMA subchannels, or resource units (RUs) on which broadcast service packets may be available.

The Broadcast Status subfield may indicate the current status of the broadcast, such as Broadcasting (broadcasting), Paused (suspended), or To be Initiated (awaiting initiation).

An exemplary design of a UL broadcast element or UL eBCS element is shown in FIG. 4. The UL broadcast element may include one or more of the following exemplary fields: element identifier; length; element identifier extension; and/or UL broadcast information, including the N fields of the eBCS. It should be noted that in this application, unless otherwise indicated, the terms "UL Broadcast Element", "UL eBCS Element", and "UL Broadcast Capability Element" may be used interchangeably.

The combination of the element identifier and the element identifier extension may identify the current element as a UL broadcast element or a UL eBCS element. The length field may indicate the length of the UL broadcast element. The UL broadcast information may include N fields (ie, eBCS 1 to eBCS N), such that each field may be used to indicate a particular UL broadcast service supported by the transmitting WTRU. Each eBCS field may contain one or more of the following exemplary subfields: Allowed Broadcast Service ID; Allowed eBCS Type (allowed eBCS type); Association Required (required association); DL Reception Required (required DL reception); Allowed Broadcast Rate (allowed broadcast rate); Broadcast Frequency Allowed (allowed broadcast frequency); Broadcast Encoding (broadcast coding); Broadcast Control (broadcast control); Broadcast Parameters (broadcast parameters); and/or Broadcast Status (broadcast status). The above subfields will be further described below.

The Allowed Broadcast Service Identifier subfield may indicate a UL Broadcast Service Identifier that is supported and allowed by the transmitting WTRU. The allowed eBCS type subfield may include the type of broadcast service allowed (e.g., whether the allowed eBCS is UL or DL, or whether the broadcast service is categorized as automotive, sensory, directional, emergency, auxiliary, informational, and/or dedicated to support the event). In one example, a bitmap may be included in the UL broadcast element to indicate which types of broadcast services are allowed and supported by the transmitting WTRU(s). In another example, the type of broadcast may be identified by an OUI or a server address. The allowed eBCS type subfield may include a detailed description of the broadcast service to be provided.

The Association Required subfield (not shown in FIG. 4) may indicate whether an association is required to use one or more allowed UL broadcast services (eg, the broadcast service identified by the Allowed Broadcast Service ID). The DL Reception Required subfield (not shown in FIG. 4) may indicate whether DL reception is required to use one or more UL allowed broadcast services (eg, the broadcast service identified by the allowed broadcast service identifier).

The Allowed Broadcast Rate subfield may indicate the allowed data rate for one or more WTRUs for UL transmission associated with the broadcast service. The Allowed Broadcast Frequency subfield may indicate the allowed frequency at which the WTRU is allowed to broadcast data on the UL associated with this allowed broadcast service. The "broadcast coding" subfield may indicate the coding to be used for the UL broadcast data packets, eg interframe BCC, interframe LDPC, HARQ CC, HARQ IR.

The Broadcast Control subfield may indicate UL broadcast control methods. For example, the "broadcast control" subfield may indicate how to control the broadcast service (eg, indicate the destination of the allowed UL broadcast service). For example, it may indicate that if the WTRU wants to use a particular UL broadcast service, the WTRU needs to directly negotiate this with the transmitting WTRU (eg, the transmitting AP) using, for example, a broadcast request frame. In another example, the "broadcast control" subfield may indicate a server address (eg, server IP address) or controller AP address (eg, another AP's MAC address or BSSID). Such a controller AP may be a master AP of a multi-AP set. A WTRU that wants to use the uplink broadcast service to receive feedback or negotiate the MCS to be used may communicate with the server or controller. For example, the control method may be via WLAN, TCP/IP, broadcast request negotiation, ANQP or GAS frame exchanges.

The Broadcast Parameters subfield may include one or more broadcast parameters, including UL access, eg EDCA, triggered broadcast access, uplink OFDMA random access. For example, if the broadcast parameter is triggered broadcast access, the WTRU using the uplink broadcast service may only transmit uplink broadcast packets if initiated by the AP. For example, an AP may be initiated on one or more subchannels or RUs. The trigger frame or trigger frame may indicate that uplink broadcast data and/or transmissions from non-associated WTRUs are being triggered. If the broadcast parameter is an uplink OFDMA random access, the WTRU using the uplink broadcast service may only transmit uplink broadcast packets if triggered by a trigger frame or a trigger frame triggering uplink random access. on one or more RUs. The Broadcast Status subfield may indicate the current status of the broadcast, such as Broadcasting (broadcasting), Paused (suspended), or To be Initiated (awaiting initiation).

In one embodiment, the UL and DL broadcast elements as described above may be combined into a single broadcast element or eBCS element. In another embodiment, information included in the UL and DL broadcast elements may be included as part of the ANQP element. In addition, any subset of UL and DL broadcast elements may be carried in any other type of frames or any other type of elements, MAC and PHY headers, and so on.

The DL broadcasting procedure according to the present application will be described below.

First, a WTRU (i.e., a WTRU without an AP) that requires a DL broadcast service may include a DL broadcast element in the frames it transmits, such as probe request frames, ANQP frames, or GAS request frames. When transmitted by the WTRU, the DL broadcast element may indicate information or parameters of the desired DL broadcast service. In another example, a non-AP WTRU may include a DL Broadcast Request Element, which may include one or more of the subfields described for the DL Broadcast Element describing the desired DL Broadcast Services.

Second, an AP may include a DL broadcast element or an eBCS element in its beacon, probe responses, association responses, ANQP response frames or GAS response frames, or any other type of frame. In one example, an AP may include a DL broadcast element only if it has received a frame from the WTRU that requests a DL broadcast element (e.g., when it has received a frame such as an ANQP frame, a GAS request frame, or probe request frames, which include a DL broadcast element or an eBCS element indicating a need for a DL broadcast service). When transmitted by the AP, the DL broadcast element may indicate the DL broadcast services provided by the AP.

Third, a WTRU (ie, a WTRU without an AP) receiving a DL broadcast element can identify one or more desired broadcast services provided by the AP. The non-AP WTRU may follow the instructions specified in the DL Broadcast Element, such as association, if association is necessary. If the broadcast status indicates that the broadcast service is currently broadcasting, the non-AP WTRU may follow the broadcast control information and parameters (e.g., tune to the correct RUs, subchannels, or channels with the correct offset to receive one or more packets). broadcast service using the specified broadcast mode or encoding).

If the broadcast status indicates that the broadcast service is paused or to be initiated, the non-AP WTRU may follow the instructions included in the DL broadcast element to resume or initiate the broadcast service. For example, if broadcast control is to be "negotiated with the AP", the WTRU may communicate with the AP and then forward a broadcast service request to the AP. In another example, the WTRU may not associate with the AP but use the ANQP request or GAS protocols to resume or initiate a DL broadcast service. If the broadcast control is indicated as "negotiated with the controller AP or server" by "WLAN" or "TCP/IP", the WTRU may communicate with the controller AP and then forward a broadcast service request to the AP while indicating the best AP for the broadcast service. transfers; or the WTRU may use TCP/IP connections to communicate with the server to resume or initiate the desired broadcast service while indicating the best AP at which the broadcast service should be provided.

The WTRU may then use broadcast control techniques to further negotiate broadcast services, such as feedback, coding, modulation and coding scheme (MCS), and/or repetition.

The UL broadcast procedure according to the present application will be described below.

First, a WTRU (i.e., a WTRU without an AP) that wants to use one or more UL Broadcast services may include a UL Broadcast element in the frames it transmits, such as Probe Request Frames, ANQP Frames, or Request Frames. GAS. When a non-AP WTRU is transmitted, the UL broadcast element may indicate information or parameters of required UL broadcast services. In another example, a non-AP WTRU may include a UL Broadcast Request Element, which may include one or more of the subfields described for the UL Broadcast Element describing the desired UL Broadcast Services.

Second, an AP may include in a UL broadcast element or an eBCS element in its beacon, probe responses, association responses, ANQP response frames or GAS response frames, or any other types of frames. An AP may include a DL broadcast element if it has received a frame from the WTRU that requests a DL broadcast element (eg, when it has received a frame such as an ANQP frame, a GAS request frame, or probe request frames that include UL broadcast element or eBCS element indicating a need for UL broadcast services). When transmitted by the AP, the UL broadcast element may indicate the UL broadcast services that are supported and allowed by the AP. The AP may provide policies on supported and allowed UL broadcast service, such as allowed broadcast rate, allowed broadcast frequency, or allowed UL broadcast method such as triggered broadcast, uplink OFDMA random access, or EDCA.

If the broadcast state is Accepting Broadcast, then a non-AP WTRU may start broadcasting its UL data if it has received a frame (e.g., beacon, probe or association responses, or FILS discovery frames) from the AP, which may include a UL Broadcast Element or an eBCS Element in which the AP may indicate that it supports and allows that particular UL Broadcast Service. The WTRU may follow the instructions included in the UL Broadcast Element to perform UL Broadcast, eg, using the allowed broadcast rate, broadcast frequency, and/or uplink broadcast methods. If the broadcast state is Pause or To Be Initiated, the non-AP WTRU may use the specified broadcast control methods to negotiate directly with the AP, or contact the controller AP or server using the broadcast control methods (e.g., WLAN, TCP/IP) to resuming or initiating the UL broadcast service provided by the AP.

The WTRU may then use broadcast control techniques to further negotiate broadcast services such as coding, MCS, or repetition.

The following description will be devoted to how to improve the reliability of the broadcast in accordance with the present application.

Broadcast packets may be sent to multiple WTRUs, such as in the case of a downlink. Channel conditions and device capabilities and sensitivities may vary among WTRUs. Therefore, the reception reliability of a broadcast packet may not be the same for all receiving WTRUs. Broadcast reliability is especially important for WTRUs that are not associated or cannot transmit data. Thus, broadcast protocols and broadcast packets can be designed such that broadcast services are guaranteed to be provided to all WTRUs.

This document describes the mechanisms for improving the reliability of the broadcast in accordance with the present application. An example of a broadcast reliability mechanism is interframe coding such as BCC and LDPC. A broadcast node (eg, AP) may transmit frames containing systematic or parity bits from previously transmitted frames, encoded and interleaved with each other. The data in the original frame may be BCC or LDPC encoded. In the first example, the data in new subframes may contain encoded data from previously transmitted frames that are linearly encoded together, which is referred to as BCC or LDPC interframe coding. In this case, the reliability of additional bits after decoding becomes higher. In the second example, the data in new subframes may contain encoded data from previously transmitted frames that are combined and interleaved. This can be described as partial frame HARQ. In this case, instead of the HARQ retransmission occurring on its own, it is transmitted along with the HARQ retransmissions from other frames. This can help reduce broadcast latency. In the following description, the above two examples will be described in detail.

In FIG. 5 and FIG. 6 shows examples of inter-frame LDPC coding with incrementally increasing increments. As shown in FIG. 5, the LDPC inter-frame coding procedure may start after generating data bits and parity bits by dropping short bits in the LDPC coding procedure, resulting in a packet with a length of Nmax. The rate RH frame shown in FIG. 5 may contain N bits, and D (unequal) increments may contain D incremental subframes from ∆1 to ∆D.

. Если длина каждого инкрементного подкадра одинакова, то Nmax = N + DΔ_i. Исходная передача для каждого кадра будет содержать N битов (как показано на фиг. 5), тогда как инкрементные подкадры (например, ∆1–∆D) могут быть составлены из дополнительных (невыкалываемых) битов четности. В примере, показанном на фиг. 6, индексы инкрементов могут быть случайными и могут не увеличиваться последовательно.Nmax may be determined based on the length of the packet to be sent (N), the number of incremental subframes (D) and their respective lengths (Δ _i ). Each incremental subframe can have a different length, so Nmax = N +

. If the length of each incremental subframe is the same, then Nmax = N + DΔ _i . The initial transmission for each frame will contain N bits (as shown in FIG. 5), while incremental subframes (eg, ∆1-∆D) may be composed of additional (non-punctured) parity bits. In the example shown in FIG. 6, the increment indices may be random and may not increment sequentially.

In FIG. 7 shows an example of BCC interframe coding. In the case of BCC interframe coding for BCC transmission, the original transmission for each frame has N non-punctured bits (eg, N bits shown in FIG. 7), and incremental subframes (eg, ∆1 and ∆2, shown in FIG. 7) may be are made up of other punctured bits. As shown in FIG. 7, the source data may contain x0, x1, x2, x3, and x4; encoded data may contain A0-A4 and B0-B4; one rate RL frame with unequal increments for BCC may contain N bits (including A0, B0, A1, B2, A3, B4), ∆1 (containing B1, A2 and B3) and ∆2 (A4 and A0).

Procedures for BCC/LDPC interframe transmission and partial HARQ burst for BCC/LDPC codes may be defined. In FIG. 8 shows an example of interframe coding and partial HARQ with fixed indices. The AP may determine the transmission of NT+D frames (ie, NT frames and D frames). The first NT transmissions (ie, 1-NT) are intra-coded frames consisting of N bits of each frame. As shown in FIG. 8, intra-frame coding contains NT frames from 1 to NT frame. The last D transmissions are inter-frame encoded subframes consisting of a combination of D increments from each frame.

In one embodiment, the subframe increments D of each frame may be combined and then transmitted. This enables partial HARQ transmission. In another embodiment, the D increments of each frame may be linearly encoded using a particular coding scheme.

For each transmitted frame, one or more of the following information may be signaled (e.g., in a Physical Layer Convergence Procedure (PLCP) header): intraframe or interframe coding, intraframe coding frame index, interframe coding frame index (in the example below, this could be index a to delta (a, b) and/or may be signaled explicitly or identified implicitly based on the frame index after the start of the entire transmission) or frame indexes encoded in the incremental subframe (in the example below, this may be index b in delta (a, b ) and/or may be signaled explicitly or identified implicitly based on the number of frames in the transmission). In the case where the indices may have different sizes, the size of the increments from each frame in the incremental subframe may be signaled.

In FIG. 9 shows an example of interframe coding and sliding window partial HARQ. As shown in FIG. 9, incremental subframes may be aggregated (eg, as an aggregated PPDU) into transmitted frames. For example, each frame may aggregate incremental subframes from frames preceding it, up to a maximum number of incremental subframes. As shown in FIG. 9, frame 2 aggregates the first incremental subframe (i.e. ∆1, 1) from frame 1. Frame 3 aggregates the second increment (i.e. ∆2, 1) from frame 1 with the first increment (∆1, 2) from frame 2. Frame 4 aggregates the increments from frames 1, 2, and 3. Frame 5 aggregates the increments from frames 2, 3, and 4 because the value of D (number of increments) is 3.

The increments to be transferred can be dynamically selected, as shown in FIG. 10. For example, this approach may be used in the event that feedback is possible from the WTRU about frames that were received unsuccessfully. The broadcasting AP may dynamically select certain frames to transmit incremental information. The broadcasting AP may dynamically select the increment size to send based on the desired quality of the broadcast signal (some frames may need more protection than others). In an example, feedback from one or more WTRUs indicates that a particular frame was received very poorly. For example, if a majority of the (selected) WTRUs indicate that the frame was received unsuccessfully, additional information may be required. In another example, the WTRU may send more information about frames that may have been sent earlier to ensure they are decoded faster to reduce overall delay.

The WTRU procedure may be defined as part of the interframe coding. As part of the exemplary WTRU procedure, the AP and the WTRU may exchange capability information regarding the ability to receive interframe coding. The capability information may include a maximum number of frames that can be decoded at the same time. The AP may use the capability information to decide on the interframe coding parameters for the broadcast channel. For example, an AP may set the number of simultaneous frames to a minimum specified by all receiving WTRUs (eg, a set of discrete, predefined and/or WTRU-specific values). The WTRU may receive the frame and decode the received PLCP header. The WTRU may identify that the received frame is interframe encoded. The WTRU may identify whether the packet is intraframe, interframe, or both. If the packet is intraframe encoded, the WTRU may decode the frame. If the decoding is successful, the WTRU may send an ACK to the requested AP and/or complete the decoding procedure for that frame. If decoding is unsuccessful, the WTRU may store the frame in a buffer.

If the packet is interframe encoded, the WTRU may decode/deinterleave/deaggregate the incremental subframes in the frame. The WTRU may identify the incremental subframe based on explicit or implicit signaling. The WTRU may discard incremental subframes of all frames that have been successfully decoded. The WTRU may process the incremental subframes of all frames that have not been decoded by adding incremental subframe information received to an existing framebuffer, and then decoding the results. If the decoding is successful, the WTRU may send an ACK to the requested AP and/or complete the decoding procedure for that frame. If decoding is unsuccessful, the WTRU may store the frame in a buffer. The WTRU may send a NAK to the AP or wait until the total number of incremental subframes has been received before sending a NAK. Because the channel is a broadcast channel, the ACK/NAK transmission may be based on an AP request to a particular WTRU(s) rather than to all WTRUs being transmitted. In one example, WTRUs may send ACK/NAKs on a specific (sub)channel, and the presence of a signal on the subchannel may notify the AP of success/failure.

If the packet has both intra- and inter-frame encoding, the WTRU may separate the intra-frame packet from the inter-frame packet, and then process each separately using the approaches described above.

In a HARQ broadcast, a broadcast frame may be transmitted multiple times or with repetition. In the exemplary procedure, the repetition transmission can be the same as the original transmission, so that receivers can easily combine the received data. Signaling may be used to allow the receiving WTRU to combine the received frames. One or more of the following information (fields) may be included in, for example, a PLCP header, a MAC header, a MAC body, and/or a beacon frame: identifier, broadcast, repetition, repetition index, next repetition frame, or next repetition beacon. The above fields will be further described below.

The identifier (ID) field may indicate any of a destination ID, a source ID, a transmitter ID, a sink ID, a broadcast ID, a broadcast channel ID, and/or a content ID. The broadcast field may be used to indicate whether the frame is broadcast, multicast, and/or unicast. The retransmission field may be used to indicate whether this frame is retransmitted. The transmission repetition field may also indicate the type of repetition used (eg, simple repetition or interframe coding).

The repetition index field may indicate the number of repetitions for the current transmission. For example, the repetition index field may be transmitted in ascending order. In another example, the repetition index field may be transmitted in descending order so that receiving WTRUs may know the number of transmission repetitions that may follow. The next repetition frame field may indicate the expected time for the next repetition frame. The next repetition frame field may also indicate the type of repetition frame to be sent at that time. The next repetition beacon field may indicate the expected time for the next repetition beacon. In the example, the expected time could be a duration.

In one embodiment, the broadcast frame may be transmitted multiple times or in a repetition manner with some diversity schemes. For example, the retransmission may not be the same as the original transmission. In this case, one or more of the following approaches can be used.

According to the first approach, different bit interleavers can be used for different repetitions. A bit interleaver may be used between the BCC encoder and the pattern matcher. In one example, multiple bit interleavers may be defined. For example, the number of bit interleavers may be the same as the maximum number of repetitions allowed. In this case, one interleaver can be used for one repetition. In another example, a fixed number of interleavers may be defined. The interleaver index matching with repetition can be determined using a function. For example, a modular function may be used. The interleaver index used for the kth repetition can be defined as Interleaver_ID = mod (k, N), where N is the specified maximum number of interleavers. The bit interleaver may or may not be used for LDPC codes. In the exemplary approach, bit interleavers may be defined for transmission repetitions.

According to the second approach, different symbol interleavers can be used for different repetitions. For example, a symbol level interleaver may be used immediately after the pattern matcher. The use of a symbol level interleaver may be to distribute the modulated symbol among the OFDM symbol. In one example, a fixed number of symbol interleavers may be defined. The interleaver index matching with repetition can be determined using a function. For example, a modular function may be used. The symbol interleaver index used for the kth repetition can be defined as Interleaver_ID = mod (k, N), where N is the defined maximum number of symbol level interleavers.

In a third approach, a different redundancy version (RV) may be used for different transmissions. Different RVs may correspond to different subsets of coded bits. The mapping of an RV index to repetition can be defined with a function. For example, a modular function may be used. The RV index used for the kth iteration can be defined as RV_ID = mod(k, N) where N is the specified maximum number of RVs.

Broadcast diversity may be signaled in a PLCP header, MAC header, or MAC body, and the data may include one or more of the following exemplary fields: ID, Broadcast, Transmission Repeat, Maximum Repeat, Repeat Index, Index transmission or next beacon/repeat timing. The above exemplary fields will be further described below.

An identifier (ID) field may indicate a destination ID, a source ID, a transmitter ID, and/or a receiver ID. The broadcast field may be used to indicate whether the frame is broadcast, multicast, and/or unicast. The repeat transmission field may be used to indicate whether this frame is transmitted with repetition. The maximum number of repetitions field may indicate the maximum number of repetitions to be expected. The repetition index field may indicate the number of transmission repetitions for the current transmission. In one example, the repetition index field may be passed forward. In another example, the repetition index field may be transmitted with a countdown so that the receiving WTRUs may know the number of subsequent transmission repetitions.

The transmit index field may be used to signal the bit level interleaver index, symbol level interleaver index, and/or RV index used in the next transmission. The next repeat beacon/timing field may indicate the expected time for the next repeat beacon/timing. In the example, the expected time may be a duration. This duration may be a function of the WTRU's capabilities, allowing each WTRU to decode each transmission independently. In another example, the expected time may be "immediate", indicating that the next repetition occurs within the duration of the interframe interval (xIFS) after the completion of the current transmission.

Procedures for power saving when receiving a broadcast service (BCS) may be used. The WTRU may receive a PLCP header with a repetition identifier. In one example, the PLCP header may contain the total number of repetitions as well as the repetition index. The WTRU may store all repetitions and decode after the last reception. The WTRU may decode after each repetition. One or more APs and one or more WTRUs may agree on a minimum duration between repetitions to allow packet decoding after each repetition.

If the WTRU has decoded the packet, it may go to sleep for the duration of the transmission. In FIG. 11 shows an example of a power saving procedure with xIFS between BCS repetitions that can be used for BCS. For example, as shown in FIG. 11, WTRU1 decoded the packet during Tx1, and then it can sleep until Tx4.

If the WTRU has decoded the packet and the duration between repetitions is "immediate", the WTRU may go to sleep for the duration of certain repetitions. In FIG. 12 shows an example power saving procedure with specific time differences between repetitions that can be used for BCS. For example, as shown in FIG. 12, WTRU1 has decoded the packet during Tx1, and then it can sleep during Tx2, Tx3 and Tx4.

In one embodiment, feedback-based repetition may be used. The maximum number of transmission repetitions may be predetermined or (re)determined. The maximum number of transmission repetitions may be carried and signaled in beacon frames, (re)association frames, probe request/response frames, or any other types of control/control frames. A WTRU (eg, a WTRU with an AP or a WTRU without an AP) may not always reach the maximum number of transmission repetitions. The WTRU may terminate the retransmission based on the feedback. For example, if the WTRU receives a positive acknowledgment (ACK) from another WTRU that may be far away from the WTRU, the WTRU may stop repeating.

In one embodiment, transmission repetitions may be separated by at least a predetermined xIFS interframe interval. In one method, the xIFS may be larger than a short interframe interval (SIFS) or a distributed interframe interval (DIFS). In one embodiment, the interframe interval between each retransmission may be dynamic and configurable. The receiving WTRU may, under certain conditions, respond with a positive acknowledgment if the WTRU has successfully received the rebroadcast(s) transmission(s). The acknowledgment may be transmitted before the next repetition, so that the broadcasting WTRU may receive it before the transmission of the next repetition. The broadcasting WTRU may determine if it can terminate the transmission repetition. In one embodiment, the WTRU group may be allowed to send an acknowledgment. For example, a broadcasting WTRU may define a group of WTRUs that may be far away from it. The broadcasting WTRU may indicate in a control frame or a control frame that the WTRU group may be allowed to transmit an acknowledgment between rebroadcasts. A group of WTRUs can send back the same acknowledgment at the same time so that they can be aligned at the receiver side and the receiver can decode them.

In one embodiment, a poll frame or a multi-user block request ACK (MU-BAR) frame may be transmitted before or after the retransmission. In an alternative embodiment, a Null Data Packet (NDP) trigger frame may be aggregated with a broadcast frame. A poll frame, MU-BAR frame, or NDP trigger frame may trigger acknowledgment transmissions from one or multiple WTRUs. The receiving WTRU, which may be polled or started, may respond with a positive acknowledgment if it has successfully received the rebroadcast(s)(s). The broadcasting WTRU may receive the positive acknowledgment and determine if it may complete the retransmission.

The broadcasting WTRU may determine if it may terminate the repetition. Or, the broadcasting WTRU or the AP may configure whether the broadcasting WTRU may end the repetition. In one embodiment, the configuration may be based on whether the broadcast frame can be targeted to associated WTRUs or non-associated WTRUs. If a frame can be transmitted by a non-associated WTRU, or partially by that non-associated WTRU, the broadcasting WTRU cannot prematurely terminate the repetition of transmissions.

The maximum number of repetitions may be determined by the AP or otherwise. The AP may broadcast the number of maximum repetitions in its beacon, association request/response, probe request/response frame, or other types of control/management frames. In one design, the AP may decide to use a larger maximum number of repetitions if the BSS coverage range may be large or the AP may capture many WTRUs at the cell edge. Otherwise, the AP may use a lower maximum number of repetitions. In FIG. 13 shows an example of a closed loop transmission repetition. As shown in FIG. 13, during Tx1, WTRU1 received the transmission from the AP, but WTRU2 and WTRU3 did not receive the transmission. Therefore, WTRU2 and WTRU3 can send NAK to the AP. Then, during Tx2, a retransmission may be performed. The WTRU2 then successfully received the transmission. But WTRU3 did not accept. Then, at time Tx3, a retransmission may be performed. The WTRU3 then received the transmission.

In one embodiment, multi-AP broadcasting may be used for reliability. WTRUs may be associated with one or multiple APs (associated WTRUs). APs may broadcast to a set of APs for broadcast (associated and non-associated WTRUs). The APs may identify the broadcast resource (eg, the entire band specified by the RU). APs may broadcast a Broadcast Channel (BC) transmission scheme. For example, APs may send Cyclic Shift Diversity (CSD) indicating the AP ID, corresponding offset, and/or cyclic prefix (CP). APs can send CSDs with the same offset and CP. APs may send a transmission based on a time interval (eg, time offset with synchronization index). APs may use the JT method (eg, Suffix Tree Clustering (STC) method and index). In FIG. 14 shows an example of multi-AP broadcast with CSD. In FIG. 15 shows an example of a multi-AP time division broadcast. In FIG. 16 shows an example of a multi-AP broadcast with a transmission spatial diversity scheme (eg, space time block code (STBC)).

In one embodiment, repetition may be used for broadcast/multicast frames. For example, repetition for broadcast/multicast frames can be used with: different self-decodable RVs, different bit level interleaver, different symbol level interleaver (equivalent to subcarrier mapping change), and/or with SIG indicating broadcast, PAID (e.g., ID association), RV, HARQ, interleaver ID, and/or next sync.

In one embodiment, feedback-based repetition may be used. For example, the transmission repetition may be separated by at least a fixed duration (eg, xIFS). xIFS can be larger than SIFS or DIFS. Feedback-based repetition may include the use of polling/multi-user block ACK request (MU-BAR). Some WTRUs may be allowed to send back an acknowledgment until the next repetition if the transmission is successfully decoded. In one embodiment, preselected remote WTRUs may send an acknowledgment (eg, using the near-far procedure in 802.11ay). An AP that has successfully received an acknowledgment may, in some cases, complete the transmission. The AP may periodically perform full repetition for non-associated WTRUs. BCS transmission parameters (for associated WTRUs) may be generalized and/or TCP/IP may be configured for a non-associated/non-transmitting WTRU via probe(s) request(s). The ACK may indicate WTRUs, a WTRU group, a Null Data Packet (NDP) Feedback Report, and/or a random access MU.

If an AP subnet is configured to send the same broadcast information from multiple APs with or without automatic repeat (AR) configured for frames sent, the WTRU receiving those transmitted frames should be able to identify frames containing the same broadcast data. transmission, or an incremental version of broadcast data redundancy. In this case, the WTRU can improve the reception of broadcast data by combining frames if necessary, or by ignoring redundant frames containing data already received. In case AR is simple repetition (sending a redundancy version of the same frame from multiple APs), the WTRU should have a means to determine that it has already received data to ignore redundant frames, or that it has not received data. The WTRU needs to know how to combine frames to increase the likelihood that data can be received. In case the AR has incremental redundancy (IR) frames, the WTRU should have a means of knowing how it should combine incremental redundant frames, combine frames with identical data, and ignore frames containing data that have already been received. There is currently no way to inform the WTRU that frames sent by different APs contain the same broadcast data or IR version of the data that the WTRU is trying to receive.

The following description will focus on subnet planning to address the issues discussed above.

The AP subnetwork may be configured to broadcast the same information from multiple APs. Such a subnetwork may use techniques to inform the WTRU that a broadcast from a plurality of APs contains broadcast data. Because each AP is a unique transmission source, a variety of methods can be used. In an exemplary method for informing the WTRU of broadcast data, the AP subnet may coordinate the use of the same broadcast ID information. APs may use one or more of the following information fields (e.g., in the PLCP header, MAC header, MAC body, and/or beacon frame) to provide broadcast identifier information: AP set indicator, subject identifier, identifier, broadcast, retransmission, repetition index, next repetition frame, or next repetition beacon. The above fields will be further described below.

The AP set indicator field may indicate that the frame, as well as its associated ID(s), is(are) being broadcast by a set of APs. The Subnet ID field MAY provide a unique ID for the subnet, and all APs on the subnet MAY use the same ID. Subnets may be coordinated to ensure that different subnets with overlapping service areas have unique subnet identifiers. In one example, the subnet ID may be based on the MAC address of one of the APs on the subnet. In another example, an SSID hash, an AP location-based hash, a unique subnet identifier assigned by a network/subnet administrator, or any other unique identifier may be used.

The identifier (ID) field may indicate a destination ID, a source ID, a transmitter ID, a receiver ID, a broadcast ID, a broadcast channel ID, and/or a content ID. The broadcast field may be used to indicate whether the frame is broadcast, multicast, and/or unicast. The retransmission field may be used to indicate whether this frame is retransmitted. The transmission repetition field may also indicate the type of repetition used (eg, simple repetition or interframe coding).

The repetition index field may indicate the number of transmission repetitions for the current transmission. In one embodiment, the repetition index field may be transmitted with a direct count. In another embodiment, the repetition index field may be transmitted with a countdown so that the receiving WTRUs may know the number of subsequent transmission repetitions. The next repetition frame field may indicate the expected time for the next repetition frame. The next repetition frame field may also indicate the type of repetition frame to be sent at that time. The next repetition beacon field may indicate the expected time for the next repetition beacon. In the example, the expected time may be a duration.

APs may coordinate and select a virtual SSID and/or MAC address that all APs on a subnet will use for broadcast (eg, a particular broadcast or a particular set of broadcasts). All APs in a subnet may transmit the same SSID information (eg, virtual SSID and/or MAC address). By transmitting the same SSID information, these APs will appear as one broadcast AP to any WTRU receiving broadcast frames sent by APs on the subnet. APs using the virtual SSID and/or MAC address may use one or more of the following information fields (e.g., in the PLCP header, MAC header, MAC body, and/or beacon frame) to provide broadcast identifier information: virtual SSID indicator, virtual MAC address, identifier, broadcast, repeat, repeat index, next repeat frame, and/or next repeat beacon. The above fields will be further described below.

The virtual SSID indicator field may be one bit indicating that the SSID is a virtual SSID, or it may be multiple bits providing information about the type of virtual SSID specified. The virtual MAC address field may be one bit indicating that the AP's MAC address is a virtual MAC address, or it may be multiple bits providing information about the type of the specified virtual MAC address.

The identifier (ID) field may indicate a destination ID, a source ID, a transmitter ID, a receiver ID, a broadcast ID, a broadcast channel ID, and/or a content ID. The broadcast field may be used to indicate whether the frame is broadcast, multicast, and/or unicast. The retransmission field may be used to indicate whether this frame is retransmitted. The transmission repetition field may also indicate the type of repetition used (eg, simple repetition or interframe coding).

The repetition index field may indicate the number of transmission repetitions for the current transmission. In one embodiment, the repetition index field may be transmitted with a direct count. In another embodiment, the repetition index field may be transmitted with a countdown so that the receiving WTRUs may know the number of subsequent transmission repetitions. The next repetition frame field may indicate the expected time for the next repetition frame. The next repetition frame field may also indicate the type of repetition frame to be sent at that time. The next repetition beacon field may indicate the expected time for the next repetition beacon. In one embodiment, the expected time may be a duration.

The procedures may be used to ensure the reliability of the UL broadcast. A DL broadcast may involve multiple transmitters and receivers, and each receiver may represent a broadcast service endpoint located within a non-AP WTRU. This can complicate the Carrier Sense Multiple Access (CSMA)/MAC ARQ protocol for broadcast data because different transmitter-receiver pairs may have different success/failure status. For example, a plurality of APs may need to know the identifiers of (unassociated) broadcast receivers in order to assign feedback resources in the UL direction. In addition, multiple APs may need to coordinate among themselves to know which MAC PDU (MPDU)/data unit is missing for at least one WTRU before attempting retransmission.

UL broadcast reliability can also be an issue. As shown in FIG. 17, UL WTRU 1701 does not know the status of the receiver (or received protocol data unit (PPDU) statistics of the Physical Layer Convergence Procedure (PLCP) for some duration), which is shown as "Does the WTRU know whether the PPDU is successful, without input higher-level data? An example of a requirement for data to be transmitted would be that data loss is unacceptable and retransmissions are required for the lost data. In this case, without knowledge of the 802.11 UL protocol layer, the WTRU 1701 may need to associate with a BSS (or connect with another access) in order to have a unicast data connection to trigger retransmission. Another example of a data transfer requirement would be that data loss is acceptable but not desirable. In this case, feedback from the receiver may improve the quality of PPDUs transmitted in the future.

In a UL broadcast, different receivers of a UL broadcast packet represent a single broadcast endpoint, and there is only one transmitter (i.e., there is a single (shared) receiver state upon which one transmitter can act). This makes the MAC layer CSMA/ARQ protocol more likely in the UL. This helps eliminate the wireless communication error or improve the reliability of data transmitted later (retransmitted or new), and the WTRU without AP does not need to rely solely on the unicast connection with the broadcast sink node through the upper layer for reliability.

The exemplary procedures for UL broadcast may or may not be applied to PPDU-based PPDUs (e.g., may be applicable to feedback during a period of time after the UL broadcast, and during that time the UL 802.11 MAC transmitter stores information that may need to be retransmitted). The UL WTRU may base the UL broadcast on feedback to adjust the robustness of the PPDUs to be sent after the feedback without performing lost data retransmissions. Example procedures for broadcast over UL may be applicable to non-broadcast PPDUs sent towards UL in a multi-AP configuration where one AP is the anchor or master AP and the other APs are auxiliary receivers or slave APs for the anchor AP.

In FIG. 18 shows an example of a transmitter for receiving joint feedback as a means of providing feedback to improve stability. In a UL broadcast packet requesting feedback, the transmitting WTRU 1801 may indicate the MCS, scrambler initiation, and/or longer guard interval (GI) to be used in the requested DL feedback. In one embodiment, a predetermined MCS/GI may be used for the DL Feedback PPDU and/or the Feedback PPDU Scrambler Trigger may be set to the same value as in the requesting UL Broadcast PPDU.

In one embodiment, a UL broadcast PPDU may indicate one or more APs that are allowed to feedback to limit feedback signal delay spread. If the transmitting WTRU does not receive any feedback, then the transmitting WTRU may conclude that all APs are busy/interfered and may perform a delayed (re)transmission. If the WTRU does not use a feedback procedure to perform retransmission (ie, no retransmission for broadcast PPDUs), the WTRU may base its transmission on the feedback to adjust the robustness of the PPDU (eg, power, MCS) to send in the future. If a plurality of APs have successfully received a UL broadcast PPDU, their feedback frames may be wirelessly combined and decoded as a single PPDU in the WTRU without the AP.

In FIG. 19 shows another exemplary procedure for providing DL feedback to the AP so that the transmitter can receive joint feedback (eg, for each MPDU/data unit in one or more aggregated MPDUs (AMPDUs) transmitted over the UL). A mechanism may be used that allows the AMPDU to be transmitted without the need for a prior exchange to establish a feedback agreement. Such an unsolicited feedback convention may be used in a UL broadcast. The parameters for the agreement (eg, buffer size, timeout value) may be set to predefined values for all WTRUs supporting UL broadcast.

To receive a single shared feedback bitmap corresponding to the data/MPDUs, an NDP feedback approach can be used, eg with positive feedback amplitude-shift keying. Tone dialing indicating status 0 may not be transmitted, while tone dialing indicating status 1 may be transmitted by the AP. The Long Training Field (LTF) of the NDP may contain a longer GI to cover propagation delay differences from different APs to the original transmitter/transmitter, ie WTRU 1901 without AP.

The UL broadcast PPDU may indicate a starting sequence number. The ACK signal in each tone set may represent a feedback bit for an MPDU/data block with a sequence number offset from the initial sequence number. Based on the tone dialing energy, the originating transmitter/transmitter (ie, WTRU without AP) can obtain the receive status of the MPDU/data block sequence number based on the corresponding tone dialing index.

Since the NDP feedback may be positive feedback amplitude-shift keying, the feedback NDP initiated by the UL broadcast PPDU may be considered by the source transmitter as a single NDP. When the original transmitter detects an NDP, the corresponding missing MPDUs/data units may be retransmitted. If no NDP is detected, the originating transmitter may deduce that all receivers (eg, APs) are interfered with/busy and may perform a delayed (re)transmission. If the WTRU does not use a feedback procedure to perform retransmission (ie, no retransmission for broadcast PPDUs), the WTRU may feedback its own transmission to adjust the robustness of the PPDUs (eg, power, MCS) to send in the future.

While the features and elements are described above in specific combinations, it will be apparent to one skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embedded in a computer-readable medium and designed to be executed by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable media. Examples of computer-readable storage media include, without limitation, read-only memory (ROM), random access memory (RAM), register, cache memory, semiconductor storage devices, magnetic media such as internal hard drives and removable drives, magneto-optical media and optical media such as CD-ROMs and digital versatile discs (DVDs). The processor, in combination with software, may be used to implement an RF transceiver for use in a WTRU, UE, terminal, base station, RNC, and/or any host computer.

Claims (29)

1. A wireless communication method for use in a station (STA), including: the station management entity (SME) generating a request primitive providing a wake-up radio (WUR) scanning process for WUR discovery frames transmitted by one or more access points (APs), wherein the request primitive contains a plurality of first parameters including at least a portion of the CompressedBSSID and MinDiscoveryChannelTime; performing a WUR scanning process based on the plurality of first parameters; generating at least one confirmation primitive based on the result of the WUR scanning process and at least a subset of the plurality of first parameters, wherein each of the at least one confirmation primitive comprises a plurality of second parameters including at least a portion of the CompressedBSSID; and sending at least one confirmation primitive to the SME. 2. The method of claim 1, wherein the plurality of first parameters further comprises at least one of a basic service set identifier (BSSID), BSSIDList, a service set identifier (SSID), SSIDList, compressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MaxDiscoveryChannelTime , MaxScanningTime, ReceivedPowerThreshod, WURScanningMode, WURScanningReportingOption, or RequestWURresult. 3. The method of claim 2, wherein WURScanningMode indicates a WUR scanning mode. 4. The method of claim 1, wherein the set of second parameters further comprises a BSSDescriptionFromWURDFSet. 5. The method of claim 1, further comprising associating with a Basic Service Set (BSS) based on one or more of the second parameter set of at least one confirmation primitive. 6. The method of claim 1, wherein the request primitive is an MLME-WURSCAN.Request primitive. 7. The method of claim 1, wherein the request primitive is generated by a station control entity (SME). 8. The method of claim 1, wherein the request primitive is an MLME-SCAN.Request primitive. 9. The method of claim 1, further comprising generating a stop request primitive to stop the WUR scanning process. 10. The method of claim 1, further comprising generating a stop confirmation primitive. 11. Wireless station (STA), containing: processor capable of generating a request primitive providing a wake-up radio (WUR) scanning process for WUR discovery frames transmitted by one or more access points (APs), wherein the request primitive contains a plurality of first parameters including at least a portion of the CompressedBSSID and MinDiscoveryChannelTime bits, performing a WUR scanning process based on a plurality of first parameters, generating at least one acknowledgment primitive based on the result of the WUR scanning process and at least a subset of the plurality of first parameters, wherein each of the at least one acknowledgment primitive comprises a plurality of second parameters including at least a portion of the CompressedBSSID bits, and sending to the station control entity (SME) at least one confirmation primitive. 12. The STA of claim 11, wherein the set of first parameters comprises at least one of BSSID, BSSIDList, SSID, SSIDList, CompressedBSSID, compressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MinDiscoveryChannelTime, MaxDiscoveryChannelTime, MasScanningTime, ReceivedPowerThreshod, WURScanningMode, or WURScanningMode RequestWURresult. 13. The STA of claim 12, wherein WURScanningMode indicates the WUR scanning mode. 14. The STA of claim 11, wherein the second parameter set further comprises a BSSDescriptionFromWURDFSet. 15. The STA of claim 11, further comprising a transceiver, the processor and the transceiver being configured to associate with a Basic Service Set (BSS) based on one or more of a second set of parameters of at least one acknowledge primitive. 16. The STA of claim 11, wherein the request primitive is an MLME-WURSCAN.Request primitive. 17. The STA of claim 11, wherein the request primitive is generated by a station control entity (SME). 18. The STA of claim 11, wherein the request primitive is an MLME-SCAN.Request primitive. 19. The STA of claim 11, wherein the processor is further configured to generate a stop request primitive to stop the WUR scanning process. 20. The STA of claim 11, wherein the processor is further configured to generate a stop acknowledge primitive.

Images