Method and WTRU for WUR scanning

Abstract

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

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application Serial No. 62 / 811,967, filed February 28, 2019, which is hereby incorporated by reference in its entirety. Background Art

[0003] Fixed or low-mobility wireless communications for local area networks (LANs) utilize technologies such as Institute of Electrical and Electronics Engineers (IEEE) 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ax, 802.11be, or generally 802.11x (also commonly referred to as WiFi). These technologies involve medium access control (MAC) and physical layer (PHY) specifications for creating a wireless LAN (WLAN) between at least two points. As WLANs grow, it may be desirable to transmit signals on the same transport for multiple types of WLAN interfaces to achieve desired performance and spectral efficiency. Summary of the Invention

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

[0005] A wireless transmit / receive unit (WTRU) is disclosed. The WTRU includes: a processor configured to generate a request primitive for enabling a WRU scanning procedure for WUR discovery frames transmitted by one or more access points (APs), the request primitive including a plurality of first parameters; perform the WUR scanning procedure based on the plurality of first parameters; generate at least one confirmation primitive at a MAC layer based on a result of the WUR scanning procedure and at least a portion of the plurality of first parameters; and transmit the at least one confirmation primitive from the MAC layer to a station management entity (SME). BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present invention may be understood in more detail from the following description given by way of example with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0007] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0008] Figure 1B is a diagram showing an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0009] Figure 1C is an example of an embodiment in which Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) for use within a communication system as shown in FIG.

[0010] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the communication system shown in FIG;

[0011] Figure 2A is a flowchart illustrating a method according to an embodiment of the present application;

[0012] Figure 2B is a flowchart illustrating a method according to another embodiment of the present application;

[0013] Figure 3 shows an example design of a downlink (DL) broadcast element;

[0014] Figure 4 shows an example design of an uplink (UL) broadcast element;

[0015] Figure 5 An example of LDPC inter-frame coding with sequentially increasing increments is shown;

[0016] Figure 6 An example of LDPC inter-frame coding with non-sequentially increasing increments is shown;

[0017] Figure 7 An example of BCC inter-frame coding is shown;

[0018] Figure 8 An example of inter-frame coding / partial HARQ with fixed index is shown;

[0019] Figure 9 An example of inter-frame coding / partial HARQ with sliding window is shown;

[0020] Figure 10 An example of inter-frame coding / partial HARQ with feedback and dynamic incremental subframe selection is shown;

[0021] Figure 11An example power saving procedure is shown with xIFS interframe spacing between repetitions of BCS;

[0022] Figure 12 An example of a power saving procedure with specific timing differences between repetitions is shown;

[0023] Figure 13 An example of repeated transmission with feedback is shown;

[0024] Figure 14 An example of multi-AP broadcasting with CSD is shown;

[0025] Figure 15 An example of multi-AP broadcasting with timing separation is shown;

[0026] Figure 16 An example of multi-AP broadcasting with a spatial transmit diversity scheme is shown;

[0027] Figure 17 An example network architecture is shown where the UL WTRU (e.g., STA) is unaware of the receiver state.

[0028] Figure 18 An example process for an AP to provide downlink (DL) feedback is shown; and

[0029] Figure 19 An example process is shown in which an AP provides downlink (DL) feedback identifying a portion of lost data. DETAILED DESCRIPTION

[0030] Figure 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW DTS-S OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0031] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate 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 configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or MiFi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as UEs. It should be noted that, in this application, the terms "WTRU" and "STA" may be used interchangeably unless otherwise specified.

[0032] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node B (such as a gNode B (gNB)), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0033] 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, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0034] The 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 link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0035] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed Uplink (UL) Packet Access (HSUPA).

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

[0037] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access and may establish the air interface 116 using NR.

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

[0039] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM Evolution (GERAN), etc.

[0040] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not be required to access the Internet 110 via CN 106.

[0041] The RAN 104 may be in communication with the 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 the WTRUs 102a, 102b, 102c, 102d. Data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although in Figure 1A Although not shown, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT or a different RAT as the RAN 104. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0042] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) from the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0043] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The WTRU 102c is shown configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0044] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0045] The 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, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0046] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0047] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in the embodiment, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0048] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122, and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

[0050] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium, nickel-zinc, nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0051] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or as an alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0052] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0053] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with particular subframes used for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with particular subframes used for UL (e.g., for transmission) or DL (e.g., for reception)) may be concurrent and / or simultaneous.

[0054] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0055] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0056] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown in FIG, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

[0058] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for facilitating switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0059] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102B, 102c, managing and storing the context of the WTRUs 102a, 102B, 102c, and the like.

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

[0061] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0062] Although the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may employ (eg, temporarily or permanently) a wired communication interface with a communication network.

[0063] In a representative embodiment, the other network 112 may be a WLAN.

[0064] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from a STA outside the BSS may reach the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0065] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP can send beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, such as in an 802.11 system, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a specific STA, the specific STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0066] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0067] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining adjacent 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels or by combining two non-contiguous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing respectively. The stream can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above-mentioned 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0068] The operating mode below 1 GHz is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, including limited capabilities for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0069] 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 can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the example of 802.11ah, for a STA that supports (e.g., only supports) 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports 1 MHz operating mode) transmitting to the AP, then all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

[0070] In the United States, 802.11ah can be used in the frequency band from 902 MHz to 928 MHz. In South Korea, the frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the frequency band is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0071] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0072] The RAN 104 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. Each of the gNBs 180a, 180b, and 180c includes one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit and / or receive signals to and from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit and / or receive wireless signals to and from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0073] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter configurations (numerology). For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths).

[0074] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0075] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, interworking between DC, NR, and E-UTRA, routing user plane data towards a user plane function (UPF) 184a, 184b, routing control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0076] Figure 1DThe CN 106 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one session management function (SMF) 183 a, 183 b, and possibly a data network (DN) 185 a, 185 b. Although the aforementioned elements are depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0077] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of services used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182 a, 182 b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies (e.g., LTE, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).

[0078] The SMF 183a, 183b can connect to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b can also connect to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0079] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface. This may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0080] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Furthermore, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0081] Given that Figures 1A-1D and Figures 1A-1D

[0015] As described herein, one or more, or all, of the functionality described herein with respect to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. An emulated device may be one or more devices configured to emulate one or more, or all, of the functionality described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0082] Emulated devices can be designed to implement one or more tests on other devices in a lab environment and / or in a carrier network environment. For example, one or more emulated devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more emulated devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulated devices can be directly coupled to another device for testing purposes and / or perform tests using over-the-air wireless communications.

[0083] One or more simulation devices can perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. One or more simulation devices can be test equipment. The simulation device can use direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) to transmit and / or receive data.

[0084] The IEEE 802.11 High-Efficiency WLAN (HEW) Study Group (SG) was created to explore the scope and purpose of possible future modifications to enhance the quality of service experienced by all users of wide-spectrum wireless users in many usage scenarios, including high-density scenarios in the 2.4 GHz, 5 GHz, and 6 GHz bands. The HEW SG is considering new use cases that support dense deployment of APs and STAs and associated radio resource management (RRM) technologies. Potential applications of HEW include emerging usage scenarios such as data delivery for stadium events, high user density scenarios such as stations or enterprise / retail environments, and evidence of increased reliance on video delivery, as well as wireless services for medical applications. The IEEE Standards Board approved the IEEE 802.11ax Task Group (TG) based on the results developed in the HEW SG.

[0085] In the TGax standards meeting, several contributions showed that measurement traffic for various applications has great potential for short packets, and there are network applications that can also generate short packets. These applications include the following: virtual office; TPC ACK; video stream ACK; device / controller (e.g., mouse, keyboard, game controller, etc.); access (e.g., probe request / response); network selection (e.g., probe request, Access Network Query Protocol (ANQP)); and / or network management / control frames. Contributions in 802.11ax have proposed the introduction of multi-user (MU) features, including uplink (UL) and downlink (DL) OFDMA and UL and DL MU-MIMO. Designing and defining a mechanism for multiplexing UL random access for different purposes can be used in 802.11ax and other protocols.

[0086] TGax's proposals regarding medium access issues in the 6 GHz band include using only triggered or scheduled medium access in the 6 GHz band, and / or limiting active scanning and scheduled enhanced distributed channel access (EDCA) medium access in the 6 GHz band.

[0087] The IEEE 802.11ba TG was created to define physical (PHY) and medium access control (MAC) modifications to provide enhanced low power operation of 802.11 devices. The MAC and PHY modifications may enable operation of a wake-up radio (WUR). The desired operating bands for the WUR include 2.4 GHz, 5 GHz, and may be extended to below 1 GHz. The WUR device may operate as a companion radio to a primary connection radio (PCR) for transmitting conventional 802.11 packets. The PCR may also be referred to as a primary radio. The WUR may transmit packets carrying (only) control information and may have an effective receiver power consumption of less than one milliwatt (mW). Receiving a wake-up packet by the WUR may cause the primary connection radio (PCR) to wake up from sleep. In an example, the WUR may have at least the same range as that of a primary connection radio operating on at least 20 MHz payload bandwidth.

[0088] Both APs and non-AP STAs can have WUR as a companion radio. Example use cases for WUR include: IoT devices; low-power operation of smartphones; fast message / incoming call notification scenarios; fast status query / reporting, configuration change scenarios; and / or fast emergency / critical event reporting scenarios.

[0089] The IEEE 802.11bc TG was created to define MAC modifications for enhanced broadcast services (eBCS) for 802.11 devices. The IEEE 802.11bc modifications may not affect the IEEE 802.11 PHY specification. The eBCS service may be in the DL direction from the AP to a non-AP STA, or in the UL direction from a sensor non-AP STA. eBCS may be provided to STAs that are associated or unassociated with a specific AP. An AP may be expected to support up to 3,000 non-AP STAs with eBCS services. In addition, there may be a class of low-cost non-AP STAs that consume eBCS services and may not be able to transmit directly to the AP. Example use cases for eBCS may include: stadium video broadcasting; car broadcasting; uplink sensor data broadcasting; museum information and multi-language broadcasting; and / or event producer information and content broadcasting.

[0090] In intra-frame coding for broadcast or other channels, the content of the transmitted frame can be derived from a single set of coded bits. In inter-frame coding, the content of the transmitted frame can be derived from multiple sets of coded bits that are normally transmitted in separate frames but are generated (e.g., using linear coding on additional increments) to form new sub-frames that can be transmitted to aid decoding. This allows the broadcast signal to be transmitted to all receiving WTRUs (STAs) with increased reliability in an incremental form of rate matching to allow smooth changes in code rate. The encoder used is typically a rate-compatible code where, for any two code rates R>R', a rate R' frame is the concatenation of a rate R frame with additional redundancy bits.

[0091] WUR scanning has been agreed to for 802.11ba devices. In a WUR scan, an AP may send out a WUR discovery frame which provides information about itself and its BSS. A WUR-capable WTRU may scan the WUR discovery frames to discover a suitable AP and BSS for association. However, MAC layer management entity (MLME) primitives may need to be defined in order for the WTRU to start WUR scanning and / or provide collected information about received WUR discovery frames to higher layers. Appropriate MLME primitives may be defined so that the WTRU can control the WUR scanning process, as well as provide information about the received WUR discovery frames collected during the WUR scanning process to higher layers. It should be noted that the terms WUR scanning and WUR scanning process may be used interchangeably unless otherwise noted.

[0092] In order to solve the above problems, the method and WTRU according to the present application will be described as follows.

[0093] The following will refer to Figure 2A A method 200 according to an embodiment of the present application is described. Figure 2A 2 shows a flow chart of method 200. Figure 2A As shown, method 200 may include: at 201, generating a request primitive by a station management entity (SME), the request primitive enabling a wake-up radio (WUR) scanning process for a WUR discovery frame transmitted by one or more access points (APs), the request primitive including a plurality of first parameters; at 202, performing the WUR scanning process based on the plurality of first parameters; at 203, generating at least one confirmation primitive at a medium access control (MAC) layer based on a result of the WUR scanning process and at least a portion of the plurality of first parameters; and at 204, transmitting at least one confirmation primitive from the MAC layer to the SME.

[0094] Therefore, according to an embodiment of the present application, a WTRU may include: a processor configured to generate a request primitive, wherein the request primitive enables a wake-up radio (WUR) scanning process for a WUR discovery frame transmitted by one or more access points (APs), the request primitive including multiple first parameters; performing the WUR scanning process based on the multiple first parameters; 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 multiple first parameters; and transmitting at least one confirmation primitive from the MAC layer to the SME.

[0095] The following description will describe the process at 201 in detail.

[0096] The request primitive may be an MLME primitive, which may be defined and used for WUR scanning. In an embodiment, the request primitive may be an MLME-WURSCAN request primitive (MLME-WURSCAN.Request primitive). For example, a WUR scan may be initiated by an MLME primitive, such as an MLME-WURSCAN request primitive. The MLME primitive may request a survey of potential BSSs via a WUR discovery frame, which the WTRU may later select to attempt to join. It should be noted that in this application, unless otherwise stated, the terms "MLME-WURSCAN request primitive", "MLME-WURSCAN request" and "request primitive" may be used interchangeably. Those parameters in the request primitive (e.g., MLME-WURSCAN request primitive) will be described below with reference to detailed embodiments.

[0097] In another embodiment, the request primitive can be an MLME-SCAN request primitive (MLME-SCAN.Request primitive) or a portion of an MLME-SCAN request primitive. Parameters in the MLME-SCAN request primitive can be similar to those in the MLME-WURSCAN request primitive, and the parameters in the MLME-SCAN request primitive are further described below. In this application, unless otherwise specified, the terms "MLME-SCAN request primitive," "MLME-SCAN request," and "request primitive" are used interchangeably. The parameters in a request primitive (e.g., the MLME-WURSCAN request primitive) are described below with reference to detailed embodiments.

[0098] In an embodiment, the request primitive may be generated by a station management entity (SME). For example, the MLME-WURSCAN request primitive may be generated by the SME in order for the WTRU to use its WUR or low power WUR mode to determine whether there are other BSSs it can join. In an embodiment, the request primitive may be generated by a processor.

[0099] The Wake-Up Radio (WUR) scanning procedure for WUR discovery frames transmitted by one or more APs is a scanning procedure in which the WTRU scans for and therefore discovers a suitable AP and BSS' for association. The WTRU will scan and discover WUR discovery frames transmitted from the APs. The WUR discovery frame may include different fields, such as SSID, compressed BSSID, channel information, etc.

[0100] The request primitive may include a plurality of first parameters. The multiple first parameters may include at least one of the following: basic service set identifier (BSSID), BSSID list (BSSIDList), service set identifier (SSID), SSID list (SSIDList), compressed BSSID (CompressedBSSID), compressed SSID (CompressedSSID), compressed BSSID list (CompressedBSSIDList), compressed SSID list (CompressedSSIDList), discovery channel (DiscoveryChannel), discovery channel list (DiscoveryChannelList), minimum discovery channel time (MinDiscoveryChannelTime), maximum discovery channel time (MaxDiscoveryChannelTime), received power threshold (ReceivedPowerThreshod), maximum scanning time (MaxScanningTime), WUR scanning reporting period (WURScanningReportingPeriod) (or WUR scanning reporting time (WURScanningReportingTime)), WUR scanning mode (WURScanningMode), WUR scanning reporting option (WURScanningReportingOption) or request WUR result (RequestWURresult). The following sections describe each of these parameters.

[0101] The BSSID may indicate the BSSID of the desired AP or desired BSS. In an embodiment, the BSSID may identify a basic service set as a 48-bit tag and in accordance with the MAC-48 convention. The BSSID may be a wildcard BSSID (e.g., ff:ff:ff:ff:ff:ff). In an embodiment, there may be only one BSSID in the request primitive. In another embodiment, there may be multiple BSSIDs in the request primitive. (One or more) BSSIDs may be included in a BSSID list. In other words, the BSSID list may contain information of one or more BSSIDs. For example, the BSSID list may be a list containing multiple BSSIDs, each of which may indicate a desired BSS or AP. Although some examples of BSSIDs and BSSID lists have been described above, they are not intended to be exclusive or to limit the present application. Any variations of the above-described embodiments of the BSSID and BSSID list may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0102] The SSID may be a service set identifier of a desired AP or BSS or SS. That is, the SSID may indicate a set of services to which the WTRU may desire to connect. The SSID may be a wildcard SSID. In an embodiment, there may be only one SSID in the request primitive. In another embodiment, there may be multiple SSIDs in the request primitive. (One or more) SSIDs may be included in an SSID list. In other words, the SSID list may contain information of one or more SSIDs of a desired AP or BSS. For example, the SSID list may be a list containing multiple SSIDs, each of which may indicate a desired service set of an AP or BSS. Although some examples of SSIDs and SSID lists have been described above, they are not intended to be exclusive or to limit the present application. Any variations of the above-described embodiments of SSIDs and SSID lists may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0103] The CompressedBSSID may indicate the compressed BSSID of a desired AP or desired BSS with which the WTRU may desire to associate. In an embodiment, the CompressedBSSID may be a partial BSSID. The CompressedBSSID may be associated with a wildcard BSSID. The associated CompressedBSSID may be calculated based on the provided BSSID. In an embodiment, there may be only one CompressedBSSID in the request primitive. In another embodiment, there may be multiple 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, the CompressedBSSIDList may be a list containing multiple 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 intended to be exclusive or to limit the present application. Any variations of the above embodiments of CompressedBSSID and CompressedBSSIDList may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0104] A DiscoveryChannel may indicate a channel or WUR channel on which discovery frames (e.g., WUR discovery frames) may be scanned during a WRU scan. In an embodiment, there may be only one DiscoveryChannel in the request primitive. That is, discovery frames may be scanned on a specific channel indicated by the DiscoveryChannel. In another embodiment, there may be multiple DiscoveryChannels in the request primitive. That is, discovery frames may be scanned on multiple channels indicated by these DiscoveryChannels. (One or more) DiscoveryChannels may be included in a DiscoveryChannelList. In other words, a DiscoveryChannelList may contain information of one or more DiscoveryChannels. For example, a DiscoveryChannelList may be a list containing multiple DiscoveryChannels, each DiscoveryChannel may indicate a channel or WUR channel on which discovery frames (e.g., WUR discovery frames) may be scanned to discover the desired (one or more) APs or (one or more) BSSs. If the MLME-WURSCAN request primitive includes one or more WURDiscoveryChannels or WURDiscoveryChannelLists, the WTRU may tune only to these WUR discovery channels to scan for WUR discovery frames. Although some examples of DiscoveryChannels and DiscoveryChannelLists have been described above, they are not intended to be exclusive or to limit the present application. Any variations of the above-described embodiments of DiscoveryChannels and DiscoveryChannelLists may also be applied to the methods and WTRUs according to the present application, as long as they can help implement the principles of the present application. It should be noted that unless otherwise indicated, channels, WUR channels, and discovery channels may be used interchangeably.

[0105] MinDiscoveryChannelTime may indicate the minimum time, expressed in time units (TUs) or other units, for the WTRU to perform a WUR scan on each of the channel(s) indicated by the DiscoveryChannel(s) in the DiscoveryChannelList. The MinDiscoveryChannelTime may be determined based on the WUR discovery period of the desired AP(s) or BSS(s) or SS(s). The WUR discovery period may be pre-acquired knowledge or received over the air from one or more APs. Although MinDiscoveryChannelTime and its preferred embodiments have been described above, they are not intended to be exclusive or to limit the present application. Any available value of MinDiscoveryChannelTime may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0106] MaxDiscoveryChannelTime may indicate the maximum time, expressed in TUs or other units, for the WTRU to perform a WUR scan on each of the channel(s) indicated by the DiscoveryChannel(s) in the DiscoveryChannelList. MaxDiscoveryChannelTime may be determined based on the WUR discovery period of the desired AP(s) or BSS(s) or SS(s). The WUR discovery period may be pre-acquired knowledge or received over the air from one or more APs. Although MaxDiscoveryChannelTime and its preferred embodiments have been described above, they are not intended to be exclusive or to limit the present application. Any available value of MaxDiscoveryChannelTime may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0107] ReceivedPowerThreshold may indicate a threshold value of received power, above which (one or more) discovery frames (e.g., WUR discovery frames) are processed. That is, only (one or more) discovery frames whose received power is greater than ReceivedPowerThreshold may be processed during the WUR scan process. (One or more) discovery frames whose received power is lower than ReceivedPowerThreshold may be ignored during the WUR scan process. In an embodiment, ReceivedPowerThreshold may be defined based on a received channel power indicator (RCPI), a received signal strength indication (RSSI), a signal-to-noise ratio (SNR), and / or a signal-to-interference-plus-noise ratio (SINR). Although ReceivedPowerThreshold and its preferred embodiments have been described above, they are not intended to be exclusive or to limit the present application. Any available value of ReceivedPowerThreshold may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0108] MaxWURScanningTime may indicate the maximum time, expressed in TUs or other units, for a WTRU to perform a WUR scanning procedure. Although MaxWURScanningTime and its preferred embodiments have been described above, they are not intended to be exclusive or limiting of the present application. Any available value of MaxWURScanningTime may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0109] WURScanningReportingPeriod (or WURScanningReportingTime) may indicate the time or period at which the results of the WUR scanning process may be reported (e.g., via an MLME-WURScanning.confirm primitive). Although WURScanningReportingPeriod and its preferred embodiments have been described above, they are not intended to be exclusive or to limit the present application. Any available value of WURScanningReportingPeriod may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0110] WURScanningMode may indicate the mode of WUR scanning. For example, the value of WURScanningMode may be "background", "simultaneously with regular scanning", "WUR scanning only", etc. In other words, the WUR scanning mode indicated by WURScanningMode may be "background", "simultaneously with regular scanning", "WUR scanning only", etc. The above-mentioned WUR scanning mode will be further described with reference to detailed embodiments below. Although WURScanningMode and its exemplary values have been described above, they are not intended to be exclusive or to limit the present application. Any available values of WURScanningMode may also be applied to the method and WTRU according to the present application, as long as they can help implement the principles of the present application.

[0111] WURScanningReportingOption can indicate how to report the results of the WUR scanning process. That is, the option of reporting the results of the WUR scanning process can be indicated by WURScanningReportingOption. The value of WURScanningReportingOption can be "Immediate", "Periodic", "At Pre-determined Time", "Channel Specific", "At_Request", "At_End", etc. For example, if the WURScanningReportingOption parameter has a value of "Periodic" or "At_Specified_Time", the WURScanningReportingPeriod or WURScanningReportingTime as described above can be included in the same primitive (i.e., the request primitive) to indicate the time or periodicity at which the results of the WUR scanning process can be provided or reported. The above options for reporting the results of the WUR scanning process will be further described with reference to detailed embodiments below. Although WURScanningReportingOption and its exemplary values are described below, they are not intended to be exclusive or limiting of the present application. Any available values of WURScanningReportingOption may also be applied to the method and WTRU according to the present application as long as they can help implement the principles of the present application.

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

[0113] So far, different first parameters that can be included in the request primitive have been described. It should be noted that the above first parameters are given as examples only, and they are not intended to be exclusive or limit the present application. Any available parameters can be included in the request primitive, as long as they can help implement the principles of the present application.

[0114] The following section will describe in detail the process 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.

[0115] In an embodiment, as described above, after the SME or processor generates a request primitive (e.g., an MLME-WURSCAN request primitive), the processor may control the WTRU to initiate a WUR scan procedure immediately or after the current frame exchange sequence is completed. The WTRU may then perform a WUR scan procedure based on a plurality of first parameters in the request primitive.

[0116] According to the WURScanningMode parameter, for example, if its value is "background", the WUR scanning process according to the present application can be started as a background scan. In this case, the WTRU can perform other types of operations.

[0117] If the value of the WURScanningMode parameter is "WUR Scan Only", the WUR scanning procedure may be initiated only as a WUR scan. In this case, for example, the WTRU may turn off its primary radio and / or perform WUR scanning only when in low power WUR mode, and the WTRU may not perform any other type of operation at the same time.

[0118] If the value of the WURScanningMode parameter is "simultaneous with normal scan" or "simultaneous with passive scan / active scan", the WUR scanning process may be performed as a simultaneous discovery process along with normal scan, active scan / passive scan, as indicated by the WURScanningMode parameter. For example, the WTRU may use its WUR to scan for WUR discovery frames in low power WUR mode while simultaneously performing passive scanning or active scanning, for example, using the PCR or primary radio.

[0119] As described above, different WUR scanning modes may be selected based on the WURScanningMode parameter. It should be noted that the WUR scanning procedure may not be the only scanning procedure performed by the WTRU in a given time period. That is, the WTRU may be performing non-WUR scanning procedures (e.g., active scanning procedures, passive scanning procedures, etc.) and WUR scanning procedures simultaneously.

[0120] In another embodiment, the request primitive can be a MLME-SCAN request primitive or part of an MLME-SCAN request primitive. In an example, the WUR scanning process can be initiated by an MLME-SCAN request primitive, which can include one or more WUR scanning parameters. For example, any one 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, WURUscanningMode, WURScanningReportOption, RequestWURResult. These parameters can be as described herein, and the process for initiating WUR scanning can be similar to that described herein. The detailed description of these parameters can be similar to those described with reference to the MLME-WURSCAN request primitive. Therefore, the detailed description of these parameters will be omitted. The terms MLME-WURSCAN and MLME-SCAN may be used interchangeably (eg, in the names of primitives such as MLME-SCAN request, MLME-SCAN confirm, MLME-WURSCANSTOP request, and / or MLME-WURSCANSTOP confirm).

[0121] The following description will describe the process at 203. As described above, the method 200 may include: at 203, generating 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.

[0122] The at least one confirmation primitive may include one or more MLME-WURSCAN confirmation primitives, one or more MLME-SCAN confirmation primitives, or a combination of (one or more) MLME-WURSCAN confirmation primitives and (one or more) MLME-SCAN confirmation primitives. For example, the at least one confirmation primitive may include one MLME-WURSCAN confirmation primitive and one MLME-SCAN confirmation primitive. For another example, the at least one confirmation primitive may include multiple MLME-WURSCAN confirmation primitives and no MLME-SCAN confirmation primitive. Although some examples of the at least one confirmation primitive have been described above, they are not intended to be exclusive or to limit the present application. In some embodiments, the terms "MLME-SCAN confirmation primitive," "MLME-WURSCAN confirmation primitive," and "confirmation primitive" may be used interchangeably.

[0123] The at least one confirmation primitive may be generated based on: (1) the result of the process at 202; and (2) a portion of the plurality of first parameters. That is, on the one hand, the at least one confirmation primitive may be generated based on the result of the process at 202, i.e., the result of the WUR scanning process. On the other hand, the at least one confirmation primitive may be generated based on a portion of the plurality of first parameters. The portion of the plurality of first parameters may include at least one of the following: WURScanningReportingOption, ReceivedPowerThreshold, CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, or a combination thereof. The description in the following section will describe in detail the portion of the plurality of first parameters used to determine the confirmation primitive. In the following description, unless otherwise noted, confirmation primitive and MLME-WURSCAN confirmation primitive may be used interchangeably.

[0124] In an embodiment, the portion of the plurality of first parameters may include a WURScanningReportingOption. That is, the MLME-WURSCAN confirmation primitive may be generated based on the value of the WURScanningReportingOption. The WURScanningReportingOption may be used to determine the timing for generating the MLME-WURSCAN confirmation primitive. The following description will describe the relationship between the MLME-WURSCAN confirmation primitive and the WURScanningReportingOption, that is, how the MLME-WURSCAN confirmation primitive is generated based on the value of the WURScanningReportingOption.

[0125] For example, if the value of WURScanningReportingOption is "Immediate", the MLME-WURSCAN confirmation primitive may be generated whenever a WUR discovery frame is correctly received or detected.

[0126] If the value of WURScanningReportOption is "Channel_Specific", then the MLME-WURSCAN confirm primitive may be generated after a specific WUR discovery channel has been scanned for a WUR discovery frame, and may or may not have a matching compressed SSID or compressed BSSID as indicated in the MLME_WURSCAN request. In this case, the WUR discovery channel may be one or more WUR discovery channels indicated in the MLME_WURSCAN request.

[0127] If the value of WURScanningReportOption is "At_Request", then if the MLME-WURSCAN request has been generated using the RequestResult parameter or the RequestResult parameter has its value set to 1, then the MLME-WURSCAN confirm primitive can be generated to provide the results of the current WUR scanning process.

[0128] If the value of WURScanningReportingOption is "At_End", the MLME-WURSCAN confirmation primitive can be issued at the end of the current WUR scanning process after the WUR scanning is completed on one or more WUR discovery channels, which can be indicated in the MLME-WURSCAN request primitive.

[0129] If the value of WURScanningReportionOption is "Periodic" or "At_Time", the MLME-WURSCAN confirmation primitive may be generated every period or at a certain time, which may be indicated in the MLME-WURSCAN request primitive.

[0130] In an embodiment, the portion of the plurality of first parameters may include at least one of the following parameters: SSID, SSIDList, BSSIDList, CompressedSSID, CompressedSSDList, CompressedBSSID, or CompressedBSSIDList. That is, the MLME-WURSCAN confirmation primitive may be generated based on the value of at least one of the following parameters: SSID, SSIDList, BSSIDList, CompressedSSID, CompressedSSDList, CompressedBSSID, or CompressedBSSIDList. The following description will describe the relationship between the MLME-WURSCAN confirmation primitive and the above-mentioned parameter(s), that is, how to generate the MLME-WURSCAN confirmation primitive based on the value(s) of the above-mentioned at least one parameter.

[0131] For example, if a WUR discovery frame with a matching SSID, BSSID, compressed SSID, or compressed BSSID has been received, an MLME-WURSCAN confirmation primitive may be generated. In another example, if one or more CompressedBSSIDs or CompressedSSIDs are provided in a request primitive (e.g., an MLME-WURSCAN request primitive), then if a WUR discovery frame with a matching compressed SSID or a matching compressed BSSID is received, an MLME-WURSCAN confirmation primitive may be generated. For example, if in the received WUR discovery frame, the transmitter ID contained in the ID field matches the 12 least significant bits (LSBs) of the expected compressed BSSID, and the type-dependent field contains the 12 MSBs of the expected compressed BSSID, then a matching compressed BSSID may be present, and an MLME-WURSCAN confirmation primitive may then be generated. If the MLME-WURSCAN request includes one or more of CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSDList, then only BSSs with matching CompressedBSSID or CompressedSSID (or part thereof) may be reported.

[0132] In an embodiment, the portion of the plurality of first parameters may include a ReceivedPowerThreshold parameter. That is, the MLME-WURSCAN confirmation primitive may be generated based on the value of the ReceivedPowerThreshold. For example, if the MLME-WURSCAN request primitive includes the ReceivedPowerThreshold, the MLME-WURSCAN confirmation primitive may be generated only for BSSs whose WUR discovery frames have been received by the WTRU with a reception power greater than the given ReceivedPowerThreshold. That is, if the reception power of the WUR discovery frame is greater than the given ReceivedPowerThreshold, the (one or more) BSSs transmitting the WUR discovery frame may be reported by the MLME-WURSCAN confirmation primitive.

[0133] The following description will describe the content of the confirmation primitive according to the present application. A confirmation primitive (e.g., an MLME-WURSCAN confirmation primitive) can be used to return a description of the BSS set detected by the WUR scanning process (e.g., by receiving one or more WUR discovery frames). In an embodiment, when the value of WURReportingOption is "Channel_Specific", "At_Request", "Periodic", or "At_Specified_Time", multiple MLME-WURSCAN confirmation primitives can be generated. In another embodiment, a single MLME-WURSCAN confirmation primitive can be generated.

[0134] In an embodiment, at least one confirmation primitive may be generated, and each of the at least one confirmation primitive may include multiple second parameters. The multiple second parameters may include at least one of the following parameters: a BSS description from a WUR set (BSSDescriptionFromWURDFSet), a result code (ResultCode), a scanned WUR discovery channel list (ScannedWURDiscoveryChannelList), or vendor-specific information (VendorSpecificInfo). If dot11WUROptionImplemented (implemented dot11WUR option) or dot11WURActivated (activated dot11WUR) is true, the BSSDescriptionFromWURDFSet parameter may be present. The following description will describe the above-mentioned second parameters in the confirmation primitive in detail.

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

[0136]

[0137] Table 1 Parameters of BSSDescriptionFromWURDFSet

[0138] ResultCode may have at least one of the following example values: SUCCESS, INTERMEDIATE_SCAN_RESULT, NOT_SUPPORTED, PARTIAL_WURSCAN, PERIODIC_SCAN_RESULT, REQUESTED_SCAN_RESULTS. In all of these example values, "SCAN" may be replaced by "WURSCAN" to clarify that the result is a WUR scan result. The value of ResultCode may depend on the reason why the MLME-WURSCAN confirmation primitive was issued. The following description will describe the above example values of ResultCode in detail.

[0139] SUCCESS may be used if the WUR scan procedure has been performed successfully. INTERMEDIATE_SCAN_RESULT may be used if the WURReportingOption parameter in the MLME-WURSCAN request primitive is Channel_Specific or Immediate. If not all WUR discovery channels have been scanned, the ResultCode value may be set to PARTIAL_SCAN. If the WURReportingOption parameter in the MLME-WURSCAN request primitive is Periodic or At_Requested_Time, the ResultCode value may be set to PARTIAL_SCAN. If the WURReportingOption parameter in the MLME-WURSCAN request primitive is At_Request and the MLME-WURSCAN request primitive has been received using RequestWURResult, the ResultCode value may be set to REQUESTED_SCAN_RESULTS.

[0140] It should be noted that the above example values of ResultCode are given as examples only and are not intended to be exclusive or limiting of the present application. Any available values of ResultCode may be applied to the methods and WTRUs according to the present application as long as they can help implement the principles of the present application.

[0141] ScannedWURDiscoveryChannelList may contain a list of WUR discovery channels that have been scanned.

[0142] In an embodiment, the WUR SCAN results may be reported by or as part of the MLME-SCAN confirmation primitive. That is, the MLME-SCAN confirmation primitive may be used to return a description of the BSS or AP set detected by the WUR scanning process (e.g., by receiving one or more WUR discovery frames). When the value of WURReportingOption is "Channel_Specific", "At_Request", "Periodic", or "At_Specified_Time", multiple MLME-SCAN confirmation primitives may be issued. Otherwise, a single MLME-SCAN confirmation primitive may be issued. The MLME-SCAN confirmation primitive may include any one of the following example parameters: BSSDescriptionFromWURDFSet, ResultCode, ScannedWURDiscoveryChannelList, or VendorSpecificInfo. The example parameters may be the same or similar to those described with reference to the MLME-WURSCAN confirmation primitive. Therefore, a detailed description of the example parameters in the MLME-SCAN confirmation primitive will be omitted. In this application, unless otherwise specified, the terms MLME-WURSCAN and MLME-SCAN are used interchangeably. Thus, unless otherwise specified, the terms MLME-SCAN request and MLME-WURSCAN request are used interchangeably; the terms MLME-SCAN confirm and MLME-WURSCAN confirm are 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" are 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 confirm primitive" are used interchangeably.

[0143] After the process at 203 , the method 200 proceeds to the process at 204 , ie, transmitting at least one confirmation primitive from the MAC layer to the SME.

[0144] The following will refer to Figure 2B The method and WTRU according to the second embodiment of the present application are described. Figure 2B As shown, the process from 201 to 204 is the same as the above reference Figure 2B The processes described are similar or identical. The difference between the first embodiment and the second embodiment is Figure 2B The illustrated method 200 includes steps 205 to 207. More specifically, the method 200 further includes: detecting whether a stop request primitive for stopping the WUR scanning process has been generated at 205, wherein if the stop request primitive has been generated, the method 200 further includes: stopping the WUR scanning process at 206; and generating a stop confirmation primitive at 207. The stop primitive may be generated before the first confirmation primitive has been generated.

[0145] The following description will describe the process at 205 and 207. In an embodiment, the stop request primitive can be a MLME-WURSCAN-STOP request primitive (MLME-WURSCAN-STOP.request primitive), which can terminate any ongoing WUR scanning process. For example, regardless of the scanning mode in which the WTRU performs the WUR scanning process based on the WURSCanningMode parameter, the MLME-WURSCAN-STOP request primitive can terminate such a WUR scanning process. The basic MLME-WURSCAN-STOP request primitive can be generated by the SME to stop all ongoing WUR scanning processes performed by the WTRU.

[0146] 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 may be used to terminate any ongoing WUR scanning process. The WUR-SCAN-STOP request primitive may include one or more parameters, such as ScanType. As described above, the WTRU may perform multiple scanning processes (e.g., both WUR scanning processes and non-WUR scanning processes) simultaneously. The ScanType parameter may indicate the type(s) of scan that the primitive may terminate. The ScanType parameter may have any of the following values: WUR_Scan, Non-WUR_Scan, and All_Scan. If ScanType is WUR_Scan, all ongoing WUR scanning processes may be terminated. If ScanType is Non_WUR_Scan, non-WUR scanning processes, including passive scanning processes and active scanning processes, may be terminated. If ScanType is All_Scan, all ongoing scanning processes may be terminated, including WUR scans and non-WUR scans (eg, active scans and passive scans).

[0147] If a stop request primitive has been generated, then the corresponding scanning process(es) may be terminated based on the stop request primitive at 206. That is, if the WTRU or its processor receives the stop request primitive, then the corresponding scanning process(es) identified by the stop request primitive may be terminated.

[0148] The following description will describe the process at 207. As described above, method 200 may include, at 207, generating a stop confirmation primitive.

[0149] In a first embodiment, the stop confirmation primitive may be an MLME-WURSCAN-STOP confirmation primitive, which may be used to indicate the successful termination of (one or more) scanning processes (e.g., (one or more) WUR scanning processes and / or (one or more) non-WUR scanning processes). In a second embodiment, the stop confirmation primitive may be an MLME-Scan-Stop confirmation primitive or an MLME-Scan-Stop confirmation primitive or a portion thereof. The MLME-Scan-Stop confirmation primitive may be used similarly to the MLME-WURSCAN-STOP confirmation. In a third embodiment, the stop confirmation primitive may be the above-mentioned MLME-WURSCAN confirmation primitive or the MLME-SCAN confirmation primitive. That is, the MLME-WURSCAN confirmation primitive or the MLME-SCAN confirmation primitive may be used for the same purpose as the MLME-WURSCAN-STOP confirmation.

[0150] The following description will describe support for eBCS services according to the present application.

[0151] There is a need to support broadcast services for non-associated WTRUs. Furthermore, there is a need for uplink broadcast services in current WLAN standards. A design is needed to support downlink broadcast services for non-associated WTRUs or WTRUs that only receive and cannot transmit. Furthermore, a design is needed for uplink broadcasts from a WTRU to one or more APs. The broadcast service protocol and signaling can be designed to support WTRUs regardless of their association status and to support uplink broadcast services from non-AP WTRUs to one or more APs.

[0152] This document describes a mechanism for broadcast service support according to the present application. A WTRU (e.g., an AP or non-AP STA) with dot11eBCSImplemented (implemented dot11 eBCS) and / or dot11eBCSActivated (activated dot11 eBCS) may include an eBCS element in its beacon, or in a probe request / response and / or (re)association request / response frame transmitted by the WTRU. In an example, the 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 UL broadcast information and / or the DL eBCS element may be included in 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.

[0153] An example design of a DL broadcast element or DL eBCS element is Figure 3 . The DL Broadcast Element may include any one or more of the following example fields: Element ID; Length; Element ID Extension; and / or DL Broadcast Capabilities including N eBCS fields. The combination of the Element ID and Element ID 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.

[0154] The DL broadcast capabilities may include N fields (i.e., eBCS 1 to eBCS N), such that each field may be used to specify a specific broadcast service provided by a transmitting WTRU (e.g., a transmitting AP). Each eBCS field may include any one or more of the following example subfields: broadcast service ID, eBCS type, association requirements, UL transmission requirements, broadcast rate, broadcast frequency, broadcast coding, broadcast control, broadcast parameters, and / or broadcast status. These subfields are further described below.

[0155] The Broadcast Service ID subfield may indicate the ID of the broadcast service. The eBCS Type subfield may include the type of broadcast service (e.g., whether the eBCS is UL or DL, or whether the broadcast service is a category of automotive, directions, emergency, support, information, and / or event support (event_support)). In an example, a bitmap may be included in the DL Broadcast element to indicate which types of broadcast services are provided by the transmitting WTRU(s). The type may also be a multi-AP broadcast. In another example, the broadcast type may be identified by an organizationally unique identifier (OUI). The Association Required subfield may indicate whether an association is required to consume one or more broadcast services (e.g., broadcast services identified by a Broadcast Service ID).

[0156] The UL Transmission Requirement subfield may indicate whether UL transmission is required to consume one or more broadcast services (e.g., broadcast services identified by a 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 being transmitted. The Broadcast Coding subfield may indicate the encoding of the broadcast data packet (e.g., inter-frame BCC binary convolutional code (BCC), inter-frame low-density parity check (LDPC), hybrid automatic repeat request (HARQ) convolutional code (CC), HARQ incremental redundancy (IR)).

[0157] The Broadcast Control subfield may indicate how the broadcast service is to be controlled. For example, the Broadcast Control subfield may indicate that if the WTRU desires a certain broadcast service, the WTRU needs to negotiate directly with the transmitting WTRU (e.g., a transmitting AP) by using, for example, a Broadcast Request frame. In another example, the Broadcast Control subfield may indicate a server address (e.g., an IP address of a server) or a controller AP address (e.g., a MAC address or BSSID of another AP). Such a controller AP may be the master AP of a multi-AP set. The WTRU may also communicate with the controller AP or server to provide feedback on the broadcast service or negotiate a rate or encoding. Example methods for control may be through WLAN, Transmission Control Protocol / Internet Protocol (TCP / IP), Broadcast Request negotiation, ANQP, and / or Generic Advertising Service (GAS) frame exchange.

[0158] The Broadcast Parameters subfield may include one or more broadcast parameters, including Offset, Channel, etc. For example, Offset may indicate the offset of the start of the next broadcast packet or broadcast burst, which may be from the end of the current transmission, or from the target beacon transmission time (TBTT) or other reference point. Channel may indicate the channel or OFDMA subchannel or resource unit (RU) on which the broadcast service packet is available.

[0159] The broadcast status subfield may indicate the current broadcast status, such as broadcasting, paused, or to be started.

[0160] Example designs for UL broadcast elements or UL eBCS elements are in Figure 4 . The UL Broadcast Element may include any one or more of the following example fields: Element ID; Length; Element ID Extension; and / or UL Broadcast Information including N eBCS fields. It should be noted that in this application, unless otherwise indicated, the terms UL Broadcast Element, UL eBCS Element, and UL Broadcast Capabilities Element may be used interchangeably.

[0161] The combination of the Element ID and the Element ID 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 (i.e., eBCS 1 to eBCSN), such that each field may be used to specify a specific UL broadcast service supported by the transmitting WTRU. Each eBCS field may include any one or more of the following example subfields: Allowed Broadcast Service ID; Allowed eBCS Type; Association Requirements; DL Reception Requirements; Allowed Broadcast Rate; Allowed Broadcast Frequency; Broadcast Coding; Broadcast Control; Broadcast Parameters; and / or Broadcast Status. The above subfields are further described below.

[0162] The Allowed Broadcast Service ID subfield may indicate the IDs of the UL broadcast services supported and allowed by the transmitting WTRU. The Allowed eBCS Type subfield may include the types of allowed broadcast services (e.g., whether the allowed eBCS is UL or DL, or whether the broadcast service is a category of automotive, sensor, direction, emergency, support, information, and / or event support). In an 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 broadcast type may be identified by an OUI or a server address. The Allowed eBCS Type subfield may include a detailed description of the provided broadcast services.

[0163] Association Requirement Subfield ( Figure 4 The DL Reception Requirement subfield (not shown) may indicate whether association is required to utilize one or more allowed UL broadcast services (e.g., broadcast services identified by allowed broadcast service IDs). Figure 4 (not shown) may indicate whether DL reception is required in order to use one or more allowed UL broadcast services (eg, broadcast services identified by allowed broadcast service IDs).

[0164] The Allowed Broadcast Rate subfield may indicate the allowed data rates for the WTRU(s) to transmit in the UL associated with the broadcast service. The Allowed Broadcast Frequency subfield may indicate the allowed frequencies on which the WTRU is allowed to broadcast data in the UL associated with the allowed broadcast service. The Broadcast Coding subfield may indicate the coding to be used for UL broadcast data packets, e.g., Inter-frame BCC, Inter-frame LDPC, HARQ CC, HARQ IR.

[0165] The broadcast control subfield may indicate a method for controlling the UL broadcast. For example, the broadcast control subfield may indicate how the broadcast service is controlled (e.g., indicating the destination of the allowed UL broadcast services). For example, it may indicate that if the WTRU desires to use certain UL broadcast services, the WTRU needs to negotiate directly with the transmitting WTRU (e.g., the transmitting AP) by using, for example, a broadcast request frame. In another example, the broadcast control subfield may indicate a server address (e.g., an IP address of a server) or a controller AP address (e.g., a MAC address or BSSID of another AP). Such a controller AP may be the master AP of a multi-AP set. The server or controller may be contacted by a WTRU that desires to utilize an uplink broadcast service to obtain feedback or negotiate the MCS to be used. For example, the method for control may be exchanged via WLAN, TCP / IP, broadcast request negotiation, ANQP, or GAS frames.

[0166] The broadcast parameter subfield may include one or more broadcast parameters, including UL access such as EDCA, triggered broadcast access, uplink OFDMA random access. For example, if the broadcast parameter is triggered broadcast access, the WTRU utilizing the uplink broadcast service may transmit uplink broadcast packets only when it is triggered by the AP. For example, the AP may be triggered on one or more subchannels or RUs. In the triggering frame or triggered frame, it may be specified that uplink broadcast data is triggered and / or transmission from unassociated WTRUs is triggered. If the broadcast parameter is uplink OFDMA random access, the WTRU utilizing the uplink broadcast service may transmit uplink broadcast packets only when it is triggered by a triggered frame or triggered frame, wherein the triggering frame or triggered frame triggers uplink random access on one or more RUs. The broadcast status subfield may indicate the current broadcast status, such as broadcast, paused, or to be started.

[0167] In an embodiment, as described above, the UL and DL broadcast elements may be combined into one broadcast element or eBCS element. In another embodiment, the information included in the UL and DL broadcast elements may be included as part of an ANQP element. Additionally, any subset of the UL and DL broadcast elements may be transmitted in any other type of frame, or in any other type of element, MAC and PHY headers, etc.

[0168] The DL broadcast process according to the present application will be described below.

[0169] First, a WTRU (i.e., a non-AP WTRU) that desires a DL broadcast service may include a DL Broadcast Element in a frame it transmits, such as a Probe Request frame, an ANQP frame, or a GAS Query frame. 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 subfields described for a DL Broadcast Element that describes the desired DL broadcast service.

[0170] Second, the AP may include a DL Broadcast Element or eBCS Element in its beacon, a probe response, an association response, an ANQP response frame, a GAS response frame, or any other type of frame. In an example, the AP may only include a DL Broadcast Element if it has received a frame from the WTRU soliciting a DL Broadcast Element (e.g., when it has received a frame including a DL Broadcast Element or eBCS Element indicating a desired DL broadcast service, such as an ANQP frame, a GAS query frame, or a probe request frame). When transmitted by the AP, the DL Broadcast Element may indicate the DL broadcast services provided by the AP.

[0171] Third, a WTRU receiving a DL broadcast element (i.e., a non-AP WTRU) may identify one or more desired broadcast services provided by the AP. The non-AP WTRU may follow the instructions indicated in the DL broadcast element, such as association if required. If the broadcast status indicates that a broadcast service is currently being broadcast, the non-AP WTRU may follow the broadcast control and parameter information (e.g., tune to the correct RU, subchannel, or channel at the correct offset to receive one or more broadcast service packets using the indicated broadcast mode or coding).

[0172] If the broadcast status indicates that the broadcast service is suspended or is to be started, the non-AP WTRU may follow the instructions included in the DL broadcast element to resume or start the broadcast service. For example, if the broadcast control should be "negotiate with AP", the WTRU may associate with the AP and then make a broadcast service request to the AP. In another example, the WTRU may not be associated with the AP, but use ANQP query or GAS protocol to resume or start the DL broadcast service. If the broadcast control is indicated as "negotiate with controller AP or server" over "WLAN" or "TCP / IP", the WTRU may associate with the controller AP and then make a broadcast service request to the AP while indicating the best AP for the broadcast service; or the WTRU may use a TCP / IP connection to contact the server to resume or start the desired broadcast service while indicating the best AP that should provide the broadcast service.

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

[0174] The UL broadcast process according to the present application will be described below.

[0175] First, a WTRU (i.e., a non-AP WTRU) that desires to utilize one or more UL broadcast services may include a UL Broadcast Element in a frame it transmits, such as a Probe Request frame, an ANQP frame, or a GAS Query frame. When transmitted by a non-AP WTRU, the UL Broadcast Element may indicate information or parameters of the desired UL broadcast service. In another example, a non-AP WTRU may include a UL Broadcast Request Element that may include one or more subfields described for the UL Broadcast Element describing the desired UL broadcast service.

[0176] Second, the AP may include a UL Broadcast Element or eBCS Element in its beacon, a Probe Response, an Association Response, an ANQP Response frame, or a GAS Response frame, or any other type of frame. The AP may include a DL Broadcast Element if it has received a frame from the WTRU soliciting a DL Broadcast Element (e.g., when it has received a frame including a UL Broadcast Element or eBCS Element indicating the desire for a UL broadcast service, such as an ANQP frame, a GAS Query frame, or a Probe Request frame). When transmitted by the AP, the UL Broadcast Element may indicate the UL broadcast services supported and allowed by the AP. The AP may provide policies regarding the supported and allowed UL broadcast services, such as the allowed broadcast rates, allowed broadcast frequencies, or allowed UL broadcast methods, such as triggered broadcast, uplink OFDMA random access, or EDCA.

[0177] If the broadcast state is Accept Broadcast, the non-AP WTRU may begin broadcasting its UL data if it has received a frame from the AP (e.g., a beacon, probe response, or association response, or FILS discovery frame) that 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 broadcasts, such as using the allowed broadcast rate, broadcast frequency, and / or uplink broadcast method. If the broadcast state is Pause or To Be Started, the non-AP WTRU may use the broadcast control method indicated to negotiate directly with the AP, or contact the controller AP or server using a broadcast control method (e.g., WLAN, TCP / IP) to resume or start the UL broadcast service provided by the AP.

[0178] The WTRU may then use broadcast control methods to further negotiate broadcast services such as coding, MCS, or repetition.

[0179] The following description will describe how to improve broadcast reliability according to the present application.

[0180] Broadcast packets may be transmitted to multiple WTRUs, such as in the downlink case. Channel conditions, as well as device capabilities and sensitivities, may vary from WTRU to WTRU. Therefore, the reliability of receiving broadcast packets may not be the same at all receiving WTRUs. Broadcast reliability is particularly important for WTRUs that are not relevant or cannot transmit. Therefore, the broadcast protocol and broadcast packets may be designed so that broadcast services are reliably provided to all WTRUs.

[0181] This document describes a mechanism for improving broadcast reliability according to the present application. An example mechanism for broadcast reliability is inter-frame coding, such as BCC and LDPC. A broadcast node (e.g., an AP) can transmit a frame containing systematic bits or parity bits from previously transmitted frames, encoded and interleaved together. The data in the original frame can be BCC or LDPC encoded. In a first example, the data in the new subframe can include coded data from previously transmitted frames that are linearly encoded together, which is called inter-frame BCC or LDPC decoding. In this case, the reliability of the additional bits after decoding becomes higher. In a second example, the data in the new subframe can include coded data from previously transmitted frames that are concatenated and interleaved together. This can be described as partial frame HARQ. In this case, HARQ retransmissions are not transmitted by themselves, but are transmitted together with HARQ retransmissions from other frames. This can help reduce the latency of broadcast transmissions. The following description will describe the above two examples in detail.

[0182] Figure 5 and Figure 6An example of LDPC inter-frame coding with sequentially increasing increments is shown. Figure 5 As shown, after constructing data bits and parity bits by discarding shortened bits in the LDPC encoding process, the LDPC inter-frame encoding process can be started, thereby generating a packet with a length of Nmax. Figure 5 The rate RH frame shown in may include N bits, and the D (unequal) equal increments may include D increment subframes from Δ1 to ΔD.

[0183] Nmax can be based on the length of the packet to be sent (N), the number of incremental subframes (D) and their corresponding lengths (Δ i ) to determine. Each incremental subframe can be set to a different length so that If the length of each incremental subframe is the same, then Nmax = N + DΔ i The original transmission of each frame will be N bits (such as Figure 5 As shown), the incremental subframe (e.g., Δ1-ΔD) may consist of additional (unpunctured) parity bits. Figure 6 In the example shown, the incremented index may be random and may not increase sequentially.

[0184] Figure 7 An example of BCC interframe coding is shown. In the case of BCC interframe coding, for BCC transmission, the original transmission of each frame has N unpunctured bits (e.g., Figure 7 ), and increment subframes (e.g., Figure 7 Δ1 and Δ2) shown in can be composed of other punctured bits. Figure 7 As shown, the source data may include x0, x1, x2, x3 and x4; the encoded data may include A0-A4 and B0-B4; a rate RL frame with unequal increments for BCC may include N bits (including A0, B0, A1, B2, A3, B4), Δ1 (including B1, A2 and B3) and Δ2 (A4 and A0).

[0185] Procedures for inter-frame BCC / LDPC transmission and partial packet HARQ of BCC / LDPC codes may be defined. Figure 8 An example of inter-frame coding and partial HARQ with fixed index is shown. The AP may define the transmission of NT+D frames (i.e., NT frames and D frames). The first NT transmissions (i.e., 1 to NT) are intra-frame coded frames consisting of N bits per frame. Figure 8 As shown, intra-frame coding includes NT frames from frame 1 to frame NT. The last D transmissions are inter-frame coded subframes composed of a combination of D increments from each frame.

[0186] In an embodiment, the D subframe increments of each frame can be concatenated and then transmitted. This enables partial HARQ transmission. In another embodiment, the D increments of each frame can be linearly encoded using a specific coding scheme.

[0187] For each transmitted frame, one or more of the following information may be signaled (e.g., in a PLCP header): intra- or inter-frame coding, an index of an intra-coded frame, an index of an inter-coded frame (in the following examples, this may be index a in delta(a,b) and / or may be explicitly signaled or implicitly identified based on the frame index after the start of the entire transmission), or an index of a frame encoded in a delta subframe (in the following examples, this may be index b in delta(a,b) and / or may be explicitly signaled or implicitly identified based on the number of frames in the transmission). In cases where the indexes may have different sizes, the size of the delta for each frame from the delta subframe may be signaled.

[0188] Figure 9 An example of inter-frame coding with sliding window and partial HARQ is shown. Figure 9 As shown, incremental subframes can be aggregated (e.g., as an aggregated PPDU) onto the transmitted frame. For example, each frame can aggregate incremental subframes from the frame before it, up to a maximum number of incremental subframes. Figure 9 As shown, frame 2 aggregates the first delta subframe (i.e., Δ1, 1) from frame 1. Frame 3 aggregates the second delta (i.e., Δ2, 1) from frame 1 and the first delta (Δ1, 2) from frame 2. Frame 4 aggregates deltas from frames 1, 2, and 3. Frame 5 aggregates deltas from frames 2, 3, and 4 because the value of D (the number of deltas) is 3.

[0189] like Figure 10 As shown, the deltas that are transmitted may be dynamically selected. For example, this approach may be used in situations where the WTRU may have feedback on a frame that has been poorly received. The broadcast AP may dynamically select specific frames to transmit the delta information. The broadcast AP may dynamically select the size of the delta to be sent based on the quality of the broadcast signal required (some frames may require more protection than other frames). In an example, (one or more) WTRU feedback indicates that the reception of a particular frame is very poor. For example, if the majority of the (selected) WTRUs indicate that the frame reception is poor, they may need more information. In another example, the WTRU may send more information on frames that can be sent earlier to ensure that they are decoded faster, thereby reducing the overall latency.

[0190] The WTRU process may be defined as part of inter-frame coding. As part of an example WTRU process, the AP and the WTRU may exchange capability information regarding the ability to receive inter-frame coding. The capability information may include the maximum number of frames that can be decoded simultaneously. The AP may use the capability information to decide on the inter-frame coding parameters for the broadcast channel. For example, the AP may set the number of simultaneous frames to a minimum value indicated by all receiving WTRUs (e.g., a discrete, predetermined value and / or a WTRU-specific set). The WTRU may receive the frame and decode the received PLCP header. The WTRU may identify whether the received frame is inter-frame coded. The WTRU may identify whether the packet is intra-frame, inter-frame, or both. If the packet is intra-frame coded, the WTRU may decode the frame. If the decoding is successful, the WTRU may send an ACK to the AP and / or terminate the decoding process for the frame as needed. If the decoding is unsuccessful, the WTRU may store the frame in a buffer.

[0191] If the packet is inter-frame coded, the WTRU may decode / deinterleave / deaggregate the incremental subframes in the frame. The WTRU may identify the incremental subframes based on explicit or implicit signaling. The WTRU may discard the incremental subframes of all frames that have been successfully decoded. The WTRU may process the incremental subframes of all undecoded frames by adding the received incremental subframe information to the existing frame buffer and then decode the results. If the decoding is successful, the WTRU may send an ACK to the AP and / or terminate the decoding process for the frame as needed. If the decoding is unsuccessful, the WTRU may store the frame in the buffer. The WTRU may send a NAK to the AP or wait until the total number of incremental subframes is received before sending a NAK. Because the channel is a broadcast channel, the ACK / NAK transmission may be based on the AP's request to a specific WTRU, rather than all WTRUs being transmitted to. In an example, the WTRU may send the ACK / NAK on a specific (sub)channel, and the presence of the signal on the subchannel may inform the AP of the success / failure.

[0192] If the packets are both intra-coded and inter-coded, the WTRU may separate the intra packets from the inter packets and then process each packet separately using the method described above.

[0193] In HARQ broadcasts, a broadcast frame may be transmitted multiple times or repeated. In an example process, the repeated transmissions may be identical to the original transmission so that the receiver can easily combine the receptions. Signaling may be used to enable the receiving WTRU to combine the received frames. For example, one or more of the following information (fields) may be included in the PLCP header, MAC body, and / or beacon frame: ID, Broadcast, Repeat Transmission, Repeat Index, Next Repeat Frame, or Next Repeat Beacon. These fields are further described below.

[0194] The ID field can indicate any of the destination ID, source ID, transmitter ID, receiver ID, broadcast ID, broadcast channel ID, and / or content ID. The broadcast field can be used to indicate whether this is a broadcast frame, a multicast frame, and / or a unicast frame. The repeat transmission field can be used to indicate whether the frame is transmitted in a repeated manner. The repeat transmission field can also indicate the type of repetition used (e.g., simple repetition or inter-frame coding).

[0195] The Repeat Index field may indicate the number of repetitions for the current transmission. For example, the Repeat Index field may be transmitted in an incrementing manner. In another example, the Repeat Index field may be transmitted in a decrementing manner so that the receiving WTRU can be aware of the number of subsequent repetitions. The Next Repeat Frame field may indicate the expected time of the next repetition of the frame. The Next Repeat Frame field may also indicate the type of repeat frame to be sent at that time. The Next Repeat Beacon field may indicate the expected time of the next repeat beacon. In an example, the expected time may be a duration.

[0196] In an embodiment, the broadcast frame may be transmitted multiple times or in a repetitive manner with some diversity scheme. For example, the repeated transmission may be different from the original transmission. In this case, one or more of the following methods may be used.

[0197] In the first method, different bit interleavers can be used for different repetitions. The bit interleaver can be used between the BCC encoder and the constellation mapper. In the example, multiple bit interleavers can be defined. For example, the number of bit interleavers can 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 can be defined. The mapping between interleaver index and repetition can be defined by a function. For example, a modular function can be used. The interleaver index for the kth repetition can be defined as Interleaver_ID = mod (k, N), where N is the maximum number of defined interleavers. The bit interleaver may or may not be used for LDPC codes. In the example method, a bit interleaver can be defined for repeated transmission.

[0198] In the second method, different symbol interleavers can be used for different repetitions. For example, a symbol-level interleaver can be used immediately after the constellation mapper. The use of a symbol-level interleaver can be to distribute modulation symbols between OFDM symbols. In an example, a fixed number of symbol interleavers can be defined. The mapping between interleaver index and repetition can be defined by a function. For example, a modular function can be used. The symbol interleaver index for the kth repetition can be defined as Interleaver_ID=mod(k, N), where N is the maximum number of symbol-level interleavers defined.

[0199] In a third approach, different redundancy versions (RVs) can be used for different transmissions. Different RVs can correspond to different subsets of the decoded bits. The mapping between RV indexes and repetitions can be defined by a function. For example, a modular function can be used. The RV index for the kth repetition can be defined as RV_ID = mod(k, N), where N is the maximum number of defined RVs.

[0200] Diversity broadcast transmissions may be signaled in the PLCP header, MAC header, or MAC body and may include one or more of the following example fields: ID, Broadcast, Repeat Transmission, Maximum Number of Repetitions, Repeat Index, Transmission Index, or Next Repeat Beacon / Timing. The above example fields are further described below.

[0201] The ID field may indicate the destination ID, source ID, transmitter ID, and / or receiver ID. The Broadcast field may be used to indicate whether this is a broadcast frame, a multicast frame, and / or a unicast frame. The Repeat Transmission field may be used to indicate whether the frame is transmitted in a repeated manner. The Maximum Repetitions field may indicate the maximum number of repetitions expected. The Repeat Index field may indicate the number of repeated transmissions for the current transmission. In one example, the Repeat Index field may be transmitted in an ascending manner. In another example, the Repeat Index field may be transmitted in a descending manner so that the receiving WTRU can be aware of the number of subsequent repeated transmissions.

[0202] The Transmission Index field may be used to signal the bit-level interleaver index, symbol-level interleaver index, and / or RV index to be used in subsequent transmissions. The Next Repeat Beacon / Timing field may indicate the expected time of the next repeat beacon / timing. In an example, the expected time may be a duration. The duration may be a function of the WTRU's ability to allow each WTRU to independently decode each transmission. In another example, the expected time may be immediate, indicating that the next repetition occurs an interframe space (xIFS) duration after the end of the current transmission.

[0203]

[0014] The procedure may be used to exploit power savings in broadcast service (BCS) reception. The WTRU may receive a PLCP header with a repetition ID. In an example, the PLCP header may contain the total number of repetitions and a repetition index. The WTRU may save all repetitions and decode them after the last reception. The WTRU may decode after each repetition. The AP(s) and WTRU(s) may negotiate a minimum inter-repetition duration to allow decoding of the packet after each repetition.

[0204] If the WTRU has decoded the packet, it may go to sleep for the duration of the transmission. Figure 11An example power saving process with xIFS interframe spacing between repetitions is shown that can be used for BCS. Figure 11 As shown, WTRU1 decodes packets during Tx1 and then it may sleep until Tx4.

[0205] If the WTRU has decoded the packet and the inter-repetition duration is immediate, the WTRU may go to sleep for the duration of the specific repetition. Figure 12 An example of a power saving procedure with a specific timing difference between repetitions that can be used for BCS is shown. Figure 12 As shown, WTRU1 decodes packets during Tx1 and then it may sleep during Tx2, Tx3, and Tx4.

[0206] In an embodiment, feedback-based retransmissions may be used. A maximum number of retransmissions may be predefined or (re)determined. The maximum number of retransmissions may be carried and signaled in a beacon frame, a (re)association frame, a probe request / response frame, or any other type of management / control frame. A WTRU (e.g., an AP WTRU or a non-AP WTRU) may not always reach the maximum number of retransmissions. The WTRU may terminate retransmissions based on feedback. For example, if the WTRU receives a positive acknowledgment (ACK) from another WTRU that may be located far away from the WTRU, the WTRU may stop retransmissions.

[0207] In an embodiment, repeated transmissions may be separated by at least a predefined interframe space xIFS. In one approach, xIFS may be greater than the short interframe space (SIFS) or the distributed interframe space (DIFS). In an embodiment, the interframe space between each retransmission may be dynamic and configurable. If the WTRU successfully receives (one or more) repeated broadcast transmissions, the receiving WTRU may in some cases reply with a positive acknowledgment. The acknowledgment may be transmitted before the next repetition so that the broadcast WTRU can receive the acknowledgment before transmitting the next repetition. The broadcast WTRU may determine whether it can terminate the repeated transmission. In an embodiment, a group of WTRUs may be allowed to transmit the acknowledgment. For example, the broadcast WTRU may determine a group of WTRUs that may be far away from itself. The broadcast WTRU may indicate in a management frame or a control frame that the group of WTRUs may be allowed to transmit acknowledgments between repeated broadcast transmissions. The group of WTRUs may transmit back identical acknowledgments simultaneously so that they may be aligned on the receiver side and the receiver may be able to decode them.

[0208] In an embodiment, a poll frame or MU-BAR frame may be transmitted before or after a repeated transmission. Alternatively, an NDP trigger frame may be aggregated with a broadcast frame. A poll frame, MU-BAR frame, or NDP trigger frame may trigger an acknowledgment transmission from one or more WTRUs. If a receiving WTRU successfully receives (one or more) repeated broadcast transmissions, the receiving WTRU may be polled or triggered and may reply with a positive acknowledgment. The broadcast WTRU may receive the positive acknowledgment and determine whether it can terminate the repeated transmission.

[0209] The broadcast WTRU may determine whether it can terminate repetitions. Alternatively, the broadcast WTRU or the AP may configure whether the broadcast WTRU can terminate repetitions. In an embodiment, this configuration may be based on whether the broadcast frame is targeted at associated WTRUs or unassociated WTRUs. If the frame can be delivered to unassociated WTRUs or partially delivered to these unassociated WTRUs, the broadcast WTRU may not terminate the repetition transmission early.

[0210] The maximum number of repetitions may be determined or otherwise specified by the AP. The AP may broadcast the maximum number of repetitions in its beacon, association request / response, probe request / response frames, or other types of control / management frames. In an embodiment, the AP may determine to use a larger maximum number of repetitions if the BSS may have a large coverage area or if the AP may be aware of many cell-edge WTRUs. Otherwise, the AP may use a smaller maximum number of repetitions. Figure 13 An example of repeated transmission with feedback is shown. Figure 13 As shown, during Tx1, WTRU1 receives a transmission from the AP, but WTRU2 and WTRU3 do not. Therefore, WTRU2 and WTRU3 may send a NAK to the AP. A repeat transmission may then be performed during Tx2. WTRU2 then successfully receives the transmission. However, WTRU3 does not receive it. A repeat transmission may then be performed during Tx3. WTRU3 then receives the transmission.

[0211] In an embodiment, multi-AP broadcast transmission can be used for reliability. The WTRU can be associated with a single or multiple APs (associated WTRUs). The AP can issue a broadcast to a set of APs (associated WTRUs and unassociated WTRUs). The AP can identify the broadcast resources (e.g., the entire frequency band, defined RUs). The AP can issue a broadcast channel (BC) transmission scheme. For example, the AP can send a cyclic shift diversity (CSD) with an indication of the APID, the corresponding shift and / or cyclic prefix (CP). The AP can send a CSD with the same offset and CP. The AP can send a slot-based transmission (e.g., a time shift with a timing index). The AP can use a "JT" method (e.g., a suffix tree clustering (STC) method and indexing). Figure 14An example of multi-AP broadcasting with CSD is shown. Figure 15 An example of multi-AP broadcasting with timing separation is shown. Figure 16 An example of multi-AP broadcasting with a spatial transmit diversity scheme (eg, space-time block code (STBC)) is shown.

[0212] In an embodiment, repeated transmissions may be used for broadcast / multicast frames. For example, repeated transmissions of broadcast / multicast frames may be used with different self-decodable RVs, different bit-level interleavers, different symbol-level interleavers (equivalent to changing subcarrier mapping), and / or SIGs indicating broadcast, PAID (e.g., association ID), RV, HARQ, interleaver ID, and / or next timing.

[0213] In an embodiment, feedback-based repeated transmissions may be used. For example, repeated transmissions may be separated by at least a fixed duration (e.g., xIFS). xIFS may be greater than SIFS or DIFS. Feedback-based repetitions may include the use of polling / multi-user block ACK requests (MU-BARs). If a transmission is successfully decoded, some WTRUs may be allowed to send back an acknowledgment before the next repetition. In an embodiment, preselected distant WTRUs may transmit an acknowledgment (e.g., using the near-far procedure in 802.11ay). The AP that successfully receives the acknowledgment may terminate the transmission in some cases. The AP may periodically complete a complete repetition for unassociated WTRUs. The BCS transmission parameters (for associated WTRUs) may be generalized, and / or TCP / IP may be configured for unassociated / non-transmitting WTRUs via (one or more) probe requests. The ACK may specify a WTRU, a WTRU group, a null data packet (NDP) feedback report, and / or a random access MU.

[0214] If the AP subnet is configured to send the same broadcast information from multiple APs, with or without automatic repetition (AR) configured for the frames being sent, the WTRU receiving these sent frames must be able to identify frames that contain the same broadcast data or incremental redundant versions of the broadcast data. In this case, the WTRU can improve its reception of the broadcast data by combining frames when appropriate or ignoring redundant frames that contain data that has already been received. For the case where the AR is a simple repetition (redundant versions of the same frame are sent from multiple APs), the WTRU must have a means of knowing whether it has already received the data to ignore the redundant frames or whether it has not received the data. The WTRU should know how to combine frames to increase the likelihood that the data can be received. For the case where the AR has incremental redundancy (IR) frames, the WTRU must have a means of knowing how it should combine incremental redundant frames, combine frames with the same data, and ignore frames containing data that has already been received. Currently, there is no way to inform the WTRU that frames sent by different APs contain the same broadcast data or IR versions of data that the WTRU is trying to receive.

[0215] The following description will describe subnet scheduling to solve the above problems.

[0216] A subnet of an AP may be configured to broadcast the same information from multiple APs. This subnet may use methods to notify the WTRU of broadcasts from multiple APs containing broadcast data. Since each AP is a unique transmission source, a variety of methods may be used. In an example method of notifying the WTRU of broadcast data, the AP subnet may coordinate to use the same broadcast ID information. The AP may use one or more of the following information fields (e.g., in a PLCP header, MAC header, MAC body, and / or beacon frame) to provide the broadcast ID information: Multi-AP Indicator, Topic ID, ID, Broadcast, Repeat Transmission, Repeat Index, Next Repeat Frame, or Next Repeat Beacon. The above fields are further described below.

[0217] The Multi-AP Indicator field may indicate that the frame and its associated ID(s) are being broadcast by multiple APs. The Subnet ID field may provide a unique ID for the subnet, and all APs in the subnet may use the same identifier. Subnets may coordinate to ensure that different subnets with overlapping service areas have unique subnet IDs. In an example, the subnet ID may be based on the MAC address of one of the APs in the subnet. In another example, a hash of the SSID, a hash based on the location of the AP, a unique subnet ID assigned by the network / subnet administrator, or any other unique ID may be used.

[0218] The ID field can indicate the destination ID, source ID, transmitter ID, receiver ID, broadcast ID, broadcast channel ID, and / or content ID. The broadcast field can be used to indicate whether this is a broadcast frame, a multicast frame, and / or a unicast frame. The repeat transmission field can be used to indicate whether the frame is transmitted in a repeated manner. The repeat transmission field can also indicate the type of repetition being used (e.g., simple repetition or interframe coding).

[0219] The Repeat Index field may indicate the number of repetitions of the current transmission. In an embodiment, the Repeat Index field may be transmitted in an ascending manner. In another embodiment, the Repeat Index field may be transmitted in a descending manner so that the receiving WTRU(s) may be aware of the number of subsequent repetitions. The Next Repeat Frame field may indicate the expected time of the next repetition of the frame. The Next Repeat Frame field may also indicate the type of repeat frame to be sent at that time. The Next Repeat Beacon field may indicate the expected time of the next repeat beacon. In an example, the expected time may be a duration.

[0220] The AP may coordinate and select a virtual SSID and / or MAC address that all APs in a subnet will use for broadcasts (e.g., a specific broadcast or a specific set of broadcasts). The APs in a subnet may all transmit the same SSID information (e.g., virtual SSID and / or MAC address). By transmitting the same SSID information, these APs will appear as a single broadcast AP to any WTRU that receives broadcast frames sent by the APs in the subnet. APs using virtual SSIDs and / or MAC addresses 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 the broadcast ID information: Virtual SSID Indicator, Virtual MAC Address, ID, Broadcast, Repeat Transmission, Repeat Index, Next Repeat Frame, and / or Next Repeat Beacon. The above fields are further described below.

[0221] The Virtual SSID Indicator field can be a single bit indicating that the SSID is a virtual SSID, or it can be multiple bits providing information about the type of virtual SSID being indicated. The Virtual MAC Address field can be a single bit indicating that the AP MAC address is a virtual MAC address, or it can be multiple bits providing information about the type of virtual MAC address being indicated.

[0222] The ID field can indicate the destination ID, source ID, transmitter ID, receiver ID, broadcast ID, broadcast channel ID, and / or content ID. The broadcast field can be used to indicate whether this is a broadcast frame, a multicast frame, and / or a unicast frame. The repeat transmission field can be used to indicate whether the frame is transmitted in a repeated manner. The repeat transmission field can also indicate the type of repetition being used (e.g., simple repetition or inter-frame coding).

[0223] The Repeat Index field may indicate the number of repetitions for the current transmission. In an embodiment, the Repeat Index field may be transmitted in an ascending manner. In another embodiment, the Repeat Index field may be transmitted in a descending manner so that the receiving WTRU(s) may be aware of the number of subsequent repetitions. The Next Repeat Frame field may indicate the expected time of the next repetition of the frame. The Next Repeat Frame field may also indicate the type of repeat frame to be sent at that time. The Next Repeat Beacon field may indicate the expected time of the next repeat beacon. In an embodiment, the expected time may be a duration.

[0224] The procedure may be used for UL broadcast reliability. In a DL broadcast, there may be multiple transmitters and receivers, and each receiver may represent a broadcast service endpoint located within a non-AP WTRU. This may complicate the MAC layer CSMA / ARQ protocol used for broadcast data, as different transmitter-receiver pairs may have different success / failure states. For example, the AP may need to know the identity of the (unassociated) broadcast receiver to assign feedback resources in the UL direction. In addition, the AP may need to coordinate between them to know which MAC PDU (MPDU) / data block is lost for at least one WTRU before a retransmission attempt is made.

[0225] UL broadcast reliability may also be an issue. Figure 17 As shown, the UL WTRU 1701 is unaware of the receiver status (or statistics of received Physical Layer Convergence Procedure (PLCP) Protocol Data Units (PPDUs) over time), which is shown as "Does the WTRU have information about whether the PPDU was successful without input from upper layers?" An example requirement for the transmitted data may be that lost data is not tolerated and retransmissions are required for lost data. In this case, without knowledge of the 802.11 protocol layer, the UL WTRU 1701 may need to associate with the BSS (or connect to another access) to have a unicast data connection to trigger retransmissions. Another example requirement for the transmitted data may be that lost data is tolerated but not desired. In this case, feedback from the receiver may improve the quality of future transmitted PPDUs.

[0226] In an UL broadcast, the different receivers of the UL broadcast packet represent a single broadcast endpoint, and there is only a single transmitter (i.e., there is a single (joint) receiver state for the single transmitter to act). This makes the MAC layer CSMA / ARQ protocol more likely in the UL. This helps to eliminate over-the-air errors or improve the robustness of later transmitted data (retransmissions or new), and the non-AP WTRU does not need to rely solely on the unicast connection to the broadcast aggregation node via upper layers to provide robustness.

[0227] The example procedures for UL broadcast transmissions may be applied on a per-PPDU basis (e.g., may be applied to feedback for a duration following a UL broadcast transmission and for a duration during which the 802.11 MAC's UL transmitter retains information that may need to be repeated). The UL WTRU may base the UL broadcast transmission on the feedback to adjust the robustness of the PPDUs sent after the feedback without performing retransmissions of lost data. The example procedures for UL broadcast transmissions may be applied to non-broadcast PPDUs sent in the UL direction in a multi-AP setup where one AP is the anchor AP or master AP and the other APs are secondary receivers for the anchor AP or slave APs.

[0228] Figure 18 An example of a transmitter obtaining joint feedback is shown as a means of providing feedback to improve robustness. In the UL broadcast packet requesting feedback, the transmitting WTRU 1801 may indicate the MCS, scrambler enable, and / or a longer guard interval (GI) to be used in the requested DL feedback. In an embodiment, a predetermined MCS / GI may be used for the feedback PPDU in the DL, and / or the feedback PPDU scrambler enable may be set to the same value as in the requested UL broadcast PPDU.

[0229] In an embodiment, the UL broadcast PPDU may indicate one or more APs that are allowed to perform feedback to limit the delay spread of the feedback signal. If the transmitting WTRU does not receive any feedback, the transmitting WTRU may infer that all APs are busy / interfered and may perform a delayed (re)transmission. If the WTRU does not use the feedback process to perform retransmissions (i.e., no retransmissions are performed for broadcast PPDUs), the WTRU may adjust the robustness of its transmission (e.g., power, MCS) for future PPDUs to be sent based on the feedback. If multiple APs successfully receive the UL broadcast PPDU, their feedback frames may be combined over the air and decoded as a single PPDU at the non-AP WTRU.

[0230] Figure 19 Another example process for an AP to provide DL feedback is shown, allowing the transmitter to obtain joint feedback (e.g., for each MPDU / data block in one or more aggregated MPDUs (AMPDUs) transmitted in the UL). A mechanism may be used that allows transmission of AMPDUs without requiring a prior exchange to establish a feedback agreement. This unsolicited feedback protocol may be used for UL broadcasts. The parameters of the protocol (e.g., buffer size, timeout value) may be set to predetermined values for all WTRUs supporting UL broadcasts.

[0231] In order to receive a single joint feedback bitmap corresponding to the data block / MPDU, an NDP feedback method may be used, for example, using on-off keying based on positive feedback. A set of tones indicating state 0 may not be transmitted, while a set of tones indicating state 1 may be transmitted by the AP. The NDP long training field (LTF) may include a longer GI to cover differences in propagation delay from different APs to the initiator / transmitter (i.e., non-AP WTRU 1901).

[0232] The UL broadcast PPDU may indicate a starting sequence number. The ACK signal on each tone set may represent feedback bits for an MPDU / data block having a sequence number offset relative to the starting sequence number. Based on the energy of the tone set, the initiator / transmitter (i.e., non-AP WTRU) may derive the reception status of the MPDU / data block sequence number based on the corresponding tone set index.

[0233] Because NDP feedback can be on-off keying based on positive feedback, the initiator can treat the feedback NDP triggered by the UL broadcast PPDU as a single NDP. When the initiator detects the NDP, the corresponding lost MPDU / data block can be retransmitted. If no NDP is detected, the initiator can infer that all receivers (e.g., AP) are interfered / busy and can perform a delayed (re)transmission. If the UL WTRU does not use the feedback process to perform retransmissions (i.e., no retransmissions are performed for broadcast PPDUs), the WTRU can transmit based on the feedback to adjust the robustness of future PPDUs to be sent (e.g., power, MCS).

[0234] Although the features and elements are described above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for use in a station (STA), the method comprising: generating, by a station management entity (SME), a request primitive that enables a wake-up radio (WUR) scanning procedure for WUR discovery frames transmitted by one or more access points (APs), the request primitive comprising a plurality of first parameters including at least a MinDiscoveryChannelTime; Performing the WUR scanning process based on the plurality of first parameters; generating at least one confirmation primitive based on a 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, the plurality of second parameters comprising at least one of: a compressed at least a portion of a basic service set identifier (BSSID), or a compressed at least a portion of a service set identifier (SSID); as well as The at least one confirmation primitive is transmitted to the SME.

2. The method of claim 1, wherein the plurality of first parameters comprises at least one of: BSSIDList, SSIDList, compressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MaxDiscoveryChannelTime, MaxScanningTime, ReceivedPowerThreshod, WURScanningMode, WURScanningReportingOption, or RequestWURresult. The method according to claim 2 , wherein the WURCScanningMode indicates a WUR scanning mode. The method of claim 1 , wherein the plurality of second parameters further comprises BSSDescriptionFromWURDFSet. 5 . The method of claim 1 , further comprising associating with a BSS based on one or more of the plurality of second parameters of the at least one confirmation primitive. The method according to claim 1 , wherein the request primitive is an MLME-WURSCAN request primitive. The method according to claim 1 , wherein the request primitive is an MLME-SCAN request primitive.

8. The method of claim 1, further comprising generating a stop request primitive for stopping the WUR scanning process.

9. The method of claim 1, further comprising generating a stop confirmation primitive.

10. A station (STA), comprising: processor, configured as generating a request primitive that enables a wake-up radio (WUR) scanning procedure for WUR discovery frames transmitted by one or more access points (APs), the request primitive comprising a plurality of first parameters including at least a MinDiscoveryChannelTime, Performing the WUR scanning process based on the plurality of first parameters, generating at least one confirmation primitive based on a 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, the plurality of second parameters comprising at least one of: a compressed at least a portion of a basic service set identifier (BSSID), or a compressed at least a portion of a service set identifier (SSID); as well as The at least one confirmation primitive is transmitted to a Station Management Entity (SME).

11. The STA of claim 10, wherein the plurality of first parameters comprises at least one of: BSSIDList, SSIDList, compressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MaxDiscoveryChannelTime, MaxScanningTime, ReceivedPowerThreshod, WURScanningMode, WURScanningReportingOption, or RequestWURresult. The STA according to claim 11 , wherein the WURCScanningMode indicates a WUR scanning mode. 13 . The STA according to claim 10 , wherein the plurality of second parameters further comprises BSSDescriptionFromWURDFSet.

14. The STA of claim 10, further comprising a transceiver, the processor and the transceiver configured to associate with a BSS based on one or more of the plurality of second parameters of the at least one acknowledgment primitive. The STA according to claim 10 , wherein the request primitive is an MLME-WURSCAN request primitive.

16. The STA of claim 10, wherein the request primitive is generated by a station management entity (SME). The STA according to claim 10 , wherein the request primitive is an MLME-SCAN request primitive.

18. The STA of claim 10, wherein the processor is further configured to generate a stop request primitive for stopping the WUR scanning process.

19. The STA of claim 10, wherein the processor is further configured to generate a stop confirmation primitive.

Images